Bug#1041559: Recommends non-existent package linux-musl-dev

[Josh Triplett]

Package: musl-dev
Version: 1.2.3-1
Severity: serious
X-Debbugs-Cc: j...@joshtriplett.org

musl-dev Recommends linux-musl-dev, which does not appear to exist in
the archive.

Policy 2.2.1 "The main archive area":
> package must not declare a "Pre-Depends", "Depends", "Recommends",
> "Build-Depends", "Build-Depends-Indep", or "Build-Depends-Arch"
> relationship on a non-*main* package unless that package is only
> listed as a non-default alternative for a package in *main*



-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.3.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages musl-dev depends on:
ii  gcc [gcc-x86-64-linux-gnu]  4:13.1.0-4
ii  musl1.2.3-1

Versions of packages musl-dev recommends:
pn  linux-musl-dev  

musl-dev suggests no packages.

-- no debconf information

Bug#1029661: Cannot authenticate with Google

[Josh Triplett]

Package: gcalcli
Version: 4.3.0-1
Severity: grave
Tags: upstream
X-Debbugs-Cc: j...@joshtriplett.org

Google no longer allows gcalcli to authenticate. Upstream recommends
manually creating a developer account and registering gcalcli as your
own app. This is a *much* more cumbersome setup process, and the simple
oauth2 workflow that gcalcli uses by default doesn't work with no
indication of why.

At a minimum, this should be documented and the flow for not having
authenticated yet should give better guidance to the user and not try an
authentication that won't work.

https://github.com/insanum/gcalcli/issues/580


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.1.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcalcli depends on:
ii  python33.11.1-1
ii  python3-dateutil   2.8.2-1
ii  python3-googleapi  1.7.12-1
ii  python3-httplib2   0.20.4-3
ii  python3-oauth2client   4.1.3-3
ii  python3-parsedatetime  2.6-3
ii  python3-six1.16.0-4

Versions of packages gcalcli recommends:
pn  python3-vobject  

gcalcli suggests no packages.

-- no debconf information

Bug#1014901: Home directories should not be setgid by default

[Josh Triplett]

On Thu, Jul 14, 2022 at 04:20:18PM -0400, Matt Barry wrote:
> On Thu, 2022-07-14 at 13:05 -0700, Josh Triplett wrote:
> > The use case below, and any other tools that create files and know to
> > set their permissions appropriately but don't expect unusual
> > ownership
> > by default:
> > > > In particular, it is common to build various kinds of filesystem,
> > > > container, or disk images, and to do so within your home
> > > > directory.
> > > > Users writing tools and scripts to build such images need to make
> > > > sure
> > > > to create files with an appropriate mode, but such scripts often
> > > > assume
> > > > (reasonably) that if they're running as root:root and they create
> > > > a
> > > > file, that file will be owned by root:root. Attempting to build
> > > > filesystems, containers, disk images, or similar in an
> > > > unexpectedly
> > > > setgid directory will produce unexpected results (leaving aside
> > > > that the
> > > > directory mode itself will be surprising).
> 
> Could you be just slightly more specific about a use case that fails? 
> Given how many times this has come up over the years, I'm trying to get
> a sense of what the *actual* issues are (as opposed to what they used
> to be).
> 
> Enough instruction that I can reproduce a specific problem(s) would be
> great.

Sure. Here's a sample of the kind of script I regularly encounter,
producing incorrect results in a setgid directory. The script expects to
produce files owned by root:root, but the files and directories get the
wrong group, and the setgid bit gets propagated to the constructed
filesystem image.

/tmp/testdir$ ls -ld
drwxr-sr-x 2 josh josh 4096 Jul 16 13:40 .
/tmp/testdir$ ls -l
total 4
-rwxr-xr-x 1 josh josh 354 Jul 16 13:40 make-filesystem.sh
/tmp/testdir$ cat make-filesystem.sh
#!/bin/bash
if [ "$(id -u)" -ne 0 ]; then
echo Run as root >&2
exit 1
fi

umask 022

mkdir fsroot fsroot/bin fsroot/etc fsroot/srv
mkdir -m 0700 fsroot/srv/workdir
echo 'nameserver 169.254.169.253' > fsroot/etc/resolv.conf
printf '#!/bin/sh\necho example binary\n' > fsroot/bin/example
chmod a+x fsroot/bin/example

mke2fs -d fsroot root.img 16M
/tmp/testdir$ sudo ./make-filesystem.sh
mke2fs 1.46.5 (30-Dec-2021)
Creating regular file root.img
Creating filesystem with 16384 1k blocks and 4096 inodes
Filesystem UUID: ec2c8666-96d9-4bce-b964-4c32ed098638
Superblock backups stored on blocks:
8193

Allocating group tables: done
Writing inode tables: done
Copying files into the device: done
Writing superblocks and filesystem accounting information: done

/tmp/testdir$ ls -l
total 1196
drwxr-sr-x 5 root josh 4096 Jul 16 13:41 fsroot
-rwxr-xr-x 1 josh josh  354 Jul 16 13:40 make-filesystem.sh
-rw-r--r-- 1 root josh 16777216 Jul 16 13:41 root.img
/tmp/testdir$ mkdir /tmp/testmount
/tmp/testdir$ sudo mount -o loop root.img /tmp/testmount
/tmp/testdir$ sudo ls -lR /tmp/testmount/
/tmp/testmount/:
total 15
drwxr-sr-x 2 root josh  1024 Jul 16 13:41 bin
drwxr-sr-x 2 root josh  1024 Jul 16 13:41 etc
drwx-- 2 root root 12288 Jul 16 13:41 lost+found
drwxr-sr-x 3 root josh  1024 Jul 16 13:41 srv

/tmp/testmount/bin:
total 1
-rwxr-xr-x 1 root josh 30 Jul 16 13:41 example

/tmp/testmount/etc:
total 1
-rw-r--r-- 1 root josh 27 Jul 16 13:41 resolv.conf

/tmp/testmount/lost+found:
total 0

/tmp/testmount/srv:
total 1
drwx--S--- 2 root josh 1024 Jul 16 13:41 workdir

/tmp/testmount/srv/workdir:
total 0

Bug#1002827: Should be in contrib; expects an installation of Steam

[Josh Triplett]

Package: proton-caller
Severity: serious
X-Debbugs-Cc: j...@joshtriplett.org

While portions of Proton are Open Source (being based on the LGPLed
Wine), proton-caller appears to specifically expect an installation of
Steam. The description says "Simply configure your Steam and common
directories", and the upstream documentation similarly talks about
configuring the path to a Steam installation.

- Josh


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

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages proton-caller depends on:
ii  libc6  2.33-1
ii  libgcc-s1  11.2.0-13

proton-caller recommends no packages.

proton-caller suggests no packages.

Bug#998108: reopening 998108

[Josh Triplett]

reopen 998108 94.0-2
thanks

I'm still experiencing this bug regularly, with complete browser UI
freezes that require killing and restarting Firefox.

WebGL or video seems to trigger it more often, as does opening a new
tab. Browsing on an existing tab doesn't tend to trigger it.

Bug#998108: Additional information: tab freezes first, then browser

[Josh Triplett]

Some additional information that might help track this down: several
times, I've observed one tab freezing, but the browser itself is still
responsive for a *short* time. I can open a new tab, and close it again,
and the previous tab then renders as a busy symbol.

I'm wondering if one of the tab processes or helper processes dies, and
then that grinds the browser to a halt but not instantly.

Bug#998108: firefox freezes shortly after start

[Josh Triplett]

On Sat, 30 Oct 2021 15:04:01 +0200 Christoph Anton Mitterer 
 wrote:
> Since about yesterday (possibly since the rebuilt package came in)
> firefox freezes shortly after being started.
> There is no high CPU activity then, it just takes no input anymore
> (no keyboard, no mouse clicks).
> This also happens in --safe-mode.

I'm encountering this as well. It happens slower if I just browse, and
much much faster if I use something like WebGL.

Bug#986268: Should be in non-free, not main; no source code

[Josh Triplett]

Package: firmware-ast
Version: 20140808-1
Severity: serious
X-Debbugs-Cc: j...@joshtriplett.org

firmware-ast is binary-only firmware. The "source code" appears to
consist of a C header file containing a hex dump of a binary, and a
makefile transforming the hex dump into binary.

The previous package, xserver-xorg-video-ast, had a similar bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941077 .

Bug#943037: Status of this bug?

[Josh Triplett]

I'm aware of the upstream update (and appreciate it); I'm asking about
the status of the Debian package for the new version.

On Sun, Nov 15, 2020 at 12:08:42AM +0100, Leandro Lucarella wrote:
> Hi Josh, Version 2.0.0, released recently, supports python3. The Debian 
> package just needs to be updated. You can download a .deb built from the 
> source from here if you can't wait:
> https://bintray.com/sociomantic-tsunami/tools/git-hub
> 
> On 14 November 2020 22:41:02 GMT+01:00, Josh Triplett  
> wrote:
> >What's the current status of this bug? I'd love to have a version of
> >git-hub that doesn't depend on Python 2; it's the last thing on my
> >system that still wants Python 2.
> 
> -- 
> Leandro Lucarella (luca)
> Sent from my phone. Please excuse my brevity and any typos.

Bug#943037: Status of this bug?

[Josh Triplett]

What's the current status of this bug? I'd love to have a version of
git-hub that doesn't depend on Python 2; it's the last thing on my
system that still wants Python 2.

Bug#963177: calendar: trying to overwrite '/etc/calendar/default', which is also in package bsdmainutils 12.1.1

[Josh Triplett]

On Sun, 21 Jun 2020 04:05:43 +0200 Chris Hofstaedtler  wrote:
> Hi Josh,
> 
> I figured you might be interested in this, too, as IIRC the original
> patch was from you:
> 
> * Thorsten Glaser  [200621 02:04]:
> > Selecting previously unselected package calendar.
> > (Reading database ... 406194 files and directories currently installed.)
> > Preparing to unpack .../calendar_12.1.1_x32.deb ...
> > Unpacking calendar (12.1.1) ...
> > dpkg: error processing archive 
> > /var/cache/apt/archives/calendar_12.1.1_x32.deb (--unpack):
> >  trying to overwrite '/etc/calendar/default', which is also in package 
> > bsdmainutils 12.1.1
> > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> > Errors were encountered while processing:
> >  /var/cache/apt/archives/calendar_12.1.1_x32.deb
> > E: Sub-process /usr/bin/dpkg returned an error code (1)

Ah. When I originally sent the patch, I believe I included appropriate
Breaks/Replaces headers to make sure this wouldn't happen, but it looks
like the version that incorporated the patch had advanced past the
version numbers in the Breaks/Replaces. The version numbers in the
Breaks/Replaces need updating.

Bug#874176: wrk: Fails to run with 'PANIC: unprotected error in call to Lua API'

[Josh Triplett]

Package: wrk
Version: 4.0.2-2
Followup-For: Bug #874176

I can confirm that this occurs for me as well; any attempt to run wrk
produces:

PANIC: unprotected error in call to Lua API (attempt to index a nil value)


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

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

Versions of packages wrk depends on:
ii  libc62.30-7
ii  libluajit-5.1-2  2.1.0~beta3+dfsg-5.1
ii  libssl1.11.1.1g-1

wrk recommends no packages.

wrk suggests no packages.

-- no debconf information

Bug#932659: node: modules are not getting detected in a fresh sid chroot environment

[Josh de Kock]

Hi,

This still occurs for me. I have a armhf chroot of Sid. It seems to be
using a node path relative to the current directory (as far as I can
tell). These paths should probably be /usr prefixed (and not relative to
cwd), but I wouldn't know where to begin fixing this.

See my tests below:

root@sid-armhf:/# node -p "require.resolve.paths('y18n')"

[ '/node_modules',
  '/root/.node_modules',
  '/root/.node_libraries',
  '/lib/arm-linux-gnueabihf/nodejs',
  '/share/nodejs',
  '/lib/nodejs' ]
root@sid-armhf:/# su user
$ pwd
/
$ node -p "require.resolve.paths('y18n')"

[ '/node_modules',
  '/home/user/.node_modules',
  '/home/user/.node_libraries',
  '/lib/arm-linux-gnueabihf/nodejs',
  '/share/nodejs',
  '/lib/nodejs' ]
$ cd
$ pwd
/home/user
$ node -p "require.resolve.paths('y18n')"

[ '/home/user/node_modules',
  '/home/node_modules',
  '/node_modules',
  '/home/user/.node_modules',
  '/home/user/.node_libraries',
  '/home/lib/arm-linux-gnueabihf/nodejs',
  '/home/share/nodejs',
  '/home/lib/nodejs' ]
$

-- 
Josh

Bug#945047: Needs dependency for Crypt/Digest/SHA256.pm

[Josh Triplett]

Package: extrepo
Version: 0.2
Severity: serious

Attempting to run extrepo produces:

Can't locate Crypt/Digest/SHA256.pm in @INC (you may need to install the 
Crypt::Digest::SHA256 module) (@INC contains: /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0 
/usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at 
/usr/share/perl5/Debian/ExtRepo/Commands/Enable.pm line 9.
BEGIN failed--compilation aborted at 
/usr/share/perl5/Debian/ExtRepo/Commands/Enable.pm line 9.
Compilation failed in require at 
/usr/share/perl5/Debian/ExtRepo/Commands/Update.pm line 3.
BEGIN failed--compilation aborted at 
/usr/share/perl5/Debian/ExtRepo/Commands/Update.pm line 3.
Compilation failed in require at /usr/bin/extrepo line 7.
BEGIN failed--compilation aborted at /usr/bin/extrepo line 7.

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

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

Versions of packages extrepo depends on:
ii  gpgv  2.2.17-3
ii  libwww-perl   6.41-1
ii  libyaml-perl  1.29-1
ii  perl  5.30.0-9

extrepo recommends no packages.

extrepo suggests no packages.

-- no debconf information

Bug#919914: gnome-tweaks now equates "don't suspend on lid close" with "don't lock on lid close" (security issue)

[Josh Triplett]

Package: gnome-tweaks
Version: 3.30.2-1
Severity: grave
Tags: security

Recently, disabling the setting "Suspend when laptop lid is closed"
seems to have started preventing *any* action on lid close, including
locking the screen; disabling that setting adds a startup file to run
/usr/lib/gnome-tweak-tool/gnome-tweak-tool-lid-inhibitor, which inhibits
*any* action on the lid switch. This is a security issue.

I disable suspend on lid close, but I *always* need the screen to lock
when I close the lid.

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

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

Versions of packages gnome-tweaks depends on:
ii  gir1.2-glib-2.01.58.3-2
ii  gir1.2-gnomedesktop-3.03.30.2-4
ii  gir1.2-gtk-3.0 3.24.3-1
ii  gir1.2-notify-0.7  0.7.7-4
ii  gir1.2-pango-1.0   1.42.4-6
ii  gir1.2-soup-2.42.64.2-2
ii  gnome-settings-daemon  3.30.2-1
ii  gnome-shell-common 3.30.2-1
ii  gsettings-desktop-schemas  3.28.1-1
ii  mutter-common  3.30.2-4
ii  python33.7.2-1
ii  python3-gi 3.30.4-1

gnome-tweaks recommends no packages.

gnome-tweaks suggests no packages.

-- no debconf information

Bug#918854: segfault updating crates.io index

[Josh Triplett]

Package: cargo
Version: 0.31.1-1
Severity: grave

Any time I try to update the crates.io index with the currently packaged
version of cargo, I get a segfault:

$ cargo update
Updating crates.io index
Segmentation fault

I can reproduce this in a brand new project (`cargo new foo`) by adding
any dependency to `Cargo.toml` (e.g. `strsim = "*"`) and then running
`cargo update`.

libgit2 was just updated recently; that might potentially be related.

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

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

Versions of packages cargo depends on:
ii  binutils2.31.1-11
ii  gcc 4:8.2.0-2
ii  gcc-7 [c-compiler]  7.4.0-2
ii  gcc-8 [c-compiler]  8.2.0-14
ii  libc6   2.28-4
ii  libcurl3-gnutls 7.62.0-1
ii  libgcc1 1:8.2.0-14
ii  libgit2-27  0.27.7+dfsg.1-0.1
ii  libssh2-1   1.8.0-2
ii  libssl1.1   1.1.1a-1
ii  rustc   1.31.0+dfsg1-2
ii  zlib1g  1:1.2.11.dfsg-1

cargo recommends no packages.

Versions of packages cargo suggests:
pn  cargo-doc  
ii  python33.7.1-3

-- no debconf information

Bug#913116: Needs to depend on chromium-sandbox

[Josh Triplett]

On Sat, Nov 17, 2018 at 11:15:28AM +, Simon McVittie wrote:
> On Fri, 16 Nov 2018 at 14:19:16 -0800, Josh Triplett wrote:
> > On Fri, 16 Nov 2018 10:20:07 +0100 Bastian Blank  wrote:
> > > Debian does not support unprivileged user namespaces, so chromium needs
> > > to depend on -sandbox to get a working package.
> > 
> > Should we, perhaps, support unprivileged user namespaces? Or, at least,
> > a means of granting targeted permission to use such namespaces without
> > being full root?
> 
> We have this mode available. Sysadmins can select it with:
> 
> sysctl -w kernel.unprivileged_userns_clone=1
> 
> which leads to the same behaviour as upstream kernels, Fedora, and
> recent Ubuntu releases. (Or use /etc/sysctl.d to change this in a
> persistent way.)
> 
> However, Debian's kernel maintainer has indicated that he doesn't consider
> this mechanism to be completely safe (I'm not sure to what extent this is
> still true), hence the current default. Setting up a user namespace gives
> you all capabilities in the namespace (including CAP_SYS_ADMIN, which is
> required if you want to protect part or all of the host system directory
> tree from the namespaced process by playing with mount namespaces and
> bind-mounts, like Flatpak does), so if you suspect the kernel still has
> flaws in which capabilities in non-init user namespaces can be abused
> to get privileged access to the overall system, you can't allow it.

I'm aware of this. And I'm not *necessarily* advocating a change to the
kernel to allow this by default. But perhaps chromium-sandbox could have
some lesser privilege (not full setuid root) that allows it to create an
unprivileged user namespace? bubblewrap and others could do the same.

> Sysadmins who have set kernel.unprivileged_userns_clone=1 can use
> dpkg-statoverride to make bwrap non-setuid, as it is on recent Ubuntu
> systems (the same compiled binary can work either way, since it detects
> which mode to work in at runtime).

We *might* also consider having a configuration package that drops a
unprivileged_userns_clone.conf file into /usr/lib/sysctl.d/ , and
letting packages like chromium depend on
unprivileged-userns-clone | chromium-sandbox.

Bug#913116: Needs to depend on chromium-sandbox

[Josh Triplett]

On Fri, 16 Nov 2018 10:20:07 +0100 Bastian Blank  wrote:
> Debian does not support unprivileged user namespaces, so chromium needs
> to depend on -sandbox to get a working package.

Should we, perhaps, support unprivileged user namespaces? Or, at least,
a means of granting targeted permission to use such namespaces without
being full root?

Bug#913116: chromium

[Josh Triplett]

On Wed, Nov 14, 2018 at 03:35:24PM +0100, Salvo Tomaselli wrote:
> If it can't start without it, it really should depend on it

I get the impression that chromium is *supposed* to work without the
setuid sandbox, if it has the necessary support from the underlying
system to do unprivileged sandboxing.

Bug#913271: segfault - broken rust compiling

[Josh Stone]

There's an ABI incompatibility between LLVM compiled with GCC and Clang:
https://bugs.llvm.org/show_bug.cgi?id=39427

So if you have a Clang-built libLLVM.so, and rustc's src/rustllvm is
built with GCC, then I think you may be hitting this problem.

Bug#913116: Fails to start without chromium-sandbox installed

[Josh Triplett]

Package: chromium
Version: 70.0.3538.67-3
Severity: grave

Without chromium-sandbox installed:

~$ chromium
[10607:10607:1106/214902.149402:FATAL:zygote_host_impl_linux.cc(116)] No usable 
sandbox! Update your kernel or see 
https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md
 for more information on developing with the SUID sandbox. If you want to live 
dangerously and need an immediate workaround, you can try using --no-sandbox.


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

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

Versions of packages chromium depends on:
ii  chromium-common  70.0.3538.67-3
ii  libasound2   1.1.7-1
ii  libatk-bridge2.0-0   2.30.0-2
ii  libatk1.0-0  2.30.0-1
ii  libatomic1   8.2.0-9
ii  libavcodec58 7:4.0.3-1
ii  libavformat587:4.0.3-1
ii  libavutil56  7:4.0.3-1
ii  libc62.27-8
ii  libcairo-gobject21.16.0-1
ii  libcairo21.16.0-1
ii  libcups2 2.2.8-5
ii  libdbus-1-3  1.12.10-1
ii  libdrm2  2.4.95-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.6-1
ii  libflac8 1.3.2-3
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.8.1-2
ii  libgcc1  1:8.2.0-9
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libglib2.0-0 2.58.1-2
ii  libgtk-3-0   3.24.1-2
ii  libharfbuzz0b1.9.0-1
ii  libicu60 60.2-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.20-1
ii  libnss3  2:3.39-1
ii  libopenjp2-7 2.3.0-1
ii  libopus0 1.3~beta+20180518-1
ii  libpango-1.0-0   1.42.4-3
ii  libpangocairo-1.0-0  1.42.4-3
ii  libpci3  1:3.5.2-1
ii  libpng16-16  1.6.34-2
ii  libpulse012.2-2
ii  libre2-4 20180901+dfsg-1
ii  libsnappy1v5 1.1.7-1
ii  libstdc++6   8.2.0-9
ii  libvpx5  1.7.0-3
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libx11-6 2:1.6.7-1
ii  libx11-xcb1  2:1.6.7-1
ii  libxcb1  1.13.1-1
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.15-1
ii  libxdamage1  1:1.1.4-3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-7+b1
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.32-2
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-1

chromium recommends no packages.

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

-- no debconf information

Bug#907518: wpa: problems with openssl 1.1.1

[Josh Triplett]

On Sun, Oct 07, 2018 at 11:00:48AM +0200, Andrej Shadura wrote:
> I’m unsure what can be done to help resolve this issue from the wpa side.

For debugging purposes, I'd still be interested to know this:

> On Wed, 5 Sep 2018 14:57:59 -0700 Josh Triplett 
> wrote:
> > Is there a way I can easily get wpa_supplicant to log the full client
> > and server certificate chain, and flag which *specific* certificate in
> > that chain it has an issue with? I'm trying to present appropriate
> > information to get the wireless network infrastructure improved, and
> > unlike https I can't just use `openssl s_client` to get the details I
> > need.

Bug#909804: Excessive CPU usage at system startup

[Josh Triplett]

Package: gnome-software
Version: 3.28.2-1
Severity: grave

I don't know whether the bug here lies in gnome-software, packagekit, or
some combination of the two.

Every time I start my system, I see packagekit burning a huge amount of
CPU for a minute, and this affects the performance of the system until
it stops.

Corresponding to this, I see a large number of log messages like this:
Sep 28 12:24:38 s PackageKit[717]: search-file transaction /18520_ddabdebb from 
uid 1000 finished with success after 643ms
Sep 28 12:24:39 s PackageKit[717]: search-file transaction /18521_bbebdedd from 
uid 1000 finished with success after 301ms

On my most recent system boot, I see 167 such messages, spanning nearly
a minute worth of 100% CPU.

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

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

Versions of packages gnome-software depends on:
ii  appstream0.12.2-2
ii  apt-config-icons 0.12.2-2
ii  dconf-gsettings-backend [gsettings-backend]  0.30.0-1
ii  gnome-software-common3.28.2-1
ii  gsettings-desktop-schemas3.28.1-1
ii  libappstream-glib8   0.7.12-1
ii  libatk1.0-0  2.30.0-1
ii  libc62.27-6
ii  libcairo21.15.12-1
ii  libfwupd21.1.2-1
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libglib2.0-0 2.58.1-2
ii  libgnome-desktop-3-173.30.1-1
ii  libgspell-1-11.6.1-1
ii  libgtk-3-0   3.24.0-3
ii  libgtk3-perl 0.034-2
ii  libgudev-1.0-0   232-2
ii  libjson-glib-1.0-0   1.4.2-4
ii  libpackagekit-glib2-18   1.1.10-1
ii  libpolkit-gobject-1-00.105-21
ii  libsecret-1-00.18.6-3
ii  libsoup2.4-1 2.64.1-1
ii  packagekit   1.1.10-1
ii  software-properties-gtk  0.96.20.2-1

gnome-software recommends no packages.

Versions of packages gnome-software suggests:
pn  apt-config-icons-hidpi 
pn  fwupd  
pn  gnome-software-plugin-flatpak  
pn  gnome-software-plugin-limba
pn  gnome-software-plugin-snap 

-- no debconf information

Bug#909559: Ships empty zipfile /usr/psychojs.zip

[Josh Triplett]

Package: psychopy
Version: 1.85.3.dfsg-1
Severity: serious

psychopy ships a file in the inappropriate location /usr/psychojs.zip .
This file appears to be an *empty* zipfile. (There's another copy of the
same empty file in
./usr/lib/python2.7/dist-packages/psychopy/psychojs.zip .)

Bug#874526: Keyboard grab doesn't work under Wayland

[Josh Triplett]

On Mon, Jul 02, 2018 at 06:36:54PM +0100, Simon McVittie wrote:
> On Wed, 06 Sep 2017 at 14:58:37 -0700, Josh Triplett wrote:
> > (It might also help to add Ctrl-Alt-Delete to the list of shortcuts
> > provided in the gnome-boxes keyboard menu, alongside Ctrl-Alt-Backspace
> > and similar.)
> 
> This is now provided in the keyboard menu for both gnome-boxes and
> virt-manager.

I appreciate that, thank you. That will help heavily as a workaround.

Bug#874526: Keyboard grab doesn't work under Wayland

[Josh Triplett]

On Mon, Jul 02, 2018 at 06:14:44PM +0100, Simon McVittie wrote:
> On Mon, 02 Jul 2018 at 01:39:24 -0700, Josh Triplett wrote:
> > On Mon, Jul 02, 2018 at 08:14:48AM +0100, Simon McVittie wrote:
> > > This seems to work under GNOME 3.28 (probably also 3.26). I'm prompted
> > > while starting up the VM for whether to allow gnome-boxes to grab the
> > > keyboard. I haven't tried a Windows VM, but if I use the keyboard menu to
> > > switch to a text-mode VT for a Linux VM with Ctrl+Alt+F$n, then either
> > > press Ctrl+Alt+Del or send it via the keyboard menu, the VM reboots
> > > as expected.
> > 
> > I can confirm that I can still reproduce this with current GNOME and
> > gnome-boxes; Ctrl+Alt+Del still goes to GNOME and not to the VM.
> 
> Which versions of gnome-shell, libmutter-2-0, gnome-boxes do you have?

gnome-boxes 3.28.5-1
gnome-shell 3.28.2-1
libmutter-2-0:amd64 3.28.2-2

> Are you prompted for whether to let gnome-boxes inhibit shortcuts? You
> should get a system-modal dialog (the sort that dims the entire screen,
> like the Shut Down dialog you get from Ctrl+Alt+Del itself) something
> like this:
> 
> |--|
> |  Boxes wants to inhibit shortcuts|
> | /!\  |
> |  You can restore shortcuts by pressing Super+Escape. |
> |  |
> |[ Deny ][ Allow ]-|
> 
> (If you don't click Allow then this feature is not expected to work.)

No, I don't get that prompt from gnome-boxes. (I've seen it before from
other applications.)

> Does it help to click inside the virtual machine window before pressing
> Ctrl+Alt+Del?

If I'm in windowed mode, yes.

As far as I can tell, it's possible to end up in a state in which the VM
has the focus but gnome-boxes doesn't have a grab on Ctrl+Alt+Del. This
can happen both in windowed mode and in fullscreen mode. In windowed
mode, if I click in gnome-boxes then a grab takes place and Ctrl+Alt+Del
works.

This may also have something to do with switching windows (via the
overview) away from a VM.

> Does sending Ctrl+Alt+Del via the keyboard menu work?

Yes.

Bug#902375: xserver-xorg-video-abi: versions 6-23 missing from all repos

[Josh Blagden]

Package: xserver-xorg-video-abi-23
Version: 23
Severity: grave
Justification: Renders xserver-xorg-video-nvidia uninstallable

I apologize for my previous faulty bug report. It turns out I was mistaken 
about xserver-xorg-core being the problem. 

It's actually xserver-xorg-video-abi which is the problem. Xserver-xorg-abi is 
a dependency of xserver-xorg-video-nvidia and it's not available, as you'll 
notice here: 
https://packages.debian.org/stretch-backports/xserver-xorg-video-nvidia

I apologize for the lack of terminal output. The Debian machine that I'm 
working on doesn't have a GUI at the moment because I haven't been able to get 
the nvidia-driver package installed. I'm actually typing these bug reports on 
my Mac. 

Regards,
Josh Blagden

> xserver-xorg-video-nvidia requires a version of xserver-xorg-core which isn't 
> available in any Debian branches. It requires xserver-xorg-core version 
> 1.19.99. Stable and Testing only have version 1.19.2, and Unstable has 
> version 1.20.

Bug#902370: xserver-xorg-video-nvidia: Required dependency version missing from Stable and Testing

[Josh Blagden]

Package: xserver-xorg-video-nvidia
Version: 390.48
Severity: grave
Justification: Renders installation impossible



xserver-xorg-video-nvidia requires a version of xserver-xorg-core which isn't 
available in any Debian branches. It requires xserver-xorg-core version 
1.19.99. Stable and Testing only have version 1.19.2, and Unstable has version 
1.20.





Regards,
Joshua Blagden 

Bug#900585: Uninstallable; depends on qemu-system-data (>> ${source:Version})

[Josh Triplett]

Package: qemu-system-x86
Version: 1:2.12+dfsg-2
Severity: serious

The various qemu packages that depend on qemu-system-data do so with
(>> ${source:Version}), which makes them uninstallable. For instance,
qemu-system-x86 1:2.12+dfsg-2 depends on qemu-system-data
(>> 1:2.12+dfsg-2).

Bug#876222: Should be in "contrib", not "main"

[Josh Triplett]

Package: mali-midgard-dkms
Severity: serious

The package description says:

> This provides the kernel module for the ARM Mali 'midgard' GPU series
> in dkms format. This covers the 6xx and 7xx GPU hardware devices. You
> need this kernel module as well the binary drivers to make the
> hardware work.

If that's the case, and this kernel module doesn't do any good without
the binary drivers, then this package should go to "contrib", not
"main".

If this kernel module has uses without the binary drivers (e.g. if it
can be made to work with the reverse-engineered driver instead), then
the description should make that clear.

- Josh Triplett

Bug#874526: Keyboard grab doesn't work under Wayland

[Josh Triplett]

Package: gnome-boxes
Version: 3.25.91-1
Severity: serious

[I don't know whether this bug lies in gnome-boxes or gnome-shell or
some combination of both. Release-critical because this completely
breaks the ability to log into many Windows VMs with gnome-boxes under
the default GNOME Wayland session.]

The mechanism gnome-boxes uses to grab the keyboard doesn't work under
the default GNOME Wayland session. This makes it impossible to send
Ctrl-Alt-Delete; it always goes to gnome-shell instead.

(It might also help to add Ctrl-Alt-Delete to the list of shortcuts
provided in the gnome-boxes keyboard menu, alongside Ctrl-Alt-Backspace
and similar.)

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

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

Versions of packages gnome-boxes depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  libarchive13 3.2.2-2
ii  libc62.24-17
ii  libcairo-gobject21.14.10-1
ii  libcairo21.14.10-1
ii  libgdk-pixbuf2.0-0   2.36.5-4
ii  libglib2.0-0 2.53.6-1
ii  libgovirt2   0.3.4-2
ii  libgtk-3-0   3.22.19-1
ii  libgtk-vnc-2.0-0 0.7.1-1
ii  libgudev-1.0-0   232-1
ii  libosinfo-1.0-0  1.1.0-1
ii  libosinfo-bin1.1.0-1
ii  libpango-1.0-0   1.40.11-1
ii  libpangocairo-1.0-0  1.40.11-1
ii  librest-0.7-00.8.0-2
ii  libsecret-1-00.18.5-3.1
ii  libsoup2.4-1 2.59.90.1-1
ii  libspice-client-glib-2.0-8   0.34-1.1
ii  libspice-client-gtk-3.0-50.34-1.1
ii  libtracker-sparql-1.0-0  1.12.1-1
ii  libusb-1.0-0 2:1.0.21-2
ii  libvirt-daemon   3.6.0-1
ii  libvirt-glib-1.0-0   1.0.0-1
ii  libxml2  2.9.4+dfsg1-4
ii  mtools   4.0.18-2+b1
ii  tracker  1.12.1-1

Versions of packages gnome-boxes recommends:
ii  qemu-system-x86  1:2.8+dfsg-7

gnome-boxes suggests no packages.

-- no debconf information

Bug#873508: sparse test failures on ppc32le (and other not so common archs)

[Josh Triplett]

On Fri, Sep 01, 2017 at 09:57:09AM +0200, Uwe Kleine-König wrote:
> On Fri, Sep 01, 2017 at 12:02:12AM -0700, Josh Triplett wrote:
> > On Thu, Aug 31, 2017 at 08:47:55PM -0400, Christopher Li wrote:
> > > On Thu, Aug 31, 2017 at 4:55 PM, Uwe Kleine-König <uwe@kleine-> Yes
> > > that works. So to address the Debian bug I can do:
> > > >
> > > >  - move sparse to /usr/lib
> > > >  - teach cgcc about the move of sparse
> > > >  - make /usr/bin/sparse call cgcc -no-compile "$@"
> > > 
> > > I don't like that. It means the user can't invoke sparse directly.
> > > 
> > > >
> > > > or is it easier to teach sparse about the architecture stuff?
> > > 
> > > First of all. It is not very trivial to teach sparse about the 
> > > architecture
> > > stuff. To my mind, we need to move all the cgcc logic into sparse.
> > 
> > Related to that: while it would mean we couldn't necessarily just rely
> > entirely on GCC's definitions for a target platform, I think in an ideal
> > world we could have a sparse binary that understood *all* target
> > platforms at once, such that you could ask Sparse on x86_64 to "compile"
> > as though targeting any arbitrary architecture. That would also have the
> > major advantage of making it easy to run the Sparse testsuite for
> > *every* target architecture without needing compilers for every such
> > architecture.
> 
> You'd need the target arch's system headers though.

Only for building userspace code, not for building standalone/kernel
code, or the Sparse testsuite.

- Josh Triplett

Bug#873508: sparse test failures on ppc32le (and other not so common archs)

[Josh Triplett]

On Thu, Aug 31, 2017 at 08:47:55PM -0400, Christopher Li wrote:
> On Thu, Aug 31, 2017 at 4:55 PM, Uwe Kleine-König  Yes
> that works. So to address the Debian bug I can do:
> >
> >  - move sparse to /usr/lib
> >  - teach cgcc about the move of sparse
> >  - make /usr/bin/sparse call cgcc -no-compile "$@"
> 
> I don't like that. It means the user can't invoke sparse directly.
> 
> >
> > or is it easier to teach sparse about the architecture stuff?
> 
> First of all. It is not very trivial to teach sparse about the architecture
> stuff. To my mind, we need to move all the cgcc logic into sparse.

Related to that: while it would mean we couldn't necessarily just rely
entirely on GCC's definitions for a target platform, I think in an ideal
world we could have a sparse binary that understood *all* target
platforms at once, such that you could ask Sparse on x86_64 to "compile"
as though targeting any arbitrary architecture. That would also have the
major advantage of making it easy to run the Sparse testsuite for
*every* target architecture without needing compilers for every such
architecture.

Bug#867340: Contains binary files without corresponding source

[Josh Triplett]

Package: i965-va-driver
Severity: serious

This bug applies to both stretch (1.7.3) and buster/sid (1.8.3).

i965-va-driver contains many binary compiled shaders with no
corresponding source. The Debian package needs to strip them out, which
may require modifying the driver to avoid requiring them.

A quick bit of scripting, to look for files of the form '*.g*b' without
a corresponding '*.asm' or '*.g*a' file, turned up the following list
from 1.8.3:

src/shaders/brc/bsw/hme_downscale_genx_0.g8b
src/shaders/brc/bsw/hme_genx_0.g8b
src/shaders/brc/bsw/vp8_brc_init_genx_0.g8b
src/shaders/brc/bsw/vp8_brc_reset_genx_0.g8b
src/shaders/brc/bsw/vp8_brc_update_genx_0.g8b
src/shaders/brc/bsw/vp8_enc_genx_0.g8b
src/shaders/brc/bsw/vp8_enc_genx_1.g8b
src/shaders/brc/bsw/vp8_enc_genx_2.g8b
src/shaders/brc/bsw/vp8_intra_distortion_genx_0.g8b
src/shaders/brc/bsw/vp8_mpu_genx_0.g8b
src/shaders/brc/bsw/vp8_tpu_genx_0.g8b
src/shaders/brc/skl/hme_downscale_genx_0.g9b
src/shaders/brc/skl/hme_genx_0.g9b
src/shaders/brc/skl/vp8_brc_init_genx_0.g9b
src/shaders/brc/skl/vp8_brc_reset_genx_0.g9b
src/shaders/brc/skl/vp8_brc_update_genx_0.g9b
src/shaders/brc/skl/vp8_enc_genx_0.g9b
src/shaders/brc/skl/vp8_enc_genx_1.g9b
src/shaders/brc/skl/vp8_enc_genx_2.g9b
src/shaders/brc/skl/vp8_intra_distortion_genx_0.g9b
src/shaders/brc/skl/vp8_mpu_genx_0.g9b
src/shaders/brc/skl/vp8_tpu_genx_0.g9b
src/shaders/h264/mc/avc_mc.g4b
src/shaders/post_processing/gen75/sharpening_h_blur.g75b
src/shaders/post_processing/gen75/sharpening_unmask.g75b
src/shaders/post_processing/gen75/sharpening_v_blur.g75b
src/shaders/post_processing/gen8/conv_nv12.g8b
src/shaders/post_processing/gen8/sharpening_h_blur.g8b
src/shaders/post_processing/gen8/sharpening_unmask.g8b
src/shaders/post_processing/gen8/sharpening_v_blur.g8b
src/shaders/post_processing/gen9/conv_nv12.g9b
src/shaders/post_processing/gen9/conv_p010.g9b
src/shaders/post_processing/gen9/pa_to_pa.g9b
src/shaders/post_processing/gen9/pa_to_pl2.g9b
src/shaders/post_processing/gen9/pa_to_pl3.g9b
src/shaders/post_processing/gen9/pl2_to_pa.g9b
src/shaders/post_processing/gen9/pl2_to_pl2.g9b
src/shaders/post_processing/gen9/pl2_to_pl3.g9b
src/shaders/post_processing/gen9/pl2_to_rgbx.g9b
src/shaders/post_processing/gen9/pl3_to_pa.g9b
src/shaders/post_processing/gen9/pl3_to_pl2.g9b
src/shaders/post_processing/gen9/pl3_to_pl3.g9b
src/shaders/post_processing/gen9/rgbx_to_nv12.g9b

1.7.3 contains the following shorter list:

src/shaders/h264/mc/avc_mc.g4b
src/shaders/post_processing/gen75/sharpening_h_blur.g75b
src/shaders/post_processing/gen75/sharpening_unmask.g75b
src/shaders/post_processing/gen75/sharpening_v_blur.g75b
src/shaders/post_processing/gen8/sharpening_h_blur.g8b
src/shaders/post_processing/gen8/sharpening_unmask.g8b
src/shaders/post_processing/gen8/sharpening_v_blur.g8b
src/shaders/post_processing/gen9/pa_to_pa.g9b
src/shaders/post_processing/gen9/pa_to_pl2.g9b
src/shaders/post_processing/gen9/pa_to_pl3.g9b
src/shaders/post_processing/gen9/pl2_to_pa.g9b
src/shaders/post_processing/gen9/pl2_to_pl2.g9b
src/shaders/post_processing/gen9/pl2_to_pl3.g9b
src/shaders/post_processing/gen9/pl2_to_rgbx.g9b
src/shaders/post_processing/gen9/pl3_to_pa.g9b
src/shaders/post_processing/gen9/pl3_to_pl2.g9b
src/shaders/post_processing/gen9/pl3_to_pl3.g9b
src/shaders/post_processing/gen9/rgbx_to_nv12.g9b

Bug#854343: [Pkg-utopia-maintainers] Bug#854343: network-manager: The search domain string in resolv.conf is being duplicated leading to problems with DNS

[Josh Triplett]

On Wed, Feb 08, 2017 at 05:15:56AM +0100, Michael Biebl wrote:
> Am 08.02.2017 um 02:59 schrieb Josh Triplett:
> > On Tue, Feb 07, 2017 at 11:22:19PM +0100, Michael Biebl wrote:
> >> Am 06.02.2017 um 10:14 schrieb Tilo Villwock:
> >>> Package: network-manager
> >>> Version: 1.6.0-1
> >>> Severity: important
> >>> Tags: upstream
> >>>
> >>> Dear Maintainer,
> >>>
> >>> resolving of hostnames stopped working after updating the package and as 
> >>> it
> >>> turns out the search domain string is being duplicated in resolv.conf 
> >>> (e.g.
> >>> 'search domain.orgdomain.org'). Right now I have to configure the 
> >>> connection
> >>> manually to resolve this.
> >>
> >> I can't reproduce the problem.
> >> I tried both the internal dhcp implementation and isc-dhcp-client 
> >> (4.3.5-3).
> >>
> >> Josh, since you raised the severity, I assume you can reproduce the 
> >> problem?
> > 
> > Yes, I have the same issue here at work ("search
> > jf.intel.comjf.intel.com"), and I can reliably reproduce it.
> > 
> >> Would be great to have more information on how to reproduce the problem.
> > 
> > I have isc-dhcp-client 4.3.5-3, and network-manager 1.6.0-1.  Happy to
> > provide additional information.
> > 
> > Have you tested on a network configured to hand out a search domain?
> > Does the search domain include multiple components as "domain.org" and
> > "jf.intel.com" do?
> 
> Works fine here:
> This is from my dnsmasq.conf:
> 
> dhcp-range=192.168.179.50,192.168.179.150,12h
> dhcp-option=option:domain-search,test.example.com,foo.com
> 
> The resulting /etc/resolv.conf
> 
> # Generated by NetworkManager
> search test.example.com foo.com
> nameserver 192.168.179.10

So, interestingly, I can reliably reproduce this on my work network, but
not on VPN (which also provides a search domain, albeit a different
one).

Also, can you test with just a single domain-search rather than two?

- Josh Triplett

Bug#854343: [Pkg-utopia-maintainers] Bug#854343: network-manager: The search domain string in resolv.conf is being duplicated leading to problems with DNS

[Josh Triplett]

On Tue, Feb 07, 2017 at 11:22:19PM +0100, Michael Biebl wrote:
> Am 06.02.2017 um 10:14 schrieb Tilo Villwock:
> > Package: network-manager
> > Version: 1.6.0-1
> > Severity: important
> > Tags: upstream
> > 
> > Dear Maintainer,
> > 
> > resolving of hostnames stopped working after updating the package and as it
> > turns out the search domain string is being duplicated in resolv.conf (e.g.
> > 'search domain.orgdomain.org'). Right now I have to configure the connection
> > manually to resolve this.
> 
> I can't reproduce the problem.
> I tried both the internal dhcp implementation and isc-dhcp-client (4.3.5-3).
> 
> Josh, since you raised the severity, I assume you can reproduce the problem?

Yes, I have the same issue here at work ("search
jf.intel.comjf.intel.com"), and I can reliably reproduce it.

> Would be great to have more information on how to reproduce the problem.

I have isc-dhcp-client 4.3.5-3, and network-manager 1.6.0-1.  Happy to
provide additional information.

Have you tested on a network configured to hand out a search domain?
Does the search domain include multiple components as "domain.org" and
"jf.intel.com" do?

- Josh Triplett

Bug#844785: "not authorised" doing various desktoppy things [and 1 more messages] [and 1 more messages]

[Josh Triplett]

On Tue, 17 Jan 2017 13:35:14 + Ian Jackson 
 wrote:
> [1] AIUI this is when your laptop suspends to RAM, but after a timeout
> or when the battery is low, wakes up so that it can suspend to disk.

Linux implements hybrid sleep by going ahead and writing the hibernation
image out, then suspending to RAM.  That makes it take longer to sleep,
but it doesn't have to wake up later on a timer (likely in an enclosed
bag).  If you wake it up while still suspended to RAM, it can wake up
fast and ignore the hibernation image; if it runs out of battery and
loses power, then when you power it back on it'll resume from the
hibernation image and still not lose state.

Bug#847542: libmozjs-24-0 24.2.0-4 breaks gnome-shell, preventing gdm3 from starting

[Josh Triplett]

Package: libmozjs-24-0
Version: 24.2.0-4
Severity: grave

Control: affects -1 gnome-shell gdm3

libmozjs-24-0 24.2.0-4 causes the following failure in gnome-shell at
startup:

Dec 08 21:05:51 x gnome-shell[581]: JS ERROR: TypeError: imports.ui is undefined
Dec 08 21:05:51 x gnome-shell[581]: Execution of main.js threw exception: 
JS_EvaluateScript() failed
Dec 08 21:05:51 x gnome-session[483]: gnome-session-binary[483]: WARNING: App 
'org.gnome.Shell.desktop' exited with code 1
Dec 08 21:05:51 x gnome-session-binary[483]: WARNING: App 
'org.gnome.Shell.desktop' exited with code 1
Dec 08 21:05:51 x gnome-shell[634]: JS ERROR: TypeError: imports.ui is undefined
Dec 08 21:05:51 x gnome-shell[634]: Execution of main.js threw exception: 
JS_EvaluateScript() failed
Dec 08 21:05:51 x gnome-session-binary[483]: Unrecoverable failure in required 
component org.gnome.Shell.desktop
Dec 08 21:05:51 x gnome-session-binary[483]: WARNING: App 
'org.gnome.Shell.desktop' exited with code 1
Dec 08 21:05:51 x gnome-session[483]: gnome-session-binary[483]: WARNING: App 
'org.gnome.Shell.desktop' exited with code 1
Dec 08 21:05:51 x gnome-session[483]: gnome-session-binary[483]: WARNING: App 
'org.gnome.Shell.desktop' respawning too quickly
Dec 08 21:05:51 x gnome-session-binary[483]: WARNING: App 
'org.gnome.Shell.desktop' respawning too quickly
Dec 08 21:05:51 x gnome-session[483]: Unable to init server: Could not connect: 
Connection refused
Dec 08 21:05:51 x kernel: gnome-session-f[643]: segfault at 0 ip 
7f7eb997ea29 sp 7ffc78c0ce60 error 4 in 
libgtk-3.so.0.2200.4[7f7eb969c000+6f7000]

Downgrading to 24.2.0-3.1 fixes this problem.

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

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

Versions of packages libmozjs-24-0 depends on:
ii  libc6   2.24-8
ii  libffi6 3.2.1-6
ii  libgcc1 1:6.2.1-5
ii  libnspr42:4.12-6
ii  libstdc++6  6.2.1-5

libmozjs-24-0 recommends no packages.

libmozjs-24-0 suggests no packages.

-- no debconf information

Bug#838819: wordpress really needs apache2's mod_rewrite enabled - either as a default, or well documented

[Josh Stern]

Package: wordpress
Version: 4.6.1+dfsg-1
Severity: serious
Tags: d-i
Justification: normal

Dear Maintainer,

I'm a newbie to apache & wordpress, working with testing out wordpress
in a virtual hosts configuration on my own box.  After getting
wordpress up and running, I found that a lot of basic functionality
was not working correctly & it took me a while to track down the
problem.  It turns out that many wordpress packages require a
permalinks setup other than the default to function.  However,
wordpress's ability to find it's own pages with permalinks other than
the default seems to depend on apache2 having mod_rewrite enabled,
which was not true of the default installation, & seemingly not well
documented by wordpress, either online or on the debian system.
Ideally this info should appear as part of a prominent README and
perhaps be configured by the wordpress package installation.   I
understand that mod_rewrite may be considered a minor security risk,
but seemingly one accepts that with the decision to use the wordpress
package.


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

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

Versions of packages wordpress depends on:
ii  apache2 [httpd] 2.4.23-4
ii  ca-certificates 20160104
ii  libapache2-mod-php  1:7.0+44
ii  libapache2-mod-php7.0 [libapache2-mod-php]  7.0.10-1
ii  libjs-cropper   1.2.2-1
ii  libphp-phpmailer5.2.14+dfsg-2
ii  mariadb-client  10.0.27-1
ii  php-gd  1:7.0+44
ii  php-getid3  1.9.12+dfsg-1
ii  php-mysql   1:7.0+44
ii  php7.0 [php]7.0.10-1
ii  php7.0-gd [php-gd]  7.0.10-1
ii  php7.0-mysql [php-mysqlnd]  7.0.10-1

Versions of packages wordpress recommends:
ii  wordpress-l10n 4.6.1+dfsg-1

ii  wordpress-theme-twentysixteen  4.6.1+dfsg-1

Versions of packages wordpress suggests:
pn  mysql-server  
pn  php-ssh2  

-- no debconf information

Bug#836426: Caused by libgtk-3-0 3.21

[Josh Triplett]

Control: tags 836426 + upstream
Control: forwarded 836426 https://bugzilla.gnome.org/show_bug.cgi?id=771739

On Tue, Sep 20, 2016 at 08:13:43PM +0200, Michael Biebl wrote:
> Am 20.09.2016 um 19:38 schrieb Josh Triplett:
> > On Thu, Sep 08, 2016 at 01:48:01PM +0200, Michael Biebl wrote:
> >> As for gnome-boxes, can you reproduce the problem with 3.21.3 from
> >> unstable? I just tested a local installation of debian 8.5 and that
> >> worked fine. I don't have  windows ISO to test whether that is
> >> reproducible with that setup.
> > 
> > I can confirm that this bug in libgtk-3-0 still affects gnome-boxes
> > 3.22.0-1 from latest sid.  (Tested with libgtk-3-0 3.21.6-1 .)
> > Downgrading libgtk-3-0 from 3.21.6-1 to 3.20.9-1 allows gnome-boxes to
> > render correctly again.
> > 
> > You might be able to reproduce this problem if you run the QXL graphics
> > driver (xserver-xorg-video-qxl) in the guest, and potentially the guest
> > agent as well.
> > 
> > I can reliably reproduce this with a Windows VM running the QXL driver
> > and guest agent.
> 
> Please file such issues upstream.

Done.

Bug#836426: Caused by libgtk-3-0 3.21

[Josh Triplett]

On Thu, Sep 08, 2016 at 01:48:01PM +0200, Michael Biebl wrote:
> As for gnome-boxes, can you reproduce the problem with 3.21.3 from
> unstable? I just tested a local installation of debian 8.5 and that
> worked fine. I don't have  windows ISO to test whether that is
> reproducible with that setup.

I can confirm that this bug in libgtk-3-0 still affects gnome-boxes
3.22.0-1 from latest sid.  (Tested with libgtk-3-0 3.21.6-1 .)
Downgrading libgtk-3-0 from 3.21.6-1 to 3.20.9-1 allows gnome-boxes to
render correctly again.

You might be able to reproduce this problem if you run the QXL graphics
driver (xserver-xorg-video-qxl) in the guest, and potentially the guest
agent as well.

I can reliably reproduce this with a Windows VM running the QXL driver
and guest agent.

- Josh Triplett

Bug#836426: Caused by libgtk-3-0 3.21

[Josh Triplett]

On Thu, Sep 08, 2016 at 01:48:01PM +0200, Michael Biebl wrote:
> Am 08.09.2016 um 03:23 schrieb Josh Triplett:
> > It seems appropriate for an issue that causes window contents to fail to
> > render, making gnome-boxes unusable with that version of GTK+.  
> 
> The emacs warnings don't look critical and are most likely something
> which needs to be addressed in emacs.

I don't know the associated impact of those; if they're *just* a warning
with no other impact, then perhaps.

> As for gnome-boxes, can you reproduce the problem with 3.21.3 from
> unstable? I just tested a local installation of debian 8.5 and that
> worked fine. I don't have  windows ISO to test whether that is
> reproducible with that setup.

I'll test gnome-boxes 3.21.3 next week.

However, it seems like a compatibility issue if upgrading to a new
libgtk-3-0 with the same SONAME breaks applications that worked with a
previous version.  Other than rare circumstances like "application doing
something always clearly documented as broken and old versions let them
get away with it", which might *occasionally* be justifiable if it
doesn't cause significant breakage in practice, generally that kind of
compatibility issue seems like a bug in the library, not the
application.

> I think it would be best if you file this issue upstream at the
> gnome-boxes bug tracker
> https://bugzilla.gnome.org/enter_bug.cgi?product=gnome-boxes

Before reporting it there, I'd need to confirm that 1) the bug still
appears with gnome-boxes 3.21.3 and 2) the bug actually lies in
gnome-boxes rather than in libgtk-3-0.

Bug#836426: Caused by libgtk-3-0 3.21

[Josh Triplett]

On Thu, Sep 08, 2016 at 02:24:37AM +0200, Michael Biebl wrote:
> On Wed, 7 Sep 2016 09:21:55 -0700 Josh Triplett <j...@joshtriplett.org>
> wrote:
> > Control: reassign -1 libgtk-3-0 3.21.5-3
> > Control: affects -1 gnome-boxes
> > Control: severity -1 serious
> > Control: forcemerge -1 832077
> 
> To me those two issues look not like they are related.
> 
> After all, this one was file for 3.20, the other one for 3.21.

Both bugs were filed for libgtk-3-0 3.21.  (836426 was originally filed
on gnome-boxes 3.20 but running with libgtk-3-0 3.21, and I can confirm
that the issue disappears when downgrading to libgtk-3-0 3.20 and
reappears when upgrading to libgtk-3-0 3.21.  All three mails in 832077
specifically mentioned libgtk-3-0 3.21.)  None of the reports apply to
libgtk-3-0 3.20.

I changed the applicable version number when reassigning to libgtk-3-0,
and as far as I can tell that did update the BTS metadata correctly.

> The severity seems overinflated as well.

It seems appropriate for an issue that causes window contents to fail to
render, making gnome-boxes unusable with that version of GTK+.  It also
seems appropriate for what looks like a backwards-compatibility issue in
GTK+.  "serious" seems appropriate for "this shouldn't get released in
the next stable release".

Bug#834367: systemctl daemon-reexec (as run on systemd upgrade) causes all keystrokes to go to text console in addition to X (including passwords)

[Josh Triplett]

On Mon, Aug 15, 2016 at 07:58:09PM +0200, Vincent Bernat wrote:
>  ❦ 15 août 2016 00:53 CEST, Josh Triplett <j...@joshtriplett.org> :
> 
> > [Severity and tag due to the likely possibility of exposing user
> > passwords this way.  If this occurs with the version in jessie as well,
> > it'll require a security update.]
> 
> I think this is fairly recent. I stumbled upon your bug report while
> searching why Alt + "left arrow" switched to another VT. It started to
> happen to me today. Therefore, I think this only happens with 231-2 but
> not with 231-1 (assuming this is the same cause).

I could reproduce it with both 231-1 and 231-2.  I suspect you started
seeing it when you upgraded from 231-1 to 231-2, causing a
daemon-reexec, and then Alt-Left went to the text console in addition to
X, causing it to change VTs.

I had a similar experience: hitting Ctrl-Alt-Del rebooted directly
rather than opening a GNOME dialog, because it went to the console.

- Josh Triplett

Bug#834367: systemctl daemon-reexec (as run on systemd upgrade) causes all keystrokes to go to text console in addition to X (including passwords)

[Josh Triplett]

Package: systemd
Version: 231-2
Severity: critical
Tags: security

[Severity and tag due to the likely possibility of exposing user
passwords this way.  If this occurs with the version in jessie as well,
it'll require a security update.]

After running "systemctl daemon-reexec" from within an X session, all
keystrokes in the X session (including passwords) appear on the
underlying text console as well.  They show up during the shutdown
process, or any other time X stops.

Since systemd's postinst runs "systemctl daemon-reexec" on upgrades,
this would occur in any session after upgrading the systemd package.

I can reliably reproduce this, either by upgrading or downgrading the
systemd package, or by running "systemctl daemon-reexec" (as root).

This might potentially explain the mention in bug 819500 of seeing
usernames and passwords on the console, as well.  This would only happen
in a session after upgrading systemd or otherwise running "systemctl
daemon-reexec", which would explain not seeing it every time.

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser 3.115
ii  libacl1 2.2.52-3
ii  libapparmor12.10.95-4
ii  libaudit1   1:2.6.5-1
ii  libblkid1   2.28-6
ii  libc6   2.23-4
ii  libcap2 1:2.25-1
ii  libcap2-bin 1:2.25-1
ii  libcryptsetup4  2:1.7.0-2
ii  libgcrypt20 1.7.2-2
ii  libgpg-error0   1.24-1
ii  libidn111.33-1
ii  libkmod222-1.1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmount1   2.28-6
ii  libpam0g1.1.8-3.3
ii  libseccomp2 2.3.1-2
ii  libselinux1 2.5-3
ii  libsystemd0 231-2
ii  mount   2.28-6
ii  util-linux  2.28-6

Versions of packages systemd recommends:
ii  dbus1.10.8-1
ii  libpam-systemd  231-2

Versions of packages systemd suggests:
ii  policykit-10.105-16
pn  systemd-container  
pn  systemd-ui 

Versions of packages systemd is related to:
ii  udev  231-2

-- no debconf information

Bug#798421: NMU uploaded to DELAYED/7-day

[Josh Triplett]

Control: tags -1 + pending

David Bremner (CCed) uploaded this NMU to DELAYED/7-day.

Bug#798421: Updated NMU changelog patch

[Josh Triplett]

In the previous version, I didn't explicitly document dropping the
associated Build-Depends on ca-certificates.  The attached version does
so.

- Josh Triplett
>From af01c459ac527710e2bc841eb12c81a806cdccc7 Mon Sep 17 00:00:00 2001
From: Josh Triplett <j...@joshtriplett.org>
Date: Fri, 18 Mar 2016 17:09:59 -0700
Subject: [PATCH 2/2] debian/changelog: Add entry for 0.23.1-1.1 NMU

---
 debian/changelog | 9 +
 1 file changed, 9 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index a5e437c..d97ae5d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+libgit2 (0.23.1-1.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Don't depend on OpenSSL, either directly or indirectly. Build with and
+depend on libcurl4-gnutls-dev instead. (Closes: #798421)
+  * Drop associated Build-Depends on ca-certificates.
+
+ -- Josh Triplett <j...@joshtriplett.org>  Fri, 18 Mar 2016 17:08:00 -0700
+
 libgit2 (0.23.1-1) unstable; urgency=medium
 
   * New upstream release 0.23.1.
-- 
2.7.0

Bug#798421: Patch and NMU

[Josh Triplett]

Control: tags -1 + patch

I've attached a patch fixing this bug, as well as a patch adding a
changelog entry for an 0.23.1-1.1 NMU.

- Josh Triplett
>From d010b82b89dff56ed6a32127af79f66b68769d44 Mon Sep 17 00:00:00 2001
From: Josh Triplett <j...@joshtriplett.org>
Date: Fri, 18 Mar 2016 17:06:45 -0700
Subject: [PATCH 1/2] Build with and depend on libcurl4-gnutls-dev (Closes:
 #798421)

---
 debian/control | 6 +++---
 debian/rules   | 2 ++
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 06b458e..a0ce1fc 100644
--- a/debian/control
+++ b/debian/control
@@ -3,8 +3,8 @@ Section: libs
 Priority: extra
 Maintainer: Russell Sim <russell@gmail.com>
 Build-Depends: debhelper (>= 9.20120417), python-minimal (>= 2.4.0), pkg-config,
-   cmake, libz-dev, libcurl4-openssl-dev, libssl-dev,
-   libssh2-1-dev, libhttp-parser-dev, ca-certificates
+   cmake, libz-dev, libcurl4-gnutls-dev,
+   libssh2-1-dev, libhttp-parser-dev
 Standards-Version: 3.9.6
 Homepage: http://libgit2.github.com/
 Vcs-Git: git://anonscm.debian.org/users/arrsim-guest/libgit2.git
@@ -16,7 +16,7 @@ Architecture: any
 Section: libdevel
 Multi-Arch: same
 Depends: libgit2-23 (= ${binary:Version}), libz-dev,
- libcurl4-openssl-dev, libssl-dev, libssh2-1-dev,
+ libcurl4-gnutls-dev, libssh2-1-dev,
  libhttp-parser-dev, ${shlibs:Depends}, ${misc:Depends}
 Description: low-level Git library (development files)
  libgit2 is a portable, pure C implementation of the Git
diff --git a/debian/rules b/debian/rules
index e82f178..72436f3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,6 +14,7 @@ TEST_TMPDIR := $(CURDIR)/tmp-test
 override_dh_auto_configure:
 	dh_auto_configure --builddirectory=build-debian-release -- \
 		-DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo \
+		-DUSE_OPENSSL:BOOL=OFF \
 		-DTHREADSAFE:BOOL=ON \
 		-DBUILD_CLAR:BOOL=ON \
 		-DLIB_INSTALL_DIR:STRING=lib/$(DEB_HOST_MULTIARCH)
@@ -21,6 +22,7 @@ override_dh_auto_configure:
 	dh_auto_configure --builddirectory=build-debian-devel -- \
 		-DCMAKE_BUILD_TYPE:STRING=Release \
 		-DTHREADSAFE:BOOL=ON \
+		-DUSE_OPENSSL:BOOL=OFF \
 		-DBUILD_CLAR:BOOL=OFF \
 		-DBUILD_SHARED_LIBS:BOOL=OFF \
 		-DLIB_INSTALL_DIR:STRING=lib/$(DEB_HOST_MULTIARCH)
-- 
2.7.0

>From 9f526442408f078a9e1dc2bf0e6fe1f416585caa Mon Sep 17 00:00:00 2001
From: Josh Triplett <j...@joshtriplett.org>
Date: Fri, 18 Mar 2016 17:09:59 -0700
Subject: [PATCH 2/2] debian/changelog: Add entry for 0.23.1-1.1 NMU

---
 debian/changelog | 8 
 1 file changed, 8 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index a5e437c..da8a307 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+libgit2 (0.23.1-1.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Don't depend on OpenSSL, either directly or indirectly. Build with and
+depend on libcurl4-gnutls-dev instead. (Closes: #798421)
+
+ -- Josh Triplett <j...@joshtriplett.org>  Fri, 18 Mar 2016 17:08:00 -0700
+
 libgit2 (0.23.1-1) unstable; urgency=medium
 
   * New upstream release 0.23.1.
-- 
2.7.0

Bug#817857: util-linux: Depends/Breaks loop with Essential packages prevents upgrade from Jessie

[Josh Triplett]

Package: util-linux
Version: 2.27.1-5
Severity: serious

Even with util-linux 2.27.1-5, I still hit a dependency loop that caused
apt to refuse to proceed:

util-linux 2.27.1-5 Depends on init-system-helpers (>= 1.29~)
init-system-helpers 1.29 Breaks sysvinit-utils (< 2.88dsf-59.3~)
sysvinit-utils 2.88dsf-59.3 Breaks util-linux (< 2.26.2-3)

sysvinit-utils and util-linux are both Essential.

Result:

~$ sudo apt install util-linux
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  init-system-helpers libfdisk1 sysvinit-utils
Suggested packages:
  bootlogd sash dosfstools kbd | console-tools util-linux-locales
The following NEW packages will be installed:
  libfdisk1
The following packages will be upgraded:
  init-system-helpers sysvinit-utils util-linux
3 upgraded, 1 newly installed, 0 to remove and 11 not upgraded.
Need to get 0 B/1198 kB of archives.
After this operation, 930 kB of additional disk space will be used.
Do you want to continue? [Y/n]
E: This installation run will require temporarily removing the essential 
package sysvinit-utils:amd64 due to a Conflicts/Pre-Depends loop. This is often 
bad, but if you really want to do it, activate the APT::Force-LoopBreak option.
E: Internal Error, Could not early remove sysvinit-utils:amd64 (2)

Bug#816224: Depends on faac in non-free

[Josh Triplett]

Package: pulseaudio-dlna
Version: 0.4.7+git2016024-1
Severity: serious

pulseaudio-dlna, in main, has a dependency on faac, in non-free.

I'd suggest working with upstream to switch to ffmpeg's aac encoder
instead; this will also likely improve quality and performance.

- Josh Triplett

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

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

Bug#805113: CVE-2015-8126: buffer overflow

[Josh Triplett]

Package: libpng12-0
Version: 1.2.50-2+b2
Severity: critical
Tags: security upstream

Quoting https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-8126
> Multiple buffer overflows in the (1) png_set_PLTE and (2) png_get_PLTE
> functions in libpng before 1.0.64, 1.1.x and 1.2.x before 1.2.54, 1.3.x and
> 1.4.x before 1.4.17, 1.5.x before 1.5.24, and 1.6.x before 1.6.19 allow remote
> attackers to cause a denial of service (application crash) or possibly have
> unspecified other impact via a small bit-depth value in an IHDR (aka image
> header) chunk in a PNG image.

In particular, "1.1.x and 1.2.x before 1.2.54".

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

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

Versions of packages libpng12-0 depends on:
ii  libc6  2.19-22
ii  multiarch-support  2.19-22
ii  zlib1g 1:1.2.8.dfsg-2+b1

libpng12-0 recommends no packages.

libpng12-0 suggests no packages.

-- no debconf information

Bug#798421: Please don't depend specifically on the OpenSSL variant of Curl

[Josh Triplett]

On Wed, Sep 09, 2015 at 12:53:42PM +1000, Russell Sim wrote:
> On 9 September 2015 at 12:37, Josh Triplett <j...@joshtriplett.org> wrote:
> 
> > I'd like to use libgit2 for projects under the GPL.  Would you please
> > consider either building libgit2 against the gnutls version of Curl, or
> > otherwise making it possible to avoid building with OpenSSL, for the
> > benefit of GPLed projects?
> >
> 
> Fair call, this should be pretty straight forward.  I thought it was
> required for threading, but this doesn't seem to be the case.
> 
> A new version will be released shortly, I can move to the gnutls version of
> curl then.
> 
> Thanks for looking into this.

Any update on this issue?

- Josh Triplett

Bug#789118: Cannot unlock screen after upgrading GNOME if locked before upgrade

[Josh Triplett]

Package: gnome-shell
Version: 3.16.3-2+b1
Followup-For: Bug #789118

I just encountered this problem again, and in addition to the repeated
authentication failure messages, I also saw a message on the lock screen
matching this one I later found in logs:

gnome-session[551]: (gnome-shell:956): Gjs-WARNING **: JS ERROR: Failed to 
start verification for user: Gio.DBusError: 
GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: 
GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Type of message, 
'(sssb)', does not match expected type '(sssbb)'

This occurred after the following package upgrades prior to locking the
screen:

[UPGRADE] gir1.2-gtk-3.0:amd64 3.18.1-1 -> 3.18.1-2
[UPGRADE] libgail-3-0:amd64 3.18.1-1 -> 3.18.1-2
[UPGRADE] libgtk-3-0:amd64 3.18.1-1 -> 3.18.1-2
[UPGRADE] libgtk-3-bin:amd64 3.18.1-1 -> 3.18.1-2
[UPGRADE] libgtk-3-common:amd64 3.18.1-1 -> 3.18.1-2
[UPGRADE] gdm3:amd64 3.14.2-2 -> 3.18.0-1
[UPGRADE] gir1.2-gdm3:amd64 3.14.2-2 -> 3.18.0-1
[UPGRADE] libgdm1:amd64 3.14.2-2 -> 3.18.0-1

I'd guess the upgrade of gdm3 caused this issue.

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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  evolution-data-server3.18.0-3
ii  gir1.2-accountsservice-1.0   0.6.40-3
ii  gir1.2-atspi-2.0 2.18.0-1
ii  gir1.2-caribou-1.0   0.4.18.1-1
ii  gir1.2-clutter-1.0   1.24.0-1
ii  gir1.2-freedesktop   1.46.0-1
ii  gir1.2-gcr-3 3.18.0-1
ii  gir1.2-gdesktopenums-3.0 3.18.0-1
ii  gir1.2-gdm3  3.18.0-1
ii  gir1.2-gkbd-3.0  3.6.0-1
ii  gir1.2-glib-2.0  1.46.0-1
ii  gir1.2-gnomebluetooth-1.03.18.0-1
ii  gir1.2-gnomedesktop-3.0  3.16.2-2
ii  gir1.2-gtk-3.0   3.18.1-2
ii  gir1.2-gweather-3.0  3.18.0-1
ii  gir1.2-ibus-1.0  1.5.10-1
ii  gir1.2-mutter-3.03.16.3-1
ii  gir1.2-networkmanager-1.01.0.6-1
ii  gir1.2-nmgtk-1.0 1.0.6-2
ii  gir1.2-pango-1.0 1.38.0-3
ii  gir1.2-polkit-1.00.105-12
ii  gir1.2-soup-2.4  2.52.0-1
ii  gir1.2-telepathyglib-0.120.24.1-1
ii  gir1.2-telepathylogger-0.2   0.8.1-1
ii  gir1.2-upowerglib-1.00.99.3-1+b2
ii  gjs  1.43.3-2
ii  gnome-backgrounds3.18.0-1
ii  gnome-icon-theme-symbolic3.12.0-1
ii  gnome-settings-daemon3.16.3-1
ii  gnome-shell-common   3.16.3-2
ii  gnome-themes-standard3.18.0-1
ii  gsettings-desktop-schemas3.18.0-1
ii  libatk-bridge2.0-0   2.18.0-1
ii  libatk1.0-0  2.18.0-1
ii  libc62.19-22
ii  libcairo21.14.2-2
ii  libcanberra-gtk3-0   0.30-2.1
ii  libcanberra0 0.30-2.1
ii  libclutter-1.0-0 1.24.0-1
ii  libcogl-pango20  1.22.0-1
ii  libcogl201.22.0-1
ii  libcroco30.6.8-3+b1
ii  libdbus-glib-1-2 0.102-1
ii  libecal-1.2-19   3.18.0-3
ii  libedataserver-1.2-213.18.0-3
ii  libgcr-base-3-1  3.18.0-1
ii  libgdk-pixbuf2.0-0   2.32.1-1
ii  libgirepository-1.0-11.46.0-1
ii  libgjs0e [libgjs0-libmozjs-24-0] 1.43.3-2
ii  libglib2.0-0 2.46.0-2
ii  libgstreamer1.0-01.6.0-1
ii  libgtk-3-0   3.18.1-2
ii  libical1a1.0.1-0.1
ii  libjson-glib-1.0-0   1.0.4-2
ii  libmozjs-24-024.2.0-3
ii  libmutter0f  3.16.3-1
ii  libnm-glib4  1.0.6-1
ii  libnm-util2  1.0.6-1
ii  libpango-1.0-0   1.38.0-3
ii  libpangocairo-1.0-0  1.38.0-3
ii  

Bug#800617: Fails to provide secrets

[Josh Triplett]

Package: gnome-keyring
Version: 3.18.0-1
Severity: grave

Since upgrading gnome-keyring from 3.16.0-4 to 3.18.0-1, applications
trying to retrieve secrets from gnome-keyring no longer can.  I see log
messages like the following:

Oct 01 10:36:37 jtriplet-mobl1 gnome-keyring-daemon[5801]: couldn't access 
control socket: /run/user/1000/keyring/control: No such file or directory
Oct 01 10:36:37 jtriplet-mobl1 gnome-session[5731]: ** Message: couldn't access 
control socket: /run/user/1000/keyring/control: No such file or directory
Oct 01 10:36:37 jtriplet-mobl1 gnome-keyring-daemon[5803]: couldn't access 
control socket: /run/user/1000/keyring/control: No such file or directory
Oct 01 10:36:37 jtriplet-mobl1 gnome-session[5731]: ** Message: couldn't access 
control socket: /run/user/1000/keyring/control: No such file or directory
[...]
Oct 01 10:36:38 jtriplet-mobl1 gnome-keyring-daemon[5808]: couldn't register in 
session: Timeout was reached
Oct 01 10:36:38 jtriplet-mobl1 gnome-keyring-daemon[5803]: couldn't communicate 
with already running daemon: Timeout was reached
Oct 01 10:36:38 jtriplet-mobl1 gnome-session[5731]: ** Message: couldn't 
communicate with already running daemon: Timeout was reached
Oct 01 10:36:38 jtriplet-mobl1 gnome-session[5731]: 
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
Oct 01 10:36:39 jtriplet-mobl1 gnome-keyring-daemon[5844]: couldn't register in 
session: Timeout was reached
[...]
Oct 01 10:37:03 jtriplet-mobl1 gnome-keyring-daemon[5808]: couldn't request 
name 'org.freedesktop.secrets' on session bus: Timeout was reached
[...]
Oct 01 10:48:34 jtriplet-mobl1 org.gnome.evolution.dataserver.Sources4[5783]: 
server_side_source_credentials_lookup_cb: Failed to lookup password: Error 
calling StartServiceByName for org.freedesktop.secrets: Timeout was reached
Oct 01 10:48:35 jtriplet-mobl1 org.gnome.seahorse.Application[5783]: 
(seahorse:8293): seahorse-WARNING **: gkr-backend.vala:85: couldn't connect to 
secret service: Error calling StartServiceByName for org.freedesktop.secrets: 
Timeout was reached

In addition to that, it also looks like every time an application tries to
access the org.freedesktop.secrets service, dbus spawns an instance of
gnome-keyring with the --foreground option, likely based on
/usr/share/dbus-1/services/org.freedesktop.secrets.service ; does this conflict
with the instance already run via /etc/xdg/autostart?

- Josh Triplett

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

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

Versions of packages gnome-keyring depends on:
ii  dbus-x11 1.10.0-3
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gcr  3.16.0-1
ii  libc62.19-22
ii  libcap-ng0   0.7.7-1
ii  libcap2-bin  1:2.24-11
ii  libgck-1-0   3.16.0-1
ii  libgcr-base-3-1  3.16.0-1
ii  libgcrypt20  1.6.3-2
ii  libglib2.0-0 2.46.0-2
ii  p11-kit  0.23.1-3
ii  pinentry-gnome3  0.9.5-4

Versions of packages gnome-keyring recommends:
ii  libpam-gnome-keyring  3.18.0-1

gnome-keyring suggests no packages.

-- no debconf information

Bug#800617: Fails to provide secrets

[Josh Triplett]

On Fri, Oct 02, 2015 at 12:39:36AM +0200, Michael Biebl wrote:
> Control: tags -1 moreinfo unreproducible
> 
> Am 01.10.2015 um 19:54 schrieb Josh Triplett:
> > Package: gnome-keyring
> > Version: 3.18.0-1
> > Severity: grave
> > 
> > Since upgrading gnome-keyring from 3.16.0-4 to 3.18.0-1, applications
> > trying to retrieve secrets from gnome-keyring no longer can.  I see log
> > messages like the following:
> > 
> > Oct 01 10:36:37 jtriplet-mobl1 gnome-keyring-daemon[5801]: couldn't access 
> > control socket: /run/user/1000/keyring/control: No such file or directory
> > Oct 01 10:36:37 jtriplet-mobl1 gnome-session[5731]: ** Message: couldn't 
> > access control socket: /run/user/1000/keyring/control: No such file or 
> > directory
> > Oct 01 10:36:37 jtriplet-mobl1 gnome-keyring-daemon[5803]: couldn't access 
> > control socket: /run/user/1000/keyring/control: No such file or directory
> > Oct 01 10:36:37 jtriplet-mobl1 gnome-session[5731]: ** Message: couldn't 
> > access control socket: /run/user/1000/keyring/control: No such file or 
> > directory
> > [...]
> > Oct 01 10:36:38 jtriplet-mobl1 gnome-keyring-daemon[5808]: couldn't 
> > register in session: Timeout was reached
> > Oct 01 10:36:38 jtriplet-mobl1 gnome-keyring-daemon[5803]: couldn't 
> > communicate with already running daemon: Timeout was reached
> > Oct 01 10:36:38 jtriplet-mobl1 gnome-session[5731]: ** Message: couldn't 
> > communicate with already running daemon: Timeout was reached
> > Oct 01 10:36:38 jtriplet-mobl1 gnome-session[5731]: 
> > SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
> > Oct 01 10:36:39 jtriplet-mobl1 gnome-keyring-daemon[5844]: couldn't 
> > register in session: Timeout was reached
> > [...]
> > Oct 01 10:37:03 jtriplet-mobl1 gnome-keyring-daemon[5808]: couldn't request 
> > name 'org.freedesktop.secrets' on session bus: Timeout was reached
> > [...]
> > Oct 01 10:48:34 jtriplet-mobl1 
> > org.gnome.evolution.dataserver.Sources4[5783]: 
> > server_side_source_credentials_lookup_cb: Failed to lookup password: Error 
> > calling StartServiceByName for org.freedesktop.secrets: Timeout was reached
> > Oct 01 10:48:35 jtriplet-mobl1 org.gnome.seahorse.Application[5783]: 
> > (seahorse:8293): seahorse-WARNING **: gkr-backend.vala:85: couldn't connect 
> > to secret service: Error calling StartServiceByName for 
> > org.freedesktop.secrets: Timeout was reached
> > 
> > In addition to that, it also looks like every time an application tries to
> > access the org.freedesktop.secrets service, dbus spawns an instance of
> > gnome-keyring with the --foreground option, likely based on
> > /usr/share/dbus-1/services/org.freedesktop.secrets.service ; does this 
> > conflict
> > with the instance already run via /etc/xdg/autostart?
> > 
> 
> Works fine here. Is this maybe a D-Bus problem? Do you use
> dbus-user-session/kdbus? Any custom config?

No custom configuration, and not using kdbus or dbus-user-session.  It
certainly seems possible that the fault lies with DBus; any additional
information I could supply to evaluate that?

- Josh triplett

Bug#800617: Fails to provide secrets

[Josh Triplett]

On Thu, Oct 01, 2015 at 04:27:01PM -0700, Josh Triplett wrote:
> On Fri, Oct 02, 2015 at 12:39:36AM +0200, Michael Biebl wrote:
> > Control: tags -1 moreinfo unreproducible
> > 
> > Am 01.10.2015 um 19:54 schrieb Josh Triplett:
> > > Package: gnome-keyring
> > > Version: 3.18.0-1
> > > Severity: grave
> > > 
> > > Since upgrading gnome-keyring from 3.16.0-4 to 3.18.0-1, applications
> > > trying to retrieve secrets from gnome-keyring no longer can.  I see log
> > > messages like the following:
> > > 
> > > Oct 01 10:36:37 jtriplet-mobl1 gnome-keyring-daemon[5801]: couldn't 
> > > access control socket: /run/user/1000/keyring/control: No such file or 
> > > directory
> > > Oct 01 10:36:37 jtriplet-mobl1 gnome-session[5731]: ** Message: couldn't 
> > > access control socket: /run/user/1000/keyring/control: No such file or 
> > > directory
> > > Oct 01 10:36:37 jtriplet-mobl1 gnome-keyring-daemon[5803]: couldn't 
> > > access control socket: /run/user/1000/keyring/control: No such file or 
> > > directory
> > > Oct 01 10:36:37 jtriplet-mobl1 gnome-session[5731]: ** Message: couldn't 
> > > access control socket: /run/user/1000/keyring/control: No such file or 
> > > directory
> > > [...]
> > > Oct 01 10:36:38 jtriplet-mobl1 gnome-keyring-daemon[5808]: couldn't 
> > > register in session: Timeout was reached
> > > Oct 01 10:36:38 jtriplet-mobl1 gnome-keyring-daemon[5803]: couldn't 
> > > communicate with already running daemon: Timeout was reached
> > > Oct 01 10:36:38 jtriplet-mobl1 gnome-session[5731]: ** Message: couldn't 
> > > communicate with already running daemon: Timeout was reached
> > > Oct 01 10:36:38 jtriplet-mobl1 gnome-session[5731]: 
> > > SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
> > > Oct 01 10:36:39 jtriplet-mobl1 gnome-keyring-daemon[5844]: couldn't 
> > > register in session: Timeout was reached
> > > [...]
> > > Oct 01 10:37:03 jtriplet-mobl1 gnome-keyring-daemon[5808]: couldn't 
> > > request name 'org.freedesktop.secrets' on session bus: Timeout was reached
> > > [...]
> > > Oct 01 10:48:34 jtriplet-mobl1 
> > > org.gnome.evolution.dataserver.Sources4[5783]: 
> > > server_side_source_credentials_lookup_cb: Failed to lookup password: 
> > > Error calling StartServiceByName for org.freedesktop.secrets: Timeout was 
> > > reached
> > > Oct 01 10:48:35 jtriplet-mobl1 org.gnome.seahorse.Application[5783]: 
> > > (seahorse:8293): seahorse-WARNING **: gkr-backend.vala:85: couldn't 
> > > connect to secret service: Error calling StartServiceByName for 
> > > org.freedesktop.secrets: Timeout was reached
> > > 
> > > In addition to that, it also looks like every time an application tries to
> > > access the org.freedesktop.secrets service, dbus spawns an instance of
> > > gnome-keyring with the --foreground option, likely based on
> > > /usr/share/dbus-1/services/org.freedesktop.secrets.service ; does this 
> > > conflict
> > > with the instance already run via /etc/xdg/autostart?
> > > 
> > 
> > Works fine here. Is this maybe a D-Bus problem? Do you use
> > dbus-user-session/kdbus? Any custom config?
> 
> No custom configuration, and not using kdbus or dbus-user-session.  It
> certainly seems possible that the fault lies with DBus; any additional
> information I could supply to evaluate that?

Some further investigation produced interesting results.

With ps, I observed two separate gnome-keyring-daemon processes running
with --components=secrets (in addition to those for ssh and pkcs11).
One sat in the same group as the other components, while the other
appeared to have launched separately and used --foreground, consistent
with getting dynamically launched from DBus.

If I killed the process launched with --foreground, and re-attempted
something that looked for secrets, the process with --foreground
reappeared, and I still couldn't obtain those secrets.

However, if I killed the process launched *without* --foreground first,
then the one launched with --foreground, and re-attempted something that
looked for secrets, the process with --foreground reappeared and I could
obtain the secrets successfully.

So, it looks like those two processes conflicted.  Somehow, programs
looking for the secrets interface couldn't talk to the
gnome-keyring-daemon process launched as part of the session, only the
one launched by dbus; and the one launched by dbus didn't work until I
stopped the one launched as part of the session first.

- Josh Triplett

Bug#798421: Please don't depend specifically on the OpenSSL variant of Curl

[Josh Triplett]

On Fri, 18 Sep 2015 03:21:59 -0700 Ben Longbons <brlongb...@gmail.com> wrote:
> None of this solve the legal problems with OpenSSL, but they're kinda
> probably planning relicensing soon ...

To Apache 2.0, which will provide GPLv3 compatibility but not GPLv2
compatibility.  (Still an improvement, though.)

- Josh Triplett

Bug#798421: Please don't depend specifically on the OpenSSL variant of Curl

[Josh Triplett]

On Wed, 9 Sep 2015 12:53:42 +1000 Russell Sim <russell@gmail.com> wrote:
> On 9 September 2015 at 12:37, Josh Triplett <j...@joshtriplett.org> wrote:
> 
> > I'd like to use libgit2 for projects under the GPL.  Would you please
> > consider either building libgit2 against the gnutls version of Curl, or
> > otherwise making it possible to avoid building with OpenSSL, for the
> > benefit of GPLed projects?
> >
> 
> Fair call, this should be pretty straight forward.  I thought it was
> required for threading, but this doesn't seem to be the case.
> 
> A new version will be released shortly, I can move to the gnutls version of
> curl then.

Any update on this bug?

- Josh Triplett

Bug#788708: iceweasel: GStreamer causes segmentation fault

[Josh Triplett]

On Fri, 21 Aug 2015 10:43:56 +0100 Tim-Philipp =?ISO-8859-1?Q?M=FCller?= 
<t@zen.co.uk> wrote:
> This looks at first glance like some GStreamer element(s) could not be
> created, such as appsink, maybe others too; possibly because the
> required GStreamer plugins are not installed. Combined with insufficient
> error handling.
> 
> I note that this bug was reported against an iceweasel version that uses
> the old and unmaintained GStreamer 0.10.x.
> 
> The current iceweasel version uses GStreamer 1.x, and I can't reproduce
> this problem with 38.2.0esr-1 either.

I can reproduce this problem with 38.2.1esr-1 in unstable as well as
40.0.3-1 in experimental.  Vising any page embedding video (including
YouTube or Twitter) crashes Iceweasel as soon as the video would start
to play.

I have gstreamer1.0-plugins-base 1.4.5-2,
gstreamer1.0-plugins-{good,bad,ugly} 1.4.5-2+b2, and gstreamer1.0-libav
1.4.5-3.

- Josh Triplett

Bug#792002: lvm2-monitor service causes long delay at boot (encrypted root/swap)

[Josh Triplett]

On Sun, Jul 19, 2015 at 09:19:04PM +0200, Bastian Blank wrote:
 On Wed, Jul 15, 2015 at 09:48:23AM -0700, j...@joshtriplett.org wrote:
  I just saw the bug again; looks like it's non-deterministic.  There was
  a delay of more than a minute on lvm2-monitor.service.
 
 Can you show the output of systemctl status dm-event.service, or
 better the whole journal, in such case?

As in, wait for the problme to reproduce, then provide the log from that
boot?

Sure, I can do that.

- Josh Triplett


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

Bug#778039: Patch for GCC 5 build issue

[Josh Gadeken]

tags 778039 + patch
thanks

Here's a fix for the GCC 5 build issue. I added 
-Wno-error=format-security to the GNUmakefile. The package 
successfully builds and links using GCC 5 with this change.


It looks like GCC 5 / gobjc 5 sets -Werror=format-security by default. 
Please see the Environment variables section at

https://wiki.debian.org/Hardening#Environment_variables for more info.

--
Josh Gadeken
Linux for HP Helion OpenStack, Hewlett-Packard
Description: Fix GCC 5 build error. 
  Add -Wno-error=format-security to ADDITIONAL_CFLAGS and ADDITIONAL_OBJCFLAGS.

Author: Josh Gadeken josh.gade...@hp.com
Bug-Debian: https://bugs.debian.org/778058

--- oolite-1.77.1.orig/GNUmakefile
+++ oolite-1.77.1/GNUmakefile
@@ -33,8 +33,8 @@ ifeq ($(GNUSTEP_HOST_OS),mingw32)
 else
 ADDITIONAL_INCLUDE_DIRS  = -Isrc/SDL -Isrc/Core -Isrc/BSDCompat -Isrc/Core/Scripting -Isrc/Core/Materials -Isrc/Core/Entities -Isrc/Core/OXPVerifier -Isrc/Core/Debug -Isrc/Core/Tables
 ADDITIONAL_OBJC_LIBS = -lgnustep-base -lstdc++
-ADDITIONAL_CFLAGS= -Wall -DLINUX -DNEED_STRLCPY
-ADDITIONAL_OBJCFLAGS = -Wall -std=c99 -DLOADSAVEGUI -DLINUX -DXP_UNIX -Wno-import
+ADDITIONAL_CFLAGS= -Wall -DLINUX -DNEED_STRLCPY -Wno-error=format-security
+ADDITIONAL_OBJCFLAGS = -Wall -std=c99 -DLOADSAVEGUI -DLINUX -DXP_UNIX -Wno-import -Wno-error=format-security
 oolite_LIB_DIRS  += -L/usr/X11R6/lib/
 ifeq ($(use_deps),yes)
 oolite_LIB_DIRS  += -Ldeps/Linux-deps/$(HOST_ARCH)/lib_linker

Bug#778058: Patch for GCC 5 build issue

[Josh Gadeken]

tags 778058 + patch
thanks

Here's a fix for the GCC 5 build issue. I added 
-Wno-error=format-security to the GNUmakefile. The package 
successfully builds and links using GCC 5 with this change.


It looks like GCC 5 / gobjc 5 sets -Werror=format-security by default. 
Please see the Environment variables section at

https://wiki.debian.org/Hardening#Environment_variables for more info.

--
Josh Gadeken
Linux for HP Helion OpenStack, Hewlett-Packard
Description: Fix GCC 5 build error. 
  Add -Wno-error=format-security to ADDITIONAL_CFLAGS and ADDITIONAL_OBJCFLAGS.

Author: Josh Gadeken josh.gade...@hp.com
Bug-Debian: https://bugs.debian.org/778058

--- oolite-1.77.1.orig/GNUmakefile
+++ oolite-1.77.1/GNUmakefile
@@ -33,8 +33,8 @@ ifeq ($(GNUSTEP_HOST_OS),mingw32)
 else
 ADDITIONAL_INCLUDE_DIRS  = -Isrc/SDL -Isrc/Core -Isrc/BSDCompat -Isrc/Core/Scripting -Isrc/Core/Materials -Isrc/Core/Entities -Isrc/Core/OXPVerifier -Isrc/Core/Debug -Isrc/Core/Tables
 ADDITIONAL_OBJC_LIBS = -lgnustep-base -lstdc++
-ADDITIONAL_CFLAGS= -Wall -DLINUX -DNEED_STRLCPY
-ADDITIONAL_OBJCFLAGS = -Wall -std=c99 -DLOADSAVEGUI -DLINUX -DXP_UNIX -Wno-import
+ADDITIONAL_CFLAGS= -Wall -DLINUX -DNEED_STRLCPY -Wno-error=format-security
+ADDITIONAL_OBJCFLAGS = -Wall -std=c99 -DLOADSAVEGUI -DLINUX -DXP_UNIX -Wno-import -Wno-error=format-security
 oolite_LIB_DIRS  += -L/usr/X11R6/lib/
 ifeq ($(use_deps),yes)
 oolite_LIB_DIRS  += -Ldeps/Linux-deps/$(HOST_ARCH)/lib_linker

Bug#778058: Patch submitted for wrong bug

[Josh Gadeken]

tags 778058 - patch
thanks

Sorry, I accidentally submitted this patch to the wrong bug number.

--
Josh Gadeken
Linux for HP Helion OpenStack, Hewlett-Packard


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

Bug#792002: lvm2-monitor service causes long delay at boot (encrypted root/swap)

[josh]

On Fri, Jul 10, 2015 at 09:44:40AM -0700, Josh Triplett wrote:
 On Fri, Jul 10, 2015 at 09:53:01AM +0200, Peter Rajnoha wrote:
  On 07/10/2015 01:48 AM, Josh Triplett wrote:
   Package: lvm2
   Version: 2.02.122-1
   Severity: grave
   File: /lib/systemd/system/lvm2-monitor.service
   
   On a laptop with encrypted root and swap, I now get a minutes-long delay 
   at boot
   time, due to lvm2-monitor.  Here's the complete set of messages at boot
   (transcribed from a photo of the screen):
   
   Loading, please wait...
 /run/lvm/lvmetad.socket: connect failed: No such file or directory
 WARNING: Failed to connect to lvmetad. Falling back to internal 
   scanning.
 Volume group data not found
 Cannot process volume group data
   Unable to find LVM volume data/root
 /run/lvm/lvmetad.socket: connect failed: No such file or directory
 WARNING: Failed to connect to lvmetad. Falling back to internal 
   scanning.
 Volume group data not found
 Cannot process volume group data
   Unable to find LVM volume data/swap
   Please unlock disk sda2_crypt:
 /run/lvm/lvmetad.socket: connect failed: No such file or directory
 WARNING: Failed to connect to lvmetad. Falling back to internal 
   scanning.
 Reading all physical volumes.  This may take a while...
 Found volume group data using metadata type lvm2
 /run/lvm/lvmetad.socket: connect failed: No such file or directory
 WARNING: Failed to connect to lvmetad. Falling back to internal 
   scanning.
 2 logical volume(s) in volume group data now active
   cryptsetup: sda2_crypt set up successfully
   fsck from util-linux 2.26.2
   /dev/mapper/data-root: clean, [...]
   [  ] A start job is running for Monitoring of LVM2 mirrors, snapshots 
   etc. using dmeventd or progress polling (59s / no limit)
   
   
   That last line matches the description in lvm2-monitor.service.
   
   (The preceeding lvm2 errors may or may not be related.  The recurring
   two lines of lvmetad errors are new, as is the long delay on
   lvm2-monitor.service; the errors before unlocking the disk about not
   finding data/root and data/swap occurred with previous versions of
   lvm2.)
  
  If initrd is generated, the existing lvm.conf needs to be modified
  so the configuration is suitable for initrd environment (where I
  suppose lvmetad daemon is not running). So the script generating
  initrd needs to modify lvm.conf so that use_lvmetad=0 is used.
  
  In case lvmetad daemon is not running in initrd, which is, I suppose,
  exactly the case here - running lvmetad (the LVM metadata caching
  daemon) is not quite useful in initrd anyway as lvmetad would need
  to be started again after switching to root fs.
  
  So that's probably the first problem here.
  
  If those falling back to internal scanning messages appear
  even after switching to root fs,
 
 The above are the only such messages I see on each boot.
 
  please check if lvm2-lvmetad.socket
  is enabled (so it can instantiate lvm2-lvmetad.service on
  first socket access):
  
  systemctl status lvm2-lvmetad.socket
 
 It's active (running) on the booted system.
 
  If it's disabled then the distro needs to make sure it's always
  enabled so whenever use_lvmetad=1 is used, the lvm2-lvmetad.service
  can be instantiated automatically.
  
  Let's check these things first before debugging the lvm2-monitor.service
  delay...
 
 I just booted the system again, and the delay seems to have gone away.
 I don't know if that means it's non-deterministic, or if it only happens
 on the first boot after upgrade.  If it's the latter, this is still a
 bug, but not an RC one.

I just saw the bug again; looks like it's non-deterministic.  There was
a delay of more than a minute on lvm2-monitor.service.

- Josh Triplett


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

Bug#778020: Patch for GCC 5 build issue

[Josh Gadeken]

tags 778020 + patch
thanks

Here's a fix for the GCC 5 build issue. I added -std=gnu89 to 
CMakeLists.txt. The package builds and links with GCC 5 with this change.


Upstream may prefer to move to C99 instead, please see section
Different semantics for inline functions at
https://gcc.gnu.org/gcc-5/porting_to.html for more background.

--
Josh Gadeken
Linux for HP Helion OpenStack, Hewlett-Packard
Description: Resolve GCC5 build errors.
 Add -std=gnu89 to CMAKE_C_FLAGS in CMakeLists.txt
 .
 mz (0.40-1.1) UNRELEASED; urgency=medium
 .
   * Non-maintainer upload.
   * Resolve GCC5 build errors.
Author: Joshua Gadeken josh.gade...@hp.com

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: vendor|upstream|other, url of original patch
Bug: url in upstream bugtracker
Bug-Debian: https://bugs.debian.org/bugnumber
Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
Forwarded: no|not-needed|url proving that it has been forwarded
Reviewed-By: name and email of someone who approved the patch
Last-Update: -MM-DD

--- mz-0.40.orig/CMakeLists.txt
+++ mz-0.40/CMakeLists.txt
@@ -5,7 +5,7 @@ if(COMMAND cmake_policy)
 	cmake_policy(SET CMP0003 NEW)
 endif(COMMAND cmake_policy)
 
-SET(CMAKE_C_FLAGS -Wall -pipe -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fasynchronous-unwind-tables)
+SET(CMAKE_C_FLAGS -Wall -pipe -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fasynchronous-unwind-tables -std=gnu89)
 
 ADD_CUSTOM_TARGET(uninstall
 	COMMAND ${CMAKE_COMMAND} -E echo Use 'xargs rm  install_manifest.txt' to uninstall this program

Bug#791964: gdm3: upgrade causes X session to be terminated

[Josh Triplett]

On Fri, Jul 10, 2015 at 06:46:18PM +0200, Michael Biebl wrote:
 Am 10.07.2015 um 18:38 schrieb Josh Triplett:
  On Fri, Jul 10, 2015 at 02:37:49PM +0200, Michael Biebl wrote:
  Control: severity -1 serious
 
  Am 09.07.2015 um 20:14 schrieb David Mohr:
  Package: gdm3
  Version: 3.14.2-1
  Severity: normal
 
  Dear Maintainer,
 
  the changelog reads:
* Systemd has been fixed in v222 to no longer kill services on reload
  if BusName is set, so drop that part from 92_systemd_unit.patch.
  but that is EXACTLY what happened to me right now, in the middle of
 
  Right. Subsequent reloads of gdm3.service should no longer kill
  gdm3.service though. So this was indeed fixed in v222 but there seems to
  be a specific issue for the upgrade path.
  Once gdm3 has been restarted, a reload no longer causes it to be killed.
  
  Note, though, that it doesn't help for systemd to be upgraded first.
  Even if running the new systemd 222, upgrading gdm3 kills the active
  session.
 
 Well, that's exactly what I said, right?

You said seems to be a specific issue for the upgrade path, and I
didn't know whether you meant the upgrade path for gdm3, systemd, or
both.  Just wanted to make sure.

- Josh Triplett


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

Bug#791964: gdm3: upgrade causes X session to be terminated

[Josh Triplett]

On Fri, Jul 10, 2015 at 02:37:49PM +0200, Michael Biebl wrote:
 Control: severity -1 serious
 
 Am 09.07.2015 um 20:14 schrieb David Mohr:
  Package: gdm3
  Version: 3.14.2-1
  Severity: normal
  
  Dear Maintainer,
  
  the changelog reads:
* Systemd has been fixed in v222 to no longer kill services on reload
  if BusName is set, so drop that part from 92_systemd_unit.patch.
  but that is EXACTLY what happened to me right now, in the middle of
 
 Right. Subsequent reloads of gdm3.service should no longer kill
 gdm3.service though. So this was indeed fixed in v222 but there seems to
 be a specific issue for the upgrade path.
 Once gdm3 has been restarted, a reload no longer causes it to be killed.

Note, though, that it doesn't help for systemd to be upgraded first.
Even if running the new systemd 222, upgrading gdm3 kills the active
session.

 I'm not yet quite sure, if this is a gdm or systemd bug and whether the
 best course of action is to simply re-introduce the workaround patch and
 drop that in stretch+1 or if we drop the reload from gdm3.postinst or if
 this indeed another corner case which is not handled properly in systemd.

For a short-term fix, how about quickly re-introducing the gdm3
workaround?  Then, we can experiment with possible ways to drop it and
(more) carefully test the upgrade paths with packages that haven't been
uploaded yet, and subsequently with experimental.

- Josh Triplett


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

Bug#792002: lvm2-monitor service causes long delay at boot (encrypted root/swap)

[Josh Triplett]

On Fri, Jul 10, 2015 at 09:53:01AM +0200, Peter Rajnoha wrote:
 On 07/10/2015 01:48 AM, Josh Triplett wrote:
  Package: lvm2
  Version: 2.02.122-1
  Severity: grave
  File: /lib/systemd/system/lvm2-monitor.service
  
  On a laptop with encrypted root and swap, I now get a minutes-long delay at 
  boot
  time, due to lvm2-monitor.  Here's the complete set of messages at boot
  (transcribed from a photo of the screen):
  
  Loading, please wait...
/run/lvm/lvmetad.socket: connect failed: No such file or directory
WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
Volume group data not found
Cannot process volume group data
  Unable to find LVM volume data/root
/run/lvm/lvmetad.socket: connect failed: No such file or directory
WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
Volume group data not found
Cannot process volume group data
  Unable to find LVM volume data/swap
  Please unlock disk sda2_crypt:
/run/lvm/lvmetad.socket: connect failed: No such file or directory
WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
Reading all physical volumes.  This may take a while...
Found volume group data using metadata type lvm2
/run/lvm/lvmetad.socket: connect failed: No such file or directory
WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
2 logical volume(s) in volume group data now active
  cryptsetup: sda2_crypt set up successfully
  fsck from util-linux 2.26.2
  /dev/mapper/data-root: clean, [...]
  [  ] A start job is running for Monitoring of LVM2 mirrors, snapshots 
  etc. using dmeventd or progress polling (59s / no limit)
  
  
  That last line matches the description in lvm2-monitor.service.
  
  (The preceeding lvm2 errors may or may not be related.  The recurring
  two lines of lvmetad errors are new, as is the long delay on
  lvm2-monitor.service; the errors before unlocking the disk about not
  finding data/root and data/swap occurred with previous versions of
  lvm2.)
 
 If initrd is generated, the existing lvm.conf needs to be modified
 so the configuration is suitable for initrd environment (where I
 suppose lvmetad daemon is not running). So the script generating
 initrd needs to modify lvm.conf so that use_lvmetad=0 is used.
 
 In case lvmetad daemon is not running in initrd, which is, I suppose,
 exactly the case here - running lvmetad (the LVM metadata caching
 daemon) is not quite useful in initrd anyway as lvmetad would need
 to be started again after switching to root fs.
 
 So that's probably the first problem here.
 
 If those falling back to internal scanning messages appear
 even after switching to root fs,

The above are the only such messages I see on each boot.

 please check if lvm2-lvmetad.socket
 is enabled (so it can instantiate lvm2-lvmetad.service on
 first socket access):
 
 systemctl status lvm2-lvmetad.socket

It's active (running) on the booted system.

 If it's disabled then the distro needs to make sure it's always
 enabled so whenever use_lvmetad=1 is used, the lvm2-lvmetad.service
 can be instantiated automatically.
 
 Let's check these things first before debugging the lvm2-monitor.service
 delay...

I just booted the system again, and the delay seems to have gone away.
I don't know if that means it's non-deterministic, or if it only happens
on the first boot after upgrade.  If it's the latter, this is still a
bug, but not an RC one.

- Josh Triplett


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

Bug#792002: lvm2-monitor service causes long delay at boot (encrypted root/swap)

[Josh Triplett]

Package: lvm2
Version: 2.02.122-1
Severity: grave
File: /lib/systemd/system/lvm2-monitor.service

On a laptop with encrypted root and swap, I now get a minutes-long delay at boot
time, due to lvm2-monitor.  Here's the complete set of messages at boot
(transcribed from a photo of the screen):

Loading, please wait...
  /run/lvm/lvmetad.socket: connect failed: No such file or directory
  WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
  Volume group data not found
  Cannot process volume group data
Unable to find LVM volume data/root
  /run/lvm/lvmetad.socket: connect failed: No such file or directory
  WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
  Volume group data not found
  Cannot process volume group data
Unable to find LVM volume data/swap
Please unlock disk sda2_crypt:
  /run/lvm/lvmetad.socket: connect failed: No such file or directory
  WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
  Reading all physical volumes.  This may take a while...
  Found volume group data using metadata type lvm2
  /run/lvm/lvmetad.socket: connect failed: No such file or directory
  WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
  2 logical volume(s) in volume group data now active
cryptsetup: sda2_crypt set up successfully
fsck from util-linux 2.26.2
/dev/mapper/data-root: clean, [...]
[  ] A start job is running for Monitoring of LVM2 mirrors, snapshots etc. 
using dmeventd or progress polling (59s / no limit)


That last line matches the description in lvm2-monitor.service.

(The preceeding lvm2 errors may or may not be related.  The recurring
two lines of lvmetad errors are new, as is the long delay on
lvm2-monitor.service; the errors before unlocking the disk about not
finding data/root and data/swap occurred with previous versions of
lvm2.)

- Josh Triplett

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

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

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.99-1
ii  dmsetup   2:1.02.99-1
ii  init-system-helpers   1.23
ii  initscripts   2.88dsf-59.2
ii  libc6 2.19-18
ii  libdevmapper-event1.02.1  2:1.02.99-1
ii  libdevmapper1.02.12:1.02.99-1
ii  libreadline5  5.2+dfsg-3
ii  libudev1  222-1
ii  lsb-base  4.1+Debian13+nmu1

lvm2 recommends no packages.

Versions of packages lvm2 suggests:
pn  thin-provisioning-tools  none

-- 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#789118: No issues with clean upgrade

[Josh Triplett]

On Fri, Jun 26, 2015 at 11:42:44AM +0200, Emilio Pozuelo Monfort wrote:
 Control: found -1 3.14.4-1
 
 On 22/06/15 02:36, Michel Dänzer wrote:
  On 22.06.2015 03:39, Josh Triplett wrote:
  On Sun, Jun 21, 2015 at 07:52:10PM +0200, Michael Biebl wrote:
  Am 20.06.2015 um 08:54 schrieb Michel Dänzer:
  On Thu, 18 Jun 2015 21:19:20 +0400 George Hertz george...@gmail.com 
  wrote:
  I've just upgraded to 3.16 on unstable, but restarted the system right 
  after the update finished.
 
  No problems unlocking.
 
  Yeah, the problem only occurs with a gnome-shell which is already
  running during the upgrade.
 
  However, the problem also occurs when only locking the session after the
  upgrade has completed.
 
  One possible workaround after the upgrade is
 
   killall -HUP gnome-shell gnome-settings-daemon
 
  I didn't know you could HUP gnome-shell to unlock the session; that's
  useful to know.
 
  Sending SIGHUP to gnome-shell only is enough to be able to unlock the
  session, but gnome-settings-daemon also needs to be restarted, or some
  things such as keyboard shortcuts don't work properly in the new
  gnome-shell.
 
  Unfortuantely we don't have a proper mechanism to restart programs in
  the desktop session. Using killall in postinst is something I'd be wary
  about.
 
  It's also not OK to unexpectedly unlock someone's session due to a
  concurrent upgrade; can't unlock my session is bad, but unlocked my
  screen during upgrade is a critical security bug.
  
  SIGHUP doesn't unlock the session, it just makes gnome-shell restart
  itself, after which the upgraded version of gnome-shell runs and
  unlocking the session works normally.
 
 This bug is preventing testing migration, which is causing a lot of other bugs
 because of version mismatches between gtk+, gnome-settings-daemon and
 mutter/gnome-shell (see e.g. #789618, #789891, #789866, #789725, #789575,
 #789484...). I've talked about it to some team members and we agreed that this
 is RC, but that it'd be better to let gnome-shell migrate for the time being. 
 So
 I'm doing some trick to let it migrate, but we'll fix this.

I wouldn't be surprised if the bug exists in previous versions of
gnome-shell as well, so allowing migration to testing seems fine.  (Or
actually, it's not obvious whether the bug exists in current versions,
as it's the previous version which failed to unlock after upgrade.)  The
new version likely isn't any more broken than the old; it's the upgrade
that's broken, and preventing that upgrade indefinitely doesn't make the
problem go away.

(Also, those other bugs seem to indicate that either the interactions
between those components need to be made less fragile, or package
dependencies need to prevent installing incompatible versions.)

 Josh, any chance you can try the SIGHUP approach and confirm that solves your
 problem and doesn't cause any other undesired effect?

I've tested sending a SIGHUP to gnome-shell, and that approach causes
several significant undesired effects.

1) Sending SIGHUP to gnome-shell momentarily drops the screen lock.
This reveals the applications behind the screen lock, and even allows
interacting with them.  (For a fraction of a second, sure, but still,
that's a security issue.)

2) If gnome-shell restarts twice in the same session, the second time it
puts up the Oh no! dialog, which only allows the user to restart their
session, losing anything they have open.  So if gnome-shell has
already restarted once in the user's session for unrelated reasons,
sending SIGHUP to it will force the user to restart their session
entirely and lose any open applications.

Based on the above, I think it'd be an extremely bad idea to send SIGHUP
to a user's gnome-shell from a maintainer script.

I think it's going to be necessary to teach gnome-shell to handle screen
unlocking after an upgrade.  I've forwarded this bug upstream to
https://bugzilla.gnome.org/show_bug.cgi?id=751544 .

- Josh Triplett


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

Bug#789118: No issues with clean upgrade

[Josh Triplett]

On Sun, Jun 21, 2015 at 07:52:10PM +0200, Michael Biebl wrote:
 Am 20.06.2015 um 08:54 schrieb Michel Dänzer:
  On Thu, 18 Jun 2015 21:19:20 +0400 George Hertz george...@gmail.com wrote:
  I've just upgraded to 3.16 on unstable, but restarted the system right 
  after the update finished.
 
  No problems unlocking.
  
  Yeah, the problem only occurs with a gnome-shell which is already
  running during the upgrade.
  
  However, the problem also occurs when only locking the session after the
  upgrade has completed.
  
  One possible workaround after the upgrade is
  
  killall -HUP gnome-shell gnome-settings-daemon

I didn't know you could HUP gnome-shell to unlock the session; that's
useful to know.

  Sending SIGHUP to gnome-shell only is enough to be able to unlock the
  session, but gnome-settings-daemon also needs to be restarted, or some
  things such as keyboard shortcuts don't work properly in the new
  gnome-shell.
 
 Unfortuantely we don't have a proper mechanism to restart programs in
 the desktop session. Using killall in postinst is something I'd be wary
 about.

It's also not OK to unexpectedly unlock someone's session due to a
concurrent upgrade; can't unlock my session is bad, but unlocked my
screen during upgrade is a critical security bug.

 Unless someone finds a way to make gnome-shell (and g-s-d) compatible
 with the older versions, I guess the best we can do is to show a NEWS
 entry. But that is typically only read by the admin.

GNOME has typically required a high degree of inter-version
compatibility in many areas, such as in configuration, due to the
possibility of shared home directories.  I think it's reasonable to
require that gnome-shell work with an older version long enough to
unlock the session, even if it has degraded functionality in other ways.
(And ideally, since gnome-shell and several other GNOME components can
restart without breaking the entire session, GNOME itself should
recognize that it needs to restart them safely.

 update-notifier would be another option, but I'm unsure about it's
 current state in jessie and if it actually still works.
 
 And last, it wouldn't work for Josh's case either, who locked the screen
 midway through the upgrade.

Right.

- Josh Triplett


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

Bug#789118: Cannot unlock screen after upgrading GNOME if locked before upgrade

[Josh Triplett]

Package: gnome-shell
Version: 3.16.2-4
Severity: grave

[Filing this on gnome-shell because it shows the lock/unlock screen, but
the bug might lie in another component.]

I just upgraded this system to GNOME 3.16 in unstable; I've included the full 
list of
upgraded packages from the aptitude log below.  At some point during the
upgrade, I closed the lid of my laptop (to lock my screen; note that I
have suspend-on-lid-close disabled), then docked my laptop, and tried to
unlock my screen.  gnome-shell's unlock screen did not respond; I could
type my password and hit enter, but it hung rather than unlocking.  (The
cancel button worked.)

Upgraded packages from /var/log/aptitude:

===
[REMOVE, NOT USED] libebackend-1.2-7:amd64
[REMOVE, NOT USED] libebook-1.2-14:amd64
[REMOVE, NOT USED] libebook-contacts-1.2-0:amd64
[REMOVE, NOT USED] libedata-book-1.2-20:amd64
[REMOVE, NOT USED] libedata-cal-1.2-23:amd64
[REMOVE, NOT USED] libgtkhtml-4.0-0:amd64
[REMOVE, NOT USED] libgtkhtml-4.0-common:amd64
[REMOVE, NOT USED] libgtkhtml-editor-4.0-0:amd64
[REMOVE, NOT USED] libgtop2-7:amd64
[HOLD, DEPENDENCIES] g++-mingw-w64:amd64
[HOLD, DEPENDENCIES] gcc-mingw-w64:amd64
[INSTALL, DEPENDENCIES] gir1.2-gweather-3.0:amd64
[INSTALL, DEPENDENCIES] gstreamer1.0-clutter-3.0:amd64
[INSTALL, DEPENDENCIES] libcamel-1.2-52:amd64
[INSTALL, DEPENDENCIES] libcgi-pm-perl:amd64
[INSTALL, DEPENDENCIES] libclutter-gst-3.0-0:amd64
[INSTALL, DEPENDENCIES] libcryptui0a:amd64
[INSTALL, DEPENDENCIES] libebackend-1.2-10:amd64
[INSTALL, DEPENDENCIES] libebook-1.2-16:amd64
[INSTALL, DEPENDENCIES] libebook-contacts-1.2-1:amd64
[INSTALL, DEPENDENCIES] libecal-1.2-18:amd64
[INSTALL, DEPENDENCIES] libedata-book-1.2-25:amd64
[INSTALL, DEPENDENCIES] libedata-cal-1.2-27:amd64
[INSTALL, DEPENDENCIES] libedataserver-1.2-20:amd64
[INSTALL, DEPENDENCIES] libedataserverui-1.2-1:amd64
[INSTALL, DEPENDENCIES] libgtop-2.0-10:amd64
[INSTALL, DEPENDENCIES] libmetacity-private3:amd64
[INSTALL, DEPENDENCIES] libmutter0f:amd64
[INSTALL, DEPENDENCIES] seahorse-daemon:amd64
[REMOVE, DEPENDENCIES] libmetacity-private2:amd64
[REMOVE, DEPENDENCIES] libmutter0e:amd64
[UPGRADE] bijiben:amd64 3.14.2-1+b1 - 3.16.2-2
[UPGRADE] binutils-mingw-w64-i686:amd64 2.25-8+6.1 - 2.25-8+6.2
[UPGRADE] binutils-mingw-w64-x86-64:amd64 2.25-8+6.1 - 2.25-8+6.2
[UPGRADE] chromium:amd64 43.0.2357.65-1 - 43.0.2357.81-1
[UPGRADE] cpp-4.8:amd64 4.8.4-2 - 4.8.4-3
[UPGRADE] cpp-4.9:amd64 4.9.2-20 - 4.9.2-21
[UPGRADE] curl:amd64 7.42.1-3 - 7.43.0-1
[UPGRADE] dnsmasq-base:amd64 2.72-3.1+b1 - 2.73-1
[UPGRADE] evince:amd64 3.14.1-2 - 3.14.2-1
[UPGRADE] evince-common:amd64 3.14.1-2 - 3.14.2-1
[UPGRADE] evolution:amd64 3.12.11-1 - 3.16.3-1
[UPGRADE] evolution-common:amd64 3.12.11-1 - 3.16.3-1
[UPGRADE] evolution-data-server:amd64 3.12.11-1 - 3.16.3-1
[UPGRADE] evolution-data-server-common:amd64 3.12.11-1 - 3.16.3-1
[UPGRADE] evolution-ews:amd64 3.12.11-1 - 3.16.3-1
[UPGRADE] evolution-plugins:amd64 3.12.11-1 - 3.16.3-1
[UPGRADE] file-roller:amd64 3.16.2-1 - 3.16.2-2
[UPGRADE] folks-common:amd64 0.10.0-1 - 0.11.1-2
[UPGRADE] g++-4.9:amd64 4.9.2-20 - 4.9.2-21
[UPGRADE] g++-4.9-multilib:amd64 4.9.2-20 - 4.9.2-21
[UPGRADE] g++-mingw-w64-i686:amd64 4.9.2-15+15.1+b1 - 4.9.2-21+15.2
[UPGRADE] g++-mingw-w64-x86-64:amd64 4.9.2-15+15.1+b1 - 4.9.2-21+15.2
[UPGRADE] gcc-4.8:amd64 4.8.4-2 - 4.8.4-3
[UPGRADE] gcc-4.8-base:amd64 4.8.4-2 - 4.8.4-3
[UPGRADE] gcc-4.9:amd64 4.9.2-20 - 4.9.2-21
[UPGRADE] gcc-4.9-base:amd64 4.9.2-20 - 4.9.2-21
[UPGRADE] gcc-4.9-multilib:amd64 4.9.2-20 - 4.9.2-21
[UPGRADE] gcc-5-base:amd64 5.1.1-9 - 5.1.1-11
[UPGRADE] gcc-mingw-w64-base:amd64 4.9.2-15+15.1+b1 - 4.9.2-21+15.2
[UPGRADE] gcc-mingw-w64-i686:amd64 4.9.2-15+15.1+b1 - 4.9.2-21+15.2
[UPGRADE] gcc-mingw-w64-x86-64:amd64 4.9.2-15+15.1+b1 - 4.9.2-21+15.2
[UPGRADE] gedit:amd64 3.14.0-3 - 3.16.2-1
[UPGRADE] gedit-common:amd64 3.14.0-3 - 3.16.2-1
[UPGRADE] gedit-plugins:amd64 3.14.0-2 - 3.16.0-1
[UPGRADE] gir1.2-clutter-1.0:amd64 1.22.2-1 - 1.22.2-3
[UPGRADE] gir1.2-evince-3.0:amd64 3.14.1-2 - 3.14.2-1
[UPGRADE] gir1.2-goa-1.0:amd64 3.16.2-1 - 3.16.3-1
[UPGRADE] gir1.2-gtk-3.0:amd64 3.14.13-1 - 3.16.4-2
[UPGRADE] gir1.2-gtksource-3.0:amd64 3.14.4-2 - 3.16.1-1
[UPGRADE] gir1.2-gtop-2.0:amd64 2.28.5-2+b1 - 2.30.0-3
[UPGRADE] gir1.2-ibus-1.0:amd64 1.5.9-1 - 1.5.10-1
[UPGRADE] gir1.2-mutter-3.0:amd64 3.14.4-2+b1 - 3.16.2-2
[UPGRADE] gir1.2-totem-1.0:amd64 3.14.0-2 - 3.16.1-2
[UPGRADE] gnome-calculator:amd64 3.14.1-1 - 3.16.2-1
[UPGRADE] gnome-chess:amd64 1:3.14.0-1 - 1:3.16.2-1
[UPGRADE] gnome-contacts:amd64 3.14.2-1 - 3.16.2-1
[UPGRADE] gnome-control-center:amd64 1:3.14.4-1 - 1:3.16.2-2+b1
[UPGRADE] gnome-control-center-data:amd64 1:3.14.4-1 - 1:3.16.2-2
[UPGRADE] gnome-documents:amd64 3.14.2-1 - 3.16.2-1
[UPGRADE] gnome-klotski:amd64 1:3.14.1-1 - 1:3.16.1-1
[UPGRADE] gnome-logs:amd64 3.14.2-1 - 3.16.2-1
[UPGRADE] gnome-nettool:amd64 3.8.1-1 - 3.8.1-1+b1
[UPGRADE] 

Bug#786469: fixed in util-linux 2.26.2-5

[Josh Triplett]

On Fri, 22 May 2015 10:49:38 + Martin Pitt mp...@debian.org wrote:
 * Using sysvinit-utils ( 2.88dsf-59.1~) confuses apt during upgrade, so
   use Depends: instead. This isn't technically true, but ensures a robust
   upgrade also from jessie. (Closes: #786469)

This seems unfortunate, considering that one of the primary purposes of
this change was to reduce dependence on sysvinit-utils.

Could the dependency go the other way, instead?

- Josh Triplett


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

Bug#785672: Critical ext4 data corruption bug (maybe is dm-crypt related ?)

[Josh Triplett]

On Wed, 20 May 2015 23:12:10 +0200 Carlos Alberto Lopez Perez 
clo...@igalia.com wrote:
 Are you using dm-crypt?
 
 Then this may be related to another bug that appeared on 4.0. See:
 
 http://thread.gmane.org/gmane.linux.kernel/1942014

I'm not using dm-crypt on that system, though that's disturbing news for
the systems I have that *are* running dm-crypt.

However, Henrique de Moraes Holschuh identified a highly likely culprit
for the corruption I encountered:
https://bugzilla.kernel.org/show_bug.cgi?id=98501 , which affects mdraid
on RAID0 with discard enabled.

So, in addition to the patch mentioned when opening this bug, could the
Debian kernel also include this patch, please?  (Meanwhile, I'll work
around it by disabling discard.)

- Josh Triplett


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

Bug#785672: Critical ext4 data corruption bug

[Josh Triplett]

Package: src:linux
Version: 4.0.2-1
Severity: critical
Tags: upstream

4.0.3 includes a fix for a critical ext4 bug that can result in major
data loss.  I believe this is the bug I just hit on my server, resulting
in massive filesystem corruption.  See upstream commit
d2dc317d564a46dfc683978a2e5a4f91434e9711 (ext4: fix data corruption
caused by unwritten and delayed extents), which has been added to
stable kernels 4.0.3 as well as much older stable kernels.

Please consider incorporating this patch into the Debian kernels as soon
as possible, including into the Jessie kernel.

- Josh Triplett

-- Package-specific info:
** Version:
Linux version 4.0.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.2 
(Debian 4.9.2-16) ) #1 SMP Debian 4.0.2-1 (2015-05-11)

** Command line:
BOOT_IMAGE=/vmlinuz-4.0.0-1-amd64 root=/dev/mapper/data-root ro quiet

** Not tainted

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

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

Versions of packages linux-image-4.0.0-1-amd64 depends on:
ii  debconf [debconf-2.0]   1.5.56
ii  initramfs-tools [linux-initramfs-tool]  0.120
ii  kmod20-1
ii  linux-base  3.5
ii  module-init-tools   20-1

Versions of packages linux-image-4.0.0-1-amd64 recommends:
ii  firmware-linux-free  3.3
pn  irqbalance   none

Versions of packages linux-image-4.0.0-1-amd64 suggests:
pn  debian-kernel-handbook  none
ii  grub-pc 2.02~beta2-23
pn  linux-doc-4.0   none

Versions of packages linux-image-4.0.0-1-amd64 is related to:
pn  firmware-atherosnone
pn  firmware-bnx2   none
pn  firmware-bnx2x  none
pn  firmware-brcm80211  none
pn  firmware-intelwimax none
pn  firmware-ipw2x00none
pn  firmware-ivtv   none
ii  firmware-iwlwifi0.43
pn  firmware-libertas   none
pn  firmware-linux  none
pn  firmware-linux-nonfree  none
pn  firmware-myricomnone
pn  firmware-netxen none
pn  firmware-qlogic none
pn  firmware-ralink none
pn  firmware-realteknone
pn  xen-hypervisor  none

-- debconf information:
  linux-image-4.0.0-1-amd64/postinst/depmod-error-initrd-4.0.0-1-amd64: false
  linux-image-4.0.0-1-amd64/prerm/removing-running-kernel-4.0.0-1-amd64: true
  linux-image-4.0.0-1-amd64/postinst/mips-initrd-4.0.0-1-amd64:


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

Bug#785595: WebIDE downloads and launches adb binary without prompting; subsequently runs at Firefox startup

[Josh Triplett]

Package: iceweasel
Version: 38.0-2
Severity: grave
Tags: upstream

I opened up the developer menu in Firefox 38, and saw the new WebIDE.
I opened that up to take a look at it, and then closed it, without
running anything else.

That action alone apparently caused Firefox to silently download the
ADB Helper and Valence extensions in the background (see extension
list below), install them without prompting, and run them.  That in turn
downloaded and ran a pre-compiled adb binary in the background (which
Firefox launches at startup).

While it's potentially acceptable to *optionally* install such
extensions on user request, or even prompt to install them, silently
doing so without user consent in response to opening WebIDE (and doing
absolutely nothing with it) is definitely not OK.

This is upstream bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1114380

- Josh Triplett

-- Package-specific info:

-- Extensions information
Name: ADB Helper
Location: ${PROFILE_EXTENSIONS}/adbhel...@mozilla.org
Status: enabled

Name: Adblock Plus
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}
Package: xul-ext-adblock-plus
Status: enabled

Name: Default theme
Location: 
/usr/lib/iceweasel/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: enabled

Name: HTTPS-Everywhere
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/https-everywh...@eff.org
Package: xul-ext-https-everywhere
Status: enabled

Name: It's All Text!
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/itsallt...@docwhat.gerf.org
Package: xul-ext-itsalltext
Status: enabled

Name: Valence
Location: ${PROFILE_EXTENSIONS}/fxdevtools-adapt...@mozilla.org
Status: enabled

-- Plugins information
Name: Gnome Shell Integration
Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
Package: gnome-shell
Status: enabled

Name: iTunes Application Detector
Location: /usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.so
Package: rhythmbox-plugins
Status: enabled


-- Addons package information
ii  gnome-shell3.14.4-1 amd64graphical shell for the GNOME des
ii  iceweasel  38.0-2   amd64Web browser based on Firefox
ii  rhythmbox-plug 3.2.1-1  amd64plugins for rhythmbox music playe
ii  xul-ext-adbloc 2.6.9+dfsg-2 all  advertisement blocking extension 
ii  xul-ext-https- 4.0.3-1  all  extension to force the use of HTT
ii  xul-ext-itsall 1.9.1-2  all  extension to edit textareas using

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

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

Versions of packages iceweasel depends on:
ii  debianutils   4.5
ii  fontconfig2.11.0-6.3
ii  libasound21.0.28-1
ii  libatk1.0-0   2.16.0-2
ii  libc6 2.19-18
ii  libcairo2 1.14.2-2
ii  libdbus-1-3   1.8.18-1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2
ii  libffi6   3.1-2+b2
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-4
ii  libgcc1   1:5.1.1-5
ii  libgdk-pixbuf2.0-02.31.1-2+b1
ii  libglib2.0-0  2.44.0-3
ii  libgtk2.0-0   2.24.25-3
ii  libhunspell-1.3-0 1.3.3-3
ii  libnspr4  2:4.10.8-1
ii  libnss3   2:3.19-1
ii  libpango-1.0-01.36.8-3
ii  libsqlite3-0  3.8.10.1-1
ii  libstartup-notification0  0.12-4
ii  libstdc++65.1.1-5
ii  libvpx2   1.4.0-3
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  procps2:3.3.9-9
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages iceweasel recommends:
ii  gstreamer1.0-libav 1.4.4-2
ii  gstreamer1.0-plugins-good  1.4.5-2+b1

Versions of packages iceweasel suggests:
pn  fonts-mathjax  none
pn  fonts-oflb-asana-math  none
pn  fonts-stix | otf-stix  none
ii  libcanberra0   0.30-2.1
ii  libgnomeui-0   2.24.5-3
ii  libgssapi-krb5-2   1.12.1+dfsg-20
pn  mozplugger none

-- 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#785267: /etc/bash_completion.d/cmake broken, produces errors on every shell startup

[Josh Triplett]

Package: cmake
Version: 3.2.2-1
Severity: critical
File: /etc/bash_completion.d/cmake

~$ cat /etc/bash_completion.d/cmake
debian/tmp/usr/share/cmake-3.0/completions/cmake
debian/tmp/usr/share/cmake-3.0/completions/cpack
debian/tmp/usr/share/cmake-3.0/completions/ctest

I'd guess that the intent was to install those files rather than a list of
their filenames.  The result is that every shell startup prints:
bash: debian/tmp/usr/share/cmake-3.0/completions/cmake: No such file or 
directory
bash: debian/tmp/usr/share/cmake-3.0/completions/cpack: No such file or 
directory
bash: debian/tmp/usr/share/cmake-3.0/completions/ctest: No such file or 
directory

- Josh Triplett

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

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

Versions of packages cmake depends on:
ii  cmake-data3.2.2-1
ii  dpkg  1.17.25
ii  libarchive13  3.1.2-11
ii  libc6 2.19-18
ii  libcurl3  7.42.1-2
ii  libexpat1 2.1.0-6+b3
ii  libgcc1   1:5.1.1-5
ii  libjsoncpp0   0.6.0~rc2-3.1
ii  libstdc++65.1.1-5
ii  procps2:3.3.9-9
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages cmake recommends:
ii  gcc   4:4.9.2-3
ii  make  4.0-8.1

Versions of packages cmake suggests:
pn  codeblocks   none
pn  eclipse  none
ii  ninja-build  1.5.1-0.1

-- Configuration Files:
/etc/bash_completion.d/cpack 8d65632f9a6c67527019978f17469d7d [Errno 2] No such 
file or directory: u'/etc/bash_completion.d/cpack 
8d65632f9a6c67527019978f17469d7d'
/etc/bash_completion.d/ctest 788e5c5eb043b85aaddf5d5584652464 [Errno 2] No such 
file or directory: u'/etc/bash_completion.d/ctest 
788e5c5eb043b85aaddf5d5584652464'

-- 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#770492: [RFC PATCH RESEND] vfs: Move security_inode_killpriv() after permission checks

[Josh Boyer]

On Sat, Jan 17, 2015 at 6:26 PM, Ben Hutchings b...@decadent.org.uk wrote:
 chown() and write() should clear all privilege attributes on
 a file - setuid, setgid, setcap and any other extended
 privilege attributes.

 However, any attributes beyond setuid and setgid are managed by the
 LSM and not directly by the filesystem, so they cannot be set along
 with the other attributes.

 Currently we call security_inode_killpriv() in notify_change(),
 but in case of a chown() this is too early - we have not called
 inode_change_ok() or made any filesystem-specific permission/sanity
 checks.

 Add a new function setattr_killpriv() which calls
 security_inode_killpriv() if necessary, and change the setattr()
 implementation to call this in each filesystem that supports xattrs.
 This assumes that extended privilege attributes are always stored in
 xattrs.

 Compile-tested only.

 XXX This is a silent change to the VFS API, but we should probably
 change something so OOT filesystems fail to compile if they aren't
 updated to call setattr_killpriv().

 Reported-by: Ben Harris bj...@cam.ac.uk
 References: https://bugs.debian.org/770492

This seems to have stalled.  I don't see it in linux-next or anywhere
else I can find.  The issue has a shiny CVE now, so it makes people
that follow those nervous.  Is there any further feedback or follow-up
here?

josh

 ---
  drivers/staging/lustre/lustre/llite/llite_lib.c |  4 
  fs/9p/vfs_inode.c   |  4 
  fs/9p/vfs_inode_dotl.c  |  4 
  fs/attr.c   | 32 
 +
  fs/btrfs/inode.c|  4 
  fs/ceph/inode.c |  4 
  fs/cifs/inode.c | 11 -
  fs/ext2/inode.c |  4 
  fs/ext3/inode.c |  4 
  fs/ext4/inode.c |  4 
  fs/f2fs/file.c  |  4 
  fs/fuse/dir.c   | 15 +++-
  fs/fuse/file.c  |  3 ++-
  fs/fuse/fuse_i.h|  2 +-
  fs/gfs2/inode.c |  3 +++
  fs/hfs/inode.c  |  4 
  fs/hfsplus/inode.c  |  4 
  fs/jffs2/fs.c   |  4 
  fs/jfs/file.c   |  4 
  fs/kernfs/inode.c   | 17 +
  fs/libfs.c  |  3 +++
  fs/nfs/inode.c  | 11 +++--
  fs/ocfs2/file.c |  6 -
  fs/reiserfs/inode.c |  4 
  fs/ubifs/file.c |  4 
  fs/xfs/xfs_acl.c|  3 ++-
  fs/xfs/xfs_file.c   |  2 +-
  fs/xfs/xfs_ioctl.c  |  2 +-
  fs/xfs/xfs_iops.c   | 16 ++---
  fs/xfs/xfs_iops.h   | 10 ++--
  include/linux/fs.h  |  1 +
  mm/shmem.c  |  4 
  32 files changed, 176 insertions(+), 25 deletions(-)

 diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c 
 b/drivers/staging/lustre/lustre/llite/llite_lib.c
 index a8bcc51..2a714b2 100644
 --- a/drivers/staging/lustre/lustre/llite/llite_lib.c
 +++ b/drivers/staging/lustre/lustre/llite/llite_lib.c
 @@ -1434,6 +1434,10 @@ int ll_setattr_raw(struct dentry *dentry, struct iattr 
 *attr, bool hsm_import)
 spin_unlock(lli-lli_lock);
 }

 +   rc = setattr_killpriv(dentry, attr);
 +   if (rc)
 +   return rc;
 +
 /* We always do an MDS RPC, even if we're only changing the size;
  * only the MDS knows whether truncate() should fail with -ETXTBUSY */

 diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c
 index 296482f..735cbf84 100644
 --- a/fs/9p/vfs_inode.c
 +++ b/fs/9p/vfs_inode.c
 @@ -1130,6 +1130,10 @@ static int v9fs_vfs_setattr(struct dentry *dentry, 
 struct iattr *iattr)
 if (S_ISREG(dentry-d_inode-i_mode))
 filemap_write_and_wait(dentry-d_inode-i_mapping);

 +   retval = setattr_killpriv(dentry, iattr);
 +   if (retval)
 +   return retval;
 +
 retval = p9_client_wstat(fid, wstat);
 if (retval  0)
 return retval;
 diff --git a/fs/9p/vfs_inode_dotl.c b/fs/9p/vfs_inode_dotl.c
 index 02b64f4..f3ca76d 100644
 --- a/fs/9p/vfs_inode_dotl.c
 +++ b/fs/9p/vfs_inode_dotl.c
 @@ -583,6 +583,10 @@ int v9fs_vfs_setattr_dotl(struct dentry *dentry, struct 
 iattr *iattr)
 if (S_ISREG(inode-i_mode))
 filemap_write_and_wait(inode-i_mapping);

 +   retval = setattr_killpriv

Bug#776246: MD4 collision/preimage attacks (CVE-2014-8242)

[Josh Triplett]

Package: librsync1
Version: 0.9.7-10
Severity: grave
Tags: security upstream

See https://github.com/librsync/librsync/issues/5 .  librsync uses MD4
as part of syncing; given the low strength and size of MD4, and the
relative ease of computing collisions/preimages, that makes librsync
unsafe to use on untrusted data, such as when running a duplicity
backup.

The upstream fix involves changing the signature format to use a strong
hash.  The new version of librsync supports reading the old signature
format, but always writes the new one.  So, fixing this has some of the
same implications as Berkeley DB upgrades.  In particular, any
applications using librsync and its data format across multiple systems
will require upgrading any readers along with writers.  I'd suggest
coordinating this with the reverse dependencies of librsync1.

- Josh Triplett

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

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

Versions of packages librsync1 depends on:
ii  libc6  2.19-13
ii  multiarch-support  2.19-13

librsync1 recommends no packages.

librsync1 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#776034: fsck runs in parallel on same physical disk

[Josh Triplett]

On Fri, 23 Jan 2015 07:44:57 +0100 Daniel Pocock dan...@pocock.pro wrote:
 I have a server with many LVM logical volumes on top of the same RAID1
 md device on two spindles.
 
 At boot, fsck appeared to be starting on many of the LVs simultaneously.
 
 There was a horrendous sound of disk head movement from the server.
 
 This also makes the whole fsck process slower and therefore the boot
 process is slower.

systemd-fsck is supposed to avoid this.  According to its manpage:

 The file system check for root is performed before the other file
 systems. Other file systems may be checked in parallel, except when
 they are one the same rotating disk.

Does your LVM setup provide the correct value for rotational?  What
does the following command say:

sudo find /sys -name 'rotational' -exec head {} +

- Josh Triplett


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

Bug#769733: Duplicate of 766991

[Josh Triplett]

This seems like a duplicate of 766991; does the updated acpid address
the issue you encountered?

- Josh Triplett


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

Bug#768418: This is grave!

[Josh Triplett]

Control: tags 768418 + confirmed upstream fixed-upstream pending

On Fri, Nov 07, 2014 at 11:32:04AM +0100, martin f krafft wrote:
 severity 768418 grave
 thanks
 
 Ouch! My testing environment is broken, hence I failed to detect
 this.
 
 Josh, I think this may be due to
 89cd3f3718d9680be19e772127580316fbc511ad. Could you please have
 a look?

Yup.  Gah.  My testing failed to catch it as well, simply because the
referenced directories *do* exist on a system you build molly-guard on.
:)

Simple fix, too; ETCDIR needs to not have DEST in it.

I've pushed fixes to the git repo (upstream and master branches).  Can
you review them, then tag/build/upload?

- Josh Triplett


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

Bug#768393: sqlite3: segmentation fault in evolution caused by calling NULL xFetch method

[Josh Triplett]

Package: libsqlite3-0
Version: 3.8.7-1
Severity: grave
Tags: patch
Control: affects -1 evolution

I have a massive email folder in Evolution.  Recently, I started
encountering segmentation faults every time I accessed that folder
(opened it, tried to copy mail into it, etc).  Running evolution under
gdb turned up a backtrace leading to the call to xFetch in
sqlite3OsFetch (by way of vdbeSorterExtendFile), with a NULL xFetch
function pointer.

Some searching turned up this upstream patch:
http://www.sqlite.org/src/info/071f7f2decd2f786c0201a4219e9c2cc9d227085

I adapted that patch to apply to 3.8.7-1; adapted version attached.  I
rebuilt sqlite3 with that patch applied, and evolution no longer
segfaults.

- Josh Triplett
--- sqlite3-3.8.7.orig/src/vdbesort.c
+++ sqlite3-3.8.7/src/vdbesort.c
@@ -603,7 +603,7 @@ static int vdbeSorterMapFile(SortSubtask
   int rc = SQLITE_OK;
   if( pFile-iEof=(i64)(pTask-pSorter-db-nMaxSorterMmap) ){
 sqlite3_file *pFd = pFile-pFd;
-if( pFd-pMethods-iVersion=3 ){
+if( pFd-pMethods-iVersion=3  pFd-pMethods-xFetch ){
   rc = sqlite3OsFetch(pFd, 0, (int)pFile-iEof, (void**)pp);
   testcase( rc!=SQLITE_OK );
 }
@@ -1126,7 +1126,7 @@ void sqlite3VdbeSorterClose(sqlite3 *db,
 static void vdbeSorterExtendFile(sqlite3 *db, sqlite3_file *pFd, i64 nByte){
   if( nByte=(i64)(db-nMaxSorterMmap)  pFd-pMethods-iVersion=3 ){
 int rc = sqlite3OsTruncate(pFd, nByte);
-if( rc==SQLITE_OK ){
+if( rc==SQLITE_OK  pFd-pMethods-xFetch ){
   void *p = 0;
   sqlite3OsFetch(pFd, 0, (int)nByte, p);
   sqlite3OsUnfetch(pFd, 0, p);

Bug#764144: powermanga: Insecure temporary file /tmp/powermanga-log.txt

[Josh Triplett]

Package: powermanga
Version: 0.93-1
Severity: grave
Tags: security

~$ ln -s ~/arbitrary-file /tmp/powermanga-log.txt
~$ ls -l /tmp/powermanga-log.txt
lrwxrwxrwx 1 josh josh 25 Oct  4 21:14 /tmp/powermanga-log.txt - 
/home/josh/arbitrary-file
~$ powermanga
(II) configuration filename: /home/josh/.config/tlk-games/powermanga.conf 
[config_file.c:231, configfile_load]
~$ ls -l /tmp/powermanga-log.txt ~/arbitrary-file
-rw-r--r-- 1 josh games 154 Oct  4 21:15 /home/josh/arbitrary-file
lrwxrwxrwx 1 josh josh   25 Oct  4 21:14 /tmp/powermanga-log.txt - 
/home/josh/arbitrary-file
~$ cat arbitrary-file
2014-10-04 21:14:55 (II) [File: config_file.c][Line: 231][Function: 
configfile_load] configuration filename: 
/home/josh/.config/tlk-games/powermanga.conf


This appears to allow overwriting an arbitrary file writable by either
the user or group games.

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

Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages powermanga depends on:
ii  libc62.19-11
ii  libpng12-0   1.2.50-2
ii  libsdl-mixer1.2  1.2.12-11+b1
ii  libsdl1.2debian  1.2.15-10
ii  powermanga-data  0.93-1

powermanga recommends no packages.

powermanga 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#748525:

[Josh Triplett]

On Fri, Sep 19, 2014 at 11:57:39AM +0200, Markus Koschany wrote:
 Hi,
 
 It seems Josh didn't receive this message. Adding him to CC accordingly.

I indeed hadn't; thank you.

 On 19.09.2014 10:24, Tobias Frost wrote:
  Control: serverity -1 important
  
  Hi Josh,
  
  while this bug may be annoying, it does not justifty a grave severity, as it
  does NOT render the package useless.
  
  Please see https://www.debian.org/Bugs/Developer#severities
  
  Therefore downgrading.
  
  --
  tobi
 
 
 I think in this case the bug submitter is right because this bug affects
 all widescreen setups including my own and I suspect most people use a
 widescreen ratio nowadays. So for all those people this bug is a
 show-stopper.

That and the bug is not easy to recover from, since while you can get
into this state via the GUI configuration, you can't get out of it
without manually editing ~/.pangzerorc .  That was what made me report
the bug as grave.  If the game automatically recovered into a usable
mode, or if you could only get *into* this state by manually editing a
configuration file, I would only have used important.

 In addition there are multiple other issues with this package which are
 described in more detail at
 
 https://bugs.debian.org/692221
 
 In my opinion those are almost all serious problems which make the
 package unfit to release at least. Fortunately Hans de Goede has also
 setup a Git repository with patches, including a patch for #748525.
 
 https://github.com/kthakore/pangzero
 
 https://github.com/kthakore/pangzero/commit/bc3e77823772e8f87f50142778f8e6fe44badfb3

Awesome.

 I suggest we package his version and work on a new release to fix all
 those issues but raise the severity to RC again until the package is in
 a usable state again.

Sounds good.


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

Bug#748525: Fails on launch if set to widescreen

[Josh Triplett]

Package: pangzero
Version: 1.4-1
Severity: grave

(Setting this to grave due to the prevalence of wide screens, and the
non-trivial difficulty of recovering from this state.)

Setting the mode to Widescreen in the options menu causes pangzero to
fail on launch, with the following message:

Undefined subroutine SDL::ListModes called at 
/usr/share/perl5/Games/PangZero/Graphics.pm line 258

That function indeed doesn't exist, but SDL::Video::list_modes does.

(Also, the code calling that routine seems to require a very narrow
range of video modes, rather than adapting to what's available on the
system, but that isn't a grave bug, just an obnoxious one.)

Recovering from this state requires manually editing ~/.pangzerorc and
changing Games::PangZero::FullScreen back to 1.

- Josh Triplett

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

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages pangzero depends on:
ii  libsdl-perl  2.542-1
ii  perl 5.18.2-4

pangzero recommends no packages.

pangzero 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#744382: [Ceph-maintainers] Bug#744382: librbd-dev and librados-dev does not provide correct shlibs/symbols file

[Josh Durgin]

On 04/14/2014 02:43 AM, Dmitry Smirnov wrote:

On Mon, 14 Apr 2014 12:09:59 Michael Tokarev wrote:

14.04.2014 11:42, Dmitry Smirnov wrote:

I found it so difficult to maintain symbols in C++ libraries so I just
used
dh_makeshlibs -V and it never failed me.


Yeah, it never fails, but it has its own downside which I mentioned
above.


Thank you for all your comments. I'm with you, I understand how useful
.symbols could be for linking (if done properly).

Specifically in regards to Ceph for a moment I feel much more comfortable with
dh_makeshlibs -V not only due to lack of confidence in C++ symbols approach
but mostly because of rapid upstream development. The amount of changes
between 0.72.2 and 0.79 is huge. I would feel quite uncomfortable if qemu
would be built successfully with 0.79 but wouldn't pull newer libraries when
used with 0.72.2... For example Ceph cluster has to be completely upgraded to
0.79 as it just doesn't work with mix of 0.72.2 and 0.79 components (i.e.
OSD,MON,MDS)...


As a ceph developer, the mixed-cluster issue is a bug (possibly fixed
already since 0.79 is undergoing heavy testing and fixes before the
next long term stable release, 0.80, is out). If you have more details
we'd be happy to hear about them.

Regarding library symbols, the ceph libraries each have C++ as well as
C interfaces, and there's been some suggestions to move to
visibility=hidden by default, to avoid some of the hairier problems
with C++ libraries [1]. It seems like this would make .symbols files 
approach more tenable, since passing through all C++ symbols would

not be as bad if only the desired ones are exported in the first place.
This isn't done yet, but in the mean time the dh_makeshlibs -V 
approach seems fine to me.


If there's anything we could do upstream to make this easier, let us know.

Thanks!
Josh

[1] http://marc.info/?l=ceph-develm=138842618710279


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

Bug#743128: [Pkg-utopia-maintainers] Processed: found 743128 in 0.9.8.8-5

[Josh Triplett]

On Thu, Apr 03, 2014 at 01:51:44PM +0200, Michael Biebl wrote:
 Am 03.04.2014 07:54, schrieb Debian Bug Tracking System:
  # libpam-systemd was already installed and the bug still occurs
  found 743128 0.9.8.8-5
[...]
 
 Care to explain why you re-opened this bug report?

Bug-number confusion, apparently.  My intention was to indicate that I
continued to experience the bug with 0.9.8.8-5, and that with 0.9.8.8-4
I had libpam-systemd installed and it does not help.  However, it looks
like I mistook 743128 for 743206.  I sent a notfound to undo this.

- Josh Triplett


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

Bug#734813: systemd as pid1 allows lxc-containers to unmount host filesystems

[Josh Triplett]

Paul Tagliamonte wrote:
 Once I was able to get a browser open, I found out olasd had researched
 and found a commit[1] that seems to mark this as systemd's decision that
 the kernel is wrong(?)

 [1]: 
 http://cgit.freedesktop.org/systemd/systemd/commit/?id=b3ac5f8cb98757416d8660023d6564a7c411f0a0

I'm not sure I'd interpret that commit message as endorsing the behavior
of allowing containers to unmount host filesystems.  As I understand it,
the intent of systemd's use of shared mounts was to ensure that new
mounts/umounts in the *host* are propagated to the *guest* (which
doesn't seem like an unreasonable default for containers that share a
root filesystem), not necessarily the other way around.  This case may
simply need further evaluation upstream.

Furthermore, if you're sharing filesystems with a container, there are
many other ways that container can potentially hose the host filesystems
if not prevented from doing so, such as deleting files *on* those
filesystems rather than unmounting them.  (That's not a theoretical
concern, as anyone who has ever 'rm -rf'ed a chroot containing a bind
mount understands quite well.)  Any potential fix would need to take
that into account as well.

In any case, I'd suggest starting this conversation with upstream,
explaining the observed behavior and asking for further clarifying
details on the intended behavior.

I also believe that preemptively CCing the tech-ctte on bugs like this
is a mistake, as it undermines the normal assumption that maintainers of
different packages are capable of normal cooperation.

- Josh Triplett


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

Bug#732940: Breaks ssh: OpenSSL version mismatch. Built against 1000105f, you have 10001060

[Josh Triplett]

Package: libssl1.0.0
Version: 1.0.1e-5
Severity: critical

Upgrading OpenSSL caused SSH to break.

Here's the upgrade from aptitude's log:
[UPGRADE] libssl-dev:amd64 1.0.1e-4 - 1.0.1e-5
[UPGRADE] libssl1.0.0:amd64 1.0.1e-4 - 1.0.1e-5
[UPGRADE] openssl:amd64 1.0.1e-4 - 1.0.1e-5

And here's SSH failing:
$ ssh joshtriplett.org
OpenSSL version mismatch. Built against 1000105f, you have 10001060

- Josh Triplett

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

Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libssl1.0.0 depends on:
ii  debconf [debconf-2.0]  1.5.52
ii  libc6  2.17-97
ii  multiarch-support  2.17-97

libssl1.0.0 recommends no packages.

libssl1.0.0 suggests no packages.

-- debconf information excluded


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

Bug#732940: Breaks ssh: OpenSSL version mismatch. Built against 1000105f, you have 10001060

[Josh Triplett]

Package: libssl1.0.0
Version: 1.0.1e-5
Followup-For: Bug #732940

Julien Cristau wrote:
 On Sun, Dec 22, 2013 at 14:02:37 -0800, Josh Triplett wrote:
 Package: libssl1.0.0
 Version: 1.0.1e-5
 Severity: critical
 
 Upgrading OpenSSL caused SSH to break.
 
 Here's the upgrade from aptitude's log:
 [UPGRADE] libssl-dev:amd64 1.0.1e-4 - 1.0.1e-5
 [UPGRADE] libssl1.0.0:amd64 1.0.1e-4 - 1.0.1e-5
 [UPGRADE] openssl:amd64 1.0.1e-4 - 1.0.1e-5
 
 And here's SSH failing:
 $ ssh joshtriplett.org
 OpenSSL version mismatch. Built against 1000105f, you have 10001060
 
 sounds like an openssh bug to me...

I upgraded OpenSSL and OpenSSH stopped working.  Since the SONAME didn't
change, kinda by definition this seems like a bug in OpenSSL, not
OpenSSH.

- Josh Triplett

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

Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libssl1.0.0 depends on:
ii  debconf [debconf-2.0]  1.5.52
ii  libc6  2.17-97
ii  multiarch-support  2.17-97

libssl1.0.0 recommends no packages.

libssl1.0.0 suggests no packages.

-- debconf information excluded


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

Bug#732940: Breaks ssh: OpenSSL version mismatch. Built against 1000105f, you have 10001060

[Josh Triplett]

Package: libssl1.0.0
Version: 1.0.1e-5
Followup-For: Bug #732940

Kurt Roeckx wrote:
On Sun, Dec 22, 2013 at 02:16:43PM -0800, Josh Triplett wrote:
 Package: libssl1.0.0
 Version: 1.0.1e-5
 Followup-For: Bug #732940
 
 Julien Cristau wrote:
  On Sun, Dec 22, 2013 at 14:02:37 -0800, Josh Triplett wrote:
  Package: libssl1.0.0
  Version: 1.0.1e-5
  Severity: critical
  
  Upgrading OpenSSL caused SSH to break.
  
  Here's the upgrade from aptitude's log:
  [UPGRADE] libssl-dev:amd64 1.0.1e-4 - 1.0.1e-5
  [UPGRADE] libssl1.0.0:amd64 1.0.1e-4 - 1.0.1e-5
  [UPGRADE] openssl:amd64 1.0.1e-4 - 1.0.1e-5
  
  And here's SSH failing:
  $ ssh joshtriplett.org
  OpenSSL version mismatch. Built against 1000105f, you have 10001060
  
  sounds like an openssh bug to me...
 
 I upgraded OpenSSL and OpenSSH stopped working.  Since the SONAME didn't
 change, kinda by definition this seems like a bug in OpenSSL, not
 OpenSSH.

 So openssl is never supposed to change it's version number?

It's not OK to break forward compatibility without changing SONAME.
Software built against an older version of a library must always work
with a newer version that has the same SONAME; that's what the SONAME
exists for.  It'd be perfectly OK for software built against a newer
OpenSSL to refuse to work with an older version (ideally by requiring a
symbol the older library doesn't have), but the reverse is a bug,
regardless of the mechanism.

- Josh Triplett

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

Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libssl1.0.0 depends on:
ii  debconf [debconf-2.0]  1.5.52
ii  libc6  2.17-97
ii  multiarch-support  2.17-97

libssl1.0.0 recommends no packages.

libssl1.0.0 suggests no packages.

-- debconf information excluded


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

Bug#732940: Breaks ssh: OpenSSL version mismatch. Built against 1000105f, you have 10001060

[Josh Triplett]

Package: libssl1.0.0
Version: 1.0.1e-5
Followup-For: Bug #732940

Kurt Roeckx wrote:
 On Sun, Dec 22, 2013 at 02:45:32PM -0800, Josh Triplett wrote:
 
 It's not OK to break forward compatibility without changing SONAME.
 Software built against an older version of a library must always work
 with a newer version that has the same SONAME; that's what the SONAME
 exists for.  It'd be perfectly OK for software built against a newer
 OpenSSL to refuse to work with an older version (ideally by requiring a
 symbol the older library doesn't have), but the reverse is a bug,
 regardless of the mechanism.

 Openssl does not do this version check, nor does it suggest to do
 any such check.  I think I've already filed this bug against
 openssh twice and it seems to be comming back.

 I don't see how openssl is breaking either forward or backward
 compatibility.  It just changed the version it returned.  Openssl
 can't be responible for whatever people do with that version.

I stand corrected; my apologies.  I've seen so many libraries that put
in version checks like this that I assumed the version check lived in
OpenSSL, not OpenSSH.  You're right, this is *not* an OpenSSL bug, it's
an OpenSSH bug.  I'll reassign accordingly.

- Josh Triplett

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

Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libssl1.0.0 depends on:
ii  debconf [debconf-2.0]  1.5.52
ii  libc6  2.17-97
ii  multiarch-support  2.17-97

libssl1.0.0 recommends no packages.

libssl1.0.0 suggests no packages.

-- debconf information excluded


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

Bug#720968: severity of 720968 is normal

[Josh Triplett]

severity 720968 normal
thanks

Testing has Iceweasel 17, and unstable has Iceweasel 24.  I don't think
it makes sense to block migration to testing over this intentional
behavior change, which seems unlikely to be reverted.  Dropping
severity; I'll leave it to the maintainer to decide whether to wontfix
it.

- Josh Triplett


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

Bug#730675: Contains static library libminiupnpc.a; should be in -dev package

[Josh Triplett]

Package: libminiupnpc5
Version: 1.5-2
Severity: serious

libminiupnpc5 contains the static library /usr/lib/libminiupnpc.a .
This library should be in the -dev package, not the shared library
package.  In addition to violating Debian Policy, and making this
package incompatible with a potential future version of libminiupnpc
with a new SONAME, this also breaks the configure scripts of packages
that use AC_CHECK_LIB to check for -lminiupnpc and assume the headers
will be present if found.

- Josh Triplett

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

Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libminiupnpc5 depends on:
ii  libc6  2.17-96

Versions of packages libminiupnpc5 recommends:
pn  minissdpd  none

libminiupnpc5 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#729416: ImportError: No module named pkg_resources

[Josh Triplett]

Package: youtube-dl
Version: 2013.11.11-1
Severity: grave

Attempting to download any youtube video produces:

Traceback (most recent call last):
  File /usr/bin/youtube-dl, line 5, in module
from pkg_resources import load_entry_point
ImportError: No module named pkg_resources

- Josh Triplett

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

Kernel: Linux 3.11-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages youtube-dl depends on:
ii  python  2.7.5-5

Versions of packages youtube-dl recommends:
ii  libav-tools  6:9.10-1
ii  mplayer  2:1.0~rc4.dfsg1+svn34540-1+b2
ii  rtmpdump 2.4+20121230.gitdf6c518-1

youtube-dl 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#724731: [gdm3] gdm does not start properly, cannot login via gdm

[Josh Triplett]

Package: gdm3
Version: 3.8.4-2
Followup-For: Bug #724731

I'm observing this issue as well, and installing libpam-systemd (with a
reboot to restart all services including gdm) did not fix it for me.  I
still get a black screen from gdm, but I can startx from a terminal.

- Josh Triplett

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

Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.34-2
ii  adduser   3.113+nmu3
ii  dconf-cli 0.16.1-1
ii  dconf-gsettings-backend   0.16.1-1
ii  debconf [debconf-2.0] 1.5.51
ii  gir1.2-gdm3   3.8.4-2
ii  gnome-session [x-session-manager] 3.8.4-2
ii  gnome-session-bin 3.8.4-2
ii  gnome-settings-daemon 3.8.5-2
ii  gnome-shell   3.8.4-4
ii  gnome-terminal [x-terminal-emulator]  3.8.4-1
ii  gsettings-desktop-schemas 3.8.2-2
ii  libaccountsservice0   0.6.34-2
ii  libatk1.0-0   2.10.0-2
ii  libaudit1 1:2.3.2-2
ii  libc6 2.17-93
ii  libcairo-gobject2 1.12.16-2
ii  libcairo2 1.12.16-2
ii  libcanberra-gtk3-00.30-2
ii  libcanberra0  0.30-2
ii  libgdk-pixbuf2.0-02.28.2-1
ii  libgdm1   3.8.4-2
ii  libglib2.0-0  2.36.4-1
ii  libglib2.0-bin2.36.4-1
ii  libgtk-3-03.8.5-1
ii  libpam-modules1.1.3-9
ii  libpam-runtime1.1.3-9
ii  libpam0g  1.1.3-9
ii  libpango-1.0-01.32.5-5+b1
ii  libpangocairo-1.0-0   1.32.5-5+b1
ii  librsvg2-common   2.36.4-2
ii  libselinux1   2.1.13-3
ii  libwrap0  7.6.q-24
ii  libx11-6  2:1.6.2-1
ii  libxau6   1:1.0.8-1
ii  libxdmcp6 1:1.1.1-1
ii  libxrandr22:1.4.1-1
ii  lsb-base  4.1+Debian12
ii  metacity [x-window-manager]   1:2.34.13-1
ii  policykit-1-gnome 0.105-2
ii  upower0.9.22-1
ii  x11-common1:7.7+4
ii  x11-xserver-utils 7.7+1

Versions of packages gdm3 recommends:
ii  at-spi2-core   2.10.0-1
ii  desktop-base   7.0.3
ii  gnome-icon-theme   3.8.3-1
ii  gnome-icon-theme-symbolic  3.8.2.2-2
ii  x11-xkb-utils  7.7~1
ii  xserver-xephyr 2:1.14.3-4
ii  xserver-xorg   1:7.7+4
ii  zenity 3.8.0-1

Versions of packages gdm3 suggests:
ii  gnome-orca3.4.2-2
ii  libpam-gnome-keyring  3.8.2-2

-- Configuration Files:
/etc/gdm3/daemon.conf changed:
[daemon]
AutomaticLoginEnable = true
AutomaticLogin = josh
[security]
[xdmcp]
[greeter]
[chooser]
[debug]


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


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

Bug#724731: [gdm3] gdm does not start properly, cannot login via gdm

[Josh Triplett]

Package: gdm3
Version: 3.8.4-2
Followup-For: Bug #724731

Disabling autologin (along with having libpam-systemd installed) seems
to fix the problem, at least for initial startup.  I've observed some
reliability issues when restarting gdm3, but initial startup seems to
work.

So: broken without libpam-systemd, also broken with autologin even with
libpam-system.

- Josh Triplett

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

Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.34-2
ii  adduser   3.113+nmu3
ii  dconf-cli 0.16.1-1
ii  dconf-gsettings-backend   0.16.1-1
ii  debconf [debconf-2.0] 1.5.51
ii  gir1.2-gdm3   3.8.4-2
ii  gnome-session [x-session-manager] 3.8.4-2
ii  gnome-session-bin 3.8.4-2
ii  gnome-settings-daemon 3.8.5-2
ii  gnome-shell   3.8.4-4
ii  gnome-terminal [x-terminal-emulator]  3.8.4-1
ii  gsettings-desktop-schemas 3.8.2-2
ii  libaccountsservice0   0.6.34-2
ii  libatk1.0-0   2.10.0-2
ii  libaudit1 1:2.3.2-2
ii  libc6 2.17-93
ii  libcairo-gobject2 1.12.16-2
ii  libcairo2 1.12.16-2
ii  libcanberra-gtk3-00.30-2
ii  libcanberra0  0.30-2
ii  libgdk-pixbuf2.0-02.28.2-1
ii  libgdm1   3.8.4-2
ii  libglib2.0-0  2.36.4-1
ii  libglib2.0-bin2.36.4-1
ii  libgtk-3-03.8.5-1
ii  libpam-modules1.1.3-9
ii  libpam-runtime1.1.3-9
ii  libpam0g  1.1.3-9
ii  libpango-1.0-01.32.5-5+b1
ii  libpangocairo-1.0-0   1.32.5-5+b1
ii  librsvg2-common   2.36.4-2
ii  libselinux1   2.1.13-3
ii  libwrap0  7.6.q-24
ii  libx11-6  2:1.6.2-1
ii  libxau6   1:1.0.8-1
ii  libxdmcp6 1:1.1.1-1
ii  libxrandr22:1.4.1-1
ii  lsb-base  4.1+Debian12
ii  metacity [x-window-manager]   1:2.34.13-1
ii  policykit-1-gnome 0.105-2
ii  upower0.9.22-1
ii  x11-common1:7.7+4
ii  x11-xserver-utils 7.7+1

Versions of packages gdm3 recommends:
ii  at-spi2-core   2.10.0-1
ii  desktop-base   7.0.3
ii  gnome-icon-theme   3.8.3-1
ii  gnome-icon-theme-symbolic  3.8.2.2-2
ii  x11-xkb-utils  7.7~1
ii  xserver-xephyr 2:1.14.3-4
ii  xserver-xorg   1:7.7+4
ii  zenity 3.8.0-1

Versions of packages gdm3 suggests:
ii  gnome-orca3.4.2-2
ii  libpam-gnome-keyring  3.8.2-2

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


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


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

Bug#724642: Many plugins fail to load with ImportError: No module named gtk

[Josh Triplett]

Package: quodlibet-plugins
Version: 1:2.4-1
Severity: grave

Since upgrading to quodlibet 2.4, the majority of plugins fail to load
because they can't import gtk.

- Josh Triplett

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

Kernel: Linux 3.10-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages quodlibet-plugins depends on:
ii  exfalso3.0.2-2
ii  python 2.7.5-5
ii  python2.7  2.7.5-8

Versions of packages quodlibet-plugins recommends:
ii  brasero3.8.0-2
pn  gstreamer0.10-chromaprint  none
ii  notification-daemon0.7.6-1
pn  python-cddbnone
ii  python-dbus1.2.0-2+b1
ii  python-gnome2  2.28.1+dfsg-1
ii  python-gtk22.24.0-3+b1
pn  python-indicatenone
pn  python-musicbrainz2none
pn  python-pyinotify   none

Versions of packages quodlibet-plugins suggests:
pn  lastfmsubmitd  none

-- 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#720968: Enables javascript without asking

[Josh Triplett]

Package: iceweasel
Followup-For: Bug #720968

The option to disable javascript still exists: go to about:config, and
toggle javascript.enabled.  That option intentionally no longer has a
checkbox in the GUI, and I don't think it makes sense for Debian to
diverge from upstream on that.  If you want a checkbox for that option,
install an addon that gives you one, or install something more flexible
like NoScript or Adblock Plus.

The other half of this report relates to the browser re-enabling the
option on upgrade, which then requires technical users who really did
intend to disable javascript to re-do that change via about:config
(assuming they didn't previously do so via user.js, which will persist
across upgrades).  That change on upgrade exists to support novice users
who may have unintentionally broken their browser by toggling that
checkbox in the GUI without knowing what they were doing.  That change
seems debatable, but I'd personally argue against diverging from
upstream on that point either.

- Josh Triplett


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