On Mon, 25.06.12 15:40, Tom Lane (t...@redhat.com) wrote:
> (1) systemd is not able to distinguish a crash that should be restarted
> from, say, failure due to misconfiguration in /etc/my.cnf. (It's not
> clear whether restart settings other than "always" would help here,
> but in general it seem
On Mon, 25.06.12 15:27, Daniel P. Berrange (berra...@redhat.com) wrote:
> With OpenStack there are quite a large number of daemons per host, each
> of which has their own .service unit file.
>
> openstack-glance-api.service
> openstack-glance-registry.service
> openstack-keystone.service
>
On 06/26/2012 03:56 AM, Chris Adams wrote:
> Once upon a time, Matthew Garrett said:
>> On Mon, Jun 25, 2012 at 08:47:16PM -0500, Chris Adams wrote:
>>> Trying to do this in profile scripts assumes that you only run local
>>> terminals that come from Fedora and that have been tested. For example,
Once upon a time, Pádraig Brady said:
> The main caveat with per terminal settings is that
> it might be desired to provide config options per terminal.
> Though I suppose users can always override TERM in their
> startup files in the unlikely case they need to change
> back to 'xterm' for example
2012/6/26 Chris Adams :
> The newer terminal
> programs have configuration menus for various things; do any of them set
> it there? If they don't, I would think it would be relatively easy to
> add (and hopefully upstreams would accept such patches).
Tried with XFCE's "Terminal", which has a $TER
Hi,
Starting from the version 0.4 pylibacl Python extension changed its
license from GPLv2+ to LGPLv2+. As the new license is less restrictive I
don't see any negative implications.
Regards
Marcin
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinf
On 06/26/2012 02:37 PM, Thomas Moschny wrote:
> 2012/6/26 Chris Adams :
>> The newer terminal
>> programs have configuration menus for various things; do any of them set
>> it there? If they don't, I would think it would be relatively easy to
>> add (and hopefully upstreams would accept such patch
On 06/26/2012 08:50 AM, Chris Adams wrote:
Once upon a time, Pádraig Brady said:
The main caveat with per terminal settings is that
it might be desired to provide config options per terminal.
Though I suppose users can always override TERM in their
startup files in the unlikely case they need t
On 06/26/2012 06:54 AM, Pádraig Brady wrote:
.
The main caveat with per terminal settings is that
it might be desired to provide config options per terminal.
Though I suppose users can always override TERM in their
startup files in the unlikely case they need to change
back to 'xterm' for exampl
On Tue, Jun 26, 2012 at 10:20:56AM -0400, John Ellson wrote:
> On 06/26/2012 06:54 AM, Pádraig Brady wrote:
> >.
> >
> >The main caveat with per terminal settings is that
> >it might be desired to provide config options per terminal.
> >Though I suppose users can always override TERM in their
> >st
This is a report of the weekly KDE-SIG-Meeting with a summary of the
topics that were discussed. If you want to add a comment please reply
to this email or add it to the related meeting page.
= Weekly KDE Summary =
Week: 26/2012
Time: 2012-06-26 15:00 UTC
Meeting page: https://fedoraproject.or
On Tue, 2012-06-26 at 10:20 -0400, John Ellson wrote:
> On 06/26/2012 06:54 AM, Pádraig Brady wrote:
> > The main caveat with per terminal settings is that
> > it might be desired to provide config options per terminal.
> > Though I suppose users can always override TERM in their
> > startup files
On Tue, Jun 26, 2012 at 3:24 AM, Matthew Garrett wrote:
> We discussed this in fesco today and had a couple of concerns.
Another one is that connecting to systems that don't support xterm-256
is not quite easy. In particular, there appears to be no way to
configure ~/.ssh/config so that "ssh old
Miloslav Trmač wrote:
> Another one is that connecting to systems that don't support xterm-256
> is not quite easy. In particular, there appears to be no way to
> configure ~/.ssh/config so that "ssh oldhost" (and "ssh oldhost
> arbitrarycommand") transparently changes the TERM value - one would
>
Once upon a time, Miloslav Trmač said:
> Another one is that connecting to systems that don't support xterm-256
> is not quite easy. In particular, there appears to be no way to
> configure ~/.ssh/config so that "ssh oldhost" (and "ssh oldhost
> arbitrarycommand") transparently changes the TERM v
On Sat, Jun 23, 2012 at 01:15:14AM +0200, Kevin Kofler wrote:
> Michael Cronenworth wrote:
>
> > Kevin Kofler wrote:
> >> How would you suggest we implement this? rm -rf the stuff in %post?
> >> (Yuck!!!) As I understand it, the symbols will be bloating the main
> >> packages and not be in subpack
I would like to upgrade Apache Traffic Server (ATS) from v3.0.x to new
stable branch v3.2.x. The 3.2 branch has lots of improvements for IPv6
and SSL that are important to me, and also fixes a crash I've been
hitting in v3.0. But, unfortunately there are a couple of incompatible
config file changes
On 06/26/2012 02:50 PM, Toshio Kuratomi wrote:
A pie in the sky option might be to have minidebuginfo/debuginfo reside
in the same package as the binaries it belongs to but in separate files
which are marked in the rpm filelist. Then rpm could have a --nodebuginfo
similar to how it has --nodoc
THE PROBLEM
We have assorted init scripts that have historically defined custom actions.
Given that this is an unbounded set, it is impossible to handle them
natively in systemd. However, they're usually part of administrators muscle
memory.
Better late than never (and thanks to Michal Schmidt),
Toshio Kuratomi wrote:
> A pie in the sky option might be to have minidebuginfo/debuginfo reside
> in the same package as the binaries it belongs to but in separate files
> which are marked in the rpm filelist. Then rpm could have a --nodebuginfo
> similar to how it has --nodoc now. Not sure if t
On Tue, Jun 26, 2012 at 16:11:19 -0400,
Bill Nottingham wrote:
Questions? Comments?
Thanks!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, Jun 25, 2012 at 8:01 PM, Miloslav Trmač wrote:
> (prepared manually, MeetBot-generated version to hopefully follow later)
http://meetbot.fedoraproject.org/fedora-meeting/2012-06-25/fesco.2012-06-25-17.00.html
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.
On Tue, Jun 26, 2012 at 04:11:19PM -0400, Bill Nottingham wrote:
> BEST PRACTICES
>
> 1) A legacy action of this sort should print to stderr the preferred way to
> accomplish the task, if one is supported.
>
> 2) Don't package a legacy action for new scripts or actions that were not
> supported
On Tue, Jun 26, 2012 at 10:45 PM, Till Maas wrote:
>> 2) Don't package a legacy action for new scripts or actions that were not
>> supported by the prior init script; this is intended for compatibility with
>> existing scripts and/or administrator brains.
>
> It would be nice to have a good plan a
On 06/26/2012 07:35 PM, Chris Adams wrote:
> Once upon a time, Miloslav Trmač said:
>> Another one is that connecting to systems that don't support xterm-256
>> is not quite easy. In particular, there appears to be no way to
>> configure ~/.ssh/config so that "ssh oldhost" (and "ssh oldhost
>> ar
On 06/26/2012 08:11 PM, Bill Nottingham wrote:
Questions? Comments?
You do realize what you have effectively just done by this dont you?
JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Bill Nottingham writes:
> Better late than never (and thanks to Michal Schmidt), I've added support to
> /sbin/service for running legacy actions if specified.
I'm confused. Only 2 months ago I was told that this was firmly
against policy and I should get rid of code that assumed it worked
(whic
On 06/26/2012 08:49 PM, Miloslav Trmač wrote:
The preferred new way is that upstream implements the action in a way
that is same across all distributions. Which, in some sense, does not
answer your question.
First and foremost how big of a problem do you guys believe this?
Secondly cant we ad
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= writes:
> On 06/26/2012 08:49 PM, Miloslav TrmaÄ wrote:
>> The preferred new way is that upstream implements the action in a way
>> that is same across all distributions. Which, in some sense, does not
>> answer your question.
> First and foremos
Once upon a time, Pádraig Brady said:
> The usual way to set/adjust TERM appropriate for the remote system
> is just to use the startup files there. This is what I add to ~/.profile
> on a solaris system for example:
Well, that works when the other end is a system that has a shell and
runs login
On Tue, Jun 26, 2012 at 11:48 PM, "Jóhann B. Guðmundsson"
wrote:
> On 06/26/2012 08:49 PM, Miloslav Trmač wrote:
>>
>> The preferred new way is that upstream implements the action in a way
>> that is same across all distributions. Which, in some sense, does not
>> answer your question.
>
>
> Firs
On Wed, Jun 27, 2012 at 12:04 AM, Tom Lane wrote:
> The idea seems to be that you'd only implement actions that exist
> in non-systemd initscripts. As long as people adhere to that,
> I don't see that we need controls or per-package permissions. And
> I don't really see why people wouldn't.
Wel
> "TL" == Tom Lane writes:
TL> Did that packaging guideline get reverted already?
No, it didn't, but of course you know the packaging committee cannot
prevent an upstream from implementing whatever functionality they like.
We can of course revisit the prohibition if someone cares to file a
t
On Tue, Jun 26, 2012 at 05:50:57PM -0400, Tom Lane wrote:
> Bill Nottingham writes:
> > Better late than never (and thanks to Michal Schmidt), I've added support to
> > /sbin/service for running legacy actions if specified.
>
> I'm confused. Only 2 months ago I was told that this was firmly
> ag
On 06/26/2012 10:12 PM, Miloslav Trmač wrote:
What is "this"?
Sorry meant to say "this is"
There are maybe a handful of services that need this hence the
precaution clause so packagers/maintainers simply don't choose to do
exactly what Bill was referring to in "3)"
Breaking "service foo
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= writes:
> On 06/26/2012 10:12 PM, Miloslav TrmaÄ wrote:
>> Breaking "service foo action" reason was just an unnecessary
>> regression that shouldn't have happened in the first place.
> Agreed and honestly this sudden turnaround now smells a bit li
On 06/26/2012 11:54 PM, Tom Lane wrote:
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= writes:
On 06/26/2012 10:12 PM, Miloslav Trma� wrote:
Breaking "service foo action" reason was just an unnecessary
regression that shouldn't have happened in the first place.
Agreed and honestly this sud
On 06/26/2012 06:54 PM, Tom Lane wrote:
I beg to differ. If Bill doesn't get his wrist slapped by FPC, I'll
be implementing this for postgresql tomorrow, because I'm tired of
hearing complaints about it.
I must be the only one that prefers your separate postgresql-setup
script over the call t
On Tue, 2012-06-26 at 21:51 -0500, Michael Cronenworth wrote:
> On 06/26/2012 06:54 PM, Tom Lane wrote:
> > I beg to differ. If Bill doesn't get his wrist slapped by FPC, I'll
> > be implementing this for postgresql tomorrow, because I'm tired of
> > hearing complaints about it.
>
> I must be the
Michael Cronenworth writes:
> On 06/26/2012 06:54 PM, Tom Lane wrote:
>> I beg to differ. If Bill doesn't get his wrist slapped by FPC, I'll
>> be implementing this for postgresql tomorrow, because I'm tired of
>> hearing complaints about it.
> I must be the only one that prefers your separate p
Mathieu Bridon writes:
> Especially since it handles multiple postgresql instances with an
> optional parameter.
> Tom, can you try to make sure the script
> in /usr/libexec/initscripts/legacy-actions allows the same?
Unless Bill hacked /sbin/service to pass additional parameters through
to the
On Tue, 2012-06-26 at 21:48 +, "Jóhann B. Guðmundsson" wrote:
> On 06/26/2012 08:49 PM, Miloslav Trmač wrote:
> > The preferred new way is that upstream implements the action in a way
> > that is same across all distributions. Which, in some sense, does not
> > answer your question.
>
> Firs
42 matches
Mail list logo
