gcj uninitialized string diagnostic on server dist-upgrade step on move from Feisty to Gutsy

Bug #120461 reported by Xeno Campanoli
This bug report is a duplicate of:  Bug #118246: update-alternatives warnings. Edit Remove
6
Affects Status Importance Assigned to Milestone
gcj-4.1 (Ubuntu)
New
Undecided
Unassigned

Bug Description

Binary package hint: gcj-4.1

Steps I know about which got me to this point:

1. Set up Feisty Server with gcj on it. There may be other affecting packages. I have almost every major language package out there installed.
2. Edit /etc/apt/sources.list so all Feisty strings are changed to Gutsy.
3. apt-get update from xterm logged in as root.
4. apt-get upgrade
5. apt-get dist-upgrade

After step 5, and some time probably less than a half hour, the last processing ended with the following:

Setting up linux-restricted-modules-386 (2.6.22.6.5) ...
Setting up linux-386 (2.6.22.6.5) ...
Setting up lynx (2.8.6-2) ...
Installing new version of config file /etc/lynx.cfg ...

Setting up libgcj7-dev (4.1.2-8ubuntu1) ...
Setting up libstdc++6-4.1-dev (4.1.2-12ubuntu1) ...
Setting up gcj-4.1 (4.1.2-8ubuntu1) ...
Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 602.
Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 602.
Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 602.
Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 602.
Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 602.
Use of uninitialized value in string ne at /usr/sbin/update-alternatives line 602.

Setting up g++-4.1 (4.1.2-12ubuntu1) ...
Setting up gcj (4:4.1.2-1ubuntu4) ...
root@joehill:/etc/apt#
---snip---

Revision history for this message
Xeno Campanoli (xeno) wrote :

root@joehill:/etc/apt# apt-get -f dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@joehill:/etc/apt# apt-get -f upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@joehill:/etc/apt#
--snip--
I tried this right afterward. Perhaps this is only specific to a configuration with gcj. Looks like the rest of my upgrade from Feisty to Gutsy on this server has nothing obviously wrong; yet.
xc

Revision history for this message
Xeno Campanoli (xeno) wrote :

This is my line 602 in /usr/sbin/update-alternatives:

checked_symlink($slavepath{$preferred,$slnum},

where it looks like this with the surrounding code:

   if ($preferred ne '') {
        $manual = "manual";
        $preferred--;
        printf STDOUT _g("Using \`%s' to provide \`%s'.")."\n", $versions[$preferred], $name;
        my $spath = $versions[$preferred];
        symlink("$spath","$altdir/$name.dpkg-tmp") ||
            &quit(sprintf(_g("unable to make %s a symlink to %s: %s"), "$altdir/$name.dpkg-tmp", $spath, $!));
        rename_mv("$altdir/$name.dpkg-tmp","$altdir/$name") ||
            &quit(sprintf(_g("unable to install %s as %s: %s"), "$altdir/$name.dpkg-tmp", "$altdir/$name", $!));
        # Link slaves...
        for( my $slnum = 0; $slnum < @slavenames; $slnum++ ) {
            my $slave = $slavenames[$slnum];
            if ($slavepath{$preferred,$slnum} ne '') {
                checked_symlink($slavepath{$preferred,$slnum}, #<---xc602
                        "$altdir/$slave.dpkg-tmp");
                checked_mv("$altdir/$slave.dpkg-tmp", "$altdir/$slave");
            } else {
                &pr(sprintf(_g("Removing %s (%s), not appropriate with %s."), $slave, $slavelinks[$slnum], $versions[$preferr
                    if $verbosemode > 0;
                unlink("$altdir/$slave") || $! == &ENOENT ||
                    &quit(sprintf(_g("unable to remove %s: %s"), "$altdir/$slave", $!));
            }
        }

    }
}

sub set_alternatives {

Revision history for this message
Xeno Campanoli (xeno) wrote :

Well, I screwed that up!
1. Looks like this is related to bug: #118246,
2. THE ABOVE INSERTION, BY ME, IS JUST WRONG. My apologies. This is the correct line:

            if (!defined($linkname= readlink($slink)) && $! != &ENOENT) {

but it's not clear to me whether that's from != or the ne on the else:

 if (!defined($linkname= readlink($slink)) && $! != &ENOENT) {
                &pr(sprintf(_g("warning: %s is supposed to be a slave symlink to\n".
                               " %s, or nonexistent; however, readlink failed: %s"), $slink, "$altdir/$sname", $!)) if $verbosemode > 0;
            } elsif ($linkname ne "$altdir/$sname") {
                unlink("$slink.dpkg-tmp") || $! == &ENOENT ||
                    &quit(sprintf(_g("unable to ensure %s nonexistent: %s"), "$slink.dpkg-tmp", $!));
---snip---

My apologies for the confusion.

Revision history for this message
Fabien Tassin (fta) wrote :

as I've said on #118246, I've traced it and in my case, it's $slink that is undefined.
It occurs (at least) when upgrading a package providing itself all the alternatives for something.

eg fakeroot: two binaries with one alternative on them. no other package (installed) providing other alternatives. The package is upgraded, at some point, the links are removed but update-alternative wants to update the symlinks. problem is there's no other available alternatives to recreate the link, thuss the warnings.

there may be other cases but I've only analyzed the case for fakeroot.

BTW, the fix you propose here is already what I have !??

Revision history for this message
Fabien Tassin (fta) wrote :

I've just posted a patch for LP #118246 fixing this.

This one (LP #120461) is a duplicate.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.