Bug#1064598: [3dprinter-general] Bug#1064598: yagv: crashes with "module 'pyglet.graphics' has no attribute 'vertex_list'"
On Thu, Mar 28, 2024 at 09:37:18AM +0100, Petter Reinholdtsen wrote: > [Gregor Riepl 2024-02-26] > > Unfortunately, it appears that upstream project is dead. > > The last commit was in 2017, and any requests by @pere on their bug tracker > > fell on deaf ears: [2] > > > > It's regrettable, but I don't think yagv can be kept with the current > > situation. > > I agree. Someone need to take over yagl upstream development for it to > be sustainable in Debian. Time to file for removal? > > See https://bugs.debian.org/877377 > for my tries to find a new > upstream. Agreed. It's been a while and there are superior alternatives to yagv now. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#1061062: prusa-slicer: Impossible to use Gcode produced by prusa-slicer on Ender 3 S1 Pro
On Wed, Jan 17, 2024 at 09:30:47AM +0100, mathis wrote: > Package: prusa-slicer > Version: 2.5.0+dfsg-4 > Severity: normal > X-Debbugs-Cc: joussemetmat...@gmail.com > > Dear Maintainer, > -- Expected Scenario: > Ender 3 S1 reads the Gcode > > --Outcome of the actions: > I tried many times to export directly the gcode to the sd, export it and then > copy it to the sd, but non worked. > Gcode produced in prusa-slicer 2.50 and cannot be used on my Ender 3 S1 Pro. > > --Resolution > The problem has already been acknoledged > (https://github.com/prusa3d/PrusaSlicer/issues/8883) and has been fixed in > upstream. > Could you please update the version in stable to allow to overcome > this bug? Hi mathis, Reading through the bug report, I think there isn't actually a patch that I can backport into Debian. It looks like it's pushed out as a configuration update, which you should be able to get from the `Configuration > Check for configuration updates` menu item. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#1057465: ITP: heatshrink -- A data compression/decompression library for embedded/real-time systems
Package: wnpp Severity: wishlist Owner: Chow Loong Jin X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: heatshrink Version : 0.4.1 Upstream Contact: Scott Vokes * URL : https://github.com/atomicobject/heatshrink * License : ISC Programming Lang: C Description : A data compression/decompression library for embedded/real-time systems Heatshrink is a data compression/decompression library for embedded/real-time systems. Its key features are: - Low memory usage (as low as 50 bytes) It is useful for some cases with less than 50 bytes, and useful for many general cases with < 300 bytes. - Incremental, bounded CPU use You can chew on input data in arbitrarily tiny bites. This is a useful property in hard real-time environments. - Can use either static or dynamic memory allocation The library doesn't impose any constraints on memory management. - ISC license You can use it freely, even for commercial purposes. I will be maintaining this under the Debian 3D printing team as it is a transitive dependency of slic3r-prusa 2.7.0 which was recently released. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#1057321: gcolor3: cursor doesn't change to dropper and fails to get info of clicked colour
On Sun, Dec 03, 2023 at 12:04:08PM +, Derek Griffin wrote: > Package: gcolor3 > Version: 2.4.0-2 > Severity: normal > > Dear Maintainer, > > I attempted to use gcolor3 as intended but when I clicked the dropper > icon. The > cursor didn't change to a dropper and when clicking a colour anywhere > on screen > the program doesn't get any info. > > When running the program from a terminal the following error is > reported: > > Failed to pick color: > GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No > such interface “org.freedesktop.portal.Screenshot” on object at path > /org/freedesktop/portal/desktop > > * What outcome did you expect instead? > > The hex values of the selected colour to appear in the gcolor3 window. > > The colour pickers in GIMP and Geany work as expected. > > I use XFCE4. Please ask for more information. Please try installing xdg-desktop-portal-xapp, and seeing if that helps. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#1056335: ITP: libbgcode -- Prusa Block & Binary G-code reader / writer / converter
Package: wnpp Severity: wishlist Owner: Chow Loong Jin X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libbgcode Version : 0.0~git20231116.bc390aa Upstream Contact: Vojtech Bubnik * URL : https://github.com/prusa3d/libbgcode * License : AGPL-3.0 Programming Lang: C++, Python Description : Prusa Block & Binary G-code reader / writer / converter libbgcode is a library used to generate binary G-code for 3D printers. Binary G-code is a new G-code file format featuring the following improvements over the legacy G-code: . 1) Block structure with distinct blocks for metadata vs. G-code 2) Faster navigation 3) Coding & compression for smaller file size 4) Checksum for data validity 5) Extensivity through new (custom) blocks. For example, a file signature block may be welcome by corporate customers. I will be packaging this library under the Debian 3-D Printing Packages team as a build-dependency of slic3r-prusa. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#1041870: [3dprinter-general] Bug#1041870: slic3r-prusa FTBFS on i386
On Tue, Jul 25, 2023 at 12:09:51AM +0200, Christoph Berg wrote: > Re: Adrian Bunk > > 2. the following change: > > > > --- debian/rules.old2023-07-24 15:36:20.941771419 + > > +++ debian/rules2023-07-24 15:36:43.133759741 + > > @@ -5,7 +5,7 @@ > > # less debug info to avoid running out of address space > > ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel)) > > export DEB_CXXFLAGS_MAINT_APPEND += --param ggc-min-expand=5 -g0 > > -else ifneq (,$(filter $(DEB_HOST_ARCH), armhf)) > > The old command was wrong anyway, the pattern list comes first: > > ifneq (,$(filter armhf, $(DEB_HOST_ARCH))) > > Doesn't matter when it's a single item without % wildcards, but will > explode when adding more architectures. > > Christoph Both versions work identically :) To be perfectly honest though, I'd initially thought $(filter ...) only took one pattern, but I see that your version works because it takes multiple patterns in the first argument, whereas the old version would have worked with a $(filter ...) function that takes only one pattern. % cat test.mk all: ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel armhf)) @echo old=true else @echo old=false endif ifneq (,$(filter mips mipsel armhf, $(DEB_HOST_ARCH))) @echo new=true else @echo new=false endif % for i in mips mipsel armhf amd64 i386; do echo "DEB_HOST_ARCH=$i"; make -f test.mk DEB_HOST_ARCH=$i; done; DEB_HOST_ARCH=mips old=true new=true DEB_HOST_ARCH=mipsel old=true new=true DEB_HOST_ARCH=armhf old=true new=true DEB_HOST_ARCH=amd64 old=false new=false DEB_HOST_ARCH=i386 old=false new=false -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#1040751: ITP: nanosvg -- simple svg parsing library
On Mon, Jul 10, 2023 at 07:50:21AM +0200, Mathieu Malaterre wrote: > On Mon, Jul 10, 2023 at 6:03 AM Chow Loong Jin wrote: > > * Package name: nanosvg > > Version : 0~git20221204.1.9da543e > > Upstream Contact: https://github.com/memononen/nanosvg/issues > > * URL : https://github.com/memonenen/nanosvg > > https://github.com/memononen/nanosvg Whoops, nice catch thanks. > > * License : zlib > > Programming Lang: C > > Description : simple svg parsing library > > > > NanoSVG is a simple stupid single-header-file SVG parse. The output of > > the parser is a list of cubic bezier shapes. > [...] > > I will be packaging this library under the Debian 3-D Printing Packages > > team as a build-dependency of slic3r-prusa. > > 4 years ago the project was declared as not actively maintained: > > * > https://github.com/memononen/nanosvg/commit/25241c5a8f8451d41ab1b02ab2d865b01600d949 Yep I realize that, but unfortunately, while there is a network of forks, there doesn't seem to be a clear de-facto "upstream" apart from this one as far as I can tell. fltk's fork[1] appears to be the only one with versioned git tags, but it has no issue tracker or way to contact upstream short of creating a pull request. memononen's repo seems to be the original and the only one in the network with issues enabled. My intention here is to package the latest git snapshot of memononen/nanosvg, with the patch for this commit[2] from fltk/nanosvg applied for the use of slic3r-prusa 2.6.0. If this isn't acceptable, the only alternative I can see is to bundle the nanosvg headers somewhere in `debian/` or as a separate component tarball in slic3r-prusa, and patch slic3r-prusa's build system to use that, now that slic3r-prusa upstream's unbundled their copy. I had also considered asking slic3r-prusa's upstream to just bundle the copy of nanosvg that they need, but I think Debian generally leans towards unbundling libraries, not bundling new ones. I'm open to ideas -- I'm not sure what the best course of action is here. [1] https://github.com/fltk/nanosvg [2] https://github.com/fltk/nanosvg/commit/abcd277ea45e9098bed752cf9c6875b533c0892f -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#1040751: ITP: nanosvg -- simple svg parsing library
Package: wnpp Severity: wishlist Owner: Chow Loong Jin X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: nanosvg Version : 0~git20221204.1.9da543e Upstream Contact: https://github.com/memononen/nanosvg/issues * URL : https://github.com/memonenen/nanosvg * License : zlib Programming Lang: C Description : simple svg parsing library NanoSVG is a simple stupid single-header-file SVG parse. The output of the parser is a list of cubic bezier shapes. The library suits well for anything from rendering scalable icons in your editor application to prototyping a game. NanoSVG supports a wide range of SVG features, but something may be missing, feel free to create a pull request! The shapes in the SVG images are transformed by the viewBox and converted to specified units. That is, you should get the same looking data as your designed in your favorite app. NanoSVG can return the paths in few different units. For example if you want to render an image, you may choose to get the paths in pixels, or if you are feeding the data into a CNC-cutter, you may want to use millimeters. The units passed to NanoSVG should be one of: 'px', 'pt', 'pc' 'mm', 'cm', or 'in'. DPI (dots-per-inch) controls how the unit conversion is done. If you don't know or care about the units stuff, "px" and 96 should get you going. I will be packaging this library under the Debian 3-D Printing Packages team as a build-dependency of slic3r-prusa. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#1036899: logiops: logid does not work for MX Master 3
On Sun, May 28, 2023 at 11:01:16PM +0200, Hendrik Tews wrote: > Package: logiops > Version: 0.3.1-1 > Severity: important > X-Debbugs-Cc: none, Hendrik Tews > > Dear Maintainer, > > after upgrading to logiops version 0.3.1-1 the logid daemon does not > seem to do anything any more. For my configuration the symptom is that > the thumb button is no longer mapped to button 2. The problem seems to > be also present in the current upstream version (v0.3.2), see upstream > issue 387 (https://github.com/PixlOne/logiops/issues/387). > > For now I downgraded to 0.2.3-1+b1, which is still working fine. Hey Hendrik, Could you check if 0.3.1-1 (in unstable) or 0.3.2-1 (in experimental) is working for you? -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#1018895: gcolor3: color picking fails due to No such interface “org.freedesktop.portal.Screenshot”
On Thu, Jan 05, 2023 at 11:50:12AM +0200, jim_p wrote: > Package: gcolor3 > Version: 2.4.0-2 > Followup-For: Bug #1018895 > X-Debbugs-Cc: pitsior...@outlook.com > > Thank you for verifying it on gnome. I can't see the benefit of installing the > remaining xdg-desktop-portal packages. For instance, the one for kde wants to > install a ton of kde packages and the wlr one wants to install pipewire etc. > > On the other hand, I found this patch on its github page which may be related > to the issue. I am mentioning it here because all similar issues to the one > above were reported to gtk-related flatpak apps too. > > https://github.com/Hjdskes/gcolor3/commit/6699c150468e3af14c6a6d411abe6b83b44b4304 Hmm, as far as I can tell, that commit only changes the way libportal is configured and built from source. In a Debian packagea, this would be equivalent to building against libportal-gtk3, which gcolor3 already does. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#1023365: prusa-slicer: Wrong wxWidgets Version linked during debian Build resulting in instant SIGSEGV on launch (due to lacking wxWidgets 3.2 support)
On Wed, Dec 21, 2022 at 06:34:40PM +1300, Olly Betts wrote: > On Wed, Dec 21, 2022 at 11:21:03AM +0800, Chow Loong Jin wrote: > > I've fixed the segfault by applying the patch from [1], but there's one > > issue remaining -- PrusaSlicer fails to initialize GLEW due to [2], > > resulting in the plater screen not showing up, same as this SuperSlicer > > issue[3]. > > > > I've also attempted to roll PrusaSlicer back to wxwidgets3.0 > > Please don't do that. We're really close to eliminating wxwidgets3.0 > now, and we're not planning to include it in the bookworm release. > > We're going to switch to --disable-glcanvasegl in wxwidgets3.2 which > should solve the incompatibilities with GLEW which seem to be the > problem here. However that's an ABI breaking change affecting any > packages using wxwidgets3.2's OpenGL APIs so it needs coordinating > with the release team - Scott is currently working on that. Alright, I'll leave the slic3r-prusa as-is then. I'm guessing that a binNMU will take care of things when we get there. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#1023365: prusa-slicer: Wrong wxWidgets Version linked during debian Build resulting in instant SIGSEGV on launch (due to lacking wxWidgets 3.2 support)
block 1023365 by 1024147 retitle 1023365 Compatibility problems with wxwidgets3.2 thanks I've fixed the segfault by applying the patch from [1], but there's one issue remaining -- PrusaSlicer fails to initialize GLEW due to [2], resulting in the plater screen not showing up, same as this SuperSlicer issue[3]. I've also attempted to roll PrusaSlicer back to wxwidgets3.0, including dropping all the wx3.2-related distro patches but it segfaults for an entirely different reason now, and I haven't had the time to figure it out (it's starting to look like a gcc bug to do with std::vector, but that doesn't make any sense). [1] https://bugs.debian.org/1022234 [2] https://bugs.debian.org/1024147 [3] https://github.com/supermerill/SuperSlicer/issues/1093 -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#1022234: Cash in Prusa-Slicer
On Sat, Oct 29, 2022 at 01:51:51PM +0200, Thomas Viehmann wrote: > Hi, > > so the crash reported here seems to be due to the font not being initialized > (it is passed as NULL in the traceback). > If we initialize a frame before calling the CalcTextsize, this works - see > the attached. > It still prints errors "could not initialize glew" and the plater tab does > not render, but I guess this is a first step towards something. > > Best regards > > Thomas Thanks for the patch. Looks like it works, so I'll apply it -- it's still better than segfaulting. The plater tab rendering issue seems to be more of a glew/wxwidgets3.2 compilation config mismatch issue (glew is compiled without EGL support and wxwidgets3.2 is compiled with EGL support, so glewInit() returns GLEW_ERROR_NO_GLX_DISPLAY), see [1]. It'll be fixed in the wxwidgets3.2 package itself and then prusa-slicer will be rebuilt against it. Hopefully that ends our trouble with wxwidgets3.2. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024147 -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#1024869: gconf2: gsettings-data-convert fails to find global schemas if unrelated locally installed schemas exist
Package: gconf2 Version: 3.2.6-7ubuntu2 Severity: normal Tags: upstream patch Dear Maintainer, Running gsettings-data-convert in an environment where gsettings schemas exist in ~/.local/share/glib-2.0/schemas and/or /usr/local/glib-2.0/schemas results in /usr/share/glib-2.0/schemas not being searched for schemas. This comes from calling `g_settings_schema_source_lookup` with `recursive` parameter set to `FALSE`, and is fixed upstream: https://gitlab.gnome.org/Archive/gconf/-/commit/98ff7acca7595f508b094506195aeffaf2e8b74c Kind regards, Loong Jin -- System Information: Debian Release: bookworm/sid APT prefers kinetic-updates APT policy: (500, 'kinetic-updates'), (500, 'kinetic-security'), (500, 'kinetic'), (400, 'kinetic-proposed'), (100, 'kinetic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.8-hyper1+ (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_SG.utf8, LC_CTYPE=en_SG.UTF-8 (charmap=UTF-8), LANGUAGE=en_SG:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gconf2 depends on: ii dbus-user-session [default-dbus-session-bus] 1.14.0-2ubuntu3 ii dbus-x11 [dbus-session-bus] 1.14.0-2ubuntu3 ii gconf-service 3.2.6-7ubuntu2 ii gconf-service-backend 3.2.6-7ubuntu2 ii libc6 2.36-0ubuntu4 ii libgconf-2-4 3.2.6-7ubuntu2 ii libglib2.0-0 2.74.0-3 ii libxml2 2.9.14+dfsg-1 ii psmisc23.5-3 ii python3 3.10.6-1 gconf2 recommends no packages. Versions of packages gconf2 suggests: ii gconf-defaults-service 3.2.6-7ubuntu2 -- no debconf information signature.asc Description: PGP signature
Bug#1020779: slic3r-prusa: FTBFS on 32-bit arches
reassign 1020779 libcereal-dev 1.3.2+dfsg-2 thanks From the build log in [1], it looks like the build error is: CMake Warning at cmake/modules/Findcereal.cmake:6 (find_package): Could not find a configuration file for package "cereal" that is compatible with requested version "". The following configuration files were considered but not accepted: /usr/share/cmake/cereal/cerealConfig.cmake, version: 1.3.2 (64bit) Call Stack (most recent call first): CMakeLists.txt:448 (find_package) I think this is because /usr/share/cmake/cereal/cerealConfigVersion.cmake is not actually architecture-dependent despite being shipped in an arch:all package (libcereal-dev). [1] https://buildd.debian.org/status/fetch.php?pkg=slic3r-prusa=i386=2.5.0%2Bdfsg-1=1663915166=0 -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#989355: transition: tinyxml2
On Fri, Aug 20, 2021 at 12:23:46AM +0200, Sebastian Ramacher wrote: > On 2021-06-08 02:06:08 +0800, Chow Loong Jin wrote: > > On Sat, Jun 05, 2021 at 05:39:04PM +0800, Chow Loong Jin wrote: > > > On Wed, Jun 02, 2021 at 12:27:06PM +0200, Sebastian Ramacher wrote: > > > > On 2021-06-02 02:45:56, Chow Loong Jin wrote: > > > > > Package: release.debian.org > > > > > Severity: normal > > > > > User: release.debian@packages.debian.org > > > > > Usertags: transition > > > > > > > > > > There's been an ABI break without an upstream soname bump in > > > > > libtinyxml2-8, between upstream versions 8.0.0 and 8.1.0, see [1] and > > > > > [2]. To remedy this, I have uploaded version 8.1.0+dfsg-2 to > > > > > experimental with the library package renamed from libtinyxml2-8 to > > > > > libtinyxml2-8a. It is waiting in the NEW queue now. > > > > > > > > Please revert tinyxml2 in unstable to the state of 8.0.0+dfsg-2 to > > > > avoid uploads of reverse dependencies that are targetted for bullseye to > > > > be built against the broken version. > > > > > > Done -- uploaded 8.0.0+dfsg-2 as 8.1.0+really8.0.0+dfsg-1 to unstable > > > > > > Also reuploaded 8.1.0+dfsg-2 as 8.1.0+really8.1.0+dfsg-1 to experimental > > > to keep the relative order of the versions. > > > > The upstream developer has uploaded a 9.0.0 release with the desired > > soname bump to libtinyxml2.so.9, which I have packaged and uploaded into > > experimental as 9.0.0+dfsg-1. > > Please go ahead Thanks. Uploaded 9.0.0+dfsg-1 to unstable. -- Loong Jin signature.asc Description: PGP signature
Bug#991018: unblock: qreator/16.06.1-7
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package qreator. [ Reason ] Qreator is currently completely broken in testing (fails to startup, see bug #986697). The fix is in 16.06.1-6, but that release also included a few unrelated changes which I've reverted in 16.06.1-7. [ Impact ] Qreator fails to start up with an exception in testing, as per https://bugs.debian.org/986697 [ Tests ] Install qreator and verify that it launches [ Risks ] No risk -- it's currently completely broken in testing, and the fix is in 16.06.1-6. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] None unblock qreator/16.06.1-7 -- System Information: Debian Release: bullseye/sid APT prefers groovy-updates APT policy: (500, 'groovy-updates'), (500, 'groovy-security'), (500, 'groovy'), (400, 'groovy-proposed'), (100, 'groovy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.12.1-hyper1 (SMP w/8 CPU threads) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_SG.utf8, LC_CTYPE=en_SG.UTF-8 (charmap=UTF-8), LANGUAGE=en_SG:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff --git a/debian/changelog b/debian/changelog index c582cd8..644cc99 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,24 @@ +qreator (16.06.1-7) unstable; urgency=medium + + * [6451544] Revert "Reexport patches using gbp-pq" +This reverts commit 8dee7af8ba45f56b493f5b3d82876307283aae69. + * [143cdf2] Revert "Port to debhelper compat 13" +This reverts commit 9241568369785cab18fb1ac322d1945f1fa1946e. + * [c9a74fa] Revert "Update Standards-Version to 4.5.0" +This reverts commit f34db2f3ab9087a93dbdce9fb12c8abae340a16a. + + -- Chow Loong Jin Tue, 13 Jul 2021 01:25:19 +0800 + +qreator (16.06.1-6) unstable; urgency=medium + + * [8dee7af] Reexport patches using gbp-pq + * [e0f42ae] Fix crash on startup due to usage of ElementTree.getiterator() +(Closes: #986697) + * [9241568] Port to debhelper compat 13 + * [f34db2f] Update Standards-Version to 4.5.0 + + -- Chow Loong Jin Sun, 11 Apr 2021 15:56:22 +0800 + qreator (16.06.1-5) unstable; urgency=medium * [4eea653] Load current location from geoclue-2.0 asynchronously. diff --git a/debian/patches/Port-ElementTree.getiterator-usage-to-ElementTree.iter.patch b/debian/patches/Port-ElementTree.getiterator-usage-to-ElementTree.iter.patch new file mode 100644 index 000..934a0ee --- /dev/null +++ b/debian/patches/Port-ElementTree.getiterator-usage-to-ElementTree.iter.patch @@ -0,0 +1,34 @@ +From: Chow Loong Jin +Date: Sun, 11 Apr 2021 15:54:21 +0800 +Subject: Port ElementTree.getiterator() usage to ElementTree.iter() + +.getiterator() has been deprecated since python3.2 and has been removed from +python3.9 + +Bug-Debian: https://bugs.debian.org/986697 +--- + qreator_lib/Builder.py | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/qreator_lib/Builder.py b/qreator_lib/Builder.py +index 996f9ff..23fb2f8 100644 +--- a/qreator_lib/Builder.py b/qreator_lib/Builder.py +@@ -83,7 +83,7 @@ class Builder(Gtk.Builder): + tree = ElementTree() + tree.parse(filename) + +-ele_widgets = tree.getiterator("object") ++ele_widgets = tree.iter("object") + for ele_widget in ele_widgets: + name = ele_widget.attrib['id'] + widget = self.get_object(name) +@@ -105,7 +105,7 @@ class Builder(Gtk.Builder): + if connections: + self.connections.extend(connections) + +-ele_signals = tree.getiterator("signal") ++ele_signals = tree.iter("signal") + for ele_signal in ele_signals: + self.glade_handler_dict.update( + {ele_signal.attrib["handler"]: None}) diff --git a/debian/patches/series b/debian/patches/series index c1fa770..5beadc7 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -5,3 +5,4 @@ Port-to-libnm.patch Fix-IndexError-when-a-wifi-network-has-100-strength.patch Fix-python-pil-imports.patch python3-port.patch +Port-ElementTree.getiterator-usage-to-ElementTree.iter.patch signature.asc Description: PGP signature
Bug#989355: transition: tinyxml2
On Sat, Jun 05, 2021 at 05:39:04PM +0800, Chow Loong Jin wrote: > On Wed, Jun 02, 2021 at 12:27:06PM +0200, Sebastian Ramacher wrote: > > On 2021-06-02 02:45:56, Chow Loong Jin wrote: > > > Package: release.debian.org > > > Severity: normal > > > User: release.debian@packages.debian.org > > > Usertags: transition > > > > > > There's been an ABI break without an upstream soname bump in > > > libtinyxml2-8, between upstream versions 8.0.0 and 8.1.0, see [1] and > > > [2]. To remedy this, I have uploaded version 8.1.0+dfsg-2 to > > > experimental with the library package renamed from libtinyxml2-8 to > > > libtinyxml2-8a. It is waiting in the NEW queue now. > > > > Please revert tinyxml2 in unstable to the state of 8.0.0+dfsg-2 to > > avoid uploads of reverse dependencies that are targetted for bullseye to > > be built against the broken version. > > Done -- uploaded 8.0.0+dfsg-2 as 8.1.0+really8.0.0+dfsg-1 to unstable > > Also reuploaded 8.1.0+dfsg-2 as 8.1.0+really8.1.0+dfsg-1 to experimental > to keep the relative order of the versions. The upstream developer has uploaded a 9.0.0 release with the desired soname bump to libtinyxml2.so.9, which I have packaged and uploaded into experimental as 9.0.0+dfsg-1. The updated Ben file should now be: title = "tinyxml2"; is_affected = .depends ~ "libtinyxml2-8" | .depends ~ "libtinyxml2-8a" | .depends ~ "libtinyxml2-9"; is_good = .depends ~ "libtinyxml2-9"; is_bad = .depends ~ "libtinyxml2-8" | .depends ~ "libtinyxml2-8a"; -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#989355: transition: tinyxml2
On Wed, Jun 02, 2021 at 12:27:06PM +0200, Sebastian Ramacher wrote: > On 2021-06-02 02:45:56, Chow Loong Jin wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > There's been an ABI break without an upstream soname bump in > > libtinyxml2-8, between upstream versions 8.0.0 and 8.1.0, see [1] and > > [2]. To remedy this, I have uploaded version 8.1.0+dfsg-2 to > > experimental with the library package renamed from libtinyxml2-8 to > > libtinyxml2-8a. It is waiting in the NEW queue now. > > Please revert tinyxml2 in unstable to the state of 8.0.0+dfsg-2 to > avoid uploads of reverse dependencies that are targetted for bullseye to > be built against the broken version. Done -- uploaded 8.0.0+dfsg-2 as 8.1.0+really8.0.0+dfsg-1 to unstable Also reuploaded 8.1.0+dfsg-2 as 8.1.0+really8.1.0+dfsg-1 to experimental to keep the relative order of the versions. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#989355: transition: tinyxml2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition There's been an ABI break without an upstream soname bump in libtinyxml2-8, between upstream versions 8.0.0 and 8.1.0, see [1] and [2]. To remedy this, I have uploaded version 8.1.0+dfsg-2 to experimental with the library package renamed from libtinyxml2-8 to libtinyxml2-8a. It is waiting in the NEW queue now. The following packages are impacted, and I have successfully rebuilt all of them locally without sourceful changes, so binNMUs are all that are necessary for this transition. - basilisk2 - bullet - caveexpress - cppcheck - dart - encfs - fastdds - gazebo - ignition-common - ignition-fuel-tools - ignition-msgs - kodi-pvr-dvblink - kodi-pvr-nextpvr - kodi-pvr-vbox - kodi-pvr-zattoo - lgogdownloader - libexadrums - libmediainfo - mrpt - ros-image-pipeline - ros-kdl-parser - ros-pluginlib - ros-ros - ros-rospack - ros-urdf - sdpb - trigger-rally [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988986 [2] https://github.com/leethomason/tinyxml2/issues/867 Ben file: title = "tinyxml2"; is_affected = .depends ~ "libtinyxml2-8" | .depends ~ "libtinyxml2-8a"; is_good = .depends ~ "libtinyxml2-8a"; is_bad = .depends ~ "libtinyxml2-8"; -- System Information: Debian Release: bullseye/sid APT prefers groovy-updates APT policy: (500, 'groovy-updates'), (500, 'groovy-security'), (500, 'groovy'), (400, 'groovy-proposed'), (100, 'groovy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.12.1-hyper1 (SMP w/8 CPU threads) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_SG.utf8, LC_CTYPE=en_SG.UTF-8 (charmap=UTF-8), LANGUAGE=en_SG:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled signature.asc Description: PGP signature
Bug#983164: ITP: logiops -- Unofficial driver for Logitech mice and keyboards
Package: wnpp Severity: wishlist Owner: Chow Loong Jin X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: logiops Version : 0.2.2 Upstream Author : Name * URL : http://www.example.org/ * License : GPL-3+ Programming Lang: C++ Description : Unofficial driver for Logitech mice and keyboards logiops is an unofficial driver for Logitech mice and keyboard, allowing for remapping of mouse buttons, configuration of mouse gestures, dpi, high-resolution scrolling, and Logitech SmartShift™ parameters. Known supported models include: - Logitech MX Master 3 - Logitech MX Master 2S - Logitech MX Master - Logitech MX Vertical - Logitech MX Ergo - Logitech M720 Triathlon Mouse - Logitech M590 Multi-Device Silent - Logitech T400 Zone Touch Mouse A similar package to this is Solaar, but afaik Solaar only works with Logitech Unifying devices, not bluetooth devices. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#978617: liblog4cplus-2.0.5: liblog4cplus exports symbols from unrelated header-only library (Catch)
Package: liblog4cplus-2.0.5 Version: 2.0.5-2 Severity: important Dear Maintainer, liblog4cplus-2.0.5 is exporting symbols from the Catch:: namespace, causing slic3r-prusa's tests (using its own bundled Catch library) to fail with std::bad_alloc. slic3r-prusa currently FTBFS due to this issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975198 Stacktrace below (note how some of the `Catch::` symbols are resolved from a local file, and some are from liblog4cplus-2.0.so.3: (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x77096537 in __GI_abort () at abort.c:79 #2 0x774507ec in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x7745b966 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #4 0x7745b9d1 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #5 0x7745bc65 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #6 0x77452f0f in std::__throw_bad_alloc() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #7 0x5565b12a in __gnu_cxx::new_allocator, std::allocator > >::allocate (__n=18446744073575334106, this=) at /usr/include/c++/10/ext/new_allocator.h:106 #8 std::allocator_traits, std::allocator > > >::allocate (__n=18446744073575334106, __a=...) at /usr/include/c++/10/bits/alloc_traits.h:460 #9 std::_Vector_base, std::allocator >, std::allocator, std::allocator > > >::_M_allocate (this=0x7fffe670, __n=18446744073575334106) at /usr/include/c++/10/bits/stl_vector.h:346 #10 std::_Vector_base, std::allocator >, std::allocator, std::allocator > > >::_M_create_storage ( __n=18446744073575334106, this=0x7fffe670) at /usr/include/c++/10/bits/stl_vector.h:361 #11 std::_Vector_base, std::allocator >, std::allocator, std::allocator > > >::_Vector_base (__a=..., __n=18446744073575334106, this=0x7fffe670) at /usr/include/c++/10/bits/stl_vector.h:305 #12 std::vector, std::allocator >, std::allocator, std::allocator > > >::vector (this=0x7fffe670, __x=std::vector of length -134217510, capacity -1466015166623 = {...}) at /usr/include/c++/10/bits/stl_vector.h:555 #13 0x5565b1e2 in Catch::TestCaseInfo::TestCaseInfo (this=0x7fffe610) at ./tests/catch2/catch.hpp:4762 #14 0x76a9b845 in Catch::TestCase::TestCase(Catch::ITestCase*, Catch::TestCaseInfo const&) () from /usr/lib/x86_64-linux-gnu/liblog4cplus-2.0.so.3 #15 0x76aa23c6 in Catch::makeTestCase(Catch::ITestCase*, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, Catch::SourceLineInfo const&) () from /usr/lib/x86_64-linux-gnu/liblog4cplus-2.0.so.3 #16 0x76aa269b in Catch::registerTestCase(Catch::ITestCase*, char const*, Catch::NameAndDesc const&, Catch::SourceLineInfo const&) () from /usr/lib/x86_64-linux-gnu/liblog4cplus-2.0.so.3 #17 0x76a6c17d in ?? () from /usr/lib/x86_64-linux-gnu/liblog4cplus-2.0.so.3 #18 0x77fe1fb2 in call_init (l=, argc=argc@entry=1, argv=argv@entry=0x7fffea88, env=env@entry=0x7fffea98) at dl-init.c:72 #19 0x77fe20b9 in call_init (env=0x7fffea98, argv=0x7fffea88, argc=1, l=) at dl-init.c:30 #20 _dl_init (main_map=0x77ffe180, argc=1, argv=0x7fffea88, env=0x7fffea98) at dl-init.c:119 #21 0x77fd30ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 #22 0x0001 in ?? () #23 0x7fffecaa in ?? () _dl_vdso_clock_gettime64 = 0x77fd0a50 , _dl_vdso_gettimeofday = 0x77fd0800 , _dl_vdso_time = 0x77fd0a20 , _dl_vdso_getcpu = 0x77fd0d60 , _dl_vdso_clock_getres_time64 = 0x77fd0d00 , _dl_hwcap2 = 2, _dl_debug_printf = 0x77fe2cf0 <_dl_debug_printf>, _dl_mcount = 0x77fe4090 <__GI__dl_mcount>, _dl_lookup_symbol_x = 0x77fdcbc0 <_dl_lookup_symbol_x>, _dl_open = 0x77fe5830 <_dl_open>, _dl_close = 0x77fe7920 <_dl_close>, _dl_tls_get_addr_soft = 0x77fe5040 <_dl_tls_get_addr_soft>, _dl_discover_osversion = 0x77febef0 <_dl_discover_osversion>, _dl_audit = 0x0, _dl_naudit = 0} _dl_argc = 1 #22 0x0001 in ?? () No symbol table info available. #23 0x7fffecaa in ?? () No symbol table info available. #24 0x in ?? () No symbol table info available. -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (400, 'focal-proposed'), (100, 'focal-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.11-hyper1+ (SMP w/8 CPU cores) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_SG.utf8, LC_CTYPE=en_SG.UTF-8 (charmap=UTF-8), LANGUAGE=en_SG:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via
Bug#960476: transition: tinyxml2
On Wed, May 13, 2020 at 09:21:33AM +0200, Sebastian Ramacher wrote: > control: forwarded -1 > https://release.debian.org/transitions/html/auto-tinyxml2.html > > Hi > > On 2020-05-13 12:42:10 +0800, Chow Loong Jin wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > This is a transition for the SONAME bump of tinyxml2 following a major > > version bump in the upstream package. The following source packages need > > to be rebuilt: > > > > * basilisk2 > > * bullet > > * caveexpress > > * cppcheck > > * dart > > * encfs > > * gazebo > > * ignition-common > > * ignition-fuel-tools > > * ignition-msgs > > * lgogdownloader > > * libexadrums > > * libmediainfo > > * mrpt > > * ros-kdl-parser > > * ros-pluginlib > > * ros-ros > > * ros-rospack > > * ros-urdf > > * sdpb > > * trigger-rally > > Do they all build fine with the new version? Yep. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#960476: transition: tinyxml2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition This is a transition for the SONAME bump of tinyxml2 following a major version bump in the upstream package. The following source packages need to be rebuilt: * basilisk2 * bullet * caveexpress * cppcheck * dart * encfs * gazebo * ignition-common * ignition-fuel-tools * ignition-msgs * lgogdownloader * libexadrums * libmediainfo * mrpt * ros-kdl-parser * ros-pluginlib * ros-ros * ros-rospack * ros-urdf * sdpb * trigger-rally Ben file: title = "tinyxml2"; is_affected = .depends ~ "libtinyxml2-6a" | .depends ~ "libtinyxml2-8"; is_good = .depends ~ "libtinyxml2-8"; is_bad = .depends ~ "libtinyxml2-6a"; -- System Information: Debian Release: buster/sid APT prefers eoan-updates APT policy: (500, 'eoan-updates'), (500, 'eoan-security'), (500, 'eoan'), (400, 'eoan-proposed'), (100, 'eoan-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.5-hyper1+ (SMP w/4 CPU cores; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_SG.utf8, LC_CTYPE=en_SG.UTF-8 (charmap=UTF-8), LANGUAGE=en_SG:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled signature.asc Description: PGP signature
Bug#958901: qreator does not start properly
On Wed, May 06, 2020 at 08:31:45PM +0200, Rainer Dorsch wrote: > reopen 958901 = > > Am Montag, 4. Mai 2020, 09:39:07 CEST schrieb Chow Loong Jin: > > On Sun, Apr 26, 2020 at 02:53:21PM +0200, Rainer Dorsch wrote: > > > Dear Maintainer, > > > > > > I installed qreator on my system (with a KDE desktop). > > > > > > I started qreator but did not see any response or window popping up: > > > [...] > > > > Hi Rainer, > > > > I suspect that qreator might be hanging at startup while trying resolve > > your current location to initialize the location QR Code generator > > widget. > > > > Could you disable the location QR code type by removing > > /usr/share/qreator/qreator/qrcodes/QRCodeLocation.py and then try > > launching it again? > > Hi Chow, > > I apologize for the late reply and thank you for your quick reply. > > Not sure if I am allowed to use the control server, so can you please check > if > the issue got reopened? > > I tried your suggestion, but no luck, I think there is no difference: > > root@h370:~# mv /usr/share/qreator/qreator/qrcodes/QRCodeLocation.py /usr/ > share/qreator/qreator/qrcodes/QRCodeLocation.py.orig > root@h370:~# Abgemeldet > rd@h370:~$ qreator > /usr/share/qreator/qreator_lib/Builder.py:21: PyGIWarning: Gtk was imported > without specifying a version first. Use gi.require_version('Gtk', '3.0') > before > import to ensure that the right version gets loaded. > from gi.repository import GObject, Gtk # pylint: disable=E0611 > /usr/share/qreator/qreator/qrcodes/QRCodeLocationGtk.py:18: PyGIWarning: > GtkChamplain was imported without specifying a version first. Use > gi.require_version('GtkChamplain', '0.12') before import to ensure that the > right version gets loaded. > from gi.repository import Gtk, GtkChamplain, Clutter, Champlain > /usr/share/qreator/qreator/qrcodes/QRCodeLocationGtk.py:20: PyGIWarning: > GtkClutter was imported without specifying a version first. Use > gi.require_version('GtkClutter', '1.0') before import to ensure that the > right > version gets loaded. > from gi.repository import GtkClutter > /usr/share/qreator/qreator/qrcodes/QRCodeWifiGtk.py:20: PyGIWarning: NM was > imported without specifying a version first. Use gi.require_version('NM', > '1.0') before import to ensure that the right version gets loaded. > from gi.repository import Gtk, GLib, GdkPixbuf, NM > No handlers could be found for logger "qreator_lib" > ^C^C^C^C^C^C^Z > [1]+ Angehalten qreator > rd@h370:~$ kill %1 Judging by your log messages, it looks like qreator was still loading QRCodeLocation, probably from a .pyc file in /usr/share/qreator/qreator/qrcodes/__pycache__/. But nevermind that, could you try upgrading to 16.06.1-5 and trying again please? I think I've fixed the hanging problem in QRCodeLocation in that release. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#958901: qreator does not start properly
On Sun, Apr 26, 2020 at 02:53:21PM +0200, Rainer Dorsch wrote: > Dear Maintainer, > > I installed qreator on my system (with a KDE desktop). > > I started qreator but did not see any response or window popping up: > [...] Hi Rainer, I suspect that qreator might be hanging at startup while trying resolve your current location to initialize the location QR Code generator widget. Could you disable the location QR code type by removing /usr/share/qreator/qreator/qrcodes/QRCodeLocation.py and then try launching it again? -- Kind regards, Loong Jin
Bug#954729: src:mesa: X won't start after upgrading mesa
Package: src:mesa Version: 20.0.2-1 Severity: critical Justification: breaks the whole system Dear Maintainer, > * What led up to the situation? Upgraded mesa packages from 19.3.3-1 to 20.0.2-1. > * What exactly did you do (or not do) that was effective (or > ineffective)? Tried to boot > * What was the outcome of this action? X wouldn't start (log attached) > * What outcome did you expect instead? X starts. -- Kind regards, Loong Jin Xorg.0.log.old Description: Xorg.0.log from the crash signature.asc Description: PGP signature
Bug#952721: ITP: gcolor3 -- Simple GTK3 color selector and picker
On Fri, Mar 06, 2020 at 07:34:07AM +0100, Eduard Bloch wrote: > Hallo, > * Chow Loong Jin [Fri, Feb 28 2020, 12:48:51PM]: > > > > why is this package useful/relevant? is it a dependency for another > > > package? do you use it? if there are other packages providing similar > > > functionality, how does it compare? > > > > Sometimes you just need a colour picker to help generate colour hex > > codes for you and sample colours from your screen. > > That is not a complete answer since there is gpick (apt show gpick). Fair enough, let's have another go. > why is this package useful/relevant? It's a simple colour picker that can trivially sample colours from the screen or pick other colours via RGB/HSL/hex code. It's also the currently maintained successor to gcolor2 which was previously removed from Debian for being dead-upstream. > is it a dependency for another package? No > do you use it? Yes > if there are other packages providing similar functionality, how does > it compare? I hadn't known about gpick, but now that you've mentioned it, gcolor3 does seem a lot easier to use. I've been clicking around gpick for the past 5 minutes, and: - I don't how I can input a hex colour that I already have, so that I may tweak it, e.g. to change its luminosity. - I can't figure out how to use the eye dropper tool -- I activated it and clicked on a thing, and I don't see any of the colours in the colour picker swatch getting updated. - I'm just really confused and lost now. > Maybe not easy enough for your purpose? No, gpick seems terribly hard to use for my purpose. And apparently not for three out of three web developers I asked either -- presented with screenshots, they all picked gcolor3. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#952721: ITP: gcolor3 -- Simple GTK3 color selector and picker
Package: wnpp Severity: wishlist Owner: Chow Loong Jin * Package name: gcolor3 Version : 2.3.1 Upstream Author : Jente Hidskes * URL : https://github.com/Hjdskes/gcolor3 * License : GPL-2+ Programming Lang: C Description : Simple GTK3 color selector and picker Gcolor3 is a simple GTK3 color selector to provide a quick and easy way to find colors for whatever task is at hand. Colors can be saved and deleted as well. > why is this package useful/relevant? is it a dependency for another > package? do you use it? if there are other packages providing similar > functionality, how does it compare? Sometimes you just need a colour picker to help generate colour hex codes for you and sample colours from your screen. > how do you plan to maintain it? inside a packaging team (check list at > https://wiki.debian.org/Teams)? are you looking for co-maintainers? do > you need a sponsor? I'll maintain it in https://salsa.debian.org/Debian/gcolor3. I don't need a sponsor. signature.asc Description: PGP signature
Bug#951818: sslstrip: should this package be removed?
On Sat, Feb 22, 2020 at 10:31:08AM -0500, Sandro Tosi wrote: > On Sat, Feb 22, 2020 at 3:25 AM Chow Loong Jin wrote: > > [...] > did you read https://github.com/moxie0/sslstrip/issues/16 where they > declared the project useless and dead, with a new fork at > https://github.com/byt3bl33d3r/sslstrip2 , again declared dead at > https://github.com/byt3bl33d3r/sslstrip2/issues/1 . So maybe this > functionality is just no longer there. Fair enough. I had realized that HSTS has largely defeated the sslstrip attack, but thought it might still be useful for some people (e.g. demonstrating an old attack). I hadn't realized there was an sslstrip2 though. I guess this should go then. > > (ported to Python 3 with a distro patch of > > course). > > are you planning on write this patch? if so, do you know already when > you're gonna have time to do that? I had started work on it a couple of days ago and was working through some byte/string issues but I guess I'll drop it. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#951818: sslstrip: should this package be removed?
On Fri, Feb 21, 2020 at 09:39:41PM -0500, Sandro Tosi wrote: > Package: sslstrip > Severity: serious > > Hello, > i think sslstrip should be removed from Debian: > > * python2 only app > * low popcon > * only r-dep is websploit, recently removed from testing, and which doesnt use > sslstrip anymore in the latest upstream release > * last upstream release and debian upload in 2011 (!) > * dead upstream, https://github.com/moxie0/sslstrip/issues/16 and render > mostly > obsolete > > If i dont hear back within a week with a good reason to keep this package in > Debian, i'll file for its removal. Are there alternative packages that provide this functionality? If not, I think it should be kept (ported to Python 3 with a distro patch of course). -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#942426: caja-mediainfo: Please port caja-mediainfo to Python 3
Package: caja-mediainfo Version: 1.0.1-2 Severity: normal Dear Maintainer, Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution, as discussed in https://lists.debian.org/debian-python/2019/07/msg00080.html Please port caja-mediainfo to python 3 soon. -- System Information: Debian Release: buster/sid APT prefers cosmic-updates APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500, 'cosmic'), (400, 'cosmic-proposed'), (100, 'cosmic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.2-hyper1+ (SMP w/4 CPU cores) Locale: LANG=en_SG.UTF-8, LC_CTYPE=en_SG.UTF-8 (charmap=UTF-8), LANGUAGE=en_SG:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#930209: unblock: libmediainfo/18.12-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package libmediainfo. This fixes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927672 and the following CVEs: CVE-2019-11372 CVE-2019-11373 unblock libmediainfo/18.12-2 -- System Information: Debian Release: buster/sid APT prefers cosmic-updates APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500, 'cosmic'), (400, 'cosmic-proposed'), (100, 'cosmic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.0.1-hyper1+ (SMP w/4 CPU cores) Locale: LANG=en_SG.UTF-8, LC_CTYPE=en_SG.UTF-8 (charmap=UTF-8), LANGUAGE=en_SG:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#927672: CVE-2019-11372 CVE-2019-11373
On Mon, Jun 03, 2019 at 10:36:48PM +0200, Moritz Mühlenhoff wrote: > On Sun, Apr 21, 2019 at 12:00:08AM +0200, Moritz Muehlenhoff wrote: > > Source: libmediainfo > > Severity: important > > Tags: security > > > > Please see > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11372 > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11373 > > What's the status, can we get that fixed for buster? Looks like the fix is upstream. I can backport the patch to buster. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#900573: qreator: Proposed patch to fix the crash
On Wed, Mar 27, 2019 at 10:31:35PM +0100, Andreas Boll wrote: > Control: severity -1 serious > Control: tags -1 + patch > > Dear maintainer, > > I've prepared a patch to fix this issue. > Also currently the package qreator isn't useful at all with this issue > because it crashes on startup. Thus bumping severity to serious > because this package shouldn't end up in Debian Buster without a fix > for this issue. > > Please let me know if I should upload this fix as NMU or if you like > to upload it yourself. Please go ahead and upload this fix. Thanks. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#905682: kido: FTBFS (can't find , which appears to now be in libnlopt-cxx-dev)
Source: kido Version: 0.1.0+dfsg-2 Severity: serious Tags: patch Justification: fails to build from source (but built successfully in the past) Dear Maintainer, kido fails to build in unstable right now due to the libnlopt-dev split. cd /<>/kido-0.1.0+dfsg/build/kido/optimizer/nlopt && /usr/lib/ccache/c++ -DBOOST_TEST_DYN_LINK -DHAVE_BULLET_COLLISION -Dkido_optimizer_nlopt_EXPORTS -I/<>/kido-0.1.0+dfsg -isystem /usr/include/eigen3 -isystem /usr/include/bullet -I/<>/kido-0.1.0+dfsg/build -Wall -fPIC -std=c++11 -g -O2 -fdebug-prefix-map=/<>/kido-0.1.0+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/bullet -o CMakeFiles/kido-optimizer-nlopt.dir/NloptSolver.cpp.o -c /<>/kido-0.1.0+dfsg/kido/optimizer/nlopt/NloptSolver.cpp In file included from /<>/kido-0.1.0+dfsg/kido/optimizer/nlopt/NloptSolver.cpp:39: /<>/kido-0.1.0+dfsg/kido/optimizer/nlopt/NloptSolver.hpp:40:10: fatal error: nlopt.hpp: No such file or directory #include ^~~ compilation terminated. make[4]: *** [kido/optimizer/nlopt/CMakeFiles/kido-optimizer-nlopt.dir/build.make:66: kido/optimizer/nlopt/CMakeFiles/kido-optimizer-nlopt.dir/NloptSolver.cpp.o] Error 1 make[4]: Leaving directory '/<>/kido-0.1.0+dfsg/build' make[3]: *** [CMakeFiles/Makefile2:479: kido/optimizer/nlopt/CMakeFiles/kido-optimizer-nlopt.dir/all] Error 2 make[3]: Leaving directory '/<>/kido-0.1.0+dfsg/build' make[2]: *** [Makefile:144: all] Error 2 make[2]: Leaving directory '/<>/kido-0.1.0+dfsg/build' make[1]: *** [debian/rules:33: override_dh_auto_build] Error 2 make[1]: Leaving directory '/<>/kido-0.1.0+dfsg' make: *** [debian/rules:22: build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 -- System Information: Debian Release: buster/sid APT prefers bionic-updates APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 'bionic'), (400, 'bionic-proposed'), (100, 'bionic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.1-hyper1+ (SMP w/4 CPU cores) Locale: LANG=en_SG.UTF-8, LC_CTYPE=en_SG.UTF-8 (charmap=UTF-8), LANGUAGE=en_SG:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Kind regards, Loong Jin From 5b5b9f42177df7dbd3a91c38eddbd282e66f07b8 Mon Sep 17 00:00:00 2001 From: Chow Loong Jin Date: Wed, 8 Aug 2018 08:59:44 +0800 Subject: [PATCH] Exchange libnlopt-dev dependency for libnlopt-cxx-dev /usr/include/nlopt.hpp has been moved into libnlopt-cxx-dev. --- debian/control | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/debian/control b/debian/control index 5488999..6a84e70 100644 --- a/debian/control +++ b/debian/control @@ -10,7 +10,7 @@ Build-Depends: debhelper (>= 9.20151219), libfcl-dev (>= 0.2.7), libbullet-dev, libassimp-dev (>= 3), - libnlopt-dev, + libnlopt-cxx-dev, coinor-libipopt-dev, freeglut3-dev, libxi-dev, @@ -365,7 +365,7 @@ Pre-Depends: ${misc:Pre-Depends} Depends: ${misc:Depends}, libkido-dev, libkido-optimizer-nlopt0.1 (= ${binary:Version}), - libnlopt-dev + libnlopt-cxx-dev Description: Kinematics Dynamics and Optimization Library - optimizer dev files KIDO is a collaborative, cross-platform, open source library created by the Georgia Tech Graphics Lab and Humanoid Robotics Lab. The library provides data -- 2.17.1 signature.asc Description: PGP signature
Bug#905561: transition: tinyxml2
On Tue, Aug 07, 2018 at 06:37:00AM +, Niels Thykier wrote:84;0;0c > Niels Thykier: > > Chow Loong Jin: > >> Package: release.debian.org > >> Severity: normal > >> User: release.debian@packages.debian.org > >> Usertags: transition > >> > >> Hi, > >> > >> There was an ABI break without soname bump in libtinyxml2-6 recently[1], > >> and I've renamed the package to libtinyxml2-6a as a consequence. > >> > >> Unfortunately, I neglected to read > >> https://wiki.debian.org/Teams/ReleaseTeam/Transitions prior to filing > >> this transition request and have already uploaded libtinyxml2-6a to > >> unstable. Sorry about that. > >> > >> The following packages are impacted: > >> [...] > >> > >> Given that the ABI break is just the addition of a struct member, no > >> sourceful changes are needed, and binNMUs should be sufficient for the > >> above packages. > >> > >> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898535 > >> > >> [...] > > Hi, > > > > Thanks for reporting the transition so we can finish it. :) > > > > I have scheduled the binNMUs for "Dependency level 2" in the transition > > tracker (see https://release.debian.org/transitions/html/auto-tinyxml2.html) > > > > Please keep an eye on the buildd logs for the relevant packages and file > > RC bugs as necessary if builds starts to fail. > > > > Thanks, > > ~Niels > > > > Hi, > > It seems that rebuilding ignition-common, kido and sdpb does not make > them pick up the dependency on libtinyxml2-6a (they seem to stay with > the old version). Hi, Both ignition-common and sdpb properly pick up the correct dependency when built with sbuild on my machine, while kido simply FTBFS. Looking at the timestamps on the build logs, it looks like the binNMUs didn't happen. > Could you please investigate and file bugs as necessary (or update > tinyxml2, if the bug is there - e.g. in symbols files or the shlibs > file)? -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#905561: transition: tinyxml2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, There was an ABI break without soname bump in libtinyxml2-6 recently[1], and I've renamed the package to libtinyxml2-6a as a consequence. Unfortunately, I neglected to read https://wiki.debian.org/Teams/ReleaseTeam/Transitions prior to filing this transition request and have already uploaded libtinyxml2-6a to unstable. Sorry about that. The following packages are impacted: - libgazebo9 - basilisk2 - trigger-rally - sdpb - rviz - librviz2d - rospack-tools - librospack0d - python-rosbag - librosbag3d - librosbag-storage3d - libroslib0d - liburdf0d - libkdl-parser0d - libcollada-urdf0d - libcollada-parser0d - collada-urdf-tools - libresource-retriever0d - ros-opencv-apps - libopencv-apps0d - libnodeletlib0d - libnodeletlib-tools - polled-camera-tool - libpolled-camera0d - libimage-transport0d - libcamera-info-manager0d - image-transport-tools - libmediainfo0v5 - lgogdownloader - libkido-utils0.1 - libignition-common - cppcheck - gazebo9-plugin-base - gazebo9 - encfs - cppcheck-gui Given that the ABI break is just the addition of a struct member, no sourceful changes are needed, and binNMUs should be sufficient for the above packages. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898535 Ben file: title = "tinyxml2"; is_affected = .depends ~ "libtinyxml2-6" | .depends ~ "libtinyxml2-6a"; is_good = .depends ~ "libtinyxml2-6a"; is_bad = .depends ~ "libtinyxml2-6"; -- System Information: Debian Release: buster/sid APT prefers bionic-updates APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 'bionic'), (400, 'bionic-proposed'), (100, 'bionic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.1-hyper1+ (SMP w/4 CPU cores) Locale: LANG=en_SG.UTF-8, LC_CTYPE=en_SG.UTF-8 (charmap=UTF-8), LANGUAGE=en_SG:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#898535: closed by Chow Loong Jin (Bug#898535: fixed in tinyxml2 6.2.0+dfsg-2)
On Sun, Aug 05, 2018 at 01:38:31PM +0200, Joachim Reichel wrote: > On 03.08.2018 06:03, Debian Bug Tracking System wrote: > > Changes: > > tinyxml2 (6.2.0+dfsg-2) unstable; urgency=medium > > . > >* [7fdca1f] Rename package for abi break (Closes: #898535) > > How do you plan to deal with the breakage that results from the renaming? Did > you already ask for binNMUs? No I haven't, but I plan to. > I do not see a bug report that requests a > transition slot, nor any discussion on debian-release. Whoops, I was just going to binNMU all rdeps and be done with it since it was a pretty short list. Considering that the current libtinyxml2-6 has already broken ABI, should I have requested and waited for a transition slot instead? -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#895735: xsel fails to paste more than 4k of text into chrome
Package: xsel Version: 1.2.0-3 Severity: normal Tags: upstream fixed-upstream Dear Maintainer, 1. Copy a large block (>4k )of text using xsel 2. Open Chrome/Chromium 3. Try to paste it into a textarea 4. Chrome/Chromium hangs This is fixed upstream in this PR: https://github.com/kfish/xsel/pull/16 Patch link: https://github.com/kfish/xsel/pull/16.patch -- System Information: Debian Release: stretch/sid APT prefers artful-updates APT policy: (500, 'artful-updates'), (500, 'artful-security'), (500, 'artful'), (400, 'artful-proposed'), (100, 'artful-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.12-hyper1+ (SMP w/4 CPU cores) Locale: LANG=en_SG.UTF-8, LC_CTYPE=en_SG.UTF-8 (charmap=UTF-8), LANGUAGE=en_SG:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xsel depends on: ii libc6 2.26-0ubuntu2.1 ii libx11-6 2:1.6.4-3 xsel recommends no packages. xsel suggests no packages. -- no debconf information -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#883341: [3dprinter-general] Bug#883341: slic3r: Missing dependencies: wx-common, libopengl-perl, libwx-glcanvas-perl
Control: tags -1 + wontfix On Tue, Jan 02, 2018 at 12:52:38AM +0200, Adrian Bunk wrote: > [...] > They are only recommended since the non-GUI functionality of the package > does work without these packages. > > Whether these should be recommends or dependencies is a valid question, > and as far as I can see both choices would be reasonable maintainer[1] > choices in this case. > > cu > Adrian > > [1] I am not the maintainer of slic3r I still think setting the GUI dependencies as recommends is the right choice as per the explanation Adrian gave, so I'm not going to change this. I recommend that you don't skip installing recommended packages if you want the full functionality of any Debian package. If you're using a derivative distro that disables the installation of recommended packages, then please take the issue up with the developers of the distro you're using. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#877392: admesh doesn't parse binary STLs correctly on big-endian architectures
Package: admesh Version: 0.98.2-3 Severity: important Tags: upstream patch Forwarded: https://github.com/admesh/admesh/pull/26 Dear Maintainer, Reading binary STLs is broken on big-endian architectures due to the incorrect little-endian assumption in admesh's STL reading code. Here's the output from admesh block-binary.stl on partch.debian.org (ppc): hyperair@partch ~/admesh-0.98.3 % /usr/bin/admesh block-binary.stl ADMesh version 0.98.3, Copyright (C) 1995, 1996 Anthony D. Martin ADMesh comes with NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Opening block-binary.stl Warning: File size doesn't match number of facets in the header Checking exact... All facets connected. No nearby check necessary. No unconnected need to be removed. No holes need to be filled. Checking normal directions... Checking normal values... Calculating volume... Verifying neighbors... = Results produced by ADMesh version 0.98.3 Input file : block-binary.stl File type : Binary STL file Header : Processed by ADMesh version 0.98.3 == Size == Min X = -613977118228749856000863895552.00, Max X = -613972282525471397484165070848.00 Min Y = -613977118228749856000863895552.00, Max Y = -613972282525471397484165070848.00 Min Z = -613977118228749856000863895552.00, Max Z = -613972282525471397484165070848.00 = Facet Status == Original Final Number of facets :12 12 Facets with 1 disconnected edge : 0 0 Facets with 2 disconnected edges : 0 0 Facets with 3 disconnected edges : 0 0 Total disconnected facets: 0 0 === Processing Statistics === = Other Statistics = Number of parts : 1Volume : nan Degenerate facets : 0 Edges fixed : 0 Facets removed: 0 Facets added : 0 Facets reversed : 0 Backwards edges : 0 Normals fixed :12 And the output of admesh with the fix: hyperair@partch ~/admesh-0.98.3 % ./admesh block-binary.stl ADMesh version 0.98.3, Copyright (C) 1995, 1996 Anthony D. Martin ADMesh comes with NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Opening block-binary.stl Checking exact... All facets connected. No nearby check necessary. No unconnected need to be removed. No holes need to be filled. Checking normal directions... Checking normal values... Calculating volume... Verifying neighbors... = Results produced by ADMesh version 0.98.3 Input file : block-binary.stl File type : Binary STL file Header : Processed by ADMesh version 0.98.3 == Size == Min X = -1.968504, Max X = 1.968504 Min Y = -1.968504, Max Y = 1.968504 Min Z = -1.968504, Max Z = 1.968504 = Facet Status == Original Final Number of facets :12 12 Facets with 1 disconnected edge : 0 0 Facets with 2 disconnected edges : 0 0 Facets with 3 disconnected edges : 0 0 Total disconnected facets: 0 0 === Processing Statistics === = Other Statistics = Number of parts : 1Volume : 61.023746 Degenerate facets : 0 Edges fixed : 0 Facets removed: 0 Facets added : 0 Facets reversed : 0 Backwards edges : 0 Normals fixed : 0 I've filed a pull request at https://github.com/admesh/admesh/pull/26 already, but it might be worth fixing on the Debian side as well. -- Kind regards, Loong Jin From f044dd2f807a910c23c998a0a91c69699770c232 Mon Sep 17 00:00:00 2001 From: Chow Loong Jin <hyper...@debian.org> Date: Sun, 1 Oct 2017 17:55:28 +0800 Subject: [PATCH] Fix reading of binary STLs in BE architectures Also use uint32_t instead of int for header_num_facets as per the binary STL spec. --- src/stlinit.c | 30 +++--- 1 file changed, 23 insertions(+), 7 deletions(-) diff --git a/src/stlinit.c b/src/stlinit.c index 40b57a3..da191b2 100644 --- a/src/stlinit.c +++ b/src/stlinit.c @@ -20,6 +20,8 @@ * https://github.com/admesh/admesh/issues */ +#include +#include #include #include #include @@ -69,7 +71,7 @@ stl_initialize(stl_file *stl) { void stl_count_facets(stl_file *stl, char *file) { long file_size; - intheader_num_facets; + uint32_t header_num_facets; intnum_facets; inti, j; size_t s; @@ -129,7 +131,7 @@ stl_count_facets(stl_file *stl, char
Bug#869638: [3dprinter-general] Bug#869638: slic3r-prusa FTBFS on big endian: admesh works correctly on little endian machines only
On Sun, Oct 01, 2017 at 06:41:09AM +0200, Petter Reinholdtsen wrote: > [Adrian Bunk] > > If this is not fixable with reasonable effort, an RM bug for the old mips > > binary should be sent against ftp.debian.org and this bug downgraded to > > important. > > I had a quick look at the code, and the trigger is of course this in > xs/src/admesh/stl.h: > > #ifndef BOOST_LITTLE_ENDIAN > #error "admesh works correctly on little endian machines only!" > #endif > > I was unable to see what should cause the code to only work on little endian > machines, and did not have a big endian machine easily available. I would > recommend forwarding the issue to upstream and asking the ftpmasters to > remove the old mips binaries until upstream or some big endian porters have > time to look at it. Upstream bug: https://github.com/prusa3d/Slic3r/issues/532 Commit that introduced the #error: https://github.com/prusa3d/Slic3r/commit/2085a482c76d88bfbb7ed8b5c598ff9f7ed8788f#diff-26021b6537e4d7f5fd50b588d3a6ca81R277 The root cause of why the #error was introduced: https://github.com/admesh/admesh/blob/master/src/stlinit.c#L272 Naturally, this also affects slic3r and admesh. A patch is on its way, please wait. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#872275: slic3r-prusa: diff for NMU version 1.37.0+dfsg-1.1
On Thu, Sep 28, 2017 at 09:56:43PM +0200, gregor herrmann wrote: > On Wed, 23 Aug 2017 19:32:43 +0200, gregor herrmann wrote: > > > I've prepared an NMU for slic3r-prusa (versioned as 1.37.0+dfsg-1.1) and > > uploaded it to DELAYED/5. Please feel free to tell me if I > > should delay it longer. > > I [0] notice that the fix for this bug in 1.37.0+dfsg-1.1 has been > overwritten by the upload of 1.37.1+dfsg-1 which is a bit unfortunate > since now the package has 3 instead of 2 RC bugs. > > Oh well. > > > Cheers, > gregor > > [0] Actually it was ntyni, thanks! Oops, looks like the 3dprinter-gene...@lists.alioth.debian.org mailing list kicked me out (probably for mail bounces or something, I've had a few close calls with other alioth lists and my @debian.org address), so I didn't get any of the previous emails. Sorry about that. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#875313: yagv: Program won't run - python typo
severty 875313 important kthxbye On Sun, Sep 10, 2017 at 05:24:54PM +0100, Nick Bailey wrote: > Package: yagv > Version: 0.4~20130422 > Severity: grave > Tags: patch > Justification: renders package unusable > > Dear Maintainer, > > If you install and run yagv in Debain stable, it will not run > because of a typo in the python. It doesn't run on some gcode files. Looks like it's a bug in handling G0 moves. G1 moves are handled fine. And it works for a lot of people because G0 moves aren't actually all that common in gcode files. Slic3r only uses G1 for instance. > In file gcodeParser.py, self.G1 should be replaced with > self.parse.G1 as per the patch reported here: > > https://github.com/chexov/yagv/commit/7d2b3d8fd2534cfb0feff1ef671bf1257e2615dd Thanks, I'll import the patch (and possibly look for a more up-to-date fork to package). > Furthermore, a segfault is generated on (at least) 64b arcitctures > before the graphics are rendered. I believe this is due to a bug > in the version of python-pyglet distributed with stable. Certainly, > I corrected segfault problem by installing the python-pyglet package > from sid. This may be because of > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864936 and if this > is true, should not a later version of python-pyglet be a dependency? I'd just leave this as is, because it actually worked with older versions of pyglet, so the above bug is actually a regression in pyglet itself that rendered pyglet completely useless (iirc there weren't any calls that actually worked in pyglet). > By obtaining the upstream source from github, and installing pyglet from sid, > I was able to obtain a working version of yagv. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#864936: yagv: segmentation fault on startup
tags 864936 + patch fixed-upstream kthxbye This is caused by improper ctypes pointer handling in pyglet, causing the 64-bit pointers to be truncated to 32-bit integers when passing through python code. See https://bitbucket.org/pyglet/pyglet/commits/30298988e3d1772cc396aa50398d239b279aef39 for a fix. This is also fixed in the 1.2 release. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#743368: alarm-clock-applet: Default installation of alarm-clock-applet does not play sounds.
On Tue, Jun 27, 2017 at 03:14:55AM -0400, Simon Désaulniers wrote: > Hi, > > It's been two years since the bug report has been made. I have just installed > the version 0.3.4-1+b1 and it is still the same. Alos, no sound is produced > when > the time comes. > > The package is simply unusable. > > I have managed to solve *my* problem by installing gstreamer1.0-fluendo-mp3. > This should appear in the recommended package list... AFAIK all the stock sounds (files in /usr/share/sounds) are ogg or wav and should work out of the box, as their respective decoders are in gstreamer1.0-plugins-base and gstreamer1.0-plugins-good, which are already covered by the dependency list. I don't think your claim that "the package is simply unusable" is true. It's not the responsibility of an alarm clock applet to furnish your system with the appropriate codecs for non-standard media files (mp3). Even rhythmbox, a media player only depends on gstreamer1.0-plugins-{base,good}. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#851926: unblock: qreator/13.05.3-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package qreator Fixes for 2 RC bugs: #725827 and #779265 unblock qreator/13.05.3-4 -- System Information: Debian Release: stretch/sid APT prefers yakkety-updates APT policy: (500, 'yakkety-updates'), (500, 'yakkety-security'), (500, 'yakkety'), (100, 'yakkety-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-hyper1+ (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- Kind regards, Loong Jin diff --git a/debian/changelog b/debian/changelog index bcca874..ce79e7f 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,20 @@ +qreator (13.05.3-4) unstable; urgency=medium + + * [5879985] Use geoclue-2.0 instead of geoclue. +geoclue is gone from sid. + + -- Chow Loong Jin <hyper...@debian.org> Mon, 16 Jan 2017 07:32:10 +0800 + +qreator (13.05.3-3) unstable; urgency=medium + + * [20d6c68] Fix debian/watch + * [1289a78] Depend on geoclue-ubuntu-geoip | geoclue-hostip +qreator won't start without at least one of these. (Closes: #725827) + * [5c40090] Depend on python-gi-cairo (Closes: #779265) + * [a0c6640] Fix exception from PIL deprecated method + + -- Chow Loong Jin <hyper...@debian.org> Sun, 15 Jan 2017 10:14:21 +0800 + qreator (13.05.3-2) unstable; urgency=low * [aec84f6] Expand package description to differentiate from qrencode diff --git a/debian/control b/debian/control index 14c4bb3..d867043 100644 --- a/debian/control +++ b/debian/control @@ -13,13 +13,15 @@ Vcs-Browser: http://git.debian.org/?p=collab-maint/qreator.git;a=summary Package: qreator Architecture: all Depends: ${python:Depends}, ${misc:Depends}, - python-imaging, + python-imaging (>= 2.0.0), python-cairo, python-dbus, python-defer, python-gi, + python-gi-cairo, gir1.2-champlain-0.12, gir1.2-clutter-1.0, + gir1.2-geoclue-2.0, gir1.2-glib-2.0, gir1.2-gdkpixbuf-2.0, gir1.2-gtk-3.0, @@ -30,7 +32,8 @@ Depends: ${python:Depends}, ${misc:Depends}, python-qrencode, python-requests, python-vobject, - python-xdg + python-xdg, + geoclue-2.0 Description: graphical utility for creating QR codes Qreator enables you to easily create your own QR codes to encode different types of information in an efficient, compact and cool way. diff --git a/debian/patches/Fix-usage-of-PIL-deprecated-method.patch b/debian/patches/Fix-usage-of-PIL-deprecated-method.patch new file mode 100644 index 000..e75af18 --- /dev/null +++ b/debian/patches/Fix-usage-of-PIL-deprecated-method.patch @@ -0,0 +1,21 @@ +From: Chow Loong Jin <hyper...@debian.org> +Date: Sun, 15 Jan 2017 09:43:31 +0800 +Subject: Fix usage of PIL deprecated method + +--- + qreator/QRCode.py | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/qreator/QRCode.py b/qreator/QRCode.py +index 84c508a..d3a0130 100644 +--- a/qreator/QRCode.py b/qreator/QRCode.py +@@ -73,7 +73,7 @@ class QRCode(object): + # Notice the conversion to BGRA that Cairo expects + # See http://cairographics.org/pythoncairopil/ and + # http://mail.gnome.org/archives/gtkmm-list/2007-May/msg00111.html +-bytearr = array.array('B', self.image.tostring("raw", "BGRA", 0, 1)) ++bytearr = array.array('B', self.image.tobytes("raw", "BGRA", 0, 1)) + height, width = self.image.size + #print self.image.size + diff --git a/debian/patches/Port-to-geoclue-2.0.patch b/debian/patches/Port-to-geoclue-2.0.patch new file mode 100644 index 000..82823de --- /dev/null +++ b/debian/patches/Port-to-geoclue-2.0.patch @@ -0,0 +1,70 @@ +From: Chow Loong Jin <hyper...@debian.org> +Date: Sun, 15 Jan 2017 23:45:17 +0800 +Subject: Port to geoclue-2.0 + +geoclue has been removed from Debian. +--- + qreator/qrcodes/QRCodeLocationGtk.py | 46 ++-- + 1 file changed, 12 insertions(+), 34 deletions(-) + +diff --git a/qreator/qrcodes/QRCodeLocationGtk.py b/qreator/qrcodes/QRCodeLocationGtk.py +index 9adb634..c6b144f 100644 +--- a/qreator/qrcodes/QRCodeLocationGtk.py b/qreator/qrcodes/QRCodeLocationGtk.py +@@ -14,6 +14,7 @@ + # with this program. If not, see <http://www.gnu.org/licenses/>. + ### END LICENSE + ++import gi + from gi.repository import Gtk, GtkChamplain, Clutter, Champlain + from qreator_lib.helpers import get_data_file + from gi.repository import GtkClutter +@@ -83,37 +84,14 @@ class QRCodeLocationGtk(object): + + + def get_current_location(): +-'''Gets the current location from geolocation via IP (only method +- currently supported)''' +-#import Geoclue +-
Bug#850643: [pkg-cli-apps-team] Bug#850643: banshee: Not compatible with MATE notification theme 'coco'
tags 850643 - patch kthxbye On Sun, Jan 08, 2017 at 07:28:39PM +0100, Arav K wrote: > Using MATE. > The default notification theme "nodoka" works well with banshee. > But when I chose theme "coco" the banshee "This song is now playing" > notification is halfway out of the screen in the low-right corner. > It should have appeared in the same position as the "nodoka" themed > notifications Could you upload a screenshot please? Also I'm removing the "patch" tag since there's no patch available. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#844222: ITP: slic3r-prusa -- G-code generator for 3D printers
Package: wnpp Severity: wishlist Owner: Chow Loong Jin <hyper...@debian.org> * Package name: slic3r-prusa Version : 1.31.4 Upstream Author : Vojtech Bubnik <bubn...@gmail.com> * URL : https://github.com/prusa3d/slic3r * License : GPL Programming Lang: Perl, C++ Description : G-code generator for 3D printers Slic3r converts digital 3D models into printing instructions (G-code) for your 3D printer. It cuts the model into horizontal slices (layers), generates toolpaths to fill them and calculates the amount of material to be extruded. . Slic3r supports input in the STL, AMF and OBJ formats, and can output G-code for several series of 3D printers, including RepRap, Ultimaker, Makerbot, as well as SVG files for DLP printers. . It can be used with a graphical interface, or in batch mode via the command-line. . This package contains the Prusa3D fork of Slic3r. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#825038: libmediainfo: FTBFS on ppc64 due to mismatched symbols file
On Sun, May 22, 2016 at 10:03:53PM +0200, John Paul Adrian Glaubitz wrote: > Source: libmediainfo > Version: 0.7.85-1 > Severity: normal > User: debian-powe...@lists.debian.org > Usertags: ppc64 > > Hi! > > libmediainfo currently fails to build from source on ppc64 due to a mismatched > symbols file. I'm not sure why the symbols diff is so large, but it might be > advisable to check the whether the issue occurs on other architectures as > well. I had a look at the diff, and it seems like perhaps c++filt isn't demangling the symbols at all. This is looks like more of a bug with dpkg-gensymbols/c++filt rather than in the package's symbols file itself. -- Kind regards, Loong Jin signature.asc Description: PGP signature
Bug#817046: libtinyxml2-dev: tinyxml2.h has CR-LF style endlines
tags 817046 + fixed-upstream On Mon, Mar 07, 2016 at 06:12:05PM +0300, Max Dmitrichenko wrote: > Package: libtinyxml2-dev > Version: 2.2.0-1 > Severity: minor > > Dear Maintainer, > > Open file /usr/include/tinyxml2.h in emacs and see ^M at the end of each line. Actually the real reason for that is that tinyxml2.h has some lines with unix line endings while the rest of it has CRLF. If you do a regexp search for [^^M]$, you'll find those lines (use ^Q to insert a literal ^M in emacs). > Probably dos2unix should be run as a build step of the package. Perhaps, but it's been fixed in the master branch upstream. Looks like a one-off error, so I'm not sure if it's the right thing to do. Perhaps I'll just patch the line-endings for the time being. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#814063: dh-autoreconf looks for ltmain.sh in the wrong place
Package: dh-autoreconf Version: 10 Severity: important Dear Maintainer, dh-autoreconf called with --as-needed fails with the following error in mediaconch: dh_autoreconf --as-needed find: '/usr/share/libtool/config/ltmain.sh': No such file or directory dh_autoreconf: find Project/GNU/CLI /usr/share/libtool/config/ltmain.sh . ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a -type f -exec md5sum {} \; > debian/autoreconf.before returned exit code 1 `dpkg -L libtool` shows that ltmain.sh is now found in /usr/share/libtool/build-aux/ltmain.sh. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#805149: ITP: mediaconch -- implementation and policy checker, reporter and fixer for media files
Package: wnpp Severity: wishlist Owner: Chow Loong Jin <hyper...@debian.org> * Package name: mediaconch Version : 15.10 Upstream Author : MediaArea.net SARL * URL : https://mediaarea.net/MediaConch/ * License : GPLv3+ Programming Lang: C++ Description : implementation and policy checker, reporter and fixer for media files MediaConch is an extensible, open source software project consisting of an implementation checker, policy checker, reporter, and fixer that targets preservation-level audiovisual files (specifically Matroska, Linear Pulse Code Modulation (LPCM) and FF Video Codec 1 (FFV1)) for use in memory institutions, providing detailed and batch-level conformance checking via an adaptable and flexible application program interface accessible by the command line, a graphical user interface, or a web-based shell. I plan to maintain this in pkg-multimedia with the other bunch of things done by MediaArea.net (libzen, libmediainfo, and mediainfo), some of which are dependencies of mediaconch. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#791155: [Pkg-gtkpod-devel] Bug#791155: libplist: library transition may be needed when GCC 5 is the default
On Wed, Aug 26, 2015 at 12:22:26AM +0100, Simon McVittie wrote: Control: tags 791155 + patch pending On Wed, 12 Aug 2015 at 11:13:32 +0200, Julien Cristau wrote: A possible patch is available at https://launchpad.net/ubuntu/+source/libplist/1.12-3ubuntu1 I have done a non-maintainer upload heavily based on that patch to DELAYED/2. Please let me know if I should cancel or reschedule this. Looks good to me, thanks. Feel free to reschedule it to 0-day if you see fit. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#791188: closed by Chow Loong Jin hyper...@debian.org (Bug#791188: fixed in libzen 0.4.31-2)
On Fri, Aug 21, 2015 at 08:15:51AM +0100, Simon McVittie wrote: On Mon, 17 Aug 2015 at 13:03:26 +, Debian Bug Tracking System wrote: libzen (0.4.31-2) experimental; urgency=medium . * [ddb5069] Perform library transition for GCC 5 rebuild (Closes: #791188) * [aa296c3] Update libzen0v5.symbols std::basic_string has changed moved into a different namespace, changing the symbols of all functions which have it in their signature. (Closes: #792495) * [5e4009d] Add Replaces and Conflicts My understanding is that you can start these transitions in unstable as soon as your library's build-deps have started their transitions (if any). libzen doesn't seem to have any library build-dependencies, so I think it's good to upload now. This blocks at least one other transition (libmediainfo). Hmm? I didn't realize unstable had the new GCC already. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#791188: libzen: library transition to libzen0v5
On Tue, Aug 11, 2015 at 09:12:07AM +0100, Simon McVittie wrote: Control: retitle 791188 libzen: library transition to libzen0v5 Control: severity 791188 serious Control: tags 791188 + patch confirmed Control: block 791139 by 791188 On Fri, 03 Jul 2015 at 13:12:35 +, Matthias Klose wrote: - Decide if the symbols matching __cxx11 or B5cxx11 are part of the library API, and are used by the reverse dependencies of the library. The symbols matching __cxx11 do appear to be part of the library's API. Ubuntu have a patch: https://launchpadlibrarian.net/213027298/libzen_0.4.29-1_0.4.29-1ubuntu2.diff.gz This blocks the equivalent rename for libmediainfo. I'm working on it. Already got an upload prepped, but I hadn't seen the Ubuntu diff. I'll check it out. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#766352: transition: libplist
On Tue, Jun 02, 2015 at 10:11:16AM +0200, Emilio Pozuelo Monfort wrote: On 27/05/15 23:47, Emilio Pozuelo Monfort wrote: Control: tags -1 = confirmed On 27/05/15 22:12, Chow Loong Jin wrote: On Sat, May 16, 2015 at 04:49:45PM +0100, Jonathan Wiltshire wrote: Control: tag -1 moreinfo Hi, On 2014-10-22 14:18, Chow Loong Jin wrote: libplist recently has had an ABI bump with the new upstream release, changing libplist.so.2 - libplist.so.3 and libplist++.so.2 - libplist++.so.3. Do all reverse dependencies build successfully with the new SONAME? The list can be found at https://release.debian.org/transitions/html/libplist.html Yes, except xbmc. However, xbmc itself FTBFS due to a libcec-related error. It doesn't look related to the libplist change. Shall I reupload it to unstable to begin the transition? Yes, go ahead. It is failing on many arches with symbol mismatches: https://buildd.debian.org/status/package.php?p=libplist Odd. Let me just fix that.. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#766352: transition: libplist
On Sat, May 16, 2015 at 04:49:45PM +0100, Jonathan Wiltshire wrote: Control: tag -1 moreinfo Hi, On 2014-10-22 14:18, Chow Loong Jin wrote: libplist recently has had an ABI bump with the new upstream release, changing libplist.so.2 - libplist.so.3 and libplist++.so.2 - libplist++.so.3. Do all reverse dependencies build successfully with the new SONAME? The list can be found at https://release.debian.org/transitions/html/libplist.html Yes, except xbmc. However, xbmc itself FTBFS due to a libcec-related error. It doesn't look related to the libplist change. Shall I reupload it to unstable to begin the transition? -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#783576: [pkg-cli-apps-team] Bug#783576: banshee: crashes on startup - System.ArgumentNullException: Argument cannot be null
tags 783576 + moreinfo unreproducible severity 783576 important kthxbye On Tue, Apr 28, 2015 at 01:05:15PM +1000, Craig Small wrote: Package: banshee Version: 2.6.2-3 Severity: grave Justification: renders package unusable When I try to starup banshee, it just crashes. I looked at the other banshee crashes on startup type bugs and I am pretty sure, but not 100% sure this is yet another way of it crashing. Looks like it's related to some USB device. Could you try unplugging them and seeing if Banshee launches? If that works, please try identifying which USB device causes the issue. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#785305: [pkg-cli-apps-team] Bug#785305: keepass2: option to lock workspace on suspend does not work
On Mon, May 25, 2015 at 11:13:02AM +0200, Peter Spiess-Knafl wrote: Hi! Is there any progress on this bug? I really loose Keepass2 a lot and I saw that is marked for removal because of this bug. Can I help you somehow? Has it been forwared to upstream yet? Odd, isn't this the role of GNOME, rather than Keepass2? I'm on Ubuntu and my screen is locked when going into sleep mode under normal circumstances. This is without using Keepass2. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#785305: [pkg-cli-apps-team] Bug#785305: keepass2: option to lock workspace on suspend does not work
forwarded 785305 https://sourceforge.net/p/keepass/bugs/1378/ kthxbye On Mon, May 25, 2015 at 12:10:22PM +0200, Peter Spiess-Knafl wrote: On 05/25/2015 12:02 PM, Chow Loong Jin wrote: On Mon, May 25, 2015 at 11:13:02AM +0200, Peter Spiess-Knafl wrote: Hi! Is there any progress on this bug? I really loose Keepass2 a lot and I saw that is marked for removal because of this bug. Can I help you somehow? Has it been forwared to upstream yet? Odd, isn't this the role of GNOME, rather than Keepass2? I'm on Ubuntu and my screen is locked when going into sleep mode under normal circumstances. This is without using Keepass2. I think there is a misunderstanding of the word workspace. An opened keepass file is also called workspace. Hmm. I just poked at the keepass2 source code, and it looks like it depends on Windows-based system events (SessionEnding, SessionSwitch, and PowerModeChanged) which aren't implemented in Mono: https://github.com/mono/mono/blob/master/mcs/class/System/Microsoft.Win32/SystemEvents.cs#L127 ...and while looking for the upstream bug tracer, I just found an upstream bug: https://sourceforge.net/p/keepass/bugs/1378/ -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#780991: [3dprinter-general] Bug#780991: slic3r: Slic3r does not start: dependency version mismatch
reassign 780991 libstdc++6 title 780991 Broken shlibs/symbols for libstdc++6 kthxbye On Sun, Mar 22, 2015 at 10:36:48PM +0100, Elena Grandi wrote: Package: slic3r Version: 1.2.6+dfsg-1 Severity: grave Justification: renders package unusable I've installed slic3r from experimental on a mostly testing system, and it does not start because it requires threads.pm = 1.96, while perl 5.20.2 only provides version 1.93 That's not the problem. It'll work with threads.pm 1.93. This is just a warning. The real problem is here: Can't load '/usr/lib/x86_64-linux-gnu/perl5/5.20/auto/Slic3r/XS/XS.so' for module Slic3r::XS: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /usr/lib/x86_64-linux-gnu/perl5/5.20/auto/Slic3r/XS/XS.so) at /usr/share/perl/5.20/XSLoader.pm line 68. It's trying to look for the GLIBCXX_3.4.21 symbol from your libstdc++.so.6 library, but is failing to find this. This means that the libstdc++.so.6 that Slic3r was compiled against is newer than the one you have. ii libstdc++6 4.9.2-10 I checked out this version of libstdc++6 (nm -D /usr/lib/x86_64-linux-gnu/libstdc++.so.6) , and sure enough, the GLIBCXX_3.4.21 symbol is missing. Slic3r's dependency list only suggests that it needs = 4.9, which is wrong. It needs = 5. For the time being, it should work if you just install the libstdc++6 package from experimental. Since native library dependencies are generated automatically during the build process, libstdc++6's symbols file needs to be fixed first, and then slic3r rebuilt against the new one. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#774608: distccmon-gnome looks in the wrong location for its icon
Package: distccmon-gnome Version: 3.1-6 Severity: minor Tags: patch Dear Maintainer, distccmon-gnome looks in PKGDATADIR for distccmon-gnome-icon.png, but this icon has been relocated downstream to /usr/share/pixmaps. Here's a modified version of debian/patches/08_gnome-data-public-dirs.patch that incorporates this fix, and the interdiff between the old and new patches. -- System Information: Debian Release: jessie/sid APT prefers utopic-updates APT policy: (500, 'utopic-updates'), (500, 'utopic-security'), (500, 'utopic'), (100, 'utopic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.17.3-hyper1 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages distccmon-gnome depends on: ii libc6 2.19-10ubuntu2.1 ii libglib2.0-0 2.42.1-1~ubuntu1 ii libgnome2-0 2.32.1-4ubuntu1 ii libgnomeui-0 2.24.5-3 ii libgtk2.0-0 2.24.25-0ubuntu1 distccmon-gnome recommends no packages. Versions of packages distccmon-gnome suggests: ii distcc 3.1-6 -- no debconf information -- Kind regards, Loong Jin Description: Install distccmon-gnome desktop, icon files to public dirs These files are currently put in /usr/share/distcc and as a result the program is not integrated in to the applications menu. . This patch puts them in /usr/share/applications and /usr/share/pixmaps respectively. . Ideally those paths should be configurable at build time. Author: Daniel Hartwig mand...@gmail.com Bug: http://code.google.com/p/distcc/issues/detail?id=111 Bug-Ubuntu: https://bugs.launchpad.net/bugs/512288 --- a/source/Makefile.in +++ b/source/Makefile.in @@ -113,7 +113,8 @@ $(conf_files) \ $(default_files)\ $(dist_extra) \ - $(gnome_data) + $(desktop_files) \ + $(icon_files) dist_dirs = m4 include_server/test_data @@ -373,8 +374,11 @@ man/pump_1.html man/include_server_1.html man/distccmon-gnome_1.html MEN = $(man1_MEN) -gnome_data = gnome/distccmon-gnome-icon.png \ - gnome/distccmon-gnome.desktop +desktopdir = $(datadir)/applications +desktop_files = gnome/distccmon-gnome.desktop + +icondir = $(datadir)/pixmaps +icon_files = gnome/distccmon-gnome-icon.png popt_OBJS=popt/findme.o popt/popt.o popt/poptconfig.o \ popt/popthelp.o popt/poptparse.o @@ -1085,10 +1089,14 @@ $(INSTALL_DATA) $(srcdir)/$$p $(DESTDIR)$(docdir)/example || exit 1; \ done -install-gnome-data: $(gnome_data) - $(mkinstalldirs) $(DESTDIR)$(pkgdatadir) - for p in $(gnome_data); do\ - $(INSTALL_DATA) $$p $(DESTDIR)$(pkgdatadir) || exit 1; \ +install-gnome-data: $(desktop_files) $(icon_files) + $(mkinstalldirs) $(DESTDIR)$(desktopdir) + $(mkinstalldirs) $(DESTDIR)$(icondir) + for p in $(desktop_files); do\ + $(INSTALL_DATA) $$p $(DESTDIR)$(desktopdir) || exit 1; \ + done + for p in $(icon_files); do\ + $(INSTALL_DATA) $$p $(DESTDIR)$(icondir) || exit 1; \ done install-conf: $(conf_files) $(default_files) @@ -1168,11 +1176,16 @@ -rmdir $(DESTDIR)$(docdir)/example uninstall-gnome-data: - for p in $(gnome_data); do\ - file=$(DESTDIR)$(pkgdir)/`basename $$p`;\ + for p in $(icon_files); do \ + file=$(DESTDIR)$(icondir)/`basename $$p`; \ + if [ -e $$file ]; then rm -fv $$file; fi \ + done + for p in $(desktop_files); do \ + file=$(DESTDIR)$(desktopdir)/`basename $$p`;\ if [ -e $$file ]; then rm -fv $$file; fi \ done - -[ `basename $(pkgdir)` = $(PACKAGE) ] rmdir $(DESTDIR)$(pkgdir) + -[ `basename $(icondir)` = $(PACKAGE) ] rmdir $(DESTDIR)$(icondir) + -[ `basename $(desktopdir)` = $(PACKAGE) ] rmdir $(DESTDIR)$(desktopdir) uninstall-conf: for p in $(conf_files); do \ diff -u b/source/Makefile.in distcc-3.1/source/Makefile.in --- b/source/Makefile.in +++ distcc-3.1/source/Makefile.in 2015-01-05 14:21:29.006455909 +0800 @@ -55,7 +55,7 @@ # These must be done from here, not from autoconf, because they can # contain variable expansions written in Make syntax. Ew. -DIR_DEFS = -DSYSCONFDIR=\${sysconfdir}\ -DPKGDATADIR=\${pkgdatadir}\ +DIR_DEFS = -DSYSCONFDIR=\${sysconfdir}\ -DPKGDATADIR=\${pkgdatadir}\ -DICONDIR=\${icondir}\ # arguments to pkgconfig GNOME_PACKAGES = @GNOME_PACKAGES@ only in patch2: unchanged: --- distcc-3.1.orig/source/src/mon-gnome.c 2015-01-05 12:16:21.0 +0800 +++ distcc-3.1/source/src/mon-gnome.c 2015-01-05 14:15:01.417143103 +0800 @@ -599,7 +599,7 @@ #if GTK_CHECK_VERSION(2,2,0) gtk_window_set_icon_from_file (GTK_WINDOW (mainwin), - PKGDATADIR /distccmon-gnome-icon.png, + ICONDIR /distccmon-gnome-icon.png, NULL); #endif signature.asc Description: Digital signature
Bug#773158: nautilus-dropbox: no notification icon is shown
On Mon, Dec 15, 2014 at 02:33:35PM +0900, Norbert Preining wrote: [...] Any suggestion how to debug this behaviour? No idea. I believe the part that generates the notification area icon/indicator applet icon thing is within the closed source portion of dropbox. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#772645: lists.debian.org: Please create debian-moderat...@lists.debian.org
+1 -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#771073: [Pkg-gtkpod-devel] Bug#771073: usbmuxd: Cannot connect via tethering (iphone 3GS)
On Wed, Nov 26, 2014 at 04:06:03PM +0100, Jean-Christophe Dubacq wrote: Package: usbmuxd Version: 1.1.0-1 Severity: normal Dear Maintainer, I have been using happily for some time the iphone tethering. At some point recently (it worked apparently on 2014-11-22, now on 2014-11-26 it does not anymore), I got the following behavior : * No more tethering (enabled on ios of course) * ios says it has connection working (flashing alert message on phone) * gnome/network-manager reports cable as unplugged in USB device * journalctl reports things such as following : [...] I have no idea about which direction to follow for investigation. Well.. to be honest, I haven't a clue either. Could you report this in the upstream bug tracker at https://github.com/libimobiledevice/usbmuxd/issues please? -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#769382: unblock: usbmuxd/1.0.8+git20140527.e72f2f7-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock unblock usbmuxd/1.0.8+git20140527.e72f2f7-2 usbmuxd 1.0.8+git20140527-1 brings support for iOS6 devices and fixes a grave bug[1] in the stack when connecting to these devices. It's been in unstable for 60 days without migrating due to the FTBFS on kfreebsd-{amd64,i386}[2] caused by some eglibc changes. 1.0.8+git20140527-2 fixes the aforementoined FTBFS bug, and drops hurd-i386 as a supported architecture due to the absence of a usable libusb. [1] https://bugs.debian.org/745844 [2] https://bugs.debian.org/765010 -- System Information: Debian Release: jessie/sid APT prefers utopic-updates APT policy: (500, 'utopic-updates'), (500, 'utopic-security'), (500, 'utopic'), (100, 'utopic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.2-hyper1 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#738195: [pkg-cli-apps-team] Processed: reopening 738195
On Tue, Nov 11, 2014 at 04:06:06PM +, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: reopen 738195 Bug #738195 {Done: Chow Loong Jin hyper...@debian.org} [gnome-do] gnome-do: Changed location of homepage Bug #757056 {Done: Chow Loong Jin hyper...@debian.org} [gnome-do] gnome-do: URL needs updating Bug reopened Ignoring request to alter fixed versions of bug #738195 to the same values previously set Ignoring request to alter fixed versions of bug #757056 to the same values previously set thanks Stopping processing here. Why are you reopening this bug? Are there any outdated references left?x https://packages.debian.org/sid/gnome-do seems to show an updated URL to me. Grepping the source for davebsd.com shows nothing. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#766352: transition: libplist
On Wed, Oct 22, 2014 at 03:27:49PM +0200, Emilio Pozuelo Monfort wrote: On 22/10/14 15:18, Chow Loong Jin wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition libplist recently has had an ABI bump with the new upstream release, changing libplist.so.2 - libplist.so.3 and libplist++.so.2 - libplist++.so.3. The transition window is closed for Jessie. Ask again when Jessie is released. Hmm, may I upload to experimental then? -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#766352: transition: libplist
On Thu, Oct 23, 2014 at 02:04:20PM +0200, Emilio Pozuelo Monfort wrote: On 23/10/14 13:11, Chow Loong Jin wrote: On Wed, Oct 22, 2014 at 03:27:49PM +0200, Emilio Pozuelo Monfort wrote: On 22/10/14 15:18, Chow Loong Jin wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition libplist recently has had an ABI bump with the new upstream release, changing libplist.so.2 - libplist.so.3 and libplist++.so.2 - libplist++.so.3. The transition window is closed for Jessie. Ask again when Jessie is released. Hmm, may I upload to experimental then? Sure. Just remember to ask us before uploading to unstable. Alright. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#766352: transition: libplist
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition libplist recently has had an ABI bump with the new upstream release, changing libplist.so.2 - libplist.so.3 and libplist++.so.2 - libplist++.so.3. Ben file: title = libplist; is_affected = .depends ~ libplist(\+\+)?2 | .depends ~ libplist(\+\+)?3; is_good = .depends ~ libplist(\+\+)?3; is_bad = .depends ~ libplist(\+\+)?2; -- System Information: Debian Release: jessie/sid APT prefers trusty-updates APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty'), (100, 'trusty-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.2-hyper1 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#763836: ITP: rhc -- OpenShift command-line tools
Package: wnpp Severity: wishlist Owner: Chow Loong Jin hyper...@debian.org * Package name: rhc Version : 1.31.2 Upstream Author : Red Hat, Inc. * URL : https://www.openshift.com * License : Apache-2.0 Programming Lang: Ruby Description : OpenShift command-line tools OpenShift is a cloud computing platform as a service (PaaS) product from Red Hat. rhc is a command-line client for OpenShift that allows you to remotely manage your OpenShift application. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#745844: [Pkg-gtkpod-devel] Bug#745844: libimobiledevice: Re: libimobiledevice-utils: Segfault with iphone 3GS on many utilities
On Tue, Sep 16, 2014 at 10:51:35AM +0200, Shérab wrote: Hi, I just uploaded a usbmuxd snapshot, seeing that upstream hasn't done anything to usbmuxd for a couple of months. I understand a release is coming soon. That upload fixes the bug for me, thanks!!! Good to know. Thanks for testing. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#761921: [3dprinter-general] Bug#761921: slic3r: Uninstallable, depends on unavailable perlapi-5.18.2
On Tue, Sep 16, 2014 at 10:40:10PM +0200, Andreas Wettergren wrote: Package: slic3r Version: 1.2.0+dfsg-1 Severity: grave Justification: renders package unusable Like the subject says, not installable in experimental at present. 1.1.7+dfsg-2+b1 already depends on perlapi-5.20.0 so this is probably just an oversight? An oversight probably. +b1 means that a binNMU was done, and 1.1.7 is in unstable. I'll look into this. (BTW, running slic3r with perl = 5.16 causes numerical bugs on some locales. Should really be fixed upstream IMHO. Workaround is to run with export LC_NUMERIC=C; slic3r.) What sort of numerical bugs? I'm unaware of this. Could you file these bugs upstream please? -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#761937: nmu: slic3r_1.2.0+dfsg-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu slic3r_1.2.0+dfsg-1 . ALL . -m Rebuild for perlapi-5.20.0 -- System Information: Debian Release: jessie/sid APT prefers trusty-updates APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty'), (100, 'trusty-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.2-hyper1 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#745844: [Pkg-gtkpod-devel] Bug#745844: libimobiledevice: Re: libimobiledevice-utils: Segfault with iphone 3GS on many utilities
On Mon, Sep 15, 2014 at 07:45:52PM +0200, Shérab wrote: Hi, I am encountering the same poblem. The system has usbmuxd 1.0.8-5 and libusbmuxd2:am 1.0.9-1. @Chow Loong Jin I read your coment abuout the usbmuxd package bu I am not sure I understood it, sorry for bothering again. Am I correct that we are aiting until pstream releases usbmuxd 1.0.9 to package it and that it is this release which is supposed tosolve the problem? I just uploaded a usbmuxd snapshot, seeing that upstream hasn't done anything to usbmuxd for a couple of months. I understand a release is coming soon. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#757798: [3dprinter-general] Bug#757798: slic3r: FTBFS with Perl 5.20: out of memory
On Tue, Aug 12, 2014 at 11:34:10PM +0300, Niko Tyni wrote: On Mon, Aug 11, 2014 at 03:30:32PM +0300, Niko Tyni wrote: fixed 757798 1.2.0+dfsg-1 thanks On Mon, Aug 11, 2014 at 03:20:50PM +0300, Niko Tyni wrote: Source: slic3r Version: 1.1.7+dfsg-1 Severity: serious Justification: transition imminent User: debian-p...@lists.debian.org Usertags: perl-5.20-transition This package fails to build with Perl 5.20.0 from experimental, scheduled for sid some time next week. I'm sorry for the lack of previous notice; my earlier test rebuilds were made in June and this package has entered sid after them. Many tests fail with an out of memory message. An example: This seems to be fixed in experimental, 1.2.0+dfsg-1 builds fine. This is https://github.com/alexrj/Slic3r/issues/2109 and the fix is at https://github.com/alexrj/Slic3r/commit/67bf99633e48f9c8a5863b88c2a03fddc1cc247f See Dave Mitchell's comments on the perl5-porters list for a rationale: Message-ID: 20140522115758.gx15...@iabyn.com http://marc.info/?l=perl5-portersm=140075990913228w=2 Great, thanks for identifying the fix! I'll cherry-pick this and make an upload soon. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#757065: smart-notifier: Single degree in temperature should be supressable (i.e. not sufficient to trigger notification)
reassign 757065 smartmontools kthxbye On Mon, Aug 04, 2014 at 08:53:36PM -0400, Daniel Dickinson wrote: Package: smart-notifier Version: 0.28-5 Severity: wishlist I got a notice of drive health change which I tracked down in the syslog to single degree increase in temperature. That's a little too paranoid for me. I'd like to be able to skip single degree temperature (there's that much variation depending on load and ambient temperature changes and in fact today in Ontario it was probably the change in ambient temperature that did it. Odd, I've never had a single degree increase in temperature. I see a lot of these in my syslog, but I've never received any notifications over smart-notifier for this. smart-notifier is a pretty dumb tool -- it just conveys any notifications that smartd calls /etc/smartmontools/run.d/60smart-notifier with (which are incidentally also mailed to you if you configured it so), so there is quite likely a configuration for smartd.conf for this, and it's quite likely that you passed a temperature threshold, in which case, smartd would be right in notifying you about this. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#757269: [3dprinter-general] Bug#757269: slic3r fails to run on sid
On Wed, Aug 06, 2014 at 01:09:24PM -0600, Bdale Garbee wrote: Package: slic3r version: 1.1.7+dfsg-1 Severity: serious On an up-to-date system running sid: bdale@rover:~$ slic3r Running Slic3r under Perl = 5.16 is not supported nor recommended Can't locate object method new via package Slic3r::Model at /usr/share/perl5/Slic3r/GUI/Plater.pm line 53. bdale@rover:~$ Do you perhaps have a stale installation of Slic3r somewhere? I've seen similar complaints before from people who have done a global installation of Slic3r from git, and not properly removed it before installing the deb. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#755273: ITP: yagv -- yet another G-Code visualizer
Package: wnpp Severity: wishlist Owner: Chow Loong Jin hyper...@debian.org * Package name: yagv Version : 0.4~git20130423.r5bd15ed Upstream Author : Jonathan Winterflood jonathan.winterfl...@gmail.com * URL : https://github.com/jonathanwin/yagv * License : CC-BY-3.0 Programming Lang: Python Description : yet another G-Code visualizer yagv is a fast 3D Gcode Viewer for Reprap-style 3D printers, in Python and OpenGL (via pyglet) It has the following features: - Load large files painlessly - Select specific layers to look at - Colour segments according to funciton - Shows a full 3D view for better undersrtanding the G-code. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#745844: [Pkg-gtkpod-devel] Bug#745844: Bug#745844: usbmuxd 1.0.9 fixes all
On Fri, Jul 04, 2014 at 02:17:13PM +0200, Josep M. Perez wrote: Sorry, I feel stupid. Did you notice that there is a link in the Sources and Dependencies section in http://www.libimobiledevice.org/ tousbmuxd-1.0.9.tar.bz2 http://www.libimobiledevice.org/downloads/libusbmuxd-1.0.9.tar.bz2 ? Does libusbmuxd-1.0.9 look like usbmuxd-1.0.9 to you? It sure doesn't to me. The release will happen in due time. Just wait for it and stop bothering this bug report, please. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#753465: [pkg-cli-apps-team] Bug#753465: banshee-extension-openvp: not installable in sid
reassign 753465 libtaoframework-sdl1.2-cil kthxbye On Wed, Jul 02, 2014 at 09:02:46AM +0200, Ralf Treinen wrote: [] Package banshee-extension-openvp (=2.4.0-4) depends on libtaoframework-sdl1.2-cil (= 2.1.svn20090801) No package matches the dependency libsdl-gfx1.2-4 of package libtaoframework-sdl1.2-cil (=2.1.svn20090801-9) Looks like libtaoframework-sdl1.2-cil itself isn't installable, so it should be fixed there instead. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#753148: reproduced on another computer
On Mon, Jun 30, 2014 at 10:38:51AM +0300, Svjatoslav Agejenko wrote: Downloading Dropbox... 100% - it stalls here - Odd. Could you try interrupting it and seeing what errors it produces? (Ctrl+C) -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#753148: reproduced on another computer
On Tue, Jul 01, 2014 at 11:54:21AM +0300, Svjatoslav Agejenko wrote: [...] Process list: ps aux | grep dropbox root 16088 0.0 0.0 58696 1944 pts/15 T11:35 0:00 sudo apt-get install nautilus-dropbox root 16089 0.2 0.2 80124 23812 pts/15 T11:35 0:00 apt-get install nautilus-dropbox root 17110 0.0 0.1 21512 11784 pts/16 Ss+ 11:35 0:00 /usr/bin/dpkg --status-fd 54 --configure nautilus-dropbox:amd64 root 17111 0.0 0.0 4180 544 pts/16 S+ 11:35 0:00 /bin/sh /var/lib/dpkg/info/nautilus-dropbox.postinst configure 1.4.0-3 root 17112 98.6 0.4 80372 35684 pts/16 R+ 11:35 5:01 /usr/bin/python /usr/bin/dropbox update n0 17733 0.0 0.0 7832 852 pts/17 S+ 11:40 0:00 grep dropbox Pressed Ctrl + C multiple times, notheing happens. But Ctrl + Z returns me back to the terminal. Could you try cat /proc/$pid_of_dropbox_process/stack? (In the above case, it would be 17112, but it's not going to be the same when you run it again). It sounds like a network issue where a TCP connection has hung, but I'd like to be sure. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#753081: gpx: FTBFS: python: Command not found
On Sun, Jun 29, 2014 at 12:14:36AM -0400, Aaron M. Ucko wrote: Source: gpx Version: 0~20140109+git3570fc9-1 Severity: serious Justification: fails to build from source Builds of gpx in minimal environments (as on Debian's autobuilders) have been failing when trying to run tests: python scripts/s3g-decompiler.py examples/lint.x3g make[1]: python: Command not found make[1]: *** [test] Error 127 Makefile:60: recipe for target 'test' failed make[1]: Leaving directory '/«BUILDDIR»/gpx-0~20140109+git3570fc9' dh_auto_test: make -j1 test returned exit code 2 make: *** [build-arch] Error 2 Please declare a build dependency on python and confirm with pbuilder or the like that you haven't missed anything else. That's odd. python seems installed on my base unstable schroot. Did it use to be Priority: standard or something? -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#753081: gpx: FTBFS: python: Command not found
On Sun, Jun 29, 2014 at 11:14:34PM -0400, Aaron M. Ucko wrote: Chow Loong Jin hyper...@gmail.com writes: That's odd. python seems installed on my base unstable schroot. Did it use to be Priority: standard or something? It still is, but not all standard packages are build essential, or vice versa; see Policy section 4.2. Oh, alright. I'll just remake my unstable-amd64 schroot then. Thanks for the info. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#753081: gpx: FTBFS: python: Command not found
On Sun, Jun 29, 2014 at 11:31:28PM -0400, Aaron M. Ucko wrote: Chow Loong Jin hyper...@gmail.com writes: Oh, alright. I'll just remake my unstable-amd64 schroot then. Thanks for the info. No problem. If you're using debootstrap, you might find its --variant=buildd flag helpful. Thanks. Looks like mk-sbuild uses that and does the right thing. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#753148: nautilus-dropbox: package fails to install, apt-get install stalls in package configure phase
tags 753148 + needinfo kthxbye On Sun, Jun 29, 2014 at 07:11:45PM +0300, Svjatoslav Agejenko wrote: Package: nautilus-dropbox Severity: important This package used to install fine previously. Now it fails every time. Could you post the terminal output from sudo apt-get install nautilus-dropbox please? It installs successfully on my machine. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#745844: [Pkg-gtkpod-devel] Bug#745844: usbmuxd 1.0.9 fixes all
On Tue, Jun 17, 2014 at 03:00:13PM +0200, Jean-Christophe Dubacq wrote: [...] Please, consider making an official release of 1.0.9, for the benefits of the pour souls that inherited an iPhone as only way to connect to the internet. I'm waiting for a 1.0.9 release from upstream. Try bugging them instead. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#749456: Package name
On Tue, Jun 10, 2014 at 10:16:43PM -0700, Dima Kogan wrote: Chow Loong Jin hyper...@gmail.com writes: On Tue, Jun 10, 2014 at 01:48:36PM -0700, Dima Kogan wrote: If it's not too late, would it be possible to change the name of this package? gpx is also the name of a common file format used for GPS tracks: http://en.wikipedia.org/wiki/GPS_eXchange_Format I think it may be confusing to have a gpx package that refers to something completely different. I know, but upstream is unresponsive, and changing the name downstream seems downright irresponsible. What do you suggest? In cases like this the precedent is to use a dash (-) to disambiguate. For instance the 'ack' searching tool (http://beyondgrep.com/) is in a package called 'ack-grep' to avoid a conflict with an earlier 'ack' package. Could this package be called something like 'gpx-cnc'? Or 'gpx-3d'? A better name exists, probably. Do you think such a change is good, or just keeping it 'gpx' is the way to go? The precedents for git (git-core) and ack (ack-grep) are kind of different -- they were package name conflicts. These are not resolvable without renaming at least one of them. In this case, we're talking about confusion between a package name + /usr/bin binary and a file format. There isn't, to my knowledge, any other executable in PATH by the name of gpx, nor is there a package named gpx, so this is still rather in the gray area. I'm not even sure that there would be much confusion arising from this package being named as gpx -- Not many programs or packages are named exactly the same as the file formats they consume. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#749456: Package name
On Tue, Jun 10, 2014 at 01:48:36PM -0700, Dima Kogan wrote: Hi. If it's not too late, would it be possible to change the name of this package? gpx is also the name of a common file format used for GPS tracks: http://en.wikipedia.org/wiki/GPS_eXchange_Format I think it may be confusing to have a gpx package that refers to something completely different. I know, but upstream is unresponsive, and changing the name downstream seems downright irresponsible. What do you suggest? -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#724631: Is anything happening with this?
Hi, I'd really like to see Slic3r packaged properly for Debian so I can ditch my hacky ~/bin shim-scripts. Is anyone still working on this? If so, are there any issues you're running into that I could help with? Otherwise, I'd like to pick this package up and get it into Debian already. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#724631: Is anything happening with this?
On Mon, May 26, 2014 at 08:46:15PM +0200, Zlatan Todoric wrote: There is 3D printing team [1] so you can join it. Basically its just, do the work and upload it :) Yeah, I noticed. I also saw the git repository. I was just wondering why work on it had stalled, and posted so that I wouldn't stumble over anyone else's toes if I pick this up. Also take a look at wiki page [2]. Thanks, didn't notice this before. [1] https://alioth.debian.org/projects/3dprinter/ [2] https://wiki.debian.org/3D-printer -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#749456: ITP: gpx -- Gcode to x3g conversion post-processor
Package: wnpp Severity: wishlist Owner: Chow Loong Jin hyper...@debian.org * Package name: gpx Version : x.y.z Upstream Author : Dr. Henry Thomas * URL : https://github.com/whpthomas/GPX * License : GPL2+ Programming Lang: C Description : Gcode to x3g conversion post-processor GPX is a post processing utility for converting gcode output from 3D slicing software like Cura, KISSlicer, S3DCreator and Slic3r to x3g files for standalone 3D printing on Makerbot Cupcake, ThingOMatic, and Replicator 1/2/2x printers - with support for both stock and sailfish firmwares. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#746513: nautilus-shares passwordless share not working with samba 4
On Mon, May 12, 2014 at 06:01:35PM -0500, Marco Galicia wrote: You're right, but i think than you can change the configuration provided in /usr/share/doc/nautilus-share/example.conf. That's only an example for people to us if they don't already use an smb.conf. Does it not work if you replace your smb.conf with this one? -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#746931: debhelper: dh_shlibdeps does not handle files with special characters in their names
Package: debhelper Version: 9.20131227ubuntu1 Severity: important Dear Maintainer, When having ELF binaries that start with $, e.g. /usr/lib/blah/$foobar, dh_shlibdeps silently ignores it, presumably due to the way it invokes file to check if the binary is an ELF. $ff=`file $file`; This seems like something that could potentially result in sh injection if it encounters a specially tailored filename. -- System Information: Debian Release: jessie/sid APT prefers trusty-updates APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty'), (100, 'trusty-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14.2-hyper1 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages debhelper depends on: ii binutils 2.24-5ubuntu3 ii dh-apparmor 2.8.95~2430-0ubuntu5 ii dpkg 1.17.5ubuntu5.2 ii dpkg-dev 1.17.5ubuntu5.2 ii file 1:5.14-2ubuntu3 ii man-db 2.6.7.1-1 ii perl 5.18.2-2ubuntu1 ii po-debconf 1.0.16+nmu2ubuntu1 debhelper recommends no packages. Versions of packages debhelper suggests: ii dh-make 0.63 -- no debconf information -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#746513: nautilus-shares passwordless share not working with samba 4
On Sat, May 03, 2014 at 01:09:28AM -0500, Marco Galicia wrote: It may be an issue of samba but it think it can be resolved in nautilus-shares easily if the config provided files are changed. nautilus-share does not provide any config files to samba. It only invokes the net usershare tool (which comes from Samba) to create usershares. Hence, any modification involving Samba's default configuration has to happen within Samba itself. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#746513: nautilus-shares passwordless share not working with samba 4
reassign 746513 samba On Wed, Apr 30, 2014 at 03:19:24PM -0500, Marco Galicia wrote: This is also affecting kde-network-filesharing when trying to setup a passwordless share. Well, if this affects both kde-network-filesharing and nautilus-share, then it's likely to be a samba issue, since that's the common denominator. Reassigning to samba.. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#746630: [Pkg-gtkpod-devel] Bug#746630: src:libimobiledevice: Could you export more 2 symbols?
On Fri, May 02, 2014 at 02:49:59PM +0900, nozzy nozzy wrote: Package: src:libimobiledevice Version: 1.1.6+dfsg-1 Severity: minor Tags: patch Dear Maintainer, I found that 2 symbols are not exported so-lib included libimobiledevice4 pkg, -plist_read_from_filename -plist_write_to_filename Those symbols are necessary to compile new version of usbmuxd downloaded from https://github.com/libimobiledevice/usbmuxd. That's odd, symbols starting with plist_* should really be part of libplist instead of libimobiledevice. *sigh* Could you export those symbols? I'll look into it. FYI: - I will attached a patch to export those symbols. - I've already applied this patch to libimobiledevice src pkg in my debian box(jessie/sid).And I've succeeded to compile the latest version of usbmuxd downloaded from github. The patch below is insufficient. You'll at least need to add these symbols to src/libimobiledevice-symbols.txt as well in order to get the symbols to appear in the built library. (And with the latest version of usbmuxd, I also seems to resolv bug #745844 and also seem that libimobile-utils/ifuse becomes totally works fine with iOS 7.1.1!) That's good. I think I'll try and poke upstream to properly release usbmuxd so I can get it packaged for Debian. [...] --- a/debian/libimobiledevice4.symbols2014-04-14 03:52:15.0 +0900 +++ b/debian/libimobiledevice4.symbols2014-04-22 21:45:55.284262846 +0900 @@ -164,6 +164,8 @@ mobilesync_send@Base 0.9.7 mobilesync_send_changes@Base 1.1.0 mobilesync_start@Base 1.1.0 + plist_read_from_filename@Base 1.1.6 + plist_write_to_filename@Base 1.1.6 np_client_free@Base 0.9.7 np_client_new@Base 0.9.7 np_client_start_service@Base 1.1.6 -- Kind regards, Loong Jin signature.asc Description: Digital signature