Re: [Tails-dev] Sharing wiperam package between Freepto and …

Borrar esta mensaxe

Responder a esta mensaxe
Autor: intrigeri
Data:  
Para: The Tails public development discussion list
CC: freepto
Asunto: Re: [Tails-dev] Sharing wiperam package between Freepto and Tails?
Hi,

@Patrick: why is the build-dep on config-package-dev versionned to
0.5.1? Isn't Wheezy's 4.13 good enough for our needs? (Worst case, we
can fetch 0.5.1 from wheezy-backports, but still :)

intrigeri wrote (25 Jun 2014 07:51:25 GMT) :
> Patrick Schleizer wrote (11 Jun 2014 12:58:23 GMT) :
>> Did some work on this... Link:
>> https://github.com/adrelanos/wiperamFreepto


> I'll look at it tomorrow with Freepto's ono-sendai. I guess this will
> be a good basis to go on working on this. If you want to improve
> things a bit today based on the input that follows, feel free :)


The current state of our work is on:
https://git-tails.immerda.ch/wiperam
(May take a few minutes before it's available.)
Untested yet.

>> = source folder name =


>> I appreciated, if we could rename source folder to wiperam. That would
>> make the ./build script work out of the box.


> Just do it? Otherwise, we'll do it tomorrow.


The Tails' repo is called wiperam, so this should be fine.

>> We probably do not need to use invoke-rc.d after "
>> update-rc.d kexec-load defaults" in maintainer scripts?


> Will look at it tomorrow.


I don't think we need to run invoke-rc.d for our own initscripts,
but we've added calls to it to reload memlockd when appropriate.

>> Do we wish to wipe the tails-* part from files names? Replace it with
>> "wiperam-*"? I think it would be a good idea.


> Yes.


Being done.

>> = lintian etc/init.d/kexec-load =


>> W: wiperam: init.d-script-not-marked-as-conffile etc/init.d/kexec-load
>> E: wiperam: init.d-script-not-included-in-package etc/init.d/kexec-load


>> I think we should override them, because we're shipping an insserv
>> override. (It complains because we're using update-rc.d in maintainer
>> scripts, so the insserv override gets activated.) Alternatively, we
>> could also ship the forked /etc/init.d/kexec-load and displace it using
>> config-package-dev.


> Will look at it tomorrow.


Converted to etc/insserv/overrides/kexec-load, so now irrelevant.

>> = litian warning missing man page =


>> Let's move files in /usr/bin/* to /usr/lib/wiperam/*, since these are
>> not useful to users anyway?


> Yes.


Done.

>> = litian warning init.d-script-possible-missing-stop =


>> You tell me. Want a lintian override? Lintian override reason?


> Will look at it tomorrow.


We've added a few overrides, and also added a few "status" options for
some initscripts.

>> = litian warning init.d-script-missing-dependency-on-remote_fs =


>> E: wiperam: init.d-script-missing-dependency-on-remote_fs
>> etc/init.d/tails-reconfigure-kexec: required-start
>> E: wiperam: init.d-script-missing-dependency-on-remote_fs
>> etc/init.d/tails-reconfigure-memlockd: required-start


>> You probably don't want to add remote_fs as dependency. Should I add a
>> lintian override? Lintian override reason?


> I'm unsure, will look at it tomorrow.


Added $remote_fs dependency. Any reason why we should not have?

>> = kexec, memlockd init scripts =


>> The old packaging used:


>> PATCHED_INITSCRIPTS="
>> kexec
>> memlockd
>> "


>> insserv -r $PATCHED_INITSCRIPTS
>> insserv $PATCHED_INITSCRIPTS $CUSTOM_INITSCRIPTS


>> I don't understand why running update-rc.d on kexec or memlockd's init
>> script would be required - their init scripts were not modified.
>> /etc/init.d/kexec is not modified at all and only /etc/memlockd.cfg gets
>> displaced, but that should not require running "update-rc.d
>> /etc/init.d/memlockd defaults". Therefore, those init scripts remain
>> untouched. If I am wrong here, we can do this.


> Tails modifies these two initscripts:
> config/chroot_local-patches/disable_kexec_initscript.diff
> config/chroot_local-patches/keep_memlockd_on_shutdown.diff


We'll port these to insserv overrides too.

>>> * standard git-buildpackage repo layout


>> I don't understand git-buildpackage and couldn't make friends with it
>> yet. If you wish, I can solve some more packaging issues raised above
>> and, would be happy if my work turns out as being useful and wouldn't
>> mind if you take over from there. Also I wouldn't mind if you forked the
>> package / wanted git write access and/or quickly fixed the
>> debian/control 'Maintainer:' to your name and so forth.


> I'll migrate the package to gbp, and we'll see who commits to maintain
> it on the long term.


To be done.

Cheers,
--
intrigeri