Re: Fedora 18 laptop regression

[Rex Dieter]

Christoph Wickert wrote:

> How many DE actually to this? GNOME does, not sure about KDE, Sugar or
> Mate, but inhibit support seems to be the exception and not the rule
> Xfce and LXDE do not yet support it, so power management on these DEs is
> broken by default.
> 
> A change that affects all desktops really should have been handled as a
> feature with approval from FESCo.  Did you ever contact the relevant
> package maintainers?

Fwiw, KDE sig was contacted, and the feature implemented (though not all 
quirks are sorted out yet).

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

-- rex

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

Re: Feedback wanted: Fedora Formulas

[Kevin Fenzi]

On Tue, 8 Jan 2013 19:18:36 -0500
Matthew Miller  wrote:

> On Tue, Jan 08, 2013 at 11:17:35PM +, "Jóhann B. Guðmundsson"
> wrote:
> > On 01/08/2013 08:15 PM, Kevin Fenzi wrote:
> > >So, what do folks think? Workable? Crazy? Crazy enough to work?
> > And we are supposed to QA this how?
> 
> Like any software? 
> 
> I'm not sure I understand the question, actually. Can you elaborate?

I'd welcome any QA thoughts/feedback. I think we would probibly have to
have guidelines at least somewhat worked out before we could figure out
how to test things. 

We could do something like what we do for packages, ie, a testing
collection and promotion to stable only happens with positive tester
feedback.

We could try and build into the process some kind of automated
testing/tooling. (search for forbidden items, runs in a virt that list
all files changed and diffs of those for review, etc. 

I think QA is definitely something to keep in mind when thinking about
the rest of the process... 

kevin


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

Re: Feedback wanted: Fedora Formulas

[Kevin Fenzi]

On Tue, 8 Jan 2013 16:18:56 -0800
Mahrud S  wrote:

> I know that Slax Linux used to have this feature. You could just
> choose the modules that you want on the website and download a custom
> live iso with those packages! But that feature is disabled
> now, perhaps because they use a new module system now.

This is not exactly what I meant... this would be things you could
run/install on any already installed Fedora. It would not have anything
to do with creating live isos... it would be just extra things for
existing installs. 

Thats not to say perhaps we couldn't think of a clever way to somehow
generate images based on them, but it would probibly take some way to
take an existing machine and make a live image from it. Not sure how
easy that is to do. 

> Ah, here: http://old.slax.org/build.php
> I'm not sure whether that's just for show or if it still works though.
> 
> That's what you are thinking, right?

Not exactly, see above. 

kevin


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

Re: Feedback wanted: Fedora Formulas

[Brendan Jones]

On 01/09/2013 05:10 AM, Brendan Jones wrote:

On 01/08/2013 09:15 PM, Kevin Fenzi wrote:

Greetings.

I've whipped up the early ideas of a way to replace (most) spins with
something that is more generic and useful. I have signed up for a
fudcon session to brainstorm on this idea and see if it can be beaten
into a plan/schedule/feature, or if it's not going to work for whatever
reason.

I have a very brainstormy/draft wiki page outlining the idea at:
https://fedoraproject.org/wiki/Fedora_formulas

The short version:

Setup a infrastructure/framework around a collection of ansible
playbooks to allow our users to simply download a formula for what they
want to do and have a curated setup made for them using Fedora
packages.

Want a electionics lab setup? download. review. answer some
questions. click.
Want a LAMP stack? download. review. answer some questions. click.
Want a openstack demo cluster? ditto.
Want a graphics designer workstation? ditto.

Note that this assumes you have already installed Fedora, it's a post
install setup. This would mean that we should continue to do spins for
various desktops as people may way to install their desktop as a base
before adding on formulas.

Of course there's tons of details/questions to work out (many listed on
the wiki page, but I'm sure there are more details too).

So, what do folks think? Workable? Crazy? Crazy enough to work?
:)

kevin


Most spins don't do anything really special apart from install a default
set of packages. Maybe this is because of the limitations of kickstart,
I don't know.

Coming from the Fedora Audio spin here's a few things that we would like
to achieve that we can (mostly) from a kickstart:

  - add default groups for the liveuser and logged in user
  - add extra kernel boot parameters (threadirqs)
  - custom desktop themes, favourites, and desktop settings (turning off
desktop effects for example)
  - default autostart apps

The main problem we have with kickstarts at the moment is that there is
no way (according to current packaging guidelines) to alter files owned
by other packages. In the future we might like to choose different
pulseaudio modules to load, ALSA config based on hardware etc. I don't


This is probably not a good example as we could drop such config files 
in /etc/skel

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

Re: Feedback wanted: Fedora Formulas

[Brendan Jones]

On 01/08/2013 09:15 PM, Kevin Fenzi wrote:

Greetings.

I've whipped up the early ideas of a way to replace (most) spins with
something that is more generic and useful. I have signed up for a
fudcon session to brainstorm on this idea and see if it can be beaten
into a plan/schedule/feature, or if it's not going to work for whatever
reason.

I have a very brainstormy/draft wiki page outlining the idea at:
https://fedoraproject.org/wiki/Fedora_formulas

The short version:

Setup a infrastructure/framework around a collection of ansible
playbooks to allow our users to simply download a formula for what they
want to do and have a curated setup made for them using Fedora
packages.

Want a electionics lab setup? download. review. answer some
questions. click.
Want a LAMP stack? download. review. answer some questions. click.
Want a openstack demo cluster? ditto.
Want a graphics designer workstation? ditto.

Note that this assumes you have already installed Fedora, it's a post
install setup. This would mean that we should continue to do spins for
various desktops as people may way to install their desktop as a base
before adding on formulas.

Of course there's tons of details/questions to work out (many listed on
the wiki page, but I'm sure there are more details too).

So, what do folks think? Workable? Crazy? Crazy enough to work?
:)

kevin

Most spins don't do anything really special apart from install a default 
set of packages. Maybe this is because of the limitations of kickstart, 
I don't know.


Coming from the Fedora Audio spin here's a few things that we would like 
to achieve that we can (mostly) from a kickstart:


 - add default groups for the liveuser and logged in user
 - add extra kernel boot parameters (threadirqs)
 - custom desktop themes, favourites, and desktop settings (turning off 
desktop effects for example)

 - default autostart apps

The main problem we have with kickstarts at the moment is that there is 
no way (according to current packaging guidelines) to alter files owned 
by other packages. In the future we might like to choose different 
pulseaudio modules to load, ALSA config based on hardware etc. I don't 
see how this solution could do this if it were RPM based. If is based as 
some kind of overlay that alters files owned by other packages post 
install then there needs to be an obvious indication that this has 
occurred. I'd expect that whoever writes such a "formula" would have to 
get sign off from the owner of the package whose files it modifies.


We are working around this by developing an application which the user 
has to run and is prompted to confirm such changes. Such a program could 
be configured to run once at startup I guess. This is a work in progress 
and not in production yet.


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

Re: GRUB2 packages, fedup

[Chris Murphy]

On Jan 8, 2013, at 5:17 PM, Matthew Miller  wrote:

> On Tue, Jan 08, 2013 at 02:43:36PM -0800, Adam Williamson wrote:
>> We did (try to...) convert installs from grub to grub2 when we did that
>> migration in Fedora...16?...when using the 'official upgrade
>> path' (anaconda, at the time), so that precedent suggests we should do
>> the same for EFI. If not in F18 with package updates, at least in F19.
> 
> Not EFI related, but a note -- if original-grub configuration files exist,
> they should stay, because the system may be a Xen guest booted with pv-grub.

Original F17 efi files are in /boot/efi/EFI/redhat. The replacement grub2 files 
go in /boot/efi/EFI/fedora. So I'd expect the old ones to remain behind.

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

Schedule for Wednesday's FESCo Meeting (2013-01-09)

[Josh Boyer]

Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 17:00UTC (1:00pm EDT, 19:00 CEST) in #fedora-meeting on
irc.freenode.net.

Links to all tickets below can be found at:
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #896 Refine Feature process
.fesco 896
https://fedorahosted.org/fesco/ticket/896

#topic #963 change of names of configuration files
.fesco 963
https://fedorahosted.org/fesco/ticket/963

= New business =

#topic #984 F19 Feature: 3D Printing -
https://fedoraproject.org/wiki/Features/3D_Printing
.fesco 984
https://fedorahosted.org/fesco/ticket/984
http://lists.fedoraproject.org/pipermail/devel/2013-January/175770.html

#topic #985 F19 Feature: Pillow - https://fedoraproject.org/wiki/Features/Pillow
.fesco 985
https://fedorahosted.org/fesco/ticket/985
http://lists.fedoraproject.org/pipermail/devel/2013-January/175769.html

#topic #986 F19 Feature: DualstackNetworking -
https://fedoraproject.org/wiki/Features/DualstackNetworking
.fesco 986
https://fedorahosted.org/fesco/ticket/986
http://lists.fedoraproject.org/pipermail/devel/2013-January/175773.html

= Open Floor =

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora 18 Beta for ARM now available!

[Paul Whalen]

The Fedora ARM team is pleased to announce that the Fedora 18 Beta release
for ARM is now available for download from:

http://dl.fedoraproject.org/pub/fedora-secondary/releases/test/18-Beta/Images/

The Beta release includes pre-built images for Versatile Express (QEMU), 
Trimslice (Tegra), Pandaboard (OMAP4), GuruPlug (Kirkwood), and Beagleboard 
(OMAP3)
hardware platforms. The Fedora 18 Beta for ARM now includes an install tree in 
the 
yum repository which may be used to PXE-boot a kickstart-based install on 
systems 
that support it, such as the Calxeda EnergyCore (HighBank). 
Please visit the announcement page for additional information and links to
specific images:

http://fedoraproject.org/wiki/Architectures/ARM/Fedora_18_Beta

We invite you to download the Fedora 18 Beta release and provide your valuable 
input to the Fedora ARM team. 

Please join us on the IRC in #fedora-arm on Freenode or send feedback and 
comments to the ARM mailing list.

On behalf of the Fedora ARM team,
Paul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Feedback wanted: Fedora Formulas

[Mahrud S]

update: definitely works.
It's pretty neat to have a live usb with the exact programs that you like
ready in your pocket!
How can you create an iso on the fly that fast?!

On Tue, Jan 8, 2013 at 4:18 PM, Mahrud S  wrote:

> I know that Slax Linux used to have this feature. You could just choose
> the modules that you want on the website and download a custom live iso
> with those packages! But that feature is disabled now, perhaps
> because they use a new module system now.
>
> Ah, here: http://old.slax.org/build.php
> I'm not sure whether that's just for show or if it still works though.
>
> That's what you are thinking, right?
>
> On Tue, Jan 8, 2013 at 3:17 PM, "Jóhann B. Guðmundsson" <
> johan...@gmail.com> wrote:
>
>> On 01/08/2013 08:15 PM, Kevin Fenzi wrote:
>>
>>> So, what do folks think? Workable? Crazy? Crazy enough to work?
>>>
>>
>> And we are supposed to QA this how?
>>
>> JBG
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://admin.fedoraproject.**org/mailman/listinfo/devel
>
>
>
>
> --
> Best wishes
> Mahrud 
>



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

Re: Feedback wanted: Fedora Formulas

[Mahrud S]

I know that Slax Linux used to have this feature. You could just choose the
modules that you want on the website and download a custom live iso with
those packages! But that feature is disabled now, perhaps
because they use a new module system now.

Ah, here: http://old.slax.org/build.php
I'm not sure whether that's just for show or if it still works though.

That's what you are thinking, right?

On Tue, Jan 8, 2013 at 3:17 PM, "Jóhann B. Guðmundsson"
wrote:

> On 01/08/2013 08:15 PM, Kevin Fenzi wrote:
>
>> So, what do folks think? Workable? Crazy? Crazy enough to work?
>>
>
> And we are supposed to QA this how?
>
> JBG
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.**org/mailman/listinfo/devel




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

Re: Feedback wanted: Fedora Formulas

[Matthew Miller]

On Tue, Jan 08, 2013 at 11:17:35PM +, "Jóhann B. Guðmundsson" wrote:
> On 01/08/2013 08:15 PM, Kevin Fenzi wrote:
> >So, what do folks think? Workable? Crazy? Crazy enough to work?
> And we are supposed to QA this how?

Like any software? 

I'm not sure I understand the question, actually. Can you elaborate?


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: GRUB2 packages, fedup

[Matthew Miller]

On Tue, Jan 08, 2013 at 02:43:36PM -0800, Adam Williamson wrote:
> We did (try to...) convert installs from grub to grub2 when we did that
> migration in Fedora...16?...when using the 'official upgrade
> path' (anaconda, at the time), so that precedent suggests we should do
> the same for EFI. If not in F18 with package updates, at least in F19.

Not EFI related, but a note -- if original-grub configuration files exist,
they should stay, because the system may be a Xen guest booted with pv-grub.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Feedback wanted: Fedora Formulas

[Jóhann B. Guðmundsson]

On 01/08/2013 08:15 PM, Kevin Fenzi wrote:

So, what do folks think? Workable? Crazy? Crazy enough to work?


And we are supposed to QA this how?

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

Re: Fedora 18 laptop regression

[Samuel Sieb]

On 01/07/2013 10:45 PM, Bastien Nocera wrote:

On Mon, 2013-01-07 at 19:49 +, alex...@hushmail.com wrote:

On 07/01/2013 at 7:40 PM, "Matthias Clasen"  wrote:


- Original Message -


And is it possible to disable suspend on lid close but still have
GNOME lock the screen on lid close? No? Didn't think so...


With the lid closed, your session will go idle, which will
eventually cause the screen to lock.
--


And is that the same as what I was asking? No? Didn't think so...

It's little things like this that make GNOME a love-hate relationship.
Looks gorgeous and several things they've got really right, but in
many places it's still style over substance.


We might even look at fixing your bug if you filed it upstream. No?
Didn't think so ;)



You mean like this one?
https://bugzilla.gnome.org/show_bug.cgi?id=685918
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: GRUB2 packages, fedup

[Adam Williamson]

On Tue, 2013-01-08 at 12:33 -0700, Chris Murphy wrote:
> On Jan 8, 2013, at 12:22 PM, Chris Murphy 
> wrote:
> 
> > What package is responsible for writing the file /etc/default/grub?
> Because a prior EFI system with grub-efi, which of course doesn't have
> an /etc/default/grub, doesn't have it after a fedup upgrade, and still
> doesn't have it after manually installing either the grub2 or
> grub2-efi packages.
> > 
> > I do have /etc/grub.d/ files, which is part of one or both of those
> packages.
> 
> Looks like anaconda normally produces /etc/default/grub, and fedup
> wouldn't be expected to do that since it's also not upgrading grub-efi
> to grub2-efi.
> 
> So then the question is if a future version of fedup is expected to do
> grub-efi to grub2-efi upgrades? Or if that's the realm of a new
> installation?

We did (try to...) convert installs from grub to grub2 when we did that
migration in Fedora...16?...when using the 'official upgrade
path' (anaconda, at the time), so that precedent suggests we should do
the same for EFI. If not in F18 with package updates, at least in F19.

It wouldn't be fedup's job exactly, I don't think. If I understand the
design right, fedup is designed so that other packages can ship scripts
which should be run during fedup operations. So the design would
probably be that the grub2-efi package should obsolete grub-efi, and
ship a fedup script that should be run on upgrade from grub-efi to
grub2-efi, to migrate the system across. I believe these are basically
dracut scripts. wwoods would no doubt be able to correct all the errors
I have inevitably made in the above :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

Orphaned package: ushare

[Adam Jackson]

Nothing's using this in F18, and upstream is very much dormant.  I don't
want to maintain it and I'd honestly prefer people use gupnp, so I'm
tossing ushare to the wolves.  If nobody claims it in a week I'll
deadpackage it.

- ajax


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: Proposed F19 Feature: Package Signature Checking During Installation

[Till Maas]

On Tue, Jan 08, 2013 at 03:20:41PM -0500, Peter Jones wrote:
> On Tue, Jan 08, 2013 at 08:28:03PM +0100, Björn Persson wrote:
> 
> > I'll agree that most users probably don't verify their DVD images as it
> > takes some manual work to do it properly, so that's another weak link,
> > but the possibility does exist for those of us who care enough about
> > our security.
> 
> It's like Ronald Reagan said: trust, but verify.  In this scenario,
> there's no way for anaconda to verify it.  As such, I'm not planning to
> work on it for this feature.

I do not see the difference from anaconda's perspective. With secure
boot enabled, UEFI(?) verified the boot medium/the environment anaconda
runs in and with the manual process a human did. How does it help
anaconda if the environment has been verified by UEFI?

Nevertheless, once anaconda is capable of installing only proper
packages from a verified environment, a patch do also do this if the
environment has been verified by a human should be trivial.

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

Re: mactel boot revisited, updating to grub2

[Peter Jones]

On Tue, Jan 08, 2013 at 02:03:31PM -0700, Chris Murphy wrote:
> 
> On Jan 8, 2013, at 12:45 PM, Chris Murphy  wrote:
> 
> > 
> > On Jan 8, 2013, at 12:34 PM, Matthew Garrett  wrote:
> > 
> >> On Tue, Jan 08, 2013 at 12:16:52PM -0700, Chris Murphy wrote:
> >> 
> >>> cp /boot/efi/EFI/fedora/grubx64.efi 
> >>> /boot/efi/EFI/System/Library/CoreServices/boot.efi
> >>> grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
> >> 
> >> Make sure that the config is using linuxefi and initrdefi, not linux and 
> >> initrd.
> > 
> > It does, but contrary to what I said earlier, I think I made a mistake 
> > moving the grub2-install created grubx64.efi file, because that one now 
> > clearly works. Whereas the one the grub2-efi package puts in 
> > /boot/efi/EFI/fedora doesn't work.
> 
> OK so it appears to be a conflict between kernel 3.6.11-1 and GRUB 2.00 that 
> I'm not clearly understanding, because adding to the confusion I just 
> realized that one of the grub2's (mine or the prebaked one) was actually 
> using a residual fedup vmlinuz-fedup kernel, which is actually kernel 3.6.6. 
> So it seems at least there's a regression in nouveau occurring between 
> grub2-efi and kernel 3.6.11, but not with 3.6.6.
> 
> grub-efi (legacy) can boot either kernel fine.

This most likely has nothing to do with grub2 at all.

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

Re: mactel boot revisited, updating to grub2

[Chris Murphy]

On Jan 8, 2013, at 12:45 PM, Chris Murphy  wrote:

> 
> On Jan 8, 2013, at 12:34 PM, Matthew Garrett  wrote:
> 
>> On Tue, Jan 08, 2013 at 12:16:52PM -0700, Chris Murphy wrote:
>> 
>>> cp /boot/efi/EFI/fedora/grubx64.efi 
>>> /boot/efi/EFI/System/Library/CoreServices/boot.efi
>>> grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
>> 
>> Make sure that the config is using linuxefi and initrdefi, not linux and 
>> initrd.
> 
> It does, but contrary to what I said earlier, I think I made a mistake moving 
> the grub2-install created grubx64.efi file, because that one now clearly 
> works. Whereas the one the grub2-efi package puts in /boot/efi/EFI/fedora 
> doesn't work.

OK so it appears to be a conflict between kernel 3.6.11-1 and GRUB 2.00 that 
I'm not clearly understanding, because adding to the confusion I just realized 
that one of the grub2's (mine or the prebaked one) was actually using a 
residual fedup vmlinuz-fedup kernel, which is actually kernel 3.6.6. So it 
seems at least there's a regression in nouveau occurring between grub2-efi and 
kernel 3.6.11, but not with 3.6.6.

grub-efi (legacy) can boot either kernel fine.


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

Re: Proposed F19 Feature: Package Signature Checking During Installation

[Peter Jones]

On Tue, Jan 08, 2013 at 08:28:03PM +0100, Björn Persson wrote:

> I'll agree that most users probably don't verify their DVD images as it
> takes some manual work to do it properly, so that's another weak link,
> but the possibility does exist for those of us who care enough about
> our security.

It's like Ronald Reagan said: trust, but verify.  In this scenario,
there's no way for anaconda to verify it.  As such, I'm not planning to
work on it for this feature.

But again, don't let that stop you from submitting a feature that you plan
to work.

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

Re: Fedora 18 laptop regression

[alex399]

On 08/01/2013 at 6:46 AM, "Bastien Nocera"  wrote:
>
>On Mon, 2013-01-07 at 19:49 +, alex...@hushmail.com wrote:
>> On 07/01/2013 at 7:40 PM, "Matthias Clasen"  
>wrote:
>> >
>> >- Original Message -
>> >
>> >> And is it possible to disable suspend on lid close but still 
>have
>> >> GNOME lock the screen on lid close? No? Didn't think so...
>> >
>> >With the lid closed, your session will go idle, which will 
>> >eventually cause the screen to lock.
>> >-- 
>> 
>> And is that the same as what I was asking? No? Didn't think so...
>> 
>> It's little things like this that make GNOME a love-hate 
>relationship.
>> Looks gorgeous and several things they've got really right, but 
>in
>> many places it's still style over substance.
>
>We might even look at fixing your bug if you filed it upstream. No?
>Didn't think so ;)
>

To go through that effort only to be ignored or lectured on the benefits of 
suspend? No thanks. It's more fun to rant on fedora-devel. Fix it if you want. 
I've done my bit :)

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

Re: Feedback wanted: Fedora Formulas

[John . Florian]

> From: Kevin Fenzi 
> 
> Greetings. 
> 
> I've whipped up the early ideas of a way to replace (most) spins with
> something that is more generic and useful. I have signed up for a
> fudcon session to brainstorm on this idea and see if it can be beaten
> into a plan/schedule/feature, or if it's not going to work for whatever
> reason. 
> 
> I have a very brainstormy/draft wiki page outlining the idea at: 
> https://fedoraproject.org/wiki/Fedora_formulas
> 
> The short version: 
> 
> Setup a infrastructure/framework around a collection of ansible
> playbooks to allow our users to simply download a formula for what they
> want to do and have a curated setup made for them using Fedora
> packages. 
> 
> Want a electionics lab setup? download. review. answer some
> questions. click. 
> Want a LAMP stack? download. review. answer some questions. click. 
> Want a openstack demo cluster? ditto. 
> Want a graphics designer workstation? ditto.
> 
> Note that this assumes you have already installed Fedora, it's a post
> install setup. This would mean that we should continue to do spins for
> various desktops as people may way to install their desktop as a base
> before adding on formulas.
> 
> Of course there's tons of details/questions to work out (many listed on
> the wiki page, but I'm sure there are more details too). 
> 
> So, what do folks think? Workable? Crazy? Crazy enough to work?
> :) 
> 
> kevin


Doh!  I wish I was going to fudcon. I've yet to get to one and this would 
be right up my alley.  I'm doing something similar with puppet now where I 
boot a custom Live Fedora spin with stateless Linux features enabled and 
puppet makes each node conform to some predetermined role.  I've been 
wanting to get some time with ansible because puppet really isn't working 
very well for this.  My situation differs mostly in that I use this 
approach to maintain hundreds (working towards thousands) of 
appliance-like nodes.  Still, there is much in common once you go beyond 
just managing packages, but also their run-time state.  Do you aim to go 
that far, or stop just shy of that?

I don't think the concept is crazy at all -- I think it's terrific, but I 
also have no idea how attached the current spin maintainers are to their 
established methods.
--
John Florian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18: WebApp and httpd 2.4 configuration

[Jóhann B. Guðmundsson]

On 01/08/2013 08:13 PM, Miloslav Trmač wrote:

On Tue, Jan 8, 2013 at 9:07 PM, "Jóhann B. Guðmundsson"
 wrote:

Surely we must have some kind of "omg we cant release with this
component in final it's utterly broken or posses security risk!" fail
safe mechanism in place to deal with this?

Do any of these packages pose a high security risk?

Do we or do we not have such an process in place?

http://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria#Final_Release_Requirements
item 22.
Mirek


Yeah had forgotten we added that this release cycle and given that these 
bugs affect allow/deny behavior in apache perhaps it would be wize to 
have someone from the security team look into it...


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

Feedback wanted: Fedora Formulas

[Kevin Fenzi]

Greetings. 

I've whipped up the early ideas of a way to replace (most) spins with
something that is more generic and useful. I have signed up for a
fudcon session to brainstorm on this idea and see if it can be beaten
into a plan/schedule/feature, or if it's not going to work for whatever
reason. 

I have a very brainstormy/draft wiki page outlining the idea at: 
https://fedoraproject.org/wiki/Fedora_formulas

The short version: 

Setup a infrastructure/framework around a collection of ansible
playbooks to allow our users to simply download a formula for what they
want to do and have a curated setup made for them using Fedora
packages. 

Want a electionics lab setup? download. review. answer some
questions. click. 
Want a LAMP stack? download. review. answer some questions. click. 
Want a openstack demo cluster? ditto. 
Want a graphics designer workstation? ditto.

Note that this assumes you have already installed Fedora, it's a post
install setup. This would mean that we should continue to do spins for
various desktops as people may way to install their desktop as a base
before adding on formulas.

Of course there's tons of details/questions to work out (many listed on
the wiki page, but I'm sure there are more details too). 

So, what do folks think? Workable? Crazy? Crazy enough to work?
:) 

kevin


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

Re: Fedora 18: WebApp and httpd 2.4 configuration

[Miloslav Trmač]

On Tue, Jan 8, 2013 at 9:07 PM, "Jóhann B. Guðmundsson"
 wrote:
>>> Surely we must have some kind of "omg we cant release with this
>>> component in final it's utterly broken or posses security risk!" fail
>>> safe mechanism in place to deal with this?
>>
>> Do any of these packages pose a high security risk?
>
> Do we or do we not have such an process in place?

http://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria#Final_Release_Requirements
item 22.
   Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18: WebApp and httpd 2.4 configuration

[Jóhann B. Guðmundsson]

On 01/08/2013 07:56 PM, Kevin Fenzi wrote:

On Tue, 08 Jan 2013 09:39:10 +
"Jóhann B. Guðmundsson"  wrote:


This may come as an completely stupid question but given that we have
not released yet why cant we remove those packages?

Because we are in the very last stages of final freeze.
Any changes at all can cause consequences we can't predict.
The safe thing is to just make as few changes as possible.


So who's responsible for fixing this and how can we prevent this from 
happening in the future?


  


Surely we must have some kind of "omg we cant release with this
component in final it's utterly broken or posses security risk!" fail
safe mechanism in place to deal with this?

Do any of these packages pose a high security risk?


Do we or do we not have such an process in place?

JBG

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

Re: Fedora 18: WebApp and httpd 2.4 configuration

[Kevin Fenzi]

On Tue, 08 Jan 2013 09:39:10 +
"Jóhann B. Guðmundsson"  wrote:

> This may come as an completely stupid question but given that we have 
> not released yet why cant we remove those packages?

Because we are in the very last stages of final freeze. 
Any changes at all can cause consequences we can't predict. 
The safe thing is to just make as few changes as possible. 

> Surely we must have some kind of "omg we cant release with this 
> component in final it's utterly broken or posses security risk!" fail 
> safe mechanism in place to deal with this?

Do any of these packages pose a high security risk? 

kevin


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

Re: Red Hat QXL GPU Driver for Windows 7?

[Lars Seipel]

On Tuesday 08 January 2013 10:36:18 Jeffrey Ollie wrote:
> http://fedoraproject.org/wiki/Features/QXLKMSSupport

No, this feature has nothing to do with Windows. You can get Windows guest 
drivers including a RH-signed QXL driver from here:

http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/

You can also build from source but then you have to sign them with some 
"developer test certificate" or something in order to get them loaded on x86-64 
WNT guests.

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

Re: Proposed F19 Feature: NodeJS - The JavaScript runtime and associated ecosystem, including the npm package manager

[T.C. Hollingsworth]

On Tuesday, January 8, 2013, Miloslav Trmač  wrote:
> On Tue, Jan 8, 2013 at 4:12 PM, Jaroslav Reznik  wrote:
>> = Features/NodeJS =
>> https://fedoraproject.org/wiki/Features/NodeJS
>
> From Summary:
>> The Node.js JavaScript runtime and associated ecosystem, including the npm 
>> package manager.
> Could you describe more detail the interaction of npm and rpm
> packaging, please?

Not much different than e.g. Python's easy_install/pip and RPM.  You
can install packages using both RPM/yum and npm, and `npm install -g`
can possibly get you into trouble just like `easy_install` outside a
virtualenv can.

The upside is that Node/npm use a sort of virtualenv-by-default setup
whereupon all modules must explicitly provide their dependencies in a
"node_modules" directory.  System RPMs accomplish this by just
symlinking to the other modules, but developers working on their own
projects have the option of `npm install`ing the npm version of the
module or `npm link`ing the system version into their project.

>At least the "how to test" section suggests that
> npm will be the preferred packaging mechanism, which is different from
> how other language-specific packaging systems are treated.

It's only "preferred" right now in the sense that we can't possibly
package all 20,000+ modules in the npm registry in 6 months, so users
interested in Node will most likely have to get what they want via npm
for the time being.

Even if we did, developers will still want to use some featurtes of
npm for the reasons mentioned above.

>     Mirek

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

Re: mactel boot revisited, updating to grub2

[Chris Murphy]

On Jan 8, 2013, at 12:34 PM, Matthew Garrett  wrote:

> On Tue, Jan 08, 2013 at 12:16:52PM -0700, Chris Murphy wrote:
> 
>> cp /boot/efi/EFI/fedora/grubx64.efi 
>> /boot/efi/EFI/System/Library/CoreServices/boot.efi
>> grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
> 
> Make sure that the config is using linuxefi and initrdefi, not linux and 
> initrd.

It does, but contrary to what I said earlier, I think I made a mistake moving 
the grub2-install created grubx64.efi file, because that one now clearly works. 
Whereas the one the grub2-efi package puts in /boot/efi/EFI/fedora doesn't work.

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

Re: Review swap

[Yannick Brosseau]

On 2013-01-08 14:26, Brendan Jones wrote:
> On 01/08/2013 08:16 PM, Yannick Brosseau wrote:
>> Hi,
>>
>> I have one pending package review that I would like to swap:
>>
>> babeltrace - Trace Viewer and Converter, mainly for the Common Trace
>> Format (LTTng)
>> https://bugzilla.redhat.com/show_bug.cgi?id=846488
>>
>> Thanks,
>>
>> Yannick
>>
> I'll take this if you can take this simple one on:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=887756
Ok, will check it.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: NodeJS - The JavaScript runtime and associated ecosystem, including the npm package manager

[T.C. Hollingsworth]

On 1/8/13, "Jóhann B. Guðmundsson"  wrote:
> I thought Lubomir Rintel a.k.a lkundrak had been working on this [1]?
>
> Was he not contacted either?

The last time he was contacted (during my original packaging effort)
regarding it he said he was "disgusted" with it and since FESCo
recently reassigned ownership of all his packages I figured there was
no need to bother him about it again.

> JBG
>
> 1. http://fedoraproject.org/wiki/User:Lkundrak/NodeJS
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: mactel boot revisited, updating to grub2

[Matthew Garrett]

On Tue, Jan 08, 2013 at 12:16:52PM -0700, Chris Murphy wrote:

> cp /boot/efi/EFI/fedora/grubx64.efi 
> /boot/efi/EFI/System/Library/CoreServices/boot.efi
> grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Make sure that the config is using linuxefi and initrdefi, not linux and 
initrd.

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

Re: GRUB2 packages, fedup

[Chris Murphy]

On Jan 8, 2013, at 12:22 PM, Chris Murphy  wrote:

> What package is responsible for writing the file /etc/default/grub? Because a 
> prior EFI system with grub-efi, which of course doesn't have an 
> /etc/default/grub, doesn't have it after a fedup upgrade, and still doesn't 
> have it after manually installing either the grub2 or grub2-efi packages.
> 
> I do have /etc/grub.d/ files, which is part of one or both of those packages.

Looks like anaconda normally produces /etc/default/grub, and fedup wouldn't be 
expected to do that since it's also not upgrading grub-efi to grub2-efi.

So then the question is if a future version of fedup is expected to do grub-efi 
to grub2-efi upgrades? Or if that's the realm of a new installation?


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

Re: Proposed F19 Feature: Package Signature Checking During Installation

[Björn Persson]

Peter Jones wrote:
> On Tue, Jan 08, 2013 at 05:46:04PM +0100, Björn Persson wrote:
> > In my opinion, if Anaconda finds that it was booted without Secure
> > Boot, then it should assume that the user has verified the checksum on
> > the installation image and that the keys therein are therefore trusted,
> > and use those keys to verify any packages it downloads.  
> 
> Feel free to submit a feature for this and patches for it if you feel
> it's appropriate to do so.

I want to, it's just that if I'd try to actually do everything I want
to do I'd spread myself so thin that I'd never get anything done at
all.

> I don't happen to think it is, so I'm not going to.

Do you think anything is gained security-wise by omitting the signature
checking? Is the installation more secure if the packages aren't
verified at all than if they are verified against an uncertain root of
trust? Or does it take more programming work to do the same checking in
all cases than it takes to enable or disable the checking depending on
whether Secure Boot was used?

> > It's enough to verify downloaded packages in that case. Packages
> > included on the boot medium don't need to be checked if the boot medium
> > is trusted, but of course it doesn't hurt to verify those too if it's
> > easier to program that way.  
> 
> It's hard to figure out how these are more trustable than downloaded
> packages, given that using boot media that wasn't downloaded is a very
> rare way to install Fedora.

DVD images have usually been published together with a file of
checksums, and I hope that practice will continue. The DVD image can be
verified with the checksum. The checksum can be verified with the PGP
signature on the checksum file. The signature is made with the Fedora
project's release key. The release key can be downloaded from Fedora's
server over HTTPS. The HTTPS session is secured with an X.509 key that
belongs to Red Hat. The X.509 key is certified by a CA key that belongs
to Geotrust. The CA key is certified by Geotrust's root CA key.

The question is then how the user acquired a copy of the root CA
certificate. In many cases it was included with an operating system
that was already installed when the user bought the computer, much
like how the platform key for Secure Boot is already installed when the
user buys the computer. In other cases the root CA certificate came
with a browser or an OS that the user downloaded, perhaps in an
insecure way. We can't control this, so it may be considered a weak
link in the chain.

I'll agree that most users probably don't verify their DVD images as it
takes some manual work to do it properly, so that's another weak link,
but the possibility does exist for those of us who care enough about
our security. When Anaconda downloads packages, on the other hand, they
will often be transferred over insecure HTTP or FTP, and the user isn't
given a chance to verify them manually before they're installed.

The presence of one or two weak links in the chain is a very poor
excuse for omitting another link altogether.

Björn Persson


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

Re: Review swap

[Brendan Jones]

On 01/08/2013 08:16 PM, Yannick Brosseau wrote:

Hi,

I have one pending package review that I would like to swap:

babeltrace - Trace Viewer and Converter, mainly for the Common Trace
Format (LTTng)
https://bugzilla.redhat.com/show_bug.cgi?id=846488

Thanks,

Yannick


I'll take this if you can take this simple one on:

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


Thanks


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

Re: Proposed F19 Feature: NodeJS - The JavaScript runtime and associated ecosystem, including the npm package manager

[Miloslav Trmač]

On Tue, Jan 8, 2013 at 4:12 PM, Jaroslav Reznik  wrote:
> = Features/NodeJS =
> https://fedoraproject.org/wiki/Features/NodeJS

From Summary:
> The Node.js JavaScript runtime and associated ecosystem, including the npm 
> package manager.
Could you describe more detail the interaction of npm and rpm
packaging, please?  At least the "how to test" section suggests that
npm will be the preferred packaging mechanism, which is different from
how other language-specific packaging systems are treated.
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

GRUB2 packages, fedup

[Chris Murphy]

What package is responsible for writing the file /etc/default/grub? Because a 
prior EFI system with grub-efi, which of course doesn't have an 
/etc/default/grub, doesn't have it after a fedup upgrade, and still doesn't 
have it after manually installing either the grub2 or grub2-efi packages.

I do have /etc/grub.d/ files, which is part of one or both of those packages.

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

mactel boot revisited, updating to grub2

[Chris Murphy]

Fedora 17, EFI booting with grub-efi And then I used Fedup to update, which 
went fine, and still uses grub legacy efi.

To upgrade to grub2-efi, I partially figured out how to do this:

cp /boot/efi/EFI/fedora/grubx64.efi 
/boot/efi/EFI/System/Library/CoreServices/boot.efi
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Reboot now takes me to GRUB2, and loads the grub.cfg. However, at the point 
where nouveau loads, text scroll hangs at nouveau. I can blindly login and do 
some things, and ssh in. So I think it's vbios corruption again, and looks like 
this bug has rematerialized:

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

Since it's the same kernel and nouveau, this actually looks like a GRUB2 bug, 
not a nouveau bug. For whatever reason, even after installing the grub2-efi 
package, the command grub2-install does not produce a new grub.efi file 
anywhere I can find. The result I get is:

# grub2-install
/boot/efi doesn't look like an EFI partition.
Installation finished. No error reported.

Yet, there are no new files anywhere on the HFS+ EFI System partition, and 
NVRAM hasn't been updated either. If I specify an alternate --efi-directory= I 
can get a new grubx64.efi produced, relocate it, and update NVRAM, but it fails 
in the same manner.

I'm thinking for F18 the easiest thing to do might be a sidebar/note in the 
Fedup documentation that suggests Mac EFI boot users not upgrade grub-efi to 
grub2-efi. And then sort out the grub2-efi issues for Fedora 19.

Comments?

What's weird is a beta or early final TC, Live CD written direct to a USB 
stick, booted this same hardware to graphical Gnome without this problem. So 
I'm not sure what's going on.

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

Re: Systemtap and PHP? (was Re: Proposed F19 Feature: PHP 5.5 - To provide the latest PHP stack)

[David Malcolm]

On Tue, 2013-01-08 at 19:29 +0100, Remi Collet wrote:
> Le 08/01/2013 19:05, David Malcolm a écrit :
> > On Tue, 2013-01-08 at 10:34 -0500, Jaroslav Reznik wrote:
> > [...]
> >> = Features/Php55 =
> >> https://fedoraproject.org/wiki/Features/Php55
> > 
> > [...snip...]
> >> Dtrace enabled build 
> > 
> > As I understand it, Fedora has systemtap but not dtrace (/usr/bin/dtrace
> > is a shim to systemtap), so does this mean that *systemtap* static
> > probes will be available for use when tracing php?  If so, that sounds
> > great, but it would probably be best to spell that out on the feature
> > page.
> > 
> > I see docs on DTrace within PHP here:
> >   https://wiki.php.net/rfc/dtrace
> > 
> > This blog post has some information on PHP and Systemtap:
> > http://blog.experimentalworks.net/2012/12/probing-php-with-systemtap-on-linux/
> > 
> > Is that the kind of thing that this aspect of the feature is hoping to
> > add?  
> 
> Yes.
> 
> And, from my tests, the example given in the above link works as expected.

Excellent!

> > If so, it's probably worth adding a link like the above to the
> > feature page.
> 
> Please, add a proposal to the "feature discussion page" ;)

Added


Thanks
Dave

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

Review swap

[Yannick Brosseau]

Hi,

I have one pending package review that I would like to swap:

babeltrace - Trace Viewer and Converter, mainly for the Common Trace
Format (LTTng)
https://bugzilla.redhat.com/show_bug.cgi?id=846488

Thanks,

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

Re: Systemtap and PHP? (was Re: Proposed F19 Feature: PHP 5.5 - To provide the latest PHP stack)

[David Malcolm]

On Tue, 2013-01-08 at 19:23 +0100, Tomasz Torcz wrote:
> On Tue, Jan 08, 2013 at 01:05:39PM -0500, David Malcolm wrote:
> > On Tue, 2013-01-08 at 10:34 -0500, Jaroslav Reznik wrote:
> > [...]
> > > = Features/Php55 =
> > > https://fedoraproject.org/wiki/Features/Php55
> > 
> > [...snip...]
> > > Dtrace enabled build 
> > 
> > As I understand it, Fedora has systemtap but not dtrace (/usr/bin/dtrace
> > is a shim to systemtap), so does this mean that *systemtap* static
> > probes will be available for use when tracing php?  If so, that sounds
> > great, but it would probably be best to spell that out on the feature
> > page.
> 
>   Systemtap is able to use dtrace probes, se the detailed desc. here:
> https://fedoraproject.org/wiki/Features/SystemtapStaticProbes#Detailed_Description

Yes - we did something similar for Python a while back [1] - but a
casual reader of the PHP 5.5 feature page wouldn't know this, or know
what it means, which is why I mentioned it.

[1]
https://fedoraproject.org/wiki/Features/SystemtapStaticProbes#Python_2

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

Re: Systemtap and PHP? (was Re: Proposed F19 Feature: PHP 5.5 - To provide the latest PHP stack)

[Remi Collet]

Le 08/01/2013 19:05, David Malcolm a écrit :
> On Tue, 2013-01-08 at 10:34 -0500, Jaroslav Reznik wrote:
> [...]
>> = Features/Php55 =
>> https://fedoraproject.org/wiki/Features/Php55
> 
> [...snip...]
>> Dtrace enabled build 
> 
> As I understand it, Fedora has systemtap but not dtrace (/usr/bin/dtrace
> is a shim to systemtap), so does this mean that *systemtap* static
> probes will be available for use when tracing php?  If so, that sounds
> great, but it would probably be best to spell that out on the feature
> page.
> 
> I see docs on DTrace within PHP here:
>   https://wiki.php.net/rfc/dtrace
> 
> This blog post has some information on PHP and Systemtap:
> http://blog.experimentalworks.net/2012/12/probing-php-with-systemtap-on-linux/
> 
> Is that the kind of thing that this aspect of the feature is hoping to
> add?  

Yes.

And, from my tests, the example given in the above link works as expected.


> If so, it's probably worth adding a link like the above to the
> feature page.

Please, add a proposal to the "feature discussion page" ;)

Remi.


> 
> Thanks; hope this is helpful
> Dave
> 

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

Re: Systemtap and PHP? (was Re: Proposed F19 Feature: PHP 5.5 - To provide the latest PHP stack)

[Tomasz Torcz]

On Tue, Jan 08, 2013 at 01:05:39PM -0500, David Malcolm wrote:
> On Tue, 2013-01-08 at 10:34 -0500, Jaroslav Reznik wrote:
> [...]
> > = Features/Php55 =
> > https://fedoraproject.org/wiki/Features/Php55
> 
> [...snip...]
> > Dtrace enabled build 
> 
> As I understand it, Fedora has systemtap but not dtrace (/usr/bin/dtrace
> is a shim to systemtap), so does this mean that *systemtap* static
> probes will be available for use when tracing php?  If so, that sounds
> great, but it would probably be best to spell that out on the feature
> page.

  Systemtap is able to use dtrace probes, se the detailed desc. here:
https://fedoraproject.org/wiki/Features/SystemtapStaticProbes#Detailed_Description

-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.

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

Re: Proposed F19 Feature: Package Signature Checking During Installation

[Peter Jones]

On Tue, Jan 08, 2013 at 11:04:30AM -0500, Steve Clark wrote:
>
> What about repins? I want to add my own custom package that is not signed and 
> create a new CD with a custom ks.cfg.
> How would that work?

You'd generate your own key, and people using your packages, who have
presumably decided they trust that you're really you through some other
method, would enrol your key in the MoK list on the machine.  Alternately
you can pay $99 (one time only) and get your keys signed by something the
machine already trusts.  I'll write more thorough documentation on each of
the processes to do these as this moves forward.

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

Systemtap and PHP? (was Re: Proposed F19 Feature: PHP 5.5 - To provide the latest PHP stack)

[David Malcolm]

On Tue, 2013-01-08 at 10:34 -0500, Jaroslav Reznik wrote:
[...]
> = Features/Php55 =
> https://fedoraproject.org/wiki/Features/Php55

[...snip...]
> Dtrace enabled build 

As I understand it, Fedora has systemtap but not dtrace (/usr/bin/dtrace
is a shim to systemtap), so does this mean that *systemtap* static
probes will be available for use when tracing php?  If so, that sounds
great, but it would probably be best to spell that out on the feature
page.

I see docs on DTrace within PHP here:
  https://wiki.php.net/rfc/dtrace

This blog post has some information on PHP and Systemtap:
http://blog.experimentalworks.net/2012/12/probing-php-with-systemtap-on-linux/

Is that the kind of thing that this aspect of the feature is hoping to
add?  If so, it's probably worth adding a link like the above to the
feature page.

Thanks; hope this is helpful
Dave

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

Re: Proposed F19 Feature: Package Signature Checking During Installation

[Peter Jones]

On Tue, Jan 08, 2013 at 05:46:04PM +0100, Björn Persson wrote:
> > One long-standing problem in Fedora is that we don't check package 
> > signatures
> > during installation.
> [...]
> > Following the implementation of Features/SecureBoot, we can extend the 
> > Secure
> > Boot keys as a root of trust provided by the hardware against which we can
> > verify a signature on our key files, thus guaranteeing that they're from the
> > same source as the boot media. 
> 
> It's great that someone is finally trying to do something about bug 998,
> but what's the plan for computers without Secure Boot? Will Anaconda
> disable all signature checking if Secure Boot is disabled or
> unavailable, or will it check as much as it can?

I'm not planning to do anything other than what we're doing now if
Secure Boot isn't enabled.

> In my opinion, if Anaconda finds that it was booted without Secure
> Boot, then it should assume that the user has verified the checksum on
> the installation image and that the keys therein are therefore trusted,
> and use those keys to verify any packages it downloads.

Feel free to submit a feature for this and patches for it if you feel
it's appropriate to do so.  I don't happen to think it is, so I'm not
going to.

> It's enough to verify downloaded packages in that case. Packages
> included on the boot medium don't need to be checked if the boot medium
> is trusted, but of course it doesn't hurt to verify those too if it's
> easier to program that way.

It's hard to figure out how these are more trustable than downloaded
packages, given that using boot media that wasn't downloaded is a very
rare way to install Fedora.

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

Re: Proposed F19 Feature: Package Signature Checking During Installation

[Björn Persson]

> One long-standing problem in Fedora is that we don't check package signatures
> during installation.
[...]
> Following the implementation of Features/SecureBoot, we can extend the Secure
> Boot keys as a root of trust provided by the hardware against which we can
> verify a signature on our key files, thus guaranteeing that they're from the
> same source as the boot media. 

It's great that someone is finally trying to do something about bug 998,
but what's the plan for computers without Secure Boot? Will Anaconda
disable all signature checking if Secure Boot is disabled or
unavailable, or will it check as much as it can?

In my opinion, if Anaconda finds that it was booted without Secure
Boot, then it should assume that the user has verified the checksum on
the installation image and that the keys therein are therefore trusted,
and use those keys to verify any packages it downloads.

It's enough to verify downloaded packages in that case. Packages
included on the boot medium don't need to be checked if the boot medium
is trusted, but of course it doesn't hurt to verify those too if it's
easier to program that way.

Björn Persson


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

Re: libcdio 0.90 update in rawhide

[Kevin Fenzi]

On Tue, 8 Jan 2013 17:28:18 +0100
Adrian Reber  wrote:

> I tried to do all rebuilds yesterday after the rawhide report. I
> missed pragha which is building right now. There were no broken
> dependencies over a few days. Just today from the packages rebuilt
> too late.

Ah, ok. 

pragha was the one I hit actually. ;) 

Thanks for rebuilding them. 

kevin


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

Red Hat QXL GPU Driver for Windows 7?

[Jeffrey Ollie]

When I powered up the Windows 7 guest that I have on my Fedora 18 system at
work, it wanted to install a driver for a "Red Hat QXL GPU" device.
Googling didn't turn up anything definitive but I'm wondering if this is an
early result of:

http://fedoraproject.org/wiki/Features/QXLKMSSupport

Is there someplace to get updated video drivers for Windows 7?

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

Re: libcdio 0.90 update in rawhide

[Adrian Reber]

On Tue, Jan 08, 2013 at 09:03:58AM -0700, Kevin Fenzi wrote:
> On Tue, 4 Dec 2012 20:22:18 +0100
> Adrian Reber  wrote:
> 
> > Some weeks ago libcdio 0.90 has been released. In addition to the
> > libcdio-0.90 release there have been parts split off into a separate
> > package called libcdio-paranoia. libcdio-paranoia has been imported
> > and I will now also update libcdio to 0.90 in rawhide. I will rebuild
> > all dependencies over the next few days and adjust the depending
> > packages to require both libraries where necessary.
> 
> Is there any particular reason the rebuilds couldn't have been done in
> the same day as the libcdio update? That would have prevented broken
> deps over a few days... 

I tried to do all rebuilds yesterday after the rawhide report. I missed
pragha which is building right now. There were no broken dependencies
over a few days. Just today from the packages rebuilt too late.

Adrian


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

Re: Proposed F19 Feature: NodeJS - The JavaScript runtime and associated ecosystem, including the npm package manager

[Jóhann B. Guðmundsson]

On 01/08/2013 03:59 PM, Stephen Gallagher wrote:

On 01/08/2013 10:40 AM, Adrian Alves wrote:

why am not in https://fedoraproject.org/wiki/Features/NodeJS If i was
the first one on start with NODEJS package



The list of people on that page is volunteer-added. If you would like 
to help on this, please feel free to add your name to the list. If you 
do so, you're committing to helping to make sure the package makes is 
into Fedora 19.


I couldn't find you to ask when I was setting up that page. We're 
happy to have your help.


I thought Lubomir Rintel a.k.a lkundrak had been working on this [1]?

Was he not contacted either?

JBG

1. http://fedoraproject.org/wiki/User:Lkundrak/NodeJS
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Package Signature Checking During Installation

[Steve Clark]

On 01/08/2013 10:55 AM, Peter Jones wrote:

On Tue, Jan 08, 2013 at 03:52:02PM +, Petr Pisar wrote:

On 2013-01-08, Jaroslav Reznik  wrote:

= Features/PackageSignatureCheckingDuringInstall =
https://fedoraproject.org/wiki/Features/PackageSignatureCheckingDuringInstall

* Detailed description:
One long-standing problem in Fedora is that we don't check package signatures
during installation. This has been a persistent issue since the very beginning
of Fedora (and even in Red Hat Linux before it.) The reason for this has
always been that there's no way to form any root of trust for the signatures
in the repositories, and thus no reason they wouldn't have been modified along
with whatever package would need to be re-signed after tampering.


Reading till here makes me pondering how's possible rpm does not check
package signature.


Following the implementation of Features/SecureBoot, we can extend the Secure
Boot keys as a root of trust provided by the hardware against which we can
verify a signature on our key files, thus guaranteeing that they're from the
same source as the boot media.


Now it's clear it's about insttalling distribution. Not about installing
a package with rpm in general.

Could reponsible person change title and abstract to be clear it's about
_distribution_ installation?

Sure thing.

It's now at
https://fedoraproject.org/wiki/Features/PackageSignatureCheckingDuringOSInstall
, and the title and description have been changed to match that.



What about repins? I want to add my own custom package that is not signed and 
create a new CD with a custom ks.cfg.
How would that work?

Thanks,


--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: libcdio 0.90 update in rawhide

[Kevin Fenzi]

On Tue, 4 Dec 2012 20:22:18 +0100
Adrian Reber  wrote:

> 
> Some weeks ago libcdio 0.90 has been released. In addition to the
> libcdio-0.90 release there have been parts split off into a separate
> package called libcdio-paranoia. libcdio-paranoia has been imported
> and I will now also update libcdio to 0.90 in rawhide. I will rebuild
> all dependencies over the next few days and adjust the depending
> packages to require both libraries where necessary.

Is there any particular reason the rebuilds couldn't have been done in
the same day as the libcdio update? That would have prevented broken
deps over a few days... 

kevin


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

Re: Proposed F19 Feature: NodeJS - The JavaScript runtime and associated ecosystem, including the npm package manager

[Stephen Gallagher]

On 01/08/2013 10:40 AM, Adrian Alves wrote:

why am not in https://fedoraproject.org/wiki/Features/NodeJS If i was
the first one on start with NODEJS package



The list of people on that page is volunteer-added. If you would like to 
help on this, please feel free to add your name to the list. If you do 
so, you're committing to helping to make sure the package makes is into 
Fedora 19.


I couldn't find you to ask when I was setting up that page. We're happy 
to have your help.

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

Re: Proposed F19 Feature: Package Signature Checking During Installation

[Peter Jones]

On Tue, Jan 08, 2013 at 03:52:02PM +, Petr Pisar wrote:
> On 2013-01-08, Jaroslav Reznik  wrote:
> >
> >= Features/PackageSignatureCheckingDuringInstall =
> > https://fedoraproject.org/wiki/Features/PackageSignatureCheckingDuringInstall
> >
> > * Detailed description:
> > One long-standing problem in Fedora is that we don't check package 
> > signatures
> > during installation. This has been a persistent issue since the very 
> > beginning
> > of Fedora (and even in Red Hat Linux before it.) The reason for this has 
> > always been that there's no way to form any root of trust for the signatures
> > in the repositories, and thus no reason they wouldn't have been modified 
> > along
> > with whatever package would need to be re-signed after tampering.
> >
> Reading till here makes me pondering how's possible rpm does not check
> package signature.
> 
> > Following the implementation of Features/SecureBoot, we can extend the 
> > Secure
> > Boot keys as a root of trust provided by the hardware against which we can
> > verify a signature on our key files, thus guaranteeing that they're from the
> > same source as the boot media. 
> >
> Now it's clear it's about insttalling distribution. Not about installing
> a package with rpm in general.
> 
> Could reponsible person change title and abstract to be clear it's about
> _distribution_ installation?

Sure thing.

It's now at
https://fedoraproject.org/wiki/Features/PackageSignatureCheckingDuringOSInstall
, and the title and description have been changed to match that.

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

Re: Proposed F19 Feature: Package Signature Checking During Installation

[Petr Pisar]

On 2013-01-08, Jaroslav Reznik  wrote:
>
>= Features/PackageSignatureCheckingDuringInstall =
> https://fedoraproject.org/wiki/Features/PackageSignatureCheckingDuringInstall
>
> * Detailed description:
> One long-standing problem in Fedora is that we don't check package signatures
> during installation. This has been a persistent issue since the very beginning
> of Fedora (and even in Red Hat Linux before it.) The reason for this has 
> always been that there's no way to form any root of trust for the signatures
> in the repositories, and thus no reason they wouldn't have been modified along
> with whatever package would need to be re-signed after tampering.
>
Reading till here makes me pondering how's possible rpm does not check
package signature.

> Following the implementation of Features/SecureBoot, we can extend the Secure
> Boot keys as a root of trust provided by the hardware against which we can
> verify a signature on our key files, thus guaranteeing that they're from the
> same source as the boot media. 
>
Now it's clear it's about insttalling distribution. Not about installing
a package with rpm in general.

Could reponsible person change title and abstract to be clear it's about
_distribution_ installation?

-- Petr

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

Re: Proposed F19 Feature: NodeJS - The JavaScript runtime and associated ecosystem, including the npm package manager

[Adrian Alves]

why am not in https://fedoraproject.org/wiki/Features/NodeJS If i was the
first one on start with NODEJS package


On Tue, Jan 8, 2013 at 12:40 PM, Adrian Alves  wrote:

> why am not in https://fedoraproject.org/wiki/Features/NodeJS If i was the
> first one on start with NODEJS package
>
>
> On Tue, Jan 8, 2013 at 12:12 PM, Jaroslav Reznik wrote:
>
>> As decided by FESCo on 2012-12-05 meeting, all proposed Features are
>> required
>> to pass through the community review by announcing them on devel-announce
>> list.
>> FESCo votes on new features no sooner than a week from the announcement.
>>
>> = Features/NodeJS =
>> https://fedoraproject.org/wiki/Features/NodeJS
>>
>> * Detailed description:
>> Node.js is a platform built on Chrome's JavaScript runtime for easily
>> building
>> fast, scalable network applications. Node.js uses an event-driven,
>> non-blocking
>> I/O model that makes it lightweight and efficient, perfect for
>> data-intensive
>> real-time applications that run across distributed devices.
>>
>> Jaroslav
>>
>> ___
>> 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
>
>
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: NodeJS - The JavaScript runtime and associated ecosystem, including the npm package manager

[Adrian Alves]

why am not in https://fedoraproject.org/wiki/Features/NodeJS If i was the
first one on start with NODEJS package


On Tue, Jan 8, 2013 at 12:12 PM, Jaroslav Reznik  wrote:

> As decided by FESCo on 2012-12-05 meeting, all proposed Features are
> required
> to pass through the community review by announcing them on devel-announce
> list.
> FESCo votes on new features no sooner than a week from the announcement.
>
> = Features/NodeJS =
> https://fedoraproject.org/wiki/Features/NodeJS
>
> * Detailed description:
> Node.js is a platform built on Chrome's JavaScript runtime for easily
> building
> fast, scalable network applications. Node.js uses an event-driven,
> non-blocking
> I/O model that makes it lightweight and efficient, perfect for
> data-intensive
> real-time applications that run across distributed devices.
>
> Jaroslav
>
> ___
> 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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Proposed F19 Feature: PHP 5.5 - To provide the latest PHP stack

[Jaroslav Reznik]

As decided by FESCo on 2012-12-05 meeting, all proposed Features are required
to pass through the community review by announcing them on devel-announce list.
FESCo votes on new features no sooner than a week from the announcement.

= Features/Php55 =
https://fedoraproject.org/wiki/Features/Php55

* Detailed description:
To provide the latest PHP stack

Upstream roadmap (see TODO)

- PHP 5.5.0alpha1 is released (Nov 22th)
- PHP 5.5.0alpha2 is released (Dec 18th)
- PHP 5.5.0beta is planed for January (feature freeze) 

Finale version (Q1/2013) should be available before fedora 19 (Q2/2013).

Planed packaging changes

Build more extensions shared for flexibility

- in php-common: bz2, calendar, ctype, exif, ftp, gettext, iconv, sockets 
and tokenizer
- moved in php-gmp: gmp
- moved in php-process: shmop
- moved in php-xml: xml and simplexml 

Dtrace enabled build 

Jaroslav
___
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

Proposed F19 Feature: Package Signature Checking During Installation

[Jaroslav Reznik]

As decided by FESCo on 2012-12-05 meeting, all proposed Features are required
to pass through the community review by announcing them on devel-announce list.
FESCo votes on new features no sooner than a week from the announcement.

= Features/PackageSignatureCheckingDuringInstall =
https://fedoraproject.org/wiki/Features/PackageSignatureCheckingDuringInstall

* Detailed description:
One long-standing problem in Fedora is that we don't check package signatures
during installation. This has been a persistent issue since the very beginning
of Fedora (and even in Red Hat Linux before it.) The reason for this has 
always been that there's no way to form any root of trust for the signatures
in the repositories, and thus no reason they wouldn't have been modified along
with whatever package would need to be re-signed after tampering.

Following the implementation of Features/SecureBoot, we can extend the Secure
Boot keys as a root of trust provided by the hardware against which we can
verify a signature on our key files, thus guaranteeing that they're from the
same source as the boot media. 

Jaroslav
___
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

Proposed F19 Feature: NodeJS - The JavaScript runtime and associated ecosystem, including the npm package manager

[Jaroslav Reznik]

As decided by FESCo on 2012-12-05 meeting, all proposed Features are required
to pass through the community review by announcing them on devel-announce list.
FESCo votes on new features no sooner than a week from the announcement.

= Features/NodeJS =
https://fedoraproject.org/wiki/Features/NodeJS

* Detailed description:
Node.js is a platform built on Chrome's JavaScript runtime for easily building
fast, scalable network applications. Node.js uses an event-driven, non-blocking
I/O model that makes it lightweight and efficient, perfect for data-intensive
real-time applications that run across distributed devices. 

Jaroslav

___
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

Proposed F19 Feature: NetworkManagerCLIAddConnection - support for adding new NetworkManager connections using the nmcli commandline tool

[Jaroslav Reznik]

As decided by FESCo on 2012-12-05 meeting, all proposed Features are required
to pass through the community review by announcing them on devel-announce list.
FESCo votes on new features no sooner than a week from the announcement.

= Features/NetworkManagerCLIAddConnection =
https://fedoraproject.org/wiki/Features/NetworkManagerCLIAddConnection

* Detailed description:
Administrators will be able to configure new connections via a simple 
command-line interface. It will be possible to create and activate new 
connections, as well as delete them.

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

[Test-Announce] Fedora 18 Go/No-Go Meeting, Wednesday, January 09 @ 19:00 UTC (2pm Eastern, 11am Pacific)

[Jaroslav Reznik]

Join us on irc.freenode.net in #fedora-meeting-2 for this important
meeting, wherein we shall determine the readiness of the Fedora 18.

Wednesday, January 09, 2013 @19:00 UTC (14:00 EST/11:00 PST/20:00 CET)

Due to conflicts in Meeting IRC channel and to give us the flexibility
to have as long Go/No-Go as possible - we have to use #fedora-meeting-2
channel this time!

"Before each public release Development, QA and Release Engineering meet
to determine if the release criteria are met for a particular release.
This meeting is called the Go/No-Go Meeting."

"Verifying that the Release criteria are met is the responsibility of
the QA Team."

For more details about this meeting see:
https://fedoraproject.org/wiki/Go_No_Go_Meeting

In the meantime, keep an eye on the Fedora 18 Final Blocker list:
http://qa.fedoraproject.org/blockerbugs/milestone/18/final/buglist

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

F-18 Branched report: 20130108 changes

[Fedora Branched Report]

Compose started at Tue Jan  8 09:15:31 UTC 2013








Summary:
Added Packages: 0
Removed Packages: 0
Upgraded Packages: 0
Compose finished at Tue Jan  8 13:41:04 UTC 2013

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

File IO-Compress-2.060.tar.gz uploaded to lookaside cache by pghmcfc

[Paul Howarth]

A file has been added to the lookaside cache for perl-IO-Compress:

346a1c981930f7cab54a4973480b3c73  IO-Compress-2.060.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 871442] Broken configuration for httpd 2.4

[bugzilla]

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=871442

--- Comment #4 from Remi Collet  ---

> The patch does not apply. 

This patch doesn't apply on the installed config.
It apply on the upstream provided config (in the source tarball).
The spec then alter it (using perl/sed, in %prep)

+ echo 'Patch #0 (netdisco-httpd24.patch):'
Patch #0 (netdisco-httpd24.patch):
+ /usr/bin/patch -p0 --fuzz=0
+ /usr/bin/cat /home/fedora/git/netdisco/netdisco-httpd24.patch
patching file netdisco_apache_dir.conf
patching file netdisco_apache.conf
...

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

[Bug 892918] perl-IO-Compress-2.060 is available

[bugzilla]

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=892918

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|mmasl...@redhat.com |ppi...@redhat.com
   Assignee|mmasl...@redhat.com |ppi...@redhat.com

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

Re: libcdio 0.90 update in rawhide

[Adrian Reber]

On Tue, Dec 04, 2012 at 08:22:18PM +0100, Adrian Reber wrote:
> Some weeks ago libcdio 0.90 has been released. In addition to the
> libcdio-0.90 release there have been parts split off into a separate
> package called libcdio-paranoia. libcdio-paranoia has been imported and
> I will now also update libcdio to 0.90 in rawhide. I will rebuild all
> dependencies over the next few days and adjust the depending packages to
> require both libraries where necessary.

I have updated libcdio in rawhide to 0.90 and rebuilt all dependencies.
There were two failures due to API changes:

audacious-plugins - 
http://kojipkgs.fedoraproject.org//work/tasks/7809/4847809/build.log
kover - same problem (cdtext related)

and one libcdio unrelated failure:

clementine -  'void g_type_init()' is deprecated
  
http://koji.fedoraproject.org/koji/getfile?taskID=4846211&name=build.log


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

Re: GRUB menu hidden by default?

[Kamil Paral]

> Here's what our policies say:
> 
> https://fedoraproject.org/wiki/Packaging:Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment
> 
> "All patches should have an upstream bug link or comment
> 
> All patches in Fedora spec files SHOULD have a comment above them
> about
> their upstream status. Any time you create a patch, it is best
> practice
> to file it in an upstream bug tracker, and include a link to that in
> the
> comment above the patch."
> 
> This is based on (and links to)
> https://fedoraproject.org/wiki/Staying_close_to_upstream_projects :
> 
> "The Fedora Project focuses, as much as possible, on not deviating
> from
> upstream in the software it includes in the repository. The following
> guidelines are a general set of best practices, and provide reasons
> why
> this is a good idea, tips for sending your patches upstream, and
> potential exceptions Fedora might make. The primary goal is to share
> the
> benefits of a common codebase for end users and developers while
> simultaneously reducing unnecessary maintenance efforts."
> 
> i.e., we try to avoid carrying patches permanently downstream, except
> in
> cases where we obviously have to patch something which it would not
> be
> appropriate to upstream (say, adding a Fedora logo to the login
> screen,
> or something).

Actually there are cases where upstream intentionally provides something 
configurable, and it has to pick one of the options as the default one, but 
that doesn't mean it _insists_ on it. The purpose of having it configurable 
(not hard-coded) is for distributions to adjust it as they see fit.

So while this 'close to upstream' approach makes sense when it comes to 
patching source code, it may not make much sense when it comes to patching 
default options in configuration files or various templates.

My comment is not related to GRUB, I haven't studied the issue closely and I 
don't know which of the cases is it. I just wanted to comment on the principle 
you cited.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 18: WebApp and httpd 2.4 configuration

[Jóhann B. Guðmundsson]

On 01/08/2013 03:48 AM, Miloslav Trmač wrote:

On Tue, Jan 8, 2013 at 4:31 AM, Adam Williamson  wrote:

On Tue, 2013-01-08 at 03:06 +, "Jóhann B. Guðmundsson" wrote:

So the remaining webapps that ship with the broken configuration that we
are about to release into the hands our our enduser base and how they
should be handled are not considered high-level technical decision?

What is the decision to be made? "Do we fix them"? Obviously yes.

("Obviously"?  Per which release blocker criterion?)

The way I understand Jóhann, the topic to escalate was a proposed
removal of currently unorphaned packages from the distribution, which
sounds like a quite reasonable topic for FESCo.


Yes


Such an escalation wouldn't fix F18, true.


This may come as an completely stupid question but given that we have 
not released yet why cant we remove those packages?


Surely we must have some kind of "omg we cant release with this 
component in final it's utterly broken or posses security risk!" fail 
safe mechanism in place to deal with this?



In retrospect, the update to httpd 2.4 should probably have been a
feature; that would make this problem visible by beta free


Remi had brought up the topic here on devel in due time and had compiled 
that list sometime in our beta slippery slope if I'm not mistaken.



   FESCo
already has "fixing features" on the agenda in a general sense, more
thoughts on how to improve the process would definitely be welcome.



This is is not happening because of lack of communication or people did 
not know, it's happening because people did not react thus fixing 
unresponsive maintainers is more closer to the point or rather coming up 
with having a rock solid cleanup process.


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

[Test-Announce] Fedora 18 Final Release Candidate 2 (RC2) Available Now!

[Andre Robatino]

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

Installation:

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

Base:

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

Desktop:

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

Security Lab:

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

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

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

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

[1] http://jreznik.fedorapeople.org/schedules/f-18/f-18-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Installation_validation_testing
[3] https://fedoraproject.org/wiki/QA:Base_validation_testing
[4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing
[5] https://fedoraproject.org/wiki/QA:Security_Lab_validation_testing
[6] https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria
[7] irc://irc.freenode.net/fedora-qa
[8] https://admin.fedoraproject.org/mailman/listinfo/test



signature.asc
Description: OpenPGP digital signature
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel