Your message dated Thu, 5 Jul 2012 11:33:10 +0200
with message-id <[email protected]>
and subject line Re: Bug#680157: unblock: gcpegg/5.1-13
has caused the Debian Bug report #680157,
regarding unblock: gcpegg/5.1-13
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 [email protected]
immediately.)
--
680157: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680157
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: [email protected]
Usertags: unblock
Please unblock package gcpegg. This version fixes RC bug #680014 which
affects all 64-bit architectures. It also fixes an unreported path bug
in the init.d script that would affect all users.
This is *not* an absolutely minimal diff to fix those bugs from -12, but
the package is better in all respects, -13 has received significant testing,
and it's a "leaf package" that nothing else depends on... so I really think
5.1-13 is the version that should be in wheezy.
Thanks!
Bdale
unblock gcpegg/5.1-13
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: i386 (x86_64)
Kernel: Linux 3.4.4-64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
On Wed, Jul 4, 2012 at 22:22:03 -0600, Bdale Garbee wrote:
> Julien Cristau <[email protected]> writes:
>
> > shouldn't the opts->port argument have been dropped? same in
> > reg_pear.c, hw_pear.c.
>
> Good point. But, while it's no long used, it shouldn't hurt anything,
> and in testing it all works fine... so I'm inclined to leave it alone
> for now.
>
> > funky indent... (and in a bunch of other places)
>
> Yes.
>
> > The hardcoding of vt 8 in the init script feels wrong as well, but I
> > guess that's not a regression. (It's going to clash with a display
> > manager that starts before it or in parallel.)
>
> Indeed. The package has been set up this way for years. This code is
> only likely to be installed on a server with a stable network
> configuration that's hosting one of the special hardware random number
> generators used by the project, and they don't tend to have displays, so
> in practice this isn't much of a problem.
>
> There's an option to build the program without the UI enabled, but I've
> never tried it, and that feels like a bigger change more suited for the
> next stable release cycle.
>
Unblocked.
Cheers,
Julien
signature.asc
Description: Digital signature
--- End Message ---
