Tim-
Thanks for the feedback.
Yeah, as I substituted amd64 for 64 to create that patch I was
thinking to myself "man this is probably not what we really want" - it
was just more of an idea and to see if that was really the root cause
of the bootstrap failures. So I re-wrote to do the uname check like
you mentioned and uploaded a new diff file called shadow_bin.svndiff2
in the same place. It seems to work but I don't know very much python
so it may not be optimal. Hopefully it gets the idea across.
I think I also uncovered another side-effect to using "64" instead of
"amd64" - there are actually some collisions for some files between
libncurses5-dev and sunwcsl:
sunwcsl: /usr/lib/amd64/libform.so
sunwcsl: /usr/lib/amd64/libpanel.so
sunwcsl: /usr/lib/amd64/libmenu.so
But when libncurses5-dev used "/usr/lib/64" it blindly over-wrote the
files (because dpkg/apt don't seem to recognize the file through the
symlink). For example-
# dpkg -S /usr/lib/amd64/libmenu.so
sunwcsl: /usr/lib/amd64/libmenu.so
# dpkg -S /usr/lib/64/libmenu.so
dpkg: /usr/lib/64/libmenu.so not found.
So the newly built packages needed a dpkg-divert to rename the three
files above.
BTW - this does fix the ISO building problem after I populated my
local /tank/ncp2 repo with all the .debs from the libiconv and ncurses
shadow builds with "amd64" as the 64bit directory. Let me know if you
want me to upload them.
Jason
On Fri, Feb 6, 2009 at 1:33 PM, Tim Spriggs <t...@tajinc.org> wrote:
> The only problem with the diff (and the reason I wanted to just use "64") is
> that the script won't work on sparc once we have a port to it. This is a
> real PITA. On the other hand having to call "uname" every time one of the
> wrapper commands is called is a real bummer too. It may not be as expensive
> as I think since python has a uname module which should just be internal env
> calls. I'll keep the patch in mind but I'm not ultimately sure how I want to
> deal with this yet.
>
> As for the package version, adding -1 is appropriate.
>
> Thanks,
> -Tim
>
> Jason Upton wrote:
>>
>> Tim-
>>
>> FYI...
>>
>> I put a svn diff of what I think needs to change for the shadow build
>> scripts. It is on gnusolaris.org in:
>>
>> ~wavejumper/shadow_bin.svndiff
>>
>> I have rebuilt libiconv with the changes and it seems to work (files
>> are in amd64 now). I'm rebuilding ncurses now and I'll put the debs I
>> built into my local /tank/ncp2 repo and see if that fixes the iso
>> building problems and report back later today.
>>
>> I can upload them after my iso testing if you want (and if you agree
>> with my proposal). I changed the version suffix from "+64" to
>> "+64-1". Wasn't sure what you'd expect/want for version updates on
>> this +64 suffix.
>>
>> Jason
>>
>> On Fri, Feb 6, 2009 at 11:50 AM, Jason Upton <wavejumpe...@gmail.com>
>> wrote:
>>
>>>
>>> I think I have found the problem. The sunwcsl package wants to create
>>> a symlink for /usr/lib/64 to /usr/lib/amd64 but the new "shadow-built"
>>> packages with combined 32/64 libs (ex libiconv, libncurses) has
>>> created a real directory for /usr/lib/64 already. So debootstrap
>>> fails while unpacking sunwcsl with:
>>>
>>> tar: ./usr/lib/64: Cannot create symlink to `amd64': File exists
>>> tar: Error exit delayed from previous errors
>>>
>>> In the sunwcsl package you can see that it wants /usr/lib/amd64 to be
>>> a real directory and /usr/lib/64 to be a symlink:
>>>
>>> r...@upton3:/tmp# dpkg -c
>>>
>>> /tank/ncp2/dists/hardy-unstable/main/binary-solaris-i386/base/sunwcsl_5.11.104-5_solaris-i386.deb
>>> |grep "/usr/lib/64"
>>> lrwxrwxrwx root/root 0 2009-02-04 14:45:45 ./usr/lib/64 -> amd64
>>>
>>> r...@upton3:/tmp# dpkg -c
>>>
>>> /tank/ncp2/dists/hardy-unstable/main/binary-solaris-i386/base/sunwcsl_5.11.104-5_solaris-i386.deb
>>> |grep "/usr/lib/amd64/$"
>>> drwxr-xr-x root/bin 0 2009-02-04 14:45:25 ./usr/lib/amd64/
>>>
>>> And on a system without updates to include the new shadow-built 32/64
>>> packages, you can see that indeed all "64" directories are symlinks to
>>> real "amd64" directories under /usr/lib:
>>>
>>> r...@upton3:/tmp# find /usr/lib -name 64 -exec ls -ald {} \;
>>> lrwxrwxrwx 1 root root 5 Dec 29 22:15 /usr/lib/link_audit/64 -> amd64
>>> lrwxrwxrwx 1 root root 5 Dec 29 22:15 /usr/lib/64 -> amd64
>>> drwxr-xr-x 2 root bin 3 Dec 29 22:16 /usr/lib/dtrace/64
>>> lrwxrwxrwx 1 root root 5 Dec 29 22:15 /usr/lib/security/64 -> amd64
>>> lrwxrwxrwx 1 root root 5 Dec 29 22:15 /usr/lib/secure/64 -> amd64
>>> lrwxrwxrwx 1 root root 5 Dec 29 22:15 /usr/lib/lwp/64 -> amd64
>>>
>>> r...@upton3:/tmp# find /usr/lib -name amd64 -exec ls -ald {} \;
>>> drwxr-xr-x 4 root bin 390 Jan 28 11:54 /usr/lib/amd64
>>> drwxr-xr-x 2 root bin 6 Dec 29 22:17 /usr/lib/sasl/amd64
>>> drwxr-xr-x 2 root bin 4 Dec 29 22:17 /usr/lib/krb5/amd64
>>> drwxr-xr-x 2 root sys 3 Dec 29 22:19 /usr/lib/adb/amd64
>>> drwxr-xr-x 2 root bin 5 Dec 29 22:17 /usr/lib/link_audit/amd64
>>> drwxr-xr-x 2 root bin 5 Dec 29 22:17 /usr/lib/ld/amd64
>>> drwxr-xr-x 2 root bin 58 Jan 28 11:54 /usr/lib/security/amd64
>>> drwxr-xr-x 2 root bin 2 Dec 16 12:13 /usr/lib/secure/amd64
>>> drwxr-xr-x 2 root sys 3 Jan 28 11:54 /usr/lib/fs/smbfs/amd64
>>> drwxr-xr-x 2 root sys 3 Jan 28 11:54 /usr/lib/fs/smb/amd64
>>> drwxr-xr-x 2 root sys 3 Dec 29 22:17 /usr/lib/fs/nfs/amd64
>>> drwxr-xr-x 2 root bin 26 Dec 29 22:19 /usr/lib/fm/amd64
>>> drwxr-xr-x 2 root bin 11 Dec 29 22:19 /usr/lib/fm/fmd/schemes/amd64
>>> drwxr-xr-x 2 root bin 4 Dec 29 22:16 /usr/lib/lwp/amd64
>>> drwxr-xr-x 2 root sys 3 Dec 29 22:17 /usr/lib/ipf/amd64
>>> drwxr-xr-x 2 root bin 3 Dec 29 22:17 /usr/lib/locale/iso_8859_1/amd64
>>> drwxr-xr-x 3 root root 3 Jun 4 2008 /usr/lib/perl/5.8.8/amd64
>>> drwxr-xr-x 2 root bin 16 Dec 29 22:16 /usr/lib/cfgadm/amd64
>>> drwxr-xr-x 2 root sys 48 Jan 28 11:54 /usr/lib/mdb/kvm/amd64
>>> drwxr-xr-x 2 root bin 14 Jan 28 11:54 /usr/lib/mdb/proc/amd64
>>> drwxr-xr-x 2 root sys 3 Dec 29 22:16 /usr/lib/mdb/raw/amd64
>>> drwxr-xr-x 2 root bin 3 Dec 29 22:16 /usr/lib/raidcfg/amd64
>>> drwxr-xr-x 2 root bin 2 Dec 18 00:35 /usr/lib/fp/libp/amd64
>>> drwxr-xr-x 2 root bin 6 Dec 29 22:17 /usr/lib/smedia/amd64
>>> drwxr-xr-x 2 root bin 5 Dec 29 22:16 /usr/lib/dns/amd64
>>> drwxr-xr-x 2 root bin 5 Dec 29 22:17 /usr/lib/iconv/amd64
>>> drwxr-xr-x 2 root bin 6 Dec 29 22:17
>>> /usr/lib/scsi/plugins/ses/vendor/amd64
>>> drwxr-xr-x 2 root bin 4 Dec 29 22:16
>>> /usr/lib/scsi/plugins/ses/framework/amd64
>>> drwxr-xr-x 2 root bin 3 Dec 29 22:16
>>> /usr/lib/scsi/plugins/scsi/engines/amd64
>>> drwxr-xr-x 2 root bin 8 Dec 29 22:19 /usr/lib/scsi/amd64
>>>
>>> Looking through the packages with "+64" in the name and seeing what
>>> happens with "/usr/lib/64" shows that this directory is made as a real
>>> directory, not a symlink.
>>>
>>> r...@upton3:/tmp# (for file in `find /tank/ncp2/ -name "*+64*.deb"` ;
>>> do dpkg -c $file ; done)|grep "/usr/lib/64"
>>> drwxr-xr-x root/root 0 2009-02-04 13:43:42 ./usr/lib/64/
>>> -rw-r--r-- root/root 2952160 2009-02-04 13:43:03
>>> ./usr/lib/64/libncursesw_g.a
>>> -rw-r--r-- root/root 355252 2009-02-04 13:43:04
>>> ./usr/lib/64/libmenuw_g.a
>>> -rw-r--r-- root/root 684714 2009-02-04 13:43:05
>>> ./usr/lib/64/libformw_g.a
>>> -rw-r--r-- root/root 137752 2009-02-04 13:43:03
>>> ./usr/lib/64/libpanelw_g.a
>>> drwxr-xr-x root/root 0 2009-02-04 13:44:56 ./usr/lib/64/
>>> -rw-r--r-- root/root 65814 2009-02-04 13:44:55
>>> ./usr/lib/64/libmenuw.a
>>> -rw-r--r-- root/root 169154 2009-02-04 13:44:55
>>> ./usr/lib/64/libncurses++w.a
>>> -rw-r--r-- root/root 754774 2009-02-04 13:44:56
>>> ./usr/lib/64/libncursesw.a
>>> -rw-r--r-- root/root 126908 2009-02-04 13:44:56
>>> ./usr/lib/64/libformw.a
>>> -rw-r--r-- root/root 25794 2009-02-04 13:44:56
>>> ./usr/lib/64/libpanelw.a
>>> lrwxrwxrwx root/root 0 2009-02-04 13:43:41
>>> ./usr/lib/64/libpanelw.so -> libpanelw.so.5
>>> lrwxrwxrwx root/root 0 2009-02-04 13:43:41
>>> ./usr/lib/64/libmenuw.so -> libmenuw.so.5
>>> lrwxrwxrwx root/root 0 2009-02-04 13:43:41
>>> ./usr/lib/64/libformw.so -> libformw.so.5
>>> lrwxrwxrwx root/root 0 2009-02-04 13:44:47
>>> ./usr/lib/64/libncursesw.so -> /lib/64/libncursesw.so.5
>>> drwxr-xr-x root/root 0 2009-02-04 13:43:40 ./usr/lib/64/
>>> -rw-r--r-- root/root 2587638 2009-02-04 13:42:57
>>> ./usr/lib/64/libncurses_g.a
>>> -rw-r--r-- root/root 654460 2009-02-04 13:42:59
>>> ./usr/lib/64/libform_g.a
>>> -rw-r--r-- root/root 344900 2009-02-04 13:42:59
>>> ./usr/lib/64/libmenu_g.a
>>> -rw-r--r-- root/root 133032 2009-02-04 13:42:58
>>> ./usr/lib/64/libpanel_g.a
>>> drwxr-xr-x root/root 0 2009-02-04 13:44:55 ./usr/lib/64/
>>> -rw-r--r-- root/root 673982 2009-02-04 13:44:55
>>> ./usr/lib/64/libncurses.a
>>> -rw-r--r-- root/root 169154 2009-02-04 13:44:55
>>> ./usr/lib/64/libncurses++.a
>>> lrwxrwxrwx root/root 0 2009-02-04 13:43:23
>>> ./usr/lib/64/libmenu.so -> libmenu.so.5
>>> lrwxrwxrwx root/root 0 2009-02-04 13:43:23
>>> ./usr/lib/64/libform.so -> libform.so.5
>>> lrwxrwxrwx root/root 0 2009-02-04 13:43:23
>>> ./usr/lib/64/libpanel.so -> libpanel.so.5
>>> lrwxrwxrwx root/root 0 2009-02-04 13:44:47
>>> ./usr/lib/64/libncurses.so -> /lib/64/libncurses.so.5
>>> drwxr-xr-x root/root 0 2009-02-04 13:43:22 ./usr/lib/64/
>>> lrwxrwxrwx root/root 0 2009-02-04 13:43:22
>>> ./usr/lib/64/libpanel.so.5 -> libpanel.so.5.5
>>> lrwxrwxrwx root/root 0 2009-02-04 13:43:22
>>> ./usr/lib/64/libmenu.so.5 -> libmenu.so.5.5
>>> lrwxrwxrwx root/root 0 2009-02-04 13:43:22
>>> ./usr/lib/64/libform.so.5 -> libform.so.5.5
>>> drwxr-xr-x root/root 0 2009-02-04 13:43:41 ./usr/lib/64/
>>> lrwxrwxrwx root/root 0 2009-02-04 13:43:41
>>> ./usr/lib/64/libpanelw.so.5 -> libpanelw.so.5.5
>>> lrwxrwxrwx root/root 0 2009-02-04 13:43:41
>>> ./usr/lib/64/libformw.so.5 -> libformw.so.5.5
>>> lrwxrwxrwx root/root 0 2009-02-04 13:43:41
>>> ./usr/lib/64/libmenuw.so.5 -> libmenuw.so.5.5
>>> drwxr-xr-x root/root 0 2009-02-02 19:31:48 ./usr/lib/64/
>>> -rw-r--r-- root/root 6952 2009-02-02 19:31:48
>>> ./usr/lib/64/libcharset.so.1.0.0
>>> -rw-r--r-- root/root 6680 2009-02-02 19:31:48
>>> ./usr/lib/64/libcharset.a
>>> -rw-r--r-- root/root 1015704 2009-02-02 19:31:48
>>> ./usr/lib/64/preloadable_libiconv.so
>>> lrwxrwxrwx root/root 0 2009-02-02 19:31:48
>>> ./usr/lib/64/libiconv.so.2 -> /lib/64/libiconv.so.2.4.0
>>> lrwxrwxrwx root/root 0 2009-02-02 19:31:48
>>> ./usr/lib/64/libcharset.so -> libcharset.so.1.0.0
>>> lrwxrwxrwx root/root 0 2009-02-02 19:31:48
>>> ./usr/lib/64/libiconv.so.2.4.0 -> /lib/64/libiconv.so.2.4.0
>>> lrwxrwxrwx root/root 0 2009-02-02 19:31:48
>>> ./usr/lib/64/libiconv.so -> /lib/64/libiconv.so.2.4.0
>>> lrwxrwxrwx root/root 0 2009-02-02 19:31:48
>>> ./usr/lib/64/libcharset.so.1 -> libcharset.so.1.0.0
>>>
>>> And searching those packages for "/usr/lib/amd64" yields nothing:
>>>
>>> r...@upton3:/tmp# (for file in `find /tank/ncp2/ -name "*+64*.deb"` ;
>>> do dpkg -c $file ; done)|grep "/usr/lib/amd64"
>>> r...@upton3:/tmp#
>>>
>>> So I propose that the shadow build packages should be using "amd64"
>>> instead of "64" since the former always seems to be a directory and
>>> the latter a symlink.
>>>
>>> Sorry for so much detail, but couldn't figure out a better way to get
>>> it across in email.
>>>
>>> Jason
>>>
>>> On Fri, Feb 6, 2009 at 9:09 AM, Jason Upton <wavejumpe...@gmail.com>
>>> wrote:
>>>
>>>>
>>>> FYI- This also affects zone installs (presumably since both are using
>>>> debootstrap). Same error:
>>>>
>>>> bash# zoneadm -z zonetestcontrib install
>>>> ...
>>>> ...
>>>> I: Extracting sunwcsl...
>>>> Zone 'zonetestcontrib' is not fully installed. debootstrap returned
>>>> error code [2].
>>>>
>>>> Jason
>>>>
>>>> On Fri, Feb 6, 2009 at 5:57 AM, Anil Gulecha <anil.ve...@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> Debootstrap during nbld-bootstrap fails. This has been seen in 2
>>>>> instances in the past 2 days. It could be related to the the recent
>>>>> sunw packages, as the last package to be extracted before the failure
>>>>> is sunwcsl.
>>>>>
>>>>> ...
>>>>> ...
>>>>> I: Extracting sunwcsl...
>>>>> Error: couldn't complete bootstrap
>>>>> Lock /tank/ncp2/dists/debarchiver.lock removed
>>>>>
>>>>> Ideas on why this is happening?
>>>>>
>>>>> Anil
>>>>> _______________________________________________
>>>>> gnusol-devel mailing list
>>>>> gnusol-devel@lists.sonic.net
>>>>> http://lists.sonic.net/mailman/listinfo/gnusol-devel
>>>>>
>>>>>
>
>
_______________________________________________
gnusol-devel mailing list
gnusol-devel@lists.sonic.net
http://lists.sonic.net/mailman/listinfo/gnusol-devel
