01:13:54 jclulow: I looked at moving section 8 to be before section 1, but that program is a C file, and it's got some *weird* preferences in there about decisions it makes. 01:14:10 Or, before 1B, rather. 01:14:10 oh? 01:14:22 Yeah. 01:14:31 I mean I wrote it, so, happy to answer any questions haha 01:15:56 It was *not* clear to me at all how I could establish that preference. 01:16:14 Ah 01:16:15 Dan looked at it with me and he couldn't figure it out either. 01:16:35 haha 01:16:39 I have created a puzzle 01:16:44 one sec I'll make a diff 01:16:48 I have a jira for it, let me see if I wrote down what stumped us 01:18:07 OS-8436 01:18:07 https://smartos.org/bugview/OS-8436 01:18:17 Looks like I didn't... 01:20:54 OK, this was my attempt though: https://github.com/TritonDataCenter/smartos-live/compare/master...OS-8436 01:21:31 Yeah based on my comment it's still going to put 1B before 8, sigh 01:21:39 Yeah. 01:21:47 Ok, a new program then!! 01:21:50 one moment 01:23:55 It was one of those things where I didn't know why *this* program in particular, or *this* behavior. I considered just outright replacing it with a static list, but I didn't feel like I understood why it works the way it does before I started mucking around in there. 01:25:46 can you gist a $MANIFEST file 01:26:05 so that I don't have to do a build haha 01:26:33 I think so. 01:26:42 It might be a bit stale, but not terribly so. 01:27:16 that's ok 01:27:23 as long as it's post manual renumbering 01:27:40 So, man/manifest, yeah? 01:28:07 err 01:28:16 probably the final altogether one 01:28:29 like the thing that has everything that we give to builder 01:28:32 assuming we still do that 01:30:12 The reason it's a program rather than a static file FWIW is that it needs to be a complete list, or man(1) will silently ignore the missing (sub)sections and I didn't want people to have to notice new sections showing up later 01:32:07 Is this what you're looking for? https://github.com/TritonDataCenter/smartos-live/blob/master/src/manifest 01:33:21 oh, I guess it's called manifest.gen? https://github.com/TritonDataCenter/smartos-live/blob/master/Makefile#L72 01:33:24 that one 01:33:48 It's what we pass in to mancf: https://github.com/TritonDataCenter/smartos-live/blob/master/Makefile#L406-L408 01:33:51 OK, that's the generated one 01:33:58 yeah 01:34:36 https://gist.github.com/bahamat/3aa123aa49cf80131413e95ab963b6c0 01:34:51 tah! 01:40:37 Ok, chatgrep to the rescue, yet again. Basically, I did the commit, we realized it didn't work and then were like how tf does this even work anyway? and then yeah, discovering that subsections get stacked with the section period, realized that it wasn't straightforward. 01:41:22 But something else that I didn't get was that after my change the order was unchanged *at all*. 01:42:16 It didn't do 1,1c,1b,8,2, even though section 8 had a lower priority.. 01:42:30 It was still 7,8,9. 01:44:40 But then after re-reading it, I would expect it to be 1m,1,1b, and 3socket,3c,3,4, but that's not the case on those either. 01:45:02 The main section is *always* first, and ordering seems to only affect subsections. 01:47:06 I thought about trying to make a pseudo 1.8 section that was all symlinks to section 8 to fool the search order, but then when displayed it would still look like section 8, but I figured that was too much of a hack. 03:23:35 MANSECTS=1,1c,8,1b,2,3,3c,3avl,3bsm,3c_db,3cfgadm,3commputil,3contract,3cpc,3curses,3dat,3devid,3devinfo,3dlpi,3dns_sd,3elf,3exacct,3ext,3fcoe,3fstyp,3gen,3gss,3jedec,3kstat,3kvm,3ldap,3lgrp,3lib,3m,3mail,3malloc,3mp,3mpapi,3mvec,3nsl,3nvpair,3ofmt,3pam,3papi,3picl,3picltree,3pool,3proc,3project,3resolv,3rpc,3rsm,3sasl,3scf,3sec,3secdb,3sip,3socket,3head,3stmf,3sysevent,3tecla,3utempter,3uuid,3vnd 03:23:38 ,3volmgt,3x11,3xau,3xaw,3xcurses,3xext,3xmu,3xnet,4,4d,4fs,4i,4ipp,4m,4p,5,5b,7,9,9e,9f,9p,9s, 03:23:42 that looks right I think 03:33:42 bahamat: https://github.com/TritonDataCenter/smartos-live/pull/1103 03:34:20 Awesome 03:34:45 I'll work on getting that merged tomorrow. 03:39:27 huy: You've probably got something either in an image or a vm that the web ui isn't able to parse properly. If you have any images that you obtained from a source other than images.smartos.org, that's a likely culprit. If not, then it's probably an instance. 04:14:56 bahamat: I would like to ask a question regarding how to re-compile uuid.node, there is my log, not sure if could help to take a look? https://pastebin.com/7eyAU9mJ how to fix the uuid.node ? 04:53:58 tozhu: That doesn't look like it's something we built. 04:56:14 tozhu: But it seems pretty straightforward that you've got a 64-bit thing trying to dynamically link with a 32-bit thing. 04:56:25 Make both of them the same bitness and that should resolve your issue. 04:57:12 node-libuuid (which is what it looks like you're using? But I'm not entirely sure), seems to support both 32 and 64-bit. So it should just be a matter of passing the right flags to it. 04:57:49 But neither node-libuuid nor rdsagent comes from us, so I'm not the best person to ask. 05:19:08 yes, it was we built 05:19:35 bahamat, may I know how to you build it? 05:19:55 just run ‘npm build’ ? 05:50:55 bahamat: Thank you for your answer 05:51:22 may I know how to you compile the uuid.node? 05:52:16 I don't. 05:54:08 There are some places where we use it (https://hound.tritondatacenter.com/?q=libuuid&i=nope&files=package.json&repos=), but there's literally no special handling for it. Just `npm install` 05:54:42 okay, thank you very much 05:57:53 bahamat: does it matter if it’s running or not ? 05:58:52 huy: No, it reads the JSON so that it can report the vm properties. 06:00:05 An easier way to narrow it down without having to destroy them is to comment them out of /etc/zones/index and see if the ui has a better time of it. 06:01:12 If you can figure out which one(s) cause the error then we can almost certainly figure out what it is getting tripped up on. 06:04:31 It’s probably a docker image I’ve been trying in the past 06:05:27 Well, like I said, if you can identify it, we can fix it. 09:40:28 bahamat: it was a bhyve instance but I just deleted it, can't tell what was causing the problem sorry 11:40:16 hello all, where could get the correct signature? I hit error like this: https://pastebin.com/YxcZNz0q 11:41:16 tozhu: what set are you upgrading from and to? 11:42:22 I have upgrade from 2021Q4 to trunk 11:42:59 ok, if you follow the "Standard (upgrade)" instructions at https://pkgsrc.smartos.org/install-on-illumos/ it should work 11:43:04 followup the guide on https://pkgsrc.smartos.org/install-on-illumos/ 11:44:24 last week, it works; but today, my colleagur, set the URL to 2023Q4, did pkgin up 11:44:38 then all things don’t work 11:45:30 so, I don’t know hot fix it, 11:47:57 you can't just update the URL, you need the upgrade kit as that contains the new pgp key 11:48:52 you can either use the trunk upgrade kit and then fixup the URLs, or use https://pkgsrc.smartos.org/packages/SmartOS/bootstrap-upgrade/bootstrap-2023Q4-x86_64-upgrade.tar.gz 11:49:23 okay, thank you very much 11:49:28 I’ll try 11:49:40 I don't publish the LTS upgrade kits on the website as it would complicate things and it's rare that someone would want to use them, but they're all there if you want to just browse around 11:50:02 if I build everything from source, the bootstrap and its tool is been built automatically? 11:50:48 if you want to bootstrap everything yourself then you wouldn't use any of the kits, though you would need at least a compiler from somewhere 11:51:18 is there some docs to guide? 11:52:24 I wan’t mirror a pkgsrc, seems the software can by synced, but the bootstrap is a link, can’t be sync-ed 11:52:52 there's the pkgsrc guide at http://netbsd.org/docs/pkgsrc/ 11:53:05 jperkin, Thank you very much for the answer, Thank you 11:53:21 shouldn't be any links, they're just regular files? 11:54:36 also 99% of the stuff I've written is up at https://github.com/TritonDataCenter/pkgbuild so you can reuse any of that 11:55:29 no, I just curl on the machine to get the bootstrapxxx.gz file that I use rsync from pkgsrc.smartos.org the file is only 2k, but I use broswer to get the file, then it’s a big file 11:56:34 yes, I have read that, it’s real usful 11:57:26 have you complete the docs that guide how to build all package in parall? :-) 11:57:48 the sizes via rsync look ok to me, e.g. 11:57:53 $ rsync rsync://pkgsrc.smartos.org/pkgsrc/packages/SmartOS/bootstrap/bootstrap-trunk-x86_64-20240116.tar.gz 11:57:56 -rw-r--r-- 18202492 2024/01/16 10:33:23 bootstrap-trunk-x86_64-20240116.tar.gz 11:58:40 okay, I’ll change my command option, currently I use ‘rsync -avP’ 11:59:24 jperkin, Thank you very much for the great help 11:59:26 for bulk building I use pbulk, there are some docs and all the scripts I use are in the pkgbuild repo, but I would caveat that with it being quite sensitive to changes so if you want to set up your own environment it's probably worth learning from my stuff but implementing your own so you will know where to look if things go wrong 12:00:06 I can't publish 100% because a lot of my builds use custom NFS mounts etc, so there will always be a certain amount of local configuration required 12:01:13 okay, got it, thank you very much 12:20:38 in my spare time I've been working on a better tool to handle all of this stuff, but it's quite a big project and I don't have a huge amount of spare time ;) 13:01:43 got it 13:02:10 so, can I help you to do something? jperkin :-) 13:06:55 I don't have anything public yet, other than the backend lib I wrote a few years back (https://github.com/jperkin/pkgsrc-rs), but will be happy to share once I have a baseline I'm reasonably happy with 16:05:21 jperkin: what’s the issue, is there any problem with CDN system? https://pastebin.com/bmEKYPQ2 16:06:03 the file is only 3260 byte 16:11:17 yes, that's correct 16:11:32 the upgrade kits are just new config files and a pgp keyring 16:13:23 okay, thank you