Bug#905734: found #905734 hplip/3.17.10

[Paul Elliott]

That worked! Although it took some time to figure out how to build using
backports. Evidently, there is some folklore involved.

I was even able to make a version for the raspberry pi!

Thank You.

On Wed, Dec 12, 2018 at 3:24 PM Didier 'OdyX' Raboud 
wrote:

> Dear Paul,
>
> Le vendredi, 7 décembre 2018, 16.15:01 h CET Paul Elliott a écrit :
> > I just downloaded it. It won't build under stretch. All the builds shown
> in
> > the logs are under sid or experimental.
>
> It does under stretch-backports (aka stretch + backports)
>
>
> https://buildd.debian.org/status/package.php?p=hplip&suite=stretch-backports
>
> To build, it needs debhelper and dh-autoreconf from backports indeed.
>
> > Correct me if I am wrong, but if you build under sid, it won't run under
> > stretch, because the libraries linked against won't be the same.
>
> Exactly. Different release suites produce differently linked software.
>
> > I don't think it will help stretch users.
>
> Stretch users don't get updated software, ONLY security fixes.
>
> Stretch users who enabled backports can get an hplip that was built
> against
> stretch libraries that can be installed on stretch hosts.
>
> You seem to want a source hplip from unstable that builds without
> modifications in stable. That's not something I'm interested in providing
> and
> a very unusual requirement for Debian packages.
>
> You also seem to want binary hplip packages that, when built in unstable,
> can
> be installed on stretch hosts. That neither is something I'm interested in
> providing, _also_ an unusual requirement, and that cannot be easily
> guaranteed.
>
> Finally, this bug was about "Unable to backport package hplip on
> stretch".  It
> is not a requirement for unstable packages to build without changes on
> stable.
> So I made minimal changes (thanks to inputs from this bug) to be able to
> build
> hplip in stretch-backports, AND I uploaded this modified package to the
> stretch-backports suite.  It is now accessible in the Debian-standard way
> to
> get backported packages on stable.  There's nothing more I can (or will)
> do.
>
> EOD for me.
>
> Cheers,
> OdyX

Bug#905734: found #905734 hplip/3.17.10

[Paul Elliott]

But upon request, packages can be adapted to target specific suites; that's
precisely what *-backports suites are.  That's why I uploaded a _modified_
hplip 3.18.10+dfsg0-3 to the `stretch-backports` suite.  That upload was
accepted today and is in the process of being built for all architectures.

https://buildd.debian.org/status/package.php?p=hplip&suite=stretch-backports

Stretch users will be able to get the latest hplip by using the `stretch-
backports` suite additionally to their standard APT setup.

I just downloaded it. It won't build under stretch. All the builds shown in
the logs are under sid or experimental.

Correct me if I am wrong, but if you build under sid, it won't run under
stretch, because the libraries
linked against won't be the same.

I don't think it will help stretch users.

Thank you for reading this email.

On Thu, Dec 6, 2018 at 1:23 PM Didier 'OdyX' Raboud  wrote:

> Le jeudi, 6 décembre 2018, 19.03:57 h CET Paul Elliott a écrit :
> > You guys must be developing under sid, and never checking that your
> > releases will actually build under the various stable releases.
>
> Exactly.  And it allows removing _a lot_ of unneeded complexity.  As hplip
> packager, I provide new upstream releases tailored towards the _next_
> stable
> release.  The "staging" area for this is `unstable`.  It will then migrate
> to
> `testing` (aka `buster`).
>
> Backporting these new upstream releases is a _different_ and _additional_
> work.  There's absolutely zero requirement for packages uploaded to
> `unstable`
> to build without modifications on other releases.
>
> > But your branches are still named for the various stable versions,
> > that is, debian/stretch-backports, debian/stretch,
> debian/jessie-backports,
> > debian/jessie.
>
> Yes. These build on the corresponding target suites.  They don't
> necessarily
> integrate the latest upstream releases (nor should they).
>
> > But you never check that these commits will actually build for these
> > versions.
>
> No, we don't.  Doing so would be _a lot_ of unneeded work.
>
> But upon request, packages can be adapted to target specific suites;
> that's
> precisely what *-backports suites are.  That's why I uploaded a _modified_
> hplip 3.18.10+dfsg0-3 to the `stretch-backports` suite.  That upload was
> accepted today and is in the process of being built for all architectures.
>
>
> https://buildd.debian.org/status/package.php?p=hplip&suite=stretch-backports
>
> Stretch users will be able to get the latest hplip by using the `stretch-
> backports` suite additionally to their standard APT setup.
>
> Cheers,
> OdyX

Bug#905734: found #905734 hplip/3.17.10

[Paul Elliott]

Yes, by cherry-picking
7f8981e96 Add --no-parallel to dh and dh_auto_build to fix building on
stable
you can make everything up to and including 3.17.10+repack0-6 build!

But at 3.18.4+repack0-1 and above fails to build because of
Bump debhelper compat to 11

Stretch does not have debhelper v11 support.

You guys must be developing under sid, and never checking that your
releases will actually build
under the various stable releases. But your branches are still named for
the various stable versions,
that is, debian/stretch-backports, debian/stretch, debian/jessie-backports,
debian/jessie.

But you never check that these commits will actually build for these
versions.
This is very confusing.

Paul Elliott

On Sun, Nov 25, 2018 at 2:28 PM Uwe Kleine-König 
wrote:

> Hello Paul,
>
> On 11/24/18 10:08 AM, Paul Elliott wrote:
> > 3.17.7 and 3.17.10 fail to build because of this bug, if you build with
> > "sbuild -d stretch hplip_3.17.10+repack0-7.dsc"
> >
> > I have determined that the commit that causes this problem is:
> > 7dbf1595d Migrate to debhelper 10, cleanup debian/rules
>
> given that the package compiles just fine when parallel building is
> disabled I bet that the relevant part of 7dbf1595d is the migration to
> debhelper 10. The debhelper manpage specifies for "--parallel,
> --no-parallel":
>
>  If neither option is specified, debhelper currently defaults to
>  --parallel in compat 10 (or later) and --no-parallel otherwise.
>
> Best regards
> Uwe
>
>
>

Bug#867577: #867577 lyx: Alt-m triggers space dialog in math mode

[Paul Elliott]

I have noticed this bug too. But only when using kde plasma, goes away when
using Gnome.

Bug#794192: closed by Scott Kitterman (Re: Bug#794192: kde-plasma-desktop: recent testing dist-upgrade makes kde-plasma go crazy.)

[Paul Elliott]

On Tue, Aug 04, 2015 at 11:32:47PM -0400, Scott Kitterman wrote:
> 
> The smooth upgrade issues won't be fixed for awhile.  Apt-get install 
> kde-plasma-install should allow you to finish the upgrade.  After you get all 
> the new packages installed, restart your KDE session and see how it works.


kde-plasma-install does not exist!

> 
> Scott K
> 

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#794192: closed by Scott Kitterman (Re: Bug#794192: kde-plasma-desktop: recent testing dist-upgrade makes kde-plasma go crazy.)

[Paul Elliott]

On Fri, Jul 31, 2015 at 05:57:04AM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the kde-plasma-desktop package:
> 
> #794192: kde-plasma-desktop: recent testing dist-upgrade makes kde-plasma go 
> crazy.
> 
> It has been closed by Scott Kitterman .




> > 
> > Dear Maintainer,
> > 
> > I have recently dist-upgrade d my debian testing on my laptop.
> > Kde plasma went crazy. No x in right corner of frame windows.
> > konsole text area never gets focus. Alt-f2 does not work.
> > 
> > konsole unusable cause no focus.
> > 
> > I am using gnome to file this bug, cause kde-plasma is broke.
> 
> We think that we understand what's missing and the balance of the needed 
> packages should migrate to testing today.  In the meantime, it sounds like the
> major thing you are missing is kwin.  You can execute manually using 
> /usr/bin/kwin_x11.  That should help considerably.

It has been 4 days since this bug was closed, but the problem
persists. dist-ugrade does say
"The following packages have been kept back:
  db5.1-util kde-full kde-plasma-desktop kde-standard plasma-desktop"


How long till this problem is fixed?
Should I reopen this bug?
Thank You.





> 
> Since I don't see anything here that's not covered by existing bugs, I'm 
> going 
> to close this one.  Once you have the next 24 hours of package updates and 
> have restarted your KDE session, then check and see what residual issues 
> remain.
> 
> Scott K




-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#794192: kde-plasma-desktop: recent testing dist-upgrade makes kde-plasma go crazy.

[Paul Elliott]

Package: kde-plasma-desktop
Version: 5:84
Severity: important

Dear Maintainer,

I have recently dist-upgrade d my debian testing on my laptop.
Kde plasma went crazy. No x in right corner of frame windows.
konsole text area never gets focus. Alt-f2 does not work.

konsole unusable cause no focus.

I am using gnome to file this bug, cause kde-plasma is broke.

I realize I may have filed this on wrong package, but
I do not know which is the correct package. Please forward
to correct package.

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

Kernel: Linux 4.0.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 kde-plasma-desktop depends on:
ii  kde-baseapps4:15.04.3-1
ii  kde-runtime 4:4.14.2-2
ii  kde-workspace   4:4.11.13-2
ii  plasma-desktop  4:4.11.13-2
ii  udisks2 2.1.6-1
ii  upower  0.99.3-1+b2

Versions of packages kde-plasma-desktop recommends:
ii  kdm   4:4.11.13-2
ii  xserver-xorg  1:7.7+9

Versions of packages kde-plasma-desktop suggests:
ii  kde-l10n-ca [kde-l10n]4:4.14.0-2
ii  kde-l10n-de [kde-l10n]4:4.14.0-2
ii  kde-l10n-el [kde-l10n]4:4.14.0-2
ii  kde-l10n-es [kde-l10n]4:4.14.0-2
ii  kde-l10n-fr [kde-l10n]4:4.14.0-2
ii  kde-l10n-it [kde-l10n]4:4.14.0-2
ii  kde-l10n-lv [kde-l10n]4:4.14.0-2
ii  kde-l10n-nl [kde-l10n]4:4.14.0-2
ii  kde-l10n-ptbr [kde-l10n]  4:4.14.0-2
ii  kde-l10n-sv [kde-l10n]4:4.14.0-2

-- no debconf information

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#793824: plasma-nm: plasma-widget-networkmanager has totally disappeared with plasma-nm 4:5.3.2-1

[Paul Elliott]

Package: plasma-nm
Version: 4:5.3.2-1
Severity: important

Dear Maintainer,

I run debian testing. When I ran apt-get dist-upgrade and it
installed plasma-nm version 4:5.3.2-1
the result is that the network manager applet or widget
has completly disappeared!

It is not in my system tray anymore either in the visible
part or the hidden part.

Add-Widgets can not find it to install it.

Get new Widgets can not find it either.

No way to get kde to do network management.

The only reason I can send you this email is by
editing /etc/network/interfaces by hand and
doing an "ifup" command!



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

Kernel: Linux 4.0.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 plasma-nm depends on:
ii  libc6   2.19-19
ii  libkf5completion5   5.12.0-1
ii  libkf5configcore5   5.12.0-1
ii  libkf5configwidgets55.12.0-1
ii  libkf5coreaddons5   5.12.0-1
ii  libkf5dbusaddons5   5.12.0-1
ii  libkf5i18n5 5.12.0-1
ii  libkf5iconthemes5   5.12.0-1
ii  libkf5itemviews55.12.0-1
ii  libkf5kdelibs4support5  5.12.0-2
ii  libkf5kiowidgets5   5.12.0-1
ii  libkf5modemmanagerqt6   5.12.0-1
ii  libkf5networkmanagerqt6 5.12.0-1
ii  libkf5notifications55.12.0-1
ii  libkf5service5  5.12.0-1
ii  libkf5solid55.12.0-1
ii  libkf5wallet5   5.12.0-1
ii  libkf5widgetsaddons55.12.0-1
ii  libkf5windowsystem5 5.12.0-1
ii  libkf5xmlgui5   5.12.0-1
ii  libopenconnect5 7.06-2
ii  libqt5core5a5.4.2+dfsg-4
ii  libqt5dbus5 5.4.2+dfsg-4
ii  libqt5gui5  5.4.2+dfsg-4
ii  libqt5network5  5.4.2+dfsg-4
ii  libqt5qml5  5.4.2-3
ii  libqt5widgets5  5.4.2+dfsg-4
ii  libqt5xml5  5.4.2+dfsg-4
ii  libstdc++6  5.1.1-14
ii  mobile-broadband-provider-info  20140317-1
ii  network-manager 1.0.2-2

plasma-nm recommends no packages.

Versions of packages plasma-nm suggests:
pn  network-manager-openconnect  
ii  network-manager-openvpn  1.0.2-1
ii  network-manager-pptp 1.0.2-1
ii  network-manager-vpnc 1.0.2-1

-- no debconf information

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#792302: maitreya does not respond anymore after clicking transit view

[Paul Elliott]

On Mon, Jul 13, 2015 at 02:14:57PM -0400, G. Heine wrote:
> Package: maitreya
> Version: 7.0.7-1
> Severity: important
> 
> Dear Maintainer,
> 
> after clicking new view > transit view (my translation) the program does not
> respond anymore and maitreya.bin uses 100 % of one CPU-core. Other options of
> new view are not affected.
> 
> This behaviour is new on my system after a complete dist-upgrade. As maitreya
> package remained unchanged in this process there seems to be some
> incompatibility with system packages changed after Jessie's freeze (sorry for
> not being more precise but that was my last complete dist-upgrade before now).

I am investigating this. Let me know if any changes you might make, cause
the problem to go away.

This might relate perhaps to sqlite.





> 
> Best regards
> Günter Heine
> 
> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (700, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages maitreya depends on:
> ii  libc6   2.19-18
> ii  libfontconfig1  2.11.0-6.3
> ii  libgcc1 1:5.1.1-12
> ii  libsqlite3-03.8.10.2-1
> ii  libstdc++6  5.1.1-12
> ii  libswe0 1.80.00.0002-1
> ii  libwxbase3.0-0  3.0.2+dfsg-1
> ii  libwxgtk3.0-0   3.0.2+dfsg-1
> ii  libwxsqlite3-3.0-0  3.2.1~dfsg1-1
>



-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#780497: youtube video on the workaround.

[Paul Elliott]

I have made 3 youtube videos on the workaround for this bug.

Workaround sounds libreoffice impress 1/3 
https://www.youtube.com/watch?v=0OkWlih5Qw0

Workaround sounds libreoffice impress 2/3 
https://www.youtube.com/watch?v=UFQLkkroTGQ

Workaround sounds libreoffice impress 3/3 
https://www.youtube.com/watch?v=Erh3b8vX7jw

Best wishes to all
-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#780746: libreoffice-impress: Need youtube resolutions and aspect ratios.

[Paul Elliott]

.0-2+b1
ii  libwpg-0.3-3   0.3.0-3
ii  libxml22.9.1+dfsg1-5
ii  uno-libs3  4.3.3-2
ii  ure4.3.3-2
ii  zlib1g 1:1.2.8.dfsg-2+b1

-- no debconf information

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#722249: Info received (help with debian packageing simplescreenrecorder)

[Paul Elliott]

Please git the latest push on
https://github.com/pelliott80/simplescreenrecorder-dpm.git


I believe I have gotten all the lintian bugs out of it.

I believe the package is now in a good state to apply for
a sponsor. But perhaps we should wait until the chaos
associated with the jessie release subsides.

Ho Wan Chan, you are the owner of this bug. How should we now
proceed?

Sincere Best Wishes to all.

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#722249: help with debian packageing simplescreenrecorder

[Paul Elliott]

I have seen the ITP on simplescreenrecorder.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722249

I have decided to help out packaging this package.

Whoever owns this bug and is working on this please clone:
g...@github.com:pelliott80/simplescreenrecorder-dpm.git
or
https://github.com/pelliott80/simplescreenrecorder-dpm.git

This is a packaging repository used for packaging. It
is in dpm format.
http://git-dpm.alioth.debian.org/

This is the most common format for packaging work on alioth.

packages in this format usually have at least 3 branches,
upstream, pristine-tar, and master.

upstream contains the upstream's source unmodified.
pristine-tar is used to reconstruct a tarball.
master is the files as modified for packaging
there will be a debian directory and the source may
be modified by any patches.

here is the changelog entry I used to help get this package
into Debian:

simplescreenrecorder (0.3.3-2) unstable; urgency=medium

  * volunteer to help get it into Debian.
  * change to non-native package; native packages do not make it into Debian.
  * update standards version to 3.9.6
  * remove unneeded build dependency on build-essential
  * remove duplicate dependency in build depends, libxext-dev, libx11-dev,
  - libxfixes-dev
  * use correct format specification URI
  - https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
  * remove indefinite article from Description field
  * wrap too long line in Description field
  * remove empty debian/postinst
  * update copyright file
  * fix VCS fields
  - VCS fields should point to the source control for the packaging;
  - not the source control for the program.
  * create debian/watch file.

 -- Paul Elliott   Sat, 07 Mar 2015 16:59:23 -0600

here are the current results of lintian:
P: simplescreenrecorder source: debian-watch-may-check-gpg-signature
N: 
N:This watch file does not include a means to verify the upstream tarball
N:using cryptographic signature.
N:
N:If upstream distributions provide such signatures, please use the
N:pgpsigurlmangle options in this watch file's opts= to generate the URL
N:of an upstream GPG signature. This signature is automatically downloaded
N:and verified against a keyring stored in
N:debian/upstream-signing-key.asc.
N:
N:Of course, not all upstreams provide such signatures, but you could
N:request them as a way of verifying that no third party has modified the
N:code against their wishes after the release. Projects such as
N:phpmyadmin, unrealircd, and proftpd have suffered from this kind of
N:attack.
N:
N:Refer to the uscan(1) manual page for details.
N:
N:Severity: pedantic, Certainty: certain
N:
N:Check: watch-file, Type: source
N: 
W: simplescreenrecorder: binary-without-manpage usr/bin/simplescreenrecorder
N: 
N:Each binary in /usr/bin, /usr/sbin, /bin, /sbin or /usr/games should
N:have a manual page
N:
N:Note that though the man program has the capability to check for several
N:program names in the NAMES section, each of these programs should have
N:its own manual page (a symbolic link to the appropriate manual page is
N:sufficient) because other manual page viewers such as xman or tkman
N:don't support this.
N:
N:If the name of the man page differs from the binary by case, man may be
N:able to find it anyway; however, it is still best practice to make the
N:case of the man page match the case of the binary.
N:
N:If the man pages are provided by another package on which this package
N:depends, lintian may not be able to determine that man pages are
N:available. In this case, after confirming that all binaries do have man
N:pages after this package and its dependencies are installed, please add
N:a lintian override.
N:
N:Refer to Debian Policy Manual section 12.1 (Manual pages) for details.
N:
N:Severity: normal, Certainty: possible
N:
N:Check: manpages, Type: binary
N: 
W: simplescreenrecorder: binary-without-manpage usr/bin/ssr-glinject

I: Lintian run was successful.

As I see it the outstanding issues on getting this package into
Debian is the lack of manpages for ssr-glinject and simplescreenrecorder.

Perhaps the upstream, Maarten Baert, could be persuaded to write those
manpages. He knows those programs best.

By the way, who owns this bug? perhaps we could collaborate in getting
this program into Debian?

Best Wishes to all.

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#655215: sbuild: Do not do run "fakeroot ./debian/rules clean" before building source

[Paul Elliott]

At a minimum, this problem should be better documented.

As it is a sbuild can fail because the local computer
(not the chroot) lacks the dependancies to do the clean.

The user naturally expects all dependancy problems to be
in "Build-Depends". Thats why we have sbuild isn't it?

It is disconcerting to find out that this is not the case.



-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#763148: Prevent migration to jessie

[Paul Elliott]

Just to see what the fuss was about, and because I wanted
to use ffmpeg, I grabbed the unstable source and tried to
build with "sbuild -d testing".

I got an undefied dependancy on libx265-dev.

Sure enough I checked debian packages and libx265-dev
is in unstable but not testing.

I am testing, i386.


Could it be that ffmpeg is blocked for this other reason,
and the whole discussion on this bug is pointless?

Best Wishes to all.


-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#776597: rng-tools: No systemd .service file.

[Paul Elliott]

On Thu, Jan 29, 2015 at 10:45:37PM -0200, Henrique de Moraes Holschuh wrote:
> On Thu, Jan 29, 2015, at 16:56, Paul Elliott wrote:
> > One problem is that the the sysV version uses bash computing to search
> > a list of random file names. I have created a bash file that does this
> > then execs rngd. I have tested this on my raspberry PI which runs
> > systemd version 44. Changes may be required to upgrade to current
> > version.
> 
> This is mostly backwards-compatibility stuff.  There is no need to carry
> it forward in the systemd unit file, AFAIK: if a kernel is new enough to
> be able to run the udev version required by systemd, it is new enough to
> have a modern device node for the random device driver.
> 

OK how about this?
----rand-server.service
# Author: Paul Elliott 
#
# License GPLv2+

[Unit]
Description=Add entropy to /dev/random 's pool a hardware RNG
# the sysV init script mentions  $remote_fs $syslog so,
# in the spirit of cargo cult programming
After=remote-fs.target
Requires=remote-fs.target
After=syslog.target
Requires=syslog.target

[Service]
Type=simple
#because simple don't need to fork i.e. "-f"
ExecStart=/usr/sbin/rngd -r /dev/hwrng -f



[Install]
WantedBy=basic.target
rand-server.service



-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#776597: rng-tools: No systemd .service file.

[Paul Elliott]

Package: rng-tools
Version: 2-unofficial-mt.14-1
Severity: wishlist

Dear Maintainer,


rng-tools works in sysV compatibility mode. No native systemd .service file.

One problem is that the the sysV version uses bash computing to search
a list of random file names. I have created a bash file that does this
then execs rngd. I have tested this on my raspberry PI which runs
systemd version 44. Changes may be required to upgrade to current version.

-script file list-rngd---
#! /bin/bash

# Author: Paul Elliott 
#
# License GPLv2+

DAEMON=/usr/sbin/rngd


#first arg is list of possible hardware rngs to used.
#first one to exist, as determined by [ -c ] will be used.


LIST=$1

shift

#all the remaining args to rngd

RNGOPTIONS=$*

HRNGDEVICE=""

for i in $LIST;do


if [ -c "/dev/$i" ] ; then
HRNGDEVICE="/dev/$i"
break; 
fi
if [ -c "/dev/misc/$i" ] ; then
HRNGDEVICE="/dev/misc/$i"
break;
fi

done


if [ "$HRNGDEVICE" == "" ] ; then


   logger "random device of form /dev/X or /dev/misc/X is not found, where 
X is one of $LIST"

   exit 1
fi

exec -a "rngd" $DAEMON -r $HRNGDEVICE  $RNGOPTIONS

end
--- systemd service file rng-tools.service---
# Author: Paul Elliott 
#
# License GPLv2+

[Unit]
Description=Add entropy to /dev/random 's pool a hardware RNG
# the sysV init script mentions  $remote_fs $syslog so,
# in the spirit of cargo cult programming
After=remote-fs.target
Requires=remote-fs.target
After=syslog.target
Requires=syslog.target

[Service]
Type=simple
#because simple don't need to fork i.e. "-f"
ExecStart=/usr/sbin/list-rngd "hwrng hw_random hwrandom intel_rng i810_rng" "-f"


[Install]
WantedBy=basic.target
end




-- System Information:
Debian Release: 8.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: i386 (i686)

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

Versions of packages rng-tools depends on:
ii  libc6  2.19-13
ii  udev   215-8

rng-tools recommends no packages.

rng-tools suggests no packages.

-- no debconf information

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#771523: systemd-journal-upload

[Paul Elliott]

771...@bugs.debian.org

systemd-journal-upload is also needed. I have a low memory
computer, and need to ship journals to another computer.


This is not something you should ignore, journal can be useless
without it.


-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#775249: ITP: swe-extrapolated-data -- Swiss Ephemeris data file for far past, far future

[Paul Elliott]

Package: wnpp
Severity: wishlist
Owner: Paul Elliott 

* Package name: swe-extrapolated-data
  Version : 1
  Upstream Author : Alois Treindl, Dieter Koch, Paul Elliott 

* URL : http://swissephauto.blackpatchpanel.com/
* License : GPL-2+
  Programming Lang: data
  Description : Swiss Ephemeris data file for far past, far future

(Include the long description here.)
 The swe-extrapolated-data package contains only data files for the periods:
 11 Aug 13000 BC to 5402 BC
 and
 5400 AD to  7 Jan 16800 AD
 such data is not usually needed by people not doing extraordinary
 research.

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#749974: new maitreya push

[Paul Elliott]

On Sat, Aug 16, 2014 at 03:50:13PM +0100, James Cowgill wrote:
> On Sat, 2014-08-16 at 09:19 -0500, Paul Elliott wrote:
> > On Sat, Aug 16, 2014 at 06:44:48AM -0400, Jaldhar H. Vyas wrote:
> > > On Sat, 16 Aug 2014, Olly Betts wrote:
> > > 
> > > >
> > > >I've NMUed wxsqlite3 to unstable, so please upload maitreya.
> > > >
> > > 
> > > I built the package in a freshly updated  unstable pbuilder but its linked
> > > against libwxsqlite3-3.0-0.  Is that right or have I in fact not got the
> > > latest packages?
> > 
> > I am investigating this now but is that not correct?
> > As I look at https://packages.debian.org/ I find that
> > source package
> > http://ftp.de.debian.org/debian/pool/main/w/wxsqlite3/wxsqlite3_3.1.0~dfsg1-1.1.dsc
> > http://ftp.de.debian.org/debian/pool/main/w/wxsqlite3/wxsqlite3_3.1.0~dfsg1.orig.tar.bz2
> > http://ftp.de.debian.org/debian/pool/main/w/wxsqlite3/wxsqlite3_3.1.0~dfsg1-1.1.debian.tar.xz
> > 
> > produces the binary packages:
> > libwxsqlite3-3.0-0 (3.1.0~dfsg1-1.1) 
> > libwxsqlite3-3.0-dev (3.1.0~dfsg1-1.1) 
> > 
> > That is also how it was when these were in experimantal.
> 
> These are the correct packages, the name of the package wasn't changed
> when wxsqlite3 just got updated. The package name corresponds to:
>  libwxsqlite3  = as in sqlite version 3
>  -3.0  = version of wxwidgets
>  -0= soversion
> 
> > When I attempt to apt-get these 2 packages, this is what
> > happened:

> Version 3.1.0~dfsg1-2 doesn't exist, maybe you built it yourself? Try
> downgrading it to the version in unstable first.
> 
> James


Ok that problem was my fault. 
The 3.0 binaries correspond to the 3.1 source. The new maitreya
is designed to use the new binaries. I believe everything is OK.

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#749974: new maitreya push

[Paul Elliott]

On Sat, Aug 16, 2014 at 06:44:48AM -0400, Jaldhar H. Vyas wrote:
> On Sat, 16 Aug 2014, Olly Betts wrote:
> 
> >
> >I've NMUed wxsqlite3 to unstable, so please upload maitreya.
> >
> 
> I built the package in a freshly updated  unstable pbuilder but its linked
> against libwxsqlite3-3.0-0.  Is that right or have I in fact not got the
> latest packages?
> 
> -- 
> Jaldhar H. Vyas 

I am investigating this now but is that not correct?
As I look at https://packages.debian.org/ I find that
source package
http://ftp.de.debian.org/debian/pool/main/w/wxsqlite3/wxsqlite3_3.1.0~dfsg1-1.1.dsc
http://ftp.de.debian.org/debian/pool/main/w/wxsqlite3/wxsqlite3_3.1.0~dfsg1.orig.tar.bz2
http://ftp.de.debian.org/debian/pool/main/w/wxsqlite3/wxsqlite3_3.1.0~dfsg1-1.1.debian.tar.xz

produces the binary packages:
libwxsqlite3-3.0-0 (3.1.0~dfsg1-1.1) 
libwxsqlite3-3.0-dev (3.1.0~dfsg1-1.1) 

That is also how it was when these were in experimantal.

When I attempt to apt-get these 2 packages, this is what
happened:

-cut here---
root@hrnowl:/home/pelliott-unstable# apt-get install libwxsqlite3-3.0-0 
libwxsqlite3-3.0-dev
Reading package lists... Done
Building dependency tree   
Reading state information... Done
libwxsqlite3-3.0-0 is already the newest version.
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libwxsqlite3-3.0-dev : Depends: libwxsqlite3-3.0-0 (= 3.1.0~dfsg1-1.1) but 
3.1.0~dfsg1-2 is to be installed
E: Unable to correct problems, you have held broken packages.
-end cut--


Before when I was testing the experimental version,
I got the source from experimental, built the binaries
from the source, and installed the binaries with
dpkg -i

If I download the wxsqllite3 binaries, install them with
dpkg-i

then I can build and run maitreya.

But apt-get install can not install the wxsqlite3 binaries.

I think this is a bug in wxsqlite3. But when they fix it
so that apt-get install on the wxsqlite3 binaries works
then I will have to update my control file.

Please tell me if my analysis is correct! And if so when
the wxsqlite package is fixed.

Thank You.


-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#749974: new maitreya push

[Paul Elliott]

Please find the new push on 
http://anonscm.debian.org/gitweb/?p=collab-maint/maitreya.git
it upgrades to the upstream's 7.0.7 and does not have the bugs
the previous version had.

It can be uploaded to unstable as soon as wxsqlite3_3.1.0
is released from experimental. Since I was told that maitreya
was the last program that needed to be setup to work with wx 3.0
I believe that can be done immeatiately. Since maitreya has been
removed from testing, I hope this will happen as soon as possible.


Sincere wishes to all and thanks for helping keep maitreya in debian!


-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#749974: new maitreya push

[Paul Elliott]

Please find the new push on 
http://anonscm.debian.org/gitweb/?p=collab-maint/maitreya.git
it upgrades to the upstream's 7.0.6 and suppresses
assertion failures with
export DEB_CPPFLAGS_MAIN_APPEND=-DNDEBUG

The upstream says he is working on fixes for these assertion failures
which should be available "in a few days".

When I get that fix, I will revert the suppression and push the
new upstream. So there most likely be a new push comming. But
that is future.

The presure to have a release ready is intense.

This push does not build on an ordinary sid system.
That is because wxsqlite3_3.1.0 has not been released from
experimental. But they say the unreadiness of maitreya
is keeping them from doing that.

I tested the pushd by downloading wxsqlite3_3.1.0 and
building it and installing it by hand.

In this environment, Maitreya will build and run without the assertion
failures I previously found. But who knows how many others are
out there that I did not find? They are suppressed now.

I also was able to get maitreya to build with sbuild, by tricking
sbuild to also get packages from experimental.

So I guess you can tell them it is OK to let go of wxsqlite3_3.1.0.
Then when it is available, you will be able to upload this push.

I am worried about all this.


-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#749974: maitreya: Please update to use wxwidgets3.0

[Paul Elliott]

On Fri, Jul 18, 2014 at 07:52:00AM +0100, James Cowgill wrote:
> On Thu, 2014-07-17 at 20:35 -0500, Paul Elliott wrote:
> > On Tue, Jul 15, 2014 at 12:21:51PM +0100, James Cowgill wrote:
> > > Hi Paul,
> > > 
> > > I looked back at the history of this bug and it seems like you were having
> > > problems with there being more assertion messages in wx3.
> > > 
> > > Does maitreya work if you disable the assertions by adding -DNDEBUG, at 
> > > least
> > > as a temporary measure?
> > > 
> > > Try this in debian/rules:
> > > export DEB_CPPFLAGS_MAIN_APPEND=-DNDEBUG
> > > 
> > > James
> 
> Sorry I made a typo. It should be MAINT and not MAIN.
> See dpkg-buildflags(1) for more info.
> 
> James
> 

That worked in the sense of turning off the display of errors.
But it feels like turning off a saftey mechanism.

I am trying to contact the upstream for his advise.

thank you.


-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#749974: Bug #749974: maitreya: Please update to use wxwidgets3.0

[Paul Elliott]

On Tue, Jul 15, 2014 at 12:21:51PM +0100, James Cowgill wrote:
> Hi Paul,
> 
> I looked back at the history of this bug and it seems like you were having
> problems with there being more assertion messages in wx3.
> 
> Does maitreya work if you disable the assertions by adding -DNDEBUG, at least
> as a temporary measure?
> 
> Try this in debian/rules:
>     export DEB_CPPFLAGS_MAIN_APPEND=-DNDEBUG
> 
> James

I just tried that:
$ git diff
diff --git a/debian/changelog b/debian/changelog
index 409aa7d..4dfa6d5 100644
--- a/debian/changelog
+++ b/debian/changelog  
 
@@ -1,3 +1,9 @@ 
 
+maitreya (7.0.6-2) unstable; urgency=medium
 
+   
 
+  * try hack: export DEB_CPPFLAGS_MAIN_APPEND=-DNDEBUG 
 
+   
         
+ -- Paul Elliott   Thu, 17 Jul 2014 19:35:46 
-0500
+
 maitreya (7.0.6-1) unstable; urgency=medium
 
   * upgrade to release 7.0.6 (Closes: 749974)
diff --git a/debian/rules b/debian/rules
index 0470214..5ccb1e4 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,4 +1,5 @@
 #!/usr/bin/make -f
+export DEB_CPPFLAGS_MAIN_APPEND=-DNDEBUG
 %:
dh $@ --with autoreconf
 



The bug remained When I rebuilt and installed!




-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#749974: Bug #749974: maitreya: Please update to use wxwidgets3.0

[Paul Elliott]

On Tue, Jul 15, 2014 at 12:21:51PM +0100, James Cowgill wrote:
> Hi Paul,
> 
> I looked back at the history of this bug and it seems like you were having
> problems with there being more assertion messages in wx3.
> 
> Does maitreya work if you disable the assertions by adding -DNDEBUG, at least
> as a temporary measure?
> 
> Try this in debian/rules:
>     export DEB_CPPFLAGS_MAIN_APPEND=-DNDEBUG
> 
> James

What if those assertions represent real bugs? When I reported
the problem upstream, he did not suggest this solution, but
rather went to work on a new release.

I will try your solution on my experimental system, to see
if it works. But I think I should consult with the upstream
before releasing it.

I will add the upstream to the CC list of this message.

Martin, what do you think?



-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#749974: Bug#750619: transition: wxsqlite3

[Paul Elliott]

On Sat, Jul 05, 2014 at 10:19:53PM +0200, László Böszörményi (GCS) wrote:
> On Sat, Jul 5, 2014 at 6:19 PM, Emilio Pozuelo Monfort  
> wrote:
> > With guayadeque gone from testing because upstream is switching to qt, 
> > what's
> > the situation here? Are the other two packages ready to switch? If so, 
> > shall we
> > start this?
>  The last package which needs updating is maitreya. Its upstream
> finished the transition two weeks ago[1]:
> "Service Release 7.0.6 (Jun 21 2014)
>  This is a service release with support for wxWidgets 3.0.0. It is
> used for wx migration purposes only.".
> But the package and its Git tree is still on 7.0.5, but hopefully Paul
> Elliott will update it soon. Should I NMU it after some days, if that
> doesn't happen, maybe on Thursday?

As I mentioned in a status report on the bug 749974 (the bug for
maitreya), the first upstream release 7.0.6 contained bugs, and had to
be sent back to the upstream for further work. The upstream is working
on that now. As soon as i get the next upstream release without bugs,
I should be able to produce a new version for debian fairly quickly.


> 
> Regards,
> Laszlo/GCS
> [1] http://www.saravali.de/index.html
> [2] http://anonscm.debian.org/gitweb/?p=collab-maint/maitreya.git

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#749974: status of upgrading maitreya to use wxwidgets3.0

[Paul Elliott]

Summary: the upstream created a new release to fix this problem.
But bugs were found in this new release. Upstream is planning
yet another release to deal with the problem, but the details
have not been fixed yet.
See below:



- Forwarded message from Martin Pettau  -

Date: Mon, 30 Jun 2014 15:56:34 +0200
From: Martin Pettau 
To: Paul Elliott 
Subject: Re: bug found in maitreya 7.0.6
X-Mailer: Evolution 3.2.3-0ubuntu6

Hi Paul,

I fixed this bug and several similar ones. wx3 has more asserts on
sizers and image sizes.

I am still thinking how to proceed. I would like to build a testing
release 7.1 with packages for Windows and OSx, but the latter makes some
difficulties. Nevertheless I must migrate to wx3 because I changed my
MacBook OS - and I am therefore not able to build any release based on
wx2.8.

I will continue research and tell you soon.

Best wishes
Martin


Am Mittwoch, den 25.06.2014, 22:45 -0500 schrieb Paul Elliott:
> 
> I believe I have found a bug in maitreya 7.0.6
> when you do Extra/Configuration/view/Object Colors
> 
> the following info appears on the console screen:
> Maitreya 7 startup parameters are
>   Executable: /usr/bin/maitreya7.bin
>   Datadir:/usr/share/maitreya7
>   Command:/usr/bin/maitreya7.bin /usr/share/maitreya7 



- End forwarded message -

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#753006: synaptic: "details" hides questions from installation process

[Paul Elliott]

Package: synaptic
Version: 0.81.2
Severity: normal

Dear Maintainer,


I was doing a installation of some packages to my debian system.
synaptic's progress stopped. I thought it was hung. On a whim,
I pressed the "details" button. The details window showed that
the package installation process was trying to ask an installation
question. I answered that question and installation proceeded to
completion.

Joe Sixpack does not know that "details" can hide a question
that synaptic installation process is waiting to an answer for.
He thinks synaptic is hung.

Details should pop up and stay up everytime there is a question
to be answered.



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

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

Versions of packages synaptic depends on:
ii  hicolor-icon-theme   0.13-1
ii  libapt-inst1.5   1.0.3
ii  libapt-pkg4.12   1.0.3
ii  libatk1.0-0  2.12.0-1
ii  libc62.19-3
ii  libcairo-gobject21.12.16-2
ii  libcairo21.12.16-2
ii  libept1.4.12 1.0.12
ii  libgcc1  1:4.9.0-7
ii  libgdk-pixbuf2.0-0   2.30.7-1
ii  libglib2.0-0 2.40.0-3
ii  libgtk-3-0   3.12.2-1+b1
ii  libpango-1.0-0   1.36.3-1
ii  libpangocairo-1.0-0  1.36.3-1
ii  libstdc++6   4.9.0-7
ii  libvte-2.90-91:0.36.2-1
ii  libx11-6 2:1.6.2-2
ii  libxapian22  1.2.17-1
ii  libxext6 2:1.3.2-1
ii  zlib1g   1:1.2.8.dfsg-1

Versions of packages synaptic recommends:
ii  gksu   2.0.2-6
ii  libgtk2-perl   2:1.2491-4
ii  policykit-10.105-6
ii  rarian-compat  0.8.1-5

Versions of packages synaptic suggests:
ii  apt-xapian-index 0.46
pn  deborphan
pn  dwww 
ii  menu 2.1.47
ii  software-properties-gtk  0.92.25debian1
ii  tasksel      3.20

-- no debconf information

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117
---
"Encryption works. Properly implemented strong crypto systems are one
of the few things that you can rely on. Unfortunately, endpoint
security is so terrifically weak that NSA can frequently find ways
around it." Edward Snowden


signature.asc
Description: Digital signature

Bug#749974: status of upgrading maitreya to use wxwidgets3.0

[Paul Elliott]

I have been notified that wxwidgets2.8 support is going away
to be replace with wxwidgets3.0. This effects maitreya
because the version in unstable links to 2.8 libraries.

I notified the upstream and he accepted the bug and produced
a new upstream =7.0.6

I had difficluty building a version of this upstream at first
because one dependancy libwxsqlite3-3.0-dev is not in unstable yet.

For my testing purposes on my test system I solved this on my system
by grabbing the source in experimental from the Debian packages
website https://www.debian.org/distrib/packages

I then built this package for debian using debuild. I installed
it, which allowed my to build/run my potential upgrade package using
debuild.

I did crude testing on this program and found that it basicly
works, but on one particular menu item, it pops up an error window.

This new bug did not exist in the old verion 7.0.5. (i reverted and
tested for it.)

I have notified the upstream and am waiting to hear back.

I hope this keeps every one informed of the status of this bug
and attempts to address it.

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#751360: libswe-dev: /usr/lib/i386-linux-gnu/pkgconfig/libswe-1.80.00.pc wrong value

[Paul Elliott]

Package: libswe-dev
Version: 1.80.00.0001-1
Severity: normal

Dear Maintainer,


the file /usr/lib/i386-linux-gnu/pkgconfig/libswe-1.80.00.pc
says includedir=${prefix}/include/libswe-1.80.00 where it
should say includedir=${prefix}/include


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

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

Versions of packages libswe-dev depends on:
ii  libc62.19-1
ii  libswe0  1.80.00.0001-1

libswe-dev recommends no packages.

libswe-dev suggests no packages.

-- no debconf information

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#747841: xorg: Fatal server error: (EE) no screens found(EE)

[Paul Elliott]

t4/event3
N: input/event3
S: input/by-path/platform-pcspkr-event-spkr
E: DEVLINKS=/dev/input/by-path/platform-pcspkr-event-spkr
E: DEVNAME=/dev/input/event3
E: DEVPATH=/devices/platform/pcspkr/input/input4/event3
E: ID_INPUT=1
E: ID_PATH=platform-pcspkr
E: ID_PATH_TAG=platform-pcspkr
E: ID_SERIAL=noserial
E: MAJOR=13
E: MINOR=67
E: SUBSYSTEM=input
E: USEC_INITIALIZED=122027


DRM Information from dmesg:
---
[0.929082] Linux agpgart interface v0.103
[9.977845] [drm] Initialized drm 1.1.0 20060810
[   10.840639] [drm] hdmi device  not found 0 13 1
[   10.943088] nouveau  [ DRM] VRAM: 125 MiB
[   10.943090] nouveau  [ DRM] GART: 512 MiB
[   10.943095] nouveau  [ DRM] TMDS table version 1.1
[   10.943097] nouveau  [ DRM] DCB version 3.0
[   10.943100] nouveau  [ DRM] DCB outp 00: 01000310 0023
[   10.943103] nouveau  [ DRM] DCB outp 01: 00110204 97e5
[   10.943105] nouveau  [ DRM] DCB conn 00: 
[   10.943439] nouveau  [ DRM] Saving VGA fonts
[   10.977864] nouveau W[ DRM] DCB type 4 not known
[   10.977867] nouveau W[ DRM] Unknown-1 has no encoders, removing
[   10.978663] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   10.978665] [drm] Driver supports precise vblank timestamp query.
[   10.980468] nouveau  [ DRM] MM: using M2MF for buffer copies
[   11.009523] nouveau  [ DRM] allocated 1280x1024 fb: 0x9000, bo f76cfc00
[   11.091414] [drm] Initialized nouveau 1.1.1 20120801 for :00:0d.0 on 
minor 0


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

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

Versions of packages xorg depends on:
ii  gnome-terminal [x-terminal-emulator]  3.12.0-2
ii  libgl1-mesa-dri   10.1.2-1
ii  libgl1-mesa-glx [libgl1]  10.1.2-1
ii  libglu1-mesa  9.0.0-2
ii  x11-apps  7.7+2
ii  x11-session-utils 7.7+1
ii  x11-utils 7.7+1
ii  x11-xkb-utils 7.7+1
ii  x11-xserver-utils 7.7+2
ii  xauth 1:1.0.7-1
ii  xfonts-100dpi 1:1.0.3
ii  xfonts-75dpi  1:1.0.3
ii  xfonts-base   1:1.0.3
ii  xfonts-scalable   1:1.0.3-1
ii  xfonts-utils  1:7.7+1
ii  xinit 1.3.2-1
ii  xkb-data  2.10.1-1
ii  xorg-docs-core1:1.7-1
ii  xserver-xorg  1:7.7+7
ii  xterm [x-terminal-emulator]   304-1

xorg recommends no packages.

Versions of packages xorg suggests:
ii  x11-xfs-utils  7.7+1
pn  xorg-docs  

Versions of packages xserver-xorg depends on:
ii  libc6   2.18-5
ii  x11-xkb-utils   7.7+1
ii  xkb-data2.10.1-1
ii  xserver-xorg-core   2:1.15.1-1
ii  xserver-xorg-input-all  1:7.7+7
ii  xserver-xorg-input-evdev [xorg-driver-input]1:2.8.2-1+b1
ii  xserver-xorg-input-mouse [xorg-driver-input]1:1.9.0-1+b2
ii  xserver-xorg-input-synaptics [xorg-driver-input]1.7.3-1+b1
ii  xserver-xorg-input-vmmouse [xorg-driver-input]  1:13.0.0-1+b2
ii  xserver-xorg-input-wacom [xorg-driver-input]0.23.0+20131011-1+b1
ii  xserver-xorg-video-cirrus [xorg-driver-video]   1:1.5.2-2
ii  xserver-xorg-video-fbdev [xorg-driver-video]1:0.4.4-1+b1
ii  xserver-xorg-video-geode [xorg-driver-video]2.11.15-2
ii  xserver-xorg-video-intel [xorg-driver-video]2:2.21.15-2+b1
ii  xserver-xorg-video-mach64 [xorg-driver-video]   6.9.4-1+b2
ii  xserver-xorg-video-mga [xorg-driver-video]  1:1.6.3-2
ii  xserver-xorg-video-modesetting [xorg-driver-video]  0.8.1-2
ii  xserver-xorg-video-nouveau [xorg-driver-video]  1:1.0.10-1+b1
ii  xserver-xorg-video-radeon [xorg-driver-video]   1:7.3.0-1+b1
ii  xserver-xorg-video-vesa [xorg-driver-video] 1:2.3.3-1+b2
ii  xserver-xorg-video-vmware [xorg-driver-video]   1:13.0.2-2

Versions of packages xserver-xorg recommends:
ii  libgl1-mesa-dri  10.1.2-1

-- no debconf information

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117
---
"Encryption works. Properly implemented strong crypto systems are one
of the few things that you can rely on. Unfortunately, endpoint
security is so terrifically weak that NSA can frequently find ways
around it." Edward Snowden


signature.asc
Description: Digital signature

Bug#722012: sbuild-createchroot 'tempfile' can't be called as a method at /usr/sbin/sbuild-createchroot

[Paul Elliott]

I have also experineced the 
'tempfile' can't be called as a method at /usr/sbin/sbuild-createchroot

problem.

Below is the patch for my debian testing system.
But it is only cargo cult programing.
##cut here with a chain saw###
--- sbuild-createchroot.orig2013-09-19 12:27:43.0 -0500
+++ sbuild-createchroot 2013-09-19 13:22:30.0 -0500
@@ -137,7 +137,7 @@
 use Sbuild::Sysconfig;
 use Sbuild::Conf qw();
 use File::Path qw(mkpath rmtree);
-use File::Temp ();
+use File::Temp qw(tempfile);
 use File::Copy;
 use Cwd qw(abs_path);
 
@@ -392,7 +392,7 @@
 # the sbuild chroot directory created, unless it's been requested to keep the
 # directory.
 if ($conf->get('MAKE_SBUILD_TARBALL')) {
-my ($tmpfh, $tmpfile) = File::Temp->tempfile("XX");
+my ($tmpfh, $tmpfile) = tempfile("XX");
 my @program_list;
 
 # Change program arguments accordingly

######cut here with a chain saw###



-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117
---
"Encryption works. Properly implemented strong crypto systems are one
of the few things that you can rely on. Unfortunately, endpoint
security is so terrifically weak that NSA can frequently find ways
around it." Edward Snowden


signature.asc
Description: Digital signature

Bug#721632: RFP: wxpdfdoc -- wxPdfDocument allows wxWidgets applications to generate PDF documents.

[Paul Elliott]

Package: wnpp
Severity: wishlist

* Package name: wxpdfdoc
  Version : 0.9.4
  Upstream Author : Ulrich Telle 
* URL : http://wxcode.sourceforge.net/components/wxpdfdoc/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Programming Lang: C++
  Description : wxPdfDocument allows wxWidgets  generate PDF documents.

wxPdfDocument allows wxWidgets applications to generate PDF
documents. The code is a port of FPDF - a free PHP class for
generating PDF files - to C++ using the wxWidgets library. Several
add-on PHP scripts found on the FPDF web site are incorporated into
wxPdfDocument. Embedding of PNG, JPEG, GIF and WMF images is
supported. In addition to the 14 standard Adobe fonts it is possible
to use other Type1 or TrueType fonts - with or without embedding them
into the generated document. In Unicode build CJK fonts are supported,
too. Graphics primitives allow the creation of simple drawings.

I have a package which compiles and links its own copy of
this package (maitreya). It would be trivial to change it
to link to external library instead.

But I can't because I find no such package.


-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117
---
"Encryption works. Properly implemented strong crypto systems are one
of the few things that you can rely on. Unfortunately, endpoint
security is so terrifically weak that NSA can frequently find ways
around it." Edward Snowden


signature.asc
Description: Digital signature

Bug#720448: git-dpm update-patches wipes out dep-3 headers on previous patches

[Paul Elliott]

On Thu, Aug 29, 2013 at 08:26:12PM +0200, Bernhard R. Link wrote:
> * Paul Elliott  [130829 03:35]:
> > Ok I will send you an example. [...]
> > Tell me if this example is helpfull.
> 
> Yes, it is helpful. That seems to be a ugly effect of git wanting to
> allow multi-line short descriptions.
> 
> As a workaround till this is fixedI suggest starting each commit with
> a single line followed by an empty line. (As suggested by the DISCUSSION
> section of git-commit(1)).

That does not work. The dep-3 standard clearly states:
"A header always ends on the first empty line."

So the result would loose some of the dep-3.


-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117
---
"Encryption works. Properly implemented strong crypto systems are one
of the few things that you can rely on. Unfortunately, endpoint
security is so terrifically weak that NSA can frequently find ways
around it." Edward Snowden


signature.asc
Description: Digital signature

Bug#720448: git-dpm update-patches wipes out dep-3 headers on previous patches

[Paul Elliott]

Package: git-dpm
Version: 0.8.4-1
Severity: normal

Dear Maintainer,

When ever I call git-dpm update-patches for a new patch,
the dep-3 headers on old patches get replaced with inferior
non dep-3 stuff.

Here is sample part of diff from such an update-patches
--
- Description: Harden libarary against buffer overflow attack against sprintf
-  calls to sprintf with '%s' in format replaced with snprint calls.
- Forwarded: privately
- Author: Paul Elliott 
++From c722a348197dce0c48c23e5ed5438d92d229944a Mon Sep 17 00:00:00 2001
++From: Paul Elliott 
++Date: Wed, 21 Aug 2013 02:09:27 -0500
++Subject: =?UTF-8?q?harden=20library=20against=20buffer=20overflow=20attack?=
++ =?UTF-8?q?s=20on=20sprintf=0Acalls=20to=20sprintf=20with=20'%s'=20in=20fo?=
++ =?UTF-8?q?rmat=20string=20replaced=20with=20snprintf?=
--

Notice that the lines deleted were dep-3, because I hand edited it
to be dep-3. When the new patch installed, this dep-3 was
removed and replaced with unreadable stuff that is not dep-3!

dep-3 patch headers are highly recommended but not required by debian.
http://dep.debian.net/deps/dep3/



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

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

Versions of packages git-dpm depends on:
ii  git  1:1.8.4~rc2-1

git-dpm recommends no packages.

git-dpm suggests no packages.

-- no debconf information

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117
---
"Encryption works. Properly implemented strong crypto systems are one
of the few things that you can rely on. Unfortunately, endpoint
security is so terrifically weak that NSA can frequently find ways
around it." Edward Snowden


signature.asc
Description: Digital signature

Bug#719653: libswe: disables -Werror=format-security

[Paul Elliott]

On Tue, Aug 13, 2013 at 10:22:52PM +, Thorsten Glaser wrote:
> Source: libswe
> Version: 1.77.00.0005-7
> Severity: serious
> Justification: possible security impact
> 
> “ Log for successful build of libswe_1.77.00.0005-7 on m68k (dist=unstable) ”
> 
> buildd on ara5 for m68k dixit:
> 
> > Changes:
> […]
> >* disable these errors  -Wno-error=format-security -Wno-format
> 
> I think this should stay as RC bug until such time as the
> format string warnings are back as errors during compilation
> and indeed fixed.


The problem is that with when I went to debian/compat to 9
it added a  -Werror=format-security -Wformat
to the build this caused the build to fatally crash
since this is an astrological program used mostly in
a non-hostile context, I don't believe this library
should be withheld until the original author modifies
the source.

The  -Wno-error=format-security -Wno-format allows the library
to build.

I do believe an warning should be added to debian/README.Debian
and a bug filed against the original author. I plan to do
that with a new release I will be making soon.

Can you suggest a switch that will allow the build to complete,
but still flag the error?

I have looked at the source and the places where the user
can control the data in the varriable is in the test
program swetest, which would not often be exposed to a hostile
user.


-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117
---
"Encryption works. Properly implemented strong crypto systems are one
of the few things that you can rely on. Unfortunately, endpoint
security is so terrifically weak that NSA can frequently find ways
around it." Edward Snowden


signature.asc
Description: Digital signature

Bug#718481: unoconv --stdout fails

[Paul Elliott]

Package: unoconv
Version: 0.6-3
Severity: normal

Dear Maintainer,

When using the command:
unoconv --stdout -f pdf ../astrodocsrc/swisseph.doc   >  swisseph.pdf

I get the following error:
unoconv: UnoException during export phase:
Unable to store document to private:stream (ErrCode 3088)

Properties: ((com.sun.star.beans.PropertyValue){ Name = (string)"FilterName", 
Handle = (long)0x0, Value = (any){ (string)"writer_pdf_Export" }, State = 
(com.sun.star.beans.PropertyState)DIRECT_VALUE }, 
(com.sun.star.beans.PropertyValue){ Name = (string)"Overwrite", Handle = 
(long)0x0, Value = (any){ (boolean)true }, State = 
(com.sun.star.beans.PropertyState)DIRECT_VALUE }, 
(com.sun.star.beans.PropertyValue){ Name = (string)"OutputStream", Handle = 
(long)0x0, Value = (any){ (com.sun.star.uno.XInterface)0x8e00084{, 
supportedInterfaces={com.sun.star.io.XOutputStream,com.sun.star.lang.XTypeProvider}}
 }, State = (com.sun.star.beans.PropertyState)DIRECT_VALUE })


But if I replace "--stdout" with "-o myfile.pdf"
the command works.

The above command also worked in version 0.5.

Could you guesstimate how long to fix this bug?
It is preventing libswe from building. But I can
work around if I need to.


Thank You.



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

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

Versions of packages unoconv depends on:
ii  python3  3.3.2-3
ii  python3-uno  1:4.1.0-3

Versions of packages unoconv recommends:
ii  libreoffice-calc 1:4.1.0-3
ii  libreoffice-draw 1:4.1.0-3
ii  libreoffice-impress  1:4.1.0-3
ii  libreoffice-writer   1:4.1.0-3

unoconv suggests no packages.

-- no debconf information

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117
---
"Encryption works. Properly implemented strong crypto systems are one
of the few things that you can rely on. Unfortunately, endpoint
security is so terrifically weak that NSA can frequently find ways
around it." Edward Snowden


signature.asc
Description: Digital signature

Bug#672911: git-dpm: /usr/share/doc/git-dpm/manpage.html is not verbatim correct

[Paul Elliott]

Package: git-dpm
Version: 0.8.2-1
Severity: normal

Dear Maintainer,

If you look at /usr/share/doc/git-dpm/manpage.html with a browser
and copy some commands to the clipboard, then copy the same to a 
command window, the result will not work.

The commands in the web page contains invisible difference that
look right to the human eye but are not. There are characters that
look like hyphens but do not fuction as hyphens to a program.
There are also invisible characters that mess up the shell or git-dpm.

An example, (one of many possible), is this line:
git$B!](Bdpm import$B!](Bnew$B!](Bupstream $B!]!](Brebase 
../new$B!](Bstuff.orig.tar.gz

The above is from "Switching to a new upstream version" many of the
characters that look like hyphens in the above are not hyphens, and
will cause errors if copied to a commmand window.



-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages git-dpm depends on:
ii  git  1:1.7.10-1

git-dpm recommends no packages.

git-dpm suggests no packages.

-- no debconf information

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#661664: RFS: pyswisseph/1.77.00-0-3 [ITP]

[Paul Elliott]

On Wednesday, February 29, 2012 06:49:46 AM Jakub Wilk wrote:

> I don't intend to sponsor this package, but here's my review:

I have addressed these problems with
Bug#671272: RFS: pyswisseph/1.77.00.0+dfsg-2 [ITP]
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671272

perhaps this new one should be merged with the old one 661664.
I don't know how to do that, or if I have the privs.

> 
> * Paul Elliott , 2012-02-28, 18:32:
> >dget -x
> >http://mentors.debian.net/debian/pool/main/p/pyswisseph/pyswisseph_1.
> >77.00-0-3.dsc
> 
> Please get rid of “<645551 is the bug number of your ITP>” and “source
> package automatically created by stdeb” cruft from the changelog.
done
> 
> “Vcs-Browser” would be more consistent and more common capitalization
> than “Vcs-browser”.
done.
> 
> I'd merge all 3 changelog entries into one, and remove of the stuff from
> it. There's no point mentioning that e.g. you added copyright file in an
> initial release. Of course you did. (But OTOH patches you added might be
> worth mentioning.)
done in part.
> 
> Remove ${python:Breaks}, nothing generates this substitution variable
> anymore.
done.
> 
> The package description is very bad. Please see Developer's Reference
> §6.2.3.

Changed, but I welcome further suggestions.

> 
> The copyright file doesn't say where the upstream sources were obtained.
> This is serious violation of Policy §12.5.

Whole copyright file redone in dep5

> 
> I don't understand your lintian override. Why you can't correct the
> spelling?

Changed the reasons to:
# Stanislas Marquis holds the copyright on the email
# containing the mispelling. Maintainer can not create
# derived work by editing the email
python-swisseph-docs binary: spelling-error-in-copyright indended intended

#mispelling occurs in upstream's license.
#Maintainer is not authorized to change license.
python-swisseph-docs binary: spelling-error-in-copyright GNU Public License 
GNU General Public License

> 
> You can remove “--buildsystem=python_distutils” from debian/rules; dh is
> able to detect the build system automatically.
done
> 
> Please get rid of the “This file was automatically generated by stdeb”
> comment.
done

> 
> Do not use patches to remove files. Such patches are huge and are very
> likely cause conflicts in the future. Just remove the files in
> debian/rules (but see below).

I don't delete them anymore; I just don't use them.

> 
> The patches have “Forwarded: yes”, but were they actually forwarded? If
> yes, to who? They look Debian-specific to me.

replaced yes with the mail Message-Id: of the mail message sent to upstream 
who has no bug tracker. message is informational, suggests upstream not do 
anything.


> 
> Assuming that you meant to use DEP-3 for your patch headers, and as far
> as I understand the specification, you need an empty line before the
> pseudo-header.
I believe I have fixed this.
> 
> Please regenerate pydoc/* at build time.
done.

create new package:python-swisseph-docs for the results.


> 
> The binary package name is wrong. It should be python-swisseph, as per
> Python Policy §2.2.
fixed.
> 
> Upstream seems to support Python 3, too. Please consider building a
> separate python3-swisseph package.
done, but no way to test it.
> 
> The is no source for PDFs in the doc/ directory. You have the following
> options:
> - Ask upstream to include the source in their tarballs.
> - Repackage their tarballs.
> If you choose the latter option, you could also get rid of unneeded
> files that delete-no-longer-need-swe-files patch currently removes.
Deleted it instead, creating a dsfg package. If anyone needs these files they 
are in libswe-dev, a package, that does regenerate these files from source.

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: This is a digitally signed message part.

Bug#661665: RFS: openastro.org/1.1.25+dfsg-4 [ITP]

[Paul Elliott]

On Wednesday, May 09, 2012 08:00:50 AM Ansgar Burchardt wrote:
> forcemerge 661665 671277
> thanks
> 
> Hi Paul,
> 
> please update the old RFS bug if you address issues from a review (and
> the package wasn't uploaded).  It makes it easier to see the whole
> picture in a later review.  (Also the older RFS request would still show
> on the bug tracker.)

Yes I believe I have addressed most of the issues refeneced in the review.

I believe I have fixed most these issues with the release indicated by bug 
671277, which was merged with this one.

Case by case below:

> Lintian emits:
> P: openastro.org source: debian-control-has-unusual-field-spacing line 5
fixed.

> "debhelper (>= 7.0.50~)" instead of "debhelper (>= 7.0.50)" would be a
> bit more friendly to backporters.
> With dh_python2, you should use X-Python-Version, not XS-Python-Version.
> Also, remove XB-Python-Version.
> 
> The package is arch:all, so there's no point including ${shlibs:Depends}
> in Depends, as it won't be ever substituted.
fixed.

> Is there a reason for patching _comments_ in
> 0005-rename-openastro.py-as-required-by.patch? That looks strange.

Soebody might read the comments and be confused.

> When built with restrictive umask (e.g. 027), the package FTBFS:
> | dh_fixperms

I believe I have fixed this issue.

> Then, if I try to build it again it fails with:
> |  dpkg-source -b openastro.org-1.1.25

It now builds twice.


> Are the Python modules included in this package supposed to be used by
> other software? If yes, then the package name should be
> python-openastromod. If no, then please move them to a private
> directory.

I have filed a bug against upstream for poor documentation of this module. 
Because I believe it is too badly documented to be made public. I have moved 
it to a private location for now, and modified openastro script, to find it at 
this new location.

> Version number passed to distutils.core.setup() contains a trailing
> newline. Please report his to upstream.

I do not completely understand this. If this problem presists, I will file a 
bug against the upstream. Please tell me if this problem still exists!


> 
> As the BTS will only show the older report after merging:
> 
> The updated package can be found at
> 
> dget -x
> http://mentors.debian.net/debian/pool/main/o/openastro.org/openastro.org_1.
> 1.25+dfsg-4.dsc
> 
> Regards,
> Ansgar

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: This is a digitally signed message part.

Bug#671277: RFS: openastro.org/1.1.25+dfsg-4 [ITP]

[Paul Elliott]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "openastro.org"

 * Package name: openastro.org
   Version : 1.1.25+dfsg-4
   Upstream Author : Pelle van der Scheer 
 * URL : http://openastro.org/
   : https://launchpad.net/~pellesimon/+archive/ppa
 * License : GPLV3+
   Section : graphics

  It builds those binary packages:

openastro.org - Fully featured Open Source Astrology software

  To access further information about this package, please visit 
  the following URL:

  http://mentors.debian.net/package/openastro.org
  http://git.debian.org/?p=collab-maint/openastro.git
  git://git.debian.org/git/collab-maint/openastro.git

  Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/o/openastro.org/openastro.org_1.1.25+dfsg-4.dsc

  More information about hello can be obtained from http://openastro.org/

  This python program depends on the python extension module pyswisseph
  which is also being RFSed:
  http://mentors.debian.net/package/pyswisseph

  Changes since the last upload:

  * create dfsg package
  - delete pyswisseph/pyswisseph-1.75.01/doc
  * change bad permissions before build; use "a-" in command
  * restore source directory by deleting openastro
  * upgrade debian/copyright to dep-5
  * "debhelper (>= 7.0.50~)" instead of "debhelper (>= 7.0.50)"
  * use X-Python-Version, not XS-Python-Version
  * remove XB-Python-Version.
  * make openastromod private; move /usr/share/openastro.org


  Regards,
   Paul Elliott


signature.asc
Description: Digital signature

Bug#671272: RFS: pyswisseph/1.77.00.0+dfsg-2 [ITP]

[Paul Elliott]

Package: sponsorship-requests
Severity: normal

Package: sponsorship-requests
  Severity: normal 

  Dear mentors,

  I am looking for a sponsor for my package "pyswisseph"

 * Package name: pyswisseph
   Version : 1.77.00.0+dfsg-2
   Upstream Author : Stanislas Marquis 
 * URL : http://pyswisseph.chaosorigin.com/
   : http://pypi.python.org/pypi/pyswisseph
 * License : GPLV2+
   Section : python

  It builds those binary packages:

python-swisseph - Python extension to the Swiss Ephemeris
python-swisseph-docs - Python extension to the Swiss Ephemeris 
 (common documentation)
python3-swisseph - Python extension to the Swiss Ephemeris (Python 3)

  To access further information about this package, please visit the following 
URL:
  http://mentors.debian.net/package/pyswisseph

  Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/p/pyswisseph/pyswisseph_1.77.00.0+dfsg-2.dsc

  More information about pyswisseph can be obtained from 
  http://pypi.python.org/pypi/pyswisseph
  http://git.debian.org/?p=collab-maint/pyswisseph.git
  git://git.debian.org/git/collab-maint/pyswisseph.git

  This python extension module can be tested using openastro.org,
  a python program that is also being RFSed:
  http://mentors.debian.net/package/openastro.org


  Changes since the last upload:

  * switch to dfsg package
  * change copyright to dep-5, fix copyright file
  * Remove ${python:Breaks}, nothing generates this substitution variable 
  - anymore.
  * simplify description.
  * remove --buildsystem=python_distutils from debian/rules
  - dh is able to detect the build system automatically.
  * email message id in Forwarded: line.
  * add newline to override file.
  * change name to python-swisseph
  * rebuild pydoc from source.
  * create a documentation package
  * create a python3 version of this extension
  - using recommendations in:
  - http://wiki.debian.org/Python/LibraryStyleGuide


  Regards,
   Paul Elliott


signature.asc
Description: Digital signature

Bug#670453: RFS: libreoffice-converter/3.3-1 [ITP] (2nd try)

[Paul Elliott]

Package: sponsorship-requests
Severity: normal

Dear mentors,

  I am looking for a sponsor for my package "libreoffice-converter"

 * Package name: libreoffice-converter
   Version : 3.3-2
   Upstream Author : Petr Mladek 
   : Mirko Nasato 
 * URL : 
https://build.opensuse.org/package/show?project=3DLibreOffice:Unstable&package=3Dlibreoffice-converter
 * License : GNU LGPL v2.1
   Section : text

  It builds those binary packages:

libreoffice-converter - Commandline Document Converter Using LibreOffice.org

  To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/libreoffice-converter


  Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/libr/libreoffice-converter/libreoffice-converter_3.3-1.dsc

  More information about libreoffice-converter can be obtained from
  Vcs-Git: git://git.debian.org/collab-maint/libreoffice-converter.git
  Vcs-Browser: 
http://git.debian.org/?p=collab-maint/libreoffice-converter.git;a=summary

  Changes since the last upload:
  * patch from upstreams adds more types
  * update git Format: field


  * Initial release. (Closes: 663273)
  * get rid of old version numbering system
  * not a ds package anymore. upstream has a tarball!
  * new watch file
  * use debian/install
  * update debian/copyright for new tarball



  Regards,
   Paul Elliott


signature.asc
Description: Digital signature

Bug#668877: RFS: libreoffice-converter/3.3-1 [ITP]

[Paul Elliott]

Package: sponsorship-requests
Severity: normal

Dear mentors,

  I am looking for a sponsor for my package "libreoffice-converter"

 * Package name: libreoffice-converter
   Version : 3.3-1
   Upstream Author : Petr Mladek 
   : Mirko Nasato 
 * URL : 
https://build.opensuse.org/package/show?project=LibreOffice:Unstable&package=libreoffice-converter
 
 * License : GNU LGPL v2.1
   Section : text

  It builds those binary packages:

libreoffice-converter - Commandline Document Converter Using LibreOffice.org

  To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/libreoffice-converter


  Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/libr/libreoffice-converter/libreoffice-converter_3.3-1.dsc

  More information about libreoffice-converter can be obtained from 
  Vcs-Git: git://git.debian.org/collab-maint/libreoffice-converter.git
  Vcs-Browser: 
http://git.debian.org/?p=collab-maint/libreoffice-converter.git;a=summary

  Changes since the last upload:

  * Initial release. (Closes: 663273)
  * get rid of old version numbering system
  * not a ds package anymore. upstream has a tarball!
  * new watch file
  * use debian/install 
  * update debian/copyright for new tarball



  Regards,
   Paul Elliott


signature.asc
Description: Digital signature

Bug#667974: RFS: libreoffice-converter/3.3.34.1+ds-3 [ITP]

[Paul Elliott]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "libreoffice-converter"

 * Package name: libreoffice-converter
   Version : 3.3.34.1+ds-3
   Upstream Author : Petr Mladek 
 Jan Holesovsky 
 * URL : 
https://build.opensuse.org/package/show?project=LibreOffice:Unstable&package=libreoffice-converter
 * License : LGPL2.1+
   Section : text

  It builds those binary packages:

libreoffice-converter - Commandline Document Converter Using LibreOffice.org

  To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/libreoffice-converter


  Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/libr/libreoffice-converter/libreoffice-converter_3.3.34.1+ds-3.dsc

  More information about hello can be obtained from 
  
https://build.opensuse.org/package/show?project=LibreOffice:Unstable&package=libreoffice-converter

  In addition the packaging code can be found in:
  Vcs-Git: git://git.debian.org/collab-maint/libreoffice-converter.git
  Vcs-Browser: 
http://git.debian.org/?p=collab-maint/libreoffice-converter.git;a=summary

  Changes since the last upload:

  libreoffice-converter (3.3.34.1+ds-3) unstable; urgency=low
  * correct webpage in debian/control
  libreoffice-converter (3.3.34.1+ds-2) unstable; urgency=low
  * new upstream release 3.3.34.1
  libreoffice-converter (3.3.32.1+ds-1) unstable; urgency=low
  * Initial release (Closes: 663273)  
  * rules make. No Makefile.
  * enable Vcs fields. git repository in collab-maint


  Regards,
   Paul Elliott


signature.asc
Description: Digital signature

Bug#663273: ITP: libreoffice-converter -- Commandline Document Converter Using LibreOffice.org

[Paul Elliott]

Package: WNPP
Severity: wishlist


* Package name : libreoffice-converter
Version : 3.3-3
Upstream Author : Petr Mladek 
* URL : 
https://build.opensuse.org/package/files?package=libreoffice-converter&project=openSUSE%3ATumbleweed
  : http://www.artofsolving.com/files/DocumentConverter.py
* License : LGPL-2.1+
Description : Commandline Document Converter Using LibreOffice.org

 This package includes a simple script ooconvert that can be used to
 convert various document file formats on the commandline. It uses
 LibreOffice.org that guarantees the quality and the variety of
 available document file formats.



signature.asc
Description: Digital signature

Bug#661664: RFS: pyswisseph/1.77.00-0-3 [ITP]

[Paul Elliott]

On Thursday, March 01, 2012 05:19:48 PM Jakub Wilk wrote:
> * Paul Elliott , 2012-03-01, 14:03:
> >On the issue of the pdfs, those pdfs are rebuilt from source in another
> >package that depends on this package.
> 
> Personally, I don't buy the “source is in another package” argument. It
> might be true for the time being (I didn't check), but next version of
> the other package could come with different documentation or simply
> without it.

The source is not, and is not required to be, distributed anywhere but the 
source package. The source package will always be available through 
http://snapshot.debian.org/ if nowhere else. I have already checked, it is 
there.

One possibility, is to rebuild these files from source, and then delete both 
the source and the results. It is a monument to absurdity, but it satisfies all 
formal requirements, and may be the easiest choice.

I guess I will have to choose between that and a dfsg project. I will decide 
later.

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: This is a digitally signed message part.

Bug#661664: RFS: pyswisseph/1.77.00-0-3 [ITP]

[Paul Elliott]

On Wednesday, February 29, 2012 06:49:46 AM Jakub Wilk wrote:

I will look into this and create a new version. It will probably take a while.


On the issue of the pdfs, those pdfs are rebuilt from source in another
package that depends on this package.  References to those pdf's should be 
refered to that other package. Those pdf are not distributed by this package, 
they should have been  deleted with the convenience code. In this case of 
"Convenience copies of documentation" which is rebuilt from source in another 
dependant package, I am not sure if it is good enough to note the other 
package where the documentation is rebuilt from source, note the problem and 
move on, or if I must turn this package into a dfsg package?

What is your opinion?



> (Please use X-Debbugs-Cc, rather than Cc, when submittig bugs. That way
> the other parties will get the mail with bug number in the subject.)
> 
> I don't intend to sponsor this package, but here's my review:
> 
> * Paul Elliott , 2012-02-28, 18:32:
> >dget -x
> >http://mentors.debian.net/debian/pool/main/p/pyswisseph/pyswisseph_1.
> >77.00-0-3.dsc
> 
> Please get rid of “<645551 is the bug number of your ITP>” and “source
> package automatically created by stdeb” cruft from the changelog.
> 
> “Vcs-Browser” would be more consistent and more common capitalization
> than “Vcs-browser”.
> 
> I'd merge all 3 changelog entries into one, and remove of the stuff from
> it. There's no point mentioning that e.g. you added copyright file in an
> initial release. Of course you did. (But OTOH patches you added might be
> worth mentioning.)
> 
> Remove ${python:Breaks}, nothing generates this substitution variable
> anymore.
> 
> The package description is very bad. Please see Developer's Reference
> §6.2.3.
> 
> The copyright file doesn't say where the upstream sources were obtained.
> This is serious violation of Policy §12.5.
> 
> I don't understand your lintian override. Why you can't correct the
> spelling?
> 
> You can remove “--buildsystem=python_distutils” from debian/rules; dh is
> able to detect the build system automatically.
> 
> Please get rid of the “This file was automatically generated by stdeb”
> comment.
> 
> Do not use patches to remove files. Such patches are huge and are very
> likely cause conflicts in the future. Just remove the files in
> debian/rules (but see below).
> 
> The patches have “Forwarded: yes”, but were they actually forwarded? If
> yes, to who? They look Debian-specific to me.
> 
> Assuming that you meant to use DEP-3 for your patch headers, and as far
> as I understand the specification, you need an empty line before the
> pseudo-header.
> 
> Please regenerate pydoc/* at build time.
> 
> The binary package name is wrong. It should be python-swisseph, as per
> Python Policy §2.2.
> 
> Upstream seems to support Python 3, too. Please consider building a
> separate python3-swisseph package.
> 
> The is no source for PDFs in the doc/ directory. You have the following
> options:
> - Ask upstream to include the source in their tarballs.
> - Repackage their tarballs.
> If you choose the latter option, you could also get rid of unneeded
> files that delete-no-longer-need-swe-files patch currently removes.

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117



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

Bug#661665: RFS: openastro.org/1.1.25-2 [ITP]

[Paul Elliott]

Package: sponsorship-requests
Severity: normal

Dear mentors,

  I am looking for a sponsor for my package "openastro.org"

 * Package name: openastro.org
   Version : 1.1.25-2
   Upstream Author : Pelle van der Scheer 
 * URL : http://openastro.org/
   : https://launchpad.net/~pellesimon/+archive/ppa
   : http://pypi.python.org/pypi/OpenAstro.org/1.1.20
 * License : GPLV3+
   Section : graphics

  It builds those binary packages:

openastro.org - Fully featured Open Source Astrology software

  To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/openastro.org


  Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/o/openastro.org/openastro.org_1.1.25-2.dsc

  More information about hello can be obtained from http://openastro.org/
  One can also get all information about the package though its collab-maint
  git repository:
  http://git.debian.org/?p=collab-maint/openastro.git
  git://git.debian.org/git/collab-maint/openastro.git

  This python program depends on the python extension module pyswisseph
  which is also being RFSed:
  http://mentors.debian.net/package/pyswisseph

  Changes since the last upload:

  * correct location for ephe_path is 
/usr/share/libswe/ephe2:/usr/share/libswe/ephe
  * upgrade to Standards-Version: 3.9.3



  Regards,
   Paul Elliott

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

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


signature.asc
Description: Digital signature

Bug#661664: RFS: pyswisseph/1.77.00-0-3 [ITP]

[Paul Elliott]

Package: sponsorship-requests
Severity: normal

Dear mentors,

  I am looking for a sponsor for my package "pyswisseph"

 * Package name: pyswisseph
   Version : 1.77.00-0-3
   Upstream Author : Stanislas Marquis 
 * URL : http://pyswisseph.chaosorigin.com/
   : http://pypi.python.org/pypi/pyswisseph
 * License : GPLV2+
   Section : python

  It builds those binary packages:

python-pyswisseph - Python extension to the Swiss Ephemeris

  To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/pyswisseph


  Alternatively, one can download the package with dget using this command:

dget -x 
http://mentors.debian.net/debian/pool/main/p/pyswisseph/pyswisseph_1.77.00-0-3.dsc
  One can also get all information about the package though its collab-maint
  git repository:
   http://git.debian.org/?p=collab-maint/pyswisseph.git
   git://git.debian.org/git/collab-maint/pyswisseph.git

  More information about hello can be obtained 
  from http://pypi.python.org/pypi/pyswisseph

  This python extension module can be tested using openastro.org,
  a python program that is also being RFSed:
  http://mentors.debian.net/package/openastro.org

  Changes since the last upload:

  * ephe_path should be "/usr/share/libswe/ephe2:/usr/share/libswe/ephe"
  * upgrade to Standards-Version: 3.9.3


  Regards,
   Paul Elliott


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

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


signature.asc
Description: Digital signature

Bug#657275: closed by jald...@debian.org (Jaldhar H. Vyas) (Bug#657275: fixed in libswe 1.77.00.0005-1)

[Paul Elliott]

Ok this problem was caused by my moving the repositories required for building 
the arch indep libraries to Build-Depends-Indep: the rest of the fix was good.

So this is really a new bug, caused by my effort to fix the other one.

No matter. I have uploaded to mentors.net version 1.77.00.0005-4 which removes 
the Build-Depends-Indep: line, merging it into the Build-Depends: line.

This webpage says there is a way to seperate the archetecture only builds, but 
it is too complicated and would be difficult to maintain. Human time is more 
expensive than computer time.
http://asylum.madhouse-project.org/blog/2012/01/26/buildd-workarounds/

I have tested the new version on found here:
http://mentors.debian.net/package/libswe 0005-4

It builds with debuild,
sbuild -A -d unstable
sbuild --arch=i386 -d unstable

So I believe I have finally fixed this one.


-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: This is a digitally signed message part.

Bug#657275: fixed Re: Bug#657275: libswe: FTBFS - unoconv expects writable home, loopback network(?)

[Paul Elliott]

I have uploaded a new version at mentors.net:
described here:
http://mentors.debian.net/package/libswe
source package:
http://mentors.debian.net/debian/pool/main/libs/libswe/libswe_1.77.00.0005-1.dsc

It gives LO a fake writable empty home. It builds using sbuild which the old 
one did not.

unoconv, libreoffice-writer, libreoffice-java-common, procps are
under Build-Depends-Indep: rather than Build-Depends:

I am not sure about the loopback network thing you mentioned.

Please let me know how it comes out.

On Tuesday, January 24, 2012 10:28:17 PM Aaron M. Ucko wrote:
> Source: libswe
> Version: 1.77.00.0004-1
> Severity: serious
> Justification: fails to build from source
> 
> Automated builds of libswe are failing because unoconv (used to
> produce PDF and HTML documentation) assumes a writable home directory,
> which the autobuilders' build environments lack.  (Many also lack
> loopback network interfaces, which may be an issue as well.)  Given
> that the documentation winds up in a separate architecture-independent
> binary package anyway, I'd suggest arranging to build it only in full
> builds, which presumably run in less restrictive environments.
> (Relatedly, I'd suggest moving unoconv from Build-Depends to
> Build-Depends-Indep.)
> 
> Could you please look into it?
> 
> Thanks!

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: This is a digitally signed message part.

Bug#657275: libswe: FTBFS - unoconv expects writable home, loopback network(?)

[Paul Elliott]

I will begin looking at the problem immediately.

But as I am a beginning packager it may take me a while to completely 
understand the situation.

For instance, libswe just appeared in debian unstable, that means someone must 
have built it. How does the build environment of the autobuilder's differ from 
the one that built libswe on its path to unstable? Why is the autobuilder's 
environment correct? In other words, why is this not a bug against the 
autobuilder's software?

How can I duplicate the autobuilder's builds on my local machine to test this 
problem?

What is a "full" build and can I be sure that a full build will never occur in 
the autobuilder?

Thank You for considering this message.


On Tuesday, January 24, 2012 10:28:17 PM you wrote:
> Source: libswe
> Version: 1.77.00.0004-1
> Severity: serious
> Justification: fails to build from source
> 
> Automated builds of libswe are failing because unoconv (used to
> produce PDF and HTML documentation) assumes a writable home directory,
> which the autobuilders' build environments lack.  (Many also lack
> loopback network interfaces, which may be an issue as well.)  Given
> that the documentation winds up in a separate architecture-independent
> binary package anyway, I'd suggest arranging to build it only in full
> builds, which presumably run in less restrictive environments.
> (Relatedly, I'd suggest moving unoconv from Build-Depends to
> Build-Depends-Indep.)
> 
> Could you please look into it?
> 
> Thanks!

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117



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

Bug#647080: Please cancel this bug.

[Paul Elliott]

Further investigation revealed the error was comming
from the control file. 

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117



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

Bug#647080: lintian: maintainer-address-malformed error occurs after "Old Changelog:" line

[Paul Elliott]

Package: lintian
Version: 2.5.3
Severity: normal


I had a pre- intent to package (ITP)  maintainer, who did not want
to publish his email address. His changelog entries looked like this:
 -- M. Pettau   Tue, 28 Jun 2011 18:35:21 
+0200
I did not want to loose the previous history, but I am not authorized
to change the address.

Naturally, this resulted in maintainer-address-malformed errors, 
as is correct.
I added a line like this before the problematic entries:

Old Changelog:

But the maintainer-address-malformed errors did not go away.

They said on debian.mentors that I should file a bug against lintian.


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages lintian depends on:
ii  binutils   2.21.90.20111025-1
ii  bzip2  1.0.5-7   
ii  diffstat   1.54-1
ii  file   5.09-2
ii  gettext0.18.1.1-5
ii  intltool-debian0.35.0+20060710.1 
ii  libapt-pkg-perl0.1.25
ii  libclass-accessor-perl 0.34-1
ii  libdpkg-perl   1.16.1.1  
ii  libemail-valid-perl0.185-1   
ii  libipc-run-perl0.90-1
ii  libparse-debianchangelog-perl  1.2.0-1   
ii  libtimedate-perl   1.2000-1  
ii  liburi-perl1.59-1
ii  locales2.13-21   
ii  man-db 2.6.0.2-2 
ii  patchutils 0.3.2-1   
ii  perl [libdigest-sha-perl]  5.12.4-6  
ii  unzip  6.0-5 

lintian recommends no packages.

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

-- no debconf information


signature.asc
Description: Digital signature

Bug#646894: ITP: maitreya -- Vedic and western astrology

[Paul Elliott]

Package: wnpp
Severity: wishlist
Owner: Paul Elliott 


* Package name: maitreya
  Version : 6.0.5
  Upstream Author : Martin Pettau 
* URL : http://www.saravali.de/
* URL : https://launchpad.net/maitreya
* License : GPLv2+
  Programming Lang: C++
  Description : Vedic and western astrology

Maitreya is a free software for Vedic and western astrology.

The software supports

* Many features for the daily work of Vedic and western astrologers.
* A large number of calculation options that make the program a 
  stable basis for research purposes.
* High precision calculation.
* Several platforms including Windows, Linux and UNIX.

About the Name and the Logo Maitreya is the ardent disciple of
Maharishi Parasara, the author of Hora Shastra, the supreme standard
text of Vedic astrology.

The logo of Maitreya contains the pictures of two famous astrologers:
Alfred Witte and Sri Yukteswar Giri.

Alfred Witte is the founder of Uranian astrology, also known as german
Hamburger Schule (Hamburg School). Uranian astrology gives
surprisingly accurate predictions.

Swami Sri Yukteswar Giri is known as a supreme Vedic astrologer. He
incarnates the union of divine wisdom and astrological knowledge. His
disciple Paramahansa Yogananda became famous in the West.

The Sanskrit sloka is taken from Brihat Parasara Hora Shastra.

OM TAT SAT


signature.asc
Description: Digital signature

Bug#646309: Correction

[Paul Elliott]

* URL : http://openastro.org/
-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#646309: ITP: openastro.org -- Open Source Astrology

[Paul Elliott]

Package: wnpp
Severity: wishlist
Owner: Paul Elliott 


* Package name: openastro.org
  Version : 1.1.25
  Upstream Author : Pelle van der Scheer 
* URL : http://www.example.org/
  : https://launchpad.net/openastro.org
* License : GPLV3
  Programming Lang: Python
  Description : Open Source Astrology

 Features
  Natal/Radix Charts
  Transit Charts
  Synastry/Combine/Composite Charts
  Solar Return / Secondary Progressions
  Customizeable Planets & Aspects
  Additional celestial bodies: Chiron, Pholus, Ceres, Pallas, Juno, Vesta
  Fictional points: North/South Node, Day/Night Pars
  Cusp Aspects
  Monthly Timeline
  European and Traditional chart view
  Online Atlas (Geocoder) using google maps (virtually every location)
  Offline Atlas (Geonames) with about 80.000 major cities!
  Database export/import, Save as JPG, PNG, SVG, OAC
  Import from skylendar (*.skif), oroboros (*.xml)
  Import from astrolog32 (*.dat), zet8 dbase (*.zds)
  Ephemeris files for 1800 AD - 2400 AD (download seperately)


signature.asc
Description: Digital signature

Bug#646308: ITP: openastro.org -- Open Source Astrology

[Paul Elliott]

Package: wnpp
Severity: wishlist
Owner: Paul Elliott 


* Package name: openastro.org
  Version : 1.1.25
  Upstream Author : Pelle van der Scheer 
* URL : http://www.openastro.org/?Home
  : https://launchpad.net/openastro.org
* License : GPLV3   
  Programming Lang: Python  
  Description : Open Source Astrology
 Features
  Natal/Radix Charts
  Transit Charts
  Synastry/Combine/Composite Charts 
 Solar Return / Secondary Progressions
  Customizeable Planets & Aspects
  Additional celestial bodies: Chiron, Pholus, Ceres, Pallas, Juno, Vesta
  Fictional points: North/South Node, Day/Night Pars
  Cusp Aspects
  Monthly Timeline
  European and Traditional chart view
  Online Atlas (Geocoder) using google maps (virtually every location)
  Offline Atlas (Geonames) with about 80.000 major cities!
  Database export/import, Save as JPG, PNG, SVG, OAC
  Import from skylendar (*.skif), oroboros (*.xml)
  Import from astrolog32 (*.dat), zet8 dbase (*.zds)


signature.asc
Description: Digital signature

Bug#645551: WNPP: ITP:pyswisseph -- Python extension to the Swiss Ephemeris

[Paul Elliott]

Package: WNPP
Severity: wishlist

* Package name : pyswisseph
Version : 1.77.00
Upstream Author : S.Marquis 
* URL : http://pypi.python.org/pypi/pyswisseph
  : http://pyswisseph.chaosorigin.com/
* License : GPL2+
Description : Python extension to AstroDienst Swiss Ephemeris library.


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

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


signature.asc
Description: Digital signature

Bug#639346: (no subject)

[Paul Elliott]

We've confirmed this issue, we can also confirm that the patch fixes the 
issue for us in the squeeze release.


Thanks, Paul.

--
Paul Elliott, UNIX Systems Administrator
York Neuroimaging Centre, University of York




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

Bug#637085: linux-image-2.6.32-5-amd64: Hard hang following BUG: scheduling while atomic: swapper/0/0x10000100

[Paul Elliott]

A further update. We've successfully run 2.6.34-1~experimental.2 from 
snapshot.debian.org for 48 hours without any crashes (although we still 
see the UNDERRUN errors). I'll be testing 2.6.33 shortly.


--
Paul Elliott, UNIX Systems Administrator
York Neuroimaging Centre, University of York




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

Bug#637085: linux-image-2.6.32-5-amd64: Hard hang following BUG: scheduling while atomic: swapper/0/0x10000100

[Paul Elliott]

: [ 7678.042794]  [] ? 
worker_thread+0x0/0x21d
Aug 11 15:16:33 occiput kernel: [ 7678.042825]  [] ? 
kthread+0x79/0x81
Aug 11 15:16:33 occiput kernel: [ 7678.042856]  [] ? 
child_rip+0xa/0x20
Aug 11 15:16:33 occiput kernel: [ 7678.042886]  [] ? 
kthread+0x0/0x81
Aug 11 15:16:33 occiput kernel: [ 7678.042915]  [] ? 
child_rip+0x0/0x20
Aug 11 15:16:33 occiput kernel: [ 7678.042943] Code: 08 48 8b 50 08 48 
89 51 08 48 89 0a 48 89 00 48 89 40 08 66 ff 45 00 fb 66 0f 1f 44 00 00 
49 8b 45 f8 48 83 e0 fc 48 39 c5 74 04 <0f> 0b eb fe f0 41 80 65 f8 fe 
4c 89 e7 ff 54 24 38 48 8b 44 24
Aug 11 15:16:33 occiput kernel: [ 7678.043239] RIP  [] 
worker_thread+0x177/0x21d

Aug 11 15:16:33 occiput kernel: [ 7678.043274]  RSP 
Aug 11 15:16:33 occiput kernel: [ 7678.043706] ---[ end trace 
e0f3d4c037247dda ]---


6) Ran the test on 2.6.32-71.el6.x86_64 from CentOS 6. This kernel runs 
fine. Does not emit the underrun errors. For info, centos are using 
firmware 5.03.02 and driver version 8.03.01.05.06.0-k8. Squeeze is using 
firmware 5.03.02 and driver version 8.03.01-k6.
7) Ran the test on linux-image-3.0.0-1-amd64 (sid), 2.6.39-bpo.2-amd64 
and linux-image-2.6.38-bpo.2-amd64. All of these run fine. Does not emit 
the underrun errors as reported in the original bug report, could be 
related.


Where should we go from here?

[1] Our test script mounts 3 x 1TB ext4 volumes and then continuously 
loops through a bonnie++ test and four fio runs performing sequential 
reads, random read/write, sequential write and random write tests.


--
Paul Elliott, UNIX Systems Administrator
York Neuroimaging Centre, University of York




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

Bug#637085: linux-image-2.6.32-5-amd64: Hard hang following BUG: scheduling while atomic: swapper/0/0x10000100

[Paul Elliott]

Hi Jonathan,

On 08/08/11 16:16, Jonathan Nieder wrote:

I assume this is fairly reproducible even after a reboot?  Is the


Correct, we can reproduce the lock ups after a reboot following 5-60 
minutes of high I/O load (900MB/s plus).



stacktrace from the first sign of trouble in dmesg always the same?


I'm no expert at reading these but I believe it is the same. Here's the 
trace after the next reboot/lock up cycle:


[ 3705.959849] kernel BUG at 
/build/buildd-linux-2.6_2.6.32-35-amd64-aZSlKL/linux-2.6-2.6.32/debian/build/source_amd64_none/mm/slub.c:2969!

[ 3706.077621] invalid opcode:  [#1] SMP
[ 3706.113947] last sysfs file: 
/sys/devices/pci:00/:00:07.0/:06:00.1/host1/rport-1:0-3/target1:0:1/1:0:1:0/block/sdj/stat

[ 3706.235513] CPU 0
[ 3706.251928] Modules linked in: btrfs zlib_deflate crc32c libcrc32c 
ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs exportfs reiserfs 
ext4 jbd2 crc16 ext2 dm_round_robin dm_multipath scsi_dh loop sd_mod 
crc_t10dif snd_pcm joydev snd_timer snd soundcore snd_page_alloc usbhid 
hid evdev pcspkr hpilo hpwdt psmouse power_meter container processor 
button serio_raw ext3 jbd mbcache dm_mod hpsa cciss uhci_hcd ehci_hcd 
qla2xxx usbcore scsi_transport_fc nls_base scsi_tgt scsi_mod be2net 
thermal thermal_sys [last unloaded: scsi_wait_scan]
[ 3706.781628] Pid: 1845, comm: ext4-dio-unwrit Not tainted 
2.6.32-5-amd64 #1 ProLiant BL460c G7
[ 3706.882853] RIP: 0010:[]  [] 
kfree+0x55/0xcb

[ 3706.956205] RSP: 0018:8805851c7e00  EFLAGS: 00010246
[ 3707.017700] RAX: 0200 RBX: 88058553eed0 RCX: 
0042
[ 3707.091197] RDX: 88058553eea0 RSI: 0041 RDI: 
ea001352a590
[ 3707.167835] RBP: 88058553eea0 R08: 880585fdc0d0 R09: 
0008
[ 3707.245578] R10: 0014 R11: 880584a6b8b8 R12: 
a023ddcf
[ 3707.319659] R13: 88058553eed8 R14: 880584a6b880 R15: 
880584a6b880
[ 3707.393985] FS:  () GS:88001520() 
knlGS:

[ 3707.476061] CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
[ 3707.538541] CR2: 7f40377c CR3: 00026295b000 CR4: 
06f0
[ 3707.627218] DR0:  DR1:  DR2: 

[ 3707.707945] DR3:  DR6: 0ff0 DR7: 
0400
[ 3707.788003] Process ext4-dio-unwrit (pid: 1845, threadinfo 
8805851c6000, task 880584a6b880)

[ 3707.885120] Stack:
[ 3707.914054]  88058553eed0 88058553eea0 8805844b0928 
a023ddcf
[ 3707.992872] <0> 8805851c7ef8 e8a08680 88058553eed0 
810618e7
[ 3708.072050] <0> f9e0 880584a6bc38 880584a6b880 
8805851c7fd8

[ 3708.169803] Call Trace:
[ 3708.211806]  [] ? ext4_end_aio_dio_work+0x4e/0x5a 
[ext4]

[ 3708.285689]  [] ? worker_thread+0x188/0x21d
[ 3708.340716]  [] ? ext4_end_aio_dio_work+0x0/0x5a [ext4]
[ 3708.415673]  [] ? autoremove_wake_function+0x0/0x2e
[ 3708.495456]  [] ? worker_thread+0x0/0x21d
[ 3708.554553]  [] ? kthread+0x79/0x81
[ 3708.616011]  [] ? child_rip+0xa/0x20
[ 3708.675317]  [] ? kthread+0x0/0x81
[ 3708.730683]  [] ? child_rip+0x0/0x20
[ 3708.784232] Code: 83 c3 08 48 83 3b 00 eb ec 48 83 fd 10 0f 86 89 00 
00 00 48 89 ef e8 b9 e8 ff ff 48 89 c7 48 8b 00 84 c0 78 13 66 a9 00 c0 
75 04 <0f> 0b eb fe 5b 5d 41 5c e9 98 56 fd ff 48 8b 4c 24 18 4c 8b 4f

[ 3708.990151] RIP  [] kfree+0x55/0xcb
[ 3709.047553]  RSP 
[ 3709.095349] ---[ end trace fec09b541df2db86 ]---
[ 3709.158246] kernel tried to execute NX-protected page - exploit 
attempt? (uid: 0)


I now have serial console logging enabled on these servers so I can 
provide a fuller copy of the trace if required although I'm guessing the 
only useful output is that pasted above.



Did this machine work well with other kernels before (and if so,
which ones)?


The machine is new and so we haven't tried older kernels, we have tried 
the current bpo kernel and also experienced lock ups there although we 
didn't have remote/serial logging enabled at the time. I can retest and 
capture the logs if that would be useful.



If you get a chance to run memtest68+, that would also be useful, of
course.


We have 5 of these blades, all identical. I memtest86+'d them on arrival 
a couple of weeks ago, everything was clean. I'll retest tonight though, 
just to be on the safe side. I'll also repeat earlier tests on one of 
the other blades to capture a trace (we've seen lock ups on the other 
blades too but again, didn't have remote/serial logging enabled at the time)


Thanks, Paul.

--
Paul Elliott, UNIX Systems Administrator
York Neuroimaging Centre, University of York



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

Bug#637085: linux-image-2.6.32-5-amd64: Hard hang following BUG: scheduling while atomic: swapper/0/0x10000100

[Paul Elliott]

Package: linux-2.6
Version: 2.6.32-35
Severity: important


We are experiencing hard lock ups when under heavy load. See below for the log 
entries we have managed to capture via remote syslog before the machine locks 
completely. The machine is a BL460c G7 and is performing multiple I/O stress 
tests to ext4 filesystems presented over FC via a qlogic card connected to a 
P2000 MSA G3. Please let me know if we can provide any further information that 
may be useful in debugging.

Aug  8 12:28:32 sulcus kernel: [ .839061] kernel BUG at 
/build/buildd-linux-2.6_2.6.32-35-amd64-aZSlKL/linux-2.6-2.6.32/debian/build/source_amd64_none/kernel/workqueue.c:287!
Aug  8 12:28:32 sulcus kernel: [ .839121] invalid opcode:  [#1] SMP 
Aug  8 12:28:32 sulcus kernel: [ .839154] last sysfs file: 
/sys/devices/pci:00/:00:07.0/:06:00.1/host1/rport-1:0-0/target1:0:0/1:0:0:2/block/sdh/stat
Aug  8 12:28:32 sulcus kernel: [ .839211] CPU 0 
Aug  8 12:28:32 sulcus kernel: [ .839237] Modules linked in: xfs exportfs 
ext4 jbd2 crc16 ext2 dm_round_robin dm_multipath scsi_dh loop sd_mod crc_t10dif 
snd_pcm snd_timer snd soundcore hpwdt snd_page_alloc hpilo joydev psmouse 
power_meter evdev container serio_raw button pcspkr processor ext3 jbd mbcache 
usbhid hid dm_mod hpsa qla2xxx uhci_hcd scsi_transport_fc cciss scsi_tgt 
ehci_hcd usbcore nls_base scsi_mod thermal thermal_sys be2net [last unloaded: 
scsi_wait_scan]
Aug  8 12:28:32 sulcus kernel: [ .839577] Pid: 1996, comm: ext4-dio-unwrit 
Not tainted 2.6.32-5-amd64 #1 ProLiant BL460c G7
Aug  8 12:28:32 sulcus kernel: [ .839627] RIP: 0010:[]  
[] worker_thread+0x177/0x21d
Aug  8 12:28:32 sulcus kernel: [ .839687] RSP: 0018:880587189e40  
EFLAGS: 00010286
Aug  8 12:28:32 sulcus kernel: [ .839717] RAX:  RBX: 
880587189ef8 RCX: 880585e8db78
Aug  8 12:28:32 sulcus kernel: [ .839750] RDX: 880585e8db78 RSI: 
880587189e80 RDI: e8a08a00
Aug  8 12:28:32 sulcus kernel: [ .839783] RBP: e8a08a00 R08: 
880587188000 R09: 880015215780
Aug  8 12:28:32 sulcus kernel: [ .839816] R10: 01959d40 R11: 
880015215f98 R12: 880585e8db70
Aug  8 12:28:32 sulcus kernel: [ .839849] R13: 880585e8db78 R14: 
880583ad3170 R15: 880583ad3170
Aug  8 12:28:32 sulcus kernel: [ .839883] FS:  () 
GS:88001520() knlGS:
Aug  8 12:28:32 sulcus kernel: [ .839933] CS:  0010 DS: 0018 ES: 0018 CR0: 
8005003b
Aug  8 12:28:32 sulcus kernel: [ .839963] CR2: 7fd1e46237b0 CR3: 
0001ceca6000 CR4: 06f0
Aug  8 12:28:32 sulcus kernel: [ .839997] DR0:  DR1: 
 DR2: 
Aug  8 12:28:32 sulcus kernel: [ .840030] DR3:  DR6: 
0ff0 DR7: 0400
Aug  8 12:28:32 sulcus kernel: [ .840063] Process ext4-dio-unwrit (pid: 
1996, threadinfo 880587188000, task 880583ad3170)
Aug  8 12:28:32 sulcus kernel: [ .840114] Stack:
Aug  8 12:28:32 sulcus kernel: [ .840136]  f9e0 
880583ad3528 880583ad3170 880587189fd8
Aug  8 12:28:32 sulcus kernel: [ .840180] <0> 880583ad3170 
e8a08a18 e8a08a08 a0227d81
Aug  8 12:28:32 sulcus kernel: [ .840244] <0>  
880583ad3170 81064f1a 880587189e98
Aug  8 12:28:32 sulcus kernel: [ .840327] Call Trace:
Aug  8 12:28:32 sulcus kernel: [ .840361]  [] ? 
ext4_end_aio_dio_work+0x0/0x5a [ext4]
Aug  8 12:28:32 sulcus kernel: [ .840395]  [] ? 
autoremove_wake_function+0x0/0x2e
Aug  8 12:28:32 sulcus kernel: [ .840429]  [] ? 
worker_thread+0x0/0x21d
Aug  8 12:28:32 sulcus kernel: [ .840459]  [] ? 
kthread+0x79/0x81
Aug  8 12:28:32 sulcus kernel: [ .840492]  [] ? 
child_rip+0xa/0x20
Aug  8 12:28:32 sulcus kernel: [ .840522]  [] ? 
kthread+0x0/0x81
Aug  8 12:28:32 sulcus kernel: [ .840551]  [] ? 
child_rip+0x0/0x20
Aug  8 12:28:32 sulcus kernel: [ .840580] Code: 08 48 8b 50 08 48 89 51 08 
48 89 0a 48 89 00 48 89 40 08 66 ff 45 00 fb 66 0f 1f 44 00 00 49 8b 45 f8 48 
83 e0 fc 48 39 c5 74 04 <0f> 0b eb fe f0 41 80 65 f8 fe 4c 89 e7 ff 54 24 38 48 
8b 44 24 
Aug  8 12:28:32 sulcus kernel: [ .840877] RIP  [] 
worker_thread+0x177/0x21d
Aug  8 12:28:32 sulcus kernel: [ .840912]  RSP 
Aug  8 12:28:32 sulcus kernel: [ .841438] ---[ end trace 0794cb72e58dafb2 
]---
Aug  8 12:28:32 sulcus kernel: [ .914059] BUG: scheduling while atomic: 
swapper/0/0x1100
Aug  8 12:28:32 sulcus kernel: [ .914131] Modules linked in: xfs exportfs 
ext4 jbd2 crc16 ext2 dm_round_robin dm_multipath scsi_dh loop sd_mod crc_t10dif 
snd_pcm snd_timer snd soundcore hpwdt snd_page_alloc hpilo joydev psmouse 
power_meter evdev container serio_raw button pcspkr processor ext3 jbd mbcache 
usbhid hid dm_mod hpsa qla2xxx uhci_hcd scsi_transport_fc cciss scsi_tgt 
ehci_hcd usbcore nls_ba

Bug#636089: ITP: swe-data -- Swiss Ephemeris Data

[Paul Elliott]

Package: WNPP
Severity: wishlist


* Package name: swe-data
  Version : 1.77.00
  Upstream Author : Dieter Koch and Alois Treindl
* URL : http://www.astro.com/swisseph/
* License : GPL2+
  Programming Lang: C
  Description : The SWISS EPHEMERIS is the high precision ephemeris 
developed by Astrodienst, largely based upon the DE406 ephemeris from 
NASA's JPL.

The Swiss Ephemeris Data is the data necessary to use the SWISS EPHEMERIS.
It consists of 36 Meg in 54 seperate files. Any particular file
could be needed or not needed depending on what the user is doing.
For more infomation on the Swiss Ephemeris data, see:
http://www.astro.com/swisseph/swisseph.htm


The Swiss Ephemeris offers these advantages:

The Swiss Ephemeris is based upon the latest planetary and lunar
ephemeris, DE405/406, developed by NASA's Jet Propulsion
Laboratory. The original integration, DE405, covered the years 3000 BC
to 3000 AD and required 550 Mb of disk space. DE406 is a compressed
version of DE405 which requires 200 MB while maintaining a precision
of better than 1 m for the moon and 25 m for the planets. These data
have been further compressed with sophisticated compression techniques
developed by Astrodienst. The ephemeris now requires for the complete
6000 years only 5 Mb for all planets except the Moon, and 13 Mb for
the Moon. This compressed ephemeris reproduces the JPL data with 0.001
arcseconds precision.

We have extended the timespan of the JPL ephemeris by numerical
integration, so that Swiss Ephemeris covers the years 5400 BC to 5400
AD, a total of 10'800 years. For this extended timespan the ephemeris
requires 32 Mbytes of ephemeris files.

All transformation steps from the inertial timeframe of the JPL DE406
integration to the reference frame for astrological coordinates (true
equinox of date), all corrections like relativistic aberration,
deflection of light in the gravity field of the Sun etc. have been
performed with utmost care and precision so that the target precision
of 0.001 arcsec is maintained through all transformation steps. Never
before has such a high precision ephemeris been available to
astrologers.

Swiss Ephemeris contains three ephemerides. The user can choose
whether he/she wants to use the original JPL DE406 data (if available
at his/her site), the compressed Swiss Ephemeris data (the default) or
a built in semianalytic theory by Steve Moshier. The Swiss Ephemeris
package switches automatically to the available best precision
ephemeris dependent on which installed ephemeris files it finds. Even
without any stored ephemeris files, using the Moshier model, planetary
positions with better than 0.1 seconds of arc precision are available
(3 arcsec for the Moon).

In addition to the astronomical planets as contained in the JPL
integration, we have included all other bodies and hypothetical
factors which are of interest to the astrologer. We have used our own
numerical integration program to provide ephemerides for ALL known
asteroids. There are over 55'000 of them and nobody will be able to
use them all. We distribute these extended asteroid files via our
download area; there are also CDROMs available with large sets of
asteroid files.

Asteroid reaserachers may be interested in a December 1998 article in
the Economist magazine about the naming of asteroids.

Speed: The Swiss Ephemeris is precise and fast. On our Linux test
machine, a 1000 MHz Pentium III, we compute 10'000 complete sets of
planetary positions, i.e. 10'000 x 11 planets, in 9 seconds. This is
0.9 milliseconds for the complete set of exact planetary positions
(consecutive 1 day steps).



-- System Information:
Debian Release: 5.0.8
  APT prefers oldstable-proposed-updates
  APT policy: (500, 'oldstable-proposed-updates'), (500, 'oldstable')
Architecture: i386 (i686)

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

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#635672: ITP: libswe -- Swiss Ephemeris

[Paul Elliott]

Package: WNPP
Severity: wishlist

* Package name: libswe
  Version : 1.77.00
  Upstream Author : Dieter Koch and Alois Treindl
* URL : http://www.astro.com/swisseph/
* License : GPL2+
  Programming Lang: C
  Description : The SWISS EPHEMERIS is the high precision ephemeris 
developed by Astrodienst, largely based upon the DE406 ephemeris from 
NASA's JPL.

The Swiss Ephemeris offers these advantages:

The Swiss Ephemeris is based upon the latest planetary and lunar
ephemeris, DE405/406, developed by NASA's Jet Propulsion
Laboratory. The original integration, DE405, covered the years 3000 BC
to 3000 AD and required 550 Mb of disk space. DE406 is a compressed
version of DE405 which requires 200 MB while maintaining a precision
of better than 1 m for the moon and 25 m for the planets. These data
have been further compressed with sophisticated compression techniques
developed by Astrodienst. The ephemeris now requires for the complete
6000 years only 5 Mb for all planets except the Moon, and 13 Mb for
the Moon. This compressed ephemeris reproduces the JPL data with 0.001
arcseconds precision.

We have extended the timespan of the JPL ephemeris by numerical
integration, so that Swiss Ephemeris covers the years 5400 BC to 5400
AD, a total of 10'800 years. For this extended timespan the ephemeris
requires 32 Mbytes of ephemeris files.

All transformation steps from the inertial timeframe of the JPL DE406
integration to the reference frame for astrological coordinates (true
equinox of date), all corrections like relativistic aberration,
deflection of light in the gravity field of the Sun etc. have been
performed with utmost care and precision so that the target precision
of 0.001 arcsec is maintained through all transformation steps. Never
before has such a high precision ephemeris been available to
astrologers.

Swiss Ephemeris contains three ephemerides. The user can choose
whether he/she wants to use the original JPL DE406 data (if available
at his/her site), the compressed Swiss Ephemeris data (the default) or
a built in semianalytic theory by Steve Moshier. The Swiss Ephemeris
package switches automatically to the available best precision
ephemeris dependent on which installed ephemeris files it finds. Even
without any stored ephemeris files, using the Moshier model, planetary
positions with better than 0.1 seconds of arc precision are available
(3 arcsec for the Moon).

In addition to the astronomical planets as contained in the JPL
integration, we have included all other bodies and hypothetical
factors which are of interest to the astrologer. We have used our own
numerical integration program to provide ephemerides for ALL known
asteroids. There are over 55'000 of them and nobody will be able to
use them all. We distribute these extended asteroid files via our
download area; there are also CDROMs available with large sets of
asteroid files.

Asteroid reaserachers may be interested in a December 1998 article in
the Economist magazine about the naming of asteroids.

Speed: The Swiss Ephemeris is precise and fast. On our Linux test
machine, a 1000 MHz Pentium III, we compute 10'000 complete sets of
planetary positions, i.e. 10'000 x 11 planets, in 9 seconds. This is
0.9 milliseconds for the complete set of exact planetary positions
(consecutive 1 day steps).



-- System Information:
Debian Release: 5.0.8
  APT prefers oldstable-proposed-updates
  APT policy: (500, 'oldstable-proposed-updates'), (500, 'oldstable')
Architecture: i386 (i686)

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

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


signature.asc
Description: Digital signature

Bug#613969: /etc/init.d/apache2 status fails to comply with LSB spec

[Paul Elliott]

Package: apache2.2-common
Version: 2.2.16-6
Severity: normal
Tags: patch

As shipped the init script for Apache2 fails to return LSB compliant error 
codes when the status is queried. This is important when using LSB scripts with 
clustering solutions such as Pacemaker[1] that require init scripts to return 
correct error codes. 

The following patch fixes the apache2 init script to return the correct codes 
when quering status according to the LSB spec[2]. Please consider including the 
patch in a future point release update. 

Thanks!

Patch:
--- apache2.2-common.apache2.init   2011-02-18 14:49:37.0 +
+++ /etc/init.d/apache2 2011-02-18 14:48:04.0 +
@@ -266,7 +266,11 @@
exit 0
else
echo "Apache2$DIR_SUFFIX is NOT running."
-   exit 1
+   if [ -e "$PIDFILE" ]; then
+   exit 1
+   else
+   exit 3
+   fi
fi
;;
*)

[1] http://www.linux-ha.org/wiki/LSB_Resource_Agents
[2] 
http://refspecs.freestandards.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

-- Package-specific info:
List of enabled modules from 'apache2 -M':
  alias auth_basic authn_file authz_default authz_groupfile
  authz_host authz_user autoindex cgid deflate dir env mime
  negotiation reqtimeout setenvif status

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

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

Versions of packages apache2 depends on:
ii  apache2-mpm-worker2.2.16-6   Apache HTTP Server - high speed th
ii  apache2.2-common  2.2.16-6   Apache HTTP Server common files

apache2 recommends no packages.

apache2 suggests no packages.

Versions of packages apache2.2-common depends on:
ii  apache2-utils   2.2.16-6 utility programs for webservers
ii  apache2.2-bin   2.2.16-6 Apache HTTP Server common binary f
ii  libmagic1   5.04-5   File type determination library us
ii  lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip
ii  mime-support3.48-1   MIME files 'mime.types' & 'mailcap
ii  perl5.10.1-17Larry Wall's Practical Extraction 
ii  procps  1:3.2.8-9/proc file system utilities

-- no debconf information



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

Bug#612894:

[Paul Elliott]

This is the relevant commit and diff that was applied upstream. I've
tested this locally and it fixes the issue for us. Please can the patch be
applied and an update released in the next point release? mhy will be
happy to NMU the fix if necessary.

commit b27e9b4bd79c30c7910a02122069695044f05477
Author: Matt Robinson 
Date:   Wed Dec 1 17:16:03 2010 -0800

[#5081] Revert "Fix #4349 - Parsing with ignoreimport=true was always
loadin

The fix for #4349 caused --parse-only not to detect syntax errors when
--ignore-import was used by adding a return statement that bypassed the
initial import:

commit 760e418d254a8d2198d2c6eb466d783a5930ef47
def perform_initial_import
+   return if Puppet.settings[:ignoreimport]

The problem that #4349 fixed was more generally fixed in commit
99c1019e1d3402ec8e476dc859d5aaef82ec4f69 for ticket #4798 so the return
statement is no longer needed, so reverting the commit for #4349 does
not reintroduce the problem of an import loop error when running puppet
doc.

Paired-with: Jesse Wolfe

diff --git a/lib/puppet/resource/type_collection.rb
b/lib/puppet/resource/type_c
index 63d1103..6a03458 100644
--- a/lib/puppet/resource/type_collection.rb
+++ b/lib/puppet/resource/type_collection.rb
@@ -153,7 +153,6 @@ class Puppet::Resource::TypeCollection
   end

   def perform_initial_import
-return if Puppet.settings[:ignoreimport]
 parser = Puppet::Parser::Parser.new(environment)
 if code = Puppet.settings.uninterpolated_value(:code,
environment.to_s) and
   parser.string = code
diff --git a/spec/unit/resource/type_collection_spec.rb
b/spec/unit/resource/typ
index 577aea4..ff4c222 100644
--- a/spec/unit/resource/type_collection_spec.rb
+++ b/spec/unit/resource/type_collection_spec.rb
@@ -426,14 +426,6 @@ describe Puppet::Resource::TypeCollection do
   @parser.expects(:parse).raises ArgumentError
   lambda { @code.perform_initial_import }.should
raise_error(Puppet::Error)
 end
-
-it "should not do anything if the ignore_import settings is set" do
-  Puppet.settings[:ignoreimport] = true
-  @parser.expects(:string=).never
-  @parser.expects(:file=).never
-  @parser.expects(:parse).never
-  @code.perform_initial_import
-end
   end

   describe "when determining the configuration version" do





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

Bug#612894: puppet: Syntax validation with --parseonly is broken when used with --ignoreimport

[Paul Elliott]

Package: puppet
Version: 2.6.2-4
Severity: normal


It no longer appears possible to perform syntax checking in post-commit hooks 
when using puppet --parseonly and --ignoreimport due to upstream bug #5081:

http://projects.puppetlabs.com/issues/5081

The issue is fixed in 2.6.5 according to the upstream report.

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

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

Versions of packages puppet depends on:
ii  adduser 3.112+nmu2   add and remove users and groups
ii  facter  1.5.7-3  a library for retrieving facts fro
pn  libopenssl-ruby(no description available)
ii  libruby [libxmlrpc-ruby 4.5  Libraries necessary to run Ruby 1.
ii  libshadow-ruby1.8   1.4.1-8  Interface of shadow password for R
ii  libxmlrpc-ruby  4.2  transitional dummy package
ii  lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip
ii  puppet-common   2.6.2-4  Centralized configuration manageme
ii  ruby1.8 1.8.7.302-2  Interpreter of object-oriented scr

Versions of packages puppet recommends:
pn  libaugeas-ruby1.8  (no description available)
ii  ruby [rdoc]   4.5An interpreter of object-oriented 

Versions of packages puppet suggests:
pn  libselinux-ruby1.8 (no description available)
pn  puppet-el  (no description available)
pn  vim-puppet (no description available)

-- Configuration Files:
/etc/default/puppet changed [not included]
/etc/init.d/puppet changed [not included]

-- 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#546402: additional infromation

[Paul Elliott]

I had an Adaptec 29160N attached to the original system. On a hunch, I removed 
it.


 The debian 5.0 system that previously would not boot, then boot without 
problem!

It still gave the error message:
"ACPI:Expecting a [Reference] package element, found type 0"
but it was non-fatal and the system went on to boot!

So the problem with this system hang was the 29160N!

the 29160 did not cause any problems for opensuse 11.1 however!

the smolt profile, referered to in the original message has been updated to 
reflect the abscence of the 29160N!

-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117



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

Bug#546402: installation-reports bug: fails to boot.

[Paul Elliott]

Package: installation-reports

Boot method: 
booted installer from hard disk using hd-media/initrd.gz, hd-media/vmlinuz


Image version: 
debian-502a-i386-DVD-1.iso  debian-502a-i386-DVD-4.iso
debian-502a-i386-DVD-2.iso  debian-502a-i386-DVD-5.iso
debian-502a-i386-DVD-3.iso  debian-update-5.0.2-i386-DVD-1.iso

Date: 
Sept 12 2009 6pm.

Machine: 
desktop Biostar MCP6P M2+

Processor: DUAL CORE AMD
Memory: 2GIG
Partitions: 
This was produce using an open suse system using same hardware,
can not do under booted system as it will not boot.

major minor  #blocks  name

   8 0  312571224 sda
   8 1  1 sda1
   8 5 104359 sda5
   8 6 104391 sda6
   8 79414058 sda7
   8 8  104856223 sda8
   8 9  104856223 sda9
   810   93233196 sda10
   816   71687369 sdb
   817  48163 sdb1
   8181052257 sdb2
   819   60123262 sdb3
   820   10458315 sdb4
Output of lspci -knn (or lspci -nn):

This was produce using an open suse system using same hardware,
can not do under booted system as it will not boot.


00:00.0 RAM memory [0500]: nVidia Corporation MCP61 Memory Controller 
[10de:03ea] (rev a1)
00:01.0 ISA bridge [0601]: nVidia Corporation MCP61 LPC Bridge [10de:03e0] (rev 
a2)
00:01.1 SMBus [0c05]: nVidia Corporation MCP61 SMBus [10de:03eb] (rev a2)
00:01.2 RAM memory [0500]: nVidia Corporation MCP61 Memory Controller 
[10de:03f5] (rev a2)
00:02.0 USB Controller [0c03]: nVidia Corporation MCP61 USB Controller 
[10de:03f1] (rev a3)
00:02.1 USB Controller [0c03]: nVidia Corporation MCP61 USB Controller 
[10de:03f2] (rev a3)
00:04.0 PCI bridge [0604]: nVidia Corporation MCP61 PCI bridge [10de:03f3] (rev 
a1)
00:05.0 Audio device [0403]: nVidia Corporation MCP61 High Definition Audio 
[10de:03f0] (rev a2)
00:06.0 IDE interface [0101]: nVidia Corporation MCP61 IDE [10de:03ec] (rev a2)
00:07.0 Bridge [0680]: nVidia Corporation MCP61 Ethernet [10de:03ef] (rev a2)
00:08.0 IDE interface [0101]: nVidia Corporation MCP61 SATA Controller 
[10de:03f6] (rev a2)
00:08.1 IDE interface [0101]: nVidia Corporation MCP61 SATA Controller 
[10de:03f6] (rev a2)
00:09.0 PCI bridge [0604]: nVidia Corporation MCP61 PCI Express bridge 
[10de:03e8] (rev a2)
00:0b.0 PCI bridge [0604]: nVidia Corporation MCP61 PCI Express bridge 
[10de:03e9] (rev a2)
00:0c.0 PCI bridge [0604]: nVidia Corporation MCP61 PCI Express bridge 
[10de:03e9] (rev a2)
00:0d.0 VGA compatible controller [0300]: nVidia Corporation GeForce 6150SE 
nForce 430 [10de:03d0] (rev a2)
00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
HyperTransport Technology Configuration [1022:1100]
00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
Address Map [1022:1101]
00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
DRAM Controller [1022:1102]
00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
Miscellaneous Control [1022:1103]
01:06.0 SCSI storage controller [0100]: Adaptec AIC-7892A U160/m [9005:0080] 
(rev 02)


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

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

Comments/Problems:

Booted installation process from hard disk.



Resulting system will not boot!
"ACPI:Expecting a [Reference] package element, found type 0

was the last thing to display on console before hang.

Tried adding acpi=off to boot parameters.
This resulted in hang with complaint about drivers fan.ko, processor.ko and 
thermal.ko
not existing. Still hangs.

This smalt entry describes the hardware. It was made with opensuse
on the same hardware, since the installed debian system will not boot.
http://www.smolts.org/show?uuid=pub_172fb22b-274c-4829-876f-d5da9c019622



Installed system



 In the bug report, describe what the problem is, including the last visible 
kernel messages in the event of a kernel hang. Describe the steps that you did 
which brought the system into the problem state. 
-- 
Paul Elliott   1(512)837-1096
pelli...@blackpatchpanel.com   PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


pgp51ZspiHrqG.pgp
Description: PGP signature

Bug#424843: RFP: peless -- peless is GTK tabbed text file lister.

[Paul Elliott]

Package: wnpp
Severity: wishlist

Peless is a simple text file lister. It only displays files and
never modifies them. It can display multiple files using a tabbed notebook,
display international characters, and search the files for regular expressions
or literal expressions. Users can choose the fonts used to display files.
License: GPL

The following files were made with ubuntu 7.04 but they probably
can be rebuilt in debian:
ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.108-1.dsc
ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.108-1_i386.deb
ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.108-1.diff.gz
ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.108-1_i386.build
ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.108-1_i386.changes
ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless_1.108.orig.tar.gz
ftp://ftp.BerliOS.de/pub/peless/ubuntu.704/peless-1.108.tar.gz



-- 
Paul Elliott   1(512)837-1096
[EMAIL PROTECTED]PMB 181, 11900 Metric Blvd Suite J
http://www.io.com/~pelliott/pme/   Austin TX 78758-3117


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]