16:04:58 vim adds most/all of the baggage old-timey vi folks said made emacs so annoying. Given my two-tool workflow (vi for tiny things, emacs for big things), modern vim makes me wonder sometimes if I should just go all-emacs. Thanks @m1ari about shift-click. Also I wonder if I should create a .vimrc that has disable-all-of-this-shit in it? (I think we ship vim-as-vi in SmartOS with it disabled already, but not all d 16:04:58 istros do.) 16:26:04 danmcd, My .vimrc disables a lot of the vim BS. 16:26:10 I just want vi, tyvm. 16:27:22 "let skip_defaults_vim=1" has a place in all of mine, certainly. I /do/ want some vim niceties though - multi undo/redo, visual select to name two. Don't want fancy mouse integration and what have you though. 16:28:24 Otherwise I'd be running /usr/has/bin/vi :D 16:33:58 I don't mind the non-intrusive improvements, TBH. 16:45:01 I just made a copy of vimrc in my .vim and edited it to disable this mouse bit;) 16:49:21 boomer alert boomer alert.... Helix Editor is the only way now! Emacs vs Vim vs Helix !!!! papertigers got me h00ked 16:52:34 :D 16:53:26 I like vi because of edit mode, so random "cat" on keyboard will not leave garbage in text;) 17:34:15 [illumos-gate] 17166 fs.d: variable dereferenced before check -- Toomas Soome 17:52:40 [illumos-gate] 17175 SMF service log could be more helpful on exec failure -- Andy Fiddaman 19:15:15 I'm trying to bridge a gap in knowledge. I'm trying to bridge a gap between sourcing the packages resulting from building illumos-gate (as per the 'Building illumos' webpage), and using the distro constructor to use those packages in order to build a system. So far, I have compiled illumos-gate, and the build was successful. I set up an IPS package 19:15:15 repository on a local server to act as the host for the packages. I'd like to use the distro constructor tool provided by OpenIndiana in order to create a simple distro from this local repository server which contains the freshly built packages. It looks like those freshly built packages reside in a pkgrepo built by the illumos build, on the build 19:15:16 server under /PATH/illumos-gate/packages/i386/nightly/repo.redist/. My doubt is about how to get the freshly built packages from the build server onto the local repository server. I've considered using the base pkg* tools, and also noticed that the bld tools have rich features. What is the idiomatic way of transferring the IPS packages out of the 19:15:16 build server pkgrepo and onto the local repository server pkgrepo? *I'm new to this. I did read the man pages for pkgrepo, pkgrecv, pkg.depotd, and the pages for building OpenIndiana and OmniOS. I haven't found material relevant enough to find an answer, despite tinkering with the tools myself 19:17:09 Guest88 pkgrecv 19:17:22 Guest88: I use pkgrecv followed by pkgrepo refresh 19:39:34 I'm not sure if it's undocumented, or if I've missed the documentation; aside from the pkgrepo that the illumos-gate build creates, I'm having a doubt about the pkg/server instance. I tried using pkgrecv to connect to LOCALSERVERIP:80 (appears to be the default port for the pkg/server:default instance per the docs) and the connection fails. It does 19:39:34 succeed on a an instance of pkg/server which I've configured using a different port. So far, I've assumed that the illumos-gate build is only creating a pkgrepo and not a pkg/server instance. To confirm, is it intended that the user configures a pkg/server service instance in order to serve the freshly built packages via http? 19:40:50 I use something like: pkgrecv -s ${BUILDREPO} -d ${PUBREPO} -k '*' 19:40:58 where $BUILDREPO and $PUBREPO are filesystem paths 19:41:19 the transfer does not involve a running package server. 19:47:00 sommerfeld: What does the -k do?! 19:48:07 Guest88: yes, the build does not start a depotd 19:48:37 jclulow: looks like something that's a noop that I don't actually need. 19:48:47 haha alright 19:48:51 "Keep the retrieved package content compressed. This option is 19:48:51 ignored when republishing." 19:49:07 Ah 19:50:35 Guest88: It's possible to have a tool that stands up a temporary depot, as well; e.g., when we work on Helios, "helios-build onu -D ..." will start a temporary depot: https://github.com/oxidecomputer/helios/blob/6f70a2d0ac0dd1cd4770e572051ba364029292ff/tools/helios-build/src/main.rs#L906-L966 19:51:00 sommerfeld Thank you 19:55:21 jclulow I checked out the link. Noted, that's interesting, thank you 19:58:45 Suppose that I created /pkg/repo1/ and initialize a pkgrepo there. Now, I change my mind and want to remove the pkgrepo on /pkg/repo1/. How do I delete it? I didn't find a 'remove' or variant subcommand in the man pages 20:01:26 It's a self-contained directory tree. Just delete it in your favorite way (rm -r or the like). 20:04:57 you obviously have used zfs create to make dataset for it and when you do not need it any more, you just zfs destroy it;) 20:10:33 if you have the repo configured with pkg(8), it should deal with the actual repository changing underneath it 20:11:00 there is also `pkg unset-publisher` which is a _really_ confusing name for it in retrospect. 20:12:32 What makes it confusing? (asking in order to learn, not being snooty) 20:14:03 Well, the verb for doing that is often "remove" 20:14:27 I'm not sure why it ended up with set-publisher/unset-publisher, rather than add/set/remove 20:19:26 Oh, got it now. It would seem more consistent using add/set/remove for sure 20:20:11 richlowe: I think part of the problem is that really a publisher is a top-level thing, and then there are origins and underneath, etc 20:20:47 So the single-level taxonomy and using options to sort of dodge around that is a source of confusion