Hi, [email protected] wrote (25 Mar 2013 12:00:11 GMT) : > Right. The shortest way to test bilibop in Tails context is the following: > 1. Boot on Tails 0.17.1 (with or without the fromiso=... variant), and set > up a password for the user account
> 2. Get bilibop-common and bilibop-udev packages: > - build them from the source (https://mentors.debian.net/packages/bilibop/) > - download them (https://un.poivron.org/~quidame/debian/pool/main/b/bilibop/) > - or see the attachments. > and install them on the system, or extract and copy only the needed files: > /lib/bilibop/common.sh > /lib/bilibop/disk > /lib/bilibop/test > /lib/udev/rules.d/66-bilibop.rules > 3. To finish: > # invoke-rc.d udev restart > # DISK=$(/lib/bilibop/disk) > # udevadm trigger --sysname-match=${DISK##*/}* These steps did work for me on Tails 0.17.2 installed on a USB stick with the Tails USB installer, using bilibop-udev 0.4.10~quidame. Yeah :) However, shouldn't bilibop-udev.postinst run `invoke-rc.d udev reload'? Just installing the package, despite the udevadm trigger in this postinst maintainer script, was not enough to have the permissions changed, and indeed the udev restart + trigger was needed. Anyway, this is mostly irrelevant for Tails, since all we need is the udev rule to do its job at boot time, and this postinst script fails for us anyway, as reported in my previous email. Actually, I'm starting to think this postinst should just not exist at all: as currently implemented, it breaks support for the standard Debian Live system (built with live-build) usecase, without bringing support for the "install bilibop-udev at runtime" usecase as apparently intended, so I fail to see what good this script makes. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
