Re: Four days
On Wed, Oct 06, 2010 at 11:11:49AM -0400, Asheesh Laroia wrote: On Tue, 5 Oct 2010, Matthew Palmer wrote: To clarify: the intended point of this proposal is to solve the perceived problem that DDs don't sponsor packages because they're concerned that they'll end up taking responsibility for a package if the maintainer ups and leaves? I don't actually see that as a problem. There are simple ways to deal with orphaned packages, regardless of the way the upload was made, and they work. If a package I sponsor is abandoned by the maintainer, it gets NMUed, orphaned and assigned to debian-qa like any other, and is then available for adoption. The variant of this problem I do see, however, is the uploading of surely-soon-to-be-unmaintained low-quality or near-duplicate packages, clogging up the archive and making extra work for debian-qa et al. *That* problem isn't going to be solved by changing the maintainer, it's only going to be solved by not uploading the surely-soon-to-be-unmaintained low-quality or near-duplicate packages in the first place. Matthew -- sounds like you've identified a commonly-asked question that has an answer. Would you (or someone else on the list) be willing to add that to the For Sponsors... section of http://wiki.debian.org/DebianMentorsFaq ? I think I've had my fill of FAQ maintenance. Someone else can do it. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101006194118.ga11...@hezmatt.org
Re: Four days
On Mon, Oct 04, 2010 at 11:42:59AM -0400, Michael Gilbert wrote: On Mon, 04 Oct 2010 11:35:04 +1100, Ben Finney wrote: Michael Gilbert michael.s.gilb...@gmail.com writes: As someone who has attempted to go through the mentoring process, I agree very much that it is rather depressing. How much of that is actually a problem, though? How much is an integral part of gaining humility as to the state of the packaging work, and the pain of learning new conventions and processes? The depressing part is that almost no one is interested in being a mentor, A state which isn't helped by the regular complaint that there's nobody to sponsor my packageees!. When I *do* sponsor something, I'm pretty much guaranteed to get at least one (other) person e-mail me personally with an RFS that's never seen the light of day here, and it's pretty much always for something I'd never touch (for some reason, it seems I see a lot of Java packages that way). Neither state of affairs encourages me to sponsor anything. so its almost impossible to get your work into Debian, which makes the effort seem pointless. Because having a nice package you can use yourself or put on a website somewhere has *no* value at all, naturally. Note that I've actually succeeded many times, but I've also failed many times as well. And the failures are all due to lack of an interested mentor, not due to package quality (a bunch of my packages are on mentors.debian.net and lintian clean). Those are not the be-all and end-all gauges of quality. I think that the efficiency of mentoring is the problem that needs to be solved. That could possibly be improved by treating mentoring tasks as bugs. It may also possibly be improved by treating mentoring as a team task. I see the complaint that DDs choose not to mentor because they end up stuck with unmaintained packages. Well, it would be less of a burden if those were team maintained (make new mentees part of those teams as well). Because packages that are unmaintained by a team that are indifferent are not any different, practially speaking, than those that are unmaintained by one person who is indifferent. Maybe mentorship should be a team effort? Start a new group of mentees every month that work together perhaps? Yeah, that's a great idea! We should setup a mailing list where they can get together and ask questions of each other and request someone to sponsor their packages! - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101004193022.ge32...@hezmatt.org
Re: RFS: pgfouine (updated package)
On Mon, Oct 04, 2010 at 11:35:55AM -0500, Luis Uribe wrote: [Forgot to send the reply to the list, just read about Four Days thread] On Mon, Oct 04, 2010 at 03:38:42PM +1100, Matthew Palmer wrote: On Sun, Oct 03, 2010 at 10:59:51PM -0500, Luis Uribe wrote: I am looking for a sponsor for the new version 1.2-2 of my package pgfouine. Are you looking for a single sponsorship, or an on-going sponsoring relationship? Are you currently, or are you planning on becoming, a DM or DD? I was on NM process but i decided to go On Hold and when i tried to re-start, my AM was busy (luk), so the process got stuck. Later i ask the Front Desk for another AM and after a few mails with Enrico, we decided that the best thing to do was stop NM, do some more work and start with DM. On NM i almost reach the end of TS I. So i'm looking for a on-going sponsor for some of my packages (most active ones) and have another opinion of my work. I've been working with anibal (main sponsor) and with santiago and rmayorga, who have uploaded some packages a few times. I hope that with another sponsor opinion the DM process will be easy. The DM process should be straightforward for you as it is. I'd recommend starting that process now, and I'll DMUA pgfouine if it looks good. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101004194349.gf32...@hezmatt.org
Re: Four days
On Mon, Oct 04, 2010 at 09:17:24PM +0200, Joachim Wiedorn wrote: Hello, Michal ??iha?? ni...@debian.org wrote on 2010-10-04 18:14: Lack of interested mentors is indeed an issue. Nobody has unlimited time and chooses what attracts him. For me it usually means things I know and test or which I find interesting after reading RFS email. I will mention another point: We have Maintainer, Debian Maintainer (DM) and Debian Developer (DD). DD's and DM's is allowed to upload packages directly (DM's only their own packages). But the other Maintainer always need an sponsor - for every upload. It seems that the most problems are packages which are maintained by this group of Maintainer. Is there a way to reduce the number of usual Maintainer? This could help. Get more people into being DMs. No better way to learn than to get bug reports from irate users whose data you've just hosed. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101004195027.gg32...@hezmatt.org
Re: RFS: pgfouine (updated package)
On Sun, Oct 03, 2010 at 10:59:51PM -0500, Luis Uribe wrote: I am looking for a sponsor for the new version 1.2-2 of my package pgfouine. The package is really, *really* not Lintian clean, and claiming otherwise in the RFS was bad form. All those CVS dirs in the resulting package definitely need gutting, and you'll want to look into why geshi is still getting installed in the package, given that it appears to be correctly depended on. Apart from that, though, it builds, installs, and runs pgfouine --help, so you're over most of the big humps. - Matt signature.asc Description: Digital signature
Re: Four days
On Mon, Oct 04, 2010 at 10:32:24PM -0400, Michael Gilbert wrote: On Mon, 4 Oct 2010 17:37:19 -0700 PJ Weisberg wrote: On Mon, Oct 4, 2010 at 1:15 PM, Michael Gilbert wrote: On Tue, 5 Oct 2010 06:30:22 +1100, Matthew Palmer wrote: Yeah, that's a great idea! We should setup a mailing list where they can get together and ask questions of each other and request someone to sponsor their packages! What's so crazy about that? What would be so wrong with empowering mentees to help themselves? I think you missed his point. ;-) Such a list already exists. It's called debian-mentors. OK, I see the attempt at irony now; although that really misses my original idea, which is to revamp the mentoring process with more of a team-based focus. On the contrary; what is different about a team of people within Debian who wish to assist and mentor potential new developers, as opposed to the membership of the debian-mentors mailing list? - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101005025209.gj32...@hezmatt.org
Re: Four days
On Tue, Oct 05, 2010 at 12:14:36AM -0400, Michael Gilbert wrote: On Tue, 5 Oct 2010 13:52:09 +1100 Matthew Palmer wrote: On Mon, Oct 04, 2010 at 10:32:24PM -0400, Michael Gilbert wrote: On Mon, 4 Oct 2010 17:37:19 -0700 PJ Weisberg wrote: On Mon, Oct 4, 2010 at 1:15 PM, Michael Gilbert wrote: On Tue, 5 Oct 2010 06:30:22 +1100, Matthew Palmer wrote: Yeah, that's a great idea! We should setup a mailing list where they can get together and ask questions of each other and request someone to sponsor their packages! What's so crazy about that? What would be so wrong with empowering mentees to help themselves? I think you missed his point. ;-) Such a list already exists. It's called debian-mentors. OK, I see the attempt at irony now; although that really misses my original idea, which is to revamp the mentoring process with more of a team-based focus. On the contrary; what is different about a team of people within Debian who wish to assist and mentor potential new developers, as opposed to the membership of the debian-mentors mailing list? A lot. The current process is individualized mentorship, not team mentorship.??? Not to my knowledge. Whilst some new maintainers may have an invitation from certain DDs to e-mail them privately with their questions, in general the intended process is that questions are asked on this mailing list, and answers are given and discussed by anyone who feels qualified to answer -- DD, DM, mentee, or interested bystander. One is to use the mentors mailing list as the maintainer for mentee packages. That way the burden of quickly orphaned packages is dispersed over the whole set of mentors rather than just one. Perhaps that will encourage more DD participation since they won't stick themselves with a lot of orphaned packages. To clarify: the intended point of this proposal is to solve the perceived problem that DDs don't sponsor packages because they're concerned that they'll end up taking responsibility for a package if the maintainer ups and leaves? I don't actually see that as a problem. There are simple ways to deal with orphaned packages, regardless of the way the upload was made, and they work. If a package I sponsor is abandoned by the maintainer, it gets NMUed, orphaned and assigned to debian-qa like any other, and is then available for adoption. The variant of this problem I do see, however, is the uploading of surely-soon-to-be-unmaintained low-quality or near-duplicate packages, clogging up the archive and making extra work for debian-qa et al. *That* problem isn't going to be solved by changing the maintainer, it's only going to be solved by not uploading the surely-soon-to-be-unmaintained low-quality or near-duplicate packages in the first place. On a practical point, making d-mentors the maintainer would clog the list with large quantities of (mostly) bug-related e-mail, a la debian-boot, making the list far worse for discussion. However a separate mailing list could be created to avoid that problem (at the cost of requiring people to subscribe to the other list, splitting attention, etc). The other idea is to reduce DD involvement in the mentoring process itself by making mentees more responsible for themselves. Take a set of mentees, have them work together to get their packages in shape, then maybe once a month (or every couple weeks) have them show the set of packages that they have ready to the mentors list. That would also reduce RFS traffic on this list. This list would become more of a coordination point for joining mentee teams. There's nothing stopping that from happening now on this list. I don't see that batching RFSes is going to either (a) reduce RFS traffic (because nothing's stopping people from still posting them here, and even the batch will have to be sent out some time), or (b) improve sponsorship rates (in fact it'd probably decrease them, because checking 1 package a day every day is far less daunting than checking 14 packages once a fortnight). However, if you want to give it a go, don't let me (or anyone else) stop you. Take Asheesh's lead and just start something, don't ask or wait for official endorsement of your idea, because it will never come. Do it, and if it works it'll catch on, and if it doesn't then... try something else. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101005053037.gk32...@hezmatt.org
Re: RFS: pgfouine (updated package)
On Sun, Oct 03, 2010 at 10:59:51PM -0500, Luis Uribe wrote: I am looking for a sponsor for the new version 1.2-2 of my package pgfouine. Are you looking for a single sponsorship, or an on-going sponsoring relationship? Are you currently, or are you planning on becoming, a DM or DD? - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101004043842.gb32...@hezmatt.org
Re: Doubts in Sigar packaging
On Thu, Sep 16, 2010 at 12:44:47PM +0100, Tony Houghton wrote: On Thu, 16 Sep 2010 19:00:27 +1000 Matthew Palmer mpal...@debian.org wrote: On Wed, Sep 15, 2010 at 03:18:20PM +0200, Adam Borowski wrote: Why won't you just use `git --describe`? It produces nice version numbers of the format last tag-number of commits after it-start of hash (or just last tag when you're packaging a release) git --describe is, as far as I can tell, useless for the purpose stated at the beginning of the thread. Did you miss the number of commits after it bit? I think that makes it ideal provided each release is tagged with its version number. Because tags aren't globally unique. Since you yourself said that tags weren't suitable, in and of themselves, when I proposed it, I can't imagine how a tag plus a commit count is of any use. The addition of a hash doesn't help, for the non-sortable reason I gave. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100917082317.ge3...@hezmatt.org
Re: Doubts in Sigar packaging
On Thu, Sep 16, 2010 at 09:59:43AM +0200, Adam Borowski wrote: On Thu, Sep 16, 2010 at 03:22:31PM +1000, Matthew Palmer wrote: On Wed, Sep 15, 2010 at 03:18:20PM +0200, Adam Borowski wrote: Why won't you just use `git --describe`? It produces nice version numbers of the format last tag-number of commits after it-start of hash (or just last tag when you're packaging a release) The start of hash is a way to disambiguate in the case of multiple branches based on the same release that happen to have the same number of commits past that it; it will be the minimal repo-wide unambiguous hash not shorter than (by default) 7 characters. You cannot use hashes in your version strings, because you can't assume that the later version is going to sort after the earlier version. If tag-commitcount isn't sufficiently unique, you're stuffed. You can't compare unversioned branches to other branches anyway. If you move from one branch to another, you need to label that manually. Git's scheme provides enough versioning to handle anything that can be done in automated way. Indeed, packaging multiple branches stemming from the same tag may give versions that are not sufficiently sortable, but there's no way to tell which branch is the lesser and which is the greater one without human intervention. So what does this have to do with producing a suffix to put on an upstream version for a Debian package? Using a tag, however, is a possibility I hadn't considered. If you merge from upstream at relevant points and then tag in your repo, you could use 0.x.y~tagname as the upstream version. Again, README.source would need to document this convention, but you can control the content of the tag to make it monotonically increasing. This would be bad, as your tags won't say anything about the version you package. Without a mapping between your tags and particular commits, there's no way to tell what upstream source you refer to. Can't you tell git to retrieve a tag (and all commits therefrom) from a remote repository? If not, what *is* the point of a git tag? If it is ambiguous, you can always put that sort of information in the Debian changelog, or perhaps README.source. git --describe doesn't have that pesky requirement. git --describe is, as far as I can tell, useless for the purpose stated at the beginning of the thread. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100916090027.ga4...@hezmatt.org
Re: Doubts in Sigar packaging
On Wed, Sep 15, 2010 at 03:18:20PM +0200, Adam Borowski wrote: On Wed, Sep 15, 2010 at 01:31:39PM +0100, Tony Houghton wrote: Matthew Palmer mpal...@debian.org wrote: sigar-1.7.0~git833ca18ecfc1f3f45eaf8544d8cdafef6603772d Yeah, that isn't going to work -- what if the next SHA you want to package is 12345[blah]... it'll look like a lesser version to dpkg. I had a similar problem when I moved roxterm to git [1]. I only use git-derived versions for testing between releases but it's still useful. Here's a bit of script that can help: Date=`git log --date=iso | grep -m1 '^Date:' | sed 's/^Date:\s*//'` Rev=`date -d $Date -u +'%Y%m%d%H%M%S'` Why won't you just use `git --describe`? It produces nice version numbers of the format last tag-number of commits after it-start of hash (or just last tag when you're packaging a release) The start of hash is a way to disambiguate in the case of multiple branches based on the same release that happen to have the same number of commits past that it; it will be the minimal repo-wide unambiguous hash not shorter than (by default) 7 characters. You cannot use hashes in your version strings, because you can't assume that the later version is going to sort after the earlier version. If tag-commitcount isn't sufficiently unique, you're stuffed. Using a tag, however, is a possibility I hadn't considered. If you merge from upstream at relevant points and then tag in your repo, you could use 0.x.y~tagname as the upstream version. Again, README.source would need to document this convention, but you can control the content of the tag to make it monotonically increasing. Unlike homebrewed versioning schemes, this one can be understood by git without changes, no matter if you say 0.8.0-a0-1247-gf38ef2b, f38ef2b or f38ef2ba31de828e4b1961efe9b9e3cf91aadea6. For Debian packaging, this is irrelevant. I recommend against using dates to mark revisions, since there probably will be multiple commits in a single day, so there is no way to tell which exactly version you did package. If it is ambiguous, you can always put that sort of information in the Debian changelog, or perhaps README.source. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100916052231.ge...@hezmatt.org
Re: Doubts in Sigar packaging
On Tue, Sep 14, 2010 at 01:51:22PM -0300, Thiago Franco de Moraes wrote: I'm trying again to package a library called SIGAR [1] because it's a requirement in a free software help to develop called InVesalius [2]. During this trying some doubts occurred: * The Source is in git [3]. I'm not using the last stable version because I wasn't able to compile it. What's the policy to version packages from git? I'm using this way: sigar-1.7.0~git833ca18ecfc1f3f45eaf8544d8cdafef6603772d after git is the commit version I'm using. Yeah, that isn't going to work -- what if the next SHA you want to package is 12345[blah]... it'll look like a lesser version to dpkg. What you need to do is select a monotonically increasing number to work from. I think the most common option is to just take the date of the last commit in the repo and use that, so something like sigar-1.7.0~git20100915. Assuming that you don't want to package two versions from the same day, that should work just fine. You'll want a debian/README.source describing where the git repo is that you got your export from, and how other people can recreate it (or update it), for cleanliness. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100914222129.gs...@hezmatt.org
Re: [Fwd: VICE]
On Sat, Sep 11, 2010 at 07:24:02PM +0200, N.L.M. de Jonge wrote: I tried e-mailing the vice deb package maintainer, but his maildir is over quota; what to do now... is there an overseer that I can e-mail about the maintainer not checking his e-mail? It appears that you were attempting to report a bug, so what you want is the Debian bug tracking system; see http://bugs.debian.org/ for all the necessary information on submitting a bug. Then, if the maintainer fails to respond, other people can deal with the bug report as required. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100911215528.gc...@hezmatt.org
Re: packaging help
On Tue, Aug 31, 2010 at 03:45:28PM +, alma...@comcast.net wrote: I am working with this tutorial to understand better the debian packaging process: http://www.debian-administration.org/article/337/Rolling_your_own_Debian_packages_part_2 it all goes well until I try to build the package from source. I am getting errors regarding SVN and APR (I think they are libraries) needed. I checked with Synaptic Manager and I see the libraries are installed. Normally, you'd be best off including the errors that you're seeing, as well as the exact names of the packages you see installed, but my spidey sense is telling me that you've installed the runtime library (eg libapr1), but not the development library (eg libapr1-dev). It is the latter that you need if you want to build against a library, not (just) the former. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100831201657.gf...@hezmatt.org
Re: conffiles
On Tue, Aug 31, 2010 at 06:47:09AM +0300, Zvi Dubitzky wrote: Is there a way to put something in DEBIAN directory that will trigger the poped up question when overwriting config files (during package installation) before running dpkg-deb --build to generate the packge OR is there a debhelper command (dh_..) that will trigger that prior to calling dpkg-deb If you're calling dpkg-deb or adding files to the DEBIAN directory by hand, you have already failed. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100831201849.gg...@hezmatt.org
Re: conffiles
On Mon, Aug 30, 2010 at 10:01:46PM +0300, Zvi Dubitzky wrote: I am having conffiles file placed in debian directory and holding the configuration files ( full path) that should avoid being overwritten when installing a package , Yet when I install the built package the package config files are overwriting the existing config files at /etc without popping out a question. You should never need to list files in /etc as conffiles, as they're detected and a conffiles written out at package build time (because Policy says all files in /etc are conffiles). You'll almost certainly get better help if you post your source package somewhere for other people to examine, or at least provide a representative sample which demonstrates the problem you're seeing. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100830200322.gc...@hezmatt.org
Re: How to Deal with files created dynamically
On Tue, Jul 27, 2010 at 10:03:42AM -0500, Matt Zagrabelny wrote: On Tue, Jul 27, 2010 at 6:53 AM, Chris Baines cbain...@gmail.com wrote: Hello Mentors, I am looking at creating packages that involve programs that create caches while running of images or other files. But I am a bit stumped at what to do with the files they create, both where they are meant to go and with what permissions. one of these two, I would wager: /var/cache/ /var/lib Scratch /var/lib from that list. If the data can be recreated from another source, then it's cache data and should *not* live in /var/lib. As for the permissions root:root 644 If the files are created by root-owned processes, sure. It kinda smells like this is going to be done by a user-run process, which means you won't be able to apply that ownership. You will probably have to revert to per-user data stored in the homedir, unless you want to start stuffing around with suid wrappers or some such. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100727195236.gb4...@hezmatt.org
Re: How to Deal with files created dynamically
On Tue, Jul 27, 2010 at 03:47:48PM -0500, Matt Zagrabelny wrote: On Tue, Jul 27, 2010 at 3:26 PM, Chris Baines cbain...@gmail.com wrote: On Wed, 2010-07-28 at 05:52 +1000, Matthew Palmer wrote: On Tue, Jul 27, 2010 at 10:03:42AM -0500, Matt Zagrabelny wrote: On Tue, Jul 27, 2010 at 6:53 AM, Chris Baines cbain...@gmail.com wrote: Hello Mentors, I am looking at creating packages that involve programs that create caches while running of images or other files. But I am a bit stumped at what to do with the files they create, both where they are meant to go and with what permissions. one of these two, I would wager: /var/cache/ /var/lib Scratch /var/lib from that list. If the data can be recreated from another source, then it's cache data and should *not* live in /var/lib. As for the permissions root:root 644 If the files are created by root-owned processes, sure. It kinda smells like this is going to be done by a user-run process, which means you won't be able to apply that ownership. You will probably have to revert to per-user data stored in the homedir, unless you want to start stuffing around with suid wrappers or some such. Yes, the programs are run with user level permissions. While per user data would be a solution I don't want to use it just to make this easier. Are there any packages that deal with these problems? You could create a group and then do something like: addgroup newpackage mkdir /var/cache/newpackage chown root:newpackage /var/cache/newpackage chmod 775 /var/cache/newpackage This is only practical if the cache files are not trusted by the application; users can directly manipulate the files and their contents. It must be possible to verify that the cache files are correct before using them. Also, if you're going to go that wild, you may as well just make the directory group 'users' or some equally common group. Also, don't forget the g+s and umask 002 to avoid per-user permission nightmares. In other words: per-user caching ftw. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100728005138.gd4...@hezmatt.org
Re: FGRun Lintian Error
On Mon, Jul 26, 2010 at 09:31:10AM +0100, Chris Baines wrote: Hello mentors, I am getting a package-section-games-but-contains-no-game lintian error on my package fgrun. FGRun is a FLightGear graphical launcher, FlightGear is a flight simulator game. FGRun puts its binary in the /usr/bin directory. FGRun is not a game, however it depends on FlightGear and its only current purpose is to configure and launch FlightGear which is a game. Should I just ignore the error or place the binary in the games /usr/share/games directory or change the section of the package to something else? I would be inclined to move it into /usr/games; whilst it may not be a game itself, per se, it's certainly more game than anything else. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100726090124.gb19...@hezmatt.org
Re: RFS: twms -- tiny web map service
On Wed, Jun 30, 2010 at 10:25:53AM +0200, David Paleino wrote: On Wed, 30 Jun 2010 08:50:20 +0100, Jonathan Wiltshire wrote: On Wed, Jun 30, 2010 at 09:55:30AM +0300, Andrew O. Shadoura wrote: It builds these binary packages: twms - tiny WMS service What is a web map service? It's a common technology used in the GIS world -- it lets you download georeferenced images from a server given coordinates, image format and other parameters. See http://en.wikipedia.org/wiki/Web_Map_Service . I don't believe the acronym should be expanded, since it's a very technical package, not for the everyday-user. On the contrary, it should definitely be expanded -- you're not exactly desperate for space in your short description, and if someone searches for web map service instead of WMS, this way you'll catch their search. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100630090333.gd19...@hezmatt.org
Re: Different package sizes on amd64 and (cross)i386
On Sun, May 16, 2010 at 04:12:20PM +0200, Nicolas Joseph wrote: Maybe but debarchiver reject my upload because the file is already added and has a different md5 sum. how do you do for real repositories? You don't upload the same package version twice. If you need to update, bump the version number. We also don't top post. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100516195827.gp30...@hezmatt.org
Re: New packager
On Wed, Mar 10, 2010 at 12:53:46AM +0100, Fabrizio Furnari wrote: Now, the great of the software we need in ArcheOS are in Java, some are web applications (some webGIS, and so on). Licensing is not a problem but packaging is a little more difficult than usual, so the conclusion to write in this ML to ask help to you: I need someone that can assist me in packaging and later will guide me through the process to became a DD. What do you think about? I'm forgetting something? You've forgetten to provide a specific, answerable question. We don't generally pair up with someone straight off the bat (although over time you'll no doubt find yourself talking to the same subset of people, as they deal with similar issues you do). But for now, ask specific and detailed questions on this list, and hope that someone's come across the problem too and solved it. Providing the complete source package you're dealing with, for examination, is also strongly encouraged. I'm too arrogant? There's no such thing as too arrogant. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100310043024.gm13...@hezmatt.org
Re: Joining Debian
On Mon, Feb 08, 2010 at 01:40:29PM -0800, Chris Taylor wrote: You should take a look at the documents located at http://www.debian.org/devel/ Namely you should read the New Maintainers Guide: http://www.debian.org/doc/maint-guide/ The Debian Developers' Reference: http://www.debian.org/doc/developers-reference/ And you should also read the Debian Policy Manual: http://www.debian.org/doc/debian-policy/ In addition, the FAQ for this list: http://people.debian.org/~mpalmer/debian-mentors_FAQ.html might answer some of your questions. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: how to compare versions
On Wed, Feb 03, 2010 at 01:43:49PM +0900, Hideki Yamane wrote: I'm thinking about tomoyo-ccstools package update but it has a problem. It has no compatibility with current version (1.6.8) and newer version (1.7.1). So, I want users would be able to choice continue upgrading or not with debconf. I wrote that, but there's a problem - it compares versions in preinst script, so it has Pre-Depends: debconf. It is recommended to avoid using Pre-Depends as policy manual says. # http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps So I want to ask how would I do such thing - compare version with current installed version - in smart way, without pre-depends. In short: you don't. You should make it clear in the NEWS.Debian file that there are compatibility issues, and your README.Debian should describe how to perform an upgrade manually (or point to upstream documentation for same). Users who are specifically interested in upgrade compatibility issues should be keeping an eye on the NEWS.Debian file for all the packages they upgrade (via apt-listchanges); everyone else is assumed to not be that interested, and should expect that incompatible upgrades may occur. That being said, you should try your best to make upgrading smooth, providing compatibility shims and automatic data conversion (as appropriate), along with encoraging upstream to take a less cavalier approach to their users' expectations (a major version bump should be used for a completely incompatible upgrade). In the worst possible case, you may want to look at providing both the older version of the package and the newer one side-by-side, to allow users to run both in parallel and upgrade at their convenience (major software packages like apache do this). It is a lot of work (both to do the packaging, test the side-by-side operation, and support the old version through a stable release without upstream help) so it's not something to be undertaken lightly, but it is another option. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Looking for a sponsor
On Wed, Dec 30, 2009 at 07:57:18AM +, Tadeusz Struk wrote: I've created one amd64.deb package. Unfortunately I don't have access to other architectures. The pkg can be found here: https://sourceforge.net/projects/spg/files/spg.0.5.0/spg_0.5.0-1_amd64.deb/download You need to provide the source package, not the binary package. The binary package is effectively useless to a potential sponsor. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Can /usr/share/doc/pkg be deleted on upgrade ?
On Thu, Nov 26, 2009 at 01:38:32PM +0100, Lucas B. Cohen wrote: Is it considered acceptable for a package to blindly delete, then recreate its entire directory under /usr/share/doc upon installation or upgrade ? I would consider it extremely unacceptable. Your package can fiddle with files it owns, but anything else is Right Out. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Embedding one .deb inside another
On Thu, Nov 26, 2009 at 12:59:54PM -0800, Joe Smith wrote: I'm having an issue with distributing a .deb package that has a dependency on another .deb package that might not be in an available repository (or the target may not have a network connection at the time of installation). What I'd like to do, ideally, is embed the dependency inside the parent package. That way, in the preinst script, it could just install it's dependency. However, the problem is that when installing the parent package, it locks the dpkg system so when it, in the preinst step, goes to run dpkg -i on the embedded .deb file, it can't get a lock and fails. Is this something that's fundamentally impossible or is there some way to achieve what I need? I'm assuming this is for a private package; this set of circumstances would never occur in the Debian archives. From that perspective, you can do whatever you want. It's not hard to setup a small apt repo (password/IP access restricted, if necessary), or (worst case) have a small shell script glued to a sharchive with both debs that can unshar and dpkg -i both of them. Also, I want this all to be able to be done from a single dpkg -i parent package.deb and not from a script where I could otherwise do dpkg -i parent.deb child.deb. The reasons for this are limitations on the current method of distribution. Can't be done; the lock on the package metadata files will be taken. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Buildd failed: C compiler cannot create executables
On Fri, Nov 27, 2009 at 08:08:36AM +0100, Joachim Wiedorn wrote: thanks for this informations! What informations? - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Can /usr/share/doc/pkg be deleted on upgrade ?
On Thu, Nov 26, 2009 at 03:41:39PM +0100, Lucas B. Cohen wrote: Roger Leigh wrote: Users don't have write access to anything under /usr in general (and /usr/share/doc in particular). If they did place files there, they must have done it after gaining root privs. I.e. they took deliberate steps to do something they should not under normal circumstances have been permitted to do. The user is clearly at fault here for writing personal data into a directory managed by the packaging system. I hadn't thought of that, I guess it settles it. Thank you for you answer. /me adds bacula to the never, not ever list. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Can /usr/share/doc/pkg be deleted on upgrade ?
On Sun, Nov 29, 2009 at 05:13:51PM -0600, Manoj Srivastava wrote: On Thu, Nov 26 2009, Matthew Palmer wrote: On Thu, Nov 26, 2009 at 01:38:32PM +0100, Lucas B. Cohen wrote: Is it considered acceptable for a package to blindly delete, then recreate its entire directory under /usr/share/doc upon installation or upgrade ? I would consider it extremely unacceptable. Your package can fiddle with files it owns, but anything else is Right Out. Right. But a package owns the directory /usr/share/doc/package-name, and other packages should not be dumping things in there -- there should be no expectation of any directory structure under another packages /usr/share/doc directory surviving. According to dpkg -L, sysklogd owns /var/log (and /var, /usr, and /usr/sbin for that matter); I would still consider it unpleasant if sysklogd decided to go and delete any of those directories because it owned it. I did use the word file in my previous statement quite deliberately. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: About software from other distribution
On Wed, Nov 11, 2009 at 12:39:58AM +0800, Liang Guo wrote: Currently I'm using qspice, a Simple Protocol for Independent Computing Environments (SPICE) client as my console to connect to KVM. qspice is a utility from RedHat Enterprise Linux 5.4, and It is licensed under GNU GPLv2. qspice and related libraries can be downloaded from ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/ as SRPM format, may I package it for Debian ? Sure, there doesn't appear to be an existing ITP, and the licence is fine. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: script-with-language-extension
On Mon, Oct 05, 2009 at 03:43:22AM +0200, Jarom?r Mike? wrote: Od: Jarom?r Mike? mira.mi...@seznam.cz JM I did it, but it breaks functionality ... there exist also symlinks with JM same name and in same location. JM usr/bin/lv2rack JM usr/bin/zynjacku JM usr/bin/zynspect JM -- JM usr/bin/lv2rack.py JM usr/bin/zynjacku.py JM usr/bin/zynspect.py CLJ Hmmm what about remove these symlink first and then remove suffix? CLJ I am going to try it. CLJ How about just mv /usr/bin/lv2rack.py /usr/bin/lv2rack and so on? JM nice solution ... but there is anyway something broken. JM This package actually contains two commands you can call from CLI zynjacku and JM lv2rack. JM When I remove .py suffixes lv2rack stop works ... zynjacku is fine. JM Without removing .py suffixes both work fine. JM I have to investigate it more. BTW: error message for lv2rack is: --- $ lv2rack Traceback (most recent call last): File /usr/bin/lv2rack, line 52, in module import zynjacku as zynjacku -- So someone's using a single file as both a library and a stand-alone program. Damned silly idea. Stick zynjacku.py in a proper library path somewhere, and write a little shim wrapper to stick in /usr/bin that calls zynjacku as it expects to be called. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: script-with-language-extension
On Mon, Oct 05, 2009 at 01:44:11PM +1100, Ben Finney wrote: Matthew Palmer mpal...@debian.org writes: So someone's using a single file as both a library and a stand-alone program. Damned silly idea. Not so silly; a Python module can be useful both as a main program and as a re-useable component in other programs. The well-known Python idiom of testing ???if __name__ == '__main__'??? is commonly used to make a module that can be used in either way. It can be done in other languages too; doesn't make it a good idea. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: presumable last policy change before releasing Squeeze?
On Sun, Oct 04, 2009 at 01:34:12AM +0200, ERSEK Laszlo wrote: - I like a fresh Standards-Version, This is not a valid reason to make an upload to Debian. It is perfectly permissible to have a package with an outdated standards version, especially if the updates to policy do not apply to your package (which is the case in 99% of packages for a given change to policy, in my experience). - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Skipping the upload of *.deb and *.changes files to m.d.n
On Tue, Sep 22, 2009 at 02:50:46PM +0200, Jos? Manuel Santamar?a Lema wrote: I'm a novice and I uploaded some times packages to m.d.n. According to the home page, binary packages are discarded keeping only the source package. However every time that I upload a package, _all_ files are uploaded, including those that will be discarded by m.d.n. I checked the dput and dupload docs and I didn't found any way to avoid the upload of *.deb and *.changes files in order to save a bit of my time and my bandwith. So, I have uploaded to my alioth account a modified version of dput: http://alioth.debian.org/~santa-guest/dput_0.9.5.1+santa1.dsc I checked a bit this list and the dput bug reports, it seems very weird for me that nobody complained about this issue. What do you think? If you want to build a change file with only a source package, then just give the -S option to dpkg-buildpackage. It's got nothing to do with dput -- it just uploads what you ask it to via the contents of the .changes. That's why there's no bug reports about it -- because it's not a bug. I don't know what m.d.n's policy on the matter is as far as requiring binary packages, but it's fairly unlikely that they'll be able to process your upload without a .changes file, so you really don't want to stop uploading that. Given that it's normally about 2kB, it's hardly a great saving anyway. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Appropriate warning when removing important package
On Wed, Sep 16, 2009 at 12:06:56PM -0700, Jeremy Leibs wrote: We have kind of a unique environment in that many of the (somewhat naive) system users have root-access for installing new packages on an as-needed basis, but the development environment itself has some specific requirements. For example, we require libboost1.37-dev over libboost-dev. I have create a trivial deb called ros-conflicts which just explicitly conflicts with the packages we need to avoid. Unfortunately, when users are doing large apt-get installs, they will just blindly hit yes without thoroughly inspecting the list of packages which may be removed, putting their system in an unusable (from a development standpoint) state. My initial workaround was to just add Essential: yes to the ros-conficts control file so that now users get a much more serious warning when they try to install a package that conflicts with it. However, this feels like a misuse of essential. shrug Works for me. They're essential packages for your environment, so why not mark them as such? Uploading them to Debian would be a no-no, but I think that's not real likely. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Requests to sponsor new library packages (was: why?)
On Wed, Aug 19, 2009 at 10:11:12AM +1000, Ben Finney wrote: Sune Vuorela nos...@vuorela.dk writes: For example, I would be very reluctant to sponsor a first package of a person that was a new library without any application using it, whereas a interesting kde application might easier catch my eye. That's interesting, thank you for that perspective. What do you propose, then, for a maintainer who wants to get a new package into Debian, but that package requires one or more separately-packaged libraries that *also* need to be sponsored into Debian before the “interesting” package can go in? Put them all into the same (or linked) RFS. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Requests to sponsor new library packages
On Wed, Aug 19, 2009 at 11:42:38PM +1000, Ben Finney wrote: Sune Vuorela nos...@vuorela.dk writes: On 2009-08-19, Ben Finney ben+deb...@benfinney.id.au wrote: That's interesting, thank you for that perspective. What do you propose, then, for a maintainer who wants to get a new package into Debian, but that package requires one or more separately-packaged libraries that *also* need to be sponsored into Debian before the ???interesting??? package can go in? Request sponsorship together. And read up on library packaging. Matthew Palmer mpal...@debian.org writes: Put them all into the same (or linked) RFS. I obviously wasn't clear on this point: The library package is prepared *first*, to provide functionality needed by the dependent package. They're not ready for sponsorship together. What advice then? In my case, ‘fooapp’ needs ‘libbar’, which in turn needs ‘libbaz’. So, with only a limited amount of time, I work first on ‘libbaz’, and that package is ready for sponsorship before the others. Should I wait until all three are done — an indeterminate amount of time — before making an RFS for the ready-to-inspect ‘libbaz’? Make an RFS if you like, but don't get all bent out of shape and chuck a hissy fit on d-mentors if nobody does anything about it (because it's a library package -- hard to do right, and utterly pointless without an application to go with it). - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: why?
On Tue, Aug 18, 2009 at 01:46:04AM +, Leinier Cruz Salfran wrote: why is so hard to find a sponsor? I have a package online since 2 weeks ago, I sent 3 RFS and I have found no sponsor yet. why The debian-mentors FAQ (http://people.debian.org/~mpalmer/debian-mentors_FAQ.html) has some hints on improving your chances of finding a sponsor. The chances are nobody has found your package interesting enough to take the (considerable) time required to check it and upload it. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Nomeclator of plugins
On Wed, Jul 22, 2009 at 03:02:19PM -0500, Boyd Stephen Smith Jr. wrote: In 200907221847.44193@alaxarxa.net, Leopold Palomo-Avellaneda wrote: I think I have not seen it in the Debian policies. I have a dual role in one application: developer and co-maintainer. I would like to ask one question that fits in both. I'm in the bulmages project. It's a big piece of software with several applications with libs and plugins. It's a cmake build project. The plugins we have are lib.so. I add the properties (soname and version) to the plugins as the project main properties. The packages consist in several packages, etc. The second, and it's my main question is about the nomenclature of the plugins. The guy says that the Suse force to create a package -dev if you have this kind of things (.so and symbolic links -.so.x.y.z). But I did a package for some .so (-dev) of the software, but not for all. Do we have a similar rule? Something like that. No, nothing like that. (IANADD) A library package should install lib$SO_NAME.so.$SO_VERSION and be called lib$SO_NAME$SO_VERSION. Except that these aren't regular shared libraries, they're dynamically loaded plugins. Leopold: no, Debian has no requirement that every shared object have a -dev package associated with it (see the many and various Apache module packages -- I wonder how SuSE deals with that hoary chestnut). However, you MUST NOT put your plugins directly into /usr/lib (or any other ld.so search path); instead, place them in something like /usr/lib/package/plugins and have the application look for them in there. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: non-native package versions
On Tue, Jun 30, 2009 at 07:23:38PM +0100, Juan Jesús Ojeda Croissier wrote: On Tue, Jun 30, 2009 at 6:28 PM, Chow Loong Jinhyper...@gmail.com wrote: On Wednesday 01,July,2009 12:27 AM, Juan Jesús Ojeda Croissier wrote: [...] And also a kind of retorical one (I guess I know already the answer...), do I really need to separate the app code from the debian packaging files? isn't there another option? I guess we'll have to slit them :-/ You don't. You just have to release the tarball without it (the debian/ directory). I know of applications which have the debian/ directory in the upstream source code, but generate tarballs without them. If you use autotools, this is very easy. Just run `make dist' in the configured source directory. If you don't, well, you're on your own (hint: tar --exclude=debian if all else fails). The problem we have right now is that we don't really use tarballs for release our apps. Well, you're going to have to fix that before you can get a Debian upload, at any rate. You can't upload a VCS revision as a source package (yet). - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: FYI: QA uploads primer
On Tue, Jun 16, 2009 at 12:53:32AM +0200, Serafeim Zanikolas wrote: On Tue, Jun 16, 2009 at 12:01:30AM +0200, Sandro Tosi wrote: On Mon, Jun 15, 2009 at 23:00, Serafeim Zanikolasser...@hellug.gr wrote: Thanks for the feedback Sandro. I've written the primer for technical-minded debian users that (a) want to contribute to debian, but are uncertain about their long-term time-commitment; and (b) given their uncertain commitment, won't read the whole policy, devref, and newmaint guide just for the sake of trying out the water. No, that's again wrong: you can't do a quality work without ready those documents (with this order: policy, devref, NM Guide). This is a false statement you're making and I'm stopping here reading your email. There's a tradeoff: encouraging potential new contributors (in the hope that they'll eventually read all the docs) at the cost of initially lower-quality RFS requests, or making it clear from the start that packaging is hard and time-consuming and they shouldn't even bother until they've read all 3 docs in full [1] Or you can point people who don't want to learn how to package things properly to QA activities that their limited time and attention span can cope with. Things like just making sure that the bugs on a package are in good order, with well-tested patches and clear comments to that effect, which reduces the time commitment for someone who *does* have the necessary skills to produce a working package. Announcing their work on debian-qa often finds someone to aggregate, test, and make the upload. Anything that encourages people to submit even shoddier RFSes than some of those that already come through here should be derided loudly and publically. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: subnetcalc
On Sat, Jun 06, 2009 at 03:59:18PM +0200, Thomas Dreibholz wrote: - The new upstream version is now 2.0.2, therefore the new Debian package is 2.0.2-1debian1. Uhm... no. 'debian' is effectively the default source, so you don't tag packages as such. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: Proposal for template for uploads
On Sun, May 17, 2009 at 10:33:07AM +0100, Neil Williams wrote: On Sat, 16 May 2009 21:50:10 -0300 Rogério Brito rbr...@ime.usp.br wrote: Dear mentors, I am looking for a sponsor for my package foo. [Include one of:] This package is NEW to Debian. The ITP number is: #bugnumber This is a QA upload that fixes description problems. This is an RC bug fix upload: #bugnumber. This is an update of a package I already maintain. [or some other description of the kind of upload required] And when you're listing bug numbers, please put a summary of what the bug is. Make it *easy* for the sponsor to say yes, rather than meh, too busy, might look at it later. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: debsigs (adopted, fixed bugs, updated)
On Sat, May 16, 2009 at 06:44:54PM +0300, Peter Pentchev wrote: The package can be found on mentors.debian.net: dget -x http://mentors.debian.net/debian/pool/main/d/debsigs/debsigs_0.1.15.dsc curl: (22) The requested URL returned error: 404 dget: curl debsigs_0.1.15.dsc http://mentors.debian.net/debian/pool/main/d/debsigs/debsigs_0.1.15.dsc failed Has this already been uploaded? - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On upstream source tarballs and dpkg-source
On Sun, May 17, 2009 at 12:07:31AM -0300, Rogério Brito wrote: Hi, LI. On May 17 2009, LI Daobing wrote: 1. download foo-1.2.3.tar.gz 2. run ln -s foo-1.2.3.tar.gz foo_1.2.3.orig.tar.gz, so debuild can recognize that you already have a orig tarball Yes, I understood that. I just replied to comment that dpkg-source is more general than that, working with very weird package names. I saw nothing in Li's comments that implied that he believed that dpkg-source was unable to work with arbitrary directories in tarballs. Please, check my package hfsprogs to see what I mean. :-) I have completely overridden Apple's naming. :-) I'm sure that Li is well aware of how dpkg-source works. I also think you need to have an urgent and invasive emoticondectomy. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: dch multi-maintainer mode
On Tue, Apr 21, 2009 at 09:22:49PM +0200, Stéphane Glondu wrote: Neil Williams a écrit : Is it still allowed as per 3.8.1 policy to use multi maintainer style changelogs? Yes. And what was the prevous style of changelog allowed, by the way? Originally, the debian changelog format was supposed to be pluggable, where people would write parsers for different changelog formats that would extract the necessary information (package name, version, changed-by, etc) from the changelog file. As it turns out, the current standard format works entirely sufficiently, and I doubt that anyone's ever used a different style, so that misfeature has been removed and the standard format everyone uses is now the One True And Only Format. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: magicfilter (QA update of the package) (fwd) (fwd)
Hi Rogério, On Mon, Apr 20, 2009 at 07:32:46PM -0300, Rogério Brito wrote: Probably this was missed the past few times that I posted to the list. Please, could anybody sponsor it? I've started looking at this package, but got caught up with other things. At the very least, you'll need to properly adopt the package before I'll upload it. I don't sponsor NMUs, and it's quite obvious you're keen to be the maintainer, so stake your claim. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: google-gflags
On Fri, Apr 10, 2009 at 08:06:54AM -0700, Ehren Kret wrote: It builds these binary packages: libgoogle-gflags-dev - a commandline flags processing library libgoogle-gflags0 - a commandline flags processing library Considering the plethora of other libraries to process command line flags, I think you'll need to sell this thing a little more. What does it do that the competition just doesn't do? Is it needed for another package? And so on. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: magicfilter (QA update of the package)
On Fri, Apr 03, 2009 at 10:23:37PM -0300, Rogério Brito wrote: Dear mentors, The package magicfilter, a print filter for spoolers like lpr/lprng/etc, in Debian had some issues (dependencies on nonexistent packages) since it had not been updated in the last 3 years (according to the changelog, its last updated was in 2006). Since I use the package regularly and care about it, I would love to see it uploaded to Debian and I plan on taking care of it (it is currently RFA'ed, as said in Bug #176737). I am, thus, looking for a sponsor for the new version 1.2-60.1 of magicfilter. Here is the relevant part of the changelog: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - magicfilter (1.2-60.1) unstable; urgency=low . * Non-maintainer upload. If you're planning on adopting the package and becoming the new maintainer, then it's not a non-maintainer upload, it's a new maintainer upload. You can also close the RFA bug. Beyond that, not knowing anything about the package or it's surrounding use cases, I'm probably not the best person to review it, but if you haven't had an upload from someone else by mid next week, ping me and I'll review/upload. Thanks for taking care of an aging package, too... - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New Developer Request
On Wed, Apr 01, 2009 at 11:57:43PM +0800, Cheng Renquan wrote: On Wed, Apr 1, 2009 at 11:20 PM, Ramesh rrame...@gmail.com wrote: Hello, I wish to contribute to debian as a developer. I got my keys signed by one of the existing developers. Please read http://www.debian.org/devel/join/newmaint And http://people.debian.org/~mpalmer/debian-mentors_FAQ.html - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Best way to solve a file conflict between packages?
On Mon, Mar 30, 2009 at 12:08:41PM +0200, Davide Puricelli wrote: I'm asking you help about bug #509367. Summarizing, new mono packages introduced a /usr/bin/csc file that conflicts with /usr/bin/csc I used to ship into chicken-bin, so now there's a conflict between these two packages. I think there're at least three possible ways to fix it: [...] 3) well, mono-devel came second, they introduced the problem and they should fix it, renaming their file. I'm not a big fan of their my popcon count is bigger than yours, I just know that we're using that name since a lot of time, while probably Mono users would be not so disappointed by a new name. I prefer the solution #3, but I'm not really impartial, I know, so, what do you think? I vote for #3 as well. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Packaging cluedome - copyright problems?
On Thu, Mar 26, 2009 at 08:02:44AM +, Tristan Greaves wrote: I'm taking a look at packaging the game Cluedome: http://www.cluedome.com/ I'm wondering if there are any copyright concerns. The game advertises itself as a clone, and the source ships with an example game rules rule and image -- which match that of the board came Clue/Cluedo. For example: Same layout, and characters such as Mrs White, Professor Plum... Yeah, those names are probably trademarked as well as the images and everything else copyrighted, so re-distributing any of that is likely to be troublesome. One option would be to NOT include those two data files in the package, but then it would not be a particularly user friendly installation. Producing unencumbered data files would seem to be the best option. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Packaging cluedome - copyright problems?
On Thu, Mar 26, 2009 at 08:40:50AM +, Tristan Greaves wrote: Matthew Palmer wrote: [clue data files with copyrighted info] One option would be to NOT include those two data files in the package, but then it would not be a particularly user friendly installation. Producing unencumbered data files would seem to be the best option. In terms of a separate package, or simply not including? Apologies for my newbie-ness here, I just want to get a handle on the approach you would take for said unencumbered data files. Submit them upstream and encourage them to include them in future releases in place of the risky ones. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: fsprotect
On Mon, Mar 23, 2009 at 12:41:48PM -0300, Eduardo M KALINOWSKI wrote: Stefanos Harhalakis wrote: I'll add it when it is available. Since this is a debian native package, I'm waiting for it to enter debian (if it ever happens) before creating a page. Whis is this native? From what I understood of the package, there is nothing Debian-specific in this package, why couldn't it be used in other distributions? It is actually fairly Debian-native. Excluding the contents of the debian/ directory, half of the files are Debian-specific, and would be of no use to anyone else. The other two files are fairly generic (well, there's nothing that leaps out at me screaming I'll only work on Debian!, at least). It's a call that could go either way. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Building localy
On Mon, Mar 23, 2009 at 11:38:16PM +0100, Jaromír Mike? wrote: Od: Chow Loong Jin hyper...@gmail.com I don't get it. debhelper should already pull in the appropriate perl. I cannot even begin to imagine how you borked up your perl installation to that extent. Neither me ... installation of ubuntu based distro is quite new here installed few packages from sid coz testing new packages. But not too much ... I am afraid of doing crazy things. Mixing packages from Ubuntu and sid qualifies as crazy things in my book. If you want newer libraries in your sid++ archive, then build them in sid and work from there (which I suspect you're now doing, based on info elsewhere in the thread). - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: fsprotect
On Sun, Mar 22, 2009 at 07:21:22PM +0200, Stefanos Harhalakis wrote: * Package name: fsprotect Version : 1.0.0 Upstream Author : Stefanos Harhalakis v...@v13.gr (me) * URL : http://www.v13.gr/ (not available yet) Based on your e-mail address, I'm guessing that www.v13.gr isn't going to be dedicated to fsprotect, so you should adjust this URL to point to the fsprotect project. It builds these binary packages: fsprotect - Helper scripts to make the filesystems immutable s/the//. Also, I'm not sure immutable is quite the right word here; I'm having trouble coming up with a better short description, though. The package appears to be lintian clean. Oh. No. It. Ain't. This package ignores some lintian errors/warnings. I believe that all of them are justified: non-standard-toplevel-dir fsprotect/ : This is required for fsprotect to work. This directory must exist in the root filesystem. *A* directory must exist in the root filesystem. I don't think a new top-level directory is justified for this. /lib would appear to be the usual location for things of this nature. fsprotect: no-debconf-config : There is no need for debconf config file. It only needs to display a warning message/note. If this is not OK I'll remove the note completely. That note is unnecessary. README.Debian is the correct place for information like this, which you've already provided. fsprotect: virtual-package-depends-without-real-package-depends : This package is never going to be a build dependency for other packages, so this should be OK. Never say never... on the other hand, keeping your depends list up to date with new kernel module versions isn't likely to be a whole lot of fun. init.d-script-does-not-implement-required-option /etc/init.d/fsprotect force-reload : It is imposible to provide a force-reload or restart option. Even the stop is a no-op. init.d-script-does-not-implement-required-option /etc/init.d/fsprotect restart : Same as above If the stop option is a no-op along with force-reload and restart, why did you implement stop and not the others? Take a look at mountall.sh. p.s. Please CC me. I'm not subscribed to the list. Mail-Followup-To is your friend. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: subnetcalc
On Sat, Feb 21, 2009 at 04:59:33PM +0100, Thomas Dreibholz wrote: I am looking for a sponsor for my package subnetcalc. subnetcalc is a simple IPv4 subnet address calculator. For given IP address and netmask, it calculates network address, broadcast address, maximum number of hosts and host address range. Also, it prints the addresses in binary format for better understandability. Can you give some details as to how this package is an improvement over the existing netmask package? - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: make user's home automatically
On Tue, Feb 03, 2009 at 08:09:28AM +0100, Anthony wrote: Le lundi 2 février 2009 22:46, Jack T Mudge III a écrit : | On Monday 02 February 2009 09:43:07 am Anthony wrote: | I have a problème about auto home creation. | | All my users are on a ldap server with is home parameter. (ofr exemple : | /home/user1) | | I would like to create the users home on user login BUT the home of my user | is not really the /home/user1 but the /export/home/user1 directory | which is auto-mounted on /home/user1 (with other automounted directory) | | I can't say I'm an expert at ldap, but couldn't you just softlink /home | to /export/home? I hope I'm not answering the wrong question... I can't do that. because others directories are mounted in the users' home with the autofs process. I use a multimount point (automount) so i can i have in one home, others directories,wich in fact are on centralized nfs servers. I thought the whole point of automount was to, you know, mount things automatically. If you need the directory to mount it on to be created (although, to me, that would be automounter's job too), then you could use pam_mkhomedir to do just that bit. Meanwhile, this is pretty off-topic for debian-mentors, so I'd appreciate it if you could pop down the hall to debian-user, which is the perfect place for this discussion. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: fspy - filesystem activity monitoring tool
On Sat, Jan 31, 2009 at 09:54:30AM +0100, Giuseppe Iuculano wrote: Matthew Palmer ha scritto: Looks good, except that the manpage mentions info pages which don't appear to exist in the package or upstream tarball. Fixed. Looks good. Uploaded. Ping me directly for future uploads if you like. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: fspy - filesystem activity monitoring tool
On Fri, Jan 30, 2009 at 05:45:44PM +0100, Giuseppe Iuculano wrote: I am looking for a sponsor for my package fspy. * Package name: fspy Version : 0.1.0-1 Upstream Author : Richard Sammet richard.sam...@gmail.com * URL : http://mytty.org/fspy/ * License : GPL Programming Lang: C Section : misc It builds these binary packages: fspy - filesystem activity monitoring tool Looks good, except that the manpage mentions info pages which don't appear to exist in the package or upstream tarball. Fix that up, reupload to m.d.n, let me know, and I'll upload it. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian OID / dicom3tools packaging
On Wed, Jan 28, 2009 at 07:44:27PM -0600, Steve M. Robbins wrote: Hi, To begin, I think there's some confusion about UID and OID. They are actually the same thing, according to Clunie: What DICOM calls UIDs are referred to in the ISO OSI world as Object Identifiers (OIDs). May I be the first to say, WT*F*? - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian OID / dicom3tools packaging
On Tue, Jan 27, 2009 at 01:05:25PM +0100, Mathieu Malaterre wrote: http://www.dclunie.com/medical-image-faq/html/part8.html#UIDRegistration ... To use SNMP one needs an Enterpise UID assigned by IANA, which is free and may also be used for any other purpose that requires a UID root. * http://www.iana.org/cgi-bin/enterprise.pl to register * http://www.iana.org/assignments/enterprise-numbers to see the registry You use the assigned enterpise number as in 1.3.6.1.4.1. ... I'm not online at the moment, so I can't read the FAQ reference given, but this most categorically *not* what an OID is supposed to be used for, *especially* in the SNMP context. An OID is supposed to provide a globally-unique but *stable* tree path to retrieve an SNMP value. You can't write a MIB if your OIDs are always changing out from underneath you. Instead, the SNMP MIB for this device should provide a table mapping the UUID of the device to entries in a table, or (if there's only one device per SNMP agent) then you can shortcut the table part of the whole thing. Which would mean for debian that I could simply be using 1.3.6.1.4.1.9586 (https://dsawiki.debian.org/dsawiki/iana). Would that be ok ? Should I be using some kind of subspace of this UID ? Since this would be done for debian-med I would suggest: $ echo med | od -b 000 155 145 144 012 1.3.6.1.4.1.9586.155.145.144 This would be the toplevel (root) of all UID generated from the dicom3tools package. Despite the similarity in acronym, an OID is not like a (U)UID. If you need a globally-unique value to identify a device or otherwise, we have whole RFCs dedicated to the task of describing how to generate one. Trying to brutalise an OID tree into doing the job is just plain *weird*, not to mention a bunch of other less-complimentary phrases. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian OID / dicom3tools packaging
On Tue, Jan 27, 2009 at 01:32:34PM +0100, Mathieu Malaterre wrote: So IMHO only large institution would need to change that to their own OID, unfortunately this is a compile time variable... Fix that. Making something that has to be unique to each installation a compile-time flag is stupendously stupid. Read it out of a config file. Then have the postinst generate a UUID properly, and you're pretty much guaranteed global uniqueness. See my other message about (not) using an OID for this purpose. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Listing dependencies with specific versions
On Tue, Dec 09, 2008 at 04:06:46PM +, Neil Williams wrote: On Tue, 9 Dec 2008 22:18:01 +0900 Paul Wise [EMAIL PROTECTED] wrote: On Tue, Dec 9, 2008 at 9:40 PM, Andy Hawkins [EMAIL PROTECTED] wrote: New symbols. It specifically has support for embedding images into the FLAC file. This was introduced in 1.2. Looks like you just found an RC bug in libflac++6 - includes new symbols in version 1.2.1-1 according to mole but the shlibs does not depend on that version: That is not a bug - the package building against it merely has to require that version. Sure, if the package that is building needs those symbols. But what about other packages that *don't* necessarily need those symbols, but get built against the newer version of the library anyway? Those symbols can end up in the built binary, but unless dpkg-shlibdeps happens to know that symbols have been added, it won't know to version the library dependency and all hell breaks loose. The solution: shlibs files, which list the last package version in which a new symbol was added to the library, so that the packaging system can make sure that that newer version is available to packages that need the extra symbols. The bug only arises if symbols are removed or function prototypes are changed in existing symbols. Not quite. If you remove symbols or change the type of a symbol, you need to bump the SONAME because that's the only piece of information that the dynamic linker has to be able to determine if a *newer* library will or won't work with a particular binary. If you add symbols, you don't need to bump the SONAME because the library is still backwards-compatible -- the SONAME effectively defines a base ABI that will continue to work into the future, and when that no longer applies, *then* the SONAME is bumped. If it was, we'd be on libglib.so.7787.0.0 by now. *cough* /usr/lib/libglib-2.0.so.0.1600.6 Not quite, but close... Hopefully more libraries will adopt the new dpkg symbols stuff so that this can be detected and fixed more often. The fix is only necessary if the symbol has CHANGED - added symbols can be managed perfectly well without a SONAME bump. Yes, you are perfectly correct about this. But we're not referring to a SONAME bump, we're talking about putting correct information in the shlibs file regarding new symbols. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dhcp-probe, another try to request with a lot of update
On Wed, Dec 03, 2008 at 04:14:06PM -0800, Michael Tautschnig wrote: [...] A new version of the package is available which integrates all updates you noticed. I controlled all files twice but an error or anything else could be hidden in. You will find all links need to reach the package on mentors.debian.net The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/dhcp-probe - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/dhcp-probe/dhcp-probe_1.2.2-2.dsc [...] Sorry, there are problems in your source package: - dget ... dpkg-source -x dhcp-probe_1.2.2-2.dsc fails because .orig.tar.gz does not match the size noted in the .dsc file, apparently it was modified afterwards. Are the modifications to the tarball documented in the source package somewhere? - The unpacked directory should better be named $package-$version, not $package_$version. Only if the tarball has been repacked for other reasons. Renaming the root directory of a tarball is *not* sufficient reason to repack it. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about bug hunting
On Tue, Dec 02, 2008 at 09:11:36PM +0100, Laurent Guignard wrote: Is there any means to know if someone work on a bug from RC bug ? rc-alert or popbugs show all RC bugs of our packages but if someone is already on, it isn't necessary to work to solve the bug. Are all works in progress referenced somewhere ? There's no real This is being worked on flag in the BTS; the problem with a flag like that is that if someone gives up or has to stop working on the bug there's no guarantee that they'll be able to or care enough to remove the flag again. It's courtesy to perhaps send an e-mail to the bug saying I'm working on this, I should have a fix within $TIMEFRAME, but it's certainly not something you can rely on happening. In practice, it's very, very rare for there to be collisions in bugfixes, except in specific instances like bug-squashing parties (when there are protocols in place to minimise problems). There's plenty of bugs to be fixed, and not that many people actively working on them, so I'd be inclined to not worry so much about possible duplication of work and just dig in and fix something that you think needs fixing. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hexec
On Mon, Dec 01, 2008 at 03:04:33PM +0100, Alexander Block wrote: Dear mentors, I am looking for a sponsor for my package hexec. Package name: hexec Version : 0.2.0-1 Upstream Author : Alexander Block [EMAIL PROTECTED] URL : http://sourceforge.net/projects/hexec/ License : GPL Section : devel It builds these binary packages: hexec - The hexec tool itself That's a really crap short description. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dhcp-probe, another try to request with a lot of update
On Sat, Nov 29, 2008 at 01:37:48PM +0100, Laurent Guignard wrote: I have another question about architecture : How is it possible to check if a package could be built on architecture without the appropriate hardware ? I can say that dhcp-probe could be build on i386 and any compatible architectures and with the upstream notes, i can say that dhcp-probe could be built on sparc but how to test on other architectures ? You don't test it yourself. When it's uploaded with Arch: any, it gets built on all architectures. If the build fails, you'll be notified of it (via a bug). Those bugs then get fixed. If it builds, but fails to run properly on an arch, then someone will find that out and lodge a bug too. The /etc/default/dhcp-probe directory is used to store all configuration files needed (one for each interface on which dhcp-probe is used). I thought that it was the best solution instead of spreading all configuration files directly in /etc. dh_installinit will automatically put a default file in place if asked nicely. See the appropriate man page for more details. Yes, dh_installinit will automatically put *a* default file in place. As you noticed, it place *A* default file. That i would like to do, is to place at least one file and i doesn't know how many because it depends of the number of network interfaces the host on which the package is installed has ! Uhm... no. That's not how it's done. /etc/default/file is a shell fragment that configures the operation of /etc/init.d/file. /etc/default is not a place for random config junk because you don't want to mkdir /etc/package. I repeat: DO NOT put your package's general config data in /etc/default. Put all that configuration data in /etc/dhcp-probe. If the init scripts for the package are currently structured such that there is one init script per configured interface, someone needs to learn to use for loops. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dhcp-probe, another try to request with a lot of update
On Thu, Nov 27, 2008 at 10:14:56PM +0100, Laurent Guignard wrote: Michal ??iha?? a écrit : Hi [...] Quick look at the package: - any reason why it is Architecture: i386? In reason of the libraries dependency. libnet1 package is for i386 architecture and dhcp_probe use it with previous update of this library in order to provide specific functions needed by dhcp_probe. #apt-cache show libnet1 Package: libnet1 [...] *Architecture: i386* That shows the binary package information on your system. If you'd run that on an arm system, dhcp-probe would now be an arm-only package. Examine the source package info, or just look at http://packages.debian.org/sid/libnet1 for the list of architectures that a package is built for. But at any rate, your argument is bollocks -- packages should have the architectures listed that *it* supports, regardless of it's dependencies. What if libnet1 *was* an i386-only package at the moment, but then in a month's time someone makes it truly arch-neutral and it builds for all arches? Much easier for everyone if your package doesn't need any changes to support more arches. May be i am wrong, but i think it is impossible to build a package on architectures that are not supported by needed libraries ? It's impossible to build, yes, but that situation will be adequately dealt with by the autobuilders. - why you manually create some directories and files? dh_install and dh_installdirs should do the job better and nicer. Anyway most of these dirs do not have to be created (examples) or look simply wrong to me (/etc/default/dhcp-probe) [...] The /etc/default/dhcp-probe directory is used to store all configuration files needed (one for each interface on which dhcp-probe is used). I thought that it was the best solution instead of spreading all configuration files directly in /etc. dh_installinit will automatically put a default file in place if asked nicely. See the appropriate man page for more details. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: howto create debian package with conf files
On Sat, Oct 25, 2008 at 11:21:19PM +0200, lucas kenter wrote: I would like to create a debian package for a simple project that I've created. The project contains only scripts, so there is no makefile or anything like that. For the script to work I would like to prompt for some simple questions like what url should be used, what organisation does this computer belong to. I've created a postinst script that asks these questions and writes them in a configuration file. (and this configuration file is listed in conffiles) Now the problem that I have is that when I reinstall this package, or upgrade it, all the questions are asked again. After some research I'm still not able to find a simple example or howto to do this right. - Is it necessary to use debconf to accomplish this? I'm not sure if Policy mandates using Debconf, but since this sounds like it's a local-only package, you don't need to follow policy anyway. I'd certainly *recommend* using debconf, though, as it provides both a standardised interface for the asking and answering of questions, a way to avoid re-asking questions, and also an easy means of automating the answering of the questions with preseeding, should you wish to do so in the future. - I thought that the postinst script was called with an argument install/upgrade/configure and so I could ask my question only when it was and install or configure, but this doesnt work. apperantly upgrading a package also uses argument configure... The postinst is called with the configure argument to say please configure the package that has just been installed, whether or not that installation is a new one or an upgrade. What might be of use to you is the fact that the second argument to the postinst call is the previous version that was fully configured. So you could do something like this in your postinst: if [ $1 = configure -a $2 = ]; then # Ask your questions fi Because the only time that the second argument will be empty is on the initial install -- after that, $2 will always contain the previously configured version. I've tried to look at packages like postfix, to see how they do it, but those are to difficult for my simple scripting skills :-( I don't know if the 'hello' package has any debconf in it, but it's usually considered the canonical how to get started package. Otherwise, I can't think of any specific packages that are good examples of the debconf art, but I know that MTAs in general are far too complex to make good examples for new packagers. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: howto create debian package with conf files
On Sun, Oct 26, 2008 at 12:10:26AM +0200, lucas kenter wrote: Wow, Thanks for the quick and helpfull response Matthew and ehm... I suppose this is what they mean by Debians helpfull community! I'm possitively amazed! :-D one more question though, So you could do something like this in your postinst: if [ $1 = configure -a $2 = ]; then # Ask your questions fi Because the only time that the second argument will be empty is on the initial install -- after that, $2 will always contain the previously configured version. Would this still allow users to issue a dpkg-reconfigure? Now *that* is an interesting question I've never explored. I'll leave that one up to you to test. If you put: echo $* at the top of your postinst, though, and then install, upgrade, and dpkg-reconfigure your package and see what happens... - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging with CMake
On Mon, Oct 06, 2008 at 01:45:10AM +0200, Laurent Léonard wrote: I try to build the package kio-ftps, but the 0.2 version (for KDE 4) uses CMake. What is the procedure to build a Debian package with CMake ? It's no different to any other package. You put cmake in the build-deps, run it to build and install the software, then use dh_install to shuffle the files where they need to go. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 'cdarch' has a dash version
On Sat, Oct 04, 2008 at 10:43:00PM +0200, Jann Horn wrote: Er... I haven't got a file named *.orig.tar.gz. I think it's because I myself made the program I want to put in a package. So my question is: How can I remove this dash? You don't want to remove the dash, you want to fix your package so that it's a proper non-native package. For that, the upstream tarball should match package_version.orig.tar.gz. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Setup Clean Etch Build Environment
On Tue, Jul 22, 2008 at 02:08:34PM +0200, Marko Randjelovic wrote: How to set clean Etch build environment, so I can backport a package from testing to etch? pbuilder, just like you would setup a lenny or sid build environment. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Modifying existing packages
On Mon, Jun 16, 2008 at 11:20:40PM -0400, Jerry Stuckle wrote: I'm new to this end - and don't know if what I want is possible or not. But here goes. What you want is quite possible, and something a lot of people do a lot. I need to modify some of the stock Debian packages for different options. For instance, I need to modify Exim to include MySQL support. I have several other packages with similar needs. What I need is a pointer to instructions on how I can get the the information for how these packages were built so I can modify them to meet my needs. I'd like to change them as little as necessary to maintain compatibility with other packages. I've looked through a lot of documentation and haven't figured out how to get the original build information. But with all the available info out there, I probably missed it, also. So if someone can at least provide a pointer to doc on where I should start, I'd appreciate it. I'm not aware of any canonical documentation that specifically addresses your needs, since it's been so long since I learnt this stuff. In general, what you want is the source package that corresponds to the binary package you want to build, and that can usually be obtained by running 'apt-get source package'. From there, you patch the package to suit your needs and then rebuild/compile the binary package (for which there are any number of methods, and documentation available). A quick Google search has found a couple of things that might be of use to you: http://www.murrayc.com/blog/permalink/2006/04/21/building-modified-debian-packages/ http://www.debian-administration.org/articles/20 - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: obm
On Tue, May 06, 2008 at 11:56:44AM +0200, Sylvain Garcia wrote: Dear mentors, I am looking for a sponsor for my package obm. * Package name: obm Version : 2.1.9-1 Upstream Author : [fill in name and email of upstream] ^^ That's good advice. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Config files which are writable by www-data
On Sun, Feb 10, 2008 at 12:02:02PM +0100, Roland Gruber wrote: Matthew Palmer schrieb: Well, don't do that, then. Ship the template files somewhere else, and then copy them into /var if they're not already there. that is probably the best solution. I think I will put them in /usr/share/doc/ldap-account-manager/examples and copy them from there to /var. Except that the contents of /usr/share/doc must not be relied upon for the proper functioning of your package. Somewhere under /usr/share/l-a-m is the correct place for these sorts of things. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Config files which are writable by www-data
On Sat, Feb 09, 2008 at 10:09:13AM +0100, Roland Gruber wrote: The problem is that my application provides a set of default templates for user creation. These files must be editable via the application itself and therefore reside in /var/ldap-account-manager. I most sincerely hope they do not. But the files are overwritten on every package installation because they are not treated as config files in Debian's sense. Well, don't do that, then. Ship the template files somewhere else, and then copy them into /var if they're not already there. Now I think about moving the files to /etc. But Debian policy sais that files in /etc should be owned by root and writable only by the user. So what can I do? Would it be ok to assign these files to group www-data and allow the group write access? Or would it be better to own them by www-data and not root? There are already some files in /etc that are writable by www-data, so that's a possibility too. It comes down to direct admin editability -- is it expected that sysadmins may want to futz around with these template files using a text editor, or is the only sensible way of dealing with these files through the application? If the former, /etc. If the latter, /var. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gnomecatalog
On Tue, Jan 08, 2008 at 08:02:02PM +0100, José Sánchez Moreno wrote: Dear mentors, I am looking for a sponsor for my package gnomecatalog. * Package name: gnomecatalog Version : 0.3.1-1.0 That '.0' at the end isn't necessary. Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] *cough* It builds these binary packages: gnomecatalog - Cataloging software for CD, DVD, and hard disk files Do you have a long description? - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How a package will determine the dependencies
On Thu, Nov 01, 2007 at 08:57:19AM -0700, varun_shrivastava wrote: i have a library and want to package it But it has a configuration option as --enable-debug=yes/no So i need to make 2 packages as 1) libinput0 2) libinput0-debug So now if an application uses libinput, how the $(shlibs:Depends) variable get substituted, during application package being built. Because dpkg will automatically determine and substitute the variable according to which one of the above two lib packages are installed, at the time of application package being built. It won't be a problem, because the -dbg package (the standard suffix isn't -debug) doesn't have full copies of the library, just the debugging symbols. The only place where you could run into trouble would be if --enable-debug for this package doesn't just enable -g -O0 and disable stripping, but instead actually modifies the source to be compiled (such as adding fprintf(stderr, DEBUG: Got here\n) throughout the source, or something else similarly irritating). If that's the case, then you've got a real problem, as I can't think of a really good solution to that. I suspect the best solution there is going to be to have the regular library and the -dbg library *conflict* with each other, and have the -dev package depend on only the non-dbg version, so anyone who's building against the library is guaranteed to only have the non-dbg version installed. That is, however, unbelievably ugly, and largely defeats the purpose of having a -dbg version of the library, because the people who are going to want the debugging-enabled library are the people who are linking against the library... I would suggest working out exactly what --enable-debug does to the library build process, and changing anything that isn't symbol related to be run-time rather than build-time configured (so enabling any fprintf(stderr, DEBUG: ) with an environment variable rather than #ifdef), and then the problem reverts to the standard strip symbols, stick symbols in -dbg package method. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing transition stuff in debhelper scripts after which time?
On Tue, Sep 25, 2007 at 04:46:43AM +0200, Daniel Leidert wrote: Today I stumbled over the question: After which time should transition stuff be removed from the debhelper scripts. In this special case I'm talking about install-sgmlcatalog calls in (e.g.) postinst scripts. Adam Di Carlo announced the depreciation of install-sgmlcatalogs in 2001. However, almost all related docbook* packages still contain this stuff. So I'm wondering, how long one should wait before such obsolete stuff can be removed? I mean, there is no requirement to support updates from e.g. Woody to Lenny, right? I checked the Debian Social Contract and the Policy manuals, but didn't find an information related to this topic. Maybe I overlooked it? I'm not sure where it's defined, but we don't support upgrades to anything other than the next release. So, unless it's needed to upgrade from an Etch system, it doesn't need to be in new releases of the package uploaded to unstable as of now. Now, that being said, it's often helpful (for backporting, for instance) to keep a bit more history in the scripts, but supporting woody is going a little overboard -- upgrading from Sarge would be absolute limit for me. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dosbox (updated package)
On Tue, Sep 18, 2007 at 04:39:05PM +0200, Markus Schölzel wrote: Dear mentors, I am looking for a sponsor for my package dosbox. * Package name: dosbox Version : 0.72-0.1 Upstream Author : The DOSBox-Team [EMAIL PROTECTED] * URL : www.sourceforge.net/projects/dosbox/ * License : GPL Section : otherosfs It builds these binary packages: dosbox - A x86 emulator with Tandy/Herc/CGA/EGA/VGA/SVGA graphics, sound a The maintainer seems to be inactive since 0.65 (2006-03-30). Does this mean that you haven't adopted the package with the maintainer's approval? To be polite, you should try and make sure that the current maintainer is OK with you taking over. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: nagvis
On Mon, Sep 17, 2007 at 10:18:48PM +0200, Martin Zobel-Helas wrote: i know it is a problem on my side, but please give me a bit time. Sorry for communicating this a bit bad, but i was quite overworked the last weeks, esp. as i am currently moving to a new home. For the others: i allready had told Hendrik 2 weeks ago i would be willing to upload both packages, nagvis and ndoutils. If you're a bit overloaded Martin, there's no problem with someone else sponsoring this upload and you taking over sponsorship when you've got a few more free cycles. Hendirk, a long description in your RFS request would be helpful to potential sponsors. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging question
On Sat, Sep 15, 2007 at 07:20:29PM -0400, Peter wrote: If I post this question in the wrong list please tell me where to ask the question :) I created an update package and it install perfectly but for one thing. If I install an earlier version, my package won't show up as an update. It's the first time this has happened. I believe I know why it doesn't but I don't know how to fix it :) The old version has a version as 1:2.1.1, my version is a 2.2 but because of the 1: in front of the earlier version that one seems to be preferred. In the debian/control file I added the line: Replaces: package ( 1:2.1.2) Result was no update Changed it to: Replaces: package ( 1:2.1.1) Result was no Update Changed it to: Replaces: package ( = 1:2.1.2) Result was no update So what do I need to do to make my package be seen as an update? You need to leave the epoch (the 1:) in the version number of your new package. Once an epoch is in place, it can never be removed as long as the same package exists in the system. Policy 5.6.12 (http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version) will give you all the goss. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to patch a patch
On Tue, Sep 11, 2007 at 12:25:52AM +0200, Mihamina (R12y) Rakotomandimby wrote: There is a list of softwares already debian packaged. The packager has applied a patch on them. I need to modify again the patched part. So, I need to patch the patch. I guess in real world I wont patch the patch, but what is the easy way to do so? I know a bit using dpatch (or is there a replacement for it? I dont remember) but then,... Thank you for your indications. Can you tell us which package it is, and exactly what you want to do? - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: eprints
On Thu, Aug 30, 2007 at 03:17:18PM +0100, David C Tarrant wrote: Dear mentors, I am looking for a sponsor for my package eprints. I don't see an ITP for this package. Making Research Freely Available - For many years we have been helping researchers and their institutions to provide free online access to their research output (documents, multimedia and data). This tells me nothing about what this package actually does. Is it some sort of document management system? Or something else entirely? * Package name: eprints Version : 3.0.1-1 Upstream Author : Christopher Gutteridge * URL : www.eprints.org * License : GPL (v2 or later) Section : web It builds these binary packages: eprints- EPrints - Repository Management Software This description is suboptimal. Don't repeat the package name in the short description, and consider the overloading of terms like Repository within Debian, and the possible confusion amongst users. I would be glad if someone uploaded this package for me. This package needs work before it is suitable for inclusion in the Debian archive. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: eprints
On Thu, Aug 30, 2007 at 06:27:09PM +0100, David C Tarrant wrote: It builds these binary packages: eprints- Content Management System for Information Archiving EPrints is a web-based content management system. It allows a large number of contributors to share their digital objects/documents with others. Contributors provide descriptive data (metadata) which is dependent on the type of object being deposited (presentations, articles, books etc.). Before being published objects must be accepted by an editor. Users can access published objects through web-page listings, searches, email alerts or via integration with other systems. Tasty description. I like it. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package requiring a customised version of libc6
On Fri, Aug 24, 2007 at 12:23:39PM +0100, David Given wrote: (Incidentally, the more I look at fakechroot the more I'm coming to believe that it's no use for anything whatsoever. The security aspects of it are... erm... nil; it's trivial for the client app to break out of its jail. Is this a potential problem?) No, because it's not meant to provide security, just like fakeroot isn't meant to provide real root privs. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: homebank (license issue)
On Thu, Aug 16, 2007 at 02:42:19PM +0200, Francesco Namuri wrote: Hi mentors, I've received from the author of homebank a pre-release version 3.4 of homebank with new SVG icons released under GPL, I have a doubt regarding one of these icons, it is released with this license metadata: cc:License rdf:about=http://web.resource.org/cc/PublicDomain; [...] It's ok for debian? While the concept of Public Domain is fine for Debian, I'm a little concerned about the execution. This doesn't seem like a proper licence grant, like the GPL boilerplate, and hence might not be considered to be sufficiently clear for Debian to take the risk on. I'd check with d-legal, and perhaps try and get a clearer licence statement out of upstream. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: php4 in lenny and Depends
On Sun, Aug 12, 2007 at 03:33:20PM -0400, Kevin Coyner wrote: I have a package that I maintain that has a dependency on php4-cgi or php5-cgi. If I remember correctly php4 will not be in lenny. Correct me if I was dreaming and misunderstood this. Nope, I think you're right. Last I heard, PHP4 was getting removed before Lenny's release. If I am correct, then in any future repackagings of my packages for lenny, do I no longer need to Depend on php4-cgi and now just on php5-cgi? You should definitely order your dependency so that php5-cgi comes first (eg php5-cgi | php4-cgi) but I'm not convinced that removing the option of php4-cgi is necessarily a fantastic idea at this stage. If your package doesn't otherwise need packages (or versions of packages) that only exist in unstable, then leaving the php4-cgi option there allows people to install the newer package in their older environments (that perhaps use PHP4). While backporting is an alternative to this, I like to allow people maximum flexibility. (This isn't any sort of official pronouncement, just my personal opinion. If you get differing opinions from (eg) release team people or ftpmasters or pretty much anyone, ignore me) - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creating Source Packages
On Sun, Jul 29, 2007 at 11:13:06AM +1000, Brendon Costa wrote: I have been looking on the web, but have found little in the way of tutorials on how to create a debian source package. I have created a binary package for my project (EDoc++: http://edoc.sourceforge.net/), but want to create a source package and then build the binary one from this. Does anyone here know of a link where there is information on doing this sort of thing? I couldn't believe google didn't come up with anything as I am sure this is a VERY common way of creating debian packages. It's *really* common -- pretty much every upload into Debian has to provide the source package. You just run 'dpkg-buildpackage -S' in the unpacked tree and it'll do all the usual dpkg-buildpackage kind of things and produce a source package including a .changes file. If you want to get a bit lower level, 'dpkg-source -b dir' will just build the diff/dsc. Manpages, as usual, will give you all the dirty details. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creating Source Packages
On Sun, Jul 29, 2007 at 02:59:53PM +1000, Brendon Costa wrote: Actually, there is no one-file source package form of a deb like there is for rpms. When you create your binary package, a signed .dsc file is created with which you can create the deb in conjunction with the original upstream tarball and the diff of the debian packaging. Ahh that would have been my mistake. I thought there would have been a single .deb file that contained the source package similar to that of source rpm's. I have those files listed below (Excepting the package_1.0-1.diff.gz) as there are no differences that need to be applied for debian. So a source distribution would just include the .dsc and .tar.gz file. Take a look at http://people.debian.org/~mpalmer/debian-mentors_FAQ.html#native_vs_non_native and the question after that (What's wrong with upstream shipping a debian/ directory?). - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting involved with Debian development...
On Thu, Jul 26, 2007 at 04:13:06PM -0400, Tim Hull wrote: Anyway, I am curious what exactly it entails to become a Debian developer, and what would be best to do if one wanted to involve oneself in Debian with this ultimate goal. The FQ... the FAQ... grin http://people.debian.org/~mpalmer/debian-mentors_FAQ.html - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: fuse (updated package)
On Tue, Jul 24, 2007 at 11:21:09AM +0200, Adam Cécile (Le_Vert) wrote: Dear mentors, I am looking for a sponsor for the new version 2.7.0-1 of my package fuse. I'm taking a look at this now. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sponsored: fuse 2.7.0-1
On Tue, Jul 24, 2007 at 11:21:09AM +0200, Adam Cécile (Le_Vert) wrote: Dear mentors, I am looking for a sponsor for the new version 2.7.0-1 of my package fuse. Looks solid. Uploaded. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ftpsync -- fast ftp directory synchronization
On Sun, Jul 15, 2007 at 05:13:58PM +0200, Julian Andres Klode wrote: I am looking for a sponsor for my package ftpsync. Any major feature improvements over sitecopy? - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Broken uploads to mentors.debian.net
On Sun, Jul 15, 2007 at 10:41:57PM +0200, Christoph Haas wrote: I have no good explanation for the situation Neil mentioned though. The package maintainer must have uploaded a package with an orig tarball. But then the orig tarball was changed and an upload without an orig tarball was done that mentioned the orig tarball though. How come the .dsc file mentions an orig file that is not uploaded? All files mentioned in the .dsc file must be uploaded. I'm confused. No they don't. All the files mentioned in a .changes get uploaded, because the .changes represents the changes made to the archive (hence the name). In contrast, a .dsc describes a particular Debian source package. If someone builds a Debian source package with a different .orig.tar.gz to another source package (of the same source package name and upstream version), then you'll get a different .orig.tar.gz mentioned in the .dsc. What happens from there is a matter for whatever is processing the .dsc after that. From a personal perspective, I think m.d.n should work as close to ftp-master as possible. If you want to keep the ability to have people take multiple stabs at a single package revision, then at the very least, .dsc files should be verified after upload and if the sums don't *all* match or one of the files in the .dsc is missing, the upload is rejected. That would solve Neil's problem, at the very least. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage and fakeroot
On Sat, Jul 14, 2007 at 12:50:32AM -0500, Manoj Srivastava wrote: On Tue, 10 Jul 2007 11:46:13 -0700, Steve Langasek [EMAIL PROTECTED] said: 'fakeroot dpkg-buildpackage' runs the build target under fakeroot, which is undesirable primarily because Debian 'build' targets are required to not depend on root privileges, and running them under fakeroot can hide bugs of this nature. I also vaguely recall some actions which work as an ordinary user but fail under fakeroot; due to a difference in behaviour. I no longer can recall the details, though, so I could be mistaken. The bzr test suite, for one. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Another revision of the d-m FAQ
In my last update of the FAQ, I forgot to include a substantial rework of the difference between native and non-native packages from Thijs Kinkhorst. The rework also split the discussion on why debian dirs in upstream tarballs is bad, which should help in the future when people ask about it -- now you've got something to point them at. Thanks Thijs, and thanks also to everyone else who has contributed material to the FAQ in the past. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
