Re: Grub2

[Adam Williamson]

On Fri, 2012-12-07 at 12:51 -0800, les wrote:

> Hi, Johan,
>   No joy!  Reboot then ran through the disk stuff, then a quick flash of
> something about grub in big text, then back to the small text and
> apparently the fine resolution screen.  I could not trap the message
> screen despite several attempts.  I think there should be a grub log, so
> I will look at the manual some more and work on figuring this out.
> Thanks for your help.
> 
> For the developers, think about adding the grub change stuff to the
> universal access stuff in some way.  It is tough when it is hard to use
> the various stuff to figure things out when you are working with a
> disadvantage to begin with.
> 
> Thanks, Johan, and by the way, I found the manual this time in my web
> search.  I needed that.

Hi Les, do the comments on this bug report:

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

help you in changing the font size at all? From memory, what you need to
do is edit /boot/grub2/themes/system/theme.txt and change the font sizes
specified there, then re-generate the grub2 config and possibly re-do
grub2-install (I forget exactly which steps are required). I'm not sure
if there's an 'update-safe' way of doing this.
-- 
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: Where are we going? (Not a rant)

[Ralf Corsepius]

On 12/08/2012 06:07 AM, M. Edward (Ed) Borasky wrote:

On Fri, Dec 7, 2012 at 7:26 PM, Arun SAG  wrote:



On Fri, Dec 7, 2012 at 5:32 AM, "Jóhann B. Guðmundsson" 
wrote:




If we want to solve this we need to release an Fedora LTS release for our
and the potential other user >base that don't have to/want to update every 6
or 12 months.




Completely agree on this one. In my day job we started using Fedora as one
of our desktop os. Then support  issues and upgrade cycle started giving
nightmares to corp IT. They are looking at other avenues now. I really wish
there is a LTS release for this awesome distro -  Fedora.


Why does there need to be a long-term support for Fedora?


My primary problem with Fedora isn't "lack of stability", but lack of 
API/ABI and UI-stability/persistence/sustainability between upgrades.


In other words, I can cope with the number of crashes upgrades typically 
come along with, but the number "UI-changes" is what makes Fedora 
difficult to use for me.



Why not just
use Red Hat Enterprise Linux?


My view: RHEL is not an alternative to Fedora. CentOS would be a 
candidate alternative to Fedora, however due to the nature of its 
upstream and its upstream target audience (servers) it lacks a lot to be 
functionally "on par" with Fedora.


That said, if I was managing a larger network, I'd likely choose CentOS 
as base OS and harvest Fedora to setup a custom "add-on" repo.


Ralf

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

Re: Where are we going? (Not a rant)

[Clyde E. Kunkel]

On 12/08/2012 12:07 AM, M. Edward (Ed) Borasky wrote:


Why does there need to be a long-term support for Fedora? Why not just
use Red Hat Enterprise Linux?



I imagine it boils down to money since Fedora=free and RHEL=$$$. 
Corporate suits will will weigh cost of Fedora support vs RHEL support 
and decide accordingly.


Or if money is an issue use Centos.

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

Re: Where are we going? (Not a rant)

[M. Edward (Ed) Borasky]

On Fri, Dec 7, 2012 at 7:26 PM, Arun SAG  wrote:
>
>
> On Fri, Dec 7, 2012 at 5:32 AM, "Jóhann B. Guðmundsson" 
> wrote:
>>
>>
>> >If we want to solve this we need to release an Fedora LTS release for our
>> > and the potential other user >base that don't have to/want to update every 
>> > 6
>> > or 12 months.
>
>
>
> Completely agree on this one. In my day job we started using Fedora as one
> of our desktop os. Then support  issues and upgrade cycle started giving
> nightmares to corp IT. They are looking at other avenues now. I really wish
> there is a LTS release for this awesome distro -  Fedora.

Why does there need to be a long-term support for Fedora? Why not just
use Red Hat Enterprise Linux?

-- 
Twitter: http://twitter.com/znmeb; Computational Journalism Publishers
Workbench: 
http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/

How the Hell can the lion sleep with all those people singing "A weem
oh way!" at the top of their lungs?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Detecting soname bumps

[Orion Poplawski]

On 12/06/2012 05:39 AM, Kamil Paral wrote:

Are we talking about something like this:
http://autoqa.fedoraproject.org/results/471217-autotest/virt02.qa/rpmguard/results/libmemcached-1.0.14-.html
and this:
http://autoqa.fedoraproject.org/results/471217-autotest/virt02.qa/rpmguard/results/libmemcached-1.0.14-.html
?

We're doing very poor job announcing it, but we run the tool on every new 
package build in Koji.


While Ville makes the appropriate point that the attentive packager 
should catch this, the overworked packager may not :(.  I missed a 
soname bump of one of many libraries (which turned out to be an upstream 
mistake) in a minor version update of openmpi, and it would have been 
good to have caught that before it was built in koji.  I guess you can 
untag builds, but that is even more build-system voodoo to know.


In fact, I tend to try to avoid many wild cards in my packages to help 
notice unexpected changes.


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

Re: Where are we going? (Not a rant)

[Arun SAG]

On Fri, Dec 7, 2012 at 5:32 AM, "Jóhann B. Guðmundsson"
wrote:

>
> >If we want to solve this we need to release an Fedora LTS release for our
> and the potential other user >base that don't have to/want to update every
> 6 or 12 months.
>


Completely agree on this one. In my day job we started using Fedora as one
of our desktop os. Then support  issues and upgrade cycle started giving
nightmares to corp IT. They are looking at other avenues now. I really wish
there is a LTS release for this awesome distro -  Fedora.


-- 
Arun S A G
http://zer0c00l.in/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Test-Announce] Fedora 18 Final Test Compose 1 (TC1) Available Now!

[Andre Robatino]

As per the Fedora 18 schedule [1], Fedora 18 Final Test Compose 1 (TC1)
is now available for testing. Content information, including changes,
can be found at https://fedorahosted.org/rel-eng/ticket/5406 . 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

Re: Where are we going? (Not a rant)

[Rahul]

On 12/07/2012 03:08 PM, "Jóhann B. Guðmundsson" wrote:



In the end if you are going to keep your machine secure et all you 
have to keep it disconnected there will always be bugs which can be 
exploited when you are network connected ;)


Smiley doesn't change the inane argument.

We don't with absolutes when it comes to security.  Fedora with updates 
is *more* secure than a Fedora version which doesn't get any updates any 
more.  Therefore, in general it is a bad idea to run a unmaintained 
Fedora on a system that is connected to the network.


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

Re: bugz.fedoraproject.org trouble

[Michael Schwendt]

On Fri, 7 Dec 2012 11:46:49 -0500, Ralph Bean wrote:

> >   http://bugz.fedoraproject.org/SOURCE-RPM-NAME
> > e.g.
> >   http://bugz.fedoraproject.org/gnome-packagekit

> I introduced the switch-over as per this ticket
> https://fedorahosted.org/fedoracommunity/ticket/381

Waiting for fedorahosted.org…

It has taken several attempts and unusually long time to load that ticket.

The ticket doesn't comment on any testing or tester feedback, however.

I've noticed the new web page interface some days ago, and it has rarely
managed to complete loading the dynamic contents without displaying
errors.

> You're quite right about this being poor timing.  I just reverted
> the alias, so bugz.fedoraproject.org/package-name should work again
> (using the pkgdb site). 

Thank you very much!

-- 
Fedora release 18 (Spherical Cow) - Linux 3.6.9-4.fc18.x86_64
loadavg: 0.02 0.04 0.08
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: What would it take to make Software Collections work in Fedora?

[Jon Masters]

On 12/07/2012 12:30 PM, Matthew Miller wrote:
> On Fri, Dec 07, 2012 at 10:40:13AM -0500, Jon Masters wrote:
>>> We could draw them between Core and Extras!
>> :) Note that just because we got rid of Core doesn't mean that it was a
>> bad idea. Ubuntu even adopted a "Core" of their own a while back. Maybe
> 
> The bad idea was the insider-vs-outsider mentality inherent in the way the
> split was made. I don't think anyone wants to go back to that, and, the
> above joke aside, I think it's clear that we wouldn't draw the line in the
> same way, and we would *definitely* have different rules than in those days.

Sure. Slight caveat that I do prefer Enterprise-leaning inspiration
everything ;) but I don't want a return to inside-vs-outside either.

> To a lot of people who weren't so close to all that, the name "Fedora Core"
> still has good connotations -- I still often meet people who refer to Fedora
> as that. I don't know what the balance in the community now is of people who
> have that kind of rosy-eyed fondness, people who are new and don't have a
> history either way, and people who remember the Dark Times and would be put
> off by the name.

Hey, it's still "fc18" (for various RPM versioning reasons) :)

>> they'll have the same experience we had and get away from that, or maybe
>> Linux distributions should ultimately not be in the business of
>> providing all+kitchen sink. Speaking only personally, what I want is a
>> stable core platform of very limited size against which I can install
>> other packages and stacks.
> 
> I think we *could* have both. There's no reason that Fedora couldn't make
> that stable core platform *and* provide layers above it. In fact, referring
> to
> https://fedoraproject.org/wiki/Overview?rd=FedoraProject:About#Our_Mission
> it seems pretty clear that both levels are in scope.

Sure we could. There's nothing to prevent a company or an organization
from shipping an OS as well as software that installs upon it. Plenty
do. But it's when one gets in the business of shoving in the kitchen
sink and believing that everything must be provided in the "one true
repo" that the problem comes. I want to be able to get packaged third
party software for distros like Fedora more easily. If there's an
expectation that some kind of platform compatibility has to exist, we
might even see that happen. I was encouraged last night that the latest
Altera design tools work on Fedora 17 with only one "compat" library
being installed, but I've been far less lucky with other stuff.

Jon.

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

Re: What would it take to make Software Collections work in Fedora?

[Bill Nottingham]

Marcela Mašláňová (mmasl...@redhat.com) said: 
> >You're using a Mac now, so good luck.
> >
> >But I'm pretty sure that software collections would not have helped
> >you to upgrade Libreoffice.  Which, by the way, is possible without
> >upgrading everything: just compile the later SRPMs.  In other words,
> >create your own backports repository, and find a group of people who
> >have the same problem to share the security and maintenance burden
> >around.
> >
> >Rich.
> >
> In that case he might use gentoo ;-) On the other hand create a
> collection for LibreOffice and support it would be a lot of work.

I would suspect, actually, that upgrading to a later LibreOffice is
fairly simple on a 'stable' release, if it was built for that release.
The problem comes when the only newer LibreOffice is built for the next
Fedora release, so it's linked against newer libicu/boost/clucene/etc/etc
that's only available in that later Fedora release, even though it doesn't
specifically *require* those newer library versions.

Of course, just doing an update for an older release breaks those who want
the older release to maintain stability at all costs. So the LibreOffice
case could be fixed by merely defining what's inside the always-stable set
vs. what's outside it and can be updated more frequently (and convincing
the maintainer to do so with LibreOffice.)

Bill

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

Re: Grub2

[les]

On Fri, 2012-12-07 at 20:20 +, "Jóhann B. Guðmundsson" wrote:
> On 12/07/2012 07:54 PM, les wrote:
> 
> > Hi, everyone,
> > My name is Les Howell.  I do semiconductor test programs for mainframe
> > ATE.
> > 
> > My current issue is with GRUB2.  I am slightly visually impaired due to
> > glaucoma.  This is important, because setting my system up to use bigger
> > fonts is vital for me to use it.  The problem I ran into when upgrading
> > to F17 from F16 is that the font settings do not work the same in Grub
> > 2.  I have worked very hard at finding solutions and using them from our
> > friend Google and from the forum, but have not yet been successful.  My
> > issue is therefore of several parts:
> > 1.  Where can I find a really good manual on Grub2?
> > 2.  What is the exact process to upgrade the font to say size 18 or so
> > in Grub2?
> > 
> > 3.  What is the exact process to change the font and color in Grub2.
> > 
> > I found a solution that seemed to appear redundantly on various places
> > that suggested the following process:
> > A. find the font you want.
> > B. use # grub-mkfont inputfontname -o /grub/fonts/fontname
> > C. edit /etc/default/grub by adding a line to the new font as:
> > GRUB_FONT="/boot/grub2/fonts/fontname"
> > D. use # grub-mkcfg
> > 
> > I did these steps, but no joy.  In addition, the fonts I tried all gave
> > me errors on one or more of the symbols (19 different fonts, mostly
> > mono-space or arial for visibility reasons.)
> > I know this is not a users forum, but this issue has implications that
> > need addressing at a much deeper stage.  
> > 
> > It is difficult for me to research this due to the vision problem, and
> > it is important for me to be able to participate more.
> > 
> > Thank you for your attention.
> > 
> > 
> 
> Does it help reducing the resolution via GRUB_GFXMODE= like
> GRUB_GFXMODE=640x480 ?
> 
> JBG
> 

Hi, Johan,
No joy!  Reboot then ran through the disk stuff, then a quick flash of
something about grub in big text, then back to the small text and
apparently the fine resolution screen.  I could not trap the message
screen despite several attempts.  I think there should be a grub log, so
I will look at the manual some more and work on figuring this out.
Thanks for your help.

For the developers, think about adding the grub change stuff to the
universal access stuff in some way.  It is tough when it is hard to use
the various stuff to figure things out when you are working with a
disadvantage to begin with.

Thanks, Johan, and by the way, I found the manual this time in my web
search.  I needed that.


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

Re: Where are we going? (Not a rant)

[Edward Mann]

 

On 07.12.2012 14:08, Jóhann B. Guðmundsson wrote: 

> On
12/07/2012 06:58 PM, Simo Sorce wrote:
> 
>> I do not care ab out
arguing with him, I care to give advice to others (if they care for my
advice, feel free to fully ignore). Don't follow that model, it's broken
security wise, unless you keep your machine disconnected from the
network.
> 
> In the end if you are going to keep your machine secure et
all you have 
> to keep it disconnected there will always be bugs which
can be exploited 
> when you are network connected ;)
> 
> I personally
think people should start worrying more about application 
> they
install on their mobile devices ( which they more often then not 
>
grant access to privacy information themselves ) or information they 
>
expose themselves on various social network sites willingly, unaware of

> the consequences it might have then having their OS cracked.
> 
> If
I was a crook I would simply use various online tracking sites or 
>
social networking sites to monitor whether you are home or not and 
>
simply rob you when your post on your status that you have gone on 
>
holidays next to the picture of your house tagged with the geographical

> coordinates to it or when an app places you on Starbucks.
> 
> Or I
would collect all those idiotic question people have to provide 
>
answer on various online sites including banks cross reference them to

> you social network pages and your posts, then simply call your bank,

> provide answer to those questions and wipe your account clean.
> 
>
Much more simpler, probably pays better of in the end and harder to 
>
track down compared to cracking your laptop OS or explode a bug which 
>
requires you to be a skilled programmer or cryptography engineer to pull

> it of..
> 
> Seriously why bother cracking people OS to get to this
information when 
> it gets handed to you on silver platter by the
individuals themselves 
> online?
> 
> JBG
> 
> "There's a war out
there, old friend. A world war. And it's not about 
> who's got the most
bullets. It's about who controls the information. 
> What we see and
hear, how we work, what we think... it's all about the 
> information!"
Cosmo

Go after the old folks, apparently they are the most recent
targets 

http://www.michigan.gov/ag/0,4534,7-164-18156-205169--,00.html


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

Re: Grub2

[les]

On Fri, 2012-12-07 at 20:20 +, "Jóhann B. Guðmundsson" wrote:
> On 12/07/2012 07:54 PM, les wrote:
> 
> > Hi, everyone,
> > My name is Les Howell.  I do semiconductor test programs for mainframe
> > ATE.
> > 
> > My current issue is with GRUB2.  I am slightly visually impaired due to
> > glaucoma.  This is important, because setting my system up to use bigger
> > fonts is vital for me to use it.  The problem I ran into when upgrading
> > to F17 from F16 is that the font settings do not work the same in Grub
> > 2.  I have worked very hard at finding solutions and using them from our
> > friend Google and from the forum, but have not yet been successful.  My
> > issue is therefore of several parts:
> > 1.  Where can I find a really good manual on Grub2?
> > 2.  What is the exact process to upgrade the font to say size 18 or so
> > in Grub2?
> > 
> > 3.  What is the exact process to change the font and color in Grub2.
> > 
> > I found a solution that seemed to appear redundantly on various places
> > that suggested the following process:
> > A. find the font you want.
> > B. use # grub-mkfont inputfontname -o /grub/fonts/fontname
> > C. edit /etc/default/grub by adding a line to the new font as:
> > GRUB_FONT="/boot/grub2/fonts/fontname"
> > D. use # grub-mkcfg
> > 
> > I did these steps, but no joy.  In addition, the fonts I tried all gave
> > me errors on one or more of the symbols (19 different fonts, mostly
> > mono-space or arial for visibility reasons.)
> > I know this is not a users forum, but this issue has implications that
> > need addressing at a much deeper stage.  
> > 
> > It is difficult for me to research this due to the vision problem, and
> > it is important for me to be able to participate more.
> > 
> > Thank you for your attention.
> > 
> > 
> 
> Does it help reducing the resolution via GRUB_GFXMODE= like
> GRUB_GFXMODE=640x480 ?
> 
> JBG
> 
Hi, Johan,
Thank you for the suggestion.  I didn't consider that, but I should
have.

But this time I ran grub2-mkconfig, whereas I think the first time I ran
grub-mkconfig.  I could not find grub-mkconfig this time, so I must have
been incorrect.

Anyway, I edited /etc/default/grub and removed the font line and added
the GFXMODE line. 

I ran the command grub2-mkconfig -o grub.cfg and got the following
errors:
It returned several errors:
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.6.8-2.fc17.x86_64
Found initrd image: /boot/initramfs-3.6.8-2.fc17.x86_64.img
Found linux image: /boot/vmlinuz-3.3.4-5.fc17.x86_64
Found initrd image: /boot/initramfs-3.3.4-5.fc17.x86_64.img
ERROR: ddf1: seeking device "/dev/dm-4" to 18446744073709421056
ERROR: hpt37x: seeking device "/dev/dm-4" to 4608
ERROR: hpt45x: seeking device "/dev/dm-4" to 18446744073709547008
ERROR: pdc: seeking device "/dev/dm-4" to 137438913024
ERROR: pdc: seeking device "/dev/dm-4" to 137438920192
ERROR: pdc: seeking device "/dev/dm-4" to 137438927360
ERROR: pdc: seeking device "/dev/dm-4" to 137438934528
ERROR: sil: seeking device "/dev/dm-4" to 18446744073709289984
  No volume groups found
Found Windows Recovery Environment (loader)
on /dev/mapper/pdc_eadgiihiejp1
Found Windows 7 (loader) on /dev/mapper/pdc_eadgiihiejp2
done

I'm about to reboot and see what happens.  I did save a backup of the
grub.cfg just incase.

thanks,
Les H


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

Re: grub (v1) in f18?

[John Reiser]

On 12/07/2012 11:42 AM, Chris Murphy wrote:

> ext[234] has two boot sectors for a total of 1024 bytes. XFS has none. Btrfs 
> has 64KB.
> 
> It just seems like GRUB is a really familiar 4000 meter cargo train, compared 
> to an unfamiliar hand truck, for the task of moving half-dozen boxes. Maybe 
> I'm underestimating the size/weight of those boxes, but maintaining a grub 
> installation, let alone troubleshooting it if it breaks for some reason, is a 
> lot more complicated than some external source rewriting 1024 bytes to merely 
> two sectors.

Some real BIOS+MBR demand that the last 2 bytes in a boot sector be 0xAA55.
So sometimes the first sector has only 510 usable bytes.  If the same code
reads the second sector, then that sector also might have only 510 usable bytes.
Those 2+2 bytes mattered to me when I wrote mine.

-- 

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

Re: Grub2

[Jóhann B. Guðmundsson]

On 12/07/2012 07:54 PM, les wrote:

Hi, everyone,
My name is Les Howell.  I do semiconductor test programs for mainframe
ATE.

My current issue is with GRUB2.  I am slightly visually impaired due to
glaucoma.  This is important, because setting my system up to use bigger
fonts is vital for me to use it.  The problem I ran into when upgrading
to F17 from F16 is that the font settings do not work the same in Grub
2.  I have worked very hard at finding solutions and using them from our
friend Google and from the forum, but have not yet been successful.  My
issue is therefore of several parts:
1.  Where can I find a really good manual on Grub2?
2.  What is the exact process to upgrade the font to say size 18 or so
in Grub2?

3.  What is the exact process to change the font and color in Grub2.

I found a solution that seemed to appear redundantly on various places
that suggested the following process:
A. find the font you want.
B. use # grub-mkfont inputfontname -o /grub/fonts/fontname
C. edit /etc/default/grub by adding a line to the new font as:
GRUB_FONT="/boot/grub2/fonts/fontname"
D. use # grub-mkcfg

I did these steps, but no joy.  In addition, the fonts I tried all gave
me errors on one or more of the symbols (19 different fonts, mostly
mono-space or arial for visibility reasons.)
I know this is not a users forum, but this issue has implications that
need addressing at a much deeper stage.

It is difficult for me to research this due to the vision problem, and
it is important for me to be able to participate more.

Thank you for your attention.



|
Does it help reducing the resolution via GRUB_GFXMODE= like 
GRUB_GFXMODE=640x480 ?


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

Re: Where are we going? (Not a rant)

[Jóhann B. Guðmundsson]

On 12/07/2012 06:58 PM, Simo Sorce wrote:

I do not care ab out arguing with him, I care to give advice to others
(if they care for my advice, feel free to fully ignore).

Don't follow that model, it's broken security wise, unless you keep your
machine disconnected from the network.


In the end if you are going to keep your machine secure et all you have 
to keep it disconnected there will always be bugs which can be exploited 
when you are network connected ;)


I personally think people should start worrying more about application 
they install on their mobile devices ( which they more often then not 
grant access to privacy information themselves ) or information they 
expose themselves on various social network sites willingly, unaware of 
the consequences it might have then having their OS cracked.


If I was a crook I would simply use various online tracking sites or 
social networking sites to monitor whether you are home or not and 
simply rob you when your post on your status that you have gone on 
holidays next to the picture of your house tagged with the geographical 
coordinates to it or when an app places you on Starbucks.


Or I would collect all those idiotic question people have to provide 
answer on various online sites including banks cross reference them to 
you social network pages and your posts, then simply call your bank, 
provide answer to those questions and wipe your account clean.


Much more simpler, probably pays better of in the end and harder to 
track down compared to cracking your laptop OS or explode a bug which 
requires you to be a skilled programmer or cryptography engineer to pull 
it of..


Seriously why bother cracking people OS to get to this information when 
it gets handed to you on silver platter by the individuals themselves 
online?


JBG

"There's a war out there, old friend. A world war. And it's not about 
who's got the most bullets. It's about who controls the information. 
What we see and hear, how we work, what we think... it's all about the 
information!"  Cosmo

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

Grub2

[les]

Hi, everyone,
My name is Les Howell.  I do semiconductor test programs for mainframe
ATE.

My current issue is with GRUB2.  I am slightly visually impaired due to
glaucoma.  This is important, because setting my system up to use bigger
fonts is vital for me to use it.  The problem I ran into when upgrading
to F17 from F16 is that the font settings do not work the same in Grub
2.  I have worked very hard at finding solutions and using them from our
friend Google and from the forum, but have not yet been successful.  My
issue is therefore of several parts:
1.  Where can I find a really good manual on Grub2?
2.  What is the exact process to upgrade the font to say size 18 or so
in Grub2?

3.  What is the exact process to change the font and color in Grub2.

I found a solution that seemed to appear redundantly on various places
that suggested the following process:
A. find the font you want.
B. use # grub-mkfont inputfontname -o /grub/fonts/fontname
C. edit /etc/default/grub by adding a line to the new font as:
GRUB_FONT="/boot/grub2/fonts/fontname"
D. use # grub-mkcfg

I did these steps, but no joy.  In addition, the fonts I tried all gave
me errors on one or more of the symbols (19 different fonts, mostly
mono-space or arial for visibility reasons.)
I know this is not a users forum, but this issue has implications that
need addressing at a much deeper stage.  

It is difficult for me to research this due to the vision problem, and
it is important for me to be able to participate more.

Thank you for your attention.


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

Re: grub (v1) in f18?

[Chris Murphy]

On Dec 7, 2012, at 10:24 AM, "Richard W.M. Jones"  wrote:

> On Thu, Dec 06, 2012 at 03:25:21PM -0700, Chris Murphy wrote:
>> Why is a boot manager needed for a virtualized guest? It seems like all you 
>> need is to point to a virtual disk (or current or past snapshot) and go 
>> directly to loading the kernel. 
>> 
>> If I could stuff < 1024 bytes of boot loader into ext4's two boot sectors, 
>> that seems ways easier than dealing with grub.
>> http://lists.fedoraproject.org/pipermail/devel/2012-December/174786.html
> 
> [My second answer, now that I've looked at that code and understand
> better where you're going with this …]

I'm casually suggesting a vastly simpler means of boot loading a VM that 
doesn't have a dependency on grub. The host VM interface acting as the boot 
manager.
> 
> Yes, I think this is all possible, and probably better than emulating
> what the BIOS does.  Even better would be if you could get those 1024
> bytes down to 512 bytes (and thus fit it in a boot sector).  Then no
> changes to existing hypervisors would be needed at all, and it would
> run on baremetal.

ext[234] has two boot sectors for a total of 1024 bytes. XFS has none. Btrfs 
has 64KB.

It just seems like GRUB is a really familiar 4000 meter cargo train, compared 
to an unfamiliar hand truck, for the task of moving half-dozen boxes. Maybe I'm 
underestimating the size/weight of those boxes, but maintaining a grub 
installation, let alone troubleshooting it if it breaks for some reason, is a 
lot more complicated than some external source rewriting 1024 bytes to merely 
two sectors.


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

Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

[Till Maas]

On Fri, Dec 07, 2012 at 02:28:16PM -0500, Matthew Miller wrote:
> On Fri, Dec 07, 2012 at 08:11:08PM +0100, Till Maas wrote:
> > > * 960 - F18 schedule + the holidays  (notting, 18:50:29)
> > >   * LINK: https://fedoraproject.org/wiki/JaroslavReznik/FedupF18Final -
> > > not updated yet  (jreznik, 18:58:15)
> > >   * AGREED: Do not block on fedup signature checking (not a regression)
> > > (+:7, -:0, 0:0)  (notting, 19:08:47)
> > how is not providing a supported way to do secure upgrade of Fedora not
> > a regression? It is a big disappointment that Fedora is more and more
> 
> I assume because Anaconda has never done this. (Our dear old friend bug
> #998.)

Anaconda only needs to do this, if it is used for network installs. But
it was always possible to verify the DVD image and use the verified
packages from there: https://fedoraproject.org/verify

Some people even bothered to change the process from using MD5 or SHA1
to using SHA256 in the past.

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

Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

[Matthew Miller]

On Fri, Dec 07, 2012 at 08:11:08PM +0100, Till Maas wrote:
> > * 960 - F18 schedule + the holidays  (notting, 18:50:29)
> >   * LINK: https://fedoraproject.org/wiki/JaroslavReznik/FedupF18Final -
> > not updated yet  (jreznik, 18:58:15)
> >   * AGREED: Do not block on fedup signature checking (not a regression)
> > (+:7, -:0, 0:0)  (notting, 19:08:47)
> how is not providing a supported way to do secure upgrade of Fedora not
> a regression? It is a big disappointment that Fedora is more and more

I assume because Anaconda has never done this. (Our dear old friend bug
#998.)



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

Re: Where are we going? (Not a rant)

[Mark Bidewell]

>  For example, making it so key applications and development stacks could
>> easily float from one base OS to the next would make it less of an issue
>> when the base OS needs to be upgraded.
>>
>
> Not sure I catch your drift here, but it sounds like it could cause API
> mismatch headaches.
>
>>
>>
It underscores the need for the base OS or core to be absolutely as small
as possible.  FreeBSD provides a good model, small installed system
customized with packages/ports.  Personally I would like to see a
three-level approach:

Level 1 (Core) - OS Kernel, command-line utilities, C/C++ compiler and libc
- moves the slowest.
Level 2 (System) - Dev Libraries, interpreters (Python, Ruby, etc), X11,
KDE/QT, GNOME, etc - moves faster.
Level 3 (Userland) - LibreOffice, Firefox, Games, etc.

A major change to one level should cause a rebuild of higher layers to
avoid the API issues you mention.  Changes within a layer should be
independent.  I would propose change rates of:

Level 1 - 12-18 mos
Level 2 - 6-12 mos
Level 3 - release as soon as stable packages are available.

-- 
Mark Bidewell
http://www.linkedin.com/in/markbidewell
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: grub (v1) in f18?

[Panu Matilainen]

On 12/07/2012 07:59 PM, Matthew Miller wrote:

On Fri, Dec 07, 2012 at 06:49:25PM +0200, Panu Matilainen wrote:

My comment was simply on the "if you have both" part: it's not
really possible to have both without playing dirty tricks, so even
the "if" is pretty moot.


My point is that it's not really possible to have *grub* without playing
tricks (maybe not dirty ones).


Sure, I'm not arguing to the contrary :)




Yes, I think we're both trying to say the same thing: there's no
point having 'grub' in the repositories as its not installable or
usable in practise. The same goes for bunch of other obsoleted
packages as well.


Are there other obsoleted packages in the F18 repo?


Yes there are, see 
http://lists.fedoraproject.org/pipermail/buildsys/2012-November/004004.html 
for a few examples of obsoleted packages that are not only in the 
repositories but getting pulled into DVD images too (or at least were at 
the time, haven't looked after that).



Is there a good way to
look for them and to clean them up before release?


Should be doable with repoquery, but a custom script is likely to do a 
better job. I can have a look when I'm a bit more awake than now, its 
not exactly rocket science anyway.


- Panu -

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

Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

[Till Maas]

On Wed, Dec 05, 2012 at 03:20:14PM -0500, Bill Nottingham wrote:

> * 960 - F18 schedule + the holidays  (notting, 18:50:29)
>   * LINK: https://fedoraproject.org/wiki/JaroslavReznik/FedupF18Final -
> not updated yet  (jreznik, 18:58:15)

>   * AGREED: Do not block on fedup signature checking (not a regression)
> (+:7, -:0, 0:0)  (notting, 19:08:47)

how is not providing a supported way to do secure upgrade of Fedora not
a regression? It is a big disappointment that Fedora is more and more
turning its back on security. If I remember correctly, Fedora was one of
the leading distributions providing and using signed packages. But with
time this is more and more invalidated and people are more and more
expected to install unsigned packages or not to verify them.  At least
back in 2010 malicious mirrors were still acknowledged as a security
risk for Fedora users and signed packages were mentioned as a counter
measure:
https://fedoraproject.org/wiki/Mirror_manager_security_risks
How come it became less important now? Actually it is even easier to
attack users as more and more mobile devices are used. And what is even
worse, the whole problem of not verifying packages on upgrade or the
upgrade image itself is not even prominently communicated. There is
nothing in the release notes about this:
http://docs.fedoraproject.org/en-US/Fedora/18/html/Release_Notes/sect-Release_Notes-Changes_for_Sysadmin.html#idm32350976

I am very disappointed about this and I think this this a bad decission.
:-(

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

Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

[Jóhann B. Guðmundsson]

On 12/07/2012 06:37 PM, Michael Scherer wrote:

While I cannot answer for Jóhann, I think a proposal could be to
contact for example QA, as some features will have a huge impact for
them. Contact irc support, as they may have some insight on the common
issue reported by people, etc.


We have a track instance in QA to use for these things no need tie that 
to single individual sitting on some feature council...


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

Re: Where are we going? (Not a rant)

[Simo Sorce]

On Fri, 2012-12-07 at 18:13 +, "Jóhann B. Guðmundsson" wrote:
> On 12/07/2012 04:59 PM, Simo Sorce wrote:
> > On Fri, 2012-12-07 at 16:47 +, "Jóhann B. Guðmundsson" wrote:
> >> On 12/07/2012 03:51 PM, David Woodhouse wrote:
> >>> On Fri, 2012-12-07 at 15:40 +0100, Caterpillar wrote:
>  The unique and most impotant negative feedback I had it when I
>  upgraded a system from Fedora 14 to 15, that was the upgrade from
>  Gnome 2 to Gnome 3.
>  …
>  Fedora community should test big transitions like Gnome 2->3 for a
>  longer period of time
> >>> FWIW if it was running Fedora 14 and the user was content with it, I
> >>> probably wouldn't have upgraded to Fedora 15. You could have waited 6
> >>> months and gone straight to Fedora 16. GNOME 3 was a bit better by then.
> >>>
> >>> I upgrade my *own* machines fairly aggressively — this box has been
> >>> running Fedora 18 since August 31st for example. But I don't necessarily
> >>> upgrade everyone's machine to *every* Fedora release.
> >> I know one *nix gray beard that is still running F9 on his workstation
> >> because it's setup just the way he likes it and it works for him.
> >>
> >> He does not have the time to spare both from work/coding and his
> >> personal life to spend hours to setup his system or constantly having to
> >> upgrade/re-install fighting and patching whatever nuance that release
> >> brings, distracting him from doing actual real work and says that's for
> >> GNU/Linux kids, he rather spend that time with his grankids.
> >>
> >> His upgrade cycle is tied to the life cycle of his hw...
> > He should have chosen to install RHEL/CentOS/etc... then.
> 
> That's your opinion

Of course, I do not claim to posses *the truth*

> > Staying on F9 as a developer is a questionable stance.
> 
> Not if you know what your are doing

Self maintenance is *certainly* more time consuming than updating Fedora
releases and relying on the work of others if you are talking about
security.

> Oh I mentioned that to him and suggested the same as you are proposing 
> and his response was those that are concern with security are those that 
> don't know how to prevent it.

Yeah and I am Batman, sorry let's just drop this I shouldn't have
replied at all.

> Given that he made his living punching hole in paper couple of decades 
> ago I know he either back ported relevant patches or fixed it himself if 
> it concerned him cursing modern coders which throw more hw at the 
> problem instead of fixing it while he was at it ( which he did few time 
> when I was working with him ).
> 
> He never changed anything ( afaik still does not ) only for the sake of 
> change so it's not like he's against upgrading the machine and does not 
> see the need for doing so once in a while but there just really has to 
> be a real reason for it to happen.
> 
> If I would have started arguing with him about it, it was going to be a 
> fight I would have definitely lost and I would have simply been laying 
> there, on his office floor knockout by the entire history of unix or 
> that stack of punch cards from back in the day he had on his desk...

I do not care ab out arguing with him, I care to give advice to others
(if they care for my advice, feel free to fully ignore).

Don't follow that model, it's broken security wise, unless you keep your
machine disconnected from the network.

Simo.

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

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

Re: Where are we going? (Not a rant)

[Andrew Price]

On 07/12/12 17:48, Matthew Miller wrote:

On Fri, Dec 07, 2012 at 03:11:31PM +, Andrew Price wrote:

Ah the ol' Fedora stability improvement thread. It must be Friday.
Ok, I'll bite.

This sort of conversation often comes and goes without much being
done. Usually it consists of debates between three camps:

1. Those who see Fedora as an intrinsically unstable distro which
showcases and attracts testing for the latest upstream work
2. Those who want Fedora to be stable enough to become a realistic
alternative to Windows and Ubuntu for the general masses
3. Those who want Fedora to be stable enough and supported for long
enough to be used as a server OS



Hmmm. I don't think I'm in any of those camps. I want Fedora to thrive and
be used, not as an "alternative" but on its own merits.


Each OS is an alternative to the others. "Alternative" here shouldn't 
imply anything negative, simply that users could happily switch from one 
to the other.



That includes being
a general-purpose OS, both on desktops, on traditional servers, and in the
cloud.


Well that's my hope, too. The items on your list are compatible with 
each other but the problem arises when you add the requirement for 
Fedora to additionally be an unstable mixing pot of the latest upstream 
packages. And that's really what rawhide should be, but since rawhide 
requires so much effort to install and keep running, that's what Fedora 
proper has become.



While I *do* think we would benefit from a slightly longer cycle (with an
"security updates only" phase), I don't think that's the only way to tackle
the problem.


I'm not against extending the cycle in essence. I just don't think the 
*first* step should be to extend cycles and/or support. I think we need 
the ability to tackle as many stability problems as we can, pre-release, 
before we can start thinking about extending life cycles, and that means 
getting people using rawhide day-to-day again. The more bugs we allow 
into our releases by neglecting to test rawhide, the more development 
time we have to spend/waste on fixing packages in the three supported 
releases.


I would link to http://lwn.net/Articles/506831/ but you were quoted in 
that article so I'm guessing you've already seen it :)



For example, making it so key applications and development stacks could
easily float from one base OS to the next would make it less of an issue
when the base OS needs to be upgraded.


Not sure I catch your drift here, but it sounds like it could cause API 
mismatch headaches.



Making upgrades incredibly painless is another good but different approach,
making us closer to a rolling release. (I think we're headed that way with
'fedup', but it's going to be a little longer for that to shake out.)


Yep, I upgraded my netbook to f18 beta with fedup yesterday without too 
much hassle. Looks promising.


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

Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

[Michael Scherer]

Le vendredi 07 décembre 2012 à 18:22 +0100, Pierre-Yves Chibon a écrit :
> On Fri, Dec 07, 2012 at 04:51:43PM +, "Jóhann B. Guðmundsson" wrote:
> > On 12/07/2012 04:46 PM, Miloslav Trmač wrote:
> > >On Fri, Dec 7, 2012 at 11:13 AM, "Jóhann B. Guðmundsson"
> > > wrote:
> > >>>I am not sure why do you want to categorize it by size and impact, when 
> > >>>it
> > >>>will be autocategorized by feedback on ML.
> > >>It's common knowledge that you cant autocategorized by feedback on Mailing
> > >>list regardless what's it's for. ( For obvious reasons )
> > >>
> > >>>The only think matters is that the Feature is widely advertised and that
> > >>>the community can provide early feedback.
> > >>No that is not enough because in the end you will only get feedback from
> > >>users of those feature not necessary from developers of other components
> > >>that might get affected by that feature.
> > >Advertising the feature on the _devel_ list is intended precisely to
> > >get feedback from developers of other possibly affected components.
> > 
> > Think broader than single announcment to an single mailing list
> > since features more often enough touch more then one part of the
> > community...
> 
> So your proposition is??

While I cannot answer for Jóhann, I think a proposal could be to 
contact for example QA, as some features will have a huge impact for
them. Contact irc support, as they may have some insight on the common
issue reported by people, etc. 

Forcing everybody to be on -devel doesn't scale, that's why there is SIG
and specialized lists. I remember having seen several people being
annoyed of the high volume of list like debian-devel, cooker@mandriva,
and in the end, this didn't helped much the communication.

Christophe Wickert spoke last year about the idea of having a common
gathering ( ie, some kind of inter team council ) for having such
discussion, dubbed the fedora council.
( 
http://meetbot.fedoraproject.org/fedora-townhall/2011-11-17/fedora_townhall.2011-11-17-23.13.log.html
 )

Maybe that could be explored ( ie, that would just be a extension of the
go/no go meeting from a organisational point of view ).

The way this is done for Mageia is to have a weekly irc meeting to talk
about various subjects, but I am not fond of adding more irc meeting.

A "feature" SIG ?
-- 
Michael

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

Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

[Jóhann B. Guðmundsson]

On 12/07/2012 05:22 PM, Pierre-Yves Chibon wrote:

On Fri, Dec 07, 2012 at 04:51:43PM +, "Jóhann B. Guðmundsson" wrote:

On 12/07/2012 04:46 PM, Miloslav Trmač wrote:

On Fri, Dec 7, 2012 at 11:13 AM, "Jóhann B. Guðmundsson"
 wrote:

I am not sure why do you want to categorize it by size and impact, when it
will be autocategorized by feedback on ML.

It's common knowledge that you cant autocategorized by feedback on Mailing
list regardless what's it's for. ( For obvious reasons )


The only think matters is that the Feature is widely advertised and that
the community can provide early feedback.

No that is not enough because in the end you will only get feedback from
users of those feature not necessary from developers of other components
that might get affected by that feature.

Advertising the feature on the _devel_ list is intended precisely to
get feedback from developers of other possibly affected components.

Think broader than single announcment to an single mailing list
since features more often enough touch more then one part of the
community...

So your proposition is??


For example using the official distribution announce mailing list which 
should reach broader audience then just -devel if people are inclined to 
go down this path.


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

Re: Where are we going? (Not a rant)

[Jóhann B. Guðmundsson]

On 12/07/2012 04:59 PM, Simo Sorce wrote:

On Fri, 2012-12-07 at 16:47 +, "Jóhann B. Guðmundsson" wrote:

On 12/07/2012 03:51 PM, David Woodhouse wrote:

On Fri, 2012-12-07 at 15:40 +0100, Caterpillar wrote:

The unique and most impotant negative feedback I had it when I
upgraded a system from Fedora 14 to 15, that was the upgrade from
Gnome 2 to Gnome 3.
…
Fedora community should test big transitions like Gnome 2->3 for a
longer period of time

FWIW if it was running Fedora 14 and the user was content with it, I
probably wouldn't have upgraded to Fedora 15. You could have waited 6
months and gone straight to Fedora 16. GNOME 3 was a bit better by then.

I upgrade my *own* machines fairly aggressively — this box has been
running Fedora 18 since August 31st for example. But I don't necessarily
upgrade everyone's machine to *every* Fedora release.

I know one *nix gray beard that is still running F9 on his workstation
because it's setup just the way he likes it and it works for him.

He does not have the time to spare both from work/coding and his
personal life to spend hours to setup his system or constantly having to
upgrade/re-install fighting and patching whatever nuance that release
brings, distracting him from doing actual real work and says that's for
GNU/Linux kids, he rather spend that time with his grankids.

His upgrade cycle is tied to the life cycle of his hw...

He should have chosen to install RHEL/CentOS/etc... then.


That's your opinion



Staying on F9 as a developer is a questionable stance.


Not if you know what your are doing



Your machine is full of security issues and you could be compromised and
become a proxy to compromise the projects you are working on.

If you choose to stay on an older machine you should at least install an
OS that gets security updates for a lot longer.


Oh I mentioned that to him and suggested the same as you are proposing 
and his response was those that are concern with security are those that 
don't know how to prevent it.


Given that he made his living punching hole in paper couple of decades 
ago I know he either back ported relevant patches or fixed it himself if 
it concerned him cursing modern coders which throw more hw at the 
problem instead of fixing it while he was at it ( which he did few time 
when I was working with him ).


He never changed anything ( afaik still does not ) only for the sake of 
change so it's not like he's against upgrading the machine and does not 
see the need for doing so once in a while but there just really has to 
be a real reason for it to happen.


If I would have started arguing with him about it, it was going to be a 
fight I would have definitely lost and I would have simply been laying 
there, on his office floor knockout by the entire history of unix or 
that stack of punch cards from back in the day he had on his desk...


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

Re: Where are we going? (Not a rant)

[Matthew Miller]

On Fri, Dec 07, 2012 at 01:53:50PM +0100, Tomas Radej wrote:
> community, I am seeking support for a movement, both collective and
> individual, that would improve communication, cooperation and generally
> the life of Fedora on the most fundamental basis.

In case it's not clear, I'm in. :)

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

Re: What would it take to make Software Collections work in Fedora?

[Matthew Miller]

On Fri, Dec 07, 2012 at 05:49:24PM +, Richard W.M. Jones wrote:
> I think the real lesson is that platforms should take backwards
> compatibility more seriously.  The single best decision that libvirt
> has ever made was to promise to support the libvirt API and ABI
> forever.  If you wrote a program against libvirt 0.0.1 (or whatever it
> was) 7 years ago, it should still work today.

And that's awesome, and *we* can do that when we make code. And we can even
ask nicely for other people to follow the same practices. But, it's a wild
world out there.


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

Re: What would it take to make Software Collections work in Fedora?

[Subhendu Ghosh]

On Fri, Dec 7, 2012 at 12:49 PM, Richard W.M. Jones  wrote:
> I think the real lesson is that platforms should take backwards
> compatibility more seriously.  The single best decision that libvirt
> has ever made was to promise to support the libvirt API and ABI
> forever.  If you wrote a program against libvirt 0.0.1 (or whatever it
> was) 7 years ago, it should still work today.

Easier said than done in some cases
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

[Matthew Miller]

On Fri, Dec 07, 2012 at 06:06:24AM -0500, Jaroslav Reznik wrote:
> Do not call it "Feature Process" but "Planning process" - as it
> fits the decision to create F19 schedule after we know the scope

+1 to that!

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

Re: grub (v1) in f18?

[Matthew Miller]

On Fri, Dec 07, 2012 at 06:49:25PM +0200, Panu Matilainen wrote:
> My comment was simply on the "if you have both" part: it's not
> really possible to have both without playing dirty tricks, so even
> the "if" is pretty moot.

My point is that it's not really possible to have *grub* without playing
tricks (maybe not dirty ones).


> Yes, I think we're both trying to say the same thing: there's no
> point having 'grub' in the repositories as its not installable or
> usable in practise. The same goes for bunch of other obsoleted
> packages as well.

Are there other obsoleted packages in the F18 repo? Is there a good way to
look for them and to clean them up before release?


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

Re: grub (v1) in f18?

[Matthew Miller]

On Fri, Dec 07, 2012 at 09:29:28AM -0800, John Reiser wrote:
> > Yes, I think we're both trying to say the same thing: there's no point
> > having 'grub' in the repositories as its not installable or usable in
> > practise. The same goes for bunch of other obsoleted packages as well.
> yum is not the only tool available.

But it is the package manager for the distro. More importantly, it's not
really about yum. *Any* package manager which respects what the packages say
("grub2 obsoletes grub") will do the same.


> Using rpm:  erase grub2 if it is present; install grub [grub1].

And then the next time you do a general package upgrade, presto, you've got
grub2 again. This is a kludge, basically, akin to installing firefox-12.0-1
from the F17 release tree even though firefox-17.0 is F17 updates.

> There are other tools, too.  rpm2cpio comes to mind.

Really???

And sure, you can build grub from source. But we're getting pretty far off
from being actually _Fedora_.

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

[perl-Catalyst-Runtime] update to 5.90019

[Iain Arnell]

commit fe03e0d9716bca30773921c5a4b40664adf49cac
Author: Iain Arnell 
Date:   Fri Dec 7 10:51:34 2012 -0700

update to 5.90019

 .gitignore |1 +
 perl-Catalyst-Runtime.spec |   12 +---
 sources|2 +-
 3 files changed, 7 insertions(+), 8 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 698ab32..3b0b220 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,3 +12,4 @@ Catalyst-Runtime-5.80021.tar.gz
 /Catalyst-Runtime-5.90015.tar.gz
 /Catalyst-Runtime-5.90017.tar.gz
 /Catalyst-Runtime-5.90018.tar.gz
+/Catalyst-Runtime-5.90019.tar.gz
diff --git a/perl-Catalyst-Runtime.spec b/perl-Catalyst-Runtime.spec
index 19fd498..863f3d5 100644
--- a/perl-Catalyst-Runtime.spec
+++ b/perl-Catalyst-Runtime.spec
@@ -1,10 +1,10 @@
 Name:   perl-Catalyst-Runtime
 Summary:Catalyst Framework Runtime
-Version:5.90018
+Version:5.90019
 Release:1%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
-Source0:
http://search.cpan.org/CPAN/authors/id/J/JJ/JJNAPIORK/Catalyst-Runtime-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/B/BO/BOBTFISH/Catalyst-Runtime-%{version}.tar.gz
 URL:http://search.cpan.org/dist/Catalyst-Runtime/
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 BuildArch:  noarch
@@ -37,9 +37,6 @@ BuildRequires:  perl(MooseX::Emulate::Class::Accessor::Fast) 
>= 0.00903
 BuildRequires:  perl(MooseX::Getopt) >= 0.30
 BuildRequires:  perl(MooseX::MethodAttributes::Inheritable) >= 0.24
 BuildRequires:  perl(MooseX::Role::WithOverloading) >= 0.09
-BuildRequires:  perl(MooseX::Types)
-BuildRequires:  perl(MooseX::Types::Common::Numeric)
-BuildRequires:  perl(MooseX::Types::LoadableClass) >= 0.003
 BuildRequires:  perl(MRO::Compat)
 BuildRequires:  perl(namespace::autoclean) >= 0.09
 BuildRequires:  perl(namespace::clean) >= 0.23
@@ -94,8 +91,6 @@ Requires:   perl(MooseX::Emulate::Class::Accessor::Fast) 
>= 0.00903
 Requires:   perl(MooseX::Getopt) >= 0.30
 Requires:   perl(MooseX::MethodAttributes::Inheritable) >= 0.24
 Requires:   perl(MooseX::Role::WithOverloading) >= 0.09
-Requires:   perl(MooseX::Types)
-Requires:   perl(MooseX::Types::LoadableClass) >= 0.003
 Requires:   perl(namespace::autoclean) >= 0.09
 Requires:   perl(namespace::clean) >= 0.23
 Requires:   perl(Path::Class) >= 0.09
@@ -181,6 +176,9 @@ make clean
 %{_mandir}/man1/*
 
 %changelog
+* Fri Dec 07 2012 Iain Arnell  5.90019-1
+- update to latest upstream version
+
 * Sat Oct 27 2012 Iain Arnell  5.90018-1
 - update to latest upstream version
 
diff --git a/sources b/sources
index fb95506..089c887 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d1be4e33a619e0ad55d3d6fab98593b9  Catalyst-Runtime-5.90018.tar.gz
+84491b1cde2052a2665e40e86cbc08be  Catalyst-Runtime-5.90019.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: What would it take to make Software Collections work in Fedora?

[Richard W.M. Jones]

On Fri, Dec 07, 2012 at 10:54:46AM +0100, Vít Ondruch wrote:
> In my previous job, we were developing application for our internal
> customer. During development, we were free to use any library which
> suited our needs. However, in some point, our customer was satisfied
> with functionality he had and he didn't want to spent any more money
> on development. Since that time, during maintenance, it was not any
> more my choice what library of what version I will use, since the
> system was built and running.
> 
> Now suddenly, after several years, the provider wants to quit their
> services and the application needs to be migrated. That would be
> perfect case for SC, because it would allow migration with lowest
> cost.
> 
> So what you would suggest? Was there any decision wrong in that process?

I think the real lesson is that platforms should take backwards
compatibility more seriously.  The single best decision that libvirt
has ever made was to promise to support the libvirt API and ABI
forever.  If you wrote a program against libvirt 0.0.1 (or whatever it
was) 7 years ago, it should still work today.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Where are we going? (Not a rant)

[Matthew Miller]

On Fri, Dec 07, 2012 at 03:11:31PM +, Andrew Price wrote:
> Ah the ol' Fedora stability improvement thread. It must be Friday.
> Ok, I'll bite.
> 
> This sort of conversation often comes and goes without much being
> done. Usually it consists of debates between three camps:
> 
> 1. Those who see Fedora as an intrinsically unstable distro which
> showcases and attracts testing for the latest upstream work
> 2. Those who want Fedora to be stable enough to become a realistic
> alternative to Windows and Ubuntu for the general masses
> 3. Those who want Fedora to be stable enough and supported for long
> enough to be used as a server OS


Hmmm. I don't think I'm in any of those camps. I want Fedora to thrive and
be used, not as an "alternative" but on its own merits. That includes being
a general-purpose OS, both on desktops, on traditional servers, and in the
cloud. It doesn't necessarily mean "the general masses" nor world
domination.

While I *do* think we would benefit from a slightly longer cycle (with an
"security updates only" phase), I don't think that's the only way to tackle
the problem.

For example, making it so key applications and development stacks could
easily float from one base OS to the next would make it less of an issue
when the base OS needs to be upgraded.

Making upgrades incredibly painless is another good but different approach,
making us closer to a rolling release. (I think we're headed that way with
'fedup', but it's going to be a little longer for that to shake out.)

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

Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

[Miloslav Trmač]

On Fri, Dec 7, 2012 at 6:22 PM, Emmanuel Seyman  wrote:
> * Miloslav Trmač [07/12/2012 18:07] :
>>
>> Advertising the feature on the _devel_ list is intended precisely to
>> get feedback from developers of other possibly affected components.
>
> IIRC, being subscribed to devel@ is not mandatory.

I was imprecise - the meeting minutes show that the announcement goes
to devel-announce.

(In any case, responding to an e-mail is not mandatory, so... :) )
   Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [389-devel] please review: Ticket 509 - lock-free access to be->be_suffixlock

[Rich Megginson]

On 12/07/2012 09:56 AM, Mark Reynolds wrote:

Hi Ludwig,

In Ticket 507, that change did not help after all, and will probably 
be removed.


It's hard to tell.  I'm having some problems getting reliable reports.  
We are working on that.




As far as I can tell, this is the only option we have for ticket 509.


Any locking is going to be worse than doing some sort of lock-free access.



Mark

On 12/07/2012 11:50 AM, Ludwig Krispenz wrote:

Hi Mark,

for ticket 507 you replaced rw locks with mutex locks, now for the 
backend you replace mutex locks with rw locks ? any reason why these 
are better here ?


Regards,
Ludwig

On 12/07/2012 05:48 PM, Mark Reynolds wrote:

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

https://fedorahosted.org/389/attachment/ticket/509/0001-Ticket-509-lock-free-access-to-be-be_suffixlock.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

File Catalyst-Runtime-5.90019.tar.gz uploaded to lookaside cache by iarnell

[Iain Arnell]

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

84491b1cde2052a2665e40e86cbc08be  Catalyst-Runtime-5.90019.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: What would it take to make Software Collections work in Fedora?

[Matthew Miller]

On Fri, Dec 07, 2012 at 10:40:13AM -0500, Jon Masters wrote:
> > We could draw them between Core and Extras!
> :) Note that just because we got rid of Core doesn't mean that it was a
> bad idea. Ubuntu even adopted a "Core" of their own a while back. Maybe

The bad idea was the insider-vs-outsider mentality inherent in the way the
split was made. I don't think anyone wants to go back to that, and, the
above joke aside, I think it's clear that we wouldn't draw the line in the
same way, and we would *definitely* have different rules than in those days.

To a lot of people who weren't so close to all that, the name "Fedora Core"
still has good connotations -- I still often meet people who refer to Fedora
as that. I don't know what the balance in the community now is of people who
have that kind of rosy-eyed fondness, people who are new and don't have a
history either way, and people who remember the Dark Times and would be put
off by the name.


> they'll have the same experience we had and get away from that, or maybe
> Linux distributions should ultimately not be in the business of
> providing all+kitchen sink. Speaking only personally, what I want is a
> stable core platform of very limited size against which I can install
> other packages and stacks.

I think we *could* have both. There's no reason that Fedora couldn't make
that stable core platform *and* provide layers above it. In fact, referring
to
https://fedoraproject.org/wiki/Overview?rd=FedoraProject:About#Our_Mission
it seems pretty clear that both levels are in scope.

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

Re: grub (v1) in f18?

[John Reiser]

On 12/07/2012 08:49 AM, Panu Matilainen wrote:

> Yes, I think we're both trying to say the same thing: there's no point having 
> 'grub' in the repositories as its not installable or usable in practise. The 
> same goes for bunch of other obsoleted packages as well.

yum is not the only tool available.

Using rpm:  erase grub2 if it is present; install grub [grub1].

There are other tools, too.  rpm2cpio comes to mind.

-- 

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

Re: grub (v1) in f18?

[Richard W.M. Jones]

On Thu, Dec 06, 2012 at 03:25:21PM -0700, Chris Murphy wrote:
> Why is a boot manager needed for a virtualized guest? It seems like all you 
> need is to point to a virtual disk (or current or past snapshot) and go 
> directly to loading the kernel. 
> 
> If I could stuff < 1024 bytes of boot loader into ext4's two boot sectors, 
> that seems ways easier than dealing with grub.
> http://lists.fedoraproject.org/pipermail/devel/2012-December/174786.html

[My second answer, now that I've looked at that code and understand
better where you're going with this ...]

Yes, I think this is all possible, and probably better than emulating
what the BIOS does.  Even better would be if you could get those 1024
bytes down to 512 bytes (and thus fit it in a boot sector).  Then no
changes to existing hypervisors would be needed at all, and it would
run on baremetal.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

[Emmanuel Seyman]

* Miloslav Trmač [07/12/2012 18:07] :
>
> Advertising the feature on the _devel_ list is intended precisely to
> get feedback from developers of other possibly affected components.

IIRC, being subscribed to devel@ is not mandatory.

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

Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

[Pierre-Yves Chibon]

On Fri, Dec 07, 2012 at 04:51:43PM +, "Jóhann B. Guðmundsson" wrote:
> On 12/07/2012 04:46 PM, Miloslav Trmač wrote:
> >On Fri, Dec 7, 2012 at 11:13 AM, "Jóhann B. Guðmundsson"
> > wrote:
> >>>I am not sure why do you want to categorize it by size and impact, when it
> >>>will be autocategorized by feedback on ML.
> >>It's common knowledge that you cant autocategorized by feedback on Mailing
> >>list regardless what's it's for. ( For obvious reasons )
> >>
> >>>The only think matters is that the Feature is widely advertised and that
> >>>the community can provide early feedback.
> >>No that is not enough because in the end you will only get feedback from
> >>users of those feature not necessary from developers of other components
> >>that might get affected by that feature.
> >Advertising the feature on the _devel_ list is intended precisely to
> >get feedback from developers of other possibly affected components.
> 
> Think broader than single announcment to an single mailing list
> since features more often enough touch more then one part of the
> community...

So your proposition is??

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

Re: What would it take to make Software Collections work in Fedora?

[Matthew Miller]

On Fri, Dec 07, 2012 at 02:08:28AM -0500, Bohuslav Kabrda wrote:
> I don't think I fully understand your question here. Every SCL is confined
> in its own root under /opt/.../name/root. So you can either do two SCLs,
^^^

Or wherever we decide is the appropriate place -- I think this was one of
the sticking points before.

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

Re: Where are we going? (Not a rant)

[Simo Sorce]

On Fri, 2012-12-07 at 16:47 +, "Jóhann B. Guðmundsson" wrote:
> On 12/07/2012 03:51 PM, David Woodhouse wrote:
> > On Fri, 2012-12-07 at 15:40 +0100, Caterpillar wrote:
> >> The unique and most impotant negative feedback I had it when I
> >> upgraded a system from Fedora 14 to 15, that was the upgrade from
> >> Gnome 2 to Gnome 3.
> >> …
> >> Fedora community should test big transitions like Gnome 2->3 for a
> >> longer period of time
> > FWIW if it was running Fedora 14 and the user was content with it, I
> > probably wouldn't have upgraded to Fedora 15. You could have waited 6
> > months and gone straight to Fedora 16. GNOME 3 was a bit better by then.
> >
> > I upgrade my *own* machines fairly aggressively — this box has been
> > running Fedora 18 since August 31st for example. But I don't necessarily
> > upgrade everyone's machine to *every* Fedora release.
> 
> I know one *nix gray beard that is still running F9 on his workstation 
> because it's setup just the way he likes it and it works for him.
> 
> He does not have the time to spare both from work/coding and his 
> personal life to spend hours to setup his system or constantly having to 
> upgrade/re-install fighting and patching whatever nuance that release 
> brings, distracting him from doing actual real work and says that's for 
> GNU/Linux kids, he rather spend that time with his grankids.
> 
> His upgrade cycle is tied to the life cycle of his hw...

He should have chosen to install RHEL/CentOS/etc... then.

Staying on F9 as a developer is a questionable stance.

Your machine is full of security issues and you could be compromised and
become a proxy to compromise the projects you are working on.

If you choose to stay on an older machine you should at least install an
OS that gets security updates for a lot longer.

Simo.

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

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

Re: [389-devel] please review: Ticket 509 - lock-free access to be->be_suffixlock

[Ludwig Krispenz]

Hi,
On 12/07/2012 05:56 PM, Mark Reynolds wrote:

Hi Ludwig,

In Ticket 507, that change did not help after all, and will probably 
be removed.


As far as I can tell, this is the only option we have for ticket 509.
yes, but the subject says lock free. So if we cannot make it lock free 
is it justified to just change the lock type ?


Ludwig


Mark

On 12/07/2012 11:50 AM, Ludwig Krispenz wrote:

Hi Mark,

for ticket 507 you replaced rw locks with mutex locks, now for the 
backend you replace mutex locks with rw locks ? any reason why these 
are better here ?


Regards,
Ludwig

On 12/07/2012 05:48 PM, Mark Reynolds wrote:

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

https://fedorahosted.org/389/attachment/ticket/509/0001-Ticket-509-lock-free-access-to-be-be_suffixlock.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: [389-devel] please review: Ticket 509 - lock-free access to be->be_suffixlock

[Mark Reynolds]

Hi Ludwig,

In Ticket 507, that change did not help after all, and will probably be 
removed.


As far as I can tell, this is the only option we have for ticket 509.

Mark

On 12/07/2012 11:50 AM, Ludwig Krispenz wrote:

Hi Mark,

for ticket 507 you replaced rw locks with mutex locks, now for the 
backend you replace mutex locks with rw locks ? any reason why these 
are better here ?


Regards,
Ludwig

On 12/07/2012 05:48 PM, Mark Reynolds wrote:

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

https://fedorahosted.org/389/attachment/ticket/509/0001-Ticket-509-lock-free-access-to-be-be_suffixlock.patch 





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


--
Mark Reynolds
Red Hat, Inc
mreyno...@redhat.com

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

Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

[Jóhann B. Guðmundsson]

On 12/07/2012 04:46 PM, Miloslav Trmač wrote:

On Fri, Dec 7, 2012 at 11:13 AM, "Jóhann B. Guðmundsson"
 wrote:

I am not sure why do you want to categorize it by size and impact, when it
will be autocategorized by feedback on ML.

It's common knowledge that you cant autocategorized by feedback on Mailing
list regardless what's it's for. ( For obvious reasons )


The only think matters is that the Feature is widely advertised and that
the community can provide early feedback.

No that is not enough because in the end you will only get feedback from
users of those feature not necessary from developers of other components
that might get affected by that feature.

Advertising the feature on the _devel_ list is intended precisely to
get feedback from developers of other possibly affected components.


Think broader than single announcment to an single mailing list since 
features more often enough touch more then one part of the community...


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

Re: grub (v1) in f18?

[Richard W.M. Jones]

On Thu, Dec 06, 2012 at 03:25:21PM -0700, Chris Murphy wrote:
> 
> On Dec 6, 2012, at 3:02 PM, "Richard W.M. Jones"  wrote:
> 
> > On Thu, Dec 06, 2012 at 03:34:23PM -0500, Matthew Miller wrote:
> >> The grub2 package obsoletes grub, so there's no way to actually _use_ the
> >> older package, but it's still in the tree. Is there a reason?
> > 
> > Yes, virtualization.
> > 
> > I actually thought grub had been removed, so I removed the dependency
> > on it in libguestfs.  However libguestfs certainly *could* use grub,
> > if it was available.  There's some heated discussion of this here:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=737261#c10
> > 
> > and also in the archives of the current mailing list.
>
> Why is a boot manager needed for a virtualized guest? It seems like
> all you need is to point to a virtual disk (or current or past
> snapshot) and go directly to loading the kernel.
>
> If I could stuff < 1024 bytes of boot loader into ext4's two boot
> sectors, that seems ways easier than dealing with grub.
> http://lists.fedoraproject.org/pipermail/devel/2012-December/174786.html

Well this is a more general question about virtualization.  I agree
that it's sometimes more convenient to use an external kernel and
initrd to boot a guest, and libvirt supports this mode (see the
 and  in libvirt XML).  But:

(a) My understanding is this doesn't eliminate the need for a BIOS,
because I think early kernel code still calls into the BIOS, or at
least uses BIOS-created structures (eg. E820).  It does however
eliminate the need to deal with grub.

(b) Maintaining a separate kernel and initrd outside the VM is a pain
when it comes to updates.  How is 'yum' running in a VM supposed to
update a kernel stored outside the VM?

(c) It's generally better to remain as close as possible to baremetal,
just for ease of testing, reduced number of code paths, etc.

Note that none of this helps with libguestfs + grub.  We want grub so
we can deal with existing guests, and they're already using grub
whether we like it or not :-(

> And if there's a use case for UEFI VM's, why not use EFISTUB instead of grub?

No idea sorry.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [389-devel] please review: Ticket 509 - lock-free access to be->be_suffixlock

[Ludwig Krispenz]

Hi Mark,

for ticket 507 you replaced rw locks with mutex locks, now for the 
backend you replace mutex locks with rw locks ? any reason why these are 
better here ?


Regards,
Ludwig

On 12/07/2012 05:48 PM, Mark Reynolds wrote:

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

https://fedorahosted.org/389/attachment/ticket/509/0001-Ticket-509-lock-free-access-to-be-be_suffixlock.patch 





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

Re: Where are we going? (Not a rant)

[Jóhann B. Guðmundsson]

On 12/07/2012 03:51 PM, David Woodhouse wrote:

On Fri, 2012-12-07 at 15:40 +0100, Caterpillar wrote:

The unique and most impotant negative feedback I had it when I
upgraded a system from Fedora 14 to 15, that was the upgrade from
Gnome 2 to Gnome 3.
…
Fedora community should test big transitions like Gnome 2->3 for a
longer period of time

FWIW if it was running Fedora 14 and the user was content with it, I
probably wouldn't have upgraded to Fedora 15. You could have waited 6
months and gone straight to Fedora 16. GNOME 3 was a bit better by then.

I upgrade my *own* machines fairly aggressively — this box has been
running Fedora 18 since August 31st for example. But I don't necessarily
upgrade everyone's machine to *every* Fedora release.


I know one *nix gray beard that is still running F9 on his workstation 
because it's setup just the way he likes it and it works for him.


He does not have the time to spare both from work/coding and his 
personal life to spend hours to setup his system or constantly having to 
upgrade/re-install fighting and patching whatever nuance that release 
brings, distracting him from doing actual real work and says that's for 
GNU/Linux kids, he rather spend that time with his grankids.


His upgrade cycle is tied to the life cycle of his hw...

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

Re: grub (v1) in f18?

[Panu Matilainen]

On 12/07/2012 05:26 PM, Matthew Miller wrote:

On Fri, Dec 07, 2012 at 10:56:44AM +0200, Panu Matilainen wrote:

I haven't experienced this with F16, F17 or so far F18. What I'm seeing is:

yum install/update grub gets me grub legacy.
yum install/update grub-efi gets me grub legacy efi.
yum install/update grub2 gets me grub2.
yum install/update grub2-efi gets me grub2 efi.


If you have *both* installed, grub2 will want to nuke grub every time an
update shows up, IIRC.


Yum and rpm refuse to install packages which are obsoleted by an
installed package, so you can't really have both. Unless you first
install grub2 and then grub with 'rpm --nodeps'...


But, it's not just if both installed, is it? The grub2 package obsoletes
grub, and yum follows obsoletes by default in dependency resolution.

Panu, you would know this better than I, so clearly I'm going crazy
somewhere. If you could explain how, I'd appreciate it. :)


My comment was simply on the "if you have both" part: it's not really 
possible to have both without playing dirty tricks, so even the "if" is 
pretty moot.



Here's on an F17 image booted in a cloud service (so no grub at all
installed initially):

   $ rpm -qa |grep grub
   grubby-8.11-1.fc17.x86_64

(As expected, just grubby; nothing else matches.)

   $ sudo yum install grub
   [...]
   Package grub is obsoleted by grub2, trying to install
   1:grub2-2.0-0.39.fc17.x86_64 instead
   Resolving Dependencies
   --> Running transaction check
   ---> Package grub2.x86_64 1:2.0-0.39.fc17 will be installed
   --> Processing Dependency: grub2-tools = 1:2.0-0.39.fc17 for package:
   --> 1:grub2-2.0-0.39.fc17.x86_64
   [...and so on]

Even "yum install grub-0.97" gets this behavior. Now, I can set
"obsoletes=0" in /etc/yum.conf if I _really_ want to get grub installed, but

   a) I don't actually want to change the default behavior of yum on the final
  image

   b) I don't want users to get messed up if they innocently change that back
  to its default

   c) I'm not even sure how I would go about changing that pre-transaction in
  appliance-creator and other tools



Yes, I think we're both trying to say the same thing: there's no point 
having 'grub' in the repositories as its not installable or usable in 
practise. The same goes for bunch of other obsoleted packages as well.


- Panu -

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

[389-devel] please review: Ticket 509 - lock-free access to be->be_suffixlock

[Mark Reynolds]

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

https://fedorahosted.org/389/attachment/ticket/509/0001-Ticket-509-lock-free-access-to-be-be_suffixlock.patch

--
Mark Reynolds
Red Hat, Inc
mreyno...@redhat.com

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

[perl-System-Command] update to 1.08

[Iain Arnell]

commit c45de9c3338d3cfdbdf5eef4c21daad9103b5b33
Author: Iain Arnell 
Date:   Fri Dec 7 09:47:37 2012 -0700

update to 1.08

 .gitignore   |1 +
 perl-System-Command.spec |8 +---
 sources  |2 +-
 3 files changed, 7 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e33e7b4..f3ffe1d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 /System-Command-1.06.tar.gz
 /System-Command-1.07.tar.gz
+/System-Command-1.08.tar.gz
diff --git a/perl-System-Command.spec b/perl-System-Command.spec
index 90b0b3e..55e87aa 100644
--- a/perl-System-Command.spec
+++ b/perl-System-Command.spec
@@ -1,6 +1,6 @@
 Name:   perl-System-Command
-Version:1.07
-Release:3%{?dist}
+Version:1.08
+Release:1%{?dist}
 Summary:Object for running system commands
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -30,7 +30,6 @@ their STDIN, STDOUT and STDERR handles.
 
 %install
 ./Build install destdir=%{buildroot} create_packlist=0
-find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null \;
 
 %{_fixperms} %{buildroot}/*
 
@@ -43,6 +42,9 @@ find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null \;
 %{_mandir}/man3/*
 
 %changelog
+* Fri Dec 07 2012 Iain Arnell  1.08-1
+- update to latest upstream version
+
 * Fri Jul 20 2012 Fedora Release Engineering  
- 1.07-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
 
diff --git a/sources b/sources
index 52ea33f..d202147 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b0eb34bea32da8824b7b99080686c326  System-Command-1.07.tar.gz
+cae18b739ddd6dea8fe830dd6aae878f  System-Command-1.08.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: bugz.fedoraproject.org trouble

[Ralph Bean]

On Fri, Dec 07, 2012 at 04:57:00PM +0100, Michael Schwendt wrote:
> There used to be
> 
>   http://bugz.fedoraproject.org/SOURCE-RPM-NAME
> e.g.
>   http://bugz.fedoraproject.org/gnome-packagekit
> 
> Whoever has installed the new non-working software on that server,
> could it be replaced with the previous version again, please?
>
> The pages don't want to load successfully anymore:
> 
>Error loading the data for this page element
>...
>Error loading the data for this page element
> 
> And
>This package has no bugs - go file some!!!
> is displayed always, apparently.
> 
> This is very unfortunate and sad, especially during the Fedora Beta phase.
> A very convenient way to take a look at existing bug reports is gone.
> A very convenient way to follow a quick link into Fedora bugzilla is gone.
> 
> And what is this thing called anyway?
> There are a couple of links at the bottom of the page, which don't work
>  -> http://fedoracommunity.fedorahosted.org/
>  -> http://moksha.fedorahosted.org/
> seems to be related to the "fedora community project", but only
> the src.rpm/rpm repo links work, which contain many rpms.

I introduced the switch-over as per this ticket
https://fedorahosted.org/fedoracommunity/ticket/381

The site (called fedora-packages, the successor to fedoracommunity)
has been up for almost a year and we were mistaken in thinking enough
developers had used it that the kinks had been worked out.

You're quite right about this being poor timing.  I just reverted
the alias, so bugz.fedoraproject.org/package-name should work again
(using the pkgdb site).  We'll hammer on the fedora-packages app
some more during freeze to try and get it up-to-snuff.

For the curious, part of the motivation for making a change at all is
that the pkgdb app has undergone feature creep over time.  Its
codebase is older and needs a port/rewrite to a more modern framework.
We're hoping to trim some of it's features which already exist in other
apps (like this bugs reporting feature), scale it down, and rewrite
the core as a more maintainable unit.. the core being acl controls.

-Ralph


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

Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

[Miloslav Trmač]

On Fri, Dec 7, 2012 at 11:13 AM, "Jóhann B. Guðmundsson"
 wrote:
>> I am not sure why do you want to categorize it by size and impact, when it
>> will be autocategorized by feedback on ML.
>
> It's common knowledge that you cant autocategorized by feedback on Mailing
> list regardless what's it's for. ( For obvious reasons )
>
>> The only think matters is that the Feature is widely advertised and that
>> the community can provide early feedback.
>
> No that is not enough because in the end you will only get feedback from
> users of those feature not necessary from developers of other components
> that might get affected by that feature.

Advertising the feature on the _devel_ list is intended precisely to
get feedback from developers of other possibly affected components.
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

File System-Command-1.08.tar.gz uploaded to lookaside cache by iarnell

[Iain Arnell]

A file has been added to the lookaside cache for perl-System-Command:

cae18b739ddd6dea8fe830dd6aae878f  System-Command-1.08.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: What would it take to make Software Collections work in Fedora?

[Mark Bidewell]

On Fri, Dec 7, 2012 at 10:40 AM, Jon Masters  wrote:

> On 12/06/2012 01:00 AM, Adam Williamson wrote:
> > On Wed, 2012-12-05 at 22:25 -0600, Michael Ekstrand wrote:
> >> On 12/05/2012 03:06 PM, Bill Nottingham wrote:
> >>> Matthew Miller (mat...@fedoraproject.org) said:
>  Three things:
> 
>  1) Fedora is big enough that we have concrete situations where one
> size
> doesn't fit all. Puppet being broken on F17 (and probably F18 as
> well)
> is a fine example of something within the distro itself. And, as a
> platform for development, offering more version choices to our
> users
> would be a strength.
> >>>
> >>> 
> >>>
> >>> Well, then maybe Fedora's too big, and we should move to a model where
> >>> Fedora is much smaller, and the grand Fedora universe contains things
> that
> >>> are packaged *for* one or multiple Fedoras.
> >>>
> >>> 
> >>
> >> FWIW (probably not much), I also think this is a great idea.  It feels
> >> strange to me that the same thing contains & manages everything from
> >> base system (e.g. kernel through core GNOME stack) and add-on apps (say
> >> Battle for Wesnoth, to pick a relatively obvious example).
> >>
> >> Now, there's a bike shed to be painted over where the lines should be
> drawn.
> >
> > We could draw them between Core and Extras!
>
> :) Note that just because we got rid of Core doesn't mean that it was a
> bad idea. Ubuntu even adopted a "Core" of their own a while back. Maybe
> they'll have the same experience we had and get away from that, or maybe
> Linux distributions should ultimately not be in the business of
> providing all+kitchen sink. Speaking only personally, what I want is a
> stable core platform of very limited size against which I can install
> other packages and stacks.
>
> Jon.
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

+1

Personally I think the line should be drawn similar to FreeBSD/Ports.
 "Core" should be primarily OS kernel, shell utilities and C compiler.
 Maybe X as well. Extras should be anything not required for an operational
system even if installed by the initial install.  My biggest beef with
Linux packaging has been that, by and large, all packages have to be
upgraded in sync if you want to have a supported system.  Battle for
Wesnoth shouldn't be tied to kernel updates.

-- 
Mark Bidewell
http://www.linkedin.com/in/markbidewell
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: bugz.fedoraproject.org/ MIA?

[Ralph Bean]

On Thu, Dec 06, 2012 at 11:54:07PM -0800, Adam Williamson wrote:
> On Fri, 2012-12-07 at 08:42 +0800, Christopher Meng wrote:
> > In fact in some area it takes me 1 min to finish loading the
> > page.. 
> 
> Bugzilla has been veeery slow for the last week or two. Painfully slow.
> Incredibly efficiency-destroying slow, if you're oh say a full-time QA
> person and so spend several hours a day loading bug URLs. Grr...

In one of the updates to RH BZ over the last few months, we lost the
ability to do multicall queries with the python-bugzilla module.  This
is partly to blame; we can do a lot to speed it up in time.


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

Re: What would it take to make Software Collections work in Fedora?

[Jon Masters]

On 12/06/2012 01:00 AM, Adam Williamson wrote:
> On Wed, 2012-12-05 at 22:25 -0600, Michael Ekstrand wrote:
>> On 12/05/2012 03:06 PM, Bill Nottingham wrote:
>>> Matthew Miller (mat...@fedoraproject.org) said: 
 Three things:

 1) Fedora is big enough that we have concrete situations where one size
doesn't fit all. Puppet being broken on F17 (and probably F18 as well)
is a fine example of something within the distro itself. And, as a
platform for development, offering more version choices to our users
would be a strength.
>>>
>>> 
>>>
>>> Well, then maybe Fedora's too big, and we should move to a model where
>>> Fedora is much smaller, and the grand Fedora universe contains things that
>>> are packaged *for* one or multiple Fedoras.
>>>
>>> 
>>
>> FWIW (probably not much), I also think this is a great idea.  It feels
>> strange to me that the same thing contains & manages everything from
>> base system (e.g. kernel through core GNOME stack) and add-on apps (say
>> Battle for Wesnoth, to pick a relatively obvious example).
>>
>> Now, there's a bike shed to be painted over where the lines should be drawn.
> 
> We could draw them between Core and Extras!

:) Note that just because we got rid of Core doesn't mean that it was a
bad idea. Ubuntu even adopted a "Core" of their own a while back. Maybe
they'll have the same experience we had and get away from that, or maybe
Linux distributions should ultimately not be in the business of
providing all+kitchen sink. Speaking only personally, what I want is a
stable core platform of very limited size against which I can install
other packages and stacks.

Jon.

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

Re: What would it take to make Software Collections work in Fedora?

[Subhendu Ghosh]

On Wed, Dec 5, 2012 at 4:04 PM, Matthew Miller  wrote:
> 3) It's the ecosystem. If using Software Collections on RHEL is good for
>your company, it's good for it to work on Fedora, because a) we're the
>upstream and problems get worked out here, b) development resources
>benefit Fedora rather than being "spent" in a pocket universe, and c)
>Software Collections which work across the whole ecosystem in a
>consistent way make us a stronger choice for development work which may
>eventually end up on Enterprise Linux in production.

To echo on the ecosystem comment.

There are things "inside", "on top", "alongside" or "under" a distribution.
Fedora takes the view that everything inside should be consistent
without redundancy.
This is extremely useful and important.

But Fedora does not have a policy for the other elements - what should
be on top, how should it be on top for example.

A while back Fedora started the ISV SIG and Greg had a beautiful blog
post [1] on why that initiative failed.
It failed because the communication to the ISVs was that they should
be inside Fedora and what they wanted
to be is on top of Fedora.

Software Collections is hope of creating a distinction between the
distribution and all that it contains, and an ability
for 3rd parties to to create their own world on top.

This always brings back the question of "what is Fedora" - folks think
I am making snide remarks when I use that phrase - but the question in
implicit in some of the discussion in this thread.

1 - Fedora is the linux software distribution
2 - Fedora is the community infrastructure that enables a linux
distribution and an ecosystem.

The two statements are quite different in their impact.


[1] 
http://gregdekspeaks.wordpress.com/2012/01/06/why-the-fedora-isv-sig-never-caught-fire/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

bugz.fedoraproject.org trouble

[Michael Schwendt]

There used to be

  http://bugz.fedoraproject.org/SOURCE-RPM-NAME
e.g.
  http://bugz.fedoraproject.org/gnome-packagekit

Whoever has installed the new non-working software on that server,
could it be replaced with the previous version again, please?

The pages don't want to load successfully anymore:

   Error loading the data for this page element
   ...
   Error loading the data for this page element

And
   This package has no bugs - go file some!!!
is displayed always, apparently.

This is very unfortunate and sad, especially during the Fedora Beta phase.
A very convenient way to take a look at existing bug reports is gone.
A very convenient way to follow a quick link into Fedora bugzilla is gone.

And what is this thing called anyway?
There are a couple of links at the bottom of the page, which don't work
 -> http://fedoracommunity.fedorahosted.org/
 -> http://moksha.fedorahosted.org/
seems to be related to the "fedora community project", but only
the src.rpm/rpm repo links work, which contain many rpms.

-- 
Fedora release 18 (Spherical Cow) - Linux 3.6.9-4.fc18.x86_64
loadavg: 0.03 0.19 0.20
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-autobox] update to 2.76

[Iain Arnell]

commit 7a3f13db18f976f794bbba533a4cb4d9a2ff0ca9
Author: Iain Arnell 
Date:   Fri Dec 7 08:51:01 2012 -0700

update to 2.76

 .gitignore|1 +
 perl-autobox.spec |8 +---
 sources   |2 +-
 3 files changed, 7 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 44bc16c..5ddc165 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ autobox-2.55.tar.gz
 /autobox-2.71.tar.gz
 /autobox-2.73.tar.gz
 /autobox-2.75.tar.gz
+/autobox-2.76.tar.gz
diff --git a/perl-autobox.spec b/perl-autobox.spec
index b06a285..76d8145 100644
--- a/perl-autobox.spec
+++ b/perl-autobox.spec
@@ -1,6 +1,6 @@
 Name:   perl-autobox
-Version:2.75
-Release:4%{?dist}
+Version:2.76
+Release:1%{?dist}
 Summary:Call methods on native types
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -35,7 +35,6 @@ make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
 
 find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
 find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
 
 %{_fixperms} $RPM_BUILD_ROOT/*
 
@@ -49,6 +48,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Fri Dec 07 2012 Iain Arnell  2.76-1
+- update to latest upstream version
+
 * Fri Jul 20 2012 Fedora Release Engineering  
- 2.75-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
 
diff --git a/sources b/sources
index 431d2f3..5b32030 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-6769d8c65f0e10d3a50abe796dd870fb  autobox-2.75.tar.gz
+5585c43340f3bd084cbfd79e394dee26  autobox-2.76.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: Where are we going? (Not a rant)

[David Woodhouse]

On Fri, 2012-12-07 at 15:40 +0100, Caterpillar wrote:
> The unique and most impotant negative feedback I had it when I
> upgraded a system from Fedora 14 to 15, that was the upgrade from
> Gnome 2 to Gnome 3.
> …
> Fedora community should test big transitions like Gnome 2->3 for a
> longer period of time

FWIW if it was running Fedora 14 and the user was content with it, I
probably wouldn't have upgraded to Fedora 15. You could have waited 6
months and gone straight to Fedora 16. GNOME 3 was a bit better by then.

I upgrade my *own* machines fairly aggressively — this box has been
running Fedora 18 since August 31st for example. But I don't necessarily
upgrade everyone's machine to *every* Fedora release.

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Where are we going? (Not a rant)

[Jóhann B. Guðmundsson]

On 12/07/2012 03:11 PM, Andrew Price wrote:
Ah the ol' Fedora stability improvement thread. It must be Friday. Ok, 
I'll bite.


This sort of conversation often comes and goes without much being 
done. Usually it consists of debates between three camps:


1. Those who see Fedora as an intrinsically unstable distro which 
showcases and attracts testing for the latest upstream work
2. Those who want Fedora to be stable enough to become a realistic 
alternative to Windows and Ubuntu for the general masses
3. Those who want Fedora to be stable enough and supported for long 
enough to be used as a server OS


I think the reason nothing happens is due to the core issue not being 
agreed upon by all camps. It's very difficult to make progress on a 
solution unless you first understand and agree on the problem.


Fedora LTS first and foremost needs maintainers willing to commit to it.



However, if you're still interested I've laid out some ideas, based on 
my belief that instability is a significant problem, below.


On 07/12/12 12:53, Tomas Radej wrote:

One of the results was a conversation I had with a few guys to
whom I recommended Fedora as a development environment. It showed me
that there's indeed something wrong. While they all said that Fedora's
features were brilliant, they unanimously rejected Fedora as a
primary system. The reason they gave me was, now quoting: It doesn't
really work.


One hypothesis is that too few people use Rawhide to a point where 
enough testing gets done before final releases. I think making some 
basic guarantees about Rawhide's stability (it boots, package 
management works, etc.) would go some way to increase early adoption 
and ensure bugs are reported and fixed before final releases, thus 
avoiding many unnecessary updates. I would certainly consider running 
Rawhide with such guarantees.


Once most of us are dog-fooding Rawhide the temptation to release the 
latest unstable upstream code in stable release updates would be 
significantly reduced and our update policy could be tightened to 
disallow version bumps, etc. in stable release updates similar to 
other, more popular distros' update policies.


I think this is a better first step forward than LTS releases because 
it focuses on users' first impressions of Fedora by increasing the 
stability level on the day of release.


If you want to improve "Rawhide" and it's stability get 
developers/maintainers to run rawhide on their daily bases.


Not going to happened afaik.

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

Re: What would it take to make Software Collections work in Fedora?

[Subhendu Ghosh]

On Thu, Dec 6, 2012 at 6:39 AM, Vít Ondruch  wrote:
> Dne 5.12.2012 22:14, Kevin Fenzi napsal(a):
>
>> I cant seem to find any specific fpc ticket where they discussed this,
>> but I am pretty sure it was brought up before there. I'd check with
>> them...
>
>
> https://fedorahosted.org/fpc/ticket/141
> https://fedorahosted.org/fpc/ticket/143
>
> But I am afraid not everything written there :/
>
> Vít
>

https://fedorahosted.org/fpc/ticket/115

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

[perl-strictures] update to 1.004004

[Iain Arnell]

commit 73102a0a4c16848c1bc175db0df7e430eda2869f
Author: Iain Arnell 
Date:   Fri Dec 7 08:34:36 2012 -0700

update to 1.004004

 .gitignore   |1 +
 perl-strictures.spec |5 -
 sources  |2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 4575ccd..5b07964 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
 /strictures-1.003001.tar.gz
 /strictures-1.004001.tar.gz
 /strictures-1.004002.tar.gz
+/strictures-1.004004.tar.gz
diff --git a/perl-strictures.spec b/perl-strictures.spec
index 2feec50..3fc5c7f 100644
--- a/perl-strictures.spec
+++ b/perl-strictures.spec
@@ -1,5 +1,5 @@
 Name:   perl-strictures
-Version:1.004002
+Version:1.004004
 Release:1%{?dist}
 Summary:Turn on strict and make all warnings fatal
 License:GPL+ or Artistic
@@ -45,6 +45,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Fri Dec 07 2012 Iain Arnell  1.004004-1
+- update to latest upstream version
+
 * Sun Sep 09 2012 Iain Arnell  1.004002-1
 - update to latest upstream version
 
diff --git a/sources b/sources
index a0a8fa8..be39a44 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-0d68d0bd668dcf7cf2c172095f6ea7b8  strictures-1.004002.tar.gz
+1a6323eee9f2c9762a77b97e604034d4  strictures-1.004004.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 885146] New: perl-Module-Build should not BR: perl(YAML::Tiny)

[bugzilla]

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

Bug ID: 885146
   Summary: perl-Module-Build should not BR: perl(YAML::Tiny)
   Product: Fedora
   Version: rawhide
 Component: perl-Module-Build
  Severity: unspecified
  Priority: unspecified
  Reporter: p...@city-fan.org

A buildreq of perl(YAML::Tiny) has recently been added to perl-Module-Build.
However, YAML::Tiny is not actually used by Module::Build or its test suite. As
per upstream's changelog, YAML::Tiny has been superseded by CPAN::Meta::YAML in
Module::Build, and CPAN::Meta::YAML is already a buildreq.

This is an issue because some of perl-YAML-Tiny's build dependencies need
Module::Build for their build process, i.e. there are circular build
dependencies as things stand. Please remove this redundant buildreq.

-- 
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=HiLREaVsLB&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

File strictures-1.004004.tar.gz uploaded to lookaside cache by iarnell

[Iain Arnell]

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

1a6323eee9f2c9762a77b97e604034d4  strictures-1.004004.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: grub (v1) in f18?

[Matthew Miller]

On Fri, Dec 07, 2012 at 10:56:44AM +0200, Panu Matilainen wrote:
> >>I haven't experienced this with F16, F17 or so far F18. What I'm seeing is:
> >>
> >>yum install/update grub gets me grub legacy.
> >>yum install/update grub-efi gets me grub legacy efi.
> >>yum install/update grub2 gets me grub2.
> >>yum install/update grub2-efi gets me grub2 efi.
> >
> >If you have *both* installed, grub2 will want to nuke grub every time an
> >update shows up, IIRC.
> 
> Yum and rpm refuse to install packages which are obsoleted by an
> installed package, so you can't really have both. Unless you first
> install grub2 and then grub with 'rpm --nodeps'...

But, it's not just if both installed, is it? The grub2 package obsoletes
grub, and yum follows obsoletes by default in dependency resolution.

Panu, you would know this better than I, so clearly I'm going crazy
somewhere. If you could explain how, I'd appreciate it. :)

Here's on an F17 image booted in a cloud service (so no grub at all
installed initially):

  $ rpm -qa |grep grub
  grubby-8.11-1.fc17.x86_64

(As expected, just grubby; nothing else matches.)

  $ sudo yum install grub
  [...]
  Package grub is obsoleted by grub2, trying to install
  1:grub2-2.0-0.39.fc17.x86_64 instead
  Resolving Dependencies
  --> Running transaction check
  ---> Package grub2.x86_64 1:2.0-0.39.fc17 will be installed
  --> Processing Dependency: grub2-tools = 1:2.0-0.39.fc17 for package:
  --> 1:grub2-2.0-0.39.fc17.x86_64
  [...and so on]

Even "yum install grub-0.97" gets this behavior. Now, I can set
"obsoletes=0" in /etc/yum.conf if I _really_ want to get grub installed, but 

  a) I don't actually want to change the default behavior of yum on the final
 image 

  b) I don't want users to get messed up if they innocently change that back
 to its default

  c) I'm not even sure how I would go about changing that pre-transaction in
 appliance-creator and other tools


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

Re: Where are we going? (Not a rant)

[Andrew Price]

Ah the ol' Fedora stability improvement thread. It must be Friday. Ok, 
I'll bite.


This sort of conversation often comes and goes without much being done. 
Usually it consists of debates between three camps:


1. Those who see Fedora as an intrinsically unstable distro which 
showcases and attracts testing for the latest upstream work
2. Those who want Fedora to be stable enough to become a realistic 
alternative to Windows and Ubuntu for the general masses
3. Those who want Fedora to be stable enough and supported for long 
enough to be used as a server OS


I think the reason nothing happens is due to the core issue not being 
agreed upon by all camps. It's very difficult to make progress on a 
solution unless you first understand and agree on the problem.


However, if you're still interested I've laid out some ideas, based on 
my belief that instability is a significant problem, below.


On 07/12/12 12:53, Tomas Radej wrote:

One of the results was a conversation I had with a few guys to
whom I recommended Fedora as a development environment. It showed me
that there's indeed something wrong. While they all said that Fedora's
features were brilliant, they unanimously rejected Fedora as a
primary system. The reason they gave me was, now quoting: It doesn't
really work.


One hypothesis is that too few people use Rawhide to a point where 
enough testing gets done before final releases. I think making some 
basic guarantees about Rawhide's stability (it boots, package management 
works, etc.) would go some way to increase early adoption and ensure 
bugs are reported and fixed before final releases, thus avoiding many 
unnecessary updates. I would certainly consider running Rawhide with 
such guarantees.


Once most of us are dog-fooding Rawhide the temptation to release the 
latest unstable upstream code in stable release updates would be 
significantly reduced and our update policy could be tightened to 
disallow version bumps, etc. in stable release updates similar to other, 
more popular distros' update policies.


I think this is a better first step forward than LTS releases because it 
focuses on users' first impressions of Fedora by increasing the 
stability level on the day of release.


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

Re: [389-devel] please review: Ticket 527 - ns-slapd segfaults if it cannot rename the logs

[Mark Reynolds]

HI Ludwig,

We only call emergency logging if we can't write to the log or rename 
it.  The server will shutdown once we can't write to the log - that's 
why we need to log a reason(if possible).


Mark

On 12/07/2012 04:13 AM, Ludwig Krispenz wrote:

Hi Mark,

the fix is ok to avoid the stack overflow, but doesn't this mean all 
further messages will be appended independent of log size ? Shouldn't 
we stop logging at some point if the 'emergency' log was called ?


Ludwig

On 12/06/2012 08:59 PM, Mark Reynolds wrote:

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

https://fedorahosted.org/389/attachment/ticket/527/0001-Ticket-527-ns-slapd-segfaults-if-it-cannot-rename-th.patch 





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


--
Mark Reynolds
Red Hat, Inc
mreyno...@redhat.com

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

Review swap: qpid-proton, rubygem-{bicho,inifile}

[Darryl L. Pierce]

Hi, I've got a few packages I'd like to get through review and will swap
reviews with anybody to do so.

qpid-proton
https://bugzilla.redhat.com/show_bug.cgi?id=874105

rubygem-bicho
https://bugzilla.redhat.com/show_bug.cgi?id=836368

rubygem-inifile
https://bugzilla.redhat.com/show_bug.cgi?id=874249

Thanks.

-- 
Darryl L. Pierce 
http://mcpierce.multiply.com/
"What do you care what people think, Mr. Feynman?"


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

Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

[Vít Ondruch]

Dne 7.12.2012 15:06, Jaroslav Reznik napsal(a):

- Original Message -

It doesn't matter from a "get this thing into Fedora" standpoint.  It
very much matters from a marketing/communication standpoint.  If it
didn't matter, Fedora Marketing wouldn't be picking specific items
out
of the overall Feature list.

The example I used in the meeting (which btw you should really go
read
the full logs at this point because all I'm doing is repeating
myself)
is that if you give a tech journalist a list of 10 Features, they can
write a pretty decent article about what is coming in the next Fedora
release.  If you give them a list of 20-30 Features, they're either
going to ignore you entirely or pick 10 Features they think are worth
writing about.

That's the problem - FeatureList should not be used tech journalists
at all! It's internal tracking "tool". For journalists, we have Talking
Points [1] - originally written for Ambassadors! (And yep, good time to
spin it up). We have Beats... Announcements based on these with picked
up the most important features without going into too much details -
easier for journalist to create a good article. Feature list changes
too often, it could be out of sync, feature pages are written for
technical people, usually hard to understand etc...

And yeah, as I understand - Features were created for marketing
purposes. So let's not call that internal list features list but use
some other term and then with cooperation with marketing and docs
pick up let say ten most important things that happened in recent
release and feature them as The Features. But marketing POV should not
limit our development tracking ;-)

[1] http://fedoraproject.org/wiki/Fedora_18_talking_points

Jaroslav


Agree.


Some Features are more important than others.  I want FESCo involved
in reviwing the ones that are big, have an impact across the distro,
are somewhat controversial, and have the potential to require a lot
of
coordination.  Whatever we call those, that is what I want reviewed.


There is no reason why FESCo couldn't pick such important features by 
themselves and review them. And keep the rest auto-approved. I guess our 
views are not that different. You just try to apply some measure to 
categorize features (or whatever we call those) where I say it is not 
possible. The amount of response of ML might be good guide for that, 
since we don't have any better.


Vít


josh
--
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: Where are we going? (Not a rant)

[Caterpillar]

Il 07/12/2012 13:53, Tomas Radej ha scritto:
> Hi everybody.
>
> [...]
> A Fedora contributor, Tomas Radej
>
>From the moment I started using Fedora to now, I installed it on 41
different machines of different owners. The unique and most impotant
negative feedback I had it when I upgraded a system from Fedora 14 to
15, that was the upgrade from Gnome 2 to Gnome 3. Everything was
crashing, a real nightmare. The end of the story? From that moment the
owner of that computer has a big problem with *me* (lol).
Fedora community should test big transitions like Gnome 2->3 for a
longer period of time
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

[Jaroslav Reznik]

- Original Message -
> It doesn't matter from a "get this thing into Fedora" standpoint.  It
> very much matters from a marketing/communication standpoint.  If it
> didn't matter, Fedora Marketing wouldn't be picking specific items
> out
> of the overall Feature list.
> 
> The example I used in the meeting (which btw you should really go
> read
> the full logs at this point because all I'm doing is repeating
> myself)
> is that if you give a tech journalist a list of 10 Features, they can
> write a pretty decent article about what is coming in the next Fedora
> release.  If you give them a list of 20-30 Features, they're either
> going to ignore you entirely or pick 10 Features they think are worth
> writing about.

That's the problem - FeatureList should not be used tech journalists
at all! It's internal tracking "tool". For journalists, we have Talking
Points [1] - originally written for Ambassadors! (And yep, good time to 
spin it up). We have Beats... Announcements based on these with picked
up the most important features without going into too much details -
easier for journalist to create a good article. Feature list changes
too often, it could be out of sync, feature pages are written for
technical people, usually hard to understand etc...

And yeah, as I understand - Features were created for marketing 
purposes. So let's not call that internal list features list but use
some other term and then with cooperation with marketing and docs
pick up let say ten most important things that happened in recent
release and feature them as The Features. But marketing POV should not
limit our development tracking ;-)

[1] http://fedoraproject.org/wiki/Fedora_18_talking_points

Jaroslav

> Some Features are more important than others.  I want FESCo involved
> in reviwing the ones that are big, have an impact across the distro,
> are somewhat controversial, and have the potential to require a lot
> of
> coordination.  Whatever we call those, that is what I want reviewed.
> 
> josh
> --
> 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

F-18 Branched report: 20121207 changes

[Fedora Branched Report]

Compose started at Fri Dec  7 09:15:42 UTC 2012







New package: libnetfilter_cthelper-1.0.0-3.fc18
 User-space infrastructure for connection tracking helpers

New package: peervpn-0.029-1.fc18
 A VPN software using full mesh network topology


Updated Packages:

NetworkManager-0.9.7.0-9.git20121004.fc18
-
* Wed Dec 05 2012 Dan Winship  - 0.9.7.0-9.git20121004
- Apply patch from master to read hostname from /etc/hostname (rh #831735)


alsa-lib-1.0.26-2.fc18
--
* Mon Dec 03 2012 Peter Robinson  1.0.26-2
- Create and own ucm directory so alsaucm doesn't crash.
- Cleanup and modernise spec


deltacloud-core-1.0.5-1.fc18

* Tue Nov 27 2012 Michal Fojtik  - 1.0.5-1
- Release 1.0.5


dhcp-4.2.4-23.P2.fc18
-
* Fri Nov 30 2012 Jiri Popelka  - 12:4.2.4-23.P2
- fix two resource leaks in lpf-ib.patch

* Mon Nov 26 2012 Jiri Popelka  - 12:4.2.4-22.P2
- add After=time-sync.target to dhcpd[6].service (#878293)
- remove groff from BuildRequires (no idea why it's been there)

* Fri Nov 16 2012 Jiri Popelka  - 12:4.2.4-21.P2
- multiple key statements in zone definition causes inappropriate error 
(#873794)

* Fri Oct 26 2012 Jiri Popelka  - 12:4.2.4-20.P2
- fix path to dhcpd6.leases in dhcpd6.conf.sample (#870458)

* Wed Oct 17 2012 Jiri Popelka  - 12:4.2.4-19.P2
- dhcpd needs to chown leases file created before de-rooting itself (#866714)


efibootmgr-0.5.4-14.fc18

* Wed Nov 28 2012 Matthew Garrett  - 0.5.4-14
- efibootmgr-0.5.4-Work-around-broken-Apple-firmware.patch
  Resolves: #873629
- efibootmgr-0.5.4-Remove-device-path-padding-on-non-Itanium.patch - improve
  spec conformance
- efibootmgr-0.5.4-fix-minor-memory-leak.patch - from upstream
- efibootmgr-0.5.4-fix-disk-minor-number-discovery.patch - from upstream
- efibootmgr-0.5.4-make_boot_var-does-not-check-for-failed-status-with-.patch -
  from upstream


fedora-packager-0.5.10.1-1.fc18
---
* Mon Dec 03 2012 Nick Bebout  - 0.5.10.1-1
- fix fedora-burn-yubikey to allow specifying what slot to use


fltk-1.3.0-8.fc18
-
* Tue Dec 04 2012 Adam Tkac  - 1.3.0-8
- fix ABI breakage caused by fltk-1_v4.3.x-cursor.patch (#883026)

* Thu Nov 29 2012 Adam Tkac  - 1.3.0-7
- add xcursor BR


geeqie-1.0-20.fc18
--
* Thu Nov 22 2012 Michael Schwendt  - 1.0-20
- Merge a patch to fix fullscreen mode.

* Tue Aug 14 2012 Michael Schwendt  - 1.0-19
- Fix license tag to GPLv2+ as GPL3 (only in file COPYING) had been
  added only temporarily for 1.0-alpha1.


glances-1.5.1-1.fc18

* Tue Nov 13 2012 Edouard Bourguignon  - 1.5.1-1
- Upgrade to 1.5.1 (fix compute data on el6)

* Thu Nov 08 2012 Edouard Bourguignon  - 1.5-1
- Upgrade to 1.5

* Sat Sep 01 2012 Edouard Bourguignon  - 1.4.1.1-1
- Upgrade to 1.4.1.1


gnome-bluetooth-3.6.1-2.fc18

* Thu Nov 29 2012 Dan Horák  - 1:3.6.1-2
- revive on Fedora/s390x, but drop Requires there - it's needed to fulfil 
compose dependencies


gnome-system-log-3.6.1-2.fc18
-
* Mon Nov 19 2012 Matthias Clasen  - 1:3.6.1-2
- Use auth_admin_keep in the polkit file (#878115)


gnome-user-share-3.0.4-2.fc18
-
* Wed Nov 28 2012 Matthias Clasen  3.0.4-2
- Compile schemas after installing the package, not before
  uninstalling it. Should fix some crashes (#877796)


gnupg2-2.0.19-6.fc18

* Thu Nov 22 2012 Tomas Mraz  - 2.0.19-6
- use AES as default crypto algorithm in FIPS mode (#879047)

* Fri Nov 16 2012 Jamie Nguyen  - 2.0.19-5
- rebuild for  - 1.0.0-2
- rebuilt

* Tue Sep 25 2012 Clément David  - 1.0.0-1
- Bump version


kernel-3.6.9-4.fc18
---
* Mon Dec 03 2012 Josh Boyer  - 3.6.9-2
- Backport 3 upstream fixes to resolve radeon schedule IB errors (rhbz 855275)

* Mon Dec 03 2012 Justin M. Forbes  3.6.9-1
- Linux 3.6.9

* Thu Nov 29 2012 Peter Robinson 
- Update some ARM GPIO and I2C configs

* Tue Nov 27 2012 Josh Boyer 
- Update patches for 8139cp issues from David Woodhouse (rhbz 851278)

* Mon Nov 26 2012 Josh Boyer  - 3.6.8-1
- Linux v3.6.8

* Mon Nov 26 2012 Josh Boyer 
- Fix regression in 8139cp driver, debugged by William J. Eaton (rhbz 851278)
- Fix ACPI video after _DOD errors (rhbz 869383)
- Fix ata command timeout oops in mvsas (rhbz 869629)
- Enable CONFIG_UIO_PDRV on ppc64 (rhbz 878180)
- CVE-2012-4530: stack disclosure binfmt_script load_script (rhbz 868285 880147)


keytool-maven-plugin-1.0-7.fc18
---
* Thu Nov 22 2012 Jaromir Capik  - 1.0-7
- Missing ASL 2.0 license file included
- Minor spec file changes according to the latest guidelines


librelp-1.0.1-1.fc18

* Wed Nov 21 2012 Tomas Heinrich  - 1.0.1-1
- upgrade to upstream version 1.0.1


libsecret-0.12-1.fc18
-
* Fri Nov 23 2012 Debarshi Ray  - 0.12-1
- Update to 0.1

Re: What would it take to make Software Collections work in Fedora?

[Rich Mattes]

On Fri, Dec 7, 2012 at 8:55 AM, Radek Vokal  wrote:

> On 12/06/2012 07:00 AM, Adam Williamson wrote:
>
>> On Wed, 2012-12-05 at 22:25 -0600, Michael Ekstrand wrote:
>>
>>> On 12/05/2012 03:06 PM, Bill Nottingham wrote:
>>>
 Matthew Miller (mat...@fedoraproject.org) said:

> Three things:
>
> 1) Fedora is big enough that we have concrete situations where one size
> doesn't fit all. Puppet being broken on F17 (and probably F18 as
> well)
> is a fine example of something within the distro itself. And, as a
> platform for development, offering more version choices to our
> users
> would be a strength.
>

 

 Well, then maybe Fedora's too big, and we should move to a model where
 Fedora is much smaller, and the grand Fedora universe contains things
 that
 are packaged *for* one or multiple Fedoras.

 

>>>
>>> FWIW (probably not much), I also think this is a great idea.  It feels
>>> strange to me that the same thing contains & manages everything from
>>> base system (e.g. kernel through core GNOME stack) and add-on apps (say
>>> Battle for Wesnoth, to pick a relatively obvious example).
>>>
>>> Now, there's a bike shed to be painted over where the lines should be
>>> drawn.
>>>
>>
>> We could draw them between Core and Extras!
>>
>>
> So what if we actually do .. but in a different way - eg. we would ensure
> that we have stable API, no feature breakage in a release for a package
> that do belong to "core" and allow faster turnaround for packages in
> "extras" .. it's not like locking it down as it used to be but defining
> more strict rules for certain set of packages.
>
>
> Doesn't this describe the critpath[1] process?

Rich

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

Re: What would it take to make Software Collections work in Fedora?

[Mark Bidewell]

On Fri, Dec 7, 2012 at 8:55 AM, Radek Vokal  wrote:

> On 12/06/2012 07:00 AM, Adam Williamson wrote:
>
>> On Wed, 2012-12-05 at 22:25 -0600, Michael Ekstrand wrote:
>>
>>> On 12/05/2012 03:06 PM, Bill Nottingham wrote:
>>>
 Matthew Miller (mat...@fedoraproject.org) said:

> Three things:
>
> 1) Fedora is big enough that we have concrete situations where one size
> doesn't fit all. Puppet being broken on F17 (and probably F18 as
> well)
> is a fine example of something within the distro itself. And, as a
> platform for development, offering more version choices to our
> users
> would be a strength.
>

 

 Well, then maybe Fedora's too big, and we should move to a model where
 Fedora is much smaller, and the grand Fedora universe contains things
 that
 are packaged *for* one or multiple Fedoras.

 

>>>
>>> FWIW (probably not much), I also think this is a great idea.  It feels
>>> strange to me that the same thing contains & manages everything from
>>> base system (e.g. kernel through core GNOME stack) and add-on apps (say
>>> Battle for Wesnoth, to pick a relatively obvious example).
>>>
>>> Now, there's a bike shed to be painted over where the lines should be
>>> drawn.
>>>
>>
>> We could draw them between Core and Extras!
>>
>>
> So what if we actually do .. but in a different way - eg. we would ensure
> that we have stable API, no feature breakage in a release for a package
> that do belong to "core" and allow faster turnaround for packages in
> "extras" .. it's not like locking it down as it used to be but defining
> more strict rules for certain set of packages.
>
>
> R
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.**org/mailman/listinfo/devel
>

+1

-- 
Mark Bidewell
http://www.linkedin.com/in/markbidewell
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: What would it take to make Software Collections work in Fedora?

[Radek Vokal]

On 12/06/2012 07:00 AM, Adam Williamson wrote:

On Wed, 2012-12-05 at 22:25 -0600, Michael Ekstrand wrote:

On 12/05/2012 03:06 PM, Bill Nottingham wrote:

Matthew Miller (mat...@fedoraproject.org) said:

Three things:

1) Fedora is big enough that we have concrete situations where one size
doesn't fit all. Puppet being broken on F17 (and probably F18 as well)
is a fine example of something within the distro itself. And, as a
platform for development, offering more version choices to our users
would be a strength.




Well, then maybe Fedora's too big, and we should move to a model where
Fedora is much smaller, and the grand Fedora universe contains things that
are packaged *for* one or multiple Fedoras.




FWIW (probably not much), I also think this is a great idea.  It feels
strange to me that the same thing contains & manages everything from
base system (e.g. kernel through core GNOME stack) and add-on apps (say
Battle for Wesnoth, to pick a relatively obvious example).

Now, there's a bike shed to be painted over where the lines should be drawn.


We could draw them between Core and Extras!



So what if we actually do .. but in a different way - eg. we would 
ensure that we have stable API, no feature breakage in a release for a 
package that do belong to "core" and allow faster turnaround for 
packages in "extras" .. it's not like locking it down as it used to be 
but defining more strict rules for certain set of packages.


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

Re: bugz.fedoraproject.org/ MIA?

[Matthias Runge]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/06/2012 09:26 PM, Ville Skyttä wrote:

> BTW the new fedora-packages webapp is much slower and less usable
> than the old pkgdb one for me, I'd personally prefer it to be
> switched back until the bugs like the above have been sorted out
> and the performance and usability have caught up.
> 
Yupp, I stumbled upon the same. Call me old-school, I liked the other
page better, but the newer is definitely more stylish.




- -- 
Matthias Runge 
   
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQwfDwAAoJEOnz8qQwcaIW2CwH/RvoTctxIwif34IpxsNa6VpA
Frdhr2WClJYEvh5wlmbPgu2wXO6iHScbcAG6JYF7xIApLszU+fWwkCX3b0Oj4W3Z
hw0ymuW1E0r6X+/RvK4MasSlwy6cEYQhJximwcI9vsDB6T988Yxv0e6XOWoEsCSN
zfIbOubEdGVQ+2nv/yL8qvk4MVCVatjItwWDaZCLQ7TjQGCuV7bPYLY8CuRFZMAp
5kRW4HO6pSYU2odeUQAjBNSYgsQXSpxYroeMIBED+OIZIhr4o1g+QhtvybtkIMSs
RpyQxft/ENmrFG9S/SLeuM0KCtxI4EUiggTaAwzbh88BuZOtEvx3VvEGuy1z3OU=
=nkpD
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Where are we going? (Not a rant)

[Jóhann B. Guðmundsson]

On 12/07/2012 12:53 PM, Tomas Radej wrote:

Hi everybody.

Disclaimer: This mail is written from the position of a Fedora
community member. Red Hat has nothing to do with this.

I don't want to start yet another rant saying that everything is broken
and we'd be better off if we aped Debian. Absolutely not. I don't want
to put blame on someone, I want to improve.

Fedora is all about passionate people doing what they want to
do in a community of like-minded folks. That's probably the most
awesome thing I've seen in my life - a bunch of folks not actually
charging money to each other, while providing everybody with fruits of
their efforts. It's probably trivial for you, because you've been doing
that for years. But for me (as I've been a part only for one year now),
it's something almost unimaginable. But reading this list showed me
that often the passion goes, at least in my eyes, too far. Instead of
constructive criticism, vitriolic scolding and personal insults are to
be found. This only makes effort in Fedora fragmented and inconsistent.

One of the results was a conversation I had with a few guys to
whom I recommended Fedora as a development environment. It showed me
that there's indeed something wrong. While they all said that Fedora's
features were brilliant, they unanimously rejected Fedora as a
primary system. The reason they gave me was, now quoting: It doesn't
really work.

While it's a simplistic statement with which I don't agree, it points
finger at the tradeoff Fedora had to make to become the fastest updated
Linux distro in the known universe - to give up much of stability. I
sort of like that decision, but I propose to step back and look at the
big picture to see if we aren't on the fast side a tad too much. Having
a completely new system out every half a year is great, but having a
system where various things crash for various reasons pretty much all
the time isn't. I don't have a definitive way to fix this, but I have
some ideas, and you people out there have better ones. Something like
having a solid, tested core that updates half as often as the developer
libraries springs into my mind, so I want to know what springs into
yours.

The threat for Fedora is that even in the FOSS, there is competition.
Distros are competing for users - users that give back, users that
report bugs, or users that are or become maintainers and developers.
When the overwhelming response to Fedora is "Hey, they've got some neat
features, but I need it to work, so that's why I'm using XYZ instead",
the user/dev base is going to wither and move elsewhere.

As I said, I don't have the knowledge, mental capacity, or mandate to
give the answer to where Fedora is going and where it should be going.
I am just worrying that if there is no change in how Fedora is done, it
will be harder and harder for the community to thrive, and I wouldn't
like that. So, through this e-mail addressed to all the Fedora
community, I am seeking support for a movement, both collective and
individual, that would improve communication, cooperation and generally
the life of Fedora on the most fundamental basis.

To conclude, I don't want this e-mail to be accusing, flaming, or
mentoring. It is meant to be concerned, inspiring and accepted with a
good, yet scrutinizing mind.



If we want to solve this we need to release an Fedora LTS release for 
our and the potential other user base that don't have to/want to update 
every 6 or 12 months.


That's the feed back I have received when I have asked both sysadmins 
and developers that don't already use Fedora and why they wont use it.


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

Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

[Josh Boyer]

On Fri, Dec 7, 2012 at 4:28 AM, Vít Ondruch  wrote:
>>> Alternately, "Feature" could be the term for the any small or big thing
>>> which is useful to track and tout for marketing purposes, and big
>>> technical
>>> changes could be, I dunno... "Major Changes".
>>
>> The meeting minutes showed that Fedora Marketing is already filtering
>> the current Feature list and picking the important ones to highlight, so
>> I don't think continuing to call the small ones Features is accurate.
>>
>> I mean, sure it could be done but it seems to make more sense to change
>> the name of the small ones instead.  Or just have them go to release
>> notes.  The main point is, calling them all the same thing is confusing
>> and leads to a basically useless "Feature list".
>>
> Feature is something somebody considers important enough to create feature
> page for it. Period.

We're going to disagree on this point.  It's OK that we disagree.

> I am not sure why do you want to categorize it by size and impact, when it
> will be autocategorized by feedback on ML. The only think matters is that
> the Feature is widely advertised and that the community can provide early
> feedback. Please avoid bureaucracy. I would realy hate to see something like
> FFCo (Fedora Feature Committee), which would decided if feature is feature,
> major change, alteration, evolution or disruption, since it really doesn't
> matter.

It doesn't matter from a "get this thing into Fedora" standpoint.  It
very much matters from a marketing/communication standpoint.  If it
didn't matter, Fedora Marketing wouldn't be picking specific items out
of the overall Feature list.

The example I used in the meeting (which btw you should really go read
the full logs at this point because all I'm doing is repeating myself)
is that if you give a tech journalist a list of 10 Features, they can
write a pretty decent article about what is coming in the next Fedora
release.  If you give them a list of 20-30 Features, they're either
going to ignore you entirely or pick 10 Features they think are worth
writing about.

Some Features are more important than others.  I want FESCo involved
in reviwing the ones that are big, have an impact across the distro,
are somewhat controversial, and have the potential to require a lot of
coordination.  Whatever we call those, that is what I want reviewed.

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

Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

[Jóhann B. Guðmundsson]

On 12/07/2012 11:13 AM, Vít Ondruch wrote:

Dne 7.12.2012 11:13, "Jóhann B. Guðmundsson" napsal(a):

On 12/07/2012 09:28 AM, Vít Ondruch wrote:


Feature is something somebody considers important enough to create 
feature page for it. Period.


That describes the current state and is your point of view.

To me an "Feature" is a completely different thing.


Could you be more specific please?


For example major release for a component or a group of components







I am not sure why do you want to categorize it by size and impact, 
when it will be autocategorized by feedback on ML. 


It's common knowledge that you cant autocategorized by feedback on 
Mailing list regardless what's it's for. ( For obvious reasons )




You have to be subscribed to d the relevant mailing list and not 
ignoring the individual(s) responsible for the feature etc..


They are probably not so obvious to me. But I can imagine several 
types of responses on ML:


And what I'm pointing on are using mailing list for that.





The only think matters is that the Feature is widely advertised and 
that the community can provide early feedback. 


No that is not enough because in the end you will only get feedback 
from users of those feature not necessary from developers of other 
components that might get affected by that feature.


Yes, nobody never cares until it is not late. I can't change that. But 
I'm trying. Announcing features in devel/devel-announce is definitely 
step in good direction.


What about all the other communities the feature might affect and the 
relevant party that is not subscribed devel/devel-announce in those 
communites?




Please avoid bureaucracy. I would realy hate to see something like 
FFCo (Fedora Feature Committee), which would decided if feature is 
feature, major change, alteration, evolution or disruption, since it 
really doesn't matter.


FESCO is for that, as in to accept,decide and determine the wider 
impact an feature might have to the whole projects eco system and 
arguably the entity that's responsible for it to be integrated into 
the distribution in as painless manner for users and developers 
alike. ( from my pov ).


FESCo's responsibilities does not change at all. The benefit will be 
that FESCo will be able to spent more time paying attention to 
features that are worth of attention. Don't forget that this 
discussion is initiative of FESCo members, who feels to be overwhelmed 
by non-important features, not mine.




Yes and to do so you need to first and foremost know what is considered 
an feature and what you mentioned "Feature is something somebody 
considers important enough to create feature page for it. Period. " 
leaves them in the exactly same place as it is now.


As I have said before we cant fix the feature process until we have 
determined what's considered an feature in the first place and if the 
feature process is mandatory or not.


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

Where are we going? (Not a rant)

[Tomas Radej]

Hi everybody.

Disclaimer: This mail is written from the position of a Fedora
community member. Red Hat has nothing to do with this.

I don't want to start yet another rant saying that everything is broken
and we'd be better off if we aped Debian. Absolutely not. I don't want
to put blame on someone, I want to improve.

Fedora is all about passionate people doing what they want to
do in a community of like-minded folks. That's probably the most
awesome thing I've seen in my life - a bunch of folks not actually
charging money to each other, while providing everybody with fruits of
their efforts. It's probably trivial for you, because you've been doing
that for years. But for me (as I've been a part only for one year now),
it's something almost unimaginable. But reading this list showed me
that often the passion goes, at least in my eyes, too far. Instead of
constructive criticism, vitriolic scolding and personal insults are to
be found. This only makes effort in Fedora fragmented and inconsistent.

One of the results was a conversation I had with a few guys to
whom I recommended Fedora as a development environment. It showed me
that there's indeed something wrong. While they all said that Fedora's
features were brilliant, they unanimously rejected Fedora as a
primary system. The reason they gave me was, now quoting: It doesn't
really work.

While it's a simplistic statement with which I don't agree, it points
finger at the tradeoff Fedora had to make to become the fastest updated
Linux distro in the known universe - to give up much of stability. I
sort of like that decision, but I propose to step back and look at the
big picture to see if we aren't on the fast side a tad too much. Having
a completely new system out every half a year is great, but having a
system where various things crash for various reasons pretty much all
the time isn't. I don't have a definitive way to fix this, but I have
some ideas, and you people out there have better ones. Something like
having a solid, tested core that updates half as often as the developer
libraries springs into my mind, so I want to know what springs into
yours.

The threat for Fedora is that even in the FOSS, there is competition.
Distros are competing for users - users that give back, users that
report bugs, or users that are or become maintainers and developers.
When the overwhelming response to Fedora is "Hey, they've got some neat
features, but I need it to work, so that's why I'm using XYZ instead",
the user/dev base is going to wither and move elsewhere. 

As I said, I don't have the knowledge, mental capacity, or mandate to
give the answer to where Fedora is going and where it should be going.
I am just worrying that if there is no change in how Fedora is done, it
will be harder and harder for the community to thrive, and I wouldn't
like that. So, through this e-mail addressed to all the Fedora
community, I am seeking support for a movement, both collective and
individual, that would improve communication, cooperation and generally
the life of Fedora on the most fundamental basis.

To conclude, I don't want this e-mail to be accusing, flaming, or
mentoring. It is meant to be concerned, inspiring and accepted with a
good, yet scrutinizing mind.

A Fedora contributor, Tomas Radej

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

Re: selinux-policy-3.11.1-57 and 3.11.1-58 breaking access to 'storage' drives

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/07/2012 01:46 AM, Ankur Sinha wrote:
> On Mon, 2012-12-03 at 12:53 -0600, Bruno Wolff III wrote:
>> In bohdi, people have reported that -59 fixed the problem going forward.
>> But people already affected need to relabel.
> 
> Looks like I got caught with this one. However, the updated and a relabel
> isn't working for me. My USB attached HDDs are still unusable:
> 
> 
>> [root@dhcppc1 Ankur_Backup]# pwd /mnt/Ankur_Backup [root@dhcppc1
>> Ankur_Backup]# lash -Z ls: cannot access references server: Permission
>> denied ls: cannot access .Pictures: Permission denied ls: cannot access
>> Config_files: Permission denied ls: cannot access .keys: Permission
>> denied ls: cannot access .AnkurBackup: Permission denied total 0 
>> ?- ? ?  .AnkurBackup ?- ?
>> ?  Config_files ?- ? ?
>> .keys ?- ? ?  .Pictures 
>> ?- ? ?  references server 
>> [root@dhcppc1 Ankur_Backup]#
> 
> 
>> [root@dhcppc1 Entertainment]# lash -Z ls: cannot access Films: Permission
>> denied ls: cannot access CM_backup: Permission denied ls: cannot access
>> TV: Permission denied total 0 ?- ? ?
>> CM_backup ?- ? ?  Films 
>> ?- ? ?  TV [root@dhcppc1
>> Entertainment]#
>> 
> 
> selinux-policy-3.11.1-59.fc18.noarch
> 
> After a setenforce 0, this is what it says:
> 
>> [root@dhcppc1 Entertainment]# lash -Z total 12K drwxrwxr-x. ankur ankur
>> unconfined_u:object_r:file_t:s0  CM_backup drwxrwxr-x. ankur ankur
>> unconfined_u:object_r:file_t:s0  Films drwxrwxr-x. ankur ankur
>> unconfined_u:object_r:file_t:s0  TV [root@dhcppc1 Entertainment]#
> 
> 
>> [root@dhcppc1 Ankur_Backup]# lash -Z total 88K drwxrwxr-x. ankur ankur
>> unconfined_u:object_r:file_t:s0  .AnkurBackup drwxrwxr-x. ankur ankur
>> unconfined_u:object_r:file_t:s0  Config_files drwxrwxr-x. ankur ankur
>> unconfined_u:object_r:file_t:s0  .keys drwxrwxr-x. ankur ankur
>> unconfined_u:object_r:file_t:s0  .Pictures drwxr-xr-x. root  root
>> unconfined_u:object_r:file_t:s0  references server [root@dhcppc1
>> Ankur_Backup]#
>> 
> 
> How would I fix this please? It's really causing me quite some trouble :(
> 
> 
> 
Update to the -60 policy.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDB1okACgkQrlYvE4MpobPhFQCgszpUcoDvrrYJLvaOkP7l9y6X
U7UAnjz1ribRQp2ESQ5A90uRFDYDzPx8
=SZ4K
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

[Vít Ondruch]

Dne 7.12.2012 11:13, "Jóhann B. Guðmundsson" napsal(a):

On 12/07/2012 09:28 AM, Vít Ondruch wrote:


Feature is something somebody considers important enough to create 
feature page for it. Period.


That describes the current state and is your point of view.

To me an "Feature" is a completely different thing.


Could you be more specific please?





I am not sure why do you want to categorize it by size and impact, 
when it will be autocategorized by feedback on ML. 


It's common knowledge that you cant autocategorized by feedback on 
Mailing list regardless what's it's for. ( For obvious reasons )


They are probably not so obvious to me. But I can imagine several types 
of responses on ML:


1) No response at all. This is positive, since the feature was probably 
discussed on different places previously, such as SIG ML or is 
non-controversial.
2) Positive response. Everybody probably agrees that Gnome 3 should be 
updated in next release.

3) Controversial feature, such as /tmp on tmpfs
4) Only negative feedback. E.g. lets move to yet another init system.
5) WTF feedback. Why are you even proposing this minor update of this 
unknown library as a feature (but this is non-category, since it will be 
probably rejected by Package Wrangler already)?


These are 5 categories of features I can imagine. Now please tell me if 
the categorization is not clear and if that is not obvious how to 
proceed with these.




The only think matters is that the Feature is widely advertised and 
that the community can provide early feedback. 


No that is not enough because in the end you will only get feedback 
from users of those feature not necessary from developers of other 
components that might get affected by that feature.


Yes, nobody never cares until it is not late. I can't change that. But 
I'm trying. Announcing features in devel/devel-announce is definitely 
step in good direction.




Please avoid bureaucracy. I would realy hate to see something like 
FFCo (Fedora Feature Committee), which would decided if feature is 
feature, major change, alteration, evolution or disruption, since it 
really doesn't matter.


FESCO is for that, as in to accept,decide and determine the wider 
impact an feature might have to the whole projects eco system and 
arguably the entity that's responsible for it to be integrated into 
the distribution in as painless manner for users and developers alike. 
( from my pov ).


FESCo's responsibilities does not change at all. The benefit will be 
that FESCo will be able to spent more time paying attention to features 
that are worth of attention. Don't forget that this discussion is 
initiative of FESCo members, who feels to be overwhelmed by 
non-important features, not mine.



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

Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

[Jaroslav Reznik]

- Original Message -
> On Fri, 2012-12-07 at 10:28 +0100, Vít Ondruch wrote:
> > Dne 6.12.2012 21:40, Josh Boyer napsal(a):
> > > On Thu, Dec 6, 2012 at 3:18 PM, Matthew Miller
> > >  wrote:
> > >> On Thu, Dec 06, 2012 at 11:20:22AM -0500, Josh Boyer wrote:
> > >>> As I said in the meeting yesterday, I think the definition of a
> > >>> Feature
> > >>> needs to be cleared up before we can really tackle this one.
> > >>>  Feature to
> > >>> me is something important enough that it shouldn't be
> > >>> auto-accepted.  If
> > >>> there is some other class of thing people submit that isn't a
> > >>> Feature,
> > >>> then I might be for auto-accepting of those.
> > >> Alternately, "Feature" could be the term for the any small or
> > >> big thing
> > >> which is useful to track and tout for marketing purposes, and
> > >> big technical
> > >> changes could be, I dunno... "Major Changes".
> > > The meeting minutes showed that Fedora Marketing is already
> > > filtering
> > > the current Feature list and picking the important ones to
> > > highlight, so
> > > I don't think continuing to call the small ones Features is
> > > accurate.
> > >
> > > I mean, sure it could be done but it seems to make more sense to
> > > change
> > > the name of the small ones instead.  Or just have them go to
> > > release
> > > notes.  The main point is, calling them all the same thing is
> > > confusing
> > > and leads to a basically useless "Feature list".
> > >
> > > josh
> > 
> > Feature is something somebody considers important enough to create
> > feature page for it. Period.
> > 
> > I am not sure why do you want to categorize it by size and impact,
> > when
> > it will be autocategorized by feedback on ML. The only think
> > matters is
> > that the Feature is widely advertised and that the community can
> > provide
> > early feedback. Please avoid bureaucracy. I would realy hate to see
> > something like FFCo (Fedora Feature Committee), which would decided
> > if
> > feature is feature, major change, alteration, evolution or
> > disruption,
> > since it really doesn't matter.
> 
> Maybe we can persuade Josh if we do s/Feature/A change that is worth
> announcing and potentially also tracking or advertising/.

Yep, as the main idea is to collect as much ideas/changes to be 
publicly announced and if we say only part of these are Features
AFTER discussion/review - I'm ok with that.

As it's the goal - to know about changes people do not consider
features but definitely could be raised to the feature status.

The common example I see as a wrangler - hey, I'm not sure this
functionality is worth creating feature, and you know, the process,
and nobody would care... But once the feature is accepted - wow,
I got so much response, from all people from different projects
that touch the area and we're now working on integration etc. ->
*VISIBILITY*.

Do not call it "Feature Process" but "Planning process" - as it
fits the decision to create F19 schedule after we know the scope
of it based on proposals. And then - I'm ok with even more terms -
Feature for something we really want to feature and make Marketing's
life easier - so not based on scope, but marketing and define
more "boxes"... 

Jaroslav

> --
> Tomas Mraz
> No matter how far down the wrong road you've gone, turn back.
>   Turkish proverb
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

[Tomas Mraz]

On Fri, 2012-12-07 at 10:28 +0100, Vít Ondruch wrote: 
> Dne 6.12.2012 21:40, Josh Boyer napsal(a):
> > On Thu, Dec 6, 2012 at 3:18 PM, Matthew Miller  
> > wrote:
> >> On Thu, Dec 06, 2012 at 11:20:22AM -0500, Josh Boyer wrote:
> >>> As I said in the meeting yesterday, I think the definition of a Feature
> >>> needs to be cleared up before we can really tackle this one.  Feature to
> >>> me is something important enough that it shouldn't be auto-accepted.  If
> >>> there is some other class of thing people submit that isn't a Feature,
> >>> then I might be for auto-accepting of those.
> >> Alternately, "Feature" could be the term for the any small or big thing
> >> which is useful to track and tout for marketing purposes, and big technical
> >> changes could be, I dunno... "Major Changes".
> > The meeting minutes showed that Fedora Marketing is already filtering
> > the current Feature list and picking the important ones to highlight, so
> > I don't think continuing to call the small ones Features is accurate.
> >
> > I mean, sure it could be done but it seems to make more sense to change
> > the name of the small ones instead.  Or just have them go to release
> > notes.  The main point is, calling them all the same thing is confusing
> > and leads to a basically useless "Feature list".
> >
> > josh
> 
> Feature is something somebody considers important enough to create 
> feature page for it. Period.
> 
> I am not sure why do you want to categorize it by size and impact, when 
> it will be autocategorized by feedback on ML. The only think matters is 
> that the Feature is widely advertised and that the community can provide 
> early feedback. Please avoid bureaucracy. I would realy hate to see 
> something like FFCo (Fedora Feature Committee), which would decided if 
> feature is feature, major change, alteration, evolution or disruption, 
> since it really doesn't matter.

Maybe we can persuade Josh if we do s/Feature/A change that is worth
announcing and potentially also tracking or advertising/.

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

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

Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

[Jóhann B. Guðmundsson]

On 12/07/2012 09:28 AM, Vít Ondruch wrote:


Feature is something somebody considers important enough to create 
feature page for it. Period.


That describes the current state and is your point of view.

To me an "Feature" is a completely different thing.



I am not sure why do you want to categorize it by size and impact, 
when it will be autocategorized by feedback on ML. 


It's common knowledge that you cant autocategorized by feedback on 
Mailing list regardless what's it's for. ( For obvious reasons )


The only think matters is that the Feature is widely advertised and 
that the community can provide early feedback. 


No that is not enough because in the end you will only get feedback from 
users of those feature not necessary from developers of other components 
that might get affected by that feature.


Please avoid bureaucracy. I would realy hate to see something like 
FFCo (Fedora Feature Committee), which would decided if feature is 
feature, major change, alteration, evolution or disruption, since it 
really doesn't matter.


FESCO is for that, as in to accept,decide and determine the wider impact 
an feature might have to the whole projects eco system and arguably the 
entity that's responsible for it to be integrated into the distribution 
in as painless manner for users and developers alike. ( from my pov ).


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

Re: What would it take to make Software Collections work in Fedora?

[Aleksandar Kurtakov]

- Original Message -
> From: "Vít Ondruch" 
> To: devel@lists.fedoraproject.org
> Sent: Friday, December 7, 2012 11:54:46 AM
> Subject: Re: What would it take to make Software Collections work in Fedora?
> 
> Dne 6.12.2012 17:31, Seth Vidal napsal(a):
> >
> >
> >
> > On Thu, 6 Dec 2012, Jan Zelený wrote:
> >
> >>
> >> The original use case for SCLs is to provide a way to deliver
> >> newer
> >> versions
> >> of SW in stable distributions like RHEL/CentOS than those
> >> available
> >> in the
> >> core system and make sure system packages and collection packages
> >> don't
> >> collide in any way (names, libraries, system paths, ...).
> >>
> >
> > right and the motivators for the above are customers/users who have
> > to
> > deal with their developers complaining about wanting a
> > specific/newer/older/intermediate version of some language or
> > another
> > and its modules.
> >
> > they complain to their ops people, they complain to fedora/red hat.
> >
> >
> 
> Oh common. You offended every developer on this ML. May be you should
> consider that it is not just about developers, but it is also about
> their management and customers who pays their bills.
> 
> In my previous job, we were developing application for our internal
> customer. During development, we were free to use any library which
> suited our needs. However, in some point, our customer was satisfied
> with functionality he had and he didn't want to spent any more money
> on
> development. Since that time, during maintenance, it was not any more
> my
> choice what library of what version I will use, since the system was
> built and running.
> 
> Now suddenly, after several years, the provider wants to quit their
> services and the application needs to be migrated. That would be
> perfect
> case for SC, because it would allow migration with lowest cost.
> 
> So what you would suggest? Was there any decision wrong in that
> process?

Migration time is the perfect time to modernize your application. And the 
customer will pay the bill no matter what - whether he will pay for the 
creation of the SC or for modernizing the application. Why would you pay for 
maintaining some obsolete system when you can make it work in a more 
supportable way? This sounds really wrong to me. If we speak about people that 
are fine paying certain amount for maintaining SC every couple of months until 
it becomes impossible to maintain the app and they pay even more to write new 
app I would say that your definition of lowest cost is quite short sided.

Alexander Kurtakov
Red Hat Eclipse team


> 
> 
> Vít
> --
> 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: What would it take to make Software Collections work in Fedora?

[Dodji Seketeli]

Fernando Nasser  a écrit:

> And _maintain_ them, with all security fixes.
>
> The problem with duplication is above all one of scalability of
> maintenance.

Please, avoiding top-posting like this would be very welcome here.
Otherwise, it is quite hard to know what you are replying to exactly.

Thank you for your understanding.

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

Re: What would it take to make Software Collections work in Fedora?

[Vít Ondruch]

Dne 6.12.2012 17:31, Seth Vidal napsal(a):




On Thu, 6 Dec 2012, Jan Zelený wrote:



The original use case for SCLs is to provide a way to deliver newer 
versions
of SW in stable distributions like RHEL/CentOS than those available 
in the

core system and make sure system packages and collection packages don't
collide in any way (names, libraries, system paths, ...).



right and the motivators for the above are customers/users who have to 
deal with their developers complaining about wanting a 
specific/newer/older/intermediate version of some language or another 
and its modules.


they complain to their ops people, they complain to fedora/red hat.




Oh common. You offended every developer on this ML. May be you should 
consider that it is not just about developers, but it is also about 
their management and customers who pays their bills.


In my previous job, we were developing application for our internal 
customer. During development, we were free to use any library which 
suited our needs. However, in some point, our customer was satisfied 
with functionality he had and he didn't want to spent any more money on 
development. Since that time, during maintenance, it was not any more my 
choice what library of what version I will use, since the system was 
built and running.


Now suddenly, after several years, the provider wants to quit their 
services and the application needs to be migrated. That would be perfect 
case for SC, because it would allow migration with lowest cost.


So what you would suggest? Was there any decision wrong in that process?


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

Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

[Vít Ondruch]

Dne 6.12.2012 21:40, Josh Boyer napsal(a):

On Thu, Dec 6, 2012 at 3:18 PM, Matthew Miller  wrote:

On Thu, Dec 06, 2012 at 11:20:22AM -0500, Josh Boyer wrote:

As I said in the meeting yesterday, I think the definition of a Feature
needs to be cleared up before we can really tackle this one.  Feature to
me is something important enough that it shouldn't be auto-accepted.  If
there is some other class of thing people submit that isn't a Feature,
then I might be for auto-accepting of those.

Alternately, "Feature" could be the term for the any small or big thing
which is useful to track and tout for marketing purposes, and big technical
changes could be, I dunno... "Major Changes".

The meeting minutes showed that Fedora Marketing is already filtering
the current Feature list and picking the important ones to highlight, so
I don't think continuing to call the small ones Features is accurate.

I mean, sure it could be done but it seems to make more sense to change
the name of the small ones instead.  Or just have them go to release
notes.  The main point is, calling them all the same thing is confusing
and leads to a basically useless "Feature list".

josh


Feature is something somebody considers important enough to create 
feature page for it. Period.


I am not sure why do you want to categorize it by size and impact, when 
it will be autocategorized by feedback on ML. The only think matters is 
that the Feature is widely advertised and that the community can provide 
early feedback. Please avoid bureaucracy. I would realy hate to see 
something like FFCo (Fedora Feature Committee), which would decided if 
feature is feature, major change, alteration, evolution or disruption, 
since it really doesn't matter.


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

Re: Summary/Minutes for Wednesday's FESCo meeting (2012-12-05)

[Vít Ondruch]

Dne 6.12.2012 18:23, Josh Boyer napsal(a):

On Thu, Dec 6, 2012 at 11:54 AM, Vít Ondruch  wrote:

Also, there was dissent already in the "auto-approving" of leaf-features
during the meeting discussion so I am not sure that auto-accepting of
Features in general given a lack of response is ever going to actually
happen.  I personally wouldn't vote for it.


This proposal entirely avoids discussion of "leaf-features", "self contained
features" or "complex features with system-wide impact" since there will
never by any reasonable metrics you can apply to decide. If you can't decide
what feature you are dealing with, how you want to judge if FESCo should be
approving it or not.

If some FESCo member thinks that is should be approved by FESCo, s/he still
has the power to open ticket for FESCo meeting. The same power as other
Fedora community members.

Actually I would be very interested to hear why there should not be
"auto-approving". Please enlighten me.

I explained my reasoning in the part of the email you cut off in your
reply.

josh


Sorry Josh, but I can't find any reasons in your quote:

"Also, there was dissent already in the "auto-approving" of leaf-features
during the meeting discussion so I am not sure that auto-accepting of
Features in general given a lack of response is ever going to actually
happen.  I personally wouldn't vote for it."


Only reason I see is "there was dissent". So based on some dissent, you 
are against "auto-approving"?


I'd love to hear why there is dissent. What is the reason for dissent.


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

Re: What would it take to make Software Collections work in Fedora?

[Marcela Mašláňová]

On 12/06/2012 05:08 PM, Richard W.M. Jones wrote:

On Thu, Dec 06, 2012 at 10:50:03AM -0500, Mark Bidewell wrote:

I used to use Fedora as my primary OS (Now I use a Mac).  The major issue
which drove me away and which I believe SC would help to solve is that with
the current dependency model is that it becomes I want a new version of
Libreoffice so now I have to upgrade my entire system from the Kernel on up
(and by upgrade I mean clean install) to avoid issues.  SC would help
decouple system and userland apps which would do wonders for usability.


You're using a Mac now, so good luck.

But I'm pretty sure that software collections would not have helped
you to upgrade Libreoffice.  Which, by the way, is possible without
upgrading everything: just compile the later SRPMs.  In other words,
create your own backports repository, and find a group of people who
have the same problem to share the security and maintenance burden
around.

Rich.

In that case he might use gentoo ;-) On the other hand create a 
collection for LibreOffice and support it would be a lot of work.


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