00:02:43 <dangergrrl> anyway i have an actual practical question
00:09:45 <dangergrrl> should i tar /code/illumos-gate? or just use git diff and patch to restore my wip?
00:10:05 <rmustacc> Are both systems up at the same time?
00:12:48 <dangergrrl> yes
00:13:10 <dangergrrl> but they aren't connected because i'm bad at vbox
00:13:32 <dangergrrl> so i'm using windows as an intermediate
00:14:26 <dangergrrl> i know i can forward the vbox ssh port but i didn't want to bother...
00:15:20 <rmustacc> Well, the simplest thing would be to just use git to clone things to the intermediate states.
00:15:34 <dangergrrl> my current vbox machine has an until now totally unused hdd that i made a zfs on
00:15:49 <dangergrrl> i don't have any idea how to do that
00:15:55 <rmustacc> If you use other methods, I would ensure that you have removed all built artifacts.
00:16:32 <rmustacc> So you know how you used git clone to get the source code originally? You can do the same thing, but just ask for it at the place you actually have it.
00:16:57 <dangergrrl> i didn't make a fork :(
00:17:23 <rmustacc> I'm not sure what you mean there.
00:17:24 <dangergrrl> that would have made stuff easier
00:17:37 <rmustacc> The github 'fork' concept doesn't have anything to do with whether you can do this or not.
00:17:44 <dangergrrl> I'm working off the main tree
00:17:47 <dangergrrl> oh, ok
00:18:08 <rmustacc> You can just still push all that to a branch of your own on gitub if you want.
00:18:20 <rmustacc> But again, not required for any of what I've described.
00:18:54 <rmustacc> But practically speaking, do whatever you're most comfortable with.
00:19:06 <rmustacc> That is more likely to lead to your success.
00:19:07 <dangergrrl> i understand unix code but just not really git
00:19:59 <dangergrrl> cvs rcs and whatever odd filesystem based thing we used at SCO are more familiar to me
00:20:13 <rmustacc> My point is, using tools you know is going to more likely be successful than trying to teach git over irc.
00:20:28 <dangergrrl> lol, okay
00:20:32 <rmustacc> So if that's creating patch files and moving them, do that. If that's tar, use that.
00:20:48 <dangergrrl> i think i could use git diff and patch would work
00:21:08 <rmustacc> You can use git format-patch, git am, git apply, etc.
00:21:11 <rmustacc> You don't need to use patch.
00:21:24 <dangergrrl> lol
00:21:38 <rmustacc> I just mean, git has additional tools for it if you want to use them.
00:21:46 <dangergrrl> I'm old, I love Larry Wall.... :P
00:22:11 <rmustacc> OK, well, good luck.
00:22:19 <dangergrrl> thanks
00:22:52 <dangergrrl> i just don't want to lose my work and i really need the hardware
00:23:28 <dangergrrl> I'm just not happy enough with it to submit to code review yet
00:26:08 <dangergrrl> saving my homedir took 48G, I'm hoping for less for my dev tree since my changes are more like 1k
00:27:18 <dangergrrl> how to push my changes to git without making a pull request?
00:28:45 <rmustacc> When you say 'to git', do you mean github?
00:28:54 <dangergrrl> yes
00:29:06 <rmustacc> You can push or pull to any repository that exists. It doesn't have to be on github.
00:29:14 <dangergrrl> i'm going to nuke that machine
00:29:22 <rmustacc> If you want to use github you must 'fork' illumos-gate on github.
00:29:29 <dangergrrl> i want to save my work
00:29:31 <rmustacc> And then you can add it as a remote and push to a branch.
00:29:37 <dangergrrl> that't what i thought
00:29:59 <rmustacc> I understand what you are doing and the destructive nature. Just trying to say that the git remote can be anything. It doesn't have to be github.
00:30:09 <dangergrrl> but i didn't do that
00:30:13 <rmustacc> For example, I push between a server and a laptop frequently.
00:30:18 <rmustacc> It doesn't matter how it started.
00:30:36 <dangergrrl> i can fork now?
00:30:44 <rmustacc> Forking is not a git concept.
00:30:56 <rmustacc> git has a notion of what it calls remotes.
00:31:08 <rmustacc> You can push to any remote and add and remove them at any time.
00:31:53 <dangergrrl> i just don't want to lose my rather limited work
00:32:22 <dangergrrl> if i can do that with a git command please help
00:32:47 <dangergrrl> i just git push?
00:38:43 <dangergrrl> okay, i don't have a sshe key with github.org
00:38:49 <dangergrrl> ssh
00:39:05 <rmustacc> How many commits is your work?
00:39:28 <dangergrrl> just the one i am working on
00:39:51 <dangergrrl> it's pretty simple you could do it in your sleep
00:39:54 <rmustacc> OK, so there is a single commit in git log and if you've made multiple, you've squashed them.
00:40:30 <dangergrrl> so i need to submit an ssh key?
00:40:33 <rmustacc> Then just run 'git format-patch HEAD~1' and take that patch file off box and mail it to yourself.
00:40:46 <dangergrrl> danke
00:40:56 <rmustacc> Or whatever you do to preserve files.
00:41:35 <dangergrrl> fatal: ambiguous argument 'HEAD-1': unknown revision or path not in the working tree.
00:42:25 <dangergrrl> I'm trying not to be stupid but i admit i am older
00:43:00 <rmustacc> Did you use the ~ (tilde) character like I used?
00:43:17 <rmustacc> Or did you use the - (minus, hyphen) like you copied above.
00:43:28 <dangergrrl> aha
00:44:32 <dangergrrl> ahathat was fast, where did it put the file?
00:44:51 <rmustacc> It listed the name of it on output.
00:44:51 <dangergrrl> aha, in .
00:46:32 <dangergrrl> so i can rebuild my tree from that?
00:47:19 <rmustacc> You can use patch like you said you're familiar with to apply it. At this point it should be like everything else you already know.
00:48:14 <dangergrrl> ty
00:49:32 <dangergrrl> my changes are just to yacc to make it use modern interfaces to create temp files
00:49:56 <dangergrrl> very minor but i wanted to save my machine, ty
01:08:03 <danmcd> @pmooney your refactoring makes the LX/brand changes even harder to do than I'd thought.  I'm going to suggest a diff at your end first.
01:08:28 <pmooney> ok
01:32:42 <danmcd> https://github.com/TritonDataCenter/illumos-joyent/pull/432/commits/f88477e83720579537fb431cb752e519b7f2f621
01:32:48 <danmcd> pmooney: ^^^
01:40:49 <danmcd> Scratch that link, try this one instead... https://github.com/TritonDataCenter/illumos-joyent/pull/432/commits/d01b52b65792285745d5550ff23d45be98c9caf1
01:41:11 <danmcd> typo, did the whole reset-and-force-push-to-branch.
01:47:34 <danmcd> And it actually builds now.
01:49:27 <danmcd> And the aforementioned patch will drop nicely into your `il14892` branch pmooney.
16:36:59 <toasterson> richlowe: tsoome_  Some diff alternative worth mentioning is https://github.com/Wilfred/difftastic/ it's syntax based diff also for C based on tree-sitter
16:41:27 <dangergrrl> hi toasterson ! :) i have only barely tried OI as a desktop and noticed it's still using the abandoned by upstream compiz (which I loved but it's not maintained upsteam anymore)
16:42:17 <dangergrrl> I just used my box as a server and dual gpu laptop which i didn't deign to fix the issues so console/network only
16:43:24 <dangergrrl> if someone wrote a better defect report than I can, I might try working with it but I'm stuck in a vm for now
16:44:17 <dangergrrl> the X server can't find the firmware that it needs
16:44:36 <dangergrrl> it would be a nice thing to fix
16:47:44 <dangergrrl> btw, /tmp living in RAM seems like a great idea but zfs actually handles this much better and it led to a RAM exhaustion where I could not log on
16:48:36 <dangergrrl> I don't have any of the error messages left, I had to reboot to use the system, perhaps the're in my logfiles
16:51:46 <dangergrrl> at least some of you wrote zfs, you should just trust it
16:53:19 <rmustacc> You can set a size on the /tmp mount point to limit it.
16:53:44 <rmustacc> One can both trust zfs and not want to eat wear on an ssd.
16:55:06 <dangergrrl> I had to reboot my system to login and that's not good either
16:55:32 <dangergrrl> i didn't have an active shell so i could not delete the offending file
16:55:36 <rmustacc> I didn't say it was good.
16:55:53 <rmustacc> I even provided a suggestion to try and limit future problems.
16:56:45 <dangergrrl> you should never have to reboot! my system had an uptime of 227 days! :)
16:57:10 <rmustacc> You will always have to reboot to update the kernel.
16:57:19 <dangergrrl> that part is true
16:57:27 <rmustacc> But one shouldn't because of issues.
16:57:42 <tsoome_> but... but... ksplices!
16:58:20 <dangergrrl> runtime of years is the main thing *nix has over windows
16:58:56 <dangergrrl> yes, you can run a web server on windows, it has to reboot weekly
16:59:25 <jbk> tsoome_: amusingly, solaris had a similar feature _years_ before linux did, but it never really made it out of i guess beta.. IIRC, it could only be done by a sun support engineer (which I suspect was working with someone else on the backend)
17:00:20 <tsoome_> yep, I know:)
17:01:15 <dangergrrl> but like IIS will serve www content, not as well as nginx or apache but it's main defect is that windows servers have low uptimes
17:01:37 <toasterson> dangergrrl: Compiz is still the thing that gives the most bang for the buck the people want. but default should be marco IIRC. Alas I am not happy with an DE really so I haven't really loocked recently.
17:02:28 <dangergrrl> toasterson, my only complaint about compiz is that it's not maintained upstream
17:02:39 <toasterson> Bumblee or optimus setups are not supported by the graphics drivers available and not even really work on linux. The main graphics card is the one that counts
17:02:43 <dangergrrl> I love the he** outta it
17:13:01 <dangergrrl> does the cube even still work?
17:13:46 <dangergrrl> is this project providing bugfixes for compiz?
17:14:24 <dangergrrl> yes, the newer maintained stuff isn't nearly as pretty as compiz
17:16:00 <dangergrrl> unless you want illumos to *be* the upstream for it i don't think you should use it but that's just imo
17:21:33 <dangergrrl> it won't get bugfixes ever again
17:21:48 <dangergrrl> and it surely still has defects
17:23:20 <dangergrrl> like it's the best UI I've ever used but someone has to keep it clean
17:24:25 <rmustacc> I think your point is understood. Note that this isn't part of illumos. I would encourage you to engage with the folks dealing with it more directly.
17:25:16 <dangergrrl> rmustacc, that's OI?  it's hard to tell where one ends and the other begins
17:25:52 <dangergrrl> illumos-gate includes a lot of things I wouldn't expect
17:26:34 <rmustacc> It will be with whatever distro you're using that packaged and provided compiz.
17:27:39 <dangergrrl> I'm using OI and I love it but I have the illumos-gate tree cloned and was just to lazy to do a find on it to search
17:27:51 <dangergrrl> sorry
18:28:01 <hpqoeu> hi, how would i go about checking out a coredump from a linux binary in an lx zone, in the global zone?
18:30:04 <rmustacc> So when we dump cores from an lx binary, it is generaly in an illumos-based format so you'll need to use mdb.
18:30:16 <danmcd> cd /zones/<zonename>/root/in/zone/path/to/core  then mdb.
18:30:30 <rmustacc> So in the lx zone, you would do something like /native/usr/bin/mdb <core>.
18:30:53 <rmustacc> However, if the incoming linux programs are striped or don't have frame pointers, there will not be as much we can do.
18:33:35 <tsoome_> Since there is 1-1 relation with issue and gerrit id, I guess, the followup to issue is not encouraged?
18:34:18 <hpqoeu> I just get "mdb: failed to dereference symbol: unknown symbol name" trying to load the core file
18:34:30 <tsoome_> I managed to produce a small bug with update, would like to fix it:D
18:36:04 <hpqoeu> copying the core file over vs running it where it was created should make no difference, right? cause i've ran it in both the zone and as a user in the global zone, and i get the same error
18:37:50 <jbk> i don't know if it'd be useful to pick back up and finish, but I did start adding support for .eh_frame stack traces to libproc (as new functions so they can act as an alternate if frame pointers aren't working)
18:38:13 <jbk> based on the work that someone ( rmustacc? ) did back at joyent
18:41:18 <hpqoeu> sorry, not trying to load the core file, but when it's actually loaded in mdb
18:42:06 <hpqoeu> the binary producing the core dump isn't stripped according to file so i assume this should help
19:36:24 <jbk> danmcd: do you know offhand how a conn_t behaves if the interface it was using to send traffic goes away (but the routing table still has a way to reach the destination)?
19:37:33 <danmcd> It should continue to work. There may be some updates when the next datagram out discovers things new.  (generation numbers may get updated, e.g.)
19:37:46 <danmcd> In a meeting so I can't source-dive to give a better answer right now.
19:37:53 <jbk> e.g. imagine if0 192.168.0.10/24, if2 10.10.0.20/24, route 0.0.0.0/0 -> 10.10.0.1, and now you have a tcp connection to 192.168.0.20, but if0 goes away
19:37:57 <jbk> ok
19:39:08 <danmcd> Hang on...
19:39:14 <danmcd> Meeting just finished.
19:41:46 <jbk> conn_t's are used for UDP as well, right?
19:42:11 <danmcd> Yes, and I'm STILL pissed off 15+years later about that piss-poor naming decision.
19:42:41 <danmcd> So when you say "if0 goes away" do you mean "ifconfig if0 down" or "ifconfig if0 unplumb"?
19:43:20 <danmcd> The former will go through ipif_down() in $UTS/common/inet/ip/ip_if.c
19:43:34 <danmcd> The latter will go through ill_delete() in the same source file.
19:44:24 <jbk> unplumb
19:44:28 <jbk> insterestingly
19:44:42 <jbk> imagine ifconfig if0 unplumb
19:44:55 <jbk> netstat -an still shows established connection w/ src of if0 ip
19:45:01 <danmcd> Well, ill_delete() should clean everyting up, including deleting the attached ipifs.
19:45:38 <danmcd> AHHH, source address selection... yeah, that might be a reason for an ipif to not disappear.  Once you bind to a local address it's bound.  You'll probably get errors on subsequent data transmission.
19:45:51 <jbk> could it impact _other_ connections?
19:45:56 <jbk> or UDP
19:45:59 <jbk> (say DNS)
19:46:11 <danmcd> If source address isn't frozen, the right thing should happen.
19:46:36 <danmcd> An easy test is to do pings to (in your example) 192.168.0.20 and the source address SHOULD change.
19:47:03 <danmcd> (and snoop the pings at the destination.
19:47:41 <danmcd> If the destination sees source address for the now-unplumbed NIC responses will never reach upstack past IP.
19:48:30 <danmcd> If you call connect() on UDP the source address will be caches on the conn_t for that UDP session.
19:49:04 <danmcd> (It's why UDP apps that don't wish to be source-address-specific should always use sendto/sendmsg without binding anything beyond port.)
19:49:57 <danmcd> Sorry for the verbosity.  Does this help?
19:55:37 <jbk> maybe
19:56:31 <jbk> though this does seem like a bug
19:56:46 <jbk> so using my scenario above
19:57:01 <jbk> create TCP connection, host picks if0 for source IP
19:57:05 <jbk> if0 unplumb
19:57:17 <jbk> so source IP no longer exists
19:57:24 <jbk> but if you pfiles process
19:57:28 <jbk> socket is still there
19:57:40 <rmustacc> Well the socket will continue to exist.
19:57:45 <jbk> with now gone IP address
19:58:13 <danmcd> Correct.
19:58:15 <rmustacc> I mean, with tcp you have that 5-tuple and called connect().
19:58:18 <danmcd> You bound it, you own it.
19:58:20 <rmustacc> Why wouldn't it?
19:58:24 <danmcd> ^^^
19:59:39 <jbk> yeah, unless the app isn't noticing things -- i would imagine trying to do anything on that socket should fail at that point
19:59:57 <danmcd> I SUPPOSE one could mark sockets to return EADDRNOTAVAIL if they're bound locally to an address that no longer exists...
20:00:47 <danmcd> But one of the beauties of TCP/IP is that sometimes addrs disappear and then reappear, and in those cases you really want to NOT have your TCP connection get disrupted.
20:01:08 <jbk> i mean if the source IP no longer exists, you can no longer (at minimum) receive any replies
20:01:26 <danmcd> Yep, and then for TCP the connection times out.
20:04:38 <rmustacc> But also if you're idle and have long timeouts (like one might want for ssh), then you can actually suspend a laptop and resume it and not lose your connection.
20:15:59 <jclulow> A locally attached IP might disappear but you might then start getting routed packets arriving through another link
20:16:14 <jclulow> I wonder what we would do in that case
20:16:32 <jclulow> I guess you'd have to put the IP up on the loopback or whatever instead to be eligible to receive them
20:16:33 <jbk> though at that point, ARP has probably timed out
20:17:03 <jbk> i'd imagine once we unplumb the interface, we'd stop responding
20:17:08 <jbk> to arp requests for that IP
20:45:39 <danmcd> jbk correct re: arp.
20:46:19 <danmcd> jclulow you're describing some of the things Mobile IP tried to work out back in the 90s. (MobileIP was full of too many cooks in the IETF.)
20:46:57 <danmcd> jclulow: also you could put local IP on lo0 OR as a /32 addr assigned to an existing nic.  You might need to deal with strict-multihoming for lo0, e.g.
20:47:11 <jclulow> Mmm
20:47:24 <jclulow> We used to use lo0 aliases at the University for direct server return load balancing 
20:54:09 <danmcd> Most IP stacks ship strict-destination-multihoming OFF (or loose-destination-multihoming ON, depending on what angle you're looking at).
21:03:04 <tsoome> .oO oradb-rg          oraakel2       No             Pending_offline
21:03:50 <tsoome> live migrating the RG;)
22:59:51 <gitomat> [illumos-gate] 15285 ucb: remove pragma ident -- Toomas Soome <tsoome⊙mc>
23:07:29 <gitomat> [illumos-gate] 15309 zfs_acl_chmod_aclmode_001_pos is failing (fix add_file permission) -- Toomas Soome <tsoome⊙mc>