I don’t have time to deal with this right now. Just keep adding packages from your gcc stack (from your installed gcc packages you wish to keep) until --auto-select quits pulling the new gcc. It will work if done correctly.
What about the following
urpmi --auto-update --excludepath gcc\* --test
BTW the option –wget is not needed unless you have to use wget for some reason. In this case you may set your preferred packages downloader by using rpmdrake or by selecting it directly into /etc/urpmi/urpmi.cfg.
This command line (with --wget) didn’t help. It keeps trying to update gfortran (gcc-gfortran) and remove scilab-5.5.2.
Somewhat short of time today, but I’ll try other packages at skip.list asap.
Thanks
814 packages waiting for update. Most updates depend on new gcc 7.2, I cannot update gcc because It requires removing packages I use to work (although outdated). I would take my chances in rebuilding packages like scilab from contrib If I could update gcc which in turn requires removing the old scilab.
Deadlock.
1 Like
Yikes, you are headed for a Gordian Knot. You need to get on IRC and beg developers for help. ASAP.
Edit: Or your need to forget about updating forever.
1 Like
I’m trying to push scilab on ABF, but I had to push some java dependencies before. I had some dependencies troubles on ABF but now I think I solve so I hope I’ll finish for this week-end. So if you have some time you may set-up a clean vbox with my personal repo enabled as explained here. 
Add all of them to skip.list…
Anyway I asked the following on IRC:
<ben79> itchka: bero: Is there any chance we can put GCC 6.3 back in repositories we're really screwing this user with that GCC 7.2 thing:
<ben79> https://forum3.openmandriva.org/t/new-updates-gcc-7-2-will-set-me-out-of-business/1441/
<ben79> Or could he add the GCC 7.2 packages with --nodeps? Would that work?
<ben79> So his system has both GCC 6.3 and GCC 7.2?
<ben79> That's what it looks like is neededYou can try to install the GCC 7.2 packages with --allow-nodeps. You will have to list every single package in the command string. So you’d run ‘urpmi --auto-updates’ and start copying and pasting gcc and lib packages to the command string till you get 'em all. If this works how you’ll know is when you get all of them it won’t be asking to remove GCC 6.3 or any packages that depend on it. Then you’ll have both GCC 6.3 and GCC 7.2 on your system. YMMV.
Apologies for so many posts. Let me be sure I have this issue understood. There are 15 packages that need to be rebuilt with GCC 7.2 to unblock 814 updates right?
If so that is the very best solution, though I do wonder if the:
# urpmi --allow-nodeps gcc*
would not work as well. I am pretty sure the * won’t work and Adelson will have to list every single GCC 7.2 package his system is calling.
Ben you need the --allow-force flag as well to make this work.
But I’d reccomend he sets up urpmi.recover with a checkpoint and cache so he can revert if anything goes badly wrong.
Mandian,
I don’t think I know how: where is your personal repo? I guess I also have to find how to set up a vbox.
Thanks
Personal repositories are here.
Just install OpenMandriva into a box by using VirtualBox (you may use latest ISO from ABF for this) and update the system. Then add my personal repository and update again the system with the following commands:
sudo urpmi.addmedia --no-verify mandian_personal http://abf-downloads.openmandriva.org/mandian_personal/repository/3.0/x86_64/main/release
sudo urpmi --auto-update
I used --no-verify option because nore of the packages in my personal repo are signed.
Ok.
Thanks.
@adelson.oliveira scilab 6.0.0 is ready for tests!
Postedit: if you have some FORTRAN skills please could you check if this patch is good enough?
Downloaded!
I installed it in a alternative computer (instead of creating a vbox). Installation went well, some security warnings since I did not use --no-verify.
I’ve launched and tested (via a ssh connection and in place) very simple graphical facilities with no problem.
Upon launching I got the following messages via ssh,
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 156 (GLX)
Minor opcode of failed request: 24 (X_GLXCreateNewContext)
Value in failed request: 0x0
Serial number of failed request: 35
Current serial number in output stream: 36
Warning: Could not find Java package '/usr/share/java/lucene/lucene-core.jar'.
Warning: Could not find Java package '/usr/share/java/lucene/lucene-analyzers-common.jar'.
Warning: Could not find Java package '/usr/share/java/lucene/lucene-queryparser.jar'.
Some problems during the loading of the Java libraries occurred.
This could lead to inconsistent behaviours.
Please check SCI/etc/classpath.xml.
libEGL warning: DRI3: failed to query the version
libEGL warning: DRI2: failed to authenticate
(scilab-bin:24721): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",
Don’t know if these messages are relevant or if they belong to the ssh connection.
I also launched it in the computer with scilab 6.0.0 and got the following messages:
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
Caught handled GLException: X11GLXDrawableFactory - Could not initialize shared resources for X11GraphicsDevice[type .x11, connection :0, unitID 0, handle 0x0, owner false, ResourceToolkitLock[obj 0x1d1972ef, isOwner false, <51d28e4f, 207b203a>[count 0, qsz 0, owner <NULL>]]] on thread main-SharedResourceRunner
[0]: jogamp.opengl.x11.glx.X11GLXDrawableFactory$SharedResourceImplementation.createSharedResource(X11GLXDrawableFactory.java:306)
[1]: jogamp.opengl.SharedResourceRunner.run(SharedResourceRunner.java:353)
[2]: java.lang.Thread.run(Thread.java:748)
Caused[0] by GLException: main-SharedResourceRunner: Error making temp context(1) current: display 0x7fd424000df0, context 0x7fd4240354c0, drawable X11OnscreenGLXDrawable[Realized true,
Factory jogamp.opengl.x11.glx.X11GLXDrawableFactory@62f63b1b,
Handle 0x8000002,
Surface WrappedSurface[ displayHandle 0x7fd424000df0
, surfaceHandle 0x8000002
, size 64x64
, UOB[ OWNS_SURFACE | WINDOW_INVISIBLE ]
, X11GLXGraphicsConfiguration[X11GraphicsScreen[X11GraphicsDevice[type .x11, connection :0, unitID 0, handle 0x7fd424000df0, owner true, ResourceToolkitLock[obj 0x2953623e, isOwner true, <484f3d5b, 4d0020fb>[count 2, qsz 0, owner <main-SharedResourceRunner>]]], idx 0], visualID 0x27, fbConfigID 0x10d,
requested GLCaps[rgba 8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms 16/0/0, dbl, mono , hw, GLProfile[GL2/GL2.sw], on-scr[.]],
chosen GLCaps[glx vid 0x27, fbc 0x10d: rgba 8/8/8/0, opaque, accum-rgba 16/16/16/16, dp/st/ms 24/0/0, dbl, mono , hw, GLProfile[GL2/GL2.sw], on-scr[.]]]
, surfaceLock <1efdf4a3, 2c0d27d0>[count 1, qsz 0, owner <main-SharedResourceRunner>]
, X11DummyUpstreamSurfaceHook[pixel 64x64]
, upstreamSurface false ]] on thread main-SharedResourceRunner
[0]: jogamp.opengl.x11.glx.X11GLXContext.createImpl(X11GLXContext.java:393)
[1]: jogamp.opengl.GLContextImpl.makeCurrentWithinLock(GLContextImpl.java:765)
[2]: jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:648)
[3]: jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:586)
[4]: jogamp.opengl.x11.glx.X11GLXDrawableFactory$SharedResourceImplementation.createSharedResource(X11GLXDrawableFactory.java:277)
Should I pay attention on it?
Many thanks!
1 Like
This patch seems to belong to the lapack double precison library not to FORTRAN itself. I’ll check for it and post anything I find.
Thanks again
About the patch, it seems to replace a deprecated lapack driver by a newer one …
It’s like some lucene packages are missing. You may try the following:
urpmq -i lucene lucene-analysis lucene-queryparser
This is a problem of your machine which makes jogl2 fail. Are you using an _nvidia_driver?[quote=“adelson.oliveira, post:38, topic:1441, full:true”]
About the patch, it seems to replace a deprecated lapack driver by a newer one …
[/quote]
yes, it’s so but it’s like dgeqp3 is a bit different dgeqpf, expecially for WORK(1) output argument. It is only used here
I guess, ssh’ed application has something to do with this. I think, the lucene warning was issued because the machine from where I ssh’ed does not have lucene. When I launched scilab in the machine where scilab was installed, this warning did not showed up.
Yes, I’m using nvidia drivers 381.22-1, also,
$ rpm -qa|grep swrast
lib64dri-drivers-swrast-17.2.3-1-omv2015.0.x86_64
I guess scilab users won’t ever know about this since scilab has its own QR wrap up functions. The link you mention is for an “internal” scilab procedure which users don’t know about.
1 Like