Bug#957160: e17: ftbfs with GCC-10

[Ross Vandegrift]

Control: unblock -1 by 959828
Control: fixed -1 e17/0.24.1-2
Control: tags -1 fixed-in-experimental

On Tue, Jun 09, 2020 at 10:17:21PM -0700, Ross Vandegrift wrote:
> On Fri, Apr 17, 2020 at 10:59:16AM +, Matthias Klose wrote:
> > The package fails to build in a test rebuild on at least amd64 with
> > gcc-10/g++-10, but succeeds to build with gcc-9/g++-9.
> 
> I've confirmed that 0.24.1-1 builds with gcc-10 in a local chroot.  But it's
> waiting on a fix to #959828 for builds in experimental.

0.24.1-2 has a workaround for #959828, and is now in experimental.

Leaving this issue open as requested.

Ross

Bug#965943: cloud.debian.org: ec2 buster arm64 don't come online in us-east-2

[Ross Vandegrift]

Package: cloud.debian.org
Severity: normal
Usertags: aws

The buster arm64 images in us-east-2 don't seem to come online - ping and ssh
fail.  The ec2 status checks pass, but take unusually long to get there.  I
tried a1 and c6g instances.  There's nothing in the system log output, and no
screenshots on arm64.

I think it's the images since:
- amd64 in the same vpc, with the same security groups works correctly
- arm64 in us-west-2 & us-east-1 work correctly

Here's the images I tried:
  ami-0a5def50f0aa9c6a3
  ami-0a67a4b56b2021f1c
  ami-0b1808bb4e7ed5ff5

Ross

Bug#965107: Update to version 0.24.1

[Ross Vandegrift]

On Thu, Jul 16, 2020 at 02:04:19PM +0200, Andreas Metzler wrote:
> On 2020-07-16 Paul Menzel  wrote:
> > Can I test these packages? Is there an easy way to build them myself?
> 
> Source packages are available in Debian experimental. Binaries are not
> available because of #959828.
> 
> @Ross: How about working around this with

Something like this would probably work.  I tried Build-Conflicts though
your solution is simpler.  But I ran into #965033 and decided to wait.
That's just fixed, so yay!  I should have time to test & upload in the
next few days.

@Paul - sorry for the slow update.  This one is a little fragile: E 0.24
requires EFL 1.24, which breaks E <0.24.  If you try to build the source
packages, you will need to build & upgrade both.

Ross

Bug#959828: systemctl: `Provides: systemd`, but doesn't provide what systemd does

[Ross Vandegrift]

On Wed, May 20, 2020 at 12:48:18PM -0700, Ross Vandegrift wrote:
> On Thu, May 07, 2020 at 07:52:31PM +0200, Julien Cristau wrote:
> > On Thu, May 07, 2020 at 09:48:34PM +1000, Dmitry Smirnov wrote:
> > > On Thursday, 7 May 2020 7:04:17 PM AEST Julien Cristau wrote:
> > > > This use of Provides is not acceptable.  The systemctl package does not
> > > > in any way provide the same functionality / interfaces as the systemd
> > > > package, and as such it does not get to pretend that it does and cause
> > > > problems to other packages.
> > > 
> > > I have to challenge that. "systemctl" provides enough functionality to 
> > > replace "systemd" inside application containers. Therefore there are 
> > > situations where "Provides: systemd" is justified.
> > > 
> > That's not what "Provides" means though.  What you're saying is
> > "systemctl provides a subset of the systemd package's functionality".
> > That's not good enough.  Provides is much stronger than "there are cases
> > where this might be enough", and there's more to systemd than systemctl.
> 
> Indeed- packages that Build-Depend on systemd need a way to express that
> fact.  experimental builds use apt-cudf, which now sees systemctl as a
> more attractive solution:
> https://buildd.debian.org/status/package.php?p=e17=experimental

Hi Dmitry - systemctl is still breaking builds in experimental, any updates?

Ross

Bug#963997: terminology: Characters not displayed

[Ross Vandegrift]

Control: tags -1 wontfix
Control: severity -1 normal

On Tue, Jun 30, 2020 at 07:09:26AM +0200, Pierre Couderc wrote:
> In the last line of the window, the character '_' is not displayed.
[snip[
> This problem exist since years on terminology, but the news is that it is 
> easy to
> reproduce on a debian system

This is a side-effect of freetype autohinting.  See the details at:
  https://savannah.nongnu.org/bugs/?37182 
ftgrid is in freetype2-demos, if you want to try the experiment there.

Upstream E devs do not consider it a bug.  The first hit on enlightenment-users
for "terminology underscore" might look familiar:
  https://sourceforge.net/p/enlightenment/mailman/message/35454255/

Best solution is to use a different font.  Inconsolata from fonts-inconsolata
and IBM Plex Mono from fonts-ibm-plex have both been better for me.  Fixes
fonts like terminus should also help.

Sorry I don't have a better solution,
Ross

Bug#963881: libecore-input1: circular dependency hell

[Ross Vandegrift]

Hi Bill,

On Sun, Jun 28, 2020 at 04:41:03PM +0200, Bill Allombert wrote:
> There is a circular dependency between libecore-input1, libecore-x1,
> libevas1 and libevas1-engines-x:
> 
> libecore-input1   :Depends: libevas1 (>= 1.23.3-0~eo)
> libecore-x1   :Depends: libecore-input1 (>= 1.23.3-0~eo)
> libevas1  :Depends: libevas1-engines-x
> libevas1-engines-x:Depends: libecore-x1 (>= 1.23.3-0~eo), libevas1 (>= 
> 1.23.3-0~eo)

So far, my attempts to avoid this have all caused failures to install the X11
engine when installing some EFL apps.  Did you run into some trouble, or just
find the cycle?  Since its the best of a bad lot, I'd like to leave it for now.
But if you ran into an upgrade or build failure, that might not make sense.

Long term, the EFL libs will be bundled into one binary package.  Upstream is
working on linking everything into one lib.  I'd really like to ship that
solution as the bundled version.  If that doesn't work out, I plan to merge all
of the debian packages.  But either way, I'd like to wait for upstream so I
only do one major rework.

Ross

Bug#925530: cloud.debian.org: Debian docker images pointing to github for bug tracking

[Ross Vandegrift]

[removing serpent@d.o from CC, he's resigned as delegate]

Hi Lucas,

On Sun, Jun 28, 2020 at 05:26:41PM +0200, Lucas Nussbaum wrote:
> One could argue that the Cloud team delegation does not cover Docker
> images.

Whether it does or not, I've been told that the docker image maintainers prefer
to keep their current organization and workflow.  I'd welcome their
participation in the team, if they were interested.  But I don't think they
need to be.

> But I think that it would be a nice addition to change the delegation to
> also include official images for virtualization environments such as
> Docker, LXC, Vagrant, as well as official images for SBC such as the
> Raspberry Pi (where it's often more convenient to boot a pre-built image
> than use the Debian installer).

Maybe it could be nice, if the people building those images want to use our
tools and work with us.  Some would raise concerns in my mind, but I don't
think it's useful to discuss before someone wants to build e.g. raspberry pi
images in cloud-team.

But it's also nice for people to provide images without us, or using different
tools.  The delegation only covers Debian-official cloud images.  And speaking
for myself: I don't feel the need to gather all other cloud-related or
image-related work under a this team.

Ross

Bug#957160: e17: ftbfs with GCC-10

[Ross Vandegrift]

Control: block -1 by 959828

On Fri, Apr 17, 2020 at 10:59:16AM +, Matthias Klose wrote:
> The package fails to build in a test rebuild on at least amd64 with
> gcc-10/g++-10, but succeeds to build with gcc-9/g++-9.

I've confirmed that 0.24.1-1 builds with gcc-10 in a local chroot.  But it's
waiting on a fix to #959828 for builds in experimental.

Ross

Bug#959828: systemctl: `Provides: systemd`, but doesn't provide what systemd does

[Ross Vandegrift]

On Thu, May 07, 2020 at 07:52:31PM +0200, Julien Cristau wrote:
> On Thu, May 07, 2020 at 09:48:34PM +1000, Dmitry Smirnov wrote:
> > On Thursday, 7 May 2020 7:04:17 PM AEST Julien Cristau wrote:
> > > This use of Provides is not acceptable.  The systemctl package does not
> > > in any way provide the same functionality / interfaces as the systemd
> > > package, and as such it does not get to pretend that it does and cause
> > > problems to other packages.
> > 
> > I have to challenge that. "systemctl" provides enough functionality to 
> > replace "systemd" inside application containers. Therefore there are 
> > situations where "Provides: systemd" is justified.
> > 
> That's not what "Provides" means though.  What you're saying is
> "systemctl provides a subset of the systemd package's functionality".
> That's not good enough.  Provides is much stronger than "there are cases
> where this might be enough", and there's more to systemd than systemctl.

Indeed- packages that Build-Depend on systemd need a way to express that
fact.  experimental builds use apt-cudf, which now sees systemctl as a
more attractive solution:
https://buildd.debian.org/status/package.php?p=e17=experimental

Ross

Bug#960983: apt-cudf: silently skips installing systemd from Build-Depends

[Ross Vandegrift]

Package: apt-cudf
Version: 5.0.1-14+b2
Severity: normal

apt-build build-dep with apt-cudf does not install systemd, even when it
appears directly in the Build-Depends of the requested package.  Example:

  $ apt-get --simulate build-dep --solver aspcud enlightenment

No error/warning tells the user that they didn't get everything they wanted.

Ross


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

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 apt-cudf depends on:
ii  aspcud [cudf-solver]  1:1.9.4-2
ii  libbz2-1.01.0.8-2
ii  libc6 2.30-7
ii  perl  5.30.0-10
ii  zlib1g1:1.2.11.dfsg-2

apt-cudf recommends no packages.

apt-cudf suggests no packages.

-- no debconf information

Bug#957169: efl: ftbfs with GCC-10

[Ross Vandegrift]

Control: fixed -1 efl/1.24.0-1
Control: tags -1 fixed-in-experimental

On Fri, Apr 17, 2020 at 10:59:25AM +, Matthias Klose wrote:
> Please keep this issue open in the bug tracker for the package it
> was filed for.  If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
> 
> The package fails to build in a test rebuild on at least amd64 with
> gcc-10/g++-10, but succeeds to build with gcc-9/g++-9.

Upstream release 1.24.0 (and later) contain a fix for builds w/gcc 10.  That is
now in experimental.  I've confirmed that the build succeeds.

Leaving open as requested.

Ross

Bug#960080: cme: public-domain files are not handled correctly

[Ross Vandegrift]

Package: cme
Version: 1.031-1
Severity: normal

Hello,

The machine readable copyright format has a special instructions for public
domain files.  They are recorded as "License: public-domain" and the rest of
the paragraph should explain the situation.

When I run cme update dpkg-copyright, it replaces my explanations with "Please
fill license public-domain from header of ...".  It should leave the prose
explanations in place.

Thanks,
Ross

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

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 cme depends on:
ii  libapp-cmd-perl   0.331-1
ii  libconfig-model-perl  2.138-2
ii  libjson-perl  4.02000-2
ii  liblog-log4perl-perl  1.49-1
ii  libpath-tiny-perl 0.108-1
ii  libpod-pom-perl   2.01-3
ii  libyaml-perl  1.30-1
ii  perl  5.30.0-10

Versions of packages cme recommends:
ii  libconfig-model-approx-perl   1.011-1
ii  libconfig-model-dpkg-perl 2.132
ii  libconfig-model-lcdproc-perl  2.052-2
ii  libconfig-model-openssh-perl  2.8.0.1-1
ii  libconfig-model-systemd-perl  0.244.1-1
ii  libconfig-model-tkui-perl 1.371-2

Versions of packages cme suggests:
pn  libconfig-model-cursesui-perl  
pn  libconfig-model-itself-perl

-- no debconf information

Bug#951117: eo logs in .xsession-errors eat all disk space

[Ross Vandegrift]

On Wed, Apr 29, 2020 at 11:21:42AM +0200, Adrian Immanuel Kiess wrote:
> The log files get up to 20 Gigabyte large per day because of this happening.
> The only difference here is that I don't get this error messages logged to
> .xsession-errors but to /var/log/syslog and journalctl.
> 
> I can reproduce this bug reported here before.
> 
> Is there any workaround known for this or an bug fix on it's way?

Upstream has made some changes to make logging quieter, it'll be available in
E24.  It should be available before too long - EFL1.24 is just out, and E24 is
scheduled for soon after.

Ross

Bug#958455: From a minimum installation of Sid, metapackage enlightenment installs neither X nor a login manager. Debian Sid, 15 april 2020

[Ross Vandegrift]

On Thu, Apr 23, 2020 at 07:06:29AM +, Daniel Tourde wrote:
> Now I am not really sure I really grasp what you mean with 'Suggests'. Would
> it be a message on the console saying "Well, if you need a login manager
> please install now package 'x-display-manager'? That's an option

Well, not quite.  By default apt will just tell you that a package you're
installing has suggested another.  For example it might look like this:

  $ sudo apt install enlightenment
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  The following additional packages will be installed:
... enlightenment ... (lots of stuff)
  Suggested packages:
... x-display-manager ... (potentially lots of stuff)
  The following NEW packages will be installed:
... enlightenment ... (lots of other stuff)
  0 upgraded, 278 newly installed, 0 to remove and 0 not upgraded.
  Need to get 158 MB of archives.
  After this operation, 623 MB of additional disk space will be used.

You would need to notice that x-display-manager is in the Suggested list, and
then install it yourself.  So I don't think this will really help.

Alternatively, you can run `apt install --install-suggests` - but you need to
know that you want the suggestions first.

> The other option is to have a 'enlightenment-desktop' metapackage which
> install enlightenment and a simple login-manager (even though it is not
> EFL-based).

Without a natural choice (ie, EFL-based or something), I don't want to add a
metapackage just for this.  A standalone window manager will usually need
additional pieces anyhow - I don't think I can effectively curate that list for
all users.

Ross

Bug#958455: From a minimum installation of Sid, metapackage enlightenment installs neither X nor a login manager. Debian Sid, 15 april 2020

[Ross Vandegrift]

Hi Daniel,

On Wed, Apr 22, 2020 at 09:18:24AM +, Daniel Tourde wrote:
> I was expecting to be welcomed by a login manager but it did not happen
> 'automagically', so to say. I checked and noticed that neither X nor a login
> manager were installed (as it happens with Gnome, KDE, XFCE (I checked... ;)
> )). Can this be fixed?

Currently, enlightenment is not a metapackge as your subject says - it's a
binary package for the enlightenment window manager.  I don't think it's
appropriate to add a Depends or Recommends on a login manager, since it's
reasonable to use without.

At most it might make sense to add Suggests: x-display-manager.  But apt does
not install Suggests by default, so you'd still need to request it manually.
Would this be an improvement?

> I know that 'entrance' is not considered stable/mature at the moment but I
> guess an another login manager could be installed anyway, one that does not
> require way too many dependencies.

If entrance (or some other EFL-based login manager) were mature, I'd be tempted
to add an enlightenment-desktop metapackage.  But I don't think this is likely.

Ross

Bug#954110: python3-pip: --extra-index-url broken due to requests unvendoring

[Ross Vandegrift]

Package: python3-pip
Version: 18.1-5
Severity: normal

Hello,

#837764 is marked as fixed in 18.1-5, but I still have this problem in buster.
I'm opening a new bug since the old one is archived.

The diffs linked at [1] do not seem to have been applied when I look at
/usr/lib/python3/dist-packages/pip/_vendor/__init__.py.

pip in sid works correctly.

Example:

$ python3 -m venv venv
$ venv/bin/pip install -v --extra-index-url $private_repo private_package
Could not install packages due to an EnvironmentError.
Traceback (most recent call last):
  File 
"/home/ross/venv/lib/python3.7/site-packages/pip/_internal/commands/install.py",
 line 338, in run
resolver.resolve(requirement_set)
  File "/home/ross/venv/lib/python3.7/site-packages/pip/_internal/resolve.py", 
line 102, in resolve
self._resolve_one(requirement_set, req)
  File "/home/ross/venv/lib/python3.7/site-packages/pip/_internal/resolve.py", 
line 256, in _resolve_one
abstract_dist = self._get_abstract_dist_for(req_to_install)
  File "/home/ross/venv/lib/python3.7/site-packages/pip/_internal/resolve.py", 
line 209, in _get_abstract_dist_for
self.require_hashes
  File 
"/home/ross/venv/lib/python3.7/site-packages/pip/_internal/operations/prepare.py",
 line 218, in prepare_linked_requirement
req.populate_link(finder, upgrade_allowed, require_hashes)
  File 
"/home/ross/venv/lib/python3.7/site-packages/pip/_internal/req/req_install.py", 
line 164, in populate_link
self.link = finder.find_requirement(self, upgrade)
  File "/home/ross/venv/lib/python3.7/site-packages/pip/_internal/index.py", 
line 572, in find_requirement
all_candidates = self.find_all_candidates(req.name)
  File "/home/ross/venv/lib/python3.7/site-packages/pip/_internal/index.py", 
line 530, in find_all_candidates
for page in self._get_pages(url_locations, project_name):
  File "/home/ross/venv/lib/python3.7/site-packages/pip/_internal/index.py", 
line 675, in _get_pages
page = self._get_page(location)
  File "/home/ross/venv/lib/python3.7/site-packages/pip/_internal/index.py", 
line 793, in _get_page
return _get_html_page(link, session=self.session)
  File "/home/ross/venv/lib/python3.7/site-packages/pip/_internal/index.py", 
line 147, in _get_html_page
resp.raise_for_status()
  File 
"/home/ross/venv/share/python-wheels/requests-2.21.0-py2.py3-none-any.whl/requests/models.py",
 line 940, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: 
https://pypi.org/simple/private_package/

Thanks,
Ross

[1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837764#45



-- System Information:
Debian Release: 10.3
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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-pip depends on:
ii  ca-certificates20190110
ii  python-pip-whl 18.1-5
ii  python33.7.3-1
ii  python3-distutils  3.7.3-1

Versions of packages python3-pip recommends:
ii  build-essential 12.6
ii  python3-dev 3.7.3-1
ii  python3-setuptools  40.8.0-1
ii  python3-wheel   0.32.3-2

python3-pip suggests no packages.

-- no debconf information

Bug#951117: libecore1: .xsession-errors eats all disk space

[Ross Vandegrift]

Control: forwarded -1 https://phab.enlightenment.org/T8621
Control: tags -1 upstream

On Thu, Feb 27, 2020 at 02:14:52AM +0300, sergio wrote:
> > Sorry but I don't think I can really help further.  Maybe the upstream
> folks
> > would be able to track something down.
> 
> OK, I'll report this bug on phab.enlightenment.org but really I so tired
> of E bugs, that I'm thinking to switch to another WM (possibly tiling
> with good float mode support). The only thing stopping me is time I need
> for choice and configuration.

Thanks for that.  Sorry that you've had issues with your use-cases.

I still can't seem to trigger this like you can, but I was able to get some
backtraces today.  I'll post these to the phab as well.

ERR<36232>:eo ../src/lib/eo/eo.c:2192 efl_data_scope_get() Eo ID 0x403d1edf 
is not a valid object. Current thread: main. This ID has probably been deleted 
or this was never a valid object ID. (domain=0, current_domain=0, 
local_domain=0, available_domains=[0 1], generation=2df, id=f47, ref=1)

/usr/lib/x86_64-linux-gnu/libeina.so.1 |
./obj-x86_64-linux-gnu/../src/lib/eina/eina_log.c : 2054 @ 
eina_log_print_cb_stderr.part.0()
/usr/lib/x86_64-linux-gnu/libeina.so.1 |
./obj-x86_64-linux-gnu/../src/lib/eina/eina_log.c : 1456 @ 
eina_log_print_unlocked()
/usr/lib/x86_64-linux-gnu/libeina.so.1 |
./obj-x86_64-linux-gnu/../src/lib/eina/eina_log.c : 2259 @ eina_log_print()
/usr/lib/x86_64-linux-gnu/libeo.so.1   |
??/?? : 2259 @ _eo_obj_pointer_get()
/usr/lib/x86_64-linux-gnu/libeo.so.1   | 
../src/lib/eo/eo.c   : 2192 @ efl_data_scope_get()
/usr/lib/x86_64-linux-gnu/libecore.so.1|   
./obj-x86_64-linux-gnu/../src/lib/ecore/ecore_exe.c:  218 @ 
ecore_exe_pid_get()
 /usr/bin/enlightenment|
../src/bin/e_exec.c   :  814 @ _e_exec_startup_id_pid_find()
/usr/lib/x86_64-linux-gnu/libeina.so.1 |
./obj-x86_64-linux-gnu/../src/lib/eina/eina_iterator.c:  150 @ 
eina_iterator_foreach()
/usr/lib/x86_64-linux-gnu/libeina.so.1 |
./obj-x86_64-linux-gnu/../src/lib/eina/eina_hash.c: 1241 @ 
eina_hash_foreach()
 /usr/bin/enlightenment|
../src/bin/e_exec.c   :  298 @ e_exec_startup_id_pid_instance_find()
 /usr/bin/enlightenment|
../src/bin/e_client.c : 2202 @ _e_client_eval()
 /usr/bin/enlightenment|
../src/bin/e_client.c : 2540 @ e_client_idler_before()
 /usr/bin/enlightenment|
../src/bin/e_main.c   : 1810 @ _e_main_cb_idle_before()
/usr/lib/x86_64-linux-gnu/libecore.so.1|   
./obj-x86_64-linux-gnu/../src/lib/ecore/ecore_idler.c  :   35 @ 
_ecore_factorized_idle_process()
/usr/lib/x86_64-linux-gnu/libeo.so.1   |
??/?? :   35 @ _event_callback_call()
/usr/lib/x86_64-linux-gnu/libeo.so.1   |
??/?? :   35 @ efl_event_callback_call()
/usr/lib/x86_64-linux-gnu/libecore.so.1|   
./obj-x86_64-linux-gnu/../src/lib/ecore/ecore_main.c   : 2413 @ 
_ecore_main_loop_iterate_internal()
/usr/lib/x86_64-linux-gnu/libecore.so.1|   
./obj-x86_64-linux-gnu/../src/lib/ecore/ecore_main.c   : 1198 @ 
_ecore_main_loop_begin()
/usr/lib/x86_64-linux-gnu/libecore.so.1|   
./obj-x86_64-linux-gnu/../src/lib/ecore/efl_loop.c :   58 @ 
_efl_loop_begin()
/usr/lib/x86_64-linux-gnu/libecore.so.1|  
./obj-x86_64-linux-gnu/src/lib/ecore/efl_loop.eo.c  :   28 @ efl_loop_begin()
/usr/lib/x86_64-linux-gnu/libecore.so.1|   
./obj-x86_64-linux-gnu/../src/lib/ecore/ecore_main.c   : 1285 @ 
ecore_main_loop_begin()
 /usr/bin/enlightenment|
../src/bin/e_main.c   : 1100 @ main()
/lib/x86_64-linux-gnu/libc.so.6| 
/build/glibc-TrjWJf/glibc-2.29/csu/../csu/libc-start.c   :  342 @ 
__libc_start_main()
 /usr/bin/enlightenment|
??/?? :  342 @ _start()



ERR<36232>:eo ../src/lib/eo/eo.c:1814 efl_isa() Eo ID 0x403d1edf is not a 
valid object. Current thread: main. This ID has probably been deleted or this 
was never a valid object ID. (domain=0, current_domain=0, local_domain=0, 
available_domains=[0 1], generation=2df, id=f47, ref=1)

/usr/lib/x86_64-linux-gnu/libeina.so.1 |
./obj-x86_64-linux-gnu/../src/lib/eina/eina_log.c : 2054 @ 
eina_log_print_cb_stderr.part.0()
/usr/lib/x86_64-linux-gnu/libeina.so.1 |
./obj-x86_64-linux-gnu/../src/lib/eina/eina_log.c : 1456 @ 
eina_log_print_unlocked()
/usr/lib/x86_64-linux-gnu/libeina.so.1 |
./obj-x86_64-linux-gnu/../src/lib/eina/eina_log.c : 2259 @ 

Bug#951117: libecore1: .xsession-errors eats all disk space

[Ross Vandegrift]

On Mon, Feb 24, 2020 at 01:59:31PM +0300, sergio wrote:
> On 24/02/2020 09:25, Ross Vandegrift wrote:
> Just tried, yes, I can trigger it on the clean user profile, with only
> one file left:
> 
> % cat .xsession
> enlightenment_start
> 
> Looks like you need to remove the shelf.
> 
> > If it does trigger, there might be something else different about your
> > system.
> 
> Have you exactly Maximize Fullscreen'ed? It's not just Fullscreen.

Now I can trigger the message, but not a nonstop stream.  E prints it while
opening and closing tilix, but not otherwise.  Moreover, I can only trigger it
in the same session where I do all of the config.  After logging out and back
in, the message is not printed.  Also, it doesn't happen under Xephyr at all.

Sorry but I don't think I can really help further.  Maybe the upstream folks
would be able to track something down.


For the record, the full sequence I came up with is:
0. Install tilix and E.
1. Start a fresh E profile, go through the first run wizard.
2. Delete the default shelf.
3. Open Settings
   a. Windows -> Window Geometry -> Maximization
  i. Set Policy to Fullscreen
 ii. Enable "Allow manipulation of maximized windows"
iii. Enable "Allow windows above fullscreen windows"
 iv. OK
   b. Input -> Key Bindings
  i. Add a binding for Window:State:Maximize Fullscreen
 ii. OK
4. Restart Enlightenment from the Enlightenment menu
5. Run tilix and maximize with the key binding from 3.b.i
6. Run tilix and close it immediately by exiting the terminal.

Repeat 6 a few times, eventually it logs this a few times:
ERR<2605>:eo ../src/lib/eo/eo.c:2192 efl_data_scope_get() Eo ID 
0x40098cfa is not a valid object. Current thread: main. This ID has 
probably been deleted or this was never a valid object ID. (domain=0, 
current_domain=0, local_domain=0, available_domains=[0 1], generation=fa, 
id=263, ref=1)

Ross

Bug#952403: enlightenment: another error eats all disk space

[Ross Vandegrift]

Control: tags -1 confirmed upstream
Controls: retitle -1 E triggers lots of evas_object_smart_data_get log messages

On Sun, Feb 23, 2020 at 11:37:55PM +0300, sergio wrote:
> ERR<1162>:evas_main ../src/lib/evas/canvas/evas_object_smart.c:145 
> evas_object_smart_data_get() calling smart object API on non-smart object!
> 
> 
> To reproduce you need e config. It's binary and I'm not sure there are
> no private data, so I'll send archive to Ross directly.

I see this without any special config.  A recent change in evas added this
message, but does seem to have added sufficient logging to track down the
actual source of the error.

Upstream report evas lacking info for troubleshooting:
https://phab.enlightenment.org/T8619

Ross

Bug#951117: libecore1: .xsession-errors eats all disk space

[Ross Vandegrift]

On Mon, Feb 24, 2020 at 02:04:38AM +0300, sergio wrote:
> On 24/02/2020 01:11, Ross Vandegrift wrote:
> 
> > Thanks for the details.  Unfortunately, I still cannot reproduce this.
>  I've
> > tried restarting Enlightenment and then opening tilix, making it
> fullscreen,
> > and then exiting.
> 
> You should be able to reproduce this bug with the config that I've send you
> for the next one.
> 
> > How do you get a window on top of fullscreened tilix?
> 
> Sorry for bad explanation, it should be vice-versa: tilix on top of
> another fullscreened window.
> 
> 
> >  As soon as I do anything that would raise another window
> >  (Ctrl-Alt-down, Alt-Tab, etc), tilix exits fullscreen mode.
> 
> My settings:
> 
> Windows -> Window Geometry -> Maximization
> Policy: Fullscreen
> Direction: Both
> Manipulation:
> Allow manipulation of maximized windows: yes
> Allow windows above fullscreen window: yes

I still can't trigger the issue with your configuration.  Have you tried with a
fresh E config?  IF that doesn't trigger the issue, then I think we just
haven't found the right settings.  If it does trigger, there might be something
else different about your system.

Ross

Bug#951117: libecore1: .xsession-errors eats all disk space

[Ross Vandegrift]

On Sun, Feb 23, 2020 at 10:37:13PM +0300, sergio wrote:
> More details:
> 
> instead of fullscreening the tilix it can be closed when it's above
> another fullscreen window
> 
> I'm unable to reproduce it just after session start, but after restart
> it reproduces frequently.
> 
> So the sequence is:
> 
> 1. restart enlightment
> 2. open tilix
> 3. put tilix above another fullscreen window or fullscreen itself
> 4. close it
> 5. repeat the sequence several times untill errors will be massively
> printed into ~/.xsession-errors
> 
> I've checked this on NUC, and it's reproducable.

Thanks for the details.  Unfortunately, I still cannot reproduce this.  I've
tried restarting Enlightenment and then opening tilix, making it fullscreen,
and then exiting.  Even after two dozen cycles, no constant stream of logs is
triggered.

How do you get a window on top of fullscreened tilix?  As soon as I do anything
that would raise another window (Ctrl-Alt-down, Alt-Tab, etc), tilix exits
fullscreen mode.

I've also tried testing with and without fullscreen compositing enabled, it
doesn't seem to make a difference.

Ross

Bug#951413: efl FTCBFS: DEB_VERSION empty, more tools missing

[Ross Vandegrift]

Control: tags -1 pending

On Sun, Feb 16, 2020 at 08:41:01AM +0100, Helmut Grohne wrote:
> So with this second patch, efl cross builds successfully here. Please
> consider applying it and thanks for bearing with me.

Very cool - thanks for the fix, it'll be in the next upload.

Ross

Bug#951117: libecore1: .xsession-errors eats all disk space

[Ross Vandegrift]

On Fri, Feb 21, 2020 at 11:10:35AM +0300, sergio wrote:
> 
> > Thanks, I've setup a session to stay open and idle for tonight.  Let's
> > see what happens if I let it sit for a while.

So far, no results - E logged zero messages overnight while I wasn't
interacting with it.

Which rendering backend do you use?  You can check in Settings -> Look
-> Compositor -> Rendering.

> I've just realized that I've another E runned permanently on intel NUC,
> there no above errors, but a lot of
> 
> ERR<1162>:evas_main ../src/lib/evas/canvas/evas_object_smart.c:145
> evas_object_smart_data_get() calling smart object API on non-smart object!

Do you logs contain any backtraces along with these messages?  While
investigating this bug, I found these too - they are trigered when
interacting with EFL windows.

When I asked upstream, I was told that there should be a backtrace along
with the message if libunwindsupport was built in.  I don't get any
backtrace, but haven't had time to investigate further.

Ross

Bug#951117: libecore1: .xsession-errors eats all disk space

[Ross Vandegrift]

On Thu, Feb 20, 2020 at 11:51:04AM +0300, sergio wrote:
> On 17/02/2020 09:03, Ross Vandegrift wrote:
> > Okay great- about how long it was from the time the session started to the 
> > time
> > you saw the log messages?
> 
> I'm monitoring .xsession-errors and can't say anything definite.
> Sometimes it takes several hours, sometimes I don't see it for a day or
> two. Anyway I see no obvious triggers. I have a couple apps runned
> permanently and have no idea what it can be.

Thanks, I've setup a session to stay open and idle for tonight.  Let's
see what happens if I let it sit for a while.

Thanks,
Ross

Bug#951117: libecore1: .xsession-errors eats all disk space

[Ross Vandegrift]

On Sun, Feb 16, 2020 at 10:04:59PM +0300, sergio wrote:
> > Does this end if you restart enlightenemnt? (Main -> Enlightenment ->
> > Restart)
> 
> I've just captured this condition before the end of the free space and
> can answer the question: yes, enlightenemnt restart stops this errors.

Okay great- about how long it was from the time the session started to the time
you saw the log messages?

Thanks,
Ross

Bug#951117: libecore1: .xsession-errors eats all disk space

[Ross Vandegrift]

Control: severity -1 normal
Control: reassign -1 enlightenment 0.23.1-4
Control: retitle -1 eo logs in .xsession-errors eat all disk space

On Tue, Feb 11, 2020 at 01:31:28PM +0300, sergio wrote:
> Package: libecore1
> Version: 1.23.3-6
> Severity: critical
> Justification: breaks unrelated software
> 
> Dear Maintainer,
> 
> it's critical as it eats all disk space causing other programs fail and
> lose data.

I haven't seen this, so lowering the priority to normal.  Let's try to
figure out the trigger.

> I don't know how to reproduce it. It happens after several days of
> running enlightenment. (My desktop is always on.)
> 
> At the beginning all works fine, and ~/.xsession-errors takes less than
> 100Kb. But some time later I find it taking all free space (dozen
> gigabytes in my case).

How do you start enlightenment?  Does your desktop suspend after
inactivity?  Do you leave any other EFL apps running?

> It repeats the following two lines endlessly:
> 
> ERR<32091>:eo ../src/lib/eo/eo.c:2192 efl_data_scope_get() Eo ID 
> 0x402d3617 is not a valid object. Current thread: main. This ID has 
> probably been deleted or this was never a valid object ID. (domain=0, 
> current_domain=0, local_domain=0, available_domains=[0 1], 
> generation=217, id=b4d, ref=1)
> ERR<32091>:eo ../src/lib/eo/eo.c:1814 efl_isa() Eo ID 0x402d3617 is not a 
> valid object. Current thread: main. This ID has probably been deleted or this 
> was never a valid object ID. (domain=0, current_domain=0, local_domain=0, 
> available_domains=[0 1], generation=217, id=b4d, ref=1)

Does this end if you restart enlightenemnt? (Main -> Enlightenment ->
Restart)

> With the previous version of E all worked fine, began to happen with the
> update to 0.23.1-4

This bug was opened against libecore1, not enlightenment.  I've
reassigned.

Ross

Bug#950420: efl FTCBFS: src/bin/eolian/meson.build:25:2: ERROR: Program(s) ['eolian_gen'] not found or not executable

[Ross Vandegrift]

Control: tags -1 pending

On Tue, Feb 04, 2020 at 07:28:12AM +0100, Helmut Grohne wrote:
> On Mon, Feb 03, 2020 at 10:14:24PM -0800, Ross Vandegrift wrote:
> > - The Build-Depends for eolian_gen is versioned like this: 
> > libeolian-bin (= ${source:Upstream-Version}) 
[snip]
> However, dpkg does not support substitution variables in Build-Depends,
> so this dependency won't be satisfiable due to not being substituted.
> We've had this for qtbase-opensource-src recently and agreed to turn it
> into a build-time check (i.e. have debian/rules reject a different
> version). Does that work for you?

Yes, that works, thanks for the tip.  I copied the approach from
qtbase-opensource-src, and it'll be in the next upload.

Ross

Bug#950420: efl FTCBFS: src/bin/eolian/meson.build:25:2: ERROR: Program(s) ['eolian_gen'] not found or not executable

[Ross Vandegrift]

Hi Helmut,

On Sat, Feb 01, 2020 at 01:10:25PM +0100, Helmut Grohne wrote:
> I'm proposing a libefl-all-dev-bin package. We simply move eolian_gen to
> that new package and have libefl-all-dev depend on it. For consumers,
> nothing changes. Two things do change:
>  * libefl-all-dev-bin is being marked Multi-Arch: foreign, so eolian_gen
>becomes usable for cross compilation.
>  * efl can build depend on libefl-all-dev-bin  to make the tool
>available.
> 
> Please consider applying the attached patch. Yes, that means going
> through NEW.

Sounds fine to me, I pushed a tweaked version of your patch to salsa.  There
are two small changes.

- I modified it to create libeolian-bin.  The other /usr/bin/ binaries in
  libefl-all-dev are debug tools not used during build (so no real need for a
  general package).  And libeolian-bin is more in line with how the other EFL
  packages are divided up.

- The Build-Depends for eolian_gen is versioned like this: 
libeolian-bin (= ${source:Upstream-Version}) 
  eolian is not officially stable upstream, which means they are still open to
  breaking changes.  Thus building EFL 1.X with eolian_gen 1.Y could be
  problematic.  Will this be burdensome for cross builds?


Thanks for the good explanation and patch,
Ross

Bug#941774: lintian: False positive for symbols-file-contains-current-version-with-debian-revision

[Ross Vandegrift]

Hi Felix,

I forgot all about this, thanks for following up.

On Sat, Dec 14, 2019 at 02:15:41PM -0800, Felix Lechner wrote:
> $ fgrep -- -5 dir2/symbols
>  
> _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPcEEvT_S7_St20forward_iterator_tag@Base
> 1.21.1-5+b1
> 
> The symbol shows a Debian revision. Lintian is right.

Aha - I was searching the symbols file from the source package.  Now I see that
the binary package's symbols file is not necessarily the same.  Sorry for the
mistake.

> As a side note, I was surprised to find 188 additional Debian revisions:

These are intentional (and have overrides).  See "Note on eolian-generated
symbols" in README.source if you're curious.

> Finally, I am not sure why some symbols were decoded properly using
> the appropriate pattern [1], while the offender is raw 'c++'. Did you
> mix C and C++ symbols in the same shared library?

Yes, by accident - libephysics uses a c++ library, and was leaking this c++
symbol.  Looks like gcc8 -O2 inlined this function, while gcc9 doesn't until
-O3.

Ross

Bug#946130: efl: edje.pc has incorrect lua dependency without luajit

[Ross Vandegrift]

Source: efl
Version: 1.23.2-1
Severity: important

Starting in EFL 1.23, meson generates this Requires on non-luajit architectures
in edje.pc:
  Requires: evas, eo, efl, ephysics, lua52 >= 5.2.0, lua52 < 5.3.0, lua

The unversioned lua entry is not satisfiable.  This causes enlightenment to
FTFBS on non-luajit architectures.

Ross

Bug#942756: cme: please provide more description of the format of d/fix.scanned.copyright

[Ross Vandegrift]

Control: tags -1 patch

On Mon, Oct 21, 2019 at 05:17:59PM +0200, Dominique Dumont wrote:
> The data contained in debian/copyright is mapped to a tree structure inside 
> cme. You can have a view of this structure by running 'cme dump dpkg-
> copyright' or get a graphical view with 'cme edit dpkg-copyright'
> 
> The instructions specified in fix.scanned.copyright are steps to walk in that 
> tree and alter the values when specified.

Aha, now this is coming together.

> > Things that I'd find helpful:
> > - what is the general form of these lines?  If that's too complex, examples
> >   covering more use-cases would be helpful.
> 
> In fact, I've found that tweaking debian/fill.copyright.blanks.yml often 
> provide better results. All in all, I've found very few cases where tweaking 
> d/fix.scanned.copyright provided better results than tweaking debian/
> fill.copyright.blanks.yml 

Makes sense - though am I correct to think that fix.scanned.copyright is for
fixing extractions that include html entities, weird chars from upstream, etc?

> I understand that Config::Model::Loader synopsis is for only for Perl
> programmer. 
> 
> On the other hand, the "load string syntax" section was intended to provide
> instructions usable for non-perl programmers. Was that section overwhelming
> as well ?

It was originally, but after your message, it's much more clear.  There's not
nearly as much to learn as it originally looked like.

> In any case, I may need to split this man page... What do you think ?

No, I don't think that's necessary anymore.  Maybe a few more words of
description, and some pointers to the Config::Model::Loader section.  Possible
patches are attached that use the explanations you sent me.

Ross
diff --git a/lib/App/Cme/Command/update.pm b/lib/App/Cme/Command/update.pm
index b4a36ea..997cc3d 100644
--- a/lib/App/Cme/Command/update.pm
+++ b/lib/App/Cme/Command/update.pm
@@ -103,6 +103,13 @@ Update a configuration file. The update is done scanning external resource. For
 the update of dpkg-copyright is done by scanning the headers of source files. (Actually, only
 dpkg-copyright model currently supports updates)
 
+The data contained in debian/copyright is mapped to a tree structure inside cme. You can have
+a view of this structure by running 'cme dump dpkg-copyright' or get a graphical view with
+'cme edit dpkg-copyright'.
+
+Sometimes the output will need adjusting.  See the section "Tweak results" in
+Config::Model::Dpkg::Copyright for ways to control cme's output.
+
 Example:
 
cme update dpkg-copyright
diff --git a/lib/Config/Model/Dpkg/Copyright.pm b/lib/Config/Model/Dpkg/Copyright.pm
index 961cc360..272734c0 100644
--- a/lib/Config/Model/Dpkg/Copyright.pm
+++ b/lib/Config/Model/Dpkg/Copyright.pm
@@ -423,8 +423,14 @@ based on comments, the result is sometimes lackluster. Your may
 specify instruction to alter or set specific copyright entries in
 C file
 (or C<< debian/.fix.scanned.copyright >>).
-Each line of this file will be handled
-by L to modify copyright information.
+
+cme stores the copyright information in a tree.  Entries in
+fix.scanned.copyright provide instructions for traversing the cme tree
+and modifying entries.  You can have a view of debian/copyright file
+translated in this syntax by running 'cme dump --format cml
+dpkg-copyright'.  Each line of this file will be handled by
+L to modify copyright information; the full
+syntax is documented in the "load string syntax" section.
 
 =head2 Example
 
@@ -464,6 +470,12 @@ Here's another more complex example:
  # and modify the copyright entry with a Perl substitution
  ! Files:~/^3rdparty/ Copyright=~s/@/(at)/
 
+Sometimes, you might want to find an entry that spans multiple lines.
+You can do this by double quoting the whole value:
+
+ ! Files:"uulib/crc32.h
+ uulib/uustring.h" Copyright="2019 John Doe"
+
 =head1 Under the hood
 
 This section explains how cme merges the information from the existing

Bug#942756: cme: please provide more description of the format of d/fix.scanned.copyright

[Ross Vandegrift]

Package: cme
Version: 1.030-1
Severity: wishlist

Hello,

I started to use cme to maintain d/copyright today.  It'll be a big help, so
thanks!  But I ran into a few snags.

I'm not sure how d/fix.scanned.copyright is supposed to work.  Some examples in
Config::Model::Dpkg::Copyright(3pm) are clear but trivial.  They allude to some
complex capabilities without any explanation ("don't forget '!' to go back to
tree root": but what tree is there?  This is a text file with a few lines.)  I
think I need some more help from the point of view of someone trying to
automate management of d/copyright.

Things that I'd find helpful:
- what is the general form of these lines?  If that's too complex, examples
  covering more use-cases would be helpful.
- how should I handle stanzas with multiple lines in Files, Copyright, etc.?
- there appears to be a few ways to modify d/copyright stanzas.  What are the
  possibilities?

I found Config::Model::Loader(3pm) but it was overwhelming.  Documenting the
data structures doesn't help much since I'm not a perl programmer and I'd
rather avoid learning about the generic serialization described there.

Thanks,
Ross

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 cme depends on:
ii  libapp-cmd-perl   0.331-1
ii  libconfig-model-perl  2.136-1
ii  libjson-perl  4.02000-1
ii  liblog-log4perl-perl  1.49-1
ii  libpath-tiny-perl 0.108-1
ii  libpod-pom-perl   2.01-3
ii  libyaml-perl  1.29-1
ii  perl  5.28.1-6

Versions of packages cme recommends:
ii  libconfig-model-approx-perl   1.011-1
ii  libconfig-model-dpkg-perl 2.126
ii  libconfig-model-lcdproc-perl  2.052-2
ii  libconfig-model-openssh-perl  2.8.0.1-1
ii  libconfig-model-systemd-perl  0.240.1-1
ii  libconfig-model-tkui-perl 1.370-1

Versions of packages cme suggests:
pn  libconfig-model-cursesui-perl  
pn  libconfig-model-itself-perl

-- no debconf information

Bug#941774: lintian: False positive for symbols-file-contains-current-version-with-debian-revision

[Ross Vandegrift]

On Sat, Oct 05, 2019 at 02:30:30AM -0400, Scott Kitterman wrote:
>  (optional=templinst|arch=!amd64 !arm64 
> !x32)_ZN8nitrokey5proto17ResponseDissectorILNS0_9CommandIDE0ERKNS0_14DeviceResponseILS2_0ENS0_7stick109GetStatus15ResponsePayload24status_translate_commandB5cxx11Ei@Base
>  3.5
> 
>  No dash anywhere.  In fact, in only dashes in the entire symbols file
>  are in the first three lines of the file:

I'm seeing a similar false positive:

E: libephysics1: symbols-file-contains-current-version-with-debian-revision on 
symbol 
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPcEEvT_S7_St20forward_iterator_tag@Base

Though in my case, there's no such symbol in the symbols file.  This is from a
local run of lintian 2.25.0, this version of libephysics1 hasn't been uploaded
yet.

Ross

Bug#941831: gir1.2-gnomedesktop-3.0: 3.34.0-2 causes gdm3 black screen

[Ross Vandegrift]

Package: gir1.2-gnomedesktop-3.0
Version: 3.34.0-2
Severity: normal

Dear Maintainer,

After installing gir1.2-gnomedesktop-3.0 3.34.0-2, gdm3 only displays a black
screen.  Downgrading to 3.30.2.1-2 and restarting gdm3 fixes the issue.

Ross

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 gir1.2-gnomedesktop-3.0 depends on:
ii  gir1.2-gdesktopenums-3.0  3.28.1-1
ii  gir1.2-glib-2.0   1.62.0-2
ii  gir1.2-gtk-3.03.24.11-1
ii  libgnome-desktop-3-18 3.34.0-2

gir1.2-gnomedesktop-3.0 recommends no packages.

gir1.2-gnomedesktop-3.0 suggests no packages.

-- no debconf information

Bug#931669: ephoto doesn't even start up

[Ross Vandegrift]

Control: retitle -1 crashes when editing custom directory setting
Control: tags -1 confirmed

On Sun, Aug 11, 2019 at 08:12:29AM -0500, Michael Meier wrote:
> I've installed libevas1-engine-x (with -drm it didn't work).
> 
> Now it starts up, but then it segfaults. Here first the startup messages:

Thanks for confirming the startup issue.  I can reproduce the crash on custom
directory edit.  It's better in upstream git- assuming it's in otherwise good
shape, I'll try to package a snapshot soon.

Ross

Bug#934196: salt-ssh: ssh keys are loaded from /var/lib/salt instead of /etc/salt

[Ross Vandegrift]

Package: salt-ssh
Version: 2018.3.4+dfsg1-6
Severity: normal

After upgrading to buster, salt-ssh was no longer able to connect to my
configured hosts.  Instead, I'd get a 'do you want to deploy the
salt-ssh key?' prompt.  I said yes and salt deployed a strange key.

Tracking down the key pointed me to /var/lib/salt:
$ sudo salt-ssh -l trace ravenhurst test.ping 2>&1 | grep IdentityFile
[TRACE   ] Executing command: ssh ravenhurst.kallisti.us -o 
KbdInteractiveAuthentication=no -o PasswordAuthentication=no -o 
GSSAPIAuthentication=no -o ConnectTimeout=65 -o Port=22 -o 
IdentityFile=/var/lib/salt/pki/master/ssh/salt-ssh.rsa -o User=root  /bin/sh << 
'EOF'

But the pki_dir setting is the default:
$ sudo grep -r pki_dir: /etc/salt
/etc/salt/master:#pki_dir: /etc/salt/pki/master

As a workaround, I moved /var/lib/salt/pki/master out of the way and
symlinked it to /etc/salt/pki/master.

Ross

-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable'), (40, 'unstable'), (30, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-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)

Versions of packages salt-ssh depends on:
ii  python3  3.7.3-1
ii  salt-common  2018.3.4+dfsg1-6

salt-ssh recommends no packages.

salt-ssh suggests no packages.

-- Configuration Files:
/etc/salt/roster changed [not included]

-- no debconf information

Bug#930178: salt-master: install fails if salt-minion was installed first

[Ross Vandegrift]

Package: salt-ssh
Version: 2018.3.4+dfsg1-6
Followup-For: Bug #930178

I ran into this tonight but was able to workaround by an uninstall &
reinstall of salt-master.

Ross

Bug#934195: salt-ssh: Failed to prepare the Salt environment for user salt. The user is not available.

[Ross Vandegrift]

Package: salt-ssh
Version: 2018.3.4+dfsg1-6
Severity: normal

Under stretch, I used salt-ssh without salt-master to manage a handful
of hosts.  After upgrading to buster, I ran into this error:

$ sudo salt-ssh ravenhurst --verbose -l debug test.ping
[DEBUG   ] Missing configuration file: /etc/salt/master
[DEBUG   ] Using cached minion ID from /etc/salt/minion_id: vanvanmojo
Failed to prepare the Salt environment for user salt. The user is not available.

The salt user is created by salt-master (though I ran into #930178 the
first time I tried to install).  Once I got salt-master installed, the
user existed and salt-ssh could work again.

Should salt-ssh depend on salt-master now?

Ross

-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable'), (40, 'unstable'), (30, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-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)

Versions of packages salt-ssh depends on:
ii  python3  3.7.3-1
ii  salt-common  2018.3.4+dfsg1-6

salt-ssh recommends no packages.

salt-ssh suggests no packages.

-- Configuration Files:
/etc/salt/roster changed [not included]

-- no debconf information

Bug#933874: efl: FTBFS on sparc64, m68k: relocation truncated to fit during linking

[Ross Vandegrift]

Source: efl
Version: 1.22.2-1
Severity: wishlist

EFL 1.22.2-1 fails to link on sparc64, m68k.

sparc64:

libtool: link: gcc -shared  -fPIC -DPIC  lib/eet/.libs/libeet_la-eet_alloc.o 
lib/eet/.libs/libeet_la-eet_cipher.o lib/eet/.libs/libeet_la-eet_connection.o 
lib/eet/.libs/libeet_la-eet_data.o lib/eet/.libs/libeet_la-eet_dictionary.o 
lib/eet/.libs/libeet_la-eet_image.o lib/eet/.libs/libeet_la-eet_lib.o 
lib/eet/.libs/libeet_la-eet_node.o lib/eet/.libs/libeet_la-eet_utils.o 
static_libs/rg_etc/.libs/lib_eet_libeet_la-rg_etc1.o 
static_libs/rg_etc/.libs/lib_eet_libeet_la-rg_etc2.o 
static_libs/rg_etc/.libs/lib_eet_libeet_la-etc2_encoder.o   -Wl,-rpath 
-Wl,/<>/src/lib/eina/.libs -Wl,-rpath 
-Wl,/<>/src/lib/emile/.libs -ldl -lgnutls 
lib/eina/.libs/libeina.so lib/emile/.libs/libemile.so -lpthread -ljpeg -lm 
-lgcrypt -lrt  -g -O2 -fstack-protector-strong -Wl,-z -Wl,relro -Wl,-z -Wl,now 
-Wl,-z -Wl,defs -Wl,--as-needed -Wl,--gc-sections -Wl,--as-needed 
-Wl,--no-copy-dt-needed-entries   -Wl,-soname -Wl,libeet.so.1 -o 
lib/eet/.libs/libeet.so.1.22.2
bin/embryo/embryo_cc-embryo_cc_sc1.o: in function `resetglobals':
./src/bin/embryo/embryo_cc_sc1.c:509:(.text.resetglobals+0x10): relocation 
truncated to fit: R_SPARC_GOT13 against symbol `code_idx' defined in 
.bss.code_idx section in bin/embryo/embryo_cc-embryo_cc_scvars.o
./src/bin/embryo/embryo_cc_sc1.c:510:(.text.resetglobals+0x14): relocation 
truncated to fit: R_SPARC_GOT13 against symbol `ntv_funcid' defined in 
.bss.ntv_funcid section in bin/embryo/embryo_cc-embryo_cc_scvars.o
./src/bin/embryo/embryo_cc_sc1.c:511:(.text.resetglobals+0x18): relocation 
truncated to fit: R_SPARC_GOT13 against symbol `curseg' defined in .bss.curseg 
section in bin/embryo/embryo_cc-embryo_cc_scvars.o
./src/bin/embryo/embryo_cc_sc1.c:512:(.text.resetglobals+0x1c): relocation 
truncated to fit: R_SPARC_GOT13 against symbol `freading' defined in 
.bss.freading section in bin/embryo/embryo_cc-embryo_cc_scvars.o
./src/bin/embryo/embryo_cc_sc1.c:513:(.text.resetglobals+0x20): relocation 
truncated to fit: R_SPARC_GOT13 against symbol `fline' defined in .bss.fline 
section in bin/embryo/embryo_cc-embryo_cc_scvars.o
./src/bin/embryo/embryo_cc_sc1.c:514:(.text.resetglobals+0x24): relocation 
truncated to fit: R_SPARC_GOT13 against symbol `fnumber' defined in 
.bss.fnumber section in bin/embryo/embryo_cc-embryo_cc_scvars.o
./src/bin/embryo/embryo_cc_sc1.c:508:(.text.resetglobals+0x28): relocation 
truncated to fit: R_SPARC_GOT13 against symbol `glb_declared' defined in 
.bss.glb_declared section in bin/embryo/embryo_cc-embryo_cc_scvars.o
./src/bin/embryo/embryo_cc_sc1.c:499:(.text.resetglobals+0x2c): relocation 
truncated to fit: R_SPARC_GOT13 against symbol `curfunc' defined in COMMON 
section in bin/embryo/embryo_cc-embryo_cc_scvars.o
./src/bin/embryo/embryo_cc_sc1.c:503:(.text.resetglobals+0x3c): relocation 
truncated to fit: R_SPARC_GOT13 against symbol `litidx' defined in .bss.litidx 
section in bin/embryo/embryo_cc-embryo_cc_scvars.o
./src/bin/embryo/embryo_cc_sc1.c:504:(.text.resetglobals+0x40): relocation 
truncated to fit: R_SPARC_GOT13 against symbol `stgidx' defined in .bss.stgidx 
section in bin/embryo/embryo_cc-embryo_cc_scvars.o
./src/bin/embryo/embryo_cc_sc1.c:505:(.text.resetglobals+0x44): additional 
relocation overflows omitted from the output
collect2: error: ld returned 1 exit status


m68k:
-
libtool: link: gcc -g -O2 -fdebug-prefix-map=/<>=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -fvisibility=hidden -fpie 
-specs=/usr/share/dpkg/pie-link.specs -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z 
-Wl,defs -Wl,--as-needed -fPIC -DPIC -pie -rdynamic -o 
bin/elementary/.libs/elementary_test bin/elementary/elementary_test-test.o 
bin/elementary/elementary_test-test_explode.o 
bin/elementary/elementary_test-test_3d.o 
bin/elementary/elementary_test-test_access.o 
bin/elementary/elementary_test-test_actionslider.o 
bin/elementary/elementary_test-test_anim.o 
bin/elementary/elementary_test-test_bg.o 
bin/elementary/elementary_test-test_box.o 
bin/elementary/elementary_test-test_bubble.o 
bin/elementary/elementary_test-test_button.o 
bin/elementary/elementary_test-test_ui_button.o 
bin/elementary/elementary_test-test_calendar.o 
bin/elementary/elementary_test-test_check.o 
bin/elementary/elementary_test-test_clock.o 
bin/elementary/elementary_test-test_cnp.o 
bin/elementary/elementary_test-test_code.o 
bin/elementary/elementary_test-test_colorselector.o 
bin/elementary/elementary_test-test_colorclass.o 
bin/elementary/elementary_test-test_combobox.o 
bin/elementary/elementary_test-test_config.o 
bin/elementary/elementary_test-test_conform.o 
bin/elementary/elementary_test-test_conform_indicator.o 
bin/elementary/elementary_test-test_ctxpopup.o 
bin/elementary/elementary_test-test_cursor.o 
bin/elementary/elementary_test-test_datetime.o 
bin/elementary/elementary_test-test_dayselector.o 

Bug#933747: closed by Ross Vandegrift (Bug#933747: fixed in efl 1.22.2-1)

[Ross Vandegrift]

Control: reopen -1
Control: tags -1 pending

On Sun, Aug 04, 2019 at 02:05:04PM +0200, Aurelien Jarno wrote:
> Thanks a lot for the quick fix. I gave a quick look to the new version,
> there is a missing change, which was also missing in my first version of
> the patch, sorry about that. Here is a patch to fix that:

Thanks for the patch, applied.  I should have an upload out shortly.

Ross


signature.asc
Description: PGP signature

Bug#933747: efl: please build with lua-old on riscv64

[Ross Vandegrift]

On Fri, Aug 02, 2019 at 10:57:25PM +0200, John Paul Adrian Glaubitz wrote:
> On 8/2/19 10:50 PM, Aurelien Jarno wrote:
> > efl can't be built on riscv64 as it build-depends on libluajit-5.1-dev
> > which has not been ported yet on this architecture. As efl is an
> > important reverse dependency, would it be possible to adopt the same
> > strategy as already done for arm64 and 390x, that is building with
> > lua-old instead of luajit?

Yes, definitely - thanks for the patch!

> Could this be done for *any* architecture that does not support LuaJIT?
> 
> This should include alpha, ia64, hppa, m68k, sh4, sparc64 and x32.

Also yes - I'm preparing a 1.22 upload, I'll include a similar change
for the other arches without luajit.

Ross

Bug#931669: ephoto doesn't even start up

[Ross Vandegrift]

Control: severity -1 normal

Hi Michael,

I bet there's no rendering engine package installed.  You can check
with: dpkg -l libevas1-engines*.  If so, installing libevas1-engines-x
should fix the issue.

Currently, ephoto Depends on libevas1, which Recommends
libevas1-engines*.  That can't be tightened to Depends without creating
a circular dependency (libevas1-engines* Depends on libevas1).  If apt's
config disables recommends, it'll leave you in this situation.

I've been trying to avoid making all EFL packages depend on the engines,
but maybe it's time to give that up.  You're the second person to run
into this.

Thanks,
Ross

On Mon, Jul 08, 2019 at 10:57:39PM -0500, Michael Meier wrote:
> Package: ephoto
> Version: 1.5-2
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> I've just installed ephoto to try it out. I didn't get very far. It doesn't
> even start up. If I try to start it up on the console, that's what it tells 
> me:
> 
> ERR<26189>:ecore_evas lib/elementary/efl_ui_win.c:5300
> _elm_win_finalize_internal() Cannot create window.
> ## Copy & Paste the below (until EOF) into a terminal, then hit Enter
> 
> eina_btlog << EOF
> /usr/lib/x86_64-linux-gnu/libeina.so.1   0x7f5ce71dcc0c 0x7f5ce71b3000
> /usr/lib/x86_64-linux-gnu/libeina.so.1   0x7f5ce71dd901 0x7f5ce71b3000
> /usr/lib/x86_64-linux-gnu/libeina.so.1   0x7f5ce71decd3 0x7f5ce71b3000
> /usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b84c6a 0x7f5ce690
> /usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b870c1 0x7f5ce690
> /usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d127a7 0x7f5ce6d01000
> /usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b8750c 0x7f5ce690
> /usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d127a7 0x7f5ce6d01000
> /usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d0f8e4 0x7f5ce6d01000
> /usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b8742b 0x7f5ce690
> /usr/bin/ephoto  0x563c68457604 0x563c6843b000
> /usr/bin/ephoto  0x563c68444b7f 0x563c6843b000
> /usr/bin/ephoto  0x563c684448dc 0x563c6843b000
> /lib/x86_64-linux-gnu/libc.so.6  0x7f5ce641e09b 0x7f5ce63fa000
> /usr/bin/ephoto  0x563c6844491a 0x563c6843b000
> EOF
> 
> ERR<26189>:eo lib/eo/eo.c:993 _efl_add_internal_end() Object of class
> 'Efl.Ui.Win_Legacy' - Not all of the object constructors have been executed.
> ## Copy & Paste the below (until EOF) into a terminal, then hit Enter
> 
> eina_btlog << EOF
> /usr/lib/x86_64-linux-gnu/libeina.so.1   0x7f5ce71dcc0c 0x7f5ce71b3000
> /usr/lib/x86_64-linux-gnu/libeina.so.1   0x7f5ce71dd901 0x7f5ce71b3000
> /usr/lib/x86_64-linux-gnu/libeina.so.1   0x7f5ce71decd3 0x7f5ce71b3000
> /usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d0f9bc 0x7f5ce6d01000
> /usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b8742b 0x7f5ce690
> /usr/bin/ephoto  0x563c68457604 0x563c6843b000
> /usr/bin/ephoto  0x563c68444b7f 0x563c6843b000
> /usr/bin/ephoto  0x563c684448dc 0x563c6843b000
> /lib/x86_64-linux-gnu/libc.so.6  0x7f5ce641e09b 0x7f5ce63fa000
> /usr/bin/ephoto  0x563c6844491a 0x563c6843b000
> EOF
> 
> ERR<26189>:evas_main lib/evas/canvas/evas_object_smart.c:718
> _efl_canvas_group_efl_object_destructor() efl_canvas_group_del() was not 
> called
> on this object: 0x40007457 (Efl.Ui.Win_Legacy)
> ## Copy & Paste the below (until EOF) into a terminal, then hit Enter
> 
> eina_btlog << EOF
> /usr/lib/x86_64-linux-gnu/libeina.so.1   0x7f5ce71dcc0c 0x7f5ce71b3000
> /usr/lib/x86_64-linux-gnu/libeina.so.1   0x7f5ce71dd901 0x7f5ce71b3000
> /usr/lib/x86_64-linux-gnu/libeina.so.1   0x7f5ce71decd3 0x7f5ce71b3000
> /usr/lib/x86_64-linux-gnu/libevas.so.1   0x7f5ce6f9c2c8 0x7f5ce6f02000
> /usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d126c7 0x7f5ce6d01000
> /usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d126c7 0x7f5ce6d01000
> /usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b7025c 0x7f5ce690
> /usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d126c7 0x7f5ce6d01000
> /usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6be29a4 0x7f5ce690
> /usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d126c7 0x7f5ce6d01000
> /usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b82d9b 0x7f5ce690
> /usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d126c7 0x7f5ce6d01000
> /usr/lib/x86_64-linux-gnu/libeo.so.1 0x7f5ce6d0fcec 0x7f5ce6d01000
> /usr/lib/x86_64-linux-gnu/libelementary.so.1 0x7f5ce6b8742b 0x7f5ce690
> /usr/bin/ephoto  0x563c68457604 0x563c6843b000
> /usr/bin/ephoto  0x563c68444b7f 0x563c6843b000
> /usr/bin/ephoto  0x563c684448dc 0x563c6843b000
> /lib/x86_64-linux-gnu/libc.so.6  0x7f5ce641e09b 0x7f5ce63fa000
> /usr/bin/ephoto  0x563c6844491a 0x563c6843b000
> EOF
> 
> 1 rmm@RMMbook ~ % ERR<26198>:efreet_desktop lib/efreet/efreet_desktop.c:986
> efreet_desktop_generic_fields_parse() no Name or _Name fields in file
> '/home/rmm/.local/share/applications/_home_rmm_local_eclipse_jee-2018-12_eclipse_.desktop'
> ## Copy & Paste the 

Bug#923025: powertop: New version 2.10 is available

[Ross Vandegrift]

On Mon, Jul 08, 2019 at 12:05:11AM +0900, Kan-Ru Chen wrote:
> Hi Ross,
> 
> I opened this bug in February. I was going to prepare a NMU to update
> powertop to 2.10 but the official website was down.
> 
> I revisited this again today and found you have a repository on
> salsa.d.o that looks quite complete. Do you intent to upload a new
> version?
> 
> Jose (ghostbar@) if you read this mail, could you let us know if you
> want to continue to maintain the powertop package or you're OK that
> Ross or myself take over the maintainer-ship?

Oh thanks for reminding me, I'd forgotten all about it.  I reached out to Jose
in January to propose collab-maint and never got a response.  I hadn't gotten
as far as uploading or maintaining.  The repo salsa probably has more changes
than appropriate for an NMU.  It'd be reasonable to salvage at this point
though.

Were you hoping to maintain?  I'd be happy to transfer the repo.  I'm also
happy to file an ITS and move it to collaborative maintenance.

Ross


signature.asc
Description: PGP signature

Bug#929822: xserver-xorg-video-amdgpu: display stops updating after VT switch

[Ross Vandegrift]

Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=110808

Bug#929822: xserver-xorg-video-amdgpu: display stops updating after VT switch

[Ross Vandegrift]

Package: xserver-xorg-video-amdgpu
Version: 19.0.1-1
Severity: normal

After starting Xorg with the AMDGPU driver, I switch to a different VT.
When I switch back to X, the display has frozen.  Only the mouse cursor
moves.  To reproduce:

1) From a linux console with no display manager or X session running:
$ startx /usr/bin/xterm
2) Switch to a different VT and back.
3) Nothing appears in the xterm when typing.
4) Switch to a different VT and back, the old typing appears.

The screen isn't updating correctly but the client & server are
functioning.  I can run commands in the terminal, but can't see any
output without a VT switch.  Exiting the xterm immediately ends the X
session cleanly.

The same issue is triggered by a suspend/resume cycle, as a well as
loggin into an X session with gdm.  In both cases, I suspect VT change
is the underlying trigger.

Ross

-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Stoney [Radeon R2/R3/R4/R5 Graphics] [1002:98e4] (rev eb)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rw-r--r-- 1 root root 343 May 30 19:48 libinput.conf

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-3 (2019-05-15)

Xorg X server log files on system:
--
-rw-r--r-- 1 ross ross 46097 May 31 13:18 
/home/ross/.local/share/xorg/Xorg.1.log
-rw-r--r-- 1 ross ross 35981 May 31 14:03 
/home/ross/.local/share/xorg/Xorg.0.log

Contents of most recent Xorg X server log file 
(/home/ross/.local/share/xorg/Xorg.0.log):
-
[  1483.270] 
X.Org X Server 1.20.3
X Protocol Version 11, Revision 0
[  1483.274] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[  1483.276] Current Operating System: Linux momomoto 4.19.0-5-amd64 #1 SMP 
Debian 4.19.37-3 (2019-05-15) x86_64
[  1483.276] Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 
root=/dev/mapper/momomoto--vg-root ro quiet splash
[  1483.279] Build Date: 25 October 2018  06:15:23PM
[  1483.280] xorg-server 2:1.20.3-1 (https://www.debian.org/support) 
[  1483.281] Current version of pixman: 0.36.0
[  1483.284]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[  1483.284] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  1483.290] (==) Log file: "/home/ross/.local/share/xorg/Xorg.0.log", Time: 
Fri May 31 14:02:35 2019
[  1483.292] (==) Using config directory: "/etc/X11/xorg.conf.d"
[  1483.293] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[  1483.293] (==) No Layout section.  Using the first Screen section.
[  1483.293] (==) No screen section available. Using defaults.
[  1483.293] (**) |-->Screen "Default Screen Section" (0)
[  1483.293] (**) |   |-->Monitor ""
[  1483.294] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[  1483.294] (==) Automatically adding devices
[  1483.294] (==) Automatically enabling devices
[  1483.294] (==) Automatically adding GPU devices
[  1483.294] (==) Max clients allowed: 256, resource mask: 0x1f
[  1483.294] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[  1483.294]Entry deleted from font path.
[  1483.294] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[  1483.294] (==) ModulePath set to "/usr/lib/xorg/modules"
[  1483.294] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[  1483.294] (II) Loader magic: 0x5590f93c8e20
[  1483.294] (II) Module ABI versions:
[  1483.294]X.Org ANSI C Emulation: 0.4
[  1483.294]X.Org Video Driver: 24.0
[  1483.294]X.Org XInput driver : 24.1
[  1483.294]X.Org Server Extension : 10.0
[  1483.295] (++) using VT number 2

[  1483.298] (II) systemd-logind: took control of session 
/org/freedesktop/login1/session/_35
[  1483.299] (II) xfree86: Adding drm device (/dev/dri/card0)
[  1483.300] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 11 paused 0
[  1483.305] (--) PCI:*(0@0:1:0) 1002:98e4:1028:087e rev 235, Mem @ 

Bug#927835: enlightenment: icon theme efreet cache is not updated on startup

[Ross Vandegrift]

Control: forwarded -1 https://phab.enlightenment.org/T7978

Bug#927835: enlightenment: icon theme efreet cache is not updated on startup

[Ross Vandegrift]

Control: tags -1 - unreproducible
Control: tags -1 forwarded https://phab.enlightenment.org/T7978

On Tue, May 21, 2019 at 09:11:01PM +0300, sergio wrote:
> Yes. In fact I have the following scheme:

I've configured a user similar to your scheme, and I can confirm that the
Adwaita icon is not loaded when I log in.  In ~etmp/.xsession:

  #!/bin/bash
  rm -rf ~/.cache /tmp/etmp_cache
  ln -s /tmp/etmp_cache ~/.cache
  mkdir $(readlink ~/.cache)
  enlightenment_start

> But really all this doesn't matter as I've just reproduced this issue on
> the new user profile, with empty e setting and no cache logic.
> 
> 1. Just after the first logging in and answering configuration questions
>I see Pavucontrol icon in the application menu.
> 2. I press logout, switch to console (Alt-Ctrl-F1) and wait for the die
>of efreed.
> 3. In the .cache I see only efreed folder. I drop the whole folder or
>only icons_Adwaita_$HOST.eet, it doesn't matter.
> 4. Logging in again into e. The .cache/efreed folder is recreated,
>icons_Adwaita_$HOST.eet is present, but there are no icon for
>Pavucontrol in the application menu

Interesting- I'm not able to reproduce a missing pavucontrol icon.  It gets the
wrong icon, but it does get an icon.

> > Is your /tmp on a different filesystem (i.e., tmpfs)?
> 
> Yes, my /tmp in on a tmpfs.

My /tmp is not, so I think this is ruled out as irrelevant.

Thanks,
Ross

Bug#927835: enlightenment: icon theme efreet cache is not updated on startup

[Ross Vandegrift]

On Tue, May 21, 2019 at 07:25:38AM +0300, sergio wrote:
> On 26/04/2019 22:19, Ross Vandegrift wrote:
> 
> > 1) Application Theme -> Icons, choose Adwaita icon theme.
> > 2) rm ~/.cache/efreet/icons_Adwaita_*
> > 3) log out and back in
> > 4) check pavucontrol icon in everything & menus
> 
> I can reproduce this with libefreet1a=1.21.1-5 from sid.
> 
> 
> > With a fresh efreetd, I cannot reproduce this issue.
> 
> What is "a fresh efreetd"? 

I meant ensuring that efreetd exits before login in step #3.  If you
always reboot after log out, then your efreetd should always be fresh.

Where do you see the icon missing?  Does this only occur if ~/.cache is
on /tmp?  Is your /tmp on a different filesystem (i.e., tmpfs)?

> Do you have deb that I can check?

Nope, I'm using 1.21.1-5 from buster.

Ross

Bug#922669: sqlalchemy: CVE-2019-7164 CVE-2019-7548 (SQL injection)

[Ross Vandegrift]

On Mon, May 06, 2019 at 10:20:25AM +0200, Thomas Goirand wrote:
> On 5/6/19 5:09 AM, Ross Vandegrift wrote:
> > Source: sqlalchemy
> > Version: 1.2.18+ds1
> > Followup-For: Bug #922669
> > 
> > I've confirmed that 1.2.18+ds1 is affected despite the description at [1].
> > Upstream has a patch for the 1.2 series at [2].
> > 
> > A debdiff including the patch is attached.  It builds and the tests pass.
> > However, the fix requires removing previously supported behavior.  Consumers
> > that depend on this have been found [3], so I'm not sure if this should be
> > shipped in buster.
> 
> Hi,
> 
> I'm sorry, but where exactly do you see a list of affected consumers?

I didn't find a list, I just wanted to note that upstream observed at
least one example (the bug report I linked as #3) of a user that was
broken by the required API change.

I don't know how concerned Debian should be about possible breakage.  I
don't use sqlalchemy much anymore, and never used the affected APIs.

Ross

Bug#922669: sqlalchemy: CVE-2019-7164 CVE-2019-7548 (SQL injection)

[Ross Vandegrift]

Source: sqlalchemy
Version: 1.2.18+ds1
Followup-For: Bug #922669

I've confirmed that 1.2.18+ds1 is affected despite the description at [1].
Upstream has a patch for the 1.2 series at [2].

A debdiff including the patch is attached.  It builds and the tests pass.
However, the fix requires removing previously supported behavior.  Consumers
that depend on this have been found [3], so I'm not sure if this should be
shipped in buster.

Ross

[1] https://github.com/sqlalchemy/sqlalchemy/issues/4481#issue-405370167
[2] https://gerrit.sqlalchemy.org/#/c/sqlalchemy/sqlalchemy/+/1184/
[3] https://github.com/sqlalchemy/sqlalchemy/issues/4538
diff -Nru sqlalchemy-1.2.18+ds1/debian/changelog 
sqlalchemy-1.2.18+ds1/debian/changelog
--- sqlalchemy-1.2.18+ds1/debian/changelog  2019-02-24 15:01:50.0 
-0800
+++ sqlalchemy-1.2.18+ds1/debian/changelog  2019-05-05 19:46:35.0 
-0700
@@ -1,3 +1,10 @@
+sqlalchemy (1.2.18+ds1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream patch for CVE-2019-7164, CVE-2019-7548 
+
+ -- Ross Vandegrift   Sun, 05 May 2019 19:46:35 -0700
+
 sqlalchemy (1.2.18+ds1-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru sqlalchemy-1.2.18+ds1/debian/patches/0002-dla-1718-1.patch 
sqlalchemy-1.2.18+ds1/debian/patches/0002-dla-1718-1.patch
--- sqlalchemy-1.2.18+ds1/debian/patches/0002-dla-1718-1.patch  1969-12-31 
16:00:00.0 -0800
+++ sqlalchemy-1.2.18+ds1/debian/patches/0002-dla-1718-1.patch  2019-05-05 
19:45:46.0 -0700
@@ -0,0 +1,332 @@
+From 82b4dcdeb0505f2dfcece5f76045b28b0edda03d Mon Sep 17 00:00:00 2001
+From: Mike Bayer 
+Date: Mon, 08 Apr 2019 22:07:35 -0400
+Subject: [PATCH] Illustrate fix for #4481 in terms of a 1.2 patch
+
+Release 1.2 has decided (so far) not to backport 1.3's fix for #4481 as it is
+backwards-incompatible with code that relied upon the feature of automatic text
+coercion in SQL statements.  However, for the specific case of order_by() and
+group_by(), we present a patch that backports the specific change in compiler
+to have 1.3's behavior for order_by/group_by specifically.   This is much more
+targeted than the 0.9 version of the patch as it takes advantage 1.0's
+architecture which runs all order_by() / group_by() through a label lookup that
+only warns if the label can't be matched.
+
+For an example of an application that was actually impacted by 1.3's change
+and how they had to change it, see:
+
+https://github.com/ctxis/CAPE/commit/be0482294f5eb30026fe97a967ee5a768d032278
+
+Basically, in the uncommon case an application is actually using the text
+coercion feature which was generally little-known, within the order_by()
+and group_by() an error is now raised instead of a warning; the application
+must instead ensure the SQL fragment is passed within a text() construct.
+The above application has also been seeing a warning about this since 1.0
+which apparently remained unattended.
+
+The patch includes adjustments to the tests that were testing for the
+warning to now test that an exception is raised. Any distro that wants
+to patch the specific CVE issue resolved in #4481 to SQLAlchemy 1.0, 1.1
+or 1.2 can use this patch.
+
+Change-Id: I3363b21428f1ad8797394b63197375a2e56a0bd7
+References: #4481
+---
+
+diff --git a/lib/sqlalchemy/sql/compiler.py b/lib/sqlalchemy/sql/compiler.py
+index 5a11ed1..4780bab 100644
+--- a/lib/sqlalchemy/sql/compiler.py
 b/lib/sqlalchemy/sql/compiler.py
+@@ -757,12 +757,11 @@
+ else:
+ col = with_cols[element.element]
+ except KeyError:
+-# treat it like text()
+-util.warn_limited(
+-"Can't resolve label reference %r; converting to text()",
+-util.ellipses_string(element.element),
++elements._no_text_coercion(
++element.element,
++exc.CompileError,
++"Can't resolve label reference for ORDER BY / GROUP BY.",
+ )
+-return self.process(element._text_clause)
+ else:
+ kwargs["render_label_as_label"] = col
+ return self.process(
+diff --git a/lib/sqlalchemy/sql/elements.py b/lib/sqlalchemy/sql/elements.py
+index 299fcad..ff86deb 100644
+--- a/lib/sqlalchemy/sql/elements.py
 b/lib/sqlalchemy/sql/elements.py
+@@ -4432,6 +4432,17 @@
+ )
+ 
+ 
++def _no_text_coercion(element, exc_cls=exc.ArgumentError, extra=None):
++raise exc_cls(
++"%(extra)sTextual SQL expression %(expr)r should be "
++"explicitly declared as text(%(expr)r)"
++% {
++"expr": util.ellipses_string(element),
++"extra": "%s " % extra if extra else "",
++}
++)
++
++
+ def _no_literals(element):
+ if hasattr(element, "__clause_element__"):
+ return element.__clause_element__()
+diff --git a/test/orm/test_e

Bug#927993: xinit: Cannot load NVIDIA drivers, doesn't connect to X server. No screens found.

[Ross Vandegrift]

Control: -1 tags moreinfo

Hi Sebastian, 

Could you send the output of: dpkg -l '*nouveau*'?  Probably the X server
output would also be useful.  That should be the output of xinit/startx if you
use it directly, otherwise check ~/.local/xorg/ or /var/log/.

Ross

Bug#927835: enlightenment: icon theme efreet cache is not updated on startup

[Ross Vandegrift]

Control: Tags -1 unreproducible

On Wed, Apr 24, 2019 at 05:43:40AM +0300, sergio wrote:
> The real setup is:
> 
> % readlink .cache
> /tmp/sergio_cache
> 
> +
> 
> mkdir $(readlink ~/.cache)
> in .xsession
> 
> 
> And I have the issue every reboot, so I'm absolutely sure efreetd is
> restarted.
> 
> 
> Really I was wrong a bit: the cache (and
> .cache/efreet/icons_Adwaita_transient.eet exactly) is recreated, but
> pavucontrol has no icon untill I choose the theme again.

With a fresh efreetd, I cannot reproduce this issue.

1) Application Theme -> Icons, choose Adwaita icon theme.
2) rm ~/.cache/efreet/icons_Adwaita_*
3) log out and back in
4) check pavucontrol icon in everything & menus

Ross

Bug#927835: enlightenment: icon theme efreet cache is not updated on startup

[Ross Vandegrift]

Control: reassign -1 libefreet-bin

On Wed, Apr 24, 2019 at 01:08:58AM +0300, sergio wrote:
> Some apps require the theme to be selected in Settings Panel -> Look ->
> Application Theme -> Icons. Pavucontrol for example. Same time I choose
> Adwaita as icon theme I see icon for pavucontrol in menu. And all works
> fine until I remove ~/.cache/efreet (exactly
> icons_Adwaita_transient.eet). Really all cache will be rebuilt at
> startup time, except icons_Adwaita_transient.eet so I will see no
> pavucontrol icon and will need to choose Adwaita to rebuild the cache.

The cache is managed by a background process, efreetd - not enlightenment.  I
can reproduce, but only if I keep the same efreetd running.

After removing the cache, try logging out of your session and waiting ~10-15s.
That will let efreetd exit.  When you login again, the cache should be
regenerated when a new efreetd is spawned.

Ross

Bug#923889: google-compute-image-packages - DoS via serial console write

[Ross Vandegrift]

On Fri, Mar 08, 2019 at 10:59:33AM +0100, Bastian Blank wrote:
> In normal operation, the rate limit of journald might make sure it does
> not come to really blocking.

Ahh, that would do it, thanks.

> What happens for use cases where you need to disable this rate limit?
> Mail servers which Postfix, which exclusively uses syslog that is
> redirected to the journal, need this, or they will loose logs.
> 
> On Azure we tried the same for a short time period.  It got quiet messy
> and also triggered bugs in the platform.

For sure - I wasn't defending the change, just surprised when I couldn't
reproduce the problem.

> I assume the initial goal was to get the log output of the provisioning
> daemons on the serial console.  This goal was also mentioned in the
> formerly shipped rsyslog config snippet.
>
> Forwarding all log traffic there completely destroys that ability, as it
> will be drowned by irrelevant log traffic.  Also the log buffer is
> limited in size.

Yep, agreed.

Ross

Bug#923889: google-compute-image-packages - DoS via serial console write

[Ross Vandegrift]

On Wed, Mar 06, 2019 at 07:49:38PM +0100, Bastian Blank wrote:
> This package instructs journald to duplicate everything sent to the
> journal to the serial console.  The serial console is a pretty rate
> limited log output device and blocking there will make all software with
> any log output block.

This doesn't seem to affect all software - I tried to reproduce with
logger, but it doesn't block.  Maybe this only affects some logging
transports?

I agree it's a problematic default - GCE serial console data is
currently stored unencrypted.  That could be an unpleasent surprise.

Ross

Bug#921068: enlightenment: Crashes when failing to load ALSA on start up.

[Ross Vandegrift]

Control: forwarded -1 https://phab.enlightenment.org/T7680

On Sat, Feb 02, 2019 at 07:34:13PM -0800, Ross Vandegrift wrote:
> On Fri, Feb 01, 2019 at 09:59:46AM +0100, Nicolas Cavallari wrote:
> > (The original ALSA problem is that the documented way to disable
> >  redirecting ALSA applications to pulseaudio was to divert
> >  /usr/share/alsa/alsa.conf.d/pulse.conf away)
> 
> There is a recent patch in upstream git that sounds like it could be related
> (a841544d0).  I hope to have some time to test tomorrow.

After a second a look, this patch won't help.

The problem is that your dpkg-divert leaves alsa with an invalid config:
$ amixer info
ALSA lib conf.c:3639:(config_file_open) cannot access file 
/etc/alsa/conf.d/99-pulse.conf
ALSA lib conf.c:3559:(snd_config_hooks_call) function snd_config_hook_load 
returned error: No such file or directory
ALSA lib conf.c:4013:(snd_config_update_r) hooks failed, removing configuration
amixer: Control device default open error: No such file or directory

According to #915696, configs in /usr/share/alsa/alsa.conf.d are no longer
automatically loaded.  So now you want to remove your diversion and delete the
symlink in /etc instead.

Still, mixer should handle cases when its backend fails to initialize.

Ross

Bug#921068: enlightenment: Crashes when failing to load ALSA on start up.

[Ross Vandegrift]

On Fri, Feb 01, 2019 at 09:59:46AM +0100, Nicolas Cavallari wrote:
> A recent pulseaudio upgrade broke the ALSA configuration.  Since this
> machine seldom needs to play sounds, this is a minor problem.
> 
> However, as a result, Enlightenment SEGVs on load.  Trying to restart
> it with F1 does not work, unless the ALSA configuration is fixed:

Thanks for the report, I can reproduce.  I don't see anything related to the
mixer in your backtrace, but it shows up in mine (attached).

> (The original ALSA problem is that the documented way to disable
>  redirecting ALSA applications to pulseaudio was to divert
>  /usr/share/alsa/alsa.conf.d/pulse.conf away)

There is a recent patch in upstream git that sounds like it could be related
(a841544d0).  I hope to have some time to test tomorrow.

Ross

Thread 6 (Thread 0x7f03b957d700 (LWP 9067)):
#0  0x7f03c5e3c357 in __GI___select (nfds=45, 
readfds=readfds@entry=0x7f03b957c730, writefds=writefds@entry=0x7f03b957c7b0, 
exceptfds=exceptfds@entry=0x7f03b957c830, timeout=timeout@entry=0x7f03b957c710) 
at ../sysdeps/unix/sysv/linux/select.c:41
resultvar = 18446744073709551102
sc_cancel_oldtype = 1
sc_ret = 
#1  0x7f03c5f50466 in _drm_tick_core (data=, 
thread=0x55d33c9d5830) at lib/ecore_x/ecore_x_vsync.c:358
wfds = {fds_bits = {0 }}
ret = 
tv = {tv_sec = 0, tv_usec = 87258}
rfds = {fds_bits = {17592186044416, 0 }}
exfds = {fds_bits = {0 }}
max_fd = 
msg = 
ref = 0x55d33d07b3c0
tick = 1
__FUNCTION__ = 
#2  0x7f03c68b9e5c in _ecore_direct_worker (work=0x55d33c9d5830) at 
lib/ecore/ecore_thread.c:484
__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = 
{94365743405104, -2636936008978456277, 140720380279134, 140720380279135, 
94365743404976, 0, -2637060908116401877, -2636936008885001941}, 
__mask_was_saved = 0}}, __pad = {0x7f03b957ca30, 0x0, 0x7f03c6960d44 
<_eina_debug_thread_add+164>, 0x0}}
__cancel_routine = 0x7f03c68ba0e0 <_ecore_direct_worker_cleanup>
__cancel_arg = 0x55d33c9d5830
__not_first_call = 
#3  0x7f03c698f0e0 in _eina_internal_call (context=0x55d33c9d57b0) at 
lib/eina/eina_thread.c:151
__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {0, 
2693211662942937387, 140720380279134, 140720380279135, 139653971171072, 0, 
-2637060908101721813, -2636936140606463701}, __mask_was_saved = 0}}, __pad = 
{0x7f03b957c9c0, 0x0, 0x0, 0x0}}
__cancel_routine = 
__cancel_arg = 
__not_first_call = 
__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {0, 
2693211662942937387, 140720380279134, 140720380279135, 139653971171072, 0, 
-2637060908101721813, -2636936140634513109}, __mask_was_saved = 0}}, __pad = 
{0x7f03b957cad0, 0x0, 0x0, 0x0}}
__cancel_routine = 
__cancel_arg = 0x55d33c9d57b0
__not_first_call = 
c = 0x55d33c9d57b0
r = 
self = 139653971171072
#4  0x7f03c692bfa3 in start_thread (arg=) at 
pthread_create.c:486
ret = 
pd = 
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139653971171072, 
2693211662942937387, 140720380279134, 140720380279135, 139653971171072, 0, 
-2637060908007349973, -2636936087314554581}, mask_was_saved = 0}}, priv = {pad 
= {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 
#5  0x7f03c5e447ef in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.

Thread 5 (Thread 0x7f03b9d7e700 (LWP 9066)):
#0  futex_wait_cancelable (private=0, expected=0, futex_word=0x55d33c8f171c) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
__ret = -512
oldtype = 0
err = 
oldtype = 
err = 
__ret = 
resultvar = 
__arg4 = 
__arg3 = 
__arg2 = 
__arg1 = 
_a4 = 
_a3 = 
_a2 = 
_a1 = 
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x55d33c8f16c8, 
cond=0x55d33c8f16f0) at pthread_cond_wait.c:502
spin = 0
buffer = {__routine = 0x7f03c6931d20 <__condvar_cleanup_waiting>, __arg 
= 0x7f03b9d7d940, __canceltype = 1026572816, __prev = 0x0}
cbuffer = {wseq = 7, cond = 0x55d33c8f16f0, mutex = 0x55d33c8f16c8, 
private = 0}
rt = 
err = 
g = 1
flags = 
g1_start = 
signals = 
result = 0
wseq = 7
seq = 3
private = 0
maxspin = 
err = 
result = 
wseq = 
g = 
seq = 
flags = 
private = 
signals = 
g1_start = 
spin = 
buffer = 
cbuffer = 
rt = 
s = 
#2  __pthread_cond_wait (cond=0x55d33c8f16f0, mutex=0x55d33c8f16c8) at 
pthread_cond_wait.c:655
No locals.
#3  0x7f03ba339a32 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
No symbol table info available.
#4  0x7f03ba3395f7 in ?? () from 

Bug#917126: Bug#874003: Nautilus does not launch applications

[Ross Vandegrift]

On Mon, Dec 24, 2018 at 12:18:15PM +, Simon McVittie wrote:
> On Sat, 22 Dec 2018 at 20:06:26 -0800, Ross Vandegrift wrote:
> > Untested patch attached.  I'm travelling the next week and may not have 
> > time to
> > test/package until January.
> 
> I don't use enlightenment myself, but the patch looks like what I had
> in mind.

Patch is tested, works as expected.  I've let upstream know and will prepare an
upload.

> > I don't know the fdo specs well, but this behavior of x-scheme-handler/file
> > seems like a pretty bad misfeature to me.  Does it exist only for the gdm3
> > use-case?
> 
> x-scheme-handler/file isn't really a feature at all, more a consequence
> of a more general feature that *is* useful.

Thanks for the explanation Simon, very helpful.

Ross

Bug#917126: Bug#874003: Nautilus does not launch applications

[Ross Vandegrift]

Control: forwarded -1 https://phab.enlightenment.org/T7521
Control: tags -1 patch

On Sat, Dec 22, 2018 at 11:41:20PM +, Simon McVittie wrote:
> While researching this in codesearch.debian.net I found that e17
> (Enlightenment) still sets the user-preferred file manager by setting
> it as an x-scheme-handler/file handler. e17 maintainers, please
> don't do this: the interoperable freedesktop.org pseudo-MIME-type
> for a general-purpose file manager like Nautilus, Thunar, Dolphin
> or (presumably) enlightenment_filemanager is inode/directory, and
> enlightenment_filemanager's desktop file already announces it as an
> inode/directory handler.

Untested patch attached.  I'm travelling the next week and may not have time to
test/package until January.

> In principle GLib could special-case x-scheme-handler/file to be ignored,
> but I don't think that's a good idea, because it would be a special case
> for something that should never happen in normal desktop sessions anyway,
> and it would mean that the locked-down gdm3 session would have no general
> way to prevent files from being opened.

I don't know the fdo specs well, but this behavior of x-scheme-handler/file
seems like a pretty bad misfeature to me.  Does it exist only for the gdm3
use-case?

Ross
--- a/src/bin/e_open.c
+++ b/src/bin/e_open.c
@@ -438,7 +438,7 @@
/* {"browser", "x-scheme-handler/http"}, */
{"mail", "x-scheme-handler/mailto"},
/*  {"terminal", NULL}, */
-   {"filemanager", "x-scheme-handler/file"},
+   {"filemanager", "inode/directory"},
{"image", "image/jpeg"},
{"video", "video/x-mpeg"},
{"music", "audio/mp3"},
--- a/src/modules/conf_applications/e_int_config_defapps.c
+++ b/src/modules/conf_applications/e_int_config_defapps.c
@@ -131,7 +131,7 @@
 if (s) cfdata->browser_desktop = eina_stringshare_add(s);
 s = efreet_ini_string_get(myini, "x-scheme-handler/mailto");
 if (s) cfdata->mailto_desktop = eina_stringshare_add(s);
-s = efreet_ini_string_get(myini, "x-scheme-handler/file");
+s = efreet_ini_string_get(myini, "inode/directory");
 if (s) cfdata->file_desktop = eina_stringshare_add(s);
 s = efreet_ini_string_get(myini, "x-scheme-handler/trash");
 if (s) cfdata->trash_desktop = eina_stringshare_add(s);
@@ -385,7 +385,7 @@
   efreet_ini_string_set(cfdata->ini, "x-scheme-handler/mailto",
 cfdata->mailto_desktop);
 if ((cfdata->file_desktop) && (cfdata->file_desktop[0]))
-  efreet_ini_string_set(cfdata->ini, "x-scheme-handler/file",
+  efreet_ini_string_set(cfdata->ini, "inode/directory",
 cfdata->file_desktop);
 if ((cfdata->trash_desktop) && (cfdata->trash_desktop[0]))
   efreet_ini_string_set(cfdata->ini, "x-scheme-handler/trash",

Bug#916630: terminology: Remote execution via special escape codes that handle unknown media types

[Ross Vandegrift]

Package: terminology
Version: 1.3.0-1
Severity: grave
Tags: security upstream
Justification: user security hole
Owner: r...@kallisti.us
Forwarded: https://phab.enlightenment.org/T7504

Terminology 1.3.1 has been released to fix a remote code execution
vulnerability in special escape handling.  This can be mitigated by unchecking
Settings -> Enable special Terminology escape codes.  I'm preparing a release.


Details from upstream bug report:
The \e}pn sequence allows a user to display media like an image or open a
web page. However, all unknown media types are handled with the
media_unknown_handle function which executes xdg-open against the file type.
This creates a large attack surface that allows a remotely introduced
executable file to be executed when that file's MIME type is registered for
xdg-open.

See the linked bug for full info.

Ross

Bug#908843: terminology: Please add support for WINDOWID environment variable

[Ross Vandegrift]

Control: forwarded -1 https://phab.enlightenment.org/T7484

On Sat, Sep 15, 2018 at 12:30:09AM +0200, Sebastian Reichel wrote:
> Package: terminology
> Version: 1.2.1-1
> Severity: wishlist
> Tags: upstream
> 
> Hi,
> 
> Please add support for setting the WINDOWID environment variable,
> which is done for example by Xterm and most libvte terminal emulators.
> It's a very useful feature to automatically set a nice icon with
> xseticon based on the running application.
> 
> -- Sebastian
> 
> 

Bug#912471: xpra: missing dependency on python-paramiko

[Ross Vandegrift]

Package: xpra
Version: 2.4+dfsg1-1
Severity: normal

xpra is unable to attach to an ssh session since paramiko is missing:

$ xpra attach ssh:vanvanmojo.local:23
2018-10-31 14:02:34,160 Xpra gtk2 client version 2.4-r20681M 64-bit
2018-10-31 14:02:34,161  running on Linux Debian testing buster
2018-10-31 14:02:34,162  window manager is 'Enlightenment'
2018-10-31 14:02:34,184 Warning: failed to import opencv:
2018-10-31 14:02:34,184  No module named cv2
2018-10-31 14:02:34,184  webcam forwarding is disabled
2018-10-31 14:02:35,207 GStreamer version 1.14.4 for Python 2.7.15 64-bit
2018-10-31 14:02:35,290 No OpenGL_accelerate module loaded: No module named 
OpenGL_accelerate
2018-10-31 14:02:35,454 OpenGL enabled with Mesa DRI Intel(R) HD Graphics 530 
(Skylake GT2)
2018-10-31 14:02:35,490 Xpra client failed to connect
2018-10-31 14:02:35,490 connection failed: No module named paramiko
2018-10-31 14:02:35,491 Error: printing disabled:
2018-10-31 14:02:35,491  No module named cups
xpra initialization error:
 connection failed: No module named paramiko

Once I do 'apt install python-paramiko', all is good again.

Thanks,
Ross

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

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

Versions of packages xpra depends on:
ii  adduser   3.118
ii  init-system-helpers   1.55
ii  libavcodec58  7:4.0.2-2+b2
ii  libavformat58 7:4.0.2-2+b2
ii  libavutil56   7:4.0.2-2+b2
ii  libc6 2.27-6
ii  libglib2.0-0  2.58.1-2
ii  libgtk2.0-0   2.24.32-3
ii  libpam0g  1.1.8-3.8
ii  libswscale5   7:4.0.2-2+b2
ii  libsystemd0   239-11
ii  libturbojpeg0 1:1.5.2-2+b1
ii  libvpx5   1.7.0-3
ii  libwebp6  0.6.1-2
ii  libx11-6  2:1.6.7-1
ii  libx264-155   2:0.155.2917+git0a84d98-2
ii  libx265-165   2.9-3
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxi62:1.7.9-1
ii  libxkbfile1   1:1.0.9-2
ii  libxrandr22:1.5.1-1
ii  libxtst6  2:1.2.3-1
ii  python2.7.15-3
ii  python-gi-cairo   3.30.1-2
ii  python-gtk2   2.24.0-5.1+b1
ii  python-rencode1.0.5-1+b2
ii  x11-xserver-utils 7.7+8
ii  xserver-xorg-input-void   1:1.4.1-1+b2
ii  xserver-xorg-video-dummy  1:0.3.8-1+b1

Versions of packages xpra recommends:
ii  keyboard-configuration  1.186
ii  openssh-client  1:7.9p1-1
ii  python-dbus 1.2.8-2+b1
ii  python-gtkglext11.1.0-9.1
ii  python-imaging  4.3.0-2
ii  python-lz4  1.1.0+dfsg-1
ii  python-lzo  1.12-2
ii  python-pil  5.3.0-1
ii  python-uritools 2.1.0-1
ii  ssh-askpass 1:1.2.4.1-10

Versions of packages xpra suggests:
ii  cups-client2.2.8-5
ii  cups-common2.2.8-5
ii  cups-filters   1.21.3-2
pn  cups-pdf   
ii  gstreamer1.0-plugins-bad   1.14.4-1+b1
ii  gstreamer1.0-plugins-base  1.14.4-1
ii  gstreamer1.0-plugins-good  1.14.4-1
ii  gstreamer1.0-plugins-ugly  1.14.4-1
ii  openssh-server 1:7.9p1-1
ii  pulseaudio 12.2-2
ii  pulseaudio-utils   12.2-2
pn  python-avahi   
pn  python-cups
pn  python-gst-1.0 
pn  python-netifaces   
pn  python-opencv  
pn  python-pyopencl
pn  python-uinput  
pn  python-yaml
pn  v4l2loopback-dkms  

-- no debconf information

Bug#912356: terminology: Pasting from menu blocks terminal

[Ross Vandegrift]

Control: forwarded -1 https://phab.enlightenment.org/T7446
Control: tags -1 upstream

On Tue, Oct 30, 2018 at 05:55:24PM +0100, xiscu wrote:
> copy a string (e.g. some path), then paste it on the terminal
> over the context menu (usually mouse-right-click). Afterwards, 
> the terminal doesn't seem to be responsive anymore (e.g. unable
> to move the cursor, or 'return' the command).
> 
> The terminal gets reponsible again if one opens a new terminal
> with the context menu (and then closes it) or if the context menu
> is just opened again and then scaped by clicking on the terminal.

Easily reproducible, thanks for the report - I've forwarded it upstream.

Ross

Bug#910753: apt: Race condition between apt's systemd timers & cloud-init

[Ross Vandegrift]

On Wed, Oct 10, 2018 at 11:24:16PM +0200, Julian Andres Klode wrote:
> > Would you be open to adding cloud-init.target to the After list on
> > apt-daily.timer? 
> 
> No. cloud-init injects itself into the boot to try to run as early
> as possible. It must ensure it works properly itself, and probably
> wants to run Before=timers.target.

That's fair - I'll test this, thanks for the alternative idea!

Thanks,
Ross

Bug#910753: apt: Race condition between apt's systemd timers & cloud-init

[Ross Vandegrift]

Package: apt
Version: 1.7.0
Severity: normal

Hello,

When a cloud VM is booted with systemd, the timers for apt's periodic actions
are launched in parallel with cloud-init.  cloud-init does some initial
setup, but it also allows end users to customize the system by e.g.,
installing packages with apt.

Depending on timing, apt-daily can go first and lock the db.  If the update
takes a while, then the db will still be locked when cloud-init tries to
apply the user's customizations.  Since this can happen on the first boot,
there's no clean way for an end-user to ensure that their packages will
install.  There's a useful ubuntu-focused discussion of this at [1].

Would you be open to adding cloud-init.target to the After list on
apt-daily.timer?  If I've understood the issue correctly, this should be
sufficient.  If units can use Before to delay timer triggers, this could be
done on the cloud-init side.  But I've been unable to confirm what systemd
does with that config.

Thanks,
Ross

[1] - 
https://unix.stackexchange.com/questions/315502/how-to-disable-apt-daily-service-on-ubuntu-cloud-vm-image


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

Kernel: Linux 4.18.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 apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2017.7
ii  gpgv2.2.10-2
ii  libapt-pkg5.0   1.7.0
ii  libc6   2.27-6
ii  libgcc1 1:8.2.0-7
ii  libgnutls30 3.5.19-1
ii  libseccomp2 2.3.3-3
ii  libstdc++6  8.2.0-7

Versions of packages apt recommends:
ii  ca-certificates  20170717

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.11-3
ii  dpkg-dev1.19.0.5
ii  gnupg   2.2.10-2
ii  gnupg2  2.2.10-2
ii  powermgmt-base  1.33
ii  synaptic0.84.3

-- no debconf information

Bug#891392: Successfully compiled ad

[Ross Vandegrift]

On Thu, Sep 13, 2018 at 12:51:53AM +0300, sergio wrote:
> I've just successfully compiled (and started) 0.22.3-2 with the patch above.
> 
> It works, but not suitable for daily usage (no screen rotation, multiple
> glitches and artefacts, slow response for some apps)

Thanks for testing and reporting back!  I haven't picked this up in a
while, glad to hear you had success.

> > it broke X11 support for my own setup.
> 
> But it doesn't break X11 support for me

Even better news.  If X11 doesn't break, then we can think about
releasing with Wayland enabled.  I'll try to take a look again this
weekend.

Ross

Bug#907368: thunderbolt-tools: Please publish Debian packaging git

[Ross Vandegrift]

Package: thunderbolt-tools
Version: 0.9.3-3
Severity: normal

thunderbolt-tools has a gbp.conf, but I can't find the proper git repo on the
internet.  d/control doesn't have Vcs-Git.  Homepage points to upstream's git,
but that doesn't have the debian branch.

Thanks,
Ross

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

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

Versions of packages thunderbolt-tools depends on:
ii  libboost-filesystem1.62.0  1.62.0+dfsg-8
ii  libboost-system1.62.0  1.62.0+dfsg-8
ii  libc6  2.27-5
ii  libgcc11:8.2.0-3
ii  libstdc++6 8.2.0-3

thunderbolt-tools recommends no packages.

thunderbolt-tools suggests no packages.

-- no debconf information

Bug#907367: thunderbolt-tools: Add thunderbolt support to initramfs

[Ross Vandegrift]

Package: thunderbolt-tools
Version: 0.9.3-3
Severity: wishlist
Tags: patch

Hello,

This patch adds thunderbolt support to initramfs.  It is enabled by installing
a new package: thunderbolt-tools-initramfs.  This allows me to enter my
cryptsetup password with a keyboard plugged into a tb3 dock.

Thanks,
Ross

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

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

Versions of packages thunderbolt-tools depends on:
ii  libboost-filesystem1.62.0  1.62.0+dfsg-8
ii  libboost-system1.62.0  1.62.0+dfsg-8
ii  libc6  2.27-5
ii  libgcc11:8.2.0-3
ii  libstdc++6 8.2.0-3

thunderbolt-tools recommends no packages.

thunderbolt-tools suggests no packages.

-- no debconf information
>From 57fc7029b73ee1eef8a4c0dc87732da1f0f08657 Mon Sep 17 00:00:00 2001
From: Ross Vandegrift 
Date: Sun, 26 Aug 2018 18:01:06 -0700
Subject: [PATCH] Add support for activating thunderbolt in initramfs

---
 debian/README.Debian  | 13 
 debian/changelog  |  7 
 debian/control| 11 +++
 debian/copyright  |  6 
 debian/initramfs/hooks/thunderbolt-tools  | 33 +++
 debian/thunderbolt-tools-initramfs.install|  2 ++
 debian/{install => thunderbolt-tools.install} |  0
 7 files changed, 72 insertions(+)
 create mode 100644 debian/README.Debian
 create mode 100755 debian/initramfs/hooks/thunderbolt-tools
 create mode 100644 debian/thunderbolt-tools-initramfs.install
 rename debian/{install => thunderbolt-tools.install} (100%)

diff --git a/debian/README.Debian b/debian/README.Debian
new file mode 100644
index 000..4d8d9ab
--- /dev/null
+++ b/debian/README.Debian
@@ -0,0 +1,13 @@
+thunderbolt-tools initramfs support
+---
+
+thunderbolt-tools-initramfs provides scripts to built thunderbolt
+support into an initramfs.  Support is enabled by default.  It can be
+disabled /etc/initramfs/conf.d/thunderbolt-tools with THUNDERBOLT=n.
+
+This supports secure-mode thunderbolt and ACLs by using the tbtacl
+data.  All devices you wish to use at boot must have been authorized
+already: new devices can't be authorized in the initramfs.  Re-run
+update-initramfs after changing authorized devices.
+
+ -- Ross Vandegrift , Sun, 26 Aug 2018 17:59:55 -0700
diff --git a/debian/changelog b/debian/changelog
index b7174bf..5970a3f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+thunderbolt-tools (0.9.3-4) unstable; urgency=medium
+
+  * thunderbolt-tools-initramfs: Add support for udev thunderbolt
+activation in initramfs.  See README.Debian for details.
+
+ -- Ross Vandegrift   Sun, 26 Aug 2018 17:58:27 -0700
+
 thunderbolt-tools (0.9.3-3) unstable; urgency=medium
 
   * Remove redundant copy of udev rules (LP: #1762187)
diff --git a/debian/control b/debian/control
index b3ad7ca..9161d78 100644
--- a/debian/control
+++ b/debian/control
@@ -20,3 +20,14 @@ Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Intel Thunderbolt userspace components
  Provides components for using Intel Thunderbolt controllers with
  security level features
+
+Package: thunderbolt-tools-initramfs
+Architecture: all
+Depends: ${misc:Depends},
+initramfs-tools (>= 0.129) | linux-initramfs-tool,
+thunderbolt-tools
+Description: Intel Thunderbolt userspace components - initramfs integration
+ Provides components for using Intel Thunderbolt controllers with
+ security level features
+ .
+ This package provides initramfs integration for thunderbolt-tools.
diff --git a/debian/copyright b/debian/copyright
index 6224da8..8353d0d 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -29,8 +29,14 @@ License: BSD-3-clause
  OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
+Files: debian/initramfs/*
+Copyright: 2018 Ross Vandegrift 
+License: GPL-2+
+
 Files: debian/*
 Copyright: 2016 Mario Limonciello 
+License: GPL-2+
+
 License: GPL-2+
  This package is free software; you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
diff --git a/debian/initramfs/hooks/thunderbolt-tools 
b/debian/initramfs/hooks/thunderbolt-tools
new file mode 100755
index 000..02354e8
--- /dev/null
+++ b/debian/initramfs/hooks/thunderbolt-tools
@@ -0,0 +1,33 @@
+#!/bin/sh
+
+PREREQ=""
+
+prereqs()
+{
+echo "$PREREQ"
+}
+
+case "$1" in
+ 

Bug#904045: enlightenment: no background image tiling

[Ross Vandegrift]

On Wed, Aug 15, 2018 at 11:41:17PM +0200, enno wrote:
> Using the `Settings Panel' not on the first (left) item `Wallpaper' but the
> third one `Screen', there the first (top) item `Virtual Desktops', up comes a
> new menu displaying the `Virtual Desktop Settings' in _pictures_, there I can
> click on each VD in turn and up comes a new menu `Desk Settings', there click
> `X Set'--and off we go to where I want.  Excellent.

Wow I didn't even know about that.  Glad you found a workaround.

> But if I use the `Settings Panel', there the first (left) item `Look', there
> the first (top) item `Wallpaper', up comes new menu `Wallpaper Settings',
> there choose the Picture by whichever possible way, click `> Advanced', there
> select `This screen', then `Apply' or `OK'--all my (ahem) `Virtual Desktops'
> get the same tiled background.

"Screen" in that dialog refers to the X screen, meaning that particular monitor
regardless of which virtual desktop is selected.  I misunderstood your previous
message and told you how to set different desktops on different monitors.

But "This Desktop" should do the trick in that dialog.

> Thanks for your time, can close this bug unless somebody wants to do some
> information presentation regarding the different terms `Virtual Desktop',
> `Screen' and their respective addressing via the Settings Panel of e17.

No problem, hope this helps.

Ross

Bug#904045: enlightenment: no background image tiling

[Ross Vandegrift]

On Mon, Aug 06, 2018 at 11:45:41PM +0200, enno wrote:
> Thanks very much appreciate your time, tiling bg images works when I
> follow your advice, but all my screens get the same background, no
> matter if I check "only this desktop" or "only this screen".

Hmmm, I just tested with enlightenment 0.22.3-2 and this works for me:

- Import two images as tiled wallpaper
- Click Advanced in the Wallpaper Settings dialog
- Select the first wallpaper
- Select the "This Screen" option
- Click Apply
- Move the window to the other screen
- Select the second wallpaper
- Click Apply

Ross

Bug#904045: enlightenment: no background image tiling

[Ross Vandegrift]

On Wed, Jul 18, 2018 at 10:22:52PM +0200, enno wrote:
> I like to have my custom images tiled as background.  e17 as of 0.17.6-1.1+b1
> could do it, apparently 0.22.3-2 cannot.  Or I couldn't find it in Settings.

You set this when the picture is imported.

Open Settings -> Wallpaper and click "Picture...".  Choose your image
file and Enlightenment will open a dialog that lets you control setup
the image, including tiling.

Ross

Bug#900308: xserver-xorg-input-libinput: options not applied after strech->buster upgrade

[Ross Vandegrift]

This bug is gone after an upgrade yesterday.  I'm still at 0.27.1-1, so
not sure which package ended up fixing this.  But Xorg.log now shows:

[49.791] (II) config/udev: Adding input device Lite-On Technology Corp. 
ThinkPad USB Keyboard with TrackPoint (/dev/input/mouse2)
[49.791] (**) Lite-On Technology Corp. ThinkPad USB Keyboard with 
TrackPoint: Applying InputClass "DisableTrackPointScrolling"

Ross

Bug#902667: terminology: Terminology fails to start

[Ross Vandegrift]

Control: tags -1 moreinfo
Control: severity -1 normal

On Fri, Jun 29, 2018 at 12:05:58PM +0200, Mark Dickie wrote:
> mark@plata:~$ terminology
> terminology: error while loading shared libraries: libelementary.so.1: cannot
> open shared object file: No such file or directory

Have you ever installed EFL from source?  If so, remove all remnants of it (in
particular, any .la files).

> Package libelementary1 does not contain .so
> 
> dpkg --listfiles libelementary1

The .so symlink is in libelementary-dev, libelementary.so.1 is needed at
runtime.  It's not in your dpkg output - if something failed during install,
"apt reinstall libelementary1" might help.

Ross

Bug#902239: enlightenment: source should be enlightenment not e17

[Ross Vandegrift]

Control: tags -1 wontfix
Control: severity -1 wishlist

On Sat, Jun 23, 2018 at 09:02:40PM +0300, sergio wrote:
> could you update source to "enlightenment" as e17 is outdated.

We discussed this a while back, and decided to leave it.  See:
https://alioth-lists.debian.net/pipermail/pkg-e-devel/2015-November/002442.html

Ross

Bug#901624: libecore-input1: circular dependency hell

[Ross Vandegrift]

On Thu, Jun 21, 2018 at 07:23:22PM +0200, Andreas Metzler wrote:
> have you seen, Paul Wuse's comment in 900594?
> 
> | Seems like installing all engines by default would be a better fix.
> 
> Any thoughts on that?

Yes, I like that idea.  I tested it out this evening and it's a good
improvement.  efl 1.20.7-6 is ready for upload on salsa, when you have the
chance.

Thanks,
Ross

Bug#901624: libecore-input1: circular dependency hell

[Ross Vandegrift]

On Tue, Jun 19, 2018 at 07:30:48PM +0200, Andreas Metzler wrote:
> I looked at it and did not have any alternative bright ideas. There is
> just a single manual (non-shlibs) dependency involved and it is there
> for a good reason.

I tested changing the libevas1-engines-x Depends -> Recommends, and it seems to
work well.  Both X11 and Wayland support is installed by default.

> > Maybe we drop the engine depends from libevas1, and require that EFL
> > apps include libevas1-engines-x | libevas-engines in their depends?
> 
> Adding a manual step for each app does not seem to be a good trade-off.

Yea, agreed this should be avoided.

Ross

Bug#897442: reprotest timeouts while installing the build-dependencies

[Ross Vandegrift]

Package: reprotest
Version: 0.7.7
Followup-For: Bug #897442

I ran into this tonight and tracked it down to the timeouts hardcoded in
adt_testbed.py.  A patch to allow overides from the environment is attached.

Ross

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

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

Versions of packages reprotest depends on:
ii  apt-utils  1.6.1
ii  diffoscope 96
ii  libdpkg-perl   1.19.0.5
ii  procps 2:3.3.15-2
ii  python33.6.5-3
ii  python3-debian 0.1.32
ii  python3-distro 1.0.1-2
ii  python3-pkg-resources  39.1.0-1
ii  python3-rstr   2.2.6-1

Versions of packages reprotest recommends:
ii  diffoscope   96
ii  diffutils1:3.6-1
ii  disorderfs   0.5.3-2
ii  faketime 0.9.7-2
ii  locales-all  2.27-3
ii  sudo 1.8.23-1

Versions of packages reprotest suggests:
pn  autodep8 
pn  qemu-system  
ii  qemu-utils   1:2.12+dfsg-3
ii  schroot  1.6.10-5

-- no debconf information
>From 04714ed7e82afaf4405296a01cac5bc0386df4d8 Mon Sep 17 00:00:00 2001
From: Ross Vandegrift 
Date: Tue, 19 Jun 2018 21:46:52 -0700
Subject: [PATCH] Allow user to override timeouts from the environment

---
 reprotest/lib/adt_testbed.py | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/reprotest/lib/adt_testbed.py b/reprotest/lib/adt_testbed.py
index 937b05c..1766f4a 100644
--- a/reprotest/lib/adt_testbed.py
+++ b/reprotest/lib/adt_testbed.py
@@ -47,8 +47,13 @@ SYSTEM_INTERFACES = {
 'arch': ArchInterface
 }
 
-timeouts = {'short': 100, 'copy': 300, 'install': 3000, 'test': 1,
-'build': 10}
+timeouts = {
+'short': int(os.getenv('REPROTEST_TIMEOUT_SHORT', 100)),
+'copy': int(os.getenv('REPROTEST_TIMEOUT_COPY', 300)),
+'install': int(os.getenv('REPROTEST_TIMEOUT_INSTALL', 3000)),
+'test': int(os.getenv('REPROTEST_TIMEOUT_TEST', 1)),
+'build': int(os.getenv('REPROTEST_TIMEOUT_BUILD', 10)),
+}
 
 
 class Testbed:
-- 
2.17.1

Bug#900856: enlightenment: Sound fails to work after upgrade

[Ross Vandegrift]

On Fri, Jun 15, 2018 at 12:48:51AM +0100, Mike Brodbelt wrote:
> $ cd ~ && grep autospawn .config/pulse/client.conf /etc/pulse/client.conf
> grep: .config/pulse/client.conf: No such file or directory
> /etc/pulse/client.conf:; autospawn = yes
> 
> It's possible this is a bug in pulseaudio directly, as the problem seems to
> be that the autospawn behaviour is not working correctly.

Hi Mike,

While upgrading a different machine from stretch -> buster, I noticed
the following in apt-listchanges output:

pulseaudio (11.1-2) unstable; urgency=medium

  * Since this version, pulseaudio disables autospawn by default on linux
systems, and replaces that with systemd socket activation. If you are not
using systemd, then please edit or remove
/etc/pulse/client.conf.d/00-disable-autospawn.conf
to re-enable it.

Seems relevant to your issue - the grep above didn't look in
/etc/pulse/client.conf.d.

Ross

Bug#901624: libecore-input1: circular dependency hell

[Ross Vandegrift]

On Fri, Jun 15, 2018 at 09:18:59PM +0200, Bill Allombert wrote:
> There is a circular dependency between libecore-input1, libecore-x1, libevas1 
> and libevas1-engines-x:

Dang, thanks for the heads up Bill.

Andreas - the change I proposed for the X11 engine caused this.  I don't
see any other way to:
1) ensure that *some* engine is installed when Evas is installed, and
2) prefer the X11 engine by default.

Maybe we drop the engine depends from libevas1, and require that EFL
apps include libevas1-engines-x | libevas-engines in their depends?

Ross

Bug#900856: enlightenment: Sound fails to work after upgrade

[Ross Vandegrift]

Control: reassign -1 pulseaudio

On Fri, Jun 15, 2018 at 12:48:51AM +0100, Mike Brodbelt wrote:
> > > $ start-pulseaudio-x11
> > > Connection failure: Connection refused
> > > pa_context_connect() failed: Connection refused
> > 
> > This is curious.  According to start-pulseaudio-x11(1), it should start a
> > daemon if required.
> 
> My man page also claims this. The shell script itself just runs "pactl"
> commands. As far as I can tell, this attempts to connect to a PulseAudio
> server, and fails - the startup of a daemon seems to rely on the autospawn
> functionality. The seemingly canonical docs are here:
> 
> https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Running/
> 
> are quite clear that this should autostart the server, unless "autospawn" is
> disabled, which it is not (it's in the debian default config):-
> 
> $ cd ~ && grep autospawn .config/pulse/client.conf /etc/pulse/client.conf
> grep: .config/pulse/client.conf: No such file or directory
> /etc/pulse/client.conf:; autospawn = yes
> 
> It's possible this is a bug in pulseaudio directly, as the problem seems to
> be that the autospawn behaviour is not working correctly.

Spawning manually works reliably.  In the working cases (your E17 on
buster, my E22 on buster) pulse is started outside of E.  So this seems
most likely.

Ross

Bug#900856: enlightenment: Sound fails to work after upgrade

[Ross Vandegrift]

On Tue, Jun 05, 2018 at 11:01:35PM +0100, Mike Brodbelt wrote:
> Doing some investigation into this, I enabled "PulseAudio Sound System"
> in Settings > Apps > Startup Applications. This didn't work - it seems
> to execute 'start-pulseaudio-x11' at login, which fails because it's
> executed at a point at which there is no pulseaudio daemon running:-

This shouldn't be required - my Startup Applications doesn't include pulse.
What does "systemctl --user status pulseaudio.service" report?  On my buster
laptop, it reports that the service is running and enabled.

> $ start-pulseaudio-x11
> Connection failure: Connection refused
> pa_context_connect() failed: Connection refused

This is curious.  According to start-pulseaudio-x11(1), it should start a
daemon if required.

Ross

Bug#900460: ephoto: fails to start

[Ross Vandegrift]

Control: clone -1 -2
Control: reassign -2 libevas1
Control: severity -2 normal
Control: retitle -2 libevas1: adjust Depends to prefer X11 engine
Control: block -1 by -2

On Fri, Jun 01, 2018 at 09:06:57AM +0900, Norbert Preining wrote:
> > Can you provide the output of "dpkg -l | grep libevas1-engine"?  It
> 
> ii  libevas1-engines-wayland:amd64  1.20.7-4  
>   amd64Evas module providing the Wayland 
> engine

Thanks, this confirms what I expected.  As a workaround, you can install
libevas1-engines-x and ephoto should work.

Mostly a note to self, I'm about to head on vacation for a week: the problem is
in the way libevas1 pulls in the engine backends.  libevas1 depends on
libevas1-engine, which is a virtual package.  In some cases, apt fulfills this
with the wayland engine only.  Since wayland-only is less common, that Depends
should be changed to libevas1-engines-x | libevas1-engine.

Thanks for the report and sorry for the trouble,
Ross

Bug#900460: ephoto: fails to start

[Ross Vandegrift]

Control: tags -1 moreinfo

Hello,

Can you provide the output of "dpkg -l | grep libevas1-engine"?  It
looks like ephoto can't find a working evas engine.  Probably you're
using X11 but the dependencies only installed the wayland engine, or
vice versa.

Thanks,
Ross

On Thu, May 31, 2018 at 03:43:25PM +0900, Norbert Preining wrote:
> Package: ephoto
> Version: 1.5-1
> Severity: grave
> Justification: renders package unusable
> 
> Bot invocations
>   ephoto
> or
>   ephoto foo.jpg
> end with
> 
> ERR<25953>:ecore_evas lib/elementary/efl_ui_win.c:5005 
> _elm_win_finalize_internal() Cannot create window.
> ## Copy & Paste the below (until EOF) into a terminal, then hit Enter
> 
> eina_btlog << EOF
> /usr/lib/x86_64-linux-gnu/libeina.so.1 0x7fb89cd406cc 0x7fb89cd19000
> /usr/lib/x86_64-linux-gnu/libeina.so.1 0x7fb89cd413f1 0x7fb89cd19000
> /usr/lib/x86_64-linux-gnu/libeina.so.1 0x7fb89cd427c3 0x7fb89cd19000
> /usr/lib/x86_64-linux-gnu/libelementary.so.1   0x7fb89b38956c 0x7fb89b109000
> /usr/lib/x86_64-linux-gnu/libelementary.so.1   0x7fb89b38b470 0x7fb89b109000
> /usr/lib/x86_64-linux-gnu/libeo.so.1   0x7fb89b8b630e 0x7fb89b8a6000
> /usr/lib/x86_64-linux-gnu/libeo.so.1   0x7fb89b8ae9ac 0x7fb89b8a6000
> /usr/lib/x86_64-linux-gnu/libelementary.so.1   0x7fb89b385142 0x7fb89b109000
> /usr/bin/ephoto0x55b70128b564 0x55b70126f000
> /usr/bin/ephoto0x55b701278a4f 0x55b70126f000
> /usr/bin/ephoto0x55b70127873c 0x55b70126f000
> /lib/x86_64-linux-gnu/libc.so.60x7fb898e3ba87 0x7fb898e1a000
> /usr/bin/ephoto0x55b70127877a 0x55b70126f000
> EOF
> 
> ERR<25953>:eo lib/eo/eo.c:949 _efl_add_internal_end() Object of class 
> 'Efl.Ui.Win' - Not all of the object constructors have been executed.
> ## Copy & Paste the below (until EOF) into a terminal, then hit Enter
> 
> eina_btlog << EOF
> /usr/lib/x86_64-linux-gnu/libeina.so.1 0x7fb89cd406cc 0x7fb89cd19000
> /usr/lib/x86_64-linux-gnu/libeina.so.1 0x7fb89cd413f1 0x7fb89cd19000
> /usr/lib/x86_64-linux-gnu/libeina.so.1 0x7fb89cd427c3 0x7fb89cd19000
> /usr/lib/x86_64-linux-gnu/libeo.so.1   0x7fb89b8aea8c 0x7fb89b8a6000
> /usr/lib/x86_64-linux-gnu/libelementary.so.1   0x7fb89b385142 0x7fb89b109000
> /usr/bin/ephoto0x55b70128b564 0x55b70126f000
> /usr/bin/ephoto0x55b701278a4f 0x55b70126f000
> /usr/bin/ephoto0x55b70127873c 0x55b70126f000
> /lib/x86_64-linux-gnu/libc.so.60x7fb898e3ba87 0x7fb898e1a000
> /usr/bin/ephoto0x55b70127877a 0x55b70126f000
> EOF
> 
> ERR<25953>:evas_main lib/evas/canvas/evas_object_smart.c:646 
> _efl_canvas_group_efl_object_destructor() efl_canvas_group_del() was not 
> called on this object: 0x400105da (Efl.Ui.Win)
> ## Copy & Paste the below (until EOF) into a terminal, then hit Enter
> 
> eina_btlog << EOF
> /usr/lib/x86_64-linux-gnu/libeina.so.1 0x7fb89cd406cc 0x7fb89cd19000
> /usr/lib/x86_64-linux-gnu/libeina.so.1 0x7fb89cd413f1 0x7fb89cd19000
> /usr/lib/x86_64-linux-gnu/libeina.so.1 0x7fb89cd427c3 0x7fb89cd19000
> /usr/lib/x86_64-linux-gnu/libevas.so.1 0x7fb89c71a237 0x7fb89c689000
> /usr/lib/x86_64-linux-gnu/libeo.so.1   0x7fb89b8b61ea 0x7fb89b8a6000
> /usr/lib/x86_64-linux-gnu/libeo.so.1   0x7fb89b8b61ea 0x7fb89b8a6000
> /usr/lib/x86_64-linux-gnu/libelementary.so.1   0x7fb89b36ee44 0x7fb89b109000
> /usr/lib/x86_64-linux-gnu/libeo.so.1   0x7fb89b8b61ea 0x7fb89b8a6000
> /usr/lib/x86_64-linux-gnu/libeo.so.1   0x7fb89b8b61ea 0x7fb89b8a6000
> /usr/lib/x86_64-linux-gnu/libeo.so.1   0x7fb89b8ae8a4 0x7fb89b8a6000
> /usr/lib/x86_64-linux-gnu/libeo.so.1   0x7fb89b8b5642 0x7fb89b8a6000
> /usr/lib/x86_64-linux-gnu/libeo.so.1   0x7fb89b8aeaa7 0x7fb89b8a6000
> /usr/lib/x86_64-linux-gnu/libelementary.so.1   0x7fb89b385142 0x7fb89b109000
> /usr/bin/ephoto0x55b70128b564 0x55b70126f000
> /usr/bin/ephoto0x55b701278a4f 0x55b70126f000
> /usr/bin/ephoto0x55b70127873c 0x55b70126f000
> /lib/x86_64-linux-gnu/libc.so.60x7fb898e3ba87 0x7fb898e1a000
> /usr/bin/ephoto0x55b70127877a 0x55b70126f000
> EOF
> 
> 
> 
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.16.11 (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 /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages ephoto depends on:
> ii  libc6 2.27-3
> ii  libecore-con1 1.20.7-4
> ii  libecore-evas11.20.7-4
> ii  libecore-file11.20.7-4
> ii  libecore-imf1 1.20.7-4
> ii  libecore-input1   1.20.7-4
> ii  libecore-ipc1 1.20.7-4
> ii  libecore1 1.20.7-4
> ii  libedje1  1.20.7-4
> ii  libeet1   1.20.7-4
> ii  

Bug#900022: stop shouldn't unconditionally fail if FLUSH_ON_STOP=0

[Ross Vandegrift]

Package: netfilter-persistent
Version: 1.0.4+nmu2
Severity: normal
Tags: patch

Currently, if FLUSH_ON_STOP=0 then /usr/sbin/netfilter-persistent stop exits
with code 1.  Since systemd runs this on stopping netfilter-persistent, the
unit goes into a failed state.  That causes anything that depends on
netfilter-persistent.service to fail.

This behavior seems wrong independantly: if FLUSH_ON_STOP=0, then it's not a
failure that the rules weren't flushed.  Please consider the attached patch.

Thanks,
Ross
>From aa9404c7908478989cedbd1daa0caea504dc4e6f Mon Sep 17 00:00:00 2001
From: Ross Vandegrift <r...@kallisti.us>
Date: Thu, 24 May 2018 11:52:02 -0700
Subject: [PATCH] Make stop succeed when FLUSH_ON_STOP=0

---
 netfilter-persistent | 1 -
 1 file changed, 1 deletion(-)

diff --git a/netfilter-persistent b/netfilter-persistent
index 8a3c365..6da593f 100755
--- a/netfilter-persistent
+++ b/netfilter-persistent
@@ -40,7 +40,6 @@ stop)
 run_plugins flush
 else
 echo "Automatic flush disabled; use '${0} flush'"
-exit 1
 fi
 ;;
 *)
-- 
2.11.0

Bug#891779: ITP: ephoto -- A Comprehensive Image Viewer Using EFL

[Ross Vandegrift]

Control: retitle -1 ITP: ephoto -- A Comprehensive Image Viewer Using EFL

Thanks for the suggestion.  I've started some work here:
https://salsa.debian.org/pkg-e-team/ephoto.git

Ross

On Wed, Feb 28, 2018 at 02:36:29PM -0500, Antoine Beaupre wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: ephoto
>   Version : 1.5
>   Upstream Author : Stephen Houston 
> * URL : https://www.enlightenment.org/about-ephoto
> * License : BSD-3-clause
>   Programming Lang: C
>   Description : A Comprehensive Image Viewer Using EFL
> 
> Ephoto is an image viewer and editor written using the Enlightenment
> Foundation Libraries(EFL). It focuses on simplicity and ease of use,
> while taking advantage of the speed and small footprint provided by
> EFL.
> 
> --
> 
> While there are many image viewers in Debian already, this one is
> interesting because it has an interesting mix of features. It has a
> grid view to browse images from the filesystem directly and slideshow
> support but can also act as a simple standalone image viewer. It can
> also operate basic filters and image modifications.
> 
> This is similar to Shotwell or Digikam, but much more lightweight in
> that images do not need to be imported.
> 
> Hopefully this can be part of the e-team..?
> 
> ___
> Pkg-e-devel mailing list
> pkg-e-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-e-devel
> 

Bug#899134: lintian: desktop file checks have outdated links

[Ross Vandegrift]

Package: lintian
Version: 2.5.86
Severity: normal
Tags: patch

The desktop file checks contain links to the spec.  Some of these need to be
updated for the latest version of the spec.  The attached patch fixes the
issues I found this morning.

Ross
>From d0c2fc81c847bb3015768c33820c3d21f9418aa9 Mon Sep 17 00:00:00 2001
From: Ross Vandegrift <r...@kallisti.us>
Date: Sat, 19 May 2018 10:01:04 -0700
Subject: [PATCH] Update freedesktop.org desktop spec links

Section page links have changed in the latest version of the desktop spec.
Also, s/standards/specifications/ to match the rest of lintian.
---
 checks/menu-format.desc | 16 
 checks/menu-format.pm   |  2 +-
 data/menu-format/known-desktop-keys |  2 +-
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/checks/menu-format.desc b/checks/menu-format.desc
index b9027bf..9ae97ce 100644
--- a/checks/menu-format.desc
+++ b/checks/menu-format.desc
@@ -252,7 +252,7 @@ Info: The desktop entry file has lines ending in CRLF 
instead of just LF.
  CR character in the file:
  .
  sed -i 's/\r//g' path/to/file
-Ref: https://standards.freedesktop.org/desktop-entry-spec/latest/ar01s02.html
+Ref: 
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s03.html
 
 Tag: duplicated-key-in-desktop-entry
 Severity: normal
@@ -270,7 +270,7 @@ Info: Desktop entries must contain, at a minimum, the keys 
Type and Name.
  .
  The desktop-file-validate tool in the desktop-file-utils package is
  useful for checking the syntax of desktop entries.
-Ref: https://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html
+Ref: 
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s06.html
 
 Tag: desktop-entry-contains-unknown-key
 Severity: minor
@@ -282,7 +282,7 @@ Info: The key on this line of the desktop entry is not one 
of the standard
  .
  The desktop-file-validate tool in the desktop-file-utils package is
  useful for checking the syntax of desktop entries.
-Ref: https://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html
+Ref: 
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s06.html
 
 Tag: desktop-entry-contains-deprecated-key
 Severity: normal
@@ -292,7 +292,7 @@ Info: The key on this line of the desktop entry has been 
deprecated in the
  .
  The desktop-file-validate tool in the desktop-file-utils package is
  useful for checking the syntax of desktop entries.
-Ref: https://standards.freedesktop.org/desktop-entry-spec/latest/apc.html
+Ref: https://specifications.freedesktop.org/desktop-entry-spec/latest/apc.html
 
 Tag: desktop-entry-contains-encoding-key
 Severity: wishlist
@@ -304,7 +304,7 @@ Info: The Encoding key is now deprecated by the FreeDesktop 
standard and
  .
  The desktop-file-validate tool in the desktop-file-utils package is
  useful for checking the syntax of desktop entries.
-Ref: https://standards.freedesktop.org/desktop-entry-spec/latest/apc.html
+Ref: https://specifications.freedesktop.org/desktop-entry-spec/latest/apc.html
 
 Tag: desktop-entry-lacks-main-category
 Severity: normal
@@ -329,7 +329,7 @@ Info: This .desktop file does not contain an "Icon" entry.
  .
  The desktop-file-validate tool in the desktop-file-utils package is
  useful for checking the syntax of desktop entries.
-Ref: 
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s05.html,
+Ref: 
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s06.html,
  
https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html,
  #854132
 
@@ -346,7 +346,7 @@ Info: This .desktop file does either not contain a 
"Keywords" entry or it does
  .
  The desktop-file-validate tool in the desktop-file-utils package is
  useful for checking the syntax of desktop entries.
-Ref: 
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s05.html,
+Ref: 
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s06.html,
  #693918, https://wiki.gnome.org/Initiatives/GnomeGoals/DesktopFileKeywords
 
 Tag: desktop-entry-uses-reserved-category
@@ -393,7 +393,7 @@ Info: The key on this line of the desktop entry has been 
deprecated in the
  .
  The desktop-file-validate tool in the desktop-file-utils package is
  useful for checking the syntax of desktop entries.
-Ref: https://standards.freedesktop.org/desktop-entry-spec/latest/apc.html
+Ref: https://specifications.freedesktop.org/desktop-entry-spec/latest/apc.html
 
 Tag: desktop-mime-but-no-exec-code
 Severity: normal
diff --git a/checks/menu-format.pm b/checks/menu-format.pm
index 295079f..0edf43e 100644
--- a/checks/menu-format.pm
+++ b/checks/menu-format.pm
@@ -96,7 +96,7 @@ my $DEPRECATED_DESKTOP_KEYS
 my $KDE_DESKTOP_KEYS = Lintian::Data->new('menu-format/kde-desktop-keys');
 
 # Known types of desktop entries.
-# https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s05.html
+# https://specifications.freedeskt

Bug#898527: libnss-mdns: Adding ipv6 scope id breaks NFS mounts

[Ross Vandegrift]

On Mon, May 14, 2018 at 01:38:15PM +0100, Simon McVittie wrote:
> On Sat, 12 May 2018 at 18:26:11 -0700, Ross Vandegrift wrote:
> > It looks like the scope id was added in #644912.  This may be a kernel bug 
> > if
> > the scope id should be accepted.
> 
> I think this might be a bug in whatever user-space tool calls
> getaddrinfo() and passes its result to the kernel, which probably means
> mount.nfs? If the kernel doesn't want to see scope IDs in this context,
> then the user-space tool shouldn't provide them: returning scope IDs is
> part of the getaddrinfo() API.

I did some digging, here's what I found.

mount.nfs accepts scoped ipv6 addresses:
  $ sudo mount.nfs -vf '[fd7d:612b:f36c:0:4d15:7364:6589:dbef%2]:/' /mnt/tmp -o 
nfsvers=4.2
  mount.nfs: timeout set for Mon May 14 19:11:01 2018
  mount.nfs: trying text-based options 
'vers=4.2,addr=fd7d:612b:f36c:0:4d15:7364:6589:dbef%2,clientaddr=fd7d:612b:f36c::4c5'

But mount(2) fails:
  $ sudo mount.nfs -v '[fd7d:612b:f36c:0:4d15:7364:6589:dbef%2]:/' /mnt/tmp -o 
nfsvers=4.2
  mount.nfs: timeout set for Mon May 14 19:12:48 2018
  mount.nfs: trying text-based options 
'nfsvers=4.2,addr=fd7d:612b:f36c:0:4d15:7364:6589:dbef%2,clientaddr=fd7d:612b:f36c::4c5'
  mount.nfs: mount(2): Invalid argument
  mount.nfs: an incorrect mount option was specified

nfs(5) has the following to say about the source argument:
  The server's hostname can be an unqualified hostname, a fully qualified
  domain name, a dotted quad IPv4 address, or an IPv6 address enclosed in square
  brackets.  Link-local and site-local IPv6 addresses must be accompanied by an
  interface identifier.  See ipv6(7) for details on specifying raw IPv6
  addresses.

And ipv6(7) has this to say about the scope id field:
  sin6_scope_id is an ID depending on the scope of the address.  It is new in
  Linux 2.4.  Linux supports it only for link-local addresses, in that case
  sin6_scope_id contains the interface index (see netdevice(7))


Best as I can figure there's three wishlist bugs here:

1. nss-mdns should not return scope id for global addresses
2. mount.nfs should strip scope id unless the address is link-local
3. the kernel should accept & ignore scope id on non-global addresses

Does this seems like a reasonable reading?

Ross

Bug#898527: libnss-mdns: Adding ipv6 scope id breaks NFS mounts

[Ross Vandegrift]

On Mon, May 14, 2018 at 01:38:15PM +0100, Simon McVittie wrote:
> Not including the scope ID in the result of address resolution breaks IPv6
> link-local addressing (fe80:*), and link-local addressing and mDNS are both
> parts of the Zeroconf stack, so they (should) go well together.

Yep, this makes perfect sense - the scope id shouldn't go away entirely.

> Or possibly nss-mdns should be setting the scope ID to the interface
> index for link-local addresses, but not for other addresses? It isn't
> entirely clear to me what nss-mdns is meant to be doing here.

On one hand, rfc4007 11.1 says that the scope id should not be used for
global scope, loopback, and undefined addresses.  On the other, ping &
ssh both saw the scope id and handled it without complaint.


> Workarounds:
> 
> * don't use mDNS (.local names) to find NFS servers; or
> * configure mdns4[_minimal] instead of mdns[_minimal] so .local names
>   resolve to IPv4 addresses

Yea there are workarounds, but I think this use-case is a sensible one
that should be supported.

My home has provider-assigned addressing via DHCPv6 PD, so it isn't
static.  ipv6 wisdom might suggest ULA + DNS instead.  That requires
static addressing or dynamic DNS - both of which are overkill for home
users.  mDNSv6 has been providing a good solution to exactly this.

Ross

Bug#898527: libnss-mdns: Adding ipv6 scope id breaks NFS mounts

[Ross Vandegrift]

Package: libnss-mdns
Version: 0.14.1-1
Severity: normal
Tags: ipv6

After upgrading my laptop from stretch to buster, I'm not able to mount NFS via
mdns.  I have the following entry in /etc/fstab:

  vanvanmojo.local:/mnt/storage   /mnt/storage nfs4   
noauto,nofail,x-systemd.automount,x-systemd.mount-timeout=10,x-systemd.requires=network-online.target,x-systemd.idle-timeout=10m
0   0

The mount fails with the following log message:

  stgulik kernel: [  575.329441] NFS: bad IP address specified: 
addr=2606:6000:4502:1d00:4639:c4ff:fe53:e49b%2

It looks like the scope id was added in #644912.  This may be a kernel bug if
the scope id should be accepted.

Thanks,
Ross


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

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

Versions of packages libnss-mdns depends on:
ii  avahi-daemon  0.7-4
ii  base-files10.1
ii  libc6 2.27-3

libnss-mdns recommends no packages.

Versions of packages libnss-mdns suggests:
ii  avahi-autoipd  0.7-4

-- no debconf information

Bug#898384: terminology: focus weirdness in 1.2.0

[Ross Vandegrift]

Package: terminology
Version: 1.2.0-1
Severity: serious

terminology 1.2.0 easily gets stuck in a state where it doesn't receive
keyboard events.  This is triggered by switching keyboard focus away from
terminology, and then back.

Upstream discussion:
 https://sourceforge.net/p/enlightenment/mailman/message/36314861/
 <20180510202714.ga10...@nabu.fau.re>

Ross

Bug#818928: terminology: fails to start terminology

[Ross Vandegrift]

Control: tags -1 moreinfo

On Mon, Mar 21, 2016 at 09:26:48PM +0200, Denys wrote:
> Dear Maintainer, terminology fails to start on debian sid.
> 
> ERR<8080>:terminology main.c:3001 elm_main() Could not initialize key 
> bindings.
> ERR<8080>:efreet_cache lib/efreet/efreet_cache.c:1108 on_send_register()
> org.enlightenment.DBus.Canceled Canceled by user.
> CRI: lib/eet/eet_lib.c:626 eet_shutdown() eina_log_print() unknown domain -1,
> original message format 'Init count not greater than 0 in shutdown.'

I don't know what could've caused this issue.  But I'm not able to reproduce
with EFL 1.20 and terminology 1.1.1 now in sid.  Could you retest?

Thanks,
Ross

Bug#773057: Dependency problem

[Ross Vandegrift]

Control: tags -1 moreinfo

On Wed, Jan 11, 2017 at 04:35:40PM +0200, Bruce Weirdan wrote:
> There's a dependency problem that renders the fix unusable:
> terminology 0.9.1-1 depends on libeina1 >=1.8.0 (available 1.8.6-2.5+b1)
> libemotion-players 1.18.4-1 depends on libeina1a >=1.18.4-1 (available
> 1.18.4-1) which conflicts with libeina1

EFL 1.20 has recently migration from experimental to sid & buster.  This issue
should no longer cause installation issues.  Can you retest?

Thanks,
Ross

Bug#895809: enlightenment: Fails to start

[Ross Vandegrift]

On Mon, Apr 16, 2018 at 06:09:27PM +0200, Manolo Díaz wrote:
> On Monday, 16 Apr 2018 at 15:43 UTC
> Ross Vandegrift wrote:
> 
> > Control: severity -1 normal
> > Control: tags -1 moreinfo
> > 
> > > ESTART: 0.17880 [0.00119] - Compositor Init
> > > <<<< Enlightenment Error >>>>
> > > Enlightenment cannot initialize Ecore_X!  
> > 
> > Is X running?  How are you starting enlightenment?
> > 
> > Ross
> 
> No, X is installed but it wasn't running. I tried the
> enlightenment_start command from the linux console, no X display
> manager such as ldm, etc.

That's the issue.  You must have a X server running to start a window
manager, enlightenment included.  Try:

startx enlightenment_start

FWIW, you might have a nicer experience with a display manager.
Enlightenment will appear as a session option in gdm/kdm/lightdm/etc.

Ross

Bug#895809: enlightenment: Fails to start

[Ross Vandegrift]

Control: severity -1 normal
Control: tags -1 moreinfo

> ESTART: 0.17880 [0.00119] - Compositor Init
>  Enlightenment Error 
> Enlightenment cannot initialize Ecore_X!

Is X running?  How are you starting enlightenment?

Ross

Bug#895762: lintian should check if Vcs-Git branch matches d/gbp.conf branch

[Ross Vandegrift]

On Sun, Apr 15, 2018 at 09:30:14PM +0200, Mattia Rizzolo wrote:
> On Sun, Apr 15, 2018 at 11:48:13AM -0700, Ross Vandegrift wrote:
> > If a package uses gbp and a deban-branch is specified in d/gbp.conf, then
> > vcswatch should probably be checking that branch.  In #886334, it's pointed 
> > out
> > that vcswatch cannot use gbp.conf since that requires unpacked source.  So
> > here's a lintian check to warn on the mismatch.
> 
> Note that this is going to most likely cause tons of false positives.
> Think of packages which origin's HEAD is correctly set (so the -b option
> in Vcs-Git is pointless) but still set debian-branch in d/gbp.conf.

Hmm, I see.  If that's common, this probably can't be checked for.

Ross


signature.asc
Description: PGP signature

Bug#895762: lintian should check if Vcs-Git branch matches d/gbp.conf branch

[Ross Vandegrift]

Package: lintian
Version: 2.5.77~bpo9+1
Severity: wishlist
Tags: patch

If a package uses gbp and a deban-branch is specified in d/gbp.conf, then
vcswatch should probably be checking that branch.  In #886334, it's pointed out
that vcswatch cannot use gbp.conf since that requires unpacked source.  So
here's a lintian check to warn on the mismatch.

Thanks,
Ross
>From 56cec96dbd4ddfcc9c1c25637d0c07ba16c22048 Mon Sep 17 00:00:00 2001
From: Ross Vandegrift <r...@kallisti.us>
Date: Sun, 15 Apr 2018 11:39:30 -0700
Subject: [PATCH] Warn about mismatches between git branches in gbp.conf &
 Vcs-Git

If d/gbp.conf exists and the buildpackage section specifies a
debian-branch, then Vcs-Git should match that branch.  This helps with the
issue described in #886334.
---
 checks/git-buildpackage.desc   | 15 +
 checks/git-buildpackage.pm | 66 ++
 debian/control |  1 +
 .../debian/debian/control.in   | 20 +++
 .../debian/debian/gbp.conf |  2 +
 t/tests/gbp-vcs-git-branch-mismatch/desc   |  6 ++
 t/tests/gbp-vcs-git-branch-mismatch/tags   |  1 +
 .../gbp-vcs-git-no-branch/debian/debian/control.in | 20 +++
 .../gbp-vcs-git-no-branch/debian/debian/gbp.conf   |  2 +
 t/tests/gbp-vcs-git-no-branch/desc |  6 ++
 t/tests/gbp-vcs-git-no-branch/tags |  1 +
 11 files changed, 140 insertions(+)
 create mode 100644 checks/git-buildpackage.desc
 create mode 100644 checks/git-buildpackage.pm
 create mode 100644 t/tests/gbp-vcs-git-branch-mismatch/debian/debian/control.in
 create mode 100644 t/tests/gbp-vcs-git-branch-mismatch/debian/debian/gbp.conf
 create mode 100644 t/tests/gbp-vcs-git-branch-mismatch/desc
 create mode 100644 t/tests/gbp-vcs-git-branch-mismatch/tags
 create mode 100644 t/tests/gbp-vcs-git-no-branch/debian/debian/control.in
 create mode 100644 t/tests/gbp-vcs-git-no-branch/debian/debian/gbp.conf
 create mode 100644 t/tests/gbp-vcs-git-no-branch/desc
 create mode 100644 t/tests/gbp-vcs-git-no-branch/tags

diff --git a/checks/git-buildpackage.desc b/checks/git-buildpackage.desc
new file mode 100644
index 0..3d0d06973
--- /dev/null
+++ b/checks/git-buildpackage.desc
@@ -0,0 +1,15 @@
+Check-Script: git-buildpackage
+Author: Ross Vandegrift <r...@kallisti.us>
+Abbrev: gbp
+Type: source
+Needs-Info: unpacked
+Info: This script checks for issues in gbp.conf.
+
+Tag: mismatch-between-vcs-git-and-gbp-debian-branch
+Severity: normal
+Certainty: possible
+Info: This package includes a debian/gbp.conf file, and the
+ buildpackage section specifies a branch name.  However, Vcs-Git in
+ debian/control points to a different branch.  If this package is
+ built with git-buildpackage, this will confuse vcswatch.
+Ref: policy 5.6.26
diff --git a/checks/git-buildpackage.pm b/checks/git-buildpackage.pm
new file mode 100644
index 0..64d63e76a
--- /dev/null
+++ b/checks/git-buildpackage.pm
@@ -0,0 +1,66 @@
+# git-buildpackage -- lintian check script -*- perl -*-
+
+# Copyright (C) 2018 Ross Vandegrift
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, you can find it on the World Wide
+# Web at http://www.gnu.org/copyleft/gpl.html, or write to the Free
+# Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+# MA 02110-1301, USA.
+
+package Lintian::git_buildpackage;
+use strict;
+use warnings;
+use autodie;
+
+use Lintian::Tags qw(tag);
+
+use Config::IniFiles;
+
+sub run {
+my ($pkg_name, $pkg_type, $info, $pkg, $group) = @_;
+
+# check for a gbp.conf with debian-branch set in the buildpackage section
+my $gbp_conf = $info->index_resolved_path('debian/gbp.conf');
+return if not $gbp_conf;
+
+my $cfg = Config::IniFiles->new(-file => $gbp_conf->fs_path);
+my $gbp_branch = $cfg->val('buildpackage', 'debian-branch');
+return if not $gbp_branch;
+
+# check for a branch in Vcs-Git
+my $dcontrol = $info->index_resolved_path('debian/control');
+return if not $dcontrol;
+
+my $fd = $dcontrol->open;
+while (my $line = <$fd>) {
+if ($line =~ /^Vcs-Git: /) {
+my (undef, $url, $dash_b, $dcontrol_branch) = split(/\s+/, $line);
+if ($dash_b ne '-b' || $dcontrol_branch ne $gbp_branch) {
+tag 'mismatch-between-vcs-git-and-gbp-de

Bug#878572: Bug#895511: exactimage FTBFS with libevas-dev 1.20.7

[Ross Vandegrift]

On Thu, Apr 12, 2018 at 10:38:55AM +0200, Sven Eckelmann wrote:
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/exactimage.html
> 
> Thanks for bringing this up again. This is a long standing bug in 
> libevas-dev. 
> Increasing the severity for the libevas-dev bug now because they have 
> uploaded 
> the problematic version to unstable without fixing it.

Hi Sven - 

(Thought I sent this info along already, but I don't see it in BTS.
Very sorry for letting this slip through the cracks.)

exactimage uses headers that accidentally exposed internal EFL data
structures.  Later that caused ABI/API compatability problems.  Upstream
decided to fix this by no longer shipping the engine headers.  According
to them, they had been optional functionality.

Upstream is unclear on whether or not exactimage can be fixed with EFL
1.20.  It sounds like the only external project to have used the engines
directly.  Their suggestion is to port to ecore-evas.  I don't have the
knowledge to help here, but Cedric from EFL offered help.

Unfortunately, it's not as simple as shipping the headers in Debian.  I
tried that, but the bits used by exactimage have since moved around, and
some of the structures have changed.  We'd need to diverge significantly
from upstream, and Pkg-E doesn't have the resources or expertise to
maintain a distro-specific fork.

Ross


signature.asc
Description: PGP signature

Bug#895171: pavucontrol requires gnome-control-center-data for icon

[Ross Vandegrift]

On Mon, Apr 09, 2018 at 08:37:11PM +0300, sergio wrote:
> On 09/04/18 20:24, Ross Vandegrift wrote:
> > You may need to change the icon theme that E is using: check the icon
> > tab under Settings -> Look -> Application Theme.
> 
> This works. But should E automatically find missing icons in other installed
> themes?

I don't know for sure, I'm not that fmailiar with the FDO specs.  From a quick
glance at the Icon Lookup section of the spec, it sounds like such fallback is
optional.

https://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html

Ross

Bug#895171: pavucontrol requires gnome-control-center-data for icon

[Ross Vandegrift]

On Mon, Apr 09, 2018 at 07:55:42PM +0300, sergio wrote:
> there are a lot of other icon themes that provides multimedia-volume-control
> (adwaita-icon-theme for exmaple, which is installed on my system), but I see
> pavucontrol icon only with gnome-control-center-data installed.

You may need to change the icon theme that E is using: check the icon
tab under Settings -> Look -> Application Theme.

Ross

Bug#895171: Acknowledgement (enlightenment: No thunderbird icon with scale 1.4 1.45 1.5)

[Ross Vandegrift]

On Sun, Apr 08, 2018 at 07:27:32AM +0300, sergio wrote:
> Same for pavucontrol.

Both work for me.  Do you have libevas-loaders installed?  What versions of
libeina1a and thunderbird packages?

Thanks,
Ross