Bug#652630: xmobar: Please update xmobar to 0.14
Package: xmobar Version: 0.13-2 Severity: wishlist Please update xmobar to version 0.14, in order to include the patch that makes CoreTemp work with the new kernel/lm_sensors file structure. Thanks in advance. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (700, 'testing'), (650, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xmobar depends on: ii libc6 2.13-21 ii libffi5 3.0.10-3 ii libgmp10 2:5.0.2+dfsg-2 ii libiw30 30~pre9-7 ii libx11-6 2:1.4.4-4 ii libxext6 2:1.3.0-3 ii libxft2 2.2.0-3 ii libxinerama1 2:1.1.1-3 Versions of packages xmobar recommends: pn curl Versions of packages xmobar suggests: ii xmonad 0.9.2-2+b3 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#665010: libghc-llvm-base-dev: Does not support LLVM 3.0
Package: libghc-llvm-base-dev Version: 3.0.0.0-3 Severity: important The package libghc-llvm-base-dev depends on llvm-dev (which is currently at version 3.0-9 in testing) but libghc-llvm-base-dev-3.0.0.0 doesn't support LLVM 3.0 yet. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (700, 'testing'), (650, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#665010: [Pkg-haskell-maintainers] Bug#665010: libghc-llvm-base-dev: Does not support LLVM 3.0
On 03/22/2012 03:21 PM, Joachim Breitner wrote: > Hi, > > Am Donnerstag, den 22.03.2012, 12:46 +0200 schrieb Ilias Tsitsimpis: >> The package libghc-llvm-base-dev depends on llvm-dev (which is currently >> at version 3.0-9 in testing) but libghc-llvm-base-dev-3.0.0.0 doesn't support >> LLVM 3.0 yet. >> > > according to http://hackage.haskell.org/package/llvm-base-3.0.0.0 it > should support LLVM 3.0. Why do you think it does not? > > Greetings, > Joachim > I tested it. Although the package installs/builds fine, I get linking errors when trying to use the llvm bindings. This problem is also reported on github issues page [1][2]. Thanks, Ilias [1] https://github.com/bos/llvm/issues/27 [2] https://github.com/bos/llvm/pull/30 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#665010: Does not support LLVM 3.0
Hi, there is a new version of haskell's llvm bindings (3.0.1.0) on hackage. I tested it against current version of llvm-dev package (3.0-9) and it seems to work fine! It would be nice if you could update the package. Thanks, Ilias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#818561: Useless in Debian
Hi David, Sorry for the late reply. On Mon, Oct 31, 2016 at 02:11PM, David Prévot wrote: > Le 31/10/2016 à 13:25, Axel Beckert a écrit : > > JFTR: The recent hoogle update pulled this in. So it seems no more > > useless but now even has reverse dependencies again. :-) > > Thank you Axel for the heads up. I guess someone (maybe from the > hoogle team) will want to take over the maintenance. Feel free to remove > me from Uploaders when you do. Indeed, hoogle now depends on libjs-chosen (since upstream ships an embedded copy of it). I failed to notice the above RC bug, or else I would have discussed this earlier. The hoogle package is maintained by the Debian Haskell Group. I don't think libjs-chosen would be a good fit for the Team. Please consider closing the above bug report (so that hoogle can migrate to testing) and orphan the package. Best, -- Ilias
Bug#844598: [haskell-stack] relocations errors on compiling
Hi Frederic, On Thu, Nov 17, 2016 at 01:35PM, frederic wagner wrote: > I cannot build anything using stack. > > to reproduce : > > stack new test simple > cd test > stack build > > -> gives following output : > [1 of 1] Compiling Main ( /tmp/stack28309/Setup.hs, > /tmp/stack28309/Setup.o ) > Linking > /home/wagnerf/.stack/setup-exe-cache/x86_64-linux/tmp-setup-Simple-Cabal-1.24.0.0-ghc-8.0.1 > ... > /usr/bin/ld: /tmp/stack28309/Setup.o: relocation R_X86_64_32S against symbol > `stg_bh_upd_frame_info' can not be used when making a shared object; > recompile with -fPIC > /usr/bin/ld: > /home/wagnerf/.stack/programs/x86_64-linux/ghc-8.0.1/lib/ghc-8.0.1/Cabal-1.24.0.0/libHSCabal-1.24.0.0.a(Simple__87.o): > relocation R_X86_64_32S against `.text' can not be used when making a shared > object; recompile with -fPIC Thanks for reporting this. The above works for me with haskell-stack and ghc both from unstable. The current version of ghc in testing is known to be broken (see #712228): https://bugs.debian.org/712228 Could you give it a try? Best, -- Ilias
Bug#862173: jessie-pu: package offlineimap/6.3.4-1
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
Dear Release Team,
I would like to update OfflineIMAP in jessie, to fix the #859478 RC bug.
Backporting the fix from newer versions of the software is too invasive,
so instead I have added a WARNING message, that will prevent users from
using the broken functionality. For more information, please see the
related bug report.
Best,
--
Ilias
diff -Nru offlineimap-6.3.4/debian/changelog offlineimap-6.3.4/debian/changelog
--- offlineimap-6.3.4/debian/changelog 2011-08-23 17:27:40.0 +0300
+++ offlineimap-6.3.4/debian/changelog 2017-05-09 15:14:10.0 +0300
@@ -1,3 +1,15 @@
+offlineimap (6.3.4-1+deb8u1) stable-proposed-updates; urgency=medium
+
+ * Prevent the usage of maxage.
+The implementation of maxage is broken in this version of OfflineIMAP
+(v6.3.4) and may even result in data loss. Document the above behavior in
+the example conf file and also warn the user every time this feature is
+being used (Closes: #859478).
+ * Set myself as the maintainer.
+Package has already been adopted in unstable.
+
+ -- Ilias Tsitsimpis Tue, 09 May 2017 15:14:10 +0300
+
offlineimap (6.3.4-1) unstable; urgency=low
* New upstream release.
diff -Nru offlineimap-6.3.4/debian/control offlineimap-6.3.4/debian/control
--- offlineimap-6.3.4/debian/control 2011-08-23 17:27:40.0 +0300
+++ offlineimap-6.3.4/debian/control 2017-04-11 13:08:40.0 +0300
@@ -1,7 +1,7 @@
Source: offlineimap
Section: mail
Priority: optional
-Maintainer: John Francesco Ferlito
+Maintainer: Ilias Tsitsimpis
Build-Depends: debhelper (>= 7.0.50~)
Build-Depends-Indep: python-support (>= 0.4.0), python-docutils, quilt
Standards-Version: 3.9.1
diff -Nru offlineimap-6.3.4/debian/patches/Prevent-usage-of-maxage.patch offlineimap-6.3.4/debian/patches/Prevent-usage-of-maxage.patch
--- offlineimap-6.3.4/debian/patches/Prevent-usage-of-maxage.patch 1970-01-01 02:00:00.0 +0200
+++ offlineimap-6.3.4/debian/patches/Prevent-usage-of-maxage.patch 2017-04-11 16:52:45.0 +0300
@@ -0,0 +1,43 @@
+Description: Prevent the usage of maxage
+ The implementation of maxage is broken in this version of OfflineIMAP (v6.3.4)
+ and may even result in data loss. Document the above behavior in the example
+ conf file and also warn the user every time this feature is being used.
+Author: Ilias Tsitsimpis
+Bug-Debian: https://bugs.debian.org/859478
+Forwarded: no, fixed in newer versions
+
+Index: b/offlineimap.conf
+===
+--- a/offlineimap.conf
b/offlineimap.conf
+@@ -237,6 +237,10 @@ remoterepository = RemoteExample
+ # calculate the earliest day that would be included in the search and include all
+ # messages from that day until today. e.g. maxage = 3 to sync only the last 3 days mail
+
++# WARNING: The implementation of maxage is broken in this version of OfflineIMAP
++# and may result in data loss. You should avoid its use, or update to a newer
++# version. For more information, please see https://bugs.debian.org/859478.
++
+ # maxage = 3
+
+
+Index: b/offlineimap/accounts.py
+===
+--- a/offlineimap/accounts.py
b/offlineimap/accounts.py
+@@ -169,6 +169,15 @@ class SyncableAccount(Account):
+ self.localrepos = Repository(self, 'local')
+ self.statusrepos = Repository(self, 'status')
+
++# Warn if maxage is being used, since it is broken on this version.
++# For more information, see https://bugs.debian.org/859478.
++maxage = self.getconfint("maxage", -1)
++if maxage != -1:
++self.ui.warn("maxage has been enabled for account `%s'."
++" This feature is broken in the current version of OfflineIMAP"
++" and may result in data loss. You should avoid its use,"
++" or update to a newer version." % self.name)
++
+ # Loop account sync if needed (bail out after 3 failures)
+ looping = 3
+ while looping:
diff -Nru offlineimap-6.3.4/debian/patches/series offlineimap-6.3.4/debian/patches/series
--- offlineimap-6.3.4/debian/patches/series 2011-08-23 17:27:40.0 +0300
+++ offlineimap-6.3.4/debian/patches/series 2017-04-11 13:08:08.0 +0300
@@ -1 +1,2 @@
0001-Fix-manpage-build-failures-from-inconsistent-heading.patch
+Prevent-usage-of-maxage.patch
Bug#859478: offlineimap: 'maxage' comments are wrong, offlineimap DELETES your mails
Control: fixed -1 6.6.0~rc3+dfsg1-1 Hi Cyril, On Tue, Apr 04, 2017 at 01:28AM, Cyril Brulebois wrote: > Looking at the code, it seems “is that older than maxage?” is > implemented by looking at the timestamp in the filename for local > mails, which happens to be October 2016 for a mail received in 2015! Your analysis is correct. Here is a blog post which explains in depth the above bug: http://www.offlineimap.org/devel/2015/04/14/why-we-changed-maxage.html This should be fixed in newer versions of OfflineIMAP. Could you please give it a try? You may also be interested in the 'sync_deletes' feature, introduced in version 7.0.6+dfsg1-1. Copying from the docs: This option stands in the [Repository RemoteExample] section. Propagate deletions from remote to local. Messages deleted in this repository won't get deleted on the local repository if set to "no". Default is yes. Best, -- Ilias
Bug#859504: python-requests breaks packages using urllib3
Package: python-requests
Version: 2.12.4-1
Severity: important
Tags: patch
Hello,
thank you for maintaining python-requests.
It seems that patch use-pip-unbundling.patch doen not work as expected:
>>> import sys, urllib3
>>> from urllib3.exceptions import HTTPError
>>> urllib3.exceptions.HTTPError is HTTPError
True
>>> sys.modules["urllib3.exceptions"] is urllib3.exceptions
True
>>> import requests
>>> urllib3.exceptions.HTTPError is HTTPError
False
>>> sys.modules["urllib3.exceptions"] is urllib3.exceptions
False
This causes (otherwise correct) Python programs to fail by simply
importing the 'requests' module. The solution proposed by upstream[1]
doesn't work either.
[1]
https://github.com/kennethreitz/requests/blob/master/requests/packages/__init__.py
Attached is a patch that works for me and seems to fix the above bug.
It would be great if this could be fixed for stretch.
Best,
--
Ilias
diff -pru old/debian/patches/use-pip-unbundling.patch new/debian/patches/use-pip-unbundling.patch
--- old/debian/patches/use-pip-unbundling.patch 2017-04-04 13:31:19.965450626 +0300
+++ new/debian/patches/use-pip-unbundling.patch 2017-04-04 13:35:17.882779284 +0300
@@ -10,11 +10,11 @@ Patch-Name: use-pip-unbundling.patch
requests/packages/__init__.py | 66 +--
1 file changed, 51 insertions(+), 15 deletions(-)
-diff --git a/requests/packages/__init__.py b/requests/packages/__init__.py
-index 4077265..b1206b2 100644
+Index: b/requests/packages/__init__.py
+===
--- a/requests/packages/__init__.py
+++ b/requests/packages/__init__.py
-@@ -23,20 +23,56 @@ request.
+@@ -23,20 +23,54 @@ request.
from __future__ import absolute_import
import sys
@@ -34,24 +34,21 @@ index 4077265..b1206b2 100644
-import chardet
-sys.modules['%s.chardet' % __name__] = chardet
+try:
-+__import__(vendored_name, globals(), locals(), level=0)
++__import__(modulename, globals(), locals(), level=0)
+except ImportError:
-+try:
-+__import__(modulename, globals(), locals(), level=0)
-+except ImportError:
-+# We can just silently allow import failures to pass here. If we
-+# got to this point it means that ``import requests.packages.whatever``
-+# failed and so did ``import whatever``. Since we're importing this
-+# upfront in an attempt to alias imports, not erroring here will
-+# just mean we get a regular import error whenever requests
-+# *actually* tries to import one of these modules to use it, which
-+# actually gives us a better error message than we would have
-+# otherwise gotten.
-+pass
-+else:
-+sys.modules[vendored_name] = sys.modules[modulename]
-+base, head = vendored_name.rsplit(".", 1)
-+setattr(sys.modules[base], head, sys.modules[modulename])
++# We can just silently allow import failures to pass here. If we
++# got to this point it means that ``import requests.packages.whatever``
++# failed and so did ``import whatever``. Since we're importing this
++# upfront in an attempt to alias imports, not erroring here will
++# just mean we get a regular import error whenever requests
++# *actually* tries to import one of these modules to use it, which
++# actually gives us a better error message than we would have
++# otherwise gotten.
++pass
++else:
++sys.modules[vendored_name] = sys.modules[modulename]
++base, head = vendored_name.rsplit(".", 1)
++setattr(sys.modules[base], head, sys.modules[modulename])
-try:
-from . import idna
@@ -67,6 +64,7 @@ index 4077265..b1206b2 100644
+vendored('urllib3.contrib')
+vendored('urllib3.contrib.ntlmpool')
+vendored('urllib3.contrib.pyopenssl')
++vendored('urllib3.contrib.socks')
+vendored('urllib3.exceptions')
+vendored('urllib3.fields')
+vendored('urllib3.filepost')
Bug#861761: unblock: (pre-approval) offlineimap/7.0.14+dfsg1-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Dear Release Team,
One of the UIs for OfflineIMAP, namely Blinkenlights, is broken in the
current version of OfflineIMAP. More specifically, the output of
Blinkenlights becomes "garbled" and eventually results in a crash of the
Python process. For more information, see the upstream bug report:
https://github.com/OfflineIMAP/offlineimap/issues/160
This has been broken for more than a year, but only recently fixed.
Since the patch is fairly small, and users have already complained about
this in the past[1], I would like to update OfflineIMAP to fix this bug.
What do you think?
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809676#31
unblock offlineimap/7.0.14+dfsg1-2
Kind Regards,
--
Ilias
diff -Nru offlineimap-7.0.12+dfsg1/debian/changelog offlineimap-7.0.12+dfsg1/debian/changelog
--- offlineimap-7.0.12+dfsg1/debian/changelog 2016-12-01 13:04:38.0 +0200
+++ offlineimap-7.0.12+dfsg1/debian/changelog 2017-05-03 18:40:38.0 +0300
@@ -1,3 +1,11 @@
+offlineimap (7.0.12+dfsg1-2) unstable; urgency=medium
+
+ * Backport upstream patch to fix Blinkenlights UI.
+Fix the Blinkenlights UI where the terminal is garbled and eventually
+OfflineIMAP crashes.
+
+ -- Ilias Tsitsimpis Wed, 03 May 2017 18:40:38 +0300
+
offlineimap (7.0.12+dfsg1-1) unstable; urgency=medium
* New upstream release.
diff -Nru offlineimap-7.0.12+dfsg1/debian/patches/Acquire-lock-before-updating-the-CursesLogHandler-window.patch offlineimap-7.0.12+dfsg1/debian/patches/Acquire-lock-before-updating-the-CursesLogHandler-window.patch
--- offlineimap-7.0.12+dfsg1/debian/patches/Acquire-lock-before-updating-the-CursesLogHandler-window.patch 1970-01-01 02:00:00.0 +0200
+++ offlineimap-7.0.12+dfsg1/debian/patches/Acquire-lock-before-updating-the-CursesLogHandler-window.patch 2017-05-03 18:29:54.0 +0300
@@ -0,0 +1,60 @@
+From: Ilias Tsitsimpis
+Date: Wed, 12 Apr 2017 13:25:46 +0300
+Subject: Acquire lock before updating the CursesLogHandler window
+
+Make sure that we refresh the screen atomically, since the emit()
+function may be called by more that one threads at a time.
+
+Also, modify the draw_bannerwin() method which used to fail in case the
+window would become too small. Make sure that the provided offsets to
+the window.addstr() method are properly bounded.
+
+Closes #160: blinkenlights display is broken
+Tested-by: Cyril Brulebois
+Tested-by: Gaudenz Steinlin
+Signed-off-by: Ilias Tsitsimpis
+Signed-off-by: Nicolas Sebrecht
+
+Origin: upstream, https://github.com/OfflineIMAP/offlineimap/commit/7bc54d241cce
+Bug: https://github.com/OfflineIMAP/offlineimap/issues/160
+Bug-Debian: https://bugs.debian.org/809676
+---
+ offlineimap/ui/Curses.py | 15 ---
+ 1 file changed, 8 insertions(+), 7 deletions(-)
+
+diff --git a/offlineimap/ui/Curses.py b/offlineimap/ui/Curses.py
+index 152c5d6..e97bed0 100644
+--- a/offlineimap/ui/Curses.py
b/offlineimap/ui/Curses.py
+@@ -315,11 +315,11 @@ class CursesLogHandler(logging.StreamHandler):
+ y,x = self.ui.logwin.getyx()
+ if y or x: self.ui.logwin.addch(10) # no \n before 1st item
+ self.ui.logwin.addstr(log_str, color)
++self.ui.logwin.noutrefresh()
++self.ui.stdscr.refresh()
+ finally:
+ self.ui.unlock()
+ self.ui.tframe_lock.release()
+-self.ui.logwin.noutrefresh()
+-self.ui.stdscr.refresh()
+
+ class Blinkenlights(UIBase, CursesUtil):
+ """Curses-cased fancy UI.
+@@ -611,11 +611,12 @@ class Blinkenlights(UIBase, CursesUtil):
+ color = curses.A_REVERSE
+ self.bannerwin.clear() # Delete old content (eg before resizes)
+ self.bannerwin.bkgd(' ', color) # Fill background with that color
+-string = "%s %s"% (offlineimap.__productname__,
+-offlineimap.__version__)
+-self.bannerwin.addstr(0, 0, string, color)
+-self.bannerwin.addstr(0, self.width -len(offlineimap.__copyright__) -1,
+- offlineimap.__copyright__, color)
++string = "%s %s" % (offlineimap.__productname__,
++offlineimap.__version__)
++spaces = " " * max(1, (self.width - len(offlineimap.__copyright__)
++ - len(string) - 1))
++string = "%s%s%s" % (string, spaces, offlineimap.__copyright__)
++self.bannerwin.addnstr(0, 0, string, self.width - 1, color)
+ self.bannerwin.noutrefresh()
+
+ def draw_logwin(self):
diff -Nru offlineimap-7.0.12+dfsg1/debian/patches/series offlineimap-7.0.12+dfsg1/debian/patches/series
--- offlineimap-7.0.12+dfsg1/debian/patches/series 2016-12-01 13:04:11.0 +0200
+++ offlineimap-7.0.12+dfsg1/debian/patches/series 2017-05-03 18:29:54.0 +030
Bug#861899: nodm: postinst should not write to stdout
Package: nodm Version: 0.13-1 Severity: normal Tags: patch Dear maintainer, nodm.postinst should not write to stdout, since messages written to stdout may confuse debconf. See the following snippnet from debconf-devel(7) man page[1]: Avoid outputting anything to stdout in your postinst, since that can confuse debconf, and postinst should not be verbose anyway. Output to stderr is ok, if you must. [1] https://manpages.debian.org/unstable/debconf-doc/debconf-devel.7.en.html Best, -- Ilias diff -ru old/debian/nodm.postinst new/debian/nodm.postinst --- old/debian/nodm.postinst 2017-05-02 23:57:24.0 +0300 +++ new/debian/nodm.postinst 2017-05-05 16:33:31.874949860 +0300 @@ -18,7 +18,7 @@ RET="$THIS_PACKAGE" fi if [ "$THIS_PACKAGE" != "$RET" ]; then - echo "Please be sure to run \"dpkg --configure $RET\"." + echo "Please be sure to run \"dpkg --configure $RET\"." >&2 fi if db_get "$RET"/daemon_name; then echo "$RET" > $DEFAULT_DISPLAY_MANAGER_FILE
Bug#808029: python-imaplib2: Please update package to its latest version
Source: python-imaplib2 Version: 2.50-2 Severity: wishlist Upstream has released imaplib2 version 2.53 which contains some minor fixes. Please consider updating this package to its latest version. Thanks, Ilias
Bug#794834: goobook: can't authenticate
reassign 794834 python-oauth2client 1.4.12-0.1 merge 794312 794834 thanks Hi Raffaele, Thanks for reporting this. This seems to be a bug in the latest version of the python-oauth2client package[1]. Hopefully it will be fixed soon. Until then, you can try and downgrade the python-oauth2client package to its previous version. Cheers, Ilias [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794312 signature.asc Description: Digital signature
Bug#826837: [debchange] --newversion always creates new entry when --distribution is given
Package: devscripts
Version: 2.16.5
Severity: normal
Tags: patch
Dear maintainer,
According to the manpage, the --newversion should append to the
current changelog entry if the current release is UNRELEASED:
| If DEBCHANGE_RELEASE_HEURISTIC is changelog (default) and the current
| release is UNRELEASED, this will only change the version of the
| current changelog stanza. Otherwise, this will create a new changelog
| stanza with the new version.
This doesn't hold when the --distribution option is being used. Instead,
a new changelog entry is created, leaving the old one (UNRELEASED) entry
intact.
I have provided a patch that fixes tha above error.
Cheers,
--
Ilias
diff --git a/scripts/debchange.pl b/scripts/debchange.pl
index db52b60..af6176c 100755
--- a/scripts/debchange.pl
+++ b/scripts/debchange.pl
@@ -1219,8 +1219,7 @@ if (($opt_i || $opt_n || $opt_bn || $opt_qa || $opt_R || $opt_s || $opt_team ||
if (($opt_v or $opt_i or $opt_l or $opt_d) and
$opt_release_heuristic eq 'changelog' and
- $changelog->{Distribution} eq 'UNRELEASED' and
- $distribution eq 'UNRELEASED') {
+ $changelog->{Distribution} eq 'UNRELEASED') {
$merge = 1;
} else {
Bug#827282: override: gitit:web/extra
Package: ftp.debian.org Severity: normal Control: block 825357 by -1 Please change the section of the binary package 'gitit' to 'web'. Thanks, -- Ilias
Bug#596031: still present with new version
Control: tags -1 + moreinfo unreproducible I cannot reproduce this problem. Since this is a very old bug report, could you please test if this still occurs in the latest version of OfflineIMAP (v6.7.0+dfsg1)? Cheers, Ilias
Bug#686039: KeyError when trying to sync certain folders
Control: tags -1 + moreinfo unreproducible On Mon, Aug 27, 2012 at 06:32PM, Ryan Kavanagh wrote: > When I try to sync certain folders (most notably INBOX), I get the > following errors: > > ERROR: Exceptions occurred during the run! > ERROR: ERROR in syncfolder for GMAIL folder INBOX: Traceback (most recent > call last): > File "/usr/lib/python2.7/dist-packages/offlineimap/accounts.py", line 407, > in syncfolder > localfolder.cachemessagelist() > File "/usr/lib/python2.7/dist-packages/offlineimap/folder/UIDMaps.py", line > 106, in cachemessagelist > del self.diskr2l[ruid] > KeyError: 5222L Hi Ryan, I cannot reproduce this problem. Since this is a very old bug report, could you please test if this still occurs in the latest version of OfflineIMAP (v6.7.0+dfsg1)? Cheers, Ilias
Bug#696373: offlineimap: offline hang too often
Control: tags -1 + moreinfo unreproducible On Thu, Dec 20, 2012 at 06:33AM, Ubuntu6226 wrote: > I launch offlineimap at boot with screen -d -m and so on. > > It works fine, but much too often, offline will hangs > and stop activity as receiving and storing emails each 5 mins. I cannot reproduce this problem. Since this is a very old bug report, could you please test if this still occurs in the latest version of OfflineIMAP (v6.7.0+dfsg1)? Cheers, Ilias
Bug#810119: GSSAPI/Kerberos authentication broken
Control: forwarded -1 https://github.com/OfflineIMAP/offlineimap/issues/332 Hi Guido, On Mon, Jan 11, 2016 at 08:22AM, Guido Günther wrote: > I wrote the prototype for the initial GSSAPI support in offlineimap so I > can have a look myself - it's just that I don't know when (for know I > just went back to the jessie version). > > I put this on my todo list and hope, so it might make sense to open a > upstream report so it's at least documented that it's broken. Any progress on this? I reported this upstream as you requested. Cheers, Ilias
Bug#604981: offlineimap: freezes while syncing debian.devel.general.2007
Control: tags -1 + moreinfo Hi Luca, On Thu, Nov 25, 2010 at 11:52PM, Luca Capello wrote: > I was (finally) moving to offlineimap to locally store all my emails, > but the initial sync frozen on a particular email from my 2007 archive > of debian-devel@. This raises the CPU usage to a point where my > laptop was automatically switched off to prevent thermal problems. > And this happens every time I tried to sync that single folder. Since this is a very old bug report, could you please test if this still occurs in the latest version of OfflineIMAP (v6.7.0+dfsg1)? Cheers, Ilias
Bug#618812: offlineimap: stacking connections to Exchange IMAP
Control: tags -1 + moreinfo Hi, Since this is a very old bug report, could you please test if this still occurs in the latest version of OfflineIMAP (v6.7.0+dfsg1)? Cheers, Ilias
Bug#648195: Spordically hangs itself up on a futex
Control: tags -1 + moreinfo unreproducible Hi Martin, On Wed, Nov 09, 2011 at 03:25PM, martin f krafft wrote: > As of late, offlineimap hangs itself up sporadically. I have yet to > identify a pattern or capture a complete strace, but I am working on > it. I cannot reproduce this problem. Since this is a very old bug report, could you please test if this still occurs in the latest version of OfflineIMAP (v6.7.0+dfsg1)? Cheers, Ilias
Bug#689921: offlineimap: socket error "Connection reset by peer" triggers python exception and exit
Control: tags -1 + moreinfo
Hi Jonathan,
On Mon, Oct 08, 2012 at 11:47AM, Jonathan Nieder wrote:
> Hi again,
>
> Jonathan Nieder wrote:
>
> > From today's offlineimap sync:
> [...]
> > | OfflineImapError: Server 'imap.gmail.com' closed connection, error on
> > SELECT '[Gmail]/All Mail'. Server said: command: EXAMINE => socket error:
> > - [Errno 104] Connection reset by peer
>
> Here's another uncaught OfflineImapError. I'll be happy to file a
> separate bug for it if that's useful --- just say the word.
>
[...]
>
> | File "/usr/lib/python2.7/dist-packages/offlineimap/imaplibutil.py", line
> 63, in select
> | raise OfflineImapError(errstr, severity)
> | OfflineImapError: Error SELECTing mailbox '[Gmail]/All Mail', server reply:
> | ('NO', ['System error (Failure)'])
These seem to be two different errors. Since this is a very old bug
report, could you please test if these still occur in the latest version
of OfflineIMAP (v6.7.0+dfsg1)?
Cheers,
Ilias
Bug#816532: RFA: python-subprocess32 -- backport of the Py3 stdlib subprocess module for Py2
Control: retitle -1 ITA: python-subprocess32 -- backport of the Py3 stdlib subprocess module for Py2 Control: owner -1 ! Hi Daniel, I would like to adopt the python-subprocess32 package. Thank you for all the work maintaining the package so far. On Tue, May 17, 2016 at 02:15PM, Daniel Stender wrote: > The package is community maintained within the DPMT, it would be great if this > could be kept, and it increases the chance to find a sponsor. I intend to request access to the DPMT and keep maintaining this package within the team. Thanks, -- Ilias signature.asc Description: PGP signature
Bug#829463: RM: haskell-openglraw [armel armhf] -- ROM; Too heavy to be built on arm*
Package: ftp.debian.org Severity: normal Hi, The haskell-openglraw package is not reasonably buildable in architectures that use GHC's LLVM code generator (i.e., arm* architectures). For a more detailed discussion, please see here: https://lists.debian.org/debian-haskell/2016/07/msg2.html In order to unblock the testing migration of Haskell packages, please remove the binaries produced by the haskell-openglraw source packages on armel and armhf. Thanks, -- Ilias signature.asc Description: PGP signature
Bug#785715: RFS: goobook/1.6-1 [ITP] -- command-line interface to Google contacts
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "goobook" Package name: goobook Version : 1.6-1 Upstream Author : Christer Sjöholm URL : https://pypi.python.org/pypi/goobook License : GPL-3.0+ Section : mail It builds those binary packages: goobook- command-line interface to Google contacts To access further information about this package, please visit the following URL: http://mentors.debian.net/package/goobook Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/g/goobook/goobook_1.6-1.dsc More information about goobook can be obtained from https://pypi.python.org/pypi/goobook. Regards, Ilias signature.asc Description: Digital signature
Bug#792190: override: uthash-dev:devel/optional
Package: ftp.debian.org Severity: normal Dear FTP Team, Please change the override priority for uthash-dev package from extra to optional because it does neither conflict with other packages nor does it depend on a package with lower priority. Thanks, Ilias signature.asc Description: Digital signature
Bug#785534: ITP: goobook -- access your Google contacts from command-line or mutt
Package: wnpp Severity: wishlist Owner: Ilias Tsitsimpis * Package name: goobook Version : 1.6 Upstream Author : Christer Sjöholm * URL : https://pypi.python.org/pypi/goobook * License : GPL-3.0+ Programming Lang: Python Description : access your Google contacts from command-line or mutt goobook can be used to access your Google contacts from the command-line and from MUAs such as Mutt. It can be used from Mutt the same way as abook. I plan to maintain this package myself but I will need a sponsor. signature.asc Description: Digital signature
Bug#785534: ITP: goobook -- access your Google contacts from command-line or mutt
Hi Christian, Thanks for your advice. I read these[1][2] two guidelines about writing Debian package descriptions which were very helpful. So I am going to change my package description to: Description: command-line interface to Google contacts GooBook is a command-line interface to Google contacts which supports: . * Searching contacts . * Adding new contacts . * Mutt integration . GooBook is written in Python and is designed for use with MUAs such as Mutt in the same way as abook. Cheers, Ilias [1] https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-desc-basics [2] https://people.debian.org/~bubulle/smith/descriptions.html On Mon, May 18, 2015 at 07:23AM, Christian PERRIER wrote: > Quoting Ilias Tsitsimpis (i.tsitsim...@gmail.com): > > Package: wnpp > > Severity: wishlist > > Owner: Ilias Tsitsimpis > > > > * Package name: goobook > > Version : 1.6 > > Upstream Author : Christer Sjöholm > > * URL : https://pypi.python.org/pypi/goobook > > * License : GPL-3.0+ > > Programming Lang: Python > > Description : access your Google contacts from command-line or mutt > > > > goobook can be used to access your Google contacts from the > > command-line and from MUAs such as Mutt. It can be used from Mutt the > > same way as abook. > > The opackage description might need some review by debian-l10n-english > (use of "your"). Apart from that no specific advice abou tthe > package..:-) signature.asc Description: Digital signature
Bug#773250: linux-image-3.18.0-trunk-amd64: USB keyboard not recognized at the time cryptsetup prompt shows up
It seems that the 'xhci-hcd' module was split into 'xhci-pci' and 'xhci-platform' since kernel version 3.18. Adding the 'xhci-pci' module to initramfs fixes the issue for me. Ilias signature.asc Description: Digital signature
Bug#797068: goobook: depends on python-httplib2 v0.9, but crashes requiring v0.9.1.
On Thu, Aug 27, 2015 at 09:46AM, Matthew Moore wrote:
> Package: goobook
> Version: 1.9-1
> Severity: grave
> Justification: renders package unusable
>
> The package goobook depends on python-httplib2 0.9+dfsg-2, but goobook
> the program has python-httplib2 0.9.1 as a requirement. This renders
> goobook unusable.
Hi Matthew,
This is a bug in the latest package of python-oauth2client[1] (#794312).
You can see that goobook correctly depends on httplib2>=0.9
(file '/usr/share/goobook/goobook-1.9.egg-info/requires.txt') but
python-oauth2client depends on httplib2>=0.9.1 which doesn't exist in
Debian
('/usr/lib/python2.7/dist-packages/oauth2client-1.4.12.egg-info/requires.txt')
Until that bug is fixed, you can try and downgrade the
python-oauth2client package to its previous version. You can also edit
the above file and relax the dependency requirement for the httplib2
package but keep in mind that this may cause some problems with the
oauth2client package.
I will leave this bug open until #794312 has been fixed.
Thanks,
Ilias
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794312
signature.asc
Description: Digital signature
Bug#776482: ITA: suckless-tools
Control: retitle -1 ITA: suckless-tools -- simple commands for minimalistic window managers Control: owner -1 ! I would like to adopt the suckless-tools package. I will try to prepare a new version of the package in the next few days and then request for a sponsorship. Many thanks to Vasudev Kamath for his great work so far. Cheers, Ilias signature.asc Description: Digital signature
Bug#737063: suckless-tools: dmenu crashes on LANG=eo.UTF-8
Hi Walter, Could you please check whether this bug is still present in the newer version of dmenu (dmenu-4.6 on suckless-tools version 41-1)? Thanks, Ilias
Bug#802217: dmenu -fn doesn't change font anymore
Control: tags -1 + upstream Hi Yuri, On Sun, Oct 18, 2015 at 03:49PM, Yuri D'Elia wrote: > In the last update, dmenu doesn't seem to actually use the supplied font > argument anymore. > > I was using an X11 font spec (-*-terminus-medium-*-*-*-16-*-*-*-*-*-*-*), > which > stopped working. It seems that dmenu has stopped using the X Logical Font Description (XLFD) format for specifying a font. Instead, it is now using the X FreeType (XFT) format. Can you please try the following: $ dmenu -fn "Terminus:size=16" > I tried now also with some other formats (xft/etc), but I realized I can > actually supply garbage to -fn, dmenu doesn't even complain. You are right. dmenu doesn't complain and instead falls back to the default font (which is monospace). I will report this upstream. Thanks, Ilias
Bug#815195: Please add Ilias Tsitsimpis as a DM
Package: debian-maintainers Severity: normal Hi, please add my key, AD70 2001 13F0 D159 8485 04AB 0098 F613 1EB8 6413, to the Debian Maintainers keyring. The jetring changeset is attached. Thanks, Ilias Comment: Add Ilias Tsitsimpis as a Debian Maintainer Date: Fri, 19 Feb 2016 23:30:03 +0200 Action: import Recommended-By: Apollon Oikonomopoulos Agreement: https://lists.debian.org/debian-newmaint/2016/02/msg00016.html Advocates: https://lists.debian.org/debian-newmaint/2016/02/msg00017.html Data: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 mQINBFVVt30BEACcBjRz8BQV4Ab0FeWdjWZyOoz5SlsSY/kLGa/7y7Kx/F6Js++I 2iluAXYFw3pl7qACWBxzUWb+rJsi7rO9GInaiugWVLybn6HWfkpGXZSSeS5MRN19 yuGw84eGfxTxYBqjBPmKUk7Z+DTVGqee4SrYfylUklfzzcxRGBoAQO1IFa2pVIfa n10tQfE/qstBV/bB5//TKWixWo4Y56/BR5YJK/KKIM8GZ3Ta790iJMEd+Z0c2ZQ3 V/IN6zhNdnD2KgSjbRPkOBO+ZSd9nuBeiizt+iyKaNnG+VCFTuu09J+aUJ+GlTRI gHUygCOxLDcftptycxDaZbF1T1rlKmzegEcE2fFIFptPqzEXw7QqZeAlDTxkG42I lbUEC17RxLrsdEQc4bMfnB/XGRpUM+/HAw/9afH4MoSkud6ZCZvgrw+MkLdVu3A9 VFiH6xOzblmTvf31oQ+pb8jrmiklNWcGjEn+XXwvtgZVX2ABa9DFAZgjnaM6bPf8 dgAdmxS6WV7g4vM5UZhWvLHttChZWjKOFNWH2gAyvY2lrlL2t35NdZEsnyE4hUqs CzK4Zv915n9XBlvvtWPu0tbw7Th9UxhqJiGNIT+XOjWqzlKhrE7f22YpvoawW1i/ H7e1kfBRtdPX+QGppuSh4anDDYUOE+PgcQZFw+GwVWBsBv9aLYvY9oCZVwARAQAB tClJbGlhcyBUc2l0c2ltcGlzIDxpLnRzaXRzaW1waXNAZ21haWwuY29tPokCNwQT AQoAIQUCVVW3fQIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRAAmPYTHrhk E6yZD/93+EbhuKszjCPwXNnPlOqDw4kshmeGYDcMIxFGkF75OAY2srNVcEscRmBB gzlF3opKFtwpn9KJpET/Y76vPX4dvOXtFxuscUOTZybRPAUpPPREEW7DEzODI3uA OEQulpLucPaoAX0SU3kNbszPAE6qRAx7Z/Cuc/A1Pf+Pwh41B6uXjARIZfH2v/4m F4hSokqC86Ey856tuJgd/QaLCoEMhLfAxUIAfe5ai6i5ZlL0jVz9IWrK1hSnAZGi FD2Dp/kZEegeqeKMOBcQ91wlJ2TPaWGOqyVNODgkwlyJO4f9lho5uj2GETNZCsjM XCTTq1stGDXRHIfG8uHnHCLUv97o5MyACq6iWBSNj6DfIa0vcbkzwM2gCwVYapaD TMe16GdGwfIq/4e22JV4Z5o2NESI9+UjWTjGlynSEjFTo3LaEnQ5VxcNdFI+19R1 SpD1a5lOwyuS72l8jwc8pPcie1JLV1DocKzrkRM8Fw30BnVPWicdVGlKQlPcnvW+ 99Y7NbiNEM+yxeggfAF6hl/OU6cR9FaMoqdHZwdV3O9QFaJTE8d8ODaWtbpVsLbk 4dtuJN00RdQDfZ/kNHFX8gmR+mDYwUEQh6M24xyA04ORL17CdfSemCkfvXeNsoTW 4Fqe3Cpcc8jvSynY5+h3QNhplcor0BZvIbFZhWlw/uwGTE0qeIkCHAQQAQoABgUC VVmdUgAKCRBvuJC6JfPj7goBD/9yHRBybjjo9MAVOozOniszASV1GrBUJOQ/MvAt peFQCn09GrdjutvM16uNyBw4OI+9KWjOJDdlHA81b+++I2yfDVO+8uz9Mv/DLOiu 7968RyaJFXinOkaFZzMncybbCsKTOiLLsEsar/nWnN/GzSIzblDzuL0HbfFKQzxd jEif1jBINIzVPUHSjSpYmp5eied/6y6BnxPQt67Ne7q9CJIlDuRIfnICcYlSvKn5 bhqrcbiqnbl8M5xxu9ZUtg6g4OgjWC1PK3EIX5Y4y7uErm7++47XzCcYZz1iPFDK akqMGcqUR7uinu51BXsS/80thJ5qbMkzvoilmp7tHkBaluUD3tWYFZvkLSkRTiAi 8Vf+ux2J3ROpaqPysezpBl9o3k7cVVpkJi80c8he2wdUFPFU//jA0ftYaL20uQnG FpzKjXd+p+Ccpt9YUx5+gU4MHqmwzfIqQZr13WqKfzJ/b+57MYbn4mYi27UXbu3G aoHNpDp1OOUlt3OTpWuXhdvx1D1ZBUIHNjKrlBjYb+OfWUuLScjVxyrRjZvkI5zS EaSqYsd9/VhgB1B4wxBj6MzvlmmpgUizJI4tor6zbIHBG9WqWbsFsB0fvy4ail1h ADmQr49u+XfL7HWD9LTkoF19cCO1cavI8ERyZL1URlWiBU9DmAGwNfvYeghMf8ac FFEDJokCHAQQAQgABgUCViqUbwAKCRD1GxjHICSCJLnPD/4qPyF7iOBKurYb4jRC F6xwgiicA6O8qVTjP4JrmuPD2KjwgFiN6jZS7Q+HwLpLzUN3MOXZ/UDT3TJbjNNT lRq3pGp0GlpG0a6ahmcduuIEJix1EkhL+ZAMCmaDQYe3FZPlerS7yHTItHN3DIsN chQEOsTSXoFq9+Re6gueUrw7l1LPn234ZT1Vn8yDpl5CrWLnvJ1dnDDSvzCd12dX 12SJj4OzEekl6wO7SpV98Q4qHLxybuqyN2w8vImZBoninVyiJ+hv0YUG8ijkW1cD xQJ54FuMfXLU5gDv+FwpeqlNhYoABcKUPunINxbFxTB+eIv3vGUde0TihsauLXwM vNrdsYFprNrswOjWucXbRCdWVDG+U0b4MxEBrJYNyqXtIH7FT6a08Rj5/WRPvIZa v6fAxcs/5kp/Zl3HCpF4UtMsLhsR7F0iS9WMFyhD7GCKkryNOBofej8mXmgx55cy MYDBtxLRRpPWFPDLnVHCXMMGUkfxamLpdZCTPo9tvNG+4A9lK70HPhFxqbiIUEzK pRd6j3TcXUnB/yLPCol0jwC8vHQepiMQ+OSlnKVotEOfjVjo4EdhiliVug8QYqZI WJC65D7ZBnoiHLpegzwh9v+VnRqtVtVFUq6B7rFm4inW3b7UewX1rrdBO83gWP57 U9BT5QkY+b7rnePKdN/zVZ2oyYkCHAQQAQoABgUCVsTlbwAKCRDDvXgyaAwJbHl9 EACSJy639VIykpvXb2useggn33ZQpwWX9SubkA1zLz3sK9jgXteF2coRat+WUgDY YK2TT1tNH8TtzdU3uH+r5elLap0Nj84X8YTzejxzF11hoL9YtcflAeCjFdhgIRdt WsziB6zfojlQb0+pf3uyc/yIfQj7fYoUXiY7tz1p7y5IJA6psd9B+FWLeO2yhIOT BIlzMmEUsV+LNJNDxdDhhp2/TLDt/YAYpMnpYUQQaUE9cPxN5zLFfIrTaHTGqS/e oArNG93h8Ufd9wwhw/0td4dRRJCbW7C1zaWduvu+E43XuEKz6OONYsBMs5AZ0YpR lxxslWgb9m8p5/dg/u4Jf/giX76wBP/z/MmPQtZTT9tK7rUdOBG+aE9HGMipI4ki ac+g1aISqwOB9zOZ+D+9VyoqVsgH3Iu1qySAJdvKOCeay7hg0FEXH+WedGo48CKH 7SAggm+L6Nv10La1MXZ5PoPNCVnQBmXNqoN2ZUxwqIl+CnIMSHWwXzCYB6ObrWcA limglLSv9/ENoLIeQeuS6zNCEZx3B5NG2eu7RtYS+frC+hv0TQV9KPDrp/PAwq6d 9NBYLp17cZOt1S9y03K8p/sG2j+ON+mf/87coKRpuAH/A/qPGSnOiY7h975/2HLd DL1SG3IOXMoEP4hN154XPCn2Dn1ADmAErF8kv61fHWkQMIkCHAQQAQoABgUCVsTl gQAKCRCdC15bHuyPDis5EADWBkbrkM5kB377lqOQ9V5zj+4hHuuU88jP6q9xpkAn GssfF8Fz1PWtaTfVizQ/CS7uT584KPSQjCYD42YBIV/q+cNWFDUbQQQK9LXIvRUJ ukanaB8+fpa0Hm3/+qoMCK88IY02ahqg4ScD9b0S1uVhCbbXTge27JpBa8V56dvt YLiqtp1zDjOoRF3up8Mazpb/nT0WoNODfSOLr6ffk43uq1nQWKYqGhSDaRBKUhiS dJl/0993mSZl7/b8rgYS2b9aBX3R2eKvLZkewgle+/Zw2BxGMeZrfxrXqoRfPGj4 5MB4PIA3gw2Z75ChXLN57wddRCY08ej7WTVwPZIQOCKJlmdPGMd1oTiHTQxdNJQ3 gm79OdOEjMa85j2SEdHKGUVDLM8nJo2v7xLNrUomI/Q+U2oJGZbieEZ49i/FRkDW
Bug#816033: jessie-pu: package suckless-tools/40-1
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
Dear Release Team,
I would like to update suckless-tools in jessie in order to fix a bug in
the slock command. Slock is a simple X display locker.
Recently, slock v1.3 was released and it fixes a bug that can be
considered security related. More specifically, the cover window would
not resize correctly when new screens were added or the resolution was
changed while the lock was active, leading to a part of the screen
beings visible (information leakage). The upstream patch that fixes the
above bug can be found here[1].
I contacted the Security Team about this, and they decided this is
not severe enough to warrant a DSA.
Attached is a full debdiff.
Thanks,
Ilias
[1] http://git.suckless.org/slock/commit/?id=f5ef1b8ebda1
diff -Nru suckless-tools-40/debian/changelog suckless-tools-40/debian/changelog
--- suckless-tools-40/debian/changelog 2013-09-15 20:03:11.0 +0300
+++ suckless-tools-40/debian/changelog 2016-02-26 13:07:26.0 +0200
@@ -1,3 +1,14 @@
+suckless-tools (40-1+deb8u1) stable-proposed-updates; urgency=medium
+
+ * Set myself as the maintainer.
+Package has already been adopted in unstable (ITA: #776482).
+ * Patch slock to properly resize the cover window.
+The cover window now resizes correctly when new screens are added
+or the resolution is changed while the lock is active.
+ * Add libxrandr-dev to build dependencies (needed by the above patch).
+
+ -- Ilias Tsitsimpis Fri, 26 Feb 2016 13:05:03 +0200
+
suckless-tools (40-1) unstable; urgency=low
* Suggest surf which can be used with tabbed.
diff -Nru suckless-tools-40/debian/control suckless-tools-40/debian/control
--- suckless-tools-40/debian/control 2013-06-23 12:30:20.0 +0300
+++ suckless-tools-40/debian/control 2016-02-26 13:04:11.0 +0200
@@ -1,8 +1,7 @@
Source: suckless-tools
Section: x11
Priority: optional
-Maintainer: Vasudev Kamath
-Uploaders: Michael Stummvoll
+Maintainer: Ilias Tsitsimpis
Build-Depends: debhelper (>= 9),
libx11-dev,
libxinerama-dev,
@@ -10,6 +9,7 @@
dpkg-dev (>= 1.16.1.1),
libxss-dev,
libxft-dev,
+ libxrandr-dev,
libfreetype6-dev
Standards-Version: 3.9.4
Homepage: http://www.suckless.org
diff -Nru suckless-tools-40/debian/patches/0001_resize_lockscreen.patch suckless-tools-40/debian/patches/0001_resize_lockscreen.patch
--- suckless-tools-40/debian/patches/0001_resize_lockscreen.patch 1970-01-01 02:00:00.0 +0200
+++ suckless-tools-40/debian/patches/0001_resize_lockscreen.patch 2016-02-26 13:22:15.0 +0200
@@ -0,0 +1,76 @@
+Description: Patch slock to correctly resize the cover window
+ Resize the cover window when new screens are added or the resolution is
+ changed while the lock is active. This prevents potential information leakage.
+Author: Markus Teich
+Orig: upstream, http://git.suckless.org/slock/commit/?id=f5ef1b8eb555
+
+Index: suckless-tools-40/slock/config.mk
+===
+--- suckless-tools-40.orig/slock/config.mk
suckless-tools-40/slock/config.mk
+@@ -7,7 +7,7 @@ VERSION = 1.1
+ PREFIX = /usr/local
+
+ # includes and libs
+-LIBS = -lc -lcrypt -lX11 -lXext
++LIBS = -lc -lcrypt -lX11 -lXext -lXrandr
+
+ # flags
+ CPPFLAGS += -DVERSION=\"${VERSION}\" -DHAVE_SHADOW_H -DCOLOR1=\"black\" -DCOLOR2=\"\#005577\"
+Index: suckless-tools-40/slock/slock.c
+===
+--- suckless-tools-40.orig/slock/slock.c
suckless-tools-40/slock/slock.c
+@@ -14,6 +14,7 @@
+ #include
+ #include
+ #include
++#include
+ #include
+ #include
+ #include
+@@ -33,6 +34,9 @@ typedef struct {
+ static Lock **locks;
+ static int nscreens;
+ static Bool running = True;
++static Bool rr;
++static int rrevbase;
++static int rrerrbase;
+
+ static void
+ die(const char *errstr, ...) {
+@@ -146,8 +150,15 @@ readpw(Display *dpy, const char *pws)
+ }
+ }
+ llen = len;
+- }
+- else for(screen = 0; screen < nscreens; screen++)
++ } else if (rr && ev.type == rrevbase + RRScreenChangeNotify) {
++ XRRScreenChangeNotifyEvent *rre = (XRRScreenChangeNotifyEvent*)&ev;
++ for (screen = 0; screen < nscreens; screen++) {
++if (locks[screen]->win == rre->window) {
++ XResizeWindow(dpy, locks[screen]->win, rre->width, rre->height);
++ XClearWindow(dpy, locks[screen]->win);
++}
++ }
++ } else for (screen = 0; screen < nscreens; screen++)
+ XRaiseWindow(dpy, locks[screen]->win);
+ }
+ }
+@@ -199,6 +210,8 @@ lockscreen(Display *dpy, int screen) {
+ invisible = XCreatePixmapCursor(dpy, lock->pmap, lock->pmap, &color, &color, 0, 0);
+ XDefineCursor(dpy, lock->win, invisible);
+ XMapRaised(dpy, lock->win);
++ if (rr)
++ XRRSelectInput(dpy, lock->win, RRScreenChangeNoti
Bug#812108: problem upgrading from offlineimap 6.3.4 to 6.6.1
Control: tags -1 + patch Hi François, Nicolas, On Fri, Jan 22, 2016 at 03:03PM, franc...@avalenn.eu wrote: > On Wed, Jan 20, 2016 at 05:44:24PM +0100, Nicolas Sebrecht wrote: > > On Wed, Jan 20, 2016 at 01:56:24PM +0100, franc...@avalenn.eu wrote: > > > > I think that the problem comes from the use of nametrans in > > > visiblename for Maildir folder (commit > > > 6b2ec956cfe8e356d3ffd54eee34773deb73279f) because it lead to change > > > the FMD5 part of the filename. > > > > Looks sensible. This is a change introduced in the late 2011 and I don't > > remember everything from this time. I don't recall having to either > > use/provide any script for updates nor having the troubles you get. Thanks for describing the problem in detail. I, too, believe that this is a regression introduced by the above commit. Since OfflineIMAP on Debian stable is at version 6.3.4, more people are going to upgrade and face the above bug. Thus, I am interested in finding an easy way to resolve this. > > > I would like a way for offlineimap to either upgrade concerned > > > Maildirs on the fly or to have a way to ensure that proper manual > > > actions are done before using it. As offlineimap is often used in > > > crontabs this must be done during upgrade of package. > > > > I wonder if the big step foward from v6.3.4 to 6.6.1 (more than 4 years > > of development) could be the cause. Since it's a long time between > > releases, I wonder if temporary code to help moving forward could have > > been introduced and then removed within this gap. I couldn't find such a code in the history. It seems weird that nobody complained so far. > Indeed it is possible. > > I think that a workaround should be included in Debian packaging in > order for the upgrade to be the best experience possible. This > workaround could be a simple flag blocking any run of offlineimap and > this flag to be cleared by the user after reading the NEWS file. I have created a patch that hopefully will help here[1]. My plan is to include this to the next OfflineIMAP version in Debian, and state at the NEWS file that everyone who is upgrading from v6.3.4 should run $ offlineimap --verify-fmd5 || offlineimap --fix-fmd5 before the first use of the newer version. Could you review this, and/or verify that this is working correctly? @nicolas: Do you believe this should be included in the mainline OfflineIMAP repository (i.e., do you believe this has any other use other than upgrading from v6.3.4)? Cheers, Ilias [1] https://github.com/iliastsi/offlineimap/commit/8d07ec308e83665
Bug#809402: offlineimap: Ui cannot be specified anymore and passwords with % inside do not work
Control: retitle -1 offlineimap: Blinkenlights cannot be used with '-l' option Control: tags -1 + upstream Control: severity -1 normal Control: forwarded -1 https://github.com/OfflineIMAP/offlineimap/issues/293 Hi Raphael, On Thu, Jan 07, 2016 at 06:00PM, raph...@encr.es wrote: > Indeed the %% works, I tried it before, but I don't know why I didn't see it > was working ! Sorry for the noise > I used another UI, and all work except Blinkenlight Good to hear that it worked! I changed the title of the report in order to track the broken Blinkenlight UI and lowered the severity to 'normal' since it is now working for you. Cheers, Ilias
Bug#810245: offlineimap: Cannot upload messages to Oracle Communications Messaging Exchange Server anymore
Control: retitle -1 Support for server BINARY mode is broken Control: reassign -1 python-imaplib2 2.53-1 Control: affects -1 + offlineimap Hi Benedikt, According to upstream, this is a bug in the imaplib2 Python module[1]. It seems that its implementation of BINARY mode is broken, which causes the error message you are seeing: "BAD Missing required argument to Append command". I have reassigned this bug report to Debian's python-imaplib2 package. Cheers, Ilias [1] https://github.com/OfflineIMAP/offlineimap/issues/284
Bug#810119: GSSAPI/Kerberos authentication broken
Control: tags -1 + help Hi Guido, On Wed, Jan 06, 2016 at 05:25PM, Guido Günther wrote: > Hi, > the recent upgrade broke Kerberos authentication like: > > GSSAPI authentication failed: AUTHENTICATE command error: BAD > ['Authentication aborted by client.']. Data: IDBA2 AUTHENTICATE GSSAPI Thanks for reporting this. Unfortunately I am not using the Kerberos authentication mechanism so I am not able to debug this. Still, it would be very helpful if you could provide the debug logs and also if you could git bisect in order to find the patch that introduced this bug. Upstream may know more about this, so we must probably forward this report[1]. I can do it for you if you like, but since I cannot reproduce it, you would have to take it from there in order to provide additional information and debug logs. Cheers, Ilias [1] https://github.com/OfflineIMAP/offlineimap
Bug#671271: Folder '.'
On Sat, Jan 02, 2016 at 11:44AM, Andreas Kloeckner wrote: > Hi there, > > I just encountered this as well, and the workaround did work for me, > too. That said, as you can see in Stefano's error message (mine is the > same), it is trying to create a folder for '.' (the current directory?) > with an empty folder name, which dovecot (my IMAP server) is flat-out > refusing. It seems within its right to refuse this--the request seems > bogus, and it feels like something is wrong on offlineimap's side. Hi Andreas, There is a patch[1] that seems related to the above problem. Since I cannot reproduce it, could you please test this patch and verify that it is working. Cheers, Ilias [1] https://github.com/OfflineIMAP/offlineimap/pull/321
Bug#812108: problem upgrading from offlineimap 6.3.4 to 6.6.1
On Fri, Mar 04, 2016 at 12:11PM, Nicolas Sebrecht wrote: > On Fri, Mar 04, 2016 at 09:50:16AM +0100, franc...@avalenn.eu wrote: > > On Sun, Feb 28, 2016 at 07:29:02PM +0100, Nicolas Sebrecht wrote: > > > > I guess this might be confusing or make bad things (including data loss) > > > if applied on mails that has moved from a folder to another one without > > > a full filename change because this might lead to UID conflicts. > > > > Indeed at first glance patch seems sound but this potential UID > > conflicts annoys me. Is it possible to retrieve the older FMD5 (before > > the change of using nametrans) and replace only those matching the old > > one ? > > Theorically, I believe that's possible to re-introduce the old algo to > re-hash the old FMD5. IIRC the old algo was using the local folder name in order to compute the FMD5. So, it is relatively easy to check if the current FMD5 matches that of the local folder name and only then change it to the new one. This will indeed provide extra insurance against potential UID conflicts, but at the same time limit the patch to only those cases where one needs to upgrade from a version older than v6.3.5. I still cannot find another usage for the above patch (i.e., other cases where FMD5 has been modified and needs fixing), so, if you like, we may go that way (and change the name of the flag to something like --migrate-fmd5-using-nametrans). If we choose to leave it as is, I will make sure that at least all messages in the folder have the same FMD5 before renaming them (otherwise we end up with UID conflicts for sure). > However, I'm not much worried. The conflicts would only appear in the > very edge-case when the user runs the fix while unexpected filemane > changes happened since the previous sync. I'd say this edge-case would > not worth the trouble in the code. If you worry about that, it's enough > to add a warning before fixing the hashes. Something like: > > "Ensure to dispose a proper backup of both the cache and the Maildir > before running this fix. Be aware that if you made unexpected changes > to filenames in the maildir (behind OfflineIMAP's back) since your > previous sync, bad things might occur. > > Continue? (y/n)" Indeed, the edge-case will occur if the user happens to move a message since the previous sync. But as rare as this may seems, the results are very bad (UID conflicts) and users are very sensitive with their emails. I understand that there is no algorithm that will work for everyone, hence, we will make sure that they have read the blog-post and made a backup. > Either way would still be much better than the current alternatives > where users have to find the proper fix by themselves and possibly do > worse things. > > Also, I may update the blog post written by François at > > http://www.offlineimap.org/configuration/2016/02/12/debian-upgrade-from-jessie-to-stretch.html > > if none of you intend to do it. I will update the patch and send a pull request (hopefully by the weekend). Cheers, Ilias
Bug#812108: problem upgrading from offlineimap 6.3.4 to 6.6.1
On Fri, Mar 04, 2016 at 01:36PM, Nicolas Sebrecht wrote: > On Fri, Mar 04, 2016 at 01:49:29PM +0200, Ilias Tsitsimpis wrote: > > I will update the patch and send a pull request (hopefully by the weekend). > > Thank you for working on this Ilias! I sent the pull request[1]. I successfully did a migration from version 6.3.4 to 6.6.1. Please review and/or test. I tried to find a way for this to automatically happen when OfflineIMAP detects that the user is upgrading from an older version (just like the LocalStatus cache is upgraded) but the only think that came into my mind is to accept both FMD5 values as valid. If anyone has any better idea, I would be happy to try and implement it. Cheers, Ilias [1] https://github.com/OfflineIMAP/offlineimap/pull/314
Bug#180184: [weird] header only mode
Control: tags -1 + upstream wontfix Control: forwarded -1 https://github.com/OfflineIMAP/offlineimap/issues/224 Hello Joey, Upstream has closed this bug report as wont-fix. Sorry, Ilias
Bug#789625: offlineimap: please deliver to 'new' without info suffix (for notmuch compatibility)
Control: tags -1 + upstream Control: severity -1 wishlist Control: forwarded -1 https://github.com/OfflineIMAP/offlineimap/issues/80 Hello Tomasz, Upstream seems to believe that this is not a bug, so I am changing its severity to wishlist. Feel free to change it back if you think otherwise. Cheers, Ilias
Bug#670872: offlineimap: There appears to be a memory leak somewhere
Control: tags -1 + upstream Control: forwarded -1 https://github.com/OfflineIMAP/offlineimap/issues/203 Control: severity -1 important Hi! OfflineIMAP used to retain the messagelist caches even after having processed a folder. This means that memory consumption used to grow linearly with the number of processed folders. This has been fixed in version v6.5.7 by the following commit: commit 29e9b7ab39c0f1589814d451204a105067f490ea Author: Giovanni Mascellani Date: Sun Jan 5 16:07:03 2014 +0100 Drop caches after having processed folders. Since the situation appears to have been improved, I am going to downgrade this bug's severity to 'important' in order to allow the new version to migrate to testing. Feel free to change it back if you think this is wrong. Cheers, Ilias
Bug#679416: Offlineimap duplicates messages
Control: tags -1 + upstream Control: forwarded -1 https://github.com/OfflineIMAP/offlineimap/issues/174 Control: severity -1 important Hello Ryan, Upstream is tracking this bug and seems to believe that it is caused by the IDLE feature. From the attached offlineimaprc file, I can see that you are indeed using this feature. Since OfflineIMAP states that "IDLE support is incomplete and experimental. Bugs may be encountered.", and there exists a simple solution to this bug (i.e., disable IDLE feature), I am going to downgrade this bug's severity to 'important' in order to allow the new version to migrate to testing. Feel free to change it back if you think this is wrong. Cheers, Ilias
Bug#809402: offlineimap: Ui cannot be specified anymore and passwords with % inside do not work
Hi Raphael, On Wed, Dec 30, 2015 at 10:50AM, Raphael wrote: > Dear Maintainer, > > Since upgrade to 6.6.0~rc3+dfsg1-1 and then 6.6.1+dfsg1-1, the ui = option > leads in segfault with : AttributeError: 'CursesLogHandler' object has no > attribute 'ui' I cannot reproduce this. I have 'ui = basic' and it is working without any problems. Could you please provide the offlineimaprc and or the command line arguments you are using? > Also I have a password with a % in it, and it's not working anymore, adding > quotes, a %% as it is said in the new doc or anything else. There is an open bug report about this[1] but the upstream is waiting for feedback from the submitter. Could you help them by providing the corresponding logs? Cheers, Ilias [1] https://github.com/OfflineIMAP/offlineimap/issues/235
Bug#873196: ImportError: No module named bundled_imaplib2
Hi, On Fri, Aug 25, 2017 at 03:02PM, Johannes Schauer wrote: > When I start offlineimap I get this exception: > > Error while trying to import system imaplib2: The provided imaplib2 version > '2.55' is not supported > Traceback (most recent call last): > File "/usr/bin/offlineimap", line 20, in > from offlineimap import OfflineImap > File "/usr/share/offlineimap/offlineimap/__init__.py", line 20, in > from offlineimap.init import OfflineImap > File "/usr/share/offlineimap/offlineimap/init.py", line 29, in > import offlineimap.virtual_imaplib2 as imaplib > File "/usr/share/offlineimap/offlineimap/virtual_imaplib2.py", line 43, in > > from offlineimap.bundled_imaplib2 import * > ImportError: No module named bundled_imaplib2 > > > After upgrading python-imaplib2 to 2.57-1 it worked again. > > You might want to make the dependency on python-imaplib2 versioned. Thanks for pointing this out. The dependency on python-imaplib2 is already versioned, I just forgot to update it. I will upload a fixed version ASAP. Cheers, -- Ilias
Bug#873824: offlineimap: Offlineimap needs to call SSL_set_min_proto_version() for openssl
Hi, On Thu, Aug 31, 2017 at 12:47PM, ael wrote: > As reported on the mailing list, offlineimap can no longer > connect to the large number of insecure imap servers which still > use TLS 1.0 or TLS 1.2, over which users have no control. > This was the result of Kurt Roecke disabling those protocols > in the Debian openssl packages. > > He has now released version openssl (1.1.0f-5) which now allows > those protocols to be used in restricted circumstances. From the > changelog comment: > > "Instead of completly disabling TLS 1.0 and 1.1, just set the minimum > version to TLS 1.2 by default. TLS 1.0 and 1.1 can be enabled again by > calling SSL_CTX_set_min_proto_version() or SSL_set_min_proto_version()" > > So the Debian package must now call those procedures to enable > connection to many imap servers. > > As far as I have seen, Kurt did not comment about this on the > offlineimap thread, so this is my interpretation of what is required. > In any case, offlineiamp 7.1.2+dfsg1-2 is currently failing to connect > with the message as before > > OpenSSL responded: > [SSL: VERSION_TOO_LOW] version too low (_ssl.c:661) > *** Finished account 'ntlspam' in 0:00 If I understand correctly, you tested the above with the latest openssl (1.1.0f-5), is that right? If so, could you please try and set the `ssl_version` in offlineimap.conf file to tls1_1 or tls1, accordingly? This should force offlineimap to use the specified version. -- Ilias
Bug#872536: suckless-tools: dmenu fails to capture the keyboard from wayland windows
Hi Lorenz, On Fri, Aug 18, 2017 at 10:10AM, Lorenz Hübschle-Schneider wrote: > Dear Maintainer, > > since gnome-session 3.24.1-2 was uploaded to testing, Gnome uses wayland by > default. However, dmenu fails to capture the keyboard when a wayland window > (e.g. gnome-terminal) is in the foreground. It works fine when an X11 > (Xwayland) window (e.g. chromium) is active. Are there any plans to support > wayland? Wayland has been discussed a number of times in the suckless mailing list[1][2][3], and judging by the replies[4][5] it seems to me that the community has yet to decide if they are in favor of or against migrating to Wayland. There seems to be a port for dmenu[6], but requires that two additional libraries be packaged for Debian. There is also bemenu[7], which is written for Wayland and is inspired from dmenu. That said, it seems that it will take same time before dmenu could support Wayland. [1] http://lists.suckless.org/dev/1302/14575.html [2] http://lists.suckless.org/dev/1608/29977.html [3] http://lists.suckless.org/dev/1307/16905.html [4] http://lists.suckless.org/dev/1307/16928.html [5] http://lists.suckless.org/dev/1608/29978.html [6] https://github.com/michaelforney/dmenu [7] https://github.com/Cloudef/bemenu -- Ilias
Bug#872536: suckless-tools: dmenu fails to capture the keyboard from wayland windows
Control: tags -1 upstream On Tue, Sep 05, 2017 at 11:09PM, Lorenz Hübschle-Schneider wrote: > Thank you Ilias. It does seem like using an alternative implementation > on (X)Wayland is best for now. It's unfortunate that supporting Wayland > seems to be quite a lot of work. Due to a bunch of other > incompatibilities I disabled Wayland on my systems for now. Should I > leave this issue open for others or would you rather close it? Let's keep it open, until it has been resolved (or until the suckless community decides they won't support Wayland). Cheers, -- Ilias
Bug#873824: offlineimap: Offlineimap needs to call SSL_set_min_proto_version() for openssl
Control: notfound 873824 offlineimap/7.1.2+dfsg1-2 On Mon, Sep 04, 2017 at 07:56PM, ael wrote: > On Thu, Aug 31, 2017 at 06:38:46PM +0300, Ilias Tsitsimpis wrote: > [...] > > If I understand correctly, you tested the above with the latest openssl > > (1.1.0f-5), is that right? If so, could you please try and set the > > `ssl_version` in offlineimap.conf file to tls1_1 or tls1, accordingly? > > This should force offlineimap to use the specified version. > > Sorry for the delay. Yes, those options worked. Thank you. Glad it worked out! > I do find the documentation about the tls/ssl options in > /usr/share/doc/offlineimap/examples/offlineimap.conf.gz > pretty confusing, and had tried various configurations that I thought > should have worked. The documentation reads: Set SSL version to use (optional). It is best to leave this unset, in which case the correct version will be automatically detected. In rare cases, it may be necessary to specify a particular version from: tls1, tls1_1, tls1_2, ssl3, ssl23. I find the above to be quite easy to understand. Could you please elaborate on what confuses you so that we can improve the wording? -- Ilias
Bug#868128: stretch-pu: package python-imaplib2/2.55-1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Hi,
Due to cut'n'paste error, the python3-imaplib2 package in stretch
declares no dependencies (#867437). Do you believe this is something
worth fixing in stretch? Attached is the proposed diff.
Thanks,
--
Ilias
diff -Nru python-imaplib2-2.55/debian/changelog python-imaplib2-2.55/debian/changelog
--- python-imaplib2-2.55/debian/changelog 2016-09-09 20:11:08.0 +0300
+++ python-imaplib2-2.55/debian/changelog 2017-07-12 11:37:15.0 +0300
@@ -1,3 +1,10 @@
+python-imaplib2 (2.55-1+deb9u1) stable-proposed-updates; urgency=medium
+
+ * Fix typo that resulted in missing dependencies for python3-imaplib2.
+Thanks to Adrian Bunk for reporting this (Closes: #867437)
+
+ -- Ilias Tsitsimpis Wed, 12 Jul 2017 11:37:15 +0300
+
python-imaplib2 (2.55-1) unstable; urgency=medium
* New upstream release.
diff -Nru python-imaplib2-2.55/debian/control python-imaplib2-2.55/debian/control
--- python-imaplib2-2.55/debian/control 2016-09-09 20:11:08.0 +0300
+++ python-imaplib2-2.55/debian/control 2017-07-12 11:36:39.0 +0300
@@ -20,7 +20,7 @@
Package: python3-imaplib2
Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
+Depends: ${python3:Depends}, ${misc:Depends}
Description: Threaded Python IMAP4 client (Python 3)
Python IMAP4 rev1 mail protocol client class using threads for parallel
operation, allowing full use of the IMAP4 concurrency features and to
Bug#864909: suckless-tools: slock in GNOME allows window view/kill etc
Hi! On Fri, Jun 16, 2017 at 11:22PM, Barak A. Pearlmutter wrote: > Under GNOME (Wayland), running slock works okay until you hit the MENU > key (the one that shows all the windows spread out and small, but with > all their glorious content clearly visible albeit dinky) at which point > one can look at what's displayed in the windows, or kill a window, or > even pull down a menu and pick something naughty. I am surprised slock even works under Wayland. slock uses XGrabKeyboard, and if I understand correctly, X11 grabs don't work with Wayland, because the Wayland window manager lives at a higher level that the X11 emulation layer. What could be done here, is to check whether slock runs under Wayland and prevent it from starting. Note that xscreensaver does the same thing. -- Ilias
Bug#614032: suckless-tools: should Provide dwm-tools
On Sat, Feb 19, 2011 at 01:19AM, Geoffrey Thomas wrote: > Package: dwm-tools > Version: 38-1 > > Hi, > > I have a site configuration metapackage that depends on dwm-tools to bring > in utilities that our users expect. While I agree that the package shouldn't > really be called dwm-tools (since we started installing it for xmonad users, > after all), it would be nice if dependencies on the old package name would > still work. > > Please add > Provides: dwm-tools > to the control file for suckless-tools. Hi, Sorry for taking so long to reply. This has gone unnoticed for so many years because it was reported against the non-existing dwm-tools package. Do you still have a use for suckless-tools providing dwm-tools as a virtual package? If not, I am leaning towards rejecting this change, as to not take up the dwm-tools name that can be used by another package in the future. Cheers, -- Ilias
Bug#870887: python-udatetime: FTBFS: Invalid RFC3339 date-time string
Hi Aaron, On Sat, Aug 05, 2017 at 09:11PM, Aaron M. Ucko wrote: > Builds of python-udatetime for a number of architectures failed, as > excerpted below (modulo some varation in elapsed time) and detailed at > https://buildd.debian.org/status/logs.php?pkg=python-udatetime&ver=0.0.12-1. > Specifically, these failures occurred on armel, armhf, mips, mipsel, > and the non-release architectures hppa, powerpc, ppc64, and sparc64. > I'm not sure offhand why those specific architectures encountered > these errors; I doubt the buildd's native timezone is relevant, since > I see a successful mips64el build at mipsel-manda01 and a failed > mipsel build at mipsel-manda03, which is presumably at the same data > center. > > Could you please take a look? It seems that an out-of-bounds read causes the above failures. I have prepared a patch[1] and will soon upload a new version. Thanks, [1] https://github.com/freach/udatetime/pull/20 -- Ilias
Bug#859478: offlineimap: 'maxage' comments are wrong, offlineimap DELETES your mails
On Tue, Apr 04, 2017 at 07:10PM, Cyril Brulebois wrote: > > This should be fixed in newer versions of OfflineIMAP. Could you please > > give it a try? > > Well, trying out new versions is something I can do, but it really doesn't > help with the fact that offlineimap in stable is responsible for data loss. You are right, that's why I didn't close this bug report. The patches that fix this bug should be: https://github.com/OfflineIMAP/offlineimap/commit/25513e90387 https://github.com/OfflineIMAP/offlineimap/commit/8096f6cd5bf Unfortunately, backporting them is not trivial since they introduce changes in the core logic of OfflineIMAP. Right now, I am considering uploading an updated version in stable, where the docs will mention that this feature should not be used, and there will also be a warning message in case it is used. Another option would be to completely disable this feature in stable (since it is broken and doesn't work as expected), but this may break older setups (and I would like to avoid this). What do you think? -- Ilias
Bug#853870: xmonad taking up all display space in workspace 1 hiding xmobar
Hi Colin, On Wed, Feb 01, 2017 at 05:31PM, Colin Gonzalez wrote: > Using xmonad and xmobar in xmonad workspace 1 puts xmobar in > background. When no program is running xmobar is visible, when program > windows are open in workspace 1, they take up all the wrokspace no > mather which layout, and makes it impossible to see and use xmobar. > However, other workspaces work fine. Using several configuration files > or none (default configurations) doesn't fix up the issue. Have you tried setting the `overrideRedirect' option of xmobar to False, as suggested in the documentation? http://projects.haskell.org/xmobar If you're running xmobar in a tiling window manager, you might need to set this option to False so that it behaves as a docked application. Defaults to True. Best, -- Ilias
Bug#842281: sbuild: --extra-repository cannot be used with --no-apt-update
Package: sbuild
Version: 0.72.0-2
Severity: normal
Tags: patch
Dear maintainer,
Since commit 0e71b40, `--extra-repository' cannot be used with
`--no-apt-update' (i.e., the extra repositories are not being used).
I have attached a patch that fixes the above for me, but since I have no
experience with the sbuild codebase, it is only provided as an example
(for instance, it does not take into account the extra repository keys).
Thanks for maintaining sbuild.
--
Ilias
diff --git a/lib/Sbuild/ResolverBase.pm b/lib/Sbuild/ResolverBase.pm
index e904243..64a3709 100644
--- a/lib/Sbuild/ResolverBase.pm
+++ b/lib/Sbuild/ResolverBase.pm
@@ -193,6 +193,26 @@ sub setup {
return 0;
}
}
+$self->run_apt_command(
+{ COMMAND => [$self->get_conf('APT_GET'), 'update',
+ '-o', 'Dir::Etc::sourcelist=' . $extra_repositories_list_file,
+ '--no-list-cleanup'],
+ ENV => {'DEBIAN_FRONTEND' => 'noninteractive'},
+ USER => 'root',
+ DIR => '/' });
+if ($? != 0) {
+return 0;
+}
+
+$self->run_apt_command(
+{ COMMAND => [$self->get_conf('APT_CACHE'), 'gencaches'],
+ ENV => {'DEBIAN_FRONTEND' => 'noninteractive'},
+ USER => 'root',
+ DIR => '/' });
+
+if ($? != 0) {
+return 0;
+}
}
# Now, we'll add in any provided OpenPGP keys into the archive, so that
Bug#842679: haskell-debian: FTBFS: ghc: panic! (the 'impossible' happened)
Control: reassign -1 ghc 8.0.1-8
Control: tags -1 + pending
On Mon, Oct 31, 2016 at 10:45AM, Chris Lamb wrote:
> Dear Maintainer,
>
> haskell-debian fails to build from source in unstable/amd64:
>
> [...]
>
> [34 of 37] Compiling Debian.GenBuildDeps ( Debian/GenBuildDeps.hs,
> dist-ghc/build/Debian/GenBuildDeps.o )
> ghc: panic! (the 'impossible' happened)
> (GHC version 8.0.1 for x86_64-unknown-linux):
> find_tycon
> Loc
> []
>
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
This should be fixed by the following patch (available on our repo):
| Subject: Avoid find_tycon panic if datacon is not in scope
|
| When using TH to splice expressions involving record field construction,
| the parent datacon may not be in scope. We shouldn't panic about this,
| because we will be renaming Exact RdrNames which don't require any
| disambiguation.
|
| Reviewers: austin, bgamari
| Reviewed By: bgamari
| Differential Revision: https://phabricator.haskell.org/D2321
| GHC Trac Issues: #12130
|
| Origin: upstream, https://git.haskell.org/ghc.git/commitdiff/694e0f3a08030
|
| Index: b/compiler/rename/RnPat.hs
| ===
| --- a/compiler/rename/RnPat.hs
| +++ b/compiler/rename/RnPat.hs
| @@ -636,7 +636,7 @@ rnHsRecFields ctxt mk_arg (HsRecFields {
| find_tycon :: GlobalRdrEnv -> Name {- DataCon -} -> Maybe Name {- TyCon
-}
| -- Return the parent *type constructor* of the data constructor
| -- (that is, the parent of the data constructor),
| --- or 'Nothing' if it is a pattern synonym.
| +-- or 'Nothing' if it is a pattern synonym or not in scope.
| -- That's the parent to use for looking up record fields.
| find_tycon env con
|| Just (AConLike (RealDataCon dc)) <- wiredInNameTyThing_maybe con
| @@ -648,8 +648,9 @@ rnHsRecFields ctxt mk_arg (HsRecFields {
|ParentIs p -> Just p
|_ -> Nothing
|
| - | otherwise
| - = pprPanic "find_tycon" (ppr con $$ ppr (lookupGRE_Name env con))
| + | otherwise = Nothing
| +-- This can happen if the datacon is not in scope
| +-- and we are in a TH splice (Trac #12130)
|
| dup_flds :: [[RdrName]]
| -- Each list represents a RdrName that occurred more than once
I hold off on the upload in order to see if GHC will finish compiling
on mips64el.
Best,
--
Ilias
Bug#842843: RM: rss2irc -- ROM; obsolete, unbuildable
Package: ftp.debian.org Severity: normal Dear FTP masters, Please remove the source package rss2irc. It hasn't seen an upstream release since 2014 and is unbuildable since Aug 2015. Thanks, -- Ilias
Bug#842281: sbuild: --extra-repository cannot be used with --no-apt-update
Hi Johannes, Thanks for looking into this. On Thu, Nov 10, 2016 at 03:22AM, Johannes Schauer wrote: > I would say that this is a feature instead of a bug. Imagine it were the other > way round and sbuild would run "apt-get update" even if --no-apt-update was > specified, then I would get another bug report "sbuild runs apt-get update > even > though --no-apt-update was given". I believe these are two different things. In my understanding, `--no-apt-update' means do not update sbuild's default archive. The patch I provided does exactly that. It updates the extra repository, but not the default one (this is also what used to happen before). > With what justification would you still run "apt-get update" even if > --no-apt-update was passed? I would've said that a user who uses > --extra-repositories just must not use --no-apt-update. Maybe sbuild should > even print a warning if they attempt to do so. I believe that there is value in using both `--no-apt-update' and `--extra-repositories', especially when the extra repository is a local archive. In fact, that is the case with one of the tools used within the Debian Haskell Group (pkg-haskell-tools[1]), and the reason I am reporting this. It seems to me that what is missing here, is a way to tell sbuild to not update the default archive, but also use the ones provided with `--extra-repositories'. pkg-haskell-tools uses the `--no-apt-update' flag to achieve this, but maybe this is not the right way to do this. What do you think? [1] https://packages.debian.org/sid/pkg-haskell-tools -- Ilias
Bug#845531: offlineimap: new upstream release 7.0.9
Hi Simon, On Thu, Nov 24, 2016 at 11:02AM, Simon McVittie wrote: > In the new upstream release of offlineimap, the blinkenlights UI > (offlineimap -u blinkenlights) seems to corrupt its display less than > in 7.0.8. It still corrupts its output after a while, but it's... less bad? > (This is a partial solution to #671087 and #809676) Yes I know, I was the one who submitted the patch upstream. Sorry for not having packaged it for Debian yet, I will do it ASAP. > I suspect that the most correct solution for this UI would be to take the > approach that is required by mainstream GUI toolkits like GTK+ > or Qt, namely doing all UI operations (in this case all tty interaction) > in a single "main thread", and having all other threads post events to that > main thread instead of manipulating the UI directly. I might look into > doing that refactor/rewrite one day, but for now, 7.0.9 seems to be > an improvement. The current implementation is indeed broken. I suspect it has always been that way, but recently became unusable due to a change in the ncurses API (hence, #809676). The latest version should fix that. It would be great if someone could do the rewrite. Upstream have stated they do not intend to work on this. Best, -- Ilias
Bug#809676: offlineimap: Blinkenlights UI flickery, slow, broken
Hi Neil, On Wed, Nov 09, 2016 at 03:35PM, Neil McGovern wrote: > That patch does seem to fix things. There's still occasional corruption > (see attached image) though that may be a different bug. Thanks for testing the patch. It is not supposed to fix the occasional corruption, but rather the flickerness caused by a change in the ncurses API. I intend to close this bug report with v7.0.9. Please open a new one about the occasional corruptions. Thanks, -- Ilias
Bug#844598: not fixed
Control: reopen -1 Control: retitle -1 Linker errors when using a stack-provided ghc Control: forwarded -1 https://github.com/commercialhaskell/stack/issues/2712 Control: notfixed -1 haskell-stack/1.1.2-6 Hi Joey, On Thu, Nov 24, 2016 at 05:01PM, Joey Hess wrote: > Still experiencing build failures using stack until I make the > workarounds to ghc's settings file described in this bug. > > ii ghc8.0.1-14 amd64The Glasgow Haskell Compilation > sy > ii haskell-stack 1.1.2-7 amd64The Haskell Tool Stack > > Packages using lts-6.12 fail to build. For example, > git://git.joeyh.name/keysafe.git My initial understanding was that Debian's ghc was at fault here, but now I see it is the other way around. It is the stack-provided ghc that fails. In fact, one solution may be to use the latest ghc provided by Debian. Of course, this is not possible for packages using lts-6.12. I re-opened this bug, and set it to track the upstream report. Best, -- Ilias
Bug#845732: RM: haskell-stack [mips mipsel] -- ROM; cannot be built due to dependencies
Package: ftp.debian.org Severity: normal Please remove haskell-stack from mips and mipsel, since it build-depends on haskell-src-exts which is marked as Not-For-Us on those archs. Thanks, -- Ilias
Bug#845731: RM: gitit [arm64] -- ROM; cannot be built, blocking migration
Package: ftp.debian.org Severity: normal Please remove gitit from arm64 since it cannot be built and blocks Haskell's migration. Thanks, -- Ilias
Bug#797166: Breaks with jQuery 1.11.3: $.browser is undefined
This has been fixed since v0.9.12: https://github.com/harvesthq/chosen/pull/950 Please consider updating your package. Best, -- Ilias
Bug#846279: ghc: Problems with Backspace, Delete and arrow keys
Control: tags -1 + moreinfo Hi Richard, On Tue, Nov 29, 2016 at 07:59PM, Richard Smith wrote: > Since upgrading to ghc 8.0.1, when trying to backspace user-entered text > (e.g. a getLine event) in a > running haskell program (whether compiled with this version of ghc, or > interpreted), the terminal > displays "^?" for backspace, "^[[3~" for delete and other codes for arrow > keys. This is the indented behavior of getLine. It has always been like this, and didn't change with ghc v8.0.1. > It appears to be previously reported, and resolved, here: > https://ghc.haskell.org/trac/ghc/ticket/2606 Please see comments 19 to 22 from the above ticket. They describe how getLine is supposed to work, and how to get the indented results using haskeline instead. Does the above resolve your issue? -- Ilias
Bug#846279: ghc: Problems with Backspace, Delete and arrow keys
Hi Richard,
On Wed, Nov 30, 2016 at 08:28PM, Richard Smith wrote:
> The issue is happening before getLine receives the user's input. So, suppose I
> have a basic function that asks for my name and then echoes it back to the
> terminal; if I make a typo while inputting my name and then try to backspace
> to
> correct, the console will display the "^?" characters. E.g.
Unfortunately, I cannot reproduce this. Backspace works as expected for
me for the following program:
$ echo "main = getLine >>= putStrLn" > Test.hs
$ ghc -o test Test.hs
using both v7.10.3 and v8.0.1.
Could you please try the following program in C:
== %><
#include
int main(void)
{
char s[32];
fgets(s, 32, stdin);
printf("%s", s);
return 0;
}
== ><%
Does backspace work in that case?
--
Ilias
Bug#839862: offlineimap: Missing Blinkenlights
Hi Neil, On Wed, Oct 05, 2016 at 08:14PM, Neil McGovern wrote: > After the last update in testing, it seems that the blinkenlights UI has > disappeared. > ERROR:root:UI 'Blinkenlights' does not exist, choose one of: machineui, > syslog, quiet, ttyui, basic > > If this is deliberate, then man offlineimapui should be updated. Thanks for reporting this. This is indeed a regression. I have created a patch[1] that hopefully fixes it. P.S. Did Blinkenlights UI work for you? There are a number of reports that it is not working correctly. Please see bugs #671087[2] and #809676[3], as well as their corresponding issues on Github. Any feedback is welcome :) Best, [1] https://github.com/OfflineIMAP/offlineimap/pull/381 [2] https://bugs.debian.org/671087 [3] https://bugs.debian.org/809676 -- Ilias
Bug#833191: offlineimap: Please add default value of sslcacertfile
Control: tags -1 wontfix Hi Reuben, On Tue, Aug 02, 2016 at 12:57AM, Reuben Thomas wrote: > As a bit of Debian integration, it would seem reasonable to add a default > value for sslcacertfile (/etc/ssl/certs/ca-certificates.crt). I am afraid this cannot be done easily, because OfflineIMAP distinguish between sslcacertfile having and not having a value. >From the docs: | sslcacertfile | | SSL CA Cert(s) to verify the server cert against (optional). | No SSL verification is done without this option. If it is | specified, the CA Cert(s) need to verify the Server cert AND | match the hostname (* wildcard allowed on the left hand side) | The certificate should be in PEM format. and also: | cert_fingerprint | | If you connect via SSL/TLS (ssl = yes) and you have no CA certificate | specified, OfflineIMAP will refuse to sync as it connects to a server | with an unknown "fingerprint". If you are sure you connect to the | correct server, you can then configure the presented server | fingerprint here. OfflineIMAP will verify that the server fingerprint | has not changed on each connect and refuse to connect otherwise. | | You can also configure fingerprint validation in addition to | CA certificate validation above and it will check both: | OfflineIMAP fill verify certificate first and if things will be fine, | fingerprint will be validated. This means that if Debian provides a default value for the sslcacertfile, then it is not possible to connect to a server without verifying its certificate (and thus rendering the cert_fingerprint option obsolete). That said, OfflineIMAP provides the special value OS-DEFAULT for the sslcacertfile option which will automatically determine the system-wide location of the standard trusted CA roots file. If you have any suggestion about how this could be fixed, please advice. In the meantime, I am marking this as WONTFIX. Best, -- Ilias
Bug#833191: offlineimap: Please add default value of sslcacertfile
On Thu, Sep 08, 2016 at 11:56AM, Reuben Thomas wrote: > On 8 September 2016 at 11:48, Ilias Tsitsimpis > wrote: > > This means that if Debian provides a default value for the > > sslcacertfile, then it is not possible to connect to a server without > > verifying its certificate (and thus rendering the cert_fingerprint > > option obsolete). > > Is it not possible for the user to unset sslcacertfile? I don't think it is possible to unset an option using Python's ConfigParser. We would have to use a special value (just like OS-DEFAULT) to denote that this option should be disabled. > If that were necessary in order to use just cert_fingerprint, that would be > an extra signal to the user that they are making their setup potentially > less secure. This should probably be discussed with the upstream. I don't think we should introduce a change like this in the Debian package. > > That said, OfflineIMAP provides the special value OS-DEFAULT for the > > sslcacertfile option which will automatically determine the system-wide > > location of the standard trusted CA roots file. > > > > That's a help, thanks (I've used it); perhaps it could be documented in > the man page? Currently, the man page does not document any of the available options in the configuration file. These are documented in the example file: /usr/share/doc/offlineimap/examples/offlineimap.conf.gz Maybe we could create an offlineimaprc man page, that would document the above options. -- Ilias
Bug#833191: offlineimap: Please add default value of sslcacertfile
On Thu, Sep 08, 2016 at 12:21PM, Reuben Thomas wrote: > On 8 September 2016 at 12:14, Ilias Tsitsimpis > wrote: > > > > > Currently, the man page does not document any of the available options > > in the configuration file. These are documented in the example file: > > /usr/share/doc/offlineimap/examples/offlineimap.conf.gz > > > > Maybe we could create an offlineimaprc man page, that would document the > > above options. > > It might be simpler and better simply to add a pointer to the examples > file to the man page. ACK. I have fixed that in the latest upload. -- Ilias
Bug#837159: ITP: python-udatetime -- Fast RFC3339 compliant date-time library
Package: wnpp Severity: wishlist Owner: Ilias Tsitsimpis * Package name: python-udatetime Version : 0.0.9 Upstream Author : Simon Pirschel * URL : https://pypi.python.org/pypi/udatetime * License : Apache 2.0 Programming Lang: C, Python Description : Fast RFC3339 compliant date-time library The udatetime module offers on average 76% faster datetime object instantiation, serialization and deserialization of RFC3339 date-time strings. It uses Python's datetime class under the hood so, code already using datetime should be able to easily switch to udatetime. All datetime objects created by udatetime are timezone aware. I plan to maintain this within the DPMT team.
Bug#837159: ITP: python-udatetime -- Fast RFC3339 compliant date-time library
Hi Thomas, On Fri, Sep 09, 2016 at 03:36PM, Thomas Goirand wrote: > On 09/09/2016 02:13 PM, Ilias Tsitsimpis wrote: > > The udatetime module offers on average 76% faster datetime object > > instantiation, serialization and deserialization of RFC3339 date-time > > strings. > > Faster than what? Sorry for not being clear here. Faster than Python's datetime module. See also https://github.com/freach/udatetime#benchmark. Best, -- Ilias
Bug#809676: offlineimap: Blinkenlights UI flickery, slow, broken
Hi Neil, On Thu, Oct 06, 2016 at 04:23PM, Neil McGovern wrote: > On Sun, Mar 13, 2016 at 09:01:11PM +0100, Christian Neukirchen wrote: > > > > Please try the proposed fix at > > https://github.com/OfflineIMAP/offlineimap/issues/290#issuecomment-196036356 > > > > The fix with upstream does improve matters, but you can still > occasionally see corruption in the characters printed. Could you please also try the patch at https://github.com/iliastsi/offlineimap/commit/d48663b9bf9 ? Thanks, -- Ilias
Bug#842029: haskell-devscripts-minimal: Extra operand in 'ln' command
Package: haskell-devscripts-minimal
Version: 0.12
Severity: normal
In install_doc_recipe() method we have:
| source=`find debian/${PKG}/${htmldir} -name "*.txt"`
| dest=debian/${PKG}${hoogle}${PKG}.txt
| run mkdir -p `dirname $dest`
| run ln -rs -T $source $dest
This will fail, in case $source contains more than one files.
As an example, for the haskell-shake package I get this:
| install_doc_recipe "libghc-shake-doc"
| Running mkdir -p debian/libghc-shake-doc/usr/share/doc/libghc-shake-doc/html/
| Running cd debian/tmp-inst-ghc/
| Running find ./usr/share/doc/libghc-shake-doc/html/ \! -name \*.haddock \!
-type d -exec install -Dm 644 \{\} ../libghc-shake-doc/\{\} \;
| Running mkdir -p
debian/libghc-shake-doc/usr/lib/ghc-doc/haddock/shake-0.15.10/
| Running cp -r
debian/tmp-inst-ghc/usr/lib/ghc-doc/haddock/shake-0.15.10//shake.haddock
debian/libghc-shake-doc/usr/lib/ghc-doc/haddock/shake-0.15.10/
| Running mkdir -p debian/libghc-shake-doc/usr/lib/ghc-doc/hoogle
| Running ln -rs -T
debian/libghc-shake-doc/usr/share/doc/libghc-shake-doc/html/CHANGES.txt
debian/libghc-shake-doc/usr/share/doc/libghc-shake-doc/html/shake.txt
debian/libghc-shake-doc/usr/lib/ghc-doc/hoogle/libghc-shake-doc.txt
| ln: extra operand
'debian/libghc-shake-doc/usr/lib/ghc-doc/hoogle/libghc-shake-doc.txt'
| Try 'ln --help' for more information.
--
Ilias
Bug#837575: jessie-pu: package suckless-tools/40-1+deb8u1
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
Dear Release Team,
I would like to update suckless-tools in jessie in order to fix a bug in
the slock command (CVE-2016-6866).
I have contacted the Security Team about this, and they decided this
is not severe enough to warrant a DSA.
Attached is a full debdiff.
Thanks,
Ilias
[CVE-2016-6866] https://security-tracker.debian.org/tracker/CVE-2016-6866
--
Ilias
diff -Nru suckless-tools-40/debian/changelog suckless-tools-40/debian/changelog
--- suckless-tools-40/debian/changelog 2016-02-26 13:07:26.0 +0200
+++ suckless-tools-40/debian/changelog 2016-09-12 17:25:07.0 +0300
@@ -1,3 +1,15 @@
+suckless-tools (40-1+deb8u2) stable-proposed-updates; urgency=medium
+
+ * CVE-2016-6866: Fix SEGV in slock when users account has been disabled.
+The screen locking application slock called crypt(3) and used the return
+value for strcmp(3) without checking to see if the return value of crypt(3)
+was a NULL pointer.
+If the hash returned by (getspnam()->sp_pwdp) was invalid, crypt(3) would
+return NULL and set errno to EINVAL. This would cause slock to segfault
+which then leaves the machine unprotected.
+
+ -- Ilias Tsitsimpis Mon, 12 Sep 2016 16:17:14 +0300
+
suckless-tools (40-1+deb8u1) stable-proposed-updates; urgency=medium
* Set myself as the maintainer.
diff -Nru suckless-tools-40/debian/patches/0002_fix-cve-2016-6866.patch suckless-tools-40/debian/patches/0002_fix-cve-2016-6866.patch
--- suckless-tools-40/debian/patches/0002_fix-cve-2016-6866.patch 1970-01-01 02:00:00.0 +0200
+++ suckless-tools-40/debian/patches/0002_fix-cve-2016-6866.patch 2016-09-12 16:09:57.0 +0300
@@ -0,0 +1,48 @@
+Description: Fix CVE-2016-6866
+ Fix SEGV in slock when users account has been disabled.
+ .
+ The screen locking application slock called crypt(3) and used the return
+ value for strcmp(3) without checking to see if the return value of crypt(3)
+ was a NULL pointer.
+ .
+ If the hash returned by (getspnam()->sp_pwdp) was invalid, crypt(3) would
+ return NULL and set errno to EINVAL. This would cause slock to segfault
+ which then leaves the machine unprotected.
+Author: Markus Teich
+Origin: upstream, http://git.suckless.org/slock/commit/?id=d8bec0f6fdc8
+
+Index: b/slock/slock.c
+===
+--- a/slock/slock.c
b/slock/slock.c
+@@ -85,7 +85,7 @@ readpw(Display *dpy)
+ readpw(Display *dpy, const char *pws)
+ #endif
+ {
+- char buf[32], passwd[256];
++ char buf[32], passwd[256], *encrypted;
+ int num, screen;
+ unsigned int len, llen;
+ KeySym ksym;
+@@ -118,7 +118,11 @@ readpw(Display *dpy, const char *pws)
+ #ifdef HAVE_BSD_AUTH
+ running = !auth_userokay(getlogin(), NULL, "auth-xlock", passwd);
+ #else
+-running = strcmp(crypt(passwd, pws), pws);
++errno = 0;
++if (!(encrypted = crypt(passwd, pws)))
++ fprintf(stderr, "slock: crypt: %s\n", strerror(errno));
++else
++ running = !!strcmp(encrypted, pws);
+ #endif
+ if(running != False)
+ XBell(dpy, 100);
+@@ -262,6 +266,8 @@ main(int argc, char **argv) {
+
+ #ifndef HAVE_BSD_AUTH
+ pws = getpw();
++ if (strlen(pws) < 2)
++ die("slock: failed to get user password hash.\n");
+ #endif
+
+ if(!(dpy = XOpenDisplay(0)))
diff -Nru suckless-tools-40/debian/patches/series suckless-tools-40/debian/patches/series
--- suckless-tools-40/debian/patches/series 2016-02-26 13:08:45.0 +0200
+++ suckless-tools-40/debian/patches/series 2016-09-12 16:01:21.0 +0300
@@ -4,3 +4,4 @@
2003_transparent-makefiles.patch
2004_use_system_searchpaths.patch
0001_resize_lockscreen.patch
+0002_fix-cve-2016-6866.patch
Bug#837904: offlineimap: sqlite status_backend: 'LocalStatusSQLiteFolder' object has no attribute 'purge'
Control: tags -1 fixed-upstream Hi Paul, On Thu, Sep 15, 2016 at 06:39PM, Paul Wise wrote: > Since the recent update I can no longer use offlineimap because it > crashes with the sqlite status_backend and there doesn't appear to be > any way to convert an existing status cache from the sqlite backend to > the plain text backend. > [...] > ERROR: Exceptions occurred during the run! > ERROR: While attempting to sync account 'some...@example.org' > 'LocalStatusSQLiteFolder' object has no attribute 'purge' > > Traceback: > File "/usr/share/offlineimap/offlineimap/accounts.py", line 263, in > syncrunner > self.__sync() > File "/usr/share/offlineimap/offlineimap/accounts.py", line 329, in __sync > remoterepos.sync_folder_structure(localrepos, statusrepos) > File "/usr/share/offlineimap/offlineimap/repository/Base.py", line 253, in > sync_folder_structure > src_repo.getsep(), status_repo.getsep())) > File "/usr/share/offlineimap/offlineimap/repository/LocalStatus.py", line > 97, in makefolder > folder.purge() This is due to the following commit[1]: | commit 038a433f69c5fae1631d00a81cba0b15e5038b32 | Author: Nicolas Sebrecht | Date: Mon Jul 25 14:39:11 2016 +0200 | | backport: sqlite: properly serialize operations on the databases Upstream tried to backport a fix, but it seems that the purge() method is not defined in version 6.7.0.3. Converting your status_backend to plain will not help here, since purge() method is not defined for this backend either. It was introduced by the following commit[2]: | commit 1410a391bcec3d500ee61f4c42371c6630d726e7 | Author: Nicolas Sebrecht | Date: Fri, 17 Jun 2016 19:47:37 +0200 | | Subject: [PATCH] avoid removing of data when user removed a maildir I will try to upload the latest version of OfflineIMAP ASAP. Best, Ilias [1] https://github.com/OfflineIMAP/offlineimap/commit/038a433f69c5fae1631d00a81c [2] https://github.com/OfflineIMAP/offlineimap/commit/1410a391bcec3d500ee61f4c42371c6630d726e7#diff-c23c6906c765513bcd9008c1b49f6746R91
Bug#832379: override: hledger:utils/extra
Package: ftp.debian.org Severity: normal Control: block 832263 by -1 Please change the section of the binary package 'hledger' to 'utils'. Thanks, -- Ilias
Bug#1054863: haskell-hsyaml: FTBFS: make: *** [/usr/share/cdbs/1/class/hlibrary.mk:153: configure-ghc-stamp] Error 25
Hi Jonas, On Fri, Oct 27, 2023 at 09:50PM, Lucas Nussbaum wrote: > > Error: hlibrary.setup: Encountered missing or private dependencies: > > base >=4.5 && <4.17 Can you please update haskell-hsyaml to version 0.2.1.2, which is the version we are currently tracking on our package-plan? This should also fix this bug and unblock stylish-haskell. Thanks, -- Ilias
Bug#1076332: RM: goobook -- ROM; abandoned upstream
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: goob...@packages.debian.org Control: affects -1 + src:goobook User: ftp.debian@packages.debian.org Usertags: remove Please remove package goobook from Debian. GooBook is officially dead, see the upstream announcement here [1]. [1] https://groups.google.com/g/goobook/c/Ee2NnNTFKig/m/22qkDxG_AAAJ Thanks, Ilias
Bug#1053686: pandoc: cannot fulfill the build dependencies
On Thu, Nov 16, 2023 at 10:16PM, Jonas Smedegaard wrote: > Quoting John MacFarlane (2023-11-16 19:25:17) > > Removing lua support would be most unfortunate! If you need help from > > upstream in getting things to work, let me know. > > I agree: Pandoc with its core scripting language disabled is a severely > crippled Pandoc. Understood, but I am not really sure how to move forward, since Pandoc doesn't fully support the latest Stackage LTS. I can help with packaging/upgrade libraries if you can provide the right set of libraries we need. -- Ilias
Bug#1053686: pandoc: cannot fulfill the build dependencies
On Fri, Nov 17, 2023 at 09:28AM, Ilias Tsitsimpis wrote: > On Thu, Nov 16, 2023 at 10:16PM, Jonas Smedegaard wrote: > > Quoting John MacFarlane (2023-11-16 19:25:17) > > > Removing lua support would be most unfortunate! If you need help from > > > upstream in getting things to work, let me know. > > > > I agree: Pandoc with its core scripting language disabled is a severely > > crippled Pandoc. > > Understood, but I am not really sure how to move forward, since Pandoc > doesn't fully support the latest Stackage LTS. I can help with > packaging/upgrade libraries if you can provide the right set of > libraries we need. I uploaded the following packages: * haskell-hslua-cli_v1.3.0-1, * haskell-hslua-module-doclayout_v1.1.0-1 * haskell-hslua-module-zip_v1.1.0-1 I believe the next step is to update pandoc to 3.0.1, so we can then package pandoc-lua-engine, pandoc-server and eventually pandoc-cli. Jonas, how can I help move this forward? Pandoc is the last blocker to finish the Haskell transition. -- Ilias
Bug#1056756: RM: haskell-aeson-compat -- ROM; deprecated
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: haskell-aeson-com...@packages.debian.org Control: affects -1 + src:haskell-aeson-compat Please remove haskell-aeson-compat from Debian. * It has no rev dependencies * The current version FTBFS * Deprecated in favor of haskell-aeson Thanks, -- Ilias
Bug#1056758: Removal notice: obsolete
Source: haskell-reform-hsp Version: 0.2.7.2-2 Severity: serious I intend to remove this package: * It has no rev dependencies * The current version FTBFS * Seems unmaintained; Last upload more than 3 years ago * It's not part of the latest Stackage LTS If you believe we should keep this package in Debian, please close this bug report. -- Ilias
Bug#1057154: pandoc: Disable Lua support on ppc* architectures
Package: pandoc Version: 2.17.1.1-3 Severity: normal Hi Jonas, As discussed on this [1] mail-thread on debian-haskell, GHC has a bug on ppc* architectures [2], and we cannot build HsLua on these architectures. As a workaround, I propose we disable Pandoc's Lua scripting engine on ppc* architectures. I believe Fedora has done the same [3]. [1] https://lists.debian.org/msgid-search/20231129074313.52gunbau7od3a...@iliastsi.net [2] https://gitlab.haskell.org/ghc/ghc/-/issues/23034 [3] https://bugzilla.redhat.com/show_bug.cgi?id=2172771#c14 Best, -- Ilias
Bug#1055626: cabal-install: pkg-config package gtk4-any, not found in the pkg-config database
Hi again, On Thu, Nov 09, 2023 at 08:53PM, Ilias Tsitsimpis wrote: > I tried this in a clean unstable environment and cannot reproduce it. > Here is what I did: > > $ docker run --rm -ti debian:sid > # apt update > # apt upgrade -y > # apt install -y cabal-install pkg-config libgtk-4-dev libatk1.0-dev > # cabal update > # cabal get gi-gtk-4.0.8 > # cd gi-gtk-4.0.8 > # cabal build > > The above builds gi-gtk-4.0.8 successfully. Maybe something is wrong > with your environment? I am going to close this bug report, since it looks like something is wrong with your environment. Please re-open if this persists. Best, -- Ilias
Bug#1054596: Removal notice: obsolete
Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: retitle -2 RM: haskell-binary-parsers -- ROM; obsolete Control: severity -2 normal On Thu, Oct 26, 2023 at 06:16PM, Ilias Tsitsimpis wrote: > I intend to remove this package: > > * It has no rev dependencies > * The current version FTBFS > * Seems unmaintained; Last upload more than 4 years ago > * It's not part of the latest Stackage LTS Dear FTP masters, please remove haskell-binary-parsers from unstable. -- Ilias
Bug#1054498: Removal notice: obsolete
Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: retitle -2 RM: haskell-butcher -- ROM; obsolete Control: severity -2 normal On Tue, Oct 24, 2023 at 06:30PM, Ilias Tsitsimpis wrote: > I intend to remove this package: > > * It has no rev dependencies > * The current version FTBFS > * It's not part of the latest Stackage LTS > > If you believe we should keep this package in Debian, please close this > bug report. Dear FTP masters, please remove haskell-butcher from unstable. -- Ilias
Bug#1018197: Removal notice: obsolete
Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: retitle -2 RM: haskell-cprng-aes -- ROM; obsolete Control: severity -2 normal On Sun, Oct 22, 2023 at 07:19PM, Adrian Bunk wrote: > #1022681 has now been fixed. Dear FTP masters, please remove haskell-cprng-aes from unstable. -- Ilias
Bug#1018196: Bug#1018197: Removal notice: obsolete
Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: retitle -2 RM: haskell-cipher-aes -- ROM; obsolete Control: severity -2 normal On Sun, Oct 22, 2023 at 07:19PM, Adrian Bunk wrote: > #1022681 has now been fixed. Dear FTP masters, please remove haskell-cipher-aes from unstable. -- Ilias
Bug#1054316: Removal notice: obsolete
Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: retitle -2 RM: haskell-czipwith -- ROM; obsolete Control: severity -2 normal On Sat, Oct 21, 2023 at 08:07PM, Ilias Tsitsimpis wrote: > I intend to remove this package: > > * It has no rev dependencies > * The current version FTBFS with GHC 9.4 > * It's not part of the latest Stackage LTS > > If you believe we should keep this package in Debian, please close this > bug report. Dear FTP masters, please remove haskell-czipwith from unstable. -- Ilias
Bug#1054356: Removal notice: obsolete
Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: retitle -2 RM: haskell-data-tree-print -- ROM; obsolete Control: severity -2 normal On Sun, Oct 22, 2023 at 04:28PM, Ilias Tsitsimpis wrote: > I intend to remove this package: > > * It has no rev dependencies > * The current version FTBFS > * Seems unmaintained; Last upload more than 5 years ago > * It's not part of the latest Stackage LTS > > If you believe we should keep this package in Debian, please close this > bug report. Dear FTP masters, please remove haskell-data-tree-print from unstable. -- Ilias
Bug#967519: haskell-diagrams-gtk: depends on deprecated GTK 2
Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: retitle -2 RM: haskell-diagrams-gtk -- ROM; obsolete Control: severity -2 normal On Mon, Jul 24, 2023 at 01:43AM, Simon McVittie wrote: > It seems nothing in Debian depends or build-depends on > haskell-diagrams-gtk. Is it still useful? If not, can we remove it from > unstable before the Debian 13 release, to discourage the addition of > new software that depends on GTK 2? Dear FTP masters, please remove haskell-diagrams-gtk from unstable. -- Ilias
Bug#1054357: Removal notice: obsolete
Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: retitle -2 RM: haskell-fclabels -- ROM; obsolete Control: severity -2 normal On Sun, Oct 22, 2023 at 04:31PM, Ilias Tsitsimpis wrote: > I intend to remove this package: > > * It has no rev dependencies > * The current version FTBFS > * It's not part of the latest Stackage LTS Dear FTP masters, please remove haskell-fclabels from unstable. -- Ilias
Bug#1054319: Removal notice: obsolete
Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: retitle -2 RM: haskell-ixset -- ROM; obsolete Control: severity -2 normal On Sat, Oct 21, 2023 at 08:38PM, Ilias Tsitsimpis wrote: > I intend to remove this package: > > * It has no rev dependencies > * The current version FTBFS (depends on broken haskell-syb-with-class) > * It's not part of the latest Stackage LTS Dear FTP masters, please remove haskell-ixset from unstable. -- Ilias
Bug#1054358: Removal notice: obsolete
Control: clone -1 -2 Control: reassign -2 ftp.debian.org Control: retitle -2 RM: haskell-mbox -- ROM; obsolete Control: severity -2 normal On Sun, Oct 22, 2023 at 04:33PM, Ilias Tsitsimpis wrote: > I intend to remove this package: > > * It has no rev dependencies > * The current version FTBFS > * Seems unmaintained; Last upload more than 5 years ago > * It's not part of the latest Stackage LTS Dear FTP masters, please remove haskell-mbox from unstable. -- Ilias
