Bug#1064329: Micro stuttering when using a DisplayPort. Issue is not present when using HDMI

2024-02-19 Thread Shawn Horvatic
Package: Gnome
Version: 43.9
XOrg or Wayland: Wayland

*OS Information*

OS: Debian GNU/Linux
Version: 12.2.0-14
Kernel: Linux version 6.1.0-18-amd64 (debian-ker...@lists.debian.org)
(gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40)
#1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01)
Bug summary

When on Discord, Youtube, or any activity while using a DisplayPort as
primary output Gnome will micro-stutter. When a micro stutter occurs the
whole system will replay sounds, video, etc of the previous few frames. For
example Youtube will double play the same note during a micro stutter, or
if someone is speaking in discord their last word will repeat twice. I
tested this with HDMI, and none of these issues occurred.
Steps
to reproduce

   1. Plugin a DisplayPort Cable. This can be integrated, or video card
   2. Fresh install of Debian, selecting the Gnome desktop when installing
   3. In firefox or chrome play a youtube video, as it easy to see the
   stutter
   4. Micro stutter should occur within 5 - 15 mins. The video will repeat
   the last frames / sound


*Suggestions *
Upgrade Gnome to a version that can support Displayport

*Notes / Other Useful Info:*
- Ticket already made with Gnome:
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7422
Gnome closed the ticket as Debian uses an unsupported version of Gnome

- KDE has a similar issue, but I have not tested it with HDMI to see if
that fixes the issue


Bug#1061429: tomboy-ng: Copy and paste to/from tomboy-ng does not work under (at least) GNOME

2024-01-24 Thread Shawn K. Quinn
Package: tomboy-ng
Version: 0.39-1
Severity: important
X-Debbugs-Cc: skqu...@rushpost.com

Dear Maintainer,

I am unable to copy and paste reliably to and from tomboy-ng to other GUI apps
while running GNOME. The X paste buffer (middle mouse button/wheel click) does
work, but normal Control-C/Control-V copy and paste do not.

I am at a loss as to how to further isolate the issue.


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

Kernel: Linux 6.5.0-5-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 tomboy-ng depends on:
hi  libc62.36-9+deb12u3
ii  libcairo21.18.0-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3
ii  libglib2.0-0 2.78.3-1
ii  libnotify-bin0.8.3-1
ii  libnotify4   0.8.3-1
ii  libpango-1.0-0   1.51.0+ds-4
ii  libpangocairo-1.0-0  1.51.0+ds-4
ii  libqt5pas1   3.0+dfsg1-1
ii  libx11-6 2:1.8.7-1
ii  wmctrl   1.07-7+b1

tomboy-ng recommends no packages.

Versions of packages tomboy-ng suggests:
ii  libayatana-appindicator3-1  0.5.93-1

-- no debconf information



Bug#1061281: gajim: Fails to start: AttributeError: module 'eventlet.green.select' has no attribute 'epoll'

2024-01-21 Thread Shawn K. Quinn
Package: gajim
Version: 1.8.4-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: skqu...@rushpost.com

Dear Maintainer,

At some point within the last few days, I am suddenly unable to launch gajim.
This is the console output I am receiving:

skquinn@crossbow:~$ gajim
Traceback (most recent call last):
  File "/usr/bin/gajim", line 8, in 
sys.exit(run())
 ^
  File "/usr/lib/python3/dist-packages/gajim/main.py", line 171, in run
_init_gui('GTK')
  File "/usr/lib/python3/dist-packages/gajim/main.py", line 105, in _init_gui
_init_gtk()
  File "/usr/lib/python3/dist-packages/gajim/main.py", line 123, in _init_gtk
from gajim.gtk import exception
  File "/usr/lib/python3/dist-packages/gajim/gtk/exception.py", line 54, in

import sentry_sdk
  File "/usr/lib/python3/dist-packages/sentry_sdk/__init__.py", line 1, in

from sentry_sdk.hub import Hub, init
  File "/usr/lib/python3/dist-packages/sentry_sdk/hub.py", line 8, in 
from sentry_sdk.scope import Scope
  File "/usr/lib/python3/dist-packages/sentry_sdk/scope.py", line 7, in

from sentry_sdk.attachments import Attachment
  File "/usr/lib/python3/dist-packages/sentry_sdk/attachments.py", line 5, in

from sentry_sdk.envelope import Item, PayloadRef
  File "/usr/lib/python3/dist-packages/sentry_sdk/envelope.py", line 7, in

from sentry_sdk.session import Session
  File "/usr/lib/python3/dist-packages/sentry_sdk/session.py", line 5, in

from sentry_sdk.utils import format_timestamp
  File "/usr/lib/python3/dist-packages/sentry_sdk/utils.py", line 1305, in

HAS_REAL_CONTEXTVARS, ContextVar = _get_contextvars()
   ^^
  File "/usr/lib/python3/dist-packages/sentry_sdk/utils.py", line 1275, in
_get_contextvars
if not _is_contextvars_broken():
   
  File "/usr/lib/python3/dist-packages/sentry_sdk/utils.py", line 1228, in
_is_contextvars_broken
from eventlet.patcher import is_monkey_patched  # type: ignore
^^
  File "/usr/lib/python3/dist-packages/eventlet/__init__.py", line 17, in

from eventlet import convenience
  File "/usr/lib/python3/dist-packages/eventlet/convenience.py", line 7, in

from eventlet.green import socket
  File "/usr/lib/python3/dist-packages/eventlet/green/socket.py", line 21, in

from eventlet.support import greendns
  File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 79,
in 
setattr(dns, pkg, import_patched('dns.' + pkg))
  
  File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 61,
in import_patched
return patcher.import_patched(module_name, **modules)
   ^^
  File "/usr/lib/python3/dist-packages/eventlet/patcher.py", line 132, in
import_patched
return inject(
   ^^^
  File "/usr/lib/python3/dist-packages/eventlet/patcher.py", line 109, in
inject
module = __import__(module_name, {}, {}, module_name.split('.')[:-1])
 
  File "/usr/lib/python3/dist-packages/dns/asyncquery.py", line 38, in 
from dns.query import (
  File "/usr/lib/python3/dist-packages/dns/query.py", line 63, in 
import httpcore
  File "/usr/lib/python3/dist-packages/httpcore/__init__.py", line 1, in

from ._api import request, stream
  File "/usr/lib/python3/dist-packages/httpcore/_api.py", line 5, in 
from ._sync.connection_pool import ConnectionPool
  File "/usr/lib/python3/dist-packages/httpcore/_sync/__init__.py", line 1, in

from .connection import HTTPConnection
  File "/usr/lib/python3/dist-packages/httpcore/_sync/connection.py", line 12,
in 
from .._synchronization import Lock
  File "/usr/lib/python3/dist-packages/httpcore/_synchronization.py", line 11,
in 
import trio
  File "/usr/lib/python3/dist-packages/trio/__init__.py", line 22, in 
from ._core import TASK_STATUS_IGNORED as TASK_STATUS_IGNORED  # isort:
split
^
  File "/usr/lib/python3/dist-packages/trio/_core/__init__.py", line 21, in

from ._local import RunVar, RunVarToken
  File "/usr/lib/python3/dist-packages/trio/_core/_local.py", line 9, in

from . import _run
  File "/usr/lib/python3/dist-packages/trio/_core/_run.py", line 2775, in

from ._io_epoll import (
  File "/usr/lib/python3/dist-packages/trio/_core/_io_epoll.py", line 202, in

class EpollIOManager:
  File "/usr/lib/python3/dist-packages/trio/_core/_io_epoll.py", line 203, in
EpollIOManager
_epoll: select.epoll = attr.ib(factory=select.epoll)
   
AttributeError: module 'eventlet.green.select' has no attribute 'epoll'

---

I have tried rolling back gajim itself but that did not help. I unfortunately
lack the detailed 

Bug#1060920: deluged: Deluged has high CPU load with many logged exceptions under normal operation

2024-01-16 Thread Shawn Begin
Package: deluged
Version: 2.0.3-4
Severity: normal
X-Debbugs-Cc: dieselcheve...@hotmail.com

Dear Maintainer,

I am a recent convert from Gentoo to Debian and installed bookworm yesterday.
I installed deluged to host my large selection of torrents.
In bookworm stable, deluged uses considerably more CPU time than it did under 
gentoo, showing > 40% regularly in htop.
I was seeing single digits in Gentoo.

I did some troubleshooting, including starting the daemon directly from the 
command line to see if deluged is sending any messages to stdout.
It appears there are a slew of exceptions being handled all day long when it is 
operating, saturating the terminal
when it is run directly by the user with -d to keep it attached.  I think this 
is why the CPU load is so high.

Being Debian stable, this kind of surprised me, which is why I am filing a bug 
report.

I have about a 700kB file of a terminal log, but, I will provide a snipplet 
below of one of the exceptions.
If you'd like the full file, please let me know and I'll post it if you'd like.

I did have apt remove deluged, deluge-console and then autoremove the unused 
deps, and reinstalled it.
No Changes.

Here is one of the exceptions:

Unhandled error in Deferred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/deluge/core/torrentmanager.py", line 
697, in add_async_callback
torrent = self._add_torrent_obj(
  File "/usr/lib/python3/dist-packages/deluge/core/torrentmanager.py", line 
668, in _add_torrent_obj
log.info(
  File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1905, 
in unwindGenerator
return _cancellableInlineCallbacks(gen)
  File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1815, 
in _cancellableInlineCallbacks
_inlineCallbacks(None, gen, status)
---  ---
  File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1660, 
in _inlineCallbacks
result = current_context.run(gen.send, result)
  File "/usr/lib/python3/dist-packages/deluge/log.py", line 69, in info
yield LoggingLoggerClass.info(self, msg, *args, **kwargs)
  File "/usr/lib/python3.11/logging/__init__.py", line 1489, in info
self._log(INFO, msg, args, **kwargs)
  File "/usr/lib/python3.11/logging/__init__.py", line 1622, in _log
fn, lno, func, sinfo = self.findCaller(stack_info, stacklevel)
builtins.TypeError: Logging.findCaller() takes from 1 to 2 positional arguments 
but 3 were given

Temporarily disabling observer LegacyLogObserverWrapper(>) due to exception: [Failure instance: Traceback: : Logging.findCaller() takes from 1 to 2 positional arguments but 3 
were given
/usr/lib/python3/dist-packages/twisted/internet/defer.py:1794:_cancellableInlineCallbacks
/usr/lib/python3/dist-packages/twisted/internet/defer.py:344:__del__
/usr/lib/python3/dist-packages/twisted/logger/_logger.py:190:failure
/usr/lib/python3/dist-packages/twisted/logger/_logger.py:142:emit
---  ---
/usr/lib/python3/dist-packages/twisted/logger/_observer.py:81:__call__
/usr/lib/python3/dist-packages/twisted/logger/_legacy.py:90:__call__
/usr/lib/python3/dist-packages/deluge/log.py:204:emit
/usr/lib/python3.11/logging/__init__.py:1536:critical
/usr/lib/python3.11/logging/__init__.py:1622:_log
]
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1794, 
in _cancellableInlineCallbacks
def handleCancel(result: Failure) -> Deferred[object]:
  File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 344, in 
__del__
log.failure(format, self.failResult, debugInfo=debugInfo)
  File "/usr/lib/python3/dist-packages/twisted/logger/_logger.py", line 190, in 
failure
self.emit(level, format, log_failure=failure, **kwargs)
  File "/usr/lib/python3/dist-packages/twisted/logger/_logger.py", line 142, in 
emit
self.observer(event)
---  ---
  File "/usr/lib/python3/dist-packages/twisted/logger/_observer.py", line 81, 
in __call__
observer(event)
  File "/usr/lib/python3/dist-packages/twisted/logger/_legacy.py", line 90, in 
__call__
self.legacyObserver(event)
  File "/usr/lib/python3/dist-packages/deluge/log.py", line 204, in emit
getattr(LoggingLoggerClass, event_dict['log_level'].name)(
  File "/usr/lib/python3.11/logging/__init__.py", line 1536, in critical
self._log(CRITICAL, msg, args, **kwargs)
  File "/usr/lib/python3.11/logging/__init__.py", line 1622, in _log
fn, lno, func, sinfo = self.findCaller(stack_info, stacklevel)
builtins.TypeError: Logging.findCaller() takes from 1 to 2 positional arguments 
but 3 were given


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

Kernel: Linux 6.1.0-17-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, 

Bug#1054105: jigdo-file: downloads serially with long pauses between (usually small) files

2023-10-16 Thread Shawn Paul Landden
Package: jigdo-file
Version: 0.8.2-1
Severity: normal
Tags: patch
X-Debbugs-Cc: shawnland...@outlook.com

(from the patch which is included)

jigdo-lite: parallel wget download if xargs is available

Jigdo downloads are significantly slower than iso downloads because there is
a new connection between each file, with a pause. This slow-down is greater
the faster the connection, so wouldn't be that big with a 56kbps connection,
and has increased since this software was developed.

No change if "xargs" from "findutils" is not available.

There is still a pause, yet to be removed, when commiting each batch of
files to the iso9660.

Signed-off-by: Shawn Paul Landden 

-- System Information:
Debian Release: 12.1
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.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 jigdo-file depends on:
ii  libbz2-1.0  1.0.8-5+b1
ii  libc6   2.37-12
ii  libdb5.35.3.28+dfsg2-1
ii  libgcc-s1   13.2.0-5
ii  libstdc++6  13.2.0-5
ii  wget1.21.3-1+b2
ii  zlib1g  1:1.2.13.dfsg-1

jigdo-file recommends no packages.

jigdo-file suggests no packages.

-- no debconf information

*** 0001-jigdo-lite-parallel-wget-download-if-xargs-is-availa.patch
>From b995741f09b3b8f52d3315b063552ee63e5b5834 Mon Sep 17 00:00:00 2001
From: Shawn Paul Landden 
Date: Mon, 16 Oct 2023 21:19:09 -0700
Subject: [PATCH] jigdo-lite: parallel wget download if xargs is available

Jigdo downloads are significantly slower than iso downloads because there is
a new connection between each file, with a pause. This slow-down is greater
the faster the connection, so wouldn't be that big with a 56kbps connection,
and has increased since this software was developed.

No change if "xargs" from "findutils" is not available.

There is still a pause, yet to be removed, when commiting each batch of
files to the iso9660.

Signed-off-by: Shawn Paul Landden 
---
 debian/control | 1 +
 scripts/jigdo-lite | 8 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index c1bab0e..190aad1 100644
--- a/debian/control
+++ b/debian/control
@@ -8,6 +8,7 @@ Standards-Version: 4.1.1
 Package: jigdo-file
 Architecture: any
 Depends: wget, ${shlibs:Depends}, ${misc:Depends}
+Recommends: findutils
 Conflicts: jigdo (<< 0.6.9)
 Homepage: https://www.einval.com/~steve/software/jigdo/
 Description: Download Debian CD/DVD/USB images from any Debian mirror
diff --git a/scripts/jigdo-lite b/scripts/jigdo-lite
index e9e4f2c..1a33814 100755
--- a/scripts/jigdo-lite
+++ b/scripts/jigdo-lite
@@ -71,14 +71,18 @@ strNotEmpty() { test "x$1" != "x"; }
 # Download a file, storing it in the current dir
 fetch() {
   if test "$#" -eq 0; then return 0; fi
-  wget --user-agent="$userAgent" $wgetOpts "$@" || return 1
+  if test -n `command -v xargs`; then
+echo "$@" | xargs -n 1 -P 5 --delimiter="\x20" wget 
--user-agent="$userAgent" $wgetOpts --force-directories 
--directory-prefix="$imageTmp" -- || return 1
+  else
+wget --user-agent="$userAgent" $wgetOpts --force-directories 
--directory-prefix="$imageTmp" -- "$@" || return 1
+  fi
 }
 #__
 
 # Given URLs, fetch them into $imageTmp, then merge them into image
 fetchAndMerge() {
   if test "$#" -eq 0; then return 0; fi
-  fetch --force-directories --directory-prefix="$imageTmp" -- "$@"
+  fetch "$@"
   # Merge into the image
   $jigdoFile $jigdoOpts --no-cache make-image --image="$image" \
 --jigdo="$jigdoF" --template="$template" "$imageTmp"
-- 
2.42.0
>From b995741f09b3b8f52d3315b063552ee63e5b5834 Mon Sep 17 00:00:00 2001
From: Shawn Paul Landden 
Date: Mon, 16 Oct 2023 21:19:09 -0700
Subject: [PATCH] jigdo-lite: parallel wget download if xargs is available

Jigdo downloads are significantly slower than iso downloads because there is
a new connection between each file, with a pause. This slow-down is greater
the faster the connection, so wouldn't be that big with a 56kbps connection,
and has increased since this software was developed.

No change if "xargs" from "findutils" is not available.

There is still a pause, yet to be removed, when commiting each batch of
files to the iso9660.

Signed-off-by: Shawn Paul Landden 
---
 debian/control | 1 +
 scripts/jigdo-lite | 8 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index c1bab0e..190aad1 100644
--- a/debian/control
+++ b/debian/control
@@ -8,6 +

Bug#950334: Run my sytoms kill all bugs will u please

2023-09-20 Thread Shawn Mccann



Shawn



Bug#950334: Up

2023-08-25 Thread Shawn Mccann



Shawn



Bug#1022167: angelfish: Search engine hard-coded, and having Internet-based home-page is against Debian policy.

2022-10-21 Thread Shawn Landden
Package: angelfish
Version: 22.06-1
Severity: normal
X-Debbugs-Cc: shawnland...@tutanota.com

If I change /usr/share/config.kcfg/angelfishsettings.kcfg to point to a search
engine other than DuckDuckGo, it still goes to this site, and the settings do 
not appear to
do anything.

It is also impossible to change the homepage from https://start.duckduckgo.com/
which means that this package calls home. It will go to this url even if the 
configuration
file is changed.

Thank you,

Shawn Paul Landden


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

Kernel: Linux 5.19.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=es_US.UTF-8, LC_CTYPE=es_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 angelfish depends on:
ii  libc6   2.35-3
ii  libgcc-s1   12.2.0-3
ii  libkf5configcore5   5.98.0-1
ii  libkf5configgui55.98.0-1
ii  libkf5coreaddons5   5.98.0-1
ii  libkf5dbusaddons5   5.98.0-1
ii  libkf5i18n5 5.98.0-1
ii  libkf5notifications55.98.0-1
ii  libkf5windowsystem5 5.98.0-1
ii  libqt5core5a5.15.4+dfsg-5
ii  libqt5gui5  5.15.4+dfsg-5
ii  libqt5network5  5.15.4+dfsg-5
ii  libqt5qml5  5.15.4+dfsg-4
ii  libqt5quick55.15.4+dfsg-4
ii  libqt5sql5  5.15.4+dfsg-5
ii  libqt5webengine55.15.10+dfsg-4
ii  libqt5webenginecore5 [qtwebengine-abi-5-15-10]  5.15.10+dfsg-4
ii  libqt5widgets5  5.15.4+dfsg-5
ii  libstdc++6  12.2.0-3
ii  qml-module-org-kde-kirigami25.98.0-1
ii  qml-module-qtfeedback   5.0~git20180903.a14bd0b-5
ii  qml-module-qtwebengine  5.15.10+dfsg-4

angelfish recommends no packages.

angelfish suggests no packages.

-- no debconf information



Bug#1021908: dpkg: support l2fs filesystem compression

2022-10-17 Thread Shawn Landden
Package: dpkg
Version: 1.20.11
Severity: wishlist
X-Debbugs-Cc: shawnland...@tutanota.com

I found that zfs's compression (available with Ubuntu's install) was not 
satisfactory on small eMMCs
because it requires a seperate /boot partition and does not support swap files.

The F2FS filesystem supports compression, with a special caveat that in order 
to actually make
the files consume less space (they always use less space, which effects 
performance and health),
they must be marked as immutable, and before being changed they must be marked 
as mutable again,
consuming the uncompressed size in terms of filesystem accounting.

dpkg has a good idea of what files are read-only, and could be configured to 
mark files as immutable,
except conffiles, which would make installation on of Debian tiny Chromebook 
eMMCs a much better
experience than with ext4.

Thanks,

Shawn Paul Landden


-- Package-specific info:
System tainted due to merged-usr-via-aliased-dirs.

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

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=es_US.UTF-8, LC_CTYPE=es_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 dpkg depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-13+deb11u3
ii  liblzma5 5.2.5-2.1~deb11u1
ii  libselinux1  3.1-3
ii  tar  1.34+dfsg-1
ii  zlib1g   1:1.2.11.dfsg-2+deb11u1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.2.4
pn  debsig-verify  

-- no debconf information



Bug#1014281: ffdiaporama: Crashes on start with "malloc(): corrupted top size"

2022-07-03 Thread Shawn K. Quinn
Package: ffdiaporama
Version: 2.1+dfsg-1+b3
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: skqu...@rushpost.com

Dear Maintainer,

   * What led up to the situation?

Trying to run ffdiaporama for the first time.

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

Run the executable "ffDiaporama" from a terminal.

   * What was the outcome of this action?

The program appears to start normally, but I get this output:

$ ffDiaporama
[07:09:12.213:INFO] QT Version:5.15.2
[07:09:12.213:INFO] StartupDir /home/skquinn
[07:09:12.213:INFO] Application not found in directory
/home/skquinn/BUILDVERSION.txt
[07:09:12.213:INFO] Application not found in directory
/../../ffDiaporama/BUILDVERSION.txt
[07:09:12.213:INFO] Application not found in directory
/../ffDiaporama/BUILDVERSION.txt
[07:09:12.213:INFO] Application not found in directory
/opt/share/ffDiaporama/BUILDVERSION.txt
[07:09:12.213:INFO] Application found in directory
/usr/share/ffDiaporama/BUILDVERSION.txt
[07:09:12.213:INFO] Set working path to /usr/share/ffDiaporama
[07:09:12.213:INFO] Start ffDiaporama 2.1 (20140209) ...
[07:09:12.286:INFO] Parse command line ...
[07:09:12.286:INFO] Set LogLevel to INFORMATION
[07:09:12.286:INFO] Start GUI ...
[07:09:12.287:INFO] Start ...
libpng warning: iCCP: known incorrect sRGB profile
[07:09:12.309:INFO] Init home user database...
[07:09:12.311:INFO] Init translations...
[07:09:12.312:INFO] Read configuration file
/usr/share/ffDiaporama/ffDiaporama.xml
[07:09:12.315:INFO] Read configuration file
/usr/share/ffDiaporama/Devices.xml
[07:09:12.321:INFO] Read configuration file
/home/skquinn/.ffDiaporama/ffDiaporama.xml
[07:09:12.321:INFO] Read configuration file
/home/skquinn/.ffDiaporama/Devices.xml
[07:09:12.322:ERROR]Restore from a previous crash...
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
[07:09:13.075:INFO] Loading system icons...
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
[07:09:13.104:INFO] Starting libav...
[07:09:13.105:INFO] Loading background library...
[07:09:13.114:INFO] Loading text frame library...
[07:09:13.139:INFO] Loading no-luma transitions...
[07:09:13.142:INFO] Loading luma transitions...
[07:09:13.310:INFO] Scan drives in computer...
[07:09:13.310:INFO] Register models...
[07:09:13.646:INFO] Reading directory content (~/)
[07:09:13.796:WARNING]  LIBAV: Warning: data is not aligned! This can lead to a
speed loss
[07:09:13.801:INFO] LIBAV: Statistics: 32768 bytes read, 0 seeks
[07:09:13.807:INFO] LIBAV: Reinit context to 960x528, pix_fmt: yuv420p
[07:09:13.814:INFO] LIBAV: Reinit context to 960x528, pix_fmt: yuv420p
[07:09:13.823:INFO] LIBAV: Statistics: 137773 bytes read, 2 seeks
[07:09:13.841:INFO] LIBAV: Reinit context to 1152x720, pix_fmt: yuv420p
[07:09:13.846:INFO] LIBAV: Reinit context to 1152x720, pix_fmt: yuv420p
[07:09:13.857:INFO] LIBAV: Statistics: 163840 bytes read, 0 seeks
[07:09:13.869:INFO] LIBAV: Statistics: 32768 bytes read, 0 seeks
[07:09:13.879:INFO] LIBAV: Reinit context to 1920x1088, pix_fmt: yuv420p
[07:09:13.888:INFO] LIBAV: Reinit context to 1920x1088, pix_fmt: yuv420p
[07:09:13.910:INFO] LIBAV: Statistics: 130938 bytes read, 2 seeks
[07:09:13.926:INFO] LIBAV: Statistics: 65536 bytes read, 0 seeks
malloc(): corrupted top size
Aborted


   * What outcome did you expect instead?

I expected to get at least as far as the main program screen.

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

Kernel: Linux 5.18.0-0.bpo.1-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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ffdiaporama depends on:
ii  ffdiaporama-data 2.1+dfsg-1
ii  libavcodec58 7:4.3.4-0+deb11u1
ii  libavfilter7 7:4.3.4-0+deb11u1
ii  libavformat587:4.3.4-0+deb11u1
ii  libavutil56  7:4.3.4-0+deb11u1
ii  libc62.31-13+deb11u3
ii  

Bug#986746: systemd: Symbols are missing when building systemd by Clang

2021-04-11 Thread Shawn Chang
Package: systemd
Version: 241-7~deb10u7
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

Reproducible steps:

# cat /etc/dpkg/buildflags.conf 
APPEND CFLAGS -O -fPIE  
APPEND CXXFLAGS -O -fPIE 
APPEND LDFLAGS -pie -fuse-ld=lld

# Add below to debian/rules
export CC=clang
export CXX=clang++

3 test cases will failed, you can ignore them by:
  1) Edit debian/rules, comment a few lines:

ifeq (, $(filter nocheck, $(DEB_BUILD_OPTIONS)))
#   echo "01234567890123456789012345678901" > build-deb/machine-id
# some tests hang under fakeroot, so disable fakeroot
#   env -u LD_PRELOAD 
SYSTEMD_MACHINE_ID_PATH=$(CURDIR)/build-deb/machine-id meson test -C build-deb 
$(TEST_TIMEOUT_MULTIPLIER) || ( \
#
env -u LD_PRELOAD  meson test -C build-deb $(TEST_TIMEOUT_MULTIPLIER) 
|| ( \

  2) Drop two 
patches(0001-util-lib-static-array-argument-sizes-are-apparently-.patch and 
test-bus-track.patch) into debian/patches:

diff --git a/src/basic/string-util.c b/src/basic/string-util.c
index 7c487fb9a3..9586b3940e 100644
--- a/src/basic/string-util.c
+++ b/src/basic/string-util.c
@@ -725,10 +725,17 @@ char *strreplace(const char *text, const char 
*old_string, const char *new_strin
 return ret;
 }

-static void advance_offsets(ssize_t diff, size_t offsets[static 2], size_t 
shift[static 2], size_t size) {
+static void advance_offsets(
+ssize_t diff,
+size_t offsets[2], /* note: we can't use [static 2] here, 
since this may be NULL */
+size_t shift[static 2],
+size_t size) {
+
 if (!offsets)
 return;

+assert(shift);
+
 if ((size_t) diff < offsets[0])
 shift[0] += size;
 if ((size_t) diff < offsets[1])
@@ -844,8 +851,7 @@ char *strip_tab_ansi(char **ibuf, size_t *_isz, size_t 
highlight[2]) {

 fclose(f);

-free(*ibuf);
-*ibuf = obuf;
+free_and_replace(*ibuf, obuf);

 if (_isz)
 *_isz = osz;
@@ -855,7 +861,7 @@ char *strip_tab_ansi(char **ibuf, size_t *_isz, size_t 
highlight[2]) {
 highlight[1] += shift[1];
 }

-return obuf;
+return *ibuf;
 }

 char *strextend_with_separator(char **x, const char *separator, ...) {

diff --git a/src/libsystemd/sd-bus/test-bus-track.c 
b/src/libsystemd/sd-bus/test-bus-track.c
index 68a0010368..57af185d46 100644
--- a/src/libsystemd/sd-bus/test-bus-track.c
+++ b/src/libsystemd/sd-bus/test-bus-track.c
@@ -49,6 +49,7 @@ int main(int argc, char *argv[]) {
 const char *unique;
 int r;

+   return 0;
 test_setup_logging(LOG_INFO);

 r = sd_event_default();

  3) Add those two patch files's name into debian/patches/series

Begin to build the package:
# dpkg-buildpackage -rfakeroot -us -uc



make[1]: Entering directory '/opt/debian10/build/tmp/systemd-241'
dh_missing --sourcedir debian/install/deb --fail-missing
make[1]: Leaving directory '/opt/debian10/build/tmp/systemd-241'
   dh_strip -O--buildsystem=meson
   debian/rules override_dh_makeshlibs
make[1]: Entering directory '/opt/debian10/build/tmp/systemd-241'
sed 's/SHARED_LIB_VERSION/241/' debian/shlibs.local.in > debian/shlibs.local
dh_makeshlibs -plibudev1 --add-udeb=libudev1-udeb -- -c4
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libudev1/DEBIAN/symbols doesn't match 
completely debian/libudev1.symbols
--- debian/libudev1.symbols (libudev1_241-7~deb10u7_amd64)
+++ dpkg-gensymbolshwl7L5   2021-04-11 14:15:58.815007345 +0800
@@ -1,10 +1,10 @@
 libudev.so.1 libudev1 #MINVER#
 * Build-Depends-Package: libudev-dev
- LIBUDEV_183@LIBUDEV_183 183
- LIBUDEV_189@LIBUDEV_189 189
- LIBUDEV_196@LIBUDEV_196 196
- LIBUDEV_199@LIBUDEV_199 199
- LIBUDEV_215@LIBUDEV_215 215
+#MISSING: 241-7~deb10u7# LIBUDEV_183@LIBUDEV_183 183
+#MISSING: 241-7~deb10u7# LIBUDEV_189@LIBUDEV_189 189
+#MISSING: 241-7~deb10u7# LIBUDEV_196@LIBUDEV_196 196
+#MISSING: 241-7~deb10u7# LIBUDEV_199@LIBUDEV_199 199
+#MISSING: 241-7~deb10u7# LIBUDEV_215@LIBUDEV_215 215
  udev_device_get_action@LIBUDEV_183 183
  udev_device_get_devlinks_list_entry@LIBUDEV_183 183
  udev_device_get_devnode@LIBUDEV_183 183
dh_makeshlibs: failing due to earlier errors
make[1]: *** [debian/rules:295: override_dh_makeshlibs] Error 1
make[1]: Leaving directory '/opt/debian10/build/tmp/systemd-241'
make: *** [debian/rules:311: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


-- Package-specific info:

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

Kernel: Linux 4.19.0-16-amd64 (SMP w/8 CPU cores)
Locale: 

Bug#950140: whois: does not support internationalized domain names encoded with punycode

2020-01-29 Thread Shawn Landden
Package: whois
Version: 5.5.5
Severity: normal

whois does not know how to convert UTF-8 passed in an argument to punycode, but 
if passed punycode,
it works correctly. This is simple, because there is no need for a black list.

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

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

Versions of packages whois depends on:
ii  libc6  2.29-6
ii  libcrypt1  1:4.4.10-7

whois recommends no packages.

whois suggests no packages.

-- no debconf information



Bug#943664: xserver-xorg-video-radeon 19.1 (ppc64) crash at startup: undefined symbol: exaGetPixmapDriverPrivate

2020-01-08 Thread Shawn Rutledge
>on the ppc64 architecture the package 
>
>   xserver-xorg-video-radeon_1%3a19.1.0-1_ppc64.deb
> 
>crashes the xserver at startup.
>Xorg complains about an undefined symbol: exaGetPixmapDriverPrivate

I’m having this issue too, after installing Debian “sid” for PPC64 big-endian 
on a PowerMac G5 and updating everything: I end up with 
xserver-xorg-video-radeon and xserver-xorg-video-ati  19.1.0-1.  So have been 
trying the suggested workarounds.  The only driver that seems to “work” for 
unaccelerated graphics is fbdev.  In that case Qt even manages to fall back to 
llvmpipe and render OpenGL (Qt Quick) content mostly correctly.  But of course, 
having a GPU, I’d certainly rather be able to use it.

The modesetting driver with AccelMethod “none” will start, but the color 
rendering has obvious issues probably related to endianness: black turns into 
bright blue, glxgears runs (via software emulation apparently) but the gears 
are cyan and magenta on a bright blue background, and generally hard to see.

I work on Qt.  Once in a while I build and test Qt on this machine to see what 
endian-related issues are showing up, and try to fix them as a low-priority 
thing.  I needed to upgrade to sid because Debian 8 was the last version that 
actually had a PPC big-endian 64-bit release, and the compiler on that version 
is getting long in the tooth; Qt 5.14 doesn’t build so easily anymore with such 
an old one.

GPU seems to be an AGP Radeon 9600; lspci says

:f0:10.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
RV350 [Radeon 9550/9600/X1050 Series]

BTW if I try to use amdgpu, I ran into the issue that glamor requires 128 or 
more instructions but this GPU only supports 64.  So it would really need to be 
radeon_drv for best performance I suppose.  (By comparison, on Debian 8 the 
radeon driver is automatically chosen, but the log says GPU access disabled or 
not working, using shadowfb for KMS.  The colors are fine, but the OpenGL 
performance is not good, of course.)

Here’s my current /etc/X11/xorg.conf.d/10-modesetting.conf
Section "Device"
Identifier "rv350"
#Driver  "fbdev"
Driver  "modesetting"
Option  "AccelMethod" "none"
EndSection

Section "Monitor"
# HorizSync source: edid, VertRefresh source: edid
Identifier "Monitor0"
VendorName "Unknown"
ModelName  "Samsung SyncMaster"
HorizSync   30.0 - 81.0
VertRefresh 50.0 - 63.0
Option "DPMS"
EndSection

Section "Screen"
Identifier "Screen0"
Device "rv350"
Monitor"Monitor0"
DefaultDepth24
SubSection "Display"
Depth   24
EndSubSection
EndSection

And xorg.log with that setup:

[147798.710]
X.Org X Server 1.20.6
X Protocol Version 11, Revision 0
[147798.759] Build Operating System: Linux 4.19.0-5-powerpc64 ppc64 Debian
[147798.776] Current Operating System: Linux g5deb 5.4.0-2-powerpc64 #1 SMP 
Debian 5.4.8-1 (2020-01-05) ppc64
[147798.776] Kernel command line: 
root=UUID=7afdfb2d-2088-4916-8a9f-1c6ff2c1c046 ro ramdisk_size=8192
[147798.809] Build Date: 25 November 2019  09:49:09AM
[147798.825] xorg-server 2:1.20.6-1 (https://www.debian.org/support)
[147798.841] Current version of pixman: 0.36.0
[147798.874]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[147798.874] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[147798.940] (==) Log file: "/home/rutledge/.local/share/xorg/Xorg.9.log", 
Time: Wed Jan  8 10:55:18 2020
[147798.957] (==) Using config directory: "/etc/X11/xorg.conf.d"
[147798.974] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[147798.978] (==) No Layout section.  Using the first Screen section.
[147798.978] (**) |-->Screen "Screen0" (0)
[147798.978] (**) |   |-->Monitor "Monitor0"
[147798.980] (**) |   |-->Device "rv350"
[147798.980] (==) Automatically adding devices
[147798.980] (==) Automatically enabling devices
[147798.980] (==) Automatically adding GPU devices
[147798.980] (==) Max clients allowed: 256, resource mask: 0x1f
[147798.981] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[147798.981]Entry deleted from font path.
[147798.982] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[147798.982] (==) ModulePath set to "/usr/lib/xorg/modules"
[147798.982] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[147798.982] (II) Loader magic: 0x12e202ad0
[147798.982] (II) 

Bug#944319: lld-9: please package development headers

2019-11-07 Thread Shawn Landden
Package: lld-9
Severity: wishlist

Zig lang (https://ziglang.org) wants to link against liblld and needs 
development headers to do so.
Until these are packaged zig has to build its internal version of lld, which is 
identical to upstream lld.

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

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

Versions of packages lld-9 depends on:
ii  libc6   2.29-3
ii  libgcc1 1:9.2.1-17
ii  libllvm91:9.0.0-3
ii  libstdc++6  9.2.1-17

lld-9 recommends no packages.

lld-9 suggests no packages.



Bug#934188: s3cmd: move to contrib. Depends on a non-free service with no free implementations

2019-08-07 Thread Shawn Landden
close -1
Message-ID: <156521345030.31452.11950702444220692635.report...@scaleway.git.icu>
X-Mailer: reportbug 7.5.2
Date: Wed, 07 Aug 2019 21:30:50 +
X-Debbugs-Cc: sh...@git.icu

Package: s3cmd
Followup-For: Bug #934188

It appears this is very common

https://packages.debian.org/search?keywords=twitter




-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)
Foreign Architectures: armel, armhf

Kernel: Linux 4.15.11-mainline-rev1 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages s3cmd depends on:
ii  python3   3.7.3-1
ii  python3-dateutil  2.7.3-3
pn  python3-magic 

s3cmd recommends no packages.

s3cmd suggests no packages.



Bug#934188: s3cmd: move to contrib. Depends on a non-free service with no free implementations

2019-08-07 Thread Shawn Landden
Package: s3cmd
Severity: serious
Justification: Policy 2.2.1

Hi,

This package depends on a non-free service (Amazon S3), but is in the main 
section of the archive.
This is a violation of 2.2.1:
must not require or recommend a package outside of main for compilation or 
execution

This program is useless without Amazon S3, and thus should be moved to the 
contrib section of the archive.

>From 2.2.2:
 
Examples of packages which would be included in contrib are:
 - wrapper packages or other sorts of free accessories for non-free programs.

-Shawn Landden

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)
Foreign Architectures: armel, armhf

Kernel: Linux 4.15.11-mainline-rev1 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages s3cmd depends on:
ii  python3   3.7.3-1
ii  python3-dateutil  2.7.3-3
pn  python3-magic 

s3cmd recommends no packages.

s3cmd suggests no packages.



Bug#926884: distcc: Does not work with clang

2019-06-20 Thread Shawn Landden
#1) I talked to some other dds and this is not a release critical bug

#2) this is a different bug from the python script bug.

Regarding the other bug:
That script *does* work (I developed and use it on Debian), however that is
a nasty bug and I don't know how to solve it.

Shawn.

El jue., 20 jun. 2019 1:13, Christian Marillat 
escribió:

> > Package: distcc
> > Followup-For: Bug #926884
> >
> > This package should not be released in Buster with this bug,
> > clang is an important compiler (and much easier for cross-compiling)
> > and not working with it is too big of a bug.
>
> I'm sorry but no. Your python script doesnt work for Debian See #920709
>
> Christian
>


Bug#926884: distcc: Does not work with clang

2019-06-19 Thread Shawn Landden
severity -1 serious
Message-ID: 
<156099516006.31749.3126069341315892890.reportbug@big-daddy.novalocal>
X-Mailer: reportbug 7.5.2
Date: Wed, 19 Jun 2019 21:46:00 -0400
X-Debbugs-Cc: sh...@git.icu

Package: distcc
Followup-For: Bug #926884

This package should not be released in Buster with this bug,
clang is an important compiler (and much easier for cross-compiling)
and not working with it is too big of a bug.

Your Upstream,

Shawn Landden

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: ppc64el (ppc64le)

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

Versions of packages distcc depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.72
ii  init-system-helpers1.56+nmu1
ii  libavahi-client3   0.7-4+b1
ii  libavahi-common3   0.7-4+b1
ii  libc6  2.28-10
ii  libgssapi-krb5-2   1.17-2
ii  libpopt0   1.16-12
ii  lsb-base   10.2019051400
ii  netbase5.6

distcc recommends no packages.

Versions of packages distcc suggests:
ii  ccache   3.7.1-1
ii  dbus 1.12.16-1
pn  distcc-pump  
pn  distccmon-gnome  
pn  dmucs



Bug#930585: Suggested fix/enhancement for wireless-tools.if-pre-up script

2019-06-15 Thread Shawn J
Package: wireless-tools
Version: 30~pre9-13

See ubuntu bug report:
https://bugs.launchpad.net/ubuntu/+source/wireless-tools/+bug/1832964


I've been experiencing an issue with my wireless card and ifup relating to
this script. I have a fix for it and thought the devs here might be
interested.

This is the issue: If a setting fails to be applied, the script brings the
card up and then tries to apply the setting again. This is fine, but it
leaves the card up. Later on in the ifup process other scripts try to
access the card and if the card is up it will respond that it's busy and
ifup fails.

My solution has been to alter the wireless-tools if-pre-up script so that
it ends by running ifconfig down in this case. Here is the patch:

--- ./wireless-tools.if-pre-up 2017-04-22 10:15:05.0 -0400
+++ ./wireless-tools 2019-06-03 22:39:24.314725863 -0400
@@ -6,7 +6,7 @@
   exit 0
 fi

-# check if this is a 802.11 device we're supposed to be effecting
+# check if this is a 802.11 device we're supposed to be affecting
 case "${IF_WIRELESS:-enable}" in
  wireless-tools|iwconfig)
  # *we* and not some other 802.11 tool should be used
@@ -140,4 +140,5 @@
  FAIL=
  ifconfig "$IFACE" up
  apply_settings
+ ifconfig "$IFACE" down
 fi


Bug#795571: kyotocabinet: diff for NMU version 1.2.76-4.1

2019-06-15 Thread Shawn Landden
Package: kyotocabinet
Followup-For: Bug #795571

close -1

This has been uploaded

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: ppc64el (ppc64le)

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



Bug#930502: htop: Please support new libnl hooks

2019-06-13 Thread Shawn Landden
Package: htop
Version: 2.2.0-1+b1
Severity: wishlist

Htop now includes metrics from libnl, as described in this talk 
https://hisham.hm/htop/

https://www.youtube.com/watch?v=L25waVhy78o

Please enable these new features.


http://hisham.hm/htop/index.php?page=downloads


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

Kernel: Linux 4.19.0-4-powerpc64le (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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages htop depends on:
ii  libc6 2.28-10
ii  libncursesw6  6.1+20181013-2
ii  libtinfo6 6.1+20181013-2

htop recommends no packages.

Versions of packages htop suggests:
ii  lsof4.91+dfsg-1
ii  strace  4.26-0.2

-- no debconf information



Bug#929580: lld-7 cannot link large binaries on ppc64le. Please make lld-8 default on ppc64le.

2019-06-09 Thread Shawn Landden
Ping.

lld-7 should be disabled on ppc64el



Bug#881692: command-not-found: I re-wrote command-not-found

2019-06-04 Thread Shawn Landden
Package: command-not-found
Version: 18
Followup-For: Bug #881692

Dear Maintainer,

Dear Maintainer,

A snap hook was just merged https://github.com/snapcore/snapd/pull/6734

My package now supports the Commands hook that Ubuntu servers export
(as well as apt-file). As Debian does not yet ship this file,
apt-file should be recommended and not suggested on Debian, but I am hesitant to
have differn't packaging as this is a native package.


-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)
Foreign Architectures: armel, armhf

Kernel: Linux 4.15.11-mainline-rev1 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages command-not-found depends on:
ii  adduser  3.118
ii  apt  1.8.2
ii  libc62.28-10

command-not-found recommends no packages.

Versions of packages command-not-found suggests:
ii  apt-file  3.2.2

-- no debconf information



Bug#929725: ddd: Window does not close when killed with ctrl-z

2019-05-31 Thread Shawn Landden
El vie., 31 may. 2019 4:33, Bernhard Übelacker 
escribió:

> Control: tags -1 + moreinfo
>
>
> Hello Shawn Landden,
> where exactly do you enter this ctrl-z?
>
Good point. I started ddd from a terminal. Ctrl-c is ignored.

>
>
> In the graphical user interface of ddd ctrl-z is the shortcut for the
> Edit - Undo action. So that is not supposed to end ddd, I guess.
>
>
> Or do you enter it in a terminal from which you started ddd?
> From man bash:
> ... Typing the suspend character (typically ^Z, Control-Z) while
> a process is running causes that process to be stopped and returns
> control to bash. ...
> So that whould just send ddd to the background and stop its execution.
> If you wanted to kill it in a terminal, where ddd was started from,
> you could use ctrl-c?
>
> Kind regards,
> Bernhard
>


Bug#929725: ddd: Window does not close when killed with ctrl-z

2019-05-29 Thread Shawn Landden
Package: ddd
Version: 1:3.3.12-5.1+b2
Severity: normal

If I do ctrl-z to kill ddd, the window remains open. I have to use xkill to 
close it.

-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: ppc64el (ppc64le)

Kernel: Linux 5.1.0-gfe9812cb9 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
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 ddd depends on:
ii  libc6   2.28-10
ii  libgcc1 1:9.1.0-1
ii  libstdc++6  9.1.0-1
ii  libtinfo6   6.1+20181013-2
ii  libx11-62:1.6.7-1
ii  libxaw7 2:1.0.13-1+b2
ii  libxm4  2.3.8-2
ii  libxmu6 2:1.1.2-2+b3
ii  libxpm4 1:3.5.12-1
ii  libxt6  1:1.1.5-1+b3

Versions of packages ddd recommends:
ii  gdb  8.2.50.20190222-1

Versions of packages ddd suggests:
pn  cups-bsd | lpr   
pn  ddd-doc  
pn  glibc-doc
pn  gnuplot  
pn  info 
ii  openssh-client [rsh-client]  1:7.9p1-10
ii  perl 5.28.1-6
pn  pydb 
pn  x11-utils
pn  xterm

-- no debconf information



Bug#929580: lld-7 cannot link large binaries on ppc64le. Please make lld-8 default on ppc64le.

2019-05-26 Thread Shawn Landden
On Sun, May 26, 2019 at 11:53 AM Sylvestre Ledru  wrote:
>
> Hello
>
> Le 26/05/2019 à 18:18, Shawn Landden a écrit :
> > Package: lld
> > Version: 1:7.0-47.1
> > Severity: important
> >
> > Dear Maintainer,
> >
> > If you try to link a largish program with lld-7 on ppc64le you get errors:
> >
> > relocation R_PPC64_REL24 out of range: -15683216 is not in [-8388608, 
> > 8388607]
> >
> > This feature is added in lld-8 and is essential to make the package useful 
> > on this platform.
> >
> > Thus, please make lld-8 default on ppc64el now, insteading of waiting until 
> > it is appropiate for
> > more mature architectures.
> >
> lld-8 won't ship in buster, so, not really a workaround.
>
> A fix could be to disable lld-7 on ppc64el.
If that is the only possibility, then yes that would be preferable to
shipping something that will only cause frustration. ld.gold and
ld.bfd both work.



Bug#929580: lld-7 cannot link large binaries on ppc64le. Please make lld-8 default on ppc64le.

2019-05-26 Thread Shawn Landden
Package: lld
Version: 1:7.0-47.1
Severity: important

Dear Maintainer,

If you try to link a largish program with lld-7 on ppc64le you get errors:

relocation R_PPC64_REL24 out of range: -15683216 is not in [-8388608, 8388607]

This feature is added in lld-8 and is essential to make the package useful on 
this platform.

Thus, please make lld-8 default on ppc64el now, insteading of waiting until it 
is appropiate for
more mature architectures.

-Shawn Landden

-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: ppc64el (ppc64le)

Kernel: Linux 5.1.0-gfe9812cb9 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
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 lld depends on:
ii  lld-7  1:7.0.1-8

lld recommends no packages.

lld suggests no packages.

-- no debconf information



Bug#928765: distcc: Does not install or uninstall on Squeeze

2019-05-10 Thread Shawn Landden
Package: distcc
Version: 3.3.2-9
Severity: important

This lintian warning describes the problem:

https://lintian.debian.org/tags/skip-systemd-native-flag-missing-pre-depends.html

Thanks,
Your upstream, Shawn Landden

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: ppc64el (ppc64le)

Kernel: Linux 4.9.0-3-powerpc64le (SMP w/4 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 distcc depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.72
ii  libavahi-client3   0.7-4+b1
ii  libavahi-common3   0.7-4+b1
ii  libc6  2.28-10
ii  libgssapi-krb5-2   1.17-2
ii  libpopt0   1.16-12
ii  lsb-base   10.2019031300
ii  netbase5.6

distcc recommends no packages.

Versions of packages distcc suggests:
pn  ccache   
ii  dbus 1.12.12-1
pn  distcc-pump  
pn  distccmon-gnome  
pn  dmucs

-- debconf information:
  distcc/daemon-allow: 127.0.0.1
  distcc/daemon-jobs:
  distcc/daemon-nice: 10
  distcc/daemon-zeroconf: false
  distcc/daemon-listen: 127.0.0.1
  distcc/daemon: false



Bug#928410: installation-reports: ppc64el fails to install on Raptor/IntegriCloud VPS (only PPC VPS provider AFAIK)

2019-05-03 Thread Shawn Landden
Package: installation-reports
Severity: normal

Dear Maintainer,

Installation over network/terminal failed with "No installable kernels found"

and also reporting that it could contact the mirror (but only for file 6)
depite internet working fine (i checked via the console), and same with other 
mirrors.

I really want to use a ppc64el system for some development

-- Package-specific info:

Boot method: CD
Image version: today's mini.iso
Date: 

Machine: https://secure.integricloud.com/
Partitions: 


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

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

Comments/Problems:




-- 

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

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

-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)
Foreign Architectures: armel, armhf

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



Bug#757794: Error messages should say which host is broken

2019-04-11 Thread Shawn Landden
Source: distcc
Followup-For: Bug #757794

You can get the host if you turn on verbose logging with DISTCC_VERBOSE=1

If you still are not satisfied, please send a pull request on GIthub

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)
Foreign Architectures: armel, armhf

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



Bug#926884: distcc: Does not work with clang

2019-04-11 Thread Shawn Landden
Source: distcc
Severity: important

Dear Maintainer,

dh_auto_configure is providing --build without --host, which results in
autoconf not setting $host, which results in distcc not getting GNU_HOST
which it passes to clang for native builds.

If you try to compile with clang on a native build it quits with 
error: unknown target triple 'unknown', please use -triple or -arch

Please pass --host to autotools

-   if (dpkg_architecture_value("DEB_BUILD_GNU_TYPE") ne 
dpkg_architecture_value("DEB_HOST_GNU_TYPE")) {
-   push @opts, 
"--host=".dpkg_architecture_value("DEB_HOST_GNU_TYPE");
-   }

Thanks,

Shawn Landden
Your upstream.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)
Foreign Architectures: armel, armhf

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



Bug#917287: failure to install x32 port from iso netboot image: gpgv unknown digest algorithm

2018-12-25 Thread Shawn Rutledge
Package: gpgv
Version: 1.4.18

I’m trying to run the installer from http://debian-x32.org/d-i/netboot.iso .  
The mirror is set by default to ftp.debian-x32.org, directory /debian/.   It 
says “downloading a file failed”.  I hit alt-F4 to get to the error console to 
investigate, and the last few lines are (omitting timestamps)

choose-mirror: DEBUG: command: wget -q 
http://ftp.debian-x32.org/debian//dists/jessie/main/binary-x32/Release -O - | 
grep ^Architecture:
anna: WARNING **: bad d-i Packages file
net-retriever: gpgv: md_enable: algorithm 10 not available
net-retriever: gpgv: Signature made Sat Aug 25 17:05:17 2018 UTC using RSA key 
ID BED007F9
net-retriever: gpgv: Can’t check signature: unknown digest algorithm
net-retriever: error: Bad signature on /tmp/net-retriever-2779-Release

So maybe the signatures are done with a newer digest algorithm and therefore 
gpgv on the ISO image needs to be updated?



Bug#898090:

2018-08-17 Thread Shawn Anderson
I was able to find that if I run the following

cpanm --uninstall Storable

my issue was addressed.

Sent from Mail for Windows 10



Bug#905009: gcc-8-x86-64-linux-gnu: Relocations in generic ELF (EM: 183)

2018-07-30 Thread Shawn Landden
My bad, it was a bug at my end.

On Mon, Jul 30, 2018 at 4:17 PM Matthias Klose  wrote:

> Control: tags -1 + moreinfo help
>
> On 30.07.2018 15:22, Shawn Landden wrote:
> > Package: gcc-8-x86-64-linux-gnu
> > Version: 8.1.0-12cross1
> > Severity: important
> >
> > Dear Maintainer,
> >
> > The x86_64-linux-gnu (target) on arm64 (host) cross-compiler is broken.
> >
> >
> > /usr/bin/x86_64-linux-gnu-ld:
> CMakeFiles/test-minicrypto.t.dir/deps/micro-ecc/uECC.c.o: Relocations in
> generic ELF (EM: 183
> >
> > I am using distcc so the problem must be in the compiler proper,
> > as distcc only uses the cross-compiler, not cross-binutils.
> > (I am running distcc from an amd64 machine)
>
> Please provide a test case, not just an error message.
>


Bug#905009: gcc-8-x86-64-linux-gnu: Relocations in generic ELF (EM: 183)

2018-07-30 Thread Shawn Landden
Package: gcc-8-x86-64-linux-gnu
Version: 8.1.0-12cross1
Severity: important

Dear Maintainer,

The x86_64-linux-gnu (target) on arm64 (host) cross-compiler is broken.


/usr/bin/x86_64-linux-gnu-ld: 
CMakeFiles/test-minicrypto.t.dir/deps/micro-ecc/uECC.c.o: Relocations in 
generic ELF (EM: 183

I am using distcc so the problem must be in the compiler proper,
as distcc only uses the cross-compiler, not cross-binutils.
(I am running distcc from an amd64 machine)

Regards

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

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

Versions of packages gcc-8-x86-64-linux-gnu depends on:
ii  binutils-x86-64-linux-gnu2.31.1-2
ii  cpp-8-x86-64-linux-gnu   8.1.0-12cross1
ii  gcc-8-x86-64-linux-gnu-base  8.1.0-12cross1
ii  libc62.27-5
ii  libcc1-0 8.2.0-1
ii  libgcc-8-dev-amd64-cross 8.1.0-12cross1
ii  libgcc1  1:8.2.0-1
ii  libgmp10 2:6.1.2+dfsg-3
ii  libisl19 0.19-1
ii  libmpc3  1.1.0-1
ii  libmpfr6 4.0.1-1
ii  libstdc++6   8.2.0-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages gcc-8-x86-64-linux-gnu recommends:
ii  libc6-dev-amd64-cross  2.27-3cross3

Versions of packages gcc-8-x86-64-linux-gnu suggests:
pn  gcc-8-doc
pn  gcc-8-locales
pn  gcc-8-multilib-x86-64-linux-gnu  
pn  libasan5-dbg-amd64-cross 
pn  libatomic1-dbg-amd64-cross   
pn  libgcc1-dbg-amd64-cross  
pn  libgomp1-dbg-amd64-cross 
pn  libitm1-dbg-amd64-cross  
pn  liblsan0-dbg-amd64-cross 
pn  libmpx2-dbg-amd64-cross  
pn  libquadmath0-dbg-amd64-cross 
pn  libtsan0-dbg-amd64-cross 
pn  libubsan1-dbg-amd64-cross

-- no debconf information



Bug#904710: wolfssl: tls 1.3 not built

2018-07-26 Thread Shawn Landden
Source: wolfssl
Severity: wishlist

Dear Maintainer,

Please enable TLS 1.3


dh_auto_configure -- \
--enable-tls13 \


-- System Information:
Debian Release: 9.4
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)

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



Bug#904711: wolfssl: no

2018-07-26 Thread Shawn Landden
Source: wolfssl
Severity: important

Dear Maintainer,

When compiling the examples:

gcc -o client-tls-perf client-tls-perf.c -Wall -I/usr/local/include -Os 
-L/usr/local/lib -lm -lwolfssl
client-tls-perf.c:28:10: fatal error: wolfssl/options.h: No such file or 
directory
 #include 

This options.h file shares the config wolfssl was built with, and must be 
shipped.

-- System Information:
Debian Release: 9.4
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)

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



Bug#898090: Is there any progress on this bug at all -- getting critical!

2018-07-19 Thread Shawn Anderson
I am not able to install any security updates at all on multiple systems due to 
this bug – is there ANY progress or workaround?

Sent from Mail for Windows 10



Bug#903148: libssl1.1: no debug package

2018-07-06 Thread Shawn Landden
Package: libssl1.1
Version: 1.1.0f-3+deb9u2
Severity: wishlist

Dear Maintainer,

I would like it if there was a debug package for libssl1.1 so I could better 
profile transmission with perf.

Thank you.

-- System Information:
Debian Release: 9.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: arm64 (aarch64)

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

Versions of packages libssl1.1 depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u3

libssl1.1 recommends no packages.

libssl1.1 suggests no packages.

-- no debconf information



Bug#898090: Running into the same issue

2018-06-21 Thread Shawn Anderson
I too am running into this issue.  I did an update via cpan and now I can no 
longer update my Ubuntu system.  This is a bit on the critical side – does 
anyone have any sort of work around?

Sent from Mail for Windows 10



Bug#644998: iftop: chooses eth0 as the default interface instead of the default route

2018-06-10 Thread Shawn Landden
Package: iftop
Version: 1.0~pre4-4
Followup-For: Bug #644998

New version of the patch that supports ipv6-only hosts
-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages iftop depends on:
ii  libc62.24-11+deb9u3
ii  libncurses5  6.0+20161126-1+deb9u2
ii  libpcap0.8   1.8.1-3
ii  libtinfo56.0+20161126-1+deb9u2

iftop recommends no packages.

iftop suggests no packages.

-- no debconf information
>From 90ce46be76f1ed558a88448d730a47ad31a18b92 Mon Sep 17 00:00:00 2001
From: Shawn Landden 
Date: Sun, 10 Jun 2018 18:33:56 -0700
Subject: [PATCH] options: select interface that is default route (Closes:
 #644998)

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

IPv4 detection first, cause iftop does not work with v4tunnel
---
 options.c | 83 ++-
 1 file changed, 82 insertions(+), 1 deletion(-)

diff --git a/options.c b/options.c
index a075357..0654d46 100644
--- a/options.c
+++ b/options.c
@@ -6,8 +6,13 @@
 
 #include "config.h"
 
+#ifdef __linux__
+#define _GNU_SOURCE
+#endif
+
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -90,6 +95,75 @@ static int is_bad_interface_name(char *i) {
 return 0;
 }
 
+/* none of these errors are expected, so I think it is OK to print them */
+static char *get_interface_for_default_route(int ipv6) {
+#ifdef __linux__
+pid_t pid;
+int fds[2];
+int r;
+char buf[4096];
+char *p, *q;
+
+r = pipe2(fds, O_CLOEXEC);
+if (r < 0) {
+fprintf(stderr, "get_interface_for_default_ipv4_route: pipe() failed: 
%s, continuing...", strerror(r));
+return NULL;
+}
+pid = fork();
+if (pid < 0) {
+fprintf(stderr, "get_interface_for_default_ipv4_route: fork() failed: 
%s, continuing...", strerror(r));
+return NULL;
+} else if (pid == 0) {
+/* child */
+r = dup2(fds[0], STDOUT_FILENO);
+if (r < 0) {
+char buf[1] = {'\n'};
+
+/* we have to write something as the other end is expecting 
something */
+r = write(fds[0], , sizeof(buf));
+_exit(EXIT_FAILURE);
+}
+
+if (ipv6)
+execlp("ip", "-6", "route", NULL);
+else
+execlp("ip", "route", NULL);
+char buf[1] = {'\n'};
+
+/* we have to write something as the other end is expecting something 
*/
+r = write(fds[0], , sizeof(buf));
+_exit(EXIT_FAILURE);
+}
+/* parent */
+close(fds[1]);
+r = read(fds[1], , sizeof(buf));
+if (r < 0) {
+fprintf(stderr, "get_interface_for_default_ipv4_route: read() failed: 
%s, continuing...", strerror(r));
+return NULL;
+}
+
+p = strstr((char *), "default via ");
+if (!p)
+return NULL;
+p += strlen("default via ");
+q = p;
+for (;*p != '\n' && *p; p++)
+;
+*p = '\0';
+p = strstr(q, " dev ");
+if (!p)
+return NULL;
+p += strlen(" dev ");
+q = p;
+for (;*p != ' ' && *p; p++)
+;
+*p = '\0';
+return xstrdup(q);
+#else
+return NULL;
+#endif
+}
+
 /* This finds the first interface which is up and is not the loopback
  * interface or one of the interface types listed in bad_interface_names. */
 static char *get_first_interface(void) {
@@ -123,9 +197,16 @@ static char *get_first_interface(void) {
 
 void options_set_defaults() {
 char *s;
+
+if (!options.interface) /* IPv4. Must come first because iftop does not 
work with v4tunnels.
+
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901283 */
+options.interface = get_interface_for_default_route(0);
+if (!options.interface) /* IPv6*/
+options.interface = get_interface_for_default_route(1);
 /* Should go through the list of interfaces, and find the first one which
  * is up and is not lo or dummy*. */
-options.interface = get_first_interface();
+if (!options.interface)
+options.interface = get_first_interface();
 if (!options.interface)
 options.interface = "eth0";
 
-- 
2.17.1



Bug#901283: iftop: v4tunnel support (IPv6 tunnels like Hurricane Electric)

2018-06-10 Thread Shawn Landden
Package: iftop
Version: 1.0~pre4-4
Followup-For: Bug #901283


Dear Maintainer,

submitted upstream: https://github.com/the-tcpdump-group/libpcap/issues/725

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

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

Versions of packages iftop depends on:
ii  libc62.24-11+deb9u3
ii  libncurses5  6.0+20161126-1+deb9u2
ii  libpcap0.8   1.8.1-3
ii  libtinfo56.0+20161126-1+deb9u2

iftop recommends no packages.

iftop suggests no packages.

-- no debconf information



Bug#644998: iftop: chooses eth0 as the default interface instead of the default route

2018-06-10 Thread Shawn Landden
>
> Here is a patch to fix the problem.
>

 This will make iftop (soft) depend on "iproute2"


Bug#644998: iftop: chooses eth0 as the default interface instead of the default route

2018-06-10 Thread Shawn Landden
Package: iftop
Version: 1.0~pre4-4
Followup-For: Bug #644998

tags 644998 patch

Dear Maintainer,

Here is a patch to fix the problem.

submitted upstream: 
http://lists.beasts.org/pipermail/iftop-users/2018-June/000472.html

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

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

Versions of packages iftop depends on:
ii  libc62.24-11+deb9u3
ii  libncurses5  6.0+20161126-1+deb9u2
ii  libpcap0.8   1.8.1-3
ii  libtinfo56.0+20161126-1+deb9u2

iftop recommends no packages.

iftop suggests no packages.

-- no debconf information
>From cdc0e3de74f529ff7c1fbc5648a9b09d1ada998a Mon Sep 17 00:00:00 2001
From: Shawn Landden 
Date: Sun, 10 Jun 2018 18:33:56 -0700
Subject: [PATCH] options: select interface that is IPv4 default route (Closes:
 #644998)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644998
---
 options.c | 77 ++-
 1 file changed, 76 insertions(+), 1 deletion(-)

diff --git a/options.c b/options.c
index a075357..efff2c7 100644
--- a/options.c
+++ b/options.c
@@ -6,8 +6,13 @@
 
 #include "config.h"
 
+#ifdef __linux__
+#define _GNU_SOURCE
+#endif
+
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -90,6 +95,72 @@ static int is_bad_interface_name(char *i) {
 return 0;
 }
 
+/* none of these errors are expected, so I think it is OK to print them */
+static char *get_interface_for_default_ipv4_route(void) {
+#ifdef __linux__
+pid_t pid;
+int fds[2];
+int r;
+char buf[4096];
+char *p, *q;
+
+r = pipe2(fds, O_CLOEXEC);
+if (r < 0) {
+fprintf(stderr, "get_interface_for_default_ipv4_route: pipe() failed: 
%s, continuing...", strerror(r));
+return NULL;
+}
+pid = fork();
+if (pid < 0) {
+fprintf(stderr, "get_interface_for_default_ipv4_route: fork() failed: 
%s, continuing...", strerror(r));
+return NULL;
+} else if (pid == 0) {
+/* child */
+r = dup2(fds[0], STDOUT_FILENO);
+if (r < 0) {
+char buf[1] = {'\n'};
+
+/* we have to write something as the other end is expecting 
something */
+r = write(fds[0], , sizeof(buf));
+_exit(EXIT_FAILURE);
+}
+
+execlp("ip", /* add "-6", here to make default IPv6 route */ "route", 
NULL);
+char buf[1] = {'\n'};
+
+/* we have to write something as the other end is expecting something 
*/
+r = write(fds[0], , sizeof(buf));
+_exit(EXIT_FAILURE);
+}
+/* parent */
+close(fds[1]);
+r = read(fds[1], , sizeof(buf));
+if (r < 0) {
+fprintf(stderr, "get_interface_for_default_ipv4_route: read() failed: 
%s, continuing...", strerror(r));
+return NULL;
+}
+
+p = strstr((char *), "default via ");
+if (!p)
+return NULL;
+p += strlen("default via ");
+q = p;
+for (;*p != '\n' && *p; p++)
+;
+*p = '\0';
+p = strstr(q, " dev ");
+if (!p)
+return NULL;
+p += strlen(" dev ");
+q = p;
+for (;*p != ' ' && *p; p++)
+;
+*p = '\0';
+return xstrdup(q);
+#else
+return NULL;
+#endif
+}
+
 /* This finds the first interface which is up and is not the loopback
  * interface or one of the interface types listed in bad_interface_names. */
 static char *get_first_interface(void) {
@@ -123,9 +194,13 @@ static char *get_first_interface(void) {
 
 void options_set_defaults() {
 char *s;
+
+if (!options.interface)
+options.interface = get_interface_for_default_ipv4_route();
 /* Should go through the list of interfaces, and find the first one which
  * is up and is not lo or dummy*. */
-options.interface = get_first_interface();
+if (!options.interface)
+options.interface = get_first_interface();
 if (!options.interface)
 options.interface = "eth0";
 
-- 
2.17.1



Bug#901283: iftop: v4tunnel support (IPv6 tunnels like Hurricane Electric)

2018-06-10 Thread Shawn Landden
Package: iftop
Version: 1.0~pre4-4
Severity: wishlist

Dear Maintainer,

It would be nice if you could attach iftop to v4tunnels. Instead iftop
reports nothing for such interfaces, and reports the traffic under the ipv4 
interface
as a single connection to the ipv4 end of the tunnel. Here is my 
/etc/network/interfaces:

 auto lo
  iface lo inet loopback

 auto eth0
  iface eth0 inet static
   address 198.46.198.198
   gateway 198.46.198.1
   netmask 255.255.255.0
   dns-nameservers 8.8.8.8 8.8.4.4

iface he-ipv6 inet6 v4tunnel
address 2001:470:c:238::2
netmask 64
#LA 0.5ms
endpoint 66.220.18.42
local 198.46.198.198
ttl 255
gateway 2001:470:c:238::1
up ip addr add 2001:470:d:238::1 dev he-ipv6

Thanks,

Shawn Landden

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

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

Versions of packages iftop depends on:
ii  libc62.24-11+deb9u3
ii  libncurses5  6.0+20161126-1+deb9u2
ii  libpcap0.8   1.8.1-3
ii  libtinfo56.0+20161126-1+deb9u2

iftop recommends no packages.

iftop suggests no packages.

-- no debconf information



Bug#881692: command-not-found: I re-wrote command-not-found

2018-05-10 Thread Shawn Landden
I re-wrote command-not-found in C. It consists of two C programs:
command-not-found, which gets triggered by bash, and
update-command-not-found, which digests the data obtained with apt-file
update.

AFAIK there is only one rough edge, in that the parsing of
/etc/apt/sources.list is not the same as apt's parsing. I do not know
enough C++ to use libapt to do this.

https://github.com/shawnl/command-not-found/

-Shawn Landden


Bug#895681: RFS: arc/5.21q-6

2018-04-14 Thread Shawn Jefferds
unsubscribe

On Sat, Apr 14, 2018 at 7:19 AM, Ricardo  wrote:

> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
> I am looking for a sponsor for my package "arc"
>
> * Package name: arc
>   Version : 5.21q-6
>   Upstream Author : Howard Chu 
> * URL : http://sf.net/projects/arc
> * License : gpl2
>   Section : utils
>
> It builds those binary packages:
>   arc   - Archive utility based on the MSDOS ARC program
>
> To access further information about this package, please visit the
> following URL:
> https://mentors.debian.net/package/arc
>
> Alternatively, one can download the package with dget using this command:
>   dget -x https://mentors.debian.net/debian/pool/main/a/arc/arc_5.
> 21q-6.dsc
>
> Changes since the last upload:
>
>   * QA upload.
>   * Bump dhlevel to 11.
>
> I checked the https://www.debian.org/doc/packaging-manuals/upgrading-
> checklist.txt and no change appear to be necessary.
>
> Regards,
> Ricardo Fantin da Costa
>



-- 
Shawn85206
canemarden...@shawn85206.com
Noli fovere canem ardentum


Bug#892973: distcc: new upstream version (3.3)

2018-03-14 Thread Shawn Landden
Package: distcc
Severity: wishlist

Dear Maintainer,

I recently released version 3.3 of distcc.

Among other things, it features a fix of CVE 2004-2687. (github issue #155)

https://github.com/distcc/distcc

Please package it.

-Shawn Landden

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

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

Versions of packages distcc depends on:
ii  adduser3.117
ii  debconf [debconf-2.0]  1.5.65
ii  libavahi-client3   0.7-3.1
ii  libavahi-common3   0.7-3.1
ii  libc6  2.26-6
ii  libpopt0   1.16-10+b2
ii  lsb-base   9.20170808
ii  netbase5.4

distcc recommends no packages.

Versions of packages distcc suggests:
pn  ccache   
ii  dbus 1.12.4-1
pn  distcc-pump  
ii  distccmon-gnome  3.1-6.3
pn  dmucs



Bug#884876: /usr/bin/zstd: statically linked against libzstd while depending on it

2017-12-20 Thread Shawn Landden
Package: zstd
Version: 1.3.2+dfsg2-1
Severity: normal
File: /usr/bin/zstd

Dear Maintainer,

shawn@t410s:~/git/distcc/build$ apt show zstd | grep libzstd
Source: libzstd
Depends: libzstd1 (= 1.3.2+dfsg2-1), libc6 (>= 2.17), libgcc1 (>= 1:3.0), 
libstdc++6 (>= 6)
shawn@t410s:~/git/distcc/build$ ldd /usr/bin/zstd
linux-vdso.so.1 (0x7fff63b89000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fea7539a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fea74ff7000)
/lib64/ld-linux-x86-64.so.2 (0x7fea75833000)

either use shared linking (-DZSTD_BUILD_STATIC:BOOL=OFF) or do not depend on 
libzstd1

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

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

Versions of packages zstd depends on:
ii  libc6   2.25-5
ii  libgcc1 1:7.2.0-18
ii  libstdc++6  7.2.0-18
ii  libzstd11.3.2+dfsg2-1

zstd recommends no packages.

zstd suggests no packages.

-- no debconf information



Bug#882974: /usr/bin/lz4: Statically linked against liblz4-1

2017-11-28 Thread Shawn Landden
Package: lz4
Version: 1.8.0-1
Severity: normal
File: /usr/bin/lz4

Dear Maintainer,

shawn@t410s:~/git/distcc$ ldd /usr/bin/lz4
linux-vdso.so.1 (0x7ffe687fe000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fcc45561000)
/lib64/ld-linux-x86-64.so.2 (0x7fcc45b23000)

(same for lz4c)

yet:
Depends: libc6 (>= 2.14), liblz4-1 (= 1.8.0-1)

to build lz4 with shared liblz4.so.1 use cmake

cd contrib/cmake_unofficial
BUILD_SHARED_LIBS=1 cmake .
make -j

Makes the binaries half the size.

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

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

Versions of packages lz4 depends on:
ii  libc6 2.25-2
ii  liblz4-1  1.8.0-1

lz4 recommends no packages.

lz4 suggests no packages.

-- no debconf information



Bug#881692: command-not-found: I re-wrote command-not-found

2017-11-25 Thread Shawn Landden
On Mon, Nov 13, 2017 at 11:50 PM, Julian Andres Klode <j...@debian.org> wrote:
> (forwarding this to ubuntu-devel-discuss and Zygmunt)
>
> On Mon, Nov 13, 2017 at 10:33:39PM -0800, Shawn Landden wrote:
>> Package: command-not-found
>> Severity: wishlist
>>
>> I re-wrote command-not-found to get rid of the python dependancy, and
>> to reduce the database size, as to reduce memory usage.
>>
>> https://github.com/shawnl/command-not-found
>>
>> I was preparing to upload it to mentors as command-not-found-ng
>
> I also rewrote it years ago, but using the same database format,
> just in C. It was a lot faster. I don't understand the memory usage
> bit - it should not matter how large the database is, it's memory
> mapped, and not read into memory, as such memory usage should be
> roughly constant.
>
> Questions/Comments for your approach:
>
> * Did you test your format on a slow HDD with caches dropped? It
>   must not be slower than the Python one (that one is way too slow
>   already) - I did, it seems to be faster (0.4 vs 0.68 seconds)
>   - I believe the database-based C rewrite was even much faster,
>   though.
I switched it to mmap() and am now getting 0.27-0.45 with caches
dropped, even after adding translations. It is 100% C and sh. (same
postinst and postrm)

Ping.



Bug#881692: command-not-found: I re-wrote command-not-found

2017-11-17 Thread Shawn Landden
>
>
> Ruby is just a major no go.

Re-written in C.

And in the future, what about Lua? It is only 300KB.

> At that system level, the best choices
> are Perl, Shell, and C++. Maybe Python (on Ubuntu it's in ubuntu-minimal,
> but in Debian it's only used by standard priority and less, perl on the
> other hand is required and essential). Ruby has the lowest priority
> - optional.
>
> --
> Debian Developer - deb.li/jak | jak-linux.org - free software dev
> Ubuntu Core Developer  de, en speaker
>


Bug#881692: command-not-found: I re-wrote command-not-found

2017-11-16 Thread Shawn Landden
On Thu, Nov 16, 2017 at 11:39 PM, Xen  wrote:

> Julian Andres Klode schreef op 14-11-2017 8:50:
>
> * You should not depend on grep, sed, coreutils, they are Essential.
>>
>
> Can I ask what this means?
>
> I actually assume that these dependencies are not *required*, not that you
> can't use the tools.

Required: yes. The highest priority. sysvinit was Required: yes until
systemd came along https://www.debian.org/doc/debian-policy/#priorities

Speaking of, I can't use 'apt-get indextargets' from shell and had to
rewrite in ruby, because sed doesn't not support lazy matching, and I don't
know how else to match NOT \n\n. (it also doesn't seem to support multiples
of submatches.) Old regular expression implementations are showing their
age (not to mention perl's non-regular features).


Bug#881692: command-not-found: I re-wrote command-not-found

2017-11-16 Thread Shawn Landden
On Thu, Nov 16, 2017 at 6:44 PM, Colin Watson <cjwat...@ubuntu.com> wrote:

> On Thu, Nov 16, 2017 at 05:10:19PM -0800, Shawn Landden wrote:
> > On Mon, Nov 13, 2017 at 11:50 PM, Julian Andres Klode <j...@debian.org>
> > wrote:
> > > * It needs to be translated - also very important.
> >
> > I made a pot file and used translations from the python version, but I
> > can't get my app to look for translations (as examined through strace). I
> > read the gettext manual and do not know what I am doing wrong.
>
> Looking at
> https://github.com/shawnl/command-not-found/blob/master/
> command-not-found.c,
> your problem appears to be that you aren't calling setlocale().  You
> should normally call this before calling bindtextdomain() and
> textdomain():
>
>   setlocale(LC_ALL, "");
>
> (The gettext manual does cover this, but possibly you were looking at
> some different bit of it.)
>
Managed to re-use all the translations from launchpad of the existing
command-not-found.

>
> --
> Colin Watson   [cjwat...@ubuntu.com]
>


Bug#881692: command-not-found: I re-wrote command-not-found

2017-11-16 Thread Shawn Landden
> * Did you test your format on a slow HDD with caches dropped? It
>>   must not be slower than the Python one (that one is way too slow
>>   already) - I did, it seems to be faster (0.4 vs 0.68 seconds)
>>   - I believe the database-based C rewrite was even much faster,
>>   though
>>
> I tested with kyotocabinet backend and it was slower with dropped caches
on a hard drive (1 second), which is the slow case I am most concerned
with. Small  makes a difference. The code is at
https://github.com/shawnl/command-not-found/tree/kyotocabinet


Bug#881692: command-not-found: I re-wrote command-not-found

2017-11-16 Thread Shawn Landden
On Mon, Nov 13, 2017 at 11:50 PM, Julian Andres Klode <j...@debian.org>
wrote:

> (forwarding this to ubuntu-devel-discuss and Zygmunt)
>
> On Mon, Nov 13, 2017 at 10:33:39PM -0800, Shawn Landden wrote:
> > Package: command-not-found
> > Severity: wishlist
> >
> > I re-wrote command-not-found to get rid of the python dependancy, and
> > to reduce the database size, as to reduce memory usage.
> >
> > https://github.com/shawnl/command-not-found
> >
> > I was preparing to upload it to mentors as command-not-found-ng
>
> I also rewrote it years ago, but using the same database format,
> just in C. It was a lot faster. I don't understand the memory usage
> bit - it should not matter how large the database is, it's memory
> mapped, and not read into memory, as such memory usage should be
> roughly constant.
>
>
Questions/Comments for your approach:
>
> * Did you test your format on a slow HDD with caches dropped? It
>   must not be slower than the Python one (that one is way too slow
>   already) - I did, it seems to be faster (0.4 vs 0.68 seconds)
>   - I believe the database-based C rewrite was even much faster,
>   though.
>
Yes, as the disk IO is all the time, I think its best to keep the file size
small. Then it has more chance of staying in memory.

> * update-command-not-found should use apt-get indextargets
>
fixed

> * You don't store components, hence you cannot tell people to enable
>   component. That's a very important use case for Ubuntu, where
>   not all components are enabled by default, but the database is
>   shipped in the package.
>
>   You could just append / to each package name I think,
>   and strip it away when displaying.
>
fixed

> * You should use getopt_long() to parse command-line options, and
>   support -h, --help :)
>
fixed

> * pts_lbsearch belongs into usr/lib/..., not usr/share/...
>
the seperate binary is gone

>
> * You don't implement a closest matches function:
>
> $ command-not-found thunderbrd
> No command 'thunderbrd' found, did you mean:
>  Command 'thunderbird' from package 'thunderbird' (main)
> thunderbrd: command not found
> $ ./command-not-found thunderbrd
> thunderbrd: command not found
>
>This one is really important. People do make typos or misremember
>command names, so the tool needs to be able to deal with that
>
>Should be easy to implement though, although you might have to
>search multiple times - once for each alternative. All you need is
>
> def similar_words(word):
> """ return a set with spelling1 distance alternative spellings
>
> based on http://norvig.com/spell-correct.html"";
> alphabet = 'abcdefghijklmnopqrstuvwxyz-_'
> s = [(word[:i], word[i:]) for i in range(len(word) + 1)]
> deletes= [a + b[1:] for a, b in s if b]
> transposes = [a + b[1] + b[0] + b[2:] for a, b in s if
> len(b)>1]
> replaces   = [a + c + b[1:] for a, b in s for c in alphabet if
> b]
> inserts= [a + c + b for a, b in s for c in alphabet]
> return set(deletes + transposes + replaces + inserts)
>
> And search for what that returns. And you don't need to search for
> those
> at all if you have a direct match.
>
> fixed, and I believe bit-for-bit identical

> * It needs to be translated - also very important.
>
I made a pot file and used translations from the python version, but I
can't get my app to look for translations (as examined through strace). I
read the gettext manual and do not know what I am doing wrong.

>
> * You need to Conflict with command-not-found and not Break AFAIUI
>
> fixed

> * You should not depend on grep, sed, coreutils, they are Essential.
>
> fixed, now it uses ruby as my shell was hacky.

> * You do have to Depend on apt-file, as that configures apt to download
>   the Contents files
>
> fixed

> * You should not have identifiers starting with _ in the program, these
>   are reserved for the C implementation (like _cleanup_free_).
>
> fixed

> Yes, and these are basically the same reasons my C prototype is
> not in the archive. Also, I did not put a lot of work into it, as
> I was waiting for PackageKit to take that over, but that was not
> done yet.
>
> I think it's a worthwhile approach, and I can see it replacing
> command-not-found if those tiny issues have been fixed. Then you
> could also avoid the -ng moniker, and just take over the main
> package (if Zygmunt does not mind), which also avoids a month
> long NEW process :)
>
> --
> Debian Developer - deb.li/jak | jak-linux.org - free software dev
> Ubuntu Core Developer  de, en speaker
>


Bug#881692: command-not-found: I re-wrote command-not-found

2017-11-14 Thread Shawn Landden
On Nov 14, 2017 8:15 AM, "Julian Andres Klode"  wrote:

On Tue, Nov 14, 2017 at 03:35:02PM +, John Lenton wrote:
> On 14 November 2017 at 12:34, Julian Andres Klode  wrote:
> > On Tue, Nov 14, 2017 at 01:00:54PM +0100, Zygmunt Krynicki wrote:
> >> I would love if we have a compact representation of mapping from name
> >> to list of bits of information where each bit can be a small structure
> >> with some data. Apart from components for ubuntu archive it could be
> >> used to store facts about snap packages, flatpaks, etc. I would try to
> >> avoid a simplistic command -> package mapping as that will force us to
> >> encode things into strings in an ad-hoc way.
> >
> > That makes sense to me. But then we're back on a db, I guess. I sort
> > like this minimal approach.
>
> I was thinking in the other direction, was going to see how it behaved
> with sqlite as the store. Would that be objectionable?

Using a relational database for a simple key -> structure mapping seems
overkill and a mismatch for the problem, and the SQL does not make it
more readable.

I'd play with lmdb and kyotocabinet, these are two high-performance
key-value file databases and then encode a structure as mentioned
before.

I had some kyotocabinet code, (i maintain that package, which btw is in
mentors) but this way is at least half the size. (Kyotocabinet is 1mb and
it almost doubles the size of the db, even using lower overhead b-tree back
end. These entries are just very small.

For the text file approach, we can even go human, readable, like git:

git just encodes a number in a fixed-length decimal number, we can do
the same, and then just encode (length, key), (length, data) pairs after
each other (or as mentioned, just use the "index" as the field id, and
store field ids in the progrma). Uses a bit more space, but encodes
everything in a format you could read with a text editor, and should
not be terribly less efficient.

The thing is: This needs to be as efficient as possible: it should
be below 100ms (or better 50ms), regardless of whether caches are dropped
or not.

Python code |   Shawn's code

SSD, cache  50ms5ms
SSD, " dropped 256ms   15ms
HDD, cache  50ms5ms
HDD, " dropped 530ms   15ms

I guess Shawn's code could even be improved in performance by
avoiding the subprocess execution, avoiding various ld cache
lookups and library loads.

I am going to have to bring it in process to add the spell check code.


That said, space requirements might matter too.
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
Ubuntu Core Developer  de, en speaker


Bug#881692: command-not-found: I re-wrote command-not-found

2017-11-13 Thread Shawn Landden
Oh, I forgot about the spelling feature

On Nov 13, 2017 22:36, "Shawn Landden" <sland...@gmail.com> wrote:

> Package: command-not-found
> Severity: wishlist
>
> I re-wrote command-not-found to get rid of the python dependancy, and
> to reduce the database size, as to reduce memory usage.
>
> https://github.com/shawnl/command-not-found
>
> I was preparing to upload it to mentors as command-not-found-ng
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, arm64, armhf
>
> Kernel: Linux 4.14.0-rc7-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
> LANGUAGE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages command-not-found depends on:
> ii  apt-file 3.1.5
> ii  lsb-release  9.20170808
> ii  python   2.7.14-1
> ii  python-gdbm  2.7.14-1
>
> command-not-found recommends no packages.
>
> command-not-found suggests no packages.
>


Bug#881692: command-not-found: I re-wrote command-not-found

2017-11-13 Thread Shawn Landden
close 881692
thanks

On Mon, Nov 13, 2017 at 10:53 PM, Shawn Landden <sland...@gmail.com> wrote:

> Oh, I forgot about the spelling feature
>
> On Nov 13, 2017 22:36, "Shawn Landden" <sland...@gmail.com> wrote:
>
>> Package: command-not-found
>> Severity: wishlist
>>
>> I re-wrote command-not-found to get rid of the python dependancy, and
>> to reduce the database size, as to reduce memory usage.
>>
>> https://github.com/shawnl/command-not-found
>>
>> I was preparing to upload it to mentors as command-not-found-ng
>>
>> closing as I forgot to code the spelling feature

> -- System Information:
>> Debian Release: buster/sid
>>   APT prefers unstable
>>   APT policy: (500, 'unstable'), (1, 'experimental')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386, arm64, armhf
>>
>> Kernel: Linux 4.14.0-rc7-amd64 (SMP w/4 CPU cores)
>> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
>> LANGUAGE=en_US.utf8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /usr/bin/dash
>> Init: systemd (via /run/systemd/system)
>>
>> Versions of packages command-not-found depends on:
>> ii  apt-file 3.1.5
>> ii  lsb-release  9.20170808
>> ii  python   2.7.14-1
>> ii  python-gdbm  2.7.14-1
>>
>> command-not-found recommends no packages.
>>
>> command-not-found suggests no packages.
>>
>


Bug#881692: command-not-found: I re-wrote command-not-found

2017-11-13 Thread Shawn Landden
Package: command-not-found
Severity: wishlist

I re-wrote command-not-found to get rid of the python dependancy, and
to reduce the database size, as to reduce memory usage.

https://github.com/shawnl/command-not-found

I was preparing to upload it to mentors as command-not-found-ng

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

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

Versions of packages command-not-found depends on:
ii  apt-file 3.1.5
ii  lsb-release  9.20170808
ii  python   2.7.14-1
ii  python-gdbm  2.7.14-1

command-not-found recommends no packages.

command-not-found suggests no packages.



Bug#880938: base-installer: must define _GNU_SOURCE for vasprintf in pkgdetails.c

2017-11-05 Thread Shawn Landden
Package: base-installer
Version: 1.171
Severity: important

in order to compile pkgdetails.c for debootstrap I had to add
#define _GNU_SOURCE

for vasprintf

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

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



Bug#880208: distcc: fails to start after last NMU if zeroconf enabled

2017-10-30 Thread Shawn Landden
Package: distcc
Version: 3.1-6.3
Severity: important

Oct 30 08:32:48 t410s systemd[1]: Starting LSB: simple distributed compiler 
server...
Oct 30 08:32:48 t410s distccd[28930]: ERROR: --zeroconf: unknown option
Oct 30 08:32:48 t410s distcc[28924]: Starting Distributed Compiler Daemon: 
distccd/etc/init.d/distcc: start failed with error code 101 ... (warning).
Oct 30 08:32:48 t410s distcc[28924]:  failed!

Appears that zeroconf support was inadvertantly disabled in the last upload.

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

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

Versions of packages distcc depends on:
ii  adduser3.116
ii  debconf [debconf-2.0]  1.5.64
ii  libc6  2.24-17
ii  libpopt0   1.16-10+b2
ii  lsb-base   9.20170808
ii  netbase5.4

distcc recommends no packages.

Versions of packages distcc suggests:
pn  ccache   
ii  dbus 1.11.22-1
pn  distcc-pump  
ii  distccmon-gnome  3.1-6.3
pn  dmucs

-- debconf information:
  distcc/daemon: true
  distcc/daemon-zeroconf: true
  distcc/daemon-jobs:
  distcc/daemon-allow: 10.0.0.0/8
  distcc/daemon-listen: 0.0.0.0
  distcc/daemon-nice: 10



Bug#879722: lintian: W-shlibs-symbol-not-found: false positive

2017-10-24 Thread Shawn Landden
Package: lintian
Version: 2.5.55
Severity: normal

dpkg-shlibdeps: warning: symbol __aeabi_atexit@CXXABI_ARM_1.3.3 used by 
debian/libkyotocabinet16v5/usr/lib/arm-linux-gnueabi/libkyotocabinet.so.16.13.0 
found in none of the libraries

dpkg-shlibdeps: warning: symbol __aeabi_atexit@CXXABI_ARM_1.3.3 used by 
debian/libkyotocabinet16v5/usr/lib/arm-linux-gnueabihf/libkyotocabinet.so.16.13.0
 found in none of the libraries

armel and armhf

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

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

Versions of packages lintian depends on:
ii  binutils  2.29.1-6
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.19.0.4
ii  file  1:5.32-1
ii  gettext   0.19.8.1-4
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.59-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.38-2+b2
ii  libdpkg-perl  1.19.0.4
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.0-8
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.72-2
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.63-2+b2
ii  man-db2.7.6.1-2
ii  patchutils0.3.4-2
ii  perl  5.26.0-8
ii  t1utils   1.40-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b4

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.19.0.4
ii  libhtml-parser-perl3.72-3+b2
pn  libtext-template-perl  

-- no debconf information



Bug#878938: kmail: crashes when filling in contact info from "recent contacts" in coposer

2017-10-22 Thread Shawn Sörbom
On Tuesday, October 17, 2017 12:37:57 PM PDT Shawn Sörbom wrote:
> Package: kmail
> Version: 4:16.04.3-4~deb9u1
> Severity: important
> 
> Dear Maintainer,
> 
> An abort() signal is thrown in kmail composer when filling in the "To:"
> field from the recent contacts drop-down menu, causing a crash. This only
> seems to happen with certain contacts. I have not been able to isolate what
> makes these contacts unique. Please contct me if you need more details.
> I have attatched a stacktrace.
> 
> Application: KMail (kmail), signal: Aborted
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [Current thread is 1 (Thread 0x7fe1edb12940 (LWP 10115))]
> 
> Thread 9 (Thread 0x7fe1d97ff700 (LWP 10127)):
> #0  0x7fff344bb949 in ?? ()
> #1  0x7fff344bbbd9 in clock_gettime ()
> #2  0x7fe20d317996 in clock_gettime () from
> /lib/x86_64-linux-gnu/libc.so.6 #3  0x7fe20dcae091 in qt_clock_gettime
> (ts=0x7fe1d97fe9e0, clock=) at
> tools/qelapsedtimer_unix.cpp:109 #4  do_gettime (frac=,
> sec=) at tools/qelapsedtimer_unix.cpp:164 #5  qt_gettime
> () at tools/qelapsedtimer_unix.cpp:173
> #6  0x7fe20de2ace9 in QTimerInfoList::updateCurrentTime
> (this=this@entry=0x7fe1c0002cd0) at kernel/qtimerinfo_unix.cpp:91 #7 
> 0x7fe20de2b295 in QTimerInfoList::timerWait (this=0x7fe1c0002cd0,
> tm=...) at kernel/qtimerinfo_unix.cpp:388 #8  0x7fe20de2c63e in
> timerSourcePrepareHelper (timeout=0x7fe1d97feab4, src=) at
> kernel/qeventdispatcher_glib.cpp:132 #9  timerSourcePrepare
> (source=, timeout=0x7fe1d97feab4) at
> kernel/qeventdispatcher_glib.cpp:165 #10 0x7fe201fd3edd in
> g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #11
> 0x7fe201fd491b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #12
> 0x7fe201fd4b0c in g_main_context_iteration () from
> /lib/x86_64-linux-gnu/libglib-2.0.so.0 #13 0x7fe20de2d06b in
> QEventDispatcherGlib::processEvents (this=0x7fe1c8c0, flags=...) at
> kernel/qeventdispatcher_glib.cpp:425 #14 0x7fe20ddd69ca in
> QEventLoop::exec (this=this@entry=0x7fe1d97fec80, flags=...,
> flags@entry=...) at kernel/qeventloop.cpp:212 #15 0x7fe20dc040f3 in
> QThread::exec (this=) at thread/qthread.cpp:507 #16
> 0x7fe20dc08da8 in QThreadPrivate::start (arg=0x55adf7955430) at
> thread/qthread_unix.cpp:368 #17 0x7fe203fa6494 in start_thread () from
> /lib/x86_64-linux-gnu/libpthread.so.0 #18 0x7fe20d30aaff in clone ()
> from /lib/x86_64-linux-gnu/libc.so.6
> 
> Thread 8 (Thread 0x7fe1daddf700 (LWP 10125)):
> #0  0x7fe20d2fd71d in read () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x7fe202018d40 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #2  0x7fe201fd44be in g_main_context_check () from
> /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3  0x7fe201fd4994 in ?? () from
> /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4  0x7fe201fd4b0c in
> g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 
> 0x7fe20de2d06b in QEventDispatcherGlib::processEvents
> (this=0x7fe1cc0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425 #6
>  0x7fe20ddd69ca in QEventLoop::exec (this=this@entry=0x7fe1daddec80,
> flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 #7 
> 0x7fe20dc040f3 in QThread::exec (this=) at
> thread/qthread.cpp:507 #8  0x7fe20dc08da8 in QThreadPrivate::start
> (arg=0x55adf785d990) at thread/qthread_unix.cpp:368 #9  0x7fe203fa6494
> in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #10
> 0x7fe20d30aaff in clone () from /lib/x86_64-linux-gnu/libc.so.6
> 
> Thread 7 (Thread 0x7fe1db7fe700 (LWP 10123)):
> #0  0x7fe20d3016ad in poll () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x7fe201fd49f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #2  0x7fe201fd4b0c in g_main_context_iteration () from
> /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3  0x7fe20de2d06b in
> QEventDispatcherGlib::processEvents (this=0x7fe1c80008c0, flags=...) at
> kernel/qeventdispatcher_glib.cpp:425 #4  0x7fe20ddd69ca in
> QEventLoop::exec (this=this@entry=0x7fe1db7fdc80, flags=...,
> flags@entry=...) at kernel/qeventloop.cpp:212 #5  0x7fe20dc040f3 in
> QThread::exec (this=) at thread/qthread.cpp:507 #6 
> 0x7fe20dc08da8 in QThreadPrivate::start (arg=0x55adf78876a0) at
> thread/qthread_unix.cpp:368 #7  0x7fe203fa6494 in start_thread () from
> /lib/x86_64-linux-gnu/libpthread.so.0 #8  0x7fe20d30aaff in clone ()
> from /lib/x86_64-linux-gnu/libc.so.6
> 
> Thread 6 (Thread 0x7fe1dbfff700 (LWP 10121)):
> #0  0x7fe20d2fd71d in read () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x7fe202018d40 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #2  0x0

Bug#879459: git: please build against openssl with OPENSSL_SHA1=1

2017-10-21 Thread Shawn Landden
tag 879459 wontfix
On Sat, Oct 21, 2017 at 1:33 PM, Anders Kaseorg  wrote:

> Git’s builtin SHA-1 implementation has the advantage of trying to detect
> attempted collisions (https://github.com/cr-marcstevens/
> sha1collisiondetection), which seems like good thing to do by default
> these days.
>
> Furthermore, Debian does not ship GPL code linked with OpenSSL for license
> reasons (https://lintian.debian.org/tags/possible-gpl-code-linked-
> with-openssl.html).
>
> the cryptograms parts of openssl are under BSD-3 (although 6aa36e8e5a0 was
confused and didn't notive this)

> Anders
>


Bug#879463: RM: kyototycoon -- ROM; not used, no longer wish to maintain

2017-10-21 Thread Shawn Landden
Package: ftp.debian.org
Severity: normal

I don't wish to maintain this package anymore.
Its popcon is low, and there is not much interest in it. (please let me know if
there is...)



Bug#879459: git: please build against openssl with OPENSSL_SHA1=1

2017-10-21 Thread Shawn Landden
Package: git
Version: 1:2.14.2-1
Severity: wishlist

Openssl's sha1 is much faster, ~25% even on this crusty 7 year old laptop. On 
new Intel and
all arm64 machines which have hardware acceleration openssl will be even more 
dramatically
faster.

shawn@t410s:~/git/git$ time git fsck
Checking object directories: 100% (256/256), done.
warning in tag d6602ec5194c87b0fc87103ca4d67251c76f233a: missingTaggerEntry: 
invalid format - expected 'tagger' line
Checking objects: 100% (235759/235759), done.
Checking connectivity: 234357, done.

real0m24.915s
user0m24.314s
sys 0m0.536s
shawn@t410s:~/git/git$ time ./git-fsck
Checking object directories: 100% (256/256), done.
warning in tag d6602ec5194c87b0fc87103ca4d67251c76f233a: missingTaggerEntry: 
invalid format - expected 'tagger' line
Checking objects: 100% (235759/235759), done.
Checking connectivity: 234357, done.

real0m21.264s
user0m20.695s
sys 0m0.548s




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

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 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 git depends on:
ii  git-man  1:2.14.2-1
ii  libc62.24-17
ii  libcurl3-gnutls  7.55.1-1
ii  liberror-perl0.17025-1
ii  libexpat12.2.3-1
ii  libpcre2-8-0 10.22-3
ii  perl 5.26.0-8
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages git recommends:
ii  less 481-2.1
ii  openssh-client [ssh-client]  1:7.6p1-2
ii  patch2.7.5-1+b2

Versions of packages git suggests:
ii  gettext-base  0.19.8.1-4
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-el
ii  git-email 1:2.14.2-1
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
pn  gitk  
pn  gitweb

-- no debconf information



Bug#878938: kmail: crashes when filling in contact info from "recent contacts" in coposer

2017-10-17 Thread Shawn Sörbom
Package: kmail
Version: 4:16.04.3-4~deb9u1
Severity: important

Dear Maintainer,

An abort() signal is thrown in kmail composer when filling in the "To:" field 
from the recent contacts drop-down menu, causing a crash.
This only seems to happen with certain contacts. I have not been able to 
isolate what makes these contacts unique. 
Please contct me if you need more details.
I have attatched a stacktrace.

Application: KMail (kmail), signal: Aborted
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fe1edb12940 (LWP 10115))]

Thread 9 (Thread 0x7fe1d97ff700 (LWP 10127)):
#0  0x7fff344bb949 in ?? ()
#1  0x7fff344bbbd9 in clock_gettime ()
#2  0x7fe20d317996 in clock_gettime () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x7fe20dcae091 in qt_clock_gettime (ts=0x7fe1d97fe9e0, clock=) at tools/qelapsedtimer_unix.cpp:109
#4  do_gettime (frac=, sec=) at 
tools/qelapsedtimer_unix.cpp:164
#5  qt_gettime () at tools/qelapsedtimer_unix.cpp:173
#6  0x7fe20de2ace9 in QTimerInfoList::updateCurrentTime 
(this=this@entry=0x7fe1c0002cd0) at kernel/qtimerinfo_unix.cpp:91
#7  0x7fe20de2b295 in QTimerInfoList::timerWait (this=0x7fe1c0002cd0, 
tm=...) at kernel/qtimerinfo_unix.cpp:388
#8  0x7fe20de2c63e in timerSourcePrepareHelper (timeout=0x7fe1d97feab4, 
src=) at kernel/qeventdispatcher_glib.cpp:132
#9  timerSourcePrepare (source=, timeout=0x7fe1d97feab4) at 
kernel/qeventdispatcher_glib.cpp:165
#10 0x7fe201fd3edd in g_main_context_prepare () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x7fe201fd491b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x7fe201fd4b0c in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x7fe20de2d06b in QEventDispatcherGlib::processEvents 
(this=0x7fe1c8c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425
#14 0x7fe20ddd69ca in QEventLoop::exec (this=this@entry=0x7fe1d97fec80, 
flags=..., flags@entry=...) at kernel/qeventloop.cpp:212
#15 0x7fe20dc040f3 in QThread::exec (this=) at 
thread/qthread.cpp:507
#16 0x7fe20dc08da8 in QThreadPrivate::start (arg=0x55adf7955430) at 
thread/qthread_unix.cpp:368
#17 0x7fe203fa6494 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#18 0x7fe20d30aaff in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 8 (Thread 0x7fe1daddf700 (LWP 10125)):
#0  0x7fe20d2fd71d in read () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fe202018d40 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fe201fd44be in g_main_context_check () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7fe201fd4994 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7fe201fd4b0c in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7fe20de2d06b in QEventDispatcherGlib::processEvents 
(this=0x7fe1cc0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425
#6  0x7fe20ddd69ca in QEventLoop::exec (this=this@entry=0x7fe1daddec80, 
flags=..., flags@entry=...) at kernel/qeventloop.cpp:212
#7  0x7fe20dc040f3 in QThread::exec (this=) at 
thread/qthread.cpp:507
#8  0x7fe20dc08da8 in QThreadPrivate::start (arg=0x55adf785d990) at 
thread/qthread_unix.cpp:368
#9  0x7fe203fa6494 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#10 0x7fe20d30aaff in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 7 (Thread 0x7fe1db7fe700 (LWP 10123)):
#0  0x7fe20d3016ad in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fe201fd49f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fe201fd4b0c in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7fe20de2d06b in QEventDispatcherGlib::processEvents 
(this=0x7fe1c80008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425
#4  0x7fe20ddd69ca in QEventLoop::exec (this=this@entry=0x7fe1db7fdc80, 
flags=..., flags@entry=...) at kernel/qeventloop.cpp:212
#5  0x7fe20dc040f3 in QThread::exec (this=) at 
thread/qthread.cpp:507
#6  0x7fe20dc08da8 in QThreadPrivate::start (arg=0x55adf78876a0) at 
thread/qthread_unix.cpp:368
#7  0x7fe203fa6494 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#8  0x7fe20d30aaff in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 6 (Thread 0x7fe1dbfff700 (LWP 10121)):
#0  0x7fe20d2fd71d in read () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fe202018d40 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fe201fd44be in g_main_context_check () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7fe201fd4994 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7fe201fd4b0c in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7fe20de2d06b in QEventDispatcherGlib::processEvents 
(this=0x7fe1d8c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425
#6  0x7fe20ddd69ca in QEventLoop::exec (this=this@entry=0x7fe1dbffec80, 

Bug#811628: Patch for kyototycoon FTBFS

2017-10-17 Thread Shawn Landden
On Sun, 6 Aug 2017 22:53:22 + "brian m. carlson" <
sand...@crustytoothpaste.net> wrote:
> tags 811628 + patch
> kthxbye
>
> Attached is a patch that makes kyotocabinet build (with warnings) with
> GCC 7.  I tried building it with CXX="g++ -std=c++03", but kyotocabinet
> uses nullptr, so that wasn't going to work.  I instead added the
> constexpr keyword which is now obligatory in C++ 11.
>
> I used "NULL" instead of nullptr because that was the existing style.
The lone "nullptr" was introduced in the gcc-7 NMU patch. When I get up and
running again
(no longer MIA) I will upload this.
> --
> brian m. carlson / brian with sandals: Houston, Texas, US
> https://www.crustytoothpaste.net/~bmc | My opinion only
> OpenPGP: https://keybase.io/bk2204


Bug#858408: /usr/bin/xrandr: Can no longer set 1920x1080 resolution manually

2017-03-21 Thread Shawn Sörbom
Package: x11-xserver-utils
Version: 7.7+7+b1
Severity: normal
File: /usr/bin/xrandr

Dear Maintainer,
I normally connect to my monitor via a passive DisplayPort to HDMI adapter. X 
sets my resolution to 1024x768 I suspect this is a quirk of the adapter, 
because despite this my monitor supports 1080p.  Normally I get around this by 
setting 1080p manually via the following script:

#!/bin/bash
output=`xrandr|grep primary|cut -d " " -f 1`
xrandr --newmode "1080p"  173.00  1920 2048 2248 2576  1080 1083 1088 1120 
-hsync +vsync
xrandr --addmode $output 1080p
xrandr --output $output --mode 1080p
kdialog --title "Resolution Changed" --passivepopup "Your screen resolution is 
now `xrandr  | grep \* | cut -d' ' -f4`"
-

This method worked until my last update 3 or four nights ago. Now, When I run 
the script, My monitor blinks off for a couple of seconds, but returns as 
1024x768 with no stdout output. any subsequent attempts to run the script 
produce the following output:

X Error of failed request:  BadName (named color or font does not exist)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  16 (RRCreateMode)
  Serial number of failed request:  40
  Current serial number in output stream:  40

My xrandr output afterwards is this:

Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
eDP-1 connected (normal left inverted right x axis y axis)
   1366x768  59.99 +  40.00  
   1360x768  59.8059.96  
   1024x768  60.0460.00  
   960x720   60.00  
   928x696   60.05  
   896x672   60.01  
   960x600   60.00  
   960x540   59.99  
   800x600   60.0060.3256.25  
   840x525   60.0159.88  
   800x512   60.17  
   700x525   59.98  
   640x512   60.02  
   720x450   59.89  
   640x480   60.0059.94  
   680x384   59.8059.96  
   576x432   60.06  
   512x384   60.00  
   400x300   60.3256.34  
   320x240   60.05  
DP-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
HDMI-2 disconnected (normal left inverted right x axis y axis)
DP-1-1 disconnected (normal left inverted right x axis y axis)
DP-1-2 connected primary 1024x768+0+0 (normal left inverted right x axis y 
axis) 0mm x 0mm
   1024x768  60.00* 
   800x600   60.3256.25  
   848x480   60.00  
   640x480   59.94  
   1080p 59.96  
DP-1-3 disconnected (normal left inverted right x axis y axis)  

Note: DP-1-2 is my primary monitor display, eDP1 is my inactive laptop screen. 
Note also that x added the 1080p line, but the refresh rate is wrong. attempts 
to switch to the 1080p modeline don't work. 

The bottom line is that I can no longer use 1080p at all on that display. Are 
there any workarounds I can try?


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

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

Versions of packages x11-xserver-utils depends on:
ii  cpp  4:6.3.0-1
ii  libc62.24-9
ii  libice6  2:1.0.9-2
ii  libx11-6 2:1.6.4-3
ii  libxaw7  2:1.0.13-1+b2
ii  libxcursor1  1:1.1.14-1+b4
ii  libxext6 2:1.3.3-1+b2
ii  libxi6   2:1.7.9-1
ii  libxmu6  2:1.1.2-2
ii  libxmuu1 2:1.1.2-2
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxt6   1:1.1.5-1
ii  libxxf86vm1  1:1.1.4-1+b2

x11-xserver-utils recommends no packages.

Versions of packages x11-xserver-utils suggests:
pn  cairo-5c
pn  nickle  
ii  xorg-docs-core  1:1.7.1-1

-- no debconf information



Bug#856251: quiterss: Quiterss immediately segfaults in kwin_wayland

2017-02-26 Thread Shawn Sörbom
Package: quiterss
Version: 0.18.4+dfsg-2
Severity: important

Dear Maintainer,

starting Quiterss in a kwin_wayland session immediately produces a segfault. 
This does not occur under Xorg. I have not run it inside a debugger yet. I hope 
to do this soon.
Thanks,
Shawn

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

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

Versions of packages quiterss depends on:
ii  libc6 2.24-9
ii  libgcc1   1:6.3.0-6
ii  libgl1-mesa-glx [libgl1]  13.0.4-1
ii  libqt5core5a  5.7.1+dfsg-3+b1
ii  libqt5gui55.7.1+dfsg-3+b1
ii  libqt5multimedia5 5.7.1~20161021-2
ii  libqt5network55.7.1+dfsg-3+b1
ii  libqt5printsupport5   5.7.1+dfsg-3+b1
ii  libqt5sql55.7.1+dfsg-3+b1
ii  libqt5sql5-sqlite 5.7.1+dfsg-3+b1
ii  libqt5webkit5 5.7.1+dfsg-1
ii  libqt5widgets55.7.1+dfsg-3+b1
ii  libqt5xml55.7.1+dfsg-3+b1
ii  libsqlite3-0  3.16.2-2
ii  libstdc++66.3.0-6

quiterss recommends no packages.

quiterss suggests no packages.

-- no debconf information



Bug#819684: Uurgent

2016-06-11 Thread Shawn Aceves
Not interested, thank you.

Shawn.

On Sat, Jun 11, 2016 at 6:36 PM, Tax_Defender <t...@bot.acer.com> wrote:

> Smile sk5aceves
>
> Solve Your Tax__Problems Now
> <http://blinkactive.net/RLI=53-UI=197004613-OI=1953-ONI=41691-SI=85383-CI=0-BI=0-II=60949-IDSP=1-KLEM=11-TIE=A-IDE=1056543-MID=491-FID=0-DIOM=0>
>


Bug#826179: ITP: open-tyrian -- Top-down futuristic fighter game

2016-06-03 Thread Shawn Sörbom
Oops, That is what I get for not tracking Unstable closely :-p . Sorry.
How do I manually close this bug?

On Friday, June 03, 2016 05:42:05 Alexandre Detiste wrote:
> Hi,
> 
> This game is already in the archive.
> 
> https://tracker.debian.org/pkg/opentyrian
> 
> Greets
> 
> Le Thursday 02 June 2016, 17:13:09 Shawn Sörbom a écrit :
> > Package: wnpp
> > Severity: wishlist
> > Owner: "Shawn Sörbom" <sh...@sorbom.com>
> > 
> > * Package name: open-tyrian
> > 
> >   Version : 2.1
> >   Upstream Author : The OpenTyrian Development Team
> > 
> > * URL : https://bitbucket.org/opentyrian/opentyrian/wiki/Home
> > * License : GPL-2
> > 
> >   Programming Lang: C
> >   Description : Top-down futuristic fighter game
> > 
> > Open Tyrian is a source port of the original Tyrian2000 (2.1) game.
> > It is a top-down arcade shooter where you pilot a spaceship to
> > various quadrants of the galaxy and destroy enemies.
> > 
> > More information is available on the upstream developers FAQ page:
> > https://bitbucket.org/opentyrian/opentyrian/wiki/FAQ



Bug#826179: ITP: open-tyrian -- Top-down futuristic fighter game

2016-06-02 Thread Shawn Sörbom
Package: wnpp
Severity: wishlist
Owner: "Shawn Sörbom" <sh...@sorbom.com>

* Package name: open-tyrian
  Version : 2.1
  Upstream Author : The OpenTyrian Development Team
* URL : https://bitbucket.org/opentyrian/opentyrian/wiki/Home
* License : GPL-2
  Programming Lang: C
  Description : Top-down futuristic fighter game

Open Tyrian is a source port of the original Tyrian2000 (2.1) game.
It is a top-down arcade shooter where you pilot a spaceship to
various quadrants of the galaxy and destroy enemies.

More information is available on the upstream developers FAQ page:
https://bitbucket.org/opentyrian/opentyrian/wiki/FAQ



Bug#807900: microhttpd: attempt at working with LFS blows

2015-12-14 Thread Shawn Landden
Package: libmicrohttpd-dev
Version: 0.9.44+dfsg-1+b1
Severity: important
File: microhttpd

MHD_create_response_from_fd_at_offset64()

and the deprecation of

MHD_create_response_from_fd_at_offset()

creates dependency hell which is unnecessary.
Can't you just test for sizeof(off_t) and sizeof(size_t)
and only issue a warning if they are different?

I'm sure there are some docs on glibc LFS support,
and how to do this better.

Not sure what systemd should do with the situation in the meantime.

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

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

Versions of packages libmicrohttpd-dev depends on:
ii  libgcrypt20-dev [libgcrypt-dev]  1.6.4-3
ii  libgnutls28-dev  3.3.18-1
ii  libmicrohttpd10  0.9.44+dfsg-1+b1

libmicrohttpd-dev recommends no packages.

libmicrohttpd-dev suggests no packages.

-- no debconf information



Bug#799593: kde-config-systemd FTBFS because of missed systemd build dependency

2015-10-03 Thread Shawn Sörbom
I have added your patch to my github repo. I have also contacted my sponsor 
and uploaded a fixed package. It should be available soon.
--Shawn

On Sunday, September 20, 2015 19:17:05 Alf Gaida wrote:
> Source: kde-config-systemd
> Severity: serious
> Tags: patch
> Justification: fails to build from source (but built successfully in the
> past)
> 
> Hi,
> building the package in pbuilder fails:
> -- checking for module 'systemd'
> --   package 'systemd' not found
> CMake Error at /usr/share/cmake-3.2/Modules/FindPkgConfig.cmake:340
> (message): A required package was not found
> Call Stack (most recent call first):
>   /usr/share/cmake-3.2/Modules/FindPkgConfig.cmake:502
> (_pkg_check_modules_internal) CMakeLists.txt:36 (pkg_check_modules)
> 
> Adding systemd to build dependencies solve this
> 
> Cheers Alf
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers buildd-unstable
>   APT policy: (990, 'buildd-unstable'), (990, 'unstable'), (500,
> 'experimental') Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.0.5-5-ck-amd64 (SMP w/4 CPU cores; PREEMPT)
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)



Bug#799593: kde-config-systemd FTBFS because of missed systemd build dependency

2015-09-28 Thread Shawn Sörbom
For some reason, I didn't see your bug until I got a removal request from 
testing. Sorry.
On Sunday, September 20, 2015 19:17:05 Alf Gaida wrote:
> Source: kde-config-systemd
> Severity: serious
> Tags: patch
> Justification: fails to build from source (but built successfully in the
> past)
> 
> Hi,
> building the package in pbuilder fails:
> -- checking for module 'systemd'
> --   package 'systemd' not found
> CMake Error at /usr/share/cmake-3.2/Modules/FindPkgConfig.cmake:340
> (message): A required package was not found
> Call Stack (most recent call first):
>   /usr/share/cmake-3.2/Modules/FindPkgConfig.cmake:502
> (_pkg_check_modules_internal) CMakeLists.txt:36 (pkg_check_modules)
> 
> Adding systemd to build dependencies solve this
> 
> Cheers Alf
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers buildd-unstable
>   APT policy: (990, 'buildd-unstable'), (990, 'unstable'), (500,
> 'experimental') Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.0.5-5-ck-amd64 (SMP w/4 CPU cores; PREEMPT)
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)



Bug#748737: [request-tracker-maintainers] Bug#748737: Bug#748737: Bug#748737: rt4-extension-assettracker: fails to upgrade from wheezy

2015-09-08 Thread Shawn Moore
Hi Jerome et al,

(Hi! I’m Shawn, one of the upstream engineers on Request Tracker)

> 2015/09/04 17:09、Jerome Charaoui <jer...@riseup.net> のメール:
> 
>>> Is this a good place to suggest Best Practical's own RT::Extension::Assets 
>>> (http://bestpractical.com/assets) as a candidate for packaging?
> 
> The recommended pratice is to submit an RFP [2].

The next major version of RT (4.4) will begin including what was 
RT::Extension::Assets as a core Assets feature, so it would certainly be 
easiest just to wait for that.

> Thanks,
> 
> — Jerome

Thanks,
Shawn


signature.asc
Description: Message signed with OpenPGP using GPGMail


Bug#796718: fprintd: does not quit, leaks memory

2015-08-23 Thread Shawn Landden
Package: fprintd
Version: 0.6.0-1
Severity: normal


Not exactly sure where this bug is, but somewhere in fingerprint authentication 
something isn't quiting
and every authentication leaks memory.
root   29765  0.0  0.1 284640  5280 ?Sl   Aug20   0:00 
gdm-session-worker [pam/gdm-password]
root   29767  0.0  0.1 263924  5028 ?Sl   Aug20   0:00 
gdm-session-worker [pam/gdm-fingerprint]
root   30202  0.0  0.1 284640  5312 ?Sl   Aug20   0:00 
gdm-session-worker [pam/gdm-password]
root   30204  0.0  0.1 263920  5132 ?Sl   Aug20   0:00 
gdm-session-worker [pam/gdm-fingerprint]
root   30438  0.0  0.1 284640  5452 ?Sl   Aug20   0:00 
gdm-session-worker [pam/gdm-password]
root   30442  0.0  0.1 263920  5068 ?Sl   Aug20   0:00 
gdm-session-worker [pam/gdm-fingerprint]
root   31524  0.0  0.1 284640  5316 ?Sl   Aug20   0:00 
gdm-session-worker [pam/gdm-password]
root   31525  0.0  0.1 263924  5136 ?Sl   Aug20   0:00 
gdm-session-worker [pam/gdm-fingerprint]
root   32072  0.0  0.1 284640  5324 ?Sl   Aug20   0:00 
gdm-session-worker [pam/gdm-password]
root   32077  0.0  0.1 263924  5056 ?Sl   Aug20   0:00 
gdm-session-worker [pam/gdm-fingerprint]
root   32189  0.0  0.1 284640  5324 ?Sl   Aug20   0:00 
gdm-session-worker [pam/gdm-password]
root   32192  0.0  0.1 263924  5124 ?Sl   Aug20   0:00 
gdm-session-worker [pam/gdm-fingerprint]
root   32281  0.0  0.1 284640  5260 ?Sl   Aug20   0:00 
gdm-session-worker [pam/gdm-password]
root   32283  0.0  0.1 263924  5052 ?Sl   Aug20   0:00 
gdm-session-worker [pam/gdm-fingerprint]
root   32656  0.0  0.1 284640  5328 ?Sl   Aug20   0:00 
gdm-session-worker [pam/gdm-password]
root   32658  0.0  0.1 263924  5112 ?Sl   Aug20   0:00 
gdm-session-worker [pam/gdm-fingerprint]
root   33774  0.0  0.1 284640  5440 ?Sl   Aug21   0:00 
gdm-session-worker [pam/gdm-password]
root   33775  0.0  0.1 263924  5112 ?Sl   Aug21   0:00 
gdm-session-worker [pam/gdm-fingerprint]
root   34128  0.0  0.2 284768  6912 ?Sl   Aug21   0:00 
gdm-session-worker [pam/gdm-password]
root   34129  0.0  0.2 263924  6752 ?Sl   Aug21   0:00 
gdm-session-worker [pam/gdm-fingerprint]
root   34931  0.0  0.2 284640  7100 ?Sl   Aug21   0:00 
gdm-session-worker [pam/gdm-password]
root   34936  0.0  0.2 263924  6720 ?Sl   Aug21   0:00 
gdm-session-worker [pam/gdm-fingerprint]
root   35644  0.0  0.2 284768  7536 ?Sl   Aug21   0:00 
gdm-session-worker [pam/gdm-password]
root   35648  0.0  0.2 263924  7280 ?Sl   Aug21   0:00 
gdm-session-worker [pam/gdm-fingerprint]
root   35876  0.0  0.2 284640  7564 ?Sl   Aug21   0:00 
gdm-session-worker [pam/gdm-password]
root   35879  0.0  0.2 263924  7200 ?Sl   Aug21   0:00 
gdm-session-worker [pam/gdm-fingerprint]
root   36130  0.0  0.2 284636  7724 ?Sl   Aug21   0:00 
gdm-session-worker [pam/gdm-password]
root   36132  0.0  0.2 263924  7296 ?Sl   Aug21   0:00 
gdm-session-worker [pam/gdm-fingerprint]
root   36665  0.0  0.2 284768  7660 ?Sl   Aug22   0:00 
gdm-session-worker [pam/gdm-password]
root   36668  0.0  0.2 263924  7268 ?Sl   Aug22   0:00 
gdm-session-worker [pam/gdm-fingerprint]
root   37110  0.0  0.2 263920  7348 ?Sl   Aug22   0:00 
gdm-session-worker [pam/gdm-fingerprint]
root   37130  0.0  0.2 284640  7532 ?Sl   Aug22   0:00 
gdm-session-worker [pam/gdm-password]
root   37134  0.0  0.2 263912  7360 ?Sl   Aug22   0:00 
gdm-session-worker [pam/gdm-fingerprint]
root   37394  0.0  0.2 284640  7532 ?Sl   Aug22   0:00 
gdm-session-worker [pam/gdm-password]
root   37397  0.0  0.2 263924  7244 ?Sl   Aug22   0:00 
gdm-session-worker [pam/gdm-fingerprint]
root   37738  0.0  0.2 284764  7616 ?Sl   Aug22   0:00 
gdm-session-worker [pam/gdm-password]
root   37741  0.0  0.2 263924  7364 ?Sl   Aug22   0:00 
gdm-session-worker [pam/gdm-fingerprint]


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

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

Versions of packages fprintd depends on:
ii  dbus   1.8.20-1
ii  libc6  2.19-19
ii  libdbus-1-31.8.20-1
ii  libdbus-glib-1-2   0.102-1
ii  libfprint0 1:0.6.0-2
ii  libglib2.0-0   2.44.1-1.1
ii  libpolkit-gobject-1-0  0.105-11
ii  policykit-10.105-11

fprintd recommends no packages.

fprintd suggests no packages.

-- no debconf 

Bug#792901: liferea: Does not gracefully install when /usr/share/doc is dpkg-excluded

2015-07-19 Thread Shawn Landden
Package: liferea
Version: 1.10.16-1
Severity: serious
Justification: Policy 12.3

rmdir: failed to remove ‘/usr/share/doc/liferea’: No such file or directory

you need to make this failure silent.

 Packages must not require the existence of any files in /usr/share/doc/ in 
order to function 
http://www.debian.org/doc/debian-policy/ch-docs.html

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

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

Versions of packages liferea depends on:
ii  dbus-x11 1.8.18-1
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gir1.2-gtk-3.0   3.16.5-1
ii  gir1.2-peas-1.0  1.12.1-2
ii  libatk1.0-0  2.16.0-2
ii  libc62.19-19
ii  libcairo21.14.2-2
ii  libgdk-pixbuf2.0-0   2.31.4-2
ii  libgirepository-1.0-11.44.0-1+b2
ii  libglib2.0-0 2.44.1-1.1
ii  libgtk-3-0   3.16.5-1
ii  libindicate5 0.6.92-2
ii  libjson-glib-1.0-0   1.0.4-1
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.36.8-3
ii  libpeas-1.0-01.12.1-2
ii  libsoup2.4-1 2.50.0-2
ii  libsqlite3-0 3.8.10.2-1
ii  libwebkitgtk-3.0-0   2.4.9-2
ii  libxml2  2.9.2+dfsg1-3
ii  libxslt1.1   1.1.28-2+b2
ii  liferea-data 1.10.16-1
ii  python-gi3.16.2-1
pn  python:any   none

Versions of packages liferea recommends:
ii  gir1.2-gnomekeyring-1.0  3.12.0-1+b1
ii  gnome-icon-theme 3.12.0-1
ii  gnome-keyring3.16.0-2
ii  steadyflow   0.2.0-1.1

Versions of packages liferea suggests:
ii  network-manager  1.0.2-2

-- 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#792165: hexchat: upgrading to 2.10.2 broke hexchat, downgrading did not fix

2015-07-12 Thread Shawn Landden
Package: hexchat
Version: 2.10.1-1
Severity: important

On the upgrade my servlist.conf got deleted and replaced by a super simple one:

v=2.10.2

N=New Network
F=19
D=0
S=newserver/6667



I'm kinda pissed.Should have at least renamed the existing one instead of 
truncating it.


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

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

Versions of packages hexchat depends on:
ii  hexchat-common   2.10.1-1
ii  libatk1.0-0  2.16.0-2
ii  libc62.19-18
ii  libcairo21.14.2-2
ii  libcanberra0 0.30-2.1
ii  libdbus-1-3  1.8.18-1
ii  libdbus-glib-1-2 0.102-1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.5.2-4
ii  libgdk-pixbuf2.0-0   2.31.4-2
ii  libglib2.0-0 2.44.1-1.1
ii  libgtk2.0-0  2.24.28-1
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  libpci3  1:3.2.1-3
ii  libperl5.20  5.20.2-6
ii  libproxy10.4.11-4+b2
ii  libpython2.7 2.7.10-3
ii  libssl1.0.0  1.0.2c-1

Versions of packages hexchat recommends:
ii  gvfs-bin  1.24.1-2+b1

Versions of packages hexchat suggests:
pn  unifont  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#791682: Bug in libruby2.1

2015-07-07 Thread Shawn Wallis
Package: libruby2.1

Version: 2.1.5-2+deb8u1

dpkg says libruby2.1 is version 2.1.5, but in
RbConfig::CONFIG['ruby_version'], and in /usr/lib/ruby/2.1.0, it says it is
version 2.1.0.

In /usr/lib/ruby/2.1.0/rubygems/defaults.rb, it is saying that
RbConfig::CONFIG['ruby_version'] is version '2.1.0'.


The problem, looking in '/usr/lib/ruby/2.1.0/rubygems/defaults.rb'.  It is
assigning my gempath to: Gem.user_home, '.gem', ruby_engine,
RbConfig::CONFIG['ruby_version'], and RbConfig::CONFIG['ruby_version'] is
equal to '2.1.0

 Now.  I have ruby 2.1.3, and my gempath is: /home/shawn/.gem/ruby/2.1.3'
because the package 'ruby2.1' is installing to ~/.gem/ruby/2.1.3.

Now why is there a /usr/lib/ruby/2.1.0 on my system saying my ruby version
is '2.1.0', and saying that my gempath is ~/.gem/ruby/2.1.0?

 /usr/lib/ruby/2.1.0 is coming from debian package 'libruby2.1', and my
debian package 'ruby2.1' is ruby 2.1.3, and actually installing the gems to
~/.gem/ruby/2.1.3.

uname -r:

 Linux shawnlaptop 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24)
 x86_64 GNU/Linux



Let me know if you have any questions, or if I made any mistakes.

Best,

Shawn


-- 
Courage, my friends; 'tis not too late to build a better world.
-Tommy Douglas


Bug#788305: hexchat: Import settings from XChat-2 option on first startup

2015-06-09 Thread Shawn Landden
Package: hexchat
Version: 2.10.2-1
Severity: minor

It would be really nice if this program allow the importation of XChat-2 
settings the first time it is run, 
if such settings exist. It is quite simple

cp ~/.xchat-2 ~/.config/hexchat
mv ~/.config/hexchat/xchat.conf ~/.config/hexchat/hexchat.conf

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

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

Versions of packages hexchat depends on:
ii  hexchat-common   2.10.2-1
ii  libatk1.0-0  2.16.0-2
ii  libc62.19-18
ii  libcairo21.14.2-2
ii  libcanberra0 0.30-2.1
ii  libdbus-1-3  1.8.18-1
ii  libdbus-glib-1-2 0.102-1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.5.2-4
ii  libgdk-pixbuf2.0-0   2.31.4-2
ii  libglib2.0-0 2.44.1-1
ii  libgtk2.0-0  2.24.28-1
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  libproxy10.4.11-4+b2
ii  libssl1.0.0  1.0.2a-1

Versions of packages hexchat recommends:
ii  gvfs-bin 1.24.1-2+b1
ii  hexchat-perl 2.10.2-1
ii  hexchat-plugins  2.10.2-1
ii  hexchat-python   2.10.2-1

Versions of packages hexchat suggests:
pn  unifont  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#786931: /usr/bin/ncal: Lunar calenders (Islam and Jewish)

2015-05-26 Thread Shawn Landden
Package: bsdmainutils
Version: 9.0.6
Severity: wishlist
File: /usr/bin/ncal
Tags: upstream

Dear Maintainer,

I was interested in adding support to cal/ncal for the Jewish and Islamic
lunar calenders (specifically the Umm al-Qura Islamic calender standardized in 
Saudi
Arabia), and as there is a fair bit of math involved, asking
if such a patch would be considered (with no guarantee) in advance.


Islamic calender

The days are purely lunar, with a year being exactly 12 moons. These moons 
are differn't
from a rotation of the Moon around the Earth, with details (look at the source) 
here:

http://www.staff.science.uu.nl/~gent0113/islam/ummalqura.htm

Jewish calender
---
A modified lunar calender, there is a leap month (Adar) entered according to the
metonic cycle. There are also some special leap day(s) rules discussed here:

https://en.wikipedia.org/wiki/Hebrew_calendar#Rosh_Hashanah_postponement

For current day calculation
---
Days in Judaism and Islam start at sunset. The user may either provide a 
latitude and longitude[1], or by default the coordinates of Jerusalem or Mekkah 
will be used,
respectfully. Existing timezones cannot be used (the latitude where that time 
would
be the mean solar time) because sunsetcalculations requie a latitude.
For days in with the artic or antartic circle in which the sun either does
not set or does not rise, solar midnight will be used (days are not 24 hours 
long).

Rounding errors
---
The solar declination calculation is subject quite a bit to rounding errors. 
When using
IEEE-754 64-bit the avr-libc library reports a 4.8 minute drift of solstice per 
year,
which becomes significant with the historical Jewish calender (but not the 
modern Islamic
calender). So if historical Jewish dates are desired, libquadmath should be 
used.

Liberty equality fraternity or death,

Shawn Landden

[1]Or, optionally, only a latitude (and get the longitude from the mean solar
time of the current timezone)?

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

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

Versions of packages bsdmainutils depends on:
ii  bsdutils 1:2.25.2-6
ii  debianutils  4.4+b1
ii  libc62.21-0experimental0
ii  libncurses5  5.9+20140913-1+b1
ii  libtinfo55.9+20140913-1+b1

bsdmainutils recommends no packages.

Versions of packages bsdmainutils suggests:
ii  cpp   4:5-3
pn  vacation  none
ii  wamerican [wordlist]  7.1-1
ii  whois 5.2.7

-- 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#784170: lxc-create depends on newuidmap/newgidmap for making unprivileged containers

2015-05-03 Thread Shawn Matthiessen
Package: lxc
Version: 1:1.0.6-6
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

lxc-create as unprivileged user depends on package uidmap but package
lxc does not list it as a dependency.

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

shawn@eeyore ~ % lxc-create -t download -n ubuntu -- -d ubuntu -r trusty -a
amd64

   * What was the outcome of this action?

lxc: Missing newuidmap/newgidmap
error mapping child
setgid: Invalid argument
lxc_container: Failed to chown container dir
lxc_container: Error creating container ubuntu



   * What outcome did you expect instead?

Setting up the GPG keyring
Downloading the image index
Downloading the rootfs
Downloading the metadata
The image cache is now ready
Unpacking the rootfs

---
You just created an Ubuntu container (release=trusty, arch=amd64,
variant=default)

To enable sshd, run: apt-get install openssh-server

For security reason, container images ship without user accounts
and without a root password.

Use lxc-attach or chroot directly into the rootfs to set a root password
or create user accounts.



-- System Information:
Debian Release: 8.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing'), (500, 'stable')
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
Init: systemd (via /run/systemd/system)

Versions of packages lxc depends on:
ii  init-system-helpers  1.22
ii  libapparmor1 2.9.0-3
ii  libc62.19-18
ii  libcap2  1:2.24-8
ii  libseccomp2  2.1.1-1
ii  libselinux1  2.3-2
ii  multiarch-support2.19-18
ii  python3  3.4.2-2

Versions of packages lxc recommends:
ii  debootstrap  1.0.67
ii  openssl  1.0.1k-3
ii  rsync3.1.1-3

Versions of packages lxc suggests:
pn  lua5.2  none

-- no debconf information


Bug#781757: Please apply upstream workaround for nvidia-driver background garbage on resume

2015-04-26 Thread Shawn Matthiessen
Hey guys,

Heres another link to the upstream fix:
https://git.gnome.org/browse/gnome-shell/commit/?h=gnome-3-14id=d19e78af2459b1b5165848b643525df29ee20265

I hope this can get cherry picked for 8.1


Until then, heres a workaround I wrote:
https://mail.google.com/mail/u/0/#inbox?compose=14cf87216630368b


Regards,


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



Bug#781757: Please apply upstream workaround for nvidia-driver background garbage on resume

2015-04-26 Thread Shawn Matthiessen
On Sun, 26 Apr 2015 18:17:19 -0700 Shawn Matthiessen shawnbon...@gmail.com
wrote:
 Hey guys,

 Heres another link to the upstream fix:
 https://git.gnome.org/browse/gnome-shell/commit/?h

Doh, somehow I botched that last link

Here's my workaround:

https://gist.githubusercontent.com/shawnbon206/3a451a7612084d9392cd/raw/c511dd741d46c083293ee712ac9040579b13d231/bg-fix.sh

It simply refreshes the wallpaper using gsettings


Bug#782428: Info received (Bug#782428: libattr1-dev: depends on glibc internals)

2015-04-12 Thread Shawn Landden
The acl problem was at my end, don't mind that. The patch is good.


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



Bug#782428: libattr1-dev: depends on glibc internals

2015-04-11 Thread Shawn Landden
Package: libattr1-dev
Version: 1:2.4.47-2
Severity: important
Tags: patch upstream

attr/xattr.h uses glibc internal declarations (__BEGIN_DECL and __THROW)
which means it can't be build for other libcs. Patch attached.

Thanks,

Shawn

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel, musl-linux-amd64

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

Versions of packages libattr1-dev depends on:
ii  libattr1  1:2.4.47-2
ii  libc6-dev [libc-dev]  2.21-0experimental0

libattr1-dev recommends no packages.

libattr1-dev 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#782428: libattr1-dev: depends on glibc internals

2015-04-11 Thread Shawn Landden
On Sat, Apr 11, 2015 at 08:36:27PM -0700, Shawn Landden wrote:
 Package: libattr1-dev
 Version: 1:2.4.47-2
 Severity: important
 Tags: patch upstream
 
 attr/xattr.h uses glibc internal declarations (__BEGIN_DECL and __THROW)
 which means it can't be build for other libcs. Patch attached.
Here is the patch:
--- a/include/xattr.h   2014-09-08 14:48:10.0 -0700
+++ b/include/xattr.h   2015-04-11 20:30:18.525078800 -0700
@@ -31,7 +31,13 @@
 #define XATTR_REPLACE 0x2   /* set value, fail if attr does not exist */
 
 
-__BEGIN_DECLS
+#ifndef __THROW
+# define __THROW
+#endif
+
+#ifdef __cplusplus
+extern C {
+#endif
 
 extern int setxattr (const char *__path, const char *__name,
  const void *__value, size_t __size, int __flags) __THROW;
@@ -58,6 +64,8 @@
 extern int lremovexattr (const char *__path, const char *__name) __THROW;
 extern int fremovexattr (int __filedes,   const char *__name) __THROW;
 
-__END_DECLS
+#ifdef __cplusplus
+}
+#endif
 
 #endif /* __XATTR_H__ */


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



Bug#782428: libattr1-dev: depends on glibc internals

2015-04-11 Thread Shawn Landden
On Sat, Apr 11, 2015 at 08:36:27PM -0700, Shawn Landden wrote:
 Package: libattr1-dev
 Version: 1:2.4.47-2
 Severity: important
 Tags: patch upstream
 
 attr/xattr.h uses glibc internal declarations (__BEGIN_DECL and __THROW)
 which means it can't be build for other libcs. Patch attached.
 
For some reason this is breaking acl's detection of attr/xattr.h?

I don't get it.


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



Bug#782039: dpkg-buildflags should ship CC variable for multi-arch cross-compiling, so that we can support clang

2015-04-08 Thread Shawn Landden
control -1 close
On Tue, Apr 07, 2015 at 04:47:59AM +0200, Guillem Jover wrote:
 Hi!
 
 On Mon, 2015-04-06 at 12:54:33 -0700, Shawn Landden wrote:
  Package: dpkg
  Version: 1.17.24
  Severity: wishlist
 
  clang is a native compiler, and so the gcc way of naming cross-compilers is 
  cumbersome as it would require the clang
  package to ship many symlinks. instead the architecture is listed with 
  -target
  CC=clang -target $(DEB_HOST_GNU_TYPE)
  
  Not all software uses autoconf, and also the autoconf auto-detection 
  doesn't work with musl-linux-(amd64|armhf|...),
  which doesn't require a differn't gcc, but simply a spec file.
 
 I think I'm quite confused by this report. How would having
 dpkg-buildflags support a CC variable (set to gcc) help when the user
 wants to use clang?
 
 If you want to use clang, then just do:
 
   $ CC=clang whatever dpkg-buildpackage
 
 what am I missing?
 
We talked about this, and what i'm proposing is still not a panacea. Closing.
 Thanks,
 Guillem


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



Bug#782099: liblzo2-dev: Do not depend on libc6-dev, please depend on libc-dev instead

2015-04-07 Thread Shawn Landden
Package: liblzo2-dev
Version: 2.08-1.2
Severity: normal

Or nothing as it is build-essential.

libc6-dev is unique to linux, even if the other glibc packages provide it, and 
will
not be provided in a potential musl port.

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

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

Versions of packages liblzo2-dev depends on:
ii  libc6-dev  2.21-0experimental0
ii  liblzo2-2  2.08-1.2

liblzo2-dev recommends no packages.

liblzo2-dev 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#782039: dpkg-buildflags should ship CC variable for multi-arch cross-compiling, so that we can support clang

2015-04-06 Thread Shawn Landden
Package: dpkg
Version: 1.17.24
Severity: wishlist

clang is a native compiler, and so the gcc way of naming cross-compilers is 
cumbersome as it would require the clang
package to ship many symlinks. instead the architecture is listed with -target
CC=clang -target $(DEB_HOST_GNU_TYPE)

Not all software uses autoconf, and also the autoconf auto-detection doesn't 
work with musl-linux-(amd64|armhf|...),
which doesn't require a differn't gcc, but simply a spec file.

Thanks,

Shawn
-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel, musl-linux-amd64

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-7+b3
ii  libc62.21-0experimental0
ii  liblzma5 5.1.1alpha+20120614-2+b3
ii  libselinux1  2.3-2
ii  tar  1.27.1-2+b1
ih  zlib1g   1:1.2.8.dfsg-2+b1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  1.1~exp8

-- 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#781489: criu: links against libprotobuf-c0 which it doesn't depend on

2015-03-30 Thread Shawn Landden
On Mon, Mar 30, 2015 at 07:52:03AM +0200, Salvatore Bonaccorso wrote:
 Control: tags -1 + moreinfo unreproducible
 
 Hi
 
 This does not look correct at first glance. criu/1.3.1-1 in
 jessie/unstable depends on libprotobuf-c1 (as well criu/1.4-1 in
 experimental). What does 
 
 apt-cache policy criu
Not a bug, built locally.

 
 shows?
 
 Regards,
 Salvatore


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



Bug#781489: criu: links against libprotobuf-c0 which it doesn't depend on

2015-03-30 Thread Shawn Landden
On Mon, Mar 30, 2015 at 07:52:03AM +0200, Salvatore Bonaccorso wrote:
 Control: tags -1 + moreinfo unreproducible
 
 Hi
 
 This does not look correct at first glance. criu/1.3.1-1 in
 jessie/unstable depends on libprotobuf-c1 (as well criu/1.4-1 in
 experimental). What does 
 
 apt-cache policy criu
sorry, I reinstalled and its fine, guess I compiled my own at one point.
 
 shows?
 
 Regards,
 Salvatore


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



Bug#781489: criu: links against libprotobuf-c0 which it doesn't depend on

2015-03-30 Thread Shawn Landden
Closing bug

On Mon, Mar 30, 2015 at 07:52:03AM +0200, Salvatore Bonaccorso wrote:
 Control: tags -1 + moreinfo unreproducible
 
 Hi
 
 This does not look correct at first glance. criu/1.3.1-1 in
 jessie/unstable depends on libprotobuf-c1 (as well criu/1.4-1 in
 experimental). What does 
 
 apt-cache policy criu
 
 shows?
 
 Regards,
 Salvatore


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



Bug#781047: libpcp3-dev: /usr/include/pcp/import.h missing

2015-03-23 Thread Shawn Landden
Package: libpcp3-dev
Version: 3.10.1
Severity: important

Dear Maintainer,

the package is not installing all the header files

please ship /usr/include/pcp/import.h

Thanks,

Shawn

While you are at it Multi-arch would be nice
-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages libpcp3-dev depends on:
ii  libc6-dev [libc-dev]  2.19-17
ii  libpcp3   3.10.1

libpcp3-dev recommends no packages.

libpcp3-dev 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#780744: miro: should Recommend: libavahi-compat-libdnssd1

2015-03-18 Thread Shawn Landden
Package: miro
Version: 6.0-1
Severity: normal

When starting miro without libavahi-compat-libdnssd1 installed it pops up a 
warning that it should be
installed to maximize functionality. Thus there should be a recommendation on 
this library.

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

Kernel: Linux 4.0.0-rc3-next-20150316 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages miro depends on:
ii  gstreamer0.10-plugins-bad   0.10.23-7.4
ii  gstreamer0.10-plugins-base  0.10.36-2
ii  gstreamer0.10-plugins-good  0.10.31-3+nmu4+b1
ii  gstreamer0.10-x 0.10.36-2
ii  libatk1.0-0 2.14.0-1
ii  libav-tools 6:11.3-1
ii  libavcodec566:11.3-1
ii  libavformat56   6:11.3-1
ii  libavutil54 6:11.3-1
ii  libc6   2.19-17
ii  libcairo2   1.14.0-2.1
ii  libfontconfig1  2.11.0-6.3
ii  libfreetype62.5.2-4
ii  libgcc1 1:5-20150307-1
ii  libgdk-pixbuf2.0-0  2.31.3-1
ii  libglib2.0-02.43.91-1
ii  libgtk2.0-0 2.24.25-3
ii  libjavascriptcoregtk-1.0-0  2.4.8-1
ii  libpango-1.0-0  1.36.8-3
ii  libpangocairo-1.0-0 1.36.8-3
ii  libpangoft2-1.0-0   1.36.8-3
ii  libsoup2.4-12.49.91.1-1
ii  libsqlite3-03.8.8.3-1
ii  libstdc++6  5-20150307-1
ii  libtag1c2a  1.9.1-2.1
ii  libwebkitgtk-1.0-0  2.4.8-1
ii  libx11-62:1.6.2-3
ii  miro-data   6.0-1
ii  python  2.7.8-4
ii  python-dbus 1.2.0-2+b3
ii  python-gconf2.28.1+dfsg-1.1
ii  python-glade2   2.24.0-4
ii  python-gst0.10  0.10.22-3
ii  python-gtk2 2.24.0-4
ii  python-libtorrent   0.16.18-1
ii  python-mutagen  1.25.1-1
ii  python-pycurl   7.19.5-3
ii  python-pysqlite22.6.3-3
ii  python-support  1.0.15
ii  python-webkit   1.1.8-3
ii  zlib1g  1:1.2.8.dfsg-2+b1

miro recommends no packages.

Versions of packages miro suggests:
pn  ffmpeg2theora   none
pn  gstreamer0.10-ffmpegnone
pn  gstreamer0.10-plugins-ugly  none
ii  libavahi-compat-libdnssd1   0.6.31-4+b2
ii  python-notify   0.1.1-4
pn  ttf-dejavu  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#780530: calendarserver: new version

2015-03-15 Thread Shawn Landden
Package: calendarserver
Version: 6.0+dfsg-1
Severity: normal

Dear Maintainer,

6.0 has been released. I have worked on packaging it a bit, but it is not 
complete:

git pull git://churchofgit.com/shawn/calendarserver


Thanks,

Shawn
---

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

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

Versions of packages calendarserver depends on:
ii  adduser3.113+nmu3
ii  lsb-base   4.1+Debian13+nmu1
ii  memcached  1.4.21-1.1
ii  python 2.7.8-4
ii  python-cffi0.8.6-1
ii  python-crypto  2.6.1-5+b2
ii  python-dateutil2.2-2
ii  python-kerberos1.1.5-0.1
ii  python-ldap2.4.10-1
ii  python-nevow   0.11.1-1
ii  python-openssl 0.14-1
ii  python-psutil  2.1.1-1+b1
ii  python-pyasn1  0.1.7-1
ii  python-pycalendar  2.0~svn13177-2
ii  python-pycparser   2.10+dfsg-3
ii  python-pygresql1:4.0-3.1
ii  python-setproctitle1.1.8-1
ii  python-sqlparse0.1.13-2
ii  python-twisted 14.0.2-3
ii  python-twisted-conch   1:14.0.2-3
ii  python-twisted-core14.0.2-3
ii  python-twisted-mail14.0.2-3
ii  python-twisted-web 14.0.2-3
ii  python-twisted-words   14.0.2-3
ii  python-tz  2012c+dfsg-0.1
ii  python-xattr   0.6.4-3
ii  python-zope.interface  4.1.1-3.1
pn  python:any none
ii  ssl-cert   1.0.35

Versions of packages calendarserver recommends:
ii  python-pam  0.4.2-13.1

Versions of packages calendarserver suggests:
pn  pyflakes none
pn  python-epydocnone
ii  python-pyasn10.1.7-1
pn  python-pydoctor  none

-- Configuration Files:
/etc/caldavd/servertoserver.dtd 6959f93d1fce2acccff5971775cb3e20 [Errno 2] No 
such file or directory: u'/etc/caldavd/servertoserver.dtd 
6959f93d1fce2acccff5971775cb3e20'
/etc/caldavd/sudoers.plist c4e456244e69c8e3f0449219e4cc589b [Errno 2] No such 
file or directory: u'/etc/caldavd/sudoers.plist 
c4e456244e69c8e3f0449219e4cc589b'
/etc/default/calendarserver changed:
start_calendarserver=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



  1   2   3   4   5   6   7   >