Bug#999954: [Pkg-sugar-devel] Bug#999954: squeak-vm: depends on obsolete pcre3 library
Hi > On 19. Dec 2023, at 11:53, Jonas Smedegaard wrote: > > Hi Yavor, > > Quoting Yavor Doganov (2023-12-19 11:21:34) >> Please find attached a patch; unfortunately I could not find a way to >> test it. > > Thanks for the patch. > > Is it a patch that you composed yourself, or did you work based off of > some upstream changeset. There is no upstream changeset for that, sadly. We should pick that up probably. Best regards -Tobias Pape > > I ask because it is helpful to know how close we are to upstream code, > especially for changes that are tricky to test thoroughly. > > > Kind regards, > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > * Sponsorship: https://ko-fi.com/drjones > > [x] quote me freely [ ] ask before reusing [ ] keep private
Bug#892016: scratch: segfault in lookupMethodInClass upon trying to load an image from the webcam
Hi All
On Sat, 22 Sep 2018 09:40:35 +0300 Adrian Bunk wrote:
> Control: clone -1 -2
> Control: reassign -1 squeak-vm
> Control: reassign -2 squeak-plugins-scratch
>
> On Sun, Aug 05, 2018 at 07:33:58PM +0200, Bernhard Übelacker wrote:
> > Hello Wouter,
> > thanks for this additional information.
> >
> > I could reproduce the issue with a usb webcam inside a buster amd64 VM.
> > Unfortunately this camera button was with the german translation not
> > visible with the small resolution of that VM.
> >
> > It took a little time to get into the smalltalk side of things.
> > But I think I have found a problem - on the c side of the plugins.
> >
> >
> >
> > (gdb) bt
> > #0 0x7fffafa33c82 in convertImageRGB24toARGB32 (cam=0x7fffafa37180
> > ) at ./unix/plugins/CameraPlugin/sqCamera-linux.c:333
> > #1 0x7fffafa33f2a in convertImage (cam=0x7fffafa37180 ) at
> > ./unix/plugins/CameraPlugin/sqCamera-linux.c:412
> > #2 0x7fffafa34d10 in CameraGetFrame (camNum=1, buf=0x7fffb2b9fcb4 "",
> > pixelCount=76800) at ./unix/plugins/CameraPlugin/sqCamera-linux.c:836
> > #3 0x7fffafa3352c in primGetFrame () at
> > ./unix/src/plugins/CameraPlugin/CameraPlugin.c:160
> > #4 0x55578ca4 in dispatchFunctionPointer
> > (aFunctionPointer=0x7fffafa33461 ) at
> > ./build-tree/gnu-interp.c:3809
> > #5 0x555769f8 in callExternalPrimitive (functionID=0x7fffafa33461
> > ) at ./build-tree/gnu-interp.c:2512
> > #6 0x5558fc92 in primitiveExternalCall () at
> > ./build-tree/gnu-interp.c:17732
> > #7 0x55578ca4 in dispatchFunctionPointer
> > (aFunctionPointer=0x5558faf0 ) at
> > ./build-tree/gnu-interp.c:3809
> > #8 0x5558227a in interpret () at ./build-tree/gnu-interp.c:9339
> > #9 0x555a7cef in main (argc=8, argv=0x7fffe2a8,
> > envp=0x7fffe2f0) at ./unix/vm/sqUnixMain.c:1458
> >
> > (gdb) list convertImageRGB24toARGB32
> > 319 static void
> > 320 convertImageRGB24toARGB32 (camPtr cam)
> > 321 {
> > 322 unsigned char *src = cam->inBuffer;
> > 323 unsigned long int *dst = cam->sqBuffer; <--
> > sizeof(*dst) == 8, should be 4 ?
> > 324 unsigned long int pixelCount = cam->sqPixels;
> > 325 unsigned long int pixel;
> > 326 int i;
> > 327
> > 328 if (0 == dst) return;
> > 329
> > 330 for ( i = 0; i < pixelCount; i++) {
> > 331 pixel = 0xFF00 | (*src++ << 16);
> > 332 pixel = pixel | (*src++ << 8);
> > 333 *dst++ = pixel | *src++;
> > 334 }
> > 335 }
> >
> >
> >
> > Here the buffer allocated in the squeak-vm is given to primGetFrame
> > and gets finally the image written to in convertImageRGB24toARGB32.
> > Unfortunately these conversion functions use "unsigned long int *dst",
> > with a long int having a size of 8 bytes at amd64, while we got
> > just 4 bytes per pixel reserved from squeak-vm, therefore
> > overrunning our reserved buffer.
> >
> >
> > When just installing the packages the plugin so.CameraPlugin gets
> > used from the package squeak-plugins-scratch.
I fixed that in the Camera Plugin last year and it is used in the current,
OpenSmalltalk-VM/Cog-based Squeak as such:
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/203de239312943d2d8be86ecec306a6f9971f49e
I think this diff is independent of OpenSmalltalk VM and should work with the
interpreter-based sources of Squeak VM 4.10 as used with this package and
Scratch.
Hope this helps.
Best regards
-Tobias
Bug#872252: Debian squeak-vm bug #862576 etoys: Doesn't get beyond Squeak security key generation
Dear Petter and all interested, > On 30.08.2017, at 19:14, David T. Lewis wrote: > > Hi Petter, > > Thank you for your reply. If you have a chance, could you please try > compiling the VM from sources on your own Debian development system, and > try running the Etoys image to see if it works. I have no way to test this > myself, and I have not been able to find someone in the Squeak community > with a suitable development level Debian system to do the test. I expect > that you can do this in 15 minutes or less, as it is just a matter of > doing a "make; sudo make install". > > To ensure that we are working from a common reference point, please use > the sources that I put here: > > https://drive.google.com/file/d/0Bzi8Tf4EvjhoYTNEUDRCc09KOEk/view?usp=sharing > To follow up here, I not only managed to easily build the with the provided snapshot/script, but also it just works starting up. (screenshot attached). @David: I had just forgotten a step in my setup; yes everything works neatly. Also, everybody feel free to contact me for things debian+squeak or debian+etoys, I'll try to help in any way I can. Best regards -Tobias > Thank you very much! > Dave > >> >> Hi, and thank you for reaching out. >> >> [David T. Lewis] >>> I am an upstream maintainer for the traditional Squeak VM, which is >>> package squeak-vm on Debian. Etoys is an important package for kids >>> around the world, so I would like to help resolve the squeak-vm package >>> issue that is causing problems for Etoys on Debian, as documented in >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862576. Although I am >>> not a Debian developer (and I do not have an up to date Debian system >>> for testing), I may be able to provide some useful guidance, and I would >>> be happy to collaborate with the squeak-vm package maintainers to >>> resolve >>> the issue. >> >> Note, dropping the reduced optimizing flag is tracked as bug #872252, so >> lets follow up there instead. I bounced your original email there, and >> changed the To: field appropriately. >> >> Note, I am not much involved in the maintenance of Squeak VM in Debian, >> but come from the Debian Edu side where we use it. :) >> >>> I do need some help to get this sorted out, so please consider this a >>> plea >>> for assistance :-) >>> >>> Background: >>> >>> The squeak-vm package is based on a fairly old snapshot of the source >>> code >>> from the upstream squeakvm.org site, and has accumulated various patches >>> and changes since that snapshot of the sources. The current upstream >>> sources >>> are greatly improved since the snapshot on which the Debian squeak-vm >>> package >>> is based, and is suitable for running the Etoys package on both 32-bit >>> and >>> 64-bit distributions. >> >> One thing that would help the maintainers is to know which of the 5 >> patches in >> https://sources.debian.net/patches/squeak-vm/1:4.10.2.2614-4.1/ > >> are now included in the official upstream source. Can you tell? >> >>> The current sources are easily compiled, and are known to work with >>> the Etoys image on recent Debian-based distributions. Having said >>> that, I do not know for sure, and cannot guarantee, that there will >>> not be issues on the latest Debian version. However, if problems arise >>> I am fairly confident that we will be able to resolve them through a >>> bit of email collaboration. >> >> Is it running in valgrind without any issues reported? Does it build >> with both the most recent gcc and clang compilers? Those tests tend to >> weed out quite a few bugs, so I thought it best to ask early. :) >> >>> What we need to do: >>> >>> Replace the old source package for squeak-vm with a source snapshot >>> based >>> on the current upstream sources at squeak-vm.org. I expect that this >>> will >>> produce a reliable squeak-vm for both 32-bit and 64-bit distributions. >>> We >>> will need to confirm this by running Etoys on the new VM. >> >> Why a snapshot and not a release? >> >> -- >> Happy hacking >> Petter Reinholdtsen >> > >
