Bug#402280: ITP: mbpeventd -- Apple MacBook Pro hotkeys event handler
Package: wnpp Severity: wishlist Owner: Julien BLACHE <[EMAIL PROTECTED]> * Package name: mbpeventd Version : 0.3 Upstream Author : Julien BLACHE <[EMAIL PROTECTED]> * URL : http://technologeek.org/projects/mbpeventd/ (soon) * License : GPL Programming Lang: C Description : Apple MacBook Pro hotkeys event handler mbpeventd handles the hotkeys found on Apple MacBook Pro laptops and adjusts the LCD backlight, sound volume, keyboard backlight or ejects the CD-ROM drive accordingly. . mbpeventd also monitors the ambient light sensors to automatically light up the keyboard backlight. . Support for the MacBook laptops is planned, patches welcome. JB. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#398533: RFP: tp-smapi -- exposes some features of the ThinkPad - first packaging attempt
On Fri, 08 Dec 2006 19:10:46 +0100 Daniel Baumann wrote: > If you're looking for a sponsor, I can do this. Thanks Daniel, as soon as I will know the packages are good enough for Debian, I'll come back to your offer. The packages still need some more text in README.Debian etc Regards Evgeni -- ^^^| Evgeni -SargentD- Golov ([EMAIL PROTECTED]) d(O_o)b | PGP-Key-ID: 0xAC15B50C >-|-< | WWW: http://www.die-welt.net ICQ: 54116744 / \| IRC: #sod @ irc.german-freakz.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BTS: Why no "invalid" or "notabug" tag?
On Fri, 8 Dec 2006 12:56:27 -0800, Don Armstrong <[EMAIL PROTECTED]> wrote: >On Fri, 08 Dec 2006, Marc Haber wrote: >> On Mon, 4 Dec 2006 16:51:26 -0800, Don Armstrong <[EMAIL PROTECTED]> >> wrote: >> >$ GET http://www.debian.org/Bugs/server-control|grep block >> >block bugnumber by bug >> >... >> > Note that the fix for the first bug is blocked by the other listed >> > bugs. >> >unblock bugnumber by >> >bug ... >> > Note that the fix for the first bug is no longer blocked by the other >> >> That's hardly what I'd call "documented". > >What more do you want? That's really all that blocking and unblocking >does. What happens to a bug when it's blocked? Which operations do behave as if the bug were not blocked, which operations behave differently, and what's the behavioral difference between being blocked and not? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Bug#398533: RFP: tp-smapi -- exposes some features of the ThinkPad - first packaging attempt
Evgeni Golov wrote: > Thanks Daniel, as soon as I will know the packages are good enough for > Debian, I'll come back to your offer. good. > The packages still need some more text in README.Debian etc hehe, mine too :) -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#398533: RFP: tp-smapi -- exposes some features of the ThinkPad - first packaging attempt
On Fri, 8 Dec 2006 19:15:20 -0200 Henrique de Moraes Holschuh wrote: > A few doubts about this: > > tp-smapi is either patch-only, or 2.6.19-only. How are you packaging > it? It cannot be just built out-of-tree in 2.6.18, it will not always > work as it needs to extend the DMI handling code. It is packaged as an out-of-tree module and it worked for me since 2.6.17, but I only can test on a Z61m. I think you're right because you know much more TP models (and their DMI stuff), then me. > Also, please make it extremely clear in the package descriptions that > the tp-smapi HDAPS is the one people should use (instead of stock > HDAPS). Stock HDAPS is buggy and broken. At the moment, hdaps isn't built. I think I'll enable the build and ship a big warning in the package description, as you said. > Anyway, the reason why I never packaged it is that to get a proper > thinkpad kernel, you need a small stack of patches that are still in > flux and I didn't feel it was a good idea to package yet: My Thinkpad runs a vanilla 2.6.19 kernel without problems, and I can use tp_smapi to controll the battery and monitor the system. [ points why tp-smapi doesn't really make sense on "older" kernels ] > For 2.6.19, you can actually have tp-smapi work reliably as an > out-of-tree build, so packaging it starts making more sense. I think it would be better to plan the tp-smapi package for Etch+1, so there will be kernel >2.6.19 and stuff you're working on in ibm-acpi. (And as it still builds on Etch with a recent kernel, an advanced user can use it). By the way, do you know anything about the "legality" of tp_smapi (I think you had read the discussion between Shem, Linus and Andrew on hdaps-devel)? Or should I ask debian-devel about their opinion? Regards Evgeni, beginning to write a huge readme.debian :) -- ^^^| Evgeni -SargentD- Golov ([EMAIL PROTECTED]) d(O_o)b | PGP-Key-ID: 0xAC15B50C >-|-< | WWW: http://www.die-welt.net ICQ: 54116744 / \| IRC: #sod @ irc.german-freakz.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BTS: Why no "invalid" or "notabug" tag?
Marc Haber <[EMAIL PROTECTED]> wrote: > On Fri, 8 Dec 2006 12:56:27 -0800, Don Armstrong <[EMAIL PROTECTED]> wrote: >>On Fri, 08 Dec 2006, Marc Haber wrote: >>> On Mon, 4 Dec 2006 16:51:26 -0800, Don Armstrong <[EMAIL PROTECTED]> wrote: >>> >$ GET http://www.debian.org/Bugs/server-control|grep block >>> >block bugnumber by bug >>> >... >>> > Note that the fix for the first bug is blocked by the other listed >>> > bugs. >>> >unblock bugnumber by >>> >bug ... >>> > Note that the fix for the first bug is no longer blocked by the other >>> That's hardly what I'd call "documented". >>What more do you want? That's really all that blocking and unblocking >>does. > What happens to a bug when it's blocked? Which operations do behave as > if the bug were not blocked, which operations behave differently, and > what's the behavioral difference between being blocked and not? Afaik there are no changes in behavior. blocks are only informational. cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
please no shlib bumps! (forw) Bug#401044: marked as done (libpng12-dev: [AMD64] asm API functions not exported)
Hi, | * Fixed "Incorrect shlibs information". Closes: #401465. --- libpng-1.2.15~beta5.orig/debian/libpng12-0.shlibs +++ libpng-1.2.15~beta5/debian/libpng12-0.shlibs @@ -0,0 +1,2 @@ +libpng12 0 libpng12-0 (>= 1.2.15~beta5) WTF is that? An shlib bump in the last second? That prevents fixing *any* package which builds against libpng12 to be fixed via unstable during the full freeze. What a bad idea. Not amused. Andi From: Anibal Monsalve Salazar <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Bug#401044: fixed in libpng 1.2.15~beta5-0 Date: Sat, 09 Dec 2006 10:17:04 + Message-Id: <[EMAIL PROTECTED]> Source: libpng Source-Version: 1.2.15~beta5-0 We believe that the bug you reported is fixed in the latest version of libpng, which is due to be installed in the Debian FTP archive: libpng12-0-udeb_1.2.15~beta5-0_i386.udeb to pool/main/libp/libpng/libpng12-0-udeb_1.2.15~beta5-0_i386.udeb libpng12-0_1.2.15~beta5-0_i386.deb to pool/main/libp/libpng/libpng12-0_1.2.15~beta5-0_i386.deb libpng12-dev_1.2.15~beta5-0_i386.deb to pool/main/libp/libpng/libpng12-dev_1.2.15~beta5-0_i386.deb libpng3_1.2.15~beta5-0_all.deb to pool/main/libp/libpng/libpng3_1.2.15~beta5-0_all.deb libpng_1.2.15~beta5-0.diff.gz to pool/main/libp/libpng/libpng_1.2.15~beta5-0.diff.gz libpng_1.2.15~beta5-0.dsc to pool/main/libp/libpng/libpng_1.2.15~beta5-0.dsc libpng_1.2.15~beta5.orig.tar.gz to pool/main/libp/libpng/libpng_1.2.15~beta5.orig.tar.gz A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Anibal Monsalve Salazar <[EMAIL PROTECTED]> (supplier of updated libpng package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 03 Dec 2006 14:47:41 +1100 Source: libpng Binary: libpng12-dev libpng12-0 libpng12-0-udeb libpng3 Architecture: source i386 all Version: 1.2.15~beta5-0 Distribution: unstable Urgency: high Maintainer: Anibal Monsalve Salazar <[EMAIL PROTECTED]> Changed-By: Anibal Monsalve Salazar <[EMAIL PROTECTED]> Description: libpng12-0 - PNG library - runtime libpng12-0-udeb - PNG library - minimal runtime library (udeb) libpng12-dev - PNG library - development libpng3- PNG library - runtime Closes: 401044 401423 401465 Changes: libpng (1.2.15~beta5-0) unstable; urgency=high . * New upstream release. - Fixed asm API functions not exported on amd64. Closes: #401044. - Fixed "libpng hangs when saving profile". Closes: #401423. * Fixed "Incorrect shlibs information". Closes: #401465. * Removed patches for png.h and pngconf.h. * Updated debian/watch. Files: 40a64ceecf92eb5053f1ef072976ba8a 721 libs optional libpng_1.2.15~beta5-0.dsc 77ca14fcee1f1f4d28123bd0b22d 829038 libs optional libpng_1.2.15~beta5.orig.tar.gz 9ea00b479e95687b0378f953d54acc9a 13622 libs optional libpng_1.2.15~beta5-0.diff.gz b1b40a48df76a1f5b82e10ec01c04e3e 185810 libs optional libpng12-0_1.2.15~beta5-0_i386.deb ef76535cb61f857b846b56d7863c2faa 171776 libdevel optional libpng12-dev_1.2.15~beta5-0_i386.deb efe91458c8ff3c84efac2d83a5a55f95 884 oldlibs optional libpng3_1.2.15~beta5-0_all.deb b17cda281c17e8616b6347c8dd636f62 67106 debian-installer extra libpng12-0-udeb_1.2.15~beta5-0_i386.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFFeouDipBneRiAKDwRAmK/AJ9n4f+NzQkrismi1ZSD5AecuErX0QCeIOoK B7roFA+xhRUtyLgKih6zWfA= =8d3V -END PGP SIGNATURE- - End forwarded message - -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please no shlib bumps! (forw) Bug#401044: marked as done (libpng12-dev: [AMD64] asm API functions not exported)
Le samedi 09 décembre 2006 à 11:35 +0100, Andreas Barth a écrit : > Hi, > > | * Fixed "Incorrect shlibs information". Closes: #401465. > --- libpng-1.2.15~beta5.orig/debian/libpng12-0.shlibs > +++ libpng-1.2.15~beta5/debian/libpng12-0.shlibs > @@ -0,0 +1,2 @@ > +libpng12 0 libpng12-0 (>= 1.2.15~beta5) > > WTF is that? An shlib bump in the last second? That prevents fixing > *any* package which builds against libpng12 to be fixed via unstable > during the full freeze. What a bad idea. > > Not amused. This is the result of uploading new versions adding new symbols in the first place. -- Josselin Mouette/\./\ "Do you have any more insane proposals for me?" signature.asc Description: Ceci est une partie de message numériquement signée
Re: please no shlib bumps! (forw) Bug#401044: marked as done (libpng12-dev: [AMD64] asm API functions not exported)
* Josselin Mouette ([EMAIL PROTECTED]) [061209 12:07]: > Le samedi 09 décembre 2006 à 11:35 +0100, Andreas Barth a écrit : > > Hi, > > > > | * Fixed "Incorrect shlibs information". Closes: #401465. > > --- libpng-1.2.15~beta5.orig/debian/libpng12-0.shlibs > > +++ libpng-1.2.15~beta5/debian/libpng12-0.shlibs > > @@ -0,0 +1,2 @@ > > +libpng12 0 libpng12-0 (>= 1.2.15~beta5) > > > > WTF is that? An shlib bump in the last second? That prevents fixing > > *any* package which builds against libpng12 to be fixed via unstable > > during the full freeze. What a bad idea. > > > > Not amused. > > This is the result of uploading new versions adding new symbols in the > first place. Joss, one question: You wrote in your changelog entry some time ago: libpng (1.2.8rel-5) unstable; urgency=low * drop_pass_width.patch: don't export png_pass_width, it's absolutely unnecessary. -- Josselin Mouette <[EMAIL PROTECTED]> Mon, 3 Oct 2005 20:18:43 +0200 Why was it unnecessary to export it, and why did packages FTBFS because of that (cf http://bugs.debian.org/399499)? Or did I miss something? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please no shlib bumps! (forw) Bug#401044: marked as done (libpng12-dev: [AMD64] asm API functions not exported)
Le samedi 09 décembre 2006 à 12:12 +0100, Andreas Barth a écrit : > Joss, one question: > You wrote in your changelog entry some time ago: > libpng (1.2.8rel-5) unstable; urgency=low > > * drop_pass_width.patch: don't export png_pass_width, it's absolutely > unnecessary. > > -- Josselin Mouette <[EMAIL PROTECTED]> Mon, 3 Oct 2005 20:18:43 +0200 > > Why was it unnecessary to export it, and why did packages FTBFS because > of that (cf http://bugs.debian.org/399499)? Or did I miss something? This symbol was added by enabling the assembly code, and at that moment vorlon asked me to unexport it. It looked safe at that moment, and packages didn't start to FTBFS because of the removal. The FTBFS bugs appearing probably mean that the patch needed to be updated. As the #ifdef PNG_HAVE_ASSEMBLER_COMBINE_ROW was replaced by #ifdef PNG_USE_PNGGCCRD, the logic around it has changed. The declaration probably needs to be moved directly to the C file using it so that it is not accessible to the application compiling against libpng. Furthermore, re-enabling this patch will not necessarily be enough to go back on the shlibs. I'm not 100% sure, but IIRC new symbols were added in 1.2.9, and maybe also in later versions. -- Josselin Mouette/\./\ "Do you have any more insane proposals for me?" signature.asc Description: Ceci est une partie de message numériquement signée
Bug#402287: ITP: pacman4console -- a console based pacman game
Package: wnpp Severity: wishlist Owner: Joao Eriberto Mota Filho <[EMAIL PROTECTED]> * Package name: pacman4console Version : 1.1 Upstream Author : Michael Billars <[EMAIL PROTECTED]> * URL : http://freshmeat.net/projects/pacmanforconsole * License : GPL Programming Lang: C Description : a console based pacman game This is a simple but very good pacman game. Also, its source code is very simple and well commencted so it may be a good reference for learning ncurses and C programming. Pacman4Console is an ASCII character based game. This game haves nine levels. But you can make you own levels. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-k7 Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
symlinks replaced by directories and vice versa
Hello, IMHO, one of the most frequently re-appearing issues in package-upgrades is symlinks in previous package versions replaced by directories in current versions and vice versa. Although the Debian policy clearly states in 6.6 (4) "A directory will never be replaced by a symbolic link to a directory or vice versa" it seems to me that many package maintainers cannot deal well with this behaviour or just don't know it. I personally filed lots of bug reports against lots of packages in the past regarding this issue. Unfortunately, this issue is typically not so easy to detect soon when it appears. Instead, such cases linger around a long time until eons later some unexpected overwrites happen or until you try to remove a package or something like this. I personally just detect them soon because I run daily filesystem-modification checks (in conjunction with debsums) and thus notice quickly when new files appear where no files out of the package managers scope should exist. Unfortunately, the issue appeared so often that at some point in the past I just resigned and gave up to file bug reports because of it and instead I began just to fix it on my systems locally and forget about it. However, since this is such a frequent source of bugs and since so many package maintainers seem not to be able to deal well with it, I'm asking myself, if it wouldn't make sense to change this behaviour to something which is more native to maintainers - i.e. automagically replace symlinks by directories and vice versa (which would natively equal a package upgrade to a package removal followed by an installation of the new version) or abort package installation if it occurs or something like this. I'm not sure if this is the right list to discuss that, but perhaps it's the best list to collect notions from others (especially package maintainers) about it. I know there *are* maintainers out there who *know* about this case and *do* handle it carefully and sometimes even *use* it intentionally, like the sendmail maintainer (although even there it makes problems because of undetected overwrites). However, I have never seen any single case where it was really necessary to package something this way. regards Mario -- talk softly and carry a keen sword -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: symlinks replaced by directories and vice versa
On Sat, Dec 09, 2006, Mario 'BitKoenig' Holbe wrote:
> However, since this is such a frequent source of bugs and since so many
> package maintainers seem not to be able to deal well with it, I'm asking
> myself, if it wouldn't make sense to change this behaviour to something
> which is more native to maintainers - i.e. automagically replace
> symlinks by directories and vice versa (which would natively equal a
> package upgrade to a package removal followed by an installation of the
> new version) or abort package installation if it occurs or something
> like this.
I agree it's counter-intuitive. I seem to recall someone told me it
was a feature of dpkg which allows local admin to e.g. ln -s /bigdisk
/usr/share. I'm not sure this is the correct explanation, but if it
is, then perhaps it would make more sense to support this functionality
at the dpkg level directly, perhaps in a similar fashion to diversions
("I want that anything that would be installed to /usr/share be
installed in $otherdir" sounds similar to what diversion currently do).
> I'm not sure if this is the right list to discuss that
(perhaps the dpkg list indeed)
--
Loïc Minier <[EMAIL PROTECTED]>
"I have no strong feelings one way or the other." -- Neutral President
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: symlinks replaced by directories and vice versa
On Sat, Dec 09, 2006 at 01:34:51PM +0100, Loïc Minier <[EMAIL PROTECTED]> wrote:
> On Sat, Dec 09, 2006, Mario 'BitKoenig' Holbe wrote:
> > However, since this is such a frequent source of bugs and since so many
> > package maintainers seem not to be able to deal well with it, I'm asking
> > myself, if it wouldn't make sense to change this behaviour to something
> > which is more native to maintainers - i.e. automagically replace
> > symlinks by directories and vice versa (which would natively equal a
> > package upgrade to a package removal followed by an installation of the
> > new version) or abort package installation if it occurs or something
> > like this.
>
> I agree it's counter-intuitive. I seem to recall someone told me it
> was a feature of dpkg which allows local admin to e.g. ln -s /bigdisk
> /usr/share. I'm not sure this is the correct explanation, but if it
> is, then perhaps it would make more sense to support this functionality
> at the dpkg level directly, perhaps in a similar fashion to diversions
> ("I want that anything that would be installed to /usr/share be
> installed in $otherdir" sounds similar to what diversion currently do).
Directory diversions is a very old feature request See #30126 and #33263.
And that could be sufficient to solve the issue.
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: symlinks replaced by directories and vice versa
Mario 'BitKoenig' Holbe <[EMAIL PROTECTED]> writes: > Hello, > > IMHO, one of the most frequently re-appearing issues in package-upgrades > is symlinks in previous package versions replaced by directories in > current versions and vice versa. > Although the Debian policy clearly states in 6.6 (4) "A directory will > never be replaced by a symbolic link to a directory or vice versa" it > seems to me that many package maintainers cannot deal well with this > behaviour or just don't know it. Afaik dpkg does not remember what is a link to and what is a directory in a package so it can't properly track that change in the package and can't differentiate it from the admin moving and linking a directory. That is the bad news. Now the good news. I think moving and linking directories could be forbidden and be replaced by moving and mount --bind. It avoids the pritfalls of symlinked dirs completly and provides all the features. ... > However, since this is such a frequent source of bugs and since so many > package maintainers seem not to be able to deal well with it, I'm asking > myself, if it wouldn't make sense to change this behaviour to something > which is more native to maintainers - i.e. automagically replace > symlinks by directories and vice versa (which would natively equal a > package upgrade to a package removal followed by an installation of the > new version) or abort package installation if it occurs or something > like this. I think post etch this could be a good idea. But someone has to dig into dpkg to implement it. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SUMMARY: Re: Dropping GStreamer 0.8 for etch
Loïc Minier wrote: >> - goobox > > Alternative programs available with a superset of the features, and an > active upstream. I'm waiting for a final ack of the maintainer that > the alternatives are indeed okay and that we can proceed with removal. If goobox's unique feature is remote audio CD playback it won't need need gstreamer's ffmpeg support for it, so dropping ffmpeg support might be a solution if the removal of goobox is not possible. > As soon as the above issues are cleared in testing, I'll request the > removal of the GStreamer 0.8 suite of testing and unstable. Thanks for resolving this! Cheers Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping GStreamer 0.8 for etch
Josselin Mouette wrote: > By hiding behind upstream, you're simply refusing to fix the problem. > The patch is a hack that is only guaranteed to work on a Debian system, > and upstream will refuse it until it is done in a proper way. This is > not how things work. Forwarding fixes upstream is important but it > doesn't come before fixing the Debian bug. > >> > As the situation is very similar in mplayer, mplayer is considered >> > RC-buggy by the security team. There was an exception for >> > gstreamer-ffmpeg because it was considered too difficult to fix, but I >> > don't think this is justified and this should be considered >> > release-critical as well. >> >> Again, nothing new. As you state yourself, this was already discussed >> and an exception was granted. Beside, you miss the important point >> that gst-ffmpeg heavily patches (read: "replaces") the ffmpeg build >> system, wihle mplayer has a close-to-vanilla ffmpeg tree. > > The exception was granted because of this assumption, which is *entirely > wrong*, as gst-ffmpeg ships a vanilla ffmpeg tree. It took me less than > one hour to figure it out and to build a working package with the Debian > ffmpeg library. > >> "Dropping GStreamer 0.8 for etch" is not "building gst-ffmpeg against >> Debian's ffmpeg"; any of these changes can be achieved in whatever >> order, these are orthogonal, even if both would help security support >> (in a different way). As I'm not considering building gst-ffmpeg >> against ffmpeg for etch, I kindly suggest we let this subthread die or >> be continued in the upstream bug report where it would be more useful. > > As the security people are the ones being really affected, I would like > to have Moritz' input on this matter. Are you ready to grant an > exception to gstreamer-ffmpeg and not to mplayer while the situation of > both packages is strictly identical? When preparing DSA-992 for ffmpeg I looked at other packages embedding libavcodec and IIRC gst-ffmpeg's copy was forked at that time. If it's technically feasible to fix gst-ffmpeg 0.10 to link dynamically against etch's libavcodec that would be of course the preferred solution, especially if it should bring in new bugfixes/features (that's what I understood about your previous comment about H264?) However, we're rather late in the release cycle and if Loic as one of the GNOME maintainers thinks that adapting gst-ffmpeg is too risky or not possible w/o regressions in the depending apps that would be understandable. OTOH you're among the GNOME maintainers as well and should have the full picture as well, so I'm a bit confused. I'd conclude to: 1. Let's all avoid flames (the latest followups have become too hostile) and concentrate on an Etch release, which kicks ass. 2. If the GNOME maintainers come to an agreement that linking dynamically is possible it would be _much_ appreciated, if not we need to bite the bullet. And for mplayer; it provides dynamic linking out of the box and it's not an important infrastructure package like gstreamer, so the above does not apply. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping GStreamer 0.8 for etch
Le samedi 09 décembre 2006 à 15:36 +0100, Moritz Muehlenhoff a écrit : > 2. If the GNOME maintainers come to an agreement that linking dynamically >is possible it would be _much_ appreciated, if not we need to bite the >bullet. I have made a new patch which is much cleaner and opened a bug about it. So far Loïc hasn't commented on it, but AIUI he's still hostile to such a change until it is accepted upstream. I don't claim to have extensively tested the patch, especially with exotic codecs, but it shows that dynamic linking is possible, and it makes a better package at first sight - but version 0.10.2 should improve codec support as well. > And for mplayer; it provides dynamic linking out of the box and it's not > an important infrastructure package like gstreamer, so the above does not > apply. Well, totem-xine is still the default in etch, which means gstreamer-ffmpeg is only important for people explicitly installing totem-gstreamer. However the reason until now for xine to be the default was its superior codec support. If both packages can link to the same libavcodec, I think totem-gstreamer is superior, as being lighter, not having the infamous bug #400525 and with better support for other (non-ffmpeg) codecs. -- Josselin Mouette/\./\ "Do you have any more insane proposals for me?" signature.asc Description: Ceci est une partie de message numériquement signée
Re: Dropping GStreamer 0.8 for etch
On Sat, Dec 09, 2006 at 05:23:47PM +0100, Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le samedi 09 décembre 2006 à 15:36 +0100, Moritz Muehlenhoff a écrit : > > 2. If the GNOME maintainers come to an agreement that linking dynamically > >is possible it would be _much_ appreciated, if not we need to bite the > >bullet. > > I have made a new patch which is much cleaner and opened a bug about it. > So far Loïc hasn't commented on it, but AIUI he's still hostile to such > a change until it is accepted upstream. > > I don't claim to have extensively tested the patch, especially with > exotic codecs, but it shows that dynamic linking is possible, and it > makes a better package at first sight - but version 0.10.2 should > improve codec support as well. > > > And for mplayer; it provides dynamic linking out of the box and it's not > > an important infrastructure package like gstreamer, so the above does not > > apply. > > Well, totem-xine is still the default in etch, which means > gstreamer-ffmpeg is only important for people explicitly installing > totem-gstreamer. However the reason until now for xine to be the default > was its superior codec support. If both packages can link to the same > libavcodec, I think totem-gstreamer is superior, as being lighter, not > having the infamous bug #400525 and with better support for other > (non-ffmpeg) codecs. Except that gstreamer 0.10 still doesn't support DVD playback (which is a regression over gstreamer 0.8). Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping GStreamer 0.8 for etch
Le samedi 09 décembre 2006 à 17:28 +0100, Mike Hommey a écrit : > > Well, totem-xine is still the default in etch, which means > > gstreamer-ffmpeg is only important for people explicitly installing > > totem-gstreamer. However the reason until now for xine to be the default > > was its superior codec support. If both packages can link to the same > > libavcodec, I think totem-gstreamer is superior, as being lighter, not > > having the infamous bug #400525 and with better support for other > > (non-ffmpeg) codecs. > > Except that gstreamer 0.10 still doesn't support DVD playback (which is > a regression over gstreamer 0.8). Ah, you're right, I always forget about this one. Which will probably lead us to stick with totem-gstreamer for quite a moment, then. -- Josselin Mouette/\./\ "Do you have any more insane proposals for me?" signature.asc Description: Ceci est une partie de message numériquement signée
Re: Names of ROOT packages in Debian
On Friday 08 December 2006 17:29, Florian Weimer wrote: > "root-project" instead of "root" could solve the problem. It's not > just that the name is too generic, your users might assume that > root-tail and root-portal are part of your packages. > > But you really need to get ftpmaster feedback. This isn't something > that should be resolved by a popular vote. I do not like "project" in the package name too much. If you think of how "www.r-project.org" is presented in Debian (as r-..) then it would sound strange to me to add "project" to a project that does not have "project" in its name. The problem of the ambiguity of the term "root" remains. Preferable to me would be to have the name of the institute as a prefix, which would make it cern-root-... or libcern-root-..., much analogous how the products of the NCBI are treated in Debian. Steffen pc02:/nfshome/moeller # apt-cache search ncbi | cut -f1 -d\ | grep ncbi libncbi6 libncbi6-dbg libncbi6-dev ncbi-data ncbi-epcr ncbi-epcr-data ncbi-tools-bin ncbi-tools-x11 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFP: tp-smapi -- exposes some features of the ThinkPad - first packaging attempt
On Fri, 8 Dec 2006 18:48:40 +0100 Evgeni Golov wrote: > You can find the packages at > http://debian.die-welt.net/pool/main/tp-smapi/ - I would love to see > much feedback, because this is my first real packaging attemt (but > neither lintian nor linda do complain). I've impoved the packages a bit, HDAPS is now built and superseeds the one from the kernel (thanks waldi!), there is no more dependency on dpatch and I've written some more lines in README.Debian (even still not enough). Happy testing, Evgeni -- ^^^| Evgeni -SargentD- Golov ([EMAIL PROTECTED]) d(O_o)b | PGP-Key-ID: 0xAC15B50C >-|-< | WWW: http://www.die-welt.net ICQ: 54116744 / \| IRC: #sod @ irc.german-freakz.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping GStreamer 0.8 for etch
On Sat, Dec 09, 2006 at 05:31:47PM +0100, Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le samedi 09 décembre 2006 à 17:28 +0100, Mike Hommey a écrit : > > > Well, totem-xine is still the default in etch, which means > > > gstreamer-ffmpeg is only important for people explicitly installing > > > totem-gstreamer. However the reason until now for xine to be the default > > > was its superior codec support. If both packages can link to the same > > > libavcodec, I think totem-gstreamer is superior, as being lighter, not > > > having the infamous bug #400525 and with better support for other > > > (non-ffmpeg) codecs. > > > > Except that gstreamer 0.10 still doesn't support DVD playback (which is > > a regression over gstreamer 0.8). > > Ah, you're right, I always forget about this one. Which will probably > lead us to stick with totem-gstreamer for quite a moment, then. I guess you meant totem-xine. Note that upstream is going to switch to totem-gstreamer by default soon. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402351: ITP: imsniff -- Simple program to log Instant Messaging activity on the network
Package: wnpp Severity: wishlist Owner: Amaya Rodrigo Sastre <[EMAIL PROTECTED]> * Package name: imsniff Version : 0.04 Upstream Author : Carlos Fernandez <[EMAIL PROTECTED]> * URL : http://sourceforge.net/projects/im-snif/ * License : GPLv2 Programming Lang: C++ Description : Simple program to log Instant Messaging activity on the network The imsniff program can be used to log IM activity on the network. It uses libpcap to capture packets and analyzes them, logging conversation, contact lists, etc. Users connecting after imsniff is started can get pretty good results, including complete contact lists and events (displaying a name change, for example). Users already connected will be able to get the conversations, but will miss the other information. The only required parameter is the interface name to listen to. This can be any interface that libpcap supports. A sample imsniff.conf.sample file is included. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) -- ·''`. If I can't dance to it, it's not my revolution : :' :-- Emma Goldman `. `' Proudly running Debian GNU/Linux (unstable) `- www.amayita.com www.malapecora.com www.chicasduras.com
Re: Names of ROOT packages in Debian
* Steffen Moeller: > I do not like "project" in the package name too much. If you think of > how "www.r-project.org" is presented in Debian (as r-..) then it would sound > strange to me to add "project" to a project that does not have "project" in > its name. It's less confusing than "root-system", I think. After all, this hasn't got to do anything with file systems. > The problem of the ambiguity of the term "root" remains. Preferable to me > would be to have the name of the institute as a prefix, which would make it > cern-root-... or libcern-root-..., much analogous how the products of the > NCBI are treated in Debian. This sounds like a good idea to me. For extra safety, you should ask the CERN folks if they agree. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
blocking bugs [Re: BTS: Why no "invalid" or "notabug" tag?]
On Sat, 09 Dec 2006, Marc Haber wrote: > What happens to a bug when it's blocked? Nothing, besides a little link in to the blockee's information to the blocker's page. > Which operations do behave as if the bug were not blocked, All. > which operations behave differently, None. > and what's the behavioral difference between being blocked and not? Besides the display above, there is no difference. This all may change at some point in the future, but since that's the way it works now, the documentation is pretty complete. Don Armstrong -- "The question of whether computers can think is like the question of whether submarines can swim." -- Edsgar Dijkstra http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#402193: ITP: macbook-backlight -- Program to change the brightness of Apple MacBook
Le 08.12.2006, à 21:08:49, Enrico Tassi a écrit: > Package: wnpp > Severity: wishlist > Owner: Enrico Tassi <[EMAIL PROTECTED]> > > > * Package name: macbook-backlight > Version : > Upstream Author : Ryan Lortie <[EMAIL PROTECTED]> > * URL : http://desrt.mcmaster.ca/code/macbook-backlight/ > * License : GPL > Programming Lang: C > Description : Program to change the brightness of Apple MacBook > > A simple C program to change the brightness of the MacBook display > tweaking some hardware registers. It works for the first (Core Duo) and > the second (Core 2 Duo) generation of MacBook. You can also have a look at the different (and maybe more actively maintained) version available from [1]. Maybe it would be a good idea to have a Debian package containing the different tools available at [2] instead of just the backlight tool. The other interesting tools are: - keyboard_brigthness - macbook-led - temperature (of the CPU) - hdaps-gl (GL-based laptop model that rotates in real-time via hdaps) These are 2 shell scripts and 2 small C programs. It would be a waste of resources to have a Debian package for each of these. I also propose myself as co-maintainer. I have a write svn access to the upstream repository. Regards, [1] http://svn.sourceforge.net/viewvc/mactel-linux/trunk/tools/backlight/ [2] http://svn.sourceforge.net/viewvc/mactel-linux/trunk/tools/ -- Dr. Ludovic Rousseau[EMAIL PROTECTED] -- Normaliser Unix c'est comme pasteuriser le camembert, L.R. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#402266: RFP: sxemacs --
On Sat, 2006-12-09 at 08:56 +0300, Kirill A. Korinskiy wrote: > Package: wnpp > Severity: wishlist > > * Package name: sxemacs > Version : 22.1.6 > Upstream Author : > * URL or Web page : http://sxemacs.org/ > * License : GPL > Description : > So, the old addage: UNIX, a process that runs under emacs. Needs to be changed: Debian, a process that runs under sxemacs. That is after reading the main page: * SXEmacs is my Window Manager. * SXEmacs is my login shell. * SXEmacs is my image viewer. * SXEmacs is my mp3 player. * SXEmacs balances my cheque book. * SXEmacs can do the math. * SXEmacs lets me communicate with my friends. * SXEmacs helps me with my databases. * SXEmacs makes VC comfortable. * SXEmacs helps with my security. Plus the features sxemacs has that xemacs dunnah. Nice. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: Ondemand governor by default in etch
Matthew Garrett wrote: > p4-clockmod is entirely useless. It's high-latency and doesn't drop the > core voltage. Nice. Is there a good alternative for P4 machines? Is the ACPI one any better (assuming a semi-sane BIOS)? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ondemand governor by default in etch
Anthony DeRobertis <[EMAIL PROTECTED]> wrote: > Matthew Garrett wrote: >> p4-clockmod is entirely useless. It's high-latency and doesn't drop the >> core voltage. > > Nice. Is there a good alternative for P4 machines? Is the ACPI one any > better (assuming a semi-sane BIOS)? It really depends on the hardware - not all P4s support voltage scaling, and without that you'll see no useful effects. The acpi driver is certainly worth a go, as is speedstep-ich (which /might/ work, but I wouldn't be optimistic). Just to elaborate on why p4-clockmod isn't terribly useful: modern CPUs expose multiple degrees of chip-level power management (C states in ACPI speak). C1 is equivilent to having the idle loop use the hlt instruction, and results in lower power usage. C2 is similar to the old APM idle modes, which allowed the processor power down even more of itself. Modern chips tend to support C3 and C4 states, in which the CPU actually disconnects itself from the bus and is pretty much unclocked. At that point, the frequency of the CPU is fairly unimportant. Simply throttling down the processor won't cause any significant reduction in power consumption, since most of what's left switched on would be drawing that much power anyway. Dropping the core voltage, however, is an obvious win - since power consumption is v^2/r, you're saving the square of the amount you've reduced it by. So p4-clockmod doesn't really help you in the case of an entirely idle CPU. And in the more common case of a CPU that /isn't/ entire idle, it can be more harm than good. Halving the speed of the chip means that you're awake for twice as long as you would otherwise be, which may mean that you don't get long enough to drop into the deeper sleep states. Intel's presented figures (at last year's OLS, I think) that suggest that p4-clockmod and straightforward throttling aren't useful approaches to dealing with power consumption. The main reason for the methods being implemented is to deal with cases where a loaded CPU is becoming too hot - the hardware has no way to prevent the OS from scheduling more work, so instead it slows down to reduce heat output. Instantaneous power consumption is reduced, but it now takes twice as long for your job to complete and your hard drive hasn't halved the amount of power it's consuming. If you own a machine that doesn't implement the ACPI interface to throttling (/proc/acpi/processor/*/throttling), then p4-clockmod may be required in order to allow the OS to respond to high temperatures. On the other hand, if you're not in that situation, it's probably more harm than good. There's a few laptops around that don't implement C3 or C4 states, and it might be beneficial there as well. Otherwise, just skip it. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
