Anyone run illumos as a main desktop os?

Blake, depends on what you mean, kinda. I use OpenIndiana as a desktop OS but I only use that machine for OI/Illumos development and cross platform development work.

I can't speak to it's suitability for other uses

I have a strong preference for self hosted development and I prefer to use emacs on X11 so...

:O

I'm having some trouble figuring out what's going wrong with pkgrecv. I'm trying to do; [pkgrecv -s ${NIGHTLY_REPO} -d ${SHARE_REPO} '*'], clearly in order to receive the freshly built packages to the sharing repo hosted locally. Upon running that command, there is output describing the processing of the packages and the retrieving and evaluating

of 551 packages. I've refreshed the share repo, and afterwards run [pkgrepo -s ${SHARE_REPO} info]. There are 0 packages in the share repo. I looked through the relevant man pages. What could be causing this?

Well, I'm having a bit more trouble with trying to serve the on-nightly packages (I was here yesterday asking about setting up a pkgrepo). I'm trying to copy the packages from on-nightly (<i>$PKG_SRC</i>) into a separate, local package repository for sharing the packages (<i>$PKG_DEST</i>). I'm using <i>pkgrecv -s $PKG_SRC -d $PKG_DEST '*'</i> to

try to transfer the packages between the repos. The processing, retrieving, and evaluation phases seem to succeed without issue; yet, upon checking <i>$PKG_DEST</i> via <i>pkgrepo -s $PKG_DEST info</i>, there is a newly made <i>PUBLISHER: $PKG_SRC</i> entry alongside <i>PUBLISHER: $PKG_DEST</i>. Surprising to me, the entry for PKG_SRC has 551

packages, while the entry for PKG_DEST has 0 packages... I haven't found documentation covering why this is -- I had been under the impression that pkgrecv would transfer the packages from $PKG_SRC to $PKG_DEST, thereby populating the destination repository with the same packages contained within the source repository; this obviously isn't the

case. Is this supposed to be happening? And how is it intended to transfer these packages?

Guest88: "pkgrecv" also has a "-v" flag for verbose output about what it's doing, and a "-n" flag for a dry run; i.e., telling you what it would do without doing it

You can also use "pkgrepo list -s $repo" to see all the packages and versions in a particular repository

(i.e., not just the count but the actual packages and their versions)

There is also "pkgrepo diff -v -s $src -s $dst" which can show you the difference between two repos

Should hopefully get you more information about what's going on

If you can make up a gist or a pastebin with the full terminal output of what you're doing, including the commands you run and their output, it might be a bit easier to see where you're going astray

I tried using the -v and it hasn't provided additional info. The output appears to remain the same as without the -v option. I'm scratching my head because I set up a pkgrepo at /pkg1, then did pkgrecv -s /PATH/TO/ON-NIGHTLYREPO -d /pkg1. /pkg1 shows an entry for the 'on-nightly' publisher with all the packages, but 'localpkg' publisher that I am

trying to receive the packages still has 0 packages after the transfer. I read through the OmniOS man pages for pkgrecv again and haven't found what's gone wrong. (using OI for the build/repo server)

Ok, I'll prepare a pastebin

danmcd: an interesting thing we ran into: The limitations on characters allowed in network interface names

danmcd: (as opposed to device names). It seems it's alnum+_

but the ARC case that documented it never was published

and I'm not sure if it got _documented_ in general?

sommerfeld: maybe a thing you remember too?

It's documented in dladm.

If you look at the manual page and the definition of link (search for datalink as a first hit) it'll describe the limitations.

ah ha!

that was far from apparent when michael tried to rename the broadcom genet drivegr

Uh oh. What happened?

The implicit restriction on drivers is that they can't end in a number.

Because we need to append the instance number.

that's a network-specific restruction, too

the specific confusion here was that we tried to use the name of the hardware, `bcm...-genet`

to disambigate the driver name

and that dash is a killer

and then we couldn't find where that was written down (it's a network-specific limitation), which you showed us. It'd be nice to know why

pastebin.com/2qmSWU8P   Here are the commands which I've run. I am trying to transfer the packages from PUBLISHER on-nightly into PUBLISHER localrepo. Perhaps I've misunderstood -- I was under the impression that pkgrecv would transfer the 551 packages from on-nightly *to* localrepo, as in making copies of the packages. I intend to serve

these packages on localrepo, by using a svc instance to make them available to other local servers via http

I suppose that my confusion is centered around not expecting PUBLISHER on-nightly to be present in /repo/pkg, and for PUBLISHER localrepo to contain 551 packages instead of 0

LIFNAMSIZ == 32, IFNAMSIZ == 16 .

$UTS/common/sys/if.h

the "struct ifreq" and its IPv6-inspired successor "struct lifreq".

ifreq goes way back to 4BSD, maybe earlier.

@richlowe ^^^ , pardon latency, been distracted today.

oh, maybe over-length too. But the "-" being so fatal was still a surprise.

jclulow Hello, not wanting to bother you if you're busy, but wanted to mention that I sent that pastebin link (in case it was buried above)

I checked through a copy of the OpenSolaris Bible and Sun's Solaris 10 System Administration Essentials in the meantime and neither mentioned pkgrepo/pkgrecv

pkgrepo/pkgrecv weren't in Solaris 10 - S10 only had the ancient SVR4 package system, not IPS

Noted, thanks. I'm still coming up to speed with the history