Bug#1017835: elpa-evil: emacs 28.1 upgrade fails with byte compiling elpa-evil

[Stefano Zacchiroli]

On Sun, Aug 21, 2022 at 12:29:21PM +0200, Gregory Mounie wrote:
> Upgrading to emacs-gtk 28.1 fails with byte co[m]piling elpa-evil*
[...]
> In toplevel form:
> evil.el:133:1: Error: Wrong number of arguments: (3 . 4), 2
> ERROR: install script from elpa-evil package failed

Confirmed, I'm seeing this as well and it's breaking the overall
installation of emacs-28 (if you've elpa-evil installed).

As a workaround, the following works: remove the "elpa-evil" Debian
package, install the same package via "M-x package-install" and then
"evil". That will give you evil version 1.15.0, which is compatible with
Emacs 28. (But also get you out of the comfort zone of Debian packages,
you've been warned!)

Hope this helps,
Cheers

Bug#991215: local copy of rust book does not allow to hide the navigation bar as the online version does

[Stefano Zacchiroli]

Package: rust-doc
Version: 1.52.1+dfsg1-1~exp3
Severity: minor
File: /usr/share/doc/rust-doc/html/book

Heya, it looks like the HTML version of the Rust book shipped with rust-doc
lacks some of the (CSS/JS) elements of the version of the book online at
https://doc.rust-lang.org/book/ . Most notably, the top-left button that allow
to toggle the left navigation bar is missing when browsing the local HTML
version.

That is annoying as, on small screens the left navigation bar can take a lot of
space and it would be nice to be able to hide it.

I've noticed the following error in the javascript console when browsing the
local version:

  book.js:572 Uncaught ReferenceError: ClipboardJS is not defined
at clipboard (book.js:572)
at book.js:594

which I do not get when browsing the live version on rust-lang.org.  (Even if
the book.js is installed and properly resolvable from the HTML page.)

Thanks for maintaining rust(-doc) in Debian!

Cheers

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rust-doc depends on:
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4.1
ii  fonts-open-sans 1.11-1.1
ii  libjs-highlight.js  9.18.5+dfsg1-1
ii  libjs-jquery3.5.1+dfsg+~3.5.5-7
ii  libjs-mathjax   2.7.9+dfsg-1

Versions of packages rust-doc recommends:
ii  cargo-doc  0.47.0-3

rust-doc suggests no packages.

-- no debconf information

Bug#988127: neomutt hangs for minutes while checking S/MIME signed mails

[Stefano Zacchiroli]

retitle 988127 neomutt hangs for minutes while checking S/MIME signed mails
found 988127 20201127+dfsg.1-1.1
thanks

Heya, I've cloned/reassigned this issue from mutt to neomutt, because it
does happen to me with neomutt right now (version 20201127+dfsg.1-1.1 ),
exactly as described in the original mutt bug report.

Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#961638: proposal: stocat - probabilistic cat

[Stefano Zacchiroli]

On Tue, May 26, 2020 at 11:39:42PM +0200, Stefano Zacchiroli wrote:
> I'm hereby proposing the inclusion of the attached "stocat" utility to
> moreutils. It's like cat, but output lines with a given probability,
> defaulting to 10%. It's very useful for random sampling (and *much*
> more efficient at that than using "shuf" which is unwieldy on very
> large inputs) and, while it can be implemented instead with awk/perl
> oneliners, those oneliners aren't very mnemonic and are error prone.

Heya, as I haven't heard back about this, but others have asked me about
how to best use stocat, I've now released it as an independent tool
here:

  https://gitlab.com/zacchiro/stocat

I'm happy to reconsider if/when it gets integrated into moreutils.

Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#982625: fails to authenticate with "TypeError: sequence item 2: expected str instance, bytes found" error

[Stefano Zacchiroli]

Hi Sudip, thanks for your reply,

On Fri, Feb 12, 2021 at 05:00:04PM +, Sudip Mukherjee wrote:
> Thanks for the report. Can you please paste your offlineimaprc file
> after removing any sensitive information, and I can try to reproduce
> the error in my setup.

in fact, it turns out this is a duplicate of #981063, which I failed to
identify initially because it didn't have the actual final error in the
message. The workaround in that bug report worked for me.

I've tried to merge the bugs, but it failed with an error on locking a
spool file on the BTS server. (I've just tried again.)

FWIW, I think #981063 should be severity serious and fixed in time for
bullseye.

Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#982625: fails to authenticate with "TypeError: sequence item 2: expected str instance, bytes found" error

[Stefano Zacchiroli]

Package: offlineimap
Version: 7.3.3+dfsg1-1+0.0~git20210105.00d395b+dfsg-2
Severity: serious

In Debian testing offlineimap plain authentication over SSL started to fail for
me in the following way:

$ offlineimap -c ~/.config/offlineimap/offlineimaprc -u basic --info
OfflineIMAP 7.3.0
  Licensed under the GNU GPL v2 or any later version (with an OpenSSL 
exception)
imaplib2 v3.05, Python v3.9.1+, OpenSSL 1.1.1i  8 Dec 2020
  imaplib2: 3.05
Remote repository 'Censored: type 'IMAP'
Host: mail.example.org Port: None SSL: True
Establishing connection to mail.example.org:993 (Censored)
Traceback (most recent call last):
  File "/usr/bin/offlineimap", line 22, in 
oi.run()
  File "/usr/share/offlineimap3/offlineimap/init.py", line 88, in run
self.__serverdiagnostics(options)
  File "/usr/share/offlineimap3/offlineimap/init.py", line 518, in 
__serverdiagnostics
account.serverdiagnostics()
  File "/usr/share/offlineimap3/offlineimap/accounts.py", line 197, in 
serverdiagnostics
self.ui.serverdiagnostics(remote_repo, 'Remote')
  File "/usr/share/offlineimap3/offlineimap/ui/UIBase.py", line 450, in 
serverdiagnostics
conn = repository.imapserver.acquireconnection()
  File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 592, in 
acquireconnection
self.__authn_helper(imapobj)
  File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 449, in 
__authn_helper
if func(imapobj):
  File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 375, in 
__authn_plain
imapobj.authenticate('PLAIN', self.__plainhandler)
  File "/usr/lib/python3/dist-packages/imaplib2.py", line 691, in 
authenticate
typ, dat = self._simple_command('AUTHENTICATE', mechanism.upper())
  File "/usr/lib/python3/dist-packages/imaplib2.py", line 1684, in 
_simple_command
return self._command_complete(self._command(name, *args), kw)
  File "/usr/lib/python3/dist-packages/imaplib2.py", line 1404, in _command
literal = literator(data, rqb)
  File "/usr/lib/python3/dist-packages/imaplib2.py", line 2247, in process
ret = self.mech(self.decode(data))
  File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 217, in 
__plainhandler
retval = NULL.join((authz, authc, passwd))
TypeError: sequence item 2: expected str instance, bytes found

The server in question has a valid letsencrypt certificate, which I can use and
authenticate fine with other clients.

Not sure if the problem is actually in offlineimap or in imaplib2, but no
relevant bugs seems to be reported against the latter either.

Thanks for maintaining offlineimap,
Cheers

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages offlineimap depends on:
ii  offlineimap3  0.0~git20210105.00d395b+dfsg-2

offlineimap recommends no packages.

offlineimap suggests no packages.

-- no debconf information

Bug#975560: M-x pyvenv-workon fails with "No such file or directory, python"

[Stefano Zacchiroli]

Package: elpa-pyvenv
Version: 1.21-1
Severity: important

Since the removal of the /usr/bin/python -> python3 symlink, M-x pyvenv-workon
fails with the following error message:

  zsh:1: command not found: python
  apply: Searching for program: No such file or directory, python

Installing python-is-python3 fixes the issue, but is clearly not the right
solution. pyvenv should be able to enter a virtualenv no matter what, given
that is where the "right" python version will be found.

Thanks a lot for maintaining elpa-pyvenv in Debian!
Cheers

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages elpa-pyvenv depends on:
ii  dh-elpa-helper  2.0.6
ii  emacsen-common  3.0.4
ii  virtualenv  20.1.0+ds-1

Versions of packages elpa-pyvenv recommends:
ii  emacs  1:27.1+1-3
ii  emacs-gtk [emacs]  1:27.1+1-3
ii  virtualenvwrapper  4.8.4-4

elpa-pyvenv suggests no packages.

-- no debconf information

Bug#970904: arc diff emits a lot of warnings about implode() PHP function

[Stefano Zacchiroli]

Package: arcanist
Version: 0~git20190207-1
Severity: normal
File: /usr/bin/arc

Sample output:

  $ arc diff
  [2020-09-25 07:38:58] ERROR 8192: implode(): Passing glue string after array 
is deprecated. Swap the parameters at 
[/usr/share/libphutil/src/utils/utils.php:1572]
  arcanist(), phutil()
#0 implode(array, string) called at [/src/utils/utils.php:1572]
#1 phutil_build_http_querystring(array) called at 
[/src/future/http/HTTPSFuture.php:526]
#2 HTTPSFuture::formatRequestDataForCURL() called at 
[/src/future/http/HTTPSFuture.php:247]
#3 HTTPSFuture::isReady() called at [/src/future/Future.php:37]
#4 Future::resolve(NULL) called at [/src/future/FutureProxy.php:34]
#5 FutureProxy::resolve() called at 
[/src/conduit/ConduitClient.php:64]
#6 ConduitClient::callMethodSynchronous(string, array) called at 
[/src/workflow/ArcanistWorkflow.php:332]
#7 ArcanistWorkflow::authenticateConduit() called at 
[/scripts/arcanist.php:356]
  [2020-09-25 07:38:58] ERROR 8192: implode(): Passing glue string after array 
is deprecated. Swap the parameters at 
[/usr/share/libphutil/src/utils/utils.php:1572]
  arcanist(), phutil()
#0 implode(array, string) called at [/src/utils/utils.php:1572]
#1 phutil_build_http_querystring(array) called at 
[/src/future/http/HTTPSFuture.php:526]
#2 HTTPSFuture::formatRequestDataForCURL() called at 
[/src/future/http/HTTPSFuture.php:247]
#3 HTTPSFuture::isReady() called at [/src/future/Future.php:37]
#4 Future::resolve(NULL) called at [/src/future/FutureProxy.php:34]
#5 FutureProxy::resolve() called at 
[/src/conduit/ConduitClient.php:64]
#6 ConduitClient::callMethodSynchronous(string, array) called at 
[/src/workflow/ArcanistDiffWorkflow.php:1597]
#7 ArcanistDiffWorkflow::getCommitMessageFromUser() called at 
[/src/workflow/ArcanistDiffWorkflow.php:1501]
#8 ArcanistDiffWorkflow::buildCommitMessage() called at 
[/src/workflow/ArcanistDiffWorkflow.php:469]
#9 ArcanistDiffWorkflow::run() called at 
[/scripts/arcanist.php:394]
  [2020-09-25 07:39:04] ERROR 8192: implode(): Passing glue string after array 
is deprecated. Swap the parameters at 
[/usr/share/libphutil/src/utils/utils.php:1572]
  arcanist(), phutil()
#0 implode(array, string) called at [/src/utils/utils.php:1572]
#1 phutil_build_http_querystring(array) called at 
[/src/future/http/HTTPSFuture.php:526]
#2 HTTPSFuture::formatRequestDataForCURL() called at 
[/src/future/http/HTTPSFuture.php:247]
#3 HTTPSFuture::isReady() called at [/src/future/Future.php:37]
#4 Future::resolve(NULL) called at [/src/future/FutureProxy.php:34]
#5 FutureProxy::resolve() called at 
[/src/conduit/ConduitClient.php:64]
#6 ConduitClient::callMethodSynchronous(string, array) called at 
[/src/differential/ArcanistDifferentialCommitMessage.php:48]
#7 ArcanistDifferentialCommitMessage::pullDataFromConduit(ConduitClient) 
called at [/src/workflow/ArcanistDiffWorkflow.php:1695]
#8 ArcanistDiffWorkflow::getCommitMessageFromUser() called at 
[/src/workflow/ArcanistDiffWorkflow.php:1501]
#9 ArcanistDiffWorkflow::buildCommitMessage() called at 
[/src/workflow/ArcanistDiffWorkflow.php:469]
#10 ArcanistDiffWorkflow::run() called at 
[/scripts/arcanist.php:394]

as this is shown in the terminal during interactive use of arc diff, it makes
using the tool quite painful at the moment.

Cheers

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages arcanist depends on:
ii  libphutil   0~git20190207-1
ii  php-cli 2:7.4+76
ii  php-curl2:7.4+76
ii  php-xml 2:7.4+76
ii  php7.4-cli [php-cli]7.4.9-2
ii  php7.4-curl [php-curl]  7.4.9-2
ii  php7.4-xml [php-xml]7.4.9-2

arcanist recommends no packages.

Versions of packages arcanist suggests:
pn  python  

-- no debconf information

Bug#969576: nextcloud-desktop: Main window not visible/constructable

[Stefano Zacchiroli]

On Wed, Sep 09, 2020 at 07:24:04PM +0200, Paul van Tilburg wrote:
> I have to reaffirm that I used an iterative approach to install each of
> these to get rid of all warnings and have the main interface appear.
> I'm afraid that all dependencies listed  above seem necessary, maybe
> you had the others for other reasons already?

Yeah, it is entirely possible. So please test what is actually needed
(e.g., in a fresh debian chroot) rather than relying on my very narrow
data point.

Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#969576: nextcloud-desktop: Main window not visible/constructable

[Stefano Zacchiroli]

severity serious
thanks

On Sat, Sep 05, 2020 at 11:59:46AM +0200, Paul van Tilburg wrote:
> The upgrade to 3.0 of the Nextcloud client led to the main window not
> being visible anymore. It seems that the QT QML modules are missing to
> make it work.  Consider the warnings in the logs:

I can confirm this. I'm raising the severity because the desktop UI is
de facto non usable due to this.

> After installing the following packages,  I can see the main window again
> (although it still disappears on me sometimes):
> 
> * qml-module-qtquick-layouts
> * qml-module-qtquick-controls2
> * qml-module-qtgraphicaleffects
> * qml-module-qtqml-models2
> * qml-module-qtqml

Thanks for this. After "apt install"-ing the above packages the issue
was fixed for me too. For what is worth, the packages that were
*actually* missing on my system prior to the installation were just:

  qml-module-qtquick-controls2
  qml-module-qtquick-templates2

so I'd expect that adding either (if they depend on one another) or both
to the package dependencies would fix this issue.

Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#964334: segfault repeatedly

[Stefano Zacchiroli]

I've seen this bug has been marked as "more info" (with no comment), but
I'm not clear on which additional info are needed and how I can provide
them.  Advice on how I can help is welcome :-)

Bug#964334: segfault repeatedly

[Stefano Zacchiroli]

Package: chromium
Version: 83.0.4103.116-2
Severity: grave

I've upgraded chromium to the current version in testing, and it segfaults
repeatedly (and very "reliably"! :-)) after usually ~1 minute of runtime, even
when not used in foreground, with a stack trace like this one:

-

$ chromium 

(chromium:1480721): Gtk-WARNING **: 21:03:45.963: Theme parsing error: 
gtk.css:6:20: The 'gtk-key-bindings' property has been renamed to 
'-gtk-key-bindings'
[1480760:1480760:0705/210346.245467:ERROR:sandbox_linux.cc(374)] 
InitializeSandbox() called with multiple threads in process gpu-process.
[1480764:1480779:0705/210348.465499:ERROR:nss_util.cc(283)] After loading Root 
Certs, loaded==false: NSS error code: -8018
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: profile 'Photoshop ICC profile': 'RGB ': RGB color space 
not permitted on grayscale PNG
libpng warning: iCCP: profile 'Photoshop ICC profile': 'RGB ': RGB color space 
not permitted on grayscale PNG
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
Received signal 11 SEGV_MAPERR 7f01744946c7
#0 0x557d36628c69 (/usr/lib/chromium/chromium+0x52b3c68)
#1 0x557d36587ef3 (/usr/lib/chromium/chromium+0x5212ef2)
#2 0x557d366287f1 (/usr/lib/chromium/chromium+0x52b37f0)
#3 0x7f1a95d8d110 (/usr/lib/x86_64-linux-gnu/libpthread-2.30.so+0x1410f)
#4 0x7f1a90e78d3c (/usr/lib/x86_64-linux-gnu/libc-2.30.so+0x85d3b)
#5 0x7f1a90e7af33 (/usr/lib/x86_64-linux-gnu/libc-2.30.so+0x87f32)
#6 0x7f1a90e7cbf9 __libc_malloc
#7 0x557d366409be operator new()
#8 0x7f1a91103a2c std::__cxx11::basic_string<>::reserve()
#9 0x7f1a910f9498 std::__cxx11::basic_stringbuf<>::overflow()
#10 0x7f1a9110204a std::basic_streambuf<>::xsputn()
#11 0x7f1a910f4714 std::__ostream_insert<>()
#12 0x557d36628d39 (/usr/lib/chromium/chromium+0x52b3d38)
#13 0x557d36629054 (/usr/lib/chromium/chromium+0x52b4053)
#14 0x557d3659a412 (/usr/lib/chromium/chromium+0x5225411)
#15 0x557d3659c548 (/usr/lib/chromium/chromium+0x5227547)
#16 0x557d34ce212a (/usr/lib/chromium/chromium+0x396d129)
#17 0x557d34ce217e (/usr/lib/chromium/chromium+0x396d17d)
#18 0x557d34337387 (/usr/lib/chromium/chromium+0x2fc2386)
#19 0x557d34c9b3d9 (/usr/lib/chromium/chromium+0x39263d8)
#20 0x557d34c9b61e (/usr/lib/chromium/chromium+0x392661d)
#21 0x557d34ce5967 (/usr/lib/chromium/chromium+0x3970966)
#22 0x557d34d114c7 (/usr/lib/chromium/chromium+0x399c4c6)
#23 0x557d34d1177e (/usr/lib/chromium/chromium+0x399c77d)
#24 0x557d34ce213f (/usr/lib/chromium/chromium+0x396d13e)
#25 0x557d34ce217e (/usr/lib/chromium/chromium+0x396d17d)
#26 0x557d34337387 (/usr/lib/chromium/chromium+0x2fc2386)
#27 0x557d345fa7a3 (/usr/lib/chromium/chromium+0x32857a2)
#28 0x557d349690bc (/usr/lib/chromium/chromium+0x35f40bb)
#29 0x557d3675a45f (/usr/lib/chromium/chromium+0x53e545e)
#30 0x557d36760a24 (/usr/lib/chromium/chromium+0x53eba23)
#31 0x557d3675eb62 (/usr/lib/chromium/chromium+0x53e9b61)
#32 0x557d3675d82d (/usr/lib/chromium/chromium+0x53e882c)
#33 0x557d36756213 (/usr/lib/chromium/chromium+0x53e1212)
#34 0x557d36771abb (/usr/lib/chromium/chromium+0x53fcaba)
#35 0x557d36771de0 (/usr/lib/chromium/chromium+0x53fcddf)
#36 0x557d36771370 (/usr/lib/chromium/chromium+0x53fc36f)
#37 0x557d345e3c46 (/usr/lib/chromium/chromium+0x326ec45)
#38 0x557d345e376c (/usr/lib/chromium/chromium+0x326e76b)
#39 0x557d345dfeed (/usr/lib/chromium/chromium+0x326aeec)
#40 0x557d345d674b (/usr/lib/chromium/chromium+0x326174a)
#41 0x557d345c9044 (/usr/lib/chromium/chromium+0x3254043)
#42 0x557d345c8d75 (/usr/lib/chromium/chromium+0x3253d74)
#43 0x557d345e7426 (/usr/lib/chromium/chromium+0x3272425)
#44 0x557d366460e0 (/usr/lib/chromium/chromium+0x52d10df)
#45 0x7f1a94b42b0f (/usr/lib/x86_64-linux-gnu/libevent-2.1.so.7.0.0+0x23b0e)
#46 0x7f1a94b4324f event_base_loop
#47 0x557d3664638e (/usr/lib/chromium/chromium+0x52d138d)
#48 0x557d365e65d5 (/usr/lib/chromium/chromium+0x52715d4)
#49 0x557d365be670 (/usr/lib/chromium/chromium+0x524966f)
#50 0x557d349043b3 (/usr/lib/chromium/chromium+0x358f3b2)
#51 0x557d365fc2a9 (/usr/lib/chromium/chromium+0x52872a8)
#52 0x557d36638c9e (/usr/lib/chromium/chromium+0x52c3c9d)
#53 0x7f1a95d81f27 start_thread
#54 0x7f1a90ef031f clone
  r8: 0077  r9: 0050 r10: 0004 r11: 
007c
 r12: 7f1a7420 r13: 7f1a7430 r14: 7f1a74736850 r15: 
0020
  di: 0021  si: 0004  bp: 0020  bx: 
7f01744946bf
  dx: 7f1a7480  ax: 7f1a742d4d90  cx: 7f01744946bf  sp: 
7f1a826d3440
  ip: 7f1a90e78d3c efl: 00010202 cgf: 002b0033 erf: 
0004
 trp: 000e msk:  cr2: 7f01744946c7
[end of stack trace]
Calling _exit(1). Core file will not be generated.

-

Thanks a lot for maintaining chromium in Debian,
Hope this helps


-- System Information:
Debian 

Bug#962051: segfault when locking screen

[Stefano Zacchiroli]

forcemerge 959883 962051
thanks

On Tue, Jun 02, 2020 at 09:54:15PM +0100, Simon McVittie wrote:
> On Tue, 02 Jun 2020 at 17:22:54 +0200, Stefano Zacchiroli wrote:
> > heya, since yesterday under Debian/testing gnome-shell crashes (and then
> > restarts) when trying to lock screen.
> 
> This seems like #959883. Please try disabling any extensions you have
> enabled, and/or upgrading to the snapshot in experimental.

Yup, that was it! I guess I missed it because I've only looked at open
bugs, my apologies. Upgrading to the experimental snapshot fixed the
issue for me too.

Merging/closing.

Thanks for your super quick solution!
Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#962051: segfault when locking screen

[Stefano Zacchiroli]

Package: gnome-shell
Version: 3.36.2-1
Severity: important

heya, since yesterday under Debian/testing gnome-shell crashes (and then
restarts) when trying to lock screen. Here's the diagnostic I can find under
journalctl:

  giu 02 17:17:32 noziere kernel: gnome-shell[106365]: segfault at 0 ip 
7fb2305fd467 sp 7ffd001db960 error 4 in libst-1.0.so[7fb2305de000+4a000]
  giu 02 17:17:32 noziere kernel: Code: 00 00 00 48 83 c3 01 41 39 9f 30 01 00 
00 0f 8e 2f 01 00 00 49 8b 87 28 01 00 00 48 8d 35 d6 f5 02 00 48 8b 2c d8 48 
8b 45 00 <48> 8b 00 4c 8b 20 4c 89 e7 e8 3b 28 fe ff 85 c0 74 c7 41 80 7c 24
  giu 02 17:17:32 noziere polkitd(authority=local)[718]: Unregistered 
Authentication Agent for unix-session:2 (system bus name :1.168, object path 
/org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) 
(disconnected from bus)
  giu 02 17:17:32 noziere gsd-media-keys[2202]: Couldn't lock screen: 
GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected 
from message bus without replying
  giu 02 17:17:32 noziere systemd[1768]: gnome-shell-x11.service: Main process 
exited, code=killed, status=11/SEGV
  giu 02 17:17:32 noziere systemd[1768]: gnome-shell-x11.service: Failed with 
result 'signal'.
  giu 02 17:17:32 noziere systemd[1768]: gnome-shell-x11.service: Scheduled 
restart job, restart counter is at 11.
  giu 02 17:17:32 noziere systemd[1768]: Stopped target GNOME X11 Session 
(session: gnome).
  giu 02 17:17:32 noziere systemd[1768]: Stopping GNOME X11 Session (session: 
gnome).
  giu 02 17:17:32 noziere systemd[1768]: Stopped target GNOME X11 Session.
  giu 02 17:17:32 noziere systemd[1768]: Stopping GNOME X11 Session.
  giu 02 17:17:32 noziere systemd[1768]: Stopped target GNOME Shell on X11.
  giu 02 17:17:32 noziere systemd[1768]: Stopping GNOME Shell on X11.
  giu 02 17:17:32 noziere systemd[1768]: Stopped GNOME Shell on X11.
  giu 02 17:17:32 noziere systemd[1768]: Starting GNOME Shell on X11...

It happens systematically, both when trying to lock screen on demand
(Ctrl+Alt+L) and when the laptop suspends (meaning that when it wakes up the
desktop is happily unlocked... this might make this bug warrant a security +
severity bump: I'll let this up to the maintainers to decide).

As shown above the shell immediately restarts afterwards, without causing any
session disruption/logout/etc.

Thanks for maintaining GNOME in Debian!

Cheers

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  evolution-data-server3.36.2-1
ii  gir1.2-accountsservice-1.0   0.6.55-2
ii  gir1.2-atspi-2.0 2.36.0-2
ii  gir1.2-freedesktop   1.64.1-1
ii  gir1.2-gcr-3 3.36.0-2
ii  gir1.2-gdesktopenums-3.0 3.36.1-1
ii  gir1.2-gdm-1.0   3.34.1-3
ii  gir1.2-geoclue-2.0   2.5.6-1
ii  gir1.2-glib-2.0  1.64.1-1
ii  gir1.2-gnomebluetooth-1.03.34.1-1
ii  gir1.2-gnomedesktop-3.0  3.36.2-1
ii  gir1.2-gtk-3.0   3.24.20-1
ii  gir1.2-gweather-3.0  3.36.0-1
ii  gir1.2-ibus-1.0  1.5.22-5
ii  gir1.2-mutter-6  3.36.2-3
ii  gir1.2-nm-1.01.24.0-1
ii  gir1.2-nma-1.0   1.8.28-2
ii  gir1.2-pango-1.0 1.44.7-4
ii  gir1.2-polkit-1.00.105-26
ii  gir1.2-rsvg-2.0  2.48.4+dfsg-1
ii  gir1.2-soup-2.4  2.70.0-1
ii  gir1.2-upowerglib-1.00.99.11-2
ii  gjs  1.64.2-1
ii  gnome-backgrounds3.36.0-1
ii  gnome-settings-daemon3.36.1-1
ii  gnome-shell-common   3.36.2-1
ii  gsettings-desktop-schemas3.36.1-1
ii  libatk-bridge2.0-0   2.34.1-3
ii  libatk1.0-0  2.36.0-2
ii  libc62.30-8
ii  libcairo21.16.0-4
ii  libecal-2.0-13.36.2-1
ii  libedataserver-1.2-243.36.2-1
ii  libgcr-base-3-1  3.36.0-2
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-4
ii  

Bug#961638: proposal: stocat - probabilistic cat

[Stefano Zacchiroli]

Package: moreutils
Version: 0.63-1+b1
Severity: wishlist
Tags: patch upstream

I'm hereby proposing the inclusion of the attached "stocat" utility to
moreutils. It's like cat, but output lines with a given probability, defaulting
to 10%. It's very useful for random sampling (and *much* more efficient at that
than using "shuf" which is unwieldy on very large inputs) and, while it can be
implemented instead with awk/perl oneliners, those oneliners aren't very
mnemonic and are error prone.

If desired, it could be extended by adding a reservoir sampling option, to
guarantee a selection of exactly K items.

Thanks a lot for moreutils!

Cheers

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages moreutils depends on:
ii  libc6  2.30-8
ii  libipc-run-perl20200505.0-1
ii  libtime-duration-perl  1.21-1
ii  libtimedate-perl   2.3200-1
ii  perl   5.30.2-1

moreutils recommends no packages.

moreutils suggests no packages.

-- no debconf information
#!/usr/bin/perl

=head1 NAME

stocat - stochastic cat, selecting lines with uniform probability


=head1 SYNOPSIS

=over

=item B [B<-p>|B<--probability> PROBABILITY] [I|B<->]...

=back


=head1 DESCRIPTION

Concatenate FILE(s) to standard output, but printing each input line to output
only with a given probability, defaulting to 0.1 (i.e., 10%).

With no FILE or when FILE is B<->, read standard input.


=head1 OPTIONS

=over 4

=item -p, --probability

Output lines with the given probability, specified as a number between 0 (0%
probability) and 1 (100% probability). Default: 0.1 (i.e., 10% probability).

=back


=head1 SEE ALSO

L


=head1 AUTHOR

Copyright 2020 by Stefano Zacchiroli 

Licensed under the GNU GPL.

=cut

use Getopt::Long;

sub die_usage() {
die "Usage: $0 [--probability|-p PROBABILITY] [file|-]\n";
}

my $probability = 0.1;
if (! GetOptions("probability|p=f" => \$probability)) {
die_usage();
}
if ($probability < 0 || $probability > 1) {
die_usage();
}

while (<>) {
print $_ if rand() <= $probability;
}

Bug#952465: please set debian-project@lists.d.o as moderated

[Stefano Zacchiroli]

Package: lists.debian.org
Severity: normal

Dear listmasters,
  in light of repeated trolling and abuse targeting individual Debian
contributors distributed via debian-project@lists.d.o, I'd like to ask for that
mailing list to be set to moderated for the time being.

A group of more than 30 Debian project members have volunteered to share the
burden of moderating the list.  Once this bug report is accepted by the BTS,
I'll followup to the listmaster contact address with the list of moderators
email addresses and account names.

Thanks a lot for your work on Debian mailing lists,
(which has certainly being unduly tiresome in recent times,)

Cheers

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#952449: please shipe "tlsh" binary and manpage

[Stefano Zacchiroli]

Package: tlsh-tools
Version: 3.4.4+20151206-1.3+b1
Severity: minor
Tags: patch

Heya,
  it's a bit weird that the main binary for this package is called
"tlsh_unittest". The upstream doc has this to say on the matter:

  Building TLSH (see below) will create a static library in the lib directory,
  and the tlsh executable (a symbolic link to tlsh_unittest).

but that's indeed not true :-). The symbolic link is *not* built and hence not
shipped by the Debian package. But it would be *nice* to ship it! So please
find attached a .links file that, if dropped into the debian/ dir, will make
the tlsh-tools package ship /usr/bin/tlsh (as a symbolic link) and its manpage.

Can you consider applying it?

Thanks a lot for maintaining tlsh in Debian,
Cheers

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tlsh-tools depends on:
ii  libc62.29-10
ii  libgcc-s1 [libgcc1]  10-20200211-1
ii  libgcc1  1:10-20200211-1
ii  libstdc++6   10-20200211-1
ii  libtlsh0 3.4.4+20151206-1.3+b1

tlsh-tools recommends no packages.

tlsh-tools suggests no packages.

-- no debconf information
usr/bin/tlsh_unittest   usr/bin/tlsh
usr/share/man/man1/tlsh_unittest.1  usr/share/man/man1/tlsh.1

Bug#928073: unblock: beancount/2.2.0-3

[Stefano Zacchiroli]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package beancount

Santiago Villa has discovered an unpredictability in the cleanup of a gnupg
socket file, which might randomly make the package FTBFS. The version I've just
uploaded to unstable includes a patch by Santiago that fixes this. It would be
nice to have this fix in testing, to make rebuilding the next stable release
more predicatble.

debdiff attached.

unblock beancount/2.2.0-3

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru beancount-2.2.0/debian/changelog beancount-2.2.0/debian/changelog
--- beancount-2.2.0/debian/changelog2019-01-14 10:01:37.0 +0100
+++ beancount-2.2.0/debian/changelog2019-04-21 17:00:36.0 +0200
@@ -1,3 +1,11 @@
+beancount (2.2.0-3) unstable; urgency=medium
+
+  [ Santiago Vila ]
+  * patches/0003: Ignore FileNotFoundError from self.tmpdir.cleanup().
+Fixes a FTBFS problem which happens randomly (Closes: #923606)
+
+ -- Stefano Zacchiroli   Sun, 21 Apr 2019 17:00:36 +0200
+
 beancount (2.2.0-2) unstable; urgency=medium
 
   * rules: do not ship *.picklecache files with Python examples (fixes
diff -Nru 
beancount-2.2.0/debian/patches/0003-Ignore-FileNotFoundError-from-self.tmpdir.cleanup.patch
 
beancount-2.2.0/debian/patches/0003-Ignore-FileNotFoundError-from-self.tmpdir.cleanup.patch
--- 
beancount-2.2.0/debian/patches/0003-Ignore-FileNotFoundError-from-self.tmpdir.cleanup.patch
 1970-01-01 01:00:00.0 +0100
+++ 
beancount-2.2.0/debian/patches/0003-Ignore-FileNotFoundError-from-self.tmpdir.cleanup.patch
 2019-04-21 17:00:36.0 +0200
@@ -0,0 +1,18 @@
+From: Santiago Vila 
+Date: Sun, 21 Apr 2019 16:48:40 +0200
+Subject: Ignore FileNotFoundError from self.tmpdir.cleanup()
+
+--- a/beancount/utils/encryption_test.py
 b/beancount/utils/encryption_test.py
+@@ -98,7 +98,10 @@
+ self.run_gpg('--import', stdin=TEST_SECRET_KEY.encode('ascii'))
+ 
+ def tearDown(self):
+-self.tmpdir.cleanup()
++try:
++self.tmpdir.cleanup()
++except FileNotFoundError:
++pass
+ 
+ def run_gpg(self, *args, **kw):
+ command = ('gpg',
diff -Nru beancount-2.2.0/debian/patches/series 
beancount-2.2.0/debian/patches/series
--- beancount-2.2.0/debian/patches/series   2019-01-14 10:01:37.0 
+0100
+++ beancount-2.2.0/debian/patches/series   2019-04-21 17:00:36.0 
+0200
@@ -1,2 +1,3 @@
 0001-Remove-fonts.googleapis.com-links-for-the-bean-web-t.patch
 0002-make-test_version-more-lax-to-accept-non-git-hg-vers.patch
+0003-Ignore-FileNotFoundError-from-self.tmpdir.cleanup.patch

Bug#923606: beancount: FTBFS randomly (gpg-related race condition)

[Stefano Zacchiroli]

On Sun, Apr 21, 2019 at 05:52:36PM +0200, Santiago Vila wrote:
> In other words: My "merge request" is below.

Thanks Santiago, patch applied --- both in the master branch in git and
in a dedicated minimal upload targeting sid. I'll request an unblock as
soon as the upload hits the archive.

Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#927070: ITP: ledger2beancount -- Convert Ledger-based textual ledgers to Beancount ones

[Stefano Zacchiroli]

Thanks Jelmer !  :-)

On April 14, 2019 6:49:26 PM GMT+02:00, Jelmer Vernooij  
wrote:
>Package: wnpp
>Severity: wishlist
>Owner: Jelmer Vernooij 
>
>* Package name: ledger2beancount
>  Version : 1.6
>  Upstream Author : Stefano Zacchiroli 
>Martin Michlmayr 
>* URL : https://github.com/zacchiro/ledger2beancount
>* License : GPLv3
>  Programming Lang: Perl
>Description : Convert Ledger-based textual ledgers to Beancount
>ones
>
>A script to automatically convert Ledger-based textual ledgers to
>Beancount
>ones.
>
>Conversion is based on (concrete) syntax, so that information that is
>not
>meaningful for accounting reasons but still valuable (e.g., comments,
>formatting, etc.) can be preserved.

-- 
Sent from my mobile phone. Please excuse my brevity and top-posting.

Bug#923606: beancount: FTBFS randomly (gpg-related race condition)

[Stefano Zacchiroli]

Hi Santiago,

On Tue, Apr 09, 2019 at 10:38:10AM +0200, Santiago Vila wrote:
> I obviously have interest to fix this before the release, because I
> can build 99.99% of packages in my setup and this is an inconvenient
> exception for me. I don't like NMUs. Should I join the Python
> Applications Packaging Team? Please tell me how I would proceed.

either way is fine, and also just submitting a merge request would do
(although please let this bug log know if you do so, to make sure it
doesn't get overlooked).

Thanks!
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#923606: beancount: FTBFS randomly (gpg-related race condition)

[Stefano Zacchiroli]

Hi Santiago,

On Tue, Mar 05, 2019 at 10:52:47AM +0100, Santiago Vila wrote:
> Also, I hope you will surely agree that telling me that you can build
> the package in your computer does not help me at all to build the
> package in my computer. In this case I'm just doing QA, but if I
> wanted to modify the software, the end result is that I could not.

sure, I agree with you on this, and I'm also very grateful for the QA
work you're doing.

> So, while we are not violating the DFSG in strict sense, as we are
> still distributing the source, the user still can't exercise their
> right to modify the software in practical terms.

Here is where I disagree with you, on the perceived severity of this
issue. I still haven't seen any other build setup than yours where this
build failure happens. So, while I totally trust you and concede that my
view of the matter might be biased; I think yours might be too, in the
opposite sense. Hence, as an independent test, I'm relying on the
official Debian build infrastructure (and associated services, like
reproducible build), as a proxy of what users are most likely to
encounter when trying to rebuild the package. That's all I'm saying.

If you disagree with this, which is totally fine, the severity can be
raised and I'll happily punt to the release team to decide what to do
with beancount.

> (I'm not changing the severity, and I'm still offering a test machine
> for you to reproduce the issue if you need it).

Thanks a lot for this. I don't think it's needed to determine the actual
fix, which is fairly obvious.  My main issue is that I also want to
update to latest upstream release for the next package upload, which is
a minor version update, but in which the code layout changed a bit,
requiring other changes in the packaging. I will not have time to do so
in time for the freeze, so I'm just trying to postpone this work
post-freeze, and I'll address this then.

If you, or others, have time and interest to fix this before, by all
means go ahead. The package is team-maintained, and I'm very happy to
receive useful NMUs to "my" packages anyway.

I hope this clarifies,
Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#923606: beancount: FTBFS randomly (gpg-related race condition)

[Stefano Zacchiroli]

severity -1 important
thanks

Hi Santiago,

On Sat, Mar 02, 2019 at 06:03:10PM +, Santiago Vila wrote:
> I tried to build this package in buster but it failed:
> [...]
> try:
> >   os.unlink(entry.name, dir_fd=topfd)
> E   FileNotFoundError: [Errno 2] No such file or directory: 
> 'S.gpg-agent.browser'
[...]
> The above is just how the build ends and not necessarily the most relevant 
> part,
> so I've put a bunch of failed build logs here:
> 
> https://people.debian.org/~sanvila/build-logs/beancount/
> 
> The failure happens randomly. Sometimes it happens, sometimes it does not,
> but the failure rate is so high that we can't really say that the package
> "builds from source and without failure".

thanks for this bug report, I had no idea about this flakiness in the
build.

> This failure is similar to another one which I reported before in another 
> package:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906335
> 
> but I'm not really sure if that helps.
> 
> If you need a test machine where this happens almost all the time, please 
> contact me
> privately and I will gladly offer ssh access.

Similarly to the other bug you mention, I think the incidence of this
FTBFS is low... at least elsewhere w.r.t. your build environment. I've
personal never witnessed this, and I'm aware of a bunch of other people
who have built from scratch without issues. More to the point,
reproducible building the package is working fine on at least four
architectures, including the one you are testing on:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/beancount.html

On that basis, I'm lowering the priority to important.

Still, I think the bug should be fixed, and I will do so (most likely
ignoring the rm error, as that means no cleanup is needed). But I will
not necessarily do this in time for the next release.

Cheers.
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#918641: pkg_resources.DistributionNotFound: The 'cheroot' distribution was not found and is required by fava

[Stefano Zacchiroli]

Package: python3-fava
Version: 1.9-3
Severity: serious

As per subject, running fava fails with the following traceback:

  Traceback (most recent call last):
File "/usr/bin/fava", line 6, in 
  from pkg_resources import load_entry_point
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3126, 
in 
  @_call_aside
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3110, 
in _call_aside
  f(*args, **kwargs)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3139, 
in _initialize_master_working_set
  working_set = WorkingSet._build_master()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 581, 
in _build_master
  ws.require(__requires__)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 898, 
in require
  needed = self.resolve(parse_requirements(requirements))
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 784, 
in resolve
  raise DistributionNotFound(req, requirers)
  pkg_resources.DistributionNotFound: The 'cheroot' distribution was not found 
and is required by fava

this should ideally be fixed by having cheroot ship an egg-info dir, but it's
being filed against fava for now to avoid testing migration.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-fava depends on:
ii  python3  3.7.1-3
ii  python3-babel2.6.0+dfsg.1-1
ii  python3-beancount2.1.3+hg20181225-3
ii  python3-click6.7+git20180829-1
ii  python3-flask1.0.2-3
ii  python3-flask-babel  0.11.2-2
ii  python3-jinja2   2.10-1
ii  python3-markdown22.3.7-1
ii  python3-ply  3.11-3
ii  python3-simplejson   3.15.0-1+b1

python3-fava recommends no packages.

python3-fava suggests no packages.

-- no debconf information

Bug#917954: fava: Incomplete debian/copyright?

[Stefano Zacchiroli]

On Tue, Jan 01, 2019 at 03:07:02PM +, Chris Lamb wrote:
> I just ACCEPTed fava from NEW but noticed it was missing attribution 
> in debian/copyright for at least some code embedded in fava/static/gen/app.js.
> 
> This is in no way exhaustive so please check over the entire package 
> carefully and address these on your next upload.

Thanks, nice catch.

I've fixed this specific occurrence (in git) and looked for others,
without finding any.

I'm postponing package upload, waiting for beancount (a fava dependency)
to clear NEW too.

Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#917532: RFP: fava -- web interface for the Beancount accounting tool

[Stefano Zacchiroli]

tag 917532 + pending
thanks

Fava is now in NEW.

Cheers.
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#917532: RFP: fava -- web interface for the Beancount accounting tool

[Stefano Zacchiroli]

On Sun, Dec 30, 2018 at 01:24:23AM +0100, Pierre-Elliott Bécue wrote:
> I think a webserver config + WSGI handling is quite overkill. Do you agree?

Yeah, I agree.

Upstream is reluctant to even document easy setup recipes on the basis
that Fava is essentially a personal service. I've myself setup a
"public" Fava, behind HTTPS auth of course, but I see value in not
making it "too easy" in this case, for fear of unsavvy users leaking
personal information out of the box.

If anything, we should work with upstream on the deployment
documentation side, and make sure said documentation is shipped with the
package.

Cheers

PS I commented on IRC about that, but FWIW: I think the reference on the
   package description to "beancount" as package name is correct,
   because there is such a binary package and it is the end-user
   oriented entry point to Beancount in Debian
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#917532: RFP: fava -- web interface for the Beancount accounting tool

[Stefano Zacchiroli]

On Sat, Dec 29, 2018 at 09:11:23PM +0100, Pierre-Elliott Bécue wrote:
> It's in new now. :)

Thanks! :-)

-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#917532: RFP: fava -- web interface for the Beancount accounting tool

[Stefano Zacchiroli]

Looks like a fava dependency is missing in Debian: [python3-]markdown2,
https://pypi.org/project/markdown2/ (There's python3-markdown in the
archive, but that's a different one: https://pypi.org/project/Markdown/)

Volunteers to package markdown2 are welcome; I'm not going to package it
myself.

Cheers.
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#917532: RFP: fava -- web interface for the Beancount accounting tool

[Stefano Zacchiroli]

A package skeleton is now available on salsa:

  https://salsa.debian.org/python-team/applications/fava

Help and co-maintainers are welcome.

(It's not clear to me if I should do anything else, other than creating
the project on salsa, to make sure other members of PAPT can directly
commit to the repo. If so, I'd appreciate someone letting me know.)

Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#917532: RFP: fava -- web interface for the Beancount accounting tool

[Stefano Zacchiroli]

Package: wnpp
Severity: wishlist

* Package name: fava
  Version : 1.9
  Upstream Author : Dominik Aumayr 
* URL : https://beancount.github.io/fava/
* License : MIT
  Programming Lang: Python
  Description : web interface for the Beancount accounting tool

Fava is a web interface for the double-entry bookkeeping software Beancount
with a focus on features and usability.

Beancount is packaged in Debian as "beancount".

Bug#799626: RFP: beancount -- command line double-entry bookkeeping system

[Stefano Zacchiroli]

The package is now sitting in NEW, waiting to land in experimental. I've
also pushed a couple of minor improvements on salsa, waiting for the
next upload. As soon as it passes NEW, I plan to upload again to
unstable, hoping to make the freeze cut (you never know... :-))

Please let me know if you have objections and please test the package
and let this bug report know if you encounter any showstopper. For my
part I've migrated my local use of beancount to the current version of
the package and it is working just fine for my needs.

Cheers.
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#799626: RFP: beancount -- command line double-entry bookkeeping system

[Stefano Zacchiroli]

On Mon, Dec 24, 2018 at 07:30:31PM +0200, Martin Michlmayr wrote:
> So this issue was reported and fixed already upstream:
> 
> Here's the original bug report:
> 
> https://bitbucket.org/blais/beancount/issues/341/test_utilsfind_repository_root-doesnt-work

Thanks Martin for finding this, and thanks James for raising it upstream
after last time I tried it out.

I've updated the package to a hg snapshot of today (which includes the
commits with the fix, and more). The source package as it is on salsa
now builds fine on a fresh unstable chroot.

Testing welcome.

Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#799626: RFP: beancount -- command line double-entry bookkeeping system

[Stefano Zacchiroli]

On Sun, Dec 09, 2018 at 05:23:35PM +0200, Martin Michlmayr wrote:
> Is the delay because of the test failures mentioned by Zack?

The main current issue is that several tests, at least when run under
sbuild/cowbuilder, enters infinite loops stat()-ing forever
"/PKG-INFO". I have been unable to find the cause, but it's somewhat
specific to the Debian build environment in conjunction with pytest.

In addition to that there are some test failures too, but they look easy
to fix (and the patches should probably be sent upstream for
integration).

I don't see myself having more time than I already devoted to this in
time for the next freeze. But if you're up to tackling this, I can
provide more info, e.g., I've a list of the affected tests, in case it
might help finding a pattern. The *general* pattern is that tests that
exec() stuff are impacted, but it's not specific enough (at least for
me) to pinpoint the issue.

Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#799626: RFP: beancount -- command line double-entry bookkeeping system

[Stefano Zacchiroli]

I've updated the package at
https://salsa.debian.org/python-team/applications/beancount to match
latest release (2.1.2) + mercurial snapshot and fixed one failing test.

Two tests still fail.

The corresponding functionalities work in the package after installed.

Also, they fail in very weird ways, only under python3.7, which are not
reproducible outside the package build environment.

I'm tempted to just push the attached patch to ignore the two tests and
upload. That will give us some user testing time before buster is frozen
and, when 3.7 become the default, reassess whether the tests still fail
or not.

Thoughts?
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
From: Stefano Zacchiroli 
Date: Mon, 1 Oct 2018 22:58:39 +0200
Subject: ignore tests that fail with pytest 3.7 in a 3.6 environment

the tests runs fine outside the build process and the corresponding
functionalities work when the package is installed
---
 beancount/ingest/identify_test.py  | 2 ++
 beancount/scripts/tutorial_test.py | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/beancount/ingest/identify_test.py b/beancount/ingest/identify_test.py
index f6689da..2d37cb6 100644
--- a/beancount/ingest/identify_test.py
+++ b/beancount/ingest/identify_test.py
@@ -4,6 +4,7 @@ __license__ = "GNU GPLv2"
 from os import path
 from unittest import mock
 import os
+import pytest
 import re
 import subprocess
 import sys
@@ -72,6 +73,7 @@ class TestScriptIdentifyFunctions(test_utils.TestTempdirMixin, unittest.TestCase
 
 class TestScriptIdentify(scripts_utils.TestScriptsBase):
 
+@pytest.mark.skip
 def test_identify(self):
 regexp = textwrap.dedent("""\
 \*\*\*\* .*/Downloads/ofxdownload.ofx
diff --git a/beancount/scripts/tutorial_test.py b/beancount/scripts/tutorial_test.py
index e2b3e32..6dcb5c2 100644
--- a/beancount/scripts/tutorial_test.py
+++ b/beancount/scripts/tutorial_test.py
@@ -2,6 +2,7 @@ __copyright__ = "Copyright (C) 2014, 2016  Martin Blais"
 __license__ = "GNU GPLv2"
 
 import os
+import pytest
 import shutil
 import tempfile
 from os import path
@@ -12,6 +13,7 @@ from beancount.scripts import tutorial
 
 class TestTutorial(test_utils.TestCase):
 
+@pytest.mark.skip
 def test_generate_tutorial(self):
 rootdir = test_utils.find_repository_root(__file__)
 example_beancount = path.join(rootdir, 'examples', 'example.beancount')

Bug#907165: package installation fails with "ERROR: install script from ess package failed"

[Stefano Zacchiroli]

On Fri, Aug 24, 2018 at 06:40:24AM -0500, Dirk Eddelbuettel wrote:
> and it is as 17.11-4 in 'experimental' (I was debating dropping it into
[...]
> Can you try the 'elpa-ess' and 'ess' (transition) package set, please?
> 
>https://packages.debian.org/source/experimental/ess

I can confirm that installing elpa-ess 17.11-4 for experimental worked
just fine.

Thanks!
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#907165: package installation fails with "ERROR: install script from ess package failed"

[Stefano Zacchiroli]

Package: ess
Version: 17.11-3
Severity: serious

  scaramouche  $ sudo dpkg --configure ess
  Setting up ess (17.11-3) ...
  Install emacsen-common for emacs25
  emacsen-common: Handling install of emacsen flavor emacs25
  Install ess for emacs25
  install/ess: Handling install for emacsen flavor emacs25
  ERROR: install script from ess package failed
  dpkg: error processing package ess (--configure):
   installed ess package post-installation script subprocess returned error 
exit status 1
  Errors were encountered while processing:
   ess

I've noticed the above failure while upgrading testing. I've tried removing
(worked) and installing from scratch (failed in the same way as above).

Previous version in testing was working fine.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ess depends on:
ii  dpkg1.19.0.5+b1
ii  emacsen-common  2.0.8
ii  install-info6.5.0.dfsg.1-4

Versions of packages ess recommends:
ii  r-base-core  3.5.1-1+b1

Versions of packages ess suggests:
pn  jags   
pn  julia  
pn  pspp   
pn  xlispstat  

-- no debconf information

Bug#873335: please ship full (org-mode) documentation as part of the binary package

[Stefano Zacchiroli]

Package: elpa-magithub
Version: 0.1.3-1
Severity: normal

magithub comes with a nice extended documentation, which can be seen rendered
here https://github.com/vermiculus/magithub/blob/master/magithub.org , but is
also available as an org-mode file in the upstream tarball (and Debian source
package).

It would be nice to ship that org-mode file under /usr/share/doc/, as the
currently shipped README file is really minimal.

As this package is for Emacs user, I suspect that just shipping the .org file
should be enough, no need to render it (e.g., to HTML) during build, IMHO.

Thanks for maintaining magithub in Debian!
Cheers.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages elpa-magithub depends on:
ii  elpa-ghub+  0.1.4-2
ii  elpa-magit  2.10.3-1
ii  elpa-s  1.11.0-4
ii  emacsen-common  2.0.8

Versions of packages elpa-magithub recommends:
ii  emacs  47.0

elpa-magithub suggests no packages.

-- no debconf information

Bug#858229: ITP: passh -- passh: a pass fork - stores, retrieves, generates, and synchronizes passwords securely.

[Stefano Zacchiroli]

Hi Adrian,

On Mon, Mar 20, 2017 at 02:18:27AM -0300, Adrian Alves wrote:
> Pass is a simple password store. This fork changes a few
> things while trying to maintain most of it intact,
> specially the core idea. I will keep pulling pass commits,
> and also pushing my modifications to them.

as a pass user, I'm interesting in having a look at this. However, the
description is not particularly telling about what are the differences
("a few things" :-)) and why this fork exists. Can you update the
description of the final package to address this?

TIA,
Cheers.
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#856020: mktexpk: don't know how to create bitmap font for txsys

[Stefano Zacchiroli]

On Fri, Feb 24, 2017 at 01:25:35PM +0100, Hilmar Preuße wrote:
> Missed one: Could you temporarily rename that file and try again?
> /home/zack/.texlive2016/texmf-var/fonts/map/pdftex/updmap/pdftex.map

Moving it away fixed the issue.

Thanks!
Cheers.
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#856020: mktexpk: don't know how to create bitmap font for txsys

[Stefano Zacchiroli]

First of all thanks for your quick feedback, Hilmar!

On Fri, Feb 24, 2017 at 11:33:48AM +0100, Hilmar Preuße wrote:
> I've no clue why mktexpk is even started, as the txsys is available as type1
> font. The MWE works fine on my box. Please enter a few commands and send the
> output:
> 
> locate txsys
> grep txsys /usr/share/texlive/texmf-dist/fonts/map/pdftex/updmap/pdftex*
> grep txsys /var/lib/texmf/fonts/map/pdftex/updmap/pdftex*

  zack@timira:~$ locate txsys
  /home/srv/src/unix-history-repo/sys/boot/i386/btx/lib/btxsys.s
  /home/srv/src/unix-history-repo/sys/boot/pc98/btx/lib/btxsys.s
  /usr/share/texlive/texmf-dist/fonts/tfm/public/newtx/txsys.tfm
  /usr/share/texlive/texmf-dist/fonts/type1/public/newtx/txsys.pfb

  zack@timira:~$ grep txsys 
/usr/share/texlive/texmf-dist/fonts/map/pdftex/updmap/pdftex*
  /usr/share/texlive/texmf-dist/fonts/map/pdftex/updmap/pdftex_dl14.map:txsys 
txsys 

Bug#856020: mktexpk: don't know how to create bitmap font for txsys

[Stefano Zacchiroli]

Package: texlive-fonts-extra
Version: 2016.20170123-3
Severity: serious

Heya, the version of texlive-fonts-extra currently in Debian/etxting causes
failure in building (with pdflatex) LaTeX files that use the "txsys" font. See
below for a minimal example, and the attached .fls and .tex files.

The error message is:

  kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 0+540/600 --dpi 540 
txsys
  mktexpk: don't know how to create bitmap font for txsys.
  mktexpk: perhaps txsys is missing from the map file.
  kpathsea: Appending font creation commands to missfont.log.
   )
  !pdfTeX error: pdflatex (file txsys): Font txsys at 540 not found
   ==> Fatal error occurred, no output PDF file produced!

I've tried both package version -3 (currently in testing) and -4 (in unstable,
waiting for unblock), and they both fail in the same way.

Suggestions on how to temporarily work-around this issue are very welcome, as
it's blocking for me.

With many thanks for your help and for maintaining TeXLive in Debian!

Cheers.

-- Package-specific info:

##

\documentclass[sigconf]{acmart}

\begin{document}

Lorem Ipsum

\begin{itemize}
\item foo
\end{itemize}

\end{document}

##

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages texlive-fonts-extra depends on:
ii  fonts-cabin1.5-2
ii  fonts-comfortaa2.003-1
ii  fonts-croscore 20161116-1
ii  fonts-crosextra-caladea20130214-1
ii  fonts-crosextra-carlito20130920-1
ii  fonts-dejavu-core  2.37-1
ii  fonts-dejavu-extra 2.37-1
ii  fonts-ebgaramond   0.016-1
ii  fonts-ebgaramond-extra 0.016-1
ii  fonts-font-awesome 4.7.0~dfsg-1
ii  fonts-freefont-otf 20120503-6
ii  fonts-freefont-ttf 20120503-6
ii  fonts-gfs-artemisia1.1-5
ii  fonts-gfs-complutum1.1-6
ii  fonts-gfs-didot1.1-6
ii  fonts-gfs-neohellenic  1.1-6
ii  fonts-gfs-olga 1.1-5
ii  fonts-gfs-solomos  1.1-5
ii  fonts-junicode 0.7.8-2
ii  fonts-lato 2.0-1
ii  fonts-linuxlibertine   5.3.0-2
ii  fonts-lobstertwo   2.0-2
ii  fonts-noto-hinted  20161116-1
ii  fonts-oflb-asana-math  000.907-6
ii  fonts-roboto-hinted2:0~20160106-2
ii  fonts-sil-gentium  20081126:1.03-1
ii  fonts-sil-gentium-basic1.1-7
ii  fonts-sil-gentiumplus  5.000-1
ii  fonts-sil-gentiumplus-compact  5.000-2
ii  fonts-stix 1.1.1-4
ii  tex-common 6.06
ii  texlive-base   2016.20170123-3
ii  ttf-adf-accanthis  0.20090423-2
ii  ttf-adf-gillius0.20090423-2
ii  ttf-adf-universalis0.20090423-2

Versions of packages texlive-fonts-extra recommends:
ii  texlive-fonts-extra-doc  2016.20170123-3
ii  texlive-latex-extra  2016.20170123-3

Versions of packages texlive-fonts-extra suggests:
pn  cm-super  

Versions of packages tex-common depends on:
ii  dpkg  1.18.22
ii  ucf   3.0036

Versions of packages tex-common suggests:
ii  debhelper  10.2.5

Versions of packages texlive-fonts-extra is related to:
ii  tex-common6.06
ii  texlive-binaries  2016.20160513.41080.dfsg-1

-- debconf information:
  tex-common/check_texmf_missing:
  tex-common/check_texmf_wrong:
\documentclass[sigconf]{acmart}

\begin{document}

Lorem Ipsum

\begin{itemize}
\item foo
\end{itemize}

\end{document}
PWD /tmp
INPUT /etc/texmf/web2c/texmf.cnf
INPUT /usr/share/texmf/web2c/texmf.cnf
INPUT /usr/share/texlive/texmf-dist/web2c/texmf.cnf
INPUT /var/lib/texmf/web2c/pdftex/pdflatex.fmt
INPUT txsys-missing-from-map-file.tex
OUTPUT txsys-missing-from-map-file.log
INPUT /usr/share/texlive/texmf-dist/tex/latex/acmart/acmart.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/acmart/acmart.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/xkeyval/xkeyval.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/xkeyval/xkeyval.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/xkeyval/xkeyval.tex
INPUT /usr/share/texlive/texmf-dist/tex/generic/xkeyval/xkvutils.tex
INPUT /usr/share/texlive/texmf-dist/tex/generic/xkeyval/keyval.tex
INPUT /usr/share/texlive/texmf-dist/tex/latex/amscls/amsart.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/amscls/amsart.cls
INPUT /usr/share/texlive/texmf-dist/fonts/map/fontname/texfonts.map
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr9.tfm
INPUT /usr/share/texlive/texmf-dist/tex/latex/amsmath/amsmath.sty
INPUT 

Bug#851974: choice of "gnome classic" session sticks, and make it impossible to go back to default "gnome" session

[Stefano Zacchiroli]

Package: gdm3
Version: 3.22.1-1
Severity: important

Heya,

yesterday evening my GNOME session (the default one) didn't want to start
properly, and just left me with the screen background after login - no Shell,
no anything else.

So I've tried logging in choosing the "GNOME Classic" session (not the metacity
one, the one based on GNOME Shell, but the panel-like look & feel). It worked
properly, and still does.  The problem is I can no longer go back to the
"GNOME" session: when I choose it upon login, I still get the "GNOME Classic"
session, and I've no idea about how to go back to the default GNOME session.

Any idea of how to fix and/or further debug this?

TIA,
Cheers

PS I'm not entirely sure it's GDM's fault. It might be gnome-session,
   gnome-shell, or something else. Feel free to reassign as needed.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gdm3 depends on:
ii  accountsservice  0.6.43-1
ii  adduser  3.115
ii  awesome [x-window-manager]   3.5.9-1
ii  dconf-cli0.26.0-2
ii  dconf-gsettings-backend  0.26.0-2
ii  debconf [debconf-2.0]1.5.59
ii  gir1.2-gdm-1.0   3.22.1-1
ii  gnome-session [x-session-manager]3.22.2-1
ii  gnome-session-bin3.22.2-1
ii  gnome-session-flashback [x-session-manager]  3.22.0-3
ii  gnome-settings-daemon3.22.1-1
ii  gnome-shell  3.22.2-1
ii  gnome-terminal [x-terminal-emulator] 3.22.1-1
ii  gsettings-desktop-schemas3.22.0-1
ii  libaccountsservice0  0.6.43-1
ii  libaudit11:2.6.7-1
ii  libc62.24-8
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libgdk-pixbuf2.0-0   2.36.3-1
ii  libgdm1  3.22.1-1
ii  libglib2.0-0 2.50.2-2
ii  libglib2.0-bin   2.50.2-2
ii  libgtk-3-0   3.22.6-1
ii  libkeyutils1 1.5.9-9
ii  libpam-modules   1.1.8-3.5
ii  libpam-runtime   1.1.8-3.5
ii  libpam-systemd   232-8
ii  libpam0g 1.1.8-3.5
ii  librsvg2-common  2.40.16-1
ii  libselinux1  2.6-3
ii  libsystemd0  232-8
ii  libwrap0 7.6.q-26
ii  libx11-6 2:1.6.4-2
ii  libxau6  1:1.0.8-1
ii  libxdmcp61:1.1.2-1.1
ii  lsb-base 9.20161125
ii  metacity [x-window-manager]  1:3.22.1-1
ii  mutter [x-window-manager]3.22.2-3
ii  policykit-1  0.105-17
ii  ucf  3.0036
ii  x11-common   1:7.7+18
ii  x11-xserver-utils7.7+7
ii  xterm [x-terminal-emulator]  327-2

Versions of packages gdm3 recommends:
ii  at-spi2-core2.22.0-5
ii  desktop-base9.0.0
ii  x11-xkb-utils   7.7+3
ii  xserver-xephyr  2:1.19.0-3
ii  xserver-xorg1:7.7+18
ii  zenity  3.22.0-1

Versions of packages gdm3 suggests:
ii  gnome-orca3.22.2-1
ii  libpam-gnome-keyring  3.20.0-3

-- Configuration Files:
/etc/gdm3/daemon.conf changed:
[daemon]
WaylandEnable=false
[security]
[xdmcp]
[greeter]
[chooser]
[debug]


-- debconf information:
  gdm3/daemon_name: /usr/sbin/gdm3
* shared/default-x-display-manager: gdm3

Bug#846476: apt: fill up disk space with many /var/lib/apt/lists/partial/*.FAILED files

[Stefano Zacchiroli]

Package: apt
Version: 1.0.9.8.3
Severity: important

Heya,
  I've just cleand up ~12 GB of /var/lib/apt/lists/partial/*.FAILED (on a 20GB
partition :-)) and I wonder what apt could do better in order to avoid similar
situations.

Some details: those *.FAILED files are due to hash mismatches when periodically
consulting httpredir.debian.org, due to unattended-upgrades cron job. Of course
the update failures there are not apt's fault. Most of the files seem to be
diffs to Packages, Sources, or Translation files, with the former dominating
disk space consumption.

OTOH, neither "apt-get clean" nor the daily apt cron job seem to clean up
*.FAILED files, that stay around for at least several months (I've seen in
there files as old as early September).

Maybe either, or both, of the clean action of apt and its cron job can be
modified to cater for cleaning up and avoiding filling the disk?

Many thanks in advance for your consideration, and for maintaining apt!
Cheers.

-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages apt depends on:
ii  debian-archive-keyring  2014.3
ii  gnupg   1.4.18-7+deb8u3
ii  libapt-pkg4.12  1.0.9.8.3
ii  libc6   2.19-18+deb8u6
ii  libgcc1 1:4.9.2-10
ii  libstdc++6  4.9.2-10

apt recommends no packages.

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.6.11-1+b1
ii  dpkg-dev1.17.27
ii  python-apt  0.9.3.12

-- no debconf information

Bug#844201: debsources: updater broken by recent (Sources.gz removal, maybe sha1 removal) dak changes

[Stefano Zacchiroli]

Package: qa.debian.org
Severity: serious
User: qa.debian@packages.debian.org
Usertags: debsources

Context is:

  https://lists.debian.org/debian-devel-announce/2016/11/msg5.html

Here are some relevant entries from debsources.log:

  Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639.
  Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639.
  Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639.
  Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639.
  Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639.
  Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639.
  Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639.
  Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639.
  Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639.
  Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639.
  Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639.
  Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639.
  Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639.
  Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639.
  Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639.
  Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639.
  Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639.
  Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639.
  Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639.
  Use of uninitialized value $sha1 in string eq at /usr/bin/debmirror line 1639.
  Errors:
   Download of dists/squeeze-lts/Release failed
   Ignoring failed Release files
   Ignoring missing Release file for dists/sid/main/source/Sources.gz
   Ignoring missing Release file for dists/sid/contrib/source/Sources.gz
   Ignoring missing Release file for dists/sid/non-free/source/Sources.gz
   Ignoring missing Release file for dists/squeeze-lts/main/source/Sources.gz
   Ignoring missing Release file for dists/squeeze-lts/contrib/source/Sources.gz
   Ignoring missing Release file for 
dists/squeeze-lts/non-free/source/Sources.gz
   Ignoring missing Release file for dists/experimental/main/source/Sources.gz
   Ignoring missing Release file for 
dists/experimental/contrib/source/Sources.gz
   Ignoring missing Release file for 
dists/experimental/non-free/source/Sources.gz
  /srv/debsources/bin/debsources-main: I: debsources-update...

Cheers.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#842353: confusing naming of newcomer bug sections

[Stefano Zacchiroli]

Package: how-can-i-help
Version: 14
Severity: minor

Heya, when running how-can-i-help I see multiple sections listing newcomer
bugs, and most notably:

- Bugs suitable for new contributors (tagged 'newcomer'):
- Bugs affecting Debian infrastructure (tagged 'newcomer'):

That is a bit confusing, because the heading of the first section hints at
listing *all* newcomer bugs, while the heading of the second only a specific
sub-class (without being a subsection of the previous section).

The first section might be listing only package-related bugs, but I'm not sure.

If so the first section could be renamed to mention "packages" somewhere.
Alternatively one might introduce subsections, with a macro-section about
"newcomers", and two subsections about packages/infrastructure.

With many thanks for maintaining how-can-i-help!
Cheers.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages how-can-i-help depends on:
ii  ruby 1:2.3.0+4
ii  ruby-debian  0.3.9+b6
ii  ruby-json2.0.1+dfsg-2

how-can-i-help recommends no packages.

how-can-i-help suggests no packages.

-- no debconf information

Bug#839190: wordpress 4.1+dfsg-1+deb8u10 regression

[Stefano Zacchiroli]

On Fri, Sep 30, 2016 at 10:20:30AM +0200, Yves-Alexis Perez wrote:
> thanks for the report, we're aware of the regression. Can you try the attached
> patch against functions.php and report back, as soon as possible?

I've tried the patch, and it fixed the regression for me.

Cheers.
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#835033: debsources: [PATCH] Retain line context on 404s by appending the hash for specific links

[Stefano Zacchiroli]

Package: qa.debian.org
Severity: minor
User: qa.debian@packages.debian.org
Usertags: debsources

Forwarding to the BTS for record keeping.

- Forwarded message from Chris Lamb <la...@debian.org> -

Date: Sun, 21 Aug 2016 11:41:27 +0100
From: Chris Lamb <la...@debian.org>
To: debian...@lists.debian.org
Cc: i...@sources.debian.net
Subject: debsources: [PATCH] Retain line context on 404s by appending the hash 
for specific links
Message-Id: <1471776087.3092845.701483073.410a5...@webmail.messagingengine.com>

Hi,

Attached is the following:

  commit a0a47c965d364fb41d1b0fde2480252a9c328479
  Author: Chris Lamb <la...@debian.org>
  Date:   Sun Aug 21 11:39:25 2016 +0100
  
  Retain line context on 404s by appending the hash for specific links
  
  Signed-off-by: Chris Lamb <la...@debian.org>
  
   debsources/app/sources/templates/sources/404_suggestions.html | 2 +-
   debsources/app/templates/footer.inc.html  | 8 
   2 files changed, 9 insertions(+), 1 deletion(-)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

>From a0a47c965d364fb41d1b0fde2480252a9c328479 Mon Sep 17 00:00:00 2001
From: Chris Lamb <la...@debian.org>
Date: Sun, 21 Aug 2016 11:39:25 +0100
Subject: [PATCH] Retain line context on 404s by appending the hash for
 specific links

Signed-off-by: Chris Lamb <la...@debian.org>
---
 debsources/app/sources/templates/sources/404_suggestions.html | 2 +-
 debsources/app/templates/footer.inc.html  | 8 
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/debsources/app/sources/templates/sources/404_suggestions.html 
b/debsources/app/sources/templates/sources/404_suggestions.html
index bf4609e..f1127f7 100644
--- a/debsources/app/sources/templates/sources/404_suggestions.html
+++ b/debsources/app/sources/templates/sources/404_suggestions.html
@@ -11,7 +11,7 @@ The file you are looking for might exist in one of the 
following
 versions:
 
 {% for s in suggestions %}
-  {{ s }}
+  {{ s }}
 {% endfor %}
 
 
diff --git a/debsources/app/templates/footer.inc.html 
b/debsources/app/templates/footer.inc.html
index 29d1d14..8636672 100644
--- a/debsources/app/templates/footer.inc.html
+++ b/debsources/app/templates/footer.inc.html
@@ -32,3 +32,11 @@
   Last update: {{ last_update }}.
 
 
+
+
+var elems = document.querySelectorAll('.js-append-window-location-hash');
+
+for (var i = 0; i < elems.length; ++i) {
+  elems[i].setAttribute('href', elems[i].getAttribute('href') + 
window.location.hash);
+}
+
-- 
2.9.3



- End forwarded message -

-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#833596: [pkg-gnupg-maint] Bug#833596: systemd user service {gpg-agent, dirmngr} breaks GNOME session startup

[Stefano Zacchiroli]

On Wed, Aug 10, 2016 at 11:46:55AM -0400, Daniel Kahn Gillmor wrote:
> That's the exact same stack i used for my test, and i didn't see the
> error.  so yeah, i'd like to try to track it down.

So I've tried again. I've good and bad news.

Good news: I can no longer reproduce the session startup failure. GNOME
starts just fine, and this is how the two services in question look:

---
  $ systemctl status --user dirmngr.service
  ● dirmngr.service - GnuPG network certificate management daemon
 Loaded: loaded (/usr/lib/systemd/user/dirmngr.service; enabled; vendor 
preset: enabled)
Active: active (running) since mer 2016-08-17 09:09:06 CEST; 5min ago
 Docs: man:dirmngr(8)
 Process: 21506 ExecStart=/usr/bin/dirmngr --daemon --homedir 
%h/.gnupg (code=exited, status=0/SUCCESS)
  Main PID: 21509 (dirmngr)
 CGroup: 
/user.slice/user-1000.slice/user@1000.service/dirmngr.service
└─21509 /usr/bin/dirmngr --daemon --homedir 
/home/zack/.gnupg

  ago 17 09:09:06 timira systemd[21502]: Starting GnuPG network certificate 
management daemon...
  ago 17 09:09:06 timira dirmngr[21506]: dirmngr[21506.0]: WARNING: 
***
  ago 17 09:09:06 timira systemd[21502]: Started GnuPG network certificate 
management daemon.

  $ systemctl status --user gpg-agent.service
  ● gpg-agent.service - GnuPG secret key agent and passphrase cache
 Loaded: loaded (/usr/lib/systemd/user/gpg-agent.service; enabled; vendor 
preset: enabled)
Active: active (running) since mer 2016-08-17 09:09:06 CEST; 5min ago
 Docs: man:gpg-agent(1)
 Process: 21507 ExecStart=/usr/bin/gpg-agent --daemon --homedir 
%h/.gnupg (code=exited, status=0/SUCCESS)
  Main PID: 21508 (gpg-agent)
 CGroup: 
/user.slice/user-1000.slice/user@1000.service/gpg-agent.service
└─21508 /usr/bin/gpg-agent --daemon --homedir 
/home/zack/.gnupg

  ago 17 09:09:06 timira systemd[21502]: Starting GnuPG secret key agent and 
passphrase cache...
  ago 17 09:09:06 timira systemd[21502]: Started GnuPG secret key agent and 
passphrase cache.
---

Bad news: I checked where the services belong in the service tree (as
you suggested on debian-devel [1]) and they are still not part of the
session scope:

---
  └─user.slice
└─user-1000.slice
  ├─user@1000.service
  │ ├─gpg-agent.service
  │ │ └─21508 /usr/bin/gpg-agent --daemon --homedir /home/zack/.gnupg
  │ ├─dirmngr.service
  │ │ └─21509 /usr/bin/dirmngr --daemon --homedir /home/zack/.gnupg
  │ └─init.scope
  │   ├─21502 /lib/systemd/systemd --user
  │   └─21503 (sd-pam) 
  └─session-1209.scope
---

[1]: https://lists.debian.org/debian-devel/2016/08/msg00085.html

FWIW I've checked and there are no other dirmngr or gpg-agent services
running in the whole tree.

Is this the expected behavior? In your test where did the two services
ended up being located in the service tree?

Hope this helps,
Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#833596: [pkg-gnupg-maint] Bug#833596: systemd user service {gpg-agent, dirmngr} breaks GNOME session startup

[Stefano Zacchiroli]

On Wed, Aug 10, 2016 at 12:12:27AM -0400, Daniel Kahn Gillmor wrote:
> So i'm not able to reproduce this behavior.
> 
> Zack, can you help me narrow down how this is happening for you?

Sure, I'll be happy to. But as I mentioned before I wonder if it's worth
to do it with my current package mix: I'm using testing, where the GNOME
stack seems to be still in flux, apparently), with gnupg2 coming from
experimental. I can debug, but I wonder if it'd be a good time
investment.

Unless you consider this issue potentially blocking for uploading to
unstable, I'd rather wait for gnupg2 to land in testing and try again.
After all the issue is for a non-default behavior that one should
explicitly enabled, right?

OTOH if you do consider this a blocker, I'll roll up my sleeves and have
a look ASAP :-)

> do you have logs of the failed login session someplace, or other details
> that might help diagnose?

I can look up logs, but I could use some guidance about where the GNOME
user session logs are supposed to be. ~/.xsession-errors seems to be
obsolete --- or else it hasn't received log entries on my laptop since
March 2016, which seems unlikely...

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#833596: systemd user service {gpg-agent,dirmngr} breaks GNOME session startup

[Stefano Zacchiroli]

Package: gnupg
Version: 2.1.14-3

Forwarding from debian-devel
https://lists.debian.org/debian-devel/2016/08/msg00093.html , as
requested by dkg.

- Forwarded message from Stefano Zacchiroli <z...@debian.org> -

Date: Sat, 6 Aug 2016 12:32:39 +0200
From: Stefano Zacchiroli <z...@debian.org>
To: debian-de...@lists.debian.org
Subject: Re: [pkg-gnupg-maint] Beware of leftover gpg-agent processes
Message-ID: <20160806103239.ga12...@upsilon.cc>
Resent-From: debian-de...@lists.debian.org

[ quoted text reordered ]

On Fri, Aug 05, 2016 at 02:43:30PM -0400, Daniel Kahn Gillmor wrote:
> The simplest way to see the control group hierarchy is with "systemctl
> status".  When these processes are launched by the user service, they'll
> end up in the user@.service like this:
[...]
> If they've been autolaunched, they'll end up in the sesion-X.scope
> sub-tree.

It was indeed the case for me: they had been auto-launched.

> > On Fri, Aug 05, 2016 at 12:41:18PM -0400, Daniel Kahn Gillmor wrote:
> >> On desktop systems (where i'd expect the majority of secret key access
> >> happens), for folks who are running systemd, i recommend enabling the
> >> systemd user services, as documented in
> >> /usr/share/doc/{gnupg-agent,dirmngr}/README.Debian :
> >> 
> >>   systemctl --user enable gpg-agent
> >>   systemctl --user enable dirmngr

OTOH, doing this inhibited a proper start of my GNOME session at next
login: only Nautilus started (I can tell because I've it handle my
desktop icons) and I could use it to browse the filesystem, but GNOME
Shell didn't see to be running.  Reverting the above with "disable" [*]
fixed the issue, and at next login GNOME session started properly,
including GNOME Shell.

I haven't yet filed this as a bug report, because my package mix is
kinda unusual at present: Debian testing + hand-picked gpg from
experimental. But it might be useful for you to know about this. Let me
know how I can debug it further and/or if you'd like to move this
discussion into a dedicated bug report (and when).

Cheers.

[*] actually, I manually removed the symlinks from
.config/systemd/user/default.target.wants/, but AFAICT the effect is
the same
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#823142: mutt-patched: First letter of Mailboxes' names is not shown

[Stefano Zacchiroli]

On Sun, May 01, 2016 at 02:00:51PM +0200, Muammar El Khatib wrote:
> Recently, the first letter of Mailboxes's names is being "stripped" in
> mutt-pached. I am sending attached to this bug report a screenshot so
> that you can see. This is not an important bug, but it is annoying. I
> solved this by adding the following¹:

Confirmed, I'm seeing the same issue.

The responsible upgrade on my (testing) laptop is this one (from
dpkg.log):

  2016-05-04 20:55:18 upgrade notmuch-mutt:all 0.21-3 0.22-1

The same upgrade also broke this setting from my .muttrc:

  # set sidebar_delim_chars="/"

which I had to comment out as it's no longer recognized. But I've no
idea whether this is related to the first-letter bug or not.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#823035: --all command line option is not documented in manpage

[Stefano Zacchiroli]

Package: gitg
Version: 0.2.7-3
Severity: minor
File: /usr/bin/gitg

As per bug subject: gitg seems to support the --all command line option (with
the same semantics of gitk --all), but that option is not documented in the
manpage, nor in the output of gitg --help.

Thanks for maintaining gitg in Debian!

Cheers.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gitg depends on:
ii  dbus-x11 1.10.8-1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  git  1:2.8.1-1
ii  gsettings-desktop-schemas3.18.1-1
ii  libc62.22-7
ii  libcairo21.14.6-1+b1
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.0-1
ii  libgtk-3-0   3.18.9-1
ii  libgtksourceview-3.0-1   3.18.2-1
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1

gitg recommends no packages.

gitg suggests no packages.

-- no debconf information

Bug#821248: ITP: fgallery -- modern, minimalist javascript photo gallery

[Stefano Zacchiroli]

On Sun, Apr 17, 2016 at 01:23:14AM +0200, Andreas Tille wrote:
> * Package name: fgallery

fgallery seems to already be in the archive:

  https://tracker.debian.org/pkg/fgallery

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#818463: archive changes: md5/sha1, gz/xz

[Stefano Zacchiroli]

Package: ftp.debian.org

Reporting this to track the various breakages on Debian infrastructure
components.

- Forwarded message from Joerg Jaspert <jo...@ganneff.de> -

Date: Tue, 15 Mar 2016 23:15:16 +0100
From: Joerg Jaspert <jo...@ganneff.de>
To: debian-devel-annou...@lists.debian.org
Subject: Archive changes
Message-ID: <87k2l3xua3@gkar.ganneff.de>
Resent-From: debian-devel-annou...@lists.debian.org

Hi,

I've just activated a few changes to the archive we talk(ed) about for a
long time. And while it is not exactly the start of this release cycle,
it should still work out nicely (so one hopes).

As of now, InRelease/Release files, Packages and Sources no longer
provide MD5Sum and SHA1sums, only SHA256.

Additionally I turned off generating gzip compressed versions of those
files, xz is there.

To test it, this is limited to experimental. We hope nothing breaks on it,
but lets try for a few days. If that works out, we should adjust
unstable, and another short time later coordinate with the release team
to adjust testing, so it ends up in the next release.

Have fun.

- End forwarded message -

-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#818498: migrate from debmirror to archvsync

[Stefano Zacchiroli]

Package: qa.debian.org
Severity: important
User: qa.debian@packages.debian.org
Usertags: debsources

debmirror shortcomings have been bugging debsources for quite a while lately.
Let's migrate away from it to archvsync [1], as that will put us in a more
"normal" situation w.r.t. how actual Debian mirrors are maintained around the
world.

[1]: https://ftp-master.debian.org/git/archvsync.git

I'm marking this bug as important because, after the recent archive changes,
debmirror isn't properly mirroring experimental (due to its having been
switched to Sources.xz).

Cheers.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#818324: updates of packages in experimental are currently ignored

[Stefano Zacchiroli]

severity 818324 serious
thanks

I'm raising the severity of 818324, because Sources.gz are already gone
for experimental, meaning that we are effectively ignoring them on
sources.debian.net until this is fixed.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#818324: debsources: migrate from Sources.gz to Sources.xz

[Stefano Zacchiroli]

Package: qa.debian.org
Severity: important
User: qa.debian@packages.debian.org
Usertags: debsources

Due to the mail below (and also at
https://lists.debian.org/debian-devel-announce/2016/03/msg6.html ) we need
to migrate the mirror lister module of Debsources from using Sources.gz to
using Sources.xz.

See:
https://anonscm.debian.org/cgit/qa/debsources.git/tree/debsources/debmirror.py#n195
for a *starting* point.

Cheers.

- Forwarded message from Joerg Jaspert  -

Date: Tue, 15 Mar 2016 23:15:16 +0100
From: Joerg Jaspert 
To: debian-devel-annou...@lists.debian.org
Subject: Archive changes
Message-ID: <87k2l3xua3@gkar.ganneff.de>
Resent-From: debian-devel-annou...@lists.debian.org

Hi,

I've just activated a few changes to the archive we talk(ed) about for a
long time. And while it is not exactly the start of this release cycle,
it should still work out nicely (so one hopes).

As of now, InRelease/Release files, Packages and Sources no longer
provide MD5Sum and SHA1sums, only SHA256.

Additionally I turned off generating gzip compressed versions of those
files, xz is there.

To test it, this is limited to experimental. We hope nothing breaks on it,
but lets try for a few days. If that works out, we should adjust
unstable, and another short time later coordinate with the release team
to adjust testing, so it ends up in the next release.

Have fun.

- End forwarded message -


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#816711: package description only mentions JSON Schema draft3, but the package actually supports draft4

[Stefano Zacchiroli]

Package: python3-jsonschema
Version: 2.5.1-4
Severity: minor

As per subject.

Thanks for maintaining jsonschema!

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-jsonschema depends on:
ii  python3  3.5.1-2
pn  python3:any  

python3-jsonschema recommends no packages.

python3-jsonschema suggests no packages.

-- no debconf information

Bug#815060: Encouraging removal of nvidia kernel modules from Debian non-free archive.

[Stefano Zacchiroli]

On Sat, Feb 20, 2016 at 09:34:48AM -0800, Bradley M. Kuhn wrote:
> I'm speaking here as a Debian user and Free Software citizen, although I
> First, I think Ben's explanation on the problems are salient.  But, more
> importantly and generally, IMO, Debian should err on the side of caution
> in these situations.

FWIW I agree with this.

And, to follow-up onto Holger's reasonable "[citation needed]" request,
I don't think that legal advice, or legal opinions in general, should be
the primary input that Debian uses to decide on this specific matter.

There are expert FOSS lawyers that consider proprietary Linux kernel
modules to be GPL violations in a number of circumstances, and others
with opposed views. And there are no relevant legal ruling yet AFAIK.

What is certain however is that a significant amount of Linux kernel
developers do consider proprietary modules like the nvidia one to be GPL
violations that infringe on their copyrights. Those developers
contribute code to the Linux kernel considering that 3rd party modules
should be released as Free Software too. Some of them also put money and
energies into fighting those who try to get away with proprietary
modules, free riding on their work.

Morally, I've no doubt on which side of those fights Debian should be.
And by distributing proprietary modules we are not helping our fellow
Free Software developers, quite the contrary.  But even putting moral
considerations aside for a moment, Debian should not be in the political
position of being cross with Linux kernel developers on the ground of
alleged copyright infringement. The political/legal Free Software
battleground is already enough of a mess; we should not contribute to
make it worse by risking community infights.

Especially when there is a technical alternative that provides an almost
identical user experience for Debian users who need nvidia.ko: a
downloader/installer package like nvidia-graphics-drivers used to be
many years ago [1,2].

Cheers.

[1]: 
http://sources.debian.net/src/nvidia-graphics-drivers/1.0.7174-3/debian/changelog/#L352-L354
[2]: 
http://sources.debian.net/src/nvidia-kernel-src/1.0.2880-1/debian/changelog/
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#815006: Renaming Iceweasel to Firefox

[Stefano Zacchiroli]

On Thu, Feb 18, 2016 at 07:48:25AM +0800, Paul Wise wrote:
> Mozilla's trademark policy isn't clear about how much modification
> requires Mozilla's written consent. Any written consent except for a
> clarification to Mozilla's trademark guidelines would be specific to
> Debian and thus would be in violation of DFSG item 8. Debian cannot
> make agreements with Mozilla about this that don't also apply to all
> distributors of modified versions of Mozilla's software.
> 
> What is the plan to solve this dilemma?

Let's take the worst case scenario: Mozilla's policy gets so extreme
that *every* derived works must be rebranded away from Mozilla's
marks---assuming for a moment that that is something that could be
enforced using trademark law in the first place. Such a policy would be
fine w.r.t. DFSG §4.

If a policy is less clear cut than that (as Mozilla's is), and we
(Debian) decide to use the marks anyhow, what we are doing is a risk
assessment exercise. We consider in good faith that the patches we will
apply will be OK w.r.t. the (unclear) policy and that therefore Mozilla
will not force us to rebrand. But we might be wrong, and Mozilla might
decide to force us to rebrand, which will be a PITA if it has to happen
in stable.

AFAIU there is no formal/contractual guarantee that Mozilla is giving
Debian here, nor they are giving us a trademark license. So DFSG §8 is
respected. Mozilla just recognizes that the kind of work that Debian
Firefox maintainers have done in the past, if continued in the future,
*should* be fine w.r.t. their trademark policy. As per my understanding
of trademark law, and given no trademark license is being given to
Debian, others (including our downstreams) will be able to apply the
same changes to Firefox without being forced to rebrand either.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#815006: Iceweasel / Firefox: Trademarks?

[Stefano Zacchiroli]

On February 17, 2016 5:55:26 PM GMT+01:00, "Paul R. Tagliamonte" 
 wrote:
>At minimum, the trademark guidelines say we can't charge for the
>software,
>what's our stance on that?

We are building our own binaries and not using Mozilla's "unaltered binaries", 
so that clause (which BTW I hate and consider cause for the non-free-ness of 
upstream binaries) doesn't apply to us.
Neither it applies to our downstream; so it isn't even a "specific to Debian" 
DFSG issue.

Cheers.
-- 
Sent from my mobile phone with K-9 Mail. Please excuse my brevity.

Bug#798199: New list: debian-outre...@lists.debian.org

[Stefano Zacchiroli]

On Sun, Sep 06, 2015 at 07:32:43PM +0200, Nicolas Dandrimont wrote:
> Name:
>  debian-outreach
> 
> Short description:
>  Public discussion of the Outreach Team's activities

Seconded.

> Category:
>  I'm torn between Developers and Misc Debian, with a slight
>  preference for the latter.

I'd say Misc Debian.

-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#812210: please ship a (more) complete manpage for /usr/bin/arc

[Stefano Zacchiroli]

Package: arcanist
Version: 0~git20150906-1
Severity: minor

"man arc" provides the manpage equivalent of "arc help", which is a nice
overview of the various command, but with no specific details about any of
them.

"arc help --full" on the other hand provide all needed details. The output of
*that* command should be in the manpage, rather than the output of the non-full
version. Can you please update the shipped manpage so that that is the case?

With many thanks for maintaining arcanist in Debian!

Cheers.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages arcanist depends on:
ii  libphutil  0~git20150906-1
ii  php5-cli   5.6.17+dfsg-3
ii  php5-curl  5.6.17+dfsg-3

arcanist recommends no packages.

Versions of packages arcanist suggests:
ii  python  2.7.11-1

-- no debconf information

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Stefano Zacchiroli]

On Mon, Jan 04, 2016 at 07:45:37AM +, Niels Thykier wrote:
> Your second item has been brought up before with different
> focus/rationale/purpose.  At least I remember there being an interest
> in splitting "non-free" into "non-free/firmware" vs. various other
> non-free sub components.

Another one that is worth mentioning here --- which I discussed in the
context of non-free.org with Dafydd Harries and others --- is
introducing a debtags facet to capture the reason why a package is in
non-free. At least two hierarchies come to mind: 1) which point of DFSG
is not respected, and 2) which one of the 4 freedoms are not granted.

I've had on my TODO list proposing the relevant debtags facets since at
least 2 years, but never found the time to actually do that. This is a
very actionable item: it is enough to follow the procedure for proposing
a new debtags. (Procedure that I cannot find right now, but IIRC it
includes coming up with a list of tag names + a list of at least N
packages, with N relatively low, that are already in the archive and
that would carry each tag.)

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Stefano Zacchiroli]

On Tue, Jan 05, 2016 at 08:15:37AM +0100, Johannes Schauer wrote:
> while I would welcome this sort of information being captured using debtags,
> this would not help me if I wanted to tell apt which packages are okay for me
> and which ones are not because apt cannot set pin priorities according to a
> package's debtags, right?

Right, but you need to start encoding the information in a machine
parsable way somewhere. Once you've that, you can exploit the
information, not before.

> Also, can the reason why something is in non-free not be captured by
> increased and a more structured use of DEP-5 (machine-readable
> debian/copyright)?

Policy §12.5 already requires to explain why a package is in non-free:

  Packages in the contrib or non-free archive areas should state in the
  copyright file that the package is not part of the Debian distribution
  and briefly explain why.

and DEP-5 prescribes the Disclaimer field to that end. Unfortunately, no
further (machine-readable) structure *within* the content of that field
is prescribed by DEP-5. So, yes, we will need to improve that part of
DEP-5 if we want to exploit information in there.

I duly note that, out of the box, having the information in d/copyright
won't help with APT pinning either.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#808216: debmirror: Debmirror seeems to have problems with new SHA256 in Packages.diff/Index files

[Stefano Zacchiroli]

On Thu, Dec 17, 2015 at 06:45:13PM +0800, Michael Bergbauer wrote:
> For a fews days (Dec 09, to be exact, in GMT+8), my debmirror cronjob pulling
> from ftp.us is running in an infinite loop - using up 100% of a core. After
> having a closer look, it seems that the culprit code is in lines 2460ff with a
> $_ value of e.g.  'SHA256-Current:
> d4228ed8d1591732f9a3af33f4064c4e0d173d16218d12b930d1c5de3673d7ce39582357\n',
> when parsing my .temp/dists/sid/main/binary-i386/Packages.diff/Index file.

Confirmed here too: Debsources/sources.debian.net hasn't been updated
since December 8th due to this bug.

It'd be great to have a backported debmirror with this fix.

I'll try Colin's oneliner patch as a work-around to get Debsources back
up running.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#807267: please provide a python3-twill package

[Stefano Zacchiroli]

Package: python-twill
Version: 0.9-3
Severity: normal

As per subject.

Thanks!

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-twill depends on:
ii  python2.7.9-1
ii  python-mechanize  1:0.2.5-3
ii  python-pyparsing  2.0.3+dfsg1-1
ii  python2.7 2.7.10-5+b1

Versions of packages python-twill recommends:
ii  doc-base  0.10.6

python-twill suggests no packages.

-- no debconf information

Bug#807053: ITP: flask-api -- browsable web APIs for the Flask micro web framework

[Stefano Zacchiroli]

Package: wnpp
Severity: wishlist
Owner: Stefano Zacchiroli <z...@debian.org>

* Package name: flask-api
  Version : 0.6.4
  Upstream Author : Tom Christie <t...@tomchristie.com>
* URL : http://www.flaskapi.org/
* License : BSD-2-clause
  Programming Lang: Python
  Description : browsable web APIs for the Flask micro web framework
Flask API is an implementation of the same web browsable APIs that the
Django REST framework provides. It gives you properly content negotiated
responses and smart request parsing.

The binary packages will be named python{,3}-flask-api.

The package Git repository will be put under the DPMT umbrella.

Bug#807054: ITP: flask-testing -- unit testing utilities for the Flask micro web framework

[Stefano Zacchiroli]

Package: wnpp
Severity: wishlist
Owner: Stefano Zacchiroli <z...@debian.org>

* Package name: flask-testing
  Version : 0.4.2
  Upstream Author : Dan Jacob
* URL : http://pythonhosted.org/Flask-Testing/
* License : BSD-3-clause
  Programming Lang: Python
  Description : unit testing utilities for the Flask micro web framework

(Long description forthcoming.)

The binary packages will be named python{,3}-flask.ext.testing.

The package Git repository will be put under the DPMT umbrella.

Bug#803658: boot hangs before cryptsetup passphrase prompt

[Stefano Zacchiroli]

On Sun, Nov 29, 2015 at 09:20:55PM +0100, Laurent Bigonville wrote:
> >- it now works, YAY (and thanks!). But I conclude from the whole
> >   experience that before now plymouth was somehow able to fallback to
> >   askpass after self-detecting some sort of failure, while new versions
> >   aren't any more. If that's the case, this might affect other users
> 
> Before the last update, plymouth was not enabled at all if splash was not
> passed to the kernel cmdline, now the plymouth daemon is started even if
> it's not passed, that probably explain the change of behavior.

Possibly. Although please note that "splash" *is* on my kernel cmdline,
and has been since forever.

> >- does the above mean that now non-free firmware is required to use
> >   plymouth on i915 hardware? Or was the warning about something else
> >   that is not strictly needed to make plymouth work? (sorry, I haven't
> >   yet tried to re-remove the firmware and see what happens)
>
> I'm not sure, I don't have a machine with an intel card to test, you should
> test without them.

I've tested this. Even after purging firmware-misc-nonfree (and
rebuilding the initramfs, which results in the aforementioned warning)
the boot still works fine.

> >-http://upsilon.cc/~zack/stuff/IMG_20151129_174719.jpg
> >-http://upsilon.cc/~zack/stuff/IMG_20151129_174736.jpg
> >-http://upsilon.cc/~zack/stuff/IMG_20151129_174751.jpg
>
> I cannot reproduce this without an intel card, could you please report this
> upstream?

To be frank, I don't think I've a decent enough understanding of what is
supposed to happen to be able to file a proper upstream bug report. In
particular, I've no idea of whether plymouth is supposed to work without
adding i915 to /etc/initramfs-tools/modules or not. If adding the module
there is a requirement, then arguably this bug is actually PEBKAC. But
if users (at least in Debian) started to rely on that behavior, than a
work-around might be needed. Not sure if it should be upstream or
distro-level though.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#803658: boot hangs before cryptsetup passphrase prompt

[Stefano Zacchiroli]

On Sun, Nov 29, 2015 at 02:44:55PM +0100, Laurent Bigonville wrote:
> >Do you have a KMS driver loaded in the initramfs?

After discussion on IRC, I've done the following:

- added "i915" to /etc/initramfs-tools/modules
- update-initramfs
- got a warning stating some firmware might be missing
- apt-get install firmware-misc-nonfree
- update-initramfs again (verifying that the warning is now gone)

After the above, the boot works fine.

Comments/questions:

- it now works, YAY (and thanks!). But I conclude from the whole
  experience that before now plymouth was somehow able to fallback to
  askpass after self-detecting some sort of failure, while new versions
  aren't any more. If that's the case, this might affect other users

- does the above mean that now non-free firmware is required to use
  plymouth on i915 hardware? Or was the warning about something else
  that is not strictly needed to make plymouth work? (sorry, I haven't
  yet tried to re-remove the firmware and see what happens)

> >I'm a bit surprised by the error message that I see in your 3rd picture, I
> >cannot reproduce this on my laptop even with plymouth completely disabled.
> >Did you modify anything in the initramfs scripts?
> >({/etc,/usr/share}/initramfs-tools/scripts)

I've had those messages since as long as I remember (with this laptop
having been bought in July 2014). According to debsums/etckeeper the
only relevant local change is:

- /etc/modprobe.d/dkms.conf, which is now empty, but used to contain
  commented lines. It looks like it has been emptied by some postinst
  script

> You can also try to add plymouth.debug to the kernel cmdline (or
> plymouth.debug=stream:/dev/kmsg)

I've done that, and took screenshots of all the debug messages before
the boot hangs. The 1st picture is the first page (obtained going back
up with Shift+PagUp); the 2nd picture is the 2nd page (overlapping with
the first one); the 3rd picture is the 2nd page, but in landscape rather
than portrait mode:

- http://upsilon.cc/~zack/stuff/IMG_20151129_174719.jpg
- http://upsilon.cc/~zack/stuff/IMG_20151129_174736.jpg
- http://upsilon.cc/~zack/stuff/IMG_20151129_174751.jpg

Thanks a lot for your help,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#803658: boot hangs before cryptsetup passphrase prompt

[Stefano Zacchiroli]

On Thu, Nov 26, 2015 at 11:41:55AM +0100, Stefano Zacchiroli wrote:
> I'll eagerly wait feedback from the Plymouth maintainers on how to
> help them debug this further :)

[ Following up with information that Laurent asked via IRC. ]

I've done "update-initramfs -k 3.16.0-4-amd64 -u" and I confirm that
after that also 3.16 became broken: it hangs before asking the LUKS
password, whereas it used to work before update-initramfs.

Linux 4.1 still boots properly (asking the password via askpass),
because I haven't update-initramfs'd it.

So it is something that sneaks in upon initramfs creation, and that used
not to sneak in with older plymouth versions.

I can also confirm that the workaround of passing plymouth.enable=0 on
the kernel cmdline sidesteps the problem. I'm now running 4.3 from
experimental, which boots properly with plymouth.enable=0.

Hope this helps,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#803658: boot hangs before cryptsetup passphrase prompt

[Stefano Zacchiroli]

On Wed, Nov 25, 2015 at 09:38:29PM +, Ben Hutchings wrote:
> > So this bug might deserve a reassign to plymouth, I guess.

Thanks for doing this, Ben.

I'll eagerly wait feedback from the Plymouth maintainers on how to help
them debug this further :)

> > Still, why are kernels 4.2 and 4.3 triggering plymouth usage, whereas
> > 4.1 is not? (FWIW, all my grub entries have "splash" on the kernel
> > cmdline.)
> 
> Perhaps you installed plymouth after Linux 4.2?  Only the newest
> initramfs is updated when you install plymouth (and most other
> packages that trigger an initramfs update).

No, that's not it. I've had Plymouth installed since ever. FWIW, here
are the plymouth packages I've installed on my machine:

  dpkg -l '*plymouth*'
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name  Version Architecture
  Description
  
+++-=-===-===-
  ii  libplymouth4:amd640.9.2-3 amd64 graphical boot 
animation and logger - shared libraries
  ii  plymouth  0.9.2-3 amd64 boot animation, 
logger and I/O multiplexer
  rc  plymouth-drm  0.9.0-4 amd64 Graphical Boot 
Animation and Logger (DRM)
  un  plymouth-theme   (no description 
available)
  ii  plymouth-themes   0.9.2-3 amd64 boot animation, 
logger and I/O multiplexer - themes
  un  plymouth-themes-all  (no description 
available)
  un  plymouth-themes-fade-in  (no description 
available)
  un  plymouth-themes-glow (no description 
available)
  un  plymouth-themes-script   (no description 
available)
  un  plymouth-themes-solar(no description 
available)
  un  plymouth-themes-spinfinity   (no description 
available)
  un  plymouth-themes-spinner  (no description 
available)
  ii  plymouth-x11  0.9.2-3 amd64 boot animation, 
logger and I/O multiplexer - X11 renderer

No idea why old kernel versions weren't calling plymouth to ask for the
luks password.

Just in case: is "dpkg --purge plymouth" supposed to be a safe way out
of this bug these days? Or do we now require plymouth in order to be
able to ask for luks password during boot?

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#803658: boot hangs before cryptsetup passphrase prompt

[Stefano Zacchiroli]

TL;DR: it seems to be a plymouth issue.

On Sun, Nov 22, 2015 at 10:19:12PM +, Ben Hutchings wrote:
> Can you try this:
> 
> - Boot with the added parameter: break=top
> - In the shell, run:
>       echo 1 >/proc/sys/kernel/sysrq
>       openvt
>       exit
> - Once the system has hung, press Alt-SysRq, Alt-W, Alt-SysRq, Alt-L
> - Switch to VT 2 then show the kernel log with: dmesg | less
> - Send photos of all the call traces

I haven't done all of the above, because I don't know what generates a
SysRq on ThinkPad's keyboards. Do you know? I've a T440s.  (I guess the
web would probably tell me, but I'm writing this on a plane w/o net
connection..., sorry about that.)

Nonetheless I've used the shell obtained with openvt to compare the
running processes in the linux 4.1 and 4.3 cases. In 4.1 (where the boot
works) the processes asking for the luks password is
"/lib/cryptsetup/askpass Please unlock disk sda3_crypt:" ; in 4.3 (where
the boot doesn't work) is "plymouth ask-for-password --prompt Please
unlock disk sda3_crypt". In both cases, the process with the next PID,
after askpass/plymouth, is "/sbin/cryptsetup -T 1 --allow-discards open
--type luks ".

So this bug might deserve a reassign to plymouth, I guess.

Still, why are kernels 4.2 and 4.3 triggering plymouth usage, whereas
4.1 is not? (FWIW, all my grub entries have "splash" on the kernel
cmdline.)

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#803658: boot hangs before cryptsetup passphrase prompt

[Stefano Zacchiroli]

On Sun, Nov 22, 2015 at 10:19:12PM +, Ben Hutchings wrote:
> On Sun, 01 Nov 2015 15:18:46 +0100 Stefano Zacchiroli <z...@debian.org> wrote:
> > Package: src:linux
> > Version: 4.2.3-2
> 
> Can you test whether this is fixed in 4.2.6-1 or 4.3-1~exp1?

I'll answer this first, as it was quicker to test.

I've tried the following debian-packaged kernels:

  $ dpkg -l 'linux-image*' | grep ^ii
  ii  linux-image-3.16.0-4-amd643.16.7-ckt11-1 amd64Linux 3.16 for 
64-bit PCs
  ii  linux-image-4.1.0-2-amd64 4.1.6-1amd64Linux 4.1 for 
64-bit PCs
  ii  linux-image-4.2.0-1-amd64 4.2.6-1amd64Linux 4.2 for 
64-bit PCs
  ii  linux-image-4.3.0-trunk-amd64 4.3-1~exp1 amd64Linux 4.3 for 
64-bit PCs

Results:

- work:   3.16.7, 4.1.6
- don't work: 4.2.6,  4.3

As an additional data point, before your mail I already had installed
all kernels above except 4.3, which I just installed from experimental.

It seems to me that: (a) it's due to something fairly recent and that is
still lingering around in 4.3; (b) it is not something transient --- in
particular I was thinking at something weird that might have happened
one off with the initram creation just for 4.2, but that doesn't seem
the case.

I'll follow-up in separate mail providing the other debug information
you've asked. It might take a couple of days though, as I'm currently
traveling.

Thanks for your help!
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#801951: debian/copyright should mention BSD3 license, not PSF

[Stefano Zacchiroli]

Package: python3-dateutil
Version: 2.2-2
Severity: important

debian/copyright currently refers to (various incarnations of...) the PSF
license, whereas python-dateutil has been relicense under BSD3 a while ago.
See http://sources.debian.net/src/python-dateutil/latest/LICENSE/ for
reference. debian/copyright should be updated (and can be widely simplified /
shortened) to refer to BSD3.

Thanks a lot for maintaining python-dateutil in Debian, it's much appreciated!

Cheers.

-- System Information:
Debian Release: stretch/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-dateutil depends on:
ii  python3-six  1.10.0-1
pn  python3:any  
ii  tzdata   2015g-1

python3-dateutil recommends no packages.

python3-dateutil suggests no packages.

-- no debconf information

Bug#799779: integrate autopkgtest/DEP8 specification into debian-policy

[Stefano Zacchiroli]

On Sun, Oct 11, 2015 at 06:01:59PM +0200, Bill Allombert wrote:
> Hello Stefano, I have created a git branch bug799779-bill with your
> patch. I needed to change a little, please review (in attachment).

Looks good to me.

> > There have been some requested format changes (see thread), which I
> > didn't have time to implement. They're now up for grabs, hurry up!
> > :-)
> 
> If I do the conversion, would you review the new version for translation
> error ?

I can certainly have a look. However, as I'm not active myself in the
autopkgtest team these days, it'd be better to keep the
autopkgtest-devel list in the loop (I'm Cc:-ing it now). Autopkgtesters:
you might want to subscribe to this policy bug report and keep an eye on
this.

> Thanks for moving forward with this,

Same :)

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#801571: do not suggest to use "*apt-get* autoremove" when using *apt*

[Stefano Zacchiroli]

Package: apt
Version: 1.1~exp12
Severity: wishlist

I'm using /usr/bin/apt and loving it. As a minor glitch, when there are
packages that could be autoremoved, I get the following message:

  Use 'apt-get autoremove' to remove them.

Given "apt autoremove" works as well, it would be nice to point /usr/bin/apt
users to that, rather than pointing them to /usr/bin/apt-get.

Thanks for (/usr/bin/)apt!

-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (/etc/apt/sources.list present, but not submitted) --


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apt depends on:
ii  adduser 3.113+nmu3
ii  debian-archive-keyring  2014.3
ii  gnupg   1.4.19-5
ii  gnupg2  2.0.28-3
ii  gpgv1.4.19-5
ii  libapt-pkg5.0   1.1~exp12
ii  libc6   2.19-22
ii  libgcc1 1:5.2.1-21
ii  libstdc++6  5.2.1-21

apt recommends no packages.

Versions of packages apt suggests:
ii  apt-doc 1.1~exp8
ii  aptitude0.7.2-1
ii  dpkg-dev1.18.3
ii  python-apt  1.0.1

-- no debconf information

Bug#799779: integrate autopkgtest/DEP8 specification into debian-policy

[Stefano Zacchiroli]

Package: debian-policy
Severity: wishlist
Tags: patch

I'm filing this bug report to avoid losing track of the discussion we've had in
July 2014 about merging the autopkgtest/DEP8 specification into Debian Policy.
The thread is archived starting from here:

  https://lists.debian.org/debian-policy/2014/07/msg00057.html

I've posted draft patches implementing what was discussed in the thread at the
time; I'm attaching them to this message as patches.

There have been some requested format changes (see thread), which I didn't have
time to implement. They're now up for grabs, hurry up! :-)

Cheers.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From 8440fe8b2bef5f99bddf3deb141a8c4b4b0354f9 Mon Sep 17 00:00:00 2001
From: Stefano Zacchiroli <z...@debian.org>
Date: Sun, 5 Oct 2014 23:41:40 +0200
Subject: [PATCH 1/2] autopkgtest: new specification for autopkgtest/DEP-8
 tests

---
 .gitignore |   4 +
 autopkgtest.desc   |  13 ++
 autopkgtest/Makefile   |  13 ++
 autopkgtest/autopkgtest.md | 305 +
 debian/control |   4 +-
 debian/rules   |  14 ++-
 6 files changed, 351 insertions(+), 2 deletions(-)
 create mode 100644 autopkgtest.desc
 create mode 100644 autopkgtest/Makefile
 create mode 100644 autopkgtest/autopkgtest.md

diff --git a/.gitignore b/.gitignore
index 5c80ed5..66b5940 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,5 +1,9 @@
 /Process.html
 /README.html
+/autopkgtest/version.txt
+/autopkgtest/*.expanded
+/autopkgtest/*.html
+/autopkgtest/*.txt.gz
 /copyright-format/copyright-format-1.0.html
 /copyright-format/version.xml
 /debconf_spec/debconf_specification.html
diff --git a/autopkgtest.desc b/autopkgtest.desc
new file mode 100644
index 000..dc7ea40
--- /dev/null
+++ b/autopkgtest.desc
@@ -0,0 +1,13 @@
+Document: autopkgtest
+Title: automatic as-installed package test specification
+Author: The Debian Project
+Abstract: Specification for automatic as-installed (AKA "autopkgtest",
+  or DEP-8) tests for Debian packages
+Section: Debian
+
+Format: text
+Files: /usr/share/doc/debian-policy/package-tests.txt.gz
+
+Format: HTML
+Index: /usr/share/doc/debian-policy/package-tests.html
+Files: /usr/share/doc/debian-policy/package-tests.html
diff --git a/autopkgtest/Makefile b/autopkgtest/Makefile
new file mode 100644
index 000..9552f38
--- /dev/null
+++ b/autopkgtest/Makefile
@@ -0,0 +1,13 @@
+all: autopkgtest.html autopkgtest.txt.gz
+
+autopkgtest.html: autopkgtest.md.expanded
+	markdown $< > $@
+
+autopkgtest.txt.gz: autopkgtest.md.expanded
+	gzip -cf9 $< > $@
+
+autopkgtest.md.expanded: autopkgtest.md version.txt
+	cat $^ > $@
+
+clean:
+	rm -f autopkgtest.html autopkgtest.txt.gz $(wildcard *.expanded)
diff --git a/autopkgtest/autopkgtest.md b/autopkgtest/autopkgtest.md
new file mode 100644
index 000..c9f6d77
--- /dev/null
+++ b/autopkgtest/autopkgtest.md
@@ -0,0 +1,305 @@
+Autopkgtest - Defining tests for Debian packages
+
+
+This document describes how the autopkgtest tester core (the program
+`adt-run`) interprets and executes tests found in Debian source
+packages.
+
+Overview
+
+
+The source package provides a test metadata file `debian/tests/control`.
+This is a file containing zero or more RFC822-style stanzas, along these
+lines:
+
+Tests: fred bill bongo
+Restrictions: needs-root breaks-testbed
+
+This example defines three tests, called `fred`, `bill` and `bongo`. The
+tests will be performed by executing `debian/tests/fred`,
+`debian/tests/bill`, etc. Each test program should, on success, exit
+with status 0 and print nothing to stderr; if a test exits nonzero, or
+prints to stderr, it is considered to have failed.
+
+The cwd of each test is guaranteed to be the root of the source package,
+which will have been unpacked but not built. *However* note that the
+tests must test the *installed* version of the program. Tests may not
+modify the source tree (and may not have write access to it).
+
+If the file to be executed has no execute bits set, `chmod a+x` is
+applied to it (this means that tests can be added in patches without the
+need for additional chmod; contrast this with debian/rules).
+
+During execution of the test, the environment variable `$ADTTMP` will
+point to a directory for the execution of this particular test, which
+starts empty and will be deleted afterwards (so there is no need for the
+test to clean up files left there).
+
+If tests want to create artifacts which are useful to attach to test
+results, such as additional log files or screenshots, the

Bug#799782: Packages not updated when .deb file takes a while to be copied/created

[Stefano Zacchiroli]

Package: local-apt-repository
Version: 0.2
Severity: normal

When creation of .deb files takes a while, the Packages file index under
/var/lib might miss the addition of new packages to the repository.

I've reproduced the problem with at least two use cases:

1) executing dpkg-repack directly in /srv/local-apt-repository
2) wgetting packages directly in /srv/local-apt-repository

in both cases, if I first create/download the .deb file to a separate dir, and
then mv it to /srv/local-apt-repository, the Packages index is updated just
fine. As a workaround for the problem, moving away the .deb from
/srv/local-apt-repository and moving it back in works fine.

I haven't debugged this thoroughly, but the feeling is that
local-apt-repository gets a notification of the new .deb file too soon, when
then file is still incomplete (or possibly empty), and skips it. Then, it gets
no other notification when the .deb file has been fully copied/built.

Thanks a lot for local-apt-repository, it's a great tool!

Cheers.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages local-apt-repository depends on:
ii  dpkg-dev 1.18.2
ii  init-system-helpers  1.23
ii  systemd  225-1

local-apt-repository recommends no packages.

local-apt-repository suggests no packages.

-- no debconf information

Bug#747094: Updated Patch

[Stefano Zacchiroli]

On Wed, Sep 09, 2015 at 10:56:21AM +0200, Stefano Zacchiroli wrote:
> Thanks for your patch! I've now rebuilt a local bash-completion that
> uses it, and it's just great.

BTW, why is this patch number 14 in the series rather than 13?

I thought that was because another patch numbered 13 was in the series
on the Ubuntu side, but according to
https://patches.ubuntu.com/b/bash-completion/bash-completion_1:2.1-4.1ubuntu2.patch
that doesn't seem to be the case.

Not that I care *that* much :), I'm just trying to figure out whether
some other patches from Ubuntu should be integrated or not.

TIA,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Bug#747094: Updated Patch

[Stefano Zacchiroli]

On Thu, Aug 13, 2015 at 09:31:57AM -0700, Brian Murray wrote:
> Michael's patch was actually incomplete, I'm attaching an updated
> version which completely adds apt support and is now in Ubuntu.

Thanks for your patch! I've now rebuilt a local bash-completion that
uses it, and it's just great.

Small feature request: "apt install" can now (with the version of apt in
experimental, at least) install local .deb packages, and resolve
dependencies as needed. So it'd be nice if "apt install " would
also complete with local *.deb files on the filesystem. Do you think you
can add that?

FWIW, I'm considering NMU-ing to DELAYED/XX bash-completion to fix this
specific bug, as I think it'd help quite a bit with the adoption of the
new apt command. (But, anyone, feel free to beat me at it!)

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Bug#797359: ITP: universal-ctags -- Generates an index (or tag) file of names found in source files

[Stefano Zacchiroli]

Thanks for your answer, Víctor!

On Mon, Aug 31, 2015 at 10:14:10AM +0200, Víctor Cuadrado Juan wrote:
> You can read a somewhat comprehensive list of changes from upstream
> here[1], and more info here[2].

Very helpful!

Last question: are you aware of any performance comparison between
exuberant-ctags and universal-ctags?

-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#797359: ITP: universal-ctags -- Generates an index (or tag) file of names found in source files

[Stefano Zacchiroli]

On Sun, Aug 30, 2015 at 12:44:44AM +0200, Víctor Cuadrado Juan wrote:
 * Package name: universal-ctags
 * URL : https://ctags.io/
  A continuation of the exuberant-ctags implementation of the ctags

Hey, can you elaborate a bit on how universal-ctags compare to
exuberant-ctags? This is by no means an objection to packaging this, but
as a heavy user of exuberant-ctags for Debsources, I'm curious about how
the two compares, specifically in terms of performances and language
support.

Thanks!
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Bug#796710: moving a key signature to the correct place loop

[Stefano Zacchiroli]

Package: gnupg
Version: 1.4.19-3
Severity: normal
Tags: upstream

[ filing the bug report, as discussed with dkg and Clint at DebConf 15 ]

Below you can find the screen log of a gpg session that, using a fresh
GNUPGHOME:

1) fetch/reresh my key from the SKS keyserver pool
2) edit the key...
3) ...resulting in gpg moving a key signature to the correct place
   multiple times
4) save the key
5) go to 1

i.e. it seems that whatever fixing gpg does to the wrong packages that
are present in the key material, it is undone by the next refresh from
the keyserver. Allegedly, this is a bug in both gpg and the keyserver
software running on the SKS pool.

Note that in the session below I did also try a second edit after
saving, without refreshing, and that does not make gpg trying to move
the signatures again. I.e. it seems that gpg fixing is stable on disk;
it is just not stable w.r.t. the key server.

I've also tested this with gpg2, obtaining the same result.

Cheers.



zack@timira:~$ export KEYID=6D866396
zack@timira:~$ export GNUPGHOME=/tmp/gpg-bug
zack@timira:~$ mkdir -m 700 $GNUPGHOME
zack@timira:~$ gpg --keyserver pool.sks-keyservers.net --recv-keys $KEYID
gpg: keyring `/tmp/gpg-bug/secring.gpg' created
gpg: keyring `/tmp/gpg-bug/pubring.gpg' created
gpg: requesting key 6D866396 from hkp server pool.sks-keyservers.net
gpg: /tmp/gpg-bug/trustdb.gpg: trustdb created
gpg: key 6D866396: public key Stefano Zacchiroli z...@upsilon.cc imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:   imported: 1  (RSA: 1)

zack@timira:~$ gpg --edit-key $KEYID
gpg (GnuPG) 1.4.19; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: moving a key signature to the correct place
gpg: moving a key signature to the correct place
gpg: moving a key signature to the correct place
gpg: moving a key signature to the correct place
gpg: moving a key signature to the correct place
gpg: moving a key signature to the correct place
gpg: moving a key signature to the correct place
gpg: moving a key signature to the correct place
gpg: moving a key signature to the correct place
gpg: moving a key signature to the correct place
gpg: moving a key signature to the correct place
gpg: moving a key signature to the correct place
gpg: moving a key signature to the correct place
gpg: moving a key signature to the correct place
gpg: moving a key signature to the correct place

pub  4096R/6D866396  created: 2010-09-27  expires: 2016-09-02  usage: SC  
 trust: unknown   validity: unknown
sub  4096R/02D0E74C  created: 2010-09-27  expires: never   usage: E   
sub  4096R/93412799  created: 2012-12-01  expires: 2016-09-02  usage: S   
[ unknown] (1). Stefano Zacchiroli z...@upsilon.cc
[ unknown] (2)  Stefano Zacchiroli z...@debian.org
[ unknown] (3)  Stefano Zacchiroli z...@cs.unibo.it
[ revoked] (4)  Stefano Zacchiroli z...@pps.jussieu.fr
[ unknown] (5)  Stefano Zacchiroli z...@pps.univ-paris-diderot.fr
[ revoked] (6)  Stefano Zacchiroli (Debian Project Leader) lea...@debian.org

gpg save

zack@timira:~$ gpg --edit-key $KEYID
gpg (GnuPG) 1.4.19; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


pub  4096R/6D866396  created: 2010-09-27  expires: 2016-09-02  usage: SC  
 trust: unknown   validity: unknown
sub  4096R/02D0E74C  created: 2010-09-27  expires: never   usage: E   
sub  4096R/93412799  created: 2012-12-01  expires: 2016-09-02  usage: S   
[ unknown] (1). Stefano Zacchiroli z...@upsilon.cc
[ unknown] (2)  Stefano Zacchiroli z...@debian.org
[ unknown] (3)  Stefano Zacchiroli z...@cs.unibo.it
[ revoked] (4)  Stefano Zacchiroli z...@pps.jussieu.fr
[ unknown] (5)  Stefano Zacchiroli z...@pps.univ-paris-diderot.fr
[ revoked] (6)  Stefano Zacchiroli (Debian Project Leader) lea...@debian.org

gpg quit

zack@timira:~$ gpg --keyserver pool.sks-keyservers.net --recv-keys $KEYID
gpg: requesting key 6D866396 from hkp server pool.sks-keyservers.net
gpg: key 6D866396: Stefano Zacchiroli z...@upsilon.cc 13 new signatures
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: new signatures: 13

zack@timira:~$ gpg --edit-key $KEYID
gpg (GnuPG) 1.4.19; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: moving a key signature to the correct place
gpg: moving a key signature to the correct place
gpg: moving a key signature to the correct place
gpg: moving a key signature to the correct place
gpg: moving a key signature to the correct place
gpg: moving a key signature to the correct place
gpg: moving a key

Bug#796425: notmuch-mutt: search (via F8) is broken when there are new messages in mailboxes

[Stefano Zacchiroli]

On Sat, Aug 22, 2015 at 10:07:17AM +0200, Tomasz Buchert wrote:
  How (often) do you run notmuch new?
 After each offlineimap run.

OK.

 So when I say new mail I don't literally mean newly synced
 messages, but only messages that are in new/ maildir. I now
 remember that I also have a personal patch on offlineimap:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789625

If this is related to the general indexing ability of notmuch
w.r.t. offlineimap, then I guess it would not be a bug in notmuch-mutt.

But still, I'm not 100% sure we are on the same page.

First of all, I cannot reproduce it using mutt only. I've tried flipping
the new bit in mutt, sync the maildir (which moves mails to the new/
subdir), and try reconstructing the thread after that. As expected, if I
do *not* run notmuch new before searching, the thread will be
incomplete. But this is not a bug, is just the trade-off of notmuch
non-synchronous updates. If I do run notmuch new and then search, the
thread is complete; again, as expected.

Do you confirm you have the same behaviour, using mutt?

Then I've tried to do the same with offlineimap, verifying that the mail
in new has the trailing :2, or similar. To be sure, I've interrupted
offlineimap before it completes the sync, ensuring that notmuch new
does not kick in.  As expected, notmuch cannot rebuild the complete
thread. But, after a notmuch new, it is able to do so.

So it still seems to me that there is no bug here or, alternatively,
that there is one I cannot reproduce.

Might it be that you're looking at your maildirs while offlineimap is
still running? In that case, you will immediately see new mail, but
notmuch new hasn't been run yet, so notmuch is unaware of new
messages.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#796425: notmuch-mutt: search (via F8) is broken when there are new messages in mailboxes

[Stefano Zacchiroli]

On Fri, Aug 21, 2015 at 10:11:22PM +0200, Tomasz Buchert wrote:
 when I try to search or rebuild thread in mutt and there
 are some new messages in my mailboxes, the operation does
 not do what promised, but jumps into mailbox with a
 new message instead.

How (often) do you run notmuch new?

According to your description it seems to me that you're running the F8
query before notmuch has had a chance to reindex, and hence realize that
the new messages belong to some previously existing threat. In that
situation, notmuch search will consider the new messages as part of
singleton message threads.

If this is the problem you're facing, I recommend plugging notmuch new
into the tool you use to retrieve mail, e.g., as an offlineimap hook. If
this is not the problem you're facing, I guess I'd need a reproducible
test, because I've no (other) idea of what's going on :)

Thanks for your bug report!
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Bug#795383: please add a License field parser to the copyright module

[Stefano Zacchiroli]

Package: python-debian
Version: 0.1.27
Severity: wishlist

The debian.copyright module returns the content of the License field as a
string, matching the literal value written down in the debian/copyright file.

It would be nice (and will avoid duplicate work) if the module would offer a
way to traverse the content of the License field as an AST, conformant to the
semantics of machine-readable debian/copyright files.

The AST should include at the very minimum boolean and/or combination of
licenses (implementing the semantics of , properly). Additionally, the AST
could distinguish between trailing + for or later license variants, and
support with for license exceptions.

FWIW, Debsources would use this feature for rendering machine-readable
copyright fiels if it were available.

Cheers.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-debian depends on:
ii  python-chardet  2.3.0-1
ii  python-six  1.9.0-3
pn  python:any  none

Versions of packages python-debian recommends:
ii  python-apt  1.0.0~beta3

Versions of packages python-debian suggests:
ii  gpgv  1.4.19-3

-- no debconf information

Bug#789647: fails to talk to quvi to download from youtube on jessie

[Stefano Zacchiroli]

On Mon, Jun 22, 2015 at 08:55:35PM -0400, Antoine Beaupré wrote:
 Package: git-annex
 Version: 5.20141125
 Severity: normal
 
 It seems this version of git-annex can't talk to quvi properly, even
 though quvi can talk to youtube:

Just confirming this bug.

(FWIW I'm on Debian Stretch, but the git-annex version is the same.)

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#788095: closed by Thomas Goirand z...@debian.org (Issue fixed in pygit2 0.22.0-2?)

[Stefano Zacchiroli]

reopen 788095
thanks

On Mon, Jun 08, 2015 at 02:21:10PM +, Debian Bug Tracking System wrote:
 I tried, and I couldn't reproduce the issue. If you still see the
 issue with version 0.22.0-2, please reopen this bug.

I've installed (on testing) pygit2 from unstable, in the version you
mentioned, and I can reproduce the bug.

Again, rebuilding the package on my machine from sources (in the version
above) fixed the issue.

Cheers
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Bug#788226: debsources: add package/version blacklist

[Stefano Zacchiroli]

Package: qa.debian.org
Severity: wishlist
User: qa.debian@packages.debian.org
Usertags: debsources

It would be nice to have a configurable package/version (and possibly /suite)
blacklist, to exclude specific packages from processing.

Use case: due to #753219 and #787271, we now have katoob/0.5.9.1-1.2+squeeze1
and moodle/1.9.9.dfsg2-2.1+squeeze4 which are not extractable. But nonetheless
the updater try to extract them at every single update run, and fails.  It's
not a big deal for such small packages, but if it were to happen for lager
packages it would be a problem.

A blacklist would allow to ignore specific packages during update runs.

Cheers.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#788095: can't load pygit2: PermissionError: [Errno 13] Permission denied: '/usr/lib/python3/dist-packages/pygit2/__pycache__/pygit2_cffi_ea785866x5470904.c'

[Stefano Zacchiroli]

Package: python3-pygit2
Version: 0.22.0-1
Severity: serious

It looks like pygit2 is not loadable in testing:

  zack@timira:~$ python3
  Python 3.4.3+ (default, Jun  2 2015, 14:09:35) 
  [GCC 4.9.2] on linux
  Type help, copyright, credits or license for more information.
   import pygit2
  Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python3/dist-packages/pygit2/__init__.py, line 35, in 
module
  from .blame import Blame, BlameHunk
File /usr/lib/python3/dist-packages/pygit2/blame.py, line 32, in module
  from .errors import check_error
File /usr/lib/python3/dist-packages/pygit2/errors.py, line 29, in module
  from .ffi import ffi, C
File /usr/lib/python3/dist-packages/pygit2/ffi.py, line 35, in module
  ffi, C = get_ffi()
File /usr/lib/python3/dist-packages/pygit2/_utils.py, line 101, in get_ffi
  include_dirs=[libgit2_include], library_dirs=[libgit2_lib])
File /usr/lib/python3/dist-packages/cffi/api.py, line 340, in verify
  lib = self.verifier.load_library()
File /usr/lib/python3/dist-packages/cffi/verifier.py, line 73, in 
load_library
  self._write_source()
File /usr/lib/python3/dist-packages/cffi/verifier.py, line 125, in 
_write_source
  file = open(self.sourcefilename, 'w')
  PermissionError: [Errno 13] Permission denied: 
'/usr/lib/python3/dist-packages/pygit2/__pycache__/pygit2_cffi_ea785866x5470904.c'

(FWIW, the same problem applies to the Python 2 package.)

Cheers

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-pygit2 depends on:
ii  dpkg  1.17.25
ii  libc6 2.19-18
ii  libgit2-220.22.2-2
ii  python3   3.4.2-2
ii  python3-cffi  0.8.6-1

python3-pygit2 recommends no packages.

Versions of packages python3-pygit2 suggests:
pn  python-pygit2-doc  none

-- 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#788095: can't load pygit2: PermissionError: [Errno 13] Permission denied: '/usr/lib/python3/dist-packages/pygit2/__pycache__/pygit2_cffi_ea785866x5470904.c'

[Stefano Zacchiroli]

FYI: rebuilding the package in testing with apt-get source -b fixed
the problem.

Cheers
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787570: debsources: DB: change sha256 column data type from string to bytea or bit string

[Stefano Zacchiroli]

Package: qa.debian.org
Severity: normal
User: qa.debian@packages.debian.org
Usertags: debsources

Currently, the sha256 column of the checksum table in Debsources' Postgres DB
has type character varying(64):

  sha256 | character varying(64) | not null
 
Such a data type is wasteful in terms of disk space. And it shows:

  debsources= select count(*) from checksums;
count
  --
   41151812

  public | checksums| table| debsources | 4890 MB|

We should switch to a more economic (and efficient) data type for storing
sha256 checksums. Good options seem to be either bytea [1] or fixed-size bit
strings [2]. Suggestions welcome!

A good, concrete way to help with this bug would be providing sample SQL
snippets to create temporary tables with the new data types, and convert /
inject into them the content of the current checksum table. That would allow to
easily benchmark disk usage and query/index efficiency.

Cheers.

[1]: http://www.postgresql.org/docs/9.4/static/datatype-binary.html#AEN5497
[2]: http://www.postgresql.org/docs/9.4/static/datatype-bit.html
   
-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787271: dpkg-source fails to extract old-old-stable version of moodle

[Stefano Zacchiroli]

Package: moodle
Version: 1.9.9.dfsg2-2.1+squeeze4
Severity: serious

Heya,

on the old-old-stable version of moodle, dpkg-source -x fails with a non-zero
exit code:

  zack@timira:/tmp$ dpkg-source -x moodle_1.9.9.dfsg2-2.1+squeeze4.dsc
  dpkg-source: info: extracting moodle in moodle-1.9.9.dfsg2
  dpkg-source: info: unpacking moodle_1.9.9.dfsg2.orig.tar.gz
  dpkg-source: info: unpacking moodle_1.9.9.dfsg2-2.1+squeeze4.debian.tar.gz
  dpkg-source: info: applying MDL-23377
  dpkg-source: info: applying MDL-24810
  dpkg-source: info: applying MDL-24258
  dpkg-source: info: applying cas1.1.3
  dpkg-source: info: applying yui_file_renames
  dpkg-source: info: applying MDL-24523
  dpkg-source: info: applying MDL-18839
  dpkg-source: info: applying MDL-25122
  dpkg-source: info: applying MDL-25754
  dpkg-source: info: applying MDL-26030
  dpkg-source: info: applying MDL-26189
  dpkg-source: info: applying MDL-26966
  dpkg-source: info: applying MDL-23872
  dpkg-source: info: applying MDL-27464
  dpkg-source: info: applying MDL-27889
  dpkg-source: info: applying MDL-28197
  dpkg-source: info: the patch has fuzz which is not allowed, or is malformed
  dpkg-source: info: if patch 'MDL-28197' is correctly applied by quilt, use 
'quilt refresh' to update it
  dpkg-source: error: expected ^--- in line 21 of diff 
`moodle-1.9.9.dfsg2/debian/patches/MDL-28197'
  zack@timira:/tmp$ echo $?
  2
  zack@timira:/tmp$

Cheers.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#753219: katoob: FTBFS: dpkg-source: error: expected ^--- in line 2 of diff `katoob-0.5.9.1/debian/patches/replace_fribidi-config_pkg-config.patch'

[Stefano Zacchiroli]

On Sat, May 30, 2015 at 10:04:08PM +0200, Guillem Jover wrote:
 This wont be fixed in dpkg, that change was necessary to fix a
 security issue in dpkg. In many cases it made visible existing broken
 patches, like the one in moodle, which before the dpkg fix was only
 getting partially applied, which renders that moodle security fix
 partially moot. In others the patch was malformed and patch would
 apply it correctly, but making dpkg try to distinguish between
 malformed or malfeasant patches would go from either impossible,
 too difficult or an arms race.

Oh, I see, thanks for clarifying --- I had misinterpreted this as a
regression in dpkg, while in fact it's a feature then.

I'll check for fixes in the relevant packages then. FWIW, right now the
only extraction failures I've noticed from the Debsources POV are moodle
and katoob (but it is possible there are others, which I'm not seeing
simply because they have been extracted in the past).

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Bug#753219: katoob: FTBFS: dpkg-source: error: expected ^--- in line 2 of diff `katoob-0.5.9.1/debian/patches/replace_fribidi-config_pkg-config.patch'

[Stefano Zacchiroli]

Heya,

On Sun, Jul 06, 2014 at 11:04:09AM +0200, Guillem Jover wrote:
 This also affects stable, it would be nice if a stable update could be
 prepared, I'm ready to help if needed, given that the “regression” was
 caused by the dpkg update.

FWIW I've noticed in Debsources logs both this issue, and what seems to
be another occurrence of it on the moodle package. I've now reported it
here https://bugs.debian.org/787271

Is there a dpkg update planned to fix this in stable (or oldstable)?
If so, I'll be glad to test it on the sources.d.n machine.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Bug#783832: debsources: reenable the file count assertion that fails on travis builds

[Stefano Zacchiroli]

retitle 783832 re-enable all tests in travis build environment
thanks

On Thu, Apr 30, 2015 at 04:52:09PM +0200, Stefano Zacchiroli wrote:
 The assertion disabled in that commit should be reenabled. Before doing that,
 though, we should figure out why it fails in the travis CI environment.

The above is now fixed --- in the sense that the assertion has been
reenabled (for general use), and selectively disabled only in travis
builds, via the @notravis nose attribute.

However, we do want to run all tests also in travis builds. This bug
will track the need of doing that.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783911: debsources: old news page

[Stefano Zacchiroli]

Package: qa.debian.org
Severity: minor
Tags: newcomer
User: qa.debian@packages.debian.org
Usertags: debsources

Similarly to the current local/sources_news.html page, we should support
sources_old_news.html, and (manually) move there old news that are no longer
relevant enough to be shown on the front page.

When sources_old_news.html is present on disk, the front page should also have
a old news... link pointing to it.

Cheers.

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org