Bug#1072771: kdevelop: symbol lookup error

[Tom Marshall]

Package: kdevelop
Version: 4:23.08.1-2+b2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: tommyi...@yahoo.com

Dear Maintainer,

The most recent update to kdevelop (I believe around May 21st) makes this
program fail to start. I get the following error and then it exits:
kdevelop: symbol lookup error: /lib/x86_64-linux-gnu/libQt5Quick.so.5:
undefined symbol:
_ZN18QTextureGlyphCache8populateEP11QFontEngineiPKjPK11QFixedPointb, version
Qt_5_PRIVATE_API

I've uninstalled and then reinstalled everything that was related to qt5 and
qt6, but no difference.

Also, when I try running kate, nothing happens. It just doesn't do anything. So
it might be a QT issue.


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

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

Versions of packages kdevelop depends on:
ii  kdevelop-data 4:23.08.1-2
ii  kdevelop512-libs  4:23.08.1-2+b2
ii  kinit 5.115.0-2
ii  kio   5.115.0-6
ii  libapr1t641.7.2-3.2
ii  libaprutil1t641.6.3-2
ii  libastyle33.1-3+b1
ii  libc6 2.38-12
ii  libclang1-16t64   1:16.0.6-27
ii  libgcc-s1 14-20240330-1
ii  libgrantlee-templates5 [grantlee5-templates-5-3]  5.3.1-3+b2
ii  libkasten4controllers05:0.26.15-1+b1
ii  libkasten4core0   5:0.26.15-1+b1
ii  libkasten4okteta2controllers0 5:0.26.15-1+b1
ii  libkasten4okteta2core05:0.26.15-1+b1
ii  libkasten4okteta2gui0 5:0.26.15-1+b1
ii  libkf5archive55.115.0-2
ii  libkf5bookmarks5  5.115.0-2
ii  libkf5codecs5 5.115.0-2
ii  libkf5completion5 5.115.0-2
ii  libkf5configcore5 5.115.0-2
ii  libkf5configgui5  5.115.0-2
ii  libkf5configwidgets5  5.115.0-2
ii  libkf5coreaddons5 5.115.0-2
ii  libkf5crash5  5.115.0-2
ii  libkf5declarative55.115.0-3
ii  libkf5guiaddons5  5.115.0-2
ii  libkf5i18n5   5.115.1-2+b1
ii  libkf5iconthemes5 5.115.0-2+b1
ii  libkf5itemmodels5 5.115.0-2
ii  libkf5itemviews5  5.115.0-2
ii  libkf5jobwidgets5 5.115.0-2
ii  libkf5kiocore55.115.0-6
ii  libkf5kiofilewidgets5 5.115.0-6
ii  libkf5kiogui5 5.115.0-6
ii  libkf5kiowidgets5 5.115.0-6
ii  libkf5newstuffcore5   5.115.0-2
ii  libkf5newstuffwidgets55.115.0-2
ii  libkf5parts5  5.115.0-2
ii  libkf5purpose-bin 5.115.0-2
ii  libkf5purpose55.115.0-2
ii  libkf5service-bin 5.115.0-2
ii  libkf5service55.115.0-2
ii  libkf5sonnetui5   5.115.0-2
ii  libkf5texteditor5 5.115.0-3
ii  libkf5textwidgets55.115.0-2
ii  libkf5threadweaver5   5.115.0-2
ii  libkf5widgetsaddons5  5.115.0-2
ii  libkf5xmlgui5 5.115.0-2+b1
ii  libkomparediff2-5 4:22.12.3-1+b1
ii  libokteta3core0   5:0.26.15-1+b1
ii  libokteta3gui05:0.26.15-1+b1
ii  libprocesscore9   4:5.27.11-1
ii  libprocessui9 4:5.27.11-1
ii  libqt5core5t645.15.13+dfsg-2
ii  libqt5dbus5t645.15.13+dfsg-2
ii  libqt5gui5t64 5.15.13+dfsg-2
ii  libqt5help5   5.15.13-3
ii  libqt5network5t64 5.15.13+dfsg-2
ii  libqt5qml5 

Bug#1063746: Upload request for golang-github-katalix-go-l2tp 0.1.7-1

[Tom Parkin]

On  Tue, Feb 20, 2024 at 10:54:04 +0100, Simon Josefsson wrote:
> Tom Parkin  writes:
> 
> > Hi folks,
> >
> > Would someone mind please reviewing and uploading
> > golang-github-katalix-go-l2tp 0.1.7-1?
> >
> > https://salsa.debian.org/go-team/packages/golang-github-katalix-go-l2tp
> 
> Looks good, although there were no tag for the previous Debian upload so
> diffing changes was a bit difficult.  Do you still have the 0.1.6-2 tag
> locally?  If so would be good if you could push that.  Uploaded anyway,
> and I forgot to add a 'New upstream release' changelog entry, although
> that should be pretty obvious from the version number anyway.

Thanks Simon, much appreciated.

In re: tags -- I'm not quite sure what's going on here.  Nilesh tagged
0.1.6-2 I believe: I did have the tag in my repo although how I'd have
it without it going via. salsa I'm not sure.

Anyway, here it is:

https://salsa.debian.org/go-team/packages/golang-github-katalix-go-l2tp/-/tags/debian%2F0.1.6-2

All the best,
Tom


signature.asc
Description: PGP signature

Bug#1063746: Upload request for golang-github-katalix-go-l2tp 0.1.7-1

[Tom Parkin]

Hi folks,

Would someone mind please reviewing and uploading
golang-github-katalix-go-l2tp 0.1.7-1?

https://salsa.debian.org/go-team/packages/golang-github-katalix-go-l2tp

The package is updated to remove the L2TPIP6 transport test, which is
failing due to the backport of an upstream kernel regression to the
stable kernel which at least Debian Bookworm is running.

Once we have a fix for the kernel regression we can re-enable the unit
test, but for the time being removing the test is the most direct
approach for addressing the CI failures captured by #1063746.

Thanks and best regards,
Tom
-- 
Tom Parkin
Katalix Systems Ltd
https://katalix.com
Catalysts for your Embedded Linux software development


signature.asc
Description: PGP signature

Bug#1063746: (no subject)

[Tom Parkin]

I believe the root cause of this issue is this backported kernel
commit:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/net/l2tp/l2tp_ip6.c?h=linux-6.1.y=f6a7182179c0ed788e3755ee2ed18c888ddcc33f

The commit is present from Linux v6.6 onwards and has been backported
to at least the linux-6.1.y series stable kernels.

I will work on a kernel fix, but in the meantime the go-l2tp package
will have to remove the testcase in order to address this bug.


signature.asc
Description: PGP signature

Bug#1034328: timeshift with btrfs on LUKS encrypted filesystem and sysvinit does not work

[Tom]

Subject: timeshift with btrfs on LUKS encrypted filesystem and/or 
sysvinit/runit does not work.
Package: timeshift
X-Debbugs-Cc: n...@ambag.es
Version: 20.11.1-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

timeshift is working with btrfs, when it is not encrypted with LUKS and 
sysvinit.
But with an encrypted drive, timeshift does work not with my BTRFS-filesystem
with sysvinit. There is only a warning, that the system-drive is not found.

Here some Infos about the system:

~# cat /etc/fstab
UUID=779a1789-d53f-4882-bdcc-36e142fc482a / btrfs rw,noatime,subvol=@ 0 1
UUID=cbc12706-9f45-452f-9d0d-4cfef99e8042 /boot ext4 defaults,noatime 0 2
UUID=779a1789-d53f-4882-bdcc-36e142fc482a /home btrfs rw,noatime,subvol=@home 0 
2
UUID=779a1789-d53f-4882-bdcc-36e142fc482a /.snapshots btrfs 
rw,noatime,subvol=@snapshots 0 2
tmpfs /tmp tmpfs defaults,nosuid,nodev 0 0

~# btrfs subvolume list /
ID 256 gen 8874 top level 5 path @
ID 262 gen 8765 top level 5 path @home
ID 263 gen 8752 top level 5 path @snapshots

~# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs 
(rw,nosuid,relatime,size=1993068k,nr_inodes=498267,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=600,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=402388k,mode=755)
/dev/mapper/sda2_crypt on / type btrfs 
(rw,noatime,space_cache,subvolid=256,subvol=/@)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
securityfs on /sys/kernel/security type securityfs (rw,relatime)
pstore on /sys/fs/pstore type pstore (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=804760k)
/dev/sda1 on /boot type ext4 (rw,noatime)
/dev/mapper/sda2_crypt on /home type btrfs 
(rw,noatime,space_cache,subvolid=262,subvol=/@home)
/dev/mapper/sda2_crypt on /.snapshots type btrfs 
(rw,noatime,space_cache,subvolid=263,subvol=/@snapshots)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
cgroup2 on /sys/fs/cgroup type cgroup2 
(rw,nosuid,nodev,noexec,relatime,nsdelegate)
tmpfs on /run/user/0 type tmpfs 
(rw,nosuid,nodev,relatime,size=402384k,nr_inodes=100596,mode=700)
tmpfs on /run/user/1000 type tmpfs 
(rw,nosuid,nodev,relatime,size=402384k,nr_inodes=100596,mode=700,uid=1000,gid=1000)


~# timeshift --check
E: System disk not found!

~# timeshift --debug
D: Main()
D: 
D: Running Timeshift v20.11.1
D: 
D: Session log file: /var/log/timeshift/2023-04-13_04-55-20_.log
D: Distribution: debian "11"
D: DIST_ID: debian
D: Main: check_dependencies()
D: Main: add_default_exclude_entries()
D: Main: add_default_exclude_entries(): exit
D: update_partitions()
D: df -T -B1
D: Device: get_disk_space_using_df(): 1
D: Device: get_mounted_filesystems_using_mtab(): 1
D: Device: get_filesystems(): 5
D: partition list updated
D: detect_system_devices()
D: /boot is mapped to device: /dev/sda1, 
UUID=cbc12706-9f45-452f-9d0d-4cfef99e8042
D: Searching subvolume for system at path: /
D: Found subvolume: @, on device: 
D: Found subvolume: @home, on device: 
D: Found subvolume: @snapshots, on device: 
D: Users: tom root
D: Encrypted home users: 
D: Encrypted home dirs:

D: Encrypted private dirs:

D: Main: load_app_config()
App config loaded: /etc/timeshift/timeshift.json
D: IconManager: init()
D: bin_path: /usr/bin/timeshift
D: found images directory: /usr/share/timeshift/images
D: Main(): ok
D: AppConsole: parse_arguments()
D: Main: initialize_repo()
D: backup_uuid=
D: backup_parent_uuid=
D: Setting snapshot device from config file
D: Main: initialize_repo(): exit
D: AppConsole: start_application()
D: exit_app()
D: Main: save_app_config()
D: SnapshotRepo: available()
D: device is null
D: is_available: false
App config saved: /etc/timeshift/timeshift.json
D: unmount_target_device()
D: clean_logs()
D: rm -rf '/tmp/8N47lEDL'



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

Kernel: Linux 5.10.0-20-amd64 (SMP w/2 CPU threads)
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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages timeshift depends on:
ii  libc62.31-13+deb11u5
ii  libcairo21.16.0-5
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1+deb11u1
ii  libgee-0.8-2 0.20.4-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4+deb11u2
ii  libjson-glib-1.0-0   1.6.2-1
ii  libvte-2.91-00.62.3-1
ii  psmisc   23.4-2
ii  rsync3.2.3-4+deb11u1

timeshift recommends no packages.

timeshift suggests no packages.

-- no debconf information


-- 

Bug#1017944: grub-xen-host: 2.06-3 crashes PV guests in early boot

[Tom Lew]

On Tue, 6 Sep 2022 15:55:39 +0200 Valentin Kleibel wrote:

found 1017944 grub2/2.06-3~deb11u1
severity 1017944 serious
tags 1017944 patch

Dear Maintainers,

We can confirm that this bug affects all pv and pvh domUs that use 
pvgrub.
The commit responsible is 20239c28 "Bump debhelper from old 10 to 13." 
[1]

...


Cheers,
Valentin

[1]
https://salsa.debian.org/grub-team/grub/-/commit/20239c28e1e9ca3eba993e7702f5cb4da81dcf95


As yet another victim of this bug on bullseye/stable, I built grub2
package with this proposed patch, and I confirm the patched
grub2 2.06-3~deb11u1 packages fix the bug on a Xen server we
upgraded from 11.4 to 11.5 yesterday, where all PV/PVH domains
didn't start after reboot. Both hypervisor reboot (with autostart
domUs) and starting individual domU are all fine with the patched
grub2 packages.

I also vote for raising severity of this bug to "critical". Current
Debian 11.5 grub-xen-host package breaks all Xen PV/PVH domain boot
attemps.

Bug#1017698: Acknowledgement (emacsen-common: core dump with unsorted double linked list corrupted)

[Tom Overlund]

I also got a segfault on upgrading to emacs 28.1. I fixed it by installing the 
emacs-el package -- which is 
recommended, but I default install all packages without recommends. Apparently 
this has something to do with 
native compilation, which requires the el source files:

https://github.com/kelleyk/ppa-emacs/issues/23

emacs-el should be changed from recommended to a hard dependency.

Bug#1005011: lots of missing entries in debian/copyright

[Tom Lee]

Tony, without commenting on severity and policy concerns I'm happy to have
a first stab at this if you like.

And seconding Tony, thank you for the detailed review Thorsten!

On Sat, Feb 5, 2022 at 8:51 AM tony mancill  wrote:

> On Sat, Feb 05, 2022 at 12:08:03PM +, Thorsten Alteholz wrote:
> > Package: capnproto
> > please rework your debian/copyright. Especially
>
> Hi Thorsten,
>
> In my previous response, I neglected to say thank you for the thorough
> review of the package and its debian/copyright.  Thank you for the
> effort and detail you put into these reviews!
>
> Regards,
> tony
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]

[Tom Russo]

Then the git sha displayed in Xastir will be the git sha in your package
repo.  That is probably OK, though, and will accurately reflect its status
in your package management system.

If you want the About box to have the SHA-1 in our repo, you should just
hack XastirGitStamp to display our SHA-1 instead of using git to probe for it,
or have it return nothing at all.  You're already patching our stuff to fit
in with your choices, this should be no big deal.

The feature is in place to allow our power users (all of whom build from source
themselves and don't use packaged versions) to see what version of the code
they're actually using based on their git SHAs.  It's gonna stay there.


On Sun, Feb 23, 2020 at 08:32:57PM +0100, we recorded a bogon-computron 
collision of the  flavor, containing:
> Re: Tom Russo 2020-02-23 <20200223182310.ga7...@bogodyn.org>
> > The script looks in the top level of the Xastir source tree being built
> > for the presence of a .git directory.  The fact that the source tree is 
> > under
> > a package directory that is itself in git should have no impact (there will
> > then be a .git directory at a higher level, and our script will simply 
> > be unaware of it and return no SHA at all).
> 
> In the packaging repo, xastir is in the top level directory.
> 
> https://salsa.debian.org/debian-hamradio-team/xastir
> 
> Christoph

-- 
Tom RussoKM5VY
Tijeras, NM  

 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]

Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]

[Tom Russo]

BTW, since you have chosen to use a snapshot rather than a release, you might
want a later snapshot than the commit bb66a77 you're using.  Commit f89c610 
(29 Dec 2019) fixed a serious bug in weather alert parsing that had been 
introduced in commit aafbc49 (9 May 2019) and which still exists in the one 
you're using.  Without that fix, weather alerts were basically broken and were 
showing up scrambled in the weather alerts dialog.

After that, commits c61e49b and 64890aa are recommended as well, as the former
fixes broken builds under GCC 10, and the latter updates the get-nws script
to cope with recent changes in the server from which NWS shapefiles are 
downloaded (the most frequent change we have at this point).

These three commits are the only substantive changes to the development branch
since the bb66a7 commit you're currently using, but there are other, less
consequential changes.  If you move to today's master branch, you're probably 
a lot better off than sticking to that earlier one.

We had intended a 2.2.0 release some time ago, but all of the developers are
pretty much committed to other things at the moment (ranging from "work for a
living" to "recover from a serious accident").  Using the development snapshot
might not be the ideal option, but it's all there is at the moment.  If 
you're not going to use 2.1.4 for the package, you should probably use the most
recent development branch state (which is, at the moment, stable and functional)
and keep an eye on development for serious bug fixes that show up.

On Sun, Feb 23, 2020 at 10:29:38AM -0800, we recorded a bogon-computron 
collision of the  flavor, containing:
> Hi Tom,
> 
> My apologies for the issues the patch to AC_INIT caused with TOCALL and
> thank you for the explanation of versioning semantics.  It was a bad
> assumption on my part, carried over from $dayjob, when I didn't see a
> release tag for 2.1.5 in the repo.  100% my mistake.
> 
> Also, thank you to Iain for the identifying and addressing the bug in
> Debian source package, which will now report 2.1.5 in the Help->About
> dialog.
> 
> Regards,
> tony
> 
> On Sun, Feb 23, 2020 at 10:45:51AM -0700, Tom Russo wrote:
> > This is a forwarded version of an email sent to the Xastir mailing list.
> > I am forwarding to you because you followed up to a different message on 
> > that 
> > list.
> > 
> > To answer your direct question, "Since we are
> > building from a snapshot - i.e., a version somewhere between 2.1.4 and
> > 2.1.5, is there a preference for which we use for configure?"
> > 
> > This is mistaken.  You are in fact using 2.1.5, which means 
> > "development version between 2.1.4.  and whatever our next release will be 
> > called."  Since this version number is used to construct the TOCALL,  the 
> > version number in AC_INIT should just be left at 2.1.5.
> > 
> > 2.1.5 will never be "released", and the presence of APX215 in the TOCALL
> > is supposed to say "this user is using a bleeding-edge version pulled
> > from git".  Our next release will get a version number bump.
> > 
> > The Xastir build system tries to construct a useful Version string to 
> > display
> > in the Help->About and also to print when Xastir is invoked with "-V", but
> > this trick only works if the code is being built from a git clone (it 
> > sticks 
> > the current SHA-1 into the version displayed in these places, but does NOT
> > screw up the TOCALL).  That won't work if you're building the Debian package
> > out of a tarball (the trick involves looking for a .git directory, and if 
> > found, invoking a git log command to get the current SHA-1).
> > 
> > - Forwarded message from Tom Russo  -
> > 
> > Date: Sun, 23 Feb 2020 10:26:41 -0700
> > From: Tom Russo 
> > To: Xastir - APRS client software discussion 
> > Subject: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to
> > malformed TOCALL
> > 
> > Xastir's versions are goofy.  The history of this is ancient, and there has 
> > been no reason to ungoof it.
> > 
> > Even numbers are releases, odd numbers are working development versions,
> > and are generally not updated for every commit --- Xastir 2.1.5 just means
> > "development branch after stable 2.1.4".
> > 
> > The TOCALL for the current development version of Xastir should be APX215,
> > and there should be no need for finer granularity to show which commit on
> > every transmit.  The ambiguity of "which commit of the dev branch am I 
> > using?"
> > is resolved using the Help->About box.  This can only matter to the user 
&

Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]

[Tom Russo]

The script looks in the top level of the Xastir source tree being built
for the presence of a .git directory.  The fact that the source tree is under
a package directory that is itself in git should have no impact (there will
then be a .git directory at a higher level, and our script will simply 
be unaware of it and return no SHA at all).

Our set up has been designed to work under the normal assumption that package
maintainers aren't using snapshots, and only will use formal releases (an
assumption that has held up for as long as Xastir has existed).  It has
always been assumed that anyone using the development branch is a power
user building it themselves.

On Sun, Feb 23, 2020 at 07:14:59PM +0100, we recorded a bogon-computron 
collision of the  flavor, containing:
> Re: Tom Russo 2020-02-23 <20200223174551.gd5...@bogodyn.org>
> > That won't work if you're building the Debian package
> > out of a tarball (the trick involves looking for a .git directory, and if 
> > found, invoking a git log command to get the current SHA-1).
> 
> Fwiw, these tricks are often a PITA for package maintainers, because
> we keep the packaging also in a git repository, but that one doesn't
> have any (git) connection to the upstream xastir.git.
> 
> In many cases, we have to patch the build system not to do these
> tricks. (Generally, I didn't check if the variant used in xastir is
> problematic.)
> 
> Christoph

-- 
Tom RussoKM5VY
Tijeras, NM  

 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]

Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]

[Tom Russo]

This is a forwarded version of an email sent to the Xastir mailing list.
I am forwarding to you because you followed up to a different message on that 
list.

To answer your direct question, "Since we are
building from a snapshot - i.e., a version somewhere between 2.1.4 and
2.1.5, is there a preference for which we use for configure?"

This is mistaken.  You are in fact using 2.1.5, which means 
"development version between 2.1.4.  and whatever our next release will be 
called."  Since this version number is used to construct the TOCALL,  the 
version number in AC_INIT should just be left at 2.1.5.

2.1.5 will never be "released", and the presence of APX215 in the TOCALL
is supposed to say "this user is using a bleeding-edge version pulled
from git".  Our next release will get a version number bump.

The Xastir build system tries to construct a useful Version string to display
in the Help->About and also to print when Xastir is invoked with "-V", but
this trick only works if the code is being built from a git clone (it sticks 
the current SHA-1 into the version displayed in these places, but does NOT
screw up the TOCALL).  That won't work if you're building the Debian package
out of a tarball (the trick involves looking for a .git directory, and if 
found, invoking a git log command to get the current SHA-1).

- Forwarded message from Tom Russo  -

Date: Sun, 23 Feb 2020 10:26:41 -0700
From: Tom Russo 
To: Xastir - APRS client software discussion 
Subject: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to
malformed TOCALL

Xastir's versions are goofy.  The history of this is ancient, and there has 
been no reason to ungoof it.

Even numbers are releases, odd numbers are working development versions,
and are generally not updated for every commit --- Xastir 2.1.5 just means
"development branch after stable 2.1.4".

The TOCALL for the current development version of Xastir should be APX215,
and there should be no need for finer granularity to show which commit on
every transmit.  The ambiguity of "which commit of the dev branch am I using?"
is resolved using the Help->About box.  This can only matter to the user him/her
self, and need not be transmitted in every packet.  A TOCALL of APX215 should
be enough for all interested parties on the receive end.

If there is a need for a stable release so that distros can have a stable 
version, we should push one out.  There is an open project on github for our 
next release with a number of required fixes before we do it.  There was a 
flurry of activity on some of those issues a while back, but between people
being injured, having other projects, and what not, nothing's been done for
quite a while.

If there is a real need for a stable release, we could probably use a little
help.  The open issues that we expected to have fixed for the next release
(nominally dubbed Xastir 2.2.0) can be seen at:

https://github.com/Xastir/Xastir/projects/2

Some might need punting.

On Sun, Feb 23, 2020 at 08:56:54AM -0800, we recorded a bogon-computron 
collision of the  flavor, containing:
> 
> Hello Dave,
> 
> The scenario here seems to be if you're running an intermediate release
> Xastir and not an official tagged release.
> 
> Dave, yes, I see you on APRS-IS : https://aprs.fi/info/a/KB3EFS and it shows
> you're running v2.15 (APX215) per the "Last Path" line:
> 
>KB3EFS>*APX215* via TCPIP*,qAC,T2ONTARIO
> 
> 
> The question here is if you're running a version of Xastir that's between
> v2.15 and v2.16, what should Xastir report as it's version to APRS-IS?  It's
> not clear if it's illegal but maybe this would be legal:
> 
>APX21G
> 
> --David
> KI6ZHD
> 
> 
> 
> 
> On 02/23/2020 08:43 AM, David A Aitcheson wrote:
> > I did & was checking validity before making noise...
> > 
> > Given that I  only am able to be on APRS via an Internet connection
> > (read: no radio use allowed)...
> > 
> > Given that I only build from source (read: I don't use a package from a
> > repository)...
> > 
> > I think that it is not effecting me...
> > 
> > David KI6ZHD - can you see me ( "KB3EFS" ) on the map in NY State?
> > 
> > 73
> > Dave
> > KB3EFS
> 
> ___
> Xastir mailing list
> xas...@lists.xastir.org
> http://xastir.org/mailman/listinfo/xastir

-- 
Tom RussoKM5VY
Tijeras, NM  

 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]

___
Xastir mailing list
xas...@lists.xastir.org
http://xastir.org/mailman/listinfo/xastir

- End forwarded message -

-- 
Tom RussoKM5VY
Tijeras, NM  

 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]

Bug#952116: [ru...@bogodyn.org: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to malformed TOCALL]

[Tom Russo]

If there is a desire to build Xastir for debian from a tarball *AND* get the
git sha into the Help->About box and "xastir -V" output, one could patch
the script "scripts/XastirGitStamp.sh" so that it blindly inserts the SHA-1
you know to be relevant instead of asking Git to provide it.  This would be
safe to do in your packaging patches.

XastirGitStamp.sh is run by src/Makefile to construct the "compiledate.c"
file (which no longer contains the compile date, so that Xastir builds can
be reproducible, another request we got a year or so ago).  It takes a directory
as argument, and in its current form looks top see if that directory has
a .git directory.  If so, it runs git log to get the sha.  Simply rip out
that logic and echo a fixed SHA-1 and you should be able to accomplish what
you intended when you modified AC_INIT, but without breaking the TOCALL.


On Sun, Feb 23, 2020 at 10:45:51AM -0700, we recorded a bogon-computron 
collision of the  flavor, containing:
> This is a forwarded version of an email sent to the Xastir mailing list.
> I am forwarding to you because you followed up to a different message on that 
> list.
> 
> To answer your direct question, "Since we are
> building from a snapshot - i.e., a version somewhere between 2.1.4 and
> 2.1.5, is there a preference for which we use for configure?"
> 
> This is mistaken.  You are in fact using 2.1.5, which means 
> "development version between 2.1.4.  and whatever our next release will be 
> called."  Since this version number is used to construct the TOCALL,  the 
> version number in AC_INIT should just be left at 2.1.5.
> 
> 2.1.5 will never be "released", and the presence of APX215 in the TOCALL
> is supposed to say "this user is using a bleeding-edge version pulled
> from git".  Our next release will get a version number bump.
> 
> The Xastir build system tries to construct a useful Version string to display
> in the Help->About and also to print when Xastir is invoked with "-V", but
> this trick only works if the code is being built from a git clone (it sticks 
> the current SHA-1 into the version displayed in these places, but does NOT
> screw up the TOCALL).  That won't work if you're building the Debian package
> out of a tarball (the trick involves looking for a .git directory, and if 
> found, invoking a git log command to get the current SHA-1).
> 
> - Forwarded message from Tom Russo  -
> 
> Date: Sun, 23 Feb 2020 10:26:41 -0700
> From: Tom Russo 
> To: Xastir - APRS client software discussion 
> Subject: Re: [Xastir] Fwd: Bug#952116: xastir: Impossible to transmit due to
>   malformed TOCALL
> 
> Xastir's versions are goofy.  The history of this is ancient, and there has 
> been no reason to ungoof it.
> 
> Even numbers are releases, odd numbers are working development versions,
> and are generally not updated for every commit --- Xastir 2.1.5 just means
> "development branch after stable 2.1.4".
> 
> The TOCALL for the current development version of Xastir should be APX215,
> and there should be no need for finer granularity to show which commit on
> every transmit.  The ambiguity of "which commit of the dev branch am I using?"
> is resolved using the Help->About box.  This can only matter to the user 
> him/her
> self, and need not be transmitted in every packet.  A TOCALL of APX215 should
> be enough for all interested parties on the receive end.
> 
> If there is a need for a stable release so that distros can have a stable 
> version, we should push one out.  There is an open project on github for our 
> next release with a number of required fixes before we do it.  There was a 
> flurry of activity on some of those issues a while back, but between people
> being injured, having other projects, and what not, nothing's been done for
> quite a while.
> 
> If there is a real need for a stable release, we could probably use a little
> help.  The open issues that we expected to have fixed for the next release
> (nominally dubbed Xastir 2.2.0) can be seen at:
> 
> https://github.com/Xastir/Xastir/projects/2
> 
> Some might need punting.
> 
> On Sun, Feb 23, 2020 at 08:56:54AM -0800, we recorded a bogon-computron 
> collision of the  flavor, containing:
> > 
> > Hello Dave,
> > 
> > The scenario here seems to be if you're running an intermediate release
> > Xastir and not an official tagged release.
> > 
> > Dave, yes, I see you on APRS-IS : https://aprs.fi/info/a/KB3EFS and it shows
> > you're running v2.15 (APX215) per the "Last Path" line:
> > 
> >KB3EFS>*APX215* via TCPIP*,qAC,T2ONTARIO
> > 
> > 
> > The question here is if y

Bug#942193: dwz: dh_dwz freecad build regression: write_die: Assertion `value && refdcu->cu_kind != CU_ALT' failed.

[Tom de Vries]

On 15-10-2019 14:33, Matthias Klose wrote:
> On 14.10.19 10:10, Tom de Vries wrote:
>> On 13-10-2019 21:34, Kurt Kremitzki wrote:
>>> Hi Matthias,
>>>
>>> On Saturday, October 12, 2019 12:34:30 PM CDT Matthias Klose wrote:
>>>> Control: tags -1 + moreinfo
>>>> Control: severity -1 grave
>>>>
>>>> please could you attach the binary, or put it somewhere on the web?
>>>>
>>>
>>> Sorry, which binary are you referring to?
>>>
>>
>> Hi,
>>
>> in order to reproduce a dwz problem, we need:
>> - the dwz command line that triggered the assertion, and
>> - the files that were used as arguments. [ And since dwz modifies files
>>    in place, we need the files as they were before dwz was run. ]
>>
>>> Here are a few links in the meantime that might help, buildd logs for
>>> the
>>> i386/s390x/mipsel failures:
>>>
>>> https://buildd.debian.org/status/fetch.php?
>>> pkg=freecad=i386=0.18.3%2Bdfsg1-3=1568751036=0
>>>
>>> https://buildd.debian.org/status/fetch.php?
>>> pkg=freecad=mipsel=0.18.3%2Bdfsg1-3=1568784049=0
>>>
>>> https://buildd.debian.org/status/fetch.php?
>>> pkg=freecad=s390x=0.18.3%2Bdfsg1-3=1569764936=0
>>>
>>
>> I think it would be the easiest for me to reproduce on i386, so if you
>> could provide the reproduction information for that one, that would be
>> great.
> 
> https://people.debian.org/~doko/tmp/dwz-freecad.tar.xz
> https://people.debian.org/~doko/tmp/dwz-freecad.sh

Reproduced it, thanks.

Filed as: https://sourceware.org/bugzilla/show_bug.cgi?id=25109

- Tom

Bug#942193: dwz: dh_dwz freecad build regression: write_die: Assertion `value && refdcu->cu_kind != CU_ALT' failed.

[Tom de Vries]

On 13-10-2019 21:34, Kurt Kremitzki wrote:
> Hi Matthias,
> 
> On Saturday, October 12, 2019 12:34:30 PM CDT Matthias Klose wrote:
>> Control: tags -1 + moreinfo
>> Control: severity -1 grave
>>
>> please could you attach the binary, or put it somewhere on the web?
>>
> 
> Sorry, which binary are you referring to?
> 

Hi,

in order to reproduce a dwz problem, we need:
- the dwz command line that triggered the assertion, and
- the files that were used as arguments. [ And since dwz modifies files
  in place, we need the files as they were before dwz was run. ]

> Here are a few links in the meantime that might help, buildd logs for the 
> i386/s390x/mipsel failures:
> 
> https://buildd.debian.org/status/fetch.php?
> pkg=freecad=i386=0.18.3%2Bdfsg1-3=1568751036=0
> 
> https://buildd.debian.org/status/fetch.php?
> pkg=freecad=mipsel=0.18.3%2Bdfsg1-3=1568784049=0
> 
> https://buildd.debian.org/status/fetch.php?
> pkg=freecad=s390x=0.18.3%2Bdfsg1-3=1569764936=0
> 

I think it would be the easiest for me to reproduce on i386, so if you
could provide the reproduction information for that one, that would be
great.

Thanks,
- Tom

Bug#933981: cdrom: USB, KVM create connect/disconnect loop in level1 (repair) install

[Tom Sullivan]

Package: cdrom
Severity: grave
Tags: d-i
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

I had another machine that gave kernel panic while upgrading from Stretch to
Buster. Use of Graphical install was also a problem during re-install due to
destroyed system. (I reported this issue in another report.) Thus, I chose to
upgrade an identical machine from level 1 (Debain Repair in GRUB2 boot menu).

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

The scrolling log in the command line display showed repeated
connect/disconnect loops for USB devices (of many kinds). This applied also to
USB mice and keyboards connected via KVM.

For what it was worth, I used a local cache of the DVDs on the machine's hard
drive.

Unplugged all USB, plugged in single USB keyboard only, and directly, not via
KVM.

   * What was the outcome of this action?

Upgraded fine with just the keyboard directly plugged into USB.

   * What outcome did you expect instead?

Correct handling of USB, without issues.




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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#925918: linux-image-amd64: linux-image-3.16.0-8-amd64 - unpredictable reboots / kernel panics?

[Tom Stocker]

I can absolutely confirm this fishy behaviour on 2 VMWare guests. (VMware ESXi, 
6.5.0, 8294253, vSphere Client version 6.7.0)

Also ssh copy was not possible to a host running linux-image-3.16.0-8-amd64

No problems with linux-image-3.16.0-7-amd64.

Very fishy.

Bug#924495: Bug #924495 in shimdandy marked as pending

[Tom Marble]

Control: tag -1 pending

Hello,

Bug #924495 in shimdandy reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/java-team/shimdandy/commit/193cb48b5d54971e5373ec5924a6882d76103e23


Build with Clojure 1.10 (Closes: #924495)

New upstream version

Signed-off-by: Tom Marble 


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/924495

Bug#920230: Patch for your Git repository

[Tom Lee]

Appreciate it Andreas, thank you. Working the NMU changes into a new
release along with some other important changes that have come up.

I'll look at moving things over to salsa.debian.org when time permits --
thanks for the suggestion.

On Wed, Jan 30, 2019 at 12:21 AM Andreas Tille  wrote:

> Hi,
>
> I attached a commit for you Git repository to record the changes of my NMU.
> BTW, it would be easier if you would decide to maintain capnproto on
>https://salsa.debian.org/debian
>
> Hope this helps, Andreas.
>
> --
> http://fam-tille.de
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#917791: poezio: Missing dependency on python3-cffi

[Tom Teichler]

Package: poezio
Version: 0.12.1-1
Severity: serious
Justification: Does not work

When starting python3-cffi is missing. Does not work at all.

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

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

Versions of packages poezio depends on:
ii  python3 3.7.1-3
ii  python3-aiodns  1.1.1-1
ii  python3-gnupg   0.4.3-2
ii  python3-poezio-poopt0.12.1-1+b1
ii  python3-pyasn1  0.4.2-3
ii  python3-pyasn1-modules  0.2.1-0.2
ii  python3-slixmpp 1.4.0-1
ii  python3.6   3.6.8~rc1-1

poezio recommends no packages.

poezio suggests no packages.

-- no debconf information

Bug#913405: seafile-gui: Undefined symbol error in seafile-applet

[Tom Mason]

Package: seafile-gui
Version: 6.1.8-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

When I run seafile-applet, instead of launching successfully, I get the
following error:
seafile-applet: symbol lookup error: seafile-applet: undefined symbol: 
seafile_checkout_task_get_type

If you need any more information, please let me know.
Regards,
Tom Mason


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

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

Versions of packages seafile-gui depends on:
ii  ccnet   6.1.8-1
ii  libc6   2.27-8
ii  libccnet0   6.1.8-1
ii  libevent-2.1-6  2.1.8-stable-4
ii  libgcc1 1:8.2.0-9
ii  libglib2.0-02.58.1-2
ii  libjansson4 2.11-1
ii  libqt5core5a5.11.2+dfsg-4
ii  libqt5dbus5 5.11.2+dfsg-4
ii  libqt5gui5  5.11.2+dfsg-4
ii  libqt5network5  5.11.2+dfsg-4
ii  libqt5webkit5   5.212.0~alpha2-17
ii  libqt5widgets5  5.11.2+dfsg-4
ii  libquazip5-10.7.6-1
ii  libseafile0 6.2.5-2
ii  libsearpc1  3.1.0-1
ii  libsqlite3-03.25.2-1
ii  libssl1.1   1.1.1-2
ii  libstdc++6  8.2.0-9
ii  seafile-daemon  6.2.5-2

seafile-gui recommends no packages.

Versions of packages seafile-gui suggests:
pn  seafile-cli  

-- no debconf information

Bug#883181: linux-image-4.9.0-4-amd64: Default stretch kernel raises cgroup strack traces under high load

[Tom Stocker]

Hi Romain

Hardly, as this system is now in production as a build server, running a bpo 
kernel.

Linux  4.16.0-0.bpo.1-amd64 #1 SMP Debian 4.16.5-1~bpo9+1 
(2018-05-06) x86_64 GNU/Linux

Best regards

Tom

-Original Message-
From: Romain Perier [mailto:romain.per...@gmail.com] 
Sent: Mittwoch, 29. August 2018 19:55
To: 883...@bugs.debian.org
Subject: Bug#883181: linux-image-4.9.0-4-amd64: Default stretch kernel raises 
cgroup strack traces under high load

Hi,


The last linux kernel in stretch being 4.9.110, could you re-test with this
kernel please ?

Thanks,
Regards,
Romain

On Thu, Nov 30, 2017 at 11:54:00AM +, Tom Stocker wrote:
> Package: src:linux
> Version: 4.9.51-1
> Severity: serious
> Justification: Policy 2.2.1
> 
> 
> 
> -- Package-specific info:
> ** Version:
> Linux version 4.9.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
> 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.51-1 (2017-09-28)
> 
> ** Command line:
> BOOT_IMAGE=/boot/vmlinuz-4.9.0-4-amd64 
> root=/dev/mapper/de--bln--vm--017--vg-root ro quiet
> 
> ** Not tainted
> 
> ** Kernel log:
> [1.533757] EXT4-fs (dm-1): mounted filesystem with ordered data mode. 
> Opts: (null)
> [1.847797] ip_tables: (C) 2000-2006 Netfilter Core Team
> [1.912833] systemd[1]: systemd 232 running in system mode. (+PAM +AUDIT 
> +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS 
> +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
> [1.912859] systemd[1]: Detected virtualization vmware.
> [1.912863] systemd[1]: Detected architecture x86-64.
> [1.914546] systemd[1]: Set hostname to .
> [2.058639] random: crng init done
> [2.131752] systemd[1]: Set up automount Arbitrary Executable File Formats 
> File System Automount Point.
> [2.131812] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
> [2.131843] systemd[1]: Listening on Syslog Socket.
> [2.131885] systemd[1]: Started Forward Password Requests to Wall 
> Directory Watch.
> [2.131920] systemd[1]: Listening on udev Control Socket.
> [2.131955] systemd[1]: Started Dispatch Password Requests to Console 
> Directory Watch.
> [2.363268] EXT4-fs (dm-1): re-mounted. Opts: errors=remount-ro
> [2.516531] systemd-journald[833]: Received request to flush runtime 
> journal from PID 1
> [2.819683] input: Power Button as 
> /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
> [2.819691] ACPI: Power Button [PWRF]
> [2.819819] ACPI: AC Adapter [ACAD] (on-line)
> [2.875315] input: PC Speaker as /devices/platform/pcspkr/input/input5
> [2.881700] vmw_vmci :00:07.7: Found VMCI PCI device at 0x11080, irq 16
> [2.881767] vmw_vmci :00:07.7: Using capabilities 0xc
> [2.882410] Guest personality initialized and is active
> [2.882410] VMCI host device registered (name=vmci, major=10, minor=58)
> [2.882410] Initialized host personality
> [2.930410] [drm] Initialized
> [2.941291] sd 0:0:0:0: Attached scsi generic sg0 type 0
> [2.941374] sd 0:0:1:0: Attached scsi generic sg1 type 0
> [2.941446] sd 0:0:2:0: Attached scsi generic sg2 type 0
> [2.941516] sd 0:0:3:0: Attached scsi generic sg3 type 0
> [2.941562] sr 2:0:0:0: Attached scsi generic sg4 type 5
> [3.012775] [drm] DMA map mode: Using physical TTM page addresses.
> [3.012868] [drm] Capabilities:
> [3.012873] [drm]   Rect copy.
> [3.012874] [drm]   Cursor.
> [3.012875] [drm]   Cursor bypass.
> [3.012876] [drm]   Cursor bypass 2.
> [3.012877] [drm]   8bit emulation.
> [3.012878] [drm]   Alpha cursor.
> [3.012879] [drm]   Extended Fifo.
> [3.012880] [drm]   Multimon.
> [3.012881] [drm]   Pitchlock.
> [3.012882] [drm]   Irq mask.
> [3.012883] [drm]   Display Topology.
> [3.012884] [drm]   GMR.
> [3.012885] [drm]   Traces.
> [3.012886] [drm]   GMR2.
> [3.012887] [drm]   Screen Object 2.
> [3.012888] [drm]   Command Buffers.
> [3.012889] [drm]   Command Buffers 2.
> [3.012890] [drm]   Guest Backed Resources.
> [3.012891] [drm]   DX Features.
> [3.012893] [drm] Max GMR ids is 64
> [3.012894] [drm] Max number of GMR pages is 65536
> [3.012895] [drm] Max dedicated hypervisor surface memory is 0 kiB
> [3.012896] [drm] Maximum display memory size is 4096 kiB
> [3.012898] [drm] VRAM at 0xe800 size is 4096 kiB
> [3.012899] [drm] MMIO at 0xfe00 size is 256 kiB
> [3.012901] [drm] global init.
> [3.013022] [TTM] Zone  kernel: Available graphics memory: 60855752 kiB
> [3.013023] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
> [3.013024] [TTM] Initializing pool allocator
> [3.013029] [TTM] Ini

Bug#898391: nvidia-driver-libs-nonglvnd: cannot upgrade due to libglvnd0 conflict

[Tom Maneiro]

I'm also affected here: I'm trying to update to Mesa 17.3 after 
installing the 390.48.2~bpo9+3 drivers on my Stretch laptop (I'm using a 
hybrid graphics laptop so I need both drivers for my setup), but either 
I get updated Mesa or lose the nVidia blob due to conflicts with the new 
packaging specs (??), rendering my setup completely unupgradable and 
unusable.

Bug#869994: work around solution

[Tom Higgins]

I ran into this problem myself and found myself reading this thread.  

In message #10 Gregor Herrmann posted a link about the removal of the current 
directory in perl-5.26.

The solution to get it back is to add the following directive to the sql-
ledger-httpd.conf file

SetEnv PERL5LIB "." 


cheers,

Tom Higgins

Bug#897975: gdm3: System fails to boot due to GDM restarting constantly.

[Tom]

Package: gdm3
Version: 3.22.3-3+deb9u1
Followup-For: Bug #897975

Dear Maintainer,

I observe the same problem on my notebook and would like to add some additional
information.

1) CPU Intel(R) Celeron(R) CPU  N3160 with integrated graphics. This might be
interesting, as there is one (EE) entry from the X-Server seen in the gdm3
debug log (see 3)

2) I enabled debugging in the gdm3 configuration - in my case gdm3 still fails.
The error message in the logs (see attachment) is:

(EE) open /dev/fb0: Permission denied

3) I disabled wayland in the gdm3 configuration - gdm3 still doesn't start

4) As a workaround I installed lightdm - which works fine.

Best regards,

Tom



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

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

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.43-1
ii  adduser   3.115
ii  dconf-cli 0.26.0-2+b1
ii  dconf-gsettings-backend   0.26.0-2+b1
ii  debconf [debconf-2.0] 1.5.61
ii  gir1.2-gdm-1.03.22.3-3+deb9u1
ii  gnome-session [x-session-manager] 3.22.3-1
ii  gnome-session-bin 3.22.3-1
ii  gnome-settings-daemon 3.22.2-2+deb9u2
ii  gnome-shell   3.22.3-3
ii  gnome-terminal [x-terminal-emulator]  3.22.2-1
ii  gsettings-desktop-schemas 3.22.0-1
ii  libaccountsservice0   0.6.43-1
ii  libaudit1 1:2.6.7-2
ii  libc6 2.24-11+deb9u3
ii  libcanberra-gtk3-00.30-3
ii  libcanberra0  0.30-3
ii  libgdk-pixbuf2.0-02.36.5-2+deb9u2
ii  libgdm1   3.22.3-3+deb9u1
ii  libglib2.0-0  2.50.3-2
ii  libglib2.0-bin2.50.3-2
ii  libgtk-3-03.22.11-1
ii  libkeyutils1  1.5.9-9
ii  libpam-modules1.1.8-3.6
ii  libpam-runtime1.1.8-3.6
ii  libpam-systemd232-25+deb9u3
ii  libpam0g  1.1.8-3.6
ii  librsvg2-common   2.40.16-1+b1
ii  libselinux1   2.6-3+b3
ii  libsystemd0   232-25+deb9u3
ii  libwrap0  7.6.q-26
ii  libx11-6  2:1.6.4-3
ii  libxau6   1:1.0.8-1
ii  libxcb1   1.12-1
ii  libxdmcp6 1:1.1.2-3
ii  lsb-base  9.20161125
ii  mutter [x-window-manager] 3.22.3-2
ii  policykit-1   0.105-18
ii  ucf   3.0036
ii  x11-common1:7.7+19
ii  x11-xserver-utils 7.7+7+b1

Versions of packages gdm3 recommends:
ii  at-spi2-core2.22.0-6+deb9u1
ii  desktop-base9.0.2+deb9u1
ii  x11-xkb-utils   7.7+3+b1
ii  xserver-xephyr  2:1.19.2-1+deb9u2
ii  xserver-xorg1:7.7+19
ii  zenity  3.22.0-1+b1

Versions of packages gdm3 suggests:
ii  gnome-orca3.22.2-3
ii  libpam-gnome-keyring  3.20.0-3

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


-- debconf information:
* shared/default-x-display-manager: lightdm
  gdm3/daemon_name: /usr/sbin/gdm3
May 12 09:32:16 debian /usr/lib/gdm3/gdm-wayland-session[3362]: 
gnome-session-binary[3366]: WARNING: IceLockAuthFile failed: Die Datei 
existiert bereits
May 12 09:32:16 debian gdm3: Child process -3362 was already dead.
May 12 09:32:16 debian gdm3: Child process 3347 was already dead.
May 12 09:32:16 debian gdm3: Unable to kill session worker process
May 12 09:32:17 debian /usr/lib/gdm3/gdm-wayland-session[3391]: 
gnome-session-binary[3395]: DEBUG(+): Enabling debugging
May 12 09:32:17 debian /usr/lib/gdm3/gdm-wayland-session[3391]: 
gnome-session-binary[3395]: DEBUG(+): Using systemd for session tracking
May 12 09:32:17 debian /usr/lib/gdm3/gdm-wayland-session[3391]: 
gnome-session-binary[3395]: DEBUG(+): GsmManager: setting client store 
0x7f3380007a10
May 12 09:32:22 debian gdm3: Child process -3391 was already dead.
May 12 09:32:22 debian gdm3: Child process 3376 was already dead.
May 12 09:32:22 debian gdm3: Unable to kill session worker process
May 12 09:32:22 debian /usr/lib/gdm3/gdm-wayland-session[3418]: 
gnome-session-binary[3422]: DEBUG(+): Enabling debugging
May 12 09:32:22 debian /usr/lib/gdm3/gdm-wayland-session[3418]: 
gnome-session

Bug#897671: [U-Boot] Bug#897671: u-boot does not work on sheevaplug

[Tom Rini]

On Sat, May 05, 2018 at 04:04:08PM -0700, Vagrant Cascadian wrote:

> Hello U-Boot.
> 
> Markus Krebs discovered that the sheevaplug target has again grown and
> installation overlaps where the u-boot env is saved since u-boot
> ~2017.09. Running saveenv overwrites u-boot, and installing u-boot
> overwrites any prior environment settings.
> 
> More detail on the bug report in Debian:
> 
>   https://bugs.debian.org/897671
> 
> We don't carry any patches for the sheevaplug u-boot target in Debian,
> so this is likely also an issue upstream. Who are the current
> maintainers for sheevaplug in u-boot upstream?
> 
> A brief summary of the current findings:
> 
> On 2018-05-05, Markus Krebs wrote:
> > Am 05.05.2018 um 20:36 schrieb Markus Krebs:
> >> Am 05.05.2018 um 20:35 schrieb Martin Michlmayr:
> >>> * Markus Krebs <markus.kr...@web.de> [2018-05-05 20:32]:
> >>>> I got it. Indeed it has to to with the size of u-boot.
> >>>
> >>> Does it boot?
> >>>
> >> 
> >> Yes it does.
> >
> > ... and no longer so, when I "saveenv" :-(
> >
> > I downloaded u-boot via git; I guess that the config for u-boot for 
> > sheevaplug is already broken upstream (in sheevaplug.h):
> >
> >#define CONFIG_ENV_SIZE 0x2 /* 128k */
> >#define CONFIG_ENV_ADDR 0x8
> >#define CONFIG_ENV_OFFSET   0x8 /* env starts here */
> >
> > but the environment shouldn't start at 0x8 when u-boot.kwb > 524 KB; 
> > in this case 'saveenv' overwrites u-boot (?).
> > Changing 0x8 to 0xa helps ; I compiled a u-boot.kwb from the 
> > so-modified sources, and now I can start Debian fine.
> 
> It looks like it was bumped from 0x6 to 0x8 in 2014:
> 
>   
> http://git.denx.de/?p=u-boot.git;a=commit;h=4dfb0e4d3e75763d6fbe8788316bea9ba23e8e01
> 
> If 0x8 isn't enough, there might be some features in the config to
> experiment with removing, or it may need to be bumped again.

I've added the maintainer to the list as well.  I would suggest looking
for things to trim out, perhaps CMD_MEMTEST ?  Also, a patch to make it
a link error when we exceed the size allowed would be great, so that in
the future we catch this when it happens.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature

Bug#888893: password-gorilla: After upgrade, password-gorilla refuses to start with "Couldn't find the package Itcl" message

[Tom]

Package: password-gorilla
Version: 1.5.3.7-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

# apt-get update && apt-get upgrade && apt-get dist-upgrade

Now, starting password-gorilla gives an error message:
Couldn't find the package Itcl.
Itcl is required for Password Gorilla
The file /home/user/gorilla-debug-log was created for debugging purposes.
Password Gorilla will now terminate.

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

checked that itcl is indeed installed:

# dpkg -l itcl3
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture 
Description
+++-==---==
ii  itcl3:amd643.4.3-2  amd64
[incr Tcl] OOP extension for Tcl - run-time files 


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

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages password-gorilla depends on:
ii  itcl3   3.4.3-2
ii  tcl8.5  8.5.19-3
ii  tcllib  1.18-dfsg-3
ii  tk8.5   8.5.19-2
ii  tklib   0.6-3

password-gorilla recommends no packages.

password-gorilla suggests no packages.

-- no debconf information

Bug#887592: linux: 4.9.65-3 FTBFS on sparc64: arch/sparc/lib/multi3.S missing patch

[Tom Turelinckx]

Source: linux
Version: 4.9.65-3
Severity: serious
Tags: patch
Justification: fails to build from source (but built successfully in the past)

linux 4.9.65-3 (Stretch 9.3), as well as 4.9.51-1 and 4.9.47-1 FTBFS on sparc64:

/build/linux-4.9.65/arch/sparc/lib/multi3.S:2:24: fatal error: asm/export.h: No 
such file or directory
 #include 
^
compilation terminated.
/build/linux-4.9.65/scripts/Makefile.build:398: recipe for target 
'arch/sparc/lib/multi3.o' failed

It seems commit 1b4af13ff2cc "sparc64: Add __multi3 for gcc 7.x and later." was 
backported to 4.9 in 4.9.32 (commit 4b684e6474d0), but 
/debian/patches/bugfix/sparc/revert-sparc-move-exports-to-definitions.patch 
doesn't patch /arch/sparc/lib/multi3.S.

Applying the following patch, taken from linux 4.11.11-1's 
revert-sparc-move-exports-to-definitions.patch allows the build to succeed on 
sparc64 for linux 4.9.65-3, as well as 4.9.51-1 and 4.9.47-1:

--- a/arch/sparc/lib/multi3.S
+++ b/arch/sparc/lib/multi3.S
@@ -1,5 +1,4 @@
 #include 
-#include 
 
.text
.align  4
@@ -32,4 +31,3 @@ ENTRY(__multi3) /* %o0 = u, %o1 = v */
retl
 add%g1, %o0, %o0
 ENDPROC(__multi3)
-EXPORT_SYMBOL(__multi3)

Would it be possible to include this patch in future linux 4.9.x packages? 
Thanks!

Best regards,
Tom Turelinckx

-- System Information:
Debian Release: 9.0
Architecture: sparc64

Kernel: Linux 4.9.0-3-sparc64-smp (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#882247:

[Tom Marble]

Mike:

There is something wrong with the default locale. Try installing a
> locale package (even firefox-l10n-en-gb) or downgrade to 57.


Turns out I can't install that from unstable (depends on firefox <<
57.0.3-1),
however I installed it from experimental (58.0~b4-1) and now firefox
works!!!

Thank you!

--Tom

Bug#882247:

[Tom Marble]

Package: firefox
Version: 58.0~b4-1
Followup-For: Bug #882247

I also have this bug... adding reportbug details...

   * What led up to the situation?

Just starting firefox.

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

Tried on a new user account with no ~/.mozilla settings -- same result.

   * What was the outcome of this action?

Blank window showing 

-- no debconf information

Bug#883181: linux-image-4.9.0-4-amd64: Default stretch kernel raises cgroup strack traces under high load

[Tom Stocker]

Package: src:linux
Version: 4.9.51-1
Severity: serious
Justification: Policy 2.2.1



-- Package-specific info:
** Version:
Linux version 4.9.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.51-1 (2017-09-28)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.9.0-4-amd64 
root=/dev/mapper/de--bln--vm--017--vg-root ro quiet

** Not tainted

** Kernel log:
[1.533757] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: 
(null)
[1.847797] ip_tables: (C) 2000-2006 Netfilter Core Team
[1.912833] systemd[1]: systemd 232 running in system mode. (+PAM +AUDIT 
+SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS 
+ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
[1.912859] systemd[1]: Detected virtualization vmware.
[1.912863] systemd[1]: Detected architecture x86-64.
[1.914546] systemd[1]: Set hostname to .
[2.058639] random: crng init done
[2.131752] systemd[1]: Set up automount Arbitrary Executable File Formats 
File System Automount Point.
[2.131812] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
[2.131843] systemd[1]: Listening on Syslog Socket.
[2.131885] systemd[1]: Started Forward Password Requests to Wall Directory 
Watch.
[2.131920] systemd[1]: Listening on udev Control Socket.
[2.131955] systemd[1]: Started Dispatch Password Requests to Console 
Directory Watch.
[2.363268] EXT4-fs (dm-1): re-mounted. Opts: errors=remount-ro
[2.516531] systemd-journald[833]: Received request to flush runtime journal 
from PID 1
[2.819683] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
[2.819691] ACPI: Power Button [PWRF]
[2.819819] ACPI: AC Adapter [ACAD] (on-line)
[2.875315] input: PC Speaker as /devices/platform/pcspkr/input/input5
[2.881700] vmw_vmci :00:07.7: Found VMCI PCI device at 0x11080, irq 16
[2.881767] vmw_vmci :00:07.7: Using capabilities 0xc
[2.882410] Guest personality initialized and is active
[2.882410] VMCI host device registered (name=vmci, major=10, minor=58)
[2.882410] Initialized host personality
[2.930410] [drm] Initialized
[2.941291] sd 0:0:0:0: Attached scsi generic sg0 type 0
[2.941374] sd 0:0:1:0: Attached scsi generic sg1 type 0
[2.941446] sd 0:0:2:0: Attached scsi generic sg2 type 0
[2.941516] sd 0:0:3:0: Attached scsi generic sg3 type 0
[2.941562] sr 2:0:0:0: Attached scsi generic sg4 type 5
[3.012775] [drm] DMA map mode: Using physical TTM page addresses.
[3.012868] [drm] Capabilities:
[3.012873] [drm]   Rect copy.
[3.012874] [drm]   Cursor.
[3.012875] [drm]   Cursor bypass.
[3.012876] [drm]   Cursor bypass 2.
[3.012877] [drm]   8bit emulation.
[3.012878] [drm]   Alpha cursor.
[3.012879] [drm]   Extended Fifo.
[3.012880] [drm]   Multimon.
[3.012881] [drm]   Pitchlock.
[3.012882] [drm]   Irq mask.
[3.012883] [drm]   Display Topology.
[3.012884] [drm]   GMR.
[3.012885] [drm]   Traces.
[3.012886] [drm]   GMR2.
[3.012887] [drm]   Screen Object 2.
[3.012888] [drm]   Command Buffers.
[3.012889] [drm]   Command Buffers 2.
[3.012890] [drm]   Guest Backed Resources.
[3.012891] [drm]   DX Features.
[3.012893] [drm] Max GMR ids is 64
[3.012894] [drm] Max number of GMR pages is 65536
[3.012895] [drm] Max dedicated hypervisor surface memory is 0 kiB
[3.012896] [drm] Maximum display memory size is 4096 kiB
[3.012898] [drm] VRAM at 0xe800 size is 4096 kiB
[3.012899] [drm] MMIO at 0xfe00 size is 256 kiB
[3.012901] [drm] global init.
[3.013022] [TTM] Zone  kernel: Available graphics memory: 60855752 kiB
[3.013023] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[3.013024] [TTM] Initializing pool allocator
[3.013029] [TTM] Initializing DMA pool allocator
[3.013122] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[3.013127] [drm] No driver support for vblank timestamp query.
[3.013382] [drm] Screen Target Display device initialized
[3.013441] [drm] width 640
[3.013453] [drm] height 480
[3.013465] [drm] bpp 32
[3.014570] [drm] Fifo max 0x0004 min 0x1000 cap 0x077f
[3.015450] [drm] Using command buffers with DMA pool.
[3.015460] [drm] DX: no.
[3.015695] fbcon: svgadrmfb (fb0) is primary device
[3.017598] Console: switching to colour frame buffer device 100x37
[3.096662] ppdev: user-space parallel port driver
[3.112337] [drm] Initialized vmwgfx 2.12.0 20170221 for :00:0f.0 on 
minor 0
[3.194699] RAPL PMU: API unit is 2^-32 Joules, 3 fixed counters, 
10737418240 ms ovfl timer
[3.194702] RAPL PMU: hw unit of domain pp0-core 2^-0 Joules
[3.194703] RAPL PMU: hw unit of domain package 2^-0 Joules
[3.194704] RAPL PMU: hw unit of domain dram 2^-16 Joules
[3.235157] shpchp: Standard Hot Plug PCI Controller Driver 

Bug#882393: Subject: installation-reports: Buster installer hangs in vgchange

[Tom Dial]

Subject: installation-reports: Buster installer hangs in vgchange
Package: installation-reports
Justification: renders package unusable
Tags: d-i
Severity: grave

Dear Maintainer,

-- Package-specific info:

Boot method: CD ISO image
Image version:
https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso
d/l 20NOV2017 02:00 UTC
Date: 

Machine: Qemu-KVM 2 CPU, 4G on HP 8570w (Debian 9.2); storage on microSD
pass-through
Partitions: 



Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it


Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [E]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:
Partition table on the target virtual machine:
# fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 59.5 GiB, 63864569856 bytes, 124735488 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x68a8979e

Device Boot Start   End   Sectors  Size Id Type
/dev/mmcblk0p1 * 2048  4095  20481M 83 Linux
/dev/mmcblk0p2   4096   4198399   41943042G 82 Linux swap /
Solaris
/dev/mmcblk0p34198400 124735487 120537088 57.5G  5 Extended
/dev/mmcblk0p54200448  54532095  50331648   24G 8e Linux LVM
/dev/mmcblk0p6   54534144 121643007  67108864   32G 8e Linux LVM
/dev/mmcblk0p7  121645056 124735487   3090432  1.5G 83 Linux



Partitions 5 and 6 are LVM PVs with LVs root, swap_1, tmp, var, and
home, all except swap_1
formatted with xfs file systems. Partition 5 contains an operational
Debian 9.2 system
installed from an ISO image w/o problems. The intent was to install the
testing (buster)
system on partition 6.

The "Starting up the partitioner" progress bar stops at 40%. Examination
from a root prompt using vgdisplay
shows the 5 LVs on partition 6 "available" and the 5 LVs on partition 5
"NOT available." Killing the
"vgchange -ay" operation in progress and attempting to activate the VG
on partition 6 manually gives a
similar result: the vgchange -ay specifying the volume group name hangs,
but vgdisplay shows the LVs as
"available." Entries for the volume group are not present in /dev.
Entries /dev/dm-0, etc, for LVs
that have been activated are actually available, mountable, and writable.

Installing Debian 9.2 from the netinstall ISO image completed
successfully on the target volume group,
and upgrading that install to buster succeeded. This appeared to upgrade
LVM related drivers and programs
to the same versions as those on the buster netinstall ISO image.

--

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="8 (jessie) - installer build 20140316"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux dyson 3.13-1-amd64 #1 SMP Debian 3.13.5-1 (2014-03-04)
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core
processor DRAM Controller [8086:0154] (rev 09)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:176b]
lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200
v2/3rd Gen Core processor PCI Express Root Port [8086:0151] (rev 09)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation 7
Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31]
(rev 04)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:176b]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 7
Series/C210 Series Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:176b]
lspci -knn: 00:19.0 Ethernet controller [0200]: Intel Corporation
82579LM Gigabit Network Connection [8086:1502] (rev 04)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:176b]
lspci -knn: Kernel driver in use: e1000e
lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 7
Series/C210 Series Chipset Family USB Enhanced Host Controller #2
[8086:1e2d] (rev 04)
lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:176b]
lspci -knn: 

Bug#785565: [Ns-developers] State of ns3 in the Debian distribution

[Tom Henderson]

Hi Martin, responses inline below.

On 10/04/2017 05:26 AM, Martin Quinson wrote:

Hello dear developers,

[I hope that this is the right channel for this. Please be patient if not]

Yes, it is the right list.


I come to you to raise you awareness on the state of NS3 in Debian. It
suffers of two bugs concerning the graphical interface(s). One of them
is seen "important", meaning that ns3 will not be part of the next
Debian release (and it will also be dropped by derivative
distributions such as Ubuntu).

The problems are described here and here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785565
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875071

In short, the first bug is about the dependency on pygoocanvas, that
will soon be removed from Debian. If ns3 keeps depending on it, ns3
will be completely removed also (it is already removed from the
"testing" rolling release, and will be completely wipped out if we
don't take any action).

The second bug is about the same kind of issue with Qt4. But I think
we have more time to react (as described in the bug report).

So, my question is to know whether you have any plan to replace these
dependencies with the modern versions of these functionnality (gir in
the case of pygoocanvas IIRC, and Qt5 in the other case).
The maintainers for these animators are looking into the possibility of 
these replacements (to reply later).

Also, if you have an easy way to drop these dependencies (by disabling
them at build time), that could solve the issue on our side.  I know I
should RTFM for that, but I fail to find the time, and I would
appreciate this help in the package maintainance, please. The current
build receipe is here (that's a makefile):
http://sources.debian.net/src/ns3/3.26%2Bdfsg-1/debian/rules/
There isn't an ns-3 build dependency on netanim.  The pyviz visualizer 
is automatically left out of the configuration if the prerequisites are 
not found by Waf.  Is this sufficient (if we don't resolve these package 
dependencies in time)?



If you're interested, the build logs are here:
https://buildd.debian.org/status/package.php?p=ns3=sid

When answering this email, that'd be great if you could keep the bug
reports in CC so that we can keep track of it from the Debian
perspective.

We are about to make a new ns-3 release (3.27).  We also noticed that 
the netanim package in Debian stretch is very old (3.100+ while we are 
now at 3.108).  Can we work towards replacing the old versions with the 
new versions in the current release of Debian, or must we wait until the 
next Debian release?


- Tom

Bug#873540: capnproto: FTBFS on mips64el: test.capnp wants AnyList::Pipeline

[Tom Lee]

Thanks for the report Aaron, raised upstream at
https://github.com/capnproto/capnproto/issues/541

I'll dig into it more later this week if upstream doesn't beat me to it.

On Mon, Aug 28, 2017 at 1:01 PM, Aaron M. Ucko <u...@debian.org> wrote:

> Source: capnproto
> Version: 0.6.1-1
> Severity: serious
> Tags: upstream
> Justification: fails to build from source
>
> The latest mips64el build of capnproto failed, as detailed at
> https://buildd.debian.org/status/fetch.php?pkg=
> capnproto=mips64el=0.6.1-1=1503916947=0
> and (very briefly) excerpted below:
>
>   src/capnp/test.capnp.h:12247:29: error: 'Pipeline' in 'struct
>   capnp::AnyList' does not name a type
>  inline  ::capnp::AnyList::Pipeline getAnyListAsList();
>^~~~
>
> AFAICT, there's not supposed to be any such type, so the problem
> presumably lies in code generation.  Could you please take a look?
> Thanks!
>
> --
> Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
> http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/
> finger/?a...@monk.mit.edu
>



-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#869608: bareos-filedaemon: corrupts backups when signature=SHA1 in fileset

[Tom Weber]

Package: bareos-filedaemon
Version: 16.2.4-3
Severity: critical
Justification: causes serious data loss

to reproduce:
1) install bareos 16.2.4 client and server packages - all with
defaults.
2) run a SelfTest backup of the client/server.
3) Restore a file from this backup - everything should be fine.

4) now change
Signature = SHA1
in /etc/bareos/bareos-dir.d/fileset/SelfTest.conf

5) run another SelfTest Full backup
6) restore a file from this new backup

The restored file is corrupted.

I marked this critical because I upgraded a debian 8 client to debian 9
without any problems. Backups (bareos 15.2.2 Server) appeared to be
running fine until I had to do a restore and ended up with broken
files.

Regards,
  Tom

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

Kernel: Linux 4.10.17-1-pve (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE:de:en_US:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages bareos-filedaemon depends on:
ii  adduser3.115
ii  bareos-common  16.2.4-3
ii  debconf [debconf-2.0]  1.5.61
ii  init-system-helpers1.48
ii  libacl12.2.52-3+b1
ii  libc6  2.24-11+deb9u1
ii  libcap21:2.25-1
ii  libgcc11:6.3.0-18
ii  libgnutls303.5.8-5+deb9u2
ii  libjansson42.9-1
ii  liblzo2-2  2.08-1.2+b2
ii  libstdc++6 6.3.0-18
ii  libwrap0   7.6.q-26
ii  lsb-base   9.20161125
ii  lsof   4.89+dfsg-0.1
ii  zlib1g 1:1.2.8.dfsg-5

bareos-filedaemon recommends no packages.

bareos-filedaemon suggests no packages.

Bug#856826: Acknowledgement (installation-reports: Debian 8.6 installer with encrypted swap creates unusable swap logical volume)

[Tom Jay]

Hello,

This can be closed, it looks like there was some kind of problem with 
the netinstall disk my host was using, as if I use my own, everything 
works fine.

Thanks!


On 05/03/17 14:54, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>   Debian Install Team 
>
> If you wish to submit further information on this problem, please
> send it to 856...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>

Bug#852258: rt-authen-externalauth: FTBFS: Your installed version of RT (4.4.1-2) is too new

[Tom Jampen]

On 01.03.2017 21:20, Andreas Beckmann wrote:
> On Wed, 25 Jan 2017 07:51:04 +0100 Tom Jampen <t...@cryptography.ch> wrote:
>> request-tracker as of version 4.4 includes rt-authen-externalauth's
>> functionality. So let's see whether rt 4.4 makes it into stretch.
> 
> That made it into stretch, so rt-authen-externalauth can be removed from
> unstable?

I'm sorry, I didn't realized it had only been removed from testing and
not from unstable. You are right, it should be removed.

Regards
Tom

Bug#852543: apache and sysvinit

[Tom H]

apache2ctl should check for "/run/systemd/system" not for "/run/systemd"

Bug#852258: rt-authen-externalauth: FTBFS: Your installed version of RT (4.4.1-2) is too new

[Tom Jampen]

Hi Chris

Thanks for reporting this bug.

request-tracker as of version 4.4 includes rt-authen-externalauth's
functionality. So let's see whether rt 4.4 makes it into stretch.

Regards
Tom

Bug#843530: docker.io: docker broken: oci runtime error: could not synchronize with container process

[Tom Marble]

I can confirm I am hitting this exact same bug (same system
information).

--Tom

Bug#835416: imagevis3d: FTBFS: singleton.hpp:131: undefined reference to `boost::serialization::singleton_module::is_locked()'

[Tom Fogal]

Hi, thanks for looking into this.

On 09/20/2016 02:45 AM, peter green wrote:
>> 1. It's failing in the doc/genlua stuff, which is an internal tool meant
>> to generate documentation that is currently unfinished.  Arguably it
>> should be removed from source releases anyway.  So a simple fix is for
>> debian to just remove this directory from SUBDIRS in TuvokSubdirs.pro.
>
> I don't see a file called TuvokSubdirs.pro , I guess you mean 
> Tuvok/Tuvok.pro ?

Ahh, this must just be an older version, mea culpa.  Yeah, IIRC it would
be there.

> Anyway I removed doc/genlua from SUBDIRS in Tuvok/Tuvok.pro and tried a 
> build in raspbian stretch.
> 
> Unfortunately it failed with
> 
> g++ -fopenmp -Wl,-z,relro -o ../Build/ImageVis3D 
[snip]
> ../Tuvok/Build/libTuvok.a(SysTools.o): In function 
> `SysTools::GetTempDirectory(std::__cxx11::basic_string std::char_traits, std::allocator >&)':
> ./Tuvok/Basics/SysTools.cpp:1060: warning: the use of `tmpnam' is 
> dangerous, better use `mkstemp'
> ../Build/objects/ImageVis3D_WindowHandling.o: In function 
> `boost::serialization::singleton::get_mutable_instance()':
> /usr/include/boost/serialization/singleton.hpp:131: undefined reference 
> to `boost::serialization::singleton_module::is_locked()'

Yes, this is the same issue that was causing 'genlua' to fail; looks
like simply removing that code wasn't a great workaround.  Sorry.

I dug a bit deeper, by downloading boost 1.61 and verifying that,
indeed, the singleton.hpp included there is NOT a header-only library,
yet the one included in Tuvok's 3rdParty directory IS a header-only library.

Looking closer at the build log, I note that it is missing many of the
-I options that upstream has.  Notably in this case:
-IIO/3rdParty/boost.  This in turn causes it to use the system copy of
boost, which has changed behavior to require a new link option.

I can think of a number of solutions:

  * build-dep require a similar version of boost on the system.  I
can confirm 1.58 is fine.  Note that the runtime is irrelevant
since IV3D restricts itself to header-only parts of boost.

  * don't hack out the -I flags from upstream so that IV3D uses its
internal copy of boost.

  * edit the .pro files to force this to link against
libboost_serialization.so.

Bug#835416: imagevis3d: FTBFS: singleton.hpp:131: undefined reference to `boost::serialization::singleton_module::is_locked()'

[Tom Fogal]

Hi,

I have a couple ideas as to what's going wrong / how to fix this.

1. It's failing in the doc/genlua stuff, which is an internal tool meant
to generate documentation that is currently unfinished.  Arguably it
should be removed from source releases anyway.  So a simple fix is for
debian to just remove this directory from SUBDIRS in TuvokSubdirs.pro.

2. There is an internal copy of this aspect of boost, but for some
reason the system's boost is the one getting picked up.  Worse, it seems
the system version actually changes behavior of the library, notably
from header-only to be an actual library that needs to be linked against.
Boost probably has a define that one can set that forces header-only
behavior.  If someone wants to look into that, I'd be happy to add an
appropriate #define upstream.

On 08/25/2016 06:01 AM, Chris Lamb wrote:
>   ar cqs libTuvok.a Build/objects/Appendix.o Build/objects/ArcBall.o [snip]
>   rm -f Build/libTuvok.a
>   mv -f libTuvok.a Build/
>   make[3]: Leaving directory 
> '/home/lamby/temp/cdt.20160825134948.1It773RQbs.db.imagevis3d/imagevis3d-3.1.0/Tuvok'
>   cd doc/genlua/ && make -f Makefile 
>   make[3]: Entering directory 
> '/home/lamby/temp/cdt.20160825134948.1It773RQbs.db.imagevis3d/imagevis3d-3.1.0/Tuvok/doc/genlua'
>   g++ -c -fopenmp -DPACKAGE_MANAGER -g -O2 
> -fdebug-prefix-map=/home/lamby/temp/cdt.20160825134948.1It773RQbs.db.imagevis3d/imagevis3d-3.1.0=.
>  -fstack-protector-strong -Wformat -Werror=format-security 
> -Wno-unknown-pragmas -std=c++0x -fno-strict-aliasing -g -O2 
> -fdebug-prefix-map=/home/lamby/temp/cdt.20160825134948.1It773RQbs.db.imagevis3d/imagevis3d-3.1.0=.
>  -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -Wall -W -D_REENTRANT -DQT_OPENGL_LIB -DQT_GUI_LIB 
> -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE 
> -I/usr/share/qt4/mkspecs/linux-g++-64 -I. -I/usr/include/qt4/QtCore 
> -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtOpenGL -I/usr/include/qt4 
> -I../.. -I/usr/include/lua5.2 -I/usr/X11R6/include -I. -o main.o main.cpp
>   g++ -m64 -fopenmp -Wl,-z,relro -o bluebook main.o-L../../Build 
> -L../../IO/expressions -L/usr/lib/x86_64-linux-gnu -L/usr/X11R6/lib64 -lTuvok 
> -ltuvokexpr -lz -llua5.2 -lGLEW -ltiff -lbz2 -llzma -llz4 -lGLU -lGL 
> -lQtOpenGL -lQtGui -lQtCore -lGL -lpthread 
>   ../../Build/libTuvok.a(SysTools.o): In function 
> `SysTools::GetTempDirectory(std::__cxx11::basic_string std::char_traits, std::allocator >&)':
>   ./Tuvok/Basics/SysTools.cpp:1060: warning: the use of `tmpnam' is 
> dangerous, better use `mkstemp'
>   ../../Build/libTuvok.a(LinesGeoConverter.o): In function 
> `boost::serialization::singleton::get_mutable_instance()':
>   /usr/include/boost/serialization/singleton.hpp:131: undefined reference to 
> `boost::serialization::singleton_module::is_locked()'
>   /usr/include/boost/serialization/singleton.hpp:131: undefined reference to 
> `boost::serialization::singleton_module::is_locked()'
>   /usr/include/boost/serialization/singleton.hpp:131: undefined reference to 
> `boost::serialization::singleton_module::is_locked()'
>   /usr/include/boost/serialization/singleton.hpp:131: undefined reference to 
> `boost::serialization::singleton_module::is_locked()'
>   /usr/include/boost/serialization/singleton.hpp:131: undefined reference to 
> `boost::serialization::singleton_module::is_locked()'
>   
> ../../Build/libTuvok.a(PLYGeoConverter.o):/usr/include/boost/serialization/singleton.hpp:131:
>  more undefined references to 
> `boost::serialization::singleton_module::is_locked()' follow
>   collect2: error: ld returned 1 exit status
>   Makefile:99: recipe for target 'bluebook' failed
>   make[3]: *** [bluebook] Error 1
>   make[3]: Leaving directory 
> '/home/lamby/temp/cdt.20160825134948.1It773RQbs.db.imagevis3d/imagevis3d-3.1.0/Tuvok/doc/genlua'
>   Makefile:111: recipe for target 'sub-doc-genlua-make_default-ordered' failed
>   make[2]: *** [sub-doc-genlua-make_default-ordered] Error 2
>   make[2]: Leaving directory 
> '/home/lamby/temp/cdt.20160825134948.1It773RQbs.db.imagevis3d/imagevis3d-3.1.0/Tuvok'
>   Makefile:44: recipe for target 'sub-Tuvok-make_default-ordered' failed
>   make[1]: *** [sub-Tuvok-make_default-ordered] Error 2
>   make[1]: Leaving directory 
> '/home/lamby/temp/cdt.20160825134948.1It773RQbs.db.imagevis3d/imagevis3d-3.1.0'
>   dh_auto_build: make -j9 returned exit code 2
>   debian/rules:5: recipe for target 'build' failed
>   make: *** [build] Error 25

Bug#826684: staden,spin: error when trying to install together

[Tom Lee]

Thanks Andreas, appreciate you bringing this to my attention.

Complicating this: we're still in the process of getting spin through the
ITP/RFS process due to some licensing concerns with parts of the source
package, I think the package may have been accidentally uploaded today
instead of being rejected from the NEW queue. I'll follow up with the FTP
folks to get a sense of what's going on and try to get this resolved as
soon as I can.

Keep you posted.


On Tue, Jun 7, 2016 at 3:07 PM, Andreas Beckmann <a...@debian.org> wrote:

> Package: staden,spin
> Severity: serious
> User: trei...@debian.org
> Usertags: edos-file-overwrite
>
> Hi,
>
> automatic installation tests of packages that share a file and at the
> same time do not conflict by their package dependency relationships has
> detected the following problem:
>
>   Selecting previously unselected package spin.
>   Preparing to unpack .../spin_6.4.5-1_amd64.deb ...
>   Unpacking spin (6.4.5-1) ...
>   dpkg: error processing archive
> /var/cache/apt/archives/spin_6.4.5-1_amd64.deb (--unpack):
>trying to overwrite '/usr/bin/spin', which is also in package staden
> 2.0.0+b10-5
>   dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
>   Errors were encountered while processing:
>/var/cache/apt/archives/spin_6.4.5-1_amd64.deb
>
> This is a serious bug as it makes installation fail, and violates
> sections 7.6.1 and 10.1 of the policy. An optimal solution would
> consist in only one of the packages installing that file, and renaming
> or removing the file in the other package. Depending on the
> circumstances you might also consider Replace relations or file
> diversions. If the conflicting situation cannot be resolved then, as a
> last resort, the two packages have to declare a mutual
> Conflict. Please take into account that Replaces, Conflicts and
> diversions should only be used when packages provide different
> implementations for the same functionality.
>
> Here is a list of files that are known to be shared by both packages
> (according to the Contents file for sid/amd64, which may be
> slightly out of sync):
>
>   usr/bin/spin
>   usr/share/man/man1/spin.1.gz
>
> This bug is assigned to both packages. If you, the maintainers of
> the two packages in question, have agreed on which of the packages will
> resolve the problem please reassign the bug to that package. You may
> also register in the BTS that the other package is affected by the bug.
>
> Cheers,
>
> Andreas
>
> PS: for more information about the detection of file overwrite errors
> of this kind see https://qa.debian.org/dose/file-overwrites.html
>



-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Bug#804868: vnstat default config causes it to incorrectly measure bandwidth usage.

[Tom van Wietmarschen]

Package: vnstat
Version: 1.12-2
Severity: grave
Justification: causes non-serious data loss

vnstats default configuration causes it to reject any bandwidth measurement 
over 100Mbit. (MaxBandwidth is set to 100). This causes incorrect bandwidth 
reports on systems with gigabit network/internet connections. Since it is 
non-obvious to users until you compare it with another tool or (as in my case) 
see a report you know cannot be correct it is very likely that users of this 
package will get incorrect usage data without being aware it is incorrect. I've 
used this tool for almost a year before noticing the reports are not entirely 
accurate.

The default MaxBandwidth setting should be removed or increased to reflect the 
current state of network technology.

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

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

Versions of packages vnstat depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.22
ii  libc62.19-18

vnstat recommends no packages.

Versions of packages vnstat suggests:
pn  vnstati  

-- Configuration Files:
/etc/vnstat.conf changed [not included]

-- no debconf information

Bug#795863: fglrx-driver: fglrx ASIC lockup: HID devices unusable

[Tom Noonan]

Package: fglrx-driver
Version: 1:14.9+ga14.201-2
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

Running the fglrx driver against a Advanced Micro Devices, Inc. [AMD/ATI] 
Bonaire [FirePro W5100] ASIC lockups have been seen on multiple occasions.
This is usually seen when the terminal is idle with the monitors in power save 
mode.
XScreenSaver is in use to lock the terminals however all screensavers are 
disabled (screen blanking only) to try and eliminate GL issues.
When the ASIC locks the keyboard, mouse, and monitors are unusable.  The system 
still responds to SSH, however.
Non-X processes will continue to run.  X, however, appears locked at the kernel 
level as it cannot be killed.
The system must be power cycled to restore the HID devices.

Here is the most recent crash dump from the kernel log:
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.369542] 6[fglrx] ASIC hang 
happened
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.369546] CPU: 4 PID: 1147 Comm: 
Xorg Tainted: P C O  3.16.0-4-amd64 #1 Debian 3.16.7-ckt11-1+deb8u3
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.369547] Hardware name: Dell Inc. 
Precision T1700/048DY8, BIOS A15 02/02/2015
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.369548]  000104bde3e3 
8150b3a5  a081f5fc
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.369549]   
a092025e 88003712fc88 a09201c9
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.369550]  c90006345600 
0001 c90006344020 
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.369552] Call Trace:
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.369557]  [8150b3a5] ? 
dump_stack+0x41/0x51
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.369592]  [a081f5fc] ? 
firegl_hardwareHangRecovery+0x1c/0x30 [fglrx]
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.369642]  [a092025e] ? 
_ZN4Asic9WaitUntil15ResetASICIfHungEv+0x1e/0x30 [fglrx]
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.369688]  [a09201c9] ? 
_ZN4Asic9WaitUntil15WaitForCompleteEv+0xb9/0x130 [fglrx]
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.369733]  [a091cae5] ? 
_ZN4Asic19PM4ElapsedTimeStampEj14_LARGE_INTEGER12_QS_CP_RING_+0xd5/0x160 [fglrx]
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.369780]  [a0930ee2] ? 
_ZNK6AsicCI19insertEventWriteEOPE12_QS_CP_RING_RPjjRmR14_LARGE_INTEGERj+0xb2/0x170
 [fglrx]
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.369826]  [a0924ac9] ? 
_ZN15ExecutableUnits35flush_all_and_invalidate_HDP_cachesE12_QS_CP_RING_+0xc9/0xf0
 [fglrx]
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.369870]  [a09249ae] ? 
_ZN15ExecutableUnits8ringIdleE12_QS_CP_RING_+0x5e/0xb0 [fglrx]
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.369908]  [a08e0f1d] ? 
_Z17uQSPm4SynchronizemP18_QS_SYNC_PACKET_IN+0x4d/0x50 [fglrx]
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.369945]  [a08dbc88] ? 
_Z8uCWDDEQCmjjPvjS_+0x648/0x1240 [fglrx]
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.369975]  [a08a70aa] ? 
CMMQS_uCWDDEQC+0xa/0x10 [fglrx]
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.369998]  [a084ca9f] ? 
firegl_cmmqs_CWDDE_32+0x36f/0x480 [fglrx]
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.370019]  [a084b33e] ? 
firegl_cmmqs_CWDDE32+0x8e/0x140 [fglrx]
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.370041]  [a084b2b0] ? 
firegl_cmmqs_disabledriver+0x120/0x120 [fglrx]
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.370059]  [a0819b98] ? 
firegl_ioctl+0x1f8/0x260 [fglrx]
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.370061]  [8108ad0d] ? 
__hrtimer_start_range_ns+0x1cd/0x390
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.370074]  [a080816a] ? 
ip_firegl_unlocked_ioctl+0xa/0x10 [fglrx]
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.370076]  [811ba4df] ? 
do_vfs_ioctl+0x2cf/0x4b0
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.370078]  [8140541e] ? 
__sys_recvmsg+0x3e/0x80
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.370080]  [811ba741] ? 
SyS_ioctl+0x81/0xa0
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.370081]  [8151158d] ? 
system_call_fast_compare_end+0x10/0x15
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.370083] 
pubdev:0xa0fed3c0, num of device:1 , name:fglrx, major 14, minor 20. 
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.370084] device 0 : 
0x8800371fc000 .
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.370085] Asic ID:0x6649, 
revision:0x15, MMIOReg:0xc90005d8.
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.370086] FB phys addr: 0xe000, 
MC :0xf4, Total FB size :0x1.
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.370087] gart table 
MC:0xf40f73c000, Physical:0xef73c000, size:0x4c3000.
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.370088] mc_node :FB, total 1 zones
Aug 15 01:12:10 TJNII-Desktop kernel: [318238.370089] MC 
start:0xf4, 

Bug#777810: GCC 5 build issue

[Tom Lee]

Will do Martin -- thank you!
On Jun 25, 2015 9:55 AM, Martin Michlmayr t...@hp.com wrote:

 * Tom Lee m...@tomlee.co [2015-05-03 02:34]:
  Not sure if you're actively attempting test rebuilds every so often, but
  feel free to try for yourself when 0.5.2-1 hits unstable.

 I can confirm that the package in unstable builds fine with GCC 5.
 Tom, as the maintainer, I suggest you close this bug.

 --
 Martin Michlmayr
 Linux for HP Helion OpenStack, Hewlett-Packard

Bug#788591: hiredis: FTBFS on powerpc

[Tom Lee]

Control: tags -1 confirmed

Thanks for the bug report Emilio. Seems to be an issue in either the
redis or jemalloc packages on powerpc rather than a bug in the hiredis
package itself. It was very easy to reproduce the redis-server
crashes, but all attempts to narrow it down to a specific line of code
in redis-server proved fruitless. Saw lots of strange memory
corruption going on. The crashes seemed more likely to happen near a
zfree(...) -- example crash below, with some of my own diagnostic
checks + a non-stripped build of redis-server.

If I reverse the patch in 03-use-system-jemalloc.diff in the redis
package  link redis-server against the vendored jemalloc code the
crashes stop, so I'm inclined to believe this may be an issue with
Debian's jemalloc package.

Oddly if I rebuild Debian jemalloc package manually (unmodified)  run
redis-server against that, everything works great. I'll raise a bug
against the jemalloc package to see if we can get to the bottom of
this.

Cheers,
Tom

Program received signal SIGSEGV, Segmentation fault.
0x20482850 in raise (sig=11) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
37  ../nptl/sysdeps/unix/sysv/linux/pt-raise.c: No such file or directory.
(gdb) bt
#0  0x20482850 in raise (sig=11) at
../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#1  0x2066ec48 in _redisAssert (estr=0x206e43c0 c-querybuf != NULL,
file=0x206e4398 networking.c, line=1044)
at debug.c:400
#2  0x2062efac in processMultibulkBuffer (c=0xf751c000) at networking.c:1044
#3  0x2062f6fc in processInputBuffer (c=0xf751c000) at networking.c:1176
#4  0x2062fbd4 in readQueryFromClient (el=0xf7410250, fd=6,
privdata=0xf751c000, mask=1) at networking.c:1258
#5  0x2060f44c in aeProcessEvents (eventLoop=0xf7410250, flags=3) at ae.c:412
#6  0x2060f74c in aeMain (eventLoop=0xf7410250) at ae.c:455
#7  0x2061fad8 in main (argc=2, argv=0xfffef6b4) at redis.c:3685
(gdb) up
#1  0x2066ec48 in _redisAssert (estr=0x206e43c0 c-querybuf != NULL,
file=0x206e4398 networking.c, line=1044)
at debug.c:400
400 raise(SIGSEGV);
(gdb)
#2  0x2062efac in processMultibulkBuffer (c=0xf751c000) at networking.c:1044
1044redisAssert(c-querybuf != NULL);
(gdb) list
1039redisAssert(c-querybuf != NULL);
1040redisClient cpy;
1041memcpy(cpy, c, sizeof(cpy));
1042/* Setup argv array on client structure */
1043if (c-argv) zfree(c-argv);
1044redisAssert(c-querybuf != NULL);
1045c-argv = zmalloc(sizeof(robj*)*c-multibulklen);
1046redisAssert(c-querybuf != NULL);
1047}
1048
(gdb) p cpy  # BEFORE
$1 = {id = 2, fd = 6, db = 0xf74c71e8, dictid = 0, name = 0x0,
querybuf = 0xf7521008 *1\r\n$4\r\nPING\r\n,
  querybuf_peak = 0, argc = 0, argv = 0xf740d090, cmd = 0x0, lastcmd =
0x207116b0 redisCommandTable+5768,
  reqtype = 2, multibulklen = 1, bulklen = -1, reply = 0xf74fff00,
reply_bytes = 0, sentlen = 0, ctime = 1435027829,
  lastinteraction = 1435027829, obuf_soft_limit_reached_time = 0,
flags = 0, authenticated = 0, replstate = 0,
  repl_put_online_on_ack = 0, repldbfd = 0, repldboff = 0, repldbsize
= 0, replpreamble = 0x0, reploff = 0,
  repl_ack_off = 0, repl_ack_time = 0, replrunid = '\000' repeats 40
times, slave_listening_port = 0, mstate = {
commands = 0x0, count = 0, minreplicas = 0, minreplicas_timeout =
0}, btype = 0, bpop = {timeout = 0,
keys = 0xf74cf850, target = 0x0, numreplicas = 0, reploffset = 0},
woff = 0, watched_keys = 0xf74fff20,
  pubsub_channels = 0xf74cf880, pubsub_patterns = 0xf74fff40, peerid =
0x0, bufpos = 0,
  buf = +PONG\r\n, '\000' repeats 16376 times}
(gdb) p *c # AFTER
$2 = {id = 0, fd = 0, db = 0x0, dictid = 0, name = 0x0, querybuf =
0x0, querybuf_peak = 0, argc = 0, argv = 0x0,
  cmd = 0x0, lastcmd = 0x0, reqtype = 0, multibulklen = 0, bulklen =
0, reply = 0x0, reply_bytes = 0, sentlen = 0,
  ctime = 0, lastinteraction = 0, obuf_soft_limit_reached_time = 0,
flags = 0, authenticated = 0, replstate = 0,
  repl_put_online_on_ack = 0, repldbfd = 0, repldboff = 0, repldbsize
= 0, replpreamble = 0x0, reploff = 0,
  repl_ack_off = 0, repl_ack_time = 0, replrunid = '\000' repeats 40
times, slave_listening_port = 0, mstate = {
commands = 0x0, count = 0, minreplicas = 0, minreplicas_timeout =
0}, btype = 0, bpop = {timeout = 0, keys = 0x0,
target = 0x0, numreplicas = 0, reploffset = 0}, woff = 0,
watched_keys = 0x0, pubsub_channels = 0x0,
  pubsub_patterns = 0x0, peerid = 0x0, bufpos = 0, buf = '\000'
repeats 16383 times}

On Fri, Jun 12, 2015 at 5:21 PM, Emilio Pozuelo Monfort
po...@debian.org wrote:
 Source: hiredis
 Version: 0.13.1-1
 Severity: serious
 Control: block 785349 by -1

 Hi,

 Your package failed to build on powerpc:

 The problem seems to be:

 ../hiredis-test -h 127.0.0.1 -p 56379 -s /tmp/hiredis-test-redis.sock || \
 ( kill `cat /tmp/hiredis-test-redis.pid`  false )
 hiredis-test: test.c:625: test_throughput: Assertion `redisGetReply(c, 
 (void

Bug#785476: segfault when building against libhiredis0.13 due to vendored header files

[Tom Lee]

Package: webdis
Version: 0.1.1-2
Severity: serious

Hello, I'm trying to transition the hiredis package from libhiredis0.10 to
libhiredis0.13, but some issues with the packaging (specifically the
vendored sources) of webdis are causing me some problems. Specifically, the
vendored hiredis and jansson headers are used instead of the headers from
libhiredis-dev and libjansson-dev.

The most noisy symptom is a segfault when building webdis against
libhiredis0.13, which gdb shows is pool_connect trying to call strlen(...)
on a null pointer:

(gdb) set follow-fork-mode child
(gdb) run /tmp/tmp.swHGJysNL5/webdis.json
Starting program: /home/tom/Source/debian/webdis-0.1.1/webdis
/tmp/tmp.swHGJysNL5/webdis.json
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
[New process 25152]
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
[New Thread 0x76585700 (LWP 25153)]
[New Thread 0x75d84700 (LWP 25154)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x76585700 (LWP 25153)]
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) bt
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x0040798f in pool_connect (p=0x623940, db_num=0,
attach=attach@entry=1) at pool.c:134
#2  0x004031a3 in worker_pool_connect (w=0x623b70, w=0x623b70) at
worker.c:133
#3  worker_main (p=0x623b70) at worker.c:153
#4  0x7715a0a4 in start_thread (arg=0x76585700) at
pthread_create.c:309
#5  0x76e8f04d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Stepping through gdb a little more carefully, we can trace the issue down
to the call out to redisAsyncConnectUnix in pool_connect.

Inside redisAsyncConnectUnix (all the way up until the final retq
instruction on amd64) the redisAsyncContext looks something like this:

 p *ac
$4 = {c = {err = 1, errstr = No such file or directory, '\000' repeats
102 times, fd = -1, flags = 0,
obuf = 0x7f68 , reader = 0x7f80, connection_type =
REDIS_CONN_UNIX, timeout = 0x0, tcp = {
  host = 0x0, source_addr = 0x0, port = 0}, unix_sock = {
  path = 0x78c0 /tmp/tmp.ltIFMqN271/redis.sock}}, err = 1,
  errstr = 0x700011e4 No such file or directory, data = 0x0, ev =
{data = 0x0, addRead = 0x0, delRead = 0x0,
addWrite = 0x0, delWrite = 0x0, cleanup = 0x0}, onDisconnect = 0x0,
onConnect = 0x0, replies = {head = 0x0,
tail = 0x0}, sub = {invalid = {head = 0x0, tail = 0x0}, channels =
0x7e80, patterns = 0x7ec0}}

*The moment the retq instruction in this function returns* the struct
layout changes in gdb (e.g. the connection_type field disappears):

 p *ac
$6 = {c = {err = 1, errstr = No such file or directory, '\000' repeats
102 times, fd = -1, flags = 0,
obuf = 0x7f68 , reader = 0x7f80}, err = 1, errstr =
0x0, data = 0x0, ev = {data = 0x0,
addRead = 0x0, delRead = 0x78c0, addWrite = 0x1, delWrite =
0x700011e4, cleanup = 0x0},
  onDisconnect = 0x0, onConnect = 0x0, replies = {head = 0x0, tail = 0x0},
sub = {invalid = {head = 0x0, tail = 0x0},
channels = 0x0, patterns = 0x0}}

So the layout of the redisContext struct used to build libhiredis-dev
0.13.1-1 differs from one used to build webdis. This can be explained by
the vendored headers  can be further verified with strace when building
the package with gbp:

$ strace -e open -f -o ../strace.txt gbp buildpackage
--git-debian-branch=debian --git-upstream-branch=master

Any possibility you could sort that out? If it were up to me I'd use a
patch to blow away the vendored sources, but I'm not sure if that's the
best way to handle this sort of situation. gbp's support for filtering may
also be an option.

libhiredis0.13 and libhiredis-dev 0.13.1-1 have been uploaded to the
experimental distribution if you'd like to reproduce this for yourself.

Cheers,
Tom

-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#781443: capnproto: FTBFS on armhf and armel (test seg. faults) but built there in the past

[Tom Lee]

  ] CharParsers.Number
[   OK ] CharParsers.Number (0 ms)
[ RUN  ] CharParsers.DoubleQuotedString
[   OK ] CharParsers.DoubleQuotedString (0 ms)
[ RUN  ] CharParsers.SingleQuotedString
[   OK ] CharParsers.SingleQuotedString (0 ms)
[--] 10 tests from CharParsers (1 ms total)

[--] 4 tests from Blob
[ RUN  ] Blob.Text
[   OK ] Blob.Text (0 ms)
[ RUN  ] Blob.Data
[   OK ] Blob.Data (0 ms)
[ RUN  ] Blob.Compare
[   OK ] Blob.Compare (0 ms)
[ RUN  ] Blob.StlInterop
[   OK ] Blob.StlInterop (0 ms)
[--] 4 tests from Blob (0 ms total)

[--] 4 tests from Endian
[ RUN  ] Endian.Byte
[   OK ] Endian.Byte (0 ms)
[ RUN  ] Endian.TwoBytes
[   OK ] Endian.TwoBytes (0 ms)
[ RUN  ] Endian.FourBytes
[   OK ] Endian.FourBytes (0 ms)
[ RUN  ] Endian.EightBytes
[   OK ] Endian.EightBytes (0 ms)
[--] 4 tests from Endian (1 ms total)

[--] 4 tests from EndianUnoptimized
[ RUN  ] EndianUnoptimized.Byte
[   OK ] EndianUnoptimized.Byte (0 ms)
[ RUN  ] EndianUnoptimized.TwoBytes
[   OK ] EndianUnoptimized.TwoBytes (0 ms)
[ RUN  ] EndianUnoptimized.FourBytes
[   OK ] EndianUnoptimized.FourBytes (0 ms)
[ RUN  ] EndianUnoptimized.EightBytes
[   OK ] EndianUnoptimized.EightBytes (0 ms)
[--] 4 tests from EndianUnoptimized (0 ms total)

[--] 4 tests from EndianReverse
[ RUN  ] EndianReverse.Byte
[   OK ] EndianReverse.Byte (0 ms)
[ RUN  ] EndianReverse.TwoBytes
[   OK ] EndianReverse.TwoBytes (0 ms)
[ RUN  ] EndianReverse.FourBytes
[   OK ] EndianReverse.FourBytes (0 ms)
[ RUN  ] EndianReverse.EightBytes
[   OK ] EndianReverse.EightBytes (0 ms)
[--] 4 tests from EndianReverse (1 ms total)

[--] 5 tests from WireFormat
[ RUN  ] WireFormat.SimpleRawDataStruct
[   OK ] WireFormat.SimpleRawDataStruct (0 ms)
[ RUN  ] WireFormat.StructRoundTrip_OneSegment
[   OK ] WireFormat.StructRoundTrip_OneSegment (0 ms)
[ RUN  ] WireFormat.StructRoundTrip_OneSegmentPerAllocation
[   OK ] WireFormat.StructRoundTrip_OneSegmentPerAllocation (0 ms)
[ RUN  ] WireFormat.StructRoundTrip_MultipleSegmentsWithMultipleAl
locations
[   OK ] WireFormat.StructRoundTrip_MultipleSegmentsWithMultipleAllocations
(0 ms)
[ RUN  ] WireFormat.NanPatching
[   OK ] WireFormat.NanPatching (0 ms)
[--] 5 tests from WireFormat (0 ms total)

[--] 1 test from Any
[ RUN  ] Any.AnyPointer
[   OK ] Any.AnyPointer (1 ms)
[--] 1 test from Any (1 ms total)

[--] 1 test from Message
[ RUN  ] Message.MallocBuilderWithFirstSegment
[   OK ] Message.MallocBuilderWithFirstSegment (0 ms)
[--] 1 test from Message (0 ms total)

[--] 14 tests from Capability
[ RUN  ] Capability.Basic
[   OK ] Capability.Basic (1 ms)
[ RUN  ] Capability.Inheritance
[   OK ] Capability.Inheritance (0 ms)
[ RUN  ] Capability.Pipelining
[   OK ] Capability.Pipelining (1 ms)
[ RUN  ] Capability.TailCall
[   OK ] Capability.TailCall (0 ms)
[ RUN  ] Capability.AsyncCancelation
[   OK ] Capability.AsyncCancelation (0 ms)
[ RUN  ] Capability.DynamicClient
[   OK ] Capability.DynamicClient (1 ms)
[ RUN  ] Capability.DynamicClientInheritance

On Sun, Mar 29, 2015 at 11:01 PM, Niels Thykier ni...@thykier.net wrote:

 On 2015-03-30 04:30, Tom Lee wrote:
  Hey Niels,
 
  Understood. Hard to see exactly what's going on here because we seem to
 be
  falling afoul of
 https://lists.debian.org/debian-devel/2014/04/msg00322.html.
  Do you happen to know if there's another way to get access to
  test-suite.log from these builds? The suggested work-around in that
 mailing
  list thread appears to require a change to the packaging, which I imagine
  we want to try and avoid.
 
  Cheers,
  Tom
 
 
  [...]

 Hi Tom,

 I see no problem in adding a VERBOSE=1 (or --disable-silent-rules, or
 whatever), as it does not have an effect of the produced built.
   In fact, I am not aware of any other way to obtain the test-suite.log
 from the buildds.  To my knowledge, the buildds more or less discards
 the build environment immediately after the build terminates.

 My best alternative is for you to get -guest access to a porterbox and
 try to reproduce it there[1].  It may take some time before you get such
 an account.  It might make sense for you to try that in parallel with
 the build logs - just in case the build logs are not enough for you to
 fix the issue.
   DDs also have access to porterboxes, so you might also be able to
 convince your sponsor to help you with obtaining additional information
 from the porterbox.  Though, in this case, you will probably want to
 stack up a few things to save a few roundtrips.  Maybe something like:

 
  * Please build the package and which fail the tests
  * Extract test-build.log
  * Run the test via gdb and do a bt at the point

Bug#781443: capnproto: FTBFS on armhf and armel (test seg. faults) but built there in the past

[Tom Lee]

Hey Niels,

Understood. Hard to see exactly what's going on here because we seem to be
falling afoul of https://lists.debian.org/debian-devel/2014/04/msg00322.html.
Do you happen to know if there's another way to get access to
test-suite.log from these builds? The suggested work-around in that mailing
list thread appears to require a change to the packaging, which I imagine
we want to try and avoid.

Cheers,
Tom


On Sun, Mar 29, 2015 at 4:45 AM, Niels Thykier ni...@thykier.net wrote:

 Source: capnproto
 Version: 0.4.1-3
 Severity: serious

 Hi,

 It seems that the current version of capnproto FTBFS on armel and
 armhf due to a segmentation fault in one of the tests.  This prevents
 the new version of migrating to testing as it is a regression compared
 to the version in testing.

 Thanks,
 ~Niels




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#780565: Integer overflow in pointer validation

[Tom Lee]

Package: capnproto
Version: 0.4.1-2
Severity: critical

Upstream has reported a number of security issues in capnproto 0.4.1.
Creating bugs to track these issues while I work on getting them fixed.

This bug is tracking the Integer overflow in pointer validation bug
reported on 2015-03-02.

Full details + patch:
https://github.com/sandstorm-io/capnproto/blob/master/security-advisories/2015-03-02-0-c%2B%2B-integer-overflow.md

-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#780568: CPU usage amplification attack #2

[Tom Lee]

Package: capnproto
Version: 0.4.1-2
Severity: critical

Upstream has reported a number of security issues in capnproto 0.4.1.
Creating bugs to track these issues while I work on getting them fixed.

This bug is tracking the second CPU usage amplification attack bug
reported on 2015-03-05.

Full details + patch:
https://github.com/sandstorm-io/capnproto/blob/master/security-advisories/2015-03-05-0-c%2B%2B-addl-cpu-amplification.md

-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#780567: CPU usage amplification attack

[Tom Lee]

Package: capnproto
Version: 0.4.1-2
Severity: critical

Upstream has reported a number of security issues in capnproto 0.4.1.
Creating bugs to track these issues while I work on getting them fixed.

This bug is tracking the CPU usage amplification attack bug reported on
2015-03-02.

Full details + patch:
https://github.com/sandstorm-io/capnproto/blob/master/security-advisories/2015-03-02-2-all-cpu-amplification.md


-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#780566: Integer underflow in pointer validation

[Tom Lee]

Package: capnproto
Version: 0.4.1-2
Severity: critical

Upstream has reported a number of security issues in capnproto 0.4.1.
Creating bugs to track these issues while I work on getting them fixed.

This bug is tracking the Integer underflow in pointer validation bug
reported on 2015-03-02.

Full details + patch:
https://github.com/sandstorm-io/capnproto/blob/master/security-advisories/2015-03-02-1-c%2B%2B-integer-underflow.md

-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#770648: no subject

[Tom Lee]

Sorry, I probably haven't communicated my own inaction here. I've been
holding off on an unblock request given a) this appears to be a bug in
pbuilder, and b) we don't have a fix uploaded to unstable yet (which seems
reasonable given `a`). The pbuilder bug has gone relatively quiet over the
last few days too.

Anyway: I've talked things over with jcristau (release team) and the
suggestion is to reduce the severity of this bug to important, so it is no
longer release-critical.

On Thu, Dec 4, 2014 at 7:30 PM, Potter, Tim (Cloud Services) 
timothy.pot...@hp.com wrote:

 Hi everyone.  I'm nervously following along with this bug since its
 presence is threatening the removal of a couple of dozen other packages as
 you can all probably see from the QA page.

 In the spirit of not hassling anyone (-: I was curious whether there was a
 plan to close this out?  It sounds like a solution is very near, hopefully
 to the satisfaction of both the maintainers and release coordinators.


 Regards,

 Tim.




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#770648: hiredis: FTBFS: Test failure

[Tom Lee]

Alrighty, talking this over with Alessandro he made the case that we should
keep tests that don't rely on *external *network connections. See e.g.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753944 which makes the
case for a loopback interface in pbuilder.

Tobi, to that effect I modified your patch to keep the tests that work fine
with localhost  thus pass in pbuilder.

Also, I feel like the serious severity is overstating the issue given
that 0.11.0-4 builds fine in buildd/sbuild. Alessandro pointed out the
periodic rebuilds would have revealed this issue otherwise.

If there are no objections I'd like to propose we adjust the severity of
this bug to normal  leave the fix for this particular bug until after
the Jessie freeze.

Otherwise, I can reach out to the release team to get the hiredis package
unblocked  work through getting a new package uploaded with the pbuilder
fixes  nocheck support.


On Mon, Nov 24, 2014 at 4:32 AM, Tobias Frost t...@frost.de wrote:

 On Mon, 24 Nov 2014 00:45:04 -0800 Tom Lee deb...@tomlee.co wrote:
  Alrighty, patch applied  pbuilder's clean. Now just waiting on
 Alessandro
  to review my changes  push the package. On master here if you want to
 try
  things out in the interim: git://
 anonscm.debian.org/collab-maint/hiredis.git
 
 
  Daniel, I also added support for DEB_BUILD_OPTS=nocheck since it caused
 you
  additional grief.
 
  Tobi, I haven't bothered addressing the pid file etc. in /tmp just yet,
 but
  I'll take a look at that sometime soon.

 Please remember we are in freeze: Both those changes are not covered by the
 freeze policy as they are not targeting RC bugs.
 As the DEB_BUILD_OPTIONS=nocheck is already committed, I suggest you ask on
 #debian-release if that they could accept this.

 The /tmp thing is unimportant now, and can be fixed for Stretch, (if you
 want
 to fix it)

 --
 tobi




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#770648: hiredis: FTBFS: Test failure

[Tom Lee]

Talked this over with the release team on #debian-release, they agree it's
a serious bug  indicated that they'd prefer the fix to be something more
along the lines of what Gregor is suggesting. I feel like the test should
call out the fact it's skipped not passed, but otherwise imagine it would
look the same.

I'll open a bug against release.debian.org  get this resolved -- thanks
everyone!

On Sun, Nov 30, 2014 at 10:17 AM, gregor herrmann gre...@debian.org wrote:

 On Sun, 30 Nov 2014 17:36:04 +0100, Alessandro Ghedini wrote:

  On dom, nov 30, 2014 at 03:06:55 +0100, Tobias Frost wrote:
   Am Sonntag, den 30.11.2014, 00:21 -0800 schrieb Tom Lee:

Also, I feel like the serious severity is overstating the issue
given that 0.11.0-4 builds fine in buildd/sbuild. Alessandro pointed
out the periodic rebuilds would have revealed this issue otherwise.
  
   
If there are no objections I'd like to propose we adjust the severity
of this bug to normal  leave the fix for this particular bug until
after the Jessie freeze.
  
   Here I can reprodcue the FTBFS locally with pbuilder 0.215+nmu3, so
   I disagree. It maybe has not been detected *yet*?
 
  What does this yet even mean? Except inside pbuilder, hiredis builds
 fine [1].
  The fact that it fails *only* inside pbuilder (and the fact that hiredis
 is not
  the only package in this situation) suggests that this is indeed a
 pbuilder bug.
  I really don't see how this is release critical in any way on the part
 of the
  hiredis package.

 While I tend to agree in general, here's an additional data point:
 I rebuilt 0.11.0-4 in my sid amd64 cowbuilder chroot, which has
 USENETWORK=yes (due to #753944) but firewalls off everything except
 localhost during build. And in this environment I see a test failure:

 make check
 make[2]: Entering directory '/tmp/buildd/hiredis-0.11.0'
 echo \
 daemonize yes\n \
 pidfile /tmp/hiredis-test-redis.pid\n \
 port 56379\n \
 bind 127.0.0.1\n \
 unixsocket /tmp/hiredis-test-redis.sock \
 | redis-server -
 ./hiredis-test -h 127.0.0.1 -p 56379 -s /tmp/hiredis-test-redis.sock || \
 ( kill `cat /tmp/hiredis-test-redis.pid`  false )
 #01 Format command without interpolation: PASSED
 #02 Format command with %s string interpolation: PASSED
 #03 Format command with %s and an empty string: PASSED
 #04 Format command with an empty string in between proper interpolations:
 PASSED
 #05 Format command with %b string interpolation: PASSED
 #06 Format command with %b and an empty string: PASSED
 #07 Format command with literal %: PASSED
 #08 Format command with printf-delegation (int): PASSED
 #09 Format command with printf-delegation (char): PASSED
 #10 Format command with printf-delegation (short): PASSED
 #11 Format command with printf-delegation (long): PASSED
 #12 Format command with printf-delegation (long long): PASSED
 #13 Format command with printf-delegation (unsigned int): PASSED
 #14 Format command with printf-delegation (unsigned char): PASSED
 #15 Format command with printf-delegation (unsigned short): PASSED
 #16 Format command with printf-delegation (unsigned long): PASSED
 #17 Format command with printf-delegation (unsigned long long): PASSED
 #18 Format command with printf-delegation (float): PASSED
 #19 Format command with printf-delegation (double): PASSED
 #20 Format command with invalid printf format: PASSED
 #21 Format command by passing argc/argv without lengths: PASSED
 #22 Format command by passing argc/argv with lengths: PASSED
 #23 Error handling in reply parser: PASSED
 #24 Memory cleanup in reply parser: PASSED
 #25 Set error on nested multi bulks with depth  7: PASSED
 #26 Works with NULL functions for reply: PASSED
 #27 Works when a single newline (\r\n) covers two calls to feed: PASSED
 #28 Don't reset state after protocol error: PASSED
 #29 Don't do empty allocation for empty multi bulk: PASSED
 #30 Returns error when host cannot be resolved: FAILED
 #31 Returns error when the unix socket path doesn't accept connections:
 PASSED

 [..]

 which seems to be the same as what Daniel originally reported.


 Adding a printf statement to test.c shows:
 #30 Returns error when host cannot be resolved: FAILED
 ERROR: Temporary failure in name resolution

 test.c currently looks for Name or service not known or Can't
 resolve: idontexist.local but not for what I get here ...

 Not sure what the best way forward is; adding a test for Temporary
 failure in name resolution might be an option (and works
 unsurprisingly):

 #v+
 --- a/test.c
 +++ b/test.c
 @@ -286,7 +286,8 @@
  c = redisConnect((char*)idontexist.local, 6379);
  test_cond(c-err == REDIS_ERR_OTHER 
  (strcmp(c-errstr,Name or service not known) == 0 ||
 - strcmp(c-errstr,Can't resolve: idontexist.local) == 0));
 + strcmp(c-errstr,Can't resolve: idontexist.local) == 0 ||
 + strcmp(c-errstr,Temporary failure in name resolution) == 0));
  redisFree(c

Bug#770648: hiredis: FTBFS: Test failure

[Tom Lee]

D'oh :) There I go making assumptions.

All the same, I feel like we can argue back and forth about the severity of
this issue but we've got a potential fix ready to go. Might as well get the
release team involved -- if we can arrange an unblock the whole issue is
moot.

On Sun, Nov 30, 2014 at 11:00 AM, gregor herrmann gre...@debian.org wrote:

 On Sun, 30 Nov 2014 10:51:56 -0800, Tom Lee wrote:

  Talked this over with the release team on #debian-release,

 Except that noone who responded is a member of the release team :)

 Cheers,
 gregor

 --
  .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key
 0xBB3A68018649AA06
  : :' : Debian GNU/Linux user, admin, and developer  -
 http://www.debian.org/
  `. `'  Member of VIBE!AT  SPI, fellow of the Free Software Foundation
 Europe
`-   NP: Cat Stevens: I Love My Dog

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQJ8BAEBCgBmBQJUe2l0XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
 ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREMUUxMzE2RTkzQTc2MEE4MTA0RDg1RkFC
 QjNBNjgwMTg2NDlBQTA2AAoJELs6aAGGSaoGscoQAJIK0qNAR4/HTYvVRo7barIC
 ZK9EombbjP8kK+iNoX2lAhDhawJgwEJ7fUOWtcjG4rjamYsSGI9HKB9abu7Brqhb
 nap+NS5NKFctfdQP2zSn9AXpu8TWwzdC73a5BOAs3Msr6T2BHcKX+e8xcdXj77xc
 FFtvcPUcFLzBtCxZA+wBrWWvPn+ZJAVIKhcoxf/85JFpfmbGyjHdwiwq9XoTgfHu
 f5esudD3UjSzYYDpMf1fgWbdfG3E1CDmbfNsuBMAmnp4TUUGlL5MiaFjIMggBk/f
 M8K9TuLah/I8/kTLNfoWjQ74+q6WJI3GySXPpHdmHny+wltY92gs0d7mea3pzov/
 UiIMGUpO5kwX6CwL3mN9wFkhSbjEy6kBrUTBnDgXsH2ktGjn6bbjnDl8Tn++Idnz
 iLfDVStzlDtihg12zxT2gthoiFx7YcYFOlQSo6wxwDoOFUM0zJmuv1rov919UaQ4
 5GJhHD4CWG1oFEn/s/7z+aOrjb39X2cF1OQa8FzqYTnmBTd+vwSLNNP4S2ipOKJU
 hTWb6cov7xpZwdxZJfOCzWX3PJEuxDHZZjLHWQy0QNdkeEJouEe6edMdb//tYQEk
 vDCplr7xZfcVbJ2ALz0uiKWyOaP48AB0r8MED7T1e8qwxEBp1LqS1AQA87NNsNgA
 G0q+Hrl4KbKUVI8I2RDO
 =6Enz
 -END PGP SIGNATURE-




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#770648: hiredis: FTBFS: Test failure

[Tom Lee]

Rather than add to the overhead of getting this change accepted, I'm going
to roll back the DEB_BUILD_OPTS=nocheck change given it's unrelated to this
bug (per the freeze policy
https://release.debian.org/jessie/freeze_policy.html). I'll roll it back in
after the freeze.

Proposed change to 0.11.0-4 looks like this:

$ debdiff ~/Source/hiredis_0.11.0-4.dsc ../hiredis_0.11.0-5.dsc
gpgv: Signature made Sun 30 Nov 2014 01:12:44 PM PST using RSA key ID
6C6608D1
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on
/home/tom/Source/debian/hiredis_0.11.0-5.dsc
diff -Nru hiredis-0.11.0/debian/changelog hiredis-0.11.0/debian/changelog
--- hiredis-0.11.0/debian/changelog 2014-10-03 20:30:13.0 -0700
+++ hiredis-0.11.0/debian/changelog 2014-11-30 13:09:15.0 -0800
@@ -1,3 +1,9 @@
+hiredis (0.11.0-5) unstable; urgency=medium
+
+  * Disable a network test failing in pbuilder (closes: #770648)
+
+ -- Tom Lee deb...@tomlee.co  Mon, 24 Nov 2014 00:17:31 -0800
+
 hiredis (0.11.0-4) unstable; urgency=medium

   * Symlinks for cmake 3.0 (closes: #758548)
diff -Nru hiredis-0.11.0/debian/patches/04_disable-network-tests.patch
hiredis-0.11.0/debian/patches/04_disable-network-tests.patch
--- hiredis-0.11.0/debian/patches/04_disable-network-tests.patch
 1969-12-31 16:00:00.0 -0800
+++ hiredis-0.11.0/debian/patches/04_disable-network-tests.patch
 2014-11-29 22:36:40.0 -0800
@@ -0,0 +1,25 @@
+Description: Disable Returns error when host cannot be resolved
+ This patch disables a test that relies on the presence of a
+ network connection.
+Author: Tobias Frost t...@debian.org
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/test.c
 b/test.c
+@@ -282,12 +282,16 @@
+ static void test_blocking_connection_errors(void) {
+ redisContext *c;
+
++#if 0
+ test(Returns error when host cannot be resolved: );
+ c = redisConnect((char*)idontexist.local, 6379);
+ test_cond(c-err == REDIS_ERR_OTHER 
+ (strcmp(c-errstr,Name or service not known) == 0 ||
+  strcmp(c-errstr,Can't resolve: idontexist.local) == 0));
+ redisFree(c);
++#else
++test(SKIPPED: Returns error when host cannot be resolved\n);
++#endif
+
+ /*test(Returns error when the port is not open: );
+ c = redisConnect((char*)localhost, 1);
diff -Nru hiredis-0.11.0/debian/patches/series
hiredis-0.11.0/debian/patches/series
--- hiredis-0.11.0/debian/patches/series2014-10-03
20:30:13.0 -0700
+++ hiredis-0.11.0/debian/patches/series2014-11-24
00:11:32.0 -0800
@@ -1,3 +1,4 @@
 01_use-proper-destdir.patch
 02_disable-failing-test.patch
 03_pkgconfig-cmake.patch
+04_disable-network-tests.patch


On Sun, Nov 30, 2014 at 12:59 PM, Tom Lee deb...@tomlee.co wrote:

 D'oh :) There I go making assumptions.

 All the same, I feel like we can argue back and forth about the severity
 of this issue but we've got a potential fix ready to go. Might as well get
 the release team involved -- if we can arrange an unblock the whole issue
 is moot.

 On Sun, Nov 30, 2014 at 11:00 AM, gregor herrmann gre...@debian.org
 wrote:

 On Sun, 30 Nov 2014 10:51:56 -0800, Tom Lee wrote:

  Talked this over with the release team on #debian-release,

 Except that noone who responded is a member of the release team :)

 Cheers,
 gregor

 --
  .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key
 0xBB3A68018649AA06
  : :' : Debian GNU/Linux user, admin, and developer  -
 http://www.debian.org/
  `. `'  Member of VIBE!AT  SPI, fellow of the Free Software Foundation
 Europe
`-   NP: Cat Stevens: I Love My Dog

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQJ8BAEBCgBmBQJUe2l0XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
 ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREMUUxMzE2RTkzQTc2MEE4MTA0RDg1RkFC
 QjNBNjgwMTg2NDlBQTA2AAoJELs6aAGGSaoGscoQAJIK0qNAR4/HTYvVRo7barIC
 ZK9EombbjP8kK+iNoX2lAhDhawJgwEJ7fUOWtcjG4rjamYsSGI9HKB9abu7Brqhb
 nap+NS5NKFctfdQP2zSn9AXpu8TWwzdC73a5BOAs3Msr6T2BHcKX+e8xcdXj77xc
 FFtvcPUcFLzBtCxZA+wBrWWvPn+ZJAVIKhcoxf/85JFpfmbGyjHdwiwq9XoTgfHu
 f5esudD3UjSzYYDpMf1fgWbdfG3E1CDmbfNsuBMAmnp4TUUGlL5MiaFjIMggBk/f
 M8K9TuLah/I8/kTLNfoWjQ74+q6WJI3GySXPpHdmHny+wltY92gs0d7mea3pzov/
 UiIMGUpO5kwX6CwL3mN9wFkhSbjEy6kBrUTBnDgXsH2ktGjn6bbjnDl8Tn++Idnz
 iLfDVStzlDtihg12zxT2gthoiFx7YcYFOlQSo6wxwDoOFUM0zJmuv1rov919UaQ4
 5GJhHD4CWG1oFEn/s/7z+aOrjb39X2cF1OQa8FzqYTnmBTd+vwSLNNP4S2ipOKJU
 hTWb6cov7xpZwdxZJfOCzWX3PJEuxDHZZjLHWQy0QNdkeEJouEe6edMdb//tYQEk
 vDCplr7xZfcVbJ2ALz0uiKWyOaP48AB0r8MED7T1e8qwxEBp1LqS1AQA87NNsNgA
 G0q+Hrl4KbKUVI8I2RDO
 =6Enz
 -END PGP SIGNATURE-




 --
 *Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#770648: hiredis: FTBFS: Test failure

[Tom Lee]

On Sun, Nov 30, 2014 at 1:31 PM, Alessandro Ghedini gh...@debian.org
wrote:

 This is, I think, the exact same problem as #759799 (which is btw severity:
 important). If the consensus is that this should be fixed in the affected
 packages (e.g. by disabling the tests), I'm all for it, but I really think
 that
 the effort should go into fixing pbuilder, since who knows how many
 packages
 are actually affected by this.


Agreed, but I'm going to get the release team involved to get this sorted
out given hiredis has been flagged for auto-removal in Jessie as a result
of this bug. Specifically, I'm requesting an unblock for 0.11.0-5 alongside
a request for clarification RE: the severity of this bug.

I suspect they're going to need to see 0.11.0-5 in unstable to make the
unblock happen, but if you like we can wait for them to comment on the
unblock request.


  Not sure what the best way forward is; adding a test for Temporary
  failure in name resolution might be an option (and works
  unsurprisingly):
 
  #v+
  --- a/test.c
  +++ b/test.c
  @@ -286,7 +286,8 @@
   c = redisConnect((char*)idontexist.local, 6379);
   test_cond(c-err == REDIS_ERR_OTHER 
   (strcmp(c-errstr,Name or service not known) == 0 ||
  - strcmp(c-errstr,Can't resolve: idontexist.local) == 0));
  + strcmp(c-errstr,Can't resolve: idontexist.local) == 0 ||
  + strcmp(c-errstr,Temporary failure in name resolution) ==
 0));
   redisFree(c);
 
   /*test(Returns error when the port is not open: );
  #v-
 
  But maybe there are better ways to fix this.

 That would make the test kinda useless, but I guess it's no worse than
 disabling
 it completely.


I don't mind this approach if we call out the fact the test was skipped
rather than silently passed, but at that point it's providing the same
value as a test that's been completely disabled ... keeping Tobias'
original patch for now.


-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#770648: hiredis: FTBFS: Test failure

[Tom Lee]

 it with USENETWORK=yes, which
 just makes the test take much longer to fail.

 It would also seem that the source package doesn't honor
 DEB_BUILD_OPTIONS=nocheck, which makes it difficult to disable the tests
 to get
 a package built despite the test failures.
 --
 Daniel Schepler




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#770648: hiredis: FTBFS: Test failure

[Tom Lee]

Thanks so much Daniel for the bug report  Tobi for your patch. I'll get a
new build together over the next day or so.

Alessandro Ghedini has been pretty responsive wrt sponsoring my uploads,
but I'll reach out if I can't get a hold of him.

On Sun, Nov 23, 2014 at 2:52 AM, Tobias Frost t...@debian.org wrote:

 Package: src:hiredis
 Followup-For: Bug #770648

 Dear Maintainer,

 As already mentioned by David, you must not use network when building the
 package,
 even lo might not be available.

 The attached patch disables the network-based tests.

 PS: The pid-file location hardcoded to /tmp looks weird.. Maybe should be
 patched
 to use $CURDIR or a relatie path ?

 If you want me to sponsor that upload, please  ping me.

 --
 tobi

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

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




-- 
*Tom Lee */ http://tomlee.co / @tglee http://twitter.com/tglee

Bug#769685: awscli: FTBFS: ImportError: Failed to import test module: awscli.testutils

[Tom Marble]

Supposedly #769496 fixed this bug, but I continued to
have troubles with 'aws' (from package 'awscli').
I suspect the 'monkey patch' fix is very sensitive to import order (?)

I partial fix was to make this change in
/usr/lib/python3/dist-packages/botocore/awsrequest.py

#from requests.packages.urllib3.connection import HTTPConnection
#from requests.packages.urllib3.connectionpool import HTTPConnectionPool
#from requests.packages.urllib3.connectionpool import HTTPSConnectionPool
from urllib3.connection import HTTPConnection
from urllib3.connectionpool import HTTPConnectionPool
from urllib3.connectionpool import HTTPSConnectionPool

HOWEVER aws is still having some other troubles (which may
or may not be related to this bug).

Regards,

--Tom

$ aws --debug --region us-east-1c ec2 describe-instances
[...]
2014-11-17 11:45:03,723 - MainThread - botocore.endpoint - DEBUG - Exception 
received when sending HTTP request.
Traceback (most recent call last):
  File /usr/lib/python3/dist-packages/urllib3/connectionpool.py, line 516, in 
urlopen
body=body, headers=headers)
  File /usr/lib/python3/dist-packages/urllib3/connectionpool.py, line 304, in 
_make_request
self._validate_conn(conn)
  File /usr/lib/python3/dist-packages/urllib3/connectionpool.py, line 724, in 
_validate_conn
conn.connect()
  File /usr/lib/python3/dist-packages/urllib3/connection.py, line 203, in 
connect
conn = self._new_conn()
  File /usr/lib/python3/dist-packages/urllib3/connection.py, line 133, in 
_new_conn
(self.host, self.port), self.timeout, **extra_kw)
  File /usr/lib/python3/dist-packages/urllib3/util/connection.py, line 64, in 
create_connection
for res in socket.getaddrinfo(host, port, 0, socket.SOCK_STREAM):
  File /usr/lib/python3.4/socket.py, line 534, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -2] Name or service not known


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

Bug#763246: imagevis3d: FTBFS: IO/UVF/ExtendedOctree/Lz4Compression.cpp:53:44: error: 'LZ4_uncompress' was not declared in this scope

[tom fogal]

Since there's not a missing include error, I guess liblz4-dev's version 
was updated and the API changed.


Can anyone confirm?

On 09/28/2014 10:45 AM, David Suárez wrote:

Source: imagevis3d
Version: 3.1.0-3
Severity: serious
Tags: jessie sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20140926 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):

g++ -c -fopenmp -DPACKAGE_MANAGER -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -std=c++0x -fno-strict-aliasing -fopenmp -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 
-fPIC -D_REENTRANT -Wall -W -DLZHAM_ANSI_CPLUSPLUS=1 -D_7ZIP_ST=1 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG 
-DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED 
-I/usr/share/qt4/mkspecs/linux-g++-64 -I. -I/usr/include/qt4/QtCore 
-I/usr/include/qt4/QtGui -I/usr/include/qt4/QtOpenGL -I/usr/include/qt4 -I. 
-IIO/3rdParty/lzham -I/usr/include/lzma -IBasics -IIO/exception 
-I/usr/include/lua5.2 -I/usr/X11R6/include -I. -o 
Build/objects/Lz4Compression.o IO/UVF/ExtendedOctree/Lz4Compression.cpp
IO/UVF/ExtendedOctree/Lz4Compression.cpp: In function 'void 
lz4Decompress(std::shared_ptrunsigned char, std::shared_ptrunsigned char, 
size_t)':
IO/UVF/ExtendedOctree/Lz4Compression.cpp:53:44: error: 'LZ4_uncompress' was not 
declared in this scope
   outputSize);
 ^
make[3]: *** [Build/objects/Lz4Compression.o] Error 1


The full build log is available from:

http://aws-logs.debian.net/ftbfs-logs/2014/09/26/imagevis3d_3.1.0-3_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.



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

Bug#755761: gdm3: Unable to start KDE after last gdm3 upgrade

[Tom Maneiro]

Package: gdm3
Version: 3.12.2-2
Severity: critical
Justification: breaks unrelated software

After today's gdm3 upgrade on testing from 3.8 to 3.12, I'm unable to
sucessfully logon onto my KDE4 setup.

Here is what is happening here: after the gdm3 upgrade, if I try to start a KDE
session by logging in, KDE hangs at the startup screen. Only the harddrive
icon is shown. System remains responsive (can switch to VTs, can SSH in, mouse
pointer still moves...). If I launch a task manager (like htop), there are
about 3 kdeinit4 process in a tree:
/usr/bin/kdeinit4 --oom-pipe 4 +kcminit_startup
CPU load during this hang remains at zero. There is no disk activity present.
For all effects the system sat there, idle.

After poking a bit those hung kdeinit4 processes with GDB, if I kill the one
with the following backtrace:
#0  0x7f38346195c0 in __read_nocancel () at ../sysdeps/unix/syscall-
template.S:81
#1  0x004070d5 in _start ()
KDE resumes startup as usual (it's almost always the second-to-last kdeinit4
process in the tree). Another workaround is to switch to a different login
manager (be it kdm or LightDM), and in such case KDE starts up without
incident, but these aren't really good options to me as I like using GDM.

Yesterday's systemd-sysv update doesn't seem to be relevant to this case, as
the older version of gdm3 worked fine until today, when I received the faulty
upgrade.



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

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

Versions of packages gdm3 depends on:
ii  accountsservice  0.6.37-2
ii  adduser  3.113+nmu3
ii  dconf-cli0.20.0-2
ii  dconf-gsettings-backend  0.20.0-2
ii  debconf [debconf-2.0]1.5.53
ii  gir1.2-gdm3  3.12.2-2
ii  gnome-session [x-session-manager]3.12.1-3
ii  gnome-session-bin3.12.1-3
ii  gnome-session-flashback [x-session-manager]  3.8.0-3
ii  gnome-settings-daemon3.12.2-1
ii  gnome-shell  3.12.2-3
ii  gnome-terminal [x-terminal-emulator] 3.12.3-1
ii  gsettings-desktop-schemas3.12.2-1
ii  kde-window-manager [x-window-manager]4:4.11.9-1
ii  konsole [x-terminal-emulator]4:4.13.1-1
ii  libaccountsservice0  0.6.37-2
ii  libatk1.0-0  2.12.0-1
ii  libaudit11:2.3.7-1
ii  libc62.19-7
ii  libcairo-gobject21.12.16-2
ii  libcairo21.12.16-2
ii  libcanberra-gtk3-0   0.30-2
ii  libcanberra0 0.30-2
ii  libgdk-pixbuf2.0-0   2.30.7-1
ii  libgdm1  3.12.2-2
ii  libglib2.0-0 2.40.0-3
ii  libglib2.0-bin   2.40.0-3
ii  libgtk-3-0   3.12.2-1+b1
ii  libpam-modules   1.1.8-3
ii  libpam-runtime   1.1.8-3
ii  libpam-systemd   208-6
ii  libpam0g 1.1.8-3
ii  libpango-1.0-0   1.36.3-1
ii  libpangocairo-1.0-0  1.36.3-1
ii  librsvg2-common  2.40.2-1
ii  libselinux1  2.3-1
ii  libsystemd-daemon0   208-6
ii  libsystemd-id128-0   208-6
ii  libsystemd-journal0  208-6
ii  libsystemd-login0208-6
ii  libwrap0 7.6.q-25
ii  libx11-6 2:1.6.2-2
ii  libxau6  1:1.0.8-1
ii  libxdmcp61:1.1.1-1
ii  libxrandr2   2:1.4.2-1
ii  lsb-base 4.1+Debian13
ii  marco [x-window-manager] 1.8.1+dfsg1-1
ii  mate-session-manager [x-session-manager] 1.8.1-4
ii  mate-terminal [x-terminal-emulator]  1.8.0+dfsg1-3
ii  metacity [x-window-manager]  1:2.34.13-1
ii  policykit-1  0.105-6
ii  ucf  3.0030
ii  x11-common   1:7.7+7
ii  x11-xserver-utils7.7+3
ii  xterm [x-terminal-emulator]  308-1

Bug#712999: Here too

[Tom Laermans]

Same issue here, but not always.

CPU:
model name  : Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz

Controller:
00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset 
6-Port SATA AHCI Controller (rev 06)


Kernel 3.14-0.bpo.1-amd64

Stock wheezy kernel untested as its C600 driver is bugged so it really 
doesn't find any drives/lvs to mount.


--
Tom Laermans
IT Infrastructure Manager
Luciad NV - http://www.luciad.com
Gaston Geenslaan 11, 3001 Heverlee, Belgium


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

Bug#743182: mediawiki: Mediawiki broken after security update

[Tom Laermans]

Package: mediawiki
Version: 1:1.19.14+dfsg-0+deb7u1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Updating from 1:1.19.5-1+deb7u1 to 1:1.19.14+dfsg-0+deb7u1 on Debian Wheezy, 
leads to the following errors in the apache
log:

[Mon Mar 31 11:12:45 2014] [error] [client 192.168.1.1] PHP Warning:  
require(/var/lib/mediawiki/includes/libs/HttpStatus.php): failed to open 
stream: No such file or directory in 
/usr/share/mediawiki/includes/AutoLoader.php on line 1009
[Mon Mar 31 11:12:45 2014] [error] [client 192.168.1.1] PHP Fatal error:  
require(): Failed opening required 
'/var/lib/mediawiki/includes/libs/HttpStatus.php' 
(include_path='/var/lib/mediawiki:/var/lib/mediawiki/includes:/var/lib/mediawiki/languages:/var/lib/mediawiki:/var/lib/mediawiki/includes:/var/lib/mediawiki/languages:.:/usr/share/php:/usr/share/pear')
 in /usr/share/mediawiki/includes/AutoLoader.php on line 1009

Confirm:

root@puppet-test:~# dpkg -L mediawiki|grep HttpStatus
root@puppet-test:~# 

Contrary to what https://packages.debian.org/wheezy/all/mediawiki/filelist
is listing.

Previous package:

root@pluto:~# dpkg -L mediawiki|grep HttpStatus
/usr/share/mediawiki/includes/libs/HttpStatus.php

Reverting to 1:1.19.5-1+deb7u1 fixes this issue.

I'm using the LDAP auth package as well but at first sight this doesn't matter.

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

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/dash

Versions of packages mediawiki depends on:
ii  apache2  2.2.22-13+deb7u1
ii  apache2-mpm-prefork [httpd]  2.2.22-13+deb7u1
ii  debconf [debconf-2.0]1.5.49
ii  libjs-jquery 1.7.2+dfsg-1
ii  libjs-jquery-cookie  6-1
ii  libjs-jquery-form6-1
ii  libjs-jquery-tipsy   6-1
ii  mime-support 3.52-1
ii  php5 5.4.4-14+deb7u8
ii  php5-mysql   5.4.4-14+deb7u8

Versions of packages mediawiki recommends:
ii  mediawiki-extensions-base  3.5~deb7u1
ii  mysql-server   5.5.35+dfsg-0+wheezy1
ii  php-wikidiff2  0.0.1+svn109581-1
ii  php5-cli   5.4.4-14+deb7u8
ii  python 2.7.3-4+deb7u1

Versions of packages mediawiki suggests:
pn  clamav none
pn  imagemagick | php5-gd  none
pn  mediawiki-math none
pn  memcached  none

-- debconf information:
  mediawiki/webserver: apache2


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

Bug#742461: mate-settings-daemon enters a infinite crash/restart loop

[Tom Maneiro]

Package: mate-settings-daemon
Version: 1.8.0-1
Severity: grave
Justification: renders package unusable

After doing a apt dist-update last night, several core components of MATE were
upgraded to 1.8 on my Jessie system.

Normally I use KDE, but from time to time I also use MATE, but since that
update I've been unable to reach a stable desktop. Everything starts to flicker
badly: panels, menus, tray icons, desktop icons. Fonts and dialogs switch font
sizes, menus are hard to use, and in general, the overall desktop feels
extremely unstable and sluggish.

Taking a look at dmesg, I find dozens of these:
[  621.039193] traps: mate-settings-d[12942] trap int3 ip:7ff691c3a3c9
sp:7fff62967f40 error:0
[  621.583086] traps: mate-settings-d[12963] trap int3 ip:7f6cf8dbc3c9
sp:7fff2c45d9e0 error:0
[  622.144056] traps: mate-settings-d[12982] trap int3 ip:7f8023b6d3c9
sp:7fff476512b0 error:0
[  622.717133] traps: mate-settings-d[13009] trap int3 ip:7f1059c9d3c9
sp:7fff96c0a210 error:0
[  623.261964] traps: mate-settings-d[13034] trap int3 ip:7f10dbc413c9
sp:7fffb5473430 error:0
[  623.819512] traps: mate-settings-d[13061] trap int3 ip:7ff2d2bc13c9
sp:7fff21f21640 error:0
[  624.355532] traps: mate-settings-d[13081] trap int3 ip:7f66db7843c9
sp:7fff11fbecc0 error:0
[  624.899599] traps: mate-settings-d[13108] trap int3 ip:7f14966b33c9
sp:7fff2518efc0 error:0
[  625.463491] traps: mate-settings-d[13135] trap int3 ip:7f1f5019b3c9
sp:7fffb9e93260 error:0
[  626.051037] traps: mate-settings-d[13162] trap int3 ip:7f56a6a813c9
sp:7fff9fea4cb0 error:0
[  626.602089] traps: mate-settings-d[13190] trap int3 ip:7f9c52e473c9
sp:7fff8217cf50 error:0
[  627.186409] traps: mate-settings-d[13217] trap int3 ip:7fc7eaa183c9
sp:74926d10 error:0
[  627.725624] traps: mate-settings-d[13236] trap int3 ip:7f426cf153c9
sp:7fffbbfd2bb0 error:0
[  628.295965] traps: mate-settings-d[13262] trap int3 ip:7f6a982823c9
sp:7fff9418ab50 error:0
[  628.829837] traps: mate-settings-d[13289] trap int3 ip:7f8d9cf5c3c9
sp:7fff50c74520 error:0
[  629.450491] traps: mate-settings-d[13308] trap int3 ip:7f8b2c2663c9
sp:7fff4c84fb30 error:0
[  630.016590] traps: mate-settings-d[13331] trap int3 ip:7f43da0fb3c9
sp:7fff38086700 error:0
[  630.555314] traps: mate-settings-d[13358] trap int3 ip:7fd7a9b503c9
sp:7fff73a05c80 error:0
[  631.119840] traps: mate-settings-d[13386] trap int3 ip:7ff4c042a3c9
sp:7fff48037df0 error:0
[  631.707592] traps: mate-settings-d[13413] trap int3 ip:7f0056e3f3c9
sp:7fff8b866740 error:0
[  632.264920] traps: mate-settings-d[13440] trap int3 ip:7f25142ff3c9
sp:7fffb113ab30 error:0
[  632.814582] traps: mate-settings-d[13467] trap int3 ip:7fb5387d03c9
sp:7fff1a405f10 error:0
which matches the frequency of the desktop flickering, which means that
mate-settings-daemon is at fault (it gets killed, desktop loses settings, it
respawns, icons and widgets gets their colors and fonts back, then it gets
killed again... and repated until I manage to logoff. Hence because of this,
MATE is completely broken on my system.

I've tried switching mate-settings-desktop backends (I had GStreamer, tried
switching to Pulse) since the actual mate-settings-daemon binary seems to live
on those, but to no avail - desktop is still unstable.



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

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

Versions of packages mate-settings-daemon depends on:
ii  mate-settings-daemon-gstreamer  1.8.0-1

mate-settings-daemon recommends no packages.

mate-settings-daemon suggests no packages.

-- no debconf information


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

Bug#729854: graphite-web: Stop working with python-django 1.6

[Tom Bombadil]

Package: graphite-web
Version: 0.9.12+debian-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The python-django package was updated to 1.6.1 recently. Then, graphite-web 
stop working with the following error:
   File /opt/graphite/webapp/graphite/urls.py, line 15, in module
 from django.conf.urls.defaults import *
 ImportError: No module named defaults
As 
http://stackoverflow.com/questions/19962736/django-no-module-named-django-conf-urls-defaults
 say, graphite-web don't work with Django 1.6 without a fix 
(https://github.com/graphite-project/graphite-web/commit/fc3f018544c19b90cc63797d18970a4cc27ef2ad)
 which isn't released in a new version, yet.
Is a backport of the fix possible? Or depend on python-django  1.6?

Thank you very much,
Bonbadil.

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

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

Versions of packages graphite-web depends on:
ii  adduser    3.113+nmu3
ii  libjs-jquery   1.7.2+dfsg-3
ii  libjs-jquery-flot  0.8.1+dfsg-2
ii  libjs-prototype    1.7.1-3
ii  libjs-scriptaculous    1.9.0-2
ii  python 2.7.5-5
ii  python-cairo   1.8.8-1+b2
ii  python-django  1.6-1
ii  python-django-tagging  1:0.3.1-3
ii  python-pyparsing   2.0.1+dfsg1-1
ii  python-simplejson  2.6.2-1
ii  python-sqlite  1.0.1-10
ii  python-tz  2012c-1
ii  python-whisper 0.9.12-1

graphite-web recommends no packages.

Versions of packages graphite-web suggests:
ii  graphite-carbon  0.9.12-1
ii  libapache2-mod-wsgi  3.4-4
ii  python-ldap  2.4.10-1
pn  python-memcache  none
pn  python-mysqldb   none

-- Configuration Files:
/etc/graphite/local_settings.py changed [not included]

-- no debconf information


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

Bug#722277: php-symfony-yaml: can't do basic yaml parsing

[Tom Jones]

Package: php-symfony-yaml
Version: 1.0.6-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The following program:

require_once('SymfonyComponents/YAML/sfYamlParser.php');
$parser = new sfYamlParser();
$res = $parser-parse('
foo:
 - x: X
   y: Y
   z: Z
');

fails and the error message is:

PHP Fatal error:  Uncaught exception 'InvalidArgumentException' with message 
'Unable to parse line 4 (  y: Y).' in 
/usr/share/php/SymfonyComponents/YAML/sfYamlParser.php:252
Stack trace:
#0 /usr/share/php/SymfonyComponents/YAML/sfYamlParser.php(188): 
sfYamlParser-parse('- x: X?  y: Y? ...')
#1 /home/tom/tsk/symfony/bug.php(10): sfYamlParser-parse('?foo:? - x: X? ...')
#2 {main}
  thrown in /usr/share/php/SymfonyComponents/YAML/sfYamlParser.php on line 252


Since this syntax for a list of maps is very basic and the library
fails to read it, the package is unusable for most users.

Upstream is on version 2.3, which can parse the example YAML just fine.

Debian package is on 1.0.6 and just doesn't work.  I note that sid
still has the same version.  It should be upgraded or removed.

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

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

Versions of packages php-symfony-yaml depends on:
ii  pear-symfony-project-channel  1.0-1
ii  php5  5.4.4-14+deb7u4

php-symfony-yaml recommends no packages.

php-symfony-yaml suggests no packages.

-- no debconf information


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

Bug#712105: foomatic-filters: foomatic-rip fails when using bjc250gs driver

[Tom Maneiro]

Package: foomatic-filters
Version: 4.0.17-1
Severity: grave
Justification: renders package unusable

I have a good old Canon BJC-250 printer that I've been using for years on my
Linux stations. Currently it's plugged to an old Pentium box (since it's
parport) running Wheezy which acts as a print server. The printer had worked
flawlessly with older distros/CUPS/foomatic versions, and I'm using the
bjc250gs drivers as it is the fastest driver for it (and it allows to tune some
printer-specific features).

However, since having moved all my systems to Wheezy (i386 and amd64, all clean
installs), the bjc250gs driver is unusable for me, since it always causes
foomatic-rip to end abruptly, and therefore nothing is sent to the printer. I
had enabled debugging messages on CUPS, but found nothing interesting except
for this:

D [12/Jun/2013:20:40:42 -04-30] [Job 57] Options from the PPD file:
D [12/Jun/2013:20:40:42 -04-30] [Job 57]
D [12/Jun/2013:20:40:42 -04-30] [Job 57]

D [12/Jun/2013:20:40:42 -04-30] [Job 57]
D [12/Jun/2013:20:40:42 -04-30] [Job 57] File: STDIN
D [12/Jun/2013:20:40:42 -04-30] [Job 57]
D [12/Jun/2013:20:40:42 -04-30] [Job 57]

D [12/Jun/2013:20:40:42 -04-30] [Job 57]
D [12/Jun/2013:20:40:42 -04-30] [Job 57] Filetype: PDF
D [12/Jun/2013:20:40:42 -04-30] [Job 57] Storing temporary files in
/var/spool/cups/tmp
D [12/Jun/2013:20:40:43 -04-30] [Job 57] File contains 1 pages
D [12/Jun/2013:20:40:43 -04-30] [Job 57] Starting renderer with command: gs
-dFirstPage=1  -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE -dNOINTERPOLATE
-sDEVICE=bjccmyk -sPrinterType=BJC-250 -dDEVICEWIDTHPOINTS=612
-dDEVICEHEIGHTPOINTS=792 -r180x180 -sFeeder=Auto -sQuality=Normal
-dInverse=false -dSmooth=false -dCompress=true -dComposeK=false
-dLimitCheck=false -dPaperRed=255 -dPaperGreen=255 -dPaperBlue=255
-dRedGamma=1.0 -dGreenGamma=1.0 -dBlueGamma=1.0 -dGamma=1.0 -dRandom=15
-sOutputFile=-   /var/spool/cups/tmp/foomatic-WeJjFP
D [12/Jun/2013:20:40:43 -04-30] [Job 57] Starting process kid3 (generation 1)
D [12/Jun/2013:20:40:43 -04-30] [Job 57] Starting process kid4 (generation 2)
D [12/Jun/2013:20:40:43 -04-30] [Job 57] Starting process renderer
(generation 2)
D [12/Jun/2013:20:40:43 -04-30] [Job 57] JCL: 2345X@PJL
D [12/Jun/2013:20:40:43 -04-30] [Job 57] job data
D [12/Jun/2013:20:40:43 -04-30] [Job 57]
D [12/Jun/2013:20:40:43 -04-30] [Job 57] renderer received signal 11
D [12/Jun/2013:20:40:43 -04-30] [Job 57] Kid3 exit status: 1
D [12/Jun/2013:20:40:43 -04-30] PID 10226 (/usr/lib/cups/filter/foomatic-rip)
stopped with status 9.

It happens on ALL of my Wheezy installs (ranging from that old Pentium MMX-225
box all the way up to a Sandy Bridge i5 laptop). My only workaround is to use
the Gutenprint driver, which not only is slower, but harder to set up and
getting good print quality from that one is not exactly straightforward, unlike
with bjc250gs.

Trying to find documentation or useful resources online with foomatic-related
errors it's like a shot in the dark, because there is nothing clear, just
dozens and dozens of users with the same error, but on different printer/driver
combinations, none of those apply to my case.



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

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

Versions of packages foomatic-filters depends on:
ii  bash   4.2+dfsg-0.1
ii  debconf [debconf-2.0]  1.5.49
ii  libc6  2.13-38
ii  libdbus-1-31.6.8-1
ii  ucf3.0025+nmu3

Versions of packages foomatic-filters recommends:
ii  colord  0.1.21-1
ii  cups1.5.3-5
ii  cups-bsd [lpr]  1.5.3-5
ii  cups-client 1.5.3-5
ii  foomatic-db-engine  4.0.8-3
ii  ghostscript 9.05~dfsg-6.3
ii  poppler-utils   0.18.4-6

foomatic-filters suggests no packages.

-- debconf information:
  foomatic-filters/ps_accounting: true
  foomatic-filters/custom_textfilter:
  foomatic-filters/title:
  foomatic-filters/config_parsed: true
  foomatic-filters/spooler: cups
  foomatic-filters/textfilter: Automagic
  foomatic-filters/filter_debug: false


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

Bug#708983: closed by Hideki Yamane henr...@debian.org (Bug#708983: fixed in net-snmp 5.7.2~dfsg-6)

[Tom Nicholls]

On 25/05/13 13:57, Adam D. Barratt wrote:


Ah, I see. This is a side-effect of the fact that hplip hasn't been
rebuilt against libsnmp30 yet.


Ah, thanks - I wasn't aware that libsnmp15 was being deprecated. That 
makes sense.


 This will sort itself out as the

transition progresses, but in the meantime keeping the old version of
the net-snmp packages installed would be the right thing to do in this
case.


Thanks.


Unfortunately this sort of thing will happen sometimes in unstable,
particularly for packages involved in a transition.


Sure. A certain amount of package breakage is inevitable when tracking 
unstable. It just looked to me as if the fix on this bug was designed to 
prevent this particular dependency issue. Clearly not :-)


T


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

Bug#708983: closed by Hideki Yamane henr...@debian.org (Bug#708983: fixed in net-snmp 5.7.2~dfsg-6)

[Tom Nicholls]

On 25/05/13 10:52, Adam D. Barratt wrote:

On Sat, 2013-05-25 at 01:27 +0100, Tom Nicholls wrote:

This change seems to have created a dependency conflict for libhpmud0,
which is required for the main printer-driver-hpcups package. libhpmud0
depends on both libsnmp15 and libsnmp-base, but libsnmp15 is no longer
installable because of the conflict with libsnmp-base.

The consequence of this was that HP printers stopped working! Fixed only
by forcibly downgrading libsnmp-base to 5.4.3.


Which version are you trying to install? -7 no longer has a conflicts,
but a versioned Breaks / Replaces which should work okay.


It's with -7. aptitude output is as follows:

tom@maturin:~$ sudo aptitude install libsnmp-base=5.7.2~dfsg-7
The following packages will be upgraded:
  libsnmp-base{b}
1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/1,565 kB of archives. After unpacking 574 kB will be used.
The following packages have unmet dependencies:
 libsnmp-base : Breaks: libsnmp15 ( 5.7.2~dfsg-5) but 5.4.3~dfsg-3 is 
installed.

The following actions will resolve these dependencies:

 Remove the following packages:
1) libhpmud0
2) libsnmp15
3) printer-driver-hpcups

 Leave the following dependencies unresolved:
4) printer-driver-all recommends printer-driver-hpcups


I'm relatively new to handling dependency conflicts, so it's possible 
I'm doing something wrong - if so, I'd be grateful if you could let me know.


Thanks,
T


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

Bug#708983: closed by Hideki Yamane henr...@debian.org (Bug#708983: fixed in net-snmp 5.7.2~dfsg-6)

[Tom Nicholls]

This change seems to have created a dependency conflict for libhpmud0, 
which is required for the main printer-driver-hpcups package. libhpmud0 
depends on both libsnmp15 and libsnmp-base, but libsnmp15 is no longer 
installable because of the conflict with libsnmp-base.


The consequence of this was that HP printers stopped working! Fixed only 
by forcibly downgrading libsnmp-base to 5.4.3.


T


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

Bug#708267: cve-2002-2443: kpasswd udp ping-pong

[Tom Yu]

Florian Weimer f...@deneb.enyo.de writes:

 * Tom Yu:

 Some limited testing indicates that when the packet storm is confined
 to a single host, legitimate kpasswd and kadm5 requests can still get
 through, and the CPU usage pegs at about 70%.  I haven't tested with
 multiple hosts involved.

 Out of curiosity, how many spoofed packets have you injected?

I only did some proof of concept testing with a single spoofed packet.


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

Bug#705820: texstudio: FTBFS on several architectures (error: 'REG_EIP' was not declared in this scope)

[Tom Jampen]

tags 705820 + fixed-upstream pending
thanks

Hi Adam

I filed an upstream bug when I saw the build logs. The bug has already been
fixed and I'm waiting for the next upstream release.

Regards
Tom


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

Bug#704775: Processed: found 704775 in 1.8.3+dfsg-4squeeze6

[Tom Yu]

Sam Hartman hartm...@debian.org writes:

 My recommendation is that this is not worth a DSA or stable fix for
 squeeze unless some Debian user comes forward and says that they're
 seeing crashes in the wild related to this.

 --Sam

Keep in mind that unmodified client software can trivially trigger
this vulnerability.  I can do an explicit check of the trigger against
the 1.8 branch if you'd like confirmation.


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

Bug#702999: SIGSEGVs sometimes when compiling, loosing all work

[Tom Jampen]

tags 702999 + unreproducible
thanks


Hi Javier

I haven't been able to reproduce this bug with the tex documents I'm
using/writing. Can you provide a sample tex file showing this behavior?

The F-Keys are assigned to different commands (pdftex, dvips, ps2pdf, ...).
Which one(s) of these commands is/are leading to SIGABRT?

Loosing all work sounds pretty extreme. Do you mean 'loosing unsaved
changes'? Saved files are not corrupted/deleted, right?

Thanks for clarifying
Tom


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

Bug#702999: SIGSEGVs sometimes when compiling, loosing all work

[Tom Jampen]

On 21.03.2013 19:07, Javier Domingo wrote:
 Well, this is something that happens randomly, there is no sample tex
 file I can provide, but I can reproduce it, and provided a backtrace,
 is there anything else I can/should provide to help you fix the bug?

I've contacted upstream, let's see what they find out. I'll keep you posted.


 The only way to reproduce it I have found is to work with it for hours
 and sometimes, it will fail when I press F1 to Quick Build. To get
 that bt, I had been working for 5 hours...

What do you use as quick build command (pdflatex and pdf viewer, or...)?


 About loosing work, yes, sorry I should have put unsaved work, but I
 am accustomed to use F1 to save, and that is the moment in which it
 crashes ;).

OK, I'm glad it's not that bad. I'm reducing severity to important and I'll
change the bug title to reflect SIGABRT.


 I have had all those problems while working on
 http://github.com/txomon/pfc projects. The main files are under the
 folder with the same name.

Thanks, I'll give it a try. I'm using TeXstudio a lot, but usually not for hours
at a time.


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

Bug#699470: crystalhd-dkms: Kernel null pointer BUG in crystalhd_dioq_fetch_wait()

[tom schorpp]

Package: crystalhd-dkms
Version: 1:0.0~git20110715.fdd2f19-7
Severity: critical
Tags: patch
Justification: breaks the whole system

Reproducible NULL pointer BUG at 
crystalhd-0.0~git20110715.fdd2f19/driver/linux/crystalhd_misc.c:515, 
triggered by adobe flash plugin from dmo repo, ffmpeg, mplayer, bino or other, 
mostly on heavy ioq usage 
or after FETCH_TIMEOUT and/or unclosed driver HANDLEs.

Your package is affected, reproducible on all 3.x kernel.org stable kernel 
versions.

Subsequent driver access without reboot or after rmmod -f  modprobe again 
will trigger kernel freeze by 
kernel unhandled paging request.

This patch has fixed this bug for me until now.

Upstream maintainer/owner of codebase host git.linuxtv.org or Broadcom authors 
have not responded yet, 
but affected BCM70015 chip hardware is still in production state and 
wholeselling as mini-PCI-E card.

Signed-off-by: Thomas Schorpp thomas.scho...@gmail.com

y
tom

8043-Jan 24 18:33:14 tom3 kernel: [  457.636878] BUG: unable to handle kernel 
NULL pointer dereference at 002c
8044:Jan 24 18:33:14 tom3 kernel: [  457.637016] IP: [a043a14c] 
crystalhd_dioq_fetch_wait+0x25c/0x410 [crystalhd]
8045-Jan 24 18:33:14 tom3 kernel: [  457.637150] PGD 631fe067 PUD 57474067 PMD 0
8046-Jan 24 18:33:14 tom3 kernel: [  457.637238] Oops:  [#1] PREEMPT SMP
8047-Jan 24 18:33:14 tom3 kernel: [  457.637326] CPU 0
8048-Jan 24 18:33:14 tom3 kernel: [  457.637361] Modules linked in: uinput 
parport_pc ppdev lp parport bluetooth nfsd lockd nfs_acl auth_rpcgss sunrpc 
exportfs acpi_cpufreq mperf cpufreq_powersave cpufreq_stats 
cpufreq_conservative cpufreq_performance cpufreq_ondemand freq_table fuse 
dm_mod ext3 jbd pciehp arc4 ath5k ath snd_hda_codec_analog mac80211 cfg80211 
snd_hda_intel snd_hda_codec snd_usb_audio thinkpad_acpi snd_pcm_oss 
snd_mixer_oss snd_hwdep rfkill snd_pcm snd_usbmidi_lib snd_seq_dummy 
snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer 
snd_seq_device gspca_zc3xx gspca_main snd videodev pcmcia usb_storage 
v4l2_compat_ioctl32 psmouse yenta_socket tpm_tis pcmcia_rsrc crystalhd(O) 
snd_page_alloc soundcore tpm pcmcia_core tpm_bios pcspkr serio_raw i2c_i801 
nvram wmi rtc_cmos battery ac evdev processor nf_conntrack_ipv6 nf_defrag_ipv6 
ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state 
nf_conntrack xt_limit xt_tcpudp iptable_filter ip
 _tables 
 x
_tables ext4 mbcache jbd2 crc16
8049-Jan 24 18:33:14 tom3 kernel: usbhid hid sg sd_mod crc_t10dif ata_generic 
uhci_hcd ahci libahci ata_piix atkbd libata thermal xhci_hcd ehci_hcd usbcore 
e1000e usb_common [last unloaded: scsi_wait_scan]
8050-Jan 24 18:33:14 tom3 kernel: [  457.637841]
8051-Jan 24 18:33:14 tom3 kernel: [  457.637841] Pid: 6318, comm: ffmpeg 
Tainted: G   O 3.2.36-dirty #7 LENOVO 7735Y1T/7735Y1T
8052:Jan 24 18:33:14 tom3 kernel: [  457.637841] RIP: 0010:[a043a14c] 
 [a043a14c] crystalhd_dioq_fetch_wait+0x25c/0x410 [crystalhd]
8053-Jan 24 18:33:14 tom3 kernel: [  457.637841] RSP: 0018:88006300dd48  
EFLAGS: 00010246
8054-Jan 24 18:33:14 tom3 kernel: [  457.637841] RAX:  RBX: 
88007b1cde50 RCX: 
8055-Jan 24 18:33:14 tom3 kernel: [  457.637841] RDX: 0046 RSI: 
a04395c3 RDI: 81493e82
8056-Jan 24 18:33:14 tom3 kernel: [  457.637841] RBP: 88006300ddf8 R08: 
 R09: 
8057-Jan 24 18:33:14 tom3 kernel: [  457.637841] R10:  R11: 
88007b1ce510 R12: 88007a855d80
8058-Jan 24 18:33:14 tom3 kernel: [  457.637841] R13:  R14: 
88007a855da8 R15: 88007b1cde50
8059-Jan 24 18:33:14 tom3 kernel: [  457.637841] FS:  7f559fa7b760() 
GS:88007f40() knlGS:
8060-Jan 24 18:33:14 tom3 kernel: [  457.637841] CS:  0010 DS:  ES:  
CR0: 80050033
8061-Jan 24 18:33:14 tom3 kernel: [  457.637841] CR2: 002c CR3: 
5747 CR4: 06f0
8062-Jan 24 18:33:14 tom3 kernel: [  457.637841] DR0:  DR1: 
 DR2: 
8063-Jan 24 18:33:14 tom3 kernel: [  457.637841] DR3:  DR6: 
0ff0 DR7: 0400
8064-Jan 24 18:33:14 tom3 kernel: [  457.637841] Process ffmpeg (pid: 6318, 
threadinfo 88006300c000, task 88007b1cde50)
8065-Jan 24 18:33:14 tom3 kernel: [  457.637841] Stack:
8066-Jan 24 18:33:14 tom3 kernel: [  457.637841]  0327 
88007b1ce510 88006b199400 88007c1b1090
8067-Jan 24 18:33:14 tom3 kernel: [  457.637841]  88006300de14 
8800594145b0 880059414400 88007b1cde50
8068-Jan 24 18:33:14 tom3 kernel: [  457.637841]  88007a855de0 
000100026d5c  88007b1cde50
8069-Jan 24 18:33:14 tom3 kernel: [  457.637841] Call Trace:
8070-Jan 24 18:33:14 tom3 kernel: [  457.637841]  [810497e0] ? 
try_to_wake_up+0x260/0x260
8071-Jan 24 18:33:14 tom3 kernel: [  457.637841

Bug#675913: ldirectord failed to start, RFC2553 compatible getaddrinfo/getnameinfo

[Tom Fernandes]

Package: resource-agents
Followup-For: Bug #675913

Hi,

I'm hitting the same bug. It's present in the version in testing (1:3.9.2-5) and
in the version in unstable (1:3.9.3+git20121009-1).

I modified the initially attached patch as the offsets did not apply any more
for the current verion in testing and tested it. It seems to work correctly
although I haven't done intesive testing yet.

Zang - where does this patch come from and are you running it in production use?

I'm not in the position to dive into the code that deep to verify, that it
doesn't have any side effects.

As the issue still persists in version 1:3.9.3+git20121009-1 it looks like that
upstream hasn't yet fixed this issue.

It would be nice to have a working HA-stack for wheezy :-) .

warm regards and thanks for the good work,


Tom



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

Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- resource-agents-3.9.2.orig/ldirectord/ldirectord.in
+++ resource-agents-3.9.2/ldirectord/ldirectord.in
@@ -828,7 +828,8 @@ use Pod::Usage;
 #use English;
 #use Time::HiRes qw( gettimeofday tv_interval );
 use Socket;
-use Socket6;
+use Socket::GetAddrInfo qw( getaddrinfo getnameinfo NI_NUMERICHOST NI_NUMERICSERV NI_NAMEREQD );
+#use Socket6;
 use Sys::Hostname;
 use POSIX qw(setsid :sys_wait_h);
 use Sys::Syslog qw(:DEFAULT setlogsock);
@@ -5039,17 +5040,21 @@ sub ld_gethostbyname
if ($name =~ /\[(.*)\]/) {
$name = $1;
}
-   my @host = getaddrinfo($name, 0, $af);
-   if (!defined($host[3])) {
-   return undef;
-   }
-   my @ret = getnameinfo($host[3], NI_NUMERICHOST | NI_NUMERICSERV);
-   if ($host[0] == AF_INET6) {
-   return [$ret[0]];
-   }
-   else {
-   return $ret[0];
-   }
+  my %hints = ( family = $af );
+  my ( $err, @res ) = getaddrinfo($name, 0, \%hints);
+  return undef if ($err);
+  while( my $ai = shift @res ) {
+my ( $err, $hostname, $servicename ) = getnameinfo( $ai-{addr} );
+if (!$err) {
+  if ($ai-{family} == AF_INET6) {
+return [$hostname];
+  }
+  else {
+return $hostname;
+  }
+}
+  }
+  return undef;
 }
 
 # ld_gethostbyaddr
@@ -5064,13 +5069,12 @@ sub ld_gethostbyaddr
my ($ip)=(@_);
 
$ip = ld_strip_brackets($ip);
-   my @host = getaddrinfo($ip,0);
-   if (!defined($host[3])) {
-   return undef;
+  my ( $err, @res ) = getaddrinfo($ip,0);
+  return undef if ($err);
+  while( my $ai = shift @res ) {
+my ( $err, $host, $service ) = getnameinfo($ai-{addr}, NI_NAMEREQD);
+return $host unless($err);
}
-   my @ret = getnameinfo($host[3], NI_NAMEREQD);
-   return undef unless(scalar(@ret) == 2);
-   return $ret[0];
 }
 
 # ld_getservbyname

Bug#688328: spatialite-gui: Unable to create new SQLite DB

[Tom Gottfried]

Package: spatialite-gui
Version: 1.2.1-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

after starting spatialite-gui, click 'Files' - 'Creating a new (empty) SQLite
DB', chose a filename and location.
An error message comes:

'CreateSpatialMetaData error: no such table: spatial_ref_sys'

click OK. Next error:
'CreateSpatialMetaData error: cannot rollback - no transaction is active'

Keep clicking OK: the error comes again and again. spatialite-gui can only be
stop by killing the process.

if any other information is needed, please ask! Thanks!
Regards,
Tom



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

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

Versions of packages spatialite-gui depends on:
ii  libc6   2.13-35
ii  libgcc1 1:4.7.1-7
ii  libgeos-c1  3.3.3-1.1
ii  libproj04.7.0-2
ii  librasterlite1  1.1~svn11-2
ii  libspatialite3  3.0.0~beta20110817-3
ii  libsqlite3-03.7.13-1
ii  libstdc++6  4.7.1-7
ii  libwxbase2.8-0  2.8.12.1-11
ii  libwxgtk2.8-0   2.8.12.1-11

spatialite-gui recommends no packages.

spatialite-gui suggests no packages.

-- no debconf information


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

Bug#683288: rt-authen-externalauth: privilege escalation

[Tom Jampen]

tag 683288 pending
thanks

On 30.07.2012 16:55, Yves-Alexis Perez wrote:
 For Wheezy, please fix this  with an isolated fix instead of updating to a
 new upstream release (since the freeze is in effect)

Fixed in git.
Tom


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

Bug#678583: texstudio: missing build dependency on zlib1g-dev

[Tom Jampen]

tag 678583 pending
thanks

On 22.06.2012 23:53, Pino Toscano wrote:
 as a followup of #675497: when doing my rebuilds for the drop of
 libfontconfig1-dev from libpoppler-dev, apparently I noted only
 pkg-config (already fixed, thanks!) as missing for texstudio... while
 there's also zlib1g-dev that is lacking :-/ (and zlib is used by the
 synctex code); it was previously pulled by the dependency chain:

Fixed in git.
Tom



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

Bug#650541: libsmbclient uses internal symbol krb5_locate_kdc

[Tom Epperly]

Package: samba
Version: 2:3.6.1-2
Followup-For: Bug #650541

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

#  apt-get dist-upgrade -u
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  cups-driver-gutenprint gcj-jre-headless grass libgmerlin-avdec1
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]? 
Setting up samba (2:3.6.1-2) ...
Starting Samba daemons: nmbd/usr/sbin/nmbd: relocation error: /usr/sbin/nmbd: 
symbol krb5_locate_kdc, version krb5_3_MIT not defined in file libkrb5.so.3 
with link time reference
 failed!
invoke-rc.d: initscript samba, action start failed.
dpkg: error processing samba (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of swat:
 swat depends on samba (= 2:3.6.1-2); however:
  Package samba is not configured yet.
dpkg: error processing swat (--configure):
 dependency problems - leaving unconfigured
configured to not write apport reports
  configured to not write apport reports
Errors were encountered while processing:
 samba
 swat
E: Sub-process /usr/bin/dpkg returned an error code (1)

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


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

Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages samba depends on:
ii  adduser3.113 
ii  debconf [debconf-2.0]  1.5.41
ii  libacl12.2.51-4  
ii  libattr1   1:2.4.46-3
ii  libc6  2.13-21   
ii  libcap21:2.22-1  
ii  libcomerr2 1.42-1
ii  libcups2   1.5.0-12  
ii  libgssapi-krb5-2   1.10+dfsg~alpha1-5
ii  libk5crypto3   1.10+dfsg~alpha1-5
ii  libkrb5-3  1.10+dfsg~alpha1-5
ii  libldap-2.4-2  2.4.25-4+b1   
ii  libpam-modules 1.1.3-6   
ii  libpam-runtime 1.1.3-6   
ii  libpam0g   1.1.3-6   
ii  libpopt0   1.16-1
ii  libtalloc2 2.0.7-3   
ii  libtdb11.2.9-4+b1
ii  libwbclient0   2:3.6.1-2 
ii  lsb-base   3.2-28
ii  procps 1:3.3.0-1 
ii  samba-common   2:3.6.1-2 
ii  update-inetd   4.41  
ii  zlib1g 1:1.2.3.4.dfsg-3  

Versions of packages samba recommends:
pn  logrotate  3.7.8-6
pn  tdb-tools  none 

Versions of packages samba suggests:
pn  ctdb  none  
pn  ldb-tools none  
pn  openbsd-inetd [inet-superserver]  0.20091229-1
pn  smbldap-tools none  

-- debconf information:
  samba/tdbsam: false
  samba/generate_smbpasswd: true
  samba/run_mode: daemons
  samba-common/title:



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

Bug#639875: fglrx-driver: xorg-video-abi-11

[Tom Marble]

Way back on 4 november, Patrick wrote:
 11-11 will be compatible with it, I just tested the next version.

ATI just released this version.  I tried building it with the
11-10 packaging and failed with errors like:

dpkg-source: warning: ignoring deletion of directory arch/x86/etc
dpkg-source: warning: ignoring deletion of directory arch/x86/etc/OpenCL
dpkg-source: warning: ignoring deletion of directory arch/x86/etc/OpenCL/vendors
dpkg-source: warning: ignoring deletion of file 
arch/x86/etc/OpenCL/vendors/amdocl32.icd
dpkg-source: warning: ignoring deletion of file arch/x86/usr/lib/libOpenCL.so.1
dpkg-source: warning: ignoring deletion of file arch/x86/usr/lib/libamdocl32.so
dpkg-source: warning: ignoring deletion of directory arch/x86/usr/bin
dpkg-source: warning: ignoring deletion of file arch/x86/usr/bin/clinfo
dpkg-source: warning: ignoring deletion of directory arch/x86_64/etc
dpkg-source: warning: ignoring deletion of directory arch/x86_64/etc/OpenCL
dpkg-source: warning: ignoring deletion of directory 
arch/x86_64/etc/OpenCL/vendors
dpkg-source: warning: ignoring deletion of file 
arch/x86_64/etc/OpenCL/vendors/amdocl64.icd
dpkg-source: warning: ignoring deletion of file 
arch/x86_64/usr/lib64/libOpenCL.so.1
dpkg-source: warning: ignoring deletion of file 
arch/x86_64/usr/lib64/libamdocl64.so
dpkg-source: warning: ignoring deletion of directory arch/x86_64/usr/bin
dpkg-source: warning: ignoring deletion of file arch/x86_64/usr/bin/clinfo
dpkg-source: error: cannot represent change to 
fglrx-driver-11-11/xpic_64a/usr/X11R6/lib64/modules/glesx.so: binary file 
contents changed

I didn't have the patience to diff the new upstream format and so...

However I did install the ATI driver *directly* (with the side effect
that my filesystem is now corrupted with files not tracked by dpkg)
and the driver does indeed work.  I am now running on (unstable+experimental):
Linux ordi 3.1.0-1-amd64 #1 SMP Mon Nov 14 08:02:25 UTC 2011 x86_64 GNU/Linux

There are some random screen flickers, but I am now enjoying Gnome 3.
(I have not tried fancy things like adding a projector, etc.)

Regards,

--Tom



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

Bug#639875: fglrx-driver: xorg-video-abi-11

[Tom Marble]

All:

I can confirm the segfault with 11-10 :(

[42.897] 0: /usr/bin/Xorg (xorg_backtrace+0x26) [0x7fcea52478f6]
[42.897] 1: /usr/bin/Xorg (0x7fcea50c3000+0x188559) [0x7fcea524b559]
[42.897] 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fcea43eb000+0xf020) 
[0x7fcea43fa020]
[42.898] 3: /usr/lib/xorg/modules/drivers/fglrx_drv.so 
(xs110SetPrivate+0x27) [0x7fcea0d450f7]
[42.899] 4: /usr/lib/xorg/modules/drivers/fglrx_drv.so (xclSetPrivate+0xd) 
[0x7fcea07876bd]
[42.899] 5: /usr/lib/xorg/modules/drivers/fglrx_drv.so 
(xdl_xs110_swlDriScreenInit+0xfd) [0x7fcea089b27d]
[42.900] 6: /usr/lib/xorg/modules/drivers/fglrx_drv.so 
(xdl_xs110_atiddxDriScreenInit+0x347) [0x7fcea0883807]
[42.900] 7: /usr/lib/xorg/modules/drivers/fglrx_drv.so 
(xdl_xs110_atiddxScreenInit+0xc49) [0x7fcea087c259]
[42.901] 8: /usr/bin/Xorg (AddScreen+0x171) [0x7fcea51152a1]
[42.901] 9: /usr/bin/Xorg (InitOutput+0x29c) [0x7fcea515163c]
[42.901] 10: /usr/bin/Xorg (0x7fcea50c3000+0x40fed) [0x7fcea5103fed]
[42.901] 11: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xfd) 
[0x7fcea3114ead]
[42.901] 12: /usr/bin/Xorg (0x7fcea50c3000+0x414ad) [0x7fcea51044ad]
[42.901] Segmentation fault at address 0x10

I am running unstable with the lastest version of xserver-xorg-core.

In order to test I rebuilt the packages by removing the depends
on old xorg-video-abi-* versions and setting the xserver-xorg-core
depends to be unversioned. Clearly this ABI change is (at least part of)
the problem.

It's a shame because this means, among other things, that we cannot
enjoy Gnome 3 completely.

Regards,

--Tom

p.s. I plan to get an Intel GPU next time w/ Free drivers



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

Bug#639875: fglrx-driver: xorg-video-abi-11

[Tom Marble]

All:

New upstream has just become available... I'll try it soon.

$ wget 
http://www2.ati.com/drivers/linux/ati-driver-installer-11-10-x86.x86_64.run

HTH,

--Tom



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

Bug#646004: python-magic: Missing libmagic1 dependency

[Tom Parker]

Package: python-magic
Version: 5.09-1
Severity: grave
Justification: renders package unusable

The libmagic1 dependency is missing, so we get things like this

palfrey@missfun:[~/src/nih/jukebox] python metadata.py ~/2-09\ Big\ Swifty.mp3  

   =
Traceback (most recent call last):
  File metadata.py, line 15, in module
import magic
  File /usr/lib/python2.6/dist-packages/magic.py, line 94, in module
_list = _libraries['magic'].magic_list
  File /usr/lib/python2.6/ctypes/__init__.py, line 366, in __getattr__
func = self.__getitem__(name)
  File /usr/lib/python2.6/ctypes/__init__.py, line 371, in __getitem__
func = self._FuncPtr((name_or_ordinal, self))
AttributeError: /usr/lib/libmagic.so.1: undefined symbol: magic_list

-- System Information:
Debian Release: 6.0.2
  APT prefers stable
  APT policy: (700, 'stable'), (680, 'unstable'), (670, 'experimental'), (500, 
'stable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

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

Versions of packages python-magic depends on:
ii  python2.6.7-2interactive high-level object-orie
ii  python2.6 2.6.7-3An interactive high-level object-o
ii  python2.7 2.7.2-3An interactive high-level object-o

python-magic recommends no packages.

Versions of packages python-magic suggests:
pn  python-magic-dbg  none (no description available)

-- no debconf information



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

Bug#639875: fglrx-driver: xorg-video-abi-11

[Tom Marble]

All:

I took a chance on rebuilding the driver for the upstream
version 11-9 which was released yesterday. I am running
a custom 3.1.0-rc7 kernel with unstable+experimental amd64 on
an eMachines eME443-BZ602 with a ATI Radeon HD 6250.

And it still segfaults :(

Snippets from Xorg.0.log below.

Regards,

--Tom

[26.028] X Protocol Version 11, Revision 0
[26.028] Build Operating System: Linux 3.1.0-rc4-amd64 x86_64 Debian
[26.028] Current Operating System: Linux ordi 3.1.0-rc7 #4 SMP Wed Sep 
28:37:39 CDT 2011 x86_64
...
[26.774] (II) Loading /usr/lib/xorg/modules/drivers/fglrx_drv.so
[27.189] (II) Module fglrx: vendor=FireGL - ATI Technologies Inc.
[27.206]compiled for 1.4.99.906, module version = 8.89.4
[27.206]Module class: X.Org Video Driver
[27.234] (II) Loading sub module fglrxdrm
[27.234] (II) LoadModule: fglrxdrm
[27.234] (II) Loading /usr/lib/xorg/modules/linux/libfglrxdrm.so
[27.274] (II) Module fglrxdrm: vendor=FireGL - ATI Technologies Inc.
[27.274]compiled for 1.4.99.906, module version = 8.89.4
[27.274] (II) ATI Proprietary Linux Driver Version Identifier:8.89.4
[27.274] (II) ATI Proprietary Linux Driver Release Identifier: 8.892
...
[27.276] (WW) Falling back to old probe method for fglrx
[27.416] (II) Loading PCS database from /etc/ati/amdpcsdb
[27.468] (--) Chipset Supported AMD Graphics Processor (0x9804) found
...
Backtrace:
[29.537] 0: /usr/bin/Xorg (xorg_backtrace+0x26) [0x5689d6]
[29.537] 1: /usr/bin/Xorg (0x40+0x16c5c9) [0x56c5c9]
[29.538] 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f81b7b5a000+0xf020) 
[0x7f81b7b69020]
[29.538] 3: /usr/lib/xorg/modules/drivers/fglrx_drv.so 
(xs110SetPrivate+0x27) [0x7f81b44dfff7]
[29.539] 4: /usr/lib/xorg/modules/drivers/fglrx_drv.so (xclSetPrivate+0xd) 
[0x7f81b3f3833d]
[29.540] 5: /usr/lib/xorg/modules/drivers/fglrx_drv.so 
(xdl_xs110_swlDriScreenInit+0xfd) [0x7f81b404933d]
[29.540] 6: /usr/lib/xorg/modules/drivers/fglrx_drv.so 
(xdl_xs110_atiddxDriScreenInit+0x345) [0x7f81b40318c5]
[29.541] 7: /usr/lib/xorg/modules/drivers/fglrx_drv.so 
(xdl_xs110_atiddxScreenInit+0xc49) [0x7f81b402a369]
[29.541] 8: /usr/bin/Xorg (AddScreen+0x171) [0x437e31]
[29.541] 9: /usr/bin/Xorg (InitOutput+0x29c) [0x473abc]
[29.541] 10: /usr/bin/Xorg (0x40+0x26cdd) [0x426cdd]
[29.542] 11: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xfd) 
[0x7f81b6899ead]
[29.542] 12: /usr/bin/Xorg (0x40+0x2719d) [0x42719d]
[29.542] Segmentation fault at address 0x10





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

Bug#619052: rpc.gssd: double free or corruption

[Tom Boven]

Op 23-03-11 16:32, Kevin Coffman schreef:

2011/3/22 Aníbal Monsalve Salazarani...@debian.org:
   

On Wed, Mar 16, 2011 at 09:28:04PM -0400, Kevin Coffman wrote:
 

A new version of library libgssglue is now available from:

http://www.citi.umich.edu/projects/nfsv4/linux/libgssglue/libgssglue-0.2.tar.gz

Changes since libgssglue-0.1:

   * Modify the gss_acquire_cred() code to accept, and
 properly handle, an input name of GSS_C_NO_NAME.
 Other misc. changes to support this change.
   * Remove some generated files from git.  Change
 autogen.sh to clean up files that might become
 outdated and incompatible.
--
To unsubscribe from this list: send the line unsubscribe linux-nfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
   

Hello Kevin,

Please have a look at Debian bug#619052.

http://bugs.debian.org/619052

The attached file is the original bug report.

Thank you,

Aníbal
 

Hi,
So far, I'm stumped.  I've been unable to reproduce this on my Fedora
13 machine.  I have a slightly different version of libc, an earlier
version of kerberos, and a later version of nfs-utils (the pnfs
version).  I went back to stock versions of everything and simply
replaced libgssglue with the new version.

glibc-2.12.2-1.x86_64
krb5-libs-1.7.1-17.fc13.x86_64
krb5-debuginfo-1.7.1-17.fc13.x86_64
krb5-auth-dialog-0.15-1.fc13.x86_64
krb5-workstation-1.7.1-17.fc13.x86_64
pam_krb5-2.3.11-1.fc13.x86_64
krb5-devel-1.7.1-17.fc13.x86_64
nfs-utils-lib-devel-1.1.5-1.fc13.x86_64
nfs-utils-1.2.3-2.pnfs.fc15.x86_64
nfs-utils-lib-1.1.5-1.fc13.x86_64
nfs-utils-lib-debuginfo-1.1.5-1.fc13.x86_64

Are you using any special options to gssd?

K.C.

   

I've just checked but no, I don't use any option at all to start rpc.gssd

Tom




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

Bug#610320: FTBFS: jug-2.0.0-1 with ant-1.8.1-1 from experimental

[Tom Ellis]

Package: jug
Version: 2.0.0-1
Severity: serious
Justification: fails to build from source

This bug has been forwarded from Ubuntu 
(https://bugs.launchpad.net/ubuntu/+source/jug/+bug/687979), but also tested on 
latest debian sid with ant packages from experimental.

jug-2.0.0-1 fails to build from source with ant-1.8.1-1 from experimental.

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

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



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

Bug#610320: FTBFS: jug-2.0.0-1 with ant-1.8.1-1 from experimental

[Tom Ellis]

Including build logs here.
 dpkg-buildpackage -rfakeroot -D -us -uc
dpkg-buildpackage: warning: using a gain-root-command while being root
dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin: vendor): 
dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor): 
dpkg-buildpackage: source package jug
dpkg-buildpackage: source version 2.0.0-1
dpkg-buildpackage: source changed by Onkar Shinde onkarshi...@ubuntu.com
 dpkg-source --before-build jug-2.0.0
dpkg-buildpackage: host architecture amd64
 fakeroot debian/rules clean
/usr/share/cdbs/1/rules/simple-patchsys.mk:31: WARNING:  simple-patchsys.mk is deprecated - please use source format 3.0 (quilt) instead
test -x debian/rules
dh_testroot
/usr/bin/make -f debian/rules reverse-config
make[1]: Entering directory `/root/src/jug-2.0.0'
/usr/share/cdbs/1/rules/simple-patchsys.mk:31: WARNING:  simple-patchsys.mk is deprecated - please use source format 3.0 (quilt) instead
make[1]: Nothing to be done for `reverse-config'.
make[1]: Leaving directory `/root/src/jug-2.0.0'
if [ reverse-patches = reverse-patches ]; then rm -f debian/stamp-patched; fi
patches: debian/patches/build-xml.diff
Trying reverse patch debian/patches/build-xml.diff at level 1 ... success.
if [ reverse-patches != reverse-patches ]; then touch debian/stamp-patched; fi
if [ reverse-patches != reverse-patches ] ; then \
		/usr/bin/make -f debian/rules update-config ; \
	fi
for dir in debian/patches ; do \
	rm -f $dir/*.log ; \
	done
dh_clean 
cd .  /usr/lib/jvm/default-java/bin/java -classpath /usr/share/ant/lib/ant.jar:/usr/share/ant/lib/ant-launcher.jar:/usr/share/java/log4j-1.2.jar:/usr/share/java/ant-junit.jar:/usr/share/java/junit.jar:/usr/lib/jvm/default-java/lib/tools.jar  -Dant.home=/usr/share/ant org.apache.tools.ant.Main -Dcompile.debug=true -Dcompile.optimize=true clean
Buildfile: /root/src/jug-2.0.0/build.xml

clean:
   [delete] Deleting directory /root/src/jug-2.0.0/build
   [delete] Deleting directory /root/src/jug-2.0.0/doc
   [delete] Deleting directory /root/src/jug-2.0.0/test
   [delete] Deleting directory /root/src/jug-2.0.0/dist

BUILD SUCCESSFUL
Total time: 0 seconds
rm -f debian/stamp-ant-build
rm -f debian/stamp-ant-check
 dpkg-source -b jug-2.0.0
dpkg-source: warning: no source format specified in debian/source/format, see dpkg-source(1)
dpkg-source: info: using source format `1.0'
dpkg-source: info: building jug using existing jug_2.0.0.orig.tar.gz
tar: A lone zero block at 927
dpkg-source: info: building jug in jug_2.0.0-1.diff.gz
dpkg-source: warning: the diff modifies the following upstream files: 
 build.log
dpkg-source: info: use the '3.0 (quilt)' format to have separate and documented changes to upstream files, see dpkg-source(1)
dpkg-source: info: building jug in jug_2.0.0-1.dsc
 debian/rules build
/usr/share/cdbs/1/rules/simple-patchsys.mk:31: WARNING:  simple-patchsys.mk is deprecated - please use source format 3.0 (quilt) instead
test -x debian/rules
mkdir -p .
/usr/bin/make -f debian/rules reverse-config
make[1]: Entering directory `/root/src/jug-2.0.0'
/usr/share/cdbs/1/rules/simple-patchsys.mk:31: WARNING:  simple-patchsys.mk is deprecated - please use source format 3.0 (quilt) instead
make[1]: Nothing to be done for `reverse-config'.
make[1]: Leaving directory `/root/src/jug-2.0.0'
if [ debian/stamp-patched = reverse-patches ]; then rm -f debian/stamp-patched; fi
patches: debian/patches/build-xml.diff
Trying patch debian/patches/build-xml.diff at level 1 ... success.
if [ debian/stamp-patched != reverse-patches ]; then touch debian/stamp-patched; fi
if [ debian/stamp-patched != reverse-patches ] ; then \
		/usr/bin/make -f debian/rules update-config ; \
	fi
make[1]: Entering directory `/root/src/jug-2.0.0'
/usr/share/cdbs/1/rules/simple-patchsys.mk:31: WARNING:  simple-patchsys.mk is deprecated - please use source format 3.0 (quilt) instead
make[1]: Nothing to be done for `update-config'.
make[1]: Leaving directory `/root/src/jug-2.0.0'
cd .  /usr/lib/jvm/default-java/bin/java -classpath /usr/share/ant/lib/ant.jar:/usr/share/ant/lib/ant-launcher.jar:/usr/share/java/log4j-1.2.jar:/usr/share/java/ant-junit.jar:/usr/share/java/junit.jar:/usr/lib/jvm/default-java/lib/tools.jar  -Dant.home=/usr/share/ant org.apache.tools.ant.Main -Dcompile.debug=true -Dcompile.optimize=true jar.asl
Buildfile: /root/src/jug-2.0.0/build.xml

prepare:
[mkdir] Created dir: /root/src/jug-2.0.0/build
[mkdir] Created dir: /root/src/jug-2.0.0/build/classes
[mkdir] Created dir: /root/src/jug-2.0.0/build/jug-native
[mkdir] Created dir: /root/src/jug-2.0.0/doc
[mkdir] Created dir: /root/src/jug-2.0.0/test
[mkdir] Created dir: /root/src/jug-2.0.0/test/build
[mkdir] Created dir: 

Bug#604925: /usr/lib/libgssapi_krb5.so.2: cannot login to ssh after upgrade from lenny to squeeze

[Tom Yu]

Sam Hartman hartm...@debian.org writes:

 Hi.  At today's release meeting, MIT indicated that they are going to
 set up an OSX X test environment to reproduce this problem.  They will
 also look into whether we can ignore the PAC and remove it from the
 authdata if it fails to verify rather than failing the authentication.
 There was agreement that if we do that we need to insert a trace point
 in the PAC code so we can know that the PAC is not verified.

I have reproduced the bug against Mac OS 10.6 Server.  The following
patch appears to work (against the trunk; I believe the 1.8 release
didn't have tracing support).  Sam, does it look reasonable to you?

diff --git a/src/include/k5-trace.h b/src/include/k5-trace.h
index 3efe0e4..43d63cc 100644
--- a/src/include/k5-trace.h
+++ b/src/include/k5-trace.h
@@ -177,6 +177,10 @@
 #define TRACE_INIT_CREDS_SERVICE(c, service) \
 TRACE(c, (c, Setting initial creds service to {string}, service))
 
+#define TRACE_MSPAC_DISCARD_NOSVCSIG(c) \
+TRACE(c, (c, Discarding MS PAC due to missing service signature.  \
+  Apple Open Directory bug?))
+
 #define TRACE_KT_GET_ENTRY(c, keytab, princ, vno, enctype, err) \
 TRACE(c, (c, Retrieving {princ} from {keytab} (vno {int},  \
   enctype {etype}) with result: {kerr}, princ, keytab, \
diff --git a/src/lib/krb5/krb/pac.c b/src/lib/krb5/krb/pac.c
index 983b4e8..64e0d9f 100644
--- a/src/lib/krb5/krb/pac.c
+++ b/src/lib/krb5/krb/pac.c
@@ -637,8 +637,13 @@ krb5_pac_verify(krb5_context context,
 return EINVAL;
 
 ret = k5_pac_verify_server_checksum(context, pac, server);
-if (ret != 0)
+if (ret == ENOENT) {
+TRACE_MSPAC_DISCARD_NOSVCSIG(context);
+pac-verified = FALSE;
+return 0;
+} else if (ret != 0) {
 return ret;
+}
 
 if (privsvr != NULL) {
 ret = k5_pac_verify_kdc_checksum(context, pac, privsvr);
@@ -977,6 +982,11 @@ mspac_get_attribute(krb5_context kcontext,
 if (*more != -1 || pacctx-pac == NULL)
 return ENOENT;
 
+/* If it didn't verify, pretend it didn't exist. */
+if (!pacctx-pac-verified) {
+return ENOENT;
+}
+
 code = mspac_attr2type(attribute, type);
 if (code != 0)
 return code;

Bug#604925: /usr/lib/libgssapi_krb5.so.2: cannot login to ssh after upgrade from lenny to squeeze

[Tom Yu]

Sam Hartman hartm...@debian.org writes:

 This patch looks reasonable.  I have not confirmed that successfully
 makes the PAC disappear, but if you've examined the logic there I'm
 happy to assume it does.

On the other hand, we do appear to expose the krb5_pac_verify()
interface that is called by the static authdata handler mspac_verify()
so I should bump the check up a level to mspac_verify().



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

Bug#604925: /usr/lib/libgssapi_krb5.so.2: cannot login to ssh after upgrade from lenny to squeeze

[Tom Yu]

forwarded 604925 
http://krbdev.mit.edu/rt/Ticket/Display.html?id=6839user=guestpass=guest
tags 604925 + confirmed upstream fixed-upstream
thanks

I committed a slightly different fix that avoids breaking the
krb5_pac_verify() API.

http://src.mit.edu/fisheye/changelog/krb5/?cs=24564



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

Bug#601805: viewvc: Grave python errors which can be fixed with a one liner, already upstream

[Tom Albers]

Package: viewvc
Version: 1.1.5-1
Severity: grave
Tags: upstream patch
Justification: renders package unusable

Upstream version 1.1.6 includes a fix for some nasty python errors. We are 
hitting the bug on lots of places, which renders the package unusuable. More 
details can be found in the upstream bugtracker: 
http://viewvc.tigris.org/issues/show_bug.cgi?id=454

The fix is a oneliner included in the bug. It fixes the links like 'Copied 
from: ' link seen on, for example:
http://websvn.kde.org/trunk/kdesupport/strigi/libstreamanalyzer/lib/analysisresult.cpp?view=log

Tom Albers
KDE Sysadmin


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

Kernel: Linux 2.6.35.4-rscloud (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 viewvc depends on:
ii  python  2.6.6-3  interactive high-level object-orie
ii  python-subversion   1.6.12dfsg-2 Python bindings for Subversion
ii  python-support  1.0.10   automated rebuilding support for P
ii  rcs 5.7-25   The GNU Revision Control System
ii  subversion  1.6.12dfsg-2 Advanced version control system

Versions of packages viewvc recommends:
ii  apache2 2.2.16-3 Apache HTTP Server metapackage
ii  apache2-mpm-itk [httpd-cgi] 2.2.16-3 multiuser MPM for Apache 2.2
ii  python-pygments 1.3.1+dfsg-1 syntax highlighting package writte

Versions of packages viewvc suggests:
pn  cvsgraph  none (no description available)
pn  libapache2-mod-python none (no description available)
ii  mime-support  3.48-1 MIME files 'mime.types'  'mailcap
pn  python-tk none (no description available)
pn  viewvc-query  none (no description available)

-- Configuration Files:
/etc/viewvc/mimetypes.conf changed [not included]
/etc/viewvc/templates/diff.ezt changed [not included]
/etc/viewvc/templates/dir_new.ezt changed [not included]
/etc/viewvc/templates/file.ezt changed [not included]
/etc/viewvc/templates/include/footer.ezt changed [not included]
/etc/viewvc/templates/include/header.ezt changed [not included]
/etc/viewvc/templates/query_form.ezt changed [not included]
/etc/viewvc/templates/query_results.ezt changed [not included]
/etc/viewvc/viewvc.conf changed [not included]

-- no debconf information



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

Bug#577490: forwarded, fixed upstream

[Tom Yu]

retitle 577490 CVE-2010-1320 double free in KDC caused by ticket renewal
forwarded 577490 http://krbdev.mit.edu/rt/Ticket/Display.html?id=6702
tags 577490 + fixed-upstream
thanks

Upstream bug #6702 CVE-2010-1230 KDC double free caused by ticket
renewal (MITKRB5-SA-2010-004)



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

Bug#577490: CVE-2010-1320

[Tom Yu]

tags 577490 security
thanks


upstream advisory is pending

CVE-2010-1320

CVSSv2 vector  AV:N/AC:L/Au:S/C:C/I:C/A:C/E:POC/RL:OF/RC:C



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

Bug#565706: grub2 enters rescue mode with fd0 cannot get C/H/S values

[Tom Wright]

I've found a workaround for this one by changing a BIOS setting - it doesn't 
fix the underlying issue though.

The BIOS setting was Legacy USB which was set to Auto and I have now set to 
Disabled.  This means that the BIOS doesn't start the USB devices, so GRUB 
can't see them and doesn't get confused.  The USB devices are still visible to 
the kernel though, so everything works fine.

If you want me to try out any other patches, I'm happy to revert the changes 
to the BIOS and try one out, but I just thought I'd post this workaround for 
anyone else who's stuck on it.

Tom


On Wednesday 24 February 2010 09:58:05 Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
 Tom Wright wrote:
  Package: grub-pc
  Version: 1.98~20100128-1.2
  Severity: normal
 
  I am seeing the same problem: grub reports this on startup and then gets
  no further:
 
  error: fd0 cannot get C/H/S values.
  entering rescue mode
 
 Can you try the attached patch?
 
  My system has three RAID1 md partitions across sda and sdb, containing
  swap, / and /boot and it has another disk (sdc).  With these plugged in,
  it all works fine, but once I plug a USB drive in as well, the system
  won't start.  I can get it to start by removing the USB drive and
  resetting it (ctrl-alt-del or power-cycle).  This is not ideal though, as
  it's a hidden-away server which always has a USB disk plugged into it for
  backup purposes, so I cannot reboot it remotely because it won't start up
  again.
 
  -- Package-specific info:
 
  *** BEGIN /proc/mounts
  /dev/disk/by-uuid/b8ea7ba8-1e96-4e1c-8993-6a3118767dd5 / ext4
  rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0 /dev/md2 /boot
  ext3 rw,relatime,errors=continue,data=ordered 0 0 /dev/sdc1
  /mythrecordings ext4 rw,relatime,barrier=1,data=ordered 0 0
  *** END /proc/mounts
 
  *** BEGIN /boot/grub/device.map
  (hd0)   /dev/sda
  (hd1)   /dev/sdb
  (hd2)   /dev/sdc
  *** END /boot/grub/device.map
 
  *** BEGIN /boot/grub/grub.cfg
  #
  # DO NOT EDIT THIS FILE
  #
  # It is automatically generated by /usr/sbin/grub-mkconfig using
  templates # from /etc/grub.d and settings from /etc/default/grub
  #
 
  ### BEGIN /etc/grub.d/00_header ###
  if [ -s $prefix/grubenv ]; then
load_env
  fi
  set default=0
  if [ ${prev_saved_entry} ]; then
set saved_entry=${prev_saved_entry}
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
  fi
 
  function savedefault {
if [ -z ${boot_once} ]; then
  saved_entry=${chosen}
  save_env saved_entry
fi
  }
  insmod raid
  insmod mdraid
  insmod ext2
  set root=(md1)
  search --no-floppy --fs-uuid --set b8ea7ba8-1e96-4e1c-8993-6a3118767dd5
  if loadfont /usr/share/grub/unicode.pf2 ; then
set gfxmode=640x480
insmod gfxterm
insmod vbe
if terminal_output gfxterm ; then true ; else
  # For backward compatibility with versions of terminal.mod that don't
  # understand terminal_output
  terminal gfxterm
fi
  fi
  insmod raid
  insmod mdraid
  insmod ext2
  set root=(md2)
  search --no-floppy --fs-uuid --set 7585406e-ce84-4bd5-afb6-e198efa46a94
  set locale_dir=($root)/grub/locale
  set lang=en
  insmod gettext
  set timeout=5
  ### END /etc/grub.d/00_header ###
 
  ### BEGIN /etc/grub.d/05_debian_theme ###
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
  ### END /etc/grub.d/05_debian_theme ###
 
  ### BEGIN /etc/grub.d/10_linux ###
  menuentry Debian GNU/Linux, with Linux 2.6.32-trunk-amd64 {
  insmod raid
  insmod mdraid
  insmod ext2
  set root=(md2)
  search --no-floppy --fs-uuid --set 7585406e-ce84-4bd5-afb6-e198efa46a94
  echoLoading Linux 2.6.32-trunk-amd64 ...
  linux   /vmlinuz-2.6.32-trunk-amd64
  root=UUID=b8ea7ba8-1e96-4e1c-8993-6a3118767dd5 ro  quiet echo   Loading
  initial ramdisk ...
  initrd  /initrd.img-2.6.32-trunk-amd64
  }
  menuentry Debian GNU/Linux, with Linux 2.6.32-trunk-amd64 (recovery
  mode) { insmod raid
  insmod mdraid
  insmod ext2
  set root=(md2)
  search --no-floppy --fs-uuid --set 7585406e-ce84-4bd5-afb6-e198efa46a94
  echoLoading Linux 2.6.32-trunk-amd64 ...
  linux   /vmlinuz-2.6.32-trunk-amd64
  root=UUID=b8ea7ba8-1e96-4e1c-8993-6a3118767dd5 ro single echo   Loading
  initial ramdisk ...
  initrd  /initrd.img-2.6.32-trunk-amd64
  }
  ### END /etc/grub.d/10_linux ###
 
  ### BEGIN /etc/grub.d/30_os-prober ###
  ### END /etc/grub.d/30_os-prober ###
 
  ### BEGIN /etc/grub.d/40_custom ###
  # This file provides an easy way to add custom menu entries.  Simply type
  the # menu entries you want to add after this comment.  Be careful not to
  change # the 'exec tail' line above.
  ### END /etc/grub.d/40_custom ###
  *** END /boot/grub/grub.cfg
 
  -- System Information:
  Debian Release: squeeze/sid
APT