When I ran 'pacman -Syu' today on an rpi3 Arch-Linux installation, the following question
was asked: Replace linux-raspberrypi with core/linux-rpi-legacy? [Y/n]
Is this a simple renaming or is this an
important change impacting the system's future?
Although the other answer was first, here's the relevant information from the forum:
Raspberry Pi kernel rename coming soon
Post by graysky ยป Sun Nov 28, 2021 12:20 pm
In a rebranding move, we
are changing the names of the two kernel packages for the RPi series
of devices to more adequately represent the intended platform.
linux-raspberrypi --> linux-rpi-legacy (RPi 1, 2, Zero, Zero W)
linux-raspberrypi4 --> linux-rpi (RPi 3, 4, 400, and Zero 2 W)
Once the new packages are built and hit your mirror, pacman should
automatically handle it by asking you if you would like to replace the
old package with the new one. Say Y to proceed.
The full name of the thread is "Raspberry Pi kernel rename coming soon"
The link on the forum for me is this
Always look first into the forums:
https://archlinuxarm.org/forum/viewtopic.php?f=3&t=15683
Related
Oracles Forum about JavaME is dead! I'm sorry to say, but questions never get an answer.
The javaME-GettingstartedGuide.pdf from Oracle tells me: The GPIO pins are preconfigured! Does this mean I must take it as it is and JavaME does not allow any configuration? Further, the document tells me Device ID 1, named GPIO4 is input only and mapped to pin 4! But the Pi documentation tells me Pin 4 is connected to +5V! Where can I find valid information?
The problem relies in the two kind of numbering. A Raspberry style (Broadcom pin number) and raspberry physical style! You can find both in the JavaME-GettingStartedGuid, but not side by side. A problem in a GettingStartedGuid. Not being prepared you get confused! See Raspberry Pi Pinout
The question w.r.t. Pin reconfiguration in JavaME however ist still open.
Today I finally found out what has been stalling my development process: Even though no errorcode is set, the function wglChoosePixelFormatARB returns 0 pixelformats.
I am trying to set up an OpenGL context in my C++ application and I have managed to retrieve the function pointers for the extensions.
glGetIntegerv(GL_MAJOR_VERSION, &maj)
returns 4 so, naturally, I assumed it would be possible to create an OpenGL 3.2 context. However, after finding out there were no matches, I started to comment out some of my requirements to go in the attribList parameter. There were no matches whatsoever.
Only when I, just to be certain, commented out
WGL_CONTEXT_MAJOR_VERSION_ARB, 3,
WGL_CONTEXT_MINOR_VERSION_ARB, 2,
I finally got matches. Out of the 8 matching pixel formats that the other requirements meet, not ONE of them seems to support version 3 of OGL.
Has anyone ever run into this? I have tried updating/reinstalling my video drivers, but nothing has changed. I am running this on Windows 7, MS Visual Studio 2008, and my graphics card is one from the AMD Radeon HD 7700 Series.
The WGL_CONTEXT_MAJOR_VERSION_ARB, WGL_CONTEXT_MINOR_VERSION_ARB and related attributes are not attributes of the Windows Pixelformat.
You must not use them with wglChoosePixelFormatARB().
Those options belong into the attribute list of wglCreateContextAttribsARB as defined by the WGL_ARB_create_context extension.
While in u-boot of my ARM based board (DM368) I mark some kernel partition block manually as bad. U-boot says that it was marked and, for example, while writing/reading kernel image I see it skipping this bad block.
But when I try to write the same partition from within Linux (loaded via NFS) I see that Linux nandwrite command USES this bad block! I checked this in several ways - Linux ignores bad block mark for 100%. But everywhere in the internet it is said that BBT is one for both u-boot and Linux.
So, where is the catch?
OK, the answer is found.
For some unclear reason Texas Instruments, manufacturer of the board DM365EVM which I use for development, provides the kernel with different BBT structure. They defined BBT offset as 2, while all the world, including the provided u-boot, defines this offset as 8.
I wish them a good health for many years.
In a wxPython application, which i am porting to Mac OSX, I set title of app frame every 500msec in update UI event, and due to that all the panels and windows are refreshed. That seems strange to me and almost halts my application which has many custom drawn controls and screens.
I wanted to know what could be the reason behind it, is it normal for MAC?
Here is a self-constrained script which replicates the scenario using timers. It keeps on printing "on paint" every 500ms because in timer I set title every 500ms.
import wx
app = wx.PySimpleApp()
frame = wx.Frame(None, title="BasePainter Test")
painter = wx.Panel(frame)
def onPaint(event):
dc = wx.PaintDC(painter)
print "onPaint"
painter.Bind(wx.EVT_PAINT, onPaint)
def loop():
frame.SetTitle(frame.GetTitle())
wx.CallLater(500, loop)
loop()
frame.Show(True)
app.SetTopWindow(frame)
app.MainLoop()
My system details:
>>> sys.version
'2.5 (r25:51918, Sep 19 2006, 08:49:13) \n[GCC 4.0.1 (Apple Computer, Inc. build 5341)]'
>>> wx.VERSION
(2, 8, 10, 1, '')
>>> os.uname()
('Darwin', 'agyeys-mac-mini.local', '9.8.0', 'Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386', 'i386')
Alas, I'm not sure of the specific issue. However, when you have a sample which demonstrates the problem but are stumped, I've always had great luck by emailing the wxpython-users mailing list and attaching the sample. You should get a response pretty quickly on if there is something you can do to fix it, or if not, that you should file a bug in the tracker.
I have had plenty of problems solved this way, and when I do have to file bugs, they are usually resolved quite speedily. Hope this helps!
It is a bug in wxPython (OSX-Carbon).
Filed a bug http://trac.wxwidgets.org/ticket/11920
Discussion:
http://groups.google.com/group/wxpython-users/browse_thread/thread/2430e0ef7ff1fb8/8f384968a42136d7
I am using Matlab to operate a camera. It is an IDT SharpVision camera, and I am using the Matlab interface provided by the company. When I try to acquire an image, I get a segmentation fault. I have tried preallocating memory by creating an empty array for the image, but this does not work.
This is the line of code that causes the seg fault:
[nResult, x] = sharpML('IdtSvAcquire',cameraId);
sharpML.dll includes a MEX file for controlling the camera.
Here is a selection from the error message stack trace:
[0] QCamChildDriver.dll:0x160fdde4(0x0f99ef08, 15, 0x00ced938, 0x00ced938)
[1] QCamDriver.dll:0x0f9c1dd8(4146, 0x00ced938, 0x00ced924, 0x11283430)
[2] sharpML.dll:0x0f991d8c(2, 0x00cedf88, 2, 0x00cedfe8)
[3] sharpML.dll:0x0f991448(2, 0x00cedf88, 2, 0x00cedfe8)
...
[35] MATLAB.exe:0x00403bd2(1109972, 0, 0x7ffd9000, 0x805512fa)
[36] kernel32.dll:0x7c817077(0x00403daf, 0, 0x78746341, 32)
Any suggestions? The company that makes the camera has since gone out of business.
~ Adam
This sounds like a driver issue since the fault is occurring here:
QCamChildDriver.dll:0x160fdde4(0x0f99ef08, 15, 0x00ced938, 0x00ced938)
One possible issue - the driver might be in conflict with your OS, especially if you are running Vista or any 64 bit OS.
If it is a driver issue, you might be able to find updated drivers somewhere on line, even if the company is gone.
Other than that you might be up a creek, unless you can find the C-source for scratchML and/or the driver.
Problem solved:
I reinstalled the camera software and relevant QCam drivers, along with cleaning up a few other bugs.
If your camera uses firewire, you could try to use this tool.