Bug#1061591: rhsrvany: tests can fail on ci.debian.net due to wine32 installation

[Michael Gilbert]

package: src:rhsrvany
version: 1.1-2
severity: serious
tag: patch

runsrvany64 and runpnpwait64 autopkgtests can fail on amd64 on
ci.debian.net because of foreign arch wine32 installability issues
[0].  This currently prevents wine from migrating to testing [1].

The attached patch solves the problem by removing wine32 install from
the scripts.  wine32 isn't needed since the tests run correctly on
amd64 when wine and wine64 are installed, which is the case for
ci.debian.net.

Best wishes,
Mike

[0] https://ci.debian.net/packages/r/rhsrvany/testing/amd64/42392786/
[1] https://qa.debian.org/excuses.php?package=wine
--- a/debian/tests/runsrvany64
+++ b/debian/tests/runsrvany64
@@ -1,5 +1,4 @@
 #!/bin/sh
 set -e
-dpkg --add-architecture i386 && apt-get update && apt-get -y install wine32
 wine /usr/share/virt-tools/rhsrvany.exe install
 wine /usr/share/virt-tools/rhsrvany.exe uninstall
--- a/debian/tests/runpnpwait64
+++ b/debian/tests/runpnpwait64
@@ -1,4 +1,3 @@
 #!/bin/sh
 set -e
-dpkg --add-architecture i386 && apt-get update && apt-get -y install wine32
 wine /usr/share/virt-tools/pnp_wait.exe

Bug#988246: wine-development: not intended for a stable release

[Michael Gilbert]

package: src:wine-development
severity: serious

This package is not intended to be released in a debian stable
release.  This bug serves to prevent migration of the package to
testing.

Best wishes,
Mike

Bug#982275: debianutils: add-shell depends on non-essential package

[Michael Gilbert]

On Sat, Feb 13, 2021 at 5:01 AM Andreas Henriksson wrote:
> > For systems where awk is not yet installed (chroots), installation of
> > dash will currently fail since it's postinst calls add-shell from
> > debianutils.
>
> Please share details about how to reproduce this situation!
>
> You say you don't have awk when dash postinst runs, but that would also
> mean you don't have base-files (since it pre-depends on awk), which
> means you're lacking essential packages while you're configuring
> dash!
>
> Sounds to me like you're doing something very peculiar and likely
> completely unsupported to be able to trigger this issue. Atleast I can't
> think of any obvious way how to trigger it.

Yes, I am doing something quite peculiar.  I am trying to install the
absolute minimal system possible, just enough to be able to run a
shell (dash).  In fact without even base-files.

# mmdebstrap --verbose --variant=custom
--include=sed,grep,libc-bin,dash,diffutils,coreutils unstable unstable
[...]
/usr/sbin/add-shell: 20: awk: not found
Either another instance of /usr/sbin/add-shell is running, or it was
previously interrupted.
Please examine /etc/shells.tmp to see if it should be moved onto /etc/shells.
dpkg: error processing package dash (--install):
 installed dash package post-installation script subprocess returned
error exit status 1
Errors were encountered while processing:
 dash

I can add mawk to the list of packages to make it work, but that isn't
quite so minimal ;)

# mmdebstrap --verbose --variant=custom
--include=sed,mawk,grep,libc-bin,dash,diffutils,coreutils unstable
unstable

> Replacing using awk with cat whenever possible sounds like a good thing
> to do, so for the record I'm not against that. My skepticism is more
> at why this is not a wishlist bug report (that would be much better to
> adress early in a development cycle, rather than when we're already in
> the bullseye freeze).

Given the peculiarity and simple work around, I am ok with any severity.

Best wishes,
Mike

Bug#982275: debianutils: add-shell depends on non-essential package

[Michael Gilbert]

package: src:debianutils
severity: serious
version: 4.11.2
tag: patch

debianutil's add-shell script uses awk, but awk is not an
Essential:yes package.  For systems where awk is not yet installed
(chroots), installation of dash will currently fail since it's
postinst calls add-shell from debianutils.

A simple fix seems possible, just change add-shell to use cat, which
is in coreutils (Essential:yes).  Proposed update attached.

Best wishes,
Mike
--- debianutils-4.11.2/add-shell	2020-05-22 20:00:40.0 -0400
+++ debianutils-4.11.3/add-shell	2021-02-07 21:47:27.0 -0500
@@ -17,7 +17,7 @@
 }
 trap cleanup EXIT
 
-if ! awk '{print}' "$file" > "$tmpfile"
+if ! cat "$file" > "$tmpfile"
 then
 cat 1>&2 <

Bug#972134: chromium: please, consider moving the package to team-maintainance to properly maintain it

[Michael Gilbert]

On Tue, Dec 22, 2020 at 3:45 AM Michel Le Bihan wrote:
> I my NMU 87.0.4280.88-0.2 has just been uploaded to unstable and I'm
> interested in joining and helping with the package. My work is in
> https://salsa.debian.org/mimi8/chromium/ . Please also see the
> discussion under
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973848 .

Hi Michel,

Thank you for helping out with the package over the past couple
months.  Clearly I have not had time lately. I just added you to the
salsa group.  Please feel free to add yourself as an uploader.

Best wishes,
Mike

Bug#963176: Unable to run any programs due to kernelbase.dll failed to initialize.

[Michael Gilbert]

control: tag -1 moreinfo
control: severity -1 important

On Fri, Jun 19, 2020 at 11:09 PM Gong S. wrote:
> The current version of wine-development cannot launch any Windows programs, 
> including built-in ones like "winecfg" and "wineconsole".

I am not able to reproduce this on i386.  Is this on an arm system?

Either way, can you provide relevant output from

$ WINEDEBUG=+all winecfg-development

Best wishes,
Mike

Bug#955690: wine-development: FTBFS: configure: error: MinGW compiler not found, cross-compiling PE files won't be supported.

[Michael Gilbert]

On Fri, Apr 3, 2020 at 5:28 PM Stephen Kitt wrote:
> Thanks for the report, the package is missing a build-dependency on
> gcc-mingw-w64-x86-64.

There is more to it than this.  I am working on it now.

> Michael, I can take care of fixing this, doing a rebuild to make sure and
> uploading, if you could push your git repo ;-).

Done.

Best wishes,
Mike

Bug#932678: glib2.0: tests timeout on i386 and mips

[Michael Gilbert]

package: src:glib2.0
severity: serious
version: 2.60.5-1

The latest glib2.0 upload fails to build on i386 and mips [0].

On i386, the gmenumodel test timed out.  On mips, the gvariant test timed out.

Best wishes,
Mike

[0] https://buildd.debian.org/status/package.php?p=glib2.0

Bug#932592: kopano-webapp: autopkgtest regression

[Michael Gilbert]

package: src:kopano-webapp
severity: serious
version: 3.5.6+dfsg1-1

kopano-webapp currently has a failing autopkgtest [0].  This currently
blocks migration of chromium since it is listed as an autopkgtest
dependency for this package.

==
ERROR: test_login (test_webapp.TestWebApp)
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.720_qx5v/downtmp/build.vfl/src/debian/tests/test_webapp.py",
line 70, in test_login
elem.click()
  File "/usr/lib/python3/dist-packages/selenium/webdriver/remote/webelement.py",
line 80, in click
self._execute(Command.CLICK_ELEMENT)
  File "/usr/lib/python3/dist-packages/selenium/webdriver/remote/webelement.py",
line 633, in _execute
return self._parent.execute(command, params)
  File "/usr/lib/python3/dist-packages/selenium/webdriver/remote/webdriver.py",
line 321, in execute
self.error_handler.check_response(response)
  File 
"/usr/lib/python3/dist-packages/selenium/webdriver/remote/errorhandler.py",
line 242, in check_response
raise exception_class(message, screen, stacktrace)
selenium.common.exceptions.JavascriptException: Message: javascript
error: circular reference
  (Session info: headless chrome=76.0.3809.62)

It looks like a selenium issue, but I haven't debugged further than
reading this log.  If it has to do with chromium-driver, please create
a chromium bug with more information.

Best wishes,
Mike

[0] https://ci.debian.net/packages/k/kopano-webapp/testing/amd64/

Bug#930469: chromium: Insta-segfault on start

[Michael Gilbert]

control: tag -1 moreinfo

On Thu, Jun 13, 2019 at 5:36 AM Guillem Jover wrote:
>   [23609:23609:0613/102304.872428:FATAL:render_process_host_impl.cc(4060)] 
> Check failed: render_process_host->InSameStoragePartition( 
> BrowserContext::GetStoragePartition(browser_context, site_instance, false )).

This is the error.  FATAL errors in chromium intentionally abort
execution.  That output should have also been seen without --debug,
although upstream's handling of FATAL messages can be flaky.

My best guess is that there is an incompatibility with profiles
created before 75.  If you start with --temp-profile, does that avoid
the problem?

Best wishes,
Mike

Bug#930348: chromium: missing intrinsics on armhf

[Michael Gilbert]

On Tue, Jun 11, 2019 at 2:21 PM Riku Voipio wrote:
> I can make an upload if you prefer, or I can wait for you.

No reason to delay, please go ahead.

Best wishes,
Mike

Bug#930348: chromium: missing intrinsics on armhf

[Michael Gilbert]

package: src:chromium
severity: serious
version: 75.0.3770.80-1

The latest upload fails to build on armhf due to missing intrinsics [0].

Best wishes,
Mike

[0]https://buildd.debian.org/status/fetch.php?pkg=chromium=armhf=75.0.3770.80-1=1560141959=0

Bug#928097: chromium: crc32 build errors on arm64

[Michael Gilbert]

package: src:chromium
severity: serious
version: 74.0.3729.108-1

The latest upload fails to build on arm64 due to errors in crc32 [0].

Best wishes,
Mike

[0]https://buildd.debian.org/status/fetch.php?pkg=chromium=arm64=74.0.3729.108-1=1556085401=0

Bug#923298: chromium: file overlap with chromium-sandbox without Conficts and/or Replaces

[Michael Gilbert]

control: tag -1 pending

On Tue, Feb 26, 2019 at 4:39 AM Lee Garrett wrote:
> your issue is related to mixing stable and testing, which is not supported and
> causing your issue here.

This may not be common knowledge, but mixed suites have always been a
supported configuration.  This is a legitimate bug.  I have a fix
queued for the next -security upload.

Best wishes,
Mike

Bug#922207: Wine + AnyRail 6.1 - messing up KDE Desktop

[Michael Gilbert]

control: tag -1 moreinfo
control: severity -1 minor

This sounds a lot like this upstream bug:
https://bugs.winehq.org/show_bug.cgi?id=23676

It is in a different app and only seen with mesa and ati drivers, not
nvidia.  Which driver do you use?

Does AnyRail allow you to disable 3d rendering?

Best wishes,
Mike

Bug#921126: wine-development: checks for /run/user instead of /run/user/$uid

[Michael Gilbert]

package: src:wine-development
severity: serious
version: 3.12-2

This has been fixed in wine [0].  It also needs to be fixed in wine-development.

Best wishes,
Mike

[0] http://bugs.debian.org/918666

Bug#913116: Needs to depend on chromium-sandbox

[Michael Gilbert]

On Mon, Dec 17, 2018 at 4:40 AM Bastian Blank wrote:
> > Since this can be used in place of chromium's setuid binary, my
> > opinion is that the Depends relationship on chromium-sandbox is no
> > longer required.
>
> Nope, at least if the package is supposed to work without admin
> intervention.

Debian policy does not (currently) demand this for dependency relationships.

Policy states that dependencies represent other packages that are
required for the first to work correctly.  In this case, since
chromium can be set up to work correctly without chromium-sandbox
installed, it thus does not need to be considered a dependency.
Whether or not the set requires administrator intervention is
consequently not relevant, at least with respect to the statement
policy makes about this.

Best wishes,
Mike

Bug#913116: Needs to depend on chromium-sandbox

[Michael Gilbert]

On Fri, Nov 16, 2018 at 4:30 AM Bastian Blank wrote:
> Debian does not support unprivileged user namespaces, so chromium needs
> to depend on -sandbox to get a working package.

The debian version of the kernel package provides
kernel.unprivileged_userns_clone as a runtime selectable option for a
while now.

Since this can be used in place of chromium's setuid binary, my
opinion is that the Depends relationship on chromium-sandbox is no
longer required.

Best wishes,
Mike

Bug#904796: chromium for arm64 lacks security updates

[Michael Gilbert]

control: tag -1 pending

On Tue, Aug 7, 2018 at 9:07 AM, Riku Voipio wrote:
> I didn't push this to main stretch branch, as the security upload commit
> is reconstructed rather the original from Michael. Changelog hasn't been
> updated either.

I had forgotten to push after the previous upload, done now.  I will
include this in the next stable-sec upload.

Best wishes,
Mike

Bug#903383: wine-development: FTBFS with unicode-data 11

[Michael Gilbert]

This will be fixed by the package now in unstable when it transitions
to testing in 5 days.

Best wishes,
Mike

Bug#901043: vkd3d-demos: /usr/bin/triangle is already shipped by the triangle-bin package

[Michael Gilbert]

control: tag -1 pending

On Fri, Jun 8, 2018 at 7:28 AM, Andreas Beckmann wrote:
> I don't think a -demos package should ship binaries with generic
> names in /usr/bin - and maybe not in /usr/bin at all.

I uploaded a new version fixing this last week, it is currently
awaiting review in NEW.

Best wishes,
Mike

Bug#902293: gcc-6: internal compiler error in convert_move on arm

[Michael Gilbert]

package: src:gcc-6
version: 6.4.0-18
severity: grave
control: affects -1 src:chromium-browser
forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86166

This was marked as a duplicate upstream and closed, but it seems like
it should be considered a separate issue.

The latest chromium upload now fails because of this [0] (using gcc
6.4.0-18, which includes the fix for #901290).

Best wishes,
Mike

[0]https://buildd.debian.org/status/fetch.php?pkg=chromium-browser=arm64=68.0.3440.17-1=1529836062=0

Bug#900533: bug not fixed in v68

[Michael Gilbert]

On Sat, Jun 23, 2018 at 8:47 PM, 積丹尼 Dan Jacobson wrote:
> The browser won't let people switch back from 68 to 67 anyway,
> they would have to rip up their whole profile.

Have you ever considered not upgrading when packages land in
experimental?  They are after all experimental.

Best wishes,
Mike

Bug#902255: llvm-toolchain-6.0: unicode non free license

[Michael Gilbert]

package: src:llvm-toolchain-6.0
version: 1:6.0-3
severity: serious
control: affects -1 src:chromium-browser

LLVM includes ConvertUTF, which has a non free license.  See #823100,
#900596, etc.  Files affected are:

lib/Support/ConvertUTF.cpp
include/llvm/Support/ConvertUTF.h

Best wishes,
Mike

Bug#901290: chromium: version 68 arm build causes internal compiler error

[Michael Gilbert]

package: src:chromium-browser
severity: grave
version: 68.0.3440.7-1

The version just uploaded to experimental causes an internal compiler
error in gcc on arm [0].

Best wishes,
Mike

[0]https://buildd.debian.org/status/package.php?p=chromium-browser=experimental

Bug#897242:

[Michael Gilbert]

version: 67.0.3396.62-2

Bug#900533: chromium 67.0.3396.62-1: youtube video, gif's, html5, and movies no longer work

[Michael Gilbert]

control: tag -1 confirmed, help

On Wed, Jun 6, 2018 at 11:37 AM, jim_p wrote:
> Is there any info on when this issue could be fixed? It has been a week since
> this bug report was opened and there are no official comments here regarding
> any progress, neither some newer source package suggesting there is a patch 
> for
> it or a fix.

It's pretty clearly an issue with the ffmpeg demuxer.  I'll debug it
when I find free time.  Others willing to help might move things a bit
faster.

Best wishes,
Mike

Bug#893302: lwjgl FTBFS with openjdk-9

[Michael Gilbert]

On Mon, Apr 23, 2018 at 4:57 PM, Markus Koschany wrote:
> lwjgl 2.9.3 is a legacy release from 2015. It is the last version of the
> 2.x series and no longer supported. Upstream moved to lwjgl 3. If nobody
> can fix this we should consider to remove lwjgl because the new version
> 3 would require new Kotlin build dependencies and more.

Does anyone know what the plan is for openjdk-8 in buster?  If it
isn't going to go away, the easiest thing may be to depend on it
instead of default-jdk.

It look like after many years now, no one has tried to put together a
kotlin compiler package, so supporting lwjgl3 seems very unlikely.

Best wishes,
Mike

Bug#891786: [pkg-dhcp-devel] Bug#891786: isc-dhcp: diff for NMU version 4.3.5-3.1

[Michael Gilbert]

On Sun, Mar 4, 2018 at 3:44 PM, Salvatore Bonaccorso wrote:
> I've prepared an NMU for isc-dhcp (versioned as 4.3.5-3.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

Hi Salvatore,

Some meaningless whitespace is touched, but otherwise your patches
look correct.  Please feel free to remove the delay.

Best wishes,
Mike

Bug#891062: chromium: skia fails to build on arm64

[Michael Gilbert]

package: src:chromium-browser
version: 65.0.3325.73-1
severity: serious

Starting with chromium 65, arm64 fails while building skia.

../../third_party/skia/src/jumper/SkJumper_stages.cpp: In function 'F
from_half(U16)':
../../third_party/skia/src/jumper/SkJumper_stages.cpp:670:12: error:
'vcvt_f32_f16' was not declared in this scope
 return vcvt_f32_f16(h);

Best wishes,
Mike

Bug#868952: bind9: diff for NMU version 1:9.10.3.dfsg.P4-12.5

[Michael Gilbert]

Hi Salvatore,

The changes look correct to me.  Please feel free to remove the delay
on the NMU.

Best wishes,
Mike

On Sat, Jul 22, 2017 at 3:57 AM, Salvatore Bonaccorso  wrote:
> Control: tags 868952 + patch
> Control: tags 868952 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for bind9 (versioned as 1:9.10.3.dfsg.P4-12.5) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
>
> Regards,
> Salvatore

Bug#862250: Proposed diff fixing prefetch logic of 9.10

[Michael Gilbert]

control: severity -1 important

The impact of this is only reduced performance, which is not release
critical.  This could be fixed by a stretch SPU later if someone is
interested in pushing that.

Best wishes,
Mike

Bug#860225: bind9: diff for NMU version 1:9.10.3.dfsg.P4-12.3

[Michael Gilbert]

On Mon, May 8, 2017 at 6:23 PM, Michael Gilbert wrote:
> I reviewed the diff.  It does look correct to me, so please feel free
> to remove the delay.

There is also CVE-2017-3139 now [0].

Best wishes,
Mike

[0] https://access.redhat.com/errata/RHSA-2017:1202

Bug#860225: bind9: diff for NMU version 1:9.10.3.dfsg.P4-12.3

[Michael Gilbert]

On Sun, May 7, 2017 at 10:38 AM, Salvatore Bonaccorso wrote:
> I've prepared an NMU for bind9 (versioned as 1:9.10.3.dfsg.P4-12.3) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.

Hi Salvatore,

I reviewed the diff.  It does look correct to me, so please feel free
to remove the delay.

I don't have the free time to prepare the jessie DSA right now, are
you willing to do it?

Best wishes,
Mike

Bug#859927: lighttpd: 15-fastcgi-php.conf does not respect php7.0 transition

[Michael Gilbert]

control: severity -1 normal
control: retitle -1 lighttpd: suggest php-cgi since php5-cgi is removed

On Sun, Apr 9, 2017 at 6:56 AM, Carsten Schoenert wrote:
> the suggesting of the (currently wrong) package php5-cgi into a depends on
> package php7.0-cgi. Without this package lighttp isn't working right now after
> the modul is enabled.

Unless you want to upset upstream, php*-cgi should be no higher than a
Suggests, see #774644.  I have already made that mistake.

The server reporting OK when it doesn't start is another bug, again see #774644.

I've downgraded the severity and cancelled the nmu since this is not an RC bug.

Best wishes,
Mike

Bug#857522: libbind-export-dev: broken symlinks: /usr/lib/x86_64-linux-gnu/liblwres-export.so -> /lib/x86_64-linux-gnu/liblwres-export.so.141, /usr/lib/x86_64-linux-gnu/libbind9.so -> libbind9.so.140.

[Michael Gilbert]

control: severity -1 important

On Sun, Mar 12, 2017 at 1:26 AM, Andreas Beckmann wrote:
>   /usr/lib/x86_64-linux-gnu/liblwres-export.so -> 
> /lib/x86_64-linux-gnu/liblwres-export.so.141
>   /usr/lib/x86_64-linux-gnu/libbind9.so -> libbind9.so.140.0.10

These are mistakenly included in libbind-export-dev, but they do no
harm being there.  This is a bug, not an RC bug.

Best wishes,
Mike

Bug#854243: bind9 - Reads /dev/random in named and does not longer answer

[Michael Gilbert]

On Sun, Feb 5, 2017 at 6:47 AM, Bastian Blank wrote:
> bind9 uses /dev/random unconditionally without the possibility to change
> that in the configuration.

It is not entirely unconditional, --with-randomdev can be set at build
time, but admittedly that is not a very friendly solution.

Best wishes,
Mike

Bug#856259: [pkg-wpa-devel] Bug#856259: wpasupplicant: missing dependency on ifupdown

[Michael Gilbert]

control: tag -1 -moreinfo
control: severity -1 normal
control: retitle -1 wpasupplicant: missing dependency on ifupdown on kfreebsd

On Mon, Feb 27, 2017 at 3:15 AM, Andrew Shadura wrote:
> Please provide more logs or debug info.

The error is limited to kfreebsd.  Running with -dd produces a stream
of of the same error message

$ wpa_supplicant -dd -i wlan0 -c wpa.conf
[...]
Invalid routing message version=173
[...]

which comes from src/drivers/driver_bsd.c, hence only kfreebsd.  With
ifupdown installed the routing message version=5.  It haven't tracked
down yet why the presence of ifupdown changes this.

Best wishes,
Mike

Bug#856259: wpasupplicant: missing dependency on ifupdown

[Michael Gilbert]

package: wpasupplicant
severity: serious
justification: policy 3.5
version: 2.5-2+v2.4-3, 2:2.4-1

wpasupplicant relies on ifupdown, but there is no relationship to it
declared in the packaging.

For example, without ifupdown installed running these commands:

# ifconfig wlan0 create wlandev iwn0
# wpa_supplicant -i wlan0 -c wpa.conf

causes the wpa_supplicant process to hang using 100% CPU.

Once ifupdown is installed, the exact same set of commands and same
conf file, wpasupplicant correctly connects to my access point.

Best wishes,
Mike

Bug#841401: deferred upload

[Michael Gilbert]

control: tag -1 pending

Uploaded to delayed/5 to give -4 a chance to migrate.

Best wishes,
Mike

Bug#856039: xserver-xorg-core: no keyboard and no mouse

[Michael Gilbert]

control: tag -1 moreinfo

On Fri, Feb 24, 2017 at 9:33 AM, Toni Mueller wrote:
> Package: xserver-xorg-core

Did you only install xserver-xorg-core?  If so, you will be missing a
lot of important packages, like xserver-xorg-input-libinput, which
provides mouse support.  To get all packages needed, consider
installing xserver-xorg instead.

[0] is related.

Best wishes,
Mike

[0] http://bugs.debian.org/854322

Bug#820381: rar crashes.

[Michael Gilbert]

control: tag -1 moreinfo

I tried rar on up to date i386 and amd64 stretch systems.  Versions
5.3 and 5.4 both work fine for me.

I am not sure if this is related or not, but linux 4.8.15-1 changes
vsyscall, which was mentioned in message #25.

Has anyone else tested this lately?

Best wishes,
Mike

Bug#855540: bind9: CVE-2016-8864 causes more regressions

[Michael Gilbert]

package: src:bind9
severity: grave
version: 1:9.10.3.dfsg.P4-11

The fix for this issue causes more regressions.

Bug#855529: chromium-widevine: dbgsym package in contrib causes src package to also go into contrib

[Michael Gilbert]

package: chromium-widevine
severity: serious
version: 55.0.2883.75-6

Just like #824169, the contrib dbgsym binary package causes the source
package to be duplicated in contrib.

Best wishes,
Mike

Bug#853108: [Pkg-chromium-maint] Bug#853108: chromium: fails to build on armhf

[Michael Gilbert]

On Wed, Feb 1, 2017 at 2:19 PM, Riku Voipio wrote:
> Can you push the current experimental to git so I can merge the
> fix on top of it, or should I just do it myself?

Just pushed now, I had it all staged a while back but forgot to push.
Apologies.

Best wishes,
Mike

Bug#853108: chromium: fails to build on armhf

[Michael Gilbert]

package: src:chromium-browser
severity: grave
version: 56.0.2924.76-1

The upload to experimental fails to build on armhf due to new NEON code.

Best wishes,
Mike

Bug#820974: plans for bug #820974

[Michael Gilbert]

On Thu, Jan 26, 2017 at 6:41 AM, Arturo Borrero Gonzalez wrote:
> could you please share yours plans regarding this bug?

Patches welcome?

Best wishes,
Mike

Bug#828082: bind9: FTBFS with openssl 1.1

[Michael Gilbert]

On Sun, Jan 22, 2017 at 6:26 AM, Luca Boccassi wrote:
> This will allow a clean rebuild for backporting purposes. Would really
> appreciate a lot if this change could be made :-)

There are no jessie backports of bind.

Best wishes,
Mike

Bug#851927: chromium: Update removed all (local) installed extensions

[Michael Gilbert]

control: severity -1 wishlist
control: retitle -1 chromium: add extensions option to CHROMIUM_FLAGS

This update does not remove anything, so there is no reason to think
there is data loss.

I agree that setting the option in CHROMIUM_FLAGS should be supported.

Best wishes,
Mike

Bug#828082: bind9: FTBFS with openssl 1.1

[Michael Gilbert]

On Fri, Jan 13, 2017 at 4
> Upstream has actually added a patch for this already in the stable
> branch as far as I know, so I expect this to actually have been
> fixed in 9.10.4-P5.

I worked on this today, their patch is not applied in -P5, so I'll be
uploading a version with Bernhard's suggestion.

Best wishes,
Mike

Bug#845171: [pkg-wine-party] Bug#845171: wine-development: FTBFS: ld aborts or segfaults

[Michael Gilbert]

On Sun, Nov 20, 2016 at 9:16 PM, Jens Reyer wrote:
> wine-development 1.9.22-1 (in stretch) built successfully on all
> architectures when it was uploaded to unstable, but fails to
> build in a stretch environment on i386 now (amd64 is still fine).
> Exactly the same for 1.9.23-1 on i386 in a sid environment:

Hi Jens,

1.9.23-1 built for me ok in a sid i386 chroot.  Can you clarify the
setup where it fails?  Did you mean kfreebsd-i386?

A recent change to binutils adds -Wl,--enable-new-dtags by default.
That may be the cause of the problem on arm.

The i386 and arm failures are probably different issues.

Best wishes,
Mike

Bug#838534: chromium: ::MoveToNewUserNS().

[Michael Gilbert]

control: severity -1 important
control: forwarded -1 http://crbug.com/571277

There are a few suggestions in the upstream bug, do any of them help?
Also bug #833342 seems similar.

Best wishes,
Mike

Bug#816325: [pkg-dhcp-devel] Bug#816325: org.freedesktop.PolicyKit1 was not provided by any .service files

[Michael Gilbert]

control: severity -1 important
control: tag -1 moreinfo, unreproducible

On Mon, Feb 29, 2016 at 4:11 PM, Joerg Frings-Fuerst wrote:
> $ systemctl start isc-dhcp-server
> Failed to start isc-dhcp-server.service: The name org.freedesktop.PolicyKit1 
> was not provided by any .service files

The org.freedesktop.PolicyKit1.service file is provided by the
policykit-1 package.  Do you have that installed?

Anyway, I tried removing that, but the server still started fine for
me with systemd.  Have you created your own isc-dhcp-server.service
file?  If so, what does it contain?

Best wishes,
Mike

Bug#819860: [dhclient] can not obtain one dhcp lease on TAP device connected to 802.1q vlan interface via one bridge

[Michael Gilbert]

contlol: severity -1 normal

On Sun, Apr 3, 2016 at 3:43 AM, LACROIX Jean Marc wrote:
> On recent Debian Kernel (3.16.7-ckt25-1) based on Jessie 8.4, i try to
> setup one bridge (br-admin) with 2 externals devices.

The description that follows isn't totally clear, are you saying that
this worked correctly prior to the 8.4 kernel update?

Best wishes,
Mike

Bug#814167: lwjgl: (Build-)Depends on OpenJDK 7

[Michael Gilbert]

On Wed, Mar 9, 2016 at 10:20 AM, Markus Koschany wrote:
> https://github.com/JetBrains/kotlin
>
> This one seems to be the blocker because kotlin build-depends on
> components of IntelliJ IDEA and all in all that's a lot of stuff for a
> mere library.

This is the huge dependency stack that I was referring to.

> But perhaps I am missing something and it is much simpler...

Possibly, I only did a quick look at it a while ago, so I don't know
if it's the only approach.

Best wishes,
Mike

Bug#814167: lwjgl: (Build-)Depends on OpenJDK 7

[Michael Gilbert]

> I have switched the build-dependency to default-jdk and changed
> JAVA_HOME in debian/rules accordingly. However the package FTBFS with
> OpenJDK 8. I guess packaging the latest upstream release would be the
> best option.

2.9.3 is supposed to support building without ant.  I looked at it a
while ago, and it isn't quite that simple.

lwjgl3 is also available, but it has a huge dependency stack with
almost none of it in Debian yet.

I have less interest in lwjgl now than I used to, and I may not be
able to find the time to work on it.

Best wishes,
Mike

Bug#812569: chromium: fails to link on i386

[Michael Gilbert]

package: src:chromium-browser
severity: grave
version: 46.0.2490.71-1

The latest upstream versions exhaust memory with ld.bfd as the linker
on i386.  The gold linker so far seems to avoid this.

Bug#808081: squeeze update of bind9?

[Michael Gilbert]

On Wed, Dec 16, 2015 at 3:22 PM, Raphael Hertzog wrote:
> Hello dear maintainer(s),
>
> the Debian LTS team would like to fix the security issues which are
> currently open in the Squeeze version of bind9:
> https://security-tracker.debian.org/tracker/CVE-2015-8000

As mentioned before, please go ahead with bind LTS updates without delay.

Best wishes,
Mike

Bug#808081: bind9: CVE-2015-8000: Responses with a malformed class attribute can trigger an assertion failure in db.c

[Michael Gilbert]

On Wed, Dec 16, 2015 at 10:11 AM, Salvatore Bonaccorso wrote:
> Hi,
>
> Attached is proposed debdiff for the unstable upload (not yet uploaded
> to any delayed queue, just want to check I do not interfere with your
> work on it already).

You can do the nmu.  I don't have time right now.

Best wishes,
Mike

Bug#789875: subsurface: FTBFS in experimental

[Michael Gilbert]

On Wed, Aug 26, 2015 at 7:11 PM, Linus Torvalds wrote:
 So quite frankly, the fact that Debian people now attack Dirk, who has
 been bending over backwards over these kinds of stupidities, is not a
 big surprise. I think it's in the Debian DNA to care more about rules
 than about technical sanity. The whole this is the only right way to
 do licensing thing extends to this is the only correct waty to do
 packaging.

 It's sad to see.

Perhaps it isn't clear external to the project, but participation in
the Debian BTS does not automatically make one a Debian person, which
not a defined status.

The maintainer of the subsurface package, an official Debian status,
removed the package on request, so in many ways, problem happily
solved?

As with any internet discussion forum there are those whose
contributions are a net negative, and Debian always errs on the side
of free speech over ban hammer, so unfortunately this kind of
distraction persists.

You can probably expect additional unblinking walls of text chock full
of insult and little actual technical content incoming from
scientia.net.

My advice is to not feed.

Best wishes,
Mike

Bug#795544: xorg: open source video drivers flawed?

[Michael Gilbert]

control: reassign -1 src:fglrx-driver

On Sat, Aug 15, 2015 at 4:23 AM, Richard Jasmin wrote:
 It seems either development is stalled on open source drivers or we have an
 upstream issue in the video department.
[...]
 Versions of packages xserver-xorg depends on:
 ii  fglrx-driver [xorg-driver-video]   1:15.7-1

You have fglrx installed, which is the closed source driver, so the
complaints about open source drivers are entirely not valid.

A cursory look at your xorg log reveals all manner of fglrx related
errors (for starters, its looking for dri in the wrong paths).

Best wishes,
Mike

Bug#795544: xorg: open source video drivers flawed?

[Michael Gilbert]

control: reassign -1 src:fglrx-driver

On Sat, Aug 15, 2015 at 4:23 AM, Richard Jasmin wrote:
 It seems either development is stalled on open source drivers or we have an
 upstream issue in the video department.
[...]
 Versions of packages xserver-xorg depends on:
 ii  fglrx-driver [xorg-driver-video]   1:15.7-1

You have fglrx installed, which is the closed source driver, so the
complaints about open source drivers are entirely not valid.

A cursory look at your xorg log reveals all manner of fglrx related
errors (for starters, its looking for dri in the wrong paths).

Best wishes,
Mike

Bug#794911: bind9: bind9 update does not work, impossible to install

[Michael Gilbert]

control: tag -1 moreinfo, unreproducible, -security
control: severity -1 important

On Fri, Aug 7, 2015 at 7:08 PM, reinhard wrote:
 Package: bind9-host
 Version: 1:9.8.4.dfsg.P1-6+nmu2+deb7u4
 Severity: serious
 File: bind9
 Tags: security
 Justification: fails to build from source (but built successfully in the past)

Which of these problems you're actually facing?  Are you unable to
install bind9-host or are you unable to build the package from source?

Both work fine for me in wheezy.

Maybe try installing +deb7u6, which is on debian-security now, instead
of +deb7u4?

Best wishes,
Mike


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

Bug#794990: mrpt: ftbfs with new libstdc++ ABI

[Michael Gilbert]

Source: mrpt
Version: 1:1.2.2-1.1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
User: debian-...@lists.debian.org
Usertags: libstdc++-cxx11

This package fails to build with the new libstdc++ ABI (with updated
libassimp3, #794835).

The error has to do with undefined references to c++11 symbols:

../../lib/libmrpt-vision.so.1.3.1: undefined reference to
`cv::Exception::Exception(int, std::__cxx11::basic_stringchar,
std::char_traitschar, std::allocatorchar  const,
std::__cxx11::basic_stringchar, std::char_traitschar,
std::allocatorchar  const, std::__cxx11::basic_stringchar,
std::char_traitschar, std::allocatorchar  const, int)'
../../lib/libmrpt-hwdrivers.so.1.3.1: undefined reference to
`cv::FileStorage::FileStorage(std::__cxx11::basic_stringchar,
std::char_traitschar, std::allocatorchar  const, int,
std::__cxx11::basic_stringchar, std::char_traitschar,
std::allocatorchar  const)'
../../lib/libmrpt-vision.so.1.3.1: undefined reference to
`cv::Algorithm::_create(std::__cxx11::basic_stringchar,
std::char_traitschar, std::allocatorchar  const)'
collect2: error: ld returned 1 exit status
apps/camera-calib/CMakeFiles/camera-calib.dir/build.make:215: recipe
for target 'bin/camera-calib' failed

Forcing the build to use g++-4.9 or -std=c++98 doesn't help.

Best wishes,
Mike


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

Bug#794835: assimp: FTBFS with g++-5

[Michael Gilbert]

control: tag -1 patch

Hi,

Here is a trivial patch.  Updating the symbols file is a better
solution since neither of the reverse dependencies rely on the changed
symbols.  I've tested that doomsday builds fine after this patch.
mrpt does fail to build with g++ 5 (I've submitted bug #794990 about
that), which is due to a different problem, not the symbol change from
this package.

Best wishes,
Mike
diff -Nru assimp-3.0~dfsg/debian/changelog assimp-3.0~dfsg/debian/changelog
--- assimp-3.0~dfsg/debian/changelog	2015-04-27 20:28:02.0 +
+++ assimp-3.0~dfsg/debian/changelog	2015-08-09 05:12:07.0 +
@@ -1,3 +1,11 @@
+assimp (3.0~dfsg-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build with g++ 5 and update symbols for the libstdc++ ABI change
+(closes: #794835).
+
+ -- Michael Gilbert mgilb...@debian.org  Sat, 08 Aug 2015 20:57:10 +
+
 assimp (3.0~dfsg-4) unstable; urgency=medium
 
   * Export ai* in C++-scope (Closes: #775890)
diff -Nru assimp-3.0~dfsg/debian/control assimp-3.0~dfsg/debian/control
--- assimp-3.0~dfsg/debian/control	2015-04-27 20:26:56.0 +
+++ assimp-3.0~dfsg/debian/control	2015-08-09 05:04:05.0 +
@@ -11,6 +11,7 @@
  python,
  python-dev (= 2.3.5-7),
  dpkg-dev (= 1.15.6),
+ g++ (=4:5.2.1-1),
  pkg-kde-tools,
  cmake,
  libboost-dev,
diff -Nru assimp-3.0~dfsg/debian/libassimp3.symbols assimp-3.0~dfsg/debian/libassimp3.symbols
--- assimp-3.0~dfsg/debian/libassimp3.symbols	2015-01-22 23:51:40.0 +
+++ assimp-3.0~dfsg/debian/libassimp3.symbols	2015-08-09 00:42:07.0 +
@@ -23,7 +23,6 @@
  (c++)Assimp::DefaultLogger::m_pLogger@Base 2.0.863
  (c++)Assimp::DefaultLogger::DefaultLogger(Assimp::Logger::LogSeverity)@Base 2.0.863
  (c++)Assimp::DefaultLogger::~DefaultLogger()@Base 2.0.863
- (c++|optional)Assimp::ProgressHandler::~ProgressHandler()@Base 2.0.863
  (c++)Assimp::Intern::AllocateFromAssimpHeap::operator delete[](void*)@Base 2.0.863
  (c++)Assimp::Intern::AllocateFromAssimpHeap::operator delete(void*)@Base 2.0.863
  (c++|subst)Assimp::Intern::AllocateFromAssimpHeap::operator new[]({c++:size_t})@Base 2.0.863
@@ -34,7 +33,6 @@
  (c++)Assimp::Logger::warn(char const*)@Base 3.0~
  (c++)Assimp::Logger::debug(char const*)@Base 3.0~
  (c++)Assimp::Logger::error(char const*)@Base 3.0~
- (c++|optional)Assimp::Logger::~Logger()@Base 2.0.863
  (c++)Assimp::Exporter::ExportToBlob(aiScene const*, char const*, unsigned int)@Base 3.0~
  (c++)Assimp::Exporter::SetIOHandler(Assimp::IOSystem*)@Base 3.0~
  (c++)Assimp::Exporter::RegisterExporter(Assimp::Exporter::ExportFormatEntry const)@Base 3.0~
@@ -43,8 +41,6 @@
  (c++)Assimp::Exporter::FreeBlob()@Base 3.0~
  (c++)Assimp::Exporter::Exporter()@Base 3.0~
  (c++)Assimp::Exporter::~Exporter()@Base 3.0~
- (c++|optional)Assimp::IOStream::~IOStream()@Base 2.0.863
- (c++|optional)Assimp::IOSystem::~IOSystem()@Base 2.0.863
  (c++)Assimp::Importer::SetIOHandler(Assimp::IOSystem*)@Base 2.0.863
  (c++)Assimp::Importer::RegisterLoader(Assimp::BaseImporter*)@Base 2.0.863
  (c++)Assimp::Importer::RegisterPPStep(Assimp::BaseProcess*)@Base 2.0.863
@@ -53,7 +49,7 @@
  (c++)Assimp::Importer::SetPropertyFloat(char const*, float, bool*)@Base 2.0.863
  (c++)Assimp::Importer::UnregisterLoader(Assimp::BaseImporter*)@Base 2.0.863
  (c++)Assimp::Importer::UnregisterPPStep(Assimp::BaseProcess*)@Base 2.0.863
- (c++)Assimp::Importer::SetPropertyString(char const*, std::basic_stringchar, std::char_traitschar, std::allocatorchar  const, bool*)@Base 2.0.863
+ (c++)Assimp::Importer::SetPropertyString(char const*, std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar  const, bool*)@Base 3.0~dfsg-4.1 
  (c++|subst)Assimp::Importer::ReadFileFromMemory(void const*, {c++:size_t}, unsigned int, char const*)@Base 2.0.863
  (c++)Assimp::Importer::SetProgressHandler(Assimp::ProgressHandler*)@Base 2.0.863
  (c++)Assimp::Importer::SetPropertyInteger(char const*, int, bool*)@Base 2.0.863
@@ -64,7 +60,6 @@
  (c++)Assimp::Importer::Importer()@Base 2.0.863
  (c++)Assimp::Importer::~Importer()@Base 2.0.863
  (c++)Assimp::LogStream::createDefaultStream(aiDefaultLogStream, char const*, Assimp::IOSystem*)@Base 2.0.863
- (c++|optional)Assimp::LogStream::~LogStream()@Base 2.0.863
  (c++)Assimp::Exporter::GetIOHandler() const@Base 3.0~
  (c++)Assimp::Exporter::GetErrorString() const@Base 3.0~
  (c++)Assimp::Exporter::GetOrphanedBlob() const@Base 3.0~
@@ -83,7 +78,7 @@
  (c++)Assimp::Importer::GetImporterCount() const@Base 3.0~
  (c++)Assimp::Importer::GetImporterIndex(char const*) const@Base 3.0~
  (c++)Assimp::Importer::GetPropertyFloat(char const*, float) const@Base 2.0.863
- (c++)Assimp::Importer::GetPropertyString(char const*, std::basic_stringchar, std::char_traitschar, std::allocatorchar  const) const@Base 2.0.863
+ (c++)Assimp::Importer::GetPropertyString(char const*, std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar  const) const@Base 3.0~dfsg-4.1
  (c++)Assimp::Importer

Bug#793903: bind9: diff for NMU version 1:9.9.5.dfsg-10.1

[Michael Gilbert]

On Wed, Jul 29, 2015 at 2:15 AM, Salvatore Bonaccorso wrote:
 Control: tags 793903 + pending

 Hi Mike,

 I've prepared an NMU for bind9 (versioned as 1:9.9.5.dfsg-10.1) and
 uploaded it to DELAYED/2. Please feel free to tell me if I should
 delay it longer or if I should cancel it instead and you handle the
 upload yourself.

Hi Salvatore,

I went ahead and handled it myself.  Thanks for the help!

Best wishes,
Mike


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

Bug#786909: chromium: unconditionally downloads binary blob

[Michael Gilbert]

Since this made it to LWN [0] and Y Combinator [1] with an incredible
amount of misinformation, let's attempt a (hopefully) non-hyped
conversation about this, which unfortunately didn't happen a few days
ago.

On Tue, Jun 16, 2015 at 9:15 AM, Christoph Anton Mitterer wrote:
 On Tue, 2015-06-16 at 00:49 -0400, Michael Gilbert wrote:
 Barring the obtusely incorrect rootkit miscategorization

 Well, as I've said,.. no one can really tell what it is, since it's a
 blob,... and even if one would assume that someone could correctly
 reverse engineer it, or reproducibly build it from public sources,
 there's absolutely no guarantee that malicious software might have been
 just distributed to selected people.

Except that the actual contents of the downloaded files in many ways
do not actually matter.  Those files are nacl executables, which are
sandboxed in any nacl-enabled chromium, so barring a sandbox escape
included in the files, this is functionally the same as visiting any
nacl website (less the fact that hotword automatically gets microphone
permission, which itself is worth independent critique).

Additionally, the Debian packages are intentionally built with nacl
disabled (in fact not built at all).  So, at least on Debian, even if
the downloaded files were in fact malicious, without a nacl
interpreter present, there is absolutely no way to trigger the
badness.

 oss-sec is a
 far better venue for discussion since Debian is not the only
 distribution that includes chromium 43 .

 I don't see how that would practically ever change something at the
 Debian level; this seems rather like simply pushing away and unpleasant
 issue.

Maybe now it's clear that a meaningful conversation at the time would
have preempted the ensuing misinformation campaign.

 And just because all other distros ship software which injects possibly
 malicious blobs, we don't have to do the same.

I simply do not follow the logic leading to this conclusion.  How does
engaging in discussion lead to any specific problem being ignored
exactly?

Anyway, if some incredibly basic homework had been done, you could
have convinced yourself of the non-issue nature of this problem,
rather than engaging in unfounded speculation.

 Anyway, I haven't said that banning such software from Debian would be
 the only solution... but at least these incidents come far too frequent
 recently, so apparently something needs to be done at Debian level to
 pro-actively prevent future cases/compromises like this.

That is exactly what Debian unstable is for, and in many ways it
worked as intended, except for the special snowflake that is chromium.
Since major chromium versions get uploaded to both unstable and stable
to fix security issues, problems introduced into unstable also
unfortunately get introduced to stable.

 And there's still no single sign of properly visible announcements to
 user what might have happened here. :(

Well, it is out there now [0,1], unfortunately with a huge amount of
misinformation.

Anyway the Debian security tracker is tracking this [2].  As stated
there, it will be fixed along with the next incoming round of chromium
security issues.  It is absolutely not worth fixing on its own.

Best wishes,
Mike

[0] https://lwn.net/Articles/648392
[1] https://news.ycombinator.com/item?id=9724409
[2] https://security-tracker.debian.org/tracker/TEMP-000-A21526


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

Bug#786909: Please stop (was: Bug#786909: chromium: unconditionally downloads binary blob)

[Michael Gilbert]

On Thu, Jun 18, 2015 at 8:23 PM, Christoph Anton Mitterer wrote:

 - still no DSA (or something like that)

See previous message.

 - still no concentrated effort at the Debian level to pro-actively work
 against such sources that include or more or less secretly download
 blobs

If you have an itch, please by all means go scratch it.  You will get
absolutely nowhere continuing to tell people that they need to drop
everything to scratch your particular itches.  No one gets to tell
anyone else how they should spend their Debian time.  That is an
incredibly obtrusive affront to personal freedom and self
actualization.  Please stop.

Best wishes,
Mike


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

Bug#786909: chromium: unconditionally downloads binary blob

[Michael Gilbert]

On Thu, Jun 18, 2015 at 7:33 PM, Steven Chamberlain wrote:
 Steven Chamberlain wrote:
 would the
 DFSG chromium browser be 'more' free if it disabled NaCl?

 Actually, in the build log I see disable_nacl=1

 I'm confused that hotword-x86-64.nexe is a NaCl module [0], even
 though Debian's chromium is built with NaCl 'disabled'?

Yes, nacl is intentionally disabled in the Debian packages, but that
itself doesn't have anything to do with the ability of the browser to
download files.

 Does this feature actually work at all, even if a user ticks
 Enable OK Google in chrome://settings;  is someone able to test that?

No, it does not work.  Obviously nacl applications cannot execute
without a nacl interpreter.

Best wishes,
Mike


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

Bug#786909: chromium: unconditionally downloads binary blob

[Michael Gilbert]

On Mon, Jun 15, 2015 at 11:16 PM, Christoph Anton Mitterer wrote:
 Shouldn't we see a DSA following this incident?

 Since no one really know which binaries have been downloaded there and
 what they actually do, and since it cannot be excluded that it was
 actually executed, such systems are basically to be considered
 compromised.

 Quite a deal of people choose open source just to prevent that - get
 untrustworthy / unverifiable code run on their systems - failed.


 And to be quite honest, I seriously consider the good faith of an such
 upstream which does these kinds of things and wonder whether it can be
 considered trustworthy enough to be part of Debian or whether it should
 be banned from it.
 More or less silently bundling proprietary code with open source
 software (especially but not only when enabled per default) can already
 be considered quite bad behaviour.

 But basically secretly downloading it leads to the question of possible
 malicious intent (and everyone knows that GoogleCo. do voluntarily
 and/or forcibly cooperate with NSA and friends).
 And I guess no one can prove that this blob didn't contain any rootkit,
 and even if - the rootkit'ed version may have been just distributed to
 certain people.
 The downloading makes it more or less impossible for the admin/user and
 especially for our maintainers to notice what's happening here
 (otherwise they'd need audit every line of code for any such
 occasions).


 And even if the blob wasn't evil: while I haven't looked at the code, I
 wouldn't even be surprised if the downloading itself is done
 insecurely.


 Worse, chromium isn't the only such rootkit-downloader,... this happens
 - to my taste - far to often in recent times,.. e.g. FF which secretly
 downloaded the OpenH264 blob.

Barring the obtusely incorrect rootkit miscategorization, oss-sec is a
far better venue for discussion since Debian is not the only
distribution that includes chromium 43 .

Best wishes,
Mike


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

Bug#786909: [Pkg-chromium-maint] Bug#786909: chromium: unconditionally downloads binary blob

[Michael Gilbert]

control: tag -1 confirmed, help

On Wed, May 27, 2015 at 7:25 AM, Yves-Alexis Perez wrote:
 Note that the binary blob is executed throught native client, which is
 not enabled by default, so I /think/ you need explicit action from the
 user (although if you enable NaCl for something else, then you might
 enable stuff you actually don't want).

I made a quick attempt at getting hotword disabled, but wasn't effective.

I won't have time to dig into the details for a while, so I'm
attaching the failed attempt to maybe inspire some other ideas.

Best wishes,
Mike
--- a/chrome/browser/extensions/api/hotword_private/hotword_private_api.cc
+++ b/chrome/browser/extensions/api/hotword_private/hotword_private_api.cc
@@ -121,7 +121,7 @@ bool HotwordPrivateSetEnabledFunction::R
   EXTENSION_FUNCTION_VALIDATE(params.get());
 
   PrefService* prefs = GetProfile()-GetPrefs();
-  prefs-SetBoolean(prefs::kHotwordSearchEnabled, params-state);
+  prefs-SetBoolean(prefs::kHotwordSearchEnabled, false);
   return true;
 }
 
--- a/chrome/browser/resources/options/browser_options.js
+++ b/chrome/browser/resources/options/browser_options.js
@@ -244,9 +244,6 @@ cr.define('options', function() {
   HotwordSearchSettingIndicator.decorate(hotwordIndicator);
   hotwordIndicator.disabledOnErrorSection =
   $('hotword-always-on-search-checkbox');
-  chrome.send('requestHotwordAvailable');
-
-  chrome.send('requestGoogleNowAvailable');
 
   if ($('set-wallpaper')) {
 $('set-wallpaper').onclick = function(event) {

Bug#786758: doomsday: segfault on startup

[Michael Gilbert]

On Mon, May 25, 2015 at 6:16 AM, Adam Borowski wrote:
 When trying to start doomsday, it pops up a dialog which says:
 .[ Doomsday Engine ]
 App init failed:
  [NotFoundError] (Record::subrecord) Subrecord 'alert' not found
 `
 then crashes with a segmentation fault.

This seems to be an incompatibility with persist.pack files from older versions.

If you backup ~/.doomsday/runtime/persist.pack to somewhere else, does
that work around the problem?

Best wishes,
Mike


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

Bug#781557: [pkg-wine-party] Bug#781557: How to allow apt or apt-get to solve this bug?

[Michael Gilbert]

On Sun, May 17, 2015 at 5:14 PM, Javier Barroso wrote:
 Hello,

 After apt update; apt dist-upgrade ; doesn't advance because this bug,
 I tried to use apt-get to remove broken packages, but I was not able
 to know how apt-get could solve this issue (holding/purging or
 rollbacking *wine* packages)

 I had to use aptitude gui to remove :

 libwine-development:amd64
 wine-development:amd64
 wine32-development:i386
 wine64-development:amd64

 So, If you were able to keep 1.7.29-4 or purging it, how did you get it work ?

Unfortunately the bug fix for this has been held up in the NEW queue
for more than a month:
https://ftp-master.debian.org/new.html

Pinging ftp masters for a review may help.

Best wishes,
Mike


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

Bug#782838: [gparted] Gparted fails to start

[Michael Gilbert]

control: tag -1 confirmed
control: retitle -1 gparted: fails to start with gvfs installed

I missed this during testing since I don't use gvfs. gparted can be
made to work again if the gvfs package is removed, but that of course
is not a real solution.

Best wishes,
Mike


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

Bug#782838: gvfs

[Michael Gilbert]

On Sat, Apr 18, 2015 at 4:49 PM, Søren Holm wrote:
 Removing gvfs does not work.

You'll probably need to reboot to get gvfs to completely go away.  See:
https://bugs.debian.org/544148

Best wishes,
Mike


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

Bug#782838: gvfs

[Michael Gilbert]

On Sat, Apr 18, 2015 at 6:31 PM, Søren Holm wrote:
 I did - didn't work :(

I guess there is more to it then, at least on lxde removing gvfs is
all it takes.  For other DEs you'll need to do some work to figure out
which other piece is also a problem.

Best wishes,
Mike


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

Bug#782838: gvfs

[Michael Gilbert]

control: reassign -1 udisks2
control: affects -1 gparted
control: retitle -1 udisks2-inhibit mount move fails

The problem is actually udisks2-inhibit.  The upstream fix for #781716
relies on that, but it doesn't seem to work:

$ sudo /usr/lib/udisks2/udisks2-inhibit /usr/bin/true
mount: bad option. Note that moving a mount residing under a shared
mount is unsupported.

The following is the command in the udisks2-inhibit script that fails

$ mount --move /run/udisks2/inhibit-polkit
/var/lib/polkit-1/localauthority/90-mandatory.d


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

Bug#782626: Debug symbols can't be used

[Michael Gilbert]

control: severity -1 normal

On Wed, Apr 15, 2015 at 3:16 AM, Andrey Rahmatullin wrote:
 Reading symbols from kvpnc...Reading symbols from
 /usr/lib/debug//usr/bin/kvpnc...(no debugging symbols found)...done.
 (no debugging symbols found)...done.

Debugging symbols is a should in debian policy.

Best wishes,
Mike


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

Bug#775235: Bug#776911: gnome-shell: fails to start on i386 when [Mesa was] built with llvm-3.5

[Michael Gilbert]

control: severity -1 wishlist
control: forwarded -1 https://freedesktop.org/patch/34445
control: retitle -1 mesa: use llvm's getCPUTargetFeatures() instead of
getHostCPUName()

It turns out that mesa uses llvm's getHostCPUName(), and qemu i386 by
default (correctly) reports itself as pentium2, which is assumed
non-sse2. gnome-shell uses a mesa feature that requires sse2, so it
fails at startup on qemu i386.

On llvm trunk they've implemented getCPUTargetFeatures(), which can be
used to check for specific cpu features like sse2, and that is the
long term solution to the problem:
https://llvm.org/bugs/show_bug.cgi?id=23201

In the meantime, the problem can be worked around by using a
non-default qemu cpu options.  Some examples:

$ qemu -cpu pentium3 test.img
$ kvm -cpu host test.img

Since there workarounds are straightforward I am reducing the severity.

Best wishes,
Mike


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

Bug#782678: motif: ftbfs missing symbol

[Michael Gilbert]

package: src:motif
version: 2.3.4-6.1
severity: serious
tag: patch

There was a symbol removed in this upload that upstream intended to be
private.  It's likely unused in other packages, but for confidence
that it doesn't lead to breakage, motif's reverse dependencies should
be checked.

Attached is a fix (same also applied in ubuntu) that I do not plan to
upload since I don't have the time to test all of the reverse deps
myself.

Best wishes,
Mike
diff -Nru motif-2.3.4/debian/changelog motif-2.3.4/debian/changelog
--- motif-2.3.4/debian/changelog	2015-04-12 15:34:03.0 -0400
+++ motif-2.3.4/debian/changelog	2015-04-15 20:31:50.0 -0400
@@ -1,3 +1,10 @@
+motif (2.3.4-6.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove symbol that was intended to be private.
+
+ -- Michael Gilbert mgilb...@debian.org  Thu, 16 Apr 2015 00:16:42 +
+
 motif (2.3.4-6.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru motif-2.3.4/debian/libxm4.symbols motif-2.3.4/debian/libxm4.symbols
--- motif-2.3.4/debian/libxm4.symbols	2014-10-07 09:57:54.0 -0400
+++ motif-2.3.4/debian/libxm4.symbols	2015-04-15 20:40:31.0 -0400
@@ -257,7 +257,7 @@
  XmFontListInitFontContext@Base 2.3.4
  XmFontListNextEntry@Base 2.3.4
  XmFontListRemoveEntry@Base 2.3.4
- XmForceGrabKeyboard@Base 2.3.4-5~
+#MISSING: 2.3.4-6.1# XmForceGrabKeyboard@Base 2.3.4-5~
  XmGetAtomName@Base 2.3.4
  XmGetColorCalculation@Base 2.3.4
  XmGetColors@Base 2.3.4

Bug#781995: motif/2.3.4-6.1 failed to build

[Michael Gilbert]

On Wed, Apr 15, 2015 at 3:12 PM, Paul Gevers wrote:
 Hi all,

 All the builds of motif failed [1] due to a missing symbol. What are we
 going to do? I saw that Graham already choose to just remove the symbol
 from the Ubuntu package. I believe that this is really a no-no,
 especially without careful investigation if other packages are using
 this symbol and this late in the release process. Can we come up with a
 better solution?

Upstream intends that symbol to be private, so it should be unused in
other packages.  But for confidence that it doesn't lead to breakage,
someone should build test the reverse dependencies, which is a large
number.  Graham can you do that?

It's rather late in the release cycle, so maybe leave things alone for
now, and plan to do a jessie-pu once that testing is complete?

 @Michael, how did you build the package that you didn't notice this
 issue in your build?

I only did debian/rules build while testing, and debian/rules
binary-indep to finish up, which missed the dpkg-gensymbols step.
That was a mistake on my part.  I should have done a test of the
binary-arch step also, but it slipped my mind, apologies.

Best wishes,
Mike


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

Bug#782653: openmpi: Fails to build from source

[Michael Gilbert]

control: tag -1 unreproducible, moreinfo

On Wed, Apr 15, 2015 at 1:29 PM, Mario Lang wrote:
 openmpi fails to build:

 $ apt-get source openmpi
 $ cd openmpi-1.6.5
 $ dpkg-buildpackage -uc -us

 (log attached)

 Note that the problem seems to be related to timestamping of
 config/libtool.m4 (at least this file, maybe others as well).

 Before execution of dpkg-buildpackage, the file looks like this:

 -rw-r--r-- 1 mlang mlang 286350 Jun 26  2013 config/libtool.m4

 And after dpkg-buildpackage failed, it looks like this:

 -rw-r--r-- 1 mlang mlang 286793 Jän  1  1970 config/libtool.m4

 Note the date, this seems to confuse the build process.

I see the same timestamp change in unstable and jessie chroot builds,
but both also built to completion.  There is also success on the
buildds, so this may not need to be RC.  Do you have any other
information about your build setup?

Best wishes,
Mike


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

Bug#782438: timidity-daemon: fails to start at boot-up but timidity starts manually ok

[Michael Gilbert]

control: severity -1 important

Given the straightforward workaround, this isn't a grave issue.

Best wishes,
Mike


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

Bug#781716: gparted: partitioning fails due to lack of udisks2 locking and automount

[Michael Gilbert]

control: tag -1 patch, pending

Hi,

I applied and tested upstream's fix for this issue.  It works, so I
uploaded an nmu to delayed/5.  Please let me know if I should delay
longer.

Best wishes,
Mike
diff -Nru gparted-0.19.0/debian/changelog gparted-0.19.0/debian/changelog
--- gparted-0.19.0/debian/changelog	2014-11-09 21:45:29.0 +
+++ gparted-0.19.0/debian/changelog	2015-04-12 19:02:57.0 +
@@ -1,3 +1,11 @@
+gparted (0.19.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply upstream fix to prevent automounting during partitioning on systems
+using udisks2 (closes: #781716).
+
+ -- Michael Gilbert mgilb...@debian.org  Sun, 12 Apr 2015 18:31:55 +
+
 gparted (0.19.0-2) unstable; urgency=medium
 
   * 03_fix-crash.patch: cherry pick of upstream commit that fixes
diff -Nru gparted-0.19.0/debian/patches/04_inhibit-udisks2.patch gparted-0.19.0/debian/patches/04_inhibit-udisks2.patch
--- gparted-0.19.0/debian/patches/04_inhibit-udisks2.patch	1970-01-01 00:00:00.0 +
+++ gparted-0.19.0/debian/patches/04_inhibit-udisks2.patch	2015-04-12 19:02:49.0 +
@@ -0,0 +1,78 @@
+From 4acb8e4fbb9e01d33cc1e9fd89686a3818050690
+From: Curtis Gedak ged...@gmail.com
+Date: Tue, 10 Mar 2015 10:56:47 -0600
+Subject: If available use udisks2-inhibit to prevent automounting (#745349)
+
+In order to prevent potential corruption of newly created file systems,
+when available use udisks2-inhibit with gpartedbin execution to prevent
+automounting.
+
+Original report:
+
+Xubuntu install fail due partition auto mount defeats Gparted
+https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1078445
+
+Some GNU/Linux distributions use the udisks2 udisksd daemon and have
+udisks2-inhibit at a known location.  The known location is not in the
+default PATH environment variable.
+
+One known distribution that matches this criteria is xubuntu 14.04.
+
+Interestingly neither kubuntu 14.04 nor ubuntu 14.04 appear to have the
+udisks2 udisksd daemon running and do not suffer from this specific
+automounting problem.
+
+Bug 745349 - gparted wrapper script needs updated for udisks2
+
+diff --git a/gparted.in b/gparted.in
+index 54e208f..c435bac 100755
+--- a/gparted.in
 b/gparted.in
+@@ -9,7 +9,7 @@
+ #GParted's operations, or if multiple partition editing
+ #tools are in use concurrently.
+ #
+-# Copyright (C) 2008, 2009, 2010, 2013 Curtis Gedak
++# Copyright (C) 2008, 2009, 2010, 2013, 2015 Curtis Gedak
+ #
+ #  This file is part of GParted.
+ #
+@@ -51,6 +51,17 @@ for k in '' `echo $PATH | sed 's,:, ,g'`; do
+ done
+ 
+ #
++#  Check if udisks2-inhibit exists in known location
++#  and if appropriate daemon is running.
++#
++HAVE_UDISKS2_INHIBIT=no
++if test -x /usr/lib/udisks2/udisks2-inhibit; then
++	if test z`ps -e | grep 'udisksd'` != z; then
++		HAVE_UDISKS2_INHIBIT=yes
++	fi
++fi
++
++#
+ #  Search PATH to determine if udisks program can be found
+ #  and if appropriate daemon is running.
+ #
+@@ -150,7 +161,8 @@ for rule in $UDEV_TEMP_MDADM_RULES; do
+ done
+ 
+ #
+-#  Use both udisks and hal-lock for invocation if both binaries exist and both
++#  Use udisks2-inhibit if udisks2-inhibit exists and deamon running.
++#  Else use both udisks and hal-lock for invocation if both binaries exist and both
+ #  daemons are running.
+ #  Else use udisks if binary exists and daemon is running.
+ #  Else use both devkit-disks and hal-lock for invocation if both binaries exist
+@@ -159,7 +171,9 @@ done
+ #  Otherwise use hal-lock for invocation if binary exists and daemon is running.
+ #  If the above checks fail then simply run gpartedbin.
+ #
+-if test x$HAVE_UDISKS = xyes  test x$HAVE_HAL_LOCK = xyes; then
++if test x$HAVE_UDISKS2_INHIBIT = xyes; then
++	/usr/lib/udisks2/udisks2-inhibit $BASE_CMD
++elif test x$HAVE_UDISKS = xyes  test x$HAVE_HAL_LOCK = xyes; then
+ 	udisks --inhibit -- \
+ 		hal-lock --interface org.freedesktop.Hal.Device.Storage --exclusive \
+ 			--run $BASE_CMD
diff -Nru gparted-0.19.0/debian/patches/series gparted-0.19.0/debian/patches/series
--- gparted-0.19.0/debian/patches/series	2014-11-09 21:38:31.0 +
+++ gparted-0.19.0/debian/patches/series	2015-04-12 19:02:49.0 +
@@ -2,3 +2,5 @@
 02_use-pkexec.patch
 
 03_fix-crash.patch
+
+04_inhibit-udisks2.patch

Bug#781995: Bug#782381: pre-approval: unblock: motif/2.3.4-8

[Michael Gilbert]

control: tag 781995 pending

On Sat, Apr 11, 2015 at 7:41 AM, Graham Inggs wrote:
 Hi release team

 In order to fix RC bug #781995, I would like to upload a version of
 Motif with upstream's fix for their bug #1565 reverted.  I plan to
 replace debian/patches/18-updated-fix1565.patch with the following:

 --- a/lib/Xm/XmI.h
 +++ b/lib/Xm/XmI.h
 @@ -297,7 +297,6 @@
  #define FIX_1501
  #define FIX_1521
  #define FIX_1505
 -#define FIX_1565

  #endif /* _XmI_h */
  /* DON'T ADD ANYTHING AFTER THIS #endif */

 Not defining FIX_1565 causes popup menus and keyboard navigation in
 menus to revert to their behaviour in Motif 2.3.3.  This fixes #781995
 and #730026 remains fixed.

I just caught this message after preparing an nmu today.  I applied
your suggested changes (in a more minimal way than you suggest),
tested the problem was fixed, and uploaded the nmu to delayed/5.

If you would prefer it to be a sponsored upload, or if you want me to
delay/alter the nmu please let me know.

Best wishes,
Mike
diff -Nru motif-2.3.4/debian/changelog motif-2.3.4/debian/changelog
--- motif-2.3.4/debian/changelog	2014-10-13 07:27:43.0 +
+++ motif-2.3.4/debian/changelog	2015-04-12 19:34:03.0 +
@@ -1,3 +1,10 @@
+motif (2.3.4-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Disable buggy fix for upstream bug #1565 (closes: #781995).
+
+ -- Michael Gilbert mgilb...@debian.org  Sun, 12 Apr 2015 19:25:51 +
+
 motif (2.3.4-6) unstable; urgency=medium
 
   * Bump standards-version to 3.9.6 (no changes).
diff -Nru motif-2.3.4/debian/patches/22-disable-1565.patch motif-2.3.4/debian/patches/22-disable-1565.patch
--- motif-2.3.4/debian/patches/22-disable-1565.patch	1970-01-01 00:00:00.0 +
+++ motif-2.3.4/debian/patches/22-disable-1565.patch	2015-04-12 19:31:45.0 +
@@ -0,0 +1,14 @@
+Description: Fix for upstream 1565 causes segfaults in motif applications, so disable it
+Author: Graham Inggs gra...@nerve.org.za
+Bug-Debian: https://bugs.debian.org/781995
+
+--- a/lib/Xm/XmI.h
 b/lib/Xm/XmI.h
+@@ -299,7 +299,6 @@ extern Pixel _XmAssignInsensitiveColor(W
+ #define FIX_1501
+ #define FIX_1521
+ #define FIX_1505
+-#define FIX_1565
+ 
+ #endif /* _XmI_h */
+ /* DON'T ADD ANYTHING AFTER THIS #endif */
diff -Nru motif-2.3.4/debian/patches/series motif-2.3.4/debian/patches/series
--- motif-2.3.4/debian/patches/series	2014-10-13 07:27:43.0 +
+++ motif-2.3.4/debian/patches/series	2015-04-12 19:29:28.0 +
@@ -19,3 +19,4 @@
 19-fix-type-inconsistencies.patch
 20-fix-1612.patch
 21-fix-1636.patch
+22-disable-1565.patch

Bug#781995: Bug#782381: pre-approval: unblock: motif/2.3.4-8

[Michael Gilbert]

On Sun, Apr 12, 2015 at 5:14 PM, Graham Inggs wrote:
 So what is the best way forward?

 I have no problems with Michael's upload (thanks!) apart from the delay.

I can reschedule to delayed/0 if as the maintainer you say that's ok.

 Paul and I were just considering adding the line:
 Recommends: xfonts-100dpi | xfonts-75dpi | xfonts-100dpi-transcoded |
 xfonts-75dpi-transcoded
 to libxm4 in motif (see LP: #1415309).  I haven't decided yet if it's
 better to go in libxm4 or nedit.

If there isn't an RC bug about that, then it's likely not appropriate
at this point in the freeze.

Best wishes,
Mike


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

Bug#782365: gxine crashes at start

[Michael Gilbert]

control: severity -1 normal

On Fri, Apr 10, 2015 at 8:13 PM, Christoph Anton Mitterer wrote:
 ii  libdvdcss2 [libdvdcss]  1.3.0-dmo1

Your system is tainted by deb-multimedia.org.

 Kernel: Linux 3.19.0-trunk-amd64 (SMP w/8 CPU cores)

Also possibly kernel related.  Please try the jessie kernel.

Best wishes,
Mike


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

Bug#775878: libmono-corlib4.5-cil: circular dependencies cause failures in some upgrade scenarios

[Michael Gilbert]

control: severity -1 important
control: retitle -1 libmono-corlib4.5-cil: possible dpkg trigger cycle

On Wed, Mar 25, 2015 at 5:26 PM, Niels Thykier wrote:
 Is this upgrade problem still reproducible?  There was an upload of dpkg
 between you filing this upload.  I do realise this does not affect the
 mono dependency cycle - but if the upgrade now works, then it was
 probably a trigger cycle.

I just did a wheezy-jessie test upgrade with libmono-corlib4.0-cil
initially installed and it went fine.

Best wishes,
Mike


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

Bug#779931: [Pkg-utopia-maintainers] Bug#779931: sk_disk_check_sleep_mode: Operation not supported for USB3 HDD docking based on JMicron 152d:0551

[Michael Gilbert]

control: severity -1 important

On Mon, Mar 9, 2015 at 10:07 AM, Gianluca Oglietti wrote:
 If the problem is the kernel, can you suggest me a way to debug this issue?

Try starting a discussion on the linux kernel mailing list (lkml.org)
or bugzilla (bugzilla.kernel.org).

Best wishes,
Mike


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

Bug#781176: byobu: fails to start when using shared NFS home

[Michael Gilbert]

control: severity -1 important

On Wed, Mar 25, 2015 at 1:21 PM, Dominik George wrote:
 This bug is possibly security relevant because the intention of the
 script, namely separating user directories in /dev/shm, is entirely
 defeated. As a matter of lucky fact, / is not writable by regular users.
 However, this will break even more once root decides to use byobu and
 succeeds in creating /cache.tmux (or whatever byobu will create for
 other backends). Please find out whether this is exploitable in any way.

Poor behavior by apps running as root does not automatically imply
security relevance.

Best wishes,
Mike


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

Bug#761345: kmk treats mixed implicit and normal rules as a fatal error

[Michael Gilbert]

control: severity -1 important

This looks like it no longer needs to be release critical since
#731341 was fixed without changes to kbuild.

Best wishes,
Mike


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

Bug#780503: icu: incomplete fix for CVE-2014-7940

[Michael Gilbert]

package: src:icu
version: 52.1-7.1
severity: serious
tags: security

Google added another check in a later patch for this issue, which
wasn't included in the previous nmu:
https://chromium.googlesource.com/chromium/deps/icu/+/a626a75aad2675254073366fcaa9465dacf17100/patches/col.patch

Best wishes,
Mike


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

Bug#780503: icu: incomplete fix for CVE-2014-7940

[Michael Gilbert]

control: tag -1 patch, pending

On Sat, Mar 14, 2015 at 9:48 PM, Michael Gilbert wrote:
 Google added another check in a later patch for this issue, which
 wasn't included in the previous nmu:

Hi,

I uploaded an nmu to delayed/3 fixing this problem.  Please see attached.

Best wishes,
Mike
diff -Nru icu-52.1/debian/changelog icu-52.1/debian/changelog
--- icu-52.1/debian/changelog	2015-02-16 02:35:11.0 +
+++ icu-52.1/debian/changelog	2015-03-15 02:05:39.0 +
@@ -1,3 +1,11 @@
+icu (52.1-7.2) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Apply a more complete fix for CVE-2014-7940 (closes: #780503).
+- Thanks to Marc Deslauriers.
+
+ -- Michael Gilbert mgilb...@debian.org  Sun, 15 Mar 2015 01:57:48 +
+
 icu (52.1-7.1) unstable; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru icu-52.1/debian/patches/CVE-2014-7940.patch icu-52.1/debian/patches/CVE-2014-7940.patch
--- icu-52.1/debian/patches/CVE-2014-7940.patch	2015-02-16 02:35:11.0 +
+++ icu-52.1/debian/patches/CVE-2014-7940.patch	2015-03-15 02:15:42.0 +
@@ -1,8 +1,12 @@
 description: uninitialized memory issue
-origin: https://chromium.googlesource.com/chromium/deps/icu/+/866ff696e9022a6000afbab516fba62cfa306075
+origin: https://chromium.googlesource.com/chromium/deps/icu/+/a626a75aad2675254073366fcaa9465dacf17100/patches/col.patch
 
 icu-52.1.orig/source/i18n/ucol.cpp
-+++ icu-52.1/source/i18n/ucol.cpp
+Updated by Marc Deslauriers marc.deslauri...@canonical.com to also fix a
+regression when running the test suite because source-endp was being
+used without checking UCOL_ITER_HASLEN.
+
+--- a/source/i18n/ucol.cpp
 b/source/i18n/ucol.cpp
 @@ -2259,6 +2259,9 @@ inline UChar getNextNormalizedChar(collI
  if (data-pos + 1 == data-endp) {
  return *(data-pos ++);
@@ -13,13 +17,17 @@
  }
  else {
  if (innormbuf) {
-@@ -2821,7 +2824,13 @@ uint32_t ucol_prv_getSpecialCE(const UCo
+@@ -2820,8 +2823,16 @@ uint32_t ucol_prv_getSpecialCE(const UCo
+ goBackOne(source);
  }
  }
- } else if (U16_IS_LEAD(schar)) {
+-} else if (U16_IS_LEAD(schar)) {
 -miss = U16_GET_SUPPLEMENTARY(schar, getNextNormalizedChar(source));
-+UChar nextChar = getNextNormalizedChar(source);
++} else if (U16_IS_LEAD(schar) 
++   ((source-flags  UCOL_ITER_HASLEN) == 0 ||
++source-pos + 1  source-endp)) {
 +const UChar* prevPos = source-pos;
++UChar nextChar = getNextNormalizedChar(source);
 +if (U16_IS_TRAIL(nextChar)) {
 +miss = U16_GET_SUPPLEMENTARY(schar, nextChar);
 +} else if (prevPos  source-pos) {

Bug#776137: sudo: fails to switch between sudo and sudo-ldap: chown: cannot access '/etc/sudoers': No such file or directory

[Michael Gilbert]

On Sun, Feb 22, 2015 at 6:35 AM, Christian Kastner wrote:
 In wheezy and later, where /etc/sudoers already is a conffile, that is
 entirely for dpkg to handle, not for the *.preinst scripts. Anything in
 the *.preinst is exclusively for when upgrading from squeeze.

So, the more I think about it, isn't this the real problem?  The
*.preinst scripts mess with wheezy's /etc/sudoers even though it
should only be managed by dpkg.

Best wishes,
Mike


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

Bug#777722: xdg-utils: diff for NMU version 1.1.0~rc1+git20111210-7.4

[Michael Gilbert]

On Fri, Feb 20, 2015 at 10:49 AM, Salvatore Bonaccorso wrote:
 Control: tags 22 + pending

 Dear maintainer,

 I've prepared an NMU for xdg-utils (versioned as 1.1.0~rc1+git20111210-7.4) 
 and
 uploaded it to DELAYED/2. Please feel free to tell me if I
 should delay it longer.

Hi Salvatore,

xdg-utils is nmu-maintained for a long time now, so I would consider
the package effectively orphaned [0], and upload with out delay.

Best wishes,
Mike

[0] http://bugs.debian.org/774590


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

Bug#776911: gnome-session: session fails to start with something went wrong message

[Michael Gilbert]

control: forcemerge 775235 -1

On Fri, Feb 6, 2015 at 1:20 PM, Simon McVittie wrote:
 Michael, I see you've found a solution or workaround: is there
 anything you'd like Rafal to try?

Try gnome-shell built with llvm-3.4 instead of 3.5.

Best wishes,
Mike


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

Bug#774363: gnome crashes/freezes seemingly random

[Michael Gilbert]

control: severity -1 important

Without any feedback or debugging, and since you're the only one
experiencing these problems, there isn't much that can be done.

Best wishes,
Mike


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

Bug#776137: sudo: fails to switch between sudo and sudo-ldap: chown: cannot access '/etc/sudoers': No such file or directory

[Michael Gilbert]

On Fri, Feb 6, 2015 at 7:02 PM, Christian Kastner wrote:
 I've looked into this now, and I believe that the --compare-versions
 issue and the chown/chmod issue is all there is to this bug. I have
 attached a new debdiff (v2) with fixes for both.

I reviewed your proposed changes, but I don't think it's the right
approach.  The origin of the problem is that the md5sum of
/etc/sudoers is the same for wheezy and later, so the logic intended
to back it up only for wheezy ends up incorrectly backing it up in
jessie and later too.

The solution I propose to modify /etc/sudoers so that it has a
different checksum, which prevents the incorrect backup.  Please see
attached.

I plan to upload this fix to unstable in a few days if there isn't any feedback.

Best wishes,
Mike
diff -Nru sudo-1.8.11p2/debian/changelog sudo-1.8.11p2/debian/changelog
--- sudo-1.8.11p2/debian/changelog	2014-12-21 18:56:21.0 +
+++ sudo-1.8.11p2/debian/changelog	2015-02-22 00:49:23.0 +
@@ -1,3 +1,11 @@
+sudo (1.8.11p2-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Modify /etc/sudoers so it has a different checksum than wheezy, which
+prevents it from being incorrectly removed (closes: #776137).
+
+ -- Michael Gilbert mgilb...@debian.org  Sun, 22 Feb 2015 00:30:33 +
+
 sudo (1.8.11p2-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru sudo-1.8.11p2/debian/sudoers sudo-1.8.11p2/debian/sudoers
--- sudo-1.8.11p2/debian/sudoers	2014-10-30 18:24:17.0 +
+++ sudo-1.8.11p2/debian/sudoers	2015-02-22 00:48:04.0 +
@@ -1,4 +1,3 @@
-#
 # This file MUST be edited with the 'visudo' command as root.
 #
 # Please consider adding local content in /etc/sudoers.d/ instead of

Bug#776137: sudo: fails to switch between sudo and sudo-ldap: chown: cannot access '/etc/sudoers': No such file or directory

[Michael Gilbert]

On Sat, Feb 21, 2015 at 9:52 PM, Christian Kastner wrote:
 It's not backed up in jessie or later. The backup/md5sum stuff is
 preceeded by a test for and old version less than 1.7.4p4-4, so in
 wheezy and later, all the md5sum stuff is ignored during upgrades.

It is most certainly backed up in jessie or later.  That happens
during install rather than upgrade, which you describe below
anyway.

 However, the backup code is accidentally triggered when switching
 between sudo and sudo-ldap, because switching is not upgrading (in the
 dpkg sense), and the version test above does not account for this scenario:

 preinst
 $ dpkg --compare-versions  le 1.7.4p4-4  echo oops
   oops

 The solution I propose to modify /etc/sudoers so that it has a
 different checksum, which prevents the incorrect backup.  Please see
 attached

 This has one nasty side effect: when upgrading from wheezy to jessie,
 anyone with a changed /etc/sudoers will be asked a conffile question,
 because both the local and the maintainer's version changed.

That is true for conffiles in general, but will not be the case for
sudo because its *.preinst moves /etc/sudoers for lenny/squeeze/wheezy
out of the way to /etc/sudoers.pre-conffile.

 Modifying sudoers so that it has a checksum can't be right, because the
 code where the checksum is relevant shouldn't have been reached in the
 first place (in wheezy or later).

It is possible that the user removed the package, then installed it
later.  That is why the install path also has handling for old
/etc/sudoers, to perform backup in that case also.

 Fixing the --compare-versions above does precisely that -- the md5sum
 stuff is never even reached.

With that approach the check is now not reached in cases where it should.

Best wishes,
Mike


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

Bug#778733: bind9: CVE-2015-1349 named crash

[Michael Gilbert]

package: src:bind9
severity: serious
tags: security

A new security issue was disclosed for bind9:
https://security-tracker.debian.org/tracker/CVE-2015-1349


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