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 th
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
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
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: warn
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.
Reg
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 exa
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
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
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
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]
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...@
I can confirm I am hitting this exact same bug (same system
information).
--Tom
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 in
Package: wnpp
Severity: wishlist
Owner: Tom Marble
* Package name: libpedantic-clojure
Version : 0.1.0
Upstream Author : Nelson Morris
* URL : https://github.com/xeqi/pedantic
* License : EPL-1.0
Programming Lang: Clojure
Description : A Clojure
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.ur
Package: wnpp
Severity: wishlist
Owner: Tom Marble
* 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
Package: wnpp
Severity: wishlist
Owner: Tom Marble
* 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
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 tech
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 addressin
Tom Marble 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
Elana Hashman writes:
> Should I also go ahead and file RFPs for the missing packages for
> visibility?
Sure!
Thanks!
--Tom
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 :) emacscl
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
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
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
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.a
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 fi
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/ja
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/tru
(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 Ec
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
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
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 m
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-
Package: wnpp
Severity: wishlist
Owner: Tom Marble
* Package name: kspsig
Version : 0.1
Upstream Author : Tom Marble
* URL : http://github.com/tmarble/kspsig
* License : GPL-3
Programming Lang: Python
Description : Key Signing Party signature
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
incl
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
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 unsta
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 kerne
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 ~/.
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!!!
Th
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 bluem
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
43 matches
Mail list logo