Bug#527928: RM: floater -- ROM; no longer maintained or running
Package: ftp.debian.org Severity: normal The Floater Bridge Network is no longer maintained. There is no reason to continue distributing the client. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527935: O: audiooss
Package: wnpp Severity: normal I'm about to leave Debian, so am orphaning my last package. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505913: The issue is resolved on the scala-side
On Nov 25, 2008, at 5:34 PM, Marek Kubica wrote: On Tue, 25 Nov 2008 23:17:40 +0100 Mehdi Dogguy [EMAIL PROTECTED] wrote: May be we can upload in Debian scala 2.7.2-r16603 directly. Generally I don't think it is a great idea to have SVN snapshots in Lenny, especially since the issue is said to be fixed in the current openjdk in experimental, see bug #506204. I haven't had time to test it, though. That's very good news, Mehdi! However, I tend to agree with Marek, only more broadly. Let's upload a real 2.7.2, and wait for the 2.8.0 release before finally switching to OpenJdk. The release will come soon enough. Lex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483412: scala build-depends on gcj-4.1 which is not availabe anymore on arm, alpha, hppa
I am not so sure the dependency can be dropped. Before doing so, we need to verify that not only does the package rebuild with minimal dependencies (which takes over half an hour), but that the scala command by itself gives a working command prompt. If those can be verified, then we could adjust the dependencies. I would prefer, though, to simply wait until the Sun JDK can be depended on by packages in main. To that end, is there another full gcj package that can be depended on, without needing to be specific about the version? Lex Spoon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493600: ftp.debian.org: remove package sbaz
Package: ftp.debian.org Severity: normal Please remove the package sbaz, both source and binary. It is no longer under maintenance. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464259: sbaz: FTBFS: /build/user/sbaz-1.20/src/sbaz/PackageSpec.scala:35: error: unreachable code
On Feb 6, 2008, at 2:29 AM, Lucas Nussbaum wrote: Package: sbaz version: 1.20-2 Severity: serious User: [EMAIL PROTECTED] Usertags: qa-ftbfs-20080205 qa-ftbfs Justification: FTBFS on i386 Hi, During a rebuild of all packages in sid, your package failed to build on i386. This is fixed in the next version of sbaz, but it depends on the next version of Scala. Since sbaz is a new, rarely used package for Debian, I have been thinking to wait a few weeks until the next Scala comes out instead of trying to backport the fixes. -Lex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443040: scala: FTBFS: GC Warning: Out of Memory! Returning NIL!
The memory settings are too low for the auto-builder's configuration. The next version uploaded will include a larger setting. -Lex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436842: floater: not handling nostrip build option (policy 10.1)
Julien Danjou [EMAIL PROTECTED] wrote: You should look for call to strip, ld -s or install -s which may strip binaries. Yes, it is using install -s. I will upload a new version that uses dh_clean instead. -Lex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409785: scala: FTBFS: concurrent is not a member of java.util
After discussion with Philipp Haller, the offending class will simply be removed for now. The rest of Scala will behave fine without it, though of course without the extra functionality. Once the Sun JVM is available under GPL, the file will be re-enabled. Lex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409785: scala: FTBFS: concurrent is not a member of java.util
Kenshi's description is accurate. I would not call it depending on a package in non-free when (a) the dependency is *optional* and (b) the software in question is open source now, even though Debian has not reacted yet. http://www.sun.com/software/opensource/java/faq.jsp I have been looking into the issue with the other Scala developers to explore options. The best would be if anyone knows a set of JDK5 stubs that Scala can compile against. An implementation is necessary, and the stubs do not need to be complete -- the concurrency classes might be enough. If anyone knows of such a thing, do email me! Anyway, I'm looking into it. And I'm hoping the Sun JVM gets into Debian main before too long. Lex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409785: scala: FTBFS: concurrent is not a member of java.util
Lex Spoon [EMAIL PROTECTED] wrote: The best would be if anyone knows a set of JDK5 stubs that Scala can compile against. An implementation is necessary, [...] Sorry, an implementation is *not* necessary. They are just needed for type checking. -Lex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415324: ipmasq: A01interfaces rejects interfaces with lo in them
Package: ipmasq Severity: normal Tags: patch The file A01interfaces.def is too zealous in cropping out the lo interface from the list of interfaces. I have an interface named ethlocal, and grep -v lo rejects it. An easy fix is to add the -x flag to grep: INTERNAL=$(enumerate-if | sort -u | grep -vx lo) -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408353: sbaz: FTBFS: internal compiler error (object java.lang not found.)
It looks like gij is not enough to run scala, but you additionally need java-gcj-compat. I'll add java-gcj-compat as an install dependency of scala, and that should fix this build problem with sbaz. -Lex Frank Küster [EMAIL PROTECTED] wrote: build.main: [mkdir] Created dir: /tmp/buildd/sbaz-1.19/build/build.main [scalac] Compiling 71 source files to /tmp/buildd/sbaz-1.19/build/build.main [scalac] scala.tools.nsc.FatalError: object java.lang not found. [scalac]at scala.tools.nsc.symtab.Definitions$definitions$.getModuleOrClass(Definitions.scala:367) [scalac]at scala.tools.nsc.symtab.Definitions$definitions$.getModule(Definitions.scala:338) [scalac]at scala.tools.nsc.symtab.Definitions$definitions$.init(Definitions.scala:651) [scalac]at scala.tools.nsc.Global$Run.init(Global.scala:397) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400894: FTBFS: tries to write in $HOME
I plan to upload new versions of the scala and sbaz packages in the next couple of weeks, so I do appreciate all of the sleuthing you guys have done. On a couple of notes: I will use Frank's suggested tetex dependencies: tetex-bin | texlive-latex-base, tetex-extra | texlive-fonts-recommended The Latex files are pretty normal, so this is hopefully enough. I don't understand the comment about times. Googling suggests that it is still recommended usage. Further, mathptmx seems to be about *math* fonts, but these documents do not use math mode. I'm going to leave it as times for now; even if it's obsolete, it's wildly popular and should continue to work. sbaz does not build-depend on Java, because it's pure Scala code. Scala depends on a JVM right now, but that's its own dependency. Instead of changing build.xml, I would rather rely on modifying debian/rules to pass in appropriate -D options. In the case of finding the Scala compiler and library, the setting is scala.lib.dir. Update coming soon -Lex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400894: FTBFS: tries to write in $HOME
Frank Küster [EMAIL PROTECTED] wrote:
On a couple of notes:
I will use Frank's suggested tetex dependencies:
tetex-bin | texlive-latex-base, tetex-extra |
texlive-fonts-recommended
No, this is not what I suggested, and it's a receipe to get FTBFS bugs -
important for etch, RC as soon as tetex is dropped in the lenny release
cycle.
What would you recommend? It is an extremely basic Latex file using no
packages other than the times one.
\usepackage{mathptmx}
\usepackage[scaled]{helvet}
is the correct replacement, except that Times is not an ideal font for
letter or A4 paper in single-column layout, it gives too many letters in
a line. s/mathptmx/mathpazo/ gives you Palatino which many find better,
or use one of the other combinations outlined in psnfss2e.pdf.
Thank you for the tips. I will try these options.
-Lex
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400894: FTBFS: tries to write in $HOME
Lex Spoon [EMAIL PROTECTED] wrote:
\usepackage{mathptmx}
\usepackage[scaled]{helvet}
is the correct replacement, except that Times is not an ideal font for
letter or A4 paper in single-column layout, it gives too many letters in
a line. s/mathptmx/mathpazo/ gives you Palatino which many find better,
or use one of the other combinations outlined in psnfss2e.pdf.
Oh yeah, the Palatino looks WAY better than either Times option. Both
Times versions had \emph{} fonts that were too small compared to their
surrounding text, for some reason.
I'm now using:
\documentclass{article}
\usepackage{mathpazo}
\usepackage[scaled]{helvet}
-Lex
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403062: scala: diff for NMU version 2.3.0-1.1
The following is the diff for my scala 2.3.0-1.1 NMU. I'll NMU this package in a few days if this bug is not fixed by the maintainter. Thank you, Ana. By all means NMU this one. My main computer is on the fritz at the moment, so for me to fix it within the next week would be a lot more effort than usual. -Lex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400894: FTBFS: tries to write in $HOME
The problem is related to bug 397045. The package depends on ant and on gcj in order to try and get a setup for compiling Java code using ant. I am not sure what the dependencies should be changed to. I will leave it alone for now, in the hopes that the ant and/or gcj maintainers make this combination of dependencies sufficient -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383158: sbaz: attempt at resolving FTBFS
Kevin Coyner [EMAIL PROTECTED] wrote: While not a user of sbaz or scala, I made an attempt anyway at fixing this RC bug. To start the process I took the orig.tar.gz file from the Debian archives and applied the diff and simply changed the Build dependency from scala-dev (which is not even in Debian and according to snapshot.debian.net never was) to scala and started to try and build it in pbuilder sid. Thanks, Kevin. I overlooked this problem due to faulty mail filters. scala-dev has been merged into the main scala package now. I will fix that dependency, as well as the other unfortunate problems you ran into. Your patch will be very helpful for all of this -Lex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392935: unable to find a javac compiler
Julien Louis [EMAIL PROTECTED] wrote: /build/buildd/scala-2.1.5/debian/simpbuild.xml:213: Unable to find a javac compiler; com.sun.tools.javac.Main is not on the classpath. Perhaps JAVA_HOME does not point to the JDK It seems you don't Build-Depend against a java compiler since gij is a java interpreter. Yes, indeed a compiler is required. Thank you; I will fix this in the next upload. -Lex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#236721: Squeak in Debian main
Andreas Kuckartz [EMAIL PROTECTED] wrote: (4) The distributed files squeak.changes and squeak.image, both around 10MB, are shipped in binary form. I wonder if there should be source code to create them initially. (See DFSG.2, Source Code) The .changes file contains Smalltalk source code (if the system is not broken!). I think that one can argue that there exists nothing really comparable to the .image files used by Smalltalk-80 systems for other programming languages. Those .image-files exist since at least 25 years and in my opinion they are an important aspect of the Smalltalk-80 way of doing things. In some way it is comparable to a living organism. A key observation for the present discussion: an image/changes pair is a perfectly valid form of ultimate source code for a Squeak developer. There is no earlier, more fundamental source code that Squeak developers use. Alan Kay himself hacks image/changes pairs when he develops new things for Squeak. The only reason these might not look like source code is that they are not fully in a text format. However, there does not seem to be any fundamental reason to insist that source code is textual. While I cannot find anything in Debian policy about this (only discussions of the topic), OSI carefully declines to mention text as either necessary or sufficient for a definition of source code. Here is the relevant part of OSI's open-source definition: The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed. (item 2 of OSI's Open Source Definition) Finally, I cannot resist a followon to Andreas' accurate comments. *All* source code is organic, evolving, and comparable to a living organism. Not even Linus Torvalds could duplicate Linux if you locked him in a room with no Internet access. Code is grown. -Lex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372590: ITP: scala -- The Scala programming language
Package: wnpp Severity: wishlist Owner: Lex Spoon [EMAIL PROTECTED] * Package name: scala Version : 2.1.5 Upstream Author : Martin Odersky [EMAIL PROTECTED] * URL : http://scala.epfl.ch * License : BSD-like (http://scala.epfl.ch/downloads/license.html) Programming Lang: Java, Scala Description : The Scala programming language Scala is a practical but advanced programming language. It is practical in that it is fully compatible with Java and even runs on JVM's. It is advanced in that, despite the constraint of working with Java, it includes: closures, nested classes with a purer semantics than Java's inner classes, a uniform object model where even int's are objects, type members of classes, top-level singleton objects, mixins, generalized abstract data types (GADT's), and more. I am working for the Scala team--LAMP--and would like to make Debian packages of Scala's open-source distribution. This would provide support for distributing future Debian packages written in Scala, and it would allow Debian users to conveniently access this great programming language. I would like to distribute the following binary Debian packages: scala-library: The minimal runtime support for Scala programs (namely, scala-library.jar). Packages written in Scala would depend on this one. scala-dev: Core development tools for Scala, including the compiler, interepreter, script-runner, and jar extractor (scalap). sbaz: Scala Bazaars, the Scala community's own, cross-platform package distribution system. scala: An umbrella package depending on the above three. People wanting to play with Scala would grab this package. These binary packages would come from two source packages, analogous to the repository structure used upstream: scala-core: scala-library, scala-dev, scala sbaz: sbaz Thus far I have a prototype packaging as described above, but I keep finding one more thing to tidy up before posting them. I currently aim to post the packages in 1-2 weeks. The only possible issue I see with packaging Scala is that other members may perceive me to have a conflict of interest because I work for LAMP. I do not believe this is a problem--LAMP's interest is the same as Debian's in that we want to have a DFSG-like distribution of Scala--but of course I am not in a position to make that decision! I look forward to people's thoughts. Lex Spoon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#236721: Squeak in Debian main
Ben, Ambiguity is the proper status for this RFP. While it remains so, people should use the external Squeak/Debian distribution. It is described as follows: http://minnow.cc.gatech.edu/squeak/3616 I am in the process of transfering maintainership to Matej Kosik ([EMAIL PROTECTED]). He (or whoever he says) should be the main point person for future discussions of Squeak's Debian packages. While I think Debian should include Squeak in its distribution, I do not have time to champion that cause on the mailing lists and bug trackers. On the RFP itself, as far as I can tell, Squeak-L fits the spirit of DFSG, but I did not argue the case. Instead, I argued that Squeak-L is suitable for distribution in non-free, but even there there was debate. I spent considerable time on debian-legal, but the arguments went in circles. Here is the main thread as best I can remember: http://lists.debian.org/debian-legal/2004/04/msg00160.html The following page has my notes about the discussion on debian-legal: http://minnow.cc.gatech.edu/squeak/3733 The one new item since that page's status is that Squeak 1.1 is now available under APSL. This provides a separate avenue for getting some versions of Squeak into Debian proper. http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-May/104466.h tml I will append the current summary from Swiki page 3733 cited above, just so that they are recorded on the bug log. -Lex --- below this line comes from Squeak Swiki page 3733 This page summarizes the debate on whether Squeak will go into Debian non-free. If it does go in, then this page will probably be added to the package for future reference. If it does not go in, then this page will be posted to debian-legal for the archives. Please post any comments, questions, or objections at the bottom of the page, or even better, comment to the debian-legal mailing list. This way, the main content of the page has a single editor. Nothing on this page is official in any way; it is just one person's attempt to summarize the state of the discussion. Status As of April 30, 2004, Squeak is not included in Debian. Debian users can still obtain packages for Squeak as described on Squeak for Debian Users. There is some discussion on the debian-legal mailing list about whether Squeak may be distributed in Debian non-free. Non-Free versus Main Some clauses of the Squeak-L seem to violate the DFSG. Most notably, the export clause is an issue. Thus, while most agree that Squeak is an extremely free and permissive license, it is not suitable for Debian/main. Thus, the current discussion is on whether Debian will include Squeak in non-free. To do this, Squeak-L must provide sufficient premission, it must impose sufficiently few requirements, and it must incur sufficiently low liability. Issues on Particular Parts of the License Export Restrictions Squeak-L requires that any distribution of Squeak follows US Export Law. Since Squeak does not include any cryptographic software, the main requirement seems to be that Squeak not be distributed to countries embargoed by the US. It is still being discussed whether Debian can enforce this satisfactorily. It has been noted that some Debian servers might already be enforcing the restriction, but there is as yet no verification on which servers those are. It has been argued that mirrors of US-based servers still need to have the same protections as the US-based servers, anyway, because US law makes it illegal to export to someone who will then reexport to an embargoed country. Thus we may want to adjust our servers anyway to disallow downloads from embargoed countries. Summary: open issue Indemnification In some circumstances, the license requires people who distribute Squeak, to reimburse Apple for legal fees accrued in response to litigation involving the distribution. However, the liability is carefully tailored to restrict the liability: Debian would only be liable for legal fees to the extent a suit is related to Debian's distribution of Squeak. Additionally, it is extremely unlikely that Apple will be sued over Squeak at all, much much less in any way that involves Debian's distribution of Squeak. If someone has a problem with Debian distributing Squeak, then they are much more likely to sue Debian directly. In fact, if someone does sue Apple over Debian's distribution, then Apple must give Debian an offer to defend the case themselves if they prefer; if Apple does not offer this opportunity, then Apple cannot request legal fees. summary: open issue Computers under Direct Use The license contains this text: 2. Permitted Uses and Restrictions. This License allows you to copy, install and use the Apple Software on an unlimited number of computers under your direct control. Two people have claimed that this renders Squeak non-distributable by Debian, but the reasoning is unclear to this editor. The counterargument is that this sentence merely grants permissions, and
Bug#369520: kwalletmanager: New wallet quietly does nothing if subsystem disabled
Package: kwalletmanager Version: 4:3.5.2-1+b2 Severity: minor After a fresh install, the wallet subsystem is disabled, and New Wallet does nothing at all. I had to first enable the subsystem, and then New Wallet worked as expected. If New Wallet is not going to do anything, it should give a brief message like Cannot create wallet because the wallet subsystem is currently disabled; would you like to enable it now? -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages kwalletmanager depends on: ii kdelibs4c2a 4:3.5.2-2+b1 core libraries for all KDE applica ii libc6 2.3.6-9 GNU C Library: Shared libraries ii libgcc1 1:4.1.0-4GCC support library ii libqt3-mt 3:3.3.6-2Qt GUI Library (Threaded runtime v ii libstdc++6 4.1.0-4 The GNU Standard C++ Library v3 kwalletmanager recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363559: xserver-xorg-video-ati: system freezes on Thinkpad T42
Ah, great. I was wondering how something like this could slip through the cracks. Still, at some point maybe we should back up the ATI driver to the older version, if that is even possible? Or, maybe there is a manual workaround that is not much trouble? Backing up via snapshot.debian.net is a real chore in this case. -Lex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363559: xserver-xorg-video-ati: system freezes on Thinkpad T42
Package: xserver-xorg-video-ati Version: 1:6.5.7.3-3 Severity: important The current version of the ati driver causes my Thinkpad T42 to freeze a few minutes after X is started. Changing to the vesa driver causes the freezes to stop. Commenting out all loaded modules from the Module section of xorg.conf causes the freeze to take longer to happen, but it does not prevent it. Likewise, turning off hardware acceleration with the NoAccel option does not prevent the freezes (though I do not recall whether NoAccel made the freeze take longer to happen). The chipset is: (--) RADEON(0): Chipset: ATI FireGL Mobility T2 (M10) NT (AGP) (ChipID = 0x4e54) For now I have used snapshot.debian.net to downgrade to 6.8.2.dfsg.1-6 and all is well again. I have been having this problem for much or all of 2006. I believe 6.9.x already had the problem, and no update through 1:6.5.7.3-3 has fixed it. The following thread describes the same problem I am seeing, but unfortunately with no resolution reached: http://hardware.mcse.ms/archive42-2006-1-276052.html Here is my xorg.conf: # xorg.conf.dpkg-new (Xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf.dpkg-new manual page. # (Type man xorg.conf.dpkg-new at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following commands as root: # # cp /etc/X11/xorg.conf.dpkg-new /etc/X11/xorg.conf.dpkg-new.custom # md5sum /etc/X11/xorg.conf.dpkg-new /var/lib/xfree86/xorg.conf.dpkg-new.md5sum # dpkg-reconfigure xserver-xorg Section Files FontPathunix/:7101 FontPathunix/:7100 # if the local font server has problems, we can fall back on these FontPath/usr/lib/X11/fonts/misc FontPath/usr/lib/X11/fonts/cyrillic FontPath/usr/lib/X11/fonts/100dpi/:unscaled FontPath/usr/lib/X11/fonts/75dpi/:unscaled FontPath/usr/lib/X11/fonts/Type1 FontPath/usr/lib/X11/fonts/CID FontPath/usr/lib/X11/fonts/100dpi FontPath/usr/lib/X11/fonts/75dpi EndSection Section Module Loadbitmap Loaddbe Loadddc Loaddri Loadextmod Loadfreetype Loadglx Loadint10 Loadrecord Loadtype1 Loadv4l Loadvbe EndSection Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xorg Option XkbModel pc105 Option XkbLayout dvorak EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/input/mice Option Protocol ExplorerPS/2 Option Emulate3Buttons true Option ZAxisMapping 4 5 EndSection Section InputDevice Identifier Synaptics Touchpad Driver synaptics Option SendCoreEventstrue Option Device/dev/psaux Option Protocol auto-dev Option HorizScrollDelta 0 EndSection Section Device Identifier ATI Driver ati BusID PCI:1:0:0 Option DynamicClocks on Option UseFBDev false Option MonitorLayout LVDS, CRT #Option NoAccel true # reasonable guesses at limits Option CRT2HSync15-92 # Option CRT2VRefresh 50-85 # the Dell LCD I am using at EPFL can only handle 1600x1200 at 60 Hz Option CRT2VRefresh 50-60 Option MergedFB on EndSection Section Device Identifier Framebuffer Driver fbdev EndSection Section Device Identifier VESA Driver vesa Option ModeSetClearScreen off EndSection Section Monitor Identifier Generic Monitor Option DPMS DisplaySize 305 229 EndSection Section Screen Identifier Default Screen Device ATI # Device Framebuffer # Device VESA Monitor Generic Monitor DefaultDepth24 SubSection Display Depth 1 Modes 1600x1200 1024x768 800x600 640x480 EndSubSection
Bug#347680: Xorg breaks acpid
Marcus's analysis looks right to me: But who can tell which is the grand-piece-of-sw that has the exclusive right to open /proc/acpi/event? The one which has been designed to multiplex the events to make them available to other programs, and it's acpid. The standard Debian setup is to use acpid to multiplex the event stream. Even if it is possible to run with acpid, that should be a different, non-standard option. There are lots of reasons to multiplex in userspace instead of in the kernel. Among these is that a userspace multiplexer can filter and modify the stream as it goes by, and a userspace multiplexer can pull events from multiple sources including virtual events injected by other sources than the raw hardware. The earlier comments that obviously the kernel should multiplex just aren't right. Doing it in userspace makes sense, and if it is done in userspace, then additionally doing it in the kernel would be a bad thing. At any rate, the current strategy isn't right. If the system is using acpid--the most common configuration--then it is a bug for X to get in the way of acpid. It is laudable that Xorg currently tries to support ACPI even when acpid is not running. However, this is an unusual and only marginally useful configuration, isn't it? Thus, if nothing else, it would seem to make sense to simply remove the non-acpid ACPI support when compiling for Debian. In that case, the party line would be, if you want to use ACPI, then you install acpid and programs talk to that. If it is still desirable to make X work without acpid around, then that should surely be a non-standard configuration which requires an *explicit* configuration option on the X server. This does not appear worthwhile for Debian, since we do have acpid easily installable, but maybe it is sufficiently worthwhile for other Linux distributions that it is worth including. -Lex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308169: debootstrap: can't mmap package info file
Package: debootstrap Version: 0.2.45-0.2 Severity: important debootstrap fails with the following error: I: Installing core packages... dpkg: can't mmap package info file `/var/lib/dpkg/available': Invalid argument W: Failure trying to run: chroot /root/woody-chroot dpkg --force-depends --install /var/cache/apt/archives/base-files_3.0.2_i386.deb /var/cache/apt/archives/base-passwd_3.4.1_i386.deb The file does exist but has size 0: # ls -l woody-chroot/var/lib/dpkg/available -rw-r--r-- 1 root root 0 May 8 11:02 woody-chroot/var/lib/dpkg/available -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.12-rc2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages debootstrap depends on: ii binutils2.15-5 The GNU assembler, linker and bina ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii wget1.9.1-11 retrieves files from the web -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#283366: audiooss: sound on a second x-screen not sent to default x-server
Hendrik Wouters [EMAIL PROTECTED] wrote: So I run the following command on a black Linux console (not X): $ X -query host :1 . This gives me a second virtual screen. Actually, this virtual screen is on the same physical display (aside from the virtual screen that is started by kdm automatically). I can switch to both screens by pressing CTRL-ALT-F7 and CTRL-ALT-F8. On the first virtual screen, auplay and co. take the current X-server (the computer who has the screen; you can name it the X-terminal if you want) as the default nas server, which is very convenient. But on the second virtual screen, that I started manually with X -query host :1 , nas programs don't take the X-server as default nas audio server. It looks like all nas programs are confused about the current x-server on the second virtual screen? end quote Okay, I see. So when you run NAS programs on the :1 server, you get no sound at all? I think you need to specify the following in one of your login files: export AUDIOSERVER=unix:0 The thing is, NAS has its own server, distinct from the X server. It would be nice if X servers had NAS built in, but that is not the case for most X servers. Instead, a default installation on Debian is going to start a single NAS server that everyone on the machine is supposed to use. This is different from what the NAS libraries assume: they assume that every X server has its own NAS server associated with it. So in fact, it looks like the NAS libraries (and thus audiooss) *are* trying to talk to the :1 NAS server... but they need to talk to :0! Explanations aside, does the AUDIOSERVER command above get sound working for you on the :1 display? (I'm CC-ing to the bug tracker, because other people are likely to be running into the same thing, whatever it turns out to be.) -Lex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#283366: audiooss: sound on a second x-screen not sent to default x-server
Hendrik, Sorry for the delay. Do you still have the same setup as when you emailed this bug report? I suspect your wish is for a change to NAS in general, and not just audiooss. Have you tried other NAS programs like auplay? Do they do the same thing, or are they doing what you ask for? I bet they are the same, because audiooss calls AuOpenServer with most of the arguments set to NULL. It thus inherits settings from the environment, just like most NAS programs. Here's the mailing list, if you decide that is the issue: http://radscan.com/nas.html#MAILLST Something you may also want to play around with, is setting AUDIOSERVER explicitly instead of relying on DISPLAY. You can set it this way to tell it to connect over TCP: export AUDIOSERVER=hostname:port or this way to tell it to connect to a Unix-domain socket on the local host: export AUDIOSERVER=unix:port If none of this is helpful, can you tell me more about your setup? You have two displays on the machine, and two NAS servers, yet all programs talk to the NAS server which is supposed to correspond to the first display? Lex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
