Bug#869692: RFS: cyclograph/1.9.1-1

[Federico Brega]

Hello,

I've released a final version (1.9.1) with the same source code as in rc3.
I noticed the updates in the Debian policy (4.1.1 and 4.1.2) but they do
not affect this package.
Finally I updated the changelog as requested and tagged the result with gbp.

Bug#866635: cyclograph: depends on libwebkitgtk-3.0-0 which is deprecated

[Federico Brega]

Hi Jeremy,
there is RFS for cyclograph https://bugs.debian.org/869692
I think we should discuss packaging there.

Thanks for your help
--
Federico

Bug#869692: RFS: cyclograph/1.9.1-1

[Federico Brega]

2017-10-13 22:14 GMT+02:00 Andrey Rahmatullin <w...@debian.org>:

> On Fri, Oct 13, 2017 at 10:04:26PM +0200, Federico Brega wrote:
> > In the meantime lintian started to warn about a new
> privacy-breach-generic:
> It was there from the beginning though:
> https://lists.debian.org/debian-mentors/2017/08/msg00048.html
>

My bad I haven't noticed it until now.


> > the package contains an html file which uses Open Layers and has the
> option
> > to show the Google Maps tiles. This obviously involves using the Google
> > Maps service. The usage of this tile is explicitly described as part of
> the
> > Google Maps service so I think it's up to the user to use this service
> and
> > trust Google or not use it.
> >
> > I think that every user should be free to chose the service it wants, so
> > I'd propose to override this warning. The other viable alternative I see
> is
> > to have a Debian patch to disable the Google Maps tiles and use only Open
> > Street Map.


Is my proposal of adding a lintian override Ok?
--
Federico

Bug#869692: RFS: cyclograph/1.9.1-1

[Federico Brega]

Hello,

elyxer will be probabbly removed from Debian in the near future, so we
cannot use it anymore to generate the user manual.
In the RC3 of the package the html file is generated from a asciidoc file.

In the meantime lintian started to warn about a new privacy-breach-generic:
the package contains an html file which uses Open Layers and has the option
to show the Google Maps tiles. This obviously involves using the Google
Maps service. The usage of this tile is explicitly described as part of the
Google Maps service so I think it's up to the user to use this service and
trust Google or not use it.

I think that every user should be free to chose the service it wants, so
I'd propose to override this warning. The other viable alternative I see is
to have a Debian patch to disable the Google Maps tiles and use only Open
Street Map.
--
Federico

Bug#869692: RFS: cyclograph/1.9.0-1

[Federico Brega]

> Please update Standards-Version to he current version.
Done.
This triggers a warning in lintian, which only knows about 4.0.0
This warning is displayed also by other packages already in Debian and
nobody put in place an override for this warning so I though I should do
the same.
Debian policy 4.1.0 §4.15 is about reproducibility, which I was
already targeting,
but it is not 100% clear how can I be sure that my package is reproducible.
I built the package twice and the binary packages are identical, but I don't
know if this is enough.
Priority from extra to optional is now part of the policy so this is
reflected in
the changelog.

> Shipping files like /usr/share/pixmaps/new.svg seems very wrong, they
> should be in a package-specific dir (and not under /usr/share/pixmaps).
All icons are now moved in /usr/share/cyclograph/icons with the exception
of the application icon, which is now also in 48x48 as required by freedesktop
specifications. A couple more sizes have been provided in png format.

> Qt frontend doesn't work: ImportError: cannot import name 'QtWebEngineWidgets'
Added the missing dependency to qtwebengine

> You shouldn't use the full icon paths in .desktop Icon, definitely not
> ones for 32x32.
I ran desktop-file-validate and it mislead me to add the full path,
The file extension should have been removed, and now they are.

Regards
--
Federico

Bug#869692: RFS: cyclograph/1.9.0-1

[Federico Brega]

We've finally manage to get a new upstream release, which is 1.9.1~rc1
We went for an rc1 because we want to have binary packages only once the source
are acceptable. So rc2 is planned to include only changes needed for
debian packaging.
Once the source is Ok for debian, the final release will be made
upstream with the
same sources of the last rc.

First of all: this bug refers to 1.9.0 but we are talking about 1.9.1
from now on, is a
separate bug needed?

> > > Patch headers should be in the DEP-3 format (lintian tells that).
Done

> > > doc/manual.html says it's autogenerated from a LyX source
They are now generated from the lyx file, with the obvious addition of
elyxer to the b-d.

> > > The same for cyclograph/qt/cyclograph_rc.py which is pyrcc5-generated.
The file is now generated by pyuicc, with the addition of
pyqt4-dev-tools to the b-d.

Also the gui files are edited by qt designer so the code generation
has been included in
the setup script, too.

The same goes for gettext

> > > The GUIs still have a "Check online" checkbox which is even on by default
> > > even if it has no effect, it should be hidden.
> > Ok, thanks for the care you are giving to this package.
> > To fix this a patch or a new upstream release is required. Are both options
> > acceptable?
> Which both options?
I was asking I a debian patch is acceptable to hide the checkbox. The
other option is
a new upstream implementing the change. Anyways we went for the second option to
keep the debian patch short.
--
Federico

Bug#872285: More info about nondeterminism_added_by_pyqt5_pyrcc5

[Federico Brega]

Hi Ximin,

> It might be safer to subclass QHash into a deterministic QDetHash or 
> something. This would allow one to use QHash both non-deterministically (to 
> protect against DoS attacks) and deterministically in the same program, 
> depending on the use-case.
>
> For example, the rust compiler internally uses a deterministic hash table but 
> offers a non-deterimistic version in its standard library, see 
> https://github.com/rust-lang/rust/issues/34902 for details.
This is the perfect for upstream bug, a debian patch would be tool
large, and nor really robust.

> You are setting seed = 0 in a header file. If this is a public header file, 
> then anyone that #includes it would lose protection against those attacks, 
> not just pyrcc.
My understanding was that rcc.h is a private header, which is only
included by the python module pyrcc which is also private, and can be
used only within PyQt.
The only alternative I can implement is changing the shell wrapper
(pyrcc5) that calls python3, the QT_HASH_SEED variable can be set in
this wrapper, so it is clear than only pyrcc can be affected.

For sure any upstream solution is better then a debian patch.


--
Federico

Bug#872285: More info about nondeterminism_added_by_pyqt5_pyrcc5

[Federico Brega]

Hi Ximin,

> It might be safer to subclass QHash into a deterministic QDetHash or 
> something. This would allow one to use QHash both non-deterministically (to 
> protect against DoS attacks) and deterministically in the same program, 
> depending on the use-case.
>
> For example, the rust compiler internally uses a deterministic hash table but 
> offers a non-deterimistic version in its standard library, see 
> https://github.com/rust-lang/rust/issues/34902 for details.
This is the perfect for upstream bug, a debian patch would be tool
large, and nor really robust.
For sure any upstream solution is better then a debian patch.

> You are setting seed = 0 in a header file. If this is a public header file, 
> then anyone that #includes it would lose protection against those attacks, 
> not just pyrcc.
My understanding was that rcc.h is a private header, which is only
included by the python module pyrcc which is also private, and can be
used only within PyQt.
The only alternative I can implement is changing the shell wrapper
(pyrcc5) that calls python3, the QT_HASH_SEED variable can be set in
this wrapper, so it is clear than only pyrcc can be affected.

--
Federico

Bug#872285: pyqt5-dev-tools: please make the built resources reproducible (randomness)

[Federico Brega]

Package: pyqt5-dev-tools
Version: 5.7+dfsg-5+b1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness

Hello.

I noticed that the python files generated by pyrcc5 are not reproducible.

I attached a patch to set the seed of QHash, which is used by the cpp part of 
pyrcc. This removes the randomness out of QHash, so generating the same 
resource file twice gives identical files.
Description: Make the build reproducible
Author: Federico Brega <charon...@gmail.com>
Last-Update: 2017-08-15

--- a/qpy/pyrcc/rcc.h
+++ b/qpy/pyrcc/rcc.h
@@ -124,6 +124,7 @@
 mCompressLevel = -1;
 mCompressThreshold = 70;
 mTreeOffset = mNamesOffset = mDataOffset = 0;
+qSetGlobalQHashSeed(0);
 }
 
 struct RCCFileInfo

Bug#869692: RFS: cyclograph/1.9.0-1

[Federico Brega]

> Patch headers should be in the DEP-3 format (lintian tells that).

Now I have to ask for the option needed for lintian to tell that.
I run lintian --display-info and it is not reporting anything about the patches.
The lintian report at https://mentors.debian.net/package/cyclograph
isn't showing anything suspicious either.
How can I get that kind of level out of lintian?

> Instead of "Removed pycompat file because lintinan says it is obsolete"
> you should write "Removed obsolete debian/pycompat".
Ok

> doc/manual.html says it's autogenerated from a LyX source yet the source
> and a way to regenerate it from that source are not included. This is a
> DFSG violation.
It's not auto-generated, but generated. I use LyX as my editor, it saves
the file in an internal format, and I export it to html.
I don't see any violation to DFSG §2, which is the closes to the subject.
I'm sure may other packages have some kind of xml in their sources but
the editor is not listed in the B-D.

> The same for cyclograph/qt/cyclograph_rc.py which is pyrcc5-generated.
I agree more on this, because the resource file is a kind of binary /
obfuscated code. It contains only artworks and the same html files used
by cyclograph-gtk3. If the generation process has to be done in debian
I don't think a new upstream release can be avoided, because the file
needed to build the resource file is not distributed in the tar.
We'll try to have the package working with no resource file installed at all,
but would it be acceptable to have it in the source package or a repack
would be needed?

> The GUIs still have a "Check online" checkbox which is even on by default
> even if it has no effect, it should be hidden.
Ok, thanks for the care you are giving to this package.
To fix this a patch or a new upstream release is required. Are both options
acceptable?

--
Federico

Bug#869692: rfs-howto

[Federico Brega]

I uploaded the package, updated with all the modifications discussed earlier.
It can be found here:
https://mentors.debian.net/debian/pool/main/c/cyclograph/cyclograph_1.9.0-1.dsc
--
Federico

Bug#869692: RFS: cyclograph/1.9.0-1

[Federico Brega]

>> Please take a look at the new changelog and see if this is now clear.
> It's better, but I would write it in this way:
>
> - Switch to pybuild
> - Add dh-python, python3-all, python3-setuptools to Build-Depends
> - Switch the cyclograph package to Python 3
Ok, this looks very clear.

>> > * The package now uses dh-python in combination with python3-setuptools
>> > "in combination"?
>> My understanding is that pybuild, provided by the dh-python package,
>> needs the setuptools for python3
> Why do you think pybuild needs setuptools? The package seems to build fine
> without that B-D.

I think you are right. I didn't understand how pybuild works.
Setuptools is not needed.

> It seems you haven't run lintian:
...
> At least vcs-field-uses-insecure-uri, vcs-field-not-canonical and
> spelling-error-in-changelog are caused by the changes in this upload, but
> you should fix other problems too.

gbp buildpackage runs lintian with the standard level, so I missed the
info, and I did not run it again aftr changing the chagelog at last. I
tried getting rid of all the warnings and most of the infos.


> Why there is no separate section for debian/ in debian/copyright? Are the
> copyright authors the same for it and the software itself?

Yes the copyright authors are the same of the package authors. Is a
separate section needed also in this case?

> You should fix the .desktop files. Currently having "python
> /usr/bin/cyclograph" there is not just unneeded, it's wrong, as
> /usr/bin/cyclograph is now using Python 3.

I added desktopFilesFix.diff in debian/patches

> Priority should be optional, not extra.
Ok

Thank you for your help
--
Federico

Bug#869692: rfs-howto

[Federico Brega]

Hello Al,
I'm not so sure about what you mean for uploading here.
Attaching the .dsc file alone seems useless to me, so I uploaded all the files
produced by "gbp buildpackage" to the project hosting on sourceforce.

You can get it using:
dget -x -u http://cyclograph.sourceforge.net/debian/cyclograph_1.9.0-1.dsc

I'm not in the keyring so the "-u" is really needed.

Sadly, I don't think this will be in time, because the package will be removed
tomorrow.


On Sat, 05 Aug 2017 15:48:43 +0300 Al Nikolov  wrote:
> Hi Federico,
>
> Please see [1] for an RFS bug template.
>
> [1]https://mentors.debian.net/sponsor/rfs-howto
>
> What is still missing in your report, is the link to the published
> package itself you want to be sponsored.
>
> It should lead essentially to the `.dsc` file (m.d.n lists them
> automatically if you upload there). Mentioning "it can be build with
> gdb" is not enough and cloning Git repository in order to simply build
> a package is a nuisance. Both put unnecessary restrictions on the
> sponsorship process.

Bug#869692: RFS: cyclograph/1.9.0-1

[Federico Brega]

On the git server you can find a new commit with all the changes requested.

2017-07-29 19:34 GMT+02:00 Andrey Rahmatullin :
> * The package now depends on python3
> Which package?
It's both a build dependency and a runtime dependency of "cyclograph"
the main binary package. The cyclograph-qt5 and cyclograph-gtk3 binary
packages depend on cyclograph, so they all depend on python3.
Please take a look at the new changelog and see if this is now clear.
> * The package now uses dh-python in combination with python3-setuptools
> "in combination"?
My understanding is that pybuild, provided by the dh-python package,
needs the setuptools for python3, but, since it cannot know if python2
or python3 is used, the correct B-D has to be manually added.
Please take a look at the new changelog and see if this is now clear.
> * Added cyclograph-qt5 ui
> Not clear that cyclograph-qt5 is a new subpackage.
Ok, last entry in the changelog was about the removal of
cyclograph-qt4, but I can understand that a longer description in the
changelog is more useful.
> * Debhelper compat version updated to 10
> It's "compat level", see debhelper(7).
Sorry for that. I confused the Debhelper version, with the compatibility level.
> * Updated Standards to 4.0.0
> It's "Standards-Version", and it's customary to add "(no change needed)"
> if an upgrade to the new version didn't require anything (I assume you've
> read the upgrade checklist?).
I read the checklist[1] and I didn't find anything to be done.
"(no change needed)" added.
> * Updated gtk to webkit2 version 4.0
> Not clear what is "gtk" here.
This is the "cyclograph-gtk3".
> * Added vcs field to debian/control
> It's not a "vcs" field but Vcs-Git and Vcs-Browser.
Modified
> You also didn't mention the switch to pybuild.
Added

 [1] https://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt
--
Federico

Bug#869692: RFS: cyclograph/1.9.0-1

[Federico Brega]

Thank you Andrey for your help.
My changes to your suggestions are commented below and can be found in the
git repository.

> You don't need to add your name in brackets if there are no other names.
Removed

>>   * Debhelper compat version updated to 9
> The current recommended level is 10.
Switched to 10, both in debian/compat and in Build-Depends: debhelper (>= 10~)

> And there are other changes (about python for example) that are not listed
> in the changelog.
I listed all the changes done to files in the "debian" folder. The
other changes are
all made by upstream and, in my understanding, are out of scope from the debian
changelog.

Please tell me if I misunderstood something.
Regards
--
Federico

Bug#869692: RFS: cyclograph/1.9.0-1

[Federico Brega]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "cyclograph":

git://git.debian.org/pkg-running/cyclograph.git

It can be built with gbp.

Changes since the last upload:
This is important because it is currently affected by and RC bug, which
is closed by this upload.

cyclograph (1.9.0-1) UNRELEASED; urgency=medium

  [ Federico Brega ]
  * New upstream release
  * Added cyclograph-qt5 ui
  * Debhelper compat version updated to 9
  * Updated Standards to 4.0.0
  * Updated gtk to webkit2 version 4.0 (closes: bug#866635)
  * Added vcs field to debian/control

  -- Federico Brega <charon...@gmail.com>  Sat, 15 Jul 2017 16:16:41 +0200

Regards,
Federico Brega

Bug#866635: cyclograph: depends on libwebkitgtk-3.0-0 which is deprecated

[Federico Brega]

Hello,

I saw your bug, and a new release of cyclograph (1.9.0) got rid of the
deprecated webkit dependency.
Nevertheless I cannot assure that the package will be uploaded in
testing before the autoremoval occurs.
Since this issue affects only one of the binaries provided, is there
any way to just remove the gtk UI (cyclograph-gtk3) and leave the main
package in testing?
Another solution could be a nmu since I've already pushed the
packaging of the latest version of the packag on the pkg-runnign-devel
git repository, but the debian maintainers in the group are probably
busy to upload it.

Please let me know if any of these solutions can cope with the bug.
--
Federico

Bug#850470: qt3d5-examples: QML examples not running because of a missing dependency

[Federico Brega]

Package: qt3d5-examples
Version: 5.7.1+dfsg-1
Severity: normal

Dear Maintainer,

I installed qt3d5-examples but none of the qml examples was running.

For instance, running the simple-qml executable gives:
qrc:/main.qml:55:1: module "Qt3D.Extras" is not installed
qrc:/main.qml:52:1: module "Qt3D.Core" is not installed
qrc:/main.qml:54:1: module "Qt3D.Input" is not installed
qrc:/main.qml:53:1: module "Qt3D.Render" is not installed
qrc:/main.qml:55:1: module "Qt3D.Extras" is not installed
qrc:/main.qml:52:1: module "Qt3D.Core" is not installed
qrc:/main.qml:54:1: module "Qt3D.Input" is not installed
qrc:/main.qml:53:1: module "Qt3D.Render" is not installed
qrc:/main.qml:55:1: module "Qt3D.Extras" is not installed
qrc:/main.qml:52:1: module "Qt3D.Core" is not installed
qrc:/main.qml:54:1: module "Qt3D.Input" is not installed
qrc:/main.qml:53:1: module "Qt3D.Render" is not installed
qrc:/main.qml:55:1: module "Qt3D.Extras" is not installed
qrc:/main.qml:52:1: module "Qt3D.Core" is not installed
qrc:/main.qml:54:1: module "Qt3D.Input" is not installed
qrc:/main.qml:53:1: module "Qt3D.Render" is not installed

Installing "qml-module-qt3d" resolves the problem, please add it to the
dependencies.

Regards

Federico


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qt3d5-examples depends on:
ii  libc6   2.24-8
ii  libqt53dcore5   5.7.1+dfsg-1
ii  libqt53dextras5 5.7.1+dfsg-1
ii  libqt53dinput5  5.7.1+dfsg-1
ii  libqt53dquick5  5.7.1+dfsg-1
ii  libqt53dquickextras55.7.1+dfsg-1
ii  libqt53drender5 5.7.1+dfsg-1
ii  libqt5core5a5.7.1+dfsg-2
ii  libqt5gui5  5.7.1+dfsg-2
ii  libqt5qml5  5.7.1-1
ii  libqt5quick55.7.1-1
ii  libqt5widgets5  5.7.1+dfsg-2
ii  libstdc++6  6.2.1-5
ii  qml-module-qtquick-scene3d  5.7.1+dfsg-1

qt3d5-examples recommends no packages.

qt3d5-examples suggests no packages.

-- no debconf information

Bug#749251: [webkit-gtk] Bug#749251: cyclograph-gtk2: depends on python-webkit which is deprecated

[Federico Brega]

Hello,

sorry for the late reply.

 hmm, there is a JavaScriptCore GIR file which has:

 record name=GlobalContext c:type=JSGlobalContextRef foreign=1/
 record name=Value c:type=JSValueRef foreign=1/

 That is not sufficient from what you're saying? In Debian the gir file is on
 the jsc dev package and the typelib in gir1.2-javascriptcoregtk-1.0.

Tank you for your suggestion but it doesn't solve the issue.
I added the following two lines at top of the example file:

from gi.repository import JavaScriptCore
print JavaScriptCore.Value

The result is:

class 'gi.repository.JavaScriptCore.Value'
Traceback (most recent call last):
  File example.py, line 9, in get_res
v = result_js.get_value()
TypeError: Couldn't find conversion for foreign struct 'JavaScriptCore.Value'

From the first output line I understand that the module is imported,
but something obscure happens.

Regards
--
Federico


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#749251: [webkit-gtk] Bug#749251: cyclograph-gtk2: depends on python-webkit which is deprecated

[Federico Brega]

2014-06-27 8:34 GMT+02:00 Carlos Garcia Campos cgar...@igalia.com:
 Yes, the problem is that webkit_javascript_result_get_value() returns a
 JSValueRef, but there's no gobject-introspection for JavaScriptCore API.
 I don't think it worked in WebKit1 either, but in WebKit1
 webkit_web_view_run_script didn't return anything, so if you are porting
 from WebKit1, maybe you can just ignore the return value for now. I have
 some comments about the code, see below.

Thank you for your comments, we'll consider them while porting the
codebase to webkit2.
As you already said webkit1 doesn't have a proper way to get results back
from javascript so we are using an hack:


self.view.execute_script(oldtitle=document.title;document.title=document.getElementById('gpx').innerHTML)
gpxcontent = unicode(self.view.get_main_frame().get_title())
self.view.execute_script('document.title=oldtitle;')

We hoped to avoid this and use something nicer.
Is this still doable? Is there a cleaner way?

Regards
--
Federico


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#688918: Solved with the update of qt-at-spi

[Federico Brega]

I've found out that this issue was cause by qt-at-spi accessibility bridge.
Updating it from version 0.3.1-1 to 0.3.1-2 fixes the issue.
I don't understand how this affects so heavily only virtualbox since
I'm running KDE so most
of the applications I'm using is Qt based.

Regards
--
Federico


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#688988: qt-at-spi: unable to see Qt-based applications listed in as accessible

[Federico Brega]

Package: qt-at-spi
Version: 0.3.1-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,
I tried to use the qt-at-spi package but I don't see any result after its 
installation.
My goal was to use ldtp for Qt-based applications, but I can't see any of the 
Qt dev tools (linguist, designer, ...) listed while thery are running.
ldtp is working for GTK-based applications, so I guess my at-spi setup is 
properly configured.

Steps to reproduce:
* in bash
 apt-get install ldtp python-ldtp qt-at-spi
 export QT_ACCESSIBILITY=1
 linguist 

* in python
 from ldtp import *
 getapplist()

Expected result: linguist in the application list.
Actual result: empty list.

I installed gnome-orca and when I  launch it with the -l option no application 
gets listed.
I'm not sure if this is enough to raise the severity to critical. 

Regards

Federico


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash

Versions of packages qt-at-spi depends on:
ii  libatspi2.0-0  2.5.3-1
ii  libc6  2.13-35
ii  libdbus-1-31.6.0-1
ii  libgcc11:4.7.2-2
ii  libqt4-dbus4:4.8.2+dfsg-2
ii  libqtcore4 4:4.8.2+dfsg-2
ii  libqtgui4  4:4.8.2+dfsg-2
ii  libstdc++6 4.7.2-2

qt-at-spi recommends no packages.

qt-at-spi suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#688918: virtualbox: Abort a while after the settings menu is shown

[Federico Brega]

Package: virtualbox
Version: 4.1.18-dfsg-1
Severity: important

Dear Maintainer,
I due to some updates entered in testing last week I can't use virtualbox 
anymore.
When I try to start an existng VM its window is closed a few instants later, on 
the console I see the error message:

libgcc_s.so.1 must be installed for pthread_cancel to work
Aborted

The same message is show when I try chenging the settings of any VM, but in 
this case the entire application gets closed.
I reinstalled libgcc1 and virtualbox to be sure it wasn't badly installed for 
some reason and tried the packages available in unstable but I don't see any 
change.

It may not be specific to virtualbox because I saw some unstable behaviours in 
other applications, too but I don't have any idea about which package is more 
relevant.


Federico

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash

Versions of packages virtualbox depends on:
ii  adduser  3.113+nmu3
ii  dpkg 1.16.8
ii  libc62.13-35
ii  libcurl3 7.26.0-1
ii  libgcc1  1:4.7.2-2
ii  libgsoap22.8.7-1
ii  libpng12-0   1.2.49-1
ii  libpython2.7 2.7.3~rc2-2.1
ii  libsdl1.2debian  1.2.15-5
ii  libssl1.0.0  1.0.1c-4
ii  libstdc++6   4.7.2-2
ii  libvncserver00.9.9+dfsg-1
ii  libx11-6 2:1.5.0-1
ii  libxcursor1  1:1.1.13-1
ii  libxext6 2:1.3.1-2
ii  libxml2  2.8.0+dfsg1-5
ii  libxmu6  2:1.1.1-1
ii  libxt6   1:1.1.3-1
ii  python   2.7.3~rc2-1
ii  python2.72.7.3~rc2-2.1
ii  zlib1g   1:1.2.7.dfsg-13

Versions of packages virtualbox recommends:
ii  libgl1-mesa-glx [libgl1]  8.0.4-2
ii  libqt4-opengl 4:4.8.2+dfsg-2
ii  libqtcore44:4.8.2+dfsg-2
ii  libqtgui4 4:4.8.2+dfsg-2
ii  virtualbox-dkms   4.1.18-dfsg-1
ii  virtualbox-qt 4.1.18-dfsg-1

Versions of packages virtualbox suggests:
ii  vde22.3.2-4
ii  virtualbox-guest-additions-iso  4.1.18-1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#663052: leds-alix-source: module fails to compile

[Federico Brega]

Package: leds-alix-source
Version: 0.0.1-1
Severity: grave
Tags: upstream patch
Justification: renders package unusable

Dear Maintainer,
the source package does not compile; the first error message is about 
THIS_MODULE being undefined.

Please find the attached patch which solves the bug.

Federico


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages leds-alix-source depends on:
ii  bzip2 1.0.6-1
ii  debhelper 9.20120115
ii  make  3.81-8.1
ii  module-assistant  0.11.4

leds-alix-source recommends no packages.

leds-alix-source suggests no packages.

-- no debconf information

-- 

*Federico Brega*Phone:  +39 02  90380812 - Int. 180
/AOCS Engineer/ Fax:+39 02  9010059
E-Mail: federico.br...@temissrl.com mailto:federico.br...@temissrl.com
*TEMIS S.r.l.* http://www.temissrl.com,
Via G. Donizetti 20
20011 Corbetta(MI), Italy 
--- old-leds-alix.c	2012-03-07 19:37:51.416914640 +0100
+++ leds-alix.c	2012-03-07 19:10:03.212963445 +0100
@@ -11,6 +11,7 @@
  */
 
 #include linux/kernel.h
+#include linux/module.h
 #include linux/init.h
 #include linux/platform_device.h
 #include linux/leds.h

Bug#662205: ITP: cyclograph -- CycloGraph plots the altimetry of your route

[Federico Brega]

Package: wnpp
Severity: wishlist
Owner: Federico Brega charo...@gmail.com

* Package name: cyclograph
  Version : 1.5.0
  Upstream Author : Federico Brega charo...@gmail.com
* URL : http://cyclograph.sourceforge.net/
* License : GPL v3
  Programming Lang: Python
  Description : CycloGraph plots the altimetry of your route

CycloGraph is a program useful for cyclists (but not only for them). It shows 
a graphical rapresentation of the route. You can manually provide data on the 
route you want to visualize (distance, altitude) or import from files produced 
from commercial or closed software witch does a similar task.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#437203: Build strigi with inotify support.

[Federico Brega]

Upstream enabled inotify by default, and I don't see any configuration
option in debian/rules that disables it.
Shouldn't this bug be closed?

Regards

--
Federico



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#566891: Unexpected behavior

[Federico Brega]

Hello,
I had the same problem described in this bug, and I was expecting nm
status to be cleared after reboot.
Even if it doesn't completely solve the issue, the script in init.d
should wake network-manager when [re]start.
The issue is made worst by knetworkmanager which doesn't allow to wake
network-manager.

Thanks

Federico



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#567473: knetworkmanager

[Federico Brega]

I know that kde3 knetworkmanager is not mantained upstream but I think
its dependecy should be corrected: it requires network-manager = 0.7
 0.7.999
It may be too late for this.
Cheers

Federico



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#534119: Re: Bug#534119: kopete: statistics module doesn't work

[Federico Brega]

Hello,
installing libqt4-sql-sqlite fixes the issue for me.
Shouldn't Kopete depend/recommend on this packege?

Regards

Federico Brega



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#514003: python decimal floating point arithmetic.

[Federico Brega]

In bug report module and class name are inverted.
In my installation of Lenny everything works fine.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org