Bug#1024757: Editor: -key ignored

The root cause of this problem with openscad is this upstream bug in Qt: https://bugreports.qt.io/browse/QTBUG-95108 The symptoms are that in some keyboard layouts, the Qt::GroupSwitchModifier is handled incorrectly, causing some keys to not respond correctly in certain applications. This bug

Bug#1024757: Editor: -key ignored

"Dr. Nikolaus Klepp" writes: > Ok, setting the keyboard layout to US makes working again. Here 3x > : Thanks for the additional test. That data point does suggest that the QT bug is the root cause. >> 3. It would be interesting to try to downgrade Qt to some 5.15.4 version and >> see if that

Bug#1024757: Editor: -key ignored

Thanks a lot for the additional information, "Dr. Nikolaus Klepp" writes: > This is what I get when I run "openscad --debug=scintillaeditor": > > Pressing 3 times: > scintillaeditor: KeyRelease - modifiers: shift ctrl alt meta keypad GROUP > scintillaeditor: KeyRelease - modifiers: shift ctrl

Bug#1024757: Editor: -key ignored

I did not manage to find a way to reproduce myself. But I found that openscad has some debugging option that may provide additional information. Can you try to run openscad with the --debug option: openscad --debug=scintillaeditor and then reproduce the problem with the ENTER key and note

Bug#1024757: Editor: -key ignored

Kristian Nielsen writes: > I had some problems running openscad in my unstable/sid environment to try to > reproduce this. I will try to solve this, but meanwhile... I managed to run the latest openscad package in unstable. I did not see the problem, the key worked fine to insert a line

Bug#1024757: Editor: -key ignored

"Dr. Nikolaus Klepp" writes: > Package: openscad > Version: 2021.01-5+b2 > After yesterdays upgrade openscad ignores the -key > > Expected: > - press --> editor performs linebreak. > > Observed: > - press --> nothing happen, the key is ignored. > - press + --> editor performs linebreak.

Bug#1009682: ghostscript breaks openscad autopkgtest

Control: reassign Thanks for the report, I will upload shortly a fixed openscad package. - Kristian. Paul Gevers writes: > With a recent upload of ghostscript the autopkgtest of openscad fails > in testing when that autopkgtest is run with the binary packages of > ghostscript from unstable.

Bug#1005641: openscad: Out-of-bounds memory access (CVE-2022-0496 and CVE-2022-0497)

Public upstream bug reports: https://github.com/openscad/openscad/issues/4037 https://github.com/openscad/openscad/issues/4043

Bug#1005641: openscad: Out-of-bounds memory access (CVE-2022-0496 and CVE-2022-0497)

Source: openscad Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Upstream has reported two out-of-bounds memory access bugs, which have been assigned CVEs:

Bug#996023: Acknowledgement (buster-pu: package openscad/2019.01~RC2-2)

The openscad bug tracking this issue is #996020: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996020 - Kristian.

Bug#996023: buster-pu: package openscad/2019.01~RC2-2

Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu [ Reason ] This is a fix for two minor security issues in buster: https://security-tracker.debian.org/tracker/CVE-2020-28599

Bug#996020: openscad: Buffer overflows in STL parser (CVE-2020-28599, CVE-2020-28600)

Package: openscad Version: 2019.01~RC2-2 Severity: important There is a bug in the import() function in OpenSCAD when importing STL files. Certain invalid files can cause out-of-bounds accesses, potentially causing arbitrary code execution. The bug is associated with these CVEs:

Bug#985903: lib3MF.so.1: undefined symbol: zip_fclose

Not 100% clear what the issue(s) reported here are, but I looked through the patches, and saw these: 1. Some libz/libzip changes. I'm guessing these are to avoid having to add -lz/-lzip to the using project? There was a related change in the recent NMU, 1.8.1+ds-3.1, which instead adds links to

Bug#986328: unblock: lib3mf/1.8.1+ds-4

(CVE-2021-21772), backporting fix from v2.1.1 +(Closes: #985092) + + -- Kristian Nielsen Thu, 01 Apr 2021 21:25:54 +0200 + lib3mf (1.8.1+ds-3.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru lib3mf-1.8.1+ds/debian/control lib3mf-1.8.1+ds/debian/control --- lib3mf-1.8.1+ds

Bug#978717: RFS: openscad/2019.05-4 [RC] -- script file based graphical CAD environment

Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for a new upload for package "openscad", which I have been maintaining for a couple years. This upload fixes a FTBFS and is needed to get openscad back into the archive. * Package name: openscad

Bug#947196: "BadMatch" error on X_ShmPutImage when using GLX_ALPHA_SIZE

? - Kristian. commit 7225800b534a36e5ad84c56c274889b8d0edc0ce (HEAD -> newstuffs, salsa/newstuffs) Author: Kristian Nielsen Date: Tue Dec 24 11:05:45 2019 +0100 Add a patch to work-around test failures against latest mesa diff --git a/debian/changelog b/debian/changelog index 9ca95

Bug#947196: "BadMatch" error on X_ShmPutImage when using GLX_ALPHA_SIZE

I managed to reproduce without openscad, using a slightly modified glxgears from mesa-demos: --- --- glxgears.c.orig 2019-12-23 20:57:04.565366089 +0100 +++ glxgears.c 2019-12-23 20:57:53.933591974 +0100 @@ -503,6 +503,8 @@

Bug#947196: Acknowledgement (mesa: "BadMatch" error on X_ShmPutImage in 24bpp; breaks openscad testsuite)

Some additional data: The error occurs when openscad tries to run glXSwapBuffers(). Here are the attributes requested from glXChooseFBConfig() and the list of XVisualInfo returned: int attributes[] = { GLX_DRAWABLE_TYPE, GLX_WINDOW_BIT | GLX_PIXMAP_BIT | GLX_PBUFFER_BIT,

Bug#947196: mesa: "BadMatch" error on X_ShmPutImage in 24bpp; breaks openscad testsuite

Source: mesa Version: mesa-19.3.1-2 Severity: important Dear Maintainer, Since upload to unstable of mesa 19.3.1-1/19.3.1-2, the openscad testsuite breaks. This also shows up as a regression on https://tracker.debian.org/pkg/mesa . The root cause is the following failure to run openscad in a

Bug#945162: Build fails on some (Ubuntu) builders due to lack of memory

How about this? It uses --max-parallel to limit build to one process per 3 GB of memory: https://salsa.debian.org/knielsen-guest/openscad/commit/3c64461f18762bbc2a1eebefe3c5f8880726791a This should prevent builds failing due to out-of-memory on small machines, and still allow most machines to

Bug#945162: Build fails on some (Ubuntu) builders due to lack of memory

Sebastien Bacher writes: > because it uses more memory than available. The attached patch makes it > build with --no-parallel which workarounds the issue, what would you Hm, this seems to be the wrong place to put this? If a build machine has too little memory for a --parallel build of a

Bug#941100: openscad FTCBFS: python3 build dependency not installable

Helmut Grohne writes: > openscad fails to cross build from source, because its python3 > dependency cannot be installed for the host architecture. It actually > wants to run python3 during build, so it needs the build architecture > python3. Thus it should be annotated :any. Please consider

Bug#933209: mark openscad-mcad Multi-Arch: foreign

On Sat, 27 Jul 2019 17:06:50 +0200 Helmut Grohne wrote: > openscad fails to cross build from source, because its build dependency > on openscad-mcad is unsatisfiable. In general, Architecture: all > files (textual). Please mark it Multi-Arch: foreign. Thanks, Helmut, sounds good. I will

Bug#802898: General OpenSCAD limitation

I believe this is caused by a general limitation of OpenSCAD. When multiple shapes are combined, the shapes must not share an edge or face exactly. There is some explanation of this in the OpenSCAD manual: https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/STL_Import_and_Export#STL_Export One

Bug#852495: [debian-mysql] Bug#852495: Bug#852495: mariadb-server-10.[01]: purging old mariadb-server shuts down mariadb-server and removes init.d links

Otto Kekäläinen writes: > Tags: unreproducible > > 2017-01-25 0:21 GMT+02:00 Julian Gilbey : >> After upgrading to 10.1 from 10.0, I purged the old >> mariadb-server-10.0 package, but this had two quite unpleasant >> effects: it shut down the server and it

Bug#848287: [debian-mysql] Fwd: osmalchemy is marked for autoremoval from testing

Otto Kekäläinen writes: > On a quick look the solution suggested by Kristian looks OK. I will > eventually do something to implement and test it, but if somebody has > time to do it right now and send me a git merge request (or Github > pull request) then things would progress

Bug#848287: [debian-mysql] Fwd: osmalchemy is marked for autoremoval from testing

"Norvald H. Ryeng" writes: > On Thu, 12 Jan 2017 13:16:32 +0100 > Dominik George wrote: >> This package does not require Oracle's MySQL, it requires a root user >> that can authenticate to the database and use it in its entirety, a >> feature which

Bug#843844: [debian-mysql] Bug#843844: Potentially missing files from mariadb-10.0 packages

Otto Kekäläinen writes: > - example configs are outdated anyway, probably no point including them at all Sounds reasonable. > - mytop maybe? There is a separate `mytop' package in Debian, so probably not. I remember previous discussions about this. If something is missing in

Bug#842454: [debian-mysql] Bug#842454: Bug#842454: default-libmysqlclient-dev is unsatisfiable for cross builds

Otto Kekäläinen <o...@debian.org> writes: > 2016-10-30 1:45 GMT+03:00 Kristian Nielsen <kniel...@knielsen-hq.org>: >> Maybe something like this is needed on the cmake command? >> >> -DINSTALL_PLUGINDIR=/usr/lib/x86_64-linux-gnu/mysql/lib18/plugin >>

Bug#842454: [debian-mysql] Bug#842454: Bug#842454: default-libmysqlclient-dev is unsatisfiable for cross builds

Helmut Grohne writes: > | dpkg: error processing archive > /tmp/apt-dpkg-install-qGtx4F/3-libmariadbclient18_10.0.27-2_i386.deb > (--unpack): > | trying to overwrite shared '/usr/lib/mysql/plugin/dialog.so', which is > different from other instances of package

Bug#838914: [debian-mysql] Bug#838914: mariadb-10.0: testsuite failures on mips/mipsel

FYI, James Cowgill writes: > mips-machine.patch > Fix the value of DEFAULT_MACHINE on 32-bit mips platforms. I've upstreamed this patch, it should appear in MariaDB 10.0.28. > mips-groonga-atomic.patch > Link groonga against libatomic as it uses 64-bit atomic operations

Bug#838557: [debian-mysql] Bug#838557: mariadb-10.0: FTBFS on mips64el

James Cowgill writes: >>> Currently mariadb-10.0 FTBFS on mips64el due to various testsuite >>> failures. The two attached patches should resolve this. I am also >>> mips-errno-enotempty.patch >>> On mips* architectures, ENOTEMPTY == 93 which wasn't handled by two test >>>

Bug#837369: [debian-mysql] Bug#837369: mariadb-10.0: FTBFS on hppa

John David Anglin writes: > The build fails because the following two tests fail: > rpl.rpl_drop_db binlog.binlog_database > These two tests fail because the error number for ENOTEMPTY is 247 on hppa: > dave@mx3210:/usr/include$ find . -name errno.h|xargs grep 247 >

Bug#809022: [debian-mysql] Bug#809022: Bug#809022: Bug#809022: autopkgtest patch for MariaDB

Kristian Nielsen <kniel...@knielsen-hq.org> writes: > And I'll see if I can fix mysql-test-run.pl upstream to not need '.' in > @INC. Otherwise, this problem will probably show up in other places sooner > or later... I've now pushed to upstream 10.0 a patch so that mysql-test

Bug#809022: [debian-mysql] Bug#809022: Bug#809022: autopkgtest patch for MariaDB

Paul Gevers writes: > I rather expect in the tool-chain. Has anybody seen the recent change in > Perl? Your remarks about including ./ in the Perl path sounds exactly > like the change that was recently made: > >

Bug#809022: [debian-mysql] Bug#809022: Bug#809022: autopkgtest patch for MariaDB

Otto Kekäläinen <o...@debian.org> writes: > 2016-09-09 23:04 GMT+03:00 Kristian Nielsen <kniel...@knielsen-hq.org>: >> ci.debian.net, maybe the docs have something, I can try looking. How is this >> configured, is everything in the debian packaging, read by autopkgt

Bug#809022: [debian-mysql] Bug#809022: Bug#809022: autopkgtest patch for MariaDB

Otto Kekäläinen writes: > Thank you very much Kristian for looking into this and producing a > potential fix. Unfortunately I don't have any environment where I > could test it, and I am a bit reluctant to apply the patch and test it > in production unless somebody confirms that

Bug#809022: [debian-mysql] Bug#809022: Bug#809022: autopkgtest patch for MariaDB

Otto Kekäläinen writes: > I uploaded now 10.0.27 and even with the recent fixes, it is still > failing. I don't know how to fix it. Can you Paul help debug it? > https://ci.debian.net/data/packages/unstable/amd64/m/mariadb-10.0/20160909_103759.autopkgtest.log.gz > starting

Bug#759309: [debian-mysql] Bug#759309: Bug#759309: Must not Provide: libmysqlclient-dev

Otto Kekäläinen o...@seravo.fi writes: Upstream MariaDB only ships with libmysqlclient.so, while I have changed the Debian version to ship the library using the name libmariadbclient.so, because I got feedback that it is not good policy for the MariaDB package to ship a so name that also

Bug#739452: [debian-mysql] Bug#739452: libmariadbclient18: arch-dependent files in Multi-Arch: same package

Jakub Wilk jw...@debian.org writes: If a package is marked as Multi-Arch: same, it should be co-installable with itself. This is currently not the case because of the two files mentioned in my original mail: Selecting previously unselected package libmariadbclient18:amd64. Preparing to

Bug#736087: [debian-mysql] Bug#736087: mysql-5.5: Please install AppArmor profile on Debian too

intrig...@debian.org writes: debian/rules only installs the usr.sbin.mysqld AppArmor profile on Ubuntu (no idea why this is done in override_dh_installlogrotate-arch, by the way; looks like a buggy merge to me, but anyway, that's off-topic for now). In my experience, there are a lot of

Bug#736087: [debian-mysql] Bug#736087: Bug#736087: mysql-5.5: Please install AppArmor profile on Debian too

intrigeri intrig...@debian.org writes: Hi, Kristian Nielsen wrote (21 Jan 2014 09:18:05 GMT) : In my experience, there are a lot of problems with installing an apparmor profile by default for the MySQL server. This is from 4 years of experience maintaining MariaDB .deb packages. Thank you

Bug#702280: Add alternative (build-)dependency: libmariadbclient-dev

Otto Kekäläinen o...@seravo.fi writes: Ok, we can postpone the upload but could we now try to figure out the technical solution of what will be eventually uploaded? Maybe we could handle this by initially changing the Depends: on libdbd-mysql-perl to a Recommends: ? That would allow to upload

Bug#565308: [debian-mysql] MariaDB in Debian proper?

Jonathan Aquilina eagles051...@gmail.com writes: it was mentioned to give a user choice as to what to use. i have seen for instance when you install gnome aside kde it asks you what desktop manager you want to use. Wouldnt something like that be needed in this situation? Gnome and KDE are

Bug#565308: [debian-mysql] MariaDB in Debian proper?

Jonathan Aquilina eagles051...@gmail.com writes: then in that case why not setup mysql-server as a dependency for MariaDB? I don't understand. Mariadb provides mysql-server. It doesn't depend on it. - Kristian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a

Bug#565308: MariaDB in Debian proper?

Lionel Elie Mamane lio...@mamane.lu writes: The main issue that needs solving is to let MySQL and MariaDB packages co-exist in the same repository. So they _do_ need some more work :) Yes. The existing packages are not suitable as-is for inclusion in Debian because of this issue. The

Bug#565308: MariaDB in Debian proper?

Lionel Elie Mamane lio...@mamane.lu writes: On Tue, Feb 09, 2010 at 10:40:59PM +0100, Kristian Nielsen wrote: Some additional information that might be useful: - apt-able repositories of MariaDB are available from http://ourdelta.org/ - Package scripts for .deb are maintained on Launchpad

Bug#565308: Additional information about existing work on .debs available

Some additional information that might be useful: - apt-able repositories of MariaDB are available from http://ourdelta.org/ - Package scripts for .deb are maintained on Launchpad: https://launchpad.net/ourdelta - Build of packages are automated in Buildbot:

Bug#399035: LD_LIBRARY_PATH=/usr/lib/debug causes switch to ancient libpthread

-a Linux ymer 2.6.13.4 #3 Thu Oct 27 01:07:26 CEST 2005 i686 GNU/Linux $ ls -l /lib/libc.so.6 lrwxrwxrwx 1 root root 13 2006-05-14 15:06 /lib/libc.so.6 - libc-2.3.6.so -- Kristian Nielsen, Software Developer MySQL AB, www.mysql.com Are you MySQL certified? www.mysql.com/certification