FGRun Lintian Error
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? 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/1280133070.3087.12.ca...@chris-debian-desktop
Re: FGRun Lintian Error
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 -- 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/20100726090124.gb19...@hezmatt.org
RFS: plasma-widget-adjustableclock
Dear mentors, I am looking for a sponsor for my package plasma-widget-adjustableclock. * Package name: plasma-widget-adjustableclock Version : 2.2-4 Upstream Author : Michal Dutkiewicz emd...@gmail.com * URL : http://www.kde- look.org/content/show.php/Adjustable+Clock?content=92825 * License : GPL version 2 or any later version Section : kde It builds these binary packages: plasma-widget-adjustableclock - plasma widget clock to show date and time The package appears to be lintian clean. The upload would fix these bugs: 589567 My motivation for maintaining this package is: I needed it. Therefore I ported it form Ubuntu, converting it to 3.0 (quilt) format, testing it and so on. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/plasma-widget- adjustableclock - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/plasma-widget- adjustableclock/plasma-widget-adjustableclock_2.2-4.dsc I would be glad if someone uploaded this package for me. Kind regards Davi Leal -- 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/201007261513.31825.d...@gnu.org
conflicts/replaces/provides vs. breaks/replaces/provides under policy 3.9.1
Hi folks, Breaks field was added to policy in 3.8 and current stable dpkg supports it as I understand. So we are ready to use it, as I understand. Under this new situation, I would like to confirm what is the best practice for each case scenario. Please comment on my thought as below: = Case 1: only one package rule install only one package out of packages providing a common virtual package. | Package: one-of-package-providing-virtual-package | Conflicts: virtual-package | Provides: virtual-package | Replaces: virtual-package Question: Please confirm this is still correct. = Case 2: package transition rule All the contents of the package foo is incorporated by bar in new 1.0 version and foo 1.0 became a transitional package with no real contents which can be removed safely. Please note pre-1.0 version of foo was not a transitional package. | Package: foo | Version: 1.0 | Description: ... | This is a transitional package for foo, and can be safely removed | after the installation is complete. | Package: bar | Version: 1.0 | Breaks: foo ( 1.0 ) | Replaces: foo ( 1.0 ) | Provides: foo Question: Is this right? Do we need ( 1.0 ) for replaces? = Case 2': package transition rule After stable release with case 2, you wish to remove the transitional package foo upon upgrade to unstable/testing/next-stable. I guess we do not package Package: foo at this moment when uploading. Question: Is there sure way to purge the old transitional package foo? Do we do ... | Package: bar | Version: 1.0 | Conflicts: foo ( 1.0 ) | Replaces: foo ( 1.0 ) | Provides: foo Or | Package: bar | Version: 1.0 | Conflicts: foo | Replaces: foo | Provides: foo Osamu -- 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/20100726150948.ga4...@debian.org
Re: conflicts/replaces/provides vs. breaks/replaces/provides under policy 3.9.1
Not answering the Conflics/Breaks issue, but some remark about Provides. * Osamu Aoki os...@debian.org [100726 17:27]: = Case 2: package transition rule All the contents of the package foo is incorporated by bar in new 1.0 version and foo 1.0 became a transitional package with no real contents which can be removed safely. Please note pre-1.0 version of foo was not a transitional package. | Package: foo | Version: 1.0 | Description: ... | This is a transitional package for foo, and can be safely removed | after the installation is complete. | Package: bar | Version: 1.0 | Breaks: foo ( 1.0 ) | Replaces: foo ( 1.0 ) | Provides: foo Here the provide has advantages and disadvantages. I'd not suggest to use it unconditionally here (and even recommend against it in the usual cases). Also note that moving package foo to oldlibs makes it easier for people to remove such packages. = Case 2': package transition rule After stable release with case 2, you wish to remove the transitional package foo upon upgrade to unstable/testing/next-stable. I guess we do not package Package: foo at this moment when uploading. | Provides: foo I'd recommend against using recommend here unless in very special cases. An additional provides means more work for each dependency resolver. And after stable released with no real package with that name, there should no longer be any need for it. Do we do ... | Package: bar | Version: 1.0 | Conflicts: foo ( 1.0 ) | Replaces: foo ( 1.0 ) This only makes sense if you want to make life easier for backporters to oldstable. Or | Package: bar | Version: 1.0 | Conflicts: foo | Replaces: foo That means foo is to be removed. This means hard decisions for the resolver (hopefully it will decide to keep bar and remove foo, and not remove both). Question: Is there sure way to purge the old transitional package foo? Why do you want to make sure to remove it? It does not cause harm, is easy to find and remove. And it might be the only thing keeping bar from being removed as a no longer needed dependency. Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- 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/20100726154816.ga31...@pcpool00.mathematik.uni-freiburg.de
Re: RFS: twofish -- updated package
Mats Erik Andersson mats.anders...@gisladisker.se writes: I am looking for a sponsor for a new version 0.3-2 of the package twofish. It builds these binary packages: libtwofish-dev - Niels Ferguson's Twofish cryptographic algorithm library libtwofish0 - Niels Ferguson's Twofish cryptographic library -- runtime package The package appears to be lintian clean in i386, amd64, and kfreebsd-i386. The upload would fix this bug: 522262, an ITA bug. Hi! With Policy 3.9.1 the -D_REENTRANT requirement has been dropped. YOu might want to get rid of that for the next upload. That's of course newer than the package -- uploaded as it is now. Regards Christoph P.S.: Have you considered becoming DM? -- 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/876302tawo@chillida.ipv6.sieglitzhof.net
RFS: kismet (updated package)
Dear mentors, I am looking for a sponsor for the new version 2010-07-R1-4.2 of my package kismet. It builds these binary packages: kismet - Wireless 802.11 monitoring tool The package appears to be lintian clean. The upload would fix these bugs: 530111, 558773, 572593 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/k/kismet - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/k/kismet/kismet_2010-07-R1-4.2.dsc I would be glad if someone uploaded this package for me. PS: I CC'ed the last uploader and the maintainer Kind regards signature.asc Description: Digital signature
RFS: plasma-widget-cwp (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.1.1-1 of my package plasma-widget-cwp. It builds these binary packages: plasma-widget-cwp - Customizable Weather Plasmoid (CWP) 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/plasma-widget-cwp - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/plasma-widget-cwp/plasma-widget-cwp_1.1.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards Boris -- 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/e1odtbc-00051h-00.tehnick-8-mail...@foot.mail.ru
Re: conflicts/replaces/provides vs. breaks/replaces/provides under policy 3.9.1
Osamu Aoki os...@debian.org writes: Under this new situation, I would like to confirm what is the best practice for each case scenario. Please comment on my thought as below: = Case 1: only one package rule install only one package out of packages providing a common virtual package. | Package: one-of-package-providing-virtual-package | Conflicts: virtual-package | Provides: virtual-package | Replaces: virtual-package Question: Please confirm this is still correct. This is still correct if the virtual package has requirements that cannot be satisfied by more than one package at the same time (such as all providers of that virtual package needing to install a file with the same path, as is the case for mail-transport-agent). Of course, the ideal is for providers of a virtual package to not conflict with each other at all and be co-installable, but that isn't always possible. = Case 2: package transition rule All the contents of the package foo is incorporated by bar in new 1.0 version and foo 1.0 became a transitional package with no real contents which can be removed safely. Please note pre-1.0 version of foo was not a transitional package. | Package: foo | Version: 1.0 | Description: ... | This is a transitional package for foo, and can be safely removed | after the installation is complete. | Package: bar | Version: 1.0 | Breaks: foo ( 1.0 ) | Replaces: foo ( 1.0 ) | Provides: foo Question: Is this right? Yes. Do we need ( 1.0 ) for replaces? You don't strictly need it, but I think it's cleaner, since it catches mistakes (such as not properly removing the transitioned files from foo). = Case 2': package transition rule After stable release with case 2, you wish to remove the transitional package foo upon upgrade to unstable/testing/next-stable. I guess we do not package Package: foo at this moment when uploading. Question: Is there sure way to purge the old transitional package foo? I'm dubious that even attempting to do this is a good idea. I wouldn't bother. -- 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/87r5iqxb44@windlord.stanford.edu
Local mentorship: Philadelphia + Boston
Hey all, I wonder -- are there any Debian mentees in the Philadelphia or Boston areas? I currently live in Philly and am moving to Somerville (near Boston) in September. I've found it difficult to consistently mentor and sponsor packages from people far away from me, but I think that if a mentee were able to meet up with me, we could have a very productive experience. So -- anyone in the Boston or Philly area? Drop me a note (on-list or off, either is fine). -- Asheesh. -- You would if you could but you can't so you won't. -- 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/alpine.deb.2.00.1007261847440@rose.makesad.us
