Bug#939310: missing systray icon for blueman-applet

[Tom Marble]

On Thursday, September 5, 2019, Christopher Schramm 
wrote:

> Peter, In 2.1 you have to provide --loglevel debug to get a useful output.
>
> Tom, awesomewm with KDE as well?
>

No. i3

Glad to help debug.

--Tom

Bug#939310: missing systray icon for blueman-applet

[Tom Marble]

On Tue, 3 Sep 2019 23:16:08 +0200 Christopher Schramm  
wrote:
> sounds like there's some issue with the libappindicator-based icon 
> implementation which disables the GTK-based one. Your edit effectively 
> avoids the latter.
> 
> Did you try blueman 2.1.1-1 yet?

I am running unstable with blueman 2.1.1-1+b1 and I still have this
behavior -- the icon is NOT shown :(

Regards,

--Tom

Bug#882247:

[Tom Marble]

Mike:

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


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

Thank you!

--Tom

Bug#882247:

[Tom Marble]

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

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

   * What led up to the situation?

Just starting firefox.

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

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

   * What was the outcome of this action?

Blank window showing 

-- no debconf information

Bug#871913: ITP: boot-clj -- Build tooling for Clojure

[Tom Marble]

Package: wnpp
Severity: wishlist
Owner: Tom Marble <tmar...@info9.net>

* Package name: boot-clj
  Version : 2.7.1
  Upstream Author : Alan Dipert
* URL : https://github.com/boot-clj/boot
* License : EPL
  Programming Lang: Java
  Description : Build tooling for Clojure

Boot is a Clojure build framework and ad-hoc Clojure script
evaluator. Boot provides a runtime environment that includes all of
the tools needed to build Clojure projects from scripts written in
Clojure that run in the context of the project.

This package will be maintained by the Debian Clojure Team.

Bug#871781: ITP: shimdandy -- Shim wrapping multiple Clojure runtimes into the same JVM

[Tom Marble]

Package: wnpp
Severity: wishlist
Owner: Tom Marble <tmar...@info9.net>

* Package name: shimdandy
  Version : 1.2.0
  Upstream Author : Toby Crawley
* URL : https://github.com/projectodd/shimdandy
* License : EPL
  Programming Lang: Java
  Description : Shim wrapping multiple Clojure runtimes into the same JVM

A Clojure runtime shim, allowing for multiple Clojure runtimes in the same JVM.

Clojure has a static runtime (implemented as static methods off of
clojure.lang.RT), so to run multiple runtimes in the same JVM, they
have to be loaded in isolated ClassLoader trees. ShimDandy provides a
mechanism for isolating the runtimes within a non-Clojure application,
and for calling in to the runtimes from the app.

This library is a dependency for the Clojure build tool 'boot'
and will be maintained by the Debian Java Team.

Bug#859012: maven-debian-helper: unnecessarily gendered pronoun in prompt

[Tom Marble]

Package: maven-debian-helper
Version: 2.1.3
Severity: normal

Dear Maintainer,

In this source file you will find a prompt...

http://sources.debian.net/src/maven-debian-helper/2.1.3/maven-packager-utils/src/main/java/org/debian/maven/packager/GenerateDebianFilesMojo.java/?hl=249#L249

... which includes the substring "please enter his name". In 2017
we can do better to help Debian be more inclusive. What's more
we don't know if there is only one copyright holder.

Proposed fix: "please enter their name(s)"

Respectfully,

--Tom




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

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

Versions of packages maven-debian-helper depends on:
ii  default-jdk 2:1.8-58
ii  default-jdk-headless2:1.8-58
ii  libmaven-clean-plugin-java  2.5-1
ii  libmaven-compiler-plugin-java   3.2-5
ii  libmaven-jar-plugin-java2.4-1
ii  libmaven-resources-plugin-java  2.6-1
ii  libmaven-site-plugin-java   2.1-4
ii  libplexus-velocity-java 1.2-1
ii  libsurefire-java2.17-3
ii  libxml2-utils   2.9.4+dfsg1-2.2
ii  maven   3.3.9-4
ii  maven-repo-helper   1.9.2
ii  unzip   6.0-21
ii  velocity1.7-5

maven-debian-helper recommends no packages.

Versions of packages maven-debian-helper suggests:
pn  apt-file  
ii  devscripts2.17.5
pn  libmaven-javadoc-plugin-java  
ii  subversion1.9.5-1

-- no debconf information

Bug#819811: ITP: leiningen -- simple build system for Clojure

[Tom Marble]

Elana Hashman  writes:
> Should I also go ahead and file RFPs for the missing packages for 
> visibility?

Sure!

Thanks!

--Tom

Bug#819811: ITP: leiningen -- simple build system for Clojure

[Tom Marble]

Tom Marble <tmar...@info9.net> writes:
> Based on the fabulous work of ehashman and the help of technomancy
> I've made some minor reformatting of the "state of packaging leiningen"
> below.

As everyone knows leiningen is a special case package due
to it's signicance to the Clojure ecosystem. As such
it doesn't make sense to track the packaging work by
constantly updating this bug.

Therefore I've created a new page on the Debian wiki for this purpose:
https://wiki.debian.org/Clojure/Leiningen

Indeed I've created a entire tree to support Clojure work:
https://wiki.debian.org/Clojure

Which has been shameless cribbed from
https://wiki.debian.org/Java

Let's continue to collaborate with the Java team and
meet online in #debian-java

Regards,

--Tom

Bug#819811: ITP: leiningen -- simple build system for Clojure

[Tom Marble]

Based on the fabulous work of ehashman and the help of technomancy
I've made some minor reformatting of the "state of packaging leiningen"
below. The biggest change is that I'm not calling out transitive
deps (on leiningen missing deps).

In terms of next steps

1. technomancy is already addressing the
   'deps with unstable-version > leiningen 2.7.2-SNAPSHOT'
   issues upstream.

2. We should probably start with 
   'deps with unstable-version < leiningen 2.7.2-SNAPSHOT'

3. Then the big work is on missing deps (which will be recursive :)
   NOTE: I had some packaging on alioth for some of these
   which probably can be reprised.

Question on java/clojure policy.. should names with a dot
be converted to a dash?
  Does [org.clojure/tools.nrepl "0.2.12"]
  want to be libtools.nrepl-clojure or libtools-nrepl-clojure ?
 (my guess is the latter)???

Regards,

--Tom

** deps with unstable-version == leiningen 2.7.2-SNAPSHOT
*** [org.clojure/data.xml "0.0.8"]
unstable: https://packages.debian.org/sid/libdata-xml-clojure
leiningen: https://github.com/technomancy/leiningen/blob/master/project.clj#L10
*** [commons-io "2.5"]
unstable: https://packages.debian.org/sid/libcommons-io-java 
leiningen: https://github.com/technomancy/leiningen/blob/master/project.clj#L11 
 
*** [clojure-complete "0.2.4"]
unstable: https://packages.debian.org/sid/libcomplete-clojure
leiningen: https://github.com/technomancy/leiningen/blob/master/project.clj#L17
NOTE: check for old packaging on alioth
*** [robert/hooke "1.3.0"]
unstable: https://packages.debian.org/sid/librobert-hooke-clojure
leiningen: 
https://github.com/technomancy/leiningen/blob/master/leiningen-core/project.clj#L9
 
*** [org.tcrawley/dynapath "0.2.5"]
unstable: https://packages.debian.org/sid/libdynapath-clojure
leiningen: 
https://github.com/technomancy/leiningen/blob/master/leiningen-core/project.clj#L11
*** [org.apache.maven.wagon/wagon-http "2.10"]
unstable: https://packages.debian.org/sid/libwagon2-java
leiningen: 
https://github.com/technomancy/leiningen/blob/master/leiningen-core/project.clj#L12
 
*** [com.hypirion/io "0.3.1"]
unstable: https://packages.debian.org/sid/libcom-hypirion-io-clojure
leiningen: 
https://github.com/technomancy/leiningen/blob/master/leiningen-core/project.clj#L13
NOTE: check for old packaging on alioth

** deps with unstable-version < leiningen 2.7.2-SNAPSHOT
*** [slingshot "0.12.2"]
unstable: 0.10.3 https://packages.debian.org/sid/libslingshot-clojure
leiningen: https://github.com/technomancy/leiningen/blob/master/project.clj#L19
NOTE: check for old packaging on alioth
*** [bultitude "0.2.8"]
unstable: 0.2.7 https://packages.debian.org/sid/libbultitude-clojure
leiningen: 
https://github.com/technomancy/leiningen/blob/master/leiningen-core/project.clj#L7
 
*** [com.cemerick/pomegranate "0.3.1"]
unstable: 0.2.0 https://packages.debian.org/sid/libpomegranate-clojure
leiningen: 
https://github.com/technomancy/leiningen/blob/master/leiningen-core/project.clj#L12

** deps with unstable-version > leiningen 2.7.2-SNAPSHOT
*** [org.clojure/tools.macro "0.1.2"]
unstable: 0.1.5 https://packages.debian.org/sid/libtools-macro-clojure
leiningen: 0.1.2 
https://github.com/technomancy/leiningen/blob/master/test_projects/sample-profile-meta/project.clj#L10
*** [commons-codec "1.6"]
unstable: 1.10 https://packages.debian.org/sid/libcommons-codec-java
leiningen: 
./test_projects/managed-deps-snapshot/project.clj
./test_projects/managed-deps/project.clj
*** [clj-stacktrace "0.2.4"]
unstable: 0.2.6 https://packages.debian.org/sid/libclj-stacktrace-clojure
leiningen: 
./resources/leiningen/help/project.clj: :dependencies [[clj-stacktrace 
"0.2.4"]]}
3:17 < tmarble> technomancy: we have [clj-stacktrace "0.2.6"] 
https://packages.debian.org/sid/libclj-stacktrace-clojure
13:17 < tmarble> but you have ./resources/leiningen/help/project.clj: 
:dependencies [[clj-stacktrace "0.2.4"]]}
13:17 < tmarble> ... can that be bumped?
13:22 < technomancy> tmarble: that file is help text, not an actual project.clj 
=)
13:22 < tmarble> nvm :)

** deps missing from leiningen 2.7.2-SNAPSHOT
*** [clj-http "2.0.1"]
unstable: https://packages.debian.org/sid/libclj-http-clojure
leiningen: https://github.com/technomancy/leiningen/blob/master/project.clj#L21
NOTE:  [clj-http "2.0.1"]
[commons-codec "1.10" :exclusions [[org.clojure/clojure]]]
[org.apache.httpcomponents/httpclient "4.5" :exclusions 
*** [org.clojure/tools.nrepl "0.2.12"]
unstable: https://packages.debian.org/sid/libtools.nrepl-clojure
leiningen: https://github.com/technomancy/leiningen/blob/master/project.clj#L16
*** [cheshire "5.6.3"]
unstable: https://packages.debian.org/sid/libcheshire-clojure
leiningen: https://github.com/technomancy/leiningen/blob/master/project.clj#L20
*** [classlojure "0.6.6"]
unstable: https://packages.debian.org/sid/libclasslojure-clojure
leiningen: 
https://github.com/technomancy/leiningen/blob/master/leiningen-core/project.clj#L8
*** [pedantic "0.2.0"]
unstable: 

Bug#819811: ITP: leiningen -- simple build system for Clojure

[Tom Marble]

Elana Hashman  writes:
> Finally following up with some conversations I had at Clojure/conj, I'd 
> like to help get the ball rolling on this again. Based on leiningen 
> 2.7.1's dependencies, here's what we'll need to package/upgrade to make 
> this happen.

Awesome, thank you!!!

I've added technomancy on Bcc: as he dropped into #debian-java a while
back asking how he could help.

Here's the link to this bug (and the rest of the context):
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819811

FWIW I'd also like to see boot packaged... Last time I checked, though,
boot has a build dep on leiningen.

Regards,

--Tom

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

[Tom Marble]

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

--Tom

Bug#840322: emacs24-common: emacsclient fails with *ERROR*: Invalid function

[Tom Marble]

Rob Browning  writes:
> Hmm.  Does foo.txt have anything odd in it, [...]

No, it's a non-existant file.

> and does it still crash if
> you do something like this:
>
>   $ emacs -Q --daemon=foo
>   $ emacsclient -c -s foo /tmp/foo.txt

Interestingly it does not crash:

tmarble@cerise 175 :) emacs -Q --daemon=foo

Warning: due to a long standing Gtk+ bug
http://bugzilla.gnome.org/show_bug.cgi?id=85715
Emacs might crash when run in daemon mode and the X11 connection is 
unexpectedly lost.
Using an Emacs configured with --with-x-toolkit=lucid does not have this 
problem.
Starting Emacs daemon.
tmarble@cerise 176 :)

In another terminal
  emacsclient -c -s foo /tmp/foo.txt
worked just fine

> Just wondering if -Q avoids the problem.

I updated my MELPA and restarted Emacs.. and now I can't
reproduce the bug.. emacsclient just works.

Feel free to close the bug now (sorry for the noise)!

--Tom

Bug#840322: emacs24-common: emacsclient fails with *ERROR*: Invalid function

[Tom Marble]

Package: emacs24-common
Version: 24.5+1-7
Severity: normal

Dear Maintainer,

Recently emacsclient stopped working in unstable.

   * What led up to the situation?

Upgrading emacs24.

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


tmarble@cerise 127 :) emacsclient /tmp/foo.txt
Waiting for Emacs...
*ERROR*: Invalid function: (\` ((\, file) _))
tmarble@cerise 128 :( emacsclient --no-wait --eval '(find-file "/tmp/foo.txt")'
*ERROR*: Invalid function: (\` ((\, file) _))
tmarble@cerise 129 :( 

   * What was the outcome of this action?

The filename passed as an argument was not visited in emacs (as emacsclient 
crashed).
It appears that emacsclient fails to eval any elisp expression.

   * What outcome did you expect instead?

I expected the file /tmp/foo.txt to be visited in a new emacs buffer.

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


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

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

Versions of packages emacs24-common depends on:
ii  dpkg1.18.10
ii  emacsen-common  2.0.8
ii  install-info6.3.0.dfsg.1-1+b1

Versions of packages emacs24-common recommends:
ii  emacs24-el  24.5+1-7

Versions of packages emacs24-common suggests:
pn  emacs24-common-non-dfsg  
ii  ncurses-term 6.0+20160917-1

-- no debconf information

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

[Tom Marble]

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

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

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

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

Regards,

--Tom

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


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

Bug#754504: ITP: libpedantic-clojure -- A Clojure library designed to be used with pomegrante to check for common unexpected cases.

[Tom Marble]

Package: wnpp
Severity: wishlist
Owner: Tom Marble tmar...@info9.net

* Package name: libpedantic-clojure
  Version : 0.1.0
  Upstream Author : Nelson Morris nmor...@nelsonmorris.net
* URL : https://github.com/xeqi/pedantic
* License : EPL-1.0
  Programming Lang: Clojure
  Description : A Clojure library designed to be used with pomegrante to 
check for common unexpected cases.

This package is a build-dep for leiningen 2 -- an essential
build tool for Clojure packages.

This package will be created and maintained by the
Debian Clojure Maintainers pkg-clojure-maintain...@lists.alioth.debian.org.

Paul Tagliamonte paul...@debian.org has offered to sponsor this package.

Regards,

--Tom


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

Bug#739295: python3-dbus: rebuild required for python 3.4

[Tom Marble]

Package: python3-dbus
Version: 1.2.0-2+b1
Severity: wishlist

Dear Maintainer,

The recent upload of python 3.4 to experimental causes
this library to fail with _dbus_bindings not found.

Please consider rebuilding this library before
python 3.4 hits unstable.

--Tom

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

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

Versions of packages python3-dbus depends on:
ii  libc6 2.17-97
ii  libdbus-1-3   1.8.0-1
ii  libdbus-glib-1-2  0.102-1
ii  libglib2.0-0  2.38.2-5
ii  python3   3.4~rc1-1
pn  python3:any   none

Versions of packages python3-dbus recommends:
ii  python3-gi  3.10.2-2

Versions of packages python3-dbus suggests:
pn  python-dbus-doc   none
pn  python3-dbus-dbg  none

-- no debconf information


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

Bug#739296: python3-gi: rebuild required for python 3.4

[Tom Marble]

Package: python3-gi
Version: 3.10.2-2
Severity: wishlist

Dear Maintainer,

The recent upload of python 3.4 to experimental causes
this library to fail with ImportError: No module named 'gi._gi'.

Please consider rebuilding this library before
python 3.4 hits unstable.

--Tom

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

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

Versions of packages python3-gi depends on:
ii  gir1.2-glib-2.01.36.0-2+b1
ii  libc6  2.17-97
ii  libffi63.0.13-12
ii  libgirepository-1.0-1  1.36.0-2+b1
ii  libglib2.0-0   2.38.2-5
ii  multiarch-support  2.17-97
ii  python33.4~rc1-1
pn  python3:anynone

python3-gi recommends no packages.

python3-gi suggests no packages.

-- no debconf information


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

Bug#715207: apel failure prevents emacs upgrade

[Tom Marble]

On 07/07/2013 01:58 AM, Tatsuya Kinoshita wrote:
 If log files /tmp/elc.* exist, please show me.

There are several of these (but only two distinct ones --
for emacs23 and emacs24):

root@octane 138# cat elc.5ytbJrSCnHqL
emacs23 -q -no-site-file -batch -l __myinit.el -f batch-byte-compile alist.el 
apel-ver.el atype.el broken.el calist.el emu.el file-detect.el filename.el 
install.el inv-19.el inv-23.el invisible.el mcharset.el mcs-20.el mcs-e20.el 
mule-caesar.el path-util.el pccl-20.el pccl.el pces-20.el pces-e20.el pces.el 
pcustom.el poe.el poem-e20_3.el poem-e20.el poem.el product.el pym.el 
richtext.el static.el tinycustom.el
emacs23: error while loading shared libraries: libGL.so.1: cannot open shared 
object file: No such file or directory
root@octane 139# cat elc.FN8bYZJvv8I3
emacs24 -q -no-site-file -batch -l __myinit.el -f batch-byte-compile alist.el 
apel-ver.el atype.el broken.el calist.el emu.el file-detect.el filename.el 
install.el inv-19.el inv-23.el invisible.el mcharset.el mcs-20.el mcs-e20.el 
mule-caesar.el path-util.el pccl-20.el pccl.el pces-20.el pces-e20.el pces.el 
pcustom.el poe.el poem-e20_3.el poem-e20.el poem.el product.el pym.el 
richtext.el static.el tinycustom.el
emacs24: error while loading shared libraries: libGL.so.1: cannot open shared 
object file: No such file or directory
root@octane 140#

 Also, please show me the output of:
 
   # apt-get install --reinstall apel
   # ls -ltrd /usr/share/emacs24/site-lisp/*
   # ls -latr /usr/share/emacs24/site-lisp/*
   # ls -ltrd /tmp/elc.*
 
   # apt-get install --reinstall emacs24-nox
   # ls -ltrd /usr/share/emacs24/site-lisp/*
   # ls -latr /usr/share/emacs24/site-lisp/*
   # ls -ltrd /tmp/elc.*
 
 If the problem is reproducible on your system, I'll try to dig up a
 cause of the problem.

I have attached the log as apel-reinstall.log.xz

It appears that the problem was related to libGL.so.1.
And there are various other unrelated install problems.

Regards,

--Tom



apel-reinstall.log.xz
Description: Binary data


signature.asc
Description: OpenPGP digital signature

Bug#715207: apel failure prevents emacs upgrade

[Tom Marble]

Package: apel
Version: 10.8+0.20120427-3
Severity: important

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

   * What led up to the situation?

A routine upgrade include apel 10.8+0.20120427-3 which caused
all installed emacs upgrades to fail.

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

What WAS effective was downgrading apel manually to 10.8+0.20120427-1 via
wget 
http://ftp.us.debian.org/debian/pool/main/a/apel/apel_10.8%2b0.20120427-1_all.deb

   * What was the outcome of this action?

With apel 10.8+0.20120427-3 all emacs upgrades failed resulting in broken 
packages.

   * What outcome did you expect instead?

The magic of apt to Just Work :)

--Tom

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (300, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages apel depends on:
ii  emacs24-nox [emacsen]  24.3+1-1.1

apel recommends no packages.

apel suggests no packages.

-- no debconf information


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

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

[Tom Marble]

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

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

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

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

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

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

Regards,

--Tom



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

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

[Tom Marble]

All:

I can confirm the segfault with 11-10 :(

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

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

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

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

Regards,

--Tom

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



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

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

[Tom Marble]

All:

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

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

HTH,

--Tom



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

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

[Tom Marble]

All:

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

And it still segfaults :(

Snippets from Xorg.0.log below.

Regards,

--Tom

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





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

Bug#633982: sun-java6-bin: Multiarch support issue with Sun Java

[Tom Marble]

John:

I tried to reproduce your problem on my amd64 system running
unstable, but jenkins worked for me.

I configured the system to use the DLJ version of the JDK:
# update-java-alternatives --set java-6-sun

Once running I was able to confirm that the nss libraries
are loaded by doing (where PID is the jenkins java process):
$ grep nss /proc/29683/maps

The fact it is working may be a side effect of recent
libc change to temporarily disable multi-arch on amd64:
http://packages.debian.org/changelogs/pool/main/e/eglibc/eglibc_2.13-11/changelog

When multi-arch is re-enabled you have a couple of potential
workarounds:

1. As you mention above, you can explicitly add the architecture
   specific directory to the library path (in /etc/default/jenkins):

JAVA_MULTIARCH=-Djava.library.path=/usr/lib/`dpkg-architecture 
-qDEB_HOST_MULTIARCH`
JAVA_ARGS=$JAVA_ARGS $JAVA_MULTIARCH

2. You can choose to use OpenJDK:
  a. System wide change
 # update-java-alternatives --set java-6-openjdk
  b. Jenkins only change:
 in /etc/default/jenkins
 JAVA=/usr/lib/jvm/java-6-openjdk/jre/bin/java

During this transition period you will likely need to
update this configuration when using OpenJDK:
--- /etc/java-6-openjdk/security/nss.cfg ---
name = NSS
nssLibraryDirectory = /usr/lib/x86_64-linux-gnu
nssDbMode = noDb
attributes = compatibility
---

We will work to insure that OpenJDK is integrated
properly with Debian. As we will never have the sources
for sun-java6 you will need to file a bug with upstream
to request for it to read a config file such as
/etc/java-6-sun/security/nss.cfg so that distributions
can make such adaptations.

Regards,

--Tom





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

Bug#633982: sun-java6-bin: Multiarch support issue with Sun Java

[Tom Marble]

On 07/27/2011 08:53 AM, Livingston, John A wrote:
 [...] We still have one or two applications that have little glitches unless 
 Sun Java is used, but this is probably the push we've needed to default to
 using OpenJDK.

At the risk of going off topic a little bit for this bug
report I'm quite interested in those cases where OpenJDK
is not a replacement for Sun Java. As I was originally the
OpenJDK representative for Sun in Debian I am quite interested
in this topic.

If you had a specific test case (or cases) I would encourage
you to try them with openjdk-7 from the experimental repository:
http://packages.debian.org/search?keywords=openjdk-7searchon=namessuite=allsection=all

We are also collaborating with upstream in modularizing the Java
packaging for Debian for JDK 8:
http://penta.debconf.org/dc11_schedule/events/718.en.html

Please feel free to followup this topic on the
Debian Java List debian-j...@lists.debian.org.

Regards,

--Tom



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

Bug#595060: signing-party: Please include kspsig

[Tom Marble]

Package: signing-party
Version: 1.1.3-1
Severity: normal


By request in #594907 please add the kspsig program to signing-party.

The upstream tarball for released version 0.1 can be
extracted as follows:

$ git clone --no-checkout git://github.com/tmarble/kspsig.git
$ cd kspsig/
$ git checkout -b version-0.1 v0.1
$ tar zcf ../kspsig_0.1.tar.gz --exclude='.git.*'  ./*

Thanks,

--Tom

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

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

Versions of packages signing-party depends on:
ii  gnupg   1.4.10-4 GNU privacy guard - a free PGP rep
ii  libc6   2.11.2-2 Embedded GNU C Library: Shared lib
ii  libclass-methodmaker-perl   2.15-2   Perl module for creating generic m
ii  libgnupg-interface-perl 0.42-3   Perl interface to GnuPG
ii  libmailtools-perl   2.06-1   Manipulate email in perl programs
ii  libmime-tools-perl  5.428-1  Perl5 modules for MIME-compliant m
ii  libterm-readkey-perl2.30-4   A perl module for simple terminal 
ii  libtext-template-perl   1.45-1   Text::Template perl module
ii  perl5.10.1-14Larry Wall's Practical Extraction 
ii  qprint  1.0.dfsg.2-2 encoder and decoder for quoted-pri

Versions of packages signing-party recommends:
ii  dialog1.1-20100428-1 Displays user-friendly dialog boxe
ii  libgd-gd2-noxpm-perl  1:2.39-2   Perl module wrapper for libgd - gd
ii  libpaper-utils1.1.24 library for handling paper charact
ii  libtext-iconv-perl1.7-2  converts between character sets in
ii  postfix [mail-transport-a 2.7.1-1High-performance mail transport ag
ii  recode3.6-17 Character set conversion utility
ii  whiptail  0.52.11-1  Displays user-friendly dialog boxe

Versions of packages signing-party suggests:
ii  imagemagick8:6.6.0.4-2.2 image manipulation programs
ii  mutt   1.5.20-9  text-based mailreader supporting M
ii  texlive-latex-recommended  2009-10   TeX Live: LaTeX recommended packag
pn  wipe   none(no description available)

-- 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#594907: ITP: kspsig -- Key Signing Party signature verification tool

[Tom Marble]

Package: wnpp
Severity: wishlist
Owner: Tom Marble tmar...@info9.net


* Package name: kspsig
  Version : 0.1
  Upstream Author : Tom Marble tmar...@info9.net
* URL : http://github.com/tmarble/kspsig
* License : GPL-3
  Programming Lang: Python
  Description : Key Signing Party signature verification tool

If  you  are  concerned  about  the  hash algorithm strength used 
in key signing this tool seeks to answer questions you may have 
following a key signing party...
- How strongly did others sign my key?
- How strongly did I sign other's keys?
- How strong are the signatures for my key?

This tool only reads keyrings: it does not do any key modifications.



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

Bug#594907: ITP: kspsig -- Key Signing Party signature verification tool

[Tom Marble]

On 08/30/2010 04:34 PM, Joerg Jaspert wrote:
 And this needs an own package because of 
 
 Sounds like it should be in signing-party instead.

Indeed it very well may want to be part of signing-party when
it grows up... The primary rationale for it being separate now
includes:

1. As this tool is making assertions about signature strength which
   important to our web of trust it is recommended that this
   tool get peer testing and review on it's own (as to avoid
   versioning signing-party at this early stage).

2. It has been suggested that the correct implementation of
   this tool is to read the keyring directly -- instead of using
   gpg -- in which case the implementation may change significantly.

If these goals should be accomplished without creating a
separate package I would be happy to pursue that approach.

Respectfully,

--Tom




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

Bug#567244: grub-common: fix grub-set-default and savedefault

[Tom Marble]

Package: grub-common
Version: 1.98~20100126-1
Severity: normal
Tags: patch

All:

This minor patch enables grub-set-default(8) and the savedefault
option to work correctly by reading the grubenv saved_entry.

Regards,

--Tom


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

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

Versions of packages grub-common depends on:
ii  base-files  5.0.0Debian base system miscellaneous f
ii  dpkg1.15.5.6 Debian package management system
ii  gettext-base0.17-8   GNU Internationalization utilities
ii  install-info4.13a.dfsg.1-5   Manage installed documentation in 
ii  libc6   2.10.2-5 Embedded GNU C Library: Shared lib
ii  libfreetype62.3.11-1 FreeType 2 font engine, shared lib
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages grub-common recommends:
ii  os-prober 1.35   utility to detect other OSes on a 

Versions of packages grub-common suggests:
pn  grub-emu  none (no description available)
pn  multiboot-doc none (no description available)

-- no debconf information
--- 00_header~  2010-01-27 22:35:16.946281548 -0600
+++ 00_header   2010-01-27 22:28:44.365351645 -0600
@@ -43,6 +43,9 @@
   load_env
 fi
 set default=${GRUB_DEFAULT}
+if [ \${saved_entry} ]; then
+  set default=\${saved_entry}
+fi
 if [ \${prev_saved_entry} ]; then
   set saved_entry=\${prev_saved_entry}
   save_env saved_entry

Bug#561309: firmware-linux-nonfree: needs firmware for module r8169

[Tom Marble]

Ben (et al):

Your patch (with Stefan's addition, replacing dev-name with r8169) also 
worked
for me on an Intel i7 920 system (amd64) running unstable (w/o the firmware).

Dec 20 18:39:08 octane kernel: [1.100454] r8169 Gigabit Ethernet driver 
2.3LK-NAPI loaded
Dec 20 18:39:08 octane kernel: [1.100471] r8169 :06:00.0: PCI INT A - 
GSI 18 (level, low) - IRQ 18
Dec 20 18:39:08 octane kernel: [1.100960] eth0: RTL8168d/8111d at 
0xc9c7a000, 00:1f:bc:08:c4:16, XID 081000c0 IRQ 30
Dec 20 18:39:08 octane kernel: [1.105168] r8169 :06:00.0: firmware: 
requesting rtl8168d-1.fw
Dec 20 18:39:08 octane kernel: [1.106433] Failed to load rtl8168d-1.fw.
...
Dec 20 18:39:08 octane kernel: [   12.736957] r8169: eth0: link up

This NIC is onboard the mobo: EVGA X58 SLI LE
http://www.evga.com/products/moreInfo.asp?pn=141-BL-E757-TRfamily=Motherboard%20Family

Thanks!

--Tom



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

Bug#393153: sun-java5-jdk: please package 1.5.0-09

[Tom Marble]

Albert (et al):

Thank you for your interest in 1.5.0_09. This issue is also
captured in an upstream bug [1].

It turns out that the _09 release has been especially delicate.
Nevertheless I expect to push out the DLJ bundles for _09 in the
next day or so -- within our goal of a 1-week delay from the
BCL (classic) bundles.

I will let you know when the DLJ bundles are ready for Debian
packaging.

Regards,

--Tom

[1] https://jdk-distros.dev.java.net/issues/show_bug.cgi?id=17

_
[EMAIL PROTECTED]
Senior Java Performance Engineer   Sun Microsystems, Inc.
http://blogs.sun.com/tmarbleWhat do you want from Java Libre?


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

Bug#370295: DLJ prevents running jython with sun-java

[Tom Marble]

Walter Landry wrote:
 [...]
 All of the examples given above are good, but libgetenv-java is about
 as clear as you can get.  It only depends on java2-runtime and libc,
 and it serves as a replacement for java.lang.System.getenv.  It
 creates a hybrid implementation.
 
 If you want to argue that it is the other packages fault, go ahead.
 That would make the java2-runtime virtual package much less useful, in
 which case there should be a java2-runtime-free virtual package.

Obviously making sun-java5 not provide java2-runtime (or whatever
provides Debian Java Policy settles upon) defeats the purpose
of packaging Sun Java.

I appreciate your trying to address an entire class of problems, but
in the case of libgetenv-java it appears that the jar is malformed.
We're it formed correctly it would be in it's own namespace.

The README.Debian says:

libgetenv-java for Debian
-

To use libgetenv-java in an application, make sure your classpath includes
/usr/share/java/libgetenv-java.jar and LD_LIBRARY_PATH includes /usr/lib/jni

 -- Mark Howard [EMAIL PROTECTED], Fri, 27 Jun 2003 15:50:01 +0100

Inspection of the jar file in the aforementioned package
shows:

=== /usr/share/java/libgetenv-java.jar ===
 0 Tue Oct 25 05:09:28 CDT 2005 META-INF/
48 Tue Oct 25 05:09:28 CDT 2005 META-INF/MANIFEST.MF
   376 Tue Oct 25 05:09:28 CDT 2005 uk/co/tigress/System.class

[EMAIL PROTECTED] 148% jar xf /usr/share/java/libgetenv-java.jar
[EMAIL PROTECTED] 151% cd uk/co/tigress/
/tmp/uk/co/tigress
[EMAIL PROTECTED] 155% javap System
Compiled from System.java
public class System extends java.lang.Object{
public static native java.lang.String getenv(java.lang.String);
}
[EMAIL PROTECTED] 156%

So IN THIS CASE... it appears that the jar file is malformed
because I cannot even compile a Java program to use this alternative class
by using import uk.co.tigress.System; (see attached altenv.java).
This would appear to because the source file did not specify that
it was in the package uk.co.tigress;.

[EMAIL PROTECTED] 212% javac -cp .:/usr/share/java/libgetenv-java.jar 
altenv.java
altenv.java:3: cannot access uk.co.tigress.System
bad class file: /usr/share/java/libgetenv-java.jar(uk/co/tigress/System.class)
class file contains wrong class: System
Please remove or make sure it appears in the correct subdirectory of the 
classpath.
import uk.co.tigress.System;
 ^
1 error
[EMAIL PROTECTED] 213%


So I can't even get this package to work, let alone provide an
example of how it would be a problem with the DLJ.

Please advise,

--Tom


// altenv.java

import uk.co.tigress.System;

public class altenv {

  public static void main(String[] args) {
if (args.length != 0) {
  System.out.println(usage: java sunenv);
} else {
  try {
String env1 = HOME;
	String val1 = System.getenv(env1);
	System.out.println(env  + env1 +  =  + val1);
String env2 = PATH;
	String val2 = System.getenv(env2);
	System.out.println(env  + env2 +  =  + val2);
  } catch (Exception e) {
	System.out.println(unable to get environment variables);
	System.out.println(Exception:  + e); 
  }
}
  }
}

Bug#376888: sun-java5-bin: README.alternatives includes wrong syntax to

[Tom Marble]

Florian Laws wrote:
 the call to update-java-alternatives as documented in
 /usr/share/doc/sun-java5-bin/README.alternatives seems to be wrong.

 I think it should read
 update-java-alternatives -s java-1.5.0-sun
 instead of just
 update-java-alternatives sun-java5

You are right!  I have fixed this in SVN [1] and it
will be resolved in the next upload.

Thanks,

--Tom

[1] 
https://jdk-distros.dev.java.net/source/browse/jdk-distros/trunk/linux/ubuntu/sun-java5/debian/README.alternatives.in?rev=161view=text


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

Bug#370296: Bug#369950: eclipse could is not search in the right place for sun-java5-jdk

[Tom Marble]

All:

Please note that

1. The Eclipse packaging predates the recent changes
   in java-common (= 0.25) which is part of a broader
   Debian Java Policy initiative to harmonize
   access to multiple implementations [1].
   At some point the Eclipse packaging should simply
   start with /usr/bin/java (assuming there is at a least
   one implementation available as determined by
   adding Depends: java-runtime ).

2. The following fix to the current eclipse packaging has been
   tested and works (if *no other implementations are
   installed*):

[EMAIL PROTECTED] 13% diff -Naur 
eclipse-3.1.2{-pristine,}/debian/extra/java_home
--- eclipse-3.1.2-pristine/debian/extra/java_home   2006-07-07 
19:46:33.0 -0500
+++ eclipse-3.1.2/debian/extra/java_home2006-07-09 16:23:16.0 
-0500
@@ -4,6 +4,7 @@

 /usr/lib/jvm/java-gcj
 /usr/lib/kaffe/pthreads
+/usr/lib/jvm/java-1.5.0-sun
 /usr/lib/j2se/1.5
 /usr/lib/j2se/1.4
 /usr/lib/j2sdk1.5-ibm
[EMAIL PROTECTED] 14%

3. Note if one of the two implementations is installed on
   the system which precede Sun Java (in java_home above)
   then Eclipse will start with the first one it finds.
   In that case the work around is to add the following
   to ~/.eclipse/eclipserc
   JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun

4. Even in the case listed in #3 Sun Java can still be used
   to edit and run Java programs by doing the following:

   a. open the Window | Preferences dialog
   b. Expand the tree  Java  Editor  Installed JREs
   c. click Add...
  select the /usr/lib/jvm/java-1.5.0-sun directory


Allow my to respectfully propose the patch in #2 be applied
to the current Eclipse packaging to close this bug.
Then, separately, as Debian Java Policy evolves the Eclipse
packaging should be updated to take those conventions
into account.

Regards,

--Tom

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=365408
http://wiki.debian.org/Java/Draft

P.S. Please note, also, that I have just updated the documentation
 for installing the Sun JRE on Debian:
   https://jdk-distros.dev.java.net/debian.html
 as well as installing the Sun JDK on Debian:
   https://jdk-distros.dev.java.net/debian-dev.html


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

Bug#375745: sun-java5: [INTL:sv] Swedish debconf templates translation

[Tom Marble]

Daniel Nylander wrote:
 Here is the Swedish translation of the debconf template for sun-java5.

Thank you very much for this translation!
I have included it in SVN [1] and it will get included in
the next upload.

Regards,

--Tom

[1] 
https://jdk-distros.dev.java.net/source/browse/jdk-distros/trunk/linux/ubuntu/sun-java5/debian/po/sv.po?rev=162view=markup


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

Bug#369950: eclipse could is not search in the right place for sun-java5-jdk

[Tom Marble]

(sorry, sent previously to the wrong bug number :-( )

All:

Please note that

1. The Eclipse packaging predates the recent changes
   in java-common (= 0.25) which is part of a broader
   Debian Java Policy initiative to harmonize
   access to multiple implementations [1].
   At some point the Eclipse packaging should simply
   start with /usr/bin/java (assuming there is at a least
   one implementation available as determined by
   adding Depends: java-runtime ).

2. The following fix to the current eclipse packaging has been
   tested and works (if *no other implementations are
   installed*):

[EMAIL PROTECTED] 13% diff -Naur 
eclipse-3.1.2{-pristine,}/debian/extra/java_home
--- eclipse-3.1.2-pristine/debian/extra/java_home   2006-07-07 
19:46:33.0 -0500
+++ eclipse-3.1.2/debian/extra/java_home2006-07-09 16:23:16.0 
-0500
@@ -4,6 +4,7 @@

 /usr/lib/jvm/java-gcj
 /usr/lib/kaffe/pthreads
+/usr/lib/jvm/java-1.5.0-sun
 /usr/lib/j2se/1.5
 /usr/lib/j2se/1.4
 /usr/lib/j2sdk1.5-ibm
[EMAIL PROTECTED] 14%

3. Note if one of the two implementations is installed on
   the system which precede Sun Java (in java_home above)
   then Eclipse will start with the first one it finds.
   In that case the work around is to add the following
   to ~/.eclipse/eclipserc
   JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun

4. Even in the case listed in #3 Sun Java can still be used
   to edit and run Java programs by doing the following:

   a. open the Window | Preferences dialog
   b. Expand the tree  Java  Editor  Installed JREs
   c. click Add...
  select the /usr/lib/jvm/java-1.5.0-sun directory


Allow my to respectfully propose the patch in #2 be applied
to the current Eclipse packaging to close this bug.
Then, separately, as Debian Java Policy evolves the Eclipse
packaging should be updated to take those conventions
into account.

Regards,

--Tom

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=365408
http://wiki.debian.org/Java/Draft

P.S. Please note, also, that I have just updated the documentation
 for installing the Sun JRE on Debian:
   https://jdk-distros.dev.java.net/debian.html
 as well as installing the Sun JDK on Debian:
   https://jdk-distros.dev.java.net/debian-dev.html


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

Bug#370296: DLJ only allows distributing the exact same file

[Tom Marble]

Walter:

I have just posted a notice to debian-legal about the
availability of new DLJ FAQ [1] which further clarifies
our intent.

It is the intent of the DLJ that licensees such as Debian will
work towards compatibility with their Operating System [2].

The sun-java5 packages have been split for very specific
reasons to both comply with the DLJ and with Debian Policy.
The package metadata (dpkg dependencies) have been designed
so that as installed on Debian the DLJ will be fulfilled:

- sun-java5-jre contains architecture independent files
- sun-java5-bin contains architecture dependent files
  and has circular depends on sun-java5-jre
- sun-java5-plugin is *optional* integration for web browsers
  because server oriented systems cannot have a Depends: on browsers
- sun-java5-jdk contains the Java Development Kit (JDK(TM))
- sun-java5-demo contains the demonstration and sample files with the JDK.
  There is a circular depends on sun-java5-jdk because the demo files
  are required by the license when the JDK is installed.  Separating
  these demo files into a separate package can be converted to Suggests:
  as soon as allowed by the license.
- sun-java5-source package installs the src.zip file which explicitly
  listed as optional in the README
- sun-java5-fonts package integrates Lucida fonts (from the JRE) using defoma
  and it is optional because defoma integration is not mandated by the license
  and if users already have a Lucida font package installed with defoma
  then this integration is redundant.
- sun-java5-doc package facilitates integration of the Sun JDK Documentation
  and has no relationship to the DLJ bundles in question -- it has
  been provided as a convenience to developers who download Javadocs
  from the http://java.sun.com website.

What's more, further clarification on modifications is
planned for the README [3].

Reaching this technical and legal solution is what I am
most proud of in the work on these packages -- it is
proof that the spirit of the DLJ of enabling distros
to do the right thing is the best way to get the
Sun Java platform on distros not directly supported by Sun.

Regards,

--Tom

[1] https://jdk-distros.dev.java.net/developer.html
[2] http://download.java.net/dlj/DLJ-FAQ-v1.2.html#q26
[3] http://download.java.net/dlj/DLJ-FAQ-v1.2.html#q9




signature.asc
Description: OpenPGP digital signature

Bug#370295: DLJ prevents running jython with sun-java

[Tom Marble]

Walter:

I have just posted a notice to debian-legal about the
availability of new DLJ FAQ [1] which further clarifies
our intent. It is not the intent of the DLJ to
prevent running Jython.

Please see the new FAQ #13 #14 and #15 [2].

If Sun wanted to discourage innovations like Jython and
JRuby we would not leave web content on our official
web sites that referred to them [3].

A further demonstration that prohibiting Jython is not our intent
is through an award at JavaOne 2006 for the Java Model Railroad
Interface (JMRI) which includes Jython [4].

Indeed the governance organization that guides the evolution
of Java Platform(TM), the JCP [5], has specifically endorsed
this entire *class* of innovations by adding a supporting bytecode,
invokedynamic, to the Java programming language [6].

You may close this bug without making Jython conflict with sun-java.

Regards,

--Tom

[1] https://jdk-distros.dev.java.net/developer.html
[2] http://download.java.net/dlj/DLJ-FAQ-v1.2.html#q13
[3] http://java.sun.com/developer/technicalArticles/JavaLP/groovy/index.html
[4] http://java.sun.com/javaone/sf/dukes_choice_awards.jsp
[5] http://www.jcp.org/
[6] http://www.jcp.org/en/jsr/detail?id=292



signature.asc
Description: OpenPGP digital signature

Bug#370245: Export control problems in license

[Tom Marble]

Walter:

I have just posted a notice to debian-legal about the
availability of new DLJ FAQ [1] which further clarifies
our intent.

Please see the new FAQ#30 [2].

HTH,

--Tom

[1] https://jdk-distros.dev.java.net/developer.html
[2] http://download.java.net/dlj/DLJ-FAQ-v1.2.html#q30



signature.asc
Description: OpenPGP digital signature

Bug#367562: Please make dependency on sun-java5-demo optional

[Tom Marble]

Alessandro Polverini is correct.  We intend to loosen this restriction which
is currently part of the README [1] in the DLJ bundle for 1.5.0_06.

As soon as allowed by the license then the control file can be
changed to make the demos/ and samples/ subdirectories optional.
The packaging has been made separate in anticipation of this
forthcoming flexibility.

Regards,

--Tom

[1] https://jdk-distros.dev.java.net/developer.html


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

Bug#368467: sun-java5-plugin: amd64 support

[Tom Marble]

We realize that this is important as demonstrated by the fact
that this is RFE# 4 for Java [4].

The original bug has the background information [1] and
we now have tracking bugs in Debian [2] and the
jdk-distros project [3].

What would be helpful is to document best practices
for the install 32-bit plugin in a chroot environment
even though it is a hack.

Similarly helpful would be proposals on how to leverage
BiArch or MultiArch to install the 32-bit client software [5]
on an amd64 system.

The complete fix, of course, will depend on native amd64
binaries of the client software (and corresponding browsers).

Regards,

--Tom

[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4802695
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=368467
[3] https://jdk-distros.dev.java.net/issues/show_bug.cgi?id=13
[4] http://bugs.sun.com/bugdatabase/top25_rfes.do
[5] client software: -client VM, Class Data Sharing,
Java Web Start, and Java Plug-in.


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

Bug#365408: [POLICY-PROPOSAL] Drop java*-runtime/compiler...

[Tom Marble]

All:

In reviewing the proposed changes to Debian Java Policy [1] [2]
please allow me to make the following suggestions:

1. With respect to virtual packages [3] I understand that
   Debian Policy does not allow packages in main to
   depend on packages in non-free.  Therefore a distinction
   must be made between the provides for main and non-free.

   As naming can be somewhat problematic allow me to
   separate the choice of names (which involves clarity, brevity
   and trademark issues) from the use of names (use in control
   and update-$J-alternatives) via the following variables
   Here I am showing my proposed choices for names but I'm more
   interested in your opinion of name usage below:

   J=cafe# the generic name of a technology that runs coffee like programs
   R=runtime # the name of the part of a platform to run such programs
   D=dev # the name of the superset of $R to develop such programs
   P=plugin  # the optional part of $R that provides OJI plugin capability

   For packages intended for main control cannot have any Depends:
   on non-free provides so a sample entry could be:
 Depends: $J-$R
   NOTE: a user may still run those packages in main with a
   non-free $J implementation, but would have to do so manually
   (update-java-alternatives) and not via dpkg dependencies AND
   would be required to have a Free $J-$R installed even if it
   were not used for the program in question.

   For packages in non-free or contrib the entry could be:
 Depends: $J-$R | $J-$R-nonfree
   In which case a $J-$R-nonfree could satisfy the dependency.

   Therefore for a given substitution of name choices I propose
   the following alternative to [3]

   Free:
 * $J-$R
 * $J-$D
   Non-Free:
 * $J-$R-nonfree
 * $J-$D-nonfree

2. I have additional ideas about update-$J-alternatives (UJA) which really
   should be the subject of a separate e-mail.  For now let me
   propose that we need a list of components (executables or plugins)
   which need to be marshaled by UJA.  This should be the union of
   all components provided by all of:
 * $J-$R
 * $J-$D
 * $J-$R-nonfree
 * $J-$D-nonfree

   Starting with Sun Java this list of components would be:
   for $R:
 ControlPanel
 java
 java_vm
 javaws
 keytool
 kinit
 klist
 ktab
 orbd
 pack200
 policytool
 rmid
 rmiregistry
 servertool
 tnameserv
 unpack200
   for $D:
 appletviewer
 apt
 extcheck
 HtmlConverter
 idlj
 jar
 jarsigner
 javac
 javadoc
 javah
 javap
 java-rmi.cgi
 jconsole
 jdb
 jinfo
 jmap
 jps
 jsadebugd
 jstack
 jstat
 jstatd
 native2ascii
 rmic
 serialver
   for plugin (NOTE: this should be generic for any plugin provider)
 mozilla-javaplugin.so
 firefox-javaplugin.so
 mozilla-snapshot-javaplugin.so

   As a concrete example, using the name choices above, the UJA
   config file for Sun Java would be (/usr/lib/jvm/.java-1.5.0-sun.jinfo):
::
name=java-1.5.0-sun-1.5.0.06
alias=java-1.5.0-sun
priority=53
section=non-free

runtime ControlPanel /usr/lib/jvm/java-1.5.0-sun/jre/bin/ControlPanel
runtime java /usr/lib/jvm/java-1.5.0-sun/jre/bin/java
runtime java_vm /usr/lib/jvm/java-1.5.0-sun/jre/bin/java_vm
runtime javaws /usr/lib/jvm/java-1.5.0-sun/jre/bin/javaws
runtime keytool /usr/lib/jvm/java-1.5.0-sun/jre/bin/keytool
runtime pack200 /usr/lib/jvm/java-1.5.0-sun/jre/bin/pack200
runtime policytool /usr/lib/jvm/java-1.5.0-sun/jre/bin/policytool
runtime rmid /usr/lib/jvm/java-1.5.0-sun/jre/bin/rmid
runtime rmiregistry /usr/lib/jvm/java-1.5.0-sun/jre/bin/rmiregistry
runtime unpack200 /usr/lib/jvm/java-1.5.0-sun/jre/bin/unpack200
dev appletviewer /usr/lib/jvm/java-1.5.0-sun/bin/appletviewer
dev apt /usr/lib/jvm/java-1.5.0-sun/bin/apt
dev extcheck /usr/lib/jvm/java-1.5.0-sun/bin/extcheck
dev HtmlConverter /usr/lib/jvm/java-1.5.0-sun/bin/HtmlConverter
dev idlj /usr/lib/jvm/java-1.5.0-sun/bin/idlj
dev jar /usr/lib/jvm/java-1.5.0-sun/bin/jar
dev jarsigner /usr/lib/jvm/java-1.5.0-sun/bin/jarsigner
dev javac /usr/lib/jvm/java-1.5.0-sun/bin/javac
dev javadoc /usr/lib/jvm/java-1.5.0-sun/bin/javadoc
dev javah /usr/lib/jvm/java-1.5.0-sun/bin/javah
dev javap /usr/lib/jvm/java-1.5.0-sun/bin/javap
dev java-rmi.cgi /usr/lib/jvm/java-1.5.0-sun/bin/java-rmi.cgi
dev jconsole /usr/lib/jvm/java-1.5.0-sun/bin/jconsole
dev jdb /usr/lib/jvm/java-1.5.0-sun/bin/jdb
dev jinfo /usr/lib/jvm/java-1.5.0-sun/bin/jinfo
dev jmap /usr/lib/jvm/java-1.5.0-sun/bin/jmap
dev jps /usr/lib/jvm/java-1.5.0-sun/bin/jps
dev jsadebugd /usr/lib/jvm/java-1.5.0-sun/bin/jsadebugd
dev jstack /usr/lib/jvm/java-1.5.0-sun/bin/jstack
dev jstat /usr/lib/jvm/java-1.5.0-sun/bin/jstat
dev jstatd /usr/lib/jvm/java-1.5.0-sun/bin/jstatd
dev native2ascii /usr/lib/jvm/java-1.5.0-sun/bin/native2ascii
dev rmic /usr/lib/jvm/java-1.5.0-sun/bin/rmic
dev serialver