Bug#1057548: cloud-init: FTBFS: failing tests
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
Bug#1057548: cloud-init: FTBFS: failing tests
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#1040406: python3-azure-cli - fails with No module named 'azure.mgmt.compute.v2022_11_01'
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#1014662: cloud-initramfs-growroot: Initramfs hook does not include `flock` command
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#979100: Legally problematic GPL-3+ readline dependency
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#968030: e17: FTBFS during combined arch+indep build
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#957160: e17: ftbfs with GCC-10
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#959828: systemctl: `Provides: systemd`, but doesn't provide what systemd does
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#959828: systemctl: `Provides: systemd`, but doesn't provide what systemd does
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#951117: libecore1: .xsession-errors eats all disk space
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#931669: ephoto doesn't even start up
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#922669: sqlalchemy: CVE-2019-7164 CVE-2019-7548 (SQL injection)
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)
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.
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#923889: google-compute-image-packages - DoS via serial console write
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
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#916630: terminology: Remote execution via special escape codes that handle unknown media types
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#900460: ephoto: fails to start
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
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#898384: terminology: focus weirdness in 1.2.0
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#895809: enlightenment: Fails to start
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
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#878572: Bug#895511: exactimage FTBFS with libevas-dev 1.20.7
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#884019: [Pkg-e-devel] Bug#884019: terminology: FTBFS if $HOME is not writable
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
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 Beckmannwrote: > > 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#881155: [Pkg-e-devel] Bug#881155: e17: Won't start correctly any longer, corrupted windows shown
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#878584: [Pkg-e-devel] Bug#878584: [libevas-dev] Missing dependency for libecore-dev
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#878584: [Pkg-e-devel] Bug#878584: [libevas-dev] Missing dependency for libecore-dev
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#878572: exactimage: FTBFS in experimental: gfx/X11Helper.hh:33:10: fatal error: Evas_Engine_Software_X11.h: No such file or directory
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#877180: [Pkg-e-devel] Bug#877180: libector-dev: missing Depends: libector1 (= ${binary:Version})
On Sun, Oct 01, 2017 at 04:02:32PM +0200, Andreas Metzler wrote: > Control: tags -1 patch > > On 2017-09-29 Andreas Beckmannwrote: > > 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#760038: [Pkg-e-devel] Bug#760038: minor problem subsists
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#613752: Registers itself to open PDF and PostScript; ends up as the default
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#571962: azureus: Fails to start with Azureus core already instantiated
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#566208: linux-image-2.6.26-2-486: e_powersaver causes constant lockups
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#560238: netbase: racoon is also broken by net.ipv6.bindv6only change
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#552994: mbrowse: Input handling prevents typing some characters
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#539752: emacs installs, but installs emacs23-nox
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