Bug#533674: Done: mpg321: comparison to mpg123 in man page is not accurate
reopen 533674 thanks + Nanakos Chrysostomos (Tue, 29 Jun 2010 20:23:13 +0300): Package: mpg321 Version: 0.2.11-3 We don't need to compare mpg321 to mpg123 anymore. This bug is not fixed, the man page still refers to mpg123 as non-free. Thanks. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554021: minirok: playback should not directly start once a track is selected
Hello Jendrik, I'm sorry this fell through the cracks and went unanswered for so long. As Lucas van Staden pointed out (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554021#10), this is a KDE-wide setting. If you change in the system settings (or via the method Lucas suggests if you don't use a KDE environment), you should see the behavior changed. Can you let me know if that's the case? Thanks! + Jendrik Seipp (Mon, 02 Nov 2009 18:42:28 +0100): Package: minirok Version: 2.1-1 Severity: wishlist In my opinion it would be great for many users, if they could select the preferred meaning of a click on a track: highlight or play if one click only highlights the track, of course 2 clicks should start the track. Thanks for the app. I think I finally found a music player that gets it right: Play music, no library, easy search in directories. Have been following the minirok releases for quite some time now and I think now it is almost perfect ;) -- System Information: Debian Release: squeeze/sid APT prefers karmic-updates APT policy: (500, 'karmic-updates'), (500, 'karmic-security'), (500, 'karmic-backports'), (500, 'karmic') Architecture: i386 (i686) Kernel: Linux 2.6.31-14-generic (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages minirok depends on: ii gstreamer0.10-alsa [g 0.10.25-2ubuntu1 GStreamer plugin for ALSA ii gstreamer0.10-esd [gs 0.10.16-1ubuntu3 GStreamer plugin for ESD ii gstreamer0.10-plugins 0.10.14-4ubuntu1 GStreamer plugins from the bad s ii gstreamer0.10-plugins 0.10.25-2ubuntu1 GStreamer plugins from the base ii gstreamer0.10-plugins 0.10.16-1ubuntu3 GStreamer plugins from the good ii gstreamer0.10-plugins 0.10.12-1 GStreamer plugins from the ugly ii gstreamer0.10-pulseau 0.10.16-1ubuntu3 GStreamer plugin for PulseAudio ii python2.6.4~rc1-0ubuntu1 An interactive high-level object-o ii python-gst0.100.10.17-1 generic media-playing framework (P ii python-kde4 4:4.3.2-0ubuntu4 Python bindings for the KDE 4 libr ii python-mutagen1.15-2 audio metadata editing library ii python-qt44.6-1 Python bindings for Qt4 ii python-simplejson 2.0.9-1Simple, fast, extensible JSON enco Versions of packages minirok recommends: ii python-dbus 0.83.0-1ubuntu2 simple interprocess messaging syst pn python-psutilnone (no description available) pn python-qt4-dbus none (no description available) Versions of packages minirok suggests: ii gstreamer0.10-plugins-b 0.10.14-4ubuntu1 GStreamer plugins from the bad s -- no debconf information -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569790: Remove selected tracks option (with patch)
tag 569790 fixed-upstream thanks + Lucas van staden (Sun, 14 Feb 2010 22:00:31 +0800): Hi, One of the 'frontends' to our music system does not have a keyboard. Fair enough. I've committed a patch similar to yours, I'll prepare a release some time soon. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569790: Remove selected tracks option (with patch)
Hello Lucas, you can delete tracks by selecting them and pressing
Delete, just as you'd delete some text. I didn't put an option in the
menu because I didn't want to clutter it. Perhaps it should be there,
hm.
+ Lucas van staden (Sun, 14 Feb 2010 18:27:37 +0800):
Package: minirok
Version: 2.1
Severity: wishlist
Hi,
Firstly, thank you very much for this player.
Simplistic, easy to use, not resource intensive, and uses the file
system (no library) - everything I wanted
well it seems nearly.
The first thing my biggest user (ie my wife) requested was the ability
to be able to remove selected tracks from the playlist.
The crop feature does do that, but you have to select all the tracks
you want to keep (so it works inverse to a simple 'remove this track'
option)
I thus added a new menu option, which removes the selected track(s)
Regards
Lucas van Staden
www.dedmeet.com (linux)
www.proxiblue.com.au (consumer electronics)
Below is the patch:
u...@pygmy:/usr/share/minirok/minirok$ diff -c playlist.py_ori playlist.py
*** playlist.py_ori 2010-02-14 18:03:35.128477864 +0800
--- playlist.py 2010-02-14 18:11:14.214724875 +0800
***
*** 1116,1126
--- 1116,1128
if len(selected_indexes) == 1:
enqueue_action = menu.addAction('Enqueue track')
+ remove_action = menu.addAction('Remove track')
if index.data(Playlist.RoleQueuePosition).toInt()[0] 0:
enqueue_action.setCheckable(True)
enqueue_action.setChecked(True)
else:
enqueue_action = menu.addAction('Enqueue/Dequeue tracks')
+ remove_action = menu.addAction('Remove selected tracks')
stop_after_action = menu.addAction('Stop playing after
this track')
***
*** 1140,1145
--- 1142,1150
self.model().toggle_stop_after(index)
elif selected_action == crop_action:
self.model().removeItemsCmd(self.unselectedIndexes())
+ elif selected_action == remove_action:
+ self.model().removeItemsCmd(selected_indexes)
+
else:
return QtGui.QTreeView.mousePressEvent(self, event)
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100214134249.ga13...@chistera.yi.org
Bug#551759: python2.5: patch to fix spurious space after completion with libreadline6
Package: python2.5
Version: 2.5.4-2
Tags: patch
Hello,
now that Python uses libreadline6, an irritating behavior has been
introduced: completing with TAB for example in the interactive
interpreter introduces an spurios space after the completed word.
This has been reported upstream [1], and an isolated patch exists [2],
which I'm attaching to this bug report. Please considering applying it
(it applies fine to 2.5).
Thanks.
[1]: http://bugs.python.org/issue5833
[2]: http://bugs.python.org/file14599/python-2.6-readline.patch
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
--- Modules/readline.c 2008-11-04 12:43:31.0 -0800
+++ Modules/readline.c 2009-04-22 15:50:49.0 -0700
@@ -759,6 +759,10 @@
static char **
flex_complete(char *text, int start, int end)
{
+#ifdef HAVE_RL_COMPLETION_APPEND_CHARACTER
+ rl_completion_append_character ='\0';
+ rl_completion_suppress_append = 0;
+#endif
Py_XDECREF(begidx);
Py_XDECREF(endidx);
begidx = PyInt_FromLong((long) start);
@@ -799,11 +803,8 @@
rl_completer_word_break_characters =
strdup( \t\n...@#$%^*()-=+[{]}\\|;:'\,/?);
/* All nonalphanums except '.' */
-#ifdef HAVE_RL_COMPLETION_APPEND_CHARACTER
- rl_completion_append_character ='\0';
-#endif
begidx = PyInt_FromLong(0L);
endidx = PyInt_FromLong(0L);
Bug#551142: python-kde4-dev: /usr/bin/pykdeuic4 symlink broken
+ Sune Vuorela (Fri, 16 Oct 2009 09:27:55 +0100): Hi dato Hello! I'm not completely sure how pykdeuic is supposed to be used. it seems like for users it doesn't matter. I use it in the same way the regular uic-qt4 is used: you call it at compile time to generate the code that builds up the interface. Since it's Python code, at compile time means when generating the tarball to be released, so that the tarball includes directly the python code in addition to the source. Or it could be at package build time, so that the Debian package surely does. System-config-printer-kde seems to just dynamically load the .ui files on demand by using some from PyQt4 import uic and a bit later class MyClass def __init__() uic.loadUI(path/to/ui/file.ui,self) I see. Well, that requires that uic is installed of the user's machine. Which is normally not the case with C++ uic, but seems to be the case with uic for Qt in Python. (But not for KDE, since it's in the python-kde4-dev package.) I guess there is two possibilities. either remove teh symlink completely or make it point to where pykdeuic4.py now resides. Please the latter. It is supposed to be an executable on the system AFAIK. and does changing the symlink to point to /usr/share/pyshared/PyQt4/uic/pykdeuic4.py fix it for you ? Yes, if I make the file exectuable as well. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551142: python-kde4-dev: /usr/bin/pykdeuic4 symlink broken
Package: python-kde4-dev Version: 4:4.3.2-1 Severity: serious /usr/bin/pykdeuic4 points to ../lib/python2.5/site-packages/PyQt4/uic/pykdeuic4.py but that file does not exist. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540868: minirok: Fails to play the next song in the queue
Hello, again. Minirok does not seem to use the proper sound card. I have two cards - A, B. In systemsettings Multimedia Device Preferences: Music ( Video):: B is on top (ie preferred to) of A. Notifications:: A is on top of B. So all the system notifications' sounds to go A and Amarok's and Dragon player's sound go to B. On the Backend tab, Xine is on top of Gstreamer. Now, in terms of the module load order, my /etc/modprobe.d/sound.conf is: options snd_ens1371 index=0 # this is A options snd_intel8x0 index=1 # this is B options snd_usb_audio index=2 # this depends on any connected webcam Due to this, all sounds from firefox (online music/movies) go to A - which is OK with me. Now the issue: minirok's sound are going to A and not B. I had expected (and wanted) it the other way. Thanks again. I wish to see the issues ironed out. I see. Minirok uses GStreamer directly in a rather rudimentary way, because at the time it was writing there were no bindings for Phonon available. Now that they are, I hope to port Minirok to use it, which AFAIK means any global configuration settings will apply to Minirok as well. Hopefully I can get this done for the next release, 2.2. Thanks for your reporting of these bugs, in the meantime I'm closing the fails to play the next song in the queue bug. Cheers! -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531347: python-gst0.10: AttributeError: 'module' object has no attribute 'Element'
reopen 531347 thanks + Adeodato Simó (Sat, 06 Jun 2009 14:38:16 +0200): close 531347 thanks % python import gst AttributeError: 'module' object has no attribute 'Element' This seems to have gone away. And seems to have returned in at least 0.10.16 and 0.10.17. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540868: minirok: Fails to play the next song in the queue
+ P Kapat (Mon, 10 Aug 2009 14:17:56 -0400): Package: minirok Version: 2.0-1 Severity: important Won't play the next (or the previous) song in the queue. Forcing it, by clicking on the Next/Previous song/button, doesn't help either. Sometimes, it waits for 2 min and then starts playing the next song!! But this behavior is not consistent. This is a new development with KDE 4.3.0. On earlier version, ie 4.2.4, it worked fine. Hello, I had a couple other people report this, but I couldn't reproduce it. Today I upgraded my testing system, and it started happening. However, upgrading all the gstreamer packages to the unstable versions made the problem go away. Is this still happening for you? (If you have problems with minirok crashing in unstable, you can try the package at http://chistera.yi.org/~adeodato/tmp/2009-10-15/minirok_2.1~r768-1_all.deb.) -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548570: minirok segfaults
+ Jonas Meurer (Sun, 27 Sep 2009 12:30:28 +0200): Package: minirok Version: 2.0-1 Severity: grave Justification: renders package unusable hello, minirok segfaults on my up-to-date debian/unstable system: Hello Jonas, this was caused by an incompatibility in PyQt 4.6. I believe I have fixed the problem. Before doing an upload, would you mind testing the packages at [1] (they are sort of 2.1~rc1)? Thanks! [1]: http://chistera.yi.org/~adeodato/tmp/2009-10-15/minirok_2.1~r768-1_all.deb -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548351: RFA: mlocate
Package: wnpp -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548352: RFA: amule
Package: wnpp -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544230: minirok segfaults when I Open Directory
+ David Bremner (Sat, 29 Aug 2009 17:50:33 -0300): Package: minirok Version: 2.0-1 Severity: important Minirok doesn't seem to work at all for me. If I try to open a directory either from the file menu or by Ctrl-F, it segfaults. According to the bug reporting wizard, my backtrace info is not useful, probably because I miss debug information. The only thing I can think of that is unusual about this sid box is that I am running xmonad as a window manager. Hello, David. Thank you for your bug report. This is indeed a known issue in 2.0 which has been fixed for the upcoming 2.1 version. If you want to give Minirok a second try, the easiest way is to type a directory by hand in the text box first; afterwards the Open directory dialog will work normally. FWIW the commit that fixes the issue is: http://git.debian.org/?p=users/adeodato/minirok.git;a=commitdiff;h=8138f1 Sorry about the low quality bug report; I was shopping for an audio player, and I thought should at least report all of the reasons I rejected options. Thanks at least for reporting it. :-) -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540057: python-qt4: needs to Break: python-kde4 ( 4:4.2.4)
Package: python-qt4 Version: 4.5.1-1.1 Severity: serious Apparently, python-qt4 4.5.1 breaks python-kde4 4.2.2: % dpkg -l python-kde4 python-qt4 ii python-kde44:4.2.2-3 ii python-qt4 4.5.1-1.1 % python from PyKDE4 import kdecore zsh: segmentation fault (core dumped) python So, I think a Breaks: python-kde4 ( 4:4.2.4) is in order. Additionally, the versioning of python-qt4 in unstable has left python-kde4 4.2.4 uninstallable (though that's arguably a bug in python-kde4 itself that'll get fixed in the next upload). Despite this, I've verified python-kde 4.2.4 works fine with python-qt4 4.5.1-1.1. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539647: minirok: ~ expansion in the directory popup
+ Ken Bloom (Sun, 02 Aug 2009 12:18:26 -0500):
Package: minirok
Version: 2.0-1
Severity: minor
The directory popup in minirok recognizes the ~ character and uses it
for home directory expansion (e.g. if I type ~/music/, then the
subdirectories of ${HOME}/music will appear in the popup.)
However, minirok itself doesn't recognize the ~, so if I type ~/music/
into the directory popup, minirok won't find the directory, won't list
any files in the file list, and will print a message on STDERR:
minirok: WARNING: could not stat '~/music': No such file or directory
Hello, Ken, thanks for your bug report.
You're correct that this doesn't work at the moment. The fix would be
easy, but rather than adding an ad-hoc solution for this, I'm going to
wait until I refactor all that code and make it use KDE classes
(together with making it use Phonon, I guess). When that happen, any URL
valid to KDE (eg., even smb:// or fish://) will be reproducable with
Minirok.
Hope that plan is okay with you, and thanks again for your bug report.
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539170: O: wxwidgets2.8
Package: wnpp I'm orphaning the wxwidgets2.8 package. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539172: RM: libgetopt++ -- RoM; library without reverse dependencies
Package: ftp.debian.org It also has very low popcon, and the only software I was aware that used it, has been removed from Debian. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539173: RM: gbuffy -- RoM; uses GTK+1.2
Package: ftp.debian.org I'm Bcc'ing #515274, the serious bug regarding gbuffy depending on GTK+1.2, in case anybody following that bug can be aware of the removal request. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507484: minirok: please add shortcut to enqueue/dequeue tracks
tag 507484 pending thanks + Felipe Sateler (Mon, 01 Dec 2008 15:09:27 -0300): Package: minirok Version: 0.9.1-1 Severity: wishlist Qeueing tracks without having to use the mouse would be great. Hello, Felipe. I've finally been able to implement this, and it'll be part of the upcoming 2.1 release. You can try it with the following package, it'd be great knowing if it works as you expected: http://chistera.yi.org/~adeodato/tmp/2009-07-28/minirok_2.1~r728-1_all.deb Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#431557: NMU diff for this bug (librmail-ruby1.8: Please apply patches available at rubyforge)
Hello,
I've prepared a NMU to apply one of the patches requested [1], the one
that was affecting me and which I've verified to be a correct and
sensible fix.
I've uploaded the NMU to DELAYED/14-day and I'm attaching the NMU diff.
Please let me know if you have any comments.
[1]:
http://rubyforge.org/tracker/index.php?func=detailaid=2661group_id=446atid=1756
Cheers,
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
diff -u librmail-ruby-0.17/debian/changelog librmail-ruby-0.17/debian/changelog
--- librmail-ruby-0.17/debian/changelog
+++ librmail-ruby-0.17/debian/changelog
@@ -1,3 +1,16 @@
+librmail-ruby (0.17-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+
+ * Apply patch from upstream BTS to avoid quoting existing parameters
+twice in Header::set_boundary(). Addresses part of #431557, which
+requested for all patches in upstream BTS to be applied to the package.
+
+ * Add a build-dependency on quilt and the 3-line magic in debian/rules to
+apply the above patch.
+
+ -- Adeodato Simó adeod...@debian.org Sun, 12 Jul 2009 10:24:45 +0200
+
librmail-ruby (0.17-1) unstable; urgency=low
* New upstream version.
diff -u librmail-ruby-0.17/debian/control librmail-ruby-0.17/debian/control
--- librmail-ruby-0.17/debian/control
+++ librmail-ruby-0.17/debian/control
@@ -2,7 +2,7 @@
Section: interpreters
Priority: optional
Maintainer: Shugo Maeda sh...@debian.org
-Build-Depends-Indep: debhelper ( 3.0.0), ruby1.8, ruby1.8-dev
+Build-Depends-Indep: debhelper ( 3.0.0), quilt, ruby1.8, ruby1.8-dev
Standards-Version: 3.6.1
Package: librmail-ruby-doc
diff -u librmail-ruby-0.17/debian/rules librmail-ruby-0.17/debian/rules
--- librmail-ruby-0.17/debian/rules
+++ librmail-ruby-0.17/debian/rules
@@ -8,10 +8,10 @@
# This is the debhelper compatibility version to use.
export DH_COMPAT=3
-
+include /usr/share/quilt/quilt.make
configure: configure-stamp
-configure-stamp:
+configure-stamp: $(QUILT_STAMPFN)
dh_testdir
# Add here commands to configure the package.
mkdir build-tree-1.8
@@ -32,7 +32,7 @@
touch build-stamp
-clean:
+clean: unpatch
dh_testdir
dh_testroot
rm -f build-stamp configure-stamp
--- librmail-ruby-0.17.orig/debian/patches/series
+++ librmail-ruby-0.17/debian/patches/series
@@ -0,0 +1 @@
+do_not_quote_params_twice_in_set_boundary.patch
--- librmail-ruby-0.17.orig/debian/patches/do_not_quote_params_twice_in_set_boundary.patch
+++ librmail-ruby-0.17/debian/patches/do_not_quote_params_twice_in_set_boundary.patch
@@ -0,0 +1,16 @@
+This patch was obtained from these bugs in the upstream BTS:
+
+ * http://rubyforge.org/tracker/index.php?func=detailaid=2170group_id=446atid=1754
+ * http://rubyforge.org/tracker/index.php?func=detailaid=2661group_id=446atid=1756
+
+--- a/lib/rmail/header.rb
b/lib/rmail/header.rb
+@@ -630,7 +630,7 @@
+ # Set the boundary parameter of this message's Content-Type:
+ # field.
+ def set_boundary(boundary)
+- params = params_quoted('content-type')
++ params = params('content-type')
+ params ||= {}
+ params['boundary'] = boundary
+ content_type = content_type()
Bug#463807: RFH: wxwidgets2.8 -- help for wxwidgets2.8 is appreciated
+ Ryan Niebur (Tue, 30 Jun 2009 15:36:06 -0700): I will help with this, in hopes that a new version will be more stable and fix the libwx-perl FTBFS bugs. Padre upstream strongly recommends (by not allowing installation with older versions, unless we patch the build system, which is what we did) the next version of wxwidgets after what we have, because the version we have is buggy. Despite my only exposure to wxwidgets being through the Perl bindings, and only using them since last week, I will be willing to work on this package in the long term to keep it in shape for Padre. I can probably help with RC bug fixing, upgrading to new upstream versions, reviewing and applying patches, fixing trivial bugs, forwarding/triaging bugs, and keeping the packaging in good shape, but probably won't be very helpful for anything that requires a lot of knowledge of wxwidgets, C++, or Python, since I don't know these. Adeodato, may I start working and commit to the Git repository? Please go ahead, thank you! Regarding 7eb273055220d815c39075c8655407514b1764c2, it seems I didn't put a rationale in the commit message, but all I can say is that I think I produced clean packages, so I'd venture the *.mo files get cleaned in some other way, or they don't need cleaning. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533674: mpg321: comparison to mpg123 in man page is not accurate
Package: mpg321 Version: 0.2.10.6 Severity: normal Hello, From the mpg321(1) man page: | mpg321 differs from mpg123 in several ways. First and foremost, it | is fully Free, under the GNU General Public License. Secondly, it | allows run-time switching of output devices (via the -o switch). | (mpg321 also allows configuring a default output device at compile- | time, but run-time switching is always allowed). Neither of this seem to be true any longer: mpg123 has been relicensed under the LGPL/GPL, so it's fully Free, and it is possible to select an output device at run-time, just as mpg321 does (when the man page says run-time switching of output devices, it really means run-time selection). mpg123 even supports pulse, jack and nas, which mpg321 does not seem to support. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531957: minirok: previous track is not shuffled when in random mode
+ Felipe Sateler (Fri, 05 Jun 2009 19:34:55 +1000): When minirok is in random mode, the previous track button goes to the previous track in the playlist, not the previous track that has just been played. Yes, I've been wanting to fix this for some time. I'll try to address it in one of the next releases. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531347: python-gst0.10: AttributeError: 'module' object has no attribute 'Element'
close 531347 thanks % python import gst AttributeError: 'module' object has no attribute 'Element' This seems to have gone away. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531478: /etc/{kbd|console-tools}/remap not supported
+ Anton Zinoviev (Tue, 02 Jun 2009 23:59:55 +0300): On Mon, Jun 01, 2009 at 10:19:45PM +0200, Adeodato Simó wrote: I miss this functionality, and I don't think we should ditch it because it's very handy (just doing a couple adjustments in a keymap, eg. for keybindings). I also found no documentation in console-setup about how to achive something similar within that package. Can you specify what kind of remapping you are using? Maybe it is supported by xkb? Well, I purposedly mentioned the word keybindings above since that's more akin to the use of remapping I'm making use. In particular, I'm using: % cat /etc/kbd/remap # This sed script is run across the dumpkeys output to remap keys on the console $a\ alt keycode 36 = Incr_Console \ alt keycode 37 = Decr_Console So I doubt that's going to be supported out of the box, and rightfully so. Anyway. Could we get console-setup to support an /etc/console-setup/remap file, or get kbd's one to work? XKB supports many options so in most case it should be possible to configure properly the keyboard without remapping. In cases when this is not so I think it is better fill a wishlist bug report against xkb-data than to use remapping as a quick hack. I can make the keyboard file for XKB if needed. Well, as seen above, I'm wanting a rather console-specific mapping, and other people could want for completely different keys, so I can't see how that could fit for xkb-data. But to answer your question - yes, this is possible but I am reluctand to do so. I've noticed that in many occasions dumpkeys doesn't work properly and I don't want to introduce in console-setup bugs that I will be unable to fix. I see. Well, what procedure would you recommend for my use case above? :-) Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531478: /etc/{kbd|console-tools}/remap not supported
Package: kbd,console-setup Hello, I think /etc/console-tools/remap was a very nice feature; I've recently purged console-* from my system except console-setup, and installed kbd instead because console-logs needs that. I saw, then, that kbd ships /etc/kbd/remap, and the init scripts supports it. However, that code path is not executed when console-setup is installed, which I guess will be mostly always in desktop machines, since X depends on console-setup. I miss this functionality, and I don't think we should ditch it because it's very handy (just doing a couple adjustments in a keymap, eg. for keybindings). I also found no documentation in console-setup about how to achive something similar within that package. Additionally, I'll note that the feature works just nice, and it could work if kbd's init script came after console-setup's in the boot sequence. Anyway. Could we get console-setup to support an /etc/console-setup/remap file, or get kbd's one to work? Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531347: python-gst0.10: AttributeError: 'module' object has no attribute 'Element'
Package: python-gst0.10 Version: 0.10.15-1 Severity: minor % python import gst AttributeError: 'module' object has no attribute 'Element' But it seems to work normally. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531219: Bug#530345: bitlbee-dev currently uninstallable due to binNMUs
Hey, Wilmer.
forcemerge 530345 531219
ASAP. (And by the way there are currently two other RC bugs open, both
uncommented since three months.)
Best of all, the one you're reporting is a dupe. :-)
Well, techincally they're different issues: you can fix #530345 just by
doing a sourceful upload with no changes, but source changes are needed
to fix #531219. But it seems you're interested in fixing #531219 already,
which is excellent. :-)
Depends: bitlbee (= ${binary:Version})
The dependency seems right already, it's a binary dep, not a source dep.
I see other programs just make the dependency less tight by doing
something like
Depends: foo (= ${source:Version})
Is that the best I can get? :-/
Well. The problem is that bitlbee-dev is an arch:all package. So, when
you want strict dependencies among binaries from a same source package,
you use:
arch:any Depends arch:any = ${binary:Version}
arch:any Depends arch:all = ${source:Version}
arch:all Depends arch:all = ${source:Version}
arch:all Depends arch:any = not possible*
So with not possible I mean that you need, normally:
Depends: foo (= ${source:Version}), foo ( ${source:Version}.)
or something similar.
HTH,
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529384: [libfwbase1] Package is no longer installable
severity 529384 serious retitle 529384 libfwbase1: uninstallable, needs updating to a newer boost forcemerge 529384 529385 529388 thanks + Colbert Blake Smith (Mon, 18 May 2009 22:32:18 -0500): Package: libfwbase1 Version: 1.3-1 Severity: normal Depends: libboost-thread1.35.0 (=1.35.0-1) but it is not installable Please change the depend to libboost-thread dependency package instead of the numbered versions. Package needs to build-depend on libboost-thread-dev, which will make it gain a dependency on libboost-thread1.38.0. Maintainers, any ETA for an upload? It's the last issue preventing boost1.35 from being removed from testing. Thanks! -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531221: okular: Arbitrarily enforces DRM
+ John Goerzen (Sat, 30 May 2009 19:09:11 -0500): I'm CCing this to Debian-devel because I think it speaks to a larger issue. I just downloaded a PDF, and tried to copy and paste a bit of text from it. I used the selection tool, and Okular offered to speak it to me, but said Copy forbidden by DRM. pdftotext was able to convert the entire file to text format in an instant. So what I want to know is: why are people putting code into Debian that limits our freedom? Why are people putting such code into KDE? And can we please patch it to stop that? I see it's been pointed out in a comment in your blog post already, but I'll mention it here for the benefit of those reading along: obeying DRM is a configurable runtime option in Okular, so it's just a matter of going to the preferences dialog and unchecking the Obey DRM check box. Now I have no idea why it would default to obeying it (or, for that matter, why it would have such an option). I'm CC'ing Pino whom I'm sure will be able to help. (My guess would be that it protects upstream against some shit or whatever, at least by their reckoning, or the person that added it in the first place.) Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529940: lib32asound2: symbol versioning changed in an incompatible way
severity 529940 serious retitle 529940 lib32asound2: symbol versioning changed in an incompatible way (ALSA_0.9.0rc4/8 dropped) thanks Hello, it seems that between 1.0.19-1 and 1.0.20-1 the list of symbols in lib32asound2 changed. More precisely, the list of symbols remained but their associated versioning changed: all symbols associated with ALSA_0.9.0rc4 and ALSA_0.9.0rc8 were changed to live under ALSA_0.9 instead, making applications compiled against = 1.0.19 fail to start due to missing symbols. Note that this problem affects the 32-bit library in amd64, but not the native libraries nor in i386 nor amd64. Also note that we've started having applications like WINE 1.1.19 in experimental rebuilt against 1.0.20, and which don't work against alsa-lib 1.0.19 either. And we'll have no easy way to detect these, since shlibs are not bumped. Will you be able to upload fixed packages in a timely manner? Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530638: simgear-dev: please update dependency from plib1.8.4-dev to libplib-dev
Package: simgear-dev Version: 1.0.0-4 Severity: minor Please depend on 'libplib-dev' or 'libplib-dev | plib1.8.4-dev'. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530001: compiz-core: compiz and compizconfig-settings-manager indirectly conflict
+ Julien Cristau (Sat, 23 May 2009 01:50:58 +0200): On Fri, May 22, 2009 at 12:41:12 -0600, Al Khaef wrote: Hi. all of the below applies to debian squeeze compizconfig-settings-manager (as well as fusion-icon and some other compiz-related packages) requres libcompizconfig0, and compiz-core has the following dependency: Breaks: libcompizconfig0 ( 0.8.0) However, in suqeeze, (0.7.6-1) is the latest available. Therefore, none of these other packages can be installed, and compizconfig can't be run. This is due to a bug in britney (the tool that handles package migration to testing), which doesn't handle Breaks, I think. Hopefully libcompizconfig will migrate to testing soon, in the mean time you can install the version from unstable. It looks like this is stalled because protobuf waits for java stuff on hppa, and failed to build on ia64. sigh. CCing -release to make sure they're aware of the breakage in squeeze. Ugh. Ok, since the blockers seem like will take time to sort out, I've added a hint to allow libcompizconfig to migrate without hppa/ia64. Hopefully it'll succeed. Thanks for the notice, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530249: amule-daemon: Should recommend unzip
+ Luís Picciochi Oliveira (Sat, 23 May 2009 12:00:10 +0100): Package: amule-daemon Version: 2.2.4-1 Severity: normal amule-daemon (as well as the amule package) should recommend unzip. The reason for this is that if a ipfilter is downloaded in zip format (e.g., emulepawcio's), amule will try to extract it using unzip. If unzip is not installed, it will fail silently, logging that that the file is in an unrecognizable format. After installing unzip, amule can extract the ipfilter and use it normally. I've committed the change in my Git repository and will be included in the next upload. Sadly, your mail didn't arrive on time for this morning's 2.2.5-1 upload, so it may be a while until I upload amule again. Thanks! -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529092: amule-daemon: amuled stop responding after download complete
+ alex (Sun, 17 May 2009 19:19:56 +0200): Package: amule-daemon Version: 2.2.3-2 Severity: normal Hello, Hello, alex. Recently I installed daemon version of amule and seems that there is some bug when amuled complete a download (I mean, 100% reached and moving from temporal to complete dir). I used amulegui from another computer and when a download is complete, amulegui stop refreshing data, but stills conected. The only solution I found is restart daemon. I guess that, prior to restarting the daemon, you tried restarting amulegui? In any case, I can't reproduce the problem. I've recently gone back to using amule-daemon myself, and operation of the daemon and the GUI continues as normal after finishing a download. I note that you're using 2.2.3. Would you be able to test with 2.2.4 or the just-uploaded 2.2.5? libcrypto++ has been recently fixed. Also, I launched daemon manually (amuled) and I try to find on logs some information, next string appears: CAUGHT DEAD SOCKET IN SENDPACKET() Maybe it's a old version bug, but I have to downgrade to this version because actual package on sid is broken because libcrypto (#525071) -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529871: Dependency mismatch for nautilus-filename-repairer and nautilus-image-converter
reopen 529871 clone 529871 -1 reassign -1 nautilus-image-converter severity -1 serious retitle -1 nautilus-image-converter: upload of experimental packages to unstable required reassign 529871 nautilus-filename-repairer severity 529871 serious retitle 529871 nautilus-filename-repairer upload of experimental packages to unstable required thanks + Michal Pomorski (Fri, 22 May 2009 00:55:07 +0200): Package: general Severity: important Cant install the these two nautilus plugins. All other plugins installed corerctly. I tried several mirrors. $ sudo aptitude install nautilus-filename-repairer nautilus-image-converter Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information Initializing package states... Done Reading task descriptions... Done The following packages are BROKEN: libnautilus-extension1 The following NEW packages will be installed: nautilus-filename-repairer nautilus-image-converter 0 packages upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 36.7kB of archives. After unpacking 258kB will be used. The following packages have unmet dependencies: libnautilus-extension1: Breaks: nautilus-filename-repairer ( 0.0.5-2) but 0.0.5-1 is to be installed. Breaks: nautilus-image-converter ( 0.3) but 0.2.1-2 is to be installed. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528626: amule: please make it easier to build with debugging symbols
+ Alexandre Rossi (Thu, 14 May 2009 10:48:38 +0200): Hello, Alexandre. Package: amule Version: 2.2.1-1+b1 Severity: normal The amule package build system does not seem to allow building with debugging symbols using the DEB_BUILD_OPTIONS=nostrip trick. Maybe the following would help : - --disable-dependency-tracking --disable-ccache --disable-debug \ + --disable-dependency-tracking --disable-ccache \ +# Enable debug with nostrip +ifneq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) +confflags += --enable-debug +else +confflags += --disable-debug +endif + ### Well, I don't think that's correct, --enable-debug is not about including debugging symbols in the build, but about emitting extra debuggin information when executing the program. Debugging symbols are included if -g is passed to the compiler, and if you check the builds log of amule in http://buildd.debian.org, you'll see -g is being passed. If, however, you're absolutely sure that building with 'nostrip' in DEB_BUILD_OPTIONS is not producing unstripped binaries (i.e., `file /usr/bin/amule` says stripped instead of not stripped), then please let me know and I'll investigate what's going wrong. But please be sure of it to the extent possible! Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515274: gbuffy: Depends on GTK 1.2
+ Kelvin Ku (Thu, 21 May 2009 12:08:39 -0400): Thanks for the gtk2 patch. We are not using debian so we're not sure what your build environment is, but we encountered a few hitches building it after patching: Hello, Kelvin. Thanks for providing these fixes for the GTK2 patch. If I'm not mistaken, the upstream of GBuffy is not really active any more, so I think if somebody feels up to maintaining it as upstream, they should go for it. Is this something any of you would be interested in? Personally, I don't use GBuffy anymore myself, so I also need to find another person to become its Debian maintainer. Thanks! - the original configure was built with autoconf 2.13, but the patched configure.in uses gtk2 m4 macros which seem to require autoconf 2.61 - the Makefile.in does not work with configure generated by autoconf 2.61; the resulting Makefile has some un-substituted $expressions - fix: hack configure to make it work Also, the patched gbuffy itself had some problems: - segfaults when opening the configuration dialog or displaying headers (both operations try to draw a pixmap) - fix: remove the gdk_draw_bitmap function in gbuffy.c so that the internal gdk_draw_drawable function is used instead - window resets position when gbuffy_display is called again, e.g., after closing configuration dialog - fix: use a configure_event callback instead of using the timeout callback to update internal window state after a position/dimension change - mailbox button and main window don't grow and shrink immediately/correctly in response to changes in button label lengths (mailbox: count) - fix: still working on it; button and window sizes are correct when gbuffy is initially launched now, but not while it is running We're not sure who exactly to contact about patching gbuffy, since the gtk2 patches seem to be pending only for the debian package. The gendiff output for our patches is below, if you're interested. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528405: new pulseaudio with uncomplete dependencies
+ Steve Langasek (Sun, 17 May 2009 13:10:01 -0700): On Sun, May 17, 2009 at 04:11:20PM +0200, Adeodato Simó wrote: + Adeodato Simó (Sun, 17 May 2009 11:21:06 +0200): The problem is a bug in the packaging of pulseaudio itself, which doesn't specify in its Depends field that it needs the latest version of libpulse0 to run, despite linking to libpulsecommon-0.9.15.so. According to the Debian Policy, this is a serious bug. (Assuming, of course, that libpulsecommon-0.9.15.so is some kind of private library that only packages from the same source depend on/link against, and that for this reason is okay to ship in libpulse0 and bump its SONAME without a package rename.) It's a new library; I guess (hope) that it's a new API and therefore there are no backwards-incompatibilities that would require a package name change. Oh, I see. Good. Still, perhaps it should be assesed how many apps are going to use this library (is it a private one?), and if it's going to see its SONAME bumped more often than libpulse.so.0 (which one would say is going to be the case by looking at its name), as to avoid having to unnecessarily rename libpulse0. Or, if only a couple packages from the same source package depend on this library, maybe we could do away with Breaks. Thoughts? -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528405: new pulseaudio with uncomplete dependencies
reassign 528405 pulseaudio retitle 528405 pulseaudio: dependency on libpulse0 should be versioned severity 528405 serious thanks + Moritz Molle (Tue, 12 May 2009 20:10:01 +0200): Hello, Moritz. Thanks for reporting this bug Package: pulseaudio Version: 0.9.15-1 Severity: critical Justification: breaks unrelated software Said pulseaudio-package doesn't enforce the installation of a package with libpulsecommon-0.9.15.so in it, so now executing pulseaudio just delivers following message: pulseaudio: error while loading shared libraries: libpulsecommon-0.9.15.so: cannot open shared object file: No such file or directory If I try to install libpulse0 which, according to apt-file, contains said library, it says that it has to remove pavucontrol. I don't want that. I have marked this bug as critical, because it breaks all programs which try to load the pulseaudio-sound-libraries as well. (I have set FLASH_FORCE_PULSEAUDIO=1, and now my iceweasel doesn't start anymore, that's not acceptable) apt-get should have refused to update pulseaudio in the first place. The problem is a bug in the packaging of pulseaudio itself, which doesn't specify in its Depends field that it needs the latest version of libpulse0 to run, despite linking to libpulsecommon-0.9.15.so. According to the Debian Policy, this is a serious bug. Regarding your trying to upgrade libpulse0 and apt wanting to remove pavucontrol, it is just unfortunate that pulseaudio was allowed to migrate to testing without the newer pavucontrol migrating as well, since libpulse0 clearly specifies they should go in together (but the migration script does not support this field, Breaks, yet). And pavucontrol has not migrated yet because it's not built on mipsel, and it's going to be a while until it can be built there due to a toolchain bug. I've added a hint that will hopefully allow pavucontrol to migrate to testing without mipsel in the next britney run. In the meantime, you should be able to install pavucontrol from unstable, if you haven't done so already. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527838: smart: FTBFS: debian/tmp does not exist
+ Daniel Schepler (Fri, 08 May 2009 14:11:21 -0700): Package: smart Version: 1.2-1 Severity: serious Hello, From my pbuilder build log: ... fakeroot debian/rules binary test -x debian/rules dh_clean -k dh_installdirs -A mkdir -p . mkdir -p debian/python-module-stampdir if test -e /usr/share/misc/config.guess ; then \ for i in ./contrib/ksmarttray/admin/config.guess ; do \ if ! test -e $i.cdbs-orig ; then \ mv $i $i.cdbs-orig ; \ cp --remove-destination /usr/share/misc/config.guess $i ; \ fi ; \ done ; \ fi if test -e /usr/share/misc/config.sub ; then \ for i in ./contrib/ksmarttray/admin/config.sub ; do \ if ! test -e $i.cdbs-orig ; then \ mv $i $i.cdbs-orig ; \ cp --remove-destination /usr/share/misc/config.sub $i ; \ fi ; \ done ; \ fi dh_installdirs -psmartpm dh_movefiles -psmartpm dh_movefiles: debian/tmp does not exist. make: *** [install/smartpm] Error 1 dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit status 2 I'll note that this failure is not reproducible in the buildds. All recent uploads of smart have managed to get built in all architectures. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528405: new pulseaudio with uncomplete dependencies
+ Adeodato Simó (Sun, 17 May 2009 11:21:06 +0200): The problem is a bug in the packaging of pulseaudio itself, which doesn't specify in its Depends field that it needs the latest version of libpulse0 to run, despite linking to libpulsecommon-0.9.15.so. According to the Debian Policy, this is a serious bug. (Assuming, of course, that libpulsecommon-0.9.15.so is some kind of private library that only packages from the same source depend on/link against, and that for this reason is okay to ship in libpulse0 and bump its SONAME without a package rename.) Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529049: ITP: octave-bugfix-3.0.5 -- bug fixes for some functions of Octave 3.0.5
+ Rafael Laboissiere (Sun, 17 May 2009 15:31:51 +0200): Hello! * Package name: octave-bugfix-3.0.5 Version : 1.0 Upstream Author : The Octave Forge Community octave-...@lists.sf.net * URL : http://octave.sourceforge.net/bugfix-3.0.5 * License : GPL-3+ Programming Lang: Octave Description : bug fixes for some functions of Octave 3.0.5 This package overrides some functions included with the 3.0.5 release that contain minor bugs. (In this version, just a fixed version of intersect.m is included.) Out of curiosity, what's the use case for having this as a separate package? Would one ever want to run octave3.0 without these fixes? If not, why would you not ship them directly as patches in the octave3.0 source package? Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528489: tasksel: kde-desktop neeeds adjusting for KDE4
+ Adeodato Simó (Wed, 13 May 2009 11:04:38 +0200): Hello, while trying to get an initial view of migrating KDE4 to testing with britney, I noticed that our taskel-meta-faux package [1] was rendered uninstallable because the kde-core metapackage is no longer provided. It seems the KDE meta-packages have been re-organized for KDE4, and now kde-full, kde-minimal and kde-standard are provided. It'd be nice if you could be looking into updating tasksel to these new metapackages, so that there's a version ready to migrate together with KDE4. So, uhm, things have been moving forward nicely since I submitted this, and KDE4 is now ready to migrate to testing. Now, I think to have read on -boot that installing squeeze is not supported at this stage, until Beta1 appears, so I'd like to know whether I can go forward and push KDE4 to testing already, or if we really need to wait for tasksel to be adjusted. A quick reply would be great, since I wouldn't want to lose this window of opportunity for finishing off this transition. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524235: Default alt-gr key replacement should be right alt for usa keyboard.
+ Frans Pop (Fri, 15 May 2009 12:34:36 +0200): On Friday 15 May 2009, Anton Zinoviev wrote: AltGr is useless with the basic US layout because it doesn't define third level where the accented letters are situated. But AFAIK it can still be used for combining characters! Example: Alt-gr+' e - é I'd call that far from useless. And that's how I personally prefer to create accented characters. Dutch does not use them enough that having them on 3rd level is really needed (and I don't write that much in Dutch anyway ;-). Hi, I just catched this message en-passe, and I thought I'd mention I use a US layout with the altgr-intl variant, and I use AltGr in exactly the way Frans mentioned. (NB: I still haven't upgraded to the new X.org / console-data combo.) Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524235: Default alt-gr key replacement should be right alt for usa keyboard.
+ Adeodato Simó (Fri, 15 May 2009 13:44:52 +0200): + Frans Pop (Fri, 15 May 2009 12:34:36 +0200): On Friday 15 May 2009, Anton Zinoviev wrote: AltGr is useless with the basic US layout because it doesn't define third level where the accented letters are situated. But AFAIK it can still be used for combining characters! Example: Alt-gr+' e - é I'd call that far from useless. And that's how I personally prefer to create accented characters. Dutch does not use them enough that having them on 3rd level is really needed (and I don't write that much in Dutch anyway ;-). Hi, I just catched this message en-passe, and I thought I'd mention I use a US layout with the altgr-intl variant, and I use AltGr in exactly the way Frans mentioned. (NB: I still haven't upgraded to the new X.org / console-data combo.) Meh, I just read Anton's reply to Frans, and I realized I read Frans' message a bit too quickly. He uses AltGr as Compose, but I actually type AltGr+e to get é!! Because of the altgr-intl variant, of course. It be really great that such usage doesn't get broken, in case you weren't aware it exists. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528527: Package candidate for removal for GNOME transition
+ Arnaud Fontaine (Wed, 13 May 2009 15:48:38 +0200): I am quite busy at the moment with my exams but I think I can upload version 1.0.1 of gwget before the end of the week-end (I hope that would be ok this way?). This new upstream version ships support for epiphany 2.26, thus fixing this RC bug. That's excellent, Arnaud. Thank you for your effort, and good luck with your exams! -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528481: RM: libkexiv2 -- RoM; obsolete source package
Package: ftp.debian.org X-Debbugs-CC: pkg-kde-ext...@lists.alioth.debian.org Hello, Please remove libkexiv2 and its binary packages (libkexiv2-3, libkexiv2-5, and libkexiv2-dev) from unstable and experimental. This library is now provided by the kdegraphics source package in unstable (with a higher SONAME, which is why cruft report won't pick up this removal). See [1] for an ack of the maintainer for this removal. Also, the dependency problems that `dak rm` will detect are just out of date packages waiting to be built on a couple architectures. Thanks, [1]: http://lists.debian.org/debian-release/2009/05/msg00125.html -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528489: tasksel: kde-desktop neeeds adjusting for KDE4
Package: tasksel Version: 2.78 Severity: important X-Debbugs-CC: pkg-kde-t...@lists.alioth.debian.org Hello, while trying to get an initial view of migrating KDE4 to testing with britney, I noticed that our taskel-meta-faux package [1] was rendered uninstallable because the kde-core metapackage is no longer provided. It seems the KDE meta-packages have been re-organized for KDE4, and now kde-full, kde-minimal and kde-standard are provided. It'd be nice if you could be looking into updating tasksel to these new metapackages, so that there's a version ready to migrate together with KDE4. Thanks, [1]: http://article.gmane.org/gmane.linux.debian.devel.release/21309 -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528525: evolution-jescs: uninstallable
Package: evolution-jescs Version: 2.24.0-1 Severity: serious Your package Conflicts: evolution (= 2.25.0), but 2.26 is in unstable. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528527: epiphany-extension-gwget: uninstallable
Package: epiphany-extension-gwget Version: 0.99-3 Severity: serious Your package Depends: epiphany-gecko ( 2.23), but 2.26 is in unstable. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528525: Package candidate for removal for GNOME transition
Hello, gwget2, evolution-rss, evolution-jescs and icewm are all RC buggy and are being considered for removal in order to get GNOME 2.24/26 migrate to testing. I note that the RC bugs of gwget2 and evolution-jescs have only been filed minutes ago, so if the maintainers express they intend to upload very soon, effort will be put in getting it built quickly and in time in order for it not to be removed. However, the RC bugs have existed unfiled for more than a week, so we'll also take that into account if everything else gets ready. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528579: RM: gtksourceview-sharp2 -- RoM; superseded by gnome-desktop-sharp2
Package: ftp.debian.org X-Debbugs-CC: pkg-cli-libs-t...@lists.alioth.debian.org Hello, the library provided by gtksourceview-sharp2, libgtksourceview2.0-cil, has been renamed to libgtksourceview2-2.0-cil and is provided now by gnome-desktop-sharp2. Please remove gtksourceview-sharp2 and all its binary packages from unstable. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522584: Dependency going away
+ Leopold Palomo Avellaneda (Tue, 14 Apr 2009 13:24:25 +0200): A Diumenge 05 Abril 2009, Ana Guerrero va escriure: bulmages-common depends on kpdf that is going away RSN with kde3 being replaced with kde4. Your package will become uninstallable then. Bulmages upstream is doing a big restructuring. So, the package in sid will be non operative soon. When upstream stabilizes their code (I hope soon) I will try to commit a new package, erasing (and adding) the dependency correctly, I leave this bug as pending. Thanks to report it. This is your choice, but not fixing it means your package will have to be removed from testing as soon as KDE4 is ready to migrate without further notice. If you prefer, you can make an upload just changing the dependency, that should suffice. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#148955: Not fixing this in the NMU
Hello, Ian. On Sat, 09 Feb 2008 16:04:48 +, you wrote: I'm about to NMU lib3ds to upgrade to 1.3.0 upstream and to fix some of the other outstanding bugs. I just thought I'd comment on why I'm not fixing this bug: Providing an existing library as a shared library is not simply a matter of providing the appropriate build setup. Also needed is to consider ABI stability. This usually involves negotiating (or trying to negotiate) with upstream about sonames, determining which versions are and are not ABI-compatible, and so forth. Also, I see from the bug logs that the shared libraries were withdrawn by upstream. It seems unwise to revert a decision without at least trying to find out why it was taken ! I think that in the meantime, other applications which want to use libds3 should link against the .a. I will fix the lack of PIC on amd64 so that this can work properly. Ian. I'm only replying to this very old mail to point out that your lib3ds 1.3.0-0.1 NMU did include shared libraries after all, but included them in the development package lib3ds-dev instead of a dedicated binary package. This most likely happened due to upstream having started to provide shared libraries themselves in 1.3.0, and the build system of the package not being robust enough as to prevent their inclusion in the development package, and perhaps you forgetting to run debdiff prior to uploading. My only intent with this mail is to contribute to our having better quality NMUs in the future. Also, a QA person will be uploading a fixed version soon. For reference: http://snapshot.debian.net/archive/2008/02/18/debian/pool/main/lib3/lib3ds/lib3ds-dev_1.3.0-0.1_amd64.deb HTH, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528378: shntool: please suggest monkeys-audio
Package: shntool Version: 3.0.7-1 Severity: wishlist Hello, it'd be great if shntool could suggest: monkeys-audio, which is the package that gives shntool the ability to split APE files. I realize this package is not in Debian proper (it's in the debian-multimedia.org repositories), but Suggests is okay for this purpose and will allow users quickly finding out the package they need for APE support. Thanks for considering! -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524452: Bug#523596: problem of 523596 is in graphicsmagick
+ Thomas Viehmann (Fri, 08 May 2009 08:39:41 +0200): tag 524452 + patch thanks Thanks Daniel for the update. Unfortunately, psiconv still fails to build with this version because it apparently makes use of a prehistoric and long deprecated API function. It doesn't really make sense to schedule another bin-NMU until this is problem fixed with a psiconv upload. Then lets move the conversation to #524452. Tested with the Clipart file in tarball's examples directory. I will not comment on the nature of that file, though. Ah, great, thanks Thomas. Daniel, do you think you could make an upload? Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523596: problem of 523596 is in graphicsmagick
Hey, Daniel. reassign 523596 libgraphicsmagick1-dev retitle 523596 Bogus cflags returned by GraphicsMagick-config $ GraphicsMagick-config --cflags -fopenmp -Wall -g -fno-strict-aliasing -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector -fPIE -O2 -Wall -pthread Not good. Here it is -fPIE causing trouble (FTBFS), but I do not think that it has any business specifying any of the above. Similar considerations probably apply to other options and other -config. Do you have an estimation of when you'll be able to address this issue? It seems to be the last bit needed for the graphicsmagick transition to become a candidate to be tried for migration (in particular, the fix is needed so that psiconv can be rebuilt, and it's the last reverse dependency needing to be built). If not, Thomas has offered to prepare a fix to be uploaded. I'm told he could prepare an upload that would just provide under debian/ -config executables that completely substitute upstream's, or a patch that fixes the upstream code itself. Please let us know what you prefer: upload yourself, and in this case let us know an approximate ETA, or a NMU, and in this case let us know your preferred approach. Thanks! -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527462: gnunet: uninstallable
Package: gnunet Version: 0.8.0b-5 Severity: serious Hello, gnunet was recently Bin-NMUed for the libltdl7 transition. Because of #527453 (gnunet: not Bin-NMU safe), this rendered the gnunet metapackage uninstallable. I'm filing this as a separate report to #527453 because a simple sourceful upload will fix this bug, whereas #527453 needs source changes. Ideally, #527453 will be addressed at the same time as that sourceful upload happens, but it's not strictly necessary. (Hence, also, the differing severities of both bug reports.) Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527314: please binNMU monotone for botan transition
+ Zack Weinberg (Wed, 06 May 2009 12:55:20 -0700): Hello, Zack (and keysafe maintainers). Hi, per the appended bug report, monotone needs to be recompiled to pick up the new libbotan soname. Please schedule: nmu monotone_0.43-3 . ALL . -m Recompile with botan-devel 1.8.2 dw monotone_0.43-3 . ia64 mips mipsel sparc . -m 'libbotan1.8-dev (= 1.8.2-1)' This closes bug #527314. I have verified that the package builds with the new library. monotone and keysafe certainly need to be rebuilt against the new version of botan, since the SONAME has changed. However, the libbotan1.8 binary package name should have been renamed in the process of bumping the SONAME (Bug#527461), and I won't be scheduling Bin-NMUs of either package until that has happened. The reason for not scheduling the Bin-NMUs is that they would be freely migrating to testing, which still has Botan 1.8.1, and then the bug would happen there in addition to unstable (not only botan 1.8.2 didn't rename the binary package, it also has a bogus shlibs file!). However, I realize having this situation in unstable is inconvenient, so you may make sourceful uploads of monotone and keyfile in order to get them rebuilt. The point is that, independently of you taking up on this offer or not, I'll block migration of these pacakges to testing until the issue is fixed in botan, just in case; so you may as well upload. (New source versions can easily be blocked from migration, Bin-NMUs can't be.) Cheers, -- Forwarded message -- Package: monotone Version: 0.43-3 Severity: grave Justification: renders package unusable libbotan1.8 was recently upgraded from 1.8.1 to 1.8.2. $ mtn mtn: error while loading shared libraries: libbotan-1.8.1.so: cannot open shared object file: No such file or directory $ ldd /usr/bin/mtn ... libbotan-1.8.1.so = not found ... $ ls -l /usr/lib/libbotan*.so -rw-r--r-- 1 root root 2905232 2009-05-04 03:58 /usr/lib/libbotan-1.8.2.so lrwxrwxrwx 1 root root 17 2009-05-06 13:07 /usr/lib/libbotan.so - libbotan-1.8.2.so Monotone needs to be rebuilt against the new Botan 1.8.2. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527461: libbotan1.8: SONAME bumped without package rename
Package: libbotan1.8 Version: 1.8.2-1 Severity: serious Hello, libbotan1.8/1.8.2-1 introduces a new SONAME with respect to 1.8.1-1, but the binary package has not been renamed. That's not a supported workflow in Debian. I recommend you start naming the binary packages according to the actual SONAME. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527453: gnunet: not Bin-NMU safe
Package: gnunet Version: 0.8.0b-5 Severity: important Hello, the gnunet source package is not Bin-NMU safe because an arch:all package (gnunet) tries to depend on arch:any packages with a strict version. This is not supported (can't be). Please reconsider whether the scrict version requirement is really needed (it seems gnunet is a metapackage, so unless there's good reasons for it, I would say it is not), and drop it in that case. If it's really needed, you'll have to do one of the Depends: foo (= $VERSION), foo ( $SOMETHING_ELSE) tricks. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523596: problem of 523596 is in graphicsmagick
+ Daniel Kobras (Thu, 07 May 2009 20:44:16 +0200): Hi Dato! Hello! On Thu, May 07, 2009 at 08:59:33AM +0200, Adeodato Simó wrote: Do you have an estimation of when you'll be able to address this issue? It seems to be the last bit needed for the graphicsmagick transition to become a candidate to be tried for migration (in particular, the fix is needed so that psiconv can be rebuilt, and it's the last reverse dependency needing to be built). I've just uploaded graphicsmagick 1.3.5-5 with a sanitised GraphicsMagick-config. Great, thanks Daniel. Unfortunately, psiconv still fails to build with this version because it apparently makes use of a prehistoric and long deprecated API function. It doesn't really make sense to schedule another bin-NMU until this is problem fixed with a psiconv upload. Ah, good thing that you tried to build it, then. Thomas, is this something you could tackle? As I said elsewhere, I'd rather not remove psiconv from testing since it provides a library with a reverse dependency. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527205: ITP: inotifyx -- Simple Python binding to the Linux inotify file system event monitoring API
+ Ritesh Raj Sarraf (Wed, 06 May 2009 12:23:06 +0530): Hello!, and thanks for your interest in packaging new software for Debian. * Package name: inotifyx Version : 0.1.0 Upstream Author : Forest Bond for...@alittletooquiet.net * URL : http://www.alittletooquiet.net/software/inotifyx/ * License : MIT/X Programming Lang: C, Python Description : Simple Python binding to the Linux inotify file system event monitoring API inotifyx is a Python extension providing access to the Linux inotify file system event notification API. It is primarily written in C but has some Python window dressing. Could you please include in the description a few lines on why would one want to use inotifyx instead of the already available pyinotify bindings? By reading the upstream homepage, it already mentions: | Reasons you might choose inotifyx over pyinotify: | | * inotifyx is a C extension and does not use ctypes, making it faster | and less prone to subtle breakage due to changes in the inotify API. | | * inotifyx is a much thinner wrapper around inotify. pyinotify is more | complicated. It does provide features that inotifyx does not, but many | of them are not needed by most applications. | | * The API provided by pyinotify seems to change in incompatible ways on | a fairly regular basis and with little justification. inotifyx has a | simple API that will change rarely, if ever. Maybe that's a bit too long for the description, but it should be easy enough to summarize those arguments for the long description. By the way, do you have preview packages available already? Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527244: rsibreak: too verbose debug output in .xsession-errors
Package: rsibreak Version: 1:0.9.0-4 Hello, my ~/.xsession-errors grows spectacularly nowadays, and half of it is filled with lines from rsibreak like: rsibreak(27067) RSITimer::checkScreensaverMode: Screensaver timeout is set at 0 rsibreak(27067) RSITimer::timerEvent: patience: 0 pause_left: 0 relax_left: 0 tiny_left: 284 big_left: 3284 idle: 0 It seems that such two lines are emitted *every* *second*. Please make it stop. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527224: Please binNMU ocsigen/1.1.0-2
+ Stéphane Glondu (Wed, 06 May 2009 13:08:08 +0200): Hello, nmu ocsigen_1.1.0-2 . ALL . -m 'Recompile with ocaml-sqlite3 1.4.0' This would close #527224. Scheduled. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524585: libept_0.5.26+b1(mips/unstable): FTBFS on mips
close 524585 thanks + Peter De Schrijver (Sat, 18 Apr 2009 12:44:51 +0300): dh_install -plibept0 dh_install: libept0 missing files (debian/tmp/usr/lib/lib*.so.*), aborting make: *** [binary-install/libept0] Error 1 dpkg-buildpackage: failure: /usr/bin/fakeroot debian/rules binary-arch gave error exit status 2 I'm closing this bug because libept managed to build successfully on mips recently: https://buildd.debian.org/fetch.cgi?pkg=libept;ver=0.5.26+b1;arch=mips;stamp=1241331185 The failure was most probably caused by the kernel/glibc problem that's been aflicted to the mipsen buildds. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526792: vsftpd: some libraries are linked to with hard-coded SONAMEs
Package: vsftpd Version: 2.1.1~pre1-1 Severity: serious From vsftpd-2.1.1~pre1-1/vsf_findlibs.sh: # Look for libcap (capabilities) if locate_library /lib/libcap.so.1; then echo /lib/libcap.so.1; else locate_library /usr/lib/libcap.so echo -lcap; locate_library /lib/libcap.so echo -lcap; fi That's wrong, as it prevents rebuilding against a newer version of libcap unless the old version is purged from the system first. Please patch that script to just execute the else part, which will do the right thing in every Debian installation with the correct development packages installed. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526078: RM: xfree86-driver-synaptics -- renamed to xserver-xorg-input-synaptics; only provides obsolete packages
Package: ftp.debian.org 07:53 dato Ganneff, jcristau: I think xserver-xorg-input-synaptics/1.1.0-1 (source) was wrongly removed from unstable 07:56 dato Ganneff: by checking projectb, you can see the xserver-xorg-input-synaptics/1.1.0-1 (binary) package is marked as provided by xserver-xorg-input-synaptics/1.1.0-1 (source), so I'm not sure why the cruft script thought it was an obsolete package 07:58 dato Ganneff: AIUI (jcristau can confirm), the obsolete package are xfree86-driver-synaptics/0.14.7~git20070706-3 (source) and xfree86-driver-synaptics/0.14.7~git20070706-3 (binary); but these couldn't have been auto-detected, and a bug should have been filed. I'll do that now. So, this bug needs two actions: removal of xfree86-driver-synaptics, bringing back xserver-xorg-input-synaptics/1.1.0-1 (source) to unstable (it's in projectb and in the pool, so it should be possible). Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522150: amsynth: Depends on libjack0.100.0-0
+ Felipe Sateler (Wed, 29 Apr 2009 07:52:50 +1000): El 29/04/09 01:03 Adeodato Simó escribió: + Felipe Sateler (Tue, 28 Apr 2009 21:03:45 +1000): Hello, Felipe. El 19/04/09 17:54 Adeodato Simó escribió: I note that the Debian Multimedia Team is listed as the maintainer for amsynth. Could some member of the team make an upload? amsynth is the last package holding the dropping of libjack0.100.0-0, which if I’m not mistaking is a goal of yourselves. :-) But I’m tracking it myself as well, so it’d be great to have it off my plate at some point. Or let me know if I should stop tracking it. The package got already uploaded, so it is probably too late by now. Thanks for keeping track of this! I think it is OK for you to drop this transition from your tracklist, since it is probable that the new jack will wait until a new upstream release before a new upload. Once again, thanks for keeping this on your mind! I'm sorry for not letting you know earlier that the jack package would not get uploaded yet (I'm not one of the people most involved with that package, I just announced the transition). I see. Well, nevermind: all packages have been rebuilt, and amsynth uploaded as you hinted, so there is no package left depending on libjack0.100.0-0 in unstable (and soon in testing), which means you can remove the libjack0.100.0-0 transitional package at your convenience, be it an upload only for that, or as part of a new upstream version, or whatever. I'm not sure what the status regarding the development package is, but I think I gave clear instructions on how that change should be pursued. I won't be tracking that, though. Do not worry about that, I will take care of it. As soon as the jack people are ready to upload a version dropping the -0 transitional package, I will follow your instructions and drop in a separate upload (allowing for migration to testing) the -0-dev package, and making the -dev Provide the transitional package. I will file minor (or serious in the case of versioned build-depends) bugs against all affected packages and eventually drop the Provides. Can you file the two bugs about versioned build-depends already, at important severity? So that maintainers have some warning in advance of what's coming. The packages were gst-plugins-bad0.10 and jackbeat. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526081: schroot: not enough warning for missing chroot
Package: schroot Version: 1.2.2-1 Hello, I had a bunch of LVM type chroots, and after removing one of them, a script that tried to make use of it started emitting the following output: E: boost::filesystem::create_directory That's all. As you can see, it's not very descriptive of the problem. It is true the script rus schroot with -q. Without -q, one gets: E: boost::filesystem::create_directory E: etch-i386-source: Chroot setup failed: stage=setup-start Which is also not indicative at all of what the exact problem was (Could not find location /lvm-etch_i386 in device /dev/vg/chroot). It be nice if something to that could be printed, even with -q. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#477366: linking ncurses-ruby against libncursesw5
Hello, I don't really use the ncurses-ruby library, but I wanted to try the sup mailed which is written in Ruby and makes use of this library. Unfortunately, non-ASCII characters were not rendered correctly. Applying the patch provided by Micah Anderson to ncurses-ruby 1.1-3 solved the rendering problems in sup. It'd be great if this patch could be applied to the ncurses-ruby Debian package. We're in the beginning of a release cycle, and any regressions can be ironed out, or the patch reverted. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525071: Update
The maintainer of libcrypto++ can reproduce the problem and is taking a look. However, it may take a while. In the meantime, amule will be unable to migrate to testing. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526081: [buildd-tools-devel] Bug#526081: schroot: not enough warning for missing chroot
+ Roger Leigh (Wed, 29 Apr 2009 09:21:09 +0100): The only create_directory call is in bin/schroot-mount/schroot-mount-main.cc which creates mountpoints inside the chroot. Are you mounting in a directory path which has more than two levels nonexistent? It might be that mkdir is failing due to create_directory not behaving like mkdir -p, in which case we should add the functionality. Regarding errors, the useless error is coming from boost. I'll need to reproduce it and see what it's doing, and then file a bug against boost if it's at fault. I'm just using a chroot definition as follows: [foo] type=lvm-snapshot location=/nonexistant device=/dev/vg/chroot lvm-snapshot-options=--size 1G And then: % sudo schroot -c foo-source E: boost::filesystem::create_directory E: foo-source: Chroot setup failed: stage=setup-start I hope that, with that, you can reproduce. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526120: uprecords: print the actual rank when sorting by boot time
Package: uptimed Version: 1:0.3.16-3 Severity: wishlist Hello, Arguably, it'd be more useful if the output of `uprecords -b` (or -B) would print in the first column the actual rank of each record, rather than just a sequence from 1 to 10. So, instead of: 1 100 daysJan 2007 2 300 daysDec 2007 3 150 daysJun 2008 It could print: 3 100 daysJan 2007 1 300 daysDec 2007 2 150 daysJun 2008 Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525071: Regarding the amule segfault bug
Hello all. Thanks for your report about the current segfault in Debian. I've asked the libcrypto++ maintiner to help with the issue, since the crash seems to happen in libcrypto++ code, and he's taking a look at the issue. I'll keep you updated about any progress. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522150: amsynth: Depends on libjack0.100.0-0
+ Felipe Sateler (Tue, 28 Apr 2009 21:03:45 +1000): Hello, Felipe. El 19/04/09 17:54 Adeodato Simó escribió: I note that the Debian Multimedia Team is listed as the maintainer for amsynth. Could some member of the team make an upload? amsynth is the last package holding the dropping of libjack0.100.0-0, which if I’m not mistaking is a goal of yourselves. :-) But I’m tracking it myself as well, so it’d be great to have it off my plate at some point. Or let me know if I should stop tracking it. The package got already uploaded, so it is probably too late by now. Thanks for keeping track of this! I think it is OK for you to drop this transition from your tracklist, since it is probable that the new jack will wait until a new upstream release before a new upload. Once again, thanks for keeping this on your mind! I'm sorry for not letting you know earlier that the jack package would not get uploaded yet (I'm not one of the people most involved with that package, I just announced the transition). I see. Well, nevermind: all packages have been rebuilt, and amsynth uploaded as you hinted, so there is no package left depending on libjack0.100.0-0 in unstable (and soon in testing), which means you can remove the libjack0.100.0-0 transitional package at your convenience, be it an upload only for that, or as part of a new upstream version, or whatever. I'm not sure what the status regarding the development package is, but I think I gave clear instructions on how that change should be pursued. I won't be tracking that, though. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525511: dvdauthor: depends on obsolete package libmagick10
+ Ben Hutchings (Sat, 25 Apr 2009 14:17:33 +0100): On Fri, 2009-04-24 at 23:50 -0500, Drake Wilson wrote: Package: dvdauthor Version: 0.6.14-3+b2 Severity: important Just what it says on the tin: dvdauthor in sid depends on libmagick10, but that package is no longer available in sid. This should be fixable with a binNMU: nmu dvdauthor_0.6.14-3 . ALL . -m 'Rebuild against libmagickcore2 (Closes: #525511)' Bah. I actually scheduled Bin-NMUs for the imagemagick transition on April 11th, but I did a mistake and most of them need to be scheduled again. Done that now, including dvdauthor. (The mistake was that I scheduled the Bin-NMUs before the obsolete packages were decrufted, which was fatal in this case because Provides were involved. I actually knew about this, but it seems I didn’t remember when scheduling them.) Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523502: Could somebody upload this? TIA. (was RFS: quick-lounge-applet (updated package))
Uhm, thanks for trying to sponsor, and I’m sorry it failed. I’m CC'ing the maintainer (Diego Fernández) so that he can take a look at fixing. Diego, according to Josselin Mouette, the problem is that the GnomeDItemEdit API has been removed in GNOME 2.26, and quick-lounge-applet should be ported to use GKeyFile instead. Fortunately, Joss said there’s a new upstream version of q-l-a that does this. Could you prepare an upload? Thanks both! + LI Daobing (Wed, 22 Apr 2009 20:39:42 +0800): Hello, On Wed, Apr 22, 2009 at 20:34, LI Daobing lidaob...@gmail.com wrote: Hello, On Wed, Apr 22, 2009 at 15:42, Adeodato Simó d...@net.com.org.es wrote: It’d be great if somebody would take a look into uploading this package, since it’s needed for the gnome-desktop transition. Many thanks in advance! + Diego Fernández Durán (Fri, 10 Apr 2009 23:36:17 +0200): Dear mentors, I am looking for a sponsor for the new version 2.12.5-6 of my package quick-lounge-applet. It builds these binary packages: quick-lounge-applet - GNOME panel applet to organise preferred applications The package appears to be lintian clean. The upload would fix these bugs: 523502 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/quick-lounge-applet - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/quick-lounge-applet/quick-lounge-applet_2.12.5-6.dsc I would be glad if someone uploaded this package for me. I'll take a look on this. build failed with cowbuilder cc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -DPREFIX=\/usr\ -DSYSCONFDIR=\/etc\ -DDATADIR=\/usr/share\ -DLIBDIR=\/usr/lib\ -DGNOMELOCALEDIR=\/usr/share/locale\ -DGLADEDIR=\/usr/share/quick-lounge-applet/glade\ -DGMENU_I_KNOW_THIS_IS_UNSTABLE -pthread -D_REENTRANT -DORBIT2=1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/libgnome-2.0 -I/usr/include/orbit-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/libbonobo-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0 -I/usr/include/libart-2.0 -I/usr/include/gnome-keyring-1 -I/usr/include/libbonoboui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libxml2 -I/usr/include/gail-1.0 -I/usr/include/gnome-vfs-module-2.0 -I/usr/include/gnome-desktop-2.0 -I/usr/include/startup-notification-1.0 -I/usr/include/libglade-2.0 -I/usr/include/panel-2.0 -I/usr/include/gnome-menus -g -O2 -g -Wall -O2 -c dlg-properties.c dlg-properties.c:31:41: error: libgnomeui/gnome-ditem-edit.h: No such file or directory dlg-properties.c: In function 'update_list': dlg-properties.c:422: warning: unused variable 'box' dlg-properties.c: In function 'get_button_from_uri': dlg-properties.c:712: warning: unused variable 'box' make[3]: *** [dlg-properties.o] Error 1 make[3]: Leaving directory `/tmp/buildd/quick-lounge-applet-2.12.5/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/buildd/quick-lounge-applet-2.12.5' make[1]: *** [all] Error 2 make[1]: Leaving directory `/tmp/buildd/quick-lounge-applet-2.12.5' make: *** [debian/stamp-makefile-build] Error 2 dpkg-buildpackage: failure: debian/rules build gave error exit status 2 E: Failed autobuilding of package I: unmounting dev/pts filesystem I: unmounting proc filesystem - Cleaning COW directory forking: rm -rf /var/cache/pbuilder/build//cow.13401 -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523502: Could somebody upload this? TIA. (was RFS: quick-lounge-applet (updated package))
+ Diego Fernández Durán (Fri, 24 Apr 2009 13:28:39 +0200): About the cowbuilder error, I successfully compiled 2.12.5-6 package with pdebuild. I don't know exactly what is failing. When you sent your initial RFS, gnome-desktop 2.26 hadn’t been uploaded to unstable yet, that’s why succeeded. Then, when gnome-desktop 2.26 hit unstable, it started failing. I hope the new upstream version works better with the new libraries. I think it will. :-) Ciao, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524834: ITP: syncmaildir -- Sync Mail Dir is a set of tools to synchronize Maildirs
Hello!, Enrico. (I’m adding -devel back in case there can be people interested on this.) On Mon, Apr 20, 2009 at 05:35:20PM +0200, Adeodato Simó wrote: So does it support (or will it support) using it in the “fetch from server, read/delete some stuff on client, maybe read some stuff on the server, push to server” mode, and it’ll do all the smart sync stuff (I’m told) OfflineIMAP does? Sorry, but I don't get it. I'll try to answer anyway... You have 2 commands: smd-pull that propagates chenges made on the server to the client, and smd-push that does the opposite. These changes include adding a message, deleting one, renaming, updaing the header... I usually pull more frequently than push, so the updating cycle you are describing is not strictly necessary in smd. In any case, the words server and client don't make any real sense here, it is very symmetric. Right. My question is what happens if I do, say: laptop% smd-push laptop% smd-pull # this brings message M as new laptop% read mail, including message M server% read mail, inclluding message M; flag message M laptop% smd-push laptop% smd-pull Are either laptop or server left with a duplicate copies of M (perhaps one flagged, one not)? Or, perhaps, you’ll see it more clearly if we say there is one server and to clients, eg. a desktop and a laptop, both of which should be useable to read mail independently. I must confess I’m not an OfflineIMAP user myself, but as I understood it, it can gracefully cope with such situation. I think I'll (I'm also the upstream) develop some sort while-true script that will iterate pull and push and eventually notify the user if something goes wrong with some modern eye-candy technology. AFAIK OfflineIMAP gives you (or will give you soon) something more called always-connected-with-ther-server-to-fetch-mail-ASAP option that smd does not provide right now (and that I really don't miss: since pulling is quite fast for the moment I'm not missing the while true script either...). Moreover OfflineIMAP is well tested, and smd is not beeing a *very* young software. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523502: Could somebody upload this? TIA. (was RFS: quick-lounge-applet (updated package))
It’d be great if somebody would take a look into uploading this package, since it’s needed for the gnome-desktop transition. Many thanks in advance! + Diego Fernández Durán (Fri, 10 Apr 2009 23:36:17 +0200): Dear mentors, I am looking for a sponsor for the new version 2.12.5-6 of my package quick-lounge-applet. It builds these binary packages: quick-lounge-applet - GNOME panel applet to organise preferred applications The package appears to be lintian clean. The upload would fix these bugs: 523502 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/quick-lounge-applet - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/quick-lounge-applet/quick-lounge-applet_2.12.5-6.dsc I would be glad if someone uploaded this package for me. Kind regards Diego Fernández Durán -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525071:
+ Claudio Saavedra (Wed, 22 Apr 2009 10:49:35 +0300): FWIW, I can confirm this bug. amule crashes on me on startup. The stacktrace is the same. On i386, I assume? -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524998: ITP: libmqdb-perl -- MappedQueryDB toolkit for federated databases
+ Charles Plessy (Tue, 21 Apr 2009 20:49:27 +0900): Files: debian/* Copyright: 2009, Charles Plessy ple...@debian.org License: PD Please treat this packaging work as if it were in public domain. Is such a wording actually appropriate for this, “as if”? -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525071: 2.2.4-1+b1 automatically rebuilt against libcrypto++8 segfaults on start
+ Stanislav Maslovski (Wed, 22 Apr 2009 01:37:09 +0400): Package: amule Version: 2.2.4-1+b1 Severity: normal For your information: after todays upgrade to automatically rebuilt amule 2.2.4-1+b1 it segfaults on start. The problem seems to be related with libcrypto++8, as returning back to 2.2.4-1 built with libcrypto++7 solves the problem. I’ve been running 2.2.4-1+b1 myself since available for several days, and in fact I did built amule locally against libcrypto++8 before the libcrypto++ maintainer uploaded the new version to unstable. However, I’m on amd64 and not i386. I’m CC'ing debian-user in case there are people with i386/unstable/amule who can confirm or deny the segfault. Please CC 525...@bugs.debian.org if you do so. Also, do you get any kind of backtrace, or can obtain one? Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524834: ITP: syncmaildir -- Sync Mail Dir is a set of tools to synchronize Maildirs
+ Enrico Tassi (Mon, 20 Apr 2009 10:10:35 +0200): Hola! Description : Sync Mail Dir is a set of tools to synchronize Maildirs Sync Mail Dir is a set of utilities to synchronize a pair of mail boxes in Maildir format, using SSH to transfer data. Unlike OfflineIMAP It requires no IMAP server to be installed on the remote host. Sync Mail Dir design is similar to the one Maildirsync, but is more efficient in terms of CPU cycles and disk I/O. So does it support (or will it support) using it in the “fetch from server, read/delete some stuff on client, maybe read some stuff on the server, push to server” mode, and it’ll do all the smart sync stuff (I’m told) OfflineIMAP does? Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522150: amsynth: Depends on libjack0.100.0-0
+ Daniel James (Wed, 01 Apr 2009 12:06:39 +0100): Hi Felipe, The Debian Multimedia Maintainers will be dropping libjack0.100.0-0 soon, so you should switch to using upstream's default name. Changing libjack0.100.0-0 to libjack0 in debian/control and dropping debian/patches/80_libjack.dpatch should be enough. Unfortunately not in the longer term, there is a more serious bug that amsynth does not work with JACK 2 at all (for example, the current upstream 1.9.2 release of JACK). Nevertheless, in the meantime, would you mind changing your dependency on libjack0.100.0-0 for a dependency on libjack0? It’s a oneliner, and will help the j-a-c-k maintainers in their goal of dropping the libjack0.100.0-0 transitional package. Or let us know if you’d prefer for somebody to NMU this change for you! I note that the Debian Multimedia Team is listed as the maintainer for amsynth. Could some member of the team make an upload? amsynth is the last package holding the dropping of libjack0.100.0-0, which if I’m not mistaking is a goal of yourselves. :-) But I’m tracking it myself as well, so it’d be great to have it off my plate at some point. Or let me know if I should stop tracking it. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522716: Pulseaudio upload to unstable
Hey, Sjoerd. Any plans to make an upload of pulseaudio to unstable (either 0.9.14-2, or a 0.9.15 version), addressing some of its RC bugs? Particularly the FTBFSes on hppa (#520378) and with new libtool (#522716), and seeing what’s up with #521282 would be nice too. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520378: Pulseaudio upload to unstable
+ Sjoerd Simons (Sat, 18 Apr 2009 18:46:02 +0100): On Sat, Apr 18, 2009 at 07:12:30PM +0200, Adeodato Sim? wrote: Hey, Sjoerd. Any plans to make an upload of pulseaudio to unstable (either 0.9.14-2, or a 0.9.15 version), addressing some of its RC bugs? Particularly the FTBFSes on hppa (#520378) and with new libtool (#522716), and seeing what???s up with #521282 would be nice too. An upload of 0.9.15 will happen soon (either today or tomorrow), which should fix the HPPA FTBS and seems to build fine with current libtool on my machine. #521282 will probably not be fixed in that upload (it seems to be at least two different bugs and need some investigation) Great, thanks for the status update! -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#456133: qiv imlib
+ Bart Martens (Sat, 18 Apr 2009 13:01:46 +0200): On Fri, 2009-04-17 at 10:09 +0200, Adeodato Simó wrote: I suggest somebody packages pqiv, we let it migrate to testing, and then we remove imlib11 and qiv from testing once icewm has stopped using it. I don’t mind that we leave qiv around in unstable for users who may not be happy with pqiv, and to “wait and see” if upstream moves and ends up upgrading to imlib2. But if Squeeze comes and this has not happened, we should remove qiv from unstable as well I think. Bart, thanks for the pointer to pqiv: would you be up to packaging it? I’m a qiv user myself, and after compiling it here, it seems to fill the niche gracefully. If not, I’ll file a RFP. Thoughts on this plan? Good plan. I just uploaded pqiv Aha. I’m CCing Andreas Metzler, though he problably read your mail via -release or something: he managed to file ITP #524569 roughly an hour before you filed #524578, but since he said “I am not stuck on maintaining this myself”, he’ll hopefully not mind you having prepared and uploaded your own as well. I chose to package pqiv without Conflicts/Provides/Replaces qiv. At least for now. Yes, I think not going Conflict/Provides/Replaces for now is a good choice (people can try it without uninstalling qiv, etc.). Just remember to do the dance if qiv doesn’t make it to Squeeze after all. I see that qiv upstream has a new developer, so maybe the imlib problem in qiv gets solved before squeeze freeze. http://www.klografx.net/qiv/ Qiv is not longer supported by me (Adam Kopacz), please visit the new Homepage: spiegl.de/qiv http://spiegl.de/qiv/ qiv.a...@spiegl.de Ah, that’s great; ideally both maintainers of qiv and pqiv should be made aware one of another if it hasn’t happened already. :-) Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524604: libept: needs to ship the documentation in a separate package for several reasons
Package: libept Version: 0.5.26 Hello!, libept people. I’d like to bring up for your consideration the idea of shipping the HTML documentation for libept in a separate package than libept-dev, eg. libept-doc. There are two issues. One is the space/duplication argument, which is not that of a big issue in this case since libept’s compressed documentation is only a bit more than 2MB (so about 20-25MB of wasted space in total). Anyway, the other bit that concerns me is that having libept build-depend on graphviz somewhat complicates the build-depends chain. For the moment, at the moment the apt transition is stalled because libept can’t be rebuilt in several places because... pango1.0 is uninstallable. Do you have any thoughts why it would be a bad idea to make this split? Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524120: transitions.yaml handling: the PTS needs to grok finished transitions
+ Mark Hymers (Wed, 15 Apr 2009 19:39:53 +0100): On Wed, 15, Apr, 2009 at 11:04:18AM +0200, Stefano Zacchiroli spoke thus.. On Wed, Apr 15, 2009 at 10:25:40AM +0200, Adeodato Simó wrote: I see the PTS as the consumer of the YAML file. There can be, theoretically, other consumers and basically you are implicitly proposing that all consumers implement the cleanup upon migration logics. FWIW, Adam Barrat (thanks!) just prodded me on IRC about this, remembering me that devscripts contains another consumer of that YAML file (/usr/bin/transition-check), which is affected by the very same problem. In a sense, that strengthen my feeling that the solution should be FTP master side, let's gather some more comments ... As I've just mentioned to Dato and Luk on #-release, we've no objection to cleaning up the file at each dinstall and have a patch for it if they're happy for us to apply it. They're just discussing it now (I assume checking that it won't have any unwanted side effects from their side). Right. I thought about it, and please do implement such cleaning on each dinstall, and we can close this bug when the code is in place. Additionally, it’d be great if a mail could be sent for each transition that gets automatically cleaned, but it’s not a requisite. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518673: libidn_1.12-2(hppa/experimental): FTBFS: java not available on hppa
+ Simon Josefsson (Fri, 17 Apr 2009 00:29:51 +0200): The sparc experimental buildd has failed to build the latest upload, since the buildd doesn't seem to have gcj. As far as I can tell, that would be a problem with the sparc buildd. There are gcj packages for sparc in the archive. This is a problem with them being temporarily uninstallable. I’ve set for libidn to be retried when they go back to being installable. I’ve looked at what you did. It indeed does the job, and that’s the basic idea to use, debhelper’s -N. A bit more idiomatic code is: | NO_JAVA_ARCHES := arm hppa hurd-i386 | DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) | | ifeq (,$(filter $(DEB_HOST_ARCH),$(NO_JAVA_ARCHES))) | ENABLE_JAVA := --enable-java | else | export DH_OPTIONS=-Nlibidn11-java | endif And then, you can lose all the $(DH_NO_JAVA) part when calling the dh_ commands, because debhelper picks it up via DH_OPTIONS from the environment. Oh, much nicer, thank you. I'm using it now. :-) I'm going to wait some days to see if any experimental buildd's fail unexpectedly, but then I'll upload to unstable. Sounds good, thanks. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518673: libidn_1.12-2(hppa/experimental): FTBFS: java not available on hppa
+ Simon Josefsson (Fri, 17 Apr 2009 09:26:00 +0200): Before uploading to unstable, I also need to sort out the lib vs java section override for libidn11-java. And there seems to be an old build-dependency on autotools-dev in libidn which should probably be removed, it doesn't seem to do anything useful. I’m not sure about the section business, the best you can do is reply to the override email and ask ftpmaster what’s the correct section. Regarding autotools-dev, it is used by debian/rules and does useful stuff: cp -f /usr/share/misc/config.sub config.sub cp -f /usr/share/misc/config.guess config.guess You can read /usr/share/doc/autotools-dev/README.Debian.gz for some information. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#456133: qiv imlib
+ Bart Martens (Mon, 13 Apr 2009 11:20:05 +0200): At this point, the most recent upstream version of qiv still needs the old imlib. Where to go from here ? Possible options: 1. Barry is working with upstream to get qiv updated to no longer need the old imlib. Let's appreciate Barry's efforts by giving Barry some more time to finish this effort. 2. We could replace qiv by pqiv, which is a program that more or less behaves like qiv. 3. Removal from Debian, although popcon reveals that there are still quite some users. I suggest somebody packages pqiv, we let it migrate to testing, and then we remove imlib11 and qiv from testing once icewm has stopped using it. I don’t mind that we leave qiv around in unstable for users who may not be happy with pqiv, and to “wait and see” if upstream moves and ends up upgrading to imlib2. But if Squeeze comes and this has not happened, we should remove qiv from unstable as well I think. Bart, thanks for the pointer to pqiv: would you be up to packaging it? I’m a qiv user myself, and after compiling it here, it seems to fill the niche gracefully. If not, I’ll file a RFP. Thoughts on this plan? -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518673: libidn_1.12-2(hppa/experimental): FTBFS: java not available on hppa
+ Simon Josefsson (Fri, 17 Apr 2009 09:58:15 +0200): Regarding autotools-dev, it is used by debian/rules and does useful stuff: cp -f /usr/share/misc/config.sub config.sub cp -f /usr/share/misc/config.guess config.guess Those files will never be used during the build, upstream libidn uses these files from build-aux/ since many release ago. Then maybe they should be copied to build-aux? Or ensure they’re copied to the appropriate place. You can read /usr/share/doc/autotools-dev/README.Debian.gz for some information. I've read it, but I think it is based on old understanding of autoconf/automake/libtool. For example, it doesn't discuss autoconf 2.6x and libtool 2.x at all. The files shipped in the autotools-dev file are older than what libidn ships. So I think autotools-dev does more harm than good in this case. Hm, then it sounds like a bug in autotools-dev, rather than a motive to ditch it completely. Anyway, it’s your choice, and my job here is done. :-) Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524264: plasma-widgets-workspace: calendar widget eats all CPU
Hey, can you explain me where is Debian bugzilla or something? I mean, is there one? I subscribe my e-mail to kde list, but I don' t know where to report bugs, and send e-mail about a bug, etc.. Everytime I try to send an email to 524...@bugs.debian.org it fails... The Debian Bug Tracking System lives at http://bugs.debian.org. You are correct that your messages to 524...@bugs.debian.org have not arrived to the system (see http://bugs.debian.org/524264). You should give us the error to see what’s the problem; maybe you will have to contact the BTS administrators in order to solve it, but it’s difficult knowing without seeing the error you get. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518673: libidn_1.12-2(hppa/experimental): FTBFS: java not available on hppa
Hello, Right, I have made this change in the 1.14-2 upload. I ended up using: Build-Depends: debhelper (= 6), autotools-dev, gcj [!arm !hppa !hurd-i386], fastjar Because only arm, hppa, and hurd-i386 are official debian architectures that lack gcj packages in unstable. Okay. If you creates -java packages that are arch:any, in addition to debian/control, you must modify your debian/rules to handle gracefully being built on a system without gcj. The result should be that the libidn11-java is not built at all; you can do that with the -N switch of debhelper. You should be able to find example code. I didn't find any example code, but I worked out something that worked on local testing. I’ve looked at what you did. It indeed does the job, and that’s the basic idea to use, debhelper’s -N. A bit more idiomatic code is: | NO_JAVA_ARCHES := arm hppa hurd-i386 | DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) | | ifeq (,$(filter $(DEB_HOST_ARCH),$(NO_JAVA_ARCHES))) | ENABLE_JAVA := --enable-java | else | export DH_OPTIONS=-Nlibidn11-java | endif And then, you can lose all the $(DH_NO_JAVA) part when calling the dh_ commands, because debhelper picks it up via DH_OPTIONS from the environment. Anyway, your version worked, as you can see in: http://buildd.ayous.org/fetch.php?pkg=libidnver=1.14-2arch=hppastamp=1239910858file=logas=raw You can see in the resulting .changes file that the libidn11-java package was not built. P-a-s would be relevant here if libidn11-java was arch:any, and only because libidn provides some non-java packages. I didn't understand the purpose of that file -- is it still something that we should consider? If we can solve things in the local debian/ directory, that seems preferable to me. No, you don’t need P-a-s. I hope this mail cleared things for you. Yes thank you! Hopefully it will work better with this upload, but if it doesn't I hope you still have some patience to help me make it work. Sure. :-) Thanks for your work, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524120: transitions.yaml handling: the PTS needs to grok finished transitions
+ Stefano Zacchiroli (Wed, 15 Apr 2009 10:02:55 +0200): On Tue, Apr 14, 2009 at 11:56:51PM +0200, Adeodato Simó wrote: The way it works is that the Release Team specifies a target package/version combination that must migrate to testing, and all listed packages are blocked until that version or a later one migrates. When that happens, the block is automatically lifted, i.e. dak no longer rejects uploads. It’d be good if the PTS could gain support for doing the same. Hum, I wonder whether the PTS is the right place where to fix that. Ideally, my preferred solution would be a way, release manager side, that automatically cleans up the YAML file when transitions are done. This is not (only :-)) because it would you that do the work rather then us :-), but rather because I see the PTS as the consumer of the YAML file. There can be, theoretically, other consumers and basically you are implicitly proposing that all consumers implement the cleanup upon migration logics. If you have strong reasons for not implementing the cleanup your side, I have no objection fixing the PTS the way you proposed. Let me know. There is code in dak that can do the cleaning up, but it’s not triggered automatically, i.e., some release person has to run a command by hand. I perfectly get whan you mean, though I’m unsure what could be done about it: AFAIK, the file not being cleaned in a fully automated fashion is in case there could be any mistakes with the cleanup, plus it really can’t be cronned by anybody else than ftpmaster because the setup is done by handing sudo access to the command to members of the release team. Maybe it should be indeed automatically cleaned up. Let’s put this bug on hold until we can figure that out. Cc'ing -release and ftpmaster@ in case they have any comments. Thanks, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
