Bug#736146: ITP: libnftnl -- nftables low-level userspace library
Package: wnpp Severity: wishlist Owner: Arturo Borrero Gonzalez * Package name: libnftnl Version : 0.1 Upstream Author : Pablo Neira Ayuso * URL : http://www.netfilter.org * License : GPL-2+ Programming Lang: C Description : nftables low-level userspace library libnftables was renamed upstream to libnftnl. Previous ITP of libnftables: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708102 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140120100145.5170.41346.report...@r2d2.cica.es
Re: mupdf (was: xpdf removed from testing?)
On Mon, Jan 20, 2014 at 4:34 AM, Jens Oliver John wrote: >> $ apt-cache show mupdf >> MuPDF is a lightweight PDF viewer and toolkit written in portable C. >> (...) > > The mupdf PDF reader is supposed to be minimal and makes on me the impression > of > being more a reference implementation using the mupdf library. > > A more featureful but still light PDF reader, which is able to utilize mupdf > as > the rendering backend, is zathura (in Debian) with the mupdf rendering backend > (not in Debian [1]). > > The zathura upstream is very lively and is constantly gaining features. > > It may be my personal perception, but the fidelity of the PDF rendering in > mupdf > is *vastly* superior to xpdf and all the PDF readers (evince, okular ...) > which > use libpoppler at this point, resulting in mupdf/libmupdf being AFIK the only > native and free PDF reader available for Linux with a rendering engine that > can > rival the proprietary ones like acrobat (in quality, not feature parity). > > I therefore suggest packaging zathura with the zathura-pdf-mupdf plugin. aka #731447 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+7wusyynqe+f871fxrul4a78pzkmqxtfmplkeu9nyojvtz...@mail.gmail.com
Re: Bug#735927: general: X *always* crashes when ram is full
previously on this list Roger Leigh contributed: > With an SSD, you really > don't want /tmp or swap on it; Why?, due to limited write cycles? As long as it is a modern SSD (years) or one of the old ones one with a sandforce controller (OpenBSD dev let me know about that) then it has a good 20% extra space above it's listed gigabytes reserved unusable for wear levelling meaning this is a non issue even when full? Unless he's worried about not being able to wipe the swap? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/801542.40858...@smtp127.mail.ir2.yahoo.com
Re: mupdf (was: xpdf removed from testing?)
On 2014-01-20 12:54:30, Mathieu Malaterre wrote: > On Mon, Jan 20, 2014 at 4:34 AM, Jens Oliver John wrote: > >> $ apt-cache show mupdf > >> MuPDF is a lightweight PDF viewer and toolkit written in portable C. > >> (...) > > > > The mupdf PDF reader is supposed to be minimal and makes on me the > > impression of > > being more a reference implementation using the mupdf library. > > > > A more featureful but still light PDF reader, which is able to utilize > > mupdf as > > the rendering backend, is zathura (in Debian) with the mupdf rendering > > backend > > (not in Debian [1]). > > > > The zathura upstream is very lively and is constantly gaining features. > > > > It may be my personal perception, but the fidelity of the PDF rendering in > > mupdf > > is *vastly* superior to xpdf and all the PDF readers (evince, okular ...) > > which > > use libpoppler at this point, resulting in mupdf/libmupdf being AFIK the > > only > > native and free PDF reader available for Linux with a rendering engine that > > can > > rival the proprietary ones like acrobat (in quality, not feature parity). > > > > I therefore suggest packaging zathura with the zathura-pdf-mupdf plugin. > > aka #731447 This is blocked by a proper fix for #617253. Ideally, mupdf would start to provide a shared library (#719351) and commit to a somewhat stable API. mupdf needs to get in a better shape before zathura-pdf-mupdf can be packaged. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Re: mass-filing bug reports to use dh-autoreconf during the build
On 16 January 2014 17:25, Matthias Klose wrote: > Last year, I started to file bug reports for the arm64 port, which required > new > versions of the config.sub and config.guess scripts. All of these can be > fixed > by using the autotools-dev package for the update. Now, another port requires > not just updates to the config.* scripts, but an update to libtool.m4 and > then > regenerating the configure file (see #726404). I would like to file bug > reports > for these and user-tag them, proposing as user / usertags > > User: debian-devel@lists.debian.org > Usertags: autoreconf > There are already ~300 bug reports user-tagged debian-...@lists.debian.org/arm64, most of which are about "config.guess / .sub". http://udd.debian.org/cgi-bin/bts-usertags.cgi?user=&tag=arm64 -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluibcj1_6ohttc8xq1gwlrhbnd5mvyyfqbzm8e90d4n...@mail.gmail.com
Re: RFH: logcheck
X-I-am-subscribed: no X-CC-me-please: yes On 11/12/13 15:55, Sylvestre Ledru wrote: > I am tagging logcheck as RFH because it seems that it could > need some love. > The PTS says: > The BTS contains patches fixing 36 bugs, consider including or untagging > them. > > And no upload has been done for the last year and half. My employer will sponsor[1] a mini-BSP/sprint targetting logcheck and related packages (e.g. those which ship or should ship logcheck snippets). Monday 27th January 2014 14:00-17:00 UTC You're welcome to join us virtually: http://wiki.debian.org/BSP/2014/01/gb/Monmouth 1: my time and that of my colleagues, that is; nothing material -- Jonathan Wiltshire Tiger Computing Ltd "Linux for Business" Tel: 01600 483 484 Web: http://www.tiger-computing.co.uk Follow us on Facebook: http://www.facebook.com/TigerComputing Registered in England. Company number: 3389961 Registered address: Wyastone Business Park, Wyastone Leys, Monmouth, NP25 3SR -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52dd181f.4030...@tiger-computing.co.uk
Re: mass-filing bug reports to use dh-autoreconf during the build
Am 20.01.2014 14:09, schrieb Dimitri John Ledkov: > On 16 January 2014 17:25, Matthias Klose wrote: >> Last year, I started to file bug reports for the arm64 port, which required >> new >> versions of the config.sub and config.guess scripts. All of these can be >> fixed >> by using the autotools-dev package for the update. Now, another port >> requires >> not just updates to the config.* scripts, but an update to libtool.m4 and >> then >> regenerating the configure file (see #726404). I would like to file bug >> reports >> for these and user-tag them, proposing as user / usertags >> >> User: debian-devel@lists.debian.org >> Usertags: autoreconf >> > > There are already ~300 bug reports user-tagged > debian-...@lists.debian.org/arm64, most of which are about > "config.guess / .sub". > > http://udd.debian.org/cgi-bin/bts-usertags.cgi?user=&tag=arm64 yes, at least for the still open issues it might be a good idea to tag these too, and prefer the more general solution of running autoreconf. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52dd28d2@debian.org
Re: Bug#735927: general: X *always* crashes when ram is full
On Mon, Jan 20, 2014 at 12:29:28PM +, Kevin Chadwick wrote: > previously on this list Roger Leigh contributed: > > > With an SSD, you really > > don't want /tmp or swap on it; > > Why?, due to limited write cycles? That's one reason, but the one I was thinking of was the shocking performance. I accidentally disabled tmpfs on /tmp on my main system with an SSD rootfs a few months back and was wondering why I was experiencing such slow builds, desktop freezing for seconds at a time, and other intermittent stalls. Turns out it was thrashing the SSD since /tmp was on the rootfs. Enabling tmpfs on /tmp resolved the problems, changing the performance from dire to excellent. (I have the swap on a RAID1 LVM LV on fast HDDs). This is a system with 8 cores @4GHz, 16GiB RAM, over 16GiB swap, so should be pretty performant, yet /tmp on an SSD made it crawl and freeze continually. This is purely down to the slow write speed of the SSD I have (Intel 320 128GB). If you have a faster SSD, maybe it won't be an issue, but given the amount of junk being written to /tmp when running a desktop environment and applications, from dozens of tmp files and sockets to streaming video, it's likely it will make a significant difference to make /tmp a tmpfs or HDD filesystem. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140120143024.gc6...@codelibre.net
Re: Bug#735927: general: X *always* crashes when ram is full
On Mon, 20 Jan 2014 14:30:24 + Roger Leigh wrote: > This is a system with 8 cores @4GHz, 16GiB RAM, > over 16GiB swap, so should be pretty performant, yet /tmp on an > SSD made it crawl and freeze continually. Interesting, have a look if it states the write access time spec in the datasheet (if available) of that SSD? Though when I've looked for write access time on off the shelf SSD drives it usually only mentions throughput or reading. Do you know if it slows the build if you use it for the source code? If your not sure it's a sandforce or has similar wear levelling then obviously don't try it in case you wear it out, though as it's your root I don't suppose you will try it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/829972.77857...@smtp115.mail.ir2.yahoo.com
Re: Bug#735927: general: X *always* crashes when ram is full
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/20/2014 09:56 AM, Kevin Chadwick wrote: > On Mon, 20 Jan 2014 14:30:24 + Roger Leigh wrote: > >> This is a system with 8 cores @4GHz, 16GiB RAM, over 16GiB swap, so >> should be pretty performant, yet /tmp on an SSD made it crawl and >> freeze continually. > > Interesting, have a look if it states the write access time spec in > the datasheet (if available) of that SSD? Though when I've looked for > write access time on off the shelf SSD drives it usually only > mentions throughput or reading. He said this was the Intel 320 Series 128GB drive. As far as I know there is no officially 128GB model of that drive, but the 120GB model (that being the advertised capacity after overprovisioning et cetera) was reviewed in depth by The Tech Report back in 2011: http://techreport.com/review/20653/intel-320-series-solid-state-drive The article includes spec-sheet information and detailed benchmark results. Glancing over them again, I'm not surprised by this described result from that drive; there are other SSDs that might do much better. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJS3UTqAAoJEASpNY00KDJrCMUP/1lefX7QpQgPQ8nvK233DPNv etYT9YEMJGfw1Z+HVPro/aFBw1zsk3VXW4Is+xP08W5GPZRpwhpVKPPW/DFOHrJX N37FK//iiqrHLvl2kodBCkgeMbLvNKH8M+727YiqmOqXFQdjOdsCS9wY90nHT7Ia f7D+i0nrxTeSE3kExWeMwIR9hMAVJLeCGftsbpARPDhVcSH1EiDKcUWf1VvfGeoW ca5j4/o1b5m6v/a1oFglMOk5M/OFxIRxQWL3ckFyxfkWgm+pkEQFXkdy2JfAv/Hc YuAK1vXR+d2Q5RdPy/5bj+llpbHy2AA/Tll7aZ1TwNNcf4XQNjxzu10Zp07RYOvY 5pzNwcLApDvKs84OY5ICfigqdoXnzo3WObgkNbcAlvssqzvw2iDhQU9AONY+xooS 0eFD0yXALWlTPLYp1afoeYXP0ruEVu9djtrLlfaJoBJ5QYIB+JReflnxm8D5BL6z 1+uKFr14WQ1+4nWX3vcFsOIwVySeqr9CUX9wpz3TRuJOfzDQwju0srFxcOEhIjxf nVhzhB2qOhFUj+x1IzxCQzYy0jxCqpOzibyMLirLTC9G5vd7bwhV2VlrBA1BpVk7 +C2oZxrjGb8iqxnSPnPbxZTsOSHpZiwd2qVmcdJ9DX/1hp2KmpwZBtavWy8+ntbZ oVDkwQLrNnirDnuB9UJ3 =r/3C -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52dd44ea.1080...@fastmail.fm
SSDs have extra "unused" space??? (was: Re: Bug#735927: general: X *always* crashes when ram is full
Hi Kevin, On Montag, 20. Januar 2014, Kevin Chadwick wrote: > As long as it is a modern SSD (years) or one of the old ones one with a > sandforce controller (OpenBSD dev let me know about that) then it has a > good 20% extra space above it's listed gigabytes reserved unusable for > wear levelling meaning this is a non issue even when full? wait, what? Do you have any vendor statements to support this 20% extra space? cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: SSDs have extra "unused" space???
Holger Levsen wrote: > On Montag, 20. Januar 2014, Kevin Chadwick wrote: >> As long as it is a modern SSD (years) or one of the old ones one with >> a sandforce controller (OpenBSD dev let me know about that) then it >> has a good 20% extra space above it's listed gigabytes reserved >> unusable for wear levelling meaning this is a non issue even when >> full? > wait, what? Do you have any vendor statements to support this 20% > extra space? Have a look at this article from Anandtech.com: http://www.anandtech.com/show/6489/playing-with-op , | The [Intel SSD DC] S3700 has 264GiB of NAND on-board but only exposes 186GiB | of it (200GB advertised capacity) as user accessible storage, the rest is | used as spare area to improve performance, consistency and endurance. ` There are numbers for other SSDs in that article. Grüße, Sven. -- Sigmentation fault. Core dumped. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/hacmbhgmm...@mids.svenhartge.de
Re: SSDs have extra "unused" space???
Hi Sven, On Montag, 20. Januar 2014, Sven Hartge wrote: > Have a look at this article from Anandtech.com: > http://www.anandtech.com/show/6489/playing-with-op [...] > There are numbers for other SSDs in that article. wow, thanks! cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Better pdiff handling for apt
On Fri, Jan 17, 2014 at 04:13:34PM +0100, David Kalnischkies wrote: > On Sat, Jan 04, 2014 at 07:34:07PM +0100, David Kalnischkies wrote: > > So, I guess merging both could cross a lot of points of your list and > > be relatively easily feed into unstable for proper field-testing. > > (a upload of my part was planed as a christmas present to experimental, > > but as usual: If you want to make deity laugh, tell her your plans) > I just did this merging the other day and Michael pushed it to experimental > (again), so everyone should feel free to give it a spin, you might be in > for a pleasant surprise ??? depending on how much you trusted the > "benchmark" in my previous mail. > [technical, it was indeed as easy as using my POC and Anthonys rred and > put some minor glue between them ??? very nice :D ] Very nice indeed. There's an extra patch at https://github.com/ajtowns/apt/commits/better-pdiffs-dk that makes a couple of minor cleanups in rred.cc. I think there's a few more to do, but I got confused as to how the pkgAcqIndexMergeDiffs stuff works, and will need to print that out to grok it, I expect... > Breakage potential: > I decided for now to enable client-side merge by default but with > detection for the X-Patch-Precedence field reprepro has introduced?? if it > has merged patches on the server side, which falls back to the old > handling. Ah, nice, that seems like it should make it backwards compatible in practice. It looks to me like dak and reprepro are the only tools that generate pdiffs currently, fwiw. Cheers, aj -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140120192156.ga27...@master.debian.org
Re: Bug#735927: general: X *always* crashes when ram is full
On Mon, Jan 20, 2014 at 10:46:50AM -0500, The Wanderer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 01/20/2014 09:56 AM, Kevin Chadwick wrote: > > > On Mon, 20 Jan 2014 14:30:24 + Roger Leigh wrote: > > > >> This is a system with 8 cores @4GHz, 16GiB RAM, over 16GiB swap, so > >> should be pretty performant, yet /tmp on an SSD made it crawl and > >> freeze continually. > > > > Interesting, have a look if it states the write access time spec in > > the datasheet (if available) of that SSD? Though when I've looked for > > write access time on off the shelf SSD drives it usually only > > mentions throughput or reading. > > He said this was the Intel 320 Series 128GB drive. As far as I know > there is no officially 128GB model of that drive, but the 120GB model > (that being the advertised capacity after overprovisioning et cetera) > was reviewed in depth by The Tech Report back in 2011: > > http://techreport.com/review/20653/intel-320-series-solid-state-drive > > The article includes spec-sheet information and detailed benchmark > results. Glancing over them again, I'm not surprised by this described > result from that drive; there are other SSDs that might do much better. You are correct--it is indeed 120GB, my mistake. I'm not sure if it's just the write speed. It's also reading stuff back from /tmp and the rest of the rootfs so it may just be a pathological workload. That said, I would have classed it as "very light"--/var, /home and the build chroots etc. are all on a separate RAID/LVM array, so /tmp was the sole part of the rootfs being actively written. It would be interesting to have further data from users who could try running with /tmp on the rootfs SSD and on a tmpfs (with or without the swap on the SSD). Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140120194359.gd6...@codelibre.net
Re: Bug#735927: general: X *always* crashes when ram is full
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/20/2014 02:43 PM, Roger Leigh wrote: > It would be interesting to have further data from users who could try > running with /tmp on the rootfs SSD and on a tmpfs (with or without > the swap on the SSD). My swap, /tmp, /boot, /usr, and / are all LVM logical volumes, on a volume group backed by two identical 256GB SSDs in RAID-1 via mdraid, and I haven't noticed any issues. All other filesystems (/var, /opt, /home) are on a separate volume group backed by RAID-5 mechanical storage. However, not only does the RAID-1 question introduce another variable and likely improve performance, these drives were specifically chosen because they were top performers in their capacity class at the time - and with SSDs, higher capacity generally performs better anyway. So this may not be a particularly valuable datapoint. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJS3ayXAAoJEASpNY00KDJrqBcQAJjEE8TA6cMnzANgXcFCQkXp F3V7L0C9XtJkJCnGQUoIgT3DkC0PtnaDqLXatnhz8nFlT1WWDxLvR2WDBU+Rl7V4 moiHT2l+zksZ1nWE2wfW+V9nLBw0vcQif3vSCvZEPtlYnY4lbPWJdBMgvBZHxeBt wFtW8xNwVoSJvxdGlknH0tnJ8CinTps4S+WU7sHslTP56Z6IUZI2/o4qnidlZNGj QE+2CjmuBdKggnFRXJViv8R6NUYdboY3RRkkFfPXk6V6U7ymI4JUCk6juAg9MyJ+ ob2+zWgeHavUA3ixeKA2hhA1HWKAMCoAGo1jdJELLLpNAx8gyW6Vg7gTutzPJXKj 61FqULfj5LOE3rmL49FyPJtQgai7Ug67RF86z+0oDZodLb/375N4daRQ5+BDmGnC sISc5z0ennqb/i8uXQU8Ywmt382Y8/IZ2RubbZVjZ2YLcXST+oIoSs1WxMIBoMRW b9VPthC5yTgn4vclwsjRxWjUl1ajB3kPJodakZAsVc8tjYVOqfQipMQk25Oekmjs hvJyUyUPxTPHXHzmNL386S+mB0eotQM/+U+OwIk54Wmuksu5OqnLL80UXkOaQwZZ kteRrweWBdfjtUjY8S+p9DBzgyBWqD3KEWkYZi48TNcehcV8lncAdaB6pgiuJDVd pmqWoF090M6xtCbxYKtb =tpWt -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52ddac97.2050...@fastmail.fm
Re: SSDs have extra "unused" space??? (was: Re: Bug#735927: general: X *always* crashes when ram is full
On Tue, Jan 21, 2014 at 1:22 AM, Holger Levsen wrote: > wait, what? Do you have any vendor statements to support this 20% extra space? Flash is basically probabilistic storage and you need extra space to ensure that the probability your data is stored remains high, and a (possibly trustworthy) controller with algorithms in front to help with that. Check out Bunnie's talk at 30C3 about SD cards where he mentioned a 16GB flash device with the controller only saying it was 128MB in size (IIRC). I assume similar things apply to SSDs/NAND etc. http://www.bunniestudios.com/blog/?p=3554 https://events.ccc.de/congress/2013/Fahrplan/events/5294.html https://media.ccc.de/browse/congress/2013/30C3_-_5294_-_en_-_saal_1_-_201312291400_-_the_exploration_and_exploitation_of_an_sd_memory_card_-_bunnie_-_xobs.html -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6EBS5bWzB3te1iLHXB33y=5gcjaq6y1ckf5o9gkjta...@mail.gmail.com
Bug#736217: ITP: gstreamer-vaapi -- VA-API plugins for GStreamer
Package: wnpp Severity: wishlist Owner: Vincent Cheng * Package name: gstreamer-vaapi Version : 0.5.7 Upstream Author : Gwenole Beauchesne * URL : http://gitorious.org/vaapi/gstreamer-vaapi * License : LGPL-2.1+ Programming Lang: C Description : VA-API plugins for GStreamer gstreamer-vaapi is a collection of GStreamer plugins and helper libraries that allow hardware accelerated video decoding, encoding and processing through VA-API. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140121062505.14217.9655.reportbug@vincent-tlaptop
