Default packages flags
Please, Is possible to know, which is default flags for packages? Or where can i find this information? For example in Gentoo or in Sabayon is this very easy. For Sabayon can I find all flags on the Sabayon's web page for all packages. Thank. Best regards. Baci -- 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/calvnwvigfuvbv7ponj6h2j3zhpkbynf9w_ekhrvnxw8zbrn...@mail.gmail.com
Bug#699592: ITP: python-tablib -- format agnostic tabular dataset library
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-tablib Version : 0.9.11-1 Upstream Author : Kenneth Reitz * URL : https://github.com/kennethreitz/tablib * License : MIT Programming Lang: Python Description : format agnostic tabular dataset library Tablib is a format agnostic tabular dataset library, written in Python. It allows you to import, export, and manipulate tabular data sets. Advanced features include, segregation, dynamic columns, tags & filtering, and seamless format import & export. -- 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/20130202084250.18405.58767.report...@buzig.gplhost.com
Re: Default packages flags
On Sat, Feb 2, 2013 at 4:28 PM, Pavel Baculák wrote: > Is possible to know, which is default flags for packages? Or where can > i find this information? For example in Gentoo or in Sabayon is this > very easy. For Sabayon can I find all flags on the Sabayon's web page > for all packages. Sounds like you want to read the dpkg-buildflags manual page, or the build logs for all packages: http://manpages.debian.net/man/sid/1/dpkg-buildflags https://buildd.debian.org/status/package.php -- 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/CAKTje6E2vz=tsvcanyhb7zm+ovbmylc+zgtztoku3n3lkt6...@mail.gmail.com
Re: Default packages flags
Pavel Baculák wrote: > Please, > Is possible to know, which is default flags for packages? Or where can > i find this information? For example in Gentoo or in Sabayon is this > very easy. For Sabayon can I find all flags on the Sabayon's web page > for all packages. (SID)ametzler@argenau:/tmp/TASN/libtasn1-3.2$ dpkg-buildflags CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security FFLAGS=-g -O2 LDFLAGS=-Wl,-z,relro (SID)ametzler@argenau:/tmp/TASN/libtasn1-3.2$ -- 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/vb1vt9-6hg@argenau.downhill.at.eu.org
Bug#699594: ITP: cliff-tablib -- tablib formatters for cliff
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: cliff-tablib Version : 1.0 Upstream Author : Doug Hellman * URL : https://github.com/dreamhost/cliff-tablib * License : Apache-2.0 Programming Lang: Python Description : tablib formatters for cliff Cliff-tablib is a set of formatter extensions for producing JSON, YAML, and HTML output. Installing cliff-tablib activates these formatters for any cliff-based programs automatically. -- 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/20130202090559.23524.43956.report...@buzig.gplhost.com
Re: Default packages flags
[ quoting fixed, redirected to mailing list ]
On 2013-02-02 Pavel Baculák wrote:
> 2013/2/2 Andreas Metzler :
>> Pavel Baculák wrote:
>>> Please,
>>> Is possible to know, which is default flags for packages? Or where can
>>> i find this information? For example in Gentoo or in Sabayon is this
>>> very easy. For Sabayon can I find all flags on the Sabayon's web page
>>> for all packages.
>> (SID)ametzler@argenau:/tmp/TASN/libtasn1-3.2$ dpkg-buildflags
>> CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
>> -Werror=format-security
[...]
> Thank you very much for answer, but this are system flags. Or I am
> writing mistake?
I would call these the default compiler/linker flags.
> But I neads flags for package, for example in Gento
> this are USE flags.
> As example - mc have possibility USE flags - I found it, when I was
> compiling mc from sources in .../debian/rules
> DEB_CONFIGURE_EXTRA_FLAGS := --enable-vfs-undelfs --with-samba
> --with-x --with-screen=slang --libexecdir='$${prefix}/lib'
> --disable-rpath
> And I need know default flags for packages which are installing by
> using apt-get or aptitude.
> Excuse mi, If I don't understand our reply, bud I now change Gentoo to
> Debian a for any packages I need know "extra flags" ...
Debian does not have an equivalent global mechanism. Optional features
at compile time are set in the respective debian/rules.
cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
--
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/20130202103426.gc3...@downhill.g.la
Re: Default packages flags
Thank you very much for answer, but this are system flags. Or I am
writing mistake?? But I neads flags for package, for example in Gento
this are USE flags.
As example - mc have possibility USE flags - I found it, when I was
compiling mc from sources in .../debian/rules
DEB_CONFIGURE_EXTRA_FLAGS := --enable-vfs-undelfs --with-samba
--with-x --with-screen=slang --libexecdir='$${prefix}/lib'
--disable-rpath
And I need know default flags for packages which are installing by
using apt-get or aptitude.
Excuse mi, If I don't understand our reply, bud I now change Gentoo to
Debian a for any packages I need know "extra flags" ...
Thank you.
Best regards.
Baci
--
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/calvnwvh8b0pu-ksexzpv7ubfp-+ckoqm7qsta2w2cq-voqb...@mail.gmail.com
Processed (with 1 errors): Re: Bug#699475: general: Reading package lists... DoneSegmentation faulty tree... 50% and stops
Processing commands for cont...@bugs.debian.org: > package general apt Limiting to bugs with field 'package' containing at least one of 'general', 'apt' Limit currently set to 'package':'general', 'apt' > reassign 699475 Unknown command or malformed arguments to command. > severity 699475 normal Bug #699475 [general] general: Reading package lists... DoneSegmentation faulty tree... 50% and stops Severity set to 'normal' from 'grave' > thanks Stopping processing here. Please contact me if you need assistance. -- 699475: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699475 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.135980399630970.transcr...@bugs.debian.org
Processed: Re: Bug#699475: general: Reading package lists... DoneSegmentation faulty tree... 50% and stops
Processing commands for cont...@bugs.debian.org: > package general apt Limiting to bugs with field 'package' containing at least one of 'general', 'apt' Limit currently set to 'package':'general', 'apt' > reassign 699475 apt Bug #699475 [general] general: Reading package lists... DoneSegmentation faulty tree... 50% and stops Bug reassigned from package 'general' to 'apt'. Ignoring request to alter found versions of bug #699475 to the same values previously set Ignoring request to alter fixed versions of bug #699475 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 699475: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699475 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.13598043532198.transcr...@bugs.debian.org
Re: Default packages flags
I know, debian don't have to same mechanism as gentoo (debian have
very good packages support and package handling utility), but all
packages have to have some default EXTRA_FLAGS when was compiling as
packages. Because for example mc is compiling as default with vfs
support or with X support .
And I need to know, if is some web site, where can I found this
informations. For some packages is it sometime important.
Thanks Baci
2013/2/2 Andreas Metzler :
> [ quoting fixed, redirected to mailing list ]
>
> On 2013-02-02 Pavel Baculák wrote:
>> 2013/2/2 Andreas Metzler :
>>> Pavel Baculák wrote:
Please,
Is possible to know, which is default flags for packages? Or where can
i find this information? For example in Gentoo or in Sabayon is this
very easy. For Sabayon can I find all flags on the Sabayon's web page
for all packages.
>
>>> (SID)ametzler@argenau:/tmp/TASN/libtasn1-3.2$ dpkg-buildflags
>>> CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
>>> -Werror=format-security
> [...]
>
>> Thank you very much for answer, but this are system flags. Or I am
>> writing mistake?
>
> I would call these the default compiler/linker flags.
>
>> But I neads flags for package, for example in Gento
>> this are USE flags.
>> As example - mc have possibility USE flags - I found it, when I was
>> compiling mc from sources in .../debian/rules
>> DEB_CONFIGURE_EXTRA_FLAGS := --enable-vfs-undelfs --with-samba
>> --with-x --with-screen=slang --libexecdir='$${prefix}/lib'
>> --disable-rpath
>
>> And I need know default flags for packages which are installing by
>> using apt-get or aptitude.
>
>> Excuse mi, If I don't understand our reply, bud I now change Gentoo to
>> Debian a for any packages I need know "extra flags" ...
>
> Debian does not have an equivalent global mechanism. Optional features
> at compile time are set in the respective debian/rules.
>
> cu andreas
>
> --
> `What a good friend you are to him, Dr. Maturin. His other friends are
> so grateful to you.'
> `I sew his ears on from time to time, sure'
>
>
> --
> 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/20130202103426.gc3...@downhill.g.la
>
--
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/calvnwvji6ri17c5bjjn9pvhsyowxjrkc7q2bfqjxkwaaieg...@mail.gmail.com
Bug#699606: ITP: radium-compressor -- audio compressor for JACK
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: radium-compressor Version : 0.5.1 Upstream Author : Kjetil S. Matheussen * URL : https://github.com/kmatheussen/radium_compressor * License : GPL Programming Lang: C++ Description : audio compressor for JACK Radium Compressor is the system compressor in Radium, but distributed as a standalone JACK client application. Radium Compressor uses the stereo compressor found in effect.lib in the Faust distribution. -- 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/20130202115937.15046.86819.reportbug@Aspire-1410
Re: Bootstrappable Debian - proposal of needed changes
On Wed, 2013-01-30 at 17:27:13 +, Wookey wrote: > +++ Ian Jackson [2013-01-16 13:50 +]: > > > * The concrete syntax in build-depends should not use < > but rather > >reuse the architecture qualification syntax. > > I have just been told of a specific reason to avoid using '< >' : > DEP-11 proposes to use '< >' for Component metadata in binary packages > http://wiki.debian.org/DEP-11 I don't see any need to use <> for those, they would seem to only need a delimiter character, something like «type;value» or «type@value», or whatever else along those lines would work. But, in any case, I don't think that proposal is a good idea as it stands; dpkg does not support file depends, and we have always considered that a feature. File depends have (at least) the following problems: * They bypass the normal shlibs/symbols dependencies, incurring in possible ABI issues. * They do not play nice with Conflicted packages, as they only request a specific path, not a path supplying a specific interface. While we supposedly do not allow same paths for conflicting interfaces, that's just a Debian policy. * By allowing that kind of extension in the Provides field, it implies we'd be accepting them in any dependency field. In addition: * Hardware IDs require patterns and similar, which TBH I don't think should be supported in dependency fields, and at least not sneaked in such a non-generic way. Once the path based provides are removed the remaininig seem representable quite fine with something like debtags. Otherwise if this is supposed to only be used by PackageKit and debtags is really not appropriate, then a new field might be fine too. But do not get me wrong, I think that getting rid of the app-install-data is a worth while goal, just probably not in that shape. > Should this profile stuff be written up as a 'DEP'? Please, I'd rather we didn't? Thanks, Guillem -- 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/20130202120726.ga3...@gaara.hadrons.org
Bug#699608: ITP: libcarp-fix-1-25-perl -- Smooth over incompatible changes in Carp 1.25
Package: wnpp Severity: wishlist Owner: Xavier Guimard -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: libcarp-fix-1-25-perl Version : 1.01 Upstream Author : Michael G Schwern * URL : http://search.cpan.org/~mschwern/Carp-Fix-1_25-1.01/ * License : Artistic OR GPL-1+ Programming Lang: Perl Description : Smooth over incompatible changes in Carp 1.25 Carp 1.25 made a change to its formatting, adding a period at the end of the message. This can mess up tests and code that are looking for error messages. Carp::Fix::1_25 makes the message consistent, regardless of what version of Carp you're using. Carp::Fix::1_25 exports its own carp functions which change the Carp message to match the 1.25 version. Carp::Fix::1_25 otherwise acts exactly like Carp and it will honor Carp global variables|Carp/GLOBAL VARIABLES such as @CARP_NOT and %Carp::Internal. Why do this instead of just upgrading Carp? Upgrading Carp would affect all installed code all at once. You might not be ready for that, or you might not want your module to foist that on its users. This lets you fix things one namespace at a time. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlENANUACgkQZ9okSKmj7dWcpACfUlsRHZJyWR5fjkcN0VLEmbt8 /CQAoNGpcSVzeQJvczNsQJBhDTw6EtE4 =i2UN -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/20130202120446.1824.18341.reportbug@xnrr142
Re: No native packages?
On Fri, 2013-02-01 at 22:25:18 +0100, Jakub Wilk wrote: > * Guillem Jover , 2013-01-29, 20:31: > > if you are going to patch the package you might as well do the one > > line change from "3.0 (native)" to "3.0 (quilt)", and rename the > > source tarball to add «.orig». > > That's a good solution for derivatives, not so much for NMUs or > backports. As I mentioned on my previous mail, I consider that a nice feature. To me NMUing or backporting a native package is the equivalent of an external and uninvolved person to send a mail to, say, the postgresql developers, telling them that you've released a new version of the upstream project for them... on the upstream server. Taking into account that the distribution archive and BTS are the hosting site for the native package, an NMU is a versionspace and file release takeover, and stomps over previously released versions and supercedes them, which might be confusing for downstreams (like non-derivatives), as the NMU might end up being rejected, or reimplemented in a different and incompatible way, etc. Thanks, Guillem -- 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/20130202125646.ga4...@gaara.hadrons.org
Re: screen says "Bad tty" if /dev/console is a symlink
On Sun, 2013-01-27 at 16:20:25 +, Roger Leigh wrote: > Given the amount of work already done by the Hurd porters, would > it be viable to undef PATH_MAX and do a test build to look at how > much this breaks? The other advantage is that it reduces duplicate > codepaths in all the places where we have #ifdef PATH_MAX > (where the dynamic allocation is done only for Hurd, rather than > across the board). This alone would remove a whole bunch of > potential bugs and improve the overall code quality and robustness. While wearing my GNU/Hurd porter hat, I've always advocated to try to fix MAX issues unconditionally, sometimes upstreams might prefer different code paths though. But yes, doing such mass build would be very useful to see how many are still there. I'd also be in favor of removing MAX defines from all our currently supported architectures. Although such build would not find all MAX instances, as some upstreams define those to arbitrary values if they are not defined. Thanks, Guillem -- 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/20130202130401.gb4...@gaara.hadrons.org
Re: screen says "Bad tty" if /dev/console is a symlink
Guillem Jover, le Sat 02 Feb 2013 14:04:01 +0100, a écrit : > But yes, doing such mass build would be very useful to see how many are > still there. I'd also be in favor of removing MAX defines from all our > currently supported architectures. Rough estimation from buildd logs: € wanna-build --list=failed | grep PATH_MAX | wc -l 248 € wanna-build --list=failed | grep MAXPATHLEN | wc -l 71 € wanna-build --list=failed | grep MAX_PATH | wc -l 2 € wanna-build --list=failed | grep ARG_MAX | wc -l 1 € wanna-build --list=failed | grep IOV_MAX | wc -l 3 € wanna-build --list=failed | grep MAXHOSTNAMELEN | wc -l 33 out of 1226 packages failing to build on hurd-i386. This doesn't mean there aren't others behind other build failures, but that gives an idea. Samuel -- 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/20130202135815.ga6...@type.fosdem.net
Bug#699634: ITP: shine -- Fixed-point MP3 encoding library
Package: wnpp Severity: wishlist Owner: Romain Beauxis * Package name: shine Version : 1.0.0 Upstream Author : The Savonet Team * URL : https://github.com/savonet/shine * License : LGPL2 Programming Lang: C Description : Fixed-point MP3 encoding library Shine is a MP3 encoding library implemented using fixed-point arithmetic. It can be used to encode audio data on architectures with no floating point processing unit (FPU) at a much better rate than encoding libraries implemented using floating-point arithmetic. -- 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/2012205211.9432.8270.reportbug@iroy
Bug#699636: ITP: ocaml-shine -- OCaml bindings for the shine fixed-point MP3 encoding library
Package: wnpp Severity: wishlist Owner: Romain Beauxis * Package name: ocaml-shine Version : 0.0.1 Upstream Author : The Savonet Team * URL : http://github.com/savonet/ocaml-shine * License : LGPL 2.1 Programming Lang: C Description : OCaml bindings for the shine library -- 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/2012210658.9457.15559.reportbug@iroy
Re: Go (golang) packaging, part 2
Michael, after re-reading your GoPackaging Wiki page and digging around a bit in the sources for the go tool, I think that only minimal changes to go(1) are needed for its build system to "Just Work" without breaking expectations: 1. Debian user's/admin's perspective: As I have already written elsewhere in this thread, using upstream build systems without extra parameters usually results in libraries and binaries being installed to /usr/local. This is not what "sudo go get" currently (version 1:1.0.2-2) does -- it happily puts both source and binary files into GOROOT (=/usr/lib/go). This is bound to break things in interesting ways at some point. One way to fix this would be changing the default GOPATH setting from an empty string to a path that has "/usr/local/lib/go" as its first entry. Another quick solution might be changing go(1)'s behavior so that it will still look for libraries in GOROOT, just not attempt to modify files there. 2. Software developer's perspective: Since the text "How to Write Go Code" at http://golang.org/doc/code.html tells me right away that setting GOPATH is something I need to do, changing the GOPATH default value should not cause too much confusion. 3. Debian package maintainer's perspective: I disagree with your position that "Go libraries [...] should not be used directly for Go development". If I put together a Debian package for a Go library, developers should still have the option to use it. And it should be easy, preferably be installed into the default GOPATH, so a second entry (after /usr/local/lib/go) does not seem unreasonable. Upstream has not made it clear whether 3rd partylibraries should be installed into GOROOT or somewhere else. There still are a few unanswered questions about how go(1) should behave, and what bugs are still lurking in that code. Perhaps upstream will change go(1) so that a concept of third-party libraries is possible. Until then, putting libraries into a separate directory such as /usr/lib/gocode seems like a good idea. But what about gccgo? Apparently, go(1) can be used with gccgo, but gccgo-compiled code cannot be linked with golang-go-compiled code. So, perhaps it makes sense to install the libraries produced by each compiler into separate directory hierarchies -- /usr/lib/gocode/golang and /usr/lib/gocode/gccgo? Cheers, -Hilko -- 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/87r4kyfp8s@msgid.hilluzination.de
Re: Re: Default packages flags
I know, debian don't have to same mechanism as gentoo (debian have very good packages support and package handling utility), but all packages have to have some default EXTRA_FLAGS when was compiling as packages. Because for example mc is compiling as default with vfs support or with X support . And I need to know, if is some web site, where can I found this informations. For some packages is it sometime important. If you are talking about the flags that are passed to each package's configure scripts, then... well... it depends on how they're built. If the package is built using dh_auto_configure (i.e. the dh7 short form), the default set of flags passed can be found in /usr/share/perl5/Debian/Debhelper/Buildsystem/autoconf.pm. Whereas, if it's build using CDBS, then the corresponding flags can be found in /usr/share/cdbs/1/class/autotools-vars.mk.However, these are merely standard flags and it's up to each individual package maintainer to add to or override them. Hope that helps. - Fabian
Re: Default packages flags
On Sat, Feb 02, 2013 at 12:48:39PM +0100, Pavel Baculák wrote: > I know, debian don't have to same mechanism as gentoo (debian have > very good packages support and package handling utility), but all > packages have to have some default EXTRA_FLAGS when was compiling as > packages. Because for example mc is compiling as default with vfs > support or with X support . > And I need to know, if is some web site, where can I found this > informations. For some packages is it sometime important. This is handled in debian/rules in each source package. I'm not aware of a web site that extracts it specifically (and besides it's often conditional on the architecture and suchlike so the best that would be possible would be to just extract debian/rules; really you're best off downloading the source package and looking). -- Colin Watson [cjwat...@debian.org] -- 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/20130202230534.ga17...@riva.dynamic.greenend.org.uk
Bug#699656: general: System freezes while using multimedia via DRI [Intel 82865G chip] on kernels above 3.2.0-3-686-pae
Package: general Severity: critical Justification: breaks the whole system Dear developers, Almost everytime [it happens randomly] I try to see some video content via DRI [VLC/XBMC, etc] on kernels with version higher than 3.2.0-3-686-pae the whole system freeze [screen goes black, system is unresponsive, can't switch consoles, monitor goes into "power/suspend/no signal mode"]. It happens with xorg.conf and without it. Disabling DRI [xorg.conf: Option "DRI" false] seems to resolve the problem, but then video is unusable [can't watch anything]. I already reported this bug for the previous version of kernel [bug report #693083], but the problem is still unsolved.++ -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20130203010828.3663.96138.reportbug@x
Bug#699656: general: System freezes while using multimedia via DRI [Intel 82865G chip] on kernels above 3.2.0-3-686-pae
reassign 699656 src:linux forcemerge 693083 699656 thanks Quoting marc (marc_sm...@gmx.com): > I already reported this bug for the previous version of kernel [bug report > #693083], but the problem is still unsolved.++ Hello, As #693083 is still opened, I fail to see why you're opening yet another bug (moreover a release critical one) and assign it to "general" which is, most often, a good way to ask for someone to close it immediately..:-) Reassigning and merging bugs signature.asc Description: Digital signature
Processed: Re: Bug#699656: general: System freezes while using multimedia via DRI [Intel 82865G chip] on kernels above 3.2.0-3-686-pae
Processing commands for cont...@bugs.debian.org: > reassign 699656 src:linux Bug #699656 [general] general: System freezes while using multimedia via DRI [Intel 82865G chip] on kernels above 3.2.0-3-686-pae Bug reassigned from package 'general' to 'src:linux'. Ignoring request to alter found versions of bug #699656 to the same values previously set Ignoring request to alter fixed versions of bug #699656 to the same values previously set > forcemerge 693083 699656 Bug #693083 [src:linux] System freezes with graphics going down [black screen]. Bug #699656 [src:linux] general: System freezes while using multimedia via DRI [Intel 82865G chip] on kernels above 3.2.0-3-686-pae Severity set to 'normal' from 'critical' Marked as found in versions linux/3.2.32-1. Merged 693083 699656 > thanks Stopping processing here. Please contact me if you need assistance. -- 693083: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693083 699656: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699656 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.135987315426887.transcr...@bugs.debian.org
