Bug#1072760: Bug#1072643: Bug#1072760: ikiwiki: FTBFS: Parse errors: No plan found in TAP output

[Jonathan Dowland]

On Tue Jun 11, 2024 at 11:40 PM BST, Martin Quinson wrote:
> That's really astonishing for me. I could not imagine that this function is
> called by someone else than po4a itself...
>
> This bug is related to https://github.com/mquinson/po4a/issues/504 which
> requires a documentation improvement in po4a, but the bug to fix is in 
> ikiwiki.
> You should update your calls to this function to follow the prototype
> modification. I'm sorry about that, but I fail to see another option.

No problem. I'll make that change. Further work will be required, too:
we were also calling the methods ->detected_charset and ->set_charset,
which have been removed (but we can pass utf-8 as the third argument to
read() now); there might be more to do as well.

I didn't write this module, so I don't know the reason we're using
internal methods and suchlike, or if we could do what we need whilst
avoiding that.

> Sorry about the inconvenience, but please people, do not CC both bugs
> as they are unrelated.

Noted.


Thank you,

-- 
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#1072760: ikiwiki: FTBFS: Parse errors: No plan found in TAP output

[Jonathan Dowland]

On Fri, Jun 07, 2024 at 05:22:32PM +0200, Santiago Vila wrote:
> During a rebuild of all packages in unstable, your package failed to build:
…
> t/po.t   (Wstat: 65280 (exited 255) Tests: 38 Failed: 0)
>   Non-zero exit status: 255
>   Parse errors: No plan found in TAP output

On the face of it this looks to be a result of po4a changes. I'm not
sure if the root cause is the same as #1072643 yet; further
investigation is required.


-- 
      Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#1067303: trash-cli in Debian: test problems again

[Jonathan Dowland]

Hi Boyuan (and Andrea)

On Tue May 28, 2024 at 8:08 PM BST, Boyuan Yang wrote:
> On Sun, 26 May 2024 14:04:40 +0200 Andrea Francia  
> wrote:
> > Hi Jonathan and Lucas,
> >   I solved the problem in the new release (0.24.5.26).

That's great news! I' dli

> Can you take a look and prepare a new release into Sid recently? If not,
> would you mind a NMU into DELAYED/15 with the fix included?

I'll take a look Today. I'm otherwise happy for NMUs, I'm on the Low
Threshold NMU list.


Best wishes,

-- 

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#1067303: trash-cli in Debian: test problems again

[Jonathan Dowland]

Hi Andrea

I'm afraid we've hit problems running the trash-cli test suite in Debian
again. Our automated processes have removed the package from "testing"
for the time being.

A trace of the errors is available here:
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067303>

It looks like the Debian packaging invokes pytest to run the test suite.
Does that make sense today?

The errors are all of the form

> E   ModuleNotFoundError: No module named 'scripts'

which implies an import path issue. Any clues?

I've explored moving to your latest tag, and also trying to use tox for
running the test suite, but I haven't got something that passes yet.
(For tox the issue is that the test suite needs to run offline, so it
behaves very differently to if I just ran "tox" on my developer machine,
which worked after I adjusted Python 3.10 to 3.11 in tox.ini and changed
one test.)

If you've got any time or clues or suggestions about what to try next
I'd really appreciate it. I don't do much Python packaging (trash-cli
is currently my own Python package) and I have trouble keeping up with
what the current Python test, build, project, configure fashions are, as
well as the same for the Debian packaging layer (we've had several
Debian/Python build integrations over the years too).



Best wishes,

-- 
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#1004693: vfs_fruit module is in the binary package samba-vfs-modules

[Jonathan Dowland]

From what I can determine, the affected module is distributed in the
samba-vfs-modules package, so any worried users trying to figure out
whether they are vulnerable or not, check whether this package is
installed: if not, you likely aren't.


--
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#855837: golang-petname: Do not include in stretch at request of maintainer

[Jonathan Dowland]

Hi Ivo,

I'm copying the Maintainers: email here (go list)

On Fri, Feb 05, 2021 at 10:21:46AM +0100, Ivo De Decker wrote:

I uploaded this as a dependency of LXD which unfortunately we did not finish
packaging in time for the Stretch freeze. As such, unless someone else is
prepared to help support it, and/or users of this package come out of the
woodwork, I do not think we should include this library in Stretch.


You filed this bug in 2017, and closed this in may 2020. However, there hasn't
been any update of this package in debian, and you removed yourself from
uploaders (in git). 


I think I closed in in May because I believed the package was otherwise
being looked after, and I've had nothing to do with it for years.
However, a look at tracker.debian.org suggests the only other uploader
was Michael Stapelberg who I believe has left Debian.

I recall the upstream maintainer, Dustin Kirkland, was interested in
working on the package, but I don't know if that's still the case.


Is there any point of shipping it in bullseye?


I doubt it, but I'm not qualified to judge any more.

If nobody in the Debian Go Packaging Team is interested in it, it's
probably worth officially orphaning.


Best wishes,

--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#969901: torbrowser-launcher: depends on /usr/bin/gpg2 but dependency not expressed

[Jonathan Dowland]

Package: torbrowser-launcher
Version: 0.3.2-11~bpo10+1
Severity: serious
Justification: Policy 3.5

There's a few things going on in this session, but this bug report is
about the last backtrace in particular:

$ torbrowser-launcher
Tor Browser Launcher
By Micah Lee, licensed under MIT
version 0.3.2
https://github.com/micahflee/torbrowser-launcher
Creating GnuPG homedir /home/jon/.local/share/torbrowser/gnupg_homedir
Downloading Tor Browser for the first time.
Downloading 
https://aus1.torproject.org/torbrowser/update_3/release/Linux_x86_64-gcc3/x/en-US
Latest version: 9.5.4
Downloading 
https://dist.torproject.org/torbrowser/9.5.4/tor-browser-linux64-9.5.4_en-US.tar.xz.asc
Downloading 
https://dist.torproject.org/torbrowser/9.5.4/tor-browser-linux64-9.5.4_en-US.tar.xz
Verifying Signature
Refreshing local keyring...
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/torbrowser_launcher/launcher.py", line 
589, in verify
c.verify(signature=sig, signed_data=signed)
  File "/usr/lib/python3/dist-packages/gpg/core.py", line 559, in verify
raise errors.BadSignatures(results[1], results=results)
gpg.errors.BadSignatures: 110775B5D101FB36BC6C911BEB774491D9FF06E2: Key expired

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/torbrowser_launcher/launcher.py", line 
600, in run
verify()
  File "/usr/lib/python3/dist-packages/torbrowser_launcher/launcher.py", line 
594, in verify
raise Exception
Exception

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/torbrowser_launcher/launcher.py", line 
603, in run
self.common.refresh_keyring()
  File "/usr/lib/python3/dist-packages/torbrowser_launcher/common.py", line 
209, in refresh_keyring
'--refresh-keys'], stderr=subprocess.PIPE)
  File "/usr/lib/python3.7/subprocess.py", line 775, in __init__
restore_signals, start_new_session)
  File "/usr/lib/python3.7/subprocess.py", line 1522, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: '/usr/bin/gpg2': 
'/usr/bin/gpg2'
Aborted




-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages torbrowser-launcher depends on:
ii  ca-certificates   20190110
ii  libdbus-glib-1-2  0.110-4
ii  python3   3.7.3-1
ii  python3-gpg   1.12.0-6
ii  python3-pyqt5 5.11.3+dfsg-1+b3
ii  python3-requests  2.21.0-1
ii  python3-socks 1.6.8+dfsg-1

Versions of packages torbrowser-launcher recommends:
ii  tor  0.3.5.10-1

Versions of packages torbrowser-launcher suggests:
ii  apparmor  2.13.2-10

-- no debconf information

Bug#936146: archivemail - Python 3 porting

[Jonathan Dowland]

On Mon, Jul 27, 2020 at 12:37:36AM -0400, Sandro Tosi wrote:

do you have any plan on completing this port? I'm not a user of
archivemail but it looks like it should be removed, not salvaged:

* no new upstream releases since 2011 (!)
* last upload to debian in 2014
* retired from fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1777616

maybe it's time to let it go?

If i dont hear otherwise in a week, i'll file for its removal


I think I'm happy for it to go. I'm certainly not going to be able to
work on porting it, and I'm most likely going to move to something else
for the purposes I use it.

Thanks,

--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#855837: closing 855837

[Jonathan Dowland]

# stetch shipped ages ago
close 855837 
thanks

-- 
👱🏻Jonathan Dowland
✎ j...@dow.land
🔗https://jmtd.net

Bug#936146: archivemail - Python 3 porting

[Jonathan Dowland]

On Thu, May 14, 2020 at 03:31:31PM -0400, Scott Talbert wrote:
archivemail seems to be a good candidate to RM due to dead upstream. 
However, it still has a relatively high popcon, so people seem to be 
using it.


I'm willing to take a stab at porting to Python 3 if anyone is 
available to test it?  The port effort doesn't look that bad at first 
glance, but I don't use this package.


I'm happy to test anything you produce, but I'd warn you that I think
it's quite a significant piece of work. From what I remember when I last
looked at hacking a feature into it (#736327), archivemail uses the
older of two different APIs provided by the python "mailbox" library,
and only the newer one was carried forward to Python 3. So moving away
from that older API is a big part of the work. 



--
  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Bug#950926: ember: Using packages to install "snap" packages is not a correct use of the packaging system

[Jonathan Dowland]

On Sun, Feb 09, 2020 at 11:12:48PM +0100, Manuel A. Fernandez Montecelo wrote:

2) These kind of methods are done for special packages like firmware,
very popular apps like flash (at the time), etc, or *data* packages
from games.


We have game-data-packager (gdp, which I originally wrote) for
situations like this. When you generate a .deb (as gdb does) containing
the data and install that, you get an Installed-Size which reflects the
actual disk usage of the package; you know that data is removed again
when you remove the package; you can express package inter-dependencies
properly, etc.

The ember package, at present

• claims to have an Installed-Size of 35.8 kB but will install
  177+MiB in pre-inst
• Does not clean that up again on package removal
• Doesn't handle "snap install" failing, silently completes package
  installation
• Supplies a .desktop file referencing Exec=ember but does not provide
  any ember binary (even as a route into the snap) in $PATH

It would be interesting to see whether game-data-packager could consume
data from snaps, and avoid all these pitfalls. I believe smcv was
interested in something similar for flatpaks (that might have been
installing into flatpaks, rather than consuming from them)


--
  Jonathan Dowland
   https://jmtd.net

Bug#950791: neomutt: missing debian/copyright entries for autosetup/*

[Jonathan Dowland]

Some initial work on this:

Bug#950791: neomutt: missing debian/copyright entries for autosetup/*

[Jonathan Dowland]

Source: neomutt
Version: 20180716+dfsg.1-1
Severity: serious
Justification: Policy 12.5

The file autosetup/autosetup leads with the following comment:

# Copyright (c) 2006-2011 WorkWare Systems http://www.workware.net.au/
# All rights reserved

This is a bit concerning, but the concern is alleviated by the contents of
autosetup/LICENSE, which looks DFSG-acceptable (but I haven't looked very
closely to be sure)

However, debian/copyright does not have a stanza for autosetup/* leaving '*'
as the applicable stanza, stating GPL-2+ which is not correct.

-- Package-specific info:
NeoMutt 20180716
Copyright (C) 1996-2016 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.

System: Linux 4.19.0-6-amd64 (x86_64)
ncurses: ncurses 6.1.20181013 (compiled with 6.1.20180714)
libidn: 1.33 (compiled with 1.33)
hcache backends: tokyocabinet

Compiler:
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.3.0-25' 
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-7 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto 
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Debian 7.3.0-25) 


Configure options: --build=x86_64-linux-gnu --prefix=/usr 
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man} 
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules {--libdir=${prefix}/lib/x86_64-linux-gnu} 
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode 
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/lib 
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss 
--idn --mixmaster --sasl --tokyocabinet

Compilation CFLAGS: -g -O2 
-fdebug-prefix-map=/build/neomutt-oDMtzm/neomutt-20180716+dfsg.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include 
-I/usr/include/lua5.3  -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5

Default options:
 +attach_headers_color +compose_to_sender +compress +cond_date +debug 
 +encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color 
 +initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop 
 +progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar 
 +skip_quoted +smtp +status_color +timeout +tls_sni +trash 


Compile options:
 +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens +getaddrinfo 
 +gnutls +gpgme +gss +hcache -homespool +idn -locales_hack +lua +meta 
 +mixmaster +nls +notmuch -openssl +pgp +sasl +smime +start_color 
 +sun_attachment +typeahead 
MAILPATH="/var/mail"

MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"

To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
   https://github.com/neomutt/neomutt/issues
or send an email to: 


-- System Information:
Debian Release: 10.2
 APT prefers stable
 APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages neomutt is related to:
ii  neomutt  20180716+dfsg.1-1

-- no debconf information

--
  Jonathan Dowland
   https://jmtd.net

Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

[Jonathan Dowland]

Preserving the rather large CC list for now…

On Thu, Jun 20, 2019 at 06:05:22AM -0400, Sam Hartman wrote:

I feel very uncomfortable with a change as big as this revert happening
this late in the release cycle.


How big is big? The MR I raised resurrects a patch that changes one line
of code, and was shipped in the last stable release. Although it looks
like further work is needed to make the change as smooth as possible so
this would grow. However, the patch certainly needs more testing. Is the
issue that it results in a large change in terms of what software is
executed by the user as a consequence, and what of that has been tested
thus far in the freeze?

How late is late? How would you have felt about it back in early April,
when I first raised it? I was surprised to discover it then, and I felt
it was late in the cycle even then. But mostly whats happened since is
nothing.

I absolutely do not blame the GNOME team here. Simon McVittie and
Michael Biebl in particular have taken risks sticking their heads above
the parapet to engage with me on this matter, and both have made it
clear that it would be unreasonable for them to make the call given
their respective levels of involvement. I respect that, and I am
extremely grateful for them engaging with the issue. The others are
either too busy or have taken a decision not to engage with a
potentially toxic issue, and I respect that, too: we are all volunteers
who have to make our own choices about what we are prepared to do and
engage in. Besides, like many teams, the GNOME team is clearly
under-resourced.

I am a *little* disappointed that this does not seem to have been
thought of as an important, project-wide issue. Regardless of whether
one uses GNOME or Wayland oneself, the matter of the default desktop for
the distribution we are all working to produce, and the experience that
our users will get out of the box, I would have thought was important
for all of us. It reinforces the idea, to me, that we are largely
working in our own silos, and not concerned (enough) about the holistic
distribution as a whole.


And yet, the lack of a clear reconfirmation in this time line even given
the wonderfully civil discussion is telling.


I'm very pleased that the discussion has come across as civil. I've
tried really hard from my end to achieve that, I know that issues around
GNOME can result in some very toxic communications.


My proposal--which again I have no power to implement--is that we go
forward with the current default.  However, we remain open to a revert
in the first couple of buster point releases.


There are caveats with switching the default in either direction. 
Let's say we go with Wayland now, and later decide to switch as per the

criteria/process you sketch below.

• users of the default, who got Wayland from Buster onwards and had no
  problems, would subsequently find themselves switched to Xorg by
  stable-updates, which IMHO would be unexpected (if noticed) and
  contrary to the expectations of a stable release.

• A user who installed or upgraded and got Wayland by default but had
  problems, would have likely addressed them by switching to the Xorg
  session explicitly (assuming they could figure out that doing so
  mitigated their issues). Changing the default would only prevent
  *future* users from hitting the same problems.


The criteria for that revert should be based on the actual severity and
frequence of problems our users run into, but should specifically
exclude the blanket reluctance to  make a change like that in a point
release.  We would still need adequate testing of such a revert.


My concern with this is it's a new set of policies and procedures, not
codified anywhere, with a lot of detail to work out "on the hoof" (how
do we measure frequency of problems? do we go with the existing bug
severity guidelines? How much is adequate testing? etc.)

So combined with the user experience above, I think we would be best not
to change the default within a stable release cycle, unless there was
some kind of enormous catastrophic issue with Wayland that we don't
know about yet, and that's unlikely.

I still argue that the traditional Debian conservative, when-its-ready
approach would be the distribution status quo (Xorg), but I recognise
the concerns about the proposed patch, further work needed, lack of
testing etc.; and those are not issues I think I can resolve alone.


--
Jonathan Dowland

Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

[Jonathan Dowland]

Hi Andrew

So far as I am aware there is still radio silence from active GNOME
packaging team members regarding this issue. No comment yet on the
patch I adapted, positive or negative; this bug (#927667) remains
at an RC severity.

I've not yet read all the thread that Samuel linked to[1] but it looks
like it leans in favour of preserving the current default (xorg).

I'm copying -release team to see if they have any (new) opinions on
the matter. Otherwise I guess it's up to someone to prepare an NMU
upload, which I will *try* to look at in the next few days, but can't
make any guarantees.

Further testers of the patch on this bug would be most welcome.

[1] https://lists.debian.org/debian-accessibility/2019/02/threads.html#4

Bug#903635: This is RC; breaks unrelated software

[Jonathan Dowland]

clone 903635 -1
retitle -1 installing and starting docker changes iptables FORWARD policy, 
breaking unrelated things
severity 903635 important
found 903635 18.09.1+dfsg1-7
found -1 18.09.1+dfsg1-7
thanks

On Mon, Jun 10, 2019 at 01:27:45AM +0800, Shengjing Zhu wrote:

Could you provide more info about "changed my FORWARD chain policy to
DROP"?


In a fresh test Buster installation. Before:


# iptables -L | grep FORWARD
Chain FORWARD (policy ACCEPT)
# dpkg -l docker.io
# dpkg-query: no packages found matching docker.io
# apt install -y docker.io


After


# iptables -L | grep FORWARD
Chain FORWARD (policy ACCEPT)
# systemctl start docker
# iptables -L | grep FORWARD
Chain FORWARD (policy DROP)


So: Installing (*and* starting) Docker, with no other configuration steps
performed by the user, changes the FORWARD table policy, which breaks e.g.
any running VMs on the host.


I set add `"iptables": false` to `/etc/docker/daemon.json`. Then reboot
my laptop. Then run `iptables-save`.


Setting that does stop this from happening, yes. If this was the package
default that would resolve the issue I have.

But that would not address the original filer's issue (unnecessary chain
DOCKER-USER creation, which I can reproduce). I should have filed a separate
issue really, sorry. I've cloned now.


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#903635: docker.io: use of iptables-legacy is incompatible with nftables-based iptables

[Jonathan Dowland]

On Sat, Jun 08, 2019 at 10:13:03PM -0400, Afif Elghraoui wrote:

I don't understand... I thought the whole point of making a bug
release-critical is to keep the bug out of the release (either by having
it fixed or removing the package).


No, that's not the point; it's the consequence. There are clear criteria
for the bug categories, "breaks unrelated software" is one of them and
what is happening here.


if you want to pursue a buster-ignore tag, someone please contact the
release team and make it happen. https://www.debian.org/Bugs/Developer
says explicit authorization is needed from the release managers, but I'd
worry that an email to debian-rele...@lists.debian.org might get lost
and it'd be weird to file a bug on release.debian.org asking to apply a
tag to another bug.


Someone should indeed do this. I might get around to it, but I can't
promise, I'm very busy this week.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

[Jonathan Dowland]

reassign 927667 gdm3
tags 927667 +patch
thanks

On Fri, May 10, 2019 at 10:26:07AM +0100, Jonathan Dowland wrote:

Two ways of resolving this are: Either the default GNOME3 session in Debian
switched back to Xorg, or the default desktop session is switched away from
GNOME; but I would much prefer the former.


The attached debdiff (bringing back the similar change from 2016) seems
to work for me (tested in a VM) but I would appreciate any additional
testing that folks could spare.

The debdiff is an NMU but I currently have no plans to upload it as such.

Also available at:
   https://salsa.debian.org/gnome-team/gdm/merge_requests/8

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄
commit 049dc7f4142850ae34ea530b5447175dd8a3834e
Author: Jonathan Dowland 
Date:   Thu May 23 16:43:14 2019 +0100

postpone switch to Wayland as default, again

This is a repeat of 569d7f50fe3a06908886cefc5168126197fec570 from
2016, postponing the switch to Wayland for the default Debian
desktop. See #927667 for discussion.

diff --git a/debian/changelog b/debian/changelog
index fc06f058..d2e936f7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+gdm3 (3.30.2-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Re-introduce debian/patches/09_default_session.patch, switching the
+default session back to "default", postponing a move to Wayland by
+default for Buster. Closes: #927667.
+
+ -- Jonathan Dowland   Fri, 24 May 2019 10:52:17 +0100
+
 gdm3 (3.30.2-3) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/09_default_session.patch b/debian/patches/09_default_session.patch
new file mode 100644
index ..d41fc744
--- /dev/null
+++ b/debian/patches/09_default_session.patch
@@ -0,0 +1,19 @@
+Description: Prefer (Xorg-based) desktop session
+ Default to "default.desktop" session, postponing a switch to
+ Wayland for the default Debian desktop.
+
+Origin: commit:569d7f50fe3a06908886cefc5168126197fec570
+Bug-Debian: https://bugs.debian.org/927667
+
+index ca06608c..3276b902 100644
+--- a/daemon/gdm-session.c
 b/daemon/gdm-session.c
+@@ -560,7 +560,7 @@ get_fallback_session_name (GdmSession *self)
+ }
+ }
+ 
+-name = g_strdup ("gnome");
++name = g_strdup ("default");
+ if (get_session_command_for_name (self, name, NULL)) {
+ g_free (self->priv->fallback_session_name);
+ self->priv->fallback_session_name = name;
diff --git a/debian/patches/series b/debian/patches/series
index 69745241..87fece76 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,6 +2,7 @@ manager-don-t-kill-timed-login-session-immediately-after-.patch
 manager-session-Add-some-debugging-around-starting-reauth.patch
 session-Don-t-allow-greeter-operations-on-an-running-sess.patch
 GdmManager-Don-t-perform-timed-login-if-session-gets-star.patch
+09_default_session.patch
 16_xserver_path.patch
 90_config_comments.patch
 91_dconf_database_path.patch

Bug#903635: docker.io: use of iptables-legacy is incompatible with nftables-based iptables

[Jonathan Dowland]

Hi Arnaud - sorry I missed your messages until now.

On Fri, May 10, 2019 at 09:03:41AM +0700, Arnaud Rebillout wrote:

As I mentioned above, there's a discussion with a work in progress to
fix that upstream: https://github.com/docker/libnetwork/pull/2339

I don't think it will be ready in time for buster though. So I see two
solutions going forward:

- 1 Jonathan lower the severity of the bug so that it's not RC.


I'd rather not do that, because I think RC is the right classification;
*but* I don't feel necessarily (given the circumstances) that docker.io
should be removed from Buster, so can I instead suggest we request that
this bug is ignored for Buster? I think we need to ask the release team
to do that (and tag accordingly) but I'll double-check the procedure.


- 2 I import the patch from github, even though it's work in progress. I
will follow up and update the patch as soon as upstream release a proper
fix, and it will be included in a point release of buster.



If I don't get any feedback from you Jonathan in the following days,
I'll go for solution number 2 then.


I bow to your judgement as maintainer as to whether the partial fix is
worth applying on its own. Will the patch in #2339 address the specific
issue of what happens on package install?

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#927667: gnome: please confirm or revert choice of Wayland for default desktop

[Jonathan Dowland]

Hi Michael,

Thank you for sharing your take.

On Sat, May 11, 2019 at 11:21:22AM +0200, Michael Biebl wrote:

Then there is the case, that I sometimes need to use software like
teamviewer (I know, bad proprietary software), which is not Wayland
ready. I need something cross-plattform though, and I'm not aware of
another solution which runs on top of Wayland.


I think we should have some sympathy towards users of non-free software
on top of Debian, even if we aren't packaging it. Pragmatically many of
our users rely on it or want it. E.g. NVIDIA driver users, Google Chrome,
Steam… and IMHO we further our goals if we are sensitive to their needs
rather than making life harder for them.


Incidentally, I was the one responsible for switching back the default
to Xorg in stretch and the main reasons which guided my decision back
then mostly still apply today.


I thought you might have been, I started reading the git log of some
packages to try and figure out what patch would need to be written, I
saw your name in (I think) gdm3 (I haven't yet come up with a working
patch but this gave me some clues thank you)


That said, I'm no longer an active GNOME team member and haven't really
done any GNOME related work during the buster development cycle.


I hadn't realised you were no longer active in the GNOME team. I hope
you are still active in Debian :-) I've always enjoyed interacting with
you (and you may not remember but I think we met at DebConf '07)


And I'm convinced, that the people doing the work should decide.


Mostly agree :-)

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#903635: This is RC; breaks unrelated software

[Jonathan Dowland]

On Wed, Apr 24, 2019 at 08:04:43PM +0100, Jonathan Dowland wrote:

Installing docker.io changed my FORWARD chain policy to DROP, breaking
networking for unrelated virsh-based VMs that I had installed on the machine at
the time. This matches exactly the text for severity: serious.


Sorry that should obviously have read "severity: critical".

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#818366: synaptic: fails to start under Wayland

[Jonathan Dowland]

On Mon, Mar 11, 2019 at 10:00:38PM +0100, Paul Gevers wrote:

I am going to raise my question again, if synaptic can't be run on the
default desktop in the default login mode, isn't the average user better
of if we don't ship synaptic with buster?


I think you've got that logic backwards. If the new display technology for
Buster doesn't work with long-established and popular packages in the 
archive, shouldn't the default display technology for Buster be reverted

back to the current one?


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄

Bug#924473: Corrected path

[Jonathan Dowland]

On Sun, Mar 17, 2019 at 07:09:52PM +0100, Bruno Kleinert wrote:

Hi Jonathan,

please find attached a debdiff that updates the path to the manpage.


Thanks for this, I will endeavour to apply and upload Tomorrow (hit a
snag locally, my sbuild environment hath borken)

Bug#911762: trash-cli: FTBFS - segmentation fault during test phase

[Jonathan Dowland]

Source: trash-cli
Version: 0.12.9.14-2.1
Severity: serious

FTBFS as per attached. sbuild fails too

I'm hoping this is cured by the new upstream version and/or
tightening a python version, and I'm going to attempt to fix
it.

-- System Information:
Debian Release: 9.5
   APT prefers stable
   APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-- no debconf information
$ gbp buildpackage -rfakeroot -us -uc
 dpkg-buildpackage -rfakeroot -us -uc -i -I
dpkg-buildpackage: info: source package trash-cli
dpkg-buildpackage: info: source version 0.12.9.14-3
dpkg-buildpackage: info: source distribution UNRELEASED
dpkg-buildpackage: info: source changed by Javi Merino 
 dpkg-source -i -I --before-build trash-cli
dpkg-buildpackage: info: host architecture amd64
 fakeroot debian/rules clean
dh clean --with python2
   debian/rules override_dh_clean
make[1]: Entering directory '/home/jon/git/debian/trash/trash-cli'
rm -rf trash_cli.egg-info/
make[1]: Leaving directory '/home/jon/git/debian/trash/trash-cli'
 dpkg-source -i -I -b trash-cli
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building trash-cli using existing 
./trash-cli_0.12.9.14.orig.tar.gz
dpkg-source: info: building trash-cli in trash-cli_0.12.9.14-3.debian.tar.xz
dpkg-source: info: building trash-cli in trash-cli_0.12.9.14-3.dsc
 debian/rules build
dh build --with python2
   dh_update_autotools_config
   dh_auto_configure
   dh_auto_build
python setup.py build --force
running build
running build_py
creating build
creating build/lib.linux-x86_64-2.7
creating build/lib.linux-x86_64-2.7/trashcli
copying trashcli/fs.py -> build/lib.linux-x86_64-2.7/trashcli
copying trashcli/rm.py -> build/lib.linux-x86_64-2.7/trashcli
copying trashcli/cmds.py -> build/lib.linux-x86_64-2.7/trashcli
copying trashcli/list_mount_points.py -> build/lib.linux-x86_64-2.7/trashcli
copying trashcli/trash.py -> build/lib.linux-x86_64-2.7/trashcli
copying trashcli/__init__.py -> build/lib.linux-x86_64-2.7/trashcli
copying trashcli/fstab.py -> build/lib.linux-x86_64-2.7/trashcli
running build_scripts
creating build/scripts-2.7
copying and adjusting bin/trash-list -> build/scripts-2.7
copying and adjusting bin/trash -> build/scripts-2.7
copying and adjusting bin/trash-put -> build/scripts-2.7
copying and adjusting bin/restore-trash -> build/scripts-2.7
copying and adjusting bin/trash-empty -> build/scripts-2.7
copying and adjusting bin/trash-rm -> build/scripts-2.7
changing mode of build/scripts-2.7/trash-list from 644 to 755
changing mode of build/scripts-2.7/trash from 644 to 755
changing mode of build/scripts-2.7/trash-put from 644 to 755
changing mode of build/scripts-2.7/restore-trash from 644 to 755
changing mode of build/scripts-2.7/trash-empty from 644 to 755
changing mode of build/scripts-2.7/trash-rm from 644 to 755
   debian/rules override_dh_auto_test
make[1]: Entering directory '/home/jon/git/debian/trash/trash-cli'
nosetests
.SS...debian/rules:12: recipe for target 
'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Segmentation fault
make[1]: Leaving directory '/home/jon/git/debian/trash/trash-cli'
debian/rules:4: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
debuild: fatal error at line 1116:
dpkg-buildpackage -rfakeroot -us -uc -i -I failed
gbp:error: 'debuild -i -I -rfakeroot -us -uc' failed: it exited with 29

Bug#870635: mutt package is not using the official mutt tarball

[Jonathan Dowland]

debian-de...@lists.debian.org
Bcc: 
Subject: Re: Bug#870635: mutt package is not using the official mutt tarball
Reply-To: 
In-Reply-To: <2017074105.iz5bje4kgkl3q...@cherubino.dyne.org>


CCing -devel because I think this might be of wider interest.

On Sat, Nov 11, 2017 at 07:41:05AM +, Antonio Radici wrote:

Sorry for the delay, my plan of action is to stop packaging neomutt with this
name, I'll create a new neomutt package (TBD by end of the month) and I'll think
if there is the need of a transitional package, the problem of a transitional
package is that mutt won't be packaged as mutt in stretch. To prevent that from
happening we will need two packages (mutt and neomutt) from two different
upstream sources.

So far the only thing which is certainly going to happen is the creation of the
neomutt package, then I could package the newest mutt as 'mutt' and think about
whether mutt needs to become a transitional package (which in that case will
remove mutt).


I think there are a facts you should seriously consider before
continuing with this approach.

Firstly, the existing package is neomutt, but called mutt. So the
existing package users are neomutt users, and the existing reported bugs
are bugs in neomutt. (The wisdom of having moved the package *to*
neomutt at this point is irrelevant, because it has happened whether we
like it or not.) If you are suggesting that the package name "mutt" is
going to be real "mutt" in future, then what happens to existing
users? What are their expectations? Do you reassign all existing bugs to
a new neomutt package name? Do you attempt to triage all bugs to figure
out whether they apply to one, the other, or both? Would users who are
using neomutt features not find the change to be a regression from their
point of view?

Secondly, is there a need for both mutt and neomutt in Debian? Our
mission is not to package every piece of software on earth, but to build
a useful operating system. Is there sufficient distinction between the
two, from a user's perspective, that there is a genuine need for both in
the archive? (Of course, the distinction is very important for the
authors of the software. But that's not the same thing.) For enough
users to justify the work? I've been a daily mutt (and now neomutt) user
in Debian for nearly 20 years, and I don't think there is.

Thirdly, let's look honestly at how well the existing package maintenance
is working. This particular issue was raise in late June[1], and you
said at the time that'd you have come up with a transition plan within a
couple of weeks[2]. For my pet neomutt bug[3] (which coincidentally I
reported at around the same time) you expected to have the patch applied
shortly, possibly even within a week[4], but it remains unfixed.

I am not trying to criticise your personal contributions to Debian. We
are all volunteers, and we all do what we can and nobody should expect
more from us than we are prepared or able to give. I am extremely
grateful for the work you have done and continue to do. But I think it's
important to communicate as realistically as possible what we are able
to do. I am very guilty of getting this wrong, and over-promising and
under-delivering for my own efforts in Debian. I simply wish to point
out that the existing Mutt packaging team appears to be stretched. It
seems to me that having two mutt packages to manage is only going to
make this situation much worse.

[1] https://marc.info/?l=mutt-users=149886522430053=2
[2] https://marc.info/?l=mutt-users=149889708628480=2
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866366
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866366#24


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Bug#870635: mutt package is not using the official mutt tarball

[Jonathan Dowland]

On Thu, Aug 03, 2017 at 10:21:51PM +, Antonio Radici wrote:
as I said on the original thread I'm planning to fix this, and as you 
can see there have been no new releases until the fix is in place.


It would be great if you could summarize *in this bug* what's your plan 
of action.


We are packaging neomutt, but calling it mutt. The obvious solution is 
to rename the package.  "mutt" could be used as transitional name to 
smoothly handle upgrades. This would not need to live for more than one 
release.


This would not proclude someone else from packaging "vanilla" mutt if 
they wanted to.



--

Jonathan Dowland

Bug#855837: golang-petname: Do not include in stretch at request of maintainer

[Jonathan Dowland]

Package: golang-petname
Severity: serious

I uploaded this as a dependency of LXD which unfortunately we did not finish
packaging in time for the Stretch freeze. As such, unless someone else is
prepared to help support it, and/or users of this package come out of the
woodwork, I do not think we should include this library in Stretch.

-- 
Jonathan Dowland


signature.asc
Description: Digital signature

Bug#839486: lhasa: FTBFS: Tests failures

[Jonathan Dowland]

On Tue, Oct 11, 2016 at 12:46:46PM +0100, James Cowgill wrote:
> Control: tags -1 patch

Thanks for looking at this!

-- 
Jonathan Dowland


signature.asc
Description: Digital signature

Bug#706909: fixed in smartmontools 6.1+svn3812-1

[Jonathan Dowland]

On Sat, Oct 03, 2015 at 06:57:31PM +0200, Paul Wise wrote:
> This isn't the way to fix this issue, the current mechanisms still lead to
> drivedb.h from the package being overwritten by downloaded data. Thedrivedb.h
> file should be shipped in the deb in /usr not /var. At package install/update
> time the copy in /var should be updated using the copy in /usr if it is newer
> than the copy in /usr. The update tool should only write to the copy in /var
> but only if the downloaded version is newer than the copy in /var.

I'm thinking that this should probably be resolved (as with #804299) by
removing the drivedb update feature from the Debian package and performing
drivedb updates via update Debian packages. I'm not yet sure whether it's
worth splitting the drivedb out of the main smartmontools package; I need
to think whether that would make backporting easier. I'm interested in any
others opinions on the issue (I guess follow-ups to #804299 would be most
appropriate).

Bug#785122: chocolate-doom: includes licence-incompatible GPLv3 code

[Jonathan Dowland]

Package: chocolate-doom
Version: 2.1.0-1
Severity: serious
Justification: license issue

Chocolate-doom includes code taken from GnuPG, which is GPLv3, whereas
chocolate-doom is GPLv2 (or later). Upstream have fixed this by replacing
the AES implementation with one from the kernel. See

https://github.com/chocolate-doom/chocolate-doom/commit/b3678129fd7bed6c3287ab682819b075e8bf495a

For ref, the first commit introducing this code is

commit a3b3e15f4eed9aaffc56be69784cd7447cf456de
Author: Simon Howard frag...@gmail.com
Date:   Sat Oct 27 06:10:50 2012 +

The first released version to include that commit is 2.0.0, meaning
only jessie and onwards are impacted.


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

Bug#724043: archivemail: FTBFS: Test failure

[Jonathan Dowland]

Hi Nikolaus,

On Sun, Nov 24, 2013 at 09:35:12PM +0100, Nikolaus Schulz wrote:
 But yes, it's a bug, and the fix is in fact trivial, it's just that my
 coding infrastructure was broken until today.

Did you manage to write up a fix for this? If not I'll work on one.

Thanks

-- 
Jonathan Dowland


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

Bug#750382: ~ Bug#750382: works for me on mips

[Jonathan Dowland]

Hi Plamend,

Thanks for your interest in this.

On Thu, Jun 26, 2014 at 03:56:36PM +0300, Plamen Aleksandrov wrote:
 I tested the package on a MIPS system and it built successfully. All the
 tests passed. 

 I think we should try to build this one again through the auto-building
 system on MIPS. If it fails again, I'll look into the differences to find
 where the problem is.

Since Bob filed the bug I uploaded a version which ensured that VERBOSE was
enabled for builds. That upload also failed on all buildds (it's unclear to
me which version you tested; -1 or -2).

The failure logs I see now shed a bit of light on which tests are failing
(test-dry-run[1,2]) but I haven't explored much further. I do see lots of
hardcoded predictable filenames in /tmp etc. which are likely to be the
smoking guns, especially on buildds. 

[1] i386 - 
https://buildd.debian.org/status/fetch.php?pkg=lhasaarch=i386ver=0.2.0%2Bgit-2stamp=1403473868
 
[2] mips - 
https://buildd.debian.org/status/fetch.php?pkg=lhasaarch=mipsver=0.2.0%2Bgit-2stamp=1403477942

-- 
Jonathan Dowland


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

Bug#750382: thanks for the prod

[Jonathan Dowland]

Thanks for pointing this out; I think I noticed back when they failed but
forgot. Today I dusted off some build environments but can't reproduce on i386
or amd64 yet. I'll keep looking.


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

Bug#724551: squishyball: FTBFS: syntax error near unexpected token `vorbisfile,'

[Jonathan Dowland]

Hi,

On Tue, Sep 24, 2013 at 09:42:30PM -0400, Aaron M. Ucko wrote:
 Please declare a build dependency on pkg-config and confirm via
 pbuilder or the like that you haven't missed any others.

Thanks for catching. How embarrassing.  I see that -1 failed too,
but as an experimental package nobody noticed or cared. confirmed
via pbuilder (sbuild seems broken at the moment)


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

Bug#722438: qtscrob: FTBFS - manpage compression race in parallel builds

[Jonathan Dowland]

On 11 Sep 2013, at 03:47, Aaron M. Ucko u...@debian.org wrote:

 Given that all three builds ran in parallel (with -j6 or -j8), I
 suspect a race condition.  Could you please take a look?

Urgh. I hit this in the middle of preparing the package but it went away 
towards the end so I forgot about it. Thanks for catching.

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

Bug#696727: ~ Re: Bug#696727: cheese does not start with Gtk-Warning

[Jonathan Dowland]

On 27 Mar 2013, at 23:41, John Paul Adrian Glaubitz 
glaub...@physik.fu-berlin.de wrote:

 could anyone who is seeing the issue with Cheese freezing try to disconnect 
 their webcam

In my case I don't think so- it's built into the frame of my laptop screen.

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

Bug#696727: cheese does not start with Gtk-Warning

[Jonathan Dowland]

On Thu, Mar 28, 2013 at 11:13:34AM +0100, John Paul Adrian Glaubitz wrote:
 How about unloading the kernel module then? I guess it's probably an
 UVC camera, so modprobe -r uvcvideo should do the trick for most
 cameras (as most of them are UVC).

Thanks for the tip. It is indeed uvcvideo, and unloading it means cheese draws 
its
UI (No device found). Interesting stuff. I'm going to try splicing some debug
statements into the code to see at what point it reaches and whether that helps
get any further.

FWIW some earlier verison of cheese worked with this webcam on this laptop.


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

Bug#696727: Info received (Bug#696727: cheese does not start with Gtk-Warning)

[Jonathan Dowland]

I've just noticed that cheese is busy looping and mallocing whilst it's
seemingly doing nothing:

   PID USER  PR  NI  VIRT  RES  SHR S  %CPU %MEMTIME+  COMMAND 
   
 18958 jon   20   0 7513m 6.2g 3236 R  92.1 80.0  20:03.57 cheese  
   


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

Bug#696727: cheese does not start with Gtk-Warning

[Jonathan Dowland]

On Thu, Mar 28, 2013 at 10:21:30AM +, Jonathan Dowland wrote:
 UI (No device found). Interesting stuff. I'm going to try splicing some
 debug statements into the code to see at what point it reaches and whether
 that helps get any further.

I've poked around a little, attached is a backtrace taken when interrupting the
spinning process. It shows the last routine executed in cheese code as
cheese_camera_play. Poking around in the C, 

cheese_camera_play (CheeseCamera *camera)
{
  …
gst_element_set_state (priv-camerabin, GST_STATE_PLAYING);

^^

That's as far as cheese gets. So, is this a gstreamer bug? (or
gstreamer0.10-plugins-bad)? Seems it uses 'camerabin', which has been
deprecated in favour of 'camerabin2' in gst 0.10, and dropped by 1.0.
Cheese moved to camerabin2 between 3.5.5 and 3.5.091.
#0  type_check_is_value_type_U (type=optimized out)
at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./gobject/gtype.c:4098
#1  g_type_check_value (value=value@entry=0x1dddfb0)
at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./gobject/gtype.c:4140
#2  0x77769d9c in gst_value_init_and_copy (dest=0x1e33520, 
src=0x1dddfb0) at gstvalue.c:4007
#3  0x7776a03f in copy_garray_of_gstvalue (
src=error reading variable: Unhandled dwarf expression opcode 0xfa, 
src=error reading variable: Unhandled dwarf expression opcode 0xfa) at 
gstvalue.c:230
#4  0x7776a130 in gst_value_copy_list_or_array (src_value=optimized 
out, 
dest_value=0x7fffd8b0) at gstvalue.c:241
#5  0x7776d35f in gst_value_list_append_value 
(value=value@entry=0x7fffd970, 
append_value=append_value@entry=0x7fffd8f0) at gstvalue.c:314
#6  0x7776da4b in gst_value_intersect_list (dest=0x7fffd970, 
value2=0x1a40460, 
value1=error reading variable: Unhandled dwarf expression opcode 0xfa) at 
gstvalue.c:2752
#7  0x7776d999 in gst_value_intersect_list (dest=0x7fffd9f0, 
value2=0x1a40460, 
value1=error reading variable: Unhandled dwarf expression opcode 0xfa) at 
gstvalue.c:2746
#8  0x7776d999 in gst_value_intersect_list (dest=0x7fffda70, 
value2=0x1d84658, 
value1=error reading variable: Unhandled dwarf expression opcode 0xfa) at 
gstvalue.c:2746
#9  0x7776d999 in gst_value_intersect_list (dest=0x7fffdaf0, 
value2=0x1d84658, 
value1=error reading variable: Unhandled dwarf expression opcode 0xfa) at 
gstvalue.c:2746
#10 0x7776d999 in gst_value_intersect_list (dest=0x7fffdb70, 
value2=0x1d84658, 
value1=error reading variable: Unhandled dwarf expression opcode 0xfa) at 
gstvalue.c:2746
#11 0x7776d999 in gst_value_intersect_list (dest=0x7fffdbf0, 
value2=0x1d84658, 
value1=error reading variable: Unhandled dwarf expression opcode 0xfa) at 
gstvalue.c:2746
#12 0x77750a73 in gst_structure_intersect_field1 (id=3915, 
val1=0x1a3d4a8, data=0x7fffdc60)
at gststructure.c:2981
#13 0x77750fc1 in gst_structure_foreach (structure=0x1a5fb90, 
func=0x77750a20 gst_structure_intersect_field1, 
user_data=0x7fffdc60) at gststructure.c:1097
#14 0x77753c00 in gst_structure_intersect 
(struct1=struct1@entry=0x1a5fb90, struct2=0x1c88330)
at gststructure.c:3030
#15 0x7770f3a4 in gst_caps_intersect_first (caps2=0x19d1e80, 
caps1=0x198ce40) at gstcaps.c:1423
#16 gst_caps_intersect_full (caps1=caps1@entry=0x198ce40, 
caps2=caps2@entry=0x19d1e80, 
mode=mode@entry=GST_CAPS_INTERSECT_FIRST) at gstcaps.c:1454
#17 0x7fffefff4c94 in gst_base_transform_getcaps (pad=0x19c9d90) at 
gstbasetransform.c:768
#18 0x7772cf96 in gst_pad_get_caps_unlocked (pad=pad@entry=0x19c9d90) 
at gstpad.c:2254
#19 0x777305b5 in gst_pad_get_caps_reffed (pad=pad@entry=0x19c9d90) at 
gstpad.c:2338
#20 0x7776148b in gst_element_get_compatible_pad 
(element=element@entry=0x1b8e240, 
pad=pad@entry=0x19c9d90, caps=caps@entry=0x0) at gstutils.c:1146
#21 0x7776216a in gst_element_link_pads_full (src=src@entry=0x1a16090, 
srcpadname=srcpadname@entry=0x0, dest=dest@entry=0x1b8e240, 
destpadname=destpadname@entry=0x0, 
flags=flags@entry=GST_PAD_LINK_CHECK_CAPS) at gstutils.c:1799
#22 0x7fffe16020ea in gst_camerabin_try_add_element 
(bin=bin@entry=0x196e020, 
new_elem=new_elem@entry=0x1b8e240) at camerabingeneral.c:99
#23 0x7fffe160228f in gst_camerabin_add_element (bin=bin@entry=0x196e020, 
new_elem=new_elem@entry=0x1b8e240) at camerabingeneral.c:56
#24 0x7fffe160247d in gst_camerabin_create_and_add_element 
(bin=bin@entry=0x196e020, 
elem_name=optimized out, elem_name@entry=0x7fffe16043fd videoscale, 
instance_name=instance_name@entry=0x7fffe16043f9 src-videoscale) at 
camerabingeneral.c:146
#25 0x7fffe15f67a0 in camerabin_create_src_elements (camera=0x196e020) at 
gstcamerabin.c:623
#26 camerabin_create_elements (camera=0x196e020) at gstcamerabin.c:779
#27 gst_camerabin_change_state (element=0x196e020, 
transition

Bug#696727: cheese does not start with Gtk-Warning

[Jonathan Dowland]

severity 696727 important
thanks

(Downgrading since no evidence that it fails for the majority)

On 28 Mar 2013, at 18:56, Emilio Pozuelo Monfort po...@debian.org wrote:

 After that I'd try with another tool
 that doesn't use gstreamer, then we can pinpoint whether this is a gstreamer 
 bug
 or not.
Already done
 
 I remember from when I did video integration in empathy that some webcams will
 only work once, and after that you have to unload the kernel module and load 
 it
 again for them to work. If that was the case here, the problem could be that
 cheese is not stopping them properly.

Cheese fails on first attempt after module reload without invoking any other 
webcam software first.

Thanks

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

Bug#696727: cheese does not start with Gtk-Warning

[Jonathan Dowland]

Hi Michael and Emilio,

On Wed, Mar 27, 2013 at 08:00:06PM +0100, Michael Biebl wrote:
 My guess would be that it is cogl/clutter/gl related.
 
 Jon, does gnome-shell (or other clutter using applications) work for you?

Yep I run GNOME 3 including gnome-shell without problems.

I should probably expand on the report a bit: the process does not terminate
after printing those errors, it sits there. Therefore, I don't have a core to
backtrace by default.

You are perhaps correct that those errors are a red herring. Nevertheless I
have a bt with G_DEBUG=fatal-warnings, attached in case it's useful.


-- 
Jonathan Dowland


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

Bug#696727: cheese does not start with Gtk-Warning

[Jonathan Dowland]

On Wed, Mar 27, 2013 at 07:38:45PM +0100, Michael Biebl wrote:
 I do get those warnings, but afaics they are a red herring.

Indeed, I've fixed the warnings using the tip at
https://bugzilla.gnome.org/show_bug.cgi?id=671912 and I still have the same
behaviour, process runs, remains running, but nothing is ever drawn to my
screen.


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

Bug#696727: Info received (Bug#696727: cheese does not start with Gtk-Warning)

[Jonathan Dowland]

Just FWIW I've installed camorama which works fine - just to confirm that my 
webcam
is OK.


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

Bug#696727: cheese does not start with Gtk-Warning

[Jonathan Dowland]

On Wed, Mar 27, 2013 at 09:16:17PM +, Jonathan Dowland wrote:
 You are perhaps correct that those errors are a red herring. Nevertheless I
 have a bt with G_DEBUG=fatal-warnings, attached in case it's useful.

Actually attached.
$ gdb ./.libs/cheese 
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /home/jon/wd/cheese-3.4.2/.libs/cheese...done.
(gdb) run
Starting program: /home/jon/wd/cheese-3.4.2/.libs/cheese 
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need set solib-search-path or set sysroot?
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
[New Thread 0x7fffe9385700 (LWP 13264)]
[New Thread 0x7fffe88ea700 (LWP 13265)]

(cheese:13261): Gtk-WARNING **: Attempting to add a widget with type GtkImage 
to a GtkToggleButton, but as a GtkBin subclass a GtkToggleButton can only 
contain one widget at a time; it already contains a widget of type GtkLabel

Program received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x76592ff7 Gtk, log_level=G_LOG_LEVEL_WARNING, 
format=0x7659eb18 Attempting to add a widget with type %s to a %s, but 
as a GtkBin subclass a %s can only contain one widget at a time; it already 
contains a widget of type %s, 
args1=args1@entry=0x7fffda98) at 
/tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/gmessages.h:101
101 /tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/gmessages.h: No such 
file or directory.
(gdb) bt
#0  g_logv (log_domain=0x76592ff7 Gtk, log_level=G_LOG_LEVEL_WARNING, 
format=0x7659eb18 Attempting to add a widget with type %s to a %s, but 
as a GtkBin subclass a %s can only contain one widget at a time; it already 
contains a widget of type %s, 
args1=args1@entry=0x7fffda98) at 
/tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/gmessages.h:101
#1  0x755a2622 in g_log (log_domain=log_domain@entry=0x76592ff7 
Gtk, 
log_level=log_level@entry=G_LOG_LEVEL_WARNING, 
format=format@entry=0x7659eb18 Attempting to add a widget with type %s 
to a %s, but as a GtkBin subclass a %s can only contain one widget at a time; 
it already contains a widget of type %s)
at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/gmessages.c:792
#2  0x7633fc98 in gtk_bin_add (container=optimized out, 
child=0x17c8410)
at /tmp/buildd/gtk+3.0-3.4.2/./gtk/gtkbin.c:124
#3  0x7585db54 in g_cclosure_marshal_VOID__OBJECTv (closure=0x64a460, 
return_value=optimized out, instance=0x17c02a0, args=optimized out, 
marshal_data=optimized out, 
n_params=optimized out, param_types=0x64a4d0)
at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./gobject/gmarshal.c:1312
#4  0x7585a9a7 in _g_closure_invoke_va (closure=0x64a460, 
return_value=0x0, instance=0x17c02a0, 
args=0x7fffdec8, n_params=1, param_types=0x64a4d0)
at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./gobject/gclosure.c:840
#5  0x75873006 in g_signal_emit_valist (instance=0x17c02a0, 
signal_id=optimized out, detail=0, 
var_args=var_args@entry=0x7fffdec8)
at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./gobject/gsignal.c:3211
#6  0x75873852 in g_signal_emit (instance=optimized out, 
signal_id=optimized out, 
detail=optimized out) at 
/tmp/buildd/glib2.0-2.33.12+really2.32.4/./gobject/gsignal.c:3356
#7  0x76346b42 in _gtk_builder_add (builder=0x16350f0, 
child_info=child_info@entry=0x1775500)
at /tmp/buildd/gtk+3.0-3.4.2/./gtk/gtkbuilder.c:765
#8  0x7634b248 in end_element (error=0x7fffe058, 
user_data=0x174b4a0, 
element_name=0x17d94e0 child, context=optimized out)
at /tmp/buildd/gtk+3.0-3.4.2/./gtk/gtkbuilderparser.c:1042
#9  end_element (context=optimized out, element_name=optimized out, 
user_data=0x174b4a0, 
error=0x7fffe058) at 
/tmp/buildd/gtk+3.0-3.4.2/./gtk/gtkbuilderparser.c:927
#10 0x7559f498 in g_markup_parse_context_parse (context=0x17bdd40, 
text=text@entry=0x17c3f90 ?xml version=\1.0\?\ninterface\n  
requires lib=\gtk+\ version=\2.16\/\n  object class=\GtkGrid\ 
id=\mainbox_normal\\nproperty 
name=\orientation\vertical/property\nproperty name=\events..., 
text_len=optimized out, text_len@entry=13557, 
error=error@entry=0x7fffe118) at 
/tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/gmarkup.c:1559
#11 0x7634b677 in _gtk_builder_parser_parse_buffer 
(builder=builder@entry=0x16350f0, 
filename=filename@entry=0x1647060 
/usr/share/cheese/cheese-main-window.ui, 
buffer=0x17c3f90 ?xml version=\1.0

Bug#702769: bup_0.25~git2011.11.04-5.1_amd64.changes ACCEPTED into unstable

[Jonathan Dowland]

On Sat, Mar 23, 2013 at 09:02:39AM +, Debian FTP Masters wrote:
 Maintainer: Jon Dowland j...@debian.org
snip
* Non-maintainer upload.

This surprised me a bit, as I orphaned bup a while ago and it was picked up by
someone else, who has already made an upload removing me from the Maintainer
field. It took me a moment to realise that their upload would have been to
experimental, and your NMU is targetting wheezy via unstable. Still, it would
have been a good opportunity to switch out the Maintainer for wheezy. I would
have suggested that if you had CCed me with your proposed NMU, or tried to
reach me via other means… None-the-less, thanks for fixing the bug.


-- 
Jonathan Dowland


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

Bug#694570: installation failures with d-i beta4 relating to EFI

[Jonathan Dowland]

Package: installation-reports
Severity: critical
Justification: makes baby jesus cry

Hi,

I just tried d-i beta4 amd64 netinst on my lenovo thinkpad x121e
laptop. The Laptop's firmware has boot mode set to 'either/both'
for legacy BIOS/EFI. The storage device was a totally blank SSD,
no prior OS.

Upon boot, prior to the point where I get to choose graphical /
text / rescue, I get the following error message (this does not
stop me progressing):

error: prefix not set

Install progressed as normal. The guided partition scheme
created a GPT partition table and a 512M EFI partition in
addition to boot. It seemed to select grub2-efi. I got a message
like the following towards the end of the process:

grub-install dummy failed

The resulting install won't boot; I get the following error¹

Loading Linux 3.2.0-4-amd64 ...
Loading initial ramdisk ...
error: no suitable mode found.
Booting however

That's the last thing I see. No keyboard lights or other 
activity.

I'll just retry this and see if I can capture anything from d-i
before rebooting out of it.

¹ https://twitter.com/jmtd/status/273521879510298624/photo/1


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