Discussion:
Bug#988083: unblock: micro-evtd/3.4-6
Add Reply
Ryan Tandy
2021-05-05 05:40:01 UTC
Reply
Permalink
Package: release.debian.org
Severity: normal
User: ***@packages.debian.org
Usertags: unblock

Please unblock package micro-evtd

[ Reason ]

One-line patch to fix FTBFS (#987631). Also taking the opportunity to
update the Maintainer field; I hope that's OK.

[ Impact ]

The package currently in bullseye (same as buster) works, however it
FTBFS with bullseye's glibc.

[ Tests ]

There are no automated tests. I have been running the updated daemon for
a few days, and I tested an installation with the updated udeb (using a
d-i daily image).

[ Risks ]

I built the package on buster with and without the patch, to see what
would change. The disassembly (objdump -d) was the same before and
after, so I think I can be confident the header was not actually used
and the patch should not change its behaviour.

However, the package had not been rebuilt since before buster was
released, so there could be unknown risks arising from rebuilding with
the newer toolchain.

[ Checklist ]

[✔] all changes are documented in the d/changelog
[✔] I reviewed all changes and I approve them
[✔] attach debdiff against the package in testing

[ Other info ]

Very low popcon. The package provides hardware support for a specific
subset of armel/orion5x NAS devices with few remaining users.

The package builds a udeb. I tested an installation using a daily d-i
image that includes the update.

unblock micro-evtd/3.4-6

thanks,
Ryan
Ryan Tandy
2021-05-06 05:40:01 UTC
Reply
Permalink
I'm sorry, I belatedly noticed another issue with micro-evtd.

#988119: the daemon creates its pid and status files with mode 666,
start-stop-daemon doesn't like that and refuses to stop the daemon.

I don't know what the appropriate severity is for that one. If it's RC I
can make another upload to fix it.

Sorry for the noise.
Paul Gevers
2021-05-19 20:00:02 UTC
Reply
Permalink
Control: tags -1 moreinfo

Hi Ryan,
Post by Ryan Tandy
#988119: the daemon creates its pid and status files with mode 666,
start-stop-daemon doesn't like that and refuses to stop the daemon.
I don't know what the appropriate severity is for that one. If it's RC I
can make another upload to fix it.
I suggest a new upload to fix that issue. But if it's no regression,
maybe we can have the current version migrate first.

Paul
Roger Shimizu
2021-05-21 16:40:01 UTC
Reply
Permalink
control: tags -1 -moreinfo
Post by Paul Gevers
Control: tags -1 moreinfo
Hi Ryan,
Post by Ryan Tandy
#988119: the daemon creates its pid and status files with mode 666,
start-stop-daemon doesn't like that and refuses to stop the daemon.
I don't know what the appropriate severity is for that one. If it's RC I
can make another upload to fix it.
I suggest a new upload to fix that issue. But if it's no regression,
maybe we can have the current version migrate first.
Yes, #988119 is not a regression issue.
I think it's better to let current version migrate first.
Current version doesn't have any feature change, so it's quite safe.

For #988119 I need some time to fix, and test to confirm it's safe to
deliver to bullseye.
Thanks for your understanding!

Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
Emilio Pozuelo Monfort
2021-05-07 09:10:02 UTC
Reply
Permalink
Post by Ryan Tandy
Package: release.debian.org
Severity: normal
Usertags: unblock
Please unblock package micro-evtd
[ Reason ]
One-line patch to fix FTBFS (#987631). Also taking the opportunity to update the
Maintainer field; I hope that's OK.
[ Impact ]
The package currently in bullseye (same as buster) works, however it FTBFS with
bullseye's glibc.
[ Tests ]
There are no automated tests. I have been running the updated daemon for a few
days, and I tested an installation with the updated udeb (using a d-i daily image).
[ Risks ]
I built the package on buster with and without the patch, to see what would
change. The disassembly (objdump -d) was the same before and after, so I think I
can be confident the header was not actually used and the patch should not
change its behaviour.
However, the package had not been rebuilt since before buster was released, so
there could be unknown risks arising from rebuilding with the newer toolchain.
[ Checklist ]
 [✔] all changes are documented in the d/changelog
 [✔] I reviewed all changes and I approve them
 [✔] attach debdiff against the package in testing
[ Other info ]
Very low popcon. The package provides hardware support for a specific subset of
armel/orion5x NAS devices with few remaining users.
The package builds a udeb. I tested an installation using a daily d-i image that
includes the update.
Cyril, can you (n)ack for d-i?

Thanks,
Emilio
Cyril Brulebois
2021-05-08 22:40:01 UTC
Reply
Permalink
Hi,
Post by Emilio Pozuelo Monfort
Post by Ryan Tandy
[ Tests ]
There are no automated tests. I have been running the updated daemon for
a few days, and I tested an installation with the updated udeb (using a
d-i daily image).
I'm very happy to see this was not only build- but also run-tested.
Post by Emilio Pozuelo Monfort
Post by Ryan Tandy
[ Risks ]
I built the package on buster with and without the patch, to see
what would change. The disassembly (objdump -d) was the same before
and after, so I think I can be confident the header was not actually
used and the patch should not change its behaviour.
However, the package had not been rebuilt since before buster was
released, so there could be unknown risks arising from rebuilding
with the newer toolchain.
[ Checklist ]
 [✔] all changes are documented in the d/changelog
 [✔] I reviewed all changes and I approve them
 [✔] attach debdiff against the package in testing
[ Other info ]
Very low popcon. The package provides hardware support for a specific
subset of armel/orion5x NAS devices with few remaining users.
The package builds a udeb. I tested an installation using a daily d-i
image that includes the update.
Cyril, can you (n)ack for d-i?
Since it seems to be a package that targets specific hardware, and since
tests have been carried out on at least one such device, this looks very
fine to me.


Cheers,
--
Cyril Brulebois (***@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Debian Bug Tracking System
2021-05-19 20:00:01 UTC
Reply
Permalink
tags -1 moreinfo
Bug #988083 [release.debian.org] unblock: micro-evtd/3.4-6
Added tag(s) moreinfo.
--
988083: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988083
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems
Debian Bug Tracking System
2021-05-21 16:40:01 UTC
Reply
Permalink
Post by Roger Shimizu
tags -1 -moreinfo
Bug #988083 [release.debian.org] unblock: micro-evtd/3.4-6
Removed tag(s) moreinfo.
--
988083: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988083
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems
Debian Bug Tracking System
2021-05-21 19:00:01 UTC
Reply
Permalink
Your message dated Fri, 21 May 2021 20:47:50 +0200
with message-id <030388b1-b50c-5349-ba6e-***@debian.org>
and subject line Re: Bug#988083: unblock: micro-evtd/3.4-6
has caused the Debian Bug report #988083,
regarding unblock: micro-evtd/3.4-6
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ***@bugs.debian.org
immediately.)
--
988083: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988083
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems
Loading...