Scott Schmit writes:
> On Tue, Aug 28, 2012 at 09:39:32AM +0200, Miloslav TrmaÄ wrote:
>> This optimizes the migration path at the cost of making the final
>> state ugly; I'm not sure that is a good bargain.
> Once F20 rolls out and F17 goes EOL, maintainers can simply
> s/systemd_post_enable/sy
On Tue, Aug 28, 2012 at 09:39:32AM +0200, Miloslav Trmač wrote:
> On Mon, Aug 27, 2012 at 11:04 AM, Paul Howarth wrote:
> > He's not ignoring it, he's saying that on F18+, the expansion of
> > %systemd_post_enable should be exactly the same as the expansion of
> > %systemd_post, i.e. not enabled by
On 28 August 2012 09:39, Miloslav Trmač wrote:
> After all, the F17 and F18 spec files will do _different_ things. I
> don't think it's unreasonable that the spec files themselves will be
> different - yes, that may be less convenient than having the same spec
> file for all branches, but allowi
On Mon, Aug 27, 2012 at 11:04 AM, Paul Howarth wrote:
> On Sun, 26 Aug 2012 14:11:39 -0400
> Tom Callaway wrote:
>> This is the problem: In F18+, systemd now uses a system-wide policy
>> (which can be overridden) to define what services are enabled, it is
>> no longer hardcoded into each package'
On 08/27/2012 05:04 AM, Paul Howarth wrote:
> He's not ignoring it, he's saying that on F18+, the expansion of
> %systemd_post_enable should be exactly the same as the expansion of
> %systemd_post, i.e. not enabled by default and honoring whatever
> presets are set for the spin.
Hmm, okay, this is
On Sun, 26 Aug 2012 14:11:39 -0400
Tom Callaway wrote:
> On 08/25/2012 09:16 PM, Kevin Kofler wrote:
> > 2. On UNRELEASED Fedora versions, i.e. Fedora 18 and higher, define
> > %systemd_post as currently done, and %systemd_post_enable to the
> > exact same thing.
>
> This is the problem: In F18
On 08/26/2012 11:41 PM, Tom Callaway wrote:
> On 08/25/2012 09:16 PM, Kevin Kofler wrote:
>> 2. On UNRELEASED Fedora versions, i.e. Fedora 18 and higher, define
>> %systemd_post as currently done, and %systemd_post_enable to the exact same
>> thing.
>
> This is the problem: In F18+, systemd now
On 08/25/2012 09:16 PM, Kevin Kofler wrote:
> 2. On UNRELEASED Fedora versions, i.e. Fedora 18 and higher, define
> %systemd_post as currently done, and %systemd_post_enable to the exact same
> thing.
This is the problem: In F18+, systemd now uses a system-wide policy
(which can be overridden) t
Tom Callaway wrote:
> On 08/25/2012 07:09 PM, Kevin Kofler wrote:
>> He's saying that %systemd_post and %systemd_post_enable should do the
>> exact SAME thing on F18, i.e. enable the service if and only if the
>> policy says it should be enabled, no matter what the package says. In
>> other words,
On 08/25/2012 07:09 PM, Kevin Kofler wrote:
> He's saying that %systemd_post and %systemd_post_enable should do the exact
> SAME thing on F18, i.e. enable the service if and only if the policy says it
> should be enabled, no matter what the package says. In other words, make the
> "_enable" suff
Tom Callaway wrote:
> Unfortunately, it isn't that easy. Please note that I had to redefine
> %systemd_post for F16 and F17 in order to simplify it to that. The
> %systemd_post_enable logic doesn't apply in F18+, because there is no
> longer any explicit enablement at the package level. The two are
On 08/23/2012 12:16 PM, Tom Lane wrote:
> Surely F18 could define %systemd_post_enable as a synonym for
> %systemd_post. The entire point of this thread is to make things
> simpler for packager maintainers, not load them down with cross-branch
> differences. (If I wanted to have a version-depende
Tom Callaway writes:
> 3) We'll adjust the guidelines like this:
> If your service is explicitly enabled by default in Fedora 16 or 17, and
> you wish to have a shared spec file, you will need to add a
> conditionalized call to the "%systemd_post_enable" macro, as follows:
> %post
> %if %{define
On 08/22/2012 06:22 PM, Lennart Poettering wrote:
> On Wed, 22.08.12 19:17, Tom Lane (t...@redhat.com) wrote:
>
>>
>> Lennart Poettering writes:
>>> On Wed, 22.08.12 09:25, Kevin Fenzi (ke...@scrye.com) wrote:
I'll add a me too here.
Any word on if the macros can/will be back-port
Scott Schmit writes:
> On Thu, Aug 23, 2012 at 01:22:27AM +0200, Lennart Poettering wrote:
>> On Wed, 22.08.12 19:17, Tom Lane (t...@redhat.com) wrote:
>>> What I would want to see in F16/F17 is macros that exactly duplicate the
>>> previously-standard snippets they are supposed to replace. Nobod
On Thu, Aug 23, 2012 at 01:22:27AM +0200, Lennart Poettering wrote:
> On Wed, 22.08.12 19:17, Tom Lane (t...@redhat.com) wrote:
> > Lennart Poettering writes:
> > > On Wed, 22.08.12 09:25, Kevin Fenzi (ke...@scrye.com) wrote:
> > >> I'll add a me too here.
> > >>
> > >> Any word on if the macros
On Wed, 22.08.12 19:17, Tom Lane (t...@redhat.com) wrote:
>
> Lennart Poettering writes:
> > On Wed, 22.08.12 09:25, Kevin Fenzi (ke...@scrye.com) wrote:
> >> I'll add a me too here.
> >>
> >> Any word on if the macros can/will be back-ported to f16/f17?
>
> > The preset logic is actually al
Lennart Poettering writes:
> On Wed, 22.08.12 09:25, Kevin Fenzi (ke...@scrye.com) wrote:
>> I'll add a me too here.
>>
>> Any word on if the macros can/will be back-ported to f16/f17?
> The preset logic is actually already available in F17, so we could
> theoretically backport that, but this
On Wed, 22.08.12 09:25, Kevin Fenzi (ke...@scrye.com) wrote:
> I'll add a me too here.
>
> Any word on if the macros can/will be back-ported to f16/f17?
>
> Has someone filed a RFE for Fedora systemd?
>
> Or would the systemd package maintainers chime in here?
The preset logic is actually a
I'll add a me too here.
Any word on if the macros can/will be back-ported to f16/f17?
Has someone filed a RFE for Fedora systemd?
Or would the systemd package maintainers chime in here?
kevin
signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
http
> "GH" == Garrett Holmstrom writes:
GH> I am pleased that I got a bug report and not an involuntary patch,
GH> as it gives me a chance to take care of special cases and schedule
GH> things appropriately.
I would much have preferred to receive an announcement about what should
be done, some d
On Tue, Aug 21, 2012 at 12:01 PM, Richard W.M. Jones wrote:
> On Tue, Aug 21, 2012 at 02:23:41PM -0400, Lukas Nykryn wrote:
>> Sorry for this mess. After a discussion, we have decided, that the
>> best way would be to create bugs for every packages and then helping
>> creating patches for specfile
On 08/21/2012 01:01 PM, Richard W.M. Jones wrote:
On Tue, Aug 21, 2012 at 02:23:41PM -0400, Lukas Nykryn wrote:
Sorry for this mess. After a discussion, we have decided, that the
best way would be to create bugs for every packages and then helping
creating patches for specfiles.
Just to be cle
On Tue, 21.08.12 13:24, Tom Lane (t...@redhat.com) wrote:
> Bruno Wolff III writes:
> > Tom Lane wrote:
> >> Bruno Wolff III writes:
> >>> Yeah, it gets old pretty quick when every time some packages get updated,
> >>> one needs to enable or disable them again.
>
> >> Huh? That doesn't happen
On Tue, Aug 21, 2012 at 13:24:53 -0400,
Tom Lane wrote:
which should not do anything on an update. It would auto-enable if
you were installing the package when it was previously not present,
but that isn't what you're describing. File a bug maybe?
I'll need to keep better track. There are
On Tue, Aug 21, 2012 at 02:23:41PM -0400, Lukas Nykryn wrote:
> Sorry for this mess. After a discussion, we have decided, that the
> best way would be to create bugs for every packages and then helping
> creating patches for specfiles.
Just to be clear, I had no problem at all with the bugs being
On 08/21/2012 05:24 PM, Tom Lane wrote:
which should not do anything on an update. It would auto-enable if
you were installing the package when it was previously not present,
but that isn't what you're describing. File a bug maybe?
regards, tom lane
It's a know ( and
- Original Message -
From: "Bill Nottingham"
To: "Development discussions related to Fedora"
Sent: Tuesday, August 21, 2012 5:59:29 PM
Subject: Re: Mass changes to packaging
Jason L Tibbitts III (ti...@math.uh.edu) said:
> >>>>> "RWMJ"
Bruno Wolff III writes:
> Tom Lane wrote:
>> Bruno Wolff III writes:
>>> Yeah, it gets old pretty quick when every time some packages get updated,
>>> one needs to enable or disable them again.
>> Huh? That doesn't happen given the current (F16/F17) scriptlets AFAICS.
>> They don't touch the s
On 08/21/2012 05:08 PM, Lennart Poettering wrote:
On Tue, 21.08.12 16:52, "Jóhann B. Guðmundsson" (johan...@gmail.com) wrote:
>On 08/21/2012 02:52 PM, Richard W.M. Jones wrote:
> >However, the person who is sending these bugs reports is
> >(a) in a much better position to change the packages b
On Tue, 21.08.12 16:52, "Jóhann B. Guðmundsson" (johan...@gmail.com) wrote:
> On 08/21/2012 02:52 PM, Richard W.M. Jones wrote:
> >However, the person who is sending these bugs reports is
> >(a) in a much better position to change the packages because they
> >understand the problem and the solutio
On 08/21/2012 02:52 PM, Richard W.M. Jones wrote:
However, the person who is sending these bugs reports is
(a) in a much better position to change the packages because they
understand the problem and the solution, and (b) ought to take on this
work because that's part of whatever feature/cleanup/
Le 21/08/2012 17:04, Tom Lane a écrit :
> I'd like to see these macros back-ported into F17 and F16 RPM to remove
> this objection. If that doesn't happen, I'm going to resist using them
> in my spec files until they are in all active Fedora branches.
+1
Remi.
--
devel mailing list
devel@list
On Tue, Aug 21, 2012 at 12:25:32 -0400,
Tom Lane wrote:
Bruno Wolff III writes:
On Tue, Aug 21, 2012 at 11:59:29 -0400,
Bill Nottingham wrote:
Presets are a valuable new feature for both distribution constructors
and administrators - rather than having a single hardcoded policy *in
the
Bruno Wolff III writes:
> On Tue, Aug 21, 2012 at 11:59:29 -0400,
>Bill Nottingham wrote:
>> Presets are a valuable new feature for both distribution constructors
>> and administrators - rather than having a single hardcoded policy *in
>> the packages* about what starts and doesn't start (and
On Tue, Aug 21, 2012 at 11:59:29 -0400,
Bill Nottingham wrote:
Presets are a valuable new feature for both distribution constructors
and administrators - rather than having a single hardcoded policy *in
the packages* about what starts and doesn't start (and requires rebuilding
to fix), preset
On 08/21/2012 10:04 AM, Tom Lane wrote:
> "Richard W.M. Jones" writes:
>> I just received about a dozen bugs like this:
>> On Tue, Aug 21, 2012 at 02:16:42PM +, bugzi...@redhat.com wrote:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=850364
>> [...]
>>> Summary: Introduce new systemd-rpm mac
Jason L Tibbitts III (ti...@math.uh.edu) said:
> > "RWMJ" == Richard W M Jones writes:
>
> RWMJ> I just received about a dozen bugs like this:
>
> Yep, someone has taken it upon themselves to mass-file a bunch of
> unnecessary tickets.
>
> When FPC makes guidelines changes, they aren't gen
On 08/21/2012 05:04 PM, Tom Lane wrote:
"
I'd like to see these macros back-ported into F17 and F16 RPM to remove
this objection. If that doesn't happen, I'm going to resist using them
in my spec files until they are in all active Fedora branches.
regards, tom lane
+1
"Richard W.M. Jones" writes:
> I just received about a dozen bugs like this:
> On Tue, Aug 21, 2012 at 02:16:42PM +, bugzi...@redhat.com wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=850364
> [...]
>> Summary: Introduce new systemd-rpm macros in watchdog spec file
> [...]
Yeah, I got
> "RWMJ" == Richard W M Jones writes:
RWMJ> I just received about a dozen bugs like this:
Yep, someone has taken it upon themselves to mass-file a bunch of
unnecessary tickets.
When FPC makes guidelines changes, they aren't generally accompanied by
some mandate that existing packages be cha
I just received about a dozen bugs like this:
On Tue, Aug 21, 2012 at 02:16:42PM +, bugzi...@redhat.com wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=850364
[...]
>Summary: Introduce new systemd-rpm macros in watchdog spec file
[...]
> Fedora 18 changes the way how to work w
42 matches
Mail list logo
