Bug#975594: RFS: capbattleship/1.0~alpha4-1 -- Sink your enemy before he gets you!
Le 24/11/2020 à 00:26, Paul Wise a écrit : On Mon, Nov 23, 2020 at 10:26 PM Fabien Givors wrote: capbattleship - Sink your enemy before he gets you! I would encourage you to use a more descriptive summary and also avoid non-inclusive language. I think the summary you used in the ITP was better for both of these suggestions. Oh, right, thanks. I should be more careful about that. I updated the short description, new version of the package should be there by now: dget -x https://mentors.debian.net/debian/pool/main/c/capbattleship/capbattleship_1.0~alpha4-2.dsc -- captnfab
Bug#975594: RFS: capbattleship/1.0~alpha4-1 -- Sink your enemy before he gets you!
Package: sponsorship-requests Severity: wishlist Dear all, I am looking for a sponsor for my package "capbattleship": * Package name: capbattleship Version : 1.0~alpha4-1 Upstream Author : Fabien Givors * URL : https://capbattleship.tuxfamily.org/ * License : CC0-1.0, CC-BY-4.0, MIT * Vcs : https://salsa.debian.org/captnfab-guest/capbattleship Section : games I wish to maintain this package inside the Debian Games Team. It builds those binary packages: capbattleship - Sink your enemy before he gets you! To access further information about this package, please visit the following URL: https://mentors.debian.net/package/capbattleship/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/capbattleship/capbattleship_1.0~alpha4-1.dsc Changes for the initial release: capbattleship (1.0~alpha4-1) unstable; urgency=medium . * Update to new upstream version 1.0~alpha4 * .desktop and icon now installed by upstream (via setup.py) Regards, -- captnfab
Re: Future of "obsession" package
On Sun, Nov 15, 2020 at 03:03:08PM +0100, Fabien Givors wrote: However, I found out that there were a sudden (yet relative) rise in popcon usage: https://qa.debian.org/popcon.php?package=obsession so, there are users… Le 15/11/2020 à 15:39, Andrey Rahmatullin a écrit : That's because openbox now Recommends it. Oh, ok, thanks Andrey, this explains that! I see different solutions: 1) remove xdg-autostart, recommend fbautostart 2) remove xdg-autostart, depends on fbautostart, add a wrapper for xdg-autostart to fbautostart 3) find an alternative to obsession-logout and obsession-exit binaries and replace obsession with a transition package What are your thoughts about that? Le 15/11/2020 à 15:29, Mateusz Łukasik a écrit : openbox-menu have or maybe I should use word had the same upstream author as obsession. Now I going to replace with jgmenu (see #882210) and remove openbox-menu from repository. At point 3 I think solution already exists in jgmenu. Second option is find magic exit script in super beauty openbox based distros like BunsenLabs Linux and port it to Debian. I see, so are you going to remove the Recommends for obsession from openbox package and replace it with jgmenu? And should I just ask for a RM of obsession? Or replace it with a transitional package recommending fbautostart and jgmenu? PS: I'm on the list -- fabien (captnfab on IRC)
Future of "obsession" package
Dear fellow debianists, I seek your advice. Years ago, with your help, I packaged "obsession" (for "openbox-session"), a tool intended to provide openbox (or other light WMs) with an xdg-autostart script and a GUI menu and CLI tool to easily disconnect/reboot/shutdown/etc. The package got uploaded thanks to a kind and patient DD. Since then, - upstream project got split in two halves (the xdg-autostart part, and the "menu" part) - which seems to have finally both disappeared - the xdg-autostart is buggy and does not comply with freedesktop.org specifications (#959922, #832980) - openbox now implements its own openbox-xdg-autostart script - there is a standalone fbautostart maintained by paultag doing the xdg-autostart job and respecting the specs - I've been busy and haven't took much care of this package :-( Now, I think that "obsession" would be a good candidate for removal, especially since it won't get any love from upstream. However, I found out that there were a sudden (yet relative) rise in popcon usage: https://qa.debian.org/popcon.php?package=obsession so, there are users… I don't want to become upstream for this package. I think that the xdg-autostart is not worth fixing. I see different solutions: 1) remove xdg-autostart, recommend fbautostart 2) remove xdg-autostart, depends on fbautostart, add a wrapper for xdg-autostart to fbautostart 3) find an alternative to obsession-logout and obsession-exit binaries and replace obsession with a transition package What are your thoughts about that? Thank you for your time, -- fabien
Bug#738920: RFS: obsession/20130822-1 [ITP] -- Session management helpers for lightweight desktop environments
Hi Eriberto, hi mentors, d/changelog: the initial realease is your first work in the package. So, d/changelog must have only 'Initial release (Closes: #731278)'. done. d/copyright: I suggest you put all licenses grouped at the end of the file. This will provide a better organization. done. d/docs: remove AUTHORS. The authors must be put in d/copyright only. done. My only definitive modifications were the creation of manpages. Since I forwarded them to upstream, I now add them with a patch. So, I removed the README.source d/rules: remove the unecessary comments, as '# -*- makefile -*-', '# Uncomment this to turn on verbose mode.' and '# This has to be exported to make some magic below work.'. I kept the emacs-line and removed the other comments. I also suggest you add '--parallel' to 'dh $@'. done. - two 'I' about hardening-no-fortify-functions. I admit I haven't tried to solve this one, but I'm sure tho CPPFLAGS are given to the C++ compiler. So I assumed it was a false-positive. This is the problem. :-) Generally, has a solution. Please, try here: https://wiki.debian.org/Hardening I made sure that the CPPFLAGS are given to the C and the C++ compilers, but the warning remains. Maybe a clue: the binaries produced are not PIE (but they have 'fortify source functions'). Thanks to recent emails on d-mentors (thx ekasper for asking and bmarc for answering), I learned that I could host a personal git repository thanks to my alioth account. So that's what I did, so I also started using git-buildpackage, and I added the Vcs-Git field in the control file. The up-to-date version of the package is here: https://mentors.debian.net/package/obsession If anyone has more comments, please tell me. Cheers, Fabien -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/530fe5f5.6070...@chezlefab.net
Bug#738920: RFS: obsession/20130822-1 [ITP] -- Session management helpers for lightweight desktop environments
Hi Eriberto, On 16/02/2014 13:24, Eriberto wrote: I checked your package. Note that I want help you improve your package but I can upload it. And that's much appreciated. My considerations: d/changelog: the initial realease is your first work in the package. So, d/changelog must have only 'Initial release (Closes: #731278)'. Ok, I suppose the changes I was mentioning in the changelog are to be put in the README.source. d/copyright: I suggest you put all licenses grouped at the end of the file. This will provide a better organization. Thank you, I wasn't even hoping such a thing could be DEP-5 compliant, but it is mentioned in section Stand-alone License Paragraph (Optional, Repeatable) I'm so unused to good standards… d/docs: remove AUTHORS. The authors must be put in d/copyright only. Ok. d/patches: replicate d/changelog parts in patches headers is unusual. Please, fix this. Ok (that's dpkg-source --commit works, I assumed it was good practice since the patches are related to the content of the changelog). But it indeed doesn't make much sense since there are other fields to add details into the patch. d/patches/copyright: is unusual fix the copyright notices in upstream code. I suggest to remove it. Ok. Anyway, the patch has been forwarded upstream, who told me he'll try to apply it ASAP. d/README.source: must be used to list modifications that you made, definitely, in the upstream source code. So that doesn't include patches or does it? d/rules: remove the unecessary comments, as '# -*- makefile -*-', '# Uncomment this to turn on verbose mode.' and '# This has to be exported to make some magic below work.'. I also suggest you add '--parallel' to 'dh $@'. Ok. Building, I can see some lintian warnings. Please, see http://eriberto.pro.br/blog/?p=1289 I've seen the remaining I and P issues (I'm always running lintian on both the source and the binary with options --pedantic --show-overrides --display-info --display-experimental --color auto -i): - one P about upstream changelog missing. I could try to dump git log« of his repository, but would that make the package better? - one P about sources not being gpg-checkable. I'm afraid I can't do much here. Except maybe asking upstream to sign his tarballs… Wouldn't that be a bit pedantic for a project hosted by bitbucket? - two I about hardening-no-fortify-functions. I admit I haven't tried to solve this one, but I'm sure tho CPPFLAGS are given to the C++ compiler. So I assumed it was a false-positive. I hope this help. It does. :) I'll upload a new version as soon as I'll have taken those remarks into account. Regards, -- captnfab -- 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/5300eb8c.5060...@chezlefab.net
Re: ITP: obsession 2013-08-22
Hi, Since melodie (the owner of the ITP) is a bit busy, she asked me if I could take care of the packaging. Here it is, lintian-clean and ready to be reviewed: - Mentors page: https://mentors.debian.net/package/obsession - DSC: http://mentors.debian.net/debian/pool/main/o/obsession/obsession_20130822-1.dsc As far as I understood, we might already have a sponsor for this package (mati75.) Thanks in advance for your help. -- Fabien (captnfab) signature.asc Description: OpenPGP digital signature
Re: ITP: obsession 2013-08-22
On 13/02/2014 21:59, Fabien Givors (Debian) wrote: Hi, Since melodie (the owner of the ITP) is a bit busy, she asked me if I could take care of the packaging. Here it is, lintian-clean and ready to be reviewed: - Mentors page: https://mentors.debian.net/package/obsession - DSC: http://mentors.debian.net/debian/pool/main/o/obsession/obsession_20130822-1.dsc As far as I understood, we might already have a sponsor for this package (mati75.) Ah, it looks like I got it wrong. Sorry mati75, I thought you were a DD. So I *am* looking for a sponsor (and willing to adopt the package) :) Thanks in advance for your help. -- 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/52fd44d0.3010...@chezlefab.net
Bug#738920: RFS: obsession/20130822-1 ITP:#731278
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package obsession * Package name: obsession Version : 20130822-1 Upstream Author : Fabrice Thiroux * URL : https://bitbucket.org/fabriceT/obsession/overview * License : GPL3 (code), LGPL3 (graphics), GPL2+ (package) Section : x11 It builds this binary package: obsession - Session management helpers for light desktop environments To access further information about this package, please visit the following URL: http://mentors.debian.net/package/obsession Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/o/obsession/obsession_20130822-1.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: * Initial release (Closes: #731278) * Adding menu file * Patches fixing Makefile Regards, Fabien Givors (captnfab) -- 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/52fd4680.7090...@chezlefab.net
Re: Packaging for multiarch i386 sse2/non-sse2
Le 19/08/2013 03:05, Wookey a écrit : +++ Henrique de Moraes Holschuh [2013-08-18 21:39 -0300]: On Sun, 18 Aug 2013, Adam Borowski wrote: C - ship both versions on i386 and switch between them on runtime The linker can select at runtime different sets of libraries depending on some cpu flags. I think it can do that for SSE2 just fine, you'd build two libs: one without interesting intructions, and other with them, and place them/name them appropriately for that to work, all in the same binary package. Right, but be careful not to confuse this functionality with multiarch. It's called 'multilib'. They both do essentially the same job (selecting libraries to load by paths), but with different paths/layouts and selection mechanisms. Multiarch paths are one per 'arch', which normally means an ABI, not an ISA. multilib paths form a matrix of all possible options so rapidly get out of hand if you have more than a couple. Oh, ok, thanks for pointing out the difference between multilib and multiarch. Things get clearer now. I think the glibc package does that, you might want to take a look at it. Various packages in debian illustrate the techniques for packaging multiple ISA flavours. (mplayer, eglibc). I'm not sure that any of them use multilib paths to do this - they just use package naming so you choose whether to install 'libc6' or 'libc6-i686' (in the same paths). They are alternatives, not something than can be installed side by side in multilib locations and selected at runtime by the linker. (I haven't actually checked the package contents to confirm this). Things could be packaged using multilib locations if you thought it was worth the effort. I had a look to eglibc source package. I can tell some dark magic is at work in this package. But as I need only a small fragment of it, I'll probably be able to extract it. The result would be a lib package on all architectures, with sse2 enabled only on amd64 arch, and a lib-sse2 package, recommended by lib, only present on i386 arch. The good news for me being that I can easily prepare a first version of the package without multilib, and add the -sse2 version later without breaking anything. Thank you all for your help! -- fabien -- 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/5211e5f2.5060...@chezlefab.net
Packaging for multiarch i386 sse2/non-sse2
Dear mentors, I'm trying to package a toolkit library for developing video games [1] [2]. As this can be expected, this library rely on sse2 instruction set. However, most of the features (except for software video rendering) are available (sometimes in a degraded mode, eg. the sound part might be slower) for non-sse2-capable hardware. Should I preferably: A - build a lib-without-sse2 package on all but amd64 architectures and a lib-with-sse2 package on i386 and amd64 architectures ? B - build a lib package on all architectures which will be build with sse2 options on amd64, with non-sse2 on all except i386 and amd64 and with both versions on i386 (I've heard that multiarch permits to ship both versions so that ld chose the right one at runtime) C - your solution here Solution B may seem more elegant at first, but is much more complicated to package (ok, that's not an excuse). On top of that, it builds a package that doesn't provide exactly the same features/symbols depending on the architecture. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602463 [2] http://clanlib.org/ Thank you for in advance your advices, -- fabien -- 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/521130f0.4070...@chezlefab.net
RFS: libclanlib2.2
Dear mentors, I am looking for a sponsor for my package libclanlib2.2. * Package name: libclanlib2.2 Version : 2.2.4-1.4 Upstream Author : The ClanLib Team deb...@clanlib.org * URL : http://clanlib.org/ * License : BSD style licence Section : libs It builds these binary packages: libclanlib2.2 - ClanLib 2.2 game SDK runtime libclanlib2.2-dev - ClanLib 2.2 game SDK development files libclanlib2.2-doc - Reference documentation and tutorials for ClanLib 2.2 The package appears to be lintian clean. The package appears to build cleanly with pbuilder on amd64. The upload would fix these bugs: 570884 My motivation for maintaining this package is: - I've used this library for developing small programs (games) and have some programming abilities in the language it's written in (C++) - I've been in touch with the developers for half a year now, they are really active and provides useful support. - There are users of this muti-platform library. But Debian users often choose the old 1.0 deprecated version since the newer 2.2 is not packaged yet (bug 570884). - I'd like to get more experience in package creation / maintenance (this is my first package). The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libclanlib2.2 - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libclanlib2.2/libclanlib2.2_2.2.4-1.4.dsc I would be glad if someone uploaded this package for me. Kind regards Fabien Givors -- 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/4cd034a1.8060...@chezlefab.net
Re: RFS: libclanlib2.2
Le 02/11/2010 17:36, Scott Howard a écrit : On Tue, Nov 2, 2010 at 11:56 AM, Givors Fabien fabien.giv...@chezlefab.net wrote: Dear mentors, I am looking for a sponsor for my package libclanlib2.2. I'll try to take a look at the package for non-DD review later - but I also wanted to point out the debian games team [1] who can also sponsor this package [2]. You could probably contact them as well to find a sponsor [3]. Thanks for your work, it looks like an interesting and useful library. Thanks for your reply, I'm going to send my RFS on their mailing list. :) regards, -- fabien signature.asc Description: OpenPGP digital signature
Re: RFS: libclanlib2.2
Le 03/11/2010 01:08, Scott Howard a écrit : Hello, On Tue, Nov 2, 2010 at 11:56 AM, Givors Fabien fabien.giv...@chezlefab.net wrote: Dear mentors, I am looking for a sponsor for my package libclanlib2.2. Non-DD review: […] Whoo ! Many thanks for the review. I already learned many things just reading it :) For now, I'll try to fix the issues you spotted and to contact the maintainers of the previous lib. regards, -- fabien signature.asc Description: OpenPGP digital signature
Re: New package : aodv-uu / looking for a mentor
Hi Fabien, On Saturday 30 August 2008 02:15, Fabien Cellier wrote: This is a routing protocol based on RFC3561 for Ad-Hoc networks. This implementation seems to be the best available. (Why) do you think it is the best protocol for ad-hoc networks? Or do you mean this program is the best implemenatation of rfc3561? Hi, and thank you for your answer ! I mean that it *could* be the best implementation of rfc3561. Well, when I was searching the web for information about it (few month ago), this was the impression I had. What is the largest scale (test) setup which has been done with aodv-uu/rfc3561? /seriously curious I cannot answer this. I personally used it successfully with 3 computers. For largest scale test, please refer to upstream author. http://core.it.uu.se/core/index.php/AODV-UU It must have been tested by some other universities as well. There is an IPv6 patch provided by the University of Buckingham, for example. I think it would be a good idea to make it available for every Debian users. Probably, yes. But we are in a freeze atm, so no new packages are possible. That's also why I'm currently not interested in sponsoring aodv-uu, I rather concentrate on fixing release related stuff. Sorry :-) I thought it could go to unstable in the meanwhile. Anyway, releasing lenny is more important, and this package is not something critical. This can wait a little, and be sponsored after the lenny rush, don't you think ? :) Please CC me on your answer. Done. (No need to cc: me, I read [EMAIL PROTECTED]) Thanks. And I won't cc: you, I promise. :D Regards, Fabien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New package : aodv-uu / looking for a mentor
Stefan Ott a écrit : On Saturday 30 August 2008 02:15, Fabien Cellier wrote: This is a routing protocol based on RFC3561 for Ad-Hoc networks. This implementation seems to be the best available. (Why) do you think it is the best protocol for ad-hoc networks? Or do you mean this program is the best implemenatation of rfc3561? Hi, and thank you for your answer ! I mean that it *could* be the best implementation of rfc3561. Well, when I was searching the web for information about it (few month ago), this was the impression I had. AFAIK aodv-uu doesn't run with recent kernels (2.6.22) - or was that fixed? Damn, it seems you're right. I just tried on a 2.6.25 kernel, but it does not compile. Well, I suppose this delays everything... Fabien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New package : aodv-uu / looking for a mentor
Hello, I packaged the aodv-uu software (Ad-hoc On-demand Distance Vector Routing) for my own needs. Here is the official project page : http://core.it.uu.se/core/index.php/AODV-UU This is a routing protocol based on RFC3561 for Ad-Hoc networks. This implementation seems to be the best available. Aodv share the same goal as olsrd, even if the technique used is very different. This is why Holger Levsen (olsrd maintener) is on copy (hello). I think it would be a good idea to make it available for every Debian users. The binaries for Etch i386, and the source package (which builds on Lenny) are both available from my repository (on my quite slow connection) : http://debian.azertyfab.net/pool/main/a/aodv-uu/ This is the last upstream version. There is two binary packages : - aodvd-uu : the daemon, - aodv-uu-source : the kernel module source for module-assistant I am thus looking for a mentor/sponsor to publish this package into Debian. Holger? :) Please CC me on your answer. Cheers, Fabien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New package : aodv-uu / looking for a mentor
Hello again, I just managed to upload my aodv-uu package on mentors.debian.net. I also picked up the magic template : From: Fabien Cellier [EMAIL PROTECTED] To: debian-mentors@lists.debian.org Subject: RFS: aodv-uu Dear mentors, I am looking for a sponsor for my package aodv-uu. * Package name: aodv-uu Version : 0.9.5 Upstream Author : [Erik Nordström [EMAIL PROTECTED]] * URL : [http://core.it.uu.se/core/index.php/AODV-UU] * License : [GPL] Section : main/net It builds these binary packages: aodv-uu-source - Source for the aodv-uu kernel module aodvd-uu - Ad-hoc On-demand Distance Vector Routing daemon (aodvd) The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/aodv-uu - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/aodv-uu/aodv-uu_0.9.5.dsc I would be glad if someone uploaded this package for me. Kind regards Fabien Cellier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving files and Conflicts/Replaces
On Fri, Oct 08, 1999 at 01:24:34PM -0700, Sean 'Shaleh' Perry wrote: On 08-Oct-99 David Coe wrote: Ben Darnell [EMAIL PROTECTED] writes: [...] In the previous package, a tcl script was left in the pilot-link package, which made it depend on tcl/tk and therefore X. I want to move this file to pilot-link-tcl, and have done so by placing the filename in debian/pilot-link-tcl.files. The problem is that when I upgrade to the new packages, the installation of pilot-link-tcl fails unless the new pilot-link has already been installed, because the script exists in both the old pilot-link and the new pilot-link-tcl. [...] I *think* if you say ``Replaces: pliot-link'' (but not Conflicts:) in pilot-link-tcl, it'll allow pilot-link to replace some of the other package's files. You want to do a version replaces. 'Replaces: pilot-link ( 0.9.1)'. I think this part aren't clear around. For me, the solutions would be: Package: pilot-link Version: 0.9.1-2 Suggests: pilot-link-tcl [because it's a good add-on to pilot-link] Package: pilot-link-tcl Version: 0.9.1-2 Conflicts: pilot-link ( 0.9.1-2) [because older ones share the same file] Replaces: pilot-link ( 0.9.1-2) [because it provides some functionnality of the old one]. Consequences: pilot-link-tcl is selected because of the Replaces, pilot-link is upgraded because of the Conflicts, pilot-link-tcl is installed and everyone is happy. However, for a two packages who just exchange some files (examples, some file moving pack to pack-doc, pack-doc being an already existing package). Package: packA Version: with.no.file-new [ can also Suggests: packA-doc but it's not mandatory ] Package: packA-doc Version: with.file-new Conflicts: packA-doc ( with.no.file-new) [because of the shared files] [ But no replaces since packA-doc doesn't replaces any functionnality from packA ] I think (no test) that adding a Replaces on this case will install packA-doc (with.file-new) even if it's not installed before the upgrade. Not putting it just make want the user want: upgrade packA, period. All IMHO. I would really appreciate if someone can point me to some more detailed explanation (maybe I misread the packaging-manual?). Thanks, -- Fabien NinolesChevalier servant de la Dame Catherine des Rosiers aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer E-mail:[EMAIL PROTECTED] WebPage:http://www.tzone.org/~fabien RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
VRweb Sponsor upload.
I sponsor a courageous future new maintainer, namely Paul Harris, to take over my vrweb package (I said you he's courageous ;) It's already does a very good job by making it compiled under slink and potato (a bug that I have for almost a year now) and I would like to upload the new package now. I already made some corrections but the package run quite well. How I do this so? Do I upload a package with his name but sign with my key? Do I make a new upload with my name and my key? Do I simply upload it with his name and key (after sending the key to new-maintainer)? I also already ask him their intentions about being a developper in Debian. He seems a quite reasonable person to me, preferring quality over quantity (which is so rare those day ;). He should soon contact a current developper in Australia to sign is GPG key. Should I wait for the signed key before doing any move? Security is not a concern since I audit all the patches he submits to me and I can sign the whole package. So, any indications about how to do it? Thanks, -- Fabien NinolesChevalier servant de la Dame Catherine des Rosiers aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer E-mail:[EMAIL PROTECTED] WebPage:http://www.tzone.org/~fabien RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Re: Little FAQ for users and maintainers
On Sat, Oct 02, 1999 at 12:56:56PM -0700, Joseph Carter wrote: On Fri, Oct 01, 1999 at 09:18:41AM -0400, Fabien Ninoles wrote: Conflicts: foo ( new-version) And don't forget Replaces: foo ( new-version), that's what it's there for---files moving from one package to another! Oups! yes but only in the second part of the mail (where foo no more exists). When foo still exist, Replaces must NOT be used! Often, this happen when a single binary source package became a multi-binaries source package: the maintainer forget to add a Conflict to the new package against the old one (who still exists!). Exemple: foo (1.0-1) became foo (1.0-2) and foo-doc (1.0-2) because foo-doc contains some files in foo (1.0-1), it must have: Conflicts: foo ( 1.0-2) and possibly Suggests: foo (1.0-2) but no Replaces since we still want foo (1.0-2) be installed. At least, that's the way I understand it (your versioning of replaces make me doubt a little; if we add the Replaces field as you suggest, what foo (1.0-2) dependencies will be?). -- Joseph Carter [EMAIL PROTECTED] Debian GNU/Linux developer GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77 8E E2 29 96 C9 44 5F BE -- * joeyh cvs commits his home directory. Aa drow eeek drow joeyh: That is simply evil. Period. -- Fabien NinolesChevalier servant de la Dame Catherine des Rosiers aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer E-mail:[EMAIL PROTECTED] WebPage:http://www.tzone.org/~fabien RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Re: Little FAQ for users and maintainers
On Fri, Oct 01, 1999 at 11:36:25PM -0600, Jason Gunthorpe wrote:
On Fri, 1 Oct 1999, Fabien Ninoles wrote:
Many time, apt-get break on conflicting files. It happens me often
on unstable but also when upgrading from slink to potato. Here some
recommendations to help users resolved the conflicts and also to
help maintainers do the Right Things (TM) the first time.
I assume you mean file conflicts. I generally recommend adding this to
/etc/apt/apt.conf
dpkg::options {--force-overwrite;};
And use an 0.3 version of APT. Of course you should file bugs when you see
the warning ;
Jason
We could add this to the FAQ. For me, I'll stay with this option since
it lets me find those bugs without having to keep looking at each
installation. I happily upgrade my machine each night through apt-get :)
--
Fabien NinolesChevalier servant de la Dame Catherine des Rosiers
aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer
E-mail:[EMAIL PROTECTED]
WebPage:http://www.tzone.org/~fabien
RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Little FAQ for users and maintainers
Mail cross-postoned, please, remove the debian-devel list before sending back Many time, apt-get break on conflicting files. It happens me often on unstable but also when upgrading from slink to potato. Here some recommendations to help users resolved the conflicts and also to help maintainers do the Right Things (TM) the first time. Should we consider building a debian-mentors FAQ for things like this? - For users: When a conflict occurs, try to run apt-get -f install several time until all conflict are removed or no more packages can be install without conflicting somewhere else. Sometime it takes more than one turn to apt-get to correct those packages. Also, take in note the conflicting packages and report them to the BTS under the package one you was trying to install or upgrade. This will help to improve the overall quality of Debian. For maintainers: Moving files from one package to another. Supposed that you move a file from Package foo to Package bar. If Package foo still existed, Package bar should included a Conflicts reading this way: Conflicts: foo ( new-version) where new-version is the version of the Package foo who has the conflicting file removed. If foo is removed, you should change it to Conflicts: foo or Conflicts: foo (= old-version) where old-version is the latest version of foo. This last one don't handle local package in the form of foo old-version.1 (that's the recommended way to do local NMU) and that's why it should be avoid when possible. -- Fabien NinolesChevalier servant de la Dame Catherine des Rosiers aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer E-mail:[EMAIL PROTECTED] WebPage:http://www.tzone.org/~fabien RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Re: vrweb, newbie maintainer/developer
goal with vrweb is to keep it working... i don't forsee another release of vrweb anyway. now, i am looking for more packages to support. i won't support a package for the sake of being a maintainer, i have to use the program. I am currently looking at xldlas, a statistics program that may be removed soon because of license problems (i'll talk to -devel about that). i saw it on the orphaned list, checked it out and found it useful for my future project :) i also want to fix those segfaults that occasionally pop up. That the way I started. So I can't disagree ;) Good luck with xldlas. License things are always delicate (that's a word for word translation, not sure if it's the right expression). Ask for some help on debian-legal if you feel it. What I really want here is to present you the opportunities of Debian. Working for Debian isn't just packaging some cool software. It can be really more than that, and most of the stuff is even more exciting than package maintenance. i'd like to get involved with that stuff, but i think i'll slowly increase my involvement rather than dive-bombing the rest of you in the deep end of development (so to speak). I agree with you. Maintain a few good packages rather than many medium one. I also want you to know that your job as a package maintainer isn't finish when you upload your package. You have to support it after that (that's where I failed with vrweb :( ). i figure a package like vrweb won't take too much support from now on anyway. i'll be able to handle it. Until the next libstdc++ transition ;) Hopefully, this time, there are a standard. That's mean following at least the debian-devel-announce mailing list (really low volume), update your package when new version on the dependencies appears, answer to bugs reports, give some (limited) support to users who ask you, and ensure that your package still follow the current Policy. to answer thos: - have been following -devel for the last month. - will check the web page from time to time for new version. - bring on the bugs! - will listen on the weekly news for those changes. Well, you catch quickly ;) Finally, one little warning: As a Debian Maintainer, you'll be given a new e-mail address @debian.org and some accounts on different machines around the world. Does machine and bandwidth are given by donators to Debian absolutely free of charge. Don't abuse those gifts and try to use it solely for Debian-related purposes. It's not mandatory but some maintainers have seen there rights as maintainer remove already in the past for such things and we don't want to be seen as a bunch of donators' abusers (sorry, can explain it more clearly). i hope to use the @debian.org to get a job, especially while i'm in transition from university to home to university to working-world. if i do use it, it'll be _really_ low volume, as a backup email address so i can then tell people my new/current email address. You can even used it as your default e-mail address, lots of maintainer do it. E-mail aren't often the problem. Disk space and ftp bandwidth are, especially when people used it to distributed warez. Debian is for Free Software but not of this kind ;) So I wait for your patches, check it ASAP (sorry, I have to write down a conference I'll give for next monday so I'll be quite busy during the next week or so; please, be patient) and upload it to master. I'll give some feedbacks about it as soon as it done. On your side, try to make your public key sign by one of the Debian Maintainer in your region. You have to meet them in person with some valid ID so they can said Yes, this guy is really Paul Harris as he pretended to be. It's important to preserve the integrety of the key ring. Voila! looks like we are done :) If you can't make it good, make it look good. Bill Gates, 1995 Debian GNU/Linux: We make good, and we make it look good. ... whatever your taste! Regards, -- Fabien NinolesChevalier servant de la Dame Catherine des Rosiers aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer E-mail:[EMAIL PROTECTED] WebPage:http://www.tzone.org/~fabien RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Re: vrweb, newbie maintainer/developer
;)
Also, the sponsor help to speed up things by verifying the new package
and uploading it himself in the name of the new maintainer (you have
to be a maintainer to upload a package). So, can you send me your patches
that I can check them? I can even upload it before you get your account
if it's your desire.
i'll send them once i figure out this gpg thing, i'd like to get at least
one person to sign my key. also, do you know what keyserver i'm supposed
to upload my public key to?
You have to send it to the new maintainer when it'll be sign by Dave.
i'm just going to wait and see if i can meet with Dave Cook for him to
sign my fresh gpg key (he's in perth somewhere nearby).
Send it to me right after you make it sign by Dave. I will send it
to [EMAIL PROTECTED] with my recommendations. However, here
also some questions about your application. It's easy questions and
don't need strong answer. (I mean, Debian doesn't need you to be a
full activist of the OpenSource/FreeSoftware movement. Just that you
understand that's it's one of our goal and that you'll be part of it.
Debian is not a political movement, just an organization build under
the OpenSource philosophy.) I hope to don't seem too much
authorative but it's real hard when it's not even your first
language.
So, first, have you read the Debian Social Contract (if not, do it ;)?
Do you understand it? What do you think about it? I'll be please to
answer any questions about it.
What's your future goals with Debian? Do you want to participate
more actively to Debian, push up more packages or simply maintain
your current package? What I really want here is to present you
the opportunities of Debian. Working for Debian isn't just packaging
some cool software. It can be really more than that, and most of the
stuff is even more exciting than package maintenance. I also want you
to know that your job as a package maintainer isn't finish when you
upload your package. You have to support it after that (that's where
I failed with vrweb :( ). That's mean following at least the
debian-devel-announce mailing list (really low volume), update your
package when new version on the dependencies appears, answer to
bugs reports, give some (limited) support to users who ask you,
and ensure that your package still follow the current Policy.
Finally, one little warning: As a Debian Maintainer, you'll be
given a new e-mail address @debian.org and some accounts on
different machines around the world. Does machine and bandwidth
are given by donators to Debian absolutely free of charge. Don't
abuse those gifts and try to use it solely for Debian-related
purposes. It's not mandatory but some maintainers have seen there
rights as maintainer remove already in the past for such things
and we don't want to be seen as a bunch of donators' abusers
(sorry, can explain it more clearly).
Voila!
Give me some news!
Fabien
{ happy to see this embarrassing bugs finally closed! ;) }
almost there! so close!
Paul
(happy to fix these bugs!)
If you can't make it good, make it look good.
Bill Gates, 1995
Regards,
--
Fabien NinolesChevalier servant de la Dame Catherine des Rosiers
aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer
E-mail:[EMAIL PROTECTED]
WebPage:http://www.tzone.org/~fabien
RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Re: vrweb, newbie maintainer/developer
On Wed, Sep 22, 1999 at 03:13:03PM +0800, Paul Harris wrote:
hi,
i have agreed to take VRweb off Fabien Ninoles' hands, and have been
successful in making it work under my Potato system! woo hoo!
however, i have no idea what the next steps are:
- What is the technique to rediff a package for the debian diff?
apply the diff on the source manually than update the control and the
changelog files and make a 'dpkg-buildpackage -rfakeroot'. It should
work (my rules file used some debhelper scripts which is useful to stay
policy compliant).
Be sure also to send the patches to upstream!
- Why is dpkg-source complaining about:
$ dpkg-source -x vrweb_1.5-2.dsc
dpkg-source: error: Expected ^@@ in line 679 of diff
is this some sort of bug? seemed to work earlier... i just untared and
patched it myself
The diff dpkg-source wait for is one produce by the build process (is
not a custom one except that the paths are fixed). Just apply them manually
and update the debian/changelog file appropriately using dch or the
debbian-changelog mode of emacs.
- Where are the FMs on the debian/rules stuff? I'd just like to make sure
it works after i get that diff thing going.
You should install debian-policy packaging-manual and read the Developper
Corner of the web pages.
- How do I accept vrweb as mine? Do I need to get a sponser or something?
I can be your sponsor seens you're not a maintainer. It'll be your when
you upload it under your name. Please, contact me. I can give more
details.
- How do I wack it on the debian mirror and all that?
dupload do the work when you're a maintainer.
also, on the other bugs mentioned in the buglist, i would like to see
something like freewrl working, as vrweb is just too big and clunky. it
may be helpful as a reference but i think a new program should be
developed that uses existing stuff like perl, gtk/qt and perl, but doesn't
have to be statically linked. (i haven't looked at freewrl yet).
talk to the freewrl maintainer. You certainly be some help for him.
consequently my aim for vrweb is to just get it to work, i am not aiming
to improve it (thats for upstream people). but would it be worthwhile to
look at fixing bug #29078: package vrweb depends on library libg++272. is
this really a bad thing? surely there are better vrml viewers out there?
The bug seems to be fixes. In the changelog entry, add a 'Closes: #29078'
anywhere. The bug will be automatically closed when the package will be
uploaded.
anyway, i'm looking forward to sumbitting a working version of vrweb, so
let me know about the proper procedures soon please! thanks!
First, please, read the FM and web pages. A new, non-official procedure
to help reducing the load of new-maintainer is to be sponsored by a current
maintainer. I'm willing and will be happy to do this for you :) Please,
read a little more and the contact me for any question. I'll contact you
again if you have any other questions.
Also, the sponsor help to speed up things by verifying the new package
and uploading it himself in the name of the new maintainer (you have
to be a maintainer to upload a package). So, can you send me your patches
that I can check them? I can even upload it before you get your account
if it's your desire.
Paul Harris
Give me some news!
Fabien
{ happy to see this embarrassing bugs finally closed! ;) }
--
Fabien NinolesChevalier servant de la Dame Catherine des Rosiers
aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer
E-mail:[EMAIL PROTECTED]
WebPage:http://www.tzone.org/~fabien
RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Debian-JP and Debian package.
Hi, I just want to know what happen between Debian-JP (http://www.debian.or.jp) and Debian. I just discover their distribution a week ago because I'm maintaining a new package for learning kanji (the japanese characters) and, asking the upstream maintainer of one of the dictionnary, he just points me out to their pages where the kaji dictionnary is already maintain. However, KDrill (my package), aren't maintain and is quite a good programs that I would like to maintain. How can I do that? Make a new kanjidic package for the main distribution of debian? Moving the kanjidic package from Debian-JP to Debian? Uploading the KDrill package to Debian-JP (I'm still a beginner in Japanese, not even knowing how to say my age, so is quite difficult for me to be a Debian-JP maintainer). BTW, I'm running now lot of Debian-JP packages now and I'm really impressed by their distribution. Shouldn't they merit to have more of them available directly in the main sites? FreeBSD already has a lot of supports for internationalization, and the author of linux- nihongo (an excellent document about getting Japanese on Linux) consider Debian-JP has the most supported Japanese Distribution. We should be a little more proud of it and work more closely with them. Just my 2 pennies, -- Fabien Ninoles GULUS founder aka Corbeau aka le Veneur Gris Debian GNU/Linux maintainer E-mail:[EMAIL PROTECTED] WebPage: http://www.callisto.si.usherb.ca/~94246757 RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
Re: non-pristine sources
On Tue, Apr 21, 1998 at 06:22:30PM -0400, Bob Hilliard wrote: One of the dictionary packages I am preparing for use with the dictd server is distributed as two separate .tar.gz files, so I will have to make a combined file as _orig.tar.gz. Do I have to ask for permission to use non-pristine sources in such a case? Another dictionary package contains formatting software and datbases for five dictionaries in the upstream tarball. One of these dictionaries - The Free On-Line Dictionary of Computing (foldoc) -is updated almost daily, but the source package is not. I intend to remove foldoc from the upstream package, leaving a non-pristine source for the remaining four dictionaries, and create another source package for foldoc, which I expect to update frequently. Do I have to ask for permission to do this? Bob -- _ |_) _ |_ Robert D. Hilliard[EMAIL PROTECTED] |_) (_) |_) Palm City, FL USAPGP Key ID: A8E40EB9 I think you can consider using the get-orig-source target to make your modification, some time, upstream archive just need a little workout to remove all the unnecessary stuff in it. -- Fabien Ninoles Running Debian/GNU Linux E-mail:[EMAIL PROTECTED] WebPage: http://www.callisto.si.usherb.ca/~94246757 WorkStation [available when connected!]: http://nightbird.tzone.org/ RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70 pgpJtiK2Ww8MK.pgp Description: PGP signature
