Bug#965917: yorick-z: diff for NMU version 1.2.0+cvs20080115-5.1
Dear Adrian, Thanks a lot. I completely forgot to process these yorick-* updates after the release and missed the mail in December. I did the two most urgent a couple of days ago (reverse dependencies of Gyoto) and plan on processing the rest within the next week. NMUs are very welcome! Most or all should be trivial. Best regards, Thibaut. Le 19/01/2022 à 12:02, Adrian Bunk a écrit : Control: tags 965917 + patch Control: tags 965917 + pending Dear maintainer, I've prepared an NMU for yorick-z (versioned as 1.2.0+cvs20080115-5.1) and uploaded it to DELAYED/7. Please feel free to tell me if I should cancel it. cu Adrian -- * Dr Thibaut Paumard | LESIA/CNRS - Table équatoriale (bât. 5) * * Tel: +33 1 45 07 78 35 | Observatoire de Paris - Section de Meudon * * Fax: +33 1 45 07 79 17 | 5, Place Jules Janssen* * thibaut.paum...@obspm.fr | 92195 MEUDON CEDEX (France) * smime.p7s Description: Signature cryptographique S/MIME
Bug#994784: mpi4py breaks gyoto autopkgtest on i386: 1 process returned, a non-zero exit code
Control: found -1 gyoto/1.4.4-4 Control: found -1 gyoto/1.4.4-3 Control: notfound -1 gyoto/1.4.4-5 Hi Paul, Le 24/09/2021 à 21:42, Paul Gevers a écrit : > Is the workaround inside the binary, or only (needed) in the test suite? > In other words, did openmpi *break* gyoto on i386 in some cases? If yes, > Ideally openmpi is updated with a versioned Breaks on gyoto with the > right unfixed package. The migration software then will schedule the set > and the migration will happen if everything's fine. The workaround is only in the test suite. There remains a bug, either within openmpi or within gyoto but triggered by the new version of openmpi. Concerning gyoto, I would only rate it "normal" though, not "serious", if you can confirm that the workaround actually worked in the testing testbed. If this is the case, I would decrease the severity of the bug and keep it opened. It would be great if the openmpi mainainers could have a look, but I guess they will need a me to provide a minimal example which will not be easy to provide, unless they experience the same symptoms in other situations. Regards, Thibaut.
Bug#994784: mpi4py breaks gyoto autopkgtest on i386: 1 process returned, a non-zero exit code
Control: reassign -1 src:openmpi src:gyoto Hi Paul, I think I've found a workaround and am getting closer to finding the cause. I've just uploaded a package (gyoto 1.4.4-5) with the workaround. If you can then check that the test passes fine, I guess we will just have to let this gyoto migrate together with openmpi. Gyoto supports two models for running within MPI: one can either specify how many processes to run with the -np argument of mpirun, and one where -np is set to 1 and gyoto itself spawns more processes (singleton approach). The test used the singleton approach. If I now let mpirun spawn itself the n processes, the test doesn't fail anymore. The code path is slightly different within gyoto between the two approaches so there could be a bug in gyoto, but it is puzzling that it only affect one specific input file, only on one architecture, and only with this new release of openmpi. And it still depends on the environment: I don't get the failure if I let autopkgtest run the test in my chroot, but I get it if I run the same commands manually in the same chroot. Best regards, Thibaut.
Bug#994784: mpi4py breaks gyoto autopkgtest on i386: 1 process returned, a non-zero exit code
Thanks Paul. I don't think mpi4py is involved, but openmpi (4.1.1-5) is (based on where in the test suite the bug happens, and on the fact that the failure also occurs when only openmpi is frozen to unstable). The puzzling bit is that the tests nicely go through in unstable, the failure only occurs with the unstable openmpi in testing (and only on i386, as far a I can tell). Still investigating. Regards, Thibaut. smime.p7s Description: Signature cryptographique S/MIME
Bug#994784: mpi4py breaks gyoto autopkgtest on i386: 1 process returned, a non-zero exit code
Control: reassign -1 src:openmpi Control: found -1 openmpi/4.1.1-3 Control: tags -1 +unreproducible +help Control: retitle -1 openmpi breaks gyoto autopkgtest on i386 Control: thanks Hi, I cannot reproduce this. I have set up a testing-i386 chroot (on my amd64 laptop) and installed openmpi from unstable (I also tried with mpi4py from unstable on top), as well as their versionned dependencies not in testing: libopenmpi-dev 4.1.1-5 libopenmpi34.1.1-5 openmpi-common 4.1.1-5 python3-mpi4py 3.0.3-10 I tried with gyoto from unstable (1.4.4-4) and from testing (1.4.4-3). Note that this is apparently different from what the debci infrastructure does (apparently recompiling instead of taking the binaries). I then ran the test from this chroot (as sbuild user): autopkgtest -B --test-name=gyoto-mpi -- null The test PASSED each time. I note that the test suite can take a long time to run and that the final line in the failure log for this test reads: mpirun.openmpi noticed that process rank 1 with PID 0 on node ci-262-d8ad913b exited on signal 9 (Killed). This happens after this test has been running for 1h and 55min. Could it be that the process is killed because of a timeout in the test environment? In the one hand it would feel strange because, on the debci infrastucture, the error always happens on the same file (example-startrace), near the beginning of the process (row 1/32). On the other hand I know this file is one of the longest to process (still below a couple of minutes on my laptop). Anyway, there's not much more I can do, except skip this test. I'm reassigning to openmpi because, on the debci infrastructure, the same failure occurs with openmpi/unstable also with mpi4py/testing. Advice welcome. Regards, Thibaut. smime.p7s Description: Signature cryptographique S/MIME
Bug#978831: patch gyoto for autoconf 2.70
Thanks for the patch Étienne, very appreciated! OpenPGP_signature Description: OpenPGP digital signature
Bug#961505: failed mips64el build of flint 2.5.2-22
Package: src:flint Version: 2.5.2-22 Severity: serious Tags: ftbfs Thanks Hi, I wanted to check whether the recent upload actually fixed 953437: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953437 I realized that it failed to build. Regards, Thibaut. Message transféré Sujet : failed mips64el build of flint 2.5.2-22 Date : Tue, 19 May 2020 20:45:33 - De : Debian buildds Pour : dispa...@tracker.debian.org * Source package: flint * Version: 2.5.2-22 * Architecture: mips64el * State: failed * Suite: sid * Builder: mipsel-aql-02.debian.org * Build log: https://buildd.debian.org/status/fetch.php?pkg=flint=mips64el=2.5.2-22=1589921133=log Please note that these notifications do not necessarily mean bug reports in your package but could also be caused by other packages, temporary uninstallabilities and arch-specific breakages. A look at the build log despite this disclaimer would be appreciated however. signature.asc Description: OpenPGP digital signature
Bug#897236: yorick: flaky autopkgtest: ERROR (txtest) failed to open X display or create X window
Control: tags -1 + fixed pending Dear Paul, Thanks for the hint, I did not know I could mark the test as flaky. This test needs to open a window which is done through xvfb-run. That xvfb-run sometimes fails to open a window is a bug in xvfb-run which I have no time to investigate. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#885506: bumping severity of pygtk bugs
Le 01/04/2020 à 23:13, Moritz Mühlenhoff a écrit : > On Mon, Oct 07, 2019 at 04:53:03PM +0200, Thibaut Paumard wrote: >> Dear Jeremy, >> >> Thanks, I have warned upstream that YAO will be removed if not updated >> to Python 3 and Gtk 3. > > It's now the last package blocking the removal of pygtk, let's remove it. > Sure. Did you already/ can you fill the RM bug? Regards, Thibaut. > Cheers, > Moritz > signature.asc Description: OpenPGP digital signature
Bug#953151: gyoto FTBFS on armel, armhf, mipsel and mips64el
Le 05/03/2020 à 10:49, peter green a écrit : > Package: gyoto > Version: 1.4.4-1 > Severity: serious > > gyoto is failing to build on armel, armhf, mipsel and mips64el Thanks Peter, I've been working on it since Monday. I think I found the bug that hits arm*, now I will check for mips*. Regards. signature.asc Description: OpenPGP digital signature
Bug#944769: python3-h5py fails to import if offline due to apparent MPI failure
Hi again, Le 03/03/2020 à 11:55, Drew Parsons a écrit : >> Actually, it may be wise to choose names that >> >> a) are clearly private, so people know they should not start using >> explicitly h5py_serial or h5py_mpi; >> >> b) will not clash with anything upstream may adopt in the future, a >> bit like choosing a debian-specific soname for shared library. >> >> why not _debian_h5py_serial and _debian_h5py_mpi? >> > > > Actually I was thinking people could start using h5py_serial or > h5py_mpi, then they'd be sure of exactly what they're getting. > > But I can see your point. It wouldn't be so portable if users started > doing that. Yep, people can still use _debian_h5py_mpi to be sure of what they get, but it is clear to them that they enter non-portable territory. > If we want to present it as _debian*, then I think it would be tidier to > place these _debian dir underneath h5py. That layout could be even > better for upstream since they'd want to do likewise (_h5py_serial, > _h5py_mpi under h5py), if they take up this suggestion. > Yes, I kinda like h5py._debian.serial and h5py._debian.mpi. Looks tidy an future-proof. Regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#944769: python3-h5py fails to import if offline due to apparent MPI failure
Hi Drew, Le 02/03/2020 à 17:33, Drew Parsons a écrit : >> Like you, I would keep h5py_serial and h5py_mpi separate rather than >> submodules of h5py. Mostly because the h5py folks could in the future >> want to use those two names and do it in an incompatible manner. > > Fair enough, I'll keep them separate. (actually, I'll file an Issue > upstream and let them know what we've done. They may want to adapt for > themselves). Actually, it may be wise to choose names that a) are clearly private, so people know they should not start using explicitly h5py_serial or h5py_mpi; b) will not clash with anything upstream may adopt in the future, a bit like choosing a debian-specific soname for shared library. why not _debian_h5py_serial and _debian_h5py_mpi? Feel free to disregard this suggestion or choose something else as you see fit. Just my 2c to avoid future headaches. Regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#944769: python3-h5py fails to import if offline due to apparent MPI failure
Hi Drew,
I see, so you effectively copy all symbols from _h5py except those that
look like __foo__ which is Python internal stuff, *and* you give them an
entry under h5py in sys.modules. Nice, that should be pretty stable.
Actually, you don't treat public_api differently from weak_privates, and
you could be missing some symbols (if introduced later) of the form
_foo_, _foo__ or __foo_. You could simplify the code and cope with this
possibility with something like:
api=[ k for k in _h5py.__dict__.keys() if not (k.startswith('__') and
k.endswith('__')) ]
Like you, I would keep h5py_serial and h5py_mpi separate rather than
submodules of h5py. Mostly because the h5py folks could in the future
want to use those two names and do it in an incompatible manner.
Kind regards, Thibaut.
Le 02/03/2020 à 15:30, Drew Parsons a écrit :
> On 2020-03-02 18:21, Thibaut Paumard wrote:
>> Le 01/03/2020 à 20:26, Drew Parsons a écrit :
>>> your h5py suggestion of [...]
>>> works up to a point.
>>
>> Hi Drew,
>>
>> Do I read correctly in your other mail that you have found a workaround?
>
> That's right, I've been building up my python-fu.
>
>> My first take would have been to apply my initial suggestion to each
>> individual sub-module but that depends on the structure of the main h5py
>> module which I didn't check...
>
> I seem to have managed it with just one formal import much as you
> suggested. Then extra handling for the weak references and h5py.tests
> (which isn't accessible from h5py, must be imported as h5py.tests)
>
>
>> I can put some brain cells into this if this is still needed, let me
>> know.
>
> The following seems to be working, but let me know if you spot any
> problems.
>
> I've assumed h5py_serial and h5py_mpi are installed independently in the
> python path. An alternative would be to install them as subpackages
> under h5py (so activated with something like "import h5py.h5py_serial as
> _h5py" instead of "import h5py_serial as _h5py". Do you think it's
> better to keep the 2 builds as separate installed modules?
>
>
> Here's my proposed h5py/__init__.py:
>
> =
> # avoid running mpi with serial (1 process) jobs
> # by checking whether mpi is actually being used over multiple processes
> # Probe number of processes with OMPI_COMM_WORLD_SIZE (openmpi) and
> MPI_LOCALNRANKS (mpich)
>
> from os import getenv as os_getenv
> import sys, importlib
>
> OPENMPI_MULTIPROC = os_getenv('OMPI_COMM_WORLD_SIZE') is not None
> MPICH_MULTIPROC = os_getenv('MPI_LOCALNRANKS') is not None
>
> MPI_ACTIVE = OPENMPI_MULTIPROC or MPICH_MULTIPROC
>
> if MPI_ACTIVE:
> try:
> import h5py_mpi as _h5py
> except:
> import h5py_serial as _h5py
> else:
> import h5py_serial as _h5py
>
> # make generic h5py module behaviour the same as specific builds
> # by importing public and weak internal symbols
>
> public_api = [ k for k in _h5py.__dict__.keys() if not k.startswith('_')
> and not k.endswith('_') ]
> weak_privates = [ k for k in _h5py.__dict__.keys() if k.startswith('_')
> and not k.endswith('_') ]
>
> this_module=sys.modules[__name__]
> for key in public_api+weak_privates:
> # "imports" symbols (makes them accessible)
> setattr(this_module,key,getattr(_h5py,key))
> # rename symbols as properties of toplevel h5py module
> sys.modules['h5py.{}'.format(key)] = getattr(_h5py,key)
>
> del public_api
> del weak_privates
> del this_module
>
>
> # tests are not loaded with h5py, but can be imported separately with
> # import h5py.tests
> tests = importlib.import_module('{}.tests'.format(_h5py.__name__))
> sys.modules['h5py.tests'] = tests
> del tests
> =
>
signature.asc
Description: OpenPGP digital signature
Bug#944769: python3-h5py fails to import if offline due to apparent MPI failure
Le 01/03/2020 à 20:26, Drew Parsons a écrit : > your h5py suggestion of [...] > works up to a point. Hi Drew, Do I read correctly in your other mail that you have found a workaround? My first take would have been to apply my initial suggestion to each individual sub-module but that depends on the structure of the main h5py module which I didn't check... I can put some brain cells into this if this is still needed, let me know. Kind regards, Thibaut. -- * Dr Thibaut Paumard | LESIA/CNRS - Table équatoriale (bât. 5) * * Tel: +33 1 45 07 78 35 | Observatoire de Paris - Section de Meudon * * Fax: +33 1 45 07 79 17 | 5, Place Jules Janssen* * thibaut.paum...@obspm.fr | 92195 MEUDON CEDEX (France) * smime.p7s Description: Signature cryptographique S/MIME
Bug#885505: bumping severity of pygtk bugs
> Did you hear anything back? Shall we remove it? > Yes, we should remove it. Can you fill the request? I won't have time before next week. Kind Regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#885505: bumping severity of pygtk bugs
Le 10/12/2019 à 19:59, Moritz Mühlenhoff a écrit : > On Mon, Oct 07, 2019 at 04:51:09PM +0200, Thibaut Paumard wrote: >> Dear Jeremy, >> >> Thanks, I have warned upstream that spydr will be removed if not updated >> to Python 3 and Gtk 3. > > Was there any reaction? Otherwise let's go ahead with the removal from > the archive. > > Cheers, > Moritz Yes, upstream did say they would fix this. As this is a leaf package, I would propose to wait until after the vacation and remove it on, say, Jan. 15th. In the meantime I ill ping them and maybe they manage by then. Else, I can always reintroduce it later. Kind regards, Thibaut. > signature.asc Description: OpenPGP digital signature
Bug#885505: bumping severity of pygtk bugs
Dear Jeremy, Thanks, I have warned upstream that spydr will be removed if not updated to Python 3 and Gtk 3. Regards, Thibaut. Le 06/10/2019 à 23:09, Jeremy Bicha a écrit : > Control: severity -1 serious > Control: tags -1 -buster > > > As part of the Python2 removal, it is our intent that pygtk will be removed > from Testing before the release of Debian 11 > "Bullseye". Therefore, I am bumping the severity of this bug to Serious to > ensure that there is plenty of warning before > the Debian 11 release and to make the eventual removal of pygtk as smooth as > possible. > > > On behalf of the Debian GNOME team, > Jeremy Bicha > signature.asc Description: OpenPGP digital signature
Bug#885506: bumping severity of pygtk bugs
Dear Jeremy, Thanks, I have warned upstream that YAO will be removed if not updated to Python 3 and Gtk 3. Regards, Thibaut. Le 06/10/2019 à 23:09, Jeremy Bicha a écrit : > Control: severity -1 serious > Control: tags -1 -buster > > > As part of the Python2 removal, it is our intent that pygtk will be removed > from Testing before the release of Debian 11 > "Bullseye". Therefore, I am bumping the severity of this bug to Serious to > ensure that there is plenty of warning before > the Debian 11 release and to make the eventual removal of pygtk as smooth as > possible. > > > On behalf of the Debian GNOME team, > Jeremy Bicha > signature.asc Description: OpenPGP digital signature
Bug#926182: Patch: Use alternatives system for guile-2.2-dev binaries
Le 25/05/2019 à 01:18, Rob Browning a écrit : > Rob Browning writes: > >> I'm not certain, but I'm planning to work on guile over the next week. >> If so, I should be able to take a look. > > Just as an update, I obviously didn't get to it earlier this week, but > I'm looking in to it now. > > After I poke around a bit, I suspect the next step will be to contact > the release managers to see what they think about any proposed changes > because of course if they're not in favor, then the changes may have to > wait. > > I expect I'll be able to report back in a couple of days. Dear Rob, Since this change would be revertible in sid, you can safely upload already and then contact the release team with the unblock request and a source debdiff. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#926182: Patch: Use alternatives system for guile-2.2-dev binaries
Le 16/05/2019 à 03:45, Rob Browning a écrit : > Thibaut Paumard writes: > >> I'm checking your patch, which looks good (compiling guile for testing >> takes a lot o time but the patch itself is pretty straightforward and >> clean). Do you intend on NMUing this? Given the age of this RC bug, I >> think you should. > > I'm not certain, but I'm planning to work on guile over the next week. > If so, I should be able to take a look. > > Thanks > Thanks Rob. For what it's worth, I now tested the patch and I think it is ready to go for Buster: - it does fix the RC bug (tested); - I think the approach is sound; - for this approach, the patch is minimal. It doesn't do anything that is not required to fix the bug. As a bonus, it can go through unstable. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#926182: Patch: Use alternatives system for guile-2.2-dev binaries
On Fri, 3 May 2019 23:09:33 +0300 Kari Pahula wrote: > tags 926182 + patch > thanks > > Hi. > > /usr/bin/guile uses alternatives system and the real binary is under > /usr/lib, as well as providing /usr/bin/guile-2.2 as a symlink. > > My patch gives the same treatment for the binaries in guile-2.2-dev. Dear Kari, I'm checking your patch, which looks good (compiling guile for testing takes a lot o time but the patch itself is pretty straightforward and clean). Do you intend on NMUing this? Given the age of this RC bug, I think you should. Regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#899605: Bug#899658: pommed/macfanctld: Invalid maintainer address pkg-mactel-de...@lists.alioth.debian.org
control: severity -1 important Le 24/05/2018 à 10:38, Thibaut Paumard a écrit : Thanks, I've asked for the migration of pkg-mactel-de...@lists.alioth.debian.org. Regards, Thibaut. Since this is only a temporary solution, we should still think of choosing another address with the next upload. Regards, Thibaut.
Bug#899605: Bug#899658: pommed: Invalid maintainer address pkg-mactel-de...@lists.alioth.debian.org
Thanks, I've asked for the migration of pkg-mactel-de...@lists.alioth.debian.org. Regards, Thibaut.
Bug#898589: yorick-yao is not unmaintained
control: not-found -1 yorick-yao/5.4.0-1 control: severity -1 wishlist control: thanks Hi, I object and I'm closing this bug as yorick-yao is not unmaintained. I'll remove it after buster if upstream does not update it. Regards, Thibaut.
Bug#871283: [Debian-astro-maintainers] Bug#871283: libgyoto6: requires rebuild against GCC 7 and symbols/shlibs bump
Le 07/08/2017 à 16:47, jcowg...@debian.org a écrit : Package: libgyoto6 Version: 1.2.0-2 Severity: serious Tags: sid buster User: debian-...@lists.debian.org Usertags: gcc-7-op-mangling Hi, It appears that your package provides an external symbol that is affected by the recent name mangling changes in GCC 7. See: https://gcc.gnu.org/gcc-7/porting_to.html#conversion-op-mangling OK, thanks. I'll do that when I'm back with a better internet connection, in roughly two weeks. If anyone with some time to spare sees this, don't hesitate to NMU. Regards, Thibaut. --
Bug#850986: keyboard focus stays in main window when opening compose window
Package: icedove Version: 1:45.4.0-1 Severity: grave Dear maintainers, I have that spurious proble that very often, when I open a new compose window (with ^N or by clicking on one of the reply-to buttons), the keyboard focus stays in the main window. I start typing, which can have nasty effects since the main indow recieves the events, such as, for instance: - deleting emails; - ignoring conversations. It is not immediate to get the focus to the compose winodw I am interested in. Clicling in this window does not help, even after having clicked in the main icedove window or in another window from an unrelated application. I have found two things that each help recover focus (no need to do both, each one is sufficient on its own): 1- closing the main window; 2- opening yet another compose window: this new window then has focus and I can from that point on get the focus in the window I like, including the compose window that initially did not get focus. This is not only anoying but also can cause data loss as I can end up deleting messages inadvertently. Forunately I have never actually purged a directory when that happened, but I consider myself lucky. I am running GNOME 3 from testing, this bug has been there for a while including when I was running cinnamon on jessie. It feels like it's happening more often (almost, but not quite, always). Kind regads, Thibaut. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages icedove depends on: ii debianutils 4.8.1 ii fontconfig2.11.0-6.7 ii libasound21.1.2-1 ii libatk1.0-0 2.22.0-1 ii libc6 2.24-8 ii libcairo2 1.14.8-1 ii libdbus-1-3 1.10.14-1 ii libdbus-glib-1-2 0.108-1 ii libevent-2.0-52.0.21-stable-2.1 ii libffi6 3.2.1-6 ii libfontconfig12.11.0-6.7 ii libfreetype6 2.6.3-3+b1 ii libgcc1 1:6.2.1-5 ii libgdk-pixbuf2.0-02.36.0-1 ii libglib2.0-0 2.50.2-2 ii libgtk2.0-0 2.24.31-1 ii libhunspell-1.4-0 1.4.1-2+b1 ii libicu57 57.1-5 ii libnspr4 2:4.12-6 ii libnss3 2:3.26.2-1 ii libpango-1.0-01.40.3-3 ii libpangocairo-1.0-0 1.40.3-3 ii libpangoft2-1.0-0 1.40.3-3 ii libpixman-1-0 0.34.0-1 ii libsqlite3-0 3.15.2-1 ii libstartup-notification0 0.12-4 ii libstdc++66.2.1-5 ii libvpx4 1.6.0-3 ii libx11-6 2:1.6.4-2 ii libxcomposite11:0.4.4-1 ii libxdamage1 1:1.1.4-2+b1 ii libxext6 2:1.3.3-1 ii libxfixes31:5.0.3-1 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1 ii psmisc22.21-2.1+b1 ii zlib1g1:1.2.8.dfsg-4 Versions of packages icedove recommends: ii hunspell-en-gb [hunspell-dictionary] 1:5.2.3-1 ii hunspell-en-us [hunspell-dictionary] 20070829-6 ii iceowl-extension 1:45.4.0-1 ii myspell-fr-gut [myspell-dictionary] 1:1.0-32 Versions of packages icedove suggests: pn apparmor ii fonts-lyx 2.2.2-1 ii libgssapi-krb5-2 1.15-1 -- no debconf information
Bug#734837: Why is tk8.4 removal triggering autoremoval messages of not depending packages at this point in time (Was: staden is marked for autoremoval from testing)
Dear Andreas, Le 31/12/2016 à 08:23, Andreas Tille a écrit : > Hi, > > On Sat, Dec 31, 2016 at 04:40:32AM +, Debian testing autoremoval watch > wrote: >> staden 2.0.0+b11-2 is marked for autoremoval from testing on 2017-01-29 >> >> It (build-)depends on packages with these RC bugs: >> 734837: tk8.4: Time to remove from testing > > Staden Build-Depends: tk-dev (without any version) and the binary > package Depends: libtk8.6 (>= 8.6.0) so I do not understand this > autoremoval message in principle and I specifically wonder why this > happens at this point in time. I cannot tell you why this message appears, in particular for staden (no matter how hard I grep staden's dependencies, I cannot find tk8.4 in it). However I can tell you why it's happening now. This is due to the recent bogus run of testing migrations. 734837 is a sort of "pseudo" RC bug that was there to prevent tk8.4 from migrating again to testing. Yet a bug in the transition script let it go through. Now the auroremoval stuff rightly wants to remove it again, and for some reason misinterprets its reverse dependencies. I would believe removing tk8.4 by hand from testing could fix the lot of associated autoremovals. Dear release team, thoughts on that? Kind regards, Thibaut. > Staden is juat an example for a set of packages with the same problem. > > Kind regards > > Andreas. >
Bug#847806: openmpi 2.0.2
Le 17/12/2016 à 17:31, Alastair McKinstry a écrit : > I say leave until post-stretch release. I'm fixing the multiarch now > (which fixes #833728, #842881; > tagged as mpich and ldconfig bugs but in practice due to mpich being > multiarch and openmpi not). > Getting this in place by the freeze on Jan 5 is the limits of my mpi > ambitions at the moment :-) Dear Alastair, good to know you are working on the multi-archification. Jan 5th is the soft freeze (basically no (re)entries of source packages not yet in testing). I don't think this mutli-archification stuff is concerned by the soft freeze, is it? In any case, the last upload targeting a migration before the hard freeze must be done around Jan. 20th at the latest, so time is flying by in any case... Kind regards, Thibaut.
Bug#848218: openmpi FTBFS on ppc64el
Control: tags -1 +patch
Le 15/12/2016 à 11:31, Thibaut Paumard a écrit :
> Currently building with this on the porterbox, I will provide the patch
> if it works.
attached
diff -urN a/debian/changelog b/debian/changelog
--- a/debian/changelog 2016-12-13 07:10:17.0 +
+++ b/debian/changelog 2016-12-15 10:27:01.0 +
@@ -1,3 +1,9 @@
+openmpi (2.0.2~git.20161225-7) UNRELEASED; urgency=medium
+
+ * Fix opal_fifo test. Closes: 848218.
+
+ -- Thibaut Jean-Claude Paumard <thib...@plummer.debian.org> Thu, 15 Dec 2016 10:27:01 +
+
openmpi (2.0.2~git.20161225-6) unstable; urgency=medium
* More hurd fixes: man pages for oshrun need to be conditional.
diff -urN a/debian/patches/opal_fifo.patch b/debian/patches/opal_fifo.patch
--- a/debian/patches/opal_fifo.patch 1970-01-01 00:00:00.0 +
+++ b/debian/patches/opal_fifo.patch 2016-12-15 12:05:45.355062390 +
@@ -0,0 +1,23 @@
+Description: fix test-suite to build on ppc64el
+ Test suite hangs on ppc64el. This is due to a bug in test/class/opal_fifo.c.
+ thread_test() must end with pthread_exit(NULL), not return NULL.
+Author: Thibaut Paumard <thib...@debian.org>
+Origin: Vendor
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848218
+Forwarded: no
+Last-Update: 2016-12-15
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: openmpi-2.0.2~git.20161225/test/class/opal_fifo.c
+===
+--- openmpi-2.0.2~git.20161225.orig/test/class/opal_fifo.c
openmpi-2.0.2~git.20161225/test/class/opal_fifo.c
+@@ -62,7 +62,7 @@ static void *thread_test (void *arg) {
+ printf ("Atomics thread finished. Time: %d s %d us %d nsec/poppush\n", (int) total.tv_sec,
+ (int)total.tv_usec, (int)(timing / 1e-9));
+
+-return NULL;
++pthread_exit(NULL);
+ }
+
+ static void *thread_test_exhaust (void *arg) {
diff -urN a/debian/patches/series b/debian/patches/series
--- a/debian/patches/series 2016-12-13 07:10:17.0 +
+++ b/debian/patches/series 2016-12-15 10:25:38.0 +
@@ -5,3 +5,4 @@
build_hurd
link-libfabric.patch
pkgconfig-vars.patch
+opal_fifo.patch
Bug#848218: openmpi FTBFS on ppc64el
Nailed it: thread_test() in test/class/opal_fifo.c must end with pthread_exit(NULL) instead of return NULL. Currently building with this on the porterbox, I will provide the patch if it works. Regards, Thibaut. Le 15/12/2016 à 10:32, Thibaut Paumard a écrit : > Hi, > > I confirm that the package build fine if the tests are deactivated, but > I can't check whether it is usable as I can't install the resutling > packages in the chroot on the porterbox. > > Kind regards, Thibaut. > > Le 15/12/2016 à 09:54, Thibaut Paumard a écrit : >> Source: openmpi >> Version: 2.0.2~git.20161225-6 >> Severity: serious >> Justification: fails to build from source (but built successfully in the >> past) >> >> Dear maintainers, >> >> openmpi fails to build on ppc64el (a release architecture). >> >> The build fails in the test suite. See: >> https://buildd.debian.org/status/fetch.php?pkg=openmpi=ppc64el=2.0.2%7Egit.20161225-6=1481633280 >> >> Naturally this bug prevents dependent packages from building, and hence >> from migrating to stretch. >> >> With the soft freeze due on Jan. 5th, fixing this is a rather pressing >> matter. >> >> Regards, Thibaut. >> > -- * Dr Thibaut Paumard | LESIA/CNRS - Table équatoriale (bât. 5) * * Tel: +33 1 45 07 78 60 | Observatoire de Paris - Section de Meudon * * Fax: +33 1 45 07 79 17 | 5, Place Jules Janssen* * thibaut.paum...@obspm.fr | 92195 MEUDON CEDEX (France) * smime.p7s Description: Signature cryptographique S/MIME
Bug#848218: openmpi FTBFS on ppc64el
Hi, I confirm that the package build fine if the tests are deactivated, but I can't check whether it is usable as I can't install the resutling packages in the chroot on the porterbox. Kind regards, Thibaut. Le 15/12/2016 à 09:54, Thibaut Paumard a écrit : > Source: openmpi > Version: 2.0.2~git.20161225-6 > Severity: serious > Justification: fails to build from source (but built successfully in the > past) > > Dear maintainers, > > openmpi fails to build on ppc64el (a release architecture). > > The build fails in the test suite. See: > https://buildd.debian.org/status/fetch.php?pkg=openmpi=ppc64el=2.0.2%7Egit.20161225-6=1481633280 > > Naturally this bug prevents dependent packages from building, and hence > from migrating to stretch. > > With the soft freeze due on Jan. 5th, fixing this is a rather pressing > matter. > > Regards, Thibaut. >
Bug#848218: openmpi FTBFS on ppc64el
Source: openmpi Version: 2.0.2~git.20161225-6 Severity: serious Justification: fails to build from source (but built successfully in the past) Dear maintainers, openmpi fails to build on ppc64el (a release architecture). The build fails in the test suite. See: https://buildd.debian.org/status/fetch.php?pkg=openmpi=ppc64el=2.0.2%7Egit.20161225-6=1481633280 Naturally this bug prevents dependent packages from building, and hence from migrating to stretch. With the soft freeze due on Jan. 5th, fixing this is a rather pressing matter. Regards, Thibaut.
Bug#844490: [pkg-boost-devel] Bug#844495: Bug#844490: FTBFS with boost1.62
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear Steve,
thanks for your answer:
Le 20/11/2016 à 05:12, Steve M. Robbins a écrit :
> On Wednesday, November 16, 2016 12:16:22 PM CST Thibaut Paumard
> wrote:
>> I've realized that, when acos() does not return, delta100 above
>> is always zero. I can simplify the case by simply doing
>> acos(cos(alpha100))
>>
>> in which case acos() also does not return. Does not look like a
>> memory leak after all.
>>
>> However, doing just that in an isolated main function does not
>> exhibit the bug (I've also tried activating all the hardening
>> features)
>
> So when you say "doing just that" in isolated main ... do you mean
> doing acos(cos(alpha100)*cos(delta100)) or acos(cos(alpha100))?
The minimal test that I tried (and that does not demonstrate the bug)
is attached below. I was not yet able to make a small test case that
exhibits the bug. I'll have to start from the full program and un-knit i
t.
I've been able to gather more information though:
- the initial failure occurred in a unit test where the Gyoto
library is used through an interpreted language (Yorick); now I have
been able to exhibit the bug also from the main gyoto executable by
increasing the resolution of the raytracing test and making it odd
(101 instead of 32) so that the ray-tracing at delta=0 occurs.
- this indicates that even more architectures are affected. amd64
and i386 seem not to be. The complete list of architectures on which I
have been able to trigger the problem is: arm64 armel armhf mips64el
ppc64el s390x powerpc ppc64.
- when failure occurs, delta seems to always be 0, but the reverse
is not true (sometimes delta is 0 ans acos() does not lock).
- increasing the number of digits makes the bug bite earlier.
- although I haven't read it in full yet, there is a thread on
debian-devel mentioning hardening of pthread locking in libc. Gyoto
does use pthreads (although the bug also shows up when using a single
thread). I'd like to see whether the bug is triggered this libc change
instead of the new version of boost, but I think I need to recompile
the older boost on a porterbox with the new libc to try this. It will
take some time, as my day job also needs attention.
- rebuilding with boost1.62 on alpha also fails (which is also a
regression) with a different symptom, which may or may not be related:
/usr/bin/ld: .libs/Screen.o: dtp-relative relocation against dynamic
symbol
_ZGVZN5boost14multiprecision11default_ops15get_constant_piINS0_8backends
13cpp_dec_floatILj100EivRKT_vE6result
https://buildd.debian.org/status/fetch.php?pkg=gyoto=alpha=1.1.
1-3=1479433143
Test case that does not demonstrate the bug:
8<--8<8<
#include
#include
int main(int argc, char ** argv) {
double alpha=0.5, delta=0.;
boost::multiprecision::number<boost::multiprecision::cpp_dec_float<100>
>
alpha100=alpha, delta100=delta, a;
a=acos(cos(alpha100));
std::cerr << a << std::endl;
return 0;
}
8<--8<8<
Kind regards, Thibaut.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJYMrgeAAoJEJOUU0jg3ChAopwQAJ+S3WPrCeDP7H+2AEOH3Veu
2KceQvYbsdOa8bextckXoZLcB0vlxNAMblk1OlbpYt2gR3PPtl7zo6yVpoXdLpAt
gXIHPA2NLGdJn+mA+4S74Jxai2I3NgE7g2/In3li5Fz5UWd4BUKkwFP6PJ98KBum
DFdst1KdLeUXTCmVI5w5AMJ9Ht+Jmo0VIqNd5b3H5oND6ublo/WlW69U3CXq/mgx
+NAzJ7QY3bWs5DmVu8IO19msCwcjzj+B8YpVUr6awuwU+ltAZOeXh/EK5vIliK/D
VYcz8YcDeWj1AAYamjq7JHE4KUk2qjv2IaETFB5gt6u56zinTxxxRjUozL2ey/tc
+zbbC0MamxoeP3ouwDmRDo7i9RFZPKsB1JOzdcIfZvczOkglQEBPwR+q6X3ooZPP
zVQVJY/RdY/2U4/QCcWB6DBPxkRu4Gx3bwY8Twaq2LqtRgMdw+NO/hFNovMkm54g
UgXA3NMHmt1IUL6AKFdeQewKunNXsgN/+v/ysxkwXvlSwmAlWxdB4+x0P1CcxzPJ
v47T/gv2lrCd0JMoMWjEG7hIhOYP9Hr6J4dFSwUmsdmhfeZAXZmbfN090dZJNvu6
3PYC/QxgNk/rgC3k2S6g3zWqz6rpWbVkONIzokL2wknWmYtaOc6FsRaGfsDu792N
ZzLWeBSV2egLCqdFnQjG
=yU0n
-END PGP SIGNATURE-
Bug#844490: FTBFS with boost1.62
Control: tags 844490 +pending Control: severity 844495 normal For the record, the bug appears when doing: acos(cos(alpha100)*cos(delta100)); where the type of alpha100 and delta100 is boost::multiprecision::cpp_dec_float_100. I've realized that, when acos() does not return, delta100 above is always zero. I can simplify the case by simply doing acos(cos(alpha100)) in which case acos() also does not return. Does not look like a memory leak after all. However, doing just that in an isolated main function does not exhibit the bug (I've also tried activating all the hardening features) On the contrary, single-casing delta100==0 does allow Gyoto's test suite to run through. So I do have a workaround, that still smells like hiding the problem under the carpet. Kind regards, Thibaut.
Bug#844495: multiprecision acos() sometimes does not return
Package: libboost1.62-dev Version: 1.62.0+dfsg-4 Severity: serious Justification: regression causes FTBFS Dear maintainer, gyoto FTBFS on several release architectures, apparently due to a regression in Boost.multiprecision introduced in boost1.62. Cf: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844490 It looks like a memory leak. Regards, Thibaut. -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: s390x Kernel: Linux 3.16.0-4-s390x (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages libboost1.62-dev depends on: ii libstdc++-6-dev [libstdc++-dev] 6.2.0-13 libboost1.62-dev recommends no packages. Versions of packages libboost1.62-dev suggests: pn libboost-atomic1.62-dev pn libboost-chrono1.62-dev pn libboost-date-time1.62-dev pn libboost-exception1.62-dev pn libboost-filesystem1.62-dev pn libboost-graph-parallel1.62-dev pn libboost-graph1.62-dev pn libboost-iostreams1.62-dev pn libboost-locale1.62-dev pn libboost-log1.62-dev pn libboost-math1.62-dev pn libboost-mpi-python1.62-dev ii libboost-mpi1.62-dev 1.62.0+dfsg-4 pn libboost-program-options1.62-dev pn libboost-python1.62-dev pn libboost-random1.62-dev pn libboost-regex1.62-dev ii libboost-serialization1.62-dev1.62.0+dfsg-4 pn libboost-signals1.62-dev pn libboost-system1.62-dev pn libboost-test1.62-dev pn libboost-thread1.62-dev pn libboost-timer1.62-dev pn libboost-type-erasure1.62-dev pn libboost-wave1.62-dev pn libboost1.62-doc pn libboost1.62-tools-dev pn libmpfrc++-dev pn libntl-dev -- no debconf information
Bug#844490: FTBFS with boost1.62
Package: src:gyoto Version: 1.1.1-2+b1 Severity: serious Justification: fails to build from source (but built successfully in the past) Dear BTS, gyoto FTBFS with boost1.62 on several release architectures: https://buildd.debian.org/status/package.php?p=gyoto It looks like it was known before the upload of boost1.62 to unstable: http://people.canonical.com/~ubuntu-archive/transitions/html/boost1.62.html The failure occurs in the test suite. Some debugging shows that the culprit lies in lib/Screen.C, line 567. More precisely, the function acos() overloaded for type boost::multiprecision::cpp_dec_float_100 sometimes never returns. It appears to be somewhat reproducible (I think the test suite of gyoto fails always at the same point in its execution on a given architecture, when it fails), but I was not able to isolate a specific value of the argument that would hang acos(). The test suite can succeed if I decrease somewhat the number of digits, e.g. using only 50 or even 90 decimal digits instead of 100. The build failure occurs earlier if I use even more digits, so it looks like a memory leak of some sort. Several approaches could hide the problem under the carpet: - skipping the test suite on the affected architectures ; - decreasing the number of digits. I'm very reluctant to do any of this because there, even if the test suite goes through, there is no guarantee that the bug will not bite users in the middle of a weeks-long simulation. Besides, decreasing the number of digits means gyoto will loose in accuracy. Looks like this needs to be fixed in boost. Kind regards, Thibaut.
Bug#831442: mpich: Broken /usr/lib/libmpich.so.12 symlink, depending on installation order
Control: severity -1 normal Dear all, I have been able to work around this bug in yorick by adding a file debian/shlibs.local in the source tree with this single line: libmpich 12 libmpich12 Le 08/08/2016 12:12, Thibaut Paumard a écrit : > Hi have open a new bug against libc-bin (ldconfig) to follow that up on > that side: 833728 The libc-bin maintainers think that the proper fix would be to also convert openmpi to multiarch and move the alternative main link also to the multiarch directory. I'm downgrading the severity since a workaround exists to avoid FTBFS. Kind regards, Thibaut.
Bug#831442: mpich: Broken /usr/lib/libmpich.so.12 symlink, depending on installation order
Hi have open a new bug against libc-bin (ldconfig) to follow that up on that side: 833728
Bug#812995: yorick-ynfft: FTBFS with libnfft version 3.3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Thanks,
I forwarded this bug report to upstream.
Kind regards, Thibaut.
Le 08/02/2016 20:19, Gianfranco Costamagna a écrit :
> Hi Thibaut and Debian Science maintainers,
>
> I did a little patch to fix the build failure, but now there is a
> testsuite failure:
>
> here the patch
>
> --- yorick-ynfft-1.0.2.orig/yor_nfft.c +++
> yorick-ynfft-1.0.2/yor_nfft.c @@ -312,7 +312,7 @@ struct _op {
> #define GET_INP_DIMS(op)((op)->plan.N) #define
> GET_OVR_DIMS(op)((op)->plan.n) #define GET_OVR_FACT(op)
> ((op)->plan.sigma) -#define GET_NFFT_FLAGS(op)
> ((op)->plan.nfft_flags) +#define GET_NFFT_FLAGS(op)
> ((op)->plan.flags) #define GET_FFTW_FLAGS(op)
> ((op)->plan.fftw_flags) #define GET_CUTOFF(op)
> ((op)->plan.m) #define GET_NEVALS(op) ((op)->nevals) @@
> -1013,7 +1013,7 @@ static void make_nfft_plan(nfft_plan *pl }
>
> /* Precompute interpolation weights. */ - if ((plan->nfft_flags &
> PRE_ONE_PSI) != 0) { + if ((plan->flags & PRE_ONE_PSI) != 0) {
> nfft_precompute_one_psi(plan); } return;
>
> basically nfft_flags has been renamed in flags.
>
> the testsuite failure is: make[1]: Entering directory
> '/build/yorick-ynfft-1.0.2' /usr/bin/make tests make[2]: Entering
> directory '/build/yorick-ynfft-1.0.2' /usr/lib/yorick/bin/yorick
> -batch nfft-tests.i 1-D transform (A0 vs. A1): SUCCESS - absolute
> error: max. = 1.9e-14, RMS = 3.9e-15 1-D transform (A1 vs. A2):
> SUCCESS - absolute error: max. = 1.2e-15, RMS = 2.8e-16
>
> ERROR (nfft_full_matrix) length must be a strictly positive even
> number LINE: 272 FILE: /build/yorick-ynfft-1.0.2/nfft.i yorick:
> quitting on error in batch mode Makefile:97: recipe for target
> 'tests' failed make[2]: *** [tests] Error 1 make[2]: Leaving
> directory '/build/yorick-ynfft-1.0.2' debian/rules:27: recipe for
> target 'override_dh_auto_test' failed
>
>
> and I'm not sure what does it mean.
>
> do you have any clue?
>
> cheers,
>
> Gianfranco
>
> On Thu, 28 Jan 2016 12:37:48 + Ghislain Antony Vaillant
> wrote:
>> Package: yorick-ynfft Version: 1.0.2-2 Severity: important
>
>> Dear Maintainer,
>
>> This source package fails to build with the latest release of
>> libnfft available in experimental. The relevant portion of the
>> build log is available below.
>
>> Version 3.3 introduced some API breaking changes in the
>> signature of the public structures.
>
>> ``` cc -I. -DVERSION=\"1.0.2\" -Wdate-time -D_FORTIFY_SOURCE=2
>> -g -O2 -fstack-protector-strong -Wformat -Werror=format-security
>> -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DPLUG_IN -I.
>> -I/usr/lib/yorick/include -o yor_nfft.o -c yor_nfft.c
>> yor_nfft.c: In function 'op_eval': yor_nfft.c:380:12: warning:
>> assignment from incompatible pointer type
>> [-Wincompatible-pointer-types] inp_dims = GET_INP_DIMS(op); ^
>> yor_nfft.c: In function 'op_extract': yor_nfft.c:313:33: warning:
>> initialization from incompatible pointer type
>> [-Wincompatible-pointer-types] #define GET_OVR_DIMS(op)
>> ((op)->plan.n) ^ yor_nfft.c:448:22: note: in expansion of macro
>> 'GET_OVR_DIMS' const int *src = GET_OVR_DIMS(op); ^
>> yor_nfft.c:312:33: warning: initialization from incompatible
>> pointer type [-Wincompatible-pointer-types] #define
>> GET_INP_DIMS(op)((op)->plan.N) ^ yor_nfft.c:459:22:
>> note: in expansion of macro 'GET_INP_DIMS' const int *src =
>> GET_INP_DIMS(op); ^ yor_nfft.c:315:44: error: 'nfft_plan {aka
>> struct }' has no member named 'nfft_flags' #define
>> GET_NFFT_FLAGS(op) ((op)->plan.nfft_flags) ^
>> yor_nfft.c:500:27: note: in expansion of macro 'GET_NFFT_FLAGS'
>> int value = get_flags(GET_NFFT_FLAGS(op), GET_FFTW_FLAGS(op)); ^
>> yor_nfft.c:315:44: error: 'nfft_plan {aka struct }'
>> has no member named 'nfft_flags' #define GET_NFFT_FLAGS(op)
>> ((op)->plan.nfft_flags) ^ yor_nfft.c:503:17: note: in expansion
>> of macro 'GET_NFFT_FLAGS' int value = GET_NFFT_FLAGS(op); ^
>> yor_nfft.c: In function 'make_nfft_plan': yor_nfft.c:1016:12:
>> error: 'nfft_plan {aka struct }' has no member named
>> 'nfft_flags' if ((plan->nfft_flags & PRE_ONE_PSI) != 0) { ```
>
>> -- System Information: Debian Release: stretch/sid APT prefers
>> testing APT policy: (500, 'testing'), (2, 'unstable'), (1,
>> 'experimental') Architecture: amd64 (x86_64) Foreign
>> Architectures: i386
>
>> Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale:
>> LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell:
>> /bin/sh linked to /bin/dash Init: systemd (via
>> /run/systemd/system)
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJWuQkBAAoJEJOUU0jg3ChAoQoP/2RzU5YE8GDl/p3kpUCgFvXe
E1LP031iOT/KAB1MXJgbkjGCP0OTiWf0KhFIgeNsoOVwR5JNcvU0en4vTSCx8uSW
/m3ExJ6kC2zKQ2UGKtSqPe8v3ShlgRnibWVLnQ30LS/X608lJBm/YZbq6UpiKXGI
hEFViwvuKa2bH0nkoS3ySIt4V0QAgGrFJ11Cs7GA9RQX5ya6dh9tmP9RAQ9WR15v
r1SSBvuF6n4Z844KcSwHkVH3mj5gJimxpLUOULKvQvtBFSteWbGrFb+jp7RJZ2on
Bug#813725: gyoto: FTBFS: gyoto.C: Error initializing libgyoto
Dear Mattia, Thanks for the report. This seems to be due to a change in behaviour of the autotools. The wrapper for the executable constructed by the autotools used to add $top_builddir/lib/.libs/ to LD_LIBRARY_PATH, so gyoto could find its plug-ins from the built source tree. It does not anymore. There are easy fixes, I'll see whether some autotools package needs to be fixed or whether to work around in the gyoto build system. Kind regards, Thibaut.
Bug#786694: FFTW FTBFS
Control: tag -1 + pending For the record, I have committed my patch to svn (revision 47058). Kind regards, Thibaut. Le 23/06/2015 12:13, Thibaut Paumard a écrit : Control: tag -1 + patch On Sun, 24 May 2015 16:03:44 +0200 Reiner Herrmann rei...@reiner-h.de wrote: I think this could be related to an issue we already faced with automake [1][2]. Depending on the timezone, .info files are sometimes not (re)generated from source (example [3]). This could explain why it doesn't happen in your local setup, when you are not varying the timezone (the .info files are not regenerated with makeinfo), but on jenkins it does. Hi, it's even worse: fftw.info is FTBFS. I have prepared a patch, I would appreciate if someone could ack before I upload it, which I will do before the bunch of reverse dependencies are removed from testing on 2015-07-21. Kind regards, Thibaut. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786694: [Reproducible-builds] Bug#786694: rcs and fftw fail to build with makeinfo: command not found
Control: tag -1 + patch
On Sun, 24 May 2015 16:03:44 +0200 Reiner Herrmann rei...@reiner-h.de
wrote:
I think this could be related to an issue we already faced with automake
[1][2].
Depending on the timezone, .info files are sometimes not (re)generated from
source (example [3]).
This could explain why it doesn't happen in your local setup, when you are
not varying
the timezone (the .info files are not regenerated with makeinfo), but on
jenkins it does.
Hi,
it's even worse: fftw.info is FTBFS.
I have prepared a patch, I would appreciate if someone could ack before
I upload it, which I will do before the bunch of reverse dependencies
are removed from testing on 2015-07-21.
Kind regards, Thibaut.
diff -Nru fftw-2.1.5/debian/changelog fftw-2.1.5/debian/changelog
--- fftw-2.1.5/debian/changelog 2011-11-29 01:48:33.0 +0100
+++ fftw-2.1.5/debian/changelog 2015-06-23 11:48:52.0 +0200
@@ -1,3 +1,13 @@
+fftw (2.1.5-2) unstable; urgency=low
+
+ * Team upload.
+ * Bug fix: FTBFS with TZ=GMT-14, thanks to Holger Levsen (Closes:
+#786694).
+ * Fix fftw.texi and make sure it is always rebuilt.
+ * Check against Policy 3.9.6
+
+ -- Thibaut Paumard thib...@debian.org Tue, 23 Jun 2015 11:48:16 +0200
+
fftw (2.1.5-1) unstable; urgency=low
* Team upload.
diff -Nru fftw-2.1.5/debian/control fftw-2.1.5/debian/control
--- fftw-2.1.5/debian/control 2011-11-29 01:55:44.0 +0100
+++ fftw-2.1.5/debian/control 2015-06-23 11:47:43.0 +0200
@@ -4,8 +4,8 @@
Maintainer: Debian Science Team debian-science-maintain...@lists.alioth.debian.org
Uploaders: Paul Brossier p...@debian.org
Build-Depends: debhelper (= 4.0.0), autotools-dev, autoconf, automake, libtool,
- mpi-default-dev, gfortran
-Standards-Version: 3.9.2
+ mpi-default-dev, gfortran, texinfo
+Standards-Version: 3.9.6
Vcs-Svn: svn://svn.debian.org/svn/debian-science/packages/fftw/
Vcs-Browser: http://svn.debian.org/viewsvn/debian-science/packages/fftw/
Homepage: http://fftw.org
diff -Nru fftw-2.1.5/debian/patches/info-syntax fftw-2.1.5/debian/patches/info-syntax
--- fftw-2.1.5/debian/patches/info-syntax 1970-01-01 01:00:00.0 +0100
+++ fftw-2.1.5/debian/patches/info-syntax 2015-06-23 11:43:46.0 +0200
@@ -0,0 +1,36 @@
+Description: Fix doc/fftw.info syntax
+ title, subtitle and author commands to use {}
+Author: Thibaut Paumard
+Origin: vendor
+Forwarded: no
+Last-Update: 20015-06-23
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/doc/fftw.texi
b/doc/fftw.texi
+@@ -5,6 +5,11 @@
+ @settitle FFTW
+ @c %**end of header
+
++@dircategory Science
++@direntry
++* FFTW: (fftw).FFTW User's Manual
++@end direntry
++
+ @include version.texi
+ @setchapternewpage odd
+ @c define constant index (ct)
+@@ -46,10 +51,10 @@
+ @titlepage
+ @sp 10
+ @comment The title is printed in a large font.
+-@title{FFTW User's Manual}
++@title FFTW User's Manual
+ @subtitle For version @value{VERSION}, @value{UPDATED}
+-@author{Matteo Frigo}
+-@author{Steven G. Johnson}
++@author Matteo Frigo
++@author Steven G. Johnson
+
+ @c The following two commands start the copyright page.
+ @page
diff -Nru fftw-2.1.5/debian/patches/series fftw-2.1.5/debian/patches/series
--- fftw-2.1.5/debian/patches/series 2011-11-29 02:20:21.0 +0100
+++ fftw-2.1.5/debian/patches/series 2015-06-23 11:33:59.0 +0200
@@ -2,3 +2,4 @@
#03_fix_doc.dpatch
#04_configure.dpatch
05_ac_define_syntax.diff
+info-syntax
diff -Nru fftw-2.1.5/debian/rules fftw-2.1.5/debian/rules
--- fftw-2.1.5/debian/rules 2011-11-29 02:06:06.0 +0100
+++ fftw-2.1.5/debian/rules 2015-06-23 11:33:59.0 +0200
@@ -48,6 +48,7 @@
build-indep-stamp: autoreconf-stamp
# docs
F77=gfortran CFLAGS=$(CFLAGS) ./configure $(CONFFLAGS) --enable-float --enable-type-prefix $(ARCHCONFFLAGS)
+ rm -f doc/fftw.info
$(MAKE) -C doc
$(MAKE) -C doc html
$(MAKE) -C FAQ
Bug#787725: [Debian-astro-maintainers] Bug#787725: Bug#787725: gyoto: FTBFS on 32-bit systems (assumes size_t is unsigned long)
Dear Aaron, Le 04/06/2015 20:51, Aaron M. Ucko a écrit : At any rate, thanks for the quick response! I'm both upstream and the debian maintainer here, so that's normal. Thanks for YOUR input. I will upload shortly a version with the proper fix, actually checking whether it is possible to cast between the two function pointer types in configure, and implement the size_t specialization conditionally based on that. For the record, C++11 provides std::is_same that could be used to determine whether size_t is a typedef to unsigned long, when Gyoto drops support for non-C++11-compliant compilers. Kind regards, Thibaut. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787725: [Debian-astro-maintainers] Bug#787725: gyoto: FTBFS on 32-bit systems (assumes size_t is unsigned long)
Le 04/06/2015 15:33, Aaron M. Ucko a écrit : I would suggest (unconditionally) extending Gyoto::Property with get_size_t and and set_size_t methods, and redefining GYOTO_PROPERTY_SIZE_T accordingly. Could you please take a look? Dear Aaron, Unconditionally, this will not work, at least the way Property is supposed to work: on 64-bit arches, the compiler will not be able to distinguish the two distinct constructors for unsigned long and size_t because it really is the same. Besides, I'd rather not break the ABI already. I could extend Property with new typedefs, accessors and constructors for size_t only for the architectures that need it, but I don't know how to determine this automatically. There is a solution that appears to be working but relies on undefined behaviour. I can also extend the test suite to make sure it actually does the right thing (I've tested manually under i386 already). Do you see a real-world case in which this will fail: /// Define a Property of type Long #define GYOTO_PROPERTY_SIZE_T(class, name, fname) \ Gyoto::Property \ (#name, \ reinterpret_castGyoto::Property::set_unsigned_long_t((void (Object::*)(size_t val))class::fname), \ reinterpret_castGyoto::Property::get_unsigned_long_t((size_t (Object::* )() const)class::fname)), Kind regards, Thibaut. -- * Dr Thibaut Paumard | LESIA/CNRS - Table équatoriale (bât. 5) * * Tel: +33 1 45 07 78 60 | Observatoire de Paris - Section de Meudon * * Fax: +33 1 45 07 79 17 | 5, Place Jules Janssen* * thibaut.paum...@obspm.fr | 92195 MEUDON CEDEX (France) * smime.p7s Description: Signature cryptographique S/MIME
Bug#786715: stellarium: Uses private copies of external headers
Le 24/05/2015 20:46, Sune Vuorela a écrit : Source: stellarium Version: 0.13.3-1 Severity: serious Hi, I think the severity of this bug is overstated. There is no reason why this should warrant removing stellarium from testing. Upstream is working on the issue, I suggest downgrading the severity to normal or important at most. Kind regards, Thibaut. Dear Maintainer, Stellarium has a copy of qzipreader/writer header files taken out of Qt, and uses the internal, but unfortuantely available, symbols out of Qt Gui. It can be directly seen due to the dependency on the internal qt versioning as in qtbase-abi-5-3-2 which is generally a sign of doing something dirty, and will require a rebuild on each new Qt upload. If the QZipReader/writer classes changes (they can do that, they are an internal thing to Qt), stellarium will not work or maybe even crash randomly. I'd suggest one of the following solutions: 1) Use an actual public zipping library. KArchive and quazip are two currently available in Debian 2) Copy out the relevant bits from Qt *and rename* them (like add a namespace or something). (The current qzip.cpp found in the external directory could be used, but needs to actually be built. Hint: ! is not a valid negation operator in cmake) 3) much discouraged, but still better than status quo. Use the privately exposed headers in qtbase5-private-dev of qzipreader_p.h and qzipwriter_p.h to at least ensure that things are in sync. This also requires changes to the build system. 4) convince Qt upstream to make QZip* public api. That's likely not going to happen, and even if it was, we would need a interrim solution. Getting something going soon would be nice to detangle stellarium from the next qt upload. And 3) doesn't solve that. I do somewhere have a quick and dirty patch for 2), but I really think you should consider 1). /Sune -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) 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) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780729: Bug#780725: PATH used for building is not specified
Hi, On Wed, 18 Mar 2015 13:58:10 +0100 Holger Levsen hol...@layer-acht.org wrote: clone 780724 -1 reassign -1 pbuilder severity -1 serious retitle -1 pbuilder must defines PATH as in debian-policy (and as on buildds) # justification: breaks package builds, see 780724 I challenge this justification. Also I'm not going to downgrade it myself, pbuilder should not be removed from jessie just because of this bug, this is just not a reasonable possible outcome. I don't think that serious is the right severity. This bug does not provoke FTBFS on the auto-builders and it remains possible to build the package by invoking dpkg-buildpackage by hand. The fact that pbuilder fails to build a certain package does not means that if breaks the build of this package. Besides, In any case, policy currently has: 10.10. File names - The name of the files installed by binary packages in the system PATH (namely `/bin', `/sbin', `/usr/bin', `/usr/sbin' and `/usr/games') must be encoded in ASCII. This section is intended to mean that file names in these directory must be encoded in ASCII. I find it contrived to use this section as a definition of a the PATH that should be used for building. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#770008: [affects jessie] Re: calendar-google-provider: Can no longer connect to Google calendars
Control: found -1 31.2.0-1 Hi, Same here, running testing. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#761277: gdc uninstallable on kfreebsd because of missing dep. libphobos-4.9-dev
Package: gdc Version: 4.9.1-4 Severity: grave Hi, gdc currently depends on libphobos-4.9-dev, including on kfreebsd-*, but libphobos-4.9-dev is not beeing built on these architectures. It may be that the bug is that libphobos should be built on kfreebsd. From the gcc-4.9 build log: -Dlibphobos_archs=amd64 armel armhf i386 x32 kfreebsd-amd64 kfreebsd-i386 but Will not build the phobos D runtime library: disabled for system kfreebsd-gnu Kind regards, Thibaut. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: kfreebsd-i386 (i386) Kernel: kFreeBSD 9.0-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash signature.asc Description: OpenPGP digital signature
Bug#707268: Fwd: plplot_5.10.0-0.1_amd64.changes is NEW
Message original Sujet: plplot_5.10.0-0.1_amd64.changes is NEW Date : Wed, 10 Sep 2014 09:50:11 + De : Debian FTP Masters ftpmas...@ftp-master.debian.org Pour : Andrew Ross andrewr...@users.sourceforge.net,Thibaut Paumard thib...@debian.org binary:libplplot-ada1 is NEW. binary:libplplot-ada1-dev is NEW. binary:libplplot-c++11 is NEW. binary:libplplot-fortran10 is NEW. binary:libplplot12 is NEW. binary:plplot-tcl-bin is NEW. binary:plplot12-driver-cairo is NEW. binary:plplot12-driver-qt is NEW. binary:plplot12-driver-wxwidgets is NEW. binary:plplot12-driver-xwin is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will recieve an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html signature.asc Description: OpenPGP digital signature
Bug#760943: plplot FTBFS due to HDF5 transition
Source: plplot Version: 5.9.9-5 Severity: grave Hi, Even when 707268 is fixed, plplot still fails to build from source because the build system is not able to cope with the new location of hdf5.h. A quick and dirty fix is to remove the check for hdf5.h in cmake/modules/octave.cmake and adding the right flags to CPPFLAGS in debian/rules: CPPFLAGS = $(shell dpkg-buildflags --get CPPFLAGS) \ $(shell mkoctfile -p INCFLAGS) Kind regards, Thibaut. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707268: Bug#740085: Bug#725957: [NMU] Bug#740085: package plplot 5.10.0
Le 09/09/2014 12:17, Olly Betts a écrit : I'm happy to sponsor or NMU if nobody more connected to the package is able to. I'm working on an NMU. I will presumably upload it tomorrow. Andrew, if you wish I can send you my changes so that you can review them. I will then be happy to sponsor your upload. I think this would really be a good idea to put plplot in team maintenance. You are doing a great job with this complex package, but it would have been uploaded weeks ago if it had been officially maintained within the science team for, for instance. You would still be the main uploader for the package, but that would unable people to more easily give you a hand rather a hint when it comes to fixing fairly simple RC bugs. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#707268: Bug#740085: Bug#725957: [NMU] Bug#740085: package plplot 5.10.0
Le 09/09/2014 12:17, Olly Betts a écrit : I'm happy to sponsor or NMU if nobody more connected to the package is able to. I'm working on an NMU. I will presumably upload it tomorrow. Andrew, if you wish I can send you my changes so that you can review them. I will then be happy to sponsor your upload. I think this would really be a good idea to put plplot in team maintenance. You are doing a great job with this complex package, but it would have been uploaded weeks ago if it had been officially maintained within the science team for, for instance. You would still be the main uploader for the package, but that would unable people to more easily give you a hand rather a hint when it comes to fixing fairly simple RC bugs. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#707268: Bug#740085: Bug#725957: [NMU] Bug#740085: package plplot 5.10.0
Le 06/09/2014 17:24, Olly Betts a écrit : On Thu, Jul 17, 2014 at 02:15:41PM +0200, Thibaut Paumard wrote: I should have some spare time next week. I'll be glad to read your findings, and we can keep each other informed on whether we get to it. It's been more than 3 weeks now - what's the status of the upload? Looking at the package on mentors, the minified JS source seems to be the only major issue. But as the current package in unstable also has that issue, and this upload will close 5 RC bugs, 2 important bugs, and a request for a new upstream version, I'm inclined to think we shouldn't let the perfect be the enemy of the good. The package that is waiting on mentors looks like a vast improvement over what's in the archive currently. I'd really like to see the last few wxwidgets3.0 transition bugs dealt with, and ideally not by removing packages (unless that's what the maintainer prefers). And plplot is also holding up gnudatalanguage there - that's 2 of the 7 remaining packages which I'm hoping to see transitioned. I'd prefer an upload sponsored by someone who's actively sponsoring plplot uploads, but the freeze is less than 2 months away now, so I'm starting to consider just sponsoring it myself. Hi, I have had to withdraw due to unexpected events. The package in mentors does not build anymore (I should check about the package in unstable, no time right now), due to the hdf5 transition. I've told Andrew last week about this. This can be fixed by removing the bits that check for hdf5.h in cmake/modules/octave.cmake (see attached patch) and adding the right flags to CPPFLAGS in debian/rules: CPPFLAGS = $(shell dpkg-buildflags --get CPPFLAGS) \ $(shell mkoctfile -p INCFLAGS) Of course, there must be a less brutal solution. I'm also considering uploading myself, but unless Andrew fixes this FTBFS, this will have to be half sponsoring, half NMUing. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#758496: [Debian-astro-maintainers] Bug#758496: stellarium: Fails to start
Control: severity -1 important Hi, I'm downgrading the severity to important because the bug seems to affect only one user so far. The package therefore remains usable by the majority of users and should not be removed from testing. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#707268: [NMU] Bug#740085: package plplot 5.10.0
Le 24/06/2014 11:09, Thibaut Paumard a écrit : Dear Andrew, The freeze is approaching. We need plplot for gnudatalanguage. Do you plan on uploading plplot 5.10.0 so it can be part of jessie? Kind regards, Thibaut. Hi Andrew, I'd rather sponsor a package you would have prepared, but failing that I will try to make a non-maintainer upload next week. Please feel free to get back to me if I shouldn't, or if you prepare the upload. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#707268: Bug#725957: [NMU] Bug#740085: package plplot 5.10.0
Hi Axel, Le 17/07/2014 13:09, Axel Beckert a écrit : Hi Thibaut, Thibaut Paumard wrote: I'd rather sponsor a package you would have prepared, but failing that How did you fail that? I reviewed his package at https://mentors.debian.net/package/plplot Thanks for pointing this out. I missed it because - plplot does not appear on the front-page of mentors, - there is no bug againsts the sponsorship-request pseudo package, - and no mention of this upload in this bug report (740085). I figured that was enough places to look for an information that should have been directed to me directly, who explicitly offered help and asked whether there was a plan. [...] I'm though likely not able to sponsor the (fixed or workarounded) package the next few days as I'm currently travelling. So feel free to sponsor it, if you have time. I'd be happy about it. I can forward you my findings this evening, if preferred. I should have some spare time next week. I'll be glad to read your findings, and we can keep each other informed on whether we get to it. Kind regards, Thibaut. I'd take care of the next GDL upload then in a few days. Regards, Axel signature.asc Description: OpenPGP digital signature
Bug#747976: yorick-av: FTBFS on kfreebsd-i386
Control: severity -1 normal Control: retitle -1 yorick-av: some codecs SIGFPE on kfreebsd-i386 Le 13/05/2014 14:20, Sebastian Ramacher a écrit : When rebuilt for the libav transition, yorick-av failed to build kfreebsd-i386: |dh_auto_test -a | make[1]: Entering directory '/«PKGBUILDDIR»' | /usr/lib/yorick/bin/yorick -batch check.i | == | testing extension: 'mpg' | == | Output #0, mpeg, to 'libavcheck.mpg': | Stream #0.0: Video: mpeg1video, yuv420p, 704x288, q=2-31, 400 kb/s, 90k tbn, 24 tbc | ERROR (*main*) Floating point interrupt (SIGFPE) | WARNING detailed line number information unavailable | now at pc= 177 (of 225), failed at pc= 183 | LINE: 53 FILE: /«PKGBUILDDIR»/check.i | yorick: quitting on error in batch mode | make[1]: *** [check-dll] Error 1 Hi, I have checked that some codecs work. As a temporary fix, I have disabled the test suite on kfreebsd-i386 and decreased the severity. This is the only architecture with this failure. All the tests pass correctly on similar architectures: kfreebsd-amd64 and on i386. In my experience, this usually means that the bug is actually in the architecture itself (in the libc or in the kernel). I have tracked the SIGFPE down to strtod() which is called by av_expr_parse() with the string tex^qComp inside avcodec_open2(). Of course SIGFPE is asynchronous and I can't be certain strdtod() is the actual culprit. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#707268: Bug#725957: gnudatalanguage and plplot not migrating
Le 26/03/2014 00:52, Axel Beckert a écrit : forwarded 725957 http://sourceforge.net/p/gnudatalanguage/bugs/594/ kthxbye Hi, Hi, Thibaut Paumard wrote: Do you need help fixing plplot and gnudatalanguage so they can reach testing? As documented in the BTS I've forwarded the FTBFS to Sylwester Arabas (the one of the GDL upstream devs I had most contact with) by e-mail after I noticed them, but got no reply so far. He though opened an issue at their tracker just an hour ago: http://sourceforge.net/p/gnudatalanguage/bugs/594/ That's because I had been talking with a colleague who is also involved upstream. I decided to offer my help here while he pinged Sylwester. I think it would make sense to maintain them in a team, either debian-science (CC:) or debian-astro. I'm happy if someone else would help keeping GDL in Debian in shape or even wants to take over maintainership completely. We both, Gürkan and me, only maintain GDL in Debian because we need it at work. We don't use it ourselves. I don't mean to hijack your package. However, it would make sense for me to get involved since I can meet upstream face to face anytime. With regards to plplot: I reviewed it for sponsoring and there's a package at https://mentors.debian.net/package/plplot -- it's mostly fine with one exception, it should have version 5.9.10-1, not version 5.9.10-2. The older 5.9.10-1 package at the same location has more issues and fixing them resulted in the 5.9.10-2 upload to mentors. I'll see if I can help for plplot and gdl on the short term, and we'll see later about adoption and team maintenance. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#707268: gnudatalanguage and plplot not migrating
Hi guys, Do you need help fixing plplot and gnudatalanguage so they can reach testing? I think it would make sense to maintain them in a team, either debian-science (CC:) or debian-astro. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#725549: Bug #725549: yorick-gl: FTBFS: make[1]: *** No rule to make target `check.i', needed by `check-dll'
Le 23/11/2013 16:10, Michael Banck a écrit : tags 725549 +pending tags 725549 +patch thanks Hi, Thanks Michael, I thought I'd fixed it already because I had to fix the same on other packages. Your fix is correct. The The Makefile inherits a check rule from a build system, so dh has recently started running it automatically which does not work. Regards, Thibaut. On Sun, Oct 06, 2013 at 10:00:57PM +0200, David Suárez wrote: Source: yorick-gl Version: 1.1+cvs20070922+dfsg-6 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20131006 qa-ftbfs Justification: FTBFS on amd64 During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): glTarray.c: In function 'yglTarrayAlpha': glTarray.c:162:3: warning: incompatible implicit declaration of built-in function 'sprintf' [enabled by default] sprintf(msg, in yglTarrayAlpha, alpha_pass is %d\n, alpha_pass); ^ cc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -DPLUG_IN -I. -I/usr/lib/yorick/include -D_FORTIFY_SOURCE=2 -c -o gltexsubs.o gltexsubs.c cc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -DPLUG_IN -I. -I/usr/lib/yorick/include -D_FORTIFY_SOURCE=2 -c -o glustub.o glustub.c cc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -DPLUG_IN -I. -I/usr/lib/yorick/include -D_FORTIFY_SOURCE=2 -c -o glGlyph.o glGlyph.c cc -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -DPLUG_IN -I. -I/usr/lib/yorick/include -DUSE_MESA_PIXMAPS -o oglx.o -c oglx.c /usr/lib/yorick/lib/codger w yorgl cntrfunc.i glfunc.i found cntrfunc.i in current directory found glfunc.i in current directory cc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -DPLUG_IN -I. -I/usr/lib/yorick/include -D_FORTIFY_SOURCE=2 -c -o ywrap.o ywrap.c cc -Wl,-z,relro -fPIC -shared -o yorgl.so ContourTets3D.o Gradient3D.o isotree.o slicetree.o glPolys.o glStrips.o gltexture.o glcode.o glfunc.o glMouse.o glx11view.o glx11setup.o TriUtil.o dlist3d.o glTarray.o gltexsubs.o glustub.o glGlyph.o oglx.o ywrap.o -lGL -lXext -lX11 -lm make[2]: Leaving directory `/«BUILDDIR»/yorick-gl-1.1+cvs20070922+dfsg' make[1]: Leaving directory `/«BUILDDIR»/yorick-gl-1.1+cvs20070922+dfsg' dh_auto_test make[1]: Entering directory `/«BUILDDIR»/yorick-gl-1.1+cvs20070922+dfsg' make[1]: *** No rule to make target `check.i', needed by `check-dll'. Stop. make[1]: Leaving directory `/«BUILDDIR»/yorick-gl-1.1+cvs20070922+dfsg' dh_auto_test: make -j1 check returned exit code 2 Not sure where this is from as yorick-gl does not seem to have any checks. I've overriden it and uploaded a fixed package to DELAYED/5-days, see attached debdiff. Michael -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726733: av_register_all() segfaults on s390x in some cases (regression, causes FTBFS)
Control: retitle -1 av_register_all() segfaults on s390x in some cases Control: severity -1 normal Control: thanks Hi, Downgrading the severity as it's actually not a regression: the package always failed building on s390x with the same error message. I thought I did my homework and checked that already, apparently I did it wrong. Interestingly, it also used to fail on s390 but the last build was successful. See: https://buildd.debian.org/status/logs.php?pkg=yorick-avarch=s390 Kind regards, Thibaut. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726733: av_register_all() segfaults on s390x in some cases (regression, causes FTBFS)
Dear Reinhard, Le 03/11/2013 02:11, Reinhard Tartler a écrit : Hi Thibaut, can you perhaps also provide a backtrace? It seems that there are no public s390x porter machines where I could get that myself. Unfortunately, I can't: gdb seems to be broken on s390x. Reporting bug as we speak: (sid_s390x-dchroot)thibaut@zelenka:~/buggy$ gdb --args yorick -i check.i GNU gdb (GDB) 7.6.1 (Debian 7.6.1-1) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as s390x-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/lib/yorick/bin/yorick...Reading symbols from /usr/lib/debug/usr/lib/yorick/bin/yorick...done. done. (gdb) r Starting program: /usr/bin/yorick -i check.i Couldn't write registers: Invalid argument. (gdb) Also, I wonder why s390x would require -DPIC -fPIC in compilation flags, but s390 would not. Where did you get that impression? As far as I can tell, the required flags are -fPIC -shared, on all platforms. In the meantime, I checked that my minimal example compiles and runs fine on wheezy s390x. I can't check sid s390 as it has been retired. Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#726733: av_register_all() segfaults on s390x in some cases (regression, causes FTBFS)
Here comes the minimal example. See file README. buggy.tgz Description: application/compressed-tar signature.asc Description: OpenPGP digital signature
Bug#726733: av_register_all() segfaults on s390x in some cases (regression, causes FTBFS)
Le 22/10/2013 18:13, Moritz Muehlenhoff a écrit : After investigation, I can build a minimal example which still fails and only contains a call to av_register_all() and segfaults precisely on this line. Adding s390@l.d.o to CC. Thibaut, can you post your minimal test case? Cheers, Moritz Oops, I forgot, thanks for mentioning. I've attached it to the bug report know, to avoid flooding e-mail addresses: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;filename=buggy.tgz;att=1;bug=726733 Kind regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#726733: av_register_all() segfaults on s390x in some cases (regression, causes FTBFS)
Package: libavformat-dev Version: 6:9.10-1 Severity: serious File: /usr/include/libavformat/avformat.h Hi, My package yorick-av fails to build on s390x: https://buildd.debian.org/status/package.php?p=yorick-av It used to build fine previously. After investigation, I can build a minimal example which still fails and only contains a call to av_register_all() and segfaults precisely on this line. This is in the context of a plug-in which is dlopen'ed from an interpreter (yorick). The plug-in works fine on all other architectures. I also tried calling av_register_all() directly from main() in a C program, it doesn't fail there. There may be something odd happening with the dlopening or the link flags that this requires (-fPIC -shared). Regards, Thibaut. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: s390x Versions of packages libavformat-dev depends on: ii libavcodec-dev 6:9.10-1 ii libavformat54 6:9.10-1 ii libavutil-dev 6:9.10-1 libavformat-dev recommends no packages. libavformat-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722610: yorick-av: FTBFS on armhf: ERROR (*main*) Segmentation violation interrupt (SIGSEGV)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Control: tags -1 +pending +upstream Hi, Thanks for reporting. I found the problem, working at releasing the fixed upstream version, then a new Debian package. It's actually surprising it didn't bite earlier: ypush_av, responsible for instanciating the state structure, did not explicitly return a pointer to it. Regards, Thibaut. Le 12/09/2013 20:53, Sebastian Ramacher a ￩crit : Source: yorick-av Version: 0.0.1-3 Severity: serious Justification: FTBFS but built successfully in the past Tags: sid jessie Control: block 706798 by -1 yorick-av currently fails to build on armhf: |dh_auto_test | make[1]: Entering directory `/home/sramacher/yorick-av-0.0.1' | /usr/lib/yorick/bin/yorick -batch check.i | == | testing extension: 'mpg' | == | ERROR (*main*) Segmentation violation interrupt (SIGSEGV) | WARNING detailed line number information unavailable | now at pc= 177 (of 225), failed at pc= 183 | LINE: 53 FILE: /home/sramacher/yorick-av-0.0.1/check.i | yorick: quitting on error in batch mode | make[1]: *** [check-dll] Error 1 I was able to reproduce the issue on harris.d.o and got following backtrace with gdb: | Program received signal SIGSEGV, Segmentation fault. | Y_av_write (argc=2) at yav.c:335 | 335 AVCodecContext *c = obj-video_st-codec; | (gdb) bt | #0 Y_av_write (argc=2) at yav.c:335 | #1 0x000645e6 in EvalBI () | #2 0x00072e98 in Eval () | #3 0x00055c20 in YRun () | #4 0x0005726e in DoTask () | #5 0x0005738a in y_on_idle () | #6 0x0001dadc in p_on_idle () | #7 0x0001d750 in u_waiter () | #8 0x in ?? () A full build log is available at https://buildd.debian.org/status/fetch.php?pkg=yorick-avarch=armhfver=0.0.1-3stamp=1378229150. Regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJSXp9IAAoJEJOUU0jg3ChAMtoP/0yTuXRwio2zHx1CfXCmbidV Y9KljtPYklw34di6jQsdjRPw9rpikkUKZxRxWPPxj37gk+oX2aNH7NnirawQ9uon MfXWTSXrPsd8GqVoed3ioKrgZTXuacaYHF6XEIYV4nRiQ6bANzgbqFNe3dK71KOS v5c6AC4eGO+jYt112rfrYZuJnpkn33tF9LOeKY6o4aoiG77EboUljuogt8eEfXip LX/MbsxViXi6kIKay2A89Co2SsNhn3FJ6j9ZYvSkvKJ3h9reAYUn+NclU+qRlpvs dW2q3PyitXnIgLO5lPlzUMTBALo+svxKlbhoEJVMsUBv5TEkf6cVFKtwjk+I5ku2 dA4Er+917xVuoDRyDX0ZD4O3iWhkWXTUgfwPW5sP26HB4vb+Tvoq/CigRMX8rrIu G8usquTw65S8KAYNF7hh4qMwvZjiueWB4vzLXjF9ptgO37NBW+FsssFGjJ8TGAbo l3OjU0w8QBWpZfj8IkD2CQRmb9PB7B6E3m6bc7mGHJlnqVR8QNBy6ctsvmsxMYAl ilLQOOjY8WEnkHzy85WvWqvhT/B1AuJBZO7Waj11NOI6qHC4fqsMIpdmA0LxrVrY V8OKqmwfg8NRS0v9fUrNRhYZ4uqZtLntIFiNviH4/0b7wXxd1/wnHQZ6p+RYrsk6 DydsN3Fes6RgJRJx+3wl =y/+5 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722662: yorick and gist: error when trying to install together
Le 13/09/2013 08:43, Ralf Treinen a écrit : Package: gist,yorick Version: gist/4.0.3-2 Version: yorick/2.2.02+dfsg-6+b1 Severity: serious User: trei...@debian.org Usertags: edos-file-overwrite Date: 2013-09-13 Architecture: amd64 Distribution: sid Here is a list of files that are known to be shared by both packages (according to the Contents file for sid/amd64, which may be slightly out of sync): /usr/bin/gist /usr/share/man/man1/gist.1.gz Hi, /usr/bin/gist has been in the Yorick package for about 15 years. It is a user interface. It's a viewer for Computer Graphics Metafile (CGM) files. What is this ruby gist thing? How popular is it and is it supposed to be called by the user? Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692753: Balazar dies soon with Error: class 'soya.GLError'(GL_INVALID_OPERATION)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 11/11/2012 17:36, Andrey Rahmatullin a écrit : On Thu, Nov 08, 2012 at 03:25:35PM +0100, Thibaut Paumard wrote: I just installed balazar to try it out. After a few seconds in the game (around 30s?) the game crashes. The graphic window shows an error message: Error: class 'soya.GLError'(GL_INVALID_OPERATION). For me it dies with SIGFPE right after pressing Start. Hi, I believe this is an instance of #630946 which can be worked around by deactivating sound in the game preference panel... Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQn9z6AAoJEJOUU0jg3ChATWEQAJY35aPFDjaCHtvystT9r5TA ls2iWUt+frffZPomTmYPuUi3+LDSzLdJP7eyf4FEIAob97HPlleGebdOB++9dqt2 aE5MCiOfuNyCEPbAufd8ADqljRQev2uA9KkVKpN00NBhT1hp/7uPgpED0CnMMShu Gcwgj/IDyn9AlkzVt+ucYNZKdVj05m4UL2pt1jgc4sJrr3YKWZUPMC4A1hJaAg40 S2RELtVti8YJv1KLJXNzIZjGqtwyOb4bXBJmDFcAu4WA6UUKx5TAcyBMSkoRkL4j 8H7W4F8TV+F7DdktM6exzAXjXSaxDFzq2aVFUZ9OESJO9XcBwLhAP/BK/W07lujr usY+S+XR0uRnj8m7w342zocwXk++RKTukZHOKmJIsqwsHdn94fAUsrcd900JXit2 hYjyeBK/MyXkV52oWxs9lUUDcu95X40n9wyKisrWJUeIuDrHJy+Fbx9nxS8UF9PF VIEedqHcJ7Qoig57l+XArrYFYTv9Sw8KBc/AkWFR8UB8jSIQNQBp6uLdycHFw1cI SAMaEJzfKoUQbM6ANYeEKN7PHlkeg+D1sYzPm+LZIs4LgljSeNpMgh/xaOHr6jqR O4l5urtXFeVVo9AxM9o14v7UDf0UnItnjCs1ZiK1UAUtnhDbi2YWUFhHUIC3j/JD RD0LIftMKRNpbDe9r1Mu =cHZ0 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692753: Balazar dies soon with Error: class 'soya.GLError'(GL_INVALID_OPERATION)
Package: balazar Version: 0.3.4.ds1-6.1 Severity: grave Hi, I just installed balazar to try it out. After a few seconds in the game (around 30s?) the game crashes. The graphic window shows an error message: Error: class 'soya.GLError'(GL_INVALID_OPERATION). The console from whihc I started the game shows: thibaut@b-wing:~/Documents/CND/2011/data/10mayosir$ balazar * Balazar * Balazar lives in /usr/share/games * Soya * Using Software Surface. * Soya * Using 8 bits stencil buffer * Soya * OpenGL initialization [OK] * Soya * version 0.15rc1 * Using OpenGL 3.3.0 NVIDIA 304.48 * - renderer : GeForce 320M/integrated/SSE2 * - vendor : NVIDIA Corporation * - maximum number of lights: 8 * - maximum number of clip planes : 8 * - maximum number of texture units : 4 * - maximum texture size: 8192 pixels * Using OpenAL 1.1 ALSOFT 1.14 * - renderer : OpenAL Soft * - vendor: OpenAL Community * Soya * Using Software Surface. * Soya * Using 16 bits stencil buffer * Soya * OpenGL initialization [OK] * Tofu * Creating new player thibaut... * Balazar * Creating level 0, 0... * Tofu * Level level_0_0 38667584 activated ! * Tofu * Player thibaut login ! GL_INVALID_OPERATION Traceback (most recent call last): File /usr/share/games/balazar/gui.py, line 216, in play_solo r = balazar.game_interface.start_single(globdef.NAME, test) File /usr/share/games/balazar/game_interface.py, line 110, in start_single r = tofu.single.serve_forever(login = login, password = password) File /usr/lib/pymodules/python2.7/tofu/single.py, line 75, in serve_forever return tofu.IDLER.idle() File main_loop.pyx, line 125, in _soya.MainLoop.idle File main_loop.pyx, line 185, in _soya.MainLoop.main_loop File main_loop.pyx, line 281, in _soya.MainLoop.render File renderer.pyx, line 434, in _soya.render File renderer.pyx, line 410, in _soya.check_gl_error _soya.GLError: GL_INVALID_OPERATION Regards, Thibaut. -- System Information: Debian Release: wheezy/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages balazar depends on: ii python 2.7.3~rc2-1 ii python-cerealizer 0.7-4 ii python-pyvorbis1.5-1 ii python-soya0.15~rc1-8 ii python-support 1.0.15 ii python-tofu0.5-5 balazar recommends no packages. Versions of packages balazar suggests: pn python-psyco none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689443: FTBFS in current wheezy environment (GCC 4.7)
package mango lassi
tags 689443 +patch
thanks
Hi,
I cannot confirm the FTBFS (the package builds fine for me in Wheezy and
SID cowbuilder, with gcc (Debian 4.7.1-7) 4.7.1).
I see where it comes from though and the trivial patch attached *should*
fix it.
Regards, Thibaut.
diff -Nru mango-lassi-001+dfsg/debian/changelog
mango-lassi-001+dfsg/debian/changelog
--- mango-lassi-001+dfsg/debian/changelog 2011-07-22 14:48:12.0
+0200
+++ mango-lassi-001+dfsg/debian/changelog 2012-10-03 11:32:08.0
+0200
@@ -1,3 +1,12 @@
+mango-lassi (001+dfsg-4.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * debian/patches/fix-ftbfs-689443.patch:
+Bug fix: FTBFS in current wheezy environment (GCC 4.7), thanks to
+Michael Tautschnig (Closes: #689443).
+
+ -- Thibaut Paumard thib...@debian.org Wed, 03 Oct 2012 11:32:08 +0200
+
mango-lassi (001+dfsg-4) unstable; urgency=low
* debian/patches/fix-libnotify0.7-compatibility.patch:
diff -Nru mango-lassi-001+dfsg/debian/patches/fix-ftbfs-689443.patch
mango-lassi-001+dfsg/debian/patches/fix-ftbfs-689443.patch
--- mango-lassi-001+dfsg/debian/patches/fix-ftbfs-689443.patch 1970-01-01
01:00:00.0 +0100
+++ mango-lassi-001+dfsg/debian/patches/fix-ftbfs-689443.patch 2012-10-03
11:26:58.0 +0200
@@ -0,0 +1,14 @@
+Index: mango-lassi-001+dfsg/src/lassi-prefs.c
+===
+--- mango-lassi-001+dfsg.orig/src/lassi-prefs.c2010-05-18
14:00:55.0 +0200
mango-lassi-001+dfsg/src/lassi-prefs.c 2012-10-03 11:26:18.0
+0200
+@@ -280,7 +280,8 @@
+ g_signal_connect(i-icon_view, selection-changed,
G_CALLBACK(on_selection_changed), i);
+
+ cells = gtk_cell_layout_get_cells (GTK_CELL_LAYOUT (i-icon_view));
+-for (GList* cell = cells; cell; cell = cell-next) {
++GList* cell=0;
++for (cell = cells; cell; cell = cell-next) {
+ if (!GTK_IS_CELL_RENDERER_TEXT (cell-data))
+ continue;
+
diff -Nru mango-lassi-001+dfsg/debian/patches/series
mango-lassi-001+dfsg/debian/patches/series
--- mango-lassi-001+dfsg/debian/patches/series 2011-07-22 13:46:02.0
+0200
+++ mango-lassi-001+dfsg/debian/patches/series 2012-10-03 11:25:14.0
+0200
@@ -2,3 +2,4 @@
skip-patch-by-POTFILES.skip.patch
fix-ftbfs-binutils-gold.patch
fix-libnotify0.7-compatibility.patch
+fix-ftbfs-689443.patch
signature.asc
Description: OpenPGP digital signature
Bug#659061: brasero: segfaults when creating a subfolder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I can still reproduce this bug with brasero 3.4.1-3. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQadCYAAoJEJOUU0jg3ChARs0P/08Jz0NBSjxsHpujeYea9JZp 6SMxKzkpYpsvBL/3mUkpf2v++syHpAFLMDmjVSTvbp5+pLfbEg6WWGTuUEaDu5ax WF6jUHn7PPe8lGSj9EQqcl1WP6frXmzLJszB3WXJjQGTYUn20ypYpK6MEMeZiM0Y /SZGi0ja3PL6AgDiq7Viid0MQeFv6pCph1u1JD2pE2VQUmB1YZDo/UaIZf53uI3P AgI043qI/uoEtoaJhT3C+7pfWfuYXVkX1hUSBUCVFLDXBGy1pT4MrDqvEd7U9wBv y2n1BFvrlo8NbQFOXueZxPpvd7Csq3+mGYuDoVTiyTp1pc5yFJV7lRvLX769Mh/y 1kn8L+QOlgtCs9VOabSfVez9PDI7CqTDjkKiiI7Nkm3V+nCfFSDKRuzFgCSHkJs/ 8cIERf2Uls87kka6fIobHKFTKXqC8FP8b7uPUERLDRVcJfbKSq8+eW7h8a2mDMWo pD61tDpIiFCFuZgab1BSBxhdAwKEzrHIQbiLI/S7vR22QCJlDZW0yfouJKCfDnuo pFJSeYM24h8lee4bRW5vLHrOaPnQgSh1DmmuEXU1DlxhLHYKPE5Umi7HTI4QFpoP t7FmCGRNNNlt/XvSzAodNd9KFhJA/UvoK7SrGzKSVi+plsJWix5Uf6GG/dJtIlRa MTgMS23WzRA7fFZJYlOW =v/k3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688095: regexp/yfnmatch.h is non free
Source: yorick Severity: serious Hi, regexp/yfnmatch.h is still under non-DFSG 4-clause BSD license. It is clearly a left-over from older times as the rest of Yorick is under 3-clause BSD license. Upstream has already commited an update at: https://github.com/dhmunro/yorick/blob/master/regexp/yfnmatch.h Regards, Thibaut. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676423: NMUing doxygen to testing-proposed-updates
Dear release team (and Matthias),
Concerning http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676423
There is a grave bug in doxygen (segfault which causes other packages to
FTBFS) which has been fixed in unstable together with other minor fixes,
including a new upstream release. I believe that means that this fixed
package will not be able to migrate to testing.
I would like to upload a minimalistic fix to testing-proposed-updates as
an NMU. The package would simply add this patch:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=21;filename=fix_676423_segfault.patch;att=1;bug=676423
and the version number would be 1.8.1-1+deb70u1 (as per my understanding
of
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu-changelog
).
A prospective debdiff is attached.
Is that good for you?
Kind regards, Thibaut.
diff -Nru doxygen-1.8.1.1/debian/changelog doxygen-1.8.1.1/debian/changelog
--- doxygen-1.8.1.1/debian/changelog2012-06-13 00:52:55.0 +0200
+++ doxygen-1.8.1.1/debian/changelog2012-08-06 14:49:31.0 +0200
@@ -1,3 +1,11 @@
+doxygen (1.8.1.1-1+deb70u1) testing-proposed-updates; urgency=low
+
+ * Non-maintainer upload
+ * Bug fix: new segmentation faults in version 1.8.1-1, thanks to Boris
+Pek (Closes: #676423).
+
+ -- Thibaut Paumard paum...@users.sourceforge.net Mon, 06 Aug 2012 14:49:31
+0200
+
doxygen (1.8.1.1-1) unstable; urgency=low
* doxygen 1.8.1.1 (bug fix) release.
diff -Nru doxygen-1.8.1.1/debian/patches/fix_676423_segfault.patch
doxygen-1.8.1.1/debian/patches/fix_676423_segfault.patch
--- doxygen-1.8.1.1/debian/patches/fix_676423_segfault.patch1970-01-01
01:00:00.0 +0100
+++ doxygen-1.8.1.1/debian/patches/fix_676423_segfault.patch2012-07-05
17:52:45.0 +0200
@@ -0,0 +1,23 @@
+Description: fix for 676423: new segmentation faults in version 1.8.1-1
+ removeEmptyLines() segfaults on empty string
+Author: Thibaut Paumard paum...@users.sourceforge.net
+Origin: vendor
+Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676423
+Forwarded: no
+Last-Update: 2012-07-05
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/htmlgen.cpp
b/src/htmlgen.cpp
+@@ -936,6 +936,11 @@
+ static QCString removeEmptyLines(const QCString s)
+ {
+ BufStr out(s.length()+1);
++ if (s.length()==0)
++ {
++out.addChar('\0');
++return out.data();
++ }
+ char *p=s.data();
+ char c;
+ while ((c=*p++))
diff -Nru doxygen-1.8.1.1/debian/patches/series
doxygen-1.8.1.1/debian/patches/series
--- doxygen-1.8.1.1/debian/patches/series 2011-12-12 15:57:06.0
+0100
+++ doxygen-1.8.1.1/debian/patches/series 2012-07-05 17:48:23.0
+0200
@@ -5,3 +5,4 @@
gcc-g.diff
doxygen-jquery.patch
#dot_num_threads.diff
+fix_676423_segfault.patch
signature.asc
Description: OpenPGP digital signature
Bug#676423: doxygen: new segmentation faults in version 1.8.1-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Matthias, I see that you have included my patch in an upload together with a lot of other fixes, including a new upstream and I thank you for that. However, that certainly means that your new upload will not reach Wheezy. What is your plan to fix this bug in Wheezy? Is that fine for you if I upload an NMU (1.8.1-1+nmu1) to testing-proposed-updates? Kind regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJQCw7xAAoJEJOUU0jg3ChAfUgQAMfELzlnXjcTUKptiYOP3zmn qRKFnw2onlXGSugvRoVpyBIEObecikfvZtocwR0lNpLR8s2fKoZ6NeXxFmkEdPew 9yNX3vkY+v/Ic0YXsS0n75k1usu9GzCYk5XapDsJWE0tPy03I74wDW0eWBg0R4xf iTMGQm8AltqUw29uL8032DPNNOWDbsnP6MQoBCZLIkHadiy+r5hvz7mC8cF25pwR vNfAeZIvGeEmMaKtqYaA45qtLpK2FDhDwrlzJIQ9xjX1+I9AiYZ9klcR02yBDYyJ 9yCGLVM3aGpssdGWbv4t9ixt4tzE7TSYXL3lI3ZGaTd7msVETqSz4jMQd8VfOm3M 9im6ujZCVwAlwulbiU6DrL8kjJIhjaSuOrE2c6oeg0CtZEKx+MDwj1ongWqKStvP 5TLUrn9an0bEuR9kF4dEuEE23wsSBdPOf1nzlfvurtWm+NuA7qRYdhUwE5U9wjp3 iUvBMShvLZg50GFI6HbaUG8T6ZEtfzeDFUiXXUdGMerxphv1yc9cy0peWCDwCFJt iZAdu5vkZ4tiq3GtGGIxh/wGiHmO+8hIi80buDzEum4zScgm9nlFY3iy0hz8wZ3G sqPm6UGTlUp1xu0dpueIpZYZxO+WbDfBbeIc8J//wmmXSQRwh+ExYFXLdKo5GeZj KkCV7QQCNMVqWFakjwX1 =hYrx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681452: gyoto FTBFS on mips (only on some buildds, test suite)
Source: gyoto Version: 0.0.3-1 Severity: serious Justification: fails to build from source (but built successfully in the past) The test suite hangs [lucatelli] and [corelli] but runs fine on [ball], in qemu and on gabrielli. [lucatelli] https://buildd.debian.org/status/fetch.php?pkg=gyotoarch=mipsver=0.0.3-4stamp=1342069240 [corelli] https://buildd.debian.org/status/fetch.php?pkg=gyotoarch=mipsver=0.0.3-3stamp=1342043550 [ball] https://buildd.debian.org/status/fetch.php?pkg=gyotoarch=mipsver=0.0.3-1stamp=1341173189 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676423: doxygen: new segmentation faults in version 1.8.1-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Matthias, unless you object, I intend on NMUing this fix to unstable on Monday, Jul. 16th. Kind regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJP++gIAAoJEJOUU0jg3ChA/bYP/jMFnq+5gOykcCBWk3muOuGt HWgrVZx70NWttV6ATFn2g8NpXKUTTlDsQ7VuGK0gpsTiu/H4goir2CqtCTwoiAmf DBHjAR5f3fCA3Of6plcCDUPriyY8IqoiJ5RWO7EsgLW4CF+icrWuibNzI/Vsy8Zd +yoYSpXL/gRKve7Ye636iRelufa2U0N1UuKlZZYUpqPJE0JF06LvXCEXYKrLDZnT jDW3rZPcs2G9+9Fj9jyy+hPg7ICTNDat0drAa8Kr5ZSPbdSWUkL5JMp3Dk0Xax7K T+ODs9wMNMSsuVsCSLY+8i+RCPb1dy/kt5BUS8fseXsF8l6JKBcN/Jk+qTMBTQ57 Qkic/uWftFjblWZ1+Aso7S86yc/Oa8NtKsRacbCOBXoqC/rbnlNuKBoQSdlcDaR5 AIMlWi9+Z+5/ZXu5Xh9MjAaEAXcZf5X/NBczKridMc7mMTA0Z7nh+NXF6J8xrAV8 5qMmJNFbd+bsIQegeR3zYC9idJdCaQBkDR2ojW+v4u/6V25FsGQSLzFNY5gosl41 cfYqlZ++tNSLvboF2ft90AxUhKu1ih3szMmCsHGgoZxiaLHHt2dCr5pZ3SMmPGwP +T4tUULpYU2xkN11N2t15Pd/5PPg+rmnKL1UXdjRPPFYn1I76AWYNfbEVzoVn7Lj NDPDMpFIcC1ReHyPM1yt =v1+a -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659061: brasero: segfaults when creating a subfolder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 package brasero tags 659061 +patch thanks Hi, I confirm that the bug is still present in 3.4.1-2 and that the patch solves it. The patch is a very clear 1-line addition and applies cleanly on top of 3.4.1. Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJP9YiIAAoJEJOUU0jg3ChAM9QP/0ERZj3xmELjvK+kavaJGGzc UA0NZW+i0a0llqW/a2KEprf4YsU+17gQAHe/Tk3BRaGIx+yA8RPe9SHgXSgsYO3u g63m+y2Zx2ExG8nUw2UE5fRgyfhXn8SjKHS8bekCK8qeFvZBT2PFLsgHH+c9n68N ZQWKIqcMkvocviavRT8gECYiI7cGIArzpfCtYuXe6xcjNUpZ15LPAnIQxbTEgIYA 4oqqylsHMrgkh8QvnlIMvIY5wee5B4YxTf7ZQZf7RSX6Kq6Bo/cvLH+8uTuoQH1h p1Wh55NA1EUoeUS8v436ouCo9GkVOvLR38NuMjRDwqqd4eSsAyURLGNBZAhTRQU0 f9WKD6VDOKZ2I9abA2D/hV+Jyr5Cj4V8teULy+4jAOlnBfAcimSgzo1Ywup7M+Qw 8cGOYdw7qJEQtubr6IJJzv23yDs42GK7y+LMsfEpw7cTnVO8TDa4vY4XxfG86WbV 2r8G6PtycYDuJUcSmdLCUm6/S5aZYmYnYJ10g0BuxEHRC/VSiepiRyP5IzU1I566 3+ucIt2dbXurhNp5RL0bUFwr/+BgvWVkzcSNKBvY9bGH1/ovPjO0t5DxR0NjOSmb wXVQXkxcllSTOnPUZ6/c/c3jm+216Z1rajDPJgykpKov94ZMPBGkHtIR0RlcQNvd tQCIr9HU6mcSxZrqdnAz =BYkP -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676423: doxygen: new segmentation faults in version 1.8.1-1
package doxygen
tags 676423 + patch
thanks
Hi,
removeEmptyLines() segfaults on empty string.
Here comes a patch.
Regards, Thibaut.
Description: fix for 676423: new segmentation faults in version 1.8.1-1
removeEmptyLines() segfaults on empty string
Author: Thibaut Paumard paum...@users.sourceforge.net
Origin: vendor
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676423
Forwarded: no
Last-Update: 2012-07-05
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/src/htmlgen.cpp
+++ b/src/htmlgen.cpp
@@ -936,6 +936,11 @@
static QCString removeEmptyLines(const QCString s)
{
BufStr out(s.length()+1);
+ if (s.length()==0)
+ {
+out.addChar('\0');
+return out.data();
+ }
char *p=s.data();
char c;
while ((c=*p++))
signature.asc
Description: OpenPGP digital signature
Bug#659061: brasero: segfaults when creating a subfolder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 package brasero tags 659061 + upstream thanks Le 05/07/12 16:20, Josselin Mouette a écrit : Le jeudi 05 juillet 2012 à 14:28 +0200, Thibaut Paumard a écrit : I confirm that the bug is still present in 3.4.1-2 and that the patch solves it. The patch is a very clear 1-line addition and applies cleanly on top of 3.4.1. Can you forward it upstream on bugzilla.gnome.org? Thanks, Done: https://bugzilla.gnome.org/show_bug.cgi?id=679460 Regards, Thibaut. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJP9bvBAAoJEJOUU0jg3ChAunkQAMt3KfPgiqZLPzUH8YRfg26x hOapthVI2w7bfjuvBFk1WUjCKqdIVwOdlcoiU82x8VeJTnyc/kVCBZdMhs73jlm6 wVbq81Z+qyEy35ErXN+dd31Z6oBU//UBOEWtxZ5Wg6CmuiG6z5LYDAhGetmw1SEe 96Pg0beHRz4OpSIQ456tLZ06zaI0L6FTMzEqRxX0Lmux1zx4DLYW/0zROsvW4hN0 eIbGbNUr+2SI2A+PL8FmJZ9vHwEWd2MrWPEyoZnKIbYz9lJiKhP3zRJUAlXllHvL 5HpGaiqOxpE7VXL/6pux+ZmoQsfkcfysg1SZt2ru43YQun8/+CxpYpaV2BuZEXG9 /vSDnxAS5C8fZXakRgbJZust4SjQUNE1Qmy++RBeurseZ1xWrVlbkKrtJSjdjO/u WfvCnH2nzDV80FNcWIV/EtgmLipOz3rxwkskbNlZWAGD42jq3j09mKwwYnBfhfkp 7ynrzWDsYXDi+CHaqs9PaFiTOt3aS4ifRPdQqb4Q3pCxht0JR1r1tjqNwkWfcMxt mzN7F/OYeZ+jZwkrqZVRIvHOv4ROVQ01BYlnOhCpsmfZ92b0FBqnzKlPqw3M2vdr apF0gJc7eM5YgXrOdsm/uhM1oTUSVi3HKqT43QODwMHXXV/AW/VcfvGeZmaG8SzR yItwBqvGUf5w5Bcebdbd =u3PA -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680184: lsb-release appears to be uninstallable on mips, causes FTBFS
Package: lsb-release Version: 4.1+Debian7 Severity: critical Version: 4.1+Debian7 Hi, python2.7 is in the BD-uninstalable state since 2 days apparently because the buildd sees lsb-release as uninstallable: Dependency installability problem for python2.7 on mips: python2.7 (= 2.7.3-1) build-depends on one of: - lsb-release (= 4.1+Debian7) https://buildd.debian.org/status/package.php?p=python2.7suite=sid I am of course not sure whether the problem lies actually within the lsb- release package. python2.7 seems to have failed building on mips previously anyway. Kind regards, Thibaut. -- Package-specific info: lsb_release output -*- -*- -*- -*- -*- Distributor ID: Debian Description:Debian GNU/Linux unstable (sid) Release:unstable Codename: sid -*- -*- -*- -*- -*- Apt policy -*- -*- -*- -*- -*- Package files: 100 /var/lib/dpkg/status release a=now 1 file:/home/thibaut/y-wing/debian/ unstable/non-free i386 Packages release n=unstable,c=non-free 1 file:/home/thibaut/y-wing/debian/ unstable/contrib i386 Packages release n=unstable,c=contrib 1 file:/home/thibaut/y-wing/debian/ unstable/main i386 Packages release n=unstable,c=main 500 http://ftp2.fr.debian.org/debian/ unstable/non-free Translation-en 500 http://ftp2.fr.debian.org/debian/ unstable/main Translation-fr 500 http://ftp2.fr.debian.org/debian/ unstable/main Translation-en 500 http://ftp2.fr.debian.org/debian/ unstable/contrib Translation-en 500 http://ftp2.fr.debian.org/debian/ unstable/non-free i386 Packages release o=Debian,a=unstable,n=sid,l=Debian,c=non-free origin ftp2.fr.debian.org 500 http://ftp2.fr.debian.org/debian/ unstable/contrib i386 Packages release o=Debian,a=unstable,n=sid,l=Debian,c=contrib origin ftp2.fr.debian.org 500 http://ftp2.fr.debian.org/debian/ unstable/main i386 Packages release o=Debian,a=unstable,n=sid,l=Debian,c=main origin ftp2.fr.debian.org Pinned packages: -*- -*- -*- -*- -*- sources.list -*- -*- -*- -*- -*- deb http://ftp2.fr.debian.org/debian/ unstable main contrib non-free deb-src http://ftp2.fr.debian.org/debian/ unstable main contrib non-free deb file:/home/thibaut/y-wing/debian/ unstable main contrib non-free deb-src file:/home/thibaut/y-wing/debian/ unstable main contrib non-free -*- -*- -*- -*- -*- /etc/lsb_release -*- -*- -*- -*- -*- - none -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lsb-release depends on: ii python 2.7.3~rc2-1 ii python2.6 2.6.8-0.1 ii python2.7 2.7.3-1 Versions of packages lsb-release recommends: ii apt 0.9.7 Versions of packages lsb-release suggests: pn lsb none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680190: python2.7 FTBFS on mips
Source: python2.7 Version: 2.7.3-1 Severity: serious Justification: fails to build from source (but built successfully in the past) Hi, pyhton2.7 does not build on mips: https://buildd.debian.org/status/package.php?p=python2.7 It is currently in the BD-Uninstallable state due to http://bugs.debian.org/680184 but its build was attempted and failed previously: https://buildd.debian.org/status/logs.php?pkg=python2.7ver=2.7.3-1arch=mips Unfortunately, this puts other packages in the BD-Uninstallable state on mips and blocks testing migrations. Regards, Thibaut. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620802: trilinos: fixed in 10.4.0.dfsg-1
package python-pytrilinos notfixed 620802 python-pitrilinos/10.4.0+dfsg notfixed 620802 trilinos/10.4.0+dfsg-1 fixed 620802 trilinos/10.4.0.dfsg-1 thanks At some point I'll get the tagging right I don't now in the bug should be fixed in stable or if it's OK to leave it like that since workarounds exist and it's fixed in unstable. Regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#620802: python-pytrilinos: fails to work
Package: python-pytrilinos Followup-For: Bug #620802 Attached is a test file which triggers the bug on 10.0.4 but not on 10.4.0 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.0.0-1-686-pae (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-pytrilinos depends on: ii libatlas3gf-base [liblapack.so.3gf] 3.8.4-3 ii libblas3gf [libblas.so.3gf] 1.2.20110419-2 ii libc62.13-21 ii libgcc1 1:4.6.1-13 ii liblapack3gf [liblapack.so.3gf] 3.3.1-1 ii libopenmpi1.31.4.3-2.1 ii libstdc++6 4.6.1-13 ii libtrilinos 10.4.0.dfsg-1 ii python 2.6.7-3 ii python-central 0.6.17 ii python-numpy 1:1.5.1-2+b1 ii python2.62.6.7-4 python-pytrilinos recommends no packages. python-pytrilinos suggests no packages. -- no debconf information #! /usr/bin/env python # # PyTrilinosExample.py (SAND Number: 2010-7675 C) - An example python script # that demonstrates the use of PyTrilinos to solve a simple 2D Laplace problem # on the unit square with Dirichlet boundary conditions, capable of parallel # execution. # # Author: Bill Spotz, Sandia National Laboratories, wfsp...@sandia.gov # # Python module imports import numpy import optparse from math import pi from PyTrilinos import Epetra, AztecOO # If pylab (a plotting package) is not installed, then pylab gets assigned to # None, making it appropriate as a conditional on whether or not to plot the # results. try: import pylab except ImportError: pylab = None ### class Laplace2D: Class Laplace2D is designed to solve u_xx + u_yy = 0 on the unit square with Dirichlet boundary conditions using standard central differencing. It can be solved in parallel with 1D domain decomposition along lines of constant y. The constructor takes an Epetra.Comm to describe the parallel environment; two integers representing the global number of points in the x and y directions, and four functions that compute the Dirichlet boundary conditions along the four boundaries. Each function takes a single argument, which is a 1D array of coordinates and returns an array of the corresponding BC values. def __init__(self, comm, nx, ny, bcx0, bcx1, bcy0, bcy1, params=None): self.__comm = comm self.__nx = nx self.__ny = ny self.__bcx0 = bcx0 self.__bcx1 = bcx1 self.__bcy0 = bcy0 self.__bcy1 = bcy1 self.__params = None self.__rhs = False self.__yMap = Epetra.Map(self.__ny, 0, self.__comm) self.constructRowMap() self.constructCoords() self.constructMatrix() self.constructRHS() self.setParameters(params) def constructRowMap(self): yElem = self.__yMap.MyGlobalElements() elements = range(yElem[0]*self.__nx, (yElem[-1]+1)*self.__nx) elements = range(yElem[0]*self.__nx, (yElem[-1]+1)*self.__nx) self.__rowMap = Epetra.Map(-1, elements, 0, self.__comm) def constructCoords(self): self.__deltaX = 1.0 / (self.__nx - 1) self.__deltaY = 1.0 / (self.__ny - 1) # X coordinates are not distributed self.__x = numpy.arange(self.__nx) * self.__deltaX # Y coordinates are distributed self.__y = self.__yMap.MyGlobalElements() * self.__deltaY def constructMatrix(self): c0 = 2.0/self.__deltaX**2 + 2.0/self.__deltaY**2 c1 = -1.0/self.__deltaX**2 c2 = -1.0/self.__deltaY**2 c3 = ((self.__deltaX + self.__deltaY)/2)**2 self.__mx = Epetra.CrsMatrix(Epetra.Copy, self.__rowMap, 5) self.__scale = Epetra.Vector(self.__rowMap) self.__scale.PutScalar(1.0) for gid in self.__rowMap.MyGlobalElements(): (i,j) = self.gid2ij(gid) if (i in (0, self.__nx-1)) or (j in (0, self.__ny-1)): indices = [gid] values = [1.0] else: indices = [gid, gid-1, gid+1, gid-self.__nx, gid+self.__nx] values = [c0 , c1, c1, c2, c2] self.__scale[self.__rowMap.LID(gid)] = c3 self.__mx.InsertGlobalValues(gid, values, indices) self.__mx.FillComplete() self.__mx.LeftScale(self.__scale) def gid2ij(self, gid): i = gid % self.__nx j = gid / self.__nx return (i,j) def setParameters(self, params=None): if params is None:
Bug#537727: gimp-gap contains a convenience copy of libmpeg3
package gimp-gap severity 537727 wishlist thanks Le 13/08/10 11:17, Gerfried Fuchs a écrit : Hi! * Thibaut Paumard paum...@users.sourceforge.net [2009-07-20 16:05:32 CEST]: Package: gimp-gap Version: 2.6.0-1 Severity: serious Justification: Policy 4.13 Because you filed this bugreport as serious this bug isn't closed yet - it is still outstanding for stable and thus not archived yet. gimp-gap contains a convenience copy of libmpeg3, which it should not (Policy 4.13 bellow). [...] Furthermore, the code copy of libmpeg3 doesn't seem to be used [...] If so this bugreport rather should had been wishlist IMHO, the extern_libs directory only sums up to 2.6mb which isn't that big of a burden to really warrant repacking the upstream source, again in my humble opinion. Hi, Indeed, the convenience copy of FFMPEG in gimp-gap 2.4.0-2 is unused, so the bug severity can be decreased. I had a remaining doubt in that FFMPEG is patent encumbered and I was undecided whether of not it was OK to ship it unstripped. As it seems, the ffmpeg source package is now distributed unstripped in debian. The ffmpeg-debian package from stable was crippled to prevent using the patent-covered bits, but those bits were still present. I conclusion: I think it is wise to strip the gimp-gap package to keep problems located in a single package. However, at the moment, it doesn't seem necessary to take action to remove the unused patent-covered code shipped in gimp-gap 2.4 from the archive. Severity reduced. Regards, Thibaut. signature.asc Description: OpenPGP digital signature
Bug#537725: severity should be wishlist
package gimp-gap severity 537725 wishlist thanks Hi, the convenience copy is not used in 2.4.0, so the package actually doesn't infringe policy. T. signature.asc Description: OpenPGP digital signature
Bug#537725: [ping] Re: RFS: gimp-gap (FTBFS, 2 other serious bugs)
Hi,
I have not received any answer to this message, I'd be very happy if
someone volunteered...
(TODO list added below)
Le 7 août 09 à 10:45, Thibaut Paumard a écrit :
Dear mentors,
I have prepared a new upload of my package gimp-gap. I would be
grateful if someone would upload it for me (I'm a DM but this
package doesn't have the Dm-Upload-Allowed field yet). It fixes
serious bugs:
- FTBFS on ia64;
- inclusion of external libraries, including patent-problematic
ffmpeg.
To get the source package:
dget
http://www.lesia.obspm.fr/perso/thibaut-paumard/debian/pool/main/g/gimp-gap/gimp-gap_2.6.0+dfsg-1.dsc
Complete changelog:
* Remove convenience copies of external libraries libmpeg3
(Closes: #537727) and ffmpeg (Closes: #537725).
* Bug fix: implicit pointer conversions, thanks to dann frazier
(Closes: #536528).
* add ${misc:Depends} in the dependencies (lintian warning).
* set debhelper compatibility level to 7 (lintian warning).
* Changed all -1 dependencies to -1~ to make backporting easier
(suggested by lintian).
* mangle version in watch file (suggested by lintian).
Best regards, Thibaut.
TODO:
For the next upload, I am working on getting gimp-gap to compile
nicely against debian's ffmpeg. I have a working version, but I
still require to ship 10 files from ffmpeg in the source package (a
100-fold improvement compared to shipping all of ffmpeg, and this
solves the patent problem).
As soon as the latest version of libmpeg3 is available, I will enable
it.
Regards, Thibaut.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537725: RFS: gimp-gap (FTBFS, 2 other serious bugs)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear mentors,
I have prepared a new upload of my package gimp-gap. I would be
grateful if someone would upload it for me (I'm a DM but this package
doesn't have the Dm-Upload-Allowed field yet). It fixes serious bugs:
- FTBFS on ia64;
- inclusion of external libraries, including patent-problematic
ffmpeg.
To get the source package:
dget
http://www.lesia.obspm.fr/perso/thibaut-paumard/debian/pool/main/g/gimp-gap/gimp-gap_2.6.0+dfsg-1.dsc
Complete changelog:
* Remove convenience copies of external libraries libmpeg3
(Closes: #537727) and ffmpeg (Closes: #537725).
* Bug fix: implicit pointer conversions, thanks to dann frazier
(Closes: #536528).
* add ${misc:Depends} in the dependencies (lintian warning).
* set debhelper compatibility level to 7 (lintian warning).
* Changed all -1 dependencies to -1~ to make backporting easier
(suggested by lintian).
* mangle version in watch file (suggested by lintian).
Best regards, Thibaut.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkp76ZEACgkQ+37NkUuUiPFnLgCfZaIuCtieRfMTc5GEONASc2iF
pfoAn1Wj7V/KRmqS7T9x6bxyHHolAma3
=pFqM
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536528: gimp-gap: implicit pointer conversions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 package gimp-gap tags 536528 pending thanks OK, I'm applying the patch in the next upload. T. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkp65gEACgkQ+37NkUuUiPHHTgCeJubXV7meeuW05zeJhFCQjuU7 TIcAoIXFlLtxMTs+aT131p9zkIJOQIv0 =qEmw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537725: gimp-gap contains a convenience copy of ffmpeg
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: gimp-gap Version: 2.6.0-1 Severity: serious Justification: Policy 4.13 Hi, gimp-gap contains a convenience copy of ffmpeg, which it should not (Policy 4.13 bellow). In addition, ffmpeg poses serious legal problems, best let them in a single package. Please remove the offending code from the source tarball. Regards, Thibaut. Policy v. 3.8.2.0: 4.13 Convenience copies of code Some software packages include in their distribution convenience copies of code from other software packages, generally so that users compiling from source don't have to download multiple packages. Debian packages should not make use of these convenience copies unless the included package is explicitly intended to be used in this way. If the included code is already in the Debian archive in the form of a library, the Debian packaging should ensure that binary packages reference the libraries already in Debian and the convenience copy is not used. If the included code is not already in Debian, it should be packaged separately as a prerequisite if possible. - -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gimp-gap depends on: ii gimp 2.6.6-1+b1The GNU Image Manipulation Program ii libatk1.0-01.26.0-1 The ATK accessibility toolkit ii libc6 2.9-18GNU C Library: Shared libraries ii libcairo2 1.8.8-2 The Cairo 2D vector graphics libra ii libfontconfig1 2.6.0-4 generic font configuration library ii libfreetype6 2.3.9-5 FreeType 2 font engine, shared lib ii libgimp2.0 2.6.6-1+b1Libraries for the GNU Image Manipu ii libglib2.0-0 2.20.4-1 The GLib library of C routines ii libgtk2.0-02.16.4-1 The GTK+ graphical user interface ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libpango1.0-0 1.24.3-1 Layout and rendering of internatio ii libpng12-0 1.2.37-1 PNG library - runtime ii zlib1g 1:1.2.3.3.dfsg-14 compression library - runtime gimp-gap recommends no packages. Versions of packages gimp-gap suggests: pn mplayer none (no description available) - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkpkeMEACgkQ+37NkUuUiPFtigCcC5hUQqKTOkb5hBMRiFMd7pUG 3VwAn1/LRBM70SVNpHPtAf//MBB7YbSt =RXv0 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537727: gimp-gap contains a convenience copy of libmpeg3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: gimp-gap Version: 2.6.0-1 Severity: serious Justification: Policy 4.13 Hi, gimp-gap contains a convenience copy of libmpeg3, which it should not (Policy 4.13 bellow). Please remove the offending code from the source tarball. (Of course, you need to wait for libmpeg3 to be upgraded, it seems some lobbying would be useful for that: see #430770). Regards, Thibaut. Policy v. 3.8.2.0: 4.13 Convenience copies of code Some software packages include in their distribution convenience copies of code from other software packages, generally so that users compiling from source don't have to download multiple packages. Debian packages should not make use of these convenience copies unless the included package is explicitly intended to be used in this way. If the included code is already in the Debian archive in the form of a library, the Debian packaging should ensure that binary packages reference the libraries already in Debian and the convenience copy is not used. If the included code is not already in Debian, it should be packaged separately as a prerequisite if possible. - -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gimp-gap depends on: ii gimp 2.6.6-1+b1The GNU Image Manipulation Program ii libatk1.0-01.26.0-1 The ATK accessibility toolkit ii libc6 2.9-18GNU C Library: Shared libraries ii libcairo2 1.8.8-2 The Cairo 2D vector graphics libra ii libfontconfig1 2.6.0-4 generic font configuration library ii libfreetype6 2.3.9-5 FreeType 2 font engine, shared lib ii libgimp2.0 2.6.6-1+b1Libraries for the GNU Image Manipu ii libglib2.0-0 2.20.4-1 The GLib library of C routines ii libgtk2.0-02.16.4-1 The GTK+ graphical user interface ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libpango1.0-0 1.24.3-1 Layout and rendering of internatio ii libpng12-0 1.2.37-1 PNG library - runtime ii zlib1g 1:1.2.3.3.dfsg-14 compression library - runtime gimp-gap recommends no packages. Versions of packages gimp-gap suggests: pn mplayer none (no description available) - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkpkeawACgkQ+37NkUuUiPFWTQCfdxrM4Byir7O/l/t1gBI9I91M WVQAn0W8yREbehrt5ZqNqBDpjVTW09oc =oTFM -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527677: gimp-gap: FTBFS: gap_dbbrowser_utils.c:160: error: conflicting types for 'gimp_proc_view_new'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 package gimp-gap block 527677 by 430770 thanks Hi, I want to upload the new upstream (2.6). To do that properly, I must wait for libmpeg3 to be upgraded to 1.8. I'll see to it that it happens. T. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkouVHAACgkQ+37NkUuUiPHEcwCfTzVsC/LgHto3vSln5HYoAKUa YMwAmwbFA2Thk9TJQ8tUPiRwwbujZZOt =XY/p -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506297: yorick-ml4 is not 64bit-safe
Package: yorick-ml4 Version: 0.5.1-2 Severity: grave Justification: renders package unusable The package is completely broken under amd64. ml4write never returns, ml4read segfaults... In ml4.c, the info array at the beginning of each ml4 variable must be of type int, not long. I'm working on a fix. Regards, Thibaut. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25.9 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages yorick-ml4 depends on: ii libc6 2.7-16GNU C Library: Shared libraries ii yorick 2.1.05+dfsg-6 interpreted language and scientifi yorick-ml4 recommends no packages. yorick-ml4 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506334: yorick-curses is not 64bit-safe
Package: yorick-curses Version: 0.1-2 Severity: grave Justification: renders package unusable yorick-curses just won't work on amd64 (segfaults). I'm working on a fix. Regards, Thibaut. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.25.9 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages yorick-ml4 depends on: ii libc6 2.7-16GNU C Library: Shared libraries ii libncurses5 5.6+20080907-1 shared libraries for terminal hand ii yorick 2.1.05+dfsg-6 interpreted language and scientifi yorick-curses recommends no packages. yorick-curses suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499915: FTBFS with dpkg-buildpackage -rsudo
Package: yorick-gl Version: 1.1+cvs20070922+dfsg-1 Severity: grave Justification: renders package unusable The clean target requires the configure one, but leaves the file configure-stamp behind. This file ends up belonging to root when dpkg- buildpackage -rsudo is used. The next run of the configure target, which is not run as root, fails. I'm fixing this right away. T. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages yorick-gl depends on: ii libc6 2.7-13GNU C Library: Shared libraries ii libgl1-mesa-glx [libgl1] 7.0.3-5 A free implementation of the OpenG ii libx11-6 2:1.1.4-2 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii yorick 2.1.05+dfsg-6 interpreted language and scientifi yorick-gl recommends no packages. yorick-gl suggests no packages. -- no debconf information PGP.sig Description: Ceci est une signature électronique PGP
Bug#498503: missing build-dependency on libxext-dev
Package: yorick-gl Version: 1.1+cvs20070922-3 Severity: grave Justification: renders package unusable Tags: pending yorick-gl lacks a build-dependency on libxext-dev. As a result, most of its features are disabled by the configure script on clean builders (where libxext-dev is not already installed). Currently, the binary package is fine on i386 but close to useless on amd64 and powerpc (the two other archs on which yorick-gl was ever built). I am going to upload a fixed revision right away. Thibaut. -- 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/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages yorick-gl depends on: ii libc6 2.7-13GNU C Library: Shared libraries ii libgl1-mesa-glx [libgl1] 7.0.3-5 A free implementation of the OpenG ii libx11-6 2:1.1.4-2 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii yorick 2.1.05+dfsg-6 interpreted language and scientifi yorick-gl recommends no packages. yorick-gl suggests no packages. -- no debconf information PGP.sig Description: Ceci est une signature électronique PGP
Bug#487673: won't start: Error: could not find a distribution template
Package: software-properties-gtk Version: 0.60.debian-1.1 Severity: grave Justification: renders package unusable Hi, I just upgraded my system. Just before upgrading, software- properties-gtk used to work fine. Right after, clicking the menu item does nothing and launching it on the command line yields: /usr/lib/python2.5/site-packages/apt/__init__.py:18: FutureWarning: apt API not stable yet warnings.warn(apt API not stable yet, FutureWarning) Traceback (most recent call last): File /usr/bin/software-properties-gtk, line 100, in module app = SoftwarePropertiesGtk(datadir=data_dir, options=options, file=file) File /var/lib/python-support/python2.5/softwareproperties/gtk/ SoftwarePropertiesGtk.py, line 75, in __init__ SoftwareProperties.__init__(self, options=options, datadir=datadir) File /var/lib/python-support/python2.5/softwareproperties/ SoftwareProperties.py, line 55, in __init__ self.reload_sourceslist() File /var/lib/python-support/python2.5/softwareproperties/ SoftwareProperties.py, line 450, in reload_sourceslist self.distro.get_sources(self.sourceslist) File /usr/lib/python2.5/site-packages/aptsources/distro.py, line 85, in get_sources Error: could not find a distribution template) aptsources.distro.NoDistroTemplateException -- 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/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages software-properties-gtk depends on: ii gksu 2.0.0-5 graphical frontend to su ii python 2.5.2-1 An interactive high- level object-o ii python-glade22.12.1-6GTK+ bindings: Glade support ii python-gtk2 2.12.1-6Python bindings for the GTK+ widge ii python-software-properti 0.60.debian-1.1 manage the repositories that you i ii python-support 0.8.2 automated rebuilding support for P ii synaptic 0.62.1 Graphical package manager software-properties-gtk recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451459: New maintainer for update-manager needs help
Hi, I [1]volunteered last week to help maintaining update-manager and update-notifier, with the immediate goal of fixing the [2]RC bug that kicked them out of Lenny. I would be grateful if I could be added to the pkg-gnome alioth team, in order to be able to commit directly my work there. In the meantime, I have a NMU package ready, but I need help to get it into the archive: as a DM, I can't upload a package for which I have not been approved. Therefore, I would be grateful if someone could review and upload the source package available here: dget http://www.lesia.obspm.fr/~paumard/debian/pool/main/u/update- manager/update-manager_0.68.debian-4.1.dsc It fixes the only RC bug in update-manager. I've discussed the fix with Gustavo Noronha Silva, who was last in charge. I also include the corresponding svn diff. Of course, any comment on the fix or integrating the team is welcome. Best regards, Thibaut. [1] http://lists.debian.org/debian-devel/2008/06/msg00049.html [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451459 bug451459.patch Description: Binary data
Bug#451459: patch for RC bug
package update-manager tags 451459 + patch pending thanks Hi, I attach a postinst that removes the files listed in the bugreport during configure/reconfigure (indeed, whenever postinst is called). it also removes the directories in which they reside, but not higher level directories: I wonder whether we should attempt pruning these two, in case python2.4 has been removed: /usr/lib/python2.4/site-packages /usr/lib/python2.4 Should I upload this to SVN? I guess I (thibaut-guest) would need to be added to the pkg-gnome project for that. As a DM, I cannot upload the fixed package myself. I can however prepare the source package completely, just tell me whether to put myself in Uploaders and whether to set DM-Upload-Allowed (I do volunteer to check other less important bugs). Else I would add NMU to the changelog and use an NMU version number. Also, I'm guessing this is an urgency=high case? Anyway, I'm off till Monday. Don't hesitate to finish the work in the meantime ;-) Regards, Thibaut. update-manager.postinst Description: Binary data
Bug#451459: update-manager RC bug: removing obsolete files: easy fix?
Hi, It looks like this bug is the only reason why update-notifier and update-manager got removed from testing: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451459 The fix looks so obvious to me that I'm wondering whether I missed something. It looks like an old version of update-manager, which never made it into a stable release, has left .pyc files behind. The fix seems to be to remove them in postinst. It looks like we should simply remove completely these two directories: /usr/lib/python2.4/site-packages/SoftwareProperties/ /usr/lib/python2.4/site-packages/UpdateManager/ I have checked that those files belong to update-manager (but at another location, now), but I didn't find a way to make sure no other package writes in the same directories. Do you see any catch? Perhaps safer to remove each individual file as listed in the bugreport, and then the directories if they get emptied? Best regards, Thibaut. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311843: patch to dpkg
I believe (re)adding no-debsig to debian/dpkg.cfg (in package dpkg) would fix this bug. Patch attached. Regards, Thibaut. debsig-verify.diff Description: Binary data PGP.sig Description: Ceci est une signature électronique PGP
