Re: Sponsor Checklist
On Tue, 31 Jul 2007 07:21:55 +0530 Kumar Appaiah [EMAIL PROTECTED] wrote: I wish to know how you can evaluate skill level. For example, if ative contribution to a FOSS project is a required skill, I really won't fit in. You mean upstream? No, it isn't a required skill for all maintainers but it DOES affect how the sponsor assesses the capabilities of the maintainer, especially with regard to packages that have a dead upstream. All the Debian bugs for the package become the responsibility of the maintainer - you - so if there is no upstream team, bugs that would have just been forwarded now have to be fixed within Debian, by the maintainer. But if it is just knowledge of issues with the package and packaging techniques, that's all right. Of course, I realize that it's my responsibilities to get bugs fixed as well. That's the point - if you do not have the skills to fix upstream bugs, you are dependent on upstream remaining viable and active. This may seem fine now but it is not at all uncommon for a small but active upstream team to become completely inactive quite suddenly due to various real-life issues. This typically starts with a build up of unfixed bugs and often escalates to one or more Release-Critical bugs in Debian. You, as maintainer, *must* be able to fix these problems or the package will be removed from Debian. Sponsors who upload packages that result in more than a fair share of RC bugs are not looked upon favourably by the release team or other parts of Debian. (This is why I do not sponsor PHP packages, despite using PHP extensively myself.) ;-) So, how do you propose to evaluate people? Though evaluation is necessary, isn't it tough for people who don't really have a FOSS contributor background? The evaluation is simply asking (or determining from answers to other questions) whether the maintainer is able to fix bugs in the upstream code. The rest follows on from that. Maintaining packages in Debian *is tough* for people who have no upstream experience or knowledge simply because they are dependent on others to fix certain bugs. It is easier for Debian *and* for upstream if the Debian maintainer has detailed knowledge of the upstream code because bug reports can include working patches. One example is architecture-specific bugs - upstream have no real way of fixing bugs that only appear on some of the supported Debian architectures because they don't have access to the hardware. If the Debian maintainer has insufficient knowledge of the upstream code to fix problems specific to Debian, these kind of bugs tend to escalate in severity until either someone else has to do an NMU or the package is removed from testing. This is why I also do not sponsor python, ruby, mono/C# or KDE packages. (I'm OK with C++ for non-GUI apps but I don't develop in KDE - don't even have it installed on any of my machines - and I have no idea where to start with the KDE/Qt class libraries.) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpStTzXhAjll.pgp Description: PGP signature
Re: Sponsor Checklist
On Tue, Jul 31, 2007 at 07:53:24AM +0100, Neil Williams wrote: Sponsors who upload packages that result in more than a fair share of RC bugs are not looked upon favourably by the release team or other parts of Debian. (This is why I do not sponsor PHP packages, despite using PHP extensively myself.) ;-) Double standards! :-) Maintaining packages in Debian *is tough* for people who have no upstream experience or knowledge simply because they are dependent on others to fix certain bugs. It is easier for Debian *and* for upstream if the Debian maintainer has detailed knowledge of the upstream code because bug reports can include working patches. One example is architecture-specific bugs - upstream have no real way of fixing bugs that only appear on some of the supported Debian architectures because they don't have access to the hardware. If the Debian maintainer has insufficient knowledge of the upstream code to fix problems specific to Debian, these kind of bugs tend to escalate in severity until either someone else has to do an NMU or the package is removed from testing. I understand. As you say, the quality of the package in Debian is also a function of the maintainer's familiarity with the package. Thanks for the clarifications! Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: Sponsor Checklist
On 11096 March 1977, Neil Williams wrote: * Is the package lintian/linda clean? Finally, what do other sponsors think about linda? Personally, I uninstalled it long ago as simply unreliable. Are there genuine issues that linda *can* find which lintian cannot? Is linda still riddled with false-positives and erroneous test results? Is linda worth using? Binary foo is linked with version 1 and 2 of libfoobar is something lintian doesnt get, AFAIK. Yes, linda is worth using. And if you find things in it that arent good you should file bugs, not uninstall it. :) -- bye Joerg [http://www.youam.net/stuff/info...-hosting.de/server-info.php] Um eine schnelle Netzanbindung zu gewährleisten hat der Server eine Realtek-Marken-Netzwerkkarte. Eine Realtek-Karte ist im Vergleich zu billigeren Karten oft etwas leistungsstärker. pgpD1PcrZ6san.pgp Description: PGP signature
Re: Sponsor Checklist
Hi, * Kumar Appaiah [EMAIL PROTECTED] [2007-07-31 13:35]: On Mon, Jul 30, 2007 at 06:59:30PM -0700, Don Armstrong wrote: [...] Another point I wish to make, to add to what Manoj has already said, is that sponsors _may_ wish to insist that the uploaded packages be pdebuilt, just to be sure that the packages are build on a clean, sid chroot. That won't work because you can't ensure that the chroot or pbuilder of the maintainer is up2date :) Kind regards Nico -- Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. http://people.debian.org/~nion/sponsoring-checklist.html pgpS0ht64fl71.pgp Description: PGP signature
RFS: inkblot
Dear mentors, I am looking for a sponsor for my package inkblot. * Package name: inkblot Version : 0.99.8-1 Upstream Author : Mike Newman [EMAIL PROTECTED], Thierry Merle [EMAIL PROTECTED] * URL : http://www.mikegtn.net/1117 * License : GPL 2 or later Section : admin It builds these binary packages: inkblot- GNOME ink level monitor The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/i/inkblot - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/i/inkblot/inkblot_0.99.8-1.dsc I would be glad if someone uploaded this package for me. Kind regards Matvey Kozhev
Re: RFS: acr38 - 1.7.9-3 (minor update)
Hi, Could someone review and upload acr38 1.7.9-3 Your changes look fine, I've uploaded it. Thanks! Thijs pgputMoPlzDYu.pgp Description: PGP signature
RFS: qink
Dear mentors, I am looking for a sponsor for my package qink. * Package name: qink Version : 0.3.1-1 Upstream Author : me * URL : http://code.google.com/p/qink * License : GPL 2 or later Section : admin It builds these binary packages: qink - Qt4 ink level monitor The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/qink - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/qink/qink_0.3.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards Matvey Kozhev
Re: RFS: open-invaders
Hi, Thanks for looking at it Alexander, and sorry that I did not answer before but I wasn't subscribed to this list and so did not see your reply before. I fixed everything you said (it's online on mentors.deban.net [1]) except point 3, that one about the architecture independent stuff. You mean that the data should be in a separate binary package (open-invaders-data)? If so, could you appoint me to a tutorial on how to do that? (I looked at the contents of the Debian New Maintainer's Guide but it doesn't look like there's anything related to that). Also, currently the game is only building on i386 (upstream author promised to fix that, but it may still need some time), so is this necessary now? [1] http://mentors.debian.net/debian/pool/main/o/open-invaders/ Thanks again, Siegfried-Angel Gevatter Pujals (RainCT) On 18 Jul, 17:20, Alexander Schmehl [EMAIL PROTECTED] wrote: Hi! * Siegfried-Angel [EMAIL PROTECTED] [070705 22:18]: * Package name: open-invaders Version : 0.2-1 Upstream Author : Darryl LeCount * URL :http://www.jamyskis.net/invaders.php * License : GPLv2 Section : games Problems with your package: - Binary is installed to /usr/bin/open-invaders, but should be /usr/games - Data ist installed to /usr/share/open-invaders/, but should be /usr/share/games/open-invaders/ - You install 3.1 MB of arch independent stuff which should go in a sepperate arch:all package - Your package contains /usr/include/ - In your debian/rules you should replace -$(MAKE) distclean with [ ! -f Makefile ] || $(MAKE) distclean (as lintian would have told you) Rest seemst fine. If you fix those, I'll upload your package. Yours sincerely, Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mini-dinstall, repository signing and apt-get authentication
Neil Time for a bug report, I think. But in order to actually get the Neil thing working, I need more help. Have you ever filed the report? I can't find it searching on b.d.o. Neil I get: Neil Failed to fetch Neil http://www.linux.codehelp.co.uk/packages/unstable/amd64/Release Neil Unable to find expected entry Packages in Meta-index file (malformed Release file?) And this is my main question: have you figured out what causes this error? I am pretty much in banging-head-against-wall mode now. Let me describe my situation: I have a flat (single directory) archive of personal debs. I see absolutely no point in maintaining code names and suites and what not. So I put the debs into /var/local/debian (which apache aliases to /debian/) on my.server.com, and in the clients' sources.list I put deb http://my.server.com/debian/ ./ I generate the Packages.gz file by cd /var/local/debian apt-ftparchive packages ./ | gzip - Packages.gz and the Release file by cd /var/local/debian apt-ftparchive release ./ /tmp/Release mv /tmp/Release . Followed by apt-get update on the clients of course. All this works flawlessly until I introduce signing. As soon as I add a Release.gpg file (generated by cd /var/local/debian gpg -abs -o Release.gpg Release) apt-get starts giving me the above error message. Now the wording made me think that perhaps perhaps I should NOT compress the Packages file, so I tried to omit the gzip step above. But then apt-get complains it cannot retrieve Packages file! rant It seems the security layer of apt was a quick hack which introduced this sort of confusion, instead of the thoughtful redesign it needed. /rant Thanks for your help in advance. -- This line is completely ham. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mini-dinstall, repository signing and apt-get authentication
On 31 Jul 2007 09:53:16 -0400 Ian Zimmerman [EMAIL PROTECTED] wrote: Neil Time for a bug report, I think. But in order to actually get the Neil thing working, I need more help. I wish you'd included the fact that the original email is from: Date: 2006-07-28 21:09 +100 It's very confusing getting a reply from an email that old! http://lists.debian.org/debian-mentors/2006/07/msg00345.html Have you ever filed the report? I can't find it searching on b.d.o. Didn't need to - I switched to reprepro instead. mini-dinstall isn't really designed for my kind of repository and I didn't see any point filing a bug report to make mini-dinstall more like reprepro when reprepro was (and is) simply a better choice for anything more than a very simple repository. And this is my main question: have you figured out what causes this error? Yes - the error is caused by not using reprepro. :-) Let me describe my situation: I have a flat (single directory) archive of personal debs. I see absolutely no point in maintaining code names and suites and what not. reprepro doesn't force these on you but it does not stop you adding them later either. I generate the Packages.gz file by cd /var/local/debian apt-ftparchive packages ./ | gzip - Packages.gz Yuk. There should be no need to do this. and the Release file by cd /var/local/debian apt-ftparchive release ./ /tmp/Release mv /tmp/Release . Nor that. All this works flawlessly until I introduce signing. As soon as I add a Release.gpg file (generated by cd /var/local/debian gpg -abs -o Release.gpg Release) apt-get starts giving me the above error message. Now the wording made me think that perhaps perhaps I should NOT compress the Packages file, so I tried to omit the gzip step above. But then apt-get complains it cannot retrieve Packages file! No. The error is because mini-dinstall doesn't support what you want. rant It seems the security layer of apt was a quick hack which introduced this sort of confusion, instead of the thoughtful redesign it needed. /rant No. IMHO mini-dinstall is the quick hack which isn't capable of supporting advanced features like SecureApt. Use the right tool for the job. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpgwP4WtNOi6.pgp Description: PGP signature
Re: RFS: open-invaders
On Tue, Jul 31, 2007 at 03:33:40PM +0200, Siegfried-Angel wrote: Hi, Thanks for looking at it Alexander, and sorry that I did not answer before but I wasn't subscribed to this list and so did not see your reply before. I fixed everything you said (it's online on mentors.deban.net [1]) except point 3, that one about the architecture independent stuff. You mean that the data should be in a separate binary package (open-invaders-data)? If so, could you appoint me to a tutorial on how to do that? (I looked at the contents of the Debian New Maintainer's Guide but it doesn't look like there's anything related to that). Also, currently the game is only building on i386 (upstream author promised to fix that, but it may still need some time), so is this necessary now? Maybe this will help? http://lists.debian.org/debian-mentors/2005/11/msg00042.html Or check some multiple-binary packages [0], or just the ./debian/control output of dh_make m. The architecture problems are kind of disappointing.. Justin [0] Ones for which there are multiple Binary packages listed for the given source Package in apt-cache showsrc output. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[help] Merging tag and trunk in a SVN repository.
Dear Mentors, I was preparing a new version of the package emboss when came an upstream fix that I wished to include in the current version in Debian. I tried to do all whithin the SVN repository holding the debian directory, but now it is a mess: - I reverted to the last revision which was workable; - I added upstream's patch; - I svn-buildpackage --svn-ignore --svn-tag'ed it; - I realised that --svn-ignore was not what I wanted, and then copied the changed files to the ../tags/numversion directory and commited it. - Then I ran svn-buildpackage in tags/numversion to prepare the source package to upload. But now I do not know how to merge this into the last work-in-progress revision... I would need to merge the tags/numversion and the trunk, but: sorbet【emboss】$ LANG=C svn merge tags/5.0.0-2/ trunk/ svn: A working copy merge source needs an explicit revision It seems that the puropose of svn merge is to work within revisions, not between tags and trunks. Could somebody point me the right tool for this ? Have a nice day, -- Charles Plessy Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mini-dinstall, repository signing and apt-get authentication
Ian And this is my main question: have you figured out what causes this error? Neil Yes - the error is caused by not using reprepro. Neil :-) I am afraid from my POV this is not particularly funny. The documentation (i.e. the apt manual and the secure apt wiki) doesn't mention reprepro (or mini-dinstall), I was trying to do this the documented way (well, except having a flat directory), and it didn't work. I don't feel just use whiz-bang tool foo is the correct answer in such a situation, or at least it is not the complete answer. That would include at least acknowledging that the documentation is wrong. Ian Let me describe my situation: I have a flat (single directory) archive Ian of personal debs. I see absolutely no point in maintaining code names Ian and suites and what not. Neil reprepro doesn't force these on you but it does not stop you adding Neil them later either. OK, I'll take a look at reprepro. Ian I generate the Packages.gz file by Ian Ian cd /var/local/debian apt-ftparchive packages ./ | gzip - Ian Packages.gz Neil Yuk. There should be no need to do this. Ian and the Release file by Ian Ian cd /var/local/debian apt-ftparchive release ./ /tmp/Release Ian mv /tmp/Release . Neil Nor that. This is all straight from the wiki. Ian All this works flawlessly until I introduce signing. As soon as I Ian add a Release.gpg file (generated by cd /var/local/debian gpg Ian -abs -o Release.gpg Release) apt-get starts giving me the above Ian error message. Now the wording made me think that perhaps perhaps Ian I should NOT compress the Packages file, so I tried to omit the Ian gzip step above. But then apt-get complains it cannot retrieve Ian Packages file! Neil No. The error is because mini-dinstall doesn't support what you want. Huh? I didn't use mini-dinstall at all. I was generating the metadata manually, in the documented format. Neil No. IMHO mini-dinstall is the quick hack which isn't capable of Neil supporting advanced features like SecureApt. Again, I didn't use mini-dinstall - I generated the Secure Apt files as documented. -- This line is completely ham. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: repository signing and apt-get authentication
On 31 Jul 2007 11:14:45 -0400 Ian Zimmerman [EMAIL PROTECTED] wrote: Ian And this is my main question: have you figured out what causes Ian this error? Neil Yes - the error is caused by not using reprepro. Neil :-) I am afraid from my POV this is not particularly funny. The documentation (i.e. the apt manual and the secure apt wiki) doesn't mention reprepro (or mini-dinstall), I was trying to do this the documented way (well, except having a flat directory) I have no idea about the docs, I just use the tool(s) that work. I was using mini-dinstall, you appear not to be. Any solution I used would not be applicable to your usage. , and it didn't work. I don't feel just use whiz-bang tool foo is the correct answer in such a situation, or at least it is not the complete answer. That would include at least acknowledging that the documentation is wrong. I've no idea if the documentation that you mention is right or wrong. I was using mini-dinstall - you are not. I'm not sure why you think my experience is applicable to a different method. Ian All this works flawlessly until I introduce signing. As soon as Ian I add a Release.gpg file (generated by cd /var/local/debian Ian gpg -abs -o Release.gpg Release) apt-get starts giving me the Ian above error message. Now the wording made me think that perhaps Ian perhaps I should NOT compress the Packages file, so I tried to Ian omit the gzip step above. But then apt-get complains it cannot Ian retrieve Packages file! Neil No. The error is because mini-dinstall doesn't support what you Neil want. Huh? I didn't use mini-dinstall at all. I was generating the metadata manually, in the documented format. Then maybe it would have been an idea to change the subject line of this year-old reply??!! I have no idea how to continue this thread - I didn't use the method you describe, the bug report that I was considering (a YEAR ago!) is completely inapplicable to your method because the bug was meant to be against mini-dinstall, not the docs. I am now using reprepro exclusively and I don't think I can help you - other than advise you, as I did, to switch to reprepro. I know it works. I'm not responsible for the docs and I'm not a repository expert or maintainer of repository-related packages but if some of the docs are on the wiki, feel free to correct them. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgphlZv3PfQxj.pgp Description: PGP signature
RFS: dosbox (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.71-0.1 of my package dosbox. It builds these binary packages: dosbox - A x86 emulator with Tandy/Herc/CGA/EGA/VGA/SVGA graphics, sound a The package appears to be lintian clean. The upload would fix these bugs: 361554, 375517, 415696, 417700 and is built using cdbs. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/dosbox - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/dosbox/dosbox_0.71-0.1.dsc I would be glad if someone uploaded this package for me. Kind regards Markus Schölzel
Re: Sponsor Checklist
On Mon, 30 Jul 2007 21:40:26 -0500 Manoj Srivastava [EMAIL PROTECTED] wrote: Hmm. Since the DD/sponsor is the one who creates the uploaded packages, they do not have to insis; they can just make it so. I hope DD's do the actual tend build/clean/rebuild/piuparts-run personally. I can never run piuparts - it just takes far too long over my crippled internet connection. Isn't there some way of getting piuparts to use the cached archives like pbuilder does? I already use the existing pbuilder chroot but downloading ALL dependencies EVERY TIME piuparts runs is completely useless to me. It's far easier for me to run sudo pbuilder update, login copy the necessary built files into the chroot and test from there. I fail to understand why piuparts is just so difficult to use without a super fast connection. Just how long is it meant to take to run the full piuparts test against sid, lenny and etch for a Gnome package on a 1Mb connection? I gave up after FOUR HOURS. Even a single piuparts run against sid takes far too long for me to do anything useful with it. Not using piuparts (or linda) hasn't been a hindrance so far. I just can't see why piuparts is recommended so often. pbuilder/pdebuild are *far* more useful, IMHO. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpHVWmh3JZWO.pgp Description: PGP signature
Re: mini-dinstall, repository signing and apt-get authentication
Le mardi 31 juillet 2007 à 12:51 -0400, Ian Zimmerman a écrit : Neil reprepro doesn't force these on you but it does not stop you Neil adding them later either. Ian OK, I'll take a look at reprepro. I did. reprepro still wants me to have a pool and dists subdirectories, at the very least. This just makes it more complicated to maintain, in particular to upload the debs. I don't think reprepro is the right tool for my job, either. Again, this is _not_ a mirror. It is just a bunch of debs (about 30 right now) that I build myself on a desktop machine, then upload to share with other client machines. Is _anyone_ else doing this? Seems like a natural thing to do. I do, and I use reprepro. And I think I have less than 30 packages in my repository! This tool is both easy and powerful, just as I like. Read carfeully the documentation and you will understand reprepro is not just a mirror tool, and uploads made by tools like dupload or dput are processed very easily directly by reprepro. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mini-dinstall, repository signing and apt-get authentication
On 31 Jul 2007 12:51:39 -0400, Ian Zimmerman [EMAIL PROTECTED] wrote: I did. reprepro still wants me to have a pool and dists subdirectories, at the very least. This just makes it more complicated to maintain, in particular to upload the debs. I don't think reprepro is the right tool for my job, either. Again, this is _not_ a mirror. It is just a bunch of debs (about 30 right now) that I build myself on a desktop machine, then upload to share with other client machines. Is _anyone_ else doing this? Seems like a natural thing to do. I use reprepro for exactly this purpose, and I only have about 10 debs in it at any given time. reprepro just makes it easier to handle all the Packages.gz/Release creation and signing. Adding new files is as sinple as reprepro include sid ... and removing them reprepro remove sid ..., everything else is handled for you. How is uploading complicated? I added a post-upload script to dupload so I can just do (on any machine) dupload --to sid foo.changes apt-get update and it all just works, I don't even have to log in to the reprepro machine. Cameron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sponsor Checklist
Joerg Jaspert [EMAIL PROTECTED] writes: On 11096 March 1977, Neil Williams wrote: Finally, what do other sponsors think about linda? Personally, I uninstalled it long ago as simply unreliable. Are there genuine issues that linda *can* find which lintian cannot? Is linda still riddled with false-positives and erroneous test results? Is linda worth using? Binary foo is linked with version 1 and 2 of libfoobar is something lintian doesnt get, AFAIK. That's because literally linking the same binary against two versions of the same library is impossible without weird ELF hacking so far as I know. What I believe linda is actually finding is that the binary is linked with version 2 of libfoobar and also linked to another library which is itself linked to version 1 of libfoobar. In other words, the problem is only detectable via transitive dependencies and looking at packages other than the package being checked, which is explicitly out of scope for lintian. I'm not sure how well linda really does with checking this. I'm fairly sure that you have to have all of the dependencies of the package installed on the system for this check to work, so the output of this check will change depending on what packages you have installed. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: info about puiparts
On Tue, 31 Jul 2007 23:14:51 +0800, Thomas Goirand [EMAIL PROTECTED] said: Manoj Srivastava wrote: Hmm. Since the DD/sponsor is the one who creates the uploaded packages, they do not have to insis; they can just make it so. I hope DD's do the actual tend build/clean/rebuild/piuparts-run personally. Therefore I actually am only insistent on the sources being available, since I usually discard the pre-build .debs anyway. Excuse my ignorance, but where can I find infos about piuparts? __ apt-cache show piuparts Description: .deb package installation, upgrading, and removal testing tool piuparts tests that .deb packages (as used by Debian) handle installation, upgrading, and removal correctly. It does this by creating a minimal Debian installation in a chroot, and installing, upgrading, and removing packages in that environment, and comparing the state of the directory tree before and after. piuparts reports any files that have been added, removed, or modified during this process. . piuparts is meant as a quality assurance tool for people who create .deb packages to test them before they upload them to the Debian package archive. Homepage: http://piuparts.alioth.debian.org/ manoj -- This is the LAST time I take travel suggestions from Ray Bradbury! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: repository signing and apt-get authentication
On 31 Jul 2007 12:51:39 -0400 Ian Zimmerman [EMAIL PROTECTED] wrote: Neil reprepro doesn't force these on you but it does not stop you Neil adding them later either. Ian OK, I'll take a look at reprepro. I did. reprepro still wants me to have a pool and dists subdirectories, I don't see the harm. It is the expected structure of a repository and makes it easy for other tools to work with it. If you want a repository that is easy to maintain, use a tool that creates a layout that most tools will understand. It sounds like you want a simple-complex repository - 'simple' bits able to support the complex requirements of SecureApt. What is so wrong with a slightly increased directory tree if it gives you the ease of maintenance AND SecureApt? Seems to me you have two choices: Use what you had without SecureApt. Use the directory layout and tools that support SecureApt. IMHO the first is short-sighted and unmaintainable because further changes in repository handling will only increase your difficulty in maintaining a bespoke layout. at the very least. This just makes it more complicated to maintain, in particular to upload the debs. dput ? I don't think reprepro is the right tool for my job, either. Again, this is _not_ a mirror. Neither are my reprepro repositories. One handles less than a dozen packages. If you want apt authentication to work with your layout, you have to ensure that it abides by how apt expects to use the layout - the easiest way to do that is with a tool that is known to work with apt authentication, like reprepro. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpRxQApfBh56.pgp Description: PGP signature
Secure apt Packages file confusion [Was: repository signing and apt-get authentication]
Unable to find expected entry Packages in Meta-index file (malformed Release file?) Ian And this is my main question: have you figured out what causes this Ian error? Neil I've no idea if the documentation that you mention is right or Neil wrong. I was using mini-dinstall - you are not. I'm not sure why Neil you think my experience is applicable to a different method. [...] Neil Then maybe it would have been an idea to change the subject line Neil of this year-old reply??!! Fair enough. So, does anyone have an idea what's really causing that error? -- This line is completely ham. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sponsor Checklist
On Tue, Jul 31, 2007 at 05:53:49PM +0100, Neil Williams wrote: On Mon, 30 Jul 2007 21:40:26 -0500 Manoj Srivastava [EMAIL PROTECTED] wrote: Hmm. Since the DD/sponsor is the one who creates the uploaded packages, they do not have to insis; they can just make it so. I hope DD's do the actual tend build/clean/rebuild/piuparts-run personally. I can never run piuparts - it just takes far too long over my crippled internet connection. Isn't there some way of getting piuparts to use the cached archives like pbuilder does? Perhaps apt-cacher? It uses /var/cache/apt-cacher/ though perhaps it could use .../apt/ I don't know if this would pull in things downloaded by apt and not -cacher.. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: repository signing and apt-get authentication
Neil Williams wrote: Seems to me you have two choices: Use what you had without SecureApt. Use the directory layout and tools that support SecureApt. There is nothing in apt's security checking code that requires any particular repository structure. Example of apt repository that uses a flat directory structure, created by mini-dinstall, including fully automated creation of signed Release files usable by apt: http://kitenet.net/~joey/debian/unstable/ -- see shy jo signature.asc Description: Digital signature
Re: mini-dinstall, repository signing and apt-get authentication
Ian I don't think reprepro is the right tool for my job, either. Ian Again, this is _not_ a mirror. It is just a bunch of debs (about Ian 30 right now) that I build myself on a desktop machine, then upload Ian to share with other client machines. Ian Ian Is _anyone_ else doing this? Seems like a natural thing to do. Cameron I use reprepro for exactly this purpose, and I only have about Cameron 10 debs in it at any given time. reprepro just makes it easier Cameron to handle all the Packages.gz/Release creation and Cameron signing. Adding new files is as sinple as reprepro include sid Cameron ... and removing them reprepro remove sid ..., everything Cameron else is handled for you. Cameron How is uploading complicated? I added a post-upload script to Cameron dupload so I can just do (on any machine) dupload --to sid Cameron foo.changes apt-get update and it all just works, I don't Cameron even have to log in to the reprepro machine. dupload?? Cheesus. I don't even know what that is. I see that I have to describe exactly what I do from the point of build. In the source directory of a package, I do fakeroot debian/rules binary that will create a file ../foo.deb, then scp ../foo.deb my.server.com:/var/local/debian then I ssh to my.server.com and do the steps I described in my first mail (as given by the wiki). Why does it have to be any more complicated than this? It worked pre-signing. If it can't work with signing anymore, why? And shouldn't this be documented? -- This line is completely ham. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sponsor Checklist
On Tue, Jul 31, 2007 at 01:21:23PM -0400, Justin Pryzby wrote: On Tue, Jul 31, 2007 at 05:53:49PM +0100, Neil Williams wrote: On Mon, 30 Jul 2007 21:40:26 -0500 Manoj Srivastava [EMAIL PROTECTED] wrote: Hmm. Since the DD/sponsor is the one who creates the uploaded packages, they do not have to insis; they can just make it so. I hope DD's do the actual tend build/clean/rebuild/piuparts-run personally. I can never run piuparts - it just takes far too long over my crippled internet connection. Isn't there some way of getting piuparts to use the cached archives like pbuilder does? Perhaps apt-cacher? It uses /var/cache/apt-cacher/ though perhaps it could use .../apt/ I don't know if this would pull in things downloaded by apt and not -cacher.. I use that, and point *everything* at it, my sources.list, my pbuilder chroots, and piuparts. That way everything one thing downloads gets used by all others. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: mini-dinstall, repository signing and apt-get authentication
On 31 Jul 2007 13:59:34 -0400, Ian Zimmerman [EMAIL PROTECTED] wrote: Cameron How is uploading complicated? I added a post-upload script to Cameron dupload so I can just do (on any machine) dupload --to sid Cameron foo.changes apt-get update and it all just works, I don't Cameron even have to log in to the reprepro machine. dupload?? Cheesus. I don't even know what that is. Are you completely against using tools to make your life easier? You're saying you want it to be less complicated, but you're already over-complicating it by not using tools others have built for exactly this situation. dupload just automates the scp to a server and allows you to do more with it. I see that I have to describe exactly what I do from the point of build. In the source directory of a package, I do fakeroot debian/rules binary dpkg-buildpackage might be better. that will create a file ../foo.deb, then scp ../foo.deb my.server.com:/var/local/debian Here's where dupload would come in handy then I ssh to my.server.com and do the steps I described in my first mail (as given by the wiki). Again, this is unnecessary, and could all be handled by reprepro (as I said, I don't even have to log in to the server, it's all done by dupload). Why does it have to be any more complicated than this? It worked pre-signing. If it can't work with signing anymore, why? And shouldn't this be documented? So stick with non-SecureApt for your simple situation, or use the advanced tools to get an advanced situation (which is IMO less complicated). If you're completely against using the tools, but must have SecureApt, why not post a link to your repository and we can help diagnose the problem you're having. I'd be willing to take a look at it to see where the errors are coming from (I'm no apt expert, but I've had to diagnose similar problems in the past). Cameron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mini-dinstall, repository signing and apt-get authentication
On 31 Jul 2007 13:59:34 -0400 Ian Zimmerman [EMAIL PROTECTED] wrote: I see that I have to describe exactly what I do from the point of build. In the source directory of a package, I do fakeroot debian/rules binary that will create a file ../foo.deb, then dput foo_version_arch.changes then let the server do the rest. No need to login. It works well - principally because it is how packages are uploaded to Debian so it needs to work! (dput supports ftp or ssh). scp ../foo.deb my.server.com:/var/local/debian then I ssh to my.server.com and do the steps I described in my first mail dput combines all that into one command. (as given by the wiki). Why does it have to be any more complicated than this? It's actually less complicated. However, see Joey's email about his repository that sounds a lot closer to what you originally wanted. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpS1cQSQffQ1.pgp Description: PGP signature
Re: RFS: tapecalc (updated package)
* Carl Fürstenberg [EMAIL PROTECTED] [2007-07-30 13:33:31 +0200]: Dear mentors, I am looking for a sponsor for the new version 20070214-2 of my package tapecalc. It builds these binary packages: tapecalc - a full-screen tape editor that lets the user edit a calculation The package appears to be lintian clean. The upload would fix these bugs: 435221 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/tapecalc - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tapecalc/tapecalc_20070214-2.dsc I would be glad if someone uploaded this package for me. Kind regards Carl Fürstenberg Uploaded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dosbox (updated package)
On Tue, Jul 31, 2007 at 06:47:34PM +0200, Markus Schölzel wrote: I am looking for a sponsor for the new version 0.71-0.1 of my package dosbox. I assume that you have tried to contact the former maintainer in addition to filing bug reoprts. The package doesn't look well maintained to me either. Package sponsored. Cheers Christoph -- Peer review means that you can feel better because someone else missed the problem, too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: dd-rhelp
Dear mentors, I am looking for a sponsor for my package dd-rhelp. * Package name: dd-rhelp Version : 0.1.1-1 Upstream Author : LAB Valentin [EMAIL PROTECTED] * URL : http://www.kalysto.org/utilities/dd_rhelp/index.en.html * License : GPL Section : utils It builds these binary packages: dd-rhelp - rescue hard disk helper The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/dd-rhelp - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/dd-rhelp/dd-rhelp_0.1.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards Markus Schölzel
Re: [help] Merging tag and trunk in a SVN repository.
Am Mittwoch, den 01.08.2007, 00:36 +0900 schrieb Charles Plessy: Dear Mentors, I was preparing a new version of the package emboss when came an upstream fix that I wished to include in the current version in Debian. I tried to do all whithin the SVN repository holding the debian directory, but now it is a mess: - I reverted to the last revision which was workable; - I added upstream's patch; - I svn-buildpackage --svn-ignore --svn-tag'ed it; - I realised that --svn-ignore was not what I wanted, and then copied the changed files to the ../tags/numversion directory and commited it. - Then I ran svn-buildpackage in tags/numversion to prepare the source package to upload. But now I do not know how to merge this into the last work-in-progress revision... I would need to merge the tags/numversion and the trunk, but: sorbet【emboss】$ LANG=C svn merge tags/5.0.0-2/ trunk/ svn: A working copy merge source needs an explicit revision It seems that the puropose of svn merge is to work within revisions, not between tags and trunks. Could somebody point me the right tool for this ? The standard way is, that you make a copy: svn copy In your case, the trunk branch was copied to tags/. So find out, which revision (I will use the term 'copyrev' for this revision number) this was and make sure, that trunk is in the state it was, when the copy was made. From your description I read, the the changes in trunk were *not* copied (svn-ignore) and you moved to the copy in tags/ to make the changes again (or copy your changes). So trunk should not conatin any changes. Then simply merge everything with: svn merge -r copyrev:HEAD merge tags/5.0.0-2/ trunk/ From your description, this should work without problems. Regards, Daniel
Re: RFS: open-invaders
Hi! * Siegfried-Angel [EMAIL PROTECTED] [070731 15:33]: I fixed everything you said (it's online on mentors.deban.net [1]) except point 3, that one about the architecture independent stuff. You mean that the data should be in a separate binary package (open-invaders-data)? Yes... Debian is shipped with 11 different architectures (even more if you count the inofficial / upcoming architectures, too). Now let's do a small estimation: 3MB architecture independent Stuff, 11 architectures, that are 30MB wasted disc space. 500 Mirrors... you just wasted 15 GB Traffic ;) If so, could you appoint me to a tutorial on how to do that? (I looked at the contents of the Debian New Maintainer's Guide but it doesn't look like there's anything related to that). Uhm... actually I'm not sure of an howto... will put it on my todo-List to create one ;) But actually it's quite simple: First you need to add a description for the -data Package to debian/control and set proper package relationships, than you tweak your debian/rules so that the arch independent stuff is installed to the -data package. Easiest might be you take a look at the ppracer package as example: http://svn.debian.org/wsvn/pkg-games/packages/trunk/ppracer/debian/control?op=filerev=0sc=0 http://svn.debian.org/wsvn/pkg-games/packages/trunk/ppracer/debian/rules?op=filerev=0sc=0 That package builds two additional arch independent packages, and has (hopefully) an easy to understand rules, but feel free to ask questions :) Also, currently the game is only building on i386 (upstream author promised to fix that, but it may still need some time), so is this necessary now? Oh, good point. Missed that... would sponsor your package, but your current approach doesn't work. Did you test your game? It doesn't find it's data files, now that you just moved them away. So, your new todo list: - Use some proper ./configure-flags instead of moving files around (Hint: Either take a look at ./configure --help or play with relative path to parent directories for mandir and docdir, and use an absolute path for bindir.) - You need to review your debian/dirs (Removing directories manually in debian/rules, after you added them do debian/dirs doesn't sound very logic; perhaps you just remove debian/dirs complelty) - BTW: Did you asked upstream, why his makefile installs the header files? Seems so wrong to me, perhaps it's just some kind of bug? Yours sincerely, Alexander signature.asc Description: Digital signature
Re: info about puiparts [was: Sponsor Checklist]
On 31/07/07, Thomas Goirand [EMAIL PROTECTED] wrote: Manoj Srivastava wrote: Hmm. Since the DD/sponsor is the one who creates the uploaded packages, they do not have to insis; they can just make it so. I hope DD's do the actual tend build/clean/rebuild/piuparts-run personally. Therefore I actually am only insistent on the sources being available, since I usually discard the pre-build .debs anyway. manoj Excuse my ignorance, but where can I find infos about piuparts? By installing it and reading the man page. That one doesn't really help: http://piuparts.alioth.debian.org/ and it seems to be a rather new tool, am I correct? It's in the archive since 2005. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Say NO to Microsoft Office broken standard. See http://www.noooxml.org/petition -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sponsor Checklist
On Tue, 31 Jul 2007 17:53:49 +0100, Neil Williams [EMAIL PROTECTED] said: On Mon, 30 Jul 2007 21:40:26 -0500 Manoj Srivastava [EMAIL PROTECTED] wrote: Hmm. Since the DD/sponsor is the one who creates the uploaded packages, they do not have to insis; they can just make it so. I hope DD's do the actual tend build/clean/rebuild/piuparts-run personally. I can never run piuparts - it just takes far too long over my crippled internet connection. Isn't there some way of getting piuparts to use the cached archives like pbuilder does? I already use the existing pbuilder chroot but downloading ALL dependencies EVERY TIME piuparts runs is completely useless to me. I am not sure I follow. You can stash the tarball for the chroot (you need chroots for pbuilder anyway). Then you just have piuparts do a simple install-purge test. piuparts ../foo_1.0-2_i386.deb It's far easier for me to run sudo pbuilder update, login copy the necessary built files into the chroot and test from there. I fail to understand why piuparts is just so difficult to use without a super fast connection. Just how long is it meant to take to run the full piuparts test against sid, lenny and etch for a Gnome package on a 1Mb connection? I gave up after FOUR HOURS. Even a single piuparts run against sid takes far too long for me to do anything useful with it. Running the full suite with upgrade tests is nice; but perhaps can be skipped for people with slow connections. manoj -- Television has proved that people will look at anything rather than each other. Ann Landers Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [help] Merging tag and trunk in a SVN repository.
Le Tue, Jul 31, 2007 at 11:08:59PM +0200, Daniel Leidert a écrit : The standard way is, that you make a copy: svn copy In your case, the trunk branch was copied to tags/. So find out, which revision (I will use the term 'copyrev' for this revision number) this was and make sure, that trunk is in the state it was, when the copy was made. From your description I read, the the changes in trunk were *not* copied (svn-ignore) and you moved to the copy in tags/ to make the changes again (or copy your changes). So trunk should not conatin any changes. Then simply merge everything with: svn merge -r copyrev:HEAD merge tags/5.0.0-2/ trunk/ Dear Daniel, I start to understand better, but I only manage to replace one file by another. Let's take the changelog as an example: In the trunk, it mentions work on the manpages, and on moving files to lib- packages. http://svn.debian.org/wsvn/pkg-emboss/emboss/trunk/debian/changelog?op=filerev=0sc=0 In the tags/5.0.0-2, it mentions the work on the manpages, incorporation of upstream fixes, and fixes related to Debian packaging. http://svn.debian.org/wsvn/pkg-emboss/emboss/tags/5.0.0-2/debian/changelog?op=filerev=0sc=0 (I have made a few commits since you answered, so let us just take this as a starting point without thinking about the past mistakes unless necessary) Now if I run the following command, nothing happens: svn merge -r HEAD:HEAD tags/5.0.0-2/ trunk/ But with this other one, trunk's changelog is just replaced by the tags one: svn merge -r 87:HEAD tags/5.0.0-2/ trunk/ I did not manage to figure out how to simply merge the files, with conflicts to resolve by hand if necessary, in order to have everything in the changelog... Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: qterm (updated package)
Dear mentors, I am looking for a sponsor for the new version 1:0.4.0-5 of my package qterm. It builds these binary packages: qterm - BBS client for X Window System written in Qt The upload would fix these bugs: 434434 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/qterm - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/qterm/qterm_0.4.0-5.dsc I would be glad if someone uploaded this package for me. Kind regards LI Daobing signature.asc Description: This is a digitally signed message part.
RFS: lunar-applet
Dear mentors, I am looking for a sponsor for my package lunar-applet. * Package name: lunar-applet Version : 1.5-1 Upstream Author : Wu Xiaotian [EMAIL PROTECTED] * URL : http://ftp.inlsd.org/lunar-applet/ * License : GPL Section : gnome It builds these binary packages: lunar-applet - A GNOME Timer applet replacement The package appears to be lintian clean. The upload would fix these bugs: 420967 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/lunar-applet - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/lunar-applet/lunar-applet_1.5-1.dsc I would be glad if someone uploaded this package for me. Kind regards LI Daobing signature.asc Description: This is a digitally signed message part.
RFS: chmsee
Dear mentors, I am looking for a sponsor for my package chmsee. * Package name: chmsee Version : 1.0.0~beta2-1 Upstream Author : Ji YongGang [EMAIL PROTECTED] * URL : http://chmsee.gro.clinux.org/ * License : GPL Section : text It builds these binary packages: chmsee - A chm file viewer written in GTK The package appears to be lintian clean. The upload would fix these bugs: 288703 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/chmsee - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/chmsee/chmsee_1.0.0~beta2-1.dsc I would be glad if someone uploaded this package for me. Kind regards LI Daobing signature.asc Description: This is a digitally signed message part.
