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
[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,
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
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
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
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
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
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
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
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,
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 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 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
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
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
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
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
"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 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
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 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, 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 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, 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
* 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 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
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 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
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 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 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
> 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
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
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
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
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
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
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
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
39 matches
Mail list logo
