Bug#1064598: [3dprinter-general] Bug#1064598: yagv: crashes with "module 'pyglet.graphics' has no attribute 'vertex_list'"

2024-04-01 Thread Chow Loong Jin
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

2024-01-17 Thread Chow Loong Jin
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

2023-12-05 Thread Chow Loong Jin
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

2023-12-04 Thread Chow Loong Jin
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

2023-11-21 Thread Chow Loong Jin
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

2023-07-25 Thread Chow Loong Jin
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

2023-07-10 Thread Chow Loong Jin
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

2023-07-09 Thread Chow Loong Jin
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

2023-06-04 Thread Chow Loong Jin
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”

2023-01-05 Thread Chow Loong Jin
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)

2022-12-26 Thread Chow Loong Jin
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)

2022-12-20 Thread Chow Loong Jin
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

2022-12-09 Thread Chow Loong Jin
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

2022-11-27 Thread Chow Loong Jin
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

2022-10-04 Thread Chow Loong Jin
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

2021-08-20 Thread Chow Loong Jin
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

2021-07-12 Thread Chow Loong Jin
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

2021-06-07 Thread Chow Loong Jin
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

2021-06-05 Thread Chow Loong Jin
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

2021-06-01 Thread Chow Loong Jin
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

2021-02-20 Thread Chow Loong Jin
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)

2020-12-29 Thread Chow Loong Jin
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

2020-05-13 Thread Chow Loong Jin
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

2020-05-12 Thread Chow Loong Jin
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

2020-05-10 Thread Chow Loong Jin
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

2020-05-04 Thread 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?

-- 
Kind regards,
Loong Jin



Bug#954729: src:mesa: X won't start after upgrading mesa

2020-03-22 Thread Chow Loong Jin
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

2020-03-06 Thread Chow Loong Jin
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

2020-02-27 Thread Chow Loong Jin
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?

2020-02-23 Thread Chow Loong Jin
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?

2020-02-22 Thread Chow Loong Jin
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

2019-10-16 Thread Chow Loong Jin
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

2019-06-08 Thread Chow Loong Jin
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

2019-06-04 Thread Chow Loong Jin
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

2019-03-28 Thread Chow Loong Jin
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)

2018-08-07 Thread Chow Loong Jin
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

2018-08-07 Thread Chow Loong Jin
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

2018-08-06 Thread 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:
 - 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)

2018-08-05 Thread Chow Loong Jin
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

2018-04-15 Thread Chow Loong Jin
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

2018-01-02 Thread Chow Loong Jin
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

2017-10-01 Thread Chow Loong Jin
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

2017-10-01 Thread Chow Loong Jin
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

2017-09-29 Thread Chow Loong Jin
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

2017-09-18 Thread Chow Loong Jin
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

2017-07-15 Thread Chow Loong Jin
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.

2017-06-27 Thread Chow Loong Jin
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

2017-01-19 Thread Chow Loong Jin
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'

2017-01-08 Thread Chow Loong Jin
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

2016-11-13 Thread Chow Loong Jin
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

2016-06-11 Thread Chow Loong Jin
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

2016-03-14 Thread Chow Loong Jin
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

2016-02-07 Thread Chow Loong Jin
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

2015-11-15 Thread Chow Loong Jin
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

2015-08-26 Thread Chow Loong Jin
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)

2015-08-21 Thread Chow Loong Jin
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

2015-08-11 Thread Chow Loong Jin
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

2015-06-02 Thread Chow Loong Jin
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

2015-05-27 Thread Chow Loong Jin
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

2015-05-27 Thread Chow Loong Jin
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

2015-05-25 Thread Chow Loong Jin
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

2015-05-25 Thread Chow Loong Jin
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

2015-03-22 Thread Chow Loong Jin
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

2015-01-04 Thread Chow Loong Jin
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

2014-12-16 Thread Chow Loong Jin
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

2014-12-16 Thread Chow Loong Jin
+1

-- 
Kind regards,
Loong Jin


signature.asc
Description: Digital signature


Bug#771073: [Pkg-gtkpod-devel] Bug#771073: usbmuxd: Cannot connect via tethering (iphone 3GS)

2014-11-26 Thread Chow Loong Jin
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

2014-11-12 Thread Chow Loong Jin
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

2014-11-11 Thread Chow Loong Jin

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

2014-10-23 Thread Chow Loong Jin
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

2014-10-23 Thread Chow Loong Jin
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

2014-10-22 Thread Chow Loong Jin
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

2014-10-02 Thread Chow Loong Jin
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

2014-09-24 Thread Chow Loong Jin
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

2014-09-16 Thread Chow Loong Jin
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

2014-09-16 Thread Chow Loong Jin
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

2014-09-15 Thread Chow Loong Jin
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

2014-08-13 Thread Chow Loong Jin
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)

2014-08-07 Thread Chow Loong Jin
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

2014-08-07 Thread Chow Loong Jin
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

2014-07-19 Thread Chow Loong Jin
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

2014-07-06 Thread Chow Loong Jin
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

2014-07-02 Thread Chow Loong Jin
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

2014-07-01 Thread Chow Loong Jin
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

2014-07-01 Thread Chow Loong Jin
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

2014-06-29 Thread Chow Loong Jin
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

2014-06-29 Thread Chow Loong Jin
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

2014-06-29 Thread Chow Loong Jin
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

2014-06-29 Thread Chow Loong Jin
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

2014-06-17 Thread Chow Loong Jin
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

2014-06-11 Thread Chow Loong Jin
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

2014-06-10 Thread Chow Loong Jin
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?

2014-05-26 Thread Chow Loong Jin
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?

2014-05-26 Thread Chow Loong Jin
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

2014-05-26 Thread Chow Loong Jin
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

2014-05-14 Thread Chow Loong Jin
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

2014-05-03 Thread Chow Loong Jin
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

2014-05-03 Thread Chow Loong Jin
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

2014-05-02 Thread Chow Loong Jin
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?

2014-05-02 Thread Chow Loong Jin
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


  1   2   3   4   >