Bug#934945: startpar: insserv attemps to write to /etc/.boot.* even with -p option

2019-08-17 Thread Jesse Smith
On 8/17/19 3:29 PM, Ian Jackson wrote:
> Jesse Smith writes ("Bug#934945: startpar: insserv attemps to write to 
> /etc/.boot.* even with -p option"):
>> The change has been made upstream so this should be fixed when the next
>> version comes out, probably around the end of September. That would save
>> the trouble of patching the test script.
> For Debian, this test failure is regarded as an RC bug.  So we need to
> fix it there ASAP, by forward porting the commit.  (A simple git
> cherry pick I assume.  Plus the test dependency change if we need it,
> of course, but we need to keep that.
>
Attached is the patch to correct the bug. That can be used until
startpar-0.64 is published.

diff --git a/testsuite/runtests b/testsuite/runtests
index 5776c78..1204592 100755
--- a/testsuite/runtests
+++ b/testsuite/runtests
@@ -14,7 +14,7 @@ touch etc/insserv.conf
 cp testscript etc/init.d/test
 chmod a+rx etc/init.d/test
 
-"$INSSERV" -p etc/init.d test
+"$INSSERV" -p etc/init.d -i etc/init.d test
 if $STARTPAR -d etc/init.d -e etc -P S -R 2 -M start 2>&1 | grep -q 'is 
running' ; then
 echo Test 1 success: the test script in init.d was running
 else


Bug#934945: startpar: insserv attemps to write to /etc/.boot.* even with -p option

2019-08-17 Thread Ian Jackson
Jesse Smith writes ("Bug#934945: startpar: insserv attemps to write to 
/etc/.boot.* even with -p option"):
> The change has been made upstream so this should be fixed when the next
> version comes out, probably around the end of September. That would save
> the trouble of patching the test script.

For Debian, this test failure is regarded as an RC bug.  So we need to
fix it there ASAP, by forward porting the commit.  (A simple git
cherry pick I assume.  Plus the test dependency change if we need it,
of course, but we need to keep that.

Ian.


-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Bug#934945: startpar: insserv attemps to write to /etc/.boot.* even with -p option

2019-08-17 Thread Jesse Smith
On 8/17/19 2:14 PM, Ian Jackson wrote:

> Jesse Smith writes ("Bug#934945: startpar: insserv attemps to write to 
> /etc/.boot.* even with -p option"):
>> On a related note, in the startpar build log it shows the version of
>> startpar being tested is located at /lib/startpar/startpar. Upstream
>> we use the startpar executable in the local directory to make sure
>> we are using the fresh copy and not the system copy. It looks like
>> maybe Startpar is being installed before the test is run? In which
>> case it works out to be the same thing.
> Debian's CI at ci.debian.net wants to test *packages*, in the context
> of the whole system, so it tests everything as-installed.  So this
> seems correct.

Sounds good.

>> This is a pretty minor change, in the Startpar "testsuite/runtests" script
>> change the line which reads:
>>
>> $INSSERV" -p etc/init.d test
>>
>> to
>>
>> $INSSERV" -p etc/init.d -i etc/init.d test
> It sounds like we should make this change to the test suite, and also
> add a test dependency saying we need at least whatever insserv gained
> the -i option ?

The change has been made upstream so this should be fixed when the next
version comes out, probably around the end of September. That would save
the trouble of patching the test script.

I'm not sure of the specific version where the behaviour change took
place, but any version of insserv >= 1.20.0 should be a good match for
startpar going forward.

- Jesse



Bug#934945: startpar: insserv attemps to write to /etc/.boot.* even with -p option

2019-08-17 Thread Ian Jackson
Jesse Smith writes ("Bug#934945: startpar: insserv attemps to write to 
/etc/.boot.* even with -p option"):
> On a related note, in the startpar build log it shows the version of
> startpar being tested is located at /lib/startpar/startpar. Upstream
> we use the startpar executable in the local directory to make sure
> we are using the fresh copy and not the system copy. It looks like
> maybe Startpar is being installed before the test is run? In which
> case it works out to be the same thing.

Debian's CI at ci.debian.net wants to test *packages*, in the context
of the whole system, so it tests everything as-installed.  So this
seems correct.

> This is a pretty minor change, in the Startpar "testsuite/runtests" script
> change the line which reads:
> 
> $INSSERV" -p etc/init.d test
> 
> to
> 
> $INSSERV" -p etc/init.d -i etc/init.d test

It sounds like we should make this change to the test suite, and also
add a test dependency saying we need at least whatever insserv gained
the -i option ?

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Bug#934945: startpar: insserv attemps to write to /etc/.boot.* even with -p option

2019-08-17 Thread Jesse Smith

> Folks, we have serious regression. Not sure, whether it is bug in
> startpar test suite, which invokes `insserv' with `-p', but without
> `-i', or it is regression in `insserv'.

It's sort of a fore-gression. The Startpar testsuite was set up to work
with older versions of insserv, like insserv-1.14.0. I've updated the
test script to work with insserv-1.20.0. This will be fixed in the next
version of Startpar.

This is a pretty minor change, in the Startpar "testsuite/runtests"
script change the line which reads:

$INSSERV" -p etc/init.d test

to

$INSSERV" -p etc/init.d -i etc/init.d test


On a related note, in the startpar build log it shows the version of
startpar being tested is located at /lib/startpar/startpar. Upstream we
use the startpar executable in the local directory to make sure we are
using the fresh copy and not the system copy. It looks like maybe
Startpar is being installed before the test is run? In which case it
works out to be the same thing.

- Jesse



Bug#934945: startpar: insserv attemps to write to /etc/.boot.* even with -p option

2019-08-16 Thread Dmitry Bogatov

Package: startpar
Affects: inserv
Version: 1.20.0-2
Severity: important
Tags: upstream help

Folks, we have serious regression. Not sure, whether it is bug in
startpar test suite, which invokes `insserv' with `-p', but without
`-i', or it is regression in `insserv'.

Either way, insserv does not migrate to testing, and it is very bad.

https://ci.debian.net/data/autopkgtest/testing/amd64/s/startpar/2743262/log.gz


pgpyDa9Gc_zgl.pgp
Description: PGP signature