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
