Re: Reviving timidity sourceforge project and doing a new official release
Hello TAMUKI and a lot of others (Cc: Various Debian people involved in $subject) On 12/03/2011 01:09 PM, TAMUKI Shoichi wrote: Hello Hans, (Cc: TiMidity++ developers) From: Hans de Goede So now I've a nice and polished version of timidity, and given that the latest official release has been 6 years ago I think it would be good to do a new official release. Thank you for your great effort to maintain TiMidity++ package for Fedora project. I looked into your patches, and I think they are almost fine. Thanks you for taking the time to look into all my patches and to merge most of them! And I must also say I'm very happy to see one of the original timidity developers back in action. You very likely know the timidity internals a lot better then me. The patch 0004 (thanks to Debian) fixes a number of typos in the man pages, but the hunks related to "FILES" and "SEE ALSO" will be omitted to leave them just as they are. Ok. Sorry, the patch 0005 seems to be ad hoc, so this will be omitted. I think that cases may be solved by the packagers' workaround and/or users' operation. Well it cannot be fixed by the users operation, unless they use scripts to move one config file out of place and another in to place whenever they start one of the involved apps. The fundamental problem is that now a days we've multiple apps using timidity.cfg and all but one of them expect timidity.cfg to point to GUS format patches. Anyways I'll start a separate email thread for this mostly aimed at explaining the problem to the Debian developers and try to come up with a solution which can be shared between Debian and Fedora. Once we (Debian and Fedora) have a consensus on how to handle this, I hope you will re-consider merging our solution. The patch 0011 will be also omitted. These shebang paths need to be corrected by packagers for now. TiMidity++ is conventionally designed for casual users' convenience. (i.e. ./configure with default prefix) :-) I see in a later mail in this thread that you've merged it after all in a slightly different version, thanks for that! For the patch 0013, autoreconf vs INSTALL issue should be solved by the packagers workaround as needed, so this patch will be omitted. I agree that my solution for this was not pretty, so instead I've now created a new autogen.sh file (attached), which takes care of re-generating *all* the autofoo related files while keeping INSTALL intact. Please add this to the cvs tree, and be sure to chmod +x it before adding it! While on the subject of all the autofoo generated files, must FOSS projects do not keep these in CVS/git instead users of the CVS/git tree are expected to run ./autogen.sh after a checkout. This avoids cluttering the history with changes to autogenerated files. I strongly believe we should adopt the same practice for timidity. With the patch 0018, I got a "undefined reference to" error during linking, so this patch will be also omitted. Patch 0018 should not be omitted it is definitively a correct patch, if timidity is build without any X11 based userinterfaces build in, it should not be linked against libX11, this is important for distributions, otherwise the cmdline only timidity package will depend on X11 for no good reason. I believe the "undefined reference to" error you got during linking means that you've build in a X11 based userinterface, and that we've a bug in the Makefiles where enabling that ui does not cause -lX11 to be added to the LIBS. But the code patch 0018 removes causes lX11 to be added to the LIBS always, iow independent of which UI's are enabled and that is just wrong. Can you please give me the ./configure line you were using which causes the "undefined reference to" errors when building with patch 0018? Then I'll try to reproduce and come up with a proper fix. As such I would like to ask you to become an admin for the sf.net timidity project, once that is done I plan to: 1) Create a (sf.net hosted) git tree based on converting CVS to git 2) Add my patches 3) Bump the release to 2.14, bake a tarbal, release 4) profit? That's not a bad idea to convert CVS to git, but we are not in trouble for now, so please let us keep the current environment. FYI, TiMidity++ hourly tarballs and released tarballs are created with attached shell scripts respectively. All files in the tar ball keep mtime as committed to see easily which files are newer or older. Note that some files was given wrong access perms when the initial commit. Therefore, their access perms should be corrected after cvs co. I would *really really* prefer to move to git, as once you get the hang of it is just so much easier and better then CVS. For example in git you can change permissions of files after there initial adding to the repository :) About your other mails, I've read through them all to, thanks for the updates. I'm going to reply to some of the things in there here, to avoid spamming everybody with 4 mails on this topic:
Bug#651683: ITP: pythontoolkit -- interactive environment for Python
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: pythontoolkit Version : 11.4.06 Upstream Author : T.Charrett * URL : http://pythontoolkit.sourceforge.net/ * License : GPL-3 Programming Lang: Python Description : interactive environment for Python PythonToolkit (PTK) is an interactive environment for Python. It was originally designed to provide a Python based environment similar to Matlab for scientists and engineers when used together with the numpy, scipy and matplotlib Python packages. However it can also be used as a general purpose interactive Python environment especially for interactive gui programming. . It is built around a console window and simple Python source editor and a Tool plugin system so that extra features and support for Python packages can be easily added. . Main features: * Console window with support for multiple Python interpreters (Engines). * Engines are external processes so that each engine is completely separated from the others and the PTK interface. * Interactively program with different GUI toolkits (wxPython, TkInter, pyGTK, pyQT4 and PySide). * Builtin Python debugger integrated with tools and editor. * Object auto-completions and calltips. * Multi-line command editing. * Command history (previous/next and search for partially typed commands). * Simple editor for code testing and scripting or everyday work. * Set, edit and clear debugger breakpoints via the editor. * A matlab style namespace/workspace browser tool that can be extended to support new types and classes. * A path manager tool to easily change the current working directory and manage the Python search paths. * A Python object inspector tool showing object docstring, code, and values. * GUI viewers for Python data types. * Python object importer/exporter system to save and load data easily. -- 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/2011122052.29623.12817.reportbug@alessio-laptop
Bug#651697: ITP: python-fftw -- FFTW bindings for python
Package: wnpp Severity: wishlist Owner: Jerome Kieffer Package name: python-fftw Version : 0.2.2 Upstream Author : Jochen Schroeder URL : https://launchpad.net/pyfftw License : GPL Programming Lang: Python Description : Python bindings to the FFTW3 C-library for computing discrete Fourier transforms. Python bindings to the FFTW3 "Fastest Fourier Transform in the West." C-library (http://www.fftw.org/) for computing discrete Fourier transforms. PyFFTW are python bindings for the FFTW3 C-routines, using numpy and ctypes. It includes a somewhat pythonic interface to the FFTW routines, but leaves the concept of creating plans and executing these plans intact. -- 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/20111211130549.8036.42033.report...@patagonia.fournet.lan
Re: Work-needing packages report for Dec 9, 2011
Russ Allbery writes: > Goswin von Brederlow writes: > >> But there is no way to find bugs taged help given a skillset. So unless >> you specifically think "Lets fix something in grub today" and go looking >> for grub bugs tagged help you never find them. > >> Say today you want to write some manpages. How do you find a RFH bug >> about adding or fixing manpages? > > That sounds great, and like something there's no way anyone's going to > have time to do. If we had time to classify any significant number of > bugs that way, we would have been able to resolve them, particularly the > easy ones. :) > > It takes a lot of effort to maintain that level of metadata. We struggle > with keeping up with the basic "fixed" or "not fixed" bug metadata. I envision this not so much for actual bugs but as a way for projects to attract new members. For things that would be nice to have but don't make the package unsuitable for release if they aren't done. Like getting rid of legacy functions. Or other small issues that aren't pressing but will be done by the team eventually if time frees up. If a package / team gets to the point where they are only keeping up (or falling behind) with the basic "fixed" or "not fixed" bug metadata then one could say it is already too late. But lets say they do keep up with it, barely. Then how are they going to improve? A "RFH: please take over developing dselect" in wnpp is not going to help as history shows. The task is just to big for anyone new to take over. And anyone already involved in dpkg doesn't need the wnpp bug to see dselect needs help. Give them some bait and get them hooked before springing monumental tasks on them. Think of it as a kind of advertising. MfG Goswin -- 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/87aa6z9p6p.fsf@frosties.localnet
Re: Red Hat is moving from / to /usr/
I demand that Stephan Seitz may or may not have written... > On Wed, Dec 07, 2011 at 11:34:34AM +0100, Marco d'Itri wrote: >> Actually, Red Hat's goal *is* to support a separate /usr, they just want >> to have the initramfs mount it. > But as was seen in the last discussion, not everyone *has* an initramfs, > because it is not needed in many cases or sometimes even not supported on > the platform. On any box for which I've built a kernel, there's no initramfs and (except in one case – netbook) there's a separate /usr. I'd quite like to keep it this way... / (without /usr) is often enough for rescue purposes (and if it isn't, it's enough to get /usr mounted). And if / is broken, then you have larger problems anyway. This mount-/usr/-in-initramfs looks to me like a means of reducing choice. -- | _ | Darren Salt, using Debian GNU/Linux (and Android) | ( ) | | X | ASCII Ribbon campaign against HTML e-mail | / \ | http://www.asciiribbon.org/ Take my advice, I'm not using it right now. -- 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/52455ef1f4%li...@youmustbejoking.demon.co.uk
Re: Red Hat is moving from / to /usr/
Darren Salt writes: > I demand that Stephan Seitz may or may not have written... > >> On Wed, Dec 07, 2011 at 11:34:34AM +0100, Marco d'Itri wrote: >>> Actually, Red Hat's goal *is* to support a separate /usr, they just want >>> to have the initramfs mount it. > >> But as was seen in the last discussion, not everyone *has* an initramfs, >> because it is not needed in many cases or sometimes even not supported on >> the platform. > > On any box for which I've built a kernel, there's no initramfs and (except in > one case â netbook) there's a separate /usr. I'd quite like to keep it this > way... To be honest most systems will have /usr localy and mounting it is no problem at all. So even with moving stuff from / to /usr it should not be a problem for them to mount /usr verry early during boot and have stuff keep working. I don't think anyone is considering moving /bin/mount just jet. > / (without /usr) is often enough for rescue purposes (and if it isn't, it's > enough to get /usr mounted). And if / is broken, then you have larger > problems anyway. > > This mount-/usr/-in-initramfs looks to me like a means of reducing choice. Or as a way to keep choices without complicating the standard case. If you do want to have a /usr mounted as NFS4 over wlan then you need an initramfs. If you have it as local partition then you don't. Consider it from that point of view. I'm still not for moving / to /usr but lets say I am less opposed now than I was at the initial mail. If it "breaks" less than 1% of setups and they need to use an initramfs to keep working then that is probably ok. Or another process that moves things to the / filesystem on a need by need basis. It MUST keep working though. Requiring that people repartition is no an option. MfG Goswin -- 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/87y5uj89gy.fsf@frosties.localnet
Help with package
Hi, I know that this mail list is not debian-mentors. I am so sorry for this mail, but I sent a lot of mails to upload the package "wmaker" and I don't know what to do. Some DD help me with the package [thanks a lot], first Anibal, Paul (DM) and Lisandro, but the package was not uploaded. Why? Is a big/complicated package, with many changes, they don't use wmaker, Paul cannot upload the package because is DM,... (but they help me a lot with the package!). Please, can somebody help me to maintain/upload the package? Thanks a lot, sorry for the Off Topic, but I don't know what to do with wmaker. On the other hand, I am trying to be DM. I worked in wmaker, uswsusp, wmmixer and wmmoonclock packages. If somebody can upload the package, I will be so glad if s/he can sponsor me. Best Regards, kix. p.s. The package is at mentors: http://mentors.debian.net/debian/pool/main/w/wmaker/wmaker_0.95.0-1.dsc p.p.s Anibal, Lisandro, Paul, if you want to add anything to this mail, feel free. Thanks for your help. Rodolfo. -- 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/4ee51578.1060...@kix.es
Re: Help with package
On Sun 11 Dec 2011 17:41:28 Rodolfo kix Garcia escribió: > Hi, > > I know that this mail list is not debian-mentors. I am so sorry for this > mail, but I sent a lot of mails to upload the package "wmaker" and I > don't know what to do. Some DD help me with the package [thanks a lot], > first Anibal, Paul (DM) and Lisandro, but the package was not uploaded. > Why? Is a big/complicated package, with many changes, they don't use > wmaker, Paul cannot upload the package because is DM,... (but they help > me a lot with the package!). > > Please, can somebody help me to maintain/upload the package? I can add that Rodolfo is doing a great effort for trying to adopt wmaker. If some DD is interested in maintaining wmaker will find in him a great team mate. He still needs to learn some stuff, but he is very proactive to it. > On the other hand, I am trying to be DM. I worked in wmaker, uswsusp, > wmmixer and wmmoonclock packages. If somebody can upload the package, I > will be so glad if s/he can sponsor me. I have been chaging some lines with Rodolfo here, I'll continue to happily sponsor his other packages. Kinds regards, Lisandro. -- “If you want to finish university, you should take care about getting on with the teachers. The result are submissive citizens that won’t face authority even if they know they’re right, in order to avoid problems“ Miriam Ruiz, http://www.miriamruiz.es/weblog/?p=187 Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -- 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/201112111828.50510.lisan...@debian.org
Bug#651766: ITP: instead-game-toilet3in1 -- quest/puzzle game
Package: wnpp Severity: wishlist Owner: Sam Protsenko * Package name: instead-game-toilet3in1 Version : 1.0 Upstream Author : Peter Kosyh * URL : http://toilet.syscall.ru * License : CC-BY-3.0 Programming Lang: Lua Description : quest/puzzle game Escape The Toilet: Triple Flush . Quest and puzzle game, in which you need to escape from the toilet. . This package already contains three versions of this game. . "You don't remember how you got here. You have not really woken up. The only thing that you are currently able to comprehend is that you are in your own toilet... A key feature of the game: you can get out of the toilet only by yourself! And not necessary today. You can escape it tomorrow for example - on a fresh mind." . The game contains 3D graphics that was made in Blender and quite pretty tracker music and sound effects. -- 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/20111212004405.7788.14684.report...@joe-pc.joe-network.org
Re: Getting dh_install to do what we need
If I understand well, this thread deals, among other things, with different ways to transmit a variable from debian/rules to dh_install. - via override_dh_install: and command line arguments - via debian/*.install static content - via debian/*.install.in content, preprocessed (with environment variables) - via debian/*.install execution output (based on environment) 1/ From this point of view, FOO_SOVERSION is similar to DEB_HOST_MULTIARCH. As the soversion is mentioned in the library binary package name, only the first solution applies to it, unless the file is preprocessed *and renamed*. override_dh_install: dh_install --package=libfoo$(FOO_SOVERSION) lib/libfoo.so.$(FOO_SOVERSION) usr/lib/$(DEB_HOST_MULTIARCH) dh_install 2/ As a novice packager, I had a hard time figuring the execution flow of the debhelper tools, and specially variable values transmission across the hierarchy of subprocesses, even if each step is well documented. It is quite instructive to read, in this very thread, experimented DD arguing whether some dpkg-buildflag variable is available to a particular program called by a dh_tool at a specific compatibility level, and having to run the program once to know for sure… The first solution provides, in debian/rules, the equivalent of a method call with an explicit list of named actual parameters. In this analogy, environment variables are global variables, and should be avoided when possible. 3/ The way debhelper splits its work in small tools does not always fit the separation of human concerns. For example, the following is IMHO more readable that generating/executing a single debian/*.install file in which each line deals with a different library. # foo stuff override_dh_install:: dh_install --package=libfoo$(FOO_SOVERSION) lib/libfoo.so.$(FOO_SOVERSION) usr/lib/$(DEB_HOST_MULTIARCH) override_dh_link:: dh_link --package=libfoo-dev usr/lib/$(DEB_HOST_MULTIARCH)/libfoo.so.$(FOO_SOVERSION) usr/lib/$(DEB_HOST_MULTIARCH)/libfoo.so … more foo stuff # bar stuff override_dh_install:: dh_install --package=libbar$(BAR_SOVERSION) lib/libbar.so.$(BAR_SOVERSION) usr/lib/$(DEB_HOST_MULTIARCH) … more bar stuff # At the end override_dh_install:: dh_install --remaining-packages override_dh_link:: dh_link --remaining-packages … and so on In short, I think that debian/*.install dynamic content should be discouraged. -- 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/20111212013038.GA2955@pegase
Re: Red Hat is moving from / to /usr/
On Thu, 08 Dec 2011 10:40:36 +0100 Goswin von Brederlow wrote: > Igor Pashev writes: > > > 07.12.2011 04:43, Marco d'Itri пишет: > >> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=12a362be5c1982f80dbfb75bda070208a2c99cdf > >> > >> Discuss. > >> > > I don't see any reason to move all into /usr from /, > > and make initrd for minimal system: > The initramfs on the other hand is made to fit. So if /usr isn't on a > networking filesystem (NFS) then you won't get networking stuff in the > initramfs. No raid then mdadm isn't included. No lvm and the initramfs > gets smaller again. And only select modules for one kernel are in > there. Huge space saving again. So an initramfs will/can be minimal. I assume this means it will be impossible to swap the hdd from one system to another without rebuilding the initramfs? Seems like a step backwards for flexability. thanks, kk -- Karl Goetz, (Kamping_Kaiser / VK7FOSS) http://www.kgoetz.id.au No, I won't join your social networking group signature.asc Description: PGP signature
Bug#651789: ITP: pentobi -- A clone of Blokus, a strategy board game based on the concept of polyominoes.
Package: wnpp Severity: wishlist Owner: Dean Evans X-Debbugs-CC: debian-devel@lists.debian.org Package name: pentobi Version : 0.3 Upstream Author : Markus Enzenberger URL : http://pentobi.sourceforge.net/ License : GPL3 Programming Lang: C++ Description : Pentobi is a clone of Blokus, a strategy board game based on the concept of polyominoes. Pentobi features 5 game versions; Classic, Classic Two-Playr, Duo, Trigon and Trigon Two-Player. Multiple levels of computer opponent difficulty. Game board save files in Smart Game Format including comments and move variations. Classic Gameplay: [1] The game is played on a square board divided into 20 rows and 20 columns, for a total of 400 squares. There are a total of 84 game tiles, organized into 21 shapes in each of four colors: blue, yellow, red, and green. The 21 shapes are based on free polyominoes, from one to five squares (one monomino, one domino, two trominoes/triominoes, five tetrominoes, and 12 pentominoes). The standard rules of play for all variations of the game are as follows: Order of play is based on color, with blue going first, followed by yellow, red, and green. The first piece played of each color is placed in one of the board's four corners. Each new piece played must be placed so that it touches at least one piece of the same color, with only corner-to-corner contact allowed - edges cannot touch. However, edge-to-edge contact is allowed when two pieces of different color are involved. When a player cannot place a piece, he or she passes, and play continues as normal. The game ends when no one can place a piece. When a game ends, the score is based on the number of squares in each player's unplayed pieces; a player loses one point for each square (e.g. a tetromino is worth -4 points). If a player played all of his or her pieces, he or she gets a bonus score of +20 points if the last piece played was a monomino, +15 points otherwise. [1] http://en.wikipedia.org/wiki/Blokus -- 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/20111212195350.63cca995@sidspace
Re: Red Hat is moving from / to /usr/
On Mo, Dez 12, 2011 at 05:36:41 (CET), Karl Goetz wrote: [...] >> The initramfs on the other hand is made to fit. So if /usr isn't on a >> networking filesystem (NFS) then you won't get networking stuff in the >> initramfs. No raid then mdadm isn't included. No lvm and the initramfs >> gets smaller again. And only select modules for one kernel are in >> there. Huge space saving again. So an initramfs will/can be minimal. > > I assume this means it will be impossible to swap the hdd from one > system to another without rebuilding the initramfs? Seems like a step > backwards for flexability. Trimming the initramfs is an *optional* feature. cf. /etc/initramfs-tools/initramfs.conf Cheers, Reinhard -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- 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/87obve1cxw@faui43f.informatik.uni-erlangen.de
