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

Delete this message

Reply to this message
Author: intrigeri
Date:  
To: The Tails public development discussion list
CC: freepto
Subject: Re: [Tails-dev] Sharing wiperam package between Freepto and Tails?
Hi,

(I'm sorry for the late reply.)

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 :)

> Can you tell me please who claims copyright on what file, so I can
> finish debian/copyright?


> I guess most files copyright is


>    (C) Amnesia <amnesia at boum dot org>
>    License: GPL-3+


Yes, they're taken from Tails source code, so this applies.

> On what files Freepto does claim copyright?


Ping?

> = 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.

> I appreciated, if we could name the repository
> https://github.com/AvANa-BBS/wiperam instead of
> https://github.com/AvANa-BBS/wiperamFreepto.


I don't see why this would be relevant. If Freepto needs some minor
tweaks to adapt the thing to their environment, it's totally fine with
me that they maintain their own Git repo of wiperam, and call it any
way they want.

> 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.

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


Yes.

> = 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.

> = 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.

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


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


Will look at it tomorrow.

> = 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.

> = 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

>> * 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.

Cheers,
--
intrigeri