Bug#1076135: reptyr: FTBFS: add support for loongarch64

[Evan Broder]

Hi -

Can you please work with the upstream project (
https://github.com/nelhage/reptyr) to add support for loongarch64? I would
prefer to not carry a patch local to the Debian packaging for a new arch
given that upstream is generally responsive to new architectures.

- Evan

Bug#1065519: phosh-full: Phosh not booting on login or from cmd on OrangePi

[Evan Robinson]

Package: phosh-full
Version: 31
Severity: important
X-Debbugs-Cc: no-re...@ejrdesign.co.za

Dear Maintainer,

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

   * What led up to the situation?
Bought an OrangePi CM4 and booted the Debian Bookwork image from the SBC 
manufacturer.
Upgraded to Debian testing.
Ran 'apt get install phosh-full'
Rebooted and tried to login to the Phosh DM.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Tried to login to the Phosh DM on the login page.

   * What was the outcome of this action?
Screen goes blank, saw a blinking cursor for about 5 - 10 sec, then the login 
screen loaded again.

   * What outcome did you expect instead?
To login to the OrangePi desktop andh ave it look like a phone layout due to 
Phosh.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.10.160-rockchip-rk356x (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages phosh-full depends on:
ii  avahi-daemon 0.8-13+b1
ii  cups-pk-helper   0.2.6-1+b1
ii  desktop-base 12.0.6+nmu1
ii  gnome-clocks 45.0-1
ii  gnome-console45.0-1
ii  gstreamer1.0-libav   1.22.10-1
ii  gstreamer1.0-plugins-ugly1.22.10-1
ii  libproxy1-plugin-networkmanager  0.4.18-2
ii  lollypop 1.4.37-1
ii  phosh-core   31
ii  phosh-pim31
ii  totem-plugins43.0-3

Versions of packages phosh-full recommends:
ii  chatty 0.8.1-1
pn  gnome-usage
pn  phosh-games
pn  phosh-plugins  

Versions of packages phosh-full suggests:
ii  phosh-phone  31

-- no debconf information

Here are some logs from journal:

Mar 05 20:33:30 orangepicm4 polkitd[842]: Registered Authentication Agent for 
unix-process:3164:26832 (system bus name :1.74 [/usr/bin/pkttyagen>
Mar 05 20:33:30 orangepicm4 brltty[537]: unsupported generic resource 
identifier: bluetooth:
Mar 05 20:33:30 orangepicm4 brltty[537]: brltty: unsupported generic resource 
identifier: bluetooth:
Mar 05 20:33:35 orangepicm4 brltty[537]: unsupported generic resource 
identifier: bluetooth:
Mar 05 20:33:35 orangepicm4 brltty[537]: brltty: unsupported generic resource 
identifier: bluetooth:
Mar 05 20:33:35 orangepicm4 systemd[1751]: mmsd-tng.service: Scheduled restart 
job, restart counter is at 24.
Mar 05 20:33:35 orangepicm4 systemd[1751]: Started mmsd-tng.service - 
Multimedia Messaging Service Daemon.
Mar 05 20:33:35 orangepicm4 mmsdtng[3180]: MMSD-TNG version 2.6.0, git version: 
2.6.0
Mar 05 20:33:35 orangepicm4 mmsdtng[3180]: Lost Dbus Connection! Exiting
Mar 05 20:33:35 orangepicm4 systemd[1751]: mmsd-tng.service: Main process 
exited, code=exited, status=1/FAILURE
Mar 05 20:33:35 orangepicm4 systemd[1751]: mmsd-tng.service: Failed with result 
'exit-code'.
Mar 05 20:33:37 orangepicm4 polkitd[842]: Operator of unix-session:2 
successfully authenticated as unix-user:orangepi to gain TEMPORARY authoriz>
Mar 05 20:33:37 orangepicm4 systemd[1]: Stopping getty@tty1.service - Getty on 
tty1...
Mar 05 20:33:37 orangepicm4 systemd[1]: getty@tty1.service: Deactivated 
successfully.
Mar 05 20:33:37 orangepicm4 systemd[1]: Stopped getty@tty1.service - Getty on 
tty1.
Mar 05 20:33:37 orangepicm4 systemd[1]: session-4.scope: Deactivated 
successfully.
Mar 05 20:33:37 orangepicm4 systemd-logind[848]: Session 4 logged out. Waiting 
for processes to exit.
Mar 05 20:33:37 orangepicm4 systemd[1]: Started phosh.service - Phosh, a shell 
for mobile phones.
Mar 05 20:33:37 orangepicm4 systemd-logind[848]: Removed session 4.
Mar 05 20:33:37 orangepicm4 polkitd[842]: Unregistered Authentication Agent for 
unix-process:unknown (system bus name :1.74, object path /org/fr>
Mar 05 20:33:37 orangepicm4 pulseaudio[1794]: ICE I/O error handler called
Mar 05 20:33:37 orangepicm4 (capsh)[3188]: pam_unix(login:session): session 
opened for user orangepi(uid=1000) by orangepi(uid=0)
Mar 05 20:33:37 orangepicm4 xfconfd[2063]: Name org.xfce.Xfconf lost on the 
message dbus, exiting.
Mar 05 20:33:37 orangepicm4 lightdm[1744]: pam_unix(lightdm-autologin:session): 
session closed for user orangepi
Mar 05 20:33:37 orangepicm4 org.gtk.vfs.Daemon[2093]: A connection to the bus 
can't be made
Mar 05 20:33:37 orangepicm4 kernel: [drm:vop2_plane_atomic_check] *ERROR* 
Unsupported linear format at Cluster0-win0
Mar 05 20:33:37 orangepicm4 kernel: [drm:vop2_plane_atomic_check] *ERROR* 
Unsupported linear format at Cluster0-win0
Mar 05 20:33:37 orangepicm4 systemd[1]: run-user-1000-gvfs.mount: Deactivated 
successfully.
Mar 05 20:33:37 orangepicm4 systemd-logind[848]: Session 2 lo

Bug#1057887: bind9 named logging for category rpz misses some rpz log messages

[Evan Harris]

Turns out this is due to there being another log category specifically for 
rpz-passthru messages, separate from the rpz category.  So an intentional 
feature rather than a bug.


Ok to close.

Bug#1057887: bind9 named logging for category rpz misses some rpz log messages

[Evan Harris]

https://gitlab.isc.org/isc-projects/bind9/-/issues/4483

Bug#1053730: chromium: Chromium argument documentattion for --password-store is wrong

[Evan Carroll]

Package: chromium
Version: 117.0.5938.149-1~deb12u1
Severity: important
X-Debbugs-Cc: m...@evancarroll.com

Dear Maintainer,

Chromium currently documents a --password-store option which is no
longer valid. This option is "gnome". This is no longer the name of the
gnome keyring, which is now called "gnome-libsecret".

You can validate the old argument no longer works by checking in the
source,

* ./components/os_crypt/sync/key_storage_util_linux.cc


Or by executing with 

chromium --user-data-dir=/tmp/foo --password-store=gnome 
--enable-logging=stderr --v=1 &> /tmp/log

Which will produce this error in your log,

42:[81904:81904:1009/140751.425052:VERBOSE1:key_storage_util_linux.cc(52)] 
Password storage detected desktop environment: (unknown)

This will go away after you use "gnome-libsecret" instead.

Additionally, while "kwallet" works, there is also "kwallet5" and
"kwallet6" supported.


-- System Information:
Debian Release: 12.2
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages chromium depends on:
ii  chromium-common117.0.5938.149-1~deb12u1
ii  libasound2 1.2.8-1+b1
ii  libatk-bridge2.0-0 2.46.0-5
ii  libatk1.0-02.46.0-5
ii  libatomic1 12.2.0-14
ii  libatspi2.0-0  2.46.0-5
ii  libc6  2.36-9+deb12u3
ii  libcairo2  1.16.0-7
ii  libcups2   2.4.2-3+deb12u4
ii  libdbus-1-31.14.10-1~deb12u1
ii  libdouble-conversion3  3.2.1-1
ii  libdrm22.4.114-1+b1
ii  libevent-2.1-7 2.1.12-stable-8
ii  libexpat1  2.5.0-1
ii  libflac12  1.4.2+ds-2
ii  libfontconfig1 2.14.1-4
ii  libfreetype6   2.12.1+dfsg-5
ii  libgbm122.3.6-1+deb12u1
ii  libgcc-s1  12.2.0-14
ii  libglib2.0-0   2.74.6-2
ii  libgtk-3-0 3.24.38-2~deb12u1
ii  libjpeg62-turbo1:2.1.5-2
ii  libjsoncpp25   1.9.5-4
ii  liblcms2-2 2.14-2
ii  libminizip11.1-8+b1
ii  libnspr4   2:4.35-1
ii  libnss32:3.87.1-1
ii  libopenh264-7  2.3.1+dfsg-3
ii  libopenjp2-7   2.5.0-2
ii  libopus0   1.3.1-3
ii  libpango-1.0-0 1.50.12+ds-1
ii  libpng16-161.6.39-2
ii  libpulse0  16.1+dfsg1-2+b1
ii  libsnappy1v5   1.1.9-3
ii  libstdc++6 12.2.0-14
ii  libwebp7   1.2.4-0.2+deb12u1
ii  libwebpdemux2  1.2.4-0.2+deb12u1
ii  libwebpmux31.2.4-0.2+deb12u1
ii  libwoff1   1.0.2-2
ii  libx11-6   2:1.8.4-2+deb12u2
ii  libxcb11.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.6-1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxkbcommon0  1.5.0-1
ii  libxml22.9.14+dfsg-1.3~deb12u1
ii  libxnvctrl0525.85.05-3~deb12u1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxslt1.1 1.1.35-1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backen  1.14.1-1
d]
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages chromium recommends:
ii  chromium-san

Bug#1042538: timeshift: Debian installer makes BTRFS root subvolume named "@rootfs" and timeshift requires "@"

[Evan Carroll]

Package: timeshift
Severity: important
X-Debbugs-Cc: m...@evancarroll.com

Dear Maintainer,

Currently Debian uses `@rootfs` as the btrfs subvolume label in the
installer while Ubuntu uses `@`. Timeshift unfortunately only
supports the Ubuntu convention of `@` and not `@rootfs`. You can see
this in this in their README,

https://github.com/linuxmint/timeshift/blob/e7fab11ae99465a8ac405981040482c9369e957a/README.md?plain=1#L109

They have two issues to include Debian compatibility with the root
subvolume named `@rootfs`.

https://github.com/linuxmint/timeshift/issues/157
https://github.com/linuxmint/timeshift/issues/83

The Debian installer does not support subvolume management with btrfs.
You can not rename your root subvolume from `@rootfs` to `@`. To use
Timeshift on Debian, you _must_ pause the installer and modify your
subvolume names. This is common, and there are at least a few YouTube
videos which do this (without explaining it). See this question and
attached self-answer for more information,

https://unix.stackexchange.com/q/752738/3285

This is a **horrible** user experience. To be clear, if you use an
uninterrupted Debian install and never drop to the terminal you can not
make use of the Timeshift package later.

I believe Debian should patch Timeshift to support its own convention of
`@rootfs`. Both of these tools should be packaged to work by default
with one another, and if they can't be made to work with one another
using the installers default, this package should be removed from the
repository as we're not supporting end-use with our own BTRFS installer.

Note, if a patch is accepted that changes this hard-coded root-label we
will break installs that have changed their root-label manually (which
presumably we don't support anyway). Ideally, this would be something
that could be customized without user intervention with btrfs tooling.

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

Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages timeshift depends on:
ii  cron [cron-daemon]   3.0pl1-162
ii  libc62.36-9
ii  libcairo21.16.0-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgee-0.8-2 0.20.6-1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.37-2
ii  libjson-glib-1.0-0   1.6.6-1
ii  libvte-2.91-00.70.3-1
pn  libxapp1 
ii  psmisc   23.6-1
ii  rsync3.2.7-1

timeshift recommends no packages.

timeshift suggests no packages.

Bug#974703: Still a problem...

[Evan Goers]

On my Panasonic Toughbook CF-M34, with a SiliconMotion LynxEM(SM710) video
chip, this is still a problem on Debian 11. I get the same issue "Not
enough video memory for the configured screen size (800x600) and color
depth."

It seems no amount of xorg.conf experimentation will make this error go
away. Even setting the VideoRam manually doesn't help. 800x600x16 should
fit within 4MB(it works just fine in Windows 98SE).

Bug#1015920: RFS: picklecast/1.0.2 [ITP] -- Screenshare receiver

[Evan Widloski]

I've corrected the copyright and changelog files.

> What is that adapter-latest.js file in debian/copyright?

It's a shim which hides variation in the WebRTC api between browsers.

Evan

Bug#1003481: libglfw3 bug causes delayed or ignored inputs in X11 session

[Evan Mohr]

Package: libglfw3
Version: 3.3.2-1

In the currently packaged version of libglfw3, there is a bug that causes
for inputs to be delayed or ignored in the X11 session (and also Wayland
via Xwayland) which causes a frustrating experience in affected games. This
issue is fixed in this commit:
https://github.com/glfw/glfw/commit/9a3664b4a992a5a9b669179098542b0f882dece7,
but Debian does not package the fixed version (3.3.3 and newer).

I suggest that the issue is fixed by updating libglfw3 to version 3.3.3 or
newer. It would also be possible to fix the issue by patching the current
version with the commit referred to above.

I am using Ubuntu 21.10, kernel 5.13.0-23-generic, and libc6 2.34-0ubuntu3.

Bug#998077: package "sfdisk" recommended but "sfdisk" purely virtual

[Evan Pitstick]

Package: salt-minion
Version: 3002.6+dfsg1-4

salt-minion recommends the "sfdisk" package but this is an empty
virtual package.
The "fdisk" package contains the sfdisk bin so it is probably the
correct replacement.


% uname -a
Linux sql-secondary 5.10.0-9-cloud-amd64 #1 SMP Debian 5.10.70-1
(2021-09-30) x86_64 GNU/Linux
% cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/";
SUPPORT_URL="https://www.debian.org/support";
BUG_REPORT_URL="https://bugs.debian.org/";

Bug#990806: No log rotation for xrdp

[Linde, Evan]

Package: xrdp
Version: 0.9.12

Log files from xrdp do not rotate, but grow continuously. 

Please consider adding a logrotate file (i.e. /etc/logrotate.d/xrdp) to the 
xrdp package. Here is the config I would suggest:

/var/log/xrdp*.log {
compress
missingok
notifempty
copytruncate
}

Or the following if it is preferable to define the rotation schedule explicitly 
rather than inherit from /etc/logrotate.conf:

/var/log/xrdp*.log {
rotate 4
weekly
compress
missingok
notifempty
copytruncate
}

Evan Linde
Research Cyberinfrastructure Analyst
Oklahoma State University
High Performance Computing Center
405-744-1455
http://hpcc.okstate.edu/

Bug#984515: fail2ban: Pattern from named-refused.conf filter failing to match log lines

[Evan Harris]

It appears that this issue has already been fixed upstream, as can be seen 
in the current source file for this filter at 
https://github.com/fail2ban/fail2ban/blob/master/config/filter.d/named-refused.conf


Which has:

prefregex = ^%(__line_prefix)s(?: error:)?\s*client(?: @\S*)? #\S+(?: \([\S.]+\))?: 
.+\s(?:denied|\(NOTAUTH\))\s*$

Which includes "(?: @\S*)?" to handle the problematic part.

Evan


On Thu, 4 Mar 2021, Sylvestre Ledru wrote:


Hello,

Le 04/03/2021 à 14:39, E Harris a écrit :

Package: fail2ban
Version: 0.10.2-2.1
Severity: normal

There is a problem in the regex matching for the optional named-refused 
filter.


Log messages from named that should be matched by this filter are not being
matched because the log pattern for the host is different than expected.

Specifically, it seems to be a problem with the prefregex portion of the 
pattern.

An example log line is:

Mar  4 07:32:52 myhost named[1390966]: client @0x7ff989af9780 
124.81.141.74#53 (.): query (cache) './ANY/IN' denied


The stock prefregex is causing match failures because of the 
'@0x7ff989af9780 ' portion of the log message.


Could you please report thi s issue upstream?

Thanks
Sylvestre

Bug#984515: fail2ban: Pattern from named-refused.conf filter failing to match log lines

[Evan Harris]

The commit that fixes this is here:

https://github.com/fail2ban/fail2ban/commit/43954692260bc57f6b7afd08115f8906b8fabce0

As best I can tell, this issue seems to have been fixed in the 0.10.5 
release.


Evan


On Thu, 4 Mar 2021, Evan Harris wrote:

It appears that this issue has already been fixed upstream, as can be seen in 
the current source file for this filter at 
https://github.com/fail2ban/fail2ban/blob/master/config/filter.d/named-refused.conf


Which has:

prefregex = ^%(__line_prefix)s(?: error:)?\s*client(?: @\S*)? #\S+(?: 
\([\S.]+\))?: .+\s(?:denied|\(NOTAUTH\))\s*$


Which includes "(?: @\S*)?" to handle the problematic part.

Evan


On Thu, 4 Mar 2021, Sylvestre Ledru wrote:


Hello,

Le 04/03/2021 à 14:39, E Harris a écrit :

Package: fail2ban
Version: 0.10.2-2.1
Severity: normal

There is a problem in the regex matching for the optional named-refused 
filter.


Log messages from named that should be matched by this filter are not 
being

matched because the log pattern for the host is different than expected.

Specifically, it seems to be a problem with the prefregex portion of the 
pattern.

An example log line is:

Mar  4 07:32:52 myhost named[1390966]: client @0x7ff989af9780 
124.81.141.74#53 (.): query (cache) './ANY/IN' denied


The stock prefregex is causing match failures because of the 
'@0x7ff989af9780 ' portion of the log message.


Could you please report thi s issue upstream?

Thanks
Sylvestre

Bug#980117: mounts to polydirs not working

[Linde, Evan]

Package: libpam-mount
Version: 2.16-4

Pam_mount is failing to mount filesystems when the mount point is a 
polyinstantiated directory.

The problem is only when the polydir itself is used as a mountpoint; there is 
no problem using a subdirectory inside the polydir. (e.g. If "/data2" is 
defined as a polydir in /etc/security/pam_namespace.conf, pam_mount succeeds 
when using /data2/subdir as a mount point, but fails when using /data2 as the 
mount point.)

When the mount fails, lines like the following are logged by both systemd and 
login (with debugging enabled in pam_mount.conf.xml):

(mount.c:250): Mount info: globalconf, user=elinde  fstab=0 ssh=0

(mount.c:622): data already seems to be mounted at /data2, skipping

This bug doesn't exist in the upstream pam-mount project, but was introduced 
with the patch 0014-Don-t-compare-source-when-checking-if-it-s-already-m.patch 
starting in Debian's 2.16-4 release (made to address 
https://bugs.debian.org/799752 and similar issues with encrypted volumes). This 
bug is also reported for Ubuntu: 
https://bugs.launchpad.net/ubuntu/+source/libpam-mount/+bug/1908638

Evan Linde
Research Cyberinfrastructure Analyst
Oklahoma State University
High Performance Computing Center
405-744-1455
http://hpcc.okstate.edu/

Bug#908058: openjdk-9-jre-headless: dependency of x11-common but a headless package

[Evan Widloski]

Seems like this is still an issue.  I'm installing jre on a machine without a 
display, so I don't understand why X11 is needed here.

Bug#974172: libmutter-7-0: Cannot unlock screen with Wayland on arm64, keybard and mouse unresponsive

[Evan McGinnis]

Hi Galí, Simon

I observed this issue as well and have bisected it.

https://salsa.debian.org/gnome-team/mutter/-/commit/209b1ba3

209b1ba383f59e1b398d3331d9fd9fcb7f0284a1

seems to be the culprit

Anything before that commit functions properly on my aarch64 machine.

PS. sorry for the resend-- forgot to include the mailing list


- Hal

Bug#974112: libkdecorations2-5v5: libkdecorations (5.19) seems wrong Plasma version (5.17.5) in Debian Bullseye, causes crashes

[Evan]

Package: libkdecorations2-5v5
Version: 4:5.17.5-2
Severity: important
X-Debbugs-Cc: esmac...@gmail.com

Dear Maintainer,

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

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

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


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

Kernel: Linux 5.8.0-3-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libkdecorations2-5v5 depends on:
ii  libc6 2.31-4
ii  libkdecorations2private6  4:5.17.5-2
ii  libkf5i18n5   5.74.0-3
ii  libqt5core5a  5.15.1+dfsg-2
ii  libqt5gui55.15.1+dfsg-2
ii  libstdc++610.2.0-16

libkdecorations2-5v5 recommends no packages.

libkdecorations2-5v5 suggests no packages.

-- no debconf information

If the current version of libkdecorations2-5v5 and libkdecorations2private6 are 
both installed (5.19), Kwin will crash when opening
some settings modules such as Window Decorations.  The 'close window' button at 
the top of windows maximizes windows instead of
closing them as well.  The solution to the problem was to downgrade the two 
packages to the 5.17.5 version (matching the current available
plasma-desktop verison)

Bug#965340: libsleef-dev: Unable to install multiple architecures due to conflicting header

[Evan Nemerson]

Package: libsleef-dev
Version: 3.4.1-2
Severity: important

Dear Maintainer,

It is not currently possible to install libsleef-dev on multiple
architectures due to all packages installing /usr/include/sleef.h.
This makes it difficult to develop software targeting multiple
architectures.

The sleef.h header is platform-specific; the x86 version has SSE
versions of various functions, ARM has NEON versions, etc.  AFAIK
that means the header should go in /usr/include/$ARCH/ instead of
just /usr/include/.

Reproducing should be trivial; just (try to) install libsleef-dev
on multiple architectures.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf, arm64, s390x, ppc64el

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

Versions of packages libsleef-dev depends on:
ii  libsleef3  3.4.1-2

libsleef-dev recommends no packages.

libsleef-dev suggests no packages.

-- no debconf information

Bug#959399: libreoffice-common: Using libreoffice results in many AppArmor "ALLOWED" log messages in kernel syslog

[Evan Harris]

No, $HOME isn't. $HOME in your case is "/raid/home/user/.


Actually it's not.  In the particular example I gave logs for, $HOME is 
/home/user.  It just happens that /home is a symlink to /raid/home.



How should the configuration be changed for multiple home directories being
stored and mounted in multiple locations?


Erm, what?

I mentioned

@{libo_user_dirs} = @{HOME} /mnt /media


I don't know where that is configured.  Where would I find that?


Wouldn't be surprised if @{HOME} (documented as "all homedirs") actually
means /home/** and thus wouldn't allow /raid/home/**.

I'd first try adding /raid/home there, obviously?


Where is "there"?

Bug#959399: libreoffice-common: Using libreoffice results in many AppArmor "ALLOWED" log messages in kernel syslog

[Evan Harris]

I guess I don't understand what needs to be changed.  $HOME is /home, which 
is where the local users homes are.  There are additional mount points 
(/raid, and one other) that hold additional network mounts of remotely store 
users' home directories.


How should the configuration be changed for multiple home directories being 
stored and mounted in multiple locations?


Evan


On Sat, 2 May 2020, Rene Engelhard wrote:


retitle 959399 libreoffice-common: many AppArmor "ALLOWED" log messages
if using "non-standard" $HOME
severity 959399 minor
tag 959399 + wontfix
thanks

On Fri, May 01, 2020 at 06:00:46PM -0500, E Harris wrote:

Using LibreOffice results in many AppArmor audit log messages marked as 
"ALLOWED".
These messages repeat many times during normal use of the app, resulting in
quite a bit of log spam.

Perhaps this is the result of the user's home directory being mounted in an 
alternate location?


Yes, and to be honest, if you change that dir you need to change all
profiles referencing $HOME to allow it.

Here you can be just glad it works because the profile is in complain
mode, if it wasn't this wouldn't work at all...

One simply cannot allow any path as this would simply defeat the
purpose.



A small sampling of messages (obfuscated):

May  1 17:19:49 host kernel: [ 9201.656675] audit: type=1400 audit(1588371589.713:822): apparmor="ALLOWED" operation="mknod" 
profile="libreoffice-soffice" name="/raid/home/user/.config/libreoffice/4/user/GpDXp7" pid=16453 comm="configmgrWriter" 
requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000


why /raid as extra mountpoint and not /home directly or / directly or if
that's not intended some bind mounts to have /home on a "known"
location? So that stuff like this doesn't knowingly break?
Or is that the case?

I am honestly not sure whether there's something to do there at all -
except for the admin of the system to adapt the profile to the setuo of
the system.

Regards,

Rene

Bug#941903: snapshot.debian.org: 404 error for one snapshot.debian.org IP address but not for the other

[Evan Jones]

On Mon, Oct 21, 2019 at 9:11 AM Peter Palfrader  wrote:

> I'm tempted to think that this tool should not use snapshot but the real
> mirrors that can handle the load way better.
>

It also accesses snapshot.debian.org when building new images, so the
traffic should be pretty small: it is just a tiny handful of developers,
plus the CI system. End users download the binary that was build and
published by Google.

That said: is there some other way to get a specific version of
Packages.txt that does not change? If so, I'd be happy to change this. The
goal is that given a build, future builds should download the *exact same
bits*. My understanding is snapshot.debian.org is exactly the way to do
this?

Thanks!

Evan

Bug#941903: snapshot.debian.org: 404 error for one snapshot.debian.org IP address but not for the other

[Evan Jones]

THANK YOU and whoever else is involved in maintaining this. Just letting
you know that I appreciate the work here. I don't work for Google, but I do
use Distroless [1], a lightweight Debian-based container runtime that uses
snapshot to have reproducible builds, so this was definitely annoying to
work around. Thanks!

[1] https://github.com/GoogleContainerTools/distroless


On Mon, Oct 21, 2019 at 3:54 AM Peter Palfrader  wrote:

> Michael Rogers schrieb am Monday, dem 07. October 2019:
>
> > When trying to fetch package lists and packages from the
> > buster/updates repository I get 404 errors at random, depending on
> > which IP address of snapshot.debian.org my machine chooses for each
> > request. Requests that go to 193.62.202.27 succeed, while requests
> > that go to 185.17.185.185 fail with 404 errors.
>
> > The requested URL /file/02424f70567c5695ef02c2410dd9bca446a86437 was not
> found on this server.
>
> Thanks for the report.  It seems that the farm broke.  Should be fixed
> now, sync is still in progress.
>
> Cheers,
> --
> |  .''`.   ** Debian **
>   Peter Palfrader   | : :' :  The  universal
>  https://www.palfrader.org/ | `. `'  Operating System
> |   `-https://www.debian.org/
>
>

Bug#935559: Unzipping a .zip file overwrites a folder of the same name

[Evan Rysdam]

Aha, in that case it looks like it uses Xarchiver 0.5.4.

Evan Rysdam

On 8/28/19 3:21 AM, Yves-Alexis Perez wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

If you report a bug, please keep its address in CC for all communications.

On Tue, 2019-08-27 at 21:07 -0400, Evan Rysdam wrote:

I don't know. How can I check that information?

It should use the preferred applications for the associated file type (so the
one it opens when double clicking on it for example).

Also you can fine-tune the behavior with the “extract to” command (“extract
here” is by design simplistic).

Regards,
- -- 
Yves-Alexis

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl1mK38ACgkQ3rYcyPpX
RFttHQf/ZS4zEVLadOeO0chVsewjjXmN/uXwZ/6azYM/s1i6fD1YytP7lD1/m6o1
rORRnYUDXrgKI82FlUx0P0XHOBsPjHDaFfk9j9uODr2+1cX1gyHNuPTGdCzJICgz
sJkO6qyYIGxkDRc2GokGc6Mdr+3Zv08Ek+ZC5VwYhgOVeq+zFhT5QNXAdDERivHq
ifiyPAvXezvQ67foiZ8TkgCmE5+xFipmN361qTZEPrIWpNVCFXQ4Oh205T0Av9rZ
bti6J/g/lvrSQPY/ss1Pesx2PPBsMGSTup4nw+riPdIa2jzPkRHy4DVJQGO6AcFX
DIWVYm+V1FbK3gbutbrTIYPgcb69Zw==
=5F/R
-END PGP SIGNATURE-

Bug#935559: Unzipping a .zip file overwrites a folder of the same name

[Evan Rysdam]

Package: thunar
Version 1.6.11-1

When I have a folder named X and a .zip file containing a folder named 
X, if I right-click the .zip file and choose "Extract Here", the 
existing folder is re-written without a warning. The behavior I expected 
was that Thunar would prompt me with a warning and an option to cancel 
the operation to preserve the original folder.


Output of 'uname -a': Linux hal 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1 
(2019-04-12) x86_64 GNU/Linux


Evan Rysdam

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

An official release of libxls 1.5.0 is here:

https://github.com/libxls/libxls/releases/tag/v1.5.0 
<https://github.com/libxls/libxls/releases/tag/v1.5.0>

It fixes all known vulnerabilities. Thanks for your patience everyone.

Evan

> On Feb 4, 2019, at 17:15, Dirk Eddelbuettel  wrote:
> 
> 
> And as one more piece of closure, the backported fix is now going into an
> update of Debian stable as well.
> 
> Thanks everybody, and especially Evan. We're already in better shape now, and
> will be in even better shape with the upcoming libxls 1.5 release.
> 
> Dirk
> 
> -- 
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

I will do an official release of libxls 1.5 this week or next.

Sent from my iPad

> On Jan 29, 2019, at 18:44, Jennifer Bryan  wrote:
> 
> I will kick off my process then.
> 
> Will you do something nice and official re: a release and I should keep my 
> eyes open for it?
> Or am I rolling on my own schedule now, knowing that I am embedding a libxls 
> release in the moral sense?
> 
> -- Jenny
> 
>> On Tue, Jan 29, 2019 at 11:38 AM Evan Miller  wrote:
>> Thanks Jenny. In that case I am not planning any additional code changes, 
>> just documentation and maybe tweaks to the build scripts.
>> 
>> Sent from my iPad
>> 
>>> On Jan 29, 2019, at 11:47, Jennifer Bryan  wrote:
>>> 
>>> Yes, all is good. I had pulled libxls again yesterday after you merged your 
>>> PR and readxl still passes checks on all platforms.
>>> 
>>> https://github.com/tidyverse/readxl/pull/543
>>> 
>>> -- Jenny
>>> 
>>>> On Tue, Jan 29, 2019 at 7:31 AM Evan Miller  wrote:
>>>> All issues identified by OSS-Fuzz are now fixed in libxls master. @Jenny 
>>>> if the code passes your readxl tests I will begin preparing a 1.5 release 
>>>> candidate.
>>>> 
>>>> In other news, I heard back from the researcher who initially reported the 
>>>> issues. His GitHub account was marked as spam, which explains why the 
>>>> issues he filed disappeared without warning.
>>>> 
>>>> Sent from my iPad
>>>> 
>>>> > On Jan 27, 2019, at 10:27, Dirk Eddelbuettel  wrote:
>>>> > 
>>>> > 
>>>> > On 27 January 2019 at 09:25, Evan Miller wrote:
>>>> > | 
>>>> > | > On Jan 26, 2019, at 23:09, Dirk Eddelbuettel  wrote:
>>>> > | > 
>>>> > | > 
>>>> > | > On 26 January 2019 at 15:59, Jennifer Bryan wrote:
>>>> > | > | I'll still wait a bit to see if libxls can get to an official 
>>>> > release soon.
>>>> > | > | 
>>>> > | > | But readxl builds and passes tests everywhere with the current 
>>>> > libxls, so
>>>> > | > | that's good news:
>>>> > | > | 
>>>> > | > | https://github.com/tidyverse/readxl/pull/543
>>>> > | > 
>>>> > | > Nice -- should I fold that into an interim release to address the 
>>>> > CVE?
>>>> > | > I can then follow-up with real release whenever you push to CRAN.
>>>> > | 
>>>> > | This would be fine from my end. I am hunting down one last hang 
>>>> > identified by OSS-Fuzz (I.e. potential denial of service), but the CVEs, 
>>>> > buffer overruns, and memory leaks are all fixed in Jenny’s pull request.
>>>> > 
>>>> > Ok I did the easy part: updating our current package (based on Jenny's 
>>>> > readxl
>>>> > 1.2.0 from December 2018) to her current dev branch with your updates. 
>>>> > The
>>>> > delta is small and clean so that was no work. In Debian unstable now.
>>>> > 
>>>> > And I then bravely/foolishly attempted the harder part of backporting to 
>>>> > the
>>>> > (old !!) version in stable.  Turns out it was not so bad and similar to 
>>>> > the
>>>> > fix in April -- I updated the relevant files 'en block':
>>>> > 
>>>> > edd@rob:~/temp-sec$ diff -rq r-cran-readxl-0.1.1.orig/ 
>>>> > r-cran-readxl-0.1.1
>>>> > Files r-cran-readxl-0.1.1.orig/src/libxls/ole.h and 
>>>> > r-cran-readxl-0.1.1/src/libxls/ole.h differ
>>>> > Files r-cran-readxl-0.1.1.orig/src/libxls/xlstool.h and 
>>>> > r-cran-readxl-0.1.1/src/libxls/xlstool.h differ
>>>> > Files r-cran-readxl-0.1.1.orig/src/ole.c and 
>>>> > r-cran-readxl-0.1.1/src/ole.c differ
>>>> > Files r-cran-readxl-0.1.1.orig/src/xls.c and 
>>>> > r-cran-readxl-0.1.1/src/xls.c differ
>>>> > Files r-cran-readxl-0.1.1.orig/src/xlstool.c and 
>>>> > r-cran-readxl-0.1.1/src/xlstool.c differ
>>>> > edd@rob:~/temp-sec$ 
>>>> > 
>>>> > I do get a segfault on the .xls example but _vaguely_ recall that we had
>>>> > issue in April too.  The "example(read_excel)" using the xlsx file works 
>>>> > fine.
>>>> > 
>>>> > Moritz: I&

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

Thanks Jenny. In that case I am not planning any additional code changes, just 
documentation and maybe tweaks to the build scripts.

Sent from my iPad

> On Jan 29, 2019, at 11:47, Jennifer Bryan  wrote:
> 
> Yes, all is good. I had pulled libxls again yesterday after you merged your 
> PR and readxl still passes checks on all platforms.
> 
> https://github.com/tidyverse/readxl/pull/543
> 
> -- Jenny
> 
>> On Tue, Jan 29, 2019 at 7:31 AM Evan Miller  wrote:
>> All issues identified by OSS-Fuzz are now fixed in libxls master. @Jenny if 
>> the code passes your readxl tests I will begin preparing a 1.5 release 
>> candidate.
>> 
>> In other news, I heard back from the researcher who initially reported the 
>> issues. His GitHub account was marked as spam, which explains why the issues 
>> he filed disappeared without warning.
>> 
>> Sent from my iPad
>> 
>> > On Jan 27, 2019, at 10:27, Dirk Eddelbuettel  wrote:
>> > 
>> > 
>> > On 27 January 2019 at 09:25, Evan Miller wrote:
>> > | 
>> > | > On Jan 26, 2019, at 23:09, Dirk Eddelbuettel  wrote:
>> > | > 
>> > | > 
>> > | > On 26 January 2019 at 15:59, Jennifer Bryan wrote:
>> > | > | I'll still wait a bit to see if libxls can get to an official 
>> > release soon.
>> > | > | 
>> > | > | But readxl builds and passes tests everywhere with the current 
>> > libxls, so
>> > | > | that's good news:
>> > | > | 
>> > | > | https://github.com/tidyverse/readxl/pull/543
>> > | > 
>> > | > Nice -- should I fold that into an interim release to address the CVE?
>> > | > I can then follow-up with real release whenever you push to CRAN.
>> > | 
>> > | This would be fine from my end. I am hunting down one last hang 
>> > identified by OSS-Fuzz (I.e. potential denial of service), but the CVEs, 
>> > buffer overruns, and memory leaks are all fixed in Jenny’s pull request.
>> > 
>> > Ok I did the easy part: updating our current package (based on Jenny's 
>> > readxl
>> > 1.2.0 from December 2018) to her current dev branch with your updates. The
>> > delta is small and clean so that was no work. In Debian unstable now.
>> > 
>> > And I then bravely/foolishly attempted the harder part of backporting to 
>> > the
>> > (old !!) version in stable.  Turns out it was not so bad and similar to the
>> > fix in April -- I updated the relevant files 'en block':
>> > 
>> > edd@rob:~/temp-sec$ diff -rq r-cran-readxl-0.1.1.orig/ r-cran-readxl-0.1.1
>> > Files r-cran-readxl-0.1.1.orig/src/libxls/ole.h and 
>> > r-cran-readxl-0.1.1/src/libxls/ole.h differ
>> > Files r-cran-readxl-0.1.1.orig/src/libxls/xlstool.h and 
>> > r-cran-readxl-0.1.1/src/libxls/xlstool.h differ
>> > Files r-cran-readxl-0.1.1.orig/src/ole.c and r-cran-readxl-0.1.1/src/ole.c 
>> > differ
>> > Files r-cran-readxl-0.1.1.orig/src/xls.c and r-cran-readxl-0.1.1/src/xls.c 
>> > differ
>> > Files r-cran-readxl-0.1.1.orig/src/xlstool.c and 
>> > r-cran-readxl-0.1.1/src/xlstool.c differ
>> > edd@rob:~/temp-sec$ 
>> > 
>> > I do get a segfault on the .xls example but _vaguely_ recall that we had
>> > issue in April too.  The "example(read_excel)" using the xlsx file works 
>> > fine.
>> > 
>> > Moritz: I'll proceed and send the required debdiff to security@d.o.  I may
>> > need to lean on you once again for 'process' as I don't do this all that 
>> > often.
>> > 
>> > Thanks everybody for the help, particularly Evan of course for the upstream
>> > work, and also Jenny for the clean new branch.
>> > 
>> > Dirk
>> > 
>> > | Evan
>> > | 
>> > | > 
>> > | > Dirk
>> > | > 
>> > | > | -- Jenny
>> > | > | 
>> > | > | On Sat, Jan 26, 2019 at 7:23 AM Evan Miller  
>> > wrote:
>> > | > | 
>> > | > | >
>> > | > | > > On Jan 26, 2019, at 10:05, Dirk Eddelbuettel  
>> > wrote:
>> > | > | > >
>> > | > | > >
>> > | > | > > On 24 January 2019 at 19:54, Evan Miller wrote:
>> > | > | > > |
>> > | > | > > | > On Jan 24, 2019, at 19:10, Dirk Eddelbuettel 
>> >  wrote:
>> > | > | > > | >
>> > | > | > > | >
>> > | > | &

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

All issues identified by OSS-Fuzz are now fixed in libxls master. @Jenny if the 
code passes your readxl tests I will begin preparing a 1.5 release candidate.

In other news, I heard back from the researcher who initially reported the 
issues. His GitHub account was marked as spam, which explains why the issues he 
filed disappeared without warning.

Sent from my iPad

> On Jan 27, 2019, at 10:27, Dirk Eddelbuettel  wrote:
> 
> 
> On 27 January 2019 at 09:25, Evan Miller wrote:
> | 
> | > On Jan 26, 2019, at 23:09, Dirk Eddelbuettel  wrote:
> | > 
> | > 
> | > On 26 January 2019 at 15:59, Jennifer Bryan wrote:
> | > | I'll still wait a bit to see if libxls can get to an official release 
> soon.
> | > | 
> | > | But readxl builds and passes tests everywhere with the current libxls, 
> so
> | > | that's good news:
> | > | 
> | > | https://github.com/tidyverse/readxl/pull/543
> | > 
> | > Nice -- should I fold that into an interim release to address the CVE?
> | > I can then follow-up with real release whenever you push to CRAN.
> | 
> | This would be fine from my end. I am hunting down one last hang identified 
> by OSS-Fuzz (I.e. potential denial of service), but the CVEs, buffer 
> overruns, and memory leaks are all fixed in Jenny’s pull request.
> 
> Ok I did the easy part: updating our current package (based on Jenny's readxl
> 1.2.0 from December 2018) to her current dev branch with your updates. The
> delta is small and clean so that was no work. In Debian unstable now.
> 
> And I then bravely/foolishly attempted the harder part of backporting to the
> (old !!) version in stable.  Turns out it was not so bad and similar to the
> fix in April -- I updated the relevant files 'en block':
> 
> edd@rob:~/temp-sec$ diff -rq r-cran-readxl-0.1.1.orig/ r-cran-readxl-0.1.1
> Files r-cran-readxl-0.1.1.orig/src/libxls/ole.h and 
> r-cran-readxl-0.1.1/src/libxls/ole.h differ
> Files r-cran-readxl-0.1.1.orig/src/libxls/xlstool.h and 
> r-cran-readxl-0.1.1/src/libxls/xlstool.h differ
> Files r-cran-readxl-0.1.1.orig/src/ole.c and r-cran-readxl-0.1.1/src/ole.c 
> differ
> Files r-cran-readxl-0.1.1.orig/src/xls.c and r-cran-readxl-0.1.1/src/xls.c 
> differ
> Files r-cran-readxl-0.1.1.orig/src/xlstool.c and 
> r-cran-readxl-0.1.1/src/xlstool.c differ
> edd@rob:~/temp-sec$ 
> 
> I do get a segfault on the .xls example but _vaguely_ recall that we had
> issue in April too.  The "example(read_excel)" using the xlsx file works fine.
> 
> Moritz: I'll proceed and send the required debdiff to security@d.o.  I may
> need to lean on you once again for 'process' as I don't do this all that 
> often.
> 
> Thanks everybody for the help, particularly Evan of course for the upstream
> work, and also Jenny for the clean new branch.
> 
> Dirk
> 
> | Evan
> | 
> | > 
> | > Dirk
> | > 
> | > | -- Jenny
> | > | 
> | > | On Sat, Jan 26, 2019 at 7:23 AM Evan Miller  wrote:
> | > | 
> | > | >
> | > | > > On Jan 26, 2019, at 10:05, Dirk Eddelbuettel  
> wrote:
> | > | > >
> | > | > >
> | > | > > On 24 January 2019 at 19:54, Evan Miller wrote:
> | > | > > |
> | > | > > | > On Jan 24, 2019, at 19:10, Dirk Eddelbuettel  
> wrote:
> | > | > > | >
> | > | > > | >
> | > | > > | > On 24 January 2019 at 16:36, Evan Miller wrote:
> | > | > > | > |
> | > | > > | > | > On Jan 23, 2019, at 01:16, Evan Miller 
> | > | > wrote:
> | > | > > | > | >
> | > | > > | > | > #34 and #35 have returned from the dead on GitHub. I’ll 
> take a
> | > | > closer look later this week.
> | > | > > | > | >
> | > | > > | > | > Evan
> | > | > > | > |
> | > | > > | > |
> | > | > > | > | OK — I can confirm that all of the reported libxls bugs are 
> fixed.
> | > | > > | >
> | > | > > | > As in: in the current libxls GH version?  I can make a patched 
> Debian
> | > | > > | > release of that.
> | > | > > |
> | > | > > | Yes, they are fixed in master on GitHub. Note that there are 
> quite a
> | > | > few changes since 1.4 – I can’t promise that master has ABI 
> compatibility
> | > | > with the last official 1.4 release. But if you compile the new sources
> | > | > using the old headers (or diff and merge manually) I don’t think 
> there will
> | > | > be an issue on that front.
> | > | > >
> | > | > > Maybe Jenny could tak

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

> On Jan 26, 2019, at 23:09, Dirk Eddelbuettel  wrote:
> 
> 
> On 26 January 2019 at 15:59, Jennifer Bryan wrote:
> | I'll still wait a bit to see if libxls can get to an official release soon.
> | 
> | But readxl builds and passes tests everywhere with the current libxls, so
> | that's good news:
> | 
> | https://github.com/tidyverse/readxl/pull/543
> 
> Nice -- should I fold that into an interim release to address the CVE?
> I can then follow-up with real release whenever you push to CRAN.

This would be fine from my end. I am hunting down one last hang identified by 
OSS-Fuzz (I.e. potential denial of service), but the CVEs, buffer overruns, and 
memory leaks are all fixed in Jenny’s pull request.

Evan

> 
> Dirk
> 
> | -- Jenny
> | 
> | On Sat, Jan 26, 2019 at 7:23 AM Evan Miller  wrote:
> | 
> | >
> | > > On Jan 26, 2019, at 10:05, Dirk Eddelbuettel  wrote:
> | > >
> | > >
> | > > On 24 January 2019 at 19:54, Evan Miller wrote:
> | > > |
> | > > | > On Jan 24, 2019, at 19:10, Dirk Eddelbuettel  
> wrote:
> | > > | >
> | > > | >
> | > > | > On 24 January 2019 at 16:36, Evan Miller wrote:
> | > > | > |
> | > > | > | > On Jan 23, 2019, at 01:16, Evan Miller 
> | > wrote:
> | > > | > | >
> | > > | > | > #34 and #35 have returned from the dead on GitHub. I’ll take a
> | > closer look later this week.
> | > > | > | >
> | > > | > | > Evan
> | > > | > |
> | > > | > |
> | > > | > | OK — I can confirm that all of the reported libxls bugs are fixed.
> | > > | >
> | > > | > As in: in the current libxls GH version?  I can make a patched 
> Debian
> | > > | > release of that.
> | > > |
> | > > | Yes, they are fixed in master on GitHub. Note that there are quite a
> | > few changes since 1.4 – I can’t promise that master has ABI compatibility
> | > with the last official 1.4 release. But if you compile the new sources
> | > using the old headers (or diff and merge manually) I don’t think there 
> will
> | > be an issue on that front.
> | > >
> | > > Maybe Jenny could take a look?
> | > >
> | > > It is her use of your library in her package that I stand behind for
> | > Debian.
> | >
> | > Ah, okay, then the ABI doesn’t matter. I had assumed you were packaging
> | > libxls as a runtime library + development headers.
> | >
> | > >
> | > > Thanks for all your diligent work on this. It is great to see this move
> | > in
> | > > the right ("fuzzing") direction.
> | >
> | > Long overdue! :-)
> | >
> | > Evan
> | >
> | > >
> | > > Dirk
> | > >
> | > > | Evan
> | > > |
> | > > | >
> | > > | > | I have successfully integrated libxls into OSS-Fuzz, and have
> | > added the researcher’s test files to the fuzzing corpus, so that this and
> | > related issues should be caught by the address sanitizer in the future.
> | > > | > |
> | > > | > | OSS-Fuzz has turned up a number of other issues. I will plan to do
> | > a release when they are all addressed.
> | > > | >
> | > > | > That is awesome.
> | > > | >
> | > > | > Thank you,  Dirk
> | > > | >
> | > > | > | Evan
> | > > | > |
> | > > | > | >
> | > > | > | >> On Jan 15, 2019, at 14:12, Moritz Muehlenhoff  | > <mailto:j...@inutil.org>> wrote:
> | > > | > | >>
> | > > | > | >> On Tue, Jan 15, 2019 at 10:43:25AM -0600, Dirk Eddelbuettel
> | > wrote:
> | > > | > | >>>
> | > > | > | >>> Hi Evan,
> | > > | > | >>>
> | > > | > | >>> On 15 January 2019 at 11:18, Evan Miller wrote:
> | > > | > | >>> |
> | > > | > | >>> | > On Jan 15, 2019, at 03:06, Moritz Muehlenhoff <
> | > j...@inutil.org <mailto:j...@inutil.org>> wrote:
> | > > | > | >>> | >
> | > > | > | >>> | > On Mon, Jan 14, 2019 at 08:45:56PM -0500, Evan Miller
> | > wrote:
> | > > | > | >>> | >> Oddly, all four issues (#34, #35, #36, #37) seem to have
> | > disappeared from GitHub. I don’t know if the original reporter intended to
> | > close them, or what.
> | > > | > | >>> | >>
> | > > | > | >>> | >> I have an email copy of #34 but do n

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

> On Jan 26, 2019, at 10:05, Dirk Eddelbuettel  wrote:
> 
> 
> On 24 January 2019 at 19:54, Evan Miller wrote:
> | 
> | > On Jan 24, 2019, at 19:10, Dirk Eddelbuettel  wrote:
> | > 
> | > 
> | > On 24 January 2019 at 16:36, Evan Miller wrote:
> | > | 
> | > | > On Jan 23, 2019, at 01:16, Evan Miller  wrote:
> | > | > 
> | > | > #34 and #35 have returned from the dead on GitHub. I’ll take a closer 
> look later this week.
> | > | > 
> | > | > Evan
> | > | 
> | > | 
> | > | OK — I can confirm that all of the reported libxls bugs are fixed.
> | > 
> | > As in: in the current libxls GH version?  I can make a patched Debian
> | > release of that.
> | 
> | Yes, they are fixed in master on GitHub. Note that there are quite a few 
> changes since 1.4 – I can’t promise that master has ABI compatibility with 
> the last official 1.4 release. But if you compile the new sources using the 
> old headers (or diff and merge manually) I don’t think there will be an issue 
> on that front.
> 
> Maybe Jenny could take a look?
> 
> It is her use of your library in her package that I stand behind for Debian.

Ah, okay, then the ABI doesn’t matter. I had assumed you were packaging libxls 
as a runtime library + development headers.

> 
> Thanks for all your diligent work on this. It is great to see this move in
> the right ("fuzzing") direction.

Long overdue! :-)

Evan

> 
> Dirk
> 
> | Evan
> | 
> | > 
> | > | I have successfully integrated libxls into OSS-Fuzz, and have added the 
> researcher’s test files to the fuzzing corpus, so that this and related 
> issues should be caught by the address sanitizer in the future.
> | > | 
> | > | OSS-Fuzz has turned up a number of other issues. I will plan to do a 
> release when they are all addressed.
> | > 
> | > That is awesome.
> | > 
> | > Thank you,  Dirk
> | > 
> | > | Evan
> | > | 
> | > | > 
> | > | >> On Jan 15, 2019, at 14:12, Moritz Muehlenhoff  <mailto:j...@inutil.org>> wrote:
> | > | >> 
> | > | >> On Tue, Jan 15, 2019 at 10:43:25AM -0600, Dirk Eddelbuettel wrote:
> | > | >>> 
> | > | >>> Hi Evan,
> | > | >>> 
> | > | >>> On 15 January 2019 at 11:18, Evan Miller wrote:
> | > | >>> | 
> | > | >>> | > On Jan 15, 2019, at 03:06, Moritz Muehlenhoff  <mailto:j...@inutil.org>> wrote:
> | > | >>> | > 
> | > | >>> | > On Mon, Jan 14, 2019 at 08:45:56PM -0500, Evan Miller wrote:
> | > | >>> | >> Oddly, all four issues (#34, #35, #36, #37) seem to have 
> disappeared from GitHub. I don’t know if the original reporter intended to 
> close them, or what.
> | > | >>> | >> 
> | > | >>> | >> I have an email copy of #34 but do not have access to the PoC 
> files. So without the cooperation of the reporter (Zhao Liang, Huawei Weiran 
> Labs) my ability to research will be limited.
> | > | >>> | > 
> | > | >>> | > That's really strange, do you have the mail address of Zhao, 
> could you ask him what happened?
> | > | >>> | 
> | > | >>> | His address may be leon.zha...@gmail.com 
> <mailto:leon.zha...@gmail.com> - I’ll try it. His GitHub profile is now a 404.
> | > | >>> | 
> | > | >>> | > 
> | > | >>> | > MITRE doesn't archive security content per se, they only deal 
> with the organisation and assignment
> | > | >>> | > of numbers. The Internet Archive's Wayback machine also hasn't 
> archived the Github pages.
> | > | >>> | > 
> | > | >>> | > Cheers,
> | > | >>> | >Moritz
> | > | >>> | 
> | > | >>> | 
> | > | >>> | Here are the Google caches of #34 and #35:
> | > | >>> | 
> | > | >>> | 
> https://webcache.googleusercontent.com/search?q=cache:pgRHJwznP7wJ:https://github.com/evanmiller/libxls/issues/34+&cd=1&hl=en&ct=clnk&gl=us&client=safari
>  
> <https://webcache.googleusercontent.com/search?q=cache:pgRHJwznP7wJ:https://github.com/evanmiller/libxls/issues/34+&cd=1&hl=en&ct=clnk&gl=us&client=safari>
> | > | >>> | 
> | > | >>> | 
> https://webcache.googleusercontent.com/search?q=cache:5GNSeHQTzEsJ:https://github.com/evanmiller/libxls/issues/35+&cd=1&hl=en&ct=clnk&gl=us&client=safari
>  
> <https://webcache.googleusercontent.com/search?q=

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

> On Jan 24, 2019, at 17:01, Jennifer Bryan  wrote:
> 
> Thanks for the update and fixes, Evan!
> 
> What sort of timeframe do you have in mind re: your official release?
> 
> That affects how I think about timing a readxl release. I don't do them 
> lightly but also want to get the fixes that address the CVEs into readxl 
> sooner rather than later.

I’m aiming to have a release in the next two weeks. Down to the last 4-5 issues 
unearthed by OSS-Fuzz but I will have limited computer access next week.

Evan

> 
> -- Jenny
> 
>> On Thu, Jan 24, 2019 at 1:36 PM Evan Miller  wrote:
>> 
>>> On Jan 23, 2019, at 01:16, Evan Miller  wrote:
>>> 
>>> #34 and #35 have returned from the dead on GitHub. I’ll take a closer look 
>>> later this week.
>>> 
>>> Evan
>> 
>> 
>> OK — I can confirm that all of the reported libxls bugs are fixed. I have 
>> successfully integrated libxls into OSS-Fuzz, and have added the 
>> researcher’s test files to the fuzzing corpus, so that this and related 
>> issues should be caught by the address sanitizer in the future.
>> 
>> OSS-Fuzz has turned up a number of other issues. I will plan to do a release 
>> when they are all addressed.
>> 
>> Evan
>> 
>>> 
>>>> On Jan 15, 2019, at 14:12, Moritz Muehlenhoff  wrote:
>>>> 
>>>>> On Tue, Jan 15, 2019 at 10:43:25AM -0600, Dirk Eddelbuettel wrote:
>>>>> 
>>>>> Hi Evan,
>>>>> 
>>>>> On 15 January 2019 at 11:18, Evan Miller wrote:
>>>>> | 
>>>>> | > On Jan 15, 2019, at 03:06, Moritz Muehlenhoff  wrote:
>>>>> | > 
>>>>> | > On Mon, Jan 14, 2019 at 08:45:56PM -0500, Evan Miller wrote:
>>>>> | >> Oddly, all four issues (#34, #35, #36, #37) seem to have disappeared 
>>>>> from GitHub. I don’t know if the original reporter intended to close 
>>>>> them, or what.
>>>>> | >> 
>>>>> | >> I have an email copy of #34 but do not have access to the PoC files. 
>>>>> So without the cooperation of the reporter (Zhao Liang, Huawei Weiran 
>>>>> Labs) my ability to research will be limited.
>>>>> | > 
>>>>> | > That's really strange, do you have the mail address of Zhao, could 
>>>>> you ask him what happened?
>>>>> | 
>>>>> | His address may be leon.zha...@gmail.com - I’ll try it. His GitHub 
>>>>> profile is now a 404.
>>>>> | 
>>>>> | > 
>>>>> | > MITRE doesn't archive security content per se, they only deal with 
>>>>> the organisation and assignment
>>>>> | > of numbers. The Internet Archive's Wayback machine also hasn't 
>>>>> archived the Github pages.
>>>>> | > 
>>>>> | > Cheers,
>>>>> | >Moritz
>>>>> | 
>>>>> | 
>>>>> | Here are the Google caches of #34 and #35:
>>>>> | 
>>>>> | 
>>>>> https://webcache.googleusercontent.com/search?q=cache:pgRHJwznP7wJ:https://github.com/evanmiller/libxls/issues/34+&cd=1&hl=en&ct=clnk&gl=us&client=safari
>>>>> | 
>>>>> | 
>>>>> https://webcache.googleusercontent.com/search?q=cache:5GNSeHQTzEsJ:https://github.com/evanmiller/libxls/issues/35+&cd=1&hl=en&ct=clnk&gl=us&client=safari
>>>>> | 
>>>>> | The PoC links are dead.
>>>>> | 
>>>>> | Looking at the backtraces and the commit fixing #36 and #37 
>>>>> (https://github.com/evanmiller/libxls/commit/24044ad7d7cec8a6a1c2370caad27890121a776e)
>>>>>  it is my belief that issues #34 and #35 are NOT fixed.
>>>>> | 
>>>>> | I’ll look into them soon.
>>>>> 
>>>>> You're awesome!  Much appreciated.
>>>>> 
>>>>> Moritz: Do you expect the CVE to puliverize too, or will it remain active 
>>>>> and
>>>>> open, but "simply" without any hard (public) evidence backing it?
>>>> 
>>>> No, they stick around, it sometimes happens that references vanish, e.g. 
>>>> then hosting sites
>>>> go down (think of berlios or similar)
>>>> 
>>>> Cheers,
>>>>Moritz
>>> 
>> 

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

> On Jan 24, 2019, at 19:10, Dirk Eddelbuettel  wrote:
> 
> 
> On 24 January 2019 at 16:36, Evan Miller wrote:
> | 
> | > On Jan 23, 2019, at 01:16, Evan Miller  wrote:
> | > 
> | > #34 and #35 have returned from the dead on GitHub. I’ll take a closer 
> look later this week.
> | > 
> | > Evan
> | 
> | 
> | OK — I can confirm that all of the reported libxls bugs are fixed.
> 
> As in: in the current libxls GH version?  I can make a patched Debian
> release of that.

Yes, they are fixed in master on GitHub. Note that there are quite a few 
changes since 1.4 – I can’t promise that master has ABI compatibility with the 
last official 1.4 release. But if you compile the new sources using the old 
headers (or diff and merge manually) I don’t think there will be an issue on 
that front.

Evan

> 
> | I have successfully integrated libxls into OSS-Fuzz, and have added the 
> researcher’s test files to the fuzzing corpus, so that this and related 
> issues should be caught by the address sanitizer in the future.
> | 
> | OSS-Fuzz has turned up a number of other issues. I will plan to do a 
> release when they are all addressed.
> 
> That is awesome.
> 
> Thank you,  Dirk
> 
> | Evan
> | 
> | > 
> | >> On Jan 15, 2019, at 14:12, Moritz Muehlenhoff  <mailto:j...@inutil.org>> wrote:
> | >> 
> | >> On Tue, Jan 15, 2019 at 10:43:25AM -0600, Dirk Eddelbuettel wrote:
> | >>> 
> | >>> Hi Evan,
> | >>> 
> | >>> On 15 January 2019 at 11:18, Evan Miller wrote:
> | >>> | 
> | >>> | > On Jan 15, 2019, at 03:06, Moritz Muehlenhoff  <mailto:j...@inutil.org>> wrote:
> | >>> | > 
> | >>> | > On Mon, Jan 14, 2019 at 08:45:56PM -0500, Evan Miller wrote:
> | >>> | >> Oddly, all four issues (#34, #35, #36, #37) seem to have 
> disappeared from GitHub. I don’t know if the original reporter intended to 
> close them, or what.
> | >>> | >> 
> | >>> | >> I have an email copy of #34 but do not have access to the PoC 
> files. So without the cooperation of the reporter (Zhao Liang, Huawei Weiran 
> Labs) my ability to research will be limited.
> | >>> | > 
> | >>> | > That's really strange, do you have the mail address of Zhao, could 
> you ask him what happened?
> | >>> | 
> | >>> | His address may be leon.zha...@gmail.com 
> <mailto:leon.zha...@gmail.com> - I’ll try it. His GitHub profile is now a 404.
> | >>> | 
> | >>> | > 
> | >>> | > MITRE doesn't archive security content per se, they only deal with 
> the organisation and assignment
> | >>> | > of numbers. The Internet Archive's Wayback machine also hasn't 
> archived the Github pages.
> | >>> | > 
> | >>> | > Cheers,
> | >>> | >Moritz
> | >>> | 
> | >>> | 
> | >>> | Here are the Google caches of #34 and #35:
> | >>> | 
> | >>> | 
> https://webcache.googleusercontent.com/search?q=cache:pgRHJwznP7wJ:https://github.com/evanmiller/libxls/issues/34+&cd=1&hl=en&ct=clnk&gl=us&client=safari
>  
> <https://webcache.googleusercontent.com/search?q=cache:pgRHJwznP7wJ:https://github.com/evanmiller/libxls/issues/34+&cd=1&hl=en&ct=clnk&gl=us&client=safari>
> | >>> | 
> | >>> | 
> https://webcache.googleusercontent.com/search?q=cache:5GNSeHQTzEsJ:https://github.com/evanmiller/libxls/issues/35+&cd=1&hl=en&ct=clnk&gl=us&client=safari
>  
> <https://webcache.googleusercontent.com/search?q=cache:5GNSeHQTzEsJ:https://github.com/evanmiller/libxls/issues/35+&cd=1&hl=en&ct=clnk&gl=us&client=safari>
> | >>> | 
> | >>> | The PoC links are dead.
> | >>> | 
> | >>> | Looking at the backtraces and the commit fixing #36 and #37 
> (https://github.com/evanmiller/libxls/commit/24044ad7d7cec8a6a1c2370caad27890121a776e
>  
> <https://github.com/evanmiller/libxls/commit/24044ad7d7cec8a6a1c2370caad27890121a776e>)
>  it is my belief that issues #34 and #35 are NOT fixed.
> | >>> | 
> | >>> | I’ll look into them soon.
> | >>> 
> | >>> You're awesome!  Much appreciated.
> | >>> 
> | >>> Moritz: Do you expect the CVE to puliverize too, or will it remain 
> active and
> | >>> open, but "simply" without any hard (public) evidence backing it?
> | >> 
> | >> No, they stick around, it sometimes happens that references vanish, e.g. 
> then hosting sites
> | >> go down (think of berlios or similar)
> | >> 
> | >> Cheers,
> | >>Moritz
> | > 
> | 
> 
> -- 
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

> On Jan 23, 2019, at 01:16, Evan Miller  wrote:
> 
> #34 and #35 have returned from the dead on GitHub. I’ll take a closer look 
> later this week.
> 
> Evan


OK — I can confirm that all of the reported libxls bugs are fixed. I have 
successfully integrated libxls into OSS-Fuzz, and have added the researcher’s 
test files to the fuzzing corpus, so that this and related issues should be 
caught by the address sanitizer in the future.

OSS-Fuzz has turned up a number of other issues. I will plan to do a release 
when they are all addressed.

Evan

> 
>> On Jan 15, 2019, at 14:12, Moritz Muehlenhoff > <mailto:j...@inutil.org>> wrote:
>> 
>> On Tue, Jan 15, 2019 at 10:43:25AM -0600, Dirk Eddelbuettel wrote:
>>> 
>>> Hi Evan,
>>> 
>>> On 15 January 2019 at 11:18, Evan Miller wrote:
>>> | 
>>> | > On Jan 15, 2019, at 03:06, Moritz Muehlenhoff >> <mailto:j...@inutil.org>> wrote:
>>> | > 
>>> | > On Mon, Jan 14, 2019 at 08:45:56PM -0500, Evan Miller wrote:
>>> | >> Oddly, all four issues (#34, #35, #36, #37) seem to have disappeared 
>>> from GitHub. I don’t know if the original reporter intended to close them, 
>>> or what.
>>> | >> 
>>> | >> I have an email copy of #34 but do not have access to the PoC files. 
>>> So without the cooperation of the reporter (Zhao Liang, Huawei Weiran Labs) 
>>> my ability to research will be limited.
>>> | > 
>>> | > That's really strange, do you have the mail address of Zhao, could you 
>>> ask him what happened?
>>> | 
>>> | His address may be leon.zha...@gmail.com <mailto:leon.zha...@gmail.com> - 
>>> I’ll try it. His GitHub profile is now a 404.
>>> | 
>>> | > 
>>> | > MITRE doesn't archive security content per se, they only deal with the 
>>> organisation and assignment
>>> | > of numbers. The Internet Archive's Wayback machine also hasn't archived 
>>> the Github pages.
>>> | > 
>>> | > Cheers,
>>> | >Moritz
>>> | 
>>> | 
>>> | Here are the Google caches of #34 and #35:
>>> | 
>>> | 
>>> https://webcache.googleusercontent.com/search?q=cache:pgRHJwznP7wJ:https://github.com/evanmiller/libxls/issues/34+&cd=1&hl=en&ct=clnk&gl=us&client=safari
>>>  
>>> <https://webcache.googleusercontent.com/search?q=cache:pgRHJwznP7wJ:https://github.com/evanmiller/libxls/issues/34+&cd=1&hl=en&ct=clnk&gl=us&client=safari>
>>> | 
>>> | 
>>> https://webcache.googleusercontent.com/search?q=cache:5GNSeHQTzEsJ:https://github.com/evanmiller/libxls/issues/35+&cd=1&hl=en&ct=clnk&gl=us&client=safari
>>>  
>>> <https://webcache.googleusercontent.com/search?q=cache:5GNSeHQTzEsJ:https://github.com/evanmiller/libxls/issues/35+&cd=1&hl=en&ct=clnk&gl=us&client=safari>
>>> | 
>>> | The PoC links are dead.
>>> | 
>>> | Looking at the backtraces and the commit fixing #36 and #37 
>>> (https://github.com/evanmiller/libxls/commit/24044ad7d7cec8a6a1c2370caad27890121a776e
>>>  
>>> <https://github.com/evanmiller/libxls/commit/24044ad7d7cec8a6a1c2370caad27890121a776e>)
>>>  it is my belief that issues #34 and #35 are NOT fixed.
>>> | 
>>> | I’ll look into them soon.
>>> 
>>> You're awesome!  Much appreciated.
>>> 
>>> Moritz: Do you expect the CVE to puliverize too, or will it remain active 
>>> and
>>> open, but "simply" without any hard (public) evidence backing it?
>> 
>> No, they stick around, it sometimes happens that references vanish, e.g. 
>> then hosting sites
>> go down (think of berlios or similar)
>> 
>> Cheers,
>>Moritz
> 

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

#34 and #35 have returned from the dead on GitHub. I’ll take a closer look 
later this week.

Evan

> On Jan 15, 2019, at 14:12, Moritz Muehlenhoff  wrote:
> 
> On Tue, Jan 15, 2019 at 10:43:25AM -0600, Dirk Eddelbuettel wrote:
>> 
>> Hi Evan,
>> 
>> On 15 January 2019 at 11:18, Evan Miller wrote:
>> | 
>> | > On Jan 15, 2019, at 03:06, Moritz Muehlenhoff  wrote:
>> | > 
>> | > On Mon, Jan 14, 2019 at 08:45:56PM -0500, Evan Miller wrote:
>> | >> Oddly, all four issues (#34, #35, #36, #37) seem to have disappeared 
>> from GitHub. I don’t know if the original reporter intended to close them, 
>> or what.
>> | >> 
>> | >> I have an email copy of #34 but do not have access to the PoC files. So 
>> without the cooperation of the reporter (Zhao Liang, Huawei Weiran Labs) my 
>> ability to research will be limited.
>> | > 
>> | > That's really strange, do you have the mail address of Zhao, could you 
>> ask him what happened?
>> | 
>> | His address may be leon.zha...@gmail.com - I’ll try it. His GitHub profile 
>> is now a 404.
>> | 
>> | > 
>> | > MITRE doesn't archive security content per se, they only deal with the 
>> organisation and assignment
>> | > of numbers. The Internet Archive's Wayback machine also hasn't archived 
>> the Github pages.
>> | > 
>> | > Cheers,
>> | >Moritz
>> | 
>> | 
>> | Here are the Google caches of #34 and #35:
>> | 
>> | 
>> https://webcache.googleusercontent.com/search?q=cache:pgRHJwznP7wJ:https://github.com/evanmiller/libxls/issues/34+&cd=1&hl=en&ct=clnk&gl=us&client=safari
>> | 
>> | 
>> https://webcache.googleusercontent.com/search?q=cache:5GNSeHQTzEsJ:https://github.com/evanmiller/libxls/issues/35+&cd=1&hl=en&ct=clnk&gl=us&client=safari
>> | 
>> | The PoC links are dead.
>> | 
>> | Looking at the backtraces and the commit fixing #36 and #37 
>> (https://github.com/evanmiller/libxls/commit/24044ad7d7cec8a6a1c2370caad27890121a776e)
>>  it is my belief that issues #34 and #35 are NOT fixed.
>> | 
>> | I’ll look into them soon.
>> 
>> You're awesome!  Much appreciated.
>> 
>> Moritz: Do you expect the CVE to puliverize too, or will it remain active and
>> open, but "simply" without any hard (public) evidence backing it?
> 
> No, they stick around, it sometimes happens that references vanish, e.g. then 
> hosting sites
> go down (think of berlios or similar)
> 
> Cheers,
>Moritz

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

> On Jan 15, 2019, at 11:18, Evan Miller  wrote:
> 
> 
>> On Jan 15, 2019, at 03:06, Moritz Muehlenhoff  wrote:
>> 
>> That's really strange, do you have the mail address of Zhao, could you ask 
>> him what happened?
> 
> His address may be leon.zha...@gmail.com - I’ll try it. His GitHub profile is 
> now a 404.

Okay, email sent, I’ll let you all know if I hear from him.

> 
> Looking at the backtraces and the commit fixing #36 and #37 
> (https://github.com/evanmiller/libxls/commit/24044ad7d7cec8a6a1c2370caad27890121a776e)
>  it is my belief that issues #34 and #35 are NOT fixed.

My revised opinion is that these issues MAY be already fixed. The commit above 
fixed out of bounds writes - it’s possible that such writes were corrupting the 
pointer that was eventually passed to free(), potentially causing both #34 and 
#35. I did not find any obvious logical errors in the relevant malloc/free 
code, but I won’t know for sure without the POC.

One thing I will do in the meantime is to reach out to Google Autofuzz and try 
to get libxls hooked into their infrastructure. They’re pretty good at 
uncovering all kinds of memory issues.

Evan


> 
> I’ll look into them soon.
> 
> Evan
> 
> 

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

> On Jan 15, 2019, at 03:06, Moritz Muehlenhoff  wrote:
> 
> On Mon, Jan 14, 2019 at 08:45:56PM -0500, Evan Miller wrote:
>> Oddly, all four issues (#34, #35, #36, #37) seem to have disappeared from 
>> GitHub. I don’t know if the original reporter intended to close them, or 
>> what.
>> 
>> I have an email copy of #34 but do not have access to the PoC files. So 
>> without the cooperation of the reporter (Zhao Liang, Huawei Weiran Labs) my 
>> ability to research will be limited.
> 
> That's really strange, do you have the mail address of Zhao, could you ask 
> him what happened?

His address may be leon.zha...@gmail.com - I’ll try it. His GitHub profile is 
now a 404.

> 
> MITRE doesn't archive security content per se, they only deal with the 
> organisation and assignment
> of numbers. The Internet Archive's Wayback machine also hasn't archived the 
> Github pages.
> 
> Cheers,
>Moritz


Here are the Google caches of #34 and #35:

https://webcache.googleusercontent.com/search?q=cache:pgRHJwznP7wJ:https://github.com/evanmiller/libxls/issues/34+&cd=1&hl=en&ct=clnk&gl=us&client=safari

https://webcache.googleusercontent.com/search?q=cache:5GNSeHQTzEsJ:https://github.com/evanmiller/libxls/issues/35+&cd=1&hl=en&ct=clnk&gl=us&client=safari

The PoC links are dead.

Looking at the backtraces and the commit fixing #36 and #37 
(https://github.com/evanmiller/libxls/commit/24044ad7d7cec8a6a1c2370caad27890121a776e)
 it is my belief that issues #34 and #35 are NOT fixed.

I’ll look into them soon.

Evan

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

Oddly, all four issues (#34, #35, #36, #37) seem to have disappeared from 
GitHub. I don’t know if the original reporter intended to close them, or what.

I have an email copy of #34 but do not have access to the PoC files. So without 
the cooperation of the reporter (Zhao Liang, Huawei Weiran Labs) my ability to 
research will be limited.

Evan

> On Jan 14, 2019, at 19:22, Dirk Eddelbuettel  wrote:
> 
> 
> Hi Evan,
> 
> On 14 January 2019 at 19:03, Evan Miller wrote:
> | Hi Dirk,
> | 
> | You are correct - these are issues with the underlying C library, the 
> GitHub issues you referenced. I have not researched them specifically, but I 
> recently fixed two issues (#36 and #37) that are possibly related:
> | 
> | https://github.com/evanmiller/libxls/issues/36 
> <https://github.com/evanmiller/libxls/issues/36>
> | https://github.com/evanmiller/libxls/issues/37 
> <https://github.com/evanmiller/libxls/issues/37>
> | 
> | I will look into #34 and #35 when I get a chance.
> 
> Thanks for the prompt follow-up.  Please keep us posted and abreast of any 
> progress.
> 
> Dirk
> 
> | Evan
> | 
> | > On Jan 14, 2019, at 17:56, Dirk Eddelbuettel  wrote:
> | > 
> | > 
> | > Hi Evan,
> | > 
> | > On 14 January 2019 at 23:32, Moritz Muehlenhoff wrote:
> | > | Package: r-cran-readxl
> | > | Severity: important
> | > | Tags: security
> | > | 
> | > | These two libxls issues should affect r-cran-readxl:
> | > | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20450
> | > | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20452
> | > 
> | > These are both file as #34 and #35 at your GitHub repo, but I did not see 
> any
> 
> s/file/filed/  -- sorry
> 
> | > follow-up.  I presume this is similar to the last time that the issue 
> really
> | > stems from the underlying C parser library?  Any idea how long it may take
> | > until we have a fix?
> | > 
> | > Courtesy to Jenny who via readxl 'upstream' is the real maintainer for
> | > the
> 
> s/Courtesy/Courtesy CC/ -- sorry
> 
> | > CRAN package I mostly just wrap up for Debian.
> | > 
> | > Best,  Dirk
> | > 
> | > | Cheers,
> | > | Moritz
> | > 
> | > -- 
> | > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> | 
> 
> -- 
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#907731: closed by Michael Gilbert (Bug#907731: fixed in steam 1.0.0.56-1)

[Evan Goers]

1IkyYrxQj4ZcDWPAQSY2BauinktgxxGT5KpxQfUbGYMLWugfE
> adVcPYvwPFHKhBVa54msB1//z1w3gb3+ayQLYvx9marM+qt5d02HEYxDLi3M6Tgm
> 7g/2gm3ScCtxWA0czpKzoP3HU8s99rxN3dZLWfEe7CGHOUmi2acrYH3Y4o15P6Ek
> I/W1UttH6pWqWXy05wplQR40EukzFBNIIiXV6Qp5NfQfFwk+Ydp6/iO02R8nP2We
> ba15M/adzz6nRdjL65mCXEuB9mb5XDghXT0xFM33nkb+QDf3IQz8BHPY+U4SQCI1
> HM0W18fkAiSeSYYJvDAtw8+pp3RaE0zTk/xINNYQm4upTuteHWehnjIDy9mpWAnI
> 1n9JgYa3x8YCfhaLZ/lbGmJdsXcFCF0VpbYlzT+wPumqTX9yPmpqi+p9GKdIDfwj
> 3wCEwrOLEHNIRPTRaRw5M3/judkY4Qg2yCUIriFcTV4NVjLJLbmblEd+wLvZiauJ
> e/v9Qoj161YFoD7AApBAR9dhxL0+Kkh/JvE7SK85lSV8b1hMNCmLS48R1Dn1C/kJ
> kqV5gXJN60+Yz8LVQM+UfQpgU5Y7K+zt3W+zBnMpt2hAQqg5S6Nc09N21eFnc3E2
> pd1qs6AA6Sd4JX/KlGnSHEzUW59hUHphQt3lwEJIkECa4geHtRm+CK5xIxlMapdK
> 893GLBiu+TRn0K9xgvL6lSxip+btebqas86fkgZ9knH4oGJraNislCcmxR1SGjob
> ldy7dZ6WJhKjkxWSfuOVpW00e4GuZvl6gtpGr/yeWqb1D9ncE/E1NV3ORi4kO/f2
> x57ln+wu+zRxYOyMJNNzI6YmAwWqTXEytjTBbjf4+rKIVyWpBMznnxPaaxqTpuTg
> 3iuV6aos+gyZ8EogIxa/VKxpBdE/aZgswfEpMWR6lYn0y+0vN1Obb+qhfHy85cXu
> UGghxgh/dHiWoHGm7etm19zJqwFMJDAyIdqTUJF6rlUnGiOsJs12k4AL5Ac1TMVt
> tpK45/a2sxP66iV37bn4tAFuds8Q3A==
> =4m5B
> -END PGP SIGNATURE-
>
>
> -- Forwarded message --
> From: Evan Goers 
> To: sub...@bugs.debian.org
> Cc:
> Bcc:
> Date: Fri, 31 Aug 2018 20:58:46 -0400
> Subject: steam-devices: Steam Controller undetected in Steam due to
> incorrect udev rules from steam-devices package
>
> Package: steam-devices
>
> Version: 1.0.0.55-1
>
> Severity: normal
>
>
> Dear Maintainer,
>
>
>  * What exactly did you do (or not do) that was effective (or
>
> ineffective)?
>
> Uninstalled the steam-devices package and used the recommended udev rules
> from the Steam community. The recommended rules suggest 0666 for Valve's
> controllers, instead of 0660 as is used in the steam-devices rules.
>
> * What was the outcome of this action?
>
> The controller was detected by Steam(big picture mode).
>
>
> It seems that changing the permissions MODE from 0660 to 0666 for
>
> Valve's devices in /lib/udev/rules.d/99-steam-controller-perms.rules
> allows the
>
> devices to work as expected. It may be necessary to change them all to
> 0666 to
>
> allow them to function normally. I can only test the Steam Controller as I
>
> don't have any of the rest listed. 0666 may be required now due to recent
> changes in Steam.
>
> -- System Information:
>
> Debian Release: buster/sid
>
> APT prefers testing
>
> APT policy: (500, 'testing')
>
> Architecture: amd64 (x86_64)
>
> Foreign Architectures: i386
>
>
> Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores)
>
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=
> (charmap=UTF-8)
>
> Shell: /bin/sh linked to /bin/dash
>
> Init: systemd (via /run/systemd/system)
>
> LSM: AppArmor: enabled
>
>
> steam-devices depends on no packages.
>
>
> Versions of packages steam-devices recommends:
>
> ii steam 1.0.0.55-1
>
>
> steam-devices suggests no packages.
>
>
>

Bug#907731: steam-devices: Steam Controller undetected in Steam due to incorrect udev rules from steam-devices package

[Evan Goers]

Package: steam-devices

Version: 1.0.0.55-1

Severity: normal


Dear Maintainer,


 * What exactly did you do (or not do) that was effective (or

ineffective)?

Uninstalled the steam-devices package and used the recommended udev rules
from the Steam community. The recommended rules suggest 0666 for Valve's
controllers, instead of 0660 as is used in the steam-devices rules.

* What was the outcome of this action?

The controller was detected by Steam(big picture mode).


It seems that changing the permissions MODE from 0660 to 0666 for

Valve's devices in /lib/udev/rules.d/99-steam-controller-perms.rules allows
the

devices to work as expected. It may be necessary to change them all to 0666
to

allow them to function normally. I can only test the Steam Controller as I

don't have any of the rest listed. 0666 may be required now due to recent
changes in Steam.

-- System Information:

Debian Release: buster/sid

APT prefers testing

APT policy: (500, 'testing')

Architecture: amd64 (x86_64)

Foreign Architectures: i386


Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores)

Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=
(charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash

Init: systemd (via /run/systemd/system)

LSM: AppArmor: enabled


steam-devices depends on no packages.


Versions of packages steam-devices recommends:

ii steam 1.0.0.55-1


steam-devices suggests no packages.

Bug#897569: Dh_Lib.pm: rename_path cannot move between filesystems

[Evan Krall]

Source: debhelper
Version: 11.1.6
Severity: normal

Dear Maintainer,

When running dpkg-buildpackage in a directory that is the root of a
filesystem (in my case, I'm building inside a docker container, and the
source is a volume mount), I get an error:

Renaming paasta-tools-dbgsym_0.70.5~bionic1_amd64.deb to 
paasta-tools-dbgsym_0.70.5~bionic1_amd64.ddeb
dh_builddeb: mv 
debian/.debhelper/scratch-space/build-paasta-tools/paasta-tools-dbgsym_0.70.5\~bionic1_amd64.deb
 ../paasta-tools-dbgsym_0.70.5\~bionic1_amd64.ddeb: Invalid cross-device link
dh_builddeb: Aborting due to earlier error

I think this is due to the commit
79da6af50c03f4a2508b1a6c0336d86470e7dd58 ("Avoid forking for most
renames"), which replaces a call to the `mv` command (which handles
cross-filesystem moves) with a call to the
`rename` syscall (which does not, and returns EXDEV).

It appears that a similar issue came up long ago with
update-alternatives in bug 42559; the resolution there was to call
rename(2) and then fall back to mv(1) if rename fails. This logic remains
today in update-alternatives.c.


-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 'bionic')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-75-generic (SMP w/32 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#588434: libpam-ldap: unable to change password in default configuration

[Evan King]

Some details I neglected to mention:

 - Whether pam_encryptfs is installed/configured has no effect.
 - My /etc/nsswitch.conf file is almost identical:

passwd: files ldap
group:  files ldap
shadow: files ldap
+gshadow:files

hosts:  files dns
networks:   files

protocols:  db files
services:   db files
ethers: db files
rpc:db files

netgroup:   nis

The gshadow line is additional on the bad host, but removing it (or 
adding it to the good host) has no effect.


Differences in packages installed related to ldap:

root@goodhost:/etc/pam.d# apt search ldap | grep installed
auth-client-config/xenial,xenial,now 0.9ubuntu1 all [installed,automatic]
curl/xenial-updates,xenial-security,now 7.47.0-1ubuntu2.2 amd64 [installed]
+dovecot-ldap/xenial-updates,now 1:2.2.22-1ubuntu2.2 amd64 [installed]
ldap-auth-client/xenial,xenial,now 0.5.3 all [installed]
ldap-auth-config/xenial,xenial,now 0.5.3 all [installed]
ldap-utils/xenial-updates,now 2.4.42+dfsg-2ubuntu3.1 amd64 [installed]
+libaprutil1-ldap/xenial,now 1.5.4-1build1 amd64 [installed,automatic]
+libcurl3/xenial-updates,xenial-security,now 7.47.0-1ubuntu2.2 amd64 
[installed,automatic]
libcurl3-gnutls/xenial-updates,xenial-security,now 7.47.0-1ubuntu2.2 
amd64 [installed]

libldap-2.4-2/xenial-updates,now 2.4.42+dfsg-2ubuntu3.1 amd64 [installed]
libldb1/xenial,now 2:1.1.24-1ubuntu3 amd64 [installed]
libnss-ldap/xenial,now 265-3ubuntu2 amd64 [installed]
libpam-ldap/xenial,now 184-8.7ubuntu1 amd64 [installed]
+libsasl2-modules-ldap/xenial,now 2.1.26.dfsg1-14build1 amd64 [installed]
+monit/xenial,now 1:5.16-2 amd64 [installed]
+php5-ldap/now 5.5.9+dfsg-1ubuntu4.20 amd64 [installed,local]
+postfix-ldap/xenial,now 3.1.0-3 amd64 [installed]
+python-ldap/xenial,now 2.4.22-0.1 amd64 [installed]
python-ldb/xenial,now 2:1.1.24-1ubuntu3 amd64 [installed]
sudo/xenial-updates,now 1.8.16-0ubuntu1.2 amd64 [installed]

root@badhost:/etc/pam.d# apt search ldap | grep installed
auth-client-config/xenial,now 0.9ubuntu1 all [installed,automatic]
curl/xenial-security,xenial-updates,now 7.47.0-1ubuntu2.2 amd64 
[installed,automatic]

ldap-auth-client/xenial,now 0.5.3 all [installed,automatic]
ldap-auth-config/xenial,now 0.5.3 all [installed,automatic]
ldap-utils/xenial-updates,now 2.4.42+dfsg-2ubuntu3.1 amd64 [installed]
libcurl3-gnutls/xenial-security,xenial-updates,now 7.47.0-1ubuntu2.2 
amd64 [installed,automatic]
libldap-2.4-2/xenial-updates,now 2.4.42+dfsg-2ubuntu3.1 amd64 
[installed,automatic]

libldb1/xenial,now 2:1.1.24-1ubuntu3 amd64 [installed,automatic]
libnet-ldap-perl/xenial,now 1:0.6500+dfsg-1 all [installed,automatic]
libnss-ldap/xenial,now 265-3ubuntu2 amd64 [installed]
libpam-ldap/xenial,now 184-8.7ubuntu1 amd64 [installed]
libslp1/xenial,now 1.2.1-11 amd64 [installed,automatic]
python-ldb/xenial,now 2:1.1.24-1ubuntu3 amd64 [installed,automatic]
+slapd/xenial-updates,now 2.4.42+dfsg-2ubuntu3.1 amd64 [installed]
+slapd-smbk5pwd/xenial-updates,now 2.4.42+dfsg-2ubuntu3.1 amd64 [installed]
sudo/xenial-updates,now 1.8.16-0ubuntu1.2 amd64 [installed]

I toyed with the possibility that sasl might be the missing piece to no 
avail.  Frankly I hope it's not.


Cheers,
 - Evan

Bug#588434: Subject: libpam-ldap: unable to change password in default configuration

[Evan King]

I can confirm that either removing use_authtok or installing 
libpam-cracklib bypasses the issue, but also that there is a third fix 
which does not involve:
 - adding a dependency that introduces unrelated (possibly unwanted) 
features

 - breaking the functionality intended by including use_authtok
 - maintaining a hack to override the package-supplied configuration

I don't know exactly what that fix is, only that it exists, because I 
have two Ubuntu 16.04 machines, one of which exhibits this problem and 
the other does not.


In the interest of discovering this fix, I've determined the following:

They both have an identical set of libpam modules installed and 
identically configured:


root@host:~# apt search libpam | grep installed
libpam-cap/xenial,now 1:2.24-12 amd64 [installed]
libpam-ldap/xenial,now 184-8.7ubuntu1 amd64 [installed]
libpam-modules/xenial,now 1.1.8-3.2ubuntu2 amd64 [installed]
libpam-modules-bin/xenial,now 1.1.8-3.2ubuntu2 amd64 [installed]
libpam-mount/xenial,now 2.14-1.1 amd64 [installed]
libpam-runtime/xenial,now 1.1.8-3.2ubuntu2 all [installed]
libpam-systemd/xenial-updates,now 229-4ubuntu13 amd64 [installed,automatic]
libpam0g/xenial,now 1.1.8-3.2ubuntu2 amd64 [installed]

There are some different service-specific configurations added, but 
every file that appears in both of these ls outputs is identical:


root@goodhost:/etc/pam.d# ll
total 104K
-rw-r--r-- 1 root root  258 2016-01-14 18:35:17 atd
-rw-r--r-- 1 root root  384 2010-01-26 13:01:31 chfn
-rw-r--r-- 1 root root   92 2010-01-26 13:01:31 chpasswd
-rw-r--r-- 1 root root  581 2010-01-26 13:01:31 chsh
-rw-r--r-- 1 root root 1.3K 2016-12-15 15:44:53 common-account
-rw-r--r-- 1 root root 1.4K 2016-12-15 15:44:53 common-auth
-rw-r--r-- 1 root root   70 2010-07-31 01:52:24 common-pammount
-rw-r--r-- 1 root root 1.6K 2016-12-15 18:16:36 common-password
-rw-r--r-- 1 root root 1.6K 2016-12-15 15:44:54 common-session
-rw-r--r-- 1 root root 1.5K 2016-12-15 15:44:54 
common-session-noninteractive

-rw-r--r-- 1 root root  606 2016-04-05 18:59:02 cron
-rw-r--r-- 1 root root   81 2010-04-19 14:18:56 dovecot
-rw-r--r-- 1 root root 4.8K 2016-01-29 21:21:30 login
-rw-r--r-- 1 root root  100 2011-12-21 12:13:38 monit
-rw-r--r-- 1 root root   92 2010-01-26 13:01:31 newusers
-rw-r--r-- 1 root root  520 2010-04-13 19:01:47 other
-rw-r--r-- 1 root root   92 2010-01-26 13:01:31 passwd
-rw-r--r-- 1 root root  255 2014-02-11 14:45:25 polkit-1
-rw-r--r-- 1 root root  143 2016-03-12 11:14:57 runuser
-rw-r--r-- 1 root root  138 2016-03-12 11:14:57 runuser-l
-rw-r--r-- 1 root root   84 2010-03-19 18:16:58 samba
-rw-r--r-- 1 root root 2.1K 2016-08-11 13:25:09 sshd
-rw-r--r-- 1 root root 2.3K 2015-11-12 18:12:32 su
-rw-r--r-- 1 root root  239 2016-08-17 10:20:48 sudo
-rw-r--r-- 1 root root  251 2016-10-26 10:04:44 systemd-user


root@badhost:/etc/pam.d# ll
total 85K
-rw-r--r-- 1 root root  258 2016-01-14 18:35:17 atd
-rw-r--r-- 1 root root  384 2015-11-12 18:12:32 chfn
-rw-r--r-- 1 root root   92 2015-11-12 18:12:32 chpasswd
-rw-r--r-- 1 root root  581 2015-11-12 18:12:32 chsh
-rw-r--r-- 1 root root 1.3K 2016-12-15 21:36:41 common-account
-rw-r--r-- 1 root root 1.4K 2016-12-15 21:36:41 common-auth
-rw-r- 1 root root   70 2016-12-15 15:31:07 common-pammount
-rw-r--r-- 1 root root 1.6K 2016-12-15 21:36:41 common-password
-rw-r--r-- 1 root root 1.6K 2016-12-15 21:36:41 common-session
-rw-r--r-- 1 root root 1.5K 2016-12-15 21:36:41 
common-session-noninteractive

-rw-r--r-- 1 root root  606 2016-04-05 18:59:02 cron
-rw-r--r-- 1 root root 4.8K 2016-01-29 21:21:30 login
-rw-r--r-- 1 root root  145 2016-12-09 03:43:43 mysql
-rw-r--r-- 1 root root   92 2015-11-12 18:12:32 newusers
-rw-r--r-- 1 root root  520 2016-03-16 15:09:13 other
-rw-r--r-- 1 root root   92 2015-11-12 18:12:32 passwd
-rw-r--r-- 1 root root  255 2016-01-17 19:13:21 polkit-1
-rw-r--r-- 1 root root  143 2016-03-12 11:14:57 runuser
-rw-r--r-- 1 root root  138 2016-03-12 11:14:57 runuser-l
-rw-r--r-- 1 root root   84 2016-03-07 21:23:05 samba
-rw-r--r-- 1 root root 2.1K 2016-04-28 05:52:36 sshd
-rw-r--r-- 1 root root 2.3K 2015-11-12 18:12:32 su
-rw-r--r-- 1 root root  239 2016-03-30 16:57:11 sudo
-rw-r--r-- 1 root root  251 2016-04-12 07:34:03 systemd-user
-rw-r--r-- 1 root root   55 2016-04-15 07:04:33 vmtoolsd

At this point I'm out of ideas on how to identify the difference that 
stops use_authtok from breaking passwd, but very interested in doing so.


Cheers,
 - Evan

Bug#840597: ITP: pyflame -- CPU profiler and flame graph tool for Python

[Evan Klitzke]

Package: wnpp
Severity: wishlist
Owner: Evan Klitzke 

* Package name: pyflame
  Version : 1.1.0
  Upstream Author : Evan Klitzke 
* URL : https://github.com/uber/pyflame
* License : Apache2
  Programming Lang: Python
  Description : CPU profiler and flame graph tool for Python

Pyflame is a tool that uses the ptrace system call to analyze running
Python processes and collect stack traces and generate flame graphs. It
can be used as an alternative to, or alongside, existing Python
profilers like cProfile.

I am also the upstream author of Pyflame, and Pyflame is something I
developed for my work at my job. It's already been packaged for Debian
for our internal use, but I'd like ot contribute it to Debian proper.
I'll have the time and resources to maintain this package because it
will be part of my work at my job.

This will be my first package in Debian and I may need some hand-holding
through the process. I would very much like to eventually become a DM,
and I hope this is the first package of many that I can help maintain.
Therefore I will need a sponsor.

One further note: Pyflame itself is written in C++, and can be built
against Python2 or Python3. I'm not sure what the best way to package
that is.

Bug#834373: Checking In

[Evan Cox]

Hello,

Just wanted to check if there was any way I could help diagnose this. Not
sure if the problem is in the Debian partman-efi component, or due to
something that Ubiquiti is doing.

Thanks,

Evan

Bug#834373: UEFI: Fails to install to blank drive

[Evan Cox]

Package: partman-efi

As per #85 at
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1418706 , I was
asked to file this bug in Debian's bug tracker. The basic issue is that
Ubuntu fails to install to a completely blank drive (e.g. a blank virtual
hard disk) if installing in UEFI mode and you choose a custom partition
layout. This bug is present in multiple Ubuntu releases, including 16.04
LTS. Not sure which version of partman-efi this is, as I cannot actually
install Ubuntu to check. To quote from the original report:

"When doing a UEFI-mode install using the latest daily Vivid ISO (Thu Feb
5), Ubiquity incorrectly concludes that a blank drive contains an existing
BIOS-mode install (see error in attached screenshot).
The resulting error dialog is also broken: none of the buttons do any thing
when clicked: X (close button), "Go Back", "Continue".
You can seemingly move the install forward by clicking "Continue" in the
main installer window, but things are still broken somewhere as grub isn't
getting correctly installed (system is unbootable after the install
completes)."

Thanks,
Evan

Bug#833897: ITP: abduco -- Terminal session management in a clean and simple way

[Evan Hanson]

Hi Antoine,

On 2016-08-10  1:54, Antoine Beaupr?? wrote:
> Abduco was removed from Debian in may because it was out of date. This
> is an attempt at updating the package to a more recent versions that
> is hopefully more stable.

Please note that the package wasn't removed because it was out of date,
but due to uncertainy around its licensing; refer to Bug#771102 and
Bug#821237 for more info. I believe that uncertainty will need to be
resolved before abduco can be included in Debian again.

Cheers,

Evan


signature.asc
Description: Digital signature

Bug#824082: r-cran-tm: missing dependencies on r-cran-nlp and r-cran-slam

[Evan Thompson]

Package: r-cran-tm
Version: 0.6-2-2
Severity: serious
Justification: Policy 3.5

Dear Maintainer,

When attempting to load tm in R:

> library(tm)
Error: package ‘NLP’ required by ‘tm’ could not be found

Installing r-cran-nlp solves this first issue, but then:

> library(tm)
Loading required package: NLP
Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]) :
  there is no package called ‘slam’
Error: package or namespace load failed for ‘tm’

Installing r-cran-slam solves the second issue.

Regards,
-- Evan Thompson



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

Kernel: Linux 4.5-3.dmz.2-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages r-cran-tm depends on:
ii  libc6  2.22-7
ii  r-base-core [r-api-3]  3.3.0-1

r-cran-tm recommends no packages.

r-cran-tm suggests no packages.

-- no debconf information

Bug#771102: upstream license violation

[Evan Hanson]

Hi Ned,

Formally yes, but see my response to #821237, whose action may moot the
point. I'll update this bug with whatever info that one brings shortly.

Best regards,

Evan


signature.asc
Description: PGP signature

Bug#821237: abduco: should it be removed from Debian?

[Evan Hanson]

Hi Mattia,

Thanks for the nudge. When #771102 was raised, I tried to contact
upstream regarding the potential licensing issues but received no
response, and there the bug sat. It's now been quite some time, however,
and I agree something should be done.

I'll make one more attempt to bring the issue to the developer's
attention, but failing a response and positive resolution I agree that
the package should be be removed.

Evan


signature.asc
Description: PGP signature

Bug#820409: r-cran-dplyr: missing dependency on r-cran-assertthat

[Evan Thompson]

Package: r-cran-dplyr
Version: 0.4.3-1
Severity: serious
Justification: Policy 3.5

Dear Maintainer,

When attempting to load dplyr in R:

> library(dplyr)
Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]) :
  there is no package called ‘assertthat’
Error: package or namespace load failed for ‘dplyr’

Installing r-cran-assertthat solves the issue.

Regards,
-- Evan Thompson



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

Kernel: Linux 4.4-6.dmz.1-liquorix-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages r-cran-dplyr depends on:
ii  libc6  2.22-5
ii  libgcc11:5.3.1-13
ii  libstdc++6 5.3.1-13
ii  r-base-core [r-api-3]  3.2.4.20160406-1
ii  r-cran-dbi 0.3.1-1
ii  r-cran-magrittr1.5-1

r-cran-dplyr recommends no packages.

r-cran-dplyr suggests no packages.

-- no debconf information

Bug#425778: verified this bug report

[Evan Harris]

Unfortunately using convert or other tools that recompress the jpeg end up 
with a generational quality loss, which most people would probably want to 
avoid.


On Sat, 07 Jun 2008 22:49:55 -0400 Jay Berkenbilt  wrote:


I've verified that this bug still applies to the current beta of libtiff 
4.0.0, so even though I have backported the largely rewritten tiff2pdf, 
the problem has not gone away.  Hopefully it will get some attention 
upstream.


In the mean time, though I'm sure you've already figured this out, I'll 
point out that you can convert this tiff to PDF using "convert" from 
ImageMagick.  It does a better job of creating PDF files than tiff2pdf, 
which is a very buggy piece of software.


--Jay



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

Bug#698392: Installation hangs starting up the partitioner

[Evan Trimby]

Just had the same issue. Downloaded the netinstall with all firmware
"firmware-7.8.0-amd64-netinst.iso" and restarted the install before I found
this thread. Install completed flawlessly.

Bug#765109: fglrx-driver: Black screen after xorg startup

[Evan Benn]

Package: fglrx-driver
Version: 1:14.9+ga14.201-2
Followup-For: Bug #765109

Dear Maintainer,

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

   * What led up to the situation?
New computer, installed fresh debian 7, installed fglrx-driver.
Graphics card not supported (R9 270X). Upgraded to jessie.
ran ati-config --initial. Black screen on startup. 
Tried a posted method of adding "File" field to xorg.conf.
Still Black screen. I can swap to terminal (ctrl-alt-f1).

-- Package-specific info:
Full fglrx package list:
ii  fglrx-atievent 1:14.9+ga14. amd64events daemon for the non-free AT
ii  fglrx-driver   1:14.9+ga14. amd64non-free ATI/AMD RadeonHD display
ii  fglrx-modules- 1:14.9+ga14. amd64dkms module source for the non-fr
ii  libfglrx:amd64 1:14.9+ga14. amd64non-free ATI/AMD RadeonHD display
ii  libfglrx-amdxv 1:14.9+ga14. amd64AMD XvBA (X-Video Bitstream Accel
ii  libgl1-fglrx-g 1:14.9+ga14. amd64proprietary libGL for the non-fre

VGA-compatible devices on PCI bus:
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Curacao XT [Radeon R9 270X] [1002:6810] (prog-if 00 [VGA controller])
Subsystem: XFX Pine Group Inc. Device [1682:9275]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: fglrx_pci


DRM and fglrx Informations from dmesg:
[0.00] AGP: No AGP bridge found
[0.00] AGP: Checking aperture...
[0.00] AGP: No AGP bridge found
[0.528841] Linux agpgart interface v0.103
[1.719181] fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, 
Starnberg, GERMANY' taints kernel.
[1.742019] <6>[fglrx] Maximum main memory to use for locked dma buffers: 
7723 MBytes.
[1.742097] <6>[fglrx]   vendor: 1002 device: 6810 count: 1
[1.742232] <6>[fglrx] ioport: bar 4, base 0xe000, size: 0x100
[1.742364] <6>[fglrx] Kernel PAT support is enabled
[1.742374] <6>[fglrx] module loaded - fglrx 14.20.7 [Sep  2 2014] with 1 
minors
[4.573759] fglrx_pci :01:00.0: irq 49 for MSI/MSI-X
[4.574139] <6>[fglrx] Firegl kernel thread PID: 1038
[4.574270] <6>[fglrx] Firegl kernel thread PID: 1039
[4.574388] <6>[fglrx] Firegl kernel thread PID: 1040
[4.574460] <6>[fglrx] IRQ 49 Enabled
[4.582095] <6>[fglrx] Reserved FB block: Shared offset:0, size:100 
[4.582097] <6>[fglrx] Reserved FB block: Unshared offset:f838000, size:4000 
[4.582098] <6>[fglrx] Reserved FB block: Unshared offset:f83c000, 
size:4c4000 
[4.582099] <6>[fglrx] Reserved FB block: Unshared offset:7ffef000, 
size:11000 

Xorg X server configuration file status:
-rw-r--r-- 1 root root 804 Dec  6 10:24 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
Section "Files"
ModulePath "/usr/lib/fglrx"
ModulePath "/usr/lib/xorg/modules"
ModulePath "/usr/lib/dri"
EndSection

Section "ServerLayout"
Identifier "aticonfig Layout"
Screen  0  "aticonfig-Screen[0]-0" 0 0
EndSection

Section "Module"
EndSection

Section "Monitor"
Identifier   "aticonfig-Monitor[0]-0"
Option  "VendorName" "ATI Proprietary Driver"
Option  "ModelName" "Generic Autodetecting Monitor"
Option  "DPMS" "true"
EndSection

Section "Device"
Identifier  "aticonfig-Device[0]-0"
Driver  "fglrx"
BusID   "PCI:1:0:0"
EndSection

Section "Screen"
Identifier "aticonfig-Screen[0]-0"
Device "aticonfig-Device[0]-0"
Monitor"aticonfig-Monitor[0]-0"
DefaultDepth 24
SubSection "Display"
Viewport   0 0
Depth 24
EndSubSection
EndSection



Xorg X server log files on system:
-rw-r--r-- 1 root root 21054 Dec  6 10:09 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 21054 Dec  6 10:09 /var/log/Xorg.2.log
-rw-r--r-- 1 root root 21054 Dec  6 10:09 /var/log/Xorg.3.log
-rw-r--r-- 1 root root 21054 Dec  6 10:09 /var/log/Xorg.4.log
-rw-r--r-- 1 root root 21054 Dec  6 10:09 /var/log/Xorg.5.log
-rw-r--r-- 1 root root 46544 Dec  6 10:26 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file
/var/log/Xorg.0.log:
[  2155.959] 
X.Org X Server 1.16.1.901 (1.16.2 RC 1)
Release Date: 2014-11-02
[  2155.959] X Protocol Version 11, Revision 0
[  2155.959] Build Operating System: Linux 3.2.0-4-amd64 x86_64 Debian
[  2155.959] Current Operating System: Linux evanpc 3.16.0-4-amd64 #1 SMP 
Debian 3.16.7-2 (2014-11-06) x86_64
[  2155.960] Kernel command line: BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 
root=/dev/mapper/evanpc-root ro initrd=/install/initrd.gz quiet
[  2155.960] Build Date: 03 November 2014  09:44:08PM
[  2155.960] xorg-server 2:1.16.1.901-1 (http://www.debian.org/support) 
[  2155.960] Current version of pixman: 0.32.6
[  2155.960]Before rep

Bug#760607: dvtm: Current version (0.6) is years out of date with upstream

[Evan Hanson]

Package: dvtm
Severity: wishlist

The upstream version for this software is currently 0.12, released
earlier this year, whereas the currently packaged version is 0.6,
released mid-2010. Versions >= 0.7 include several features I want to
use, and the upstream developer has expressed a desire to see this on
the project ML[1] and privately, as well.

[1]: http://lists.suckless.org/dev/1407/22826.html

Evan

-- System Information:
Debian Release: 7.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages dvtm depends on:
ii  libc6 2.13-38+deb7u3
ii  libncursesw5  5.9-10

Versions of packages dvtm recommends:
ii  ncurses-term  5.9-10

dvtm suggests no packages.


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

Bug#755577: abduco: should recommend dvtm

[Evan Hanson]

On 2014-07-22  9:21, Jonas Smedegaard wrote:
> According to the online manual, abduco starts dvtm as default command.
> Therefore I believe the package should recommend (or at least suggest)
> that other package.

Indeed, this makes sense to me. I'll update with a Recommends shortly.

Evan


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

Bug#755122: ITP: abduco -- abduco provides session management, allowing programs to be run independently from their controlling terminals

[Evan Hanson]

On 2014-07-18 20:31, Konstantin Khomoutov wrote:
> Consider removing the program's name from its short description:

Agreed.

> [...]
> 
> If this paragraph is really a part of the long description please
> consider removing all that fuss about legacy code, quality of
> implementation and licensing issues: the user is supposed to know
> nothing about dtach so the description should probably not be
> comparative.  Boasting seems inappropriate as well.

Indeed. This was the closest thing to a long description I could find
upstream, so included it in the report, but I'll omit it from the
packaging.

Evan


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

Bug#755122: ITP: abduco -- abduco provides session management, allowing programs to be run independently from their controlling terminals

[Evan Hanson]

Package: wnpp
Severity: wishlist
Owner: Evan Hanson 

* Package name: abduco
  Version : 0.1
  Upstream Author : Marc Andre Tanner 
* URL : http://www.brain-dump.org/projects/abduco/
* License : ISC
  Programming Lang: C
  Description : abduco provides session management, allowing programs to be 
run independently from their controlling terminals

That is, programs can be detached - run in the background - and then
later reattached. Together with dvtm it provides a simpler and cleaner
alternative to tmux or screen.

abduco is in many ways very similar to dtach but is actively maintained,
contains no legacy code, provides a few additional features, has a
cleaner, more robust implementation and is distributed under the ISC
license.

I use this program and find it a nice alternative to the others
mentioned. I will maintain it, but will need a sponsor.


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

Bug#748714: Unpaper: allow negative border margins, add sheet-size option

[Evan Thompson]

Package: gscan2pdf
Version: 1.2.5-1
Severity: wishlist
Tags: patch

In the Unpaper module, please (a) allow for negative border margins to be set
and (b) add support for the '--sheet-size' option.  The combination of these
two features allows for completely "clean" (no residual borders, pages properly
sized and aligned) output from my ScanSnap S1300 from within gscan2pdf.

The attached patch (poorly) implements the above request.



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

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

Versions of packages gscan2pdf depends on:
ii  imagemagick  8:6.7.7.10+dfsg-2
ii  libconfig-general-perl   2.56-1
ii  libgoo-canvas-perl   0.06-2
ii  libgtk2-ex-simple-list-perl  0.50-2
ii  libgtk2-imageview-perl   0.05-2
ii  libhtml-parser-perl  3.71-1+b1
ii  liblist-moreutils-perl   0.33-2
ii  liblocale-gettext-perl   1.05-8
ii  liblog-log4perl-perl 1.43-1
ii  libpdf-api2-perl 2.021-1
ii  libproc-processtable-perl0.50-1
ii  libreadonly-perl 1.04-1
ii  librsvg2-common  2.40.2-1
ii  libsane-perl 0.05-2+b1
ii  libset-intspan-perl  1.19-1
ii  libtiff-tools4.0.3-8
ii  libtry-tiny-perl 0.22-1
ii  perlmagick   8:6.7.7.10+dfsg-2
ii  sane-utils   1.0.24-1.1+b1

Versions of packages gscan2pdf recommends:
ii  djvulibre-bin  3.5.25.4-4
ii  libgtk2-ex-podviewer-perl  0.18-1
ii  sane   1.0.14-9
ii  tesseract-ocr  3.03.03-1
ii  unpaper0.4.2-1
ii  xdg-utils  1.1.0~rc1+git20111210-7.1

gscan2pdf suggests no packages.
--- Unpaper.pm.diverted	2014-05-17 06:52:22.0 -0500
+++ Unpaper.pm	2014-05-19 15:43:33.251895510 -0500
@@ -59,6 +59,25 @@
},
default => 'single',
   },
+  'sheet-size' => {
+   type=> 'ComboBox',
+   string  => $d->get('Sheet size'),
+   options => {
+none => {
+ string => $d->get('(none)'),
+ tooltip => $d->get(''),
+},
+letter => {
+ string => $d->get('Letter'),
+ tooltip => $d->get(''),
+},
+legal => {
+ string  => $d->get('Legal'),
+ tooltip => $d->get(''),
+},
+   },
+   default => 'none',
+  },
   'output-pages' => {
type=> 'SpinButton',
string  => $d->get('# Output pages'),
@@ -184,10 +203,11 @@
  tooltip => $d->get(
 'Vertical distance to keep from the sheet edge when aligning a border area.'
  ),
- min   => 0,
- max   => 1000,
- step  => 1,
- order => 0,
+ min => -1000,
+ max => 1000,
+ step=> 1,
+ order   => 0,
+ default => 0,
 },
 horizontal => {
  type=> 'SpinButton',
@@ -195,10 +215,11 @@
  tooltip => $d->get(
 'Horizontal distance to keep from the sheet edge when aligning a border area.'
  ),
- min   => 0,
- max   => 1000,
- step  => 1,
- order => 1,
+ min => -1000,
+ max => 1000,
+ step=> 1,
+ order   => 1,
+ default => 0,
 },
},
   },
@@ -234,6 +255,7 @@
 
  # Layout ComboBox
  my $combobl  = $self->add_widget( $vbox, $options, 'layout' );
+ my $combobs  = $self->add_widget( $vbox, $options, 'sheet-size' );
  my $outpages = $self->add_widget( $vbox, $options, 'output-pages' );
  $combobl->signal_connect(
   changed => sub {
@@ -541,7 +563,9 @@
   }
   else {
if ( defined $default->{$option} ) {
-push @items, "--$option $default->{$option}";
+if ( not $default->{$option} eq 'none' ) {
+ push @items, "--$option $default->{$option}";
+}
}
   }
  }

Bug#747578: wireshark: Uses gcrypt functions without explicit gcrypt build-dependency

[Evan Huus]

If I recall correctly, Wireshark cannot currently be upgraded to GnuTLS v3
for license reasons; it is or creates a dependency on GPL3+ code while
Wireshark needs to remain GPL2+.

Evan


On Sat, May 10, 2014 at 3:10 AM, Andreas Metzler  wrote:

> Package: wireshark
> Version: 1.10.7-1
> Severity: normal
> User: ametz...@debian.org
> Usertags: gnutls3
>
> Hello,
>
> This package uses gcrypt directly (not only as an indirect dependency
> via gnutls) but does not build-depend on it.
>
> In the long turn it would be better to switch from gcrypt to gnutls'
> crypto API, to limit external depencies. (GnuTLS v3 uses nettle
> instead of gcrypt.)
>
> FWIW I have done a successful testbuild of wireshark against
> libgnutls28-dev (and even libgcrypt20-dev). Please consider upgrading.
>
> cu Andreas
> --
> `What a good friend you are to him, Dr. Maturin. His other friends are
> so grateful to you.'
> `I sew his ears on from time to time, sure'
>
>

Bug#731193: terminator: dragging terminator window to the top of a KDE desktop screen fails to maximize it properly

[Evan Hansen]

Package: terminator
Version: 0.97-2
Severity: normal

Dear Maintainer,

Recently updated terminator from debian testing.  Since the update,
dragging the terminator window to the top of a KDE desktop screen fails
to maximize the window properly.  Sometimes the window partially fills
one screen or partially fills two screens when dual displays are used.  
However, the maximize button on the window functions properly and the
window maximizes on one screen.

This behavior is exhibited only by terminator.  Other updated applications
do not exhibt this behavior.

Regards,
Evan


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

Kernel: Linux 3.11-2-686-pae (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

Versions of packages terminator depends on:
ii  gconf2  3.2.6-1
ii  python-dbus 1.2.0-2+b1
ii  python-gobject  3.8.2-1
ii  python-gtk2 2.24.0-3+b1
ii  python-vte  1:0.28.2-5
pn  python:any  

Versions of packages terminator recommends:
ii  python-gnome2 2.28.1+dfsg-1
ii  python-keybinder  0.3.0-2
ii  python-notify 0.1.1-3
ii  xdg-utils 1.1.0~rc1+git20111210-7

terminator suggests no packages.

-- no debconf information


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

Bug#720527: libfreetype6: Newer libfreetype missing the symbol FT_Stream_GetShort.

[Joseph Evan Spafford]

Package: libfreetype6
Version: 2.4.9-1.1
Severity: normal

We have some applications for which we do not have source, 
which are affected by a regression within libfreetype6. Upon trying to run 
these on wheezy though the program gives an error about an undefined symbol and 
exits.  

For example --

sedit.exe: undefined symbol: FT_Stream_GetShort

In squeeze (with libfreetype6 at debian version 2.4.2-2.1+squeeze4), the
application runs and displays itself.

objdump -T shows that the FT_Stream_GetShort is on the squeeze box and
absent on wheezy's version, If you like I can give to the respective
output from it.
ldd demonstrates that the program has no missing dynamic libraries. 


Tracing things back it seems that the symbols name was changed to
FT_Stream_GetUShort in the commit 21b1a0de7c052dcd25348c4e3597c8a631108f61
(based on freetype2's repository at 
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/)
As I understand, the major number of the library hasn't changed. Resulting
in this breakage.

-- System Information:
Debian Release: 7.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-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/bash


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

Bug#711020: reptyr: New upstream release: 0.4

[Evan Broder]

Hey Richard -
  Thanks a lot for the bug! I unfortunately don't have the excuse of
unawareness to hide behind - I've been aware of the release but just
not grabbed the time to prepare an upload.

There's a commit on reptyr HEAD that I think is worth grabbing (it
makes it handle the situation of child processes much better), and
Nelson just cut a new release, so I'm going to pull that in. Hopefully
I'll have a new binary staged by the end of the day.

I'll work on uploading in a more timely manner going forward, but I
also put myself on http://wiki.debian.org/LowThresholdNmu for roughly
this purpose - I don't have any issue with DDs helping to improve my
packages (well, package). I'll plan to update reptyr's README.Debian
to be more clear about that.

Thanks again for the ping. Let me know if there's anything I can do to
help with retty (e.g. does it make sense for the transitional package
to live in reptyr? I'm not deeply familiar with these sorts of things)

- Evan

On Mon, Jun 3, 2013 at 7:07 PM, Richard Hartmann
 wrote:
> Package: reptyr
> Version: 0.3-2
> Severity: wishlist
>
> Hi Evan,
>
> there's been a new release of reptyr some time ago, please see
>
> https://github.com/nelhage/reptyr/tags
>
> If you need/want help with packaging or maintaining, please let me know.
> I will most likely deprecate retty and replace it with a migration
> package to reptyr so I have substantial interest in this package being
> up to date.
>
>
> Thanks,
> Richard
>
>
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: i386 (i686)
>
> Kernel: Linux 3.7-trunk-686-pae (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
>
> Versions of packages reptyr depends on:
> ii  libc6  2.17-3
>
> reptyr recommends no packages.
>
> reptyr suggests no packages.
>
> -- no debconf information


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

Bug#708651: update-manager-gnome: apt-get update 404 not found

[Evan Harvey]

Package: update-manager-gnome
Version: 0.200.5-1
Severity: normal

Dear maintainer,

I use linux-image-3.2.0-0.bpo because my XPS L502X hangs when booting into 2.6.
I am not exactly sure why but it seems to have something to do with acpi.  I
have two machines running Debian 6.0.7 squeeze at home one is a desktop.  Both
of my machines periodically and inconsistently report errors when trying to run
"sudo apt-get update".  The errors consist of E: 404 not found or E: Invalid
signature.  I have run sudo apt-key update and apt informs me that the keys
have been processed and unchanged 7/7 which I have confirmed multiple times.
The 404 not found message only occurs for the back-port repositories but
the kernel that I am using is back-ported!  The 404 not found will also report
different IP addresses which it is unable to find.  For example:

Err http://ftp.us.debian.org squeeze-backports-sloppy/main amd64 Packages
  404  Not Found [IP: 64.50.236.52 80]
Err http://ftp.us.debian.org squeeze-backports-sloppy/contrib amd64 Packages
  404  Not Found [IP: 64.50.236.52 80]
Err http://ftp.us.debian.org squeeze-backports-sloppy/non-free amd64 Packages
  404  Not Found [IP: 64.50.236.52 80]
W: Failed to fetch http://ftp.us.debian.org/debian-backports/dists/squeeze-
backports-sloppy/main/binary-amd64/Packages.gz  404  Not Found [IP:
64.50.236.52 80]

W: Failed to fetch http://ftp.us.debian.org/debian-backports/dists/squeeze-
backports-sloppy/contrib/binary-amd64/Packages.gz  404  Not Found [IP:
64.50.236.52 80]

W: Failed to fetch http://ftp.us.debian.org/debian-backports/dists/squeeze-
backports-sloppy/non-free/binary-amd64/Packages.gz  404  Not Found [IP:
64.50.236.52 80]

E: Some index files failed to download, they have been ignored, or old ones
used instead.

Dear maintainer,

Sometimes this IP address begins with 128 instead of 64.  Is this normal? This
morning after running sudo apt-get update I received the above error messages
and some others.  I ran sudo apt-key update and then apt-get update again and
it seemed to work
fine. However, then I ran sudo apt-get upgrade and I was informed that all my
packages are up-to-date.  About 5 minutes later I was notified that there are 4
updates available for the system.  Maybe they were just released this morning.
If I can provide and additional information please let me know.  I have tried
to attach my syslog but I cannot.  I may not have permissions through report-
bug.



-- System Information:
Debian Release: 6.0.7
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-0.bpo.4-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

Versions of packages update-manager-gnome depends on:
ii  gconf22.28.1-6   GNOME configuration database syste
ii  gksu  2.0.2-5graphical frontend to su
ii  python2.6.6-3+squeeze7   interactive high-level object-orie
ii  python-dbus   0.83.1-1   simple interprocess messaging syst
ii  python-gconf  2.28.1-1   Python bindings for the GConf conf
ii  python-gobject2.21.4+is.2.21.3-1 Python bindings for the GObject li
ii  python-gtk2   2.17.0-4   Python bindings for the GTK+ widge
ii  python-support1.0.10 automated rebuilding support for P
ii  python-vte1:0.24.3-4 Python bindings for the VTE widget
ii  update-manager-core   0.200.5-1  APT update manager core functional

update-manager-gnome recommends no packages.

Versions of packages update-manager-gnome suggests:
ii  software-properties-gtk0.60.debian-3 manage the repositories that you i
ii  update-notifier0.99.3debian8 Daemon which notifies about packag


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

Bug#491723: StatusNet package upload?

[Evan Prodromou]

Daniel,

There's a package here:

http://people.debian.org/~costela/packages/

I'm not sure if it's appropriate to give the package to an XMPP group 
since the software is not primarily XMPP-based.


-Evan

On 13-01-28 03:07 PM, Daniel Pocock wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



Hi Andreas,

Can you please let me know about the status of the package - are you
still ITP?  Or would you prefer somebody else to take over?  Or is
there some blocking issue?

I'm actually doing a joint session with Evan (StatusNet
founder/upstream) at FOSDEM this weekend[1] and it would be helpful to
upload the package into experimental or sid if it is ready (the
previous posts suggest only the debian/copyright file needs to be
finished) - and I will be happy to discuss with Evan in person if
changes are needed upstream to make this package happen.

I'm also wondering if anybody would object to putting this package
under pkg-xmpp-maintainers[2] as a place for group collaboration on
the package?

Regards,

Daniel


1. https://fosdem.org/2013/schedule/event/free_open_secure_communications/

2.
http://qa.debian.org/developer.php?login=pkg-xmpp-de...@lists.alioth.debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJRBtp1AAoJEOm1uwJp1aqDFgEQAJYKot5SlrZZSkrChsuTaE0j
Iidt4DnMTaUNeCfjCLkrBk2uR8i24UnFP+IJ4Yp7SmsJ/3TwruIB77oeb+QS6X5j
9WgrF1m9q0gvchUYkweiPQOc2wQb7gx4UXvmhrnrH9suqKzHEe4ogWg+g8wIPece
iMQSxRl1WYI8/9zOlYY77lsXstgWr0N7phYDrE+T6LIqL/sxrx04Hn5ltEKSISEt
MPHir9SIZLyJp2qLo+Xx4bLFwQuGC3i7kfMlJBa8R5orUIaG+IiN1aorWJSSjk8I
IHwcWS5+aTEooyxFNnZrBc/J3oWSGgV71tG3r2b2QZlsvnophkbVLFVwaZMXAFxa
n+n0230O8RwiHMn5qt9iZYMKB8HReL7qz+k6vFZXCgEQS7FZTP8V5DudLbbAMDZL
hBXx/lNNdlaw7VLsI9CZa8ClS7x3cINpBegL1DAoEqB0uR/Y2Z8AX6H7FMMLTgMj
smzKBFSo7z/+XhMrCZPQQc3+4MRS6j1w8bJKLv2DNHoPtgM6yo+DLyfMGxmSJt+d
RnnDP8NAZ4XLeec/8h21BXKdywhca6VC/MD1mmmh47pWQfXem4OJfSilkWM3Yd8E
X/Epfp31hBdrQPSjcwWzIsFpsxEzhx9lM9U/Xc0UuAqHMW16f3Nvj1gEFxwJ+UOr
XDFj8a+mRZ4t0ukT1xm/
=ytA9
-END PGP SIGNATURE-





smime.p7s
Description: S/MIME Cryptographic Signature

Bug#694911: gnome-screensaver: Dims the screen on all the tty's

[evan]

Package: gnome-screensaver
Version: 2.30.0-2squeeze1
Severity: minor

When locking the computer and the display is fading to the screensaver if the 
user switches to a different tty during the fading process all of the tty's 
have the same screen brightness as the GUI's tty.  Normal screen brightness on 
all tty's is restored by switching back to the GUI's tty after the fading 
process has been completed.  Thank you for providing and maintaining debian. 

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

Kernel: Linux 3.2.0-0.bpo.3-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

Versions of packages gnome-screensaver depends on:
ii  dbus-x11  1.2.24-4+squeeze1  simple interprocess messaging syst
ii  gconf22.28.1-6   GNOME configuration database syste
ii  gnome-icon-theme  2.30.3-2   GNOME Desktop icon theme
ii  gnome-session-bin 2.30.2-3   The GNOME Session Manager - Minima
ii  libc6 2.11.3-4   Embedded GNU C Library: Shared lib
ii  libcairo2 1.8.10-6   The Cairo 2D vector graphics libra
ii  libdbus-1-3   1.2.24-4+squeeze1  simple interprocess messaging syst
ii  libdbus-glib-1-2  0.88-2.1   simple interprocess messaging syst
ii  libgconf2-4   2.28.1-6   GNOME configuration database syste
ii  libgl1-mesa-glx [libg 7.10.3-4~bpo60+1   free implementation of the OpenGL 
ii  libglib2.0-0  2.24.2-1   The GLib library of C routines
ii  libgnome-desktop-2-17 2.30.2-2   Utility library for loading .deskt
ii  libgnome-menu22.30.3-1   an implementation of the freedeskt
ii  libgnomekbd4  2.30.2-2   GNOME library to manage keyboard c
ii  libgtk2.0-0   2.20.1-2   The GTK+ graphical user interface 
ii  libpam0g  1.1.1-6.1+squeeze1 Pluggable Authentication Modules l
ii  libpango1.0-0 1.28.3-1+squeeze2  Layout and rendering of internatio
ii  libx11-6  2:1.3.3-4  X11 client-side library
ii  libxext6  2:1.1.2-1  X11 miscellaneous extension librar
ii  libxklavier16 5.0-2  X Keyboard Extension high-level AP
ii  libxxf86vm1   1:1.1.0-2  X11 XFree86 video mode extension l

Versions of packages gnome-screensaver recommends:
ii  gnome-power-manager   2.32.0-2   power management tool for the GNOM
ii  libpam-gnome-keyring  2.30.3-5   PAM module to unlock the GNOME key

Versions of packages gnome-screensaver suggests:
pn  rss-glx(no description available)
ii  xscreensaver-data 5.11-1+b1  data files to be shared among scre

-- no debconf information


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

Bug#694402: gnome-system-monitor: does not close process

[evan]

Package: gnome-system-monitor
Version: 2.28.1-1
Severity: normal

When the user opens the system monitor all the features work correctly but the 
process will not close by using ctrl+q alt+f4 or simply clicking the "close 
window" button on the top right hand corner of the pane.  The only was the user 
can close the system monitor is by opening a terminal and using the kill 
command.
I have tried to provide debconf information but I am not sure that I have done 
with correctly.  Any suggestions for future bug reports? Thank you for 
providing and maintaining debian.

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

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

Versions of packages gnome-system-monitor depends on:
ii  gconf2 2.28.1-6  GNOME configuration database syste
ii  libc6  2.11.3-4  Embedded GNU C Library: Shared lib
ii  libcairo2  1.8.10-6  The Cairo 2D vector graphics libra
ii  libgcc11:4.4.5-8 GCC support library
ii  libgconf2-42.28.1-6  GNOME configuration database syste
ii  libglib2.0-0   2.24.2-1  The GLib library of C routines
ii  libglibmm-2.4-1c2a 2.24.2-1  C++ wrapper for the GLib toolkit (
ii  libgtk2.0-02.20.1-2  The GTK+ graphical user interface 
ii  libgtkmm-2.4-1c2a  1:2.20.3-1C++ wrappers for GTK+ (shared libr
ii  libgtop2-7 2.28.1-1  gtop system monitoring library (sh
ii  librsvg2-2 2.26.3-1  SAX-based renderer library for SVG
ii  libsigc++-2.0-0c2a 2.2.4.2-1 type-safe Signal Framework for C++
ii  libstdc++6 4.4.5-8   The GNU Standard C++ Library v3
ii  libwnck22  2.30.4-2  Window Navigator Construction Kit 
ii  libxml22.7.8.dfsg-2+squeeze5 GNOME XML library

Versions of packages gnome-system-monitor recommends:
ii  gvfs   1.6.4-3   userspace virtual filesystem - ser
ii  libgksu2-0 2.0.13~pre1-3 library providing su and sudo func

gnome-system-monitor suggests no packages.

-- no debconf information
:~$ DEBCONF_SYSMO=evan debconf gnome-system-monitor
debconf: DbDriver "passwords" warning: could not open 
/var/cache/debconf/passwords.dat: Permission denied

** (gnome-system-monitor:4364): WARNING **: SELinux was found but is not 
enabled.


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

Bug#629524: gnome-power-manager: Two batteries displayed after resume from suspend

[evan]

Package: gnome-power-manager
Version: 2.32.0-2
Severity: normal

When I resume the computer from suspend two battery icons are showing. This 
problem was fixed a few weeks ago and I have reported it before. Thank you for 
providing and maintaining debian. 

-- Package-specific info:
Distro version:   6.0.6
Kernel version:   3.2.0-0.bpo.3-amd64
g-p-m version:2.32.0
HAL version:  0.5.14
System manufacturer:  missing
System version:   missing
System product:   missing
AC adapter present:   yes
Battery present:  yes
Laptop panel present: yes
CPU scaling present:  yes
Battery Information:
  battery.charge_level.current = 40226  (0x9d22)  (int)
  battery.charge_level.design = 57720  (0xe178)  (int)
  battery.charge_level.last_full = 48207  (0xbc4f)  (int)
  battery.charge_level.percentage = 83  (0x53)  (int)
  battery.charge_level.rate = 29870  (0x74ae)  (int)
  battery.is_rechargeable = true  (bool)
  battery.model = 'Dell'  (string)
  battery.present = true  (bool)
  battery.rechargeable.is_charging = false  (bool)
  battery.rechargeable.is_discharging = true  (bool)
  battery.remaining_time = 4848  (0x12f0)  (int)
  battery.reporting.current = 3624  (0xe28)  (int)
  battery.reporting.design = 5200  (0x1450)  (int)
  battery.reporting.last_full = 4343  (0x10f7)  (int)
  battery.reporting.rate = 2691  (0xa83)  (int)
  battery.reporting.technology = 'Li-ion'  (string)
  battery.reporting.unit = 'mAh'  (string)
  battery.serial = '2326'  (string)
  battery.technology = 'lithium-ion'  (string)
  battery.type = 'primary'  (string)
  battery.vendor = 'SANYO'  (string)
  battery.voltage.current = 11638  (0x2d76)  (int)
  battery.voltage.design = 11100  (0x2b5c)  (int)
  battery.voltage.unit = 'mV'  (string)
UPower data:
Device: /org/freedesktop/UPower/devices/line_power_ADP0
  native-path:  
/sys/devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/ADP0
  power supply: yes
  updated:  Sat Nov 24 15:45:59 2012 (599 seconds ago)
  has history:  no
  has statistics:   no
  line-power
online: no

Device: /org/freedesktop/UPower/devices/battery_BAT0
  native-path:  
/sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0
  vendor:   SANYO
  model:Dell
  serial:   2326
  power supply: yes
  updated:  Sat Nov 24 15:55:35 2012 (23 seconds ago)
  has history:  yes
  has statistics:   yes
  battery
present: yes
rechargeable:yes
state:   discharging
energy:  40.2708 Wh
energy-empty:0 Wh
energy-full: 48.2073 Wh
energy-full-design:  57.72 Wh
energy-rate: 29.9256 W
voltage: 11.665 V
time to empty:   1.3 hours
percentage:  83.5367%
capacity:83.5192%
technology:  lithium-ion
  History (charge):
1353797735  83.537  discharging
1353797705  84.181  discharging
1353797675  84.872  discharging
1353797645  85.310  discharging
  History (rate):
1353797735  29.926  discharging
1353797705  29.548  discharging
1353797675  29.926  discharging
1353797645  29.903  discharging

Daemon:
  daemon-version:  0.9.5
  can-suspend: yes
  can-hibernateyes
  on-battery:  yes
  on-low-battery:  no
  lid-is-closed:   no
  lid-is-present:   yes
GNOME Power Manager Process Information:
evan  2258  0.0  0.1 218072 10984 ?S15:44   0:00  
\_ gnome-power-manager
evan  2999  0.0  0.0   4004   564 pts/0S+   15:55   0:00  \_ sh 
-c LC_ALL=C /usr/share/reportbug/handle_bugscript  
'/usr/share/bug/gnome-power-manager/s
evan  3000  0.0  0.0   9148  1132 pts/0S+   15:55   0:00  
\_ /bin/bash /usr/share/reportbug/handle_bugscript 
/usr/share/bug/gnome-power-manager/scri
HAL Process Information:
112   1885  0.0  0.0  45188  5556 ?Ssl  15:44   0:00 /usr/sbin/hald
root  1889  0.0  0.0  4  1392 ?S15:44   0:00  \_ hald-runner
root  1961  0.0  0.0  24340  1164 ?S15:44   0:00  \_ 
hald-addon-input: Listening on /dev/input/event6 /dev/input/event15 
/dev/input/event0 /dev/inpu
root  2036  0.0  0.0  24332  1164 ?S15:44   0:00  \_ 
/usr/lib/hal/hald-addon-generic-backlight
root  2037  0.0  0.0  24332  1168 ?S15:44   0:00  \_ 
/usr/lib/hal/hald-addon-generic-backlight
root  2044  0.0  0.0  24332  1164 ?S15:44   0:00  \_ 
/usr/lib/hal/hald-addon-rfkill-killswitch
root  2064  0.0  0.0  24336  1172 ?S15:44   0:00  \_ 
hald-addon-storage: polling /dev/sdb (every 2 sec)
root  2072  0.0  0.0  24336  1408 ?S15:44   0:00  \_ 
hald-addon-storage: polling /dev/sr0 (every 2 sec)
root  2073  0.0  0.0  24348  11

Bug#691549: udev: logitec mouse is not being detected during every boot

[evan]

Package: udev
Version: 164-3
Severity: normal

Hello,
When I boot up my debian OS the wireless mouse is sometimes not detected.  When 
this occures sometimes I can disconnet the device and reconnect it several 
times and
the system detects the mouse again.  The usb port seems to be working fine when 
this occures and this does not happen with my wired logitec keyboard.  
Sometimes I must
reboot the OS in order to use the mouse.  This did not happen at all when using 
the stable linux kernel. It seems to have begun after installing xfce4 
alongside gnome
at which point libfam0 was removed.  It may be from using backports.  Thank you 
for your time and for maintaining and providing debian GNU/Linux.

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

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

Versions of packages udev depends on:
ii  debconf [debconf-2.0]   1.5.36.1 Debian configuration management sy
ii  libc6   2.11.3-4 Embedded GNU C Library: Shared lib
ii  libselinux1 2.0.96-1 SELinux runtime shared libraries
ii  libudev0164-3libudev shared library
ii  libusb-0.1-42:0.1.12-16  userspace USB programming library
ii  lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip
ii  util-linux  2.17.2-9 Miscellaneous system utilities

Versions of packages udev recommends:
ii  pciutils  1:3.1.7-6  Linux PCI Utilities
ii  usbutils  0.87-5squeeze1 Linux USB utilities

udev suggests no packages.

-- debconf information:
  udev/new_kernel_needed: false
  udev/title/upgrade:
  udev/reboot_needed:
  udev/sysfs_deprecated_incompatibility:


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

Bug#689732: closed by Holger Levsen (Re: Bug#689732: base: waking up from suspend mode fails to reconnect devices and display)

[Evan Harvey]

This bug was reported through reportbug. I will report it again.

Thank you.

On Sat, Oct 6, 2012 at 1:45 AM, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the base package:
>
> #689732: base: waking up from suspend mode fails to reconnect devices and
> display
>
> It has been closed by Holger Levsen .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Holger Levsen <
> hol...@layer-acht.org> by
> replying to this email.
>
>
> --
> 689732: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689732
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Forwarded message --
> From: Holger Levsen 
> To: 689732-d...@bugs.debian.org
> Cc:
> Date: Sat, 6 Oct 2012 09:41:00 +0200
> Subject: Re: Bug#689732: base: waking up from suspend mode fails to
> reconnect devices and display
> On Freitag, 5. Oktober 2012, evan wrote:
> > When the user wakes the computer up from suspend mode the screen, mouse
> and
> > keyboard do not function.  The user is unable to obtain any error
> messages.
> > I must reboot the computer by holding down the power button.  This
> happens
> > everytime the pc goes into suspend mode. If instructed I could send the
> > syslog file or other helpful log files. Thank you for providing and
> > maintaining debian.
>
> please use "reportbug" and re-submit the bug against "src:linux", thanks.
>
> -- Forwarded message --
> From: evan 
> To: Debian Bug Tracking System 
> Cc:
> Date: Fri, 05 Oct 2012 11:03:37 -0600
> Subject: base: waking up from suspend mode fails to reconnect devices and
> display
> Package: base
> Severity: normal
>
>
> When the user wakes the computer up from suspend mode the screen, mouse and
> keyboard do not function.  The user is unable to obtain any error messages.
> I must reboot the computer by holding down the power button.  This happens
> everytime the pc goes into suspend mode. If instructed I could send the
> syslog
> file or other helpful log files. Thank you for providing and maintaining
> debian.
>
> -- System Information:
> Debian Release: 6.0.6
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 2.6.32-5-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
>
>

Bug#689746: base: GUI switches from tty7, tty8 and tty9

[Evan Harvey]

Holger, It is the Gnome gui. With X Windows Manager.

On Fri, Oct 5, 2012 at 2:35 PM, evan  wrote:

> Package: base
> Severity: minor
>
>
> After logging into the GUI on tty7 and logging out the GUI switches to
> tty8.
> After logging into the GUI on tty8 and logging out the GUI switches to
> tty9.
> After logging into the GUI on tty9 and logging out the GUI switches to
> tty8.
> The GUI switches from tty8 to tty9 and vise versa after logging out.
> Thank you for providing and maintaining debian.
>
> -- System Information:
> Debian Release: 6.0.6
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 2.6.32-5-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
>

Bug#689746: base: GUI switches from tty7, tty8 and tty9

[evan]

Package: base
Severity: minor


After logging into the GUI on tty7 and logging out the GUI switches to tty8.
After logging into the GUI on tty8 and logging out the GUI switches to tty9.
After logging into the GUI on tty9 and logging out the GUI switches to tty8.
The GUI switches from tty8 to tty9 and vise versa after logging out.
Thank you for providing and maintaining debian.

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

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


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

Bug#689732: base: waking up from suspend mode fails to reconnect devices and display

[evan]

Package: base
Severity: normal


When the user wakes the computer up from suspend mode the screen, mouse and
keyboard do not function.  The user is unable to obtain any error messages.
I must reboot the computer by holding down the power button.  This happens
everytime the pc goes into suspend mode. If instructed I could send the syslog 
file or other helpful log files. Thank you for providing and maintaining debian.

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

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


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

Bug#689672: base: blank non-responsive screen after waking system up from suspend

[evan]

Package: base
Severity: normal


When the user wakes the system up from suspend the computer screen is blank.
As a novice to debian I did not know how to shutdown the computer properly.
I attempted to press the power button + enter to shut the system down properly
after waiting a few minutes the computer did not shutdown. I tried ctrl+alt+
delete+enter and after a few minutes the system did not shutdown. I then held 
the power button down in order to turn the system off. When I rebooted the sys-
tem and attempted to boot the boot loader hung on "waiting for /dev to be
fully populated". I then shut the system down again by holding down the power
button. I booted into recovery mode this time and the boot loader hung on the
ACPI section -- sorry next time I will write down the message from the boot
loader. I shut the system down again by holding the power button down. I
loaded into recovery mode again and the debian system loaded sucessfully. I am
not sure how to provide a backtrace in debian but if instructed via email I 
would be happy to provide any additional useful information.  Thank you for 
providing and maintianing debian.

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

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


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

Bug#689543: cdimage.debian.org: generic debian system switches gui from tty7 to tty8 when connecting ethernet

[evan]

Package: cdimage.debian.org
Severity: wishlist

Whenever I connect my ethernet the system gui switches from tty7 to tty8. I 
downloaded this iso from debian.org. The system functions
properly but I am not sure why this generic version of debian is switching to 
tty8 when I connect to the internet. Thank you.

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

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


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

Bug#686120: wireshark: Segfault when clicking Cancel button on the FlowGraph window with the Graph Analysis window open

[Evan Huus]

It looks like GTK is calling flow_graph_on_destroy@flowgraph.c:138
before calling on_destroy@graph_analysis.c:169. Since the latter
references memory free()ed by the former, we're getting a segfault
sometimes. Not sure what the appropriate fix is - glib doesn't seem to
have a way to explicitly order signal deliveries?

On Tue, Aug 28, 2012 at 3:44 PM, Nahuel Greco  wrote:
> Package: wireshark
> Version: 1.8.2-1
> Severity: normal
>
> Try the following:
>
> 1- Open any .pcap file
> 2- Open the FlowGraph window using Statics->FlowGraph
> 3- Press the OK button to display the Graph Analysis window, it will
> show without closing the previous window
> 4- Press the CANCEL button in the FlowGraph window (the first window
> opened)
> 5- segfault
>
>
>
> -- System Information:
> Debian Release: wheezy/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (1, 'experimental')
> Architecture: i386 (i686)
>
> Kernel: Linux 3.2.0-3-686-pae (SMP w/2 CPU cores)
> Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
> Shell: /bin/sh linked to /bin/bash
>
> Versions of packages wireshark depends on:
> ii  libc6   2.13-35
> ii  libcairo2   1.12.2-2
> ii  libgdk-pixbuf2.0-0  2.26.1-1
> ii  libglib2.0-02.32.3-1
> ii  libgtk2.0-0 2.24.10-2
> ii  libpango1.0-0   1.30.0-1
> ii  libpcap0.8  1.3.0-1
> ii  libportaudio2   19+svn2021-1
> ii  libwireshark2   1.8.2-1
> ii  libwiretap2 1.8.2-1
> ii  libwsutil2  1.8.2-1
> ii  wireshark-common1.8.2-1
> ii  zlib1g  1:1.2.7.dfsg-13
>
> wireshark recommends no packages.
>
> wireshark suggests no packages.
>
> -- no debconf information
>


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

Bug#678342: Autotools helpers are not installed

[Evan Nemerson]

Package: valac
Version: 0.16.0-2

Vala ships with some helpers for autotools which are not being
distributed with the Debian packages due to --disable-unversioned being
passed to configure.

See https://bugzilla.gnome.org/show_bug.cgi?id=668812






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

Bug#672292: lintian: harness errors out on master due to list being passed to require

[Evan Broder]

Package: lintian
Version: 2.5.6-100-geef3c3b
Severity: important

Dear Maintainer,

Currently the reporting harness on master exits with the following error:

  syntax error at ./harness line 104, near "require Lintian::Util 
qw(visit_dpkg_paragraph)"

It seems that this is because the `require` function doesn't accept a
list argument in the same way that `use` does.

-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise'), (100, 'precise-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-24-generic (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

Versions of packages lintian depends on:
ii  binutils   2.22-6ubuntu1
ii  bzip2  1.0.6-1
ii  diffstat   1.54-1
ii  file   5.09-2
ii  gettext0.18.1.1-5ubuntu3
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.25build2
ii  libc-bin   2.15-0ubuntu10
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.31-1build3
ii  libdpkg-perl   1.16.1.2ubuntu7
ii  libemail-valid-perl0.185-1
ii  libipc-run-perl0.90-1
ii  libparse-debianchangelog-perl  1.2.0-1ubuntu1
ii  libtimedate-perl   1.2000-1
ii  liburi-perl1.59-1
ii  locales2.13+git20120306-3
ii  man-db 2.6.1-2
ii  patchutils 0.3.2-1.1
ii  perl [libdigest-sha-perl]  5.14.2-6ubuntu2
ii  unzip  6.0-4ubuntu1

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 
ii  dpkg-dev   1.16.1.2ubuntu7
ii  libhtml-parser-perl3.69-1build1
ii  libtext-template-perl  1.45-2
ii  man-db 2.6.1-2
ii  xz-utils   5.1.1alpha+20110809-3

-- no debconf information



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

Bug#671286: LUA_CPATH_DEFAULT broken when not building with debhelper

[Evan Wies]

Package: lua5.1
Version: 5.1.4-6

Changeset 5.1.4-6)which introduced DEB_HOST_MULTIARCH for the 
LUA_CPATH_DEFAULT in luaconf.h, like so:

#define LUA_CDIR2 LUA_ROOT2 "lib/" DEB_HOST_MULTIARCH "/lua/5.1/"
...
#define LUA_CPATH_DEFAULT \
"./?.so;" LUA_CDIR"?.so;" LUA_CDIR2"?.so;" LUA_CDIR3"?.so;" 
LUA_CDIR"loadall.so"

#endif

The DEB_HOST_MULTIARCH is only set during the Debian build process, or 
manually through the preprocessor. Since Lua packages are built with 
debhelper, they include a well-formed LUA_CPATH_DEFAULT.


However, this change breaks the compilation of programs outside of 
debhelper which embed Lua and rely upon LUA_CPATH_DEFAULT:

error: expected ')' before 'DEB_HOST_MULTIARCH'

A workaround is to set DEB_HOST_MULTIARCH manually (using 
dpkg-architecture -qDEB_HOST_MULTIARCH), or construct ones own 
LUA_CPATH_DEFAULT.


Since liblua5.1-0dev is architecture-specific, perhaps the build process 
could insert the architecture into luaconf.h rather than depend on a 
definition set in the package build process?


This is still present in the 5.1.4 series, as well as 5.1.5-1

This bug was originally submitted to Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/lua5.1/+bug/977813

Bug#661759: Wireshark should use SVG icon by default

[Evan Huus]

Package: wireshark
Version: 1.6.5-1

As from Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/wireshark/+bug/943649

The Wireshark icon currently used is a PNG that looks blurry when scaled up
in the Ubuntu launcher or alt-tab switcher. Wireshark provides an SVG icon
already, so that should be used instead.

Thanks,
Evan

Bug#651776: Please transition gtkmm2.4 to multiarch

[Evan Broder]

Package: gtkmm2.4
Version: 1:2.24.2-2
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu precise ubuntu-patch

Hello -

Please find attached a patch to gtkmm2.4 to transition it to use
multiarch library paths as described at
<http://wiki.debian.org/Multiarch/Implementation>. This patch should
be safe to apply in Debian now that multiarch has been bootstrapped.

Since libgtkmm-2.4-dev contains no build-time-generated include files
or arch-dependent scripts/executables, it can be safely marked as
Multi-Arch: same, so this patch does so. Because many of its direct
and indirect dependencies have not yet been transitioned for
multiarch, libgtkmm-2.4-dev will not currently be multiarch
co-installable. This is fine, though, and if all of the dependencies
were ever to be transitioned for multiarch, the gtkmm -dev package
would immediately become multiarch co-installable.

Typically the biggest outstanding blocker to multiarch transitions is
.la files with non-empty dependency_libs lines. I don't have access to
lintian.debian.org, but I checked all files listed in
http://lintian.ubuntuwire.org/tags/non-empty-dependency_libs-in-la-file.html
(http://paste.ubuntu.com/766579/) and gtkmm2.4 isn't listed anywhere,
so this transition should be safe now by that metric.

Thanks for your consideration,
 - Evan

-- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric'), (100, 'oneiric-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-13-generic (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
diff -Nru gtkmm2.4-2.24.2/debian/control gtkmm2.4-2.24.2/debian/control
--- gtkmm2.4-2.24.2/debian/control	2011-08-15 01:27:13.0 -0700
+++ gtkmm2.4-2.24.2/debian/control	2011-12-11 21:01:11.0 -0800
@@ -12,8 +12,8 @@
 Homepage: http://www.gtkmm.org/
 Vcs-Browser: http://svn.debian.org/viewsvn/pkg-gnome/desktop/unstable/gtkmm2.4
 Vcs-Svn: svn://svn.debian.org/svn/pkg-gnome/desktop/unstable/gtkmm2.4
-Build-Depends: cdbs (>= 0.4.51),
-   debhelper (>= 6),
+Build-Depends: cdbs (>= 0.4.93~),
+   debhelper (>= 8.1.3~),
gnome-pkg-tools (>= 0.11),
libgtk2.0-dev (>= 2.24.0),
libglibmm-2.4-dev (>= 2.27.93),
@@ -26,6 +26,7 @@
 Package: libgtkmm-2.4-dev
 Section: libdevel
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  libgtkmm-2.4-1c2a (= ${binary:Version}),
@@ -36,6 +37,7 @@
  libpangomm-1.4-dev (>= 2.26.0),
  libatkmm-1.6-dev (>= 2.22.0)
 Suggests: libgtkmm-2.4-doc
+Multi-Arch: same
 Description: C++ wrappers for GTK+ (development files)
  Gtkmm is a C++ interface for the popular GUI library GTK+, with API version
  2.4.  Gtkmm provides a convenient interface for C++ programmers to create
@@ -49,12 +51,14 @@
 Package: libgtkmm-2.4-1c2a
 Section: libs
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends},
  ${shlibs:Depends}
 Conflicts: libgtkmm-2.4-1,
libgtkmm-2.4-1c2
 Replaces: libgtkmm-2.4-1,
   libgtkmm-2.4-1c2
+Multi-Arch: same
 Description: C++ wrappers for GTK+ (shared libraries)
  Gtkmm is a C++ interface for the popular GUI library GTK+, with API version
  2.4.  Gtkmm provides a convenient interface for C++ programmers to create
@@ -68,9 +72,11 @@
 Section: debug
 Priority: extra
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  libgtkmm-2.4-1c2a (= ${binary:Version})
+Multi-Arch: same
 Description: C++ wrappers for GTK+ (debug symbols)
  Gtkmm is a C++ interface for the popular GUI library GTK+, with API version
  2.4.  Gtkmm provides a convenient interface for C++ programmers to create
diff -Nru gtkmm2.4-2.24.2/debian/control.in gtkmm2.4-2.24.2/debian/control.in
--- gtkmm2.4-2.24.2/debian/control.in	2011-08-15 01:09:31.0 -0700
+++ gtkmm2.4-2.24.2/debian/control.in	2011-12-11 21:00:59.0 -0800
@@ -7,8 +7,8 @@
 Homepage: http://www.gtkmm.org/
 Vcs-Browser: http://svn.debian.org/viewsvn/pkg-gnome/desktop/unstable/gtkmm2.4
 Vcs-Svn: svn://svn.debian.org/svn/pkg-gnome/desktop/unstable/gtkmm2.4
-Build-Depends: cdbs (>= 0.4.51),
-   debhelper (>= 6),
+Build-Depends: cdbs (>= 0.4.93~),
+   debhelper (>= 8.1.3~),
gnome-pkg-tools (>= 0.11),
libgtk2.0-dev (>= 2.24.0),
libglibmm-2.4-dev (>= 2.27.93),
@@ -21,6 +21,7 @@
 Package: libgtkmm-2.4-dev
 Section: libdevel
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  libgtkmm-2.4-1c2a (= ${binary:Version}),
@@ -31,6 +32,7 @@

Bug#651759: Please transition pangomm to multiarch

[Evan Broder]

Package: pangomm
Version: 2.28.4-2
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu precise ubuntu-patch

Hello -

Please find attached a patch to pangomm to transition it to use
multiarch library paths as described at
<http://wiki.debian.org/Multiarch/Implementation>. This patch should
be safe to apply in Debian now that multiarch has been bootstrapped.

Since libpangomm-1.4-dev contains no build-time-generated include
files or arch-dependent scripts/executables, it can be safely marked
as Multi-Arch: same, so this patch does so. Because many of its direct
and indirect dependencies have not yet been transitioned for
multiarch, libpangomm-1.4-dev will not currently be multiarch
co-installable. This is fine, though, and if all of the dependencies
were ever to be transitioned for multiarch, the pangomm -dev
package would immediately become multiarch co-installable.

Typically the biggest outstanding blocker to multiarch transitions is
.la files with non-empty dependency_libs lines. I don't have access to
lintian.debian.org, but I checked all files listed in
http://lintian.ubuntuwire.org/tags/non-empty-dependency_libs-in-la-file.html
(http://paste.ubuntu.com/766579/) and pangomm isn't listed anywhere,
so this transition should be safe now by that metric.

Thanks for your consideration,
 - Evan

-- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric'), (100, 'oneiric-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-13-generic (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
diff -Nru pangomm-2.28.4/debian/control pangomm-2.28.4/debian/control
--- pangomm-2.28.4/debian/control	2011-11-16 16:47:10.0 -0800
+++ pangomm-2.28.4/debian/control	2011-12-11 15:17:50.0 -0800
@@ -11,8 +11,8 @@
 DM-Upload-Allowed: yes
 Vcs-Browser: http://svn.debian.org/viewsvn/pkg-gnome/desktop/unstable/pangomm
 Vcs-Svn: svn://svn.debian.org/svn/pkg-gnome/desktop/unstable/pangomm
-Build-Depends: cdbs (>= 0.4.51),
-   debhelper (>= 8),
+Build-Depends: cdbs (>= 0.4.93~),
+   debhelper (>= 8.1.3~),
gnome-pkg-tools (>= 0.11),
libcairomm-1.0-dev (>= 1.2.2),
libglibmm-2.4-dev (>= 2.22.1-2),
@@ -23,10 +23,12 @@
 
 Package: libpangomm-1.4-1
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Replaces: libgtkmm-2.4-1c2a (<< 1:2.13)
 Conflicts: libgtkmm-2.4-1c2a (<< 1:2.13)
 Depends: ${shlibs:Depends},
  ${misc:Depends}
+Multi-Arch: same
 Description: C++ Wrapper for pango (shared libraries)
  Pangomm is a C++ wrapper for the pango library. Originally part of
  gtkmm, pangomm provides convenient C++ interfaces for handling both
@@ -36,6 +38,7 @@
 
 Package: libpangomm-1.4-dev
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Replaces: libgtkmm-2.4-dev (<< 1:2.13)
 Conflicts: libgtkmm-2.4-dev (<< 1:2.13)
 Section: libdevel
@@ -45,6 +48,7 @@
  libcairomm-1.0-dev (>= 1.2.2),
  libglibmm-2.4-dev (>= 2.14.1),
  libpango1.0-dev (>= 1.23.0)
+Multi-Arch: same
 Description: C++ Wrapper for pango (development files)
  Pangomm is a C++ wrapper for the pango library. Originally part of
  gtkmm, pangomm provides convenient C++ interfaces for handling both
@@ -71,9 +75,11 @@
 Architecture: any
 Section: debug
 Priority: extra
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends},
  ${misc:Depends},
  libpangomm-1.4-1 (= ${binary:Version})
+Multi-Arch: same
 Description: C++ Wrapper for pango (debugging symbols)
  Pangomm is a C++ wrapper for the pango library. Originally part of
  gtkmm, pangomm provides convenient C++ interfaces for handling both
diff -Nru pangomm-2.28.4/debian/control.in pangomm-2.28.4/debian/control.in
--- pangomm-2.28.4/debian/control.in	2011-11-16 16:40:24.0 -0800
+++ pangomm-2.28.4/debian/control.in	2011-12-11 15:17:40.0 -0800
@@ -6,8 +6,8 @@
 DM-Upload-Allowed: yes
 Vcs-Browser: http://svn.debian.org/viewsvn/pkg-gnome/desktop/unstable/pangomm
 Vcs-Svn: svn://svn.debian.org/svn/pkg-gnome/desktop/unstable/pangomm
-Build-Depends: cdbs (>= 0.4.51),
-   debhelper (>= 8),
+Build-Depends: cdbs (>= 0.4.93~),
+   debhelper (>= 8.1.3~),
gnome-pkg-tools (>= 0.11),
libcairomm-1.0-dev (>= 1.2.2),
libglibmm-2.4-dev (>= 2.22.1-2),
@@ -18,10 +18,12 @@
 
 Package: libpangomm-1.4-1
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Replaces: libgtkmm-2.4-1c2a (<< 1:2.13)
 Conflicts: libgtkmm-2.4-1c2a (<< 1:2.13)
 Depends: ${shlibs:Depends},
  ${misc:Depends}
+Multi-Arch: same
 Description: C++ Wrapper for pango (shared libraries)
  Pangomm 

Bug#651744: Please transition cairomm for multiarch

[Evan Broder]

Package: cairomm
Version: 1.10.0-2
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu precise ubuntu-patch

Hello -

Please find attached a patch to cairomm to transition it to use
multiarch library paths as described at
<http://wiki.debian.org/Multiarch/Implementation>. This patch should
be safe to apply in Debian now that multiarch has been bootstrapped.

Since libcairomm-1.0-dev contains no build-time-generated include
files or arch-dependent scripts/executables, it can be safely marked
as Multi-Arch: same, so this patch does so. Because many of its direct
and indirect dependencies have not yet been transitioned for
multiarch, libcairomm-1.0-dev will not currently be multiarch
co-installable. This is fine, though, and if all of the dependencies
were ever to be transitioned for multiarch, the libcairomm -dev
package would immediately become multiarch co-installable.

Typically the biggest outstanding blocker to multiarch transitions is
.la files with non-empty dependency_libs lines. I don't have access to
lintian.debian.org, but I checked all files listed in
http://lintian.ubuntuwire.org/tags/non-empty-dependency_libs-in-la-file.html
(http://paste.ubuntu.com/766579/) and cairomm isn't listed anywhere,
so this transition should be safe now by that metric.

Thanks for your consideration,
 - Evan

-- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric'), (100, 'oneiric-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-13-generic (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
diff -Nru cairomm-1.10.0/debian/control cairomm-1.10.0/debian/control
--- cairomm-1.10.0/debian/control	2011-05-17 09:45:51.0 -0700
+++ cairomm-1.10.0/debian/control	2011-12-11 12:12:37.0 -0800
@@ -3,15 +3,17 @@
 Priority: optional
 Maintainer: Dave Beckett 
 Uploaders: Danilo Piazzalunga 
-Build-Depends: debhelper (>= 5), cdbs, libcairo2-dev (>= 1.10.0), libsigc++-2.0-dev, gnome-pkg-tools
+Build-Depends: debhelper (>= 8.1.3~), cdbs (>= 0.4.93~), libcairo2-dev (>= 1.10.0), libsigc++-2.0-dev, gnome-pkg-tools
 Standards-Version: 3.9.2
 Homepage: http://cairographics.org/cairomm/
 
 Package: libcairomm-1.0-dev
 Section: libdevel
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Depends: libcairomm-1.0-1 (= ${binary:Version}), libcairo2-dev (>= 1.10.0), ${misc:Depends}, libsigc++-2.0-dev
 Suggests: libcairomm-1.0-doc
+Multi-Arch: same
 Description: C++ wrappers for Cairo (development files)
  cairomm provides C++ bindings for the Cairo graphics library,
  a multi-platform library providing anti-aliased vector-based
@@ -24,8 +26,10 @@
 Package: libcairomm-1.0-1
 Section: libs
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Replaces: libcairomm-1.0-0
+Multi-Arch: same
 Description: C++ wrappers for Cairo (shared libraries)
  cairomm provides C++ bindings for the Cairo graphics library,
  a multi-platform library providing anti-aliased vector-based
diff -Nru cairomm-1.10.0/debian/libcairomm-1.0-1.install cairomm-1.10.0/debian/libcairomm-1.0-1.install
--- cairomm-1.10.0/debian/libcairomm-1.0-1.install	2010-04-20 13:40:07.0 -0700
+++ cairomm-1.10.0/debian/libcairomm-1.0-1.install	2011-12-10 18:18:49.0 -0800
@@ -1 +1 @@
-debian/tmp/usr/lib/libcairomm-1.0.so.*
+debian/tmp/usr/lib/*/libcairomm-1.0.so.*
diff -Nru cairomm-1.10.0/debian/libcairomm-1.0-dev.install cairomm-1.10.0/debian/libcairomm-1.0-dev.install
--- cairomm-1.10.0/debian/libcairomm-1.0-dev.install	2010-04-30 19:40:38.0 -0700
+++ cairomm-1.10.0/debian/libcairomm-1.0-dev.install	2011-12-10 18:18:37.0 -0800
@@ -1,9 +1,9 @@
 debian/tmp/usr/include
-debian/tmp/usr/lib/libcairomm-1.0*.so
-debian/tmp/usr/lib/libcairomm-1.0*.a
-debian/tmp/usr/lib/libcairomm-1.0*.la
-debian/tmp/usr/lib/pkgconfig
-debian/tmp/usr/lib/cairomm-1.0
+debian/tmp/usr/lib/*/libcairomm-1.0*.so
+debian/tmp/usr/lib/*/libcairomm-1.0*.a
+debian/tmp/usr/lib/*/libcairomm-1.0*.la
+debian/tmp/usr/lib/*/pkgconfig
+debian/tmp/usr/lib/*/cairomm-1.0
 examples/README usr/share/doc/libcairomm-1.0-dev/examples
 examples/surfaces/*.cc usr/share/doc/libcairomm-1.0-dev/examples/surfaces
 examples/text/*.cc usr/share/doc/libcairomm-1.0-dev/examples/text
diff -Nru cairomm-1.10.0/debian/rules cairomm-1.10.0/debian/rules
--- cairomm-1.10.0/debian/rules	2011-05-17 09:46:36.0 -0700
+++ cairomm-1.10.0/debian/rules	2011-12-10 18:16:44.0 -0800
@@ -5,7 +5,7 @@
 include /usr/share/gnome-pkg-tools/1/rules/clean-la.mk
 
 # We want .a
-DEB_CONFIGURE_EXTRA_FLAGS = --enable-static
+DEB_CONFIGURE_EXTRA_FLAGS = --enable-static --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
 
 # Doxygen cannot handle compressed tag files
 DEB_COMPRESS_EXCLUDE := .tag

Bug#651596: Please transition atkmm1.6 for multiarch

[Evan Broder]

Source: atkmm1.6
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu precise ubuntu-patch

Hello -

Please find attached a patch to atkmm1.6 to transition it to use
multiarch library paths as described at
<http://wiki.debian.org/Multiarch/Implementation>. This patch should
be safe to apply in Debian now that multiarch has been bootstrapped.

Since libatkmm-1.6-dev contains no build-time-generated include files
or arch-dependent scripts/executables, it can be safely marked as
Multi-Arch: same, so this patch does so. Because many of its
dependencies (at least libatk1.0-dev and libglib2.0-dev) have not yet
been transitioned for multiarch, libatkmm-1.6-dev will not currently
be multiarch co-installable. This is fine, though, and if all of the
dependencies were ever to be transitioned for multiarch, the libatkmm
-dev package would immediately become multiarch co-installable.

The most significant blocker to converting packages to multiarch is
the presence of .la files which reference a library in its
dependency_libs line. Debian is tracking the presence of such
problematic .la files at
<http://release.debian.org/~aba/la/current.txt>; however, that file
appears to be out of date and inaccurate.

The only remaining problematic .la file for atkmm1.6 is
python-visual. I've uploaded an NMU to fix python-visual (bug #633273)
which will exit the deferred queue tomorrow; once that goes through
this upload will be safe. Note that with the exception of .la files,
there is no need to block transitioning a library to multiarch on any
dependencies above or below it.

Thanks for your consideration,
 - Evan

-- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric'), (100, 'oneiric-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-13-generic (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
diff -Nru atkmm1.6-2.22.6/debian/changelog atkmm1.6-2.22.6/debian/changelog
--- atkmm1.6-2.22.6/debian/changelog	2011-11-16 17:28:12.0 -0800
+++ atkmm1.6-2.22.6/debian/changelog	2011-12-10 02:58:59.0 -0800
@@ -1,3 +1,14 @@
+atkmm1.6 (2.22.6-2) unstable; urgency=low
+
+  * Convert to multiarch:
+- Pass --libdir with multiarch path to configure
+- Adjust .install files to refer to /usr/lib subdirs
+- Add multiarch Pre-Depends
+- Bump debhelper and cdbs build-deps for ${misc:Pre-Depends} and
+  $(DEB_HOST_MULTIARCH) support, respectively
+
+ -- Evan Broder   Sat, 10 Dec 2011 02:46:11 -0800
+
 atkmm1.6 (2.22.6-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru atkmm1.6-2.22.6/debian/control atkmm1.6-2.22.6/debian/control
--- atkmm1.6-2.22.6/debian/control	2011-11-16 17:30:23.0 -0800
+++ atkmm1.6-2.22.6/debian/control	2011-12-10 02:59:25.0 -0800
@@ -12,8 +12,8 @@
 Homepage: http://www.gtkmm.org/
 Vcs-Browser: http://svn.debian.org/viewsvn/pkg-gnome/packages/unstable/atkmm1.6
 Vcs-Svn: svn://svn.debian.org/svn/pkg-gnome/packages/unstable/atkmm1.6
-Build-Depends: cdbs (>= 0.4.51),
-   debhelper (>= 8),
+Build-Depends: cdbs (>= 0.4.93~),
+   debhelper (>= 8.1.3~),
gnome-pkg-tools (>= 0.11),
libglibmm-2.4-dev (>= 2.24.0),
libatk1.0-dev (>= 1.12.0),
@@ -23,6 +23,7 @@
 Package: libatkmm-1.6-dev
 Section: libdevel
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  libatkmm-1.6-1 (= ${binary:Version}),
@@ -31,6 +32,7 @@
 Suggests: libatkmm-1.6-doc
 Breaks: libgtkmm-2.4-dev (<< 1:2.22.0)
 Replaces: libgtkmm-2.4-dev (<< 1:2.22.0)
+Multi-Arch: same
 Description: C++ wrappers for ATK accessibility toolkit (development files)
  Atkmm is a C++ interface for ATK, accessibility toolkit used by Gtk+ library.
  It provides a familiar interface for C++ programmers to add accessibility
@@ -40,10 +42,12 @@
 
 Package: libatkmm-1.6-1
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends},
  ${shlibs:Depends}
 Breaks: libgtkmm-2.4-1c2a (<< 1:2.22.0)
 Replaces: libgtkmm-2.4-1c2a (<< 1:2.22.0)
+Multi-Arch: same
 Description: C++ wrappers for ATK accessibility toolkit (shared libraries)
  Atkmm is a C++ interface for ATK, accessibility toolkit used by Gtk+ library.
  It provides a familiar interface for C++ programmers to add accessibility
@@ -55,11 +59,13 @@
 Section: debug
 Priority: extra
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  libatkmm-1.6-1 (= ${binary:Version})
 Breaks: libgtkmm-2.4-dbg (<< 1:2.22.0)
 Replaces: libgtkmm-2.4-dbg (<< 1:2.22.0)
+Multi-Arch: same
 Description: C++ wrappers for ATK accessibility toolk

Bug#651134: transition glibmm2.4 for multiarch

[Evan Broder]

I've been informed by Steve Langasek that he prefers the substvar
${misc:Pre-Depends} over explicitly pre-depending on multiarch-support
so that we can easily phase out the pre-dependency when it's no longer
needed for transitional purposes.

Therefore, here is a patch which uses the substvar instead. It also
requires a debhelper build-dep bump, because 8.1.3 was the version
debhelper version to support that substvar.

Thanks,
 - Evan
diff -Nru glibmm2.4-2.31.2/debian/control glibmm2.4-2.31.2/debian/control
--- glibmm2.4-2.31.2/debian/control	2011-12-07 15:19:15.0 +
+++ glibmm2.4-2.31.2/debian/control	2011-12-10 01:20:44.0 +
@@ -13,8 +13,8 @@
 Homepage: http://www.gtkmm.org/
 Vcs-Browser: http://svn.debian.org/viewsvn/pkg-gnome/desktop/unstable/glibmm2.4
 Vcs-Svn: svn://svn.debian.org/svn/pkg-gnome/desktop/unstable/glibmm2.4
-Build-Depends: cdbs (>= 0.4.51),
-   debhelper (>= 8),
+Build-Depends: cdbs (>= 0.4.93~),
+   debhelper (>= 8.1.3~),
gnome-pkg-tools (>= 0.11),
libglib2.0-dev (>= 2.31.0),
libsigc++-2.0-dev (>= 2.0.10),
@@ -24,8 +24,10 @@
 Package: libglibmm-2.4-1c2a
 Section: libs
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends},
  ${shlibs:Depends}
+Multi-Arch: same
 Description: C++ wrapper for the GLib toolkit (shared libraries)
  GLib is a low-level general-purpose library used mainly by GTK+/GNOME
  applications, but is useful for other programs as well.
@@ -36,6 +38,7 @@
 Package: libglibmm-2.4-dev
 Section: libdevel
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  libglibmm-2.4-1c2a (= ${binary:Version}),
@@ -44,6 +47,7 @@
  pkg-config
 Suggests: libglibmm-2.4-doc,
   libgtkmm-3.0-dev
+Multi-Arch: same
 Description: C++ wrapper for the GLib toolkit (development files)
  GLib is a low-level general-purpose library used mainly by GTK+/GNOME
  applications, but is useful for other programs as well.
@@ -55,9 +59,11 @@
 Section: debug
 Priority: extra
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  libglibmm-2.4-1c2a (= ${binary:Version})
+Multi-Arch: same
 Description: C++ wrapper for the GLib toolkit (debug symbols)
  GLib is a low-level general-purpose library used mainly by GTK+/GNOME
  applications, but is useful for other programs as well.
diff -Nru glibmm2.4-2.31.2/debian/control.in glibmm2.4-2.31.2/debian/control.in
--- glibmm2.4-2.31.2/debian/control.in	2011-12-07 15:04:27.0 +
+++ glibmm2.4-2.31.2/debian/control.in	2011-12-10 01:19:13.0 +
@@ -8,8 +8,8 @@
 Homepage: http://www.gtkmm.org/
 Vcs-Browser: http://svn.debian.org/viewsvn/pkg-gnome/desktop/unstable/glibmm2.4
 Vcs-Svn: svn://svn.debian.org/svn/pkg-gnome/desktop/unstable/glibmm2.4
-Build-Depends: cdbs (>= 0.4.51),
-   debhelper (>= 8),
+Build-Depends: cdbs (>= 0.4.93~),
+   debhelper (>= 8.1.3~),
gnome-pkg-tools (>= 0.11),
libglib2.0-dev (>= 2.31.0),
libsigc++-2.0-dev (>= 2.0.10),
@@ -19,8 +19,10 @@
 Package: libglibmm-2.4-1c2a
 Section: libs
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends},
  ${shlibs:Depends}
+Multi-Arch: same
 Description: C++ wrapper for the GLib toolkit (shared libraries)
  GLib is a low-level general-purpose library used mainly by GTK+/GNOME
  applications, but is useful for other programs as well.
@@ -31,6 +33,7 @@
 Package: libglibmm-2.4-dev
 Section: libdevel
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  libglibmm-2.4-1c2a (= ${binary:Version}),
@@ -39,6 +42,7 @@
  pkg-config
 Suggests: libglibmm-2.4-doc,
   libgtkmm-3.0-dev
+Multi-Arch: same
 Description: C++ wrapper for the GLib toolkit (development files)
  GLib is a low-level general-purpose library used mainly by GTK+/GNOME
  applications, but is useful for other programs as well.
@@ -50,9 +54,11 @@
 Section: debug
 Priority: extra
 Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  libglibmm-2.4-1c2a (= ${binary:Version})
+Multi-Arch: same
 Description: C++ wrapper for the GLib toolkit (debug symbols)
  GLib is a low-level general-purpose library used mainly by GTK+/GNOME
  applications, but is useful for other programs as well.
diff -Nru glibmm2.4-2.31.2/debian/libglibmm-2.4-1c2a.install glibmm2.4-2.31.2/debian/libglibmm-2.4-1c2a.install
--- glibmm2.4-2.31.2/debian/libglibmm-2.4-1c2a.install	2011-12-07 15:02:46.0 +
+++ glibmm2.4-2.31.2/debian/libglibmm-2.4-1c2a.install	2011-12-10 01:19:13.0 +
@@ -1 +1 @@
-usr/lib/lib*.so.*
+usr/lib/*/lib*.so.*
diff -Nru glibmm2.4-2.31.2/debian/libglibmm-2.4-dev.insta

Bug#651363: ITP: python-github2 -- Library to expose all the version 2 Github API over Python

[Evan Broder]

On Fri, Dec 9, 2011 at 8:24 AM, Paul Tagliamonte  wrote:
> On Fri, Dec 9, 2011 at 11:18 AM, Evan Broder  wrote:
>> Hey Paul -
>>   Does it make sense to put python-github2 in the archive at this
>> point? Github has recently deprecated the v2 API in favor of their new
>> v3 API (http://develop.github.com/ and http://developer.github.com/v3/
>> respectively)
>
> I think that's a really valid concern, and it's something I thought
> about - however, the v3 API is fairly incomplete and at times,
> unusable. v2 is still being used (even though it's called deprecated)
> - however, I was on the fence about introducing it.
>
> I thought having it as a option would be a good thing(tm), but a
> stiffly worded mail or argument would change my mind.
>
> I'd love to hear your thoughts on this, personally, I see the use, but
> others might see it as more of a liability.

I don't have particularly strong opinions on this, so I certainly
won't be the person to write such a stiffly worded e-mail.

I'm mostly concerned about the long-term support costs for bindings to
an API that's already marked as deprecated - even if there's no plan
to phase it out. In particular, Github claims on [1] that they intend
to finalize the v3 API some time around now, at which point I would
expect them to start coming up with a deprecation schedule for v2.

But at the end of the day, I think there are strong mitigating factors
- the incompleteness of the API (have you considered reaching out to
Github about that?), and the fact that stable and complete Python
bindings for the v3 API don't seem to have asserted themselves yet. So
I guess I'd say go for it.

[1] http://developer.github.com/v3/changelog/



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

Bug#651363: ITP: python-github2 -- Library to expose all the version 2 Github API over Python

[Evan Broder]

Hey Paul -
   Does it make sense to put python-github2 in the archive at this
point? Github has recently deprecated the v2 API in favor of their new
v3 API (http://develop.github.com/ and http://developer.github.com/v3/
respectively)

- Evan



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

Bug#636890: yada modifies build-dependencies when rebuilding

[Evan Broder]

Package: libapache2-mod-auth-pam
Followup-For: Bug #636890
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu precise ubuntu-patch

Hello maintainer,

Please find attached a patch which replaces yada with debhelper and
uses source format 3.0 (quilt) to patch the upstream source. With this
patch, the package is clean of lintian errors and warnings.

Thanks,
 - Evan

-- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric'), (100, 'oneiric-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-13-generic (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
diff -Nru libapache2-mod-auth-pam-1.1.1/debian/compat libapache2-mod-auth-pam-1.1.1/debian/compat
--- libapache2-mod-auth-pam-1.1.1/debian/compat	1969-12-31 16:00:00.0 -0800
+++ libapache2-mod-auth-pam-1.1.1/debian/compat	2011-12-05 23:00:25.0 -0800
@@ -0,0 +1 @@
+8
diff -Nru libapache2-mod-auth-pam-1.1.1/debian/conf/apache2 libapache2-mod-auth-pam-1.1.1/debian/conf/apache2
--- libapache2-mod-auth-pam-1.1.1/debian/conf/apache2	1969-12-31 16:00:00.0 -0800
+++ libapache2-mod-auth-pam-1.1.1/debian/conf/apache2	2011-11-29 20:48:42.0 -0800
@@ -0,0 +1,2 @@
+@include common-auth
+@include common-account
diff -Nru libapache2-mod-auth-pam-1.1.1/debian/conf/apache2.pam.conf libapache2-mod-auth-pam-1.1.1/debian/conf/apache2.pam.conf
--- libapache2-mod-auth-pam-1.1.1/debian/conf/apache2.pam.conf	2011-12-05 23:01:35.0 -0800
+++ libapache2-mod-auth-pam-1.1.1/debian/conf/apache2.pam.conf	1969-12-31 16:00:00.0 -0800
@@ -1,2 +0,0 @@
-@include common-auth
-@include common-account
diff -Nru libapache2-mod-auth-pam-1.1.1/debian/control libapache2-mod-auth-pam-1.1.1/debian/control
--- libapache2-mod-auth-pam-1.1.1/debian/control	2011-12-05 23:01:35.0 -0800
+++ libapache2-mod-auth-pam-1.1.1/debian/control	2011-12-05 23:00:47.0 -0800
@@ -2,12 +2,12 @@
 Maintainer: LENART Janos 
 Section: web
 Priority: extra
-Standards-Version: 3.8.1
-Build-Depends: apache2-threaded-dev (>= 2.0.50-9), libpam0g-dev, yada (>= 0.54)
+Standards-Version: 3.9.2
+Build-Depends: debhelper (>= 8.1.3~), apache2-threaded-dev (>= 2.0.50-9), libpam0g-dev
 
 Package: libapache2-mod-auth-pam
 Architecture: any
-Depends: apache2.2-common (>= 2.2.11-2), ${libapache2-mod-auth-pam:Depends}
+Depends: ${misc:Depends}, ${shlibs:Depends}, apache2.2-common (>= 2.2.11-2)
 Description: module for Apache2 which authenticate using PAM
  mod_auth_pam implements authentication routines using PAM (Plugable
  Authentication Modules) for apache's authentication protocol.
@@ -16,7 +16,7 @@
 
 Package: libapache2-mod-auth-sys-group
 Architecture: any
-Depends: apache2.2-common (>= 2.2.11-2), ${libapache2-mod-auth-sys-group:Depends}
+Depends: ${misc:Depends}, ${shlibs:Depends}, apache2.2-common (>= 2.2.11-2)
 Description: Module for Apache2 which checks user against system group
  mod_auth_pam implements 'require group' functionality against system group
  database.
diff -Nru libapache2-mod-auth-pam-1.1.1/debian/copyright libapache2-mod-auth-pam-1.1.1/debian/copyright
--- libapache2-mod-auth-pam-1.1.1/debian/copyright	1969-12-31 16:00:00.0 -0800
+++ libapache2-mod-auth-pam-1.1.1/debian/copyright	2011-11-29 21:07:11.0 -0800
@@ -0,0 +1,26 @@
+Copyright (c) 2000 Ingo Luetkebohle, All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in
+   the documentation and/or other materials provided with the
+   distribution.
+
+THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
+WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR OTHER CODE CONTRIBUTORS
+BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
+OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
+OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
+OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
+OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGE.
diff -Nru libapache2-mod-auth-pam-1.1.1/debian/doc/README.Debian libapache2-mod-auth-pam-1.1.1/debian/doc/README.Debian
--- libapache2-mod-auth-pam-1.1.1/debian/doc/READM

Bug#651134: Please transition glibmm2.4 for multiarch

[Evan Broder]

Source: glibmm2.4
Version: 2.30.0-3
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu precise ubuntu-patch

Hello -

Please find attached a patch to glibmm2.4 to transition ot to use
multiarch library paths as described at
<http://wiki.debian.org/Multiarch/Implementation>. This patch should
be safe to apply in Debian now that multiarch has been bootstrapped.

Since libglibmm-2.4-dev contains no build-time-generated include
files, it can be safely marked as Multi-Arch: same, so this patch does
so. Because its dependency libglib2.0-dev has not yet been
transitioned for multiarch, libglibmm-2.4-dev will not be multiarch
co-installable. This is fine, though, and if libglib2.0-dev were to
ever be transitioned for multiarch, the libglibmm -dev package would
become immediately co-installble.

The most significant blocker to converting packages to multiarch is
the presence of .la files which reference a library in its
dependency_libs line. Debian has made cleaning up these .la files a
release goal, and is tracking the presence of such problematic .la
files at <http://release.debian.org/~aba/la/current.txt>.

For some reason glibmm2.4 isn't listed in that file. However, as the
rest of the gtkmm stack lists python-visual and subtitleeditor, I
assume that those reference glibmm2.4 as well. subtitleeditor has
actually already been fixed (I don't know why it is still listed). I
uploaded a fix for python-visual to DELAYED/10 a few days ago (bug
#633273), so once that goes through this upload will be safe. (I'll
add the blocking metadata momentarily)

Thanks for considering the patch,
 - Evan


-- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric'), (100, 'oneiric-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-13-generic (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
diff -Nru glibmm2.4-2.30.0/debian/changelog glibmm2.4-2.30.0/debian/changelog
diff -Nru glibmm2.4-2.30.0/debian/control glibmm2.4-2.30.0/debian/control
--- glibmm2.4-2.30.0/debian/control	2011-12-02 16:56:39.0 -0800
+++ glibmm2.4-2.30.0/debian/control	2011-12-05 18:09:44.0 -0800
@@ -12,7 +12,7 @@
 Homepage: http://www.gtkmm.org/
 Vcs-Browser: http://svn.debian.org/viewsvn/pkg-gnome/desktop/unstable/glibmm2.4
 Vcs-Svn: svn://svn.debian.org/svn/pkg-gnome/desktop/unstable/glibmm2.4
-Build-Depends: cdbs (>= 0.4.51),
+Build-Depends: cdbs (>= 0.4.93~),
debhelper (>= 8),
gnome-pkg-tools (>= 0.11),
libglib2.0-dev (>= 2.30.0),
@@ -23,8 +23,10 @@
 Package: libglibmm-2.4-1c2a
 Section: libs
 Architecture: any
+Pre-Depends: multiarch-support
 Depends: ${misc:Depends},
  ${shlibs:Depends}
+Multi-Arch: same
 Description: C++ wrapper for the GLib toolkit (shared libraries)
  GLib is a low-level general-purpose library used mainly by GTK+/GNOME
  applications, but is useful for other programs as well.
@@ -35,6 +37,7 @@
 Package: libglibmm-2.4-dev
 Section: libdevel
 Architecture: any
+Pre-Depends: multiarch-support
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  libglibmm-2.4-1c2a (= ${binary:Version}),
@@ -43,6 +46,7 @@
  pkg-config
 Suggests: libglibmm-2.4-doc,
   libgtkmm-3.0-dev
+Multi-Arch: same
 Description: C++ wrapper for the GLib toolkit (development files)
  GLib is a low-level general-purpose library used mainly by GTK+/GNOME
  applications, but is useful for other programs as well.
@@ -54,9 +58,11 @@
 Section: debug
 Priority: extra
 Architecture: any
+Pre-Depends: multiarch-support
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  libglibmm-2.4-1c2a (= ${binary:Version})
+Multi-Arch: same
 Description: C++ wrapper for the GLib toolkit (debug symbols)
  GLib is a low-level general-purpose library used mainly by GTK+/GNOME
  applications, but is useful for other programs as well.
diff -Nru glibmm2.4-2.30.0/debian/control.in glibmm2.4-2.30.0/debian/control.in
--- glibmm2.4-2.30.0/debian/control.in	2011-12-02 16:18:49.0 -0800
+++ glibmm2.4-2.30.0/debian/control.in	2011-12-05 18:07:21.0 -0800
@@ -7,7 +7,7 @@
 Homepage: http://www.gtkmm.org/
 Vcs-Browser: http://svn.debian.org/viewsvn/pkg-gnome/desktop/unstable/glibmm2.4
 Vcs-Svn: svn://svn.debian.org/svn/pkg-gnome/desktop/unstable/glibmm2.4
-Build-Depends: cdbs (>= 0.4.51),
+Build-Depends: cdbs (>= 0.4.93~),
debhelper (>= 8),
gnome-pkg-tools (>= 0.11),
libglib2.0-dev (>= 2.30.0),
@@ -18,8 +18,10 @@
 Package: libglibmm-2.4-1c2a
 Section: libs
 Architecture: any
+Pre-Depends: multiarch-support
 Depends: ${misc:Depends},
  ${shlibs:Depends}
+Multi-Arch: same
 Description: C++ wrapper for the GLib t

Bug#651024: Acknowledgement (Please transition libsigc++-2.0 for multiarch)

[Evan Broder]

*sigh* This is a bit embarrassing, but it looks like I grabbed an old
version of my patch.

Because there are no build-time-generated header files,
libsigc++-2.0-dev can be safely marked as Multi-Arch: same as well.

Updated patch attached, along with my apologies.

- Evan


libsigc++-2.0_2.2.10-0ubuntu2.debdiff
Description: Binary data

Bug#651024: Acknowledgement (Please transition libsigc++-2.0 for multiarch)

[Evan Broder]

block 651024 by 633273
thanks

Oh, sorry - I forgot that before moving the library paths, all
dependencies which list the current paths in .la files must be
corrected in order to avoid needing a rebuild.

 lists python-visual
and subtitleeditor as the only two packages blocking this, however it
appears to be out of date as subtitleeditor has been fixed already.

An NMU for python-visual was uploaded to DELAYED/10 a few days ago;
once that goes through this conversion would be safe.



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

Bug#651024: Please transition libsigc++-2.0 for multiarch

[Evan Broder]

Package: libsigc++-2.0
Version: 2.2.9-1
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu precise ubuntu-patch

Hello -

Please find attached a patch to libsigc++-2.0 to transition it to use
multiarch library paths as described at
<http://wiki.debian.org/Multiarch/Implementation>. This patch should
be safe to apply in Debian now that multiarch has been bootstrapped.

Thanks,
 - Evan

-- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric'), (100, 'oneiric-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-13-generic (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
diff -Nru libsigc++-2.0-2.2.10/debian/control libsigc++-2.0-2.2.10/debian/control
--- libsigc++-2.0-2.2.10/debian/control	2011-08-24 08:47:30.0 -0700
+++ libsigc++-2.0-2.2.10/debian/control	2011-12-04 12:48:42.0 -0800
@@ -11,10 +11,12 @@
 
 Package: libsigc++-2.0-0c2a
 Section: libs
+Pre-Depends: multiarch-support
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Conflicts: libsigc++-1.9-0, libsigc++-2.0-0, libsigc++-2.0-0c2
 Replaces: libsigc++-1.9-0, libsigc++-2.0-0, libsigc++-2.0-0c2
 Architecture: any
+Multi-Arch: same
 Description: type-safe Signal Framework for C++ - runtime
  This library implements a full callback system for use in widget
  libraries, abstract interfaces, and general programming. It provides
@@ -27,10 +29,12 @@
 
 Package: libsigc++-2.0-dev
 Section: libdevel
+Pre-Depends: multiarch-support
 Conflicts: libsigc++-1.9-dev
 Replaces: libsigc++-1.9-dev
 Depends: libsigc++-2.0-${Soname} (= ${binary:Version}), pkg-config, ${misc:Depends}
 Suggests: libsigc++-2.0-doc
+Multi-Arch: same
 Architecture: any
 Description: type-safe Signal Framework for C++ - development files
  This library implements a full callback system for use in widget
diff -Nru libsigc++-2.0-2.2.10/debian/libsigc++-2.0-dev.install libsigc++-2.0-2.2.10/debian/libsigc++-2.0-dev.install
--- libsigc++-2.0-2.2.10/debian/libsigc++-2.0-dev.install	2011-08-24 08:47:30.0 -0700
+++ libsigc++-2.0-2.2.10/debian/libsigc++-2.0-dev.install	2011-11-29 15:02:02.0 -0800
@@ -1,6 +1,6 @@
 usr/include
-usr/lib/*.a
-usr/lib/*.la
-usr/lib/*.so
-usr/lib/pkgconfig
-usr/lib/sigc++-2.0
+usr/lib/*/*.a
+usr/lib/*/*.la
+usr/lib/*/*.so
+usr/lib/*/pkgconfig
+usr/lib/*/sigc++-2.0
diff -Nru libsigc++-2.0-2.2.10/debian/libsigc++-2.0.soname.install libsigc++-2.0-2.2.10/debian/libsigc++-2.0.soname.install
--- libsigc++-2.0-2.2.10/debian/libsigc++-2.0.soname.install	2011-08-24 08:47:30.0 -0700
+++ libsigc++-2.0-2.2.10/debian/libsigc++-2.0.soname.install	2011-11-29 14:56:37.0 -0800
@@ -1 +1 @@
-usr/lib/*.so.*
+usr/lib/*/*.so.*
diff -Nru libsigc++-2.0-2.2.10/debian/rules libsigc++-2.0-2.2.10/debian/rules
--- libsigc++-2.0-2.2.10/debian/rules	2011-08-24 08:47:30.0 -0700
+++ libsigc++-2.0-2.2.10/debian/rules	2011-11-29 15:23:18.0 -0800
@@ -18,6 +18,7 @@
 else
 CROSS= --build $(DEB_BUILD_GNU_TYPE)
 endif
+DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
 # Which automake version to use.
 AUTOMAKE_VERSION=1.10
@@ -100,7 +101,7 @@
 
 	ACLOCAL=$(ACLOCAL) AUTOMAKE=$(AUTOMAKE) autoreconf
 	test -d builddir || mkdir builddir
-	cd builddir && ../configure --prefix=/usr --enable-shared --enable-static $(CROSS)
+	cd builddir && ../configure --prefix=/usr --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) --enable-shared --enable-static $(CROSS)
 
 	touch config-stamp
 

Bug#571408: microcode.ctl: Patch from Ubuntu

[Evan Broder]

Package: microcode.ctl
Version: 1.17-13.1
Followup-For: Bug #571408
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu precise ubuntu-patch

In Ubuntu, the attached patch was applied in addition to Stefano's
patch above fix the microcode JSON search URL being used, as it
changed again.

(https://bugs.launchpad.net/ubuntu/+source/microcode.ctl/+bug/891283)

Thanks for considering the patch.


-- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric'), (100, 'oneiric-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-13-generic (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
diff -u microcode.ctl-1.17/debian/update-intel-microcode microcode.ctl-1.17/debian/update-intel-microcode
--- microcode.ctl-1.17/debian/update-intel-microcode
+++ microcode.ctl-1.17/debian/update-intel-microcode
@@ -10,7 +10,8 @@
 import tarfile
 import urllib2
 
-url = 'http://downloadcenter.intel.com/JSONDataProvider.aspx?DownloadType=Firmware&ProductFamily=Processors&ProductLine=Desktop&ProductProduct=Intel%C2%AE%20Core%E2%84%A2%20i7%20Processor&sortDir=descending&Hits=10&&lang=eng&pg=1&refresh=filters&dataType=json&type=GET'
+url = 'http://downloadcenter.intel.com/JSONDataProvider.aspx?OSVersion=Linux*&DownloadType=Firmware&ProductFamily=Processors&ProductLine=Desktop&ProductProduct=Intel%C2%AE%20Core%E2%84%A2%20i7%20Desktop%20Processor&sortDir=descending&refresh=filters&dataType=json&type=GET'
+
 try:
 	data = urllib2.urlopen(url).read()
 except urllib2.HTTPError, e:
@@ -21,6 +22,7 @@
 	sys.exit(1)
 
 results = json.loads(data)['results']
+assert len(results), "no search results - microcode search URL needs updating"
 
 # check for numerically highest date
 newest = sorted(results, key=lambda x: x['version'])[-1]

Bug#650793: lintian: No way to suppress langpack-related package-contains-broken-symlink on Ubuntu

[Evan Broder]

Package: lintian
Version: 2.5.4
Severity: normal

Part of Ubuntu's package build process involves taking all localized
data for packages in our main component and separating it into
separate per-language "language packages" (or "langpacks"), such as
language-pack-en or language-pack-fr-base. This allows users to only
install the translations that they will use.

When we separate out the language data at build-time, we replace files
in /usr/share/help, /usr/share/gnome/help, /usr/share/omf with
symlinks to the same path in /usr/share/help-langpack,
/usr/share/gnome/help-langpack, etc. These -langpack files are
contained within our language pack packages, but are not directly
depended on.

As a result of this, when run across the Ubuntu archive, Lintian
current emits almost 29,000 instances of
package-contains-broken-symlink that match one of these translated
paths [1].

I'm not sure what the right solution here is, but my best idea is to
extend vendor profiles to support suppressing tags based on the
additional intian-info field, probably with wildcard matching. Such a
mechanism would also solve bug #649852.

[1] http://lintian.ubuntuwire.org/tags/package-contains-broken-symlink.html

Thanks,
 - Evan

-- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric'), (100, 'oneiric-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-13-generic (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

Versions of packages lintian depends on:
ii  binutils   2.21.53.20110810-0ubuntu5 The GNU assembler, linker and bina
ii  bzip2  1.0.5-6ubuntu1high-quality block-sorting file co
ii  diffstat   1.54-1produces graph of changes introduc
ii  file   5.04-5ubuntu3 Determines file type using "magic"
ii  gettext0.18.1.1-3ubuntu1 GNU Internationalization utilities
ii  intltool-debia 0.35.0+20060710.1 Help i18n of RFC822 compliant conf
ii  libapt-pkg-per 0.1.24build3  Perl interface to libapt-pkg
ii  libclass-acces 0.34-1Perl module that automatically gen
ii  libdpkg-perl   1.16.0.3ubuntu5   Dpkg perl modules
ii  libemail-valid 0.184-1   Perl module for checking the valid
ii  libipc-run-per 0.90-1Perl module for running processes
ii  libparse-debia 1.2.0-1ubuntu1parse Debian changelogs and output
ii  libtimedate-pe 1.2000-1  collection of modules to manipulat
ii  liburi-perl1.58-1module to manipulate and access UR
ii  locales2.13+git20110622-2common files for locale support
ii  man-db 2.6.0.2-2 on-line manual pager
ii  patchutils 0.3.2-1   Utilities to work with patches
ii  perl [libdiges 5.12.4-4  Larry Wall's Practical Extraction 
ii  unzip  6.0-4ubuntu1  De-archiver for .zip files

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch (no description available)
ii  dpkg-dev 1.16.0.3ubuntu5 Debian package development tools
ii  libhtml-parser-perl  3.68-1build1collection of modules that parse H
ii  libtext-template-perl1.45-2  Text::Template perl module
ii  man-db   2.6.0.2-2   on-line manual pager
ii  xz-utils 5.0.0-2 XZ-format compression utilities

-- no debconf information



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

Bug#650791: lintian: Lab does not update info when component of package changes

[Evan Broder]

Source: lintian
Version: 2.5.3ubuntu2
Usertags: origin-ubuntu precise

Ubuntu regularly moves (both source and binary) packages between
components in its repository (generally between main and universe). We
do not require a new upload or binNMU to do this move.

Since Lintian only re-processes a package when its version number
change, the cache about the package in the info/ section of a static
lab will be inaccurate until the package is updated. Because of this,
manual attempts to run lintian across the whole lab will error out.

-- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric'), (100, 'oneiric-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-13-generic (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

Versions of packages lintian depends on:
ii  binutils   2.21.53.20110810-0ubuntu5 The GNU assembler, linker and bina
ii  bzip2  1.0.5-6ubuntu1high-quality block-sorting file co
ii  diffstat   1.54-1produces graph of changes introduc
ii  file   5.04-5ubuntu3 Determines file type using "magic"
ii  gettext0.18.1.1-3ubuntu1 GNU Internationalization utilities
ii  intltool-debia 0.35.0+20060710.1 Help i18n of RFC822 compliant conf
ii  libapt-pkg-per 0.1.24build3  Perl interface to libapt-pkg
ii  libclass-acces 0.34-1Perl module that automatically gen
ii  libdpkg-perl   1.16.0.3ubuntu5   Dpkg perl modules
ii  libemail-valid 0.184-1   Perl module for checking the valid
ii  libipc-run-per 0.90-1Perl module for running processes
ii  libparse-debia 1.2.0-1ubuntu1parse Debian changelogs and output
ii  libtimedate-pe 1.2000-1  collection of modules to manipulat
ii  liburi-perl1.58-1module to manipulate and access UR
ii  locales2.13+git20110622-2common files for locale support
ii  man-db 2.6.0.2-2 on-line manual pager
ii  patchutils 0.3.2-1   Utilities to work with patches
ii  perl [libdiges 5.12.4-4  Larry Wall's Practical Extraction 
ii  unzip  6.0-4ubuntu1  De-archiver for .zip files

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch (no description available)
ii  dpkg-dev 1.16.0.3ubuntu5 Debian package development tools
ii  libhtml-parser-perl  3.68-1build1collection of modules that parse H
ii  libtext-template-perl1.45-2  Text::Template perl module
ii  man-db   2.6.0.2-2   on-line manual pager
ii  xz-utils 5.0.0-2 XZ-format compression utilities

-- no debconf information



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

Bug#602249: [PATCH] Added check for maintscript-helper in preinst without dpkg Pre-Depends

[Evan Broder]

tags 602249 patch
thanks

I've attached a patch which checks for use of dpkg-maintscript-helper
in preinst scripts in the same manner as existing checks for tools
like gconf-schemas. I marked it as severity pedantic for Debian, but
with a profile change for Ubuntu to make it serious (as this can
impact Ubuntu 10.04 -> 12.04 upgrades)

The check is marked as certainty: possible because the check will
match uses of maintscript-helper which are safely guarded in a
"maintscript-helper supports" conditional, but because of the impact
to Ubuntu, it seems better to have a check with false positives than
none at all.

Thanks,
 - Evan
From fc261862e08341adc824441da3056db94726127d Mon Sep 17 00:00:00 2001
From: Evan Broder 
Date: Fri, 2 Dec 2011 15:32:44 -0800
Subject: [PATCH] Added check for maintscript-helper in preinst without dpkg
 Pre-Depends

dpkg in Squeeze is new enough that this is not strictly necessary,
making this pedantic in Debian. However, dpkg in Lucid does not have
dpkg-maintscript-helper, making this serious as it could break the
upgrade path.

Signed-off-by: Evan Broder 
---
 checks/scripts   |6 ++
 checks/scripts.desc  |8 
 profiles/ubuntu/main.profile |3 ++-
 3 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/checks/scripts b/checks/scripts
index 46bc373..0918cb4 100644
--- a/checks/scripts
+++ b/checks/scripts
@@ -886,6 +886,12 @@ while () {
 if (m,\bsuidregister\b,) {
 tag 'suidregister-used-in-maintainer-script', $file;
 }
+if ($file eq 'preinst') {
+if (m/^\s*dpkg-maintscript-helper(?:\s|\z)/ &&
+!$info->relation('pre-depends')->implies('dpkg (>= 1.15.7.2)')) {
+tag 'preinst-uses-dpkg-maintscript-helper-without-predepends', "$file:$.";
+}
+}
 if ($file eq 'postrm') {
 if (m,update\-alternatives \-\-remove,) {
 tag 'update-alternatives-remove-called-in-postrm';
diff --git a/checks/scripts.desc b/checks/scripts.desc
index 113e30c..b33a19b 100644
--- a/checks/scripts.desc
+++ b/checks/scripts.desc
@@ -154,6 +154,14 @@ Info: The package contains a preinst maintainer script that uses
  section 3.5).
 Ref: policy 7.2
 
+Tag: preinst-uses-dpkg-maintscript-helper-without-predepends
+Severity: pedantic
+Certainty: possible
+Info: The package contains a preinst maintainer script that
+ uses dpkg-maintscript-helper but does not declare a
+ pre-dependency on a version of dpkg that provides that
+ script.
+
 Tag: control-interpreter-without-depends
 Severity: serious
 Certainty: possible
diff --git a/profiles/ubuntu/main.profile b/profiles/ubuntu/main.profile
index 753fd36..fd84533 100644
--- a/profiles/ubuntu/main.profile
+++ b/profiles/ubuntu/main.profile
@@ -7,6 +7,7 @@ Disable-Tags: debian-changelog-file-is-a-symlink,
  upstart-job-in-etc-init.d-not-registered-via-update-rc.d
 
 # Serious as it may break Lucid upgrade path
-Tags: data.tar.xz-member-without-dpkg-pre-depends
+Tags: data.tar.xz-member-without-dpkg-pre-depends,
+ preinst-uses-dpkg-maintscript-helper-without-predepends
 Severity: serious
 
-- 
1.7.5.4

Bug#650712: lintian: [PATCH] Respect vendor profiles when generating HTML reports

[Evan Broder]

Package: lintian
Version: 2.5.3ubuntu2
Severity: normal

Currently Lintian does not look at vendor profiles at all when
generating HTML reports.

This patchset changes the html_reports script to look at the default
vendor profile instead of parsing the .desc files in checks on its
own. It's currently deployed at lintian.ubuntuwire.org (for instance,
http://lintian.ubuntuwire.org/tags/data.tar.xz-member-without-dpkg-pre-depends.html
correctly shows up as Severity: serious)

I'm not sure this patch is ideal in its current form, because it means
that if a tag were suppressed in the Debian profile, it wouldn't show
up on lintian.d.o at all, and I know several people who treat
lintian.d.o as an online repository of information about Lintian tags

It's also possible that the profile should be settable from
reporting/config.

Thanks,
 - Evan

-- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric'), (100, 'oneiric-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-13-generic (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

Versions of packages lintian depends on:
ii  binutils   2.21.53.20110810-0ubuntu5 The GNU assembler, linker and bina
ii  bzip2  1.0.5-6ubuntu1high-quality block-sorting file co
ii  diffstat   1.54-1produces graph of changes introduc
ii  file   5.04-5ubuntu3 Determines file type using "magic"
ii  gettext0.18.1.1-3ubuntu1 GNU Internationalization utilities
ii  intltool-debia 0.35.0+20060710.1 Help i18n of RFC822 compliant conf
ii  libapt-pkg-per 0.1.24build3  Perl interface to libapt-pkg
ii  libclass-acces 0.34-1Perl module that automatically gen
ii  libdpkg-perl   1.16.0.3ubuntu5   Dpkg perl modules
ii  libemail-valid 0.184-1   Perl module for checking the valid
ii  libipc-run-per 0.90-1Perl module for running processes
ii  libparse-debia 1.2.0-1ubuntu1parse Debian changelogs and output
ii  libtimedate-pe 1.2000-1  collection of modules to manipulat
ii  liburi-perl1.58-1module to manipulate and access UR
ii  locales2.13+git20110622-2common files for locale support
ii  man-db 2.6.0.2-2 on-line manual pager
ii  patchutils 0.3.2-1   Utilities to work with patches
ii  perl [libdiges 5.12.4-4  Larry Wall's Practical Extraction 
ii  unzip  6.0-4ubuntu1  De-archiver for .zip files

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch (no description available)
ii  dpkg-dev 1.16.0.3ubuntu5 Debian package development tools
ii  libhtml-parser-perl  3.68-1build1collection of modules that parse H
ii  libtext-template-perl1.45-2  Text::Template perl module
ii  man-db   2.6.0.2-2   on-line manual pager
ii  xz-utils 5.0.0-2 XZ-format compression utilities

-- no debconf information
>From 8f16f3a76717eff9ab4730a632f57dfbf3bb2eb8 Mon Sep 17 00:00:00 2001
From: Evan Broder 
Date: Fri, 2 Dec 2011 00:18:08 -0800
Subject: [PATCH 1/2] Always use the effective severity in a tag's long-form
 description

Signed-off-by: Evan Broder 
---
 lib/Lintian/Tag/Info.pm |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/Lintian/Tag/Info.pm b/lib/Lintian/Tag/Info.pm
index ff2b269..5f871c7 100644
--- a/lib/Lintian/Tag/Info.pm
+++ b/lib/Lintian/Tag/Info.pm
@@ -283,9 +283,9 @@ sub description {
 if ($self->{ref}) {
 push(@text, '', _format_reference($self->{ref}));
 }
-if ($self->{severity} and $self->{certainty}) {
-my $severity = $self->{severity};
-my $certainty = $self->{certainty};
+if ($self->severity and $self->certainty) {
+my $severity = $self->severity;
+my $certainty = $self->certainty;
 push(@text, '', "Severity: $severity, Certainty: $certainty");
 }
     if ($self->{script} and $self->{'script-type'}){
-- 
1.7.5.4

>From 4c70e2c05cf003e6bc332ad3c663c429d42eeefe Mon Sep 17 00:00:00 2001
From: Evan Broder 
Date: Fri, 2 Dec 2011 00:18:47 -0800
Subject: [PATCH 2/2] Use profile information about tags in HTML reports

instead of parsing the tag descriptions independently.

Signed-off-by: Evan Broder 
---
 reporting/html_reports |   25 -
 1 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/reporting/html_reports b/reporting/html_reports
index 5815434..a16f0de 100755
--- a/reporting/html_report

Bug#650710: lintian: please check for dpkg-maintscript-helper in preinst without pre-depends: dpkg (>= 1.15.7.2)

[Evan Broder]

Package: lintian
Version: 2.5.4
Severity: wishlist

dpkg-maintscript-helper was introduced in dpkg 1.15.7.2, and that
version is required to use the dpkg-maintscript-helper mv_conffile and
rm_conffile subcommands.

The dpkg-maintscript-helper manpage recommends setting Pre-Depends:
dpkg (>= 1.15.7.2) in packages which use these features in the
preinst. However, since Squeeze released with a newer version than
that (1.15.8.11), this Pre-Depends is not strictly needed to upgrade
from Squeeze to Wheezy.

On the other hand, Ubuntu's last LTS (10.04 or Lucid) released with
dpkg 1.15.5.6, and does not include dpkg-maintscript helper, which
means that the Pre-Depends is necessary on Ubuntu to ensure a safe
upgrade from 10.04 to our next LTS, 12.04 (Precise)

It would be helpful of Lintian could catch preinsts using
dpkg-maintscript-helper without also setting the Pre-Depends.

As with bug #648350, this should be severity: serious for Ubuntu,
though I can't imagine a static analysis check that would have high
certainty, so it will probably have to be certainty: possible.

Thanks,
 - Evan

-- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric'), (100, 'oneiric-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-13-generic (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

Versions of packages lintian depends on:
ii  binutils   2.21.53.20110810-0ubuntu5 The GNU assembler, linker and bina
ii  bzip2  1.0.5-6ubuntu1high-quality block-sorting file co
ii  diffstat   1.54-1produces graph of changes introduc
ii  file   5.04-5ubuntu3 Determines file type using "magic"
ii  gettext0.18.1.1-3ubuntu1 GNU Internationalization utilities
ii  intltool-debia 0.35.0+20060710.1 Help i18n of RFC822 compliant conf
ii  libapt-pkg-per 0.1.24build3  Perl interface to libapt-pkg
ii  libclass-acces 0.34-1Perl module that automatically gen
ii  libdpkg-perl   1.16.0.3ubuntu5   Dpkg perl modules
ii  libemail-valid 0.184-1   Perl module for checking the valid
ii  libipc-run-per 0.90-1Perl module for running processes
ii  libparse-debia 1.2.0-1ubuntu1parse Debian changelogs and output
ii  libtimedate-pe 1.2000-1  collection of modules to manipulat
ii  liburi-perl1.58-1module to manipulate and access UR
ii  locales2.13+git20110622-2common files for locale support
ii  man-db 2.6.0.2-2 on-line manual pager
ii  patchutils 0.3.2-1   Utilities to work with patches
ii  perl [libdiges 5.12.4-4  Larry Wall's Practical Extraction 
ii  unzip  6.0-4ubuntu1  De-archiver for .zip files

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch (no description available)
ii  dpkg-dev 1.16.0.3ubuntu5 Debian package development tools
ii  libhtml-parser-perl  3.68-1build1collection of modules that parse H
ii  libtext-template-perl1.45-2  Text::Template perl module
ii  man-db   2.6.0.2-2   on-line manual pager
ii  xz-utils 5.0.0-2 XZ-format compression utilities

-- no debconf information



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

Bug#650701: [PATCH] Check git and debian/changelog before showing dummy version number

[Evan Broder]

Source: lintian
Version: 2.5.4
Severity: wishlist

Currently Lintian has a placeholder version number ("") which
gets replaced at build time. However, things like the lintian.d.o
harness run from source checkouts. Without manual cleanup, they will
keep showing the dummy number.

If the version number hasn't been substituted in, this patch checks
for a more authoritative version number, first trying git-describe,
and then the debian/changelog, and finally printing "" only
if neither of the other two pan out.

-- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric'), (100, 'oneiric-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-13-generic (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

Versions of packages lintian depends on:
ii  binutils   2.21.53.20110810-0ubuntu5 The GNU assembler, linker and bina
ii  bzip2  1.0.5-6ubuntu1high-quality block-sorting file co
ii  diffstat   1.54-1produces graph of changes introduc
ii  file   5.04-5ubuntu3 Determines file type using "magic"
ii  gettext0.18.1.1-3ubuntu1 GNU Internationalization utilities
ii  intltool-debia 0.35.0+20060710.1 Help i18n of RFC822 compliant conf
ii  libapt-pkg-per 0.1.24build3  Perl interface to libapt-pkg
ii  libclass-acces 0.34-1Perl module that automatically gen
ii  libdpkg-perl   1.16.0.3ubuntu5   Dpkg perl modules
ii  libemail-valid 0.184-1   Perl module for checking the valid
ii  libipc-run-per 0.90-1Perl module for running processes
ii  libparse-debia 1.2.0-1ubuntu1parse Debian changelogs and output
ii  libtimedate-pe 1.2000-1  collection of modules to manipulat
ii  liburi-perl1.58-1module to manipulate and access UR
ii  locales2.13+git20110622-2common files for locale support
ii  man-db 2.6.0.2-2 on-line manual pager
ii  patchutils 0.3.2-1   Utilities to work with patches
ii  perl [libdiges 5.12.4-4  Larry Wall's Practical Extraction 
ii  unzip  6.0-4ubuntu1  De-archiver for .zip files

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch (no description available)
ii  dpkg-dev 1.16.0.3ubuntu5 Debian package development tools
ii  libhtml-parser-perl  3.68-1build1collection of modules that parse H
ii  libtext-template-perl1.45-2  Text::Template perl module
ii  man-db   2.6.0.2-2   on-line manual pager
ii  xz-utils 5.0.0-2 XZ-format compression utilities

-- no debconf information
>From 4332ec8f449562df13079f0b8f408a90a0b7d1bc Mon Sep 17 00:00:00 2001
From: Evan Broder 
Date: Thu, 1 Dec 2011 20:59:57 -0800
Subject: [PATCH] Check git and debian/changelog before showing dummy version
 number

This should ensure that lintian --version prints out something
reasonable if it's run from a source tree.

Signed-off-by: Evan Broder 
---
 debian/rules |2 +-
 frontend/lintian |   15 ++-
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index feaaf11..a1aafb9 100755
--- a/debian/rules
+++ b/debian/rules
@@ -97,7 +97,7 @@ binary-indep: $(neededfiles) build
 
 	dh_install
 # some manual work
-	sed -i 's//$(VER)/' $(tmp)/usr/bin/lintian
+	sed -i 's/my $$LINTIAN_VERSION = ""/my $$LINTIAN_VERSION = "$(VER)"/' $(tmp)/usr/bin/lintian
 	install -m 644 doc/lintianrc.example $(tmp)/etc/lintianrc
 	dh_installdocs
 	dh_installchangelogs
diff --git a/frontend/lintian b/frontend/lintian
index 8e2b64c..f054618 100755
--- a/frontend/lintian
+++ b/frontend/lintian
@@ -26,6 +26,9 @@ use strict;
 use warnings;
 
 use Getopt::Long;
+use File::Basename;
+use IPC::Run;
+use Parse::DebianChangelog;
 
 # }}}
 
@@ -73,7 +76,17 @@ qw(
 ### "Normal" application variables
 
 # Version number - Is replaced during build with sed, see d/rules
-my $LINTIAN_VERSION = '';  #External Version number
+my $LINTIAN_VERSION = "";  #External Version number
+if ( $LINTIAN_VERSION eq '' && -d dirname(__FILE__) . "/../.git" ) {
+IPC::Run::run ["git", "--git-dir=" . dirname(__FILE__) . "/../.git", "describe"], \
+undef, \$LINTIAN_VERSION;
+chomp $LINTIAN_VERSION;
+}
+if ( $LINTIAN_VERSION eq '' && -f dirname(__FILE__) . "/../debian/changelog" ) {
+my $changelog = Parse::DebianChangelog->init({ infile => dirname(__F

Bug#633273: Patch for bug #633273

[Evan Broder]

tag 633273 patch
thanks

Hi -
   I've prepared an NMU which will remove the unneeded .la file. It
looks like the intent was to use a post-install/% hook target, however
no such target exists that I can find, and binary-post-install/% was
too late (the files must be cleaned up before dh_pycentral is called)

I've switched it to use the install/% hook instead.

Additionally, I modified it to only remove the .la file, and not the
glade or so files, as both of those are needed in order to
successfully run the examples. And I dropped the build-dependency on
libxcb-render-util0-dev that was added in the last NMU, as
python-visual doesn't use that library directly and it currently
builds fine without it.

Thanks,
 - Evan


python-visual_5.12-1.3.debdiff
Description: Binary data

Bug#650355: Please upgrade gedit-latex-plugin to 3.3.2

[Evan Broder]

Package: gedit-latex-plugin
Version: 3.3.1-1
Severity: wishlist

gedit-latex-plugin 3.3.1 uses the deprecated gnome-open program for
opening files. Upstream adjusted this to use gvfs-open instead ([1],
[2]) and released this as 3.3.2.

(Please be sure to include a dependency on gvfs-bin; the current
version does not depend on libgnome2-0, which provides gnome-open,
which is why this issue was discovered in the first place)

Thanks,
 - Evan

[1] 
http://git.gnome.org/browse/gedit-latex/commit/?id=4166f494ca26e1ef0540652fc1658e9dc31e6a0d
[2] https://bugzilla.gnome.org/show_bug.cgi?id=661076

-- System Information:
Debian Release: wheezy/sid
  APT prefers oneiric-updates
  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
'oneiric'), (100, 'oneiric-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-13-generic (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



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