Re: Repository switch over to Salsa?
Hi! On Sat, 2018-06-02 at 18:59:22 +0200, Sven Joachim wrote: > On 2018-06-01 03:27 +0200, Guillem Jover wrote: > > On Thu, 2018-05-31 at 18:20:35 +0200, Helge Kreutzmann wrote: > >> On Fri, Feb 09, 2018 at 03:31:00AM +0100, Guillem Jover wrote: > >> > On Sat, 2018-02-03 at 19:11:42 +0100, Helge Kreutzmann wrote: > >> > > Are you reestablishing commit access as it is currently? Hey, so the migration is almost done, I need an account name and ssh public keys from both of you. I'll send another mail announcing the new setup. Thanks, Guillem
Re: Repository switch over to Salsa?
Guillem Jover writes ("Re: Repository switch over to Salsa?"):
> Hey, so the migration is almost done, I need an account name and ssh
> public keys from both of you. I'll send another mail announcing the
> new setup.
On a tangent: I recently had cause to `dgit clone dpkg' and I was
disappointed that I didn't get the proper git history. Is there a
reason you are not using `dgit push' ?
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Frontend locking in APT clients
Hi folks,
With frontend locking in dpkg git, I think it's time I clear up
some potential confusion as to how this is supposed to work in the
APT world.
The idea is that the current _system->Lock() / apt_pkg.SystemLock
/ apt_pkg.pkgsystem_lock() will start to manage _both_ lock-frontend
and lock, and new methods LockInner() and UnlockInner() will be
provided to release "lock". Code running dpkg will need to call
those around dpkg runs, rather than the generic Lock ones.
python-apt is currently broken in that you need to release the lock
prior to calling commit() on an apt.Cache. This will change soon
- no unlocking will be needed. A python-apt (>> 1.7~alpha1~) client
should behave as following:
Basically, add Depends: python-apt (>> 1.7~alpha1~), and do:
with apt_pkg.SystemLock():
main()
- forget about locks if you don't invoke dpkg manually - do not
release that, ever. If you do run dpkg manually do it like this:
with apt_pkg.NoInnerLock():
subprocess.check_call(["dpkg", "--configure", "-a"])
or instead of context managers, use the functions
pkgsystem_{un,}lock{,_inner}.
This will ensure that your apt client will be safe against
any other apt client, and any other client implementing frontend
locking. It will not be safe against other frontends that acquire
the dpkg lock themselves, those will need fixing too. It will however,
be safe against concurrent runs of dpkg by users or frontends not
implementing locking.
Thanks,
Julian
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Re: Frontend locking in APT clients
On Mon, Jun 18, 2018 at 08:19:17PM +0200, Julian Andres Klode wrote:
> Hi folks,
>
> With frontend locking in dpkg git, I think it's time I clear up
> some potential confusion as to how this is supposed to work in the
> APT world.
>
> The idea is that the current _system->Lock() / apt_pkg.SystemLock
> / apt_pkg.pkgsystem_lock() will start to manage _both_ lock-frontend
> and lock, and new methods LockInner() and UnlockInner() will be
> provided to release "lock". Code running dpkg will need to call
> those around dpkg runs, rather than the generic Lock ones.
>
> python-apt is currently broken in that you need to release the lock
> prior to calling commit() on an apt.Cache. This will change soon
> - no unlocking will be needed. A python-apt (>> 1.7~alpha1~) client
> should behave as following:
>
> Basically, add Depends: python-apt (>> 1.7~alpha1~), and do:
> with apt_pkg.SystemLock():
> main()
> - forget about locks if you don't invoke dpkg manually - do not
> release that, ever. If you do run dpkg manually do it like this:
>
> with apt_pkg.NoInnerLock():
> subprocess.check_call(["dpkg", "--configure", "-a"])
I want to note that apt in its current merge request state,
automatically sets DPKG_FRONTEND_LOCKED when invoking dpkg
if the system lock is acquired (after the fork, directly
before the execvp). If you run dpkg yourself, like for calling
dpkg --configure -a you will probably have to set the environment
variable yourself.
So you'll need:
with apt_pkg.NoInnerLock():
os.putenv("DPKG_FRONTEND_LOCKED", "1")
subprocess.check_call(["dpkg", "--configure", "-a"])
I thought about making Lock() set the variable and unlock unset
it, but I'm not sure about implicatiomns wrt other subprocesses
like hooks.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
