Bug#392721: ITP: pyecm -- Number factorization with the Elliptic Curve Method (ECM)
Package: wnpp Severity: wishlist Owner: Martin Kelly <[EMAIL PROTECTED]> * Package name: pyecm Version : 0.1 Upstream Author : Martin Kelly <[EMAIL PROTECTED]> * URL : http://www.sourceforge.net/projects/pyecm/ * License : GPL Programming Lang: Python Description : Number factorization with the Elliptic Curve Method (ECM) pyecm is a python program to factor numbers using the Elliptic Curve Method (ECM). It is relatively fast in that it can quickly factors numbers up to 50 digits. pyecm seems to be faster than gmp-ecm on many tests and is much more portable (it's written in python). -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#731205: python-mpmath: Please package the latest mpmath for gmpy2 compatibility
Package: python-mpmath Version: 0.15-1 Severity: normal python-gmpy has been renamed to python-gmpy2, so it will be deleted from the archive once no packages depend on it. AFAIK, python-mpmath is the only remaining package depending on it. mpmath versions 0.16 and greater have gmpy2 compatiblity, so the packaging should be just a version bump. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#610810: check the attach files
I don't see any attached files. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#690519: O: openclipart0.18 -- Open Clip Art Library
Package: wnpp Severity: normal I intend to orphan the openclipart0.18 package.
Bug#690518: O: openclipart -- Open Clip Art Library
Package: wnpp Severity: normal I intend to orphan the openclipart package.
Bug#691126: O: openclipart2 -- Open Clip Art Library
Package: wnpp Severity: normal I intend to orphan the openclipart2 package. The package description is: The Open Clip Art Library is a collection of 100% license-free, royalty-free, and restriction-free art that you can use for any purpose. . This package contains much more clipart than the standard openclipart, but it is sorted by artist (who created the clip art) rather than by subject (e.g. sports). . This package is a meta package installing both the SVG and PNG (converted from SVG) versions. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#693660: O: openclipart -- Open Clip Art Library
Package: wnpp Severity: normal I intend to orphan the openclipart package. The package description is: The Open Clip Art Library is a collection of 100% license-free, royalty-free, and restriction-free art that you can use for any purpose. . The clip art in this package is sorted by subject (e.g. sports). Openclipart 2 is sorted by artist (who created the clip art) and is much larger. . This package is a meta package installing both the SVG and PNG (converted from SVG) versions. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#693661: O: openclipart2 -- Open Clip Art Library
Package: wnpp Severity: normal I intend to orphan the openclipart2 package. The package description is: The Open Clip Art Library is a collection of 100% license-free, royalty-free, and restriction-free art that you can use for any purpose. . This package contains much more clipart than the standard openclipart, but it is sorted by artist (who created the clip art) rather than by subject (e.g. sports). . This package is a meta package installing both the SVG and PNG (converted from SVG) versions. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#690518: O: openclipart -- Open Clip Art Library
The reason I orphaned it was because my employer did not allow me to continue working on it, for legal reasons. The package was definitely a lot of work to maintain, but ultimately it is not a bad package. The builds take a long time because the package processes many image files, and there are some complications, but that goes with any significant software. If you're interested, I would go ahead and take it. Petter Reinholdtsen wrote: [Martin Kelly] I intend to orphan the openclipart package. Is there something one should know about ig if one was to consider taking over maintenance of the openclipart package? In other words, why do you want to orphan it? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#642676: dvorak7min: diff for NMU version 1.6.1-13.1
That's fine. I'm a student and was waiting for the semester to end (in about 3 weeks) to upload this. If your package works though, I have no problem with the upload; might as well keep it. Jakub Wilk wrote: tags 642676 + patch tags 642676 + pending thanks Dear maintainer, I've prepared an NMU for dvorak7min (versioned as 1.6.1-13.1) and uploaded it to DELAYED/3. Please feel free to tell me if I should delay it longer. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#663747: [r...@debian.org: Bug#663747: FTBFS with LibreOffice 3.5: basis-link gone/uninstallable with LibreOffice 3.5]
Filing this as important for now but this bug will become serious when LibreOffice 3.5.x gets uploaded to sid (and this *will* happen before the wheezy freeze) I should have time to apply that patch to 2.0-1 within the next week or two; I will do so as soon as I can. [1] and you even missed -12, but that happily only was a simple rebuild so this upload should have worked. Bad nevertheless. I submitted this package for upload last summer (around July 2011), but Moritz Muelenhoff (my sponsor) was very busy so it didn't get uploaded until now. That may be why your changes were not incorporated into it. In any case, I will fix it soon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#663747: [r...@debian.org: Bug#663747: FTBFS with LibreOffice 3.5: basis-link gone/uninstallable with LibreOffice 3.5]
Thanks; I'm merging in the changes you mentioned. However, what should I do about the changelog? If I retroactively add entries, the dates will be out of order (which looks bad). But if I skip versions that exist (-12, -13), that looks bad too. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#357147: References non-existant file in /home....
Why is this a problem? It is from the original source on the openclipart.org website. They were willing to publish these files wiht the /home references in there, so why should we care? It is just metadata in any case. Additionally, this is not at all the only file with these /home references; they are all over the place. Finding and fixing these would either involve a very painful patch or an automated script, but again, I don't see the point. I will close this; feel free to reopen if you disagree. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#664037: openclipart-svg: Update is too large
I am in the process of renaming openclipart -> openclipart2 and reintroducing the old openclipart. This will give you a partial fix, in that you can use the old openclipart for a smaller package. But it is still not a 100% fix. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#664037: openclipart-svg: Update is too large
Note: openclipart-0.18+dfsg-14 has just been uploaded, reintroducing the old (smaller) openclipart. openclipart2 is about to be uploaded as well, so you can pick either package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#664037: openclipart-svg: Update is too large
Also note that the newest package uses optipng during the build process to compress the png files, which reduces the package size for openclipart-png. Unfortunately, it won't help with openclipart-svg. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#720360: git am should recognize DEP-3 patch headers
On Wed, 21 Aug 2013 00:37:41 +0200 Florian Schlichting wrote: > Package: git > Version: 1:1.7.10.4-2 > Severity: wishlist > > It would be helpful to have 'git am' recognize DEP-3 style patch headers > in Debian. While it correctly extracts the author and description when > the headers are called 'Subject' and 'From', it fails to do so when the > alternative forms 'Description' and 'Author' are used. Hi Florian, I agree with this, and at the time of writing, this issue is still oustanding. That said, I'm wondering whether the solution is: - Patch upstream git to do this - Patch only Debian's git to do this (would require the git package maintainer to rebase the patch after every release... possible quite ugly) - Modify dquilt to generate git am compatible headers. I don't feel like I have enough background to suggest which of these is the right way to go, but I am interested in helping to get this done, as it would be very useful to myself and others. Any thoughts?
Bug#776233: openclipart: Some images, particularly PNGs, are far too large
Hi, Thank you for the bug report; I quite agree with you. I am no longer the openclipart maintainer (openclipart is currently orphaned), but whoever becomes maintainer next should definitely look at this. Thanks, Martin On 01/25/2015 10:47 AM, David Wright wrote: > Package: openclipart > Version: 1:0.18+dfsg-14 > Severity: normal > > Dear Maintainer, > > Some of the images in this package are far too large. For example > -rw-r--r-- 1 3769493 Jun 4 2012 microchip_v.2_havok_redh_01.png > -rw-r--r-- 1 3055767 Jun 4 2012 salad_mateya_01.png > -rw-r--r-- 1 2829335 Jun 6 2012 stop_sign_right_font_mig_.png > -rw-r--r-- 1 2819817 Jun 5 2012 stop_sign_miguel_s_nchez_.png > -rw-r--r-- 1 1831764 Jun 4 2012 apple_mateya_01.png > -rw-r--r-- 1 1639377 Jun 4 2012 paprika_mateya_01.png > -rw-r--r-- 1 1593583 Jun 4 2012 cake_mateya_01.png > -rw-r--r-- 1 1564746 Jun 4 2012 bread_mateya_01.png > -rw-r--r-- 1 1535656 Jun 4 2012 pasta_mateya_01.png > -rw-r--r-- 1 1481671 Jun 4 2012 egg_mateya_01.png > -rw-r--r-- 1 1237372 Jun 4 2012 cheese_mateya_01.png > -rw-r--r-- 1 1198050 Jun 4 2012 salami_mateya_01.png > -rw-r--r-- 1 1086920 Jun 4 2012 banana_mateya_01.png > -rw-r--r-- 1 1035599 Jun 4 2012 milk_mateya_01.png > > Looking inside: > /usr/share/openclipart/png/computer/microchip_v.2_havok_redh_01.png PNG > 16000x14464 > /usr/share/openclipart/png/signs_and_symbols/stop_sign_miguel_s_nchez_.png > PNG 20990x29700 > > At 100dpi, a stop sign that large would completely block the alley behind my > house! > > I have visited the site https://openclipart.org/ and found some of these > images. > Downloading the largest of the three sizes available there for the microchip > gives > -rw-r--r-- 1 442072 Jan 25 10:22 Anonymous-microchip-v.2.png > (2381x2112 pixels). > > The effect on a laptop with a 1.8GHz twin processor and 2GB memory running > X and the fvwm window manager is that everything stops for several minutes, > including the clock display and, worse, the mouse, which means you have to > be careful not to click anywhere because when the click action happens, the > mouse might be anywhere on the screen after it has played catch-up. > > Please replace the large images with smaller versions. If large PNGs are > required, they can be generated from the svg files. > > Cheers, > David. > > -- System Information: > Debian Release: 7.8 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: i386 (i686) > > Kernel: Linux 3.2.0-4-686-pae (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 openclipart depends on: > ii openclipart-libreoffice 1:0.18+dfsg-14 > ii openclipart-png 1:0.18+dfsg-14 > ii openclipart-svg 1:0.18+dfsg-14 > > openclipart recommends no packages. > > openclipart suggests no packages. > > -- no debconf information > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#796398: Patch to fix SHA issue
This bug is also hitting me; I would be very grateful for a fixed package! On Mon, 31 Aug 2015 21:11:18 + "Warmerdam, B. (Bart)" wrote: > > This patch can be used to fix it: > https://github.com/funtoo/keychain/commit/d76c2e9aa1c05ceac1c2d06a29783ee95e876a37 > >
Bug#805264: What I expected to to happen with gmpy2.mpz/gmpy2.xmpz
On Mon, 16 Nov 2015 10:36:21 -0800 David George Henderson III wrote: > What I'm attempting to do is perform a dot product of an int32 array > with a list of mpz integers. > > z=np.zeros(10,np.int32) > y=[gmpy.mpz[1] *10 ] > > summation = gmp.xmpz(0) > for i in range(0,10): > product = gmpy2.xmpz(z[i]) > product *= y[i] > summation += product > > The bug prevents this from running. > > My workaround defeats the purpose of using gmpy2.xmpz typed variables : > > for i in range(0,10): > product = gmpy2.xmpz(int(z[i])) > > > > Hi, Thanks for your bug report. I'm not surprised that gmpy2.[x]mpz doesn't have a constructor for handling the numpy int32 type; to do so would likely require gmpy to link against numpy, introducing an undesired dependency into the library. I'm guessing that exporting the int32 to standard Python int will be your best bet, as int32 and mpz are different objects. Is this causing a performance bottleneck? This issue is present in current versions of gmpy (2.0.7) as well as the 2.0.3 version you reported against. You may consider raising it with upstream gmpy on github: https://github.com/aleaxit/gmpy Regards, Martin
Bug#805264: constructor gmpy2.xmpz(z[k]) where z is a numpy int32 array - more context
Of course I can't rule out some implementation of this that I haven't thought of. If this is important to you, I recommend raising it as an Issue on the gmpy github site I linked; the author of gmpy is quite responsive and should be able to help. Since I'm only the Debian maintainer rather than the upstream maintainer and this is an upstream rather than a packaging bug, there's not much more I can do. On Wed, Nov 18, 2015 at 12:03 AM, David George Henderson III < d...@pop-server.its.caltech.edu> wrote: > Hi Martin, > > I'm not far enough along to create a performance comparison. > > The immediate functionality is the gram-schmidt factorization of a lattice > basis matrix stored in columns of int32 vectors. The numpy array of objects > are the orthogonalized vectors and the dot product is the time-critical > code to optimize. Please forgive my jargon, its not relevant to the bug. > > It seems plausible that there is a bytecode reference to an int32 array > component that is defined independently of the numpy library. If this is > indeed the case, the gmpy2.xmpz() constructor could be reworked to accept > this datatype as input. After all, Python2 short ints are int32. > > The code I'm writing handles each of native int(), gmpy2.mpz() and > gmpy2.xmpz() objects for the containers for big integer vector components. > Each orthogonalized vector is as an numpy array of object (each object is a > xmpz or other bigint container). > > The gmpy2.xmpz objects are going to have extremely large magnitudes. Its > unclear whether the int(z[i]) is going to be a big hit in performance. What > is clear that I'm going to be recalculating the int32 arrays quite > frequently in each step of lattice basis reduction. > > A numpy dtype=int32 array holds mutable int32 array components. This is > the functionality I'd like to mimic with a numpy dtype=object array where > each object is a mutable xmpz. > > I'll certainly be doing a timing analysis on each implementation > alternative. I'm not counting on the gmpy2.xmpz working because it is > written up as experimental. > > Would you please forward this elaboration to the ultimate maintainer of > gmpy2? > > Thanks in advance, > > David >
Bug#767417: python-gmpy2: FTBFS: test failures
On 10/30/2014 03:02 PM, Sebastian Ramacher wrote:
> Source: python-gmpy2
> Version: 2.0.4-1
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
>
> python-gmpy2 failed to build on i386, armel, armhf, mips, mipsel,
> kfreebsd-i386 and powerpc:
> | File "test/test_mpz_io.txt", line 71, in test_mpz_io.txt
> | Failed example:
> | mpz(D("1e10"))
> | Expected:
> | mpz(100)
> | Got:
> | mpz(100L)
> | **
> | 1 items had failures:
> |1 of 68 in test_mpz_io.txt
> | ***Test Failed*** 1 failures.
> | Results for: test_mpz_io Attempted: 68 Failed:1
> | Results for: test_mpz_pack_unpack Attempted: 16 Failed:0
> | Results for: test_mpz_to_from_binary Attempted:6 Failed:0
> |
> | Summary - Attempted: 964 Failed:3
> | make: *** [test-python2.7] Error 1
> | debian/rules:45: recipe for target 'test-python2.7' failed
>
> For a full build log, see
> https://buildd.debian.org/status/fetch.php?pkg=python-gmpy2&arch=i386&ver=2.0.4-1&stamp=1414367107.
>
> Cheers
>
Thanks; it looks like it failed in the exact same way for all the 32-bit
architectures. This is the first time that the build is contingent on
the unit tests passing, and it appears we found a bug that upstream
didn't know about! Looks like we just need to change int to uint64 or
something similar. I should be able to patch it soon; we can put the
patch into our builds and then send it upstream.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#760360: openclipart: build requires >100 GB of memory, errors ignored
Hi Michael, Thank you for the bug report. I'm no longer the maintainer of openclipart, but I looked at this bug a little bit. It appears one particular file is causing this: office/telephone/mobile_phone_01.svg I can easily repro the issue by trying to open it with inkscape: inkscape office/telephone/mobile_phone_01.svg I get the "unable to convert" warning over and over again and inkscape hangs with ever increasing memory. This suggests to me that the file has always been corrupt but previous versions of inkscape ignored that. I do know that this package used to happily build a few years ago. It looks like inkscape has a bug, and this file may also be corrupt. If the file is corrupt, inkscape should handle the error gracefully. If the file is not corrupt, then inkscape should be able to process the file without issue. On 09/03/2014 02:12 AM, Michael Tautschnig wrote: Package: openclipart Version: 1:0.18+dfsg-14 Severity: wishlist Usertags: goto-cc The following is a kind of experience report as I'm not entirely sure whether there is anything wrong with my set up, but I'm seeing the following problem when auto-building the package using pbuilder/cowbuilder: [...] Processing ./office/telephone/mobile_phone_01.svg ** (inkscape:32107): WARNING **: helper-fns::helperfns_read_vector() Unable to convert "0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0" to number ** (inkscape:32107): WARNING **: helper-fns::helperfns_read_vector() Unable to convert "0,0,0,0,0.01672,0,0,0,0,0,0,0,0,0,0,0,0,0,0.8916,0" to number ** (inkscape:32107): WARNING **: helper-fns::helperfns_read_vector() Unable to convert "0,0.025022,0.008303,0.375,0,0,0,0,0.07506,0,0,0,0,0.033326,0,0,0,0,0,1" to number ** (inkscape:32107): WARNING **: helper-fns::helperfns_read_vector() Unable to convert "1,0.3285714285714286,0,0,0,0,0,0,0.2571428571428571,0,0,0,1,0,0,1,1,0,0,0" to number ** (inkscape:32107): WARNING **: helper-fns::helperfns_read_vector() Unable to convert ",0.8571428571428572,1,1" to number Killed Processing ./office/telephone/telephone_sauvetage_yves_01.svg Background RRGGBBAA: ff00 Area 0:0:163.286:163.286 exported to 163 x 163 pixels (90 dpi) [...] The reason this was killed was me manually killing that inkscape process running beyond 100 GB of main memory. I'm not quite sure what sort of system the package was originally built on, but requiring that much memory seems hardly practical. Furthermore, having the build continue despite the errors isn't a good idea I believe, as indeed the package build succeeded despite me having killed the conversion process. Best, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#763095: inkscape: Infinite loop with warnings on Openclipart svg file open
Package: inkscape Version: 0.48.5-2 Severity: important Dear Maintainer, I have noticed that, when opening a file from the openclipart-0.18+dfsg package, inkscape infinite loops while displaying the following warning: ** (inkscape:334): WARNING **: helper-fns::helperfns_read_vector() Unable to convert ",0.8571428571428572,1,1" to number In addition, there are reports that memory usage continues to grow indefinitely. The file is clipart/office/telephone/mobile_phone_01.svg, and the repro is very simple: inkscape clipart/office/telephone/mobile_phone_01.svg You can find the file via apt-get source openclipart. This bug report was prompted by a related bug report to on Openclipart (#760360). -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages inkscape depends on: ii gconf-service3.2.6-3 ii libaspell15 0.60.7~20110707-1.1 ii libatk1.0-0 2.12.0-1 ii libatkmm-1.6-1 2.22.7-2.1 ii libc62.19-10 ii libcairo21.12.16-3 ii libcairomm-1.0-1 1.10.0-1.1 ii libfontconfig1 2.11.0-6.1 ii libfreetype6 2.5.2-1.1 ii libgc1c2 1:7.2d-6.3 ii libgcc1 1:4.9.1-12 ii libgconf-2-4 3.2.6-3 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libglib2.0-0 2.40.0-5 ii libglibmm-2.4-1c2a 2.40.0-1 ii libgnomevfs2-0 1:2.24.4-6 ii libgomp1 4.9.1-12 ii libgsl0ldbl 1.16+dfsg-2 ii libgtk2.0-0 2.24.24-1 ii libgtkmm-2.4-1c2a1:2.24.4-1.1 ii libgtkspell0 2.0.16-1.1 ii liblcms2-2 2.6-3 ii libmagick++5 8:6.7.7.10+dfsg-4+b1 ii libmagickcore5 8:6.7.7.10+dfsg-4+b1 ii libpango-1.0-0 1.36.6-1 ii libpangocairo-1.0-0 1.36.6-1 ii libpangoft2-1.0-01.36.6-1 ii libpangomm-1.4-1 2.34.0-1.1 ii libpng12-0 1.2.50-2 ii libpoppler-glib8 0.26.4-1 ii libpoppler46 0.26.4-1 ii libpopt0 1.16-10 ii librevenge-0.0-0 0.0.1-3 ii libsigc++-2.0-0c2a 2.2.11-4 ii libstdc++6 4.9.1-12 ii libwpg-0.3-3 0.3.0-3 ii libx11-6 2:1.6.2-3 ii libxml2 2.9.1+dfsg1-4 ii libxslt1.1 1.1.28-2 pn python:any ii zlib1g 1:1.2.8.dfsg-2 Versions of packages inkscape recommends: pn aspell ii imagemagick 8:6.7.7.10+dfsg-4+b1 ii libgnomevfs2-extra 1:2.24.4-6 ii libwmf-bin 0.2.8.4-10.3 pn perlmagick pn pstoedit ii python-lxml 3.3.5-1+b1 ii python-numpy1:1.8.2-2 ii transfig1:3.2.5.e-4 Versions of packages inkscape suggests: pn dia | dia-gnome pn libsvg-perl pn libxml-xql-perl pn python-uniconvertor ii ruby 1:2.1.0.4 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#465446: pyecm: vague claims in long description
You're right: gmp-ecm is just as portable as pyecm. Sorry about that. As for the "faster" claim, I believe I was mistaken. On some tests it seemed to be, but upon further testing gmps-ecm is faster by a constant factor of about 3. Pyecm's main advantage is ease of use. I apologize for the innacurate description (no harm intended) and will change it in the next version, which should be coming within a few months. Martin Laurent Fousse wrote: Package: pyecm Version: 1.2.2-1 Severity: wishlist Hello, I noticed the following sentence in the long description: pyecm seems to be faster than gmp-ecm on many tests and is much more portable (it's written in Python). Concerning the portability, I don't think it's relevant to debian users as both programs are available in all released and unofficial ports that I know of. I don't think it's accurate either, as python itself is written in C just like gmp-ecm and I'd like to know a specific plateform where python and pyecm are available and gmp-ecm is not. As for the "faster" claim, could you provide specific examples where pyecm outperforms gmp-ecm? It's of particular interest to the gmp-ecm developers. Thanks! Regards, Laurent. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#425174: ITP: python-gmpy -- Interfaces GMP to Python for fast, unbound-precision computations
Package: wnpp Owner: Martin Kelly <[EMAIL PROTECTED]> Severity: wishlist * Package name: python-gmpy Version : 1.01 Upstream Author : Alex Martelli <[EMAIL PROTECTED]> * URL : http://gmpy.sourceforge.net/ * License : LGPL Programming Lang: Python Description : Interfaces GMP to Python for fast, unbound-precision computations gmpy is a C-coded Python extension module that wraps the GMP library to provide to Python code fast multiprecision arithmetic (integer, rational, and float), random number generation, advanced number-theoretical functions, and more. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#488941: python-gmpy: Please upload gmpy 1.03 (patch attached)
I have no problem with joining DPMT; I at a student and during the school year I often have very little time to maintain packages. If someone wants to help me with this, I have no problem with it. I do have a question about your patch, however. Isn't this a strange way to create a new release? Why would you add version information to the rules file? Why not just follow the standard procedure here: http://www.debian.org/doc/maint-guide/ch-update.en.html#s-newupstream-real ? I am new to maintaining and don't quite understand how this patch would be used to create a new version. Ondrej Certik wrote: Package: python-gmpy Version: 1.02~1.dfsg.1-1 Severity: wishlist Tags: patch Hi, I packaged the new upstream release, the package builds, it's lintian clean. The patch is attached. I also added myself to uploaders and the DM upload field. Feel free to remove it if you disagree. I also imported the package to the DPMT repositories. Let me know if you are against maintaining it in there and I'll remove it. However, I strongly suggest you are not against :), as it is much easier to maintain it in DPMT, as anyone can easily fix the package and if you stay as the maintainer, you will need to approve all changes in the end and you will have to upload it. Let me know if you have any questions to the patch and also let me know if you are busy but otherwise agree with the patch, I'll ask some other DD to upload the package. Thanks a lot, Ondrej -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (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/bash Versions of packages python-gmpy depends on: ii libc6 2.7-12 GNU C Library: Shared libraries ii libgmp3c2 2:4.2.2+dfsg-3 Multiprecision arithmetic library ii python2.5.2-1An interactive high-level object-o ii python-central0.6.7 register and build utility for Pyt python-gmpy recommends no packages. -- no debconf information Index: debian/control === --- debian/control (revision 5800) +++ debian/control (revision 5802) @@ -2,10 +2,12 @@ Section: python Priority: optional Maintainer: Martin Kelly <[EMAIL PROTECTED]> +Uploaders: Ondrej Certik <[EMAIL PROTECTED]> Build-Depends: debhelper (>= 5.0.38), python-all-dev (>= 2.3.5-11), python-central (>= 0.5.6), libgmp3-dev (>= 4.0.1) -Standards-Version: 3.7.3 +Standards-Version: 3.8.0 Homepage: http://gmpy.sourceforge.net/ XS-Python-Version: >= 2.3 +XS-DM-Upload-Allowed: yes Package: python-gmpy Architecture: any Index: debian/changelog === --- debian/changelog(revision 5800) +++ debian/changelog(revision 5802) @@ -1,3 +1,13 @@ +python-gmpy (1.03.ds-1) unstable; urgency=low + + * New upstream release + * orig-tarball target added to debian/rules for generating the orig.tar.gz + * Bump Standards-Version to 3.8.0 (no changes needed) + * XS-DM-Upload-Allowed: yes field added + * Ondrej Certik added to uploaders + + -- Ondrej Certik <[EMAIL PROTECTED]> Wed, 02 Jul 2008 10:03:49 +0200 + python-gmpy (1.02~1.dfsg.1-1) unstable; urgency=low * New upstream release Index: debian/rules === --- debian/rules(revision 5800) +++ debian/rules(revision 5802) @@ -42,3 +42,10 @@ binary: binary-indep binary-arch .PHONY: build clean binary-indep binary-arch binary install + +VER=1.03 +orig-tarball: + wget http://gmpy.googlecode.com/files/gmpy-$(VER).zip; + unzip gmpy-$(VER).zip + tar czf python-gmpy_$(VER).ds.orig.tar.gz gmpy-$(VER) + rm -rf gmpy-$(VER) gmpy-$(VER).zip -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#488941: python-gmpy: Please upload gmpy 1.03 (patch attached)
No, the version is there just to create an original tarball. Use it like this: Isn't this what the watch file is for? svn+ssh://[EMAIL PROTECTED]/svn/python-modules/packages/python-gmpy/trunk I don't have an account; how do I get one? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#488941: python-gmpy: Please upload gmpy 1.03 (patch attached)
Watch file can only download the .zip file, but then you need to repackage it. You can do it by hand, or you can call my target, that I implemented. Yes I suppose that is useful. svn+ssh://[EMAIL PROTECTED]/svn/python-modules/packages/python-gmpy/trunk I don't have an account; how do I get one? Here is our page: http://wiki.debian.org/Teams/PythonModulesTeam Create an account yourself at alioth: http://alioth.debian.org/ Then sign in to debian-python mailinglist and ask there to have your account added to the DPMT group. Then you can edit svn. You can reference me, that I asked you to do it. :) I will do all that. Anyway, is it ok to upload the package as it is? (The new upstream is important for me) Yes you may upload as is. Thanks. I should tell my sponsor (Piotr Ożarowski) about this, right? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#585965: Openclipart orphanage
I'm interested in adopting openclipart. I'm not a Debian developer, so I would need someone to sponsor the uploads, but I would be happy to maintain the package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#588878: Still interested in adopting dvorak7min?
Yes, I am still interested. On 12/21/2010 06:53 PM, Francois Marier wrote: Hi Martin, Are you still interested in taking over the dvorak7min package? Cheers, Francois -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#588878: Possibly adopting dvorak7min
Hi, I'm the current maintainer for python-gmpy and pyecm, although I'm not a Debian developer. I may be interested in adopting dvorak7min. I use the Dvorak keyboard layout and this program helped me learn it, so I'd like to keep it in the repository if possible! The package looks simple enough to maintain. The one question I have is: What I need to know to use the collab-maint git repository for dvorak7min? Do I need to upload releases into it? If so, how do I get a username and where can I find instructions for uploading to it? Thanks, Martin Kelly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#585965: Openclipart orphanage
Hi Martin, are you still interested? I'll help out with updating openclipart and I can sponsor your uploads. Yes, I am still interested. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#610810: [imms-audacious] The plugin is not working with audacious 2.4.2-1
It appears that rc10 doesn't compile with new versions of audacious but code from the upstream subversion does. I'm not the maintainer, but I am willing to create a package from the upstream subversion to make imms work again; I have already done most of the work to get that done privately. If I do so, would it be okay to upload it? I'm not a DD so I can't upload it myself. If the maintainer responds soon, I could have him approve it first. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#618216: python-gmpy: FTBFS: Unsatisfiable build-dependency: libgmp3-dev(inst ~*=PROVIDED=*= ! >= wanted 4.0.1)
On 03/13/2011 01:33 PM, Lucas Nussbaum wrote: Source: python-gmpy Version: 1.14-1 Severity: serious Tags: wheezy sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20110313 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. I know the cause of this and it should be easy to fix. I'll get to it as soon as I can, probably within a week or two. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#923641: dvorak7min FTCBFS: does not pass cross tools to make
On 3/3/19 1:40 AM, Helmut Grohne wrote: Source: dvorak7min Version: 1.6.1+repack-3 Tags: patch User: helm...@debian.org Usertags: rebootstrap dvorak7min fails to cross build from source, because it does not pass cross tools to make. The easiest way of fixing that - using dh_auto_build - makes dvorak7min cross buildable. Please consider applying the attached patch. Helmut Thanks for the patch! I have put it in git and requested an upload from Francois Marier, so it should go in soon.
Bug#958138: RM: python-gmpy/oldstable -- ROM; dead upstream, needs Python 2
Package: ftp.debian.org Severity: normal This package has been dead upstream for many years now (the final release was 1.17, in 2013). It's superceded by gmpy2, which is already packaged as python3-gmpy2. All reverse dependencies are currently removed from unstable as they don't support Python 3. Even if they weren't, the reverse dependencies can could all use gmpy2 if they are at some point patched to support Python 3 and added back into unstable: $ apt-cache rdepends python-gmpy python-gmpy Reverse Depends: obfsproxy python-tlslite-ng python-sympy python-gmpy-doc obfsproxy and python-sympy support gmpy2 in source code, though the packaging doesn't depend on it. If these packages ever came back (by supporting Python 3), they could add a dependency on python3-gmpy2 instead. python-tlslite-ng does not support gmpy2, but it uses gmpy in a trivial way (uses 5 functions or so in a single location, with easy gmpy2 replacements). Thus it could be easily patched.
Bug#937791: Blocked on reverse dependencies
On 4/13/20 2:25 PM, Moritz Mühlenhoff wrote: On Sat, Feb 08, 2020 at 11:13:20AM -0800, Martin Kelly wrote: On Sat, 8 Feb 2020 10:55:23 -0800 Martin Kelly wrote: On 2/2/20 8:39 PM, Sandro Tosi wrote: should we remove this package then? or do you want to generate a python3-gmpy? I didn't realize, but it looks like this package actually does support Python 3. I had assumed we would let this package die when Python 2 dies, since the package is dead upstream since 2013. However, looking at the popcon stats, the original python GMPY is still much more popular than than python GMPY2 (3543 vs 443). So I think it's worth keeping this package. I'm working on converting it over now and should be able to get it done in the next few weeks. Is it possible to remove the AUTORM tag until this is done, or should we let it get deleted and upload a new python3-gmpy package after that? Looking further, it seems that with current versions of Python 3 (I tested with 3.7.3), the old GMPY 1.17 is no longer passing. When I run test3/gmpy_test.py, I'm getting: $ python3 test3/gmpy_test.py ... 8 items had failures: 1 of 4 in gmpy_test_cvr 4 of 126 in gmpy_test_cvr.__test__.user_errors 1 of 1 in gmpy_test_dec 2 of 2 in gmpy_test_mpf 2 of 60 in gmpy_test_mpf.__test__.binio 2 of 2 in gmpy_test_mpq 2 of 4 in gmpy_test_mpz 7 of 25 in gmpy_test_rnd.__test__.rand 1504 tests in 42 items. 1483 passed and 21 failed. ***Test Failed*** 21 failures. In contrast, the tests for GMPY 2 all succeed, so I think the author clearly intended for tests to fully pass. Since this hasn't been maintained for 7 or so years, I'm not too surprised. Given this, I think we should let this package be removed and consider resurrecting it in the future if people ask for it and someone will step up to maintain it. Sandro, is there anything more to do if I want to let this package be removed, or do I just wait for the auto-removal? Martin, what are you referring here to with "removed"? Removal from testing or unstable? The former happened automatically in the mean time, the latter needs a bug using "reportbug ftp.debian.org" Cheers, Moritz Thanks for clarifying; I filed a bug to remove this package from unstable, as it's dead upstream and all reverse dependencies are removed from unstable at this point: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958138
Bug#958043: python3-gmpy2: import gmpy2 fails
On 4/17/20 10:08 AM, lkcl wrote: Package: python3-gmpy2 Version: 2.1.0~b4-1+b1 Severity: important (please ignore debian release information below, a rolling release is used) python3.7 is being used, here (not python3.8) however python3-gmpy2 has *only* been compiled for python3.8. this is severely exclusionary, forces people to hard-upgrade to a set and specific version of python, and very bad practice. this bugreport's severity might need to be upgraded. most "good" python packages compile multiple versions not just for python2 and python3, they compile for multiple versions *of* python2 (or, used to) and python3. this package should cookie-cut such other packages, there are plenty that do this. Hi, It appears that python3.7 has been removed from the python3-all list of supported versions (see the changelog for python3-all and for dh-python). As a result, I'm actually seeing numpy (which you cited as an example) no longer working with python3.7 either. You can test this by doing cowbuilder, installing python3.7 and python3-numpy, and then trying to import numpy with python3.7. It's failing for me. Looking at the pybuild code and manpage, it appears it already handles exactly this problem and should be doing the right things without extra work. From "man pybuild": DEBHELPER COMMAND SEQUENCER INTEGRATION • build depend on dh-python, • build depend on all supported Python interpreters, pybuild will use it to create a list of interpreters to build for. Rec‐ ognized dependencies: • python3-all-dev - for Python extensions that work with Python 3.X interpreters, • python3-all-dbg - as above, add this one if you're building -dbg packages, - python3-gmpy2 already build-depends on python3-all-dev, which should be sufficient for compiling for all interpreters. The fact that python3.7 is no longer a supported version is a separate issue and not specific to this package. I've CC'ed Piotr Ożarowski. Piotr, please let me know if I'm misunderstanding something here or need to take a different action.
Bug#977786: O: pyecm -- integer factorization with the Elliptic Curve Method (ECM)
Package: wnpp Severity: normal I intend to orphan the pyecm package. It is little-used (popcon score 19). The package description is: pyecm is a Python program to factor numbers using the Elliptic Curve Method (ECM). It is relatively fast in that it can quickly factors numbers up to 50 digits. . Because it is written in Python, pyecm is very portable. It is also fairly easy to use. Use of python-gmpy and/or python-psyco will speed it up immensely.
Bug#937791: Blocked on reverse dependencies
On 2/2/20 8:39 PM, Sandro Tosi wrote: $ apt-cache rdepends python-gmpy python-gmpy Reverse Depends: obfsproxy python-tlslite-ng python-sympy python-gmpy-doc Dependencies on obfsproxy and python-sympy documented with affects and blocks. python-tlslite-ng has been removed already, there are no more reverse dependencies on python-gmpy, what should we do next? i see the source package doesnt produce any python3 package, and the last changelog entry contains: * Override python-foo-but-no-python3-foo Lintian warning, since this package is end-of-life after Python 2 support ends. should we remove this package then? or do you want to generate a python3-gmpy? I didn't realize, but it looks like this package actually does support Python 3. I had assumed we would let this package die when Python 2 dies, since the package is dead upstream since 2013. However, looking at the popcon stats, the original python GMPY is still much more popular than than python GMPY2 (3543 vs 443). So I think it's worth keeping this package. I'm working on converting it over now and should be able to get it done in the next few weeks. Is it possible to remove the AUTORM tag until this is done, or should we let it get deleted and upload a new python3-gmpy package after that? and we can rename python-gmpy-doc to python3-gmpy-doc once the blocking bugs are resolved. please dont, -doc package must preserve the python- prefix. Cheers, Sandro
Bug#937791: Blocked on reverse dependencies
On Sat, 8 Feb 2020 10:55:23 -0800 Martin Kelly wrote: On 2/2/20 8:39 PM, Sandro Tosi wrote: > should we remove this package then? or do you want to generate a python3-gmpy? > I didn't realize, but it looks like this package actually does support Python 3. I had assumed we would let this package die when Python 2 dies, since the package is dead upstream since 2013. However, looking at the popcon stats, the original python GMPY is still much more popular than than python GMPY2 (3543 vs 443). So I think it's worth keeping this package. I'm working on converting it over now and should be able to get it done in the next few weeks. Is it possible to remove the AUTORM tag until this is done, or should we let it get deleted and upload a new python3-gmpy package after that? Looking further, it seems that with current versions of Python 3 (I tested with 3.7.3), the old GMPY 1.17 is no longer passing. When I run test3/gmpy_test.py, I'm getting: $ python3 test3/gmpy_test.py ... 8 items had failures: 1 of 4 in gmpy_test_cvr 4 of 126 in gmpy_test_cvr.__test__.user_errors 1 of 1 in gmpy_test_dec 2 of 2 in gmpy_test_mpf 2 of 60 in gmpy_test_mpf.__test__.binio 2 of 2 in gmpy_test_mpq 2 of 4 in gmpy_test_mpz 7 of 25 in gmpy_test_rnd.__test__.rand 1504 tests in 42 items. 1483 passed and 21 failed. ***Test Failed*** 21 failures. In contrast, the tests for GMPY 2 all succeed, so I think the author clearly intended for tests to fully pass. Since this hasn't been maintained for 7 or so years, I'm not too surprised. Given this, I think we should let this package be removed and consider resurrecting it in the future if people ask for it and someone will step up to maintain it. Sandro, is there anything more to do if I want to let this package be removed, or do I just wait for the auto-removal?
Bug#950205: python-gmpy2 fails autopkg tests with python3.8
On 1/29/20 10:39 PM, Matthias Klose wrote: Package: src:python-gmpy2 Version: 2.1.0~b3-3 Severity: important Tags: sid bullseye User: debian-pyt...@lists.debian.org Usertags: python3.8 python-gmpy2 fails autopkg tests with python3.8: autopkgtest [09:06:22]: test command1: - - - - - - - - - - results - - - - - - - - - - command1 FAIL stderr: :1: DeprecationWarning: an integer is required (got type mpfr). Implicit conversion to integers using __int__ is deprecated, and may be removed in a future version of Python. autopkgtest [09:06:22]: test command1: - - - - - - - - - - stderr - - - - - - - - - - :1: DeprecationWarning: an integer is required (got type mpfr). Implicit conversion to integers using __int__ is deprecated, and may be removed in a future version of Python. gmpy2.factorial(r) autopkgtest [09:06:22]: summary command1 FAIL stderr: :1: DeprecationWarning: an integer is required (got type mpfr). Implicit conversion to integers using __int__ is deprecated, and may be removed in a future version of Python. Exit request sent. Adding the maintainer, Case Van Horsen. Case, it looks like the following autopkgtest command is failing with Python 3.8. The output is above. You should be able to repro by running: python3 test/runtests.py as this is the command that the autopkgtest runs. I have also opened a bug report on Github for this: https://github.com/aleaxit/gmpy/issues/259
Bug#950205: python-gmpy2 fails autopkg tests with python3.8
On Sat, 8 Feb 2020 11:22:22 -0800 Martin Kelly wrote Adding the maintainer, Case Van Horsen. Case, it looks like the following autopkgtest command is failing with Python 3.8. The output is above. You should be able to repro by running: python3 test/runtests.py as this is the command that the autopkgtest runs. I have also opened a bug report on Github for this: https://github.com/aleaxit/gmpy/issues/259 The maintainer put out a new release that fixes the issue. I will package it as soon as I can.
Bug#937791: Blocked on reverse dependencies
We are blocked on the following reverse dependencies: $ apt-cache rdepends python-gmpy python-gmpy Reverse Depends: obfsproxy python-tlslite-ng python-sympy python-gmpy-doc
Bug#937791: Blocked on reverse dependencies
On Mon, 9 Sep 2019 10:42:08 -0700 Martin Kelly wrote: We are blocked on the following reverse dependencies: $ apt-cache rdepends python-gmpy python-gmpy Reverse Depends: obfsproxy python-tlslite-ng python-sympy python-gmpy-doc Dependencies on obfsproxy and python-sympy documented with affects and blocks. python-tlslite-ng has been removed already, and we can rename python-gmpy-doc to python3-gmpy-doc once the blocking bugs are resolved.
Bug#937792: Blocked by reverse dependencies
We are blocked by the following reverse dependencies: $ apt-cache rdepends python-gmpy2 python-gmpy2 Reverse Depends: python-mpmath |python-gmpy2-doc |python-gmpy2-common pyecm pyecm is already fixed to use Python 3 and the other two are built by us and just need renaming. Added affects/blocks to python-mpmath.
Bug#999376: marked as done (python-gmpy2 ftbfs with Python 3.10)
On 11/19/21 1:45 PM, Debian Bug Tracking System wrote: Your message dated Fri, 19 Nov 2021 21:40:53 + with message-id and subject line Bug#999376: fixed in python-gmpy2 2.1.0~b5-1 has caused the Debian Bug report #999376, regarding python-gmpy2 ftbfs with Python 3.10 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) Sorry, I was in an arm sling after shoulder surgery and unable to easily type on my home computer, so I hadn't gotten a chance to update this yet. I was about to do so and see you beat me to it. Thank you!
Bug#965001: strange version 2.1.0 beta4 fails tests with mpfr4 4.1.0
On Tue, Jul 14, 2020, 3:15 AM Vincent Lefevre wrote:
> On 2020-07-14 09:48:18 +0200, Matthias Klose wrote:
> > There is no 2.1.0 beta4, just a beta1, so I don't know what was packaged
> in
> > February 2020. However the tests now fail with mpfr 4.1.0, seems to be
> > consistent across all architectures:
> >
> > **
> > File "test/test_gmpy2_format.txt", line 157, in test_gmpy2_format.txt
> > Failed example:
> > c.__format__('e')
> > Differences (ndiff with -expected +actual):
> > - '3.3331e-01+5e+00j'
> > + '3.3331e-01+5.e+00j'
> > ? +
>
> FYI, the old MPFR behavior was regarded as a bug:
>
>
> https://gforge.inria.fr/tracker/index.php?func=detail&aid=21816&group_id=136&atid=619
>
> There were 2 reasonable interpretations of the description in the
> MPFR manual that did not leave the output partly unspecified, and
> for each of them, some outputs were incorrect. The one that has
> been chosen is the one that is closer to ISO C's %e and it does
> not change the numerical output value (the only difference is
> trailing zeros).
>
> --
> Vincent Lefèvre - Web:
Bug#965001: strange version 2.1.0 beta4 fails tests with mpfr4 4.1.0
On Wed, Jul 15, 2020, 4:27 PM Martin Kelly wrote:
> On Tue, Jul 14, 2020, 3:15 AM Vincent Lefevre wrote:
>
>> On 2020-07-14 09:48:18 +0200, Matthias Klose wrote:
>> > There is no 2.1.0 beta4, just a beta1, so I don't know what was
>> packaged in
>> > February 2020. However the tests now fail with mpfr 4.1.0, seems to be
>> > consistent across all architectures:
>> >
>> > **
>> > File "test/test_gmpy2_format.txt", line 157, in test_gmpy2_format.txt
>> > Failed example:
>> > c.__format__('e')
>> > Differences (ndiff with -expected +actual):
>> > - '3.3331e-01+5e+00j'
>> > + '3.3331e-01+5.e+00j'
>> > ? +
>>
>> FYI, the old MPFR behavior was regarded as a bug:
>>
>>
>> https://gforge.inria.fr/tracker/index.php?func=detail&aid=21816&group_id=136&atid=619
>>
>> There were 2 reasonable interpretations of the description in the
>> MPFR manual that did not leave the output partly unspecified, and
>> for each of them, some outputs were incorrect. The one that has
>> been chosen is the one that is closer to ISO C's %e and it does
>> not change the numerical output value (the only difference is
>> trailing zeros).
>>
>> --
>> Vincent Lefèvre - Web: <https://www.vinc17.net/>
>> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
>> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>>
>
> Hi all,
>
> Thanks for the bug report. Unfortunately I'm on a long hiking vacation
> with no computer access until October and won't be able to look at this
> until then. I welcome a non-maintainer upload if this needs a fix sooner.
>
> I'm also CCing the upstream maintainer, who may have an opinion on that to
> do here.
>
The beta4 version is this one:
https://github.com/aleaxit/gmpy/releases/tag/gmpy2-2.1.0b4
It looks like it may be a tag but not a release? In any case, I assume
that's what I packaged (I can't check as I don't have computer access right
now, just phone).
Apparently this bug is going to cause autoremoval from testing soon. Is the
severity really high enough for that?
Again, I'd like to take a closer look at this but am away from a computer
until October on an extended trip
>
Bug#965001: strange version 2.1.0 beta4 fails tests with mpfr4 4.1.0
On Thu, Jul 30, 2020, 5:34 AM Matthias Klose wrote: > On 7/30/20 3:42 AM, Martin Kelly wrote: > > Apparently this bug is going to cause autoremoval from testing soon. Is > the > > severity really high enough for that? > > yes, because it blocks migration of mpfr4, used by our GCC packages. I'm > certainly biased, however I'd like to see the new mpfr4 in use now, even > if it > means removing a bindings package from testing. > Case Van Horsen (upstream maintainer), is there anything we can do here to fix the tests? I can look at this in October, but the package will be removed from testing at that point. I'm not sure when the package freeze will be, but I certainly don't want to miss the next release.
Bug#965001: strange version 2.1.0 beta4 fails tests with mpfr4 4.1.0
On Thu, Jul 30, 2020, 6:48 AM Case Van Horsen wrote: > I will update the test suite today. (The offending test will be > removed from test_gmpy2_format.txt and moved to test_mpfr40_format.txt > and test_mpfr41_format.txt with the appropriate version chosen.) > > Will this release move to MPC 1.2.0? > > Case > Thanks Case! Matthias, Vincent, would one of you be willing to do a non-maintainer upload once Case releases the new version? I would like to but won't have computer access until October. > On Thu, Jul 30, 2020 at 6:36 AM Martin Kelly > wrote: > > > > On Thu, Jul 30, 2020, 5:34 AM Matthias Klose wrote: > >> > >> On 7/30/20 3:42 AM, Martin Kelly wrote: > >> > Apparently this bug is going to cause autoremoval from testing soon. > Is the > >> > severity really high enough for that? > >> > >> yes, because it blocks migration of mpfr4, used by our GCC packages. > I'm > >> certainly biased, however I'd like to see the new mpfr4 in use now, > even if it > >> means removing a bindings package from testing. > > > > > > Case Van Horsen (upstream maintainer), is there anything we can do here > to fix the tests? I can look at this in October, but the package will be > removed from testing at that point. I'm not sure when the package freeze > will be, but I certainly don't want to miss the next release. > > > > > > >
Bug#960201: python-gmpy2: autopkgtest regression: RuntimeWarning: coroutine '' was never awaited
On 5/10/20 8:20 AM, Paul Gevers wrote: Source: python-gmpy2 Version: 2.1.0~b4-1 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), Because your autopkgtest was part of the tests for glibc, I spotted that the autopkgtest of python-gmpy2 regressed recently. On 2020-05-01 at 19:13 we had the last successful run on arm64 in testing, the first failure was also on 2020-05-01, even earlier: at 02:08 in unstable on amd64. I copied some of the output at the bottom of this report. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-gmpy2/5338978/log.gz Thanks for the bug report. Given that no new python-gmpy2 package was uploaded on May 1, I'm guessing one of the dependencies of this package has broken, or changed in a way that broke this package. Is there a way to get a list of packages that were uploaded after the last successful test and before the first failure? +Case Van Horsten, the upstream maintainer. Case, could you take a look at the failures here? They seem to have occurred without gmpy2 changing, so some dependency is failing.
Bug#1046766: python-gmpy2: Fails to build source after successful build
On 8/13/23 12:21, Lucas Nussbaum wrote: Source: python-gmpy2 Version: 2.1.2-2 Severity: minor Tags: trixie sid ftbfs User: lu...@debian.org Usertags: ftbfs-sab-20230813 ftbfs-source-after-build User: debian...@lists.debian.org Usertags: qa-doublebuild Hi, This package fails to build a source package after a successful build (dpkg-buildpackage ; dpkg-buildpackage -S). This is probably a clear violation of Debian Policy section 4.9 (clean target), but this is filed as severity:minor for now, because a discussion on debian-devel showed that we might want to revisit the requirement of a working 'clean' target. More information about this class of issues, included common problems and solutions, is available at https://wiki.debian.org/qa.debian.org/FTBFS/SourceAfterBuild Thanks for the report; I'll look into this as soon as I can.
Bug#1085178: linux-signed-amd64: Some BPF fentry hooks silently fail
Source: linux-signed-amd64
X-Debbugs-Cc: martin.ke...@crowdstrike.com
Version: 6.11.2+1
Severity: important
Tags: upstream
Some BPF fentry hooks in the 6.11.2-cloud-amd64 kernel successfully
load
but then are ignored when they should fire. This can be seen with the
following bpftrace command:
bpftrace -e 'kfunc:acct_process { printf("acct_process called\n"); }'
Which normally should trigger when running some short-lived process,
but
instead doesn't show output on the 6.11.2-cloud-amd64 kernel. The same
command works fine as a kprobe, showing this issue is unique to fentry.
So the below command shows output as expected:
bpftrace -e 'kprobe:acct_process { printf("acct_process called\n"); }'
Further, other related hooks in the same code path work fine, such as
this one:
bpftrace -e 'kfunc:acct_collect { printf("acct_collect called\n"); }'
Which shows that the issue has to do with only *some* fentry hooks.
This issue exists in upstream 6.11.2 as well and appears to be fixed in
upstream master. My git bisect pointed at commit 98f7e32f20d2 ("mm/x86:
implement arch_check_zapped_pud()"). I'm not sure why that commit fixes
it, but I manually cherry-picked that commit on top of 6.11.2 and it
indeed fixed the issue.
A few other things to note:
- This issue exists in 6.11.2-cloud-amd64 kernel but not 6.11.2-amd64,
so it presumably depends on some collection of CONFIG options.
- There is an issue with identical symptoms on some kernels with
CONFIG_X86_X32_ABI=y set (6.11.2-cloud-amd64 does *not* have x32 ABI
set). I reported this upstream [1] but haven't gotten a response.
- This x32 ABI issue reproduces on Debian's 6.10.9-amd64 kernel and
on upstream master but not the
6.10.11-amd64 or 6.11.2-amd64 kernels, so it appears to be coming and
going semi-randomly. Technically there is currently no latest Debian
kernel hitting the x32 ABI issue, but since the issue is coming and
going, it may come back in a later release.
[1]
https://lore.kernel.org/bpf/7136605d24de9b1fc62d02a355ef11c950a94153.ca...@crowdstrike.com/T/#u
-- System Information:
Debian Release: 12.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.11.2-cloud-amd64 (SMP w/20 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1085178: linux-signed-amd64: Some BPF fentry hooks silently fail
On Tue, 15 Oct 2024 18:55:11 + Martin Kelly
wrote:
> Source: linux-signed-amd64
> X-Debbugs-Cc: martin.ke...@crowdstrike.com
> Version: 6.11.2+1
> Severity: important
> Tags: upstream
>
> Some BPF fentry hooks in the 6.11.2-cloud-amd64 kernel successfully
> load
> but then are ignored when they should fire. This can be seen with the
> following bpftrace command:
>
> bpftrace -e 'kfunc:acct_process { printf("acct_process called\n"); }'
>
This was root-caused to be the same issue as the one addressed in this
(unmerged) patch series:
https://lore.kernel.org/lkml/20240723063258.2240610-1-zhengyej...@huaweicloud.com/
Essentially this has to do with ftrace and weak functions.
Bug#1085178: Re: Bug#1085178: linux-signed-amd64: Some BPF fentry hooks silently fail
On Fri, 2025-02-21 at 21:03 +0100, Salvatore Bonaccorso wrote: > > > > > Essentially this has to do with ftrace and weak functions. > > As I understand this is still an issue in 6.12.15-1. > That's correct; 6.12.15 should still be impacted, as long as CONFIG_X86_KERNEL_IBT is set. CONFIG_X86_KERNEL_IBT changes the function prologue in a way that causes this issue when combined with an certain fentry bug. I confirmed this issue is fixed with this patch series: https://lore.kernel.org/bpf/20250218195918.255228...@goodmis.org/ Since that fixes the underlying fentry bug. I would guess that series will merge into 6.15, but we'll have to see.
