Bug#1013981: O: gimp-gap -- animation package for the GIMP

Package: wnpp Severity: normal Control: affects -1 src:gimp-gap Hi, I intend to orphan the gimp-gap package. The package description is: The GIMP Animation Package (GAP) is a collection of plug-ins to extend the GIMP with capabilities to edit and create animations and movies as sequences of

Bug#1004777: yorick-av: FTBFS with ffmpeg 5.0

Thanks. It looks like the API has changed quite a lot since the last time I have looked this way. Is there an upgrading guide for downstream developpers or a frequent issues list I could use? Best regards, Thibaut. Le 01/02/2022 à 21:28, Sebastian Ramacher a écrit : Source: yorick-av

Bug#965917: yorick-z: diff for NMU version 1.2.0+cvs20080115-5.1

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

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?

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

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

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

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é

Bug#953437: Upstream has a proposed fix

Hi, Le 16/05/2020 à 12:36, Julien Puydt a écrit : > export sessionid=$(schroot -b -c sid) Wrong architecture, should be sid_mips64el Regards, Thibaut signature.asc Description: OpenPGP digital signature

Bug#953437: Upstream has a proposed fix

Le 15/05/2020 à 11:07, Julien Puydt a écrit : > It should, but since I haven't been able to reproduce your problem on > eller.debian.org... > Interesting. I just re-compiled my test-case in a fresh chroot on eller, and it still segfaults. The base system is sid-mips64el. Regards, Thibaut.

Bug#953437: Upstream has a proposed fix

Hi Julien, Thanks for looking into this. Le 14/05/2020 à 21:43, Julien Puydt a écrit : > Hi, > > upstream has tried to provide a fix for your problem on their latest > trunk branch : would you be able to give it a try? > > Thanks, Well, I certainly can try, but wouldn't it be easier for you

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

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 pack

Bug#953437: libflint-arb2: acb_hypgeom_2f1 segfaults on mips64el for certain inputs

Package: libflint-arb2 Version: 1:2.17.0-1 Severity: normal Dear Maintainer, acb_hypgeom_2f1 segfaults on mips64el for certain inputs. This triggered a FTBFS through the test-suite of Gyoto: https://buildd.debian.org/status/fetch.php?pkg=gyoto=mips64el=1.4.3-2=1582934308=0 which was passing

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*.

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

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

Bug#944769: python3-h5py fails to import if offline due to apparent MPI failure

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: >>

Bug#944769: python3-h5py fails to import if offline due to apparent MPI failure

epends 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 - S

Bug#944769: python3-h5py fails to import if offline due to apparent MPI failure

Hi Drew, Le 27/01/2020 à 05:40, Drew Parsons a écrit : > from os import getenv as os_getenv > OPENMPI_MULTIPROC = os_getenv('OMPI_COMM_WORLD_SIZE') and > int(os_getenv('OMPI_COMM_WORLD_SIZE')) > 1 > MPICH_MULTIPROC = os_getenv('MPI_LOCALNRANKS') and > int(os_getenv('MPI_LOCALNRANKS'))>1 >

Bug#946986: python3-h5py: h5py does not play nicely with subprocess and mpirun

Hi, Le 24/01/2020 à 13:17, Rafael Laboissière a écrit : >>> I'm not sure subprocess is involved at all, it may be that MPI_Init() >>> simply dies because h5py has already called it earlier. >>> >> >> That sounds plausible. > > I am not sure this would be an explanation for the problem. > > At

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#946986: python3-h5py: h5py does not play nicely with subprocess and mpirun

Hi, Le 22/01/2020 à 16:49, Drew Parsons a écrit : > Might be worth bringing to the attention of the subprocess developers. I > figure they'll either be interested to know about the problem or will > have a simple explanation. I'm not sure subprocess is involved at all, it may be that MPI_Init()

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 r

Bug#944769: python3-h5py fails to import if offline due to apparent MPI failure

Le 15/11/2019 à 11:21, Thibaut Paumard a écrit : > There are ways to detect whether a job is running under MPI (at least as > far as OpenMPI is concerned, I did not find the equivalent for MPICH). > > What I do in my own code is checking for the environment variable > OMPI_

Bug#944769: python3-h5py fails to import if offline due to apparent MPI failure

Dear Jamie, Le 15/11/2019 à 09:48, Jameson Graef Rollins a écrit : > > I'm sorry, but I strongly disagree. This situation is not artificial in > any way. This bug was triggered by the default configuration on my > laptop when my primary network interface was down, a very common > situation.

Bug#942106: Adding Python 3.8 as a supported Python3 version

Le 07/11/2019 à 15:08, Matthias Klose a écrit : > [1] https://wiki.debian.org/Python/Python3.8. Thanks Matthias. I've added the following point to "common upstream issues": * Embedding Python: modules are not linked with libpython3.8 anymore, but programs that embed Python still need to link

Bug#944192: python3-h5py: 'import h5py' produces Open MPI message to stderr

Dear Jamie, Le 06/11/2019 à 19:15, Jameson Graef Rollins a écrit : > On Wed, Nov 06 2019, Thibaut Paumard wrote: >> I believe: >> - the issue is not very serious, as it will not prevent your code from >> running fine and efficiently (it's only an informative mes

Bug#944192: python3-h5py: 'import h5py' produces Open MPI message to stderr

Le 06/11/2019 à 00:41, Jameson Graef Rollins a écrit : > FYI downgrading to 2.8.0-3 from stable make the message go away, so it > appears to actually be something in the newer 2.10.0 release. > > Thanks. > > jamie. > Dear Jamie, I believe: - the issue is not very serious, as it will not

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

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

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. > >

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 t

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

Bug#890889: stretch-pu: package yorick-av/0.0.4-1

Le 09/03/2019 à 17:25, Adam D. Barratt a écrit : > Ping? If nothing happens with the next couple of weeks then I plan on > closing this bug. > Thanks for the heads up. I can't believe I missed your mail for so long. Uploaded. Kind regards, Thibaut. signature.asc Description: OpenPGP

Bug#919272: Is multiple-layers of alternatives a good thing to users?

Dear Mo Zhou, Le 01/02/2019 à 05:55, Mo Zhou a écrit : > Tacking the three 32-bit variants as examples, we will have the > following alternative chain if the 3 variants were made co-installable: > > Package: libblis2-openmp, Provides: libblis.so.2 > Package: libblis2-pthread, Provides:

Bug#918796: ITP: yorick-full -- full installation of the Yorick interpreter and add-ons

Package: wnpp Severity: wishlist Owner: Thibaut Paumard * Package name: yorick-full Version : 2.2.04+dfsg1+full Upstream Author : Thibaut Paumard * URL : http://yorick.sourceforge.net * License : GPL-2+ Programming Lang: None (metapackage) Description

Bug#918711: yorick-full makes all yorick RC buggy too easily

Source: yorick Severity: normal Hi, The yorick source package build a binary package called "yorick-full" which Depends on or Recommends most of the third-party plugins. This has the iritating consequence that each time a plug-in is RC-buggy, the entire Yorick ecosystem also become RC buggy. In

Bug#899058: ITP: domoticz -- Home automation system

Le 07/06/2018 à 19:03, Thibaut Paumard a écrit : > Strangely, this build of domoticz advertises itself as Version: 3.2112 > in http://localhost:8080/#/About, not 3.8153. Dear Federico, It turns out that the version string is determined at build-time based on the git history. We should

Bug#899058: ITP: domoticz -- Home automation system

Dear Federico, I've had some success building domoticz on buster using your git repository with some modifications (see attached patch): - in order to use Z-Wave hardware, add libopenzwave1.5-dev as a build-dependency, provide a dummy libopenzwave.pc file and set PKG_CONFIG_PATH to find it.

Bug#899605: [Pkg-mactel-devel] Bug#899658: pommed/macfanctld: Invalid maintainer address pkg-mactel-de...@lists.alioth.debian.org

will not be able to participate in the forseable future. I've seen that you have already uploaded macfanctld, can you take care also of pommed? Kind regards, Thibaut. 2018-05-26 21:01 GMT+09:00 Thibaut Paumard <thib...@debian.org>: control: severity -1 important Le 24/05/2018 à 10:38, T

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

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#899058: ITP: domoticz -- Home automation system

Dear Federico, great. Others have tried before you, you may find the state of the previous attemps on alioth in /git/debian-iot/domoticz.git/, in case that helps. Feel free to not use it, though. The debian-iot team (debian-iot-maintainers alioth list) should be interested in

Bug#885505: yorick-spydr/yorick-yao: Depends on unmaintained pygtk

Thanks, I've contacted upstream (a few months ago already). I hope they will update YAO and Yorick, else will remove them from the archive after the Buster release. Regards, Thibaut.

Bug#893726: dasher: Direct mode does not work in Wayland windows

Package: dasher Version: 5.0.0~beta~repack-6 Severity: important Tags: upstream Dear team, Now that #852699 is closed, the basic functionalities of Dasher work in a Wayland session. However, this is making use of the X11 backend. The drawback is that Direct mode only works for X11 windows (e.g.

Bug#890889: stretch-pu: package yorick-av/0.0.4-1

Control: tags -1 - moreinfo Control: thanks Le 03/03/2018 à 15:31, Adam D. Barratt a écrit : Control: tags -1 + moreinfo On Tue, 2018-02-20 at 12:01 +0100, Thibaut Paumard wrote: yorick-av has an important bug (important impact on usability, does not make the package totally useless) that I

Bug#892176: yorick-av: Need to set VBV buffer size for MPEG1/2 files

Description: Set VBV buffer size for MPEG1/2 files FFmpeg emits warnings when producing MPEG1/2 files and the VBV buffer size has not been set. The output files may then play sluggishly in VLC. This backported patch sets a VBV buffer size sufficient to hold one frame. Author: Thibaut Paumard <t

Bug#890889: stretch-pu: package yorick-av/0.0.4-1

need to be rescaled for most codecs" +(Closes: #890880). + + -- Thibaut Paumard <thib...@debian.org> Tue, 20 Feb 2018 11:37:10 +0100 + yorick-av (0.0.4-1) unstable; urgency=low * New upstream release diff --git a/debian/patches/rescale-ts b/debian/patches/rescale-ts new file mode 1006

Bug#890880: yorick-av: AVPacket timestamps need to be rescaled for most codecs

Package: yorick-av Version: 0.0.4-1 Severity: important Tags: upstream Dear self, Due to changes in the FFmpeg API, the files produced by yorick-av are essentially garbage for all but the libtheora codec. yorick-av should call av_packet_rescale_ts() before av_interleaved_write_frame(). This is

Bug#781151: boot often stalls with two "A start job is running" messages: binfmt and schroot sessions

Dear Michael, The machine on which I was seeing this bug recently died. In addition, the situation had improved and I can't remember whether I had seen the bug recently before the machine started to decay about six months ago. If I remember correctly, what did help quite a lot was to empty

Bug#859493: libgsl2: move libgslcblas.so into a separate package

Package: libgsl2 Version: 2.3+dfsg-1 Followup-For: Bug #859493 Hi, This can be fixed without a transition and such a fix would presumably be welcome by the release team as it would allow partial upgrades from jessie to stretch by allowing co-installation of libgsl0ldbl and libgsl2: - split

Bug#858612: ITP: wifiphisher -- Automated phishing attacks against Wi-Fi networks

Hi, Le 25/03/2017 à 11:44, Raphael Hertzog a écrit : > Hi, > > On Sat, 25 Mar 2017, Thibaut Paumard wrote: >> I'm not sure of the benefit for the project of shipping this, > > This is a tool that is shipped in Kali Linux, a Debian derivative and we > are trying to me

Bug#858094: no spectrum is displayed

. Le 18/03/2017 à 09:20, Thibaut Paumard a écrit : > Package: qfitsview > Version: 3.3+p1+dfsg-1+b2 > Severity: important > Tags: upstream > > Hi, > > When loading a 3D cube (e.g. from SINFONI), the spectrum sub-window is present > but empty (no axes, no spectrum). On

Bug#858094: no spectrum is displayed

Package: qfitsview Version: 3.3+p1+dfsg-1+b2 Severity: important Tags: upstream Hi, When loading a 3D cube (e.g. from SINFONI), the spectrum sub-window is present but empty (no axes, no spectrum). On the bottom left and bottom right corners are the boundaries of the spectral range. The

Bug#829188: SEGVs too frequently (~every other day)

Package: icedove Version: 1:45.6.0-2 Followup-For: Bug #829188 Me too, in 45.6.0-2 (running on stretch). I'll try upgrading to unstable's version and running through the recommended command-line. This is from a simple gdb, non-stopping on SIGPIPE, with extensions enabled (iceowl, google provider

Bug#857817: unblock: yorick-mira/1.1.0+git20170124.3bd1c3~dfsg1-2

:23.0 +0100 @@ -1,3 +1,10 @@ +yorick-mira (1.1.0+git20170124.3bd1c3~dfsg1-2) unstable; urgency=low + + * Bug fix: "ymira crashes when trying to fit several wavelengths" +(Closes: #856835). + + -- Thibaut Paumard <thib...@debian.org> Sun, 05 Mar 2017 11:43:23 +0100 + yo

Bug#857629: backportpackage: buildinfo file unknown to PPAs

Package: ubuntu-dev-tools Version: 0.157 Severity: normal File: /usr/bin/backportpackage Hi, When using backportpackage to backport and upload a Debian package to Ubuntu, the upload is rejected with such an e-mail: Rejected: Unable to identify file

Bug#856835: ymira crashes when trying to fit several wavelengths

Package: yorick-mira Version: 1.1.0+git20170124.3bd1c3~dfsg1-1 Severity: important Hi, the command-line tool ymira crashes when trying to use several wavelengths. While MiRA is still useable from within Yorick and when fitting a single wavelength, this is a severe limitation for new

Bug#852149: Re : Re: Firefox-ESR Crash in Stretch when exiting Browser with Orca running

Le 02/03/2017 à 11:26, Thibaut Paumard a écrit : > I attach a corrected patch that does apply cleanly. I am currently > building the package under stretch and will upload it to some public > space when done. > Hi, I've uploaded the patched firefox-esr, built on stretch,

Bug#856642: [firefox-esr] FTBFS with some locales when building with "debian/rules build"

Package: firefox-esr Version: 45.7.0esr-4 Severity: normal --- Please enter the report below this line. --- Hi, I tried today rebuilding firefox-esr in the context of of debugging #852149. I built with debian/rules build. My locale is set to fr_FR.utf8. The build fails during the test phase

Bug#852149: Re : Re: Firefox-ESR Crash in Stretch when exiting Browser with Orca running

Le 01/03/2017 à 23:54, Mike Hommey a écrit : > Thanks. This points to > https://bugzilla.mozilla.org/show_bug.cgi?id=1273020 > > which points to > https://hg.mozilla.org/integration/mozilla-inbound/rev/8bfdf5dfcf6bcf706fea4cda201f72ffc0c69c4a > > Can someone try to apply this patch and see how

Bug#852149: Re : Re: Firefox-ESR Crash in Stretch when exiting Browser with Orca running

ds > > > Jean-Philippe MENGUAL > > HYPRA, progressons ensemble > > Tél.: 01 84 73 06 61 > > Mail: cont...@hypra.fr > > Site Web: http://www.hypra.fr > > - Thibaut Paumard <thib...@debian.org> a écrit : >> Le 24/02/2017 à 17:35, a

Bug#855022: [gnome-shell] regularly SEGFAULTs while switching between windows with Alt-Tab

Dear maintainers, I have switched to alternative alt-tab extensions ("Alternatetab", in Debian, and [0]"Coverflow alt-tab"), and none of them seems affected by this SEGFAULT issue. [0] https://extensions.gnome.org/extension/97/coverflow-alt-tab/ Regards, Thibaut.

Bug#855022: [gnome-shell] regularly SEGFAULTs while switching between windows with Alt-Tab

Dear Maintainers, I am now able to reproduce this 100% of the time with a narrowed-down context: - external monitor attached; - icedove running; - hit Alt-Tab in such a way that the icedove drawer opens; - use the keyboard arrow keys until the SEGFAULT happens. By opening the "drawer", I mean

Bug#855022: [gnome-shell] regularly SEGFAULTs while switching between windows with Alt-Tab

Le 13/02/2017 à 13:32, Simon McVittie a écrit : > Control: tags -1 moreinfo > > On Mon, 13 Feb 2017 at 12:06:54 +0100, Thibaut Paumard wrote: >> #1 0x7f2c7679a480 in () at >> /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so > > Can you repeat this backtrace with de

Bug#855022: [gnome-shell] regularly SEGFAULTs while switching between windows with Alt-Tab

Package: gnome-shell Version: 3.22.2-4 Severity: important --- Please enter the report below this line. --- Dear GNOME maintainers, Since a couple of weeks, I experience regular crashes of GNOME shell (several times a day at work). I think it started when I upgraded to stretch. I include a

Bug#854119: ITP: node-write-pkg -- Write a package.json file in the node.js framework

Control: retitle -1 ITP: node-write-pkg -- Write a package.json Le 04/02/2017 à 11:47, Aarti Kashyap a écrit : > Package: wnpp > Severity: wishlist > Owner: Aarti Kashyap > > X-Debbugs-CC: debian-de...@lists.debian.org >

Bug#852699: dasher -- useless under GNOME (Wayland)

Le 03/02/2017 à 14:22, Samuel Thibault a écrit : > Thibaut Paumard, on Fri 03 Feb 2017 13:09:37 +0100, wrote: >> A work-around is to run dasher with GDK_BACKEND=x11: >> >> GDK_BACKEND=x11 dasher > > Perhaps we (and upstream) should do this by default for now?

Bug#852699: dasher -- useless under GNOME (Wayland)

Le 03/02/2017 à 13:09, Thibaut Paumard a écrit : > GDK_BACKEND=x11 dasher > > Then dasher mostly works. Well, direct mode only works with X11 windows.

Bug#852699: dasher -- useless under GNOME (Wayland)

Control: retitle -1 dasher -- does not work with wayland backend Dear team, Le 26/01/2017 à 15:37, Thibaut Paumard a écrit : > Dasher works well under X11 (e.g. "GNOME" or "Cinnamon" session) but > does nothing useful under the "GNOME (Wayland)" session.

Bug#852701: [dasher] "direct mode" toggle can be inverted

Package: dasher Version: 5.0.0~beta~repack-1 Severity: minor Tags: upstream --- Please enter the report below this line. --- Dear team, Starting version 5, dasher now remembers whether it was in direct mode when quitting. However the corresponding toggles are inverted if dasher is started

Bug#852699: dasher -- useless under GNOME (Wayland)

Package: dasher Version: 4.11+git20130508.adc653-3 Severity: wishlist Tags: upstream --- Please enter the report below this line. --- Dear team, Dasher works well under X11 (e.g. "GNOME" or "Cinnamon" session) but does nothing useful under the "GNOME (Wayland)" session. It looks like Dasher can

Bug#767348: dasher: Direct mode does not work (gnome3)

Control: tag -1 unreproducible Le 26/01/2017 à 12:22, Thibaut Paumard a écrit : > Le 25/01/2017 à 18:03, Matthias Urlichs a écrit : > >> However, other problems (which probably deserve their own bug report but >> I'm in a hurry): >> >> * turn on File > Direct

Bug#797891: dasher: Segfault on toggling "Control Mode" check box

t; Thanks & Bye, > > Simon > > > Am 2017-01-25 um 16:52 schrieb Thibaut Paumard: >> control: tag -1 confirmed >> >> Dear Simon, >> >> I recently adopted dasher and am now processing the backlog of bug reports. >> >> I can conf

Bug#767348: dasher: Direct mode does not work (gnome3)

Le 25/01/2017 à 18:03, Matthias Urlichs a écrit : > However, other problems (which probably deserve their own bug report but > I'm in a hurry): > > * turn on File > Direct mode. Quit Dasher. Start it again. Note that the > checkbox in the File menu is now inverted (i.e. Direct Mode is enabled >

Bug#797891: dasher: Segfault on toggling "Control Mode" check box

control: tag -1 confirmed Dear Simon, I recently adopted dasher and am now processing the backlog of bug reports. I can confirm the SEGFAULT, but only if I click repeatedly and fast on the toggle. In you experience, it the bug easy to reproduce or do you have to insist? Does the bug break some

Bug#767348: dasher: Direct mode does not work (gnome3)

control: tag -1 moreinfo control: thanks Dear Matthias, I recently adopted dasher and am processing the backlog of bug reports. I know it's been a while since you filed this report and nobody apparently reacted, but I would appreciate if you could confirm whether it is still valid:

Bug#850986: keyboard focus stays in main window when opening compose window

Control: tag -1 upstream Dear Carsten, I won't fight about the severity as I said, it's up to the maintainer in my opinion. Yet I disagree with one of your points: Le 11/01/2017 à 21:37, Carsten Schoenert a écrit : > Well, loosing a email wouldn't I call data loss in the meaning of the >

Bug#850986: keyboard focus stays in main window when opening compose window

ss [...] which looks appropriate since : > On Wed, Jan 11, 2017 at 08:08:47PM +0100, Thibaut Paumard wrote: >> 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

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

Bug#848859: FTBFS randomly (failing tests)

Le 04/01/2017 à 19:58, Anton Gladky a écrit : > 2017-01-04 13:26 GMT+01:00 Santiago Vila : >> No matter how much glitch-free is the autobuilder you use to build the >> above package, it will fail to build 1 every 147 times on average, >> mathematically, because the test is wrongly

Bug#849974: openmpi: not enough slots available

Dear Heinrich, I also had noted this change in behaviour, I don't know whether this is intentional. It looks like openmpi does not want to do oversubscription by default anymore. You can get the old behaviour back by using the --map-by option: mpirun --map-by socket:OVERSUBSCRIBE -np 4 python -c

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: >>

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

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/

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, > >

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

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:

Bug#845594: openmpi-bin: MPI_Comm_spawn fails if blt_tcp_if_include is set to lo

th some local > fixes needed for Debian - adding libpmix* which was not fully included; > For me, the test case fails as advertised for unstable, works for me (tm). > > I'm uploading my working version to experimental for further tests. > > regards > Alastair > > >

Bug#842817: fixed in yorick-hdf5 0.8.0-7

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thanks for the reminder. The upload is on its way. Le 02/12/2016 à 11:07, Gilles Filippini a écrit : > Hi Thibaut, > > On Thu, 03 Nov 2016 11:51:19 +0000 Thibaut Paumard > <thib...@debian.org> wrote: >> Source: yorick-hdf5

Bug#845594: openmpi-bin: MPI_Comm_spawn fails if blt_tcp_if_include is set to lo

Le 25/11/2016 à 08:51, Thibaut Paumard a écrit : > Control: retitle 845594 "openmpi: lo interface broken in the tcp btl" > > Hi, > > Actually the regression can also be demonstrated without using > MPI_Comm_spawn with: > mpirun -np 2 --mca btl_tcp_if_include lo

Bug#846323: mplayer extraction is broken

Control: severity -1 wishlist It's a preference that can be set at runtime. Ideally the default should be the new API instead of the (very) old. Regards, self.

Bug#846323: mplayer extraction is broken

Package: gimp-gap Version: 2.6.0+dfsg-5+b1 Severity: important Dear maintainers, MPlayer command-line parameters have changed to that mplayer-based extraction fails with: -aofile has been removed. Use -ao pcm:file= instead. -jpeg has been removed. Use -vo jpeg: instead. It should be fairly

Bug#844495: boost: multiprecision acos() sometimes does not return (also Bug#844490: FTBFS with boost1.62)

of a multiprecision type and is 0, ilogb(b) is 0, not FP_ILOGB0. This, in itself, is probably a bug, that I have not tried to fix. Any chance to see this fix or a better one applied in time for stretch? Regards, Thibaut. Le 25/11/2016 à 12:44, Thibaut Paumard a écrit : > Dear all, > > I

Bug#844495: boost: multiprecision acos() sometimes does not return (also Bug#844490: FTBFS with boost1.62)

.9.2) runs through. In addition: Le 21/11/2016 à 10:02, Thibaut Paumard a écrit : > - 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 &g

Bug#845594: openmpi-bin: MPI_Comm_spawn fails if blt_tcp_if_include is set to lo

Control: retitle 845594 "openmpi: lo interface broken in the tcp btl" Hi, Actually the regression can also be demonstrated without using MPI_Comm_spawn with: mpirun -np 2 --mca btl_tcp_if_include lo --mca btl tcp,self ./slave The above command runs fine under jessie (openmpi 1.6.5-9.1) but

Bug#845594: openmpi-bin: MPI_Comm_spawn fails if blt_tcp_if_include is set to lo

Package: openmpi-bin Version: 2.0.1-7 Severity: normal Dear Maintainer, I attach a minimal example to be compiled with mpicc.openmpi -o slave slave.c mpicc.openmpi -o master master.c Note that slave is an MPI executable that can be launched with e.g. mpicc.openmpi -np 4 ./slave while master

  1   2   3   4   5   >