Hi Tim,
Sorry I didn't respond sooner. I like the changes you made to remove
the code duplication. The ncurses package builds much like before
except now uses amd64 directory so that looks good to me.
The same two problems I mentioned in my other reply still exist
though. I'll try to look into it some more and let you know if I
figure any more out. Do you think we need a "ld" shadow wrapper for
the second issue like I speculated?
Thanks,
Jason
On Sat, Feb 7, 2009 at 5:04 PM, Tim Spriggs <t...@tajinc.org> wrote:
> Hi Jason,
>
> The code duplication throughout the scripts was driving me batty. Before it
> got any worse I refactored the code to use a base class (which provides the
> new dir-name semantics.) There will be a little more refactoring to come but
> the changes should be very minor (comparatively.)
>
> I've only done some high level testing and I found a few bugs that may have
> kept things from working fully. It's possible I introduced some new ones too
> though :-/ I have to run off for tonight so I committed the changes to the
> repository so you can grab them.
>
> If you could test the shadow_env on the packages you previously mentioned I
> would appreciate it to know if all problems still exist before diving in
> again.
>
> Cheers,
> -Tim
>
> Jason Upton wrote:
>>
>> 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
