Re: RFS: gwibber
On Tue, Jun 30, 2009 at 4:08 PM, Filip Chabikdeb...@hadret.com wrote: I dunno why they didn't showed up on my PC :/ Just run: lintian -iIEvXc --pedantic *.changes Lintian will give enough information to solve each point. -- Cheers, Kartik Mistry | 0xD1028C8D | IRC: kart_ Debian GNU/Linux Developer Blog.en: ftbfs.wordpress.com Blog.gu: kartikm.wordpress.com -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: gwibber
Dnia 2009-06-30, wto o godzinie 09:44 +0530, Kartik Mistry pisze: I will love if you also fix following: I dunno why they didn't showed up on my PC :/ W: gwibber: binary-without-manpage usr/bin/gwibber I'll made use of gwibber.1 provided in upstream as You suggested :) I: gwibber source: debian-watch-file-is-missing I'd love to do that, but I don't know how can I provide such file when bzr branch is used? Is there any manual about it available? I: gwibber: package-contains-empty-directory usr/share/omf/gwibber/ I don't know how I can change this one -- I guess it's gwibber own bug, is it? I: gwibber: copyright-with-old-dh-make-debian-copyright Will fix that in new release :) I: gwibber: extended-description-is-probably-too-short Will fix that in new release :) P: gwibber: copyright-refers-to-symlink-license usr/share/common-licenses/GPL Will fix that in new release :) P: gwibber source: source-contains-bzr-control-dir .bzr It shouldn't be there, in debian/rules there's this line [1]. I will fix that in new release :) P: gwibber: no-upstream-changelog You can ask upstream to provide Changelog or NEWS file(s). I already asked, I'm waiting for answer from Ryan Paul. I: gwibber: arch-dep-package-has-big-usr-share 1316kB 97% I don't know how I can change that one too :( Thank You for your time, and sorry for my inconvenience. [1] cd $(TMP_DIR) tar zcf ../$(DEBIAN_NAME)_$(VERSION).orig.tar.gz --exclude=.bzr $(DEBIAN_NAME)-$(VERSION) -- Filip Chabik deb...@hadret.com -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: gwibber
On Tue, Jun 30, 2009 at 4:08 PM, Filip Chabikdeb...@hadret.com wrote: I: gwibber source: debian-watch-file-is-missing I'd love to do that, but I don't know how can I provide such file when bzr branch is used? Is there any manual about it available? Fine. You can ask upstream to provide 'download' tarballs at some point of time. I: gwibber: package-contains-empty-directory usr/share/omf/gwibber/ I don't know how I can change this one -- I guess it's gwibber own bug, is it? Just remove empty directory. P: gwibber source: source-contains-bzr-control-dir .bzr It shouldn't be there, in debian/rules there's this line [1]. I will fix that in new release :) Thanks. P: gwibber: no-upstream-changelog You can ask upstream to provide Changelog or NEWS file(s). I already asked, I'm waiting for answer from Ryan Paul. Good! I: gwibber: arch-dep-package-has-big-usr-share 1316kB 97% I don't know how I can change that one too :( Splitting package gwibber and gwibber-common is solution. Thank You for your time, and sorry for my inconvenience. Thanks a lot for packaging and contribution to Debian! -- Cheers, Kartik Mistry | 0xD1028C8D | IRC: kart_ Debian GNU/Linux Developer Blog.en: ftbfs.wordpress.com Blog.gu: kartikm.wordpress.com -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: gwibber
[Filip Chabik, 2009-06-30] http://mentors.debian.net/debian/pool/main/g/gwibber/gwibber_1.2.0+bzr346-2.dsc few additional comments: * use python-support instead of python-central if you want to join PAPT[1] at some point * Architecture should be all not any - some build dependencies can be moved to Build-Depends-Indep - replace python-all-dev with python (= 2.5) * remove python2.5 from Build-Depends and make sure /usr/bin/gwibber's shebang is set correctly * remove Encoding field from desktop file (all desktop files should be encoded in UTF-8) * move postinst content do debian/rules (hint: dh_link) * remove postrm (if it's really needed, there's a bug somewhere) * provide get-orig-source rule (and use bzr's export command) [1] http://python-apps.alioth.debian.org/policy.html -- http://people.debian.org/~piotr/sponsor -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
deal with autoreconf -i
Hi, What is the smart way to deal with the package that uses autoreconf -i? If I just package it, direct source change would be added to diff.gz, and cannot rebuild it by error. Which package/article is good example for that? Please let me know about it. Thanks. -- Regards, Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp http://wiki.debian.org/HidekiYamane -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deal with autoreconf -i
On Tue, Jun 30, 2009 at 9:46 PM, Hideki Yamanehenr...@debian.or.jp wrote: What is the smart way to deal with the package that uses autoreconf -i? If I just package it, direct source change would be added to diff.gz, and cannot rebuild it by error. Teach upstream to use automake's 'make dist' feature. If they won't co-operate, use 'make maintainer-clean' to clean up instead of 'make distclean'. Look for packages build-depending on autoconf if you want to find examples. -- 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
Re: deal with autoreconf -i
Hi, On Tue, 30 Jun 2009 21:51:23 +0800 Paul Wise p...@debian.org wrote: Teach upstream to use automake's 'make dist' feature. If they won't co-operate, use 'make maintainer-clean' to clean up instead of 'make distclean'. Look for packages build-depending on autoconf if you want to find examples. Great thanks! :) I'll do so. -- Regards, Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp http://wiki.debian.org/HidekiYamane -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
non-native package versions
Hi :-) Before nothing, sorry for my mistakes about mount-systray ackage and the native and non-native packages. Your comments and the mentor's FAQ help me a lot. Well, I have one doubt about the version. What I understand from the policy[1] is that for the package mount-systray, the version should be something like: mount-systray-0.5.3-1 uptream version = 0.5.3 debian version = 1 But then lintian tells me I need a *.orig.tgz (which I haven't) or if I created a *.orig directory, then tells me the diff is empty and so on. I (or actually we - Guadalinex team) am upstream and we maintain the code with the debian files all together. I know that it's better not to do that and separate the code and the debian files, but, at least by now, we have that way. The thing is if I put the version like 'mount-systray-0.5.3debian1', which I have seen in some packages, lintian doesn't say a word. My question is, what is the difference between both version ways? And also a kind of retorical one (I guess I know already the answer...), do I really need to separate the app code from the debian packaging files? isn't there another option? I guess we'll have to slit them :-/ Thanks in advance for your time and your anwsers :-) Cheers [1] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version -- Juanje -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: non-native package versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Juan Jesús Ojeda Croissier schrieb: Hi :-) Before nothing, sorry for my mistakes about mount-systray ackage and the native and non-native packages. Your comments and the mentor's FAQ help me a lot. Well, I have one doubt about the version. What I understand from the policy[1] is that for the package mount-systray, the version should be something like: mount-systray-0.5.3-1 uptream version = 0.5.3 debian version = 1 Yes. But then lintian tells me I need a *.orig.tgz (which I haven't) or if I created a *.orig directory, then tells me the diff is empty and so on. I (or actually we - Guadalinex team) am upstream and we maintain the code with the debian files all together. I know that it's better not to do that and separate the code and the debian files, but, at least by now, we have that way. You have, it is the src tarball. It has to be named this way: source_package_name_upstream_version.orig.tar.gz e.g.: mount-systray_0.5.3.orig.tar.gz The thing is if I put the version like 'mount-systray-0.5.3debian1', which I have seen in some packages, lintian doesn't say a word. My question is, what is the difference between both version ways? Because it is a native version, it hasn't got a debian revision, which starts with the _last_ '-'. And also a kind of retorical one (I guess I know already the answer...), do I really need to separate the app code from the debian packaging files? isn't there another option? There is, but it is wrong and it will not get uploaded. I guess we'll have to slit them :-/ Thanks in advance for your time and your anwsers :-) Cheers [1] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpKQT0ACgkQ2XA5inpabMdxqgCfXEEATvFxK66zqRr7KotLn7aE 0xkAn3iwERBwUAxelkGggcLHDfgY5lvJ =e5hs -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: non-native package versions
(IANADD; TINASOTODP.) In 135eeb1d0906300927x47149b60x74e8194e76a17...@mail.gmail.com, Juan Jesús Ojeda Croissier wrote: Hi :-) Before nothing, sorry for my mistakes about mount-systray ackage and the native and non-native packages. Your comments and the mentor's FAQ help me a lot. Well, I have one doubt about the version. What I understand from the policy[1] is that for the package mount-systray, the version should be something like: mount-systray-0.5.3-1 uptream version = 0.5.3 debian version = 1 But then lintian tells me I need a *.orig.tgz (which I haven't) or if I created a *.orig directory, then tells me the diff is empty and so on. $ pwd ~/my-new-package_0.4.5-1 $ cd .. $ cp -Rl my-new-package_0.4.5-1 my-new-package_0.4.5.orig $ rm -rf my-new-package_0.4.5.orig/debian Now, you'll have a non-empty diff. Remember, though, that 0.4.5-2 must be based on the same .orig.tar.gz and that you should avoid making changes outside of the debian directory in your .diff.gz. If any changes are required, use a patch system. I (or actually we - Guadalinex team) am upstream and we maintain the code with the debian files all together. I know that it's better not to do that and separate the code and the debian files, but, at least by now, we have that way. That happens. It's even appropriate for you to maintain a debian/ directory in your VCS. It should be kept out of the release tarball, but the build system can handle it even if it isn't. The thing is if I put the version like 'mount-systray-0.5.3debian1', which I have seen in some packages, lintian doesn't say a word. That would still be a native package by my reckoning, which is not what is appropriate for this package. [D]o I really need to separate the app code from the debian packaging files? isn't there another option? The other option is native packaging. However, I think we've already covered why that isn't appropriate for this package. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: non-native package versions
On Wednesday 01,July,2009 12:27 AM, Juan Jesús Ojeda Croissier wrote: [...] And also a kind of retorical one (I guess I know already the answer...), do I really need to separate the app code from the debian packaging files? isn't there another option? I guess we'll have to slit them :-/ You don't. You just have to release the tarball without it (the debian/ directory). I know of applications which have the debian/ directory in the upstream source code, but generate tarballs without them. If you use autotools, this is very easy. Just run `make dist' in the configured source directory. If you don't, well, you're on your own (hint: tar --exclude=debian if all else fails). [...] -- Regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: RFS: gwibber
Dnia 2009-06-30, wto o godzinie 16:11 +0530, Kartik Mistry pisze: Just run: lintian -iIEvXc --pedantic *.changes Thanks a lot for this one! Lintian will give enough information to solve each point. It did! :) -- Filip Chabik deb...@hadret.com -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: gwibber
Dnia 2009-06-30, wto o godzinie 16:22 +0530, Kartik Mistry pisze: Fine. You can ask upstream to provide 'download' tarballs at some point of time. I did what lintian suggested -- I've added debian/watch file which for now contains only my comments, but which will provide working link for upstream as soos as stable release of Gwibber will be available. Just remove empty directory. I guess I'll have to dig deeper, maybe I'll change whole debian/rules file and stop relay on Ubuntu package (shame on me, but I'm still learning). I already asked, I'm waiting for answer from Ryan Paul. Good! He answered me, I will quote: @hadret: You can browse the revision history: http://u.nu/8suf It's a bit cryptic, but it is all we have right now. So, do I have to make this file from what I can find on provided link, or can I wait until they will provide something better? Splitting package gwibber and gwibber-common is solution. I believe it's no longer an issue (I believe it was .bzr folder) but splitting package is very nice idea. Is there any good resource I can read about splitting (python) packages? Thanks a lot for packaging and contribution to Debian! It's a pleasure. I always wanted to contribute more to Debian and I'm doing my best right now. Hopefully I'll learn fast to stop bother real Maintainers and only ask some Sponsors for uploading packages I made, without necessity of guiding me how to do it properly (: Once more, thanks a lot for your time and help! I really appreciate it! -- Filip Chabik deb...@hadret.com -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: non-native package versions
On Tue, Jun 30, 2009 at 5:55 PM, Boyd Stephen Smith Jr.b...@iguanasuicide.net wrote: (IANADD; TINASOTODP.) In 135eeb1d0906300927x47149b60x74e8194e76a17...@mail.gmail.com, Juan Jesús Ojeda Croissier wrote: [...] Well, I have one doubt about the version. What I understand from the policy[1] is that for the package mount-systray, the version should be something like: mount-systray-0.5.3-1 uptream version = 0.5.3 debian version = 1 But then lintian tells me I need a *.orig.tgz (which I haven't) or if I created a *.orig directory, then tells me the diff is empty and so on. $ pwd ~/my-new-package_0.4.5-1 $ cd .. $ cp -Rl my-new-package_0.4.5-1 my-new-package_0.4.5.orig $ rm -rf my-new-package_0.4.5.orig/debian Now, you'll have a non-empty diff. Yeah, that was what I did last time. This fixed my problem by now, but it quite complex if you need to do it automatically. We use buildbot with some custom scripts for builging all our packages and isos. But it's another history... Remember, though, that 0.4.5-2 must be based on the same .orig.tar.gz and that you should avoid making changes outside of the debian directory in your .diff.gz. If any changes are required, use a patch system. Ok, we don't need that right now, but I'll keep in mind for the future. Thanks I (or actually we - Guadalinex team) am upstream and we maintain the code with the debian files all together. I know that it's better not to do that and separate the code and the debian files, but, at least by now, we have that way. That happens. It's even appropriate for you to maintain a debian/ directory in your VCS. It should be kept out of the release tarball, but the build system can handle it even if it isn't. We like to maintain the /debian directory in our VCS and we don't release tarballs, so this way is actually a bit forced for us, but I guess we could use bzr-builddeb or try to split it... The thing is if I put the version like 'mount-systray-0.5.3debian1', which I have seen in some packages, lintian doesn't say a word. That would still be a native package by my reckoning, which is not what is appropriate for this package. Ok, I didn't find any reference at the policy about it and I didn't know the difference. Thanks a lot :-) [D]o I really need to separate the app code from the debian packaging files? isn't there another option? The other option is native packaging. However, I think we've already covered why that isn't appropriate for this package. Yes, now I know this can't be a native package :-) Thanks guys :-) -- Juanje -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: gwibber
On Tue, 30 Jun 2009, Filip Chabik wrote: Dnia 2009-06-30, wto o godzinie 13:18 +0200, Piotr Ożarowski pisze: * provide get-orig-source rule (and use bzr's export command) If you could write more about this one, I'd be very happy (: Thanks a lot for your time and instructions, really appreciate it! Hi there, Sandro Tosi posted on the debian wiki [0] how to write a get-orig-source target on your debian/rules, in the example is made with svn, but works the same :-) [0] http://wiki.debian.org/SandroTosi/Svn_get-orig-source Regards, Mauro -- JID: lavaram...@jabber.org | http://lusers.com.ar/ 2B82 A38D 1BA5 847A A74D 6C34 6AB7 9ED6 C8FD F9C1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: gwibber
Dnia 2009-06-30, wto o godzinie 13:18 +0200, Piotr Ożarowski pisze: few additional comments: * use python-support instead of python-central if you want to join PAPT[1] at some point I'd love to do that. Where I can find some good resources about making proper Debian packages using python-support or python at all? I really don't want to relay on Ubuntu package any longer. * Architecture should be all not any Fixed. - some build dependencies can be moved to Build-Depends-Indep Fixed. - replace python-all-dev with python (= 2.5) Fixed. * remove python2.5 from Build-Depends and make sure /usr/bin/gwibber's shebang is set correctly Fixed. * remove Encoding field from desktop file (all desktop files should be encoded in UTF-8) Fixed. * move postinst content do debian/rules (hint: dh_link) Working on it. I might need some more help, but I still search for more informations about creating proper python packages. Any other hints than provided dh_link are very welcome (: * remove postrm (if it's really needed, there's a bug somewhere) I haven't got enough knowledge to answer if postrm is really necessary or not. It removes /usr/share/gwibber after uninstallation of gwibber from system (it would be done automatically but I'm using ln -s to libjs-jquery which aren't remove. I believe it's because of using postinst and not dh_link in debian/rules, is that right?). * provide get-orig-source rule (and use bzr's export command) If you could write more about this one, I'd be very happy (: Thanks a lot for your time and instructions, really appreciate it! Pozdrawiam! (: -- Filip Chabik deb...@hadret.com -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: gwibber
Dnia 2009-06-30, wto o godzinie 15:00 -0300, Mauro Lizaur pisze: Sandro Tosi posted on the debian wiki [0] how to write a get-orig-source target on your debian/rules, in the example is made with svn, but works the same :-) [0] http://wiki.debian.org/SandroTosi/Svn_get-orig-source Thank you, I'll take a look on that! (: -- Filip Chabik deb...@hadret.com -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: tvim
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Harry Rickards wrote: Mauro Lizaur wrote: On Sun, 28 Jun 2009, Harry Rickards wrote: ... dependencies.) I've also removed UTF-8 from the FreeDesktop file via a patch, as it's been deprecated. Should I contact the upstream author and ask them to remove it from the upstream source, or just leave it? Great, and contacting the upstream to remove the deprecated parts can be a good idea, yes. Regards, Mauro Okay. Done. Upstream have done, and have released 0.2.1. I've updated the package, which is now available at: - - URL: http://mentors.debian.net/debian/pool/main/t/tvim - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/t/tvim/tvim_0.2.1-1.dsc Come on, someone's got to want to sponsor it. - -- Many thanks Harry Rickards (GPG Key ID:58449F6F) - -BEGIN GEEK CODE BLOCK- Version: 3.1 GAT/GCM/GCS/GCC/GIT/GM d? s: a? C UL P- L+++ E--- W+++ N o K+ w--- O- M- V- PS+ PE Y+ PGP++ t 5 X R tv-- b+++ DI D G e* h! !r y? - --END GEEK CODE BLOCK-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iJwEAQECAAYFAkpKWAAACgkQ+9DWHFhEn29WgwP+Nlgpfrrx3bkPYlXCVQfDKaOF eQKclSNyi8rsa78qfSPN2SYRW1RZNpbzQveSfXDdALmm0P9vz2KLPmrEhdTJZATO AUSmrkl4cHJvrHZ1bTh49beo+QplxIklh4lG1mgdPi7K7z2vE97IBnIFkZTRi/EE nCYtsOh1ZjtOu1kTWO8= =klyQ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: non-native package versions
On Tue, Jun 30, 2009 at 6:28 PM, Chow Loong Jinhyper...@gmail.com wrote: On Wednesday 01,July,2009 12:27 AM, Juan Jesús Ojeda Croissier wrote: [...] And also a kind of retorical one (I guess I know already the answer...), do I really need to separate the app code from the debian packaging files? isn't there another option? I guess we'll have to slit them :-/ You don't. You just have to release the tarball without it (the debian/ directory). I know of applications which have the debian/ directory in the upstream source code, but generate tarballs without them. If you use autotools, this is very easy. Just run `make dist' in the configured source directory. If you don't, well, you're on your own (hint: tar --exclude=debian if all else fails). The problem we have right now is that we don't really use tarballs for release our apps. We have some packages that we maintain on our VCS system, we build them from a buildbot[1] with some custom scripts and then we upload them with reprepro to our repository. I know we need to chango some things on the packages to get them into Debian, but I would like to do it in a way that we still can use for our project. Is there any way to do all the *.orig.tgz stuff from the rules file? Maybe there is a way to keep the /debian directory in out VCS and generate the tarbal from the rules file before be checked if that exist. We are open to any idea :-) Cheers [1] http://buildbot.net -- Juanje -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: non-native package versions
On Tue, Jun 30, 2009 at 07:23:38PM +0100, Juan Jesús Ojeda Croissier wrote: On Tue, Jun 30, 2009 at 6:28 PM, Chow Loong Jinhyper...@gmail.com wrote: On Wednesday 01,July,2009 12:27 AM, Juan Jesús Ojeda Croissier wrote: [...] And also a kind of retorical one (I guess I know already the answer...), do I really need to separate the app code from the debian packaging files? isn't there another option? I guess we'll have to slit them :-/ You don't. You just have to release the tarball without it (the debian/ directory). I know of applications which have the debian/ directory in the upstream source code, but generate tarballs without them. If you use autotools, this is very easy. Just run `make dist' in the configured source directory. If you don't, well, you're on your own (hint: tar --exclude=debian if all else fails). The problem we have right now is that we don't really use tarballs for release our apps. Well, you're going to have to fix that before you can get a Debian upload, at any rate. You can't upload a VCS revision as a source package (yet). - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: non-native package versions
In 20090630183826.gf4...@hezmatt.org, Matthew Palmer wrote: On Tue, Jun 30, 2009 at 07:23:38PM +0100, Juan Jesús Ojeda Croissier wrote: On Tue, Jun 30, 2009 at 6:28 PM, Chow Loong Jinhyper...@gmail.com wrote: On Wednesday 01,July,2009 12:27 AM, Juan Jesús Ojeda Croissier wrote: [D]o I really need to separate the app code from the debian packaging files? isn't there another option? I guess we'll have to slit them :-/ You don't. You just have to release the tarball without it (the debian/ directory). I know of applications which have the debian/ directory in the upstream source code, but generate tarballs without them. The problem we have right now is that we don't really use tarballs for release our apps. Well, you're going to have to fix that before you can get a Debian upload, at any rate. Not really. The .orig.tar.gz could be a VCS snapshot. It just needs to be named appropriately and (preferably) be reproducible if lost. If upstream doesn't normally release tarballs, a get-orig-source target is virtually mandatory since this package would be very hard to maintain without it. You can't upload a VCS revision as a source package (yet). Is this a thinly-veiled reference to the new source package format? If it is, do you know of any page on the Internet that gives the status of this project? -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS: gwibber
[Filip Chabik, 2009-06-30] Dnia 2009-06-30, wto o godzinie 13:18 +0200, Piotr Ożarowski pisze: few additional comments: * use python-support instead of python-central if you want to join PAPT[1] at some point I'd love to do that. Where I can find some good resources about making proper Debian packages using python-support or python at all? I really don't want to relay on Ubuntu package any longer. in majority of cases it's just: | python setup.py --root=foo | dh_pysupport and then fill in Depends see /usr/share/doc/python-support/README.gz or http://people.debian.org/~srivasta/manoj-policy/ for more (the first file should be enough) * move postinst content do debian/rules (hint: dh_link) Working on it. I might need some more help, but I still search for more informations about creating proper python packages. Any other hints than provided dh_link are very welcome (: dh_link will create links for you * remove postrm (if it's really needed, there's a bug somewhere) I haven't got enough knowledge to answer if postrm is really necessary or not. It removes /usr/share/gwibber after uninstallation of gwibber from system (it would be done automatically but I'm using ln -s to libjs-jquery which aren't remove. I believe it's because of using postinst and not dh_link in debian/rules, is that right?). that's right, see `man dh_link` for more * provide get-orig-source rule (and use bzr's export command) If you could write more about this one, I'd be very happy (: get-orig-source: REV=$(shell dpkg-parsechangelog | sed -rne 's,^Version: .*bzr([^-]+).*,\1,p'); \ VER=$(shell dpkg-parsechangelog | sed -rne 's,^Version: ([^-]+).*,\1,p'); \ bzr export -r $$REV gwibber_$$VER.orig.tar.gz lp:gwibber should be enough Thanks a lot for your time and instructions, really appreciate it! /me goes back to PAPT/DPMT packages, there are some other small issues, but I'll not steal a sponsoree from Kartik ;-) Pozdrawiam! (: ja również :) PS no need to Cc me, I read the list :-P -- http://people.debian.org/~piotr/sponsor signature.asc Description: Digital signature
Re: RFS: gwibber
[Filip Chabik, 2009-06-30] Splitting package gwibber and gwibber-common is solution. I believe it's no longer an issue (I believe it was .bzr folder) but splitting package is very nice idea. Is there any good resource I can read about splitting (python) packages? since you fixed the Architecture field, there's no reason to split the package anymore -- http://people.debian.org/~piotr/sponsor signature.asc Description: Digital signature
RFS: kcometen4 (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.0.5-1 of my package kcometen4. It builds these binary packages: kcometen4 - An OpenGL KDE screensaver with lightning and comets The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/k/kcometen4 - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/k/kcometen4/kcometen4_1.0.5-1.dsc I would be glad if someone uploaded this package for me. Kind regards John Stamp -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: python-ipcalc
Hi,
On Sat, 27 Jun 2009 22:08:59 +0200 mezgani ali wrote:
Ok Evgeni, you know it was difficult for me to divine it :)
Yeah I guess so, no problem :)
Ok, I'll have a look on Monday or so, quite busy right at the moment.
For some monday==tuesday ;)
I had a look at your package yesterday and prepared some proposed
changes now, see the attached debdiff.
First of all: you added python-support to Build-Depends, but did not
call dh_pysupport in your debian/rules, so it was mostly useless :)
And your debian/rules was soo long for a so tiny package :)
debhelper knows perfectly how to handle python setup.py scripts, so I
just put a
%:
dh $@
into debian/rules and let it build - much cleaner and now with correct
pysupport integration :)
The other changes in the diff are against control:
Depends: python-support comes out of ${python:Depends}, no need to add
this manually, lintian complains about ${misc:Depends} missing, so I
added it.
Then I added Provides: ${python:Provides} - maybe someone wants so pull
python2.4-ipcalc for some reason.
And I reformatted the description a bit, as lintian complained about
too long lines.
So please have a look at the attached diff, understand it and apply
it :)
Whats still open? lintian complains about a missing watch-file. But
upstreams page looks quite hacky and I did not find an easy way how to
look up the latest version from it. You can add an override or an empty
watch file with a comment, I usually do the last, but you can do
whatever you want - or ignore the warning for the moment and tell
upstream to publish the source in a more sane way.
And while at it, please consider adding a README.source as
described in Policy 4.14 and telling the others how to fetch the latest
source and create a .orig.tar.gz (writing go to URL, fetch the .zip
and convert it with command should be enough).
Regards
Evgeni
--
Bruce Schneier Fact Number 188:
Heisenberg's Uncertainty Principle doesn't protect your qubits from
Bruce Schneier. Bruce knows with certainty.
python-ipcalc-evgeni.debdiff
Description: Binary data
Re: non-native package versions
On Wednesday 01,July,2009 02:23 AM, Juan Jesús Ojeda Croissier wrote: The problem we have right now is that we don't really use tarballs for release our apps. We have some packages that we maintain on our VCS system, we build them from a buildbot[1] with some custom scripts and then we upload them with reprepro to our repository. I say just do tarball releases. They can't be that hard to do, right? Just identify snapshots of the history that are stable enough for widespread usage, and then tarball it using one of the methods I highlighted in my previous post. Anyway, regarding your custom scripts.. are they for daily builds? They could be retained IMO, while doing a tarball release at appropriate intervals. I know we need to chango some things on the packages to get them into Debian, but I would like to do it in a way that we still can use for our project. Is there any way to do all the *.orig.tgz stuff from the rules file? Maybe there is a way to keep the /debian directory in out VCS and generate the tarbal from the rules file before be checked if that exist. We are open to any idea :-) You could write a get-orig-source rule in debian/rules for that purpose. But that is complicated, unnecessary, and ugly. Like I've mentioned in my previous post, there are projects (like smuxi) which keep the debian/ folder in their VCS, but release source tarballs without them, so that they may be packaged in each distribution separately. I cannot see how this would disrupt your existing workflow in any way. -- Regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: RFS: iulib (3rd attempt)
On Sun, Jun 28, 2009 at 12:26:00AM +0200, Jeffrey Ratcliffe wrote: 2009/6/27 Nick Leverton n...@leverton.org: First, you call dh_quilt_unpatch from your clean target, however this command is provided by quilt which is not part of build-essential. Pbuilder only auto-installs the dependencies after cleaning the package - but it will not do this as the clean fails. You might fix this by doing dh_quilt_unpatch || true in your clean. It builds fine in my pbuilder without this. Hmm. Maybe mine is wrong then. Russ Alberry thinks so too so I'll check. Of course, I did install (and use) it, but made modifications, and didn't install it again. Thanks for pointing that out. Done it myself a few times, my thanks to my sponsors who are very patient :) Thanks for your help. I have uploaded the package again with the above changes. I'd be glad if someone would review this package for upload too, thankyou. Nick -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: gvpe, the GNU Virtual Private Ethernet daemon
Right, sorry it's taken a few days to get round to this, it's been a bit
hectic here (and the heat breaks my concentration badly).
On Thu, Jun 25, 2009 at 12:40:34AM +, Robert Edmonds wrote:
On 2009-06-24, George Danchev danc...@spnet.net wrote:
GVPE looks like a fork of tinc which is already in Debian (or at least
shares
some code with it), and its source tree carries libev (by the same author)
instead of linking with the libev library provided as a separate package
and
already uploaded in Debian. Unfortunately, code dups, also means (security)
bugs dups, like that conditional `devision by zero' in ev_select.c line 105
which seems to be windows-specific (NFBITS previously and conditionally
defined
as 0).
gvpe definitely isn't a fork of tinc, it merely uses tinc's
platform-specific tun/tap interface code (about 200 lines for
linux/kfreebsd). the crypto code is completely different and in C++.
Yes, I realised there was some overlap but not a complete copy of tinc.
It's less than desirable, but not avoidable IMO.
and unfortunately the embedded copy of libev is compiled with
EV_MULTIPLICITY set to 0 (libev in debian is compiled with the default
setting of 1), which changes the API/ABI. (it controls whether an
additional parameter is required by function calls or passed to
callbacks.)
And likewise, embedding libev isn't great either, but there is a good
reason.
I've emailed upstream to see whether he'd be open to reworking these
problems sometime.
I worked through the diff of your proposed changes and integrated almost
all of them - if I'm right, lots are formatting and style, some cruft
removal, and some technical. The file gvpe.init particularly came mostly
from the debhelper template, which is why it was weaker.
The bits I'm left with are the ones I don't quite follow, here as a
diff with annotations:
init.d:
@@ -31,16 +31,11 @@
#merely create a single tunnel, it creates a real
#network with multiple endpoints.
### END INIT INFO
-PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
-
-DAEMON=/usr/sbin/gvpe
NAME=gvpe
DESC=GNU Virtual Private Ethernet daemon
-LOGDIR=/var/log/gvpe
-
PIDFILE=/var/run/$NAME.pid
-test -x $DAEMON || exit 0
+test -x /usr/bin/gvpectrl || exit 0
Ok, I missed the fact that the PATH variable has wrong paths in (oops)
so that can go in. But why remove the declaration of $NAME and move it
further down?
I take it the $LOGDIR variable goes because it doesn't get
used - I assumed that log_daemon_msg and friends used it, probably a bad
thing to assume.
Why test that /usr/bin/gvpectrl is executable but not $DAEMON?
@@ -56,8 +51,6 @@
CIPHER=aes128
DIGEST=sha256
-LOGFILE=$LOGDIR/$NAME.log # Server logfile
-
Likewise, I presume $LOGFILE doesn't get used.
@@ -73,8 +66,7 @@
# Use this if you want the user to explicitly set 'RUN' in
# /etc/default/
if [ x$RUN != xyes ]; then
-log_failure_msg $NAME disabled, please adjust the configuration to
your needs
-log_failure_msg and then set RUN to 'yes' in /etc/default/$NAME to
enable it.
+log_failure_msg $NAME disabled in /etc/default/$NAME.
exit 1
Is this change to the output text a preference, or is there a style for
this sort of message that I've missed somewhere?
@@ -153,7 +145,7 @@
log_end_msg 0
exit 0
fi
-if start_server; then
+if start_server ; then
I think you missed this one ;)
@@ -213,19 +205,11 @@
fi
;;
reload)
-log_daemon_msg Reloading configuration for $DESC $NAME
-if running; then
-[ -x /usr/sbin/gvpectrl ] /usr/sbin/gvpectrl -kHUP
-log_end_msg 0
-else
-log_progress_msg apparently not running
-log_end_msg 1
-exit 1
-fi
+log_warning_msg Reloading $NAME daemon: not implemented (use
restart).
;;
*)
N=/etc/init.d/$NAME
-echo Usage: $N
{start|stop|force-stop|restart|reload|force-reload|status} 2
+echo Usage: $N
{start|stop|force-stop|restart|force-reload|status} 2
I only just today noticed that gvpectrl can send a HUP signal to the
daemon, and tested that it reloads the configuration properly, so I've
implemented reloading. Does it look correct?
debian/rules:
@@ -20,7 +20,7 @@
CROSS= --build $(DEB_BUILD_GNU_TYPE)
endif
-CONF=./configure $(CROSS) --prefix=/usr --includedir=$${prefix}/include
--mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
--sysconfdir=/etc --localstatedir=/var --libexecdir=$${prefix}/lib/gvpe
--disable-maintainer-mode --disable-dependency-tracking --enable-dns
--enable-icmp --enable-rawip --enable-tcp --enable-udp
CFLAGS=$(CFLAGS) LDFLAGS=-Wl,-z,defs
+CONF=./configure $(CROSS) --prefix=/usr --includedir=$${prefix}/include
--mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
--sysconfdir=/etc
RFS: ia32-libs-tools (updated package)
Dear mentors, I am looking for a sponsor for the new version 19 of my package ia32-libs-tools. It builds these binary packages: ia32-apt-get - Apt-get and dpkg wrapper for on-the-fly ia32-libs conversion ia32-archive - Create a local archive of converted i386 debs for amd64 and ia64 ia32-libs - ia32 shared libraries for use on amd64 and ia64 systems ia32-libs-gtk - ia32 shared libraries for use on amd64 and ia64 systems ia32-libs-tools - Tools for converting i386 debs for amd64 and ia64 The upload would fix these bugs: 435455, 458457, 459521, 460169, 460737, 463701, 471363, 475137, 478046, 484581, 487788, 490947, 492453, 492978, 493968, 496248, 497919, 498044, 499040, 499043, 504137, 505625, 505627, 505631, 505632, 505761, 508170, 527521, 529935, 530954, 532512, 532986, 533746, 534903, 534979, 535035, 535081 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/i/ia32-libs-tools - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/i/ia32-libs-tools/ia32-libs-tools_19.dsc I would be glad if someone uploaded this package for me. The package adds a debconf question that allows disabling ia32-apt-get or limiting the nuber of package it provides and thereby limiting the amount of damage it can do. This fixes I believe what most people complained about in the recent flame on debian-devel. It also fixes some install, remove and purge problems peope run into that disabled their package management. So some quite important fixes. This is my first package with debconf support so please take an extra look at that part. I think I followed the debconf-devel example pretty closely so I hope it is ok. Kind regards Goswin von Brederlow -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: gwibber
On Wed, Jul 1, 2009 at 12:37 AM, Piotr Ożarowskipi...@debian.org wrote: /me goes back to PAPT/DPMT packages, there are some other small issues, but I'll not steal a sponsoree from Kartik ;-) Heh :) No issue if you steal him :P -- Cheers, Kartik Mistry | 0xD1028C8D | IRC: kart_ Debian GNU/Linux Developer Blog.en: ftbfs.wordpress.com Blog.gu: kartikm.wordpress.com -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
