Bug#552994: mbrowse: Input handling prevents typing some characters

[Ross Vandegrift]

Package: mbrowse
Version: 0.3.1-8
Severity: grave
Justification: renders package unusable


Since the GTK 2.x upgrade, mbrowse has become totally unusable - typing
certain characters into the text input fields is impossible.  This
prevents me from entering certain hostnames or community strings.

1) If I type e: mbrowse exits
2) If I type g: mbrowse trys to GET the currently selected item
3) If I type w: mbrowse trys to WRITE to the currently selected item

Please revert to the old GTK 1.x version of this application, which had
none of these problems.

Ross

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mbrowse depends on:
ii  libatk1.0-01.28.0-1  The ATK accessibility toolkit
ii  libc6  2.9-25GNU C Library: Shared libraries
ii  libcairo2  1.8.8-2   The Cairo 2D vector graphics libra
ii  libfontconfig1 2.6.0-4   generic font configuration library
ii  libfreetype6   2.3.11-1  FreeType 2 font engine, shared lib
ii  libglib2.0-0   2.22.2-2  The GLib library of C routines
ii  libgtk2.0-02.18.2-1  The GTK+ graphical user interface 
ii  libpango1.0-0  1.26.0-1  Layout and rendering of internatio
ii  libsnmp15  5.4.1~dfsg-12 SNMP (Simple Network Management Pr

mbrowse recommends no packages.

mbrowse suggests no packages.

-- no debconf information



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

Bug#566208: linux-image-2.6.26-2-486: e_powersaver causes constant lockups

[Ross Vandegrift]

Package: linux-image-2.6.26-2-486
Version: 2.6.26-19lenny2
Severity: critical
Justification: breaks the whole system

After upgrading linux-image-2.6.26-2-486 from 17lenny1 to 19lenny2, I
started experiencing 100% reproducable system lockups on a VIA C7
system.  No errors in the logs, no oops, no BUG, nothing - just a hard
lock.  No keyboard LED response and no sysrq functionality worked.

Sometimes the system wouldn't complete the boot process without
freezing.  Sometimes it would last three minutes or so before
freezing.  I could reproduce the lockup with cat /dev/zero  file.
Every time, within 10 seconds, the system would freeze.

After a lot of trial, error, and searching, I discovered that the
e_powersaver module was being loaded and the lockups went away if I
unloaded it.

The kernel build help text indicates that the module shouldn't ever be
used, and is highly dangerous:

 This adds the CPUFreq driver for VIA C7 processors.  However, this
 driver does not have any safeguards to prevent operating the CPU out
 of spec and is thus considered dangerous.  Please use the regular ACPI
 cpufreq driver, enabled by CONFIG_X86_ACPI_CPUFREQ.

I have blacklisted this module and suspect that it should be
blacklisted by default.  It seems possible that Debian bug #563941 is
related to this issue as well, but there's not enough info in the
report for me to be sure.

Thanks,
Ross

-- Package-specific info:
** Version:
Linux version 2.6.26-2-486 (Debian 2.6.26-19lenny2) (da...@debian.org) (gcc 
version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 Wed Nov 4 20:19:07 
UTC 2009

** Command line:
root=LABEL=root ro 

** Not tainted

** Kernel log:
[   13.058778] udevd version 125 started
[   13.061147] usb 2-1: new low speed USB device using uhci_hcd and address 2
[   13.303392] usb 2-1: configuration #1 chosen from 1 choice
[   13.308441] usb 2-1: New USB device found, idVendor=051d, idProduct=0002
[   13.308522] usb 2-1: New USB device strings: Mfr=3, Product=1, SerialNumber=2
[   13.308596] usb 2-1: Product: Back-UPS XS 1300 LCD FW:836.H7 .D USB FW:H7 
[   13.308667] usb 2-1: Manufacturer: American Power Conversion
[   13.308736] usb 2-1: SerialNumber: 8B0749R09108  
[   17.063851] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[   17.111770] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[   17.171321] Linux agpgart interface v0.103
[   17.321713] agpgart: Detected VIA P4M900 chipset
[   17.324789] agpgart: AGP aperture is 32M @ 0xfc00
[   19.291607] Initializing USB Mass Storage driver...
[   19.400611] scsi4 : SCSI emulation for USB Mass Storage devices
[   19.401000] scsi5 : SCSI emulation for USB Mass Storage devices
[   19.401232] usbcore: registered new interface driver usb-storage
[   19.401305] USB Mass Storage support registered.
[   19.461227] usb-storage: device found at 4
[   19.461238] usb-storage: waiting for device to settle before scanning
[   19.464808] usb-storage: device found at 2
[   19.464815] usb-storage: waiting for device to settle before scanning
[   19.832163] input: Power Button (FF) as /class/input/input1
[   19.863234] ACPI: Power Button (FF) [PWRF]
[   19.863598] input: Sleep Button (CM) as /class/input/input2
[   19.888589] ACPI: Sleep Button (CM) [SLPB]
[   19.60] input: Power Button (CM) as /class/input/input3
[   19.921730] ACPI: Power Button (CM) [PWRB]
[   22.914126] input: PC Speaker as /class/input/input4
[   23.138478] Error: Driver 'pcspkr' is already registered, aborting...
[   23.248778] ACPI: PCI Interrupt :80:01.0[A] - GSI 17 (level, low) - 
IRQ 17
[   23.248968] PCI: Setting latency timer of device :80:01.0 to 64
[   24.460310] usb-storage: device scan complete
[   24.461172] scsi 5:0:0:0: Direct-Access Generic  Flash Disk   8.07 
PQ: 0 ANSI: 2
[   24.475496] sd 5:0:0:0: [sde] 1978368 512-byte hardware sectors (1013 MB)
[   24.476243] sd 5:0:0:0: [sde] Write Protect is off
[   24.476321] sd 5:0:0:0: [sde] Mode Sense: 03 00 00 00
[   24.476330] sd 5:0:0:0: [sde] Assuming drive cache: write through
[   24.479494] sd 5:0:0:0: [sde] 1978368 512-byte hardware sectors (1013 MB)
[   24.480239] sd 5:0:0:0: [sde] Write Protect is off
[   24.480318] sd 5:0:0:0: [sde] Mode Sense: 03 00 00 00
[   24.480326] sd 5:0:0:0: [sde] Assuming drive cache: write through
[   24.480414]  sde:7usb-storage: device scan complete
[   24.522804] scsi 4:0:0:0: Direct-Access Seagate  FreeAgent0132 
PQ: 0 ANSI: 4
[   24.706237]  sde1
[   24.706650] sd 5:0:0:0: [sde] Attached SCSI removable disk
[   24.710798] sd 4:0:0:0: [sdf] 3907029168 512-byte hardware sectors (2000399 
MB)
[   24.711555] sd 4:0:0:0: [sdf] Write Protect is off
[   24.711646] sd 4:0:0:0: [sdf] Mode Sense: 2d 08 00 00
[   24.711654] sd 4:0:0:0: [sdf] Assuming drive cache: write through
[   24.712930] sd 4:0:0:0: [sdf] 3907029168 512-byte hardware sectors (2000399 
MB)
[   24.714540] sd 4:0:0:0: [sdf] Write Protect is off
[   24.714628] sd 4:0:0:0: [sdf] Mode 

Bug#571962: azureus: Fails to start with Azureus core already instantiated

[Ross Vandegrift]

On Mon, May 10, 2010 at 10:11:51PM +0300, Damyan Ivanov wrote:
 I cannot reproduce the bug, and I appear to already have the swt.jar 
 - swt-gtk-3.5.1.jar symlink in /usr/share/java/, shipped by the 
 libswt-gtk-3.5 package, version 3.5.1-2 (same as in the original 
 report):
 
 $ dpkg -S /usr/share/java/swt.jar
 libswt-gtk-3.5-java: /usr/share/java/swt.jar
 $ ls /usr/share/java/swt.jar -l
 lrwxrwxrwx 1 root root 17  1 ?? 22,51 /usr/share/java/swt.jar - 
 swt-gtk-3.5.1.jar

It looks like this was related to something getting botched up with
libswt.  Reinstalling libswt-gtk-3.5-java fixed me up.  Thanks for the
info!

Ross

-- 
Ross Vandegrift
r...@kallisti.us

If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher.
--Woody Guthrie


signature.asc
Description: Digital signature

Bug#560238: netbase: racoon is also broken by net.ipv6.bindv6only change

[Ross Vandegrift]

Package: netbase
Version: 4.40
Severity: normal

Hello,

I recently had a VPN break and have traced it back to the
net.ipv6.bindv6only change.  When racoon initiates IKE, I can see the
response packet from the IPSec responder but racoon never receives it.

I disabled net.ipv6.bindv6only and rebooted.  Now racoon is able to
bring up my VPN as previously.

Ross

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages netbase depends on:
ii  initscripts   2.87dsf-8  scripts for initializing and shutt
ii  lsb-base  3.2-23 Linux Standard Base 3.2 init scrip

Versions of packages netbase recommends:
ii  ifupdown  0.6.9  high level tools to configure netw

netbase suggests no packages.

-- debconf information:
  netbase/upgrade-note/etc-network-interfaces-pre-3.17-1:
  netbase/upgrade-note/init.d-split-pre-3.16-1:
  netbase/upgrade-note/radius-ports-pre-3.05:
  netbase/upgrade-note/portmap-restart-pre-3.11-2:



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

Bug#539752: emacs installs, but installs emacs23-nox

[Ross Vandegrift]

Package: emacs
Version: 23.1+1-2
Severity: normal


I updated my installation yesterday.  I've had the emacs and emacs22
packages installed.  The following happened:

malaclypse:~# grep emacs /var/log/aptitude
[INSTALL, DEPENDENCIES] emacs23-bin-common
[INSTALL, DEPENDENCIES] emacs23-common
[INSTALL, DEPENDENCIES] emacs23-nox
[UPGRADE] emacs 22.3+1-1.1 - 23.1+1-2

This breaks my emacs in X, which isn't tragic (I can workaround it), but
is quite confusing!  I've added this to this bug report since it seems
likely that this is related to dependencies that aren't installable,
though my system had no problem installing emacs23-common.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-openvz-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages emacs depends on:
ii  emacs23-nox [emacs23] 23.1+1-2   The GNU Emacs editor (without X su

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information



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

Bug#613752: Registers itself to open PDF and PostScript; ends up as the default

[Ross Vandegrift]

I recently hit this bug after an upgrade pulled in Gnome 3.  Very
annoying.  Though I agree that this should be changed, see here for a
workaround that's better than nothing:

http://lists.debian.org/debian-user/2011/12/msg01372.html

Ross


signature.asc
Description: This is a digitally signed message part

Bug#760038: [Pkg-e-devel] Bug#760038: minor problem subsists

[Ross Vandegrift]

On 10/08/2014 09:44 AM, Curtis Dean Smith wrote:
 Well, I've given up on e17 for the short term, although I went from
 stable to testing specifically for e17.  I try once a week to see if
 something changed, but no luck.

Have you tried disabling the login splash screen on the first login?
This was a common workaround back in the late 0.17 era.  I don't have a
great reference, but there's some discussion here:

http://osdir.com/ml/enlightenment-users-linux-ui/2013-08/msg00057.html

Ross


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

Bug#878572: exactimage: FTBFS in experimental: gfx/X11Helper.hh:33:10: fatal error: Evas_Engine_Software_X11.h: No such file or directory

[Ross Vandegrift]

Source: exactimage
Version: 1.0.1-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Control: affects -1 + edisplay

Hello,

exactimage fails to build against EFL 1.20 from experimental:

In file included from gfx/X11Helper.cc:36:0:
gfx/X11Helper.hh:33:10: fatal error: Evas_Engine_Software_X11.h: No such file 
or directory
 #include "Evas_Engine_Software_X11.h"
  ^~~~
compilation terminated.
make[3]: *** [objdir/gfx/X11Helper.o] Error 1
build/bottom.make:54: recipe for target 'objdir/gfx/X11Helper.o' failed
make[3]: *** Waiting for unfinished jobs
edisplay/edisplay.cc:25:10: fatal error: Evas_Engine_Software_X11.h: No such 
file or directory
 #include "Evas_Engine_Software_X11.h"
  ^~~~
compilation terminated.
make[3]: *** [objdir/edisplay/edisplay.o] Error 1
build/bottom.make:54: recipe for target 'objdir/edisplay/edisplay.o' failed


Thanks,
Ross


exactimage_1.0.1-1_amd64.build.gz
Description: application/gzip

Bug#878584: [Pkg-e-devel] Bug#878584: [libevas-dev] Missing dependency for libecore-dev

[Ross Vandegrift]

On Sun, Oct 15, 2017 at 01:20:05PM +0200, Andreas Metzler wrote:
> Ross, could you apply and push the attached patch?

Hmm, two concerns about this solution:

1) lintian finds a circular dependency
  libecore-dev libector-dev libeet-dev libeeze-dev libeina-dev libemile-dev 
libevas-dev
I don't know for sure that it's a problem here, but in the past the team
has worked hard to avoid cycles.

2) Upstream doesn't really support builds against part of EFL (and
hasn't since the library merge before 1.8).  I think we generally ought
to avoid supporting scenarios that upstream doesn't.

Instead, what if all of the -dev packages were merged into
libefl-all-dev?  Sample patch is attached.  It's mildly tested:
enlightenment from experimental builds, and the resulting Depends look
correct.  What do you think?

I've pushed the accumulated fixes to:
https://github.com/rvandegrift/efl/tree/debian/experimental
I've added this patch at:
https://github.com/rvandegrift/efl/tree/debian/experimental-next

Thanks,
Ross


merge-libe-dev-pkgs.diff.gz
Description: application/gzip

Bug#877180: [Pkg-e-devel] Bug#877180: libector-dev: missing Depends: libector1 (= ${binary:Version})

[Ross Vandegrift]

On Sun, Oct 01, 2017 at 04:02:32PM +0200, Andreas Metzler wrote:
> Control: tags -1 patch
> 
> On 2017-09-29 Andreas Beckmann  wrote:
> > Package: libector-dev
> > Version: 1.18.4-1
> > Severity: serious
> > User: debian...@lists.debian.org
> > Usertags: piuparts
> > 
> > Hi,
> > 
> > during a test with piuparts I noticed your package ships (or creates)
> > a broken symlink.
> > 
> > From the attached log (scroll to the bottom...):
> > 
> > 1m1.9s ERROR: FAIL: Broken symlinks:
> >   /usr/lib/x86_64-linux-gnu/libector.so -> libector.so.1.18.4
> 
> Thank you, Andreas.
> 
> Ross, find attached patches two fix this issue and another similar one.

Thanks: both are applied in my tree for 1.20.4-2.

Ross

Bug#881155: [Pkg-e-devel] Bug#881155: e17: Won't start correctly any longer, corrupted windows shown

[Ross Vandegrift]

Control: severity -1 important

I'm not able to reproduce.  This could be related to your video drivers.
But since Enlightenment in buster is old an unmaintained, nothing can be
done to fix it.

The current Enlightenment release is available in Debian experimental -
I'd encourage you to try that version instead.

Thanks,
Ross


On Wed, Nov 08, 2017 at 11:45:15AM +0100, Adrian Immanuel Kiess wrote:
> Package: e17
> Version: 0.17.6-1.1+b1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
>* What led up to the situation?
>  Using E17.
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>  startx or login with XDM.
>* What was the outcome of this action?
>  Currupted window display after login into E17.
>* What outcome did you expect instead?
>  Working E17 window manager.
> 
> currently in Debian/testing the E17 window manager won't load correctly any
> longer.
> 
> I tried with a default .e config and my own .e configuration.
> 
> The application windows won't show up correctly any longer after login.
> 
> Thank you very much in advance,
> 
> Yours Adrian Immanuel Kieß
> http://immanuelK.net
> 
> 
> 
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (900, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.13.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)
> 
> Versions of packages e17 depends on:
> ii  dbus-x11   1.12.0-1
> ii  e17-data   0.17.6-1.1
> ii  libasound2 1.1.3-5
> ii  libc6  2.24-17
> ii  libdbus-1-31.12.0-1
> ii  libecore-con1  1.8.6-2.5+b2
> ii  libecore-evas1 1.8.6-2.5+b2
> ii  libecore-file1 1.8.6-2.5+b2
> ii  libecore-imf1  1.8.6-2.5+b2
> ii  libecore-input11.8.6-2.5+b2
> ii  libecore-ipc1  1.8.6-2.5+b2
> ii  libecore-x11.8.6-2.5+b2
> ii  libecore1  1.8.6-2.5+b2
> ii  libedbus1  1.7.10-1+b2
> ii  libedje-bin1.8.6-2.5+b2
> ii  libedje1   1.8.6-2.5+b2
> ii  libeet11.8.6-2.5+b2
> ii  libeeze1   1.8.6-2.5+b2
> ii  libefreet-bin  1.8.6-2.5+b2
> ii  libefreet1a1.8.6-2.5+b2
> ii  libeina1   1.8.6-2.5+b2
> ii  libeio11.8.6-2.5+b2
> ii  libevas1   1.8.6-2.5+b2
> ii  libevas1-engines-x [libevas1-engine-software-x11]  1.8.6-2.5+b2
> ii  libpam0g   1.1.8-3.6
> ii  libxcb-keysyms10.4.0-1+b2
> ii  libxcb-shape0  1.12-1
> ii  libxcb11.12-1
> 
> Versions of packages e17 recommends:
> ii  pm-utils  1.4.1-17
> 
> e17 suggests no packages.
> 
> -- no debconf information
> ___
> 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#884019: [Pkg-e-devel] Bug#884019: terminology: FTBFS if $HOME is not writable

[Ross Vandegrift]

Control: tags -1 pending

On Sun, Dec 10, 2017 at 03:48:30PM +0100, Andreas Beckmann wrote:
> same problem as in e17:

Thanks, I've applied the fix from e17.

Ross

Bug#883833: [Pkg-e-devel] Bug#883833: e17: FTBFS if $HOME is not writable

[Ross Vandegrift]

Control: tags -1 pending

Looks good, patch applied.

Ross

On Fri, Dec 08, 2017 at 08:07:31AM +0100, Andreas Metzler wrote:
> Control: tags -1 patch
> 
> On 2017-12-08 Andreas Beckmann  wrote:
> > Source: e17
> > Version: 0.22.1-1
> > Severity: serious
> > Justification: fails to build from source (but built successfully in the 
> > past)
> 
> > e17 FTBFS if $HOME is not existent (and therefore not writable) as
> > enforced by current pbuilder.
> > See also Policy 9.2.3.
> 
> > From the attached log:
> 
> > FATAL: Cannot create run dir '/nonexistent/.run' - errno=2
> 
> edje_cc seems to need a writeable ~/.
> 
> cu Andreas
> -- 
> `What a good friend you are to him, Dr. Maturin. His other friends are
> so grateful to you.'
> `I sew his ears on from time to time, sure'

> From 68546024af75578f47e42236077792ec33eb8646 Mon Sep 17 00:00:00 2001
> From: Andreas Metzler 
> Date: Fri, 8 Dec 2017 08:03:54 +0100
> Subject: [PATCH] Fix FTBFS with HOME="/nonexistent".
> 
> Copy fake_home.sh from efl and run dh_auto_build under it. edje_cc needs a
> writeable HOME. Closes: #883833
> ---
>  debian/changelog|  7 +++
>  debian/fake_home.sh | 15 +++
>  debian/rules|  4 
>  3 files changed, 26 insertions(+)
>  create mode 100755 debian/fake_home.sh
> 
> diff --git a/debian/changelog b/debian/changelog
> index 316806a9f..6f1bee871 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,10 @@
> +e17 (0.22.1-2) UNRELEASED; urgency=medium
> +
> +  * Copy fake_home.sh from efl and run dh_auto_build under it. edje_cc needs 
> a
> +writeable HOME. Closes: #883833
> +
> + -- Andreas Metzler   Fri, 08 Dec 2017 08:01:08 +0100
> +
>  e17 (0.22.1-1) experimental; urgency=medium
>  
>* New upstream release
> diff --git a/debian/fake_home.sh b/debian/fake_home.sh
> new file mode 100755
> index 0..2902878e1
> --- /dev/null
> +++ b/debian/fake_home.sh
> @@ -0,0 +1,15 @@
> +#!/bin/sh
> +
> +cleanup () {
> +[ -n "$temp_HOME" ] && rm -r "$temp_HOME"
> +[ -n "$temp_XDG_RUNTIME_DIR" ] && rm -r "$temp_XDG_RUNTIME_DIR"
> +}
> +
> +trap cleanup EXIT
> +
> +temp_HOME=$(mktemp -d)
> +temp_XDG_RUNTIME_DIR=$(mktemp -d)
> +
> +env HOME="$temp_HOME" \
> +XDG_RUNTIME_DIR="$temp_XDG_RUNTIME_DIR" \
> +$*
> diff --git a/debian/rules b/debian/rules
> index eafe076d0..de55ca691 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -11,6 +11,10 @@ 
> ARCH_PATH=$(DEB_HOST_GNU_SYSTEM)-$(DEB_HOST_GNU_CPU)-$(RELEASE)
>  override_dh_auto_configure:
>   dh_auto_configure --verbose
>  
> +override_dh_auto_build:
> + $(CURDIR)/debian/fake_home.sh \
> + dh_auto_build -O--buildsystem=meson --verbose
> +
>  override_dh_lintian:
>   sed -e "s/MULTIARCH/$(DEB_TARGET_MULTIARCH)/" \
>   -e "s/ARCH_PATH/$(ARCH_PATH)/" \
> -- 
> 2.15.0
> 

> ___
> 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#878584: [Pkg-e-devel] Bug#878584: [libevas-dev] Missing dependency for libecore-dev

[Ross Vandegrift]

On Mon, Oct 16, 2017 at 07:55:07PM +0200, Andreas Metzler wrote:
> I have not yet read over the patch in detail, I just have three quick
> notes:

Thanks for the feedback.  I've fixed these issues, but kept the
transitional package for libelementary-dev.  stable & sid have it,
but it comes from the old separate elementary source.

All pending updates plus an upgrade to 1.20.5 have been pushed to:
https://github.com/rvandegrift/efl/tree/debian/experimental

I've tested upgrades from current sid & experimental, including
replacing old -dev packages.  Ready for review when you get a chance.

(mentors isn't accepting my upload right now, I can try again later if
you'd like to see a built package.)

Thanks,
Ross

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#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#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#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#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#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#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#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#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#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#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#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#968030: e17: FTBFS during combined arch+indep build

[Ross Vandegrift]

On Fri, Aug 07, 2020 at 01:17:29AM +0200, Andreas Beckmann wrote:
> e17/experimental FTBFS during a combined binary arch+indep build (i.e. the
> default dpkg-buildpackage mode), while it succeeds during separate arch and
> indep builds (dpkg-buildpackage -B, dpkg-buildpackage -A; as done by the
> buildds). I know no other package having such a failure mode ;-)

Hah, I swear I finally had all combinations working- but looks like I just
moved the bump in the rug around.  At least I got a totally unique failure out
for my time! :)

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#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#979100: Legally problematic GPL-3+ readline dependency

[Ross Vandegrift]

Control: tags -1 pending

Hello,

On Sat, 2 Jan 2021 18:47:07 +0100 Bastian Germann wrote:
> This package depends on libreadline8 which is GPL-3+ licensed. According 
> to debian/copyright parts of your package are GPL-2-only licensed. If 
> that is also (transitively) the case for the binaries that link with 
> libreadline.so.8 it might be legally problematic (see 
> https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).

Since enlightenment Build-Depends on connman, I took a look.  I think this
isn't actually a problem. 

According to the docs, readline is only used in the cli client.  I confirmed in
a fresh sid container:

  # dpkg -l connman*
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name  Version Architecture Description
  
+++-=-===--===
  ii  connman   1.36-2.2amd64Intel 
Connection Manager daemon
  ii  connman-dev:amd64 1.36-2.2amd64Development 
files for connman
  ii  connman-doc   1.36-2.2all  ConnMan 
documentation
  ii  connman-vpn   1.36-2.2amd64Intel 
Connection Manager daemon - VPN daemon
  root@b7aa1f65ab2d:/# for i in $(dpkg -l connman* | grep connman | awk '{print 
$2}'); do dpkg -L $i | xargs ldd 2> /dev/null | grep -E '(^/)|libreadline'; 
done | grep -B 1 readline
  /usr/bin/connmanctl:
  libreadline.so.8 => /lib/x86_64-linux-gnu/libreadline.so.8 
(0x7f3b73d8b000)

Upstream relicensed the client source to GPL v2 or later in 27e37a50
specifically to address this issue [1].  That change was released in 1.10, but
d/copyright does not reflect it.

I've opened an MR with the fix at [2], but need a sponsor to upload since I'm
DN.  Since the uploader and maintainer have been inactive for some years, and
since this bug has had no reply since January, I'll open a sponsorship request
bug today.

[1] - 
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=27e37a50f35cc54c266cbd37e32dadbf3016e5e8
 
[2] - https://salsa.debian.org/debian/connman/-/merge_requests/6

Ross

Bug#1014662: cloud-initramfs-growroot: Initramfs hook does not include `flock` command

[Ross Vandegrift]

On Fri, Feb 17, 2023 at 09:54:08PM +0100, Santiago Vila wrote:
> After applying the suggested patch, the reported error
> does not show anymore.
> 
> Instead, I get this:
> 
> /scripts/local-bottom/growroot: line 97: wait-for-root: not found
> 
> Where does this "wait-for-root" come from?
> I can't find it in any package.

There's a relevant MR in salsa:
https://salsa.debian.org/cloud-team/cloud-initramfs-tools/-/merge_requests/2

Would you mind testing the patch there?  I don't know how widely used
this package is.

Thanks,
Ross

Bug#1040406: python3-azure-cli - fails with No module named 'azure.mgmt.compute.v2022_11_01'

[Ross Vandegrift]

Package: azure-cli
Version: 2.45.0-1
Followup-For: Bug #1040406
X-Debbugs-Cc: rvandegr...@debian.org

Hi Luca,

I'm hitting this issue on azure-cli in bookworm.  It sounds like this package
is difficult - but is there any possibility of a stable update?


$ az vm
The command failed with an unexpected error. Here is the traceback:
No module named 'azure.mgmt.compute.v2022_11_01'
...

Thanks,
Ross


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

Kernel: Linux 6.4.0-rc3 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages azure-cli depends on:
ii  python33.11.2-1+b1
ii  python3-azure-cli  2.45.0-1

azure-cli recommends no packages.

azure-cli suggests no packages.

-- no debconf information

Bug#1057548: cloud-init: FTBFS: failing tests

[Ross Vandegrift]

On Tue, Dec 05, 2023 at 11:04:12PM +0100, Santiago Vila wrote:
> During a rebuild of all packages in unstable, your package failed to build:

I started updating to the latest upstream release, which fixes this FTBFS.  But
I'm reluctant to push to the team repo, due to an issue with the network
nocloud datasource.

With a local webserver hosting cloud-init seed data, cloud-init 23.4.3 never
hits my local http server.  The same setup with 23.3.1 from sid works fine.
Disk based nocloud seeds work fine with 23.4.3.

So far, I haven't found any obvious failure - under 23.4.3,
DataSourceNoCloudNet either doesn't run or can't reach the http server.  In
case anyone has time to poke, the new release is pushed to my personal repo at
https://salsa.debian.org/rvandegrift/cloud-init

Ross

Bug#1057548: cloud-init: FTBFS: failing tests

[Ross Vandegrift]

Control: tags -1 pending

On Mon, Feb 19, 2024 at 01:47:24PM -0800, Ross Vandegrift wrote:
> On Tue, Dec 05, 2023 at 11:04:12PM +0100, Santiago Vila wrote:
> > During a rebuild of all packages in unstable, your package failed to build:
> 
> I started updating to the latest upstream release, which fixes this FTBFS.  
> But
> I'm reluctant to push to the team repo, due to an issue with the network
> nocloud datasource.
> 
> With a local webserver hosting cloud-init seed data, cloud-init 23.4.3 never
> hits my local http server.  The same setup with 23.3.1 from sid works fine.
> Disk based nocloud seeds work fine with 23.4.3.

Upstream found and fixed this issue in 23.4.4  But before I could get to
packaging it, they also released 24.1.  I just pushed updates with the new
version to salsa.  The new version is working for me.

I don't have upload access for cloud-init - we can work out an upload at the
team meeting next week.

Ross