Re: Bug#570621: Parsing output = derivative work?
2011/3/8 Mahyuddin Susanto : >> Parsing the output of a program doesn’t make a derivative work. However, >> if this parsing is vital for the operation of the application and makes >> it useless without that program, what is the difference with dynamic >> linking to a library? To a programmer, there might be one, but to a >> court, there wouldn’t be any. >> > > Thanks for CCing to debian-legal > anyway, i'm really confused for this packages, but i'm open for input > for a best solutions In general, I wouldn't consider parsing the output of another program to de a derivative work. According to the GPL FAQ [1]: "Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged). If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program. " [1] http://www.gnu.org/licenses/gpl-faq.html#MereAggregation Greetings, Miry -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTik7=pd+jz77tutb1knxfgfiwc-4gb89vjcod...@mail.gmail.com
Re: RFS: jstest-gtk
2011/2/24 Stephen Kitt : > Dear mentors and games team, > > I am looking for a sponsor for my package "jstest-gtk". > > * Package name : jstest-gtk > Version : 0.1.1~git20090722-1 > Upstream Author : Ingo Ruhnke > * URL : http://pingus.seul.org/~grumbel/jstest-gtk/ > * License : GPL-3+ > Section : utils > > It builds these binary packages: > jstest-gtk - joystick testing and configuration tool > jstest-gtk-dbg - joystick testing and configuration tool - debug > > The package has no lintian errors or warnings; it does have some info and > pedantic-level issues, the most severe of which in my mind is the lack of > descriptions in the patches (although they're all very short and > straightforward which is why I haven't fixed them before requesting a > sponsor). > > The upload would fix these bugs: 527962 > > My motivation for maintaining this package is that this is an ideal > complement to the joystick package which I already maintain: joystick > provides command-line tools to manage joysticks, including calibrating them > and remapping their axes and buttons, and jstest-gtk provides a more > user-friendly graphical interface to the same functions. > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/j/jstest-gtk > - Source repository: deb-src http://mentors.debian.net/debian unstable main > contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/j/jstest-gtk/jstest-gtk_0.1.1~git20090722-1.dsc > > The packaging is largely to be credited to Miriam Ruiz. > > I would be glad if someone uploaded this package for me. I will review and uload it :) Greetings, Miry -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=hy2vgt8j-sddpkentkxlcug0v86a+fvybw...@mail.gmail.com
Re: RFS: bygfoot (Updated package)
El día 17 de febrero de 2010 19:02, Elías Alejandro escribió: >> Also, users expect not to lose previous saved games when upgrading to >> a newer version of the game, so we should do as much as possiible to >> avoid that. It is really annoying to be playing a game and lose your >> saved data after an upgrade. Players would have the whole right to >> complain about it. I would. > > Miriam, I'm totally agree with you. Oh, I forgot to say one thing. If possible, the stored game data should be arch-independent (that means independent of the endianess and word size of the processor), so that if you take your $HOME from your PowerPC computer to your AMD64 one, or if your $HOME is shared among different computers, things still work. Greetings, Miry -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4671dd0c1002171029m1333e181q2d1c47165a55a...@mail.gmail.com
Re: RFS: bygfoot (Updated package)
2010/2/17 Paul Wise : > 2010/2/17 Elías Alejandro : >> Hi Christoph, >> >>> At least I don't consider this package as long as the preinstal >>> does a find over all home directories. Messing in user's home >>> directories isn't nice and find can take *really* *long*. >> >> I'm agree with the "isn't nice", but how can I keep the user savegames >> that belong previous to versions, or simply delete it?. Each versions >> create a hidden directory named .bygfoot in the /home for savegames, >> but each version can't load this savegames, just if this savegame >> belong to the same version. I've tried with the script preinst, keep >> the previous savegame and then the new version will create its own >> .byfoot. > > The game itself should handle this stuff at runtime, the maintainer > scripts have no business touching user's home directories. I totally support this. No packages should directly mess up with configuration stuff in user's directories when installed or uninstalled. If the format should be upgraded, it should be done by the program itself when it is executed by the user -aka. runtime- as Paul says, not in postinst/prerm/... Also, users expect not to lose previous saved games when upgrading to a newer version of the game, so we should do as much as possiible to avoid that. It is really annoying to be playing a game and lose your saved data after an upgrade. Players would have the whole right to complain about it. I would. Greetings, Miry -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4671dd0c1002170846y8435d08t53f0179783710...@mail.gmail.com
Re: RFS: pygpiv
2008/12/6 Miriam Ruiz <[EMAIL PROTECTED]>: > I had to go to http://pypi.python.org/pypi/pygpiv/1.0.0 to find out > what the package was about: Sorry, fuller description here: http://libgpiv.sourceforge.net/pygpiv.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: pygpiv
2008/12/6 Gerber van der Graaf <[EMAIL PROTECTED]>: > Dear mentors, > > I am looking for a sponsor for my package "pygpiv". > > * Package name: pygpiv > Version : 1.0.0-1 > Upstream Author : [fill in name and email of upstream] > * URL : [fill in URL of upstreams web site] > * License : [fill in] > Section : python I had to go to http://pypi.python.org/pypi/pygpiv/1.0.0 to find out what the package was about: pygpiv 1.0.0 Particle Image Velocimetry module Python module, wrapped from Libgpiv, for Particle Image Velocimetry. The module is intended for developers on the PIV technique itself and for fluid dynamics researchers and engineers who feel limited by the Gpiv GUI program and the command line programs from the Gpivtools package. So, those may write their own 'quick hacks' easely by using the Python scripting language for rapid development. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libmsn
2008/11/16 Miriam Ruiz <[EMAIL PROTECTED]>: > 2008/11/15 Pau Garcia i Quiles <[EMAIL PROTECTED]>: > >> It builds these binary packages: >> libmsn - high-level C++ library for MSN Messenger [runtime] >> libmsn-dbg - high-level C++ library for MSN Messenger [debug] >> libmsn-dev - high-level C++ library for MSN Messenger [devel] > > Some quick comments: > > You shouldn't call your runtime library just libmsn, see [1]. You > definitely shouldn't get rid of that lintian's message with an > override. > > The package is GPL without any special clauses and links against > OpenSSL. OpenSSL license is not compatible with GPL AFAIK > > [1] http://www.debian.org/doc/debian-policy/ Sorry, I meant [1] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html BTW, it's not a big issue, but I find it cleaner when I have to repackage a bzip2 tarball to gzip to do: bunzip2 program.tar.bz2 gzip program.tar instead of unpackaging it complely and repackaging it again. Thus at least the MD5 of the tar is maintained. It is not really important anyway, but I like it more, easier to compare :) Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libmsn
2008/11/15 Pau Garcia i Quiles <[EMAIL PROTECTED]>: > It builds these binary packages: > libmsn - high-level C++ library for MSN Messenger [runtime] > libmsn-dbg - high-level C++ library for MSN Messenger [debug] > libmsn-dev - high-level C++ library for MSN Messenger [devel] Some quick comments: You shouldn't call your runtime library just libmsn, see [1]. You definitely shouldn't get rid of that lintian's message with an override. The package is GPL without any special clauses and links against OpenSSL. OpenSSL license is not compatible with GPL AFAIK [1] http://www.debian.org/doc/debian-policy/ Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: GNU FreeDink
2008/8/27 Sylvain Beucler <[EMAIL PROTECTED]>: > I'll create the watch file (and the proper changelog entry) along with > the first non-snapshot release :) > > If there nothing else to fix at first glance, I'll roll out the > upstream release within the next few days. Thanks, if I find something else I'll tell you :) I really encourage you to join the Debian Games Team [1] and co-maintain it there. It is really much simpler to maintain a game package in a team due to economy of scale, as there are more maintainers helping and many of the issues a game might have are shared with other game packages. [1] http://wiki.debian.org/Games/Team > Is it possible to upload new packages to Debian at this point? Since > it's freeze time, does they go to experimental? Yes, it is possible to upload them, but they won't get into Lenny. They will stay in unstable until Lenny is released, and after that they will automatically move into testing. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: GNU FreeDink
2008/8/27 Sylvain Beucler <[EMAIL PROTECTED]>: > Hi Miry, > > You may want to check the latest snapshot at: > http://www.freedink.org/snapshots/freedink-1.08.20080826.tar.gz > http://www.freedink.org/snapshots/debian/freedink_1.08.20080826-1.dsc > > I recently got help with x86_64 and the game was reported to run fine > :) Hi Sylvain :) It compiles perfectly for me now, a couple of things anyway: 1) debian/watch has no uncommented lines 2) debian/changelog is signed by root <[EMAIL PROTECTED]> Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advice
2008/8/25 Serafeim Zanikolas <[EMAIL PROTECTED]>: > There _is_ actually a mentoring program by the debian women project. I don't > see why they wouldn't accept a male mentee. In fact, there are thoughts of > expanding it outside d-women, according to the web page. > > http://women.debian.org/mentoring/ I would volunteer myself to mentor someone who would really like to learn about Debian management, as long as: 1) My time is quite limited, so the person should need to be proactive and willing to do some work on their own. I could help in directing them but I could not do all the work for them. 2) I'm very involved in packaging games, C/C++ stuff and Python. I wouldn't be a good mentor for someone wanted to maintain web applications, Java stuff, fonts or things like that. 3) I would prefer to mentor other girls, as one of my goals would be to be able to increase the number of women in Debian, but I wouldn't object mentoring guys. That would be OK too. 4) As Spanish is my native tongue, it wouldn't be a problem to help other Spanish speakers who could be not so fluent in English, as long as they took into account that to really get involved in Debian development they should get proficient in this language. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: GNU FreeDink
2008/8/23 Sylvain Beucler <[EMAIL PROTECTED]>: > Hi, > > I uploaded a new version: > > * separate debian/ to the diff.gz > > * fix 'dfarc' build under amd64 > > * trim debhelper commented functions that do belong to the package > type > > * various fixes / doc clean-up > > Please let me know if there is any issue. I'll have a look at it. :) Thanks, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: GNU FreeDink
2008/8/20 Sylvain Beucler <[EMAIL PROTECTED]>: >> 1) Some of the tarballs include debian/ and their diffs are empty. In >> my opinion upstream tarballs should not include the debian/ directory. > > I thought about it, and I concluded when the maintainer is part of the > upstream team (or in this case, _is_ upstream), it makes things easier > to keep 'debian/' upstream too. > > I saw suggestions to place 'debian/' separately, but they usually > lacked elaboration, so I couldn't tell whether that applied to > freedink. On the contrary I saw discussion about a packager having > commit access to maintain upstream's debian/ and that was considered > good. > > So far it seems better for me not to separate 'debian/' :) There are a few reasons I can think if right now: 1) Debian is not the only distribution that uses debian/ for the package sources, all its derivatives do. By shipping debian/ in the orig tarball you're making it harder for them to customize the packaging, and harder to read their diff files 2) Modifications in the packaging will likely force you to make you a new release of the program. It can be quite annoying and inconvenient for non-debian based distros. 3) In case someone has to NMU one of your packages, it'll be harder, the diff file would be more cryptic. In fact, even though you can modify and add new files to debian/, as wierd as it might read in the diff, you cannot delete any of them It's perfectly valid for upstream to have their debian/ directory in their own versioning system, but when generating the release tarball it's much better to remove it from there and have it included in the diff. That's what the diff is for, in any case. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: GNU FreeDink
My first thoughts on the packages: 1) Some of the tarballs include debian/ and their diffs are empty. In my opinion upstream tarballs should not include the debian/ directory. 2) pdebuild on dfarc-2.99.20080819 fails (amd64): x86_64-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I/tmp/buildd/dfarc-2.99.20080819/src -I.. -DEXEEXT=\"\" -I/usr/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -g -O2 -MT DFArcFrame.o -MD -MP -MF .deps/DFArcFrame.Tpo -c -o DFArcFrame.o /tmp/buildd/dfarc-2.99.20080819/src/DFArcFrame.cpp /tmp/buildd/dfarc-2.99.20080819/src/DFArcFrame.cpp: In member function 'void DFArcFrame::SelectDModFromListBox()': /tmp/buildd/dfarc-2.99.20080819/src/DFArcFrame.cpp:227: error: cast from 'wxClientData*' to 'int' loses precision /tmp/buildd/dfarc-2.99.20080819/src/DFArcFrame.cpp: In member function 'void DFArcFrame::RestoreListBoxFromConfig()': /tmp/buildd/dfarc-2.99.20080819/src/DFArcFrame.cpp:555: error: cast from 'wxClientData*' to 'int' loses precision make[4]: *** [DFArcFrame.o] Error 1 3) usually it's recommended to remove the commented lines in debian/rules which are not relevant to the kind of package That's all for the moment. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: GNU FreeDink
2008/8/19 Sylvain Beucler <[EMAIL PROTECTED]>: > Hi mentors, > > I am looking for a sponsor for my package "freedink". I'll try to have a look at it if I have some time. If anyone else is able to do it before I do, please go ahead. In any case, Sylvain, are you interested in packaging this game in your own or would you consider joining the Debian Games Team and maintain it collaboratively? Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: xdigger
2008/6/11 Ansgar Burchardt <[EMAIL PROTECTED]>: > I'm looking for a sponsor for a new Debian revision of xdigger, an arcade > diamonds digging game. I've already uploaded it. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: vfu (updated package)
2008/6/1 Vincent Bernat <[EMAIL PROTECTED]>: > For some unknown reason, Miriam Ruiz uploaded your package without > telling it here. I would have suggested to add unrar-free as Recommends > or Suggests. Sorry, I was asked to sponsor the package through IRC and wasn't even aware of this thread. Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lost Labyrinth
2008/5/12 Vincent Bernat <[EMAIL PROTECTED]>: > OoO En ce début d'après-midi nuageux du lundi 12 mai 2008, vers 14:46, > je disais: > > > >> I am new to this list so I first want to say hello to everybody. > > >> Since a few days we can compile our game Lost Labyrinth with a free > compiler. > >> So the whole game is open source now. > >> It is written in purebasic which is commercial. But the new compiler > >> translates it to c++ and creates an executable. > > >> I would like to know if somebody here would like to maintain it. > >> Create a deb for it (I already have a script that creates a deb for the > >> version with the old compiler) and maintain it for debian. > > >> Maybe this would be a nice addition for the games sector of debian? It would be really nice to have it in Debian, but I wonder if it would have to go to contrib. Even though it can be exported to C++, the source code (as in "the preferred format for modification") will still be purepasic, wouldn't it? Does the generated C++ code depend on some non-free libraries? Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: teeworlds
2008/4/15, Jack Coulter <[EMAIL PROTECTED]>: > Matricks also asked me to post his remarks on the licensing situation: > > [...] Well, he seems a reasonable one in the end. I'm sorry for my hard words in my previous mails, he didn't deserve them. He seems a bit burn out, I think we could make him cheer up a bit if he sees that people actually appreciate their game and that they like playing it. I have the feeling that some developers burn out because they only get complains and negative feedback, while the big amount of people that appreciate their work is often silent. As I said, I'm really sorry for my rudeness in my previous mails, I don't think he deserved it and in fact he just got the blame for some previous fightings with other upstreams that had nothing to do with him, that same way that we seemed to get the blame for previous fighting about their license in which we were not involved. I'll try to be more careful next time. Thanks to Charles Plessy for making me rethink about it. I consider all this issue to be finished and closed on my side. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: teeworlds
2008/4/15, Charles Plessy <[EMAIL PROTECTED]>: > Le Tue, Apr 15, 2008 at 10:03:17AM +0200, Miriam Ruiz a écrit : > > > In general I try to avoid heated discussions with stubborn upstreams > > The 4th point is simply totally stupid and useless > > Some upstreams are just plainly stupid > > It's simply too childish. > > Hello Miriam, Hi :) > while I do not really disagree with your conclusions, I was just > wondering before you sent this email if the discussion got heated > because the upstream read the thread on -mentors and got upset by > persons calling his license "stupid". No, not in this case. It all seems to come from a previous discussion among some of them, some time ago [1]. I chose the words I used consciously, so I cannot excuse myself by saying it was the heat of the discussion, even more when I'm not personally involved at all in this package in any way. I'm sorry if it seemed that I was talking about this concrete upstream, I was just generalizing. In fact I was really thinking about another concrete person (upstream of a couple of games) when I used the word "stupid", who really got the nerves out of me some time ago. I wasn't talking about this concrete upstream or this concrete situation, it's not the first time I go through something like this. > Since we know that email is a communication method that is very prone to > misunderstandings, I think that we should try to play safe when > discussion about third parties on a public mailing list. To avoid misunderstandings and just in case, I'll try to clarify this: I wasn't calling stupid to anyone in particular and was just generalizing. In fact, I wasn't trying to insult upstream for this game: I don't know them, never met them, never spoke to them, so I cannot think anything of them, good or bad. As it is obvious, but wanting to make it crystal clear: my words are my personal opinion and in no way should be interpreted as representing Debian or the Debian Games Team in any way, or any other group of people apart of myself. If upstream for that game reads this and gets angry, my words are my own responsibility and it's me who they have to blame for them, and no one else. I'll try to be more politically correct with my words next time, to avoid potential problems with some upstreams. > I also wonder if IRC should be avoided for potentially difficult > interactions with upstream. Anyway, thank you Jack for having tried. Greetings, Miry [1] http://www.teeworlds.com/forum/viewtopic.php?id=957 "there have been quite a lot of nagging on the dev-team about the license. It started of back in the 0.3.x days, when the license was a bit more strict, and not to be considered "free". When they then changed the license to 0.4.x, some nagging just kept going on"
Re: RFS: teeworlds
2008/4/15, Jack Coulter <[EMAIL PROTECTED]>: > After having a heated debate with matricks and another developer void_ on > the teeworlds IRC channel, they are unwilling to change/remove point 4, but > brought up (as it has been here) that there are already packages in main > with similar clauses. In general I try to avoid heated discussions with stubborn upstreams that have no clue about licenses but won't even listen. It gets nowhere. The 4th point is simply totally stupid and useless, but I think it's no harm. Ftpmasters and most of the people in d-legal seem to consider it DFSG free, so just go ahead and package it :) > As other people mentioned here, it is *technically* DFSG compliant, and > really all this debate has just been about semantics, and I'd avoid bringing > it up again with the copyright holder (matricks) as he stated, he's spent > more time arguing license semantics than developing the game, and threatened > to close source it. Some upstreams are just plainly stupid about these kind of discussions. You simply tell them that the license has flaws and it's like you were insulting their families or something like that. "Now I get angry and I won't breath anymore". It's simply too childish. I had this kind of discussions with upstreams a couple of times and it's not worth it, if upstream just consider them so perfect that they won't even listen to your reasons, and start threatening you with stupid silly things, they won't act mature whatever you might do, so don't waste your energies there. > As it stands, I see no reason for this package not to be included in main, > referring to: > > "I still don't feel that it's DFSG-free, but if there are already > packages in the archive with similar clauses, ftpmasters will probably > consider it DFSG-free. It's OK for me, I don't consider it such a > serious issue as to arguing its inclusion in main, I was just curious > about whether it was considered free enough or not." > > and > > "Talked to Jörg Jaspert about that (you need to do something during work > time, don't you?), and this clause is indeed free (since it's so > ridiculous easy to circumvent^W fullfill). So for the sake of gaming, > bundle it with any kind of script, and be done with it." > > If there are any other issues, please email me back. Of course, as it has been mentioned, if you want to collaboratively maintain this game, you're welcome to join the Debian Games Team. Greetings, Miry
Re: RFS: teeworlds
2008/4/14, Jack Coulter <[EMAIL PROTECTED]>: > I asked around on the Teeworlds IRC channel, they pointed me to the > following thread on thier forums: > http://www.teeworlds.com/forum/viewtopic.php?id=957 > > The second post, by user matricks (matricks = copyright holder) clarifies > this: > > "We don't restrict selling it as a part of a bigger distribution like > ubuntu and stuff like that. What we are restricting is that you can't sell > just teeworlds and take money except for the media cost. This license was > discussed in great length and input were taken from some fedora legal guy > (can't remember the name). The SIL Open Font Licence contains a similar > statement and is considered to be free by the FSF guys." I don't understand the purpose of that clause then, as it can be easily circumvented (with that interpretation, it would be a matter of just adding something else to the media). I don't see the point about adding a clause that adds no protection at all. I still don't feel that it's DFSG-free, but if there are already packages in the archive with similar clauses, ftpmasters will probably consider it DFSG-free. It's OK for me, I don't consider it such a serious issue as to arguing its inclusion in main, I was just curious about whether it was considered free enough or not. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: teeworlds
2008/4/14, Jack Coulter <[EMAIL PROTECTED]>: > Dear mentors, > > I am looking for a sponsor for my package "teeworlds". > > * Package name: teeworlds > Version : 0.4.2-0 > Upstream Author : Magnus Auvinen <[EMAIL PROTECTED]> > * URL : http://www.teeworlds.com > * License : Custom free license, satisfies DFSG > Section : games The license text is: Copyright (C) 2007-2008 Magnus Auvinen This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution. 4. Neither this software nor any of its individual components, in original or modified versions, may be sold by itself. IMPORTANT NOTE! The source under src/engine/external are stripped libraries with their own licenses. Mostly BSD or zlib/libpng license but check the individual libraries. With that being said, contact us if there is anything you want to do that the license does not premit. That's the zlib license (http://www.gzip.org/zlib/zlib_license.html) with an extra clause forbidding some kind of commercial usage ("Neither this software nor any of its individual components, in original or modified versions, may be sold by itself"). I'm not really sure that it is DFSG-compliant. I'm CCing debian-legal to get other opinions on that. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mathwar -- A flash card game designed to teach maths
2008/3/13, Barry deFreese <[EMAIL PROTECTED]>: > Hi folks, > > After speaking with the maintainer I have adopted mathwar for the games > team. It's kind of more of an educational game so if you don't think it > belongs in the games team let me know and I'll adopt it myself. > > If someone has time to review and/or upload I would appreciate it. > > http://mentors.debian.net/debian/pool/main/m/mathwar/mathwar_0.2.5-1.dsc > > Description: A flash card game designed to teach maths It has nothing to do with Adobe Flash, does it? I thought that at first when I read the description. > A GTK application that teaches kids (and adults) how to > respond quickly to math problems using flash cards and timers. > It includes a Computer player, where the player gets to > decide if the Computer is right or not. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: boolstuff - library for operating on boolean expression binary trees
Hi, I am looking for a sponsor for my package "boolstuff". * Package name: boolstuff Version : 0.1.11 Upstream Author : Pierre Sarrazin <[EMAIL PROTECTED]> * URL : http://perso.b2b2c.ca/sarrazip/dev/boolstuff.html * License : GPL Programming Lang: C++ Description : library for operating on boolean expression binary trees BoolStuff is a C++ library that supports a few operations on boolean expression binary trees. The main features are: * a simple boolean expression parser (supports operators AND, OR and NOT, as well as parentheses) * an algorithm to convert a boolean expression binary tree into its Disjunctive Normal Form (this algorithm supports the NOT operator) * a function that determines if an expression tree is in DNF. It builds these binary packages: boolstuff - library for operating on boolean expression binary trees boolstuff-dev - library for operating on boolean expression binary trees libboolstuff-0.1-0 - library for operating on boolean expression binary trees The package appears to be lintian clean. The upload would fix these bugs: 44 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/boolstuff - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/boolstuff/boolstuff_0.1.11-1.dsc I would be glad if someone uploaded this package for me. It's quite an easy package: small, C++, uses autotools, no patches. I've added the flag DM-Upload-Allowed: yes to debian/control I need this library for the allowing users to set the filtering rules they want to have in GoPlay! Feedback is encouraged and welcome :) Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bulletml (updated package)
2008/1/30, Cyril Brulebois <[EMAIL PROTECTED]>: > On 30/01/2008, Luca Bruno wrote: > > As I see this is usually maintained by Miriam, and she has DM > > privilege, wouldn't be better for you both if she does the upload and > > set the DM-Allowed field? > > For this particular package, that looks like a nice idea. Yep, I agree, I'll add that tag in SVN, thanks :) Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: Thousand Parsec packages.
2008/1/30, Barry deFreese <[EMAIL PROTECTED]>: > Hi folks, > > Could someone please review my thousand parsec packages on mentors? > Upstream is begging me to get packages out there. I sent this to the > games team a while back but received no response so I'm hoping someone > on mentors will take pity on me. :-) Wow!! You've already finished them? You're great! :) Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: piklab (updated package)
I've just reloaded the package to mentors :) Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: piklab (updated package)
2008/1/26, Luca Bruno <[EMAIL PROTECTED]>: > Miriam Ruiz scrisse: > > > I am looking for a sponsor for the new version 0.15.2-1 > > of my package "piklab". > > This package is fine for me, and I will be glad to upload it. > I only noticed that in the previous version you added a > DM-Upload-Allowed field, which you now change to > XS-DM-Upload-Allowed. > But in the meanwhile, as Cyril already pointed out, dpkg was changed > to understand the original version. > > So, wouldn't be better for you to revert this field-name change? Yup, you're right here. All those changes are really confusing if you don't follow every single list in Debian for a while, I guess. I'll remove it, reupload the package to mentors and see if it works this time :) Thanks, Luca, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: piklab (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.15.2-1 of my package "piklab". It builds these binary packages: piklab - IDE for PIC-microcontroller development The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/piklab - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/piklab/piklab_0.15.2-1.dsc I would be glad if someone uploaded this package for me. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: gnash (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.8.1+cvs20080124.0900-1 of my package "gnash". It builds these binary packages: gnash - free Flash movie player gnash-common - free Flash movie player - common files/libraries gnash-cygnal - free Flash movie player - Media server gnash-tools - free Flash movie player - Command-line Tools mozilla-plugin-gnash - free Flash movie player - Plugin for Mozilla and derivatives The current package in the repositories has to be removed due to licensing problems. Gnash is GPLv3 and it links against Qt. Although newer versions of Qt are GPLv3, the one in the repositories is not ( http://packages.debian.org/changelogs/pool/main/q/qt-x11-free/qt-x11-free_3.3.7-9/libqt3-mt-dev.copyright : "You may use, distribute and copy the Qt GUI Toolkit under the terms of GNU General Public License version 2"). The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/gnash - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gnash/gnash_0.8.1+cvs20080124.0900-1.dsc I would be glad if someone uploaded this package for me. Greetings, Miry PS: I have added the label "XS-DM-Upload-Allowed: yes" to debian/control to allow Debian Maintainers uploads (that's me). If you're not comfortable with that, please ignore this sponsorship request. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unused libraries copyrigths
2008/1/21, Al Nikolov <[EMAIL PROTECTED]>: > Hello, mentors! > > In a case when upstream tarball contains some third party libraries which > are not used in favor to theirs packaged versions, what should be done? > > 1. Third party code should be stripped off from orig.tar in source package. > > or > > 2a. It still there, but nothing about it's copyright should be declared in > the copyright file. > > or > > 2b. All copyrights should be declared though the third party code is not > used in binary package (just because it is distributed in source package). 1 or 2b (never 2a), depending on the maintainer's choice. If you already have to repackage the source, or if it's too big, or you feel that for some reason it's the best option, go for 1 and get rid of that unused code. If you don't want to repackage it, or you prefer not to delete it, it must be declared in debian/copyright always, whether or not it is actually used in the binary packages. debian/copyright must contain the copyright statements for all the contents of the source package. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ubuntu-to-Debian packaging
2007/12/2, Patrick Schoenfeld <[EMAIL PROTECTED]>: > 1) Copyright / license issues: By removing important information from > the previous packaging you might insult the packaging license. > Redistribution in Debian might therefore be illegal. While I do believe that, as a general rule, it's much better to keep old changelog entries, I'm pretty sure it's not illegal at all toremove them (IANAL) as long as you keep the copyright statements. It might not be polite, but it definitely doesn't look illegal. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: pykaraoke (updated package)
2007/11/27, Piotr Ożarowski <[EMAIL PROTECTED]>: > Miriam, > > You're already in DPMT, how about joining PAPT as well and maintaining > this package there? We can offer for example: > * fixing lintian overrides > * building python extensions for all supported Python versions in > python-pykaraoke package > * handling new dpkg fields fast (some freaks have whole repository on > local machines, and they love to show others their sed skills) > (hint: Homepage field) > * fixing .desktop file (Application category issue, deprecated Encoding > field) > * merge README.txt and README.txt into README.txt (debian/docs) Great idea! I'll upload it to SVN tomorrow :) Thanks for the suggestion, I didn't even think about it :) I'll upload it to SVN tomorrow morning (CET here), and afterwards I'll prepare a newer package from there :) > bzed: too late, Miriam is mine, you need to find another girl for the > team ;-P XD Kisses, Miry
RFS: pykaraoke (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.5.1.ds1-1 of my package "pykaraoke". It builds these binary packages: pykaraoke - free CDG/MIDI/MPEG karaoke player pykaraoke-bin - free CDG/MIDI/MPEG karaoke player python-pykaraoke - free CDG/MIDI/MPEG karaoke player The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/pykaraoke - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/pykaraoke/pykaraoke_0.5.1.ds1-1.dsc Changes: * New Upstream Release. + GUI: Now works with WxPython v2.8 + GUI: Improved search results layout + CDG player: Improved handling of corrupt CDG files + CDG player: Solved minor scrolling issues * Added DM-Upload-Allowed tag to control * Removed Ana Guerrero from Uploaders * Added Homepage label to control * Updated menu: Games/Arcade -> Games/Action * Replaced deprecated ${Source-Version} by ${source:Version} in control * Added dh_desktop to rules I would be glad if someone uploaded this package for me. Greetings, Miry PS: I've added the tag "DM-Upload-Allowed: yes" to debian/control to allow future uploads of this package by Debian Maintainers (TM) - That is, me :P -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: piklab (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.15.0-1 of my package "piklab". It builds these binary packages: piklab - IDE for PIC-microcontroller development The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/piklab - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/piklab/piklab_0.15.0-1.dsc I would be glad if someone uploaded this package for me. Greetings, Miry PS: I've added a "DM-Upload-Allowed: yes" to debian/control. If you're not comfortable with uploading a package with this tag, or you don't trust me, please don't upload the package, but don't ask me to remove it either. __ Pregunta, Responde, Descubre. Comparte tus consejos y opiniones con los usuarios de Yahoo! Respuestas http://es.answers.yahoo.com/info/welcome -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: prboom (updated package)
2007/10/30, Marco Rodrigues <[EMAIL PROTECTED]>: > Dear mentors, > > I am looking for a sponsor for the new version 2:2.4.7+dfsg-1 > of my package "prboom". > > It builds these binary packages: > prboom - clone of the legendary first person shooter Doom > > The package appears to be lintian clean. > > The upload would fix these bugs: 426804, 447012 > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/p/prboom > - Source repository: deb-src http://mentors.debian.net/debian unstable main > contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/p/prboom/prboom_2.4.7+dfsg-1.dsc > > I would be glad if someone uploaded this package for me. > > Kind regards > Marco Rodrigues After all the recent discussions in the Games Team list [1] [2] [3], I'm not sure to understand this RFS. I'm not sure if Marco is aware of the mailing thread about some of his commits to SVN, or if the current uploaders for prboom are aware of this request for sponsorship, but I'm really quite lost about all this, so I felt like forwarding it to the Games Team list might clarify the situation. Miry [1] http://lists.debian.org/debian-devel-games/2007/10/msg00038.html [2] http://lists.debian.org/debian-devel-games/2007/10/msg00058.html [3] http://lists.debian.org/debian-devel-games/2007/10/msg00066.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New packaging advice, manpages and binary additions
2007/10/15, Robin Cornelius <[EMAIL PROTECTED]>: > Second issue is how do I add a binary file, eg an icon (xpm), to the > source tree?. The applicaiton is a X11 QT app and so it would be nice > to have a menu icon but upstream does not have one. Clearly the ideal > situation is to get upstream to add one but untill that happens is it > possible to just add an icon to the source tree with out > "unrepresentable changes" messages when running dpkg-buildpackage ? You can also add PNG images by converting and unconverting them to ASCII text format with SNG: - http://packages.debian.org/sng - http://sng.sourceforge.net/ "SNG (Scriptable Network Graphics) is a minilanguage designed specifically to represent the entire contents of a PNG (Portable Network Graphics) file in an editable form. Thus, SNGs representing elaborate graphics images and ancillary chunk data can be readily generated or modified using only text tools. SNG is implemented by a compiler/decompiler called sng that losslessly translates between SNG and PNG." For generic binary files, you'll probably have to uuencode them in the package source, so you can add them to the diff file, and uudecode them in your debian/rules script when creating the binary packages from it. Quite hacky, I know, but there's no nice and clean way to do it that I know of, for the moment. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Passing variables to a Makefile
2007/10/11, Charles Plessy <[EMAIL PROTECTED]>: > Dear mentors, > > in a package I prepare, there is the following line in a source/Makefile: > > CPPFLAGS=-O3 -funroll-loops -march=i686 -mfpmath=sse -msse -mmmx > > This is obviously not convenient for building on many platforms, so I > decided to override it with the following command in debian/rules: > > CPPFLAGS='$(CFLAGS)' $(MAKE) --environment-overrides --directory=source > > However, I am quite unexperienced with makefiles, and my gut feeling > tells me that I may be doing something wrong... Can somebody tell me ? It seems OK for me, I usually do it that way too. You can also alternatively override the variable sending it as a parameter for make: $(MAKE) -C source CPPFLAGS='$(CFLAGS)' But in my opinion both ways are equivalent in this case. I did not have time to have a look at the package anyway, so I haven't tested it. I'm quite too busy these days, sorry. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: opencity NMU to mentors
I would beg everyone in the thread to keep calm. There seems to have been a miscomunication among all of us, so lets let it that way and forget about it, please. It won't do any good for anyone to keep discissing this. To be honest, when I read the first mail I thought "How can this be? They're doing us an NMU for some bugs that are not extremelly urgent, they haven't even notified us about it, and they haven't sent eny patches to the BTS?". I guess that's why everyone in the mailing list was so shocked, because we (me, at least) didn't understand what was happening. In fact the letters NMU have a very clear and concise meaning, that's an upload to Debian's repositories, from a person that's not the maintainer, to solve a problem in the minimal disruptive form. The usage of the word NMU for a different thing, as in this case, seems to have confused us all. For the future, I'd prefer that whoever wants to help the Games Team send patches to the BTS. It's much easier for everyone. We're handling all the packages in a subversion server, and it's not as simple as to get the package and upload it as it is, we have to commit the changes there too. Furthermore, there might be changes already there that might not be uploaded yet, so those should also be added to the package to be uploaded. To sum up, it's quite a big amount of work for us to extract the patches from the already made packege. Now that all the situation has been clarified, lets all continue with our work :) Greetings, Miry 2007/9/13, Thanasis Kinias <[EMAIL PROTECTED]>: > scripsit Cyril Brulebois: > [...] > > The Right Thing to do is to contact the maintainers first. And it is not > > like the Games Team were totally unresponsive, especially when it comes > > to handling copyright-related problems (see Miriam's — in particular but > > not only — incredible work bugging upstreams to clarify their license / > > consider relicensing). > > > > > > is to do a non-DD NMU and let the Games Team sponsor it if they > > > > want... it seemed silly to duplicate the work. > > > > What about letting the team some time to react and fix its package? > [...] > > Hey Games Team, > > I'm sorry about the confusion here. Neil's perplexing hostility toward > me seems unfortunately to have set the tone for discussion. Let me > clarify a few things: > > 1) I'm not a DD so I can't _really_ do an NMU. I made an NMU package > for my own personal use, fixing the problems I identified. I filed > bugs, assigning severity as I understood was appropriate (and I stand by > assigning Serious severity to violating policy MUSTs). The I uploaded > my package to mentors.debian.net and sent e-mails mentioning that it was > there, and that if they wanted to the Games Team could simply sponsor > the upload -- or do whatever they wanted to with it. I specifically did > _not_ request to have anyone else sponsor the upload; that would have > been grossly inappropriate and I am displeased to think that anyone > should have thought that was my objective. > > 2) I could have posted three separate patches to the three bugs I'd > filed -- or I could just upload a package from which the maintainer > could do a quick diff and see what's there. I thought making a > ready-to-upload package available might ease the workload on the Games > Team -- but only, of course, if the Team accepted it. > > Again, I'm sorry about the confusion. I'm just trying to be helpful :) > > -- > Thanasis Kinias > Doctoral Candidate, Department of History, and > Instructor, Professional Enhancement Programs > Arizona State University, Tempe, Arizona, U.S.A. > . > Je ne viens d'aucun pays, d'aucune cité, d'aucune tribu. Je suis fils de la > route, ma patrie est caravane, et ma vie la plus inattendue des traversées. > -- Amin Maalouf, _Léon l'Africain_ > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFG6aD3Pw5095PItGURAtq5AKCHyfqfTLppKzUkGQw8YttM+a+/AwCg3F3m > 38UFLcDiXM0h+cFoAHcA7ak= > =2Bid > -END PGP SIGNATURE- > >
Re: [UPLOADED] hex-a-hop (updated package)
2007/9/11, Jens Seidel <[EMAIL PROTECTED]>: > On Tue, Sep 11, 2007 at 03:38:06PM +0200, Bas Wijnen wrote: > > I uploaded the package. I still have some comments (see below), but > > they weren't enough reason to not upload. > > Thanks. > > > On Tue, Sep 11, 2007 at 12:20:11AM +0200, Jens Seidel wrote: > > > > this is a "GPL without version" claim, which according to the GPL > > > > means any version is acceptable. I > > > > > > It's still "GPL without version". I need the permission of Miriam and > > > maybe others before I can change it. > > > > Strictly speaking, you don't. You can choose to accept any version, for > > example "all versions >= 2", like the game itself is licensed. Then you > > have the right to distribute using that license. > > > > However, I agree it is nice to ask people what they intended, and not > > remove license options without reason. > > OK, will probably do this with the next upload. Go ahead Jens, no problem at all :) The idea was mainly: "This patch is released under the same license as the game itself and the packaging", but whatever license or text you prefer will be OK for me :) You can change it yourself if you want, but if you prefer to do it formally nice, just tell me the text you prefer and I'll do the commit myself :) The idea is that not only the program itself and the packaging have a license, but also the patches do have a copyright and license. Maybe the best text would be "This patch is licensed undet the same license as the program, see debian/copyright" or something like that. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hex-a-hop (updated package)
2007/9/10, Jens Seidel <[EMAIL PROTECTED]>: > Hi Bas, > > On Mon, Sep 10, 2007 at 09:55:31AM +0200, Bas Wijnen wrote: > > I have some questions before uploading the package: > > first of all thanks for your review. > > > - You have specified "Priority: extra". According to policy, "This > > contains all packages that conflict with others with required, > > important, standard or optional priorities, or are only likely to be > > useful if you already know what they are or have specialized > > requirements." I would expect this to be optional. Is there a reason > > that it isn't? > > Oops, I didn't changed this. Sam, you are probably the one who is > responsible. Can you explain this? (Would it be OK for me to change > this (after a carefully analysis this night) or do you feel responsible > for this alone?) In fact the main responsible for the package until now was me. I convinced Sam to be added to Uploaders because, having contributed with a patch, he knew enough of the package to understand it. Go ahead and change it, no problem :) Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hex-a-hop (updated package)
2007/9/10, Bas Wijnen <[EMAIL PROTECTED]>: > Hi, > > I'm taking a look at it, and see that Sam is in the Uploaders. Should I > upload the package (if it's good), or does he normally do that? > > Thanks, > Bas Please upload it, Bas :) PS: BTW, It's better to use [EMAIL PROTECTED] instead of [EMAIL PROTECTED] for this kind of stuff, not everyone is subscribed to the latter. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: RFS: Kenta Cho's games
bulletml, mu-cade and torus-trooper have already been uploaded :) Greetings, Miry --- Miriam Ruiz <[EMAIL PROTECTED]> escribió: > Hi, > > I finally finished all of Kenta Cho's games, and it is time to find > sponsorship for them. Some of them are already in the archive, but there are > new debian releases, so those should be easier: > > http://mentors.debian.net/debian/pool/main/b/bulletml/bulletml_0.0.6-2.dsc > http://mentors.debian.net/debian/pool/main/r/rrootage/rrootage_0.23a-6.dsc > http://mentors.debian.net/debian/pool/main/a/a7xpg/a7xpg_0.11.dfsg1-2.dsc > http://mentors.debian.net/debian/pool/main/g/gunroar/gunroar_0.15.dfsg1-2.dsc > > (rrootage needs a previous upload of the newer release of the libary > bulletml) > > These other games are NEW: > > http://mentors.debian.net/debian/pool/main/m/mu-cade/mu-cade_0.11.dfsg1-1.dsc > http://mentors.debian.net/debian/pool/main/t/torus-trooper/torus-trooper_0.22.dfsg1-1.dsc > http://mentors.debian.net/debian/pool/main/t/tumiki-fighters/tumiki-fighters_0.2.dfsg1-1.dsc > http://mentors.debian.net/debian/pool/main/v/val-and-rick/val-and-rick_0.1a.dfsg1-1.dsc > > All these games are under a BSD license, are arcade games, abstract > shooters, > and if you want to know more about them, I recently wrote an entry in my > weblog about them: > > http://www.miriamruiz.es/weblog/?p=107 > > bulletml is a library coded in C++ > rrootage is a game coded in C++ > The rest are games coded in D Language. > > Greetings and thanks, > Miry > > PS: Please, to organize things a bit, if you intend to sponsor some of > these > games, it'd be better if you told in the list, so that other possible > sponsors > already know. > > PS2: Of course, as usual, feedback is welcome. There's a hard work behind > all > of these games, and they're quite severely patched, as the original ones > were > developed on Windows with a proprietary D compiler, and we have moved them > to > Linux with gdc free D Language compiler, which is already in Debian. Sé un Mejor Amante del Cine ¿Quieres saber cómo? ¡Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: Kenta Cho's games
Hi, I finally finished all of Kenta Cho's games, and it is time to find sponsorship for them. Some of them are already in the archive, but there are new debian releases, so those should be easier: http://mentors.debian.net/debian/pool/main/b/bulletml/bulletml_0.0.6-2.dsc http://mentors.debian.net/debian/pool/main/r/rrootage/rrootage_0.23a-6.dsc http://mentors.debian.net/debian/pool/main/a/a7xpg/a7xpg_0.11.dfsg1-2.dsc http://mentors.debian.net/debian/pool/main/g/gunroar/gunroar_0.15.dfsg1-2.dsc (rrootage needs a previous upload of the newer release of the libary bulletml) These other games are NEW: http://mentors.debian.net/debian/pool/main/m/mu-cade/mu-cade_0.11.dfsg1-1.dsc http://mentors.debian.net/debian/pool/main/t/torus-trooper/torus-trooper_0.22.dfsg1-1.dsc http://mentors.debian.net/debian/pool/main/t/tumiki-fighters/tumiki-fighters_0.2.dfsg1-1.dsc http://mentors.debian.net/debian/pool/main/v/val-and-rick/val-and-rick_0.1a.dfsg1-1.dsc All these games are under a BSD license, are arcade games, abstract shooters, and if you want to know more about them, I recently wrote an entry in my weblog about them: http://www.miriamruiz.es/weblog/?p=107 bulletml is a library coded in C++ rrootage is a game coded in C++ The rest are games coded in D Language. Greetings and thanks, Miry PS: Please, to organize things a bit, if you intend to sponsor some of these games, it'd be better if you told in the list, so that other possible sponsors already know. PS2: Of course, as usual, feedback is welcome. There's a hard work behind all of these games, and they're quite severely patched, as the original ones were developed on Windows with a proprietary D compiler, and we have moved them to Linux with gdc free D Language compiler, which is already in Debian. Sé un Mejor Amante del Cine ¿Quieres saber cómo? ¡Deja que otras personas te ayuden! http://advision.webevents.yahoo.com/reto/entretenimiento.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: Piklab - IDE for PIC-microcontroller development
2007/9/6, José L. Redrejo Rodríguez <[EMAIL PROTECTED]>: > > El lun, 03-09-2007 a las 11:45 +0200, Miriam Ruiz escribió: > > Piklab is an integrated development environment for applications based > > on > > Microchip PIC and dsPIC microcontrollers similar to the MPLAB > > environment. > > > > Support for several compiler and assembler toolchains is integrated. > > The > > GPSim simulator, the ICD1 programmer, the ICD2 debugger, the PICkit1 > > and > > PICkit2 programmers, the PicStart+ programmer, and most direct > > programmers > > are supported. A command-line programmer and debugger is also > > available. > > > > Piklab is an application for the KDE desktop. > > > > Homepage: http://piklab.sourceforge.net/ > > > > Packages: http://mentors.debian.net/debian/pool/main/p/piklab/ > > DSC File: > > http://mentors.debian.net/debian/pool/main/p/piklab/piklab_0.14.5-1.dsc > > > > As usual, feedback is welcome :) > > Is this package uploaded yet? > > Yes, it has been uploaded :) It is in NEW now, thanks!! Miry
RFS: Piklab - IDE for PIC-microcontroller development
Piklab is an integrated development environment for applications based on Microchip PIC and dsPIC microcontrollers similar to the MPLAB environment. Support for several compiler and assembler toolchains is integrated. The GPSim simulator, the ICD1 programmer, the ICD2 debugger, the PICkit1 and PICkit2 programmers, the PicStart+ programmer, and most direct programmers are supported. A command-line programmer and debugger is also available. Piklab is an application for the KDE desktop. Homepage: http://piklab.sourceforge.net/ Packages: http://mentors.debian.net/debian/pool/main/p/piklab/ DSC File: http://mentors.debian.net/debian/pool/main/p/piklab/piklab_0.14.5-1.dsc As usual, feedback is welcome :) Miry
Re: RFS: steam-powered
2007/9/3, Ben Finney <[EMAIL PROTECTED]>: > > "Michael Gilbert" <[EMAIL PROTECTED]> writes: > > > > The users *are* free to choose the software that's out there. The > > > Debian project is also free to refuse to choose what software it > > > distributes. > > > > the key word is "distribution." the question is whether the part of > > the software to be added to the archive is distributable. for > > steam-powered, all of the software in the package is fully GPL'd, and > > thus freely redistributable under the terms of the GPL. > > I don't think that was in question. This sub-thread is discussing > whether we *want* software in Debian whose only purpose is to sell > non-free software. I for one would prefer not to concentrate too much in adding that kind of software to Debian, and even less in trying to promote it if there's no real demand for it beforehand. Of course if someone is willing to do the job and there's demand for it and Debian in general sees it OK, it's OK for me. It would be nice to launch the flame to debian-devel in advance, just in case. Anyway, even if the Team as a group decides to invest some effort into those kind of programs, I'll concentrate myself in DFSG-free stuff and, the most, some other slightly less free, but not that much. So, my personal vote, just speaking for myself, is that I'm not willing to devote a single second of my time supporting those programs Software must be DFSG-free to be in Debian. Not all DFSG-free software > must be distributed by Debian. Agreed Miry
Re: RFS: pingus (updated package)
Hi Marco, We were planning to take care of that game in the Games Team. If you're interested in working on it collaboratively, you're welcome to join the Team. I cannot upload it for you, but I'll try to have a look at your package. Greetings, Miry PS: CCing to the Games Team mailing list 2007/8/31, Marco Rodrigues <[EMAIL PROTECTED]>: > > Dear mentors, > > I am looking for a sponsor for the new version 0.7.0-8.5 > of my package "pingus". > > It builds these binary packages: > pingus - Free Lemmings(TM) clone > pingus-data - Data files for pingus, a free Lemmings(TM) clone > > The upload would fix these bugs: 375769, 439463 > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/p/pingus > - Source repository: deb-src http://mentors.debian.net/debian unstable > main > contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/p/pingus/pingus_0.7.0-8.5.dsc > > I would be glad if someone uploaded this package for me. > > Kind regards > Marco Rodrigues
Re: signing packages from a different machine
2007/8/22, Kamaraju S Kusumanchi <[EMAIL PROTECTED]>: > > Hi > I have access to two machines - say machine A, machine B. On machine A > when I build a package, I can automatically sign the package as needed. > However now I am sitting at a friends machine (machine B) and built a > package using pdebuild. But I am not sure how to sign this package. The > errors from pdebuild are > > pbuilder-time-stamp: 1187760442 > signfile /home/raju/pbuilder/result/texmacs_1.0.6.10-2.dsc Kamaraju > Kusumanchi <[EMAIL PROTECTED]> > gpg: skipped "Kamaraju Kusumanchi <[EMAIL PROTECTED]>": secret key not > available > gpg: [stdin]: clearsign failed: secret key not available > debsign: gpg error occurred! Aborting > > What should I do? Should I copy the secret key from machine A to machine > B? > or should I copy the .dsc, .changes files from machine B to machine A and > sign there? I looked in maint-guide, developers-reference, > debian-reference > but could not find any suggestions there. I would recommend you not to copy your secret key to your friend's machine. A secret key is something to keep safe and secret. It would be much better to move the files to your machine and sign the packages there, or to carry your secret keys in a USB device, possibly encrypted just in case you lose it, and just using it in machines you can trust. Miry
Re: debian files in sourceforge cvs
2007/6/27, Pádraig Brady <[EMAIL PROTECTED]>: Justin Pryzby noted to me previously that, advantages for having debian/ in the .diff.gz rather than the orig.tar.gz are: . more conventional . not confusing other people using other distributions . allowing new Debian revisions without bumping the version for the non-Debian source" The last is the main advantage I can see. Also, allowing derivative distributions to be able to fit the packaging to their needs, even replace it. Derivative distributions also use the debian/ directory, and having to modify stuff there, especially if you need to delete files, is quite dirty with .digg.gz patches. Miry
Re: RFS+RFC: SDCC (Small Device C Compiler)
Hi :) 2007/6/27, Bas Wijnen <[EMAIL PROTECTED]>: Hi Miriam, It might take a few days before I get to it, but I'd be happy to sponsor (and co-maintain, if you want) SDCC for/with you. You're totally welcome to comaintain it! :) I'm maintaining it in subversion for the moment: http://svn.debian.org/wsvn/collab-maint/ext-maint/sdcc/ I don't mind if someone else is faster in sponsoring this time. :-) Thanks, Bas Wijnen Thanks a lot :) Miry
RFS+RFC: SDCC (Small Device C Compiler)
SDCC is a C compiler for the Intel MCS51 family, AVR, HC08, PIC and Z80 microcontrollers. http://packages.debian.org/sdcc http://sdcc.sourceforge.net/ You can get/review my packages from: http://mentors.debian.net/debian/pool/main/s/sdcc/ or dget http://mentors.debian.net/debian/pool/main/s/sdcc/sdcc_2.7.0-1.dsc Greetings and thanks, Miry
RFS: Frets on Fire
After some months of working, we've finally been able to finish a DFSG-free version of the game Frets on Fire, as well as some free songs to play the game. The packages can be obtained from http://mjj29.matthew.ath.cx/debian-upload/fretsonfire/ , or via the Debian Games Team subversion server ( http://wiki.debian.org/Games/SVN ). Frets on Fire ( http://fretsonfire.sourceforge.net/ ) is a game of musical skill and fast fingers. The aim of the game is to play guitar with the keyboard as accurately as possible. Anyone available to have a look at the packages and sponsor them? The game is coded in python and is released (as well as the data) under the GPL license. When you rebuild the packages, please make sure you do with -v0. Greetings and thanks, Miry Any questions or feedback is welcome :)
Re: build two binary packages with different configure parameters
I had to do something like that for ultrastar-ng. I created two different directories, called configure from inside each of them with the proper different parameters and had to duplicate the make and make install. Dunno if it's not elegan enough, but I didn't want to make it too complex. You might want to have a look at it. There's nothing special in it anyway. Greetings, Miry
Re: RFS: Ultrastar NG
--- Niv Sardi <[EMAIL PROTECTED]> escribió: > Hi ! > > I'm interested in getting UltraStar into Debian, and if you like I can > sponsor your uploads (after I take the time to review it more deeply). Thanks! This version of the package has already been uploaded, and is waiting in the NEW queue, but may I count on you for later uploads? :) > A few comments as you requested =) Thanks! > - this is personal, but I'd rather have -flavour rules, I feel it'd make > it easier to maintain, given your current debian/rules it'd just be > adding rule-flavour: before the flavour blocks. > > i.e. having a config-gst: and a config-xine: rule. Hmmm.. yup, it makes sense, I'll try to change the building system to handle that, it should be quite straight forward :) > - personal too: Wouldn't ultrastarng-flavour package naming make more > sense ? especially as it's the name of the binary ? I was in doubt about that. The binary is called ultrastarng, but the project in sourceforge is called ultrastar-ng. I finally thought that ultrastar-ng would fit better, because it would make clear that ultrastar and ng are different words. Otherwise it's quite a confusing name. > - You should state the licence of the added xpm too in the copyright > file. Did you design them yourself ? Yup, I did it myself, based on the graphics included in the themes (which are GPL'ed). It is, of course, GPL'ed as the rest of the packaging-related files :) > A part for those few points that are rather personal, the package seems > to be in a good shape. > > Except that this software seems to be saying that I'm totally out of the > key, witch is obviously an RC bug ! Heh, but is it that a bug in the program or in the user? :P ;) Greetings, Miry LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: Ultrastar NG
Karaoke program under the GPL which is based off and looks similar to Singstar for PS2. UltraStar-NG [1] is based on UltraStar and allows you to add your own songs in the forms of mp3s along with a song text and a music video file. The packaging is being done the Debian Games Team SVN server [2]. Right now I'm creating 2 binary packages, one compiled against libxine and the other one against gstreamer. There's a default void package depending on the libxine version, as it is the one I'll be using by default (so that newbies have it easier to choose). There's a song available for testing in the Windows version (written in Delphi) [3]. I've put it temporarily available [4] but I guess it cannot be considerede DFSG-free in any way. There are songs for UltraStar available everywhere anyway. You can get the packages from here: http://mentors.debian.net/debian/pool/main/u/ultrastar-ng http://mentors.debian.net/debian/pool/main/u/ultrastar-ng/ultrastar-ng_0.1.3-1.dsc Comments and feedback, as always, are also welcome :) [1] http://sourceforge.net/projects/ultrastar-ng/ [2] http://wiki.debian.org/Games/SVN [3] http://sourceforge.net/projects/ultrastar/ [4] http://users.alioth.debian.org/~baby-guest/ultrastar-ng/songs.tgz __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please, review and enhance "How to split a package into several smaller packages"
Hi, I made a small example about multiple binaries a couple of days ago, as I wanted to write something about that in my weblog. It is quite a common scenario when packaging games. In any case you can have a look at it if you want, even though I should still have to add some comments I guess: http://miriamruiz.es/code/hello_0.1-1.dsc http://miriamruiz.es/code/hello_0.1-1.diff.gz http://miriamruiz.es/code/hello_0.1.orig.tar.gz Feedback is welcome if there's something that could be done in an easier way :) Greetings, Miry
Re: staying in stable but compiling for sid
2007/4/13, Steve Kemp <[EMAIL PROTECTED]>: You have several choices here: * Use pbuilder to setup a build environment. "heavyweight" but simple. * Use chroots for building. simple and well understood. These two choices suffer in that you can't get a graphical environment within them. So if you build a package for sid which used Xorg you couldn't test it. That's not exactly sure. You'll have a bit overhead but you can start X from a chroot. If you want, you can have a look at this: http://www.miriamruiz.es/code/create_chroot_system.sh Sorry, the explanation I did it in Spanish ( http://www.miriamruiz.es/weblog/?p=23 ) , but it's quite easy looking at the script. Greetings, Miry
Freeness of a license - french
Hi, Can anyone tell me if the "Art Libre" license ( http://moleinvasion.tuxfamily.org/download/snd/LICENSE.txt ) might be considered DFSG-free? It's written in french, and although I can more or less understand a part of it, I'm incapable of be sure whether it might be DFSG-free or not. Lots of thanks, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: pykaraoke
Pykaraoke is already in the repositories, but as a new version has come out with lots of improvements. PyKaraoke is a free karaoke player. You can use this program to play your collection of CDG, MIDI and MPEG karaoke songs. There is also a frontend for the pycdg and pympg karaoke players. It provides a search engine to find your songs, a file/folder browser to pick songs from disk, as well as a playlist. Homepage: http://www.kibosh.org/pykaraoke/ The game is coded in python, and the packages are available at: http://mentors.debian.net/debian/pool/main/p/pykaraoke/ For dget: http://mentors.debian.net/debian/pool/main/p/pykaraoke/pykaraoke_0.5-1.dsc Comments and suggestions are also welcome. Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnash: /usr/lib/libXcursor.la does not exist
Hi, It seems to be enough just with rebuilding gtkglext debian package. A binNMU has been scheduled so it will probably be solved soon. Thanks :) Miry --- Brendon Higgins <[EMAIL PROTECTED]> escribió: > Hi > > Loïc Minier wrote (Sunday 07 May 2006 6:48 am): > > On Sat, May 06, 2006, Miriam Ruiz wrote: > > > /bin/sed: can't read /usr/lib/libXcursor.la: No such file or directory > > > libtool: link: `/usr/lib/libXcursor.la' is not a valid libtool archive > > > > grep -l Xcursor.la /usr/lib/*.la > > will list the libtool archives which still reference this file, the > > packages shipping these files should be updated not to reference > > Xcursor.la (rebuilt). > > There is a hack floating around that basically involves taking a meat > cleaver > to all the files that reference Xcursor.la and others that have gone along > with it which no longer exist. > > I'm trying to find the line I saw a while ago, but Google is failing me. The > > idea is you grep for all the la files that reference libXcursor.la, and just > > remove that reference from them. It's a pretty nasty hack, but it can be > done, and it seems to work. Best you don't take my word for it until you > find > a confirmation of this idea, though. > > Relevent discussion here (plus many others in debian-x): > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354674 > > Peace, > Brendon > __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gnash: /usr/lib/libXcursor.la does not exist
Hi, I'm getting some errors building gnash when reaching the linking step: ranlib .libs/libgnashbackend.a creating libgnashbackend.la /bin/sed: can't read /usr/lib/libXcursor.la: No such file or directory libtool: link: `/usr/lib/libXcursor.la' is not a valid libtool archive Talking to upstream, they told me they're not linking directly with X in any step, so the problem must be somewhere in Debian. The package is available temporarily at http://baby.yi.org/packages/gnash/ and the full building log is: http://baby.yi.org/packages/gnash/gnash_0.0.20060506-1_i386.build It seems ( http://bugs.debian.org/347352 ) that it's not just me who is getting this error. Do you know if it's something in my package, in the building system or I shall just wait for whatever bug in Debian (due to the latest xorg transition) to be fixed? Greetings, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: gnash (FSF Free Flash Player)
--- Paul Wise <[EMAIL PROTECTED]> escribió: > Some comments: Thanks a lot for your comments on the package, they have been really useful!! > * debian/control: gnash is not binNMUable due to libgnash-dev > strictly depending on libgnash0 (= ${Source-Version}). What should I do in this case? just depend on libgnash0 without the version? wasn't they going to solve this problem in some way? > * debian/control: about mozilla-dev, generally, xulrunner is being > moved to these days, is that something that is possible for the > plugin? I'd love to be able to try this in galeon/epiphany. I haven't ever had a look at xulrunner but it seems to be interesting. The plugin should be compatible with any browser that supports mozilla plugins I guess. Is there a standard way to handle that? > * debian/rules: might want to use a more standard patch system > than something homegrown. I'd suggest quilt or dpatch. The patch > target doesn't seem to be used or do anything. I'm using that just because as I'm depending on CVS version it's much easier to be using patches, but I plan to remove that when a release version appears, so I don't wanna complicate it much. I've fixed a lot of things, I guess the packages are almost finished for now. I just have to know what to do with a lintian warning: W: klash: binary-or-shlib-defines-rpath ./usr/lib/kde3/libklashpart.so /usr/lib:/usr/share/qt3/lib N: N: The binary or shared library defines the `RPATH'. Usually this is a N: bad thing. Most likely you will find a Makefile with a line like: N: gcc test.o -o test -Wl,--rpath N: or N: gcc test.o -o test -R/usr/local/lib N: Please contact debian-devel@lists.debian.org if you have questions N: about this. N: ./usr/lib/kde3/libklashpart.so is a plugin for konqueror, an it seems to depend on the libraries at /usr/share/qt3/lib. As this is the first konqueror plugin I package, I don't know if it's something usual or not. Does somebody out there have a hint? Greetings and lots of thanks, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Question about debian/copyright
Hi, I have a doubt related to debian/copyright. In policy it is said that "Every package must be accompanied by a verbatim copy of its copyright and distribution license in the file /usr/share/doc/package/copyright.". I've always interpreted this in the sense that every binary package must be accompanied of the verbatim copy of copyright and distribution licenses of the contents packaged in it. Now, if a source package (orig.tar.gz) contains different material with different licenses (allowing redistribution and so), but binary packages only include part of them, is it mandatory to have in debian/copyright files in the binary .deb packages the copyright and licenses of things that are are not packaged in them, but that are distributed in the source package? More concisely, is debian/copyright supposed to include the copyright and license of the contents of the binary package in which it is contained, or the source package from which it is generated? Take into account that the source package already contains the copyright notices related to the source distribution, right as upstream have included them. Greetings, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC: gnash (FSF Free Flash Player)
Hi, Gnash is a free Flash movie player, which works either standalone, or as a Firefox/Mozilla plugin. Currently It is in a very alpha state. The plugin is under heavy development at this time. Gnash supports the current Shockwave format, version 7. While all the ActionScript classes exist, not all of the methods defined by the SWF format documentation are implemented however, so not all flash movies work 100% if they utilize any of the unimplemented methods. This is one of the areas to work on to achieve full version 7 compliance. Included in the Gnash is an XML based messaging system, as specified in the Flash specification. This lets a flash movie communicate over a TCP/IP socket, and parse the incoming XML message. This lets a movie be a remote control for other devices or applications. The home page of the project lies at http://www.gnu.org/software/gnash/ Gnash is not ready for uploading to SID yet, and upstream has not made any stable release, but as there is quite a high demand for it, I'm considering putting it into experimental. I don't think the plugin is useful yet for final users, and it's probably only of interest for developers right now. Gnash is currently under heavy development. The last packages I've made are available at http://baby.yi.org/packages/gnash/ Greetings, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: swfmill
Thanks for your comments. I've got a question about one of them: > * you need to check the package with lintian/linda. I get > warnings: > > W: libswfmill0: package-name-doesnt-match-sonames libswfmillxslt0 libswft0 I have this same problem in gnash, the library files include two different libraries, but i just don't want to name it after only one of them, as it would be quite an obscure thing to do. Do I need to create two lib...0 and two lib...-dev files? I think that would be an overkill. What's the standard way of solving this? Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC: swfmill
swfmill is an xml2swf and swf2xml processor with import functionalities License: GNU GPL Homepage: http://iterative.org/swfmill/ It's most common use is the generation of asset libraries containing images (PNG and JPEG), fonts (TTF) or other SWF movies for use with MTASC-compiled ActionScript, although swfmill can be used to produce both simple and complex SWF structures. Features: * Built around an XSLT/EXSLT processor (libxslt) * Input and output of the XSLT transformation can be either XML or binary SWF * XSLT commands for importing PNG, JPEG, TTF and SWF, and for mapping SWF ID numbers * Built-in "simple dialect" to support library creation and building simple SWFs My packages are available at http://baby.yi.org/packages/swfmill/ (lets hope my home server stays up for some time, I'm still having small problems with the connection) Thanks, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: question about CFLAGS modifiers to ./configure
Thanks for your help, I have the ideas quite much clearer now. It seems that libgnashserver depends on libgnashasobjs, and at the same time libgnashasobjs depends on libgnashserver too, which is something quite wierd. Is there a nice solution for this? I guess the right thing should be to tell upstream to unify the libraries into one, is there any other solution I can handle? Greetings and thanks, Miry --- "Bernhard R. Link" <[EMAIL PROTECTED]> escribió: > This looks like the prime example of a error -Wl,-z,syms is there to > catch. The library libgnashhashserver needs symbols from the library > libgnashhasobjs, but does not link against this library. > Without -Wl,-z,syms the linker supposes that this might be callbacks > to the main program, and most programs using this lib link properly > because they most likely also link against libgnashhasobjs. And if > people realize they cannot link against libgnashhashserver without that > lib they tend to not realize the error in hashserver but just adding > linkining to hashobj (which might be an additional error, as linking > against libs you do not need directly is an error, but in the common > cases both errors do not show up and it just works so people do not > suspect any bad). > > To fix this try to add something like (untested): > > libgnashhashserver_la_LIBADD = libgnashhashobjs.la __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: question about CFLAGS modifiers to ./configure
It seems that the linker options: "-Wl,-z,defs" are neccesary (for policy), but if you don't add this linker flags, it compiles and builds without problems. With them, it's hell. I've managed to compile libbase and libgeometry adding AM_LDFLAGS to Makefile.am: libbase/Makefile.am: AM_LDFLAGS = $(OPENGL_LIBS) $(SDL_LIBS) $(LIBZ) $(JPEG_LIBS) libgeometry/Makefile.am: AM_LDFLAGS = $(OPENGL_LIBS) $(SDL_LIBS) -L../libbase -lgnashbase But I'm having serious problems with some of the other components. I'm attaching the latest snapshot of my debian directory, as well as the .build file resulting from trying to build it. I'm getting tons of undefined references, some of which I don't seem to be able to get rid of. The source is not yet available as a tgz, as it is still under development in the CVS. To get it, you need to: export CVS_RSH="ssh" cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/gnash co gnash as described in http://www.gnu.org/software/gnash/ I've emailed upstream about it. Greetings, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com debian.tar.bz2 Description: pat1628936378 gnash_0.0.20060328-1_i386.build.bz2 Description: 2767681692-gnash_0.0.20060328-1_i386.build.bz2
Re: question about CFLAGS modifiers to ./configure
--- Steve Langasek <[EMAIL PROTECTED]> escribió: > On Fri, Mar 31, 2006 at 08:41:22AM +0200, Miriam Ruiz wrote: > > > --- Steve Langasek <[EMAIL PROTECTED]> escribió: > > > > This is discussed in policy 10.2. If your libraries are failing to link > > > when using -z,defs, that's a bug in those libraries; anything that > > > references symbols from other libraries on the system needs to link > against > > > those libraries. > > > Thanks, I have no clue why the linker gives errors then. I'll send the > > reference to this conversation to upstream as I'm not sure to be able to > fix > > that myself properly. > > It might be helpful to you (and others) if you posted the full error > messages here as well, and provided a link to a source package. Odds are > good that your upstream won't understand the error message any better than > you do. :) My home connection is down so I can only read and write mail from work. My home server obviously is offline so I don't have it easy to put my packages available. The program is gnash ( http://bugs.debian.org/347352 ) and the problem is that, when linking the libraries, it gives unresolved symbols. I've managed to compile libbase and libgeometry adding AM_LDFLAGS to Makefile.am: libbase/Makefile.am: AM_LDFLAGS = $(OPENGL_LIBS) $(SDL_LIBS) $(LIBZ) $(JPEG_LIBS) libgeometry/Makefile.am: AM_LDFLAGS = $(OPENGL_LIBS) $(SDL_LIBS) -L../libbase -lgnashbase But I'm having serious problems with some of the other components. I can post the full error message if you might think it's interesting. I can also send my latest version of the debian/ directory to the bug report. I hope to have my home connection fixed soon (it's been about 3 weeks and 5 different technicians coming home to see it since it doesn't work). Any suggestion on how to make my packages available with only web access? Greetings and thanks, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: question about CFLAGS modifiers to ./configure
--- Steve Langasek <[EMAIL PROTECTED]> escribió: > This is discussed in policy 10.2. If your libraries are failing to link > when using -z,defs, that's a bug in those libraries; anything that > references symbols from other libraries on the system needs to link against > those libraries. Thanks, I have no clue why the linker gives errors then. I'll send the reference to this conversation to upstream as I'm not sure to be able to fix that myself properly. Greetings, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
question about CFLAGS modifiers to ./configure
Hi, DebHelper uses by default (in the pre-made templates) "-Wl,-z,defs" in CFLAGS when running ./configure CFLAGS="-Wall -g -O2 -Wl,-z,defs" ./configure --host=$(DEB_HOST_GNU_TYPE) ... I'm packaging a program (with some libraries in it) that won't compile with them unless you explicitly modify Makefile.am files and add the libraries (already included in the package but not installed in time of compilation), which is not done by default. without those options it compiles and install cleanly without problem with upstream's building system. Is it important to keep them? Could someone possibly explain to me what they mean? Lots of thanks!!! Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW queue
Not exactly, AFAIK: http://theory.uwinnipeg.ca/localfiles/infofiles/make/make_33.html A phony target is one that is not really the name of a file. It is just a name for some commands to be executed when you make an explicit request. There are two reasons to use a phony target: to avoid a conflict with a file of the same name, and to improve performance. The phony target will cease to work if anything ever does create a file named `clean' in this directory. Since it has no dependencies, the file `clean' would inevitably be considered up to date, and its commands would not be executed. To avoid this problem, you can explicitly declare the target to be phony, using the special target .PHONY Greetings, Miry --- Kai Hendry <[EMAIL PROTECTED]> escribió: > On 2006-03-08T09:00+0100 Miriam Ruiz wrote: > > Is it my imagination or binary-arch doesn't exist either? > > Isn't that what .PHONY is for? > > sam$ egrep PHONY webpy-0.135/debian/rules > .PHONY: build clean binary-indep binary-arch binary install configure > > Best wishes, > __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW queue
--- Kai Hendry <[EMAIL PROTECTED]> escribió: > > http://hendry.iki.fi/debian/unstable/webpy_0.135-1.diff.gz > > doesn't have a required 'build' target, which IMO is sufficient reason > > to reject the upload. > > What should it be? 386? I think it refers to this: http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules debian/rules is a makefile script with different rules that must do different things. For what I've read in the mail, it seems that the "build:" target is missing. The build target should perform all the configuration and compilation of the package. debian/rules in your diff only have the following targets for what I can see: clean, install, binary-indep, binary Is it my imagination or binary-arch doesn't exist either? Greetings, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC/RFS: bcpp - C(++) beautifier
--- Alexander Schmehl <[EMAIL PROTECTED]> escribió: > Two (minor) remarks: > - debian/compat: should be set to 5 > - debian/control: You could add the Upstream Homepage (as described in > the developers reference [1]) > > Package is on it's way. Nice tool, would welcome further uploads. Thanks!!! I'll have a look at those :) Is it worth mentioning the home page in the description, even when that home page has not extra relevant information apart from the program itself? (Another question related to this, but for another package. If the home page is in chinese/japanese or whatever, should I put it in the description too? In that case, should I put also a note saying that it's not in english?) Greetings, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC/RFS: bcpp - C(++) beautifier
bcpp indents C/C++ source programs, replacing tabs with spaces or the reverse. Unlike indent, it does (by design) not attempt to wrap long statements. This version improves the parsing algorithm by marking the state of all characters, recognizes a wider range of indention structures, and implements a simple algorithm for indenting embedded SQL. License: BSD Homepage: http://www.invisible-island.net/bcpp/ Packages: http://baby.yi.org/packages/bcpp/ Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC/RFS: ...
--- "Thaddeus H. Black" <[EMAIL PROTECTED]> escribió: > If a package's name and description are so crude that > decent people avoid naming the package or talking about > it, then I ask that you let the package die. Please do > not package such software for Debian. If a package is useful, then why not changing the name and the description if it is so offensive? Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Linking file types and apps
Hi, I want to make a package update my system so that it creates an association between a file with a certain extension, and a program. It seems that I need to write some .desktop file and update the mime types, but I haven't been able to find some documentation or explanation so clear that allows me to make it. I've been trying to copy what some other packages do, without success. Can you point me to somewhere to be able to learn that, or give some hints on how to do it, please? Greetings and thanks, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC/RFS: PyKaraoke
Joe Wreschnig wrote: > The pyc files are generated in the postinst, you won't see them in dpkg > -L/-c output. So, if you upgrade to a newer version of python, it won't work, as the compiled files would not be regenerated. is that it? I guess I understand why it cannot be run with python2.4 then. I hope someone finds a better solution anyway :) > There's one problem left with the most recent package, it has the proper > license, but still lacks the copyright notice. Done. Sorry. Same URL: http://baby.yi.org/packages/pykaraoke/ :) Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC/RFS: PyKaraoke
--- Joe Wreschnig <[EMAIL PROTECTED]> escribió: > > Why can't it be used with python 2.4? > > The modules are byte-compiled for Python 2.3, and should be recompiled > when Debian ships Python 2.4 as the default. There's no way to > automatically do that yet, so instead dh_python sets it up so that a > simple rebuild will cause it to upgrade properly. It's messy, and should > be done more automatically, but isn't yet. I guess you're talking about the future, as I don't see any .pyc file in the package, even using dh_python and so. Anyway I guess it'll help maintaining the compatibility in the future for what I understood. Right now the only change I noticed in the package is that one I mentioned about the dependencies. Thanks :) Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC/RFS: PyKaraoke
Done, new packages are (again) at: http://baby.yi.org/packages/pykaraoke/ Thanks :) Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC/RFS: PyKaraoke
--- Miriam Ruiz <[EMAIL PROTECTED]> escribió: > > --- Joe Wreschnig <[EMAIL PROTECTED]> escribió: > > > Some issues: > > > > Your debian/control should not depend directly on "python", but use > > "${python:Depends}" and call dh_python in its binary-indep target. You > > also need to Build-Depend on Python. > > I did that in one of my packages, which I co-maintain, that is written in > python, and it was converted to something similar to what i did this time. > Which is the best approach and why? I've tried that, and it adds the dependencies: python (>= 2.3), python (<< 2.4) Why can't it be used with python 2.4? Greetings, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC/RFS: PyKaraoke
--- Joe Wreschnig <[EMAIL PROTECTED]> escribió: > Some issues: > > Your debian/control should not depend directly on "python", but use > "${python:Depends}" and call dh_python in its binary-indep target. You > also need to Build-Depend on Python. I did that in one of my packages, which I co-maintain, that is written in python, and it was converted to something similar to what i did this time. Which is the best approach and why? > You patch the upstream source in a number of places. The reasons seem > good, but you also moved the cdgBorderPreset function which makes the > diff unnecessarily hard to check. Also, > "self.FileName[len(self.FileName)-1]" is much clearer as just > "self.FileName[-1]". If you haven't sent the changes upstream, you > probably should. To be honest, I reported some bugs after trying the package to upstream and it was him who sent me the patches. > debian/copyright lists the authors and the license, but does not have a > proper copyright notice. Looking at the source, it seems to be > "Copyright (C) 2005 Kelvin Lawson ([EMAIL PROTECTED])". The > source also specifies LGPL 2.1, but debian/copyright says LGPL 2. Thanks, I'll fix that :) I should have checked it, it was the default template created with dh_make --copyright lgpl slightly changed. > Once these are fixed, I would be happy to sponsor this. Thanks, I'll email you when it's ready :) > Just a warning (for you and upstream, if you didn't know) -- Pygame's > MPEG support, and pygame.mixer.music in general, are both very flakey. I didn't know. Anyway I guess it will improve :) I didn't have any problems playing my karaoke files back anyway. Greetings, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC/RFS: PyKaraoke
PyKaraoke is a free karaoke player. You can use this program to play your collection of CDG, MIDI and MPEG karaoke songs. This package includes the command-line programs to play CDG files, MIDI/KAR files and MPEG files. Features: * CDG (MP3+G, OGG+G) playback - Play standard CDG karaoke files * MIDI (.MID/.KAR) playback - Play MIDI format karaoke files * MPEG playback - Play karaoke songs and movies in MPEG format MIDI/KAR support on Linux, requires the following: * Timidity++ * Sounds/patches for Timidity++ (e.g. freepats or eawpatches) Homepage: http://www.kibosh.org/pykaraoke/ My packages are available at http://baby.yi.org/packages/pykaraoke/ Greetings, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: RFC: PyKaraoke
--- Miriam Ruiz <[EMAIL PROTECTED]> wrote: > Only the frontend seems to be using libwxgtk-python, so I'm planning to > separate it into two different binary packages, one with the command line > programs (and less dependencies, no wx) and another one, depending on it, > with > the frontend. I've split the package into two, as I said. I have a problem with lintian anyway, the manpage for all the programs is the same, with links. Thus, the gui program does not include its own manpage, as it is included in the command-line package, which is required. Lintian gives a warning anyway. May I override it? Greetings, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC: PyKaraoke
PyKaraoke is a free karaoke player written in Python. You can use it to play your collection of CDG, MIDI and MPEG karaoke songs. Upstream homepage is at http://www.kibosh.org/pykaraoke/ PyKaraoke is actually a GUI frontend which controls three libraries, pycdg for CDG files, pykar for MIDI/KAR files and pympg for MPEG files. If you do not wish to use the GUI you can actually start a player directly from the command-line (or by associating file-types in your operating system). Prerequisites for using the program are: python python-pygame libwxgtk-python python-numeric Only the frontend seems to be using libwxgtk-python, so I'm planning to separate it into two different binary packages, one with the command line programs (and less dependencies, no wx) and another one, depending on it, with the frontend. My current packages are at http://baby.yi.org/packages/pykaraoke/ . I guess the links to the program should go to /usr/games instead of /usr/bin, and I'm not sure whether /usr/lib/python is the best place to put the program files, as probably /usr/share/python would fit best, but upstream choose to put them there. Maybe I should ask him about it. I'd be glad to receive comments about the package or about the doubts I have commented. Lots of thanks, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: treeline and treeline-i18n
I've repackaged TreeLine in only one orig files (that includes upstream tarballs inside). The new files can be found, again, at: http://baby.yi.org/packages/treeline/ BTW, Does anyone has a clue about which programs are used to translate .ts / .qm files? Greetings, Miry --- Miriam Ruiz <[EMAIL PROTECTED]> escribió: > Hi Dato :) > > --- Adeodato Simó <[EMAIL PROTECTED]> escribió: > > > * Miriam Ruiz [Thu, 02 Feb 2006 09:31:22 +0100]: > > > > Hi, > > > > > My packages can temporarily be found at: > > http://baby.yi.org/packages/treeline/ > > > > The packages look good. I can upload them, these are my only concerns: > > Thanks :) > > > (1) As per upstream's require.html, the spell checker is not an > > absolute dependency, and aspell is normally preferred. What about > > this?: > > > > -Depends: python, python-qt3, ispell, ${misc:Depends} > > +Depends: python, python-qt3, ${misc:Depends} > > +Recommends: aspell | ispell > > Yes you're right. That may be more sensible. I've updated it. > > > (2) [minor suggestion, I don't mind leaving it as is] I'd personally > > leave the end of this sentence out of the Debian description. > > > > TreeLine is written in Python and uses the PyQt bindings to the Qt > > - toolkit, which makes it very portable. > > + toolkit. > > I don't really mind too much, I've corrected it as it might be redundant for > the description. It might be of interest to users knowing that they can be > able to take their data files (xml) to many systems, but the last words > probably are redundant with the rest of the sentence. > > > (3) > > > > > Package: treeline-i18n > > > Description: translation files for treeline data manager > > > > Despite upstream shipping these two in separate tarballs, two separate > > binaries _and_ source seems an overkill to me. Perhaps other -mentors > > readers will disagree, but I'd look into shipping the translations in > > the treeline package itself (most packages do ship translations > > themselves, don't they?). This would mean repackaging, though. > > I found it overkill too, I was just not sure whether to repackage it (maybe > putting original .tgz files inside a .orig.tar.gz?) or to leave them as they > are. Do you think it might be better to repackage them? If I repackaged the > original tarballs, would it be better to have just one binary? > > > Cheers, > > Greetings, > Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: treeline and treeline-i18n
Hi Dato :) --- Adeodato Simó <[EMAIL PROTECTED]> escribió: > * Miriam Ruiz [Thu, 02 Feb 2006 09:31:22 +0100]: > > Hi, > > > My packages can temporarily be found at: > http://baby.yi.org/packages/treeline/ > > The packages look good. I can upload them, these are my only concerns: Thanks :) > (1) As per upstream's require.html, the spell checker is not an > absolute dependency, and aspell is normally preferred. What about > this?: > > -Depends: python, python-qt3, ispell, ${misc:Depends} > +Depends: python, python-qt3, ${misc:Depends} > +Recommends: aspell | ispell Yes you're right. That may be more sensible. I've updated it. > (2) [minor suggestion, I don't mind leaving it as is] I'd personally > leave the end of this sentence out of the Debian description. > > TreeLine is written in Python and uses the PyQt bindings to the Qt > - toolkit, which makes it very portable. > + toolkit. I don't really mind too much, I've corrected it as it might be redundant for the description. It might be of interest to users knowing that they can be able to take their data files (xml) to many systems, but the last words probably are redundant with the rest of the sentence. > (3) > > > Package: treeline-i18n > > Description: translation files for treeline data manager > > Despite upstream shipping these two in separate tarballs, two separate > binaries _and_ source seems an overkill to me. Perhaps other -mentors > readers will disagree, but I'd look into shipping the translations in > the treeline package itself (most packages do ship translations > themselves, don't they?). This would mean repackaging, though. I found it overkill too, I was just not sure whether to repackage it (maybe putting original .tgz files inside a .orig.tar.gz?) or to leave them as they are. Do you think it might be better to repackage them? If I repackaged the original tarballs, would it be better to have just one binary? > Cheers, Greetings, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: treeline and treeline-i18n
A friend of mine spent some days looking for a suitable data storage system that could fit his need: he wanted to have a general-purpose tree-structured system where he could store different kinds of his personal data. After looking at different programs, he finally found out treeline, which suited his needs. I've also used the program since then and it's quite useful. TreeLine is a GPL program written in python, and can be obtained from http://www.bellz.org/treeline/ My packages can temporarily be found at: http://baby.yi.org/packages/treeline/ Comments are welcome. Greetings and thanks, Miry Package: treeline Description: versatile tree-like structured custom data manager TreeLine is a versatile tool for working with all kind of information that fits into a tree-like structure. . It can be used to edit bookmark files, create mini-databases (e.g., for addresses, tasks, records, CDs, etc.), outline documents, or just collect ideas. It can also be used as a generic editor for XML files. . The data schemas for any node in the data tree can be customized and new types of nodes can be defined. The way data is presented on the screen, exported to HTML, or printed can be defined with HTML-like templates. Plug-ins can be written to load and save data from and to custom file formats or external data sources and extend the functionality of TreeLine. . TreeLine is written in Python and uses the PyQt bindings to the Qt toolkit, which makes it very portable. . Homepage: http://www.bellz.org/treeline/ Package: treeline-i18n Description: translation files for treeline data manager TreeLine is a versatile tool for working with all kind of information that fits into a tree-like structure. . This package contains the translation files to German and French. . Homepage: http://www.bellz.org/treeline/ __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: RFS: wmcpuload - Dockapp that displays the current CPU usage
It seems that the webpage you mention has changed and redirects you to http://seiichisato.jp/dockapps/ Greetings, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Games Team
--- Eddy Petriºor <[EMAIL PROTECTED]> escribió: > Can ome packaging can be done for non-free games? (I am thinking about > a wrapper over the pristine installers/data/ to make the games > installable through apt-get). To be honest, I'm not particulary interested in non-free software at all, including games, but I have nothing against it if we decide as a group to do so. In my oppinion there's so much work to do about free games that I don't think it's a good idea giving away our time to non-free projects. Of course, there's the usual balance to consider between freeness and users-friendliness, but, as it has happened to other kinds of programs in more critical areas, I think it might better to concentrate in improving free games than in packaging non-free stuff, and in the long term it might give better results. Greetings, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian Games Team
Hi, We've been recently talking about creating a group to maintain games in Debian in a collaborative way. As a starting point, I've created a mailing list in alioth for coordination, and also for create discussion threads about the main problems related to game development and games packages in Debian. You can join that list at: http://lists.alioth.debian.org/mailman/listinfo/pkg-games-devel Here are some points that might be addressed by this group if there is interested in it: - Maintaining games collaboratively, as they tend to share many points in common. - "Scale economy" benefits: maintaining more packages, quicker an with less effort. - Open a way towards a larger involvement in Debian project to people maintaining just one or few games. - Quick-fixing of security issues common to games. - Discussion of problems and facts relative to game packaging. - Discussion of how to DFGS might be interpreted regarding multimedia contents and artwork in games. - Identify important games that are not packaged yet and package them. - Identify games that we were only maintainig out of inertia, and consider dropping them - Make it easier for users to know the games available in Debian, maybe with some game selector interface, a web page, screenshots or whatever. You're welcome to join the group, or say whatever you think about this project. Greetings, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: Kraptor and Kball
Thanks, I've corrected the watch files in both packages and added the bug closure in the changelog for kraptor. The new versions are availabe again at: http://baby.yi.org/packages/kronos/ Greetings, Miry --- Steve Langasek <[EMAIL PROTECTED]> escribió: > On Tue, Jan 10, 2006 at 03:19:00AM -0800, Steve Langasek wrote: > > > Already uploaded kball, actually; you should've received some email about > > that by now. Looks like bug #345244 wasn't closed in the changelog, > though, > > so I'll go close it by hand. Also, you might want to fix the broken > > debian/watch file that you added in -3, as it points to kraptor > upstream... > > > I'll take a look at kraptor as well, since it has a similar RC bug. > > ... and I see that kball's watch file ended up in the kraptor packaging. > Whoops. If you'd care to fix this issue, and also document the closure of > bug #345249 in the changelog, I can sponsor kraptor tomorrow. __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y moviles desde 1 centimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: Kraptor and Kball
Kraptor and Kball are two games currently in debian repositories, Kraptor is a classic shoot 'em up scroller game, where you must fight against tons of bad dudes. The game offers high speed action, with massive destruction and lots of fun. Kraptor features a powerful engine for 2D shooter scroller games. Massive destruction, powerful weapons, all that you always wanted in this kind of games! http://kraptor.sourceforge.net/ KBall is a game of skill and reflexes, non violent, suitable for all ages. The idea is to move a ball around the map, without falling, without running out of time, and getting the prizes, in order to reach the exit. The map has different traps, such as slides, pushers, jumps, falls, walls, etc. Maps are viewed from top view, and the walls and player's ball are real-time rendered in beautiful 3D. http://kball.sourceforge.net/ New packages are temporarily available at http://baby.yi.org/packages/kronos/ . It seems all my usual sponsors are quite busy right now, so if somebody has the time for having a look and sponsoring them, you're welcome. Greetings and thanks in advance, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y moviles desde 1 centimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC: treeline
Hi, I'm packaging a program called treeline, which is a tool for working with all kind of information that fits into a tree-like structure and it's written in python. The homepage of the program is http://www.bellz.org/treeline/ 1) I have the current draft of my packages at http://baby.yi.org/packages/treeline/ in case you want to have a look at them. They only have a lintian warning which I'm not very sure how to handle: W: treeline: script-not-executable ./usr/lib/treeline/spellcheck.py N: N: This file starts with the #! sequence that marks interpreted scripts, N: but it is not executable. The program consists of many .py scripts which are called from a shell script, so the don't really need to be executable, but all of them seem to have a starting shebang line: #!/usr/bin/env python Should I remove this linkes from the files? 2) The installation script generates python compiled .pyc files during the creation of the package. I think I can remember there were some other packages which did that compilation durinf the installation of the package in the postinst script. Which of both approaches seems to be better? Are they equivalent? 3) The installation script installs the files in /usr/lib/treeline/. These files seem to be totally arch-independent, and thus it might be better to put them under /usr/share/treeline/. Should I keep the default installation dir or just change it? Greetings and thanks (and happy New Year) :) Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y moviles desde 1 centimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: including images for documentation
--- Kapil Hari Paranjape <[EMAIL PROTECTED]> escribió: > Hello, > > I have added some documentation to a Debian package (tex4ht) that I > maintain. > > This documentation is not part of upstream and includes some images. > Source for this documentation+images is also part of what I have > added to the upstream source. > > Is there some way to include the images in the debian package? The best way I know for adding binary files to a Debian's diff patch is through the use of uuencode and uudecode programs, or something similar to that. You will not be able to add a binary file directly to the program tree, the tools will fail. You should also remember to add the copyright owner and license of all that new documentation, in case it is different to the main program's. > Thanks and regards, > > Kapil. Greetings, Miry __ Renovamos el Correo Yahoo! Nuevos servicios, más seguridad http://correo.yahoo.es -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gtklife vs. lucidlife
Hi :) I have quite of a problem of which I cannot find an easy solution. Some time ago I packaged a program called gtklife, which is a fast simulator of Conway's Game of Life using GTK widgets. The original program is available at http://ironphoenix.org/tril/gtklife/ There's also a derivative of that program I've also packaged called lucidlife which uses GTK2 (which are cuter) and uses gnome desktop. It is available at http://icculus.org/~jcspray/LucidLife/ The problem is that both programs are too similar, so in case I wanted to put one of them inside Debian's repositories I should choose which one I prefer. The engine of both programs is the same, the main difference is the interface. gtklife's interface is just GTK but it is desktop-agnostic, lucidlife has a better interface, uses GTK2 but is dependent on Gnome. Any ideas or suggestions? Thanks, Miry __ Renovamos el Correo Yahoo! Nuevos servicios, más seguridad http://correo.yahoo.es -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shotgun Debugger: different data packages depending on endianness
--- Justin Pryzby <[EMAIL PROTECTED]> wrote: > I guess you could Recommend: endianpkg1 | endianpkg2. That wouldn't select the approppriate one when installing, will it? > Really, it seems that the game should just work with a single set of > data files by doing appropriate byteswapping. I know, and I do agree with you. They just seem to prefer doing it the other way (lazyness?) > Justin Thanks and greetings, Miry __ Renovamos el Correo Yahoo! Nuevos servicios, más seguridad http://correo.yahoo.es -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Shotgun Debugger: different data packages depending on endianness
Hi, I've packaged a game called "Shotgun Debugger", available at: http://sdb.gamecreation.org/ You can see a brief description of the game at: http://www.happypenguin.org/show?Shotgun%20Debugger According to the following web page: http://gcsociety.sp.cs.cmu.edu/~frenzy/porting.html """ Shotgun Debugger uses the MD2 format for its 3D models. MD2 is a binary format, and is thus prone to endianness incompatibility. The models that come with the Shotgun Debugger packages will work on little-endian architectures (Intel x86, AMD64, etc.) only. If you plan on compiling Shotgun Debugger on a big-endian system (PowerPC*, SPARC, etc.), you will need to download the big-endian model pack. These models have the .md2b extension; just put them in the models/ directory. Shotgun Debugger recognizes the endianness of your system and loads the appropriate model set. """ I've created two different packages, one with the md2 files and another one with the md2b files. I've tried to make the main program install the appropriate package depending on it's endianness but I wasn't able to get it working. Any ideas how to do it? BTW, which debian archs are big endian and which are small endian? BTW, my packages are available at: http://156.35.156.136/inniyah/shotgun-debugger/ Note: I'm not really interested in maintaining this package. After playing a bit with the game, I discovered it's not the kind of game I like to play, so I just want to learn how to do it, not maintaining it. If anybody wants to maintain the packages for tis game, (s)he is free to do it :) Greetings, Miry __ Renovamos el Correo Yahoo! Nuevos servicios, más seguridad http://correo.yahoo.es __ Renovamos el Correo Yahoo! Nuevos servicios, más seguridad http://correo.yahoo.es -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]