02:15:06 Anyone run illumos as a main desktop os? 02:28:05 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. 02:28:29 I can't speak to it's suitability for other uses 02:30:25 I have a strong preference for self hosted development and I prefer to use emacs on X11 so... 02:30:53 :O 02:52:37 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 02:52:38 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? 19:03:17 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 ($PKG_SRC) into a separate, local package repository for sharing the packages ($PKG_DEST). I'm using pkgrecv -s $PKG_SRC -d $PKG_DEST '*' to 19:03:18 try to transfer the packages between the repos. The processing, retrieving, and evaluation phases seem to succeed without issue; yet, upon checking $PKG_DEST via pkgrepo -s $PKG_DEST info, there is a newly made PUBLISHER: $PKG_SRC entry alongside PUBLISHER: $PKG_DEST. Surprising to me, the entry for PKG_SRC has 551 19:03:18 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 19:03:19 case. Is this supposed to be happening? And how is it intended to transfer these packages? 20:57:00 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 20:57:36 You can also use "pkgrepo list -s $repo" to see all the packages and versions in a particular repository 20:57:51 (i.e., not just the count but the actual packages and their versions) 20:58:13 There is also "pkgrepo diff -v -s $src -s $dst" which can show you the difference between two repos 20:58:26 Should hopefully get you more information about what's going on 20:58:55 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 21:03:36 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 21:03:36 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) 21:04:07 Ok, I'll prepare a pastebin 21:04:45 danmcd: an interesting thing we ran into: The limitations on characters allowed in network interface names 21:05:09 danmcd: (as opposed to device names). It seems it's alnum+_ 21:05:16 but the ARC case that documented it never was published 21:05:27 and I'm not sure if it got _documented_ in general? 21:05:58 sommerfeld: maybe a thing you remember too? 21:06:04 It's documented in dladm. 21:06:32 If you look at the manual page and the definition of link (search for datalink as a first hit) it'll describe the limitations. 21:06:46 ah ha! 21:07:12 that was far from apparent when michael tried to rename the broadcom genet drivegr 21:07:32 Uh oh. What happened? 21:07:44 The implicit restriction on drivers is that they can't end in a number. 21:07:52 Because we need to append the instance number. 21:08:07 that's a network-specific restruction, too 21:08:25 the specific confusion here was that we tried to use the name of the hardware, `bcm...-genet` 21:08:31 to disambigate the driver name 21:08:35 and that dash is a killer 21:09:23 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 21:23:41 https://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 21:23:41 these packages on localrepo, by using a svc instance to make them available to other local servers via http 21:24:51 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 22:11:16 LIFNAMSIZ == 32, IFNAMSIZ == 16 . 22:11:26 $UTS/common/sys/if.h 22:11:45 the "struct ifreq" and its IPv6-inspired successor "struct lifreq". 22:12:07 ifreq goes way back to 4BSD, maybe earlier. 22:12:21 @richlowe ^^^ , pardon latency, been distracted today. 22:13:05 oh, maybe over-length too. But the "-" being so fatal was still a surprise. 23:17:13 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) 23:21:18 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 23:24:42 pkgrepo/pkgrecv weren't in Solaris 10 - S10 only had the ancient SVR4 package system, not IPS 23:29:38 Noted, thanks. I'm still coming up to speed with the history