Bug#665481: postfix: postlog segfaults on --help
Package: postfix Version: 2.7.1-1+squeeze1 Severity: normal I wondered what "postlog" does, so I ran it with the --help argument. This causes a segfault: postlog[6737]: segfault at 0 ip 7f576e168322 sp 7fff85f0fd90 error 4 in libpostfix-util.so.1.0.1[7f576e145000+33000] I realize postlog might not have "--help" functionality, but it shouldn't segfault. I guess this is really an upstream problem, but I thought I'd report it anyway. -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core) 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 postfix depends on: ii adduser 3.112+nmu2 add and remove users and groups ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy ii dpkg1.15.8.12Debian package management system ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib ii libdb4.84.8.30-2 Berkeley v4.8 Database Libraries [ ii libsasl2-2 2.1.23.dfsg1-7 Cyrus SASL - authentication abstra ii libssl0.9.8 0.9.8o-4squeeze7 SSL shared libraries ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip ii netbase 4.45 Basic TCP/IP networking system ii ssl-cert1.0.28 simple debconf wrapper for OpenSSL Versions of packages postfix recommends: ii python 2.6.6-3+squeeze6 interactive high-level object-orie Versions of packages postfix suggests: ii bsd-mailx [mail-re 8.1.2-0.20100314cvs-1 simple mail user agent ii emacs23-nox [mail- 23.2+1-7 The GNU Emacs editor (without X su ii libsasl2-modules 2.1.23.dfsg1-7Cyrus SASL - pluggable authenticat ii mutt [mail-reader] 1.5.20-9+squeeze2 text-based mailreader supporting M pn postfix-cdb(no description available) pn postfix-ldap (no description available) pn postfix-mysql (no description available) pn postfix-pcre (no description available) pn postfix-pgsql (no description available) ii procmail 3.22-19 Versatile e-mail processor pn resolvconf (no description available) pn sasl2-bin (no description available) pn ufw(no description available) -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#861649: RFS: gudhi/2.0.0+dfsg-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "gudhi" * Package name: gudhi Version : 2.0.0+dfsg-1 Upstream Author : Gudhi Project / INRIA * URL : http://gudhi.gforge.inria.fr/ * License : GPL3+ Section : math It builds these binary packages: gudhui - Generic open source C++ library for Topological Data Analysis libgudhi-dev - Generic open source C++ library for Topological Data Analysis libgudhi-doc - Generic open source C++ library for Topological Data Analysis libgudhi-examples - Generic open source C++ library for Topological Data Analysis python3-gudhi - Generic open source C++ library for Topological Data Analysis (I now notice that I've been duplicating my short package descriptions. This will be fixed.) GUDHI is primarily a C++ header-only template library for computations in the mathematical field of topological data analysis. The C++ template library is in libgudhi-dev, and its documentation (built by Doxygen) is in libgudhi-doc. The -examples package contains upstream's example programs (both source and compiled). python3-gudhi contains the package's Python (3) interface. Upstream's GUI tool for a small part of the library functionality is in the package gudhui. The latter program is perhaps of questionable quality. The package contains an autopkgtest test suite that leverages upstream's tests of the Python interface. During my RFS for version 1.3.1 of this package (#840739), concern was voiced over unclear licensing terms for some of upstream's files. I believe I have rectified this now. In particular, the DFSG-repacked tarball removes a lot of example data files under unclear licensing as shipped by upstream. The package includes the following patches: 0001-Disable-some-tests-that-uncleanly-write-outside-of-t.patch - Some of upstream's tests write all over the place. These have been disabled for now. 0002-Disable-tests-that-use-DFSG-deleted-data-files.patch - Some of upstream's tests use the unclearly licensed data files that were removed for the DFSG tarball. Disable these. 0003-Force-Python-3-detection-to-avoid-mixing-2-and-3.patch - Upstream's build system gets confused if a Python 2 interpreter and Cython 3 are both present. Work around this by looking only for version 3 of both. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/gudhi Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/gudhi/gudhi_2.0.0+dfsg-1.dsc Regards, Gard Spreemann
Bug#840739: RFS: gudhi/1.3.1+ds-1 [ITP]
On Wednesday, 8 February 2017 18:46:46 CET Roger Shimizu wrote: > Dear Gard, > > I cannot sponsor the upload. But here's my review that I hope it's helpful. Dear Roger, Thank you very much for your helpful feedback. I believe I have rectified some of the below. > Here're the items need to be fixed: > - missing in debian/copyright, not GPL-3+ license: > cmake/modules/FindEigen3.cmake > cmake/modules/FindTBB.cmake > include/gudhi/Contraction/CGAL_queue/*.h > data/points/COIL_database/images/* > doc/*/*.png > Better to ask upstream to confirm license of those image files. > Usually license of image files is different from the code. If it's not > sure simply remove it from "debian source" repack. Good catch! I'm sorry for overlooking this. I'll get to work clarifying the licenses and/or stripping out these. > - lintian reports: > I: libgudhi-dev: spelling-error-in-copyright unneccessary unnecessary Fixed. > Other comments, nice to have: > - it's more convenient if you can export your work to some modern > SCM, such as git >the review will be easier if doing with such SCM >you can omit the final releasing commit, so if there's something > still need to work, you don't have to push forcefully. Done; https://git.nonempty.org/debian-gudhi/ > - add Vcs-* line to d/control (depends on the above item) Done. > - bump to debhelper 10 Done. > - wrap and sort Build-Depends & Depends list in d/control Done. > - have separated -doc package The documentation shipped with upstream's source is rather limited. They instead ship a dedicated tarball for documentation [1]. I intend to package it too, and have it provide the -doc package. Does this sound sensible to you? > - In favor of https URL over http in debian/copyright Done (for the copyright format URL; upstream's website is not on HTTPS). > So far it's enough for now. Thanks! I'll upload a new version to mentors.debian.net when I hear back from upstream regarding the missing copyrights. [1] https://gforge.inria.fr/frs/download.php/file/ 36176/2016-09-12-16-12-33_GUDHI_DOC_1.3.1.tar.gz Best, Gard
Bug#840739: RFS: gudhi/1.3.1+ds-1 [ITP]
On Wednesday, 8 February 2017 20:47:07 CET Gard Spreemann wrote: > On Wednesday, 8 February 2017 18:46:46 CET Roger Shimizu wrote: > > > > - have separated -doc package > > The documentation shipped with upstream's source is rather > limited. They instead ship a dedicated tarball for documentation > [1]. I intend to package it too, and have it provide the -doc > package. > > Does this sound sensible to you? Scratch that. My package now generates the doxygen documentation and builds a -doc package. > I'll upload a new version to mentors.debian.net when I hear back > from upstream regarding the missing copyrights. Upstream say they will take into account my remarks regarding licensing for the next release. I'll upload a new version to mentors when that happens. The version on https://git.nonempty.org/debian-gudhi/ has diverged a bit from the mentors one meanwhile. Most importantly, it now builds a -doc and an -examples package. Any comments would be greatly appreciated. Best regards, Gard
Bug#778635: L-BFGS-B now in Debian
The L-BFGS-B library in question is now in Debian as liblbfgsb0 and
liblbfgsb-dev.
Removing the relevant source files from scipy/optimize/setup.py and
adding lbfgsb to the list of libraries to link to seems to work fine,
and the relevant tests still pass. I did
-sources = ['lbfgsb.pyf', 'lbfgsb.f', 'linpack.f', 'timer.f']
+sources = ['lbfgsb.pyf']
+libs = lapack.setdefault('libraries', [])
+libs.append('lbfgsb')
+lapack['libraries'] = libs
which obviously is confusing name-wise, but works.
With this change, one gets rid of an embedded copy of both lbfgsb and
Linpack.
See also #811069.
Best,
Gard
Bug#811073: RFS: lbfgsb/3.0-1 [ITP]
On Friday 25 March 2016 18:56:40 Gianfranco Costamagna wrote: > Hi, Hi, and thanks for the feedback! > something needs changes: > - std-version= 3.9.7 Yep, I'll update that. > - no watch file? I didn't make one since upstream's tarball (at least for the latest version) contains precompiled binaries, as well as a few files outside of any directory (a little tarbomb). It is my understanding that these need to be stripped out of the Debian source. Should I make a script for that and have uscan run it? Upstream has a very slow release cycle, and it is my impression that the library is more or less "done". Is a watch file still important? > - no sane build system, why are you building the library such way? There is no build system upstream. How should I best approach this issue? > you seem to use just two files in your library, why everything is dropped? The following source files are not used: - blas.f: We use the system libblas instead of this bundled copy. - driver*.f*: These are demonstration files for how to use the library, and are therefore not compiled. Should they be installed as example source files somewhere? - linpack.f: We use the system liblapack instead of this bundled LINPACK. See also debian/patches/replace-linpack-with-lapack.patch. That leaves only lbfgsb.f and timer.f, as you say. The former contains the entire substance of the library. > I don't think flags in rules are actually evaluated, because you > don't set them Thank you, I'll look into that. > - dbg package is useless now that we have ddbg automatic generation. Will fix. Thanks. Best, Gard
Bug#811073: RFS: lbfgsb/3.0-1 [ITP]
On Wednesday 30 March 2016 14:27:45 Gianfranco Costamagna wrote: > HI, > > >I didn't make one since upstream's tarball (at least for the latest > >version) contains precompiled binaries, as well as a few files outside > >of any directory (a little tarbomb). It is my understanding that these > >need to be stripped out of the Debian source. Should I make a script > >for that and have uscan run it? > > > >Upstream has a very slow release cycle, and it is my impression that > >the library is more or less "done". Is a watch file still important? > > Filex-Excluded copyright keyword might become handy. I see. I was under the impression that was only to be used when files are excluded for copyright reasons. I repackaged the upstream tarball because it included binaries (compiled from the source, one presumes) and some metadata - not necessarily things that are problematic in a copyright sense. > please consider, other people might have to understand how did you > do the work, and redo it. That makes a lot of sense, yes. > >There is no build system upstream. How should I best approach this > >issue? > > add one :) This'll be more work, so I'll have to postpone it a bit. The build seems a bit trivial for a whole generic system to be added, doesn't it? > >- blas.f: We use the system libblas instead of this bundled copy. > > nice indeed > > >- driver*.f*: These are demonstration files for how to use the > > > > library, and are therefore not compiled. Should they be installed > > as example source files somewhere? > > a package-examples might be trivial to add now, but you are the maintainer > you have to know your users' expectations. If you think an example > packages is useful you can add it. I think they'll be useful, yes. I'll get around to adding that.
Bug#811073: RFS: lbfgsb/3.0-1 [ITP]
On Friday 25 March 2016 18:56:40 Gianfranco Costamagna wrote: > something needs changes: > - std-version= 3.9.7 > - no watch file? > - no sane build system, why are you building the library such way? > you seem to use just two files in your library, why everything is dropped? > I don't think flags in rules are actually evaluated, because you don't set > them - dbg package is useless now that we have ddbg automatic generation. > > Please address/comment/fix the above, and I'll do another spin http://mentors.debian.net/debian/pool/main/l/lbfgsb/lbfgsb_3.0-2.dsc addresses the standards-version and the dbg package. I'll have to work on the watch file and (if needed) the build system. As for the flags: When I debuild, I see gfortran -g -O2 -fstack-protector-strong -fPIC -o build/lbfgsb.o -c lbfgsb.f so it seems the flags are taken into account. Am I mistaken? Thanks again for the help. Best, Gard
Bug#819968: xul-ext-https-everywhere: Change dependency from iceweasel to firefox or firefox-esr
Package: xul-ext-https-everywhere Version: 5.1.1-2 Severity: minor Dear Maintainer, With #815006 reintroducing Firefox, xul-ext-https-everywhere should no longer depend on/enhance iceweasel, but rather on firefox | firefox-esr. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xul-ext-https-everywhere depends on: ii iceweasel 45.0.1esr-1 xul-ext-https-everywhere recommends no packages. xul-ext-https-everywhere suggests no packages. -- no debconf information
Bug#811073: RFS: lbfgsb/3.0-1 [ITP]
On Wednesday 30 March 2016 18:31:48 Gianfranco Costamagna wrote: > Hi > > >http://mentors.debian.net/debian/pool/main/l/lbfgsb/lbfgsb_3.0-2.dsc > >addresses the standards-version and the dbg package. I'll have to work > >on the watch file and (if needed) the build system. > > ok, let me know when the other points are addressed, and I'll grab it :) > (please call it always -1, until it goes in unstable/new queue) Hi again, I believe I've addressed the issues you raised now (3.0+dfsg.1-1, [1]). The watch file with repacking currently does *not* use Files-Excluded, but rather Ben Finney's repack scripts [2]. I'm guessing the Files-Excluded method is preferable, but I wasn't thinking straight when I made the change. Please let me know if it's preferable to have it that way. [1] https://mentors.debian.net/debian/pool/main/l/lbfgsb/lbfgsb_3.0+dfsg.1-1.dsc [2] https://wiki.debian.org/BenFinney/software/repack Best, Gard
Bug#778635: python-scipy bundles library for L-BFGS-B minimization
Source: python-scipy Severity: wishlist Tags: upstream Dear Maintainer, python-scipy bundles Fortran code for L-BFGS-B minimization in scipy/optimize/lbfgsb/*.f. The code comes from outside the SciPy project [1], and I believe it is useful as a standalone library and that the python-scipy package should remove the included copy. Additionally, the included copy of lbfgsb bundles its own copy of LINPACK, which as far as I understand is deprecated in favor of LAPACK. Following this bugreport I propose a patch for lbfgsb that makes it use the system LAPACK instead. [1] http://users.iems.northwestern.edu/~nocedal/lbfgsb.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#778635: python-scipy bundles library for L-BFGS-B minimization
Patch against upstream lbfgsb (needs packaging) that replaces its bundled
LINPACK with LAPACK.
--- a/lbfgsb.f
+++ b/lbfgsb.f
@@ -1185,7 +1185,8 @@
p(i2) = v(i2) + sum
20 continue
c Solve the triangular system
- call dtrsl(wt,m,col,p(col+1),11,info)
+c call dtrsl(wt,m,col,p(col+1),11,info)
+ call dtrtrs('U', 'T', 'N', col, 1, wt, m, p(col+1), col, info)
if (info .ne. 0) return
c solve D^(1/2)p1=v1.
@@ -1197,7 +1198,8 @@
c[ 0 J' ] [ p2 ] [ p2 ].
c solve J^Tp2=p2.
- call dtrsl(wt,m,col,p(col+1),01,info)
+c call dtrsl(wt,m,col,p(col+1),01,info)
+ call dtrtrs('U', 'N', 'N', col, 1, wt, m, p(col+1), col, info)
if (info .ne. 0) return
c compute p1=-D^(-1/2)(p1-D^(-1/2)L'p2)
@@ -2135,7 +2137,8 @@
cfirst Cholesky factor (1,1) block of wn to get LL'
c with L' stored in the upper triangle of wn.
- call dpofa(wn,m2,col,info)
+c call dpofa(wn,m2,col,info)
+ call dpotrf('U', col, wn, m2, info)
if (info .ne. 0) then
info = -1
return
@@ -2143,7 +2146,8 @@
cthen form L^-1(-L_a'+R_z') in the (1,2) block.
col2 = 2*col
do 71 js = col+1 ,col2
- call dtrsl(wn,m2,col,wn(1,js),11,info)
+c call dtrsl(wn,m2,col,wn(1,js),11,info)
+ call dtrtrs('U', 'T', 'N', col, 1, wn, m2, wn(1,js), col, info)
71 continue
c Form S'AA'S*theta + (L^-1(-L_a'+R_z'))'L^-1(-L_a'+R_z') in the
@@ -2158,7 +2162,8 @@
c Cholesky factorization of (2,2) block of wn.
- call dpofa(wn(col+1,col+1),m2,col,info)
+c call dpofa(wn(col+1,col+1),m2,col,info)
+ call dpotrf('U', col, wn(col+1,col+1), m2, info)
if (info .ne. 0) then
info = -2
return
@@ -2227,7 +2232,8 @@
c Cholesky factorize T to J*J' with
cJ' stored in the upper triangle of wt.
- call dpofa(wt,m,col,info)
+c call dpofa(wt,m,col,info)
+ call dpotrf('U', col, wt, m, info)
if (info .ne. 0) then
info = -3
endif
@@ -3208,12 +3214,14 @@
m2 = 2*m
col2 = 2*col
- call dtrsl(wn,m2,col2,wv,11,info)
+c call dtrsl(wn,m2,col2,wv,11,info)
+ call dtrtrs('U', 'T', 'N', col2, 1, wn, m2, wv, col2, info)
if (info .ne. 0) return
do 25 i = 1, col
wv(i) = -wv(i)
25 continue
- call dtrsl(wn,m2,col2,wv,01,info)
+c call dtrsl(wn,m2,col2,wv,01,info)
+ call dtrtrs('U', 'N', 'N', col2, 1, wn, m2, wv, col2, info)
if (info .ne. 0) return
c Compute d = (1/theta)d + (1/theta**2)Z'W wv.
Bug#778635: Patch to silence lbfgsb
If the lbfgsb bundled with python-scipy is replaced with a separate package, the latter should receive something like the following patch, which is included in the SciPy-bundled version of lbfgsb per https://github.com/scipy/scipy/issues/2261 (Synopsis: There are a few places in the lbfgsb code where the no-printing flag is ignored.) --- a/lbfgsb.f +++ b/lbfgsb.f @@ -2550,7 +2550,9 @@ if (gd .ge. zero) then c the directional derivative >=0. c Line search is impossible. -write(6,*)' ascent direction in projection gd = ', gd +if (iprint .ge. 0) then + write(6,*)' ascent direction in projection gd = ', gd +endif info = -4 return endif @@ -3279,8 +3281,10 @@ 55 continue if ( dd_p .gt.zero ) then call dcopy( n, xp, 1, x, 1 ) - write(6,*) ' Positive dir derivative in projection ' - write(6,*) ' Using the backtracking step ' + if (iprint .ge. 0) then +write(6,*) ' Positive dir derivative in projection ' +write(6,*) ' Using the backtracking step ' + endif else go to 911 endif
Bug#800603: network-manager: NetworkManager segfaults because of null pointer dereferencing when terminating
Package: network-manager
Version: 1.0.6-1
Severity: normal
Dear Maintainer,
On my system, NetworkManager segfaults when terminating, for example
when the system shuts down or when the service is stopped or restarted
by the user.
A backtrace reveals that the segfault is caused by null pointer
dereferencing on line 776 of src/nm-manager.c. Nearby code is
static void
check_if_startup_complete (NMManager *self)
{
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
GSList *iter;
if (!priv->startup) // <--- Line 776.
return;
and a core dump reveals that priv is in fact a null pointer when
"systemctl stop network-manager.service" is issued on my system.
NM seems otherwise to work as normal, and I have only seen the
segfault when it is asked to terminate. I have not had time to
investigate any further.
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages network-manager depends on:
ii adduser3.113+nmu3
ii dbus 1.10.0-3
ii init-system-helpers1.23
ii isc-dhcp-client4.3.3-3
ii libbluetooth3 5.33-1
ii libc6 2.19-22
ii libdbus-1-31.10.0-3
ii libdbus-glib-1-2 0.102-1
ii libglib2.0-0 2.44.1-1.1
ii libgnutls-deb0-28 3.3.17-1
ii libgudev-1.0-0 230-2
ii libmm-glib01.4.10-1
ii libndp01.4-2
ii libnewt0.520.52.18-1+b1
ii libnl-3-2003.2.26-1
ii libnl-genl-3-200 3.2.26-1
ii libnl-route-3-200 3.2.26-1
ii libnm0 1.0.6-1
ii libpam-systemd 226-3
ii libpolkit-agent-1-00.105-12
ii libpolkit-gobject-1-0 0.105-12
ii libreadline6 6.3-8+b3
ii libsoup2.4-1 2.50.0-2
ii libsystemd0226-3
ii libteamdctl0 1.18-1
ii libuuid1 2.27-3
ii lsb-base 9.20150917
ii policykit-10.105-12
ii udev 226-3
ii wpasupplicant 2.3-2.1
Versions of packages network-manager recommends:
ii crda3.13-1
ii dnsmasq-base2.75-1
ii iptables1.4.21-2+b1
ii iputils-arping 3:20121221-5+b2
ii modemmanager1.4.10-1
ii ppp 2.4.6-3.1
Versions of packages network-manager suggests:
ii avahi-autoipd 0.6.31-5
pn libteam-utils
-- no debconf information
Bug#766738:
On Wed, 29 Oct 2014 19:22:51 +0100 (CET) Daniel Gröber wrote: > Hey, > > I finished packaging ghc-mod-5.1.1.0 and it's dependencies, see: > [1]. I also uploaded a build for Gard to test here [2] (I hope it's > the right arch). Hey. Great. I've already tested 5.1.1.0 built locally, and memory usage is much better than with 4.1.2. Thanks. -- Gard Spreemann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766738: ghc-mod: Uses hundreds of MB of memory per open file in Emacs
Package: ghc-mod Version: 4.1.2-2 Severity: important Tags: upstream Dear Maintainer, When used with Emacs, ghc-mod 4.1.2-2 will, unlike versions < 4, consume hundreds of MB of memory *per open file* in many cases. For many, this will be a serious regression from earlier versions, making ghc-mod's Emacs integration practically useless. The problem is known upstream [1], and seems to be (at least partly) rectified in ghc-mod 5.x. The latter is not packaged in Debian, and does introduce a few new dependencies that are also not packaged in Debian. Since Emacs integration is a (the?) major feature of ghc-mod, should perhaps ghc-mod be downgraded to 3.x, or upgraded to 5.x, before Jessie? [1] https://github.com/kazu-yamamoto/ghc-mod/issues/243 -- System Information: Debian Release: jessie/sid APT prefers utopic-updates APT policy: (500, 'utopic-updates'), (500, 'utopic-security'), (500, 'utopic') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-23-generic (SMP w/2 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 ghc-mod depends on: ii haskell-mode 13.10-2 ii libc6 2.19-10ubuntu2 ii libffi6 3.1-2 ii libgmp10 2:6.0.0+dfsg-4build1 Versions of packages ghc-mod recommends: ii ghc 7.6.3-19 ghc-mod suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766738: Request to Join Project pkg-haskell from Daniel Gröber (dxld-guest)
On Saturday 25. October 2014 15:02:46 Joachim Breitner wrote: > Am Samstag, den 25.10.2014, 14:47 +0200 schrieb Gard Spreemann: > > Hi. I've newly subscribed to the list, and reported 766738. If there's > > anything I can do to help with resolving it, please let me know. > > sure. You mention that that ghc-mod 5.x has fixed it, and introduces new > dependencies. If you can identify those, and check that we can upgrade > them without having to upgrade too many unrelated packages, that would > be helpful. I should have made this clearer, but I haven't actually checked yet. The changelog for 5.0.0 does, however, say "ghc-mod consumes much less memory than ghc-mod-4.1". I'll try to get it tested soon. > You can use the haskell-package-plan software to find that out: > http://anonscm.debian.org/gitweb/?p=pkg-haskell/package-plan.git;a=summary > > There is a README.md, I hope it is sufficient to get you started with > the tool. I haven't had time to do what you suggest in detail, but from a cursory manual look, I can see that ghc-mod 5.1.1.0 introduces these new dependencies (over 4.1.2): - async - data-default - djinn-ghc - ghc-paths - haskell-src-exts - monad-journal - pretty - split - text - transformers-base Of these, it seems to me at first glance that only djinn-ghc and monad-journal are not in Sid. The latter has no unpackaged dependencies, while the former needs djinn-lib. In summary, if I'm not missing anything, ghc-mod 5.1.1.0 would need to have djinn-ghc, djinn-lib and monad-journal packaged. -- Gard Spreemann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#766738: Request to Join Project pkg-haskell from Daniel Gröber (dxld-guest)
Hi again. On Saturday 25. October 2014 19:20:27 Joachim Breitner wrote: > Am Samstag, den 25.10.2014, 18:45 +0200 schrieb Gard Spreemann: > > I should have made this clearer, but I haven't actually checked yet. The > > changelog for 5.0.0 does, however, say "ghc-mod consumes much less memory > > than ghc-mod-4.1". I'll try to get it tested soon. > > ok, please do. I've checked now. The situation with 5.1.1.0 is much better: For me, RSS is around 150 MB per file. With 4.1.2-2 it was about 300-500 MB. For me, and others on relatively low end systems, this is could be the difference between "annoying but acceptable" and "useless". For the record: I don't know what the situation was with 3.x, but it I doubt it used a lot of memory - at least I didn't notice it. [Off topic: Does anybody know why it's necessary to spawn a new ghc-modi process for every open file? I'm sure upstream has a good reason since the memory usage is a known problem, but I'm curious…] -- Gard Spreemann -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#810122: xul-ext-firegestures: Firegestures no longer recognizes any gestures
Package: xul-ext-firegestures Version: 1.10-2 Severity: grave Justification: renders package unusable Dear Maintainer, After a recent Iceweasel upgrade from 38.5.0esr-1 to 43.0.2-1+b1, the Fireguestures extension no longer does anything. The standard swipe guestures seem to be recognized, but nothing happens. Also the extension configuration dialogs now contain a lot of empty dropdown menus, effectively disallowing any meaningful configuration changes. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xul-ext-firegestures depends on: ii iceweasel 43.0.2-1+b1 xul-ext-firegestures recommends no packages. xul-ext-firegestures suggests no packages. -- no debconf information
Bug#810626: plasma-workspace: plasmashell leaks memory
Package: plasma-workspace Version: 4:5.4.3-1 Severity: important Tags: upstream fixed-upstream Dear Maintainer, plasmashell seems to leak memory. After three days of intermittent use, the process' RSS is 800 MB, many times higher than what it was a few days ago. The upstream bug report [1] indicates (comment 108) that the problem is resolved in 5.5.2. [1] https://bugs.kde.org/show_bug.cgi?id=344879 -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages plasma-workspace depends on: ii dbus-x111.10.6-1 ii frameworkintegration5.16.0-1 ii gdb-minimal [gdb] 7.10-1 ii kactivities 5.16.0-1 ii kde-cli-tools 4:5.4.3-1 ii kded5 5.16.0-1 ii kinit 5.16.0-1 ii kio 5.16.0-1 ii libc6 2.21-6 ii libcln6 1.3.4-1 ii libdbusmenu-qt5-2 0.9.3+15.10.20150604-1 ii libgcc1 1:5.3.1-5 ii libgps223.15-2 ii libice6 2:1.0.9-1+b1 ii libkf5activities5 5.16.0-1 ii libkf5auth5 5.16.0-1 ii libkf5baloo55.16.0-1 ii libkf5bookmarks55.16.0-1 ii libkf5completion5 5.16.0-1 ii libkf5configcore5 5.16.0-1 ii libkf5configgui55.16.0-1 ii libkf5configwidgets55.16.0-1 ii libkf5coreaddons5 5.16.0-1 ii libkf5crash55.16.0-1 ii libkf5dbusaddons5 5.16.0-1 ii libkf5declarative5 5.16.0-1 ii libkf5globalaccel-bin 5.16.0-1 ii libkf5globalaccel5 5.16.0-1 ii libkf5guiaddons55.16.0-1 ii libkf5i18n5 5.16.0-1 ii libkf5iconthemes5 5.16.0-1 ii libkf5idletime5 5.16.0-1 ii libkf5itemviews55.16.0-1 ii libkf5jobwidgets5 5.16.0-1 ii libkf5js5 5.16.0-1 ii libkf5jsembed5 5.16.0-1 ii libkf5kdelibs4support5 5.16.0-1 ii libkf5kiocore5 5.16.0-1 ii libkf5kiofilewidgets5 5.16.0-1 ii libkf5kiowidgets5 5.16.0-1 ii libkf5networkmanagerqt6 5.16.0-1 ii libkf5newstuff5 5.16.0-1 ii libkf5notifications55.16.0-1 ii libkf5notifyconfig5 5.16.0-1 ii libkf5package5 5.16.0-1 ii libkf5plasma5 5.16.0-1 ii libkf5plasmaquick5 5.16.0-1 ii libkf5quickaddons5 5.16.0-1 ii libkf5runner5 5.16.0-1 ii libkf5screen6 4:5.4.3-1 ii libkf5service-bin 5.16.0-1 ii libkf5service5 5.16.0-1 ii libkf5solid55.16.0-1 ii libkf5su5 5.16.0-1 ii libkf5texteditor5 5.16.0-1 ii libkf5textwidgets5 5.16.0-1 ii libkf5wallet-bin5.16.0-1 ii libkf5wallet5 5.16.0-1 ii libkf5waylandclient54:5.4.3-1 ii libkf5waylandserver54:5.4.3-1 ii libkf5webkit5 5.16.0-1 ii libkf5widgetsaddons55.16.0-1 ii libkf5windowsystem5 5.16.0-1 ii libkf5xmlgui5 5.16.0-1 ii libkf5xmlrpcclient5 5.16.0-1 ii libksgrd7 4:5.4.3-1 ii libkworkspace5-54:5.4.3-1 ii libpam0g1.1.8-3.1 ii libphonon4qt5-4 4:4.8.3-2 ii libplasma-geolocation-interface54:5.4.3-1 ii libprocesscore7 4:5.4.3-1 ii libprocessui7 4:5.4.3-1 ii libqalculate5v5 0.9.7-9.1+b1 ii libqt5core5a5.5.1+dfsg-10 ii libqt5dbus5 5.5.1+dfsg-10 ii libqt5gui5 5.5.1+dfsg-10 ii libqt5network5 5.5.1+dfsg-10 ii libqt5qml5 5.5.1-3 ii libqt5quick55.5.1-3 ii libqt5script5 5.5.1+dfsg-2 ii libqt5sql5 5.5.1+dfsg-10 ii libqt5webkit5 5.5.1+dfsg-2 ii libqt5widgets5 5.5.1+dfsg-10 ii libqt5x11extras55.5.1-3 ii libqt5xml5 5.5.1+dfsg
Bug#808743: Sketch of package that builds both Python and R interfaces
Hi Andreas, I played around a bit with this and came up with the following sketch (attached). I ended up mimicking parts of what the CDBS module for R does in an otherwise dh-centric rules file. I hope it is at least of some use. Best, Gard fastcluster_1.1.16-1.debian.tar.xz Description: application/xz-compressed-tar
Bug#811069: ITP: lbfgsb -- Limited-memory quasi-Newton bound-constrained optimization
Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: lbfgsb Version : 3.0 Upstream Author : Ciyou Zhu, Richard Byrd, Jorge Nocedal, Jose Luis Morales * URL : http://users.iems.northwestern.edu/~nocedal/lbfgsb.html * License : BSD-3-clause Programming Lang: Fortran Description : Limited-memory quasi-Newton bound-constrained optimization The library is a widely used implementation of a bounded, limited-memory BFGS algorithm. A search on codesearch.debian.net reveals that at least the following packages in Debian bundle duplicates of the code: - python-scipy (see also #778635) - vxl - nwchem - plastimatch - psi4 I believe that Debian should provide lbfgsb as a standalone library, as it is useful in its own right and its presence could lead to code deduplication in the future. Note that upstream's tarball (http://users.iems.northwestern.edu/~nocedal/Software/Lbfgsb.3.0.tar.gz) contains a few prebuilt binaries, and is also a minor tarbomb. Upstream seems very inactive in the sense that the code appears to be "done". I have maintained a package for personal use since 2013 and have never experienced problems. I thus feel I could handle maintaing the package also for a wider user base going forward. I would need a sponsor.
Bug#811073: RFS: lbfgsb/3.0-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "lbfgsb" * Package name: lbfgsb Version : 3.0-1 Upstream Author : Ciyou Zhu, Richard Byrd, Jorge Nocedal and Jose Luis Morales * URL : http://users.iems.northwestern.edu/~nocedal/lbfgsb.html * License : BSD-3-clause Section : math It builds these binary packages: liblbfgsb-dev - Limited-memory quasi-Newton bound-constrained optimization (static library) liblbfgsb0 - Limited-memory quasi-Newton bound-constrained optimization liblbfgsb0-dbg - Limited-memory quasi-Newton bound-constrained optimization (debug symbols) Note that upstream's tarball [1] contains precompiled binaries, and is also a minor tarbomb. I have therefore repackaged it. You will find that my orig tarball is a strict subset of upstream's. My package includes two patches: - replace-linpack-with-lapack.patch: The library code originally uses LINPACK (from an embedded copy). Since LINPACK has largely been superseded by LAPACK, this patch replaces calls to the former with equivalent calls to the latter. Specifically, dpofa is replaced by dpotrf, and dtrsl is replaced by dtrtrs. - silence.patch: The library's documentation indicates that it will only write out messages when the iprint flag is greater than zero. There are two places where writing still happens unconditionally, which this patch fixes. A similar patch was also applied by the SciPy project (see their issue 3238). I've used the patched package on and off for the past few years and have not encountered problems. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/lbfgsb Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/l/lbfgsb/lbfgsb_3.0-1.dsc More information about lbfgsb can be obtained from [2]. [1] http://users.iems.northwestern.edu/~nocedal/Software/Lbfgsb.3.0.tar.gz [2] http://users.iems.northwestern.edu/~nocedal/lbfgsb.html Regards, Gard Spreemann
Bug#808743: r-cran-fastcluster: Does not provide upstream Python interface
Package: r-cran-fastcluster Severity: normal Dear Maintainer, The upstream package from which r-cran-fastcluster originates, simply called "fastcluster", provides both an R and a Python interface as first-class citizens [1] (both are in fact thin wrappers around a C++ library, whose interface is, AFAIK, not meant to be exposed). However, the current Debian package provides only the R interface. It would be really nice if also the Python interface could be provided. I suspect one would then rename the source to something like "fastcluster", and from it build two binaries, for example "r-cran-fastcluster" and "python-fastcluster". I have a sketch for packaging of the Python interface [2], but that is for *just* that interface. Hopefully it is not too hard to provide both. I am not too experienced with Debian packaging, but I'd happily assist if I can be of any help. [1] http://www.danifold.net/fastcluster.html [2] https://launchpad.net/~gspreemann/+archive/ubuntu/ppa/+files/fastcluster_1.1.16-0ubuntu0gspr1.2.debian.tar.xz -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#807902: Kopete segfault started occurring at same time
Hi, It may or may not be relevant, or helpful, but Kopete (4:15.08.3-1+b1) also started segfaulting when its last window is closed around the same time. It could be related. -- Gard Spreemann
Bug#807902: Kopete segfault started occurring at same time
On Tue, 22 Dec 2015 17:31:36 +0100 Gard Spreemann wrote: > It may or may not be relevant, or helpful, but Kopete > (4:15.08.3-1+b1) also started segfaulting when its last window is > closed around the same time. It could be related. With the updated Qt that just entered testing (5.5.1+dfsg-10), Kopete no longer segfaults like this. -- Gard Spreemann
Bug#811069: ITP: lbfgsb -- Limited-memory quasi-Newton bound-constrained optimization
Hi Paul, and thanks for your feedback! On Sat, 16 Jan 2016 22:28:50 +0800 Paul Wise wrote: > On Fri, Jan 15, 2016 at 7:52 PM, Gard Spreemann wrote: > > > A search on codesearch.debian.net reveals that at least the following > > packages in Debian bundle duplicates of the code: > > - python-scipy (see also #778635) > > - vxl > > - nwchem > > - plastimatch > > - psi4 > > > > I believe that Debian should provide lbfgsb as a standalone library, > > as it is useful in its own right and its presence could lead to code > > deduplication in the future. > > Please report these to the Debian security team so they can record the > info in their metadata: > > https://wiki.debian.org/EmbeddedCodeCopies I'm sorry, I seem to have spoken too soon. Most of these are the incompatible, older version 2 of L-BFGS-B. An exception is python-scipy, which really does bundle version 3 (with minor trivial patches). > > Note that upstream's tarball > > (http://users.iems.northwestern.edu/~nocedal/Software/Lbfgsb.3.0.tar.gz) > > contains a few prebuilt binaries, and is also a minor tarbomb. > > Ick, that is something that needs fixing upstream. I have now contacted upstream and notified them of some of these things, including prebuilt binaries, some metadata mess and some missing copyright notes.
Bug#811069: Package suggestion
A package suggestion (as well as a cleaned-up source tarball) is available at Mentors [1, 2]. The corresponding RFS, with more information, is bug #811073 [3]. [1] http://mentors.debian.net/debian/pool/main/l/lbfgsb/lbfgsb_3.0-1.dsc [2] https://mentors.debian.net/package/lbfgsb [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811073 Best, Gard Spreemann
Bug#840739: New upstream version with revamped packaging
Upstream has since released a new version of GUDHI (2.0.0). The RFS bug #861649 [1], which has been merged with this one, details my package for it. I believe it addresses most of the problems helpfully pointed out here. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861649 Best, Gard Spreemann
Bug#852377: RFS: tikzit/1.0-1 [ITP]
On Monday 24 July 2017 23:10:33 CEST Andrey Rahmatullin wrote: > Control: owner -1 ! > > Please bump Standards-Version to the current version and I'll upload > it. Hello Andrey, As Andrew pointed out, he has already uploaded the package. I will make sure to bump the standards-version for the next upstream release though, so thanks! Best, Gard
Bug#852376: ITP: tikzit -- Graphical tool for rapidly creating and editing node-and-edge style graphs in TikZ.
Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: tikzit Version : 1.0 Upstream Author : Aleks Kissinger * URL : http://tikzit.sourceforge.net/ * License : Mostly GPL-3+, some LGPL-2+ Programming Lang: Mostly Objective C Description : Graphical tool for rapidly creating and editing node-and-edge style graphs in TikZ. TikZiT is a graphical tool for rapidly creating and editing node-and-edge style graphs. It was originally created to aid in the typesetting of "dot" diagrams of interacting quantum observables (see arXiv:0906.4725), but can be used as a general graph editing program. I used to maintain a version of this software in an Ubuntu PPA that was moderately popular. To this day a few people e-mail me requesting updated versions of the software, so I believe this package will be useful. There was little development following the 2013 release of version 1.0. However, development has recently restarted and a version 1.1 appears to be forthcoming. I would need a sponsor for the package.
Bug#852377: RFS: tikzit/1.0-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "tikzit" * Package name: tikzit Version : 1.0-1 Upstream Author : Aleks Kissinger * URL : http://tikzit.sourceforge.net/ * License : Mostly GPL-3+, some LGPL-2+ Section : tex It builds these binary packages: tikzit - Graphical tool for creating node-and-edge style graphs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/tikzit Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/t/tikzit/tikzit_1.0-1.dsc The current version of the package is based on the "v1.0" tag in upstream's git repository. There are four patches on top of this, corresponding to later upstream commits, that fix a bison parser declaration error. The orig tarball does not match the tarball released by upstream. It is a repack of the git tree with some website-related files removed. I realize therefore that the version should be something like 1.0+dfsg.1-1. I am aware that the package lacks a watch file. I need advice as to how this is best done when upstream releases both as tarball and as tagged git commits, with slight differences. Regards, Gard Spreemann
Bug#840686: ITP: gudhi -- C++ template library for topological data analysis
Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: gudhi Version : 1.3.1 Upstream Author : Gudhi project / INRIA * URL : http://gudhi.gforge.inria.fr/ * License : GPL-3+ Programming Lang: C++ Description : C++ template library for topological data analysis The GUDHI library is a generic open source C++ library for Topological Data Analysis (TDA) and Higher Dimensional Geometry Understanding. The library offers state-of-the-art data structures and algorithms to construct simplicial complexes and compute persistent homology. The GUDHI library is developed as part of the GUDHI project supported by the European Research Council. I have initial packaging of the libgudhi-dev (the headers for this template-based library) done, and will add the comprehensive set of examples later. I would need a sponsor. Best regards, Gard Spreemann
Bug#840739: RFS: gudhi/1.3.1+ds-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "gudhi" * Package name : gudhi Version : 1.3.1+ds-1 Upstream Author : Gudhi Project / INRIA * URL : http://gudhi.gforge.inria.fr/ * License : GPL3+ Section : math GUDHI is a C++ header-only template library for computations in the mathematical field of topological data analysis. My package currently only builds libgudhi-dev, which contains the upstream library headers for this header-only template library. The build process does also build a bunch of example binaries, but these are *not* installed. I intend to add them to a gudhi-examples package at a later time, but upstream does not currently ship good install rules for them. My package includes the following patches: - Stash-flags.patch: Work around an upstream-acknowledged bug where CMake ignores compiler flags. - Don-t-use-static-boost.patch: Don't link examples statically to boost. This is not currently relevant, as the examples are not used. - Disable-some-tests-that-uncleanly-write-outside-the-.patch: Disable two upstream self-tests that write outside the build directory. (I now see that this patch's name was cut off by gbp). The package can be accessed at https://mentors.debian.net/package/gudhi and through dget -x https://mentors.debian.net/debian/pool/main/g/gudhi/gudhi_1.3.1+ds-1.dsc The package builds cleanly against a sid pbuilder. Best, Gard Spreemann -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#838381: ITP: ripser -- Software for computing persistent homology of Vietoris-Rips filtrations
Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: ripser Version : 1.0.1 Upstream Author : Ulrich Bauer * URL : http://ripser.org * License : LGPL-3.0+ Programming Lang: C++ Description : Software for computing persistent homology of Vietoris-Rips filtrations Ripser is specialized in computing persistent homology of Vietoris-Rips filtrations, useful in the mathematical field of applied algebraic topology, very efficiently. It does not aim for the generality of for example PHAT, but takes advantage of the special filtration outperform more general software. Ripser is useful to people doing work in topological data analysis and applied topology in general, and is a self-contained small program whose package should be relatively easy to maintain. I would need a sponsor for the package. Best regards, Gard Spreemann
Bug#838931: repro: logrotate script fails if repro is not running
Package: repro Version: 1:1.9.7-5 Severity: normal Dear Maintainer, The logrotate script for repro uses start-stop-daemon in its postrotate in a way that makes it exit with status 1 if repro is not running. This can cause needless e-mails to be sent to the administrator of the system if repro is installed but deliberately not running, or if the package has been removed with configuration files kept in place. I do not know what the most appropriate way to fix this is, but it seems that adding --oknodo to start-stop-daemon in repro's logrotate script will work. Best, Gard Spreemann -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#814199: Possible upstream references
Hello, As far as I can tell, this seems related to the following two upstream bugs: - https://bugs.kde.org/show_bug.cgi?id=347195 - https://bugs.kde.org/show_bug.cgi?id=356225 The latter is marked as fixed, but judging by the comments that doesn't really seem to be the case.
Bug#829614: plasma-workspace: krunner no longer launches application
Package: plasma-workspace Version: 4:5.6.5.1-1 Severity: normal Dear Maintainer, After upgrading plasma-workspace from 4:5.6.4-2 to 4:5.6.5.1-1 today, krunner has stopped functioning correctly. Hitting enter has no effect, nomatter what I type into krunner's textbox. Entering for example "emacs" or "kate" used to launch the corresponding program and remove the krunner window. Now neither happens. Best, Gard -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages plasma-workspace depends on: ii dbus-x11 1.10.8-1 ii frameworkintegration 5.22.0-1 ii gdb-minimal [gdb]7.11.1-2 ii kde-cli-tools4:5.6.5-1 ii kded55.22.0-1 ii kinit5.22.0-1 ii kio 5.22.0-1 ii libc62.22-13 ii libcln6 1.3.4-1 ii libdbusmenu-qt5-20.9.3+16.04.20160218-1 ii libgcc1 1:6.1.1-7 ii libgps22 3.16-2 ii libice6 2:1.0.9-1+b1 ii libkf5activities55.22.0-2 ii libkf5auth5 5.23.0-1 ii libkf5baloo5 5.22.0-2 ii libkf5bookmarks5 5.22.0-2 ii libkf5completion55.23.0-1 ii libkf5configcore55.23.0-1 ii libkf5configgui5 5.23.0-1 ii libkf5configwidgets5 5.22.0-1 ii libkf5coreaddons55.23.0-1 ii libkf5crash5 5.23.0-1 ii libkf5dbusaddons55.23.0-1 ii libkf5declarative5 5.22.0-1+b1 ii libkf5globalaccel-bin5.23.0-1 ii libkf5globalaccel5 5.23.0-1 ii libkf5guiaddons5 5.23.0-1 ii libkf5i18n5 5.22.1-1 ii libkf5iconthemes55.22.0-1 ii libkf5idletime5 5.23.0-1 ii libkf5itemviews5 5.23.0-1 ii libkf5jobwidgets55.23.0-1 ii libkf5js55.23.0-1 ii libkf5jsembed5 5.22.0-1 ii libkf5kdelibs4support5 5.22.0-2 ii libkf5kiocore5 5.22.0-1 ii libkf5kiofilewidgets55.22.0-1 ii libkf5kiowidgets55.22.0-1 ii libkf5networkmanagerqt6 5.23.0-1 ii libkf5newstuff5 5.22.0-1 ii libkf5notifications5 5.23.0-1 ii libkf5notifyconfig5 5.22.0-1 ii libkf5package5 5.22.0-1 ii libkf5plasma55.22.0-1 ii libkf5plasmaquick5 5.22.0-1 ii libkf5quickaddons5 5.22.0-1+b1 ii libkf5runner55.22.0-1 ii libkf5screen-bin 4:5.6.5-1 ii libkf5screen74:5.6.5-1 ii libkf5service-bin5.22.0-1 ii libkf5service5 5.22.0-1 ii libkf5solid5 5.23.0-1 ii libkf5su55.22.0-1 ii libkf5texteditor55.22.0-1 ii libkf5textwidgets5 5.22.0-1 ii libkf5wallet-bin 5.22.0-1 ii libkf5wallet55.22.0-1 ii libkf5waylandclient5 4:5.23.0-1 ii libkf5widgetsaddons5 5.23.0-1 ii libkf5windowsystem5 5.23.0-1 ii libkf5xmlgui55.22.0-1 ii libkf5xmlrpcclient5 5.22.0-1 ii libkscreenlocker55.6.5-1 ii libksgrd74:5.6.5-1 ii libkworkspace5-5 4:5.6.5.1-1 ii libphonon4qt5-4 4:4.9.0-3 ii libplasma-geolocation-interface5 4:5.6.5.1-1 ii libprocesscore7 4:5.6.5-1 ii libprocessui74:5.6.5-1 ii libqalculate5v5 0.9.7-9.1+b1 ii libqt5core5a 5.6.1+dfsg-3 ii libqt5dbus5 5.6.1+dfsg-3 ii libqt5gui5 5.6.1+dfsg-3 ii libqt5network5 5.6.1+dfsg-3 ii libqt5qml5 5.6.1-4 ii libqt5qui
Bug#829614: plasma-workspace: krunner no longer launches application
On Wed, 06 Jul 2016 12:51:59 +0200 Diederik de Haas wrote: > On maandag 4 juli 2016 20:03:54 CEST Gard Spreemann wrote: > > After upgrading plasma-workspace from 4:5.6.4-2 to 4:5.6.5.1-1 today, > > krunner has stopped functioning correctly. > > > > -- System Information: > > Debian Release: stretch/sid > > APT prefers testing > > APT policy: (990, 'testing'), (500, 'unstable') > > I see that various packages are at version 5.22.x while others are > at 5.23.x. What happens if you upgrade those packages to the 5.23.x > version, available in sid/unstable? Hi all, and apologies for being slow to reply (I incorrectly remembered having subscribed to the bug without actually having done so). After upgrading (only) libkf5plasma55.22.0-1 to 5.23.0-1, I am no longer experiencing this bug. Do I mark it as fixed in 5.23.0, or do we instead consider this a non-bug I experienced because I had inadvertendly mixed Plasma versions? Best, Gard
Bug#829614: plasma-workspace: krunner no longer launches application
On Saturday 09 July 2016 16:41:13 Diederik de Haas wrote: > On zaterdag 9 juli 2016 16:29:27 CEST Gard Spreemann wrote: > > Do I mark it as fixed in 5.23.0, or do we instead consider this a > > non-bug I experienced because I had inadvertendly mixed Plasma > > versions? > > I'd say neither. > The issue seems (very much) to be caused by various framework packages not > being at the same versions. > It is still not known whether they all need to be at the same versions or > only a subset of those framework packages and which that would be. > > And as it causes real issues, it is a valid bug. Alright. This is a working combination for plasma-workspace 4:5.6.5.1-1: ii libkf5activities55.22.0-2 ii libkf5auth5 5.23.0-1 ii libkf5baloo5 5.22.0-2 ii libkf5bookmarks5 5.22.0-2 ii libkf5completion55.23.0-1 ii libkf5configcore55.23.0-1 ii libkf5configgui5 5.23.0-1 ii libkf5configwidgets5 5.22.0-1 ii libkf5coreaddons55.23.0-1 ii libkf5crash5 5.23.0-1 ii libkf5dbusaddons55.23.0-1 ii libkf5declarative5 5.22.0-1+b1 ii libkf5globalaccel-bin5.23.0-1 ii libkf5globalaccel5 5.23.0-1 ii libkf5guiaddons5 5.23.0-1 ii libkf5i18n5 5.22.1-1 ii libkf5iconthemes55.22.0-1 ii libkf5idletime5 5.23.0-1 ii libkf5itemviews5 5.23.0-1 ii libkf5jobwidgets55.23.0-1 ii libkf5js55.23.0-1 ii libkf5jsembed5 5.22.0-1 ii libkf5kdelibs4support5 5.22.0-2 ii libkf5kiocore5 5.22.0-1 ii libkf5kiofilewidgets55.22.0-1 ii libkf5kiowidgets55.22.0-1 ii libkf5networkmanagerqt6 5.23.0-1 ii libkf5newstuff5 5.22.0-1 ii libkf5notifications5 5.23.0-1 ii libkf5notifyconfig5 5.22.0-1 ii libkf5package5 5.22.0-1 ii libkf5plasma55.23.0-1 ii libkf5plasmaquick5 5.22.0-1 ii libkf5quickaddons5 5.22.0-1+b1 ii libkf5runner55.22.0-1 ii libkf5screen-bin 4:5.6.5-1 ii libkf5screen74:5.6.5-1 ii libkf5service-bin5.22.0-1 ii libkf5service5 5.22.0-1 ii libkf5solid5 5.23.0-1 ii libkf5su55.22.0-1 ii libkf5texteditor55.22.0-1 ii libkf5textwidgets5 5.22.0-1 ii libkf5wallet-bin 5.22.0-1 ii libkf5wallet55.22.0-1 ii libkf5waylandclient5 4:5.23.0-1 ii libkf5widgetsaddons5 5.23.0-1 ii libkf5windowsystem5 5.23.0-1 ii libkf5xmlgui55.22.0-1 ii libkf5xmlrpcclient5 5.22.0-1 With 5.22.0-1 of libkf5plasma5 instead, the combination does not work (exhibits the bug). Thanks a lot for your help in figuring this out. Best, Gard
Bug#1076376: python3-pot: reports SyntaxWarning with Python 3.12
Hi, Thanks for the bug report. I believe this is a simple oversight in some docstrings with TeX that should have been raw strings (as elsewhere in the code). I've filed a pull request upstream [1] fixing the cases I could find. [1] https://github.com/PythonOT/POT/pull/657 Best, Gard signature.asc Description: PGP signature
Bug#1039001: Tests disabled
Source: hera Version: 1.0.0+dfsg-2 Followup-For: Bug #1039001 Control: severity 1039001 wishlist Uploading catch2 v3 also made hera FTBFS (#1054686), and it is not clear whether the catch2 package will provide backwards-compatible headers (#1055237). Since updating hera is not entirely trivial, the fix for #1054686 was to temporarily disable tests. With tests disabled, I'm lowering the severity of this bug. signature.asc Description: PGP signature
Bug#1070201: Matching upstream bug report
Hi, I believe this is upstream's issue 27506 [1]. Given the bug's nature, I suggest that perhaps it should be temporarily worked around by disabling the failing test. [1] https://github.com/scikit-learn/scikit-learn/issues/27506 Best, Gard signature.asc Description: PGP signature
Bug#1070201: Small reproducing example
The following code based on the failing test reproduces the issue on an i386 porterbox: *** from sklearn.tree import ( DecisionTreeClassifier, export_graphviz, ) import pdb X = [[-2, -1], [-1, -1], [-1, -2], [1, 1], [1, 2], [2, 1]] y2 = [[-1, 1], [-1, 1], [-1, 1], [1, 2], [1, 2], [1, 3]] w = [1, 1, 1, 0.5, 0.5, 0.5] def main(): clf = DecisionTreeClassifier( max_depth=2, min_samples_split=2, criterion="gini", random_state=2 ) clf = clf.fit(X, y2, sample_weight=w) pdb.set_trace() contents1 = export_graphviz(clf, filled=True, impurity=False, out_file=None) if __name__ == "__main__": main() *** On an amd64 system, we see the following normal behavior when inspecting `clf.tree_` and its negation at the given breakpoint: > (Pdb) clf.tree_.impurity > array([0.4691358 , 0., 0., 0., 0.]) > (Pdb) -clf.tree_.impurity > array([-0.4691358 , -0., -0., -0., -0.]) However, on an i386 porterbox, we get this funny behavior with the negation: > (Pdb) clf.tree_.impurity > array([0.4691358 , 0., 0., 0., 0.]) > (Pdb) -clf.tree_.impurity > array([-4.69135802e-001, -1.59149684e-314, -1.5000e+000, > -2.12199579e-314, nan]) This smells of some alignment issue on an FFI boundary, perhaps. It certainly explains the failing test (as the tested code does `np.min` and `np.max` of `-clf.tree_.impurity`). Best, Gard signature.asc Description: PGP signature
Bug#1070201: Perhaps alignment-related?
It seems that any `Tree` attribute that uses `self._get_node_ndarray()`
to get a *floating point* ndarray suffers from this weird behavior when
negating. Examples include `weighted_n_node_samples` and
`threshold`. However, attributes that use the same function to get
*integer* ndarrays don't. Examples include `n_node_samples` and
`feature`.
Moreover, *only negation* seems to be problematic. Multiplying by `-1.0` seems
fine:
> (Pdb) clf.tree_.impurity.__neg__()
> array([-4.69135802e-001, -1.59149684e-314, -1.5000e+000,
> -2.12199579e-314, nan])
> (Pdb) clf.tree_.impurity.__mul__(-1.0)
> array([-0.4691358 , -0., -0., -0., -0.])
Some further observations:
* On i386:
(Pdb) clf.tree_.impurity.__array_interface__
{'data': (161778564, False), 'strides': (44,), 'descr': [('', 'https://github.com/numpy/numpy/commit/490b1e45ce16ca91d1c6a1e644f844179b5410eb
signature.asc
Description: PGP signature
Bug#1059100: rust-wasm-bindgen: Please consider producing a binary for wasm-bindgen-cli also
Source: rust-wasm-bindgen X-Debbugs-Cc: g...@nonempty.org Version: 0.2.87-1 Severity: wishlist In order to use wasm-bindgen to write Rust code that interacts with Javascript, the binaries output by rustc need to be passed through postprocessing with the utility wasm-bindgen-cli. That bin crate is a workspace member upstream, but is not currently packaged in Debian. Having it would greatly improve the usefulness of wasm-bindgen. It seems that the cli crate does have dependencies that are not yet in Debian, so this may well be a non-trivial amount of work.
Bug#1059611: doxygen: Generated documentation pulls in JS from third-party source in some cases
Package: doxygen X-Debbugs-Cc: g...@nonempty.org Version: 1.9.8+ds-2 Severity: normal Tags: upstream As documented upstream in issue 10354 [1], Doxygen will when MathJax is enabled generate documentation that makes requests to a third-party website when viewed. This is obviously problematic from a privacy point of view, as users expect offline documentation to be offline. For examples of this happening, see e.g. reports for Lintian's privacy-breach-generic tag [2]. Upstream's version 1.10.0 was released just a few days ago, and fixes the issue [3]. Alternatively, the behavior should be easy to patch out (I'm happy to provide a patch/MR). [1] https://github.com/doxygen/doxygen/issues/10354 [2] https://udd.debian.org/lintian-tag.cgi?tag=privacy-breach-generic [3] https://www.doxygen.nl/manual/changelog.html#log_1_10_0 signature.asc Description: PGP signature
Bug#1059612: libgudhi-doc: HTML documentation causes requests to third-party website when viewed
Package: libgudhi-doc X-Debbugs-Cc: g...@nonempty.org Version: 3.8.0+dfsg-1 Severity: important This is to document that libgudhi-doc contains HTML documentation that causes requests to a third-party website when viewed, potentially violating user privacy expectations. This seems to me to be due to a bug in Doxygen. signature.asc Description: PGP signature
Bug#1062932: Error building nvidia-kernel-dkms while installing nvidia-driver package
On 4 April 2024 02:52:29 CEST, David Landry wrote: >Good evening, > >The bug involving compiling/installing nvidia-kernel-dkms is still present. >The result of the bug is that following a reboot after the erroneous >installation noted below, my display drivers get completely disabled, >including nouveau, resulting in my external display not functioning and my >primary laptop display having very low resolution. > >I followed the instructions to install NVIDIA proprietary drivers here: >https://wiki.debian.org/NvidiaGraphicsDrivers > >When I executed: >sudo apt install nvidia-driver firmware-misc-nonfree >I received the following errors, as recorded from the output of the above >command: >Setting up nvidia-kernel-dkms (525.147.05-4~deb12u1) ... Hello, You seem to be attempting to install a package version with the bug (525.147.05-4~deb12u1). As you can see from the very bugreport you're replying to, the fixed version for Bookworm is 525.147.05-7~deb12u1 (https://lists.debian.org/debian-stable-announce/2024/02/msg2.html). Are you sure you have bookworm-updates enabled? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#1068647: python-pot: autopkgtest regression on i386 with NumPy 1.26.4
Control: forwarded -1 https://github.com/PythonOT/POT/issues/618 Thanks for the bug report. This seems like a simple case of a missing floating point tolerance in upstream's test. It's easy to patch, but I've sent a reproducible example upstream [1] as they're likely to have better insight into the appropriate floating point tolerance level for the test. [1] https://github.com/PythonOT/POT/issues/618 Best, Gard
Bug#1074115: gudhi: FTBFS with CGAL 6.0
Joachim Reichel writes: > Source: gudhi > Version: 3.7.1+dfsg-1 > Severity: normal > Tags: ftbfs > X-Debbugs-Cc: reic...@debian.org > > Dear maintainer, > > your package fails to build with cgal 6.0~beta1-1, which has recently been > uploaded to experimental. See [1] for the release notes with breaking changes. > > [1] https://github.com/CGAL/cgal/releases/tag/v6.0-beta1 > > Some issues can be fixed just by requiring C++17 (see attached patch). The use > of CGAL_USE_FILE needs to be replaced by target_link_library(... PRIVATE > CGAL::CGAL) (missing in the patch). Finally, CGAL has moved from Qt5 to Qt6. Hi, Thanks for the heads up. The upcoming 3.10 release of GUDHI will support CGAL 6.0, and should be out soon [1]. I'll get it packaged as soon as it's out (the RC cycle for GUDHI is usually merely a matter of days). PS: I see this bug was filed against GUDHI versions starting with the one in Bookworm. Does that make sense? Is there an expectation to be able to compile the Bookworm version of GUDHI with a not-yet-in-Trixie version of CGAL? [1] https://github.com/GUDHI/gudhi-devel/releases/tag/tags%2Fgudhi-release-3.10.0rc1 Best, Gard signature.asc Description: PGP signature
Bug#1039474: ghc: GHCi sometimes segfaults
Package: ghc Version: 9.0.2-4 Severity: normal Tags: upstream X-Debbugs-Cc: g...@nonempty.org Dear Maintainer, GHCi seems to segfault randomly every now and then, after seemingly failing to allocate memory for simple operations, e.g.: $ ghci GHCi, version 9.0.2: https://www.haskell.org/ghc/ :? for help ghci> 750+850 1600 ghc: mmap 4096 bytes at (nil): Cannot allocate memory ghc: Try specifying an address with +RTS -xm -RTS zsh: segmentation fault ghci Shortly afterwards, the same commands may work perfectly well. I've observed this happen on two completely different machines, but have been unable to consistently reproduce. Upstream describes the issue at https://discourse.haskell.org/t/facing-mmap-4096-bytes-at-nil-cannot-allocate-memory-youre-not-alone/6259 but it seems that the fix has not been backported to 9.0.x. I have no idea how hard it would be to do. Sorry for not catching this before Bookworm released. I do believe I saw the segfault once or twice before the release, but I must have chalked it up to a hardware fault or something :-/ -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/6 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ghc depends on: ii dpkg1.21.22 ii gcc 4:12.2.0-3 ii libbsd-dev 0.11.7-2 ii libc6 2.36-9 ii libc6-dev 2.36-9 ii libffi-dev 3.4.4-1 ii libffi8 3.4.4-1 ii libgmp-dev 2:6.2.1+dfsg1-1.1 ii libgmp102:6.2.1+dfsg1-1.1 ii libncurses-dev 6.4-4 ii libtinfo6 6.4-4 ghc recommends no packages. Versions of packages ghc suggests: pn ghc-doc pn ghc-prof pn haskell-doc ii llvm-13 1:13.0.1-11+b2 ii perl 5.36.0-7 -- no debconf information signature.asc Description: PGP signature
Bug#1030142: scipy: Has reverted to using bundled copy of L-BFSG-B library
Source: scipy
Version: 1.10.0-2
Severity: normal
Tags: patch
X-Debbugs-Cc: g...@nonempty.org
Dear Maintainer,
Ever since #778635, the SciPy package has carried a patch that makes it
use the system LBFGSB library provided by liblbfgsb0 instead of the
bundled copy that upstream uses. It seems that this patch no longer does
the trick with SciPy's move to building with Meson, as has become
evident with 1.10.0-2 entering unstable:
* python3-scipy no longer depends on liblbfgsb0
*
/usr/lib/python3/dist-packages/scipy/optimize/_lbfgsb.cpython-311-x86_64-linux-gnu.so
has no reference to liblbfgsb.so.0
Attached is an updated patch, to replace the old one with the same name,
that seems to rectify the situation. I have tested that it restores
linking with liblbfgsb.so.0, and that no tests fail.
Best,
Gard
From: Gard Spreemann
Date: Sun, 29 Jan 2023 19:55:15 +0100
Subject: Use system LBFGSB.
---
scipy/optimize/meson.build | 5 +
scipy/optimize/setup.py| 4 +++-
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/scipy/optimize/meson.build b/scipy/optimize/meson.build
index c7079e7..78a006f 100644
--- a/scipy/optimize/meson.build
+++ b/scipy/optimize/meson.build
@@ -100,15 +100,12 @@ lbfgsb_module = custom_target('lbfgsb_module',
_lbfgsb = py3.extension_module('_lbfgsb',
[
-'lbfgsb_src/lbfgsb.f',
-'lbfgsb_src/linpack.f',
-'lbfgsb_src/timer.f',
lbfgsb_module,
],
c_args: numpy_nodepr_api,
fortran_args: fortran_ignore_warnings,
include_directories: [inc_np, inc_f2py],
- link_args: version_link_args,
+ link_args: version_link_args + ['-llbfgsb'],
dependencies: [lapack, fortranobject_dep],
install: true,
link_language: 'fortran',
diff --git a/scipy/optimize/setup.py b/scipy/optimize/setup.py
index c24ef50..1dabc2b 100644
--- a/scipy/optimize/setup.py
+++ b/scipy/optimize/setup.py
@@ -64,8 +64,10 @@ def configuration(parent_package='', top_path=None):
pre_build_hook = None
lapack = combine_dict(lapack, numpy_nodepr_api)
+lapack.setdefault('libraries', [])
+lapack['libraries'].append('lbfgsb')
-sources = ['lbfgsb.pyf', 'lbfgsb.f', 'linpack.f', 'timer.f']
+sources = ['lbfgsb.pyf']
ext = config.add_extension('_lbfgsb',
sources=[join('lbfgsb_src', x)
for x in sources],
signature.asc
Description: PGP signature
Bug#1030145: r-cran-fastcluster: Missing copyright information
Source: r-cran-fastcluster Version: 1.1.24-1 Severity: normal X-Debbugs-Cc: g...@nonempty.org Dear Maintainer, The upstream author of the package has specified that "all changes from version 1.1.24 on" are copyright Google Inc. [1]. The current d/copyright therefore only accurately represents the situation prior to version 1.1.24-1. [1] https://cran.r-project.org/web/packages/fastcluster/LICENSE signature.asc Description: PGP signature
Bug#1027819: tikzit: Segfaults when pressing the b key
Package: tikzit X-Debbugs-Cc: g...@nonempty.org Version: 2.1.6-3 Severity: normal As reported upstream [1], TikZiT will segfault and crash if one presses the b key. This seems related to a hotkey for a functionality that used to, but no longer does, exist in the program. I am preparing a patch to disable the b key functionality. [1] https://github.com/tikzit/tikzit/issues/140 -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-6-amd64 (SMP w/6 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tikzit depends on: ii libc6 2.36-7 ii libgcc-s1 12.2.0-11 ii libpoppler-qt5-1 22.08.0-2.1 ii libqt5core5a 5.15.7+dfsg-2 ii libqt5gui55.15.7+dfsg-2 ii libqt5network55.15.7+dfsg-2 ii libqt5widgets55.15.7+dfsg-2 ii libstdc++612.2.0-11 ii tex-common6.18 Versions of packages tikzit recommends: ii preview-latex-style 12.2-1 ii texlive-latex-base 2022.20221123-1 ii texlive-pictures 2022.20221123-1 tikzit suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#1022308:
Hi, I have verified that adding libglu1-mesa-dev to the build-deps makes the package again build successfully. -- Gard signature.asc Description: PGP signature
Bug#1024903: pytorch: CVE-2022-45907: torch.jit.annotations.parse_type_line prone to command injection
Hi,
Turning upstream commit 767f6aa49fe20a2766b9843d01e3b7f7793df6a3 into a
patch seems straightforward on 1.12.1-1 and 1.7.1-7. At least both
versions still build fine with the patch. I will see if I can get around
to running the test soon enough.
Meanwhile, attached are the two corresponding patches.
I don't know if this is worth fixing, since upstream's comments seem to
indicate that the code in question is only for Python 2
compatibility.
Best,
Gard
From: Gard Spreemann
Date: Tue, 29 Nov 2022 17:51:18 +0100
Subject: Do not blindly eval input string
This fix for CVE-2022-45907 is based on upstream commit
767f6aa49fe20a2766b9843d01e3b7f7793df6a3 , whose message follows.
---
commit 767f6aa49fe20a2766b9843d01e3b7f7793df6a3
Author: Nikita Shulga
Date: Thu Nov 17 22:05:27 2022 +
[JIT][Security] Do not blindly eval input string (#89189)
Introduce `_eval_no_call` method, that evaluates statement only if it
does not contain any calls(done by examining the bytecode), thus preventing command injection exploit
Added simple unit test to check for that
`torch.jit.annotations.get_signature` would not result in calling random
code.
Although, this code path exists for Python-2 compatibility, and perhaps
should be simply removed.
Fixes https://github.com/pytorch/pytorch/issues/88868
Pull Request resolved: https://github.com/pytorch/pytorch/pull/89189
Approved by: https://github.com/suo
---
test/test_jit.py | 8
torch/csrc/jit/frontend/script_type_parser.cpp | 2 +-
torch/jit/annotations.py | 14 --
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/test/test_jit.py b/test/test_jit.py
index fb9f6fa..49b51dd 100644
--- a/test/test_jit.py
+++ b/test/test_jit.py
@@ -3422,6 +3422,14 @@ def foo(x):
return a + 2
torch.jit.script(invalid4)
+def test_calls_in_type_annotations(self):
+with self.assertRaisesRegex(RuntimeError, "Type annotation should not contain calls"):
+def spooky(a):
+# type: print("Hello") -> Tensor # noqa: F723
+return a + 2
+print(torch.__file__)
+torch.jit.annotations.get_signature(spooky, None, 1, True)
+
def test_is_optional(self):
ann = Union[List[int], List[float]]
torch._jit_internal.is_optional(ann)
diff --git a/torch/csrc/jit/frontend/script_type_parser.cpp b/torch/csrc/jit/frontend/script_type_parser.cpp
index bec9e87..2e014c9 100644
--- a/torch/csrc/jit/frontend/script_type_parser.cpp
+++ b/torch/csrc/jit/frontend/script_type_parser.cpp
@@ -229,7 +229,7 @@ std::vector ScriptTypeParser::evaluateDefaults(
// We then run constant prop on this graph and check the results are
// constant. This approach avoids having to have separate handling of
// default arguments from standard expressions by piecing together existing
- // machinery for graph generation, constant propgation, and constant
+ // machinery for graph generation, constant propagation, and constant
// extraction.
auto tuple_type = Subscript::create(
r,
diff --git a/torch/jit/annotations.py b/torch/jit/annotations.py
index ba68920..bb09f96 100644
--- a/torch/jit/annotations.py
+++ b/torch/jit/annotations.py
@@ -1,4 +1,5 @@
import ast
+import dis
import enum
import inspect
import re
@@ -135,6 +136,15 @@ def check_fn(fn, loc):
raise torch.jit.frontend.FrontendError(loc, "Expected a single top-level function")
+def _eval_no_call(stmt, glob, loc):
+"""Evaluate statement as long as it does not contain any method/function calls"""
+bytecode = compile(stmt, "", mode="eval")
+for insn in dis.get_instructions(bytecode):
+if "CALL" in insn.opname:
+raise RuntimeError(f"Type annotation should not contain calls, but '{stmt}' does")
+return eval(bytecode, glob, loc) # type: ignore[arg-type] # noqa: P204
+
+
def parse_type_line(type_line, rcb, loc):
"""Parses a type annotation specified as a comment.
@@ -145,7 +155,7 @@ def parse_type_line(type_line, rcb, loc):
arg_ann_str, ret_ann_str = split_type_line(type_line)
try:
-arg_ann = eval(arg_ann_str, {}, EvalEnv(rcb)) # type: ignore # noqa: P204
+arg_ann = _eval_no_call(arg_ann_str, {}, EvalEnv(rcb))
except (NameError, SyntaxError) as e:
raise RuntimeError("Failed to parse the argument list of a type annotation") from e
@@ -153,7 +163,7 @@ def parse_type_line(type_line, rcb, loc):
arg_ann = (arg_ann,)
try:
-ret_ann = eval(ret_ann_str, {}, EvalEnv(rcb)) # type: ignore # noqa: P204
+ret_ann = _eval_no_call(ret_ann_str, {}, EvalEnv(rcb))
except (NameError, SyntaxError) as e:
raise RuntimeError("
Bug#1034163: waypipe: Leaks memory
Package: waypipe Version: 0.8.4-2 Severity: important X-Debbugs-Cc: g...@nonempty.org Upstream commit 9070c4c527c906cb186588ca410d92d2f7f3c7ba fixes and documents a memory leak [1] present in versions prior to 0.8.6. The leak can be reproduced by running e.g. waypipe -d ssh localhost weston-simple-shm 2>&1 | grep "in flight" and watching the number of bytes in flight steadily increasing as time goes by. [1] https://gitlab.freedesktop.org/mstoeckl/waypipe/-/commit/9070c4c527c906cb186588ca410d92d2f7f3c7ba -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-security'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-7-amd64 (SMP w/6 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages waypipe depends on: ii libavcodec59 7:5.1.2-3 ii libavutil57 7:5.1.2-3 ii libc6 2.36-8 ii libgbm1 22.3.6-1+deb12u1 ii liblz4-1 1.9.4-1 ii libswscale6 7:5.1.2-3 ii libva22.17.0-1 ii libzstd1 1.5.4+dfsg2-5 Versions of packages waypipe recommends: ii openssh-client 1:9.2p1-2 ii openssh-server 1:9.2p1-2 waypipe suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#1034165: unblock: waypipe/0.8.4-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: wayp...@packages.debian.org, g...@nonempty.org
Control: affects -1 + src:waypipe
Please unblock package waypipe.
[ Reason ]
Waypipe versions prior to 0.8.6 contain a memory leak that is documented
as bug #1034163 [1]. I have cherry-picked a one-line fix from upstream
[2], and have verified that it fixes the problem. I have uploaded
0.8.4-3 to unstable with that patch as the only change. A debdiff
against 0.8.4-2 (in testing) is attached.
[ Impact ]
If the unblock isn't granted, Bookworm will ship with a version of
waypipe that leaks memory, making long-running sessions
problematic. Since waypipe's job is to provide SSH forwarding (à la "ssh
-X") to software running under Wayland, such long-running sessions are
expected.
[ Tests ]
By running waypipe in debug mode, e.g.
waypipe -d ssh localhost weston-simple-shm 2>&1 | grep "in flight"
one can watch the "number of bytes in flight" messages report an
ever-increasing number of bytes in the version of waypipe in Bookworm
(0.8.4-2). With the fixed version from unstable (0.8.4-3), the number
of bytes in flight remains bounded.
This test was recommended to me by waypipe's upstream author.
[ Risks ]
The fix is a one-line patch, authored by upstream and already released
as part of upstream's version 0.8.6.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034163
[2]
https://gitlab.freedesktop.org/mstoeckl/waypipe/-/commit/9070c4c527c906cb186588ca410d92d2f7f3c7ba
unblock waypipe/0.8.4-3
diff -Nru waypipe-0.8.4/debian/changelog waypipe-0.8.4/debian/changelog
--- waypipe-0.8.4/debian/changelog 2022-11-23 17:11:16.0 +0100
+++ waypipe-0.8.4/debian/changelog 2023-04-10 15:51:36.0 +0200
@@ -1,3 +1,9 @@
+waypipe (0.8.4-3) unstable; urgency=medium
+
+ * Add upstream patch to fix memory leak. (Closes: #1034163)
+
+ -- Gard Spreemann Mon, 10 Apr 2023 15:51:36 +0200
+
waypipe (0.8.4-2) unstable; urgency=medium
* Increase timeout limit for build-time tests. (Closes: #1011322)
diff -Nru waypipe-0.8.4/debian/patches/0001-Fix-a-memory-leak.patch waypipe-0.8.4/debian/patches/0001-Fix-a-memory-leak.patch
--- waypipe-0.8.4/debian/patches/0001-Fix-a-memory-leak.patch 1970-01-01 01:00:00.0 +0100
+++ waypipe-0.8.4/debian/patches/0001-Fix-a-memory-leak.patch 2023-04-10 15:51:36.0 +0200
@@ -0,0 +1,29 @@
+From: Gard Spreemann
+Date: Mon, 10 Apr 2023 12:21:18 +0200
+Subject: Fix a memory leak
+
+This cherry-picks upstream commit
+9070c4c527c906cb186588ca410d92d2f7f3c7ba. The original commit message
+follows.
+
+This was introduced by a0f6bfa191f55b99e4ff68dd0063aa0c0e12dcbd
+incorrectly checking when to increase the value of
+cxs->last_confirmed_msgno. As a result, one of the two Waypipe
+processes would leak all the messages sent to the other process.
+---
+ src/mainloop.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/mainloop.c b/src/mainloop.c
+index 181319c..38a084d 100644
+--- a/src/mainloop.c
b/src/mainloop.c
+@@ -280,7 +280,7 @@ static int interpret_chanmsg(struct chan_msg_state *cmsg,
+ } else if (type == WMSG_ACK_NBLOCKS) {
+ struct wmsg_ack *ackm = (struct wmsg_ack *)packet;
+ if (msgno_gt(ackm->messages_received,
+-cxs->last_received_msgno)) {
++cxs->last_confirmed_msgno)) {
+ cxs->last_confirmed_msgno = ackm->messages_received;
+ }
+ return 0;
diff -Nru waypipe-0.8.4/debian/patches/series waypipe-0.8.4/debian/patches/series
--- waypipe-0.8.4/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ waypipe-0.8.4/debian/patches/series 2023-04-10 15:51:36.0 +0200
@@ -0,0 +1 @@
+0001-Fix-a-memory-leak.patch
signature.asc
Description: PGP signature
Bug#1034448: bind9: Typo in documentation file name
Package: bind9 Version: 1:9.16.37-1~deb11u1 Severity: minor X-Debbugs-Cc: g...@nonempty.org Dear Maintainer, /etc/bind/named.conf refers to documentation in /usr/share/doc/bind9/README.Debian.gz. The correct file name is seemingly /usr/share/doc/bind9/README.Debian. -- Gard signature.asc Description: PGP signature
Bug#1028643: Also seems to cause artifacts under XWayland
In addition to the quite negative changes described by others in this bug report – which I fully agree with – it also seems that the new fontconfig version causes a new rendering artifact with emacs running under XWayland. While text rendering wasn't perfect under XWayland before either, the weird color artifacts that now show up make things even worse in my opinion. See attached screenshot. -- Gard signature.asc Description: PGP signature
Bug#1031706: optuna: test_create_new_trial randomly fails on s390x
"Rebecca N. Palmer" writes: > test_create_new_trial (both parts) sometimes fails on s390x, failing > the autopkgtest. > > It might make sense to remove this package on s390x, if it isn't > reasonable to actually fix this. Thanks for the report! I've brought this to upstream's attention [1], but I'm a bit confused as the upstream tests seem to make some surprising assumptions about monotonicity of `datetime.now()` [2]. I'll hold off on further investigation until I've figured out whether I've just misunderstood something on their part. In the worst case I'll disable autopkgtests – or this particular test – on s390x. [1] https://github.com/optuna/optuna/issues/4453 [2] https://github.com/optuna/optuna/issues/4455 Best, Gard signature.asc Description: PGP signature
Bug#1031949: tex-common: fmtutil fails to copy logs, installation fails
Package: tex-common Version: 6.16 Severity: normal Dear Maintainer, Installing a combination like texlive-latex-base texlive-latex-recommended texlive-latex-extra texlive-pictures texlive-luatex texlive-pictures-doc on a fresh Bullseye system with no TeX packages present fails with Building format(s) --all. This may take some time... fmtutil failed. Output has been stored in /tmp/fmtutil.LCLt5oyh Please include this file if you report a bug. dpkg: error processing package tex-common (--configure): installed tex-common package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: tex-common E: Sub-process /usr/bin/dpkg returned an error code (1) Bug #1016055 seems related, but was closed as caused by a full filesystem. On my system, the partition in question has hundreds of GB free. The log file mentioned above contains: fmtutil: fmtutil is using the following fmtutil.cnf files (in precedence order): fmtutil: /usr/share/texmf/web2c/fmtutil.cnf fmtutil: /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf fmtutil: fmtutil is using the following fmtutil.cnf file for writing changes: fmtutil: /etc/texmf/web2c/fmtutil.cnf fmtutil [INFO]: writing formats under /var/lib/texmf/web2c fmtutil [INFO]: --- remaking luatex with luatex fmtutil: running `luatex -ini -jobname=luatex -progname=luatex luatex.ini' ... Unable to read environment locale: exit now. fmtutil [INFO]: --- remaking tex with tex fmtutil: running `tex -ini -jobname=tex -progname=tex tex.ini' ... This is TeX, Version 3.14159265 (TeX Live 2020/Debian) (INITEX) (/usr/share/texlive/texmf-dist/tex/plain/config/tex.ini (/usr/share/texlive/texmf-dist/tex/plain/base/plain.tex Preloading the plain format: codes, registers, parameters, fonts, more fonts, macros, math definitions, output routines, hyphenation (/usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex)) ) Beginning to dump on file tex.fmt (preloaded format=tex 2023.2.25) 2027 strings of total length 29296 4990 memory locations dumped; current usage is 110&4877 926 multiletter control sequences \font\nullfont=nullfont \font\tenrm=cmr10 \font\preloaded=cmr9 \font\preloaded=cmr8 \font\sevenrm=cmr7 \font\preloaded=cmr6 \font\fiverm=cmr5 \font\teni=cmmi10 \font\preloaded=cmmi9 \font\preloaded=cmmi8 \font\seveni=cmmi7 \font\preloaded=cmmi6 \font\fivei=cmmi5 \font\tensy=cmsy10 \font\preloaded=cmsy9 \font\preloaded=cmsy8 \font\sevensy=cmsy7 \font\preloaded=cmsy6 \font\fivesy=cmsy5 \font\tenex=cmex10 \font\preloaded=cmss10 \font\preloaded=cmssq8 \font\preloaded=cmssi10 \font\preloaded=cmssqi8 \font\tenbf=cmbx10 \font\preloaded=cmbx9 \font\preloaded=cmbx8 \font\sevenbf=cmbx7 \font\preloaded=cmbx6 \font\fivebf=cmbx5 \font\tentt=cmtt10 \font\preloaded=cmtt9 \font\preloaded=cmtt8 \font\preloaded=cmsltt10 \font\tensl=cmsl10 \font\preloaded=cmsl9 \font\preloaded=cmsl8 \font\tenit=cmti10 \font\preloaded=cmti9 \font\preloaded=cmti8 \font\preloaded=cmti7 \font\preloaded=cmu10 \font\preloaded=cmmib10 \font\preloaded=cmbsy10 \font\preloaded=cmcsc10 \font\preloaded=cmssbx10 \font\preloaded=cmdunh10 \font\preloaded=cmr7 at 14.51799pt \font\preloaded=cmtt10 at 14.4pt \font\preloaded=cmssbx10 at 14.4pt \font\preloaded=manfnt 14787 words of font info for 50 preloaded fonts 14 hyphenation exceptions Hyphenation trie of length 6075 has 181 ops out of 35111 181 for language 0 No pages of output. Transcript written on tex.log. fmtutil [INFO]: log file copied to: /var/lib/texmf/web2c/tex/tex.log fmtutil [INFO]: /var/lib/texmf/web2c/tex/tex.fmt installed. fmtutil [INFO]: --- remaking pdftex with pdftex fmtutil: running `pdftex -ini -jobname=pdftex -progname=pdftex -translate-file=cp227.tcx *pdfetex.ini' ... This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian) (INITEX) restricted \write18 enabled. (/usr/share/texlive/texmf-dist/web2c/cp227.tcx) entering extended mode (/usr/share/texlive/texmf-dist/tex/plain/config/pdfetex.ini (/var/lib/texmf/tex/generic/tex-ini-files/pdftexconfig.tex) (/usr/share/texlive/texmf-dist/tex/plain/etex/etex.src (/usr/share/texlive/texmf-dist/tex/plain/base/plain.tex Preloading the plain format: codes, registers, parameters, fonts, more fonts, macros, math definitions, output routines, hyphenation (/usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex [skipping from \patterns to end-of-file...])) (/usr/share/texlive/texmf-dist/tex/plain/etex/etexdefs.lib Skipping module "grouptypes"; Loading module "interactionmodes"; Skipping module "nodetypes"; Skipping module "iftypes";) (/var/lib/texmf/tex/generic/config/language.def (/usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex)) Augmenting the Plain TeX definitions: \tracingall; Adding new e-TeX definitions: \eTeX, \loggingall, \tracingnone, register allocation; extended register allocation; Recycling: \addlanguage, \@nswer (not defined), \@sk, \b@dresponsetrue, \b@dresponsefalse, \ch@ckforyn, \mayber@cycle, \et@xabort, \et
Bug#1031949: Due to missing locales
On closer inspection, this seems to be due to missing locales. -- Gard signature.asc Description: PGP signature
Bug#1031949: tex-common: fmtutil fails to copy logs, installation fails
Hilmar Preusse writes: > On 25.02.23 Gard Spreemann (g...@nonempty.org) wrote: > > Hi Gard, > >> Installing a combination like >> >> texlive-latex-base texlive-latex-recommended texlive-latex-extra >> texlive-pictures texlive-luatex texlive-pictures-doc >> >> on a fresh Bullseye system with no TeX packages present fails with >> >> Building format(s) --all. >> This may take some time... >> fmtutil failed. Output has been stored in >> /tmp/fmtutil.LCLt5oyh >> Please include this file if you report a bug. >> > > Does [1] describe and (eventually) solve your issue? > Hi Hilmar, It seems to describe it, yes. And I solved it by generating the locales that my user had set. But it still seems like a bug that postinst fails if the system doesn't have a certain locale. Or maybe I'm viewing this incorrectly? Best, Gard signature.asc Description: PGP signature
Bug#1031949: tex-common: fmtutil fails to copy logs, installation fails
Norbert Preining writes: >> that my user had set. But it still seems like a bug that postinst fails >> if the system doesn't have a certain locale. Or maybe I'm viewing this >> incorrectly? > > Yes, you do ;-) > > Certain programs, in this case luatex, require correct locale setup to > work. It would be nice if we could detect these problems beforehand and > warn the user with a clear message, but also this is non-trivial. > > If the locale are incorrectly setup, there is not much to do but fail. > > Think about: You could configure to set your shell to > /bin/IamNotThereBash > and it would of course create a lot of problems. Maintainer scripts > cannot work around all possible misconfiguration of a system. Fair enough - you've convinved me :-) But should this bug remain open, with lowered severity and a better title and description, to document this fact for users? Unless there's already a bug covering this matter. Thanks for the help. Best, Gard signature.asc Description: PGP signature
Bug#1031949: tex-common: fmtutil fails to copy logs, installation fails
Hilmar Preuße writes: > The issue is reported against texlive-binaries: > #922500 . Fair enough - feel free to close #1031949 then. Thanks, and sorry for the noise :-) -- Gard signature.asc Description: PGP signature
Bug#1039001: hera: Updating to version 2.0.0
Source: hera Version: 1.0.0+dfsg-1 Severity: wishlist X-Debbugs-Cc: g...@nonempty.org Upstream released Hera 2.0.0 a while ago. Updating the package is taking a while, because upstream now bundles a quite modified copy of PHAT. While we can probably live with that, a bigger problem is that upstream hasn't reconciled what I believe are incompatible licenses for PHAT and Hera itself. An issue has been filed [1]. This bug is intended to serve as documentation. [1] https://github.com/anigmetov/hera/issues/13 -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/6 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled signature.asc Description: PGP signature
Bug#1039002: gudhi: Updating GUDHI to version 3.8.0
Source: gudhi Version: 3.7.1+dfsg-1 Severity: wishlist X-Debbugs-Cc: g...@nonempty.org This bug is meant to document the fact that that updating the GUDHI package to version 3.8.0 (or later) is currently blocked by #1039001. signature.asc Description: PGP signature
Bug#1080526: ITP: python-multiurl -- Python package for downloading multiple URLs at once
Package: wnpp Severity: wishlist Owner: Gard Spreemann X-Debbugs-Cc: debian-de...@lists.debian.org, g...@nonempty.org * Package name: python-multiurl Version : 0.3.1 Upstream Contact: European Centre for Medium-Range Weather Forecasts * URL : https://github.com/ecmwf/multiurl * License : Apache-2.0 Programming Lang: Python Description : Python package for downloading multiple URLs at once Python package for downloading multiple URLs at once This package is a simple prerequisite of python-cads-api-client [1]. I aim to maintain the package myself, together with the reverse dependencies (python-api-cads-client and python-cdsapi). [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078809 signature.asc Description: PGP signature
Bug#1078794: python3-cdsapi: Should depend on (currently not packaged) cads-api-client
Package: python3-cdsapi X-Debbugs-Cc: g...@nonempty.org Version: 0.7.0-1 Severity: important Version 0.7.0 of cdsapi introduced a dependency on cads-api-client [1]. This went unnoticed by me, as it's seemingly only used in code interacting with the beta version of the CDS API. I intend to package cads-api-client, and have cdsapi depend on it. [1] https://github.com/ecmwf-projects/cads-api-client/ signature.asc Description: PGP signature
Bug#1078809: ITP: python-cads-api-client -- Python client for the ECMWF CADS API
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Gard Spreemann X-Debbugs-Cc: g...@nonempty.org Severity: wishlist * Package name: python-cads-api-client Version : 1.2.0 Upstream Contact: European Centre for Medium-Range Weather Forecasts * URL : https://github.com/ecmwf-projects/cads-api-client * License : Apache-2.0 Programming Lang: Python Description : Python client for the ECMWF CADS API The existing python-cdsapi package now requires [1] the auxiliary cads-api-client, which I therefore intend to package. The piece of software is small, follows a sensible release cycle, has few dependencies, and is produced by the same organization as produces python-cdsapi. It should therefore be as easy for me to maintain as python-cdsapi has been for years. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078794 signature.asc Description: PGP signature
Bug#1061099: libimgui-dev: Please build sdlrenderer backend
Package: libimgui-dev X-Debbugs-Cc: g...@nonempty.org Version: 1.86+ds-1 Severity: normal The ImGui package's custom makefile currently does not build the sdlrenderer backend. Enabling building of it is as simple as adding backends/imgui_impl_sdlrenderer.cpp to said makefile's SRCS variable. Please consider making this change, as it likely has no drawbacks, only benefits. Best, Gard signature.asc Description: PGP signature
Bug#1061100: imgui: Please tag git commits that correspond to versions in the archive
Source: imgui X-Debbugs-Cc: g...@nonempty.org Version: 1.86+ds-1 Severity: minor ImGui is currently available in the following distributions and versions: * bullseye: 1.81+ds-1 * bookworm: 1.86+ds-1 * trixie: 1.89.6+ds-1 * sid: 1.89.6+ds-1 Of these, only the bullseye version is properly tagged in the git repository shared on Salsa. Please tag the git commit corresponding every version uploaded to the Debian archives to make the life of other DDs easier. (In my case, the lack of tags was a great annoyance when investigating #1061099) Best, Gard signature.asc Description: PGP signature
Bug#1061099: MR on Salsa
Control: tags 1061099 patch A fix is available as MR 1 on Salsa: https://salsa.debian.org/yangfl-guest/imgui/-/merge_requests/1 Best, Gard signature.asc Description: PGP signature
Bug#922233: lintian: spelling-error-in-patch-description should ignore "from" fields
Package: lintian Version: 2.6.0 Severity: minor Dear Maintainer, It is quite common, for example when using gbp to manage a package, that patches are formatted in email-style with a "from: Name " header. Perhaps Lintian should ignore spelling errors in this part of patches. I myself have to override Lintian thinking my name should be spelled "Guard". Best, Gard -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils 2.31.1-11 ii bzip2 1.0.6-9 ii diffstat 1.62-1 ii dpkg 1.19.2 ii dpkg-dev 1.19.2 ii file 1:5.35-2 ii gettext0.19.8.1-9 ii gpg2.2.12-1 ii intltool-debian0.35.0+20060710.5 ii libapt-pkg-perl0.1.34+b1 ii libarchive-zip-perl1.64-1 ii libcgi-pm-perl 4.40-1 ii libclass-accessor-perl 0.51-1 ii libclone-perl 0.41-1+b1 pn libdigest-sha-perl ii libdpkg-perl 1.19.2 ii libemail-valid-perl1.202-1 ii libfile-basedir-perl 0.08-1 ii libio-async-perl 0.72-1 ii libipc-run-perl20180523.0-1 ii liblist-moreutils-perl 0.416-1+b4 ii libparse-debianchangelog-perl 1.2.0-13 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl1.76-1 ii libxml-simple-perl 2.25-1 ii libyaml-libyaml-perl 0.76+repack-1 ii man-db 2.8.5-1 ii patchutils 0.3.4-2 ii perl 5.28.1-4 ii t1utils1.41-3 ii xz-utils 5.2.4-1 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b5 Versions of packages lintian suggests: pn binutils-multiarch ii libhtml-parser-perl3.72-3+b3 pn libtext-template-perl -- no debconf information
Bug#883544: src:tikzit: Unnecessary Build-Depends: libgnustep-gui-dev
On Tuesday 5 December 2017 02:40:29 CET Yavor Doganov wrote: > Please replace libgnustep-gui-dev with libgnustep-base-dev in your > Build-Depends. (Also, you can safely drop gnustep-make since > libgnustep-base-dev is always guaranteed to depend on it.) Hello, and thank you for informing me. I have prepared tikzit-1.0+ds-3 fixing this, and have asked my sponsor to upload it. > P.S. Unrelated to this bug report, but since it is important: > > Please always check if your package is involved in a library transition > before uploading. Your upload of tikzit/1.0+ds-2 on 21 November was in > the middle of a gnustep-base transition (#879738) and such uploads reset > the time it takes for the entire GNUstep stack to migrate to testing. > The only legitimate reason to upload during library transitions is when > you fix a bug *affecting* the transition. No harm done this time, but > please pay attention in the future. Thanks. I'm sorry about that! I was of the mistaken impression that leaf packages wouldn't hold up the transition. I'll take care to be better informed in the future. Best, Gard
Bug#883544: src:tikzit: Unnecessary Build-Depends: libgnustep-gui-dev
On Tuesday 5 December 2017 17:49:31 CET Yavor Doganov wrote: > There's no need to make an upload just to fix this. Understood. Andrew Shadura: Please ignore the sponsorship request. I'll let you know when there are more substantial changes. > Well, the new version of the library migrates together with all of the > (binNMUed) reverse dependencies and tikzit is definitely one of them. > Any sourceful uploads of rdeps reset the age-days and britney (the > testing migration script) does not consider it as valid candidate. > > You can check whether there's an ongoing transition with grep-excuses > or the PTS/tracker page of your package. For example, > >https://tracker.debian.org/pkg/adun.app > > correctly indicates that adun.app is currently involved in the > gnustep-sqlclient transition. Understood! Thanks! -- Gard
Bug#861649: Newer version uploaded
On Tuesday 26 December 2017 21:58:36 CET Tobias Frost wrote: > Hi Gard, > > I was checking your RFS, but I cannot get it compiled... Hello Tobias, and thanks for your feedback. Apparently this is a known regression [1] when building with CGAL 4.11. That version entered sid after last time I built GUDHI, so I hadn't noticed. Upstream says it will fix the problem in its next release, so I'll wait for that and then reupload. [1] https://lists.gforge.inria.fr/pipermail/gudhi-users/2017-December/97.html Best, Gard
Bug#861649: Newer version uploaded
On Wednesday 7 March 2018 19:32:48 CET Tobias Frost wrote: > But the lintian stuff I complained about is not completly fixed, there > is even a new tag: > I: gudhi source: quilt-patch-missing-description no-external-doc- > resources.patch > > Please run lintian after every build! Best, include it into pbuilder or > like! Remember "some sponsors are evil and pedantic [1] when running > lintian. > > [1] https://nthykier.wordpress.com/2012/02/23/some-sponsors-are-evil-a > nd-pedantic/ Ah, I'm sorry; I had accidentally run lintian too unpedantically and with an older version. I've adopted your suggested routine now. Thanks a lot! Some comments/questions on other lintian messages follow. > I: gudhi source: binary-control-field-duplicates-source field "section" > in package gudhui Since there's nothing inherent about one of the binary packages being in the same section as the source, I think it should be OK to keep this as is. Does that seem OK? > P: gudhi source: file-contains-trailing-whitespace debian/control (line > 110) Fixed. > P: gudhi source: package-uses-old-debhelper-compat-version 10 Fixed. > I: gudhi source: quilt-patch-missing-description no-external-doc- > resources.patch Fixed. > W: gudhi source: unnecessary-testsuite-autopkgtest-field Fixed. > I: python3-gudhi: spelling-error-in-binary usr/lib/python3/dist- > packages/gudhi.cpython-36m-x86_64-linux-gnu.so ment meant > I: python3-gudhi: spelling-error-in-binary usr/lib/python3/dist- > packages/gudhi.cpython-36m-x86_64-linux-gnu.so preambule preamble > I: python3-gudhi: spelling-error-in-binary usr/lib/python3/dist- > packages/gudhi.cpython-36m-x86_64-linux-gnu.so choosen chosen I'd prefer to consider these upstream bugs. I can report them, but I guess it's OK to leave these minor things unpatched? > W: libgudhi-examples: lib-recommends-documentation recommends: > libgudhi-doc I think this is a false report; libgudhi-examples is in fact not a library package. > I: libgudhi-doc: possible-documentation-but-no-doc-base-registration Fixed. > I: gudhui: spelling-error-in-binary usr/bin/gudhui preambule preamble See above. > P: gudhui: no-upstream-changelog Upstream doesn't supply one. > W: gudhui: binary-without-manpage usr/bin/gudhui This is a GUI tool without an upstream manpage. Should I make a stub one? > Please review d/copyright. I found at least one undocumented file which > is licensed Apache 2.0 and another one under LGPL3+. Neither are in > d/copyright. I'm looking into this, and will get back to you. Best, Gard
Bug#861649: Newer version uploaded
On Sunday 11 March 2018 00:18:32 CET Gard Spreemann wrote: > On Wednesday 7 March 2018 19:32:48 CET Tobias Frost wrote: > > Please review d/copyright. I found at least one undocumented file which > > is licensed Apache 2.0 and another one under LGPL3+. Neither are in > > d/copyright. > > I'm looking into this, and will get back to you. > I've updated the copyright information for the Apache 2.0-licensed file, as well as another MIT-licensed file with missing coverage. It turns out that the swaths of LGPL3+-licensed files were CGAL patches carried by upstream to support CGAL << 4.11. Since CGAL 4.11.1 is in buster, and there's already a lot of DFSG modifications to the upstream source in my package, I simply added deletion of these patches in the DFSG modifications and bumped the CGAL version requirements accordingly. I verified that the patches are only used when CGAL << 4.11 is detected. Is this satisfactory? A new version has been uploaded to mentors: https://mentors.debian.net/debian/pool/main/g/gudhi/gudhi_2.1.0+dfsg-1.dsc Thanks again! -- Gard
Bug#778635: python-scipy bundles library for L-BFGS-B minimization
On Fri, Mar 29, 2019 at 7:03 AM Drew Parsons wrote:
> Hi Gard, can you provide a simple test script so we can confirm that
> scipy works correctly after applying your L-BFGS-B patch?
Hi,
Attached is an improved patch, superseding the previous ones, for
using Debian's system LBFGSB library (build-depend on liblbfgsb-dev).
The patch can be tested with something like:
from scipy.optimize import fmin_l_bfgs_b, rosen
x0 = [0.2, -0.2, 0.1, -0.1]
res = fmin_l_bfgs_b(rosen, x0, approx_grad=True, factr=10)
print("Unbounded minimum:")
print(res)
res = fmin_l_bfgs_b(rosen, x0, approx_grad=True, factr=10,
bounds=len(x0)*[(-0.5, 0.5)])
print("Bounded minimum:")
print(res)
One can then compare the two outputs produced with the patch with the
ones produced without it.
The results may differ very slightly because the system LBFGSB uses LAPACK,
while the SciPy-bundled one uses LINPACK.
Best,
Gard
From: Gard Spreemann
Date: Tue, 2 Apr 2019 11:25:26 +0200
Subject: Use system LBFGSB.
---
scipy/optimize/setup.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/scipy/optimize/setup.py b/scipy/optimize/setup.py
index 67d2576..58666e6 100644
--- a/scipy/optimize/setup.py
+++ b/scipy/optimize/setup.py
@@ -38,7 +38,9 @@ def configuration(parent_package='',top_path=None):
numpy_nodepr_api['define_macros'])
else:
lapack['define_macros'] = numpy_nodepr_api['define_macros']
-sources = ['lbfgsb.pyf', 'lbfgsb.f', 'linpack.f', 'timer.f']
+lapack.setdefault('libraries', [])
+lapack['libraries'].append('lbfgsb')
+sources = ['lbfgsb.pyf']
config.add_extension('_lbfgsb',
sources=[join('lbfgsb',x) for x in sources],
**lapack)
Bug#989381: lintian: spelling-error-in-copyright is triggering on names
Package: lintian Version: 2.104.0 Severity: normal X-Debbugs-Cc: g...@nonempty.org Dear Maintainer, Lintian is triggering spelling-error-in-copyright upon seeing my first name (Gard) in the copyright field of some packages (example: [1]). It suggests that I should be named Guard instead. A bug filed with my parents was closed with wontfix, so I'll try the second best thing. I do not know how one would go about exempting names from such spellchecks, but could one perhaps at least whitelist the known quantity that is the maintainer's name? The bug seems at least superficially similar to #922233. [1] https://lintian.debian.org/sources/python-cdsapi Best, Gard -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-security') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-6-amd64 (SMP w/6 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.35.2-2 ii bzip2 1.0.8-4 ii diffstat1.64-1 ii dpkg1.20.9 ii dpkg-dev1.20.9 ii file1:5.39-3 ii gettext 0.21-4 ii gpg 2.2.27-2 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.39 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b7 ii libclone-perl 0.45-1+b1 ii libconfig-tiny-perl 2.26-1 ii libcpanel-json-xs-perl 4.25-1+b1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1.1 ii libdevel-size-perl 0.83-1+b2 ii libdpkg-perl1.20.9 ii libemail-address-xs-perl1.04-1+b3 ii libfile-basedir-perl0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl1.06-1.1 ii libhtml-html5-entities-perl 0.004-1.1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004003-1 ii liblist-compare-perl0.55-1 ii liblist-moreutils-perl 0.430-2 ii liblist-utilsby-perl0.11-1 ii libmoo-perl 2.004004-1 ii libmoox-aliases-perl0.001006-1.1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.118-1 ii libperlio-gzip-perl 0.19-1+b7 ii libproc-processtable-perl 0.59-2+b1 ii libsereal-decoder-perl 4.018+ds-1+b1 ii libsereal-encoder-perl 4.018+ds-1+b1 ii libtext-glob-perl 0.11-1 ii libtext-levenshteinxs-perl 0.03-4+b8 ii libtext-markdown-discount-perl 0.12-1+b1 ii libtext-xslate-perl 3.5.8-1+b1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b3 ii libtimedate-perl2.3300-2 ii libtry-tiny-perl0.30-1 ii libtype-tiny-perl 1.012001-2 ii libunicode-utf8-perl0.62-1+b2 ii liburi-perl 5.08-1 ii libxml-libxml-perl 2.0134+dfsg-2+b1 ii libyaml-libyaml-perl0.82+repack-1+b1 ii lzip1.22-3 ii lzop1.04-2 ii man-db 2.9.4-2 ii patchutils 0.4.2-1 ii perl [libdigest-sha-perl] 5.32.1-4 ii t1utils 1.41-4 ii unzip 6.0-26 ii xz-utils5.2.5-2 lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch pn libtext-template-perl -- no debconf information
Bug#273323: doc-debian: please ship typesettable version of social contract and dfsg documents
Diederik de Haas writes: > I wanted to print the Debian Social Contract, which turned out to be WAY > more difficult then I expected and then it should be. > > So I went to https://www.debian.org/social_contract and wanted to print > that. Apparently there isn't a print stylesheet for it, so if you print > that, you also get 'Blog', 'Micronews', 'Planet' and a search box. > Of course I didn't mind the Debian logo. > The last page (of the print preview) shows that it's available in a whole > bunch of languages, which is good, but undesirable for a print version. > And then you get a bunch of links, also undesirable for a print version. > > Then I went looking for a PDF version and didn't find anything. > > I did find a 'social-contract.txt.gz' (why compressed?), but that's > missing any form of nice formatting (that the webpage does have). > I did try 'zcat ' and editing that in > LibreOffice Writer, but apparently I've lost my skills in office > programs, so I bailed on that. Are any of these helpful? I'm happy to do more iterations – perhaps using LuaLaTeX and better fonts? This is so far just rushed lunch-work: https://nonempty.org/~gspr/social.tex https://nonempty.org/~gspr/social.pdf -- Gard signature.asc Description: PGP signature
Bug#273323: doc-debian: please ship typesettable version of social contract and dfsg documents
Diederik de Haas writes: > I only looked at the pdf and it's a very nice start, thanks! > > […] Thanks for the feedback. Daniel Lange's email made me think that there should perhaps be an authoritative version of the text, from which PDF, whatever-printable, HTML, etc. can be generated (using for example pandoc)? -- Gard signature.asc Description: PGP signature
Bug#983517: pytorch: Build documentation
Source: pytorch Version: 1.7.1-7 Severity: wishlist X-Debbugs-Cc: g...@nonempty.org Dear Maintainer, It would be nice to have a python-torch-doc package with the HTML documentation available, if it's not a complicated process. This is of course not urgent. I can look into the matter after the Bullseye release. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/6 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#940613: Any updates?
Hi, I see version 1.0 of this software was just released, and has been making its way around the web. It looks really neat! Do you think you'll be interested in picking back up your packaging efforts for after the Bullseye release? I'm happy to lend a hand. Best, Gard
Bug#985189: ITP: et -- Eternal Terminal (ET) is a remote shell that automatically reconnects without interrupting the session.
Jason Gauci writes: > Package name: et > Version : 6.1.4 > Upstream Author : Jason Gauci > URL : https://eternalterminal.dev/ > License : Apache > Programming Lang: C++ > Description : Eternal Terminal (ET) is a remote shell that > automatically reconnects without interrupting the session. > > Eternal Terminal (ET) is a remote shell that automatically reconnects without > interrupting the session. Hi, Might it be sensible to consider the full name "eternalterminal" (or "eternal-terminal") for this package? This would take pressure off the two-letter package name space, without giving up much (any?) discoverability. -- Gard signature.asc Description: PGP signature
Bug#985728: ITP: howdy -- Infrared Facial Authentication Module for Linux
Lem Severein writes: > Version 3.0.0 will introduce large changes and make Howdy a lot more > mature. I think it's time to try and package it within the main debian > archive. > > I am the main developer and maintainer of this package, and i > intend to continue to support Howdy. I'm not sure in what team > this package would fit, but a sponsor would be nice. Maybe this is already covered under the discussion of the more mature version 3 coming up, but: the shenanigans going on in the postinst script (like downloading stuff from the internet) seem to me quite worrisome. Best, Gard signature.asc Description: PGP signature
Bug#985728: ITP: howdy -- Infrared Facial Authentication Module for Linux
Lem Severein writes: > Unfortunately the dlib compilation step is necessary to be executed on the > machine itself. The build automatically enables certain hardware > accelerations, depending on system components. I think people would be quite upset with a d/postinst script that not only builds third-party software (already a problem), but also reaches out to the internet to fetch said software (without even getting into the fact that the authenticity of the downloaded software is not verified, which is a separate problem independent of Debian). Additionally, the current maintainer scripts don't look very idempotent (Policy § 6.2 [1]). > If complete offline installation is a must I could move the dlib into the > Howdy deb file. Not sure how that would work license wise. This sounds like a violation of Policy § 4.13 [2]. If the local dlib compilation is indeed a requirement for this package, I would hazard a guess that it is not distributable in Debian. [1] https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#maintainer-scripts-idempotency [2] https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies Best, Gard signature.asc Description: PGP signature
Bug#985728: ITP: howdy -- Infrared Facial Authentication Module for Linux
Lem Severein writes: > Hey Gard, > > Thanks for the helpful links, I fully understand your concern. > > I can do away with the numpy and opencv installs through the (much more > outdated) python-numpy and python-opencv debian packages respectively. > However, dlib does not seem to have such a package yet and having to > maintain that would be out of scope for me. I'm only a dlib user, not a > contributor, and i don't think it would be my place to package it. https://tracker.debian.org/pkg/dlib ? Or is this a different dlib? > However, dlib is available through pip and running that command would be > idempotent. OK, but your package cannot rely on stuff installed through pip! > (I wrongly hit "Reply" instead of "Reply All" in my last email, thanks for > letting me know) No problem. And I hope I'm not coming across as too negative; I just wanna make sure you're not wasting a lot of effort on packaging something that ends up being undistributable in Debian :-) -- Gard signature.asc Description: PGP signature
Bug#987360: Help needed?
I'm sad to see that we shipped Bullseye without an essential component of Sway. Is there anything I can do to assist in getting this bug fixed, perhaps for a potential future bullseye-packports package? -- Gard signature.asc Description: PGP signature
Bug#993031: ripser FTCBFS: hard codes the build architecture compiler
Thanks! Including your patch in a new upload now. -- Gard
Bug#969543: Related bug
Indeed. This seems to be related to #421344 [1]. Deleting the config symlink and reinstalling works. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421344 --- Gard
Bug#932726: ITP: python-pyspike -- Python library for the numerical analysis of spike train similarity
Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: python-pyspike Version : 0.6.0 Upstream Author : Mario Mulansky * URL : https://mariomulansky.github.io/PySpike/ * License : BSD-2-clause Programming Lang: Python, C Description : Python library for the numerical analysis of spike train similarity PySpike is a Python library for the numerical analysis of spike train similarity. Its core functionality is the implementation of the ISI-distance and SPIKE-distance as well as SPIKE-Synchronization. It provides functions to compute multivariate profiles, distance matrices, as well as averaging and general spike train processing. Mario Mulansky, Thomas Kreuz, PySpike - A Python library for analyzing spike train synchrony, SoftwareX, (2016), ISSN 2352-7110, http://dx.doi.org/10.1016/j.softx.2016.07.006. The library seems simple and mature, and I will be capable of maintaining it on my own. I will need a sponsor, and will enquire with the DDs that have sponsored packages for me in the past.
Bug#961783: gudhi: Update to upstream version 3.2.x
Source: gudhi Version: 3.1.1+dfsg-1+b1 Severity: wishlist This bug documents the fact that GUDHI's upstream 3.2.x versions now depend on the Hera library [1]. I am in the process of packaging that library, and GUDHI will be updated once it is done. [1] https://github.com/grey-narn/hera
Bug#961784: ITP: hera -- Library for computing bottleneck and Wasserstein distances between persistence diagrams
Package: wnpp Severity: wishlist Owner: Gard Spreemann * Package name: hera Version : 0~git20200309 Upstream Author : Arnur Nigmetov * URL : https://github.com/grey-narn/hera * License : BSD-3-clause Programming Lang: C++ Description : Library for computing bottleneck and Wasserstein distances between persistence diagrams Hera is a header-only library that implements algorithms from Michael Kerber, Dmitriy Morozov, and Arnur Nigmetov, "Geometry Helps to Compare Persistence Diagrams.", Journal of Experimental Algorithmics, vol. 22, 2017, pp. 1--20. (conference version: ALENEX 2016). that exploits geometry to compute Wasserstein and bottleneck distances between persistence diagrams much faster than plain matching-based algorithms. The library is being packaged because it is now an upstream dependency of GUDHI (src:gudhi). I intend to maintain the package myself.
Bug#890538: I seem to have stolen your package name
Hello, When I filed #961784 I did not notice this RFP. This resulted in me accidentally stealing the package name "hera" for an entirely unrelated package [1]. Sorry about this! [1] https://tracker.debian.org/pkg/hera Best, Gard signature.asc Description: PGP signature
Bug#978191: gudhi: FTBFS: Tangential_complex.h:957:40: error: no type named ‘Power_center_d’ in ‘Gudhi::tangential_complex::Tangential_complex, CGAL::Dynamic
Thank you for reporting this. It also revealed an upstream bug, which has been forwarded. I'm uploading a fix now. Best, Gard
Bug#972009: gudhi ftbfs with python3.9 as supported python version
Matthias Klose writes: > Package: src:gudhi > Version: 3.3.0+dfsg-1 > Severity: important > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: python3.9 > > seem to be a packaging error Indeed! Thanks for reporting. I think I know what's wrong, and will get to it soon.
