On Mon, May 07, 2012 at 02:33:54PM +0100, Adam D. Barratt wrote:
> fwiw, there's just (as in within the past couple of hours) been a change
> committed upstream which defaults accept_8bitmime to true.
Good news.
As mentioned on bug #445013:
-snip-
> accept_8bitmime = true
> I would actually rec
On Tue, 8 May 2012, Gergely Nagy wrote:
but sometimes it is necessary to do unusual things in init scripts to
properly intregrate a service into the system. How to deal with that?
Write shell wrappers that are executed from systemd?
If absolutely neccessary, that is an option. So is fixing the
(Please try to respect M-F-T, and not Cc: me. If I want a CC, I'll set
M-F-T appropriately, thanks)
Stefan Fritsch writes:
> On Tue, 8 May 2012, Gergely Nagy wrote:
>>> but sometimes it is necessary to do unusual things in init scripts to
>>> properly intregrate a service into the system. How to
On 05/03/2012 07:23 PM, Stefano Zacchiroli wrote:
> I agree that's a problem too and I share your feeling that it has been
> particularly bad in recent discussions like the init system ones.
To keep on the topic of the init systems, we had Patrick Lauer,
a Gentoo developer who I believe knows quite
On Wed, 2012-05-09 at 16:58 +0800, Thomas Goirand wrote:
> On 05/03/2012 07:23 PM, Stefano Zacchiroli wrote:
> > I agree that's a problem too and I share your feeling that it has been
> > particularly bad in recent discussions like the init system ones.
> To keep on the topic of the init systems, w
Thomas Goirand writes:
> But that's not the problem. The issue is that there's no
> outcome, and that it's demotivating. If I read others that
> what we want to work on isn't a good idea, I will simply
> not work on that, and external contributors will run away.
I agree with this. The init syste
On Wed, May 09, 2012 at 04:58:53PM +0800, Thomas Goirand wrote:
> We should have had some enthusiastic replies and constructive
> comments on how we could make this happen, how we could improve
> OpenRC to fit our needs. Instead, I have read posts criticizing
> without knowing. If I was Patrick, I'
Jakub Wilk, 2012-05-07 14:24+0200:
> How does it know whether to indent a line by one space[1] or two
> spaces[2]?
Is that such a big deal? Licenses are written to be understandable even
if their layout is changed, are they not?
--
,--.
: /` ) Tanguy Ortolo
| `-'Debian Developer
\_
Russ, I flagged your message as one to respond to, but not to debate any
particular point you raise, but rather to thank you for raising it at all,
despite it being potentially controversial. I'd also like to thank you for
tirelessly participating on the list, especially in recent times: I find yo
On May 09, Arto Jantunen wrote:
> In addition to that it would be nice if everyone could agree to not work
> against a certain init implementation (for example by refusing to
> include the startup file for that init when someone else has written one
> and submited it as a wishlist bug).
I definit
On May 08, Gergely Nagy wrote:
> > but sometimes it is necessary to do unusual things in init scripts to
> > properly intregrate a service into the system. How to deal with that?
> > Write shell wrappers that are executed from systemd?
> If absolutely neccessary, that is an option. So is fixing
On Wed, May 09, 2012 at 10:39:38AM +0200, Gergely Nagy wrote:
> > And the integrator/packager may not want to learn all the funny
> > languages that daemons can be written in (ocaml, haskell, java, ruby,
> > ...). Besides, init scripts are conf files on Debian for good reasons.
> So are unit files
On Wed, May 09, 2012 at 12:29:21PM +0300, Arto Jantunen wrote:
> Thomas Goirand writes:
>
> > But that's not the problem. The issue is that there's no
> > outcome, and that it's demotivating. If I read others that
> > what we want to work on isn't a good idea, I will simply
> > not work on that,
Philipp Kern writes:
> On Wed, May 09, 2012 at 10:39:38AM +0200, Gergely Nagy wrote:
>> > And the integrator/packager may not want to learn all the funny
>> > languages that daemons can be written in (ocaml, haskell, java, ruby,
>> > ...). Besides, init scripts are conf files on Debian for good r
]] Philipp Kern
> You will not, however, get a conffile update prompt when the system
> file changes (e.g. to update your own local copy to incorporate the
> fix).
This is something I'm pondering if we should handle in either a systemd
trigger or a tool that packages shipping systemd files can c
On 05/09/12 21:37, Tollef Fog Heen wrote:
> ]] Philipp Kern
>
>> You will not, however, get a conffile update prompt when the system
>> file changes (e.g. to update your own local copy to incorporate the
>> fix).
> This is something I'm pondering if we should handle in either a systemd
> trigger o
Hi,
On Wed, May 9, 2012 at 10:57 AM, Patrick Lauer wrote:
> On 05/09/12 21:37, Tollef Fog Heen wrote:
>> ]] Philipp Kern
>>
>>> You will not, however, get a conffile update prompt when the system
>>> file changes (e.g. to update your own local copy to incorporate the
>>> fix).
>> This is somethin
Tollef Fog Heen writes:
> ]] Philipp Kern
>
>> You will not, however, get a conffile update prompt when the system
>> file changes (e.g. to update your own local copy to incorporate the
>> fix).
>
> This is something I'm pondering if we should handle in either a systemd
> trigger or a tool that
On 05/09/12 21:58, Fernando Lemos wrote:
> Hi,
>
> On Wed, May 9, 2012 at 10:57 AM, Patrick Lauer wrote:
>> On 05/09/12 21:37, Tollef Fog Heen wrote:
>>> ]] Philipp Kern
>>>
You will not, however, get a conffile update prompt when the system
file changes (e.g. to update your own local co
On 2012-05-09 14:01 +0200, Gergely Nagy wrote:
> Philipp Kern writes:
>
>> On Wed, May 09, 2012 at 10:39:38AM +0200, Gergely Nagy wrote:
>>> > And the integrator/packager may not want to learn all the funny
>>> > languages that daemons can be written in (ocaml, haskell, java, ruby,
>>> > ...). Be
On Wed, May 09, 2012 at 03:37:50PM +0200, Tollef Fog Heen wrote:
> ]] Philipp Kern
>
> > You will not, however, get a conffile update prompt when the system
> > file changes (e.g. to update your own local copy to incorporate the
> > fix).
>
> This is something I'm pondering if we should handle i
Sven Joachim writes:
> On 2012-05-09 14:01 +0200, Gergely Nagy wrote:
>
>> Philipp Kern writes:
>>
>>> On Wed, May 09, 2012 at 10:39:38AM +0200, Gergely Nagy wrote:
> And the integrator/packager may not want to learn all the funny
> languages that daemons can be written in (ocaml, hask
Tollef Fog Heen wrote:
> ]] Philipp Kern
>
> > You will not, however, get a conffile update prompt when the system
> > file changes (e.g. to update your own local copy to incorporate the
> > fix).
>
> This is something I'm pondering if we should handle in either a systemd
> trigger or a tool tha
On Wed, 2012-05-09 at 21:57 +0800, Patrick Lauer wrote:
> Why this arbitrary limit to only one application?
>
> http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&chap=4
>
> Something along those lines makes life a lot easier and avoids these
> schizophrenic hacks around package man
Roger Leigh wrote:
> Can't we just do things the Debian way, and just provide them directly
> as conffiles in /etc? It's nice that systemd provides its mechanism
> to symlink/include the units provided elsewhere, but is this either
> necessary or desirable on a Debian system?
Not having the files
On May 09, Tollef Fog Heen wrote:
> This is something I'm pondering if we should handle in either a systemd
> trigger or a tool that packages shipping systemd files can call to tell
> the user about any changes. (Basically a wrapper around ucf, probably.)
The more I think about it, the more I su
Uoti Urpala writes:
> Roger Leigh wrote:
>> Can't we just do things the Debian way, and just provide them directly
>> as conffiles in /etc? It's nice that systemd provides its mechanism
>> to symlink/include the units provided elsewhere, but is this either
>> necessary or desirable on a Debian s
Marco d'Itri wrote:
> On May 09, Tollef Fog Heen wrote:
> > This is something I'm pondering if we should handle in either a systemd
> > trigger or a tool that packages shipping systemd files can call to tell
> > the user about any changes. (Basically a wrapper around ucf, probably.)
>
> The more
Gergely Nagy wrote:
> Uoti Urpala writes:
> > Not having the files in /etc by default does have technical advantages.
> > It's easier to see what is local non-default configuration. Original
> > default file is always available in a known location (and very easy to
> > revert to, temporarily for t
Josh Triplett wrote:
>Marco d'Itri wrote:
>> On May 09, Tollef Fog Heen wrote:
>> > This is something I'm pondering if we should handle in either a systemd
>> > trigger or a tool that packages shipping systemd files can call to tell
>> > the user about any changes. (Basically a wrapper around ucf
]] Arto Jantunen
> I think the only technical decision that needs to be made at this point
> is removing the Essential mark from sysvinit. The consensus for that
> should be somewhat more reachable, even if the technical implementation
> may have some open questions.
I don't think anybody is opp
Steve McIntyre wrote:
> Josh Triplett wrote:
> >Marco d'Itri wrote:
> >> The more I think about it, the more I suspect that the correct solution
> >> would be to just symlink /lib/udev/rules.d/ to /etc/udev/rules.d/ and so
> >> on.
> >
> >Please don't. As a user, I find it highly preferable for
Uoti Urpala writes:
> Gergely Nagy wrote:
>> Uoti Urpala writes:
>> > Not having the files in /etc by default does have technical advantages.
>> > It's easier to see what is local non-default configuration. Original
>> > default file is always available in a known location (and very easy to
>> >
Uoti Urpala wrote:
>
>Who's the one choosing his preferred configuration format based on the
>limitations of his preferred packaging system here? Hint: it's not Red
>Hat.
*yawn*
When you've got something constructive to add to Debian development,
let us know. Until that point, please go away and
Steve McIntyre writes:
> Uoti Urpala wrote:
>>
>>Who's the one choosing his preferred configuration format based on the
>>limitations of his preferred packaging system here? Hint: it's not Red
>>Hat.
>
> *yawn*
>
> When you've got something constructive to add to Debian development,
> let us know
Hi,
On Wed, May 9, 2012 at 7:11 PM, Steve McIntyre wrote:
> Uoti Urpala wrote:
>>
>>Who's the one choosing his preferred configuration format based on the
>>limitations of his preferred packaging system here? Hint: it's not Red
>>Hat.
>
> *yawn*
>
> When you've got something constructive to add t
Steve McIntyre wrote:
> Uoti Urpala wrote:
> >Who's the one choosing his preferred configuration format based on the
> >limitations of his preferred packaging system here? Hint: it's not Red
> >Hat.
>
> *yawn*
>
> When you've got something constructive to add to Debian development,
> let us know.
Hello,
The upstream author for one of my packages changed the major version
of the shared library (only used by the package) from 5 to 5000.
I am trying to understand his response as to why. Should I be changing
the library name from libdar64-5 to libdar64-5000? Or does this change
reflect some s
Package: wnpp
Owner: tak...@debian.org
Severity: wishlist
* Package name: python-cssselect
Version : 0.6.1
Upstream Author : Ian Bicking
* URL or Web page : http://pypi.python.org/pypi/cssselect
* License : BSD3
Description : cssselect parses CSS3 Selectors and transl
reassign 672104 wnpp
retitle 672104 ITP: pv-grub-menu.lst
Dear all,
Some systems booted by PV-Grub need a menu.lst file like the one created by
grub1, but without GRUB itself on the MBR. Such systems include computer cloud
systems like Amazon's Elastic Computer Cloud. Some methods to create suc
40 matches
Mail list logo
