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

このメッセージを削除

このメッセージに返信
著者: Patrick Schleizer
日付:  
To: The Tails public development discussion list, freepto
題目: Re: [Tails-dev] Sharing wiperam package between Freepto and Tails?
Hi!

= news =

Did some work on this... Link:
https://github.com/adrelanos/wiperamFreepto

Package builds fine. ./build script produces deterministic
wiperam_0.1.orig.tar.gz, wiperam_0.1-1_all.deb and
wiperam_0.1-1.debian.tar.gz.

Package installation and actual functionality untested.

= copyright =

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+

On what files Freepto does claim copyright?

For my own copyright, I plan on being relaxed. For now, GPLv3+ as well,
but for this minor thing also something more lax could be used. Nevermind.

= source folder name =

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

= git url =

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

= kexec-load =

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

= tails-* filenames =

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

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

= litian warning missing man page =

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

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

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

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

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

= answer =

intrigeri:
> This would be terrific. I've planned to work a bit on it with
> ono-sendai around June 27-29. Do you think you can get the package in
> a better shape before?


Yes.

> Suggestions:
>
>   * switch to non-native package, to ease maintaining the delta
>     Freepto, Tails, Whonix and others might have to insert


Done?

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

> 3.0 (quilt) source format


Done?

> * Lintian is your friend


:) Answered above.

Cheers,
Patrick