Re: RFS: trophy (Adopted and updated package)
Hi Andreas, On Tue, 2011-07-05 at 20:06 +0200, Andreas Moog wrote: On 07/05/2011 08:18 AM, Kilian Krause wrote: On Mon, 2011-07-04 at 17:12 +0200, Andreas Moog wrote: New version uploaded to mentors and pushed to git://anonscm.debian.org/pkg-games/trophy.git (Note that I put the pkg-games team as maintainer and myself as Uploader). The current version that's on mentors.d.n has Maintainer: Andreas Moog still (and no Uploaders). Can you please check that this is indeed the latest version? Now it is the latest version, I simply forgot to dput ;-) As your orig.tar.gz didn't match up with the one on upstream's site, I've replaced the file with the one that is available for public download - the contents seem to be identical. And regarding dh-autoreconf I'll have your word for it that when things break you'll step up and see to fixing it. One minor issue, your debian/copyright had a paragraph jump with . without the whitespace instead of . which would be required. I've also corrected that. Apart from these two: Built, signed, uploaded. Thanks for your work! -- Best regards, Kilian signature.asc Description: This is a digitally signed message part
Git and tarballs
Hi all, I've recently started to work on some packages and am not sure if I follow best practices when packaging software from git repositories with git-buildpackage. My main point of confusion is that I don't really see the need for tarballs and what I am doing right now feels a bit clumsy and wrong. As my gut feeling is typically a good indicator I feel the need for additional feedback. Lets assume that I want to create a new package for software that lives on github and releases have been tagged and are therefore available through the githubredir service. Not everybody provides downloads, but you can essentially download every commit as a tarball. What I have been doing so far is the following (package foo): --- snip --- $ mkdir foo $ cd foo ; git init $ git remote add UPSTREAM_GH_USER git://github.com/UPSTREAM_GH_USER/foo.git $ git fetch UPSTREAM_GH_USER $ git checkout -b upstream UPSTREAM_GH_USER/master $ git checkout -b master TAG_TO_PACKAGE $ mkdir debian $ dch --create $ cat EOF debian/watch version=3 http://githubredir.debian.net/github/UPSTREAM_GH_USER/foo /([\d\.]+)\.tar\.gz EOF $ uscan --force-download --rename $ pristine-tar commit ../foo_TAG_TO_PACKAGE.orig.tar.gz $ cd debian ; HACK_AWAY --- snip --- I know that I could just download the tarball from github and use git-import-orig to import the release, but I basically see upstream as simply another remote branch whose tags are packaged. I would welcome any feedback, criticism and praise for this workflow. This, however, raises some questions: 1. What to do for new releases/tags? i. One way would be to run git-import-orig --uscan and be done with it, but I would probably lose all upstream history on the upstream branch if I do that. ii. Another way would simply merge the remote changes into 'upstream' and 'debian' and basically boils down to: $ git fetch UPSTREAM_GH_USER $ git checkout upstream ; git merge UPSTREAM_GH_USER/master $ git checkout master ; git merge NEW_TAG_TO_PACKAGE $ uscan --rename $ pristine-tar commit ../foo_NEW_TAG_TO_PACKAGE.orig.tar.gz $ cd debian ; HACK_AWAY 2. How to repack tarballs/tags? (DFSG, etc) I am really not sure how to repack tarballs in this workflow which might be needed to make it DFSG compliant or simply because some files should not be shipped. (jars for Java for example). My feeling is that I'd have to work on the actual tarball acquired with uscan and repack it, before commiting to the pristine-tar branch. There are also some helper that can be incorporated into the watch file (such as jh_repack), which would essentially mean that the tarball does *not* correspond to an upstream tag. It also seems to be good practice to implement get-orig-source in the rules file, in which the repacking could also happen. 3. Repository overkill The packaging should probably be pushed to a git repo on alioth, which would mean that master and pristine-tar track the alioth repo, and upstream needs to be pushed explicitly to alioth as it tracks the upstream repository. This difference in the branch setup is a potential source of error and I would like to avoid it, but am not sure how. In short Am I nuts? What are your workflows? Do you *only* work with tarballs and don't use/track the upstream repositories at all? * only use git-import-orig * Repository lives only on alioth and all branches track alioth If not: How do you work with the *real* upstream branches? How do you generate tarballs? Sorry for the wall-of-text and for all your advice in advance :) -- .''`. Wolodja Wentlandbabi...@gmail.com : :' : `. `'` 4096R/CAF14EFC `- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Re: Git and tarballs
Le mercredi 6 juillet 2011 14:38:36, Wolodja Wentland a écrit : Hi all, Hi Wolodja, First, thanks for posting your git workflow. It is for me very interesting to see different ways of dealing with upstream also using git. [SNIP] I know that I could just download the tarball from github and use git-import-orig to import the release, but I basically see upstream as simply another remote branch whose tags are packaged. I would welcome any feedback, criticism and praise for this workflow. There was a thread recently about using tarballs or tags on debian-devel@l.d.o recently. No consensus was reached as it clearly depends on your needs and probably also your tastes. Personally I work with upstream tarball. Yet, I do keep remote branches to follow upstream development in the same repository, but it's mainly for having convenient cherry-picks. Your setup greatly interest me. This, however, raises some questions: 1. What to do for new releases/tags? i. One way would be to run git-import-orig --uscan and be done with it, but I would probably lose all upstream history on the upstream branch if I do that. Upstream history is not lost since there is still the upstream branches available. ii. Another way would simply merge the remote changes into 'upstream' and 'debian' and basically boils down to: $ git fetch UPSTREAM_GH_USER $ git checkout upstream ; git merge UPSTREAM_GH_USER/master $ git checkout master ; git merge NEW_TAG_TO_PACKAGE $ uscan --rename $ pristine-tar commit ../foo_NEW_TAG_TO_PACKAGE.orig.tar.gz $ cd debian ; HACK_AWAY The problem with this solution setup is that a clone of the alioth repository would not setup a remote upstream branch, thus you can't just run git buildpackage after the clone. On the other hand you could republish the upstream branch on alioth but you make all people download more data for nothing. 2. How to repack tarballs/tags? (DFSG, etc) I am really not sure how to repack tarballs in this workflow which might be needed to make it DFSG compliant or simply because some files should not be shipped. (jars for Java for example). My feeling is that I'd have to work on the actual tarball acquired with uscan and repack it, before commiting to the pristine-tar branch. There are also some helper that can be incorporated into the watch file (such as jh_repack), which would essentially mean that the tarball does *not* correspond to an upstream tag. It also seems to be good practice to implement get-orig-source in the rules file, in which the repacking could also happen. Does pristine-tar work if the upstream branch contains files which have been removed during repack? 3. Repository overkill The packaging should probably be pushed to a git repo on alioth, which would mean that master and pristine-tar track the alioth repo, and upstream needs to be pushed explicitly to alioth as it tracks the upstream repository. This difference in the branch setup is a potential source of error and I would like to avoid it, but am not sure how. In my setup all branches (upstream, pristine-tar and master) track those on alioth, while the copy of upstream development branches track the upstream branches. There is few confusion in this scheme. In short Am I nuts? I don't think so. What are your workflows? See above. Do you *only* work with tarballs and don't use/track the upstream repositories at all? * only use git-import-orig * Repository lives only on alioth and all branches track alioth It's perfectly possible to track upstream repositories and use tarballs at the same time. This way cherry-pick and upstream changes review is still easy but the alioth repository is not full of non-debian commits. I acknowledge that the latter argument can't be seen as a weakness. If not: How do you work with the *real* upstream branches? How do you generate tarballs? Sorry for the wall-of-text and for all your advice in advance :) No problem, thanks for your post. signature.asc Description: This is a digitally signed message part.
Re: Git and tarballs
On Wed, Jul 06, 2011 at 03:12:41PM +0200, Thomas Preud'homme wrote: Does pristine-tar work if the upstream branch contains files which have been removed during repack? Unfortunately the directory and the tarball must have identical contents. -- WBR, wRAR signature.asc Description: Digital signature
: RFS: autoconf-archive (updated package)
Dear mentors, I am looking for a sponsor for the new version 1:2011.04.12-1 of the package autoconf-archive. It builds these binary packages: autoconf-archive - Autoconf Macro Archive The upload would fix these bugs: 214089, 568413, 572669, 584180, 593838, 622369 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/autoconf-archive - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/autoconf-archive/autoconf-archive_2011.04.12-1.dsc I would be glad if someone uploaded this package for me. Note that previous maintainer was marked MIA and I will comaintain it with Deng Xiyue Notice also that copyright was fixed and DEP5 They are two lintian warnings that are bug on lintian: - #607694 if you are using stable lintian - new version: autoconf-archive source: git-patches-not-exported but they are exported see debian/patches/series (will report) and I have no patch for now Kind regards bastien roucaries -- 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/201107061514.44552.roucaries.bast...@gmail.com
Re: Git and tarballs
On Wed, Jul 6, 2011 at 8:38 AM, Wolodja Wentland babi...@gmail.com wrote: Hi all, I've recently started to work on some packages and am not sure if I follow best practices when packaging software from git repositories with git-buildpackage. My main point of confusion is that I don't really see the need for tarballs and what I am doing right now feels a bit clumsy and wrong. As my gut feeling is typically a good indicator I feel the need for additional feedback. [snip] Am I nuts? What are your workflows? Do you *only* work with tarballs and don't use/track the upstream repositories at all? * only use git-import-orig * Repository lives only on alioth and all branches track alioth If not: How do you work with the *real* upstream branches? How do you generate tarballs? I, personally, just use the Debian Github redirector [1] for my watch files since my upstreams are good at tagging releases. At that point I can just use git-import-orig. I don't really need upstream's commit history in Debian's VCS (since it is available on their own repo), so this system works for me. Since the debian repositories require an .orig.tar.gz, my first step of new release workflow is to make sure I create a proper tarball that is DFSG, and check that into my VCS with git-import-orig --pristine-tar. I look at it as the debian git VCS is to aid in packaging efforts, which revolve around .orig.tar.gz, .dsc, and .debian.tar.gz - so my workflow is based on creating and maintaining those files. Cheers, Scott [1] http://githubredir.debian.net/ -- 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/cang8-dawehgsqxkgjtrsu-00nq0tujwffhrqwdlyyj-hhdw...@mail.gmail.com
Re: RFS: arp-scan (updated package, new maintainer)
Hi William, On Tue, 2011-07-05 at 18:23 -0600, René Mayorga wrote: On Tue, Jul 05, 2011 at 08:45:41AM +0200, Kilian Krause wrote: Tim, are you agreed that William takes over or do you want to remain as uploader/co-maintainer? Please let him a co-maint for a while, since he is active but busy at this momment. Sounds fine to me. Could you please prepare an upload that would reflect this in a way you both are ok with? I guess letting Tim as Maintainer and putting you into Uploaders would do the trick - together with an update in debian/changelog. Unless there is some mail alias/list you want to use together. Thanks! -- Best regards, Kilian signature.asc Description: This is a digitally signed message part
Commit hooks for Git and no tarballs ?
Dear all, this thread reminds me of a problem I had in a similar case. When I track the upstream branch, merge it in the Debian branch, our commit hook sends one notification per upstream commit on our packagers mailing list. To reduce traffic, and to avoid confusion between changes made by the packagers and changes made by upstream developers, I would like these merges to generate a single notification similar to the one after pushing the result of a git-import-orig command. Are there people already using such a setup ? I would be interested to copy their commit hook. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20110706143706.ga25...@merveille.plessy.net
Re: Git and tarballs
Bonjour Thomas, On Wed, Jul 06, 2011 at 15:12 +0200, Thomas Preud'homme wrote: Le mercredi 6 juillet 2011 14:38:36, Wolodja Wentland a écrit : First, thanks for posting your git workflow. It is for me very interesting to see different ways of dealing with upstream also using git. No problem. It was basically what felt right at that time and was driven by the necessities. I have the impression by other comments that a style like this is not very common though. My main motivation right now is to *see* a couple of different established workflows, so I can get a better understanding of it. As a new maintainer you are trying to get to grips with various tools, regulations and workflows and I enjoy a See what others are doing and combine the best parts approach. [SNIP] I know that I could just download the tarball from github and use git-import-orig to import the release, but I basically see upstream as simply another remote branch whose tags are packaged. I would welcome any feedback, criticism and praise for this workflow. There was a thread recently about using tarballs or tags on debian-devel@l.d.o recently. No consensus was reached as it clearly depends on your needs and probably also your tastes. Yeah, TMTOWTDI is good and nice, but you are also often unsure what is good and what not. Do you recall the subject of the thread? I skimmed through my archive and nothing met my eye. Personally I work with upstream tarball. Yet, I do keep remote branches to follow upstream development in the same repository, but it's mainly for having convenient cherry-picks. Your setup greatly interest me. Yeah, this tarball-centric style seems to be quite typical. But after playing around I found that the tarball is *only* needed to populate the pristine-tar branch as everything else is already in the repositories. I just wasn't sure how repacking (with/without helpers) is handled. This, however, raises some questions: ii. Another way would simply merge the remote changes into 'upstream' and 'debian' and basically boils down to: $ git fetch UPSTREAM_GH_USER $ git checkout upstream ; git merge UPSTREAM_GH_USER/master $ git checkout master ; git merge NEW_TAG_TO_PACKAGE $ uscan --rename $ pristine-tar commit ../foo_NEW_TAG_TO_PACKAGE.orig.tar.gz $ cd debian ; HACK_AWAY The problem with this solution setup is that a clone of the alioth repository would not setup a remote upstream branch, thus you can't just run git buildpackage after the clone. On the other hand you could republish the upstream branch on alioth but you make all people download more data for nothing. Yeah, that is exactly the problem I am facing there and a major problem with this approach. I guess that upstream should be used in the way intended by git-buildpackage. If real upstream branches are needed they can be added later and tracked locally under a different name. (suggestions?) 2. How to repack tarballs/tags? (DFSG, etc) This question still interests me. Is this *really* done manually? How do, for example, jh_repack (in the watchfile) and get-orig-source fit into the picture? Thanks for your input, that was quite helpful. I guess the one *very* important aspect is that people should be able to debcheckout foo and git-buildpackage and don't run into problems. -- .''`. Wolodja Wentlandbabi...@gmail.com : :' : `. `'` 4096R/CAF14EFC `- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Re: RFS: hwinfo (updated package)
Hi William, On Tue, Jul 05, 2011 at 10:50:02PM -0500, William Vera wrote: On Mon, Jun 27, 2011 at 1:46 AM, Kilian Krause kil...@debian.org wrote: On Mon, 2011-06-27 at 01:34 -0500, William Vera wrote: -(snip)- I need make a package for x86emu.h or I can make some patch for this? I would appreciate your comments and advices. from a first look at [1] this seems to be a kFreeBSD issue so it may be safe to patch the x86emu.h out for Linux. [1]: http://packages.debian.org/search?searchon=contentskeywords=x86emu.hmode=exactfilenamesuite=unstablearch=any I'm a little confused, can you give more details? Thanks in advance all I was referring to was the fact that this file according to packages.d.o seems to only exist in kFreeBSD based kernels in Debian. If that is correct and you don't intend to build on kFreeBSD but on linux, that file may eventually not be required. Thus my comment that this may be some code that's only required to build ok on BSD kernels and thus might be ok to patch out on Linux if that isn't a coincidence in header filenames. You may want to discuss the exact details of the x86emu.h source upstream had in mind with upstream though. They surely know best how to get the proper build env set up to build their code. I've just given you the heads up that this file seems to not exist in a generic package in Debian yet so that may be another candicate for a Build-Depends package that should be put together first (or included or whatever). Hope this now made it a bit clearer. -- Best regards, Kilian signature.asc Description: Digital signature
Re: RFS: lebiniou, lebiniou-data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/29/2011 05:12 PM, David Banks wrote: wrt to debian/copyright file there are a few issues: * You might consider using DEP-5 as a best practice, this is up to you. This has been fixed, but I'm not sure what exactly the content of the Format: field should be. * You should probably mention the original author and license of src/pnglite.[ch] in the copyright file. Also fixed. * You should mention the copyright on fonts/FreeMono.ttf and preferably ship the source if possible. Alternatively, repack and exclude it. (About the latter, I see that in Makefile.am you use --enable-debian to disable installing the fonts. I would say as a matter of style you should keep all debian-specific tweaks inside the 'debian' directory. Arguably it's better to patch the Makefile than to put this option in. Regardless of where you put the option, though, everything in the _source_ package needs a copyright statement.) I included the FreeMono.sfd, COPYING and README files from the freefont package in the source tarball. However, the Debian package now depends on ttf-freefont, and the option to remove the fonts/ directory has been moved from the Makefile to debian/patches, as suggested. * Manpage is lebiniou.6, but I'm not sure if Le Biniou would be called a game, though you can see it as one. I'd be comfortable with it under section 1. Moved back to section 1. * The program didn't seem to detect audio from Rhythmbox out of the box, presumably as it was trying to use the alsa plugin where rhythmbox uses pulseaudio. Maybe consider adding a note to the manual about how to switch the audio plugin, for new users. The manual has been updated. I uploaded the new packages to mentors.debian.net. Thanks, - -- Olivier -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4Ui+4ACgkQpqVXaJzJYNKH7wCfXiZ45Zo/yJ5qbQu/oU3RIDpR +uQAnjrCQ0bCxyMdgBJkytd6j5EwTQxP =tBIQ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e148bee.9050...@biniou.info
Re: Git and tarballs
Le mercredi 6 juillet 2011 17:52:31, Wolodja Wentland a écrit : Bonjour Thomas, :) [SNIP] There was a thread recently about using tarballs or tags on debian-devel@l.d.o recently. No consensus was reached as it clearly depends on your needs and probably also your tastes. Yeah, TMTOWTDI is good and nice, but you are also often unsure what is good and what not. Do you recall the subject of the thread? I skimmed through my archive and nothing met my eye. No surprise. I had some difficulties myself and for good reason: the thread was about Best practice for cleaning autotools-generated files. I would say the debate really started at [0] [0] http://lists.debian.org/debian-devel/2011/05/msg00420.html Only 2 people argued with each other about advantages and drawbacks of both solution but several interesting arguments were given along the long thread. Good luck for reading them. Personally I work with upstream tarball. Yet, I do keep remote branches to follow upstream development in the same repository, but it's mainly for having convenient cherry-picks. Your setup greatly interest me. Yeah, this tarball-centric style seems to be quite typical. But after playing around I found that the tarball is *only* needed to populate the pristine-tar branch as everything else is already in the repositories. Absolutely. But you also need a branch with the content of the tarball. I also have example of tarball which doesn't contain the same thing as the upstream repo. Just consider all the tarballs which strip out all the repo-specific file (think .gitignore for example). Hence if you use the remote upstream dev branch you often need to repack so that the upstream branch match what was commited in pristine-tar branch. Actually I have the case of an archive which is pretty different from the upstream SVN repo. I just wasn't sure how repacking (with/without helpers) is handled. As you said, it's common practice to have a get-orig-source target in debian/rules which will remove all the necessary files. But I guess it might need some very regular update in some cases, for example if upstream code contains some non-free files which change from one version to another (like image for some theme). Note that I never experienced that and is pure speculation. [SNIP] Yeah, that is exactly the problem I am facing there and a major problem with this approach. I guess that upstream should be used in the way intended by git-buildpackage. If real upstream branches are needed they can be added later and tracked locally under a different name. (suggestions?) Personally I don't have any local branch, just remote branches. And when I need to do a bisect for example I will checkout temporarily one of the upstream dev branches. What I have is: origin = upstream repo alioth = alioth repo master, upstream and pristine-tar are also local branches. No local branches for origin. And I also maintain a branch per distribution (lenny, squeeze, wheezy, sid) on alioth only. I try to update them so that they always reflect the state of my package in the respective distributions. 2. How to repack tarballs/tags? (DFSG, etc) This question still interests me. Is this *really* done manually? How do, for example, jh_repack (in the watchfile) and get-orig-source fit into the picture? I think the best is to have a working get-orig-source and then just call uscan + debian/rules get-orig-source and pristine-tar commit the result. Of course you should check the result but the interesting thing about this setup is that people can reproduce the filtering themself when a new version is released and you didn't package it yet. Thanks for your input, that was quite helpful. I guess the one *very* important aspect is that people should be able to debcheckout foo and git-buildpackage and don't run into problems. You're welcome. Best regards. Thomas Preud'homme signature.asc Description: This is a digitally signed message part.
Re: RFS: lebiniou, lebiniou-data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Oliver, On 06.07.2011 18:23, Olivier Girondel wrote: This has been fixed, but I'm not sure what exactly the content of the Format: field should be. please see [1] and that thread in general. Some people have different understandings what to put there. The thread I am referring to addresses most if not all concerns with it. [1] http://lists.debian.org/debian-mentors/2011/05/msg00529.html - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOFJV/AAoJEMcrUe6dgPNt32AP/A5aKWbRmDV/QhDlE9rV0DxF MYOGfotMvDlK6usM0QpQjl86E+hG6jZ/8TWjPS1M2pkjVvkw2kyu2JWfaMSwYUgB c0g0694yf2qKAa+tiKZ/jvUhih6wDmkrEMqcWKAh/r8XFkibm4vIO9Mm4QDCc+jP qTXKcmkbIVXraJ88QHZiohaLCgcZ4eMJf/Exxr8yt+4zuLbBYi6fRdW195BSsiCk vJwiuX+k9ZzQOUnfm4E9Z/rAciAW/a/xqnU0Yw+4c0AfX96iDZe778LF/zQqPQ3v Jxz2bbukJ/UwXwm61KF962EhyIqFFfrDg8zKEvXRKz3NKaWyIVomKBMqIhgE+eOB GIPI9x0o0XWr1RPgaZ2iCb7Vsn4mRX7PFlEcdyePPfcZW50tOZmzOLGrQ3ajw1Qh Y742A8j1PRP0Xp0YLDnhXwTOmlOw7wIZl/YItfhj9NfwwyWuzD+WgFZA+Jh+a3pu btaXdhrogo1vvQDYd78La8ivBC4m/mqJfL2TU1OVY46m8R3Uh9rELtH/7Ii+t0yI 9gQnHQQ+DpKIqLGlHBc+5RhYwUp2tnPAIYHR1lDD0hmsbVoPqyT+wYpAi7bb0fGP ffWlbZiPWwtgVe9CmSG6BlRuXBQMka6mEAdDVvyAgdiTdDmRV0V1bLdCKQOG/rvj 4GW5X3gAtNc0KUgzrCFd =8fKi -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e149580.4010...@toell.net
Re: RFS: arp-scan (updated package, new maintainer)
Hi 2011/7/6 Kilian Krause kil...@debian.org: Hi William, On Tue, 2011-07-05 at 18:23 -0600, René Mayorga wrote: On Tue, Jul 05, 2011 at 08:45:41AM +0200, Kilian Krause wrote: Tim, are you agreed that William takes over or do you want to remain as uploader/co-maintainer? Please let him a co-maint for a while, since he is active but busy at this momment. Sounds fine to me. Could you please prepare an upload that would reflect this in a way you both are ok with? I guess letting Tim as Maintainer and putting you into Uploaders would do the trick - together with an update in debian/changelog. Unless there is some mail alias/list you want to use together. Package updated Thanks! Thanks to you -- Best regards, Kilian Cheers -- William Vera bi...@billy.com.mx PGP Key: 1024D/F5CC22A4 Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 -- 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/CAPQrxNKTu+QsSS0PrhPFB3+32XEO4ngRUVgátkotplosf...@mail.gmail.com
RFS: libpar2 (reupload to Debian)
Dear mentors, I am looking for a sponsor for my package libpar2: * Package name: libpar2 Version : 0.2 Upstream Author : Peter Brian Clements Francois Lesueur flesueur AT users.sourceforge.net * URL : http://parchive.sourceforge.net * License : GPL-2+ Description : Library for performing common tasks related to PAR recovery sets LibPar2 allows for the generation, modification, verification, and repairation of PAR v1.0 and PAR v2.0(PAR2) recovery sets, as described in http://parchive.sourceforge.net/docs/specifications/parity-volume-spec/article-spec.html. This package was already part of Debian, but got removed in bug #620497. As I am the maintainer of nzbget (http://packages.qa.debian.org/nzbget), which can use the libpar2 library for automatic detection of broken/incomplete files, I want to re-introduce this package to Debian. I looked through the code and have done some cleanup-work and applied some patches that were posted in the sourceforge tracker. I am aware that I will be the de-facto upstream for the Debian-Users of this package. The package can be found on mentors.debian.net: dget http://mentors.debian.net/debian/pool/main/l/libpar2/libpar2_0.2-2.dsc The packaging information is also available in Git: git://git.debian.org/collab-maint/libpar2.git All comments are appreciated. Cheers, Andreas signature.asc Description: OpenPGP digital signature
Re: Git and tarballs
Andrey Rahmatullin wrote: On Wed, Jul 06, 2011 at 03:12:41PM +0200, Thomas Preud'homme wrote: Does pristine-tar work if the upstream branch contains files which have been removed during repack? Unfortunately the directory and the tarball must have identical contents. That's not true, but the larger the difference the larger the delta file will be. -- see shy jo signature.asc Description: Digital signature
Re: RFS: xnoise
shuerhaaken shuerhaa...@googlemail.com wrote on 2011-07-06 12:54: My motivation for maintaining this package is: I am the developer of this program and I'd like to see it in Debian. In the past I packaged this only for Ubuntu via ppa, but that is not the way it should go. Until now I haven't seen any ITP bug report. Please do this at first. Then please start with a fresh debian/changelog which show the resolved ITP bug with Closes: # Checking of the file debian/rules I see: build: dh_testdir ./configure --prefix=/usr --disable-soundmenu --disable-soundmenu2 dh_auto_build dh_auto_test but than you use the new way with dh $@. Please search for a way using: * override_dh_auto_build * override_dh_auto_configure Details see here: http://kitenet.net/~joey/talks/debhelper/debhelper-slides.pdf Another point: What is the advantage of xnoise to other similar programs? --- Have a nice day. Joachim (Germany) -- 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/20110706204506.79594...@jupiter.home
Re: How to patch a file with changing path?
Am 27.06.2011 21:07, schrieb Kilian Krause: - Why you can't use the zip I don't see. You can easily repack and note that in README.source. Use the get-orig-source target in debian/rules for that and possibly use a ~debian version number. The ~debian is not neccessary though IMHO in this case. Thanks for your advice. I will try to do it this way. -- MfG, Christian Welzel GPG-Key: http://www.camlann.de/de/pgpkey.html Fingerprint: 4F50 19BF 3346 36A6 CFA9 DBDC C268 6D24 70A1 AD15 -- 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/4e14abcd.4040...@camlann.de
Re: Git and tarballs
Le mercredi 6 juillet 2011 20:31:02, Joey Hess a écrit : Andrey Rahmatullin wrote: On Wed, Jul 06, 2011 at 03:12:41PM +0200, Thomas Preud'homme wrote: Does pristine-tar work if the upstream branch contains files which have been removed during repack? Unfortunately the directory and the tarball must have identical contents. That's not true, but the larger the difference the larger the delta file will be. Ah great, good to know. So it rules out some of my arguments/concerns about using tarball Vs tags. Best regards. signature.asc Description: This is a digitally signed message part.
Re: RFS: xnoise
shuerhaaken shuerhaa...@googlemail.com wrote on 2011-07-06 12:54: The package appears to be lintian clean. Unfortunately not! Here is my logging (packaging for testing): N: Setting up lab in /tmp/sVt1potpnA ... N: N: Processing changes file xnoise_0.1.25-1_amd64 (version 0.1.25-1) ... N: N: Processing source package xnoise (version 0.1.25-1) ... I: xnoise source: duplicate-short-description xnoise xnoise-dev W: xnoise source: out-of-date-standards-version 3.9.1 (current is 3.9.2) I: xnoise source: debian-watch-file-is-missing N: N: Processing binary package xnoise (version 0.1.25-1) ... E: xnoise: missing-dependency-on-libc needed by usr/bin/xnoise and 11 others E: xnoise: helper-templates-in-copyright W: xnoise: description-synopsis-starts-with-article W: xnoise: extended-description-line-too-long W: xnoise: extended-description-line-too-long W: xnoise: extended-description-line-too-long I: xnoise: capitalization-error-in-description gstreamer GStreamer W: xnoise: unknown-locale-code default W: xnoise: extra-license-file usr/share/xnoise/license/COPYING W: xnoise: binary-without-manpage usr/bin/xnoise E: xnoise: non-empty-dependency_libs-in-la-file usr/lib/xnoise/libCyclicSaveState.la E: xnoise: non-empty-dependency_libs-in-la-file usr/lib/xnoise/libDatabaseLyrics.la E: xnoise: non-empty-dependency_libs-in-la-file usr/lib/xnoise/libLastfmCovers.la E: xnoise: non-empty-dependency_libs-in-la-file usr/lib/xnoise/libLyricwiki.la E: xnoise: non-empty-dependency_libs-in-la-file usr/lib/xnoise/libTitleToDecoration.la E: xnoise: non-empty-dependency_libs-in-la-file usr/lib/xnoise/libchartlyrics.la E: xnoise: non-empty-dependency_libs-in-la-file usr/lib/xnoise/libmediakeys.la E: xnoise: non-empty-dependency_libs-in-la-file usr/lib/xnoise/libmpris.la E: xnoise: non-empty-dependency_libs-in-la-file usr/lib/xnoise/libnotifications.la E: xnoise: non-empty-dependency_libs-in-la-file usr/lib/xnoise/libxnoisetest.la E: xnoise: non-empty-dependency_libs-in-la-file usr/lib/xnoise/libxnoiseutils.la W: xnoise: postinst-has-useless-call-to-ldconfig W: xnoise: postrm-has-useless-call-to-ldconfig N: N: Processing binary package xnoise-dev (version 0.1.25-1) ... E: xnoise-dev: helper-templates-in-copyright W: xnoise-dev: description-synopsis-starts-with-article W: xnoise-dev: extended-description-line-too-long W: xnoise-dev: extended-description-line-too-long W: xnoise-dev: extended-description-line-too-long I: xnoise-dev: capitalization-error-in-description gstreamer GStreamer --- Have a nice day. Joachim (Germany) -- 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/20110706213750.681f9...@jupiter.home
Re: Git and tarballs
Wolodja Wentland babi...@gmail.com writes: I've recently started to work on some packages and am not sure if I follow best practices when packaging software from git repositories with git-buildpackage. [...] I do the following for OpenAFS (see the supporting scripts in the openafs source package) based on work done by Sam Hartman for krb5, and I'm very happy with it. I'm probably going to eventually adopt the same approach for all other software with a Git upstream. The key feature is that the import-upstream script imports the tarball contents but commits it as a merge between the upstream tag and the local upstream branch, which preserves all of upstream's commit history while simultaneously including in the upstream branch any tarball-generated files that aren't in Git. This isn't required for OpenAFS, but for some other packages I want to use some of the files that are generated as part of the upstream tarball release but aren't checked in. (This is part of debian/README.source for the openafs package.) Importing a New Upstream Release We want to be able to use Git to cherry-pick fixes from upstream, but we want to base the Debian packages on the upstream tarball releases. We also need to strip some non-DFSG files from the upstream tarball releases and imported code, and want to drop the WINNT directory to save some space. This means we follow a slightly complicated method for importing a new upstream release. Follow the following procedure to import a new upstream release: 1. Update the package version in debian/changelog to match the new upstream version. If the new upstream version is a release candidate, don't forget to add ~ before rc so that the versions will sort property. 2. Double-check the TAG setting in debian/rules to be sure it's going to retrieve the correct Git tag. 3. Run debian/rules get-orig-source. This will generate a tarball from the upstream Git tag using git archive, remove the WINNT directory, and create a file named openafs_version.orig.tar.gz in the current directory. 4. Ensure that you have the OpenAFS upstream Git repository available as a remote in the Git repository where you're doing the packaging work and it's up to date: git remote add openafs git://git.openafs.org/openafs.git git fetch openafs This will be required to locate the tag for the new upstream release. 5. Determine the release tag corresponding to this tarball. At the time of this writing, upstream uses tags in the form: openafs-stable-version openafs-devel-version for stable and development releases respectively. version is the version number with periods replaced by underscores. This convention may change, so double-check with git tag. 6. Import the upstream source from the tarball with: debian/import-upstream tarball upstream-tag local-tag where tarball is the tarball created by get-orig-source above, upstream-tag is the corresponding tag from the upstream Git repository, and local-tag is of the form upstream/version where version is the non-Debian portion of the package version number. (In other words, including any tildes, but not the dash and the Debian revision.) 7. Commit the tarball to the repository with pristine-tar, using the new local tag as the reference: pristine-tar commit tarball local-tag 8. Merge the new upstream source into the master branch: git checkout master git merge local-tag where local-tag is the tag you used above. You can also just merge with the upstream branch; either is equivalent. 9. Flesh out the changelog entry for the new version with a summary of what changed in that release, and continue as normal with Debian packaging. Pulling Upstream Changes Upstream releases, particularly stable releases, are relatively infrequent, so it's often desirable to pull upstream changes from the stable branch into the Debian package. This should always be done using git cherry-pick -x so that we can use git cherry to see which changes on the stable branch have not been picked up. The procedure is therefore: 1. Identify the hash of the commit that you want to pull up using git log or other information. 2. git cherry-pick -x hash. If the cherry-pick fails and you have to manually do a merge, follow the instructions to use -c to keep the original commit message as a starting point, but *also* manually add a line like: (cherry picked from commit hash) to the changelog entry where hash is the full hash of the upstream commit. Note that the upstream commits on the stable branch will generally already have a line like this from
Re: Git and tarballs
On Wed, Jul 06, 2011 at 19:02 +0200, Thomas Preud'homme wrote: Personally I don't have any local branch, just remote branches. And when I need to do a bisect for example I will checkout temporarily one of the upstream dev branches. What I have is: origin = upstream repo alioth = alioth repo [ snip ] I think the best is to have a working get-orig-source and then just call uscan + debian/rules get-orig-source and pristine-tar commit the result. Of course you should check the result but the interesting thing about this setup is that people can reproduce the filtering themself when a new version is released and you didn't package it yet. Ok based on this discussion and some great help on #debian-mentors I can now think of the following workflows. I would sincerely appreciate any comments on their merits and problems from people who have more experience than me. (i.e. almost all of you). The main desiderata are: * Intuitive setup that follow the principle of least surprise * debcheckout + git-buildpackage should work out of the box * Easy * Not much work for new upstream releases * Flexibel if something goes boink and adaptations are needed * Integrates well with existing infrastructure (github, alioth, commit hooks that push news to IRC channels or mailing lists, ...) Git-only Branches NameLocal/RemoteMerges From Tracks --- master local upstreamalioth/master upstreamlocal real_upstream/masteralioth/upstream real_upstream/masterremote n/a alioth/master remote n/a alioth/upstream remote n/a Workflow Essentially tags are merged from real_upstream/master into upstream and debian. The debian branch also contains the debian packaging and is the branch from which Debian releases are cut. Packages are built with git-buildpackage and the orig tarball is automagically created with git archive from a tag. (Or?) Questions - * How to differentiate between upstream and packaging history? → git-dch will be flooded with real_upstream changelogs (Or?) * How to make sure that Charles Plessy is happy? (i.e. commit-hooks do not flood channels with upstream changelogs) * I know how to download tags from github with githubredir, but how to handle repositories elsewhere? (in debian/watch) Git only - Repackaging == Essentially the same as before, but with an additional dfsg_free branch that merges from upstream and is merged into master. My main questions here are due to my wish to see repacking done in an automated way by a script which is used in get-orig-source. * Where do you put those scripts? * What to do in the case of NMUs for new versions, such that the script is not applicable anymore and get-orig-version is essentially useless? * Are there collections of these scripts somewhere? I can think of jh_repack right now, but are there other helpers? * What uses get-orig-version? Tarball only Branches NameLocal/RemoteMerges From Tracks - master local n/a alioth/master upstreamlocal n/a alioth/upstream pristine-tarlocal n/a alioth/pristine-tar alioth/master remote n/a alioth/upstream remote n/a altoth/pristine-tar remote n/a Workflow Tarballs are downloaded from upstream and merged with git-import-orig, orig tarballs are constructed from upstream + pristine-tar. Questions - * Is pristine-tar *really* needed here as it will basically say No change from upstream? I have to confess that I don't quite see the merit of pristine-tar when generating tarballs as those should be exactly the same tarball as produced by git archive TAG. Or am I missing something here? Combination === I can easily see how the git-only workflow can also just be changed to use git-import-orig --uscan which somehow feels like the right thing to do. What to do though if new tarballs suddenly needs repacking? In a way I have the feeling that the tarball only workflow is much better suited for packaging, but something in me says that it is wrong as the tarballs are not really needed because everything that is needed is already in the VCS. Sorry for the many questions -- I certainly owe all of you a dram of Talisker when we meet ... -- .''`. Wolodja Wentlandbabi...@gmail.com : :' : `. `'` 4096R/CAF14EFC `- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
RFS: pidgin-latex.
I am looking for a sponsor for my package pidgin-latex. * Package name: pidgin-latex Version : 1.4.4-1 Upstream Author : Benjamin Moll q...@users.sourceforge.net * URL : http://sourceforge.net/projects/pidgin-latex/ * License : GPL-2 Section : net It builds these binary packages: pidgin-latex - Pidgin plugin to display LaTeX formula The package appears to be lintian clean. The upload would fix these bugs: 520658 My motivation for maintaining this package is: usefull plugin to show our math formulas for pidgin. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/pidgin-latex - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/pidgin-latex/pidgin-latex_1.4.4-1.dsc A guide about pidgin-latex could be found: http://www.wangtang.de/pidgin-latex/ I would be glad if someone uploaded this package for me. Kind regards Elías Alejandro -- 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/20110706211529.GA2401@debianero
Re: Git and tarballs
On Wed, Jul 06, 2011 at 12:53 -0700, Russ Allbery wrote: Wolodja Wentland babi...@gmail.com writes: I've recently started to work on some packages and am not sure if I follow best practices when packaging software from git repositories with git-buildpackage. I do the following for OpenAFS (see the supporting scripts in the openafs source package) based on work done by Sam Hartman for krb5, and I'm very happy with it. I'm probably going to eventually adopt the same approach for all other software with a Git upstream. Thanks Russ for officially blowing my mind :) -- But seriously, that *feels* like a good approach. [ ... ] but for some other packages I want to use some of the files that are generated as part of the upstream tarball release but aren't checked in. Ok, this is not necessary for me right now. Do you know how often the tarball does *not* correspond to a git archive TAG and therefore needs to be stored explicitly? Importing a New Upstream Release [ ... ] 3. Run debian/rules get-orig-source. This will generate a tarball from the upstream Git tag using git archive, remove the WINNT directory, and create a file named openafs_version.orig.tar.gz in the current directory. How stable is get-orig-source across releases? What would I do if upstream suddenly decides to change the internal structure of the tarball? Why isn't the actual tarball tampering implemented as a standalone script and called from get-orig-sources, which would allow you to also apply it to manually downloaded tarballs? 7. Commit the tarball to the repository with pristine-tar, using the new local tag as the reference: pristine-tar commit tarball local-tag Why exactly is this needed when the tarball can be cut from upstream tags? -- .''`. Wolodja Wentlandbabi...@gmail.com : :' : `. `'` 4096R/CAF14EFC `- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Re: Git and tarballs
Wolodja Wentland babi...@gmail.com writes: On Wed, Jul 06, 2011 at 12:53 -0700, Russ Allbery wrote: [ ... ] but for some other packages I want to use some of the files that are generated as part of the upstream tarball release but aren't checked in. Ok, this is not necessary for me right now. Do you know how often the tarball does *not* correspond to a git archive TAG and therefore needs to be stored explicitly? This will be the case for anyone who is doing traditional tarball-based releases that contain generated files. The Autoconf/Automake stuff is the most common, but other possibilities include generated protocol documentation, man pages generated via pod2man, or anything else where upstream pre-generates some things. A good argument can be made that the Debian package build should regenerate all of that from scratch, but even when I'm doing that, I like to have the *real* upstream tarball release be the basis of the Debian packaging, so including that in Git makes pristine-tar and so forth much more efficient. This is particularly true when upstream signs their tarball releases. 3. Run debian/rules get-orig-source. This will generate a tarball from the upstream Git tag using git archive, remove the WINNT directory, and create a file named openafs_version.orig.tar.gz in the current directory. How stable is get-orig-source across releases? What would I do if upstream suddenly decides to change the internal structure of the tarball? Why isn't the actual tarball tampering implemented as a standalone script and called from get-orig-sources, which would allow you to also apply it to manually downloaded tarballs? For OpenAFS, I do it this way because I don't actually use the released tarball, so the get-orig-source target generates a tarball. For a package where I was using a released tarball for the reasons described above, I would dispense with this target entirely and just use uscan to download the tarball (or acquire it some other way). Here's the OpenAFS get-orig-source, for the record. As you can see, it doesn't change much. # These variables are used by get-orig-source, to construct dkms.conf, and # to set the build version. You will need to change TAG to package stable # releases instead of experimental releases. DEBIAN := $(shell dpkg-parsechangelog | grep ^Version: | cut -d' ' -f2) DEBVERS := $(shell echo '$(DEBIAN)' | cut -d- -f1) VERSION := $(shell echo '$(DEBVERS)' | sed -e 's/[+-].*//' -e 's/~//g') TAG := $(shell echo 'openafs-stable-$(VERSION)' | sed 's/\./_/g') REPO:= git://git.openafs.org/openafs.git # Upstream does tarball releases for major releases, but not for point # relesaes, and the tarball releases are split into src and doc and # contain the WINNT directory. Dropping WINNT, which is not used on # Debian, saves a substantial amount of space in the source package, and # there's no reason to include the files generated by regen.sh when we're # going to run it again ourselves anyway. # # This rule therefore generates an upstream tarball from the upstream Git # tag, rather than the tarball release, without the generated files that # are not in Git and without the WINNT directory. It assumes that # git-core is installed and there's network connectivity to the upstream # repository. get-orig-source: git archive --remote='$(REPO)' --prefix='openafs_$(DEBVERS).orig/' \ --format=tar '$(TAG)' | tar xf - rm -r openafs_$(DEBVERS).orig/src/WINNT tar cf openafs_$(DEBVERS).orig.tar openafs_$(DEBVERS).orig rm -r openafs_$(DEBVERS).orig gzip -9 openafs_$(DEBVERS).orig.tar 7. Commit the tarball to the repository with pristine-tar, using the new local tag as the reference: pristine-tar commit tarball local-tag Why exactly is this needed when the tarball can be cut from upstream tags? Each time you regenerate the upstream tarball from the Git repository, it will change. You have to store pristine-tar data for one specific generated tarball, or someone who has only the repository won't be able to recreate the tarball used in Debian packaging. -- 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/87oc17az0a@windlord.stanford.edu
Re: Git and tarballs
On Wed, Jul 06, 2011 at 14:19 -0700, Russ Allbery wrote: Wolodja Wentland babi...@gmail.com writes: How stable is get-orig-source across releases? For a package where I was using a released tarball for the reasons described above, I would dispense with this target entirely and just use uscan to download the tarball (or acquire it some other way). And certain helpers (jh_repack) can be added to the watch file or you just work with the downloaded tarball in the get-orig-source. Is get-orig-source called by anything or is it merely a nice target to have so life is easier for other maintainers and oneself when preparing new releases? Why exactly is this needed when the tarball can be cut from upstream tags? Each time you regenerate the upstream tarball from the Git repository, it will change. You have to store pristine-tar data for one specific generated tarball, or someone who has only the repository won't be able to recreate the tarball used in Debian packaging. Ack, and it also has the added benefit that Debian is always able to regenerate the tarball even if upstream and all its repositories/tarballs disappeared completely. Thanks Russ for your kind help and I can see much clearer now. -- .''`. Wolodja Wentlandbabi...@gmail.com : :' : `. `'` 4096R/CAF14EFC `- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Re: Git and tarballs
Wolodja Wentland babi...@gmail.com writes: Is get-orig-source called by anything or is it merely a nice target to have so life is easier for other maintainers and oneself when preparing new releases? The latter. One could replace it with a shell script, but it's a semi-standard because it's mentioned in Policy. Each time you regenerate the upstream tarball from the Git repository, it will change. You have to store pristine-tar data for one specific generated tarball, or someone who has only the repository won't be able to recreate the tarball used in Debian packaging. Ack, and it also has the added benefit that Debian is always able to regenerate the tarball even if upstream and all its repositories/tarballs disappeared completely. Right. But for me it's convenience that's the biggest factor. I like being able to pull down the repository from anywhere and build a new Debian revision of the package without having to hunt down or download the original upstream tarball separately. With Subversion, I ended up checking the upstream tarballs into the repository to accomplish the same end, but of course that gets very bloated in terms of space very quickly. -- 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/87zkkr9hiw@windlord.stanford.edu
RE : : RFS: autoconf-archive (updated package)
Please do not upload directly, i will upload git tree before under collab maint and postthe final ppackage here. It is more a rfc. Bastien Le 6 juil. 2011 15:14, Bastien ROUCARIES roucaries.bast...@gmail.com a écrit : Dear mentors, I am looking for a sponsor for the new version 1:2011.04.12-1 of the package autoconf-archive. It builds these binary packages: autoconf-archive - Autoconf Macro Archive The upload would fix these bugs: 214089, 568413, 572669, 584180, 593838, 622369 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/autoconf-archive - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/autoconf-archive/autoconf-archive_2011.04.12-1.dsc I would be glad if someone uploaded this package for me. Note that previous maintainer was marked MIA and I will comaintain it with Deng Xiyue Notice also that copyright was fixed and DEP5 They are two lintian warnings that are bug on lintian: - #607694 if you are using stable lintian - new version: autoconf-archive source: git-patches-not-exported but they are exported see debian/patches/series (will report) and I have no patch for now Kind regards bastien roucaries
