Your message dated Tue, 08 Aug 2017 11:03:51 +0000 with message-id <e1df2ih-0008uo...@fasolo.debian.org> and subject line Bug#852582: fixed in bit-babbler 0.7 has caused the Debian Bug report #852582, regarding bit-babbler: Update udevadm path 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 ow...@bugs.debian.org immediately.) -- 852582: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852582 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: bit-babbler Version: 0.6 Severity: normal User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: udevadm Hi, since Jessie, the udevadm binary is available as /bin/udevadm. To not break existing scripts, which use the old /sbin/udevadm path, the udev package currently ships a compat symlink which we would like to drop eventually (in buster or buster+1). According to codesearch [1] your package bit-babbler does hard-code the udevadm path as /sbin/udevadm. Please change that to /bin/udevadm. Thanks for considering. Michael, on behalf of the pkg-systemd team. [1] https://codesearch.debian.net/search?q=%2Fsbin%2Fudevadm
--- End Message ---
--- Begin Message ---Source: bit-babbler Source-Version: 0.7 We believe that the bug you reported is fixed in the latest version of bit-babbler, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 852...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Ron Lee <r...@debian.org> (supplier of updated bit-babbler package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Format: 1.8 Date: Mon, 19 Jun 2017 13:31:17 +0930 Source: bit-babbler Binary: bit-babbler bit-babbler-dbg Architecture: source amd64 Version: 0.7 Distribution: unstable Urgency: medium Maintainer: Ron Lee <r...@debian.org> Changed-By: Ron Lee <r...@debian.org> Description: bit-babbler - BitBabbler hardware TRNG and kernel entropy source support bit-babbler-dbg - debugging symbols for BitBabbler tools Closes: 852582 Changes: bit-babbler (0.7) unstable; urgency=medium . * Handle the oddball case of a RHEL/CentOS 6 kernel being used with libusb version 1.0.13 or later. They backported the USBDEVFS_GET_CAPABILITIES API, but not the patch which was applied to the mainline kernel at the same time to add USBDEVFS_CAP_BULK_SCATTER_GATHER. With the default libusb 1.0.9 that it normally ships with this doesn't matter because none of it is supported there anyway, but updating it makes this become a real problem that we need to deal with. . * Test for SIGRTMIN, MacOSX doesn't have it. . * Test for pthread_setname_np by signature, it's implemented differently on different platforms. Also support pthread_set_name_np which is what is used by OpenBSD and FreeBSD. . * Explicitly set the pthread stack size on (more) platforms where it is tiny by default. We do create some large structures on the stack, and it's probably better to have a consistent size on all platforms than have some of them smash it "unexpectedly". . * Querying the string length with strftime is a GNU extension, so only use that where it's actually available. . * Provide an implementation of FeedKernelEntropy for MacOS. It does have a documented interface for that, even if the implementation of it that is in its kernel source as of Sierra is ... let's go with enlightening. . * Rename _P(), our convenience alias to ngettext, to P_(). On OpenBSD 6.1 _P is defined in ctype.h, and regardless of what you might think of that, symbols starting with an underscore are reserved. So they win this one. . * Test for LOG_MAKEPRI, it isn't required by POSIX, and OpenBSD 6.1 doesn't provide it. . * Add explicit tests for strtod_l and newlocale. The newlocale function is specified by POSIX, but OpenBSD doesn't provide it. We can get away with falling back to strtod there because it only has very limited support for locales anyway, and right now it will always be either C or en_US.UTF8, both of which use '.' as the decimal point. . * Support systems without abi::__forced_unwind for thread cancellation stack unwinding and clean up. The GCC toolchain on OpenBSD doesn't support it, and neither does clang on FreeBSD or MacOS. . * Disable thread cancellation around calls to vfprintf on OpenBSD. On that platform it is a cancellation point (as expected), but if cancellation does occur there on 6.1, it can leave its internal _thread_flockfile mutex locked which means any future calls to vfprintf (or anything else needing that lock) will deadlock. We can't easily test for that bug, so we just always provide our own safe cancellation point instead on that platform. . * Support unordered_map in both std and std::tr1 namespaces. Normally it isn't available in std:: unless C++11 support is enabled, but clang on FreeBSD provides the tr1 header as a symlink to the std one, and only provides the template in the std namespace. . * Test for libusb_has_capability. FreeBSD 11 bumped LIBUSB_API_VERSION to 0x01000102, but didn't add the libusb_has_capability() function which was part of that interface version. It did however add the hotplug API, and it does mostly work, so if the API version is sufficient, but we can't test for this capability, then we'll assume it's available and that it will handle a call to it gracefully if for some reason it really isn't. . * Deal with FreeBSD 11 libusb start up and shut down delays. In our testing there was a delay of around 4 seconds before it would report any existing devices when LIBUSB_HOTPLUG_ENUMERATE was used with the hotplug callback (and a similar delay when new devices really were hotplugged later). That makes things awkward for the --scan option, which would see no devices at all before returning its results, unless it too had an arbitrary (and user unfriendly long) delay before responding. So we explicitly enumerate the initial set ourselves on FreeBSD now even when hotplug support is enabled, and handle any duplicates when the hotplug events finally do arrive. . Likewise, when libusb_exit is called, it also blocks for around 4 seconds before returning - which delays our code from being able to do a clean exit quickly. There's not much we can do about that one except add some extra debug logging when verbosity is turned up, so that users can see it is not actually our code that has them twiddling their thumbs waiting. Hopefully later releases of FreeBSD will improve on this. . * Work around FreeBSD 11 deadlocking on device unplug. If a device is ever removed while we are in the middle of a call to libusb_bulk_transfer(), then that call may deadlock and never return, and the thread which called it will not be able to be cancelled. We can limit the impact that has on our code (since we will already always be cancelling that thread once we get the hotplug notification of the removal) by using pthread_timedjoin_np and if the join times out, bark about it and just ignore the zombie thread that we've been left with. It's not ideal, and if it happens often enough in a single process run, then leaked resources will start to be exhausted. But most people don't replug things all that frequently, this won't happen every time they do, and it is about the best we can do until the FreeBSD bug is fixed. There's no downside to the workaround if the bug doesn't actually occur when a device is unplugged. . * Disable some buggy optimisations (normally enabled by -O2) when using GCC on FreeBSD 11. On that platform (we've not seen this anywhere else), they appear to miscompile some code in a way that stack unwinding details are lost and a thrown exception will invoke terminate rather than being caught by the handler it should have unwound to. Some of these were in obscure corners of the code that are only seen when unlikely errors occur, so it's not impossible that there may be a few more lurking. But for now, we'll just disable the known problem ones rather than falling all the way back to compiling with -O0 on that platform. . * Add a --limit-max-xfer option to seedd and bbcheck. This gives people a runtime workaround for systems where, despite having an ostensibly new enough Linux kernel and libusb version to support large bulk URBs, the hardware chipset has some quirk that isn't yet fixed in the kernel driver which makes using them troublesome (I'm looking at you RPI3). If passed, this will force the old 16kB limit on individual requests to usbfs. That doesn't have any effect on the size of requests that users can make from our code, it just might be slightly slower at obtaining huge numbers of bits, since we need to get them in smaller chunks internally. . * Add an example of how to obtain random integers within an arbitrary range where every value in that range remains equally probable. This isn't a difficult thing to do, but enough people have asked to provide a working example, and there's enough history elsewhere of people doing something naive, like using a modulus to limit the range (thus making some values more probable than others), to have a good example easily available that users can refer to. . * Search for where udevadm is found in the qemu-hook script. Its installed path was changed by systemd 204 in Jessie from /sbin to /bin, so now we need to deal with multiple interfaces to stay portable, since there are supported distro releases that aren't EOL yet which still have it in the old location. Jessie's systemd had a compat link to make it available in both places, but the systemd maintainers want to drop that for Buster (and not all other distros with newer systemd provide that). Closes: #852582 . * Tweak the udev rules to work around a bug in udev versions up to at least 232-25 which makes testing ATTR keys with != become a perilous folly. If an event occurs for a device which does not have that attribute at all, then the rule will be skipped, the same as if it was actually equal to the value being tested for. Checksums-Sha1: 31bec571393f5e6d6654c38b540a98359d386d7a 1514 bit-babbler_0.7.dsc 64197b08cfdedf6af73802b54602b87ac0017022 350395 bit-babbler_0.7.tar.gz 8510760b1d16146b4d4943e74d5b3b13e9b3f4ad 1007996 bit-babbler-dbg_0.7_amd64.deb d49cedf5d42235eab32066637e72760cd3efa8ec 5471 bit-babbler_0.7_amd64.buildinfo 879bf5481bb2c7159ca2161fae48afa92035c9c5 235010 bit-babbler_0.7_amd64.deb Checksums-Sha256: bc922f00a09e761f920e93dc3bdc648981ea633c9f086e8b5493763c364a4dfa 1514 bit-babbler_0.7.dsc f6527def241904d45265161be463b133a87eca2624473530ecd258dec3256be9 350395 bit-babbler_0.7.tar.gz 5fe622ff8a5e9f48708b676fb79dcd6fff94ef7ff29f37d5564924b3554cc6cb 1007996 bit-babbler-dbg_0.7_amd64.deb 3705089f4070b3a92fac954b0b7b0164bababfa7bfa8a9650dc88e06cafe8c40 5471 bit-babbler_0.7_amd64.buildinfo cab6ab5ef678d3a021db5884b6cadfa24cf7d6ea061b450d360ec3b111f1d2f6 235010 bit-babbler_0.7_amd64.deb Files: ddd723fc7a9365c28990d7bafa86a901 1514 admin optional bit-babbler_0.7.dsc 3321be32fc2b1628638d906bdc74e0e7 350395 admin optional bit-babbler_0.7.tar.gz dc014fb68f0ea6aee44ad586017253fc 1007996 debug extra bit-babbler-dbg_0.7_amd64.deb 1476af731a70990b75e9368cb4e3206d 5471 admin optional bit-babbler_0.7_amd64.buildinfo 37ddf2bdf093eb14c468b7960950acfe 235010 admin optional bit-babbler_0.7_amd64.deb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJZiZfpAAoJECSWn9pgwHEswt8QAJQ48S2d46C80CuA40XuEtFX GtDf/9uEksZRAUQfoWEIrmn9FbrUdGc93Lnm7uYnOcYunwFmvA9lLXIOJpqdIwsR tC9c50aC3rtxk994yPRXeoZa9yDnbmH1KrQow6kP/RJvxIzDuNf3uRpU/rSCm9yC lDMBPNQCQpKQs0jbDQz3fOvxNMHRm30f+dTz5FA9NzS4io8HpF1C8ydLA1XbSorE FAM3dH/GA2N3WgW2oP3IqFwB/HmTL0aLpwgK/8a961EavcXO9c3yyUuQL9XST/HE x2vEliIv6hofe9NFwaianX5OW1a8PnnkqK2F5BBnAFgRSVrhtPWTQRm2xX5G4s/2 YJS/xR92WXT/+LenPNgfkYh7UxWNjrHhDuAD9/9WsGInJK8ssn1Fn+Vb7G9zl+ry 6THlqOxs87w+1gooTGne9RgxezDe4pp4A/zPyT338y5GJ5/GauZq/Qk7vVh6UEaU KIMM0/q+Log6VbP/keMoZxe7I7loClMalg9EVi49gZ6ud5eJM8ZgeqjNYSv3QI/B wvRnC+sqU58cmHmVLacnIRBD/AuyTN2knymdq0FKy2vT0lhkyiH5Fd5IXULxpE8n IOQHMYPTdsoQrMc8Cfv03NBUpJpUHq+OExGlfF3gp1C+tIYcYx4ISHRToUFEc4Sf 8A0VS2sVfJyw5ODpY7Qb =LmQ/ -----END PGP SIGNATURE-----
--- End Message ---
