Custom Query (1145 matches)

Reported by geofft, 13 years ago.

Evan tells me that

• ia32-libs is going away in Oneiric in favor of multiarch
• the multiarch spec does not allow dependencies on packages from a non-native architecture -- you have to manually install said packages in a separate invocation.

This combines to mean that it's impossible to write a metapackage that depends on the libraries we've been wanting to run things out of AFS -- e.g., debathena-athena-libraries can't depend on 64-bit and 32-bit libraries on amd64. At best we can write an arch-dependent metapackage debathena-athena-lib32raries, but none of our other metapackages can depend on that; it'll have to be installed manually.

The right place to figure out what we need to do about this, and possibly what upstream needs to do about this, is  #multiarch on OFTC. I'm milestoning this as a Natty Beta blocker because we need to deal really really quickly before Oneiric's multiarch plans are too immutable, even though it doesn't affect the Natty cluster release directly.

References:  https://wiki.ubuntu.com/MultiarchSpec

Pre-multiarch, architecture-dependent packages may depend on Architecture: all packages and assume that the transitive dependencies will be resolved using packages of the same architecture or other packages that are Architecture: all. To avoid breaking this assumption, Architecture: all packages will, at least initially, be treated as equivalent to packages of the native architecture for all dependency resolution. This means that for an Architecture: all package to satisfy the dependencies of a foreign-architecture package, it must be marked Multi-Arch: foreign or Multi-Arch: allowed.

 http://summit.ubuntu.com/uds-o/meeting/foundations-o-multiarch-next-steps/

Oneiric goals:

• ia32-libs out of the archive (i.e. multiarch-ify everything in ia32-libs - at least 200 libraries)
• Get rid of lib{32,64}foo

 http://wiki.debian.org/Multiarch

Reported by geofft, 13 years ago.

D-Bus has a facility for running services when you send a message to a well-known name but no service is bound to that well-known name (these services are listed in /usr/share/dbus-1/system-services). The system D-Bus daemon runs outside the chroot, so naturally services it activates will also run outside the chroot.

This interacts poorly in a couple of cases with privileged-inside-the-chroot programs making requests to daemons outside the chroot over D-Bus. One notable case is aptdaemon, used by Ubuntu Software Center -- if you install something via that GUI (as opposed to any other GUI, or the command line), then it will get installed in the environment of aptdaemon, namely outside the chroot.

We're probably seeing this in production, given that we've run into a couple of machines with Skype mysteriously installed outside the chroot, and Skype from the partners repository is well-advertised in Ubuntu Software Center.

Addressing #462 would fix this solidly, but would also be fairly high-impact. A much smaller-impact fix is to hook the servicehelper (/usr/lib/dbus-1.0/dbus-daemon-launch-helper, as mentioned in /etc/dbus-1/system.conf), which elevates privileges from the messagebus user to root when running a service. Since we want D-Bus activation to work at boot time, we should have a wrapper that detects if a login chroot exists, and runs the original servicehelper inside the chroot if so, and otherwise just runs the original servicehelper.

Reported by tabbott, 17 years ago.

We should investigate making a package that configures VPNC to use the MIT VPN service.