Package: upstart
Severity: wishlist
Version: 0.6.3
Tags: patch
On Sat, Sep 05 2009, Manoj Srivastava wrote:
> One of the features missing in upstart that is present in
> sysvinit is that the latter loads SELinux security policy early in the
> boot sequence, and the former does not (plea
On Sun, Sep 06, 2009 at 04:43:57AM +0200, Marco d'Itri wrote:
> Great news. I really look forward to converting my init scripts to
> native upstart jobs, but I believe that some clarifications are needed
> about the long-term impact of switching to upstart.
> Can you clarify what normal packages w
Am Samstag 05 September 2009 schrieb Klaus Ethgen:
> Am Sa den 5. Sep 2009 um 20:18 schrieb Hans-J. Ullrich:
> > APT::Cache-Limit "1";
>
> Doesn't help as the limit is hard coded in apt. Just look at the source.
> The problem was fixed in versions after stable.
>
> Regards
>Klaus
A
Hi
Is there an statement in Debian Policy that explicitly requires higher
version of a shared library package to be backwards-binary-compatible with
previous versions of the same package?
I mean, is a situation when after library package upgrade local binaries
stops working because of missing
On Sep 06, Steve Langasek wrote:
> > When should maintainers start adding upstart jobs to their packages?
> Not before the upstart compat package that provides upstart-job for
> sysvinit-based systems is available.
Is this relevant for Linux-specific packages as well? I.e., do we want
to continue
Am Samstag 05 September 2009 23:29:39 schrieb Steve Langasek:
> The rationale for this /using glib/ is that devicekit-disks is not an
> integral part of udev, it's an add-on component that will be installed only
> on desktop systems. So the size impact to /lib for servers for this
> component woul
Nikita V. Youshchenko wrote:
> Hi
>
> Is there an statement in Debian Policy that explicitly requires higher
> version of a shared library package to be backwards-binary-compatible with
> previous versions of the same package?
>
> I mean, is a situation when after library package upgrade local
> Nikita V. Youshchenko wrote:
> > Hi
> >
> > Is there an statement in Debian Policy that explicitly requires higher
> > version of a shared library package to be backwards-binary-compatible
> > with previous versions of the same package?
> >
> > I mean, is a situation when after library package up
On Sun, Sep 6, 2009 at 12:50:59 +0200, Emilio Pozuelo Monfort wrote:
> Nikita V. Youshchenko wrote:
> > Hi
> >
> > Is there an statement in Debian Policy that explicitly requires higher
> > version of a shared library package to be backwards-binary-compatible with
> > previous versions of the
On Sun, Sep 06, 2009 at 02:58:02PM +0400, Nikita V. Youshchenko wrote:
> > Nikita V. Youshchenko wrote:
> > > Hi
> > >
> > > Is there an statement in Debian Policy that explicitly requires higher
> > > version of a shared library package to be backwards-binary-compatible
> > > with previous version
On Sep 06, Hendrik Sattler wrote:
> And what about embedded systems? They start to use those libraries for even
> the simplest utilities that are also usuable on very small systems. And
> that's
No, "they" do not.
--
ciao,
Marco
signature.asc
Description: Digital signature
> On Sun, Sep 6, 2009 at 12:50:59 +0200, Emilio Pozuelo Monfort wrote:
> > Nikita V. Youshchenko wrote:
> > > Hi
> > >
> > > Is there an statement in Debian Policy that explicitly requires
> > > higher version of a shared library package to be
> > > backwards-binary-compatible with previous versio
Hendrik Sattler wrote:
>> (I'll do you one better, though -- system-config-printer upstream wants to
>> install /lib/udev/udev-configure-printer, which pulls in the entire libcups
>> stack. Sigh...)
>
> *sigh* I agree. Has the world gone mad?
The desktop world, yes.
JB.
--
Julien BLACHE - D
On Sun, Sep 6, 2009 at 15:14:21 +0400, Nikita V. Youshchenko wrote:
> As of today, debian does not contain this bug, because ffmpeg with this
> brakage happened not to be uploaded yet to debian. However, once it is,
> the bug will be in debian, and will have to be handled somehow.
>
So when th
* Julien Cristau:
>> Yes, it's an RC bug. If you break the API and/or ABI, you need to change the
>> package name and the SONAME.
>>
> AFAIK the rule is "if you break ABI, you MUST change the package name and
> SHOULD change the SONAME".
It's still possible to work around that by not providing a
On Sun, Sep 06, 2009 at 12:04:33PM +0200, Marco d'Itri wrote:
> On Sep 06, Steve Langasek wrote:
>
> > > When should maintainers start adding upstart jobs to their packages?
> > Not before the upstart compat package that provides upstart-job for
> > sysvinit-based systems is available.
> Is this
On Sun, Sep 06, 2009 at 01:45:35AM -0500, Manoj Srivastava wrote:
> Package: upstart
> Severity: wishlist
> Version: 0.6.3
> Tags: patch
>
> On Sat, Sep 05 2009, Manoj Srivastava wrote:
>
> diff --git upstart-0.6.3.orig/debian/changelog upstart-0.6.3/debian/changelog
> index be2b21f..afaf59a 1006
On Sun, 2009-09-06 at 05:01 +0200, Marco d'Itri wrote:
> On Sep 06, Steve Langasek wrote:
> > It's normal that in the process of drafting a standard, people will take
> > into account the prevailing real-world practices, to ensure that the
> > standard will be useful. Once something *is a standa
On Sun, Sep 06, 2009 at 12:04:33PM +0200, Marco d'Itri wrote:
> On Sep 06, Steve Langasek wrote:
> > > When should maintainers start adding upstart jobs to their packages?
> > Not before the upstart compat package that provides upstart-job for
> > sysvinit-based systems is available.
> Is this re
On Sun, Sep 06, 2009 at 06:40:44PM +0200, Pierre Habouzit wrote:
> On Sun, Sep 06, 2009 at 12:04:33PM +0200, Marco d'Itri wrote:
> > On Sep 06, Steve Langasek wrote:
> > > > When should maintainers start adding upstart jobs to their packages?
> > > Not before the upstart compat package that provi
On Sun, Sep 06, 2009 at 03:45:38PM +, Florian Weimer wrote:
> * Julien Cristau:
> >> Yes, it's an RC bug. If you break the API and/or ABI, you need to change
> >> the
> >> package name and the SONAME.
> > AFAIK the rule is "if you break ABI, you MUST change the package name and
> > SHOULD ch
"Nikita V. Youshchenko" writes:
> This does not help in a corner case.
> Issue I am looking at is:
> - a library used to export a symbol, it was visible in objdump -T output,
> - at some point, upstream decides that this symbol should be removed,
> claiming that "it was not ever included in any
On Sun, Sep 06, 2009 at 10:52:22AM -0700, Steve Langasek wrote:
> On Sun, Sep 06, 2009 at 06:40:44PM +0200, Pierre Habouzit wrote:
> > On Sun, Sep 06, 2009 at 12:04:33PM +0200, Marco d'Itri wrote:
> > > On Sep 06, Steve Langasek wrote:
>
> > > > > When should maintainers start adding upstart jobs
On Sun, Sep 06, 2009 at 11:26:20AM -0700, Russ Allbery wrote:
> "Nikita V. Youshchenko" writes:
> > This does not help in a corner case.
> > Issue I am looking at is:
> > - a library used to export a symbol, it was visible in objdump -T output,
> > - at some point, upstream decides that this sym
Package: wnpp
Severity: wishlist
Owner: Piotr Lewandowski
* Package name: fbcat
Version : 0.2
Upstream Author : Jakub Wilk, Piotr Lewandowski
* URL : http://fbcat.googlecode.com/
* License : GPLv2
Programming Lang: C
Description : framebuffer grabber
Hi,
as I was unsuccessful in finding similiar cases on the mailing lists I would
like some input on the handling of corner-case in packaging.
The package is fso-usaged from the freesmartphone.org software-stack and not
yet in debian.
Compilation results in a binary fsousaged, a shared library
On Sep 04, Serafeim Zanikolas wrote:
> As the new vict^Wmaintainer of update-inetd, I'd appreciate a review of the
> proposal below to migrate it to dpkg triggers [0]
Maybe you could have discussed it with the former maintainer, so I could
have explained why I never implemented the changes you ar
On Fri, 04 Sep 2009, Marco d'Itri wrote:
> On Sep 04, Ron Johnson wrote:
> > Whatever the cause, it breaks the FHS.
> Since it keeps being repeated, it is time to destroy this argument.
> FHS documents what distributions want to do: of the other relevant
> distributions, representatives from Red H
On Sun, Sep 06 2009, Pierre Habouzit wrote:
> Isn't it a dupli of #543420
True, I should have checked.
> where the maintainer claims upstream doesn't want such a patch ?
Right. I did not copy the upstream. I also think that we have
invested a lot of effort in Debian in order to
On Sun, Sep 06 2009, Russ Allbery wrote:
> "Nikita V. Youshchenko" writes:
>
>> This does not help in a corner case.
>
>> Issue I am looking at is:
>> - a library used to export a symbol, it was visible in objdump -T output,
>> - at some point, upstream decides that this symbol should be removed,
Henrique de Moraes Holschuh wrote:
> So why exactly should we support this breakage in udev, again? If what it
> takes is to move the usb and pci ID databases to /, so be it. When compared
> to our kernel tarballs, they're small, less than 1MB for both of them.
Agreed. Moving usb.ids and pci.id
Steve Langasek wrote:
> And if the symbols in question were exported in a header (else how did
> mplayer come to depend on them?),
The package could have defined the prototype before using it. That's a real live
scenario, see e.g. #542216 (hopefully it's not very frequent...).
Emilio
signature
Manoj Srivastava writes:
> On Sun, Sep 06 2009, Russ Allbery wrote:
>> We have done this in the past in Debian without changing the SONAME in
>> places where compatibility of SONAME with other distributions is
>> important. Specifically, libkrb53 removed several private symbols and
>> we didn't
On Mon, 07 Sep 2009, Michael Biebl wrote:
> Henrique de Moraes Holschuh wrote:
> > So why exactly should we support this breakage in udev, again? If what it
> > takes is to move the usb and pci ID databases to /, so be it. When compared
> > to our kernel tarballs, they're small, less than 1MB for
Henrique de Moraes Holschuh wrote:
> IMO, whomever came up with the idea of leaking pci.ids and usb.ids data to
> /dev, made a bad mistake. Just because you'd show something in an UI,
> doesn't mean it can be used to permanently identify a device safely. I have
> no idea what HAL, and HAL-consume
Can we have amarok 1.4 as an option to use? in my opinion, amarok 2 is not
usable yet. I decided to give it a try when it replaced 1.4 in squeeze, but
it's missing many 1.4 features and has many unstable glitches that were not
present in 1.4.
Currently when I run amarok I get a dcop no reply error
Sounds like upstream should be persuaded to move the shared library
code into the daemon since there is no reason for it to be in a
library. Until then, install it as a private shared library and use
rpath so the daemon/plugins can find the library.
--
bye,
pabs
http://wiki.debian.org/PaulWise
[Please CC me in replies, I am currently not subscribed to -devel].
On Saturday 05 September 2009 01:21:00 pm Petter Reinholdtsen wrote:
> The plan is to
> change upstart to actually use /etc/inittab, to ease the switch
> between sysvinit and upstart.
Please don't. As you correctly pointed out,
Ok, thank you for the clarification, Steve!
Best regards
--
Danai SAE-HAN (韓達耐)
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
39 matches
Mail list logo
