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 _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.