Bug#606988: A new amsn version is out (0.98.4)
Subject: A new amsn version is out (0.98.4) Package: amsn Version: 0.98.3-0ubuntu1 Severity: normal Hello everyone, aMSN 0.98.4 is out, in the spirit of the holiday season! It contains several bugfixes, including the bug which made you unable to read Offline Messages. This should be our last bugfix release before 0.99, in which we will enable Audio/Video calls again, as we’ve been working hard on implementing the newest P2P protocol changes. please update as soon as possible -- System Information: Debian Release: squeeze/sid APT prefers lucid-updates APT policy: (500, 'lucid-updates'), (500, 'lucid-security'), (500, 'lucid-proposed'), (500, 'lucid-backports'), (500, 'lucid'), (500, 'karmic-backports') Architecture: amd64 (x86_64) Kernel: Linux 2.6.36-02063601-generic (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 Versions of packages amsn depends on: ii amsn-data 0.98.3-0ubuntu1 Data files for aMSN ii gstreamer0.10-n 0.0.10-2build1 ICE library (GStreamer plugin) ii libc6 2.11.1-0ubuntu7.6Embedded GNU C Library: Shared lib ii libgcc1 1:4.5.0-4ubuntu1 GCC support library ii libglib2.0-02.24.1-0ubuntu1 The GLib library of C routines ii libgssdp-1.0-2 0.7.2-2build1GObject-based library for SSDP ii libgstfarsight0 0.0.17-2ubuntu2 Audio/Video communications framewo ii libgstreamer-pl 0.10.28-1GStreamer libraries from the base ii libgstreamer0.1 0.10.28-1Core GStreamer libraries and eleme ii libgupnp-1.0-3 0.13.4-1build1 GObject-based library for UPnP ii libgupnp-igd-1. 0.1.3-4ubuntu1 library to handle UPnP IGD port ma ii libjpeg62 6b-15ubuntu1 The Independent JPEG Group's JPEG ii libpng12-0 1.2.42-1ubuntu2.1PNG library - runtime ii libsnack2-alsa 2.2.10-dfsg1-9 Sound extension to Tcl/Tk and Pyth ii libsoup2.4-12.30.2-0ubuntu0.1an HTTP library implementation in ii libstdc++6 4.4.3-4ubuntu5 The GNU Standard C++ Library v3 ii libv4l-00.6.4-1ubuntu1 Collection of video4linux support ii libx11-62:1.3.2-1ubuntu3 X11 client-side library ii libxml2 2.7.6.dfsg-1ubuntu1.1GNOME XML library ii tcl-tls 1.5.0.dfsg-9 the TLS OpenSSL extension to Tcl ii tk8.5 8.5.8-1 Tk toolkit for Tcl and X11, v8.5 - ii xdg-utils 1.0.2-6.1ubuntu3 desktop integration utilities from ii zlib1g 1:1.2.3.3.dfsg-15ubuntu1 compression library - runtime amsn recommends no packages. Versions of packages amsn suggests: ii1.0.22-0ubuntu5ALSA utilities pnnone (no description available) ii3.6.13+build3+nobinonly-0ubuntu0.10.04 safe and easy web browser from Moz ii8.4.19-4 Tcl (the Tool Command Language) v8 ii8.5.8-2Tcl (the Tool Command Language) v8 -- 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#557754: amsn: CVE-2006-0138 denial-of-services
Hi everybody, please look at [1] the new amsn 0.98.9 fixes those vulnerabilities, so can please you consider adding amsn back? thanks [1] http://sourceforge.net/mailarchive/forum.php?thread_name=CAO3MEfCKyEDFo%2BFuwkFepb2akUgMKVdvmNU9UsF%2B6kUdV0zxnw%40mail.gmail.comforum_name=amsn-devel
Bug#670840: ettercap should depend from 'menu' package
Package: ettercap-graphical Version: 1:0.7.4.2-1 Severity: normal Dear Maintainer, ettercap should depend from 'menu' package. please see https://bugs.launchpad.net/ubuntu/+source/ettercap/+bug/991103 -- System Information: Debian Release: wheezy/sid APT prefers precise-updates APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 'precise-proposed'), (500, 'precise'), (100, 'precise-backports') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-24-generic (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 Versions of packages ettercap-graphical depends on: ii ettercap-common 1:0.7.4.2-1 ii libc6 2.15-0ubuntu10 ii libglib2.0-0 2.32.1-0ubuntu2 ii libgtk2.0-0 2.24.10-0ubuntu6 ii libltdl7 2.4.2-1ubuntu1 ii libncurses5 5.9-4 ii libnet1 1.1.4-2.1 ii libpcap0.8 1.1.1-10 ii libpcre3 8.12-4 ii libssl1.0.0 1.0.1-4ubuntu5 ii libtinfo5 5.9-4 ii zlib1g 1:1.2.3.4.dfsg-3ubuntu4 Versions of packages ettercap-graphical recommends: ii gksu 2.0.2-6ubuntu1 ettercap-graphical suggests no packages. -- no debconf information
Bug#646581: (no subject)
This bug should be closed, opened against wrong package.
Bug#702534:
I'm untagging this patch and closing this bug, since the ftbfs on x32 seems to be not failing anymore. thanks G. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681726: Kepler has been released.
According to wiki There is also a 3.8 release of Eclipse, but it is not promoted anywhere on their web site, directing interested users to 4.2. Eclipse 3.8 provides bugfixes for Indigo adds Java 7 support, but is not a 'packaged distribution' release, and will not be maintained after 4.3 Kepler is released. Features and plugins equivalent to a packaged distribution may be added from within the IDE. Kepler has been released one month ago. So please consider updating eclipse to kepler. Thanks Gianfranco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713045: (no subject)
Hi Mdt, which kind of problem are you referring to? Gianfranco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711948: (no subject)
Attached the debian patch for closing this issue.
Please consider its upload.From: Gianfranco Costamagna costamagnagianfra...@yahoo.it
Date: Wed, 31 Jul 2013 09:51:49 +0200
Subject: [PATCH] Fixed bug #711948 and maybe #712228
---
changelog | 10 ++
control | 14 +++---
rules | 9 +++--
3 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/changelog b/changelog
index ef4c84b..ea93665 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,13 @@
+ghc (7.6.3-4) unstable; urgency=low
+
+ * Team upload
+ * Switch to llvm (Closes: #711948)
+ * removed deprecated DM-Upload-Allowed
+ * removed some version checks, higher versions are already in oldstable.
+ * Added dpkg-buildflags as build-dep, fixing lintian warning.
+
+ -- Gianfranco Costamagna costamagnagianfra...@yahoo.it Mon, 29 Jul 2013 10:32:24 +0200
+
ghc (7.6.3-3) unstable; urgency=low
* Add patches/Handle-sign-bit-when-generating-veneer-for-ARM-Thumb.patch,
diff --git a/control b/control
index 8bd6be5..19649df 100644
--- a/control
+++ b/control
@@ -4,7 +4,6 @@ Priority: extra
Maintainer: Debian Haskell Group pkg-haskell-maintain...@lists.alioth.debian.org
Uploaders: Joachim Breitner nome...@debian.org,
Erik de Castro Lopo er...@mega-nerd.com
-DM-Upload-Allowed: yes
Standards-Version: 3.9.4
Build-Depends:
debhelper (= 9),
@@ -13,15 +12,16 @@ Build-Depends:
ghc,
grep-dctrl,
dh-autoreconf,
- gcc (= 4:4.2),
- llvm-3.0 [armel armhf],
+ gcc,
+ llvm [armel armhf],
libffi-dev,
pkg-config,
xsltproc,
docbook-xsl,
docbook-xml,
- binutils (= 2.19.51.20090508) [arm armel],
- libncurses5-dev
+ binutils [armel armhf],
+ libncurses5-dev,
+ dpkg-dev (= 1.16.1.1)
Build-Depends-Indep:
hscolour,
fop
@@ -33,12 +33,12 @@ Vcs-Browser: http://darcs.debian.org/cgi-bin/darcsweb.cgi?r=pkg-haskell/ghc
Package: ghc
Architecture: any
-Depends: gcc (= 4:4.2), llvm-3.0 [armel armhf], libgmp-dev, libffi-dev, libbsd-dev, libc6-dev, ${shlibs:Depends}, ${misc:Depends}
+Depends: gcc, llvm [armel armhf], libgmp-dev, libffi-dev, libbsd-dev, libc6-dev, ${shlibs:Depends}, ${misc:Depends}
Provides: haskell-compiler, ${provided-devs}, ${haskell:Provides}, ${ghci}
Replaces: ghc6 ( 7)
Conflicts: ghc6 ( 7), ${provided-devs}
Breaks: cabal-install ( 0.8.0), haskell-devscripts ( 0.8.13), ghc-doc (= 6.12.1-8)
-Suggests: perl, ghc-prof, ghc-doc, haskell-doc, llvm-3.0
+Suggests: perl, ghc-prof, ghc-doc, haskell-doc, llvm
Description: The Glasgow Haskell Compilation system
The Glorious Glasgow Haskell Compilation system (GHC) is a compiler for
Haskell.
diff --git a/rules b/rules
index 6d480ea..1cb63ec 100755
--- a/rules
+++ b/rules
@@ -8,6 +8,11 @@
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
+# Set default flags with dpkg-buildflags
+# This might also close #712228
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+DPKG_EXPORT_BUILDFLAGS = 1
+include /usr/share/dpkg/buildflags.mk
# Set a dummy HOME variable upon build. Some build daemons do not set HOME, but
# ghc-cabal expects it to be available.
@@ -101,8 +106,8 @@ endif
./configure $(confflags) --prefix=/usr \
$(EXTRA_CONFIGURE_FLAGS) \
--with-ld=ld.bfd \
- --with-llc=llc-3.0 \
- --with-opt=opt-3.0
+ --with-llc=llc \
+ --with-opt=opt
touch $@
--
Bug#650601: (no subject)
Hi Developers and release team. Since libpng 1.5.11 is vulnerable to CVE-2012-3386 [1], fixed in 1.5.12 and 1.6.3, and that this transition hadn't hit wheezy, I would like to suggest you to change the transition directly to 1.6.3 instead of 1.5. [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3386 Gianfranco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650601: (no subject)
Hi Julien, thanks for the fast answer, I updated libpng, the package should be less broken than the previous one. It is available in mentors, experimental suite. Feel free to upload it. I know it is still preliminar, but can be a good place for starting the transition http://mentors.debian.net/package/libpng I'll address some of the lintian warnings later, if needed. thanks Gianfranco - Messaggio originale - Da: Julien Cristau jcris...@debian.org A: Gianfranco Costamagna costamagnagianfra...@yahoo.it; 650...@bugs.debian.org Cc: Inviato: Sabato 3 Agosto 2013 18:00 Oggetto: Re: Bug#650601: (no subject) On Sat, Aug 3, 2013 at 13:51:58 +0100, Gianfranco Costamagna wrote: Hi Developers and release team. Since libpng 1.5.11 is vulnerable to CVE-2012-3386 [1], fixed in 1.5.12 and 1.6.3, and that this transition hadn't hit wheezy, I would like to suggest you to change the transition directly to 1.6.3 instead of 1.5. Not our call. Somebody needs to get a not-completely-broken newer libpng package in to experimental, then we can talk. Cheers, Julien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718982: docbook2x cannot be installed anymore
Package: docbook2x Version: 0.8.8-8 Severity: serious Dear Maintainer, please consider upload of my package available on mentors [1], because now docbook2x cannot be installed on sid anymore. I cannot build/rebuild anymore packages I maintain in debian. I can adopt the package. Gianfranco [1] http://mentors.debian.net/package/docbook2x
Bug#718982: (no subject)
From the log [snip] Setting up libxml-parser-perl (2.41-1+b1) ... Setting up libxml-sax-expat-perl (0.40-2) ... update-perl-sax-parsers: Registering Perl SAX parser XML::SAX::Expat with priority 50... update-perl-sax-parsers: Updating overall Perl SAX parser modules info file... Replacing config file /etc/perl/XML/SAX/ParserDetails.ini with new version Processing triggers for sgml-base ... Setting up docbook2x (0.8.8-8) ... /var/lib/dpkg/info/docbook2x.postinst: 10: /var/lib/dpkg/info/docbook2x.postinst: install-info: not found dpkg: error processing docbook2x (--configure): subprocess installed post-installation script returned error exit status 127 Processing triggers for libc-bin ... Processing triggers for ca-certificates ... Updating certificates in /etc/ssl/certs... 157 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.ddone. Errors were encountered while processing: docbook2x E: Sub-process /usr/bin/dpkg returned an error code (1) Gianfranco
Bug#660682: (no subject)
I have prepared a new version on mentors [1] I think I can take care of this program. [1] http://mentors.debian.net/package/docbook2x Thanks Gianfranco
Bug#718982: docbook2x cannot be installed anymore
Hi Daniel thanks for the fast and prompt answer. Unfortunately I deleted the package because I wanted to upload a NMU version, and for some reason the package didn't get published anymore on mentors. I also tried to dcut the old package but also dcut file is still there. Tomorrow morning I'll try to bump the version and upload again, hoping some script will clean up things at some points. I never had this kind of issues on mentors, and I uploaded already a lot of packages. Otherwise I think you can grab the debian directory from mentors and rebuild it if needed I still see files on the ftp site ftp://mentors.debian.net/ Unless I cannot figure out what's wrong with mentors today, I'll publish on github or wherever you think is more appropriate! Thanks for your time Gianfranco Sent from Yahoo! Mail on Android
Bug#718982: docbook2x cannot be installed anymore
I made my changes available here https://github.com/LocutusOfBorg/docbook2x Mentors seems to be still stuck on some packages, seems to be a general problem. Could you please take it from here? this is particularly the commit I'm referring to https://github.com/LocutusOfBorg/docbook2x/commit/bd2579ba06e759ae594a9f510e26abf427152726 many thanks Gianfranco Da: Daniel Leidert daniel.leid...@wgdd.de A: Gianfranco Costamagna costamagnagianfra...@yahoo.it; 718...@bugs.debian.org Inviato: Giovedì 8 Agosto 2013 20:10 Oggetto: Re: Bug#718982: docbook2x cannot be installed anymore Am Mittwoch, den 07.08.2013, 13:40 +0100 schrieb Gianfranco Costamagna: Package: docbook2x Version: 0.8.8-8 Severity: serious Dear Maintainer, please consider upload of my package available on mentors [1], because now docbook2x cannot be installed on sid anymore. I cannot build/rebuild anymore packages I maintain in debian. There is no docbook2x package on mentors.d.n. I can adopt the package. Please go ahead. It is up for adoption. Regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718982: docbook2x cannot be installed anymore
Ok for some other obscure reasons now mentors works again https://mentors.debian.net/package/docbook2x - Messaggio originale - Da: Daniel Leidert daniel.leid...@wgdd.de A: Gianfranco Costamagna costamagnagianfra...@yahoo.it; 718...@bugs.debian.org Cc: Inviato: Venerdì 9 Agosto 2013 11:44 Oggetto: Re: Bug#718982: docbook2x cannot be installed anymore Am Freitag, den 09.08.2013, 08:51 +0100 schrieb Gianfranco Costamagna: I made my changes available here https://github.com/LocutusOfBorg/docbook2x Got it from there. Here are my comments: - If you add yourself to Uploaders, you don't need an NMU version number. Yeah, I noticed when I uploaded on mentors, I forgot it - I'd appreciate if you drop cdbs over debhelper (or do you prefer cdbs?). I don't have an opinion, but I would like to switch to debhelper too, unfortunately I don't know how to do it, do you have any sort of guide? - When changing to a debhelper rules file, I recommend to add autotools-dev ( 20100122.1~) and call its addon (hardening should be automatically enabled with dh 9). Even if you stay with cdbs update the config.* files. Already done, it was another lintian warning ;) - About the VCS. For some reason, the alioth SCM browser is broken for debian-xml-sgml (still points to CVS). However, the Vcs-Svn is svn://anonscm.debian.org/debian-xml-sgml/packages/docbook2x/trunk/ now. However, you are free to change to git if you want to adopt the package (open bug http://bugs.debian.org/660682). In this case you should close the RFA bug too. changed, and I'm already closing this bug, I'll commit on svn after the upload if possible - There are some more bug reports which you might to target, e.g. #516165, #597454, #631078 ... Since this bug is pretty serious (at least to me) I'm planning to fix bugs in a future upload, if possible Regards, Daniel Thanks for your time, Gianfranco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718651: (no subject)
Hi On Saturday 03 August 2013, Ritesh Raj Sarraf wrote: Package: wpasupplicant Version: 1.0-3+b2 Severity: normal Are there plans to package the 2.0 version of this package? Probably 2.1, unlikely 2.0 at this state. Regards Hi wpa devs, FYI wpa 2.0 is available on mentors [1], closing something like 10 bugs. Feel free to upload/review it! thanks Gianfranco [1] http://mentors.debian.net/package/wpa -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712978: tomcat7: New tomcat 7.0.41 is available
Package: tomcat7 Version: 7.0.40-2 Severity: wishlist Dear Maintainer, I write here because a new tomcat7 is available for download. I have already imported it here [1] and built correctly. Thanks for your attention [1] http://anonscm.debian.org/gitweb/?p=pkg-java/tomcat7.git;a=summary Gianfranco
Bug#577089: (no subject)
Hi jkl345, your bug report seems to be really old, many new versions have been released since you opened it, could you please try again with the latest 0.9.18 or the development 0.9.19? Thanks
Bug#664505: (no subject)
Hi deux, your bug is a little bit outdated, a new release is out now (0.9.18) and another one is going to be release in the next few days, could you please try again to reproduce your problem? Thanks
Bug#664505: (no subject)
Hi deux, your bug is a little bit outdated, a new release is out now (0.9.18) and another one is going to be release in the next few days, could you please try again to reproduce your problem? Thanks
Bug#521685: (no subject)
Hi Eugene, I don't know if this bug has been fixed and where to find the hedgewars documentation... I don't think I ever seen a manpage, where are you suggesting to put this? Maybe upstream can put a help page in the program?
Bug#585466: (no subject)
Hi Jocelyn, this bug is almost two major releases old, do you know if the bug persists in the latest version? Thanks
Bug#714347: py-sendfile: New upstream release available
Package: py-sendfile Version: 1.2.4-1 Severity: wishlist Dear Maintainer, A new sendfile release 2.0 is available on [1] I'm pretty sure packaging this release can fix bug #608287 too. Please consider upgrading it. Thanks. BTW I have already packaged it and uploaded to [2] it may need further tweaks. [1] http://code.google.com/p/pysendfile/downloads/list [2] http://mentors.debian.net/package/py-sendfile Gianfranco
Bug#702741: boinc-dbg: debian/control Suggests: libssl0.9.8-dbg - Change to libssl1.0.0-dbg
I honestly don't know how to deal with this problem, the line in control file is this one Suggests: libcurl3-dbg, libssl0.9.8-dbg, libwxgtk2.8-dbg should I change libssl0.9.8-dbg to libssl1.0.0-dbg | libssl0.9.8-dbg Or maybe just updating to 1.0.0 with not so many problems? I'm pretty sure no backports will be issued for debian 6.0 anymore Gianfranco Da: mdt m...@cryptolab.net A: Debian Bug Tracking System sub...@bugs.debian.org Inviato: Domenica 10 Marzo 2013 23:32 Oggetto: Bug#702741: boinc-dbg: debian/control Suggests: libssl0.9.8-dbg - Change to libssl1.0.0-dbg Package: boinc-dbg Version: 7.0.27+dfsg-5 Severity: important user@debian:~$ sudo apt-get install libssl0.9.8-dbg Reading package lists... Done Building dependency tree Reading state information... Done Package libssl0.9.8-dbg is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'libssl0.9.8-dbg' has no installation candidate -- System Information: Debian Release: 7.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages boinc-dbg depends on: ii boinc-client 7.0.27+dfsg-5 ii boinc-manager 7.0.27+dfsg-5 boinc-dbg recommends no packages. Versions of packages boinc-dbg suggests: ii libcurl3-dbg 7.26.0-1+wheezy1 pn libssl0.9.8-dbg none ii libwxgtk2.8-dbg 2.8.12.1-12 -- no debconf information -- pkg-boinc-devel mailing list pkg-boinc-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-boinc-devel
Bug#679207: boincmgr segfault when setting proxy
I admit your patch seems really good to me but I have to prior test it, I'll give a try in the next few hours and commit in debian master if everything goes well. Thanks for pointing this out to us, unfortunately upstream seems to don't care so much about this kind of bugs even if they can be considered showstopper. ATM they are porting to wx 3.0 so this bug should be fixed automatically after the port is completed. Anyway your patch will (hopefully) allow us to push in the near future a new version in unstable. I will directly ping upstream if the patch is good to speed up the release process. Many thanks for your help. Gianfranco
Bug#521746: (no subject)
Could anybody please explain why this bug is still open? could anybody upload the fix, or close this bug? thanks Gianfranco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521746: (no subject)
sorry but I don't see any ia32-libs on control file... http://sources.debian.net/src/eagle/6.4.0-2/debian/control is this because you don't build amd64 anymore? seems good to me. thanks Gianfranco - Messaggio originale - Da: Scott Howard showard...@gmail.com A: Gianfranco Costamagna costamagnagianfra...@yahoo.it; Debian Bug Tracking System 521...@bugs.debian.org; cont...@bugs.debian.org Cc: Inviato: Sabato 6 Luglio 2013 13:17 Oggetto: Re: Bug#521746: (no subject) fixed 521746 5.6.0-4 thanks On Sat, Jul 6, 2013 at 5:59 AM, Gianfranco Costamagna costamagnagianfra...@yahoo.it wrote: Could anybody please explain why this bug is still open? could anybody upload the fix, or close this bug? I'll add the tag for the versions it was fixed in. Thanks for pointing out that the bug wasn't tagged after it was closed in the BTS back in 2009. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717337: ITP: skype4py
Package: wnpp Severity: wishlist Owner: Gianfranco Costamagna costamagnagianfra...@yahoo.it * Package name : skype4py Version : 1.0.35 Upstream Original Author: Arkadiusz Wahlig y...@nokix.pasjagsm.pl Maintainer: Mikko Ohtamaa http://opensourcehacker.com * URL : https://github.com/awahlig/skype4py Skype4py has been removed because of no upstream support. Now seems to be new upstream authors are taking care of it http://packages.qa.debian.org/s/skype4py.html Please consider reinclusion again -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727691: (no subject)
Package: check Version: 0.9.10-5 Hi developers, maybe do you have a rationale for this, but in ettercap we have recently enabled tests, and we link our tests with libcheck.so file. In debian seems to be this file is deleted upon build, as shown in rules file rm -f debian/check/usr/lib/$(DEB_HOST_MULTIARCH)/libcheck.so.* rm -f debian/check/usr/lib/$(DEB_HOST_MULTIARCH)/libcheck.so rm -f debian/check/usr/lib/$(DEB_HOST_MULTIARCH)/libcheck.la How can we link it if you delete it when building? At this moment we are using an embedded libcheck copy, but this solution isn't the best one. Thanks, Gianfranco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727691: (no subject)
Control: retitle -1 check framework library is missing the so files -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727691: (no subject)
Il Lunedì 28 Ottobre 2013 14:16, Robert Lemmen rober...@semistable.com ha scritto: hi gianfranco, there is indeed some reasoning behind this: the ABI (and even API) of libcheck isn't particularily stable, arguably it wouldn't even be desirable for a library like this to have a stable interface: the cost of making it harder to change outweghts the benefits. because of this, libcheck is shipped as a *static only* library, which means you can still link against it and don't have to include libcheck *code* in your project. the static library is called liobcheck.a, and a typical linker invocation involves -static to tell the linker about the fact that you want to link statically. Thanks, I tried, but I'm still having linking problems. (I don't know why travis-ci succeedes, while I have problems on my computer please also note that it is not the target usecase to ever *ship* anything linked against libcheck, which is the usual reason for wanting to link against a .so. Sorry I didn't undestand this part, the pourpose of check is to include tests on a particular software right? what we do is: - build ettercap, - build tests (linked against check) - run tests. so check is not linked against ettercap, but only against test code, and it isn't shipped with any installer, is just for running testsuites. Do you have any better way for running tests on ettercap project? thanks for your answers! G. regards robert On Fri, Oct 25, 2013 at 02:10:06PM +0100, Gianfranco Costamagna wrote: Hi developers, maybe do you have a rationale for this, but in ettercap we have recently enabled tests, and we link our tests with libcheck.so file. In debian seems to be this file is deleted upon build, as shown in rules file rm -f debian/check/usr/lib/$(DEB_HOST_MULTIARCH)/libcheck.so.* rm -f debian/check/usr/lib/$(DEB_HOST_MULTIARCH)/libcheck.so rm -f debian/check/usr/lib/$(DEB_HOST_MULTIARCH)/libcheck.la How can we link it if you delete it when building? At this moment we are using an embedded libcheck copy, but this solution isn't the best one. -- Robert Lemmen http://www.semistable.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727691: (no subject)
Il Martedì 29 Ottobre 2013 10:23, Robert Lemmen rober...@semistable.com ha scritto: On Tue, Oct 29, 2013 at 08:50:05AM +, Gianfranco Costamagna wrote: because of this, libcheck is shipped as a *static only* library, which means you can still link against it and don't have to include libcheck *code* in your project. the static library is called liobcheck.a, and a typical linker invocation involves -static to tell the linker about the fact that you want to link statically. Thanks, I tried, but I'm still having linking problems. (I don't know why travis-ci succeedes, while I have problems on my computer hmm, can you tell me in detail what you are doing (i.e. linker invocation) and what error message you are getting? Ok I found and fixed the problem. The problem was that (seems to be a fault in debian/check build), check wasn't linked against pthread, math and time. this commit fixed the problem https://github.com/LocutusOfBorg/ettercap/commit/a8d67aa64ecea865971105fff1256de7ecf749cc I had some of this kind of problem with the switch from eglibc 2.15 to eglibc 2.17, I had to add manually some pthread or math somewhere in the makefiles on various debian programs, because the libraries weren't automatically linked (I never looked deeply at this kind of issues). can this be fixed on check side? Sorry I didn't undestand this part, the pourpose of check is to include tests on a particular software right? what we do is: - build ettercap, - build tests (linked against check) - run tests. so check is not linked against ettercap, but only against test code, and it isn't shipped with any installer, is just for running testsuites. Do you have any better way for running tests on ettercap project? no better suggestions, what you do sounds absolutely right. I just said that because a typical reason for people wanting a .so instead of a static lib si that they want to ship the test binary and are concerned about the size of it. and that's just not what unit tests are for... Well, thanks for the explanation! regards robert -- Robert Lemmen http://www.semistable.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684828: (no subject)
Sorry why this bug is still open? uglifyjs reached testing months ago, I think this bug can be closed, in order to allow backbone reach testing bests, Gianfranco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730332: (no subject)
Hi, I see the problem, anyway I don't know how to properly fix it.
I see in the boinc-manager dependencies only listed
Depends: ${shlibs:Depends}, ${misc:Depends}
IIRC misc:Depends puts libboinc7 into manager dependencies, and according to
clientgui/Makefile.am it is linked to the mananger
boincmgr_LDFLAGS = $(LIBBOINC) $(SQLITE3_LIBS) $(LIBNOTIFY_LIBS)
$(CLIENTGUILIBS) $(BOINC_EXTRA_LIBS) $(CLIENTLIBS) `pkg-config --libs gtk+-2.0`
-lno
So in order to avoid this link you first need to remove libboinc from the boinc
manager.
This is an upstream issue, not a debian one, can you report upstream?
objdump -p `which boincmgr`
NEEDED libboinc.so.7
G.
Bug#730332: (no subject)
e.g. MIOFILE is defined in boinclib and used in clientgui/browser.cpp Sent from Yahoo Mail on Android
Bug#730332: (no subject)
/boinc/clientgui/WizardAttach.h:190: undefined reference to
`ACCOUNT_OUT::~ACCOUNT_OUT()'
/boinc/clientgui/WizardAttach.h:190: undefined reference to
`ACCOUNT_IN::~ACCOUNT_IN()'
/boinc/clientgui/WizardAttach.h:190: undefined reference to
`PROJECT_CONFIG::~PROJECT_CONFIG()'
/boinc/clientgui/WizardAttach.h:190: undefined reference to
`PROJECT_CONFIG::~PROJECT_CONFIG()'
/boinc/clientgui/WizardAttach.h:190: undefined reference to
`ACCOUNT_IN::~ACCOUNT_IN()'
Also this is needed for manager.
For me is won't fix, unless upstream wants to provide two different libraries
or something else.
Unfortunately is too big for a downstream patch.
Bests,
Gianfranco
Il Mercoledì 27 Novembre 2013 16:03, Gianfranco Costamagna
costamagnagianfra...@yahoo.it ha scritto:
e.g. MIOFILE is defined in boinclib and used in clientgui/browser.cpp
Sent from Yahoo Mail on Android
From: Gianfranco Costamagna costamagnagianfra...@yahoo.it;
To: 730...@bugs.debian.org 730...@bugs.debian.org;
Subject: Bug#730332: (no subject)
Sent: Wed, Nov 27, 2013 2:11:01 PM
Hi, I see the problem, anyway I don't know how to properly fix it.
I see in the boinc-manager dependencies only listed
Depends: ${shlibs:Depends}, ${misc:Depends}
IIRC misc:Depends puts libboinc7 into manager dependencies, and according to
clientgui/Makefile.am it is linked to the mananger
boincmgr_LDFLAGS = $(LIBBOINC) $(SQLITE3_LIBS) $(LIBNOTIFY_LIBS)
$(CLIENTGUILIBS) $(BOINC_EXTRA_LIBS) $(CLIENTLIBS) `pkg-config --libs
gtk+-2.0` -lno
So in order to avoid this link you first need to remove libboinc from the
boinc manager.
This is an upstream issue, not a debian one, can you report upstream?
objdump -p `which boincmgr`
NEEDED libboinc.so.7
G.
--
pkg-boinc-devel mailing list
pkg-boinc-de...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-boinc-devel
Bug#730841: boinc-nvidia-cuda: please Recommend libcuda1-i386 [amd64]
Hi Andreas and all, Package: boinc-nvidia-cuda Version: 7.2.33+dfsg-1 Severity: normal Hi, I have a small gift for you: libcuda1-i386:i386. That's a real package that can be recommended from boinc-nvidia-cuda:amd64 and it will care for the installation of libcuda1:i386 (if foreign architecture i386 is enabled on amd64). Provides and multiarch foreign don't work together, so this is the working solution for cross-arch Recommends for now. I would suggest the following control.in change: -@Recommends: libcuda1-ia32 [amd64]|nvidia-current [amd64]|libcuda-5.0-1 [amd64], ia32-libs [amd64]|nvidia-current [amd64]|libcuda-5.0-1 [amd64] +@Recommends: libcuda1-i386 [amd64]|nvidia-current [amd64], ia32-libs [amd64]|nvidia-current [amd64]|libcuda-5.0-1 [amd64] libcuda1-ia32 is gone long ago ... the libcuda-5.0-1 alternative needs to be removed, otherwise the Recomends is already satisfied by libcuda1:amd64. I'm not sure what you want to achieve with the ia32-libs Recommends, but this does not work anyway since libcuda-5.0-1 is already satisfied by libcuda1:amd64. I think I fixed it in commit http://anonscm.debian.org/gitweb/?p=pkg-boinc/boinc.git;a=commitdiff;h=26346c083bb655f7620f308ef0e5b393dacb520d can you please review it? I think I followed your suggestions, but I'm not completely sure. Bests and thanks for your report/gift!, Gianfranco Andreas PS: NVIDIA has declared CUDA on 32-bit x86 as deprecated, so this may disappear at some point in the future ... -- pkg-boinc-devel mailing list pkg-boinc-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-boinc-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730841: boinc-nvidia-cuda: please Recommend libcuda1-i386 [amd64]
Is it good in this way?
diff --git a/debian/control.in b/debian/control.in
index e1cb404..b20b9e1 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -62,8 +62,8 @@ Package: boinc
@Architecture: amd64 i386
@Section: contrib/net
@Priority: extra
-@Depends: ${misc:Depends}, boinc, libcuda1 | nvidia-current,
-@Recommends: libcuda1-i386 [amd64]|nvidia-current [amd64], nvidia-current
[amd64]
+@Depends: ${misc:Depends}, boinc, libcuda1 | libcuda-5.0-1 | nvidia-current,
+@Recommends: libcuda1-i386 [amd64] | libcuda-5.0-1-i386 [amd64] |
nvidia-current [amd64]
@Description: metapackage for CUDA-savvy BOINC client and manager
@ The Berkeley Open Infrastructure for Network Computing (BOINC) is a
@ software platform for distributed computing: several initiatives of
@@ -109,7 +109,7 @@ Package: boinc
@ ${python:Depends},
@ adduser,
@ ca-certificates
-@Suggests: boinc-manager, x11-xserver-utils, libcuda1, libcuda1-i386 [amd64]
+@Suggests: boinc-manager, x11-xserver-utils, libcuda1-i386 [amd64] |
libcuda-5.0-1-i386 [amd64]
@Description: core client for the BOINC distributed computing infrastructure
@ The Berkeley Open Infrastructure for Network Computing (BOINC) is a
@ software platform for distributed computing: several initiatives of
(Sorry but I don't know too much about cuda and this delta from ubuntu, it is
messing up everything)
Gianfranco
Il Lunedì 2 Dicembre 2013 13:23, Andreas Beckmann a...@debian.org ha
scritto:
On 2013-12-02 12:14, Gianfranco Costamagna wrote:
I think I fixed it in commit
http://anonscm.debian.org/gitweb/?p=pkg-boinc/boinc.git;a=commitdiff;h=26346c083bb655f7620f308ef0e5b393dacb520d
can you please review it?
I think I followed your suggestions, but I'm not completely sure.
You need to keep libcuda-5.0-1 as alternative to libcuda1, thats a
virtual package provided by Ubuntu which does not have libcuda1. Maybe
put it in front of nvidia-current (and maybe drop nvidia-current
alltogether):
Depends: ..., libcuda1 | libcuda-5.0-1 | nvidia-current
Recommends: libcuda1-i386 [amd64]|nvidia-current [amd64]
Hmm, maybe Ubuntu should provide something like libcuda-5.0-1-i386 as
well. I'll add this myself to libvdpau1 and suggest this to Graham. So
start right now with
Recommends: libcuda1-i386 [amd64] | libcuda-5.0-1-i386 [amd64] |
nvidia-current [amd64]
and
Suggests: ..., libcuda1-i386 [amd64] | libcuda-5.0-1-i386 [amd64]
Andreas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706759: debian-maintainers: Please add Gianfranco Costamagna as a DM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: debian-maintainers Severity: normal Hello, Please add me (Gianfranco Costamagna) as a Debian Maintainer. Attached is the jetring changeset. Thanks, Gianfranco -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRhPjrAAoJEItu8lKPB14dy0AIAJ3xaFih6H3hDa++xktWka5w UkB/rIfEukUZBYPrMucIHud2/fV+SzjgBOOzYI2YW/rgvdCoK5yq0dGiNnx8iV76 FvWsYLwJ2QHJC1NlnD2BgqLWUnxO74eCJWxXBynftwuWV/WjB/gp2lU0sEgHHLl9 u/u5ynPhU6QIakEi8/+M8TRnc8RME3CYzX2RxrQye2BIsqweSoSi0p3kkryoY0Cn D3I905F/wFHJO9H57DarmQuftDUm9i6jiYYM5wELIv4idhvm7KiE/0ffFg1lklI5 1YyuxHBd/SizmypiTpT54zvbvhInj1pGk1eFB5lHKIXwuDONZQxKE6jXEm+cIdM= =AfEj -END PGP SIGNATURE- message Description: Binary data -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: debian-maintainers Severity: normal Hello, Please add me (Gianfranco Costamagna) as a Debian Maintainer. Attached is the jetring changeset. Thanks, Gianfranco -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRhPjrAAoJEItu8lKPB14dy0AIAJ3xaFih6H3hDa++xktWka5w UkB/rIfEukUZBYPrMucIHud2/fV+SzjgBOOzYI2YW/rgvdCoK5yq0dGiNnx8iV76 FvWsYLwJ2QHJC1NlnD2BgqLWUnxO74eCJWxXBynftwuWV/WjB/gp2lU0sEgHHLl9 u/u5ynPhU6QIakEi8/+M8TRnc8RME3CYzX2RxrQye2BIsqweSoSi0p3kkryoY0Cn D3I905F/wFHJO9H57DarmQuftDUm9i6jiYYM5wELIv4idhvm7KiE/0ffFg1lklI5 1YyuxHBd/SizmypiTpT54zvbvhInj1pGk1eFB5lHKIXwuDONZQxKE6jXEm+cIdM= =AfEj -END PGP SIGNATURE-
Bug#706759: (no subject)
add-8B6EF2528F075E1D Description: Binary data
Bug#701380: (no subject)
This bug have been fixed between 7.0.36 and 7.0.38. You can see both changelogs (on ubuntu raring, not the same configuration but the same changelog) https://launchpadlibrarian.net/121599012/buildlog_ubuntu-raring-amd64.boinc_7.0.36%2Bdfsg-3_FAILEDTOBUILD.txt.gz https://launchpadlibrarian.net/121666774/buildlog_ubuntu-raring-amd64.boinc_7.0.36%2Bdfsg-4~raring1_BUILDING.txt.gz
Bug#720849: boinc-manager: Can't connect to boinc-client due to empty password in gui_rpc_auth.cfg
Also passing --dir /etc/boinc-client to boincmgr should do the trick Gianfranco - Messaggio originale - Da: MestreLion launch...@rodrigosilva.com A: Julien Palard jul...@palard.fr; 720...@bugs.debian.org Cc: Inviato: Domenica 25 Agosto 2013 21:28 Oggetto: Bug#720849: boinc-manager: Can't connect to boinc-client due to empty password in gui_rpc_auth.cfg At 12:59 25/08/2013, you wrote: Package: boinc-manager Version: 7.2.7+dfsg-1 Severity: important While installing boinc-manager, the file /etc/boinc-client/gui_rpc_auth.cfg is created empty. While starting boinc-manager without parameters, it gives Retrieving current status and then Unable to connect to the core client. This message does not help the user to understand that the problem is that he didn't gave a password in /etc/boinc-client/gui_rpc_auth.cfg and that this password should be given to boincmgr using the -p argument. /etc/boinc-client/gui_rpc_auth.cfg is created empty because authorization is not required for local access (ie, managing a boinc client running in localhost). It is only required for remote access (ie, someone else accessing your boinc client). And remote access is also disabled by default. So most likely your issue is not related to gui_rpc_auth.cfg, unless you're trying to acesss your boinc client from another computer. I suspect it can be the current directoy: boincmgr must run from the boinc data directory (/var/lib/boinc-client) so it can find the all config and state files of current boinc instance. Also, The -p option is available via GUI: In Advanced view, go to Advanced - Select Computer, where you can provide hostname and password of the boinc instance you're trying to access. And I think the fact that user have to put a password in gui_rpc_auth.cfg, the format used by the file, etc should be documented (I searched and didn't find any documentation about this, if it's actually documented, documentation is too hard to find for a normal user). You only have to put a password if you're trying remote access. As for documentation, the very first google hit for boinc remote access leads to: http://boinc.berkeley.edu/wiki/Controlling_BOINC_remotely And for gui_rpc_auth.cfg leads to: http://boinc.berkeley.edu/trac/wiki/RpcAuth `man boinccmd` also briefly mentions gui_rpc_auth.cfg and its role, and `man boinc` suggests http://boinc.berkeley.edu/wiki/Client_configuration which has related info. ML -- pkg-boinc-devel mailing list pkg-boinc-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-boinc-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721298: boinc-client: Idle Detection Not Working Computer Always In Use
Hi Preston, could you please try this global_prefs_override.xml file? global_preferences run_on_batteries0/run_on_batteries run_if_user_active1/run_if_user_active run_gpu_if_user_active1/run_gpu_if_user_active suspend_cpu_usage0.00/suspend_cpu_usage start_hour0.00/start_hour end_hour0.00/end_hour net_start_hour0.00/net_start_hour net_end_hour0.00/net_end_hour leave_apps_in_memory1/leave_apps_in_memory confirm_before_connecting0/confirm_before_connecting hangup_if_dialed0/hangup_if_dialed dont_verify_images0/dont_verify_images work_buf_min_days1.00/work_buf_min_days work_buf_additional_days10.00/work_buf_additional_days max_ncpus_pct100.00/max_ncpus_pct cpu_scheduling_period_minutes60.00/cpu_scheduling_period_minutes disk_interval60.00/disk_interval disk_max_used_gb100.00/disk_max_used_gb disk_max_used_pct95.00/disk_max_used_pct disk_min_free_gb0.00/disk_min_free_gb vm_max_used_pct75.00/vm_max_used_pct ram_max_used_busy_pct50.00/ram_max_used_busy_pct ram_max_used_idle_pct90.00/ram_max_used_idle_pct max_bytes_sec_up0.00/max_bytes_sec_up max_bytes_sec_down0.00/max_bytes_sec_down cpu_usage_limit100.00/cpu_usage_limit daily_xfer_limit_mb0.00/daily_xfer_limit_mb daily_xfer_period_days0/daily_xfer_period_days /global_preferences I see a couple of difference that may cause this issue, if it isn't a code problem. thanks Gianfranco - Messaggio originale - Da: Preston Maness aggroska...@gmail.com A: Debian Bug Tracking System sub...@bugs.debian.org Cc: Inviato: Venerdì 30 Agosto 2013 5:32 Oggetto: Bug#721298: boinc-client: Idle Detection Not Working Computer Always In Use Package: boinc-client Version: 7.2.7+dfsg-1 Severity: important Dear Maintainer, I am unable to get BOINC to activate when computer is not in use. I don't know how else to troubleshoot the idle detection features of boinc. The log file at /var/lib/boinc-client/stdoutdae.txt simply shows a line that says Suspending Computation - computer is in use even after the idle time has been reached. The XML with the global configuration parameters is below. Telling boinc to run always seems to work as expected. The CPU and GPU both get jobs at that point and start crunching away. Please advise me as to how I may help in further troubleshooting this issue. Cheers, Preston Maness -- Package-specific info: -- Contents of /etc/default/boinc-client: # This file is /etc/default/boinc-client, it is a configuration file for the # /etc/init.d/boinc-client init script. # Set this to 1 to enable and to 0 to disable the init script. ENABLED=1 # Set this to 1 to enable advanced scheduling of the BOINC core client and # all its sub-processes (reduces the impact of BOINC on the system's # performance). SCHEDULE=1 # The BOINC core client will be started with the permissions of this user. BOINC_USER=boinc # This is the data directory of the BOINC core client. BOINC_DIR=/var/lib/boinc-client # This is the location of the BOINC core client, that the init script uses. # If you do not want to use the client program provided by the boinc-client # package, you can specify here an alternative client program. #BOINC_CLIENT=/usr/local/bin/boinc BOINC_CLIENT=/usr/bin/boinc # Here you can specify additional options to pass to the BOINC core client. # Type 'boinc --help' or 'man boinc' for a full summary of allowed options. #BOINC_OPTS=--allow_remote_gui_rpc BOINC_OPTS= # Scheduling options # Set SCHEDULE=0 if prefering to run with upstream default priority # settings. # Nice levels. When systems are truly busy, e.g. because of too many active # scientific applications started by the boinc client, there is a chance for # the boinc client not to be granted sufficient opportunity to check for # scientific applications to be alive and make the (wrong) decision to # terminate the scientific app. This is particularly an issue with many # apps started in parallel on modern multi-core systems and extra overheads # for the download and uploads of files with the project servers. Another # concern is the latency for scientific applications to communicate with the # graphics card, which should be low. All such values should be set and # controled from within the BOINC client. The Debian init script also sets # extra constrains via chrt on real time performance and via ionice on # I/O performance, which is beyond the regular BOINC client. It then was # too easy to use that code to also constrain minimal nice levels. We still # think about how to best distinguish GPU applications from regular apps. BOINC_NICE_CLIENT=10 BOINC_NICE_APP_DEFAULT=19 #BOINC_NICE_APP_GPU=5 # not yet used # ionice classes. See manpage of ionice (1) in the util-linux package. BOINC_IONICE_CLIENT=3 # idle
Bug#721298: boinc-client: Idle Detection Not Working Computer Always In Use
- Messaggio originale - Da: Preston Maness aggroska...@gmail.com A: 721...@bugs.debian.org 721...@bugs.debian.org; costamagnagianfra...@yahoo.it Cc: Inviato: Sabato 31 Agosto 2013 4:32 Oggetto: Re: Bug#721298: boinc-client: Idle Detection Not Working Computer Always In Use -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, On 08/30/2013 05:59 AM, Gianfranco Costamagna wrote: Hi Preston, could you please try this global_prefs_override.xml file? I'm utilizing it now. I'm actually pretty impressed at how well the machine is still functioning even with all cores working on jobs. I can still browse the web, write this email, tail various logs, compiz effects still look nice, etc. When I tried to run everything like this before --Run CPU and GPU while in use, use 100 percent of resources-- the computer became unresponsive to everything except Ctrl-Alt-SysRq-REISUB. I'm guessing that the RAM limits are preventing that from happening, as well as some of the tweaks in the init script in the schedule() function. However, I don't see how this tests idle detection. Is the theory that the scheduling tweaks negate the need to detect idle time? So far, the machine is still doing pretty well. I haven't checked any GPU jobs to see if they're getting computation errors, but the CPU jobs all seem to be completing just fine. Ok sorry for the misunderstanding, my point was to try to enable idle detection starting from my xml file, nevermind, can you please try this one? computation should start after 20 seconds of inactivity or something like that thanks global_preferences run_on_batteries0/run_on_batteries run_if_user_active0/run_if_user_active run_gpu_if_user_active0/run_gpu_if_user_active idle_time_to_run0.20/idle_time_to_run suspend_cpu_usage0.00/suspend_cpu_usage start_hour0.00/start_hour end_hour0.00/end_hour net_start_hour0.00/net_start_hour net_end_hour0.00/net_end_hour leave_apps_in_memory1/leave_apps_in_memory confirm_before_connecting0/confirm_before_connecting hangup_if_dialed0/hangup_if_dialed dont_verify_images0/dont_verify_images work_buf_min_days1.00/work_buf_min_days work_buf_additional_days10.00/work_buf_additional_days max_ncpus_pct100.00/max_ncpus_pct cpu_scheduling_period_minutes60.00/cpu_scheduling_period_minutes disk_interval60.00/disk_interval disk_max_used_gb100.00/disk_max_used_gb disk_max_used_pct95.00/disk_max_used_pct disk_min_free_gb0.00/disk_min_free_gb vm_max_used_pct75.00/vm_max_used_pct ram_max_used_busy_pct50.00/ram_max_used_busy_pct ram_max_used_idle_pct90.00/ram_max_used_idle_pct max_bytes_sec_up0.00/max_bytes_sec_up max_bytes_sec_down0.00/max_bytes_sec_down cpu_usage_limit100.00/cpu_usage_limit daily_xfer_limit_mb0.00/daily_xfer_limit_mb daily_xfer_period_days0/daily_xfer_period_days /global_preferences Cheers, Preston Maness -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJSIVWdAAoJEM8h7WmSAmad4WAH/0OeubcvbimmstM5WlRiU9J6 noLq/lqL5MbdsqmD7vsA/sdax7GiXxkcz8x6WiQoyZkZcFQuNVWQWF8yymBxqAhi U8/kcBG69Kj/RHLKpBaOFpDOOHXj0WLpjKFai7CL/JrmpE93Gw8zeWPg4+wLCcjk xsqHOQguFbVKfQ3ujmNDnO0JnI+6bOmRnRXacRV8OhwVbH7Puf2zr0+9elfNohEf 0glJwcWeYwsyxxrczSIImBG4GSNamR7oFanem86eTLsVowMxTBN+bOhI5Ri60yCQ OOdVn5tGG8g3Luk5yjDVB00UqYfiAVap/fnS/BL/+b6JeMu4SQ1BXoq/xdjonJY= =ilBE -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657499: (no subject)
I would like to contribute in pootle packaging if needed. Now Translate Toolkit is in unstable. Gianfranco
Bug#729759: New flex available on mentors
Hi Manoj and Guillem, I have packaged (since I didn't receive answers so far) the new flex release, that closes 3 or maybe more bugs. I made it available on mentors, I hope to have a feedback from you, since you are the maintainers and/or you have uploaded the last release. Also would be nice to merge the ubuntu multiarch work, but this I think is more than a NMU possibility, and moreover introduces a new package that needs to go to the new queue. What do you think about? Best regards, [1] https://mentors.debian.net/package/flex Gianfranco
Bug#712228: (no subject)
Hi Joachim and Thomas, this bug [1] seems to be really similar to that one https://ghc.haskell.org/trac/ghc/ticket/3668 maybe somewhere debian is overriding the GHC flags and pie is added? Bests, Gianfranco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733977: boinc-app-milkyway: Please sync with upstream
Hi Ken thanks for your report. Unfortunately I tried some time ago to package again milkyway with the new code hosted here [1] Code that I think is the official client one. Anyway I'm just stuck with some errors when I run the package with boinc, and I get only computation errors messages. I also asked two pull requests [2], to fix a build failure and a potential security issue. Nobody replied so far. What can I do? Fix everything without upstream support? I can, but I don't have time and man power for making the package stable without looking really deeply at the code. I'll try again with the last milkyway code, can you please try to have a better contact with upstream? thanks [1] https://github.com/Milkyway-at-home/milkywayathome_client [2] https://github.com/Milkyway-at-home/milkywayathome_client/pulls G. Il Giovedì 2 Gennaio 2014 20:48, Ken Sharp imwellcushtymel...@googlemail.com ha scritto: Package: boinc-app-milkyway Version: 0.18d-4 The current version supplied by boinc-app-milkyway appears to run fine on armel but: 1. The estimated runtime is always way off. 2. The results are always invalid. 3. It's a really old version: there will be many changes between 0.18 and the current upstream 1.x branch which will fix a lot of bugs. If there is anything further needed then please let me know. Origin: http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=3440#60666 -- pkg-boinc-devel mailing list pkg-boinc-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-boinc-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729158: ia64 not keeping up
Since ia64 isn't keeping up in debian I think this bug is the only blocker left for the testing migration Ivo, how do you think about closing it? thanks, Gianfranco
Bug#733618: Acknowledgement (Please backport patch for fpc, fixing sparc build failure)
tags 733618 patch Gianfranco Il Lunedì 30 Dicembre 2013 13:52, Gianfranco Costamagna costamagnagianfra...@yahoo.it ha scritto: Tags: patch I'm attaching the debdiff for your convenience. Thanks
Bug#734588: transition sdlgfx 2.0.23 to 2.0.25
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition (opening a bug, sorry for double posting) Hi debian release Managers! Together with Manuel (the sdlgfx uploader, who reads in cc), we decided to ask for a transition the package can be found here [1] and brings a really similar API, but the packages that build-deps from it will likely need a binNMU to build against the new ABI/API. We are most sure that mostly of them (if not all of them) will just need a rebuild. Unfortunately the package will go through the new queue (we can avoid that, as explained below), because of the change from libsdl-gfx1.2-4 to libsdl-gfx1.2-5. http://packages.qa.debian.org/s/sdlgfx.html # reverse-depends -b src:sdlgfx Reverse-Build-Depends-Indep === * libalien-sdl-perl (for libsdl-gfx1.2-dev) * taoframework (for libsdl-gfx1.2-dev) Reverse-Build-Depends = * angband (for libsdl-gfx1.2-dev) * balder2d (for libsdl-gfx1.2-dev) * ballerburg (for libsdl-gfx1.2-dev) * blocks-of-the-undead (for libsdl-gfx1.2-dev) * brainparty (for libsdl-gfx1.2-dev) * clanlib (for libsdl-gfx1.2-dev) * dd2 (for libsdl-gfx1.2-dev) * enigma (for libsdl-gfx1.2-dev) * freedink (for libsdl-gfx1.2-dev) * freedroidrpg (for libsdl-gfx1.2-dev) * freetennis (for libsdl-gfx1.2-dev) * freewheeling (for libsdl-gfx1.2-dev) * gambas3 (for libsdl-gfx1.2-dev) * haskell-sdl-gfx (for libsdl-gfx1.2-dev) * haskell-sdl-image (for libsdl-gfx1.2-dev) * hyperrogue (for libsdl-gfx1.2-dev) * infon (for libsdl-gfx1.2-dev) * iulib (for libsdl-gfx1.2-dev) * lincity-ng (for libsdl-gfx1.2-dev) * luola (for libsdl-gfx1.2-dev) * mana (for libsdl-gfx1.2-dev) * manaplus (for libsdl-gfx1.2-dev) * mousetrap (for libsdl-gfx1.2-dev) * ocamlsdl (for libsdl-gfx1.2-dev) * openssn (for libsdl-gfx1.2-dev) * qonk (for libsdl-gfx1.2-dev) * sitplus (for libsdl-gfx1.2-dev) * tome (for libsdl-gfx1.2-dev) * warmux (for libsdl-gfx1.2-dev) * widelands (for libsdl-gfx1.2-dev) thanks for your time, have a nice new year, Gianfranco [1] http://anonscm.debian.org/gitweb/?p=pkg-sdl/packages/sdlgfx.git Il Sabato 28 Dicembre 2013 13:49, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com ha scritto: 2013/12/22 Gianfranco Costamagna costamagnagianfra...@yahoo.it: Il Domenica 22 Dicembre 2013 0:19, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com ha scritto: 2013/12/21 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com: I can help of course, I'm trying to get more and more involved in debian (I'm a DM since some months now, but I started contributing more than one year ago in the debian alioth gits) I'll be glad to help, altough sometimes I still make mistakes (the .24 wasn't uploaded because the ABI/API changed and nobody bumped the soname... I pushed everything on alioth! OK, thanks, I will review it. So I reviewed it and pushed the changes, which is mostly to squash the changelog of .24 and .25 together and minor packaging changes which probably are not important (didn't remember to commit separately, sorry). Wonderful! That was in my plans, but I was too lazy to to it :) So is it OK to go for you, other than waiting for the transition? I think that the bump in SONAME will bring the following complications: - the binary .deb has a new name, thus has to go through the FTP master's NEW queue (and can take weeks/months) - all reverse-depends will have to be recompiled against the new version (probably binNMU is enough, but since there are ~30 or so I guess that some of them will fail to compile and complicate the transition) - I think that a transition should be opened with Release Managers, the number of packages is high enough I wonder if we can do something like the following to avoid at least the 1st step: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549110 http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=54;filename=sdlgfx-2.0.20-1.1-nmu.diff;att=1;bug=549110 For this part I don't know the best solution honestly... I tried the possible to avoid the new queue stall, but maybe since this is an API/ABI change is good to change everything and to have a package name coherent with the new sdl API/ABI. for the transition yes, I think we should open a transition and ask
Bug#734588: Acknowledgement (transition sdlgfx 2.0.23 to 2.0.25)
Sorry for don't adding the binnmu tag, but this package isn't uploaded yet. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733977: boinc-app-milkyway: Please sync with upstream
Hi Ken, I had more luck than you in my boinc-app-milkyway from github. I can run and validate successfully every milkyway_nbody task but I get a failure on milkybody_separation one. I don't have the nbody build now, I can give it to you tomorrow if you are intrested. Anyway for making it build: install boinc, boinc-app-dev, boinc-dev clone the repository git submodule init git submodule update delete the boinc folder (in this way we will use _our_ boinc libraries) apply the two pull requests https://github.com/Milkyway-at-home/milkywayathome_client/pulls (or just use the patches in debian directory) clone the debian directory from here http://anonscm.debian.org/gitweb/?p=pkg-boinc/boinc-app-milkyway.git dpkg-buildpackage should do the trick On monday I'll update the debian git repository, it won't work right now after you create the package (I'll change the debian/rules for building only the nbody) you will be able to run milkyway. As soon as I get more feedbacks, and if I don't figure out what is wrong with separation, I'll update milkyway using only nbody platform (and of course after I'm sure this is the right client to ship). EDIT: I see that maybe separation isn't just supported http://milkyway.cs.rpi.edu/milkyway/apps.php http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=3394 http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=3407 bests, G. Il Domenica 12 Gennaio 2014 9:27, Ken Sharp imwellcushtymel...@googlemail.com ha scritto: I'm not sure if the code you referenced is the correct code. According to the forums the original code didn't have a licence and the newer code hasn't been released yet, at least that's what I got from the reading the threads. There really is nothing made clear on the subject. I've asked for a little clarity but with no response so far: http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=576 I tried building the code from github but it can't find libraries, uses old libraries a bit of a nightmare. Probably isn't much point in using that code until someone officially tells us what is going on. On 03/01/14 00:28, Gianfranco Costamagna wrote: Hi Ken thanks for your report. Unfortunately I tried some time ago to package again milkyway with the new code hosted here [1] Code that I think is the official client one. Anyway I'm just stuck with some errors when I run the package with boinc, and I get only computation errors messages. I also asked two pull requests [2], to fix a build failure and a potential security issue. Nobody replied so far. What can I do? Fix everything without upstream support? I can, but I don't have time and man power for making the package stable without looking really deeply at the code. I'll try again with the last milkyway code, can you please try to have a better contact with upstream? thanks [1] https://github.com/Milkyway-at-home/milkywayathome_client [2] https://github.com/Milkyway-at-home/milkywayathome_client/pulls G. Il Giovedì 2 Gennaio 2014 20:48, Ken Sharp imwellcushtymel...@googlemail.com ha scritto: Package: boinc-app-milkyway Version: 0.18d-4 The current version supplied by boinc-app-milkyway appears to run fine on armel but: 1. The estimated runtime is always way off. 2. The results are always invalid. 3. It's a really old version: there will be many changes between 0.18 and the current upstream 1.x branch which will fix a lot of bugs. If there is anything further needed then please let me know. Origin: http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=3440#60666 -- pkg-boinc-devel mailing list pkg-boinc-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-boinc-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733977: boinc-app-milkyway: Please sync with upstream
Hi Ken, I merged and pushed on debian git my local changes. For separation I didn't succeed in making it work, so I disabled it (otherwise you won't get new work if you submit too many computation error units) in order to make it work clone the milkyway code https://github.com/Milkyway-at-home/milkywayathome_client clone the debian directory http://anonscm.debian.org/gitweb/?p=pkg-boinc/boinc-app-milkyway.git make a tarball of the source package ./debian/rules tarball dpkg-buildpackage install, enjoy! report here in case of troubles thanks G. Il Domenica 12 Gennaio 2014 10:39, Gianfranco Costamagna costamagnagianfra...@yahoo.it ha scritto: Hi Ken, I had more luck than you in my boinc-app-milkyway from github. I can run and validate successfully every milkyway_nbody task but I get a failure on milkybody_separation one. I don't have the nbody build now, I can give it to you tomorrow if you are intrested. Anyway for making it build: install boinc, boinc-app-dev, boinc-dev clone the repository git submodule init git submodule update delete the boinc folder (in this way we will use _our_ boinc libraries) apply the two pull requests https://github.com/Milkyway-at-home/milkywayathome_client/pulls (or just use the patches in debian directory) clone the debian directory from here http://anonscm.debian.org/gitweb/?p=pkg-boinc/boinc-app-milkyway.git dpkg-buildpackage should do the trick On monday I'll update the debian git repository, it won't work right now after you create the package (I'll change the debian/rules for building only the nbody) you will be able to run milkyway. As soon as I get more feedbacks, and if I don't figure out what is wrong with separation, I'll update milkyway using only nbody platform (and of course after I'm sure this is the right client to ship). EDIT: I see that maybe separation isn't just supported http://milkyway.cs.rpi.edu/milkyway/apps.php http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=3394 http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=3407 bests, G. Il Domenica 12 Gennaio 2014 9:27, Ken Sharp imwellcushtymel...@googlemail.com ha scritto: I'm not sure if the code you referenced is the correct code. According to the forums the original code didn't have a licence and the newer code hasn't been released yet, at least that's what I got from the reading the threads. There really is nothing made clear on the subject. I've asked for a little clarity but with no response so far: http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=576 I tried building the code from github but it can't find libraries, uses old libraries a bit of a nightmare. Probably isn't much point in using that code until someone officially tells us what is going on. On 03/01/14 00:28, Gianfranco Costamagna wrote: Hi Ken thanks for your report. Unfortunately I tried some time ago to package again milkyway with the new code hosted here [1] Code that I think is the official client one. Anyway I'm just stuck with some errors when I run the package with boinc, and I get only computation errors messages. I also asked two pull requests [2], to fix a build failure and a potential security issue. Nobody replied so far. What can I do? Fix everything without upstream support? I can, but I don't have time and man power for making the package stable without looking really deeply at the code. I'll try again with the last milkyway code, can you please try to have a better contact with upstream? thanks [1] https://github.com/Milkyway-at-home/milkywayathome_client [2] https://github.com/Milkyway-at-home/milkywayathome_client/pulls G. Il Giovedì 2 Gennaio 2014 20:48, Ken Sharp imwellcushtymel...@googlemail.com ha scritto: Package: boinc-app-milkyway Version: 0.18d-4 The current version supplied by boinc-app-milkyway appears to run fine on armel but: 1. The estimated runtime is always way off. 2. The results are always invalid. 3. It's a really old version: there will be many changes between 0.18 and the current upstream 1.x branch which will fix a lot of bugs. If there is anything further needed then please let me know. Origin: http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=3440#60666 -- pkg-boinc-devel mailing list pkg-boinc-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-boinc-devel -- pkg-boinc-devel mailing list pkg-boinc-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-boinc-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735289: libsdl2-gfx -- basic antialiased drawing for SDL2
Package: wnpp Severity: wishlist Owner: Debian SDL packages maintainers pkg-sdl-maintain...@lists.alioth.debian.org * Package name: libsdl2-mixer Version : 1.0.0 Upstream Author : Andreas Schiffler aschiffler at ferzkopp dot net * URL : http://www.ferzkopp.net/joomla/content/view/19/14/ * License : zlib/linpng Programming Lang: C Description : The SDL2_gfx library is an extension to the SDL2 library which provides basic antialiased drawing routines such as lines, circles or polygons, an interpolating rotozoomer for SDL2 surfaces, framerate control and MMX image filters.. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733977: boinc-app-milkyway: Please sync with upstream
do you have libboinc-app7 and libboinc-app-dev installed? cheers, Gianfranco Il Venerdì 17 Gennaio 2014 16:03, Ken Sharp imwellcushtymel...@googlemail.com ha scritto: It took me a while to work out what was going on with my builds but I managed to get it to build on amd64 on Debian Testing (failed miserably on Ubuntu Precise), but armel (which is what I really needed it for) fails: # cd /tmp/milkywayathome_client/obj-arm-linux-gnueabi/nbody # /usr/bin/distcc c++ -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -static-libgcc -pthread -fno-unsafe-math-optimizations -fno-common -funswitch-loops -Wall -Wextra -Wshadow -Wredundant-decls -Winline -Wdisabled-optimization -Wpointer-arith -Wcast-align -Wstrict-aliasing -Wstrict-aliasing=3 -Wswitch-enum -Wswitch-default -Wfloat-equal -Wwrite-strings -Wcomment -Wno-unknown-pragmas -fno-rounding-math -fno-math-errno -fopenmp -O2 -g -DNDEBUG -Wl,-z,relro -static-libstdc++ CMakeFiles/milkyway_nbody.dir/src/main.c.o -o ../bin/milkyway_nbody -L/tmp/milkywayathome_client/obj-arm-linux-gnueabi/lib -rdynamic ../lib/libnbody.a ../lib/libnbody_lua.a ../lib/libmilkyway_lua.a ../lib/libnbody.a ../lib/libmilkyway.a ../lib/libpopt.a ../lib/liblua51.a -lm -lrt ../lib/libcrlibm.a -lboinc_graphics2 -lboinc_api -lboinc ../lib/libdsfmt.a -lrt -Wl,-rpath,/tmp/milkywayathome_client/obj-arm-linux-gnueabi/lib /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glutInitWindowPosition' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glPopAttrib' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glutSwapBuffers' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glPointSize' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `gluCylinder' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glutKeyboardUpFunc' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glBegin' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glDisable' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glRasterPos3d' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glutGet' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glColor4d' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glColor4fv' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `boinc_app_mouse_move(int, int, int, int, int)' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `gluSphere' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glPixelStorei' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glTexCoord2f' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glCallLists' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `gluBuild2DMipmaps' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glDepthMask' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glutReshapeFunc' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glutInitDisplayMode' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glVertex3fv' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glBlendFunc' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `gluLookAt' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glColor4f' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `boinc_app_key_press(int, int)' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glutKeyboardFunc' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `gluDeleteQuadric' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glutFullScreen' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glEnable' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glGetIntegerv' /usr/lib/gcc/arm-linux-gnueabi/4.8/../../../libboinc_graphics2.so: undefined reference to `glutMouseFunc'
Bug#733977: boinc-app-milkyway: Please sync with upstream
but I don't undestand you cannot build or run it? if you can build, can you please show ldd of nbody file? I cannot reproduce Gianfranco Il Venerdì 17 Gennaio 2014 16:35, Ken Sharp imwellcushtymel...@googlemail.com ha scritto: On 17/01/14 15:28, Gianfranco Costamagna wrote: libboinc-app7 and libboinc-app-dev installed? Yup, bother version 7.2.33+dfsg-1. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733977: boinc-app-milkyway: Please sync with upstream
I can reproduce. Don't know what is missing, I'll work on it. Gianfranco Il Venerdì 17 Gennaio 2014 18:58, Ken Sharp imwellcushtymel...@googlemail.com ha scritto: On 17/01/14 16:34, Gianfranco Costamagna wrote: but I don't undestand you cannot build or run it? Under armel it does not build. I provided the build failure in a previous email. It claims there are load of undefined references in libboinc_graphics2.so. Repeated multiple times, same result. if you can build, can you please show ldd of nbody file? It doesn't get that far.
Bug#733977: boinc-app-milkyway: Please sync with upstream
Hi, I added a quick and dirty workaround http://anonscm.debian.org/gitweb/?p=pkg-boinc/boinc-app-milkyway.git;a=commitdiff;h=5ebca65e05b19d6dcc1abda6c7e5fefbd793d436 anyway when NBODY_GL is set to off the libboinc_graphic library shouldn't be linked against nbody, this is a milkyway issue, but I won't report and fix until they start accepting my pull requests and we figure out if the source tree if the official one. The problem is really in boinc package, that should link against gl because it uses it. I complained about this on boinc_dev mail list. Thanks, Gianfranco Il Venerdì 17 Gennaio 2014 20:03, Gianfranco Costamagna costamagnagianfra...@yahoo.it ha scritto: I can reproduce. Don't know what is missing, I'll work on it. Gianfranco Il Venerdì 17 Gennaio 2014 18:58, Ken Sharp imwellcushtymel...@googlemail.com ha scritto: On 17/01/14 16:34, Gianfranco Costamagna wrote: but I don't undestand you cannot build or run it? Under armel it does not build. I provided the build failure in a previous email. It claims there are load of undefined references in libboinc_graphics2.so. Repeated multiple times, same result. if you can build, can you please show ldd of nbody file? It doesn't get that far. -- pkg-boinc-devel mailing list pkg-boinc-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-boinc-devel
Bug#736345: flex, new release available for download
Package: flex Version: 2.5.35-10.1 Severity: wishlist Dear Maintainer, A new flex release 2.5.37 is available for download [1] (august 2012) I have already tried to package it and it succedes with not many tweaks (just commenting out a link that the new release automatically does) Of course I think I can NMU it if needed, or put it on mentors. let me know if I can help. [1] http://qa.debian.org/watch/sf.php/flex/flex-2.5.37.tar.gz Gianfranco
Bug#736814: boinc-client recommends the removed ia32-libs
Hi Adrian, thanks for your bug report. Unfortunately this bug has already been fixed in the latest git on alioth. Will be fixed in the next upload, but I cannot do it, since I'm a DM and for the introduction of the server packages this upload will need an action from a DD and go in the new queue (unfortunately). I hope this bug will be fixed soon, since ia32 has been dropped long time ago Gianfranco Il Domenica 26 Gennaio 2014 23:03, Adrian Bunk b...@stusta.de ha scritto: Package: boinc-client Version: 7.2.33+dfsg-1 Severity: serious boinc-client recommends the removed package ia32-libs. -- pkg-boinc-devel mailing list pkg-boinc-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-boinc-devel
Bug#733618: Please backport patch for fpc, fixing sparc build failure
Package: fp-compiler Version: 2.6.2-7 Hi debian fpc developers, I open this bug for asking you to backport this patch from upstream on 2.6x branch. This bug has been reported since two years by a debian folk http://mantis.freepascal.org/view.php?id=19720 this is the fix http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revisionrevision=22477 http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/compiler/sparc/cgcpu.pas?r1=22477r2=22476pathrev=22477 Would be really nice to backport this easy and trivial fix (just disable the error), in order to fix this serious FTBFS in hedgewars/sparc https://buildd.debian.org/status/fetch.php?pkg=hedgewarsarch=sparcver=0.9.20-2stamp=1388364710 (I don't know a proper fix for this, I don't want at this moment to try disabling FPIC) (ccing the last uploaders of fpc on unstable) thanks Gianfranco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733618: Acknowledgement (Please backport patch for fpc, fixing sparc build failure)
Tags: patch I'm attaching the debdiff for your convenience. Thanks 733618.debdiff Description: Binary data
Bug#738849: Please enable webview support for wx3.0
Package: libwxgtk3.0-0 Severity: serious The wx3.0 package *should* depend from libwebkitgtk-3.0-dev. The last boinc release needs webwview support, and I finally spotted why I didn't succeed in building it on a clean debian environment. Your build log clearly says that you are enabling webview checking for --enable-printarch... yes checking for --enable-svg... yes checking for --enable-webkit... yes checking for --enable-webview... yes checking for --enable-graphics_ctx... yes BUT after that you can see it gets disabled checking for linux/joystick.h... yes checking for python... /usr/bin/python configure: WARNING: webkitgtk not found. configure: WARNING: WebKit not available, disabling wxWebView checking for WEBKIT... checking for CAIRO... yes checking for cairo_push_group... yes boinc fails with this log, while building with a custom wx3.0 library doesn't fail. I can upload on mentors or a debdiff here if needed. thanks. G. /usr/include/wx-3.0/wx/vector.h:44:23: warning: previous declaration of 'void wxQsort(void*, size_t, size_t, wxSortCallback, const void*)' [-Wredundant-decls] WXDLLIMPEXP_BASE void wxQsort(void* pbase, size_t total_elems, ^ In file included from NoticeListCtrl.cpp:36:0: NoticeListCtrl.h:48:25: error: 'wxWebViewEvent' has not been declared void OnLinkClicked( wxWebViewEvent event ); ^ NoticeListCtrl.h:49:26: error: 'wxWebViewEvent' has not been declared void OnWebViewError( wxWebViewEvent event ); ^ NoticeListCtrl.h:59:5: error: 'wxWebView' does not name a type wxWebView* m_browser; ^ NoticeListCtrl.cpp:53:72: error: invalid use of non-static member function 'void CNoticeListCtrl::OnLinkClicked(int)' EVT_WEBVIEW_NAVIGATING(ID_LIST_NOTIFICATIONSVIEW, CNoticeListCtrl::OnLinkClicked) ^ NoticeListCtrl.cpp:53:85: error: 'EVT_WEBVIEW_NAVIGATING' was not declared in this scope EVT_WEBVIEW_NAVIGATING(ID_LIST_NOTIFICATIONSVIEW, CNoticeListCtrl::OnLinkClicked) ^ NoticeListCtrl.cpp:54:5: error: expected '}' before 'EVT_WEBVIEW_ERROR' EVT_WEBVIEW_ERROR(ID_LIST_NOTIFICATIONSVIEW, CNoticeListCtrl::OnWebViewError) Building wx [1] https://buildd.debian.org/status/fetch.php?pkg=wxwidgets3.0arch=i386ver=3.0.0-2stamp=1385783568 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738849: Acknowledgement (Please enable webview support for wx3.0)
Attaching the debdiff (I didn't bump the std-version) After further looking at the configure log I found some problems: - you use the embedded libnotify because you don't add the debian one - you don't enable sdl support - you don't enable libmspack support I attached two debdiff, one fixing this bug alone, the second fixing all of them. BR, Gianfranco 738849.debdiff Description: Binary data 738849-v2.debdiff Description: Binary data
Bug#719110: Patch
This is the updated debdiff, following the suggestions from here [1] [1] https://code.launchpad.net/~ankitbko/ubuntu/saucy/eject/fix-for-795239/+merge/173335 I uploaded the package on mentors. thanks, Gianfranco 719110.debdiff Description: Binary data
Bug#739663: Processed: libboinc7: fails to upgrade from 'wheezy' - trying to overwrite /usr/lib/libboinc_zip.so.7
Hi Andreas, I tried to add a Break+Replaces, but it didn't work, I think because now boinc-dev is not a real package anymore, just a transition virtual package. For this reason I only added a breaks on libboinc7, and I tested on a virtual machine. It seems to be working, but this is the first time I play with breaks/replaces fields, so I might be wrong somewhere. this is the commit, I'll upload a version in the next few days if no answer, since I think this bug is pretty serious. http://anonscm.debian.org/gitweb/?p=pkg-boinc/boinc.git;a=commitdiff;h=c993dd1d92d58a03562c52c3d2f8b180303eb84f Can I kindly ask you to review the patch? many thanks, Gianfranco Il Venerdì 21 Febbraio 2014 2:51, Debian Bug Tracking System ow...@bugs.debian.org ha scritto: Processing control commands: affects -1 + boinc-dev Bug #739663 [libboinc7] libboinc7: fails to upgrade from 'wheezy' - trying to overwrite /usr/lib/libboinc_zip.so.7 Added indication that 739663 affects boinc-dev -- 739663: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739663 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- pkg-boinc-devel mailing list pkg-boinc-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-boinc-devel
Bug#739663: Processed: libboinc7: fails to upgrade from 'wheezy' - trying to overwrite /usr/lib/libboinc_zip.so.7
Il Venerdì 21 Febbraio 2014 14:54, Andreas Beckmann a...@debian.org ha scritto: On 2014-02-21 14:37, Gianfranco Costamagna wrote: Hi Andreas, I tried to add a Break+Replaces, but it didn't work, How did this look like? And how did it fail? I dont't honestly remember, it failed with almost the same error, or something related to a missing boinc-dev package I think because now boinc-dev is not a real package anymore, just a transition virtual package. Since the B+R you add are versioned, they only match against real packages. And the old one is a real package. For this reason I only added a breaks on libboinc7, and I tested on a virtual machine. It seems to be working, but this is the first time I play with breaks/replaces fields, so I might be wrong somewhere. This probably breaks if I torture-test it :-) And it will definitely break in case you add a transitional boing-dev package. mmm this is something I don't understand, and moreover the problem is that I manually try to upgrade packages with dpkg, and in this case I needed to add manually libboinc7 IIRC to the list. So I don't know exactly how to test for this bug, this is why help is really needed ;) this is the commit, I'll upload a version in the next few days if no answer, since I think this bug is pretty serious. http://anonscm.debian.org/gitweb/?p=pkg-boinc/boinc.git;a=commitdiff;h=c993dd1d92d58a03562c52c3d2f8b180303eb84f Can I kindly ask you to review the patch? 7.0.39+dfsg-1 is the version that split up boinc-dev? And this was the first upload of the new 7.0.39+dfsg upstream, i.e. there have not been any 7.0.39+dfsg-1~experimental0 or similar versions? this is the version that has some library moved from one package to another, no, this is the first upload, nothing in experimental So each package that got a bit of the previous content (and ships it at the same location) should have Breaks: boinc-dev ( 7.0.39+dfsg) Replaces: boinc-dev ( 7.0.39+dfsg) (in addition to other B+R it might already have). ok, this seems reasonable, but we moved the libraries many times between versions, that boinc-dev, the libboinc introduction, the split between client and server libraries, the server-maker package introduction... Boinc has grown a lot since the old package, this is why I'm having this kind of troubles in thinking in a clean way for upgrade, the same can happen I think even in ubuntu, with different versions and so different files overridden. I don't like to fix just this bug and have a transition failure between somebody with backports enabled or other different repository. I hope to have explained my (maybe wrong, I'm here to learn :p) point thanks for your support and bug report so far! Cheers, Gianfranco (this review is based solely on your reply and the commitdiff you linked, I haven't looked at the boinc package in more detail, but I might take a further look at the weekend) Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719110: review eject 2.1.5+deb1+cvs20081104-13.1 2014-02-14 21:29
Il Domenica 23 Febbraio 2014 10:39, Bart Martens ba...@debian.org ha scritto: Hi Gianfranco, Hi Bart and debian mentors, first sorry for the late reply. I have two questions for you. 1. The patch makes the program use one additional position of the memory pointed to by buf. Are you sure that there will be no buffer overflow for any value of name without replacing 14 by 15 in the allocation ? I honestly don't think so. buf = (char *) malloc(strlen(name)+14); /* to allow for /dev/cdroms/ + 0 + null */ /dev/cdroms/ is 12 characters +1 +1 however we are looking to /dev/cdrom/ +1 +1, that is only 11 characters, so the upper case is not this one, but the latest one (line 483 of the same source file) moreover the malloc takes care of strlen(name) and we do strcpy(buf, /dev/); strcat(buf, name); temp[0]='0'+i; temp[1]='\0'; so in our case we should just have 4+1+1 more bytes, name+6 in total. I don't see any particular issues there. 2. The package has a high popcon. Have you thoroughly tested the resulting package ? I would feel more comfortable if you would confirm that on bug 719110. This is something I cannot really deeply test, however you can follow up the discussion on LP, where there is 15 comments about this topic. Is that enough? I can upload the patch on a ppa and ask to the affected user to reproduce/test. Regards, Bart Martens thanks to you, Gianfranco
Bug#739975: Ettercap version 0.8.0 out
Il Lunedì 24 Febbraio 2014 16:33, Barak A. Pearlmutter ba...@cs.nuim.ie ha scritto: Hi Barak and Alex, Thanks for your note. Yes, 0.8.0 was released some time ago. The kali patches are merged into the Debian packaging branch in git://github.com/barak/ettercap and I tagged kali/0.8.0-0kali1 with a snapshot of the kali sources. If you want to use the kali version you can still stay with Debian. You should be able to simply install the kali .deb file in a Debian system. Or failing that, just build the binary .deb files from source. (If you don't know how to do that ask by private email and I'll explain.) The reason 0.8.0 hasn't made it into Debian is that there are some nasty problems. In version 0.8.0 much of ettercap is broken out into a private shared library libettercap.so, This links to a zillion things it shouldn't, in particular X libraries, even though it is loaded by the text-only ettercap executable. It also causes instability when the same libettercap.so is linked by both the graphical and textual executables. This has been fixed. Upstream is aware of the issues and there's been some work on them, but (due in large measure to my own lack of time) a proper package of 0.8.0 has not yet been generated. Fixed (I think) You can see the work in the above git repo, and I'd welcome patches! I opened a Pull Request for this. Some of the patches, are already been cherry picked from you in your master branch This patch starts from the kali branch that is exactly as the 0.8.0 version, and merges kali, your and my patches into a single commit https://github.com/barak/ettercap/pull/8 Can you please review it? It should be fine right now thanks Gianfranco (who would be glad to comaintain the package) Cheers, --Barak. -- Barak A. Pearlmutter Hamilton Institute Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland http://www.bcl.hamilton.ie/~barak/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739975: (no subject)
With my pull request https://github.com/barak/ettercap/pull/10 everything seems to be back to the normal. The problem was about buildd environment, a typo in control file (buildd picks always the first option IIRC) and a bug in -4 upload, a missing man in the path of ettercap-pkexec. Can you please upload? urgency low should be good, since it is overridden from the previous one! cheers! Gianfranco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738849: Acknowledgement (Please enable webview support for wx3.0)
Il Giovedì 13 Febbraio 2014 20:47, Olly Betts o...@survex.com ha scritto: On Thu, Feb 13, 2014 at 02:08:19PM +, Gianfranco Costamagna wrote: Attaching the debdiff (I didn't bump the std-version) Does enabling webkit support mean that the webkit runtime will become a runtime dependency of libwxgtk3.0-0 (or is there a dynamic loading attempt at runtime with fallback if webkit isn't installed)? I don't know, I think it will become a simple so file, linked against the boinc binary Adding an unconditional dependency on webkit means it will get dragged in by all users of wxwidgets, when few actually need it, which isn't going to be popular, so if it would be a hard dependency, we're going to want to split that out into a separate package (like libwxgtk-media3.0-0 and for similar reasons). Or implement the dynamic loading and push that upstream. this is up to you, I don't know, the package delta is really small, but I'm not in the position of choosing something like that, I just would like to have in one way or the other the webkit support :) After further looking at the configure log I found some problems: - you use the embedded libnotify because you don't add the debian one It's not an embedded copy of libnotify, but rather some generic fallback code. But src/generic/notifmsgg.cpp says: // even if the platform has the native implementation, we still normally want // to use the generic one (unless it's totally unsuitable for the target UI as // is the case of Hildon) because it may provide more features, so include // wx/generic/notifmsg.h to get wxGenericNotificationMessage declaration even // if wx/notifmsg.h only declares wxNotificationMessage itself (if it already // uses the generic version, the second inclusion will do no harm) If the generic version is normally used anyway, building with libnotify seems rather pointless, but I will look into this in more detail. Thanks for pointing this out. - you don't enable sdl support - you don't enable libmspack support Are there packages which actually need these enabling? Just because upstream have support for X doesn't mean we need to enable it in the debian package. Dragging in more dependencies is unhelpful, especially if nobody is using them. Ack for this, feel free to drop it, until maybe somebody asks for it :) Cheers, Gianfranco Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739975: That's great
Hi Barak, are you sure? https://buildd.debian.org/status/package.php?p=ettercap doesn't show up on buildd neither on rss news since 10 hours... Maybe it has been rejected by ftpmaster? Gianfranco Il Mercoledì 26 Febbraio 2014 0:10, Barak A. Pearlmutter ba...@cs.nuim.ie ha scritto: Version 0.8.0-5 is uploaded to Debian now, so if you test that it would be much appreciated. --Barak.
Bug#739999: (no subject)
Oh... this has been reproduce on trusty machine, I asked for a sync request of tomcat7, and the buildd failed to build from source https://launchpadlibrarian.net/167631874/buildlog_ubuntu-trusty-i386.tomcat7_7.0.52-1_FAILEDTOBUILD.txt.gz I don't know the rationale of this problem, because I cannot reproduce in my local pbuilder environment Gianfranco
Bug#690158: (no subject)
In any case, it would be nice if ettercap would warn before disabling packet forwarding, and also by default restore the forwarding setting upon exit. Doing so would avoid the awkward situation that engendered this bug report. This should be fixed in the development release, unfortunately it still needs LOT of testing before of a new release. The problem was in the restore code. Ettercap was starting, tweak ip forward, dropping its privileges, doing the good/bad stuff, trying to restore ip forward (but without enough privileges) - fail. Now instead of setuid we use seteuid, that should give us the possibility to become root again (and seems working so far). reference: https://github.com/Ettercap/ettercap/blob/master/src/ec_utils.c (regain_privs function) So the restoration code should work now. Unfortunately there are some issues about an incorret ip-forward ssl rule reported, that might be related to this regain/drop_privs functions https://github.com/Ettercap/ettercap/issues/465 So hopefully the next release will close this issue aswell. Cheers, Gianfranco
Bug#740705: Please incorportate ubuntu patches
Package: insighttoolkit
Version: 3.20.1+git20120521-4
Severity: wishlist
Tags: patch
Dear Maintainer,
The ubuntu insidhttoolkit package has some patches that would be nice to have
included in (maybe) the next upload, or at least discussed here.
Since the tiff-4/5 patch has been dropped in debian, in favor of the embedded
copy I suggest to include/drop the other delta from ubuntu.
The patch is snan-sanity.patch
and this is the content:
Index: insighttoolkit-3.20.1+git20120521/Utilities/NrrdIO/sane.c
=== ---
insighttoolkit-3.20.1+git20120521.orig/Utilities/NrrdIO/sane.c 2012-09-11
17:25:06.0 + +++
insighttoolkit-3.20.1+git20120521/Utilities/NrrdIO/sane.c 2012-09-11
17:39:19.196189762 + @@ -115,7 +115,11 @@ ( defined(__GNUC__) (__GNUC__
4 || (__GNUC__ == 4 __GNUC_MINOR__ = 7 ))) /* don't compare airFP_SNAN
*/ #else - airFP_SNAN == airFPClass_f(AIR_SNAN) + /* we
don't bother checking for +airFP_SNAN == airFPClass_f(AIR_SNAN)
because +the signal-ness of the NaN is not preserved in +
float conversion */ + /* airFP_SNAN == airFPClass_f(AIR_SNAN) */
#endif airFP_QNAN == airFPClass_d(AIR_NAN) airFP_QNAN ==
airFPClass_d(AIR_QNAN) )) {
and the rationale for including it (quoting the ubuntu changelog)
insighttoolkit (3.20.1+git20120521-1ubuntu3) quantal; urgency=low *
debian/patches/snan-sanity.patch: - In sanity checks done by the nrrd utility
code, don't bother testing signal NaN clases, because GCC does not guarantee to
preserve signal-ness across float conversions. This was contributing to a FTBFS
for plastimatch. -- Michael Terry mte...@ubuntu.com Wed, 25 Jul 2012 14:08:00
-0400
thanks for reading,
Gianfranco
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740705: Please incorportate ubuntu patches
Il Giovedì 6 Marzo 2014 5:59, Steve M. Robbins st...@sumost.ca ha scritto: On March 4, 2014 08:42:43 AM Gianfranco Costamagna wrote: Package: insighttoolkit Version: 3.20.1+git20120521-4 Severity: wishlist Tags: patch Dear Maintainer, The ubuntu insidhttoolkit package has some patches that would be nice to have included in (maybe) the next upload, or at least discussed here. Well, given that ITK 3.20 is well over 3 years old, I don't anticipate spending much of my time on it. But the package is under group maintenance and maybe one of the other maintainers will step up. Hi Steve!, Ok, can you then please sponsor a package for me? I can fix this bug, also #740628 and push on mentors. Is there some reason you can't use ITK v4? The main reason is: armel is not present in the architecture list set by the maintainer armhf is not present in the architecture list set by the maintainer hurd-i386 is not present in the architecture list set by the maintainer kfreebsd-amd64 is not present in the architecture list set by the maintainer kfreebsd-i386 is not present in the architecture list set by the maintainer mips is not present in the architecture list set by the maintainer mipsel is not present in the architecture list set by the maintainer powerpc is not present in the architecture list set by the maintainer s390x is not present in the architecture list set by the maintainer sparc is not present in the architecture list set by the maintainer many packages that have been successfully built with the v3 won't build anymore against v4, so the rationale is use 4 on amd64 and i386, switch to v3 for other archs. I don't know if you have an hint for building them against v4 (removing the package from ftpmaster will let the package reach testing I know) Thanks! Gianfranco -Steve -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734588: transition sdlgfx 2.0.23 to 2.0.25
Uploaded and built. http://packages.qa.debian.org/s/sdlgfx.html thanks, Gianfranco Il Sabato 5 Aprile 2014 14:44, Julien Cristau jcris...@debian.org ha scritto: Control: tag -1 confirmed On Wed, Jan 8, 2014 at 10:40:06 +, Gianfranco Costamagna wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition (opening a bug, sorry for double posting) Hi debian release Managers! Together with Manuel (the sdlgfx uploader, who reads in cc), we decided to ask for a transition the package can be found here [1] and brings a really similar API, but the packages that build-deps from it will likely need a binNMU to build against the new ABI/API. Feel free to upload to unstable. Cheers, Julien
Bug#745228: flex: Flex 2.5.39-3 has a typo in installman
Package: flex Version: 2.5.39-3 Severity: serious Dear Manoj, (opening this bug just to prevet flex reach testing) This commit [1] introduced a bug in rules files (probably a typo) -override_dh_installman: +verride_dh_installman: this prevents the override_dh_installman to be executed. Also changing the changelog after a release is not a good pratice (a typo of course), would be nice to have it reverted debian/changelog @@ -19,7 +27,6 @@ flex (2.5.39-2) unstable; urgency=low flex (2.5.39-1) unstable; urgency=medium - * New upstream release * internationalization: added support for various languages. Fix make install target to not fail when the flex++ program is already @@ -42,7 +49,6 @@ flex (2.5.39-1) unstable; urgency=medium build system in the NMU are not needed, dh does the right thing. * The new upstream release added the prototypes in re-entrant mode, so we are no longer carrying those patches. - -- Manoj Srivastava sriva...@debian.org Thu, 10 Apr 2014 18:06:12 -0700 How do you feel about fixing if they are bugs? Sorry for the serious severity, but I don't think this package should reach testing... Feel free to downgrade if it was intended. [1] http://anonscm.debian.org/gitweb/?p=users/srivasta/debian/flex.git;a=commitdiff;h=bc29909df3c662da30d80f22ded71b05988ac965 Happy Easter! Gianfranco
Bug#745229: libsdl-perl binNMU fail to build from source
Package: libsdl-perl Version: 2.540-5 Severity: normal Dear Maintainer The transition of auto sdlgfx [1] seems stuck because of two build failures [2] of your libsdl-perl amd64 and s390x packages I tried to rebuild it on my sid amd64 up-to-date local pbuilder environment, and I built it successfully. Without knowing the rationale of this build failure (that isn't reproducible locally), I just open this bug in order to make you aware of the issue. [1] https://release.debian.org/transitions/html/auto-sdlgfx.html [2] https://buildd.debian.org/status/package.php?p=libsdl-perl Happy Easter! Gianfranco
Bug#744896: upstream fixed this bug
tags 744896 fixed-upstream Hi, I would like to inform you that the bug has been fixed upstream https://gist.github.com/FROGGS/11191811 thanks, Gianfranco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731823: Fixed in mentors, can anybody please sponsor?
Hi *
file vtkXYPlotActor.class
vtkXYPlotActor.class: compiled Java class data, version 49.0 (Java 1.5)
file vtkTypeInt16Array.class
vtkTypeInt16Array.class: compiled Java class data, version 49.0 (Java 1.5)
the trick was this patch
+--- a/CMake/vtkWrapJava.cmake
b/CMake/vtkWrapJava.cmake
+@@ -204,7 +204,7 @@ MACRO(VTK_GENERATE_JAVA_DEPENDENCIES TARGET)
+ ADD_CUSTOM_COMMAND(
+ OUTPUT ${driver}
+ COMMAND ${JAVA_COMPILE}
+- -source 5 -classpath
${javaPath} ${srcPath}/vtk${TARGET}Driver.java
++ -source 1.5 -target 1.5 -classpath ${javaPath}
${srcPath}/vtk${TARGET}Driver.java
+ DEPENDS ${sources}
+ )
+ ADD_CUSTOM_COMMAND(TARGET ${TARGET} SOURCE ${TARGET} DEPENDS ${driver})
So I started from jordi's patch, added this, rebuilt, checked the binary,
uploaded on mentors...
changestool for adding the orig tar.gz (sick, mentors wants it)
waiting for a sponsor ;)
cheers,
Gianfranco
Bug#747108: I: Fixed in mentors, can anybody please sponsor?
Hi *
Like for the other bug 731823 I did the same trick for this RC bug.
However I'm not sure if the TCL patches from Jordi should be applied here too
or not.
the trick was this patch
--- vtk6-6.0.0.orig/Wrapping/Java/CMakeLists.txt
+++ vtk6-6.0.0/Wrapping/Java/CMakeLists.txt
@@ -237,7 +237,7 @@
add_custom_command(
OUTPUT ${VTK_BINARY_DIR}/java/javac_stamp.txt
DEPENDS ${VTK_JAVA_SOURCE_FILES}
COMMAND ${JAVA_COMPILE} ${JAVAC_OPTIONS}
- -source 1.5 -classpath
${VTK_JAVA_HOME}/..${SEPARATOR}${ECLIPSE_SWT_LIBRARIES} -sourcepath
${VTK_SOURCE_DIR}/Wrapping/Java/ -d ${VTK_BINARY_DIR}/java
+ -source 1.5 -target 1.5 -classpath
${VTK_JAVA_HOME}/..${SEPARATOR}${ECLIPSE_SWT_LIBRARIES} -sourcepath
${VTK_SOURCE_DIR}/Wrapping/Java/ -d ${VTK_BINARY_DIR}/java
${VTK_BINARY_DIR}/java/vtk/*.java
${VTK_BINARY_DIR}/java/vtk/rendering/*.java
${VTK_BINARY_DIR}/java/vtk/rendering/awt/*.java ${SWT_FILES}
COMMAND ${CMAKE_COMMAND} -E touch ${VTK_BINARY_DIR}/java/javac_stamp.txt
COMMENT Compiling Java Classes
waiting for a sponsor on mentors;)
cheers,
Gianfranco
Bug#747108: I: Fixed in mentors, can anybody please sponsor?
Hi Anton,
Thanks to you for the upload!
Since you are in the debian science team, can you please also upload vtk?
http://bugs.debian.org/731823
and also, do you think the vtk tcl fixes should be cherry picked to vtk6 too?
cheers,
Gianfranco
Il Venerdì 9 Maggio 2014 23:36, Anton Gladky gl...@debian.org ha scritto:
Hi Gianfranco,
thanks for the help! I integrated your fix into the next upload.
Regards
Anton
2014-05-09 19:03 GMT+02:00 Gianfranco Costamagna
costamagnagianfra...@yahoo.it:
Hi *
Like for the other bug 731823 I did the same trick for this RC bug.
However I'm not sure if the TCL patches from Jordi should be applied here
too or not.
the trick was this patch
--- vtk6-6.0.0.orig/Wrapping/Java/CMakeLists.txt
+++ vtk6-6.0.0/Wrapping/Java/CMakeLists.txt
@@ -237,7 +237,7 @@ add_custom_command(
OUTPUT ${VTK_BINARY_DIR}/java/javac_stamp.txt
DEPENDS ${VTK_JAVA_SOURCE_FILES}
COMMAND ${JAVA_COMPILE} ${JAVAC_OPTIONS}
- -source 1.5 -classpath
${VTK_JAVA_HOME}/..${SEPARATOR}${ECLIPSE_SWT_LIBRARIES} -sourcepath
${VTK_SOURCE_DIR}/Wrapping/Java/ -d ${VTK_BINARY_DIR}/java
+ -source 1.5 -target 1.5 -classpath
${VTK_JAVA_HOME}/..${SEPARATOR}${ECLIPSE_SWT_LIBRARIES} -sourcepath
${VTK_SOURCE_DIR}/Wrapping/Java/ -d ${VTK_BINARY_DIR}/java
${VTK_BINARY_DIR}/java/vtk/*.java
${VTK_BINARY_DIR}/java/vtk/rendering/*.java
${VTK_BINARY_DIR}/java/vtk/rendering/awt/*.java ${SWT_FILES}
COMMAND ${CMAKE_COMMAND} -E touch ${VTK_BINARY_DIR}/java/javac_stamp.txt
COMMENT Compiling Java Classes
waiting for a sponsor on mentors;)
cheers,
Gianfranco
--
debian-science-maintainers mailing list
debian-science-maintain...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#731823: Bug#747108: I: Fixed in mentors, can anybody please sponsor?
Hi Anton, thanks again for the upload, but are you sure my patch alone is
enough?
Because I started from Jordi's modifications, that were into the
allpatches.patch patch
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=42;bug=731823
I don't know if it works without them, did you test it?
also the tcl patch and the missing ${shlibs:Depends} should be fixed in my
opinion
Gianfranco
Il Sabato 10 Maggio 2014 10:24, Anton Gladky gl...@debian.org ha scritto:
Hi Gianfranco,
thanks for the fix! I have applied your patch and made an upload.
http://anonscm.debian.org/gitweb/?p=collab-maint/vtk.git;a=commitdiff;h=5e721d4f2721b41c528ccd5960e6196ff4a77318
Anton
2014-05-10 0:09 GMT+02:00 Gianfranco Costamagna
costamagnagianfra...@yahoo.it:
Hi Anton,
Thanks to you for the upload!
Since you are in the debian science team, can you please also upload vtk?
http://bugs.debian.org/731823
and also, do you think the vtk tcl fixes should be cherry picked to vtk6
too?
cheers,
Gianfranco
Il Venerdì 9 Maggio 2014 23:36, Anton Gladky gl...@debian.org ha scritto:
Hi Gianfranco,
thanks for the help! I integrated your fix into the next upload.
Regards
Anton
2014-05-09 19:03 GMT+02:00 Gianfranco Costamagna
costamagnagianfra...@yahoo.it:
Hi *
Like for the other bug 731823 I did the same trick for this RC bug.
However I'm not sure if the TCL patches from Jordi should be applied here
too or not.
the trick was this patch
--- vtk6-6.0.0.orig/Wrapping/Java/CMakeLists.txt
+++ vtk6-6.0.0/Wrapping/Java/CMakeLists.txt
@@ -237,7 +237,7 @@ add_custom_command(
OUTPUT ${VTK_BINARY_DIR}/java/javac_stamp.txt
DEPENDS ${VTK_JAVA_SOURCE_FILES}
COMMAND ${JAVA_COMPILE} ${JAVAC_OPTIONS}
- -source 1.5 -classpath
${VTK_JAVA_HOME}/..${SEPARATOR}${ECLIPSE_SWT_LIBRARIES} -sourcepath
${VTK_SOURCE_DIR}/Wrapping/Java/ -d ${VTK_BINARY_DIR}/java
+ -source 1.5 -target 1.5 -classpath
${VTK_JAVA_HOME}/..${SEPARATOR}${ECLIPSE_SWT_LIBRARIES} -sourcepath
${VTK_SOURCE_DIR}/Wrapping/Java/ -d ${VTK_BINARY_DIR}/java
${VTK_BINARY_DIR}/java/vtk/*.java
${VTK_BINARY_DIR}/java/vtk/rendering/*.java
${VTK_BINARY_DIR}/java/vtk/rendering/awt/*.java ${SWT_FILES}
COMMAND ${CMAKE_COMMAND} -E touch
${VTK_BINARY_DIR}/java/javac_stamp.txt
COMMENT Compiling Java Classes
waiting for a sponsor on mentors;)
cheers,
Gianfranco
--
debian-science-maintainers mailing list
debian-science-maintain...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731823: Not fixed.
Hi all, I grabbed the deb from debian incoming and this bug is NOT fixed. Can you please upload again with the real fix from mentors? There is also a build failure on kfreebsd-amd64, don't know if related to this fix https://buildd.debian.org/status/fetch.php?pkg=vtkarch=kfreebsd-amd64ver=5.8.0-16stamp=1399720557 cheers, Gianfranco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748013: PTS doesnt display uploads to mentors anymore
Hi Holger, the fact is that I reuploaded the package and now it is in the delayed/5 queue. It was correctly shown on the BTS some hours ago. for me this is not a bug. Gianfranco Il Martedì 13 Maggio 2014 14:39, Holger Levsen hol...@layer-acht.org ha scritto: package: qa.debian.org x-debbugs-cc: Gianfranco Costamagna costamagnagianfra...@yahoo.it Hi, On Montag, 12. Mai 2014, Gianfranco Costamagna wrote: cppcheck [1] has been removed from testing [2] because of a sourceless javascript file [3]. Because of this I packaged (with patch and thanks from Octavio) a new dfsg version and uploaded on mentors [4] some time ago. (I'm uploading it again right now since I forgot to put the bug reference into the changelog) [...] [1] http://packages.qa.debian.org/c/cppcheck.html [4] http://mentors.debian.net/package/cppcheck indeed, that upload is on mentors.d.n, but it's not displayed in the cppcheck PTS page. Appearantly this used to work, so somehow it has been broken... cheers, Holger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748169: boinc
Boinc 7.2 doesn't build with wx3.0. This is a known problem, and it has been already fixed in 7.4 releases. I'll be really happy to upload the new release as soon as 738849 [1] is fixed, since the new release uses webview and doesn't build with the current package. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738849 cheers, Gianfranco
Bug#738849: Please enable webview support for wx3.0
Hi Olly, I'm looking right now at the package. Enabling webview gives us a new library, so I think a new package is the most feasible way, right? (sorry, the package is quite heavy, I can miss something) ldd debian/tmp/usr/bin/boincmgr |grep wx libwx_gtk2u_webview-3.0.so.0 = /usr/lib/x86_64-linux-gnu/libwx_gtk2u_webview-3.0.so.0 (0x7fd6b9232000) this is the library installed in libwxgtk3.0-0_3.0.0 because of install-gtk-lib: install-gtk-shared-stamp [snip] dh_install -Xmedia $(objdir_gtk_install)/lib/$(DEB_HOST_MULTIARCH)/libwx_gtk*.so.* usr/lib/$(DEB_HOST_MULTIARCH) [/snip] install-gtk-dev: install-gtk-shared-stamp [snip] dh_install -Xmedia $(objdir_gtk_install)/lib/$(DEB_HOST_MULTIARCH)/libwx_gtk*.so usr/lib/$(DEB_HOST_MULTIARCH) [snip] and I'll look shortly where the headers file are located but I'm pretty sure they are in package_headers := wx$(release)-headers since they are included as wx/webview.h wx/webviewfshandler.h so can you please suggest me how to move on? My opinion: -leave headers in the generic package (should check but I'm pretty sure they already are there -create a new package? move on -media? this is up to you something like libwxgtk-webview=SOV with the library inside and a libwxgtk-webview-dev with the link? the patch seems to be really trivial if I'm understanding correctly how does your package work cheers, Gianfranco Il Giovedì 17 Aprile 2014 3:03, Olly Betts o...@survex.com ha scritto: On Wed, Apr 16, 2014 at 07:00:15AM +0100, costamagnagianfra...@yahoo.it wrote: Hi Olly, do you have any news on this? Boinc 7.4.x is going to be released soon, with webview support, would be nice to have it at least in experimental for testing, do you think is it possible? I seem to be the only active member of the wx maintainers team, and my wx time is already occupied with trying to migrate the archive away from 2.8. It would be good if that happened before jessie, and there's still a lot to do (and this is only the C++ packages - I've not even started on wxpython yet): https://wiki.debian.org/Teams/WxWidgets/Transition2.8to3.0 So if you want to get webview support with any degree of urgency, you'll have to do the hard work yourself I'm afraid - just chucking the trivial patch at me isn't anything like enough. If someone provides a well tested and sane patch, I'm very likely to apply it. As I've outlined already at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738849#22 we can't have libwxgtk3.0-0 depending on webkit or else people will quite reasonably complain about the dependency bloat. The webkit libraries either need to be loaded dynamically on demand, or else we need a separate binary package containing just the webkit parts of wx (similar to libwxgtk-media3.0-0 for wxMediaCtrl). To be explicit: For webview support, the first thing you probably need to do is check the binary packages you built from your modified source package and see what their dependencies are compared to those for the packages currently in the archive. If your changes gain us a dependency on webkit libraries (which seems likely) you need to either split off that code into a separate library and put it in its own binary package, or change wx to load those libraries only when actually used, ideally using the wx wrappers around dlopen(), dlsym(), etc so we can try to push the patch upstream. If you want us to switch to using libnotify instead of the generic wx implementation, you need to respond to my query (and quoted source code comment) in comment 22. If you want us to enable sdl and libmspack support, you also need to justify why doing so is useful, and investigate the (direct and indirect) extra dependencies which each results in. Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738849: Please enable webview support for wx3.0
Hi again Olly. The package seems to be building fine, running with the split and boinc now builds correctly (I didn't test the run, just the build). I double checked the libraries, they aren't anymore in the gtk package and they are in the webview one. I also checked the documentation, and updated it. https://github.com/LocutusOfBorg/wx/commit/92a5bd8ff7c2347d00beac74f0938689ce706679 https://github.com/LocutusOfBorg/wx/commit/4b357103f85186a8585edb60d0ef6c707dfac5ba I'm still a little bit worried about the dependencies that I should add for the new packages, can you please review? The patch was really trivial, it needed just a little time for me once I got the courage for starting Nothing should be pushed upstream, the package already correctly builds its own library. I would like to contribute a little more if you want, bumping standard version, maybe cherry-pick the patch from #736374 or would you like to wait for the new upcoming release? I really would like a positive, negative or whatever feedback (please ask me to test whatever you want, I don't know if I did the whole work correctly) have a nice weekend cheers, Gianfranco Il Giovedì 24 Aprile 2014 18:11, Gianfranco Costamagna costamagnagianfra...@yahoo.it ha scritto: Hi Olly, I'm looking right now at the package. Enabling webview gives us a new library, so I think a new package is the most feasible way, right? (sorry, the package is quite heavy, I can miss something) ldd debian/tmp/usr/bin/boincmgr |grep wx libwx_gtk2u_webview-3.0.so.0 = /usr/lib/x86_64-linux-gnu/libwx_gtk2u_webview-3.0.so.0 (0x7fd6b9232000) this is the library installed in libwxgtk3.0-0_3.0.0 because of install-gtk-lib: install-gtk-shared-stamp [snip] dh_install -Xmedia $(objdir_gtk_install)/lib/$(DEB_HOST_MULTIARCH)/libwx_gtk*.so.* usr/lib/$(DEB_HOST_MULTIARCH) [/snip] install-gtk-dev: install-gtk-shared-stamp [snip] dh_install -Xmedia $(objdir_gtk_install)/lib/$(DEB_HOST_MULTIARCH)/libwx_gtk*.so usr/lib/$(DEB_HOST_MULTIARCH) [snip] and I'll look shortly where the headers file are located but I'm pretty sure they are in package_headers := wx$(release)-headers since they are included as wx/webview.h wx/webviewfshandler.h so can you please suggest me how to move on? My opinion: -leave headers in the generic package (should check but I'm pretty sure they already are there -create a new package? move on -media? this is up to you something like libwxgtk-webview=SOV with the library inside and a libwxgtk-webview-dev with the link? the patch seems to be really trivial if I'm understanding correctly how does your package work cheers, Gianfranco Il Giovedì 17 Aprile 2014 3:03, Olly Betts o...@survex.com ha scritto: On Wed, Apr 16, 2014 at 07:00:15AM +0100, costamagnagianfra...@yahoo.it wrote: Hi Olly, do you have any news on this? Boinc 7.4.x is going to be released soon, with webview support, would be nice to have it at least in experimental for testing, do you think is it possible? I seem to be the only active member of the wx maintainers team, and my wx time is already occupied with trying to migrate the archive away from 2.8. It would be good if that happened before jessie, and there's still a lot to do (and this is only the C++ packages - I've not even started on wxpython yet): https://wiki.debian.org/Teams/WxWidgets/Transition2.8to3.0 So if you want to get webview support with any degree of urgency, you'll have to do the hard work yourself I'm afraid - just chucking the trivial patch at me isn't anything like enough. If someone provides a well tested and sane patch, I'm very likely to apply it. As I've outlined already at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738849#22 we can't have libwxgtk3.0-0 depending on webkit or else people will quite reasonably complain about the dependency bloat. The webkit libraries either need to be loaded dynamically on demand, or else we need a separate binary package containing just the webkit parts of wx (similar to libwxgtk-media3.0-0 for wxMediaCtrl). To be explicit: For webview support, the first thing you probably need to do is check the binary packages you built from your modified source package and see what their dependencies are compared to those for the packages currently in the archive. If your changes gain us a dependency on webkit libraries (which seems likely) you need to either split off that code into a separate library and put it in its own binary package, or change wx to load those libraries only when actually used, ideally using the wx wrappers around dlopen(), dlsym(), etc so we can try to push the patch upstream. If you want us to switch to using libnotify instead of the generic wx implementation, you need to respond to my query (and quoted source code comment
Bug#738849: Please enable webview support for wx3.0
Hi Olly! Il Lunedì 28 Aprile 2014 7:47, Olly Betts o...@survex.com ha scritto: Il Giovedì 24 Aprile 2014 18:11, Gianfranco Costamagna costamagnagianfra...@yahoo.it ha scritto: Hi Olly, I'm looking right now at the package. Enabling webview gives us a new library, so I think a new package is the most feasible way, right? Yes, seems we should be able to put the webview library into a new binary package (very like how the mmedia library is handled). yes, I started from media package and did some magic sed commands to copy paste My opinion: -leave headers in the generic package (should check but I'm pretty sure they already are there That seems reasonable (and to be what we do for the wxmediactrl headers). mmm the headers were already there, so I don't think we need to change anything here (the files have some magic #ifdef inside) https://packages.debian.org/sid/amd64/wx3.0-headers/filelist /usr/include/wx-3.0/wx/webview.h /usr/include/wx-3.0/wx/webviewarchivehandler.h /usr/include/wx-3.0/wx/webviewfshandler.h something like libwxgtk-webview=SOV with the library inside and a libwxgtk-webview-dev with the link? Yes. wonderful the patch seems to be really trivial if I'm understanding correctly how does your package work If there's already a separate library built, then it shouldn't be a complex patch, though it still needs careful testing as the simple changes in the patch can cause major changes in the resulting packages. yes of course I double checked the libraries, they aren't anymore in the gtk package and they are in the webview one. Have you compared the existing binary packages before and after your changes with debdiff? That's a good way to pick up any files that have inadvertently been installed to a different package, or which have changed in ways we don't want. I did some magic test here: the new packages shows these files $ dpkg -c libwxgtk-webview3.0-0_3.0.0-3_amd64.deb drwxr-xr-x root/root 0 2014-04-28 17:34 ./ drwxr-xr-x root/root 0 2014-04-28 17:33 ./usr/ drwxr-xr-x root/root 0 2014-04-28 17:33 ./usr/share/ drwxr-xr-x root/root 0 2014-04-28 17:33 ./usr/share/doc/ drwxr-xr-x root/root 0 2014-04-28 17:34 ./usr/share/doc/libwxgtk-webview3.0-0/ -rw-r--r-- root/root 22859 2014-04-28 09:25 ./usr/share/doc/libwxgtk-webview3.0-0/copyright -rw-r--r-- root/root 79775 2013-11-11 14:10 ./usr/share/doc/libwxgtk-webview3.0-0/changelog.gz -rw-r--r-- root/root 18441 2014-04-28 11:04 ./usr/share/doc/libwxgtk-webview3.0-0/changelog.Debian.gz drwxr-xr-x root/root 0 2014-04-28 17:33 ./usr/share/lintian/ drwxr-xr-x root/root 0 2014-04-28 17:33 ./usr/share/lintian/overrides/ -rw-r--r-- root/root 57 2014-04-28 17:33 ./usr/share/lintian/overrides/libwxgtk-webview3.0-0 drwxr-xr-x root/root 0 2014-04-28 17:33 ./usr/lib/ drwxr-xr-x root/root 0 2014-04-28 17:34 ./usr/lib/x86_64-linux-gnu/ -rw-r--r-- root/root 122608 2014-04-28 17:34 ./usr/lib/x86_64-linux-gnu/libwx_gtk2u_webview-3.0.so.0.0.0 lrwxrwxrwx root/root 0 2014-04-28 17:33 ./usr/lib/x86_64-linux-gnu/libwx_gtk2u_webview-3.0.so.0 - libwx_gtk2u_webview-3.0.so.0.0.0 $ dpkg -c libwxgtk-webview3.0-0-dbg_3.0.0-3_amd64.deb drwxr-xr-x root/root 0 2014-04-28 17:34 ./ drwxr-xr-x root/root 0 2014-04-28 17:34 ./usr/ drwxr-xr-x root/root 0 2014-04-28 17:33 ./usr/share/ drwxr-xr-x root/root 0 2014-04-28 17:33 ./usr/share/doc/ drwxr-xr-x root/root 0 2014-04-28 17:34 ./usr/share/doc/libwxgtk-webview3.0-0-dbg/ -rw-r--r-- root/root 22859 2014-04-28 09:25 ./usr/share/doc/libwxgtk-webview3.0-0-dbg/copyright -rw-r--r-- root/root 79775 2013-11-11 14:10 ./usr/share/doc/libwxgtk-webview3.0-0-dbg/changelog.gz -rw-r--r-- root/root 18441 2014-04-28 11:04 ./usr/share/doc/libwxgtk-webview3.0-0-dbg/changelog.Debian.gz drwxr-xr-x root/root 0 2014-04-28 17:34 ./usr/lib/ drwxr-xr-x root/root 0 2014-04-28 17:34 ./usr/lib/debug/ drwxr-xr-x root/root 0 2014-04-28 17:34 ./usr/lib/debug/.build-id/ drwxr-xr-x root/root 0 2014-04-28 17:34 ./usr/lib/debug/.build-id/a5/ -rw-r--r-- root/root 638129 2014-04-28 17:34 ./usr/lib/debug/.build-id/a5/eafcf1baff67ffc345ddf7927e5a47f28ed8d6.debug $ dpkg -c libwxgtk-webview3.0-dev_3.0.0-3_amd64.deb drwxr-xr-x root/root 0 2014-04-28 17:34 ./ drwxr-xr-x root/root 0 2014-04-28 17:33 ./usr/ drwxr-xr-x root/root 0 2014-04-28 17:33 ./usr/share/ drwxr-xr-x root/root 0 2014-04-28 17:33 ./usr/share/doc/ drwxr-xr-x root/root 0 2014-04-28 17:34 ./usr/share/doc/libwxgtk-webview3.0-dev/ -rw-r--r-- root/root 22859 2014-04-28 09:25 ./usr/share/doc/libwxgtk-webview3.0-dev/copyright -rw-r--r-- root/root 79775 2013-11-11 14:10 ./usr/share/doc/libwxgtk-webview3.0-dev/changelog.gz -rw-r--r-- root/root 18441 2014-04-28 11:04 ./usr/share/doc
Bug#738849: Please enable webview support for wx3.0
Il Giovedì 1 Maggio 2014 0:32, Olly Betts o...@survex.com ha scritto:
On Wed, Apr 30, 2014 at 07:34:03PM +0100, costamagnagianfra...@yahoo.it
wrote:
Il Mercoledì 30 Aprile 2014 12:39, Olly Betts o...@survex.com
ha scritto:
On Wed, Apr 30, 2014 at 08:45:47AM +0100, Gianfranco Costamagna
wrote:
Isn't the -Wl,--as-needed automatically passed by
dh
system? are you
overriding LDFLAGS somewhere?
I don't believe either is true. Passing it unconditionally
wouldn't be
a good plan, as it breaks some cases (as I mentioned above).
Are you perhaps thinking of -Wl,-z,relro (which is related
to
hardening)?
ok can it be that ubuntu enables them by default and debian not?
https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed
I don't follow Ubuntu development these days, but possibly.
ubuntu is using them since three years, and why should removing a not
used library be a problem?
I mean if no symbols are used we can drop safely right?
It isn't always safe to do so - you can get a clean build but hit
problems at runtime. For example a program might use dlsym() to look up
a symbol from a library it was linked against, but if there aren't any
references at link time, the library won't be there if --as-needed is
used:
olly@gemse:~$ cat asneeded.c
#include dlfcn.h
#include stdio.h
int main(int argc, char ** argv) {
void * handle = dlopen(NULL, RTLD_NOW);
if (!handle) {
fprintf(stderr, dlopen failed: %s\n, dlerror());
return 1;
}
(void)argc;
while (*++argv) {
printf(%s=%p\n, *argv, dlsym(handle, *argv));
}
return 0;
}
olly@gemse:~$ gcc -Wall -W -O2 asneeded.c -ldl -lz -o asneeded
olly@gemse:~$ ./asneeded zlibVersion
zlibVersion=0x7fc6e04a9fc0
olly@gemse:~$ gcc -Wall -W -O2 -Wl,--as-needed asneeded.c -ldl -lz -o
asneeded
olly@gemse:~$ ./asneeded zlibVersion
zlibVersion=(nil)
Lol, please look what happens on my ubuntu saucy machine
gcc -Wall -W -O2 as.c -ldl -lz
./a.out zlibVersion
zlibVersion=(nil)
gcc -Wall -W -O2 -Wl,--as-needed as.c -ldl -lz
./a.out zlibVersion
zlibVersion=(nil)
So should be harmless because I didn't see a ton of bug reports on ubuntu for
this :)
Thanks for teaching me this, I wasn't aware of the dlopen possibility
Can we safely leave them inside?
The patch is so ugly, but the libraries are not there anymore
https://github.com/LocutusOfBorg/wx/commit/e18d875c355096e458371d7f83910d02c926c294
A much cleaner way is just to add this to debian/rules instead of the
above changes:
export DEB_LDFLAGS_APPEND=-Wl,--as-needed
Oh yes, I was aware of something like this, but I forgot the exact syntax and
slipped out of my mind...
Should be fixed and ready now!
https://github.com/LocutusOfBorg/wx/commit/7ad7d5974db86f62b805c33ef6d61e6d25dd
Attached the log of the new debdiffs
Great, that looks much better to me. Thanks for all your work on this.
Thanks to you! I have still too much to learn from debian and you all :)
(I'm rebuilding right now)
Cheers,
Olly
Have a nice day,
Gianfranco
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738849: Please enable webview support for wx3.0
Hi again Olly
Il Giovedì 1 Maggio 2014 0:32, Olly Betts o...@survex.com ha scritto:
On Wed, Apr 30, 2014 at 07:34:03PM +0100, costamagnagianfra...@yahoo.it
wrote:
Il Mercoledì 30 Aprile 2014 12:39, Olly Betts o...@survex.com
ha scritto:
On Wed, Apr 30, 2014 at 08:45:47AM +0100, Gianfranco Costamagna
wrote:
Isn't the -Wl,--as-needed automatically passed by
dh
system? are you
overriding LDFLAGS somewhere?
I don't believe either is true. Passing it unconditionally
wouldn't be
a good plan, as it breaks some cases (as I mentioned above).
Are you perhaps thinking of -Wl,-z,relro (which is related
to
hardening)?
ok can it be that ubuntu enables them by default and debian not?
https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed
I don't follow Ubuntu development these days, but possibly.
ubuntu is using them since three years, and why should removing a not
used library be a problem?
I mean if no symbols are used we can drop safely right?
It isn't always safe to do so - you can get a clean build but hit
problems at runtime. For example a program might use dlsym() to look up
a symbol from a library it was linked against, but if there aren't any
references at link time, the library won't be there if --as-needed is
used:
olly@gemse:~$ cat asneeded.c
#include dlfcn.h
#include stdio.h
int main(int argc, char ** argv) {
void * handle = dlopen(NULL, RTLD_NOW);
if (!handle) {
fprintf(stderr, dlopen failed: %s\n, dlerror());
return 1;
}
(void)argc;
while (*++argv) {
printf(%s=%p\n, *argv, dlsym(handle, *argv));
}
return 0;
}
olly@gemse:~$ gcc -Wall -W -O2 asneeded.c -ldl -lz -o asneeded
olly@gemse:~$ ./asneeded zlibVersion
zlibVersion=0x7fc6e04a9fc0
olly@gemse:~$ gcc -Wall -W -O2 -Wl,--as-needed asneeded.c -ldl -lz -o
asneeded
olly@gemse:~$ ./asneeded zlibVersion
zlibVersion=(nil)
Can we safely leave them inside?
The patch is so ugly, but the libraries are not there anymore
https://github.com/LocutusOfBorg/wx/commit/e18d875c355096e458371d7f83910d02c926c294
A much cleaner way is just to add this to debian/rules instead of the
above changes:
export DEB_LDFLAGS_APPEND=-Wl,--as-needed
are you sure about this? Seems to be not working
DEB_LDFLAGS_APPEND=-Wl,--as-needed
and neither this
DEB_LDFLAGS_MAINT_APPEND=-Wl,--as-needed
(or at least I don't see them when building)
are them hidden?
cheers,
Gianfranco
Attached the log of the new debdiffs
Great, that looks much better to me. Thanks for all your work on this.
Cheers,
Olly
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738849: Please enable webview support for wx3.0
Il Venerdì 2 Maggio 2014 3:37, Olly Betts o...@survex.com ha scritto: On Fri, May 02, 2014 at 01:58:16AM +0100, Gianfranco LocutusOfBorg Costamagna wrote: I already added you export line at the bottom (please see my commit on github) https://github.com/LocutusOfBorg/wx/commit/15e8f7d106298109e58a2a3c8bf8add0b3001aa7 Hi again, One problem is that: +export DEB_LDFLAGS_APPEND=-Wl,--as-needed dpkg-buildflags --get LDFLAGS should be: +export DEB_LDFLAGS_APPEND=-Wl,--as-needed But it seems the real issue is actually that the export doesn't happen before the $(shell dpkg-buildflags --export=configure) gets expanded. A simple fix is to just specify it there directly: $(shell DEB_LDFLAGS_APPEND=-Wl,--as-needed dpkg-buildflags --export=configure) yes, that one did the trick, thanks! should be good enough :) so I also checked the webkitgtk build archs, and seems to be supported on every arch, but *not* on gnu hurd (failng to build) https://buildd.debian.org/status/package.php?p=webkitgtksuite=sid is this a problem? hurd shouldn't be a release architecture, and shouldn't prevent the testing migration. what do you think? I hope they'll fix soon the hurd build failure, thanks, Gianfranco Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699141:
Il Mercoledì 18 Giugno 2014 11:38, Dmitry Smirnov only...@debian.org ha scritto: On Wed, 18 Jun 2014 09:07:51 you wrote: Hi, the new get-orig-script should address this issue, sorry I wrote it prior to see your bug report I'm closing it now, feel free to reopen if you have an even better approach `get-orig-script` is a non-standard way to fetch source archive. It would be better if you implement it as get-orig-source target in debian/rules as mandated by policy §4.9. See more details in Sorry, the script is get-orig-source.sh I didn't include it in debian/rules file, to keep things clean (in my opinion, since this script isn't used when building or cleaning the package). Do you think I should add it again in rules file? Googling around I found many get-orig-source.sh scripts, all those packages are bugged then? I wrote it in this way starting from another debian package! https://www.google.it/search?client=ubuntuchannel=fsq=get-orig-source.shie=utf-8oe=utf-8gfe_rd=crei=vamhU6raOejW8gfAsIGoBw let me know if I need to merge it back in rules file Thanks for your answers Gianfranco http://wiki.debian.org/onlyjob/get-orig-source I think policy compliance matters for such case as it will be better to be able to get source archive in a unified manner. -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B --- No person, no idea, and no religion deserves to be illegal to insult, not even the Church of Emacs. -- Richard Stallman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743231: (no subject)
Now cmake 3.0 has been officially released (10 days ago) Would be really nice to start the transition to the new cmake program. of course I can help in mainining it, I already packaged it locally with no problems (just a problem with tests) Cheers, Gianfranco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752665: Please correct the link for backport-new mail
Source: ftp.debian.org Severity: normal When a package is uploaded in the backports-new queue the mail links to the new queue rather than the correct backport-new queue https://ftp-master.debian.org/backports-new.html this is the mail I got so far binary:libwxgtk-webview3.0-0-dbg is NEW. binary:libwxgtk-media3.0-dev is NEW. binary:libwxgtk-webview3.0-0 is NEW. binary:libwxgtk-media3.0-0 is NEW. binary:libwxbase3.0-dev is NEW. binary:libwxgtk3.0-dev is NEW. binary:libwxgtk3.0-0 is NEW. binary:libwxgtk-webview3.0-dev is NEW. binary:libwxbase3.0-0 is NEW. binary:wx3.0-i18n is NEW. binary:wx3.0-examples is NEW. binary:libwxgtk3.0-0-dbg is NEW. binary:wx3.0-headers is NEW. binary:libwxbase3.0-0-dbg is NEW. binary:libwxgtk-media3.0-0-dbg is NEW. source:wxwidgets3.0 is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will recieve an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html thanks Gianfranco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749395: Should the link be updated?
Hi debian release and vtk6 maintainers, Following up from an irc conversation on ftp and release channel I think the Ben file should be updated to is_good = .depends ~ libvtk6.1; thanks, Gianfranco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727553: New binwalk packaged
Hi Leo, today I did some work on the new binwalk release and uploaded on my personal git repository https://github.com/LocutusOfBorg/binwalk/ I didn't push to collab-maint, because I added myself as uploader, so I would like to have an ack for comaintaining. Unfortunately we cannot package 1.3.0 right now, because of the missing pyqtgraph in debian. Would you mind uploading this one? I also asked on irc about pyqtgraph in debian thanks, Gianfranco
