Bug#869692: RFS: cyclograph/1.9.1-1
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
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
2017-10-13 22:14 GMT+02:00 Andrey Rahmatullin : > 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
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
> 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
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
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
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)
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 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
> 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
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
>> 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
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
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
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
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 Sat, 15 Jul 2017 16:16:41 +0200 Regards, Federico Brega
Bug#866635: cyclograph: depends on libwebkitgtk-3.0-0 which is deprecated
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
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
Hello, sorry for the late reply. > hmm, there is a JavaScriptCore GIR file which has: > > > > > 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: 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
2014-06-27 8:34 GMT+02:00 Carlos Garcia Campos :
> 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
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
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
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
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 +#include #include #include #include
Bug#662205: ITP: cyclograph -- CycloGraph plots the altimetry of your route
Package: wnpp Severity: wishlist Owner: Federico Brega * Package name: cyclograph Version : 1.5.0 Upstream Author : Federico Brega * 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.
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
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
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
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.
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
