Bug#288202: Pornview hangs on close
On Tue, Jan 18, 2005 at 10:21:38AM +0100, Siggi Langauf wrote: > On Mon, 17 Jan 2005, Brian Nelson wrote: > > > Here's a backtrace with debugging symbols: > > > > Program received signal SIGINT, Interrupt. > > [Switching to Thread -1216928096 (LWP 19155)] > > 0xe410 in __kernel_vsyscall () > > (gdb) bt > [...] > > The debugging symbols are nice, but this thread alone doesn't look very > suspicious. > > Could you send me the output of "thread apply all bt", please? Here ya go: Thread 5 (Thread -1263666256 (LWP 28377)): #0 0xe410 in __kernel_vsyscall () #1 0xb7a9741e in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb7ae2ff8 in fifo_remove_int (fifo=0x8717bb8, blocking=1) at audio_out.c:337 #3 0xb7ae4114 in ao_loop (this_gen=0x86f3140) at audio_out.c:374 #4 0xb7a94ca3 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #5 0xb7a2c9ba in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 4 (Thread -1255003216 (LWP 28376)): #0 0xe410 in __kernel_vsyscall () #1 0xb7a23c5d in poll () from /lib/tls/i686/cmov/libc.so.6 #2 0xb53287b4 in ao_alsa_handle_event_thread (data=0x82ed188) at audio_alsa_out.c:156 #3 0xb7a94ca3 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb7a2c9ba in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 2 (Thread -1233708112 (LWP 28374)): #0 0xe410 in __kernel_vsyscall () #1 0xb7a975da in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb7ad449c in metronom_sync_loop (this=0x82beb60) at metronom.c:873 #3 0xb7a94ca3 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb7a2c9ba in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 1 (Thread -1216928096 (LWP 28359)): #0 0xe410 in __kernel_vsyscall () #1 0xb7a9741e in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb78de286 in _XUnregisterFilter () from /usr/X11R6/lib/libX11.so.6 #3 0xb78c192e in _XReply () from /usr/X11R6/lib/libX11.so.6 #4 0xb78bcda4 in XSync () from /usr/X11R6/lib/libX11.so.6 #5 0xb5f5b314 in xv_dispose (this_gen=0x82d5ca8) at video_out_xv.c:1051 #6 0xb7ae0c15 in vo_exit (this_gen=0x82d6e90) at video_out.c:1511 #7 0xb7ad9b29 in xine_close_video_driver (this=0x81ec4f8, vo_port=0xfffc) at load_plugins.c:1590 #8 0x08081893 in gtk_xine_unrealize (widget=0x81eb628) at gtkxine.c:634 #9 0xb7bd63b6 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #10 0xb7bc4949 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #11 0xb7bc46b6 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #12 0xb7bd5925 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #13 0xb7bd4f4c in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #14 0xb7bd51e6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #15 0xb7f19d93 in gtk_widget_unrealize () from /usr/lib/libgtk-x11-2.0.so.0 #16 0xb7f191d4 in gtk_widget_unparent () from /usr/lib/libgtk-x11-2.0.so.0 #17 0xb7d59c0c in gtk_bin_get_type () from /usr/lib/libgtk-x11-2.0.so.0 #18 0xb7bd6db3 in g_cclosure_marshal_VOID__OBJECT () from /usr/lib/libgobject-2.0.so.0 #19 0xb7bc4949 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #20 0xb7bc46b6 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #21 0xb7bd5721 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #22 0xb7bd4f4c in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #23 0xb7bd51e6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #24 0xb7d980f3 in gtk_container_remove () from /usr/lib/libgtk-x11-2.0.so.0 #25 0xb7f20fdc in gtk_widget_get_default_direction () from /usr/lib/libgtk-x11-2.0.so.0 #26 0xb7bc67f1 in g_object_run_dispose () from /usr/lib/libgobject-2.0.so.0 #27 0xb7e39cb9 in gtk_object_destroy () from /usr/lib/libgtk-x11-2.0.so.0 #28 0xb7f192e5 in gtk_widget_destroy () from /usr/lib/libgtk-x11-2.0.so.0 #29 0x080712ed in videoplay_destroy () at videoplay_xine.c:669 #30 0x08059aa0 in browser_destroy () at browser.c:335 #31 0xb7e1d0d4 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 #32 0xb7bc46b6 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #33 0xb7bd5ec8 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #34 0xb7bd4d3a in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #35 0xb7bd51e6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #36 0xb7f1bf67 in gtk_widget_send_expose () from /usr/lib/libgtk-x11-2.0.so.0 #37 0xb7e1a324 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #38 0xb7ccf1a5 in _gdk_events_queue () from /usr/lib/libgdk-x11-2.0.so.0 #39 0xb7b59632 in g_main_depth () from /usr/lib/libglib-2.0.so.0 #40 0xb7b5a6b8 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #41 0xb7b5a9f0 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #42 0xb7b5af93 in g_main_loop_run () from /usr
Bug#274514: Debian transition to Aspell 0.60
I've finally decided to put into motion a transition to Aspell 0.60 in Debian. Aspell 0.60 is a major release in terms of functionality but is a relatively minor change from a packaging perspective. In particular, the libaspell soname has not changed, so no software using the library will need to be rebuilt. This should be a relatively painless transition, so I do not believe it will pose a major problem to sarge. The one hurdle in the way is the binary format of the dictionaries has incompatibly changed again. Thus, the old dictionaries compiled with 0.50 will not work and must be rebuilt. To make this transition as painless as possible, I propose updating each dictionary as follows: * Change the build-depends to aspell-bin (>> 0.60) * Change the provides from aspell-dictionary to aspell6-dictionary. Since the new libaspell15 will no longer read the old dictionaries, it will conflict with "aspell-dictionary" while recommending "aspell6-dictionary". This will force any of the old dictionaries that provide aspell-dictionary to be removed. Also, any packages depending on aspell-dictionary will unfortunately have to be updated to use aspell6-dictionary instead. These packages are: abiword-common, sylpheed, sylpheed-claws, ekg, ekg2. You may find the new aspell packages available at: http://people.debian.org/~pyro/pending/ Please test building dictionaries with the new packages and let me know if you have any problems. Also, if you find any flaws in my proposal, please let me know. I'm going on a pseudo-vacation for the next two weeks and would really like to upload the new packages when I return. I'd appreciate it if someone would setup a staging area to collect all of the newly built dictionaries so that they can all be uploaded together. Please coordinate on the [EMAIL PROTECTED] mailing list, unless of course Agustin objects. ;) -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292479: ITP: kernel-patch-swsusp2 -- software suspend 2 for linux kernel patch
On Thu, Jan 27, 2005 at 10:20:05AM +0100, martin f krafft wrote: > Package: wnpp > Severity: wishlist > > @Bernard, I intend to package swsusp2 for Debian, just letting you > know... > > * Package name: kernel-patch-swsusp2 > Version : 2.1.5.15 > Upstream Author : Bernard Blackham <[EMAIL PROTECTED]> Isn't Nigel Cunningham the primary author? Also, Bernard is in the NM queue, though he's been on hold for quite a while... -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341658: libqt4-core: QBitArray operator{&,|,^}(...) missing from libQtCore.so
tag 341658 fixed-upstream thanks Torsten Marek <[EMAIL PROTECTED]> writes: > The functions > > QBitArray operator&(const QBitArray &, const QBitArray &); > QBitArray operator|(const QBitArray &, const QBitArray &); > QBitArray operator^(const QBitArray &, const QBitArray &); > > are missing from libQtCore.so. This is upstream bug scheduled to be fixed in 4.1.0: http://www.trolltech.com/developer/tasktracker.html?method=entry&id=83512 -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343060: libaspell15: aspell has to be targetted for C++ ABI transition
# Lowering the severity since I don't see this bug severity 343060 important thanks Akira TAGOH <[EMAIL PROTECTED]> writes: > There is no rebuild of aspell package after the reversion of > the mt allocator which was happened at 4.0.2-4. it causes > the strange crash when the applications/libraries which was > rebuilt against the newer libstdc++, uses libaspell15 which > was built against the old libstdc++, but has the same > soname. I'm not sure why they didn't change it and why the > rebuild package list was missing aspell though, when I input > something with scim on gaim, it crashes immediately, and > rebuilding aspell got it fixed. AIUI, there is no need for libaspell to be rebuilt for the mt allocator transition. That transition only affects certain C++ libraries, and although libaspell is written in C++, it only exports a C interface. Furthermore, I haven't had the problem you've described. Are you sure you've diagnosed the problem correctly? -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342658: libqt4-core: Locking Issue?
Ian Wienand <[EMAIL PROTECTED]> writes: [...] > (gdb) back > #0 0x21363d81 in __pthread_sigsuspend (set=0x6fbf7270) > at ../linuxthreads/sysdeps/unix/sysv/linux/ia64/pt-sigsuspend.c:32 > #1 0x21362380 in __pthread_wait_for_restart_signal > (self=0x2137edc8) at pthread.c:1216 > #2 0x2135d050 in __pthread_cond_wait (cond=0x60004338, > mutex=0x600042e0) at restart.h:34 > #3 0x2103f400 in QReadWriteLock::lockForWrite () from > /usr/lib/libQtCore.so.4 > #4 0x211d0340 in qt_addObject () from /usr/lib/libQtCore.so.4 > #5 0x211d0e50 in QObject::QObject () from /usr/lib/libQtCore.so.4 > #6 0x21184e20 in QFactoryLoader::QFactoryLoader () from > /usr/lib/libQtCore.so.4 > #7 0x2120b670 in QTextDecoder::~QTextDecoder () from > /usr/lib/libQtCore.so.4 > #8 0x21210ef0 in QTextCodec::codecForName () from > /usr/lib/libQtCore.so.4 > #9 0x2120c160 in QTextEncoder::fromUnicode () from > /usr/lib/libQtCore.so.4 > #10 0x2120efd0 in QTextCodec::codecForLocale () from > /usr/lib/libQtCore.so.4 > #11 0x210b30d0 in QString::toLocal8Bit () from /usr/lib/libQtCore.so.4 > #12 0x210e04b0 in locale_encode () from /usr/lib/libQtCore.so.4 > #13 0x210e06f0 in QFile::encodeName () from /usr/lib/libQtCore.so.4 > #14 0x210f8e20 in QFileEngineHandler::QFileEngineHandler () from > /usr/lib/libQtCore.so.4 > #15 0x210e5460 in QFile::open () from /usr/lib/libQtCore.so.4 > #16 0x40001070 in main () > > It seems that lock in qt_addObject has already been taken by > something. Has anything changed in this area recently? In the code? No, not by me. I don't see any reason why that lock would be taken indefinitely anyway. > BTW, using the libQtCore_debug.so.4 library didn't give me any useful > line numbers or other debugging info. If you load it into gdb and run > 'info functions' all the symbols are defined as non-debugging symbols. > This may have something to do with the way it was built. That's bug #341807. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343190: libqt4-dev: qmake adding unneeded libraries to the linker command line
Benjamin Mesing <[EMAIL PROTECTED]> writes: > to reduce dependencies between packages, it is suggested to add only > neccessary libraries as linker arguments. Steve Langasek explained the > problems in [1]. Now qmake pulls in loads of unneeded dependencies, > including e.g. libfreetype (-lfreetype). Any idea of how to fix it? -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343060: yes, need to rebuild
Peter Moulder <[EMAIL PROTECTED]> writes: > To reproduce a crash with the existing aspell build (0.60.4-1_i386): > > # apt-get install scim-pinyin > $ GTK_IM_MODULE=scim gedit > > On my machine at work, gedit crashes on startup, i.e. with just the above > procedure. On my home machine, the following addition is needed: > > Press Ctrl+Space > A short bar should appear at the bottom of the screen; > select Chinese (simplified) > Smart Pinyin. > Type `w'. Should crash at this point: > *** glibc detected *** free(): invalid pointer: 0x082d35d8 *** The backtrace for that crash on my machine looks like: (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0x4a3ad691 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0x4a3aef5b in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0x4a3e3bb7 in __libc_message () from /lib/tls/i686/cmov/libc.so.6 #4 0x4a3ea187 in _int_free () from /lib/tls/i686/cmov/libc.so.6 #5 0x4a3ea622 in free () from /lib/tls/i686/cmov/libc.so.6 #6 0x410e8dc1 in operator delete () from /usr/lib/libstdc++.so.6 #7 0xb7a47dea in scim::CommonLookupTable::~CommonLookupTable () from /usr/lib/libscim-1.0.so.8 #8 0xb7ad0b8f in scim::SocketInstance::do_transaction () from /usr/lib/scim-1.0/1.4.0/IMEngine/socket.so #9 0xb7ad4f56 in scim::SocketInstance::commit_transaction () from /usr/lib/scim-1.0/1.4.0/IMEngine/socket.so #10 0xb7ad5cff in scim::SocketInstance::process_key_event () from /usr/lib/scim-1.0/1.4.0/IMEngine/socket.so #11 0xb7aecfe3 in gtk_im_context_scim_new () from /usr/lib/gtk-2.0/2.4.0/immodules/im-scim.so #12 0x4abeb481 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #13 0x4add742a in _gdk_events_queue () from /usr/lib/libgdk-x11-2.0.so.0 #14 0x4a88f421 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #15 0x4a892687 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #16 0x4a892bd8 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #17 0x4abea629 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #18 0x080607c1 in main () I don't see how libaspell could be blamed... -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343739: qt4-dev-tools: menu item for assistant
Petr Mensik <[EMAIL PROTECTED]> writes: > Is there any reason why Qt Assistant does have any Menuitem in some > debian Xserver menus? In KDE menu i didnt found any of Qt Designer, Qt > Linguist, or Qt Assistant. That doest bother me much, as its under > Debian subtree. Still i think it might be there, because who else will > try using Qt language than KDE programmer? Plenty, I'd guess, including myself... > But maybe against debian policies, dunno. But what i look for is > Assistant menuitem somewhere. Its simple program, but its helpful > when you doing something with Qt. But i did not found other way of > starting assistant, than from commandline. I think some menuitem would > not do something bad, so why would not add Qt Assistant to help > section or applications/programming? Not everyone know he has > installed it when he cant find it in menu. Will it be there, or there > are reasons why its not already there? There is a menu entry for it, under Apps/Tools. This might not be the most logical place for it, but the Debian menu hierarchy is a total mess anyway. I don't think Apps/Programming is appropriate since you can't actually use it for programming, unlike the other stuff that appears under there. I'm open to other suggestions though. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337297: libqt4-dev: -lXxf86vm missing with qt3support for qmake
José Ramón Álvarez Sánchez <[EMAIL PROTECTED]> writes: > After trying to build a external program that uses libxxf86vm > and with a line QT += qt3support in the .pro file for qmake, > i got linking errors about symbols XF86VidModeQueryVersion and > XF86VidModeGetModeLine not defined. > > Just added "-lXxf86vm" to the line QMAKE_PRL_LIBS > in file /usr/lib/libQt3Support.prl and it worked OK, > although I am not sure if that is the best way it must be corrected > (or, is libxxf86vm not considered system library?) AFAIK, Qt4 doesn't have native support for Xxf86vm, so if you use it, you're responsible for modifying the build system of your application to link against it. For example, using qmake, you'd add something like this to your .pro: LIBS += -lXxf86vm Or am I misunderstanding this bug report? -- Captain Logic is not steering this tugboat.
Bug#337847: qt4-designer: I see nothing in the menu
jjluza <[EMAIL PROTECTED]> writes: > Le Dimanche 6 Novembre 2005 23:59, cedric a écrit : >> I had the same problem. but after restarting my computer, all works well. >> And I can't reproduce it. > > For my part, I still get the problem after restarting. Does removing ~/.designer and restarting fix it? -- Captain Logic is not steering this tugboat.
Bug#338380: qt4-designer: please provide a pure debug build of designer
Andreas Pakulat <[EMAIL PROTECTED]> writes: > today I was struck by designer and release vs. debug built of Qt4. I > have a Custom Widget which is visible in designer when I have no logic > in it. But it completely "breaks" designer if I put the real code in it, > the solution to this is that the widget uses a shared library. This > library is built in debug mode (the custom widget is built with release > mode) and that was the cause. Now I have to built the widget in release > mode, because Qt4 was built using release or the combined release+debug > building mode (in which case, designer gets built in release mode). > Designer can thus only load widgets which are built in the same mode as > designer itself and as you can see all libraries these widgets depend > upon need to use release built too. > > So the conclusion is: Please provide 2 designer packages, one using > release built and one using a debug-only built of Qt4. I know this means > building Qt4 twice for each update, but it's not possible to debug any > custom widget in the current setup due to the missing debug symbols. I'd rather wait and see what kind of improvements go into the designer in Qt4.1. The current version has proven to be very buggy, and this seems like something that should definitely be supported by a single designer binary. > The above might also explain some of the problems reported in 325782 > > If you feel this is more a wishlist than a minor bug, please downgrade, > but I thought as it breaks debug-building custom widgets its a minor > bug not a wishlist. I'd say it's a "normal" bug. Minor is more for spelling errors and stuff. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338976: pbuilder: pdebuild dies if /etc/shadow doesn't exist
Package: pbuilder Version: 0.138 Severity: normal For whatever reason, /etc/shadow doesn't exist in my chroot, and so when I run pdebuild, it dies: [...] + save_aptcache + local doit + '[' -n '' ']' + trap umountproc_cleanbuildplace exit + createbuilduser + '[' -n 'su -p root' ']' + grep -q '^root:' /home/nelson/pbuilder/build//10521/etc/passwd + grep -q '^root:' /home/nelson/pbuilder/build//10521/etc/group + grep -q '^root:' /home/nelson/pbuilder/build//10521/etc/shadow grep: /home/nelson/pbuilder/build//10521/etc/shadow: No such file or directory + cowprotect /home/nelson/pbuilder/build//10521/etc/shadow + for A in '"$@"' + readlink -f /home/nelson/pbuilder/build//10521/etc/shadow /home/nelson/pbuilder/build/10521/etc/shadow ++ readlink -f /home/nelson/pbuilder/build//10521/etc/shadow + A=/home/nelson/pbuilder/build/10521/etc/shadow + mv /home/nelson/pbuilder/build/10521/etc/shadow /home/nelson/pbuilder/build/10 521/etc/shadow~ mv: cannot stat `/home/nelson/pbuilder/build/10521/etc/shadow': No such file or directory + umountproc_cleanbuildplace + '[' 1 -ne 0 ']' + echo ' -> Aborting with an error' -> Aborting with an error [...] -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.14 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages pbuilder depends on: ii cdebootstrap 0.3.9 Bootstrap a Debian system ii coreutils 5.93-2 The GNU core utilities ii debianutils 2.15.1 Miscellaneous utilities specific t ii gcc 4:4.0.2-1 The GNU C compiler ii wget 1.10.2-1 retrieves files from the web Versions of packages pbuilder recommends: ii devscripts2.9.8 Scripts to make the life of a Debi ii fakeroot 1.5.5 Gives a fake root environment ii sudo 1.6.8p9-3 Provide limited super user privile -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345801: main window empty
[EMAIL PROTECTED] writes: > when I start the qt4 designer, I get the full workbench, everything > seems ok. But when starting a new form and choosing a "main window", > the created window is just empty. Regarding to the docs it should have > the usual decoration such as a menu bar. It should be possible to > create a missing menu bar through the context menu. > > But there is neither a menu bar, nor does the context menu allow > this. The other decorations are missing as well. > > Any idea? Does the new version, 4.1.0, which just hit unstable today, look better to you? -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345801: main window empty
Hadmut Danisch <[EMAIL PROTECTED]> writes: > On Thu, Jan 05, 2006 at 06:08:00PM -0500, Brian Nelson wrote: >> >> Does the new version, 4.1.0, which just hit unstable today, look better >> to you? > > > Yup, now there is a menu bar. > > But shouldn't there be a status bar at the bottom as well? There is--it's just empty. It appears in the .ui though. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342658: libqt4-core: Locking Issue?
Ian Wienand <[EMAIL PROTECTED]> writes: > On Mon, Dec 12, 2005 at 01:39:13PM +0200, Brian Nelson wrote: >> Ian Wienand <[EMAIL PROTECTED]> writes: >> >> [...] >> > (gdb) back >> > #0 0x21363d81 in __pthread_sigsuspend (set=0x6fbf7270) >> > at ../linuxthreads/sysdeps/unix/sysv/linux/ia64/pt-sigsuspend.c:32 >> > #1 0x21362380 in __pthread_wait_for_restart_signal >> > (self=0x2137edc8) at pthread.c:1216 >> > #2 0x2135d050 in __pthread_cond_wait (cond=0x60004338, >> > mutex=0x600042e0) at restart.h:34 >> > #3 0x2103f400 in QReadWriteLock::lockForWrite () from >> > /usr/lib/libQtCore.so.4 >> > #4 0x211d0340 in qt_addObject () from /usr/lib/libQtCore.so.4 >> > #5 0x211d0e50 in QObject::QObject () from /usr/lib/libQtCore.so.4 >> > #6 0x21184e20 in QFactoryLoader::QFactoryLoader () from >> > /usr/lib/libQtCore.so.4 >> > #7 0x2120b670 in QTextDecoder::~QTextDecoder () from >> > /usr/lib/libQtCore.so.4 >> > #8 0x21210ef0 in QTextCodec::codecForName () from >> > /usr/lib/libQtCore.so.4 >> > #9 0x2120c160 in QTextEncoder::fromUnicode () from >> > /usr/lib/libQtCore.so.4 >> > #10 0x2120efd0 in QTextCodec::codecForLocale () from >> > /usr/lib/libQtCore.so.4 >> > #11 0x210b30d0 in QString::toLocal8Bit () from >> > /usr/lib/libQtCore.so.4 >> > #12 0x210e04b0 in locale_encode () from /usr/lib/libQtCore.so.4 >> > #13 0x210e06f0 in QFile::encodeName () from /usr/lib/libQtCore.so.4 >> > #14 0x210f8e20 in QFileEngineHandler::QFileEngineHandler () from >> > /usr/lib/libQtCore.so.4 >> > #15 0x210e5460 in QFile::open () from /usr/lib/libQtCore.so.4 >> > #16 0x40001070 in main () >> > >> > It seems that lock in qt_addObject has already been taken by >> > something. Has anything changed in this area recently? >> >> In the code? No, not by me. I don't see any reason why that lock would >> be taken indefinitely anyway. > > I ruled out a few things, namely it seems to happen with both > LinuxThreads and NPTL, so it seems unlikely that the threading > library/kernel is at fault. > > The changes-4.0.1 file says that support has been added for SGI Altix, > which means someone must have been interested in getting it working on > IA64? Any idea who that person might be? No, no idea. Does this still happen with Qt 4.1.0? -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347191: aspell: Dumps core with when (r)eplacing with 00
Panu Kalliokoski <[EMAIL PROTECTED]> writes: > I'm using aspell with the finnish dictionary. > > When I run aspell on a file containing the three characters "OO\n" (that > is, big Oh, big Oh, newline, and use the (r)eplace functionality to > replace "OO" with "00" (zero, zero), aspell dumps core. What versions of aspell, libaspell15, and aspell-fi do you have installed? -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347251: libqt4-gui: Most icons don't load for some reason (and crash from time to time)
severity 347251 important thanks "Nach M. S." <[EMAIL PROTECTED]> writes: > Since the upgrade to Qt 4.1.0, I noticed icons pretty much everywhere > have disappeared. For example, load up Designer, aside from the Window > icon, icons everywhere else such as tool bar or for the item pains and > menus have all disappeared. Try removing libqt4-debug and see if the problem still occurs. If that fixes it, then it's due to some upstream problems with the build system and plugins loading. See, for example, #337764, #337847, #341807 ... > In my own apps I noticed the same thing, icons vanished everywhere but > from the Window icons. Also in my own apps, I've gotten this: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1220241728 (LWP 22025)] > 0xb7bb8893 in QImage::scanLine () from /usr/lib/libQtGui.so.4 Hmm, I haven't seen this before. I wonder if it's related, or if it's yet another bug... -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346586: libqt4-dev: linker error: /usr/lib/libQtSql.so: undefined reference to
Benjamin Mesing <[EMAIL PROTECTED]> writes: >> /usr/lib/libQtSql.so: undefined reference to [EMAIL PROTECTED]' >> /usr/lib/libQtSql.so: undefined reference to [EMAIL PROTECTED]' >> [...] > An update of libmysqlclient14(-dev) to version 4.1.15-1 solved the > issue. > So maybe libqt4-dev should depend on libmysqlclient14(-dev) >= 4.1.15-1? > > Btw. I have a wishlist bug to build against libmysqlclient15 instead of > 14, any chance you will switch over at one point? Couldn't find a > relevant wishlist bug for your packages. Yeah, I plan to do so for the next upload. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346605: libqt4-dev: linker error cannot find -lQt3Support_debug when compiling in debug mode
Benjamin Mesing <[EMAIL PROTECTED]> writes: > An update of libqt4-debug to 4.1 (which was still 4.0.1 before) fixed > this issue and brought it down to bug 346586. > So probably libqt4-dev 4.1 should conflict with libqt4-debug <= 4.0.1? Conflicts with earlier versions are frowned upon in policy (7.3). I think the right thing to do would be to split all of the _debug.so symlinks into a separate libqt4-debug-dev package. The current scheme of lumping them all into libqt4-dev and not explicitly depending on libqt4-debug is broken, I think. Then, if you're going to build and link against the debug libs, you just declare a build dependency on libqt4-debug-dev. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#335831: qt4-x11 4.1.0-1 still FTBFS in mips/mipsel
Isaac Clerencia <[EMAIL PROTECTED]> writes: > It looks like the problem still exists, I'm attaching a fixed qatomic32.s > created by Ryan Murray. Eh, did no one see this message? http://lists.debian.org/debian-mips/2006/01/msg00021.html -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347360: qt4-x11: FTBFS in ARM (no matching function for call to 'getXDefault(const char [4], const char [6], qreal*))
Isaac Clerencia <[EMAIL PROTECTED]> writes: > qt4 is FTBFS'ing in ARM with the following problem: > kernel/qapplication_x11.cpp: In function 'void > qt_init(QApplicationPrivate*, int, Display*, Qt::HANDLE, Qt::HANDLE)': > kernel/qapplication_x11.cpp:1547: error: no matching function for call > to 'getXDefault(const char [4], const char [6], qreal*)' > kernel/qapplication_x11.cpp:1174: note: candidates are: void > getXDefault(const char*, const char*, int*) > kernel/qapplication_x11.cpp:1185: note: void > getXDefault(const char*, const char*, double*) > kernel/qapplication_x11.cpp:1196: note: void > getXDefault(const char*, const char*, bool*) > kernel/qapplication_x11.cpp: At global scope: > kernel/qapplication_x11.cpp:1185: warning: 'void getXDefault(const > char*, const char*, double*)' defined but not used > > the problem is that in ARM qreal is defined as float and not as double, Do you know if there's a good reason for this? > I guess the easiest fix would be to add another implementation of > getXDefault with prototype: void getXDefault(const char*, const char*, > float*) similar to the double one in kernel/qapplication_x11.cpp. I already applied a different fix in svn--I changed the qreal declaration to double instead of float, which is how it was declared before 4.1.0. If you think this will be problematic for some reason, let me know. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347581: debian-policy: Explicitly permit *-headers binary package created from library source package
"Kevin B. McCarty" <[EMAIL PROTECTED]> writes: > Could Policy be amended slightly to explicitly permit library source > packages to create a -headers package containing include files? > > I am thinking that something like the following could be added between > the existing first and second paragraphs of Section 8.4, "Development > files", > http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-dev > > [begin suggested text] > If your library source package includes a large number of header files > that are to be installed in /usr/include or subdirectories thereof, it > may place them in a binary package called librarynamesoversion-headers > or (if you prefer only to support one development version at a time, or > if the library API is preserved across different soversions) > libraryname-headers. If you do this, the development package must > Depend upon the headers package. If the development package is > architecture-dependent and the headers package is not, the development > package should not require exactly the same version of the headers > package in order to prevent problems arising from binary NMUs. > [end suggested text] > > Without this or a similar text, it is not clear to me that source > packages creating -headers binary packages are in compliance > with Policy, which currently says "The development files associated to a > shared library need to be placed in a package called > librarynamesoversion-dev, or if you prefer only to support one > development version at a time, libraryname-dev." It's not clear to me that splitting out the headers is actually a good thing (it's very annoying for autobuilders since the corresponding -dev package won't be installable until the new version has been autobuilt), so I certainly don't think policy should endorse it. > CC'ed to debian-devel in case anyone wants to add to or disagree with > this suggestion. Uh, no it's not. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347581: debian-policy: Explicitly permit *-headers binary package created from library source package
"Kevin B. McCarty" <[EMAIL PROTECTED]> writes: > Brian Nelson wrote: > >> It's not clear to me that splitting out the headers is actually a good >> thing (it's very annoying for autobuilders since the corresponding -dev >> package won't be installable until the new version has been autobuilt), >> so I certainly don't think policy should endorse it. > > It wouldn't be an endorsement, just a permission. It seems to me that > policy currently prohibits -headers packages for shared libraries by > saying that development files must be in the -dev package. Do you feel > -headers packages _should_ be explicitly prohibited? Sure, I don't see any advantage to having them. > My main motive in making the suggestion is that when the headers are > architecture-independent and there are a lot of them, splitting them out > into a separate arch:all package can save a lot of archive space. (I > don't know what the motive was of the developers who created packages > like libqt3-headers, which are arch:any.) Get:1 http://rubeus sid/main libqt3-headers 3:3.3.5-3 [364kB] Fetched 364kB in 1s (226kB/s) I wouldn't call 364kB a lot of saved archive space, and you'd be hard-pressed to find a package with more headers than Qt. >> "Kevin B. McCarty" <[EMAIL PROTECTED]> writes: >>>CC'ed to debian-devel in case anyone wants to add to or disagree with >>>this suggestion. >> >> Uh, no it's not. > > For "CC'ed" read "X-Debbugs-CC'ed". The web archive of the mailing list > hasn't been updated since early this morning (as of this writing), but > you can see my email in the gated newsgroup, for instance on Google > Groups, http://groups.google.com/group/linux.debian.devel . > If it isn't showing up to debian-devel email subscribers, something > strange is going on (I read the list through the web archive so I don't > know whether or not this is the case). Oh, I guess the mail I replied to hadn't been processed by the submit bot then. My mistake. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347782: Add sqlite support to Qt-4.1.0
Thorvald Natvig <[EMAIL PROTECTED]> writes: > Could you add sqlite3 support to Qt? The source is included in the Qt > distribution, so it's just a matter of adding -qt-sql-sqlite to the > configure string. Already added to 4.1.0-2, which is currently sitting in the NEW queue and should become available shortly. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347191: aspell: Dumps core with when (r)eplacing with 00
tag 347191 upstream forwarded 347191 http://sourceforge.net/tracker/index.php?func=detail&aid=1405037&group_id=245&atid=100245 thanks Panu Kalliokoski <[EMAIL PROTECTED]> writes: > On Mon, Jan 09, 2006 at 09:31:45AM -0800, Brian Nelson wrote: >> What versions of aspell, libaspell15, and aspell-fi do you have >> installed? > > $ dpkg -l aspell-bin libaspell15 aspell-fi > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed > |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: > uppercase=bad) > ||/ NameVersion Description > +++-===-===-== > ii aspell-bin 0.60.2+20050121-2 GNU Aspell standalone spell-check > utilities > ii libaspell15 0.60.2+20050121-2 The GNU Aspell spell-checker > runtime toolkits > ii aspell-fi 0.7-14.1The Finnish dictionary for aspell I was able to reproduce this on current aspell packages in unstable as well, so I forwarded it upstream. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347589: aspell: doesn't handle \% correctly for .tex files
tag 347589 upstream forwarded 347589 http://sourceforge.net/tracker/index.php?func=detail&aid=1405044&group_id=245&atid=100245 thanks Matthew Roberts <[EMAIL PROTECTED]> writes: > When spell checking a .tex file, aspell assumes any '%' character will > result in a comment on the remainder of the line and ignores remaining > words. However, a '\%' sequence denotes that a percent sign should be > printed, and spell checking should continue on the rest of the line. > > The following line will not generate a mistake in aspell: > > More than 60\% of the students feilled the exam. I was able to reproduce this on 0.60.4 as well, so I forwarded it upstream to http://sourceforge.net/tracker/index.php?func=detail&aid=1405044&group_id=245&atid=100245. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345388: libqt4-dev: qmake adds -L/usr/lib
Marc Glisse <[EMAIL PROTECTED]> writes: > qmake adds -L/usr/lib to (the beginning of) LIBS. This is unneeded, and > actually causes many problems. I agree it's unneeded, but what problems does it cause? -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#336492: libqt4-gui: conflicts with libqt4-core 4.0.1-2
Jean-Christophe Dubacq <[EMAIL PROTECTED]> writes: > When upgrading from 4.0.1-2 to 4.0.1-4, libqt4-gui tries to overwrite > libqjpeg.so: > dpkg: error processing > /var/cache/apt/archives/libqt4-gui_4.0.1-4_i386.deb (--unpack): > trying to overwrite `/usr/lib/qt4/plugins/imageformats/libqjpeg.so', which > is also in package libqt4-core > dpkg-deb: subprocess paste killed by signal (Broken pipe) > > The answer is simple: It should have some more headers: > Replaces: libqt4-core (<<4.0.1-4) > Conflicts: libqt4-core (<<4.0.1-4) Thanks. It should just replace libqt4-core though, and not conflict with it. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#339357: libqt4-dev: QMenu::exec() returns wrong value
Artur Wiebe <[EMAIL PROTECTED]> writes: > When opening a popup menu with QMenu::exec() and clicking left outside > of the menu exec() returns not 0 as I would expect it. If this is not a > bug, sry for wasting your time. It does sound like a bug. Did you search the bug reports on http://www.trolltech.com/developer/tasktracker.html for anything relevant? I just looked but couldn't find anything. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337764: libqt4-debug: Building apps in debug mode breaks image loading
Andreas Pakulat <[EMAIL PROTECTED]> writes: > Building QT4 apps using > > CONFIG += debug > > breaks the loading of any icons in the application. Remove debug and > everythings fine. This not only happens to the icons created for that > app, but also for the icons in standard dialog, like the QFileDialog. Hmm, I can't reproduce this. Can you test some of the examples from Qt and see if you can reproduce it with any of those. The stuff under mainwindows/ seem like good candidates. You can find the examples in the Qt source, or in the new qt4-doc package I'm about to upload (4.0.1-5). -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337764: libqt4-debug: Building apps in debug mode breaks image loading
tag 337764 confirmed thanks Andreas Pakulat <[EMAIL PROTECTED]> writes: > On 18.11.05 10:20:54, Brian Nelson wrote: >> Andreas Pakulat <[EMAIL PROTECTED]> writes: >> >> > Building QT4 apps using >> > >> > CONFIG += debug >> > >> > breaks the loading of any icons in the application. Remove debug and >> > everythings fine. This not only happens to the icons created for that >> > app, but also for the icons in standard dialog, like the QFileDialog. >> >> Hmm, I can't reproduce this. Can you test some of the examples from Qt >> and see if you can reproduce it with any of those. The stuff under >> mainwindows/ seem like good candidates. > > Sure, just take the "application" example, add > > CONFIG += debug > > and run qmake-qt4 && make. The program won't display any icon, except the > one for paste. This is with an up to date sid and I'm having Qt3 as > default Qt (i.e. qmake == qmake-qt3). > > QTDIR is set to point to /usr/share/qt3, but changing to /usr/share/qt4 > doesn't help either. OK, I see it now. Strange I couldn't reproduce it the first time I tried. I wonder if this is a consequence of this bug: http://www.trolltech.com/developer/tasktracker.html?method=entry&id=86441 Examining the strace, it does look like it's loading both the debug and non-debug versions of the plugins. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327359: qmake generates invalid -L linker Option
tag 327359 upstream thanks This actual bug is filed as http://www.trolltech.com/developer/tasktracker.html?method=entry&id=87775 upstream, scheduled to be fixed in 4.1.1. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#339357: libqt4-dev: a simple test
Artur Wiebe <[EMAIL PROTECTED]> writes:
> No, I could not find anything. I've just played around with this: A
> QTreeWidget with setContextMenuPolicy(Qt::CustomContextMenu) and the signal
> customContextMenuRequested(const QPoint&) connected to a my_slot(const
> QPoint&) which looks like
>
> void myView::my_slot(const QPoint& pos)
> {
> QMenu popup(this);
>
> popup.addAction("test 1");
> popup.addAction("test 2");
> popup.addAction("test 3");
>
> //QAction* retval = popup.exec(m_tw->mapToGlobal(pos));
> QAction* retval = popup.exec(QCursor::pos());
> qDebug() << retval;
> }
>
> This works. The commented out version does not. It opens a popup but
> clicking left outside the menu returns not 0.
Well, I just looked over the QMenu code to try to see what could be
happening here, but nothing obvious stood out.
Would you like to file a bug upstream and see if the trolls can figure
it out?
--
Captain Logic is not steering this tugboat.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340754: aspell-he: Incorrect "contents" file created
Package: aspell-he Version: 0.9+0-3 Severity: normal In your debian/rules, there's a line: echo he >> $(BASEDIR)/usr/share/aspell/he/.contents that should instead be: echo he >> $(BASEDIR)/usr/share/aspell/he.contents This is probably my fault, since I think the original explanation I wrote for creating auto-hash-building dictionaries contained the same typo. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.14 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340755: aspell-fi: Provides wrong aspell dictionary type
Package: aspell-fi Version: 0.7-16 Severity: serious The aspell-fi package should provide "aspell6a-dictionary", and not "aspell-dictionary". The reason for this is that the "aspell-dictionary" virtual package is reserved for dictionaries that use the aspell-autobuildhash system and are thus independent of the dictionary format. This package, on the other hand, builds the hash at package build time and includes it in the .deb. The next time the aspell dictionary format changes, this package will need to be rebuilt. Aspell ensures the installed dictionaries have the correct format by conflicting with incompatible formats, and it relies on the provides relationship to do this. So, to be clear: aspell-dictionary: uses aspell-autobuildhash, Arch: all, independent of aspell version aspell6a-dictionary: packages dictionary hash in the .deb, Arch: any, depends on specific aspell versions due to dictionary format changes. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.14 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340756: aspell-no: Incorrect arch, provides wrong aspell dictionary type
Package: aspell-no Version: 2.0-22 Severity: serious The aspell-no package should provide "aspell6a-dictionary", not "aspell-dictionary". The reason for this is that the "aspell-dictionary" virtual package is reserved for dictionaries that use the aspell-autobuildhash system and are thus independent of the dictionary format. This package, on the other hand, builds the hash at package build time and includes it in the .deb. The next time the aspell dictionary format changes, this package will need to be rebuilt. Aspell ensures the installed dictionaries have the correct format by conflicting with incompatible formats, and it relies on the provides relationship to do this. Also, since the dictionary hashes are affected by endianess, this package should be Arch: any, not Arch: all. Otherwise it won't work properly on arches that have a different endianess from the system on which you built it. So, to be clear: aspell-dictionary: uses aspell-autobuildhash, Arch: all, independent of aspell version aspell6a-dictionary: packages dictionary hash in the .deb, Arch: any, depends on specific aspell versions due to dictionary format changes. Note that packaging dictionaries using the aspell-autobuildhash system is strongly preferred, but the quick fix for this package is to just change the Arch: and Provides: control fields. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.14 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#312381: kbiff: imap4s support is buggy and leaky
Package: kbiff Version: 3.7.1-3.1 Severity: important Using imap4s mailboxes with kbiff leaks gobs of memory (hundreds of megs after a few hours), whereas regular imap4 works fine. Here are some of my relevant settings: [Inbox] Docked=true DontCheck=false Mailboxes=imap4s://[EMAIL PROTECTED]:993/INBOX?keepalive=yes&async=no&timeout=10,[...] Notify=false Poll=15 RunCommand=false ... And here's a snippet of some "valgrind --error-limit=no --num-callers=50 --leak-check=yes" output: ==30501== Conditional jump or move depends on uninitialised value(s) ==30501==at 0x1B9566B5: KBiffSocket::setSSL(bool) (in /usr/lib/kbiff.so) ==30501==by 0x1B9525D5: KBiffMonitor::setMailbox(KBiffURL&) (in /usr/lib/kbi ff.so) ==30501==by 0x1B94B511: KBiff::setMailboxList(QPtrList const&, unsigned) (in /usr/lib/kbiff.so) ==30501==by 0x1B94B1AD: KBiff::processSetup(KBiffSetup const*, bool) (in /us r/lib/kbiff.so) ==30501==by 0x1B94F210: main (in /usr/lib/kbiff.so) kdecore (KLibLoader): WARNING: KLibrary: /usr/lib/libkdecore.so.4: undefined sym bol: PKCS7_content_free kdecore (KLibLoader): WARNING: KLibrary: /usr/lib/libkdecore.so.4: undefined sym bol: OpenSSL_add_all_algorithms kdecore (KLibLoader): WARNING: KLibrary: /usr/lib/libkdecore.so.4: undefined sym bol: OpenSSL_add_all_algorithms_conf kdecore (KLibLoader): WARNING: KLibrary: /usr/lib/libkdecore.so.4: undefined sym bol: OpenSSL_add_all_algorithms_noconf ==30501== ==30501== Conditional jump or move depends on uninitialised value(s) ==30501==at 0x1DB31923: RSA_padding_add_PKCS1_type_2 (in /usr/lib/libcrypto. so.0.9.7) ==30501== ==30501== Conditional jump or move depends on uninitialised value(s) ==30501==at 0x1DB1D9D6: BN_ucmp (in /usr/lib/libcrypto.so.0.9.7) ==30501== ==30501== Conditional jump or move depends on uninitialised value(s) ==30501==at 0x1DB2E4C0: (within /usr/lib/libcrypto.so.0.9.7) ==30501== ==30501== Conditional jump or move depends on uninitialised value(s) ==30501==at 0x1DB1D9D6: BN_ucmp (in /usr/lib/libcrypto.so.0.9.7) ==30501==by 0x1F: ??? ==30501== ==30501== Conditional jump or move depends on uninitialised value(s) ==30501==at 0x1DB1DC95: bn_cmp_words (in /usr/lib/libcrypto.so.0.9.7) ==30501== ==30501== Conditional jump or move depends on uninitialised value(s) ==30501==at 0x1DB1E292: bn_mul_recursive (in /usr/lib/libcrypto.so.0.9.7) ==30501== ==30501== Use of uninitialised value of size 4 ==30501==at 0x1DB1E29A: bn_mul_recursive (in /usr/lib/libcrypto.so.0.9.7) ==30501== ==30501== Conditional jump or move depends on uninitialised value(s) ==30501==at 0x1DB249DE: bn_sub_words (in /usr/lib/libcrypto.so.0.9.7) [... ad nauseam ...] ==30501== ERROR SUMMARY: 953092 errors from 321 contexts (suppressed: 13328 from 9) ==30501== malloc/free: in use at exit: 805151 bytes in 31615 blocks. ==30501== malloc/free: 351337 allocs, 319722 frees, 21381458 bytes allocated. ==30501== For counts of detected errors, rerun with: -v ==30501== searching for pointers to 31615 not-freed blocks. ==30501== checked 1986384 bytes. [...] ==30501== 129589 (780 direct, 128809 indirect) bytes in 39 blocks are definitely lost in loss record 135 of 275 ==30501==at 0x1B90459D: malloc (vg_replace_malloc.c:130) ==30501==by 0x1DAFA97E: (within /usr/lib/libcrypto.so.0.9.7) [...] ==30501== LEAK SUMMARY: ==30501==definitely lost: 1597 bytes in 71 blocks. ==30501==indirectly lost: 130864 bytes in 4644 blocks. ==30501== possibly lost: 140 bytes in 1 blocks. ==30501==still reachable: 672550 bytes in 26899 blocks. ==30501== suppressed: 0 bytes in 0 blocks. ==30501== Reachable blocks (those to which a pointer was found) are not shown. ==30501== To see them, rerun with: --show-reachable=yes -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11.10 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages kbiff depends on: ii kdelibs44:3.3.2-6.1 KDE core libraries ii libart-2.0-22.3.17-1 Library of functions for 2D graphi ii libaudio2 1.7-2The Network Audio System (NAS). (s ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libfam0c102 2.7.0-7 client library to control the FAM ii libfontconfig1 2.3.2-1 generic font configuration library ii libfreetype62.1.7-2.4FreeType 2 font engine, shared lib ii libgcc1 1:3.4.3-13 GCC support library ii libice6 4.3.0.dfsg.1-14 Inter-Client Exchange library ii libidn110.5.13-1.0 GNU libidn library, implementation ii libpng12-0 1.2.8rel-1 PNG library - runtime ii libqt3c102-mt 4:3.3.4+catchmedia-2 Qt GUI Library (Threaded runtime v ii libsm6
Bug#313490: Missing gcc and g++ symlinks in /usr/lib/ccache
Package: ccache Version: 2.4-1 Severity: normal $ debdiff ccache_2.3-1.1_i386.changes ccache_2.4-1_i386.changes Files in second .changes but not in first - /usr/lib/ccache/g++-3.4 /usr/lib/ccache/g++-4.0 /usr/lib/ccache/gcc-3.4 /usr/lib/ccache/gcc-4.0 /usr/lib/ccache/i486-linux-gnu-g++-2.95 /usr/lib/ccache/i486-linux-gnu-g++-3.0 /usr/lib/ccache/i486-linux-gnu-g++-3.4 /usr/lib/ccache/i486-linux-gnu-g++-4.0 /usr/lib/ccache/i486-linux-gnu-gcc-2.95 /usr/lib/ccache/i486-linux-gnu-gcc-3.0 /usr/lib/ccache/i486-linux-gnu-gcc-3.4 /usr/lib/ccache/i486-linux-gnu-gcc-4.0 Files in first .changes but not in second - /usr/lib/ccache/g++ /usr/lib/ccache/gcc [...] -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11.3 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages ccache depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310590: aspell dictionaries depend on libaspell15 package name, that might change
On Tue, May 24, 2005 at 11:30:05PM +0200, Agustin Martin wrote: > On Tue, May 24, 2005 at 03:13:41PM +0200, Matthias Klose wrote: > > Package: aspell > > > > Many aspell dictionaries depend on the libaspell15 package. with the > > next soversion (or the coming C++ ABI change), the package name has to > > be changed, as well as other 24 dictionary packages. That's just a > > maintainance burden. Package dictionaries may depend on aspell (>= > > 0.60) instead, but you may argue, that the aspell binary isn't > > necessarily needed. Proposing: > > > > - a new libaspell package, which depends on the current libaspell15 > > package (a provides is not enough, because dictionaries have to > > depend on an version, and versioned provides don't yet exist) > > > > - alternatively dictionary packages should depend on aspell. > > > > - a short paragraph in README.Debian as a mini policy. > > Just to note that after Brian suggestion, one of the things that are waiting > in dictionaries-common for sarge release is aspell-autobuidhash, allowing the > binary hashes being built from dict postinst. This is still very > experimental, and would require for dicts using it that not only libaspellxx > is installed but also aspell-bin, but should make dependencies simpler for > those dicts, since the dependency would be on aspell-bin, which is synced to > the appropriate libaspellxx because it depends on it. Yeah, what he said. Couple questions: Matthias: How soon will the C++ ABI transition start? Or, in other words, how long do we have to implement the autobuildhash for all of the dictionaries before the libaspell name will have to change? Agustin: What's the status of aspell-autobuildhash? I'd like to start seriously testing it very soon, within the next couple of weeks, so that we can start transitioning the dictionary packages as soon as sarge releases. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#261196: apt-proxy patch for HTTP Basic authorization support
Here's a quick hack to support HTTP Basic authorization in apt-proxy
that works for me.
Disclaimer: I have no familiarity with Twisted and only glanced at RFC
2617 before implementing this, so I'm overly confident this patch is
correct...
--
Society is never going to make any progress until we all learn to
pretend to like each other.
--- apt-proxy-1.9.30.old/apt_proxy/apt_proxy.py 2005-05-19 09:41:18.0
-0700
+++ apt-proxy-1.9.30/apt_proxy/apt_proxy.py 2005-06-01 14:38:07.0
-0700
@@ -29,6 +29,7 @@
from twisted.python.failure import Failure
import memleak
from twisted.internet import error
+import base64
#from posixfile import SEEK_SET, SEEK_CUR, SEEK_END
#since posixfile is considered obsolete I'll define the SEEK_* constants
#myself.
@@ -586,6 +587,11 @@
self.sendHeader('host', self.request.backendServer.host)
+if self.request.backendServer.username:
+self.sendHeader('authorization', "Basic "
++
base64.encodestring(self.request.backendServer.username + ":"
+ +
self.request.backendServer.password))
+
if self.local_mtime != None:
datetime = http.datetimeToString(self.local_mtime)
self.sendHeader('if-modified-since', datetime)
Bug#232341: Still not added
Michael Graham <[EMAIL PROTECTED]> writes: > Is there any movement on this bug as I have just noticed that proven is > not in the aspell dictionary? It's there, but for some reason it's in the en-variant_1 and en-variant_2 lists. See /usr/share/doc/aspell-en/README.gz for info on how to use the variant lists. I don't know why it's considered a variant and what word it would be a variant of, which is why I've left this bug report open. Some day I'll get around to doing something about it... -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306448: pbuilder: Support for preserving environment PATH
Package: pbuilder
Version: 0.127.1
Severity: wishlist
Here's a simple patch that adds a --preserve-envpath to pbuilder which
prevents the PATH from being clobbered.
diff -urN pbuilder-0.127/debian/changelog pbuilder-0.127.1/debian/changelog
--- pbuilder-0.127/debian/changelog 2005-04-21 15:38:16.0 -0700
+++ pbuilder-0.127.1/debian/changelog 2005-04-25 23:24:55.0 -0700
@@ -1,3 +1,9 @@
+pbuilder (0.127.1) unstable; urgency=low
+
+ * Patched to support a --preserve-envpath option
+
+ -- Brian Nelson <[EMAIL PROTECTED]> Mon, 25 Apr 2005 23:24:11 -0700
+
pbuilder (0.127) unstable; urgency=low
* pdebuild.1, pdebuild-user-mode-linux.1: --debsign-k requires key-id.
diff -urN pbuilder-0.127/pbuilder-buildpackage pbuilder-0.127.1/pbuilder-buildpackage
--- pbuilder-0.127/pbuilder-buildpackage 2005-04-21 15:36:41.0 -0700
+++ pbuilder-0.127.1/pbuilder-buildpackage 2005-04-25 23:24:53.0 -0700
@@ -87,7 +87,9 @@
fi
echo " -> Building the package"
-export PATH="/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin"
+if [ "$PRESERVE_ENVPATH" != "yes" ]; then
+export PATH="/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin"
+fi
executehooks "A"
diff -urN pbuilder-0.127/pbuilder-checkparams pbuilder-0.127.1/pbuilder-checkparams
--- pbuilder-0.127/pbuilder-checkparams 2005-04-15 21:14:48.0 -0700
+++ pbuilder-0.127.1/pbuilder-checkparams 2005-04-25 23:24:53.0 -0700
@@ -169,6 +169,10 @@
PRESERVE_BUILDPLACE="yes"
shift;
;;
+ --preserve-envpath)
+ PRESERVE_ENVPATH="yes"
+ shift;
+ ;;
--bindmounts)
BINDMOUNTS="${BINDMOUNTS} $2"
shift; shift;
I need this in order to make use of ccache inside the pbuilder chroot
for certain build systems (like qmake) which don't honor variables like
CC and CXX. To work around these broken systems, I add /usr/lib/ccache
to the PATH.
If there's a way to accomplish this without the patch (e.g. through
hooks), let me know. I wasn't able to figure out any other way...
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-ac12
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages pbuilder depends on:
ii coreutils 5.2.1-2The GNU core utilities
ii debianutils 2.13.2 Miscellaneous utilities specific t
ii debootstrap 0.2.45-0.2 Bootstrap a basic Debian system
ii gcc 4:3.3.5-3 The GNU C compiler
ii wget 1.9.1-10 retrieves files from the web
-- no debconf information
Bug#308842: libaspell-dev: missing new_aspell_speller symbol
On Fri, May 13, 2005 at 03:35:33AM +1000, Andrew Lau wrote: > configure:22891: checking for new_aspell_speller in -laspell > configure:22921: gcc -o conftest -g -O2 conftest.c -laspell -lstdc++ > -lesmtp -lpthread -lesmtp >&5 > /usr/bin/ld: cannot find -lstdc++ > collect2: ld returned 1 exit status > configure:22927: $? = 1 That's no missing symbol in libaspell; that's a failure to link against libstdc++. It's probably a gcc-3.4 problem since it works fine with gcc-3.3. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#288202: Is there still someting going on about this issue?
On Tue, May 03, 2005 at 08:43:58PM +0200, Roel van der Made wrote: > I still have the same probs nog being able to close pornview nicely > after viewing my favorite image-collections :) > > If you need some more info about my system tell me, would be nice if > this could be resolved.. Nope, I can reproduce it myself. I just don't know how to fix it... -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306694: ITP: qt-x11-opensource -- Qt 4 cross-platform C++ application framework
On Mon, May 02, 2005 at 11:23:04PM +0200, Adeodato Simó wrote: > * Brian Nelson [Wed, 27 Apr 2005 19:09:01 -0700]: [...] > > I plan to maintain the packaging in a distributed version control > > system, once I figure out which of the 20 or so is the most practical. > > OK. If you finally choose Subversion, you may want to use the existing > repository for the Alioth pkg-kde project. But please feel free to use > whichever you prefer. I'm already using a local subversion repository, so I'd be comfortable with that. It's not the best for distributed development, but if it's already in use for the KDE packages, it would probably make the most sense to stick with it. > We will be glad to cooperate more closely. Thanks & good luck, > > > P.S.: Will you change the name of the source package to qt4-x11? Yep, that's the plan. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306694: ITP: qt-x11-opensource -- Qt 4 cross-platform C++ application framework
Package: wnpp Severity: wishlist * Package name: qt-x11-opensource Version : 4.0 beta 2 Upstream Author : Trolltech AS * URL or Web page : http://www.trolltech.com * License : Dual GPL/QPL Description : Qt 4 cross-platform C++ application framework Qt is a cross-platform C++ application framework. Qt's primary feature is its rich set of widgets that provide standard GUI functionality. Qt 4 is the next major revision of Qt, currently planned for a late Q2 release. Preliminary packaging is available here: http://people.debian.org/~pyro/experimental/ I would like to group-maintain this package and have set the maintainer to "Debian Qt/KDE Maintainers " in the preliminary packages. Please let me know if this is inappropriate for whatever reason. I plan to maintain the packaging in a distributed version control system, once I figure out which of the 20 or so is the most practical. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306694: ITP: qt-x11-opensource -- Qt 4 cross-platform C++ application framework
On Wed, Apr 27, 2005 at 11:10:44PM -0500, Peter Samuelson wrote: > > [Brian Nelson] > > * Package name: qt-x11-opensource > > Version : 4.0 beta 2 > > Upstream Author : Trolltech AS > > Is there some reason for the "-opensource" in the name? It's the upstream name. For whatever reason, Trolltech has chosen different names for each major release: Qt1: qt Qt2: qt-x11 Qt3: qt-x11-free Qt4: qt-x11-opensource Qt5 will probably be qt-x11-foss or qt-x11-freeasinspeech or something equally annoying. > That's a pretty redundant designation for something in Debian main, > don't you think? I'd probably go with "qt4" or "libqt4" or "qt4-x11" > for the source package name. I was thinking about naming it qt4-x11, but I'm not sure it's worth deviating from upstream. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306694: ITP: qt-x11-opensource -- Qt 4 cross-platform C++ application framework
On Wed, Apr 27, 2005 at 10:38:57PM -0400, Josh Metzler wrote: > On Wednesday 27 April 2005 10:09 pm, Brian Nelson wrote: > > I would like to group-maintain this package and have set the maintainer > > to "Debian Qt/KDE Maintainers " in the > > preliminary packages. Please let me know if this is inappropriate for > > whatever reason. > > I had assumed that Martin Loschwitz would maintain QT4 packages, since he is > the maintainer of the QT3 packages. As far as I know, he has never > publicly stated such an intention, but it seems to me that you should at > least ask him about it. I CC'd [EMAIL PROTECTED] which I presume he reads. He's certainly welcome to help co-maintain it. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306879: qt-x11-free: Alternatives to support coexistence with Qt 4
Package: qt-x11-free Severity: wishlist Tags: patch Here's a patch to add support for using alternatives for all of the executables shared with Qt 4. Note that it's not 100% complete, since some of the supplied manpages need to be renamed... >From my preliminary testing, it appears Qt 3/4 coexist happily with this patch if QTDIR is set properly... diff -urN qt-x11-free-3.3.4.old/debian/qt3-assistant.postinst qt-x11-free-3.3.4/debian/qt3-assistant.postinst --- qt-x11-free-3.3.4.old/debian/qt3-assistant.postinst 1969-12-31 16:00:00.0 -0800 +++ qt-x11-free-3.3.4/debian/qt3-assistant.postinst 2005-04-28 16:07:21.669727309 -0700 @@ -0,0 +1,10 @@ +#!/bin/sh + +set -e + +update-alternatives --install \ + /usr/bin/assistant-qt3 assistant "/usr/bin/assistant-qt3" "35" \ + --slave /usr/share/man/man1/assistant.1.gz assistant.1.gz \ + "/usr/share/man/man1/assistant-qt3.1.gz" + +#DEBHELPER# diff -urN qt-x11-free-3.3.4.old/debian/qt3-assistant.prerm qt-x11-free-3.3.4/debian/qt3-assistant.prerm --- qt-x11-free-3.3.4.old/debian/qt3-assistant.prerm 1969-12-31 16:00:00.0 -0800 +++ qt-x11-free-3.3.4/debian/qt3-assistant.prerm 2005-04-27 23:37:10.0 -0700 @@ -0,0 +1,12 @@ +#!/bin/sh + +set -e + +case "$1" in + upgrade) ;; + remove|failed-upgrade|deconfigure) +update-alternatives --remove assistant "/usr/bin/assistant-qt3" +;; +esac + +#DEBHELPER# diff -urN qt-x11-free-3.3.4.old/debian/qt3-dev-tools.postinst qt-x11-free-3.3.4/debian/qt3-dev-tools.postinst --- qt-x11-free-3.3.4.old/debian/qt3-dev-tools.postinst 2005-04-27 22:06:45.0 -0700 +++ qt-x11-free-3.3.4/debian/qt3-dev-tools.postinst 2005-04-27 23:37:10.0 -0700 @@ -11,5 +11,15 @@ /usr/bin/uic uic "/usr/bin/uic-qt3" "35" \ --slave /usr/share/man/man1/uic.1.gz uic.1.gz \ "/usr/share/man/man1/uic-qt3.1.gz" - + +update-alternatives --install \ +/usr/bin/lupdate lupdate "/usr/bin/lupdate-qt3" "35" \ + --slave /usr/share/man/man1/lupdate.1.gz lupdate.1.gz \ + "/usr/share/man/man1/lupdate-qt3.1.gz" + +update-alternatives --install \ +/usr/bin/lrelease lrelease "/usr/bin/lrelease-qt3" "35" \ + --slave /usr/share/man/man1/lrelease.1.gz lrelease.1.gz \ + "/usr/share/man/man1/lrelease-qt3.1.gz" + #DEBHELPER# diff -urN qt-x11-free-3.3.4.old/debian/qt3-dev-tools.prerm qt-x11-free-3.3.4/debian/qt3-dev-tools.prerm --- qt-x11-free-3.3.4.old/debian/qt3-dev-tools.prerm 2005-04-27 22:06:45.0 -0700 +++ qt-x11-free-3.3.4/debian/qt3-dev-tools.prerm 2005-04-27 23:37:10.0 -0700 @@ -7,6 +7,8 @@ remove|failed-upgrade|deconfigure) update-alternatives --remove moc "/usr/bin/moc-qt3" update-alternatives --remove uic "/usr/bin/uic-qt3" +update-alternatives --remove lupdate "/usr/bin/lupdate-qt3" +update-alternatives --remove lrelease "/usr/bin/lrelease-qt3" ;; esac diff -urN qt-x11-free-3.3.4.old/debian/qt3-linguist.postinst qt-x11-free-3.3.4/debian/qt3-linguist.postinst --- qt-x11-free-3.3.4.old/debian/qt3-linguist.postinst 1969-12-31 16:00:00.0 -0800 +++ qt-x11-free-3.3.4/debian/qt3-linguist.postinst 2005-04-27 23:37:10.0 -0700 @@ -0,0 +1,10 @@ +#!/bin/sh + +set -e + +update-alternatives --install \ + /usr/bin/linguist-qt3 linguist "/usr/bin/linguist-qt3" "35" \ + --slave /usr/share/man/man1/linguist.1.gz linguist.1.gz \ + "/usr/share/man/man1/linguist-qt3.1.gz" + +#DEBHELPER# diff -urN qt-x11-free-3.3.4.old/debian/qt3-linguist.prerm qt-x11-free-3.3.4/debian/qt3-linguist.prerm --- qt-x11-free-3.3.4.old/debian/qt3-linguist.prerm 1969-12-31 16:00:00.0 -0800 +++ qt-x11-free-3.3.4/debian/qt3-linguist.prerm 2005-04-27 23:37:10.0 -0700 @@ -0,0 +1,12 @@ +#!/bin/sh + +set -e + +case "$1" in + upgrade) ;; + remove|failed-upgrade|deconfigure) +update-alternatives --remove linguist "/usr/bin/linguist-qt3" +;; +esac + +#DEBHELPER# diff -urN qt-x11-free-3.3.4.old/debian/qt3-qtconfig.postinst qt-x11-free-3.3.4/debian/qt3-qtconfig.postinst --- qt-x11-free-3.3.4.old/debian/qt3-qtconfig.postinst 1969-12-31 16:00:00.0 -0800 +++ qt-x11-free-3.3.4/debian/qt3-qtconfig.postinst 2005-04-27 23:37:10.0 -0700 @@ -0,0 +1,10 @@ +#!/bin/sh + +set -e + +update-alternatives --install \ + /usr/bin/qtconfig-qt3 qtconfig "/usr/bin/qtconfig-qt3" "35" \ + --slave /usr/share/man/man1/qtconfig.1.gz qtconfig.1.gz \ + "/usr/share/man/man1/qtconfig-qt3.1.gz" + +#DEBHELPER# diff -urN qt-x11-free-3.3.4.old/debian/qt3-qtconfig.prerm qt-x11-free-3.3.4/debian/qt3-qtconfig.prerm --- qt-x11-free-3.3.4.old/debian/qt3-qtconfig.prerm 1969-12-31 16:00:00.0 -0800 +++ qt-x11-free-3.3.4/debian/qt3-qtconfig.prerm 2005-04-27 23:37:10.0 -0700 @@ -0,0 +1,12 @@ +#!/bin/sh + +set -e + +case "$1" in + upgrade) ;; + remove|failed-upgrade|deconfigure) +update-alternatives --remove qtconfig "/usr/bin/qtconfig-qt3" +;; +esac + +#DEBHELPER# diff -urN qt-x11-free-3.3.4.old/debian/rules qt-x11-free-3.3.4/debian/rules --- qt-x11-free-3.3.4.old/debia
Bug#307481: aspell: symbol size mismatch in shared library
severity 307481 normal thanks On Tue, May 03, 2005 at 09:43:09AM -0400, James Aspnes wrote: > Upgrading to the most recent version of aspell-bin fixed the problem. > So there may be a missing dependency issue but otherwise this doesn't > seem to be a bug. Ugh. The soname of libaspell15 did not change from 0.50 -> 0.60, but maybe it should have. Although the external API/ABI did not change, the 'aspell' binary uses internal library symbols that did change. The only thing I could do at this time is make the current libaspell15 conflict with aspell-bin (<< 0.60), but that's pretty clumsy. Fortunately, it's not a release crtical bug since it does not affect woody -> sarge partial upgrades (woody doesn't have libaspell15). A better solution for the future is probably to make aspell-bin depend on the exact same version of libaspell15, instead of relying on shlibs to do a >= dependency. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#307551: zeiberbude: Depends on obsolete single-threaded Qt
Package: zeiberbude Severity: important >From the libqt3-dev package description: WARNING: The nonthreaded version of Qt3 is considered deprecated and may disappear anytime in the future. Please use libqt3-mt-dev instead (Read README.Debian for instructions). Changing the build dependency to libqt3-mt-dev is sufficient to fix this. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10-ac12 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299738: aspell with curses breaks vim-gtk
On Tue, Mar 15, 2005 at 07:46:19PM -0800, Fernando Brucher wrote: > When I invoke aspell from vim-gtk (under X), the new > curses enabled aspell confuses vim and it only shows > one line of garbage. Ah, that's what you get for using that Inferior Editor. Emacs of course works perfectly with aspell. ;) > Using the non-curses version of aspell works fine. I didn't see a > command line switch in aspell to do this so I recompiled aspell > without curses. Maybe Debian could offer a non-curses package of > aspell. The problem might be vim's fault for not suporting curses > display correctly. But this quick fix works fine. I guess the problem is that aspell is linked against libncursesw, but (g)vim is linked against libncurses (no 'w'). I suppose I could provide an alternate aspell binary not linked against libncursesw, but that seems overly clunky. How are you using aspell in vim? vimspell? -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#300286: aspell-sv: Swedish aspell dictionary not working with ispell.el
On Fri, Mar 18, 2005 at 07:43:20PM +0100, Björn Lindström wrote:
> Now, if I try to do (ispell-change-dictionary "svenska"), I get this error:
>
> Undefined dictionary: svenska
>
>
> This is the value of my ispell-dictionary-alist, which doesn't look right:
>
> (("american" "[a-zA-Z]" "[^a-zA-Z]" "[']" nil
> ("-d" "en_US")
> nil iso-8859-1)
> ("british" "[a-zA-Z]" "[^a-zA-Z]" "[']" nil
> ("-d" "en_GB")
> nil iso-8859-1)
> ("canadian" "[a-zA-Z]" "[^a-zA-Z]" "[']" nil
> ("-d" "en_CA")
> nil iso-8859-1)
> ("english" "[a-zA-Z]" "[^a-zA-Z]" "[']" nil
> ("-d" "en")
> nil iso-8859-1)
> (nil "[A-Za-z]" "[^A-Za-z]" "[']" nil
> ("-B")
> nil iso-8859-1))
The problem is simply that aspell-sv lacks a .info-aspell file, as
specified in:
http://dict-common.alioth.debian.org/dsdt-policy.html#aspell-registration
--
Society is never going to make any progress until we all learn to
pretend to like each other.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306448: pbuilder: Support for preserving environment PATH
On Sat, Jun 18, 2005 at 09:18:30PM +0900, Junichi Uekawa wrote: > Hi, > > > Here's a simple patch that adds a --preserve-envpath to pbuilder which > > prevents the PATH from being clobbered. > > I'm not sure if there should be a generic environmental variable > option or one specific to PATH. > > I'm inclined to move the default-PATH-setting to a configuration > file rather than adding a yet-another-option. > > Thoughts? That would be fine with me. In fact, it would be a better solution for me, since right now I have to use an ugly wrapper script to be able to run pbuilder from my normal user account that does: sudo sh -c "export PATH=/usr/lib/ccache:$PATH; /usr/bin/pdebuild ..." Otherwise, sudo or chroot (I forget which) will clobber the PATH anyway, even with my patch applied... -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310590: aspell dictionaries depend on libaspell15 package name, that might change
On Mon, Jun 20, 2005 at 04:40:30PM +0200, Agustin Martin wrote: > On Tue, May 31, 2005 at 04:55:17PM +0200, Agustin Martin wrote: > > That makes the mirrors happy because the aspell dict is now arch:all, but > > does not cause hashes being rebuilt if a new aspell with incompatible binary > > hash format is uploaded. That is what ispell-autobuildhash is currently > > doing and is what is expected from aspell-autobuildhash. There are some > > problems pending, like a /usr/lib/aspell-0.60 explicitely hardcoded path > > that > > will complicate a transition to e.g. 0.61, while everything would be > > simpler if a plain /usr/lib/aspell is used. These are the kind of things > > that are still to be considered. > > Can local/extra dirs be selected besides /usr/lib/aspell-0.60? At runtime, yes. At configure time, there are --enable-pkgdatadir=DIR and --enable-pkglibdir=DIR, but I believe you cannot specify multiple directories for those. > Something > like aspell looking for dicts and datas in both > > /usr/lib/aspell-0.60 > /usr/lib/aspell-auto > > Something like this would be good for the autobuildhash stuff, if the > auto-dicts are installed in /usr/lib/aspell-auto. This way, when > upgrading to e.g., aspell-0.61 autobuilt hashes will be rebuilt and found by > the new aspell at /usr/lib/aspell-auto, new aspell stuff would be installed > in /usr/lib/aspell-0.61 and obsolete dicts at /usr/lib/aspell-0.60 would be > ignored. Wouldn't you want to clean up the obsolete dicts? I don't really understand what you're trying to accomplish. Are you trying to support *both* old school dictionaries (with the hash files packaged) and new ones where the hash is autobuilt? -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306448: pbuilder: Support for preserving environment PATH
On Mon, Jun 20, 2005 at 07:40:22PM +0900, Junichi Uekawa wrote: > > > I'm not sure if there should be a generic environmental variable > > > option or one specific to PATH. > > > > > > I'm inclined to move the default-PATH-setting to a configuration > > > file rather than adding a yet-another-option. > > > > > > Thoughts? > > > > That would be fine with me. In fact, it would be a better solution for > > me, since right now I have to use an ugly wrapper script to be able to > > run pbuilder from my normal user account that does: > > > > sudo sh -c "export PATH=/usr/lib/ccache:$PATH; /usr/bin/pdebuild ..." > > > > Otherwise, sudo or chroot (I forget which) will clobber the PATH anyway, > > even with my patch applied... > > > The following change should work fine, no? No... > --- pbuilder-buildpackage 21 Apr 2005 23:10:23 - 1.111 > +++ pbuilder-buildpackage 20 Jun 2005 10:38:50 - > @@ -87,7 +87,6 @@ > fi > > echo " -> Building the package" > -export PATH="/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin" This is around where you have to set the PATH (right after $CHROOTEXEC). If you set the PATH before $CHROOTEXEC (e.g. when the pbuilderrc is sourced like below), it'll just get clobbered by $CHROOTEXEC... > executehooks "A" > > Index: pbuilderrc > === > RCS file: /home/dancer/CVSREPOSITORY/pbuilder/pbuilderrc,v > retrieving revision 1.33 > diff -u -r1.33 pbuilderrc > --- pbuilderrc13 Feb 2005 07:20:44 - 1.33 > +++ pbuilderrc20 Jun 2005 10:38:50 - > @@ -53,3 +53,6 @@ > # Set the debootstrap variant to 'buildd' type. > DEBOOTSTRAPOPTS[0]='--variant=buildd' > # unset DEBOOTSTRAPOPTS > + > +# Set the PATH I am going to use inside pbuilder: default is > "/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin" > +export PATH="/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin" > -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310590: aspell dictionaries depend on libaspell15 package name, that might change
On Tue, Jun 21, 2005 at 12:54:13PM +0200, Agustin Martin wrote: > On Tue, Jun 21, 2005 at 04:54:50AM +0300, Brian Nelson wrote: > > Wouldn't you want to clean up the obsolete dicts? > > > > I don't really understand what you're trying to accomplish. Are you > > trying to support *both* old school dictionaries (with the hash files > > packaged) and new ones where the hash is autobuilt? > > I was just brainstorming about how to make the transition easier. > > I personally prefer all aspell dicts being autobuilt, that would make > things much simpler. Are there any good reasons to not do require dicts to be autobuild, aside from having to do a transition? > But in that case I think is better if things are > put in a non-versioned directory, so the dict location does not change > in case of a non binary-compatible aspell upgrade, just hashes are > autorebuilt. That could be something like > > /usr/lib/aspell-auto I'll buy that. I could change aspell to use /usr/lib/aspell-auto, and the only thing that would break would be current dictionaries, right? If a dictionary were not autobuilt but installed stuff into /usr/lib/aspell-auto directly from the .deb, would aspell-autobuildhash be able to cope? Of course, if both auto and non-auto dicts could share the /usr/lib/aspell-auto, we might as well go back to just calling it /usr/lib/aspell... > If new hashes are sought for in a versioned dir, we would need to move the > dicts links when a new binary incompatible aspell is uploaded, making things > unnecesarily complicated. Yeah. The only real benefit from having a version in the directory name is to support concurrent installs of incompatible aspells, which of course we don't need... -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310911: aspell: meaning of -l changed from 0.50 with no warning
On Thu, May 26, 2005 at 02:32:54PM -0700, Tom Brown wrote: > I think changing the meaning of a parameter to something totally > different should have at least been mentioned in changelog.Debian.gz or > changelog.gz but the only "documentation" I can find for the change is > bug #301026. Yeah, I didn't notice that change until later. I agree that upstream should have better documented it. > I've attached a patch which outputs a more helpful error if one uses -l > without a parameter. I've forwarded your suggestion to upstream (it seems like a good idea to me), but I still haven't heard back from him... I'll probably just go ahead and apply it if I don't hear anything in a couple more days. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306448: pbuilder: Support for preserving environment PATH
On Fri, Jun 24, 2005 at 07:55:10AM +0900, Junichi Uekawa wrote:
> > > --- pbuilder-buildpackage 21 Apr 2005 23:10:23 - 1.111
> > > +++ pbuilder-buildpackage 20 Jun 2005 10:38:50 -
> > > @@ -87,7 +87,6 @@
> > > fi
> > >
> > > echo " -> Building the package"
> > > -export PATH="/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin"
> >
> > This is around where you have to set the PATH (right after $CHROOTEXEC).
> > If you set the PATH before $CHROOTEXEC (e.g. when the pbuilderrc is
> > sourced like below), it'll just get clobbered by $CHROOTEXEC...
>
> Now I don't grok you.
> $CHROOTEXEC is just 'chroot' which shouldn't have any effect on
> the environmental variable which the shell is holding.
Err, yeah, sorry. It's not CHROOTEXEC, it's PBUILDERROOTCMD (sudo, su,
etc.) that munges the PATH.
> Removing this PATH over to the pbuilderrc config file which
> is sourced at the top of pbuilder-buildpackage should fix what you're
> experiencing.
>
> ... but that's not happening.
>
> Hmm...
Ah, it's because the pbuilderrc is sourced in pdebuild (via
pbuilder-checkparams) *before* the ${PBUILDERROOTCMD} pbuilder stuff...
It should work if you set PBUILDERROOTCMD="" run the whole
/usr/bin/pdebuild as root.
--
Society is never going to make any progress until we all learn to
pretend to like each other.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317873: aspell: unstable to testing?
On Fri, Jul 15, 2005 at 05:21:58PM -0400, Steven Rostedt wrote: [...] > OK, so my question is, should I go back to testing. (Sorry to be > offtopic for aspell, but the subject came up here). I've only gone from > stable to testing to unstable. Never the reverse. How safe is that? It depends on the state of your system. If you've already installed parts of the GCC 4 transition on your system, it won't be a particularly smooth move to testing. Also, keep in mind that testing will also have to undergo the GCC 4 transition in a couple weeks. It'll hopefully go smoother than the unstable one, but there will still be some bumps along the way. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318765: libqt4-dev: got broken alternatives symlink for moc
Jan Niehusmann <[EMAIL PROTECTED]> writes: > Compiling a simple test program with qt4 failed with this error message: > > $ qmake > $ make > (cd "/src/tools/moc" && make) > /bin/sh: line 0: cd: /src/tools/moc: No such file or directory > make: *** [/usr/bin/moc] Error 1 > > The reason is, that I somehow ended up with a broken alternatives > symlink > for moc: > > $ ls -al /etc/alternatives/moc > lrwxrwxrwx 1 root root 20 Nov 5 2003 /etc/alternatives/moc -> > /usr/lib/qt2/bin/moc > $ ls -al /usr/lib/qt2/bin/moc > ls: /usr/lib/qt2/bin/moc: No such file or directory Hmm, I wonder if an old Qt2 package didn't properly call "update-alternatives --remove" in the prerm. > Unfortunately, update-alternatives seems to be unable to correct this: > > # update-alternatives --config moc > > There is only 1 program which provides moc > (/usr/bin/moc-qt4). Nothing to configure. That's probably an update-alternatives bug, but there are so many to choose from I can't figure out which one it is... #100135 is one possibility... > Of course, the fix is trivial (manually correct the symlink). I have no > idea how this happened, but I surely didn't manually mess with the > alternatives. Probably some interesting sequence of installs and > uninstalls of different versions of qt. Yep, that would be my guess. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#316089: chage fix broken
found 316089 3.65 thanks The fix for this appears to be broken. I see: Setting up exim4-config (4.52-1) ... Adding system-user for exim (v4) chage: can't open shadow password fileUse of uninitialized value in concatenation (.) or string at /usr/sbin/adduser line 400. groupdel: group Debian-exim does not exist dpkg: error processing exim4-config (--configure): subprocess post-installation script return error exit status 1 -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#316089: chage fix broken
On Wed, Jul 20, 2005 at 08:12:25AM +0200, Marc Haber wrote: > tags #316089 - sid etch sarge > confirmed #316089 3.65 > thanks > > On Tue, Jul 19, 2005 at 08:41:59PM -0700, Brian Nelson wrote: > > The fix for this appears to be broken. I see: > > > > Setting up exim4-config (4.52-1) ... > > Adding system-user for exim (v4) > > chage: can't open shadow password fileUse of uninitialized value in > > concatenation (.) or string at /usr/sbin/adduser line 400. > > groupdel: group Debian-exim does not exist > > dpkg: error processing exim4-config (--configure): > > subprocess post-installation script return error exit status 1 > > That's kind of a cosmetic issue, the "use of unitiailized value" comes > from the construction of the error message (which does not get output > here). Which version of passwd do you have installed on your system? It was actually an old version: 1:4.0.3-35 > The cosmetic issue has been fixed in svn, and I cannot reproduce the > issue any more here. However, that error message shouldn't have been > displayed in any place since this is the case the chage error handling > change was supposed to handle specially (which is does on my test > system). Can you please try > > adduser --system --group --home /var/spool/exim4 --no-create-home \ > --disabled-login --force-badname Debian-exim-test > > on your system and give me the output? The Debian-exim-test account > can be removed again afterwards. It appears to work fine on a fully updated sid system: # adduser --system --group --home /var/spool/exim4 --no-create-home --disabled-login --force-badname Debian-exim-test adduser: Warning: The home dir you specified does not exist. Allowing use of questionable username. Adding system user `Debian-exim-test'... Adding new group `Debian-exim-test' (101). Adding new user `Debian-exim-test' (101) with group `Debian-exim-test'. chage: the shadow password file is not present chage failed with return code 3, shadow not enabled, password aging cannot be set. Continuing.Not creating home directory. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#273761: aspell-bin: Use alternatives to provide /usr/bin/ispell
As Agustin pointed out, it's probably too dangerous to have /usr/bin/ispell managed by the alternatives system. However, I will make sure the ispell script (as well as spell) are installed in /usr/share/doc/aspell/examples so that they're easier to find and may be used if the system administrator chooses. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319440: aspell-el: Info file needed for dictionaries-common emacs registration
Package: aspell-el Severity: normal Tags: help I need to create a aspell-el.info-aspell file for the aspell-el dictionary package, but I'm not familiar enough with Greek to do it myself. It should conform to the format as described here: http://dict-common.alioth.debian.org/dsdt-policy.html#infofile -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305006: kdelibs4: depends on libaspell15, but it have to be libaspell15c2
On Thu, Jul 21, 2005 at 09:42:49PM -0400, Josh Metzler wrote: > Actually, it sounds like libaspell15 doesn't export any C++ symbols, and so > didn't need to do a transition. It is likely going to undo the package > name change and go back to libaspell15. I'll provide both libaspell15 and libaspell15c2 (for now). I have prepared packages, but they can't be uploaded until ftp-master comes back online. In the meantime, you can find them here: http://people.debian.org/~pyro/pending/ -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319456: man dangling symlinks
tag 319456 confirmed thanks On Fri, Jul 22, 2005 at 10:32:17AM +0200, Jose Antonio wrote: > from /etc/cron.daily/man-db: > mandb: warning: /usr/share/man/man1/moc.1.gz is a dangling symlink > mandb: warning: /usr/share/man/man1/uic.1.gz is a dangling symlink > mandb: warning: /usr/share/man/man1/qtconfig.1.gz is a dangling symlink > mandb: warning: /usr/share/man/man1/qmake.1.gz is a dangling symlink > mandb: warning: /usr/share/man/man1/lupdate.1.gz is a dangling symlink > mandb: warning: /usr/share/man/man1/lrelease.1.gz is a dangling symlink > > maybe related to #318765 (update-alternatives bug) Nope, that's my fault--they're dangling because there aren't any real manpages to point to. I've been meaning to add those manpages but haven't gotten around to it yet... -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319660: katoob depends on libaspell15 which doesn't exists anymore
tag 319660 pending thanks On Sat, Jul 23, 2005 at 08:28:59PM +0100, Baruch Even wrote: > katoob depends on libaspell15 which has been replaced with > libaspell15c2. The package needs to be rebuilt to correct this. Please don't. I (aspell maintainer) am undoing the libaspell15 transition, so this problem will go away as soon as ftp-master comes back up and I can upload a new package. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318889: sylpheed-claws-gtk2: libaspell15 was changed to libaspell15c2 so it doesn't install
tag 318889 pending thanks On Mon, Jul 18, 2005 at 03:51:51PM +0300, Micha Feigin wrote: > Debain switch from libaspell15 to libaspell15c2 which requires a rebuild > of the package. After that it works fine. Without it, it won't install I (aspell maintainer) am undoing the libaspell15 transition, so this problem will go away as soon as ftp-master comes back up and I can upload a new package. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318053: python2.3-gnome2-extras: package is uninstallable because it depends on libaspell15
tag 318053 pending thanks On Wed, Jul 13, 2005 at 02:04:24AM -0400, John McCutchan wrote: > Package depends on libaspell15, which has been replaced by libaspell15c2 I (aspell maintainer) am undoing the libaspell15 transition, so this problem will go away as soon as ftp-master comes back up and I can upload a new package. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317814: libenchant1 depends on removed libaspell15 package and cannot be installed.
tag 317814 pending thanks On Mon, Jul 11, 2005 at 10:28:44PM +0100, David Ramsden wrote: > libenchant1 depends on libapsell15 which appears to have been removed > and replaced with libapsell15c2. > > As a result libenchant1 cannot be installed. > > This stops programs such as abiword from being installed. > > Please update the depends on this package. I (aspell maintainer) am undoing the libaspell15 transition, so this problem will go away as soon as ftp-master comes back up and I can upload a new package. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317954: bluefish 1.0-1 depends on the absent in unstable libaspell15
tag 317954 pending thanks On Tue, Jul 12, 2005 at 10:01:10AM -0500, Erick Ivaan Lopez Carreon wrote: > The following packages have unmet dependencies: > bluefish: Depends: libaspell15 (>= 0.60) but it is not installable > E: Broken packages > > > And in accordance with the list of packages: > Package libaspell15 > * stable (libs): The GNU Aspell spell-checker runtime toolkits > 0.60.2+20050121-2: alpha amd64 arm hppa i386 ia64 m68k mips > mipsel powerpc s390 sparc > * testing (libs): The GNU Aspell spell-checker runtime toolkits > 0.60.2+20050121-3: alpha amd64 arm hppa i386 ia64 m68k mips > mipsel powerpc s390 sparc > Package libaspell15c2 > * unstable (libs): The GNU Aspell spell-checker runtime toolkits > 0.60.3-3: arm hppa i386 m68k mips mipsel powerpc s390 sparc I (aspell maintainer) am undoing the libaspell15 transition, so this problem will go away as soon as ftp-master comes back up and I can upload a new package. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319665: aspell-no: Needs repackaging for latest aspell
Package: aspell-no Severity: grave Version: 2.0-20 Tags: sid As of the aspell 0.60.3-2 package, I changed the location in which aspell looks for dictionaries from /usr/lib/aspell-0.60 to /usr/lib/aspell (for support for autobuilding dictionary hashes). Obviously, this broke all existing dictionaries so I made it conflict with dictionaries providing aspell6-dictionary. Additionally, as of version 0.60.3-3 in conjunction with dictionaries-common >= 0.49.2, aspell now fully supports building dictionary hashes at install time. This provides two huge advantages over packaging the hashes in the .deb: 1. The dictionary packages may be Arch: all, which for some dictionaries provides a significant relief to the mirrors. 2. The hashes will be automatically rebuilt for new aspell versions if the dictionary format changes, eliminating the need to transition all dictionary packages. Consequently, this is now the preferred method for packaging aspell dictionaries. Packaging dictionaries for aspell >= 0.60.3-3 - [Old-style hashes (.rws files) in .deb] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell6a-dictionary" 2. Ensure dictionary files are installed to /usr/lib/aspell 3. Remove any dependency on libaspell15 (see #310590) or aspell-bin (which no longer exists). Instead depend on aspell (>= 0.60.3-2). [New-style autobuilt hashes] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell-dictionary" (no version in name). 2. Remove build-dependency on aspell(-bin) 3. Change Architecture to "all" 4. Add binary package dependency on "aspell (>= 0.60.3-3)" 5. Remove any relationship on libaspell15 or aspell-bin 6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where $DICT_LANG is the iso code for the dictionary, e.g. "en") 7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to /usr/share/aspell. 8. For each of the above wordlists: a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where $WORDLIST is the wordlist filename minus the .*wl.gz extension) b. Add a symlink /usr/lib/aspell/$WORDLIST.rws -> /var/lib/aspell/$WORDLIST.rws c. Append the $WORDLIST to the file "/usr/share/aspell/$DICT_LANG/.contents". The .contents file should contain one $WORDLIST per line. 9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the easiest way to do this is to build-depend on dictionaries-common-dev (>= 0.9.1) and run installdeb-aspell from debian/rules. For some examples, see aspell-en (for dictionaries based on ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for dictionaries based on plain wordlists). If the dictionary is packaged correctly, you should see something like: Setting up aspell-en (6.0-0-5) ... aspell-autobuildhash: processing: en [en-common] aspell-autobuildhash: processing: en [en-variant_0] aspell-autobuildhash: processing: en [en-variant_1] aspell-autobuildhash: processing: en [en-variant_2] aspell-autobuildhash: processing: en [en_CA-w_accents-only] aspell-autobuildhash: processing: en [en_CA-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only] aspell-autobuildhash: processing: en [en_US-w_accents-only] aspell-autobuildhash: processing: en [en_US-wo_accents-only] when installing. The dictionary should then work the same as before. Please send any questions to the [EMAIL PROTECTED] mailing list. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318816: Needs repackaging for latest aspell
retitle 318816 Needs repackaging for latest aspell severity 318816 grave tag 318816 sid thanks Here's some additional information regarding the aspell changes: As of the aspell 0.60.3-2 package, I changed the location in which aspell looks for dictionaries from /usr/lib/aspell-0.60 to /usr/lib/aspell (for support for autobuilding dictionary hashes). Obviously, this broke all existing dictionaries so I made it conflict with dictionaries providing aspell6-dictionary. Additionally, as of version 0.60.3-3 in conjunction with dictionaries-common >= 0.49.2, aspell now fully supports building dictionary hashes at install time. This provides two huge advantages over packaging the hashes in the .deb: 1. The dictionary packages may be Arch: all, which for some dictionaries provides a significant relief to the mirrors. 2. The hashes will be automatically rebuilt for new aspell versions if the dictionary format changes, eliminating the need to transition all dictionary packages. Consequently, this is now the preferred method for packaging aspell dictionaries. Packaging dictionaries for aspell >= 0.60.3-3 - [Old-style hashes (.rws files) in .deb] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell6a-dictionary" 2. Ensure dictionary files are installed to /usr/lib/aspell 3. Remove any dependency on libaspell15 (see #310590) or aspell-bin (which no longer exists). Instead depend on aspell (>= 0.60.3-2). [New-style autobuilt hashes] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell-dictionary" (no version in name). 2. Remove build-dependency on aspell(-bin) 3. Change Architecture to "all" 4. Add binary package dependency on "aspell (>= 0.60.3-3)" 5. Remove any relationship on libaspell15 or aspell-bin 6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where $DICT_LANG is the iso code for the dictionary, e.g. "en") 7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to /usr/share/aspell. 8. For each of the above wordlists: a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where $WORDLIST is the wordlist filename minus the .*wl.gz extension) b. Add a symlink /usr/lib/aspell/$WORDLIST.rws -> /var/lib/aspell/$WORDLIST.rws c. Append the $WORDLIST to the file "/usr/share/aspell/$DICT_LANG/.contents". The .contents file should contain one $WORDLIST per line. 9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the easiest way to do this is to build-depend on dictionaries-common-dev (>= 0.9.1) and run installdeb-aspell from debian/rules. For some examples, see aspell-en (for dictionaries based on ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for dictionaries based on plain wordlists). If the dictionary is packaged correctly, you should see something like: Setting up aspell-en (6.0-0-5) ... aspell-autobuildhash: processing: en [en-common] aspell-autobuildhash: processing: en [en-variant_0] aspell-autobuildhash: processing: en [en-variant_1] aspell-autobuildhash: processing: en [en-variant_2] aspell-autobuildhash: processing: en [en_CA-w_accents-only] aspell-autobuildhash: processing: en [en_CA-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only] aspell-autobuildhash: processing: en [en_US-w_accents-only] aspell-autobuildhash: processing: en [en_US-wo_accents-only] when installing. The dictionary should then work the same as before. Please send any questions to the [EMAIL PROTECTED] mailing list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319619: Needs repackaging for latest aspell
retitle 319619 Needs repackaging for latest aspell severity 319619 grave tag 319619 sid thanks Here's some additional information regarding the aspell changes: As of the aspell 0.60.3-2 package, I changed the location in which aspell looks for dictionaries from /usr/lib/aspell-0.60 to /usr/lib/aspell (for support for autobuilding dictionary hashes). Obviously, this broke all existing dictionaries so I made it conflict with dictionaries providing aspell6-dictionary. Additionally, as of version 0.60.3-3 in conjunction with dictionaries-common >= 0.49.2, aspell now fully supports building dictionary hashes at install time. This provides two huge advantages over packaging the hashes in the .deb: 1. The dictionary packages may be Arch: all, which for some dictionaries provides a significant relief to the mirrors. 2. The hashes will be automatically rebuilt for new aspell versions if the dictionary format changes, eliminating the need to transition all dictionary packages. Consequently, this is now the preferred method for packaging aspell dictionaries. Packaging dictionaries for aspell >= 0.60.3-3 - [Old-style hashes (.rws files) in .deb] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell6a-dictionary" 2. Ensure dictionary files are installed to /usr/lib/aspell 3. Remove any dependency on libaspell15 (see #310590) or aspell-bin (which no longer exists). Instead depend on aspell (>= 0.60.3-2). [New-style autobuilt hashes] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell-dictionary" (no version in name). 2. Remove build-dependency on aspell(-bin) 3. Change Architecture to "all" 4. Add binary package dependency on "aspell (>= 0.60.3-3)" 5. Remove any relationship on libaspell15 or aspell-bin 6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where $DICT_LANG is the iso code for the dictionary, e.g. "en") 7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to /usr/share/aspell. 8. For each of the above wordlists: a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where $WORDLIST is the wordlist filename minus the .*wl.gz extension) b. Add a symlink /usr/lib/aspell/$WORDLIST.rws -> /var/lib/aspell/$WORDLIST.rws c. Append the $WORDLIST to the file "/usr/share/aspell/$DICT_LANG/.contents". The .contents file should contain one $WORDLIST per line. 9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the easiest way to do this is to build-depend on dictionaries-common-dev (>= 0.9.1) and run installdeb-aspell from debian/rules. For some examples, see aspell-en (for dictionaries based on ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for dictionaries based on plain wordlists). If the dictionary is packaged correctly, you should see something like: Setting up aspell-en (6.0-0-5) ... aspell-autobuildhash: processing: en [en-common] aspell-autobuildhash: processing: en [en-variant_0] aspell-autobuildhash: processing: en [en-variant_1] aspell-autobuildhash: processing: en [en-variant_2] aspell-autobuildhash: processing: en [en_CA-w_accents-only] aspell-autobuildhash: processing: en [en_CA-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only] aspell-autobuildhash: processing: en [en_US-w_accents-only] aspell-autobuildhash: processing: en [en_US-wo_accents-only] when installing. The dictionary should then work the same as before. Please send any questions to the [EMAIL PROTECTED] mailing list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319156: Needs repackaging for latest aspell
retitle 319156 Needs repackaging for latest aspell severity 319156 grave tag 319156 sid thanks Here's some additional information regarding the aspell changes: As of the aspell 0.60.3-2 package, I changed the location in which aspell looks for dictionaries from /usr/lib/aspell-0.60 to /usr/lib/aspell (for support for autobuilding dictionary hashes). Obviously, this broke all existing dictionaries so I made it conflict with dictionaries providing aspell6-dictionary. Additionally, as of version 0.60.3-3 in conjunction with dictionaries-common >= 0.49.2, aspell now fully supports building dictionary hashes at install time. This provides two huge advantages over packaging the hashes in the .deb: 1. The dictionary packages may be Arch: all, which for some dictionaries provides a significant relief to the mirrors. 2. The hashes will be automatically rebuilt for new aspell versions if the dictionary format changes, eliminating the need to transition all dictionary packages. Consequently, this is now the preferred method for packaging aspell dictionaries. Packaging dictionaries for aspell >= 0.60.3-3 - [Old-style hashes (.rws files) in .deb] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell6a-dictionary" 2. Ensure dictionary files are installed to /usr/lib/aspell 3. Remove any dependency on libaspell15 (see #310590) or aspell-bin (which no longer exists). Instead depend on aspell (>= 0.60.3-2). [New-style autobuilt hashes] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell-dictionary" (no version in name). 2. Remove build-dependency on aspell(-bin) 3. Change Architecture to "all" 4. Add binary package dependency on "aspell (>= 0.60.3-3)" 5. Remove any relationship on libaspell15 or aspell-bin 6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where $DICT_LANG is the iso code for the dictionary, e.g. "en") 7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to /usr/share/aspell. 8. For each of the above wordlists: a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where $WORDLIST is the wordlist filename minus the .*wl.gz extension) b. Add a symlink /usr/lib/aspell/$WORDLIST.rws -> /var/lib/aspell/$WORDLIST.rws c. Append the $WORDLIST to the file "/usr/share/aspell/$DICT_LANG/.contents". The .contents file should contain one $WORDLIST per line. 9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the easiest way to do this is to build-depend on dictionaries-common-dev (>= 0.9.1) and run installdeb-aspell from debian/rules. For some examples, see aspell-en (for dictionaries based on ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for dictionaries based on plain wordlists). If the dictionary is packaged correctly, you should see something like: Setting up aspell-en (6.0-0-5) ... aspell-autobuildhash: processing: en [en-common] aspell-autobuildhash: processing: en [en-variant_0] aspell-autobuildhash: processing: en [en-variant_1] aspell-autobuildhash: processing: en [en-variant_2] aspell-autobuildhash: processing: en [en_CA-w_accents-only] aspell-autobuildhash: processing: en [en_CA-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only] aspell-autobuildhash: processing: en [en_US-w_accents-only] aspell-autobuildhash: processing: en [en_US-wo_accents-only] when installing. The dictionary should then work the same as before. Please send any questions to the [EMAIL PROTECTED] mailing list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319676: aspell-bg: Needs repackaging for latest aspell
Package: aspell-bg Severity: grave Version: 3.0-4 Tags: sid As of the aspell 0.60.3-2 package, I changed the location in which aspell looks for dictionaries from /usr/lib/aspell-0.60 to /usr/lib/aspell (for support for autobuilding dictionary hashes). Obviously, this broke all existing dictionaries so I made it conflict with dictionaries providing aspell6-dictionary. Additionally, as of version 0.60.3-3 in conjunction with dictionaries-common >= 0.49.2, aspell now fully supports building dictionary hashes at install time. This provides two huge advantages over packaging the hashes in the .deb: 1. The dictionary packages may be Arch: all, which for some dictionaries provides a significant relief to the mirrors. 2. The hashes will be automatically rebuilt for new aspell versions if the dictionary format changes, eliminating the need to transition all dictionary packages. Consequently, this is now the preferred method for packaging aspell dictionaries. Packaging dictionaries for aspell >= 0.60.3-3 - [Old-style hashes (.rws files) in .deb] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell6a-dictionary" 2. Ensure dictionary files are installed to /usr/lib/aspell 3. Remove any dependency on libaspell15 (see #310590) or aspell-bin (which no longer exists). Instead depend on aspell (>= 0.60.3-2). [New-style autobuilt hashes] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell-dictionary" (no version in name). 2. Remove build-dependency on aspell(-bin) 3. Change Architecture to "all" 4. Add binary package dependency on "aspell (>= 0.60.3-3)" 5. Remove any relationship on libaspell15 or aspell-bin 6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where $DICT_LANG is the iso code for the dictionary, e.g. "en") 7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to /usr/share/aspell. 8. For each of the above wordlists: a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where $WORDLIST is the wordlist filename minus the .*wl.gz extension) b. Add a symlink /usr/lib/aspell/$WORDLIST.rws -> /var/lib/aspell/$WORDLIST.rws c. Append the $WORDLIST to the file "/usr/share/aspell/$DICT_LANG/.contents". The .contents file should contain one $WORDLIST per line. 9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the easiest way to do this is to build-depend on dictionaries-common-dev (>= 0.9.1) and run installdeb-aspell from debian/rules. For some examples, see aspell-en (for dictionaries based on ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for dictionaries based on plain wordlists). If the dictionary is packaged correctly, you should see something like: Setting up aspell-en (6.0-0-5) ... aspell-autobuildhash: processing: en [en-common] aspell-autobuildhash: processing: en [en-variant_0] aspell-autobuildhash: processing: en [en-variant_1] aspell-autobuildhash: processing: en [en-variant_2] aspell-autobuildhash: processing: en [en_CA-w_accents-only] aspell-autobuildhash: processing: en [en_CA-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only] aspell-autobuildhash: processing: en [en_US-w_accents-only] aspell-autobuildhash: processing: en [en_US-wo_accents-only] when installing. The dictionary should then work the same as before. Please send any questions to the [EMAIL PROTECTED] mailing list. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319675: aspell-de: Needs repackaging for latest aspell
Package: aspell-de Version: 0.60-20030222-1-3 Severity: grave Tags: sid As of the aspell 0.60.3-2 package, I changed the location in which aspell looks for dictionaries from /usr/lib/aspell-0.60 to /usr/lib/aspell (for support for autobuilding dictionary hashes). Obviously, this broke all existing dictionaries so I made it conflict with dictionaries providing aspell6-dictionary. Additionally, as of version 0.60.3-3 in conjunction with dictionaries-common >= 0.49.2, aspell now fully supports building dictionary hashes at install time. This provides two huge advantages over packaging the hashes in the .deb: 1. The dictionary packages may be Arch: all, which for some dictionaries provides a significant relief to the mirrors. 2. The hashes will be automatically rebuilt for new aspell versions if the dictionary format changes, eliminating the need to transition all dictionary packages. Consequently, this is now the preferred method for packaging aspell dictionaries. Packaging dictionaries for aspell >= 0.60.3-3 - [Old-style hashes (.rws files) in .deb] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell6a-dictionary" 2. Ensure dictionary files are installed to /usr/lib/aspell 3. Remove any dependency on libaspell15 (see #310590) or aspell-bin (which no longer exists). Instead depend on aspell (>= 0.60.3-2). [New-style autobuilt hashes] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell-dictionary" (no version in name). 2. Remove build-dependency on aspell(-bin) 3. Change Architecture to "all" 4. Add binary package dependency on "aspell (>= 0.60.3-3)" 5. Remove any relationship on libaspell15 or aspell-bin 6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where $DICT_LANG is the iso code for the dictionary, e.g. "en") 7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to /usr/share/aspell. 8. For each of the above wordlists: a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where $WORDLIST is the wordlist filename minus the .*wl.gz extension) b. Add a symlink /usr/lib/aspell/$WORDLIST.rws -> /var/lib/aspell/$WORDLIST.rws c. Append the $WORDLIST to the file "/usr/share/aspell/$DICT_LANG/.contents". The .contents file should contain one $WORDLIST per line. 9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the easiest way to do this is to build-depend on dictionaries-common-dev (>= 0.9.1) and run installdeb-aspell from debian/rules. For some examples, see aspell-en (for dictionaries based on ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for dictionaries based on plain wordlists). If the dictionary is packaged correctly, you should see something like: Setting up aspell-en (6.0-0-5) ... aspell-autobuildhash: processing: en [en-common] aspell-autobuildhash: processing: en [en-variant_0] aspell-autobuildhash: processing: en [en-variant_1] aspell-autobuildhash: processing: en [en-variant_2] aspell-autobuildhash: processing: en [en_CA-w_accents-only] aspell-autobuildhash: processing: en [en_CA-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only] aspell-autobuildhash: processing: en [en_US-w_accents-only] aspell-autobuildhash: processing: en [en_US-wo_accents-only] when installing. The dictionary should then work the same as before. Please send any questions to the [EMAIL PROTECTED] mailing list. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages aspell-de depends on: ii dictionaries-common 0.49.2 Common utilities for spelling dict ii libaspell15 0.60.3-4 GNU Aspell spell-checker runtime l aspell-de recommends no packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319670: aspell-pt: Needs repackaging for latest aspell
Package: aspell-pt Severity: grave Version: 0.50-2-4 Tags: sid As of the aspell 0.60.3-2 package, I changed the location in which aspell looks for dictionaries from /usr/lib/aspell-0.60 to /usr/lib/aspell (for support for autobuilding dictionary hashes). Obviously, this broke all existing dictionaries so I made it conflict with dictionaries providing aspell6-dictionary. Additionally, as of version 0.60.3-3 in conjunction with dictionaries-common >= 0.49.2, aspell now fully supports building dictionary hashes at install time. This provides two huge advantages over packaging the hashes in the .deb: 1. The dictionary packages may be Arch: all, which for some dictionaries provides a significant relief to the mirrors. 2. The hashes will be automatically rebuilt for new aspell versions if the dictionary format changes, eliminating the need to transition all dictionary packages. Consequently, this is now the preferred method for packaging aspell dictionaries. Packaging dictionaries for aspell >= 0.60.3-3 - [Old-style hashes (.rws files) in .deb] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell6a-dictionary" 2. Ensure dictionary files are installed to /usr/lib/aspell 3. Remove any dependency on libaspell15 (see #310590) or aspell-bin (which no longer exists). Instead depend on aspell (>= 0.60.3-2). [New-style autobuilt hashes] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell-dictionary" (no version in name). 2. Remove build-dependency on aspell(-bin) 3. Change Architecture to "all" 4. Add binary package dependency on "aspell (>= 0.60.3-3)" 5. Remove any relationship on libaspell15 or aspell-bin 6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where $DICT_LANG is the iso code for the dictionary, e.g. "en") 7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to /usr/share/aspell. 8. For each of the above wordlists: a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where $WORDLIST is the wordlist filename minus the .*wl.gz extension) b. Add a symlink /usr/lib/aspell/$WORDLIST.rws -> /var/lib/aspell/$WORDLIST.rws c. Append the $WORDLIST to the file "/usr/share/aspell/$DICT_LANG/.contents". The .contents file should contain one $WORDLIST per line. 9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the easiest way to do this is to build-depend on dictionaries-common-dev (>= 0.9.1) and run installdeb-aspell from debian/rules. For some examples, see aspell-en (for dictionaries based on ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for dictionaries based on plain wordlists). If the dictionary is packaged correctly, you should see something like: Setting up aspell-en (6.0-0-5) ... aspell-autobuildhash: processing: en [en-common] aspell-autobuildhash: processing: en [en-variant_0] aspell-autobuildhash: processing: en [en-variant_1] aspell-autobuildhash: processing: en [en-variant_2] aspell-autobuildhash: processing: en [en_CA-w_accents-only] aspell-autobuildhash: processing: en [en_CA-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only] aspell-autobuildhash: processing: en [en_US-w_accents-only] aspell-autobuildhash: processing: en [en_US-wo_accents-only] when installing. The dictionary should then work the same as before. Please send any questions to the [EMAIL PROTECTED] mailing list. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319668: aspell-sl: Needs repackaging for latest aspell
Package: aspell-sl Severity: grave Version: 0.60-2 Tags: sid As of the aspell 0.60.3-2 package, I changed the location in which aspell looks for dictionaries from /usr/lib/aspell-0.60 to /usr/lib/aspell (for support for autobuilding dictionary hashes). Obviously, this broke all existing dictionaries so I made it conflict with dictionaries providing aspell6-dictionary. Additionally, as of version 0.60.3-3 in conjunction with dictionaries-common >= 0.49.2, aspell now fully supports building dictionary hashes at install time. This provides two huge advantages over packaging the hashes in the .deb: 1. The dictionary packages may be Arch: all, which for some dictionaries provides a significant relief to the mirrors. 2. The hashes will be automatically rebuilt for new aspell versions if the dictionary format changes, eliminating the need to transition all dictionary packages. Consequently, this is now the preferred method for packaging aspell dictionaries. Packaging dictionaries for aspell >= 0.60.3-3 - [Old-style hashes (.rws files) in .deb] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell6a-dictionary" 2. Ensure dictionary files are installed to /usr/lib/aspell 3. Remove any dependency on libaspell15 (see #310590) or aspell-bin (which no longer exists). Instead depend on aspell (>= 0.60.3-2). [New-style autobuilt hashes] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell-dictionary" (no version in name). 2. Remove build-dependency on aspell(-bin) 3. Change Architecture to "all" 4. Add binary package dependency on "aspell (>= 0.60.3-3)" 5. Remove any relationship on libaspell15 or aspell-bin 6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where $DICT_LANG is the iso code for the dictionary, e.g. "en") 7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to /usr/share/aspell. 8. For each of the above wordlists: a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where $WORDLIST is the wordlist filename minus the .*wl.gz extension) b. Add a symlink /usr/lib/aspell/$WORDLIST.rws -> /var/lib/aspell/$WORDLIST.rws c. Append the $WORDLIST to the file "/usr/share/aspell/$DICT_LANG/.contents". The .contents file should contain one $WORDLIST per line. 9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the easiest way to do this is to build-depend on dictionaries-common-dev (>= 0.9.1) and run installdeb-aspell from debian/rules. For some examples, see aspell-en (for dictionaries based on ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for dictionaries based on plain wordlists). If the dictionary is packaged correctly, you should see something like: Setting up aspell-en (6.0-0-5) ... aspell-autobuildhash: processing: en [en-common] aspell-autobuildhash: processing: en [en-variant_0] aspell-autobuildhash: processing: en [en-variant_1] aspell-autobuildhash: processing: en [en-variant_2] aspell-autobuildhash: processing: en [en_CA-w_accents-only] aspell-autobuildhash: processing: en [en_CA-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only] aspell-autobuildhash: processing: en [en_US-w_accents-only] aspell-autobuildhash: processing: en [en_US-wo_accents-only] when installing. The dictionary should then work the same as before. Please send any questions to the [EMAIL PROTECTED] mailing list. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319660: katoob depends on libaspell15 which doesn't exists anymore
Mohammed Sameer <[EMAIL PROTECTED]> writes: > On Sat, Jul 23, 2005 at 01:00:31PM -0700, Brian Nelson wrote: >> tag 319660 pending >> thanks >> >> On Sat, Jul 23, 2005 at 08:28:59PM +0100, Baruch Even wrote: >> > katoob depends on libaspell15 which has been replaced with >> > libaspell15c2. The package needs to be rebuilt to correct this. >> >> Please don't. >> >> I (aspell maintainer) am undoing the libaspell15 transition, so this >> problem will go away as soon as ftp-master comes back up and I can >> upload a new package. >> > Allow me to ask a stupid question since I'm still new to all this: > Is this the gcc 4.0 transition ? Yes, but libaspell15 doesn't need to undergo the transition since it only publicly exports a C interface. Hence, I'm undoing the transition. See the discussion in this thread for more info: http://lists.debian.org/debian-devel/2005/07/msg01019.html -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319666: aspell-tl: Needs repackaging for latest aspell
Package: aspell-tl Severity: grave Version: 0.02-5 Tags: sid As of the aspell 0.60.3-2 package, I changed the location in which aspell looks for dictionaries from /usr/lib/aspell-0.60 to /usr/lib/aspell (for support for autobuilding dictionary hashes). Obviously, this broke all existing dictionaries so I made it conflict with dictionaries providing aspell6-dictionary. Additionally, as of version 0.60.3-3 in conjunction with dictionaries-common >= 0.49.2, aspell now fully supports building dictionary hashes at install time. This provides two huge advantages over packaging the hashes in the .deb: 1. The dictionary packages may be Arch: all, which for some dictionaries provides a significant relief to the mirrors. 2. The hashes will be automatically rebuilt for new aspell versions if the dictionary format changes, eliminating the need to transition all dictionary packages. Consequently, this is now the preferred method for packaging aspell dictionaries. Packaging dictionaries for aspell >= 0.60.3-3 - [Old-style hashes (.rws files) in .deb] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell6a-dictionary" 2. Ensure dictionary files are installed to /usr/lib/aspell 3. Remove any dependency on libaspell15 (see #310590) or aspell-bin (which no longer exists). Instead depend on aspell (>= 0.60.3-2). [New-style autobuilt hashes] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell-dictionary" (no version in name). 2. Remove build-dependency on aspell(-bin) 3. Change Architecture to "all" 4. Add binary package dependency on "aspell (>= 0.60.3-3)" 5. Remove any relationship on libaspell15 or aspell-bin 6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where $DICT_LANG is the iso code for the dictionary, e.g. "en") 7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to /usr/share/aspell. 8. For each of the above wordlists: a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where $WORDLIST is the wordlist filename minus the .*wl.gz extension) b. Add a symlink /usr/lib/aspell/$WORDLIST.rws -> /var/lib/aspell/$WORDLIST.rws c. Append the $WORDLIST to the file "/usr/share/aspell/$DICT_LANG/.contents". The .contents file should contain one $WORDLIST per line. 9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the easiest way to do this is to build-depend on dictionaries-common-dev (>= 0.9.1) and run installdeb-aspell from debian/rules. For some examples, see aspell-en (for dictionaries based on ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for dictionaries based on plain wordlists). If the dictionary is packaged correctly, you should see something like: Setting up aspell-en (6.0-0-5) ... aspell-autobuildhash: processing: en [en-common] aspell-autobuildhash: processing: en [en-variant_0] aspell-autobuildhash: processing: en [en-variant_1] aspell-autobuildhash: processing: en [en-variant_2] aspell-autobuildhash: processing: en [en_CA-w_accents-only] aspell-autobuildhash: processing: en [en_CA-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only] aspell-autobuildhash: processing: en [en_US-w_accents-only] aspell-autobuildhash: processing: en [en_US-wo_accents-only] when installing. The dictionary should then work the same as before. Please send any questions to the [EMAIL PROTECTED] mailing list. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319667: aspell-sv: Needs repackaging for latest aspell
Package: aspell-sv Severity: grave Version: 0.50-2-4 Tags: sid As of the aspell 0.60.3-2 package, I changed the location in which aspell looks for dictionaries from /usr/lib/aspell-0.60 to /usr/lib/aspell (for support for autobuilding dictionary hashes). Obviously, this broke all existing dictionaries so I made it conflict with dictionaries providing aspell6-dictionary. Additionally, as of version 0.60.3-3 in conjunction with dictionaries-common >= 0.49.2, aspell now fully supports building dictionary hashes at install time. This provides two huge advantages over packaging the hashes in the .deb: 1. The dictionary packages may be Arch: all, which for some dictionaries provides a significant relief to the mirrors. 2. The hashes will be automatically rebuilt for new aspell versions if the dictionary format changes, eliminating the need to transition all dictionary packages. Consequently, this is now the preferred method for packaging aspell dictionaries. Packaging dictionaries for aspell >= 0.60.3-3 - [Old-style hashes (.rws files) in .deb] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell6a-dictionary" 2. Ensure dictionary files are installed to /usr/lib/aspell 3. Remove any dependency on libaspell15 (see #310590) or aspell-bin (which no longer exists). Instead depend on aspell (>= 0.60.3-2). [New-style autobuilt hashes] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell-dictionary" (no version in name). 2. Remove build-dependency on aspell(-bin) 3. Change Architecture to "all" 4. Add binary package dependency on "aspell (>= 0.60.3-3)" 5. Remove any relationship on libaspell15 or aspell-bin 6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where $DICT_LANG is the iso code for the dictionary, e.g. "en") 7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to /usr/share/aspell. 8. For each of the above wordlists: a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where $WORDLIST is the wordlist filename minus the .*wl.gz extension) b. Add a symlink /usr/lib/aspell/$WORDLIST.rws -> /var/lib/aspell/$WORDLIST.rws c. Append the $WORDLIST to the file "/usr/share/aspell/$DICT_LANG/.contents". The .contents file should contain one $WORDLIST per line. 9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the easiest way to do this is to build-depend on dictionaries-common-dev (>= 0.9.1) and run installdeb-aspell from debian/rules. For some examples, see aspell-en (for dictionaries based on ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for dictionaries based on plain wordlists). If the dictionary is packaged correctly, you should see something like: Setting up aspell-en (6.0-0-5) ... aspell-autobuildhash: processing: en [en-common] aspell-autobuildhash: processing: en [en-variant_0] aspell-autobuildhash: processing: en [en-variant_1] aspell-autobuildhash: processing: en [en-variant_2] aspell-autobuildhash: processing: en [en_CA-w_accents-only] aspell-autobuildhash: processing: en [en_CA-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only] aspell-autobuildhash: processing: en [en_US-w_accents-only] aspell-autobuildhash: processing: en [en_US-wo_accents-only] when installing. The dictionary should then work the same as before. Please send any questions to the [EMAIL PROTECTED] mailing list. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319681: aspell-bn: Needs repackaging for latest aspell
Package: aspell-bn Severity: grave Version: 0.60.0.01.1.1-2 Tags: sid As of the aspell 0.60.3-2 package, I changed the location in which aspell looks for dictionaries from /usr/lib/aspell-0.60 to /usr/lib/aspell (for support for autobuilding dictionary hashes). Obviously, this broke all existing dictionaries so I made it conflict with dictionaries providing aspell6-dictionary. Additionally, as of version 0.60.3-3 in conjunction with dictionaries-common >= 0.49.2, aspell now fully supports building dictionary hashes at install time. This provides two huge advantages over packaging the hashes in the .deb: 1. The dictionary packages may be Arch: all, which for some dictionaries provides a significant relief to the mirrors. 2. The hashes will be automatically rebuilt for new aspell versions if the dictionary format changes, eliminating the need to transition all dictionary packages. Consequently, this is now the preferred method for packaging aspell dictionaries. Packaging dictionaries for aspell >= 0.60.3-3 - [Old-style hashes (.rws files) in .deb] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell6a-dictionary" 2. Ensure dictionary files are installed to /usr/lib/aspell 3. Remove any dependency on libaspell15 (see #310590) or aspell-bin (which no longer exists). Instead depend on aspell (>= 0.60.3-2). [New-style autobuilt hashes] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell-dictionary" (no version in name). 2. Remove build-dependency on aspell(-bin) 3. Change Architecture to "all" 4. Add binary package dependency on "aspell (>= 0.60.3-3)" 5. Remove any relationship on libaspell15 or aspell-bin 6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where $DICT_LANG is the iso code for the dictionary, e.g. "en") 7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to /usr/share/aspell. 8. For each of the above wordlists: a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where $WORDLIST is the wordlist filename minus the .*wl.gz extension) b. Add a symlink /usr/lib/aspell/$WORDLIST.rws -> /var/lib/aspell/$WORDLIST.rws c. Append the $WORDLIST to the file "/usr/share/aspell/$DICT_LANG/.contents". The .contents file should contain one $WORDLIST per line. 9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the easiest way to do this is to build-depend on dictionaries-common-dev (>= 0.9.1) and run installdeb-aspell from debian/rules. For some examples, see aspell-en (for dictionaries based on ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for dictionaries based on plain wordlists). If the dictionary is packaged correctly, you should see something like: Setting up aspell-en (6.0-0-5) ... aspell-autobuildhash: processing: en [en-common] aspell-autobuildhash: processing: en [en-variant_0] aspell-autobuildhash: processing: en [en-variant_1] aspell-autobuildhash: processing: en [en-variant_2] aspell-autobuildhash: processing: en [en_CA-w_accents-only] aspell-autobuildhash: processing: en [en_CA-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only] aspell-autobuildhash: processing: en [en_US-w_accents-only] aspell-autobuildhash: processing: en [en_US-wo_accents-only] when installing. The dictionary should then work the same as before. Please send any questions to the [EMAIL PROTECTED] mailing list. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319680: aspell-ca: Please autobuild dictionary hash at install time
Package: aspell-ca Severity: wishlist As of aspell >= 0.60.3-3 in conjunction with dictionaries-common >= 0.49.2, aspell now fully supports building dictionary hashes at install time. This provides two huge advantages over packaging the hashes in the .deb: 1. The dictionary packages may be Arch: all, which for some dictionaries provides a significant relief to the mirrors. 2. The hashes will be automatically rebuilt for new aspell versions if the dictionary format changes, eliminating the need to transition all dictionary packages. Consequently, this is now the preferred method for packaging aspell dictionaries. Packaging autobuilt dictionaries for aspell >= 0.60.3-3 - 1. Change "Provides: aspell6-dictionary" to "Provides: aspell-dictionary" (no version in name). 2. Remove build-dependency on aspell(-bin) 3. Change Architecture to "all" 4. Add binary package dependency on "aspell (>= 0.60.3-3)" 5. Remove any relationship on libaspell15 or aspell-bin 6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where $DICT_LANG is the iso code for the dictionary, e.g. "en") 7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to /usr/share/aspell. 8. For each of the above wordlists: a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where $WORDLIST is the wordlist filename minus the .*wl.gz extension) b. Add a symlink /usr/lib/aspell/$WORDLIST.rws -> /var/lib/aspell/$WORDLIST.rws c. Append the $WORDLIST to the file "/usr/share/aspell/$DICT_LANG/.contents". The .contents file should contain one $WORDLIST per line. 9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the easiest way to do this is to build-depend on dictionaries-common-dev (>= 0.9.1) and run installdeb-aspell from debian/rules. For some examples, see aspell-en (for dictionaries based on ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for dictionaries based on plain wordlists). If the dictionary is packaged correctly, you should see something like: Setting up aspell-en (6.0-0-5) ... aspell-autobuildhash: processing: en [en-common] aspell-autobuildhash: processing: en [en-variant_0] aspell-autobuildhash: processing: en [en-variant_1] aspell-autobuildhash: processing: en [en-variant_2] aspell-autobuildhash: processing: en [en_CA-w_accents-only] aspell-autobuildhash: processing: en [en_CA-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only] aspell-autobuildhash: processing: en [en_US-w_accents-only] aspell-autobuildhash: processing: en [en_US-wo_accents-only] when installing. The dictionary should then work the same as before. Please send any questions to the [EMAIL PROTECTED] mailing list. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319672: aspell-it: Needs repackaging for latest aspell
Package: aspell-it Severity: grave Version: 0.60-2 Tags: sid As of the aspell 0.60.3-2 package, I changed the location in which aspell looks for dictionaries from /usr/lib/aspell-0.60 to /usr/lib/aspell (for support for autobuilding dictionary hashes). Obviously, this broke all existing dictionaries so I made it conflict with dictionaries providing aspell6-dictionary. Additionally, as of version 0.60.3-3 in conjunction with dictionaries-common >= 0.49.2, aspell now fully supports building dictionary hashes at install time. This provides two huge advantages over packaging the hashes in the .deb: 1. The dictionary packages may be Arch: all, which for some dictionaries provides a significant relief to the mirrors. 2. The hashes will be automatically rebuilt for new aspell versions if the dictionary format changes, eliminating the need to transition all dictionary packages. Consequently, this is now the preferred method for packaging aspell dictionaries. Packaging dictionaries for aspell >= 0.60.3-3 - [Old-style hashes (.rws files) in .deb] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell6a-dictionary" 2. Ensure dictionary files are installed to /usr/lib/aspell 3. Remove any dependency on libaspell15 (see #310590) or aspell-bin (which no longer exists). Instead depend on aspell (>= 0.60.3-2). [New-style autobuilt hashes] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell-dictionary" (no version in name). 2. Remove build-dependency on aspell(-bin) 3. Change Architecture to "all" 4. Add binary package dependency on "aspell (>= 0.60.3-3)" 5. Remove any relationship on libaspell15 or aspell-bin 6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where $DICT_LANG is the iso code for the dictionary, e.g. "en") 7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to /usr/share/aspell. 8. For each of the above wordlists: a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where $WORDLIST is the wordlist filename minus the .*wl.gz extension) b. Add a symlink /usr/lib/aspell/$WORDLIST.rws -> /var/lib/aspell/$WORDLIST.rws c. Append the $WORDLIST to the file "/usr/share/aspell/$DICT_LANG/.contents". The .contents file should contain one $WORDLIST per line. 9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the easiest way to do this is to build-depend on dictionaries-common-dev (>= 0.9.1) and run installdeb-aspell from debian/rules. For some examples, see aspell-en (for dictionaries based on ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for dictionaries based on plain wordlists). If the dictionary is packaged correctly, you should see something like: Setting up aspell-en (6.0-0-5) ... aspell-autobuildhash: processing: en [en-common] aspell-autobuildhash: processing: en [en-variant_0] aspell-autobuildhash: processing: en [en-variant_1] aspell-autobuildhash: processing: en [en-variant_2] aspell-autobuildhash: processing: en [en_CA-w_accents-only] aspell-autobuildhash: processing: en [en_CA-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only] aspell-autobuildhash: processing: en [en_US-w_accents-only] aspell-autobuildhash: processing: en [en_US-wo_accents-only] when installing. The dictionary should then work the same as before. Please send any questions to the [EMAIL PROTECTED] mailing list. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319673: aspell-fo: Needs repackaging for latest aspell
Package: aspell-fo Severity: grave Version: 0.2.16-1.1 Tags: sid As of the aspell 0.60.3-2 package, I changed the location in which aspell looks for dictionaries from /usr/lib/aspell-0.60 to /usr/lib/aspell (for support for autobuilding dictionary hashes). Obviously, this broke all existing dictionaries so I made it conflict with dictionaries providing aspell6-dictionary. Additionally, as of version 0.60.3-3 in conjunction with dictionaries-common >= 0.49.2, aspell now fully supports building dictionary hashes at install time. This provides two huge advantages over packaging the hashes in the .deb: 1. The dictionary packages may be Arch: all, which for some dictionaries provides a significant relief to the mirrors. 2. The hashes will be automatically rebuilt for new aspell versions if the dictionary format changes, eliminating the need to transition all dictionary packages. Consequently, this is now the preferred method for packaging aspell dictionaries. Packaging dictionaries for aspell >= 0.60.3-3 - [Old-style hashes (.rws files) in .deb] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell6a-dictionary" 2. Ensure dictionary files are installed to /usr/lib/aspell 3. Remove any dependency on libaspell15 (see #310590) or aspell-bin (which no longer exists). Instead depend on aspell (>= 0.60.3-2). [New-style autobuilt hashes] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell-dictionary" (no version in name). 2. Remove build-dependency on aspell(-bin) 3. Change Architecture to "all" 4. Add binary package dependency on "aspell (>= 0.60.3-3)" 5. Remove any relationship on libaspell15 or aspell-bin 6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where $DICT_LANG is the iso code for the dictionary, e.g. "en") 7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to /usr/share/aspell. 8. For each of the above wordlists: a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where $WORDLIST is the wordlist filename minus the .*wl.gz extension) b. Add a symlink /usr/lib/aspell/$WORDLIST.rws -> /var/lib/aspell/$WORDLIST.rws c. Append the $WORDLIST to the file "/usr/share/aspell/$DICT_LANG/.contents". The .contents file should contain one $WORDLIST per line. 9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the easiest way to do this is to build-depend on dictionaries-common-dev (>= 0.9.1) and run installdeb-aspell from debian/rules. For some examples, see aspell-en (for dictionaries based on ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for dictionaries based on plain wordlists). If the dictionary is packaged correctly, you should see something like: Setting up aspell-en (6.0-0-5) ... aspell-autobuildhash: processing: en [en-common] aspell-autobuildhash: processing: en [en-variant_0] aspell-autobuildhash: processing: en [en-variant_1] aspell-autobuildhash: processing: en [en-variant_2] aspell-autobuildhash: processing: en [en_CA-w_accents-only] aspell-autobuildhash: processing: en [en_CA-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only] aspell-autobuildhash: processing: en [en_US-w_accents-only] aspell-autobuildhash: processing: en [en_US-wo_accents-only] when installing. The dictionary should then work the same as before. Please send any questions to the [EMAIL PROTECTED] mailing list. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319669: aspell-pt-br: Needs repackaging for latest aspell
Package: aspell-pt-br Severity: grave Version: 2.4.really.3.0.beta4-9 Tags: sid As of the aspell 0.60.3-2 package, I changed the location in which aspell looks for dictionaries from /usr/lib/aspell-0.60 to /usr/lib/aspell (for support for autobuilding dictionary hashes). Obviously, this broke all existing dictionaries so I made it conflict with dictionaries providing aspell6-dictionary. Additionally, as of version 0.60.3-3 in conjunction with dictionaries-common >= 0.49.2, aspell now fully supports building dictionary hashes at install time. This provides two huge advantages over packaging the hashes in the .deb: 1. The dictionary packages may be Arch: all, which for some dictionaries provides a significant relief to the mirrors. 2. The hashes will be automatically rebuilt for new aspell versions if the dictionary format changes, eliminating the need to transition all dictionary packages. Consequently, this is now the preferred method for packaging aspell dictionaries. Packaging dictionaries for aspell >= 0.60.3-3 - [Old-style hashes (.rws files) in .deb] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell6a-dictionary" 2. Ensure dictionary files are installed to /usr/lib/aspell 3. Remove any dependency on libaspell15 (see #310590) or aspell-bin (which no longer exists). Instead depend on aspell (>= 0.60.3-2). [New-style autobuilt hashes] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell-dictionary" (no version in name). 2. Remove build-dependency on aspell(-bin) 3. Change Architecture to "all" 4. Add binary package dependency on "aspell (>= 0.60.3-3)" 5. Remove any relationship on libaspell15 or aspell-bin 6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where $DICT_LANG is the iso code for the dictionary, e.g. "en") 7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to /usr/share/aspell. 8. For each of the above wordlists: a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where $WORDLIST is the wordlist filename minus the .*wl.gz extension) b. Add a symlink /usr/lib/aspell/$WORDLIST.rws -> /var/lib/aspell/$WORDLIST.rws c. Append the $WORDLIST to the file "/usr/share/aspell/$DICT_LANG/.contents". The .contents file should contain one $WORDLIST per line. 9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the easiest way to do this is to build-depend on dictionaries-common-dev (>= 0.9.1) and run installdeb-aspell from debian/rules. For some examples, see aspell-en (for dictionaries based on ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for dictionaries based on plain wordlists). If the dictionary is packaged correctly, you should see something like: Setting up aspell-en (6.0-0-5) ... aspell-autobuildhash: processing: en [en-common] aspell-autobuildhash: processing: en [en-variant_0] aspell-autobuildhash: processing: en [en-variant_1] aspell-autobuildhash: processing: en [en-variant_2] aspell-autobuildhash: processing: en [en_CA-w_accents-only] aspell-autobuildhash: processing: en [en_CA-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only] aspell-autobuildhash: processing: en [en_US-w_accents-only] aspell-autobuildhash: processing: en [en_US-wo_accents-only] when installing. The dictionary should then work the same as before. Please send any questions to the [EMAIL PROTECTED] mailing list. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318815: Needs repackaging for latest aspell
retitle 318815 Needs repackaging for latest aspell severity 318815 grave tag 318815 sid thanks Here's some additional information regarding the aspell changes: As of the aspell 0.60.3-2 package, I changed the location in which aspell looks for dictionaries from /usr/lib/aspell-0.60 to /usr/lib/aspell (for support for autobuilding dictionary hashes). Obviously, this broke all existing dictionaries so I made it conflict with dictionaries providing aspell6-dictionary. Additionally, as of version 0.60.3-3 in conjunction with dictionaries-common >= 0.49.2, aspell now fully supports building dictionary hashes at install time. This provides two huge advantages over packaging the hashes in the .deb: 1. The dictionary packages may be Arch: all, which for some dictionaries provides a significant relief to the mirrors. 2. The hashes will be automatically rebuilt for new aspell versions if the dictionary format changes, eliminating the need to transition all dictionary packages. Consequently, this is now the preferred method for packaging aspell dictionaries. Packaging dictionaries for aspell >= 0.60.3-3 - [Old-style hashes (.rws files) in .deb] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell6a-dictionary" 2. Ensure dictionary files are installed to /usr/lib/aspell 3. Remove any dependency on libaspell15 (see #310590) or aspell-bin (which no longer exists). Instead depend on aspell (>= 0.60.3-2). [New-style autobuilt hashes] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell-dictionary" (no version in name). 2. Remove build-dependency on aspell(-bin) 3. Change Architecture to "all" 4. Add binary package dependency on "aspell (>= 0.60.3-3)" 5. Remove any relationship on libaspell15 or aspell-bin 6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where $DICT_LANG is the iso code for the dictionary, e.g. "en") 7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to /usr/share/aspell. 8. For each of the above wordlists: a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where $WORDLIST is the wordlist filename minus the .*wl.gz extension) b. Add a symlink /usr/lib/aspell/$WORDLIST.rws -> /var/lib/aspell/$WORDLIST.rws c. Append the $WORDLIST to the file "/usr/share/aspell/$DICT_LANG/.contents". The .contents file should contain one $WORDLIST per line. 9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the easiest way to do this is to build-depend on dictionaries-common-dev (>= 0.9.1) and run installdeb-aspell from debian/rules. For some examples, see aspell-en (for dictionaries based on ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for dictionaries based on plain wordlists). If the dictionary is packaged correctly, you should see something like: Setting up aspell-en (6.0-0-5) ... aspell-autobuildhash: processing: en [en-common] aspell-autobuildhash: processing: en [en-variant_0] aspell-autobuildhash: processing: en [en-variant_1] aspell-autobuildhash: processing: en [en-variant_2] aspell-autobuildhash: processing: en [en_CA-w_accents-only] aspell-autobuildhash: processing: en [en_CA-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only] aspell-autobuildhash: processing: en [en_US-w_accents-only] aspell-autobuildhash: processing: en [en_US-wo_accents-only] when installing. The dictionary should then work the same as before. Please send any questions to the [EMAIL PROTECTED] mailing list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319677: aspell-pl: Please autobuild dictionary hash at install time
Package: aspell-pl Severity: wishlist As of aspell >= 0.60.3-3 in conjunction with dictionaries-common >= 0.49.2, aspell now fully supports building dictionary hashes at install time. This provides two huge advantages over packaging the hashes in the .deb: 1. The dictionary packages may be Arch: all, which for some dictionaries provides a significant relief to the mirrors. 2. The hashes will be automatically rebuilt for new aspell versions if the dictionary format changes, eliminating the need to transition all dictionary packages. Consequently, this is now the preferred method for packaging aspell dictionaries. Packaging autobuilt dictionaries for aspell >= 0.60.3-3 - 1. Change "Provides: aspell6-dictionary" to "Provides: aspell-dictionary" (no version in name). 2. Remove build-dependency on aspell(-bin) 3. Change Architecture to "all" 4. Add binary package dependency on "aspell (>= 0.60.3-3)" 5. Remove any relationship on libaspell15 or aspell-bin 6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where $DICT_LANG is the iso code for the dictionary, e.g. "en") 7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to /usr/share/aspell. 8. For each of the above wordlists: a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where $WORDLIST is the wordlist filename minus the .*wl.gz extension) b. Add a symlink /usr/lib/aspell/$WORDLIST.rws -> /var/lib/aspell/$WORDLIST.rws c. Append the $WORDLIST to the file "/usr/share/aspell/$DICT_LANG/.contents". The .contents file should contain one $WORDLIST per line. 9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the easiest way to do this is to build-depend on dictionaries-common-dev (>= 0.9.1) and run installdeb-aspell from debian/rules. For some examples, see aspell-en (for dictionaries based on ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for dictionaries based on plain wordlists). If the dictionary is packaged correctly, you should see something like: Setting up aspell-en (6.0-0-5) ... aspell-autobuildhash: processing: en [en-common] aspell-autobuildhash: processing: en [en-variant_0] aspell-autobuildhash: processing: en [en-variant_1] aspell-autobuildhash: processing: en [en-variant_2] aspell-autobuildhash: processing: en [en_CA-w_accents-only] aspell-autobuildhash: processing: en [en_CA-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only] aspell-autobuildhash: processing: en [en_US-w_accents-only] aspell-autobuildhash: processing: en [en_US-wo_accents-only] when installing. The dictionary should then work the same as before. Please send any questions to the [EMAIL PROTECTED] mailing list. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319674: aspell-de-alt: Needs repackaging for latest aspell
Package: aspell-de-alt Severity: grave Version: 2.1-1-1 Tags: sid As of the aspell 0.60.3-2 package, I changed the location in which aspell looks for dictionaries from /usr/lib/aspell-0.60 to /usr/lib/aspell (for support for autobuilding dictionary hashes). Obviously, this broke all existing dictionaries so I made it conflict with dictionaries providing aspell6-dictionary. Additionally, as of version 0.60.3-3 in conjunction with dictionaries-common >= 0.49.2, aspell now fully supports building dictionary hashes at install time. This provides two huge advantages over packaging the hashes in the .deb: 1. The dictionary packages may be Arch: all, which for some dictionaries provides a significant relief to the mirrors. 2. The hashes will be automatically rebuilt for new aspell versions if the dictionary format changes, eliminating the need to transition all dictionary packages. Consequently, this is now the preferred method for packaging aspell dictionaries. Packaging dictionaries for aspell >= 0.60.3-3 - [Old-style hashes (.rws files) in .deb] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell6a-dictionary" 2. Ensure dictionary files are installed to /usr/lib/aspell 3. Remove any dependency on libaspell15 (see #310590) or aspell-bin (which no longer exists). Instead depend on aspell (>= 0.60.3-2). [New-style autobuilt hashes] 1. Change "Provides: aspell6-dictionary" to "Provides: aspell-dictionary" (no version in name). 2. Remove build-dependency on aspell(-bin) 3. Change Architecture to "all" 4. Add binary package dependency on "aspell (>= 0.60.3-3)" 5. Remove any relationship on libaspell15 or aspell-bin 6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where $DICT_LANG is the iso code for the dictionary, e.g. "en") 7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to /usr/share/aspell. 8. For each of the above wordlists: a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where $WORDLIST is the wordlist filename minus the .*wl.gz extension) b. Add a symlink /usr/lib/aspell/$WORDLIST.rws -> /var/lib/aspell/$WORDLIST.rws c. Append the $WORDLIST to the file "/usr/share/aspell/$DICT_LANG/.contents". The .contents file should contain one $WORDLIST per line. 9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the easiest way to do this is to build-depend on dictionaries-common-dev (>= 0.9.1) and run installdeb-aspell from debian/rules. For some examples, see aspell-en (for dictionaries based on ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for dictionaries based on plain wordlists). If the dictionary is packaged correctly, you should see something like: Setting up aspell-en (6.0-0-5) ... aspell-autobuildhash: processing: en [en-common] aspell-autobuildhash: processing: en [en-variant_0] aspell-autobuildhash: processing: en [en-variant_1] aspell-autobuildhash: processing: en [en-variant_2] aspell-autobuildhash: processing: en [en_CA-w_accents-only] aspell-autobuildhash: processing: en [en_CA-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only] aspell-autobuildhash: processing: en [en_US-w_accents-only] aspell-autobuildhash: processing: en [en_US-wo_accents-only] when installing. The dictionary should then work the same as before. Please send any questions to the [EMAIL PROTECTED] mailing list. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319678: aspell-fr: Please autobuild dictionary hash at install time
Package: aspell-fr Severity: wishlist As of aspell >= 0.60.3-3 in conjunction with dictionaries-common >= 0.49.2, aspell now fully supports building dictionary hashes at install time. This provides two huge advantages over packaging the hashes in the .deb: 1. The dictionary packages may be Arch: all, which for some dictionaries provides a significant relief to the mirrors. 2. The hashes will be automatically rebuilt for new aspell versions if the dictionary format changes, eliminating the need to transition all dictionary packages. Consequently, this is now the preferred method for packaging aspell dictionaries. Packaging autobuilt dictionaries for aspell >= 0.60.3-3 - 1. Change "Provides: aspell6-dictionary" to "Provides: aspell-dictionary" (no version in name). 2. Remove build-dependency on aspell(-bin) 3. Change Architecture to "all" 4. Add binary package dependency on "aspell (>= 0.60.3-3)" 5. Remove any relationship on libaspell15 or aspell-bin 6. Package an empty file /var/lib/aspell/$DICT_LANG.compat (where $DICT_LANG is the iso code for the dictionary, e.g. "en") 7. Install the wordlists compressed as .mwl.gz, .wl.gz, or .cwl.gz to /usr/share/aspell. 8. For each of the above wordlists: a. Package an empty file /var/lib/aspell/$WORDLIST.rws (where $WORDLIST is the wordlist filename minus the .*wl.gz extension) b. Add a symlink /usr/lib/aspell/$WORDLIST.rws -> /var/lib/aspell/$WORDLIST.rws c. Append the $WORDLIST to the file "/usr/share/aspell/$DICT_LANG/.contents". The .contents file should contain one $WORDLIST per line. 9. Add a postinst call to "/usr/sbin/update-dictcommon-aspell"--the easiest way to do this is to build-depend on dictionaries-common-dev (>= 0.9.1) and run installdeb-aspell from debian/rules. For some examples, see aspell-en (for dictionaries based on ftp://ftp.gnu.org/gnu/aspell/dict tarballs) or aspell-es (for dictionaries based on plain wordlists). If the dictionary is packaged correctly, you should see something like: Setting up aspell-en (6.0-0-5) ... aspell-autobuildhash: processing: en [en-common] aspell-autobuildhash: processing: en [en-variant_0] aspell-autobuildhash: processing: en [en-variant_1] aspell-autobuildhash: processing: en [en-variant_2] aspell-autobuildhash: processing: en [en_CA-w_accents-only] aspell-autobuildhash: processing: en [en_CA-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ise-wo_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-w_accents-only] aspell-autobuildhash: processing: en [en_GB-ize-wo_accents-only] aspell-autobuildhash: processing: en [en_US-w_accents-only] aspell-autobuildhash: processing: en [en_US-wo_accents-only] when installing. The dictionary should then work the same as before. Please send any questions to the [EMAIL PROTECTED] mailing list. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301754: O: scoop
Package: wnpp Severity: normal I'm orphaning this package since I no longer use it. Also, as a complicated web app, I'm not even convinced it should be packaged. Given that scoop does not exist in stable and has a low popcon ranking, I have no qualms with removing it completely from the archive. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.11.3 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299738: aspell with curses breaks vim-gtk
reassign 299738 vim-gtk thanks On Wed, Mar 16, 2005 at 08:47:30AM -0800, Fernando Brucher wrote: > > > Using the non-curses version of aspell works fine. > > I didn't see a > > > command line switch in aspell to do this so I > > recompiled aspell > > > without curses. Maybe Debian could offer a > > non-curses package of > > > aspell. The problem might be vim's fault for not > > suporting curses > > > display correctly. But this quick fix works fine. > > > > I guess the problem is that aspell is linked against > > libncursesw, but > > (g)vim is linked against libncurses (no 'w'). I > > suppose I could provide > > an alternate aspell binary not linked against > > libncursesw, but that > > seems overly clunky. > > > > How are you using aspell in vim? vimspell? > > From the command line. In command mode I do the > following (I have a macro for it obviously): > > :w! > :!aspell -c --dont-backup "%" > :e! "%" Since this works fine in console vim, I'm guessing it's a bug in gvim's terminal emulation. Many other programs (e.g. mc) don't work gvim, but do work in vim. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301762: O: bbappconf -- Configuration tool for Blackbox application windows
Package: wnpp Severity: normal I intend to orphan the bbappconf package so I no longer use blackbox, and thus have no need for this package. The package description is: bbappconf makes it possible to set some options for the windows the blackbox window manager opens, such as: - workspace on which they should appear - titlebar display (visible or hidden) - stickiness - position and size of windows . Homepage: http://bbtools.windsofstorm.net/available.phtml#bbappconf -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.11.3 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#275451: Debian qwt 4.2.0 pending ftp-master processing
tag 275451 pending thanks Qwt 4.2.0 has been uploaded and is now in the NEW queue awaiting ftp-master processing. It should be available in the archive in 2-4 weeks. In the meantime, you can find it at http://people.debian.org/~pyro/pending/. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302283: ITP: sleepshell -- Sleep dummy shell
On Wed, Mar 30, 2005 at 10:19:12PM -0300, Leonardo Serra wrote: > Package name: sleepshell > Version : 0.0.1-1 > Upstream Author : Leonardo Serra <[EMAIL PROTECTED]> > URL : http://www.mariovaldez.net/software/sleepshell/ > License : GPL > Description : Sleep dummy shell > > This is a simple do-nothing, sleep-forever program that > can be used as a login shell to keep the connection open > but without interactive shell. > You can use it to create SSH accounts for users who will > only use them for SSH-tunneling; to create an encrypted > tunnel to your servers. Does Debian really need a package for a trivial <10 line C program? -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299725: aspell-0.60 + dictionaries-common: Can no longer customise case/non-case chars in Emacs
Agustin Martin <[EMAIL PROTECTED]> writes:
> In the meantime I noticed that aspell seems to accept encoding names in
> the emacs mime-charset format, (e.g., iso-8859-1 intead of iso8859-1),
> so another possibility is to try handling this from within ispell.el,
> in pseudo-code something like
>
> if (running_aspell){
>append_to_args("--encoding=" . ispell-coding-system)
> }
That intuitively seems like the best solution to me. You may want to
consult with aspell upstream (aspell-user@gnu.org) for another opinion
though, since I'm pretty retarded when it comes to language encoding
stuff.
--
Society is never going to make any progress until we all learn to
pretend to like each other.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#288202: Update on Bug 288202
On Mon, Jul 04, 2005 at 12:34:27AM -0400, Darren Albers wrote: > Update to this, I downloaded the src deb and tried building it, when I > used the configure option --enable-xine it segfaulted when I tried to > run it. When I used configure --enable-mplayer it built and ran fine > including closing properly! > > If I used configure with no options it will build, but no movies will play... > > If I build with GTK2 support and mplayer it works fine. > > If I build with gtk2 support and xine it shows the problem this bug > describes. So that seems to be the problem. > > So I guess maybe two packages are needed? One for Mplayer support and > another with xine support, if someone can get xine support working? Unfortunately mplayer is still not in Debian, so building pornview with mplayer support is not an option. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
