This is a bit off topic, since I purged nvidia and installed "debian's" 375 last weekend. 378 dropped into sid this week, and it installed fine. Then 384.98-2 dropped into sid this morning, and it also installed without an issue.

I'm still having the glxinfo issue/error, but again, I'm pretty sure this will shake out when mesa is updated.

The bottom line is that because I'm good right now, I'm not inclined to install the latest nvidia driver (387.34, last I checked) with sgfxi with the added flag fix. I might do it this weekend, but maybe not until I have to deal with an upgraded kernel. If anyone else has had this installation issue, please post your results after running the updated sgfxi.
Back to top

I'm curious what happens with the flag fix, I haven't tested it, been busy with work, can't do heavy testing at this point.

I don't believe it's a good solution, nor is it a solution I want to leave in inxi because I'm unclear what happens on removal, etc, and I'm unclear what the packages in question even do.

Unfortunately smxi/sgfxi were hit with the wget bug, which I've fully corrected now in both (as well as in a much more robust fix in inxi), but the nvidia issue was unclear, and didn't get much attention beyond my adding an auto add flag to the nvidia installer which should have in theory corrected your issues.

note that technically speaking, all you'd need to do to restore fully from a test is to use apt to reinstall the package that owns the file in question. Reinstalls in debian do not check the actual binaries, they apparently do in Arch, but not in debian, which is convenient, it means it doesn't matter what something does to a specific library, you can just reinstall it and go on.

The real sad part of this is that I can never trust gnu wget again, because they uploaded a new version WITHOUT TESTING IT AT ALL!!

And yes, I'm aware of the irony of my releasing a fix without testing it, but sgfxi does not have many users compared to wget, which is basically in every linux system in the world, so it's a bit different to not test a core utility than to not test a user addon that's not even a package in any distribution. inxi for example is always tested.

Since -O is a standard option, any reasonable testing script would have detected the failure instantly, so this tells me the programmers working on that are not testing it, it's not possible they are, with a consistent test set before release. Which means I can't trust it anymore.

Note that once you write a simple shell script that simply runs your wget build using most of the standard options, and combinations, and exits on failure, testing it would take a minute or two, literally.
Back to top

For the libglvnd issue, follow this bug thread: bugs.debian.org/cgi-bin/bugreport.cgi?bug=879041

There's a conflict between libglvnd0-nvidia and libglvnd0:i386. I think the nvidia driver wants to install libglvnd0-nvidia, but I'm not exactly sure about that.

Updated mesa didn't solve this, and this issue was re-assigning to nvidia-graphics-drivers.

bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=nvidia-graphics-drivers

I still haven't tried to install the driver via sgfxi, but this is what's up, FWIW.

Update/Edit:


Back to top

It would be easier to see what's up if you try the sgfxi install.

It's now set to default install those nvidia libs, so the question is, if that flag is used, does the install work.

this takes a few minutes to determine, and you can always apt reinstall the lib package anyway if things don't quite work.

I don't have any information on this beyond what you have told me, so the only way to verify if it works is to simply install via sgfxi the nvidia driver, which will then install with the use nvidia libs in the install.

It's always very difficult to know what exactly debian maintainers mean when they talk about packages overwriting some debian lib, usually there's an unhappy reaction to that fact, but what there usually and sadly is not is a verification that such an overwrite fixes the issue.
Back to top

bugs.debian.org/cgi-bin/bugreport.cgi?bug=879041

If you take a look at Dirk Lehmann's original post, he'is running the installer in a way that allows full control over his installation.



... he gets the libGL errors (same errors). And given Andreas Beckmann's final comments, I don't think you want to answer "yes, install install a full copy of libglvnd". I'm 99% sure you'd be installing what Beckmann says is Nvidia's "ancient version of libglvnd".

Is that what you've done with the script? I do not want to install nvidia's version. I want to answer "no", not "abort".

h2, ask Santa for this: www.newegg.com/Product/Product.aspx?Item=9SIA2F85ST7915
Back to top

It would be easier to see what's up if you try the sgfxi install.

It's now set to default install those nvidia libs, so the question is, if that flag is used, does the install work.

this takes a few minutes to determine, and you can always apt reinstall the lib package anyway if things don't quite work.

I don't have any information on this beyond what you have told me, so the only way to verify if it works is to simply install via sgfxi the nvidia driver, which will then install with the use nvidia libs in the install.

It's always very difficult to know what exactly debian maintainers mean when they talk about packages overwriting some debian lib, usually there's an unhappy reaction to that fact, but what there usually and sadly is not is a verification that such an overwrite fixes the issue.
Back to top

If you want to see what happens with the nvidia installer, you'd have to run the .run package, which is in I think /usr/src/sgfxi and then see what happens.

Technically speaking, I can't test stuff I don't have.

I could also reverse the option, to default to not using that thing, which might get rid of the question, I don't know.
Back to top

bugs.debian.org/cgi-bin/bugreport.cgi?bug=879041



This issue is done for me.

1) The wget issue is solved.

2) Installing the nvidia-driver the debian way solved most of my issue, and this is probably due to the way debian packages the driver to proceed with the installation, even though the Open GL issue was not solved by a successful driver installation.

3) h2, I would reverse the flag fix in sgfxi. This issue obviously impacted a few people, but not enough to warrant a universal script fix.

I've been messing with this for 6 weeks, and I'm over it. No one else has complained, so I'm going to chalk this up to a personal one-off. If anyone else is having the same type of issue, there's plenty of info in this thread to fix the problem, or to post sgfxi run results to effect change in sgfxi if needed.
Back to top

Reversed the -g option, now -g turns ON that nvidia install feature, and default is now to disalbe the install, which should I believe also get rid of the question in the install process I think.
Back to top

An updated wget came into sid today: tracker.debian.org/pkg/wget

1.19.2-2 over 1.19.2-1



Looks good to me.
Back to top