Re: LeJOS NXJ Packaging
Hi Chris, I am trying to package the LeJOS NXJ project, its a java apt and replacement firmware for the Lego Mindstorms NXT. On the subject of packaging, the LeJOS NXJ project releases there project including all the 3rd party jars, pre-compiled jars and compiled firmware images and JNI files. I can remove the 3rd party jars and patch all the references to them and can recompile all of the JNI files. But the firmware image for the Mindstorms NXT is apparently hard to compile needing a custom setup of the arm-elf toolchain. Could I include in the package a precomiled firmware image? Also, do I just have to patch up the release so that it will compile correctly, this involves packaging most of the bash scripts and some of the ant makefiles or is there another option? What exactly is so custom about the arm-elf toolchain? Clearly, it might require cross compilation, but maybe Emdebian people can help out here. Properly building firmware instead of shipping it pre-built also means proper documentation of that custom build process, which sounds worthwhile anyway. What exactly do you mean by patch up the release? Release of what? Best, Michael pgpu1krCAAf0t.pgp Description: PGP signature
RFS: monkey (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.11.0-1 of my package monkey. It builds these binary packages: monkey - very small and fast open source web server for Linux The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/monkey - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/monkey/monkey_0.11.0-1.dsc I would be glad if someone uploaded this package for me. Kind regards Thorsten Schmale -- 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/20100727082923.ga20...@maggie.schmalenegger.com
Re: RFS: cba
Dear Sylvestre, On 26/07/10 17:43, Sylvestre Ledru wrote: Le lundi 26 juillet 2010 à 12:22 +0100, pierrot a écrit : Dear Sylvestre, On 26/07/10 15:22, Sylvestre Ledru wrote: Hello, Le vendredi 23 juillet 2010 à 12:55 +0100, pierrot a écrit : Dear Sylvestre, thank you for your ITS (intent to sponsor). I changed the debian/control according to [1], registered at alioth and applied to join the debian science project. I uploaded the corrected package to mentors again and will put a git version to alioth Where is it available ? uploaded it to: git://git.debian.org/git/debian-science/packages/cba.git Thanks. I fixed some issues and uploaded it. By the way, make clean fails to remove src/cba src/gui/cba-gtk Sylvestre Thanks a lot for uploading and pour l'aide ! Pierrot -- 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/4c4e5c9e.5080...@gmx.net
Re: LeJOS NXJ Packaging
On Tue, 2010-07-27 at 09:07 +0200, Michael Tautschnig wrote: Hi Chris, I am trying to package the LeJOS NXJ project, its a java apt and replacement firmware for the Lego Mindstorms NXT. On the subject of packaging, the LeJOS NXJ project releases there project including all the 3rd party jars, pre-compiled jars and compiled firmware images and JNI files. I can remove the 3rd party jars and patch all the references to them and can recompile all of the JNI files. But the firmware image for the Mindstorms NXT is apparently hard to compile needing a custom setup of the arm-elf toolchain. Could I include in the package a precomiled firmware image? Also, do I just have to patch up the release so that it will compile correctly, this involves packaging most of the bash scripts and some of the ant makefiles or is there another option? What exactly is so custom about the arm-elf toolchain? Clearly, it might require cross compilation, but maybe Emdebian people can help out here. Properly building firmware instead of shipping it pre-built also means proper documentation of that custom build process, which sounds worthwhile anyway. What exactly do you mean by patch up the release? Release of what? Best, Michael It needs to be built with softfloats and interworking enabled and needs to be built with a specific version of the gcc (4.3.x, not the current one). When I say patch up the release, I mean I am going to have to apply lots of patches to many files to make the lejos nxj package it work under Debian. Chris -- 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/1280230758.2942.125.ca...@chris-debian-desktop
RE: FGRun Lintian Error
On Mon, 2010-07-26 at 19:01 +1000, Matthew Palmer wrote: On Mon, Jul 26, 2010 at 09:31:10AM +0100, Chris Baines wrote: Hello mentors, I am getting a package-section-games-but-contains-no-game lintian error on my package fgrun. FGRun is a FLightGear graphical launcher, FlightGear is a flight simulator game. FGRun puts its binary in the /usr/bin directory. FGRun is not a game, however it depends on FlightGear and its only current purpose is to configure and launch FlightGear which is a game. Should I just ignore the error or place the binary in the games /usr/share/games directory or change the section of the package to something else? I would be inclined to move it into /usr/games; whilst it may not be a game itself, per se, it's certainly more game than anything else. - Matt How would you go about doing this? Would you patch the makefile or add something in to the debian/rules file. My rules file is pretty basic at the moment and just consists of: %: dh $@ (Sorry Mat) Chris -- 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/1280231173.19625.0.ca...@chris-debian-desktop
Re: FGRun Lintian Error
On Tue, Jul 27, 2010 at 7:46 AM, Chris Baines cbain...@gmail.com wrote: How would you go about doing this? Would you patch the makefile or add something in to the debian/rules file. My rules file is pretty basic at the moment and just consists of: %: dh $@ chromium-bsu debian/rules: %: dh --with autotools_dev $@ --parallel override_dh_auto_configure: dh_auto_configure -- CXXFLAGS=$(CXXFLAGS) -Wall --bindir=/usr/games --datadir=/usr/share/games If your upstream is not using autotools then this probably won't work. BTW, if you are interested in joining the Debian games team we need more folk. -- 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/aanlktimnj+oxk1auxmujqrgwd5zcg8ogs8hbzv9at...@mail.gmail.com
How to Deal with files created dynamically
Hello Mentors, I am looking at creating packages that involve programs that create caches while running of images or other files. But I am a bit stumped at what to do with the files they create, both where they are meant to go and with what permissions. Both programs build there caches off system wide data so it would be good if the caches are available system wide. I am sorry if this description is a bit vague. The programs I am looking at are terrasync, part of the Flightgear package and a new package I am thinking of building signs that enables floating signs within Flightgear. Thanks, Chris -- 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/1280231590.19625.7.ca...@chris-debian-desktop
Re: LeJOS NXJ Packaging
Hi Chris, [...] It needs to be built with softfloats and interworking enabled and needs to be built with a specific version of the gcc (4.3.x, not the current one). In this case you might want to ship gcc 4.3.x together with your package, build it first, and then compile the firmware. Note that version 3 source packages may be built from multiple archive files, which should simplify packaging quite a bit. When I say patch up the release, I mean I am going to have to apply lots of patches to many files to make the lejos nxj package it work under Debian. You might want to speak to upstream to get the package cleaned up. It seems to me that the resulting Debian package will be a lot cleaner as it will have the complete tool chain to build the package and not contain lots of duplicated code. Sure, this is not the easiest thing to achieve, but it seems worthwhile. Best, Michael pgp9Dz5pNdppC.pgp Description: PGP signature
Re: How to Deal with files created dynamically
On Tue, Jul 27, 2010 at 6:53 AM, Chris Baines cbain...@gmail.com wrote: Hello Mentors, I am looking at creating packages that involve programs that create caches while running of images or other files. But I am a bit stumped at what to do with the files they create, both where they are meant to go and with what permissions. one of these two, I would wager: /var/cache/ /var/lib As for the permissions root:root 644 (that was just a guess) -matt -- 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=grwqwblnbagady+wuup928daamhkneyjph...@mail.gmail.com
Re: will different compiler generate different symbols?
2010/7/16 Russ Allbery r...@debian.org: If so, you won't be alone, and I'm sure we'll end up with a transition plan. I've been holding off on adding symbols for C++ libraries until the support for C++ symbol patterns is in stable for exactly that reason. It resolves the problem of different mangling between different C++ versions. -- Is it acceptable that a library come without symbols file? I found my package will generate different symbols in different platform(i386 amd64), if I use symbols generated in amd64, it will not compile in i386; if I use symbols generated in i386, it will not compile in amd64, I have not test other platform, but I think it may have the same problem too. so I want my package have no symbols file. -- Liang Guo http://bluestone.cublog.cn -- 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/aanlktimgwd0lcvxz=jm=8mvv7+-uztc6gcxyelsqr...@mail.gmail.com
Re: RFS: libaosd (updated package)
On Fri, Jul 23, 2010 at 8:45 PM, Eugene Paskevich eug...@raptor.kiev.ua wrote: I am looking for a sponsor for the new version 0.2.6-1 of the package libaosd. As promised on IRC, here is a review: Why did you add the libaosd-text-dev package? Policy 3.9.1 is out. You could mention in the changelog that the maintainer agreed to transfer maintainership of the package to you. Please run tagpending before uploading packages to mentors. Are you aware of the abi-compliance-checker package? It would be great if you could use it upstream to ensure you do not break the ABI. There is also this service based on that tool: http://linuxtesting.org/upstream-tracker/ As upstream, do you have any comments on #464744? Why did you drop this line from debian/rules? rm -f config.sub config.guess If you contact the openSUSE maintainer to ask them to update the package, you might want to get them to change the source package description, which is currently a copy of their libcaca source package description. aosd_cat also is obviously not written in C# :) The upstream build system hides the build commands, usually we prefer that they are shown so that looking at the build logs allows people to debug issues more easily. Some complaints from automated tools: lintian: I: libaosd source: binary-control-field-duplicates-source field section in package libaosd2 I: libaosd source: binary-control-field-duplicates-source field section in package libaosd-text2 I: aosd-cat: copyright-with-old-dh-make-debian-copyright P: aosd-cat: no-upstream-changelog I: aosd-cat: hyphen-used-as-minus-sign usr/share/man/man1/aosd_cat.1.gz:88 I: libaosd-dev: copyright-with-old-dh-make-debian-copyright P: libaosd-dev: no-upstream-changelog I: libaosd2: copyright-with-old-dh-make-debian-copyright P: libaosd2: no-upstream-changelog X: libaosd2: shlib-calls-exit usr/lib/libaosd.so.2.0.0 I: libaosd2: no-symbols-control-file usr/lib/libaosd.so.2.0.0 I: libaosd-text-dev: copyright-with-old-dh-make-debian-copyright P: libaosd-text-dev: no-upstream-changelog P: libaosd-text2: no-upstream-changelog I: libaosd-text2: copyright-with-old-dh-make-debian-copyright I: libaosd-text2: no-symbols-control-file usr/lib/libaosd-text.so.2.0.0 dpkg-shlibdeps: dpkg-shlibdeps: warning: dependency on libgmodule-2.0.so.0 could be avoided if debian/aosd-cat/usr/bin/aosd_cat were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libcairo.so.2 could be avoided if debian/aosd-cat/usr/bin/aosd_cat were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libgthread-2.0.so.0 could be avoided if debian/aosd-cat/usr/bin/aosd_cat were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libpangocairo-1.0.so.0 could be avoided if debian/aosd-cat/usr/bin/aosd_cat were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on librt.so.1 could be avoided if debian/aosd-cat/usr/bin/aosd_cat were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided if debian/aosd-cat/usr/bin/aosd_cat were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libXfixes.so.3 could be avoided if debian/libaosd2/usr/lib/libaosd.so.2.0.0 were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libgmodule-2.0.so.0 could be avoided if debian/libaosd-text2/usr/lib/libaosd-text.so.2.0.0 were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libglib-2.0.so.0 could be avoided if debian/libaosd-text2/usr/lib/libaosd-text.so.2.0.0 were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libgthread-2.0.so.0 could be avoided if debian/libaosd-text2/usr/lib/libaosd-text.so.2.0.0 were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on librt.so.1 could be avoided if debian/libaosd-text2/usr/lib/libaosd-text.so.2.0.0 were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided if debian/libaosd-text2/usr/lib/libaosd-text.so.2.0.0 were not uselessly linked against it (they use none of its symbols). -- 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/aanlktinz=ytvguuzo2vy2yk-gixmc7chhs_4=bude...@mail.gmail.com
Re: How to Deal with files created dynamically
On Tue, 2010-07-27 at 10:03 -0500, Matt Zagrabelny wrote: On Tue, Jul 27, 2010 at 6:53 AM, Chris Baines cbain...@gmail.com wrote: Hello Mentors, I am looking at creating packages that involve programs that create caches while running of images or other files. But I am a bit stumped at what to do with the files they create, both where they are meant to go and with what permissions. one of these two, I would wager: /var/cache/ /var/lib As for the permissions root:root 644 (that was just a guess) -matt That looks promising. Thanks, Chris -- 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/1280256280.2532.0.ca...@chris-debian-desktop
Re: FGRun Lintian Error
On Tue, 2010-07-27 at 07:53 -0400, Paul Wise wrote: On Tue, Jul 27, 2010 at 7:46 AM, Chris Baines cbain...@gmail.com wrote: How would you go about doing this? Would you patch the makefile or add something in to the debian/rules file. My rules file is pretty basic at the moment and just consists of: %: dh $@ chromium-bsu debian/rules: %: dh --with autotools_dev $@ --parallel override_dh_auto_configure: dh_auto_configure -- CXXFLAGS=$(CXXFLAGS) -Wall --bindir=/usr/games --datadir=/usr/share/games If your upstream is not using autotools then this probably won't work. BTW, if you are interested in joining the Debian games team we need more folk. -- bye, pabs http://wiki.debian.org/PaulWise Thanks Paul, that was the final fix I needed. I have now uploaded my package to the mentors site. However it wont be available in Debian until simgear is upgraded and unfortunately I don't think that will happen until I get around to it! The games team sounds interesting, I have just joined the mailing list. Thanks again, Chris -- 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/1280257694.24766.6.ca...@chris-debian-desktop
Re: How to Deal with files created dynamically
On Tue, Jul 27, 2010 at 10:03:42AM -0500, Matt Zagrabelny wrote: On Tue, Jul 27, 2010 at 6:53 AM, Chris Baines cbain...@gmail.com wrote: Hello Mentors, I am looking at creating packages that involve programs that create caches while running of images or other files. But I am a bit stumped at what to do with the files they create, both where they are meant to go and with what permissions. one of these two, I would wager: /var/cache/ /var/lib Scratch /var/lib from that list. If the data can be recreated from another source, then it's cache data and should *not* live in /var/lib. As for the permissions root:root 644 If the files are created by root-owned processes, sure. It kinda smells like this is going to be done by a user-run process, which means you won't be able to apply that ownership. You will probably have to revert to per-user data stored in the homedir, unless you want to start stuffing around with suid wrappers or some such. - Matt -- 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/20100727195236.gb4...@hezmatt.org
Re: How to Deal with files created dynamically
On Wed, 2010-07-28 at 05:52 +1000, Matthew Palmer wrote: On Tue, Jul 27, 2010 at 10:03:42AM -0500, Matt Zagrabelny wrote: On Tue, Jul 27, 2010 at 6:53 AM, Chris Baines cbain...@gmail.com wrote: Hello Mentors, I am looking at creating packages that involve programs that create caches while running of images or other files. But I am a bit stumped at what to do with the files they create, both where they are meant to go and with what permissions. one of these two, I would wager: /var/cache/ /var/lib Scratch /var/lib from that list. If the data can be recreated from another source, then it's cache data and should *not* live in /var/lib. As for the permissions root:root 644 If the files are created by root-owned processes, sure. It kinda smells like this is going to be done by a user-run process, which means you won't be able to apply that ownership. You will probably have to revert to per-user data stored in the homedir, unless you want to start stuffing around with suid wrappers or some such. - Matt Yes, the programs are run with user level permissions. While per user data would be a solution I don't want to use it just to make this easier. Are there any packages that deal with these problems? Can you suggest any material about the suid wrappers or some such as I have no clue about them. Thanks, Chris -- 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/1280262363.2.4.ca...@chris-debian-desktop
Re: will different compiler generate different symbols?
Liang Guo bluestonech...@gmail.com writes: Is it acceptable that a library come without symbols file? Yes. It's still optional, particularly for C++ libraries I think. I found my package will generate different symbols in different platform(i386 amd64), if I use symbols generated in amd64, it will not compile in i386; if I use symbols generated in i386, it will not compile in amd64, I have not test other platform, but I think it may have the same problem too. so I want my package have no symbols file. This is a standard problem with C++ libraries. You have to use architecture-specific symbols for a lot of C++ libraries. There are new facilities in dpkg to try to help making writing those symbol files easier, but I'm still not getting a warm and fuzzy mature feeling about use of symbols with C++ at this point. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87k4ogu001@windlord.stanford.edu
Re: How to Deal with files created dynamically
On Tue, Jul 27, 2010 at 3:26 PM, Chris Baines cbain...@gmail.com wrote: On Wed, 2010-07-28 at 05:52 +1000, Matthew Palmer wrote: On Tue, Jul 27, 2010 at 10:03:42AM -0500, Matt Zagrabelny wrote: On Tue, Jul 27, 2010 at 6:53 AM, Chris Baines cbain...@gmail.com wrote: Hello Mentors, I am looking at creating packages that involve programs that create caches while running of images or other files. But I am a bit stumped at what to do with the files they create, both where they are meant to go and with what permissions. one of these two, I would wager: /var/cache/ /var/lib Scratch /var/lib from that list. If the data can be recreated from another source, then it's cache data and should *not* live in /var/lib. As for the permissions root:root 644 If the files are created by root-owned processes, sure. It kinda smells like this is going to be done by a user-run process, which means you won't be able to apply that ownership. You will probably have to revert to per-user data stored in the homedir, unless you want to start stuffing around with suid wrappers or some such. - Matt Yes, the programs are run with user level permissions. While per user data would be a solution I don't want to use it just to make this easier. Are there any packages that deal with these problems? You could create a group and then do something like: addgroup newpackage mkdir /var/cache/newpackage chown root:newpackage /var/cache/newpackage chmod 775 /var/cache/newpackage New users who would use this package would need to be added to said group: adduser joeuser newpackage HTH, -matt -- 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/aanlktin7ned7dem2kubtorfbdtib4mrbbz0qeufmw...@mail.gmail.com
Re: will different compiler generate different symbols?
[...] I found my package will generate different symbols in different platform(i386 amd64), if I use symbols generated in amd64, it will not compile in i386; if I use symbols generated in i386, it will not compile in amd64, I have not test other platform, but I think it may have the same problem too. so I want my package have no symbols file. This is a standard problem with C++ libraries. You have to use architecture-specific symbols for a lot of C++ libraries. There are new facilities in dpkg to try to help making writing those symbol files easier, but I'm still not getting a warm and fuzzy mature feeling about use of symbols with C++ at this point. Before dpkg 1.15.7.2 I had quite a few issues in the diagnostics package, which had symbol files for C++ for quite some time already, including spurious build failures because of different compiler versions. But with c++ name de-mangling support symbol files have become really manageable, and combining regex and c++ gives sheer beauty :-) Just my 2c, Michael pgpp889tcEsgx.pgp Description: PGP signature
Re: RFS: libaosd (updated package)
On Tue, 27 Jul 2010 20:11:47 +0300, Paul Wise p...@debian.org wrote: On Fri, Jul 23, 2010 at 8:45 PM, Eugene Paskevich eug...@raptor.kiev.ua wrote: I am looking for a sponsor for the new version 0.2.6-1 of the package libaosd. As promised on IRC, here is a review: First of all I'd like to thank you for your time and help! As you started reviewing this package does it mean that I have found a sponsor and now should note appropriately in m.d.n? Why did you add the libaosd-text-dev package? The reason for splitting out libaosd-text-dev from libaosd-dev is mainly because libaosd-dev could be used standalone without the -text lib and header. In the current state it is possible to have aosd-text.h installed without the actual libaosd-text.so library installed, which is definitely wrong. Policy 3.9.1 is out. Updated. You could mention in the changelog that the maintainer agreed to transfer maintainership of the package to you. Updated. Please run tagpending before uploading packages to mentors. Ran now. Are you aware of the abi-compliance-checker package? It would be great if you could use it upstream to ensure you do not break the ABI. There is also this service based on that tool: http://linuxtesting.org/upstream-tracker/ Now that you told me about it, I am, thank you. :-) I have run the check 0.2.5 vs 0.2.6 and for both libaosd and libaosd-text the verdict was: Compatible. As upstream, do you have any comments on #464744? I was going to comment in that bug directly once the package is uploaded. Why did you drop this line from debian/rules? rm -f config.sub config.guess I'm not sure why they are there to begin with. These files are in orig tarball and are replaced with debian ones. Why do they have to be removed on clean? If you contact the openSUSE maintainer to ask them to update the package, you might want to get them to change the source package description, which is currently a copy of their libcaca source package description. aosd_cat also is obviously not written in C# :) Thank you, I'll try to contact openSUSE maintainer. The upstream build system hides the build commands, usually we prefer that they are shown so that looking at the build logs allows people to debug issues more easily. Fixed with a patch. Some complaints from automated tools: lintian: I: libaosd source: binary-control-field-duplicates-source field section in package libaosd2 I: libaosd source: binary-control-field-duplicates-source field section in package libaosd-text2 Fixed. I: aosd-cat: copyright-with-old-dh-make-debian-copyright I: libaosd-dev: copyright-with-old-dh-make-debian-copyright I: libaosd2: copyright-with-old-dh-make-debian-copyright I: libaosd-text-dev: copyright-with-old-dh-make-debian-copyright I: libaosd-text2: copyright-with-old-dh-make-debian-copyright Fixed. P: aosd-cat: no-upstream-changelog P: libaosd-dev: no-upstream-changelog P: libaosd2: no-upstream-changelog P: libaosd-text-dev: no-upstream-changelog P: libaosd-text2: no-upstream-changelog Will be fixed in the next upstream release. I: aosd-cat: hyphen-used-as-minus-sign usr/share/man/man1/aosd_cat.1.gz:88 Fixed both upstream and with a local patch until the next release. X: libaosd2: shlib-calls-exit usr/lib/libaosd.so.2.0.0 Will be fixed in the next upstream release. I: libaosd2: no-symbols-control-file usr/lib/libaosd.so.2.0.0 I: libaosd-text2: no-symbols-control-file usr/lib/libaosd-text.so.2.0.0 Given that this tag is of wishlist severity, I believe that it's not strictly necessary to resolve. If it is strongly advised to fix this one, could you please point me to the guide on how to create these files? Is it just dpkg-gensymbols or there is something more to it? dpkg-shlibdeps: warning: dependency on XXX could be avoided if YYY were not uselessly linked against it (they use none of its symbols). I'm gonna need your help in resolving this one... As per Niels Thykier's advice I have added these flags into debian/rules LDFLAGS: --as-needed,--no-undefined. It removed most of the warnings but these two: dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided if debian/aosd-cat/usr/bin/aosd_cat were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided if debian/libaosd-text2/usr/lib/libaosd-text.so.2.0.0 were not uselessly linked against it (they use none of its symbols). -- Eugene Paskevich | *==)--- | Plug me into eug...@raptor.kiev.ua| ---(==* | The Matrix -- 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/op.vgizvuz22m4...@kite.raptor.kiev.ua
Re: RFS: libaosd (updated package)
Eugene Paskevich eug...@raptor.kiev.ua writes: It removed most of the warnings but these two: dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided if debian/aosd-cat/usr/bin/aosd_cat were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided if debian/libaosd-text2/usr/lib/libaosd-text.so.2.0.0 were not uselessly linked against it (they use none of its symbols). I would not worry about fixing this. I think trying to fix it is more trouble than it's worth, and since this library won't add any new library dependencies to your package, it's really just aesthetic. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/877hkgijdp@windlord.stanford.edu
Re: RFS: libaosd (updated package)
On Wed, 28 Jul 2010 02:40:18 +0300, Russ Allbery r...@debian.org wrote: Eugene Paskevich eug...@raptor.kiev.ua writes: dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided if debian/aosd-cat/usr/bin/aosd_cat were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libpthread.so.0 could be avoided if debian/libaosd-text2/usr/lib/libaosd-text.so.2.0.0 were not uselessly linked against it (they use none of its symbols). I would not worry about fixing this. I think trying to fix it is more trouble than it's worth, and since this library won't add any new library dependencies to your package, it's really just aesthetic. Thank you. The updated package has been uploaded to m.d.n. -- Eugene Paskevich | *==)--- | Plug me into eug...@raptor.kiev.ua| ---(==* | The Matrix -- 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/op.vgi0r0yh2m4...@kite.raptor.kiev.ua
Re: How to Deal with files created dynamically
On Tue, Jul 27, 2010 at 03:47:48PM -0500, Matt Zagrabelny wrote: On Tue, Jul 27, 2010 at 3:26 PM, Chris Baines cbain...@gmail.com wrote: On Wed, 2010-07-28 at 05:52 +1000, Matthew Palmer wrote: On Tue, Jul 27, 2010 at 10:03:42AM -0500, Matt Zagrabelny wrote: On Tue, Jul 27, 2010 at 6:53 AM, Chris Baines cbain...@gmail.com wrote: Hello Mentors, I am looking at creating packages that involve programs that create caches while running of images or other files. But I am a bit stumped at what to do with the files they create, both where they are meant to go and with what permissions. one of these two, I would wager: /var/cache/ /var/lib Scratch /var/lib from that list. If the data can be recreated from another source, then it's cache data and should *not* live in /var/lib. As for the permissions root:root 644 If the files are created by root-owned processes, sure. It kinda smells like this is going to be done by a user-run process, which means you won't be able to apply that ownership. You will probably have to revert to per-user data stored in the homedir, unless you want to start stuffing around with suid wrappers or some such. Yes, the programs are run with user level permissions. While per user data would be a solution I don't want to use it just to make this easier. Are there any packages that deal with these problems? You could create a group and then do something like: addgroup newpackage mkdir /var/cache/newpackage chown root:newpackage /var/cache/newpackage chmod 775 /var/cache/newpackage This is only practical if the cache files are not trusted by the application; users can directly manipulate the files and their contents. It must be possible to verify that the cache files are correct before using them. Also, if you're going to go that wild, you may as well just make the directory group 'users' or some equally common group. Also, don't forget the g+s and umask 002 to avoid per-user permission nightmares. In other words: per-user caching ftw. - Matt -- 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/20100728005138.gd4...@hezmatt.org
