Re: The future of the boot system in Debian

[Manoj Srivastava]

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 (please correct me if this is not
>  the case).  I would be happy to help integrate selinux  into upstart,
>  if that is the future of booting in Debian.
>
> Having /sbin/init load the security policy is good because:
>  a) Doing it in an init script  makes it easier to by pass security by
> running another script earlier (so a malicious superuser may
> trivially bypass security on reboot). This is even harder to prevent
> using an event based system.
>  b) Using an init script makes it impossible to enforce security
> policies and access control over which files /sbin/init may read,
>  c) Since it is compiled in, there is no dependency on things in
> /usr/bin -- like load_policy, which also needs libsepol1 from /usr,
> which is not small,
>  d) Putting policy loading in initramfs is bad for two reasons:
> i) It means we would not longer suport SELinux use without having to
>use initramfs -- my machines do not use either an initramfs, nor
>modules -- which is easy when using custome kernels, and I think
>is a use case Debian should continue to support
>ii) We would need to either patch something in the initramfs to link
>with libselinux1, to load policy directly, or we will have to
>load into the initramfs load_policy and libsepol1 from /usr,
>Adding a couple f small hunks to whatever provides /sbin/init
>seems easier.
>  e) At this point, we only have two candidates for /sbin/init, sysvinit
> and upstart, so the burden of writing patches is no onerous, and in
> any case, I am volunteering to help create the patches.

Well, here is a (lightly) tested patch for upstart.

manoj

 .../debian/changelog   |   11 ++
 .../debian/control |4 +-
 .../debian/patches/001-selinux-support |  132 
 .../debian/patches/series  |1 +
 {upstart-0.6.3.orig => upstart-0.6.3}/debian/rules |4 +
 5 files changed, 151 insertions(+), 1 deletions(-)

diff --git upstart-0.6.3.orig/debian/changelog upstart-0.6.3/debian/changelog
index be2b21f..afaf59a 100644
--- upstart-0.6.3.orig/debian/changelog
+++ upstart-0.6.3/debian/changelog
@@ -1,3 +1,14 @@
+upstart (0.6.3-1.1) UNRELEASED; urgency=low
+
+  * Add support for loading SELinux policy early in the boot
+sequence. This changeset adds conditional support for loading SELinux
+policy early in the boot sequence if a) it is enabled at compile time,
+and b) the machine has SELinux enabled at run time.  Also, since the
+SELinux support patch is conditionally effective, this patch adds
+support for enabling it on Linux architectures. 
+
+ -- Manoj Srivastava   Sat, 05 Sep 2009 12:15:46 -0500
+
 upstart (0.6.3-1) unstable; urgency=low
 
   * New upstream release.
diff --git upstart-0.6.3.orig/debian/control upstart-0.6.3/debian/control
index 2c6226b..c4aa61f 100644
--- upstart-0.6.3.orig/debian/control
+++ upstart-0.6.3/debian/control
@@ -4,7 +4,9 @@ Priority: extra
 Maintainer: Michael Biebl 
 Uploaders: martin f. krafft 
 Standards-Version: 3.8.2
-Build-Depends: debhelper (>= 7), quilt, pkg-config (>= 0.22), libdbus-1-dev (>= 1.2.16), libexpat1-dev (>= 2.0.0)
+Build-Depends: debhelper (>= 7), quilt, pkg-config (>= 0.22), libdbus-1-dev (>= 1.2.16), libexpat1-dev (>= 2.0.0),
+   libselinux1-dev (>= 1.14) [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64],
+   libsepol1-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64]
 Vcs-Git: git://git.debian.org/git/collab-maint/upstart.git
 Vcs-Browser: http://git.debian.org/?p=collab-maint/upstart.git;a=summary
 Homepage: http://upstart.ubuntu.com/
diff --git upstart-0.6.3/debian/patches/001-selinux-support upstart-0.6.3/debian/patches/001-selinux-support
new file mode 100644
index 000..bceec13
--- /dev/null
+++ upstart-0.6.3/debian/patches/001-selinux-support
@@ -0,0 +1,132 @@
+From 75658fbccea3fe087f1fa5a4971e4319a05201a1 Mon Sep 17 00:00:00 2001
+From: Manoj Srivastava 
+Date: Sat, 5 Sep 2009 11:46:45 -0500
+Subject: [PATCH 2/2] Add functionality to load SELinux policy early in boot
+
+This patch is applied conditionally, and unless WITH_SELINUX is defined
+when make is called (that is, at compile time), it does nothing. If
+WITH_SELINUX is set to 'yes' at compile time, this patch, analogous to
+that in sysvinit, checks early to see if SELinux is enabled on the
+machine, and then tries to load policy, If loading policy fails,and if
+SELinux is in enforcing mode, it prevents startup.
+
+If the machine does not have selinux enabled at run time, nothing
+happens.
+
+Signed-off-by: Man

Re: The future of the boot system in Debian

[Steve Langasek]

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 will have to do to support the
> non-Linux ports which are unable to run upstart?

 - Install a symlink in /etc/init.d instead of an init script, pointed at
   /lib/init/upstart-job and named to match the upstart job file (with the
   .conf extension removed)
 - Add a dependency on the virtual package upstart-job.

An upcoming version of debhelper should implement this as part of
dh_installinit - just provide debian/[.].upstart instead of
debian/].init.  Cf. bug #536035.

The upstart-job utility, provided by the upstart source package, will then
simulate sensible init script behavior on systems using sysvinit, including
a query interface for LSB init script options to support dependency-based
booting.

> 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.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: apt-get not working anymore

[Hans-J. Ullrich]

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
Ah, yes, I understand. So, as I am running unstable, this will not really 
help.

But in stable there is (when i remember correctly), still an apt.conf, where 
you also can add the line above (the line actually belongs to there, I added 
it in the other file, as in later versions apt.conf is no more available. 
However, it works for me) 

If I understood you wrong, please apologize for the noise.


Good luck!

Hans
 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

library-related policy question

[Nikita V. Youshchenko]

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 symbols, by definition an RC bug against 
library package? Or is depends on particular situation?

Nikita

P.S.
Please CC replies to my e-mail address.


signature.asc
Description: This is a digitally signed message part.

Re: The future of the boot system in Debian

[Marco d'Itri]

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 supporting sysvinit on Linux systems?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: DeviceKit and /usr

[Hendrik Sattler]

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 would be negligible; the total size impact of pulling in libglib
> on the desktop is zero; and the size impact to /lib for desktops is almost
> certainly also negligible.

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 
what worries me. If libglib is accepted are core utility in /lib, there will 
be no end to this :-(

> (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?

HS


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: library-related policy question

[Emilio Pozuelo Monfort]

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 binaries 
> stops working because of missing symbols, by definition an RC bug against 
> library package? Or is depends on particular situation?

Yes, it's an RC bug. If you break the API and/or ABI, you need to change the
package name and the SONAME.

See e.g.
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#binarycompat

Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: library-related policy question

[Nikita V. Youshchenko]

> 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
> > binaries stops working because of missing symbols, by definition an RC
> > bug against library package? Or is depends on particular situation?
>
> Yes, it's an RC bug. If you break the API and/or ABI, you need to change
> the package name and the SONAME.
>
> See e.g.
> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html

Is libpkg-guide an official debian document these days?
If not, maybe API/ABI-keep requirement should be added to Policy?


signature.asc
Description: This is a digitally signed message part.

Re: library-related policy question

[Julien Cristau]

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 same package?
> > 
> > I mean, is a situation when after library package upgrade local binaries 
> > stops working because of missing symbols, by definition an RC bug against 
> > library package? Or is depends on particular situation?
> 
> 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".

Policy already has "The run-time shared library needs to be placed in a
package whose name changes whenever the shared object version changes"
(with the assumption that the SONAME changes when ABI breaks) in section
8.1.

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: library-related policy question

[Jan Hauke Rahm]

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 versions of the same package?
> > >
> > > I mean, is a situation when after library package upgrade local
> > > binaries stops working because of missing symbols, by definition an RC
> > > bug against library package? Or is depends on particular situation?
> >
> > Yes, it's an RC bug. If you break the API and/or ABI, you need to change
> > the package name and the SONAME.
> >
> > See e.g.
> > http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
> 
> Is libpkg-guide an official debian document these days?
> If not, maybe API/ABI-keep requirement should be added to Policy?

I don't think there is a reason to change Policy. If a package breaks
other packages it's considered an RC bug. Since shared libraries are
meant to be used through API and ABI, a breakage of those means breaking
other packages. The libpkg-guide has good guidelines on how to prevent
such, i.e. changing SONAME and package name.

Hauke


signature.asc
Description: Digital signature

Re: DeviceKit and /usr

[Marco d'Itri]

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

Re: library-related policy question

[Nikita V. Youshchenko]

> 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 same
> > > package?
> > >
> > > I mean, is a situation when after library package upgrade local
> > > binaries stops working because of missing symbols, by definition an
> > > RC bug against library package? Or is depends on particular
> > > situation?
> >
> > 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".
>
> Policy already has "The run-time shared library needs to be placed in a
> package whose name changes whenever the shared object version changes"
> (with the assumption that the SONAME changes when ABI breaks) in section
> 8.1.

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 public APIs".
- but this results into binary stop working.

To be particular: this is about libavformat52 and mplayer.

mplayer from debian sid, executed against libavformat52 sid, works.

mplayer from debian sid, executed against libavformat52 from 
debian-multimedia, fails with 'mplayer: symbol lookup error: mplayer: 
undefined symbol: codec_wav_tags'.

We've discussed that with Christian Marillat (debian-multimedia 
maintainer), that resulted into upstream bug report at 
http://roundup.ffmpeg.org/roundup/ffmpeg/issue1352, but upstream rejected 
the issue.

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.

Nikita


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DeviceKit and /usr

[Julien BLACHE]

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 - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: library-related policy question

[Julien Cristau]

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 that happens, you change the libavformat52 package name to
something else?

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: library-related policy question

[Florian Weimer]

* 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 library
package at all (as seen with apt).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: The future of the boot system in Debian

[Pierre Habouzit]

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 relevant for Linux-specific packages as well? I.e., do we want
> to continue supporting sysvinit on Linux systems?

for one: LSB somehow requires it.
second:  I think it's disruptive for users to be unable to do
 /etc/init.d/$service stop/start/restart anymore.

So I'd say that even for Linux we want some kind of sysvinit like
scripts anyways.


-- 
Intersec 
Pierre Habouzit 
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie


signature.asc
Description: Digital signature

Re: The future of the boot system in Debian

[Pierre Habouzit]

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 100644
> --- upstart-0.6.3.orig/debian/changelog
> +++ upstart-0.6.3/debian/changelog
> @@ -1,3 +1,14 @@
> +upstart (0.6.3-1.1) UNRELEASED; urgency=low
> +
> +  * Add support for loading SELinux policy early in the boot
> +sequence. This changeset adds conditional support for loading SELinux
> +policy early in the boot sequence if a) it is enabled at compile time,
> +and b) the machine has SELinux enabled at run time.  Also, since the
> +SELinux support patch is conditionally effective, this patch adds
> +support for enabling it on Linux architectures. 
> +
> + -- Manoj Srivastava   Sat, 05 Sep 2009 12:15:46 -0500

Isn't it a duplicate of #543420 where the maintainer claims upstream
doesn't want such a patch ?

-- 
Intersec 
Pierre Habouzit 
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie


signature.asc
Description: Digital signature

Re: udev and /usr

[Frank Lin PIAT]

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 standard*, you don't
> > arbitrarily change what you're doing and claim that it still complies with
> > the standard because "the standard follows what Red Hat does".
> I am not claiming that this complies with the standard, just that it
> does not matter because if there is a wide consensus (which does not
> need to be unanimous) about this then eventually the standard will be
> updated to reflect it.
> Anyway, FHS also has examples of things changed long after they were
> adopted by everybody, like /var/spool/mail/ vs. /var/mail/.

I would ask a question to [FHS|udev-upstream|whoever] : What "smooth"
migration path do you offer for those millions systems that are
installed with a standalone /usr?

I am grateful to udev developers and maintainers. I remember what was
Linux before udev... (far too many "vim /etc/modules", MAKEDEV, chown
and chmod )

FWIW, I did some statistics on installation-reports (in my debian-boot
mailing list backlog).
  48 reports has the string "% /dev"
  18 reports has the string "% /usr"
That's 37% ! This statistics are probably biased, because people with a
single partition layout probably don't bother reporting their disk
partitioning.

My 2¢,

Franklin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: The future of the boot system in Debian

[Steve Langasek]

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 relevant for Linux-specific packages as well? I.e., do we want
> to continue supporting sysvinit on Linux systems?

We at least need to support it initially, to avoid forcing users to migrate
to upstart before we have a migration path that doesn't involve typing the
"Yes, I want to break my system" rune into apt-get. :)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: The future of the boot system in Debian

[Steve Langasek]

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 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 supporting sysvinit on Linux systems?

> for one: LSB somehow requires it.

No.  The LSB requires *LSB packages* to use init scripts.  Debian
packages are not LSB packages.

> second:  I think it's disruptive for users to be unable to do
>  /etc/init.d/$service stop/start/restart anymore.

The transition plan here is to allow users to use the 'service' command
('service $service stop/start/restart') as an abstraction layer.  If the
ports all migrate to upstart too, we'll eventually want to stop shipping
these symlinks.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: library-related policy question

[Steve Langasek]

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 change the SONAME".

> It's still possible to work around that by not providing a library
> package at all (as seen with apt).

In that case, the virtual package name as used in the shlibs/symbols files
still changes with each ABI change.

And doing this makes partial upgrades impossible, so is not generally
recommended.  In the case of apt it's appropriate because you don't want two
different versions of the library accessing the same on-disk data
simultaneously.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: library-related policy question

[Russ Allbery]

"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 public APIs".
> - but this results into binary stop working.

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 change the SONAME.  *However*, if you're thinking about doing that,
you have to both be quite sure that the number of packages using that
symbol is very limited and rare *and* coordinate that change with all of
those packages, which will probably mean adding Breaks to the new version
of the shared library.

Usually this is more hassle than it's worth, but diverging from upstream
on SONAME can also be an annoying long-term maintenance problem.  The more
central the library (and hence the larger the transition if it changes
SONAME), the more it's worth putting some effort into avoiding changing
the SONAME.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: The future of the boot system in Debian

[Pierre Habouzit]

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 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 supporting sysvinit on Linux systems?
> 
> > for one: LSB somehow requires it.
> 
> No.  The LSB requires *LSB packages* to use init scripts.  Debian
> packages are not LSB packages.

Okay, my mistake.

> > second:  I think it's disruptive for users to be unable to do
> >  /etc/init.d/$service stop/start/restart anymore.
> 
> The transition plan here is to allow users to use the 'service' command
> ('service $service stop/start/restart') as an abstraction layer.  If the
> ports all migrate to upstart too, we'll eventually want to stop shipping
> these symlinks.

I see. Let's hope our SHELLs will pick up completions soon enough then
;)


-- 
·O·  Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org


signature.asc
Description: Digital signature

Re: library-related policy question

[Steve Langasek]

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 symbol should be removed, 
> > claiming that "it was not ever included in any public APIs".
> > - but this results into binary stop working.

> 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 change the SONAME.  *However*, if you're thinking about doing that,
> you have to both be quite sure that the number of packages using that
> symbol is very limited and rare *and* coordinate that change with all of
> those packages, which will probably mean adding Breaks to the new version
> of the shared library.

And if the symbols in question were exported in a header (else how did
mplayer come to depend on them?), it can be very difficult to be sure you
know the complete set of reverse-dependencies.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#545375: ITP: fbcat -- framebuffer grabber

[Piotr Lewandowski]

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

fbcat grabs an image of a framebuffer and stores in a PPM file.
.
This package also provides a compatibility wrapper around fbcat to ease 
mirgration from fbgrab.


--
Piotr Lewandowski



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

shared library in binary-package?

[Heiko Stübner]

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 libfsousage.so* 
and three plugins (controller.so, lowlevel_kernel26.so, lowlevel_openmoko.so).

The plugins use libfsousage and fsousaged loads them according to its config-
file.

According to the debian-policy libfsousage would require the two separate 
shared libary packages (0, -dev) but the only users are and will be fsousaged 
and the plugins alone.

Are there other packaging options for such a case, as libfsousage is currently 
3,4KB and it seems like much overhead to have the library-packages when there 
won't ever be other users of it.

Currently I have all in one package (34KB deb / 252KB installed-size) but 
lintian doesn't like it.

Any pointers would be greatly appreciated.

Thanks
Heiko


signature.asc
Description: This is a digitally signed message part.

Re: RFC: update-inetd migration to dpkp-triggers

[Marco d'Itri]

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 are proposing.

For a start, (x)inetd is used by less and less programs, are the changes
you are planning justified considering that we have lived with the
current limitations for 15 years without significant troubles?
And do we really need all the complexity to support xinetd, which is
installed by 3.8% of the users?

> * abolish /etc/inetd.conf and /etc/xinetd.d/ and instead auto-generate
This is unacceptable, and I say this as the openbsd-inetd maintainer
(which is another reason why you should have discussed this first with
the other maintainers involved).
/etc/inetd.conf is a well known UNIX interface and it must continue to
be supported, at least for locally-configured services.

> * document that local policy will live in /etc/inetd.conf.d/ and any manual
>   changes will be made effective by running update-inetd
I also consider not acceptable that manual configuration changes are
ignored unless some program is run.

> * should version-depend in the update-inetd version that is shipped in
>   squeeze (so that /etc/inetd.conf.d/ is in place)
Hint: at this point, you can as well create a new package with a
different name which will use the new interface.

> * all deamon packages that use update-inetd [1]:
> * should drop their dependency in update-inetd and should not call
>   anymore update-inetd in postinst/prerm scripts
The only packages which can depend on update-inetd are the ones
providing inet-superserver. If any other package is depending on
update-inetd it is broken.

> [1] 40: the number of update-inetd's rdeps in main/unstable, excluding
> ``Provides: inet-superserver'' packages
Feel free to file bugs.

Other than this, I agree with vorlon's sensible remarks.

-- 
ciao,
Marco


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: udev and /usr

[Henrique de Moraes Holschuh]

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 Hat and Suse said they do not
> support this and except Debian nobody else raised the issue.

RedHat doesn't care because RedHat users have to reinstall from scratch
every major version bump, which is equivalent to Debian telling you you have
to reinstall from scratch every new stable release.

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.

As for the update-usbids and update-pciids problems, we can certainly
repackage this stuff in volatile and drop the two utilities as well the /var
issue it generates.  Symlinks will provide all backwards-compatibility that
is needed.  I believe we should do this regardless, but we better decide if
these databases have to live under / or /usr first.

How wise is to depend on these two databases for by-id symlinks, though?  I
have seen devices in my systems get new names and revised names on both PCI
and USB in the past, and I am not aware of any new rule that it won't happen
again.  There is also the obvious one when a device gets first added to the
database.

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-consumers did with that information (maybe it was
for display purposes only, for example?), but I do know that stuff that ends
up in /dev/by-id IS very likely to be used as a permanent way to identify
devices in places like /etc/fstab, etc.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: The future of the boot system in Debian

[Manoj Srivastava]

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 make Squeeze SELinux
 compliant, and make it so that turning on SELinux is fairly easy. I
 have asked the release managers to consider making Squeeze have SELinux
 working out of the box a release goal, and so far there has been no
 denial; and I consider the patch consistent with the choices we have
 made as a project in the past.

I am also saying that I would be willing to maintain the SELinux
 patches  in sysvinit/upstart, if it comes to that, and the "burden" of
 keeping the patch around would be fairly small (it is a small patch,
 and  fairly self contained).

manoj
-- 
"A pacifist who calls the police isn't one; hired violence is still
violence." Clayton E. Cramer optilink!cramer
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: library-related policy question

[Manoj Srivastava]

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, 
>> claiming that "it was not ever included in any public APIs".
>> - but this results into binary stop working.
>
> 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 change the SONAME.  *However*, if you're thinking about doing that,
> you have to both be quite sure that the number of packages using that
> symbol is very limited and rare *and* coordinate that change with all of
> those packages, which will probably mean adding Breaks to the new version
> of the shared library.
>
> Usually this is more hassle than it's worth, but diverging from upstream
> on SONAME can also be an annoying long-term maintenance problem.  The more
> central the library (and hence the larger the transition if it changes
> SONAME), the more it's worth putting some effort into avoiding changing
> the SONAME.

While coordinating with other packages is nice, it is not nice
 to break user created packages either.  Being systems integrators we
 sometimes get myopic about only being concerned with breakage in "our"
 product, but we should also have care that our users too might actually
 use the libraries we ship.  Coordinating with all users is a far harder
 task.

manoj
-- 
The only really decent thing to do behind a person's back is pat it.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: udev and /usr

[Michael Biebl]

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.ids to / (/lib/hwdata was a proposed location)
seems currently the best solution to me.

> As for the update-usbids and update-pciids problems, we can certainly
> repackage this stuff in volatile and drop the two utilities as well the /var
> issue it generates.  Symlinks will provide all backwards-compatibility that
> is needed.  I believe we should do this regardless, but we better decide if
> these databases have to live under / or /usr first.

I'd also vote for removing update-usbids and update-pciids.
Those tools looks broken to me anyway. given that a package upgrade will
overwrite an updated ids file again.

Aurel's concern was, if usbutils (and pciutils for that matter) were acceptable
for volatile and Luk (on debian-release) acknowledged that this package would be
ok for volatile and stable point releases.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: library-related policy question

[Emilio Pozuelo Monfort]

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.asc
Description: OpenPGP digital signature

Re: library-related policy question

[Russ Allbery]

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 change the SONAME.  *However*, if you're thinking about doing
>> that, you have to both be quite sure that the number of packages using
>> that symbol is very limited and rare *and* coordinate that change with
>> all of those packages, which will probably mean adding Breaks to the
>> new version of the shared library.

>> Usually this is more hassle than it's worth, but diverging from
>> upstream on SONAME can also be an annoying long-term maintenance
>> problem.  The more central the library (and hence the larger the
>> transition if it changes SONAME), the more it's worth putting some
>> effort into avoiding changing the SONAME.

> While coordinating with other packages is nice, it is not nice
>  to break user created packages either.  Being systems integrators we
>  sometimes get myopic about only being concerned with breakage in "our"
>  product, but we should also have care that our users too might actually
>  use the libraries we ship.  Coordinating with all users is a far harder
>  task.

Right, when we did this for libkrb53 (and by "we" I mean mostly Sam), it
was part of coordinated effort with upstream to remove the deprecated
symbols from the library exports, and upstream was also reaching out to
all the users as well.  The symbols being removed hadn't been prototyped
unless you defined KRB5_DEPRECATED and then were removed entirely from the
headers before being removed from the exports, and there was a lot of
advance warning across multiple releases.

It's almost never worth the effort to avoid the SONAME change.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: udev and /usr

[Henrique de Moraes Holschuh]

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 both of them.
> 
> Agreed. Moving usb.ids and pci.ids to / (/lib/hwdata was a proposed location)
> seems currently the best solution to me.

Well, the best solution could well be to not do fragile, broken things like
using variable (and untrusted) data to set up permanent device ids.

So, I'd rather see that one answered before anyone bothers with moving
pci.ids and usb.ids around.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: udev and /usr

[Michael Biebl]

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-consumers did with that information (maybe it was
> for display purposes only, for example?), but I do know that stuff that ends
> up in /dev/by-id IS very likely to be used as a permanent way to identify
> devices in places like /etc/fstab, etc.

From what I can see in /lib/udev/rules.d, the ids files are only used to setup
the (udev) environment variable ID_VENDOR_FROM_DATABASE
(75-net-description.rules, 75-tty-description.rules, 78-sound-card.rules).

There are no symlinks created in /dev based on that information.

Given the name of the rules file, it indeed looks to be intended to be used for
display/descriptive purposes.


Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

amarok 2 in squeeze

[Andrew R Kelley]

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 message. I can't
even run the program. It worked for a while, kind of, and then died.

In conclusion, I think AT LEAST amarok 1.4 should be in the repository.

Thanks,

-- 
Andy Kelley
Nuclear Development
http://nucleardev.com/

Re: shared library in binary-package?

[Paul Wise]

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: The future of the boot system in Debian

[Rene Mayrhofer]

[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, the current Debian init 
architecture is one of the most painful and outdated (not to say broken) parts 
in the whole system. It's really time to move away from old cruft (and I 
consider inittab to be cruft of little use at this time) and start using 
something that will not cause more pain in the future.


There is definitely a need to support inittab during the transition period, but 
this can be done like the file-rc package has been doing for years: with 
conversion scripts to and from the old format, supporting those legacy 
features that make sense but not committed to care for every corner case. 
Leave those (probably multiple-100-lines perl/shell beasts) in place for a 
couple of years, declare inittab deprecated with squeeze (or squeeze+1), and 
remove afterwards.

I would also _strongly_ suggest to do another iteration over all init scripts 
and mandate the implementation of a "status" command as well as parameters to 
"start" (or add a "start-nofork" command or something like that) to start the 
service with exec instead of fork. This would pave the way for using 
daemon/service supervision in the future (e.g. using upstart and deferring to 
standard init scripts to implement its native event.d files), and thus for more 
robust embedded systems support.

Full ack for all other points in your mail, though. I have been using upstart 
on the current beta and upcoming release of Gibraltar firewall as well as all 
my Debian servers for the better part of 1 1/2 years and have not had any 
issues with it so far. 

best regards,
Rene


signature.asc
Description: This is a digitally signed message part.

Re: Policy of capitalisation of in /usr/share/?

[韓達耐]

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