Bug#701830: vlc: FTBFS on powerpcspe (illegal insns due to -mtune=G4)
Am Mittwoch, den 27.02.2013, 18:47 +0100 schrieb Roland Stigge: As you can see above, -mtune=G4 is used by default, leading to the above illegal instructions. The attached patch fixes this by enabling altivec only on powerpc _except_ powerpcspe, and doing confflags += --with-tuning=8548 which is propagated to gcc as -mtune=8548 on powerpcspe. Your patch logic looks complicated (multiple filters). What are the values of DEB_HOST_ARCH DEB_HOST_ARCH_CPU on powerpc and powerpcspe? -- Benjamin Drung Debian Ubuntu Developer ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#701830: vlc: FTBFS on powerpcspe (illegal insns due to -mtune=G4)
Hi, On 03/01/2013 03:43 PM, Benjamin Drung wrote: Am Mittwoch, den 27.02.2013, 18:47 +0100 schrieb Roland Stigge: As you can see above, -mtune=G4 is used by default, leading to the above illegal instructions. The attached patch fixes this by enabling altivec only on powerpc _except_ powerpcspe, and doing confflags += --with-tuning=8548 which is propagated to gcc as -mtune=8548 on powerpcspe. Your patch logic looks complicated (multiple filters). What are the values of DEB_HOST_ARCH DEB_HOST_ARCH_CPU on powerpc and powerpcspe? On powerpcspe, we have the following settings: DEB_HOST_ARCH=powerpc DEB_HOST_ARCH_CPU=powerpcspe The two filters on the patch are just used to detect the case of powerpc in general, but excluding the powerpcspe case (a special case of powerpc). Resulting in powerpc- for the case with altivec. In all other cases (including powerpcspe and non-powerpc), we disable altivec. Roland ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#664998: marked as done (Too much CPU used)
Your message dated Fri, 1 Mar 2013 10:30:24 -0500 with message-id CAEcnbVzTjjvCdSsDuw5QwEkFR=ijavr3mo-iievq94dv4he...@mail.gmail.com and subject line Closing unreproducible/moreinfo. has caused the Debian Bug report #664998, regarding Too much CPU used to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 664998: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664998 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: mpg123 Version: 1.12.1-3.2 Severity: wishlist It is long time since I last used mpg123, but it used to be the lowest consuming of all players, today I played a song (typical 128 kb/s joint stereo encoding) and saw it take 23% CPU on my AMD Athlon(tm) 64 Processor 3000+, I have just played the very same file under audacious and it was always under 3%, so I guess something is wrong here. I tried to investigate, as I saw it was using x86-64 (SSE) for decoding, to see if I was able to select a more standard decoder, but it seems that the only ones compiled on amd64 are: x86-64 generic generic_dither and choosing generic was even worse, 31% of CPU eaten. Wow, I have done more tests right now and saw that this was due to using -v, I mean, if I play it without -v it takes under 3% and if I run it with -v it goes to 30-40%. I was reporting this bug thinking it was a problem in our building of the package, but it seems that there is a problem in how -v is implemented, thus I'd say it is an upstream thing. I don't know what else to add here, if you are not able to reproduce it or need more info just add for it. Regards. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/1 CPU core) Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mpg123 depends on: ii libc62.13-27 ii libltdl7 2.4.2-1 ii libmpg123-0 1.12.1-3.2 Versions of packages mpg123 recommends: ii libasound2 1.0.25-2 ii oss-compat 2 Versions of packages mpg123 suggests: ii libasound21.0.25-2 ii libaudio2 1.9.3-4 ii libesd0 0.2.41-10+b1 ii libjack0 [libjack-0.116] 1:0.121.3+20120222git81e8f031-1 ii libpulse0 1.1-3 -- no debconf information ---End Message--- ---BeginMessage--- Closing since it's not reproducible and almost a year since the moreinfo tag.---End Message--- ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#701830: vlc: FTBFS on powerpcspe (illegal insns due to -mtune=G4)
Hi, On 03/01/2013 06:08 PM, Benjamin Drung wrote: DEB_HOST_ARCH DEB_HOST_ARCH_CPU on powerpc and powerpcspe? On powerpcspe, we have the following settings: DEB_HOST_ARCH=powerpc DEB_HOST_ARCH_CPU=powerpcspe Isn't it the other way around? Of course, sorry! The two filters on the patch are just used to detect the case of powerpc in general, but excluding the powerpcspe case (a special case of powerpc). Resulting in powerpc- for the case with altivec. In all other cases (including powerpcspe and non-powerpc), we disable altivec. What do you think about the alternative attached patch? diff --git a/debian/rules b/debian/rules index 4d3c5dc..3203434 100755 --- a/debian/rules +++ b/debian/rules @@ -193,14 +193,19 @@ confflags += --disable-neon removeplugins += neon endif -# PowerPC specific optimizations -ifneq ($(filter $(DEB_HOST_ARCH_CPU),powerpc),) +# PowerPC specific optimizations (excluding powerpcspe) +ifeq (,$(filter-out powerpc,$(DEB_HOST_ARCH_CPU))$(filter powerpcspe,$(DEB_HOST_ARCH))) confflags += --enable-altivec else confflags += --disable-altivec removeplugins += altivec endif Effect should be equivalent to my proposal. +# PowerPCSPE specific optimizations +ifeq (,$(filter-out powerpcspe,$(DEB_HOST_ARCH)) This line looks more complicated to me than my original proposal, but should be equivalent for our purposes. Finally, maybe a matter of taste. So this patch would be fine for powerpcspe, also Thanks, Roland ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#699470: crystalhd-dkms: Kernel null pointer BUG in crystalhd_dioq_fetch_wait()
It looks like the crystalhd drivers are buggy with newer kernel releases. I opt for removing the dkms package. I will do this over the weekend. On Thu, Feb 28, 2013 at 4:52 PM, thomas schorpp thomas.scho...@gmail.com wrote: On 28.02.2013 20:41, Julien Cristau wrote: On Thu, Jan 31, 2013 at 19:25:50 +0100, tom schorpp wrote: Package: crystalhd-dkms Version: 1:0.0~git20110715.fdd2f19-7 Severity: critical Tags: patch Justification: breaks the whole system Reproducible NULL pointer BUG at crystalhd-0.0~git20110715.fdd2f19/driver/linux/crystalhd_misc.c:515, triggered by adobe flash plugin from dmo repo, ffmpeg, mplayer, bino or other, mostly on heavy ioq usage or after FETCH_TIMEOUT and/or unclosed driver HANDLEs. Does the maintainer or somebody on pkg-multimedia plan on fixing this RC bug? If not I'll consider a NMU removing the dkms package from crystalhd source. Cheers, Julien Known linux-media Maintainers STAGING - CRYSTAL HD VIDEO DECODER M:Naren Sankar nsan...@broadcom.com M:Jarod Wilson ja...@wilsonet.com M:Scott Davilla davi...@4pi.com M:Manu Abraham abraham.m...@gmail.com seem to have left the Broadcom's legacy driver code, focusing on the new linux-media staging driver, but limited time, one stated lately on the linux-media/LKML, nothing read from the others. I could adapt it to new kernel releases the next 2-3 years, but nothing more, not a experienced kernel driver coder, no debian package/policy maintaining motivation because I do not use dkms or debian kernels packages. If my last patch applies to Your codebase in the debian git repository (mine is from git.linuxtv.org, according to the git changelog more advanced in the gstreamer plugin, merge?) You may consider it hotfixed and release with known multithreading (gstreamer based transcoders/matroska demuxers) and PM ACPI S3 issues? Has not crashed here any more, nor notable side effects with usual playback use cases, including Totem (gstreamer). y tom ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers -- ~ Andres ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#701830: vlc: FTBFS on powerpcspe (illegal insns due to -mtune=G4)
Am Freitag, den 01.03.2013, 16:05 +0100 schrieb Roland Stigge: Hi, On 03/01/2013 03:43 PM, Benjamin Drung wrote: Am Mittwoch, den 27.02.2013, 18:47 +0100 schrieb Roland Stigge: As you can see above, -mtune=G4 is used by default, leading to the above illegal instructions. The attached patch fixes this by enabling altivec only on powerpc _except_ powerpcspe, and doing confflags += --with-tuning=8548 which is propagated to gcc as -mtune=8548 on powerpcspe. Your patch logic looks complicated (multiple filters). What are the values of DEB_HOST_ARCH DEB_HOST_ARCH_CPU on powerpc and powerpcspe? On powerpcspe, we have the following settings: DEB_HOST_ARCH=powerpc DEB_HOST_ARCH_CPU=powerpcspe Isn't it the other way around? The two filters on the patch are just used to detect the case of powerpc in general, but excluding the powerpcspe case (a special case of powerpc). Resulting in powerpc- for the case with altivec. In all other cases (including powerpcspe and non-powerpc), we disable altivec. What do you think about the alternative attached patch? -- Benjamin Drung Debian Ubuntu Developer diff --git a/debian/rules b/debian/rules index 4d3c5dc..3203434 100755 --- a/debian/rules +++ b/debian/rules @@ -193,14 +193,19 @@ confflags += --disable-neon removeplugins += neon endif -# PowerPC specific optimizations -ifneq ($(filter $(DEB_HOST_ARCH_CPU),powerpc),) +# PowerPC specific optimizations (excluding powerpcspe) +ifeq (,$(filter-out powerpc,$(DEB_HOST_ARCH_CPU))$(filter powerpcspe,$(DEB_HOST_ARCH))) confflags += --enable-altivec else confflags += --disable-altivec removeplugins += altivec endif +# PowerPCSPE specific optimizations +ifeq (,$(filter-out powerpcspe,$(DEB_HOST_ARCH)) +confflags += --with-tuning=8548 +endif + %: dh $@ --parallel --with autoreconf ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
tvheadend for Debian
Hi Adam, I just stumbled upon XBMC and noticed it would be a valuable replacement for my current VDR setup and figured I'd probably need tvheadend if I want to keep watching the DVB-T channels I currently enjoy. And as I'm a Debian developer, needing to install non-Debian software irritates me quite a lot. I therefore started to look around for suitable packages, and even considered packaging it myself for Debian. But you are apparently maintaining a Ubuntu PPA for tvheadend. So would you be interested in integrating tvheadend properly into Debian? From filing an ITP to uploading it into the archive, I'd be happy to assist in the process. I'd be happy to hear back from you. Cheers, OdyX ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#699470: crystalhd-dkms: Kernel null pointer BUG in crystalhd_dioq_fetch_wait()
On 01.03.2013 18:36, Andres Mejia wrote: It looks like the crystalhd drivers are buggy with newer kernel releases. I opt for removing the dkms package. I will do this over the weekend. Top posting on list and removal announce without valid bug report for Your claimed issue and any confirmation? Driver does not behave different from linux 3.2...3.7.1 here, see my posts on the linux-media list, xbmc people? y tom On Thu, Feb 28, 2013 at 4:52 PM, thomas schorpp thomas.scho...@gmail.com wrote: On 28.02.2013 20:41, Julien Cristau wrote: On Thu, Jan 31, 2013 at 19:25:50 +0100, tom schorpp wrote: Package: crystalhd-dkms Version: 1:0.0~git20110715.fdd2f19-7 Severity: critical Tags: patch Justification: breaks the whole system Reproducible NULL pointer BUG at crystalhd-0.0~git20110715.fdd2f19/driver/linux/crystalhd_misc.c:515, triggered by adobe flash plugin from dmo repo, ffmpeg, mplayer, bino or other, mostly on heavy ioq usage or after FETCH_TIMEOUT and/or unclosed driver HANDLEs. Does the maintainer or somebody on pkg-multimedia plan on fixing this RC bug? If not I'll consider a NMU removing the dkms package from crystalhd source. Cheers, Julien Known linux-media Maintainers STAGING - CRYSTAL HD VIDEO DECODER M:Naren Sankar nsan...@broadcom.com M:Jarod Wilson ja...@wilsonet.com M:Scott Davilla davi...@4pi.com M:Manu Abraham abraham.m...@gmail.com seem to have left the Broadcom's legacy driver code, focusing on the new linux-media staging driver, but limited time, one stated lately on the linux-media/LKML, nothing read from the others. I could adapt it to new kernel releases the next 2-3 years, but nothing more, not a experienced kernel driver coder, no debian package/policy maintaining motivation because I do not use dkms or debian kernels packages. If my last patch applies to Your codebase in the debian git repository (mine is from git.linuxtv.org, according to the git changelog more advanced in the gstreamer plugin, merge?) You may consider it hotfixed and release with known multithreading (gstreamer based transcoders/matroska demuxers) and PM ACPI S3 issues? Has not crashed here any more, nor notable side effects with usual playback use cases, including Totem (gstreamer). y tom ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#702025: (no subject)
Package: libdiscid0 Version: 0.2.2-3 Package could not be downloaded by apt-get because of different size. After installing by hand from the web 'apt-get dist-upgrade' fails to upgrade it every time. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processed: Re: Bug#702025: (no subject)
Processing control commands: tags -1 moreinfo unreproducible Bug #702025 [libdiscid0] (no subject) Added tag(s) unreproducible and moreinfo. -- 702025: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702025 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#702025: (no subject)
Control: tags -1 moreinfo unreproducible On 2013-03-01 21:09:07, TrialAndError wrote: Package could not be downloaded by apt-get because of different size. After installing by hand from the web 'apt-get dist-upgrade' fails to upgrade it every time. Looks like mirror problems to me. What are the exact commands that you're running and the exact error message? Regards -- Sebastian Ramacher signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#699470: crystalhd-dkms: Kernel null pointer BUG in crystalhd_dioq_fetch_wait()
On 01.03.2013 18:36, Andres Mejia wrote: It looks like the crystalhd drivers are buggy with newer kernel releases. I opt for removing the dkms package. I will do this over the weekend. Driver is maintainable and supported up to at least Linux 3.8 series, when we'll have 4.0 in debian stable, 2015? schorpp@tom3:/mnt/data/usr/local/src/crystalhd/driver/linux$ make clean rm -f *.map *.list *.o *.ko crystalhd.mod.c crystalhd_lnx.o crystalhd_misc.o crystalhd_cmds.o crystalhd_hw.o crystalhd_linkfuncs.o crystalhd_fleafuncs.o crystalhd_flea_ddr.o schorpp@tom3:/mnt/data/usr/local/src/crystalhd/driver/linux$ schorpp@tom3:/mnt/data/usr/local/src/crystalhd/driver/linux$ make make -C /lib/modules/3.8.1/build SUBDIRS=/mnt/data/usr/local/src/crystalhd/driver/linux modules make[1]: Entering directory `/mnt/data/usr/local/src/linux-laststable' CC [M] /mnt/data/usr/local/src/crystalhd/driver/linux/crystalhd_lnx.o CC [M] /mnt/data/usr/local/src/crystalhd/driver/linux/crystalhd_misc.o CC [M] /mnt/data/usr/local/src/crystalhd/driver/linux/crystalhd_cmds.o CC [M] /mnt/data/usr/local/src/crystalhd/driver/linux/crystalhd_hw.o CC [M] /mnt/data/usr/local/src/crystalhd/driver/linux/crystalhd_linkfuncs.o CC [M] /mnt/data/usr/local/src/crystalhd/driver/linux/crystalhd_fleafuncs.o CC [M] /mnt/data/usr/local/src/crystalhd/driver/linux/crystalhd_flea_ddr.o LD [M] /mnt/data/usr/local/src/crystalhd/driver/linux/crystalhd.o Building modules, stage 2. MODPOST 1 modules CC /mnt/data/usr/local/src/crystalhd/driver/linux/crystalhd.mod.o LD [M] /mnt/data/usr/local/src/crystalhd/driver/linux/crystalhd.ko make[1]: Leaving directory `/mnt/data/usr/local/src/linux-laststable' schorpp@tom3:/mnt/data/usr/local/src/crystalhd/driver/linux$ Builds without warnings with my patches. schorpp@tom3:~$ uname -a Linux tom3 3.8.1 #12 SMP PREEMPT Fri Mar 1 20:41:00 CET 2013 x86_64 GNU/Linux schorpp@tom3:~$ hellobcm starting up Running DIL (3.22.0) Version DtsDeviceOpen: Opening HW in mode 0 Clock set to 180 Setting Color Mode to 1 try calls done Unable to open input file DtsAllocIoctlData Error schorpp@tom3:~$ dmesg |grep crystal [6.426460] Loading crystalhd v3.10.1 [6.426515] crystalhd :03:00.0: Starting Device:0x1612 [6.429600] crystalhd :03:00.0: irq 51 for MSI/MSI-X [ 99.896730] crystalhd :03:00.0: Opening new user[0] handle [ 102.604770] crystalhd :03:00.0: Closing user[0] handle via ioctl with mode 1c200 [ 243.648468] crystalhd :03:00.0: Opening new user[0] handle [ 246.325373] crystalhd :03:00.0: Closing user[0] handle via ioctl with mode 1c200 [ 334.105537] crystalhd :03:00.0: Opening new user[0] handle [ 336.776957] crystalhd :03:00.0: Closing user[0] handle via ioctl with mode 1c200 [ 510.322855] crystalhd :03:00.0: Opening new user[0] handle [ 510.577299] crystalhd :03:00.0: Closing user[0] handle with mode [ 510.781740] crystalhd :03:00.0: Opening new user[0] handle [ 511.036308] crystalhd :03:00.0: Closing user[0] handle with mode [ 511.240825] crystalhd :03:00.0: Opening new user[0] handle [ 513.801093] crystalhd :03:00.0: [FMT CH] PIB:0 ff 420 6 2d0 162 2d0 0 0 0 [ 513.921604] crystalhd :03:00.0: MISSING 3 PICTURES [ 514.587208] crystalhd :03:00.0: Closing user[0] handle via ioctl with mode 1c200 [ 535.989772] crystalhd :03:00.0: Opening new user[0] handle [ 536.244314] crystalhd :03:00.0: Closing user[0] handle with mode [ 536.448772] crystalhd :03:00.0: Opening new user[0] handle [ 536.703282] crystalhd :03:00.0: Closing user[0] handle with mode [ 536.907816] crystalhd :03:00.0: Opening new user[0] handle [ 539.435257] crystalhd :03:00.0: [FMT CH] PIB:0 ff 420 6 2d0 162 2d0 0 0 0 [ 539.508317] crystalhd :03:00.0: MISSING 3 PICTURES [ 616.455975] crystalhd :03:00.0: Closing user[0] handle via ioctl with mode 1c200 schorpp@tom3:~$ Loads and runs with Totem and MPlayer. root@tom3:~# lspci -vvv -s 03:00.0 |grep Sta Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR+ PERR- INTx- Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME- DevSta:CorrErr+ UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkSta:Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- UESta:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol- CESta:RxErr+ BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ Status:InProgress- Status:NegoPending- InProgress- root@tom3:~# Some non-fatal pci errors, but lspci is usually reporting incorrectly here or my old pci-e host is pretty incompatible. So no technical reasons to drop the package? y tom ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org
Re: Bug#699470: crystalhd-dkms: Kernel null pointer BUG in crystalhd_dioq_fetch_wait()
On Fri, Mar 1, 2013 at 21:38:54 +0100, thomas schorpp wrote: So no technical reasons to drop the package? Until and unless the driver is in mainline, there's every reason to drop it. Cheers, Julien signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#699470: crystalhd-dkms: Kernel null pointer BUG in crystalhd_dioq_fetch_wait()
On Fri, Mar 1, 2013 at 12:36:03 -0500, Andres Mejia wrote: It looks like the crystalhd drivers are buggy with newer kernel releases. I opt for removing the dkms package. I will do this over the weekend. Thanks. Julien signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#699470: crystalhd-dkms: Kernel null pointer BUG in crystalhd_dioq_fetch_wait()
On 01.03.2013 21:55, Julien Cristau wrote: On Fri, Mar 1, 2013 at 21:38:54 +0100, thomas schorpp wrote: So no technical reasons to drop the package? Until and unless the driver is in mainline, there's every reason to drop it. Well, then drop all the other non-mainline drivers dkms packages, too. This is getting unserious, I wish You all much fun with more root holes in closed source vdpau GPU drivers. Thanks to Broadcom for the nice effort. Bye, tom ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: tvheadend for Debian
In short, no. I'm not interested in managing official packages in distro's etc... It's enough work just helping to maintain the code. Longer answer... We provide the launchpad PPA simply because it keeps most of our users happy and is the best way to get most users running up to date code. We will soon, hopefully, move the repo to self-hosted and then we'll probably include some additional packages. However if other people want to maintain a distro official package then I've no problem with that, though it'd be nice to maintain a dialog and ensure things are flowing back and forth etc... Adam On 1 March 2013 18:32, Didier 'OdyX' Raboud o...@debian.org wrote: Hi Adam, I just stumbled upon XBMC and noticed it would be a valuable replacement for my current VDR setup and figured I'd probably need tvheadend if I want to keep watching the DVB-T channels I currently enjoy. And as I'm a Debian developer, needing to install non-Debian software irritates me quite a lot. I therefore started to look around for suitable packages, and even considered packaging it myself for Debian. But you are apparently maintaining a Ubuntu PPA for tvheadend. So would you be interested in integrating tvheadend properly into Debian? From filing an ITP to uploading it into the archive, I'd be happy to assist in the process. I'd be happy to hear back from you. Cheers, OdyX ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#699470: crystalhd-dkms: Kernel null pointer BUG in crystalhd_dioq_fetch_wait()
On Fri, Mar 1, 2013 at 3:55 PM, Julien Cristau jcris...@debian.org wrote: On Fri, Mar 1, 2013 at 21:38:54 +0100, thomas schorpp wrote: So no technical reasons to drop the package? Until and unless the driver is in mainline, there's every reason to drop it. Cheers, Julien I just checked the crystalhd driver in the mainline kernel. The driver seems to be much better maintained over there than at linuxtv.org. See [1]. I'm going to drop the driver from linuxtv.org. If after I drop the package someone has some compelling reason to use the driver from linuxtv.org, they can submit another bug to the crystalhd package and explain why the linuxtv.org driver should be used. 1. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/staging/crystalhd -- ~ Andres ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
