Re: Proposed F19 Feature: systemd features

[Adam Williamson]

On Sat, 2013-02-02 at 07:24 +, "Jóhann B. Guðmundsson" wrote:
> On 02/02/2013 07:12 AM, David Tardon wrote:
> > On Sat, Feb 02, 2013 at 06:20:18AM +, "Jóhann B. Guðmundsson" wrote:
> >> On 02/02/2013 05:57 AM, Chris Adams wrote:
> >>> If you can't handle that, then Fedora development might not be the right
> >>> place for you.
> >>>
> >> Get the fuck out before you get in my business. If you want to test
> >> me here I am deal with it because I wont back down not after the
> >> treatment he has given me!
> >>
> >> You have absolutely no idea what I have sacrificed for the project
> >> and if you want to head down that road son realize I dont bark I
> >> bite!
> >>
> >> Chris Adams care to explain to me what the fuck you have been doing
> >> all those years other than trying to play the tough boy?
> >>
> >> Let's put your contribution to the test!
> > Congratulations! You have proved your "merit" once again. That personal
> > attack was uncalled for.
> 
> Was it?
> 
> He threaten me I responded.
> 
> The position and do correct me if I'm wrong for Adam did not exist 
> before he got hired,
> and he was not even hired from the community.
> 
> Care to share the link to his position at that time.
> 
> Feel free to use the internet archive let's analyze what stood in it,
> 
> Prove me wrong and I shall be the first to admit my wrong doing, my 
> mistake and apologize to all parties involved.

Um...Chris Adams and I are two different people. He doesn't work for RH.
I haven't been involved in this strand of the thread at all.
-- 
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: Proposed F19 Feature: systemd features

[David Tardon]

On Sat, Feb 02, 2013 at 07:06:12AM +, "Jóhann B. Guðmundsson" wrote:
> On 02/02/2013 07:03 AM, David Tardon wrote:
> >On Sat, Feb 02, 2013 at 02:08:00AM +, "Jóhann B. Guðmundsson" wrote:
> >>When I meet a maintainer in the project that stated to me "I have to
> >>talk to my manager first" before upgrading his "component" that
> >>rings alarm bells to me, That gives me the feel that they are
> >>maintaining their components as a part of their job not because they
> >>want to scratch an itch and want to!
> >There is a third reason for maintaining a component: it is a dependency
> >for another component the packager maintains. This is applicable for
> >_all_ packagers, be they from Red Hat or the community. You either
> >conveniently omitted this reason to make an argument or never thought of
> >it, in which case I respectfully ask you to butt out of this thread
> >because you do not know what you are talking about.
> 
> Oh in my case it was an "primary" component no dependency that Red
> Hat maintainer could not update until he got approval but for the

You generalized one specific case to _all components of all Red Hat
maintainers_. When I rejected that generalization, you are counteracting
by claiming that my argument does not apply for that one _specific_
case. Sorry, but that is a faulty reasoning.

> sake of your argument and concision let's lower my IQ to an rock (
> which I do believe is 20 ) and say I dont have freaking flying idea
> what I'm talking about.

Is this sarcasm or a personal attack? I am not quite sure...

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

Re: Proposed F19 Feature: systemd features

[Jóhann B. Guðmundsson]

On 02/02/2013 07:12 AM, David Tardon wrote:

On Sat, Feb 02, 2013 at 06:20:18AM +, "Jóhann B. Guðmundsson" wrote:

On 02/02/2013 05:57 AM, Chris Adams wrote:

If you can't handle that, then Fedora development might not be the right
place for you.


Get the fuck out before you get in my business. If you want to test
me here I am deal with it because I wont back down not after the
treatment he has given me!

You have absolutely no idea what I have sacrificed for the project
and if you want to head down that road son realize I dont bark I
bite!

Chris Adams care to explain to me what the fuck you have been doing
all those years other than trying to play the tough boy?

Let's put your contribution to the test!

Congratulations! You have proved your "merit" once again. That personal
attack was uncalled for.


Was it?

He threaten me I responded.

The position and do correct me if I'm wrong for Adam did not exist 
before he got hired,

and he was not even hired from the community.

Care to share the link to his position at that time.

Feel free to use the internet archive let's analyze what stood in it,

Prove me wrong and I shall be the first to admit my wrong doing, my 
mistake and apologize to all parties involved.


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

Re: Proposed F19 Feature: systemd features

[David Tardon]

On Sat, Feb 02, 2013 at 06:20:18AM +, "Jóhann B. Guðmundsson" wrote:
> On 02/02/2013 05:57 AM, Chris Adams wrote:
> >If you can't handle that, then Fedora development might not be the right
> >place for you.
> >
> Get the fuck out before you get in my business. If you want to test
> me here I am deal with it because I wont back down not after the
> treatment he has given me!
> 
> You have absolutely no idea what I have sacrificed for the project
> and if you want to head down that road son realize I dont bark I
> bite!
> 
> Chris Adams care to explain to me what the fuck you have been doing
> all those years other than trying to play the tough boy?
> 
> Let's put your contribution to the test!

Congratulations! You have proved your "merit" once again. That personal
attack was uncalled for.

@list admins: Could we put this person on the moderation list, please?

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

Re: Proposed F19 Feature: systemd features

[Jóhann B. Guðmundsson]

On 02/02/2013 07:03 AM, David Tardon wrote:

On Sat, Feb 02, 2013 at 02:08:00AM +, "Jóhann B. Guðmundsson" wrote:

When I meet a maintainer in the project that stated to me "I have to
talk to my manager first" before upgrading his "component" that
rings alarm bells to me, That gives me the feel that they are
maintaining their components as a part of their job not because they
want to scratch an itch and want to!

There is a third reason for maintaining a component: it is a dependency
for another component the packager maintains. This is applicable for
_all_ packagers, be they from Red Hat or the community. You either
conveniently omitted this reason to make an argument or never thought of
it, in which case I respectfully ask you to butt out of this thread
because you do not know what you are talking about.


Oh in my case it was an "primary" component no dependency that Red Hat 
maintainer could not update until he got approval but for the sake of 
your argument and concision let's lower my IQ to an rock ( which I do 
believe is 20 ) and say I dont have freaking flying idea what I'm 
talking about.


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

Re: Proposed F19 Feature: systemd features

[David Tardon]

On Sat, Feb 02, 2013 at 02:08:00AM +, "Jóhann B. Guðmundsson" wrote:
> When I meet a maintainer in the project that stated to me "I have to
> talk to my manager first" before upgrading his "component" that
> rings alarm bells to me, That gives me the feel that they are
> maintaining their components as a part of their job not because they
> want to scratch an itch and want to!

There is a third reason for maintaining a component: it is a dependency
for another component the packager maintains. This is applicable for
_all_ packagers, be they from Red Hat or the community. You either
conveniently omitted this reason to make an argument or never thought of
it, in which case I respectfully ask you to butt out of this thread
because you do not know what you are talking about.

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

Re: Proposed F19 Feature: systemd features

[Jóhann B. Guðmundsson]

On 02/02/2013 02:28 AM, Rahul Sundaram wrote:

Hi


On Fri, Feb 1, 2013 at 9:08 PM, "Jóhann B. Guðmundsson" wrote:


Either RH employees are participating in the project by their own
free will or not. I have personally meet both sides which has
gotten me confused and conflicted.


Employees can have assigned duties as well as projects of their own 
interest.  If you are confused about which one is what and have a need 
to know, feel free to ask them.



When I meet a maintainer in the project that stated to me "I have
to talk to my manager first" before upgrading his "component" that
rings alarm bells to me, That gives me the feel that they are
maintaining their components as a part of their job not because
they want to scratch an itch and want to!


Why is it cause for alarm that some people in Fedora are getting paid 
to do something within Fedora?


>  I dont know about your parts but I grew up in environment where 
slavery is not accepted.


This frequent "I dont know about your parts" sounds quite 
discriminatory and getting paid to do a job is pretty much the 
opposite of slavery.


Rahul


Then Rahul how about a wiki page about all the RH employees that are 
maintaining components in the distribution that have to vs those that 
want to.


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

Re: Proposed F19 Feature: systemd features

[Jóhann B. Guðmundsson]

On 02/02/2013 02:39 AM, Reindl Harald wrote:


Am 02.02.2013 03:08, schrieb Jóhann B. Guðmundsson:

When I meet a maintainer in the project that stated to me "I have to talk to my 
manager first" before upgrading his
"component" that rings alarm bells to me, That gives me the feel that they are 
maintaining their components as a
part of their job not because they want to scratch an itch and want to!

jesus christ be gladful that companies like red hat are
paying people for development of free software and if
someone get paied for a job soemtimes he has to speak
with his managers


It's not like RH gives other company's the alternative to sponsor the 
project now does it



I dont know about your parts but I grew up in environment where slavery is not 
accepted

your definition of "slavery" is completly broken


If an RH employee is maintainer is maintaining a component in the 
distribution and doing so because it's an part of his job but not 
because he want's to I call that slavery especially when he has to go to 
his manager to ask him if he is allowed to "upgrade" the component it to 
it's latest release. Yes first hand I have experienced an RH employee 
that has said I need to speak to my manager before he could upgrade the 
component he was maintaining to the latest release and to me that's 
pretty fucking alarming


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

Re: Proposed F19 Feature: systemd features

[Jóhann B. Guðmundsson]

On 02/02/2013 05:57 AM, Chris Adams wrote:

Once upon a time, "Jóhann B. Guðmundsson"  said:

Feeling happy in the Red Hat position they invented for you in QA.
Feeling a big man now? Challenged accepted big man you have in your rein
of error effectively killed 2 thriving process in the QA community. Do
you really want to head down this road with me? Go ahead big  man make
my day!

Umm, what?  I'll take a stab as a non-Red Hatter: you are WAY off base
here.  Please step away from the mailing list and take some time to cool
off.  You are making baseless attacks against people who I have seen
provide significant value to the Fedora community (no matter their email
address).


Let's venture that road kid



_Nothing_ in Fedora is your private business.  This is a community
project, and all community members can have input.  When someone gives
input on proposals, you CANNOT say "go away, this is not your business"
(especially when that is someone that has put significant hours into
Fedora, whether paid by an employer to do so or not).


When an Red Hat employee that gets away with what ever he pleases within 
the community I say what dam I please.


You might put him in some god like status I don't!

Trust me when I say this people a little higher up the hierarchy has 
tried to convince me he's a good guy but my interaction with him tells a 
whole complexly different story...




If you can't handle that, then Fedora development might not be the right
place for you.

Get the fuck out before you get in my business. If you want to test me 
here I am deal with it because I wont back down not after the treatment 
he has given me!


You have absolutely no idea what I have sacrificed for the project and 
if you want to head down that road son realize I dont bark I bite!


Chris Adams care to explain to me what the fuck you have been doing all 
those years other than trying to play the tough boy?


Let's put your contribution to the test!

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

Re: Proposed F19 Feature: systemd features

[Jóhann B. Guðmundsson]

On 02/02/2013 02:28 AM, Adam Williamson wrote:

On Sat, 2013-02-02 at 01:25 +, "Jóhann B. Guðmundsson" wrote:


Feeling happy in the Red Hat position they invented for you in QA.
Feeling a big man now? Challenged accepted big man you have in your rein
of error effectively killed 2 thriving process in the QA community. Do
you really want to head down this road with me? Go ahead big  man make
my day!

Well, no, not really. We're not having a fight, here. At least, I'm not
trying to. I'm trying to discuss process. You appear to think this is a
battle for domination, but that's not how it looks from where I'm
sitting. I'm sorry if it came up that way, I'm not trying to slap you
down or demean you, I think we've just fallen prey to a bit of process
confusion here.

So, can we back up a bit? I've just read back the whole way through the
two threads, and it turns out to be a bit of a mess. I think the problem
is different people have different perceptions of what's going on.

So in the 01-16 FESCo meeting - right at the end, in open floor - there
was a short conversation about cron job conversion:

18:56:15  on an different subject does it make sense to
migrate all those cron scripts to systemd timer units?
18:56:25  what?
18:56:25  all shipped cron scripts I mean
18:56:40  Viking-Ice: what end-user benefit would all that work
bring?
18:57:10 * nirik has no opinion on it without looking at it in more
detail.
18:57:20  Viking-Ice: as a maintainer, I don't plan to do it,
because I don't see any user improvement
18:57:37  is there any?
18:58:11  lets discuss that proposal after it's had discussion on
list or detailed proposal sent to us?
18:58:22  mitr, fewer packages in install have not looked at
it further it's just recent that systemd gained "calender" support
18:58:40  for those timer units
18:59:31  I'll compile a list of packages that ship cron
jobs and look what benefits it might bring
18:59:42  Viking-Ice: could you mention in your proposal what
it brings to users?
18:59:44  ok thanks

This wasn't widely advertised at the time, it's not mentioned in the
01-16 meeting minutes (no #info or #action lines were given). So anyone
who wasn't at the meeting probably never saw it. The discussion does not
relate to the actual feature that was proposed - as we agree, that does
not cover cron job migration. And so far as I can tell you never brought
any kind of formal proposal to FESCo: there is nothing in the 01-23 or
01-30 logs on this topic, and you have not proposed a feature for it.


No because I was looking into it as I have been trying to state this 
whole time.



There was then the thread "Start of systemd timers after install/update
of a package". You mentioned that you had looked into the migration
possibilities and come to a list of 38 cron jobs in service related
packages.


Yes out of 99


There was a bit of follow-up discussion between you and
Marcela; other principals in the current discussion weren't involved in
the thread at this point (Bill posted to it early, but never *after* you
mentioned your list of 38 packages).


Bill showed up on the systemd channel looking for a glorified solution 
in the form of generators but mmaslano had already at that time shown 
her concerns about potential administrative conflicts as in half in cron 
job half in timer units...

Then we come to this thread, which was related to a specific feature:
https://fedoraproject.org/wiki/Features/SystemdCalendarTimers . The
migration question was brought up early and quite vaguely by Marcela,
not clearly in direct relation to the feature but more as a 'general
concern'. You replied and clarified that the feature doesn't actually
cover the cron job migration, and re-stated that you were working on a
cron job migration proposal.


Yes timer units have been there from more or less the start and they 
just gained calendar support which is totally irrelevant to my research. 
Tim wanted even to put in on our ( QA ) meeting logs that he showed 
concerned over this failing to understand that all that has happened is 
that you can specificy calendar days dates in timer units which he then 
retracted from the meeting logs once I had explained it to him that, 
that feature had nothing to do with anykind of migration.




Then we fast-forward a week or so, and Bill replied to Marcela and
provided his own proposal for how to decide what cron jobs to migrate.

Now at this point I can kinda see how to you it looked like Bill was
'butting in on' your work, as now I've gone and done the thread
archaeology and dragged up three week old FESCo logs from the archives,
I can see that this has been kind of an 'ongoing thing' for you. But it
doesn't quite have that visibility for anyone else - the FESCo
discussion wasn't in the minutes and there's no public draft proposal,
and the references in the "Start of systemd timers after install/update
of a package" thread are somewhat vague and it's not clear Bill even saw
them. Bill was present for the o

Re: Proposed F19 Feature: systemd features

[Chris Adams]

Once upon a time, "Jóhann B. Guðmundsson"  said:
> Feeling happy in the Red Hat position they invented for you in QA. 
> Feeling a big man now? Challenged accepted big man you have in your rein 
> of error effectively killed 2 thriving process in the QA community. Do 
> you really want to head down this road with me? Go ahead big  man make 
> my day!

Umm, what?  I'll take a stab as a non-Red Hatter: you are WAY off base
here.  Please step away from the mailing list and take some time to cool
off.  You are making baseless attacks against people who I have seen
provide significant value to the Fedora community (no matter their email
address).

_Nothing_ in Fedora is your private business.  This is a community
project, and all community members can have input.  When someone gives
input on proposals, you CANNOT say "go away, this is not your business"
(especially when that is someone that has put significant hours into
Fedora, whether paid by an employer to do so or not).

If you can't handle that, then Fedora development might not be the right
place for you.

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

Re: Proposed F19 Feature: systemd features

[Adam Williamson]

On Sat, 2013-02-02 at 01:25 +, "Jóhann B. Guðmundsson" wrote:

> Feeling happy in the Red Hat position they invented for you in QA. 
> Feeling a big man now? Challenged accepted big man you have in your rein 
> of error effectively killed 2 thriving process in the QA community. Do 
> you really want to head down this road with me? Go ahead big  man make 
> my day!

Well, no, not really. We're not having a fight, here. At least, I'm not
trying to. I'm trying to discuss process. You appear to think this is a
battle for domination, but that's not how it looks from where I'm
sitting. I'm sorry if it came up that way, I'm not trying to slap you
down or demean you, I think we've just fallen prey to a bit of process
confusion here.

So, can we back up a bit? I've just read back the whole way through the
two threads, and it turns out to be a bit of a mess. I think the problem
is different people have different perceptions of what's going on.

So in the 01-16 FESCo meeting - right at the end, in open floor - there
was a short conversation about cron job conversion:

18:56:15  on an different subject does it make sense to
migrate all those cron scripts to systemd timer units?
18:56:25  what?
18:56:25  all shipped cron scripts I mean
18:56:40  Viking-Ice: what end-user benefit would all that work
bring?
18:57:10 * nirik has no opinion on it without looking at it in more
detail.
18:57:20  Viking-Ice: as a maintainer, I don't plan to do it,
because I don't see any user improvement
18:57:37  is there any?
18:58:11  lets discuss that proposal after it's had discussion on
list or detailed proposal sent to us?
18:58:22  mitr, fewer packages in install have not looked at
it further it's just recent that systemd gained "calender" support
18:58:40  for those timer units
18:59:31  I'll compile a list of packages that ship cron
jobs and look what benefits it might bring
18:59:42  Viking-Ice: could you mention in your proposal what
it brings to users?
18:59:44  ok thanks

This wasn't widely advertised at the time, it's not mentioned in the
01-16 meeting minutes (no #info or #action lines were given). So anyone
who wasn't at the meeting probably never saw it. The discussion does not
relate to the actual feature that was proposed - as we agree, that does
not cover cron job migration. And so far as I can tell you never brought
any kind of formal proposal to FESCo: there is nothing in the 01-23 or
01-30 logs on this topic, and you have not proposed a feature for it.

There was then the thread "Start of systemd timers after install/update
of a package". You mentioned that you had looked into the migration
possibilities and come to a list of 38 cron jobs in service related
packages. There was a bit of follow-up discussion between you and
Marcela; other principals in the current discussion weren't involved in
the thread at this point (Bill posted to it early, but never *after* you
mentioned your list of 38 packages).

Then we come to this thread, which was related to a specific feature:
https://fedoraproject.org/wiki/Features/SystemdCalendarTimers . The
migration question was brought up early and quite vaguely by Marcela,
not clearly in direct relation to the feature but more as a 'general
concern'. You replied and clarified that the feature doesn't actually
cover the cron job migration, and re-stated that you were working on a
cron job migration proposal.

Then we fast-forward a week or so, and Bill replied to Marcela and
provided his own proposal for how to decide what cron jobs to migrate.

Now at this point I can kinda see how to you it looked like Bill was
'butting in on' your work, as now I've gone and done the thread
archaeology and dragged up three week old FESCo logs from the archives,
I can see that this has been kind of an 'ongoing thing' for you. But it
doesn't quite have that visibility for anyone else - the FESCo
discussion wasn't in the minutes and there's no public draft proposal,
and the references in the "Start of systemd timers after install/update
of a package" thread are somewhat vague and it's not clear Bill even saw
them. Bill was present for the open floor section of the 01-16 meeting
(I just checked my personal logs, as the public ones don't show
joins/parts), but he didn't say anything - he may not really have
followed the conversation. So Bill may not actually have been fully
aware this was something you were working on.

This was where the thread started going seriously downhill - in response
to three different people you stated more and more strongly that you
were working on the cron job migration thing and Bill was 'butting in'.
Again, I can see how it looked like that to you, but I think to the
others it didn't - I'm guessing the others, like me, hadn't seen all the
previous stuff. It looked more like Bill suggested a proposal and you
were claiming more or less by fiat that this was your area and he should
butt out, and that's what got people's backs up.

So now I've dug through the background I can s

Re: Proposed F19 Feature: systemd features

[Rahul Sundaram]

Hi


On Fri, Feb 1, 2013 at 9:08 PM, "Jóhann B. Guðmundsson" wrote:


> Either RH employees are participating in the project by their own free
> will or not. I have personally meet both sides which has gotten me confused
> and conflicted.
>

Employees can have assigned duties as well as projects of their own
interest.  If you are confused about which one is what and have a need to
know, feel free to ask them.

>
> When I meet a maintainer in the project that stated to me "I have to talk
> to my manager first" before upgrading his "component" that rings alarm
> bells to me, That gives me the feel that they are maintaining their
> components as a part of their job not because they want to scratch an itch
> and want to!
>

Why is it cause for alarm that some people in Fedora are getting paid to do
something within Fedora?

>  I dont know about your parts but I grew up in environment where slavery
is not accepted.

This frequent "I dont know about your parts" sounds quite discriminatory
and getting paid to do a job is pretty much the opposite of slavery.

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

Re: Proposed F19 Feature: systemd features

[Jóhann B. Guðmundsson]

On 02/02/2013 01:57 AM, Rahul Sundaram wrote:

Hi


On Fri, Feb 1, 2013 at 7:52 PM, "Jóhann B. Guðmundsson" 
mailto:johan...@gmail.com>> wrote:



I know few RH employees who would beg the differ, many of which go
above and beyond their "corporate" duties but I'll remember your
remarks.

It's good to know there exist that corporate line...


You don't seem to have understood what I said.  If a Red Hat employee 
has Fedora activities as part of their job, then it is not unexpected 
that feedback about those activities might reach their manager.  They 
might very well have other interests in Fedora which aren't part of 
their Red Hat role and in that case, it is fine to ask people to 
direct feedback only to them as an individual.


You cant have it both ways.

Either RH employees are participating in the project by their own free 
will or not. I have personally meet both sides which has gotten me 
confused and conflicted.


When I meet a maintainer in the project that stated to me "I have to 
talk to my manager first" before upgrading his "component" that rings 
alarm bells to me, That gives me the feel that they are maintaining 
their components as a part of their job not because they want to scratch 
an itch and want to!


I dont know about your parts but I grew up in environment where slavery 
is not accepted.


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

Re: Proposed F19 Feature: systemd features

[Rahul Sundaram]

Hi


On Fri, Feb 1, 2013 at 7:52 PM, "Jóhann B. Guðmundsson"
wrote:

>
> I know few RH employees who would beg the differ, many of which go above
> and beyond their "corporate" duties but I'll remember your remarks.
>
> It's good to know there exist that corporate line...
>

You don't seem to have understood what I said.  If a Red Hat employee has
Fedora activities as part of their job, then it is not unexpected that
feedback about those activities might reach their manager.  They might very
well have other interests in Fedora which aren't part of their Red Hat role
and in that case, it is fine to ask people to direct feedback only to them
as an individual.

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

Re: Proposed F19 Feature: systemd features

[Matthew Miller]

On Fri, Feb 01, 2013 at 04:36:20PM -0500, Bill Nottingham wrote:
> 3) introduce compatibility
> The cron and at interfaces aren't complex at all. It shouldn't be
> too hard to have a generator that reads crontab and cron.*, and
> the at queue, and creates the approprate timer files for systemd,
> in the same way that the fstab & sysv generators run. We could
> even have new versions of the crontab and at commands that do the
> right thing.

I heart this approach.


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

Re: Proposed F19 Feature: systemd features

[Bruno Wolff III]

On Sat, Feb 02, 2013 at 01:25:09 +,
  "\"Jóhann B. Guðmundsson\""  wrote:


community. Do you really want to head down this road with me? Go 
ahead big  man make my day!


This is not appropriate behavior for a Fedora contributor.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: systemd features

[Jóhann B. Guðmundsson]

On 02/02/2013 01:16 AM, Adam Williamson wrote:

On Fri, 2013-02-01 at 19:38 +, "Jóhann B. Guðmundsson" wrote:

On 02/01/2013 05:16 PM, Adam Williamson wrote:

On Fri, 2013-02-01 at 08:44 +, "Jóhann B. Guðmundsson" wrote:

On 02/01/2013 04:21 AM, David Tardon wrote:

On Thu, Jan 31, 2013 at 11:46:33PM +, "Jóhann B. Guðmundsson" wrote:

And in the midst of me doing this research I have to have Bill
Notting butting into my work ( and I know what that means ), trying
to come up with his own list instead of simply asking me for the one
I was looking at [¹] and consulting with me where I was with my
findings and now he can just have at it and finish do it his own
way., create those units and prep the necessary patches to the
packages etc. since he's such an expert on the matter.

If you stop behaving like a child, maybe people will start to take you
seriously.

And Bills behavior towards me has been so civilized through out the years.

If he leaves me and my work alone and general stays away from me maybe I
will...

Well, no, that's not going to happen. Fedora's a collaborative project.
If you're making significant changes to core packages - which you would
be, if you start porting things from crond to systemd timers - other
people who work on the core system are going to take an interest. Like
Bill. That's kind of how things work around here. You don't just get to
stake off some territory and say MINE MINE MINE NO-ONE COMES IN HERE.

Oh and you where so collaborate Adam when you decided on your own
deleting my tickets in the QA trac instance that A) exist because of me
and B) I was using to keep track on my work within the QA community. It
did not cross for a second for you to send me a line or ping me on irc
and ask me if it was ok.

I didn't 'delete' anything. I *closed* some tickets that had seen no
activity for two years and ten months, as part of a general effort to
keep trac focused on current and active tasks. The tickets are still
there and you could re-open them if you choose. This is roughly
analogous to the EOL bugzilla closures we do with each release. When you
contacted me about this I did not tell you to butt out and leave my area
of expertise alone, we had a discussion about it. Collaboratively.


And you dare talking to me about mine mine when I want one man, one man
out of thousand of contributors to leave me alone and stay out of my
business!

There it is again: "my business". I'm not sure how you consider this
"your business". This feature page:

https://fedoraproject.org/wiki/Features/SystemdCalendarTimers

lists Lennart as the feature owner. It does not list you anywhere. It
does not in any way cover the question of how many, if any, cron jobs we
should convert into systemd timer units: this is clearly beyond the
feature's scope. There is no otherfeature that *does* cover that work,
so far as I am aware. You are not the owner of the systemd package. You
are not the owner of the cronie package. You are not the owner of any of
the packages that would be candidates for conversion. So how exactly is
the conversion to timer units "your business"? Your claim doesn't appear
to be staked in any way anyone else can see.


Feeling happy in the Red Hat position they invented for you in QA. 
Feeling a big man now? Challenged accepted big man you have in your rein 
of error effectively killed 2 thriving process in the QA community. Do 
you really want to head down this road with me? Go ahead big  man make 
my day!


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

Re: Proposed F19 Feature: Virtio RNG

[Matthew Garrett]

On Fri, Feb 01, 2013 at 08:17:26PM -0500, Paul Wouters wrote:

> The guests can always run their own rngd type tool?

Yeah, this just makes host randomness available to the guest - it 
doesn't directly feed it to /dev/random. The guest still gets to define 
its own policy.

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

Re: Proposed F19 Feature: Virtio RNG

[Miloslav Trmač]

On Sat, Feb 2, 2013 at 2:19 AM, Paul Wouters  wrote:
> On Fri, 1 Feb 2013, Matthew Garrett wrote:
>
>> other than providing other sources of entropy, and long-term this is
>> going to be fixed once everyone's moved to Ivy Bridge and has an
>> unprivileged instruction to hand out entropy.
>
> uhm I know intel really wants us to use it directly and trust them, but
> we're going to run it through the kernel right? And just expose it via
> /dev/random to userland yes?
... and applications will call the best-matching RNG function from a
reputable crypto library instead of reading /dev/anything or using an
architecture-specific instruction directly, hopefully.

(That said, if you don't trust Intel to implement rdrand properly, do
you trust them not to specially recognize and "mis-execute" code
implementing the kernel /dev/random entropy pool update or other
similarly critical code?  There is even that handy microcode update
mechanism that allows a hypothetical malicious Intel to adapt to
kernel code changes.)
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Virtio RNG

[Matthew Garrett]

On Fri, Feb 01, 2013 at 08:19:30PM -0500, Paul Wouters wrote:
> On Fri, 1 Feb 2013, Matthew Garrett wrote:
> 
> >other than providing other sources of entropy, and long-term this is
> >going to be fixed once everyone's moved to Ivy Bridge and has an
> >unprivileged instruction to hand out entropy.
> 
> uhm I know intel really wants us to use it directly and trust them, but
> we're going to run it through the kernel right? And just expose it via
> /dev/random to userland yes?

rngd calls rdrand and seeds /dev/random with it. The kernel doesn't use 
rdrand directly, but does have some setup code to ensure that it's 
reseeded before userspace starts.

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

Re: Proposed F19 Feature: Virtio RNG

[Paul Wouters]

On Fri, 1 Feb 2013, Matthew Garrett wrote:


other than providing other sources of entropy, and long-term this is
going to be fixed once everyone's moved to Ivy Bridge and has an
unprivileged instruction to hand out entropy.


uhm I know intel really wants us to use it directly and trust them, but
we're going to run it through the kernel right? And just expose it via
/dev/random to userland yes?

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

Re: Proposed F19 Feature: Virtio RNG

[Paul Wouters]

On Fri, 1 Feb 2013, Bill Nottingham wrote:


VirtIO RNG (random number generator) is a paravirtualized device that is
exposed as a hardware RNG device to the guest. Virtio RNG just appears as a
regular hardware RNG to the guest, which the kernel reads from to fill its
entropy pool. This effectively allows a host to inject entropy into a guest via
several means: The default mode uses the host's /dev/random, but a physical HW
RNG device or EGD (Entropy Gathering Daemon) source can also be used.


What exactly feeds /dev/random in the guest in the cases where this doesn't
exist, and how do we cope with this obviously making /dev/random exhaustion
in the host much more likely? (Other than assume that a HW RNG is in the
host.)

Given FIPS paranoia about RNG sources, does this have knock-on effects in
the FIPS compliance of guests depending on how it's fed in the host?


The guests can always run their own rngd type tool?

I've been promised random in guests since xen2 days. It would be good if
we actually managed to get it.

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

Re: Proposed F19 Feature: systemd features

[Adam Williamson]

On Fri, 2013-02-01 at 19:38 +, "Jóhann B. Guðmundsson" wrote:
> On 02/01/2013 05:16 PM, Adam Williamson wrote:
> > On Fri, 2013-02-01 at 08:44 +, "Jóhann B. Guðmundsson" wrote:
> >> On 02/01/2013 04:21 AM, David Tardon wrote:
> >>> On Thu, Jan 31, 2013 at 11:46:33PM +, "Jóhann B. Guðmundsson" wrote:
>  And in the midst of me doing this research I have to have Bill
>  Notting butting into my work ( and I know what that means ), trying
>  to come up with his own list instead of simply asking me for the one
>  I was looking at [¹] and consulting with me where I was with my
>  findings and now he can just have at it and finish do it his own
>  way., create those units and prep the necessary patches to the
>  packages etc. since he's such an expert on the matter.
> >>> If you stop behaving like a child, maybe people will start to take you
> >>> seriously.
> >> And Bills behavior towards me has been so civilized through out the years.
> >>
> >> If he leaves me and my work alone and general stays away from me maybe I
> >> will...
> > Well, no, that's not going to happen. Fedora's a collaborative project.
> > If you're making significant changes to core packages - which you would
> > be, if you start porting things from crond to systemd timers - other
> > people who work on the core system are going to take an interest. Like
> > Bill. That's kind of how things work around here. You don't just get to
> > stake off some territory and say MINE MINE MINE NO-ONE COMES IN HERE.
> 
> Oh and you where so collaborate Adam when you decided on your own 
> deleting my tickets in the QA trac instance that A) exist because of me 
> and B) I was using to keep track on my work within the QA community. It 
> did not cross for a second for you to send me a line or ping me on irc 
> and ask me if it was ok.

I didn't 'delete' anything. I *closed* some tickets that had seen no
activity for two years and ten months, as part of a general effort to
keep trac focused on current and active tasks. The tickets are still
there and you could re-open them if you choose. This is roughly
analogous to the EOL bugzilla closures we do with each release. When you
contacted me about this I did not tell you to butt out and leave my area
of expertise alone, we had a discussion about it. Collaboratively.

> And you dare talking to me about mine mine when I want one man, one man 
> out of thousand of contributors to leave me alone and stay out of my 
> business!

There it is again: "my business". I'm not sure how you consider this
"your business". This feature page:

https://fedoraproject.org/wiki/Features/SystemdCalendarTimers

lists Lennart as the feature owner. It does not list you anywhere. It
does not in any way cover the question of how many, if any, cron jobs we
should convert into systemd timer units: this is clearly beyond the
feature's scope. There is no otherfeature that *does* cover that work,
so far as I am aware. You are not the owner of the systemd package. You
are not the owner of the cronie package. You are not the owner of any of
the packages that would be candidates for conversion. So how exactly is
the conversion to timer units "your business"? Your claim doesn't appear
to be staked in any way anyone else can see.
-- 
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: Proposed F19 Feature: systemd features

[Jóhann B. Guðmundsson]

On 02/01/2013 11:14 PM, Stephen John Smoogen wrote:

On 1 February 2013 15:57, Miloslav Trmač  wrote:

On Fri, Feb 1, 2013 at 10:36 PM, Bill Nottingham  wrote:

In any case, to look at 'we have this functionality... now what':

For the sake of completeness, the default is 0) Avoid all the
arguments and work, and continue using existing files.

Is there actually a noticeable benefit in migrating?  We will help
Linux win neither on the desktop nor in the cloud by tinkering with
something admins are not supposed to touch :)

So far I can see:
A. Disk space usage in minimal systems has been mentioned: but cronie
is 200 kB, that's almost a waste of breath.
B. Cron's facility to submit jobs by unprivileged users to a daemon
running as root is a possible privilege escalation path; removing it
from the minimal (or even default) installation would remove a
possible risk (as long as we don't introduce an equivalent one as a
replacement.)
C. If we remove cron, is there anything left that needs the local MTA?
  Removing the local MTA would be similar to removing cron, only more
so.

I expect that in that case, systemd would expand until it became an
MTA .. whether or not the main developers wanted it to :).

Every program attempts to expand until it can send mail. Those
programs which cannot so expand are replaced by ones which can.

[misquoted from Zawinski]


When it does every current traditional "monitoring" system become 
obsolete but the resistance to venture into the inevitable exist upstream..


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

Re: Proposed F19 Feature: systemd features

[Jóhann B. Guðmundsson]

On 02/01/2013 08:32 PM, Rahul Sundaram wrote:

Hi

On Fri, Feb 1, 2013 at 3:23 PM, "Jóhann B. Guðmundsson"


You can go yourself through the community working log meetings to
find my reference.

I would expect RH employee ( and other corporation's employee )
sitting at the same table as their community brethren's and not
having to worries about their job for their actions within the
community.


If their work in the community is part of their job, then we cannot 
really separate the two.


I know few RH employees who would beg the differ, many of which go above 
and beyond their "corporate" duties but I'll remember your remarks.


It's good to know there exist that corporate line...

JBG




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

Re: Proposed F19 Feature: Virtio RNG

[Miloslav Trmač]

On Fri, Feb 1, 2013 at 10:39 PM, Bill Nottingham  wrote:
> Given FIPS paranoia about RNG sources, does this have knock-on effects in
> the FIPS compliance of guests depending on how it's fed in the host?

(Hoping for an answer from someone who has actually fully analyzed the
FIPS RNG situation and requirements; in the meantime...)

FIPS generally prefers using a deterministic RNG, seeded only once,
with a fairly small amount of entropy (64-512 bits, much smaller than
the 4k we usually think of as the "/dev/random entropy pool"); so this
would imply asking the host for that small amount of "strong" entropy
on boot, using it to seed with (some of?) it the kernel RNGs, and then
seeding user-space from the kernel RNGs without asking the host for
more entropy.

I think that even in FIPS mode /dev/urandom continues to operate more
or less unmodified (and would thus probably continuously seed from the
host), but that needs confirming by someone with actual knowledge.
   Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Virtio RNG

[Stephen John Smoogen]

On 1 February 2013 16:40, Matthew Garrett  wrote:
> On Fri, Feb 01, 2013 at 04:39:17PM -0500, Bill Nottingham wrote:

>> Given FIPS paranoia about RNG sources, does this have knock-on effects in
>> the FIPS compliance of guests depending on how it's fed in the host?
>
> I'm not convinced that you could currently claim with a straight face
> that guests meet any sort of FIPS standard for random numbers.

As far as I know they do not. Guests that require FIPS, PCI etc
require still some sort of guest -> hardware tool to get random
numbers to it. The ones I consulted on a while back had to have a usb
device passed through to get a "good enough" checkoff by the auditor.


-- 
Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me."  —James Stewart as Elwood P. Dowd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Virtio RNG

[Matthew Garrett]

On Fri, Feb 01, 2013 at 04:39:17PM -0500, Bill Nottingham wrote:

> What exactly feeds /dev/random in the guest in the cases where this doesn't
> exist, and how do we cope with this obviously making /dev/random exhaustion
> in the host much more likely? (Other than assume that a HW RNG is in the
> host.)

At the moment the guest gets its entropy in the same way that bare metal 
would - various interrupts are picked up and fed into the entropy pool. 
The problem there is that (a) there's typically far fewer of these 
events on a guest, and (b) how much do you really trust those timings to 
be random when you're at the whims of an external process scheduler. So, 
right now, you have very little entropy in the guest and what entropy 
you do have may not be worth a great deal. In a lot of cases, 
/dev/urandom is probably running off the original seed value that 
happened to be sitting in your image file. The same one that's probably 
running in a bunch of other guests.

This patchset means that there's a /dev/hwrng available in the guest, so 
you still need to run something like rngd to mix that into the kernel's 
entropy pool. You're right that the total amount of entropy is still 
limited to that available on the host, and it does make host-side 
exhaustion more likely. There's not a lot that can be done about that 
other than providing other sources of entropy, and long-term this is 
going to be fixed once everyone's moved to Ivy Bridge and has an 
unprivileged instruction to hand out entropy.

> Given FIPS paranoia about RNG sources, does this have knock-on effects in
> the FIPS compliance of guests depending on how it's fed in the host?

I'm not convinced that you could currently claim with a straight face 
that guests meet any sort of FIPS standard for random numbers.

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

Re: Proposed F19 Feature: Virtio RNG

[Bill Nottingham]

Jaroslav Reznik (jrez...@redhat.com) said: 
> Feature owner(s): Cole Robinson , Amit Shah 
> 
> 
> Provide a paravirtual random number generator to virtual machines, to prevent 
> entropy starvation in guests.  
> 
> == Detailed description ==
> The linux kernel collects entropy from various non-deterministic hardware 
> events, like mouse and keyboard input, and network traffic. This entropy is 
> then 
> exposed through /dev/random, commonly used by cryptographic applications that 
> need true randomness to maintain security. However if more entropy is being 
> consumed than is being produced, we have entropy starvation: reading from 
> /dev/random will block, which can cause a denial of service. A common example 
> here is use of /dev/random by SSL in various services.
> 
> VirtIO RNG (random number generator) is a paravirtualized device that is 
> exposed as a hardware RNG device to the guest. Virtio RNG just appears as a 
> regular hardware RNG to the guest, which the kernel reads from to fill its 
> entropy pool. This effectively allows a host to inject entropy into a guest 
> via 
> several means: The default mode uses the host's /dev/random, but a physical 
> HW 
> RNG device or EGD (Entropy Gathering Daemon) source can also be used. 

What exactly feeds /dev/random in the guest in the cases where this doesn't
exist, and how do we cope with this obviously making /dev/random exhaustion
in the host much more likely? (Other than assume that a HW RNG is in the
host.)

Given FIPS paranoia about RNG sources, does this have knock-on effects in
the FIPS compliance of guests depending on how it's fed in the host?

Bill

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

Re: Proposed F19 Feature: systemd features

[Stephen John Smoogen]

On 1 February 2013 15:57, Miloslav Trmač  wrote:
> On Fri, Feb 1, 2013 at 10:36 PM, Bill Nottingham  wrote:
>> In any case, to look at 'we have this functionality... now what':
>
> For the sake of completeness, the default is 0) Avoid all the
> arguments and work, and continue using existing files.
>
> Is there actually a noticeable benefit in migrating?  We will help
> Linux win neither on the desktop nor in the cloud by tinkering with
> something admins are not supposed to touch :)
>
> So far I can see:
> A. Disk space usage in minimal systems has been mentioned: but cronie
> is 200 kB, that's almost a waste of breath.
> B. Cron's facility to submit jobs by unprivileged users to a daemon
> running as root is a possible privilege escalation path; removing it
> from the minimal (or even default) installation would remove a
> possible risk (as long as we don't introduce an equivalent one as a
> replacement.)
> C. If we remove cron, is there anything left that needs the local MTA?
>  Removing the local MTA would be similar to removing cron, only more
> so.

I expect that in that case, systemd would expand until it became an
MTA .. whether or not the main developers wanted it to :).

Every program attempts to expand until it can send mail. Those
programs which cannot so expand are replaced by ones which can.

[misquoted from Zawinski]

-- 
Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me."  —James Stewart as Elwood P. Dowd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: systemd features

[Miloslav Trmač]

On Fri, Feb 1, 2013 at 10:36 PM, Bill Nottingham  wrote:
> In any case, to look at 'we have this functionality... now what':

For the sake of completeness, the default is 0) Avoid all the
arguments and work, and continue using existing files.

Is there actually a noticeable benefit in migrating?  We will help
Linux win neither on the desktop nor in the cloud by tinkering with
something admins are not supposed to touch :)

So far I can see:
A. Disk space usage in minimal systems has been mentioned: but cronie
is 200 kB, that's almost a waste of breath.
B. Cron's facility to submit jobs by unprivileged users to a daemon
running as root is a possible privilege escalation path; removing it
from the minimal (or even default) installation would remove a
possible risk (as long as we don't introduce an equivalent one as a
replacement.)
C. If we remove cron, is there anything left that needs the local MTA?
 Removing the local MTA would be similar to removing cron, only more
so.


B. and C. would be somewhat interesting - if and only if we did the
next step of making cron/MTA optional and not installed by default.
Is that reasonable and feasible?


> 3) introduce compatibility
>
> The cron and at interfaces aren't complex at all. It shouldn't be
> too hard to have a generator that reads crontab and cron.*, and
> the at queue, and creates the approprate timer files for systemd,
> in the same way that the fstab & sysv generators run. We could
> even have new versions of the crontab and at commands that do the
> right thing.
>
> That's extra work that would need to be done, and we would
> have to actually be obsoleting cron here (can't have two things
> running the same jobs),

Technically it's not necessary to obsolete cron as a tool/daemon (and
reimplement all of the functionality); systemd could be handling
/etc/cron.{hourly,daily,monthly,weekly}, leaving the full syntax of
/etc/{ana,}crontab and per-user task lists edited via crontab(1)
(including root's, which is distinct from /etc/crontab) to cronie.
Unfortunately there is an ugly half-way case: /etc/cron.d.

I'd be very hesitant about moving per-user jobs to systemd - for
security reasons the mechanism to accept user's job submission really
needs to be distinct from PID 1, so structurally it can't end up that
different from simply including cronie into systemd; an independent
cronie reimplementation would just be asking for privilege
escalations, with zero user benefit.
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: libcacard can never be installed

[Paolo Bonzini]

Il 29/01/2013 10:03, Richard W.M. Jones ha scritto:
> On Tue, Jan 29, 2013 at 08:57:11AM +, Peter Robinson wrote:
>> On Tue, Jan 29, 2013 at 8:52 AM, Richard W.M. Jones  
>> wrote:
>>> I have a filed a bug about this:
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=905345
>>> "libcacard can never be installed"
>>
>> Is there a reason that qemu ships a bundled version of libcacard?
>> What's the difference between the two of them? Can qemu use the
>> unbundled version or are they essentially two completely different
>> libraries with the same name?
> 
> It looks as if the qemu source contains the one canonical copy of
> libcacard.  The separate 'libcacard' package has the following sources
> file:
> 
> $ cat sources 
> 189bc5b87281a72f8c72a0f7ebaa6d00  qemu-1.2.1.tar.bz2

Yes, I noticed this a month ago and suggested that Alon would merge the
packages and orphan libcacard.  He forgot to do the second step
apparently. :)

Paolo

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

[Peter Jones]

On Tue, Jan 29, 2013 at 04:25:05AM -0800, Dan Mashal wrote:
> I'm sure QA, releng, docs, etc will go with what the community decides.
> 
> Lets have a poll. A very public one.
> 
> On the main website. Not somebody's blog. And let's let the users decide
> what they want.

Do we have any significant data that even a plurality of our *users* visit
our main website on a regular - or any - basis?

I have my doubts that all that many do, much less that we've got data that
tells us that such a poll would result in meaningful data.

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

Re: Proposed F19 Feature: systemd features

[Bill Nottingham]

"Jóhann B. Guðmundsson" (johan...@gmail.com) said: 
> On 01/31/2013 03:51 PM, Bill Nottingham wrote:
> >I would be tempted to say:
> >   "Anything running at a core system level where a dependence on a separate
> >cron daemon may be unwanted (or a bad idea) should be migrated, and nothing
> >else for now until we have a clearer perspective on the future."
> >
> >Given that list that would be migration of:
> >mcelog
> >mdadm
> >ovirt-node
> >prelink (?)
> >tmpwatch
> >vdsm-*
> >
> >But I'm open to other ideas.
> 
> Am I supposed to assume you are working migrating this?

I was asked people to take a look at what the functionality can do, what
it may mean to migrate, and what we want to offer to our users, in the
short and in the long term.

The thing about migrating SysV services is that we didn't have to at
the start, and yet they'd still work, in systemd, without change.
(For the most part).

And admins could use the old tools adminms were used to in SysV land
(/sbin/service, chkconfig, etc) with systemd, and they'd work and
give them consistent output for both the native services, and the ones
they hadn't got around to migrating yet.

Here, while systemd has basically subsumed the functionality of
cron (minus user jobs), it hasn't subsumed any of the infrastructure -
there's no compat.

In any case, to look at 'we have this functionality... now what':

1) migrate some cron jobs

Then, system scheduled tasks are in two places. Admins can learn and
cope, and have to go looking in multiple places and remember which tools
to deal with which scheduled task type. It's not ideal. And if we do
so, it's good to have some clear criteria to help admins decide where
to find what they're looking for. You started working here - you
suggested 'ones that come with daemons/services', I looked, and
thought perhaps 'ones that live at a level below
everything else, including the ones below daemons and services'. It's
just different ideas as to where to draw the line.

But it's still not a great interface to have users end up in - two
infrastructures running in parallel.

2) migrate all

This is cleaner, inasmuch as we can tell everyone "hey, everything
is over here now". But it's still a full break of interfaces and
paradigms, and it easily devolves to #1 as soon as something doesn't
get done, or new stuff is added. (After all, we can't remove support
for cron-format jobs.)

3) introduce compatibility

The cron and at interfaces aren't complex at all. It shouldn't be
too hard to have a generator that reads crontab and cron.*, and
the at queue, and creates the approprate timer files for systemd,
in the same way that the fstab & sysv generators run. We could
even have new versions of the crontab and at commands that do the
right thing.

That's extra work that would need to be done, and we would
have to actually be obsoleting cron here (can't have two things
running the same jobs), so it's obviously not F19 material. We'd
also need a mechanism for user jobs. But if this is where we want
the system to end up, this is what we start working towards and
writing code for. Once that lands, transitioning can actually be
done much more smoothyl with less user disruption, and having
different jobs in different formats doesn't hurt nearly as much.

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

Re: Proposed F19 Feature: High Availability Container Resources

[David Vossel]

- Original Message -
> From: "Daniel J Walsh" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Friday, February 1, 2013 10:09:27 AM
> Subject: Re: Proposed F19 Feature: High Availability Container Resources
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 01/29/2013 03:17 PM, Glauber Costa wrote:
>  = Features/ High Availability Container Resources =
>  https://fedoraproject.org/wiki/Features/High_Availability_Container_Resources
> 
> 
>  
> Feature owner(s): David Vossel 
>  
>  The Container Resources feature allows the HA stack (Pacemaker +
>  Corosync) residing on a host machine to extend management of
>  resources into virtual guest instances (KVM/LXC).
> >>> 
> >>> Is this about LXC or libvirt-lxc? These two are entirely
> >>> different
> >>> projects, sharing no code, which makes me wonder which project is
> >>> meant here?
> >> 
> >> Yep, I left that vague and should have used the term "linux
> >> containers"
> >> instead of LXC.  I'm going to update the page to reflect this.
> >> 
> >> This feature architecturally doesn't care which project
> >> manages/initiates
> >> the container.  All we care about is that the container has it's
> >> own
> >> isolated network namespace that is reachable from the host (or
> >> whatever
> >> node is remotely managing the resources within the container)  I
> >> intentionally chose to use tcp/tls as the first transport we will
> >> support
> >> to avoid locking this feature into use with any specific virt
> >> technology.
> >> 
> >> With that said, I'm likely going to be focusing my test cases on
> >> libvirt-lxc just because it seems like it has better fedora
> >> support.  The
> >> LXC project appears to be moving all over the place.  Part of the
> >> project
> >> is really to identify good use-cases for linux containers in an HA
> >> environment.  The kvm use-case is fairly straight forward and well
> >> understood though.  I'll update the page to list the linux
> >> container
> >> use-case as a possible risk.
> > 
> > Please also keep in mind that LXC usually refers to a specific
> > project,
> > either the original "lxc" code or "libvirt-lxc". We have either
> > Container
> > Solutions in Fedora, like OpenVZ.
> > 
> > You may be able to reach a broader base by making your solution
> > work on
> > that too (and of course, I'd be more than happy to help to trim any
> > issues
> > you may find)
> > 
> > -- E Mare, Libertas
> > 
> I would like to also understand how we can work together with
> virt-sandbox.
> (Secure Linux Containers)

Really interesting idea.

Integrating with virt-sandbox would allow the cluster to dynamically launch 
resources in a contained environment.

My understand is that this contained environment would give users the ability 
to automatically set cpu and memory usage limits for a resource as well as 
isolate that resource's access to the rest of system.  Everywhere that resource 
gets launched in the cluster, it gets the exact same environment.

For the HA config we could do this in a really slick way.  We could just allow 
people to start defining environment details (number cpus, memory usage, 
network settings) in the resource definition.  Then when it's time to launch 
the resource, if we have certain environment details associated with the 
resource, we'll just launch the resource in a dynamically created guest sandbox 
environment instead of directly within the host.  This is really brilliant... 
Conceptually this is like we are creating a virtual machine image on the fly 
for a resource to start in that follows the resource wherever it goes in the 
cluster.

This would be fun to talk through sometime.  The remote LRMD daemon I'm working 
on would be the piece of the puzzle that allows the HA stack to reach into 
contained environment to start/stop/monitor the resource living in the 
container. 

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

Re: Proposed F19 Feature: System Configuration Shell

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/31/2013 02:08 PM, Jaroslav Reznik wrote:
> = Features/SystemConfigurationShell = 
> https://fedoraproject.org/wiki/Features/SystemConfigurationShell
> 
> Feature owner(s): Tom Schwaller 
> 
> The System Configuration Shell System provides an easy to use
> interactive command line interface with a standardized syntax to
> manage your system.
> 
> == Detailed description == Network Administrators love their very
> powerful switch/router/firewall/etc. CLI which can be used for all
> administrative tasks in a very structured and well documented way.
> Compare that to classical Linux System Administration which is a
> mix of editing configuration files using different formats and
> executing commands & scripts with a heterogeneous syntax. The
> System Configuration Shell will provide an interactive command line
> interface using the python-configshell framework with a
> standardized syntax to manage your system. It consists of the 
> command configsh which starts an interactive shell and can also be
> used in shell scripts and the command config for one-shot
> configuration commands (e.g. config hostname www.fedoraproject.org
> which not only executes hostname www.fedoraproject.org but also
> changes several configuration files to make the new hostname
> permanent).
> 
> The System Configuration Shell will facilitate the Linux System
> administrators daily work. Since every command is logged (in a
> verbose mode even showing the exact system commands and scripts
> executed), each administrator can decide him/herself if he/she
> feels comfortable using standard parts (or local extensions) the
> System Configuration Shell. The approach is similar to the OpenWrt
> UCI Command Line Utility or the Vyatta vbash but using a different
>  approach.


Tom, I'd like to direct your attention to the OpenLMI project at
www.openlmi.org. We're working on a public, local/remote API interface
for doing system management in Linux. It seems to me that your config
interface might benefit from hooking into OpenLMI to do the actual
work under the hood. I was hoping you might be willing to talk with us
about integrating these two projects.

The benefits to OpenLMI would be access to a ready, usable UI
interface for system management. The benefits to python-configshell
would be a stable interface for actually performing the requested work.

If you're interested in exploring this, please subscribe to
https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel (so as
not to saturate devel@lists.fedoraproject.org with excess
project-specific discussions).
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEMKxsACgkQeiVVYja6o6OtDQCfVziWJs95pE5qQjw3pI6JfYDI
S4kAn1NCQwyG8la066jR0VCUDFPhHcjR
=yd8g
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: systemd features

[Rahul Sundaram]

Hi

On Fri, Feb 1, 2013 at 3:23 PM, "Jóhann B. Guðmundsson"

>
> You can go yourself through the community working log meetings to find my
> reference.
>
> I would expect RH employee ( and other corporation's employee ) sitting at
> the same table as their community brethren's and not having to worries
> about their job for their actions within the community.
>

If their work in the community is part of their job, then we cannot really
separate the two.

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

Re: Proposed F19 Feature: systemd features

[Jóhann B. Guðmundsson]

On 02/01/2013 08:04 PM, Rahul Sundaram wrote:


Again, your complaint here seems very vague.  Please provide 
references.  If there is a complaint about someone working in a 
company that itself is involved in the project, it is not unexpected 
it will get escalated to their manager to help resolve it.   Since you 
are a volunteer, that will not be the case.  How is this special 
treatment?  What else did you expect?


You can go yourself through the community working log meetings to find 
my reference.


I would expect RH employee ( and other corporation's employee ) sitting 
at the same table as their community brethren's and not having to 
worries about their job for their actions within the community.


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

Re: Proposed F19 Feature: systemd features

[Rahul Sundaram]

Hi

On Fri, Feb 1, 2013 at 2:42 PM, "Jóhann B. Guðmundsson"  wrote:

> I dont know if that group actually is active and on one of the group when
it got formed it was proposed that Red Hat employees would > get *special*
treatment within the project and the CWG would speak with their *managers*
so much for that...

Again, your complaint here seems very vague.  Please provide references.
If there is a complaint about someone working in a company that itself is
involved in the project, it is not unexpected it will get escalated to
their manager to help resolve it.   Since you are a volunteer, that will
not be the case.  How is this special treatment?  What else did you
expect?


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

Re: Proposed F19 Feature: systemd features

[Matthew Miller]

On Fri, Feb 01, 2013 at 07:39:48PM +, "Jóhann B. Guðmundsson" wrote:
> >I really don't understand how it hurts to have multiple people look at the
> >information.
> The plan was to gather that information and give people something to
> actually look at.

So... more information is good, right?

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

Re: Proposed F19 Feature: systemd features

[Jon Ciesla]

On Fri, Feb 1, 2013 at 1:38 PM, "Jóhann B. Guðmundsson"
wrote:

> On 02/01/2013 05:16 PM, Adam Williamson wrote:
>
>> On Fri, 2013-02-01 at 08:44 +, "Jóhann B. Guðmundsson" wrote:
>>
>>> On 02/01/2013 04:21 AM, David Tardon wrote:
>>>
 On Thu, Jan 31, 2013 at 11:46:33PM +, "Jóhann B. Guðmundsson" wrote:

> And in the midst of me doing this research I have to have Bill
> Notting butting into my work ( and I know what that means ), trying
> to come up with his own list instead of simply asking me for the one
> I was looking at [¹] and consulting with me where I was with my
> findings and now he can just have at it and finish do it his own
> way., create those units and prep the necessary patches to the
> packages etc. since he's such an expert on the matter.
>
 If you stop behaving like a child, maybe people will start to take you
 seriously.

>>> And Bills behavior towards me has been so civilized through out the
>>> years.
>>>
>>> If he leaves me and my work alone and general stays away from me maybe I
>>> will...
>>>
>> Well, no, that's not going to happen. Fedora's a collaborative project.
>> If you're making significant changes to core packages - which you would
>> be, if you start porting things from crond to systemd timers - other
>> people who work on the core system are going to take an interest. Like
>> Bill. That's kind of how things work around here. You don't just get to
>> stake off some territory and say MINE MINE MINE NO-ONE COMES IN HERE.
>>
>
> Oh and you where so collaborate Adam when you decided on your own deleting
> my tickets in the QA trac instance that A) exist because of me and B) I was
> using to keep track on my work within the QA community. It did not cross
> for a second for you to send me a line or ping me on irc and ask me if it
> was ok.
>
> Ńor did Stephen or Toshio when they filed an request that I was granted
> packaging privileges without them as much as asking me or giving me heads
> up before doing that!
>
> And you dare talking to me about mine mine when I want one man, one man
> out of thousand of contributors to leave me alone and stay out of my
> business!
>

I count at least 4, in this thread alone.  I say this to my kids
regularly:  Your perception of their behaviour is not, by itself, always a
good rationale for yours.  Sometimes, in a community, when you work on
other people's stuff, they might also want to work on it or have input into
how it's done.  That's just the way it is.  Since no one person writes all
the code or maintains all the packages, it's *all* other people's stuff.

-J


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




-- 
http://cecinestpasunefromage.wordpress.com/

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

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

Re: Proposed F19 Feature: systemd features

[Jóhann B. Guðmundsson]

On 02/01/2013 07:41 PM, Rahul Sundaram wrote:

Hi


On Fri, Feb 1, 2013 at 2:28 PM, "Jóhann B. Guðmundsson" wrote:


I dont mind everyone else opinions and criticism or help staying
in and out of my works and what not except Bill's after the
treatment he has given me over the years.


I have no idea what treatment you are talking about. State the 
problems specifically, resolve it or disagree and get over it.   If 
you need help with that,  talk to 
https://fedoraproject.org/wiki/Community_working_grou 



I dont know if that group actually is active and on one of the group 
when it got formed it was proposed that Red Hat employees would get 
*special* treatment within the project and the CWG would speak with 
their *managers* so much for that...


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

Re: Proposed F19 Feature: systemd features

[Jóhann B. Guðmundsson]

On 02/01/2013 07:35 PM, Matthew Miller wrote:

On Fri, Feb 01, 2013 at 07:28:56PM +, "Jóhann B. Guðmundsson" wrote:

I personally would have preferred people waiting and giving me the
chance to go through all the cron jobs and make my presentation and
findings to fesco then afterwards discuss the merits of making the
switch for the cron jobs of those 38 components that might warrant
conversion.

I really don't understand how it hurts to have multiple people look at the
information.




The plan was to gather that information and give people something to 
actually look at.


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

Re: Proposed F19 Feature: systemd features

[Jóhann B. Guðmundsson]

On 02/01/2013 05:16 PM, Adam Williamson wrote:

On Fri, 2013-02-01 at 08:44 +, "Jóhann B. Guðmundsson" wrote:

On 02/01/2013 04:21 AM, David Tardon wrote:

On Thu, Jan 31, 2013 at 11:46:33PM +, "Jóhann B. Guðmundsson" wrote:

And in the midst of me doing this research I have to have Bill
Notting butting into my work ( and I know what that means ), trying
to come up with his own list instead of simply asking me for the one
I was looking at [¹] and consulting with me where I was with my
findings and now he can just have at it and finish do it his own
way., create those units and prep the necessary patches to the
packages etc. since he's such an expert on the matter.

If you stop behaving like a child, maybe people will start to take you
seriously.

And Bills behavior towards me has been so civilized through out the years.

If he leaves me and my work alone and general stays away from me maybe I
will...

Well, no, that's not going to happen. Fedora's a collaborative project.
If you're making significant changes to core packages - which you would
be, if you start porting things from crond to systemd timers - other
people who work on the core system are going to take an interest. Like
Bill. That's kind of how things work around here. You don't just get to
stake off some territory and say MINE MINE MINE NO-ONE COMES IN HERE.


Oh and you where so collaborate Adam when you decided on your own 
deleting my tickets in the QA trac instance that A) exist because of me 
and B) I was using to keep track on my work within the QA community. It 
did not cross for a second for you to send me a line or ping me on irc 
and ask me if it was ok.


Ńor did Stephen or Toshio when they filed an request that I was granted 
packaging privileges without them as much as asking me or giving me 
heads up before doing that!


And you dare talking to me about mine mine when I want one man, one man 
out of thousand of contributors to leave me alone and stay out of my 
business!


JBG


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

Re: Proposed F19 Feature: systemd features

[Rahul Sundaram]

Hi


On Fri, Feb 1, 2013 at 2:28 PM, "Jóhann B. Guðmundsson" wrote:

>
> I dont mind everyone else opinions and criticism or help staying in and
> out of my works and what not except Bill's after the treatment he has given
> me over the years.
>

I have no idea what treatment you are talking about.  State the problems
specifically, resolve it or disagree and get over it.   If you need help
with that,  talk to https://fedoraproject.org/wiki/Community_working_group

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

Re: Proposed F19 Feature: systemd features

[Matthew Miller]

On Fri, Feb 01, 2013 at 07:28:56PM +, "Jóhann B. Guðmundsson" wrote:
> I personally would have preferred people waiting and giving me the
> chance to go through all the cron jobs and make my presentation and
> findings to fesco then afterwards discuss the merits of making the
> switch for the cron jobs of those 38 components that might warrant
> conversion.

I really don't understand how it hurts to have multiple people look at the
information.


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

Re: Proposed F19 Feature: systemd features

[Jóhann B. Guðmundsson]

On 02/01/2013 07:14 PM, Rahul Sundaram wrote:

Hi

On Fri, Feb 1, 2013 at 3:44 AM, "Jóhann B. Guðmundsson"

>  And Bills behavior towards me has been so civilized through out the 
years.
>  If he leaves me and my work alone and general stays away from me 
maybe I will...


You are just proving David Tardon's point here.   You have no monopoly 
on ideas.   Just because you have a proposal doesn't mean everyone 
else who is interested has to stay out of it.   Our method of doing 
things in Fedora is to actively sharing the space we work on.  That is 
the civilized way to handle it.  You seem to want  total control over 
your chosen area of participation.   We simply don't work that way.  
Bill Nottingham has a lot of relevant expertise in this area and his 
opinions are atleast as welcome as yours.  You are free to disagree 
with him but you cannot take stake any ownership.


I dont mind everyone else opinions and criticism or help staying in and 
out of my works and what not except Bill's after the treatment he has 
given me over the years.


I personally would have preferred people waiting and giving me the 
chance to go through all the cron jobs and make my presentation and 
findings to fesco then afterwards discuss the merits of making the 
switch for the cron jobs of those 38 components that might warrant 
conversion.


But since it matters so much to you have at it.

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

Proposed F19 Feature: Virt Storage Migration

[Jaroslav Reznik]

= Features/Virt Storage Migration =
https://fedoraproject.org/wiki/Features/Virt_Storage_Migration

Feature owner(s): Cole Robinson , Paolo Bonzini 


Migrate a running virtual machine from one host to another, including in use 
storage, with no downtime. No need for a shared storage location between the 
two.  

== Detailed description ==
Live migration of a VM has been around for a while, but usage historically 
required that VM storage disk images were shared between the source and 
destination host, and mounted in the same location.

Since qemu 0.12 (December 2009), there has been a storage migration feature in 
qemu, but it was inflexible, and inefficient to the point that any workload in 
the guest would often prevent the guest from ever being full migrated. While 
supported in libvirt/virsh, it was still difficult to use, requiring stub disk 
images to be present on the destination host.

New developments in QEMU allow migrating a VM with no shared storage between 
the source and destination, and does it in a performant manner. 
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Proposed F19 Feature: System Configuration Shell

[Jaroslav Reznik]

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

Feature owner(s): Tom Schwaller 

The System Configuration Shell System provides an easy to use interactive 
command line interface with a standardized syntax to manage your system. 

== Detailed description ==
Network Administrators love their very powerful switch/router/firewall/etc. CLI 
which can be used for all administrative tasks in a very structured and well 
documented way. Compare that to classical Linux System Administration which is 
a mix of editing configuration files using different formats and executing 
commands & scripts with a heterogeneous syntax. The System Configuration Shell 
will provide an interactive command line interface using the python-configshell 
framework with a standardized syntax to manage your system. It consists of the 
command configsh which starts an interactive shell and can also be used in 
shell scripts and the command config for one-shot configuration commands (e.g. 
config hostname www.fedoraproject.org which not only executes hostname 
www.fedoraproject.org but also changes several configuration files to make the 
new hostname permanent).

The System Configuration Shell will facilitate the Linux System administrators 
daily work. Since every command is logged (in a verbose mode even showing the 
exact system commands and scripts executed), each administrator can decide 
him/herself if he/she feels comfortable using standard parts (or local 
extensions) the System Configuration Shell. The approach is similar to the 
OpenWrt UCI Command Line Utility or the Vyatta vbash but using a different 
approach. 
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Dracut HostOnly

[Reindl Harald]

Am 01.02.2013 18:22, schrieb Adam Williamson:
> On Fri, 2013-02-01 at 11:46 +0100, Reindl Harald wrote:
> 
>> in this case you have already the following because on
>> virtual machines it is very unlikely that hardware
>> fundenemtally changes
> 
> Porting machines from one virt system to another isn't that unusual, and
> that can cause the hardware to change

one reson more to NOT make HostOnly DEFAULT

there where i work you setup HA clusters and failover and
will not change for fun the infrastructure behind the guests
because the main target of virtualization is abstraction
from the real hardware and so HostOnly is OK, i can live with
it but i can see no sense in making it default to make others
lifes harder




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

Re: Proposed F19 Feature: systemd features

[Rahul Sundaram]

Hi

On Fri, Feb 1, 2013 at 3:44 AM, "Jóhann B. Guðmundsson"

>  And Bills behavior towards me has been so civilized through out the
years.
>  If he leaves me and my work alone and general stays away from me maybe I
will...

You are just proving David Tardon's point here.   You have no monopoly on
ideas.   Just because you have a proposal doesn't mean everyone else who is
interested has to stay out of it.   Our method of doing things in Fedora is
to actively sharing the space we work on.  That is the civilized way to
handle it.  You seem to want  total control over your chosen area of
participation.   We simply don't work that way.  Bill Nottingham has a lot
of relevant expertise in this area and his opinions are atleast as welcome
as yours.  You are free to disagree with him but you cannot take stake any
ownership.

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

Proposed F19 Feature: Usermode Migration

[Jaroslav Reznik]

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

Feature owner(s): Harald Hoyer , Kay Sievers 
, Bill Nottingham  

Access control of privileged operations for ordinary users should be handled 
exclusively by a centrally managed authority.

Usermode/consolehelper should be phased out and be replaced entirely by 
polkit. 

== Detailed description ==
The usermode/consolehelper program is a setuid-root wrapper around a couple of 
system tools, providing superuser privileges to ordinary users. Its policy is 
controlled by text files in /etc.

These days, most privileged system operations are already controlled by 
polkit, a well-established, fine-grained, (possibly) network-transparent 
service for managing privileged operations by ordinary users. Enterprise 
environments need to be able to centrally define access control policy for the 
organization, and automatically apply it to all connected workstations.

* polkit can be used by privileged processes to decide if it should execute 
privileged operations on behalf of the requesting user. For directly executed 
tools, polkit provides a setuid-root helper program called ‘’pkexec’’.The 
hooks to ask the user for authorizations are well-integrated into text 
environments, and native in all major graphical environments.
* The concept of a ''console user''  (that usermode/consolehelper implements) 
is no longer a sufficient concept to derive privileges from. OTOH polkit 
authorizations can properly distinguish between multiple active sessions and 
seats: e.g. an untrusted user’s reboot request is only granted if only a 
single user session runs at that time.

Btw. this Feature was already accepted for Fedora 18 and it's continuous effort 
spread over several releases.
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Proposed F19 Feature: Virtio RNG

[Jaroslav Reznik]

= Features/Virtio RNG =
https://fedoraproject.org/wiki/Features/Virtio_RNG

Feature owner(s): Cole Robinson , Amit Shah 


Provide a paravirtual random number generator to virtual machines, to prevent 
entropy starvation in guests.  

== Detailed description ==
The linux kernel collects entropy from various non-deterministic hardware 
events, like mouse and keyboard input, and network traffic. This entropy is 
then 
exposed through /dev/random, commonly used by cryptographic applications that 
need true randomness to maintain security. However if more entropy is being 
consumed than is being produced, we have entropy starvation: reading from 
/dev/random will block, which can cause a denial of service. A common example 
here is use of /dev/random by SSL in various services.

VirtIO RNG (random number generator) is a paravirtualized device that is 
exposed as a hardware RNG device to the guest. Virtio RNG just appears as a 
regular hardware RNG to the guest, which the kernel reads from to fill its 
entropy pool. This effectively allows a host to inject entropy into a guest via 
several means: The default mode uses the host's /dev/random, but a physical HW 
RNG device or EGD (Entropy Gathering Daemon) source can also be used. 
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

[Rahul Sundaram]

Hi

On Fri, Feb 1, 2013 at 12:20 PM, Paul Wouters  wrote:

>
> Now if only "cannot display date with the time in top panel" could be
> a gnome3 blocker bug, that would be one less gnome3 issue. The other
> major one of notifications being seemingly overengineered while still
> being pretty useless probably is a bigger issue :/


It is possible to display date with time in the panel just fine.  use
gnome-tweak-tool to do that.  I agree that notifications are problematic
however.   I had to install a extension just to get to know when a open
window in pidgin is getting new messages.

https://extensions.gnome.org/extension/258/notifications-alert-on-user-menu/

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

[Jerry James]

On Fri, Feb 1, 2013 at 10:20 AM, Paul Wouters  wrote:
> Now if only "cannot display date with the time in top panel" could be
> a gnome3 blocker bug, that would be one less gnome3 issue. The other
> major one of notifications being seemingly overengineered while still
> being pretty useless probably is a bigger issue :/

Run gnome-tweak-tool.  Choose "Shell" in the left pane.  Click "On"
next to "Show date in clock".  Enjoy!
--
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

[Tom Hughes]

On 01/02/13 17:20, Paul Wouters wrote:


Now if only "cannot display date with the time in top panel" could be
a gnome3 blocker bug, that would be one less gnome3 issue.


You know you can turn the date on with gnome-tweak-tool right? or just 
with this:


gsettings set org.gnome.desktop.interface clock-show-date true

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fairly serious GCC 4.8 Ada regression

[Orion Poplawski]

GCC 4.8 seems to have a fairly serious regression with regards to converting 
Long_Float to Integer:


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

There aren't many ada using packages in in Fedora, but this is affecting plplot.


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

Re: Proposed F19 Feature: Dracut HostOnly

[Adam Williamson]

On Fri, 2013-02-01 at 11:46 +0100, Reindl Harald wrote:

> in this case you have already the following because on
> virtual machines it is very unlikely that hardware
> fundenemtally changes

Porting machines from one virt system to another isn't that unusual, and
that can cause the hardware to change.
-- 
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

[Bug 893916] perl-DBD-CSV-0.38 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |CURRENTRELEASE
Last Closed||2013-02-01 12:05:23

-- 
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=cS75oGV1pa&a=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 893916] perl-DBD-CSV-0.38 is available

[bugzilla]

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

--- Comment #4 from Fedora Update System  ---
perl-Clone-0.34-1.fc18, perl-DBI-1.623-1.fc18, perl-DBD-CSV-0.38-1.fc18 has
been pushed to the Fedora 18 stable repository.  If problems still persist,
please make note of it in this bug report.

-- 
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=WQSZYviMlV&a=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Proposed F19 Feature: Cinnamon as Default Desktop

[Paul Wouters]

On Wed, 30 Jan 2013, Bruno Wolff III wrote:


On 2013-01-29, 22:52 GMT, Michael Scherer wrote:

I am delighted to announce you that Red Hat has a policy of not
tolerating drugs on the work place. So you should be utterly relieved to
know that no people posting here with a @redhat.com email should be
under the influence of any serious hallucinogens.


Some of Red Hat people are remotees, working from home. ;)


And even at the office, I doubt they really ban all drugs. Really, no Moutain 
Dew?


I can only speak for Red Hat Canada, when I say that in our country,
there is no caffeine in Mountain Dew.

but more on topic, having disliked the reduced functionality of gnome3
when it replaced my beloved gnome2, I tried out cinnamon, and well. I
went back to gnome3. The bottom panel did not work as with gnome2,
changing the size of the panel (my eyes suck) did not increase the size
of the icons on it. Changing window focus felt like a first person
shooter. But I _could_ get a date displayed in the top panel!

Changing the default a few times just means we are guaranteed to annoy 
_everyone_

Now if only "cannot display date with the time in top panel" could be
a gnome3 blocker bug, that would be one less gnome3 issue. The other
major one of notifications being seemingly overengineered while still
being pretty useless probably is a bigger issue :/

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

Re: Proposed F19 Feature: systemd features

[Adam Williamson]

On Fri, 2013-02-01 at 08:44 +, "Jóhann B. Guðmundsson" wrote:
> On 02/01/2013 04:21 AM, David Tardon wrote:
> > On Thu, Jan 31, 2013 at 11:46:33PM +, "Jóhann B. Guðmundsson" wrote:
> >> And in the midst of me doing this research I have to have Bill
> >> Notting butting into my work ( and I know what that means ), trying
> >> to come up with his own list instead of simply asking me for the one
> >> I was looking at [¹] and consulting with me where I was with my
> >> findings and now he can just have at it and finish do it his own
> >> way., create those units and prep the necessary patches to the
> >> packages etc. since he's such an expert on the matter.
> > If you stop behaving like a child, maybe people will start to take you
> > seriously.
> 
> And Bills behavior towards me has been so civilized through out the years.
> 
> If he leaves me and my work alone and general stays away from me maybe I 
> will...

Well, no, that's not going to happen. Fedora's a collaborative project.
If you're making significant changes to core packages - which you would
be, if you start porting things from crond to systemd timers - other
people who work on the core system are going to take an interest. Like
Bill. That's kind of how things work around here. You don't just get to
stake off some territory and say MINE MINE MINE NO-ONE COMES IN HERE.
-- 
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: rawhide report: 20130201 changes

[पराग़]

Hi,
  I have fixed libicu broken dependencies for following packages
389-admin
389-ds-base
389-dsgw
ibus-qt
idzebra
libcommuni
libircclient-qt
msort
pam_mapi
sword
yaz
zarafa

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

Re: Proposed F19 Feature: High Availability Container Resources

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/29/2013 03:17 PM, Glauber Costa wrote:
 = Features/ High Availability Container Resources = 
 https://fedoraproject.org/wiki/Features/High_Availability_Container_Resources


 
Feature owner(s): David Vossel 
 
 The Container Resources feature allows the HA stack (Pacemaker + 
 Corosync) residing on a host machine to extend management of
 resources into virtual guest instances (KVM/LXC).
>>> 
>>> Is this about LXC or libvirt-lxc? These two are entirely different 
>>> projects, sharing no code, which makes me wonder which project is 
>>> meant here?
>> 
>> Yep, I left that vague and should have used the term "linux containers"
>> instead of LXC.  I'm going to update the page to reflect this.
>> 
>> This feature architecturally doesn't care which project manages/initiates
>> the container.  All we care about is that the container has it's own
>> isolated network namespace that is reachable from the host (or whatever
>> node is remotely managing the resources within the container)  I
>> intentionally chose to use tcp/tls as the first transport we will support
>> to avoid locking this feature into use with any specific virt
>> technology.
>> 
>> With that said, I'm likely going to be focusing my test cases on
>> libvirt-lxc just because it seems like it has better fedora support.  The
>> LXC project appears to be moving all over the place.  Part of the project
>> is really to identify good use-cases for linux containers in an HA
>> environment.  The kvm use-case is fairly straight forward and well
>> understood though.  I'll update the page to list the linux container
>> use-case as a possible risk.
> 
> Please also keep in mind that LXC usually refers to a specific project,
> either the original "lxc" code or "libvirt-lxc". We have either Container
> Solutions in Fedora, like OpenVZ.
> 
> You may be able to reach a broader base by making your solution work on
> that too (and of course, I'd be more than happy to help to trim any issues
> you may find)
> 
> -- E Mare, Libertas
> 
I would like to also understand how we can work together with virt-sandbox.
(Secure Linux Containers)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEL6LcACgkQrlYvE4MpobNP2wCglY4RnI20xvM2hXrbKkQzcHyP
rmcAnRTGdfi86tlQCRJs5lNucFr+IOda
=pr0g
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Dracut HostOnly

[Reindl Harald]

Am 01.02.2013 11:37, schrieb Harald Hoyer:
> Am 29.01.2013 16:53, schrieb Dennis Gilmore:
>> as legal has said we cannot pregenerate initramfses i think this should
>> be a non-starter. even loading a 20mb initramfs from a sdcard on a slow
>> arm box doesnt take that long, and id personally much rather be able to
>> change hardware or yank the drive  and put it into a different box
>> without worrying about making sure i have the right initramfs bits in
>> place. at least to me the costs outweigh the benefits. the grub timeout
>> on my laptop/desktops is longer than the time it takes to load the
>> initramfs. 
>>
> If you are running a lot of virtual machines, you will care about
> a) boot time
> b) disk size
> c) yum update time (including generation of the initramfs)

in this case you have already the following because on
virtual machines it is very unlikely that hardware
fundenemtally changes - but on real hardware as DEFAULT?

yes i have the same also on real hardware
but i would not recommend it to any other person

[root@testserver:~]$ cat /etc/dracut.conf.d/90-plymouth.conf
omit_dracutmodules+="plymouth"

[root@testserver:~]$ cat /etc/dracut.conf.d/91-host-only.conf
hostonly="yes"




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

Re: Proposed F19 Feature: Apache OpenOffice

[Fernando Nasser]

What about dependency conflicts?

Which one will determine the version of the dependencies?
I think it will have to be the current existing OO right?

So the new one, if added, must build and run with any shared
dependency at the original one levels.

Makes sense?

--Fernando

- Original Message -
> From: "Matej Cepl" 
> To: devel@lists.fedoraproject.org
> Sent: Friday, February 1, 2013 8:38:59 AM
> Subject: Re: Proposed F19 Feature: Apache OpenOffice
> 
> On 2013-01-31, 22:07 GMT, Chris Adams wrote:
> > I'm not saying having both is a bad thing, but I would like to
> > think
> > that there's some thought given to "does Fedora gain from having
> > both",
> > since there is a cost involved.
> 
> We don’t (unfortunately?) have policy to stop somebody from packaging
> whatever they want (if it satisfies Fedora packaging policy).
> 
> Matěj
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Apache OpenOffice

[Matej Cepl]

On 2013-01-31, 22:07 GMT, Chris Adams wrote:
> I'm not saying having both is a bad thing, but I would like to think
> that there's some thought given to "does Fedora gain from having both",
> since there is a cost involved.

We don’t (unfortunately?) have policy to stop somebody from packaging 
whatever they want (if it satisfies Fedora packaging policy).

Matěj

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

Re: Proposed F19 Feature: OpenAttestation

[Josh Boyer]

On Thu, Jan 31, 2013 at 10:02 PM, Wei, Gang  wrote:
> Josh Boyer wrote on 2013-02-01:
>> On Thu, Jan 31, 2013 at 12:40 AM, Wei, Gang  wrote:
>>> Bill Nottingham wrote on 2013-01-29:
 Jaroslav Reznik (jrez...@redhat.com) said:
> = Features/OpenAttestation =
> https://fedoraproject.org/wiki/Features/OpenAttestation
>
> Feature owner(s): Gang Wei 
>
> Provide fedora packages for OpenAttestation to support Trusted Compute
> Pools(TCP) feature in OpenStack since Folsom release & in future oVirt
> releases.

 Wow, TCP is a horribly unfortunate acronym collision.

> == Detailed description ==
> This feature would include mostly packaging OpenAttestation project for
> fedora.
>
> * the source package will be named oat
> * the binary packages will include oat-appraiser & oat-client
>>
>> 
>>
 How does it intend to attest the OS in a rapidly updating Fedora
 environment? Just the kernel + initramfs? An image-based checksum such
 as what is used in ChromeOS?
>>>
>>> By far, just kernel + initramfs. Every time the kernel/initramfs got
>>> updated, the Know Good Value in OpenAttestation Server should be
>>> updated to take new kernel/initramfs as "trusted" one.
>>
>> Does this feature require any kernel options set in the Fedora kernel?
>> The dependency on Intel TXT machines and tboot would lead me to believe
>> that it might require IMA/EVA support.  Is that the case?  If so, those
>> are currently disabled in the Fedora kernel.
>
> This feature doesn't require any kernel options set directly. But tboot
> package will require intel_iommu=on and it will do it by providing grub2
> scripts.
> It doesn't require IMA/EVA by far.

Great.  Thanks for the quick reply.

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

Re: Proposed F19 Feature: firewalld Rich Language

[Thomas Woerner]

On 02/01/2013 04:43 AM, Scott Schmit wrote:

On Wed, Jan 30, 2013 at 12:56:18PM +, Jaroslav Reznik wrote:

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

Feature owner(s): Thomas Woerner 

This feature adds a rich (high level) language to firewalld, that
allows to easily create complex firewall rules without the knowledge
of iptables syntax.


Where is this language documented, or is it still to be designed?

It is in the design state. If the language is in an advanced state, I 
will push it to the firewalld and feature page.

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

Re: Proposed F19 Feature: Apache OpenOffice

[Pierre-Yves Chibon]

On Fri, 2013-02-01 at 11:41 +0100, Martin Sourada wrote:
> On Fri, 01 Feb 2013 09:38:19 +0100 
> Pierre-Yves Chibon wrote:
> 
> > On Fri, 2013-02-01 at 09:34 +0100, Robert Mayr wrote:
> > > 
> > > 
> > > 2013/2/1 Martin Sourada 
> > >  
> > > Yes, defaults needs to be sensible and usable and for many
> > > people
> > > that's what they end up with. I'm not saying we should go
> > > and have AOO
> > > installed by default, but available in repos in a state that
> > > does not
> > > conflict with LO (and other office suites *in official
> > > repos*) ;-) Think
> > > about sysadmins, multi-user systems, ... Seeing a bug report
> > > saying "My
> > > LO Writer segfaults with this error while AOO is installed"
> > > isn't
> > > exactly helpful, but not having AOO isn't a solution. Hence
> > > I say OK to
> > > adding AOO, as long as it wont conflict with LO both as
> > > package and in
> > > runtime.
> > > 
> > > Unlike pulseaudio (in the above linked thread), AOO is
> > > end-user GUI application, not a
> > > library/daemon/sound-server/whatever
> > > used to get the wanted sound to your headphones (that by
> > > design
> > > interferes with anything else trying to do the same) ;-) By
> > > adding AOO
> > > we're not breaking some third app, we might break LO and
> > > that's exactly
> > > what I consider critical not to do. Is it doable? Are there
> > > people
> > > willing and able to do that? If yes, sure, let them.
> > 
> > > +1 Martin, that's the point.
> > 
> > No that's completely not the point:
> > http://lists.fedoraproject.org/pipermail/devel/2013-January/177803.html
> > 
> Have you actually read what I wrote and what I was reacting to? Or have
> I written it so bad to make it seem in conflict with what you linked?

I was arguing that you are trying to make a point that is not even on
the table, so there is no point discussing over it.

Since we all agree, let's move on :)

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

Re: Proposed F19 Feature: Apache OpenOffice

[Martin Sourada]

On Fri, 01 Feb 2013 09:38:19 +0100 
Pierre-Yves Chibon wrote:

> On Fri, 2013-02-01 at 09:34 +0100, Robert Mayr wrote:
> > 
> > 
> > 2013/2/1 Martin Sourada 
> >  
> > Yes, defaults needs to be sensible and usable and for many
> > people
> > that's what they end up with. I'm not saying we should go
> > and have AOO
> > installed by default, but available in repos in a state that
> > does not
> > conflict with LO (and other office suites *in official
> > repos*) ;-) Think
> > about sysadmins, multi-user systems, ... Seeing a bug report
> > saying "My
> > LO Writer segfaults with this error while AOO is installed"
> > isn't
> > exactly helpful, but not having AOO isn't a solution. Hence
> > I say OK to
> > adding AOO, as long as it wont conflict with LO both as
> > package and in
> > runtime.
> > 
> > Unlike pulseaudio (in the above linked thread), AOO is
> > end-user GUI application, not a
> > library/daemon/sound-server/whatever
> > used to get the wanted sound to your headphones (that by
> > design
> > interferes with anything else trying to do the same) ;-) By
> > adding AOO
> > we're not breaking some third app, we might break LO and
> > that's exactly
> > what I consider critical not to do. Is it doable? Are there
> > people
> > willing and able to do that? If yes, sure, let them.
> 
> > +1 Martin, that's the point.
> 
> No that's completely not the point:
> http://lists.fedoraproject.org/pipermail/devel/2013-January/177803.html
> 
Have you actually read what I wrote and what I was reacting to? Or have
I written it so bad to make it seem in conflict with what you linked?

Martin


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

Re: Proposed F19 Feature: Dracut HostOnly

[Harald Hoyer]

Am 30.01.2013 00:22, schrieb Dennis Gilmore:
> On Tue, 29 Jan 2013 16:32:12 +
> Matthew Garrett  wrote:
> 
>> On Tue, Jan 29, 2013 at 09:53:32AM -0600, Dennis Gilmore wrote:
>>> as legal has said we cannot pregenerate initramfses i think this
>>> should be a non-starter.
>>
>> We already ship several pre-generated initramfses.
>>
> 
> that are built at kernel build time? the issue with building it at
> build time was making sure we knew exactly what sourcs we needed to
> ship to match all the binaries in the initramfs. the initramfs's we
> build and ship as part of teh install tree we know exactly what sources
> because they match what is in the release tree rather than what was in
> the buildroot at build time.
> 
> Dennis
> 

The problem with kernel modules is, that the system can have/need non-kernel.rpm
modules and you would have to stack several initramfs images then and that leads
to the problem with depmod generated files.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Dracut HostOnly

[Harald Hoyer]

Am 29.01.2013 16:53, schrieb Dennis Gilmore:
> El Tue, 29 Jan 2013 14:45:34 +
> Jaroslav Reznik  escribió:
>> = Features/DracutHostOnly =
>> https://fedoraproject.org/wiki/Features/DracutHostOnly
> 
>> Feature owner(s): Harald Hoyer 
> 
>> Only create "host-only" initramfs images. A generic fallback image
>> should be installed by anaconda on installation/update and never ever
>> be removed.  
> 
>> == Detailed description ==
>> Current initramfs images contain most of the kernel drivers to boot
>> from any hardware. This results in a very big initramfs, which takes
>> a long time to load on system start and a long time to create on
>> kernel updates. Switching to host-only will improve the situation. To
>> cope with hardware change, a boot entry "Rescue System" should be
>> installed with a full fledged initramfs also containing debug tools.
>> This boot entry can then be used to recover from hardware changes and
>> also from unforseen software failure after updates.
> 
> as legal has said we cannot pregenerate initramfses i think this should
> be a non-starter. even loading a 20mb initramfs from a sdcard on a slow
> arm box doesnt take that long, and id personally much rather be able to
> change hardware or yank the drive  and put it into a different box
> without worrying about making sure i have the right initramfs bits in
> place. at least to me the costs outweigh the benefits. the grub timeout
> on my laptop/desktops is longer than the time it takes to load the
> initramfs. 
> 
> Dennis

If you are running a lot of virtual machines, you will care about
a) boot time
b) disk size
c) yum update time (including generation of the initramfs)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Dracut HostOnly

[Harald Hoyer]

Am 29.01.2013 19:28, schrieb Daniel J Walsh:
> On 01/29/2013 11:20 AM, John Reiser wrote:
> A generic fallback image should be installed by anaconda on
> installation/update and never ever be removed.
> 
>>> Also, fallback has interesting security properties…
> 
> 
>> "Rescue mode" forces a SELinux relabel at the next boot, and relabel can
>> take a very long time.
> 
>> How does "fallback mode" handle this, particularly if there have been 
>> updates to SELinux policy after the fallback was created?
> 
> The reason for this is we do not know what files were created on the system
> while SELinux was disabled (Policy Not Loaded).  If you know you did not
> created files on the system you could remove the /.autorelabel file and boot
> without a relabel.
> 

The "rescue" initramfs carries just more kernel drivers to cope with different
HW and will also have more debug tools, if you really really screwed up your
real root. Nothing security fancy here, besides that you might want to passwort
protect this entry, either via grub or via including /etc/passwd with a rescue
root password in the initramfs.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Dracut HostOnly

[Harald Hoyer]

Am 29.01.2013 17:20, schrieb John Reiser:
 A generic fallback image should be
 installed by anaconda on installation/update and never ever be
 removed.
> 
>> Also, fallback has interesting security properties…
> 
> 
> "Rescue mode" forces a SELinux relabel at the next boot, and relabel
> can take a very long time.
> 
> How does "fallback mode" handle this, particularly if there have been
> updates to SELinux policy after the fallback was created?
> 

The "rescue" initramfs and all initramfs in general do _not_ carry any selinux
policies. These are turned on later on the real root. Nothing changes here.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: using rpms for non-root installs

[Stephan Bergmann]

On 01/31/2013 08:40 AM, Michael Stahnke wrote:

You actually may have an option. It's dirty, and here be dragons. I
know this from working on RPM on AIX, so again, it's hacky. I did this
on a CentOS 6.3 box for my example, should work on Fedora.

You can do something like:

   ls zip-3.0-1.el6.x86_64.rpm
   mkdir $HOME/.myrpm
   cp -pr /var/lib/rpm/* $HOME/.myrpm/
   chown -R $USER  $HOME/.myrpm/
   rpm -Uvh --justdb --dbpath $HOME/.myrpm zip-3.0-1.el6.x86_64.rpm
   rpm2cpio < zip-3.0-1.el6.x86_64.rpm | cpio  -idmv
   rpm -q --dbpath $HOME/.myrpm zip

Results:

[vagrant@localhost ~]$ rpm -q --dbpath /home/vagrant/.myrpm zip
zip-3.0-1.el6.x86_64
[vagrant@localhost ~]$ rpm -q zip
package zip is not installed


You now have zip installed (and rooted) in $HOME.  You'd have to add
the --dbpath option to rpm any time you used it, and it would get out
of sync with the system rpm database unless you wrote some tooling
around that. But it's completely do-able.

Again, it's ugly and I don't recommend it.


FWIW, we have a similar script for LibreOffice, 
 
(inherited from its OpenOffice.org ancestry), and at least back in OOo 
times used it frequently to install instances "to the side."  Worked 
reasonably well.


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

Re: Proposed F19 Feature: systemd features

[Jóhann B. Guðmundsson]

On 02/01/2013 04:21 AM, David Tardon wrote:

On Thu, Jan 31, 2013 at 11:46:33PM +, "Jóhann B. Guðmundsson" wrote:

And in the midst of me doing this research I have to have Bill
Notting butting into my work ( and I know what that means ), trying
to come up with his own list instead of simply asking me for the one
I was looking at [¹] and consulting with me where I was with my
findings and now he can just have at it and finish do it his own
way., create those units and prep the necessary patches to the
packages etc. since he's such an expert on the matter.

If you stop behaving like a child, maybe people will start to take you
seriously.


And Bills behavior towards me has been so civilized through out the years.

If he leaves me and my work alone and general stays away from me maybe I 
will...


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

Re: Proposed F19 Feature: Apache OpenOffice

[Pierre-Yves Chibon]

On Fri, 2013-02-01 at 09:34 +0100, Robert Mayr wrote:
> 
> 
> 2013/2/1 Martin Sourada 
>  
> Yes, defaults needs to be sensible and usable and for many
> people
> that's what they end up with. I'm not saying we should go and
> have AOO
> installed by default, but available in repos in a state that
> does not
> conflict with LO (and other office suites *in official
> repos*) ;-) Think
> about sysadmins, multi-user systems, ... Seeing a bug report
> saying "My
> LO Writer segfaults with this error while AOO is installed"
> isn't
> exactly helpful, but not having AOO isn't a solution. Hence I
> say OK to
> adding AOO, as long as it wont conflict with LO both as
> package and in
> runtime.
> 
> Unlike pulseaudio (in the above linked thread), AOO is
> end-user GUI application, not a
> library/daemon/sound-server/whatever
> used to get the wanted sound to your headphones (that by
> design
> interferes with anything else trying to do the same) ;-) By
> adding AOO
> we're not breaking some third app, we might break LO and
> that's exactly
> what I consider critical not to do. Is it doable? Are there
> people
> willing and able to do that? If yes, sure, let them.

> +1 Martin, that's the point.

No that's completely not the point:
http://lists.fedoraproject.org/pipermail/devel/2013-January/177803.html


Pierre

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

Re: Proposed F19 Feature: Apache OpenOffice

[Robert Mayr]

2013/2/1 Martin Sourada 

>
> Yes, defaults needs to be sensible and usable and for many people
> that's what they end up with. I'm not saying we should go and have AOO
> installed by default, but available in repos in a state that does not
> conflict with LO (and other office suites *in official repos*) ;-) Think
> about sysadmins, multi-user systems, ... Seeing a bug report saying "My
> LO Writer segfaults with this error while AOO is installed" isn't
> exactly helpful, but not having AOO isn't a solution. Hence I say OK to
> adding AOO, as long as it wont conflict with LO both as package and in
> runtime.
>
> Unlike pulseaudio (in the above linked thread), AOO is
> end-user GUI application, not a library/daemon/sound-server/whatever
> used to get the wanted sound to your headphones (that by design
> interferes with anything else trying to do the same) ;-) By adding AOO
> we're not breaking some third app, we might break LO and that's exactly
> what I consider critical not to do. Is it doable? Are there people
> willing and able to do that? If yes, sure, let them.
>
> Martin
>
> +1 Martin, that's the point.
LibreOffice is working quite well and must (!) therefore remain the default
Office Suite, as new users want to have a Suite which is working on Fedora,
and actually we know that LibreOffice is working very well.
Perhaps in the future we can say the same for OO, but not now, we don't
know it yet. If someone wants to provide the OO packages ok, but as an
alternative on the repo. And for those who want to install it, it shouldn't
break anything on Fedora, even if the user wants to install both Suites,
IMHO.
I hope you understand my point of view.

-- 
Robert Mayr
(robyduck)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel