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#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
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 none
ii zlib1g 1:1.2.8.dfsg-1
freecad recommends no packages.
Versions of packages freecad suggests:
pn freecad-doc none
-- no debconf information
--
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 my...@gmx.com To: Olly Betts o...@survex.com 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#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
ITP: tapsim -- Atom probe experiment simulator
Package: wnpp Severity: wishlist Owner: D Haley my...@gmx.com * Package name: tapsim Version : 1.0b.r766 Upstream Author : Christian Oberforfer oberdorc muenster * URL : 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#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
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
