reassign 1088310 python3-gyoto
notfound 1088310 2.0.2-4+b2
thanks
The point is that this test was ran with with python3-defaults that
includes python3.13, but this version of python3-gyoto had been built
earlier with a version of python3-all-dev that did not include it.
This has been fixed by
Thanks for the heads up.
Yorick builds agains both MPI implementations, so the proposed solution
won't work.
I will fix it ASAP.
Cheers, Thibaut.
Le 20/11/2024 à 22:42, Emilio Pozuelo Monfort a écrit :
Source: yorick
Version: 2.2.04+dfsg1-13
Severity: serious
Hi,
Your package (
exceptions that are normally ingored. Also note that I will very likely work
around this issue in an upcoming version of yorick-ynfft, by disabling
exception trapping during this call.
Cheers, Thibaut.
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (500, 's
Hi,
Thanks for your work.
I'll be looking into it within 3 weeks.
Cheers, Thibaut.
. MPICH does use the
alternative system to provide mpic++, which is good, but a package build
system should not rely on it.
Cheers, Thibaut.
Source: gyoto
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: thib...@debian.org, Adrian Bunk
See #1077247: gyoto does FTBFS on 32-bit, due to mpich being used there.
This is due to the following code in debian/rules:
#
single frames. It adds a Video menu to image
windows in the GIMP.
I have not been using or updating this package in quite a long time.
In my experience this package does not require extensive effort to be
kept in working shape (but I can't afford it anymore).
Cheers, Thibaut.
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
! 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 fr
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.
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.
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
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
D
Thanks for the patch Étienne, very appreciated!
OpenPGP_signature
Description: OpenPGP digital signature
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é
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
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.
Re
t for mis64el
otherwise:
# log in to eller
thibaut@u-wing:~/testhypergeom$ ssh eller.debian.org
# make chroot
thibaut@eller:~$ schroot -b -c sid_mips64el-dchroot -n hypergeom
# install libraries in chroot
thibaut@eller:~$ dd-schroot-cmd -c hypergeom apt-get update
thibaut@eller:~$ dd-schroot-c
regards, Thibaut.
signature.asc
Description: OpenPGP digital signature
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
turn 0;
}
8<8<8<8<8<8<8<8<8<8<
Compile with
gcc -o hypergeom main.c -lflint-arb -lflint
The program segfaults for the built-in data as well as for "large"
values of the two arguments:
(sid_mips64el-dchroot)thibaut
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*.
Regard
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 ki
ust my 2c to avoid future headaches.
Regards, Thibaut.
signature.asc
Description: OpenPGP digital signature
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, Thibau
nds 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 Pari
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
>
<--8<--8<--8<--8<--8<--8<--
My guess: import h5py implicitly sets up the MPI stack, including all
those environment variables. This is equivalent to running mpirun
recursively, which is not supported. Either mpirun notices and errors
out, or does not notice it and dies.
Like other issues, this points to not setting up the MPI stack when not
explicitly requested (see bug#944769 as mentioned by Drew).
Kind regards, Thibaut.
signature.asc
Description: OpenPGP digital signature
> 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
ay be that MPI_Init()
simply dies because h5py has already called it earlier.
Hi have no time for testing right now, but a simple printf() before
calling MPI_Init() should tell.
Regards, Thibaut.
signature.asc
Description: OpenPGP digital signature
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 reacti
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_COMM_WO
so in a separate python3-h5py-openmpi package.
Not sure whether that would make sense. If python3-h5py-openmpi would
need to work as a drop-in replacement for python3-h5py, then the two
would have to conflict with each other and you wouldn't be able to use
both on the same machine.
Kind regards, Thibaut.
signature.asc
Description: OpenPGP digital signature
upon that in my project Gyoto and fixed python.m4
(borrowed from [1]pyconfigure) to support it. I've also submitted my
patch [2]there.
Regards, Thibaut.
[1] https://savannah.gnu.org/projects/pyconfigure/
[2] https://savannah.gnu.org/bugs/?57115
PS: setting Mail-Followup-To 942...@bugs
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 messag
solves your issue because version 2.8.0 was not
linked with MPI (and therefore may be less efficient, depending on
hardware).
Kind regards, Thibaut.
signature.asc
Description: OpenPGP digital signature
I have the same issue
Running `/usr/bin/unattended-upgrade -v -d --download-only` manually shows that
it is trying to solve dependencies somehow and keeps failing at finding
something it is satisfied with. Here is an extract:
[…]
Checking: evolution-common ([,
, ])
pkg libebook-1.2-19 now marked
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
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
tags 874833 pending
thanks
Hi,
there is a new upstream version using qt5 which will help the qt4
removal effort.
Best regards,
--
Thibaut Gridel
retitle 834409 ITA: boats -- race scenario drawing tool
tags 834409 pending
thanks
Hi,
I have a new upstream version that i would like to package.
This will help the qt4 removal effort as well.
Best regards,
--
Thibaut Gridel
> 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
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? Gi
t 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, Thiba
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
Descri
o.2
Package: python3-numpy,Depends: libblas.so.3
Kind regards, Thibaut.
signature.asc
Description: OpenPGP digital signature
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
buggy.
In order to fix that, I plan on introducing a new source package that will
build only yorick-full, and remove this binary package from src:yorick.
Regards, Thibaut.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (900, 'testing'), (
Package: fonts-cantarell
Version: 0.111-2
Severity: normal
In Gtk3 applications such as gucharmap, combining characters U+0335 to U+0338
do not visually combine to the previous character.
Because of this, since they have null width, they visually combine with the
*next* character.
E.g., “a̸” shou
Package: fontforge
Version: 1:20170731~dfsg-1
Severity: normal
When trying to open some UFO fonts, fontforge segfaults with the following
trace:
#0 0x7f2746c6e5aa in SPLFindOrder (ss=0x21) at ././fontforge/svg.c:3453
#1 0x7f2746c793fe in SFLFindOrder (sf=sf@entry=0x55e103d80d10,
layerde
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 pat
work with
this version.
Kind regards, Thibaut.
diff --git a/debian/control b/debian/control
index 690e2f3..2ca483c 100644
--- a/debian/control
+++ b/debian/control
@@ -16,6 +16,7 @@ Build-Depends: cmake,
libpthread-stubs0-dev,
libsqlite3-dev,
libtinyxml-dev,
+ libopenzwave1.5-dev,
python3
Le 28/05/2018 à 02:04, Nobuhiro Iwamatsu a écrit :
Hi, Thibaut.
I am planning to organize it with tracker.d.o.
Do you think about this?
https://tracker.debian.org/teams/pkg-mactel-devel/
Best regards,
Nobuhiro
Great, go ahead.
I don't have access to a mactel for the moment, so I
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
Thanks,
I've asked for the migration of pkg-mactel-de...@lists.alioth.debian.org.
Regards, Thibaut.
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.
.
Regards, Thibaut.
Le 18/05/2018 à 20:33, Federico Ceratto a écrit :
Package: wnpp
Severity: wishlist
Owner: Federico Ceratto
* Package name: domoticz
Version : 3.8153
Upstream Author : https://github.com/domoticz/domoticz/graphs/contributors
* URL : http
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.
n
'serious').
Unfortunately I have no clue how to fix this.
Kind regards, Thibaut.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (900, 'testing'), (500, 'testing-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
F
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
no packages.
-- no debconf information
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
on
, Thibaut.
-- System Information:
Debian Release: 9.3
APT prefers stable-updates
APT policy: (900, 'stable-updates'), (900, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-5-amd64 (SMP w/8 CPU cores)
Loca
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
Confirmed.
It’s possible to recover using « nosmp » on the kernel command line (set from
the bootloader).
T-Bone
Package: libgcab-1.0-0
Version: 0.7-5
Severity: important
Tags: upstream
Attempting to apply a BIOS upgrade failed because of: “failed to extract .cab
file: incorrect checksum detected”.
Rebuilding libgcab-1.0-0 without the latest patch for big-endian checksum
computation fixed the issue.
This is
:
> On Tue, Dec 5, 2017 at 3:20 AM, Thibaut Girka wrote:
> > I have a few gnome-shell extensions enabled: Alternatetab, Application menu,
> > Removable drive menu, Places status indicator and Pomodoro, all from Debian.
>
> Please also disable all your GNOME Shell extensio
Sorry for the line-wrapping in the previous report.
The crashes are still present and very frequent (5~10 times a day).
I think those crashes only occur when a notification is to be displayed (and I
have just successfuly crashed it using “notify-send test”), but it does not
occur every time (and I
empty /tmp
from a recovery shell when the machine was failing to boot. I don't know
whether systemd could do it automatically early in the boot process.
Anyway, I cannot test anymore. Feel free to close this bug.
Kind regards, Thibaut.
Package: gnome-shell
Version: 3.26.2-1
Severity: important
gnome-shell crashes fairly often and quite randomly on my laptop, which is
especially problematic when gnome-shell is used as a Wayland compositor.
I have not managed to find a pattern reliably leading to crashes, but here is a
backtrace:
Package: firmware-atheros
Version: 20170823-1
Severity: normal
Starting from linux 4.12, wifi silently stops working after the second WPA
group rekeying (see #875362):
oct. 19 19:35:43 vicious wpa_supplicant[868]: wlp58s0: CTRL-EVENT-CONNECTED -
Connection to 14:cc:20:56:eb:94 completed [id=0 id_
This appears exactly when wpa_supplicant issues this message:
oct. 18 23:52:25 vicious wpa_supplicant[868]: wlp58s0: WPA: Key negotiation
completed with 16:cc:20:56:eb:95 [PTK=CCMP GTK=TKIP]
oct. 18 23:52:25 vicious wpa_supplicant[868]: wlp58s0: CTRL-EVENT-CONNECTED -
Connection to 16:cc:20:56:eb
Package: src:linux
Version: 4.12.6-1
Severity: normal
Since I upgraded to linux 4.12.0-1-amd64, my wifi at home (5.18GHz, WPA2-PSK)
frequently and silently fails. Manually re-connecting works. This issue does
not appear on linux 4.11.0-1, nor does it occur at my workplace, where I am
connected to
I updated to 4.11.0-trunk-armmp from experimental, and I am also using u-boot
from ALARM, as I have not seen this issue on my ALARM-running A20 boards yet…
… and it failed again, this time with no explicit MMC-related errors, but with
hung tasks instead, much like my previous kernel log.
To be ho
I had the same issue.
A gnome reload (Alt+F2) solved my problem.
I keep experiencing this issue even with a brand new board (same model, newer
hw revision) and on linux-image-4.10.0-rc6-armmp.
I have been informed that this issue might have been fixed by:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers?id=2154d94b40ea2a5de05245
everything that depends on libgsl;
3- install libgslcblas0;
4- remove libgsl0ldbl.
By the way, libgsl2 should be called libgsl19 as the SONAME is libgsl.so.19
(Policy, Sect. 8.1).
Regards, Thibaut.
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (900, 'testing
After a little less than two weeks running on 4.8, the second board finally
crashed during an “aptitude update” with:
1062229.158740] mmc0: Card stuck in programming state! mmc_do_erase
[1062229.933728] sunxi-mmc 1c0f000.mmc: fatal err update clk timeout
[1062230.708711] sunxi-mmc 1c0f000.mmc: fat
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
Control: tags -1 fixed-upstream
Hi,
The bug has been identified by upstream as something that they have
fixed in their internal development version. It has to do with the
numeric separator in some locales. Unsetting the locale works around the
problem:
$ LANG= QFisView
Kind regards, Thibaut
the same bug.
The previous Debian version (3.2+dfsg-1) shows the same behaviour.
Regards, Thibaut.
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-2-amd64 (S
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
aunch the image
reconstruction from there.
In other words, this bug is not RC but has a serious impact on the usability of
the package for most users.
The fix is backported from upstream's latest release (1.1.1).
A source debdiff is attached.
Kind regards, Thibaut.
unblock yorick-
.
Either the Ubuntu infrastructure has to be updated to ignore (or use) the
buildinfo files, or backportpackage has to be fixed to do the workaround above
automatically.
Regards, Thibaut.
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (900, 'testing')
Ar
interferometric instruments
(which this release is targetting), and for people who are not experts of
Yorick.
This is fixed upstream in commit c0a8a9c73d6a032979e9c96cb93bf78d5d9f6cea
Regards, Thibaut.
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (900, 'te
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 str
o normal, mainly because building with dpkg-buildpackage would likely
have worked.
Kind regards, Thibaut.
--- System information. ---
Architecture: Kernel: Linux 4.9.0-1-amd64
Debian Release: 9.0
990 stable repos.fds-team.de 990 stable
download.videolan.org 990 stable dl
, as I can't reproduce the crash.
Regards, Thibaut.
diff --git a/accessible/generic/ApplicationAccessible.h b/accessible/generic/ApplicationAccessible.h
--- a/accessible/generic/ApplicationAccessible.h
+++ b/accessible/generic/ApplicationAccessible.h
@@ -55,39 +55,45 @@ public:
virtual voi
running.
The symptom that firefox crashes is the crash report window popping-up.
The original bug reporter also mentioned in the thread above that he is
using orca as well.
Kind regards, Thibaut.
Le 01/03/2017 à 10:35, MENGUAL Jean-Philippe a écrit :
> Hi,
>
> I have reported this
I have made some more tests using the “spew” and “stress” packages, but it
doesn't seem to cause the issue. So far, it mainly happened during package
installation (thus causing the additional pain of leaving some packages in a
broken state).
I have been unable to reproduce the issue with older ker
severity 855911 critical
thanks
Changed the severity to critical, since it may make the whole system unusable
and cause data loss.
Package: linux-image-4.9.0-1-armmp
Severity: normal
I recently switched to linux 4.9.0 (jessie-backport package on one, package
from testing in the other) and latest u-boot on my two A20-OLinuXIno-LIME2
boards, which were running seriously outdated versions of linux until now (4.4
and 4.0).
Both
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.
my external monitor being connected.
Regards, Thibaut.
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
n main (argc=, argv=) at main.c:471
8<8<8<8<8<8<8<8<8<8<8<8<
Regards, Thibaut.
--- System information. ---
Architecture: Kernel: Linux 4.9.0-1-amd64
Debian Release: 9.0
990 stable repos.fds-tea
and rationale why you want to package it for Debian and how
you plan on maintaining it in the long run.
It was also missing a proper title, which I tried to fix.
Regards, Thibaut.
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?
>
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.
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.
already in directed mode, i.e. the button in the main
interface and the File menu toggle always start unselected, and
selecting them reverts the behaviour to non-direct, but the display to
direct.
Regards, Thibaut.
--- System information. ---
Architecture: Kernel: Linux 4.8.0-2-amd64
Debian
1 - 100 of 1125 matches
Mail list logo
