Re: debian/watch for gitorious
Hello, On Fri, 08 Mar 2013 21:51:26 +0100 Ansgar Burchardt ans...@debian.org wrote: Please do! Having a header in each file makes reviewing license information much, much easier. If there's only a global license file it will often not contain information about files that are released under a different licenses. Or it gets totally unclear what the actual license is if files from project A get copied into project B. By the way. How about upstream shipping a file in debian/copyright format describing all the things about licenses in one place? -- WBR, Andrew signature.asc Description: PGP signature
Re: debian/watch for gitorious
On Fri, Mar 08, 2013 at 10:54:58AM +0800, Paul Wise wrote: None of the C files contain copyright or license information, which is a good idea: http://tieguy.org/blog/2012/03/17/on-the-importance-of-per-file-license-information/ Please, don't! There are at least three reasons why not: * It adds significant amount of legal spam that gets into way. Every single time someone looks through one of the files, it takes a second or two to skip past the header. This wastes time that could be spent coding or debugging. * Such notices invariably become inaccurate. Unless every single contributor takes care to meticulously update this information (and hardly anyone does), it will be at best misleading. On the other hand, a global license file carries less data and thus has a fair chance of being valid (as you don't need to care about individual files). And if you use version control, you already have per-file -- and even, per-line, authorship tracking that requires no manual effort to update. * It is legally dubious whether anyone will be able to cut this spam away once it gets there, kind of like an epoch. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- 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/20130308181624.ga6...@angband.pl
Re: debian/watch for gitorious
Hello, On Fri, 8 Mar 2013 17:44:03 +0100 Alfonso Sabato Siciliano alfi...@gmail.com wrote: CFLAGS= `sdl-config --cflags` -Wall -g LFLAGS= `sdl-config --libs` -lSDL_image -lSDL_ttf -lSDL_mixer beret: game.o thing.o physics.o $(CC) $(LFLAGS) $^ -o $@ %.o: %.c $(CC) -c $(CFLAGS) $ This is not correct. Correct would be: CFLAGS=`sdl-config --cflags` -Wall -g LDLIBS=`sdl-config --libs` -lSDL_image -lSDL_ttf -lSDL_mixer beret: game.o thing.o physics.o # end of file With no %.o: %.c rule at all, and with nothing for linking. Use built-in rules, they rule. -- WBR, Andrew signature.asc Description: PGP signature
Re: debian/watch for gitorious
Hello, On Fri, 8 Mar 2013 17:44:03 +0100 Alfonso Sabato Siciliano alfi...@gmail.com wrote: CFLAGS= `sdl-config --cflags` -Wall -g LFLAGS= `sdl-config --libs` -lSDL_image -lSDL_ttf -lSDL_mixer ... beret: game.o thing.o physics.o $(CC) $(LFLAGS) $^ -o $@ Well, I wasn't entirely correct when I said incorrect. Incorrect is calling LDLIBS LFLAGS. Also, it's a good idea to place libs after your binaries, not before. But why do that when built-in rules work just fine and make you Makefile a lot shorter? -- WBR, Andrew signature.asc Description: PGP signature
Re: debian/watch for gitorious
Adam Borowski kilob...@angband.pl writes: On Fri, Mar 08, 2013 at 10:54:58AM +0800, Paul Wise wrote: None of the C files contain copyright or license information, which is a good idea: http://tieguy.org/blog/2012/03/17/on-the-importance-of-per-file-license-information/ Please, don't! Please do! Having a header in each file makes reviewing license information much, much easier. If there's only a global license file it will often not contain information about files that are released under a different licenses. Or it gets totally unclear what the actual license is if files from project A get copied into project B. Ansgar -- 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/8738w5ipip@eisei.43-1.org
Re: debian/watch for gitorious
On Fri, Mar 08, 2013 at 09:51:26PM +0100, Ansgar Burchardt wrote: Adam Borowski kilob...@angband.pl writes: On Fri, Mar 08, 2013 at 10:54:58AM +0800, Paul Wise wrote: None of the C files contain copyright or license information, which is a good idea: http://tieguy.org/blog/2012/03/17/on-the-importance-of-per-file-license-information/ Please, don't! Please do! Having a header in each file makes reviewing license information much, much easier. This might be the case only if that information has any semblance of validity. That's possible pretty much only for tiny projects with one or at most few contributors. In anything worth looking at, a single file will be typically edited by tens of contributors at least, with changes touching many files at once. Another issue is, if code is borrowed from another project, it will usually be included inside a file rather than being a whole file (unless we're talking about embedded copies, which are bad for obvious reasons). This means you'd need to track contributions at line scope (or even character!) rather than per-file. So, you pay costs, for no gains. If you really need to know how a piece of code ended up in the project, just use version control. It's reliable and complete, at least for modern version control systems. Version control is not centered on legal issues, but in the worst case it will tell you at least who checked something in. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- 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/20130308214030.ga11...@angband.pl
Re: debian/watch for gitorious
On Sat, Mar 9, 2013 at 5:40 AM, Adam Borowski wrote: This might be the case only if that information has any semblance of validity. That's possible pretty much only for tiny projects with one or at most few contributors. In anything worth looking at, a single file will be typically edited by tens of contributors at least, with changes touching many files at once. Not all of these changes will be eligible for copyright protection. If you really need to know how a piece of code ended up in the project, just use version control. It's reliable and complete, at least for modern version control systems. Version control is not centered on legal issues, but in the worst case it will tell you at least who checked something in. Version control data doesn't end up in tarballs so it is not useful for filling out debian/copyright. Version control data is orthogonal to who owns copyright, just because someone is the author or committer of some code doesn't mean that they are the copyright holder (think work for hire, copyright transfer, etc). -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6HwrPCy_DE3H8=dhux43_yfvnc+t6n538ehyx2h170...@mail.gmail.com
debian/watch for gitorious
Hi, I am making my first package (game: beret), the source of software is on gitorious: https://gitorious.org/beret . What must I write in debian/watch? I don't find docs about. regards Alfonso -- 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/CAPJrGM09D2t=6o-tOFBe8MMJx0=h90p+yvzfuwb0q259ovh...@mail.gmail.com
Re: debian/watch for gitorious
On Fri, Mar 8, 2013 at 9:45 AM, Alfonso Sabato Siciliano wrote: I am making my first package (game: beret), the source of software is on gitorious: https://gitorious.org/beret . What must I write in debian/watch? I don't find docs about. This particular project has no releases and no git tags, so you can't create a useful watch file. I would suggest talking to upstream and asking them to make source code tarball releases and git tags for them. At the same time, you could point them at these guides for upstream projects: http://www.freedesktop.org/wiki/Games/Upstream http://wiki.debian.org/UpstreamGuide I took a look at the git repository and found these issues, please forward them upstream: There is a copy of this font in the git repo, it should be removed and packaged separately: http://iotic.com/averia/ None of the C files contain copyright or license information, which is a good idea: http://tieguy.org/blog/2012/03/17/on-the-importance-of-per-file-license-information/ There is a Windows Thumbs.db in the git repo, that is useless and should be removed. A lot of the files have execute permission but they are not executables so shouldn't have that. credits.png and title.png contain pre-rendered text, they should be rendered at runtime instead so that the text can be translated into other languages. I would suggest splitting tilesheet.png/spritesheet.png up into individual tiles and sprites and loading them at runtime or creating tilesheet.png/spritesheet.png at build time. Many/all of the images appear to be created in the GIMP, are there any XCF files? If so they should be in git and the PNG files should be removed and rendered at build time. All the music is pre-mixed, pre-encoded so not in an ideal form for modification, can you ask upstream how they were created? How were the sound effects created? What format are the rooms files in? How are they supposed to be modified? I see there is level2png.git, I wonder if it would be better for the game itself to just load PNG files instead of using the intermediate format. In any case, the best form for modification (PNG) should be in git not the intermediate form (current level files) and the level files should be created at build time. The game fails to build because it uses an incorrect path to the SDL header, I've just now sent upstream a patch for this. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6h_+yqw_rphg7ewwajpgw4ntjjhc1_vpxggqbsmusx...@mail.gmail.com
