Bug#1064457: ITP: composefs -- file system for mounting container images

Awesome, thanks Roland! Don’t hesitate to reach out if you hit any issues! On Wed, Feb 12, 2025, at 4:53 AM, Roland Hieber wrote: > Control: owner -1 ! > > I've now put together some initial packaging using the git-buildpackage > workflow, which seems to work okay (the binaries do what they should

Bug#1064457: Happy to help

Hey I'm one of the upstream maintainers of composefs (and ~20 years ago I was a Debian Developer...) and I am happy to help with whatever needs doing here. One thing I'd call out is that today the podman container runtime can optionally use composefs - it's a soft dependency today but I'd like t

Bug#823548: linux-user-chroot deprecation

l-u-c post: https://mail.gnome.org/archives/ostree-list/2016-May/msg0.html FWIW if any transition scripts are written I'd be happy to have them in l-u-c upstream. I'm as yet unsure whether it's worth doing so, or pushing for dependent consumers to do a hard port. I'm doing the latter with m

Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus

On Wed, Jan 7, 2009 at 6:41 PM, Marcel Holtmann wrote: > > that is exactly how it works and we can't use signal. Even directed > signal are not working since the method call into the agent has to > return the result or an error. > > What problem do you guys actually have with this? The agent insid

Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus

On Wed, Jan 7, 2009 at 6:25 PM, Simon McVittie wrote: > > As a solution for the current release of BlueZ, assuming that rethinking > the Agent API completely is not an option, does the proposed policy at >

Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus

On Wed, Jan 7, 2009 at 3:09 PM, Simon McVittie wrote: > > As far as I can tell, BlueZ agents work like this: > > * the agent (a UI process run by a user) calls a method on the hci daemon (run > by root) and passes in its unique name and its (arbitrary) object path > * later, the hci daemon calls

Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus

On Wed, Jan 7, 2009 at 2:17 PM, Simon McVittie wrote: > >> Unfortunately they don't a well known service name nor object path, agents >> are >> user-registered > > Never mind. We have a lot of these rules in the archive anyway > (http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-utopia-maint

Bug#497321: Question on license terms for a Makefile of yours

On Tue, Sep 2, 2008 at 4:03 PM, Francesco Poli <[EMAIL PROTECTED]> wrote: > Hi Colin, > I am a Debian user who recently filed bug #497321, where I proposed a > modified version of a Makefile apparently created by you. Hi, In general all code I wrote for a Debian package should be considered to be

Bug#495257:

For etch->lenny, if you really care, you could have an out of band (i.e. out-of-dpkg) preupgrade process which deletes the old dbus' package prerm script. Now long term, there are multiple cases, as I argued here: http://mail.gnome.org/archives/networkmanager-list/2005-March/msg00033.html To sum