Bug#412220: ruby1.8: reverse lookup doesn't work.
Package: ruby1.8
Version: 1.8.5-4
Severity: normal
ri Socket.gethostbyname implies that
ruby -rsocket -e 'p Socket.gethostbyname("127.0.0.1")'
should return something like:
["localhost", ["localloop", "loop", "loghost"], 2, "\177\000\000\001"]
as it does on a redhat machine I have access to using
ruby 1.8.2 (might be patched).
on my machine at least, it returns:
["127.0.0.1", [], 2, "\177\000\000\001"]
which is not what I'd like.
You can replace 127.0.0.1 with any address you like
(obviously, looking up localhost isn't important); I expect
that looking up localhost can be done without a connection
to the outside network so might fit in a regression test.
This used to work, but I haven't paid close attention to changes
recently, and the documentation I can find says this should work.
Also applies to a version of 1.9 ( 1.9.0+20060609-1 ) I have installed:
sr:~/src> ruby1.9 -rsocket -e 'p
Socket.gethostbyname("127.0.0.1")'
["127.0.0.1", [], 2, "\177\000\000\001"]
sr:~/src> ruby1.9 --version
ruby 1.9.0 (2006-06-08) [i486-linux]
sr:~/src> ruby1.6 -rsocket -e 'p
Socket.gethostbyname("127.0.0.1")'
["localhost.localdomain", ["localhost"], 2, "\177\000\000\001"]
In the meantime, I guess I'll use resolv.
-neil
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.4.27-2-386
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages ruby1.8 depends on:
ii libc6 2.3.6.ds1-11 GNU C Library: Shared libraries
ii libruby1.8 1.8.5-4 Libraries necessary to run Ruby 1.
ruby1.8 recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#666980: zoneminder: hash authentication broken in update
Package: zoneminder
Version: 1.25.0-1
Severity: normal
Dear Maintainer,
I upgraded from 1.24.2 recently, and streaming (live and
recorded) failed with errors in the log:
socket_sendto( /tmp/zms-562793s.sock ) failed: No such file or directory
I tracked this down to a socket that should
have been created by nph-zms, then ran this cgi
program under the shell with the arguments from
/var/log/apache/access.log. It didn't work,
and printed an error about authentication. I added
user=&pass= to the arguments, and the
nph-zms program streamed jpeg data.
I then reconfigured zoneminder to use "plain" instead of
"hashed" under AUTH_RELAY. That "fixed" the glitch, but
now the username and password information is included in
pages, and that seems dangerous to me.
I tried rebuilding from source, and noticed that the
configure script prints the following warnings; perhaps
they are part of the problem.
checking for gcrypt.h... yes
checking for gcry_check_version in -lgcrypt... no
configure: WARNING: libgcrypt.a is required for authenticated streaming - use
ZM_SSL_LIB option to select openssl instead
checking for MD5 in -lgnutls-openssl... no
configure: WARNING: gnutls-openssl.a is required for authenticated streaming -
use ZM_SSL_LIB option to select openssl instead
I was able to use this configuration option in the previous
version, as confirmed to me by apache access logs.
Thanks,
-neil
-- System Information:
Debian Release: wheezy/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.1.0-1-amd64 (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
Versions of packages zoneminder depends on:
ii apache2 2.2.22-2
ii apache2-mpm-prefork [apache2] 2.2.22-2
ii ffmpeg 5:0.7.11-0.2
ii javascript-common 7
ii libapache2-mod-php5 5.4.0-3
ii libarchive-tar-perl
ii libarchive-zip-perl 1.30-6
ii libavcodec534:0.8.1-1
ii libavdevice53 4:0.8.1-1
ii libavformat53 4:0.8.1-1
ii libavutil51 4:0.8.1-1
ii libbz2-1.0 1.0.6-1
ii libc6 2.13-27
ii libdate-manip-perl 6.31-1
ii libdevice-serialport-perl 1.04-2+b3
ii libgcc1 1:4.6.3-1
ii libgcrypt11 1.5.0-3
ii libgnutls-openssl27 2.12.18-1
ii libjpeg88d-1
ii libjs-mootools 1.4.5~debian1-1
ii libmime-lite-perl 3.028-1
ii libmime-tools-perl 5.502-1
ii libmysqlclient165.1.61-2
ii libpcre38.12-4
ii libphp-serialization-perl 0.34-1
ii libstdc++6 4.6.3-1
ii libswscale2 4:0.8.1-1
ii libsys-mmap-perl0.16-1+b1
ii libwww-perl 5.836-1
ii mysql-client-5.1 [mysql-client] 5.1.61-2
ii mysql-server5.1.61-2
ii mysql-server-5.1 [mysql-server] 5.1.61-2
ii perl5.14.2-9
ii perl-modules [libmodule-load-perl] 5.14.2-9
ii php55.4.0-3
ii php5-mysql 5.4.0-3
ii rsyslog [system-log-daemon] 5.8.9-1
ii zip 3.0-4
ii zlib1g 1:1.2.6.dfsg-2
zoneminder recommends no packages.
zoneminder suggests no packages.
-- Configuration Files:
/etc/init.d/zoneminder changed:
prog=ZoneMinder
ZM_PATH_BIN="/usr/bin"
ZM_DBG_LEVEL_zmc="-12"
export ZM_DBG_LEVEL_zmc
command="$ZM_PATH_BIN/zmpkg.pl"
start() {
echo -n "Starting $prog: "
# not needed (ns): zmfix -a
$command start
RETVAL=$?
[ $RETVAL = 0 ] && echo success
[ $RETVAL != 0 ] && echo failure
echo
[ $RETVAL = 0 ] && touch /var/lock/zm
return $RETVAL
}
stop() {
echo -n "Stopping $prog: "
#
# Why is this status check being done?
# as $command stop returns 1 if zoneminder
# is stopped, which will result in
# this returning 1, which will stuff
# dpkg when it tries to stop zoneminder before
# uninstalling . . .
#
result=`$command status`
if [ ! "$result" = "running" ]; then
echo "Zoneminder already stopped"
echo
RETVAL=0
else
$command stop
RETVAL=$?
[ $RETVAL = 0 ] && echo success
[ $RETVAL != 0 ] && echo failure
echo
[ $RETVAL = 0 ] && rm -f /var/lock/zm
fi
}
status() {
Bug#858529: libc6: fgets repeats content after fork on stretch only
Package: libc6
Version: 2.24-9
Severity: normal
Dear Maintainers,
I'm testing a programming exercise for students, and found failed tests
that I believe are due to libc6. I retried the minimal test case on
every machine I have access to, and found that only my two Debian Stretch
machines failed, then took a clean vagrant Jessie box, confirmed correct
behavior, updated to Stretch, and reproduced the error.
I expect the following code to print its input, once. Instead, it
prints lines two through four twice. (abcdbcd).
#include
#include
#include
#include
int main() {
char buf[255];
int ln=1;
int status;
FILE *f;
f = fopen("/tmp/fourlines", "w");
fprintf(f, "a\nb\nc\nd\n");
fclose(f);
f= fopen("/tmp/fourlines", "r");
printf("%d: %s", ln++, fgets(buf, 255, f));
if(fork() == 0) { exit(1); }
wait(&status);
if(fgets(buf, 255, f)) printf("%d: %s", ln++, buf);
if(fgets(buf, 255, f)) printf("%d: %s", ln++, buf);
if(fgets(buf, 255, f)) printf("%d: %s", ln++, buf);
if(fgets(buf, 255, f)) printf("%d: %s", ln++, buf);
if(fgets(buf, 255, f)) printf("%d: %s", ln++, buf);
if(fgets(buf, 255, f)) printf("%d: %s", ln++, buf);
exit(0);
}
Output on my two machines and vm with 2.24-9:
1: a
2: b
3: c
4: d
5: b
6: c
7: d
The behavior is consistent under the debugger; I don't see
anything obvious in the FILE structure, and notice that a
read occurs between the d and b (the end of input and when
what should be old data is back in).
I plan to look into slightly older libc6 versions to find the
regression, but that will take me some time.
This is sent from the virtual machine, to keep it as clean as
possible.
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libc6 depends on:
ii libgcc1 1:6.3.0-6
libc6 recommends no packages.
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.60
pn glibc-doc
ii libc-l10n 2.24-9
ii locales2.24-9
-- debconf information:
glibc/restart-failed:
glibc/kernel-too-old:
glibc/upgrade: true
glibc/restart-services:
glibc/disable-screensaver:
glibc/kernel-not-supported:
* libraries/restart-without-asking: true
Bug#858529: minimal update narrows to libc6.
I took a clean jessie install in vagrant (bento/debian-8.7), then rather than update everything to stretch, I apt-get install’ed only libc6 from stretch. Same result: four lines before the upgrade, seven lines, duplicating the last three, after. Happy to share Vagrantfile and output, though I expect your skills are stronger than mine. -neil
Bug#776886: This patch is necessary
I applied the first two changes (memmove and long->int) and doing so solved a segfault problem on my x86_64 system. They appear safe (memmove acts as memcpy except it handles overlap). Please apply the patch! -neil
Bug#466477: it's biting me; don't close, maybe reassign
I'm about to submit a documentation wishlist request (at least) on openldap because I've bloodied my forehead getting it to talk to directory.umd.edu. The following statement does not appear to be true: I don't think you even need to re-assign the bug to OpenLDAP, since it supports cipher priority strings now. Grepping the source suggests that it can speak some priority strings but not the real priority string required to talk to that server. (it calls gnutls_X_set_priority, but not gnutls_priority_set or gnutls_priority_init.) Is there a bit of code I'm missing? thanks, -neil -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#510346: new TLS_CIPHER_SUITE underdocumented
Package: libldap-2.4-2 Version: 2.4.11-1 Severity: normal Please feel free to retitle; I don't know if this is a documentation problem or a feature problem. I'm trying my absolute hardest to get libldap to talk ssl to ldaps://directory.umd.edu:636/ and haven't figured it out. I believe my inability to get it to work is just documentation, but it works in old ldap (2.3.30-5+etch1) presumably because openssl negotiates differently. The problem I'm trying to solve: % openssl s_client -connect directory.umd.edu:636 works. (and thus, old libldap works fine, because openssl can negotiate with the server.) % gnutls-cli-debug -p 636 directory.umd.edu works, and describes many features that the server doesn't support. e.g., TLS1.1 support. % gnutls-cli -p 636 directory.umd.edu fails; wireshark shows gnutls sending a TLS1.1 client hello and the server dropping the connection. % gnutls-cli --protocols SSL3.0 -p 636 directory.umd.edu works; oddly, TLS1.0 does not. With that knowledge, I can then: % gnutls-cli --priority 'NORMAL:\!VERS-TLS1.1:\!VERS-TLS1.0' -p 636 directory.umd.edu So I'm confident that even if there's a bug in gnutls ability to negotiate with this server, there should be a way for me to configure gnutls through ldap.conf. However, after putting that string into TLS_CIPHER_SUITE (without escaping the !'s) % ldapsearch -d 12 -H ldaps://directory.umd.edu/ uid=nspring ldap_build_search_req ATTRS: supportedSASLMechanisms TLS: could not set cipher list NORMAL:!VERS-TLS1.1:!VERS-TLS1.0. ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) So that doesn't work; I then try setting TLS_CIPHER_SUITE to TLS_DHE_RSA_3DES_EDE_CBC_SHA1 , which has alongside it in gnutls-cli --list the note SSL3.0; unfortunately, the client still sends a TLS1.1 client hello message that the server does not care for. What the heck am I doing wrong? I'm certain that ldap.conf(5) must be updated in Debian to no longer say: TLS_CIPHER_SUITE Specifies acceptable cipher suite and preference order. should be a cipher specification for OpenSSL, e.g., HIGH:MEDIUM:+SSLv2. It would be cool if README.Debian had a small note about this relatively debian-specific configuration. (which I'm in favor of, don't get me wrong; that's just where I look for help when I know there's a Debian-ism to deal with.) After writing this up, I found #466477, which describes a configuration TLSCipherSuite, which seems to be part of slapd.conf, which I don't think I have, and asserts that openldap "supports cipher priority strings", which it doesn't appear to. I checked upstream 2.4.13; it doesn't appear to have anything better. Listing the ciphers to support is not sufficient to get gnutls to talk to servers like this one. Thanks for your hard work. I'd be happy to test a pre-release if there's a patch for passing a priority string to the gnutls library. I could try to write one, or better yet test one out, but I don't know that I understand the problem enough to know someone else doesn't have a different plan. thanks, -neil -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libldap-2.4-2 depends on: ii libc62.7-16 GNU C Library: Shared libraries ii libgnutls26 2.4.2-4 the GNU TLS library - runtime libr ii libsasl2-2 2.1.22.dfsg1-23 Cyrus SASL - authentication abstra libldap-2.4-2 recommends no packages. libldap-2.4-2 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#362775: swig: 1.3.29 fixes a bug for me
Package: swig Version: 1.3.28-1 Followup-For: Bug #362775 Support for ruby 1.6 was broken by swig 1.3.28. CVS logs at: http://swig.cvs.sourceforge.net/swig/SWIG/Lib/ruby/rubystrings.swg?view=log appear to confirm that the fix is present in release 1.3.29. ... just in case that extra demand for a new upstream release is necessary incentive. thanks! -neil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373101: debarchiver: warn on package architecture not in @architectures?
Package: debarchiver Version: 0.3.2 Severity: wishlist I decided to add amd64 packages into a debarchiver managed directory, and couldn't figure out why the Packages file wasn't being generated even though debarchiver did grab the amd64 packages from the incoming directory and place them in the right location. Although it was my mistake, I think it might be reasonable to warn when the dists/ (or at least incoming/) directory contains architectures not listed in the @architectures configuration variable. It appears that the @architectures variable isn't described in the man page; it would be nice if it were. I checked that the same missing documentation is present in 0.6.1, but did not test for any possibly-added warning. thanks for entertaining the suggestion(s), -neil -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.27-2-386 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages debarchiver depends on: ii adduser 3.63 Add and remove users and groups ii apt-utils 0.5.28.6 APT utility programs ii dpkg-dev 1.13.11package building tools for Debian ii opalmod 0.1.13 A set of Perl modules for various -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373101: debarchiver: warn on package architecture not in @architectures?
On Jun 12, 2006, at 6:10 PM, Ola Lundqvist wrote: Although it was my mistake, I think it might be reasonable to warn when the dists/ (or at least incoming/) directory contains architectures not listed in the @architectures configuration variable. I fully agree. Maybe it should even reject such packages, or what do you think? Ola, From my perspective, I think that the architectures configuration variable could be automatically determined from the union of the dists/*/binary-* directories and contents of incoming/, or perhaps (if you think there's a reason to exclude architectures present in those directories) automatically determined only if left unconfigured. If you do decide that rejecting is cleaner, 323614 (explain why package goes into REJECT/) seems relevant, though I'd bias toward a log file in the reject directory explaining specifics over man page explanations of the possible reasons. I have some .debs in a reject directory and I haven't had the time to figure out why. Thanks again -- I appreciate debarchiver and your attention. -neil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457645: mt-daapd: doesn't index more than one itunes.xml file
Package: mt-daapd Version: 0.9~r1586-1 Severity: minor mt-daapd incorrectly processes the second 'iTunes Music Library.xml' file that it scans, with the symptom of having the second set of playlists be present, but empty of songs. After some investigation, the scanner misinterprets the second xml file because it is looking to substitute the same prefix in the second file as it did in the first. This is because scan_xml_translate_path in src/scan-xml.c has static variables that assume that once the correct transform on filenames has been found, it is good. The fix is to move the "path_found" variable to be a proper global and reset it when scan_xml_file is set. I ended up testing an uglier fix that doesn't have much value as a patch. That function doesn't seem to have changed upstream. -neil -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18ns (PREEMPT) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages mt-daapd depends on: ii adduser 3.105add and remove users and groups ii avahi-daemon0.6.16-5 Avahi mDNS/DNS-SD daemon ii libavahi-compat-howl0 0.6.21-4 Avahi Howl compatibility library ii libavcodec1d0.cvs20070307-6 ffmpeg codec library ii libavformat1d 0.cvs20070307-6 ffmpeg file format library ii libavutil1d 0.cvs20070307-6 ffmpeg utility library ii libc6 2.7-4GNU C Library: Shared libraries ii libflac81.2.1-1 Free Lossless Audio Codec - runtim ii libid3tag0 0.15.1b-10 ID3 tag reading library from the M ii libogg0 1.1.3-2 Ogg Bitstream Library ii libsqlite3-03.4.2-2 SQLite 3 shared library ii libtagc01.4-8+b1 TagLib Audio Meta-Data Library (C ii libvorbis0a 1.2.0.dfsg-2 The Vorbis General Audio Compressi ii libvorbisfile3 1.2.0.dfsg-2 The Vorbis General Audio Compressi ii zlib1g 1:1.2.3.3.dfsg-6 compression library - runtime mt-daapd recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#285590: stable yet?
After trying to build a program that would use libdts on amd64, I discovered that I had to root around in its configuration to retarget it to use dts_pic instead. Your scheme of building a second library file with _pic is one I hadn't seen before. Given that libdts apparently hasn't changed for over a year, do you think you could consider it stable enough to either build an -fPIC version and leave it as the only .a, or include the .so file? The package seems fairly limited on amd64 otherwise. thanks, -neil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350979: libruby1.8: http.rb 'verify_mode' error
Package: libruby1.8 Version: 1.8.4-1 Severity: normal When running code that worked with 1.8.2 on sarge, 1.8.4 complains with the following trace. It suggests to me that @ssl_context is not set to anything other than nil (in the initialize method), so line 565 would more safely check @ssl_context first (and perhaps generate a more useful error message) before invoking @ssl_context.verify_mode. Again, although I'm not an xmlrpc whiz, the code does run correcly on sarge's version of ruby if I downgrade. "Correctly" does involve printing that warning message about the server's cert not being verified this session. It's possible that my mixed sarge/etch install is to blame (I wanted to install rails). I'll try to look into it a bit, since I realize this stack trace from code that would require authentication tokens to run and reproduce forms a fairly poor bug report. I thought it worth filing the incomplete report in case I'm not able to figure out a fix. thanks, -neil scriptroute:~/scriptroute/planetlab> ./enable_slice_on_all.rb /usr/lib/ruby/1.8/net/http.rb:565:in `connect': undefined method `verify_mode' for nil:NilClass (NoMethodError)from /usr/lib/ruby/1.8/net/http.rb:555:in `do_start' from /usr/lib/ruby/1.8/net/http.rb:544:in `start' from /usr/lib/ruby/1.8/net/http.rb:1031:in `request' from /usr/lib/ruby/1.8/net/http.rb:988:in `post2' from /usr/lib/ruby/1.8/xmlrpc/client.rb:535:in `do_rpc' from /usr/lib/ruby/1.8/xmlrpc/client.rb:420:in `call2' from /usr/lib/ruby/1.8/xmlrpc/client.rb:410:in `call' from ./enable_slice_on_all.rb:39:in `getListOfMyNodes' from ./enable_slice_on_all.rb:92 -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.27-2-386 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages libruby1.8 depends on: ii libc6 2.3.5-12 GNU C Library: Shared libraries an ii libncurses5 5.4-9 Shared libraries for terminal hand ii zlib1g1:1.2.3-3 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#633678: edd_id missing from daily initrd images
Package: debian-installer Hi, I'm unable to reinstall wheezy from usb / iso on my amd64 machine. After sufficient wrestling to create a symlink for wheezy to appear "stable" to appease anna-install (which seemed to look for stable anyway... there's a FIXME in there somewhere that seems suspect), I was blocked for a bit on an error after the (no-op) "partitioning" step in which the code wants to run edd_id. /lib/udev/edd_id is missing from the daily initrd images on d-i: anotherengine:~/Downloads% curl http://d-i.debian.org/daily-images/amd64/daily/hd-media/initrd.gz | gunzip -c | cpio -i -t | grep _id % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 57 5414k 57 3102k0 0 611k 0 0:00:08 0:00:05 0:00:03 636k lib/udev/ata_id lib/udev/usb_id lib/udev/scsi_id lib/udev/cdrom_id lib/udev/path_id but is mentioned in rules.d: anotherengine:~/Downloads% mkdir xy && cd xy && curl http://d-i.debian.org/daily-images/amd64/daily/cdrom/initrd.gz | gunzip -c | cpio -i -d anotherengine:~/Downloads/xy% grep -r edd_id * lib/udev/rules.d/60-persistent-storage.rules I was able to find edd_id in the squeeze initrd.gz image at http://ftp.nl.debian.org/debian/dists/squeeze/main/installer-amd64/current/images/hd-media/ , put it in place, and get past that particular error, though I have yet to succeed in un-bricking my system. Sorry for the poor format of this bug report. I think it's correct (certainly that the program is not there, certainly that some code attempts to invoke it), but I don't know whose fault it is that the program is missing. thanks, -neil -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#633678: Apparently this change happened in may.
curl http://d-i.debian.org/daily-images/amd64/20110531-00:15/hd-media/initrd.gz | gunzip -c | cpio -i -t | grep _id lacks edd_id, while curl http://d-i.debian.org/daily-images/amd64/20110501-00:14/hd-media/initrd.gz | gunzip -c | cpio -i -t | grep _id includes it. Just in case this helps track down the change. Thanks, -neil -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
