Bug#763966: linux-image-3.16-2-amd64: Fail to write on ext3 filesystem of an external USB hard drive
On Sun, Nov 09, 2014 at 01:22:31PM +0100, Bastian Blank wrote: On Sat, Oct 04, 2014 at 12:53:29PM +0200, Sebastien Helleu wrote: ** Tainted: I (2048) * Working around severe firmware bug. You may want to search for a fixed firmware, but this may be irrelevant for the current problem. ** Kernel log: [...] This log does not show any message similar to the ones shown before. Please provide complete logs. Bastian -- We'll pivot at warp 2 and bring all tubes to bear, Mr. Sulu! Hi Bastian, Here are the errors I have with kernel 3.17-1 (Linux omega 3.17-1-amd64 #1 SMP Debian 3.17-1~exp1 (2014-10-14) x86_64 GNU/Linux): Nov 22 09:18:02 omega kernel: [ 1120.392369] EXT4-fs (sdc1): mounting ext3 file system using the ext4 subsystem Nov 22 09:18:02 omega kernel: [ 1120.411984] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: (null) Nov 22 09:18:10 omega kernel: [ 1128.721413] end_request: critical target error, dev sdc, sector 12447 Nov 22 09:18:10 omega kernel: [ 1128.721433] Aborting journal on device sdc1-8. Nov 22 09:18:32 omega kernel: [ 1150.220476] EXT4-fs error (device sdc1): ext4_journal_check_start:56: Detected aborted journal Nov 22 09:18:32 omega kernel: [ 1150.220495] EXT4-fs (sdc1): Remounting filesystem read-only I found that other people have similar problem with recent kernels, for example: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1366538 This external USB drives works perfectly fine with any kernel = 3.14 (when booting this kernel on the same machine, so exactly same hardware/softare installed). And with a kernel 3.14, I'm not able at all to write on the disk. That's why I'm almost sure the problem is in Linux kernel. Cordialement / Best regards. -- Sébastien Helleu web: flashtux.org / weechat.org mail: flashc...@flashtux.org irc: FlashCode @ irc.freenode.netxmpp: flashc...@jabber.fr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763966: Mount option nobarrier
As a workaround, I found out that mount option nobarrier helps with the problem, I can write on the disk (even if it's not a perfect solution). /dev/sdc1 /mnt/lacie auto rw,user,noauto,nobarrier 0 0 Cordialement / Best regards. -- Sébastien Helleu web: flashtux.org / weechat.org mail: flashc...@flashtux.org irc: FlashCode @ irc.freenode.netxmpp: flashc...@jabber.fr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776105: weechat: New upstream release (1.1)
On Fri, Jan 23, 2015 at 04:39:57PM -0800, Vincent Cheng wrote: Package: weechat Version: 1.0.1-1 Severity: wishlist Dear maintainer, Please consider packaging the latest upstream release (version 1.1). Thanks! Regards, Vincent Hi, A new version (1.1.1) will be released tomorrow, which will fix annoying bugs of 1.1 (like a crash and problems with irc buffers). This new version should be quickly packaged after the release. Cordialement / Best regards. -- Sébastien Helleu web: flashtux.org / weechat.org mail: flashc...@flashtux.org irc: FlashCode @ irc.freenode.netxmpp: flashc...@jabber.fr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784592: weechat-curses: Wrong conf file setting?
On Thu, May 07, 2015 at 02:06:26AM +0200, Jean-Philippe MENGU?AL wrote: Package: weechat-curses Version: 1.0.1-1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Installed Jessie. * What exactly did you do (or not do) that was effective (or ineffective)? Tried to connect to oftc in ssl. * What was the outcome of this action? Weechat !efused, problem with handshake, gnutls, etc. * What outcome did you expect instead? Should connect in ssl. *** End of the template - remove these template lines *** Problem: my weechat.conf contained: gnutls_ca_file = %h/ssl It should be: /etc/ssl/certs/ca-certificates.crt on a typical Debian Is that my own case or a general conf problem? Thanks, Regards, Hi Jean-Philippe, The option you are mentionning weechat.network.gnutls_ca_file should have the default value /etc/ssl/certs/ca-certificates.crt, you can check inside WeeChat with this command: /help weechat.network.gnutls_ca_file This will show help and current/default values. The value you have may come from an old config file (when auto-upgrading config files, WeeChat don't change the value of options if they have the same name, but just a new default value). So you can just reset the value fo the option with this command: /unset weechat.network.gnutls_ca_file Cordialement / Best regards. -- Sébastien Helleu web: flashtux.org / weechat.org mail: flashc...@flashtux.org irc: FlashCode @ irc.freenode.netxmpp: flashc...@jabber.fr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#896091: gimp fails to run with a symbol lookup error: undefined symbol: babl_process_rows
Package: gimp Version: 2.8.22-1 Severity: grave Justification: renders package unusable gimp fails to run with this error: gimp: symbol lookup error: /usr/lib/x86_64-linux-gnu/libgegl-0.3.so.0: undefined symbol: babl_process_rows -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gimp depends on: ii gimp-data2.8.22-1 ii libaa1 1.4p5-44+b1 ii libbabl-0.1-01:0.1.28-dmo1 ii libbz2-1.0 1.0.6-8.1 ii libc62.27-3 ii libcairo21.15.10-1 ii libdbus-1-3 1.12.6-2 ii libdbus-glib-1-2 0.110-2 ii libexif120.6.21-5 ii libfontconfig1 2.13.0-4 ii libfreetype6 2.8.1-2 ii libgdk-pixbuf2.0-0 2.36.11-2 ii libgegl-0.3-00.3.28-4 ii libgimp2.0 2.8.22-1 ii libglib2.0-0 2.56.1-2 ii libgs9 9.22~dfsg-2 ii libgtk2.0-0 2.24.32-1 ii libgudev-1.0-0 232-2 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-1 ii libmng1 1.0.10+dfsg-3.1+b5 ii libpango-1.0-0 1.42.0-1 ii libpangocairo-1.0-0 1.42.0-1 ii libpangoft2-1.0-01.42.0-1 ii libpng16-16 1.6.34-1 ii libpoppler-glib8 0.62.0-2 ii librsvg2-2 2.40.20-2 ii libtiff5 4.0.9-5 ii libwmf0.2-7 0.2.8.4-12 ii libx11-6 2:1.6.5-1 ii libxcursor1 1:1.1.15-1 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxmu6 2:1.1.2-2 ii libxpm4 1:3.5.12-1 ii python 2.7.14-4 ii python-gtk2 2.24.0-5.1+b1 ii python2.72.7.14-8 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages gimp recommends: ii ghostscript 9.22~dfsg-2 Versions of packages gimp suggests: pn gimp-data-extras pn gimp-help-en | gimp-help pn gvfs-backends ii libasound21.1.3-5 -- no debconf information
Bug#892072: weechat: build against ruby2.5
On Sun, Mar 04, 2018 at 07:57:11PM -0300, Antonio Terceiro wrote: > Source: weechat > Version: 1.9.1-1 > Severity: serious > Justification: will FTBFS soon > Tags: patch > > Hi, > > I am about to upload ruby-defaults to unstable, switching the default > Ruby to ruby2.5, and ruby2.3 support will be removed right after that. > Please consider applying the attached patch, obtained from upstream. > > Even better: please work with upstream to be able to build against the > default ruby, instead of hardcoding a list of ruby versions. Otherwise, > every time there is a Ruby transition, weechat will be a blocker. > Hunting down these issues is quite time consuming. > Hi Antonio, I agree with the need to detect Ruby and other libraries in WeeChat without hardcoding a list of supported versions in the CMake and configure files. I opened an issue, so this will be implemented as soon as possible: https://github.com/weechat/weechat/issues/1156 -- Sébastien Helleu web: weechat.org / flashtux.org irc: FlashCode @ irc.freenode.net
Bug#908782: weechat: please backport v2.1 to stretch for headless mode
On Thu, Sep 13, 2018 at 10:33:45PM +0100, Phil Morrell wrote: > Package: weechat > Version: 1.6-1+deb9u2 > Severity: wishlist > > > Hi, I'd like to use weechat-headless on a stable server, so please > upload v2.1 or later to stretch-backports, thanks. > Hi Phil, Waiting for an official Debian backport, you can use the repositories on weechat.org, where you have WeeChat 2.2 for Debian Stretch (only amd64/i386/armhf archs): https://weechat.org/download/debian/ -- Sébastien Helleu web: weechat.org / flashtux.org irc: FlashCode @ irc.freenode.net
Bug#922431: closed by Michael Gilbert (Re: Bug#922431: chromium: URL chrome://tracing does not work any more)
On Sat, Feb 16, 2019 at 01:33:06AM +, Debian Bug Tracking System wrote: > > Tracing is disabled in debian starting with 72.0.3626.81-1. Its > implementation relies on many sourceless javascript files. > > Best wishes, > Mike Then maybe the "Audits" tab in DevTools could be removed? (not sure if that's easy to do that). Because it seems broken when you try to perform an audit on a site, there's an error: "Ah, sorry! We ran into an error: Protocol error (Tracing.start): 'Tracing.start' was not found". I spent many hours to understand it was related to the latest version available in Debian, so I think this can confuses other people as well. -- Sébastien Helleu web: weechat.org / flashtux.org irc: FlashCode @ irc.freenode.net
Bug#935128: Packages potentially affected by unbounded buffer over-read in GNU Aspell 0.60.*
On Fri, Aug 30, 2019 at 10:31:47AM +0200, Agustin Martin wrote: > On Thu, Aug 29, 2019 at 12:20:28AM +0200, Agustin Martin wrote: > > On Mon, Aug 19, 2019 at 04:33:40PM -0400, Kevin Atkinson wrote: > > > On Mon, 19 Aug 2019, Salvatore Bonaccorso wrote: > > > > > > > See > > > > https://lists.gnu.org/archive/html/aspell-announce/2019-08/msg0.html > > > > > > > Within Debian the "pumpa" will need an update. Others might be > > > > required as well. Kevin Atkinson might be up for help if needed. > > > Also see http://aspell.net/buffer-overread-ucs.txt for a slightly improved > > > version of the announcement that I edited for clarity. > > > > Hi all, > > > > This message is sent to all packages that depend in some way on > > libaspell15 (pdo addresses bcc'ed) > > > > A potentially unbounded buffer over-read has been found in in GNU > > Aspell 0.60.*. Package aspell 0.60.7-1 has been uploaded to Debian > > experimental, including upstream patch to deal with this problem. > > > > Unfortunately this fix may break applications that use null-terminated > > UCS-2 or UCS-4 strings with the C API. These applications will need > > to be fixed to make use of the new more secure API in order to > > continue to have a functional spell checker. > > This is the list of non aspell packages depending on libaspell15 which > are possibly affected (maintainers bcc'ed), > > eiskaltdcpp-qt > enchant > gnustep-gui-runtime > inkscape > kdelibs5-plugins > libenchant1c2a > libenchant2 > libenchant-voikko > librcc0 > libtext-aspell-perl > mcabber > php7.3-pspell > pumpa > raspell > sonnet-plugins > tea > weechat-plugins > xmlcopyeditor > yagf > > -- > Agustin Hi Agustin, WeeChat aspell plugin uses only UTF-8 strings for Aspell and should therefore not be affected by these changes. -- Sébastien Helleu web: weechat.org / flashtux.org irc: FlashCode @ irc.freenode.net
Bug#938817: weechat: Python2 removal in sid/bullseye
On Fri, Aug 30, 2019 at 07:58:32AM +, Matthias Klose wrote: > Package: src:weechat > Version: 2.4-1 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal > > Python2 becomes end-of-live upstream, and Debian aims to remove > Python2 from the distribution, as discussed in > https://lists.debian.org/debian-python/2019/07/msg00080.html > > Your package either build-depends, depends on Python2, or uses Python2 > in the autopkg tests. Please stop using Python2, and fix this issue > by one of the following actions. > > - Convert your Package to Python3. This is the preferred option. In > case you are providing a Python module foo, please consider dropping > the python-foo package, and only build a python3-foo package. Please > don't drop Python2 modules, which still have reverse dependencies, > just document them. > > This is the preferred option. > > - If the package is dead upstream, cannot be converted or maintained > in Debian, it should be removed from the distribution. If the > package still has reverse dependencies, raise the severity to > "serious" and document the reverse dependencies with the BTS affects > command. If the package has no reverse dependencies, confirm that > the package can be removed, reassign this issue to ftp.debian.org, > make sure that the bug priority is set to normal and retitle the > issue to "RM: PKG -- removal triggered by the Python2 removal". > > - If the package has still many users (popcon >= 300), or is needed to > build another package which cannot be removed, document that by > adding the "py2keep" user tag (not replacing the py2remove tag), > using the debian-pyt...@lists.debian.org user. Also any > dependencies on an unversioned python package (python, python-dev) > must not be used, same with the python shebang. These have to be > replaced by python2/python2.7 dependencies and shebang. > > This is the least preferred option. > > If the conversion or removal needs action on another package first, > please document the blocking by using the BTS affects command, like > > affects + src:weechat > > If there is no py2removal bug for that reverse-dependency, please file > a bug on this package (similar to this bug report). > > If there are questions, please refer to the wiki page for the removal: > https://wiki.debian.org/Python/2Removal, or ask for help on IRC > #debian-python, or the debian-pyt...@lists.debian.org mailing list. Hi Matthias, Thanks for reporting this problem. As scheduled by the WeeChat Python 3 roadmap (https://weechat.org/scripts/python3/), the next version of WeeChat will be compiled with Python 3 by default. That means the version 2.6, scheduled in about one week, will include the package weechat-python (name unchanged), and will be linked to Python 3 only (WeeChat 2.6 will not support Python 2 at all in Debian). The description of this package will be updated to mention that it is "Python 3 scripting support" (not just "Python"). So this bug can be closed once the version 2.6 of WeeChat is released and the Debian packaging updated consequently. -- Sébastien Helleu web: weechat.org / flashtux.org irc: FlashCode @ irc.freenode.net
Bug#954410: weechat: Please package the slack plugin
On Sat, Mar 21, 2020 at 12:02:31PM +0100, Francesco Poli (wintermute) wrote: > Package: weechat > Version: 2.7.1-1 > Severity: wishlist > > Hello and thanks for maintaining this Debian package! > > Does it include support for accessing slack channels? > I've read that there exists a plugin named [wee-slack], but > I cannot find the corresponding Debian package. > > [wee-slack]: <https://github.com/wee-slack/wee-slack> > > If the plugin is not packaged, could you please package it? > Thanks for your time and helpulness! Hi Francesco, Scripts are not packaged with WeeChat, they are external contributions. There's a package weechat-scripts in Debian, but scripts are not always up-do-date there. You can simply install the Slack script from your WeeChat with this command: /script install slack.py This will install the latest version available from weechat.org scripts repository: https://weechat.org/scripts/ -- Sébastien Helleu web: weechat.org / flashtux.org irc: FlashCode @ irc.freenode.net
Bug#993333: weechat: FTBFS: Target "irc" links to item " use `command -v' in scripts instead
On Tue, Aug 31, 2021 at 12:18:52AM +0300, Niko Tyni wrote: > Source: weechat > Version: 3.0.1-1 > Severity: serious > Tags: ftbfs sid bookworm > > This package fails to build from source on current sid. > > It looks like this regressed with the recent change in debianutils > that made /usr/bin/which output a deprecation warning. > > >From a build log: > >-- Found GCRYPT: /usr/bin/which: this version of `which' is deprecated; > use `command -v' in scripts instead. >-L/usr/lib/x86_64-linux-gnu -lgcrypt > >[...] > >CMake Error at src/plugins/irc/CMakeLists.txt:20 (add_library): > Target "irc" links to item " use `command -v' in scripts instead. > > -L/usr/lib/x86_64-linux-gnu -lgcrypt" which has leading or trailing > whitespace. This is now an error according to policy CMP0004. > > A full log is available at > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/weechat.html > > -- > Niko Tyni nt...@debian.org Hi Niko, Thanks for your report. The problem is indirectly caused by the deprecation of the "which" command in the package debianutils. I opened the Debian bug #993244 two days ago (feel free to merge bugs if needed). The "which" command seems to be used inside CMake, not in WeeChat itself, but this breaks compilation of WeeChat (I suppose like many other packages). For now I have no fix available on WeeChat side. If the warning on stderr in "which" command stays as-is, I think CMake has to be fixed. -- Sébastien Helleu web: weechat.org / flashtux.org irc: FlashCode @ irc.libera.chat
Bug#994040: "SystemError: initialization of _psycopg raised unreported exception" when running under WSGI
Hi Stéphane,
I've hit the same problem while migrating my Django sites from Debian Buster to
Bullseye.
In my case, setting "WSGIApplicationGroup" to "%{GLOBAL}" doesn't help much.
But I found another solution, by enabling Daemon mode, as recommended by the
Django docs:
https://docs.djangoproject.com/en/3.2/howto/deployment/wsgi/modwsgi/#using-mod-wsgi-daemon-mode
So I added these two lines in each site (with appropriate domain name) and it
works fine:
WSGIDaemonProcess example.com
WSGIProcessGroup example.com
Hope it helps.
--
Sébastien Helleu
web: weechat.org / flashtux.org
irc: FlashCode @ irc.libera.chat
Bug#1001245: weechat: FTBS against Ruby 3.0
On Mon, Dec 06, 2021 at 06:23:50PM -0300, Lucas Kanashiro wrote: > Package: weechat > Version: 3.3-1 > Severity: important > Tags: patch bookworm sid > User: debian-r...@lists.debian.org > Usertags: ruby3.0 > > Dear maintainer, > > The current version of weechat does not support Ruby 3.0, please apply the > upstream patch below: > > https://github.com/weechat/weechat/commit/fe9768f484304c28cf4e6d6eb980613b00ca6904 > > > It will fix the current FTBFS against ruby3.0. > > TIA! > > -- > Lucas Kanashiro Hi, If this patch is applied, other commits should be used as well: they fix issues on macOS and detection with autotools, but not sure then if they are mandatory for the Debian package. Commits: * Fix compilation with Ruby 3.0 on macOS: https://github.com/weechat/weechat/commit/27a480c7d7cc897ec1228f25d97bbfeb0f52dca3 * Fix detection of Ruby 3.0 on macOS: https://github.com/weechat/weechat/commit/be753046b729dab518c390cbf9be6360310fc65a * Add detection of Ruby 3.0 in autotools: https://github.com/weechat/weechat/commit/aed64f5020f63a37413da29367734b066fdaf235 -- Sébastien Helleu web: weechat.org / flashtux.org irc: FlashCode @ irc.libera.chat
