Activity for Roland Rosenfeld
-
Roland Rosenfeld created ticket #201
htmldoc 1.9.22 breaks on drawing.html (patch)
-
CVE-2025-31164
-
CVE-2025-31163
-
CVE-2025-31162
-
The attached patch should fix the above mentioned problem with true/false variable names. Using this with in combination with current GIT tree allows to compile xfig with GCC 15.
-
I just noticed, that Mario Haustein already fixed the prototypes in GIT. But when I try to build the GIT version with GCC-15, I still run into the following error: main.c:123:17: error: expected identifier or '(' before 'true' 123 | static Boolean true = True; | ^~~~ main.c:124:17: error: expected identifier or '(' before 'false' 124 | static Boolean false = False; | ^~~~~ main.c:198:66: error: lvalue required as unary '&' operand 198 | XtOffset(appresPtr, allownegcoords), XtRBoolean, (caddr_t) &...
-
fig2dev: incompatible with GCC 15 C23 standard
-
I just noted, that https://sourceforge.net/p/mcj/fig2dev/ci/ab4eee3cf0d0c1d861d64b9569a5d1497800cae2/ already fixes this issue.
-
xfig: incompatible with GCC 15 C23 standard
-
fig2dev: incompatible with GCC 15 C23 standard
-
pdf export does not work
-
Sounds to me that you have to install the ghostscript package to make this work (gs is the short name of ghostscript).
-
Looks very good to me. The only thing that first confused me a little is the double "xfig.xfig", but this seems to be somewhat common to have the reverse domain "org.xfig" first and the application name added later (like org.kde.digikam). It's not that open that domain name and application name are identical and on my (small) system these cases often use a application name with upper case (org.flameshot.Flameshot.desktop, org.fontforge.FontForge.desktop, org.freecadweb.FreeCAD.desktop, org.keepassxc.KeePassXC.desktop),...
-
I just cross-checked that this issue was introduced in 3.2.9 and didn't exist in 3.2.8b. 3.2.8b also has a buffer overflow on trying to export the dimensionsline.fig created by 3.2.9, but it does not generate those broken coordinates on user-defined-text dimension-lines itself.
-
User defined text brakes Dimension Lines
-
buffer overflow in regression test 776
-
Sometimes I only need to write down my problem and find the solution minutes later... The issue is already fixed in 19d7684ca10f6c1279568aa19e9a9da2276851f1. So I close this ticket now...
-
buffer overflow in regression test 776
-
You are right, the second ", ignore" does the trick, now the testsuite does not longer fail.
-
I'll dive deeper into this later. Here's the testsuite.dir/073/testsuite.log attached.
-
Good to hear, since Debian just introduced gs 10.03 in the unstable distribution, which resulted in building fig2dev failing because of test 108. bitmaps.at:258: FAILED (bitmaps.at:261) So I just applied commit https://sourceforge.net/p/mcj/fig2dev/ci/0421812adafd9924766626d8b88cb9eb6a985361/ but now the new test 73. output.at:131: 73. create pdf version 1.1 (output.at:131): FAILED (output.at:133) fails (with the above mentioned gs warnings).
-
Here is a slightly updated version (but still some warnings aboutn the screenshot sizes)
-
Maybe the file should be tuned even more, since appstream-util validate reports some problems: • tag-missing : <content_rating> required [use https://odrs.gnome.org/oars] • attribute-invalid : <screenshot> width (359) too small [https://mcj.sourceforge.net/images/library-icon-view.png] minimum is 624px • attribute-invalid : <screenshot> width (450) too small [https://mcj.sourceforge.net/images/file-panel.png] minimum is 624px • attribute-invalid : <screenshot> width (319) too small [https://mcj.sourceforge.net/images/color-panel.png]...
-
Maybe the file should be tuned even more, since appstream-util validate reports some problems: • tag-missing : <content_rating> required [use https://odrs.gnome.org/oars] • attribute-invalid : <screenshot> width (359) too small [https://mcj.sourceforge.net/images/library-icon-view.png] minimum is 624px • attribute-invalid : <screenshot> width (450) too small [https://mcj.sourceforge.net/images/file-panel.png] minimum is 624px • attribute-invalid : <screenshot> width (319) too small [https://mcj.sourceforge.net/images/color-panel.png]...
-
appstream metainfo file missing
-
xfig: Ignores "print only active" checkbox in print dialog
-
3.2.9 (and before) testsuite: 17 106 108 failed
-
The test 106 (bitmaps.at:249) should be a known incompatibility with new ghostscript 10.02. I reported it in https://sourceforge.net/p/mcj/tickets/160/ and it is already fixed in GIT https://sourceforge.net/p/mcj/fig2dev/ci/ebbb9e22afa6b2646d8cd9c359d62b604fc7f9d4/ But I have no idea, what's going wrong in test 108 (bitmaps.at:260). This should simply convert a small fig file to pdf, but fails on your system with a ghostscript error. Since this issue doesn't happen on Debian systems (which also uses...
-
xfig man page: backslash encoding
-
BTW: The root cause (in Ghostscript) was fixed in https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=9b6fe6
-
ghostscript 10.02 fails on eps2write -sPageList=1 (patch included)
-
test 106 fails with ghostscript 10.02 (number of black pixels)
-
sometimes fig2dev does not insert prolog for UTF-8 fonts into EPS file
-
Debian 12 installation of .DEB file fails.
-
Debian 12 installation of .DEB file fails.
-
The Debian package privoxy_3.0.34-1~pp+1_amd64.deb isn't intended for Debian bookworm (12) bu for Debian bullseye (11) as the containing foldername "3.0.34 (stable) bullseye" mentions. On Debian bookworm you should just use privoxy 3.0.34-1 that's shipped with bookworm. Your observed incompatibility is that 3.0.34-1~pp+1 is compiled for bullseye, which uses libmbedcrypto3, libmbedtls12, libmbedx509-0. No idea what your Screenshot_20230627_083751.png refers, but this it not what dpkg --info privoxy_3.0.34-1~pp+1_amd64.deb...
-
I did some bisecting and found out, that the segfault was fixed with commit f35ead0ea199c8920aaa3c483f42d760d7a32fcf (HEAD) Author: Thomas Loimer thomas.loimer@tuwien.ac.at Date: Fri May 19 18:33:24 2023 +0200 Refactor sanitizing line objects, fixes ticket #152 A box object with three corners caused an invalid memory access. Such a box is now closed and converted to a polygon. on my system.
-
It should be fixed by Commit 1c4e13 not ebacf5 (which is only some doc update)
-
see also - https://bugs.debian.org/999981 (pcre bug report in Debian) - https://fedoraproject.org/wiki/PcreDeprecation
-
see also * https://bugs.debian.org/999981 (pcre bug report in Debian) * https://fedoraproject.org/wiki/PcreDeprecation
-
Upgrade PCRE to a newer version
-
I think we can close this developer-todo, since it refers to the packaged pcre library, which was removed in 3.0.33.
-
I think we can close this developer-todo, since it refers to the packaged pcre library, which was removed in 3.0.33.
-
I built the package identical to the Debian package, so I use mbettls instead of openssl. This means, that you need the mentioned dependencies. Just run "sudo apt --fix-boken install" as mentioned above (or "sudo apt-get -f install", which I usually use).
-
Okay, it's not a good idea to mix up the (old) Ubuntu package with a locally build privoxy. Since it seems that it's too hard for me to explain how to do this all the right way, I decided to build a Ubuntu focal package of privoxy 3.0.33. You can download it from my web page: https://www.spinnaker.de/tmp/privoxy_3.0.33-1~focal+1_amd64.deb So just remove the stuff under /usr/local/ you placed there using "make install", download the above package and install it using "dpkg -i privoxy_3.0.33-1~focal+1_amd64.deb"....
-
Don't know what exactly went wrong on your side. But some comments to the workflow: - why do you run autoheader after ./configure instead of before? - why do you only copy the privoxy binary instead of running "make install"? - I expect that the missing FEATURE_HTTPS_INSPECTION in show-status is the consequence of /etc/privoxy/templates/show-status not beeing updated but kept from a former version.
-
You need to install libssl-dev (don't miss the "-dev"!) on Ubuntu. Then you need to run ./configure --with-openssl Otherwise SSL won't be enabled. Alternatively you can install libmbedtls-dev and run ./configure --with-mbedtls Check the output of the last lines of the configure run, there should be configure: Detected OpenSSL. Enabling https inspection. or configure: Detected mbedTLS. Enabling https inspection. in one of the last lines. If you don't find on e of these lines, you won't have https...
-
I can reproduce the issue with privoxy 3.0.32, while everything is okay with 3.0.33. Seems that this is what the ChangeLog of 3.0.33 means with the following: Establish the TLS connection with the client earlier and decide how to route the request afterwards. This allows to change the forwarding settings based on information from the https-inspected request, for example the path. If you are using Debian bullseye, this comes with privoxy 3.0.32. You may think about using the 3.0.33 package, I uploaded...
-
I can reproduce the issue with privoxy 3.0.32, while everything is okay with 3.0.33. Seems that this is what the ChangeLog of 3.0.33 means with the following: Establish the TLS connection with the client earlier and decide how to route the request afterwards. This allows to change the forwarding settings based on information from the https-inspected request, for example the path. If you are using Debian bullseye, this comes with privoxy 3.0.22. You may think about using the 3.0.33 package, I uploaded...
-
I can reproduce the issue with privoxy 3.0.22, while everything is okay with 3.0.33. Seems that this is what the ChangeLog of 3.0.33 means with the following: Establish the TLS connection with the client earlier and decide how to route the request afterwards. This allows to change the forwarding settings based on information from the https-inspected request, for example the path. If you are using Debian bullseye, this comes with privoxy 3.0.22. You may think about using the 3.0.33 package, I uploaded...
-
Here's a minimal patch to use snprintf() instead of sprintf().
-
Potential Buffer Overflow getenv(LANG) in src/w_help.c
-
I'm not sure, whether this issue is really fixed. Have a look at my screenshots and fig files, you see a compound object consisting of an arc and a box (before). Then I move the lower right corner of the compound to the right. I'd expect the circle arc to become an eliptical arc, but the arc keeps beeing a part of a circle, which now "leaves" the box and the compound. This behavior can be explained, but isn't intuitive to me.
-
I'm not sure, whether this issue is really fixed. Have a look at my screenshots and fig files, you see a compound object consisting of an arc and a box (before). Then I move the lower right corner of the compound to the right. I'd expect the circle arc to become an eliptical arc, but the arc keeps beeing a part of a circle, which now "leaves" the box and the compound. This behavior can be explained, but isn't intuitive to me.
-
I'm not sure, whether this issue is really fixed. Have a look at my screenshots and fig files, you see a compound object consisting of an arc and a box (before). Then I move the lower right corner of the compound to the right. I'd expect the circle arc to become an eliptical arc, but the arc keeps beeing a part of a circle, which now "leaves" the box and the compound. This behavior can be explained, but isn't intuitive to me.
-
I'm not sure, whether this issue is really fixed. Have a look at my screenshots and fig files, you see a compound object consisting of an arc and a box (before). Then I move the lower right corner of the compound to the right. I'd expect the circle arc to become an eliptical arc, but the arc keeps beeing a part of a circle, which now "leaves" the box and the compound. This behavior can be explained, but isn't intuitive to me.
-
That might be my fault: I build xfig in the Debian package with libgs. But in the autopkgtest I forgot to depend on libgs-dev, so in the testing environment we have a different package set installed than when building xfig. As the result test3 behaves different in the autopkgtest than in the build environment. Maybe I should add test1, test2, test3 to the xfig package at build time and restore them o the test dir when doing the autopkgtest. But this means, that we ship three useless test binaries...
-
incorrect systemd service dependency
-
This is already fixed in version 3.0.28-3, which is available in Debian testing (bullseye) and sid (unstable), but not in the 3.0.28-1 version that is available on sourceforge.
-
Handling of libraries is rudimentary
-
Wish: Provide an interface for managing different depth combinations for fig2dev -D
-
Wish: add export options for fig2ps
-
Wish: PGF export (incl. patch)
-
Wish: PGF export (incl. patch)
-
PGF export
-
Wish: include support for sml
-
xfig terminates w/o warning if there is no space left on device
-
"Move Points" on compound breaks arc in compound
-
Crash while editing text element
-
line while drawing a line is invisivle
-
Bottom and right toolbars disappear after extreme resizing
-
Wish: Text justified vertically
-
zoom factor doesn't respect physical display size
-
dead keys do not work in text input
-
WISH: CAD-like catch for better drawing with lines
-
warning in test1.c
-
fig2dev crash in compute_closed_spline
-
fig2dev crash in compute_closed_spline
-
artifacts in PDF export
-
artifacts in PDF export
-
artifacts in PDF export
-
artifacts in PDF export
-
Seems that "wc -l" returns a trailing tab before the output on your system. So Thomas may need to add some code to to get rid of this (maybe append "| sed 's/^[ \t]*//' (replace \t with a TAB) or the like to the test code.
-
This is a problem with using tex instead of etex, which triggers on some TeX versions. It should be fixed in GIT commit https://sourceforge.net/p/mcj/fig2dev/ci/43bfd148609b33163f9ccdc7d350818f8005cb35/ Sie also https://bugs.debian.org/920368 and https://sourceforge.net/p/pgf/bugs/508/
-
https://bugs.debian.org/920368 You are right, using etex instead of tex solves this issue.
-
xfig: interpolated spline draws polyline instead
-
Cannot open xfig-full-3.2.7a.tar.xz
-
Since it's not an xfig bug an macOS issue, I close this ticket.
-
I know, what klicking on an icon means, but I still do not know what it means on macOS. Seems that for tar.xz files it means to create some unusable files...
-
I don't know, what "clicking on an icon" in macOS means, nor do I understand what all these freshly created files come from. I just downloaded xfig-full-3.2.7a.tar.xz from the NetCologne SourceForge mirror. It has the following md5sum: 3019d82efaa1277493bd42e1970897af Please check this to prove, that we are talking about the same file. If I unpack this file with tar xvfJ, this results in two directories (fig2dev-3.2.7a and xfig-3.2.7a), which contain the sources of fig2dev and xfig. Maybe your system...
-
I don't know, what "clicking on an icon" in macOS means, nor do I understand what all these freshly created files come from. I just downloaded xfig-full-3.2.7a.tar.xz from the NetCologne SourceForge mirror. It has the following md5sum: 3019d82efaa1277493bd42e1970897af Please check this to prove, that we are talking about the same file. If I unpack this file with tar xvfJ, this results in two directories (fig2dev-3.2.7a and xfig-3.2.7a), which contain the sources of fig2dev and xfig. Maybe your system...
-
I don't know, what "clicking on an icon" in macOS means, nor do I understand what all these freshly created files come from. I just downloaded xfig-full-3.2.7a.tar.xz from the NetCologne SourceForge mirror. It has the following md5sum: 3019d82efaa1277493bd42e1970897af Please check this to prove, that we are talking about the same file. If I unpack this file with tar xvfJ, this results in two directories (fig2dev-3.2.7a and xfig-3.2.7a), which contain the sources of fig2dev and xfig. Maybe your system...
-
fig2dev: Invalid memory read crash while running with '-L pdf' option
-
fig2dev: global buffer overflow while running with '-L pdf' option
-
Bottom and right toolbars disappear after extreme resizing
-
In 3.2.7a this is really fixed :-)
-
xfig writes file in wrong directory when saving
-
I fear, that adding the files to 3.2.7 somewhat failed. The files are mentioned in CHANGES, but I cannot find them in the tarball (I expected them in fig2dev/i18n), nor are they mentioned in fig2dev/i18n/Makfile*.
-
more i18n files for fig2dev
1 >
Gen AI apps are built with MongoDB Atlas
Atlas offers built-in vector search and global availability across 125+ regions. Start building AI apps faster, all in one place.