Hide Idle (>14 d.) Chans


← 2020-02-03 | 2020-02-05 →
whaack: diana_coman: EOD Report: I did my daily writing (which went a bit overtime), 2h of setting up comp, and then 6h of saltmines. The 2h of setting up comp was well spent, I continued my study of the commands jfw had mentioned. After I gained some more knowledge it was easy to diagnose and fix my problem - my comp is now connected.
ossabot: Logged on 2020-01-24 16:36:30 jfw: whaack: I suspect you've got some basics to learn here too. ifconfig and route commands, DHCP
jfw: diana_coman: I've published notes in leau of a summary article today. Would you rather I finish that tomorrow or move on?
jfw: The following log days were shorter so on the first pass reading side I'm all caught up.
jfw: whaack: nice to hear, did you figure out if it was realtak driver problem or what?
jfw will be back on the morrow.
diana_coman: whaack: so what was the problem anyway?
diana_coman: http://logs.ossasepia.com/log/ossasepia/2020-02-04#1017152 - jfw, up to you really; fwiw notes were funny to read so I won't complain either way, not like they are not clear for me or anything of the sort, lol.
ossabot: Logged on 2020-02-04 02:38:48 jfw: diana_coman: I've published notes in leau of a summary article today. Would you rather I finish that tomorrow or move on?
whaack: diana_coman: The first problem is that the standard NIC by all appearances cannot send packets. I solved this by using a spare ethernet<->usb adapter. Then once I was using "eth1' instead of 'eth0' I could not connect because my routes table did not have the 'default' set to my router's ip address.
whaack: diana_coman: Now that I have a connection I'll download gcc and compile the other driver for my network card and see if I can connect without using the ethernet<->usb adapter. If not then likely there is a problem with the hardware.
diana_coman: whaack: ahaha, your "I solved this" is "I worked around that", did you even notice?
whaack: diana_coman: lol I missed that I used that wording just now.
diana_coman: yeah, not a distinction to which you are used to pay much attention, that's why; that's why I highlighted it too, because you should pay attention to it specifically and to this sort of differences more generally: it can be fine to choose a workaround instead of a solution in some cases but it's *never* fine to call things something other than they actually are.
whaack: diana_coman: understood. I know it is a workaround but the language I employed shows that on some level I see 'workarounds' and 'solutions' as interchangeable. I'll take care to make the distinction.
whaack: diana_coman: the real funny bit is i originally typed "I know it is a temporary solution but the..."
whaack: (atm it looks like it's going to be a permanent work around)
diana_coman: there is no such thing as a "temporary solution" and it's still not a solution
diana_coman: and yeah, the curse of "temporary" is that it ~always ends up permanent
whaack: diana_coman: do you have a specific type of article you'd like me to write for The Odyssey?
diana_coman: whaack: hm, what do you *want* to write now you read it?
whaack: diana_coman: the first topic that comes to mind is something to do with the ethics of honesty, which would discuss how Odysseus occasionally makes up these long elaborate lies. Sometimes his deceitfulness seems prudent (i.e. when he's trying to keep his disguise while setting up his slaughter of the suitors)..sometimes it seems he's lying for sport (when he reunites with his father at first he pretends to be someone else for no rea
whaack: son clear to me)
diana_coman: whaack: ha, if you do a full blown analysis of deceitfulness @ Greeks, that would be quite something, lol
diana_coman: can do a phd thesis out of the topic, I dare say (though yes, obv, not based on the odyssey alone, how could that ever be)
whaack: lol, well I don't kid myself that I can do a great job on the topic, especially with a 3hr writing limit.
diana_coman: whaack: so pick something that fits the time better or otherwise work on it more
whaack: diana_coman: btw, the first eulora dependency from the fedora install guide, boost-jam, was not available
diana_coman: whaack: how about choose your favourite event/chapter/part and review that - summarise what's going on, how it's built/told and why it matters
diana_coman: link it to anything relevant you know otherwise
whaack: diana_coman: okay
diana_coman: whaack: yes, centos 6 has an older thing though that works; look for jam or ftjam , there is some package containing on or the other, can't recall now without the notes
whaack: diana_coman: alright
whaack: the weird thing though is i downloaded the rpm for bootjam and ran "cat boost-jam-1.55.0-25.el6.x86_64.rpm" (dont ask why) and my terminal turned into hieroglyphics, i had to restart my comp
diana_coman: ahahah
whaack: i don't understand why displaying characters to stdout would then change the symbols for characters permanently
jfw: hehe, whaack learns about in-band signalling and state machines
diana_coman: whaack: did you try simply a "reset" cmd first?
diana_coman: before restarting computer, try some simpler measures, you know?
whaack: let me reproduce the bug and try
whaack: yes reset does the job
diana_coman: whaack: btw, you'll get that sort of thing ~any time you display non-ascii
diana_coman: jfw: you are an optimist after all!
jfw: whaack: https://vt100.net/docs/vt100-ug/chapter3.html#SCS is what typically causes the hieroglyphs (box-drawing character set really, https://vt100.net/docs/vt100-ug/table3-9.html ), though there are other weird things that can happen too, of which 'reset' can fix most
whaack: jfw: thanks i'll give the two a read
jfw: diana_coman: what can I say, it worked last time just with some delay :D
jfw: whaack: my go-to for displaying might-be-binary files is 'less', as it escapes terminal control characters by default
jfw: of course to actually inspect a binary there's hexdump or xxd
jfw: diana_coman: http://logs.ossasepia.com/log/ossasepia/2020-02-04#1017157 - thanks; thinking I'll go for finishing it
ossabot: Logged on 2020-02-04 04:20:04 diana_coman: http://logs.ossasepia.com/log/ossasepia/2020-02-04#1017152 - jfw, up to you really; fwiw notes were funny to read so I won't complain either way, not like they are not clear for me or anything of the sort, lol.
whaack: Cal3D *
diana_coman: whaack: yeah, use my blog
diana_coman: minigame's website was not resurrected after pizarro's implosion.
whaack: diana_coman: ty
diana_coman: whaack: I guess update the wiki too, what can it hurt.
whaack: diana_coman: I was about to say I'm on it
BingoBoingo: diana_coman: Please let me know if you would like the domain DNS pointed somewhere else. Right now it's all pointed at the Eulora logs.
diana_coman: BingoBoingo: thanks; so far there was simply no decision to bring the website back up; will let you know if anything changes on this.
BingoBoingo: diana_coman: Ok, thank you.
whaack: diana_coman: wow, i learned i have an account on the wiki page from a while back
whaack: diana_coman: should I have to be root to run "autoreconf --install --force" ?
diana_coman: whaack: no, should not require root; why?
whaack: diana_coman: I got the error "Can't exec "aclocal": Permission denied at /usr/share/autoconf/Autom4te/FileUtils.pm line 326.
diana_coman: I guess you'd end up needing that only if you are trying to install it somewhere where you don't have permissions
diana_coman: it's the first time I see/hear of such a thing; do you have some incompatible versions of autotools?
diana_coman: that's usually where the weird stems from on autoreconf and the like.
whaack: diana_coman: I had to run `yum install autoconf`
whaack: diana_coman: i admit i skipped the step and kept going without trouble.
diana_coman: cal3d is quite undemanding, yes
diana_coman: dorion: is this silence-since-Sunday the busy-silence or the stuck-silence?
whaack: diana_coman: now at the "./autogen.sh" step I get "configure:3522: error: possibly undefined macro: _AC_CC
whaack: "If this token and others are legitimate, please use m4_pattern_allow. See the autoconf documentation. Autogen failed"
diana_coman: whaack: uhm, I didn't run into that either; it really sounds like you are missing something/have mismatched versions
diana_coman: whaack: did you install libtool ?
whaack: diana_coman: no I don't think so.
jfw: whaack: does 'aclocal' work manually from shell? might need to be installed separately.
whaack: jfw: I don't have the aclocal command
jfw: the 'autotools' come in a couple related but not always used packages: autoconf, automake, libtool mainly. Looks like aclocal is part of automake.
whaack: I got aclocal from doing yum install libtool. but I still get the same error.
jfw: whaack: which same error, did you circle back to the autoreconf ?
whaack: jfw: no i had not, and i just did now, and that fixed the original autoreconf problem, i'll continue and redo the other steps.
jfw imports those vt100 / vt102 user guides to the fixpoint library, as the Paul Williams fella already broke his site by forcing https
whaack: diana_coman: I got a few errors on the `jam -aq libs plugins cs-config walktest` step. Here is the [paste.deedbot.org/?id=2aRJ] and [paste.deedbot.org/?id=S9ec][here] is the missing optional dependencies from cs.
diana_coman: whaack: cal3d lists as "optional" pretty much everything because the original author was so afraid to decide on anything at all that he ended up with this situation where rendering stuff (and similar) is somehow optional for a graphics engine, among other lulz.
whaack: kek
diana_coman: at any rate, the walktest thing has to work if you are to have any use for cs really because that's the basic test of graphics pretty much
whaack: i recall the wonderful feeling of walking around that dungeon the first time i installed eulora
diana_coman: whaack: zlib is a must iirc; and you'll probably need zlib-devel package
jfw: whaack: don't you think you might want to get x11 working first before getting to things a couple layes of deps above that?
whaack: jfw: I do have x11 working
diana_coman: and uhm, x11 missing?
whaack: idk why it says i don't
diana_coman: whaack: something is missing, so it's not finding it
jfw: ah ok, then probably just missing the -devel packages (headers mainly).
diana_coman: probably like for zlib above, you don't have the devel packages
diana_coman: heh, as jfw says
whaack: so do i just do a yum install and slap -devel onto all those missing things?
jfw: redhat does this thing where "we'll save you 10kb of header files because why would you want to compile anything rather than eat binaries?"
whaack: (just did that for zlib)
diana_coman: whaack: didn't you look at the list of deps for fedora and other systems? because the package names might be different but the deps are still deps
whaack: diana_coman: No, is there a list of deps for eulora posted somewhere or should i search online for a list of deps for cs?
diana_coman: whaack: no, those on the wiki#
diana_coman: and don't waste time searching online re deps for cs, lolz, that's really not going to do anything other than waste time.
whaack: diana_coman: The wiki doesn't have an explicit list of deps
whaack: diana_coman: I tried to find an equiv for every package that didn't have the same name as the one in fedora's repo
diana_coman: I guess I'll have to write-up my notes at some point then.
whaack: jam I had to search for in the wild, and my machine has been hard at work since i got zlib-devel
diana_coman: whaack: since my list of to-write is long and only getting longer and otherwise on centos I just ported the darned client to gnat anyway, here's a raw paste of notes with packages for corresponding CS stuff, from when I was simply mapping what fits what (ie see what is really needed, perhaps not all of them are): http://paste.deedbot.org/?id=KogY
diana_coman: whaack: looking at it now, I can even tell that bullet is not needed and otherwise it even tends to create trouble so leave it out
whaack: diana_coman: thx
whaack: currently stuck with Cg. I installed from nvidia but thought about using the rpmfusion repo
diana_coman: see possibly the note that it needs the libgl-devel thing too
diana_coman: if you look in the configure script, you'll see exactly what/how it checks anyway; it's a long thing but relatively straightforwardly written, as those things go.
whaack: diana_coman: I installed cg, I am pretty sure, but all i can find is an executable /usr/bin/cgc -- i need to look for a folder though, correct?
whaack: (to put as the destination of the ./configure --with-Cg="" --with-CgGL="")
diana_coman: whaack: so it's missing the headers; the -devel package etc
diana_coman will bbl
jfw: whaack: assuming you still have it installed from nvidia rather than rpmfusion you probably do have all the headers and just don't know where to look, and the configure argument wouldn't be necessary
jfw: (I haven't used Cg though so just guessing.)
whaack: jfw: I solved? worked around? the problem by downloading the tarball from nvidia, extracting it to /opt/nvidia-cg-toolkit, and setting the config arguments accordingly
jfw: cool, sounds like a solution to me as I don't see any benefit in adding a new intermediary just to install what's surely a pile of blobs anyway
jfw: given that it's apparently self-contained in a subdir like that
diana_coman: whaack: sounds like a solution, well done!
whaack: thanks, i got the walk test running!
whaack: one thing that tripped me up was while installing i started my x11 as root, and was su'd into my non-root user
whaack: i was not able to start x11 (and thus the walktest) from the terminal running as the non-root user
jfw: whaack: "not able" how?
whaack: (also, back to the same bug with ./autogen.sh "configure:3522: error: possibly undefined macro: _AC_CC)
whaack: jfw: I logged into a tty as root. Then I ran startx. Then, while in the graphical environment, i opened up a terminal. I ran su whaack (my nonroot user) and then ran the walktest. It gave me an error akin to 'X11 failed to start'
whaack: I fixed this by running startx as 'whaack'
jfw: uh, I thought you specifically said you couldn't start X as non-root user
jfw: and yeah, it's not the greatest practice to start an X session as root, gives all the GUI stuff more privilege than it ought to have
jfw: the X server process does need to be root but that's distinct from the clients and should be handled by startx and the setuid bit
whaack: jfw: right, that was not clear. I was not able to start x11 while su'd into a non-root user in a terminal that was started in an x environment that i started as root. (quite a mouthful, and i'm sorry if I am using some of the x11 terms incorrectly)
jfw: so you wanted to start an x11 inside the x11? lol
jfw: technically what you were trying might be possible by setting the DISPLAY variable to match it was in the root shell. That doesn't mean starting a new X server, but telling the clients how to connect to the existing one. But yeah, best to start as whaack to begin with.
jfw: **match what it was
← 2020-02-03 | 2020-02-05 →