date:20140709

On Wed, Jul 09, 2014 at 01:13:30PM +0200, Reindl Harald wrote:
 in fact it where around 5 people keep heating the discussion and burry
 the arguments of people which did not want more than what was present
 over years and now came back in DNF and it that case *you must* respond
 and try to explain why their arguments are wrong in case of upstream
 did not care and closed bugreports 2014/01 already

It is absolutely fine to respond and make the points. But if someone doesn't
get it after that, it's okay to let the matter drop. In fact, it's the
best thing to do.

This is _particularly_ true when the person responding isn't doing so with a
good attitude. When, as you say, people are heating the discussion, the best
way to cool it down is to not throw fuel. You can't educate people who
aren't interested in listening, and they're generally not the people making
decisions anyway. In fact, it makes the situation worse because it makes it
drives away people who might agree with you -- or be convinced.


-- 
Matthew Miller
mat...@fedoraproject.org
Fedora Project Leader
-- 
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: New Fedora 22 Change proposal: systemd-sysusers

On Wed, Jul 09, 2014 at 06:19:19AM -0700, Colin Walters wrote:
 Hi, for Atomic I'd like to investigate the new systemd-sysusers, so I
 wrote up a Change:
 
 https://fedoraproject.org/wiki/Changes/SystemdSysusers
 
 Note: for Fedora 22.
 
 The main motivation for me is it would allow Atomic to not be a Remix
 due to the not-in-Fedora shadow-utils patch[1]  Further, it would
 potentially allow us to migrate away from /usr/lib/passwd and
 nss-altfiles which would be really nice.  Though I'm still exploring
 that.
 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1098304

Colin, we're _really_ hoping to make Atomic a flagship feature for Fedora
Cloud in F21. If I work on getting the shadow-utils patch landed, does that
_conflict_ with the new approach? (And, are there any other blockers which
would make this not a possibility?)


-- 
Matthew Miller
mat...@fedoraproject.org
Fedora Project Leader
-- 
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: New Fedora 22 Change proposal: systemd-sysusers

- Original Message -
 Hi, for Atomic I'd like to investigate the new systemd-sysusers, so I
 wrote up a Change:
 
 https://fedoraproject.org/wiki/Changes/SystemdSysusers

A move to something more declarative makes sense (whether in systemd or through 
some kind of long-expected declarative rpm facility doesn’t matter to me much.)

The sysusers tool _really_ needs to use an existing API to manage the user 
database, though.  As it is, the implementation
* validates names incorrectly
* breaks the configurable [UG]ID_MIN logic 
(http://fedoraproject.org/wiki/Features/1000SystemAccounts, and yes, that is 
actually used and needed)
* is likely to break various readers software by not updating the shadow files
* doesn’t do any auditing.
We are currently already in a bad position by having two major implementations 
of maintaining the critical databases, we absolutely don’t want any more.

At this point this means systemd-sysuers should either run the executables from 
shadow-utils, or link to libuser.  (Or, I suppose, use accountsservice, but 
that ends up calling shadow-utils.).

The plan is to have a single implementation, living around sssd.  (Jakub knows 
more.)  Either of two API points above are planned to use the sssd 
implementation, so can be relied on long-term.
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: New Fedora 22 Change proposal: systemd-sysusers

2014-07-09 Thread Colin Walters

On Wed, Jul 9, 2014, at 06:34 AM, Matthew Miller wrote:

 Colin, we're _really_ hoping to make Atomic a flagship feature for Fedora
 Cloud in F21. If I work on getting the shadow-utils patch landed, does
 that
 _conflict_ with the new approach?

It doesn't conflict, no.  Let's discuss this in the bug, and thanks for
helping with this!
-- 
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: [Base] The Base Design WG is looking for a new committee member!

2014-07-09 Thread Phil Knirsch

That sounds great Michal. If you could join us tomorrow at our meeting 
at 15:00 UTC on #fedora-meeting that would be excellent.


Thank you for your interest and see you tomorrow!

Regards, Phil


On 07/08/2014 02:31 PM, Michal Sekletar wrote:

On Fri, Jun 27, 2014 at 06:13:01PM +0200, Phil Knirsch wrote:

Hi everyone.


Hello everyone,



As Bill Nottingham has decided to resign from the committee we now
have a free seat that we'd like to fill with another person.

In order to fill this seat i'm therefore reaching out here to Fedora
development to offer allow any applicant from the community to get
in touch with us and let us know you're interested, why you're
interested, why you think you'd be a good fit and maybe even the
things you'd like to drive or accomplish in the Base Design WG.


I am interested in becoming a member of Base Design WG. I'd like help with
accomplishing goals of Base WG and make sure that we provide minimal but solid
foundation for others to build upon.

I believe my previous experience makes me a good fit for this position :
   * Red Hat employee since 2011, now member of Plumbers group
   * maintainer and contributor to various networking related projects
   * systemd maintainer in RHEL

I'd like to help with integration of upstream changes in key components to the
distribution and making sure they are not disruptive. Another area where I'd
like to contribute are container use cases of Fedora Base. Ensuring we provide
minimal, but easily extensible platform for sand-boxed/containerized apps.



For more background on what the Base WG does, here our Fedora wiki:

https://fedoraproject.org/wiki/Base

In order to contact us you can either reply directly to me or join
us during our regular meetings each Friday at 15:00 UTC on
#fedora-meeting.

I strongly suspect next weeks meeting will be canceled due to the US
holiday, but after that we'll be doing weekly meetings again.

Looking forward to see you there!

Thanks  regards, Phil

--
Philipp Knirsch  | Tel.:  +49-711-96437-470
Manager Core Services| Fax.:  +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com
Wankelstrasse 5  | Web:   http://www.redhat.com/
D-70563 Stuttgart, Germany
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


Michal




--
Philipp Knirsch  | Tel.:  +49-711-96437-470
Manager Core Services| Fax.:  +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com
Wankelstrasse 5  | Web:   http://www.redhat.com/
D-70563 Stuttgart, Germany
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

startxfce4 harmonization with the systemd-logind

2014-07-09 Thread poma



startxfce4 harmonization with the systemd-logind
https://bugzilla.redhat.com/show_bug.cgi?id=1117682
https://bugzilla.redhat.com/attachment.cgi?id=916668

As explained here,
gphoto2 only as root -
https://lists.fedoraproject.org/pipermail/users/2014-January/446166.html

with the reference,
systemd-logind not tracking startx sessions
https://bugzilla.redhat.com/show_bug.cgi?id=806491

Applicable to Fedora 19 - 21  Rawhide.


poma

--
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: startxfce4 harmonization with the systemd-logind

2014-07-09 Thread Kevin Fenzi

On Wed, 09 Jul 2014 10:21:55 +0200
poma pomidorabelis...@gmail.com wrote:

 
 startxfce4 harmonization with the systemd-logind
 https://bugzilla.redhat.com/show_bug.cgi?id=1117682
 https://bugzilla.redhat.com/attachment.cgi?id=916668
 
 As explained here,
 gphoto2 only as root -
 https://lists.fedoraproject.org/pipermail/users/2014-January/446166.html
 
 with the reference,
 systemd-logind not tracking startx sessions
 https://bugzilla.redhat.com/show_bug.cgi?id=806491
 
 Applicable to Fedora 19 - 21  Rawhide.

Thanks for the patch, will take a look. 

IMHO, There's no need to post to multiple lists and directly mail
upstream folks when you file a bug with a patch though. 

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: New Fedora 22 Change proposal: systemd-sysusers

2014-07-09 Thread Colin Walters

On Wed, Jul 9, 2014, at 07:30 AM, Miloslav Trmač wrote:

* validates names incorrectly

We're talking about the equivalent of lu_name_allowed() from libuser?
Something like the
/* Allow trailing $ for samba machine accounts. */
?

But the usernames specified here are only for system users, they're not
derived from dynamic input, so it seems to me we can be even more
restrictive safely.

Can you be more specific about the name validation?

* breaks the configurable [UG]ID_MIN logic
(http://fedoraproject.org/wiki/Features/1000SystemAccounts, and yes, that
is actually used and needed)

It *does* read that file since:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=f7dc3ab9f43b67abcbd34062b9352ab42debec49
This predates sysusers, but I'm assuming you mean the bug here is that
it's read at build time and instead should be dynamic?

* is likely to break various readers software by not updating the shadow
files

There was a discussion of that upstream, it's on the TODO. I agree with
Lennart here that it seems nicer to just not have entries at all, but if
it breaks some checking tool, doesn't hurt to add it either.

* doesn’t do any auditing.

I don't see libuser doing any either? Am I missing it?

We are currently already in a bad position by having two major
implementations of maintaining the critical databases, we absolutely
don’t want any more.

Those two being libuser and shadow-utils?

At this point this means systemd-sysuers should either run the
executables from shadow-utils, or link to libuser. (Or, I suppose, use
accountsservice, but that ends up calling shadow-utils.).

Hmm. Well, I do see a key distinction here being between system and
non-system accounts. There's clearly a need for unification and caching
around all of the many ways in which admins might want to store and
manage non-system accounts, and I see SSSD providing a lot of value
there. But system accounts are a lot more restricted; and we're not
discussing (now) having them anywhere other than /etc/passwd in the
traditional format, correct? In that case, I don't see significant
complexity or cost to having multiple readers/writers.
--
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: New Fedora 22 Change proposal: systemd-sysusers

(This is all rather beside the point: fixing those particular things won’t
eliminate any of the problems of triplicate implementations and splintered
knowledge. But to spread the awareness of the area…)

- Original Message -
On Wed, Jul 9, 2014, at 07:30 AM, Miloslav Trmač wrote:

* validates names incorrectly

We're talking about the equivalent of lu_name_allowed() from libuser?
Yes.

But the usernames specified here are only for system users, they're not
derived from dynamic input, so it seems to me we can be even more
restrictive safely.
True; to that extent this is not such a pressing problem.

Can you be more specific about the name validation?
The binding maximum length constraint is from the utmp format (UT_NAMESIZE -
1); LOGIN_NAME_MAX is an upper bound but not binding, and this has already
ended up in systemd-sysuser’s documentation essentially promising to do the
impossible/unsafe by using the non-binding maximum length.

* breaks the configurable [UG]ID_MIN logic
(http://fedoraproject.org/wiki/Features/1000SystemAccounts, and yes, that
is actually used and needed)

Yes.

* is likely to break various readers software by not updating the shadow
files

There was a discussion of that upstream, it's on the TODO. I agree with
Lennart here that it seems nicer to just not have entries at all,

On a typical system _no_ accounts are misssing from the shadow files, so tools
and admins’ scripts are not designed and rigorously tested to handle this.
(Early in its history, system-config-users had a _lot_ of problems with
shadow/non-shadow mismatches.)

Note also that if a tool needs to edit _one_ field within the shadow file, it
needs to add some values for all the other fields (or at least the mandatory
ones), and it’s not always obvious what value to use. So it’s actually much
clearer for the system tools, which already know the default values of the
fields based on their own configuration, to pre-create the shadow entries with
the correct default values. (Though this applies especially to real users
rather than passwordless system accounts.)

* doesn’t do any auditing.

I don't see libuser doing any either? Am I missing it?

No, it’s also missing I’m afraid.

We are currently already in a bad position by having two major
implementations of maintaining the critical databases, we absolutely
don’t want any more.

Those two being libuser and shadow-utils?

Yes, to my knowledge.

At this point this means systemd-sysuers should either run the
executables from shadow-utils, or link to libuser. (Or, I suppose, use
accountsservice, but that ends up calling shadow-utils.).

Hmm. Well, I do see a key distinction here being between system and
non-system accounts.

The two are distinct, but that doesn’t justify having three different writers
with different policies maintaining a single database, for either of the cases.

In that case, I don't see significant
complexity or cost to having multiple readers/writers.

The cost to write the new code in systemd-sysusers is already way larger than
what would have been necessary to just call useradd, so it is inefficient by
that measure already. Then add this discussion, and making any future changes
in the design more costly (like your proposal for /usr/lib/passwd - one more
implementation is one more place to patch; every future change would be all
that much harder)
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: New Fedora 22 Change proposal: systemd-sysusers

On Wed, 09.07.14 06:19, Colin Walters (walt...@verbum.org) wrote:

 Hi, for Atomic I'd like to investigate the new systemd-sysusers, so I
 wrote up a Change:
 
 https://fedoraproject.org/wiki/Changes/SystemdSysusers
 
 Note: for Fedora 22.
 
 The main motivation for me is it would allow Atomic to not be a Remix
 due to the not-in-Fedora shadow-utils patch[1]  Further, it would
 potentially allow us to migrate away from /usr/lib/passwd and
 nss-altfiles which would be really nice.  Though I'm still exploring
 that.
 
 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1098304

Ah, interesting. A week ago I filed this:

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

In order to get the process started to get this through FPC first. In
that ticket I actually promised to bring this up on fedora-devel, but it
appears that you beat me to it.

The reason I haven't brought this up yet is because I wanted a 
nice way how we can make use of this from RPM scriptlets, so that
packages can just stick to this declarative scheme, and be
done. However, that's actually not that trivial:

Some packages (notably polkit) rely on files owned by a system user that
is not root. This means we need to do the user registration in %pre how
it was always done. But if we do the user registration declaratively
from files we ship in the RPM, then we could only run that from %post,
which of course means that the files cannot be owned properly.

Fortunately it's only a handful of packages which appear to require that
though (but I didn't spend to much time to figure out the details). Our
current way of thinking is to simply introduce a second syntax for the
sysusers RPM macro: the few packages which need that would then be able
to embedd the declaration of the user into %pre, while most users would
be created via %post. The few packages which need that would contain the
user definition at two places though: once in the file system in a
drop-in file shipped in the RPM, and a second time, inline, in the %pre
scriptlet. Not pretty... Not sure though what other options there are,
that would be better...

Anyway, I do like to see this feature implemented in Fedora. I think
it's really crucial to get this done.

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: New Fedora 22 Change proposal: systemd-sysusers

On Wed, 09.07.14 10:30, Miloslav Trmač (m...@redhat.com) wrote:

 - Original Message -
  Hi, for Atomic I'd like to investigate the new systemd-sysusers, so I
  wrote up a Change:
  
  https://fedoraproject.org/wiki/Changes/SystemdSysusers
 
 A move to something more declarative makes sense (whether in systemd or 
 through some kind of long-expected declarative rpm facility doesn’t matter to 
 me much.)
 
 The sysusers tool _really_ needs to use an existing API to manage the
 user database, though.  

Yeah, because we dodn't want to intrdocue any new API we have carefully
made sure that whenever we write pasword, group and shadow files we use
existing APIs from glibc, more specifically putpwent(), putgrent(),
putspent() and crypt_r(). 

This is about creating system users, not normal users, hence using
anything more fancy than glibc's native APIs is wrong. This is not stuff
which is supposed to land on an ActiveDirectory server or so. It's stuff
we need to be able to recreate during earliest boot, before the first
daemons start, where little else but the most basic file system is
around. libuser is not useful for this kind of environment.

It appears to me that libuser unsuccessfully duplicates APIs from glibc,
shadow-utils and other packages. I mean, it's quite weird to have both
passwd and lpasswd around, and then complaining to me that we don't
need multiple implementations. I mean, I really don't understand why
there are two implementations of this in the first place! 

Anyway, I can understand the reason for libuser's existence, but for the
low-level stuff we do with systemd here this is simply not the right
tool for the job. We want something so low level that glibc is the only
right option.

Also, note that with systemd we try to find solutions that work for most
Linux distributions. libuser appears to be quite common on Fedora, but I
am pretty sure that systemd is not the vehicle to make it standard on
other distributions too, in particular via such a relatively auxiliary
feature of systemd.

 As it is, the implementation
 * validates names incorrectly

How so? Can you elaborate? Point me to normative documents?

 * breaks the configurable [UG]ID_MIN logic
 (http://fedoraproject.org/wiki/Features/1000SystemAccounts, and yes,
 that is actually used and needed)

Well, this is something I really don't like. THis limit should be
compile-time configurable, but not runtime-configurable. This is
something the distributor needs to decide on, not something
administrators should be able to change without recompiling.

With systemd we kinda need to get something that works for the big
picture, and I have doubts that this is something I want to see in the
big picture, sorry.

 * is likely to break various readers software by not updating the
 shadow files

Well, we don't update the shadow file, since a missing shadow entry is
actually interpreted the exact way we want it here: as a disabled
account, with no password set, where it is not possible to login
to. That's the absolute correct default for system users.

That said, it was brought to my attention that pwck doesn't agree with
that. So I figure we'll update the shadow file too, the patch should be
easy. It's on the todo list.

 * doesn’t do any auditing.

Well, looking forward to a patch to add this.

 We are currently already in a bad position by having two major
 implementations of maintaining the critical databases, we absolutely
 don’t want any more.

Good! We just use glibc APIs for writing those files. If you want only
one implementation, why not get rid of libuser, and stick to glibc? ;-)

 At this point this means systemd-sysuers should either run the
 executables from shadow-utils, or link to libuser.  (Or, I suppose,
 use accountsservice, but that ends up calling shadow-utils.).

Sorry, I am not going to play your stacking game. This is supposed to be
simple, work in a minimal early-boot environment, and use stuff that is
commonly around on Linuxes, from embedded to servers. glibc APIs
are. libuser is not.

 The plan is to have a single implementation, living around sssd.
 (Jakub knows more.)  Either of two API points above are planned to
 use the sssd implementation, so can be relied on long-term.  Mirek

I am sorry, but to make this very clear: sssd has not place in early
boot or in smaller setups. The problems we we want to solve with systemd
we try to solve generically, and this means that I am not telling people
to pull in sssd into the smallest of devices.

sssd/libuser is fine for creating nomral users with, and fine for
late-boot stuff, and fine for bigger setups. But other than that, glibc
wins the day.

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: rawhide report: 20140709 changes

2014-07-09 Thread Kevin Fenzi

FYI, rawhide composed fine, but due to renaming and building a new
rawhide composer machine it didn't properly sync the compose to the
master mirror. :( 

I have corrected the issue and am manually syncing it over now. 

So, if you wonder why you didn't see any updates in yum/dnf, thats
why. ;) 

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: New Fedora 22 Change proposal: systemd-sysusers

2014-07-09 Thread Chris Adams

Once upon a time, Lennart Poettering mzerq...@0pointer.de said:
 On Wed, 09.07.14 10:30, Miloslav Trmač (m...@redhat.com) wrote:
  * breaks the configurable [UG]ID_MIN logic
  (http://fedoraproject.org/wiki/Features/1000SystemAccounts, and yes,
  that is actually used and needed)
 
 Well, this is something I really don't like. THis limit should be
 compile-time configurable, but not runtime-configurable. This is
 something the distributor needs to decide on, not something
 administrators should be able to change without recompiling.

Please, no!  As soon as you use disparate systems in a network
environment, having differing versions of UID_MIN (where recompilation
is required to change) is just wrong.  As the message above sys, yes,
that is actually used and needed.  I see no valid justification for
removing that functionality.

-- 
Chris Adams li...@cmadams.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: New Fedora 22 Change proposal: systemd-sysusers

2014-07-09 Thread Reindl Harald



Am 09.07.2014 19:18, schrieb Chris Adams:
 Once upon a time, Lennart Poettering mzerq...@0pointer.de said:
 On Wed, 09.07.14 10:30, Miloslav Trmač (m...@redhat.com) wrote:
 * breaks the configurable [UG]ID_MIN logic
 (http://fedoraproject.org/wiki/Features/1000SystemAccounts, and yes,
 that is actually used and needed)

 Well, this is something I really don't like. THis limit should be
 compile-time configurable, but not runtime-configurable. This is
 something the distributor needs to decide on, not something
 administrators should be able to change without recompiling.

and because someone decicdes to compile different the admin should
be forced to re-compile? that's not how the world works!


 Please, no!  As soon as you use disparate systems in a network
 environment, having differing versions of UID_MIN (where recompilation
 is required to change) is just wrong.  As the message above sys, yes,
 that is actually used and needed.  I see no valid justification for
 removing that functionality

+1

UID_MIN   500
UID_MAX 6

GID_MIN   500
GID_MAX 6

still here in use and that won't change

if somebody enforces to change that at compile time he don't
care for any production setups not re-installed every year
and decides to break things just for fun



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: rawhide report: 20140709 changes

2014-07-09 Thread Bruno Wolff III


On Wed, Jul 09, 2014 at 11:01:57 -0600,
 Kevin Fenzi ke...@scrye.com wrote:

FYI, rawhide composed fine, but due to renaming and building a new
rawhide composer machine it didn't properly sync the compose to the
master mirror. :(

I have corrected the issue and am manually syncing it over now.


I am seeing the rawhide stuff now. Is the branched stuff going to show 
up soon?

--
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: rawhide report: 20140709 changes

2014-07-09 Thread Kevin Fenzi

On Wed, 9 Jul 2014 12:23:54 -0500
Bruno Wolff III br...@wolff.to wrote:

 On Wed, Jul 09, 2014 at 11:01:57 -0600,
   Kevin Fenzi ke...@scrye.com wrote:
 FYI, rawhide composed fine, but due to renaming and building a new
 rawhide composer machine it didn't properly sync the compose to the
 master mirror. :(
 
 I have corrected the issue and am manually syncing it over now.
 
 I am seeing the rawhide stuff now. Is the branched stuff going to
 show up soon?

The branched compose failed this morning, we are fixing that up and
hopefully there will be a branched tree later today. 

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: New Fedora 22 Change proposal: systemd-sysusers

On Wed, 09.07.14 12:25, Miloslav Trmač (m...@redhat.com) wrote:

Can you be more specific about the name validation?

The binding maximum length constraint is from the utmp format
(UT_NAMESIZE - 1); LOGIN_NAME_MAX is an upper bound but not binding,
and this has already ended up in systemd-sysuser’s documentation
essentially promising to do the impossible/unsafe by using the
non-binding maximum length.

Oh, well. If utmp really is the normative source for this then that's
quite a pity, in particular since this appears not to be documented
anywhere, even though people care quite often what the maximum length
for usernames is.

If 32chars as required by utmp is really the limit we should follow
here, then I would really enjoy if we'd actually set LOGIN_NAME_MAX to
the same value.

Anyway, I have now added a check for UT_NAMESIZE-1:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=932ad62b84165b0acf690ea34c4b8083657ae244

There was a discussion of that upstream, it's on the TODO. I agree with
Lennart here that it seems nicer to just not have entries at all,

On a typical system _no_ accounts are misssing from the shadow files,
so tools and admins’ scripts are not designed and rigorously tested to
handle this. (Early in its history, system-config-users had a _lot_
of problems with shadow/non-shadow mismatches.)

Note also that if a tool needs to edit _one_ field within the shadow
file, it needs to add some values for all the other fields (or at
least the mandatory ones), and it’s not always obvious what value to
use. So it’s actually much clearer for the system tools, which
already know the default values of the fields based on their own
configuration, to pre-create the shadow entries with the correct
default values. (Though this applies especially to real users rather
than passwordless system accounts.)

Well, we use glibc APIs. It would be good to document this in the
respective manpages, most specifically putspent(3). Thanks.

Hmm, it would be good btw, if libuser would actually use glibc APIs, for
the precise reasons you are pointing out. As it appears though you
reimplemented all those APIs for no reason...

The two are distinct, but that doesn’t justify having three different
writers with different policies maintaining a single database, for
either of the cases.

Well, sysusers is on the safe side here, we appear to be the only ones
who actually use the lowest level APIs for this, there are, which are
glibc's, but I figure I am repeating myself now...

In that case, I don't see significant
complexity or cost to having multiple readers/writers.

The cost to write the new code in systemd-sysusers is already way
larger than what would have been necessary to just call useradd, so it
is inefficient by that measure already. Then add this discussion, and
making any future changes in the design more costly (like yourd
proposal for /usr/lib/passwd - one more implementation is one more
place to patch; every future change would be all that much harder)
Mirek

Well, userass/adduser are something the distros currently deviate
greatly in, and we needed somethign simple, safe, somewhat vwidely
available and capable of running in earliest boot. The glibc APis
provide that, no other API does that.

Oh, also, libuser is a glib API. Nothing against glibc, but for the
low-level stuff we do that runs with nothing around we try to be OOM
safe, and stuff...

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

Minutes from today's FESCo Meeting (2014-07-09)

===
#fedora-meeting: FESCO (2014-07-09)
===


Meeting started by mattdm at 17:01:56 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2014-07-09/fesco.2014-07-09-17.01.log.html
.



Meeting summary
---
* init process  (mattdm, 17:02:02)

* #1311 Disable syscall auditing by default  (mattdm, 17:04:21)
  * LINK: https://fedorahosted.org/fesco/ticket/1311   (mattdm,
17:04:25)
  * ACTION: mitr to close syscall auditing ticket, file bug, etc.
(mattdm, 17:09:42)

* #1322 F21 Changes - Progress on Changes Freeze  (mattdm, 17:09:52)
  * LINK: https://fedorahosted.org/fesco/ticket/1322   (mattdm,
17:10:02)
  * ACTION: mattdm to take aperidoc updates to cloud wg and qa and web
before next fesco  (mattdm, 17:18:29)

* Next week's chair  (mattdm, 17:21:34)
  * t8m to chair next meeting  (mattdm, 17:25:18)

* Open Floor  (mattdm, 17:25:22)
  * FESCo Town Hall is going to be this Friday, 13:00 UTC  (mattdm,
17:25:54)
  * per-product config draft is potentially an alpha blocker  (mattdm,
17:27:12)
  * fpc meeting which will cover this is tomorrow (thursday) at 16:00
UTC in #fedora-meeting-1  (mattdm, 17:28:37)

Meeting ended at 17:33:36 UTC.




Action Items

* mitr to close syscall auditing ticket, file bug, etc.
* mattdm to take aperidoc updates to cloud wg and qa and web before next
  fesco




Action Items, by person
---
* mattdm
  * mattdm to take aperidoc updates to cloud wg and qa and web before
next fesco
* mitr
  * mitr to close syscall auditing ticket, file bug, etc.
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* mattdm (61)
* jreznik (19)
* sgallagh (17)
* abadger1999 (11)
* mitr (9)
* zodbot (9)
* nirik (8)
* dgilmore (7)
* t8m (6)
* pjones (2)
* jwb (1)
* mmaslano (0)
* kylem (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot


-- 
Matthew Miller
mat...@fedoraproject.org
Fedora Project Leader
-- 
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: New Fedora 22 Change proposal: systemd-sysusers

- Original Message -
 On Wed, 09.07.14 10:30, Miloslav Trmač (m...@redhat.com) wrote:
  - Original Message -
  A move to something more declarative makes sense (whether in systemd or
  through some kind of long-expected declarative rpm facility doesn’t matter
  to me much.)
  
  The sysusers tool _really_ needs to use an existing API to manage the
  user database, though.
 
 Yeah, because we dodn't want to intrdocue any new API we have carefully
 made sure that whenever we write pasword, group and shadow files we use
 existing APIs from glibc, more specifically putpwent(), putgrent(),
 putspent() and crypt_r().

 This is about creating system users, not normal users, hence using
 anything more fancy than glibc's native APIs is wrong.

I have already given examples where using a higher-level API would avoid 
mistakes _and_ make future changes easier; and none of the reasons offered 
convince me:

 This is not stuff
 which is supposed to land on an ActiveDirectory server or so. It's stuff
 we need to be able to recreate during earliest boot, before the first
 daemons start, where little else but the most basic file system is
 around. libuser is not useful for this kind of environment.

libuser is not configured to edit LDAP if a system is configured as an LDAP 
client (that functionality exists but usually is only used by admins’ scripts 
with custom config files); shadow-utils even can’t do it at all.  AFAIK both 
are quite usable in the environment described above.

 It appears to me that libuser unsuccessfully duplicates APIs from glibc,
 shadow-utils and other packages.

Yes, it only duplicates a glibc API if we ignore all the code that isn’t in 
glibc, including all the things that systemd-sysusers got wrong; and 
shadow-utils doesn’t have a C API so libuser doesn’t duplicate a shadow-utils 
API.

 I mean, it's quite weird to have both
 passwd and lpasswd around, and then complaining to me that we don't
 need multiple implementations. I mean, I really don't understand why
 there are two implementations of this in the first place!

I was not proposing to call the libuser command-line tools, so I don’t think 
they are relevant.  I agree it is not good that there are two implementations, 
and as I already wrote, there is a plan (and people assigned to it) to fix this.

 Also, note that with systemd we try to find solutions that work for most
 Linux distributions. libuser appears to be quite common on Fedora, but I
 am pretty sure that systemd is not the vehicle to make it standard on
 other distributions too, in particular via such a relatively auxiliary
 feature of systemd.

systemd has been happy to make so many different things de-facto standard that 
I can’t see this being an outlier.


  As it is, the implementation
(Most discussed elsewhere in the thread.)

  * breaks the configurable [UG]ID_MIN logic
  (http://fedoraproject.org/wiki/Features/1000SystemAccounts, and yes,
  that is actually used and needed)
 
 Well, this is something I really don't like.

I don’t like this either, but it is necessary and unavoidable.  “I don’t want” 
and “sorry” just isn’t good enough for real-world deployments; that can only 
get a distribution kicked off the candidate list.


  We are currently already in a bad position by having two major
  implementations of maintaining the critical databases, we absolutely
  don’t want any more.
 
 Good! We just use glibc APIs for writing those files. If you want only
 one implementation, why not get rid of libuser, and stick to glibc? ;-)

Because the glibc API is not at all the right one.  (Way too low-level as 
systemd-sysusers has successfully demonstrated; impossible to add more fields; 
enshrines old bad design decisions, like having password expiration in 24-hour 
granularity.)  Considering the actual library name is completely irrelevant, 
having the new API written and maintained by people whose _primary occupation_ 
is to understand accounts and identities seems like a good enough reason to 
have it done by sssd maintainers, as a library included within that project.

And yes, the plan is to “get rid of libuser”, or rather to only have it a shim 
layer over the new sssd API.

  At this point this means systemd-sysuers should either run the
  executables from shadow-utils, or link to libuser.  (Or, I suppose,
  use accountsservice, but that ends up calling shadow-utils.).
 
 Sorry, I am not going to play your stacking game. This is supposed to be
 simple, work in a minimal early-boot environment, and use stuff that is
 commonly around on Linuxes, from embedded to servers. glibc APIs
 are. libuser is not.

I would be perfectly happy if it called shadow-utils.  That’s 200 kB total, and 
definitely “commonly around on Linuxes”.

Describing modularity, avoiding duplicate implementations, and keeping 
specialized knowledge private to specialized modules as a “stacking game” is 
not helping this discussion.

  The plan is to have a single implementation,

Re: New Fedora 22 Change proposal: systemd-sysusers

- Original Message -
 On Wed, 09.07.14 12:25, Miloslav Trmač (m...@redhat.com) wrote:
   Can you be more specific about the name validation?
 
  The binding maximum length constraint is from the utmp format
  (UT_NAMESIZE - 1); LOGIN_NAME_MAX is an upper bound but not binding,
  and this has already ended up in systemd-sysuser’s documentation
  essentially promising to do the impossible/unsafe by using the
  non-binding maximum length.
snip
 If 32chars as required by utmp is really the limit we should follow
 here, then I would really enjoy if we'd actually set LOGIN_NAME_MAX to
 the same value.

I agree that would be useful, but it would also break the glibc ABI I’m afraid 
(and undefining LOGIN_NAME_MAX to indicate that sysconf() should be used would 
break “only” the API).  Yeah, the utmp connection is apparently not obvious to 
many people.

 Hmm, it would be good btw, if libuser would actually use glibc APIs, for
 the precise reasons you are pointing out. As it appears though you
 reimplemented all those APIs for no reason...

For the excuse, I have inherited that code, and it is a part of the module API 
so not that attractive to just drop.  As for future plans, I’m not inclined to 
rewrite this just for fun, especially when this is all going away in a about a 
year.

 Oh, also, libuser is a glib API. Nothing against glibc, but for the
 low-level stuff we do that runs with nothing around we try to be OOM
 safe, and stuff...
I’m afraid the libuser’s ABI embeds a GLib dependency, so it won’t be removed; 
though recent-ish additions have added enough utility functions that many users 
of libuser don’t have to touch GLib themselves.

*shrug* OOM-safety in a non-daemon is not all that useful.  The right thing to 
do of course would be to use a way higher-level language that does 90% of what 
GLib does inherently as a part of the language instead of having to choose, and 
disagree about, a C utility library, but that’s where we are…
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

orphaning iperf (2.0.X)

2014-07-09 Thread Gabriel Somlo

iperf 2.0.* has a dead upstream, but last I checked 3.0.* (for which there 
appears to be a distinct rpm package,
not maintained by me) isn't offering 100% feature parity. Not talking about 2.X 
- 3.X compatibility, but rather
what all the 2.0 flags do vs. what the 3.X ones do :)

Anyhow, while I think it might be still worth keeping 2.X around, I am totally 
swamped at the moment and can't
do it justice, so free to a good home.

Potential maintainers, please note there are two open bugs against iperf 2.0.5: 
1108805 and 1116917, which you'd
be inheriting as well.

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

libuv 0.11.x for rawhide

2014-07-09 Thread Igor Gnatenko

Hi,

I'm packaging neovim for Fedora and my builds failing[0], because
using feature not available in 0.10.x releases.
In Fedora libuv seems 0.10.x, so can you update it to 0.11.26 (now)?
It's available[1].
If you don't want to break many packages, which using libuv - you can
update it for rawhide. because f21 already branched - we can break
rawhide I tho.

[0]http://copr-be.cloud.fedoraproject.org/results/ignatenkobrain/neovim/fedora-rawhide-x86_64/neovim-0.0.0-1.git308953e.fc21/build.log
[1]https://github.com/joyent/libuv/releases
-- 
-Igor Gnatenko
-- 
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: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!

2014-07-09 Thread Mike Pinkerton



On 7 Jul 2014, at 11:17, Josh Boyer wrote:

On Mon, Jul 7, 2014 at 9:02 AM, Stephen Gallagher  
sgall...@redhat.com wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/06/2014 03:43 AM, William wrote:

On Thu, 2014-07-03 at 10:05 -0400, Josh Boyer wrote:


That's misleading.  Fedora hasn't been releasing
do-it-yourself releases.  Our previous install images were
composed and tested by QA, including testing fedup upgrades from
the previous release.  With Fedora.next, we don't have an install
image that is an equivalent of = F20.

Perhaps I have missed them, but I've seen no discussion or plans
around testing upgrades to F21 from F20.  Unless the Products
intend to test upgrading from F20, and/or QA intends to somehow
test fedup from F20 to F21 in a non-product manner, we're
essentially changing the semantics of upgrades.  I agree it
should still work, but saying it's a continuation of existing
practice when it isn't is wrong.

josh



It's also misleading given how much focus has been given to the
three new products that will be released: So why now is there a
non-productised version? That's not been advertised much.



I honestly don't know how much more we could have advertised that.
We've been talking about it since the beginning. Particularly about
how the Fedora Products are additive to the classic Fedora and that
spins aren't going away (they're non-productized versions too).


You're talking about additive in the they all use the same repos
sense, but there is no planned install media that will be produced
similar to the F20 release.  There are the 3 products, and there are
the spins.  The product closest to the existing Fedora default is
Workstation, and we're targeting a live media as the primary
deliverable.  There have been 0 plans or discussions around
fedup/upgrades from F20 so far.




While I appreciate that the Fedora project has goals that it wants to  
achieve with the three new products, I had assumed based on the  
explanations that I have read that:


1.  There will not be any change in the repo structure -- no separate  
repos for separate products.


2.  For those of us who are not interested in the new products or  
do not find their minimum package assurances to be important in our  
use cases, there will still be a traditional non-productized Fedora.


3.  There will still be plain non-productized versions of /etc/os- 
release (or wherever the systemd guys are relocating it) and /etc/ 
fedora-release.


4.  There would be, at least, a net install CD to install a  
traditional non-productized Fedora system.


5.  A fedup upgrade will be possible from a traditional non- 
productized Fedora 20 system to a traditional non-productized  
Fedora 21 system and, in due time, from traditional non-productized  
Fedora 21 to 22, etc.


Am I mistaken on any or all of this?

--
Mike Pinkerton


--
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: libuv 0.11.x for rawhide

2014-07-09 Thread Bruno Wolff III


On Wed, Jul 09, 2014 at 23:00:12 +0400,
 Igor Gnatenko i.gnatenko.br...@gmail.com wrote:

Hi,

I'm packaging neovim for Fedora and my builds failing[0], because
using feature not available in 0.10.x releases.
In Fedora libuv seems 0.10.x, so can you update it to 0.11.26 (now)?


Have you filed a bug against libuv for this (if there isn't already one).

You could also offer to co-maintain libuv if you are willing to do that 
to speed things up. In that case I'd give the contact a heads up of 
what you want to do when you request access.

--
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: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!

2014-07-09 Thread Stephen Gallagher

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/09/2014 03:07 PM, Mike Pinkerton wrote:
 
 On 7 Jul 2014, at 11:17, Josh Boyer wrote:
 
 On Mon, Jul 7, 2014 at 9:02 AM, Stephen Gallagher 
 sgall...@redhat.com wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 07/06/2014 03:43 AM, William wrote:
 On Thu, 2014-07-03 at 10:05 -0400, Josh Boyer wrote:
 
 That's misleading.  Fedora hasn't been releasing 
 do-it-yourself releases.  Our previous install images
 were composed and tested by QA, including testing fedup
 upgrades from the previous release.  With Fedora.next, we
 don't have an install image that is an equivalent of =
 F20.
 
 Perhaps I have missed them, but I've seen no discussion or
 plans around testing upgrades to F21 from F20.  Unless the
 Products intend to test upgrading from F20, and/or QA
 intends to somehow test fedup from F20 to F21 in a
 non-product manner, we're essentially changing the
 semantics of upgrades.  I agree it should still work, but
 saying it's a continuation of existing practice when it
 isn't is wrong.
 
 josh
 
 
 It's also misleading given how much focus has been given to
 the three new products that will be released: So why now is
 there a non-productised version? That's not been advertised
 much.
 
 
 I honestly don't know how much more we could have advertised
 that. We've been talking about it since the beginning.
 Particularly about how the Fedora Products are additive to the
 classic Fedora and that spins aren't going away (they're
 non-productized versions too).
 
 You're talking about additive in the they all use the same
 repos sense, but there is no planned install media that will be
 produced similar to the F20 release.  There are the 3 products,
 and there are the spins.  The product closest to the existing
 Fedora default is Workstation, and we're targeting a live media
 as the primary deliverable.  There have been 0 plans or
 discussions around fedup/upgrades from F20 so far.
 
 
 
 While I appreciate that the Fedora project has goals that it wants
 to achieve with the three new products, I had assumed based on
 the explanations that I have read that:
 
 1.  There will not be any change in the repo structure -- no
 separate repos for separate products.
 

This is true.


 2.  For those of us who are not interested in the new products or
 do not find their minimum package assurances to be important in our
 use cases, there will still be a traditional non-productized
 Fedora.
 

This is nuanced. Fedora as a non-Productized repository will exist.
See below.


 3.  There will still be plain non-productized versions of 
 /etc/os-release (or wherever the systemd guys are relocating it)
 and /etc/fedora-release.
 

This is true.


 4.  There would be, at least, a net install CD to install a
 traditional non-productized Fedora system.
 

This is not strictly true. The *official* install media will be for
one of the Products. There will also be install media and/or live
images for the Spins. These Spins will essentially be installing
specific package sets from non-productized Fedora.

I do not know which or if any Spins will be providing the specific net
install CD you're asking about. This will not be an *official* (read:
tested by QA) method of installing Fedora. However, I see no reason
why it wouldn't work.


 5.  A fedup upgrade will be possible from a traditional 
 non-productized Fedora 20 system to a traditional
 non-productized Fedora 21 system and, in due time, from
 traditional non-productized Fedora 21 to 22, etc.
 

This statement is true for F20-F21. For F21-F22, I want it to be
possible to go from non-productized to productized *if the user
wishes* (opt-in, not opt-out).


 Am I mistaken on any or all of this?
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlO9qS8ACgkQeiVVYja6o6Oa3ACbBm+zSBn3I2WLRhjU35d16644
emEAnjSHRMoSOX3aGXrobm+uxzYbSfaG
=e1DI
-END 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: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!

On Wed, Jul 09, 2014 at 04:42:23PM -0400, Stephen Gallagher wrote:
 I do not know which or if any Spins will be providing the specific net
 install CD you're asking about. This will not be an *official* (read:
 tested by QA) method of installing Fedora. However, I see no reason
 why it wouldn't work.


A few months ago* I remember the server WG talking about providing a
minimal/netinstall image. Has this changed?

* dredges up meeting logs --
  
http://meetbot.fedoraproject.org/teams/server-wg/server-wg.2014-02-25-16.00.html


-- 
Matthew Miller
mat...@fedoraproject.org
Fedora Project Leader
-- 
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: New Fedora 22 Change proposal: systemd-sysusers

On Wed, 09.07.14 13:47, Miloslav Trmač (m...@redhat.com) wrote:

  Yeah, because we dodn't want to intrdocue any new API we have carefully
  made sure that whenever we write pasword, group and shadow files we use
  existing APIs from glibc, more specifically putpwent(), putgrent(),
  putspent() and crypt_r().
 
  This is about creating system users, not normal users, hence using
  anything more fancy than glibc's native APIs is wrong.
 
 I have already given examples where using a higher-level API would
 avoid mistakes _and_ make future changes easier; and none of the
 reasons offered convince me:

Well, there appears to be no higher-level API around. You are saying
yourself that libuser is going away. It's also not OOM safe, pulls in
the glib dependency, it bypassed the low-level glibc APIs. So I am not
sure what you are telling me with that...

We use the only widely established API there is, and that has a future,
that is documented (though not parcitularly well), that is OOM safe,
doesn't pull in any deps, and is pretty much exactly as low-level as we
need it. That's glibc. I really don't see any other option here.

  It appears to me that libuser unsuccessfully duplicates APIs from glibc,
  shadow-utils and other packages.
 
 Yes, it only duplicates a glibc API if we ignore all the code that
 isn’t in glibc, including all the things that systemd-sysusers got
 wrong; and shadow-utils doesn’t have a C API so libuser doesn’t
 duplicate a shadow-utils API.

Well, You should be aware that sysusers is less than a month old and has
been part of a systemd release less than a week ago for the first
time. If the only thing you could find is the user name length thing,
the lack of updating of shadow and that we lack audit (which libuser
also lacks), then I think we did a pretty good job so far...

  I mean, it's quite weird to have both
  passwd and lpasswd around, and then complaining to me that we don't
  need multiple implementations. I mean, I really don't understand why
  there are two implementations of this in the first place!
 
 I was not proposing to call the libuser command-line tools, so I don’t
 think they are relevant.  I agree it is not good that there are two
 implementations, and as I already wrote, there is a plan (and people
 assigned to it) to fix this.

Well, the plans are vague, involve daemons and stuff, and from all I
heard are really not the right thing for a minimalist early-boot tool
like systemd-sysusers...

  Also, note that with systemd we try to find solutions that work for most
  Linux distributions. libuser appears to be quite common on Fedora, but I
  am pretty sure that systemd is not the vehicle to make it standard on
  other distributions too, in particular via such a relatively auxiliary
  feature of systemd.
 
 systemd has been happy to make so many different things de-facto
 standard that I can’t see this being an outlier.

Well, we can push stuff with systemd, sure, but it has to be convincing
if we do it, we must be able to make a strong case. And quite frankly,
you really didn't sell libuser so well, so far... I mean, you are even
saying that it will go away...

 
  Good! We just use glibc APIs for writing those files. If you want only
  one implementation, why not get rid of libuser, and stick to glibc? ;-)
 
 Because the glibc API is not at all the right one.  (Way too low-level
 as systemd-sysusers has successfully demonstrated; impossible to add
 more fields; enshrines old bad design decisions, like having password
 expiration in 24-hour granularity.)  Considering the actual library
 name is completely irrelevant, having the new API written and
 maintained by people whose _primary occupation_ is to understand
 accounts and identities seems like a good enough reason to have it
 done by sssd maintainers, as a library included within that project.

Well, you know, systemd-sysusers, as the name says is a tool solely
for registering system users. Sure, the glibc API might not be the best
in the world, but it does do the basic bits that we need it to do just
fine.

And the thing about primary occupation I can only read that you are
telling me to stay off your lawn, because I don't understand
stuff. 

 And yes, the plan is to “get rid of libuser”, or rather to only have
 it a shim layer over the new sssd API.

I am sorry, but I really don't see system user registration in the
early-boot as something I would ever entrust in a full flegded sssd-like
thing.

Please understand that we are not duplicating adduser here. Already in
the name of the tool we wanted to make clear thtat this is abotu system
users, nothing else. The file format we defined has been reduced to the
minimum possible, in order to make it difficult for people to use it for
anything else than this (for example, you cannot set a shell for a user
with this, as system users are not suppoed to be logged into, unless the
admin later on manually sets a password and a shell).

An API that wants to implement a

F-21 Branched report: 20140709 changes

2014-07-09 Thread Fedora Branched Report

Compose started at Wed Jul  9 20:16:43 UTC 2014

Broken deps for armhfp
--
[APLpy]
APLpy-0.9.8-5.fc21.noarch requires pywcs
[PyKDE]
PyKDE-3.16.6-14.fc20.armv7hl requires sip-api(10) = 0:10.0
[audtty]
audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2
[csound]
csound-java-5.19.01-1.fc20.armv7hl requires libgcj_bc.so.1
csound-java-5.19.01-1.fc20.armv7hl requires java-gcj-compat
csound-java-5.19.01-1.fc20.armv7hl requires java-gcj-compat
csound-java-5.19.01-1.fc20.armv7hl requires java-1.5.0-gcj
csound-tk-5.19.01-1.fc20.armv7hl requires libtk8.5.so
csound-tk-5.19.01-1.fc20.armv7hl requires libtcl8.5.so
[deltacloud-core]
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudfiles)
[dragonegg]
dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21
[eclipse-jbosstools]
eclipse-jbosstools-jst-4.1.1-2.fc21.noarch requires eclipse-wtp-jst-web
eclipse-jbosstools-ws-4.1.1-2.fc21.noarch requires 
osgi(org.eclipse.jst.ws.annotations.core)
[edelib]
edelib-2.1-4.fc21.armv7hl requires libedelib.so
edelib-devel-2.1-4.fc21.armv7hl requires libedelib.so
[eucalyptus]
eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl 
requires hibernate3-jbosscache = 0:3.6.10-7
[flashrom]
flashrom-0.9.6.1-5.svn1705.fc20.armv7hl requires libftdi.so.1
[gcc-python-plugin]
gcc-python2-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 
0:4.8.2-14.fc21
gcc-python2-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21
gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires 
libpython3.3dm.so.1.0
gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 
0:4.8.2-14.fc21
gcc-python3-plugin-0.12-18.fc21.armv7hl requires libpython3.3m.so.1.0
gcc-python3-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21
[ghc-crypto-api]
ghc-crypto-api-devel-0.11-5.fc21.armv7hl requires 
ghc-devel(entropy-0.2.2.1-ae359458c8f3b4c8838403b8c9a5a50a)
[gnome-python2-desktop]
gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires 
libmetacity-private.so.0
[gofer]
ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0
[golang-github-smarterclayton-go-systemd]

golang-github-smarterclayton-go-systemd-devel-0-0.5.git5cb9e9e.fc21.noarch 
requires golang(github.com/guelfey/go.dbus)
[grass]
grass-6.4.3-5.fc21.armv7hl requires libtk8.5.so
grass-6.4.3-5.fc21.armv7hl requires libtcl8.5.so
[hfsutils]
hfsutils-x11-3.2.6-24.fc20.armv7hl requires libtk8.5.so
hfsutils-x11-3.2.6-24.fc20.armv7hl requires libtcl8.5.so
[hibernate-search]
hibernate-search-4.5.1-4.fc21.noarch requires mvn(org.apache.avro:avro)
[ice]
ice-php-3.5.1-4.fc21.armv7hl requires php(zend-abi) = 0:20121212-32
ice-php-3.5.1-4.fc21.armv7hl requires php(api) = 0:20121113-32
[jacorb]
jacorb-2.3.1-12.fc21.noarch requires 
UNKNOWN-mvn(org.beanshell:bsh:UNKNOWN)
[jboss-integration]
jboss-integration-6.0.0-0.3.CR1.fc21.noarch requires mvn(jacorb:jacorb)
[leiningen]
leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks
leiningen-1.7.1-7.fc20.noarch requires classworlds
[libghemical]
libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3
libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3
[libopensync-plugin-irmc]
1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1
[ltsp]
ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs
ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog
[mapserver]
mapserver-java-6.2.1-7.fc21.armv7hl requires java-gcj-compat
[meshmagick]
meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1
meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires 
libOgreMain.so.1.8.1
[mingw-tk]
mingw32-tk-8.5.13-5.fc21.noarch requires mingw32(tcl85.dll)
[netdisco]
netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay)
[openvas-client]
openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_omp.so.6
openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_nasl.so.6
openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_misc.so.6
openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_hg.so.6
openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_base.so.6
[orsa]
orsa-0.7.0-28.fc21.armv7hl requires libginac.so.2
orsa-mpich-0.7.0-28.fc21.armv7hl requires libginac.so.2
orsa-openmpi-0.7.0-28.fc21.armv7hl requires libginac.so.2
[php-pecl-parsekit]
php-pecl-parsekit-1.3.0-5.fc21.armv7hl requires php(zend-abi) = 
0:20121212-32
php-pecl-parsekit-1.3.0-5.fc21.armv7hl requires php(api) = 0:20121113-32
[python-pygit2]
python-pygit2-0.20.2-3.fc21.armv7hl requires libgit2.so.0

Re: New Fedora 22 Change proposal: systemd-sysusers

2014-07-09 Thread Oron Peled


A non-API related question...

On Thursday 10 July 2014 01:49:41 Lennart Poettering wrote:
 Please understand that we are not duplicating adduser here. Already in
 the name of the tool we wanted to make clear thtat this is abotu system
 users, nothing else. The file format we defined has been reduced to the
 minimum possible, in order to make it difficult for people to use it for
 anything else than this.

There are cases where a home directory of system users carry some semantics.

Two examples from the top of my head:
 * Some tftpd implementations use it as the base path (and chroot into it)
 * Some anonymous ftpd implementation have similar use (chroot into ~ftp)

So I assume *all* of these cases should be replaced by systemd explicit
settings -- e.g: WorkingDirectory, RootDirectory in the unit file.

Generally, I prefer the explicit systemd settings over home directory
with magical effects, but I wonder if anyone is aware of existing
system users which carry more complex semantics.

Thanks,

-- 
Oron Peled Voice: +972-4-8228492
o...@actcom.co.il  http://users.actcom.co.il/~oron
Promises are like babies: fun to make, but hell to deliver.
   -- Nadav Har'El

-- 
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: [ACTION REQUIRED][FINAL NOTICE] Retiring packages for Fedora 21 v4

2014-07-09 Thread Adam Williamson

On Tue, 2014-07-01 at 19:55 +0200, Till Maas wrote:
 The following packages are orphaned or did not build for two
 releases and will be retired when Fedora (F21) is branched, unless someone
 adopts them. If you know for sure that the package should be retired, please 
 do
 so now with a proper reason:
 https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
 
 According to https://fedoraproject.org/wiki/Schedule branching will
 occur on 2014-07-08. The packages will be retired starting 2014-07-04.
 If you intend to claim a package, please take it now.

ddclient seems to have been retired apparently as a part of this
process, going by the commit:

http://pkgs.fedoraproject.org/cgit/ddclient.git/commit/?id=f741436ca38fd6c36ffbfbb26b3131b278657faa

but it wasn't listed in this email. Was that an oversight? Was it listed
somewhere else I didn't catch? It does show up as 'orphaned' in pkgdb:
https://admin.fedoraproject.org/pkgdb/package/ddclient/ .
-- 
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

[Bug 1116600] perl-IO-Socket-IP-0.30 is available

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

Petr Pisar ppi...@redhat.com changed:

   What|Removed |Added

 Status|ON_QA   |ASSIGNED
External Bug ID||CPAN 95983



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

[Bug 1116600] perl-IO-Socket-IP-0.30 is available

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

Petr Pisar ppi...@redhat.com changed:

   What|Removed |Added

External Bug ID||CPAN 97050



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

[Bug 1116600] perl-IO-Socket-IP-0.30 is available

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

Petr Pisar ppi...@redhat.com changed:

   What|Removed |Added

   Assignee|psab...@redhat.com  |ppi...@redhat.com



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

[perl-IO-Socket-IP] Fix multihomed SSL

commit 8efa4cc6d6d8d39fe3e73678c2553f5b8fd77303
Author: Petr Písař ppi...@redhat.com
Date:   Wed Jul 9 09:21:46 2014 +0200

Fix multihomed SSL

 IO-Socket-IP-0.30-multihomed_SSL.patch |   58 
 perl-IO-Socket-IP.spec |8 -
 2 files changed, 65 insertions(+), 1 deletions(-)
---
diff --git a/IO-Socket-IP-0.30-multihomed_SSL.patch 
b/IO-Socket-IP-0.30-multihomed_SSL.patch
new file mode 100644
index 000..1223385
--- /dev/null
+++ b/IO-Socket-IP-0.30-multihomed_SSL.patch
@@ -0,0 +1,58 @@
+Am Di 08. Jul 2014, 06:35:58, PEVANS schrieb:
+ I may have to revert this one because it's causing bad knock-on
+ effects with IO::Socket::SSL:
+ 
+ https://rt.cpan.org/Ticket/Display.html?id=97050
+ 
+ Basically: the very thing it was supposed to fix, it has broken. Meh.
+
+Yes, unfortunately it wasn't as easy as I thought because the calling scheme 
inside IO::Socket::* (i.e. new - configure - connect ) isn't that simple if 
you have a class hierarchy and also try to implement multi-homing :(
+
+But I think I have a working patch (included, against 0.30).
+The basic idea of the patch is that one has to distinguish between an error at 
the transport layer which can be solved with IP based multi-homing and an error 
at the application layer. One could expect the system error to be reflected 
inside $!, while an application error will probably not set $! (e.g. 
IO::Socket::SSL sets an $SSL_ERROR variable). So if connect fails, but $! is 
not set, one can assume error at the application layer and stop trying to fix 
it with IP based multi-homing.
+
+The other difference in the patch is to change 
$self-IO::Socket::IP::connect($addr) to CORE::connect($self,$addr), because if 
you have a look at the connect function it simple calls CORE::connect if an 
$addr argument is given. It was already right to not use $self-connect in this 
place, it was only a problem if called from inside the new - configure - 
connect chain.
+
+With this patch the tests inside IO::Socket::IP pass and also the tests of 
IO::Socket::SSL.
+
+Regards,
+Steffen
+
+https://rt.cpan.org/Public/Bug/Display.html?id=95983
+
+diff --git a/lib/IO/Socket/IP.pm b/lib/IO/Socket/IP.pm
+index 1911145..16eb7c8 100644
+--- a/lib/IO/Socket/IP.pm
 b/lib/IO/Socket/IP.pm
+@@ -601,7 +601,7 @@ sub setup
+   }
+ 
+   if( defined( my $addr = $info-{peeraddr} ) ) {
+- if( $self-IO::Socket::IP::connect( $addr ) ) {
++ if( $self-connect( $addr ) ) {
+ $! = 0;
+ return 1;
+  }
+@@ -611,6 +611,13 @@ sub setup
+ return 0;
+  }
+ 
++   # If connect failed but we have no system error there must be an error
++   # at the application layer, like a bad certificate with
++   # IO::Socket::SSL.
++   # In this case don't continue IP based multi-homing because the problem
++   # cannot be solved at the IP layer.
++   return 0 if ! $!;
++
+  ${*$self}{io_socket_ip_errors}[0] = $!;
+  next;
+   }
+@@ -651,7 +658,7 @@ sub connect
+# (still in progress). This even works on MSWin32.
+my $addr = 
${*$self}{io_socket_ip_infos}[${*$self}{io_socket_ip_idx}]{peeraddr};
+ 
+-   if( $self-IO::Socket::IP::connect( $addr ) or $! == EISCONN ) {
++   if( CORE::connect( $self, $addr ) or $! == EISCONN ) {
+   delete ${*$self}{io_socket_ip_connect_in_progress};
+   $! = 0;
+   return 1;
diff --git a/perl-IO-Socket-IP.spec b/perl-IO-Socket-IP.spec
index 39d83cb..611ccdf 100644
--- a/perl-IO-Socket-IP.spec
+++ b/perl-IO-Socket-IP.spec
@@ -1,11 +1,13 @@
 Name:   perl-IO-Socket-IP
 Version:0.30
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Drop-in replacement for IO::Socket::INET supporting both IPv4 
and IPv6
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/IO-Socket-IP/
 Source0:
http://www.cpan.org/authors/id/P/PE/PEVANS/IO-Socket-IP-%{version}.tar.gz
+# Fix multihomed SSL, bug #1116600, CPAN RT#95983
+Patch0: IO-Socket-IP-0.30-multihomed_SSL.patch
 BuildArch:  noarch
 BuildRequires:  perl
 BuildRequires:  perl(base)
@@ -33,6 +35,7 @@ arguments and methods are provided in a backward-compatible 
way.
 
 %prep
 %setup -q -n IO-Socket-IP-%{version}
+%patch0 -p1
 
 %build
 perl Build.PL installdirs=vendor
@@ -53,6 +56,9 @@ rm -f t/21nonblocking-connect-internet.t
 %{_mandir}/man3/*
 
 %changelog
+* Wed Jul 09 2014 Petr Pisar ppi...@redhat.com - 0.30-2
+- Fix multihomed SSL (bug #1116600)
+
 * Mon Jul 07 2014 Petr Pisar ppi...@redhat.com - 0.30-1
 - 0.30 bump
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-IO-Socket-IP/f21] Fix multihomed SSL

Summary of changes:

  8efa4cc... Fix multihomed SSL (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-IO-Socket-IP/f20] Fix multihomed SSL

commit 817e1f51da9591d219d7d005b99f6eb9497dd464
Author: Petr Písař ppi...@redhat.com
Date:   Wed Jul 9 09:21:46 2014 +0200

Fix multihomed SSL

 IO-Socket-IP-0.30-multihomed_SSL.patch |   58 
 perl-IO-Socket-IP.spec |8 -
 2 files changed, 65 insertions(+), 1 deletions(-)
---
diff --git a/IO-Socket-IP-0.30-multihomed_SSL.patch 
b/IO-Socket-IP-0.30-multihomed_SSL.patch
new file mode 100644
index 000..1223385
--- /dev/null
+++ b/IO-Socket-IP-0.30-multihomed_SSL.patch
@@ -0,0 +1,58 @@
+Am Di 08. Jul 2014, 06:35:58, PEVANS schrieb:
+ I may have to revert this one because it's causing bad knock-on
+ effects with IO::Socket::SSL:
+ 
+ https://rt.cpan.org/Ticket/Display.html?id=97050
+ 
+ Basically: the very thing it was supposed to fix, it has broken. Meh.
+
+Yes, unfortunately it wasn't as easy as I thought because the calling scheme 
inside IO::Socket::* (i.e. new - configure - connect ) isn't that simple if 
you have a class hierarchy and also try to implement multi-homing :(
+
+But I think I have a working patch (included, against 0.30).
+The basic idea of the patch is that one has to distinguish between an error at 
the transport layer which can be solved with IP based multi-homing and an error 
at the application layer. One could expect the system error to be reflected 
inside $!, while an application error will probably not set $! (e.g. 
IO::Socket::SSL sets an $SSL_ERROR variable). So if connect fails, but $! is 
not set, one can assume error at the application layer and stop trying to fix 
it with IP based multi-homing.
+
+The other difference in the patch is to change 
$self-IO::Socket::IP::connect($addr) to CORE::connect($self,$addr), because if 
you have a look at the connect function it simple calls CORE::connect if an 
$addr argument is given. It was already right to not use $self-connect in this 
place, it was only a problem if called from inside the new - configure - 
connect chain.
+
+With this patch the tests inside IO::Socket::IP pass and also the tests of 
IO::Socket::SSL.
+
+Regards,
+Steffen
+
+https://rt.cpan.org/Public/Bug/Display.html?id=95983
+
+diff --git a/lib/IO/Socket/IP.pm b/lib/IO/Socket/IP.pm
+index 1911145..16eb7c8 100644
+--- a/lib/IO/Socket/IP.pm
 b/lib/IO/Socket/IP.pm
+@@ -601,7 +601,7 @@ sub setup
+   }
+ 
+   if( defined( my $addr = $info-{peeraddr} ) ) {
+- if( $self-IO::Socket::IP::connect( $addr ) ) {
++ if( $self-connect( $addr ) ) {
+ $! = 0;
+ return 1;
+  }
+@@ -611,6 +611,13 @@ sub setup
+ return 0;
+  }
+ 
++   # If connect failed but we have no system error there must be an error
++   # at the application layer, like a bad certificate with
++   # IO::Socket::SSL.
++   # In this case don't continue IP based multi-homing because the problem
++   # cannot be solved at the IP layer.
++   return 0 if ! $!;
++
+  ${*$self}{io_socket_ip_errors}[0] = $!;
+  next;
+   }
+@@ -651,7 +658,7 @@ sub connect
+# (still in progress). This even works on MSWin32.
+my $addr = 
${*$self}{io_socket_ip_infos}[${*$self}{io_socket_ip_idx}]{peeraddr};
+ 
+-   if( $self-IO::Socket::IP::connect( $addr ) or $! == EISCONN ) {
++   if( CORE::connect( $self, $addr ) or $! == EISCONN ) {
+   delete ${*$self}{io_socket_ip_connect_in_progress};
+   $! = 0;
+   return 1;
diff --git a/perl-IO-Socket-IP.spec b/perl-IO-Socket-IP.spec
index 2c059f6..7b30952 100644
--- a/perl-IO-Socket-IP.spec
+++ b/perl-IO-Socket-IP.spec
@@ -1,11 +1,13 @@
 Name:   perl-IO-Socket-IP
 Version:0.30
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Drop-in replacement for IO::Socket::INET supporting both IPv4 
and IPv6
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/IO-Socket-IP/
 Source0:
http://www.cpan.org/authors/id/P/PE/PEVANS/IO-Socket-IP-%{version}.tar.gz
+# Fix multihomed SSL, bug #1116600, CPAN RT#95983
+Patch0: IO-Socket-IP-0.30-multihomed_SSL.patch
 BuildArch:  noarch
 BuildRequires:  perl
 BuildRequires:  perl(base)
@@ -33,6 +35,7 @@ arguments and methods are provided in a backward-compatible 
way.
 
 %prep
 %setup -q -n IO-Socket-IP-%{version}
+%patch0 -p1
 
 %build
 perl Build.PL installdirs=vendor
@@ -53,6 +56,9 @@ rm -f t/21nonblocking-connect-internet.t
 %{_mandir}/man3/*
 
 %changelog
+* Wed Jul 09 2014 Petr Pisar ppi...@redhat.com - 0.30-2
+- Fix multihomed SSL (bug #1116600)
+
 * Mon Jul 07 2014 Petr Pisar ppi...@redhat.com - 0.30-1
 - 0.30 bump
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-IO-Socket-IP/f19] Fix multihomed SSL

commit 6f804a3698febc0fd4f11b5102b7d44715913179
Author: Petr Písař ppi...@redhat.com
Date:   Wed Jul 9 09:21:46 2014 +0200

Fix multihomed SSL

 IO-Socket-IP-0.30-multihomed_SSL.patch |   58 
 perl-IO-Socket-IP.spec |8 -
 2 files changed, 65 insertions(+), 1 deletions(-)
---
diff --git a/IO-Socket-IP-0.30-multihomed_SSL.patch 
b/IO-Socket-IP-0.30-multihomed_SSL.patch
new file mode 100644
index 000..1223385
--- /dev/null
+++ b/IO-Socket-IP-0.30-multihomed_SSL.patch
@@ -0,0 +1,58 @@
+Am Di 08. Jul 2014, 06:35:58, PEVANS schrieb:
+ I may have to revert this one because it's causing bad knock-on
+ effects with IO::Socket::SSL:
+ 
+ https://rt.cpan.org/Ticket/Display.html?id=97050
+ 
+ Basically: the very thing it was supposed to fix, it has broken. Meh.
+
+Yes, unfortunately it wasn't as easy as I thought because the calling scheme 
inside IO::Socket::* (i.e. new - configure - connect ) isn't that simple if 
you have a class hierarchy and also try to implement multi-homing :(
+
+But I think I have a working patch (included, against 0.30).
+The basic idea of the patch is that one has to distinguish between an error at 
the transport layer which can be solved with IP based multi-homing and an error 
at the application layer. One could expect the system error to be reflected 
inside $!, while an application error will probably not set $! (e.g. 
IO::Socket::SSL sets an $SSL_ERROR variable). So if connect fails, but $! is 
not set, one can assume error at the application layer and stop trying to fix 
it with IP based multi-homing.
+
+The other difference in the patch is to change 
$self-IO::Socket::IP::connect($addr) to CORE::connect($self,$addr), because if 
you have a look at the connect function it simple calls CORE::connect if an 
$addr argument is given. It was already right to not use $self-connect in this 
place, it was only a problem if called from inside the new - configure - 
connect chain.
+
+With this patch the tests inside IO::Socket::IP pass and also the tests of 
IO::Socket::SSL.
+
+Regards,
+Steffen
+
+https://rt.cpan.org/Public/Bug/Display.html?id=95983
+
+diff --git a/lib/IO/Socket/IP.pm b/lib/IO/Socket/IP.pm
+index 1911145..16eb7c8 100644
+--- a/lib/IO/Socket/IP.pm
 b/lib/IO/Socket/IP.pm
+@@ -601,7 +601,7 @@ sub setup
+   }
+ 
+   if( defined( my $addr = $info-{peeraddr} ) ) {
+- if( $self-IO::Socket::IP::connect( $addr ) ) {
++ if( $self-connect( $addr ) ) {
+ $! = 0;
+ return 1;
+  }
+@@ -611,6 +611,13 @@ sub setup
+ return 0;
+  }
+ 
++   # If connect failed but we have no system error there must be an error
++   # at the application layer, like a bad certificate with
++   # IO::Socket::SSL.
++   # In this case don't continue IP based multi-homing because the problem
++   # cannot be solved at the IP layer.
++   return 0 if ! $!;
++
+  ${*$self}{io_socket_ip_errors}[0] = $!;
+  next;
+   }
+@@ -651,7 +658,7 @@ sub connect
+# (still in progress). This even works on MSWin32.
+my $addr = 
${*$self}{io_socket_ip_infos}[${*$self}{io_socket_ip_idx}]{peeraddr};
+ 
+-   if( $self-IO::Socket::IP::connect( $addr ) or $! == EISCONN ) {
++   if( CORE::connect( $self, $addr ) or $! == EISCONN ) {
+   delete ${*$self}{io_socket_ip_connect_in_progress};
+   $! = 0;
+   return 1;
diff --git a/perl-IO-Socket-IP.spec b/perl-IO-Socket-IP.spec
index 2c059f6..7b30952 100644
--- a/perl-IO-Socket-IP.spec
+++ b/perl-IO-Socket-IP.spec
@@ -1,11 +1,13 @@
 Name:   perl-IO-Socket-IP
 Version:0.30
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Drop-in replacement for IO::Socket::INET supporting both IPv4 
and IPv6
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/IO-Socket-IP/
 Source0:
http://www.cpan.org/authors/id/P/PE/PEVANS/IO-Socket-IP-%{version}.tar.gz
+# Fix multihomed SSL, bug #1116600, CPAN RT#95983
+Patch0: IO-Socket-IP-0.30-multihomed_SSL.patch
 BuildArch:  noarch
 BuildRequires:  perl
 BuildRequires:  perl(base)
@@ -33,6 +35,7 @@ arguments and methods are provided in a backward-compatible 
way.
 
 %prep
 %setup -q -n IO-Socket-IP-%{version}
+%patch0 -p1
 
 %build
 perl Build.PL installdirs=vendor
@@ -53,6 +56,9 @@ rm -f t/21nonblocking-connect-internet.t
 %{_mandir}/man3/*
 
 %changelog
+* Wed Jul 09 2014 Petr Pisar ppi...@redhat.com - 0.30-2
+- Fix multihomed SSL (bug #1116600)
+
 * Mon Jul 07 2014 Petr Pisar ppi...@redhat.com - 0.30-1
 - 0.30 bump
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1116600] perl-IO-Socket-IP-0.30 is available

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

Petr Pisar ppi...@redhat.com changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version|perl-IO-Socket-IP-0.30-1.fc |perl-IO-Socket-IP-0.30-2.fc
   |21  |22



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

[Bug 1116600] perl-IO-Socket-IP-0.30 is available

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



--- Comment #6 from Petr Pisar ppi...@redhat.com ---
Fixed as perl-IO-Socket-IP-0.30-2.fc21 in F21.

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

[Bug 1116600] perl-IO-Socket-IP-0.30 is available

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



--- Comment #7 from Fedora Update System upda...@fedoraproject.org ---
perl-IO-Socket-IP-0.30-2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/perl-IO-Socket-IP-0.30-2.fc20

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

[Bug 1116600] perl-IO-Socket-IP-0.30 is available

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



--- Comment #8 from Fedora Update System upda...@fedoraproject.org ---
perl-IO-Socket-IP-0.30-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/perl-IO-Socket-IP-0.30-2.fc19

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

[Bug 1117675] New: Request EPEL7 branch