[osol-discuss] Re: build 27a on x86 : panic at boot
same here on my wz1100. Is this a new occurence of 6294769? For info I found this thread which is pretty close http://www.opensolaris.org/jive/thread.jspa?messageID=4174၎ bbr This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: build 27a on x86 : panic at boot
Benjamin Brumaire wrote: same here on my wz1100. Is this a new occurence of 6294769? For info I found this thread which is pretty close http://www.opensolaris.org/jive/thread.jspa?messageID=4174၎ bbr Could it be related to this? http://www.gnusolaris.org/cgi-bin/trac.cgi/ticket/84 (Not sure if Sun already has a bug open to track that.) -- Mac ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Nexenta OS (elatte) Alpha 1 released
Nexenta OS (elatte) Alpha 1 is now available for download at: http://www.gnusolaris.org This release contains 6 ISO images: LiveCD, InstallCD, and 4 SourceCDs. Features: * OpenSolaris kernel build #27 (non-debug). * Xorg 6.8.2-77, substantially revamped and fixed to auto-detect hardware and configure itself. * More network drivers. * 23 bugs fixed and features added since the pre-alpha (11/07) release. * 90 new packages added. Thanks! Nexenta Team. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Nexenta OS (elatte) Alpha 1 released
Alex, I just tried to do a dist-upgrade from pre-alpha1 and it failed on sunwcsd. It looks like it is trying to remove and recreate devices, which is failing. Is dist-upgrade meant to be supported yet do we need to reinstall. ShanonOn 11/21/05, Alex Ross <[EMAIL PROTECTED]> wrote: Nexenta OS (elatte) Alpha 1 is now available for download at:http://www.gnusolaris.orgThis release contains 6 ISO images: LiveCD, InstallCD, and 4 SourceCDs. Features:* OpenSolaris kernel build #27 (non-debug).* Xorg 6.8.2-77, substantially revamped and fixed to auto-detect hardwareand configure itself.* More network drivers.* 23 bugs fixed and features added since the pre-alpha (11/07) release. * 90 new packages added.Thanks!Nexenta Team.___opensolaris-discuss mailing listopensolaris-discuss@opensolaris.org -- Achieve Your Full Potential ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Nexenta OS (elatte) Alpha 1 released
Shanon Loveridge wrote: I just tried to do a dist-upgrade from pre-alpha1 and it failed on sunwcsd. It looks like it is trying to remove and recreate devices, which is failing. Is dist-upgrade meant to be supported yet do we need to reinstall. Unfortunately you'd still need to reinstall in order to upgrade some sunw packages (incl. sunwcsd). We are working towards fixing this, hopefully by Alpha 2. -- Mac ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Nexenta OS (elatte) Alpha 1 released
Shanon, Live upgrades of kernels (ala Ubuntu GNU/Linux) is not supported yet. This is something we are working on. This is not trivial feature at all and will require some time to implement. For the time being you have to reinstall. Note that once you reinstall, upgrades for many others sunw* packages should just work. Erast On Mon, 2005-11-21 at 20:24 +1100, Shanon Loveridge wrote: > Alex, > > I just tried to do a dist-upgrade from pre-alpha1 and it failed on > sunwcsd. It looks like it is trying to remove and recreate devices, > which is failing. > > Is dist-upgrade meant to be supported yet do we need to reinstall. > > Shanon > > On 11/21/05, Alex Ross <[EMAIL PROTECTED]> wrote: > Nexenta OS (elatte) Alpha 1 is now available for download at: > > http://www.gnusolaris.org > > This release contains 6 ISO images: LiveCD, InstallCD, and 4 > SourceCDs. > > Features: > > * OpenSolaris kernel build #27 (non-debug). > * Xorg 6.8.2-77, substantially revamped and fixed to > auto-detect hardware > and configure itself. > * More network drivers. > * 23 bugs fixed and features added since the pre-alpha (11/07) > release. > * 90 new packages added. > > Thanks! > Nexenta Team. > > > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > > > > -- > > Achieve Your Full Potential > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: build 27a on x86 : panic at boot
> diskread: reading beyond end of ramdisk
> start = 0x2000, size = 0x2000
> failed to read superblock
I believe this is a new bug, introduced by the fix for:
6344611 create_ramdisk needs to react less poorly to missing files or
directories.
http://cvs.opensolaris.org/source/diff/on/usr/src/cmd/boot/scripts/create_ramdisk.ksh?r2=1.7&r1=1.6
Note how the test on line 99 tests for the existence of the wrong file; it is
missing the ${ALT_ROOT} file prefix. This breaks creating ramdisk boot archives
on a server for diskless clients. I guess it also breaks creating the ramdisk
boot
archive during CD/Network installation (because the install target HDD is
probably
mounted at "/a" and create_ramdisk is run with option "-R /a", and the getsize
shell function computes a bogus ramdisk size estimate - unless it is run from
the
"/a" directory).
I've filed the following bug on bugs.opensolaris.org
(Sorry, I've not yet got the CR / bug id):
=
In snv_27 /boot/solaris/bin/create_ramdisk is badly broken, it cannot build
boot archives for a Solaris installation in an alternate root any more:
Example (diskless client):
# cd /tmp
# pwd
/tmp
# /export/root/moritz/boot/solaris/bin/create_ramdisk -R /export/root/moritz
Creating ram disk on /export/root/moritz
updating /export/root/moritz/platform/i86pc/boot_archive...this may take a
minute
Could not seek to offset -1 in /tmp/create_ramdisk.3228.tmp/rd.file: Invalid
argument
mount: I/O error
mount: Cannot mount /dev/lofi/1
umount: warning: /tmp/create_ramdisk.3228.tmp/rd.mount not in mnttab
umount: /tmp/create_ramdisk.3228.tmp/rd.mount not mounted
rmdir: directory "/tmp/create_ramdisk.3228.tmp/rd.mount": Directory not empty
Root cause: the getsize shell function in boot/solaris/bin/create_ramdisk
estimates a size of 0 KBytes for the ramdisk.
94 function getsize {
95 # Estimate image size, add %10 overhead for ufs stuff
96 total_size=0
97 for file in $filelist
98 do
99 if [ -e $file ] ; then
100 du -sk ${ALT_ROOT}/${file} | read size name
101 (( total_size += size ))
102 fi
103 done
104 (( total_size += total_size * 10 / 100 ))
105 }
Of cause the test at line 99 must test "${ALT_ROOT}/${file}", not "$file" !
Workaround:
===
run create_ramdisk with the current directory set to the alternate root
directory; with the example above:
# cd /export/root/moritz
# /export/root/moritz/boot/solaris/bin/create_ramdisk -R /export/root/moritz
Suggested Fix:
==
--- usr/src/cmd/boot/scripts/create_ramdisk.ksh~2005-11-14
22:11:41.0 +0100
+++ usr/src/cmd/boot/scripts/create_ramdisk.ksh 2005-11-19 20:32:19.401462000
+0100
@@ -96,7 +96,7 @@
total_size=0
for file in $filelist
do
- if [ -e $file ] ; then
+ if [ -e ${ALT_ROOT}/$file ] ; then
du -sk ${ALT_ROOT}/${file} | read size name
(( total_size += size ))
fi
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] mounted CDROMs and door locking
On Monday 21 November 2005 06:07, Ian Collins wrote: > Matt Ingenthron wrote: > > Robert Lunnon wrote: > >> I want to stir the pot a bit and ask whether Solaris's practise of > >> locking the manual cd open is really necessary when read-only media > >> in mounted. Why not allow a manual eject and just invalidate the fs > >> and unmount the filesystem automatically on a media remove. > > > > Not to say it's the wrong thing to do, but under this proposal, what > > do you suggest is the appropriate way to handle processes running off > > of that filesystem or with open FDs to files on that filesystem? > > Why not temper the proposal and add a force eject option? There are > times when the CD will refuse to eject, resulting in the straightened > paper clip being used. Once this has been done, it's just about > impossible to get Solaris to recognise another CD. If the machine is a > server, this can result in the CD drive being unusable until the next > reboot, when ever that might be > > >> I am suggesting this because I have a couple of friends who I have > >> shifted to Solaris and they continually complain about the CDROM not > >> ejecting. It would be much better from a user POV to allow manual > >> ejects. > > > > Personally, it's never bothered me. Maybe once or twice when I had to > > go find a console to eject something off of a server, but after you > > get used to it, you remember to eject beforehand. :) Also, I > > frequently install to a server from the CD in my laptop over NFS > > anyway-- less walking and it's not unusual for the drive in my laptop > > to be faster. > > Agreed, but I think we do need better disaster recover with CD drives. > > Ian My users don't use the command line, they are fugitives from windows. They have common problems with the cdrom refusing to eject. It's hard to explain to a windows exile that the cd wont eject because there "Might be" a file open on it. In some other cases I've seen things get so confused that the CD returns an I/O error and no amount of eject commands will eject it. I've had to stop the volume manager, and eject it manually. You really cant expect a mere mortal to do these things, they need easy ways out of these things. I personally don't see why a read-only media can't be ejected like this, after all we live with floppies and other removable disks (eg flash drives) that Solaris just can't prevent you from removing. What makes CDs so different? . Besides, not being able to eject the CD with the eject button is counter-intuitive and in my book that just makes it plain wrong from a HMI design point of view. Bob ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] mounted CDROMs and door locking
On Monday 21 November 2005 00:42, Joerg Schilling wrote: > Robert Lunnon <[EMAIL PROTECTED]> wrote: > > I want to stir the pot a bit and ask whether Solaris's practise of > > locking the manual cd open is really necessary when read-only media in > > mounted. Why not allow a manual eject and just invalidate the fs and > > unmount the filesystem automatically on a media remove. > > > > I am suggesting this because I have a couple of friends who I have > > shifted to Solaris and they continually complain about the CDROM not > > ejecting. It would be much better from a user POV to allow manual ejects. > > This practice is used since 1988 and before Microsoft and Linux did > something else, nobody complained. > > Jörg I don't know Jörg, there have been complaints about vold for as long as I can remember and a large part of it is because if something goes wrong you can't force an ejected state to fix it. If I was able to force an eject on demand and get volume manager to recognise it then I'd probably have far less complaint about vold. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [Security-discuss] Re: [osol-discuss] how to crypt a folder?
On Fri, 2005-11-18 at 17:13, Joerg Schilling wrote: > Darren J Moffat <[EMAIL PROTECTED]> wrote: > > > We currently have an encrypt(1) command that works on individual files. > > > > We have encryption support for lofi(7d) - the block driver - working > > and hope to release it to OpenSolaris site soon. > > This sounds really good. > > Do you have an idea when this will happen? The code is working already - I'm running with it on my laptop just now. We are currently using AES_CBC but want to change it over to AES_CTR which has only just integrated into snv_28. Once we have done that we will try and get the code bits up onto opensolaris.org, at the very least the lofi(7d) and lofiadm(1m) changes - the project has a PAM module and some other things in it just now but those less (IMO) important. I'll discuss this with Casper this week to make sure he is on board with this plan as well. -- Darren J Moffat ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OKay .. I guess this is the way you want it ..
On Sat, 2005-11-19 at 00:07, Dennis Clarke wrote: > For Casper :-) > > ? Automatically Layout File Systems > > > On this screen you must select all the file systems you want auto-layout to > create, or accept the default file systems shown. > > NOTE: For small disks, it may be necessary for auto-layout to break up some > of the file systems you request into smaller file systems to fit the > available disk space. So, after auto-layout completes, you may find file > systems in the layout that you did not select from the list below. > > File Systems for Auto-layout > > [X] / > [ ] /opt > [ ] /usr > [ ] /usr/openwin > [ ] /var > [X] swap > > > This feels "wrong" and maybe I'll just get over it. The bit that is "wrong" is that we still mentioned /usr/openwin as "special" thats so SunOS 4.x :-) [ or at least pre 2.6 ]. -- Darren J Moffat ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: HP Compaq DL380s, DL580 CCISS drivers oh my!
> Today I dl'ed the x86 version and tried it out on the > Dl380 G2 and when it boot the first CD, it hung > shortly after the Grub menu. Try to boot the kernel with "moddebug" set to 8000, so that we can get an idea in which part of the kernel / which kernel module it is hanging. For setting moddebug, see Dan Mick's blog: http://blogs.sun.com/roller/page/dmick?entry=diagnosing_kernel_hangs_panics_with This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OKay .. I guess this is the way you want it ..
[ ... ] > > File Systems for Auto-layout > > > > [X] / > > [ ] /opt > > [ ] /usr > > [ ] /usr/openwin > > [ ] /var > > [X] swap > > > > > > This feels "wrong" and maybe I'll just get over it. > > The bit that is "wrong" is that we still mentioned /usr/openwin > as "special" thats so SunOS 4.x :-) [ or at least pre 2.6 ]. Well, what always feels far most wrong (is there a 'wrongest' ?) to me is that on today's disks, it assigns 90% of the disk to /export/home by default although that's not even listed there ... FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Urgent help requested...system boots with errors after BFUing to 27
Will Hayworth writes: > After which it asked for my root password to get into maintenance > mode, which I provided. One of the prompts had recommended that I > run fsck, so I did, answering yes to every prompt, hoping that it > would be smart (forgive the inherent ignorance in this). But after > rebooting in normal mode, I still get that same prompt. Failsafe > boots reasonably, but I can't do anything useful in it. The one useful thing you should be able to do in it is run "bootadm update-archive". You get into this state when there's a mismatch between the contents of the boot archive (used by GRUB) and the actual files on the disk. Rather than allowing the system to run (and potentially fly to bits in the process), it forces you into this failsafe mode to repair the problem. You always need to do "bootadm update-archive" after updating key things, such as device drivers. If you're doing that from the failsafe, you need to mount your normal root somewhere first, and use the "-R" option on bootadm. (The failsafe boot option _should_ walk you through this process. If it doesn't, then that sounds like a newboot [GRUB] problem. File a bug.) -- James Carlson, KISS Network<[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] mounted CDROMs and door locking
Robert Lunnon <[EMAIL PROTECTED]> wrote: > My users don't use the command line, they are fugitives from windows. They > have common problems with the cdrom refusing to eject. It's hard to explain > to a windows exile that the cd wont eject because there "Might be" a file > open on it. In some other cases I've seen things get so confused that the CD > returns an I/O error and no amount of eject commands will eject it. I've had > to stop the volume manager, and eject it manually. You really cant expect a > mere mortal to do these things, they need easy ways out of these things. > > I personally don't see why a read-only media can't be ejected like this, > after > all we live with floppies and other removable disks (eg flash drives) that > Solaris just can't prevent you from removing. What makes CDs so different? > . > Besides, not being able to eject the CD with the eject button is > counter-intuitive and in my book that just makes it plain wrong from a HMI > design point of view. Before MS Win did start to "support" this, it was the agreeed behavior: - Apple _and_ Sun did have a Floppy drive _without_ eject button. - CD-ROM drives did just copy this idea and allowed to make the eject button to "diasppear" (being hidden). If you run a command line, you call "eject cdrom". If you use a gui, you just push the eject button on the gui. So where is your problem? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: snv_b28 this week ?
Going by the Nevada schedule build 28 should come approx. 2 weeks after build 27. nv27 hit the sdlc november 16, i'll leave the difficult calculations up to you ;) This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] mounted CDROMs and door locking
On 21 Nov 2005, at 12:28, Joerg Schilling wrote: - Apple _and_ Sun did have a Floppy drive _without_ eject button. Apple still do this, FWIW... you won't find an eject button on a Mac's CD/DVD drive. (Or its floppy drive, if you can still find one of those.) They haven't even had paperclip holes for a few years now... Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]Java Desktop System Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] mounted CDROMs and door locking
[ ... ] > Before MS Win did start to "support" this, it was the agreeed behavior: > > - Apple _and_ Sun did have a Floppy drive _without_ eject button. > > - CD-ROM drives did just copy this idea and allowed to make the > eject button to "diasppear" (being hidden). > > If you run a command line, you call "eject cdrom". > > If you use a gui, you just push the eject button on the gui. > > So where is your problem? "before" and "today". Habits change, and agreed behaviour changes... I might not like that, nor agree with the direction it's going in, but I can't deny it happening ... To be honest, I didn't even notice that Windows these days allows me to just push the button. My habit there was/is to use Eject from the context menu ... Anyway, Solaris needs two things for the key to "just work": a) vold reacting on the key press (I don't know right now what's happening internally when you press the eject button) b) hsfs forced umount support, for internal cleanup. If anyone's willing to work on b) as an OpenSolaris project, pls. contact me directly. FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] mounted CDROMs and door locking
Robert Lunnon wrote: On Monday 21 November 2005 06:07, Ian Collins wrote: Matt Ingenthron wrote: [snipped...] Agreed, but I think we do need better disaster recover with CD drives. Ian My users don't use the command line, they are fugitives from windows. They have common problems with the cdrom refusing to eject. It's hard to explain to a windows exile that the cd wont eject because there "Might be" a file open on it. In some other cases I've seen things get so confused that the CD returns an I/O error and no amount of eject commands will eject it. I've had to stop the volume manager, and eject it manually. You really cant expect a mere mortal to do these things, they need easy ways out of these things. I personally don't see why a read-only media can't be ejected like this, after all we live with floppies and other removable disks (eg flash drives) that Solaris just can't prevent you from removing. What makes CDs so different? . Besides, not being able to eject the CD with the eject button is counter-intuitive and in my book that just makes it plain wrong from a HMI design point of view. Agreed. I have faced similar issues. Though I am used to either typing eject or right-clicking on the cdrom icon on JDS and selecting eject, I feel that it is much more usable if the cdrom eject button behaved as it should. It is intuitive and much easier to just press a button rather than several keystrokes or mouse clicks. However forced unmount of filesystems in use can cause trouble. But at least it should unmount and eject if the cd is not being used by any app. Another thing would be to cause a popup with an explanatory message to appear if the cd cannot be ejected. Regards, Moinak. Bob ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] mounted CDROMs and door locking
On Sun, Nov 20, 2005 at 03:42:52PM +0100, Joerg Schilling wrote: > This practice is used since 1988 and before Microsoft and Linux did something > else, nobody complained. Linux doesn't allow to eject a CD in use. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] mounted CDROMs and door locking
Christoph Hellwig wrote: On Sun, Nov 20, 2005 at 03:42:52PM +0100, Joerg Schilling wrote: This practice is used since 1988 and before Microsoft and Linux did something else, nobody complained. It does. Just try a latest 2.6 kernel which has subfs. I works on SuSE 9.3. Regards, Moinak. Linux doesn't allow to eject a CD in use. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] mounted CDROMs and door locking
On Mon, Nov 21, 2005 at 07:36:25PM +0530, Moinak Ghosh wrote: > >>This practice is used since 1988 and before Microsoft and Linux did > >>something > >>else, nobody complained. > >> > >> > It does. Just try a latest 2.6 kernel which has subfs. I works on > SuSE 9.3. Then the suse folks patched your kernel. Standard linux behaviour for Linux is to lock the door on a cdrom once it's opened (from kernel or userspace). ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] mounted CDROMs and door locking
Christoph Hellwig wrote: On Mon, Nov 21, 2005 at 07:36:25PM +0530, Moinak Ghosh wrote: This practice is used since 1988 and before Microsoft and Linux did something else, nobody complained. It does. Just try a latest 2.6 kernel which has subfs. I works on SuSE 9.3. Then the suse folks patched your kernel. Standard linux behaviour for Linux is to lock the door on a cdrom once it's opened (from kernel or userspace). As I metioned before this behavior is provided with subfs/submount (http://sourceforge.net/projects/submount/) which is included in SuSE. Regards, Moinak. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] mounted CDROMs and door locking
On Mon, Nov 21, 2005 at 07:36:25PM +0530, Moinak Ghosh wrote: > It does. Just try a latest 2.6 kernel which has subfs. There's no subfs in a latest 2.6 kernel. I looked up what subfs is, and it's a stackable filesystem that is mounted to a mount pointed at boot time, and then mounts an underlying filesystem on access + a daemon that umounts it once it's unused again. I don't see that it uses any special care to unlock the door of a mounted cdrom, it just keeps it's usage time down. If you are really keen on this behaviour you could write a similar filesystem for solaris or try to trick autofs into this scenario. In general I'd advice against it because it's a really stupid idea. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: snv_b28 this week ?
ok, thanks. stefan This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] mounted CDROMs and door locking
Christoph Hellwig wrote: On Mon, Nov 21, 2005 at 07:36:25PM +0530, Moinak Ghosh wrote: It does. Just try a latest 2.6 kernel which has subfs. There's no subfs in a latest 2.6 kernel. I looked up what subfs is, and it's a stackable filesystem that is mounted to a mount pointed at boot time, and then mounts an underlying filesystem on access + a daemon that umounts it once it's unused again. I don't see that it uses any special care to unlock the door of a mounted cdrom, it just keeps it's usage time down. If you are really keen on this behaviour you could write a similar filesystem for solaris or try to trick autofs into this scenario. In general I'd advice against it because it's a really stupid idea. To do the auto-unmount on eject for Solaris would require changes to vold (See the other post by Frank Hoffman). But as you say unmount on unuse looks odd. Rather it should be unmount (if possible) on eject. Regards, Moinak. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why not to use pkgsrc package system ?
On Thu, 2005-11-17 at 21:50, Alan DuBoff wrote: > This is currently a problem with all of the distributions on > Solaris/OpenSolaris. Blastwave, pkgsrc, (I suspect) gentoo, sunfreeware, > etc...all build their own userland. GNU/OpenSolaris does the same in it's own > way. this is why I built my own (see http://www.openbios.org/~oxygene/projects/Projects/pmpkg ). I try to use existing libraries and programs where possible, and mostly succeeded so far - autotool's lack of support for non-gnu libintl/libiconv and qemu's issues with solaris' gcc are the two issues that require some duplication for the time being. otoh, I'm still facing some issues with build dependencies the others don't, because they can just require a package of their own, while I want more flexibility. patrick mauritz signature.asc Description: This is a digitally signed message part ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] mounted CDROMs and door locking
> > >To do the auto-unmount on eject for Solaris would require changes to > vold (See the other post >by Frank Hoffman). But as you say unmount on unuse looks odd. Rather > it should be unmount >(if possible) on eject. For HSFS it's of no special consequence. For filesystems that _write_ to the removeable media, it is - unmount-when-unused can make sure outstanding I/O buffers can be flushed properly, while unmount-on-eject might end up with an inconsistent medium even if the OS itself "cleans up". The filesystem driver can only clean up state that it controls ... and a forced unmount is exactly that, force cleanup of internal state regardless of what has happened to the storage ... fsflush & friends aren't 100% deterministic wrt. to when all in-core state changes will have ended on the medium. But then, for unmount-when-unused to work properly, mounts need to be quick. Which at least for PCFS, they're not. This piece needs some real work. In a way, unmount-when-unused is what autofs has always been doing. I know autofs' sourcecode is a beast, which probably explains why people haven't been extending it but instead created "workalikes" that deal with removeable media ... FrankH. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why not to use pkgsrc package system ?
On 11/21/05, Patrick Mauritz <[EMAIL PROTECTED]> wrote: > On Thu, 2005-11-17 at 21:50, Alan DuBoff wrote: > > This is currently a problem with all of the distributions on > > Solaris/OpenSolaris. Blastwave, pkgsrc, (I suspect) gentoo, sunfreeware, > > etc...all build their own userland. GNU/OpenSolaris does the same in it's > > own > > way. > this is why I built my own (see > http://www.openbios.org/~oxygene/projects/Projects/pmpkg ). I try to use from : http://www.openbios.org/~oxygene/projects/Projects/pmpkg . also, blastwave doesn't seem to deliver build scripts to package stuff yourself, and I couldn't find their patches to make things build on solaris either, so it's not really an open project A build system is being worked on that results in scripts and diffs being available also. As for not being "open". Just join. You can shell account and look around. How "closed" is that? Dennis ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] mounted CDROMs and door locking
Calum Benson <[EMAIL PROTECTED]> wrote: > > On 21 Nov 2005, at 12:28, Joerg Schilling wrote: > > > - Apple _and_ Sun did have a Floppy drive _without_ eject button. > > Apple still do this, FWIW... you won't find an eject button on a > Mac's CD/DVD drive. (Or its floppy drive, if you can still find one > of those.) They haven't even had paperclip holes for a few years now... And something that might have been forgotten these days: UNIX is a multi user system so it does not make sense to copy ideas from single user solutions like MS WIN. Why should the person who by chance sits in front of the CD-ROM be allowed to accidently eject a mounted CD-ROM that is currently used by another user that sits at the other side of the world logged in remotely? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] snv_b28 this week ?
Stefan Parvu wrote: Hey, Any ideas when build28 should be out ? This week ? Well, today's the deadline for us to integrate our packages into the build dock so they can start the build, but Thursday and Friday are holidays in the US, and many people are taking off early, so this one may take a couple days longer to get out the door. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Nexenta OS (elatte) Alpha 1 released 2005-11-18 mini-review
ref: http://www.gnusolaris.org/gswiki/Getting_Started Nexenta OS (elatte) Alpha 1 released I just spent a day reviewing a few trial loads of the latest release of Nexenta OS (elatte) Alpha 1 LIVE-CD. Oddly, it has taken up to an hour for the LIVE CD to get most of the desktop loaded on my two test machines (Compaq Presario S5000V and a custom Intel P4 2.5GHZ, 256MB RAM). I noticed that Nexenta doesn't provide the MGA_HAL driver for Matrox video card users. Now, the Knoppix 4.0.2 and older Gnoppix Live CD worked fine on both of my test machines and several older distros of Knoppix and other LIVE CDs/DVDs. Maybe some clues to 'streamline' Nexenta loading of the GNOME desktop, necessary apps, and better RAMDISK usage may help Nexenta on systems with less than 512 MB of RAM. The nice point about this release of Nexenta is the improvements to X and the additional network drivers. Also, over 90 bug fixes and several other issues were resolved. As far as languages and the sessions, I was only able to pick POSIX-C English and various GNOME sessions from the GDM. One of the best features is that you can load up Nexenta in Single user CLI mode and begin doing programming work immediately. This may be something worth reviewing for educational Unix programming and beginner classes. I'll try to review more of the Nexenta OS system inthe upcoming days as I upgrade the RAM in my test systems. ~Ken Mays __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: build 27a on x86 : panic at boot
Jürgen Keil wrote:
diskread: reading beyond end of ramdisk
start = 0x2000, size = 0x2000
failed to read superblock
I believe this is a new bug, introduced by the fix for:
6344611 create_ramdisk needs to react less poorly to missing files or
directories.
http://cvs.opensolaris.org/source/diff/on/usr/src/cmd/boot/scripts/create_ramdisk.ksh?r2=1.7&r1=1.6
Note how the test on line 99 tests for the existence of the wrong file; it is
missing the ${ALT_ROOT} file prefix. This breaks creating ramdisk boot archives
on a server for diskless clients. I guess it also breaks creating the ramdisk
boot
archive during CD/Network installation (because the install target HDD is
probably
mounted at "/a" and create_ramdisk is run with option "-R /a", and the getsize
shell function computes a bogus ramdisk size estimate - unless it is run from
the
"/a" directory).
I've filed the following bug on bugs.opensolaris.org
(Sorry, I've not yet got the CR / bug id):
6353553..
cheers,
steve
=
In snv_27 /boot/solaris/bin/create_ramdisk is badly broken, it cannot build
boot archives for a Solaris installation in an alternate root any more:
Example (diskless client):
# cd /tmp
# pwd
/tmp
# /export/root/moritz/boot/solaris/bin/create_ramdisk -R /export/root/moritz
Creating ram disk on /export/root/moritz
updating /export/root/moritz/platform/i86pc/boot_archive...this may take a
minute
Could not seek to offset -1 in /tmp/create_ramdisk.3228.tmp/rd.file: Invalid
argument
mount: I/O error
mount: Cannot mount /dev/lofi/1
umount: warning: /tmp/create_ramdisk.3228.tmp/rd.mount not in mnttab
umount: /tmp/create_ramdisk.3228.tmp/rd.mount not mounted
rmdir: directory "/tmp/create_ramdisk.3228.tmp/rd.mount": Directory not empty
Root cause: the getsize shell function in boot/solaris/bin/create_ramdisk
estimates a size of 0 KBytes for the ramdisk.
94 function getsize {
95 # Estimate image size, add %10 overhead for ufs stuff
96 total_size=0
97 for file in $filelist
98 do
99 if [ -e $file ] ; then
100 du -sk ${ALT_ROOT}/${file} | read size name
101 (( total_size += size ))
102 fi
103 done
104 (( total_size += total_size * 10 / 100 ))
105 }
Of cause the test at line 99 must test "${ALT_ROOT}/${file}", not "$file" !
Workaround:
===
run create_ramdisk with the current directory set to the alternate root
directory; with the example above:
# cd /export/root/moritz
# /export/root/moritz/boot/solaris/bin/create_ramdisk -R /export/root/moritz
Suggested Fix:
==
--- usr/src/cmd/boot/scripts/create_ramdisk.ksh~2005-11-14
22:11:41.0 +0100
+++ usr/src/cmd/boot/scripts/create_ramdisk.ksh 2005-11-19 20:32:19.401462000
+0100
@@ -96,7 +96,7 @@
total_size=0
for file in $filelist
do
- if [ -e $file ] ; then
+ if [ -e ${ALT_ROOT}/$file ] ; then
du -sk ${ALT_ROOT}/${file} | read size name
(( total_size += size ))
fi
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
--
stephen lau // [EMAIL PROTECTED] | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Nexenta OS (elatte) Alpha 1 released 2005-11-18 mini-review
Good review. Thanks ken! One little thing, Nexenta Alpha 1 comes with non-debug kernel which makes Nexenta perfect platform for performance investigations. Erast On Mon, 2005-11-21 at 09:06 -0800, ken mays wrote: > ref: http://www.gnusolaris.org/gswiki/Getting_Started > > > Nexenta OS (elatte) Alpha 1 released > > I just spent a day reviewing a few trial loads of the > latest release of Nexenta OS (elatte) Alpha 1 LIVE-CD. > > Oddly, it has taken up to an hour for the LIVE CD to > get most of the desktop loaded on my two test machines > (Compaq Presario S5000V and a custom Intel P4 2.5GHZ, > 256MB RAM). I noticed that Nexenta doesn't provide the > MGA_HAL driver for Matrox video card users. > > Now, the Knoppix 4.0.2 and older Gnoppix Live CD > worked fine on both of my test machines and several > older distros of Knoppix and other LIVE CDs/DVDs. > Maybe some clues to 'streamline' Nexenta loading of > the GNOME desktop, necessary apps, and better RAMDISK > usage may help Nexenta on systems with less than 512 > MB of RAM. > > The nice point about this release of Nexenta is the > improvements to X and the additional network drivers. > Also, over 90 bug fixes and several other issues were > resolved. > > As far as languages and the sessions, I was only able > to pick POSIX-C English and various GNOME sessions > from the GDM. > > One of the best features is that you can load up > Nexenta in Single user CLI mode and begin doing > programming work immediately. This may be something > worth reviewing for educational Unix programming and > beginner classes. > > I'll try to review more of the Nexenta OS system > inthe upcoming days as I upgrade the RAM in my test > systems. > > > ~Ken Mays > > > > > __ > Yahoo! FareChase: Search multiple travel sites in one click. > http://farechase.yahoo.com > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] snv_b28 this week ?
Stefan Parvu wrote: Hey, Any ideas when build28 should be out ? This week ? Thanks, Stefan This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org nope. i haven't even started yet. build 28 just hit WOS today, so i'll start the delivery today or tomorrow, but we have a holiday for Thanksgiving (thurs & fri), so most likely you'll see it next week. cheers, steve -- stephen lau // [EMAIL PROTECTED] | 650.786.0845 | http://whacked.net opensolaris // solaris kernel development ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: [approach-discuss] Re: ioctl SIOCGENADDR returns ENOENT
On the other hand, the ioctl is no more ugly than fishing the MAC from ARP. The ablilty to be able to retrieve MAC from down interfaces is nice and essential for some applications. But I suspect it's more commen for poeple to look for up interfaces instead. Please make the IOCTL work for non-root users. Linux, for example allows retrieving MAC without being root. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: ioctl SIOCGENADDR returns ENOENT
What's RFE? If it were a service request requires a software support contract with Sun, I'm affraid I can't get that; my employer has not purchase any software support in last several years. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why not to use pkgsrc package system ?
On Thu, 17 Nov 2005, Alan DuBoff wrote: > On Thursday 17 November 2005 05:58 am, Patrick Mauritz wrote: >> As for why not using pkgsrc, there are many things to consider: eg. that >> pkgsrc builds basically your whole userland again (at least the large >> chunks: yet another perl installation, yet another python, ..) > > This is currently a problem with all of the distributions on > Solaris/OpenSolaris. Blastwave, pkgsrc, (I suspect) gentoo, sunfreeware, > etc...all build their own userland. GNU/OpenSolaris does the same in it's own > way. Hmm, thinking about the above made this light-bulb come on: For each of the major Solaris ports systems, the target platform has been: a) Traditional (shipping) Sun Solaris releases: - pkgsrc - OpenPKG - TWW b) Explicitely _not_ Sun Solaris releases, but rather a Nevada-based distro (in a sense, the port system's target platform is itself): - SchilliX/SPS - Nexenta/Debian c) Both a) and b): - JDS/pkgbuild With this in mind, I'm thinking maybe SchilliX, Nexenta, and JDS won't suffer from the problem Alan sites above...? Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] snv_b28 this week ?
> Well, today's the deadline for us to integrate our > packages > into the build dock so they can start the build, but > Thursday > and Friday are holidays in the US, and many people > are taking > off early, so this one may take a couple days longer > to get > out the door. No worries, you guys have then a nice holiday. Im still reading ZFS... Stefan Parvu Blog: http://stefanparvu.blogspot.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] App porting forum?
On Mon, 14 Nov 2005, Erast Benson wrote: > Alfredo, > > One of the goals of GNU/OpenSolaris project is to track all changes and > bugs progress on porting/enhancing OSS projects... Erast, What would be _really_ cool would be to have a two-way flow between the Nexenta system and the JDS/pkgbuild one. In this scenario the following would happen for example: A JDS developer integrates a change to Xine into their ports collection (which is done by updating/testing the custom Xine spec file in the JDS build system), and the change automatically gets updated in the Nexenta build system too. And vice versa of course. Of course even cooler yet would be to have on a single standard format and master site for capturing porting specs and patches, and have all Solaris app porting developers contribute to and draw from it. Eric > > GNU/OpenSolaris web development portal provide Subversion hosting and > integrated Trac (Nexenta Bug Tracking System, i.e. NBTS) available for > HackZone developers. (one should aquire account first) > > Latests development will bring future Launchpad(a collection of services > for projects in the open source universe) integration, so any security > fixes released by Ubuntu, RedHat, Debian, Gentoo, etc will be > automatically tracked by NBTS and vice-versa. > https://launchpad.net/distros/nexenta > > GNU/OpenSolaris web portal provides read/write Subversion access for > "HackZone" interface. This interface is described at: > http://www.gnusolaris.org/gswiki/HackZone > > Bugs can be tracked/viewed at here: > http://www.gnusolaris.org/gswiki/Bugs > > HackZone forum: > http://www.gnusolaris.org/phpbb/viewforum.php?f=4 > > just an idea... > > Erast > > On Mon, 2005-11-14 at 16:31 -0300, Alfredo Pe?a wrote: >> Hi, >> I remember some talk about the creation of a application porting >> discussion forum. I can't find that list in >> http://www.opensolaris.org/os/discussions/ >> Is there plans to have that list? Is it ok to send app port questions to >> opensolaris-discuss meanwhile? >> Alf >> ___ >> opensolaris-discuss mailing list >> opensolaris-discuss@opensolaris.org >> > ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Nexenta OS (elatte) Alpha 1 released 2005-11-18 mini-review
Just a small update: After updating the Compaq Presario S5000V test machine to 512MB of RAM, this instantly fixed my loading problems with the latest Nexenta OS with zero major issues. The entire OS loaded from start to 'finish' within 10-15 minutes. A quick note on things I've noticed: GNOME 'about' reports version 2.12.0, distributor: GNU_Solaris, and a build date of 09/20/05. Yet, the release notes mention GNOME 2.12.1 is included. Several major GNOME desktop apps are still at 2.12.0 and only a few are at 2.12.1. So, a quick review of GNOME apps reveal: Gedit 2.12.0 File-roller 2.12.0 Evolution 2.3.7 Eog 2.12.1 GGV 2.12.0 Totem 1.2.0 Dict 2.12.0 Nautilus 2.12.0 gcalctool 5.6.31 Firefox 1.0.6 gnome-games 2.12.0 gstreamer 0.8.11 gucharmap 1.4.4 This can all be done with the simple: 'dpkg -l |more' or visual confirmation. I was a bit suprised that the bug reporting tool brought up Firefox instead of the reporting tool. This might have needed a last minute tweak. Now that the Nexenta OS loaded well on a 512MB RAM configuration, I can say that Nexenta is an excellent OpenSolaris distro with the GNOME 2.12.x based desktop environment. The whole system is very fast for each application loading from the CD and working from command line (i.e. terminal mode) is a breeze. The Compaq Presario S5000V seems to have no video problems with the basic setup. I did notice I didn't have sound working on the default setup in which I'll review later. A few things like Mesa-DRI (better hardware OpenGL accelerated drivers), includion of the Nvidia Solaris video driver, better sound device driver support, and a full refresh of GNOME 2.12.1/.2 as a default desktop will make this a stellar OpenSolaris distribution for professional game development, educational, and corporate environments. ~Ken Mays --- Erast Benson <[EMAIL PROTECTED]> wrote: > Good review. Thanks ken! > > One little thing, Nexenta Alpha 1 comes with > non-debug kernel which > makes Nexenta perfect platform for performance > investigations. > > Erast > > On Mon, 2005-11-21 at 09:06 -0800, ken mays wrote: > > ref: > http://www.gnusolaris.org/gswiki/Getting_Started > > > > > > Nexenta OS (elatte) Alpha 1 released > > > > I just spent a day reviewing a few trial loads of > the > > latest release of Nexenta OS (elatte) Alpha 1 > LIVE-CD. > > > > Oddly, it has taken up to an hour for the LIVE CD > to > > get most of the desktop loaded on my two test > machines > > (Compaq Presario S5000V and a custom Intel P4 > 2.5GHZ, > > 256MB RAM). I noticed that Nexenta doesn't provide > the > > MGA_HAL driver for Matrox video card users. > > > > Now, the Knoppix 4.0.2 and older Gnoppix Live CD > > worked fine on both of my test machines and > several > > older distros of Knoppix and other LIVE CDs/DVDs. > > Maybe some clues to 'streamline' Nexenta loading > of > > the GNOME desktop, necessary apps, and better > RAMDISK > > usage may help Nexenta on systems with less than > 512 > > MB of RAM. > > > > The nice point about this release of Nexenta is > the > > improvements to X and the additional network > drivers. > > Also, over 90 bug fixes and several other issues > were > > resolved. > > > > As far as languages and the sessions, I was only > able > > to pick POSIX-C English and various GNOME sessions > > from the GDM. > > > > One of the best features is that you can load up > > Nexenta in Single user CLI mode and begin doing > > programming work immediately. This may be > something > > worth reviewing for educational Unix programming > and > > beginner classes. > > > > I'll try to review more of the Nexenta OS system > > inthe upcoming days as I upgrade the RAM in my > test > > systems. > > > > > > ~Ken Mays > > > > > > > > > > __ > > Yahoo! FareChase: Search multiple travel sites in > one click. > > http://farechase.yahoo.com > > ___ > > opensolaris-discuss mailing list > > opensolaris-discuss@opensolaris.org > > > > __ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] SchilliX-0.3 ready
ftp://ftp.berlios.de/pub/schillix/ New software: Using Build 27a with zfs support. All needed libs now fully support 32 and 64 bit versions. - screen-4.0.2 - findutils-4.2.25 - cpp - samba-3.0.14a - lynx2-8-5 - zsh-4.2 - nail-11.22 - mutt-1.5.9 - ncftp-3.1.9 - ruby-1.8 - devpro-make-sccs-binaries - pkgutil - devpro-libm-bins-20051024 - Updated to star-1.5a70 with fixed -find bugs - Updated to a cdrecord with better support for ultra speed CD_RW media. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: ioctl SIOCGENADDR returns ENOENT
Shao Wu writes: > What's RFE? "Request For Enhancement" We subdivide Change Requests (CRs) into "bugs" (cases where the system does not work as it's been designed to) and "RFEs" (cases where the system doesn't do what's wanted). This is completely separate from priority. Things can have low or high priority without regard to whether they're actually bugs or RFEs. In this case, this is a feature that Solaris doesn't have. It could have it, but was never designed to. That makes the request an RFE. (It could reasonably be considered a bug *if* we'd committed to delivering the feature at some point and failed, but I don't see that this is the case here.) > If it were a service request requires a software support contract > with Sun, I'm affraid I can't get that; my employer has not purchase > any software support in last several years. I don't really know how the support contract issues work. My (obviously narrow) understanding, though, is that if you don't have a contract, you're limited to: public patches, new releases, Solaris Express, and Open Solaris. At least the last two of those will get you timely relief. Once an RFE (or bug) is in the database, the only thing that matters is whether there's someone willing to do the engineering work necessary. Motivators include having specific customers, especially those with cash in hand, though that's certainly not the only reason things get implemented. -- James Carlson, KISS Network<[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: [approach-discuss] Re: ioctl SIOCGENADDR returns ENOENT
Shao Wu writes: > On the other hand, the ioctl is no more ugly than fishing the MAC > from ARP. Right. Which you can already do with the existing ioctls. So, it's my suspicion that those asking for the feature either don't realize the limitations it'll have or don't care. I don't actually know which one it is. > The ablilty to be able to retrieve MAC from down interfaces is nice and > essential for some applications. But I suspect it's more commen for poeple to > look for up interfaces instead. > > Please make the IOCTL work for non-root users. Linux, for example > allows retrieving MAC without being root. The existing ioctls to do this via ARP should work for non-root users. -- James Carlson, KISS Network<[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Is 'forking' inevitable here too?
Erast Benson wrote: > Very good point and a right concern (to some degree) IMHO... > As J.S. mentioned before, in the future we should expect at least 2 > types of OpenSolaris-based distros: > > a) GNU-centric, those who trying to re-use GNU/Linux as much as possible > > b) Solaris-centric, those who trying to mimic Solaris as much as > possible > > But I'm hoping that both (a) and (b) will be *much more* compatable than > any two distros in GNU/Linux world. And the reason for my hope is that > we are using the same "Least Common Denominator"(LCD) - OpenSolaris(tm) > which is not just a kernel but userland too and developed under the > single roof. In my sense, LCD will preserve inter-distro compatability. > > The amount of OpenSolaris code that big that I really doubt it is > possible to successfuly fork OpenSolaris. Which is a good thing too. Yeah, with the rollout of OpenSolaris, Sun provided an open-source kernel, similar to what kernel.org does. But unlike kernel.org, the OpenSolaris base comprises lots of other core software too. In other words OpenSolaris is a really big least common denominator. (The internal project name for this part of Solaris is the OS/Net consolidation, commonly known as O/N.) So right off the bat, all distros are starting with the entire O/N consolidation, hopefully ensuring, as Erast points out, a relatively high degree of inter-distro compatability. FWIW, I wrote a little about this in a blog post a while back: http://blogs.sun.com/roller/page/eric_boutilier?anchor=solaris_opensolaris_standard_base And more recently Martin MC Brown wrote an opinion piece on this concept in a ComputerWorld article here: http://www.computerworld.com/softwaretopics/os/story/0,10801,105786,00.html Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] application porting forum?
Dan Price wrote: > On Thu 03 Nov 2005 at 07:39AM, Richard L. Hamilton wrote: > > Since I'm going to ask a question about some problems porting a > > particular app to [Open]Solaris (in another thread), it occurred to > > me: why not have a forum for that topic in general? The more apps run > > on [Open]Solaris, the better it is for everyone. Further, in some > > Richard, > > Kudos. I've been meaning to start such a community for some time now, > but have been too busy. > > I strongly agree with this idea, and I think it would be good to > investigate a multi-pronged approach: > > - Create a place for porters to ask and answer technical > questions. > > - Create a master "wish list" of open source apps we'd like to port: >- What the app is, what it does >- What needs porting (is it fine tuning? major functionality? > clean integration with SMF?... what's the issue?) >- Possible funding, bounties, etc. > > - Educational materials/articles about porting. > > - A list of identified problems with OS which are inhibiting > porting. > > - Porting challenges: In other words-- "December's challenge > to the group is to port Audacity" +1! ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] application porting forum?
On Sun, 2005-11-06 at 23:46 -0800, Dan Price wrote: > On Thu 03 Nov 2005 at 07:39AM, Richard L. Hamilton wrote: > > Since I'm going to ask a question about some problems porting a > > particular app to [Open]Solaris (in another thread), it occurred to > > me: why not have a forum for that topic in general? The more apps run > > on [Open]Solaris, the better it is for everyone. Further, in some > > Richard, > > Kudos. I've been meaning to start such a community for some time now, > but have been too busy. > > I strongly agree with this idea, and I think it would be good to > investigate a multi-pronged approach: > > - Create a place for porters to ask and answer technical > questions. [EMAIL PROTECTED] with integrated Trac. > - Create a master "wish list" of open source apps we'd like to port: >- What the app is, what it does [EMAIL PROTECTED] Also, HackZone, HackZoneTeams. >- What needs porting (is it fine tuning? major functionality? > clean integration with SMF?... what's the issue?) www.gnusolaris.org's Wiki and Bugs pages >- Possible funding, bounties, etc. www.gnusolaris.org/gswiki/Bugs integrated with https://launchpad.net/distros/nexenta Launchapd is distribution independent issue tracker. supports bounties and many other features. well founded. > - Educational materials/articles about porting. www.gnusolaris.org's Wiki > - A list of identified problems with OS which are inhibiting > porting. Again /Bugs or /Wiki > - Porting challenges: In other words-- "December's challenge > to the group is to port Audacity" > > Further thoughts? > > -dp My thoughts are: lets re-use what we have and make it better instead of reinventing the wheel again. All porting problems are generic and once porting is done, what do you do next with the package? Right... future upstream sync-ups and security bug fixes. This is where community interoperability is highly required. PS: Initial idea with www.gnusolaris.org was: Web portal for centralized porting efforts and *not* Nexenta specific. It integrates Wiki, Blogs, Forums, mailing lists, Subversion and Trac+Launchpad in single place sutable for Solaris developers. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] mounted CDROMs and door locking
Joerg Schilling wrote: Besides, not being able to eject the CD with the eject button is counter-intuitive and in my book that just makes it plain wrong from a HMI design point of view. Before MS Win did start to "support" this, it was the agreeed behavior: - Apple _and_ Sun did have a Floppy drive _without_ eject button. - CD-ROM drives did just copy this idea and allowed to make the eject button to "diasppear" (being hidden). If you run a command line, you call "eject cdrom". If you use a gui, you just push the eject button on the gui. So where is your problem? It's not the process that's broken, it's the fact that when it breaks down and the CD can't be ejected, the system can (and I haven't tried cdrecord -eject) require a reboot to get the CD drive to work again. Ian ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] App porting forum?
Alfredo Pe?a wrote: > Hi, > I remember some talk about the creation of a application porting > discussion forum. I can't find that list in > http://www.opensolaris.org/os/discussions/ > Is there plans to have that list? Is it ok to send app port questions to > opensolaris-discuss meanwhile? Posting here is probably not the best way to go. For app port question, you'll have much better luck posting to [EMAIL PROTECTED] because most (all?) of the Solaris GNOME/JDS and KDE porting folks are subscribed there. Also, because almost every major open source app that's been around for a while has been ported to Solaris by one or more of: Blastwave, Sunfreeware, or Companion CD, those communities are good places to look for guidance too. - If the app is on the Companion CD: the engineer who ported it might have documented useful porting info. This is done via a file called sfw.README in the source package. For more information and a link to a tar file of all the READMES, see: http://www.opensolaris.org/jive/message.jspa?messageID=8147#8147 - If the app is on sunfreeware.com, e-mail Steve Christensen for porting advice. - If the app is on Blastwave, click on the package name in the package list, and then click on "contact the maintainer". Also click on the maintainer's name -- sometimes you'll find additional porting information or pointers there. Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why not to use pkgsrc package system ?
On Mon, 2005-11-21 at 16:08, Dennis Clarke wrote: > A build system is being worked on that results in scripts and diffs > being available also. good to know! > As for not being "open". Just join. You can shell account and look > around. How "closed" is that? the "just join" part is what makes it closed. for pmpkg, just download the latest tarball, and apart from some local changes, which aren't stable/tested yet, you have it.. the most I could figure out - if I want that - is from what IP that download request came from. (and if you want, you can use monotone to track the tree, getting the latest changes, be able to branch&merge from it, all without an account here - though that's not a published fact at this time) even then blastwave still has the issue with rebuilding everything. otoh, the scope is broader, which is probably the main reason - I only care for solaris 10 and newer. patrick mauritz signature.asc Description: This is a digitally signed message part ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] mounted CDROMs and door locking
On Monday 21 November 2005 22:28, Joerg Schilling wrote: > Robert Lunnon <[EMAIL PROTECTED]> wrote: > > My users don't use the command line, they are fugitives from windows. > > They have common problems with the cdrom refusing to eject. It's hard to > > explain to a windows exile that the cd wont eject because there "Might > > be" a file open on it. In some other cases I've seen things get so > > confused that the CD returns an I/O error and no amount of eject commands > > will eject it. I've had to stop the volume manager, and eject it > > manually. You really cant expect a mere mortal to do these things, they > > need easy ways out of these things. > > > > I personally don't see why a read-only media can't be ejected like this, > > after all we live with floppies and other removable disks (eg flash > > drives) that Solaris just can't prevent you from removing. What makes CDs > > so different? . > > Besides, not being able to eject the CD with the eject button is > > counter-intuitive and in my book that just makes it plain wrong from a > > HMI design point of view. > > Before MS Win did start to "support" this, it was the agreeed behavior: > > - Apple _and_ Sun did have a Floppy drive _without_ eject button. > > - CD-ROM drives did just copy this idea and allowed to make the > eject button to "diasppear" (being hidden). > > If you run a command line, you call "eject cdrom". > > If you use a gui, you just push the eject button on the gui. > > So where is your problem? Because it doesn't always work and when it doesn't work there is no way to know WHY. If it could be made bulletproof, I'd concede it'd be OK but it is far from bulletproof. This would include a notification on the console when someone tries to eject a busy CD. Bob ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why not to use pkgsrc package system ?
On 11/21/05, Patrick Mauritz <[EMAIL PROTECTED]> wrote: > On Mon, 2005-11-21 at 16:08, Dennis Clarke wrote: > > A build system is being worked on that results in scripts and diffs > > being available also. > good to know! > > > As for not being "open". Just join. You can shell account and look > > around. How "closed" is that? > the "just join" part is what makes it closed. oh ? > for pmpkg, just download the latest tarball, Well I guess I need to figure out how to get a subversion server up and running as well as a few other things. I'll have a look around and see what I have on hand. The idea is to make everything public but there is little added value. Simply putting the diffs out doesn't do anything for the quality or supply of the software packages. We would have to go back and get all 1290 packages into the system and then get the diffs and scripts exposed and .. what? Downloadable such that you can build it all on your own system? Is that the magic bullet that makes for an "open source" project ? Truth is .. I don't know. I would think that having it all open is a good first step and then move forward from there. The nice thing is that the pkg tools are now avail in a binary redistributible form and that makes it a lot easier to install a SVR4 type package. All of the SUNW dependencies are the next hurdle as well as the package database. Dennis ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why not to use pkgsrc package system ?
On Monday 21 November 2005 06:37 am, Patrick Mauritz wrote: > On Thu, 2005-11-17 at 21:50, Alan DuBoff wrote: > > This is currently a problem with all of the distributions on > > Solaris/OpenSolaris. Blastwave, pkgsrc, (I suspect) gentoo, sunfreeware, > > etc...all build their own userland. GNU/OpenSolaris does the same in it's > > own way. > > this is why I built my own Right. But ultimately if we want to really work together, it would be nice if we had a common set of libraries that everyone could use, and so that we shouldn't have so many sets of libs floating around our directories. The fact that you build your own only exemplifies that point, IMO. -- Alan DuBoff - Sun Microsystems Solaris x86 Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why not to use pkgsrc package system ?
On Monday 21 November 2005 10:25 am, Eric Boutilier wrote: > With this in mind, I'm thinking maybe SchilliX, Nexenta, and JDS won't > suffer from the problem Alan sites above...? The key will be in getting the core libs into a common location. The more that is built, the more libs are required, when those all become "their own" so to speak is when we have problems. In theory we should be able to have a common set of libs for all to use. In the rare case that a package needs an off version to run, then they should add their own, but only in special cases and the goal should be for all to bring it back to the common libs when possible. -- Alan DuBoff - Sun Microsystems Solaris x86 Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] SchilliX-0.3 ready
And available at: http://www.genunix.org/distributions/schillix/schillix-0.3/index.html Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED] Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] OpenSolaris ports attributes Wiki
Using a Jotspot wiki, I put together an OpenSolaris ports attributes table: http://peetie.jot.com/OpenSolarisPortsAttributes The objective is to make this a reference document that provides a comparative perspective with an emphasis on impartiality, completeness, and accuracy, Please advise of corrections and improvements. Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why not to use pkgsrc package system ?
Alan DuBoff <[EMAIL PROTECTED]> wrote: > On Monday 21 November 2005 06:37 am, Patrick Mauritz wrote: > > On Thu, 2005-11-17 at 21:50, Alan DuBoff wrote: > > > This is currently a problem with all of the distributions on > > > Solaris/OpenSolaris. Blastwave, pkgsrc, (I suspect) gentoo, sunfreeware, > > > etc...all build their own userland. GNU/OpenSolaris does the same in it's > > > own way. > > > > this is why I built my own > > Right. But ultimately if we want to really work together, it would be nice if > we had a common set of libraries that everyone could use, and so that we > shouldn't have so many sets of libs floating around our directories. I am not sure if a cooperation with a Debain oriented Solaris distribution would be feasable. I expect just too many incompatibilities. I am not shure whether the belenix people are interested in a cooperation... I did see paralleles in the basic ideas of SchilliX and Blastwave quite some time ago and I found the main problem with Blastwave that it is closed source and using an fixed install path (/opt/csw) that is not compatible with an OpenSolaris distribution like SchilliX that does not need to put things beneath Sun Solaris but to replace missing software from Sun Solaris. This is why I started to write the SPS system in hope to be able to use the know how from the Blastwave packages later. Note that there is a big difference between patching a piece of software for Debian or doing the same for Solaris. Debian people don't care whether a patch breaks this on any OS but Linux. A package created for Linux does not need to work on Solaris at all. Well, the result is that about a month ago, I realized that SchilliX and Blastwave need to cooperate because Blastwave is the only source of packages that take special care of the needs on Solaris and because SchilliX likes to be as close to Sun Solaris as possible. As it seems that Dennis is also interested, we now need to convince the Blastwave maintainers ;-) Just a note at the end: If there is not enough information from the people who created a ported piece of software, it is in many cases better to do the port again and by yourself :-( In order to share things there need to be a feeling of openness. It would help a lot of Sun did have opened the build system that is used to compile the Open Source software found on Sun Solaris. Unfortunately Sun did not and it took me a lot of time to e.g. compile the Netscape libraries and libxml2 correct enough. Nobody from the community did ask me about my efforts and it seems that the other distros prefer a simple aproach instead asking me for my knoe how and in return sharing their know how. The fact that Sun did not open those things that in theory _are_ Opensource already was a real skid. Looking back the time I was working on SchilliX makes it obvious that about 80% of the time, I was working on things that in theory should be OpenSourcer already and well documented. I see no quick way out of these problems. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why not to use pkgsrc package system ?
Alan DuBoff <[EMAIL PROTECTED]> wrote: > On Monday 21 November 2005 10:25 am, Eric Boutilier wrote: > > With this in mind, I'm thinking maybe SchilliX, Nexenta, and JDS won't > > suffer from the problem Alan sites above...? > > The key will be in getting the core libs into a common location. The more > that > is built, the more libs are required, when those all become "their own" so to > speak is when we have problems. A lot of things are already available available in the SPS. I may need to update the files on the server but the fact that there is a lot to do for SchilliX does not leave me the time Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Boot issues with prebuit OpenSolaris
Is this the right place to discuss boot/install issues with the prebuilt distro's? Lots of trouble with snv_27a. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why not to use pkgsrc package system ?
On Mon, 2005-11-21 at 15:23, Alan DuBoff wrote: > On Monday 21 November 2005 06:37 am, Patrick Mauritz wrote: > > On Thu, 2005-11-17 at 21:50, Alan DuBoff wrote: > > > This is currently a problem with all of the distributions on > > > Solaris/OpenSolaris. Blastwave, pkgsrc, (I suspect) gentoo, sunfreeware, > > > etc...all build their own userland. GNU/OpenSolaris does the same in it's > > > own way. > > > > this is why I built my own > > Right. But ultimately if we want to really work together, it would be nice if > we had a common set of libraries that everyone could use, and so that we > shouldn't have so many sets of libs floating around our directories. Isn't that what Sun branded Solaris(tm) is all about? OpenSolaris is about doing your own thing, tweaking that one thing that's bugged you for years. Consistency in distros could possibly be a laudable goal, but I certainly don't expect it, nor do I personally want it. Sun really like Burger King these days, and with these new distros coming out, we've got the salad bar from hell to go with it, one with lots of goodies and ideas to choose from. I can have it my way. Once we've got bootable CF, that is :) John ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: snv_b28 this week ?
does 28 integrate Xorg 6.9/7.0? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Boot issues with prebuit OpenSolaris
Bruce Riddle <[EMAIL PROTECTED]> wrote: > Is this the right place to discuss boot/install > issues with the prebuilt distro's? > > Lots of trouble with snv_27a. I don't understand, I has no problems with SchilliX so far Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: snv_b28 this week ?
Robert Dickel wrote: does 28 integrate Xorg 6.9/7.0? 6.9 RC2 - I've updated the X changelogs to include the changes delivered in the packages we integrated today: http://opensolaris.org/os/community/x_win/changelogs/changelogs-nv_20/ -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why not to use pkgsrc package system ?
On Tue, 2005-11-22 at 00:29 +0100, Joerg Schilling wrote: > Alan DuBoff <[EMAIL PROTECTED]> wrote: > > > On Monday 21 November 2005 06:37 am, Patrick Mauritz wrote: > > > On Thu, 2005-11-17 at 21:50, Alan DuBoff wrote: > > > > This is currently a problem with all of the distributions on > > > > Solaris/OpenSolaris. Blastwave, pkgsrc, (I suspect) gentoo, sunfreeware, > > > > etc...all build their own userland. GNU/OpenSolaris does the same in > > > > it's > > > > own way. > > > > > > this is why I built my own > > > > Right. But ultimately if we want to really work together, it would be nice > > if > > we had a common set of libraries that everyone could use, and so that we > > shouldn't have so many sets of libs floating around our directories. > > I am not sure if a cooperation with a Debain oriented Solaris distribution > would > be feasable. I expect just too many incompatibilities. To some degree. Why not? Also putting too much in OSOL LCD(OpenSolaris least common denominator) will break distribution's individuality. So, please lets be careful here. Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Boot issues with prebuit OpenSolaris
Joerg Schilling wrote: Bruce Riddle <[EMAIL PROTECTED]> wrote: Is this the right place to discuss boot/install issues with the prebuilt distro's? Lots of trouble with snv_27a. I don't understand, I has no problems with SchilliX so far Well I haven't tried to install your distro, on a particular machine. Right now I'm struggling with snv_27a, It appears similar problems with b24, on this same machine. The install hangs just after displaying the install menu. Now this is the new boot architecture. I thought I was down the right path for modifying my jumpstart environment cp /js/11_x86_27/Solaris_11/Tools/Boot/x86.miniroot /tmp/x86.miniroot.gz cd /tmp gzipd -d x86.miniroot.gz lofiadm -a /tmp/x86.miniroot mount /dev/lofi/1 /mnt # make any changes. # in my case I modified /mnt/etc/bootrc, yet it had no impact. cd / umount /mnt lofiadm -d /dev/lofi/1 cd /tmp gzip x86.miniroot cp x86.miniroot.gz /js/11_x86_27/Solaris_11/Tools/Boot/x86.miniroot However the script bootrc doesn't seem to do the install. Anybody know which script actually controlls the install menu? The one that presents: 1. Solaris Interactive (default) 2. Custom JumpStart 3. 4 5 6. Single user shell I can't seem to snoop it out because of (ramdisk?) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: snv_b28 this week ?
I'd like to see any information of the QA testing of Xscreensaver 4.23 and Xorg 6.9 RC2. Has things stabilized? Ref: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6343352 ~Ken --- Alan Coopersmith <[EMAIL PROTECTED]> wrote: > Robert Dickel wrote: > > does 28 integrate Xorg 6.9/7.0? > > 6.9 RC2 - I've updated the X changelogs to include > the changes > delivered in the packages we integrated today: > > http://opensolaris.org/os/community/x_win/changelogs/changelogs-nv_20/ > > -- > -Alan Coopersmith- > [EMAIL PROTECTED] >Sun Microsystems, Inc. - X Window System > Engineering > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Boot issues with prebuit OpenSolaris
On Monday 21 November 2005 05:12 pm, Bruce Riddle wrote: > Well I haven't tried to install your distro, on a particular machine. > Right now I'm struggling with snv_27a, It appears similar problems with > b24, on this same machine. Quite a few ACPI changes went in between 20-23, as I recall. Some laptops that would install have problems now. For the most part, more hardware works though. I have only seen problems on the Toshiba M2, which previous needed to have the PC Card set to PCIC Compatible, and if that is set now Solaris reboots on the install just after the kernel banner. I haven't debugged that. > However the script bootrc doesn't seem to do the install. > Anybody know which script actually controlls the install menu? Jan is the person that probably knows. -- Alan DuBoff - Sun Microsystems Solaris x86 Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: snv_b28 this week ?
Xorg 6.9RC2 seems to be stable - QA found only one issue which was quickly fixed and included in this build. (Bug 6351399 listed in the changelog.) Xscreensaver 4.23 isn't ready for QA yet - at the moment I'm trying to figure out if I can get away with integrating the hacks (aka display modules) from 4.23 without having to upgrade the entire package, since the people working on the xscreensaver daemon/lock code are too busy on other work to merge the whole thing in right now. (The hacks we ship unmodified, but the main daemon/lock screen code is heavily modified and will be much harder to merge.) I've hijacked recently filed bug 6351570 for this purpose, since otherwise it would have been closed as a dup of long-open RFE 4802301 (though I've updated it to reflect new releases a few times since it was filed). -alan- ken mays wrote: I'd like to see any information of the QA testing of Xscreensaver 4.23 and Xorg 6.9 RC2. Has things stabilized? Ref: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6343352 ~Ken --- Alan Coopersmith <[EMAIL PROTECTED]> wrote: Robert Dickel wrote: does 28 integrate Xorg 6.9/7.0? 6.9 RC2 - I've updated the X changelogs to include the changes delivered in the packages we integrated today: http://opensolaris.org/os/community/x_win/changelogs/changelogs-nv_20/ -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why not to use pkgsrc package system ?
On 11/21/05, Alan DuBoff <[EMAIL PROTECTED]> wrote: > On Monday 21 November 2005 06:37 am, Patrick Mauritz wrote: > > On Thu, 2005-11-17 at 21:50, Alan DuBoff wrote: > > > This is currently a problem with all of the distributions on > > > Solaris/OpenSolaris. Blastwave, pkgsrc, (I suspect) gentoo, sunfreeware, > > > etc...all build their own userland. GNU/OpenSolaris does the same in it's > > > own way. > > > > this is why I built my own > > Right. But ultimately if we want to really work together, it would be nice if > we had a common set of libraries that everyone could use, and so that we > shouldn't have so many sets of libs floating around our directories. > > The fact that you build your own only exemplifies that point, IMO. i agree 100% with Alan on this. with one notable exception, i have seen very little in terms of "working together", although it's been several months since the idea was brought up. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why not to use pkgsrc package system ?
Stefan Teleman wrote: On 11/21/05, Alan DuBoff <[EMAIL PROTECTED]> wrote: [snipped...] Right. But ultimately if we want to really work together, it would be nice if we had a common set of libraries that everyone could use, and so that we shouldn't have so many sets of libs floating around our directories. The fact that you build your own only exemplifies that point, IMO. i agree 100% with Alan on this. with one notable exception, i have seen very little in terms of "working together", although it's been several months since the idea was brought up. One of the reasons I see for this proliferation is that each repository expresses dependencies at the package level tying it to a certain naming convention. Thus even though Blastwave and Sunfreeware standardize on SVR4 packaging, they have different name prefixes. IMHO a few things are required here: * A way to express dependency at the software and version level. For example depends on gtk 1.5 rather than something like CSWgtk1. This way any package that provides gtk 1.5 and is available on the path should suffice. RPM already has this via it's provides and requires clauses. * But the above also requires a standard naming convention for the provides and requires clauses. Package names can still be different. * A way to handle dependency conflicts. What if 2 apps require different versions of Gtk 2.x ? Portage has a slot mechanism to handle this case. I haven't yet looked at it in much detail so cannot comment more. This would necessitate some minor duplication only where there is a conflict. Regards, Moinak. --Stefan -- Stefan Teleman [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Why not to use pkgsrc package system ?
Erast Benson wrote: Also putting too much in OSOL LCD(OpenSolaris least common denominator) will break distribution's individuality. So, please lets be careful here. Then maybe there needs to be another distribution. Solaris LCD. Or maybe, when installing software, you would check for common libraries before installing missing libraries. The installer should look at certain directories, then revision level of the libraries. If it uses a different library, ask if permissible. Anything to start reducing the amount of libraries would be helpful. At least, just start trying to get this task done. I've got another idea. Why not use an environment variable such as: LCD=/usr/lib:/usr/sfw/lib:/usr/local/lib Where during software installation, if the library isn't found in the LCD path, it installs its specific library. If the LCD variable isn't present, software installs as usual, just building up libraries. Paul ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
