I think I’ve read everything I could get my hands on by every author you mentioned except Camus and Kierkegaard. I’ve read a couple of Kierkegaard’s books but pretty much made myself do it. IMO, Dostoevsky’s best is The Brothers Karamazov which is a “must read”. Off the top of my head, the only modern fiction I could add to the one’s you list is that of Solzhenitsyn, most of which is historical fiction, and his non-fiction works are just as good. Perhaps not as interesting to those who didn’t grow up during the cold war–I wouldn’t know.
$ xbps-query -X libgcc
mesa is graphics related and depends on libgcc
$ sudo ./packagefromfile pax
./packagefromfile: 29: [: NONE: unexpected operator
./usr/share/man/man1/paxcpio.1' ... pax-manual-20161104_1: adding./usr/share/man/man1/paxtar.1’ …
./usr/share/man/man1/pax.1' ... pax-manual-20161104_1: adding./usr/bin/paxcpio’ …
./usr/bin/paxtar' ... pax-manual-20161104_1: adding./usr/bin/pax’ …
pax-manual-20161104_1: binary package created successfully (pax-manual-20161104_1.i686.xbps)
created pax-manual-20161104_1.i686.xbps in /tmp
Neat script, I was just trying it out a little!
One thing xbps lacks is a logging system. Conceptually if it logged the package state before an update or other change, then it could revert back to that using the cache, but that would fail if the install was from a live image. This script seems a step closer to having a reverse gear to get out of trouble on upgrades and so on.
$ tar -xvJf pax-manual-20161104_1.i686.xbps
$ diff -u props.plist origpaxunpacked/props.plist
files.plist has a different mtime as one might expect, the only real difference in the script made package vs the original from the cache is in the props.plist file.
Oops. You uncovered a bug I missed. == should be = on line 29
I’ve been working in OpenBSD scripts, and even some of the official scripts use Kornisms (bash and korn support == as a comparison, but POSIX standard is =). I made sure not to use [[ (as I try to avoid it in general) but I forgot about the double equal sign…
so they ARE tarballs… last time I tried to look inside a package file, I had problems. I probably guessed the wrong compression filter. Something I’ll need to remember…
hmm. wouldn’t have helped in this case. (I checked) Doesn’t check for strict POSIX compliance. I can’t find a switch of any kind on the page.
Syntax probably based on what’s allowed by bash or korn rather than strict POSIX. It’s GPL-3, which strongly suggests they’re Linux types, so bashisms aren’t seen as a problem. (despite how many distros use dash).
Bash still allows that syntax even in posix mode (set -o posix), so it’s not that strict…
:/var/db/xbps$ plistutil -i pkgdb-0.38.plist -o ~/projects/plist/testoutput1.txt
Decodes the data sections of pkgdb-0.38.plist and turns the undecoded xml to garbage - well it proves that’s where the info is hidden.
A small portable C library to handle Apple Property List files in binary or XML.
It looks like some but not all of the xml elements found in pkgdb-0.38.plist under the appropriate heading, e.g. >key> pax>/key>
are used in the props.plist file in the package. So the data is in there but not directly transposed. (Some arrows< were reversed to confuse the markup)
I’d already figured out where everything was. I suspected it was base64, but when I tried feeding one of the elements through an online decoder, I got garbage. However, I tried again with another data element and a different decoder, and got the install script I was expecting.
This makes it possible to put those files into the created package (I haven’t seen it documented anywhere, but examining how xbps-src does it showed that you just put those files in the root of $DESTDIR; xbps-create sees the special filenames and handles them special.
So… plistutil - any idea whether that’s part of the live CDs? I figured I might need to somehow parse the data elements and pipe them through base64 (which is in coreutils). That might offer a slightly easier option.
(frankly, I probably shouldn’t use pax as it’s not in the base install. tar can do what I need, but I don’t know if it can be done in one command. It could on some BSDs, but that’s only because tar, cpio and I think one or two others are just invokations of pax.)
Uhm what? I checked with a bash script and put #/bin/sh at the top and it gave me many errors about breaking posix rules.
If you declare a script as bash it will only throw issues of bash.
Thanks again everyone for the suggestions. May I suggest this other discussion be moved to a new thread?
exactly what I’m on about. /bin/sh is not bash here or a lot of other distros. It’s dash and chokes on things that are legal in extended shells like bash/korn/zsh. (dash is debian-almquist, few extensions if any, so requires clean posix syntax)
However, a lot of linux users who aren’t writing system scripts use all sorts of bashisms and don’t even realize they’re doing things that might not be portable. The script checker above allows things that make dash puke. Clearly, they’re using extensions. I’m guessing bash and not korn based on guesses about the cultures involved (gpl3 being prominent in Linux circles where bash dominates, whereas in BSD land you get old-school Bourne, Korn and apparently Almquist.)
I never shebang bash… (fwiw I never shebang korn either, though in openBSD, sh is ksh) I always declare /bin/sh, and try to make sure I’m using strict syntax. I goofed on that one up there.
ah, yeah, sorry about that (things are getting away from us aren’t they…)
(it is your thread…)
No problem. I probably should have put a smiley face on that. It could be taken the wrong way. I was thinking of some future reader with possibly the same problem. If Dostoevsky and Kierkegaard don’t frighten them away, surely a shell script discussion would. Also, I get a notification on new posts and, yeah, would prefer they are relevant.
All that aside, I could almost mark the thread as solved because so far my workaround has worked through several reboots and restarts. I still haven’t done a full upgrade but have allowed it to upgrade several packages with no more problems. It turns out all I have to do is have both libstdc++.so.6.0.22 and libstdc++.so.6.0.20 in /usr/lib and before startx, change the libstdc++.so and libstdc++.so.6 links to point to the earlier version. After x loads, I change the links back to point to the later version. And, yes, I have written shell scripts to do that.
well, maybe I’ll get a bit more curious and look into this issue some more (not sure, as it ain’t easy troubleshooting something you can’t reproduce!)
For now, I’m relaxing looking at notpron (search the web if you’ve not heard of it. That’s all I’m going to tell you).
I decided to throw caution to the wind and do an -Su. The bad news is that X crashed using my work around and for some reason it won’t load amdgpu. The good news is that I installed the ATI driver and it now works as it should–without the workaround! What am I to make of this? I think installing “mesa-demos” brought in some dependencies that made loading glamoregl work. I don’t find libEGL, libOSMesa, libGLES, and a few others anywhere else. Heh, not that long ago, the challenge was getting 3D to work; now I can’t get it to work without 3D.
So, if anyone wants to play with it, try setting up a really bare bones system with just: xorg-minimal, xterm, xf86-video-ati, xorg-fonts, pekwm. With the exception of pekwm, that comes straight from the “Post Installation” page. Don’t install any applications or graphical login. Get pekwm working. Then repeat "xorg-install -Su’ until it has no more updates, and reboot. If pekwm works, then it may be something unique to my hardware (remember, the current live boot disk didn’t work for me), or I did something stupid that I don’t remember. If not, I think there is a dependency problem somewhere, or possibly a bug in the xorg startup.
If you wanted to mark solved, just edit the title at the top of your first post (you mentioned it before)
That’s good. I take it you mean the driver you have to get from AMD? If you’re not opposed to using it, then there are advantages if you’re interested in getting the best performance out of it.
And if that’s the case, was this is the old fglrx or the AMDGPU-PRO (old is catalyst driver, related to “radeon”; and new is crimson driver related to “amdgpu”)
No, xf86-video-ati. When I reinstalled to use amdgpu, I didn’t install the -ati package because xorg kept loading it instead of amdgpu. After the full update, xorg refused to load amdgpu so I installed xf86-video-ati.
aha. I’d thought that’s what you’d have had from the beginning.
Then that actually explains more. The kernel module and xorg module should be from the matching series.
If I’m understanding this correctly, then you’re also using the “radeon” kernel module, and then that’s how it’s supposed to work as I’m reading it…
xf86-video-ati is the xorg module for the “radeon” driver (as I said, I’d previously misspoke when calling it “radeon”). xf86-video-amdgpu is for the new AMDGPU driver.
While it should have worked between xf86-video-amdgpu and AMDGPU, you might still be suffering a bug on that one since you did have it matched and still had problems, but at least you’ve got a working setup now.
Sounds like a flaw in Xorg if it can attempt to use the wrong xorg module for the loaded kernel module. But I don’t know enough about how that works…
Needless to say, if you’re somehow using the “amdgpu” kernel driver with the “ati” xorg module, then I’m clearly thoroughly confused as to how this works!
Ok, then, that would suggest that the main problem was that I didn’t do a recursive -Su. IMO, the “Update” section of the “Post-Installation” page should mention that it needs to be repeated until there are no more updates. On Arch, -Su is only needed once, that’s what I’m familiar with, and that’s what the post-installation instructions imply. Anyway, using the bare-bones install image, the xorg module would never match the kernel module unless a complete update and reboot were performed. And when I did reinstall, I deliberately avoided updating. Argh! I feared it would turn out that I did something stupid.