Bug#203805: basilisk2: timing speeds are messed up in new version
Hi Paul, That's pretty fun to revive an 18 year old Debian bug! I did a triple take looking at the header. I don't think I even have the proper setup to validate this bug any more, so you're welcome to close it out. Thanks for readopting basiliskII! best, Josh On Sun, Jul 25, 2021 at 10:44 PM Paul Wise wrote: > On Fri, 01 Aug 2003 12:18:24 -0700 Joshua Kwan wrote: > > > I just upgraded basilisk2 from the last version (the one uploaded long > > ago), and now the emulator is extremely unstable. > > Since you reported this issue, basilisk2 was removed from Debian but > was then reintroduced to Debian, would you mind testing if this issue > is still present in the latest Debian package? > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise >
Bug#758745: ITP: python-pyvmomi -- Python bindings for the VMware vSphere Web Services SDK
Package: wnpp Severity: wishlist Owner: Joshua Kwan jo...@triplehelix.org X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-pyvmomi Version : 5.5.0-2014.1 Upstream Author : Shawn Hartsock hartso...@vmware.com * URL : https://github.com/vmware/pyvmomi * License : Apache Programming Lang: Python Description : Python bindings for the VMware vSphere Web Services SDK pyVmomi is the Python SDK for the VMware vSphere API that allows you to automate actions on VMware ESX, ESXi, and vCenter servers. I open sourced this package during my time at VMware and am now working with the current upstream maintainer to get a Debian package going. The upstream maintainer does not intend to be an uploader at least for now. Thanks! -Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#256446: PuTTY/pterm and UTF-8
I no longer use Debian on a daily basis (let alone pterm), so I can't really comment on whether it's fixed. Could someone check and close this bug so we can all go on with our lives? I do not even remember filing this bug, but I'm glad I sounded at least somewhat clever 9 years ago :) -Josh On Sat, May 25, 2013 at 8:43 PM, Thomas Dickey dic...@his.com wrote: On Sat, May 25, 2013 at 04:11:16PM -0400, Samuel Bronson wrote: Thomas Dickey dic...@radix.net writes: On Sun, Jul 25, 2004 at 05:17:42PM +0100, Robert de Bath wrote: If you want a UTF-8 terminfo for PuTTY, it's just like the non-UTF-8 one you're using except smacs and rmacs are null and acsc is the standard unicode conversion. OTOH, if ncurses requires an 8-bit acsc it's a one line change in PuTTY non-wide ncurses relies on the acsc, wide-curses has a kludge to recognize UTF-8 locales and an internal table for line-drawing characters. I don't suppose we could enable the kludge in the meantime by adding U8#1 to the putty terminfo? I'm getting really tired of this :-(. I made that change two years ago: # 2011-02-05 # * add U8 feature to denote entries for terminal emulators which do not # support VT100 SI/SO when processing UTF-8 encoding -TD # * add xterm-utf8 as a demo of the U8 feature -TD I see that it's gotten into Debian/testing during the past year. -- Thomas E. Dickey dic...@invisible-island.net http://invisible-island.net ftp://invisible-island.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlGhWs4ACgkQcCNT4PfkjttVFgCfdTP99r9LfHaJ89IxgmLRVbcm Zj4AnR4ELdcouW9FFGh1jpwB5g9n/024 =+34k -END PGP SIGNATURE-
Bug#622673: panic-action segfault involving _spoolss_EnumPrinters
Package: samba Version: 2:3.5.8~dfsg-1 I'm seeing a Samba panic-action a couple times a day, just starting recently. It appears to come from a computer running Windows 7. This backtrace was generated after I installed samba-dbg and restarted smbd but it doesn't look like any extra information was provided as a result. Like the other poster, the core was not present in the given directory after the crash occurred. [2011/04/13 11:26:51.160760, 0] lib/fault.c:46(fault_report) === [2011/04/13 11:26:51.160815, 0] lib/fault.c:47(fault_report) INTERNAL ERROR: Signal 11 in pid 10507 (3.5.8) Please read the Trouble-Shooting section of the Samba3-HOWTO [2011/04/13 11:26:51.160840, 0] lib/fault.c:49(fault_report) From: http://www.samba.org/samba/docs/Samba3-HOWTO.pdf [2011/04/13 11:26:51.160863, 0] lib/fault.c:50(fault_report) === [2011/04/13 11:26:51.160881, 0] lib/util.c:1465(smb_panic) PANIC (pid 10507): internal error [2011/04/13 11:26:51.163986, 0] lib/util.c:1569(log_stack_trace) BACKTRACE: 24 stack frames: #0 /usr/sbin/smbd(log_stack_trace+0x1a) [0x7f9ba54221fa] #1 /usr/sbin/smbd(smb_panic+0x1f) [0x7f9ba54222bf] #2 /usr/sbin/smbd(+0x377ae9) [0x7f9ba5411ae9] #3 /lib/libc.so.6(+0x321e0) [0x7f9ba24ce1e0] #4 /usr/sbin/smbd(_spoolss_EnumPrinters+0x54a) [0x7f9ba536443a] #5 /usr/sbin/smbd(+0x2e653c) [0x7f9ba538053c] #6 /usr/sbin/smbd(+0x3101ae) [0x7f9ba53aa1ae] #7 /usr/sbin/smbd(api_pipe_request+0x1a8) [0x7f9ba53af098] #8 /usr/sbin/smbd(np_write_send+0x174a) [0x7f9ba53a7c0a] #9 /usr/sbin/smbd(+0x118a59) [0x7f9ba51b2a59] #10 /usr/sbin/smbd(+0x118cd2) [0x7f9ba51b2cd2] #11 /usr/sbin/smbd(reply_trans+0x637) [0x7f9ba51b35c7] #12 /usr/sbin/smbd(+0x17a505) [0x7f9ba5214505] #13 /usr/sbin/smbd(+0x17a8a7) [0x7f9ba52148a7] #14 /usr/sbin/smbd(+0x17ad00) [0x7f9ba5214d00] #15 /usr/sbin/smbd(run_events+0x1eb) [0x7f9ba543186b] #16 /usr/sbin/smbd(smbd_process+0x7f5) [0x7f9ba5216305] #17 /usr/sbin/smbd(+0x682bfa) [0x7f9ba571cbfa] #18 /usr/sbin/smbd(run_events+0x1eb) [0x7f9ba543186b] #19 /usr/sbin/smbd(+0x397a63) [0x7f9ba5431a63] #20 /usr/sbin/smbd(_tevent_loop_once+0x90) [0x7f9ba5432500] #21 /usr/sbin/smbd(main+0xad3) [0x7f9ba571d893] #22 /lib/libc.so.6(__libc_start_main+0xfd) [0x7f9ba24bac4d] #23 /usr/sbin/smbd(+0xfd2d9) [0x7f9ba51972d9] [2011/04/13 11:26:51.164095, 0] lib/util.c:1470(smb_panic) smb_panic(): calling panic action [/usr/share/samba/panic-action 10507] [2011/04/13 11:26:52.211609, 0] lib/util.c:1478(smb_panic) smb_panic(): action returned status 0 [2011/04/13 11:26:52.211680, 0] lib/fault.c:326(dump_core) dumping core in /var/log/samba/cores/smbd -- Joshua Kwan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577871: abiword: Intent to NMU (FTBFS: configure: error: C compiler cannot create executables)
On Wed, May 05, 2010 at 01:22:59AM +0300, Jari Aalto wrote: Let me know if this bug is already been worked on or if it's okay to NMU the package. In the NMU I'd also like to upgrade it to latest version 2.8.4 at the same time to get latest into the Debian. If Patrik is gone, I can give you my blessing as the previous maintainer of abiword... But I'm not sure if he's working on anything right now. -- Joshua Kwan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#243857: Patch has been available in Ubuntu
tags 243857 + patch thanks Hey, Looks like this bug hasn't seen action for quite a while. It seems like in the meantime, Ubuntu has fixed this bug. Check out this patch: http://launchpadlibrarian.net/18656164/cdrom-detect-better-flow.patch This code is in their current version of cdrom-detect and seems to work well in the exact same situation that d-i fails. Can we get this patch backported? I can do a NMU if there is no real maintainer willing to step up. Thanks! -- Joshua Kwan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#460390: Orphaned
retitle 460178 O: ytnef -- improved decoder for application/ms-tnef attachments retitle 460390 O: libytnef -- improved decoder for application/ms-tnef attachments thanks These packages have now been orphaned. -- Joshua Kwan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#485388: setting package to fortunes fortunes-off fortunes-min fortune-mod, tagging 476770, tagging 497060 ...
# Automatically generated email from bts, devscripts version 2.10.35lenny7 # via tagpending # # fortune-mod (1:1.99.1-4) unstable; urgency=low # # * Take bulk attribution/typo corrections from Simon Danner's git. Thanks so #much! Saves me some work for sure. #closes: #411907, #400232, #502483, #497057, #497060, #385408 #closes: #527198, #445470, #476770, #500282, #369662, #363095, #386503 #closes: #501748, #498932, #491815, #485388, #361896 # package fortunes fortunes-off fortunes-min fortune-mod tags 476770 + pending tags 497060 + pending tags 485388 + pending tags 400232 + pending tags 386503 + pending tags 385408 + pending tags 500282 + pending tags 497057 + pending tags 502483 + pending tags 527198 + pending tags 501748 + pending tags 445470 + pending tags 411907 + pending tags 498932 + pending tags 491815 + pending -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548365: Please make yourself maintainer
Package: abiword Hi Patrik, Please make yourself the maintainer of the abiword package. Neither Masayuki or I have been working on it in quite a while. Thanks and please close this bug on the next upload when this has been done. -- Joshua Kwan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548366: Please make yourself maintainer
Package: ircd-hybrid Hi Aurelien, Please feel free to remove me as Maintainer and take it on as your own package. I haven't worked on this package for quite a while. Thanks for the work you've been doing. You can close this bug out when you've made the change and the next upload. Best, -- Joshua Kwan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525826: flac maintenance RC bug
Hi Thomas, you're right - please do what you need to. I am too busy these days. -Josh On Wed, Jul 29, 2009 at 09:16:38AM +0200, Thomas Viehmann wrote: Hi Andres, given that Josh did not answer your mail[1] to #525826 about helping with flac and seems to be not too active (public lists seem to have last no posts later than August 2008) at the moment, I would suggest that the multimedia maintainers take over flac unless Josh objects in the next two weeks. I would suggest temporarily dropping Josh from the uploaders and adding him back when he returns to a more active role in maintaining flac in order to not split the maintainer housekeeping in too many steps if he has lost interest. Kind regards T. 1. http://bugs.debian.org/525826#17 -- Thomas Viehmann, http://thomas.viehmann.net/ -- Joshua Kwan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531477: libgksu2-0: Does not work when Defaults requiretty is in /etc/sudoers
Package: libgksu2-0 Version: 2.0.10-1 Severity: normal When /etc/sudoers has the Defaults requiretty setting enabled, it breaks Gksu because (obviously) sudo will not run if stdin is not a terminal. This setting is enabled by default on non-Debian platforms like Red Hat Enterprise Linux 5. According to Gustavo, we already have this handled for su because it has the same check, and instead of creating a pipe we use forkpty(). He says that code can be cloned to work for sudo as well. (The best idea is probably to just genericize the forkpty() code and have both gksu_su_fuller and gksu_sudo_fuller use it.) Thanks! -Josh (also jo...@triplehelix.org if you didn't notice already, but currently wearing my VMware hat ;)) -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libgksu2-0 depends on: ii gconf2 2.26.2-1 GNOME configuration database syste ii libatk1.0-01.26.0-1 The ATK accessibility toolkit ii libc6 2.9-13GNU C Library: Shared libraries ii libcairo2 1.8.6-2+b1The Cairo 2D vector graphics libra ii libfontconfig1 2.6.0-3 generic font configuration library ii libfreetype6 2.3.9-5 FreeType 2 font engine, shared lib ii libgconf2-42.26.2-1 GNOME configuration database syste ii libglade2-01:2.6.4-1 library to load .glade files at ru ii libglib2.0-0 2.20.1-2 The GLib library of C routines ii libgnome-keyring0 2.26.1-1 GNOME keyring services library ii libgtk2.0-02.16.1-2 The GTK+ graphical user interface ii libgtop2-7 2.24.3-1 gtop system monitoring library ii libpango1.0-0 1.24.2-1 Layout and rendering of internatio ii libstartup-notificatio 0.10-1library for program launch feedbac ii libxml22.7.3.dfsg-1 GNOME XML library ii xauth 1:1.0.3-2 X authentication utility ii xbase-clients 1:7.4+1 miscellaneous X clients - metapack ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime Versions of packages libgksu2-0 recommends: ii sudo 1.7.0-1Provide limited super user privile libgksu2-0 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#496217: mt-daapd: web interface still refusing valid credentials
I'd like to chime and mention that I have orphaned the package on wnpp
because I can't deal with this shit anymore. Especially since I had
nothing to do with this security update, i have no motivation to deal
with it (in addition to being frustrated with mt-daapd's robustness in
general.)
So if anyone's up to it, upload away.
-Josh
On Fri, Sep 05, 2008 at 10:21:27AM +0200, Martijn Plak wrote:
My patch was for the r1376 debian package, not r1696. To be precise, it
fixed an incomplete backport of a security fix. For those sources, it is
correct.
In r1376, ws_decodepassword returns 0 on success. ws_decodepassword was
changed to return TRUE in r1622.
If the debian package is upgraded to newer upstream sources, every patch
needs to be reconsidered. Especially for backported changes, it is not
surprising the patch is not needed anymore. Which seems to be the case
here.
Package: mt-daapd
Version: 0.9~r1696-1.4
Followup-For: Bug #496217
Julien BLACHE [EMAIL PROTECTED] wrote:
Even in 0.9~r1696-1.4 still refuses valid credentials for the web
interface. I haven't been able to track that down further.
The solution proposed by Martijn Plak is not correct, if you look at
the source of webserver.c, the method ws_decodepassword returns
TRUE if the decoding of the base64 header succeeded. However, TRUE is
defined as 1, not 0. So, a better solution would be:
+ if((auth) (TRUE == ws_decodepassword(auth,username, password))) {
Hope it helps,
Jan Willem
--
Joshua Kwan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496243: O: mt-daapd -- iTunes-compatible DAAP server
Package: wnpp Severity: normal I intend to orphan the mt-daapd package. The package description is: mt-daapd is a DAAP server that works with most POSIX compatible operating systems. It allows you to share your music collection over the local network using the same protocol iTunes uses, so real iTunes users may peruse your music. . Moreover, if your music is in more esoteric formats like FLAC, Ogg Vorbis, or Musepack, these can be converted on the fly to different formats (usually WAV), so that your entire music collection can be listened to by normal iTunes clients. . It also features a web interface that can be used to control components of the server, trigger database updates, and create playlists. I don't have the energy to deal with security issues that constantly keep cropping up in mt-daapd. Additionally, the etch update seems to have broken a *lot* of things, even though I had nothing to do with it. Please, please, take it off my hands. -Josh -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495738: abiword: Garbled text
severity 495738 normal thanks I haven't seen this and many people that use abiword obviously haven't either or else I would have been inundated with bug reports. I suggest you try creating a new user and see if the problem recurs just in case it has something to do with fontconfig, or your particular window manager setup. For now I'm setting the severity to normal. If you can give a top-to-bottom method for reproducing this bug (considering I can't right now), I will look in to it and adjust the severity again as required. -Josh On Tue, Aug 19, 2008 at 11:54:36PM -0700, BlueSloth wrote: Package: abiword Version: 2.6.4-4 Severity: grave Justification: renders package unusable All the text in a document is garbled and unreadable. Hmm.. upon further inspection it looks like it's not so much garbled as mashed together. Abiword appears to expect the characters to render about 5 times smaller than they actually are, and so isn't giving them enough space. The cursor is very small, and only the lower part of a character disappears when I delete it. Changing the font, font size, zoom level, and paragraph spacing settings don't help. The sample text in the font selection dialog renders perfectly. The text in the Paragraph dialog is smushed together vertically, but not horizontally. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493997: abiword fails to use default web browser in gnome or xfce
libxrender1 1:0.9.4-2 X Rendering Extension client libra ii zlib1g1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages abiword recommends: ii abiword-help 2.6.4-4online help for AbiWord ii abiword-plugin-grammar2.6.4-4grammar checking plugin for AbiWor ii abiword-plugin-mathview 2.6.4-4equation editor plugin for AbiWord ii aspell-en [aspell-dictionary] 6.0-0-5.1 English dictionary for GNU Aspell ii poppler-utils 0.8.4-1.1 PDF utilitites (based on libpopple Versions of packages abiword suggests: pn abiword-plugin-gofficenone (no description available) -- no debconf information -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493997: sensible-browser
On Wed, Aug 20, 2008 at 08:44:28PM +0100, Julian Hughes wrote: *All* applications open links in epiphany as I want, except abiword which opens in elinks if installed or not at all if elinks is not installed. All other applications' help files open normally whether they are Gnome, Xfce or DE independent applications. Only Abiword is doing this. Well, I am quite sure AbiWord respects $BROWSER, so it may well be an issue with sensible-browser *as it pertains to AbiWord*. Please at least let me know if changing the BROWSER value to a real browser like Epiphany works. Suggesting I use Firefox doesn't appear to be a constructive or useful comment to me. I use Epiphany and also have Iceweasel installed. I prefer Epiphany, this is the browser I choose as default in Gnome or Xfce. *Every* application I use respects this with the exception of Abiword. I have no idea what else I might be expected to do but at the moment all Abiword's help and update-checker facilities are unavailable to me. ok, set BROWSER=epiphany then. I was merely suggesting a generic course of action. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493565: Not an AbiWord bug
reassign 493565 libpango1.0-0 thanks Dear Pango Maintainers, This was filed against abiword but I'm pretty sure it is a pango bug. I installed libpango1.0-0-dbg and have gotten some debug output.. (abiword:5502): Pango-WARNING **: shaping failure, expect ugly output. shape-engine='BasicEngineFc', font='Standard Symbols L 32', text='' Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f6aee92c780 (LWP 5502)] pango_shape (text=0x28523e0 , length=1, analysis=0x2886910, glyphs=0x2885ba0) at /build/buildd/pango1.0-1.20.5/pango/shape.c:120 120 last_cluster = glyphs-log_clusters[0] - 1; (gdb) p glyphs $1 = (PangoGlyphString *) 0x2885ba0 (gdb) p glyphs-log_clusters $2 = (gint *) 0x0 -- here is the problem (gdb) bt #0 pango_shape (text=0x28523e0 , length=1, analysis=0x2886910, glyphs=0x2885ba0) at /build/buildd/pango1.0-1.20.5/pango/shape.c:120 #1 0x0064cd8b in GR_UnixPangoGraphics::measureString () #2 0x0063e7d2 in GR_Graphics::getMaxCharacterDimension () #3 0x00799d04 in XAP_Draw_Symbol::setFontToGC () #4 0x0079219b in XAP_UnixDialog_Insert_Symbol::runModeless () #5 0x00540ad4 in ap_EditMethods::insSymbol () #6 0x0065200b in EV_Menu::invokeMenuMethod () #7 0x0065539f in EV_UnixMenu::menuEvent () #8 0x7f6aec0cdebd in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #9 0x7f6aec0e0c2d in ?? () from /usr/lib/libgobject-2.0.so.0 #10 0x7f6aec0e2116 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #11 0x7f6aec0e2623 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #12 0x7f6aed64e9ab in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0 #13 0x7f6aed5421ed in gtk_menu_shell_activate_item () from /usr/lib/libgtk-x11-2.0.so.0 #14 0x7f6aed543ec5 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #15 0x7f6aed535688 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #16 0x7f6aec0cdebd in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #17 0x7f6aec0e08fc in ?? () from /usr/lib/libgobject-2.0.so.0 #18 0x7f6aec0e1f99 in g_signal_emit_valist () ---Type return to continue, or q return to quit--- from /usr/lib/libgobject-2.0.so.0 #19 0x7f6aec0e2623 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #20 0x7f6aed64a19e in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #21 0x7f6aed52e203 in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 #22 0x7f6aed52f24b in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #23 0x7f6aece4ef8c in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #24 0x7f6aeba31892 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #25 0x7f6aeba3501d in ?? () from /usr/lib/libglib-2.0.so.0 #26 0x7f6aeba3554d in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #27 0x7f6aed52f667 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #28 0x0052355d in AP_UnixApp::main () #29 0x7f6ae846e1a6 in __libc_start_main () from /lib/libc.so.6 #30 0x00520eb9 in _start () If you feel I've given you this bug in error, give it back to me, and if you have any suggestions for what upstream should do to fix it I'll gladly include that in my reply to them too. Thanks.. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493565: abiword crashes on insert symbol
forwarded 493565 http://bugzilla.abisource.com/show_bug.cgi?id=11731 tags 493565 confirmed thanks Nice catch. Forwarded upstream. Hoping for a quick turnaround from them. On Sun, Aug 03, 2008 at 11:57:55AM +0200, Michael Burschik wrote: Whenever I select insert symbol from the abiword menu, the program crashes with the following warning: (abiword:4002): Pango-WARNING **: shaping failure, expect ugly output. shape-engine='BasicEngineFc', font='Standard Symbols L 32', text='' -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492211: fixed in r24545
On Thu, Jul 31, 2008 at 09:57:09AM +0200, Eike Nicklas wrote: This bug has been fixed in upstream revision 24545: http://www.abisource.com/viewvc?view=revrevision=24545 Yup! I prodded upstream, I was there when the fix happened. thanks for your help though. I am already asking RMs to get the ball rolling for me on another upload.. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492211: severity
severity 492211 serious thanks On Sat, Jul 26, 2008 at 02:31:50AM +0300, Mert Dirik wrote: I can't say I know these procedures very well, but I think making this bug's severity RC makes it can be fixed for Lenny. Fair enough. Restoring original severity. I only changed the severity in fear of not having abiword 2.6 reach testing. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492211: abiword: Crashes switching back from print preview
severity 492211 important forwarded 492211 http://bugzilla.abisource.com/show_bug.cgi?id=11720 thanks Whoa there. That's a bad bug you found, but it doesn't make the WHOLE thing unusable. As you can see, it's been reported to upstream and it's being worked on. On Thu, Jul 24, 2008 at 04:38:52PM +0200, g.gragnani wrote: Package: abiword Version: 2.6.4-4 Severity: grave Justification: renders package unusable I can reproduce this: Select View - Normal Layout select File - Print Preview close the preview window Try to enter any char Crash!!! -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490414: setting package to abiword-plugin-goffice abiword-plugin-mathview abiword-common abiword-plugins abiword abiword-plugin-grammar abiword-help ...
# Automatically generated email from bts, devscripts version 2.10.33 # via tagpending # # abiword (2.6.4-1) unstable; urgency=low # # * Bug fixes from upstream: #- Print preview now matches onscreen layout more accurately. # closes: #336216 #- Font operations are all done using Pango now, so the XAP_UnixFont # crash should no longer occur. closes: #443048, #444957 #- Spellcheck button is no longer greyed out gratuitously. closes: #422520 #- !! and ?? in DejaVu Sans Mono seem to be correctly monospaced # now. closes: #470949 #- AbiWord can now import OpenWriter files without a MIME type. # closes: #376417 #- Build error affecting 2.4.6 was already fixed upstream, but thanks # to Peter Green for the patch and Lucas Nussbaum for the report. # closes: #490414 # package abiword-plugin-goffice abiword-plugin-mathview abiword-common abiword-plugins abiword abiword-plugin-grammar abiword-help tags 490414 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465318: Need the document
tags 465318 + moreinfo thanks Dan, Thanks for your bug report. Could you attach that document or another document that exhibits the same problem or I can't really do anything about this bug. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470949: setting package to abiword-plugin-goffice abiword-plugin-mathview abiword-common abiword abiword-plugin-grammar abiword-help ...
# Automatically generated email from bts, devscripts version 2.10.33 # via tagpending # # abiword (2.6.3-1) unstable; urgency=low # # * Bug fixes from upstream: #- Print preview now matches onscreen layout more accurately. # closes: #336216 #- Font operations are all done using Pango now, so the XAP_UnixFont # crash should no longer occur. closes: #443048, #444957 #- Spellcheck button is no longer greyed out gratuitously. closes: #422520 #- !! and ?? in DejaVu Sans Mono seem to be correctly monospaced # now. closes: #470949 # package abiword-plugin-goffice abiword-plugin-mathview abiword-common abiword abiword-plugin-grammar abiword-help tags 470949 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#276070: setting package to abiword-plugin-goffice abiword-plugin-mathview abiword-common abiword abiword-plugin-grammar abiword-help ...
# Automatically generated email from bts, devscripts version 2.10.33 # via tagpending # # abiword (2.6.3-1) unstable; urgency=low # # * Minor changes: #- Drop psiconv support overall to alleviate dependency bloat/package spam, # at the risk of offending the one guy who still has a Psion 5. #- Upgrade to debhelper 7 and Policy 3.8.0. #- Drop one of Ryan's Ubuntu patches by building abiword-2.6.pc in the # configure stage of debian/rules. Lose autoconf/automake build dep. #- Upgrade boost build-dependency to 1.35 to quell some apt-get insanity # while pbuilder satisfies the Build-Depends. #- Disable smooth scrolling by default with a patch. closes: #276070 # package abiword-plugin-goffice abiword-plugin-mathview abiword-common abiword abiword-plugin-grammar abiword-help tags 276070 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443048: setting package to abiword-plugin-goffice abiword-plugin-mathview abiword-common abiword abiword-plugin-grammar abiword-help ...
# Automatically generated email from bts, devscripts version 2.10.33 # via tagpending # # abiword (2.6.3-1) unstable; urgency=low # # * New upstream stable release, incorporating many build bits from Ryan #Pavlik. Thanks! (His Ubuntu changelogs follow this entry.) #closes: #473508, #488069 # * Bug fixes from upstream: #- Print preview now matches onscreen layout more accurately. # closes: #336216 #- Font operations are all done using Pango now, so the XAP_UnixFont # crash should no longer occur. closes: #443048, #444957 # package abiword-plugin-goffice abiword-plugin-mathview abiword-common abiword abiword-plugin-grammar abiword-help tags 336216 + pending tags 488069 + pending tags 473508 + pending tags 443048 + pending tags 444957 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336216: setting package to abiword-plugin-goffice abiword-plugin-mathview abiword-common abiword abiword-plugin-grammar abiword-help ...
# Automatically generated email from bts, devscripts version 2.10.33 # via tagpending # # abiword (2.6.3-1) unstable; urgency=low # # * New upstream stable release, incorporating many build bits from Ryan #Pavlik. Thanks! (His Ubuntu changelogs follow this entry.) #closes: #473508, #488069 # * Bug fixes from upstream: #- Print preview now matches onscreen layout more accurately. # closes: #336216 #- Font operations are all done using Pango now, so the XAP_UnixFont # crash should no longer occur. closes: #443048, #444957 # package abiword-plugin-goffice abiword-plugin-mathview abiword-common abiword abiword-plugin-grammar abiword-help tags 336216 + pending tags 473508 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490169: apt: undesired autoremove behavior
Package: apt Version: 0.7.14+b1 I recently installed the latest msttcorefonts, which is now a dummy package for the new name ttf-msttcorefonts-installer. I had previously installed msttcorefonts manually. Since msttcorefonts is now a dummy package, I removed it from my system. But because ttf-msttcorefonts-installer was installed as a dependency of msttcorefonts, apt now suggests it for autoremoval. I think this behavior is highly misleading. A potential solution would involve a package control field indicating the status of msttcorefonts as a dummy package for ttf-msttcorefonts-installer. That way, the manually installed state, true or false, could propagate to the new package. Obviously, this will happen consistently in the very common case of all dummy packages being used in Debian. Thoughts? -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309943: Seems to be working in 2.6.3
tag 309943 + unreproducible thanks Hi Kenneth, I can't reproduce this bug right now with the pending 2.6.3 build I have that is going to be uploaded to unstable soon. Not sure about 2.4.6 and I don't have the resources to download the package of that right now, but could you give it a try? If the crash is indeed related to ttftool as your log indicates, ttftool has been completely obsoleted since 2.4 series and the printing system has switched to the far more robust GNOME-Print. Please give that a try and I will close this bug within a week or so if I don't hear a response. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476241: intent to NMU
On Thu, Apr 17, 2008 at 09:16:02PM +0200, Nico Golde wrote: Hi, attached is a patch fixing this issue. It will be also archived on: http://people.debian.org/~nion/nmu-diff/mt-daapd-0.9~r1696-1.2_0.9~r1696-1.3.patch Kind regards Nico Go for it. I'm too busy with school... I'm on Low Threshold NMU anyway. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402104: This isn't the right solution
On Fri, Jan 11, 2008 at 07:27:49PM +0100, Javier Serrano Polo wrote: Since you're forcing me to repackage, could you please define appropriate for a package of this nature or tell me whether you knew about this gcc bug? I didn't know about it, but now I do. What are you repackaging? -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402104: This isn't the right solution
Hi Javier, The fix you propose isn't appropriate for a package of this nature. Let's wait until ia32-libs is fixed (bug #448537). -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460178: RFA: {lib,}ytnef, improved decoder for application/ms-tnef attachments
Package: wnpp Severity: normal Hi there. I'm looking for someone to adopt the ytnef family of packages. I personally don't have a use for this package anymore. It is useful when people who use Outlook send you attachments, but I've since converted everyone I care about to programs that speak MIME. There haven't been any upstream releases since I uploaded the package the first time, but there are a few things you can do, like make it easier for people to integrate this into their procmail filter. Here's the canned description: Yerase's TNEF Stream Reader allows you to decode application/ms-tnef e-mail attachments, which are usually entitled winmail.dat and are generally a file container format that is only readable by Microsoft Outlook. Some TNEF streams also include RTF-formatted data. . ytnef parses these streams into normal MIME attachments and RTF attachments that you can read from non-Outlook mail readers. . A convenience script is provided to allow users to transparently filter messages containing TNEF attachments into messages with proper attachments, via procmail. Feel free to go ahead and just hijack the package if you are interested. I will keep on maintaining it until then. -Josh -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460179: RFA: cuetools -- tools for manipulating CUE/TOC files
Package: wnpp Severity: normal I request an adopter for the cuetools package. The package description is: cuetools is a set of programs that are useful for manipulating CUE sheet (cue) files and Table of Contents (toc) files. CUE and TOC files are a way to represent the layout of a data or audio CD in a machine-readable ASCII format. The package includes these utilities: . - cueconvert: convert between CUE and TOC formats - cuebreakpoints: print the breakpoints from a CUE or TOC file - cueprint: print disc and track information for a CUE or TOC file . Probably the most popular use is to split a large audio file into many small files according to a CUE or TOC, for example: . cuebreakpoints disc.cue | shnsplit disc.wav It's a pretty easy package to maintain, but there are some interesting bugs on the BTS that I haven't ever had a chance to look at. It has a small base of users. You should adopt this if you are looking for a good first package as it's pretty easy to wrap your head around. -Josh -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460180: RFA: shntool -- multi-purpose tool for manipulating and analyzing WAV files
Package: wnpp Severity: normal I request an adopter for the shntool package. The package description is: shntool is a multi-purpose WAVE data processing and reporting utility. File formats are abstracted from its core, so it can process any file that contains WAVE data, compressed or not - provided there exists a format module to handle that particular file type. . shntool has native support for .wav files. If you want it to work with other formats, you must have the appropriate helper program installed. Some of these helper programs - notably for Monkey's Audio, wavpack, LPAC, OptimFROG - are not (yet) available in Debian. . With the helper programs mentioned above, shntool is able to convert files between all supported formats. It's a pretty easy package to maintain and it doesn't seem like a lot of people use it, but it is pretty useful (Personally I use 'shntool len' the most out of any of the features.) Good if you're looking for a first package to maintain, it's pretty much straight up make/make install kind of stuff. -Josh -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460181: RFA: libmail-mboxparser-perl
Package: wnpp Severity: normal It's just a perl module that reads mboxes. How much simpler could you get? Adopt it! Here's the canned description. Description: Perl5 module for fast, object-oriented UNIX mailbox reading This Perl module attempts to provide a simplified access to standard UNIX-mailboxes (mboxes.) It offers only a subset of methods to get 'straight to the point'. More sophisticated things can still be done by invoking any method from MIME::Tools on the appropriate return values. . Mail::MboxParser has not been derived from Mail::Box and thus isn't acquainted with it in any way. It, however, incorporates some invaluable hints by the author of Mail::Box, Mark Overmeer. It has no serious bugs, but people looking for a way to programmatically work through mboxes often install it (and thus report bugs on it). Good if you want to learn Perl / Perl packaging for Debian. -Josh -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443508: RoM; no users, no longer maintained
Package: ftp.debian.org Severity: normal The package 'thinksynth', currently only in experimental, is incredibly outdated and the authors abandoned the project. Moreover I'm not interested in maintaining the upstream source, so let's just put it out of its misery. Thanks, -Josh -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22.6 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434956: mt-daapd: segfault at startup; uninstallable
On Fri, Jul 27, 2007 at 07:40:04PM -0400, [EMAIL PROTECTED] wrote: mt-daapd version 0.9~r1586-1 is uninstallable on my system, because the postinst script fails. the postinst script is failing because /usr/sbin/mt-daapd is segfaulting. Could you please run the mt-daapd binary manually and provide a coredump? (ulimit -c unlimited before running) Also, please submit a copy of the log file, /var/log/mt-daapd.log if it contains anything. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434956: mt-daapd: segfault at startup; uninstallable
tags 434956 unreproducible severity 434956 important thanks On Sat, Aug 04, 2007 at 05:20:49PM -0400, Chris Roddy wrote: I regret I am no longer able to reproduce the problem. I blew away my config file a few days ago, and have started over from the config shipped with the package; mt-daapd now starts and runs without any problem. I will see if I have a copy of the old config around, but I doubt it. Okay -- well, I'm downgrading this bug until someone can reproduce it. Thanks anyway. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433667: Please OK licence change for silo-installer udeb
On Wed, Jul 18, 2007 at 07:38:05PM +0200, Frans Pop wrote: As this can be considered a licence change and as you have contributed to silo-installer in the past, please OK this licence change by replying to [EMAIL PROTECTED] with a short statement of your agreement. I approve of the license. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423716: Update is wrong.
Hi Nach, On Mon, Jun 18, 2007 at 11:41:44PM +0300, Nach wrote: 1.2.10-1), libstdc++6 (= 4.2-20070516), zlib1g (= 1:1.2.1) ... ZSNES depends on zlib 1.2.3 as can be seen in the configure script: configure.in:AM_PATH_ZLIB (1.2.3, , [AC_MSG_ERROR(zlib = 1.2.3 is required)]) It looks like it's that way because 1.2.1 is binary-compatible with 1.2.3. Is there a good reason I should force the dependency to be = 1.2.3? In any case, all supported releases of Debian currently have 1.2.3: zlib1g | 1:1.2.3-13 | etch-m68k | m68k zlib1g | 1:1.2.3-13 |stable | alpha, amd64, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc zlib1g | 1:1.2.3-15 | testing | alpha, amd64, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc zlib1g | 1:1.2.3-15 | unstable | alpha, amd64, arm, hppa, hurd-i386, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc The best I am currently willing to do for you is to add a build-depends on zlib1g-dev (= 1:1.2.3), but that only helps with backporting. Anyway, the reason it built at all is because of this. Otherwise I would've noticed. Let me know what you think. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425562: Intent to NMU
Hi Marco, I intend to NMU this soon if you don't at least provide a response to this bug's status. Please let me know. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428134: RM: autoprofile -- RoM
Package: ftp.debian.org Severity: normal Hi, I'd like for autoprofile (and obviously its associated binary package gaim-autoprofile) because the software is no longer maintained upstream and is not compatible with Pidgin. Perhaps it can be re-uploaded (by someone else; I don't particularly have the time) when upstream comes around, but for now it does not belong in the archive. Thanks! -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.21 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428166: zsnes exits at startup, can't create mcop directory
On Sat, Jun 09, 2007 at 10:56:48AM -0400, Rian Hunter wrote: Creating link /home/rian/.kde/socket-cooked. can't create mcop directory Try zsnes -ad oss or -ad alsa. It might be trying to use arts for whatever reason. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426676: It's Not My Problem (tm)
http://flac.sourceforge.net/api/group__porting__1__1__2__to__1__1__3.html confirms that the seekable stream decoder is gone as of 1.1.3 (and thus 1.1.4). It looks like it's pretty easy to get it building. If you really can't figure it out I can try to provide a patch later today. Thanks -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427473: libflac-dev: LD_PRELOAD error building moc
On Mon, Jun 04, 2007 at 11:55:55AM +0200, Elimar Riesebieter wrote: checking for libFLAC... yes ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. . This even shows using pbuilder. Using 1.1.2 there was no ERROR. I don't think this is my bug because it appears to happen with all the other libraries that are checked for too, like: checking for timidity... ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. no Please close this bug if you agree. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426671: FLAC 1.1.4 is coming, library transition imminent
Hi Ana, On Tue, Jun 05, 2007 at 12:43:29AM +0200, Ana Guerrero wrote: Since the -dev package has the same name, could you ask binNMU for all the packages affected by this transition? If you're asking this so that packages depending on libflac7 will get updated to depend on libflac8, that is the responsibility of maintainers. What does libflac-dev have to do with this? It is not supposed to have a versioned named. Let me know. Thanks, -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405167: Any time soon?
On Thu, May 31, 2007 at 02:24:22PM +0200, Jesus Climent wrote: Any progress on this? it's about to hit NEW. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426648: FLAC 1.1.4 is coming, library transition imminent
Package: jackd Version: 0.103.0-5 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426632: FLAC 1.1.4 is coming, library transition imminent
Package: aqualung Version: 0.9~beta7.1-1 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426664: FLAC 1.1.4 is coming, library transition imminent
Package: scummvm Version: 0.9.1-1 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426676: FLAC 1.1.4 is coming, library transition imminent
Package: libsndfile1 Version: 1.0.17-1 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426673: FLAC 1.1.4 is coming, library transition imminent
Package: vlc-nox Version: 0.8.6.a.debian-6 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426675: FLAC 1.1.4 is coming, library transition imminent
Package: xmms2-plugin-flac Version: 0.2DrJekyll-1 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426678: FLAC 1.1.4 is coming, library transition imminent
Package: libk3b3 Version: 1.0.1-1 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426665: FLAC 1.1.4 is coming, library transition imminent
Package: libaudio-flac-decoder-perl Version: 0.2-2 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426649: FLAC 1.1.4 is coming, library transition imminent
Package: kradio Version: 0.1.1.1~20061112-2 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426633: FLAC 1.1.4 is coming, library transition imminent
Package: alsaplayer-common Version: 0.99.77-1 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426639: FLAC 1.1.4 is coming, library transition imminent
Package: dssi-example-plugins Version: 0.9.1-3 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426655: FLAC 1.1.4 is coming, library transition imminent
Package: libtunepimp5 Version: 0.5.3-2 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426667: FLAC 1.1.4 is coming, library transition imminent
Package: stratagus Version: 2.1-9.1 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426661: FLAC 1.1.4 is coming, library transition imminent
Package: gstreamer0.8-flac Version: 0.8.12-6 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426645: FLAC 1.1.4 is coming, library transition imminent
Package: gnusound Version: 0.7.4-5 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426636: FLAC 1.1.4 is coming, library transition imminent
Package: audacity Version: 1.3.3-1 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426652: FLAC 1.1.4 is coming, library transition imminent
Package: libapache2-mod-musicindex Version: 1.2.0-1 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426668: FLAC 1.1.4 is coming, library transition imminent
Package: kwave Version: 0.7.7-2 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426647: FLAC 1.1.4 is coming, library transition imminent
Package: gstreamer0.10-plugins-good Version: 0.10.5-5 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426671: FLAC 1.1.4 is coming, library transition imminent
Package: libakode2 Version: 2.0.2-1 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426637: FLAC 1.1.4 is coming, library transition imminent
Package: cynthiune.app Version: 0.9.5-5 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426653: FLAC 1.1.4 is coming, library transition imminent
Package: libaudio-flac-header-perl Version: 1.4-1 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426669: FLAC 1.1.4 is coming, library transition imminent
Package: timidity Version: 2.13.2-12 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426642: FLAC 1.1.4 is coming, library transition imminent
Package: flac123 Version: 0.0.9-4 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426658: FLAC 1.1.4 is coming, library transition imminent
Package: muse Version: 0.8.1a-4 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426644: FLAC 1.1.4 is coming, library transition imminent
Package: ecasound Version: 2.4.5-2 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426660: FLAC 1.1.4 is coming, library transition imminent
Package: muine Version: 0.8.7-1+b1 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426677: FLAC 1.1.4 is coming, library transition imminent
Package: libxine1 Version: 1.1.6-1 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426635: FLAC 1.1.4 is coming, library transition imminent
Package: arson Version: 0.9.8beta2-4.3 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426651: FLAC 1.1.4 is coming, library transition imminent
Package: kid3 Version: 0.8.1-2 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426663: FLAC 1.1.4 is coming, library transition imminent
Package: rezound Version: 0.12.2beta-8 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426679: FLAC 1.1.4 is coming, library transition imminent
Package: moc Version: 2.5.0~svn20070523-1 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426659: FLAC 1.1.4 is coming, library transition imminent
Package: mt-daapd Version: 0.2.4+r1376-2 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426643: FLAC 1.1.4 is coming, library transition imminent
Package: ecawave Version: 1:0.6.1-10 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426672: FLAC 1.1.4 is coming, library transition imminent
Package: kdemultimedia-kio-plugins Version: 4:3.5.7-1 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426670: FLAC 1.1.4 is coming, library transition imminent
Package: idjc Version: 0.6.11-1 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426640: FLAC 1.1.4 is coming, library transition imminent
Package: ecamegapedal Version: 0.4.4-6 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426656: FLAC 1.1.4 is coming, library transition imminent
Package: mkvtoolnix Version: 2.0.2-1 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426646: FLAC 1.1.4 is coming, library transition imminent
Package: graveman Version: 0.3.12-5-1 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426662: FLAC 1.1.4 is coming, library transition imminent
Package: prokyon3 Version: 0.9.4-3 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426654: FLAC 1.1.4 is coming, library transition imminent
Package: libsdl-sound1.2 Version: 1.0.1-12 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426638: FLAC 1.1.4 is coming, library transition imminent
Package: cmus Version: 2.1.0-1 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426634: FLAC 1.1.4 is coming, library transition imminent
Package: ardour Version: 1:2.0.2-2 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426674: FLAC 1.1.4 is coming, library transition imminent
Package: vorbis-tools Version: 1.1.1-12 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426666: FLAC 1.1.4 is coming, library transition imminent
Package: sox Version: 13.0.0-1 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426650: FLAC 1.1.4 is coming, library transition imminent
Package: hydrogen Version: 0.9.3-2 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426657: FLAC 1.1.4 is coming, library transition imminent
Package: mpd Version: 0.12.2-3 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426641: FLAC 1.1.4 is coming, library transition imminent
Package: easytag Version: 1.99.12-1 Severity: normal Hi, This is to let you know I've gotten around to packaging FLAC 1.1.4. As you may know, this involves not only the usual SONAME change from libflac7 - libflac8 libflac++5 - libflac++6 but also liboggflac* have been removed, and merged into the main FLAC library, so there are lots of API considerations involved with that. You're receiving this bug because your package depends on one or more of libflac7, libflac++5, liboggflac3, or liboggflac++2. By now your upstream sources have transitioned, or at least made #ifdef style provisions for this new API, especially if your package depends on liboggflac*. If not, Josh Coalson, the upstream maintainer of FLAC, has prepared a fairly extensive transition guide on the FLAC web site in case you want to have a go at making the transition yourself. (What a dedicated maintainer!): http://flac.sourceforge.net/api/group__porting.html If you're ready to build against 1.1.4, please download binary packages or build them from source from here: http://people.debian.org/~joshk/ i386 and amd64 are available on that page. Well, this is a small-time library transition. So this is probably the only message you'll see about this. I plan to upload 1.1.4 tomorrow evening if there are no concerns raised about the sanity of this transition, and you will have until the package clears NEW to prepare. Once it hits unstable, you should upload your package on the same day to mitigate uninstallable packages. (But if anyone complains, tell them that they're using unstable, and should live with it.) Oh, and sorry for the belated transition -- I've been quite busy with school. Anyway, let me know if there are any problems. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425799: closed by Daniel Baumann [EMAIL PROTECTED] (reply to [EMAIL PROTECTED]) (Re: libc6-i386 tries to overwrite /lib32 symlink made by ncurses)
reopen 425799 reassign 425799 libc6-i386 thanks homeboy On Thu, May 24, 2007 at 06:51:10AM +, Daniel Baumann wrote: This was fixed as of ncurses 5.6-3. I understand, but this happened in an upgrade situation wherein: libc6-i386 was scheduled to be upgraded to 2.5-9 lib32ncurses5 was scheduled to be upgraded to 5.6-3 Because of how apt makes decisions I assume it chose to upgrade libc6-i386 first, which is perfectly reasonable. We can't assume people will always get lib32ncurses5 in first. There are two ways to fix this. 1) Make libc6-i386 depend on lib32ncurses5. This is stupid. 2) Make libc6-i386 Replaces: lib32ncurses5. This should allow for smooth upgrades. This is to say that the fix can't be accomplished on the ncurses end. The damage has already been done from 5.6-1 and libc6-i386 must clean up. I understand that this won't be an issue in the coming months since people will never see these two releases, but it's all about doing things right. Thanks and please don't close the bug again without further discussion. -- Joshua Kwan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425799: libc6-i386 tries to overwrite /lib32 symlink made by ncurses
Package: libc6-i386 Version: 2.5-9 Severity: serious Preparing to replace libc6-i386 2.5-8 (using .../libc6-i386_2.5-9_amd64.deb) ... Unpacking replacement libc6-i386 ... dpkg: error processing /var/cache/apt/archives/libc6-i386_2.5-9_amd64.deb (--unpack): trying to overwrite `/lib32', which is also in package lib32ncurses5 The problem here is that lib32ncurses5 5.6-1 is still installed, and it provides the same symlink... If I let this install fail, and dpkg -i lib32ncurses5 5.6-3, which removes the symlink, then try this again, it all works. -Josh -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.21 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libc6-i386 depends on: pn libc6 none (no description available) libc6-i386 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419934: +S chanmode support
Package: ircd-hybrid
Tags: patch
Here's the patch, that used to be part of the original SSL patch, that
allows you to set a channel to only be joinable by SSL-users or people
on localhost.
--
Joshua Kwan
#! /bin/sh /usr/share/dpatch/dpatch-run
## 19_sslonly.dpatch.dpatch by Joshua Kwan [EMAIL PROTECTED]
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: No description.
@DPATCH@
--- ircd-hybrid-7.2.2/include/numeric.h~2007-01-21 10:39:19.0
-0800
+++ ircd-hybrid-7.2.2/include/numeric.h 2007-01-21 10:39:32.0 -0800
@@ -382,6 +382,7 @@
/* ERR_LINKFAIL 479unreal */
/* ERR_CANNOTKNOCK 480unreal */
/* ERR_NOULINE 480austnet */
+#define ERR_SSLONLYCHAN 480
#define ERR_NOPRIVILEGES 481
#define ERR_CHANOPRIVSNEEDED 482
#define ERR_CANTKILLSERVER 483
--- ircd-hybrid-7.2.2/src/messages.tab~ 2007-01-21 10:38:11.0 -0800
+++ ircd-hybrid-7.2.2/src/messages.tab 2007-01-21 10:38:53.0 -0800
@@ -504,7 +504,7 @@
/* 477 */ {NULL, NULL, NULL},
/* 478 */ {ERR_BANLISTFULL, :%s 478 %s %s %s :Channel ban list is full,
NULL},
/* 479 */ {ERR_BADCHANNAME, :%s 479 %s %s :Illegal channel name, NULL},
-/* 480 */ {NULL, NULL, NULL},
+/* 480 */ {ERR_SSLONLYCHAN, :%s 480 %s %s :Cannot join channel (+S),
NULL},
/* 481 */ {ERR_NOPRIVILEGES, :%s 481 %s :Permission Denied - You're not an
IRC operator, NULL},
/* 482 */ {ERR_CHANOPRIVSNEEDED, :%s 482 %s %s :You're not channel
operator, NULL},
/* 483 */ {ERR_CANTKILLSERVER, :%s 483 %s :You can't kill a server!,
NULL},
--- ircd-hybrid-7.2.2/src/channel_mode.c~ 2007-01-21 10:29:20.0
-0800
+++ ircd-hybrid-7.2.2/src/channel_mode.c2007-01-21 10:33:13.0
-0800
@@ -332,6 +332,9 @@
{ MODE_NOPRIVMSGS, 'n' },
{ MODE_PRIVATE,'p' },
{ MODE_SECRET, 's' },
+#ifdef HAVE_LIBCRYPTO
+ { MODE_SSLONLY,'S' },
+#endif
{ MODE_TOPICLIMIT, 't' },
{ 0, '\0' }
};
@@ -1313,7 +1316,11 @@
{chm_nosuch, NULL}, /* P */
{chm_nosuch, NULL}, /* Q */
{chm_nosuch, NULL}, /* R */
+#ifdef HAVE_LIBCRYPTO
+ {chm_simple, (void*) MODE_SSLONLY}, /* S */
+#else
{chm_nosuch, NULL}, /* S */
+#endif
{chm_nosuch, NULL}, /* T */
{chm_nosuch, NULL}, /* U */
{chm_nosuch, NULL}, /* V */
--- ircd-hybrid-7.2.2/src/channel.c~2007-01-21 10:37:39.0 -0800
+++ ircd-hybrid-7.2.2/src/channel.c 2007-01-21 10:38:01.0 -0800
@@ -44,6 +44,7 @@
#include event.h
#include memory.h
#include balloc.h
+#include fdlist.h
struct config_channel_entry ConfigChannel;
dlink_list global_channel_list = { NULL, NULL, 0 };
@@ -679,6 +679,21 @@
chptr-mode.limit)
return ERR_CHANNELISFULL;
+ if (SSLonlyChannel(chptr))
+ {
+#ifdef HAVE_LIBCRYPTO
+if (MyClient(source_p)) {
+int fd = source_p-localClient-fd.fd;
+fde_t *F = lookup_fd(fd);
+
+if (F !F-ssl strcmp(source_p-localClient-sockhost,
127.0.0.1))
+return (ERR_SSLONLYCHAN);
+}
+#else
+return (ERR_SSLONLYCHAN);
+#endif
+ }
+
return 0;
}
--- a/modules/core/m_sjoin.c2007-01-21 10:54:13.0 -0800
+++ b/modules/core/m_sjoin.c2007-01-21 10:54:23.0 -0800
@@ -171,6 +171,9 @@
case 'p':
mode.mode |= MODE_PRIVATE;
break;
+ case 'S':
+mode.mode |= MODE_SSLONLY;
+break;
case 'k':
strlcpy(mode.key, parv[4 + args], sizeof(mode.key));
args++;
@@ -629,6 +632,7 @@
{ MODE_SECRET, 's' },
{ MODE_MODERATED, 'm' },
{ MODE_INVITEONLY, 'i' },
+ { MODE_SSLONLY,'S' },
{ MODE_PRIVATE,'p' },
{ 0, '\0' }
};
--- ircd-hybrid-7.2.2.dfsg.1/include/channel_mode.h~2007-01-21
10:58:30.0 -0800
+++ ircd-hybrid-7.2.2.dfsg.1/include/channel_mode.h 2007-01-21
10:58:58.0 -0800
@@ -55,6 +55,7 @@
#define MODE_TOPICLIMIT 0x0008
#define MODE_INVITEONLY 0x0010
#define MODE_NOPRIVMSGS 0x0020
+#define MODE_SSLONLY0x0040
/* cache flags for silence on ban */
#define CHFL_BAN_CHECKED 0x0080
@@ -71,6 +72,7 @@
/* name invisible */
#define SecretChannel(x)(((x)-mode.mode MODE_SECRET))
+#define SSLonlyChannel(x) (((x)-mode.mode MODE_SSLONLY))
#define PubChannel(x) (!SecretChannel(x))
/* knock is forbidden, halfops can't kick/deop other halfops.
* +pi means paranoid and will generate notices on each invite */
