Bug#426569: xulrunner: gmail broken for epiphany and galeon
On Tue, May 29, 2007 at 02:39:52PM -0500, Andy Bezella - PRA [EMAIL PROTECTED] wrote: Package: xulrunner Version: 1.8.1.4-1 Followup-For: Bug #426569 with the upgrade from 1.8.0.11-4.1 to 1.8.1.4-1, gmail no longer works when viewed with either galeon or epiphany (although they fail in different ways). downgrading libmozjs0d, libxul0d, and libxul-common back down to 1.8.0.11-4.1 is a workaround. See the bug log, there is a workaround. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426491: ucf: [debconf_rewrite] Debconf templates review
Hi, Thanks for your efforts for the translations for the ucf package. This is much appreciated. Unfortunately, I will not be applying the patches unmodified, since I do not agree with some of the changes suggested. (I am also not fully in agreement with the antiseptic tone being advocated wrt user interaction; but that is a discussion for another time) One of the first changes suggested is changing keep your currently-installed version to keep the currently installed version, which I think is less clear. The version I woulds use would be keep the local version currently installed instead; which emphasizes the fact that we are talking about the version local to the machine. Secondly, if you are to hyphenate the currently-installed in the choices; not hyphenating it in the default will break things; the default has to be one of the choices. I suggest adding this to the review guidelines, so mistakes like this are not made. Next, I still consider it perfectly fine to personalize the computer human interaction; I really liked HAL in 2001. There have been other studies that indicate that user experience in enhanced by a less sterile and formal dialogue. Mayer (2002) articulated eight principles of multimedia design: Personalisation principle: Deeper learning occurs when words are presented in a conversational style rather than a formal style. It is recommended that designers use conversational rather than expository style language, and the first and second person rather than the third person where appropriate. DEVELOPING A COMPUTER INTERACTION TO ENHANCE STUDENT UNDERSTANDING IN STATISTICAL INFERENCE , Kay Lipson, Glenda Francis, and Sue Kokonis Swinburne University of Technology, Australia ([EMAIL PROTECTED]) Mayer, R. E. (2002). Cognitive theory and the design of multimedia instruction: An example of the two-way street between cognition and instruction. New Directions for Teaching and Learning, 89(Spring), 55-71. So the question is going to remain the same. The differences -- File differences does not really add much clarification. Line by line differences between versions adds some clarity. Debian policy states -- The Debian policy states. The Debian Technical Policy Manual states; if you want to be pedantic. I don't think there is a The Debian policy. We have the Debian X policy, The Debian Web policy, The Debian Menu policy Also, configuration files do not preserve changes. Entities acting on configuration files must act in a manner that user initiated changes to configuration files must be preserved; if we are being pedantic, we should be consistently pedantic. Next, cannot and can not are both correct -- in different contexts. If the usage is opposite can -- if I am unable to perform some task, then I cannot do it. This is not the case here -- I obviously _can_ label the file a conffile, as long as I am wiling to forego some desirable aspects of the situation. I also can _not_ make it a conffile. When written as two words, one may imagine an emphasis being placed on the word not. In this case, writing it out as two words correctly conveys the nuances it was meant to convey. However, since this is obviously creating some distress, how about: This script attempts to provide conffile-like handling for files that may not be labelled as conffiles. Next, in one place the replacement for `' is '', in another it is (obviously, it should be ‘’, since debconf templates can handle utf-8, right?). Do you want me to upload a version of UCF with the new version of the templates, and feed those to the translators? manoj -- Colorless green ideas sleep furiously. Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Bug#415405: [Pkg-xfce-devel] Bug#415405: [xfce4-session-logout] No keyboard shortcuts in the logout confirmation dialog
(Please keep [EMAIL PROTECTED] on CC: list) On mer, 2007-05-30 at 10:06 +0400, Timur Izhbulatov wrote: If it doesn't fit your needs, please tell it. Otherwise, I'll consider the bug closed. To be honest, I don't think that any of solutions you suggested is the proper. Even if I assign some shortcut for xfce4-session-logout, I still can't answer the question without pointing device. Uh, wait. I'm sorry, I think I misunderstood your question. You mean that -after- having run xfce4-session-logout, when the screen is kind of greyed and the system ask you about restart/logout/shutdown, there you can't use keyboard? I can use left/right arrows and tab to go from one button to another, doesn't it work for you? Regards, -- Yves-Alexis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#156115: xserver-xorg-core: X server lists scalable fonts with fixed font names, and before real fixed fonts
Hi Massimo, It looks like this problem with fixed fonts being listed after scalable fonts with fixed names still apply today. Does it still matter? If so, we should probably talk to upstream about it instead of keeping it here for another 5 years :) Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425995: ALSA: internal sound card does not work if USB headset plugged in at boot
On Mon, 28 May 2007 18:34:17 +0200 maximilian attems [EMAIL PROTECTED] wrote: if bugs persist please inform upstream on the alsa bug tracking system see - http://www.alsa-project.org/ Done, see: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3129 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426611: release-notes: Please document that now changes in motd are erased at each reboot.
Le Wed, May 30, 2007 at 08:08:18AM +0200, Javier Fernández-Sanguino Peña a écrit : # Set EDITMOTD to no if you don't want /etc/motd to be editted # automatically Changes made into /etc/motd.tail are not automatically applied to /etc/motd; you can do this whith the following command: ? They are applied after every reboot. As this is implemented in bootmisc.sh. This phrase might need to be rewritten. By the way, I would have been happy to provide a patch, but where are the sources ? They are available at cvs.debian.org under the 'ddp' repository. Please check out http://www.debian.org/doc/cvs Thanks, Admins from Sarge expect that after modifying /etc/motd, users logging in immediately see the new message. If we tell them to modify /etc/motd.tail, the message is not displayed unless /etc/motd is regenerated by hand or by reboot. I will submit a proper patch which explains this better. Have a nice day, -- Charles
Bug#426630: lwat: postinst fails to install admin.ini
Package: lwat Version: 0.14-3 Severity: grave Justification: renders package unusable When installed lwat from unstable/testing, I get no /etc/lwat/admin.ini This makes it impossible to add new users, which is a core function for lwat. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (1000, 'stable'), (900, 'testing'), (800, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8) Versions of packages lwat depends on: ii apache22.2.3-4 Next generation, scalable, extenda ii apache2-mpm-prefork [apach 2.2.3-4 Traditional model for Apache HTTPD ii debconf [debconf-2.0] 1.5.11Debian configuration management sy ii libapache2-mod-php55.2.0-8+etch4 server-side, HTML-embedded scripti ii php5 5.2.0-8+etch4 server-side, HTML-embedded scripti ii php5-cli 5.2.0-8+etch4 command-line interpreter for the p ii php5-ldap 5.2.0-8+etch4 LDAP module for php5 ii smarty-gettext 1.0b1-2 provides gettext support for smart lwat recommends no packages. -- debconf information: * shared/ldapns/base-dn: dc=bzzware,dc=org * lwat/authprefix: ou=AuthGroup * lwat/minPwLength: 5 * lwat/allowPwSet: true * lwat/minPwLower: 0 * lwat/netgroupprefix: ou=Netgroup * lwat/domain: test.bzzware.org * lwat/minPwNumber: 0 * shared/ldapns/ldap-server: localhost * lwat/uselisgroup: false * lwat/minPwUpper: 0 * lwat/hostprefix: ou=Hosts * lwat/homedirlocation: /home * lwat/groupprefix: ou=Group * lwat/templates: educational institution -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426611: release-notes: Please document that now changes in motd are erased at each reboot.
On Wed, May 30, 2007 at 08:29:56AM +0900, Charles Plessy wrote: 5.15 Mesage of the day - /etc/motd is now rebuilt by /etc/init.d/bootmisc.sh from a template, /etc/motd.tail, at each reboot. It means that changes made to /etc/motd will be lost. This does not happen if you set EDITMOTD in /etc/default/rcS: # Set EDITMOTD to no if you don't want /etc/motd to be editted # automatically EDITMOTD=yes Changes made into /etc/motd.tail are not automatically applied to /etc/motd; you can do this whith the following command: ? They are applied after every reboot. As this is implemented in bootmisc.sh. This phrase might need to be rewritten. By the way, I would have been happy to provide a patch, but where are the sources ? They are available at cvs.debian.org under the 'ddp' repository. Please check out http://www.debian.org/doc/cvs Regards Javier signature.asc Description: Digital signature
Bug#426491: ucf: [debconf_rewrite] Debconf templates review
Thanks for your efforts for the translations for the ucf package. This is much appreciated. Unfortunately, I will not be applying the patches unmodified, since I do not agree with some of the changes suggested. (I am also not fully in agreement with the antiseptic tone being advocated wrt user interaction; but that is a discussion for another time) No X at all, Manoj. The final summary sent in a bug report is exactly aimed to trigger what you sent: a confirmation by the package maintainer who has the final word on the proposed changes. So, thanks for the care you took answering the bug report and expressing your concerns. One of the first changes suggested is changing keep your currently-installed version to keep the currently installed version, which I think is less clear. The version I woulds use would be keep the local version currently installed instead; which emphasizes the fact that we are talking about the version local to the machine. That's completely fine by me. Secondly, if you are to hyphenate the currently-installed in the choices; not hyphenating it in the default will break things; the default has to be one of the choices. I suggest adding this to the review guidelines, so mistakes like this are not made. Sorry for that. I'm afraid I'm entirely responsible for this mismatch introduction. Even reviewers have no responsibility..:-) Debian policy states -- The Debian policy states. The Debian Technical Policy Manual states; if you want to be pedantic. I don't think there is a The Debian policy. We have the Debian X policy, The Debian Web policy, The Debian Menu policy Indeed, I was initially thinking about using a formulation that entirely avoids Debian so that derived distros can use the templates and their translations as is. Something like Established packaging guidelines or something like this, maybe? Also, configuration files do not preserve changes. Entities acting on configuration files must act in a manner that user initiated changes to configuration files must be preserved; if we are being pedantic, we should be consistently pedantic. I'm missing the context here but I guess you're right. However, since this is obviously creating some distress, how about: This script attempts to provide conffile-like handling for files that may not be labelled as conffiles. Seems perfectly fine by me. Next, in one place the replacement for `' is '', in another it is (obviously, it should be ‘’, since debconf templates can handle utf-8, right?). debconf templates, yes, but gettext still issues some warnings so the dle folks settled on using single quotes. Remaining double quotes are more an error than anything else. Do you want me to upload a version of UCF with the new version of the templates, and feed those to the translators? I suggest we first exchange on an agreed templates file. Would you mind sending your rewritten one in the bug report (I'm subscribed to the PTS for ucf, so no need to CC), eventually CC'ed to debian-l10n-english? Once we have converged on something, then I'll use the rewritten templates file for a translation update round (it should last for about 15 days). Whether or not an upload happen in the meantime is indeed not really critical and is left to your judgement. signature.asc Description: Digital signature
Bug#425628: kmail: mail copy
severity 425628 important thanks Hi, I can confirm this bug, connecting to a Dovecot IMAP server. Extremely annoying. cheers -- vbi -- My godda bless, never I see sucha people. -- Signor Piozzi, quoted by Cecilia Thrale signature.asc Description: This is a digitally signed message part.
Bug#425882: 2:2.0.0-2 looks the same for me + suggestion
D G wrote: By the way: a bug for 2:2.0.0-2: when you wander onto an inactive window, the mouse pointer disappears. Please do not mix reports since it messes up the contents of the original bug, while this new bug will end up being forgotten. If this problem still happens with latest 2:2.0.0-3 that has been uploaded recently, feel free to file a new bug report. Anyway, I have downgraded to the driver in unstable, bacause of serious problems with the one in experimental (eg, ctrl+alt+F1 and you are done :-) ). That's another unrelated bug, right? Feel free to file another report about this (or add a followup to the existing driver crashes). I am sure resizing windows is supposed to be fast as of now. Lots of people have seen it being slow, remember: with the obsolete -modesetting driver, that is OK. Maybe this one needs rechecking and see which feature from the obsolete one is missing in the new one (but be careful, with -modesetting, the colours of the AVI were horrible). There have been lots of changes since the old modesetting driver, I might be hard to locate where the problem appeared... What about videos outside of both beryl and compiz ? OK, but after installing xine from experimental. With the one in unstable, the image freezes after a few seconds (on metacity, in Beryl it crashes from the beginning). Does the crash report any X-related error in the terminal where you launched Xine? Which video plugin are you using when playing these videos? For instance, in mplayer, you can do mplayer -vo x11 foo.avi to use the x11 plugin. Please try at least x11 and xv. Wow! With x11, even on Beryl, mplayer works! But it is the only one that works in beryl. Totem (with xine) and vlc hang. Idem gmplayer with xv. Ok, might be yet another XV problem then. Please try with 2:2.0.0-3, it got some new XV-relate fixes. VO: [xv] 320x240 = 320x240 Planar YV12 [ws] Error in display. [ws] Error code: 11 ( BadAlloc (insufficient resources for operation) ) [ws] Request code: 141 [ws] Minor code: 19 [ws] Modules: flip_page And another resource allocation problem... Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426569: Bug #426569
El mar, 29-05-2007 a las 20:19 +0200, Mike Hommey escribió: Could you both try to stop epiphany, then touch /usr/lib/xulrunner/.autoreg and restart epiphany ? It didn't help. If that doesn't change anything, could you also try to run with another user ? I created another user, I closed all instances of Eiphany and ran it as as the new user (through gksu) and I still get the same behavior. I know for sure that it ran as the new user, because it was using the default GNOME theme, as it couldn't connect to the session manager to retrieve my GNOME theme and other settings. By the way, I'm getting a similar error on Youtube.com when I try to register a vote: Error de JavaScript en , en la línea 0: uncaught exception: [Exception... Failure nsresult: 0x80004005 (NS_ERROR_FAILURE) location: JS frame :: http://www.youtube.com/js/AJAX_yts1175144889.js :: getXmlHttpRequest :: line 20 data: no] -- Javier Kohen [EMAIL PROTECTED] ICQ: blashyrkh #2361802 Jabber: [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje está firmada digitalmente
Bug#426422: xserver-xorg-video-ati: X freezes with arkhart and vegastrike with version 1:6.6.192-1 (build from experim source)
Alban Browaeys wrote: WHen playing arkhart or vegastrike (when reaching a solar system with a lot of details) X freezes. Tell me if I can help (testing patches, or any hint at what may be going wrong ). Does it happen with driver 6.6.3 or 6.6.191 (available from snapshot.debian.net)? Or with another xserver-xorg-core? Here is the gdb backtrace : Not really useful unfortunately :( thanks, Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426270: (2nd call) Please update debconf PO translation for the package dhcp3 3.0.4-15
Quoting Andreas Henriksson ([EMAIL PROTECTED]): On tis, 2007-05-29 at 07:39 +0200, Christian Perrier wrote: (2nd call: late corrections made after remarks received from other translators. Already sent translations have been included) Updated version of the swedish translation attached. To maintainers, please use the attached file instead. The one sent by Andreas is considered invalid by gettext, because of a bug in the tool used by Andreas (#420685). I however suppose that a reviewed file will come soon after the review by the Swedish team. sv.po Description: application/gettext signature.asc Description: Digital signature
Bug#426631: Should use libspeex instead of embedding a copy
Package: libopenh323-1.18.0
Version: 1.18.0.dfsg-1+b1
Severity: important
Tags: patch
Below you will find a patch that corrects the check done by configure so
that speex_audio_pwplugin.so will use libspeex instead of embeding a
copy of the Speex library.
This will result in more bugfixes and can be quite important in an event
of a security vulnerability in the Speex algorithm.
The irony is that the source build-depends on libspeex-dev, even though
it isn't used _at all_ in the binaries.
I guess we agree on the result and this is a technical bug.
Please apply.
Best regards,
Faidon
--- openh323-1.18.0.dfsg.orig/plugins/configure 2006-10-22 15:25:38.0
+0300
+++ openh323-1.18.0.dfsg/plugins/configure 2007-05-30 09:40:37.0
+0300
@@ -3243,7 +3243,7 @@
printf(%s\n, header.speex_version);
}
C_FILE
-cc -o t t.c -lspeex /dev/null 21
+cc -o t t.c -I/usr/include/speex -lspeex /dev/null 21
if test \! -x t ; then
echo $as_me:$LINENO: result: cannot determine - using library version
5
echo ${ECHO_T}cannot determine - using library version 6
--- openh323-1.18.0.dfsg.orig/plugins/configure.ac 2006-10-22
15:25:38.0 +0300
+++ openh323-1.18.0.dfsg/plugins/configure.ac 2007-05-30 09:38:51.0
+0300
@@ -117,7 +117,7 @@
printf(%s\n, header.speex_version);
}
C_FILE
-cc -o t t.c -lspeex /dev/null 21
+cc -o t t.c -I/usr/include/speex -lspeex /dev/null 21
if test \! -x t ; then
AC_MSG_RESULT(cannot determine - using library version)
else
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425276: help
tag 425528 + help thanks I upgrade openoffice.org from 2.2.0-7 to 2.2.1~rc1-1 and I've got some strange issues in shapes : - when I try to create a rounded square rectangle, it create a kind of quarter circle ! - when I open some files previously created in 2.2.1-rc1, all rectangles are replaced, - when I open file created previously in 2.2.1-rc1, with the old one, all shapes are shown normally !!! I can reproduce it every time ! I can reproduce this on up-to-date sid/i386 now, too in the meanwhile and the idea I spoke of in #425528 was due to our usage of STLport5. But all build I've did with stlport4 has the same error.. The other changes (besides upgrading to 2.2.1rc1, but other people don't have this problem with 2.2.1rcX, so...) should not have an effect on displaying in draw/impress... So I even tried using gcc-4.2 and with gcc 4.1.2-6a gcc upgrade was at fault but it didn't work either. What I didn't test yet was building with an older gcc-4.1... A person I asked remembered that he had that problem once, too, but forgot what it was... I've no idea anymore for now... Tagging appropriately. Hints/Fixes welcome. Gr??e/Regards, Ren? -- .''`. Ren? Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 signature.asc Description: Digital signature
Bug#426395: libc dlopening libgcc on arm
Joey Hess a écrit : Just spent half an hour since my slug wouldn't boot and I had to reflash an old initramfs. This bug should be fixed ASAP before it breaks a lot of systems. [EMAIL PROTECTED]:/tmp/initramfsmkinitramfs -o out -k Working files in /root/tmp/mkinitramfs_tj3082 and overlay in /root/tmp/mkinitramfs-OL_jH3085 [EMAIL PROTECTED]:/tmp/initramfschroot /root/tmp/mkinitramfs_tj3082 bin/sh libgcc_s.so.1 must be installed for pthread_cancel to work [EMAIL PROTECTED]:~/tmp/initramfsstrings /lib/libc.so.6|grep 'libgcc_s.so.1 must be installed for pthread_cancel to wor' libgcc_s.so.1 must be installed for pthread_cancel to work [EMAIL PROTECTED]:~/tmp/mkinitramfs_tj3082dpkg -l libc6 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii libc6 2.5-9 GNU C Library: Shared libraries This need for libgcc without direct linkage to it seems to be specific to arm. CCing the glibc maintainers for comment; you can find the code that does this under ports/sysdeps/unix/sysv/linux/arm/. This code is actually present on all architectures. I am currently trying to see what makes arm different. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- 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#319994: reopen Bug#319994 (Well reproducible also in the latest version)
Dear Cyril, I upgraded to the latest 4.2.0-3: dpkg -l gnuplot Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii gnuplot4.2.0-3A command-line driven interactive plotting p in my etch box (that required upgrading some libc, locales and a few other chain dependencies). I'm afraid this bug is perfectly reproducible. For example, type the following: mkdir test cd test echo 1 2\n3 4 pippo gnuplot and then, at the gnuplot command line, type p'piTAB As you press TAB, you expect that the line is completed to p'pippo (as in most linux distributions / unix builds), but the debian gnuplot does nothing. Tried both within xterm and gnome-terminal: this has nothing to do with an interaction with the terminal. So, sorry but once again this bug is not fixed: please do the little test above before next release, to make sure this bug is really fixed. Similarly, #75403 is still open (I'll send a message regarding that one too). Instead I can certify that #384919 was indeed fixed. Thank you, all the best, Nick -- 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#423425: xserver-xorg-input-evtouch: Also responsible for SEGVs on VT change
On Thu, May 24, 2007 at 03:51:07PM -0400, [EMAIL PROTECTED] wrote: Package: xserver-xorg-input-evtouch Version: 0.8.5-1 Followup-For: Bug #423425 When I try to change to a VT (e.g. trying to hibernate using swsusp2), X segfaults with the following backtrace: Backtrace: 0: X(xf86SigHandler+0x81) [0x80c8591] 1: [0xe420] 2: X(xf86RemoveEnabledDevice+0x34) [0x80c8684] 3: /usr/lib/xorg/modules/input//evtouch_drv.so [0xb7caa3ff] hmmm... I don't think it is related, anyway I uploaded a new package that fixes this SEGV (0.8.5-2). Let me know if it eventually also fixes the freezes you were experiencing. :) -- mattia :wq! -- 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#426395: libc dlopening libgcc on arm
Aurelien Jarno a écrit : Joey Hess a écrit : Just spent half an hour since my slug wouldn't boot and I had to reflash an old initramfs. This bug should be fixed ASAP before it breaks a lot of systems. [EMAIL PROTECTED]:/tmp/initramfsmkinitramfs -o out -k Working files in /root/tmp/mkinitramfs_tj3082 and overlay in /root/tmp/mkinitramfs-OL_jH3085 [EMAIL PROTECTED]:/tmp/initramfschroot /root/tmp/mkinitramfs_tj3082 bin/sh libgcc_s.so.1 must be installed for pthread_cancel to work [EMAIL PROTECTED]:~/tmp/initramfsstrings /lib/libc.so.6|grep 'libgcc_s.so.1 must be installed for pthread_cancel to wor' libgcc_s.so.1 must be installed for pthread_cancel to work [EMAIL PROTECTED]:~/tmp/mkinitramfs_tj3082dpkg -l libc6 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii libc6 2.5-9 GNU C Library: Shared libraries This need for libgcc without direct linkage to it seems to be specific to arm. CCing the glibc maintainers for comment; you can find the code that does this under ports/sysdeps/unix/sysv/linux/arm/. This code is actually present on all architectures. I am currently trying to see what makes arm different. The same code is also present on glibc 2.3.6 for nptl builds. So at least amd64 is using it in etch for the initrd. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- 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#426680: vim: Please include syntax highlighting files for markdown and ikiwiki
Package: vim Version: 1:7.1-000+1 Severity: wishlist Please consider including the syntax highlighting file for markdown, available at http://www.vim.org/scripts/script.php?script_id=1242 ; please also enable use of this filetype for files matching *.mdwn . Please also consider including the syntax highlighting file for ikiwiki markup, available at http://ikiwiki.info/tips/vim_syntax_highlighting/ikiwiki.vim . With that file included, users of ikiwiki can set ft=ikiwiki to use that syntax temporarily, or add au BufNewFile,BufRead *.mdwn set ft=ikiwiki to their startup files to use ikiwiki style for all markdown files. - Josh Triplett -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-rc1 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages vim depends on: ii libc62.5-9 GNU C Library: Shared libraries ii libgpmg1 1.19.6-25 General Purpose Mouse - shared lib ii libncurses5 5.6-3 Shared libraries for terminal hand ii vim-common 1:7.1-000+1 Vi IMproved - Common files ii vim-runtime 1:7.1-000+1 Vi IMproved - Runtime files vim recommends no packages. -- no debconf information -- 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#388382: kdemultimedia-kio-plugins: lame encoding produces files with only white noise
2007/5/29, Sune Vuorela [EMAIL PROTECTED]: On Tuesday 29 May 2007, Kevin Baradon wrote: Package: kdemultimedia-kio-plugins Version: 4:3.5.7-1 Followup-For: Bug #388382 Hello, Omitting lame -x switch broke CD-MP3 encoding on x86. Encoding without -x switch works (tested with .wav files). So previous fix was not correct. Please let me known if I can do something to help debugging. So you are saying that while fixing mp3 encoding on ppc we broke it on i386 ? Yes. so we better patch it to use -x on archs like x86 - and to not use -x on archs like ppc - is that what you are saying? I think this is cause of the bug. Ripping used to work well. If you provide me a patched package I can test it. I just find the lame -x option very badly described. Only one line in manpage. And I don't even know which byte order is used on CDDAs. /Sune -- Do you know how to uninstall on the firewall? You have to remove from a button of the sendmail for disabling the virus. -- Kevin BARADON -
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#426630: lwat on debian-edu
I had lwat 0.14-3 on my debian-edu etch system. /etc/lwat/admin.ini present purged lwat and reinstalled with lwat from sid version 0.14-3 I have /etc/lwat/admin.ini both in my etch installed from dvd and after the apt-get from sid. Ronny Aasen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426682: Please add Content-type: text/plain; charset=UTF-8 header to emails
Package: apticron Version: 1.1.20 Severity: minor Tags: patch Hi, As it is perfectly legal for changelogs to contain UTF-8 encoded characters, these may end up in the mail sent by apticron. However, there is no header that tells the MUA that the content uses UTF-8 encoding. Adding `-a Content-type: text/plain; charset=UTF-8' to mailx invocation will put the proper header, helping the MUA to show the special characters. Thanks for considering, dam -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-1-686 (SMP w/2 CPU cores) Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages apticron depends on: ii apt 0.6.46.4-0.1Advanced front-end for dpkg ii apt-listchanges 2.73.3 Display change history from .deb a ii debconf [debconf 1.5.13 Debian configuration management sy ii iproute 20061002-4 Professional tools to control the ii mailx1:8.1.2-0.20070424cvs-1 A simple mail user agent apticron recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426681: Should use libgsm instead of embedding a copy
Package: libopenh323-1.18.0
Version: 1.18.0.dfsg-1+b1
Severity: important
Tags: patch
Upstream has commented-out the support for system's GSM library (libgsm)
because the default library isn't compiled with WAV49.
Debian's version is however and that's why some time ago, libgsm1-dev
was added to the build-dependencies of the source package.
The patch below uncomments upstreams' code so that libgsm is used
again. I run autoconf and I'm supplying a patch for configure, besides
configure.ac to spare the extra build-dependency.
Severity important since this will result in quite a few bugfixes that
Debian's version includes and will help with any future security
vulnerabilities, if that happens.
Best regards,
Faidon
diff -Nur openh323-1.18.0.dfsg.openh323-1.18.0.dfsg.orig/plugins/configure
openh323-1.18.0.dfsg/plugins/configure
--- openh323-1.18.0.dfsg.orig/plugins/configure 2006-10-22 15:25:38.0
+0300
+++ openh323-1.18.0.dfsg/plugins/configure 2007-05-30 10:23:32.0
+0300
@@ -272,7 +272,7 @@
PACKAGE_BUGREPORT=
ac_unique_file=configure.ac
-ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME
PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix
program_transform_name bindir sbindir libexecdir datadir sysconfdir
sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir
build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS CXX CXXFLAGS
LDFLAGS CPPFLAGS ac_ct_CXX EXEEXT OBJEXT CC CFLAGS ac_ct_CC CPP EGREP
INSTALLPREFIX LIBDIR build build_cpu build_vendor build_os host host_cpu
host_vendor host_os target target_cpu target_vendor target_os LDSO
H323_GSMAMR_NB_FLOAT H323_EMBEDDED_GSM H323_SYSTEM_SPEEX LIBOBJS LTLIBOBJS'
+ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME
PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix
program_transform_name bindir sbindir libexecdir datadir sysconfdir
sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir
build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS CXX CXXFLAGS
LDFLAGS CPPFLAGS ac_ct_CXX EXEEXT OBJEXT CC CFLAGS ac_ct_CC CPP EGREP
INSTALLPREFIX LIBDIR build build_cpu build_vendor build_os host host_cpu
host_vendor host_os target target_cpu target_vendor target_os LDSO
H323_GSMAMR_NB_FLOAT H323_EMBEDDED_GSM H323_SYSTEM_GSM H323_SYSTEM_SPEEX
LIBOBJS LTLIBOBJS'
ac_subst_files=''
# Initialize some variables set by options.
@@ -817,6 +817,7 @@
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
--enable-embeddedgsmembed GSM codec via static linking
+ --enable-localgsm use local version of GSM library rather than
system version
--enable-localspeex use local version of Speex library rather than
system version
Some influential environment variables:
@@ -3137,6 +3127,100 @@
+H323_SYSTEM_GSM=0
+localgsm=xxx
+# Check whether --enable-localgsm or --disable-localgsm was given.
+if test ${enable_localgsm+set} = set; then
+ enableval=$enable_localgsm
+ localgsm=$enableval
+fi;
+
+if test ${localgsm} = yes ; then
+ { echo $as_me:$LINENO: Forcing use of local GSM sources 5
+echo $as_me: Forcing use of local GSM sources 6;}
+elif test ${localgsm} = no ; then
+ { echo $as_me:$LINENO: Forcing use of system GSM library 5
+echo $as_me: Forcing use of system GSM library 6;}
+ H323_SYSTEM_GSM=1
+else
+ echo $as_me:$LINENO: checking for gsm_create in -lgsm 5
+echo $ECHO_N checking for gsm_create in -lgsm... $ECHO_C 6
+if test ${ac_cv_lib_gsm_gsm_create+set} = set; then
+ echo $ECHO_N (cached) $ECHO_C 6
+else
+ ac_check_lib_save_LIBS=$LIBS
+LIBS=-lgsm $LIBS
+cat conftest.$ac_ext _ACEOF
+/* confdefs.h. */
+_ACEOF
+cat confdefs.h conftest.$ac_ext
+cat conftest.$ac_ext _ACEOF
+/* end confdefs.h. */
+
+/* Override any gcc2 internal prototype to avoid an error. */
+#ifdef __cplusplus
+extern C
+#endif
+/* We use char because int might match the return type of a gcc2
+ builtin and then its argument prototype would still apply. */
+char gsm_create ();
+int
+main ()
+{
+gsm_create ();
+ ;
+ return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (eval echo $as_me:$LINENO: \$ac_link\) 5
+ (eval $ac_link) 2conftest.er1
+ ac_status=$?
+ grep -v '^ *+' conftest.er1 conftest.err
+ rm -f conftest.er1
+ cat conftest.err 5
+ echo $as_me:$LINENO: \$? = $ac_status 5
+ (exit $ac_status); }
+{ ac_try='test -z $ac_c_werror_flag || test ! -s
conftest.err'
+ { (eval echo $as_me:$LINENO: \$ac_try\) 5
+ (eval $ac_try) 25
+ ac_status=$?
+ echo $as_me:$LINENO: \$? = $ac_status 5
+ (exit $ac_status); }; }
+{ ac_try='test -s conftest$ac_exeext'
+ { (eval echo $as_me:$LINENO: \$ac_try\) 5
+ (eval $ac_try) 25
+ ac_status=$?
+ echo $as_me:$LINENO: \$? = $ac_status 5
+ (exit $ac_status); }; }; then
+ ac_cv_lib_gsm_gsm_create=yes
+else
+ echo $as_me:
Bug#75403: reopen Bug#75403 (Broken in latest unstable, as well as in stable)
package gnuplot found 75403 4.2.0-3 thanks Hello, this bug is still open for both 4.2.0-3 and the stable snapshot 4.0.0-5. I suspect it is related to #319994: please read specifically the info provided by Chali Ahmul M.P.U [EMAIL PROTECTED] about readline, in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=319994 To test this bug, just open a terminal (xterm, gnome-terminal or whatever), enter gnuplot and type any sequence of characters which exceeds the line length, so that the line folds to the next. Then press left arrow and go back through the typed line. All is fine until you reach the left border of the screen, then you loose track of the cursor, which is indeed somewhere along the command line, but you don't know where. This can be very annoying and can lead to incorrect command lines, and even to undesired DATA LOSS, in unlucky cases. Consider for example you type a long line, then you press left arrow long enough to reach (without knowing) the beginning of the line. Then you type !rm * (with a space character after the *) and press enter. Regardless of the contents of the rest of the long line, this would remove all files in the current directory without you seeing beforehand. I admit this is a bit extreme, but other data loss could occur with unwanted and unseen typing, resulting in a line starting with: !cat VeryPreciousAndExpensiveFile So I also propose to increase the severity to grave, but I leave this up to you Cyril. By the way, this bug is surely absent in all Fedora Core releases I tested and in SUSE 9.2. All the best, Nick -- 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
Joshua Kwan wrote: 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 Just an FYI, the next verison of libsndfile has a snapshot of the FLAC sources included in the libsndfile sources. This was done partially to insulate libsndfile internals from FLAC API chanegs but more importantly to make libsndfile/FLAC easier to use on windows and MacOSX. Cheers, Erik -- - Erik de Castro Lopo - life is too long to know C++ well -- Erik Naggum -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#293556: gnupg: sometimes --refresh-keys leaves empty pubring.gpg when
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: gnupg Version: 1.4.6-2 Followup-For: Bug #293556 X-Debbugs-Cc: martin f krafft [EMAIL PROTECTED], Werner Koch [EMAIL PROTECTED] Hi! Today I experienced this while ^C-ing gnupg --refresh-keys: ~/.gnupg/pubkey.gpg was empty and ~/.gnupg/pupkey.gpg~ contained a valid and current (i.e. containing the already refreshed keys) copy of my public key ring. This seems to only happen if gnupg had modified the keyring immediately before the interrupt. Strangly enough, the responsible function rename_tmp_file from g10/keyring.c seems to do the Right Thing: remove pubkey.gpg~ rename pubkey.gpg.tmp pubkey.gpg chmod pubkey.gpg Regards, David - -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-1-vserver-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnupg depends on: ii gpgv 1.4.6-2 GNU privacy guard - signature veri ii libbz2-1.0 1.0.3-7 high-quality block-sorting file co ii libc62.5-9 GNU C Library: Shared libraries ii libldap2 2.1.30-13.4 OpenLDAP libraries ii libreadline5 5.2-3 GNU readline and history libraries ii libusb-0.1-4 2:0.1.12-7 userspace USB programming library ii makedev 2.3.1-83creates device files in /dev ii zlib1g 1:1.2.3-15 compression library - runtime gnupg recommends no packages. - -- no debconf information - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGXSl3/Pp1N6Uzh0URAndHAJ429uBTAz0XgOwlie+IHxa09V/3eQCgog0Q LLzq2sYP2KrgkNg5qCqlSgs= =C9I3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425905: nscd: should it depend on libc6-amd64 ?
reassign 425905 dpkg-dev,nscd Daniel Jacobowitz a écrit : On Thu, May 24, 2007 at 11:17:10PM +0300, Wladimir Mutel wrote: I have K7 CPU. Lots of other my hosts have i686. Why upgrade to nscd 2.5-8 should bring libc6-amd64 with itself ? It doesn't even have a dependency on libc6 (non-amd64), so I think this must be a bug in the build process. This is a bug in dpkg-shlibdeps. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426683: network-manager: nm should have basic firewalling framework
Package: network-manager Version: 0.6.4-8+b1 Severity: wishlist NetworkManager is cool but it would be cooler if there could be some minimal firewalling capabilities clubbed with it. Currently, adding a script to /etc/network/if-up.d/firewall does the job. [EMAIL PROTECTED]:~$ cat /etc/network/if-up.d/firewall #!/bin/bash if [ $IFACE == lo ]; then echo; else /sbin/iptables -A INPUT -i $IFACE -m state --state NEW,INVALID -j DROP; Probably, you could either put such scripts in the /usr/share/doc/$$/example folders and document it in the README.Debian file or else add similar framework into Debconf. This feature would be good for users. Thanks, Ritesh -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (550, 'unstable'), (500, 'stable'), (350, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-debian (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages network-manager depends on: ii adduser 3.102 Add and remove users and groups ii dbus 1.0.2-1 simple interprocess messaging syst ii dhcdbd 2.0-5 D-Bus interface to the ISC DHCP cl ii hal 0.5.9-3 Hardware Abstraction Layer ii ifupdown 0.6.8 high level tools to configure netw ii iproute 20061002-4 Professional tools to control the ii iputils-arping 3:20020927-6Tool to send ICMP echo requests to ii libc62.5-9 GNU C Library: Shared libraries ii libdbus-1-3 1.0.2-5 simple interprocess messaging syst ii libdbus-glib-1-2 0.73-2 simple interprocess messaging syst ii libgcrypt11 1.2.4-2 LGPL Crypto library - runtime libr ii libglib2.0-0 2.12.12-1 The GLib library of C routines ii libgpg-error01.4-2 library for common error values an ii libhal1 0.5.9-3 Hardware Abstraction Layer - share ii libiw29 29~pre21-2 Wireless tools - library ii libnl1-pre6 1.0~pre6-5 Library for dealing with netlink s ii libnm-util0 0.6.4-8+b1 network management framework (shar ii lsb-base 3.1-23.1Linux Standard Base 3.1 init scrip ii wpasupplicant0.6.0~cvs20070224-2 Client support for WPA and WPA2 (I Versions of packages network-manager recommends: ii network-manager-kde 1:0.1-4KDE systray applet for controlling -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426684: loudmouth: New upstream release available
Package: loudmouth Version: 1.2.1-1 Severity: wishlist Loudmouth 1.2.2 was release a month ago, please update the package. The latest release of Gossip depends on this new version. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426072: 2.0.1-1
I don't get this issue in 2.0.1, duplicating the same setup that I used in my bug filing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426685: dvorak lisp-machine-like keyboard layout
Package: console-data Version: 2002.12.04dbs-46.2 Severity: wishlist Please add the attached layout to the list of supported ones in /usr/share/keymaps/i386/dvorak/ It is similar to the one described in bug#282126, but with a Dvorak layout for letters (not for symbols). Thank you very much. Carlos Carleos [EMAIL PROTECTED] 2:341/14.79 # Lisp Machine keyboard (by [EMAIL PROTECTED]) # Dvorak version # # US layout (qwerty for symbols, dvorak for letters) # exchange Caps Lock - Backspace (Rubout) # exchange Alt (AltGr) - Control # exchange parentheses - square brackets # # extra: # Win keys - Alt (Meta) # Menu key - Compose (ISO-8859-1) # PC105 less-than/greater-than key - Escape # keymaps 0-2,4-6,8-9,12 keycode 1 = Escape alt keycode 1 = Meta_Escape shift alt keycode 1 = Meta_Escape control alt keycode 1 = Meta_Escape keycode 2 = one exclam alt keycode 2 = Meta_one shift alt keycode 2 = Meta_exclam keycode 3 = two at at nul nul alt keycode 3 = Meta_two shift alt keycode 3 = Meta_at control alt keycode 3 = Meta_nul keycode 4 = threenumbersign control keycode 4 = Escape alt keycode 4 = Meta_three shift alt keycode 4 = Meta_numbersign keycode 5 = four dollar dollar Control_backslash alt keycode 5 = Meta_four shift alt keycode 5 = Meta_dollar control alt keycode 5 = Meta_Control_backslash keycode 6 = five percent control keycode 6 = Control_bracketright alt keycode 6 = Meta_five shift alt keycode 6 = Meta_percent keycode 7 = six asciicircum control keycode 7 = Control_asciicircum alt keycode 7 = Meta_six shift alt keycode 7 = Meta_asciicircum keycode 8 = sevenampersandbraceleft Control_underscore alt keycode 8 = Meta_seven shift alt keycode 8 = Meta_ampersand control alt keycode 8 = Meta_Control_underscore keycode 9 = eightasterisk bracketleft Delete alt keycode 9 = Meta_eight shift alt keycode 9 = Meta_asterisk control alt keycode 9 = Meta_Delete keycode 10 = nine bracketleftbracketright alt keycode 10 = Meta_nine shift alt keycode 10 = Meta_parenleft keycode 11 = zero bracketright braceright alt keycode 11 = Meta_zero shift alt keycode 11 = Meta_parenright keycode 12 = minusunderscore backslash Control_underscore Control_underscore alt keycode 12 = Meta_minus shift alt keycode 12 = Meta_underscore control alt keycode 12 = Meta_Control_underscore keycode 13 = equalplus alt keycode 13 = Meta_equal shift alt keycode 13 = Meta_plus keycode 14 = Caps_Lock alt keycode 14 = Meta_Delete shift alt keycode 14 = Meta_Delete control alt keycode 14 = Meta_Delete keycode 15 = Tab alt keycode 15 = Meta_Tab shift alt keycode 15 = Meta_Tab control alt keycode 15 = Meta_Tab keycode 16 = s keycode 17 = w keycode 18 = v keycode 19 = l keycode 20 = f keycode 21 = u keycode 22 = i keycode 23 = j keycode 24 = p keycode 25 = n keycode 26 = parenleft braceleft control keycode 26 = Escape alt keycode 26 = Meta_bracketleft shift alt keycode 26 = Meta_braceleft keycode 27 = parenright braceright asciitilde Control_bracketright alt keycode 27 = Meta_bracketright shift alt keycode 27 = Meta_braceright control alt keycode 27 = Meta_Control_bracketright keycode 28 = Return alt keycode 28 = Meta_Control_m keycode 29 = Alt keycode 30 = a keycode 31 = r keycode 32 = period greater alt keycode 52 = Meta_period shift alt keycode 52 = Meta_greater keycode 33 = g keycode 34 = c keycode 35 = e keycode 36 = d keycode 37 = y keycode 38 = b keycode 39 = o
Bug#426569: Fwd: Bug#426569
On 5/29/07, Mike Hommey [EMAIL PROTECTED] wrote: Remove both files (compreg.dat and xpti.dat) and the problem will be gone. Perfect! I will add this to the postinst scripts. Thank you very much! Best regards, Silvestre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426687: bold comma in man page bash.1
Package: bash Version: 3.1dfsg-8 Severity: minor Tags: patch Hi, Please see the attached patch, the comma after is displayed bold if there is no additional space between and ,. --- bash-3.1/doc/bash.1.orig 2007-05-30 09:53:07.0 +0200 +++ bash-3.1/doc/bash.1 2007-05-30 09:53:13.0 +0200 @@ -577,7 +577,7 @@ have equal precedence, followed by .B ; and -.BR , +.BR , which have equal precedence. .PP A sequence of one or more newlines may appear in a \fIlist\fP instead signature.asc Description: This is a digitally signed message part.
Bug#424049: Proposed solution
package libopenh323-1.18.0
tag 424049 + patch
package libpt-1.10.0
tag 424050 + patch
thanks control
[3rd mail against the same package with patches attached in a row!]
As I stated before, the major blocker in removing the conflicts between
different versions of libpt/libopenh323 is the /usr/lib/pwlib/ (and its
respective /usr/lib/debug one) directory, which is present in both
libraries and is common between different versions.
Attached you will find two patches -one for each library- in which I
attempt to resolve this by placing the pwlib plugins and H.323 codecs in
/usr/lib/pwlib/${PWLIB_VERSION}/foo/bar
(e.g. /usr/lib/pwlib/1.10.2/codecs/audio)
instead of
/usr/lib/pwlib/foo/bar
This is a bit suboptimal, because we can have the same SONAME but a
different minor or build version which will result in tightened
dependencies for no reason. This is not however such a big deal and it's
certainly better than the current situation.
As always, I'm including patches for configure along with configure.ac
to avoid an unnecessary build-dependency on autoconf.
Please not that the patches are only build-tested for the moment.
Feedback is welcome!
Also please not that the patches do not include the removal of
Conflicts/Replaces from debian/control, this has to be done by the
maintainer(s).
Please apply. Having multiple versions of the same library installed and
happily coexist is standard procedure in Debian and for a good reason.
Best regards,
Faidon
P.S. On a side note, the whole mess with
LIBH323COMPAT/LIBPTCOMPAT{1,2,3} should really be resolved. Libraries
have SONAMEs that indicate their ABI, that's all that matters.
We shouldn't care about the build number or the minor revision that
didn't break the ABI and we certainly shouldn't create useless symlinks.
Look e.g. at libpcap0.8, which has a 0.8 soname but its version is 0.9.5
-- there was a discussion on debian-devel some time ago about this.
diff -Nur pwlib-1.10.2.orig/debian/libpt-plugins-alsa.dirs
pwlib-1.10.2/debian/libpt-plugins-alsa.dirs
--- pwlib-1.10.2.orig/debian/libpt-plugins-alsa.dirs2007-05-15
17:46:23.0 +0300
+++ pwlib-1.10.2/debian/libpt-plugins-alsa.dirs 1970-01-01 02:00:00.0
+0200
@@ -1 +0,0 @@
-usr/lib/pwlib/device/sound/
diff -Nur pwlib-1.10.2.orig/debian/libpt-plugins-avc.dirs
pwlib-1.10.2/debian/libpt-plugins-avc.dirs
--- pwlib-1.10.2.orig/debian/libpt-plugins-avc.dirs 2007-05-15
17:46:23.0 +0300
+++ pwlib-1.10.2/debian/libpt-plugins-avc.dirs 1970-01-01 02:00:00.0
+0200
@@ -1 +0,0 @@
-usr/lib/pwlib/device/videoinput/
diff -Nur pwlib-1.10.2.orig/debian/libpt-plugins-dc.dirs
pwlib-1.10.2/debian/libpt-plugins-dc.dirs
--- pwlib-1.10.2.orig/debian/libpt-plugins-dc.dirs 2007-05-15
17:46:23.0 +0300
+++ pwlib-1.10.2/debian/libpt-plugins-dc.dirs 1970-01-01 02:00:00.0
+0200
@@ -1 +0,0 @@
-usr/lib/pwlib/device/videoinput/
diff -Nur pwlib-1.10.2.orig/debian/libpt-plugins-oss.dirs
pwlib-1.10.2/debian/libpt-plugins-oss.dirs
--- pwlib-1.10.2.orig/debian/libpt-plugins-oss.dirs 2007-05-15
17:46:23.0 +0300
+++ pwlib-1.10.2/debian/libpt-plugins-oss.dirs 1970-01-01 02:00:00.0
+0200
@@ -1 +0,0 @@
-usr/lib/pwlib/device/sound/
diff -Nur pwlib-1.10.2.orig/debian/libpt-plugins-v4l2.dirs
pwlib-1.10.2/debian/libpt-plugins-v4l2.dirs
--- pwlib-1.10.2.orig/debian/libpt-plugins-v4l2.dirs2007-05-15
17:46:23.0 +0300
+++ pwlib-1.10.2/debian/libpt-plugins-v4l2.dirs 1970-01-01 02:00:00.0
+0200
@@ -1 +0,0 @@
-usr/lib/pwlib/device/videoinput/
diff -Nur pwlib-1.10.2.orig/debian/libpt-plugins-v4l.dirs
pwlib-1.10.2/debian/libpt-plugins-v4l.dirs
--- pwlib-1.10.2.orig/debian/libpt-plugins-v4l.dirs 2007-05-15
17:46:23.0 +0300
+++ pwlib-1.10.2/debian/libpt-plugins-v4l.dirs 1970-01-01 02:00:00.0
+0200
@@ -1 +0,0 @@
-usr/lib/pwlib/device/videoinput/
diff -Nur pwlib-1.10.2.orig/debian/rules pwlib-1.10.2/debian/rules
--- pwlib-1.10.2.orig/debian/rules 2007-05-15 17:46:23.0 +0300
+++ pwlib-1.10.2/debian/rules 2007-05-30 06:49:35.0 +0300
@@ -188,28 +188,34 @@
# plugins
#libpt-plugins-v4l
+ mkdir -p
debian/libpt-plugins-v4l/usr/lib/pwlib/$(SHLIBSVER)/device/videoinput/
cp plugins/pwlib/device/videoinput/v4l_pwplugin.so \
- debian/libpt-plugins-v4l/usr/lib/pwlib/device/videoinput/
+
debian/libpt-plugins-v4l/usr/lib/pwlib/$(SHLIBSVER)/device/videoinput/
#libpt-plugins-v4l2
+ mkdir -p
debian/libpt-plugins-v4l2/usr/lib/pwlib/$(SHLIBSVER)/device/videoinput/
cp plugins/pwlib/device/videoinput/v4l2_pwplugin.so \
- debian/libpt-plugins-v4l2/usr/lib/pwlib/device/videoinput/
+
debian/libpt-plugins-v4l2/usr/lib/pwlib/$(SHLIBSVER)/device/videoinput/
#libpt-plugins-avc
+ mkdir -p
debian/libpt-plugins-avc/usr/lib/pwlib/$(SHLIBSVER)/device/videoinput/
cp
Bug#426688: tcp-wrappers: [INTL:vi] Vietnamese debconf templates translation update
Package: tcp-wrappers Version: 7.6.dbs-14 Severity: minor Tags: l10n, patch The updated Vietnamese translation for the debconf file: tcp-wrappers translated and submitted by: Clytie Siddall (vi-VN, Vietnamese free-software translation team / nhóm Việt hóa phần mềm tự do) vi.po.gz Description: GNU Zip compressed data PGP.sig Description: This is a digitally signed message part
Bug#412691: netmrg: The monitor 'Script Options' field is ignored
On Sun, 27 May 2007, Uwe Steinmann wrote: [...] Sorry for the long delay. It took me quite some time to figure out what's going on here. The documentation is bit scarce on this. It will work, if you specify the command as 'local-netmrg-lmsensors.pl %parameters%' %parameters% will be replaced with 'temp1' in your case. I have not tried this (NetMRG was temperamental enough that I prefer not to touch my config now that I got it to work well), but if I understand the above correctly, then the attached patch may help clarify this point. -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.diff -ur netmrg-0.18.2.orig/README netmrg-0.18.2/README --- netmrg-0.18.2.orig/README 2004-11-09 05:26:14.0 +0100 +++ netmrg-0.18.2/README 2007-05-30 10:25:24.0 +0200 @@ -1389,10 +1389,12 @@ Edit * Name - An description used to identify the test. - * Command - The program to execute for this test. If the value of - this field does not start with a slash, it is assumed that the - command is located in the default NetMRG tests directory. - Commands are passed to a shell for execution by the gatherer. + * Command - The program to execute for this test and its + arguments. If the value of this field does not start with a + slash, it is assumed that the command is located in the + default NetMRG tests directory. Commands are passed to a shell + for execution by the gatherer. Add %parameters% where you would + like NetMRG to add its parameters. * Data Type - The type of data gathered from the program. + Standard Out - Data from the program's standard output is returned. The program should output data on one line which diff -ur netmrg-0.18.2.orig/share/doc/netmrg.sgml netmrg-0.18.2/share/doc/netmrg.sgml --- netmrg-0.18.2.orig/share/doc/netmrg.sgml 2004-11-09 05:26:14.0 +0100 +++ netmrg-0.18.2/share/doc/netmrg.sgml 2007-05-30 10:25:46.0 +0200 @@ -1314,7 +1314,7 @@ refsect2titleEdit/title itemizedlist listitemparaguilabelName/guilabel - An description used to identify the test./para/listitem - listitemparaguilabelCommand/guilabel - The program to execute for this test. If the value of this field does not start with a slash, it is assumed that the command is located in the default NetMRG tests directory. Commands are passed to a shell for execution by the gatherer./para/listitem + listitemparaguilabelCommand/guilabel - The program to execute for this test and its arguments. If the value of this field does not start with a slash, it is assumed that the command is located in the default NetMRG tests directory. Commands are passed to a shell for execution by the gatherer. Add %parameters% where you would like NetMRG to add its parameters./para/listitem listitemparaguilabelData Type/guilabel - The type of data gathered from the program. itemizedlist listitemparaguilabelStandard Out/guilabel - Data from the program's standard output is returned. The program should output data on one line which should be a numeric value or U to specify an unknown value./para/listitem diff -ur netmrg-0.18.2.orig/share/doc/txt/netmrg.txt netmrg-0.18.2/share/doc/txt/netmrg.txt --- netmrg-0.18.2.orig/share/doc/txt/netmrg.txt 2004-11-09 05:26:14.0 +0100 +++ netmrg-0.18.2/share/doc/txt/netmrg.txt 2007-05-30 10:25:36.0 +0200 @@ -1389,10 +1389,12 @@ Edit * Name - An description used to identify the test. - * Command - The program to execute for this test. If the value of - this field does not start with a slash, it is assumed that the - command is located in the default NetMRG tests directory. - Commands are passed to a shell for execution by the gatherer. + * Command - The program to execute for this test and its + arguments. If the value of this field does not start with a + slash, it is assumed that the command is located in the + default NetMRG tests directory. Commands are passed to a shell + for execution by the gatherer. Add %parameters% where you would + like NetMRG to add its parameters. * Data Type - The type of data gathered from the program. + Standard Out - Data from the program's standard output is returned. The program should output data on one line which
Bug#426258: cinelerra: playback does not stop
* Florian Cramer [EMAIL PROTECTED] [2007-05-27 16:39]: Package: cinelerra This package doesn't appear to be in Debian. Did you get it from another web site? -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426444: libtalloc-dev: Should depend on libtalloc1
* Josh Triplett [EMAIL PROTECTED] [2007-05-28 13:56]: Package: libtalloc-dev Version: 1.0.1-1 There's no such package afaict. Where did you find it? -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423425: xserver-xorg-input-evtouch: Also responsible for SEGVs on VT change
On Wed, May 30, 2007 at 04:16:19PM +0900, Mattia Dongili wrote: On Thu, May 24, 2007 at 03:51:07PM -0400, [EMAIL PROTECTED] wrote: Package: xserver-xorg-input-evtouch Version: 0.8.5-1 Followup-For: Bug #423425 When I try to change to a VT (e.g. trying to hibernate using swsusp2), X segfaults with the following backtrace: Backtrace: 0: X(xf86SigHandler+0x81) [0x80c8591] 1: [0xe420] 2: X(xf86RemoveEnabledDevice+0x34) [0x80c8684] 3: /usr/lib/xorg/modules/input//evtouch_drv.so [0xb7caa3ff] hmmm... I don't think it is related, anyway I uploaded a new package that fixes this SEGV (0.8.5-2). Let me know if it eventually also fixes the freezes you were experiencing. :) as expected the other problem is not fixed... I'll look again into this. -- mattia :wq! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426611: release-notes: Please document that now changes in motd are erased at each reboot.
Le Wed, May 30, 2007 at 08:08:18AM +0200, Javier Fernández-Sanguino Peña a écrit : /etc/motd is now rebuilt by /etc/init.d/bootmisc.sh from a template, /etc/motd.tail, at each reboot. It means that changes made to /etc/motd will be lost. This does not happen if you set EDITMOTD in /etc/default/rcS: Actually, are you sure that this functionality is available on Etch ? -- Charles
Bug#426686: installation-reports: lenny OK on Compaq Presario 5030
Lars-Göran Larsson wrote: Package: installation-reports Severity: wishlist -- Package-specific info: Boot method: CD Image version: http://cdimage.debian.org/cdimage/dayly-builds/daily/arch-latest/i386/iso-cd/debian-testing-i386-netinst.iso 03-May-2007 10:50 Date: May 26 2007 09:50 - 11:50 Machine: Compaq Presario 5030 Partitions: fdisk -l /dev/hda: Disk /dev/hda: 40,0 GB, 40020664320 byte 240 huvuden, 63 sektorer/spår, 5169 cylindrar Enheter = cylindrar av 15120 · 512 = 7741440 byte Enhet Start BörjanSlut BlockId System /dev/hda1 11040 7862368+ 7 HPFS/NTFS /dev/hda210411560 3931200c W95 FAT32 (LBA) /dev/hda3 *15612080 3931200c W95 FAT32 (LBA) /dev/hda42081516923352809f W95 Utökad (LBA) /dev/hda52081357011264368+ b W95 FAT32 /dev/hda635713705 1020568+ 83 Linux /dev/hda73706506010243768+ 83 Linux /dev/hda850615169 824008+ 82 Linux växling / Solaris Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: I started the installation by just hitting return at boot-prompt. No problems occurred. Grub installation found my Windows XP on /dev/hda1, but not Windows 98 on /dev/hda3, and suggested grub to be installed on MBR, which worked out fine. The Windows XP choice in grub boot menu leads to the old boot menu, where I can chose between Windows XP and Windows 98. Good enough. Even if detection of the windows 98 would work you'd find yourself in an odd situation since you'd have two ways to boot into windows 98. This is because is not Debian Installer business to edit the Windows boot menu in order to remove the Windows 98 entry. -- Regards, EddyP = Imagination is more important than knowledge A.Einstein signature.asc Description: OpenPGP digital signature
Bug#426583: There is no .desktop file
Le mercredi 30 mai 2007 à 02:17 +0200, Daniel Leidert a écrit : And once again: There is no MimeType field, so calling dh_desktop is useless and adds a useless call of update-desktop-database to the debhelper scripts. Don't do this. Further this file is invalid: Application is not a valid category. You should better use Education;Science;MedicalSoftware; as suggested by the specification. You can check such issues yourself with the desktop-file-validate tool. Regards, Daniel Thanks for the explanation about dh_desktop. But I'm not the author of this .desktop file, I have never touched gnumed-client. I found this package in the list of the packages changed in Ubuntu and waiting to be merged with Debian, so my goal is only to reduce the delta between Debian and Ubuntu. Feel free to fix anything you want. -- Adrien Cunin aka Adri2000 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426689: Dvorak lisp-machine-like keyboard layout
Package: console-data Version: 2:1.01-7 Severity: wishlist Please add the attached layout to the list of supported ones in /usr/share/keymaps/i386/dvorak/ It is similar to the one described in bug#282126, but with a Dvorak layout for letters (not for symbols). Thank you very much. Carlos Carleos [EMAIL PROTECTED] 2:341/14.79 lisp-us.kmap Description: Binary data -- Carlos Enrique Carleos Artime FidoNet-poshto: 2:341/14.79 Dep-to de Statistiko kaj Plejbonigo, Retposhto: [EMAIL PROTECTED] kaj Matematika DidaktikoTelefono:+34 985 181 904 Universitato Oviedo - Asturio Adreso: EUITIndus 33203 Hispanio
Bug#426690: fails to remove /etc/lwat in purge
Package: lwat Version: 0.14-3 Severity: normal when doing aptitude purge lwat, /etc/lwat still exists, even if no files in there was modified to reproduce, you may do aptitude install lwat aptitude purge -y lwat rm -rf /etc/lwat and then again aptitude install lwat aptitude purge -y lwat -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (1000, 'stable'), (900, 'testing'), (800, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages lwat depends on: ii apache22.2.3-4 Next generation, scalable, extenda ii apache2-mpm-prefork [apach 2.2.3-4 Traditional model for Apache HTTPD ii debconf [debconf-2.0] 1.5.11Debian configuration management sy ii libapache2-mod-php55.2.0-8+etch4 server-side, HTML-embedded scripti ii php5 5.2.0-8+etch4 server-side, HTML-embedded scripti ii php5-cli 5.2.0-8+etch4 command-line interpreter for the p ii php5-ldap 5.2.0-8+etch4 LDAP module for php5 ii smarty-gettext 1.0b1-2 provides gettext support for smart lwat recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425610: locales: dpkg-reconfigure fails: unexpected end of file
Marc Haber a écrit : Package: locales Version: 2.5-8 Severity: normal $ sudo env DEBIAN_FRONTEND=readline dpkg-reconfigure locales Configuring locales --- Locales are a framework to switch between multiple languages and allow users to use their language, country, characters, collation order, etc. Please choose which locales to generate. UTF-8 locales should be chosen by default, particularly for new installations. Other character sets may be useful for backwards compatibility with older systems and software. 1. All locales 200. fr_LU ISO-8859-1 snip 199. [EMAIL PROTECTED] ISO-8859-15 (Enter the items you want to select, separated by spaces.) Locales to be generated: 90 91 127 Many packages in Debian use locales to display text in the correct language for the user. You can choose a default locale for the system from the generated locales. This will select the default language for the entire system. If this system is a multi-user system where not all users are able to speak the default language, they will experience difficulties. 1. None 2. de_DE.UTF-8 3. [EMAIL PROTECTED] 4. en_US.UTF-8 Default locale for the system environment: 2 Generating locales (this might take a while)... de_DE.UTF-8... done [EMAIL PROTECTED] done en_US.UTF-8... done Generation complete. sh: -c: line 0: unexpected EOF while looking for matching `' sh: -c: line 1: syntax error: unexpected end of file $ I am unable to reproduce this bug. Could you please add a -x to the first line of /var/lib/dpkg/info/locales.postinst (after #! /bin/sh) and rerun it again? This should tell us the location of the problem. Thanks, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426691: config file and map upload/downloading, commands
Package: sauerbraten Version: 0.0.20070413.dfsg-1 Severity: wishlist /getmap and /sendmap don't work (need write permission on /usr/share/games/sauerbraten/packages/base ?) this config file locks the game for me: name tarzeau team GNU sensitivity 4 (i put it in ~/.sauerbraten/config.cfg) yours, Gürkan
Bug#426548: acpi events cause hard freeze on X40
also sprach Reinhard Tartler [EMAIL PROTECTED] [2007.05.30.0957 +0200]: What makes you think this was because of ACPI events? I fail to see any evidence that this problem is related to ACPI at all. It could be as well because of a broken implementation of the IDE driver. But this is speculative as well. I see it happen whenever I close the display or unplug/plug the power adapter, sometimes when I switch video display to the VGA port, and even sometimes just read()ing /proc/acpi/ibm/video or when DPMS blanks the screen. These are all ACPI-related and have nothing to do with the IDE driver. In fact, I was about to get Lenovo to replace the graphics chip/display combo because that could also be a source. It's certainly video-related here. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems signature.asc Description: Digital signature (GPG/PGP)
Bug#424978: --help output should not go to less automatically
also sprach David Lichteblau [EMAIL PROTECTED] [2007.05.18.1439 +0200]: Other than man is pretty broad. That includes git foo --help. Why is git allowed to use a pager here and ldapvi --help is not, when both print documentation that is longer than a page of output? I think git is also doing it wrong, and so is svk. Git also uses a pager in other situations, for example git --log and git --diff. Off the top of my head, I cannot recall examples other than git, but I certainly find it user-friendly and do not really see the point of, say, tar --help printing 249 lines without a pager. Every terminal in use nowadays can easily scroll and even search back 250 lines with the added benefit of not randomly clearing the screen when you quit $PAGER. As a user, you can either pipe through a pager if the program does not do that automatically, or you can pipe through cat to avoid the pager for programs that default to using one. So for both implementations, users can force the other output style if they want, reducing this issue to the question of getting the default right. This is backwards. Since you also speak German, here, with permission, our discussion on the topic, in German, from #debian.de: 30 01:38 Rhonda madduck: Wegen deinem Fehlerbericht zu ldapvi - ist es dir wichtig genug, dass ich ihn mit wontfix offen lassen muss, oder darf ich ihn schließen? :) 30 10:51 madduck Rhonda: warum nicht einfach --help auf stdout und ohne less? 30 10:52 Rhonda madduck: Stört es dich wirklich so extrem? Weshalb? 30 10:56 madduck Rhonda: weil ich dann nicht einfach --help machen und mir anhand des outputs im gleichen fenster die kommandozeile zusammenbasteln kann 30 10:56 madduck ja, mich stört es echt. 30 10:56 Rhonda madduck: Doch, kannst du. 30 10:57 madduck alias less=cat 30 10:58 Rhonda ldapvi --help | cat 30 10:58 madduck so ein schmarrn. 30 10:58 madduck wenn ich's in less haben will, dann mache ich ldapvi --help | less 30 10:58 madduck oder machen die anderen unix tools das etwa auch sorum? 30 10:59 Rhonda Ich kann Davids Begründung mehr als nur nachvollziehen und sehe keinen Grund, das zu deaktivieren. 30 11:01 madduck mach was du willst. 30 11:02 Rhonda Deswegen frag ich dich ja. 30 11:02 Myon es ist Unix, das Tool soll nicht PAGER benutzen wenn der User das selbst machen kann/erwartet 30 11:02 Rhonda Myon: Und warum macht es man dann? 30 11:02 madduck Rhonda: genauso sollte git nen bug bekommen. 30 11:02 Rhonda Erwartungshaltungen sind was antrainiertes. 30 11:02 madduck Rhonda: unix ist älter als die meisten von uns. 30 11:03 Myon *shrugs* es ist halt nicht der Unix-Way 30 11:03 Myon mehr Argumente gibts nicht, aber das sollte imho reichen 30 11:03 Rhonda madduck: Deswegen darf keine Evolution stattfinden, ich verstehe. Gute Begründung. 30 11:03 Rhonda Wenn du die git-Leute überreden kannst, dass sie's entfernen, mach ich's auch. 30 11:03 madduck das ist keine evolution, das ist mutation ohne was anderes. 30 11:03 Myon Rhonda: cut and paste kaputt zu machen, ist keine wirkliche Evolution 30 11:04 madduck wie gesagt, mach was du willst, ich verwende ich kein ldap mehr. 30 11:04 Rhonda Myon: Wo macht es cutpaste kaputt? *wonders* 30 11:04 Myon 10:56 madduck Rhonda: weil ich dann nicht einfach --help machen und mir anhand des outputs im 30 11:04 Myon gleichen fenster die kommandozeile zusammenbasteln kann 30 11:04 Rhonda Ah, Trotzreaktionen sind natürlich ein starkes Argument, richtig. 30 11:04 madduck wieso frägst du eigentlich? 30 11:04 Rhonda Myon: Und das stimmt nicht. 30 11:04 madduck genau so war's, deswegen kam der bug 30 11:05 madduck ich musste ein zweites fenster aufmachen, weil ich bei spalte 46 vergesse hatte, wie die eine option hiess. 30 11:05 Myon Rhonda: less löscht je nach Terminal und Lust/Laune den Output beim Beenden 30 11:05 madduck und ja schon den pager zumachen musste um überhaupt einen befehl absetzen zu können. 30 11:05 madduck pager ist doch heutzugtage eh idiotisch für's pagen. 30 11:05 madduck das kann jedes terminal 30 11:05 Rhonda madduck: Weil ich vorher abprüfen will, ob da ein reopen nachkommen würde, oder ob ich's prinzipiell schließen kann. 30 11:05 Myon das auch :) 30 11:05 Rhonda Myon: Deswegen | cat 30 11:06 Myon bla 30 11:06 madduck Rhonda: pff. wie gesagt, mach was du willst. ich auch. 30 11:06 Myon (sorry) 30 11:06 Myon | cat ist nicht akzeptabel 30 11:06 Rhonda Ich hab nicht gesagt, dass es ideal ist. 30 11:06 madduck und wenn mich das problem beim nächsten mal wieder stört, dann gibt es halt nen reopen oder nen neuen bug. 30 11:06 Myon aber es ist auch nicht mein Problem, aber es würde mich nerven wenn ich ldapvi benutzte 30 11:06 Rhonda Aber ich finde die Begründungen nicht für stark genug, dass ich mich da gegen Upstream entscheide. 30 11:07 Myon *das* ist eine andere Frage 30 11:07 Rhonda Myon: Das ist aber die, die _ich_ mir zu stellen hab. 30 11:08
Bug#407036: xserver-xorg: Server crashes each time after hibernate with suspend2
Hi Brice, yes the X server still crashes every few times on resume from suspend to memory with that that xserver-xorg-core package. I have tried to attach gdb to the X server, in virtual console but can't get that to work. Killing xscreensaver helps but still doesn't work, so I can't get a crash report. Bruce On Wed, May 30, 2007 at 12:31:36AM +0200, Brice Goglin wrote: Hi guys, Does this crash of the X server after resume from hibernate with suspend2 still occurs these days? Did you try with latest xserver-xorg-core in unstable (2:1.3.0.0.dfsg-5) and your latest driver? thanks, Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426692: One CPU slow down with kernel 2.6.18-4-686 (etch2)
Package: linux-image Version: 2.6.18-4-686 (etch2) I have a dual xeon system with 2 xeon 5050 dual core processors with HyperTreading. Sometimes one of the physical cores slow down and never speed up again. There is a lot of system and user load (~80-90%) and a lot of soft irq (~20-30%) on that CPU (on 2 virtual CPU because of HyperTreading). When a process running on the slow CPU it finished approximately 10 times slower than on one of the other CPUs. The slow CPU speed up only when I reboot the system. I am using Debian GNU/Linux 4.0, kernel 2.6.18-4-686 (etch2). Used packages: apache2, bind9, postfix, courier, mysql, proftpd, etc... I am not using x-window.
