James Laska wrote:
> 3. Package must be newer than previously released versions - can't
> ship newer package in N-1.

Definitely, but we must make sure that it's still possible to queue the same
update for N and N-1 at the same time (= without having to wait for a push
between queueing N and queueing N-1).

Kevin Kofler

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

On 03/09/2010 03:43 PM, Kevin Kofler wrote:
> James Laska wrote:
>> 3. Package must be newer than previously released versions - can't
>> ship newer package in N-1.
>
> Definitely, but we must make sure that it's still possible to queue the same
> update for N and N-1 at the same time (= without having to wait for a push
> between queueing N and queueing N-1).

I'm in the habit of queuing for N and N-1 in a single bodhi request. Is
this addressed by any of our existing or proposed update policies?

It seems to cast doubt on the value of karma -- just because something
gets lots of positive karma on N doesn't mean that N-1 is ok. Then
again, the same concern is present in any grouped update if the voters
haven't tried *all* of the packages mentioned.

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

On Tue, 2010-03-09 at 16:08 -0800, Josh Stone wrote:
> On 03/09/2010 03:43 PM, Kevin Kofler wrote:
> > James Laska wrote:
> >> 3. Package must be newer than previously released versions - can't
> >> ship newer package in N-1.
> >
> > Definitely, but we must make sure that it's still possible to queue the same
> > update for N and N-1 at the same time (= without having to wait for a push
> > between queueing N and queueing N-1).
>
> I'm in the habit of queuing for N and N-1 in a single bodhi request. Is
> this addressed by any of our existing or proposed update policies?
>
> It seems to cast doubt on the value of karma -- just because something
> gets lots of positive karma on N doesn't mean that N-1 is ok. Then
> again, the same concern is present in any grouped update if the voters
> haven't tried *all* of the packages mentioned.
>
> Josh

Even if you put an update for N and N-1 in the same form, once you
submit the request it splits it into two requests, one per Fedora
release. This means you'd have one set of karma per Fedora release.

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

On Tue, 09 Mar 2010 15:43:04 -0500
James Laska <jlaska@redhat.com> wrote:

> We'll make adjustments based on feedback so far. But I want to point
> out that one goal for this policy is to reach consensus on a set of
> criteria that all [1] packages must adhere to in order to be accepted
> as Fedora updates. The important word for me is "accepted". This
> comes long before any functional or bug verification. This is
> intended to support the fundamentals of packaging software for Fedora
> that have already been established and are used to evaluate all
> software upon entry into Fedora [2].
>
> Some basics I'd propose as a starting point for defining acceptance
> criteria include:
>
> 1. repoclosure/conflicts - no package update can introduce broken
> deps or conflicts. I'd recommend we apply this to both
> 'updates-testing' and 'updates' (but that's detailed below)
> 2. Package sanity
> * No rpmlint failures

I think this one should not be there. Or should be heavily filtered.
rpmlint sometimes marks things as errors that are not.

Or at the very least we should make sure that all the things it does
mark as error really are things we would block a package for.

Also, there are often a host of warnings...

> * Is the Source properly defined
> * License review/examination (if possible)

We should at least fail for a non valid License tag, IMHO.

> * Upstream Source match tarball

I can provide a hackish script I used for my source file audits for
this.

> * Package scriptlet syntax checks
> 3. Package must be newer than previously released versions -
> can't ship newer package in N-1.
> 4. Any additional MUST requirements folks would like to see
> covered from the package review requirements?

There could be others.

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

On 03/09/2010 04:11 PM, Jesse Keating wrote:
> Even if you put an update for N and N-1 in the same form, once you
> submit the request it splits it into two requests, one per Fedora
> release. This means you'd have one set of karma per Fedora release.

Aha, I forgot that. Thanks.

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

Jesse Keating wrote:

> On Tue, 2010-03-09 at 16:08 -0800, Josh Stone wrote:
>> It seems to cast doubt on the value of karma -- just because something
>> gets lots of positive karma on N doesn't mean that N-1 is ok. Then
>> again, the same concern is present in any grouped update if the voters
>> haven't tried *all* of the packages mentioned.
>
> Even if you put an update for N and N-1 in the same form, once you
> submit the request it splits it into two requests, one per Fedora
> release. This means you'd have one set of karma per Fedora release.

Indeed, and I'd argue that this is a problem, not a feature. If an update is
confirmed to fix an issue in the current stable release and the previous
stable release is affected by the exact same issue, I don't see a good
reason not to push the update with identical changes to the previous stable
release as well. Not doing it would result in the previous stable release
not getting bugfixes in a timely manner, if at all, anymore, as it has a lot
fewer testers.

Kevin Kofler

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

On Tue, 2010-03-09 at 17:13 -0700, Kevin Fenzi wrote:

> > Some basics I'd propose as a starting point for defining acceptance
> > criteria include:
> >
> > 1. repoclosure/conflicts - no package update can introduce broken
> > deps or conflicts. I'd recommend we apply this to both
> > 'updates-testing' and 'updates' (but that's detailed below)
> > 2. Package sanity
> > * No rpmlint failures
>
> I think this one should not be there. Or should be heavily filtered.
> rpmlint sometimes marks things as errors that are not.

+1 here. The current upstream rpmlint errors/warnings list is not what
we'd want to use to automatically approve/deny updates, I'm fairly sure.
=) We'd need to either get quite drastic changes upstream, or overlay
our own error/warning split on the tests (which is what Mandriva does;
there's an automated rpmlint run on every package submission and it
rejects packages if certain tests fail, but the definition of which
tests are critical is *not* the upstream one).

Over time this would work fine, but at the start it may possibly
introduce some absurdity due to 'grandfathered in' situations: an update
may be rejected due to some lint failure which was actually present in
the version of the package that's being updated anyway (it's not a
_change_ in the update). I'm not sure if that's really a problem - we
could just argue that the problems should be fixed and when you're
pushing an update is as good a time as any to fix them - but I thought
it'd be worth mentioning in advance just in case. Anyway, we should be
very careful and conservative to start with, in terms of what automated
tests we introduce. I'd recommend we do a week or two where we 'dry run'
the system - generate lists of updates which would have been blocked,
but don't actually block them - to make sure the results are sane,
before we start actually blocking things.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

On 03/09/2010 06:56 PM, Michael Schwendt wrote:
> On Tue, 9 Mar 2010 12:21:04 -0500 (EST), Kamil wrote:

> If you - and the QA team - want to expand your testing activities, focus
> on the CRITPATH packages first. Do a good job there. Nobody from QA has
> ever given feedback to any of my updates, and it won't happen in the
> future either. There won't be real testing of those packages unless you
> could dedicate resources like some great users do it.
ACK.

> But you can't.
Agreed. I wish all of these people who believe karma is a suiteable
means to improve quality, should actually be testing package
update-candidates and provide karma vote.

No surprise this hasn't happened: The people violently refuse to
comprehend that this approach is technically impossible.

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

----- "Adam Williamson" <awilliam@redhat.com> wrote:
> There actually already *is* a review point
> prior to moving to -updates, but it's currently owned by rel-eng and
> is
> not highly publicized, and very little gets rejected. It is there,
> though: rel-eng explained this earlier in the threads, and explained
> that they are unhappy with it being informal. I'm trying to find the
> post, but there's just too much to wade through, sorry

"Why Fedora needs an Updates Policy" from Josh Boyer:

http://jwboyer.livejournal.com/36737.html

That's why we need some defined process. That's why we need
to improve current practice. That's why all those proposals
appear.

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

Wed Mar 10 10:30:04 2010
Return-path: <389-users-bounces@lists.fedoraproject.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Wed, 10 Mar 2010 10:14:01 +0200
Received: from bastion.fedoraproject.org ([209.132.182.51]:39642)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <389-users-bounces@lists.fedoraproject.org>)
id 1NpH3I-0007YE-4Y
for tom@linux-archive.org; Wed, 10 Mar 2010 10:14:00 +0200
Received: from lists.fedoraproject.org (collab1.vpn.fedoraproject.org [192.168.1.21])
by bastion02.phx2.fedoraproject.org (Postfix) with ESMTP id 9E7D210F872;
Wed, 10 Mar 2010 08:44:18 +0000 (UTC)
Received: from collab1.fedoraproject.org (localhost.localdomain [127.0.0.1])
by lists.fedoraproject.org (Postfix) with ESMTP id 13E7A32676D;
Wed, 10 Mar 2010 08:44:18 +0000 (UTC)
X-Original-To: 389-users@lists.fedoraproject.org
Delivered-To: 389-users@lists.fedoraproject.org
Received: from smtp-mm2.fedoraproject.org (smtp-mm2.fedoraproject.org
[66.35.62.164])
by lists.fedoraproject.org (Postfix) with ESMTP id 092AF32676C
for <389-users@lists.fedoraproject.org>;
Wed, 10 Mar 2010 08:44:16 +0000 (UTC)
Received: from aragon.dr15.cnrs.fr (aragon.dr15.cnrs.fr [147.210.72.197])
by smtp-mm2.fedoraproject.org (Postfix) with ESMTP id 94830E71C4
for <389-users@lists.fedoraproject.org>;
Wed, 10 Mar 2010 08:44:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by aragon.dr15.cnrs.fr (Postfix) with ESMTP id 51B1E1894DB
for <389-users@lists.fedoraproject.org>;
Wed, 10 Mar 2010 09:44:14 +0100 (CET)
X-Virus-Scanned: amavisd-new at dr15.cnrs.fr
Received: from aragon.dr15.cnrs.fr ([127.0.0.1])
by localhost (mail.dr15.cnrs.fr [127.0.0.1]) (amavisd-new, port 10024)
with LMTP id A1Lbc+ZoNE8I for <389-users@lists.fedoraproject.org>;
Wed, 10 Mar 2010 09:44:13 +0100 (CET)
Received: from [IPv6:2001:660:6101:21:21a:a0ff:febb:959c] (unknown
[IPv6:2001:660:6101:21:21a:a0ff:febb:959c])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "Jean-Noel Chardron", Issuer "CNRS-Standard" (verified OK))
by aragon.dr15.cnrs.fr (Postfix) with ESMTPS id 3E16C1894DA
for <389-users@lists.fedoraproject.org>;
Wed, 10 Mar 2010 09:44:13 +0100 (CET)
Message-ID: <4B975BDC.2030203@dr15.cnrs.fr>
Date: Wed, 10 Mar 2010 09:44:12 +0100
From: =?UTF-8?B?amVhbi1Ob8OrbCBDaGFyZHJvbg==?=
<Jean-Noel.Chardron@dr15.cnrs.fr>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: "General discussion list for the 389 Directory server project."
<389-users@lists.fedoraproject.org>
References: <df41a9e41003091251y14641e72g5bf9ef29fe26f6b8@mail .gmail.com> <20100309212735.GK4621@bakgwai.americas.hpqcorp.ne t> <df41a9e41003091338s16ce2ff8id50b3a88346fefa3@mail .gmail.com> <20100309215806.GM4621@bakgwai.americas.hpqcorp.ne t> <df41a9e41003091427i3fa58c3dnf964c5320fd4a8b4@mail .gmail.com>
<df41a9e41003091430t28c5d2c5n6bb5c8df85cd3768@mail .gmail.com>
In-Reply-To: <df41a9e41003091430t28c5d2c5n6bb5c8df85cd3768@mail .gmail.com>
Subject: Re: [389-users] NB: can't login/connect to FDS
X-BeenThere: 389-users@lists.fedoraproject.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "General discussion list for the 389 Directory server project."
<389-users@lists.fedoraproject.org>
List-Id: "General discussion list for the 389 Directory server project."
<389-users.lists.fedoraproject.org>
List-Unsubscribe: <https://admin.fedoraproject.org/mailman/listinfo/389-users>,
<mailto:389-users-request@lists.fedoraproject.org?subject=unsubscrib e>
List-Archive: <http://lists.fedoraproject.org/pipermail/389-users>
List-Post: <mailto:389-users@lists.fedoraproject.org>
List-Help: <mailto:389-users-request@lists.fedoraproject.org?subject=help>
List-Subscribe: <https://admin.fedoraproject.org/mailman/listinfo/389-users>,
<mailto:389-users-request@lists.fedoraproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: 389-users-bounces@lists.fedoraproject.org
Errors-To: 389-users-bounces@lists.fedoraproject.org

Brad Fuller wrote:
>
> Thanks for the reply. Yes. I checked the logs. (Mentioned in oreg msg)
> and there was no mention of the client.
>
> Afa sitting up he user - yes I set up a couple of users for posix access.
>
> I think my problem is more fundamental. Yes, I do have port 389 open
> on both machines.
>
> Any app that I can run on the client to see if it sees the ldap server?
>
In first you have to verify the setup of the server with tools like :
- ldapsearch of openldap that is locate in /usr/bin on fedora 11
- ldapsearch of mozilla that is locate in /usr/lib/mozldap/ldapsearch on
i686 or /usr/lib64/mozldap/ on x86_64 . you can install this with the
rpm mozldap-tools
take care that the arguments of these two commands are not equal.

once you have setup the server you can setup the client with authconfig
and test with getent
example : #getent passwd returns the list of your local user and the
list of your "ldap users" in the base.



> Brad Fuller
>
>> On Mar 9, 2010 1:58 PM, <patrick.morris@hp.com
>> <mailtoatrick.morris@hp.com>> wrote:
>>
>> Hi Brad! On Tue, 09 Mar 2010, Brad Fuller wrote: > Thanks for the
>> reply. See below On Tue, Mar 9, ...
>>
>> Authconfig also does stuff like configure PAM for you, etc, so you're
>> probably set there, but it's a bit more involved than just the canges
>> you mentioned.
>>
>> My guess now is that it's almost certainly expecting users to contain
>> the posixAccount object class, which you may or may not have set on
>> them currently. You mentioned that you were able to "create people,"
>> but didn't say how, so whether those were set up appropriately to work
>> as Unix logins is hard for me to say.
>>
>> As far as being able to tell if your client is hitting the server or
>> not, you should be able to look at the server's access logs.
>>
>> -- 389 users mailing list 389-users@lists.fedoraproject.org
>> <mailto:389-users@lists.fedoraproject.org>
>> https://admin.fedoraproject.org/mailman/...
>>
> ------------------------------------------------------------------------
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users


--
Jean-Noel Chardron



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

On 09/03/10 20:43, James Laska wrote:
> Some basics I'd propose as a starting point for defining acceptance
> criteria include:
>
> 1. repoclosure/conflicts - no package update can introduce broken
> deps or conflicts. I'd recommend we apply this to both
> 'updates-testing' and 'updates' (but that's detailed below)
> 2. Package sanity
> * No rpmlint failures

rpmlint, in common with many other "lint" tools, reports things that it
thinks *may* be errors that actually are intended. To regard "no rpmlint
failures" as a package sanity check is way over the top I think.

Comparing the rpmlint output for an updated package with the rpmlint
output for the currently in-repo package would be more useful as that
could identify any new issues, but there should still be a means to
override rpmlint if the maintainer can explain why it's not a problem.

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