Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]

[Brendan Jones]

Absolutely. I apologise if you took offence Toshi. My rant was in by no 
means directed at you, but the subject at hand. Reading back it looks 
like I have targeted you unfairly - not my intention.
On 10/07/2010 02:51 PM, Toshio Kuratomi wrote:
> Uh. I'm talking purely about bundled libs here which are
> a distro/maintainer/packager issue much more than a user issue.  It becomes
> a user issue if the distro can't do it's job and keep all of the bundled
> libraries up to date and the user is forced to circumvent the distro
> packaging.


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

Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]

[Toshio Kuratomi]

On Thu, Oct 07, 2010 at 02:00:50PM +1000, Brendan Jones wrote:
> On 10/07/2010 12:10 PM, Toshio Kuratomi wrote:
> > But I agree that having a strict requirement because it's felt that the
> > issues that are raised by allowing the requirement to be violated are very
> > problematic for us as a distro but then letting certain things bundle
> > because they're more important than other packages is morale sapping.
> > Fesco is voting in the trac ticket on whether to allow libvpx to be bundled
> > and also whether to allow bundling of any library that mozilla decides to in
> > the future; I think if that passes the FPC will have to look at making it
> > easier for other packages to do the same.
> >
> > -Toshio
> >
> Surely its the users choice. I hate the fact that a distro feels the 
> need to align itself with one or the other - there are plenty 
> alternatives out there (which aren't chromium) that do the job. Let's 
> support these or stop whinging and fork firefox.
>
Uh. I'm talking purely about bundled libs here which are
a distro/maintainer/packager issue much more than a user issue.  It becomes
a user issue if the distro can't do it's job and keep all of the bundled
libraries up to date and the user is forced to circumvent the distro
packaging.

Trademarks may be more about users butthat's not what I'm talking about
here at all.

-Toshio



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

Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]

[Brendan Jones]

On 10/07/2010 12:10 PM, Toshio Kuratomi wrote:
> But I agree that having a strict requirement because it's felt that the
> issues that are raised by allowing the requirement to be violated are very
> problematic for us as a distro but then letting certain things bundle
> because they're more important than other packages is morale sapping.
> Fesco is voting in the trac ticket on whether to allow libvpx to be bundled
> and also whether to allow bundling of any library that mozilla decides to in
> the future; I think if that passes the FPC will have to look at making it
> easier for other packages to do the same.
>
> -Toshio
>
Surely its the users choice. I hate the fact that a distro feels the 
need to align itself with one or the other - there are plenty 
alternatives out there (which aren't chromium) that do the job. Let's 
support these or stop whinging and fork firefox.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]

[Toshio Kuratomi]

On Wed, Oct 06, 2010 at 04:55:46PM +0200, Tomas Mraz wrote:
> I give +1 to this. On the other hand Fedora also is (was?) a project
> where individual package maintainers had the biggest influence on what
> packages ship if they do not cross some fundamental legal limits. This
> changed in many ways recently and the restrictions and requirements are
> more and more technical, not just legal, and even controversial.
>
We have a long history of technical requirements actually.  In fedora.us we
even had re-reviews when packages were updated.

> The
> problem here really is that some "not so important?" projects are forced
> to accept all the restrictions and requirements and other "more
> important?" projects get a free pass from them. This is unfortunate and
> it does not improve the spirit of the package maintainers.
> 
Well, there's also the security, bugfix, and encouraging forking issues that
are listed here:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

But I agree that having a strict requirement because it's felt that the
issues that are raised by allowing the requirement to be violated are very
problematic for us as a distro but then letting certain things bundle
because they're more important than other packages is morale sapping.
Fesco is voting in the trac ticket on whether to allow libvpx to be bundled
and also whether to allow bundling of any library that mozilla decides to in
the future; I think if that passes the FPC will have to look at making it
easier for other packages to do the same.

-Toshio


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

Re: Firewall settings unworkable

[Genes MailLists]

On 10/06/2010 11:26 AM, Thomas Woerner wrote:

> 6) Compatibility Mode
> 
> The current static firewall model will still be available for 
> compatibility for users or administrators creating their own firewall. 
> This deactivates the firewall service and also the D-BUS daemon.
> 
> ---
> 
> Comments and additional information is highly welcome.
> 

  I hope by 'compatibility mode' you mean it is 'completely off' and
there is no possibility of it touching the rules because its not running
in any form.

  Its vital for those of us who have hand coded firewall rules that this
is totally turned off and it is impossible for it to touch the rules.

   In my case, I have about 40,000 rules and I def don't want anything
else mucking with them!

   Thanks - its an interesting idea and the default firewall could use
some spiffing up for many use cases.


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

Re: Fedora 14 Blocker Bugs + Review Meeting 2010-10-08 @ 16:00 UTC (12 PM EST)

[Piscium]

On 6 October 2010 23:25, Adam Williamson  wrote:

> This isn't generally how we do things. We encourage people to mark bugs
> as blockers; this constitutes *nominating* the bug as a blocker, it
> makes it pop up for review at a blocker review meeting. We then usually
> determine whether or not the bug meets the criteria during the review
> meeting, collaboratively between...well, theoretically between qa,
> releng and devel, practically between whoever shows up for the review
> meeting. :) We would then give it the whiteboard field AcceptedBlocker
> if we accepted it, or remove the Blocks: field and add the whiteboard
> field RejectedBlocker if we rejected it.

There is an outstanding bug with respect to the host name set in
Anaconda that is not kept when using the Live CD. It has been fixed in
Rawhide, the question is if it should also be fixed in F14.

Its overall impact is low. Many people leave the host name as
localhost - no impact. Others might have let's say a small home
network with two or three PCs - it is straightforward to manually
change the host name after installation. I am unsure however if this
would impact sysadmins that have for example 10 or more PCs or servers
on a network. Do they use Anaconda or Live CDs at all? Perhaps
sysadmins would like to take a look at this:
https://bugzilla.redhat.com/show_bug.cgi?id=638634
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 14 Blocker Bugs + Review Meeting 2010-10-08 @ 16:00 UTC (12 PM EST)

[Brian Pepple]

On Wed, 2010-10-06 at 15:25 -0700, Adam Williamson wrote:
> On Wed, 2010-10-06 at 18:05 -0400, Brian Pepple wrote:
> > On Wed, 2010-10-06 at 17:53 -0400, John Poelstra wrote:
> > > --If you are the OWNER of one of these bugs, PLEASE add a comment to the 
> > > bug letting us know how things are going and what you are planning to do 
> > > next.  I
> > 
> > > 639730 :: MODIFIED :: empathy :: bdpep...@gmail.com :: Empathy fails to 
> > > connect to Google Talk :: 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=639730
> > 
> > This bug shouldn't have been marked as a blocker since it's doesn't meet
> > the criteria for being a blocker. I've gone ahead and removed the
> > blocker.
> 
> This isn't generally how we do things. We encourage people to mark bugs
> as blockers; this constitutes *nominating* the bug as a blocker, it
> makes it pop up for review at a blocker review meeting. We then usually
> determine whether or not the bug meets the criteria during the review
> meeting, collaboratively between...well, theoretically between qa,
> releng and devel, practically between whoever shows up for the review
> meeting. :) We would then give it the whiteboard field AcceptedBlocker
> if we accepted it, or remove the Blocks: field and add the whiteboard
> field RejectedBlocker if we rejected it.

My bad, wasn't aware how that was handled. Thanks for the heads-up.

Later,
/B
-- 
Brian Pepple 

https://fedoraproject.org/wiki/User:Bpepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E


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: Fedora 14 Blocker Bugs + Review Meeting 2010-10-08 @ 16:00 UTC (12 PM EST)

[Adam Williamson]

On Wed, 2010-10-06 at 18:05 -0400, Brian Pepple wrote:
> On Wed, 2010-10-06 at 17:53 -0400, John Poelstra wrote:
> > --If you are the OWNER of one of these bugs, PLEASE add a comment to the 
> > bug letting us know how things are going and what you are planning to do 
> > next.  I
> 
> > 639730 :: MODIFIED :: empathy :: bdpep...@gmail.com :: Empathy fails to 
> > connect to Google Talk :: https://bugzilla.redhat.com/show_bug.cgi?id=639730
> 
> This bug shouldn't have been marked as a blocker since it's doesn't meet
> the criteria for being a blocker. I've gone ahead and removed the
> blocker.

This isn't generally how we do things. We encourage people to mark bugs
as blockers; this constitutes *nominating* the bug as a blocker, it
makes it pop up for review at a blocker review meeting. We then usually
determine whether or not the bug meets the criteria during the review
meeting, collaboratively between...well, theoretically between qa,
releng and devel, practically between whoever shows up for the review
meeting. :) We would then give it the whiteboard field AcceptedBlocker
if we accepted it, or remove the Blocks: field and add the whiteboard
field RejectedBlocker if we rejected it.

It's not a big deal in this case as I'm pretty sure we'd vote against it
being a blocker at the meeting, but just mentioning the procedure.
Unfortunately the whole process isn't currently documented on the wiki,
but I have a draft SOP documenting it under review at present:

https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_blocker_bug_process_nth_draft

of course, it really helps if devs who have bugs nominated (or accepted)
as blockers can come to the blocker review meetings and help with the
discussion of those bugs. (The blocker reviews take place Fridays in
#fedora-bugzappers ).

so generally it probably works best if you just add a comment in the bug
saying you'd vote against it being a blocker, and if you have the time,
come along to the review meeting and join in the discussion there. For
this bug it's no biggie though, I think we're fine with it not being a
blocker.
-- 
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 Blocker Bugs + Review Meeting 2010-10-08 @ 16:00 UTC (12 PM EST)

[Brian Pepple]

On Wed, 2010-10-06 at 17:53 -0400, John Poelstra wrote:
> --If you are the OWNER of one of these bugs, PLEASE add a comment to the 
> bug letting us know how things are going and what you are planning to do 
> next.  I

> 639730 :: MODIFIED :: empathy :: bdpep...@gmail.com :: Empathy fails to 
> connect to Google Talk :: https://bugzilla.redhat.com/show_bug.cgi?id=639730

This bug shouldn't have been marked as a blocker since it's doesn't meet
the criteria for being a blocker. I've gone ahead and removed the
blocker.

Later,
/B
-- 
Brian Pepple 

https://fedoraproject.org/wiki/User:Bpepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E


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

Fedora 14 Blocker Bugs + Review Meeting 2010-10-08 @ 16:00 UTC (12 PM EST)

[John Poelstra]

When: Friday, 2010-10-08 @ 16:00 UTC (12 PM EST)
Where: #fedora-bugzappers on irc.freenode.net

Here are the current bugs listed as blocking the final release of Fedora 
14. We'll be discussing all of these to determine if they meet the 
criteria, should stay on the list, and are getting the attention they 
need.

--If you are the OWNER of one of these bugs, PLEASE add a comment to the 
bug letting us know how things are going and what you are planning to do 
next.  I

--If your bug is in MODIFIED, please make sure a build and bodhi update 
have been submitted.  If that's already happened, please change the bug 
to ON_QA so we can start test verificaiton.

Thank you,
John

599873 :: NEW :: valide :: bioinfornat...@gmail.com :: FTBFS 
valide-0.6.1-0.22.20103003svn511.fc14 :: 
https://bugzilla.redhat.com/show_bug.cgi?id=599873

635821 :: NEW :: anaconda :: anaconda-maint-l...@redhat.com :: 
Attempting to submit (scp or bugzilla) an exception report fails if 
networking not active :: https://bugzilla.redhat.com/show_bug.cgi?id=635821

640271 :: NEW :: install-guide :: da...@gnsa.us :: Fedora 14 
installation guide references "RHEL" in examples :: 
https://bugzilla.redhat.com/show_bug.cgi?id=640271

640309 :: NEW :: install-guide :: da...@gnsa.us :: F-14 installation 
guide documents unsupported 'telnet' method :: 
https://bugzilla.redhat.com/show_bug.cgi?id=640309

635333 :: NEW :: libgdl :: debarshi@gmail.com :: libgdl needs to be 
downgraded to 2.30.x :: https://bugzilla.redhat.com/show_bug.cgi?id=635333

584328 :: NEW :: anaconda :: dleh...@redhat.com :: AttributeError: 
'NoneType' object has no attribute 'name' :: 
https://bugzilla.redhat.com/show_bug.cgi?id=584328

639985 :: NEW :: python :: dmalc...@redhat.com :: Firefox crashes with 
xulrunner-python installed :: 
https://bugzilla.redhat.com/show_bug.cgi?id=639985

639393 :: NEW :: qtgpsc :: fab...@bernewireless.net :: Broken 
dependency: qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) :: 
https://bugzilla.redhat.com/show_bug.cgi?id=639393

617284 :: NEW :: distribution :: jfor...@redhat.com :: Fedora 14 
Virtualization Target Blocker :: 
https://bugzilla.redhat.com/show_bug.cgi?id=617284

639395 :: NEW :: intellij-idea :: lkund...@v3.sk :: Broken dependency: 
intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples :: 
https://bugzilla.redhat.com/show_bug.cgi?id=639395

627388 :: NEW :: anaconda :: msi...@redhat.com :: VNC install ignores 
password :: https://bugzilla.redhat.com/show_bug.cgi?id=627388

639391 :: NEW :: spacewalk-certs-tools :: msu...@redhat.com :: Broken 
dependency: spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires 
spacewalk-backend-libs >= 0:0.8.28 :: 
https://bugzilla.redhat.com/show_bug.cgi?id=639391

628528 :: NEW :: xorg-x11-server :: peter.hutte...@redhat.com :: 
Emulating middle button doesn't work anymore. :: 
https://bugzilla.redhat.com/show_bug.cgi?id=628528

633298 :: NEW :: kde-settings :: rdie...@math.unl.edu :: Fedora 14 
Blocker KDE Tracker :: https://bugzilla.redhat.com/show_bug.cgi?id=633298

629192 :: NEW :: pino :: rosset.fil...@gmail.com :: Twitter isn't 
functioning :: https://bugzilla.redhat.com/show_bug.cgi?id=629192

528022 :: ASSIGNED :: vbetool :: a...@redhat.com :: setroubleshoot: 
  SELinux is preventing /usr/sbin/vbetool "mmap_zero" access on 
. :: https://bugzilla.redhat.com/show_bug.cgi?id=528022

620635 :: ASSIGNED :: antlr3 :: xja...@fi.muni.cz :: antlr3 needs to be 
rebuilt against python 2.7 in F14 and devel :: 
https://bugzilla.redhat.com/show_bug.cgi?id=620635

635778 :: MODIFIED :: anaconda :: b...@redhat.com :: IndexError: list 
index out of range :: https://bugzilla.redhat.com/show_bug.cgi?id=635778

627789 :: MODIFIED :: anaconda :: b...@redhat.com :: Error setting up 
repository - 16, Device busy :: 
https://bugzilla.redhat.com/show_bug.cgi?id=627789

637339 :: MODIFIED :: empathy :: bdpep...@gmail.com :: empathy 2.31.90-2 
blocked by SELinux :: https://bugzilla.redhat.com/show_bug.cgi?id=637339

639730 :: MODIFIED :: empathy :: bdpep...@gmail.com :: Empathy fails to 
connect to Google Talk :: https://bugzilla.redhat.com/show_bug.cgi?id=639730
___
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: Making Fedora work with laptops on docking station with external monitor

[Adam Williamson]

On Wed, 2010-10-06 at 23:32 +0300, Pasi Kärkkäinen wrote:

> What's the worst thing that can happen when trusting the ACPI lid state?
> 
> Think about this:
> 
> - Laptop lid open (so internal lvds enabled), and also external monitor 
> connected.
> - lid state is wrong at boot, so it says lid closed.
> - Scripts check: "lid closed, external display enabled -> use only external 
> monitor".
> 
> That gives you a working setup, you can login using the external display,
> and use the system perfectly fine. You can then manually enable the 
> internal lvds display, or possibly enable some workaround, 
> as you have a buggy laptop/driver/bios.
> 
> That doesn't sound bad at all.

However, it's not the worst case. The worst case is if someone has an
external monitor connected which they're not actually using (it may be
hidden or being used with some other input or just turned off). This
does happen:

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

that bug is already inconvenient for some people; if they have laptops
with bad lid switches it'd be much more inconvenient. The only active
display would be the external display they weren't actually using.
-- 
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

2 More Packaging Guideline Updates

[Toshio Kuratomi]

There's 2 more Guidelines that were approved in past meetings that have just
been written up.

= Directory ownership update =
https://fedorahosted.org/fpc/ticket/5
6 +1 votes , no 0 votes, and no -1 votes

This update makes it clearer that packages like gtk-doc do not need to be
required simply to own a directory and gives some examples of things that
are required for other reasons vs only directory ownership.

= Not using Sourcedir =
https://fedorahosted.org/fpc/ticket/12

We sent this one to FESCo for review after approving it.  They also approved
it so it's now written up.  It prohibits the use of $RPM_SOURCE_DIR or
%{_sourcedir} to install files.  Instead, %{SOURCEN} should always be used.

-Toshio


pgpR2JLy3bHxV.pgp
Description: 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

Re: xulrunner 2.0 in rawhide (F15) bundles several system libs

[Martin Sourada]

On Mon, 2010-10-04 at 09:57 +0200, Martin Stransky wrote:
> On 09/30/2010 08:54 PM, Sven Lankes wrote:
> > 2. The combination of the Mozilla Trademark issue combined with the
> > strict handling of patches by (corporate|distro)-maintainers (I don't
> > think that this is a RH/Fedora issue - same with Canonical/Ubuntu)
> > makes me feel uneasy about ff being called Free sofware.
> >
> 
> Please look at this list:
> 
> https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&component=firefox&product=Fedora&classification=Fedora
> 
> https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&component=thunderbird&product=Fedora&classification=Fedora
> 
> There are 1108 open bugs against Firefox and 404 bugs against 
> Thunderbird and new bugs are coming. And there are only three mozilla 
> maintainers at Red Hat.
> 
> As you can see, it's impossible for us to fix (or even sort!) all 
> reported bugs so we really have to cooperate with mozilla upstream, 
> which involves *hundreds* of skilled mozilla hackers.
> 
> Right now, we are in process to redirect firefox/thunderbird crashes 
> directly to mozilla crash database (http://crash-stats.mozilla.com) 
> which is handled by mozilla guys, instead of our bugzilla, so they can 
> help us with all Fedora Firefox/Thunderbird crashes.
> 
> And you can imagine that we can't achieve that with Fedora customized 
> Firefox build. If we want help from upstream we have to follow some rules.
> 
I don't want to add more fuel to the fire, but from my viewpoint there
are only three manageable options:

  * Grant exception for xulrunner to bundle these libs temporarily
and press Mozilla to add support for system libs.
  * Convince mozilla that our (as of now hypothetical) patches to
unbundle the libs are good enough for them to accept their
inclusion in our package without having to re-brand.
  * Switch to different upstream (i.e. iceweasel or icecat or
whatever it is called). This is vastly different from
maintaining our own fork...

I would lean towards the first one with strong emphasis on "press
Mozilla to add support for system libs". But I have my doubts about
mozilla in this regard, after all, proper support on linux does not seem
to be high priority for them (Why the heck don't they put proper
versions to their shared libs? Why the heck do they bundle codecs
directly and with their own patches and refuse to include patches to
support using system libs?...)

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: Making Fedora work with laptops on docking station with external monitor

[Pasi Kärkkäinen]

On Wed, Oct 06, 2010 at 12:33:58PM -0700, Adam Williamson wrote:
> On Wed, 2010-10-06 at 22:03 +0300, Pasi Kärkkäinen wrote:
> > On Tue, Oct 05, 2010 at 11:28:43AM -0700, Adam Williamson wrote:
> > > On Tue, 2010-10-05 at 19:20 +0100, Matthew Garrett wrote:
> > > > On Tue, Oct 05, 2010 at 11:18:32AM -0700, Adam Williamson wrote:
> > > > 
> > > > > don't we already have default behaviours based on the lid switch,
> > > > > anyway? So why don't we have this problem with those? IIRC, we default
> > > > > to suspending the system when the lid is closed on battery power - so
> > > > > are we suspending people's systems at random, if those systems have
> > > > > lying lid switches?
> > > > 
> > > > Because we only do that on lid state transitions.
> > > 
> > > So we could at least cover the case where you plug in an external
> > > monitor, then close the lid? That would be better than nothing. I assume
> > > the problem case is booting with the lid closed and an external monitor
> > > connected.
> > >
> > 
> > Exactly, that's the problematic case.
> > 
> > When you boot F14 laptop lid closed and only external monitor
> > connected, GDM still appears only on the closed internal LVDS,
> > not on the external monitor where is should be. 
> > So the behaviour is clearly wrong.
> > 
> > This is on HP laptop with radeon graphics.
> > 
> 
> You're missing the nuance of the debate. What I mean by 'problem case'
> is that, according to mjg59, lid sensors don't always actually work
> correctly; there are many documented cases of systems whose lid switches
> report incorrect state, especially at boot. So we can't just say 'always
> enable the external monitor and disable the internal monitor if the lid
> switch says 'closed' and there's an external monitor connected', because
> the lid switch might be lying.
>

Well.. I think as a default we should trust the lid state.
Buggy drivers should be fixed. Buggy BIOSes should be reported to system 
vendors.

What's the worst thing that can happen when trusting the ACPI lid state?

Think about this:

- Laptop lid open (so internal lvds enabled), and also external monitor 
connected.
- lid state is wrong at boot, so it says lid closed.
- Scripts check: "lid closed, external display enabled -> use only external 
monitor".

That gives you a working setup, you can login using the external display,
and use the system perfectly fine. You can then manually enable the 
internal lvds display, or possibly enable some workaround, 
as you have a buggy laptop/driver/bios.

That doesn't sound bad at all.
The current situation is far more problematic.

If you the lid state is "closed" and there are no external connected monitors,
then maybe enable the lvds anyway..

Did I miss something?

-- Pasi

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

Re: Firewall settings unworkable

[R P Herrold]

On Wed, 6 Oct 2010, Richard W.M. Jones wrote:

> Seems quite complex.  What's wrong with a directory:
>
>  /etc/iptables.d/
>
> where RPMs like libvirt just drop the required additional rules (in a
> separate chain if you like) and restart the iptables service?  It's
> low-tech but simple and it's all that libvirt needs.

As iptables are 'first match wins', there is a need to be 
willing to commit to documenting a SNN type mechanism, and to 
maintain it long term as well

Considering the upstart and related 'dependency driven' 
initscript mechanisms are all the vogue in some quarters these 
days as well, integrating this as devices come and go, and 
those devices optionally carry with them new network 
connectivity patterns, appearing and disappearing, it is not 
clear this is very workable

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

[Bug 640752] Broken dependency: perl-Test-Simple-tests-0.94-2.fc14.noarch requires perl-Test-Simple = 0:0.94-2.fc14

[bugzilla]

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


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

James Laska  changed:

   What|Removed |Added

Summary|Broken dependencies found   |Broken dependency:
   |with|perl-Test-Simple-tests-0.94
   |perl-Test-Simple-0.94-2.fc1 |-2.fc14.noarch requires
   |4   |perl-Test-Simple =
   ||0:0.94-2.fc14

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 640752] Broken dependencies found with perl-Test-Simple-0.94-2.fc14

[bugzilla]

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


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

Paul Howarth  changed:

   What|Removed |Added

 CC||p...@city-fan.org

--- Comment #2 from Paul Howarth  2010-10-06 15:38:50 EDT ---
perl-Test-Simple = 0:0.94-2.fc14 *is* in the repository but it's not the latest
version there. The report probably stems from running repoclosure with the
"newest" option.

This will probably show up quite often where there are dual-lived perl modules
that are built both as part of the main perl package and as separate packages
from the CPAN distribution. In this case the version built from the main perl
package is newer, but it doesn't include the "tests" subpackage.

It would make sense to either ship the tests with the main perl package
version, or not ship them with the CPAN version to avoid this problem in
future.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Firewall settings unworkable

[Dennis Jacobfeuerborn]

On 10/06/2010 08:31 PM, Richard W.M. Jones wrote:
> Seems quite complex.  What's wrong with a directory:
>
>/etc/iptables.d/
>
> where RPMs like libvirt just drop the required additional rules (in a
> separate chain if you like) and restart the iptables service?  It's
> low-tech but simple and it's all that libvirt needs.

If you do an "/etc/init.d/iptables save" and then reboot the machine you 
will probably end up with duplicate rules because the libvirt rules are now 
created from /etc/sysconfig/iptables and then again from the respective 
iptables.d file.

That's why I mentioned the two layer approach. You basically need a layer 
that loads the basic rules and then applies the per-subsystem ones and that 
is able to extract the per-subsystem rules again on save. This could be 
relatively easy or very hard depending the subset of rules you want to 
support for the subsystems.

Thomas Woerners idea looks like the best approach to this. I was aiming for 
a more iterative approach using scripts instead of a daemon but if Thomas 
has fleshed this out already and some code working then more power to him :)

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

Re: Making Fedora work with laptops on docking station with external monitor

[Adam Williamson]

On Wed, 2010-10-06 at 22:03 +0300, Pasi Kärkkäinen wrote:
> On Tue, Oct 05, 2010 at 11:28:43AM -0700, Adam Williamson wrote:
> > On Tue, 2010-10-05 at 19:20 +0100, Matthew Garrett wrote:
> > > On Tue, Oct 05, 2010 at 11:18:32AM -0700, Adam Williamson wrote:
> > > 
> > > > don't we already have default behaviours based on the lid switch,
> > > > anyway? So why don't we have this problem with those? IIRC, we default
> > > > to suspending the system when the lid is closed on battery power - so
> > > > are we suspending people's systems at random, if those systems have
> > > > lying lid switches?
> > > 
> > > Because we only do that on lid state transitions.
> > 
> > So we could at least cover the case where you plug in an external
> > monitor, then close the lid? That would be better than nothing. I assume
> > the problem case is booting with the lid closed and an external monitor
> > connected.
> >
> 
> Exactly, that's the problematic case.
> 
> When you boot F14 laptop lid closed and only external monitor
> connected, GDM still appears only on the closed internal LVDS,
> not on the external monitor where is should be. 
> So the behaviour is clearly wrong.
> 
> This is on HP laptop with radeon graphics.
> 

You're missing the nuance of the debate. What I mean by 'problem case'
is that, according to mjg59, lid sensors don't always actually work
correctly; there are many documented cases of systems whose lid switches
report incorrect state, especially at boot. So we can't just say 'always
enable the external monitor and disable the internal monitor if the lid
switch says 'closed' and there's an external monitor connected', because
the lid switch might be lying.
-- 
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: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]

[Gregory Maxwell]

On Wed, Oct 6, 2010 at 10:08 AM, Michal Schmidt  wrote:
[snip]
> Of course. But there's in fact no disagreement, only looking at
> different aspects of the same thing.
>
> Why do you think the copying takes place? Because the companies have
> built a good reputation and brand, allowing them to increase profit.
>
> Good quality => good reputation => solid brand => better profits.
>
> Then copyists try to get better profits too without bothering to
> build their own good reputation, by deceiving the buyers into thinking
> the original company with good reputation produced their goods.
>
> I'm really quite surprised about this thread. Of all the stuff
> often put under the confusing term "intellectual property" I expected
> trademarks to be the least controversial.

Exactly.  I often describe trademarks as a kind of consumer protection
law— but instead of using the blunt tool of government driven
enforcement it relies on the existence of an interested party (the
trademark holder) to provide the protection at their own expense with
enforcement via civil law.

This has advantages (it's very flexible, enforcement can be made to
match the need, the public doesn't need to pay for it directly) and
disadvantages (it suffers if the interested party is either not
interested enough or too interested), but regardless it's pretty much
something categorically different from, say, patents... which have no
consumer-protective properties and which are very difficult to escape
(compared to changing a package name/branding).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Review request: Nice-to-have bug process documentation proposal

[Adam Williamson]

On Wed, 2010-10-06 at 14:58 -0400, John Poelstra wrote:
> Adam Williamson said the following on 10/06/2010 01:32 PM Pacific Time:
> > On Thu, 2010-09-23 at 12:58 +0100, Adam Williamson wrote:
> >> Hi, everyone. So we partly used the proposed new nice-to-have bug
> >> tracking system during the F14 Beta process, and it seemed to go well.
> >> In a quick burst of airport productivity, I've quickly written up a
> >> bunch of proposed new wiki pages and modifications to existing ones to
> >> document the nice-to-have process (and, incidentally, extend
> >> documentation of the blocker process, since we don't seem to have much
> >> of it beyond the blocker meeting SOP right now). All the pages can be
> >> found here:
> >>
> >> https://fedoraproject.org/wiki/Category:NTH_adjustment_drafts
> >
> > Thanks to James for his feedback on this. I haven't had much feedback
> > from anyone else. However, given that in practice everyone involved in
> > the release review process has been happy using the NTH system drafted
> > here so far, I intend to make the draft changes final (with
> > modifications to reflect James' feedback) by the end of the week, so if
> > you have any feedback you've been sitting on, now would be the perfect
> > time to send it :) Thanks everyone!
> 
> Can you be more specific as to which page we are actually giving 
> feedback on?  There are five of them there and they almost all look the 
> same.

All of them. They're mostly modifications of existing pages. I'm not
quite sure how you get that they look the same, they're very different.

https://fedoraproject.org/wiki/User:Adamwill/Draft_desktop_results_nth_adjust 
is a proposed change to 
https://fedoraproject.org/wiki/QA:Desktop_validation_results_template .

https://fedoraproject.org/wiki/User:Adamwill/Draft_desktop_validation_nth_adjust
 is a proposed change to 
https://fedoraproject.org/wiki/QA:Desktop_validation_testing .

https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_blocker_bug_meeting_nth_draft
 is a proposed change to 
https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting .

https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_blocker_bug_process_nth_draft
 is a proposed new page; it's not particularly specific to the nice-to-have 
proposal, actually, it just became apparent while I was doing this that we have 
no page which explains the entire blocker bug review process, and we should 
have one. This is it.

https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_nth_process_nth_draft is a 
proposed new page which covers the whole nice-to-have review process much as 
the above proposed page covers the blocker review process.

I included a summary of the whole proposed NTH process in my initial
review request mail. These are the wiki changes necessary to document
that process.
-- 
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: Making Fedora work with laptops on docking station with external monitor

[Pasi Kärkkäinen]

On Tue, Oct 05, 2010 at 07:31:54PM +0100, Peter Robinson wrote:
> On Tue, Oct 5, 2010 at 7:28 PM, Adam Williamson  wrote:
> > On Tue, 2010-10-05 at 19:20 +0100, Matthew Garrett wrote:
> >> On Tue, Oct 05, 2010 at 11:18:32AM -0700, Adam Williamson wrote:
> >>
> >> > don't we already have default behaviours based on the lid switch,
> >> > anyway? So why don't we have this problem with those? IIRC, we default
> >> > to suspending the system when the lid is closed on battery power - so
> >> > are we suspending people's systems at random, if those systems have
> >> > lying lid switches?
> >>
> >> Because we only do that on lid state transitions.
> >
> > So we could at least cover the case where you plug in an external
> > monitor, then close the lid? That would be better than nothing. I assume
> > the problem case is booting with the lid closed and an external monitor
> > connected.
> 
> The BIOS generally manages to get that one correct, can we not query
> and keep the current state on boot?
> 

Yep, BIOS gets it correct for me (HP laptop with radeon graphics).
For Fedora to get it correct it's enough for  to check:

$ cat /proc/acpi/button/lid/LID/state
state:  closed

and then disable the internal LVDS, and enable external (connected) monitor.

-- Pasi


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

Re: Making Fedora work with laptops on docking station with external monitor

[Pasi Kärkkäinen]

On Tue, Oct 05, 2010 at 11:28:43AM -0700, Adam Williamson wrote:
> On Tue, 2010-10-05 at 19:20 +0100, Matthew Garrett wrote:
> > On Tue, Oct 05, 2010 at 11:18:32AM -0700, Adam Williamson wrote:
> > 
> > > don't we already have default behaviours based on the lid switch,
> > > anyway? So why don't we have this problem with those? IIRC, we default
> > > to suspending the system when the lid is closed on battery power - so
> > > are we suspending people's systems at random, if those systems have
> > > lying lid switches?
> > 
> > Because we only do that on lid state transitions.
> 
> So we could at least cover the case where you plug in an external
> monitor, then close the lid? That would be better than nothing. I assume
> the problem case is booting with the lid closed and an external monitor
> connected.
>

Exactly, that's the problematic case.

When you boot F14 laptop lid closed and only external monitor
connected, GDM still appears only on the closed internal LVDS,
not on the external monitor where is should be. 
So the behaviour is clearly wrong.

This is on HP laptop with radeon graphics.

-- Pasi

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

Re: Making Fedora work with laptops on docking station with external monitor

[Pasi Kärkkäinen]

On Tue, Oct 05, 2010 at 08:53:12AM -0700, Adam Williamson wrote:
> On Tue, 2010-10-05 at 09:35 +0100, Richard Hughes wrote:
> > On 5 October 2010 05:30, Orion Poplawski  wrote:
> > > Are we really stuck with gdm/kdm/lxdm/...dm
> > > implementing it?
> > 
> > No, I think what we need to do is to teach GPM how to turn off the
> > internal panel when docked and with the lid closed. The only missing
> > piece is for the kernel to export some kind of sysfs boolean saying
> > "in-dock". From talks with mjg59, detecting a dock is pretty hard.
> 
> Maybe just 'lid closed and external monitor connected' would be close
> enough? Is there a use case where you'd want to have an external monitor
> connected and the internal system's lid closed, but still have the
> internal system's display turned on?
>

Yep, that's enough info.

$ cat /proc/acpi/button/lid/LID/state
state:  open

$ cat /proc/acpi/button/lid/LID/state
state:  closed


That lid info combined with info about external monitors connected or not:


$ ls /sys/class/drm/card0
card0-DVI-D-1card0-LVDS-1  dev power  uevent
card0-HDMI Type A-1  card0-VGA-1   device  subsystem

$ cat /sys/class/drm/card0/card0-LVDS-1/status
connected

$ cat /sys/class/drm/card0/card0-LVDS-1/enabled
enabled

Same info is available for external VGA/DVI/HDMI outputs.


-- Pasi

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

Re: Review request: Nice-to-have bug process documentation proposal

[John Poelstra]

Adam Williamson said the following on 10/06/2010 01:32 PM Pacific Time:
> On Thu, 2010-09-23 at 12:58 +0100, Adam Williamson wrote:
>> Hi, everyone. So we partly used the proposed new nice-to-have bug
>> tracking system during the F14 Beta process, and it seemed to go well.
>> In a quick burst of airport productivity, I've quickly written up a
>> bunch of proposed new wiki pages and modifications to existing ones to
>> document the nice-to-have process (and, incidentally, extend
>> documentation of the blocker process, since we don't seem to have much
>> of it beyond the blocker meeting SOP right now). All the pages can be
>> found here:
>>
>> https://fedoraproject.org/wiki/Category:NTH_adjustment_drafts
>
> Thanks to James for his feedback on this. I haven't had much feedback
> from anyone else. However, given that in practice everyone involved in
> the release review process has been happy using the NTH system drafted
> here so far, I intend to make the draft changes final (with
> modifications to reflect James' feedback) by the end of the week, so if
> you have any feedback you've been sitting on, now would be the perfect
> time to send it :) Thanks everyone!

Can you be more specific as to which page we are actually giving 
feedback on?  There are five of them there and they almost all look the 
same.

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

Re: Making Fedora work with laptops on docking station with external monitor

[Pasi Kärkkäinen]

On Tue, Oct 05, 2010 at 06:29:21PM -0600, Dariusz J. Garbowski wrote:
> On 05/10/10 08:40 AM, FlorianFesti wrote:
> >   On 10/05/2010 03:15 PM, Nathaniel McCallum wrote:
> >> If the lid is open, both output should be enabled by default (you are
> >> free to manually disable one).  If the lid is closed on battery power
> >> the system should suspend (unless you choose otherwise in GPM prefs).
> >>
> > I wonder if there are latops that can be booted with lid closed and that 
> > make a subtle sematic difference between the lid was just being closed 
> > and is lid was already closed when we booted up.
> 
> Dells can boot with lid closed when connected to dock. I do that every day :-)
> 

Yep, I also boot my HP laptop lid closed, in a dock.

-- Pasi

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

Re: Summary/Minutes for today's FESCo meeting (2010-10-05)

[Kevin Fenzi]

On Wed, 06 Oct 2010 19:20:55 +0200
Harald Hoyer  wrote:

> here we go:
> 
> https://admin.fedoraproject.org/updates/dracut-005-5.fc13
> https://admin.fedoraproject.org/updates/dracut-005-5.fc12
> 
> Patches are here:
> 
> short URL: http://goo.gl/23Bu
> 
> http://pkgs.fedoraproject.org/gitweb/?p=dracut.git;a=tree;h=refs/heads/f13/master;hb=f13/master

Thanks. 

This seems like a lot of change for stable releases, but if they are
all bugfixes that might matter to those users I suppose it makes sense. 

Thanks for adding more details. 

kevin


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

Re: Summary/Minutes for today's FESCo meeting (2010-10-05)

[Kevin Fenzi]

On Wed, 6 Oct 2010 08:29:32 -0400
Brandon Lozza  wrote:

...snip many tons of lines... 

Can you please trim your replies?

> Interesting, from the meeting we can tell
> 
> 1) A number of people want to give Mozilla an exception.
> 
> 2) BRANDING is an issue, like I said in another thread. Which is why
> people are against removing it.
> 
> 3) Maintainers for Mozilla aren't being expected to follow package
> guidelines, citing the use of system libs as a source of extra work.

No, it's that upstream doesn't want them to unbundle those libs right
now, no matter how much work they are willing to do. 

> 4) People still seem to think that Iceweasel is somehow inferior to
> Firefox. Plus if Fedora removed the branding it wouldn't remove
> compatibility, source code, plugin support and wouldn't introduce
> so-called "sketchy" patches.

Do you have a f14 rpm for iceweasel people could try out and examine?

kevin


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

Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft

[Kevin Fenzi]

On Wed, 29 Sep 2010 09:19:08 +0200
Michal Schmidt  wrote:

> On Tue, 28 Sep 2010 17:14:28 -0600 Kevin Fenzi wrote:
> > On Tue, 28 Sep 2010 18:45:11 +0200
> > Jaroslav Reznik  wrote:
> > > 
> > > Ok - that's one problem - we sucks in selective updates and
> > > information for users.
> > >
> > > Other could be - change release scheme:
> > > 1. very similar to current one - rawhide, Fn, Fn-1
> > > * rawhide - really raw development platform
> > > * Fn - live release, similar to current state but more testing
> > > (proventesters, autoqa)
> > > * Fn-1 - do not touch, even more strict rules
> > 
> > Thats what https://fedoraproject.org/wiki/Updates_Policy already
> > attempts to impress on maintainers. 
> 
> In the policy I do not see as clear distinction between F(n) (current
> stable) and F(n-1) (old stable) as Jaroslav proposes. The closest to
> it is this sentence:
>   The update rate for any given release should drop off over time,
>   approaching zero near release end-of-life.
> The wording suggests a continuous rate of change which is weird and
> hard to get right.
> 
> An explicit distinction between F(n) and F(n-1) would make sense for
> at least these reasons:
>  - Many users of F(n) desire current versions of end-user software
>in updates (of course given that it gets tested sufficiently before
>being pushed there and that the new version is not a revolutionary
>change since the previous version).
>  - Some users intentionally install F(n-1) only after F(n) is
> released, believing it to be more stable and more conservative about
> updates (important fixes only) than F(n). I guess this is intuitive
> to users.
>  - F(n)-updates-testing usually has a reasonable amount of users, but
>much fewer people use F(n-1)-updates-testing.

How would you suggest wording this? The above is what people might
expect from a F(n-1), but what policy would match these goals?

ie, how can we explain how F(n-1) is different from F(n) for
maintainers? What updates should be in one and not the other? 

kevin


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

[Bug 640752] Broken dependencies found with perl-Test-Simple-0.94-2.fc14

[bugzilla]

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


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

--- Comment #1 from James Laska  2010-10-06 14:37:31 EDT ---
Sorry, typo, that was supposed to be ...

 package: perl-Test-Simple-tests-0.94-2.fc14.noarch from F-14-x86_64
   unresolved deps: 
  perl-Test-Simple = 0:0.94-2.fc14

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

FPC Meeting -- Guideline Changes

[Toshio Kuratomi]

At todays FPC meeting, the FPC approved several guideline changes.

= Rationale for Conflicts Guideline =

https://fedorahosted.org/fpc/ticket/18
6 +1, no 0, no -1. 

This was purely informational and requires no changes to how you package

= Appropriate Content in Changelogs =
https://fedorahosted.org/fpc/ticket/17
6 +1, no 0, no -1 

At fesco's request we explored what content was appropriate for rpm
changelogs.  Our goal here was to not impose a burden or change on most
maintainers while still clarifying what was expected and not expected
content in a changelog entry.

= Update filtering of Provides and Requires =
https://fedorahosted.org/fpc/ticket/16
6 +1, no 0, no -1 

This change updated both the Auto Provides and Requires Filtering page:
https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering

and the perl packaging guidelines:
https://fedoraproject.org/wiki/Packaging:Perl#Filtering_Requires:_and_Provides

There were two changes:
1) Highlight that using Packaging:AutoProvidesAndRequiresFiltering is a must
and packages that are doing filtering in other ways should be migrated to
using the filtering described there.
2) Perl packages can use the %{?perl_default_filter} macro.

When rpm gains the ability to ignore the perl extensions and docdir the
ability exists to unset that macro and all should be well.

= Updated java guidelines =
https://fedorahosted.org/fpc/ticket/13
6 +1, no 0, no -1.

The java guidelines have seen some minor updates proposed by a member of the
java sig.  Most of it was clarification and fixes to the example spec
templates.

In addition to the guidelines accepted today, the following guidelines were
approved at a previous meeting and have now been written into the
guidelines:

= Bundled library exceptions =
https://fedorahosted.org/fpc/ticket/8

This update to the bundled libraries policy clarified when an exception
might be granted and listed packagelibrary combinations which have been
granted exceptions with rationale.

Note that this does not cover gupnp-dlna (pending a future meeting) or the
recent mozilla talks (unknown how we're going to deal with that).

-Toshio


pgp5aTsBVY8i0.pgp
Description: 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

[Bug 640752] New: Broken dependencies found with perl-Test-Simple-0.94-2.fc14

[bugzilla]

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

Summary: Broken dependencies found with perl-Test-Simple-0.94-2.fc14

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

   Summary: Broken dependencies found with
perl-Test-Simple-0.94-2.fc14
   Product: Fedora
   Version: 14
  Platform: All
OS/Version: Linux
Status: NEW
 Status Whiteboard: repoclosure_hash:2585e5f1e75c833fd80c9c9a0512da267b7d2
b68a0c6d7a5954aa3536db1a2e8
  Severity: medium
  Priority: medium
 Component: perl-Test-Simple
AssignedTo: cw...@alumni.drew.edu
ReportedBy: jla...@redhat.com
 QAContact: extras...@fedoraproject.org
CC: cw...@alumni.drew.edu,
fedora-perl-devel-l...@redhat.com
Classification: Fedora
Target Release: ---


ARRAY(0x7727830)

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Firewall settings unworkable

[Richard W.M. Jones]

Seems quite complex.  What's wrong with a directory:

  /etc/iptables.d/

where RPMs like libvirt just drop the required additional rules (in a
separate chain if you like) and restart the iptables service?  It's
low-tech but simple and it's all that libvirt needs.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: e4defrag support?

[Michał Piotrowski]

W dniu 6 października 2010 15:42 użytkownik Eric Sandeen
 napisał:
> Michał Piotrowski wrote:
>> W dniu 6 października 2010 05:01 użytkownik Eric Sandeen
>>  napisał:
>
> ...
>
>>> cool!  I suppose I could turn it on in rawhide, or you could just
>>> build your own e2fsprogs to get it ...
>>
>> I already built my own version.
>
> Ok, let me know if you can break anything! :)
>
> (Some of my concern, which is admittedly hand-wavy, is the
> kernelside design of the thing, but any outright breakage
> of the current implementation would be good to find as well)
>
> Some things to test would be attempting to defrag files
> which are being actively written to / read from in various
> ways - concurrent access, mmap, etc

I want to start with basic scenario:
- mad file/directory/link creation/delete/move - something like fsrace/fsfuzzer
- create file checksums
- defrag file/dir/image
- verify checksums

>.  Also possibly testing large
> and/or sparse files, files with extended attributes, testing
> enospc conditions 
>
> If you find a way to break it we can enshrine it as a regression
> test in the testsuite.

I plan to log all actions taken by the script - something like a
"reply" option :)

I do not know if it will work but worth a try

>
> Thanks!
>
> -Eric

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

Re: e4defrag support?

[Eric Sandeen]

Clyde E. Kunkel wrote:
> On 10/06/2010 02:01 PM, Eric Sandeen wrote:
>> 
>> OK gang, it's in e2fsprogs-1.41.12-6.fc15
>>
>> you have to invoke it with "-test" options to make it go ;)
>>
>> Word of warning, it's not had a lot of attention, and the whole
>> design could change in the future, but it's something to play with :)
>>
>> -Eric
> 
> Docs with it?  In man pages?

yep :)

/usr/sbin/e4defrag
/usr/share/man/man8/e4defrag.8.gz

-Eric

> Thanks!!

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

Re: e4defrag support?

[Clyde E. Kunkel]

On 10/06/2010 02:01 PM, Eric Sandeen wrote:
>
> OK gang, it's in e2fsprogs-1.41.12-6.fc15
>
> you have to invoke it with "-test" options to make it go ;)
>
> Word of warning, it's not had a lot of attention, and the whole
> design could change in the future, but it's something to play with :)
>
> -Eric

Docs with it?  In man pages?

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

Re: e4defrag support?

[Eric Sandeen]

Frank Murphy wrote:
> On 06/10/10 16:31, Eric Sandeen wrote:
>>
>> Maybe I'm being a bit too paranoid but it is your data after all :)
>>
> 
> I just use Rawhide for testing,
> so a little reinstall keeps you in practice :D
> 

OK gang, it's in e2fsprogs-1.41.12-6.fc15

you have to invoke it with "-test" options to make it go ;)

Word of warning, it's not had a lot of attention, and the whole
design could change in the future, but it's something to play with :)

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

Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]

[Andre Robatino]

Adam Williamson  redhat.com> writes:

> It's really pretty simple: we can only define goals and values and
> blahblah for 'the Fedora project' as long as we actually retain control
> over 'the Fedora project' (that's we as in the Fedora community, not Red
> Hat, BTW) and we can only do that if we control the name 'Fedora'. If
> anyone can make anything and call it 'Fedora', how are people to know
> what comes from the Fedora project and is backed by its values, and what
> doesn't?

Well, I suppose digital signatures would make this possible - but given that
most people don't know how to use them, and the availability of an infinite
number of free names to choose from, I think trademark restrictions are
reasonable.





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

Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]

[Bruno Wolff III]

On Wed, Oct 06, 2010 at 12:25:27 -0500,
  Chris Adams  wrote:
> Once upon a time, Bruno Wolff III  said:
> > Some have
> > also hoped that Mozilla would change with regard to bundled libraries in the
> > near future, but that seems pretty unlikely.
> 
> I think that's an unfair statement; from what I understand, Firefox has
> already unbundled some libraries, and said they will unbundle others
> once their changes settle down.

I guess that depends on what one means by near and unbundled libraries.
I got the impression that the vpx stuff was months away from being
unbundled. And there is no apparent commitment not to bundle new libraries
going forward. So that there will need to be an ongoing exception to cover
any new libraries that get used by Firefox. It does seem that specific
libraries do end up getting unbundled in most cases eventually. However
at least one library is likely to be a long term fork because Mozilla
and upstream disagree on the feature added to the Mozilla version of
the library.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 557485] Extra provides need trimming

[bugzilla]

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


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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA

--- Comment #4 from Fedora Update System  2010-10-06 
13:33:47 EDT ---
perl-SOAP-Lite-0.710.07-3.el5 has been pushed to the Fedora EPEL 5 testing
repository.  If problems still persist, please make note of it in this bug
report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update perl-SOAP-Lite'.  You can
provide feedback for this update here:
https://admin.fedoraproject.org/updates/perl-SOAP-Lite-0.710.07-3.el5

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-CatalystX-Component-Traits/f14/master] update to 0.16

[Iain Arnell]

Summary of changes:

  c7aa7fc... update to 0.16 (*)

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

Re: Review request: Nice-to-have bug process documentation proposal

[Adam Williamson]

On Thu, 2010-09-23 at 12:58 +0100, Adam Williamson wrote:
> Hi, everyone. So we partly used the proposed new nice-to-have bug
> tracking system during the F14 Beta process, and it seemed to go well.
> In a quick burst of airport productivity, I've quickly written up a
> bunch of proposed new wiki pages and modifications to existing ones to
> document the nice-to-have process (and, incidentally, extend
> documentation of the blocker process, since we don't seem to have much
> of it beyond the blocker meeting SOP right now). All the pages can be
> found here:
> 
> https://fedoraproject.org/wiki/Category:NTH_adjustment_drafts

Thanks to James for his feedback on this. I haven't had much feedback
from anyone else. However, given that in practice everyone involved in
the release review process has been happy using the NTH system drafted
here so far, I intend to make the draft changes final (with
modifications to reflect James' feedback) by the end of the week, so if
you have any feedback you've been sitting on, now would be the perfect
time to send it :) Thanks everyone!
-- 
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: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]

[Chris Adams]

Once upon a time, Bruno Wolff III  said:
> Some have
> also hoped that Mozilla would change with regard to bundled libraries in the
> near future, but that seems pretty unlikely.

I think that's an unfair statement; from what I understand, Firefox has
already unbundled some libraries, and said they will unbundle others
once their changes settle down.

-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Making Fedora work with laptops on docking station with external monitor

[Nathaniel McCallum]

On 10/06/2010 01:17 PM, Till Maas wrote:
> On Wed, Oct 06, 2010 at 12:54:41PM -0400, Nathaniel McCallum wrote:
> 
>> I'm pretty sure docking stations are irrelevant to this whole thread.
>> The issue is about lids and video outputs.  If you think lids are all
>> over the place (as mjg59 points out), docks are even worse.  Lets not
>> drag them into the conversation if they don't need to be.
> 
> I have to use docking stations, therefore they are not irrelevant for
> me. And I only encountered problems in use-cases involving docking
> stations, but I never had any problem with my other Thinkpad and the
> lid. Therefore I am all for making Fedora not suck by default when I use
> a docking station. And even more I am interested in what is happening
> with all the frameworks, e.g. u\* or whatever is acting on changes.
> One interesting questions is, what do I have to do to get no change in
> the screen setup if I move from one docking station to another.

I'm with you.  I use docking stations too. However, for the topic of why
doesn't Fedora show on my monitor when the lid is closed in my docking
station, the docking station is actually irrelevant.  Its just a video
output.

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

Re: Summary/Minutes for today's FESCo meeting (2010-10-05)

[Harald Hoyer]

On 10/06/2010 05:59 PM, Bill Nottingham wrote:
> Matthew Garrett (mj...@srcf.ucam.org) said:
>>> But I cannot list all the RHEL6 bugs.
>>
>> Why not? Strip partner names if necessary, but please make it possible
>> for people to decide whether a given update is a benefit to them.
>
> Well, he could list them in the bug field, but bodhi would elide
> them in the updates advisory. He could do double duty and list
> them all in the changelog, but that's getting a bit extreme when
> it comes to 100 patches.
>
> Bill

here we go:

https://admin.fedoraproject.org/updates/dracut-005-5.fc13
https://admin.fedoraproject.org/updates/dracut-005-5.fc12

Patches are here:

short URL: http://goo.gl/23Bu

http://pkgs.fedoraproject.org/gitweb/?p=dracut.git;a=tree;h=refs/heads/f13/master;hb=f13/master

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

Re: Making Fedora work with laptops on docking station with external monitor

[Till Maas]

On Wed, Oct 06, 2010 at 12:54:41PM -0400, Nathaniel McCallum wrote:

> I'm pretty sure docking stations are irrelevant to this whole thread.
> The issue is about lids and video outputs.  If you think lids are all
> over the place (as mjg59 points out), docks are even worse.  Lets not
> drag them into the conversation if they don't need to be.

I have to use docking stations, therefore they are not irrelevant for
me. And I only encountered problems in use-cases involving docking
stations, but I never had any problem with my other Thinkpad and the
lid. Therefore I am all for making Fedora not suck by default when I use
a docking station. And even more I am interested in what is happening
with all the frameworks, e.g. u\* or whatever is acting on changes.
One interesting questions is, what do I have to do to get no change in
the screen setup if I move from one docking station to another.

Regards
Till


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

Re: Making Fedora work with laptops on docking station with external monitor

[Nathaniel McCallum]

On 10/06/2010 12:50 PM, Till Maas wrote:
> On Tue, Oct 05, 2010 at 11:22:44AM +0100, Richard Hughes wrote:
> 
>> Well, I guess some people would want the laptop to suspend, but it's a
>> very good question. Now all it needs is someone willing and able to
>> write a little patch for me :-)
> 
> Do you know which components need patching to make Fedora work
> flawlessly with docking stations? I noticed problems, too, but even
> bigger problems to find out how the information flows e.g. if a notebook
> is inserted or ejected from a docking station. On thinkpads it seems not
> generate some event that cycles through the output configurations.

I'm pretty sure docking stations are irrelevant to this whole thread.
The issue is about lids and video outputs.  If you think lids are all
over the place (as mjg59 points out), docks are even worse.  Lets not
drag them into the conversation if they don't need to be.

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

Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]

[Nathaniel McCallum]

On 10/06/2010 12:41 PM, Bruno Wolff III wrote:
> On Wed, Oct 06, 2010 at 12:29:59 -0400,
>   Nathaniel McCallum  wrote:
>>
>> The only possible room for debate that I see is that there is, in
>> Firefox, a potential conflict between our "ship upstream" and "don't
>> bundle libs" values.  We have FESco to sort that out.
> 
> Those are the policies I was refering to.
> 
>> In short: No big deal. Close the thread. Move on. ;)
> 
> Well the project doesn't seem to be coming to consensus on this issue.
> Some of us feel that we should provide an Iceweasel or drop Firefox,
> similar to other things the project has decided to not package. Others think
> that Firefox is so important to the project, that we must make an exception
> for it. (And to some extent, that we should stay close to upstream.) Some have
> also hoped that Mozilla would change with regard to bundled libraries in the
> near future, but that seems pretty unlikely.
> 
> I don't think this is just a FESCO issue. I really think this is a board
> issue as it has to do with the relative importance of our bundled libraries
> policy, our stay close to upstream policies, the impact on our user base
> of replaceing Firefox with an unbranded version or just dropping it and
> the morale of various developers if we give or don't give Firefox an
> exemption to the no bundled libraries policies.
> 
> For example it may be that we can't do an Iceweasel, because the current
> packagers of Firefox may refuse to do that as an alterative to packaging
> Firefox and we may not find new volunteers to do the packaging work.

Yup.  I don't have a dog in this fight, so to speak.  Just as long as we
agree that Mozilla's policy and Fedora's policy are roughly the same and
that this policy is sensible.  Whether Mozilla's refusal to accept
patches is sensible is another matter...

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

Re: Making Fedora work with laptops on docking station with external monitor

[Till Maas]

On Tue, Oct 05, 2010 at 11:22:44AM +0100, Richard Hughes wrote:

> Well, I guess some people would want the laptop to suspend, but it's a
> very good question. Now all it needs is someone willing and able to
> write a little patch for me :-)

Do you know which components need patching to make Fedora work
flawlessly with docking stations? I noticed problems, too, but even
bigger problems to find out how the information flows e.g. if a notebook
is inserted or ejected from a docking station. On thinkpads it seems not
generate some event that cycles through the output configurations.

Regards
Till


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

Re: Making Fedora work with laptops on docking station with external monitor

[Orion Poplawski]

On 10/05/2010 09:48 AM, Orion Poplawski wrote:
> On 10/05/2010 02:35 AM, Richard Hughes wrote:
>> On 5 October 2010 05:30, Orion Poplawski   wrote:
>>> Are we really stuck with gdm/kdm/lxdm/...dm
>>> implementing it?
>>
>> No, I think what we need to do is to teach GPM how to turn off the
>> internal panel when docked and with the lid closed. The only missing
>> piece is for the kernel to export some kind of sysfs boolean saying
>> "in-dock". From talks with mjg59, detecting a dock is pretty hard.
>>
>> Richard.
>
> By GPM I'm guessing you mean gnome-power-manager?  So each desktop environment
> needs to implement this?  Does gpm run before login so that it is configured
> properly at login time?  Who's needs handle it for KDE, LXDE, XFCE, etc.?
>
>

I still don't feel like there has been adequate discussion on where in 
userspace this needs to be handled.  So far all I've seen is what appears to 
be a GNOME only solution.  I'll CC the KDE list to at least get another 
perspective in here.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]

[Bruno Wolff III]

On Wed, Oct 06, 2010 at 12:29:59 -0400,
  Nathaniel McCallum  wrote:
> 
> The only possible room for debate that I see is that there is, in
> Firefox, a potential conflict between our "ship upstream" and "don't
> bundle libs" values.  We have FESco to sort that out.

Those are the policies I was refering to.

> In short: No big deal. Close the thread. Move on. ;)

Well the project doesn't seem to be coming to consensus on this issue.
Some of us feel that we should provide an Iceweasel or drop Firefox,
similar to other things the project has decided to not package. Others think
that Firefox is so important to the project, that we must make an exception
for it. (And to some extent, that we should stay close to upstream.) Some have
also hoped that Mozilla would change with regard to bundled libraries in the
near future, but that seems pretty unlikely.

I don't think this is just a FESCO issue. I really think this is a board
issue as it has to do with the relative importance of our bundled libraries
policy, our stay close to upstream policies, the impact on our user base
of replaceing Firefox with an unbranded version or just dropping it and
the morale of various developers if we give or don't give Firefox an
exemption to the no bundled libraries policies.

For example it may be that we can't do an Iceweasel, because the current
packagers of Firefox may refuse to do that as an alterative to packaging
Firefox and we may not find new volunteers to do the packaging work.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]

[Nathaniel McCallum]

On 10/06/2010 12:12 PM, Bruno Wolff III wrote:
> On Wed, Oct 06, 2010 at 10:59:08 -0400,
>   Nathaniel McCallum  wrote:
>>
>> I have an idea... I'm going to create a fork of Fedora.  I'm going to
>> fill it full of proprietary shit.  I'm going to find the buggiest closed
>> drivers I can find and load them into the kernel.  I'll also make it so
>> that you have to type in your credit card number just to login.  I'll
>> register a fedora derivative domain name and SEO the hell out of it.
>> Then, I'll tell people my distro is called Fedora Ultimate Edition.
>> Everyone will believe me because I'll leave all the Fedora artwork in
>> place.  I'll also publish is under the pseudonym of Ralf Corsepius: Ralf
>> Corsepius' Fedora Ultimate Edition.
> 
> The Fedora project goes pretty far in making it easy to produce an unbranded
> version of Fedora for people that want to do that. The trademark protected
> stuff is supposed to be in just a few packages that have alternative packages
> in the distro already, that can replace them. I think that makes a point
> that Fedora isn't trying to abuse trademarks to keep supposedly open source
> closed.
> 
> I don't think Mozilla is trying to abuse their trademarks either (though
> there have been open source projects that have). I don't think they go as
> far as fedora in making it easy to make a rebranded application, but they
> certainly don't make it very difficult either as there is an Iceweasel
> out there.
> 
> The issue seems to be that Mozilla's policies for their brand conflict
> with Fedora's policies for their brand and that Fedora has limited
> resources. I don't think anyone is being evil here. There are reasonable
> positions on both sides of the argument.

Agreed, I'm just trying to point out the absurdity of saying that "any
restriction on trademark impedes the freedoms of the GPL (etc...)."  My
point is that it is precisely the limitations that guarantee those freedoms.

I don't see any conflict between Fedora's policy and Mozilla's policy.
Both say that if you redistribute and change code you have to
re-trademark.  Those policies are fair and sensible.  We can either
patch and re-trademark Firefox or ship upstream.  One of the values of
Fedora is stay close to upstream.  Another value is the Firefox brand.
This is a no-brainer choice for Fedora: ship upstream Firefox.  I really
can't believe this thread is as long as it is.

The only possible room for debate that I see is that there is, in
Firefox, a potential conflict between our "ship upstream" and "don't
bundle libs" values.  We have FESco to sort that out.

In short: No big deal. Close the thread. Move on. ;)

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

Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]

[Bruno Wolff III]

On Wed, Oct 06, 2010 at 10:59:08 -0400,
  Nathaniel McCallum  wrote:
> 
> I have an idea... I'm going to create a fork of Fedora.  I'm going to
> fill it full of proprietary shit.  I'm going to find the buggiest closed
> drivers I can find and load them into the kernel.  I'll also make it so
> that you have to type in your credit card number just to login.  I'll
> register a fedora derivative domain name and SEO the hell out of it.
> Then, I'll tell people my distro is called Fedora Ultimate Edition.
> Everyone will believe me because I'll leave all the Fedora artwork in
> place.  I'll also publish is under the pseudonym of Ralf Corsepius: Ralf
> Corsepius' Fedora Ultimate Edition.

The Fedora project goes pretty far in making it easy to produce an unbranded
version of Fedora for people that want to do that. The trademark protected
stuff is supposed to be in just a few packages that have alternative packages
in the distro already, that can replace them. I think that makes a point
that Fedora isn't trying to abuse trademarks to keep supposedly open source
closed.

I don't think Mozilla is trying to abuse their trademarks either (though
there have been open source projects that have). I don't think they go as
far as fedora in making it easy to make a rebranded application, but they
certainly don't make it very difficult either as there is an Iceweasel
out there.

The issue seems to be that Mozilla's policies for their brand conflict
with Fedora's policies for their brand and that Fedora has limited
resources. I don't think anyone is being evil here. There are reasonable
positions on both sides of the argument.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Summary/Minutes for today's FESCo meeting (2010-10-05)

[Bill Nottingham]

Matthew Garrett (mj...@srcf.ucam.org) said: 
> > But I cannot list all the RHEL6 bugs.
> 
> Why not? Strip partner names if necessary, but please make it possible 
> for people to decide whether a given update is a benefit to them.

Well, he could list them in the bug field, but bodhi would elide
them in the updates advisory. He could do double duty and list
them all in the changelog, but that's getting a bit extreme when 
it comes to 100 patches.

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

Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]

[Adam Williamson]

On Wed, 2010-10-06 at 16:41 +0200, Ralf Corsepius wrote:

> However, this here is Fedora, a project that once was aiming at 
> "Freedom" - As trivial as it is, restrictive trademark policies simply 
> do not fit into this philosophy.

If we don't protect the Fedora trademark, anyone can produce anything
and call it 'Fedora'. Including something which doesn't fit into our
philosophy of freedom at all.

It's really pretty simple: we can only define goals and values and
blahblah for 'the Fedora project' as long as we actually retain control
over 'the Fedora project' (that's we as in the Fedora community, not Red
Hat, BTW) and we can only do that if we control the name 'Fedora'. If
anyone can make anything and call it 'Fedora', how are people to know
what comes from the Fedora project and is backed by its values, and what
doesn't?
-- 
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: e4defrag support?

[Frank Murphy]

On 06/10/10 16:31, Eric Sandeen wrote:
>
>
> Maybe I'm being a bit too paranoid but it is your data after all :)
>

I just use Rawhide for testing,
so a little reinstall keeps you in practice :D

-- 
Regards,

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

Re: e4defrag support?

[Frank Murphy]

On 06/10/10 16:29, Clyde E. Kunkel wrote:

> Cool if you turn it on in rawhide.  Helps those of us who are build
> challenged :-).  I can test in raid and LV environments.
>
> Regards,
> OldFart

Likewise, if basic instruction provided.

-- 
Regards,

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

Re: e4defrag support?

[Eric Sandeen]

Clyde E. Kunkel wrote:
> On 10/05/2010 11:01 PM, Eric Sandeen wrote:
>> 
>> cool!  I suppose I could turn it on in rawhide, or you could just
>> build your own e2fsprogs to get it ...
>>
>> -Eric
>>
> 
> 
> Cool if you turn it on in rawhide.  Helps those of us who are build 
> challenged :-).  I can test in raid and LV environments.

ok... now, everyone promise not to cry if it does something bad
to your rawhide box!  ;)
 
I'll turn it on today... hm I might rename it e4defrag_test for now,
just to make it a little more obvious.

Maybe I'm being a bit too paranoid but it is your data after all :)

-Eric

> Regards,
> OldFart

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

Re: e4defrag support?

[Clyde E. Kunkel]

On 10/05/2010 11:01 PM, Eric Sandeen wrote:
> 
> cool!  I suppose I could turn it on in rawhide, or you could just
> build your own e2fsprogs to get it ...
>
> -Eric
>


Cool if you turn it on in rawhide.  Helps those of us who are build 
challenged :-).  I can test in raid and LV environments.

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

Re: Firewall settings unworkable

[Thomas Woerner]

I am currently working on a proof of concept implementation of a 
firewall daemon, that will support dynamic firewall management with a 
D-BUS interface.

This implementation should be usable in some days and will feature the 
transition of the current firewall model to the dynamic version. It will 
provide the majority of features system-config-firewall has at the 
moment (services, ports, trusted, forward, icmp and masquerading), but 
will be limited to a command line client with D-BUS interface.

Here is more information on planned and proposed features:


Firewall Concepts - PROPOSAL


1) Firewall daemon

The current firewall services are static and can not handle dynamic 
firewall changes. Also system, user and administrator preferences can 
not be incorporated easily. The separation of IPv4 and IPv6 firewall 
services makes all this even worse.

The solution is to create a firewall service with a daemon, which is 
taking care of the firewall similar to NetworkManager that does this for 
network connections. The firewall daemon provides information about the 
current active firewall settings via D-BUS and also accepts firewall 
changes via D-BUS by using policykit authentication methods.

The firewall daemon is acting as a single authority for firewall 
creation and management. Controlling and maintaining the firewall if 
there are several applications or daemons changing firewall rules and 
behavior independently will most likely make it impossible to have a 
sane firewall state.

Support for additional firewall features like ebtables is needed to be 
able to support desktop and virtualizsation requirements.

2) Dynamic firewall

The current static model does not allow to add or remove rules and to 
load or unload netfilter firewall helpers easily. Restarting the 
firewall completely is required. Also the order of rules is very 
important and the usage of the predefined INPUT and FORWARD rules chains 
only is not helping to solve this.

The chains need to be separated. For example chains for services and 
ports, masquerading, port forwarding, icmp filtering and virtualization 
and custom rules. This makes it much more flexible, safe and robust. 
Adding a rule with the firewall daemon to one of these chains will most 
likely not interefere with rules of other chains. The order of the 
chains and how they are used is fixed and will not change.

For the netfilter firewall helpers it is not that easy. Helpers are for 
example used for amanda, ftp, samba and tftp services. If one of these 
services gets disabled, then the helper has to get unloaded from the 
kernel. For some of the helpers this is only possible after all 
connections that are handled by the module are closed. Therefore 
connection tracking information is important here and needs to get into 
account. Adding support for conntrack connection handling is therefore 
needed here.

It is possible to specify a timeout for a firewall service and also the 
other features. The service will be opened immediately and closed again 
after the defined period is over. This allows to accept new connections 
from unknown sources in the specified time frame. This will be very 
useful for UPNP, SNMP or NetBIOS for example to find printers or to 
share data with others. This mechanism is similar to the bluetooth 
handler in cell phones.

3) Network zones: Network security model

The network security model specifies the default trust level of all 
connections and can be selected initially at installation time, 
firstboot or when the first network connection gets established. The 
model describes the trust level of the whole network environment, the 
host is connected to and also defines what to do with new connections.

There are different initial models:

   - Home / Work
   - Public
   - Connection specific

The home or work zone has the highest trust level. All incoming 
connections are allowed. The public zone on the other hand is fully 
untrusted. No incoming connection is allowed. The connection specific 
model requires that the user tunes the trust level of a connection 
according to the needs. The default is untrusted.

The user or administrator is able to define new zones or adapt initial 
zones to change the behaviour according to their needs. Network 
connections can be bound to zones. The network security model makes it 
possible to have one trust level for all connections or to have several 
connections with different trust levels. The firewall has support for 
these zones and makes it possible that the user or admin can enable 
firewall features for zones.

If a new or undefined network connection is enabled in NetworkManager, 
the firewall daemon gets informed about this via D-BUS and can set 
firewall rules accordingly. There are chains for all supported network zones

4) Port metadata information (proposed by Lennart Poettering)

To have a port independent metadata information would be good to have. 
The current mod

Re: e4defrag support?

[Chris Adams]

Once upon a time, Eric Sandeen  said:
> Some things to test would be attempting to defrag files
> which are being actively written to / read from in various
> ways - concurrent access, mmap, etc.

Also make sure to test files used by sendfile() and splice()/vmsplice().

-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]

[Nathaniel McCallum]

On 10/06/2010 10:41 AM, Ralf Corsepius wrote:
> On 10/06/2010 04:08 PM, Michal Schmidt wrote:
>> On Wed, 06 Oct 2010 15:26:59 +0200 Ralf Corsepius wrote:
>>> On 10/06/2010 02:49 PM, Matej Cepl wrote:
 Nonsense, trademarks exists to protect users and to avoid living off
 somebody else brand recognition.
>>>
>>> I disagree - trademarks exist to protect the manufacturer from
>>> loosing profits because of their products being copied.
>>>
>>> Ask Adidas or Nike why they sue Chinese manufacturers and you'll see.
>>> They'll tell you that they loose money because of being copied.
>>
>> Of course. But there's in fact no disagreement, only looking at
>> different aspects of the same thing.
>>
>> Why do you think the copying takes place? Because the companies have
>> built a good reputation and brand, allowing them to increase profit.
>>
>> Good quality =>  good reputation =>  solid brand =>  better profits.
> 
> I am not disagreeing that restrictive trademarks, patents, restricive 
> license etc. all make sense in the commerical world.
> 
> However, this here is Fedora, a project that once was aiming at 
> "Freedom" - As trivial as it is, restrictive trademark policies simply 
> do not fit into this philosophy.
> 
>> Then copyists try to get better profits too without bothering to
>> build their own good reputation, by deceiving the buyers into thinking
>> the original company with good reputation produced their goods.
>>
>>
>> I'm really quite surprised about this thread. Of all the stuff
>> often put under the confusing term "intellectual property" I expected
>> trademarks to be the least controversial.
> Well, my view differs:
> To me, restrictive trademarks are in the same league as patents and 
> closed source.
> Last century's, commercial world's instruments of protectionism which 
> contradict the philosophy behind FLOSS. It's just thanks to the fact 
> "restrictive prosecution of trademarks" are rare in the FLOSS world, 
> which has caused it to get away more or less unattended.

I have an idea... I'm going to create a fork of Fedora.  I'm going to
fill it full of proprietary shit.  I'm going to find the buggiest closed
drivers I can find and load them into the kernel.  I'll also make it so
that you have to type in your credit card number just to login.  I'll
register a fedora derivative domain name and SEO the hell out of it.
Then, I'll tell people my distro is called Fedora Ultimate Edition.
Everyone will believe me because I'll leave all the Fedora artwork in
place.  I'll also publish is under the pseudonym of Ralf Corsepius: Ralf
Corsepius' Fedora Ultimate Edition.

Doing this harms real people and a real organization.  The "freedom" to
do this is not freedom at all but lunacy.  Its quite simple.  You're
free use my work however you like, even for evil.  But you are not
allowed to claim you are me.  Fedora and Mozilla go way beyond this.
They give you the FREEDOM to call yourself Fedora and/or Mozilla so long
as the work actually represents them. That is where the freedom is
found: freedom with conditions.  Just like every single Free/Open
license: freedom with conditions.  The default state of copyright is
that you have few freedoms.  Copyleft works by granting you additional
freedoms so long as your exercise of those freedoms don't damage anyone
else's use of those freedoms.  The trademark grants of Fedora and
Mozilla work the same way: you can use the trademark so long as your use
of the trademark doesn't impede on anyone else's use of the trademark
(including the original author).  Thus, your argument actually undoes
the entire power of the GPL.

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

Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]

[Tomas Mraz]

On Wed, 2010-10-06 at 16:41 +0200, Ralf Corsepius wrote: 
> On 10/06/2010 04:08 PM, Michal Schmidt wrote:
> > On Wed, 06 Oct 2010 15:26:59 +0200 Ralf Corsepius wrote:
> >> On 10/06/2010 02:49 PM, Matej Cepl wrote:
> >>> Nonsense, trademarks exists to protect users and to avoid living off
> >>> somebody else brand recognition.
> >>
> >> I disagree - trademarks exist to protect the manufacturer from
> >> loosing profits because of their products being copied.
> >>
> >> Ask Adidas or Nike why they sue Chinese manufacturers and you'll see.
> >> They'll tell you that they loose money because of being copied.
> >
> > Of course. But there's in fact no disagreement, only looking at
> > different aspects of the same thing.
> >
> > Why do you think the copying takes place? Because the companies have
> > built a good reputation and brand, allowing them to increase profit.
> >
> > Good quality =>  good reputation =>  solid brand =>  better profits.
> 
> I am not disagreeing that restrictive trademarks, patents, restricive 
> license etc. all make sense in the commerical world.
> 
> However, this here is Fedora, a project that once was aiming at 
> "Freedom" - As trivial as it is, restrictive trademark policies simply 
> do not fit into this philosophy.
I give +1 to this. On the other hand Fedora also is (was?) a project
where individual package maintainers had the biggest influence on what
packages ship if they do not cross some fundamental legal limits. This
changed in many ways recently and the restrictions and requirements are
more and more technical, not just legal, and even controversial. The
problem here really is that some "not so important?" projects are forced
to accept all the restrictions and requirements and other "more
important?" projects get a free pass from them. This is unfortunate and
it does not improve the spirit of the package maintainers.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

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

Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]

[Ralf Corsepius]

On 10/06/2010 04:08 PM, Michal Schmidt wrote:
> On Wed, 06 Oct 2010 15:26:59 +0200 Ralf Corsepius wrote:
>> On 10/06/2010 02:49 PM, Matej Cepl wrote:
>>> Nonsense, trademarks exists to protect users and to avoid living off
>>> somebody else brand recognition.
>>
>> I disagree - trademarks exist to protect the manufacturer from
>> loosing profits because of their products being copied.
>>
>> Ask Adidas or Nike why they sue Chinese manufacturers and you'll see.
>> They'll tell you that they loose money because of being copied.
>
> Of course. But there's in fact no disagreement, only looking at
> different aspects of the same thing.
>
> Why do you think the copying takes place? Because the companies have
> built a good reputation and brand, allowing them to increase profit.
>
> Good quality =>  good reputation =>  solid brand =>  better profits.

I am not disagreeing that restrictive trademarks, patents, restricive 
license etc. all make sense in the commerical world.

However, this here is Fedora, a project that once was aiming at 
"Freedom" - As trivial as it is, restrictive trademark policies simply 
do not fit into this philosophy.

> Then copyists try to get better profits too without bothering to
> build their own good reputation, by deceiving the buyers into thinking
> the original company with good reputation produced their goods.
>
>
> I'm really quite surprised about this thread. Of all the stuff
> often put under the confusing term "intellectual property" I expected
> trademarks to be the least controversial.
Well, my view differs:
To me, restrictive trademarks are in the same league as patents and 
closed source.
Last century's, commercial world's instruments of protectionism which 
contradict the philosophy behind FLOSS. It's just thanks to the fact 
"restrictive prosecution of trademarks" are rare in the FLOSS world, 
which has caused it to get away more or less unattended.

Ralf


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

Re: xulrunner 2.0 in rawhide (F15) bundles several system libs

[Peter Jones]

On 10/06/2010 10:08 AM, Brandon Lozza wrote:
> On 10/6/10, Matej Cepl  wrote:
>> I won't comment on the trademark issue (because that's just pure lunacy),
>> but let me comment here "they don't accept my patches, so they are non-
>> free". That's just nonsense ...
> 
> Yes it is, that's not the issue. They aren't letting us distribute it
> ourselves, unless its brand is removed or we don't make those changes.

On the contrary, distribution is the thing they *are* allowing.

-- 
Peter

First things first -- but not necessarily in that order.
-- The Doctor

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

Re: xulrunner 2.0 in rawhide (F15) bundles several system libs

[Emmanuel Seyman]

* Brandon Lozza [06/10/2010 16:28] :
>
> Yes it is, that's not the issue. They aren't letting us distribute it
> ourselves, unless its brand is removed or we don't make those changes.

It's their brand, they get to decide what they do (or let you do) with it.

Emmanuel

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

Any comments about the latest version of mono on my site?

[Paul F. Johnson]

Hi,

A couple of days back I uploaded preview 8 of mono-2.8 for comments but
have heard nothing back. The move to 2.8 will require a good number of
rebuilds as 2.8 has had all the .NET 1.1 stuff removed.

If you have a mono reliant package, can you please rebuild and let me
know if there are any problems. If I submit to rawhide now there will be
a tonne of breakages and I'd rather avoid that if possible.

URLS

http://www.all-the-johnsons.co.uk/mono/libgdiplus-2.8-1.fc15.src.rpm and
http://www.all-the-johnsons.co.uk/mono/mono-2.8-1.fc15.src.rpm

Paul
-- 
Vertraue mir, ich weiss, was ich mache...

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

trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]

[Michal Schmidt]

On Wed, 06 Oct 2010 15:26:59 +0200 Ralf Corsepius wrote:
> On 10/06/2010 02:49 PM, Matej Cepl wrote:
> > Nonsense, trademarks exists to protect users and to avoid living off
> > somebody else brand recognition.
> 
> I disagree - trademarks exist to protect the manufacturer from
> loosing profits because of their products being copied.
> 
> Ask Adidas or Nike why they sue Chinese manufacturers and you'll see.
> They'll tell you that they loose money because of being copied.

Of course. But there's in fact no disagreement, only looking at
different aspects of the same thing.

Why do you think the copying takes place? Because the companies have
built a good reputation and brand, allowing them to increase profit.

Good quality => good reputation => solid brand => better profits.

Then copyists try to get better profits too without bothering to
build their own good reputation, by deceiving the buyers into thinking
the original company with good reputation produced their goods.


I'm really quite surprised about this thread. Of all the stuff
often put under the confusing term "intellectual property" I expected
trademarks to be the least controversial.

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

Re: xulrunner 2.0 in rawhide (F15) bundles several system libs

[Brandon Lozza]

On 10/6/10, Matej Cepl  wrote:
> I won't comment on the trademark issue (because that's just pure lunacy),
> but let me comment here "they don't accept my patches, so they are non-
> free". That's just nonsense ...

Yes it is, that's not the issue. They aren't letting us distribute it
ourselves, unless its brand is removed or we don't make those changes.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: e4defrag support?

[Eric Sandeen]

Michał Piotrowski wrote:
> W dniu 6 października 2010 05:01 użytkownik Eric Sandeen
>  napisał:

...

>> cool!  I suppose I could turn it on in rawhide, or you could just
>> build your own e2fsprogs to get it ...
> 
> I already built my own version.

Ok, let me know if you can break anything! :)

(Some of my concern, which is admittedly hand-wavy, is the
kernelside design of the thing, but any outright breakage
of the current implementation would be good to find as well)

Some things to test would be attempting to defrag files
which are being actively written to / read from in various
ways - concurrent access, mmap, etc.  Also possibly testing large
and/or sparse files, files with extended attributes, testing
enospc conditions 

If you find a way to break it we can enshrine it as a regression
test in the testsuite.

Thanks!

-Eric
 
>> -Eric
>>
> 
> Regards,
> Michal

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

Re: Summary/Minutes for today's FESCo meeting (2010-10-05)

[Bruno Wolff III]

On Wed, Oct 06, 2010 at 08:29:32 -0400,
  Brandon Lozza  wrote:
> 
> Interesting, from the meeting we can tell
> 
> 1) A number of people want to give Mozilla an exception.
> 
> 2) BRANDING is an issue, like I said in another thread. Which is why
> people are against removing it.

People have claimed that the Firefox brand helps Fedora. I'd like to see
some measurement of this. Especially in our target audience.

> 3) Maintainers for Mozilla aren't being expected to follow package
> guidelines, citing the use of system libs as a source of extra work.

Yes and no. There are suggestions that Mozilla does eventually intend
to use the upstream libraries once they are considered good enough
(except for maybe libpng because of the fork) and so the exception is
temporary per library.

> 4) People still seem to think that Iceweasel is somehow inferior to
> Firefox. Plus if Fedora removed the branding it wouldn't remove
> compatibility, source code, plugin support and wouldn't introduce
> so-called "sketchy" patches.

I don't think that just debranding Firefox would be all that much extra
work. Doing that would leave us positioned to do other changes when we
were ready and to be able to more quickly respond to security issues.
Replacing on of the library dependencies would be work and doing all of
those might not currently be sustainable. Also the maintainers of the
affected libraries in Fedora would need to help as there are patches in
Firefox for some libraries that aren't upstream.

There was also talk about whether or not it would be allowed for there
to be a separate Iceweasel package in Fedora. This might be done to
test the feasibility of maintaining it. There were mixed feelings about
this amoung FESCO.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: xulrunner 2.0 in rawhide (F15) bundles several system libs

[Ralf Corsepius]

On 10/06/2010 02:49 PM, Matej Cepl wrote:
> Ralf Corsepius, Tue, 05 Oct 2010 06:01:09 +0200:
>> Close source school of thinking - Trademarks exist to protect an
>> enterprise's product and to close out "copyiers". FLOSS exists to enable
>> people "to share".
>
> Nonsense, trademarks exists to protect users and to avoid living off
> somebody else brand recognition.

I disagree - trademarks exist to protect the manufacturer from loosing 
profits because of their products being copied.

Ask Adidas or Nike why they sue Chinese manufacturers and you'll see.
They'll tell you that they loose money because of being copied.

> Which is the only reason why plagiarized
> products are really bad. I would really prefer genuine Rhine Risling than
> some cheap junk which just sells much better under this name.
I drink Baden Riesling ... a Rhine Risling likely originates from 
somewhere else.


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

rawhide report: 20101006 changes

[Rawhide Report]

Compose started at Wed Oct  6 08:15:24 UTC 2010

Broken deps for x86_64
--
antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6
bluefish-2.0.2-1.fc15.1.x86_64 requires libgucharmap.so.7()(64bit)
clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) < 
0:1.3.0
clutter-gst-devel-1.2.0-1.fc15.x86_64 requires pkgconfig(clutter-1.0) < 
0:1.3.0
gambas2-gb-pdf-2.21.0-3.fc15.x86_64 requires libpoppler.so.7()(64bit)
gearmand-0.13-2.fc14.x86_64 requires libmemcached.so.5()(64bit)
gedit-plugins-2.31.6-1.fc15.x86_64 requires libgucharmap.so.7()(64bit)
gloobus-preview-0.4.1-7.fc14.x86_64 requires libpoppler.so.7()(64bit)
gloobus-preview-0.4.1-7.fc14.x86_64 requires 
libpoppler-glib.so.5()(64bit)
1:gnome-applets-2.32.0-1.fc15.x86_64 requires libgucharmap.so.7()(64bit)
1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
gnome-pilot-conduits-2.0.17-4.fc13.x86_64 requires 
libgpilotdconduit.so.2()(64bit)
gnome-pilot-conduits-2.0.17-4.fc13.x86_64 requires 
libgpilotd.so.2()(64bit)
gnome-pilot-conduits-2.0.17-4.fc13.x86_64 requires 
libgpilotdcm.so.2()(64bit)
gnome-python2-brasero-2.31.1-7.fc14.x86_64 requires 
libbrasero-burn.so.1()(64bit)
gnome-python2-brasero-2.31.1-7.fc14.x86_64 requires 
libbrasero-media.so.1()(64bit)
gnome-python2-evince-2.31.1-7.fc14.x86_64 requires 
libevdocument.so.3()(64bit)
gnome-python2-evince-2.31.1-7.fc14.x86_64 requires 
libevview.so.3()(64bit)
gnome-python2-totem-2.31.1-7.fc14.x86_64 requires 
libgnome-media-profiles.so.0()(64bit)
gpx-viewer-0.1.2-2.fc14.x86_64 requires 
libchamplain-gtk-0.4.so.0()(64bit)
gpx-viewer-0.1.2-2.fc14.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit)
gtranslator-1.9.11-3.fc14.x86_64 requires libgucharmap.so.7()(64bit)
gucharmap-devel-2.33.0-1.fc15.i686 requires gtk2-devel >= 0:2.91.0
gucharmap-devel-2.33.0-1.fc15.x86_64 requires gtk2-devel >= 0:2.91.0
hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit)
libextractor-plugins-pdf-0.6.2-1500.fc15.x86_64 requires 
libpoppler.so.7()(64bit)
moblin-panel-status-0.1.21-6.fc14.x86_64 requires 
libsocialweb-client.so.1()(64bit)
moblin-panel-status-0.1.21-6.fc14.x86_64 requires 
libchamplain-0.6.so.0()(64bit)
moblin-panel-status-0.1.21-6.fc14.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
opensips-memcached-1.6.3-2.fc15.x86_64 requires 
libmemcached.so.5()(64bit)
pdf2djvu-0.7.3-4.fc14.x86_64 requires libpoppler.so.7()(64bit)
php-pecl-memcached-1.0.2-1.fc14.x86_64 requires 
libmemcached.so.5()(64bit)
pypoppler-0.12.1-4.fc14.x86_64 requires libpoppler.so.7()(64bit)
pypoppler-0.12.1-4.fc14.x86_64 requires libpoppler-glib.so.5()(64bit)
qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit)
rakudo-0.0.2010.08_2.7.0-1.fc14.x86_64 requires 
libparrot.so.2.7.0()(64bit)
referencer-1.1.6-6.fc15.x86_64 requires libpoppler.so.7()(64bit)
referencer-1.1.6-6.fc15.x86_64 requires libpoppler-glib.so.5()(64bit)
spacewalk-certs-tools-1.1.1-2.1.fc15.noarch requires 
spacewalk-backend-libs >= 0:0.8.28
stardict-3.0.1-21.fc13.x86_64 requires libgucharmap.so.7()(64bit)
totem-2.90.5-5.fc15.i686 requires libpeasui-1.0.so.0
totem-2.90.5-5.fc15.x86_64 requires libpeasui-1.0.so.0()(64bit)
tracker-0.8.17-2.fc15.i686 requires libpoppler.so.7
tracker-0.8.17-2.fc15.i686 requires libpoppler-glib.so.5
tracker-0.8.17-2.fc15.x86_64 requires libpoppler-glib.so.5()(64bit)
tracker-0.8.17-2.fc15.x86_64 requires libpoppler.so.7()(64bit)
xournal-0.4.5-6.fc14.x86_64 requires libpoppler.so.7()(64bit)
xournal-0.4.5-6.fc14.x86_64 requires libpoppler-glib.so.5()(64bit)
zathura-0.0.8.1-6.fc15.x86_64 requires libpoppler.so.7()(64bit)
zathura-0.0.8.1-6.fc15.x86_64 requires libpoppler-glib.so.5()(64bit)



Broken deps for i386
--
antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6
bluefish-2.0.2-1.fc15.1.i686 requires libgucharmap.so.7
clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) < 
0:1.3.0
gambas2-gb-pdf-2.21.0-3.fc15.i686 requires libpoppler.so.7
gearmand-0.13-2.fc14.i686 requires libmemcached.so.5
gedit-plugins-2.31.6-1.fc15.i686 requires libgucharmap.so.7
gloobus-preview-0.4.1-7.fc14.i686 requires libpoppler-glib.so.5
gloobus-preview-0.4.1-7.fc14.i686 requires libpoppler.so.7
1:gnome-applets-2.32.0-1.fc15.i686 requires libgucharmap.so.7
1:gnome-games-extra-2.31.91.1-1.fc15.i686 requires 
libclut

Re: Summary/Minutes for today's FESCo meeting (2010-10-05)

[Matthew Garrett]

On Wed, Oct 06, 2010 at 02:46:28PM +0200, Harald Hoyer wrote:
> But I cannot list all the RHEL6 bugs.

Why not? Strip partner names if necessary, but please make it possible 
for people to decide whether a given update is a benefit to them.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: xulrunner 2.0 in rawhide (F15) bundles several system libs

[Matej Cepl]

Ralf Corsepius, Tue, 05 Oct 2010 06:01:09 +0200:
> Close source school of thinking - Trademarks exist to protect an
> enterprise's product and to close out "copyiers". FLOSS exists to enable
> people "to share".

Nonsense, trademarks exists to protect users and to avoid living off 
somebody else brand recognition. Which is the only reason why plagiarized 
products are really bad. I would really prefer genuine Rhine Risling than 
some cheap junk which just sells much better under this name.

Matěj
-- 
http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
 
The American Republic will endure, until politicians realize they
can bribe the people with their own money.
-- Alexis de Tocqueville


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

Re: Summary/Minutes for today's FESCo meeting (2010-10-05)

[Harald Hoyer]

On 10/05/2010 11:20 PM, Kevin Fenzi wrote:
> ===
> #fedora-meeting: FESCO (2010-10-05)
> ===
...
> 19:59:38  some examples: dracut was updated in f12/13 with a bunch of 
> patches. Were those all bugfixes?
> 19:59:59  if it's hard to tell, that means either a) we need to think 
> about how to make a generic exemplar of that case, or b) the packager needs 
> to be telling us more about the update
> 20:00:07  NetworkManager rebases to a git snapshot in all of 
> f12/f13/f14/rawhide at the same time.
> 20:00:19  And I think both of those are "b" there.
> 20:00:59  right, so more education...
> 20:01:12  Ideally we'd have some means of identifying this
> 20:01:14  (obviously, there could be more classes of things; feel 
> free to bring them up if they're of consequence)
> 20:01:28  But insisting that all changelog elements be flagged with a 
> bug just encourages people not to mention things in changelogs
> 20:01:46  yeah.
> 20:02:05  mjg59: If your changelog looks like this, it's "b" in my 
> list:
> 20:02:07  * Wed Sep 22 2010 Harald Hoyer  005-4 - 
> backported a lot of bugfixes from git
> 20:02:31  insisting that there's an actual changelog might be a 
> start? ;)


Well, I could list all bugs found in F12,F13,F14 in the changelog, which are 
also displayed in https://admin.fedoraproject.org/updates/dracut-005-4.fc13
But I cannot list all the RHEL6 bugs.

It's basically a new dracut version, but I tried only to cherry-pick the 
relevant patches of dracut upstream for the bugfixes + known bugs without 
bugzillas + patches needed for the cherry-picking.

It was a decision of:
- backport only the bugfixes + new code to adapt for the backporting (which 
might introduce new bugs)
or
- cherry-picking tested code, which fixes the bugs + tested patches needed for 
the cherry-picking

so I chose the latter and cherry-picked.


+Patch42: 0042-kernel-modules-add-more-hardcoded-modules.patch
+Patch43: 0043-dracut-functions-use-udevadm-to-get-ID_FS_.patch
+Patch44: 0044-dracut.conf-use-as-default-for-config-variables.patch
+Patch45: 0045-znet-use-ccw-init-and-ccw-rules-from-s390utils-in-dr.patch
+Patch46: 0046-znet-renamed-rd_CCW-to-rd_ZNET.patch
+Patch47: 0047-fcoe-add-sbin-vconfig-and-the-8021q-kernel-module.patch
+Patch48: 0048-dracut.8-fix-rd_LVM_LV-description.patch
+Patch49: 0049-plymouth-only-display-luksname-and-device-for-multip.patch
+Patch50: 0050-dracut.spec-remove-elfutils-libelf-requirement.patch
+Patch51: 0051-use-grep-directly-without-nm-to-drop-binutils-requir.patch
+Patch52: 0052-plymouth-plymouth-populate-initrd-get-rid-of-awk.patch
+Patch53: 0053-dracut-get-rid-of-the-file-command.patch
+Patch54: 0054-dracut.spec-clean-up-the-requirements.patch
+Patch55: 0055-90mdraid-dracut-functions-fix-md-raid-hostonly-detec.patch
+Patch56: 0056-40network-parse-ip-opts.sh-add-ip-auto6-to-valid-opt.patch
+Patch57: 0057-40network-dhclient-script-be-more-verbose.patch
+Patch58: 0058-40network-ifup-be-more-verbose.patch
+Patch59: 0059-TEST-50-MULTINIC-do-not-provide-a-cdrom-in-the-testc.patch
+Patch60: 0060-95fcoe-fcoe-up-wait_for_if_up.patch
+Patch61: 0061-get-rid-of-rdnetdebug.patch
+Patch62: 0062-95znet-removed-55-ccw.rules-and-ccw_init.patch
+Patch63: 0063-Makefile-make-more-clean.patch
+Patch64: 0064-selinux-loadpolicy.sh-exit-for-selinux-0.patch
+Patch65: 0065-dracut-functions-check-if-specific-dracut-module-is-.patch
+Patch66: 0066-multipath-simplify-and-install-wwids-rhbz-595719.patch
+Patch67: 0067-multipath-remove-multipath-udev-rules-if-no-multipat.patch
+Patch68: 0068-90crypt-crypto_LUKS-identifier-corrected.patch
+Patch69: 0069-selinux-move-selinux-to-a-separate-module.patch
+Patch70: 0070-plymouth-cryptroot-ask.sh-beautify-password-prompt.patch
+Patch71: 0071-network-depend-on-ifcfg-if-etc-sysconfig-network-scr.patch
+Patch72: 0072-network-strip-pxelinux-hardware-type-field-from-BOOT.patch
+Patch73: 0073-dracut.spec-moved-znet-to-dracut-network.patch
+Patch74: 0074-Write-rules-for-symlinks-to-dev-.udev-rules.d-for-la.patch
+Patch75: 0075-dracut-functions-set-LANG-C-for-ldd-output-parsing.patch
+Patch76: 0076-dracut-functions-use-LC_ALL-C-rather-than-LANG-C.patch
+Patch77: 0077-dmsquash-resume-do-not-name-the-dev-.udev-rules-like.patch
+Patch78: 0078-dmsquash-live-mount-live-image-at-dev-.initramfs-liv.patch
+Patch79: 0079-dmsquash-live-depend-on-dm-module.patch
+Patch80: 0080-dmsquash-live-do-not-umount-dev-.initramfs-live-for-.patch
+Patch81: 0081-plymouth-depend-on-crypt-if-cryptsetup-exists.patch
+Patch82: 0082-dracut.spec-removed-duplicate-COPYING.patch
+Patch83: 0083-Just-look-for-cryptroot-instead-of-sbin-cryptroot.patch
+Patch84: 0084-Have-cryptroot-ask-load-dm_crypt-if-needed.patch
+Patch85: 0085-crypt-assemble-70-luks.rules-dynamically.patch
+Patch86: 0086-cryptroot-ask-s-getargs-rd_NO_CRYPTTAB-getarg-rd_NO_.patch
+Patch87: 0087-crypt-parse-crypt.sh-fix-end-label-for-luks-udev-rul.patch
+Patch88: 0088-crypt-wait-for-all-rd_LUKS_UUI

Re: xulrunner 2.0 in rawhide (F15) bundles several system libs

[Matej Cepl]

Florent Le Coz, Mon, 04 Oct 2010 15:20:04 +0200:
>>  Trademark cannot be ever free as in freedom.
> That's why Fedora should not ship Firefox, but Iceweasel, or Icecat, or
> Minefield, or anything else that is not trademarked and isn't impossible
> to patch without mozilla's consent.

I won't comment on the trademark issue (because that's just pure lunacy), 
but let me comment here "they don't accept my patches, so they are non-
free". That's just nonsense ... any upstream is free to accept or reject 
any patches as they are free to decide. Ask Hans Reiser about reiserfs4. 
The difference is (and neither option makes the project non-free) is 
whether upstream accepts any patches at all (with some margin of error) 
or if they routinely accept patches and they give rational reason when 
rejecting some (and no, you don't have to agree with the reason).

And concerning having private copies of libraries, the difference is 
whether they try to send their patches upstream (and whether they 
actually did that in the past) or not.

Just my 0.02 CZK
-- 
http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
 
To err is human, to purr feline.


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

Re: Summary/Minutes for today's FESCo meeting (2010-10-05)

[Brandon Lozza]

On 10/5/10, Kevin Fenzi  wrote:
> ===
> #fedora-meeting: FESCO (2010-10-05)
> ===
>
> Meeting started by nirik at 19:30:01 UTC. The full logs are available at
> http://meetbot.fedoraproject.org/fedora-meeting/2010-10-05/fesco.2010-10-05-19.30.log.html
>
> Meeting summary
> ---
> * init process  (nirik, 19:30:01)
>   * mclasen will not be able to attend today due to a backhoe incident.
> (nirik, 19:30:48)
>   * cwicket will also be unable to attend.  (nirik, 19:30:59)
>   * kylem is also unable to attend.  (nirik, 19:31:13)
>
> * #473 new meeting time (redux)  (nirik, 19:33:54)
>   * LINK: https://fedorahosted.org/fesco/ticket/473   (nirik, 19:33:54)
>   * ACTION: make sure cwickert is updated, revisit next week.  (nirik,
> 19:46:09)
>   * reminder: you can vote in tickets if unable to attend the meeting.
> (nirik, 19:46:22)
>
> * Updates policy / Vision implementation status  (nirik, 19:46:48)
>   * ideas wanted to improve stable N-1 wording/distinction.  (nirik,
> 19:57:04)
>   * LINK: http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs
> <-- only shows formatting rules, so some recommendations for their
> content might be nice.  (gholms, 20:08:46)
>   * AGREED: will asking testers/qa to be on the lookout for things not
> following the update_policy and notify us via a ticket for further
> discussion.  (nirik, 20:09:54)
>   * AGREED: will see if FPC is willing/able to expand on the changelog
> guidelines.  (nirik, 20:12:47)
>
> * #472 About Mozilla's decision to not allow using the system's libvpx
>   (nirik, 20:14:40)
>   * LINK: https://fedorahosted.org/fesco/ticket/472   (nirik, 20:14:40)
>   * LINK: https://fedorahosted.org/fesco/ticket/472   (nirik, 20:30:41)
>   * AGREED: will vote on proposals in ticket.  (nirik, 21:05:11)
>
> * Open Floor  (nirik, 21:05:43)
>   * LINK: https://fedorahosted.org/rel-eng/ticket/4149   (gholms,
> 21:07:13)
>
> Meeting ended at 21:18:39 UTC.
>
>
>
>
> Action Items
> 
> * make sure cwickert is updated, revisit next week.
>
>
>
>
> Action Items, by person
> ---
> * cwickert
>   * make sure cwickert is updated, revisit next week.
> * **UNASSIGNED**
>   * (none)
>
>
>
>
> People Present (lines said)
> ---
> * nirik (145)
> * pjones (69)
> * mjg59 (56)
> * notting (39)
> * gholms (31)
> * ajax (23)
> * hicham (22)
> * abadger1999 (17)
> * spot (10)
> * Oxf13 (10)
> * zodbot (8)
> * mdomsch (8)
> * mcepl (1)
> * rdieter (1)
> * SMParrish (0)
> * kylem (0)
> * mclasen (0)
> * cwickert (0)
> --
> 19:30:01  #startmeeting FESCO (2010-10-05)
> 19:30:01  Meeting started Tue Oct  5 19:30:01 2010 UTC.  The chair
> is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
> 19:30:01  Useful Commands: #action #agreed #halp #info #idea #link
> #topic.
> 19:30:01  #meetingname fesco
> 19:30:01  The meeting name has been set to 'fesco'
> 19:30:01  #chair mclasen notting nirik SMParrish kylem ajax pjones
> cwickert mjg59
> 19:30:01  #topic init process
> 19:30:01  Current chairs: SMParrish ajax cwickert kylem mclasen
> mjg59 nirik notting pjones
> 19:30:06 * notting is here
> 19:30:36 * ajax waves
> 19:30:48  #info mclasen will not be able to attend today due to a
> backhoe incident.
> 19:30:56 * pjones throws a trout at ajax
> 19:30:59  #info cwicket will also be unable to attend.
> 19:31:12  A backhoe incident?  Ouch.
> 19:31:13  #info kylem is also unable to attend.
> 19:31:21  gholms: took out his home internet it seems.
> 19:31:30  Ok, that's not *so* bad.
> 19:31:52  and kylem will not be here
> 19:32:19  SMParrish: / mjg59: you guys here?
> 19:33:15  Afternoon
> 19:33:27  Hello. :) Thats 5.
> 19:33:45  Shall we start with meeting time?
> 19:33:54  #topic #473 new meeting time (redux)
> 19:33:54  https://fedorahosted.org/fesco/ticket/473
> 19:34:09  has everyone updated their
> http://whenisgood.net/ee8prq/results/z5binx entry?
> 19:34:15  i have
> 19:34:25 * nirik 's didn't really change any
> 19:35:04  so, currently we have 0 times everyone can attend. ;)
> 19:35:18  yeah :/
> 19:35:22  a few times with 1 person left out, but everyone else...
> 19:35:31  and excluding one person doesn't really help that much
> 19:36:11  I guess we need to confirm that everyone updated before we
> do anything else?
> 19:36:24  although one of the times where mclasen is the only
> holdout his update info says will become available in a couple of weeks
> 19:37:01  oh?
> 19:37:12  Wait. I'm suddenly worried by the timezones here.
> 19:37:15  wed 1-2?
> 19:37:17  So can we move to that time and then hope that he can make
> do responding to trac until then?  sounds not that great.
> 19:37:27  mjg59: yeah, the site is confusing.
> 19:37:28  mjg59: yeah, the site's representation of timezones is
> weird.
> 19:37:30  nirik: 2-3 your time. unless i'm forgetting what your
> time is
> 19:37:31  I think it's in my loca

Re: jackbeat

[Brendan Jones]

On 10/06/2010 08:06 PM, Xavier Bachelot wrote:
> If yes, from a quick glance, it seems jackbeat uses an allowed licence
> (GPL) and doesn't require any supporting libs that are not ditributable
> by Fedora, so I think the only reason it's not in the repo is nobody
> packaged it yet. Feel free to do so and submit a review.
>
> Regards,
> Xavier

Thanks for the research! Will do

Brendan

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

Re: jackbeat

[Xavier Bachelot]

On 10/06/2010 11:55 AM, Brendan Jones wrote:
> Is there a reason why this is not included in the repositories? If not 
> I'd be happy to submit it and take it on.
> 
> regards,
> 
> Brendan
> 
> 
Is it this software you are talking about ? http://jackbeat.samalyse.org/

If yes, from a quick glance, it seems jackbeat uses an allowed licence
(GPL) and doesn't require any supporting libs that are not ditributable
by Fedora, so I think the only reason it's not in the repo is nobody
packaged it yet. Feel free to do so and submit a review.

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

jackbeat

[Brendan Jones]

Is there a reason why this is not included in the repositories? If not 
I'd be happy to submit it and take it on.

regards,

Brendan


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

fedpkg koji error

[Farkas Levente]

hi,
while try to make a scratch build i always got:
-
# fedpkg scratch-build
Could not log into koji: Opening a SSL connection failed
-
even if i try to remove .fedora.cert and fedora-packager-setup (so it's
not a certificate problem).
what else can be the reason?
thanks in advance.
regards.

-- 
  Levente   "Si vis pacem para bellum!"
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757

[Tim Waugh]

On Tue, 2010-10-05 at 15:27 -0700, Jesse Keating wrote:
> PPS  I did not modify my bump script yet to attempt a commit to master
> and merge to the f14 branch.  In the interest of time, I took the easy
> route and just did commits to the f14 branch.  Maintainers can do a
> merge and fixup after the builds have been done if they wish to have
> their branches in sync with master once more.

For this sort of thing I would have thought that separate commits on
whichever branches need changing would be fine.  Git's merging (if/when
each maintainer decides to merge branches) ought to be able to handle
that.

I don't think that merging "backwards" from master to f14 would be a
good idea.  Wouldn't that bring "rawhide"-y changes into f14?  For
example, ghostscript's master branch uses ghostscript-9.00 -- merging
master into f14 would cause havoc.

Or have I misunderstood what you are saying?

Tim.
*/



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: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757

[Peter Robinson]

> PPS  I did not modify my bump script yet to attempt a commit to master
> and merge to the f14 branch.  In the interest of time, I took the easy
> route and just did commits to the f14 branch.  Maintainers can do a
> merge and fixup after the builds have been done if they wish to have
> their branches in sync with master once more.

While in some cases this might be OK there is alot of packages that
have already diverged from rawhide I'm thinking of the gnome-3
stuff amongst others.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757

[Peter Robinson]

On Tue, Oct 5, 2010 at 11:27 PM, Jesse Keating  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> As you might be aware, there was a period of roughly two weeks where a
> gcc build (gcc-4.5.1-3.fc14) in the buildroots for both Fedora 14 and
> Fedora 15.  Items built with this could have undefined behavior, which
> could lead to data corruption.

I was aware but only due to random packages of mine being rebuilt, I
was wondering when the details were going to emege.

> Unfortunately I'm told that it is impossible to look at a generated
> binary and detect whether or not the binary would be effected by this
> bug.  The only reliable way to tell would be to re-create the build
> environment exactly, except replace GCC with one that will detect the
> error scenario and print something.  As this is a significant amount of
> work, I decided instead to just rebuild the potential problem builds.
>
> I detected all the "latest" builds of packages that had gcc-4.5.1-3.fc14
> in the buildroot, and then further narrowed it down to things which
> require rtld(GNU_HASH) to find the things that actually used gcc (since
> gcc gets thrown in every buildroot anyway).
>
> For Fedora 15 this was a simple task.  Just find the packages where the
> latest build is "bad", bump it and rebuild it.  End of story.  This work
> is already done (except that a few have failed, and I need to follow up
> on those).
>
> For Fedora 14 the matter is much more complicated.  Builds are spread
> out across 3 main tags, dist-f14, dist-f14-updates-testing, and
> dist-f14-updates-candidate.
>
> dist-f14 is things that have made it through bodhi as stable.
>
> dist-f14-updates-testing is for things which are currently in
> updates-testing
>
> dist-f14-updates-candidate is for things which could potentially become
> an update should the maintainer decide.
>
> To handle the F14 scene I've come up with this strategy:
> * For things tagged in dist-f14 and no newer build elsewhere, do a bump,
> build and tag directly into dist-f14.  While there is some risk of
> breakage, it is quite minimal and with discussion from QA we are willing
> to take that chance.  This work is ongoing.
>
> * For things tagged in dist-f14-updates-testing, do a bump, build and
> then edit the bodhi ticket to add the new build, and re-push to
> updates-testing.  This work will begin soon.

This unfortunately also has the effect of resetting the timer possibly
pushing things out to 14 days, which is some what painful.

> * for things tagged in dist-f14-updates-candidate, do a bump and build.
>  Then look for an open bodhi ticket for that package, adjusting as
> needed.  If no bodhi ticket is found, do not create a new one, just
> leave the build as is.  This work will begin soon.
>
> Using this strategy we should be able to replace potentially bad builds
> with corrected ones wherever they might have been published (barring the
> failed builds).  This message is mostly a heads up as to what's happening.

What happens in a case where the packager is about to push a new
version, or there has been a rebuild since the 26th?

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