Bug#376672: libswt-gtk-3.1-java conflicts libswt3.1-gtk-java
package: libswt-gtk-3.1-java Hello! Is it really necessary to have both libswt-gtk-3.1-java and libswt3.1-gtk-java in the Debian archive and conflicting each other? This makes it impossible to have eclipse and azureus installed at the same time! Nice greetings, Fabian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374600: [Fwd: Re: Pine license change (debian-unofficial.org)]
package: pine severity: minor version: 4.64-1 Hello! Some weeks ago, I sent a request to the pine upstream authors for the permission to release pine as a binary package for http://www.debian-unofficial.org. My idea was to use the modifications for the pine source code that you introduced with the current Debian package (4.64-1), so that I would only have to change some files in the debian subdir (new changelog entry, no pine-tracker package, etc). Well, upstream grants me the permission, but wants two minor issues to be fixed in the source code (please see below) before. As I mentioned before, I do not want to do any changes to the source code outside the debian directory. Now I would like to ask you if you could fix these two small issues in the Debian package and release a new revision, so that I could use this for the binary package for d-u.o! Of course I will inform the upstream author about my plans. Thank you very much! Cheers, Fabian Weitergeleitete Nachricht Von: Hugh Sheets [EMAIL PROTECTED] An: Greffrath Fabian [EMAIL PROTECTED] Kopie: [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED] Betreff: Re: Pine license change (debian-unofficial.org) Datum: Fri, 16 Jun 2006 14:59:34 -0700 (PDT) Fabian, we have a license for you. In reviewing your changes, our engineer had the following comments: I question the following changes: In pine-4.64/imap/src/osdep/unix/env_unix.h MANDATORYLOCKPROT is set to 0600 from the correct 0666. This is discussed in: http://www.washington.edu/imap/IMAP-FAQs/index.html#5.5 Shared mailbox files (e.g., helpdesk) depend upon the locks being 0666 instead of 0600. In pine-4.64/imap/src/osdep/unix/os_slx.h #include time.h is added. time.h is already included three lines higher up in the source code. Why is this second included needed? I want to call your attention to line item 2.4 in the license. You will need to add an N to the version number of a modified Pine you distribute. Thanks for your patience and don't hesitate to contact us with any questions. Hugh Sheets Manager, Messaging Solutions Technology Engineering Group Distributed Systems University of Washington - The University of Washington Pine MESSAGING SOFTWARE Distribution License (...) 120 kB of license and legal notice, including complete Debian .diff file End of Pine License and Legal Notices On Wed, 7 Jun 2006, Greffrath Fabian wrote: Hello Hugh! I did not contact you for quite some time now, hope you still remember me and what we already talked about... I would like to ask you about the progress of the pine license change. You told me that there might be some success in the early new year (this was in 2005) and now half of 2006 is over without any visible changes. I would like to offer you some kind of compromise: Maybe you know that there is already a pine source package with a separate diff-file in Debian, which users may download and compile on their own computer. Although the modifications which are implemented by the diff-file are quite minor, there are no binary packages for pine in Debian, because the (let's call it 'old') license forbids to redistribute modified versions. So far, so good. Please allow me to distribute this modified version of Pine as a binary package. I am talking about the same package that Debian users will get when downloading and compiling pine on their own. Of course I will make clear in the documentation that this version of pine is not original and that they should report bugs to us, not you (Maybe you have some paraphrases prepared for situations like this. English is not my native language). To make clear what changes to the pine source code we are talking about, please have a look at the following diff-file: http://ftp.debian.org/debian/pool/non-free/p/pine/pine_4.64-1.diff.gz (This affects the version of pine currently in Debian. In the oldstable distribution of Debian there is still version 4.44 of pine.) Thank you very much! Nice Gretings, Fabian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372909: Support for 'Cherry CyMotion Master LINUX' keyboard
package: xlibs severity: wishlist Hello! Since the last weekend I am the proud owner of this special Linux-keyboard manufactured by Cherry [1]. It has only one problem: It does not work under Linux ;) After plugging the keyboard in (PS/2) I changed the line Option XkbModel pc105 in /etc/X11/xorg.conf to Option XkbModel cymotionlinux and restarted X to see if the new buttons work. Well, xev told me that about half of the special buttons (e.g. the ten on the left and right side of the keyboard) do not even send keycodes to the X server. On the cdrom which is bundled with the keyboard there is a package which installs you a daemon (!) to interpret the key events as well as somthing like a control center application, which wants you to install half of KDE as well... Because I did not want to run the daemon, I started some web research for an alternative way to get the special keys working and found a very detailed (german) howto in an ubuntu-forum [2]. They refer to a command line to set the right keycodes which can be found in a (again german) howto from Gentoo [3]. The line reads like this: setkeycodes e065 136 e070 161 e032 172 e05f 143 e063 145 e06d 171 e00b 177 e012 178 e017 137 e00a 135 e018 133 e071 148 e02c 149 e072 202 e007 129 e008 131 e05b 200 After running this as root and hacking it into a runlevel script as suggested, now X receives a keycode from every single key on this keyboard. We see, it is possible to get it running without Cherry's daemon, simply using X's 'household remedies'. -- My question is: Why do I have to do this manually? Why doesn't X interpret the keys correctly, although the cymotionlinux keyboard model is selected in the xorg.conf? Next problem is, that now all keys send keycodes, but most of them have cryptic names while some others send names like 'XF86Stop'. The ubuntu howto now tells that in this case you have to edit the file /etc/X11/xkb/symbols/inet in order to add some lines to the 'xkb_symbols cymotionlinux' section and remove some other lines. After another restart of X, all buttons now send their 'names'. -- Next question: Why do I have to do this manually? I expect that if a keyboard is supported, that all of it's keys are translated in the /etc/X11/xkb/symbols/inet file. This problem is not limited to the xlibs-packages, because xkb-data and xkb-data-legacy also include the (incomplete/wrong) /etc/X11/xkb/symbols/inet file. Is there any chance to get this fixed? Thank you very much. Nice greetings, Fabian [1]http://www.cherrycorp.com/english/office/cymotion-line_master_linux.htm [2]http://www.ubuntu-forum.de/artikel/9825/1/Cherry-CyMotion-Master-Linux-Dapper.html [3]http://de.gentoo-wiki.com/Cherry_CyMotion_Master_Linux#.C3.84nderungen_in_Dateien_vornehmen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370647: jumpnbump-menu: please add 'waiting for server'
package: jumpnbump version: 1.50-5 severity: wishlist In the 'Jump n Bump menu', when trying to play a network game my computer freezes in a low resolution mode with a non-working mouse, if I hit the 'client' button a second too early before my friend has run his 'server'. It would be nice, i f something like a 'waiting for server' mode could be implemented. I would also be a good idea if the software on the client side selects the same level (if available, else error-message!) that runs on the server, because else you will experience buggy gameplay. Thank you and nice greetings, Fabian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370650: jumpnbump-levels: rabbit disappears in upper left corner
package: jumpnbump-levels version: 0.0.20050626 severity: minor Hi! If I jump out of the screen in the upper left corner (at least in the standard level and some others), my rabbit will disappear for many seconds or maybe never fall back into the screen until I randomly press the arrow keys. To reproduce this behaviour run the standard level (jumpnbump.dat), place your rabbit somewhere on the yellow-looking platform in the upper left and press the jump-button. Maybe this bug belongs to the 'jumpnbump' package, but I filed it against the levels packaged as discussed before ;) Nice greetings, Fabian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369498: jumbnbump: manpage missing some hints
Am Dienstag, den 30.05.2006, 23:35 -0400 schrieb Francois Marier: Alright, I'll have to update the manpage. Thanks for letting me know! No problem ;) I noticed that too, however last time I checked, I didn't see any difference between 1.50 and 1.55. Feel free to tell me if I missed anything though. Well, this is strange. The files in the 1.55 tarball are stored in a directory called 'jumpnbump-1.50'. On the other hand the 1.55 tarball is 100 kB larger than the 1.50 one... Sure, I'd love to. Do you know of any other website carrying jumpnbump levels or you are saying that the current jumpnbump-levels Debian package is out of date? I just got the idea, because it is not possible to play the 'mslug3' level in double resolution, which lets it look rather ugly. This site has 50 MB of levels, but I have not tested them all yet ;) http://jumpnbump.spaceteddy.net/ BTW, I think I found another bug: If I jump out of the screen in the upper left corner (at least in the standard level and some others), my rabbit will disappear for many seconds or maybe never fall back into the screen until I randomly press the arrow keys. This is sometimes very annoying... Also, in the 'Jump n Bump menu', when trying to play a network game my computer freezes in a low resolution mode with a non-working mouse, if I run my 'client' a second too early before my friend has run his 'server'. It would be nice, i f something like a 'waiting for server' mode could be implemented. Just an idea... ;) Nice greetings, Fabian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369498: jumbnbump: manpage missing some hints
package: jumpnbump version: 1.50-5 severity: wishlist Hi! On the game's website I found in the Changelog, that AI was added in Version 1.5. I could not find out how to activate it though. The manpage in the upstream tarball http://www.jumpbump.mine.nu/port/jumpnbump-1.50.tar.gz told me the secret, that you have to press buttons 1 to 4 for computer players. The manpage of the Debian package does not include this hint. Also, there seems to be an upstream version 1.55 in this directory: http://www.jumpbump.mine.nu/port/ BTW, do you plan to add some more (recent) levels to the 'jumpnbump-levels' package? Thank you very much! Nice greetings, Fabian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366815: prboom: new uptream and opengl
package: prboom version: 2.2.6-3 severity: wishlist Hi! I have two requests concerning prboom: - Please consider packaging the new upstream version 2.4.1 - Please provide an OpenGL-enabled version of prboom in a separate package, e.g. 'prboom' and 'prboom-gl' Thank you! Nice greetings, Fabian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364711: x-window-system-core: broken dependencies?
package: x-window-system-core version: 6.9.0.dfsg.1-6 severity: wishlist Hello! I am wondering about the dependencies of the 'x-window-system-core' meta-package. Among others, it depends on the following packages: xlibmesa-dri, xlibmesa-gl | libgl1-mesa-dri, libglu1-xorg | libglu1-mesa This means that you have the choice to install the OpenGL graphics library and the OpenGL utility library from either the X.Org release or from the MESA release. Fine! But when it comes to the DRI modules, the meta-package depends on 'xlibmesa-dri'. This means that whenever I install the 'libgl1-mesa-dri' package as an alternative to 'xlibmesa-gl', I consequently have to remove the 'x-window-system-core' meta-package along with the 'xlibmesa-dri' package. But I would like to keep the meta-package. This is somehow annoying, since the 3 graphics adapters I use (ATI Radeon 9500 [R300 based], SIS 630 [embedded, Notebook] and SIS 661) only work in accelerated mode when using MESA's 'libgl1-mesa-dri' package. So this is more than an alternative for me but the only working solution ;) Please change the dependency on the dri modules to the following: xlibmesa-dri | libgl1-mesa-dri Thank you very much! Fabian Greffrath -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360614: ffmpeg: enables shared objects
package: ffmpeg severity: wishlist Hi! I want to ask you why you do not compile the ffmpeg-libraries with the '--enable-shared' configure option enabled? Shared ffmpeg libraries are needed to compile e.g. 'transcode' using libavcodec (see below) and forces users to first rebuild ffmpeg with '--enable-shared' and then build transcode. Please rebuild the ffmpeg libraries with the shared libraries enabled! (From transcode wiki: 'Very important: you _need_ both the header files _and_ libavcodec.so files. The libavcodec.a file won't do!') Thank you very much, -- Fabian Greffrath Institut für Experimentalphysik I Ruhr-Universität Bochum D-44780 Bochum Raum: NB 2/28 Tel.: +49(234)32-27691 Fax: +49(234)32-14170 Email: [EMAIL PROTECTED]
