date:20120228

On Wed, 2012-02-29 at 00:22 -0700, Chris Murphy wrote:
> On Feb 29, 2012, at 12:09 AM, Adam Williamson wrote:
> 
> > On Tue, 2012-02-28 at 23:30 -0700, Chris Murphy wrote:
> >> On Feb 28, 2012, at 11:21 PM, Adam Williamson wrote:
> >>> 
> >>> I suppose it might be interesting to see if grub2-efi works any
> >>> better...
> >> 
> >> It's been a year since I've tested it so it needs to be retested. But I do 
> >> know that doesn't fix bug 765954, so the machine is, for me, functionally 
> >> useless as a laptop with just a text console.
> >> 
>  5.
>  At reboot/poweroff time, there's a LOT of extra "garbage" information 
>  being produced on-screen compared to F16. It goes by quick enough and 
>  isn't logged, so I'm not sure if it's important. But I do get a reboot, 
>  albeit with about a 1 minute delay over F16.
> >>> 
> >>> I suspect 'yum install plymouth' may help with that.
> >> 
> >> With rhgb and quiet disabled on F16 and F17, so plymouth is a non-factor.
> > 
> > that doesn't actually disable plymouth, it's still involved.
> 
> ok i don't get the fedora logo splash at shutdown in any event.

yup, but IIRC ray's told me that plymouth is actually still involved in
rendering the 'text' output you get if you take out rhgb from the
parameters. I think there is a parameter you can pass to entirely
disable plymouth, but I forget what it is.
-- 
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

Re: F17, Apple, EFI boot, livecd-tools


On Feb 29, 2012, at 12:09 AM, Adam Williamson wrote:

> On Tue, 2012-02-28 at 23:30 -0700, Chris Murphy wrote:
>> On Feb 28, 2012, at 11:21 PM, Adam Williamson wrote:
>>> 
>>> I suppose it might be interesting to see if grub2-efi works any
>>> better...
>> 
>> It's been a year since I've tested it so it needs to be retested. But I do 
>> know that doesn't fix bug 765954, so the machine is, for me, functionally 
>> useless as a laptop with just a text console.
>> 
 5.
 At reboot/poweroff time, there's a LOT of extra "garbage" information 
 being produced on-screen compared to F16. It goes by quick enough and 
 isn't logged, so I'm not sure if it's important. But I do get a reboot, 
 albeit with about a 1 minute delay over F16.
>>> 
>>> I suspect 'yum install plymouth' may help with that.
>> 
>> With rhgb and quiet disabled on F16 and F17, so plymouth is a non-factor.
> 
> that doesn't actually disable plymouth, it's still involved.

ok i don't get the fedora logo splash at shutdown in any event.

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

Re: F17, Apple, EFI boot, livecd-tools

On Tue, 2012-02-28 at 23:30 -0700, Chris Murphy wrote:
> On Feb 28, 2012, at 11:21 PM, Adam Williamson wrote:
> > 
> > I suppose it might be interesting to see if grub2-efi works any
> > better...
> 
> It's been a year since I've tested it so it needs to be retested. But I do 
> know that doesn't fix bug 765954, so the machine is, for me, functionally 
> useless as a laptop with just a text console.
> 
> >> 5.
> >> At reboot/poweroff time, there's a LOT of extra "garbage" information 
> >> being produced on-screen compared to F16. It goes by quick enough and 
> >> isn't logged, so I'm not sure if it's important. But I do get a reboot, 
> >> albeit with about a 1 minute delay over F16.
> > 
> > I suspect 'yum install plymouth' may help with that.
> 
> With rhgb and quiet disabled on F16 and F17, so plymouth is a non-factor.

that doesn't actually disable plymouth, it's still involved.
-- 
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

Re: F17, Apple, EFI boot, livecd-tools

On Feb 28, 2012, at 11:21 PM, Adam Williamson wrote:
> 
> I suppose it might be interesting to see if grub2-efi works any
> better...

It's been a year since I've tested it so it needs to be retested. But I do know 
that doesn't fix bug 765954, so the machine is, for me, functionally useless as 
a laptop with just a text console.

>> 5.
>> At reboot/poweroff time, there's a LOT of extra "garbage" information being 
>> produced on-screen compared to F16. It goes by quick enough and isn't 
>> logged, so I'm not sure if it's important. But I do get a reboot, albeit 
>> with about a 1 minute delay over F16.
> 
> I suspect 'yum install plymouth' may help with that.

With rhgb and quiet disabled on F16 and F17, so plymouth is a non-factor. I 
just get a lot (like probably 10+ screenfulls) of repetitive text that scrolls 
by very quickly with F17. This comes after the unmounting of filesystems 
sequence, where as on F16 the computer shuts down. This only happens on actual 
hardware, in VM, I'm not seeing much of a difference.

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

Re: "master" branch still invokes build in f17-candidate??

Mathieu Bridon wrote:
> I would certainly be very confused if `fedpkg mockbuild` produced a f17
> rpm but `fedpkg build` produced an f18 one.

"build" is the common case and should always work; srpm, mockbuild etc. are 
extras, I don't care if they break.

Kevin Kofler

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

Re: F17, Apple, EFI boot, livecd-tools

On Tue, 2012-02-28 at 16:36 -0700, Chris Murphy wrote:
> Following applies to a 2008, Macbook Pro 4,1
> 
> 1.
> Used livecd-tools-17.6-1.fc17 to successfully create an EFI bootable USB 
> stick of Fedora-17-Alpha-x86_64-Live-Desktop.iso.
> 
> 2.
> Due to this bug: EFI boot fails on Macs with NVIDIA GeForce 8600M GT
> https://bugzilla.redhat.com/show_bug.cgi?id=751147
> 
> I add 'nomodeset' kernel parameter. I know of no work around to get a GUI on 
> this hardware. But it does boot kernel and most services.
> 
> 3.
> tty1 hangs at "Started Display Manager"
> tty2 is functional, not sure how to get any information on what's up with 
> tty1. Normally what I'm used to with EFI boot and nomodeset is X can't 
> actually startup, but the rest of the services load, and I end up at a prompt.
> 
> 4.
> Out of 5 boot attempts, I get to a usable tty2 console and can reboot thrice.
> 
> Twice, I get a hang right after GRUB loads either the kernel or initrd, the 
> GRUB splash screen is present with no text. The machine has hung and I have 
> to hold the power button to shut down.
> 
> So on this hardware I'd say GRUB is marginally reliable.

I suppose it might be interesting to see if grub2-efi works any
better...

> 5.
> At reboot/poweroff time, there's a LOT of extra "garbage" information being 
> produced on-screen compared to F16. It goes by quick enough and isn't logged, 
> so I'm not sure if it's important. But I do get a reboot, albeit with about a 
> 1 minute delay over F16.

I suspect 'yum install plymouth' may help with that.

In F16, dracut required plymouth, and dracut is in @core, so plymouth
got pulled into any install. In F17, dracut doesn't require plymouth any
more, and this is desired. So for Alpha I stuck plymouth into comps, but
I only put it into @base, not @core. Minimal installations don't install
@base, they install @core. If you do a text mode installation, you get a
minimal install, hence no plymouth.

I'm not entirely sure what we want to do about this for Beta - whether
we want to put plymouth in @core, or what.
-- 
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

Re: F17 x86_64 composes

On Tue, 2012-02-28 at 16:37 -0600, Mike Chambers wrote:
> Noticed that x86_64 tree is still NOT installable, as in no boot.iso or
> anything.  Is this going to remain that way for awhile?

Is there a reason you can't use the Alpha boot.iso?
-- 
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

Re: F17 x86_64 composes

2012-02-28 Thread Kevin Fenzi

On Tue, 28 Feb 2012 16:37:50 -0600
Mike Chambers  wrote:

> Noticed that x86_64 tree is still NOT installable, as in no boot.iso
> or anything.  Is this going to remain that way for awhile?

Well, it's going to stay that way until the bug that prevents it
working is fixed. :) 

It seems no one has reported the bug, so I did: 

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

kevin


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

Re: "master" branch still invokes build in f17-candidate??

2012-02-28 Thread Mathieu Bridon

On Wed, 2012-02-29 at 05:31 +0100, Kevin Kofler wrote:
> Tom Lane wrote:
> 
> > Kevin Kofler  writes:
> >> VÃt Ondruch wrote:
> >>> If you say to Koji that it should checkout master at remote machine,
> >>> build a SRPM etc, why the Koji can't determine the proper %{?dist} at
> >>> remote machine? Why it takes the %{?dist} from local machine instead? It
> >>> makes no sense. It might work for other branches, but master is bit
> >>> different, so it should be handled differently.
> > 
> >> Yes, for fedpkg build, the client should not have to care about what
> >> %{?dist} is at all. It should just ask Koji to build the current git hash
> >> in Rawhide and that's it.
> > 
> > Nope, it's not that easy, as some purely-local operations (eg "fedpkg
> > srpm") also want to know the dist tag.
> 
> Those operations can use Jesse's heuristics, but there's no good reason to 
> use them for fedpkg build.

I would certainly be very confused if `fedpkg mockbuild` produced a f17
rpm but `fedpkg build` produced an f18 one.


-- 
Mathieu


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

Re: Clarify our position on forks

2012-02-28 Thread Ralf Corsepius


On 02/27/2012 02:14 PM, Stephen Gallagher wrote:

On Mon, 2012-02-27 at 08:07 +0100, Thorsten Leemhuis wrote:

Kevin Fenzi wrote on 27.02.2012 04:21:


#topic #810 Clarify our position on forks .fesco 810


It's just a statement that is asked for in the ticket, but nevertheless:
Shouldn't issues like this be discussed on this list first, so FESCo
members can get a impression from the flamewar ^w discussion what the
developer community thinks about the issue raised?



Personally, my stance on this is that, provided that the forks are
properly renamed such that they will not conflict with other forks of
the same codebase, there's no reason to disallow them.
ACK. The fact "forks are forks" or even more general the "origin of a 
package" should be irrelevant. They should be treated like any other 
arbitrary package.


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

Re: "master" branch still invokes build in f17-candidate??

Tom Lane wrote:

> Kevin Kofler  writes:
>> VÃt Ondruch wrote:
>>> If you say to Koji that it should checkout master at remote machine,
>>> build a SRPM etc, why the Koji can't determine the proper %{?dist} at
>>> remote machine? Why it takes the %{?dist} from local machine instead? It
>>> makes no sense. It might work for other branches, but master is bit
>>> different, so it should be handled differently.
> 
>> Yes, for fedpkg build, the client should not have to care about what
>> %{?dist} is at all. It should just ask Koji to build the current git hash
>> in Rawhide and that's it.
> 
> Nope, it's not that easy, as some purely-local operations (eg "fedpkg
> srpm") also want to know the dist tag.

Those operations can use Jesse's heuristics, but there's no good reason to 
use them for fedpkg build.

Kevin Kofler

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

Re: Add some information to Packaging cmake wiki

Richard Shaw wrote:
> Hmm... I guess we shouldn't add it to the cmake macro then :) I
> usually wait and see if there's a problem first and then try that as
> the fix. I haven't had a situation where it gave me bad flags yet, but
> I did have a package that hard coded "Release" with bad flags (-O3
> etc..) so I had to patch around that one.

Oh, by the way, "Release" isn't even necessarily the default build type. 
CMake has no built-in default (i.e. it will only use the global CFLAGS, not 
those from any build type, which is actually often what we want), and some 
packages define its own, which can be RelWithDebInfo or even Debug. (For 
example, anything using find_package(KDE4) which doesn't specify its own 
gets the default build type set to RelWithDebInfo by FindKDE4Internal.cmake. 
Our %cmake_kde4 macro actually forces it to Release instead for the reasons 
already discussed (NDEBUG flags).)

Kevin Kofler

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

Re: Add some information to Packaging cmake wiki

Richard Shaw wrote:
> Hmm... I guess we shouldn't add it to the cmake macro then :) I
> usually wait and see if there's a problem first and then try that as
> the fix. I haven't had a situation where it gave me bad flags yet, but
> I did have a package that hard coded "Release" with bad flags (-O3
> etc..) so I had to patch around that one.

Yeah, some packages try to strip Release builds (e.g. through the -s flag), 
and -O3 is also semi-common.

KDE, on the other hand, enables some debugging code in RelWithDebInfo which 
we really don't want in shipped packages (only Release defines NDEBUG). The 
Release mode flags of course don't include -g, but the -g gets picked up 
from the Fedora optflags anyway.

Kevin Kofler

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

Re: Don't be afraid to ask for help

On Mon, Feb 27, 2012 at 20:22:56 -0800,
  Adam Williamson  wrote:
> On Mon, 2012-02-27 at 08:42 -0600, Jon Ciesla wrote:
> 
> > Seconded.
> > 
> > And if anyone has gcc47 or libpng FTBFS issues, this is a great place
> > to ask for help on them.
> 
> Well, pulseaudio doesn't currently build, and that's preventing us from
> fixing the bug that audio doesn't work in F17. The problem is apparently
> in assembler code, though, so fixing it is unlikely to be trivial.
> 
> Lennart was working on it, but I've not heard from him on that for a few
> days.

https://admin.fedoraproject.org/updates/pulseaudio-1.1-8.fc17 includes
both an analog of the bluez fix and Lennart's pending fix for bug
794690 (the CK sound issue).

I did a similar build for rawhide, but the patch order got reversed.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: C++ ABI rebuilds for rawhide too?

2012-02-28 Thread Orcan Ogetbil

On Tue, Feb 28, 2012 at 3:23 PM, Jon Ciesla wrote:
> On Tue, Feb 28, 2012 at 2:18 PM, Bruno Wolff III wrote:
>> Are the same packages going to get automatically rebuilt in rawhide as
>> well as f17?
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>
> Yes, when they've finished.
>
> https://fedorahosted.org/fesco/ticket/813
>

Can you please provide a roadmap/instruction about how the packages in
F-17 updates-testing will be handled?
According to the ticket, there is no clear agreement yet.

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

Re: F17, Apple, EFI boot, livecd-tools

Following applies to a 2011, Macbook Pro 8,2

1.
Used livecd-tools-17.6-1.fc17 to successfully create an EFI bootable USB stick 
of Fedora-17-Alpha-x86_64-Live-Desktop.iso.

2.
I get to the GRUB menu. Times out and starts to boot. Same result as: EFI boot 
failure to properly initialize graphics on Macs with Intel and AMD graphics
https://bugzilla.redhat.com/show_bug.cgi?id=765954


So no improvement so far over F16 on either hardware. But livecd-tools appears 
to work correctly.


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

Re: F17, Apple, EFI boot, livecd-tools

Following applies to a 2008, Macbook Pro 4,1

1.
Used livecd-tools-17.6-1.fc17 to successfully create an EFI bootable USB stick 
of Fedora-17-Alpha-x86_64-Live-Desktop.iso.

2.
Due to this bug: EFI boot fails on Macs with NVIDIA GeForce 8600M GT
https://bugzilla.redhat.com/show_bug.cgi?id=751147

I add 'nomodeset' kernel parameter. I know of no work around to get a GUI on 
this hardware. But it does boot kernel and most services.

3.
tty1 hangs at "Started Display Manager"
tty2 is functional, not sure how to get any information on what's up with tty1. 
Normally what I'm used to with EFI boot and nomodeset is X can't actually 
startup, but the rest of the services load, and I end up at a prompt.

4.
Out of 5 boot attempts, I get to a usable tty2 console and can reboot thrice.

Twice, I get a hang right after GRUB loads either the kernel or initrd, the 
GRUB splash screen is present with no text. The machine has hung and I have to 
hold the power button to shut down.

So on this hardware I'd say GRUB is marginally reliable.

5.
At reboot/poweroff time, there's a LOT of extra "garbage" information being 
produced on-screen compared to F16. It goes by quick enough and isn't logged, 
so I'm not sure if it's important. But I do get a reboot, albeit with about a 1 
minute delay over F16.


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

Re: Add some information to Packaging cmake wiki

2012-02-28 Thread Richard Shaw

On Tue, Feb 28, 2012 at 5:19 PM, Rex Dieter  wrote:
> Kevin Kofler wrote:
>
>> Richard Shaw wrote:
>>> I've noticed with several packages lately that frequently the wrong
>>> build flags are used or appened to the ones the cmake macro sets.
>>> Sometimes this can happen because the main cmake configuration file
>>> forces the type to "Release" (bad!) but not always.
>>>
>>> I've found that adding: "-DCMAKE_RELEASE_TYPE=RelWithDebinfo" often
>>> takes care of this.
>>
>> FYI, some packages use bad flags with RelWithDebinfo and good ones with
>> Release, some always use good flags, and some always use bad flags (and
>> have to be patched).

Hmm... I guess we shouldn't add it to the cmake macro then :) I
usually wait and see if there's a problem first and then try that as
the fix. I haven't had a situation where it gave me bad flags yet, but
I did have a package that hard coded "Release" with bad flags (-O3
etc..) so I had to patch around that one.

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

[389-devel] Please review: [389 Project] #260: 389 DS does not support multiple paging controls on a single connection

2012-02-28 Thread Noriko Hosoi


https://fedorahosted.org/389/ticket/260

https://fedorahosted.org/389/attachment/ticket/260/0001-Trac-Ticket-260-389-DS-does-not-support-multiple.patch

 Fix description:
 1. "Connection" object holds the paged results related values.
Now they are packaged in one PagedResults object.  And the
array of PagedResults with its length and used count are
placed in PagedResultList, which is stashed in Connection
(slap.h).
 2. The pagedresults APIs are extended to take the index of Paged-
Results array.  The index is set to the cookie in the Paged-
Results control before returning it to the client.  When a
client sends a paged results request, the cookie field in the
first request control is supposed to be empty.  The result
control is returned with the search results.  The result
control stores the index in the cookie and the client sets
it to the following request control to get the next pages.
When the paged search is done, empty cookie is returned.
 3. The array grows if multiple simple paged results requests
over a single connection come in.  The array does not get
released every time, but it is when the server is shutdown.
 4. Simple paged results connection is timed out when it exeeds
the timelimit.  If multiple requests are served, it won't
be disconnected until all the requests are timed out.

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

Re: "master" branch still invokes build in f17-candidate??

2012-02-28 Thread Tom Lane

Kevin Kofler  writes:
> VÃt Ondruch wrote:
>> If you say to Koji that it should checkout master at remote machine,
>> build a SRPM etc, why the Koji can't determine the proper %{?dist} at
>> remote machine? Why it takes the %{?dist} from local machine instead? It
>> makes no sense. It might work for other branches, but master is bit
>> different, so it should be handled differently.

> Yes, for fedpkg build, the client should not have to care about what 
> %{?dist} is at all. It should just ask Koji to build the current git hash in 
> Rawhide and that's it.

Nope, it's not that easy, as some purely-local operations (eg "fedpkg srpm")
also want to know the dist tag.

I don't actually have a problem with Jesse's solution now that I know
about it; it was just surprising that fedpkg would depend on other
branches besides the one I have checked out.

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

Re: Add some information to Packaging cmake wiki

2012-02-28 Thread Rex Dieter

Kevin Kofler wrote:

> Richard Shaw wrote:
>> I've noticed with several packages lately that frequently the wrong
>> build flags are used or appened to the ones the cmake macro sets.
>> Sometimes this can happen because the main cmake configuration file
>> forces the type to "Release" (bad!) but not always.
>> 
>> I've found that adding: "-DCMAKE_RELEASE_TYPE=RelWithDebinfo" often
>> takes care of this.
> 
> FYI, some packages use bad flags with RelWithDebinfo and good ones with
> Release, some always use good flags, and some always use bad flags (and
> have to be patched).
> 
> (For example, the KDE packages are all built in release mode.)
> 
> It depends on the package. Always check the CFLAGS being used (the verbose
> build output).

I sympathize with Richard's sentiment that we should make an effort to 
sanitize and ideally standarize this in our builds... and using 
RelWithDebinfo CMAKE_RELEASE_TYPE is one approach to achieving that.

-- rex

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

Re: Add some information to Packaging cmake wiki

Richard Shaw wrote:
> I've noticed with several packages lately that frequently the wrong
> build flags are used or appened to the ones the cmake macro sets.
> Sometimes this can happen because the main cmake configuration file
> forces the type to "Release" (bad!) but not always.
> 
> I've found that adding: "-DCMAKE_RELEASE_TYPE=RelWithDebinfo" often
> takes care of this.

FYI, some packages use bad flags with RelWithDebinfo and good ones with 
Release, some always use good flags, and some always use bad flags (and have 
to be patched).

(For example, the KDE packages are all built in release mode.)

It depends on the package. Always check the CFLAGS being used (the verbose 
build output).

Kevin Kofler

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

F17 x86_64 composes

2012-02-28 Thread Mike Chambers

Noticed that x86_64 tree is still NOT installable, as in no boot.iso or
anything.  Is this going to remain that way for awhile?

-- 
Mike Chambers
Madisonville, KY

"Best little town on Earth!"

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

Re: How can we make F17 be able to boot on Macs (with or without reFit)

On Feb 28, 2012, at 2:37 PM, Chris Murphy wrote:

>> 
>> Starting with a USB stick produced with the following:
>> http://mirrors.yocum.org/fedora/releases/test/17-Alpha/Fedora/x86_64/iso/Fedora-17-Alpha-x86_64-netinst.iso
>> 
>> dd if=Fedora-17-Alpha-x86_64-netinst.iso of=/dev/rdisk1
> 
> I'm not sure if this is expected or not, but I make the following 
> observations about the resulting USB stick, which appears to have a bogus GPT 
> according to three utilities.

parted can't fix it.

gdisk then says the GPT is damaged and will not fix/restore the 1st partition 
which contains the bulk of the boot data.

gpt bails entirely.

AFAIK this ISO isn't valid, insofar as the GPT is invalid, but I'm not sure if 
that relates to the booting problems both computers are having.

I'm going to try making an EFI bootable USB stick using the latest livecd-tools 
and the F17-alpha-LiveCD and see where that takes me.

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

Add some information to Packaging cmake wiki

2012-02-28 Thread Richard Shaw

I don't have access to edit this[1] so I hope someone who does will.

I've noticed with several packages lately that frequently the wrong
build flags are used or appened to the ones the cmake macro sets.
Sometimes this can happen because the main cmake configuration file
forces the type to "Release" (bad!) but not always.

I've found that adding: "-DCMAKE_RELEASE_TYPE=RelWithDebinfo" often
takes care of this.

Thanks,
Richard

[1] https://fedoraproject.org/wiki/Packaging:Cmake
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How can we make F17 be able to boot on Macs (with or without reFit)

> 
> Starting with a USB stick produced with the following:
> http://mirrors.yocum.org/fedora/releases/test/17-Alpha/Fedora/x86_64/iso/Fedora-17-Alpha-x86_64-netinst.iso
> 
> dd if=Fedora-17-Alpha-x86_64-netinst.iso of=/dev/rdisk1

I'm not sure if this is expected or not, but I make the following observations 
about the resulting USB stick, which appears to have a bogus GPT according to 
three utilities.

1.
GPT fdisk (gdisk) version 0.8.2

Partition table scan:
 MBR: protective
 BSD: not present
 APM: not present
 GPT: present

Found valid GPT with protective MBR; using GPT.
Warning! Main partition table overlaps the first partition by 48 blocks!
You will need to delete this partition or resize it in another utility.
Disk /dev/disk1: 3915776 sectors, 1.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): E2E967A4-B1E8-4D61-9F5D-37F99C3E603E
Partition table holds up to 128 entries
First usable sector is 48, last usable sector is 319454
Partitions will be aligned on 4-sector boundaries
Total free space is 1550 sectors (775.0 KiB)

Number  Start (sector)End (sector)  Size   Code  Name
  2   58168   59483   658.0 KiB   0700  卉䡏批楲d灁汰e灁汰
  3   59484   61323   920.0 KiB   AF00  卉䡏批楲d灁汰e灁汰

Similar results but different Name encoding for gdisk on Fedora.


2.
parted on F17

Error: The backup GPT table is not at the end of the disk, as it should be.
This might mean that another operating system believes the disk is smaller.
Fix, by moving the backup to the end (and removing the old backup)?
Fix/Ignore/Cancel? i  
Warning: Not all of the space available to /dev/sdb appears to be used, you can
fix the GPT to use all of the space (an extra 3596288 blocks) or continue with
the current setting? 
Fix/Ignore? i 
Error: Unable to satisfy all constraints on the partition.

3.
Apple's "gpt" program:

cd2:~ chris@ gpt show -l disk2
gpt show: error: bogus map
gpt show: unable to open device 'disk2': No such file or directory
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 788123] Request for EPEL branches for perl-Module-Runtime

2012-02-28 Thread 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=788123

Paul Howarth  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version||perl-Module-Runtime-0.012-1
   ||.el5
 Resolution||NEXTRELEASE
Last Closed||2012-02-28 16:11:42

--- Comment #8 from Paul Howarth  2012-02-28 16:11:42 EST ---
I was able to do this build without Params::Classify (and hence
ExtUtils::ParseXS) because Module::Runtime was updated not to depend on
Params::Classify.

-- 
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: How can we make F17 be able to boot on Macs (with or without reFit)

Prior attempt, I mentioned at the very bottom of the email, easy to miss, was a
Macbook Pro 4,1 (2008) model.

---

Attempt 2 with different hardware: Apple Macbook Pro 8,2 (2011).

1.
Starting with a USB stick produced with the following:
http://mirrors.yocum.org/fedora/releases/test/17-Alpha/Fedora/x86_64/iso/Fedora-17-Alpha-x86_64-netinst.iso

dd if=Fedora-17-Alpha-x86_64-netinst.iso of=/dev/rdisk1

2.
Inserting the USB stick while Mac OS 10.6.8 is running (I know, older OS on the
newer hardware, I'm on crack), the Startup Disk panel does not show any
additional options for booting.

3.
Rebooting, holding option key, I get two additional boot option icons both
labeled "EFI Boot". One is an orange USB icon. The other is a blue Fedora icon.

4.
When choosing either option, I get the GRUB Legacy menu, it times down to zero,
I get 7 seconds of USB stick activity, followed by a tone from the laptop I
have only ever heard when doing firmware updates. Interval is approximately 0.7
seconds tone, 0.3 seconds silence, three times. Followed by 3 seconds of
silence. Then repeats. It does not end on its own after 2 minutes, and the
computer does not reboot. And the keyboard is not functional. I have to hold
the power button for 5 minutes to force a shutdown.

Again, no text onscreen to indicate what the problem is - it's still at the
GRUB window during all of this.

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

Re: How can we make F17 be able to boot on Macs (with or without reFit)

On Feb 28, 2012, at 12:53 PM, Matthew Garrett wrote:
> 
> Yes. I'm mostly working on the netinst isos, and right now if you take 
> that and dd it onto a USB stick, then insert that and hold down alt on 
> boot, you'll get a Mac install.

1.
http://mirrors.yocum.org/fedora/releases/test/17-Alpha/Fedora/x86_64/iso/Fedora-17-Alpha-x86_64-netinst.iso

dd if=Fedora-17-Alpha-x86_64-netinst.iso of=/dev/rdisk1

2.
I get two additional icons to boot from, both named "EFI Boot". One is an 
orange USB icon, the other is a blue Fedora icon. 

3.
If I choose the blue Fedora icon, I get a GRUB Legacy menu, let it time out. It 
appears to be loading data from the USB stick. After about 45 seconds, the 
computer reboots, and I'm at a Mac OS login window. No text error messages 
indicating why.

4.
I reboot with option key to get the AppleEFI boot menu, choose the orange USB 
"EFI Boot" icon, the same thing happens. 45 seconds, I get a reboot, and I'm at 
a Mac OS login window. No text error messages indicating why.

5.
In Mac OS X 10.7.3, Startup Disk panel, there are no additional boot options 
listed when the USB stick is inserted, yet there are two "ANACONDA" labeled 
volumes mounted.

The hardware is a Macbook Pro 4,1 (2008) model.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: C++ ABI rebuilds for rawhide too?

On Tue, Feb 28, 2012 at 2:18 PM, Bruno Wolff III  wrote:
> Are the same packages going to get automatically rebuilt in rawhide as
> well as f17?
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

Yes, when they've finished.

https://fedorahosted.org/fesco/ticket/813

-J

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

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

C++ ABI rebuilds for rawhide too?

Are the same packages going to get automatically rebuilt in rawhide as
well as f17?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How can we make F17 be able to boot on Macs (with or without reFit)

On Tue, 2012-02-28 at 19:53 +, Matthew Garrett wrote:
> On Tue, Feb 28, 2012 at 08:34:22PM +0100, Andreas Tunek wrote:
> > Den 28 februari 2012 18:22 skrev Matthew Garrett :
> > > Yes, F17's current media should be pretty close to working.
> > >
> > 
> > Is this on native/basic Apple EFI, not reFit?
> 
> Yes. I'm mostly working on the netinst isos, and right now if you take 
> that and dd it onto a USB stick, then insert that and hold down alt on 
> boot, you'll get a Mac install. Unfortunately, alpha ended up getting 
> built with a grub that dies on any Macs that don't have built-in 
> ethernet, so you may have some problems with that. The alpha kernel also 
> has a bug that seems to trigger on Macs that results in incredible 
> slowness. But other than that! Fixed kernel is in the archive now, and 
> I've just commited a fix for the grub bug.

For the record, the incredible slowness bug is
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=795050 and is
documented at
https://fedoraproject.org/wiki/Common_F17_bugs#slow
(yes, I'm having some fun with the anchor names on the common bugs page,
and yes, my life is that tragic.)
-- 
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

Re: How can we make F17 be able to boot on Macs (with or without reFit)

2012-02-28 Thread Matthew Garrett

On Tue, Feb 28, 2012 at 08:34:22PM +0100, Andreas Tunek wrote:
> Den 28 februari 2012 18:22 skrev Matthew Garrett :
> > Yes, F17's current media should be pretty close to working.
> >
> 
> Is this on native/basic Apple EFI, not reFit?

Yes. I'm mostly working on the netinst isos, and right now if you take 
that and dd it onto a USB stick, then insert that and hold down alt on 
boot, you'll get a Mac install. Unfortunately, alpha ended up getting 
built with a grub that dies on any Macs that don't have built-in 
ethernet, so you may have some problems with that. The alpha kernel also 
has a bug that seems to trigger on Macs that results in incredible 
slowness. But other than that! Fixed kernel is in the archive now, and 
I've just commited a fix for the grub bug.

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

Re: How can we make F17 be able to boot on Macs (with or without reFit)

2012-02-28 Thread Andreas Tunek

Den 28 februari 2012 18:22 skrev Matthew Garrett :
> On Tue, Feb 28, 2012 at 05:57:38PM +0100, Andreas Tunek wrote:
>> Has there been any more tests getting F17 to boot on macs, with or without
>> refit? I would love to test, but if macs are not any target hardware for
>> fedora it would be pretty pointless.
>
> Yes, F17's current media should be pretty close to working.
>

Is this on native/basic Apple EFI, not reFit?

/Andreas

> --
> Matthew Garrett | mj...@srcf.ucam.org
> --
> 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: How can we make F17 be able to boot on Macs (with or without reFit)

On Tue, 2012-02-28 at 12:23 -0700, Chris Murphy wrote:
> 
> On Feb 28, 2012, at 12:15 PM, Adam Williamson wrote:
> > 
> > Chris Murphy is pretty active testing various things in regards to Mac
> > booting, and I've been meaning to get in touch and ask if he's taken a
> > look at F17 Alpha.
> 
> I just downloaded the LiveCD, installed it in VM so I can use the
> latest livecd-tools to make an EFI bootable USB stick for the Mac
> hardware I have here. Will report back.

Thanks! It's much appreciated.
-- 
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

Re: How can we make F17 be able to boot on Macs (with or without reFit)

On Feb 28, 2012, at 12:15 PM, Adam Williamson wrote:
> 
> Chris Murphy is pretty active testing various things in regards to Mac
> booting, and I've been meaning to get in touch and ask if he's taken a
> look at F17 Alpha.

I just downloaded the LiveCD, installed it in VM so I can use the latest 
livecd-tools to make an EFI bootable USB stick for the Mac hardware I have 
here. Will report back.

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

Re: How can we make F17 be able to boot on Macs (with or without reFit)

On Tue, 2012-02-28 at 17:57 +0100, Andreas Tunek wrote:
> Has there been any more tests getting F17 to boot on macs, with or
> without refit? I would love to test, but if macs are not any target
> hardware for fedora it would be pretty pointless.

I didn't really manage to make time to get anywhere with formal testing
as part of the QA processes, unfortunately (I was hoping to have a test
case or two and get someone in QA some Mac hardware), but mjg59 is
working on things on the development end and testing with the hardware
he has available, and there has been some discussion and testing going
on particularly in the mactel-boot review request bug:

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

Chris Murphy is pretty active testing various things in regards to Mac
booting, and I've been meaning to get in touch and ask if he's taken a
look at F17 Alpha.
-- 
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

Re: How can we make F17 be able to boot on Macs (with or without reFit)

2012-02-28 Thread Michele Baldessari

On Tue, Feb 28, 2012 at 05:22:22PM +, Matthew Garrett wrote:
> On Tue, Feb 28, 2012 at 05:57:38PM +0100, Andreas Tunek wrote:
> > Has there been any more tests getting F17 to boot on macs, with or without
> > refit? I would love to test, but if macs are not any target hardware for
> > fedora it would be pretty pointless.
> 
> Yes, F17's current media should be pretty close to working.

FWIW I installed F16 some time ago and upgraded just yesterday to F17 
(via the rc4 iso) just fine on my MacbookAir4,1. 
F16 didn't have a working graphical anaconda (Intel HW was too new), F17
upgrade went perfectly. So Kudos to everyone ;)

cheers,
-- 
Michele Baldessari
C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Issues with yum

2012-02-28 Thread Przemek Klosowski


On 02/27/2012 07:04 AM, Josh Boyer wrote:

On Mon, Feb 27, 2012 at 1:44 AM, elison.ni...@gmail.com:

I forgot to add: 8) Yum cannot use an iso image as a repo without
mounting it. Yast in suse allows to directly use iso images as
repos.


You also forgot to add:

1) A proposed alternative 2) Patches to fix any of the issues you
pointed out 3) Anything constructive at all in your ramblings.

Seriously, if you want yum replaced with something then you need to
show up with an alternate proposal, how it would work, and people
willing to do that work.  Without those things, this is at best going
to be ignored and at works just turn into a huge "ME TOO" thread that
still winds up generating no change.


I love yum. I have been using it on dozens of systems for probably 
something like 100 system-years. Normally it's rock-solid, but when it 
breaks it is something to behold. I had a couple of failures over the 
years, and it just so happens that the system I write this on has a 
major problem when out of the blue yum just collapsed in a heap:


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

Things can happen---I am OK with that. What worries me more is that yum 
became a little baroque and non-transparent. There is a litany of 
remedies for yum problems:


yum-complete-transaction
rpm --rebuilddb
yum clean all
package-cleanup (--problems/orphans/dupes/leaves)

While I have a general understanding of how yum works, and one or more 
of the above always got me out of trouble in the past, this time they 
didn't help and I don't know what to do next: which tools to use, what 
to look for. Yum-utils has 23 separate executables and 18 manpages that 
list a bewildering variety of options and subcommands---intimidating 
complexity, which may also be reflected in increasing yum run times for 
routine actions like queries and updates.


Of course it's not reasonable to throw yum out and start from scratch.
Given that it almost always works very well, perhaps it's even 
reasonable to conclude that it should be left alone. Even if we agree 
that something should be done, which of the following ideas are worth 
pursuing:


 * better diagnostic tools
 * more visibility into the yum data and internals
 * some refactoring
 * documentation for debugging problems

Re-reading what I wrote, I realize that it's not very constructive, as I 
don't know what is the right thing to do to improve yum, much less how 
to do it. I just want to raise the issues for discussion.

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

Re: [389-devel] Please Review: (181) Allow PAM passthru plug-in to have multiple config entries

2012-02-28 Thread Nathan Kinder


On 02/27/2012 04:11 PM, Nathan Kinder wrote:

https://fedorahosted.org/389/ticket/181

https://fedorahosted.org/389/attachment/ticket/181/0001-ticket-181-Allow-PAM-passthru-plug-in-to-have-multip.patch 

Here is a revised patch that avoids some unnecessary DN normalization as 
well as addresses an issue pointed out by Rich where the post-op 
callback needs to skip failed operations.


https://fedorahosted.org/389/attachment/ticket/181/0001-ticket-181-Allow-PAM-passthru-plug-in-to-have-multip.patch

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


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

Re: Don't be afraid to ask for help

On Tue, Feb 28, 2012 at 10:41:25 -0600,
  Bruno Wolff III  wrote:
> On Tue, Feb 28, 2012 at 11:31:09 -0500,
>   Bill Nottingham  wrote:
> > Bruno Wolff III (br...@wolff.to) said: 
> > > > So far there is only an f18 bluez build. That will work for my testing,
> > > > but that won't let me easily to an f17 build.
> > > 
> > > Nottingham appears to be getting an F17 bluez rebuild ready right now.
> > 
> > Yes, the only F18 change over F17 was the change to fix this issue. Merged,
> > built, in bodhi now.
> 
> A local rebuild of pulseaudio didn't seem to pick up the change. So
> it seems likely that pulseaudio will need an analogous patch.

I can't do this now, but if there isn't a new pulseaudio build tonight
(about 9 hours from now), I'll try to make one.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Test-Announce] Meat the Beefy Miracle: Announcing the release of Fedora 17 Alpha!

On Tue, 2012-02-28 at 09:07 -0600, Dennis Gilmore wrote:

> == Issues and Details ==
> 
> For more information including common and known bugs, tips on how to 
> report bugs, and the official release schedule, please refer to the 
> release notes:
> http://fedoraproject.org/wiki/Fedora_17_Alpha_release_notes
> 
> A shorter list of common bugs can be found here:
> http://fedoraproject.org/wiki/Common_F17_bugs

Thanks Dennis!

As this is buried at the bottom of the announcement I thought I'd give
it a shout-out, because this particular Alpha is pretty Alpha and has an
assortment of rather large bugs which lots of you will likely run into.
So please, really do read the common bugs page:

http://fedoraproject.org/wiki/Common_F17_bugs

That's:

http://fedoraproject.org/wiki/Common_F17_bugs

where you will find out all about minor problems like the installer's
propensity to explode at the slightest touch (other distributions
present, or a btrfs partition) and sound not working at all out of the
box. Really. You're going to want to read it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

Re: How can we make F17 be able to boot on Macs (with or without reFit)

2012-02-28 Thread Matthew Garrett

On Tue, Feb 28, 2012 at 05:57:38PM +0100, Andreas Tunek wrote:
> Has there been any more tests getting F17 to boot on macs, with or without
> refit? I would love to test, but if macs are not any target hardware for
> fedora it would be pretty pointless.

Yes, F17's current media should be pretty close to working.

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

Re: Issues with yum

On Feb 28, 2012, at 10:02 AM, John Reiser wrote:

> On 02/28/2012 08:51 AM, Chris Murphy wrote:
> 
>> *shrug* OK I'm not going to deny you a feature. I still don't understand
>> why it would be started in the first place if you didn't intend to finish it.
> 
> The Fedora mirror system doesn't always behave nicely
> (timeouts, bad sync, slow transfer rate, ...)
> I find that SIGINT is appropriate about once per week
> just for downloads.

Well I sure love eating crow. I have in fact hit control-c in the case where a 
slow mirror (like, dial-up modem slow) was even delaying the database update. 
10 minutes later, still no idea if there were any applicable updates available. 
But control-c during that initial database updating for me has always been 
instant kill and drop to a prompt. Retrying, nothing is inconsistent, and I'm 
connected to a  much faster mirror 100% of the time. So at least that instance 
of control-c appears to work.

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

Re: Issues with yum

2012-02-28 Thread John Reiser

On 02/28/2012 08:51 AM, Chris Murphy wrote:

> *shrug* OK I'm not going to deny you a feature. I still don't understand
> why it would be started in the first place if you didn't intend to finish it.

The Fedora mirror system doesn't always behave nicely
(timeouts, bad sync, slow transfer rate, ...)
I find that SIGINT is appropriate about once per week
just for downloads.

-- 

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

Re: How can we make F17 be able to boot on Macs (with or without reFit)

2012-02-28 Thread Andreas Tunek

Has there been any more tests getting F17 to boot on macs, with or without
refit? I would love to test, but if macs are not any target hardware for
fedora it would be pretty pointless.

/Andreas
On Dec 27, 2011 4:09 AM, "Chris Murphy"  wrote:

>
> On Dec 26, 2011, at 5:55 PM, Todd V Orvieto wrote:
>
> > Chris,
> >  I got really frustrated with triple boot on Max OS X Lion.  At one
> point I had it working on snow leopard pretty well.
>
> A possible problem with Lion is not technically with Lion itself. When
> 10.7 is installed, there is an additional partition created called Recovery
> HD, which contains a minimal system for booting a limited environment.
> Because of this, out of the gate you have at least three partitions: sda1,
> sda2, sda3. You can only add one more partition and have parity with a
> hybrid MBR and I'll bet gptsync does this incorrectly. And there are also
> 2.2TB concerns because of course the Windows partition can't go beyond the
> 2.2TB limit. So how the MBR should look in a triple boot, is unique. I've
> done probably 2-3 dozen installs and figured out one that's ideal for less
> than 2.2TB disks, and one or two that are tolerable, but still gross lies,
> for 2.2TB+ drives.
>
> It also requires giving up on the Windows bootloader and use GRUB2 for
> bootloading both Windows and Fedora.
>
> > My buddy who works for Apple has told me that the installation of refit
> voids the warranty and they have refused to fix computers under warranty
> with refit installed.
>
> Well that's completely bogus. I've heard this myth before, I don't know
> where it started. I think some traveling support crew probably were
> misinformed that rEFIt is an EFI firmware replacement, and if it were true
> that people were flashing Apple's firmware with some 3rd party firmware,
> they'd be able to void warranties. But rEFIt is not firmware, it's a set of
> EFI applications and drivers. So whoever says this is completely full of
> crap and doesn't know what they're talking about.
>
>
> >  I think this is bummer because the Apple hardware is good, it makes no
> sense why Apple cares.
>
> Apple doesn't care to support foreign OS's.
>
>
> Chris Murphy
> --
> 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: Issues with yum

On Feb 28, 2012, at 12:19 AM, elison.ni...@gmail.com wrote:

> On Tue, Feb 28, 2012 at 12:39 PM, Chris Murphy  
> wrote:
>> What's the expectation of a user hitting control-c in the middle of a yum 
>> update anyway? My first inclination is it makes zero sense, like habaneros 
>> in a smoothie.
> 
> As stated earlier, the expectation is that when yum is still setting
> up update process or downloading repo information, it will stop that
> and quit.
> Only when yum reaches "starting transaction test" or "running
> transaction", it should restrict ctrl-c.

*shrug* OK I'm not going to deny you a feature. I still don't understand why it 
would be started in the first place if you didn't intend to finish it. But 
then, I never use -y either so I kinda know what I'm getting into before I 
confirm with "Y" that I do want to proceed with the update.


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

UEFI install from USB media

http://docs.fedoraproject.org/en-US/Fedora/16/html/Installation_Guide/Making_USB_Media.html

2nd sentence reads: Note that you cannot install Fedora on UEFI-based AMD64 and 
Intel 64 systems from a USB flash drive, although you can use a USB flash drive 
to boot the Fedora installer on UEFI-based AMD64 and Intel 64 systems

This appears to say "you cannot install, but you can boot". It's quite 
confusing. I have used livecd-tools to create UEFI bootable LiveCD media on a 
USB stick and also installed it onto an Intel-64 system. So this portion of 
documentation appears to be incorrect. If so, I'll volunteer to file a 
documentation bug - however the bugzilla only has a documentation bug report 
version of "devel" so it's slightly unclear how to file such a doc bug report. 
If it's a bug.

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

Re: "master" branch still invokes build in f17-candidate??

2012-02-28 Thread Josh Boyer

On Tue, Feb 28, 2012 at 11:18 AM, Richard W.M. Jones  wrote:
> On Mon, Feb 27, 2012 at 12:14:49PM -0800, Jesse Keating wrote:
>> On 2/27/12 8:37 AM, Tom Lane wrote:
>> >Orion Poplawski  writes:
>> >>On 02/27/2012 09:09 AM, Tom Lane wrote:
>> >>>WTF?  Do I need to fix this, and if so how?
>> >
>> >>git pull
>> >>(to bring in the f17 branch and mark devel as f18)
>> >
>> >Hmm, that package indeed hadn't had f17 git pull'd yet.  (I had scripted
>> >a git pull in all my package directories after the branch, but I think
>> >that it failed in this one due to uncommitted changes.)
>> >
>> >So you're saying that fedpkg's behavior depends on the existence of
>> >other, un-checked-out, branches in my local repo?  This seems a
>> >tad ... unreliable.  Not to say surprising.
>> >
>> >                     regards, tom lane
>>
>> I was looking for a way to determine the behavior of the master
>> branch (for the sake of dist values) without hitting the network, as
>> that would break git's ability to work offline.  The best I could
>> come up with at the time this code was written was to check and see
>> what other branches existed, and just increment the biggest one by
>> one.  I welcome suggestions for better ways to manage this.
>
> Didn't RHEL-CVS use a file in the local directory called 'branch'(?)

I believe Fedora-CVS had the same.  Except it needed to be updated at branch
time, and fetched from the server across all checkouts.  Makefile.common is
what hid all that and nobody noticed because you had to be on the network to
do anything with CVS anyway.

Doing the same in git would still require a 'git pull' to get the updated file.

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

Re: Need help with systemd service files

2012-02-28 Thread Michal Schmidt


Dne 28.2.2012 17:23, Garrett Holmstrom napsal(a):

Of interest here is the fact that the script that
cloud-init-local.service runs currently has a bug that causes it to
return the wrong return code. Since cloud-init.target Requires that
service (cloud-config.service does not function correctly without it),
two of those services should not be running at all, if I understand the
systemd documentation correctly.


Garrett,
Juerg had an old version of systemd installed (F16 GA, no updates).
After installing updates he's now getting dependency failures as you 
correctly anticipated :-)


[   97.114643] systemd[1]: cloud-init-local.service: main process
exited, code=exited, status=1
[   97.115478] systemd[1]: cloud-init-local.service changed start -> failed
[   97.124134] systemd[1]: Job cloud-init-local.service/start
finished, result=failed
[   97.124157] systemd[1]: Job cloud-config.target/start finished,
result=dependency
[   97.124173] systemd[1]: Job cloud-final.service/start finished,
result=dependency
[   97.124192] systemd[1]: Job cloud-final.service/start failed with
result 'dependency'.
[   97.124875] systemd[1]: Job cloud-config.service/start finished,
result=dependency
[   97.124894] systemd[1]: Job cloud-config.service/start failed with
result 'dependency'.
[   97.125595] systemd[1]: Job cloud-config.target/start failed with
result 'dependency'.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: "master" branch still invokes build in f17-candidate??

Vít Ondruch wrote:
> If you say to Koji that it should checkout master at remote machine,
> build a SRPM etc, why the Koji can't determine the proper %{?dist} at
> remote machine? Why it takes the %{?dist} from local machine instead? It
> makes no sense. It might work for other branches, but master is bit
> different, so it should be handled differently.

Yes, for fedpkg build, the client should not have to care about what 
%{?dist} is at all. It should just ask Koji to build the current git hash in 
Rawhide and that's it.

Kevin Kofler

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

Re: Don't be afraid to ask for help

On Tue, Feb 28, 2012 at 11:31:09 -0500,
  Bill Nottingham  wrote:
> Bruno Wolff III (br...@wolff.to) said: 
> > > So far there is only an f18 bluez build. That will work for my testing,
> > > but that won't let me easily to an f17 build.
> > 
> > Nottingham appears to be getting an F17 bluez rebuild ready right now.
> 
> Yes, the only F18 change over F17 was the change to fix this issue. Merged,
> built, in bodhi now.

A local rebuild of pulseaudio didn't seem to pick up the change. So
it seems likely that pulseaudio will need an analogous patch.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Don't be afraid to ask for help

Bruno Wolff III wrote:
> Even though this is in bluez, it looks like it is probably inlined into
> pulseaudio as the file has the same name in pulseaudio.

You still need to apply the same patch to the pulseaudio package, just 
rebuilding against the updated bluez won't magically fix it.

Kevin Kofler

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

Re: Don't be afraid to ask for help

On Tue, Feb 28, 2012 at 10:31 AM, Bill Nottingham  wrote:
> Bruno Wolff III (br...@wolff.to) said:
>> > So far there is only an f18 bluez build. That will work for my testing,
>> > but that won't let me easily to an f17 build.
>>
>> Nottingham appears to be getting an F17 bluez rebuild ready right now.
>
> Yes, the only F18 change over F17 was the change to fix this issue. Merged,
> built, in bodhi now.

Awesome, thanks all!

See what happens? :)

-J

> Bill



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

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

Re: Don't be afraid to ask for help

2012-02-28 Thread Bill Nottingham

Bruno Wolff III (br...@wolff.to) said: 
> > So far there is only an f18 bluez build. That will work for my testing,
> > but that won't let me easily to an f17 build.
> 
> Nottingham appears to be getting an F17 bluez rebuild ready right now.

Yes, the only F18 change over F17 was the change to fix this issue. Merged,
built, in bodhi now.

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

Re: Need help with systemd service files

2012-02-28 Thread Garrett Holmstrom

On Feb 28, 2012 6:12 AM, "Juerg Haefliger"  wrote:
> [   92.376121] systemd[1]: cloud-init-local.service changed start ->
failed

Of interest here is the fact that the script that cloud-init-local.service
runs currently has a bug that causes it to return the wrong return code.
Since cloud-init.target Requires that service (cloud-config.service does
not function correctly without it), two of those services should not be
running at all, if I understand the systemd documentation correctly.
On Feb 28, 2012 6:12 AM, "Juerg Haefliger"  wrote:

> On Tue, Feb 28, 2012 at 12:02 PM, Michal Schmidt 
> wrote:
> > On 02/26/2012 07:37 AM, Garrett Holmstrom wrote:
> >>
> >> On 2012-02-24 4:22, Juerg Haefliger wrote:
> >>>
> >>> So I installed the official Fedora version of cloud-init but the
> >>> service startup ordering is broken there too:
> >>>
> >>> [root@342 ~]# dmesg | grep cloud | grep About
> >>> [   91.668396] systemd[1]: About to execute: /usr/bin/cloud-init
> >>> start-local
> >>> [   91.993238] systemd[1]: About to execute: /usr/bin/cloud-init-cfg
> all
> >>> config
> >>> [   92.540255] systemd[1]: About to execute: /usr/bin/cloud-init-cfg
> all
> >>> final
> >>> [   92.559834] systemd[1]: About to execute: /usr/bin/cloud-init start
> >
> >
> > I can't reproduce the problem. They are started in the expected order
> here.
> >
> > Juerg,
> > is this a log of the order during boot? Or did you test the services by
> > listing all 4 of them in systemctl start ...?
> > The latter would show bug 704214.
>
>
> This is the boot order. Different than the last time:
>
> [root@fedora ~]# dmesg | grep cloud
> [1.639947] systemd[1]: Installed new job cloud-config.service/start as
> 80
> [1.639952] systemd[1]: Installed new job cloud-config.target/start as
> 81
> [1.639957] systemd[1]: Installed new job
> cloud-init-local.service/start as 82
> [1.639961] systemd[1]: Installed new job cloud-init.service/start as 83
> [1.639966] systemd[1]: Installed new job cloud-final.service/start as
> 84
> [1.640413] systemd[1]: cloud-config.target changed dead -> active
> [1.640426] systemd[1]: Job cloud-config.target/start finished,
> result=done
> [   91.676503] systemd[1]: About to execute: /usr/bin/cloud-init
> start-local
> [   91.686093] systemd[1]: Forked /usr/bin/cloud-init as 489
> [   91.686227] systemd[1]: cloud-init-local.service changed dead -> start
> [   91.990133] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all
> config
> [   91.998048] systemd[1]: Forked /usr/bin/cloud-init-cfg as 549
> [   91.998213] systemd[1]: cloud-config.service changed dead -> start
> [   92.364807] systemd[1]: Received SIGCHLD from PID 549 (cloud-init-cfg).
> [   92.364835] systemd[1]: Got SIGCHLD for process 549 (cloud-init-cfg)
> [   92.364877] systemd[1]: Child 549 belongs to cloud-config.service
> [   92.364889] systemd[1]: cloud-config.service: main process exited,
> code=exited, status=0
> [   92.375143] systemd[1]: cloud-config.service changed start -> exited
> [   92.375160] systemd[1]: Job cloud-config.service/start finished,
> result=done
> [   92.375264] systemd[1]: Got SIGCHLD for process 489 (cloud-init)
> [   92.375302] systemd[1]: Child 489 belongs to cloud-init-local.service
> [   92.375311] systemd[1]: cloud-init-local.service: main process
> exited, code=exited, status=1
> [   92.376121] systemd[1]: cloud-init-local.service changed start -> failed
> [   92.377151] systemd[1]: Job cloud-init-local.service/start
> finished, result=failed
> [   92.377175] systemd[1]: Unit cloud-init-local.service entered failed
> state.
> [   92.377833] systemd[1]: About to execute: /usr/bin/cloud-init start
> [   92.385184] systemd[1]: Forked /usr/bin/cloud-init as 599
> [   92.385262] systemd[1]: cloud-init.service changed dead -> start
> [   92.385293] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all
> final
> [   92.393218] systemd[1]: Forked /usr/bin/cloud-init-cfg as 600
> [   92.393358] systemd[1]: cloud-final.service changed dead -> start
> [   92.394075] systemd[1]: cloud-config.service: cgroup is empty
> [   92.394927] systemd[1]: cloud-init-local.service: cgroup is empty
> [   92.550734] systemd[1]: Received SIGCHLD from PID 600 (cloud-init-cfg).
> [   92.550760] systemd[1]: Got SIGCHLD for process 600 (cloud-init-cfg)
> [   92.550803] systemd[1]: Child 600 belongs to cloud-final.service
> [   92.550810] systemd[1]: cloud-final.service: main process exited,
> code=exited, status=0
> [   92.559058] systemd[1]: cloud-final.service changed start -> exited
> [   92.559072] systemd[1]: Job cloud-final.service/start finished,
> result=done
> [   92.559522] systemd[1]: cloud-final.service: cgroup is empty
> [  116.415829] systemd[1]: Received SIGCHLD from PID 599 (cloud-init).
> [  116.415854] systemd[1]: Got SIGCHLD for process 599 (cloud-init)
> [  116.415896] systemd[1]: Child 599 belongs to cloud-init.service
> [  116.415908] systemd[1]: cloud-init.service: main process exited,
> code=exited, s

Re: Help needed for virtualbox ( Was Provenpackager? Want to help out? )

2012-02-28 Thread Sérgio Basto

On Tue, 2012-02-28 at 04:52 +, "Jóhann B. Guðmundsson" wrote: 
> On 02/28/2012 02:09 AM, Sérgio Basto wrote:
> > Hi,
> > 3 things
> > 1- I like have help on convert:
> > vboxweb-service from VirtualBox on rpmfusion.
> > "http://cvs.rpmfusion.org/viewvc/*checkout*/rpms/VirtualBox-OSE/F-17/vboxweb-service?revision=1.1&root=free";
> > off-list
> 
> First of all this is for the rpmfusion list and was off topic for this 
> thread that said...
> 
> Here is a vboxweb.service that should work for if not you can read the 
> systemd man pages and figure out the rest.
> 
> ### vboxweb.service ###
> 
> [Unit]
> Description=VirtualBox OSE Web Service
> After=network.target
> 
> [Service]
> Type=forking
> PIDFile=/run/vboxweb.pid
> ExecStart=/usr/bin/vboxwebsrv --pidfile /run/vboxweb.pid  --background
> 
> [Install]
> WantedBy=multi-user.target
> 
> "/etc/sysconfig/$SERVICE" was dropped since...
> 
> a) it does not exist in the package spec file
> 
> b) upstream wont accept submitted units with /etc/sysconfig/ files which 
> means those that still want to do this will need start carrying patches 
> in the form of EnvironmentFile=-/etc/sysconfig/$SERVICE against upstream 
> units to add this behaviour to units.
> 
> Doing so would go against our upstream mantra I believe
> 
> c) This is no longer necessary since users really should be following [1]
> 
> 
> > 2- how I do ? with systemd :
> > service iptables status
> 
> systemctl status iptables.service
> 
> iptables -L or for the exact initscript command that was used, run 
> /usr/libexec/iptables.init status
> 
> > service iptables save
> 
> iptables-save
> 
> or for the exact initscript command that was used, run 
> /usr/libexec/iptables.init save
> 
> > 3 - we got this message on /var/log/message systemd[1]: PID
> > file /run/sendmail.pid not readable (yet?) after start.
> 
> What's happening here is that sendmail is daemonizes itself in a racy way.
> 
> It exits the original process before the child writes the PID file which 
> means that when systemd attempts to read the service's PID file, it is 
> not there yet.
> 
> The proper steps to daemonize a process are described and can be found 
> in [2]
> 
> >
> > I thing we want read /var/run/sendmail.pid , are we missing /var ?
> 
> No we are not however since [3] all path should really be pointing to 
> /run at this point instead of that symlink...
> 
> JBG
> 
> 1. 
> http://fedoraproject.org/wiki/Systemd#How_do_I_customize_a_unit_file.2F_add_a_custom_unit_file.3F
> 2. http://0pointer.de/public/systemd-man/daemon.html
> 3. http://lists.fedoraproject.org/pipermail/devel/2011-March/150031.html

Thanks very much. 
I will checkout when I have time (could be not this week), I give you
feedback for good or for bad. 

Thanks, 
-- 
Sérgio M. B.

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

Re: "master" branch still invokes build in f17-candidate??

2012-02-28 Thread Richard W.M. Jones

On Mon, Feb 27, 2012 at 12:14:49PM -0800, Jesse Keating wrote:
> On 2/27/12 8:37 AM, Tom Lane wrote:
> >Orion Poplawski  writes:
> >>On 02/27/2012 09:09 AM, Tom Lane wrote:
> >>>WTF?  Do I need to fix this, and if so how?
> >
> >>git pull
> >>(to bring in the f17 branch and mark devel as f18)
> >
> >Hmm, that package indeed hadn't had f17 git pull'd yet.  (I had scripted
> >a git pull in all my package directories after the branch, but I think
> >that it failed in this one due to uncommitted changes.)
> >
> >So you're saying that fedpkg's behavior depends on the existence of
> >other, un-checked-out, branches in my local repo?  This seems a
> >tad ... unreliable.  Not to say surprising.
> >
> > regards, tom lane
> 
> I was looking for a way to determine the behavior of the master
> branch (for the sake of dist values) without hitting the network, as
> that would break git's ability to work offline.  The best I could
> come up with at the time this code was written was to check and see
> what other branches existed, and just increment the biggest one by
> one.  I welcome suggestions for better ways to manage this.

Didn't RHEL-CVS use a file in the local directory called 'branch'(?)

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: Don't be afraid to ask for help

2012-02-28 Thread Sérgio Basto

On Mon, 2012-02-27 at 08:42 -0600, Jon Ciesla wrote: 
> On Mon, Feb 27, 2012 at 8:05 AM, Bruno Wolff III  wrote:
> > I am sending this because, we have a lot of FTBFS packages which I have
> > see at least one blog griping about, I accidentally fixed something that
> > was blocking other work (in the sense that I didn't know that other work
> > that I wouldn't have to do was waiting for this problem to be solved) and
> > I fixed something for someone that asked for help in a roundabout way.
> >
> > We are all not experts in everything and it isn't a problem to ask for
> > help if you are stuck on something for a package. Someone else on the
> > devl list (or one of the programming language specific lists) may be able
> > to easily solve a problem that you could spend hours on without making
> > a lot of progress.
> >
> > For those that can help, doing so is a good idea. By removing a blocker
> > you let someone else do work they can do on Fedora. By showing them
> > the resolution, they may be able to resolve similar situations when they
> > see them again, including cases when other developers run across the
> > problem. It's nice to help your fellow contributors. Fixing things makes
> > Fedora better for everyone.
> 
> Seconded.
> 
> And if anyone has gcc47 or libpng FTBFS issues, this is a great place
> to ask for help on them.

I have with VirtualBox (again) 
but is a Kbuild problem 
http://koji.fedoraproject.org/koji/packageinfo?packageID=7356
The biggest problem (now) is with one package on fedora kbuild ? 
kmk_sed stops to work correctly on F17 .

/usr/bin/kmk_sed:
file 
/builddir/build/BUILD/VirtualBox-4.1.8_OSE/src/VBox/Runtime/common/err/errmsg.sed
 line 31: Unmatched [ or [^

see this bug report, please:
https://www.virtualbox.org/ticket/10160

any clue is welcomed 

Thanks, 
-- 
Sérgio M. B.

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

Re: Don't be afraid to ask for help

On Tue, Feb 28, 2012 at 10:10:36 -0600,
  Bruno Wolff III  wrote:
> On Tue, Feb 28, 2012 at 10:07:14 -0600,
>   Bruno Wolff III  wrote:
> > On Tue, Feb 28, 2012 at 10:06:21 -0600,
> >   Jon Ciesla  wrote:
> > > 
> > > I'm not sure, reading that, if the fix is on it's way to pulseaudio or
> > > not.  Which makes me hesitant to commit a patch, though I would be
> > > happy to if needed.
> > 
> > Bluez has a build from today with the fix.
> > I'll grab it and see if just installing it (the bluez update) gets 
> > pulseaudio
> > to build. If so I'll fire off a build.
> 
> So far there is only an f18 bluez build. That will work for my testing,
> but that won't let me easily to an f17 build.

Nottingham appears to be getting an F17 bluez rebuild ready right now.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Don't be afraid to ask for help

On Tue, Feb 28, 2012 at 10:07:14 -0600,
  Bruno Wolff III  wrote:
> On Tue, Feb 28, 2012 at 10:06:21 -0600,
>   Jon Ciesla  wrote:
> > 
> > I'm not sure, reading that, if the fix is on it's way to pulseaudio or
> > not.  Which makes me hesitant to commit a patch, though I would be
> > happy to if needed.
> 
> Bluez has a build from today with the fix.
> I'll grab it and see if just installing it (the bluez update) gets pulseaudio
> to build. If so I'll fire off a build.

So far there is only an f18 bluez build. That will work for my testing,
but that won't let me easily to an f17 build.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Don't be afraid to ask for help

On Tue, Feb 28, 2012 at 10:06:21 -0600,
  Jon Ciesla  wrote:
> 
> I'm not sure, reading that, if the fix is on it's way to pulseaudio or
> not.  Which makes me hesitant to commit a patch, though I would be
> happy to if needed.

Bluez has a build from today with the fix.
I'll grab it and see if just installing it (the bluez update) gets pulseaudio
to build. If so I'll fire off a build.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Don't be afraid to ask for help

On Tue, Feb 28, 2012 at 9:56 AM, Bruno Wolff III  wrote:
> On Mon, Feb 27, 2012 at 20:22:56 -0800,
>  Adam Williamson  wrote:
>>
>> Well, pulseaudio doesn't currently build, and that's preventing us from
>> fixing the bug that audio doesn't work in F17. The problem is apparently
>> in assembler code, though, so fixing it is unlikely to be trivial.
>>
>> Lennart was working on it, but I've not heard from him on that for a few
>> days.
>
> It looks like this is on its way to being solved.
> Lennart asked about this and in the thread got this reply:
> http://www.mail-archive.com/pulseaudio-discuss%40lists.freedesktop.org/msg02702.html
> Which referenced this fix.
> http://pkgs.fedoraproject.org/gitweb/?p=bluez.git;a=blob;f=sbc_mmx.patch;h=2f00bb6856fb8e313f332d8ed90ca65a3a58de3a;hb=HEAD
> Even though this is in bluez, it looks like it is probably inlined into
> pulseaudio as the file has the same name in pulseaudio.
>
> I tried making the same change in the pulseaudio file and make finished.
> (I didn't do a complete change to allow fedpkg local to work.)
>
> So it looks like checking on the status of the bluez update and once that's
> in place rebuilding pulseaudio.
>
> I am not sure what will happen if you make the change locally in pulseaudio
> and not have the bluez change in place. However, that might be the lesser
> of two evils if the current problem is bad enough.

I'm not sure, reading that, if the fix is on it's way to pulseaudio or
not.  Which makes me hesitant to commit a patch, though I would be
happy to if needed.

-J

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



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

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

Re: Don't be afraid to ask for help

On Mon, Feb 27, 2012 at 20:22:56 -0800,
  Adam Williamson  wrote:
> 
> Well, pulseaudio doesn't currently build, and that's preventing us from
> fixing the bug that audio doesn't work in F17. The problem is apparently
> in assembler code, though, so fixing it is unlikely to be trivial.
> 
> Lennart was working on it, but I've not heard from him on that for a few
> days.

It looks like this is on its way to being solved.
Lennart asked about this and in the thread got this reply:
http://www.mail-archive.com/pulseaudio-discuss%40lists.freedesktop.org/msg02702.html
Which referenced this fix.
http://pkgs.fedoraproject.org/gitweb/?p=bluez.git;a=blob;f=sbc_mmx.patch;h=2f00bb6856fb8e313f332d8ed90ca65a3a58de3a;hb=HEAD
Even though this is in bluez, it looks like it is probably inlined into
pulseaudio as the file has the same name in pulseaudio.

I tried making the same change in the pulseaudio file and make finished.
(I didn't do a complete change to allow fedpkg local to work.)

So it looks like checking on the status of the bluez update and once that's
in place rebuilding pulseaudio.

I am not sure what will happen if you make the change locally in pulseaudio
and not have the bluez change in place. However, that might be the lesser
of two evils if the current problem is bad enough.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Don't be afraid to ask for help

On Tue, Feb 28, 2012 at 8:46 AM, Jon Ciesla  wrote:
> On Mon, Feb 27, 2012 at 10:22 PM, Adam Williamson  wrote:
>> On Mon, 2012-02-27 at 08:42 -0600, Jon Ciesla wrote:
>>
>>> Seconded.
>>>
>>> And if anyone has gcc47 or libpng FTBFS issues, this is a great place
>>> to ask for help on them.
>>
>> Well, pulseaudio doesn't currently build, and that's preventing us from
>> fixing the bug that audio doesn't work in F17. The problem is apparently
>> in assembler code, though, so fixing it is unlikely to be trivial.
>>
>> Lennart was working on it, but I've not heard from him on that for a few
>> days.
>
> Agreed, it's not likely.  And I'm certain my assembler-fu is weaker
> than nearly anyone else's, to say nothing of Lennart's.  But I may
> peek anyway, if for no other reason than to satisfy my own curiosity.

Heh.  Yeah.  No.  Way over my head. :/

> -J
>
>> --
>> 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
>
>
>
> --
> in your fear, seek only peace
> in your fear, seek only love
>
> -d. bowie



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

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

[Test-Announce] Meat the Beefy Miracle: Announcing the release of Fedora 17 Alpha!

2012-02-28 Thread Dennis Gilmore

Hot dog! The Fedora 17 "Beefy Miracle" Alpha Release is available! This 
release offers a preview of some of the best and meatiest free and open 
source technology currently under development. Relish in a glimpse of 
the future:

http://fedoraproject.org/get-prerelease

== What is the Alpha release? ==

The Alpha release contains all the bunderful features of Fedora 17 in a 
form that anyone can help test. This testing, guided by the Fedora QA 
team, helps us target and identify bugs. When these bugs are fixed, we 
make a Beta release available. A Beta release is code-complete, and 
bears a very strong resemblance to the third and final release. The 
final release of Fedora 17 is due in early May.
Frankly, we think Fedora 17 will be the best release ever, but we know 
we can't do it without your help. Please take a moment of your time to 
download and try out the Alpha and make sure the things that are 
important to you are working. If you find a bug, please report it -- 
every bug you uncover is a chance to improve the experience for millions 
of Fedora users worldwide. Together, we can make Fedora a franktastic, 
rock-solid distribution. (Read down to the end of this announcement for 
more information on how to help.)

== Condiments ==

When we said Beefy, we weren't kidding: an a-bun-dance of condiments, 
err, features, are available to help you feed your hunger for the best 
in free and open source software. We take pride in our toppings, and in 
our fine ingredients; Fedora 17 includes both over- and under-the-bun 
improvements that show off the power and flexibility of the advancing 
state of free (range) software.

Check out our menu, certain to please a variety of appetites:

* End Users *

End users will see numerous improvements in Fedora 17.

* GIMP has been updated to the long awaited 2.8 release, with an 
a-bun-dant list of new features, such as the single window mode, layer 
groups, and on-canvas text editing.
* Improved language and font support: A number of Lohit fonts, enabling 
Indian script, have been added, as well as support for Inscript 2 for 
keymapping; libpinyin increases pinyin input speed by adding predictive 
intelligence.
* Desktops galore! Whether you like your bun covered in GNOME, KDE, 
Sugar, or otherwise, we've updated it to the sauciest, tastiest version 
available. 


* Systems Administrators *

Serving up hot dogs all day long? Increase your reliability and 
versatility with the new enhancements to the clustering stack in Fedora 
17. Load balancing and high availability improvements have been made, 
allowing systems administrators to deploy Fedora in environments 
requiring greater availability and clustered file systems; both Corosync 
2.0 and the Pacemaker Cluster Resource Manager 1.1.7 are included. JBoss 
Application Server (AS) 7 has also been added to Fedora 17; this fast, 
lightweight, and modular application server allows you to run full Java 
EE applications.

* Developers *

Developers can cook up fresh code with the updates and additions of 
numerous languages in Fedora 17. Java 7, Ruby 1.9.3, and PHP 5.4 are 
just some of the latest-and-greatest; we've also got updates and 
additions in the Haskell platform, Erlang, and D, as well as the 
addition of the Opa programming language. GCC has been updated to 4.7, 
and Fedora 17 has additionally been rebuilt with this new version, 
resulting in compiled code improvements.

* Virtualization *

A a-bun-dance of virtualization features are ready for consumption in 
Fedora 17:

* Open vSwitch is a flexible, multi-layer software switch typically used 
in virtualization environments as the network switching component in the 
hypervisor, providing virtual machines their network connectivity.
* KVM improvements, including the addition of a virtualized PMU 
(performance monitoring unit)for guests, and a live block copy features, 
allowing an image backing a guest disk to be copied while the guest is 
online.
* Virtualization sandboxing provides a new application development 
library (libvirt-sandbox) to facilitate the embedding of virtualization. 


* Hot Dogs as a Service (HDaaS) *

Kidding! We couldn't resist jumping into the game with our own acronym. 
Seriously, though, we have a frank-tastic variety of cloud technologies 
coming in Fedora 17, including the fresh additions of some of the best 
Infrastructure-as-a-Service (IaaS) platforms in free and open source 
software -- Cloudstack, Eucalyptus, and OpenNebula. OpenStack gets 
bumped in Fedora 17 to the Es

Re: FAS Country Code (fwd)

2012-02-28 Thread Paul Wouters


On Mon, 27 Feb 2012, Toshio Kuratomi wrote:


On Sun, Feb 26, 2012 at 10:17:00PM -0500, Paul Wouters wrote:


I already re-set it to Canada, and it seemed to make no changes, and I
mailed ad...@fedoraproject.org a week or so ago.

What is generating these, and who to contact to fix these?


See if you can change it now.

Your country_code was set to the empty string... I think it should have been
Null instead.


Why? Any country as long as it is US? :)


Not sure why it was set to empty string (changes to country
code aren't one of the logged actions).


I went in and set it to Canada again and saved. But like I said, it also
shows up as Canada to begin with, so not sure if it did anything at all.

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

Re: Don't be afraid to ask for help

On Mon, Feb 27, 2012 at 10:22 PM, Adam Williamson  wrote:
> On Mon, 2012-02-27 at 08:42 -0600, Jon Ciesla wrote:
>
>> Seconded.
>>
>> And if anyone has gcc47 or libpng FTBFS issues, this is a great place
>> to ask for help on them.
>
> Well, pulseaudio doesn't currently build, and that's preventing us from
> fixing the bug that audio doesn't work in F17. The problem is apparently
> in assembler code, though, so fixing it is unlikely to be trivial.
>
> Lennart was working on it, but I've not heard from him on that for a few
> days.

Agreed, it's not likely.  And I'm certain my assembler-fu is weaker
than nearly anyone else's, to say nothing of Lennart's.  But I may
peek anyway, if for no other reason than to satisfy my own curiosity.

-J

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



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

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

Re: Need help with systemd service files

2012-02-28 Thread Juerg Haefliger

On Tue, Feb 28, 2012 at 12:02 PM, Michal Schmidt  wrote:
> On 02/26/2012 07:37 AM, Garrett Holmstrom wrote:
>>
>> On 2012-02-24 4:22, Juerg Haefliger wrote:
>>>
>>> So I installed the official Fedora version of cloud-init but the
>>> service startup ordering is broken there too:
>>>
>>> [root@342 ~]# dmesg | grep cloud | grep About
>>> [   91.668396] systemd[1]: About to execute: /usr/bin/cloud-init
>>> start-local
>>> [   91.993238] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all
>>> config
>>> [   92.540255] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all
>>> final
>>> [   92.559834] systemd[1]: About to execute: /usr/bin/cloud-init start
>
>
> I can't reproduce the problem. They are started in the expected order here.
>
> Juerg,
> is this a log of the order during boot? Or did you test the services by
> listing all 4 of them in systemctl start ...?
> The latter would show bug 704214.


This is the boot order. Different than the last time:

[root@fedora ~]# dmesg | grep cloud
[1.639947] systemd[1]: Installed new job cloud-config.service/start as 80
[1.639952] systemd[1]: Installed new job cloud-config.target/start as 81
[1.639957] systemd[1]: Installed new job
cloud-init-local.service/start as 82
[1.639961] systemd[1]: Installed new job cloud-init.service/start as 83
[1.639966] systemd[1]: Installed new job cloud-final.service/start as 84
[1.640413] systemd[1]: cloud-config.target changed dead -> active
[1.640426] systemd[1]: Job cloud-config.target/start finished, result=done
[   91.676503] systemd[1]: About to execute: /usr/bin/cloud-init start-local
[   91.686093] systemd[1]: Forked /usr/bin/cloud-init as 489
[   91.686227] systemd[1]: cloud-init-local.service changed dead -> start
[   91.990133] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all config
[   91.998048] systemd[1]: Forked /usr/bin/cloud-init-cfg as 549
[   91.998213] systemd[1]: cloud-config.service changed dead -> start
[   92.364807] systemd[1]: Received SIGCHLD from PID 549 (cloud-init-cfg).
[   92.364835] systemd[1]: Got SIGCHLD for process 549 (cloud-init-cfg)
[   92.364877] systemd[1]: Child 549 belongs to cloud-config.service
[   92.364889] systemd[1]: cloud-config.service: main process exited,
code=exited, status=0
[   92.375143] systemd[1]: cloud-config.service changed start -> exited
[   92.375160] systemd[1]: Job cloud-config.service/start finished, result=done
[   92.375264] systemd[1]: Got SIGCHLD for process 489 (cloud-init)
[   92.375302] systemd[1]: Child 489 belongs to cloud-init-local.service
[   92.375311] systemd[1]: cloud-init-local.service: main process
exited, code=exited, status=1
[   92.376121] systemd[1]: cloud-init-local.service changed start -> failed
[   92.377151] systemd[1]: Job cloud-init-local.service/start
finished, result=failed
[   92.377175] systemd[1]: Unit cloud-init-local.service entered failed state.
[   92.377833] systemd[1]: About to execute: /usr/bin/cloud-init start
[   92.385184] systemd[1]: Forked /usr/bin/cloud-init as 599
[   92.385262] systemd[1]: cloud-init.service changed dead -> start
[   92.385293] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all final
[   92.393218] systemd[1]: Forked /usr/bin/cloud-init-cfg as 600
[   92.393358] systemd[1]: cloud-final.service changed dead -> start
[   92.394075] systemd[1]: cloud-config.service: cgroup is empty
[   92.394927] systemd[1]: cloud-init-local.service: cgroup is empty
[   92.550734] systemd[1]: Received SIGCHLD from PID 600 (cloud-init-cfg).
[   92.550760] systemd[1]: Got SIGCHLD for process 600 (cloud-init-cfg)
[   92.550803] systemd[1]: Child 600 belongs to cloud-final.service
[   92.550810] systemd[1]: cloud-final.service: main process exited,
code=exited, status=0
[   92.559058] systemd[1]: cloud-final.service changed start -> exited
[   92.559072] systemd[1]: Job cloud-final.service/start finished, result=done
[   92.559522] systemd[1]: cloud-final.service: cgroup is empty
[  116.415829] systemd[1]: Received SIGCHLD from PID 599 (cloud-init).
[  116.415854] systemd[1]: Got SIGCHLD for process 599 (cloud-init)
[  116.415896] systemd[1]: Child 599 belongs to cloud-init.service
[  116.415908] systemd[1]: cloud-init.service: main process exited,
code=exited, status=0
[  116.422236] systemd[1]: cloud-init.service changed start -> exited
[  116.422252] systemd[1]: Job cloud-init.service/start finished, result=done
[  116.422760] systemd[1]: cloud-init.service: cgroup is empty
[root@fedora ~]# dmesg | grep cloud | grep Ab
[   91.676503] systemd[1]: About to execute: /usr/bin/cloud-init start-local
[   91.990133] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all config
[   92.377833] systemd[1]: About to execute: /usr/bin/cloud-init start
[   92.385293] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all final

Send me your public key and I'll hook you up with access to the VM if
you want to poke around.

...Juerg


> Michal
>
> --
> devel mailing list
> devel@li

Re: PCRE 8.30 will break API

2012-02-28 Thread Petr Pisar

On 2012-02-09, Petr Pisar  wrote:
> It's long time since PCRE (Perl-Compatible Regular Expression) library
> has changed API or ABI. Version 8.30 is different.
[...]
> Result is pcre library has changed SONAME from libpcre.so.0 to
> libpcre.so.1.
>
I'm pleased to announce all reverse dependencies of PCRE have been
rebuilt successfully against new libpcre.so.1 library. Old libpcre.so.0
has been removed and new library moved into /usr in pcre-8.30-2.fc18
which is landing into F18 now.

I'd like to thank everybody who helped me with this transition. This
PCRE upgrade will be highlighted as F18 feature
.

-- Petr

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

File Catalyst-Action-REST-0.99.tar.gz uploaded to lookaside cache by iarnell

2012-02-28 Thread Iain Arnell

A file has been added to the lookaside cache for perl-Catalyst-Action-REST:

3817a9a2514f76bf853aac0427678fae  Catalyst-Action-REST-0.99.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Provenpackager? Want to help out?