Bug#476900: ITP: fglrx-kernel-modules -- fglrx (ATI driver) kernel module build against the last kernel
Package: wnpp Severity: wishlist Owner: Bertrand Marc <[EMAIL PROTECTED]> * Package name: fglrx-kernel-modules Version : 1:8-4-1 Upstream Author : ATI/AMD * URL : http://ati.amd.com/support/drivers/linux/linux-radeon.html * License : restricted Description : fglrx (ATI driver) kernel module build against the last kernel It is a simple package that provide the fglrx kernel module compiled for the last 2.6 kernel found in Debian. It compiles fglrx-kernel-src. There would be no need of module-assistant to get (proprietary) 3D acceleration working. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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]
Split a package, rename an init file
Hello, I'd like to split a package foo into 2 new packages : foo and foo-daemon. To do that I moved the daemon and the other obvious files with dh_install -pfoo-dameon. I used dh_installinit to install the init.d file to the foo-daemon package. Everything seems fine, but when I upgrade foo to the new foo+foo-daemon. I get 2 files in /etc/init.d/ : foo and foo-daemon. Here are my questions : what am I doing wrong ? How can I remove the /etc/init.d/foo unnecessary file ? Regards, Bertrand 2 things : I'm an not on debian-devel, and in this case foo = fglrx-driver -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Split a package, rename an init file
Thanks for your answers! So I guess the best way to do this is to split the package and use dh_installinit --name=foo This way I can provide the buggy binary daemon in a seperate package (recommended by foo), and keep the name of the conffiles. Do you think of something else? Regards, Bertrand Adam Majer a écrit : Bertrand Marc wrote: Hello, I'd like to split a package foo into 2 new packages : foo and foo-daemon. To do that I moved the daemon and the other obvious files with dh_install -pfoo-dameon. I used dh_installinit to install the init.d file to the foo-daemon package. Here are my questions : what am I doing wrong ? How can I remove the /etc/init.d/foo unnecessary file ? No, you can't just remove /etc/init.d/foo. It is a conffile and may be modified by admin. You should probably keep /etc/init.d/foo instead of renaming it foo-daemon. 2 things : I'm an not on debian-devel, and in this case foo = fglrx-driver Will foo depend on foo-daemon? If yes, why are you splitting the package? - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Split a package, rename an init file
I'm currently using fglrx without atieventsd (for testing pupose). Everything is working fine except for the acpi stuffs. Whenever I'm on battery, I have to manually configure aticonfig with --set-powerstate 1. Except for this, everything is fine. I have 3D acceleration, as usual. Adam Majer a écrit : Bertrand Marc wrote: Thanks for your answers! So I guess the best way to do this is to split the package and use dh_installinit --name=foo This way I can provide the buggy binary daemon in a seperate package (recommended by foo), and keep the name of the conffiles. Do you think of something else? So the fglrx driver works fine *without* the daemon? - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#594800: ITP: 0ad -- 3D real-time strategy (RTS) game of ancient warfare
Package: wnpp Severity: wishlist Owner: Bertrand Marc * Package name: 0ad Version : alpha1~r07970 Upstream Author : Wildfire Games * URL : http://wildfiregames.com/0ad/ * License : GPL, LGPL, MIT Programming Lang: C++ Description : 3D real-time strategy (RTS) game of ancient warfare Historically-based war/economy game that allows players to relive or rewrite the history of Western civilizations, focusing on the years between 500 B.C. and 500 A.D. The project is highly ambitious, involving state-of-the-art 3D graphics, detailed artwork, sound, and a flexible and powerful custom-built game engine. This package would contain the main program. -- 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/20100829162047.430.99458.report...@localhost.localdomain
Bug#594802: ITP: 0ad-data -- 3D real-time strategy (RTS) game of ancient warfare
Package: wnpp Severity: wishlist Owner: Bertrand Marc * Package name: 0ad-data Version : alpha1~r07970 Upstream Author : Wildfire Games * URL : http://wildfiregames.com/0ad/ * License : CC-BY-SA Programming Lang: Description : 3D real-time strategy (RTS) game of ancient warfare Historically-based war/economy game that allows players to relive or rewrite the history of Western civilizations, focusing on the years between 500 B.C. and 500 A.D. The project is highly ambitious, involving state-of-the-art 3D graphics, detailed artwork, sound, and a flexible and powerful custom-built game engine. This package contains the data files. -- 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/20100829162739.496.75730.report...@localhost.localdomain
PlayOnLinux in contrib
Hi, I am the current owner of the ITP bug #485149 for PlayOnLinux and I have a question about this (free) software. PlayOnLinux is a front-end for Wine. Its aim is to provide a nice way (without command line) to install programs built for Windows. Therefore it allows the user to install proprietary softwares (in /home of course) such as commercial games and other closed source softwares. The PlayOnLinux program itself is written under the GPL2+ so I (and my sponsor) think it could be uploaded to contrib. Do you think such a program which allows to easily install proprietary softs in a Debian system would be acceptable in contrib and would not be a policy violation ? Regards, Bertrand Marc PS Please CC me as I am not on this list. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: PlayOnLinux in contrib
Mehdi Dogguy a écrit : If it's GPLv2+ and doesn't depend on proprietary software, why it cannot be in main? Does it depend on proprietary things? Regards, As it is now, PlayOnLinux makes the user install Microsoft fonts. You can say no, but it will keep asking every time you start PlayOnLinux. We are currently thinking to add a Depends: ttf-mscorefonts-installer because of that... Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Depend on a package from an other arch
Dear developpers, I am trying to fix Debian bug #783875 [1]: playonlinux (which is arch independant) should depend on the 32 bits version of wine. Therefore I added a dependency on wine32|wine32-development, but it seems the package will not migrate to testing [2], because wine32 is not available on amd64. Niels Thykier suggested on mentors that this could be an issue with the testing migration code [3], so I send this question to debian-release@ too. I thought I should instead add a dependency on wine32:any | wine32-development:any and ask the wine maintainer to move to multiarch:allowed. But the best source on this subject is an Ubuntu one [4]. I cannot find any reliable Debian source about this and it seems I was wrong [3]. Could you give me a pointer on this ? Or do you know any package with a dependency on a package from an other arch ? Thanks, Bertrand PS Please CC me as I am not subscribed to these lists. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783875 [2] https://packages.qa.debian.org/p/playonlinux.html [3] https://lists.debian.org/debian-mentors/2015/08/msg00153.html [4] https://wiki.ubuntu.com/MultiarchSpec signature.asc Description: OpenPGP digital signature
