Re: 3Depict : upload request, bug #876620
Hi Sébastien, Your suggestion was correct - I was not aware of the --git-pristine-tar option. I don't think I would have found that option myself. I've pushed the history-rewritten changes, so the tag upstream/0.0.20 should now generate a byte-identical tarball. I've also re-tested this under cowbuilder. As an aside : Is there some discussion as to why this is an option, rather than the default? Hopefully this is right/usable now... On 15/10/17 14:46, Sébastien Villemot wrote: > Hi, > > On Sun, Oct 15, 2017 at 01:12:09PM +0100, D Haley wrote: > >> I rolled back history, and had to manually ssh in and hand edit the git >> repository on the remote, as pushing with --force is denied by the remote. >> [remote rejected] master->master (non fast-forward) >> >> I'm unable to get gbp to generate a byte-for-byte identical tarball, >> even if the contents are byte-for-byte identical when unpacked. I'm at a >> loss for what to do, as cloning the current repository >> >> $ gbp import-orig --pristine-tar ../3depict_0.0.20.orig.tar.gz >> What is the usptream version? [0.0.20] >> ... >> gbp:info Successfully imported version 0.0.20 of >> ../3depict_0.0.20.orig.tar.gz >> >> $ mv 3depict_0.0.20.orig.tar.gz 3depict_0.0.20.orig.tar.gz.real >> >> $ gbp buildpackage -S >> ... >> Ctrl+C >> >> $sha1sum *gz* >> > > It looks like you forgot to pass the --git-pristine-tar option to gbp > buildpackage. > >> Thanks, and apologies for taking up your time. > > No worry, I’m happy to help. > -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: 3Depict : upload request, bug #876620
Hi Sebastien, I rolled back history, and had to manually ssh in and hand edit the git repository on the remote, as pushing with --force is denied by the remote. [remote rejected] master->master (non fast-forward) I'm unable to get gbp to generate a byte-for-byte identical tarball, even if the contents are byte-for-byte identical when unpacked. I'm at a loss for what to do, as cloning the current repository $ gbp import-orig --pristine-tar ../3depict_0.0.20.orig.tar.gz What is the usptream version? [0.0.20] ... gbp:info Successfully imported version 0.0.20 of ../3depict_0.0.20.orig.tar.gz $ mv 3depict_0.0.20.orig.tar.gz 3depict_0.0.20.orig.tar.gz.real $ gbp buildpackage -S ... Ctrl+C $sha1sum *gz* This must be a bug in gbp (seems unlikely, but I can find no other explanation??), as it is not doing what it says it should? It claims it has successfully imported it (and yes it creates a new tag). There is no debian/ directory present (which AFAIK is correct). I've refrained from pushing this changeset, as I don't want to have to redo the remote history edit, for fear of breaking something. I'm really at a loss as to what to do - there are too many constraints I cannot satisfy simultaneously. This is either a problem with the tools or with my understanding of them - they do not appear to do the job they claim. I'm quite frustrated and have spent far too much time on this - I don't know what to do. Thanks, and apologies for taking up your time. On 27/09/17 13:13, Sébastien Villemot wrote: > On Wed, Sep 27, 2017 at 01:10:16AM +0100, D Haley wrote: >> Dear Sébastien, >> >> I have corrected d/control & d/copyright, as well as updating to compat >> 10. This has been pushed as f513233d7. gbp import-orig --pristine-tar >> has been used to import the upstream tarball, and have also been pushed. > > Thanks. However something is wrong with the upstream branch: it includes a > debian/ subdirectory. > > Please fix the upstream branch (possibly by writing history): it should > contain > exactly the files included in upstream tarball. Don't forget to update the > pristine-tar branch accordingly as needed. One should be able to recreate from > the git a tarball byte-to-byte identical to the upstream tarball. You can > check > that it works correctly by moving away your local copy of upstream tarball, > running "gbp buildpackage -S", and verify that the tarball it created is the > same as upstream tarball. > > Also please document all your changes in debian/changelog (at least adding the > bump to debhelper compat 10). > >> A quick question : Unless I'm mistaken, it seems that VCS-Git and >> VCS-Browser are the same (and this is reflected in debian-science >> policy). Is there a link to explain why we are duplicate this, so I can >> understand this a bit better? I'm assuming its to do with enforcing >> https transport? > > The two URLs are not exactly the same. Vcs-Browser has /cgit/ while Vcs-Git > has > /git/. > > Note that the Vcs-Git URL in your debian/control file is wrong, you should > replace /cgit/ by /git/. > > The Debian Science policy is also outdated on this issue, we should fix it. > > Thanks, > -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Re: 3Depict : upload request, bug #876620
Dear Sébastien, I have corrected d/control & d/copyright, as well as updating to compat 10. This has been pushed as f513233d7. gbp import-orig --pristine-tar has been used to import the upstream tarball, and have also been pushed. A quick question : Unless I'm mistaken, it seems that VCS-Git and VCS-Browser are the same (and this is reflected in debian-science policy). Is there a link to explain why we are duplicate this, so I can understand this a bit better? I'm assuming its to do with enforcing https transport? Thanks for the quick response. On 25.09.2017 14:52, Sébastien Villemot wrote: > Dear D Haley, > > On Mon, Sep 25, 2017 at 12:03:28AM +0100, D Haley wrote: > >> I would like to request an upload for the 3Depict package. The latest >> changeset (eae0c8c8a05c1) has been pushed to git.debian.org [1]. >> >> This updates the package to upstream version to 0.0.20, and also fixes a >> FTBFS bug due to a missing build-dep in sid. The package has been >> successfully built in cowbuilder. > > Please also update the pristine-tar branch, I can’t recreate the tarball > without it. > > The following changes should also be made: > - in d/control: use an https URL for Vcs-Git (instead of git://) > - in d/copyright: same for the Format field (per policy 4.0.0) > - upgrading to Debhelper compat level 10 would be nice, though not strictly > needed > > Best, > -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
3Depict : upload request, bug #876620
Dear Science-Mantainers, I would like to request an upload for the 3Depict package. The latest changeset (eae0c8c8a05c1) has been pushed to git.debian.org [1]. This updates the package to upstream version to 0.0.20, and also fixes a FTBFS bug due to a missing build-dep in sid. The package has been successfully built in cowbuilder. Thanks. [1] https://anonscm.debian.org/cgit/debian-science/packages/3depict.git/ -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#876620: 3depict: missing build dependency on rename
Hi, Thanks for the report. I've pushed a change to git [1] and will request a sponsor to upload the changes. Relevant changesets are: 95090e76 f5e5835b [1] https://anonscm.debian.org/cgit/debian-science/packages/3depict.git/ -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
3depict upload request 0.0.20
Dear Debian-science-maintainers, I have updated the 3depict package to 0.0.20 [1]. Is it possible to upload this (dd06f5) to experimental (as I understand this is the correct path, as we are in soft freeze). I have tested it with cowbuilder, and confirmed that the installed package functions locally on my machine. Thanks! [1] https://anonscm.debian.org/cgit/debian-science/packages/3depict.git/commit/?id=dd06f5b091afe68dd0e51ae5f1973b9e11afaa6b -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
3Depict upload
Dear Debian-science, I have recently updated the 3depict package on Alioth [1] to 0.0.19, and would like to request an upload. This closes an RC bug ( #831200 ). I have successfully cowbuilt the package, and it is (on my local system) lintian-clean. Thanks. [1] https://anonscm.debian.org/gitweb/?p=debian-science/packages/3depict.git P.S. - Is anyone else getting "Bad Object ID" when trying to use the VCS Browser on alioth, such as on the following link? https://anonscm.debian.org/gitweb/?p=debian-science/packages/3depict.git;a=commit;h=352ed974d7bf004a5a68ddacb3c7856b1b118518 -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#798858: blocked
Hi, I claim that this bug is blocked by mathgl, as mathgl has enabled c++11 support. I'm not a maintainer on that package anymore. Mathgl's C++11 support has been re-enabled in HEAD after closing 800460 by disabling C++11 support [1] (ie the fix is now reverted in head) . I've contacted the maintainer, should I wait for a response or ask for an NMU? Thanks [1] https://anonscm.debian.org/gitweb/?p=debian-science/packages/mathgl.git;a=commit;h=b10b6b515c426087120d3707997bf57a0807be81 -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#800460: Ping
Hi Dmitirios, Thanks for the quick response. My current opinion is that we should lock-step with the C++11 transition in Debian, which occurs with gcc6. https://wiki.debian.org/GCC5#Prepare_for_GCC_6 Otherwise, we are simply risking bugs like 798858, 800460 and 80953, as C++11 is not the Debian default at this time. On 21/01/16 12:00, Dimitrios Eftaxiopoulos wrote: > Hello Dave, > > > Στις Wednesday 20 of January 2016 18:18:28 γράψατε: >> Hi Dimitrios, >> >> >> It looks like there is still a problem with the latest git head. It >> seems that there may have been a mishap with the patching, and the patch >> has been reversed at some point? I can see in b7027842 that the C++11 >> has been set back to ON in the CMakeLists file. > > I did that intentionally, thinking that problems have been solved and we > should apply as many features as we can. It seems that this is not the case. > So I will do a new upload with the C++11 features disablesd in the CMakeLists > file. > >> >> I personally keep a debian/source/local-options file like so, to enforce >> patches-unapplied in my other repository: >> >> https://anonscm.debian.org/cgit/debian-science/packages/3depict.git/tree/deb >> ian/source/local-options?id=7fc15a0ad61ab38f0c1e4c1b2085dadf212d693c >> >> Last time I checked this was the recommended thing to do, as quilt + gbp >> dont play nicely together. >> >> I'm not totally clear what is going on here, but removing the .pc >> directory and going back to a patches-unapplied git seems to fix the >> problem for me. > > I started keeping the .pc directory some time ago, because I noticed that the > deletion of it somehow reverted the effect of the patches. I do not see any > side eefects up to now. > >> >> I dont want to push any changes until we agree on what both the cause of >> the problem and what the solution is. >> >> >> Thanks! > > Best regards > Dimitris > -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#800460: Ping
Hi Dimitrios, It looks like there is still a problem with the latest git head. It seems that there may have been a mishap with the patching, and the patch has been reversed at some point? I can see in b7027842 that the C++11 has been set back to ON in the CMakeLists file. I personally keep a debian/source/local-options file like so, to enforce patches-unapplied in my other repository: https://anonscm.debian.org/cgit/debian-science/packages/3depict.git/tree/debian/source/local-options?id=7fc15a0ad61ab38f0c1e4c1b2085dadf212d693c Last time I checked this was the recommended thing to do, as quilt + gbp dont play nicely together. I'm not totally clear what is going on here, but removing the .pc directory and going back to a patches-unapplied git seems to fix the problem for me. I dont want to push any changes until we agree on what both the cause of the problem and what the solution is. Thanks! -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#798858: Ref: FTBFS against mathgl 2.3.3
Hi, Thanks for the report. A quick glance suggests this may be related to a bug in mathgl (800460) . https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800460 I co-maintain mathgl, so I'll look at this on the weekend, when I have some time. -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#800460: mathgl: Test program fails to build, syntax error in header
Package: mathgl Version: 2.3.3-2 Severity: normal Hi All, A bit of a note-to-self (and Dimitrios, I guess). This report is due to some notice on the mathgl mailing list: https://groups.google.com/forum/?_escaped_fragment_=topic/mathgl/ioV2hTVfhq4#!topic/mathgl/ioV2hTVfhq4 The following program does not compile: #include int main() { mglGraph gr; gr.FPlot("sin(pi*x)"); gr.WriteFrame("test.png"); } $g++ --version g++ (Debian 4.9.2-10) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ g++ mathgl.cpp -o mathgl -lmgl -std=c++11 In file included from /usr/include/c++/4.9/complex.h:36:0, from /usr/include/mgl2/define.h:268, from /usr/include/mgl2/abstract.h:23, from /usr/include/mgl2/data_cf.h:23, from /usr/include/mgl2/data.h:23, from /usr/include/mgl2/mgl_cf.h:24, from /usr/include/mgl2/mgl.h:23, from mathgl.cpp:1: /usr/include/mgl2/define.h:277:19: error: unable to find numeric literal operator ‘operator""iF’ const mdual mgl_I=_Complex_I; ^ /usr/include/mgl2/define.h:277:19: note: use -std=gnu++11 or -fext-numeric-literals to enable more built-in suffixes In file included from /usr/include/mgl2/abstract.h:23:0, from /usr/include/mgl2/data_cf.h:23, from /usr/include/mgl2/data.h:23, from /usr/include/mgl2/mgl_cf.h:24, from /usr/include/mgl2/mgl.h:23, from mathgl.cpp:1: /usr/include/mgl2/data.h: In member function ‘void mglDataV::Fill(mreal, mreal, char)’: /usr/include/mgl2/data.h:611:6: error: ‘typeof’ was not declared in this scope if(mgl_isnum(x2)) ^ /usr/include/mgl2/data.h:611:6: error: ‘_a’ was not declared in this scope if(mgl_isnum(x2)) ^ /usr/include/mgl2/data.h:611:6: error: could not convert ‘({...})’ from ‘void’ to ‘bool’ if(mgl_isnum(x2)) ^ . And so on for quite a while. It looks like there are some typing problems in the headers. We should have a unit test to fix this. It renders the package relatively unusable. This may or may not be the cause of bug #798858 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798858 Thanks! -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages mathgl depends on: ii libc6 2.19-18 ii libgcc1 1:5.2.1-17 ii libgif4 4.1.6-11 ii libgl1-mesa-glx [libgl1] 10.3.2-1 ii libglu1-mesa [libglu1]9.0.0-2 ii libgsl0ldbl 1.16+dfsg-2 ii libhdf4-0 4.2.10-3 ii libhdf5-8 1.8.13+docs-15 ii libhpdf-2.2.1 2.2.1-1.1 ii libjpeg62-turbo 1:1.3.1-12 ii libltdl7 2.4.2-1.11 ii libmgl-qt7.4.02.3.3-2 ii libmgl7.4.0 2.3.3-2 ii libpng12-01.2.50-2+b2 ii libqt5core5a 5.4.2+dfsg-5 ii libqt5gui55.4.2+dfsg-5 ii libqt5printsupport5 5.4.2+dfsg-9 ii libqt5widgets55.4.2+dfsg-5 ii libstdc++65.2.1-17 ii zlib1g1:1.2.8.dfsg-2+b1 mathgl recommends no packages. mathgl suggests no packages. -- no debconf information -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#791173: libstxxl: library transition may be needed when GCC 5 is the default
Hi All, Apologies for being late to fix this bug. I had previously looked into it and from the above instructions, I had seen the bump was needed, but have only just had the time to work on this. I have contacted upstream to see which of the two options they would prefer. My preference is for a soname bump, but this risks being out of sync with upstream. I don’t think that is a major problem, as we can fix that on a future stxxl release, but if someone is willing to correct me here, let me know. Hopefully I will get a response, and should be able to tackle this next weekend. Thanks. -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
upload request : 3depict
Dear debian-science team, I have recently updated the 3depict package on alioth [1], and would like to request an upload if possible. I have successfully cowbuilt the package, and it is (on my local system) lintian-clean. Thanks. [1] https://anonscm.debian.org/gitweb/?p=debian-science/packages/3depict.git -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#764814: freecad downloads and executes code
Hi and thanks for the input, I think this bug is less about licencing, which is a large and complex issue, than a quick fix for code execution. Upstream can make their decisions about licencing. This is possibly not a debian question, and i feel somewhat tangential to this bug, and the issues in the other bug are still not entirely sorted. We have a technical solution that will work here. I think I disagree about the complexity of the SHA1 solution. I think it is very simple, and looks like the attached, which is incomplete. Notably, the other files need to be similarly patched, and the SHA1s need computing. Otherwise, the SSL solution could be achieved by using eg, the Requests library. Some discussion on this topic was had a while ago: https://lwn.net/Articles/582065/ Thanks! diff -r 58946a488476 src/Mod/Arch/ArchCommands.py --- a/src/Mod/Arch/ArchCommands.py Sun Oct 12 15:44:26 2014 +0100 +++ b/src/Mod/Arch/ArchCommands.py Sun Oct 12 15:49:30 2014 +0100 @@ -24,6 +24,8 @@ #*** import FreeCAD,Draft,ArchComponent,DraftVecUtils +import hashlib + from FreeCAD import Vector if FreeCAD.GuiUp: import FreeCADGui @@ -562,6 +564,13 @@ FreeCAD.Console.PrintMessage("downloading "+url+" ...\n") response = urllib2.urlopen(url) s = response.read() + sha = hashlib.sha1(s) + sha_found = sha.hexdigest() + + SHA1_EXPECTED_HEX="asdf" + if not sha_found = SHA1_EXPECTED : + return None + f = open(filepath,'wb') f.write(s) f.close() -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#764814: freecad downloads and executes code
Hi, and thanks for the quick response. I was unaware of the licensing issue - I don't really have an opinion on the licencing problem, but more the technical issue of unsigned code execution. Whilst you/upstream control the resource, freecad doesn't confirm that the download actually comes from said resource - python will not check this. An attacker can intercept the https initial handshake and impersonate the resource, as no signatures are checked. This is not hard if they control the network (eg public wifi/fake access point). I think there are several possible solutions, in varying orders of difficulty: * Hard-code a given .py git identifier, then check the downloads SHA1 or SHA1 _and_ MD5 after the download. Hard-code the matching SHA1 in the freecad sources. Convert the url stream into a binary stream and pass it to python's SHA1 module, then check the result. The downside is of course, this is not upgradeable. * Implement certificate checking in the freecad source, by locating and finding the debian certificates, parsing them and checking the provider's validity (pretty hard? I'm no python guru, but I understand the next python release will include certificate validation). Upgrades remain, but more complex. Slightly less serious suggestions : * Change freecad to use a different dxf backend (eg librecad's internal (BSD)) * Chance licence ;) Thanks! -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#764814: freecad downloads and executes code
Subject: freecad: Downloads and executes code Package: freecad Version: 0.14.3702+dfsg-2 Severity: important Dear Maintainer, As per discussions with the security team, I am marking the severity as grave. Freecad downloads and executes code (e.g. ArchCommands.py) from the network, from https. This uses urllib2, which does not check https certificates. The files that are downloaded occur when attempting to activate non-present module features, such as via opening a DXF file. Sample session console output: DXF libraries not found. Downloading... downloading https://raw.github.com/yorikvanhavre/Draft-dxf-importer/master/dxfColorMap.py ... downloading https://raw.github.com/yorikvanhavre/Draft-dxf-importer/master/dxfImportObjects.py ... downloading https://raw.github.com/yorikvanhavre/Draft-dxf-importer/master/dxfLibrary.py ... downloading https://raw.github.com/yorikvanhavre/Draft-dxf-importer/master/dxfReader.py ... I believe arbitrary code could be (theoretically) injected into these downloads, then executed. I am not an expert in such matters, and have not attempted to do so, so please review this for actual vulnerability (I may be wrong, and this could be mitigated in some other way). I would hazard that this vulnerability would be minor, due to the low-ish user base of freecad who are opening dxf files on untrusted networks. The file in question i believe to be : freecad-0.14.3702+dfsg/src/Mod/Arch/ArchCommands.py I further note that urllib is referenced in the following files: $ find ./ -type f -name \* -exec grep -H "urllib" {} \; | grep urlopen ./Tools/wiki2qhelp.py:from urllib2 import urlopen, HTTPError ./Tools/generateBase/generateDS.py:implFile = urllib2.urlopen(implUrl) ./Tools/generateBase/generateDS.py:##implFile = urllib2.urlopen(implUrl) ./Mod/Arch/ArchCommands.py:response = urllib2.urlopen(url) ./Mod/Start/StartPage/StartPage.py:xml = parse(urllib.urlopen(url)).getroot() Looking at generateDS.py, this may also be affected. I do not believe StartPage.py affected in the scope of this bug. Thanks! -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages freecad depends on: ii libboost-filesystem1.55.0 1.55.0+dfsg-2 ii libboost-program-options1.55.0 1.55.0+dfsg-3 ii libboost-regex1.55.01.55.0+dfsg-2 ii libboost-signals1.55.0 1.55.0+dfsg-3 ii libboost-system1.55.0 1.55.0+dfsg-2 ii libboost-thread1.55.0 1.55.0+dfsg-2 ii libc6 2.19-7 ii libcoin80 3.1.4~abc9f50-7 ii libfreeimage3 3.15.4-3+b2 ii libfreetype62.5.2-1 ii libgcc1 1:4.9.0-7 ii libgfortran34.9.0-7 ii libgl1-mesa-glx [libgl1]10.2.4-1 ii libglu1-mesa [libglu1] 9.0.0-2 ii libice6 2:1.0.9-1 ii liboce-foundation8 0.15-4 ii liboce-modeling80.15-4 ii liboce-ocaf-lite8 0.15-4 ii liboce-ocaf80.15-4 ii liboce-visualization8 0.15-4 ii libpyside1.21.2.2-1+b1 ii libpython2.72.7.8-3 ii libqt4-network 4:4.8.6+git49-gbc62005+dfsg-1 ii libqt4-opengl 4:4.8.6+git49-gbc62005+dfsg-1 ii libqt4-svg 4:4.8.6+git49-gbc62005+dfsg-1 ii libqt4-xml 4:4.8.6+git49-gbc62005+dfsg-1 ii libqt4-xmlpatterns 4:4.8.6+git49-gbc62005+dfsg-1 ii libqtcore4 4:4.8.6+git49-gbc62005+dfsg-1 ii libqtgui4 4:4.8.6+git49-gbc62005+dfsg-1 ii libqtwebkit42.2.1-7 ii libquadmath04.9.0-7 ii libshiboken1.2 1.2.2-1+b1 ii libsm6 2:1.2.2-1 ii libsoqt4-20 1.6.0~e8310f-1 ii libspnav0 0.2.2-1 ii libstdc++6 4.9.0-7 ii libx11-62:1.6.2-2 ii libxerces-c3.1 3.1.1-5 ii libxext62:1.3.2-1 ii libzipios++0c2a 0.1.5.9+cvs.2007.04.28-5.1 ii python-collada 0.4-2 ii python-matplotlib 1.3.1-2 ii python-pivy 0.5.0~v609hg-3 ii python-ply 3.4-3 ii python-pyside 1.2.2-1 ii python2.7 2.7.8-3 pn python:any ii zlib1g 1:1.2.8.dfsg-1 freecad recommends no packages. Versions of packages freecad suggests: pn freecad-doc -- no debconf information -- debian-science-maint
Bug#746609: Fwd: Re: 3depict: Please update to use wxwidgets3.0
Original Message Subject: Re: 3depict: Please update to use wxwidgets3.0 Date: Thu, 24 Jul 2014 23:18:55 +0100 From: D Haley To: Olly Betts Hi, No it has not been missed. I have been busy over the last few weekends with other non-debian things. I could have done it last week, but was decided to work on the upstream source as a priority (I am upstream). I don't fully understand the corect solution to the problem, as the program will compile against wx2.8 and wx3.0. I needed to do more work to check to see if I can libwxgtk2.8-dev | libwxgtk3.0-dev with these sources (later wx2.8 will be dropped, but not yet). If you are happy to NMU the change yourself, that would actually help. I was deferring it until I actually understood what I was doing, and kept putting it off. Cheers, and apologies for the delay. On 24/07/14 22:59, Olly Betts wrote: On Mon, Jun 16, 2014 at 11:49:42AM +0100, Olly Betts wrote: On Fri, Jun 13, 2014 at 07:06:05AM +, Debian Bug Tracking System wrote: 3depict (0.0.16-2) unstable; urgency=medium . * Add wx 3.0 startup patch (Closes: #746609) You've have indeed included such a patch, but you didn't update "Build-Depends" to use libwxgtk3.0-dev, so this bug isn't actually fixed: | Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.16.1~), libgl1-mesa-dev | libgl-dev, libpng-dev | libpng15-dev, libqhull-dev, libwxgtk2.8-dev, libftgl-dev, libxml2-dev, libmgl-dev (>= 2.0), automake I'm happy to NMU if that helps. It's been over a month without a response - I'm wondering if my previous message got missed because I only sent it to the ticket? Cheers, Olly -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#746609: possible patch
Hi, Thanks for the report. I was not able to exactly reproduce the problem that you describe. The startup tips show for myself, and then the program runs. This is true normally, in valgrind, and under gdb. However, I was able to reproduce the same symptoms, but with the autosave dialog. I have made a patch which fixes the die-on-autosave dialog problem for myself, and have similarly modified the startup tips as well. If you can confirm this fixes the startup problem for yourself (I've updated git [1]), then this would be great. Unless the transition is imminent, I will wait until the next upload to close this. [1] http://anonscm.debian.org/gitweb/?p=debian-science/packages/3depict.git;a=commit;h=1da7709cc8e3d0ecf03b72dd95e4e092a1a0eab1 -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#747211: scilab: Allow scilab gui to start without opengl
Package: scilab Version: 5.5.0-2 Severity: wishlist Dear Maintainer, Currently under testing, using virtualbox there are some problems with the vboxvideo driver, and thus full opengl support is difficult to access (software rendering only). This happens quite frequently on many systems, for various reasons. The module is installed, but cannot be used. https://www.virtualbox.org/ticket/12746 Thus it would be nice if scilab could start, and use opengl when only software rendering is available. I realise that this may be a complex reuquest, as this I am sure reaches deep into gluegen/jogl initialisation. For anyone searching, the following errors occur when launching scilab (scilab-bin, inside the do_scilex function). glxgears runs, but only with low framerates. libGL error: pci id for fd 4: 80ee:beef, driver (null) OpenGL Warning: Failed to connect to host. Make sure 3D acceleration is enabled for this VM. libGL error: core dri or dri2 extension not found libGL error: failed to load driver: vboxvideo I've attached a slightly redacted strace log. Thanks! -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages scilab depends on: ii scilab-cli 5.5.0-2 ii scilab-full-bin 5.5.0-2 Versions of packages scilab recommends: ii scilab-doc 5.5.0-2 Versions of packages scilab suggests: pn scilab-doc-fr pn scilab-doc-ja pn scilab-doc-pt-br -- no debconf information -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#745668: Really fixed?
+ layout2->addWidget(_enableUsageStatistics, 1, 0); It looks like it is still enabled by default? I might be wrong, as I am unfamiliar with QT's config file system. But its not clear what the default value is set to. As updates are handled by apt-get/aptitude, this should be disabled by default. There is no need to contact a remote server. -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#740553: libqhull: -dev package uninstallable
Package: libqhull6 Version: 2012.1-4 Severity: grave File: libqhull Justification: renders package unusable Dear Maintainer, -dev package appears to contain zero-byte files. Dpkg reports the following (Reading database ... 260712 files and directories currently installed.) Preparing to unpack libqhull-dev_2012.1-4_amd64.deb ... Unpacking libqhull-dev:amd64 (2012.1-4) ... dpkg: error processing archive libqhull-dev_2012.1-4_amd64.deb (--install): unable to open '/usr/include/libqhull/libqhull.h.dpkg-new': No such file or directory Errors were encountered while processing: libqhull-dev_2012.1-4_amd64.deb Attempting to force-all does nothing: LANG=C sudo dpkg --force-all -i libqhull-dev_2012.1-4_amd64.deb (Reading database ... 260712 files and directories currently installed.) Preparing to unpack libqhull-dev_2012.1-4_amd64.deb ... Unpacking libqhull-dev:amd64 (2012.1-4) ... dpkg: error processing archive libqhull-dev_2012.1-4_amd64.deb (--install): unable to install new version of `/usr/include/qhull/user.h': No such file or directory Errors were encountered while processing: libqhull-dev_2012.1-4_amd64.deb -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libqhull6:amd64 depends on: ii libc6 2.17-97 ii multiarch-support 2.17-97 libqhull6:amd64 recommends no packages. libqhull6:amd64 suggests no packages. -- no debconf information -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
ITP: tapsim -- Atom probe experiment simulator
Package: wnpp Severity: wishlist Owner: D Haley * Package name: tapsim Version : 1.0b.r766 Upstream Author : Christian Oberforfer http://www.uni-muenster.de/Physik.MP/Schmitz/en/tapsim/ * License : GPL Programming Lang: C, C++ Description : Atom probe experiment simulator Simulation package for Atom Probe measurements of samples with heterogenous evaporation properties. It allows the theoretical analysis of tips with arbitrary shape, with arbitrary atomic structure and well-defined chemical composition. In this regard, practically no limitations exist. Each tip atom is represented by a Wigner-Seitz cell. Sponsor is required. Plan to maintain as part of debian-science. -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#738339: libqhull-dev: qhull overflows stack with null outputs
Package: libqhull-dev Version: 2009.1-3 Severity: wishlist Dear Maintainer, For qhull>2012, the file pointer arguments for qh_new_qhull can no longer be null - this results in the program going into infinite recursion between qh_fprintf and qh_error, as qh_error tries to print, and qh_fprintf raises calls the error function, as the output pointer is null. The output looks like the following, when running under valgrind, where indicates clipped output: QH6232 Qhull internal error (userprintf.c): fp is 0. Wrong qh_fprintf called. . QH6232 Qhull internal error (userprintf.c): fp is 0. Wrong qh_fprintf called. QH6232 Qhull internal error (userprintf.c): fp is 0. Wrong qh_fprintf called. ==11016== Stack overflow in thread 1: can't grow stack to 0xffef01ff8 For completeness, I am including this link, which states that in previous versions of qhull ( <2011.2) passing NULL triggered a bug. http://permalink.gmane.org/gmane.comp.gnu.octave.maintainers/25693 Thanks. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libqhull-dev depends on: ii libqhull5 2009.1-3 libqhull-dev recommends no packages. libqhull-dev suggests no packages. -- no debconf information -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#737653: missing URL
Hi Looks like I left out the upstream URL. The file I am referring to is here [1] , and the compilation error is: g++ tetcall.cxx -o tetcall -ltet ... tetcall.cxx:190:42: error: cannot convert ‘const char*’ to ‘tetgenbehavior*’ for argument ‘1’ to ‘void tetrahedralize(tetgenbehavior*, tetgenio*, tetgenio*, tetgenio*, tetgenio*)’ tetrahedralize("pq1.414a0.1", &in, &out); ^ ... Forcing a define for TETLIBRARY gives (as to be expected) a link error from a missing definition. Thanks! [1] http://wias-berlin.de/software/tetgen/files/tetcall.cxx -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#737653: libtet1.5-dev: consider enabling TETLIBRARY define
Package: libtet1.5-dev Version: 1.5.0-1 Severity: normal Dear Maintainer, libtet appears to be compiled without TETLIBRARY defined. The example from upstream ( ) does not compile due to this (aside from other minor upstream errors). TETLIBRARY is required for the library interface, and is located in /usr/include/tetgen.h:23. This is needed to allow for calling using the lib interface mode, as suggested by upstream. Could this be enabled for future releases? Thanks! -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libtet1.5-dev depends on: ii libtet1.5 1.5.0-1 libtet1.5-dev recommends no packages. libtet1.5-dev suggests no packages. -- no debconf information -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers