Re: RFS: libapache2-mod-socket-policy-server (an Apache2 module for serving Adobe socket policy files)
On 09/21/2011 11:43 AM, Thomas Goirand wrote: On 09/21/2011 12:49 PM, Daniel Kauffman wrote: ... for serving Adobe socket policy files. What's that? How do you make them? Adobe Flash Player (since version 9.0.124.0) will not open a socket connection to a server unless the server first authorizes the connection via an Adobe socket policy. This module serves these policies. (Adobe uses a non-standard protocol for serving these policies, hence the existence of this module.) Adobe socket policies are configured using XML. A selection of pre-configured socket policies are available in: /usr/share/libapache2-mod-socket-policy-server/socket-policy/ And more information about socket policies in particular, and cross domain policies in general, is available from the Adobe Cross Domain Policy File Specification: https://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html Other useful links discussing Adobe socket policies: https://www.adobe.com/devnet/flashplayer/articles/socket_policy_files.html https://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html The package is ready for sponsorship and can be downloaded from: http://socketpolicyserver.com The updated package is ready for download. 1/ The package is a native package, which isn't required for an Apache module IMO. Please read about it in the Debian policy manual. There is no upstream, so it seemed appropriate to create a native package... is that incorrect? I didn't see a reference to quilt in the Debian Policy Manual and the Debian New Maintainers' Guide section 2.9 seems to suggest that a native package is ok where there is no upstream. The native format seems a little simpler. But if I'm missing something, and the quilt format is preferable, I can switch to that. 2/ The package has apache2-threaded-dev as Build-Depends, any reason why it wouldn't work with apache2-prefork-dev also? Also, having a binary package with apache2 | apache2-mpm seems strange to me. I agree, both of those seemed a little odd to me as well. I had referenced the instructions on: http://wiki.debian.org/Apache/PackagingModules And it seems that building against the threaded headers results in a module that works with both threaded and non-threaded versions of apache2. In my case, I built the module against apache2-threaded-dev and have no issues running the module with either apache2-mpm-worker or apache2-mpm-prefork. The binary dependency on apache2 | apache2-mpm was from those same instructions. Some apache2 modules use this construct, and some don't. All four of the apache2-mpm-* packages provide both names. I'm not sure what the reasoning is behind this, though it is interesting that apache2 is a package and apache2-mpm is a virtual package. Perhaps this is some sort of historical artifact? 3/ It'd be nice to use the DEP5 format for debian/copyright. Please see http://dep.debian.net/deps/dep5/. It's still a candidate, so it's not a requirement though. Updated, no problem. 4/ Your Standards-Version: isn't up-to-date. Did you build the package in SID and ran lintian there? Reviewed checklist and updated Standards-Version. Re-built using pbuilder sid and checked using lintian from backports. No issues. I: libapache2-mod-socket-policy-server: extended-description-is-probably-too-short You don't need the last dot at the end, but you do need a longer extended description. Lintian complains with less than 2 lines, but I think at least 10 lines sounds reasonable. By reading what you wrote, I still don't understand what your package is doing. :) The description is now longer. Hopefully, it is also more descriptive. :-) 5/ Your debian/README explains how to use apt-get, that we can edit the config file of the module, and how to restart apache. I don't think you should do that, it's not helpful, but there might be other things you want to document (like what to put in the socket policy file for example?). I updated the README to be a duplicate of the (new) description from the control file (including links describing the socket policy file format), plus a description of the configuration directives and a description of how to test that the module is configured as expected. Anything else come to mind that might be helpful here? 6/ Your package configures a VirtualHost in a /etc/apache2/conf.d file, don't you think it would be nicer in /etc/apache2/sites-available? If not, please explain here why. True, VirtualHost doesn't really belong there. Not sure how I missed that. However, instead of moving the configuration, I removed the VirtualHost declaration, so that the default configuration is now a global configuration. None of the apache2 modules in the repository touch /etc/apache2/sites-available -- IMO the sites-available directory is more appropriate for something like a web application. I hope the above helps, It does, thank you. Thanks for your will to
Re: Package separation/naming conventions
Jakub Wilk jw...@debian.org writes: * Ole Streicher debian-de...@liska.ath.cx, 2011-09-21, 16:42: - libwcs4 and libwcs4-dev - libpgsbox4 and libpgsbox4-dev First of all, don't version your -dev package(s), unless you want to keep multiple versions of it in the archive at the same people. (You probably don't.) Also, unless there's good reason to separate -dev package, I'd create just a single one. So I would just create a common wcslib-dev package, correct? And, which dependencies should the wcslib-dev package have? libpgsbox.a would contain references to pgplot5; which is non-free, old and ugly. However, in most of the cases one would just develop for libwcs, so libpgsbox.a is just for some rare special cases. Should wcslib-dev therefore suggest pgplot, but not depend on it? Or is the link here made with the suggests/enhances dependency? And what would then suggest what? libwcs4-dev suggests wcslib-doc, or vice versa? You can use both. Or none. Users will find out which package they need anyway, so don't worry about it. :) How would they do that? I personally would find it quite confusing to find the development headers and documentation of libpgsbox4 in wcslib-devel resp. wcslib-doc. - libwcs4-tools (two small executable) - libpgsbox4-tools (one small executable) That make sense (except there's probably no need to version *-tools packages). To summarize: libwcs4 . shared library for libwcs.4.so libpgsbox4 .. shared library for libpgsbox.4.so --- depends on libwcs4, pgplot5 wcslib-dev .. headers and static libs for libwcs and libpgsbox --- recommends libwcs4, wcslib-doc --- suggests libpgsbox4, pgplot5 wcslib-doc .. API documentation of libwcs and libpgsbox --- suggests wcslib-dev libwcs-tools small tools built with libwcs4 --- depends on libwcs4 libpgsbox-tools . small tool built with libpgsbox --- depends on libwcs4, libpgsbox4, pgplot5 Any comments/improvements here? Is the division into main and contrib done automatically based on the dependencies to non-free packages? And if a package requires a non-free package to build, will it automatically go to contrib, even if the package itself (like libwcs4) has no dependency to non-free? Best regards Ole -- 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/ytz7h512exk@news.ole.ath.cx
Re: RFS: libapache2-mod-socket-policy-server (an Apache2 module for serving Adobe socket policy files)
On 09/22/2011 03:32 PM, Daniel Kauffman wrote: Adobe Flash Player (since version 9.0.124.0) will not open a socket connection to a server unless the server first authorizes the connection via an Adobe socket policy. This module serves these policies. (Adobe uses a non-standard protocol for serving these policies, hence the existence of this module.) Adobe socket policies are configured using XML. This is exactly what should be in your long description!!! There is no upstream, so it seemed appropriate to create a native package... is that incorrect? What do you mean no upstream ? You mean that you are BOTH upstream and maintainer? I didn't see a reference to quilt in the Debian Policy Manual and the Debian New Maintainers' Guide section 2.9 seems to suggest that a native package is ok where there is no upstream. No. It's ok to do so when the software is intended only for Debian (like, the Debian installer for example... I'm not even sure that's the case, just an example), which isn't your case. The native format seems a little simpler. But if I'm missing something, and the quilt format is preferable, I can switch to that. The native format has nothing to do with quilt / source format 1.0 vs 3.0. Unless you are doing something specific to Debian. And it seems that building against the threaded headers results in a module that works with both threaded and non-threaded versions of apache2. Ok, cool then! Thomas -- 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/4e7b021...@debian.org
RFS: pidgin-privacy-please
Dear mentors, I am looking for a sponsor for my package pidgin-privacy-please. * Package name: pidgin-privacy-please Version : 0.7.1-1 Upstream Author : Stefan Ott * URL : http://pidgin-privacy-please.googlecode.com/ * License : GNU GPLv3 Section : net It builds those binary packages: pidgin-privacy-please - plugin for enhanced privacy in pidgin To access further information about this package, please visit the following URL: http://mentors.debian.net/package/pidgin-privacy-please Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/pidgin-privacy-please/pidgin-privacy-please_0.7.1-1.dsc I would be glad if someone uploaded this package for me. cheers -- Stefan Ott http://www.ott.net/ You are not Grey Squirrel? -- 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/CAOk=tPTiRSqmnT=ebh0natx1vffgvsmhi4ss31ldpxpqmtw...@mail.gmail.com
Re: RFS: pidgin-privacy-please
Stefan Ott ste...@ott.net writes: Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/pidgin-privacy-please/pidgin-privacy-please_0.7.1-1.dsc I would be glad if someone uploaded this package for me. I noticed two things with regards to the package: * The copyright years in debian/copyright's upstream license part do not match the years of the upstream sources (2005-2008 vs 2005-2010) * debian/copyright claims the license is GPLv2+, while upstream sources are GPLv3+. Thus, debian/copyright would be in need of some minor updates, but seeing as you're upstream too, these issues can be considered cosmetic, in my opinion. -- |8] -- 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/8762kk6bqh@balabit.hu
Re: RFS: pidgin-privacy-please
On Thu, Sep 22, 2011 at 13:46, Gergely Nagy alger...@balabit.hu wrote: I noticed two things with regards to the package: * The copyright years in debian/copyright's upstream license part do not match the years of the upstream sources (2005-2008 vs 2005-2010) * debian/copyright claims the license is GPLv2+, while upstream sources are GPLv3+. Thus, debian/copyright would be in need of some minor updates, but seeing as you're upstream too, these issues can be considered cosmetic, in my opinion. Thanks for noticing. I re-uploaded the package with a corrected version of debian/copyright. cheers -- Stefan Ott http://www.ott.net/ You are not Grey Squirrel? -- 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/CAOk=tPQ=iHfS7ropyuSyv56PszL_kw8PRvAMWZMMM8yAQq9=m...@mail.gmail.com
Re: Package separation/naming conventions
Hi, Ole Streicher debian-de...@liska.ath.cx writes: Is the division into main and contrib done automatically based on the dependencies to non-free packages? No, it is done by hand using the Section field in debian/control. And if a package requires a non-free package to build, will it automatically go to contrib, even if the package itself (like libwcs4) has no dependency to non-free? If it has a contrib/non-free build-dependency, the source package needs to go to contrib as well. It cannot build binaries in main in that case. Regards, 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/s2sr538pz8p@bistromathics.mathi.uni-heidelberg.de
Re: Package separation/naming conventions
Hi Ansgar, Ansgar Burchardt ans...@debian.org writes: Ole Streicher debian-de...@liska.ath.cx writes: Is the division into main and contrib done automatically based on the dependencies to non-free packages? No, it is done by hand using the Section field in debian/control. OK, so I have to add the flags there. If it has a contrib/non-free build-dependency, the source package needs to go to contrib as well. It cannot build binaries in main in that case. My problem here is: the source package contains libwcs which may be built (and used) completely without non-free dependencies, and libpgsbox which needs a non-free library to be built and used. Is there a way to get libwcs into main and libpgsbox into contrib? Can I specify build-dependencies separately for each binary package? Best Ole -- 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/ytz39fo3h85@news.ole.ath.cx
Re: Package separation/naming conventions
Ole Streicher debian-de...@liska.ath.cx writes: If it has a contrib/non-free build-dependency, the source package needs to go to contrib as well. It cannot build binaries in main in that case. My problem here is: the source package contains libwcs which may be built (and used) completely without non-free dependencies, and libpgsbox which needs a non-free library to be built and used. Is there a way to get libwcs into main and libpgsbox into contrib? You have two options, I think (hopefully someone will correct me, if I'm terribly wrong): * Either don't build the part which (build-)depends on non-free, and don't ship it at all, then both the source and the resulting binaries can be in main. * Split the source package into two: one that contains and builds only the completely free parts, and one that builds only the lib that'd go into contrib. Personally, I would go with the first option, unless libpgsbox is really desperately needed, and splitting the source package is worth the effort. Can I specify build-dependencies separately for each binary package? Nope, you cannot. -- |8] -- 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/87wrd04v6m@balabit.hu
Re: Package separation/naming conventions
* Ole Streicher debian-de...@liska.ath.cx, 2011-09-22, 09:51: - libwcs4 and libwcs4-dev - libpgsbox4 and libpgsbox4-dev First of all, don't version your -dev package(s), unless you want to keep multiple versions of it in the archive at the same people. (You probably don't.) Also, unless there's good reason to separate -dev package, I'd create just a single one. So I would just create a common wcslib-dev package, correct? And, which dependencies should the wcslib-dev package have? A -dev package should have a strict versioned dependency on all the shared libraries it provides .so symlink for. libpgsbox.a would contain references to pgplot5; which is non-free, old and ugly. Wait, you link *statically* to a non-free library? That'd make your binary package contain non-free bits, and as a consequence the whole source package would have to go to non-free. Also, now I notices that (at least according to your ITP), libwcs is licensed under the GPLv3+. We can't legally distribute GPLed software linked (statically or dynamically) to non-free stuff! Or is the link here made with the suggests/enhances dependency? And what would then suggest what? libwcs4-dev suggests wcslib-doc, or vice versa? You can use both. Or none. Users will find out which package they need anyway, so don't worry about it. :) How would they do that? apt-cache search? :) -- Jakub Wilk -- 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/20110922124106.ga4...@jwilk.net
Re: Package separation/naming conventions
Jakub Wilk jw...@debian.org writes: A -dev package should have a strict versioned dependency on all the shared libraries it provides .so symlink for. This is clear, but means that the wcslib-dev would depend on libpgsbox4, and therefore on pgplot5, which is not nice. libpgsbox.a would contain references to pgplot5; which is non-free, old and ugly. Wait, you link *statically* to a non-free library? That'd make your binary package contain non-free bits, and as a consequence the whole source package would have to go to non-free. No; it is just that libpgsbox.a has symbols that are resolved in pgplot5. So, the library itself is not linked, but the user needs to link libpgplot.a when he wants to statically link libpsgbox.a; which means that the library itself is free but needs a non-free one. Also, now I notices that (at least according to your ITP), libwcs is licensed under the GPLv3+. We can't legally distribute GPLed software linked (statically or dynamically) to non-free stuff! I will contact the original author to clarify this. It seems that the easiest solution would be to remove the libpgsbox stuff completely unless someone really needs it. Best Ole -- 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/ytzy5xg1zpl@news.ole.ath.cx
Re: mentors.debian.net moved to new hardware
On Thu, 22 Sep 2011 01:08:33 +0200 Arno Töll deb...@toell.net wrote: our (not so) old host running http://mentors.debian.net was replaced right before by shiny new hardware. For you, as user you shouldn't hopefully notice the switch. The new hardware is much more powerful and has plenty of disk space. Hence all problems with exhausted disk space and time-outing servers should not occur anymore. Does it include the new version of debexpo that was soon to be deployed? In particular I'm waiting for a bugfix to allow uploading to experimental. -- 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/20110922145155.5faaa9b0@tiber.centauri
Re: mentors.debian.net moved to new hardware
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony, On 22.09.2011 15:51, Tony Houghton wrote: On Thu, 22 Sep 2011 01:08:33 +0200 Does it include the new version of debexpo that was soon to be deployed? In particular I'm waiting for a bugfix to allow uploading to experimental. No, not yet - sorry. I intend to deploy that very soon, unfortunately I still got no acknowledge from Asheesh, as the patch you are referring to is embedded in a major change and can't easily cherry-picked. As soon as we did, I will write a separate announcement. Sorry for the hassle. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOe0CMAAoJEMcrUe6dgPNtMwYQAMb+cl8jjR4/dz2aiznBlboe BCYlixiUn3Rm4Xz4Jd6I06Qabbi/YgNFSVrXB9h6EW6bI1l6U/PNI71SjKzCLV/W U1LM1I0OYbQ8pbutiezUPwu4CYLjAnoYs3Th2oFU5tVm321XZxXpxo6kGM+ICaOg FcAmQS00SOF2XyKS+ltIeSbyLpjmQ74+tBJCc/4/GUW90NPiU88POrcsz4IvQKP0 I6sbPb18KB5Jl3uGMFfrfgvr/9FLFFYnamn7ZXkD0yFnyyjP7/vk1ZirumndAi3n m/JAPOY+fS+1GWc1fKZnezXCUbruo+h0sWDakStaFs/3XrSGqxVI2+sUYQDAcQMh 7UPDHugN6z3TxAEC5C6AEqSn4Zp5udsrYdBJoBivrO0FJkJt4JVFWD1P3Pw01hdB bMM8Qo8jEvZum24gwvZ/zToSqIme0yZUWiAf4zL8r6dhRFbl+K99ls89PxFEGsPn zwuw6WUjBWBzXu4fetJ7OAwOM+UvLmnYKFthuDktBc6MDMJNQiGrylc+shjHxArG xMiFRmVn0oEndLoz5bXt4+SstsO/t7C4BxpNeS7Ey+cUSa/sAMtydeZxD4eCQ/Eg mMA9IYs1nUnagDTyidV39LH6JvAgbMvFZopb5jTgkQHUqQuAGzUP5t4/15RIpFnM 4SIAzRR/zXqMTju2J5nN =Iig7 -END PGP SIGNATURE- -- 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/4e7b408c@toell.net
RFS: kboot-utils -- needed for d-i to complete on PS3
Hi Debian Mentors, I am looking for a sponsor for my package kboot-utils, it is needed to make debian-installer complete a successful installation on PlayStation3. I am also the upstream author. * Package name: kboot-utils Version : 0.1 Upstream Author : Antonio Ospite osp...@studenti.unina.it * URL : http://git.ao2.it/kboot-utils.git/ * License : GPLv3 Programming Lang: Posix shell It builds the binary package: kboot-utils To access further information about this package, please visit the following URL: http://bugs.debian.org/641465 The package can be downloaded with dget using this command: dget -u http://ao2.it/debian/kboot-utils_0.1-1.dsc The source package can be now found in the 'debian' branch at: http://git.ao2.it/kboot-utils.git/ please keep in mind that I am still learning how to deal with git-buildpackage. The package has been tested with pbuilder, checked with lintian, verified it is piuparts-clean, but there might very well still be something worth fixing. I packaged kboot-utils (Helper tools to generate a kboot.conf file) for debian, and I'd like to ask if someone can *review* the package and maybe eventually sponsor me for upload to the main archive. At the end of the day it will be needed to have a 100% working installation on the PlayStation3, see Bug #619236: http://bugs.debian.org/619236 The plan is to first have kboot-utils in the official archive and then make d-i install it when machine==PS3. Thanks, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? pgpjkVqbczyjy.pgp Description: PGP signature
Re: What to do about the situation with id3v2
Hello everyone On Wed, May 25, 2011 at 22:56, Andrew O. Shadoura bugzi...@tut.by wrote: You can also drop libid3 as it is now and write a wrapper around some better ID3 tagging library that has the same (or compatible) interface as libid3. Also, I'd merge id3 and id3v2 into one package, or even one binary, which would behave differently depending on its argv[0]. Well, here we are, several months later. I have since rewritten id3v2 to use taglib instead of libid3 and it seems to work reasonably well [1]. I have informed upstream about my work but haven't received any feedback so far. I thus assume that they are not particularly interested in maintaining a thing that now consists of mostly my code - I can't really blame them for that. I also contacted several debian package maintainers whose packages use libid3 and sent some patches along but so far without a whole lot of success either. I guess they have more pressing things to worry about. What this leaves me with, however, is an AFAICT working version of id3v2 with support for id3v2.4 tags and nobody using it. After re-reading this thread (and the last message in particular) I have now come up with a cunning plan (which would probably have been obvious from the very beginning to a greater mind): as I took over upstream development of id3 [2] when I adopted the package, I'm thinking of (ab)using that project for my id3v2 fork and replacing the debian id3 and id3v2 packages with this great new hopefully-working thing, probably calling the new package id3 again. Once that is done, I intend to orphan libid3 to make it obvious to everyone who still uses it that they should seriously consider switching to something else instead. I realize that replacing a perfectly working little tool like id3 with my mostly untested id3v2 fork might not be the nicest thing to do, but at the moment it's the best solution I can come up with. Thus I was wondering if any of you have any comments on this. Reasonble idea? The most stupid thing you've heard in a while? Something in between? Any feedback would be welcome. [1] http://src.ott.net/cgi-bin/gitweb.cgi?p=id3v2;a=summary [2] http://id3.googlecode.com/ cheers -- Stefan Ott http://www.ott.net/ You are not Grey Squirrel? -- 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/CAOk=tptpouvpekfvdwe67ygw8r0-l3mgmu5pzw_pq0mrvqk...@mail.gmail.com
Re: RFS: libapache2-mod-socket-policy-server (an Apache2 module for serving Adobe socket policy files)
On 09/22/2011 02:38 AM, Thomas Goirand wrote: On 09/22/2011 03:32 PM, Daniel Kauffman wrote: I didn't see a reference to quilt in the Debian Policy Manual and the Debian New Maintainers' Guide section 2.9 seems to suggest that a native package is ok where there is no upstream. No. It's ok to do so when the software is intended only for Debian (like, the Debian installer for example... I'm not even sure that's the case, just an example), which isn't your case. Thanks for the clarification regarding native vs. quilt, rebuilt using quilt. The updated package can be downloaded from: http://socketpolicyserver.com -- Daniel Kauffman Lead Developer Rock Solid Solutions, LLC 877.239.9195 toll-free 208.699.9699 mobile -- 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/4e7b9278.4020...@rocksolidsolutions.org
Question about menu files
Hi, I have this in the menu file: package(wmaker):needs=wmaker \ section=/ title=Exit sort=ZZ \ command=EXIT And I got this lintian error: W: wmaker: menu-command-not-in-package usr/share/menu/wmaker:6 EXIT W: wmaker: menu-item-needs-tag-has-unknown-value wmaker usr/share/menu/wmaker:6 N: N:The menu item has a line that has a needs= field with a strange value. N:This may be intentional, but it's probably a typo that will make menu N:ignore the line. N: N:Severity: minor, Certainty: certain N: N:Check: menu-format, Type: binary Yes, is not a command. What should I do? I cannot find more info about how to add the EXIT, SHUTDOWN,... commands. Thanks a lot, Best Regards, kix -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- 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/20895f0d694890e74e5839bd02337...@kix.es
Re: RFS: kboot-utils -- needed for d-i to complete on PS3
Antonio Ospite osp...@studenti.unina.it writes: I packaged kboot-utils (Helper tools to generate a kboot.conf file) for debian, and I'd like to ask if someone can *review* the package and maybe eventually sponsor me for upload to the main archive. While I can't sponsor you, I did have a quick glance over the packaging, and would have a few comments: * lintian reports Lintian in Sid does report a few issues with the packaging, such as: P: kboot-utils source: unversioned-copyright-format-uri http://dep.debian.net/deps/dep5 P: kboot-utils: copyright-refers-to-symlink-license usr/share/common-licenses/GPL I would also extend the copyright file so that the GPL-3+ license block contains more than just a pointer to the GPL-3. (See the How to apply these terms to your new programs section of the GPL). * README You install the README file, but is that really neccessary? It doesn't add anything over the package's long description, as far as I see. * debian/rules While the rules file is exactly the same as the sample, I'd still suggest removing the comments about the file being a sample. After all, it is used in a package that's targeted for Debian - it's real, live, production ready and so on and so forth - not a sample anymore, even if it's pretty much three lines total. Other than these little cosmetic issues, I didn't find anything else that'd be suspicious as far as packaging is concerned. -- |8] -- 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/87obycrz8b@luthien.mhp
Re: What to do about the situation with id3v2
On Fri, Sep 23, 2011 at 12:48 AM, Stefan Ott wrote: I realize that replacing a perfectly working little tool like id3 with my mostly untested id3v2 fork might not be the nicest thing to do, but at the moment it's the best solution I can come up with. Thus I was wondering if any of you have any comments on this. Reasonble idea? The most stupid thing you've heard in a while? Something in between? Any feedback would be welcome. Draining the audio file tag reading swamp can only be a good idea. Please get some more testing done (by debian-user or where-ever) before you embark on this project. -- 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/caktje6hxz10wjljsk8ms2fvkx0txfb1uz_o9pqnr8a9wb5z...@mail.gmail.com
