Re: Let's close the remaining merge reviews

[drago01]

On Tue, Mar 25, 2014 at 1:07 AM, Toshio Kuratomi  wrote:
> On Mon, Mar 24, 2014 at 04:41:29PM -0400, Cole Robinson wrote:
>>
>> An alternative would be to reassign every open merge review to the component
>> in question, and let maintainers handle it as they like.
>>
>> Thoughts?
>>
> Alternative idea -- maybe identify all packages which are not ciritcal and
> have an open merge review.  Take those packages out of the repository.

That's a bit harsh ... we have been shipping those packages for years, why
suddenly drop them? What problem does this solve?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Request for comments regarding default configuration of pam_abl module

[Christopher Meng]

Is there a policy that for different Fedora.next products, we can
apply different rules?

Or just add comments in the conf?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Michael Catanzaro]

On Mon, 2014-03-24 at 17:14 -0700, Adam Williamson wrote:
> Saying that "nobody" wants this, it's "madness", "totally wacky",
> "almost all users are NOT going to put up with this" is going rather
> too
> far. I think it's entirely worth the Desktop product making this
> possible and I suspect quite a lot of people will use it, but I don't
> think it's sufficient grounds for downgrading the spins too far in
> importance or dropping them.

That language was probably too harsh, sorry. Let's try again: I think a
large (or huge) subset of users will be dissatisfied with the procedure
for installing alternate desktops through GNOME Software, and will opt
to not install Workstation at all. I don't think this will be a surprise
to anybody.

As long as we still have spins, it's not really a big deal.


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Adam Williamson]

On Mon, 2014-03-24 at 19:07 -0500, Michael Catanzaro wrote:
> On Mon, 2014-03-24 at 13:38 -0700, Dan Mashal wrote:
> > You always make sense. But nobody listens.
> > 
> > Who the hell wants to install Gnome to install MATE or KDE or XFCE?
> 
> Nobody, it's madness.

I think this is rather overstating the case. I certainly don't think
(and I already wrote) that it's enough to make everyone happy, but I
think it actually is what some people want. Quite a lot of people
install Ubuntu, for instance, and then add on GNOME or KDE or something
as a secondary environment to play around with: they want to have the
'standard product' installed, and another desktop available as a kind of
alternative on top of that, or they just want to make sure they have all
the 'standard' bits installed under/alongside their chosen desktop in
case anything else is expecting them (the "platform" approach).

Saying that "nobody" wants this, it's "madness", "totally wacky",
"almost all users are NOT going to put up with this" is going rather too
far. I think it's entirely worth the Desktop product making this
possible and I suspect quite a lot of people will use it, but I don't
think it's sufficient grounds for downgrading the spins too far in
importance or dropping them.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Michael Catanzaro]

On Mon, 2014-03-24 at 13:38 -0700, Dan Mashal wrote:
> You always make sense. But nobody listens.
> 
> Who the hell wants to install Gnome to install MATE or KDE or XFCE?

Nobody, it's madness.

I'm pretty sure everyone agrees that spins are here to stay. Are spins
the best solution to this problem? I doubt it, but at least it's no
worse than where we're at now.


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Let's close the remaining merge reviews

[Toshio Kuratomi]

On Mon, Mar 24, 2014 at 04:41:29PM -0400, Cole Robinson wrote:
> 
> An alternative would be to reassign every open merge review to the component
> in question, and let maintainers handle it as they like.
> 
> Thoughts?
> 
Alternative idea -- maybe identify all packages which are not ciritcal and
have an open merge review.  Take those packages out of the repository.

Then revisit the list and formulate a plan on what to do with thoes (even if
the plan is then, these were critical enough to leave in so we'll give them
a pass on going through a formal review).

-Toshio


pgpwZkb5_xTPH.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Jóhann B. Guðmundsson]

On 03/24/2014 10:23 PM, Miloslav Trmač wrote:

That doesn't work.


On the contrary if it did not the business module Red Hat is build upon 
would not exist since Red Hat is making money out of stability promises 
to it's customers which upstream is not providing right.


  Unfortunately a common reason to deprecate a component is that the 
upstream has gone away or become inactive, in which case we can't 
expect that same upstream to take action to coordinate a deprecation.




Here we are talking about various upstreams that make up the core/baseOS 
not single entity.


Now if an upstream for a component is dead in every sense of the word as 
in not being actively maintained anywhere by anyone it should be removed 
because that in itself is the signal for deprecation.


If people oppose said removal they simple should have to step up and 
start actively maintain that component thus bringing life to it again 
for those users that continue to use it as in if upstream has gone away 
and someone or some downstream distribution continues to patch that 
component it effectively has become the new upstream and the circle of 
life and the ecosystem surrounding that component continues.





(The Base WG has, as one its goals:

Based on feedback from other WGs, provide a API and/or ABI
stability for a specific release rather than simply package
versions/releases

)



I eagerly await how they plan on succeed doing that and how they are 
going to overcome certain obstacles they will be faced with solving 
while doing so.




By the way the kernel does not have a proper deprecation process
which is accurately reflected in all the code that is bit-rotting
there so it's not the holy grail of code maintenance as you let it
out to be.


The kernel has built a reputation for having a very simple deprecation 
process: "Don't" :)


Right which is bound to catch up with them (  it's unavoidable with 
evolution that disruptive changes will happen ) and arguably already has.


JBG

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Miloslav Trmač]

2014-03-24 22:53 GMT+01:00 "Jóhann B. Guðmundsson" :

> systemd is now, or soon will be, a core component of pretty much all
>> major and minor distributions out there and it's no longer just about
>> you Lennart and your thoughts of whether it's "Yuck!" or not, you are
>> now similar to the kernel and like the kernel you should have a proper
>> deprecation process that is not just what you, Kay and who ever the
>> main developers decide is cool or not at the time. You should give us
>> and distributions in general more than 4 days to deal with what lives
>> or not. Ultimately systemd is no longer in nappies and is all grown
>> up, while you are still it's father it's now a teenager and needs to
>> be somewhat independent of it's father, it has friends that now depend
>> on it and there's should be a central place where these architectural
>> changes and deprecation intentions are announced, discussed and in the
>> case of deprecation given more than 4 days before removal.
>>
> 

>  From broader view this boils down to how long should unmaintained core os
> components be kept around


The way I read Peter's mail, he is referring to TCPWrapName in systemd,
removing it less than 4 years after its introduction, with no advance
notification to users.  (To be clear, this is not a Fedora-specific concern
unless someone wants to make it one, and I don't.)

Independently, looking at
https://bugzilla.redhat.com/bugzilla/buglist.cgi?component=tcp_wrappers ,
it doesn't seem that tcp_wrappers need much maintenance.


> , which is something that should be hashed out among relevant upstreams in
> next plumbers session to establish a clear path forward and arguably
> upstreams should be responsible to make the decisions when things should be
> deprecated forcing downstream to either adapt new modern way's or maintain
> stuff downstream with themselves chose they do so instead of adapt.
>

That doesn't work.  Unfortunately a common reason to deprecate a component
is that the upstream has gone away or become inactive, in which case we
can't expect that same upstream to take action to coordinate a deprecation.

And in any case, we shouldn't start with the default assumption that any
published Open Source component is by default stable and recommended to be
relied upon by other applications, and only "blacklist" those that are
known to be deprecated; in fact many Open Source codebases are private
codebases published "just in case others find them useful".

We should rather use a "whitelist" approach, choosing and listing
components known to be competently designed and likely to be
well-maintained in the future, and taking extra care to help them stay that
way--moving towards an actual declared API of the OS.

(The Base WG has, as one its goals:

> Based on feedback from other WGs, provide a API and/or ABI stability for a
> specific release rather than simply package versions/releases
>
)


By the way the kernel does not have a proper deprecation process which is
> accurately reflected in all the code that is bit-rotting there so it's not
> the holy grail of code maintenance as you let it out to be.
>

The kernel has built a reputation for having a very simple deprecation
process: "Don't" :)  And actually it does have a "proper" deprecation
process beside that:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/obsolete(though
I'm not entirely sure how popular / comprehensive this is, at last
one time this seemed to be undesirable, opposing the "Don't" approach.)
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 24.03.2014 22:53, schrieb Jóhann B. Guðmundsson:
> By the way the kernel does not have a proper deprecation process which is 
> accurately reflected in all the code that
> is bit-rotting there so it's not the holy grail of code maintenance as you 
> let it out to be

the kernel at least has the rule "if it break something it has to be reverted"
a mantra from which *many* other projects could learn

why?

because Linus is not acting like a blind butcher and aware of his
great responsibility which is the logical result of great power



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Jóhann B. Guðmundsson]

On 03/24/2014 09:22 PM, Peter Robinson wrote:

I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
Fedora. There has been a request in systemd upstream to disable support
for it by default, but I am not sure I want to do that unless we can
maybe say goodbye to it for the big picture too.

I have decided now to drop all support for tcpwrap from systemd, for the
next release. For those who believe that tcpd is really a good idea
(yuck!) not much is lost though, they can just plug in tcpd into
systemd, the way they did it with good old inetd, too, hence we are not
taking anything away there, we are pretty much compatible with what
inetd supported there (or actually: didn't support there).

I am not going to file a feature for Fedora, to remove support for it
entirely across the whole distro. I still think dropping it is the right
thing to do, but I don't think it's a good use of my own time, to fight
this through... I'd be happy though if somebody else would pick this
up. Looking at the current FESCO members I am not entirely sure though
whether a proposal to disable libwrap would have a chance in the current
cycle though. (also, M. Miller kinda supported the proposal, which as
history tells us means he probably is _not_ going to vote for it in the
end...)

It's a pity though that nobody in Fedora is actively working on getting
rid of legacy cruft. I really wished we had some people who oversee
deprecating things more proactively, figure out how to deprecate things,
write stub code to provide smooth transitions, write release notes and
so on. Being at the bleeding edge of things also means deciding that
some things really should go, from time to time... Besides deprecating
old cruft like libwrap, this would also mean removing all the old crap
from comps "standard" that we still install by default (894110)...

Interesting! You sent the email starting this thread a mere 4 days
ago, two of those a weekend. You've not given it a chance to even go
to FESCo meeting for discussion. Did you send it in the same way to
the rest of the distros that depend, or are soon to depend on, systemd
now SuSE, Arch, Debian, Ubuntu etc giving them no chance to
discuss the impact before you unceremoniously tear a feature, for
some, out?

Ultimately I've long stopped using tcpwrappers (a decade or so ago in
fact) so it doesn't bother me what so ever but I know of a LOT of
people that use it, rightly or wrongly, extensively.

systemd is now, or soon will be, a core component of pretty much all
major and minor distributions out there and it's no longer just about
you Lennart and your thoughts of whether it's "Yuck!" or not, you are
now similar to the kernel and like the kernel you should have a proper
deprecation process that is not just what you, Kay and who ever the
main developers decide is cool or not at the time. You should give us
and distributions in general more than 4 days to deal with what lives
or not. Ultimately systemd is no longer in nappies and is all grown
up, while you are still it's father it's now a teenager and needs to
be somewhat independent of it's father, it has friends that now depend
on it and there's should be a central place where these architectural
changes and deprecation intentions are announced, discussed and in the
case of deprecation given more than 4 days before removal.


I'm not sure where this is coming from but Arch removed this 3 years ago 
and the original request of removal from upstream came from opensuse 
with Debian responding they will be keeping this around for a while ( it 
will be like 4 years in my gestimation for Debian to catch up with 
systemd integration anyway so this is hardly a pressing concern for them 
) so Lennart was being rather conservative of it's removal upstream 
atleast not without checking with us ( Fedora ) first since we were the 
remaining part responding of the "big distro's" to his "heads up" .


From broader view this boils down to how long should unmaintained core 
os components be kept around, which is something that should be hashed 
out among relevant upstreams in next plumbers session to establish a 
clear path forward and arguably upstreams should be responsible to make 
the decisions when things should be deprecated forcing downstream to 
either adapt new modern way's or maintain stuff downstream with 
themselves chose they do so instead of adapt.


By the way the kernel does not have a proper deprecation process which 
is accurately reflected in all the code that is bit-rotting there so 
it's not the holy grail of code maintenance as you let it out to be.


It lacks it's Boothby's to snip out the dead branches as much as we do 
here with us.


JBG


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Simo Sorce]

On Mon, 2014-03-24 at 21:22 +, Peter Robinson wrote:
> >> I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
> >> Fedora. There has been a request in systemd upstream to disable support
> >> for it by default, but I am not sure I want to do that unless we can
> >> maybe say goodbye to it for the big picture too.
> >
> > I have decided now to drop all support for tcpwrap from systemd, for the
> > next release. For those who believe that tcpd is really a good idea
> > (yuck!) not much is lost though, they can just plug in tcpd into
> > systemd, the way they did it with good old inetd, too, hence we are not
> > taking anything away there, we are pretty much compatible with what
> > inetd supported there (or actually: didn't support there).
> >
> > I am not going to file a feature for Fedora, to remove support for it
> > entirely across the whole distro. I still think dropping it is the right
> > thing to do, but I don't think it's a good use of my own time, to fight
> > this through... I'd be happy though if somebody else would pick this
> > up. Looking at the current FESCO members I am not entirely sure though
> > whether a proposal to disable libwrap would have a chance in the current
> > cycle though. (also, M. Miller kinda supported the proposal, which as
> > history tells us means he probably is _not_ going to vote for it in the
> > end...)
> >
> > It's a pity though that nobody in Fedora is actively working on getting
> > rid of legacy cruft. I really wished we had some people who oversee
> > deprecating things more proactively, figure out how to deprecate things,
> > write stub code to provide smooth transitions, write release notes and
> > so on. Being at the bleeding edge of things also means deciding that
> > some things really should go, from time to time... Besides deprecating
> > old cruft like libwrap, this would also mean removing all the old crap
> > from comps "standard" that we still install by default (894110)...
> 
> Interesting! You sent the email starting this thread a mere 4 days
> ago, two of those a weekend. You've not given it a chance to even go
> to FESCo meeting for discussion. Did you send it in the same way to
> the rest of the distros that depend, or are soon to depend on, systemd
> now SuSE, Arch, Debian, Ubuntu etc giving them no chance to
> discuss the impact before you unceremoniously tear a feature, for
> some, out?
> 
> Ultimately I've long stopped using tcpwrappers (a decade or so ago in
> fact) so it doesn't bother me what so ever but I know of a LOT of
> people that use it, rightly or wrongly, extensively.
> 
> systemd is now, or soon will be, a core component of pretty much all
> major and minor distributions out there and it's no longer just about
> you Lennart and your thoughts of whether it's "Yuck!" or not, you are
> now similar to the kernel and like the kernel you should have a proper
> deprecation process that is not just what you, Kay and who ever the
> main developers decide is cool or not at the time. You should give us
> and distributions in general more than 4 days to deal with what lives
> or not. Ultimately systemd is no longer in nappies and is all grown
> up, while you are still it's father it's now a teenager and needs to
> be somewhat independent of it's father, it has friends that now depend
> on it and there's should be a central place where these architectural
> changes and deprecation intentions are announced, discussed and in the
> case of deprecation given more than 4 days before removal.

+1

Simo,

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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Lennart Poettering]

On Mon, 24.03.14 21:22, Peter Robinson (pbrobin...@gmail.com) wrote:

> Interesting! You sent the email starting this thread a mere 4 days
> ago, two of those a weekend. You've not given it a chance to even go
> to FESCo meeting for discussion. Did you send it in the same way to
> the rest of the distros that depend, or are soon to depend on, systemd
> now SuSE, Arch, Debian, Ubuntu etc giving them no chance to
> discuss the impact before you unceremoniously tear a feature, for
> some, out?

I quickly got reports back from the other distros, and even reported it
back here...

I am not "tearing" the thing, I am just saying that I don't have the
time to work on it in the Fedora scale.

> systemd is now, or soon will be, a core component of pretty much all
> major and minor distributions out there and it's no longer just about
> you Lennart and your thoughts of whether it's "Yuck!" or not, you are
> now similar to the kernel and like the kernel you should have a proper
> deprecation process that is not just what you, Kay and who ever the
> main developers decide is cool or not at the time. You should give us
> and distributions in general more than 4 days to deal with what lives
> or not. Ultimately systemd is no longer in nappies and is all grown
> up, while you are still it's father it's now a teenager and needs to
> be somewhat independent of it's father, it has friends that now depend
> on it and there's should be a central place where these architectural
> changes and deprecation intentions are announced, discussed and in the
> case of deprecation given more than 4 days before removal.

We *did* get feedback from distros first, and we provide an alternative
to use tcpwrap with systemd even further on (via tcpd), so I really
don't see what you are upset about.

Lennart

-- 
Lennart Poettering, Red Hat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: PEP453 // ensurepip // pip

[Donald Stufft]

On Mar 24, 2014, at 5:38 AM, Robert Kuska  wrote:

> Hi Donald,
> 
> welcome to our mailing list.
> 
> - Original Message -
>> From: "Donald Stufft" 
>> To: python-de...@lists.fedoraproject.org
>> Sent: Friday, March 21, 2014 11:19:49 PM
>> Subject: PEP453 // ensurepip // pip
>> 
>> Hey there,
>> 
>> So I’m one of the authors of PEP453, the original implementor of ensurepip,
>> and
>> a pip maintainer. I know that pip (and other language level package managers)
>> have a sort of love/hate (sometimes more of one or the other!) relationship
>> with the downstream Linux packagers. I know that PEP453 also puts more focus
>> on this in general since it's now a recommendation for pip to be installed
>> if Python is.
>> 
>> So I'd like to say that If there are problems I'd like to help fix them.
>> Especially if there are problems with pip that make you nervous/upset/sad
>> with
> 
> I would say this one https://github.com/pypa/pip/issues/1351 is important for 
> us 
> as packagers. It makes me nervous/upset and sad altogether :-).

Awesome, well that’s on the list for 1.6 so that should be the next feature 
release
of pip.

> 
>> having it tied so closely to Python. Also generally about making less
>> headache
>> for distros where pip is involved (pip and the OS package manager stomping on
>> each other etc).
>> 
>> To start off this goal I've filed https://github.com/pypa/pip/issues/1668 to
>> figure out how pip can get our defaults to the point where most users will be
>> installing to ~/.local/ instead of the system location. If there's more
>> things
>> pip can do I'd love to know about them, or if ensurepip or the PEP453
>> processes
>> have something I can help with too :)
> 
> Nice, I have put my two cents in it.
> 
>> 
>> -
>> Donald Stufft
>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>> 
>> 
>> ___
>> python-devel mailing list
>> python-de...@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/python-devel
> 
> Thank you for bringing up this long-awaited and postponed issue for 
> discussion!
> 
> Regards,
> 
> Robert Kuska 
> -
> rkuska @ 
> #fedora-devel on freenode
> #brno #gulag #software-collections on brq.redhat


On the topic of re-wheeling (Sorry I just joined so I don’t have it in my 
history to reply to).

I’m assuming Fedora unbundles the stuff that pip bundles (sorry :/) and I’m 
guessing that
since the Rewheeling is going to pull in the system versions that it’s going to 
pull in a
copy of pip with those things unbundled. If that’s the case you’re going to 
need to install
those things into the virtualenv itself.

However I think that the copy of pip inside of a venv should keep stuff bundled 
if at all
possible. One of the reasons we did this was so that when using pip inside of a 
venv
we don’t make any assertions about what other things you can have installed. So 
for
example we depend on requests, we don’t want someone who is using an older (or 
newer!)
requests inside of their venv to be unable to install it because pip itself 
uses it. Also
another reason we did that is because if you uninstall one of those things and 
it breaks
pip you don’t really have a good way to unbreak it except destroy the venv or 
install it
manually. This is less of a concern for the system installed pip because you 
have yum
or whatever that can be used to fix it and y’all integrate things already to 
ensure compat :)


-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
python-devel mailing list
python-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 24.03.2014 22:22, schrieb Peter Robinson:
> Interesting! You sent the email starting this thread a mere 4 days
> ago, two of those a weekend. You've not given it a chance to even go
> to FESCo meeting for discussion. Did you send it in the same way to
> the rest of the distros that depend, or are soon to depend on, systemd
> now SuSE, Arch, Debian, Ubuntu etc giving them no chance to
> discuss the impact before you unceremoniously tear a feature, for
> some, out?

be careful with criticism or you get killfild by Lennart



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Peter Robinson]

>> I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
>> Fedora. There has been a request in systemd upstream to disable support
>> for it by default, but I am not sure I want to do that unless we can
>> maybe say goodbye to it for the big picture too.
>
> I have decided now to drop all support for tcpwrap from systemd, for the
> next release. For those who believe that tcpd is really a good idea
> (yuck!) not much is lost though, they can just plug in tcpd into
> systemd, the way they did it with good old inetd, too, hence we are not
> taking anything away there, we are pretty much compatible with what
> inetd supported there (or actually: didn't support there).
>
> I am not going to file a feature for Fedora, to remove support for it
> entirely across the whole distro. I still think dropping it is the right
> thing to do, but I don't think it's a good use of my own time, to fight
> this through... I'd be happy though if somebody else would pick this
> up. Looking at the current FESCO members I am not entirely sure though
> whether a proposal to disable libwrap would have a chance in the current
> cycle though. (also, M. Miller kinda supported the proposal, which as
> history tells us means he probably is _not_ going to vote for it in the
> end...)
>
> It's a pity though that nobody in Fedora is actively working on getting
> rid of legacy cruft. I really wished we had some people who oversee
> deprecating things more proactively, figure out how to deprecate things,
> write stub code to provide smooth transitions, write release notes and
> so on. Being at the bleeding edge of things also means deciding that
> some things really should go, from time to time... Besides deprecating
> old cruft like libwrap, this would also mean removing all the old crap
> from comps "standard" that we still install by default (894110)...

Interesting! You sent the email starting this thread a mere 4 days
ago, two of those a weekend. You've not given it a chance to even go
to FESCo meeting for discussion. Did you send it in the same way to
the rest of the distros that depend, or are soon to depend on, systemd
now SuSE, Arch, Debian, Ubuntu etc giving them no chance to
discuss the impact before you unceremoniously tear a feature, for
some, out?

Ultimately I've long stopped using tcpwrappers (a decade or so ago in
fact) so it doesn't bother me what so ever but I know of a LOT of
people that use it, rightly or wrongly, extensively.

systemd is now, or soon will be, a core component of pretty much all
major and minor distributions out there and it's no longer just about
you Lennart and your thoughts of whether it's "Yuck!" or not, you are
now similar to the kernel and like the kernel you should have a proper
deprecation process that is not just what you, Kay and who ever the
main developers decide is cool or not at the time. You should give us
and distributions in general more than 4 days to deal with what lives
or not. Ultimately systemd is no longer in nappies and is all grown
up, while you are still it's father it's now a teenager and needs to
be somewhat independent of it's father, it has friends that now depend
on it and there's should be a central place where these architectural
changes and deprecation intentions are announced, discussed and in the
case of deprecation given more than 4 days before removal.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 24.03.2014 21:51, schrieb Lennart Poettering:
> On Mon, 24.03.14 21:45, Reindl Harald (h.rei...@thelounge.net) wrote:
> 
>> and that is the problem with you attitude
> 
> Okeydokey, as you wish, you are now in my killfile

so what - why should i case about beeing in the killfile
of people which can't stand criticism - other than you
i can and be not that thin-skinned to need a killfile



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Lennart Poettering]

On Mon, 24.03.14 21:45, Reindl Harald (h.rei...@thelounge.net) wrote:

> and that is the problem with you attitude

Okeydokey, as you wish, you are now in my killfile.

Lennart

-- 
Lennart Poettering, Red Hat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Bill Nottingham]

Lennart Poettering (mzerq...@0pointer.de) said: 
> this through... I'd be happy though if somebody else would pick this
> up. Looking at the current FESCO members I am not entirely sure though
> whether a proposal to disable libwrap would have a chance in the current
> cycle though. (also, M. Miller kinda supported the proposal, which as
> history tells us means he probably is _not_ going to vote for it in the
> end...)
> 
> It's a pity though that nobody in Fedora is actively working on getting
> rid of legacy cruft. I really wished we had some people who oversee
> deprecating things more proactively, figure out how to deprecate things,
> write stub code to provide smooth transitions, write release notes and
> so on.

Well, if you're going to passive-agressively shittalk anyone who tries to do
so in a way you disagree with (as you do above), I'm not sure why anyone
would willingly take you up on that offer. 

In any case, yes, concentrating on how to deprecate, providing smooth
transitions, release notes, etc. are all important things to think about
when discussing removing a feature, and framing the discussions in terms of
"it's crap code, it doesn't really do what people are trying to use it for,
no one should use it" accomplishes none of those items.

Bill
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 24.03.2014 21:32, schrieb Lennart Poettering:
> On Mon, 24.03.14 20:59, Reindl Harald (h.rei...@thelounge.net) wrote:
> 
>> Am 24.03.2014 20:27, schrieb Jóhann B. Guðmundsson:
>>> But certain people seem to rather want to drown Fedora in bureaucracy and 
>>> vague future proposals 
>>> and working groups instead of doing what needs to be done.
>>
>> no, certain people want to do something *useful* with their sytems and 
>> precious
>> time and not remove things and adopt changes with no good reason
>>
>> if you want to do worthful things go ahead as your QA job and clean systemd
>> especially the first one of the following list, they all hurt over months
>> and #1072368 comes back with the last systemd releases in Rawhide
> 
> You know, Harald, with your constant complaining you are just ensuring
> that people will ignore whatever you say

no more ignore is hardly possible
systemd in F19 was perfect
systemd in F20 is horrible from the view of a sysadmin

> For example, when I see a bug
> reported by you I put it at the very end of my TODO list, because I
> really don't want to deal with the constant complaints we are getting
> from you. 

if you would do your job better i would not have to complain

> You know, you are not dumb, and the stuff you post is often quite
> relevant to our work, but as long as you post this stuff the way you do
> the only thing you will achieve quickly is that we'll ignore what you
> say, and that you get moderated again on mailing lists like systemd-devel like
> you already got twice. That is a loss, since there are things in what
> you say that I find quite relevant. But jeesus, it's so frickin annoying
> to deal with you and your writings, you know that?

if it would not feel systemd upstream does not care what
happens left and right maybe the feedback would differnt

did you ever consider that?

>> https://bugzilla.redhat.com/show_bug.cgi?id=1072368
>> https://bugzilla.redhat.com/show_bug.cgi?id=1010572
>> https://bugzilla.redhat.com/show_bug.cgi?id=626477
>> https://bugzilla.redhat.com/show_bug.cgi?id=1047148
>> https://bugzilla.redhat.com/show_bug.cgi?id=1024379
> 
> Quite frankly, these all are fixed upstream

upstream does not help in case of Fedora

if the number one downstream distribution can't manage them
upstream should consider that thigs are not working properly

> or relatively harmless

define harmless

* frozen terminals in case of reboot remote servers is not harmless
* burry relevant messages in a permanent flood is not harmless

> things like where you'd prefer us to generate less log messages. Making
> such a fuss about these things is way over the top. Not a single one of
> these you posted is about actual functionality bugs not getting fixed
> upstream.

if you ever would have managed 10, 20, 30 servers where you do
things like distribute-command "cat /var/log/messages" and expect
to not get burried by irrelevant notices your point of view would
be different

the problem is that you insist in journald and filtering while
you refuse to understand larger setups

> Please try to understand that things like this don't get the highest
> priority on our TODO list. Also, you don't have the privilige of being
> entitled to get your own private bugs fixed immeidately, really

i understand that, but you need to understand the reaction because
in fact i do not take anybody serious not face things like
https://bugzilla.redhat.com/show_bug.cgi?id=1010572 after the
first boot - why? because that means the person never looks at
his logs, serious sysadmins do

> Yes, it would be nice if we fix them, but open source is really not 
> just about you demanding things and we giving it to you

you don't get the point

systemd in F19 is working perfect
systemd in F20 is horrible

i do not demand to introduce all that things which are the reason
for now i not consider to upgrade any production machine to F20

> It's a two way street, so instead of all the negative energy you spend 
> bitching about things, how about actually doing something really 
> constructive, 
> figuring out a patch or so, for the relevant things, and submitting that?

and that is the problem with you attitude

* making changes left and right
* not care about the impact of users
* demand users to chew the reuslt or fix it themslef




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Let's close the remaining merge reviews

[Cole Robinson]

Hi all,

In case readers don't know, this page describes what a merge review is:

https://fedoraproject.org/wiki/Merge_Reviews

In short: when fedora core and extras merged, a Package Review was opened for
every package in core. The idea was that every core package would be reviewed
to ensure it met with the extras packaging guidelines. It has never blocked
anything, it's just a best effort 'we should do this one day'.

Since 1 year ago (2013-03-24), 8 merge reviews have been closed as either
RAWHIDE, CURRENTRELEASE, or NEXTRELEASE.

There's currently 126 open merge reviews. Of those, since 2013-03-24, 8 have
received new comments. The breakdown is:

Not related to any progress on the merge review (account closings mostly):
226640, 226497

Related to the merge review but not indicative of any progress being made
(pings, 'what is this bug for', ...): 225755, 226425

Varying amounts of attempted review (4 bugs): 225989, 226209, 225708, 226140

So in the past 12 months, there's been some positive activity on 12 merge
reviews. But 116 have sat totally dormant. Many have not been touched for over
five years.

Keeping these reviews open has a real cost:

- Developer confusion in the form of 'what is this bug, why should I care'
(there's lots of that in the comments of these reviews from over the years).

- Reviewer confusion when they go to this page:
http://fedoraproject.org/PackageReviewStatus/I experienced this when I
first went to the page, and had to go read up on it.

- Reviewer energy, for those folks that make a valiant attempt only for
repeated pings to go unanswered. And yet I don't blame maintainers for not
caring much about a merge review. And they are easy to ignore: personally I
don't track bugs assigned to me so much as I track bugs belonging to the
packages I care about, so I'm sure many maintainers don't even know these open
bugs exist, since the component is 'Package Review'.

- Bugzilla search times on open bugs (okay that's probably a stretch :) )

I suggest we just close all these bugs. I'm happy to do the autoclosing, add
myself to the CC, and handle any follow up comments. I propose a message like
this:

"We've decided to close all merge reviews:



If there is any in-progress work lingering, or if anyone is interested in
completing this review, please reopen this bug and reassign the bug to the
actual component."

An alternative would be to reassign every open merge review to the component
in question, and let maintainers handle it as they like.

Thoughts?

Thanks,
Cole
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Dan Mashal]

On Sat, Mar 22, 2014 at 7:29 PM, Kevin Kofler  wrote:
> Yeah, this idea of having to install GNOME first to be able to install the
> desktop you actually want is totally wacky, and if that is really what we
> recommend to our users, they will run to other distributions (that actually
> support the desktop environment they care about with a dedicated installable
> live image) in droves. Really, almost all users are NOT going to put up with
> this. You need to be really determined to want to run Fedora to jump through
> such ridiculous hoops, most people will just look elsewhere.
>
> And this is really true independently of the desktop environment we are
> talking about (except maybe things such as WM-only setups whose users are
> used to tweaking things by hand anyway).


You always make sense. But nobody listens.

Who the hell wants to install Gnome to install MATE or KDE or XFCE?

Dan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Lennart Poettering]

On Mon, 24.03.14 20:59, Reindl Harald (h.rei...@thelounge.net) wrote:

> Am 24.03.2014 20:27, schrieb Jóhann B. Guðmundsson:
> > But certain people seem to rather want to drown Fedora in bureaucracy and 
> > vague future proposals 
> > and working groups instead of doing what needs to be done.
> 
> no, certain people want to do something *useful* with their sytems and 
> precious
> time and not remove things and adopt changes with no good reason
> 
> if you want to do worthful things go ahead as your QA job and clean systemd
> especially the first one of the following list, they all hurt over months
> and #1072368 comes back with the last systemd releases in Rawhide

You know, Harald, with your constant complaining you are just ensuring
that people will ignore whatever you say. For example, when I see a bug
reported by you I put it at the very end of my TODO list, because I
really don't want to deal with the constant complaints we are getting
from you. 

You know, you are not dumb, and the stuff you post is often quite
relevant to our work, but as long as you post this stuff the way you do
the only thing you will achieve quickly is that we'll ignore what you
say, and that you get moderated again on mailing lists like systemd-devel like
you already got twice. That is a loss, since there are things in what
you say that I find quite relevant. But jeesus, it's so frickin annoying
to deal with you and your writings, you know that?

> https://bugzilla.redhat.com/show_bug.cgi?id=1072368
> https://bugzilla.redhat.com/show_bug.cgi?id=1010572
> https://bugzilla.redhat.com/show_bug.cgi?id=626477
> https://bugzilla.redhat.com/show_bug.cgi?id=1047148
> https://bugzilla.redhat.com/show_bug.cgi?id=1024379

Quite frankly, these all are fixed upstream, or relatively harmless
things like where you'd prefer us to generate less log messages. Making
such a fuss about these things is way over the top. Not a single one of
these you posted is about actual functionality bugs not getting fixed
upstream.

Please try to understand that things like this don't get the highest
priority on our TODO list. Also, you don't have the privilige of being
entitled to get your own private bugs fixed immeidately, really. Yes, it
would be nice if we fix them, but open source is really not just about
you demanding things and we giving it to you. It's a two way street, so
instead of all the negative energy you spend bitching about things, how
about actually doing something really constructive, figuring out a patch
or so, for the relevant things, and submitting that?

Lennart

-- 
Lennart Poettering, Red Hat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Dan Mashal]

On Wed, Mar 19, 2014 at 4:55 AM, Josh Boyer  wrote:
> Any other DE that wants to meet the requirements for Workstation is similarly
> welcome.

So if we meet the "requirements" exactly what happens?

As far as I understand, all MATE would have to do is use gdm as the
display manager. Is that correct?

Dan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Agenda for Env-and-Stacks WG meeting (2014-03-25)

[Marcela Mašláňová]

WG meeting will be at 16:00 UTC, 17:00 Central Europe, 12:00 (noon) 
Boston, 9:00 San Francisco, 1:00 Tokyo in #fedora-meeting on Freenode.


== Topic ==
* chair(wo)man - I'm on different meeting, could someone handle it?
* work more on Open Questions:
https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft%29
 * obs-signd is probably the easier to deploy -> add ad proposed solution?
 * conflicts within Playground repo -> discussed a little on mailing 
list, but no final proposal
 * 1 Big repo vs multiple small ones -> discussed on mailing list, no 
consensus reached


See you,
Marcela
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Miloslav Trmač]

2014-03-23 3:48 GMT+01:00 Kevin Kofler :

> Miloslav Trmač wrote:
> > When we say that there should be "high bar" for becoming a Fedora
> Product,
> > that means that there should be few of them,
>
> I see this repeated over and over by several people. This strikes me as
> quite the opposite of being inclusive.
>

(These are my personal opinions, official FESCo position is what has been
voted on in the meetings, and so far does not go into such detail AFAIK.)

I don't think that's the case.  Fedora is obviously open to including
individual packages and large multi-package projects that are very far from
the mainstream.  "Fedora Product"-like efforts can, and do, happen outside
of the Fedora umbrella--the major desktop environments to date have been a
typical example--and the results of such efforts can, and are, included in
the Fedora universe, as individual packages, comps groups, or spins.

Fedora Products involve *bidirectional* coordination with the Fedora
universe: not only "which version of upstream's project should we package
so that we fit Fedora's schedule", but also the opposite, and "we need to
change $this so that that-other-Fedora-product can do something useful".
Such coordination is much more practical if there are only a few Products,
not dozens of them, if they have a fairly large number of contributors that
watch what is happening around the other Products, and if they have
consistent requirements, which is easiest to achieve by minimizing the
overlap = potential for conflicts between Products.  (What would we do with
three desktop Products, one wanting X, one Mir, one Wayland, or one of them
asking for bionic libc?)

IMHO, ALL the current Spins should automatically become Products (or the
> whole Products idea dropped in favor of the existing Spins system that just
> worked).
>

I don't think most spins *want* to become Products, with voting bodies and
bi-weekly liaison discussions at FESCo; as far as packaging an interesting
collection of upstream software, such overhead (useful for
coordinating *specifically
Fedora-targeted* development efforts) isn't helpful.

I don't think any Fedora contributor should need to sign up to work on a
full-fledged Product in order to have their voice heard, their work
included, the work judged on its merits, or, to be more specific to KDE, to
have the possibility to be release-blocking or to be visibly featured on
the "Get Fedora" pages; for all I know, it might well make sense to feature
some kind of KDE spin more visibly than the Fedora Server product.
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 24.03.2014 20:30, schrieb Jóhann B. Guðmundsson:
>> Being at the bleeding edge of things also means deciding that
>> some things really should go, from time to time... Besides deprecating
>> old cruft like libwrap, this would also mean removing all the old crap
>> from comps "standard" that we still install by default (894110)...
> 
> For the record Fedora is not a bleeding edge distro anymore or first in 
> anything

maybe some people should consider the difference between "leading" and 
"bleeding"

smart: leading if things are ready
dumb:  bleeding for any price

if you think people are happily bleeding all the time you need a lot to learn
people accept bleeding for good reasons from time to time but not always with
no real benefit and if you want a distribution where users always bleed go
ahead but don't try to damage the way Fedora goes to become a serious
useable distribution over the time

if users bleed to much they dirft away before they die



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 24.03.2014 20:27, schrieb Jóhann B. Guðmundsson:
> But certain people seem to rather want to drown Fedora in bureaucracy and 
> vague future proposals 
> and working groups instead of doing what needs to be done.

no, certain people want to do something *useful* with their sytems and precious
time and not remove things and adopt changes with no good reason

if you want to do worthful things go ahead as your QA job and clean systemd
especially the first one of the following list, they all hurt over months
and #1072368 comes back with the last systemd releases in Rawhide

https://bugzilla.redhat.com/show_bug.cgi?id=1072368
https://bugzilla.redhat.com/show_bug.cgi?id=1010572
https://bugzilla.redhat.com/show_bug.cgi?id=626477
https://bugzilla.redhat.com/show_bug.cgi?id=1047148
https://bugzilla.redhat.com/show_bug.cgi?id=1024379




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: AppStream Logs and False Positives

[Richard Hughes]

On 24 March 2014 19:01, Jerry James  wrote:
> Thank you, I appreciate the offer.  However, I think I'm going to use my
> fedorapeople.org space for this purpose.  Hopefully it won't be needed for
> long, anyway (/me crosses fingers).

Yes, I think fedorapeople.org is fine for this; like I said it's
immediately mirrored onto the mirror network. When you've got a build
with the new AppData file let me know and I'll take a screenshot of
what it looks like in gnome-software so you can show upstream.

Richard.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Help understanding Anaconda source - walk through needed.

[Matthew Garrett]

On Mon, Mar 24, 2014 at 07:21:51PM +, Aaron Gray wrote:
> The HP Dl140 G3 has MCA based graphics. F20 seems to be mainly fixed
> apart from MCA based Anaconda, which gets the resolution wrong, the
> screen being too small for the Anaconda graphics.
> VESA setup mode works fine however.

Ah. You mean MGA, not MCA. It's entirely possible that there's a bug in 
the mgag200 driver that's resulting in a failure to get the correct 
EDID, but that's a kernel bug rather than an anaconda one.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Jóhann B. Guðmundsson]

On 03/24/2014 06:18 PM, Lennart Poettering wrote:

It's a pity though that nobody in Fedora is actively working on getting
rid of legacy cruft. I really wished we had some people who oversee
deprecating things more proactively, figure out how to deprecate things,
write stub code to provide smooth transitions, write release notes and
so on.


Those people get tired having to constantly fight things through the 
bureaucracy and downstream distribution and it's clone too.



  Being at the bleeding edge of things also means deciding that
some things really should go, from time to time... Besides deprecating
old cruft like libwrap, this would also mean removing all the old crap
from comps "standard" that we still install by default (894110)...


For the record Fedora is not a bleeding edge distro anymore or first in 
anything.


The distribution that is and has been for quite sometime is Arch but I'm 
pretty sure you already knew that.


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Jóhann B. Guðmundsson]

On 03/24/2014 06:50 PM, Stephen John Smoogen wrote:




On 24 March 2014 12:18, Lennart Poettering > wrote:



It's a pity though that nobody in Fedora is actively working on
getting
rid of legacy cruft. I really wished we had some people who oversee
deprecating things more proactively, figure out how to deprecate
things,
write stub code to provide smooth transitions, write release notes and
so on. Being at the bleeding edge of things also means deciding that
some things really should go, from time to time... Besides deprecating
old cruft like libwrap, this would also mean removing all the old crap
from comps "standard" that we still install by default (894110)...


Old cruft is in the OS because for some set of people it is useful, 
and it is very hard to design around stuff people think should be 
there because it was there before. The only way to get around that is 
to build something completely new with a different 'brand' which does 
not have expectations from people already there. I think you would 
have a better chance starting from a ground zero and putting new wine 
in a new winesack versus trying to put it in an old one and then 
wondering why it keeps bursting.



It has been tried and tested and the people that suggested that ( me in 
particular in relation with the serverWG ) got burned on the stakes, 
accused wanting to "fork" Fedora for suggesting just that as in cleaning 
and implementing the output from that work in a separated repository's 
under a new brand until we were confident enough to with that effort and 
drop replace Fedora as we know it with that effort.


The fact is there is a lot of legacy cruff we should be removing as well 
as doing other necessary cleanups to make Fedora agile again for the 
upcoming changes in the IT industry landscape.


But certain people seem to rather want to drown Fedora in bureaucracy 
and vague future proposals and working groups instead of doing what 
needs to be done.


JBG
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Help understanding Anaconda source - walk through needed.

[Aaron Gray]

The HP Dl140 G3 has MCA based graphics. F20 seems to be mainly fixed
apart from MCA based Anaconda, which gets the resolution wrong, the
screen being too small for the Anaconda graphics.
VESA setup mode works fine however.

On 17 March 2014 22:02, Adam Williamson  wrote:
> On Mon, 2014-03-17 at 09:39 -0400, Adam Jackson wrote:
>> On Wed, 2014-03-12 at 20:07 +, Aaron Gray wrote:
>>
>> > I am looking for someone to walk me through the Anaconda source as I
>> > need to understand it and cannot find where its 'main' is and how it
>> > launches X Windows as I need to work out why the main installer is not
>> > working on my HP D140 G3's with MCA video controllers.
>>
>> Anaconda doesn't really "configure" X before running it, it just relies
>> on X's autoconfiguration logic to Do The Right Thing.  I'm hoping you
>> don't really mean MCA to mean Micro Channel Architecture there, one I
>> didn't think anybody besides IBM was foolish enough to use that and two
>> Fedora's X hasn't supported buses older than PCI for a couple of
>> releases now.
>>
>> Whatever problem you're having with graphics at install time, you will
>> almost certainly also have after installed; it's usually easier to debug
>> by going ahead and installing in text mode and then debugging graphics
>> once installed.
>
> I think the system he's referring to is this one:
>
> http://reviews.cnet.com/soho-servers/hp-proliant-dl140/4507-3125_7-30620088.html
>
> Graphics Controller
>
> Type Integrated
> Interface Type PCI
> Graphics Processor / Vendor ATI RAGE XL
> Video Memory 8 MB / 8 MB (max) SDRAM
> Video Interfaces VGA
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

proactively deprecating things that should be -- base design wg [was Re: Maybe it's time to get rid of tcpwrappers/tcpd?]

[Matthew Miller]

On Mon, Mar 24, 2014 at 07:18:58PM +0100, Lennart Poettering wrote:
> I am not going to file a feature for Fedora, to remove support for it
> entirely across the whole distro. I still think dropping it is the right
> thing to do, but I don't think it's a good use of my own time, to fight
> this through... I'd be happy though if somebody else would pick this
> up. Looking at the current FESCO members I am not entirely sure though
> whether a proposal to disable libwrap would have a chance in the current
> cycle though. (also, M. Miller kinda supported the proposal, which as
> history tells us means he probably is _not_ going to vote for it in the
> end...)

I guess I wasn't clear enough with you last time around. I thought I was
more clear this time, but I guess I'll repeat: demanding "instant progress
or nothing" doesn't get you as far as breaking things down into manageable
steps and executing on each one. Sometimes, we need to bite the bullet and
make a big painful cut, but usually we don't. When it's something like this,
(or like the default MTA, or like logging -- where there's no particular
urgency to make the change and there are reasonable Fedora contributors with
reservations, I'm absolutely in favor of phased approach.


> It's a pity though that nobody in Fedora is actively working on getting
> rid of legacy cruft. I really wished we had some people who oversee
> deprecating things more proactively, figure out how to deprecate things,
> write stub code to provide smooth transitions, write release notes and
> so on. Being at the bleeding edge of things also means deciding that
> some things really should go, from time to time... 

I absolutely agree. This should be an important fuction of the Base Design
working group. Before that, we also have a "Minimal Core" SIG with some
interest but not much activity (that last may somewhat be my fault, since I
kicked it off but my attention wandered).

>Besides deprecating
> old cruft like libwrap, this would also mean removing all the old crap
> from comps "standard" that we still install by default (894110)...

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

There wasn't previously a great framework for discussing this kind of thing.
I hope that we do have that now. And just as you don't have to be a voting
WG member to contribute to a product SIG, it would be helpful for anyone
interested in this to provide constructive feedback to the Base Design
group.

-- 
Matthew Miller--   Fedora Project--
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: AppStream Logs and False Positives

[Jerry James]

Hi Corey,

On Mon, Mar 24, 2014 at 12:11 PM, Corey Sheldon wrote:

> I'd be willing to host some space on a time-based setup as my server and
> home system are not always on (running live-static blogs) but hit me up if
> need be also I run fc20 sec xfce x86 if you need help with outreach or
> testing on other WMs
>

Thank you, I appreciate the offer.  However, I think I'm going to use my
fedorapeople.org space for this purpose.  Hopefully it won't be needed for
long, anyway (/me crosses fingers).
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Stephen John Smoogen]

On 24 March 2014 12:18, Lennart Poettering  wrote:

>
>

> It's a pity though that nobody in Fedora is actively working on getting
> rid of legacy cruft. I really wished we had some people who oversee
> deprecating things more proactively, figure out how to deprecate things,
> write stub code to provide smooth transitions, write release notes and
> so on. Being at the bleeding edge of things also means deciding that
> some things really should go, from time to time... Besides deprecating
> old cruft like libwrap, this would also mean removing all the old crap
> from comps "standard" that we still install by default (894110)...
>
>
Old cruft is in the OS because for some set of people it is useful, and it
is very hard to design around stuff people think should be there because it
was there before. The only way to get around that is to build something
completely new with a different 'brand' which does not have expectations
from people already there. I think you would have a better chance starting
from a ground zero and putting new wine in a new winesack versus trying to
put it in an old one and then wondering why it keeps bursting.

-- 
Stephen J Smoogen.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Lennart Poettering]

On Thu, 20.03.14 18:34, Lennart Poettering (mzerq...@0pointer.de) wrote:

> Heya!
> 
> I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
> Fedora. There has been a request in systemd upstream to disable support
> for it by default, but I am not sure I want to do that unless we can
> maybe say goodbye to it for the big picture too.

I have decided now to drop all support for tcpwrap from systemd, for the
next release. For those who believe that tcpd is really a good idea
(yuck!) not much is lost though, they can just plug in tcpd into
systemd, the way they did it with good old inetd, too, hence we are not
taking anything away there, we are pretty much compatible with what
inetd supported there (or actually: didn't support there).

I am not going to file a feature for Fedora, to remove support for it
entirely across the whole distro. I still think dropping it is the right
thing to do, but I don't think it's a good use of my own time, to fight
this through... I'd be happy though if somebody else would pick this
up. Looking at the current FESCO members I am not entirely sure though
whether a proposal to disable libwrap would have a chance in the current
cycle though. (also, M. Miller kinda supported the proposal, which as
history tells us means he probably is _not_ going to vote for it in the
end...)

It's a pity though that nobody in Fedora is actively working on getting
rid of legacy cruft. I really wished we had some people who oversee
deprecating things more proactively, figure out how to deprecate things,
write stub code to provide smooth transitions, write release notes and
so on. Being at the bleeding edge of things also means deciding that
some things really should go, from time to time... Besides deprecating
old cruft like libwrap, this would also mean removing all the old crap
from comps "standard" that we still install by default (894110)...

Lennart

-- 
Lennart Poettering, Red Hat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: AppStream Logs and False Positives

[Corey Sheldon]

I'd be willing to host some space on a time-based setup as my server and
home system are not always on (running live-static blogs) but hit me up if
need be also I run fc20 sec xfce x86 if you need help with outreach or
testing on other WMs


Corey W Sheldon
Owner, 1st Class Mobile Shine
310.909.7672
www.facebook.com/1stclassmobileshine


On Mon, Mar 24, 2014 at 2:06 PM, Jerry James  wrote:

> On Mon, Mar 24, 2014 at 11:54 AM, Richard Hughes wrote:
>
>> Are you installing them with the package? I guess file:// could make
>> sense, so if that's what you're doing can you file a bug in
>> https://github.com/hughsie/appstream-glib/tree/master/libappstream-glib
>> please and we'll discuss there. Generally I think screenshots should
>> be available on some remote server (which is only accessed when
>> building metadata, not by all clients) as they tend to be sizeable and
>> not particularly useful if you've got an app already installed.
>
>
> Agreed.  I really only need this to solve a chicken and egg problem.  I
> want to convince upstream to adopt the AppData file that I've written for
> them.  It would be helpful to my argument if I could show them what their
> app would look like in gnome-software.  But, since upstream hasn't posted
> any screenshots (that I can find), I need to do something else to
> demonstrate to them what this would gain, hence the question.
>
> I can probably find web space somewhere to upload the screenshots I've
> taken, but it seems weird for me to be hosting their screenshots.  Still,
> that's probably what I should do until [1] I can get upstream to do the
> hosting.
>
> Footnotes:
> [1] He says optimistically.
> --
> Jerry James
> http://www.jamezone.org/
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: AppStream Logs and False Positives

[Jerry James]

On Mon, Mar 24, 2014 at 11:54 AM, Richard Hughes wrote:

> Are you installing them with the package? I guess file:// could make
> sense, so if that's what you're doing can you file a bug in
> https://github.com/hughsie/appstream-glib/tree/master/libappstream-glib
> please and we'll discuss there. Generally I think screenshots should
> be available on some remote server (which is only accessed when
> building metadata, not by all clients) as they tend to be sizeable and
> not particularly useful if you've got an app already installed.


Agreed.  I really only need this to solve a chicken and egg problem.  I
want to convince upstream to adopt the AppData file that I've written for
them.  It would be helpful to my argument if I could show them what their
app would look like in gnome-software.  But, since upstream hasn't posted
any screenshots (that I can find), I need to do something else to
demonstrate to them what this would gain, hence the question.

I can probably find web space somewhere to upload the screenshots I've
taken, but it seems weird for me to be hosting their screenshots.  Still,
that's probably what I should do until [1] I can get upstream to do the
hosting.

Footnotes:
[1] He says optimistically.
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: AppStream Logs and False Positives

[Richard Hughes]

On 24 March 2014 17:15, Jerry James  wrote:
> Am I taking a fundamentally wrong approach, or does something in the appdata
> stack need to be taught about file:// URLs?

Are you installing them with the package? I guess file:// could make
sense, so if that's what you're doing can you file a bug in
https://github.com/hughsie/appstream-glib/tree/master/libappstream-glib
please and we'll discuss there. Generally I think screenshots should
be available on some remote server (which is only accessed when
building metadata, not by all clients) as they tend to be sizeable and
not particularly useful if you've got an app already installed.

Richard.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Request for comments regarding default configuration of pam_abl module

[Corey Sheldon]

My personal take is for desktop (normal end-user) that it stays as is or as
a option in an advanced options setting and in the server-land to make the
added DoS environment default as any of us in that realm should know not
only about to determine our environment's needs but how to adjust

Corey W Sheldon
Owner, 1st Class Mobile Shine
310.909.7672
www.facebook.com/1stclassmobileshine


On Mon, Mar 24, 2014 at 12:57 PM, Kevin Fenzi  wrote:

> On Sun, 23 Mar 2014 23:46:15 -0600
> Eric Smith  wrote:
>
> > In bug #1079767, it is requested that the default configuration for
> > pam_abl be changed such that multiple root login failures from a
> > network host will (temporarily) blacklist that host.  The existing
> > default configuration deliberately does not do that, due to potential
> > for a Denial of Service. For example, in a classroom or lab, students
> > might try to log into a server as root, and failures could prevent
> > the instruction from being able to do so from the same machines in
> > the lab.  Another scenario would be a miscreant breaking into one
> > machine on a network, that happens to be used to ssh into another
> > machine on the network, and getting that first machine blacklisted.
> >
> > I understand the motivation to blacklist malicious hosts that try
> > dictionary attacks against root, but I don't like having the default
> > configuration susceptible to a DoS.  My feeling is that the default
> > configuration provides some value, but that the system administrator
> > should make the choice as to whether to tighten the rules and
> > potentially have a DoS issue.
> >
> > I'm interested in hearing in opinions of other developers, before
> > making a decision about the proposed change.
>
> I think it's pretty common practice to use a 'bastion host' to gateway
> into other servers that aren't directly reachable on the internet.
>
> Not sure if that use case is enough to sway the default however. You
> could say that people setting up a bastion host should be changing the
> default config for their setup rather than everyone else changing
> default for the bastion host case.
>
> kevin
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: AppStream Logs and False Positives

[Jerry James]

On Wed, Mar 19, 2014 at 9:33 AM, Richard Hughes  wrote:

> Quite a few people have asked me how the AppStream distro metadata is
> actually generated for their package. Since F20 we're also doing
> things like supply missing AppData files for some key apps, and
> replacing some upstream screenshots on others. In order to make this
> more transparent, I'm going to be uploading the logs of each
> generation run to https://github.com/hughsie/createrepo_as_logs -- If
> you've got a few minutes I'd appreciate you finding your application
> there and checking for any warnings or errors, and perhaps forwarding
> any findings to upstream. Although over 10% of applications in rawhide
> ship AppData, that means a huge chunk don't and also quite a few
> upstreams don't even have things like translated desktop files.
>

I've got an application with a valid desktop file for which I attempted to
write an appdata file.  I couldn't find any screenshots online, so I took
some of my own and installed them with the application.  The log message
for this application says:

Failed to load screenshot file://: Downloading failed: Cannot resolve
hostname

Am I taking a fundamentally wrong approach, or does something in the
appdata stack need to be taught about file:// URLs?

Thanks,
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Request for comments regarding default configuration of pam_abl module

[Kevin Fenzi]

On Sun, 23 Mar 2014 23:46:15 -0600
Eric Smith  wrote:

> In bug #1079767, it is requested that the default configuration for
> pam_abl be changed such that multiple root login failures from a
> network host will (temporarily) blacklist that host.  The existing
> default configuration deliberately does not do that, due to potential
> for a Denial of Service. For example, in a classroom or lab, students
> might try to log into a server as root, and failures could prevent
> the instruction from being able to do so from the same machines in
> the lab.  Another scenario would be a miscreant breaking into one
> machine on a network, that happens to be used to ssh into another
> machine on the network, and getting that first machine blacklisted.
> 
> I understand the motivation to blacklist malicious hosts that try
> dictionary attacks against root, but I don't like having the default
> configuration susceptible to a DoS.  My feeling is that the default
> configuration provides some value, but that the system administrator
> should make the choice as to whether to tighten the rules and
> potentially have a DoS issue.
> 
> I'm interested in hearing in opinions of other developers, before
> making a decision about the proposed change.

I think it's pretty common practice to use a 'bastion host' to gateway
into other servers that aren't directly reachable on the internet. 

Not sure if that use case is enough to sway the default however. You
could say that people setting up a bastion host should be changing the
default config for their setup rather than everyone else changing
default for the bastion host case. 

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Java 8

[Peter Robinson]

On Mon, Mar 24, 2014 at 3:41 PM, Mikolaj Izdebski  wrote:
> On 03/22/2014 06:15 AM, Miloslav Trmač wrote:
>> Given the known large number of failures (OptionalJavadocs says "80% build
>> failure rate" without saying that all are JavaDoc-related), we really
>> should do a mass rebuild to identify which packages fail to build *and* to
>> file bugs soonish, instead of waiting for a Fedora-wide mass rebuild and
>> then scrambling to fix dozens/hundreds of build failures in to avoid
>> slipping the schedule.  We don't necessarily need an official one, perhaps
>> only in a never-to-be-merged side tag (or even scratch builds?)
>
> Agreed.
>
> To do a rebuild in Koji Java 8 must land in there first.  That can could
> be a separate tag, but rel-eng is quite reluctant to provide them.

java 8 is already in the main repos and had been there since F-19.
It's just not providing things like java-devel and hence isn't used by
default in the build process.

> Copr could be a better place to do the rebuild.  One big advantage is
> that it doesn't use any ARM builders, but on the other hand it has quite
> limited capacity (AFAIK 10 builders only).

That's not an advantage, building ARM packages is a requirement of
something in primary architecture. Also you can't tag copr builds in
Fedora. You need to use a koji f21 side tag.

> Besides that, there is already one approved change [1] which requires
> rebuilding most of Java packages.  We didn't do a mass rebuild for it
> yet because we wanted to sync with Java 8 rebuild.

Well there will also be a mass rebuild in general for gcc 4.9 so you
should coordinate with rel-eng to minimise builds in general.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Java 8

[Mikolaj Izdebski]

On 03/24/2014 04:49 PM, Peter Robinson wrote:
> On Mon, Mar 24, 2014 at 3:41 PM, Mikolaj Izdebski  wrote:
>> On 03/22/2014 06:15 AM, Miloslav Trmač wrote:
>>> Given the known large number of failures (OptionalJavadocs says "80% build
>>> failure rate" without saying that all are JavaDoc-related), we really
>>> should do a mass rebuild to identify which packages fail to build *and* to
>>> file bugs soonish, instead of waiting for a Fedora-wide mass rebuild and
>>> then scrambling to fix dozens/hundreds of build failures in to avoid
>>> slipping the schedule.  We don't necessarily need an official one, perhaps
>>> only in a never-to-be-merged side tag (or even scratch builds?)
>>
>> Agreed.
>>
>> To do a rebuild in Koji Java 8 must land in there first.  That can could
>> be a separate tag, but rel-eng is quite reluctant to provide them.
> 
> java 8 is already in the main repos and had been there since F-19.
> It's just not providing things like java-devel and hence isn't used by
> default in the build process.

That's exactly the problem.  We need to use a modified version of
java-1.8.0-openjdk with extra provides and adjusted priorities for
alternatives.  Blocking java-1.7.0-oepnjdk may also be required.  This
makes it impossible to scratch-build Java packages using f21-build
target in current state.

> 
>> Copr could be a better place to do the rebuild.  One big advantage is
>> that it doesn't use any ARM builders, but on the other hand it has quite
>> limited capacity (AFAIK 10 builders only).
> 
> That's not an advantage, building ARM packages is a requirement of
> something in primary architecture. Also you can't tag copr builds in
> Fedora. You need to use a koji f21 side tag.

I was talking talking about doing scratch builds to identify packages
failing to build with Java 8.  Java 8 change does *not* require mass
rebuild in Fedora.  Great majority of packages will work with Java 8
with no change.

> 
>> Besides that, there is already one approved change [1] which requires
>> rebuilding most of Java packages.  We didn't do a mass rebuild for it
>> yet because we wanted to sync with Java 8 rebuild.
> 
> Well there will also be a mass rebuild in general for gcc 4.9 so you
> should coordinate with rel-eng to minimise builds in general.
> 
> Peter

-- 
Mikolaj Izdebski
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Owner-change] Fedora packages ownership change

[nobody]

Change in ownership over the last 168 hours
===

9 packages were orphaned

marco [epel7] was orphaned by raveit65
 MATE Desktop window manager
 https://admin.fedoraproject.org/pkgdb/acls/name/marco
caja [epel7] was orphaned by raveit65
 File manager for MATE desktop
 https://admin.fedoraproject.org/pkgdb/acls/name/caja
codemodel [devel,f20] was orphaned by jhernand
 Java library for code generators
 https://admin.fedoraproject.org/pkgdb/acls/name/codemodel
pluma [epel7] was orphaned by raveit65
 Text editor for the MATE desktop
 https://admin.fedoraproject.org/pkgdb/acls/name/pluma
mozo [epel7] was orphaned by raveit65
 MATE Desktop menu editor
 https://admin.fedoraproject.org/pkgdb/acls/name/mozo
eom [epel7] was orphaned by raveit65
 Eye of MATE image viewer
 https://admin.fedoraproject.org/pkgdb/acls/name/eom
perltidy [devel,f19,f20] was orphaned by scop
 Tool for indenting and reformatting Perl scripts
 https://admin.fedoraproject.org/pkgdb/acls/name/perltidy
mate-themes [epel7] was orphaned by raveit65
 MATE Desktop themes
 https://admin.fedoraproject.org/pkgdb/acls/name/mate-themes
caja-extensions [epel7] was orphaned by raveit65
 Set of extensions for caja file manager
 https://admin.fedoraproject.org/pkgdb/acls/name/caja-extensions

4 packages unorphaned
-
msimacekunorphaned : hamcrest12 [devel,f20]
pghmcfc unorphaned : perltidy [devel,f19,f20]
msimacekunorphaned : codemodel [devel,f19,f20]
skottlerunorphaned : erlang-mustache [EL-6]

2 packages were retired

fltk [devel] was retired by jchaloup
 C++ user interface toolkit
 https://admin.fedoraproject.org/pkgdb/acls/name/fltk
sbackup [devel] was retired by filiperosset
 Simple Backup Suite for desktop use
 https://admin.fedoraproject.org/pkgdb/acls/name/sbackup

17 packages changed owner
-
limbgave to mrunge : lockfile-progs [epel7]
limbgave to besser82   : libyui-gtk [EL-6]
limbgave to besser82   : fdupes [EL-5,EL-6,epel7]
limbgave to pghmcfc: perl-Test-Most [EL-5,EL-6]
kevin   gave to nonamedotc : sundials [devel,f19,f20]
kevin   gave to nonamedotc : fityk [devel,f19,f20]
limbgave to pghmcfc: perl-Data-Dumper-Names [EL-6]
limbgave to besser82   : libyui-bindings [EL-6]
limbgave to besser82   : libyui-ncurses [EL-6]
limbgave to besser82   : libyui-qt [EL-6]
limbgave to bjohnson   : libzdb [epel7]
limbgave to mcermak: sshpass [epel7]
limbgave to bkabrda: python-wheel [f20]
limbgave to yograterol : python-rsa [epel7]
limbgave to cicku  : herbstluftwm [epel7]
limbgave to besser82   : libyui [EL-6]
limbgave to psavelye   : python-pyroute2 [epel7]


Sources: https://github.com/pypingou/fedora-owner-change
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Java 8

[Mikolaj Izdebski]

On 03/22/2014 06:15 AM, Miloslav Trmač wrote:
> Given the known large number of failures (OptionalJavadocs says "80% build
> failure rate" without saying that all are JavaDoc-related), we really
> should do a mass rebuild to identify which packages fail to build *and* to
> file bugs soonish, instead of waiting for a Fedora-wide mass rebuild and
> then scrambling to fix dozens/hundreds of build failures in to avoid
> slipping the schedule.  We don't necessarily need an official one, perhaps
> only in a never-to-be-merged side tag (or even scratch builds?)

Agreed.

To do a rebuild in Koji Java 8 must land in there first.  That can could
be a separate tag, but rel-eng is quite reluctant to provide them.

Copr could be a better place to do the rebuild.  One big advantage is
that it doesn't use any ARM builders, but on the other hand it has quite
limited capacity (AFAIK 10 builders only).

Besides that, there is already one approved change [1] which requires
rebuilding most of Java packages.  We didn't do a mass rebuild for it
yet because we wanted to sync with Java 8 rebuild.

-- 
Mikolaj Izdebski

[1] https://fedoraproject.org/wiki/Changes/HeadlessJava
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: unalz to remove from Fedora

[Petr Pisar]

On 2014-03-17, Petr Pisar  wrote:
> I think it's time to remove the package from Fedora (21).
>
Nobody raised a hand, I'm going to retire the package.

-- Petr

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: GCJ [was: pdftk retired?]

[Orcan Ogetbil]

On Mon, Mar 24, 2014 at 6:02 AM, Andrew Haley  wrote:
> On 03/22/2014 07:51 PM, Orcan Ogetbil wrote:
>> On Thu, Mar 20, 2014 at 7:24 AM, Andrew Haley  wrote:
>>> On 03/19/2014 10:59 PM, Andrew Hughes wrote:>>
 And JDK5 might be good enough for the use required. It doesn't claim
 to be anything more than that, so I don't see the harm in leaving it there.
>>>
>>> Speaking as the upstream maintainer, I do.
>>
>> Hi Andrew, can you be a little more specific about the potential harm
>> you see with keeping GCJ in Fedora?
>
> I think Rahul already answered this.  Do you expect me to
> say something different from him?

Well, speaking of "harm", yes, I do.

Don't take me wrong. I just want to know if there is any reason beyond
maintainer unwillingness/ lack of time.

Thanks,
Orcan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Corey Sheldon]

this is the proverbal security vs. convenience  issue safety unfortunately
isn't convenient


Corey W Sheldon
Owner, 1st Class Mobile Shine
310.909.7672
www.facebook.com/1stclassmobileshine


On Mon, Mar 24, 2014 at 8:21 AM, Florian Weimer  wrote:

> On 03/24/2014 01:06 PM, Reindl Harald wrote:
>
>  Am 24.03.2014 12:57, schrieb Nicolas Mailhot:
>>
>>> Le Sam 22 mars 2014 01:20, Miloslav Trmač a écrit :
>>>
>>>  The RHEL documentation, apart from fully describing the abilities,
 specifically describes two uses: a ftpd banner

>>>
>>> Surprisingly, ftp is still widely used entreprise-side, because ssh is
>>> giving too much access
>>>
>>
>> no, it is easy to restrict ssh to ONLY sftp and chroot and with
>> simple bind-mounts you can completly replace ftp, doing that here
>> in production over years with 3 simple scripts
>>
>
> It's still very difficult to securely process uploaded files under a
> different user account.  Some SFTP clients set restrictive permissions on
> upload, and the OpenSSH implementation does not allow to bypass that.
>
> --
> Florian Weimer / Red Hat Product Security Team
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Nicolas Mailhot]

Le Sam 22 mars 2014 03:21, Lennart Poettering a écrit :

> And you honestly believe that people who are capable enough of setting
> up DNS locally and across the company in a secure way to do something

To set up DNS securely you need a handful of people to manage a master dns
and its slave on the internal network, and order every one else to use
them only.

To set up filtering rules you need someone for each handful of servers,
and with virtualization, that's not the same kind of number at all. Apps
sprout up like mushrooms after rain, they change all the time, they
conflict with each other, just conveying information from the development
teams to the security people is a full time job. Something that is widely
understood and can be done by rote by less-clueful people to harden things
a bit is not to be spurned.

Regards,

-- 
Nicolas Mailhot

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: qmake-qt4 DEFINES issue

[Jaroslav Reznik]

- Original Message -
> On Mon, Mar 24, 2014 at 04:55:34AM +0100, Kevin Kofler wrote:
> > > One possible fix would be to rename 'qt' back to 'qt4' explicitly
> > That will have to happen soon anyway, with the move to Qt 5.
> 
> Is qt5 going to be shifted to be packaged as generic qt? Is there value in
> doing that over leaving it versioned?

Versioned. See https://bugzilla.redhat.com/show_bug.cgi?id=878188 for 
discussion (unless something changes I missed).

R.

> --
> Matthew Miller--   Fedora Project--
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 24.03.2014 13:26, schrieb Florian Weimer:
> On 03/24/2014 01:23 PM, Reindl Harald wrote:
> 
>>> It's still very difficult to securely process uploaded files under a 
>>> different user account.  Some SFTP clients set
>>> restrictive permissions on upload, and the OpenSSH implementation does not 
>>> allow to bypass that.
>>
>> man umask
>>
>> [root@rh:/downloads]$ cat /etc/ssh/sshd_config  | grep internal-sftp
>> Subsystem sftp internal-sftp -u 006
> 
> umask doesn't apply to explicit chmod

besides that we get way too off-topic and my first reply was in context
of "because ssh is giving too much access" which is a wrong anecdote:

fine, the same applies for samba, ftp and any other file transfer protocol
if you want 100% defined permissions you need to use inotify and handmade
daemons in any case because the client can fire always a chmod of files
he own



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Florian Weimer]

On 03/24/2014 01:23 PM, Reindl Harald wrote:


It's still very difficult to securely process uploaded files under a different 
user account.  Some SFTP clients set
restrictive permissions on upload, and the OpenSSH implementation does not 
allow to bypass that.


man umask

[root@rh:/downloads]$ cat /etc/ssh/sshd_config  | grep internal-sftp
Subsystem sftp internal-sftp -u 006


umask doesn't apply to explicit chmod.

--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 24.03.2014 13:21, schrieb Florian Weimer:
> On 03/24/2014 01:06 PM, Reindl Harald wrote:
> 
>> Am 24.03.2014 12:57, schrieb Nicolas Mailhot:
>>> Le Sam 22 mars 2014 01:20, Miloslav Trmač a écrit :
>>>
 The RHEL documentation, apart from fully describing the abilities,
 specifically describes two uses: a ftpd banner
>>>
>>> Surprisingly, ftp is still widely used entreprise-side, because ssh is
>>> giving too much access
>>
>> no, it is easy to restrict ssh to ONLY sftp and chroot and with
>> simple bind-mounts you can completly replace ftp, doing that here
>> in production over years with 3 simple scripts
> 
> It's still very difficult to securely process uploaded files under a 
> different user account.  Some SFTP clients set
> restrictive permissions on upload, and the OpenSSH implementation does not 
> allow to bypass that.

man umask

[root@rh:/downloads]$ cat /etc/ssh/sshd_config  | grep internal-sftp
Subsystem sftp internal-sftp -u 006



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Florian Weimer]

On 03/24/2014 01:06 PM, Reindl Harald wrote:


Am 24.03.2014 12:57, schrieb Nicolas Mailhot:

Le Sam 22 mars 2014 01:20, Miloslav Trmač a écrit :


The RHEL documentation, apart from fully describing the abilities,
specifically describes two uses: a ftpd banner


Surprisingly, ftp is still widely used entreprise-side, because ssh is
giving too much access


no, it is easy to restrict ssh to ONLY sftp and chroot and with
simple bind-mounts you can completly replace ftp, doing that here
in production over years with 3 simple scripts


It's still very difficult to securely process uploaded files under a 
different user account.  Some SFTP clients set restrictive permissions 
on upload, and the OpenSSH implementation does not allow to bypass that.


--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

File Type-Tiny-0.040.tar.gz uploaded to lookaside cache by corsepiu

[corsepiu]

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

e1b0730e699d03cd82c240d79f64635f  Type-Tiny-0.040.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 24.03.2014 12:57, schrieb Nicolas Mailhot:
> Le Sam 22 mars 2014 01:20, Miloslav Trmač a écrit :
> 
>> The RHEL documentation, apart from fully describing the abilities,
>> specifically describes two uses: a ftpd banner
> 
> Surprisingly, ftp is still widely used entreprise-side, because ssh is
> giving too much access

no, it is easy to restrict ssh to ONLY sftp and chroot and with
simple bind-mounts you can completly replace ftp, doing that here
in production over years with 3 simple scripts

[root@localhost:~]$ mount | grep sftp-homes | wc -l
168

* create and maintain the mountpoints from the backend
* mount all bind-mounts at boot
* unmount them before shutdown
* internally you can use the same for userbased smb shares

that's why i go that angry by the broken coreutils "df"
behavior which now luckily no longer lists all bind-mounts
but is still a mess and nobody cares

https://bugzilla.redhat.com/show_bug.cgi?id=1042840
https://bugzilla.redhat.com/show_bug.cgi?id=1001092#c12




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: qmake-qt4 DEFINES issue

[Matthew Miller]

On Mon, Mar 24, 2014 at 04:55:34AM +0100, Kevin Kofler wrote:
> > One possible fix would be to rename 'qt' back to 'qt4' explicitly
> That will have to happen soon anyway, with the move to Qt 5.

Is qt5 going to be shifted to be packaged as generic qt? Is there value in
doing that over leaving it versioned?

-- 
Matthew Miller--   Fedora Project--
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Nicolas Mailhot]

Le Sam 22 mars 2014 01:20, Miloslav Trmač a écrit :

> The RHEL documentation, apart from fully describing the abilities,
> specifically describes two uses: a ftpd banner

Surprisingly, ftp is still widely used entreprise-side, because ssh is
giving too much access, and no one released an easy to use webdav
substitute (plus windows dav clients suck)

Regards,

-- 
Nicolas Mailhot

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Nicolas Mailhot]

Le Jeu 20 mars 2014 20:44, Stephen John Smoogen a écrit :

> I am giving you a standard enterprise problem.

I can confirm that thanks to the stability of the config file, tcpwrappers
is widely used here.

IPtables has just started getting some adoption (after years of turf wars
between firewall admin and server admins) but I'm not confident a lot of
projects will really use it (unfortunately, iptables did *not* have
clearly defined configuration rules, so it's a free-for-all a lot of
projects do not want to mess with).

Selinux is the future that will arrive someday when someone dares making
it mandatory (and accepts the inevitable fallout when enterprisey stuff
like Oracle and friends start failing right and left)

I really wish there was less energy spent on what the code looks from the
inside and more than providing stable easy to use user interface. You can
rewrite code twenty times no one will care as long as the interface is
familiar. Break configuration syntax or other interfaces, however, and all
hell breaks loose.

And before someone complains of sysadmin stop energy: Microsoft core fonts
(1996-era stuff) are still in the top #5 sourceforge downloads, despite
being years out of date and unmaintained, and despite the boatloads of
better FLOSS fonts which have been released in the past years. I'm sure
they are still in Fedora install howtos.

THAT's how badly users want human interface stability, be it on the server
or the desktop side.

-- 
Nicolas Mailhot

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: GCJ [was: pdftk retired?]

[Andrew Haley]

On 03/22/2014 07:51 PM, Orcan Ogetbil wrote:
> On Thu, Mar 20, 2014 at 7:24 AM, Andrew Haley  wrote:
>> On 03/19/2014 10:59 PM, Andrew Hughes wrote:>>
>>> And JDK5 might be good enough for the use required. It doesn't claim
>>> to be anything more than that, so I don't see the harm in leaving it there.
>>
>> Speaking as the upstream maintainer, I do.
> 
> Hi Andrew, can you be a little more specific about the potential harm
> you see with keeping GCJ in Fedora?

I think Rahul already answered this.  Do you expect me to
say something different from him?

Andrew.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Orphaned: perltidy

[Paul Howarth]

On 24/03/14 08:41, Ville Skyttä wrote:

I haven't used perltidy in quite a while so I've released its
ownership in pkgdb, hopefully someone who does goes and grabs it.


Taken. Co-maintainers welcome.

Paul.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: ostree/fedora atomic and impact on the mirror network

[Florian Weimer]

On 03/11/2014 02:34 PM, Martin Langhoff wrote:

On Tue, Mar 11, 2014 at 9:10 AM, Colin Walters  wrote:

Remember OSTree is a content-addressed object store (like git), not a chain
of deltas (like Subversion, and other systems out there such as Chromium
Autoupdate, and Docker).


Ouch -- so updates fetch EVERY file regardless of whether it has
changed between the snapshot installed and the target snapshot? That
is kind of bad.


It only downloads objects which are new, e.g. files that have changed, 
or directories which contain a change (perhaps indirectly).  This is 
still a lot of HTTP requests, so it is very slow unless you happen to 
have a local mirror.



Are you aware of the work done on OLPC's os-builder, which used rsync
"informed" by a per-snapshot metatada file?


Plain rsync is usually not deemed suitable for distributing things 
because of the server-side overhead.  zsync (rsync algorithm with a dumb 
server) might work, though.


--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Orphaned: perltidy

[Ville Skyttä]

I haven't used perltidy in quite a while so I've released its
ownership in pkgdb, hopefully someone who does goes and grabs it.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct