Bug#1040686: fixed in libpdfbox-java 1:1.8.16-3

[Ted]

There are a few reasons that my build configuration might trigger build
dependencies that don't normally.
I'll try this again after the next time I update the local repository and
see if the problem persists.

I increment a package version before I build a local version, and this may
be the cause.

I will start sending build logs in the future because I've been really
foolish not to.


-- 

-Theodoric

Bug#1040686: libpdfbox-java: Missing build dependency on lcdf-typetool OR extraneous other relation in debian/

[Ted]

There are a few reasons that my build configuration might trigger build
dependencies that don't normally.
I'll try this again after the next time I update the local repository and
see if the problem persists.

I increment a package version before I build a local version, and this may
be the cause.

I will start sending build logs in the future because I've been really
foolish not to.

On Sun, Jul 9, 2023 at 6:03 AM Theodoric Stier  wrote:

> Source: libpdfbox-java
> Version: 1:1.8.16-2
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source
> X-Debbugs-Cc: kerd...@gmail.com
>
> Dear Maintainer,
>
> This package fails to build when lcdf-typetool is not installed, but
> only during packaging. It appears not to be used during the build.
> Maybe it's supposed to be a build dependency. If it isn't supposed to
> be a build dependency, then the build should succeed without its presence.
>
> Salutations,
> Ted
>
> -- System Information:
> Debian Release: 12.0
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.1.0-9-amd64 (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>


-- 

-Theodoric

Bug#1039724: gpgme: building underbookworm fails with no matches in python3-gpg.install

[Ted]

Thank you for pointing this out. I have removed python3-setuptools and
successfully built gpgme1.0.
For fun I will see if I can figure out how to add this to Conflicts.

On Wed, Jul 5, 2023 at 12:30 PM Andreas Metzler  wrote:

> On 2023-07-04 Ted  wrote:
> > The only software which has ever run here is from a bookworm or vscodim
> > repo so i will just wait for bookworm to stabilize and hope i can abandon
> > the workarounds in the future.
>
> Hello,
>
> You were right all the time. python3-setuptools is the culprit,
> installing it breaks the build.
>
> cu Andreas
> --
> `What a good friend you are to him, Dr. Maturin. His other friends are
> so grateful to you.'
> `I sew his ears on from time to time, sure'
>


-- 

-Theodoric

Bug#1039724: gpgme: building underbookworm fails with no matches in python3-gpg.install

[Ted]

The only software which has ever run here is from a bookworm or vscodim
repo so i will just wait for bookworm to stabilize and hope i can abandon
the workarounds in the future.

On Tue, Jul 4, 2023, 12:58 PM Andreas Metzler  wrote:

> On 2023-07-03 Ted  wrote:
> > Just to keep updated, I checked if all build deps have updates in
> > bookworm-updates and bookworm-security, but didn't find anything. I also
> > checked to make sure that the package versions i'm using for all build
> > dependencies are equal to the latest in bookworm.
>
> You will need to search for local python stuff (e.g. /usr/local or
> in the home directory, not packaged ones.
>
> Please keep this discussion on the bug tracker, do not only mail me
> directly.
>
> cu Andreas
>

Bug#1031824: (no subject)

[Ted To]

May be related to 
.  Works on a Void 
Linux installation which has libsoup 3.2.0_2 instead of the Bookworm 
version 3.2.2-1.

Bug#1031824: geary: Geary integration with Gnome Online Accounts (NextCloud) is not working.

[Ted To]

Package: geary
Version: 43.0-1+b1
Severity: important
Tags: upstream




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

Kernel: Linux 6.1.0-3-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 geary depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gnome-keyring42.1-1+b1
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libenchant-2-2   2.3.3-2
ii  libfolks26   0.15.5-2+b1
ii  libgck-1-0   3.41.1-1+b1
ii  libgcr-base-3-1  3.41.1-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgee-0.8-2 0.20.6-1
ii  libglib2.0-0 2.74.5-1
ii  libgmime-3.0-0   3.2.13+dfsg-2
ii  libgoa-1.0-0b3.46.0-1
ii  libgsound0   1.0.3-2
ii  libgspell-1-21.12.0-1+b1
ii  libgtk-3-0   3.24.36-3
ii  libhandy-1-0 1.8.1-1
ii  libicu72 72.1-3
ii  libjavascriptcoregtk-4.1-0   2.38.5-1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmessaging-menu0   22.9.0-1+b1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libpeas-1.0-01.34.0-1+b1
ii  libsecret-1-00.20.5-3
ii  libsoup-3.0-03.2.2-1
ii  libsqlite3-0 3.40.1-1
ii  libstemmer0d 2.2.0-2
ii  libunwind8   1.6.2-3
ii  libwebkit2gtk-4.1-0  2.38.5-1
ii  libxml2  2.9.14+dfsg-1.1+b3
ii  libytnef02.0-1+b1

geary recommends no packages.

geary suggests no packages.

-- no debconf information

Bug#1021729: Acknowledgement (gnome-settings-daemon: External monitor detected but not identified.)

[Ted To]

Seems to be fixed with an update this weekend.  Please close.

On Thu, 2022-10-13 at 15:09 +, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 1021729:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021729.
> 
> 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 GNOME Maintainers
> 
> 
> If you wish to submit further information on this problem, please
> send it to 1021...@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#1021729: gnome-settings-daemon: External monitor detected but not identified.

[Ted To]

Package: gnome-settings-daemon
Version: 43.0-2
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
 a recent upgrade from the testing repository
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 NA
   * What was the outcome of this action?
 NA
   * What outcome did you expect instead?
 NA

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


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

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

Versions of packages gnome-settings-daemon depends on:
ii  gnome-settings-daemon-common  43.0-2
ii  gsettings-desktop-schemas 43.0-1
ii  libasound21.2.7.2-1
ii  libc6 2.35-3
ii  libcairo2 1.16.0-6
ii  libcanberra-gtk3-00.30-10
ii  libcanberra0  0.30-10
ii  libcolord21.4.6-1
ii  libcups2  2.4.2-1+b1
ii  libfontconfig12.13.1-4.5
ii  libgcr-base-3-1   3.41.1-1
ii  libgdk-pixbuf-2.0-0   2.42.9+dfsg-1
ii  libgeoclue-2-02.6.0-2
ii  libgeocode-glib-2-0   3.26.3-3
ii  libglib2.0-0  2.74.0-2
ii  libgnome-desktop-3-20 43-2
ii  libgtk-3-03.24.34-3
ii  libgudev-1.0-0237-2
ii  libgweather-4-0   4.2.0-1
ii  libmm-glib0   1.18.12-1
ii  libnm01.40.0-1
ii  libnotify40.8.1-1
ii  libnspr4  2:4.35-1
ii  libnss3   2:3.83-1
ii  libpam-systemd [logind]   251.5-2
ii  libpango-1.0-01.50.10+ds-1
ii  libpangocairo-1.0-0   1.50.10+ds-1
ii  libpolkit-gobject-1-0 0.105-33
ii  libpulse-mainloop-glib0   16.1+dfsg1-2
ii  libpulse0 16.1+dfsg1-2
ii  libspa-0.2-bluetooth  0.3.59-1
ii  libupower-glib3   0.99.20-1
ii  libwacom9 2.4.0-3
ii  libwayland-client01.21.0-1
ii  libx11-6  2:1.8.1-2
ii  libxext6  2:1.3.4-1+b1
ii  libxfixes31:6.0.0-2
ii  libxi62:1.8-1+b1
ii  pipewire-pulse0.3.59-1
ii  pulseaudio16.1+dfsg1-2
ii  pulseaudio-module-bluetooth   16.1+dfsg1-2
ii  wireplumber   0.4.12-1

Versions of packages gnome-settings-daemon recommends:
ii  iio-sensor-proxy  3.0-2
ii  libspa-0.2-bluetooth  0.3.59-1
ii  pipewire-pulse0.3.59-1
ii  wireplumber   0.4.12-1
ii  x11-xserver-utils 7.7+9+b1

Versions of packages gnome-settings-daemon suggests:
pn  usbguard  

-- no debconf information

Bug#1007103: Rosegarden: malloc_consolidate(): unaligned fastbin chunk detected

[Ted Felix]

On 3/27/22 1:49 AM, Ron Murray wrote:
I have the same problem here. Removing lmms and fluidsynth-dssi made no 
difference.


I did a debug build and ran it with gdb. The resullt is attached.


  Thanks.  In your case it looks like something called "whysynth" is 
the issue:


/usr/lib/dssi/whysynth.so

  This is shown in the _dl_map_object() entry in the backtrace:

#10 0x77fd59cd in _dl_map_object (loader=0x0,
loader@entry=0x77ffe220, name=name@entry=0x7fffdc1a3e30 
"/usr/lib/dssi/whysynth.so", type=type@entry=2, 
trace_mode=trace_mode@entry=0, mode=mode@entry=-1879048191, 
nsid=) at dl-load.c:2336


  Try uninstalling that.  The others might still be an issue, so don't 
be surprised if it continues to crash and more plugins need to be 
uninstalled.


  There appear to be a number of issues with the various DSSI synth 
plugins.  Someone needs to open bug reports against each of these 
crashing plugins and mention all the others.  That should get us closer 
to finding the real problem.


  This bug report against rosegarden can be closed.

Bug#1007103: Further information

[Ted Felix]

  OP informs me that he tracked the problem down to the ZynAddSubFX 
DSSI plugin.  He switched to the ZynAddSubFX standalone app and all is 
well for him.


  This bug can be closed for rosegarden.

Bug#1007103: Further information

[Ted Felix]

  I just pushed improved plugin logging as [3a07309c].  If you can, 
please test latest git:


  https://sourceforge.net/p/rosegarden/git/ci/master/tree/

  A debug build should now let you know when it is trying to load a 
plugin.  And that should be the last thing you see from rosegarden when 
a plugin crashes on load.

Bug#1007103: Further information

[Ted Felix]

On 3/19/22 7:08 AM, Rainer Hans Liffers wrote:
> I compiled the latest version of rosegarden with debugging enabled 
and subsequently ran gdb as shown in attached file.  Is this information 
sufficient?


  Yes.  Thanks.

  The first line relevant to rg is this:

#19 0x55e3188e in Rosegarden::LADSPAPluginFactory::loadLibrary 
(this=0x7fffb0004fd0, soName=...)
  at 
/home/rainer/Downloads/rosegarden/src/sound/LADSPAPluginFactory.cpp:504


  And this is not unusual.  Unfortunately, if there are problems with 
plugins, rg does little to protect itself against them crashing.  We 
have a bug on our bug tracker related to this:


  https://sourceforge.net/p/rosegarden/bugs/1474/

  Not sure anyone will get around to fixing it, though.  And 
regardless, we can't really fix this issue.  The problem is actually in 
the fluidsynth-dssi.so plugin that we are trying to load:


#8  _dl_new_object (realname=realname@entry=0x7fffb014e0a0 
"/usr/lib/dssi/fluidsynth-dssi.so", libname=libname@entry=0x7fffb0153ab8 
"/usr/lib/dssi/fluidsynth-dssi.so",
type=type@entry=2, loader=loader@entry=0x0, 
mode=mode@entry=-1879048190, nsid=nsid@entry=0) at dl-object.c:89


  So fluidsynth's dssi plugin is the next place to look.  Of course, 
once again, the issue might actually be caused by something fluidsynth 
brings in.



BTW, this error only occurs on my laptop running Debian bookworm.
On my (dual boot) desktop, rosegarden works fine both under KDE neon
and EndeavourOS, using pipewire 0.3.48.


  Not surprising.  Could be a config difference, or something subtle 
about library versioning.


  I'm going to add some logging to help diagnose this in the future. 
This isn't the first time this has been an issue.  It would be nice to 
know exactly what is going on immediately.


  Thanks for the bug report.rainer@Freya:~$ gdb /usr/local/bin/rosegarden
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/rosegarden...
(gdb) run
Starting program: /usr/local/bin/rosegarden 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7145e640 (LWP 4384)]
[New Thread 0x7fffeac7a640 (LWP 4385)]
[main] System Locale: "en_AU"
[main] Qt translations path:  "/usr/share/qt5/translations"
[main] Qt translations loaded successfully.
[main] RG Translation: trying to load :locale/ "en_AU"
[main] RG Translations loaded successfully.
[main] Loaded application icon " "rg-rwb-rose3-16x16" "
[main] Loaded application icon " "rg-rwb-rose3-32x32" "
[main] Loaded application icon " "rg-rwb-rose3-48x48" "
[main] Loaded application icon " "rg-rwb-rose3-64x64" "
[main] Loaded application icon " "rg-rwb-rose3-128x128" "
[main] Unbundling examples...
[main] Unbundling templates...
[main] Unbundling libraries (device files)...
[New Thread 0x7fffdae94640 (LWP 4386)]
[New Thread 0x7fffda693640 (LWP 4387)]
[New Thread 0x7fffd9e92640 (LWP 4388)]
[New Thread 0x7fffd9691640 (LWP 4389)]
[New Thread 0x7fffd8e90640 (LWP 4390)]
[New Thread 0x7fffc3fff640 (LWP 4391)]
[New Thread 0x7fffbbfff640 (LWP 4392)]
[main] Creating RosegardenMainWindow instance...
[New Thread 0x7fffc2dee640 (LWP 4393)]
[SequencerThread] run()
[New Thread 0x7fffc25ed640 (LWP 4394)]
[PluginFactory] PluginFactory::instance( "dssi" ): creating new 
DSSIPluginFactory
[JackDriver] initialise() begin...
[New Thread 0x7fffc1dbd640 (LWP 4395)]
[New Thread 0x7fffc15bc640 (LWP 4396)]
[JackDriver] initialise() - JACK sample rate =  48000 Hz, buffer size =  1024
[JackDriver] initialise() - creating disk thread...
[New Thread 0x7fffd84e7640 (LWP 4397)]
[JackDriver] initialise() - found  9  JACK physical outputs
[JackDriver] initialise() - connecting from  " rosegarden:master out L " to " 
Tiger Lake-LP Smart Sound Technology Audio Controller Speaker + 
Headphones:playback_FL "
[JackDriver] initialise() - connecting from  " rosegarden:master out R " to " 
Tiger Lake-LP Smart Sound Technology Audio Controller Speaker + 
Headphones:playback_FR "
[JackDriver] initialise() - found  5  JACK physical inputs
[JackDriver] initialise() - connecting from  " Tiger Lake-LP Smart Sound 
Technology Audio Controller Digital Microphone:capture_FL " to " 
rosegarden:record in 1 L "
[JackDriver] initialise() - connecting from  " Tiger 

Bug#1007103: Further information

[Ted Felix]

malloc_consolidate(): unaligned fastbin chunk detected Aborted


  We've not seen this upstream.  Best bet would be to do a debug build 
from source and run under gdb.  Then do a backtrace when it crashes. 
That should help us determine whether it is Rosegarden or one of the 
many libraries it pulls in.  Let me know if you need help with this and 
I'll point you to the relevant pages on our wiki.

Bug#994062: Acknowledgement (gnome-shell-extension-tilix-dropdown: No JS module 'tweener' found in search path)

[Ted To]

After updating extension.js along the lines of
https://askubuntu.com/questions/1286212/no-js-module-tweener-found-in-search-path-gnome-shell-extension-error-on-ubun,
there is still an error with a "No property x_fill on StBin" error.

Bug#994062: gnome-shell-extension-tilix-dropdown: No JS module 'tweener' found in search path

[Ted To]

Package: gnome-shell-extension-tilix-dropdown
Version: 7-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

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

   * What led up to the situation?
installed gnome-shell-extension-tilix-dropdown
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
attempted to enable extension
   * What was the outcome of this action?
extension not enabled with the error given in the subject line.
   * What outcome did you expect instead?
extension enabled

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


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

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

Versions of packages gnome-shell-extension-tilix-dropdown depends on:
ii  gnome-shell  3.38.4-1
ii  tilix1.9.4-2

gnome-shell-extension-tilix-dropdown recommends no packages.

gnome-shell-extension-tilix-dropdown suggests no packages.

-- no debconf information

Bug#975143: rosegarden: FTBFS: Panner.cpp:138:18: error: aggregate ‘QPainterPath path’ has incomplete type and cannot be defined

[Ted Felix]

On 11/19/20 4:37 AM, Lucas Nussbaum wrote:

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

/<>/src/gui/widgets/Panner.cpp:138:18: error: aggregate 
‘QPainterPath path’ has incomplete type and cannot be defined


  This was fixed in r15845 upstream:

https://sourceforge.net/p/rosegarden/code/15845/

  Patch attached.

Ted.
>From bdb6c75b733d4868e350af4baeeb15e309c7b62a Mon Sep 17 00:00:00 2001
From: Ted Felix 
Date: Tue, 16 Jun 2020 00:48:04 -0400
Subject: [PATCH] Fix QPainterPath compilation error

---
 src/gui/general/ThornStyle.cpp | 1 +
 src/gui/widgets/Panner.cpp | 1 +
 2 files changed, 2 insertions(+)

diff --git a/src/gui/general/ThornStyle.cpp b/src/gui/general/ThornStyle.cpp
index 43746078..de426f1a 100644
--- a/src/gui/general/ThornStyle.cpp
+++ b/src/gui/general/ThornStyle.cpp
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/src/gui/widgets/Panner.cpp b/src/gui/widgets/Panner.cpp
index ceba4eae..ead23faf 100644
--- a/src/gui/widgets/Panner.cpp
+++ b/src/gui/widgets/Panner.cpp
@@ -24,6 +24,7 @@
 #include "misc/Debug.h"
 #include "base/Profiler.h"
 
+#include 
 #include 
 #include 
 
-- 
2.25.1

Bug#968267: Calamares installation fails due to no display managers selected for the displaymanager module

[Ted Lavarias]

Package: calamares-settings-debian
Version: 11.0.2-1

When trying to install Debian 10.5 using the Live Image, I received an
"Installation Failed" error. A dialog box popped up saying "No display
managers selected for the displaymanager module. The list is empty after
checking for installed display managers." I believe this is related to bug
#934503 ("enabling autologin doesn't work") due to the displaymanager
module not being enabled in settings.conf. But now that it seems the
displaymanager module is enabled, when I try to install 10.5 with autologin
disabled, it causes the installation to fail.

I have a screenshot of the error message from the failed installation as
well, but it simply contains the text above in the quotes. I tried to
install it twice, thinking that there might have been some error on my
part, but that does not seem to be the case. I have since used the Live
Image installation for 10.4 and it installed just fine. I checked the
ChangeLog for 10.5 and saw that there seemed to be a fix regarding the
displaymodule that fixed bug #934503. That seems to be the issue causing
the 10.5 Live Image installation to fail now.

--
Very respectfully,
*Ted Lavarias*

Bug#904717: rosegarden "Tie Notes at Barlines" has no effect on some imported MIDI

[Ted Felix]

Confirmed.  This is likely working as designed.

In the Bass_sample.mid case, the note beginnings have been quantized, 
but the note durations have not been quantized.  Rosegarden seems to 
prefer exact note durations when doing ties.  If you double-click the 
note that you want to tie and set its duration to a dotted quarter, you 
can then tie across the barline.


It may be possible to improve this, but I'm not the one to ask.  I 
recommend closing this bug and starting a discussion on the upstream 
rosegarden-user mailing list:


https://sourceforge.net/projects/rosegarden/lists/rosegarden-user

Look forward to seeing you there.

Bug#951381: pdftex ignores tl-paper setting

[Ted To]

Hi Norbert,

Ah, yes, you are correct.  Doh!

Thank you!

Ted

On 2/15/20 5:26 PM, Norbert Preining wrote:

tags 951381 + unreproducible moreinfo
thanks

Hi Ted,

I just tried to reproduce this on my buster system, without success.

On Sat, 15 Feb 2020, Ted To wrote:

$ tl-paper

...

Did you rebuild the formats after changing the default paper size?

Please do
sudo tl-paper set all letter
sudo fmtutil-sys --all

After that it should work.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#951381: Acknowledgement (pdftex ignores tl-paper setting)

[Ted To]

FYI, latex + dvipdf produces pdfs with the correct paper size.

On 2/15/20 12:36 PM, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 951381: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951381.

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 TeX Maintainers 

If you wish to submit further information on this problem, please
send it to 951...@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#951381: pdftex ignores tl-paper setting

[Ted To]

Package: texlive-base, texlive-binaries

Version: 2018.20190227-2, 2018.20181218.49446-1

Paper size to letter:

$ tl-paper
Current dvipdfmx paper size (from 
/var/lib/texmf/dvipdfmx/dvipdfmx-paper.cfg): letter
Current dvips paper size (from 
/var/lib/texmf/dvips/config/config-paper.ps): letter
Current pdftex paper size (from 
/var/lib/texmf/tex/generic/config/pdftexconfig.tex): letter

Current xdvi paper size (from /var/lib/texmf/xdvi/XDvi-paper): letter

But produced pdf files still come out as a4:

$ pdflatex test
This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 
2019/dev/Debian) (preloaded format=pdflatex)

 restricted \write18 enabled.
entering extended mode
(./test.tex
LaTeX2e <2018-12-01>
(/usr/share/texlive/texmf-dist/tex/latex/base/letter.cls
Document Class: letter 2014/09/29 v1.2z Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size12.clo)) (./test.aux)
[1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] [2] [3] 
(./test.aux) )
(see the transcript file for additional 
information)
ist/fonts/type1/public/amsfonts/cm/cmbx12.pfb>
Output written on test.pdf (3 pages, 33961 bytes).
Transcript written on test.log.

$ pdfinfo test.pdf
Creator:    TeX
Producer:   pdfTeX-1.40.19
CreationDate:   Sat Feb 15 12:23:17 2020 EST
ModDate:    Sat Feb 15 12:23:17 2020 EST
Tagged: no
UserProperties: no
Suspects:   no
Form:   none
JavaScript: no
Pages:  3
Encrypted:  no
Page size:  595.276 x 841.89 pts (A4)
Page rot:   0
File size:  33961 bytes
Optimized:  no
PDF version:    1.5

This has apparently been fixed in unstable but not in stable or testing.

Bug#946193: workaround

[Ted Anderson]

I encountered the same problem upgrading from (jessie to) stretch to 
buster today.  I was successful using the simpler workaround of deleting 
compatibility.ini from my profile.  Once Firefox started, it recreated a 
new compatibility.ini file automatically.  Here is a comparison of the 
old and new files:


ota@alfriston:~$ diff 
~/.mozilla/firefox/bhojq6pr.default/compatibility.ini 
~/firefox-pre-buster-profile/compatibility.ini

2c2
< LastVersion=68.3.0_20191203235607/20191203235607
---
> LastVersion=68.3.0_20191204133900/20191204133900
ota@alfriston:~$ firefox --version
Mozilla Firefox 68.3.0esr
ota@alfriston:~$ cat /etc/debian_version
10.2
ota@alfriston:~$ dpkg -l | grep firefox
ii  firefox-esr   68.3.0esr-1~deb10u1 
 amd64Mozilla Firefox web browser - Extended Support 
Release (ESR)

ota@alfriston:~$ cat /etc/debian_version
10.2

So this minor versioning glitch appears to explain the problem as 
described above.  I also found the Mozilla bug(s) from July that 
addresses a similar problem, but which apparently doesn't handle this case.


https://bugzilla.mozilla.org/show_bug.cgi?id=1554029
https://bugzilla.mozilla.org/show_bug.cgi?id=1568252

HtH,
Ted

Bug#947860: release-notes: Sec 4.3 preparing sources.list omits explicit statement of key change

[Ted Anderson]

Package: release-notes
Severity: normal

Dear Maintainer,

When upgrading from Jessie to Stretch, I was confused about when I was 
supposed to actually edit the sources.list file.  I found section 4.3 
"Preparing APT source-list files" unclear on when to perform this 
critical step.  I investigated the apt-get dist-upgrade command, but it 
does not edit sources.list for me.  I also found earlier mention that I 
should be careful that all deb lines should mention "jessie" and later 
(in section 4.4 "Upgrading packages") the comment "double-check that the 
APT source entries [...] refer either to ''stretch'' or to ''stable''". 
Apparently, between these two I was supposed to edit the file to replace 
jessie with stretch.


The corresponding text for Buster is about the same in this respect.

I think adding a summary sentence to this effect at the beginning of 
section 4.3 would be sufficient.  While I've used Debian, and Ubuntu 
before that, for years, my exposure to apt/aptitude has been sporadic 
and doubtless my mental model of its operation is askew.  Making the 
obvious steps more explicit would help less experienced users with this 
upgrade process.


Perhaps changing the first sentence of 4.3 to:

Before starting the upgrade you must reconfigure APT's source-list
files (/etc/apt/sources.list and files under /etc/apt/sources.list.d/)
to add sources for stretch  and remove sources for jessie 
.


Thank you for your consideration.

Ted Anderson

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

Kernel: Linux 3.16.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
Init: systemd (via /run/systemd/system)

Bug#933230: acpid: Race during startup can result in event devices not being opened

[Ted Felix]

On 7/27/19 4:21 PM, ano...@users.sourceforge.net wrote:

The attached patch...


Patch has been applied and pushed.  Test upstream at:

  https://sourceforge.net/p/acpid2/code/ci/master/tree/

Planning a release for 8/15 or 9/15.  Thanks again.

Bug#932978: same here

[Ted Serreyn]

Started testing buster and see the same result here.

Sysvinit, restart fails, package for snmpd never finishes configuration.



--
Ted Serreyn
Serreyn Network Services, LLC
t...@serreyn.com<mailto:t...@serreyn.com>
262-432-0260

Bug#933230: acpid: Race during startup can result in event devices not being opened

[Ted Felix]

On 7/27/19 4:21 PM, ano...@users.sourceforge.net wrote:

On my system, this race happens frequently for /dev/input/event8 "Video
Bus" during boot, preventing acpid from handling my system's brightness
keys.


  Thanks for the patch.  I've posted the patch and this report upstream:

https://sourceforge.net/p/acpid2/tickets/18/

  Probably will do a new release with this in a month or so.

Bug#918328: aptitude: symbol lookup error: aptitude: undefined symbol: _ZN6Xapian4MSetC1EOS0_

[Ted Percival]

Package: aptitude
Version: 0.8.11-3
Severity: important

Starting aptitude fails due to a missing Xapian symbol:

$ aptitude
aptitude: symbol lookup error: aptitude: undefined symbol:
_ZN6Xapian4MSetC1EOS0_

This is probably a bug in the syms in the applicable xapian library package
causing aptitude to get a library dependency that is too weak.

In particular, my system has a recent version of aptitude with an older version
of libxapian30, so there was probably a new symbol introduced in libxapian30
without adjusting the shared library dependency information.

$ apt-cache policy aptitude
aptitude:
  Installed: 0.8.11-3
  Candidate: 0.8.11-6
  Version table:
 0.8.11-6 500
500 http://mirrors.xmission.com/debian testing/main amd64 Packages
500 http://mirrors.xmission.com/debian unstable/main amd64 Packages
 *** 0.8.11-3 100
100 /var/lib/dpkg/status
 0.8.7-1 990
990 http://mirrors.xmission.com/debian stable/main amd64 Packages

$ apt-cache policy libxapian30
libxapian30:
  Installed: 1.4.3-2+deb9u2
  Candidate: 1.4.3-2+deb9u2
  Version table:
 1.4.9-1 500
500 http://mirrors.xmission.com/debian testing/main amd64 Packages
500 http://mirrors.xmission.com/debian unstable/main amd64 Packages
 *** 1.4.3-2+deb9u2 990
990 http://mirrors.xmission.com/debian stable/main amd64 Packages
100 /var/lib/dpkg/status


-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:

aptitude linkage:
linux-vdso.so.1 (0x7ffdbd4e5000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7f7386abf000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7f7386a85000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7f7386a57000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f738685)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7f738674a000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f7386629000)
libboost_iostreams.so.1.62.0 => 
/usr/local/lib/libboost_iostreams.so.1.62.0 (0x7f738660a000)
libboost_system.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.62.0 (0x7f7386605000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7f73861f1000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f73861d)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f738604d000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f7385eca000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f7385eae000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f7385ced000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7f7385cd3000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f7385ab5000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f7385aa2000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f738587c000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f7385668000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 
(0x7f73855cd000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f73855ac000)
/lib64/ld-linux-x86-64.so.2 (0x7f7387101000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f73855a7000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f738559d000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f7385396000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.11-3
ii  libapt-pkg5.0 1.8.0~alpha2
ii  libboost-iostreams1.62.0  1.62.0+dfsg-10
ii  libboost-system1.62.0 1.62.0+dfsg-10
ii  libc6 2.28-4
ii  libcwidget3v5 0.5.17-11
ii  libgcc1   1:8.2.0-13
ii  libncursesw6  6.1+20181013-1
ii  libsigc++-2.0-0v5 2.10.0-1
ii  libsqlite3-0  3.25.3-2
ii  libstdc++68.2.0-13
ii  libtinfo6 6.1+20181013-1
ii  libxapian30   1.4.3-2+deb9u2

Versions of packages aptitude recommends:
ii  libparse-debianchangelog-perl  1.2.0-12
ii  sensible-utils 0.0.9+deb9u1

Versions of packages aptitude suggests:
ii  apt-xapian-index0.49

Bug#914160: Bug#912376: fixed in qcontrol 0.5.6-2

[Ted To]

My experience was that a reboot allowed qcontrol to be installed but it 
certainly makes sense that reloading devices could fix the install as 
well.  I'm willing to help test this -- would I install the stretch 
qcontrol (not backported), reboot and then try to install the backported 
qcontrol?


On 1/2/19 10:21 AM, Ian Campbell wrote:

On Wed, 2019-01-02 at 15:14 +, Ian Campbell wrote:

But after booting the buster kernel qcontrol could setup
successfully:


I wonder if it is the reboot itself, and not necessarily the switch to
the buster kernel which is the bandaid here, i.e. if rebooting back
into the stretch kernel would work too.


In fact I also wonder if:
 udevadm control --reload-rules && dpkg --configure -a

would do the trick, indicating that the reload is what is missing.

Bug#914160: Bug#912376: fixed in qcontrol 0.5.6-2

[Ted To]

On 12/21/18 7:12 AM, Ian Campbell wrote:

On Fri, 2018-12-21 at 06:25 -0500, Ted To wrote:

Still broken for me.  I used Bernhard's workaround and qcontrol
starts.


Thank you for letting me know. Unfortunately this works for me locally
so I need more information from an affected system with no workarounds
applied to diagnose.

Please can you revert whatever edits you made to workaround the issue
(e.g. put the udev and systemd files back to their default/packaged
state and remove any override files you might have added to /etc/,
likewise revert the qcontrol.conf settings to the default).


Thanks for the response Ian.  It seems that what was missing was a 
reboot although part of the problem was that qcontrol failed to 
completely install because of the error.  What I did to get qcontrol to 
completely install was Bernhard's workaround.  After reverting it and 
rebooting everything is now working fine.


Thank you,
Ted

Bug#914160: Bug#912376: fixed in qcontrol 0.5.6-2

[Ted To]

Still broken for me.  I used Bernhard's workaround and qcontrol starts.

Version information:

$ apt show qcontrol
Package: qcontrol
Version: 0.5.6-2~bpo9+1
Priority: optional
Section: utils
Maintainer: Ian Campbell 
Installed-Size: 103 kB
Depends: libc6 (>= 2.15), liblua5.1-0, init-system-helpers (>= 1.18~), udev
Homepage: https://www.hellion.org.uk/qcontrol/
Download-Size: 25.6 kB
APT-Manual-Installed: yes
APT-Sources: http://ftp.us.debian.org/debian stretch-backports/main 
armel Packages


On Sun, 09 Dec 2018 15:20:30 + Ian Campbell  wrote:

Source: qcontrol
Source-Version: 0.5.6-2

We believe that the bug you reported is fixed in the latest version of
qcontrol, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 912...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ian Campbell  (supplier of updated qcontrol package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 09 Dec 2018 14:42:37 +
Source: qcontrol
Binary: qcontrol qcontrol-udeb
Architecture: source
Version: 0.5.6-2
Distribution: unstable
Urgency: medium
Maintainer: Ian Campbell 
Changed-By: Ian Campbell 
Description:
 qcontrol   - hardware control for QNAP Turbo Station devices
 qcontrol-udeb - hardware control for QNAP Turbo Station devices (udeb)
Closes: 908525 912376
Changes:
 qcontrol (0.5.6-2) unstable; urgency=medium
 .
   [ Ondřej Nový ]
   * d/changelog: Remove trailing whitespaces
 .
   [ Ian Campbell ]
   * Switch Homepage to https.
   * Fix "qcontrol FTCBFS: upstream Makefile hard codes the build
 architecture pkg-config" by allowing the override of the pkg-config binary
 Thanks to Helmut Grohne for the initial patch (Closes: #908525).
   * Correctly install 60-qcontrol.rules (Closes: #912376).
   * Refresh all patches to apply without fuzz.
   * Catch more installation errors in debian/rules.
Checksums-Sha1:
 70a3b9b459708b73436443539d8be74db2d5c44b 1983 qcontrol_0.5.6-2.dsc
 4381fac43f1801f57f690126ba945bd0f693d1e2 19236 qcontrol_0.5.6-2.debian.tar.xz
 7026d800bc091a301a8ff16b3d8e5ab4716a8c60 5888 qcontrol_0.5.6-2_source.buildinfo
Checksums-Sha256:
 f9a9501b9cf603c155a4f939d8f6d3147cc07e6dddc0512de8047baa21a14cb2 1983 
qcontrol_0.5.6-2.dsc
 565dc48adc871653790632da7ccd3f8576c6d00a29bfaff631fd662fc4e851cc 19236 
qcontrol_0.5.6-2.debian.tar.xz

Bug#915603: (no subject)

[Ted Percival]

Bug 871306[2] says graphicsmagick needs to Build-Depend on g++ (>= 4:7) to get
the new & old ABIs, but I don't see a versioned Build-Depends on g++ since the
bug was closed in version 1.3.26-5.

> For new
> executables to build without undefined references, your library will
> need rebuilding with GCC 7.

So the solution might just be to add the versioned Build-Depends: g++ (>= 4:7)
and rebuild to get the old symbols back into the library, rather than bumping
the soname.

[1] https://wiki.debian.org/GCC7#GCC_7_name_mangling_bug_fix
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871306

Bug#915606: libgraphicsmagick++-q16-12: Requires soname/shlibs bump for C++11 ABI changes

[Ted Percival]

Package: libgraphicsmagick++-q16-12
Version: 1.3.31-1
Severity: important

Important due to RC Policy "Shared library packages must include correct shlibs
files".

There was an ABI change between libgraphicsmagick++-q16-12 versions
1.3.30+hg15796-1~deb9u2 and 1.3.31-1 but the shlibs file was not changed. As a
result, some dependent packages like python3-pgmagick don't get a strict-enough
dependency from dpkg-shlibdeps and can end up in a broken state when built with
the newer library but installed with the older.

Steps to reproduce:

1. Ensure you have the stable repo in your apt sources.
2. Install the older library:

apt install libgraphicsmagick++-q16-12=1.3.30+hg15796-1~deb9u2

3. Install python3-pgmagick from testing/unstable:

apt install python3-pgmagick=0.7.4-1+b2

4. Try to load the library (which has an unconstrained dependency on
   libgraphicsmagick++-q16-12):

echo 'import pgmagick' | python3

Observation: failure to load libGraphicsMagick++-Q16.so due to missing symbol:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/pgmagick/__init__.py", line
1, in 
from pgmagick import _pgmagick
ImportError:
/usr/lib/python3/dist-packages/pgmagick/_pgmagick.cpython-36m-x86_64-linux-gnu.so:
undefined symbol:
_ZNK6Magick5ColorcvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcv

This is because the python3-pgmagick library was built with the newer GM++
library, which declares the same soname/shlibs as the older library, but the
exported symbols differ because of the libstdc++ C++11 ABI change
.

You can compare the exported symbols from each version of
libgraphicsmagick++-q16-12:

readelf -s -W /usr/lib/libGraphicsMagick++-Q16.so.12 | awk '{
print $8 }' | sort -u

Diffing the symbol lists, you can see some changes related to the C++11 ABI
change:


-_ZNK6Magick5ColorcvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEB5cxx11Ev
+_ZNK6Magick5ColorcvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcv

There are also some other changes not necessarily related to the libstdc++ ABI
change.

So I think the soname should have been incremented in version 1.3.31-1 to
prevent packages getting dependencies that are too weak and allow broken
installations. Incrementing it now and rebuilding all dependent packages would
fix them.

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

Kernel: Linux 4.18.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.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libgraphicsmagick++-q16-12 depends on:
ii  libc62.27-8
ii  libgcc1  1:8.2.0-10
ii  libgomp1 8.2.0-10
ii  libgraphicsmagick-q16-3  1.3.30+hg15796-1~deb9u2
ii  libstdc++6   8.2.0-10

libgraphicsmagick++-q16-12 recommends no packages.

Versions of packages libgraphicsmagick++-q16-12 suggests:
pn  graphicsmagick-dbg  

Bug#915603: libgraphicsmagick++-q16-12: Requires soname/shlibs bump for libstdc++11 transition

[Ted Percival]

Package: libgraphicsmagick++-q16-12
Version: 1.3.31-1
Severity: important

Important due to RC Policy "Shared library packages must include correct shlibs
files".

There was an ABI change between libgraphicsmagick++-q16-12 versions
1.3.30+hg15796-1~deb9u2 and 1.3.31-1 but the shlibs file was not changed. As a
result, some dependent packages like python3-pgmagick don't get strict-enough
dependency from dpkg-shlibdeps and can end up in a broken state when built with
the newer library but installed with the older.

Steps to reproduce:

1. Ensure you have the stable repo in your apt sources.
2. Install the older library:

apt install libgraphicsmagick++-q16-12=1.3.30+hg15796-1~deb9u2

3. Install python3-pgmagick from testing/unstable:

apt install python3-pgmagick=0.7.4-1+b2

4. Try to load the library (which has an unconstrained dependency on
   libgraphicsmagick++-q16-12):

echo 'import pgmagick' | python3

Observation: failure to load libGraphicsMagick++-Q16.so due to missing symbol:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/pgmagick/__init__.py", line 1, in 

from pgmagick import _pgmagick
ImportError: 
/usr/lib/python3/dist-packages/pgmagick/_pgmagick.cpython-36m-x86_64-linux-gnu.so:
 undefined symbol: 
_ZNK6Magick5ColorcvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcv

This is because the python3-pgmagick library was built with the newer GM++
library, which declares the same soname/shlibs as the older library, but the
exported symbols differ because of the libstdc++ C++11 ABI change
.

You can compare the exported symbols from each version of
libgraphicsmagick++-q16-12:

readelf -s -W /usr/lib/libGraphicsMagick++-Q16.so.12 | awk '{ print $8 }' | 
sort -u

Diffing the symbol lists, you can see some changes related to the C++11 ABI
change:


-_ZNK6Magick5ColorcvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEB5cxx11Ev
+_ZNK6Magick5ColorcvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcv

There are also some other changes not necessarily related to the libstdc++ ABI
change.

So I think the soname should have been incremented in version 1.3.31-1 to
prevent packages getting dependencies that are too weak and allow broken
installations. Incrementing it now and rebuilding all dependent packages would
fix them.

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

Kernel: Linux 4.18.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.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libgraphicsmagick++-q16-12 depends on:
ii  libc62.27-8
ii  libgcc1  1:8.2.0-10
ii  libgomp1 8.2.0-10
ii  libgraphicsmagick-q16-3  1.3.30+hg15796-1~deb9u2
ii  libstdc++6   8.2.0-10

libgraphicsmagick++-q16-12 recommends no packages.

Versions of packages libgraphicsmagick++-q16-12 suggests:
pn  graphicsmagick-dbg  

-- no debconf information

Bug#909399: kacpimon handles not more than 20 connections

[Ted Felix]

On 11/6/18 7:24 PM, Ted Felix wrote:

Will be included in the 2.0.31 release on November 15 or so.


  A new upstream version (2.0.31) is now available that addresses this 
issue.


https://sourceforge.net/projects/acpid2/files/

Bug#909399: kacpimon handles not more than 20 connections

[Ted Felix]

On 9/22/18 6:55 PM, zieg...@uni-freiburg.de wrote:

starting kacpimon fails because of "too many connections".


  I've bumped the limit from 20 to 100.  See upstream commit [9bc1579]:

https://sourceforge.net/p/acpid2/code/ci/9bc15796a5aed24719312a1505eb5d09965eef4d/

  Will be included in the 2.0.31 release on November 15 or so.

Bug#909399: kacpimon handles not more than 20 connections

[Ted Felix]

  Ah, now I get it.  It's kacpimon that is failing.  That's just a 
debugging tool.  I wouldn't even classify this as "important".  "minor" 
or "wishlist" at best.


  kacpimon is still using the older version of connection_list.c.  It's 
a bit of a mess.  And that one still has a 20 connection limit.  Should 
be fixable by upgrading that file, assuming it's compatible with the 
rest of kacpimon.  Or you can just jack MAX_CONNECTIONS up to 1024.  I 
really should fix this properly one day.


Ted.

Bug#909399: kacpimon handles not more than 20 connections

[Ted Felix]

On 09/22/2018 06:55 PM, zieg...@uni-freiburg.de wrote:

Version: 1:2.0.28-1+b1


  This is odd since this exact problem was fixed in 2.0.20.  It was 
fixed in response to #719659.  As a result, we should be able to handle 
1024 connections.  Do we somehow have a regression?  Or was this not 
properly tested back in 2.0.20?


  I'll have a closer look.

Ted.

Bug#907496: libcurlpp0: Always fails with "No URL set!"

[Ted Percival]

Package: libcurlpp0
Version: 0.8.1-2+b1
Severity: grave
Justification: renders package unusable

libcurlpp0 appears to always fail with a "No URL set!" error message.
I only tested the "Easy" API.

For example even the first example in its repo

doesn't work:

$ g++ -Wall example00.cpp `curlpp-config --cflags --libs` `curl-config --cflags 
--libs`
$ ./a.out 
No URL set!

I recompiled libcurlpp using both 7 & 8[1] and when linking the example program 
to
the new build it works fine (both static & dynamic libs). So I'm not sure where
the problem lies but even after reinstalling the Debian package I could only get
it to work with my local libcurlpp.

[1] GCC package versions:
g++-7: 7.3.0-28
g++-8: 4:8.2.0-1

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

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

Versions of packages libcurlpp0 depends on:
ii  libc6   2.27-5
ii  libcurl47.61.0-1
ii  libgcc1 1:8.2.0-4
ii  libstdc++6  8.2.0-4

libcurlpp0 recommends no packages.

libcurlpp0 suggests no packages.

-- no debconf information

Bug#902717: [macchanger] make default macchanger behavior configurable

[Ted To]

Package: macchanger
Version: 1.7.0-5.3+b1
Severity: wishlist

--- Please enter the report below this line. ---

While I can easily edit /etc/macchanger/ifupdown.sh to change the -e
flag to something else, I'm sure this is not the preferred method.  It
would be nice to have an OPTIONS variable in /etc/default/macchanger
which seems to be the preferred locale for configuration changes.

I'm happy to create a patch if it would be helpful.  I did notice that
the git repository for macchanger no longer works and I am not able to
find the new one.

--- System information. ---
Architecture: Kernel:   Linux 4.9.0-6-amd64

Debian Release: 9.4
  500 stable-updates  ftp.us.debian.org   500 stable
security.debian.org   500 stable  repository.spotify.com   500
stable  ftp.us.debian.org   100 stretch-backports
ftp.us.debian.org   100 stable  www.deb-multimedia.org
--- Package information. ---
Depends (Version) | Installed
=-+-=
libc6(>= 2.4) | debconf (>= 0.5)  |  OR
debconf-2.0   | dpkg (>= 1.15.4)  |  OR
install-info  |

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#895650: [kernel] Suspend only works 1st time for Acer S7 392

[Ted To]

Package: kernel
Version: 4.14.0-0.bpo.3-amd64
Severity: important

--- Please enter the report below this line. ---
Suspend only works first time.  It worked fine on an ancient Acer Aspire
One.  Now on an Acer S7 392, suspend works on its first try but
afterwards fails.  Currently running the backports kernel but didn't
work with stable either.

--- System information. ---
Architecture: Kernel:   Linux 4.14.0-0.bpo.3-amd64

Debian Release: 9.4
  500 stable-updates  deb.debian.org   500 stable
repository.spotify.com   500 stable  deb.debian.org   100
stretch-backports deb.debian.org
--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#895239: [systemd] suspend works 1st time

[Ted To]

That doesn't seem to work either.

It's curious as I've corresponded with someone with the exact same model
who asked on the Debian mailing list in 2015.  They now have everything
working great with Linux Mint 18.2.  But even booting off the 18.2 live
ISO, suspend only works the first time so it doesn't seem like it is the
kernel.  Also, as far as they recall, they did not have any special boot
parameter customizations.

In that regard I've even tried a live ISO of Antergos with a very recent
kernel and still only suspends on the first attempt.

On 04/08/2018 04:49 PM, Michael Biebl wrote:
> 
> Am 08.04.2018 um 19:56 schrieb Ted To:
>> Package: systemd
>> Version: 232-25+deb9u3
>> Severity: important
>>
>> --- Please enter the report below this line. ---
>>
>> Suspend only works first time.  It worked fine on an ancient Acer Aspire
>> One.  Now on an Acer S7 392, suspend works on its first try but
>> afterwards fails.  Currently running the backports kernel but didn't
>> work with stable either.
> 
> If you simply run (as root)
> echo mem > /sys/power/state
> 
> can you suspend/resume multiple times?
> 
> If not, it's most likely a kernel problem and not a systemd problem.
> 
> 
> 

Bug#895239: [systemd] suspend works 1st time

[Ted To]

Package: systemd
Version: 232-25+deb9u3
Severity: important

--- Please enter the report below this line. ---

Suspend only works first time.  It worked fine on an ancient Acer Aspire
One.  Now on an Acer S7 392, suspend works on its first try but
afterwards fails.  Currently running the backports kernel but didn't
work with stable either.

$ sudo journalctl -u suspend.target
[sudo] password for tct:
-- Logs begin at Sun 2018-04-08 12:17:50 EDT, end at Sun 2018-04-08
13:49:23 EDT. --
Apr 08 12:48:07 okeeffe systemd[1]: Reached target Suspend.
Apr 08 12:48:07 okeeffe systemd[1]: suspend.target: Unit is bound to
inactive unit systemd-suspend.service
Apr 08 12:48:07 okeeffe systemd[1]: Stopped target Suspend.
Apr 08 12:48:09 okeeffe systemd[1]: Reached target Suspend.
Apr 08 12:48:09 okeeffe systemd[1]: suspend.target: Unit is bound to
inactive unit systemd-suspend.service
Apr 08 12:48:09 okeeffe systemd[1]: Stopped target Suspend.
Apr 08 13:02:36 okeeffe systemd[1]: Reached target Suspend.
Apr 08 13:02:36 okeeffe systemd[1]: suspend.target: Unit is bound to
inactive unit systemd-suspend.service
Apr 08 13:02:36 okeeffe systemd[1]: Stopped target Suspend.
Apr 08 13:28:28 okeeffe systemd[1]: Reached target Suspend.
Apr 08 13:28:28 okeeffe systemd[1]: suspend.target: Unit is bound to
inactive unit systemd-suspend.service
Apr 08 13:28:28 okeeffe systemd[1]: Stopped target Suspend.
Apr 08 13:29:24 okeeffe systemd[1]: Reached target Suspend.
Apr 08 13:29:24 okeeffe systemd[1]: suspend.target: Unit is bound to
inactive unit systemd-suspend.service
Apr 08 13:29:24 okeeffe systemd[1]: Stopped target Suspend.

and relevant portions of syslog:

Apr  8 13:50:09 debian NetworkManager[533]:   [1523209809.4718]
manager: sleep requested (sleeping: no  enabled: yes)
Apr  8 13:50:09 debian NetworkManager[533]:   [1523209809.4719]
manager: sleeping...
Apr  8 13:50:09 debian NetworkManager[533]:   [1523209809.4720]
manager: NetworkManager state is now ASLEEP
Apr  8 13:50:09 debian NetworkManager[533]:   [1523209809.4724]
device (wlp1s0): state change: activated -> deactivating (reason
'sleeping') [100 110 37]
Apr  8 13:50:09 debian dbus[521]: [system] Activating via systemd:
service name='org.freedesktop.nm_dispatcher'
unit='dbus-org.freedesktop.nm-dispatcher.service'
Apr  8 13:50:09 debian NetworkManager[533]:   [1523209809.4770]
device (wlp1s0): state change: deactivating -> disconnected (reason
'sleeping') [110 30 37]
Apr  8 13:50:09 debian systemd[1]: Starting Network Manager Script
Dispatcher Service...
Apr  8 13:50:09 debian avahi-daemon[519]: Withdrawing address record for
fd21:9228:e650::b2e on wlp1s0.
Apr  8 13:50:09 debian avahi-daemon[519]: Withdrawing address record for
2601:14d:4101:380b::b2e on wlp1s0.
Apr  8 13:50:09 debian avahi-daemon[519]: Withdrawing address record for
fd21:9228:e650:0:889d:b57e:e0cc:c4b2 on wlp1s0.
Apr  8 13:50:09 debian avahi-daemon[519]: Withdrawing address record for
fd21:9228:e650:0:5e51:4fff:fef2:d5b9 on wlp1s0.
Apr  8 13:50:09 debian avahi-daemon[519]: Leaving mDNS multicast group
on interface wlp1s0.IPv6 with address fd21:9228:e650:0:5e51:4fff:fef2:d5b9.
Apr  8 13:50:09 debian avahi-daemon[519]: Joining mDNS multicast group
on interface wlp1s0.IPv6 with address
2601:14d:4101:380b:889d:b57e:e0cc:c4b2.
Apr  8 13:50:09 debian avahi-daemon[519]: Withdrawing address record for
2601:14d:4101:380b:889d:b57e:e0cc:c4b2 on wlp1s0.
Apr  8 13:50:09 debian avahi-daemon[519]: Leaving mDNS multicast group
on interface wlp1s0.IPv6 with address
2601:14d:4101:380b:889d:b57e:e0cc:c4b2.
Apr  8 13:50:09 debian avahi-daemon[519]: Joining mDNS multicast group
on interface wlp1s0.IPv6 with address
2601:14d:4101:380b:5e51:4fff:fef2:d5b9.
Apr  8 13:50:09 debian avahi-daemon[519]: Withdrawing address record for
2601:14d:4101:380b:5e51:4fff:fef2:d5b9 on wlp1s0.
Apr  8 13:50:09 debian avahi-daemon[519]: Leaving mDNS multicast group
on interface wlp1s0.IPv6 with address
2601:14d:4101:380b:5e51:4fff:fef2:d5b9.
Apr  8 13:50:09 debian avahi-daemon[519]: Joining mDNS multicast group
on interface wlp1s0.IPv6 with address fe80::5e51:4fff:fef2:d5b9.
Apr  8 13:50:09 debian avahi-daemon[519]: Registering new address record
for fe80::5e51:4fff:fef2:d5b9 on wlp1s0.*.
Apr  8 13:50:09 debian avahi-daemon[519]: Withdrawing address record for
fe80::5e51:4fff:fef2:d5b9 on wlp1s0.
Apr  8 13:50:09 debian avahi-daemon[519]: Leaving mDNS multicast group
on interface wlp1s0.IPv6 with address fe80::5e51:4fff:fef2:d5b9.
Apr  8 13:50:09 debian avahi-daemon[519]: Interface wlp1s0.IPv6 no
longer relevant for mDNS.
Apr  8 13:50:09 debian dbus[521]: [system] Successfully activated
service 'org.freedesktop.nm_dispatcher'
Apr  8 13:50:09 debian systemd[1]: Started Network Manager Script
Dispatcher Service.
Apr  8 13:50:09 debian nm-dispatcher: req:1 'connectivity-change': new
request (2 scripts)
Apr  8 13:50:09 debian nm-dispatcher: req:1 'connectivity-change': start
running ordered scripts...
Apr  8 13:50:09 debian NetworkManager[533]:   

Bug#884143: ITA: urbit/0.5-1 -- an operating function

[Ted Blackman]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "urbit":

* Package name: urbit
Version : 0.5-1
Upstream Author : Raymond Pasco <r...@the.ug>
* URL : https://urbit.org
* License : MIT
Section : net

It builds these binary packages:
urbit - an operating function

To access further information about this package, please visit the
following URL:
https://github.com/urbit/urbit

The .deb can be found here:
https://github.com/urbit/urbit/releases/download/v0.5.1/urbit_0.5-1_amd64.deb

The files used to generate this package can be found here:
https://github.com/urbit/urbit/tree/master/debian

The package files themselves are available here:
https://bootstrap.urbit.org/urbit_0.5-1_amd64.changes
https://bootstrap.urbit.org/urbit_0.5-1_amd64.upload
https://bootstrap.urbit.org/urbit_0.5-1.dsc

Changes since the last upload:

urbit (0.5-1) unstable; urgency=medium
* hoon %143; new boot sequence; %jael support
-- Ted Blackman <t...@tlon.io>  Thu, 12 Oct 2017 17:11:53 -0700

This is my first time submitting a package to debian. I've tried to follow
the instructions exactly, but I'm not sure I've gotten them all right. I'd
appreciate any advice you're willing to give me as I go though this process.

Thanks,
Ted Blackman

Software Engineer
Tlon Corporation

Bug#866963: shellinabox: Not working. Had it installed on my NAS with Jessie and it was fully working. I did a "dist-upgrade" and it is no longer working. Suspecting that something with my old configu

[Ted To]

Hi Alexandre -- the requested output is below.

$ systemctl status shellinabox
● shellinabox.service - LSB: Shell In A Box Daemon
   Loaded: loaded (/etc/init.d/shellinabox; generated; vendor preset: 
enabled)

   Active: active (running) since Mon 2017-07-03 05:40:18 EDT; 25min ago
 Docs: man:systemd-sysv-generator(8)
  Process: 533 ExecStart=/etc/init.d/shellinabox start (code=exited, 
status=0/SUCCES

Tasks: 2 (limit: 4915)
   CGroup: /system.slice/shellinabox.service
   ├─582 /usr/bin/shellinaboxd -q 
--background=/var/run/shellinaboxd.pid -c
   └─583 /usr/bin/shellinaboxd -q 
--background=/var/run/shellinaboxd.pid -c


$ sudo journalctl -u shellinabox
-- Logs begin at Mon 2017-07-03 05:39:43 EDT, end at Mon 2017-07-03 
06:06:25 EDT. --
Jul 03 05:40:18 debian systemd[1]: Starting LSB: Shell In A Box 
Daemon...

Jul 03 05:40:18 debian systemd[1]: Started LSB: Shell In A Box Daemon.

On 2017-07-03 5:36 am, Alexandre Detiste wrote:

control: severity -1 normal
control: retitle -1 shellinabox: Not working
control: tag -1 +moreinfo

Hi,

Please provide/look at more information like output from
"systemctl status shellinabox" and or "journalctl -u shellinabox".

This way we'll my have enough information to reproduce this bug.

Greets,

Alexandre Detiste

2017-07-03 4:28 GMT+02:00 Ted To <t...@theo.to>:

Package: shellinabox
Version: 2.20
Severity: grave
Justification: renders package unusable

Bug#866963: shellinabox: Not working. Had it installed on my NAS with Jessie and it was fully working. I did a "dist-upgrade" and it is no longer working. Suspecting that something with my old configu

[Ted To]

Package: shellinabox
Version: 2.20
Severity: grave
Justification: renders package unusable

Dear Maintainer,

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


   * What led up to the situation?
 dist-upgraded NAS

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 installed it on a VM

   * What was the outcome of this action?
 still not working

   * What outcome did you expect instead?
 was hoping it would be working

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


-- System Information:
Debian Release: 9.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 4.9.0-3-marvell
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages shellinabox depends on:
ii  adduser3.115
ii  libc6  2.24-11+deb9u1
ii  libpam0g   1.1.8-3.6
ii  libssl1.1  1.1.0f-3
ii  lsb-base   9.20161125
ii  zlib1g 1:1.2.8.dfsg-5

shellinabox recommends no packages.

Versions of packages shellinabox suggests:
ii  openssl  1.1.0f-3

-- no debconf information

Bug#808015: acpid: FTBFS: libnetlink.c:497:54: error: comparison between signed and unsigned integer expressions

[Ted Felix]

On 12/15/2015 11:19 AM, Chris Lamb wrote:

Yep, works great. (Both in ./libnetlink.c and ./kacpimon/libnetlink.c)


  Ok, this should be fixed upstream in [32f291].

https://sourceforge.net/p/acpid2/code/ci/32f291

  I'll do an official release 1/15/2016.  Unless you'd like it sooner.

Ted.

Bug#808015: acpid: FTBFS: libnetlink.c:497:54: error: comparison between signed and unsigned integer expressions

[Ted Felix]

On 12/15/2015 06:00 AM, Chris Lamb wrote:

acpid fails to build from source in unstable/amd64:
   libnetlink.c: In function 'addattr_l':
   libnetlink.c:497:54: error: comparison between signed and unsigned integer 
expressions [-Werror=sign-compare]
 if ((int)NLMSG_ALIGN(n->nlmsg_len) + RTA_ALIGN(len) > maxlen) {
 ^
   libnetlink.c: In function 'rta_addattr32':
   libnetlink.c:527:36: error: comparison between signed and unsigned integer 
expressions [-Werror=sign-compare]
 if (RTA_ALIGN(rta->rta_len) + len > maxlen) {
   ^
   libnetlink.c: In function 'rta_addattr_l':
   libnetlink.c:545:47: error: comparison between signed and unsigned integer 
expressions [-Werror=sign-compare]
 if (RTA_ALIGN(rta->rta_len) + RTA_ALIGN(len) > maxlen) {
  ^


  As it is, it's building fine for me.  I assume I have an older 
rtnetlink.h.


  The common thread here is RTA_ALIGN().  My guess is that it's now 
returning an unsigned.  Adding an (int) to each one should fix it.  E.g.:


if ((int)RTA_ALIGN(rta->rta_len) + len > maxlen) {

  Give it a try and let me know.  If it works, I'll get it in upstream.

Ted.

Bug#792432: OSX Compile Errors

[Ted Toal]

Package: e-PCR
Version: 2.3.12

When I try to build the e-PCR program, a variety of errors occur.  The build 
command I use is:

make LF64LDFLAGS= LF64CCFLAGS=-DNATIVE_LARGEFILES

I am using OSX Yosemite V10.10.3, with Xcode 5.02 and Xcode command line tools 
installed. 

I was able to fix the errors with these code changes:

1. Uncomment '#include sstream' in mmap.cpp

2. Add these includes to epcr/minilcs.hpp:

#include cstdlib
#include sstream

With these changes the build succeeds but several warnings are issued.  Some 
include a description of how these warnings can be eliminated with code changes 
(that seem like reasonable changes).  I was able to eliminate the warnings with 
this command line:

make LF64LDFLAGS= LF64CCFLAGS=-DNATIVE_LARGEFILES COMMON_CC_FLAGS=-w

I suggest that the above command line be included in the BUILD.html and 
BUILD.txt files under the OSX section.  The warnings are:

stsfilter.cpp:47:49: warning: '' within '||' [-Wlogical-op-parentheses]
return (o1.pos2o2.pos2 || o1.pos2==o2.pos2  o1.pos1o2.pos1);
~~ ~^~
stsfilter.cpp:47:49: note: place parentheses around the '' expression to 
silence this warning

fahash_lookup.cpp:343:38: warning: '' within '||' [-Wlogical-op-parentheses]
return sid  s.sid || sid == s.sid  pos  s.pos;
   ~~ ~^~
fahash_lookup.cpp:343:38: note: place parentheses around the '' expression to 
silence this warning

fahash_lookup.cpp:385:60: warning: '' within '||' [-Wlogical-op-parentheses]
 ( gaps()  h.gaps() || gaps() == h.gaps() 
 ~~ ~~~^~
fahash_lookup.cpp:385:60: note: place parentheses around the '' expression to 
silence this warning
   ^
fahash_lookup.cpp:384:52: warning: '' within '||' [-Wlogical-op-parentheses]
 ( pos2  h.pos2 || pos2 == h.pos2 
 ~~ ~~~^~
fahash_lookup.cpp:384:52: note: place parentheses around the '' expression to 
silence this warning
   ^
fahash_lookup.cpp:383:52: warning: '' within '||' [-Wlogical-op-parentheses]
return pos1  h.pos1 || pos1 == h.pos1  
 ~~ ~~~^~
fahash_lookup.cpp:383:52: note: place parentheses around the '' expression to 
silence this warning
   ^
fahash_lookup.cpp:435:54: warning: '' within '||' [-Wlogical-op-parentheses]
return ( o1.pos2  o2.pos2 || o1.pos2 == o2.pos2  o1.pos1  o2.pos1 );
   ~~ ~~~^~~~
fahash_lookup.cpp:435:54: note: place parentheses around the '' expression to 
silence this warning

fahash_main.cpp:257:9: warning: enumeration value 'eNone' not handled in switch 
[-Wswitch]
switch(command) {
   ^

fahash_main.cpp:261:1: warning: control may reach end of non-void function 
[-Wreturn-type]
}
^

re-PCR_main.cpp:345:9: warning: enumeration value 'eNone' not handled in switch 
[-Wswitch]
switch(command) {
   ^

re-PCR_main.cpp:349:1: warning: control may reach end of non-void function 
[-Wreturn-type]
}
^

re-PCR_main.cpp:488:46: warning: format specifies type 'unsigned int' but the 
argument has type 'unsigned long' [-Wformat]
argv[i],fcount+1,fcount+stslist.size());
 ^

re-PCR_main.cpp:502:38: warning: format specifies type 'unsigned int' but the 
argument has type 'unsigned long' [-Wformat]
argv[i],fcount+1,fcount+stslist.size());
 ^



--
Ted Toal, Graduate Student, twt...@ucdavis.edu
Brady Lab, UC Davis, Life Sciences 2243
One Shields Ave., Davis, CA  95616, ph: (530) 752-2537

Bug#792434: OSX Compile Errors

[Ted Toal]

Package: ncbi-epcr
Version: 2.3.12

When I try to build the e-PCR program, a variety of errors occur.  The build 
command I use is:

make LF64LDFLAGS= LF64CCFLAGS=-DNATIVE_LARGEFILES

I am using OSX Yosemite V10.10.3, with Xcode 5.02 and Xcode command line tools 
installed. 

I was able to fix the errors with these code changes:

1. Uncomment '#include sstream' in mmap.cpp

2. Add these includes to epcr/minilcs.hpp:

#include cstdlib
#include sstream

With these changes the build succeeds but several warnings are issued.  Some 
include a description of how these warnings can be eliminated with code changes 
(that seem like reasonable changes).  I was able to eliminate the warnings with 
this command line:

make LF64LDFLAGS= LF64CCFLAGS=-DNATIVE_LARGEFILES COMMON_CC_FLAGS=-w

I suggest that the above command line be included in the BUILD.html and 
BUILD.txt files under the OSX section.  The warnings are:

stsfilter.cpp:47:49: warning: '' within '||' [-Wlogical-op-parentheses]
return (o1.pos2o2.pos2 || o1.pos2==o2.pos2  o1.pos1o2.pos1);
~~ ~^~
stsfilter.cpp:47:49: note: place parentheses around the '' expression to 
silence this warning

fahash_lookup.cpp:343:38: warning: '' within '||' [-Wlogical-op-parentheses]
return sid  s.sid || sid == s.sid  pos  s.pos;
   ~~ ~^~
fahash_lookup.cpp:343:38: note: place parentheses around the '' expression to 
silence this warning

fahash_lookup.cpp:385:60: warning: '' within '||' [-Wlogical-op-parentheses]
 ( gaps()  h.gaps() || gaps() == h.gaps() 
 ~~ ~~~^~
fahash_lookup.cpp:385:60: note: place parentheses around the '' expression to 
silence this warning
   ^
fahash_lookup.cpp:384:52: warning: '' within '||' [-Wlogical-op-parentheses]
 ( pos2  h.pos2 || pos2 == h.pos2 
 ~~ ~~~^~
fahash_lookup.cpp:384:52: note: place parentheses around the '' expression to 
silence this warning
   ^
fahash_lookup.cpp:383:52: warning: '' within '||' [-Wlogical-op-parentheses]
return pos1  h.pos1 || pos1 == h.pos1  
 ~~ ~~~^~
fahash_lookup.cpp:383:52: note: place parentheses around the '' expression to 
silence this warning
   ^
fahash_lookup.cpp:435:54: warning: '' within '||' [-Wlogical-op-parentheses]
return ( o1.pos2  o2.pos2 || o1.pos2 == o2.pos2  o1.pos1  o2.pos1 );
   ~~ ~~~^~~~
fahash_lookup.cpp:435:54: note: place parentheses around the '' expression to 
silence this warning

fahash_main.cpp:257:9: warning: enumeration value 'eNone' not handled in switch 
[-Wswitch]
switch(command) {
   ^

fahash_main.cpp:261:1: warning: control may reach end of non-void function 
[-Wreturn-type]
}
^

re-PCR_main.cpp:345:9: warning: enumeration value 'eNone' not handled in switch 
[-Wswitch]
switch(command) {
   ^

re-PCR_main.cpp:349:1: warning: control may reach end of non-void function 
[-Wreturn-type]
}
^

re-PCR_main.cpp:488:46: warning: format specifies type 'unsigned int' but the 
argument has type 'unsigned long' [-Wformat]
argv[i],fcount+1,fcount+stslist.size());
 ^

re-PCR_main.cpp:502:38: warning: format specifies type 'unsigned int' but the 
argument has type 'unsigned long' [-Wformat]
argv[i],fcount+1,fcount+stslist.size());
 ^



--
Ted Toal, Graduate Student, twt...@ucdavis.edu mailto:twt...@ucdavis.edu
Brady Lab, UC Davis, Life Sciences 2243
One Shields Ave., Davis, CA  95616, ph: (530) 752-2537

Bug#773329: Upstream fix

[Ted Felix]

  This has now been fixed upstream in Rosegarden.  The relevant commits 
are r13910 and r13911.


https://sourceforge.net/p/rosegarden/code/13910/
https://sourceforge.net/p/rosegarden/code/13911/

Ted.


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

Bug#773329: Incorrect Cflags line in jack.pc

[Ted Felix]

On 04/19/2015 09:10 AM, Adrian Knoth wrote:

The cflags from pkg-config for jack are incorrect which breaks makefiles
and configure scripts that depend on them (e.g. those for rosegarden).

I tend to disagree - more likely, rosegarden is broken, because a ton of
other software that relies on jackd compiles just fine.


  It appears that the issue is that rosegarden is using 
PKG_CHECK_MODULES() when it should be using AC_CHECK_LIB().  I just 
tried AC_CHECK_LIB() and it works fine.  I'll get it into the next 
release of rosegarden.



   Cflags: -I/usr/include

...should be this:

   Cflags: -I${includedir} -I${includedir}/jack

No, -I/usr/include is correct, because the appropriate include is

#include jack/jack.h


  I thought this too, but actually the issue is a quirk in the way 
pkg-config works.  The Cflags line in the .pc file has to follow a very 
specific and strange format (shown above) for PKG_CHECK_MODULES() to 
work.  It's really quite bizarre and perplexing.  AC_CHECK_LIB() is much 
more reliable.



So wontfix?


  I agree.


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

Bug#772148: Attaching patch

[Ted Gould]

Here is the patch I thought I originally had on the bug.
diff --git a/debian/bustle-pcap.install b/debian/bustle-pcap.install
new file mode 100644
index 000..242724b
--- /dev/null
+++ b/debian/bustle-pcap.install
@@ -0,0 +1 @@
+usr/bin/bustle-pcap
diff --git a/debian/bustle.install b/debian/bustle.install
new file mode 100644
index 000..f73f493
--- /dev/null
+++ b/debian/bustle.install
@@ -0,0 +1,2 @@
+usr/share/*
+usr/bin/bustle
diff --git a/debian/changelog b/debian/changelog
index 4c751f4..4870212 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+bustle (0.4.7-2+ted1) UNRELEASED; urgency=medium
+
+  * d/control: Split out bustle-pcap into its own binary package
+
+ -- Ted Gould t...@gould.cx  Fri, 05 Dec 2014 09:02:48 -0600
+
 bustle (0.4.7-2) unstable; urgency=medium
 
   * d/control: really build depend on intltool
diff --git a/debian/control b/debian/control
index e694cf2..710cb84 100644
--- a/debian/control
+++ b/debian/control
@@ -29,6 +29,7 @@ Package: bustle
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Suggests: graphviz
+Recommends: bustle-pcap
 Description: D-Bus activity visualiser
  Bustle is a tool to chart and provide timing information of D-Bus
  calls for profiling and debugging purposes. It is intended to replace
@@ -39,4 +40,16 @@ Description: D-Bus activity visualiser
  data in Graphviz format.
  .
  This package contains the graphical visualizer for traces generated
- with the bustle-pcap tool.
+ with the bustle-pcap tool in the bustle-pcap package.
+
+Package: bustle-pcap
+Architecture: any
+Depends: ${misc:Depends}, ${shlibs:Depends}
+Conflicts: bustle (= 0.4.7-2)
+Description: D-Bus traffic capture tool for the pcap format
+ Bustle is a tool to chart and provide timing information of D-Bus
+ calls for profiling and debugging purposes. It is intended to replace
+ reading the cryptic output of dbus-monitor.
+ .
+ This package contains the capture tool which will capture the D-Bus
+ traffic into a pcap file that can be visualized using Bustle.
diff --git a/debian/rules b/debian/rules
index 34881fb..6c84f82 100755
--- a/debian/rules
+++ b/debian/rules
@@ -21,5 +21,5 @@ override_dh_auto_build:
 	./setup build
 
 override_dh_install:
-	./setup copy --destdir debian/bustle
+	./setup copy --destdir debian/tmp
 	dh_install

Bug#773329: Incorrect Cflags line in jack.pc

[Ted Felix]

Package: libjack-jackd2-dev
Version: 1.9.10+20140719git3eb0ae6a~dfsg-2

The cflags from pkg-config for jack are incorrect which breaks makefiles 
and configure scripts that depend on them (e.g. those for rosegarden).


The culprit is the Cflags line at the end of 
/usr/lib/x86_64-linux-gnu/pkgconfig/jack.pc.  This:


  Cflags: -I/usr/include

...should be this:

  Cflags: -I${includedir} -I${includedir}/jack

This problem is present in both jessie and sid.  I didn't check wheezy 
or prior.



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

Bug#772148: bustle: Split out bustle-pcap into a separate binary package

[Ted Gould]

Package: bustle
Version: 0.4.2-1
Severity: wishlist

Dear Maintainer,

It would be useful to be able to install the monitor on a device that doesn't
have the full stack required for the visualizer. Then a capture can be taken
and transfered to a machine that has the visualizer to be analyzed.

Thanks,
Ted



-- System Information:
Debian Release: jessie/sid
  APT prefers utopic-updates
  APT policy: (500, 'utopic-updates'), (500, 'utopic-security'), (500, 
'utopic'), (100, 'utopic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages bustle depends on:
ii  libatk1.0-0 2.12.0-1ubuntu2
ii  libc6   2.19-10ubuntu2.1
ii  libcairo2   1.13.0~20140204-0ubuntu1
ii  libffi6 3.1-2
ii  libgdk-pixbuf2.0-0  2.30.8-1
ii  libglib2.0-02.42.1-1~ubuntu1
ii  libgmp102:6.0.0+dfsg-4build1
ii  libgtk2.0-0 2.24.25-0ubuntu1
ii  libpango1.0-0   1.36.6-1
ii  libpcap0.8  1.6.2-1

bustle recommends no packages.

Versions of packages bustle suggests:
ii  graphviz  2.38.0-5build1

-- no debconf information


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

Bug#769729: cron-apt: package should recommend cron-daemon

[Ted Kotz]

It looks like supporting /etc/cron.d and /etc/crontab format are requirements 
for packages providing cron-daemon.  As systemd-cron had a bug report against 
it until it provided support for those formats and fcron does not provide 
cron-daemon.

I can't really say if it should be required or suggested. I was surprised it 
wasn't required as a package that integrates with cron should need cron.

If you have a preference for a specific cron implementation just or it into 
the list.

Depends: cron | cron-daemon

If it encounters this dependency it will prefer to install the first one.  I 
think the virtual package gives preference to the Debian default which I 
believe is croon right now.

Ola Lundqvist o...@inguza.com wrote:
Hi

Good suggestion. However I need to know if other daemons are compatible
with /etc/cron.d file format.

I guess it should be a dependency on cron-daemon and recommend on cron.
or?

/ Ola

Inguza Technology AB
Sent from a phone
Den 15 nov 2014 23:15 skrev Ted Kotz t...@kotz.us:

 Package: cron-apt
 Version: 0.9.2
 Severity: normal

 Dear Maintainer,


 This package should recommend virtual package cron-daemon instead
of
 cron. That way users can use an alternative cron daemon more easily.


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

 Kernel: Linux 3.16.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 cron-apt depends on:
 ii  apt  1.0.9.3

 Versions of packages cron-apt recommends:
 ii  bsd-mailx [mailx]  8.1.2-0.20140825cvs-1
 pn  cron   none
 ii  liblockfile1   1.09-6

 cron-apt suggests no packages.

 -- Configuration Files:
 /etc/cron-apt/action.d/3-download changed:
 autoclean -y
 dist-upgrade -d -y -o APT::Get::Show-Upgraded=true
 upgrade -d -y -o APT::Get::Show-Upgraded=true


 -- no debconf information


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#769729: cron-apt: package should recommend cron-daemon

[Ted Kotz]

Package: cron-apt
Version: 0.9.2
Severity: normal

Dear Maintainer,


This package should recommend virtual package cron-daemon instead of
cron. That way users can use an alternative cron daemon more easily.


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

Kernel: Linux 3.16.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 cron-apt depends on:
ii  apt  1.0.9.3

Versions of packages cron-apt recommends:
ii  bsd-mailx [mailx]  8.1.2-0.20140825cvs-1
pn  cron   none
ii  liblockfile1   1.09-6

cron-apt suggests no packages.

-- Configuration Files:
/etc/cron-apt/action.d/3-download changed:
autoclean -y
dist-upgrade -d -y -o APT::Get::Show-Upgraded=true
upgrade -d -y -o APT::Get::Show-Upgraded=true


-- no debconf information


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

Bug#766991: acpid: does not process events

[Ted Felix]

On 10/27/2014 09:05 AM, Norbert Preining wrote:

The reason is that acpid is not started automatically anymore, but
some systemd tells me that something about socket activation etc.


  I've not used systemd yet, but I'm pretty sure acpid works fine when 
the socket is sent in as the stdin fd (or something along those lines, 
there was a patch made to acpid to allow it to work with its socket sent 
in via a fd for the systemd folks).


  I would recommend comparing your acpid.service file with Fedora's:

http://pkgs.fedoraproject.org/cgit/acpid.git/tree/acpid.service

  Then have a look at this bug report on the acpid2 page:

http://sourceforge.net/p/acpid2/tickets/3/

  Just some thoughts.  Hopefully some of this helps you out.  Again, 
I've not used systemd yet, so I'm of limited help.  Let us know if any 
of this helps you out and what changes you had to make to the config 
files so we can get the changes into Debian.


Thanks for the bug report.
Ted.


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

Bug#766397: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Ted Zlatanov]

On Thu, 23 Oct 2014 12:34:38 -0400 Richard Stallman r...@gnu.org wrote: 

RS I've read that falling back to ssl3 is a real security hole,
RS being exploited frequently.  That feature should be removed.

That's not really relevant to the bug report, but with GnuTLS you use
priority strings to control this.  Nikos, the GnuTLS maintainer, asked
for feedback on disabling it in the default priority string in the
mailing list:

http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/7732

If you're using the Emacs GnuTLS integration, you simply set the
priority string through `gnutls-algorithm-priority' to what works for
you; for example SECURE256:-VERS-SSL3.0. I'd rather wait for the final
decision from the GnuTLS maintainer than change the Emacs default.

If you're using the external s_client, you need to customize its
invocation accordingly.

HTH
Ted


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

Bug#766397: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Ted Zlatanov]

On Thu, 23 Oct 2014 10:57:17 -0500 Rob Browning r...@defaultvalue.org wrote: 

RB Ted Zlatanov t...@lifelogs.com writes:
 could you provide a test case?  The information gathered by
 `M-x report-emacs-bug' would be really helpful, too.

RB Hmm, I'm not the original reporter, and don't yet deeply understand the
RB relevant issues, but on the surface, the bug appears to just ask that
RB Emacs stop using or mentioning s_client.

I replied to the bug address as well, so I hope Kurt responds with a recipe.

RB If that turns out to be a reasonable request, then I'd imagine that the
RB code in imap.el, etc. would need adjustment, i.e.

No, the logic that needs to change is the one that opens the network
stream (and imap.el will be obsoleted, as Lars and Stefan mentioned).
But I'd like to know what's using imap.el in Kurt's case because I don't
know of any code that uses it.  Was he just warning that imap.el *could*
use s_client?  I went to the original bug report and couldn't find that
information, sorry.

RB In any case, I can certainly send you the report-emacs-bug information
RB from my system, but the bug didn't originate there (I don't even have
RB emacs23 installed at the moment).  Did you mean for Kurt to send it?

Yes, sorry, the web interface misled me.  Kurt?

RB And what kind of test did you have in mind?

Some code that lets me replicate the bug or issue on a Debian system,
with enough information to let me bring up such a system in a virtual
environment.

Ted


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

Bug#766397: Bug#766395: emacs/gnus: Uses s_client to for SSL.

[Ted Zlatanov]

On Wed, 22 Oct 2014 15:05:02 -0500 Rob Browning r...@defaultvalue.org wrote: 

RB Rob Browning r...@defaultvalue.org writes:
 The following issue was just reported against emacs23 in Debian, and
 from a quick glance, it looks like 24.4 still uses s_client, so if this
 is a problem, it's perhaps still relevant.

RB Oh, and the link (for the emacs24 bug cloned from the emacs23 bug) is
RB here:

RB   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766397

Hi Rob,

could you provide a test case?  The information gathered by
`M-x report-emacs-bug' would be really helpful, too.

Ted


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

Bug#757949: sogo: daily log rotation stops sogo due to old process taking too long to exit

[Ted Kotz]

Package: sogo
Version: 2.0.5a-1~bpo70+1
Severity: normal

Dear Maintainer,
I found my sogo instance was sometimes hanging. Further investigation led me to 
this bug report in the upstream package.
http://www.sogo.nu/bugs/view.php?id=1865

This change exists in the source code under Scripts/logrotate. 

The change is not reflected in /etc/logrotate.d/sogo though which probably 
should be just a copy of the logrotate file from upstream.

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

Kernel: Linux 3.14.5-x86_64-linode42 (SMP w/8 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 sogo depends on:
ii  adduser   3.113+nmu3
ii  gnustep-base-runtime  1.22.1-4
ii  libc6 2.13-38+deb7u3
ii  libcurl3-gnutls   7.26.0-1+wheezy9
ii  libgcc1   1:4.7.2-5
ii  libglib2.0-0  2.33.12+really2.32.4-5
ii  libgnustep-base1.22   1.22.1-4
ii  libgnutls26   2.12.20-8+deb7u2
ii  liblasso3 2.3.6-2
ii  libmemcached101.0.8-1
ii  libobjc4  4.7.2-5
ii  libsbjson2.3  2.3.2-2
ii  libsope1  2.0.5-1~bpo70+1
ii  libssl1.0.0   1.0.1e-2+deb7u11
ii  libxml2   2.8.0+dfsg1-7+wheezy1
ii  libxmlsec11.2.18-2
ii  libxmlsec1-openssl1.2.18-2
ii  libxslt1.11.1.26-14.1
ii  sogo-common   2.0.5a-1~bpo70+1
ii  tmpreaper 1.6.13+nmu1
ii  zip   3.0-6

sogo recommends no packages.

Versions of packages sogo suggests:
ii  postgresql  9.1+134wheezy4

-- Configuration Files:
/etc/default/sogo changed:
PREFORK=2

/etc/logrotate.d/sogo changed:
/var/log/sogo/*.log {
daily
missingok
rotate 7
compress
delaycompress
notifempty
copytruncate
}

/etc/sogo/sogo.conf changed:
{
  SOGoProfileURL = 
postgresql://sogo:sogo@localhost:5432/sogo/sogo_user_profile;;
  OCSFolderInfoURL = 
postgresql://sogo:sogo@localhost:5432/sogo/sogo_folder_info;;
  OCSSessionsFolderURL = 
postgresql://sogo:sogo@localhost:5432/sogo/sogo_sessions_folder;;
  OCSEMailAlarmsFolderURL = 
postgresql://sogo:sogo@localhost:5432/sogo/sogo_alarms_folder;;
  SOGoLanguage = English;
  SOGoAppointmentSendEMailNotifications = YES;
  SOGoFoldersSendEmailNotifications = YES;
  SOGoACLsSendEmailNotifications = YES;
  SOGoMailingMechanism = sendmail;
  WOSendMail = /usr/sbin/sendmail;
  SOGoTimeZone = America/New_York;
  SOGoMailDomain = kotz.us;
  SOGoLanguage = English;
  SOGoSentFolderName = Sent;
  SOGoTrashFolderName = Trash;
  SOGoDraftsFolderName = Drafts;
  SOGoIMAPServer = imaps://localhost:993/;;
  SOGoSieveServer = sieve://localhost:4190/?tls=YES;;
  SOGoIMAPAclConformsToIMAPExt = YES;
  SOGoVacationEnabled = NO;
  SOGoForwardEnabled = NO;
  SOGoSieveScriptsEnabled = NO;
  SOGoFirstDayOfWeek = 0;
  SOGoMailMessageCheck = every_2_minutes;
  SOGoMailAuxiliaryUserAccountsEnabled = YES;
  domains = {
kotz.us = {
  SOGoMailDomain = kotz.us;
  SOGoUserSources = (
{
  type = ldap;
  id = kotz.us; 
  CNFieldName = cn; 
  IDFieldName = uid; 
  UIDFieldName = uid; 
  bindFields = (uid, cn); 
  IMAPLoginFieldName = uid;
  IMAPHostFieldName = gosaMailServer; 
  baseDN = ou=People,dc=kotz,dc=us; 
  filter = (objectClass=gosaMailAccount)(gosaMailServer=kotz.us);
  bindAsCurrentUser = YES; 
  hostname = localhost; 
  port = 389; 
  canAuthenticate = YES; 
  isAddressBook = YES; 
  displayName = Kotz.us Users;
  userPasswordAlgorithm = ssha;
}
  );
};
  };
  SOGoPasswordChangeEnabled = YES;
  WOWatchDogRequestTimeout = 3;
  SxVMemLimit = 256;
  NGImap4ConnectionStringSeparator = /;
  NGImap4DisableIMAP4Pooling = NO;
  SoDebugKeyLookup = NO;
  SoDebugBaseURL = NO;
  SOGoMemcachedHost = 127.0.0.1;
  SOGoiPhoneForceAllDayTransparency = YES;
  SOGoEnablePublicAccess = YES;
  
}


-- no debconf information


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

Bug#756571: Loops: modify_ldt: Invalid argument; err:module:find_forwarded_export ... for 'krnl386.exe16.MapLS'

[Ted Anderson]

Package: wine
Version: 1.4.1-4
Severity: normal
Tags: upstream

Dear Maintainer,

   * What led up to the situation?

After 57 days of uptime, I rebooted and picked up a new kernel (there 
were several kernel updates since early June).  However, I was unable to 
start Notes7 under Wine.  The result is that the program looped after 
generating these messages:


p11-kit: couldn't load module: 
/usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: 
/usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open 
shared object file: No such file or directory

modify_ldt: Invalid argument
modify_ldt: Invalid argument
modify_ldt: Invalid argument
modify_ldt: Invalid argument
modify_ldt: Invalid argument
err:module:find_forwarded_export module not found for forward 
'krnl386.exe16.MapLS' used by Lc:\\windows\\system32\\KERNEL32.dll


I'm pretty sure the first of these is irrelevant.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?

Web searching for terms in the final error message were unenlightening. 
 Eventually, I was lead to a launchpad bug 1327532[1] and a Linux 
Kernel Mailing List discussion[2].  I was able to confirm that setting 
ldt16 to 1 resolved the problem and allowed Notes7 to start.

# echo 1   /proc/sys/abi/ldt16

From the linux-image-amd64 change log I saw that these two patches were 
included in the kernel on 29 Jun 2014 (linux (3.2.60-1) wheezy; 
urgency=medium).  I installed this kernel on July 7th.


- [amd64] modify_ldt: Ban 16-bit segments on 64-bit kernels
- [amd64] modify_ldt: Make support for 16-bit segments a runtime option

Eventually, I found Wine bug 36664[3] and FAQ-10.22[4].

The diagnosis was made difficult because my error message was unusual in 
containing find_forwarded_export and my program is a 32-bit 
application.  Apparently, even some 32-bit applications make use of 
16-bit DLLs or functions.


[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1327532
[2] https://lkml.org/lkml/2014/5/7/508
[3] https://bugs.winehq.org/show_bug.cgi?id=36664
[4] http://wiki.winehq.org/FAQ#head-bf26e320f9d279ba6d2e039f7d91f0a60a433f88

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

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

% uname -a
Linux anapneo 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux

IBM Lotus Notes, version 7.0.3.

Versions of packages wine depends on:
ii  debconf [debconf-2.0]  1.5.49
ii  wine-bin   1.4.1-4

wine recommends no packages.

Versions of packages wine suggests:
pn  binfmt-support none
pn  klamav | clamavnone
pn  ttf-mscorefonts-installer  none
pn  winbindnone
pn  wine-doc   none

Versions of packages libwine depends on:
ii  debconf [debconf-2.0]  1.5.49
ii  libc6  2.13-38+deb7u3
ii  libdbus-1-31.6.8-1+deb7u3
ii  libfontconfig1 2.9.0-7.1
ii  libfreetype6   2.4.9-1.1
ii  libgnutls262.12.20-8+deb7u2
ii  libice62:1.0.8-2
ii  libjpeg8   8d-1+deb7u1
ii  libmpg123-01.14.4-1
ii  libncurses55.9-10
ii  libodbc1   2.2.14p2-5
ii  libpng12-0 1.2.49-1
ii  libsm6 2:1.2.1-2
ii  libssl1.0.01.0.1e-2+deb7u11
ii  libtiff4   3.9.6-11
ii  libtinfo5  5.9-10
ii  libx11-6   2:1.5.0-1+deb7u1
ii  libxcomposite1 1:0.4.3-2
ii  libxcursor11:1.1.13-1+deb7u1
ii  libxext6   2:1.3.1-2+deb7u1
ii  libxi6 2:1.6.1-1+deb7u1
ii  libxinerama1   2:1.1.2-1+deb7u1
ii  libxml22.8.0+dfsg1-7+wheezy1
ii  libxrandr2 2:1.3.2-2+deb7u1
ii  libxrender11:0.9.7-1+deb7u1
ii  libxslt1.1 1.1.26-14.1
ii  libxxf86vm11:1.1.2-1+deb7u1
ii  multiarch-support  2.13-38+deb7u3
ii  zlib1g 1:1.2.7.dfsg-13

Versions of packages libwine recommends:
ii  libgsm1 1.0.13-4
ii  libv4l-00.8.8-3
ii  libwine-alsa1.4.1-4
ii  libwine-gl  1.4.1-4
ii  ttf-liberation  1.07.2-6

Versions of packages libwine suggests:
pn  libwine-cms  none
pn  libwine-gphoto2  none
pn  libwine-ldap none
pn  libwine-openal   none
pn  libwine-printnone
pn  libwine-sane none
pn  wine-doc none

-- no debconf information


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

Bug#752283: acpid: thinkpad t400s, suspend when LID closed stopped working

[Ted Felix]

On 06/22/2014 02:47 AM, Gijs Hillenius wrote:

Sometime following a recent update, closing the lid of this
Thinkpad T400s no longer suspends.


  This is not likely to be an acpid issue.  It could be a window 
manager issue, an acpi-support issue, or a kernel issue.  Here are some 
things to try:


1. Try using kacpimon to verify that lid close/open events are coming 
in.  See the man page for kacpimon.  If the events aren't coming in, 
you've got a kernel issue.


2. If you've got lid close/open events coming in, then you'll need to 
check and see if your window manager is responsible for handling lid 
open/close.  Some are, some aren't.  If yours is, and you've got it 
configured properly, then you may have a window manager issue.


3. Lastly, take a look in /etc/acpi/events (see the man page for acpid 
for more info).  Is there a lid closed configuration file in there (e.g. 
/etc/acpi/events/lidbtn)?  Is it properly connected to a script (e.g. 
/etc/acpi/lid.sh)?  Is that script working?  If there is a broken script 
or config file in here, then you've likely got an acpi-support issue.



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

Bug#367320: Patch available

[Ted Percival]

On Sat, Dec 28, 2013 at 6:31 PM, Geoffrey Thomas geo...@ldpreload.com wrote:
 On Sat, 2 Sep 2006, Ted Percival wrote:

 I have written a patch that adds timestamps to the output of prelink
 through a -T command-line option. The patch is attached as
 prelink-timestamp.patch and has been sent upstream.

 I notice this patch isn't present in current prelink SVN. Did you get a 
 response from upstream about including it, or shall I resubmit it to them?

I don't remember getting a response from upstream, feel free to submit
to them (or remove it if you like - it doesn't concern me anymore).


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

Bug#732277: Option for acpid to drop certain events completely

[Ted Felix]

On 12/16/2013 04:03 AM, Pigeon wrote:

event=battery.*
action=DIEDIEDIE


  Thanks for the patch.  I will review it today.  It sounds like an 
interesting feature.



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

Bug#719659: acpid 2.0.20 released

[Ted Felix]

  This has been fixed in acpid 2.0.20 just released today.

http://sourceforge.net/projects/acpid2


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

Bug#719659: acpid ignores its unix socket on systems with many event interfaces

[Ted Felix]

On 08/13/2013 10:42 PM, Ben Winslow wrote:

The simplest
fix would be simply raising MAX_CONNECTIONS in connection_list.c


Thanks (again) for the bug report.  I've just pushed a quick fix to the
sourceforge repo with MAX_CONNECTIONS bumped to 100.  I will pursue a
more satisfactory solution next.  Here's the patch in case anyone needs
it immediately:

commit 903271fb387ad4cc630c29810eecaacfb3e21080
Author: Ted Felix t...@tedfelix.com
Date:   Wed Aug 14 19:02:33 2013 -0400

Increase MAX_CONNECTIONS to 100

This is an interim fix for Debian 719659.

diff --git a/connection_list.c b/connection_list.c
index 0fc7c53..cf99162 100644
--- a/connection_list.c
+++ b/connection_list.c
@@ -35,7 +35,7 @@
 /*---*/
 /* private objects */

-#define MAX_CONNECTIONS 20
+#define MAX_CONNECTIONS 100

 static struct connection connection_list[MAX_CONNECTIONS];


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

Bug#719659: Full fix available

[Ted Felix]

  The full fix for this is now available in the git repo on sourceforge.

http://sourceforge.net/projects/acpid2/

  It now expands the connection list in increments of 20 connections as 
needed up to 1024.  add_connection() also has better error handling, so 
problems in there will now be logged.


  Any testing anyone can do would be appreciated.

  Unless the Debian folks need it sooner, I think I will shoot for the 
usual September 15 release date for this.  Let me know what you would 
prefer.



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

Bug#717120: cscope: 64-bit build reports no matches for some symbols the 32-bit build finds.

[Ted Anderson]

Package: cscope
Version: 15.7a
Severity: normal

I recently moved from Ubuntu Lucid 10.04.4 LTS (i386) to Debian Wheezy (amd64).
I have used cscope for years and depend upon it for helping navigate a large
C++ code base.  I recently found that the version of cscope that comes with
Wheezy for the amd64 architecture cannot find some symbols that surely exist.
Specifically, a symbol whose name is syncFsEverywhere.

Experimentation showed that searching for .yncFsEverywhere and
[s]yncFsEverywhere  .*cFsEverywhere produced the expected matches, but
syncEveryw.* produced no results.

Using the binary from my old Lucid installation, I was able to remove and
rebuild the cscope database and it was able to locate 11 instances of this
symbol.  Next I tried uninstalling Wheezy's 64-bit version and replacing it
with the i386 package.  This was also able to find the symbols.  Then I
installed the Wheezy cscope source package using apt and built the 64-bit
binary myself.  This version worked the same as the repository's 64-bit
version: no results.  Finally, I downloaded the 15.8a release from SourceForge
(http://sourceforge.net/projects/cscope/files/cscope/15.8a/) and built it.
That version works fine compiled for the amd64 architecture, producing the
expected 11 results.

I reviewed the change log between the Debian version 15.7a and the SourceForge
version 15.8a and didn't see anything obvious to explain the change.  Perhaps
just upgrading Wheezy to the latest upstream version would be the best
approach.  I notice that Debian bug #689198 also suggests this.



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

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 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 cscope depends on:
pn  ed   none
ii  libc62.13-38
ii  libncurses5  5.9-10
ii  libtinfo55.9-10

cscope recommends no packages.

Versions of packages cscope suggests:
pn  cscope-el  none


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

Bug#701234: Elevation to serious - acpid 2.0.19

[Ted Felix]

  I just released acpid 2.0.19 in response to the elevation to 
serious severity.  It should fix the compilation issue.


Ted.


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

Bug#706593: Fwd: [Pkg-utopia-maintainers] Bug#706593: network-manager: Don't know how to create 'NMSettingVPN' connections

[Ted Percival]

On Thu, May 2, 2013 at 8:04 AM, Michael Biebl bi...@debian.org wrote:
 It seems you don't have any of the VPN plugins installed.
 If you want to create new connections from within the GUI you will need
 them. Please install them and report back.

After installing network-manager-pptp-gnome the UI works fine.

Maybe if it gives a hint like Check that an appropriate VPN package
is installed I can figure it out myself next time :-)

Thanks!


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

Bug#706593: network-manager: Don't know how to create 'NMSettingVPN' connections

[Ted Percival]

Package: network-manager
Version: 0.9.8.0-1
Severity: normal

I installed network-manager from experimental. When I try to create a
VPN from the GNOME GUI I get an error saying
Error creating connection
Don't know how to create 'NMSettingVPN' connections

I guess the dependencies below show that the libnm-glib-vpn1
dependency is not strict enough and allowed me to get mismatched
components (0.9.4  0.9.8).


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

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

Versions of packages network-manager-gnome depends on:
ii  dbus-x11 1.6.8-1
ii  dconf-gsettings-backend [gsettings-backend]  0.12.1-3
ii  dpkg 1.16.10
ii  gconf-service3.2.5-1+build1
ii  gnome-icon-theme 3.4.0-2
ii  libatk1.0-0  2.4.0-2
ii  libc62.13-38
ii  libcairo-gobject21.12.2-3
ii  libcairo21.12.2-3
ii  libdbus-1-3  1.6.8-1
ii  libdbus-glib-1-2 0.100.2-1
ii  libgconf-2-4 3.2.5-1+build1
ii  libgdk-pixbuf2.0-0   2.26.1-1
ii  libglib2.0-0 2.33.12+really2.32.4-5
ii  libgnome-bluetooth10 3.4.2-1
ii  libgnome-keyring03.4.1-1
ii  libgtk-3-0   3.4.2-6
ii  libnm-glib-vpn1  0.9.4.0-10
ii  libnm-glib4  0.9.8.0-2
ii  libnm-gtk0   0.9.8.0-1
ii  libnm-util2  0.9.8.0-2
ii  libnotify4   0.7.5-1
ii  libpango1.0-01.30.0-1
ii  network-manager  0.9.8.0-2
ii  policykit-1-gnome0.105-2

Versions of packages network-manager-gnome recommends:
ii  gnome-bluetooth 3.4.2-1
ii  gnome-keyring   3.4.1-5
ii  iso-codes   3.41-1
ii  mobile-broadband-provider-info  20130312-1
ii  notification-daemon 0.7.6-1

Versions of packages network-manager-gnome suggests:
pn  network-manager-openconnect-gnome  none
pn  network-manager-openvpn-gnome  none
pn  network-manager-pptp-gnome none
pn  network-manager-vpnc-gnome none

-- no debconf information


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

Bug#706593: Dependencies are not the problem

[Ted Percival]

I tried upgrading libnm-glib-vpn1 to version 0.9.8.0-2 to match but
that did not solve the problem.


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

Bug#701206: acpid: Mic mute button on Thinkpad X230 is not recognized

[Ted Felix]

On 04/24/2013 04:21 AM, Marek Elias wrote:

Input Layer:  Type: 1  Code: 28  Value: 0


  That's the Enter key.  Nothing to worry about.


Input Layer:  Type: 1  Code: 248  Value: 1


  This is KEY_MICMUTE.  That can easily be added to acpid by adding 
the following lines to input_layer.c:


   {{{0,0}, EV_KEY, KEY_MICMUTE, 1},
  button/micmute MICMUTE 0080 },

  Add them to the /*** AUDIO ***/ section.  Rebuild and try it. 
acpid should receive mic mute events.  This doesn't mean it will do 
anything with them.  You'll need to add a config file and a script to 
make something useful happen.  See the man page.


  If this works and you find this helpful, let me know and I'll include 
this change in the next release.


  If you just wanted the mic mute button to work in your window manager 
(e.g. Gnome or KDE), then it's best to get them to support these 
keys/buttons.  acpid is geared more towards those who are not running a 
window manager (servers).  You can still use it for this, but it's not 
really the best solution.


 The led inside mic mute button also does not switch on/off. This works
 fine for normal mute button.

  Your script for acpid will need to turn the light on and off.  Most 
likely, your window manager is doing this already for the mute button, 
but it is not aware of the mic mute button and the LED.


Ted.


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

Bug#701206: acpid: Mic mute button on Thinkpad X230 is not recognized

[Ted Felix]

On 04/24/2013 10:19 AM, Marek Elias wrote:

I did the changed you suggested and rebuilt the acpid package.
Now I can see the events and run scripts with it.


  Great.  Then I'll go ahead and add the lines to the official source. 
 It will appear in the next version.  Since there haven't been any 
major changes lately, that might be a while off.


Ted.


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

Bug#701206: acpid: Mic mute button on Thinkpad X230 is not recognized

[Ted Felix]

On 04/24/2013 10:19 AM, Marek Elias wrote:

I did the changed you suggested and rebuilt the acpid package.
Now I can see the events and run scripts with it.


  I just added this change to the official source.  If you wouldn't 
mind retesting with the official source, I'd appreciate it.  You can 
find the sf git repo here:


http://sourceforge.net/p/acpid2/code/ci/master/tree/

  Let me know if it works.  Thanks.

Ted.


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

Bug#701206: acpid: Mic mute button on Thinkpad X230 is not recognized

[Ted Felix]

On 02/22/2013 10:00 PM, Yevgeny Kosarzhevsky wrote:

when I run acpi_listen and press MicMute button I get only ^@ output, no codes 
recognized.


  What does kacpimon report for that button?  You'll need to kill acpid 
for kacpimon to work.  Check the man page for more.


Ted.


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

Bug#697606: linux-image-3.2.0-4-powerpc: Suspend on iBook G3 (A1007) no longer works

[Ted To]

Package: src:linux
Version: 3.2.35-2
Severity: important

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

   * What led up to the situation?
upgraded kernel linux-image-3.2.0-4 from prior version of 3.2.0-4
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
suspend no longer works
   * What outcome did you expect instead?
suspend would continue to work

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



-- Package-specific info:
** Version:
Linux version 3.2.0-4-powerpc (debian-ker...@lists.debian.org) (gcc 
version 4.6.3 (Debian 4.6.3-8) ) #1 Debian 3.2.35-2


** Command line:
root=UUID=362cffcd-65ce-4dba-b9ae-00fa2847ef6a ro radeon.modeset=0

** Not tainted

** Kernel log:
[   12.464617] airport: Physical address 8003
[   12.958781] usb 2-1: reset full-speed USB device number 2 using 
ohci_hcd
[   13.669456] airport 0.0003:radio: Hardware identity 
0005:0001:0001:0002
[   13.677439] airport 0.0003:radio: Station identity  
001f:0001:0008:0046
[   13.685122] airport 0.0003:radio: Firmware determined as 
Lucent/Agere 8.70
[   13.721713] ieee80211 phy1: Selected rate control algorithm 
'minstrel_ht'

[   13.724648] Registered led device: rt73usb-phy1::radio
[   13.724818] Registered led device: rt73usb-phy1::assoc
[   13.724986] Registered led device: rt73usb-phy1::quality
[   13.727889] usbcore: registered new interface driver rt73usb
[   13.838225] airport 0.0003:radio: firmware: agent loaded 
agere_sta_fw.bin into memory
[   13.931290] airport 0.0003:radio: Hardware identity 
0005:0001:0001:0002
[   13.939376] airport 0.0003:radio: Station identity  
001f:0002:0009:0030
[   13.947252] airport 0.0003:radio: Firmware determined as 
Lucent/Agere 9.48

[   13.955115] airport 0.0003:radio: Ad-hoc demo mode supported
[   13.962923] airport 0.0003:radio: IEEE standard IBSS ad-hoc mode 
supported

[   13.970745] airport 0.0003:radio: WEP supported, 104-bit key
[   13.978482] airport 0.0003:radio: WPA-PSK supported
[   16.051350] Adding 741204k swap on /dev/sda4.  Priority:-1 extents:1 
across:741204k

[   16.099207] EXT4-fs (sda3): re-mounted. Opts: (null)
[   16.711972] EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro
[   17.412409] loop: module loaded
[   18.314991] i2c i2c-0: PMac Keywest Audio: attach_adapter method is 
deprecated
[   18.322788] i2c i2c-0: Please use another way to instantiate your 
i2c_client
[   18.330336] i2c i2c-1: PMac Keywest Audio: attach_adapter method is 
deprecated
[   18.337932] i2c i2c-1: Please use another way to instantiate your 
i2c_client
[   18.345564] i2c i2c-2: PMac Keywest Audio: attach_adapter method is 
deprecated
[   18.353253] i2c i2c-2: Please use another way to instantiate your 
i2c_client
[   18.360961] i2c i2c-3: PMac Keywest Audio: attach_adapter method is 
deprecated
[   18.368599] i2c i2c-3: Please use another way to instantiate your 
i2c_client
[   18.376146] i2c i2c-4: PMac Keywest Audio: attach_adapter method is 
deprecated
[   18.383742] i2c i2c-4: Please use another way to instantiate your 
i2c_client
[   18.391160] i2c i2c-5: PMac Keywest Audio: attach_adapter method is 
deprecated
[   18.398419] i2c i2c-5: Please use another way to instantiate your 
i2c_client
[   18.405689] i2c i2c-6: PMac Keywest Audio: attach_adapter method is 
deprecated
[   18.413001] i2c i2c-6: Please use another way to instantiate your 
i2c_client
[   18.528561] i2c i2c-7: PMac Keywest Audio: attach_adapter method is 
deprecated
[   18.536332] i2c i2c-7: Please use another way to instantiate your 
i2c_client
[   18.543983] i2c i2c-8: PMac Keywest Audio: attach_adapter method is 
deprecated
[   18.551785] i2c i2c-8: Please use another way to instantiate your 
i2c_client
[   18.620588] input: PowerMac Beep as 
/devices/pci0001:10/0001:10:17.0/input/input4
[   21.273996] EXT4-fs (sda5): mounted filesystem with ordered data 
mode. Opts: (null)
[   21.895503] input: Macintosh mouse button emulation as 
/devices/virtual/input/input5

[   27.303548] lp: driver loaded but no devices found
[   29.260855] ondemand governor failed, too long transition latency of 
HW, fallback to performance governor

[   31.765589] ADDRCONF(NETDEV_UP): eth1: link is not ready
[   31.951285] eth1: New link status: Connected (0001)
[   31.959010] rt73usb 2-1:1.0: firmware: agent loaded rt73.bin into 
memory

[   32.472706] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   32.474791] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[   32.498305] ADDRCONF(NETDEV_UP): eth1: link is not ready
[   32.595082] sungem_phy: PHY ID: 4061e4, addr: 0
[   32.595445] gem 0002:20:0f.0: eth0: Found BCM5221 PHY
[   32.598451] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   35.471545] radeonfb :00:10.0: Invalid ROM contents
[   35.471869] radeonfb :00:10.0: Invalid ROM contents
[   35.601156] [drm] Initialized drm 1.1.0 20060810
[   35.831062] [drm] 

Bug#697606: linux-image-3.2.0-4-powerpc: Suspend on iBook G3 (A1007) no longer works

[Ted To]

On 01/07/2013 10:27 am, Ben Hutchings wrote:

Control: tag -1 moreinfo

On Mon, 2013-01-07 at 09:50 -0500, Ted To wrote:

Package: src:linux
Version: 3.2.35-2
Severity: important

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

* What led up to the situation?
upgraded kernel linux-image-3.2.0-4 from prior version of 3.2.0-4
* What exactly did you do (or not do) that was effective (or
  ineffective)?
* What was the outcome of this action?
suspend no longer works
* What outcome did you expect instead?
suspend would continue to work


How does it not work?  Does the computer hang, wake up immediately, 
or

reboot when woken?


The computer suspends when the lid is shut (this is independent of 
software) but when I open the lid, it hangs.  The USB wireless adapter 
wakes up but nothing can be done but a hard shutdown.


Ted


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

Bug#557103: uw-imapd occasionally corrupts /var/spool/mail/[user] and ~/mbox

[Ted Mittelstaedt]

We see the same issue (first line corrupted)  We have tried mlock.  It 
creates lock files in /tmp just fine, and fuser indicates the 
/var/mail/username file is locked but the bug persists.


Did anyone try the suggested change?

Ted


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

Bug#682074: texmaker: Restore session does not work after fresh boot

[Ted To]

Package: texmaker
Version: 3.3.4-1
Severity: important

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

   * What led up to the situation?
Attempt to restore session
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
change default /tmp from ram to HD space and to keep files following a boot
   * What was the outcome of this action?
Session restore worked
   * What outcome did you expect instead?


I have reported a bug to the developer but he does not seem inclined to change
the location of restore session data from /tmp to something like ~/.config/xm1
(see https://code.google.com/p/texmaker/issues/detail?id=686). Perhaps for the
debian package, it can be patched.
*** End of the template - remove these lines ***



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

Kernel: Linux 3.2.0-3-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/dash

Versions of packages texmaker depends on:
ii  libc6 2.13-33
ii  libgcc1   1:4.7.1-2
ii  libpoppler-qt4-3  0.18.4-3
ii  libqt4-network4:4.8.2-1
ii  libqt4-xml4:4.8.2-1
ii  libqtcore44:4.8.2-1
ii  libqtgui4 4:4.8.2-1
ii  libqtwebkit4  2.2.1-4+b1
ii  libstdc++64.7.1-2
ii  texmaker-data 3.3.4-1
ii  zlib1g1:1.2.7.dfsg-13

Versions of packages texmaker recommends:
ii  aspell  0.60.7~20110707-1
pn  asymptote   none
ii  ghostscript 9.05~dfsg-6
pn  ibus-qt4none
ii  myspell-en-us [myspell-dictionary]  1:3.3.0-3
pn  netpbm  none
pn  psutils none
ii  texlive-latex-extra 2012.20120611-1

texmaker suggests no packages.

-- no debconf information


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

Bug#681820: e2fsprogs: Problems in German translation

[Ted Ts'o]

On Mon, Jul 16, 2012 at 10:02:42PM +0200, Helge Kreutzmann wrote:
 
 By chance I saw a slight error in the German output e2fsprogs
 programms. I grabed the latest de.po and startet reviewing it;
 unfortunately it is quite huge and I only managed to to about 1/3 up
 to now.
 
 I found various issues, from spelling errors, inconsistent
 translations to (unfortunately) mistranslations. Due to the latter I
 like to explore if there are chances to do an upload despite the
 freeze and ask for a freeze exception.
 
 If the answer is yes (and ideally the upstream maintainer is
 repsonsive) then I could try to review a few more strings for the
 targeted upload date.

Helge,

Many thanks for your effort!  In my experience Philipp is very
responsive as the upstream Translation Project translator for
e2fsprogs.  Ideally, if agrees with your updates, he could upload a
fixed de.po for e2fsprogs to the Translation project, and I would be
very happy to get it into an updated e2fsprogs upload for Debian.  We
would have to reques a freeze exception, but if the only change is
translation and man page typo's, I'm pretty sure it wouldn't cause any
issues, since it wouldn't effect the udeb's used by the d-i team.

Regards,

- Ted


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

Bug#678955: ntp: Update default ntp.conf

[Ted To]

Package: ntp
Version: 1:4.2.6.p5+dfsg-2
Severity: minor

Dear Maintainer,

/etc/ntp.conf should be updated to reflect 1) consolidate redundant
configuration lines and 2) add 'limited to the restrict directive in order to
make kod effective.  See
http://lists.ntp.org/pipermail/pool/2012-June/005872.html

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

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

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



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

Kernel: Linux 3.2.0-2-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/dash

Versions of packages ntp depends on:
ii  adduser  3.113+nmu3
ii  dpkg 1.16.3
ii  libc62.13-33
ii  libcap2  1:2.22-1
ii  libedit2 2.11-20080614-5
ii  libopts251:5.12-0.1
ii  libssl1.0.0  1.0.1c-3
ii  lsb-base 4.1+Debian6
ii  netbase  5.0

Versions of packages ntp recommends:
ii  perl  5.14.2-11

Versions of packages ntp suggests:
pn  ntp-doc  none

-- no debconf information



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

Bug#678388: upgrade of wine fails and then wine64-bin's instructions do not work

[Ted To]

Package: wine64-bin
Version: 1.4.1-1
Severity: grave
Justification: renders package unusable

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

   * What led up to the situation?
upgrade to wine available
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
attempted to upgrade
upgrade failed because /usr/bin/wine existed
uninstalled previous version of wine
installed new version of wine
followed instructions: failed at 'apt-get install wine-bin:i386', even manually
installing each dependency.
   * What was the outcome of this action?
do not have wine working on my system
   * What outcome did you expect instead?
new, shiny wine on my system



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

Kernel: Linux 3.2.0-2-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/dash

-- no debconf information



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

Bug#677624: multiarch-support should be priority: required

[Ted Ts'o]

Package: multiarch-support
Version: 2.13-33

Forwarding per Russ's observation that multiple required library
packages are depending on multiarch-support, which causes Lintian to
complain.

Given that it is a transitional package, this shouldn't be a big deal,
since it's less than 200k installed (and all of that package
documentation overhead)

Thanks,

- Ted
---BeginMessage---
Theodore Ts'o ty...@mit.edu writes:

 If a required package (such as e2fslibs, which is required by e2fsprogs)
 provides multiarch support, then Lintian requires that the package have
 a dependency on the package multiarch-support[1].

 However, this causes debcheck to complain because you now have a
 required package depending on a package, multiarch-support, which is
 only at standard priority[2] 

 [1] 
 http://lintian.debian.org/tags/missing-pre-dependency-on-multiarch-support.html
 [2] http://qa.debian.org/debcheck.php?dist=unstablepackage=e2fsprogs

 What is the right thing to do to resolve this mutually irreconcilable
 set of complaints from either Lintian or debcheck?

multiarch-support should be priority: required.  It's already a dependency
of several other priority: required packages, such as libselinux1 and
zlib1g.

That implies that in the interim you should ignore debcheck.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aa05kxv0@windlord.stanford.edu


---End Message---

Bug#674453: e2fsck(8): Unnecessary escape of tabs in the manual

[Ted Ts'o]

tags 674453 +pending
thanks

Patch applied, thanks.

- Ted



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

Bug#674694: resize2fs(8): Unnecessary escape before a tab in the manual

[Ted Ts'o]

tags 674694 +pending
thanks

Patch applied, except that 1 k and 2 k blocksize looks horrible; I
much prefer 1k and 2k blocksize.  So I reverted that part of the
patch.

It may be the preferred style for SI units, but these are the same
jokers who suggest the use of ridiculous terms like tibibytes (a
term I reject, since while they may get to define what a metre is,
they don't have the authority or responsibility to define what a
byte means --- and if they did, they'd probably insist on ten bits
in a byte :-).

In any case, in the computer world we very regularly do *not* put a
space between the number and units: i.e., 640k memory.

Best regards,

- Ted



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

Bug#670100: e2fsprogs: Please don't use blocksize of 1024 in usage-type 'small'

[Ted Ts'o]

On Mon, Apr 23, 2012 at 03:22:52PM +0300, Touko Korpela wrote:
  Finally, the only file system where someone is likely to be creating
  that is this small in this day and age is the /boot filesystem --- and
  there, even if the drive using 512-byte emulation, performance isn't
  an issue since no one is executing out of /boot, or even modifying it
  very often.
 
 Yes, /boot is my primary worry.

Yes, and the performance hit only really happens when you need to do a
read-modify-write cycle.  And /boot doesn't get modified very often
--- only when you update a kernel, and even when you do, it's mostly
large files which will generally be contiguous.  So the performance
hit is barely measurable.

 A thing to consider is that dumb SSDs and
 USB sticks/memory cards are more common than smart SSDs.

(a) dumb SSD's still had to work well on Windows XP, and hardware
designs are conservative, so it's not clear to me this is really a
huge issue.  And (b) USB sticks/memory cards are again primarily used
for file interchange, where performance is not a big thing.  (It's
really random 4k writes where the read-modify-write cycles really
hurt.  For big files, we where we issue a large contiguous write
transaction, you only do the read-modify-write cycle for the first and
last 4k block and that's not a big deal.

 And maybe some wants to resize such small filesystem bigger but resizing
 can't change blocksize larger.

... and how often do you start with a file system *that* small?

 Still I think that at least filesystems that are larger than about 50-100MB
 in size default blocksize should be 4096.

You're certainly entitled to your opinion.  One of the reasons why
this policy is not hard coded, but can be easily modified via
/etc/mke2fs.conf is so that sysadmins can make changes for what is
most appropriate for their systems.

Regards,

- Ted




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

Bug#670100: e2fsprogs: Please don't use blocksize of 1024 in usage-type 'small'

[Ted Ts'o]

On Mon, Apr 23, 2012 at 06:51:28PM +0300, Touko Korpela wrote:
 USB sticks and other flash media are optimised for FAT (using big blocks).
 Most of my information comes from LWN article Optimizing Linux with cheap
 flash drives https://lwn.net/Articles/428584/
 I don't know if linear reads during boot are affected but other usage is
 much slower when reads/writes aren't aligned.
 Fdisk has already fixed its default partition layout.

Read that article more closely.  Flash page sizes are well beyond 4k;
with modern flash they are 32k and 64k.  Hence, any read *smaller*
than the page size (32k or 64k) will take the same amount of time as a
page read.  It's not going matter whether it is 512-byte aligned or 4k
aligned.  And if you do a nice big contiguous read (i.e., reading in a
4MB kernel image), it might make a small amount of difference, but
only at the beginning and the end of the file, which might result in a
performance hit of just under 0.2% --- i.e., reading in a 4MB kernel,
which might take 1.100 millseconds, might end up taking 1.102
millseconds instead.  Good luck measuring that.

For writes, to get optimal speeds, you need to be doing 4MB aligned
writes.  Will there be a difference between 512 byte and 4k random
writes?  It depends on the SSD.  For good SSD's it won't matter at
all.  For bad ones, there may be some difference, but the big
breakpoint happens with 4MB writes (or whatever the erase block size
happens to be --- for newer devices, they might be 8MB at this point).

And again, for /boot, it's really not going to matter.  Heck, on my
systems /boot is generally well larger than 512MB anyway (but that's
because I'm a kernel developer :-).

- Ted



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

Bug#670100: e2fsprogs: Please don't use blocksize of 1024 in usage-type 'small'

[Ted Ts'o]

On Mon, Apr 23, 2012 at 01:17:34AM +0300, Touko Korpela wrote:
 Package: e2fsprogs
 Version: 1.42.2-2
 Severity: normal
 
 I noticed that mke2fs has a default blocksize of 1024 bytes when it uses
 filesystem type 'small' (3-512MB) from mke2fs.conf.
 It's a bad thing for performance (more so now when 4K sector HDDs and SDDs
 are common). Also space savings are quite small.

You can always override the blocksize if you feel strongly about this.

The performance problem is only true on very new disks --- and it's
rare that someone would be formatted a file system so small on such
disks.  I'll also note that many SDD's can handle 512 byte mis-aligned
blocks (i.e., Windows XP formatting) just fine.  It doesn't make any
difference at all on Intel SSD's, for example.

Secondly, mke2fs will use 4k blocks if the drive requires it (i.e.,
for Advanced Format disks with 4k sectors).  So the problem you're
worried about only occurs for Advanced Format drives with 512e
emulation.

Finally, the only file system where someone is likely to be creating
that is this small in this day and age is the /boot filesystem --- and
there, even if the drive using 512-byte emulation, performance isn't
an issue since no one is executing out of /boot, or even modifying it
very often.

- Ted



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

Bug#669730: e2fsprogs: Bigalloc is not documented

[Ted Ts'o]

Hi Touko,

Note that bigalloc is still somewhat under development; there are
number of bugs that are still in the kernel code, so at this point I
can't really recommend non-developers use it in production yet...

(Some of the bugs weren't evident at the time of the 1.42 release, or
I would have added more cautions in the e2fsprogs release notes.)

 - Ted



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

Bug#642227: WARNING: SegmentNotationHelper::makeNoteViable(): No valid split for event

[Ted Felix]

  Thanks for the bug report.

  r12743 (Jan 8, 2012) of rosegarden fixes a similar bug.  If you can 
attach a sample MIDI file that causes the problem, I can test it against 
the latest source.


Ted.



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

Bug#666460: define 'check' clearer

[Ted Ts'o]

On Mon, Apr 02, 2012 at 06:34:39AM +0800, jida...@jidanni.org wrote:
 My main motivation is that for years uses see
 checking messages at boot.
 
 On a dentist's bill at least checking is separate from treating.
 
 So somehow the user should be more informed about what is going on.
 
 Else he wonders if all that Windows defragmentation is somehow
 unnecessary on Linux, and for years his disks have passed with flying
 colors... When if fact the dentist is doing more than just looking.

This is no different from Windows when it runs the CHKDSK program; it
says that it's checking the disk, but it's really checking and
repairing it.  And none of this has anything to do with
defragmentation; it has to do with dealing with potentially corrupted
file systems after hardware failures/hiccups --- or if a USB thumb
drive is forcibly removed in the middle of a write operation, and the
flash translation's metadata is corrupted.

 I really have no idea.
 
 I just wish
 =Checking... done===
 messages were more honest.
 
 I just don't like my dentist to say he only checked when he in fact
 plans to check and maybe alter.

This message has nothing to do with the fsck man page or the
util-linux package. that's really a matter of the system startup
scripts.  But I'll note that the term checking has a very long
history, going back decandes for Linux, Unix, as well as in MS-DOS /
Windows --- so it's not even Linux / Unix.

   - Ted



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

Bug#666460: define 'check' clearer

[Ted Ts'o]

On Sat, Mar 31, 2012 at 06:39:35AM +0800, jida...@jidanni.org wrote:
 Package: util-linux
 Version: 2.20.1-4
 Severity: wishlist
 File: /usr/share/man/man8/fsck.8.gz
 X-debbugs-cc: ty...@mit.edu
 
 The man page should say by 'check' we mean that nothing will be altered
 on the disk except updating the mount tally. Anything more invasive we
 call 'repair'. Or something like that. It is not clear. One just guesses.

The man page currently says:

Fsck is used to check and optionally repair one or more Linux file
systems

That's not technically correct since in actual practice is fsck with
no options will repair the file system.  This becomes clear if you
read the definitions of the -y, -n, and -a/-p options.

So probably the best thing to do is delete the word optionally in
the above statement.

- Ted





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

Bug#666725: secure passwords more predictable than expected

[Ted Ts'o]

severity 666725 normal
thanks

On Sun, Apr 01, 2012 at 12:50:58PM +0200, Thomas Arendsen Hein wrote:
 
 When using pwgen -s 1 50 to generate 50 one-char passwords,
 only lowercase letters are used.
 
 When using pwgen -s 2 50 to generate 50 two-char passwords,
 exactly one lowercase letter and one number is used.
 
 Three-char and longer passwords are not affected by this major
 security issue.

Thanks for reporting this, and I agree it's a bug, but if you're using
one or two letter passwords (or heck, anything under 5 characters),
you're totally insecure anyway.  Whether someone has to brute force 26
possible passwords versus 62 possible passwords is not a major
security issue.  :-)

- Ted



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

Bug#666460: define 'check' clearer

[Ted Ts'o]

One of the reasons why the fsck page is a little vague is that it's a
front end progam which executes a file system specific checker
program.  These programs are not necessarily consistent in how they
operate.  The way e2fsck, which is the file system checker used for
ext2, ext3, and ext4 (and so /sbin/fsck.ext2, /sbin/fsck.ext3, and
/sbin/fsck.ext4, are either sym links or hard links to /sbin/e2fsck)
works is that without any options, it is interactive; it will require
access to a tty, and before it actually makes any changes, it will
*ask* the user whether it wants to correct a particular file system
corruption if it comes a cross scuh a corruption.

The options -n, and -y will make e2fsck automatically answer no, or
yes to questions, so it can be used non-interactively --- i.e., it
doesn't need access to a valid tty for input, which is the case for
boot scripts.

The -p/-a option for e2fsck is called preen mode, which will answer
yes automatically for safe questions, and will exit with an error,
causing the boot script to abort the boot, for dangerous questions
that requires a system administrator's personal attention to minimize
the chances of data loss.

Other file system consistency checkers are sometimes a little
different, although most of them handle the -y, -n, and -a/-p as
described in the fsck man page since that's what the boot scripts use.

 - Ted



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

Bug#663752: Fixed in glibc

[Ted Percival]

tags fixed-upstream upstream
thanks

This bug is fixed in glibc. Here are the patches:

Patch 1: 
http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=c0244a9dedce43a4b950d91451b16a7cf5408476;hp=c5e3c2ae59cc8c5d3ad5e1adfd099c726baad862
Patch 2: 
http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=e12df166d37522c2ed434c2d70a1b04640d2d7c6;hp=84e2a551a72c79b020694bb327e33b6d71b09b63

Thread leading to these changes:
http://cygwin.com/ml/libc-hacker/2011-06/msg2.html



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

Bug#665885: e2fsprogs: libcomerr2.shlibs should point at e2fsprogs-udeb for udebs

[Ted Ts'o]

tags 665885 +pending
thanks

On Tue, Mar 27, 2012 at 06:41:42PM +0200, Julien Cristau wrote:
  Is this what you are looking for?
  
  % more debian/libcomerr2/DEBIAN/shlibs 
  libcom_err 2 libcomerr2 (= 1.33-3)
  udeb: libcom_err 2 e2fsprogs-udeb (= 1.33-3)

 Yep, that looks like what I'd expect.  Thanks.

Great, just checking since I wasn't familiar with that udeb-specific
syntax in the shlibs file.

I've applied the following patch that will be in the e2fsprogs 1.42.2
release.

- Ted

commit 38c5e731157116b7cd350e2e3c05e64340307a2c
Author: Theodore Ts'o ty...@mit.edu
Date:   Tue Mar 27 11:48:18 2012 -0700

debian: add pointer to e2fsprogs-udeb to libcomerr2.shlibs

The udeb for btrfs-tools need libcom_err.so.2, which is packaged as a
part of e2fsprogs-udeb since we don't have a separate libcomerr2 udeb.
So we need to make sure the shlibs file has an explicit pointer to
handle this case.

Addresses-Debian-Bug: #665885

Signed-off-by: Theodore Ts'o ty...@mit.edu

diff --git a/debian/rules b/debian/rules
index 82a1576..1f6e7b4 100755
--- a/debian/rules
+++ b/debian/rules
@@ -618,7 +618,7 @@ endif
dh_compress
 
dh_makeshlibs -Ne2fsprogs-udeb -Nlibblkid1-udeb -Nlibuuid1-udeb
-   dh_makeshlibs -plibcomerr${COMERR_SOVERSION} \
+   dh_makeshlibs --add-udeb=e2fsprogs-udeb -plibcomerr${COMERR_SOVERSION} \
-V 'libcomerr2 (= 1.33-3)'
 ifneq ($(UTIL_LINUX_NG),yes)
dh_makeshlibs -plibblkid${BLKID_SOVERSION} -V 'libblkid1 (= 1.39-1)'



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

Bug#665427: Fix roff syntax and typo in mke2fs.conf.5 and tune2fs.8

[Ted Ts'o]

tags 665427 +pending
thanks

On Fri, Mar 23, 2012 at 10:27:11PM -0400, David Prévot wrote:
 
 We noticed some tiny errors in the mke2fs.conf.5 and tune2fs.8 manpages
 while translating them in French (for the manpages-fr-extra package),
 please find attach a patch to address these issues.

Thanks, applied.

 BTW, we would be pleased if you could consider shipping the translated
 manpages directly in your package, or even better, help us to integrate
 them upstream.

The major concern that I have with including the translated manpages
is the synchronization problem that this implies.  By definition the
translated man pages will always be out of sync, whenever I make
change; I can forsee this leading to endless bug reports, for which I
am not really able to act upon.  Also, how do the man pages get
updated?  Do I have to ask?  Will someone be checking the e2fsprogs
git repository on a regular basis to find man page changes?

It just seems that including translated man pages is a support
nightmare.

The other question I have is if I include the French man pages in the
e2fsprogs package, then what if I start having to include German,
Spanish, Polish, Turkish, etc.  Wouldn't this massively bloat the
e2fsprogs package?  And if I have to create an e2fsprogs-fr-manpages,
and a e2fsrpogs-es-manpages, etc., again this start looking like a
huge amount of work just to give me more bug reports that I'm not
capable of handling (since I don't speak French.)

Regards,

- Ted



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

Bug#665885: e2fsprogs: libcomerr2.shlibs should point at e2fsprogs-udeb for udebs

[Ted Ts'o]

On Mon, Mar 26, 2012 at 09:53:56PM +0200, Julien Cristau wrote:
 Package: e2fsprogs
 Version: 1.42.1-2
 Severity: important
 Tags: d-i
 
 (x-debbugs-cc to debian-boot and the btrfs-tools maintainer)
 
 btrfs-tools-udeb's btrfsctl and mkfs.btrfs seem to be linked against
 libcom_err.so.2, and the package ends up with a dependency on
 libcomerr2, which isn't an udeb.  Since libcom_err seems to be included
 in e2fsprogs-udeb, I guess this means the shlibs file should be adjusted
 to point there.  See the --add-udeb option to dh_makeshlibs.

Is this what you are looking for?

% more debian/libcomerr2/DEBIAN/shlibs 
libcom_err 2 libcomerr2 (= 1.33-3)
udeb: libcom_err 2 e2fsprogs-udeb (= 1.33-3)

- Ted



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