Bug#537206: ITP: ctcs -- hardware testing/burnin suite
Package: wnpp Severity: wishlist Owner: Matthew Palmer * Package name: ctcs Version : 1.3.1pre1 Upstream Author : Jason T. Collins * URL : http://sourceforge.net/projects/va-ctcs/ * License : GPL Programming Lang: C Description : hardware testing/burnin suite The Cerberus Test Control System is is a test suite for use by developers and others to test hardware. It includes a modular test system that allows you to build and integrate your own tests. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dpkg doing wrong math (0.09 = 0.9) ?- [was: dak now supports ~ in version numbers]
On Thu, Aug 10, 2006 at 08:47:14PM -0400, Roberto C. Sanchez wrote: > On Fri, Aug 11, 2006 at 10:42:53AM +1000, Matthew Palmer wrote: > > > > I'd imagine you'd be hard pressed to find a mathematician who knows what to > > do with a number that reads 0.0.9, either. That's why we're software > > developers, not mathematicians. > > > > Or, to put it another way: your numbers are not our numbers. > > I never said I was a mathematician :-) The royal 'your', though. > The original comparison, though, was 0.09 and 0.9. We're out to break *all* the rules. If we need to make up a new evaluation algorithm to be able to handle 0.0.1, we may as well include handling zero-padding differently as well. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg doing wrong math (0.09 = 0.9) ?- [was: dak now supports ~ in version numbers]
On Thu, Aug 10, 2006 at 07:47:36PM -0400, Roberto C. Sanchez wrote: > On Fri, Aug 11, 2006 at 01:29:40AM +0200, Adeodato Simó wrote: > > * Michael Biebl [Fri, 11 Aug 2006 01:12:59 +0200]: > > > > > that "dpkg --compare-versions '0.09' '=' '0.9'" yields true, which I > > > think is rather odd, because it means that now all version numbers up to > > > 0.9 will be considered < 0.09+0.1. > > > > 0.09 = 0.9 means: > > > > 0 == 0 > > and > > . == . > > and > > 09 == 9 > > > > Which is pretty standard math. ;-) > > > Except that the final comparison ignores that the number was to the > right of the decimal, making the zero significant. I think you will be > hard pressed to find a mathematician who supports dropping significant > zeros for no good reason. I'd imagine you'd be hard pressed to find a mathematician who knows what to do with a number that reads 0.0.9, either. That's why we're software developers, not mathematicians. Or, to put it another way: your numbers are not our numbers. - Matt
Re: dpkg doing wrong math (0.09 = 0.9) ?- [was: dak now supports ~ in version numbers]
On Fri, Aug 11, 2006 at 01:12:59AM +0200, Michael Biebl wrote: > I have to admit that when choosing 0.09+0.1 as version number I didn't > check with dpkg --compare-versions because then I would have discovered > that "dpkg --compare-versions '0.09' '=' '0.9'" yields true, which I > think is rather odd, because it means that now all version numbers up to > 0.9 will be considered < 0.09+0.1. > > So, what should I do now: > 1.) Wait for a 0.10 release. I think my users wouldn't be happy ;-) > 2.) Use an epoch. > 3.) File a bug report against dpkg. > > If it's not a bug in dpkg, could someone please elaborate on the > reasoning of this behaviour. I'd be grateful for any comments and replies. Oooh, oooh! I know the answer to this! Having recently written a program to do quite detailed things with package version numbers, I've gotten intimately familiar with Policy s5.6.12. Specifically, 09 == 9 because "The numerical values of these two parts are compared" (3rd last paragraph), so leading zeroes are effectively stripped before comparison. I don't think it's a bug in dpkg or policy, realistically speaking -- the old practice of "0.01" versioning is pretty weird in general (periods are cheap, just make it 0.0.1 instead), and numeric sorting is much better in the general case (would you want 9 gt 10 == true?) but it just happens to have bitten you here. I think you're up for an epoch. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Wed, Aug 09, 2006 at 08:14:43PM +, David Nusinow wrote: > On Wed, Aug 09, 2006 at 11:12:15AM +0100, Ian Jackson wrote: > > What I need as someone working on a package for which I'm not the > > maintainer is this: > > > > dpkg-source -x must give me something I can immediately edit and diff > > on the resulting tree after I've edited and built it must produce a > > sane patch. So debian/rules build must not edit any source files. > > > > This is the supposedly universal interface for Debian packages, which > > the rest of us (ie, people not the package maintainer) are relying on. > > It is my opinion that packages where dpkg-source -x doesn't produce > > the source that actually gets compiled are in violation of policy. > > In every single patch system I've encountered, you can run debian/rules > patch and get the patched source. It's only one more command and I consider > it universal for all patch systems deployed in Debian. dbs doesn't have it. It also isn't mentioned as a best practice *anywhere* I can find that people might commonly look, so it isn't immediately obvious to people who might decide to roll their own next time. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Sun, Aug 06, 2006 at 01:52:09PM +0100, Darren Salt wrote: > I demand that Matthew Palmer may or may not have written... > > > I've given up on this thread, but I just have to say one thing: > > > On Sat, Aug 05, 2006 at 11:38:39AM +0300, George Danchev wrote: > >> `Hate patch systems' can easily apply all chunks and start > > BWAHAHAHAHAHAHAHAHAHAHA! > > > Easily. Heh. You should be a comedian. > > Actually, yes, it *should* be easy: "debian/rules patch". I can't see any mention of that target in Policy. Am I looking at a badly outdated version? (3.7.2.0, 2006-05-04). It also fails to work on a split-patch package I've been working on over the weekend (just to renew my hatred of such systems). Should I be filing a serious bug against that package? Even the devref, s6.1, fails to make the slightest mention (let alone recommendatation) as to a target to provide. Even the two patch systems it does mention don't provide a common interface to such a common and necessary task. Can you provide an authoritative reference which documents the universal necessity of a patch target to debian/rules? Or are you, perhaps, taking the convention of a single patch management system and ass-u-ming that it works across the board, when it, most assuredly, does not? > Bwahahaha, as they say. :-) Yep, I certainly do say that. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
I've given up on this thread, but I just have to say one thing: On Sat, Aug 05, 2006 at 11:38:39AM +0300, George Danchev wrote: > `Hate patch systems' can easily apply all chunks and start BWAHAHAHAHAHAHAHAHAHAHA! Easily. Heh. You should be a comedian. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Thu, Aug 03, 2006 at 02:08:00AM +0300, George Danchev wrote: > On Thursday 03 August 2006 00:45, Matthew Palmer wrote: > > On Wed, Aug 02, 2006 at 08:47:01PM +0300, George Danchev wrote: > > > On Wednesday 02 August 2006 20:11, Otavio Salvador wrote: > > > > Frank Küster <[EMAIL PROTECTED]> writes: > > > > > George Danchev <[EMAIL PROTECTED]> wrote: > > > > >>> > But you lose debian specific patches to be clearly separated from > > > > >>> > the upstrem source (digging diff.gz for that is not fun), unless > > > > >>> > one knows where to find > > > > >>> > > > > >>> First, what is a "Debian-specific patch?" Isn't everything in > > > > >>> diff.gz that? > > > > >> > > > > >> Right, but you have parts which touch upstream files > > > > >> (debian/patches/*), and parts which does not (debian/!patches). I > > > > >> prefer them to be clearly separated when the whole debian source > > > > >> package is unpacked. > > > > > > > > > > Not only that. Many packages make changes to upstream files that are > > > > > Debian-specific (e.g. for using infrastructure or libraries that > > > > > don't exist outside), but also changes to upstream files that > > > > > will/should be temporary because upstream will apply the same patch, > > > > > has been asked to, or the patch has been taken from their development > > > > > version. > > > > > > > > Iff we use a branch to each change we can have same behaviour using a > > > > SCM but anyone that would want to change or contrib changes will need > > > > to learn how we deal with this all. > > > > > > This is fine, but (again) you forget about your 'apt-get source' users, > > > which are not supposed to be aware of your SCM, where your repo is, > > please, find 'SCM' in the above row, thanks. I did. Using an SCM and shipping a monolithic diff.gz makes it *easier* for the 'apt-get source' user to work with the package, because there isn't a randomly-chosen "debian patch manager" in the way to confuse and confound. > > source and why they have been applied." > > > > Which is it? Clearly identified patches, or "not supposed to be aware"? > > Obviously 'SCM' is what you missed above, which led you to such a confusion. > Yes, people might be able to apt-get source and have patches which are to be > (un)applied to the upstream source clearly identified without having to > bother with any SCM to do the _patching_ work. (SCM == VCS) They don't have to know anything about the SCM to manipulate a monolithic diff.gz package. This is in contrast to a "patch-managed" package, where you *MUST* learn the patch management system to make a minimal, useful NMU patch. > > > I.e. if you have patches, do them debian way (using a debian patch > > > system) > > > > Please identify "the debian way", so I may start using it. > > > > Oh wait. There isn't any single Debian way. Never has been, almost > > certainly never will be. > > There is no signle SCM you can do packaging either. No, there isn't, but the difference is that the SCM doesn't get in your way. - Matt
Re: Centralized darcs
On Wed, Aug 02, 2006 at 08:36:18PM +0200, Eduard Bloch wrote: > #include > * John Goerzen [Wed, Aug 02 2006, 01:01:51PM]: > > On Wed, Aug 02, 2006 at 08:47:01PM +0300, George Danchev wrote: > > > > to learn how we deal with this all. > > > > > > This is fine, but (again) you forget about your 'apt-get source' users, > > > which > > > > NO. They need not care. They can just hack and send me diffs. My > > debian/changelog will already document what has been going on anyway. > > Heh. So they need two copies, one where they do modifications, then diff > those and send you the diff. Or they need to change debian/changelog and > learn to use interdiff. All that is more work that just callin > "dpatch_edit_patch foo". $ dpatch_edit_patch zsh: command not found: dpatch_edit_patch Yep, that was very little work. Even less benefit, though. Oh, you meant dpatch-edit-patch, perhaps? That's great, but there's plenty of packages that contain debian/patches/ were dpatch-edit-patch will get you nowhere. And when you do find a package where dpatch-edit-patch "works", all it does, effectively, is make two copies, one where you do modifications, and then diff those and store the diff. Gee that sounds familiar. dpatch-edit-patch also suffers from the difficulty that you need to manually revert bits and pieces that you don't want in your final dpatch, like (for instance) updated changelog entries (which you made to make test builds to ensure that everything's working OK before going through the rigamarole of wrapping up the patch, and then reopening it again -- a full-tree diff, removal, and re-copying -- if you got it wrong. > Why do dist.VCS fans always talk about patches like the would rain from > the sky just so? Because we've moved on from being our own VCS (a la dpatch) and are now using an automated tool to track things *for* us, instead. So now working with patches is simple and straightforward. > > > are not supposed to be aware of your SCM, where your repo is, patches > > > applied > > > to the upstream source and why they have been applied. I.e. if you have > > > patches, do them debian way (using a debian patch system) even using SCM > > > to > > > manage your whole packaging. Your orig.tar.gz must be really original > > > tar.gz, > > > and your diff.gz should hold whole debian-specific thing. > > > > I am quite well aware of that and it is trivial to do. > > And if the user has more than one patch which needs to be maintained > separately, is it still is still trivial FOR HIM? (or her) HE (or she) can work out how to make things work FOR HIMSELF (or herself). Chances are, no matter which system you choose, someone out there isn't going to like it. So why hamstring yourself with a sub-standard system that you don't like working with, just to please some minority of users? - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Wed, Aug 02, 2006 at 08:47:01PM +0300, George Danchev wrote: > On Wednesday 02 August 2006 20:11, Otavio Salvador wrote: > > Frank Küster <[EMAIL PROTECTED]> writes: > > > George Danchev <[EMAIL PROTECTED]> wrote: > > >>> > But you lose debian specific patches to be clearly separated from the > > >>> > upstrem source (digging diff.gz for that is not fun), unless one > > >>> > knows where to find > > >>> > > >>> First, what is a "Debian-specific patch?" Isn't everything in diff.gz > > >>> that? > > >> > > >> Right, but you have parts which touch upstream files (debian/patches/*), > > >> and parts which does not (debian/!patches). I prefer them to be clearly > > >> separated when the whole debian source package is unpacked. > > > > > > Not only that. Many packages make changes to upstream files that are > > > Debian-specific (e.g. for using infrastructure or libraries that don't > > > exist outside), but also changes to upstream files that will/should be > > > temporary because upstream will apply the same patch, has been asked to, > > > or the patch has been taken from their development version. > > > > Iff we use a branch to each change we can have same behaviour using a > > SCM but anyone that would want to change or contrib changes will need > > to learn how we deal with this all. > > This is fine, but (again) you forget about your 'apt-get source' users, which > are not supposed to be aware of your SCM, where your repo is, patches applied > to the upstream source and why they have been applied. Do you think you can stick to one story for a whole thread? Do you want to know what patches are in there, or not? First you said "I prefer them to be clearly separated when the whole debian source package is unpacked." and "Some people prefer to have debian-specific patches (applied to the upstream source) separated and with comments appended" (I presume you're part of the "Some people"). Yet now you're saying "'apt-get source' users [...] are not supposed to be aware of [...] patches applied to the upstream source and why they have been applied." Which is it? Clearly identified patches, or "not supposed to be aware"? > I.e. if you have patches, do them debian way (using a debian patch system) Please identify "the debian way", so I may start using it. Oh wait. There isn't any single Debian way. Never has been, almost certainly never will be. - Matt
Re: Centralized darcs
On Wed, Aug 02, 2006 at 06:54:51PM +0300, George Danchev wrote: > On Wednesday 02 August 2006 18:35, John Goerzen wrote: > > On Wed, Aug 02, 2006 at 06:01:27PM +0300, George Danchev wrote: > > > > > How is that not true if one knows a given patch system and does know > > > > > about your VCS and needs to work on one of your packages. Do they > > > > > have > > > > > > > > They just apt-get source, hack away, and send me a diff. > > > > > > Also true for any debian patch system, but with the gain the debian > > > specific > > > > No, it's not, because for most of them, the "source" that you get with > > apt-get source is a tar.gz file and a debian/ directory. You can NOT > > just hack away on that like you would any package. You MUST learn the > > specific tool to do ANYTHING. > > After apt-get source you get debian source package directory with > debian/patches/ inside. Learing to add/remove/update patches is easy and if > one is not able to learn that, better not to send any diff, waste of time. I'm going to be charitable and assume you haven't done any significant QA work. Working with any of the debian/patches management systems (and there are oh-so-many of them) is a pest, and having to learn how all of them work (if only to get a pre-patched source tree I can try and do useful work on) is a wholesale pest. > > > > They shouldn't be converting the package to use a patch system. > > > > > > They can send new patch to be included in debian/patches/, remove one, or > > > > If I am using darcs, or svn, or whatever, there is no debian/patches at > > all. I don't understand what you are saying here. > > Where are you debian specific patches you apply to the upstream source > tree as patches in debian/patches/ do. Or your have orig.tar.gz already > patched with these and which is no more original tar.gz, and diff.gz not > containing these. This is forbidden by the policy as we know. And this > adds confusion. Of course you don't modify the orig.tar.gz. the diff.gz is capable of patching more than just the contents of debian/. > > > But you lose debian specific patches to be clearly separated from the > > > upstrem source (digging diff.gz for that is not fun), unless one knows > > > where to find > > > > First, what is a "Debian-specific patch?" Isn't everything in diff.gz > > that? > > Right, but you have parts which touch upstream files (debian/patches/*), and > parts which does not (debian/!patches). I prefer them to be clearly separated > when the whole debian source package is unpacked. Why? You're doing an NMU. You don't need to know which patches need to be sent upstream. > > Maybe you mean just stuff in debian/. Well it's easy enough to filter > > that out. > > > > I think people that are NMUing packages rarely care about this. > > see above. What, exactly? - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Wed, Aug 02, 2006 at 06:31:18PM +0200, Frank Küster wrote: > John Goerzen <[EMAIL PROTECTED]> wrote: > > I think people that are NMUing packages rarely care about this. > > When NMU'ing a package, I'd really appreciate to know which changes have > which purpose and which "specificity". In particular when trying to > incorporate a fix provided by upstream - why the hell doesn't it apply > cleanly? Did the Debian maintainer already try to address the problem > differently, We have changelogs for that. If a maintainer doesn't fill out changelogs adequately, what are the chances that they're going to document their patches any better? - Matt
Re: Centralized darcs
On Wed, Aug 02, 2006 at 06:01:27PM +0300, George Danchev wrote: > On Wednesday 02 August 2006 17:31, John Goerzen wrote: > > On Wed, Aug 02, 2006 at 05:20:26PM +0300, George Danchev wrote: > > > debian/patches/ as separate file, how do I know how to update/remove/etc > > > > There would be no debian/patches. > > That could be bad sometimes, or most of the time. Some people prefer to have > debian-specific patches (applied to the upstream source) separated and with > comments appended, which leads to more fine-grained control. They're doing an NMU, not completely reauthoring the package. What do they care about the subtleties of some random other patch? > update it as well. They can send a patch against the toplevel soruce package > directory. Exactly. > > > them ? How is that different from learning darcs patch system which might > > > happend to be new for me. There is also git arch which also pretend to be > > > a patch system at heart. Thus the diversity is the same as in different > > > patch system / not necessary a bat thing though /. > > > > They can build and use the package just like normal. Somebody doesn't > > have to know how to use my VC in order to work on my package, which is > > different from the situation with the patch systems. > > But you lose debian specific patches to be clearly separated from the upstrem > source (digging diff.gz for that is not fun), They're doing an NMU. diff.gz archaeology should not be necessary. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#380468: ITP: phpunit2 -- Unit testing suite for PHP5
On Sun, Jul 30, 2006 at 02:40:47PM +0200, Bart Martens wrote: > Package: wnpp > Severity: wishlist > Owner: Bart Martens <[EMAIL PROTECTED]> > > * Package name: phpunit2 *cough*330301*cough* - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question on setting setuid bit
On Thu, Jul 06, 2006 at 11:13:30AM +0200, Thibaut Paumard wrote: > Le jeudi 06 juillet 2006 à 07:36 +1000, Matthew Palmer a écrit : > [about suid bits] > > My personal preference would be for the maintainer to just take a stand, set > > it or not, and let people who actually know what's going on to use > > dpkg-statoverride to fix the problem to their satisfaction. (This actually > > also applies to man-db and cdrecord, as it happens, but there's a lot of > > inertia to overcome there). > > In that case, does it make sense to prompt the admin once from the > postinst script with a message such as: > "Warning: from installed with suid bit. If > this is unacceptable at your site, use dpkg-statoverride to clear this > bit." ? Dear ghods no. For all the reasons previously mentioned, and more. - Matt
Re: A question on setting setuid bit
On Wed, Jul 05, 2006 at 09:36:37AM +0100, Steve Kemp wrote: > On Tue, Jul 04, 2006 at 08:37:52PM -0400, LEE, Yui-wah (Clement) wrote: > > > I am building a package in which one of the binary has > > to have the setuid and setgid bits set. I wonder which > > one of the following two is the more appropriate method > > to use? > > It looks like you've got the answer to this already, but > it is worth considering whether the bit needs to be set > by default. > > Perhaps a debconf question like man-db, or cdrecord, could > allow the user to disable/enable this. Ugh, please don't. Seriously, as a regular user of those packages, I have no idea whether it's *really* a good idea for those to be setuid or not -- I vaguely know the risk/benefit from general knowledge, but assessing the risk intelligently? No way. I'd bet that 99% of installations have whatever the maintainer recommended setting (either recommended by default or perhaps the wording of the question). My personal preference would be for the maintainer to just take a stand, set it or not, and let people who actually know what's going on to use dpkg-statoverride to fix the problem to their satisfaction. (This actually also applies to man-db and cdrecord, as it happens, but there's a lot of inertia to overcome there). > I'd want to be extremely sure that the package had no > buggy code before installing it setuid/setgid. If you'd > like somebody to check over the code for you, or as a > second pair of eyes, then please consider asking the auditing > people: > > http://shellcode.org/mailman/listinfo/debian-audit This is good advice. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question on setting setuid bit
On Wed, Jul 05, 2006 at 07:34:02AM +0200, Bartosz Fenski aka fEnIo wrote: > On Tue, Jul 04, 2006 at 08:37:52PM -0400, LEE, Yui-wah (Clement) wrote: > > I am building a package in which one of the binary has > > to have the setuid and setgid bits set. I wonder which > > one of the following two is the more appropriate method > > to use? > > > > 1. Use "install -m 6755 " in the install > >target of the Makefile. > > > >However, I already tried this method and it did not > >work. The "install" program that I am using is part > >of the GNU coreutils. I could not find any specific > >confirmation that the setuid and setgid bits > >(i.e. the first digit "6" in the numeric mode > >"6755") can be used with the install program (the > >document says only that the -m switch works "as in" > >chmod). > > > > 2. Add a "chmod ug+s" command in the postinst script. > > 3. Use dpkg-statoverride in your postinst script. dpkg-statoverride is a tool for the system administrator to specify a different mode or ownership for a file to that which is provided in the package. It is not meant to be used by the package. The correct answer, in this case, is to ensure that the file in the package has the appropriate permissions, and then use the -X option to dh_fixperms to ensure that fixperms doesn't turn the permissions back to the default. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: openwatcom -- C/C++ compiler and IDE that produce efficient, portable code
On Sun, Jul 02, 2006 at 06:50:07PM -0500, Ron Johnson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Adam Borowski wrote: > > On Sun, Jul 02, 2006 at 06:17:20PM -0400, Jason Spiro wrote: > [snip] > > the moment you use openwatcom to compile any work-related piece > > of software (thus not "Personal Use"), you need to make the > > source of openwatcom publicly available for 12 months. > > Why is "I must make available the compiler's source code" > problematic? It follows in the spirit of that clause of the GPL > which says that if you distribute binaries, you must make the source > code available. By extending it to the compiler, you ensure that > the possibly-modified cc will be available to recreate the executable. It's not limited to modified versions, it's not limited to distribution (only use), it's public distribution (not just "to those you made the binary available to"), and it's for a period of time far exceeding that of the distribution. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: transitioning towards using BTS versioning for NMUs (and experimental)
On Tue, Jun 20, 2006 at 12:44:40PM +0200, Goswin von Brederlow wrote: > "Steinar H. Gunderson" <[EMAIL PROTECTED]> writes: > > >[Don suggested to use the tags _and_ the versioning information in a > >transitional period; I'm not 100% sure what this buys us, except that I'm > >not sure how well britney would cope without.] > > 4. Run a script over the archive (like the one I made a while ago -- sources > >available for anyone who needs it :-) ) to remove all the instance of > >these two tags, and replace them by versioned closes. > > Does that mean one can't get a list of bugs fixed in NMUs anymore? As > maintainer one might want to read up on those bugs specificaly without > having to parse the changelog for bug numbers. The BTS shows "Fixed in X.X.X-Y" in the bug summary list, I think. It doesn't seem like it'd be hard to add a "fixed-in=X.X.X-Y" parameter to the query string if debbugs doesn't have that already -- that way you could get a *better* report of bugs fixed in the latest NMU. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SQL Ledger and PostgreSQL: ID fault on create database
On Thu, Jun 15, 2006 at 10:12:32PM +0100, Chris Forsey wrote: > Not sure if this is the right list, but unsure where to post as I need > some guys with good debian experience [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], for starters. This list is for development of Debian itself. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Re: RFC: Better portability for package maintainers]
On Sun, May 21, 2006 at 11:30:59PM +0200, Josselin Mouette wrote: > Le samedi 20 mai 2006 à 19:43 -0700, Erast Benson a écrit : > > Nexenta is absolutely rock stable OS (thanks to legendary Solaris > > history) > > Solaris history is indeed legendary, but not for its stability. Well, when you consider what dict(1) has to say about 'legendary': "Of or pertaining to a legend or to legends; consisting of legends" when legends are: "Any wonderful story coming down from the past, but not verifiable by historical record; a myth; a fable" You and Erast may be violently agreeing with each other. > -- > .''`. Josselin Mouette/\./\ > : :' : [EMAIL PROTECTED] > `. `'[EMAIL PROTECTED] > `- Debian GNU/Linux -- The power of freedom
Re: Creation of custom
On Mon, May 15, 2006 at 10:47:48AM +0200, [EMAIL PROTECTED] wrote: > Am 15.05.2006 um 10:32 Uhr haben Sie geschrieben: > > CFEngine is in Debian, but has some real nasty frustrations. Puppet > > isn't in Debian, but Jamie is working hard on the packages and I've got > > some provisional ones built from his sources if you want to try it out. > > Puppet is fairly new on the scene, but is maturing fast, and has much > > less irritations. > > Well, of course I would like to try, that's why I asked ;-) You actually asked about custom packages, and might have rejected my suggestions as not fitting into your desired solution... > So how can I get my (virtual) fingers on that (puppy) packages? Are they > for sarge, otherwiese I will (have to) build some myself. The ones I've got are intended for Ubuntu Breezy (the SOE for the client I'm currently working for), but looking at the dependencies for all of the packages, there's nothing that Sarge wouldn't satisfy. I've put the debs up at http://www.hezmatt.org/~mpalmer/puppet/. Note that there's a new upstream version, but I don't have packages for that yet. > What is the URL for puppy? http://reductivelabs.com/projects/puppet/ - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Creation of custom "configured" packages?
On Mon, May 15, 2006 at 09:49:00AM +0200, [EMAIL PROTECTED] wrote: > in case I am in the wrong list, I beg you pardon, but I asked this > already in debian-user without success. Custom *packages* is probably more on-topic for debian-mentors, but I don't think that custom packages are the right solution. > I would like to build customized, configured packages (for example > additional bash script for the bash package, some default keybindings > for screen, some host in /etc/ssh/known_hosts for ssh ... the list is > endless), because maitainigs multiple systems becomes frustrating > otherwise, if you maintain more than 2 computers (4 in my case). > > What would be the best (cleanest, most debian-like solution) be? I > thought of "meta-packages" with pre-depends to the real packages and > dpkg-divertions for the config files? I don't think you can dpkg-divert conffiles, which makes it a bit tricky to do that anyway. The correct solution to your problem, I think, is a system management application such as CFEngine or (my preferred option) Puppet. These systems allow you to specify rules which describe how your system is supposed to look, and then the program does what's needed to make that happen. You can make classes, too, which are generic configuration fragments which you can apply to a group of hosts -- a very powerful feature which allows you to make the common config parts really common. CFEngine is in Debian, but has some real nasty frustrations. Puppet isn't in Debian, but Jamie is working hard on the packages and I've got some provisional ones built from his sources if you want to try it out. Puppet is fairly new on the scene, but is maturing fast, and has much less irritations. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: per-architecture Provides field
On Thu, Apr 13, 2006 at 12:13:57AM -0700, Erast Benson wrote: > On Thu, 2006-04-13 at 00:04 +0200, Loïc Minier wrote: > > Why not simply Provide: sunwlxsl all of the > > time, doesn't it provide sunwlxsl on other arches? > > But how? sunwlxsl is something which is only present in > OpenSolaris-based derivatives, such as NexentaOS? Assuming that the virtual package 'sunwlxsl' doesn't have conflicting meanings on different architectures, I see no reason not to provide the virtual package on all architectures. Non-OpenSolaris derived architectures may ignore the virtual package entirely, but that isn't harming anything. I'm a bit confused about why you need to Provide a crazy sun package name, though -- are you intending for the Debian packaging system to integrate with the "native" packaging system somehow, and the two to cooperate? - Matt
Re: Proper way of closing *old* bugs
On Sat, Apr 08, 2006 at 05:55:05PM -0500, Adam Majer wrote: > Cyril Bouthors wrote: > > On 3 Apr 2006, Adam Majer wrote: > > > > > >> But the correct method of closing bugs is to send a message to > >> [EMAIL PROTECTED] with the explanation of the fix and not in > >> the changelog. Well, at least not in the way you seem to intend. The > >> bugs closed in changelogs are suppose to be bugs closed due to the > >> changes from the previous version to the current version. If you only > >> mean to do, > >> > >> * Close bugs that were fixed VERY long time ago (closes: > >> #123,#234,#345,#456,#567,#678,#789,) > >> > >> then I don't think that is appropriate use of the changelog. > >> > > > > Closing bugs through the changelog is an officially supported method > > and most DDs close bugs that way. Submitters receive a detailed > > notification by email as soon as the package is uploaded. > > > > I have no special mean to close bugs without informing the submitters > > with a clear and detailed explanation as I always did with all my > > packages. I'm stunned that anyone still thinks that closing unrelated bugs in a changelog is a good idea. [EMAIL PROTECTED] sends the detailed close message to the submitter, and it doesn't make it look like the problem was fixed in that version (which, of course, it wasn't). > My question is, is it now appropriate to use the changelog as a crutch > to close bugs that have nothing to do with the upload? I was always > under impression that *old* bugs should be closed by sending an email to > [EMAIL PROTECTED] saying that you are closing it because it was > fixed some time ago, etc.. etc.. Absolutely. There's some debate over whether closing upstream bugs in the changelog is OK, like so: * New upstream version. (Closes: #N) - The bar is now frobbed correctly. (Closes: #X) - No longer trip over our shoelaces. (Closes: #Y) * Random package installation failures stopped. (Closes: #) Some people think that it shouldn't be done ever, since it's not a change that the maintainer explicitly made, but others think that it's OK when done like that shown above, as it preserves all of the useful information. But I can't think of *any* discussion which has ended with people claiming that closing random bugs is OK in an upload. How would you even describe it in the changelog? * The bug has magically disappeared. (Closes: #NNN) Uhhh... I doubt it. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd and experimental
On Wed, Mar 01, 2006 at 02:46:02AM +0100, Gabor Gombas wrote: > On Wed, Mar 01, 2006 at 01:04:17AM +, Brian M. Carlson wrote: > > However, the code of conduct seems to > > point out that one should not Cc someone unless they specifically ask > > for it (a guideline that you neglected to follow, after I pointed this > > out to Mr. Bushnell). > > Frankly, I never check the recipient list when I press "g" in mutt. I > assume that if you do not want to be CC'ed, then you can set up > Reply-To: to express that. How? I can't use the same header for two purposes; if I want to specify that private replies should go to one address, but I want list replies to go to the list (and only the list), how do I go about that using only Reply-To? - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Mon, Jan 30, 2006 at 11:03:03AM +0100, Josselin Mouette wrote: > Le lundi 30 janvier 2006 à 10:20 +1100, Matthew Palmer a écrit : > > On Sun, Jan 29, 2006 at 02:58:05PM +0100, Josselin Mouette wrote: > > > There have already been - admittedly sporadic - proposals to rewrite > > > some key parts of the system, like the init scripts or adduser, in > > > python. However, if the proponent knows from the beginning the > > > implementation wouldn't be accepted because of the language it is > > > written in, you can't expect him to start working on it. > > > > What's this "wouldn't be accepted" nonsense? Are you seriously suggesting > > that, if someone rewrote adduser in Python, that it would be rejected by the > > ftpmasters *because* it was written in Python? > > Yes, this is because all dependencies of a package must be of equal or > higher priority. Having adduser depending on python would imply to > increase the priority of python. Call it 'adduser-python' then. Show that it's better (oh, for an objective criterion) and it'll get switched. Not exactly rocket science. You're going to have to do that anyway, even *if* python is essential, because nobody, even the most die-hard Pythonista, would be dumb enough to call for tossing out the current adduser implementation for a Python one until the new one had undergone some fairly massive testing in production. > > > Putting python in the set of required packages today would simply be a > > > waste of resources. But accepting the idea of putting it in *if* a good > > > enough application shows up is the necessary step to have the > > > applications show up. Some people here are refusing it by principle. > > > > They're refusing it on the principle of "the cost/benefit ratio sucks". Not > > a bad principle, as things go. > > The arguments I've heard most are not about that ratio. You made the argument. - Matt
Re: when and why did python(-minimal) become essential?
On Sun, Jan 29, 2006 at 04:17:13AM +0100, Josselin Mouette wrote: > Le samedi 28 janvier 2006 à 17:01 -0600, Peter Samuelson a écrit : > > [Josselin Mouette] > > > Because python and ruby have similar features > > > > Same with perl and python. > > Great. I guess you're going to second the upcoming GR that will state > that Pi=3 ? Hey, you were the one who started the mud-slinging. Ruby and Python are miles apart as languages (and thank $DEITY for that). - Matt
Re: when and why did python(-minimal) become essential?
On Sun, Jan 29, 2006 at 02:58:05PM +0100, Josselin Mouette wrote: > There have already been - admittedly sporadic - proposals to rewrite > some key parts of the system, like the init scripts or adduser, in > python. However, if the proponent knows from the beginning the > implementation wouldn't be accepted because of the language it is > written in, you can't expect him to start working on it. What's this "wouldn't be accepted" nonsense? Are you seriously suggesting that, if someone rewrote adduser in Python, that it would be rejected by the ftpmasters *because* it was written in Python? > Putting python in the set of required packages today would simply be a > waste of resources. But accepting the idea of putting it in *if* a good > enough application shows up is the necessary step to have the > applications show up. Some people here are refusing it by principle. They're refusing it on the principle of "the cost/benefit ratio sucks". Not a bad principle, as things go. Spend some time enhancing the benefit side of the equation, and less time screaming that people are meanies, and your language-of-choice-for-today might just have a hope of making it in. - Matt Bannerwaver for "Ruby in Essential" because it'd be cool. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On Mon, Jan 23, 2006 at 05:33:33PM -0800, Paul Johnson wrote: > On Sunday 22 January 2006 03:16, David Weinehall wrote: > > > Since all Ubuntu packages are recompiled against a different set of > > libraries, the bug might not even affect the Debian package, even though > > they share the same source. Hence having Ubuntu developers triage the > > bugs to rule out such issues before they are forwarded to Debian's BTS > > is always a good thing; thus the maintainer field should be changed > > for *binary packages*. The source is the same, so the field should NOT > > be changed for *source packages*. > > Given Ubuntu hopelessly complicates everything, pretends there is cooperation > where there is none, and merely duplicates the effort of the debian-desktop > project, and contributes nothing to the community or society, what's stopping > us from officially discouraging Ubuntu's existence? I think that way lies madness, for so many reasons. It's not exactly encouraging of the principles of Free Software, nor is it particularly practical. Would we hold a GR to say "Ubuntu is the Antichrist"? Some sort of technical thing to micq our packages against Ubuntu? I don't really see the value in it, either -- what's it going to get us? I seriously doubt that, even if we *wanted* a PR war, that we could win it. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On Fri, Jan 20, 2006 at 01:40:11PM -0800, Matt Zimmerman wrote: > On Sat, Jan 21, 2006 at 08:31:44AM +1100, Matthew Palmer wrote: > > All you'll get is the loud minority having a whinge then, no matter what the > > outcome. > > It will certainly beat the hell out of continuing this thread. It will just be this thread all over again. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On Fri, Jan 20, 2006 at 12:41:49PM -0800, Matt Zimmerman wrote: > On Sat, Jan 21, 2006 at 07:13:31AM +1100, Matthew Palmer wrote: > > On Fri, Jan 20, 2006 at 09:20:33AM -0800, Matt Zimmerman wrote: > > > By way of example, the Debian maintainer is equipped to answer questions > > > like "why is the package set up this way?", "what are your plans for it?", > > > etc., while the MOTU team are not. > > > > What the? By that logic, the upstream author should be in the Maint: field, > > since they're in the *best* position to answer those questions for the > > majority content of the package. At any rate, in most cases the answer, > > from the Debian maintainer, to the first question would either be "Dunno, > > can't remember" or "the previous maintainer was a known crack addict", while > > the answer to the second would be " make sure it doesn't break, I > > suppose" -- none of whick are particularly more interesting answers than > > what you'd get from the MOTUs. > > If I were to accept your declaration that the Debian maintainer is equally > ill-equipped to discuss the package, then it follows that they are an > equally valid value for the Maintainer field. It only follows if your definition of maintainer is "can answer all development questions". If you're going to go that way, you may as well put the man in the moon as the maintainer of your packages, as he's got as much chance, in the general case, of answering those questions. Thus, I'd say that your definition of "Maintainer" is bollocks. > There really isn't any point in arguing our individual views, though. What > I'm interested in is what will satisfy a majority of Debian developers, and > the proposed poll seems like the closest we'll get to that. All you'll get is the loud minority having a whinge then, no matter what the outcome. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On Fri, Jan 20, 2006 at 09:20:33AM -0800, Matt Zimmerman wrote: > On Fri, Jan 20, 2006 at 07:08:38PM +1100, Matthew Palmer wrote: > > I keep hearing this, but I really don't believe it. In Debian, "Maintainer" > > means "An individual or group of people primarily responsible for the > > on-going well being of a package". As I understand it, in Ubuntu, the MOTUs > > have responsibility for all of the packages in Universe. > > In practice, it doesn't work out to mean the same thing, however. Most of > the packages in universe are maintained only by the Debian maintainer, and > propagated unmodified into Ubuntu. It is only when there is a specific > motive to change the package in Ubuntu that anyone on that team will touch > it. But if a problem in a package in Ubuntu universe does appear, whose responsibility[1][2] is it to fix it? Whatever the answer to that question, also answers the question "what should go in the Maintainer: field?". > By way of example, the Debian maintainer is equipped to answer questions > like "why is the package set up this way?", "what are your plans for it?", > etc., while the MOTU team are not. What the? By that logic, the upstream author should be in the Maint: field, since they're in the *best* position to answer those questions for the majority content of the package. At any rate, in most cases the answer, from the Debian maintainer, to the first question would either be "Dunno, can't remember" or "the previous maintainer was a known crack addict", while the answer to the second would be " make sure it doesn't break, I suppose" -- none of whick are particularly more interesting answers than what you'd get from the MOTUs. - Matt [1] Subject to the usual "we're all volunteers, yada yada" proviso. [2] Remember also that with responsibility should come authority, so the Debian maintainer is usually an immediate non-candidate in Ubuntu.
Re: klik, loop mounts, and insecurity [was: statement from one of the klik project members]
On Fri, Jan 20, 2006 at 03:59:23PM +, Kurt Pfeifle wrote: > Wouter Verhelst wrote on debian-devel@lists.debian.org: > > [Re-adding Cc to Kurt, as he's mentioned he isn't subscribed] > > > > On Fri, Jan 20, 2006 at 01:20:26PM +0800, Cameron Patrick wrote: > > > Kurt Pfeifle wrote: > > > > The klik client installation needs root privileges once, to add 7 lines > > > > like this one to /etc/fstab: > > > > > > > > /tmp/app/1/image /tmp/app/1 cramfs,iso9660 user,noauto,ro,loop,exec 0 > > > > 0 > > > > > > Doesn't this introduce a local root exploit? A user can easily write > > > their own /tmp/app/1/image file which contains, say, a setuid root bash > > > executable. > > > > Yes, that's exactly what I was afraid of, myself. > > Please try "man mount". If your manpage is similar to mine, it will > contain something like: > > snip -- > OPTIONS >user Allow an ordinary user to mount the file system. The name > of the mounting user is written to mtab so that he can un- > mount the file system again. This option implies the op- > tions noexec, nosuid, and nodev (unless overridden by sub- > sequent options, as in the option line user,exec,dev,suid). > snap -- > > Note the part mentioning "nosuid" - and compare it to the fstab line > used by klik. :-) You might want to read your manpage a bit more: nosuid Do not allow set-user-identifier or set-group-identifier bits to take effect. (This seems safe, but is in fact rather unsafe if you have suidperl(1) installed.) Particularly note the parenthetical sentence. On another point, I believe you said earlier that the admin is required to add 7 of those lines to fstab before klik could be used. Does that mean that no more than 7 applications can be installed, or that no more than 7 users can use klik on the one machine? Either way, it seems quite artificially limiting. If I have an 8th user who wants to use klik, what do I do? - Matt
Re: For those who care about their packages in Ubuntu
On Fri, Jan 20, 2006 at 12:10:54AM +0100, JanC wrote: > On 1/17/06, Wouter Verhelst <[EMAIL PROTECTED]> wrote: > > How about renaming Maintainer to Debian-Maintainer in Ubuntu's binary > > packages, and having a specific Ubuntu-Maintainer? > > This should probably happen in a way that all (or most) Debian-derived > distro's agree on then. > > And one more problem: Ubuntu doesn't have the same "maintainer" > concept as Debian has... I keep hearing this, but I really don't believe it. In Debian, "Maintainer" means "An individual or group of people primarily responsible for the on-going well being of a package". As I understand it, in Ubuntu, the MOTUs have responsibility for all of the packages in Universe. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [ad-hominem construct deleted]
On Wed, Jan 18, 2006 at 12:30:22PM +0200, Riku Voipio wrote:
> On Wednesday 18 January 2006 11:01, Gerfried Fuchs wrote:
> > So you are saying it's the Debian Developer's job to pull changes from
> > ubuntu back? If that is an official statement, then that would be useful
> > for a d-d-a mail so we are aware of it.
>
> This is what also wonder about ubuntu-haters. Somehow it is OK for
> Debian to have different opinions and preferences ("Tell me about changes"
> vs "don't spam me" or "You don't Attribute my work" vs "Don't put my
> name there").
>
> But at the same time you require a explict policy from ubuntu and anytime
> a ubuntu developer says something about it is considered a official position
> statetement.. Until we can do a official statement of debian derivate
> policy ourselfs, we can hardly require it from them..
We don't have to require an official position statement from Ubuntu -- it's
already been published. The other difference is that Ubuntu has a Dictator
For Life, who runs the show, while Debian is just a loose collection of
people who elect someone annually to keep them out of mischief.
Also, other Debian derivatives and Gentoo/Fedora/OpenSUSE don't make a habit
of touting their contributions to Debian, and that's been the main complaint
that I've seen in this thread -- that Ubuntu *talks* about contributing back
to Debian, but isn't *seen* to be doing so, on a systematic basis.
> > Do you imply with this message that Ubuntu doesn't care about quality
> > in their upstreams but rather keep their stuff to themselfes?
>
> The same can be claimed about about Debian and our upstreams. Not all
> maintainers submit their patches upstream, and sometimes our lack
> of co-operation have made our upstreams really unhappy (Remember micq?).
The micq debacle wasn't about Debian not sending patches upstream, it was
about Debian not being able to keep up-to-date with the intentional
breakages of the ICQ protocol by Miribilis, and consequently making micq
(and hence, it's author) look bad.
> > And I like to point out that there isn't any correspondence between the
> > ubuntu developers and the debian developers in respect to getting
> > sensible patches they do back into debian, which very much disappoints
> > me, if not does get me a bad opinion on the intentions of ubuntu.
>
> Ubuntu (and other derivates) are using the same freedoms Debian
> is built upon. We would not accept a licence that required us to submit
> our patches upstream (dissident and desert island tests), so howcome it
> is OK to require such behaviour from our downstreams?
We're not requiring any particular behaviour from our downstreams beyond
licence compliance and "keeping their promises".
- Matt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On Mon, Jan 16, 2006 at 08:51:12AM +0100, Raphael Hertzog wrote: > Hello Joey, > > On Sun, 15 Jan 2006, Joey Hess wrote: > > Leaving ubuntu out of this, what puzzles me about your message, Raphael, > > is this: > > > > Raphael Hertzog wrote: > > > If you have some uploads pending, and would like to see those packages > > > included [...] > > > > > If for whatever reason you don't want to upload the new package to Debian > > > directly [...] > > > > This seems to assume that > > > > a) There might be a lot of Debian developers who have some upload ready > >to go but are sitting on them for some reason. > > Not really... it happens quite often that I plan on working on a new > upstream version (or whatever) but for various reasons, I do not prioritze > it much because I know I will do it in time for etch... however I may be > interested to have that better version in Ubuntu as well instead of the > actual version (which may be too buggy in my opinion). If I don't know > about the Ubuntu freeze, I may miss the opportunity to work on it in time... Personally, I think that Debian maintainers need to be a bit more proactive about filing faux-serious "keep this out of testing" bugs (and requesting removals from testing in the meantime), and Ubuntu needs to track this activity to work out what stuff the Debian maintainer thinks is going to suck if it ends up in the next Ubuntu release. Until this utopia occurs, however, I've taken the liberty of requesting removal of non-release-worthy packages for the next Ubuntu release. E-mail ubuntu-motu@lists.ubuntu.com (it's probably subscriber-only, though, which makes it a bad choice for communications with the MOTUs by outsiders, unfortunately) and make the request. To be fair to the MOTUs, it's probably best to do this fairly quickly once you realise that the current version is bong and you can't fix it quickly, as (according to a senior Ubuntu person) MOTUs are supposed to be fixing major bugs in Debian packages anyway, so if they know up-front that something is broken, and they're doing their job, they can fix it or remove it, at their choice. Asking for removal now doesn't give the MOTUs much time to fix. It's a hell of a lot better than having useless crap with your name on it in a stable release of something as high profile as Ubuntu, though. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Sun, Jan 15, 2006 at 08:21:20AM -0500, Theodore Ts'o wrote: > And on _top_ of that, we have all sorts of gratuitous autotools > changes. Let's not forget the random conversion of build systems -- dpatch seems to be a favourite to rewrite perfectly functioning build systems into. > This is roughly equivalent to submitting a patch to LKML with all > sorts of gratuitous whitespace cleanups mixed in with real, > substantive changes in a garguantuan monolithic patch, _and_ including > all of the changes between 2.6.14 and 2.6.15 in the patch that you > submit expecting the kernel developers to review it. Go ahead, try > it. I dare you. :-) And please let me know if you try this, so I can watch from a safe distance. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Fri, Jan 13, 2006 at 01:14:18PM -0800, Matt Zimmerman wrote: > Some things that it does say: [...] > - Ubuntu submits fixes for Debian bugs to the Debian BTS including a patch > URL If that said "sometimes" or "some people within Ubuntu", it would be correct. Not every relevant patch ends up in the BTS. I'd also echo David Nusinow's comments that the wording of some of the statements implies a far closer cooperation than is apparent from watching what actually happens. - Matt signature.asc Description: Digital signature
Re: Dissection of an Ubuntu PR message
On Fri, Jan 13, 2006 at 03:03:14PM -0200, Gustavo Franco wrote: > On 1/13/06, Matthew Garrett <[EMAIL PROTECTED]> wrote: > > David Nusinow <[EMAIL PROTECTED]> wrote: > > > > > Please stop trying to twist my words around. Canonical didn't contribute > > > back. An individual who happened to work for Canonical did. If someone > > > employed by the US government contributes to Debian of his own volition do > > > we say that the US government gives back to Debian? Do we say that your > > > employer gives back to Debian? > > > > If it's an authorised use of company time, sure. Whether or not it is in > > this case, I don't know. > > > > Exactly my point Matthew, and calm down David, i wrote: "e.g.: David > said that Daniel helped him, but if he did that in his workhours it's > under Canonical bless.". Do you see ? I just pointed out that there's > a possibility that he was helping you in his workhours, You've never done anything at work that wasn't officially sanctioned by your boss? - Matt signature.asc Description: Digital signature
Re: Need for launchpad
On Sun, Jan 08, 2006 at 11:44:57AM +0100, Stephan Hermann wrote: > On Sunday 08 January 2006 10:39, Andrew Suffield wrote: > > On Sun, Jan 08, 2006 at 07:49:33PM +1100, Matthew Palmer wrote: > > > On Sun, Jan 08, 2006 at 09:02:09AM +0100, Stephan Hermann wrote: > > > > On Sunday 08 January 2006 07:27, Andrew Suffield wrote: > > > > > On Fri, Jan 06, 2006 at 03:19:42PM -0500, Frans Jessop wrote: > > > > > > Ubuntu's launchpad is amazing. Do you think it would be helpful if > > > > > > all DD's worked through it on their projects? Wouldn't that keep > > > > > > things more organized and efficient? Or perhaps Debian could build > > > > > > its own version of launchpad which is better. Again, I think it > > > > > > would do a good job keeping everything organized an efficient. > > > > > > > > > > The day when working on Debian requires the use of a web interface > > > > > will be the day that I hunt down and painfully kill the person > > > > > responsible for doing it. > > > > > > > > Luckily that the bts of Launchpad has a mailinterface..which is quite > > > > nice. So some other parts will have mailinterfaces as well, and some > > > > other goodies where someone can attach some nice cli tools. > > > > > > Which nobody except the Blessed Few (being those who have signed the NDA > > > allowing them access to the Launchpad code) can modify or enhance. > > > > And even then have uncertain chances of getting it deployed into a > > place where it's useful, and goodness knows how practical it would be > > to do this anyway - the backend limitations could be anything. > > Sure, but this applies to any software, actually the best example is the > kernel. I can deploy anything I like to the kernel I use. I can't (on *so* many levels) deploy anything at all to the Launchpad I'm supposed to use. > > > > > Removing the ability to manage things from the shell would not be > > > > > more organised and efficient unless you're a complete fricking moron > > > > > who can't operate a unix host. Which appears to be the target > > > > > audience of launchpad. > > > > > > > > Well, I'm happy to see, that a lot of people are not thinking like you. > > > > They see launchpad as a collaborative worktool. > > > > > > Your comment doesn't follow from what Andrew said. > > > > Indeed, it appears to demonstrate a complete absence of having > > understood the paragraph it is in reply to, or perhaps even having > > read it. > > I commented this in my reply to Matthew. No, you didn't. > As I said, it's a matter of the working behaviour. I'm almost faster with the > keyboard even on UIs then with the mouse or touchpad, but it doesn't mean, > that others are fast as well. So you're willing to hamstring yourself so that others less capable can do a bit? How noble. And stupid. > People who can use the CLI are blessed, but leaving the others behind? No, > elite thinking was yesterday, today is, how we can gather more people around > a project, to work on. the more people we can gather, the faster we will > accomplish goals. Let me emphasise Manoj's citation of the Mythical Man Month. He basically calls bullshit on your entire argument, and with such style. > Therefore, a lot of people never learned the advantages of cli, and more > people don't want to learn them. Why? I don't know, and it doesn't matter. > But, even those people we have to reach with an easy to use interface, and if > this means: webapplications, so be it. It doesn't mean, that I or you have to > use it, But don't you have to use it if you want to get the collaboration benefits with the teeming masses? - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Sun, Jan 08, 2006 at 04:47:56PM +, Martin Meredith wrote: > Manoj Srivastava wrote: > > On Fri, 06 Jan 2006 15:19:42 -0500, Frans Jessop > > <[EMAIL PROTECTED]> said: > >>Ubuntu's launchpad is amazing. Do you think it would be helpful if > >>all DD's worked through it on their projects? > > > > Sure, as long as they change lauchpad to meet my workflow > > requirements. This would mean letting me have a local repo, signed > > remote repos, arch, email only interfaces, and not getting into my > > way. If they make changes to meet these requirements, I'll have > > absolutely no problem throwing away tools I have worked on honing for > > a decade or so and switching to launchpad. Oh, and release launchpad > > under a free license, of course, so I don't make Debian development > > rely on a non-free toolset, of course. > > Other than the email interface - they have most of that planned in hct :D > > https://wiki.launchpad.canonical.com/HCT Planned. It's still vapour as far as I'm concerned. Which is a pity, because it looks really nice, in principle. And, in the meantime, everybody else is building their own half-assed variants, which they'll be loathe to drop when HCT finally appears on the scene. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Sun, Jan 08, 2006 at 11:25:28AM +0100, Stephan Hermann wrote: > On Sunday 08 January 2006 09:49, Matthew Palmer wrote: > > On Sun, Jan 08, 2006 at 09:02:09AM +0100, Stephan Hermann wrote: > > > On Sunday 08 January 2006 07:27, Andrew Suffield wrote: > > > > On Fri, Jan 06, 2006 at 03:19:42PM -0500, Frans Jessop wrote: > > > > > Ubuntu's launchpad is amazing. Do you think it would be helpful if > > > > > all DD's worked through it on their projects? Wouldn't that keep > > > > > things more organized and efficient? Or perhaps Debian could build > > > > > its own version of launchpad which is better. Again, I think it > > > > > would do a good job keeping everything organized an efficient. > > > > > > > > The day when working on Debian requires the use of a web interface > > > > will be the day that I hunt down and painfully kill the person > > > > responsible for doing it. > > > > > > Luckily that the bts of Launchpad has a mailinterface..which is quite > > > nice. So some other parts will have mailinterfaces as well, and some > > > other goodies where someone can attach some nice cli tools. > > > > Which nobody except the Blessed Few (being those who have signed the NDA > > allowing them access to the Launchpad code) can modify or enhance. > > Everything what is on https://wiki.launchpad.canonical.com/ is free to use. VS2005 Express is free to use, too. What's your point? > Read and think again. Or use another example: Amazons code is not free to > see, but you can use the interfaces described in their developers documents, > same applies to google api. > So where is the difference? Everybody is playing with public interfaces, > where the sourcecode is non-free. But nobody complains. Without google > e.g., as a free, but sourcecode-non-free service, most of the people here, > even the cli guys are lost. I don't build my entire development infrastructure around Google. > Oh, I never signed an NDA, so I've never seen the code, actually I'm not > interested in the code, because if I have a problem with the result, I can > file bugs against this products, or bug the maintainers of the code in their > present irc channel :) And, in my experience, unless your needs happen to coincide with what the Launchpad want to do, you'll be ignored. Which is fine -- scratching one's own itch and all -- but not exactly productive for Debian's needs. Or, for that matter, Ubuntu's own MOTU team. I've noticed several things that the MOTUs have stated a desire for that isn't in Launchpad. > > > > Removing the ability to manage things from the shell would not be more > > > > organised and efficient unless you're a complete fricking moron who > > > > can't operate a unix host. Which appears to be the target audience of > > > > launchpad. > > > > > > Well, I'm happy to see, that a lot of people are not thinking like you. > > > They see launchpad as a collaborative worktool. > > > > Your comment doesn't follow from what Andrew said. > > Well, if I see that e.g. find and xargs are more efficient for my local file > search then the beagle desktop search or whatever, it's my choice. Again, you're not addressing what Andrew said. > But regarding, that vi, emacs or kbabel are not network aware for sharing the > workload with the community, I think rosetta as translation webapplication > is, in this moment, the best tool to work with. The output of Rosetta is > usable for everyone and anyone. So, now, what is more efficient? Hmm, 10 minutes with Emacs (including committing to the public repo) against probably spending that long just waiting for pages to reload in Rosetta. You might get this massive productivity boost if, in fact, you have a bunch of people all working on a set of translations *simultaneously*, but let's be honest here, how often does that *actually* happen? > Well, if I see the difference between 20 people working on one application > and > translating them in less then 2 hours, or I'm sitting in a dark, cold cellar, > alone, only with vi, and translating 30 strings in 2 hours, what is more > worth for OSS or free software? Driving away people who know they are more productive on the command line, so that everyone can group-hug on the web? Priceless. > > > But why should I tell that to a unix-guru, who can't even read the code > > > of conduct of the mailinglist of the distribution he is working for. > > > > People in glass houses, and all that. Last time I got a serve from someon
Re: Need for launchpad
On Sun, Jan 08, 2006 at 04:48:11PM +0100, Stephan Hermann wrote: > On Sunday 08 January 2006 14:32, Hamish Moffatt wrote: > > On Sun, Jan 08, 2006 at 11:25:28AM +0100, Stephan Hermann wrote: > > > Oh, I never signed an NDA, so I've never seen the code, actually I'm not > > > interested in the code, because if I have a problem with the result, I > > > can file bugs against this products, or bug the maintainers of the code > > > in their present irc channel :) > > > > Surely you see this is not good enough for Debian though? > > I think I answered that in one of the last replies. Only because > OpenOffice is crashing more times then MS Office, I shouldn't use > OpenOffice? Or is the better way to provide the developers with my > experiences of using OpenOffice and make it better? I think the best way to help OOo would be to fix the bugs and contribute those back to the project. > Glitches and Bugs is in every software, if not, then we wouldn't have > anything to do :) So, the best way of improving is to use it, and if > someone finds a bug or a glitch or an idea of making the workflow easier > and faster, the best way is to file a bug or kick the developers :) While your powers of persuasion may be super-human, the rest of us find it more productive to fix the damn bug and submit the fix upstream. That way, I get the fix *immediately*, the developers don't have to spend excess time just trying to understand the problem (before they can begin to fix it), and everyone benefits. Less tiring on my kicking leg, too. That's even *before* you start talking about times when disagreement over what, or how, or when, or whatever. Freedom to fork, although one we don't *want* to exercise, is nonetheless a fundamental freedom. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packaging problem - no binary
[This is probably more appropriate for the debian-mentors list] On Sun, Jan 08, 2006 at 05:47:32PM +0100, Daniel Knabl wrote: > |dh_gencontrol > |dpkg-gencontrol -ldebian/changelog -isp > |-Tdebian/vexim.substvars -Pdebian/vexim dpkg-gencontrol: error: control > |file must have at least one binary package part dh_gencontrol: command > |returned error code 65280 make: *** [binary-arch] Fehler 1 > > maybe this happens, because the application exists of only php files and > docu? Until now i was not able to find a solution for packaging this > application. While I can understand why the tools may not want to make packages containing PHP files, I'm fairly sure there's any code in them to enforce that. The term "binary package" in Debian parlance means, simply, "a package you install on your system", whether or not it actually contains any binaries. What you're seeing there is a lack of a stanza in your debian/control file describing any of these binary packages -- effectively, you haven't defined any output for your packaging scripts, and the tools are getting confused. I'd suggest using dh_make or similar to produce an example debian/ directory, or looking over an existing package with similar contents to see how they do it. My package 'irm' is PHP-based, and I don't recall too many egregious warts in it. Also you might be well-served by checking over some of the resources listed in the FAQ for the debian-mentors list: http://people.debian.org/~mpalmer/debian-mentors_FAQ.html As for finding people to review your package, you *definitely* want to ask in d-mentors. - Matt signature.asc Description: Digital signature
Re: Need for launchpad
On Sun, Jan 08, 2006 at 09:02:09AM +0100, Stephan Hermann wrote: > On Sunday 08 January 2006 07:27, Andrew Suffield wrote: > > On Fri, Jan 06, 2006 at 03:19:42PM -0500, Frans Jessop wrote: > > > Ubuntu's launchpad is amazing. Do you think it would be helpful if all > > > DD's worked through it on their projects? Wouldn't that keep things more > > > organized and efficient? Or perhaps Debian could build its own version > > > of launchpad which is better. Again, I think it would do a good job > > > keeping everything organized an efficient. > > > > The day when working on Debian requires the use of a web interface > > will be the day that I hunt down and painfully kill the person > > responsible for doing it. > > Luckily that the bts of Launchpad has a mailinterface..which is quite nice. > So some other parts will have mailinterfaces as well, and some other goodies > where someone can attach some nice cli tools. Which nobody except the Blessed Few (being those who have signed the NDA allowing them access to the Launchpad code) can modify or enhance. > > Removing the ability to manage things from the shell would not be more > > organised and efficient unless you're a complete fricking moron who > > can't operate a unix host. Which appears to be the target audience of > > launchpad. > > Well, I'm happy to see, that a lot of people are not thinking like you. They > see launchpad as a collaborative worktool. Your comment doesn't follow from what Andrew said. > But why should I tell that to a unix-guru, who can't even read the code of > conduct of the mailinglist of the distribution he is working for. People in glass houses, and all that. Last time I got a serve from someone on an Ubuntu channel, I raised the issue of the Code of Conduct and got told "so what?". > Finally, are you not able to use lynx? I know your smarter than that. Pressing the down-arrow 50 times to reach an action button takes a lot longer than typing a quick command to invoke that same action, and we both know it. Please don't throw bogus solutions around like that, it only encourages him. > But give them a choice, because linux/unix is choice. *cough*NDA*cough*. - Matt
Re: Bug#344081: ITP: xen-debiantools -- Tools to manage debian XEN virtual servers
On Mon, Dec 19, 2005 at 11:54:26PM +0200, Radu Spineanu wrote: > * Package name: xen-debiantools > Version : 0.2 > Upstream Author : Steve Kemp <[EMAIL PROTECTED]> Considering the upstream author, have you discussed your plans to upload this with Steve? - Matt signature.asc Description: Digital signature
Re: xmcd
On Sat, Dec 17, 2005 at 08:37:28PM +0100, Elimar Riesebieter wrote: > does one know why xmcd isn't upgraded since 31 of May in 2003? The > package is neither orphaned nor up for adoption, which I would do > then. Have you asked the maintainer, Adrian Bridgett? He's around (last made an upload less than a month ago, for tkdiff), so I don't see why he wouldn't be able to give you a reasonable answer to your question. If he's non-responsive, then that's a whole other kettle of fish, but we should cross that bridge when (and if) we come to it. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Automatic closing of bugs
On Fri, Dec 02, 2005 at 02:22:41PM +0100, Simon Richter wrote: > Matthew Palmer wrote: > > >Your mission, should you choose to accept it, is dig through the Perl code > >in merkel:/org/bugs.debian.org/scripts and work out how to add this > >functionality. > > You can use "package foo" as a command to control@ to tell it ignore > everything that does not affect bugs against foo. I am unsure whether > comma notation is allowed (so katie could generate "package bar,wnpp" at > the beginning of bug closing emails). Except that katie doesn't send to control@, it sends to nnn-close@ (indicated in the header of the bug-closing messages in the BTS). I'm fairly sure that the BTS doesn't read commands off the top of messages sent to nnn-done@ (that could cause some killer confusion) but it does parse a pseudo-header (to get the Version: information to drive the version tracking feature). - Matt signature.asc Description: Digital signature
Re: Automatic closing of bugs
On Thu, Dec 01, 2005 at 05:45:53PM -0500, Roberto C. Sanchez wrote: > I just had a bug that I opened (#339832) closed by a changelog entry in > a new debconf upload. This is apparently a typo, as the changelog entry > claims that the bug it was closing was related to a Swedish translation > update. > > My bug was a wishlist bug against gmessage asking for it to become an > alternative to xmessage. > > Is there a way to not allow changelog entries to automatically close > bugs assigned to other packages? This seems like it might require > modifying some infrastructure, but I am not sure what are the affected > components or what I can do to help. Aaah, changelog typos. Brings back memories or trampling all over people's bugs with a quick slip of the finger... If you have a look at the message sent to 339832-close@, the close message does actually state the source package which closes the bug, so I think the fix is to make debbugs recognise Source: pseudo-headers in messages sent to -close@ and only close the bug if the values match. I could have sworn something like that was already done, but it fairly obviously isn't (at least not for Source: pseudo-headers). Your mission, should you choose to accept it, is dig through the Perl code in merkel:/org/bugs.debian.org/scripts and work out how to add this functionality. - Matt signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Fri, Nov 25, 2005 at 03:22:37PM +0100, Goswin von Brederlow wrote: > A signature in the deb by a random developer is as trustworthy as the > changes file and you already trust that. So we are going from snakeoil > to snakoil. No harm done. It's not the same, actually. A signature in a .deb needs to be made by a key which is still trustworthy at the time of verification, which could be quite some time in the future. The key which makes a .changes signature, in contrast, only *needs* to be valid at the time the upload is made -- if it is later compromised, it's not important, because by that time the archive signing key hsa taken over the role of integrity verification. Of course, using the signature on the .changes to verify the .debs independent from the archive at some later date is a nice side-benefit, but one which suffers from the same key-lifetime issues as in-deb signatures, and since the .changes from autobuilt uploads aren't publically available (apparently d-d-$arch-changes isn't archived, from info previously posted in this thread) that method of package authentication isn't going to be 100% reliable anyway. - Matt signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 11:38:45AM -, Adam D. Barratt wrote: > On Thursday, November 24, 2005 11:17 AM, Wouter Verhelst <[EMAIL PROTECTED]> > wrote: > > > On Thu, Nov 24, 2005 at 02:11:45PM +1100, Matthew Palmer wrote: > [...] > >> On that score, the description for d-d-c says that it includes > >> buildd logs, > > > > Then that description is wrong. It never did include buildd logs, and > > AFAIK, there are no plans to that effect, either. > > It doesn't say that. > > It says: > > "Notices about uploaded packages for the unstable distribution, from > developers, buildds and katie, the archive sentinel." > > i.e. the only e-mails from buildds involved are "notices about uploaded > packages", not logs. Sorry, that was a massive typo on my part. I thought "buildd output", and wrote "buildd logs" when I meant "buildd .changes files". My question, as amended, though, still holds -- are the .changes associated with the upload of autobuilt packages supposed to go to d-d-c, and if so, are they there and I'm just not seeing them in the list archive? - Matt signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 03:48:15PM +1000, Anthony Towns wrote: > On Thu, Nov 24, 2005 at 02:31:22PM +1100, Matthew Palmer wrote: > > I think the final judgment in this issue is going to come down to personal > > taste and needs more than anything else. > > That's fine for personal repositories, it's not sufficient for Debian's > archive. Well, I think that personal taste is sufficient for Debian's archive, and it seems obvious that Those In The Know have decided that they prefer one taste over another. > > > > At the very least, though, I can't find a hole which makes binary > > > > package > > > > signatures, done properly, any less secure than per-archive signing. > > > That's easy: you trust the Packages file to be correct when using apt, > > > and it's not verified at all by per-package signatures. > > That's a good point. However, what damage can be done with a bodgy Packages > > file, if only well-signed .debs are actually accepted for installation on > > the system? > > Add a "Depends: some-random-package" that you know has a security hole > to dpkg's entry in the Packages and it'll be automatically installed by > apt. You're a lot more devious than I am, AJ, as I'd never considered these possibilities. > > > Hrm, I see queue/done (which contains .changes files going back to the > > > dark ages) isn't even being mirrored to merkel properly at the moment. > > > That's not so constructive. > > Is there a publically accessable form of queue/done somewhere that people > > can download the .changes files from? > > No, there isn't anything, apparently the mirroring to merkel got disabled > due to the inode usage / rsync time. There's some 700k odd changes > files. Ouch. rsync must be *loving* those. - Matt signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 12:30:37PM +1000, Anthony Towns wrote: > On Thu, Nov 24, 2005 at 09:09:21AM +1100, Matthew Palmer wrote: > > 3) I can verify the provenance of a particular package in my own custom > > repos at any time (did that come from Debian? Did someone build it > > internally? What's going on?) I can kinda-sorta do that if I manually sign > > each binary package I download & verify against the Packages->Release chain > > with a special "came from Debian" key, and I can verify the source of the > > source (heh) package via the dsc signature, but having a complete "chain of > > custody" on a binary package seems like a "nice" thing to have. > > Sure; but why do that inside the .deb? You can verify a detached signature > just as easily as an inline one (gpgv sig file // gpgv file), and you > can verify a signature of a hash just as easily as a signature of a file. > If you're worried you might lose the detached, signed information, either > keep it with the data it's authenticating (pool/main/f/foo/foo.origin, > eg), or keep good backups, or both. Then there's the opposite argument about "why not do that inside the .deb?". On the one hand, if I copy a detached-signed .deb around, I need to remember to copy the .origin file around with it. Conversely, if I use in-file sigs, I can no longer rely on the md5sum of the .deb as originally provided to verify original provenance. I think the final judgment in this issue is going to come down to personal taste and needs more than anything else. > > At the very least, though, I can't find a hole which makes binary package > > signatures, done properly, any less secure than per-archive signing. > > That's easy: you trust the Packages file to be correct when using apt, > and it's not verified at all by per-package signatures. That's a good point. However, what damage can be done with a bodgy Packages file, if only well-signed .debs are actually accepted for installation on the system? The only thing that comes to mind is wasting some time and bandwidth on downloading dodgy debs (or their equally-dodgy dependencies), but if the system checks the signatures before installing anything, can anything actually be damaged? > > Is your > > objection to binary-package signing that it is "no better" than archive > > signing, or that it is actively *worse* than per-archive signing (again, if > > both are done "properly", whatever we may define that to mean). > > My objection is that it's *useless* for *Debian*. Debian has too many > sources for packages for key management to be plausible, and keeps > packages unchanged over too long a period for the keys to be guaranteed > secure for the lifetime of a package. Additionally, packages can be > authenticated both via Packages.gz files and .changes files, which > already exist and are usable. Don't the same arguments about key longevity apply to checking the signatures on .changes files, too? > > One scenario, which initially seems compelling, but which I've since > > rejected, is that of "offline signing" of binary packages -- the idea that > > the archive can be authenticated via signatures applied to packages before > > they hit the archive. > > This is what .changes files are for, and it's useful both for recovering > from compromises and in a "cvs blame" sort of sense. Note that they also > give more information than a simple signature on the .deb. > > Hrm, I see queue/done (which contains .changes files going back to the > dark ages) isn't even being mirrored to merkel properly at the moment. > That's not so constructive. Is there a publically accessable form of queue/done somewhere that people can download the .changes files from? That would be quite handy for people to use to verify binary packages (and would be a darn sight easier to use than trolling d-d-c archives). - Matt
Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 11:54:33AM +1000, Anthony Towns wrote: > On Wed, Nov 23, 2005 at 04:37:05PM -0200, Henrique de Moraes Holschuh wrote: > > On Thu, 24 Nov 2005, Anthony Towns wrote: > > > Personally, I think it's cryptographic snake oil, at least in so far > > A signed deb has a seal of procedence and allows one to track the path it > > made through the system, and who changed it. > > That's what the .changes file is for. Only possible if the .changes file is still accessable, and going through the d-d-c archives isn't exactly convenient. On that score, the description for d-d-c says that it includes buildd logs, but a quick scroll through doesn't appear to find any. Are they sent somewhere else now, or am I just going blind? Certainly, if we're going to be verifying binary packages from the .changes files, we need to have all of the buildd .changes files available in an archive *somewhere*. - Matt signature.asc Description: Digital signature
Re: dpkg-sig support wanted?
On Thu, Nov 24, 2005 at 02:08:17AM +1000, Anthony Towns wrote: > On Wed, Nov 23, 2005 at 11:33:47AM +0100, Florian Weimer wrote: > > * Marc Brockschmidt: > > > Today (or last night, whatever), the dak installation on ftp-master was > > > changed to not accept packages that include more than 3 parts, which are > > > usually the binary version and the compressed control and data > > > tarballs. This means that signed binary packages are rejected. > > This is a pity. I think dpkg-sig is an important step into the right > > direction: providing more assurances about package integrity to our > > users. > > Personally, I think it's cryptographic snake oil, at least in so far > as it relates to Debian. I remain interested in seeing any realistic > demonstration of how a Debian user could reasonably rely on them for > any practical assurance. Are you, perchance, interpreting "user" in Florian's message a little too strictly? I consider myself a user of Debian, as well as a contributor, and I can see a couple of uses for signed binary packages for my own purposes (as well as uses for Debian itself). Maybe I'm raising a too-long-ago-for-my-recollection flamewar, but I can think of the following scenarios (not all of them strictly-Debian, though). I'd be interested in explanations (or pointers to previous discussions) discrediting them, so I can be properly enlightened. 1) A signature added by the "originator" of a particular binary package (the buildds, typically, within Debian) could provide some identification of the true origin of a binary package. If a buildd were to be deemed to be compromised, all packages signed with that buildd's key could be turfed and rebuilt. (Note that I'm not suggesting using buildd keys as a "this package is OK for the archive" check, see my comments below). 2) A signature from dinstall saying "this package was installed in the Debian archive" would provide a means of automatic "assurance" of the source of a binary package, when I'm putting together custom CDs or package repos. 3) I can verify the provenance of a particular package in my own custom repos at any time (did that come from Debian? Did someone build it internally? What's going on?) I can kinda-sorta do that if I manually sign each binary package I download & verify against the Packages->Release chain with a special "came from Debian" key, and I can verify the source of the source (heh) package via the dsc signature, but having a complete "chain of custody" on a binary package seems like a "nice" thing to have. Maybe that's the snake-oil you speak of, aj -- it gives me the warm fuzzies to be able to look at a long list of signatures and say "hmm, that looks secure" when it shouldn't making me anywhere near as fuzzy. At the very least, though, I can't find a hole which makes binary package signatures, done properly, any less secure than per-archive signing. Is your objection to binary-package signing that it is "no better" than archive signing, or that it is actively *worse* than per-archive signing (again, if both are done "properly", whatever we may define that to mean). One scenario, which initially seems compelling, but which I've since rejected, is that of "offline signing" of binary packages -- the idea that the archive can be authenticated via signatures applied to packages before they hit the archive. The benefit suggested there is that offline signing is more secure than leaving the Release.gpg private key somewhere it can theoretically be stolen and used to sign bogus release files. The problem is that, in general, no automatic signing key is any more secure than any other. In addition, if (for eg) every buildd had it's own automatic key, and that was sufficient for admission to the archive and for checking archive integrity, that you've got less security because there's N keys, spread across a range of machines, any of which can do the job of letting a package into the archive. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Wed, Nov 23, 2005 at 10:29:32AM +1100, Brian May wrote: > I would speculate debsigs got a name change to dpkg-sig. Can somebody > confirm or deny? As Mark said, it's not a name change. The FAQ on the dpkg-sig site (http://dpkg-sig.turmzimmer.net/) has more info. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
On Tue, Nov 22, 2005 at 04:50:02PM +0100, Marc 'HE' Brockschmidt wrote: > As I'm responsible for most of dpkg-sig's code (and planned to do some > more work in the next two months) I'd like to know if anyone cares about > using these binary signatures or if I can invest my time into something > that's a bit more satisfying (== non-Debian stuff). I'm keenly interested in per-package signatures for Debian packages -- I think they're a great idea and it's a pity that they haven't received more interest. I've never seen dpkg-sig mentioned before, only debsigs, so I'm not familiar with the tool itself, but the concept is one that needs a lot more exposure. - Matt signature.asc Description: Digital signature
Re: Request: Source for parts of GNU/Solaris
On Mon, Nov 07, 2005 at 07:35:11PM -0800, Steve Langasek wrote: > On Mon, Nov 07, 2005 at 04:48:52PM -0800, Erast Benson wrote: > > > this URL also does _neither_ offer access to the apt > > > (0.6.40.1-1.1) nor your patched debhelper (4.9.3elatte) as requested in my > > > other mail. > > > I'm personally working on it, and I will not commit those changes until > > they will be tested. Rememer, these all binaries are under development, and > > available for developers only. > > Sorry, but that doesn't mean it's your choice to not distribute the source > which matches the binaries. If you haven't tested it enough to be willing > to release the GPL source, then you shouldn't be releasing binaries either. WhatSteveSaid++. Also, it's even *more* important to release source whenever you're producing binaries for "developer testing". How are developers supposed to help test and debug the program if they can't use the source to identify the problems and fix them? - Matt signature.asc Description: Digital signature
Re: Debian based GNU/Solaris: pilot program
On Thu, Nov 03, 2005 at 01:31:08PM -0800, Erast Benson wrote: > On Thu, 2005-11-03 at 22:19 +0100, Adam Borowski wrote: > > Or, *freedoms*. If a hardware vendor wants to profit from Linux users, > > they need to lift the limitations on the access to knowledge about their > > wares. > > Please wake up. :-) Why? Living in a dream world with you seems far more entertaining. > This will never happen. Nobody sane who spent 50$ millon dollars VC's > capital will open their IP for free. This is fact of life. Bwa. Ha. Ha. > Major shift of Linux users to OpenSolaris-based distributions might > happen pretty soon. Do you have *any* rational basis for making this statement? Even *sun* can't give a compelling reason for a sudden, massive stampede of existing (and new) Linux users to suddenly up-and-switch OS. I can see benefits in the large-system market, but how many people have a 32-way box? I doubt that Solaris supports as much varied hardware as Linux does, despite your claims of vendor support -- what percentage of the drivers for commodity x86 hardware in OpenSolaris were written by vendors? Does OpenSolaris cleanly install onto my laptop and support all of the hardware in it? > The question is: whether Debian community wants to be on train or not > and at which point? I think buffet car of your train may be serving kool-aid. - Matt signature.asc Description: Digital signature
Re: Debian based GNU/Solaris: pilot program
On Thu, Nov 03, 2005 at 11:51:31AM -0800, Erast Benson wrote: > The great thing about CDDL is that it is file based. So, all files which > are licensed under CDDL-terms works exactly as GPL does. i.e. any change > made by anybody (including propriatery distributors) *must* be contributed > back to the community. That's not how the GPL works, but it's an amazingly common misconception. > This makes CDDL much better than BSD and almost as better as GPL for what > it was invented. So, CDDL will not stop progress of dpkg. Quite opposite > in fact, it should speed up dpkg development since there will be more > *payed* forces working on it and all changes to > *existing* CDDL files will be contributed back to the community. I'm sorry, could you point me to the part of the CDDL which guarantees paid development of CDDL-covered work? I must have missed that clause in my (admittedly brief) reading of the CDDL. > That is why OpenSolaris CDDL'd kernel allowes HW vendors to hide their > IP in their own proprietery files but at the same time forces HW vendors > to contribute their changes to CDDL-licensed files back to the > OpenSolaris community. This fact is a killer for Linux kernel. IMHO. I have my doubts that any of your Os could be H. What you've just described here, though, is the LGPL. So why didn't Sun just pick that licence instead of writing a new GPL-incompatible one? > Since Linux kernel suffers big time from not having wide HW vendors > support. It's a pest every now and then, but it doesn't appear to be killing Linux in any major way. The reason why more hardware vendors aren't supporting Linux is fear and lack of percieved commercial benefit. Neither of which your average wintel hardware vendor is going to see any differently in OpenSolaris. There *are* ways around the "GPL all your source" problem in the kernel -- look at nVidia and ATI, for instance. They're also amazingly good examples of why proprietary drivers suck: they're not wonderfully stable, and are missing (in the case of ATI, at least) support for a couple of fairly common failure modes (like not handling resume at all well). Open Source drivers likely wouldn't suffer from those problems for more than a few days. I see nothing in the CDDL which would magically ensure that vendors properly and completely supported their hardware on OpenSolaris. > I have 10+ years of writing drivers experience for all kind of OSes, so > I know what I'm talking about. HW vendors will *never* open their IP in > drivers. There's quite a number of vendor-contributed drivers in the Linux kernel, so I call bullshit. On top of that, this exact argument was made about proprietary software in general some years ago, about how Open Source could never, ever succeed. Yet, you don't have to look very far at all to see what a crock of excrement that argument was. I see the exact same crock when I look at this new version, too. > Some HW vendors will never give NDAs for their user guides. So, > GPL kernels will always suffer as the result it forces Linux community > to reverse engineer binary drivers. Without user guides publicly > available, those drivers will allways miss many features which M$ > Windows users (as an example) having and enjoying using every day. Never say never. > The idea behind Nexenta OS is to bring GNU software to the level, when > end-user will not suffer from GPL kernel *limitations*. You're not exactly a proponent of Dale Carnegie's methods, are you? > Hopefully, now you understand why our "Pilot" program was a *good > thing*. Without it, we could hit streets with unresolved legal issues. You can have an openly-readable wiki without shipping code, you know. > Now, when Nexenta team fully understands the issues, we will resolve > them first and will make ISO images available for developers only by > personal request. And once ISO polished, we will open them for public. > > Meanwhile I do not see any other issues why we should keep web site > closed, so, we will clean it up and open it up soon. But ISO images will > not be publicly available till all legal problems resolved one way or > another. But if you're shipping infringing code to those who ask for it personally, you're still infringing. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian based GNU/Solaris: pilot program
On Thu, Nov 03, 2005 at 08:45:52AM -0800, Erast Benson wrote: > On Thu, 2005-11-03 at 15:51 +, Matthew Garrett wrote: > > Erast Benson <[EMAIL PROTECTED]> wrote: > > > > > (a) to ship packaged OpenSolaris core on "main" CD, and the rest of > > > GPL-filtered software, will go on "Companion" CD, or through APT > > > repository later on. This is doable, since OpenSolaris core has > > > everything it needs to be installed as a base system. We will try look > > > carefully into GPL vs. LGPL vs. dual-licensed GPL and will clean up > > > Nexenta to be complient with requests on this mailing lists. > > > > Remember that dpkg is GPLed, so there's a slightly awkward bootstrapping > > issue. > > I personally with community help will re-write stripped down CDDL > variant of dpkg. Will Debian community be happy? But this is sort of > duplication of work. I do not think that the goal of Debian community is > to force developers do duplicate their work. You appear to be pointing the blame for "duplication of work" all Debian's way, when there are two parties who can do something about the problem -- and, when it comes down to it, the licence of the OpenSolaris libc might have been less than entirely well chosen. Now, I understand you may not want to anger our new Insect Overlords by publically criticising the application of the CDDL to certain works, but when it comes down to it, licencing the OpenSolaris libc under the CDDL is a less-than-entirely-useful move, because it restricts exactly this kind of use of the OpenSolaris libc that you propose. Even glibc isn't licenced this restrictively; it's LGPL. Considering the age and extensive analysis of the GPL, I find it fairly unlikely that the scenario you find yourself in wasn't considered at all by the drafters of the CDDL, and by the people who chose to apply the CDDL to the OpenSolaris libc. The only two conclusions I can draw is that either the lawyers thought that the scenario didn't apply, or that this kind of work wasn't intended to be permitted. The latter would be unpleasant, and the former can only be resolved either through negotiation with copyright holders of GPL works, or in a court of competent jurisdiction. While relicencing or rewriting large chunks of the (GPLd) code on which Nexenta will be based is a possibility, I'd talk to the people who are responsible for the licencing of the OpenSolaris libc before getting too noisy about Debian being to blame for any duplication of work that might result. > If Debian really wans to be "system runtime" independent, and would like > to have Debian GNU/Solaris port, it should release dpkg as LGPL > software. This should help FreeBSD and GNU/Solaris non-glibc ports to > suvirve. The current licencing of dpkg is "system runtime" independent, it's just not "software licence" independent. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian based GNU/Solaris: pilot program
On Wed, Nov 02, 2005 at 10:52:07PM -0800, Erast Benson wrote: > On Wed, 2005-11-02 at 21:25 -0800, Thomas Bushnell BSG wrote: > > Alex Ross <[EMAIL PROTECTED]> writes: > > > > > The issue... what issue? The http://www.sun.com/gnome issue? The > > > numerous-our-examples issue? > > > > Of course, that's an issue. > > > > Sun does not have the right to ship Gnome with Solaris. But I'm not > > sure they do so. > > but their loyers obviosly reads GPL differently. since they do ship > GNOME as their primary JDS desktops, I thought that JDS was built on top of Linux, not Solaris? > among others GNU GPL software, gcc, tar, sed, awk etc... Things may have changed more recently, but all of the GNU stuff *used* to be only available quite separately from the actual distribution of Solaris. Can't remember the MarketingSpeak name for the suite of tools, for the life of me, though. - Matt signature.asc Description: Digital signature
Re: [Fwd: Re: Debian based GNU/Solaris: pilot program]
On Wed, Nov 02, 2005 at 06:31:00PM -0800, Erast Benson wrote: > On Thu, 2005-11-03 at 01:14 +, Matthew Garrett wrote: > > Alex Ross <[EMAIL PROTECTED]> wrote: > > > Michael Banck wrote: > > >> If so, do you plan to use Debian's mailing lists and bug > > >> tracking system for development? > > > > > > No. We have ours: svn, Trac, and mailing lists. > > > > It's unlikely that you'll be accepted as an official Debian port unless > > you're willing to use the Debian bug tracking system. It's not > > reasonable to expect Debian maintainers to be willing to copy bugs to a > > completely different bug tracking system in cases where it turns out to > > be a Solaris-specific issue. > > on another hand, is Debian community willing to be not just GNU/Linux > centric and put some work on GNU/Solaris too? If yes, we could > re-consider. We do have non-Linux ports in the works (in various states of completion). Typically they don't get released because there is insufficient interest to get them to the quality level needed for a stable release. This lack of interest probably stems from a "Linux is OK for me" viewpoint rather than an "all these non-Linux ports are useless" opinion -- that is, apathy rather than malice. A released Debian/Solaris would, in all likelihood, enhance Debian in all sorts of ways, like porting a regular program to 64-bit and big-endian architectures cleans things up. > on another hand, Ubuntu has its own tracking system, so GNU/Solaris is > not the first one. Even though Ubuntu is GNU/Linux system... It's GNU/Linux, but not Debian. It's a derivative. The question here isn't whether you want to use some Debian-derived technologies in your port (which you're free to do with or without any input or cooperation with Debian itself) but whether you want to be part of A Debian Release. > on another hand, GNU/Solaris uses different kernel and libc, which > brings many non-Debian-related issues into play. Yehah! As I recall, there were plans to produce a non-glibc port of one of the BSDs, so there's precedent at some level. Being not-so-glibc-dependent would also benefit projects like the guys trying to rebuild Debian for uclibc (or one of the other itty-bitty-libcs) for use in the embedded space. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian based GNU/Solaris: pilot program
On Wed, Nov 02, 2005 at 06:21:12PM -0800, Erast Benson wrote: > read some more GPL vs. CDDL legality stuff on our web site at > http://www.gnusolaris.org/gswiki/GNU/Solaris_Resources Authorization Required This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required. Posting URLs to answer questions is only useful when random people who might look at those URLs can read the content of the page. - Matt signature.asc Description: Digital signature
Re: Debian based GNU/Solaris: pilot program
On Tue, Nov 01, 2005 at 09:32:49PM -0700, Alejandro Bonilla Beeche wrote: > I don't know if Alex works for Sun, but in anyway, he has the freedom > and option to express himself as he wishes. Your comments, only bring FUD. So I do *not* have the freedom and option to express myself as I wish? Interesting. However, you pass adverse comment on my adverse comment on Alex's post, and that is (apparently) acceptable. Well, I pass adverse comment on your adverse comment of my adverse comment, and I look forward to your adverse comment on my adverse comment on your adverse comment on my adverse comment about Alex's post. BTW, FUD does actually have a distinct meaning, it's not some catchall for "BadWords". - Matt signature.asc Description: Digital signature
Re: Debian based GNU/Solaris: pilot program
On Tue, Nov 01, 2005 at 09:07:08PM -0800, Erast Benson wrote: > On Wed, 2005-11-02 at 14:24 +1100, Matthew Palmer wrote: > > On Tue, Nov 01, 2005 at 06:21:45PM -0800, Alex Ross wrote: > > > 2) 2,300 Debian packages available for immediate usage. > > > > [...] > > > > > There are probably very few projects that can come anywhere close to > > > Nexenta OS, > > > in terms of the size, > > > > 2300 << 15000, by my reckoning. > > very true. but Nexenta OS is not just number of packages. it also brings > something totally new and exciting to the Debian world. I'm not discounting that it's new and exciting (I wouldn't say "totally", but that's a matter of opinion), and I'm in fact quite interested in what the technical benefits of running Debian on a Solaris kernel might be for my needs. However, Alex did specifically claim that Nexenta was of unmatched size, and I was refuting that particular claim. > ...and number of packages growes as we speak. So, it is just a matter of > time. I'm actually quite surprised that you've only been able to build 2300 packages out of Debian, but I presume there's significant hurdles which I'd have trouble imagining standing in your way there. > Most hard and exciting part is to achive acceptable level of integration > between OpenSolaris Core and the rest of Debian world. Nobody did it > before. So, it is sort of not for newbies. :-) Right. You want competent, clueful, technical people to work on the project. I suspect that these are the same people who are going to be turned off (as I was) by unashamed marketing speak. In fact, your message has gotten me far more interested in Nexenta than the original did, as I can see the sort of things that need to be done and might be interested in working on some of those. - Matt signature.asc Description: Digital signature
Re: Debian based GNU/Solaris: pilot program
On Tue, Nov 01, 2005 at 06:21:45PM -0800, Alex Ross wrote: > 2) 2,300 Debian packages available for immediate usage. [...] > There are probably very few projects that can come anywhere close to > Nexenta OS, > in terms of the size, 2300 << 15000, by my reckoning. > and openness. You keep using that word. I do not think it means, what you think it means. > If interested, please send e-mail to , and tell us > a few > words about yourself. We'll respond with a user/password. Not to poop on your parade, but please, next time you go to announce something to a technical list like d-devel -- drop the marketing guff, just stick to the useful info. - Matt signature.asc Description: Digital signature
Re: /usr/lib/debug/usr/lib etc. in various packages [bug 336698]
On Tue, Nov 01, 2005 at 12:19:07AM +, Darren Salt wrote: > I've noticed that several files which should be in /usr/lib/debug are in fact > in /usr/lib/debug/usr/lib. Checking via packages.d.o shows that as well as > this, debug data is showing up in /usr/lib/debug/usr/bin and > /usr/lib/debug/lib. Further to Steve's comments, see section 15.2 of the GDB manual, "Debugging Information in Separate Files". It describes what actually goes on. The rationale for keeping full paths inside /usr/lib/debug is solid, too, once you think about it -- without the hierarchy within /usr/lib/debug, you'd have no way to store detached symbols for multiple executables with the same name, unless the files were stored by some non-name-related scheme (ugly). - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: major problem with gnome-games dependency]
On Wed, Oct 12, 2005 at 03:13:30AM +0200, Adeodato Simó wrote: > [CC'ing the aptitude maintainer, mainly for the last paragraph.] > > * Jeroen van Wolffelaar [Tue, 11 Oct 2005 22:00:22 +0200]: > > > The main things that this thread shows me, is that it is *not* immediately > > clear to people not too familiar with Debian that the removal of the 'gnome' > > package will not have *any* effect on what actual software is actually > > installed > > on your system. > > Do not forget, though, that with aptitude becoming the prefered tool > for package management (over plain apt-get), this is no longer true. > "aptitude install gnome" will mark all of its dependencies as "auto", > i.e. just installed because of a dependency. Which means that > "aptitude remove gnome" will want to remove all the dependencies _for > real_, unless they have been previously marked as "noauto" by hand. What will "aptitude remove gnome-games" do? Remove gnome, leaving the deps behind, or remove gnome and then remove it's deps because they're auto? - Matt
Re: Creating Debian packages
On Wed, Oct 05, 2005 at 05:48:34PM +0200, Thomas Jollans wrote: > What documentation is available on the subject of creating debian > packages ? What documents should I read before starting ? And before > applying for NM ? I'm especially interested, for the beginning, in a > comprehensive HowTo on the subject. I have already read the social > contract and the DFSG ;) The FAQ for the debian-mentors list should answer most of your questions. debian-mentors is also a better mailing list for these sorts of questions. 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: init.d script for iptables ruleset
On Wed, Sep 21, 2005 at 01:12:38AM -, Samuel Jean wrote: > Here it goes. I wondered about a clever way to load my iptables ruleset via > init.d's script. Surprisingly, I didn't find any with Debian. I didn't search > that much though. Have a look at Shorewall -- it does similar things to what you're proposing, and is already written. There's probably also a lot of other firewall maintenance systems with similar methods. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using buildds only (was: Results of the meeting...)
On Mon, Aug 22, 2005 at 10:45:58AM +0200, W. Borgert wrote: > Quoting Sven Luther <[EMAIL PROTECTED]>: > > All packages should be built by official debian buildds anyway, not on > > developper machines with random cruft and unsecure packages installed, or > > even > > possibly experimental or home-modified stuff. > > That would be very good, indeed. I am very much in favour of allowing > only source-only uploads and having all binaries build by the buildds > only. The argument against it is, that DDs wouldn't check, whether > the package builds cleanly etc. I think, that this is a poor argument, > but anyway. I used to think that too. I took a wander through queue/reject on merkel. I don't think that any more. I'm curious as to how Ubuntu is going to sustain source-only uploads, honestly. - Matt signature.asc Description: Digital signature
Re: Bug#323855: ITP: opencvs -- OpenBSD CVS implementation with special emphasis in security
On Sun, Aug 21, 2005 at 07:01:37PM -0700, Daniel Burrows wrote: > On Saturday 20 August 2005 02:20 pm, Thomas Bushnell BSG wrote: > > How does their extensive use of it explain why they would reimplement > > it? > > Is there anyone who's used CVS extensively and HASN'T thought about > reimplementing it? Judging by the number of revision control systems springing up out there, I'd say the answer to that question is "No, and furthermore most of them have gone further than just thinking about it". OpenCVS is one of the few to not think "and I can make it Suck Less, to boot". - Matt signature.asc Description: Digital signature
Re: Bug#323855: ITP: opencvs -- OpenBSD CVS implementation with special emphasis in security
On Sun, Aug 21, 2005 at 10:05:43PM +1200, Martin Langhoff wrote: > On 8/19/05, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote: > > I'd love to see people migrating to Arch > > Being a long-time Arch user, let me tell you that Arch has been > orphaned upstream. Correction: tla, an Arch frontend, has been orphaned upstream. Most of the interesting development work for the past 6 months or so has been on baz, another Arch frontend. Saying Arch has been orphaned upstream because of Tom Lord's announcement is roughly similar to saying that Linux has been orphaned because the 2.0 kernel series is no longer maintained... > and it's unclear for how long, as Canonical has their eyes on bzr and > hct. I'm quite confident that there will be an upgrade path from Arch archives to bzr archives. Canonical, amongst other people, have too much invested in Arch to just let that history fester. As for hct, I understand it is a wrapper frontend to baz/bzr to provide the sorts of functionality that package maintainers need, instead of being a general-purpose revision control tool. - Matt signature.asc Description: Digital signature
Re: arch, svn, cvs
On Sat, Aug 20, 2005 at 03:17:35PM -0700, Thomas Bushnell BSG wrote: > like a foundation already: a bad release manager chose a pyramidal > model. That's the beginnings of a good inductive argument. Then we > add the other foundation he gives: here's a bunch of well-managed > projects, which use a non-pyramidal scheme. http://www.zedshaw.com/blog/programming/programmer_stats.html Particularly, in this instance, the section on Confounding. - Matt signature.asc Description: Digital signature
Re: Intermediate Web Development on Debian
[This list is typically for discussion related to the development of Debian, not development on Debian. Nonetheless...] On Tue, Aug 16, 2005 at 04:11:45PM -0400, Parker, Matthew wrote: > -- Technology Requirements -- > > * Relatively quick development time > > * Linux-based > > * Allow for automated unit testing I would suggest at least taking a look at Ruby on Rails (http://www.rubyonrails.org). I've heard interesting things about the language, and the Rails framework appears to be suited to rapid application development, and there's a solid unit testing framework available. I wouldn't necessarily sell everything else down the river for it, but if you're assessing new technologies, it's definitely worth a look. - Matt signature.asc Description: Digital signature
Bug#320855: RFA: cyrus-imapd
Package: wnpp Severity: normal (Note that this is the obsolete 1.5.x series of cyrus-imapd, not the current 2.1 cyrus packages!) As I'm transitioning all servers under my care away from cyrus-imapd 1.5, I have little to no further interest in maintaining these packages. I would only recommend someone maintaining them if they're in the position I was in when I took over maintainership: they have servers running cyrus-imapd 1.5 that they can't easily transition to another mail system. Note that maintenance of this package should include keeping a bit of an eye on security reports from cyrus-imapd 2.1 and checking if they're applicable to 1.5. If nobody actively adopts[1] this package, I will ask for it's removal from unstable in a few weeks, which is my preferred option anyway. - Matt [1] That is, they let me know they're willing to maintain it, *and* make an upload with themselves as maintainer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt 0.6 downloads from second archive?
On Thu, Jul 21, 2005 at 07:12:29AM +1000, Graham Williams wrote: > Since installing apt 0.6 on an otherwise up-to-date unstable (except > for anything depending on the aspell libraries...) packages on my > local archive are being overlooked even though this archive is listed > before others in my apt/sources.list. Downgrading to apt 0.5 and > things work again as expected (i.e., most is downloaded from > localhost). Huge (uninformed) guess, but apt may be preferring packages from repositories it can verify the contents of. Besides, if the versions are the same, then the contents should be the the same too, and (modulo bandwidth charges) which one you get from shouldn't matter. BTW, the new (twisted-based) apt-proxy rocks hard, if it's your traffic allowances you're worried about (and who wouldn't be in Australia, given what we get charged). - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian mentors & ubuntu
On Tue, Jul 19, 2005 at 09:34:28AM -0400, David Nusinow wrote: > On Tue, Jul 19, 2005 at 03:14:32PM +0200, martin f krafft wrote: > > also sprach David Nusinow <[EMAIL PROTECTED]> [2005.07.19.1507 +0200]: > > > It's rather pathetic that the Debian mentors site doesn't run the > > > operating > > > system that's the reason for its existence. > > > > Go ahead and provide hosting for it on a Debian machine, set it up, > > then apply for the domain to be moved. > > Asking me to do this doesn't make the situation any less pathetic. It's > also not worth the effort, seeing as very few packages of note are actually > distributed from it as far as I've seen. The intention, as I understand it, isn't to be a general-purpose package repository (at least, last time I looked at it, no pre-built binary packages were provided), but to be a "staging area" of sorts for packages which people wanted sponsored into the archive. The value of the packages therein is a subjective matter, and one which I, for one, am not touching with my 10 foot pole (Barge, mk1, mod0). - Matt signature.asc Description: Digital signature
Re: debian mentors & ubuntu
On Tue, Jul 19, 2005 at 11:06:28PM +1000, Hamish Moffatt wrote: > Unrelated question: why was mentors.debian.net delegated (historically) > to non-DDs? Because those were the people that decided they wanted the service, and dedicated the time to getting it (and keeping it) operational? - Matt signature.asc Description: Digital signature
Re: debian mentors & ubuntu
On Tue, Jul 19, 2005 at 12:21:09PM +0200, Nico Golde wrote: > why is mentors.debian.net powered by Ubuntu? Why is this question on debian-devel, instead of in the inbox of the m.d.n maintainers? - Matt signature.asc Description: Digital signature
Re: BTS version tracking
On Mon, Jul 18, 2005 at 12:06:29PM +0100, Colin Watson wrote: > A frequently requested feature for the bug tracking system in recent years > has been the ability to track which bugs apply to which distributions, > so that, eg, maintainers and others can tell which bugs that have been > fixed in unstable still apply to packages in testing or stable. > > This has now been implemented. May I just say, to Colin, Anthony, James, and anyone else who had the slightest bit to do with implementing this functionality: Thank You. It's a tricky problem, both on the UI and infrastructure sides of the coin, it must have taken quite some time to put it all together, and I'm glad that we've got it. This will make debbugs even better to use now. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: unreproducable bugs
On Fri, Jul 15, 2005 at 01:54:48PM -0400, kamaraju kusumanchi wrote: > Manoj Srivastava wrote: > >On Fri, 15 Jul 2005 15:42:44 +0200, Nico Golde <[EMAIL PROTECTED]> said: > > What's with the recent push to get every little things written > >down into policy, so the developer no longer is required to have an > >ability to think, or exercise any judgement whatsoever? > > Dont know about others. But whenever I post some question on irc or a > mailing list the most frequent answer is 'it is there in the policy', > 'go by the policy', 'read the policy' etc., Similar answers would have > made other people think that "all Debian maintainers/developers should > go by the policy and only by the policy". I'd suggest checking the usual suspects (Policy, DevRef, NM Guide, etc) before asking questions. Then, when people give you those sorts of answers, you can confidently say "no it's not, go eat your hat". - Matt signature.asc Description: Digital signature
Re: interacting with the press
On Fri, Jul 15, 2005 at 08:12:36PM +1200, Nigel Jones wrote: > On 15/07/05, Matthew Palmer <[EMAIL PROTECTED]> wrote: > > On Wed, Jul 13, 2005 at 11:11:49AM +0200, Florian Weimer wrote: > > > * Anand Kumria: > > > > > > > [1]: > > > http://smh.com.au/news/breaking/debian-debates-support-for-ports/2005/07/12/1120934228145.html> > > > > > > Apparently, this is subscription only. 8-( > > > > > > Has this article been republished by another newspaper with less tight > > > access controls? > > > > Lynx is love. > I think it's just that they generate a random number to decide if they > will let you view without registration (thats what happened for me), > so you must be a lucky one ,) No, they allow unregistered access to one article per day, but they work that one in some fashion that apparently doesn't get triggered with lynx, so you can view lots of articles (unless they've fixed that bug recently and I haven't noticed). - Matt signature.asc Description: Digital signature
Re: Bug#318204: ITP: php-simpletest -- Unit testing and web testing framework for PHP
On Wed, Jul 13, 2005 at 08:48:44PM -0400, Charles Fry wrote: > * License : The Open Group Test Suite License I'm not optimistic about this licence being DFSG-free. - Matt signature.asc Description: Digital signature
Re: interacting with the press
On Wed, Jul 13, 2005 at 11:11:49AM +0200, Florian Weimer wrote: > * Anand Kumria: > > > [1]: > http://smh.com.au/news/breaking/debian-debates-support-for-ports/2005/07/12/1120934228145.html> > > Apparently, this is subscription only. 8-( > > Has this article been republished by another newspaper with less tight > access controls? Lynx is love. - Matt signature.asc Description: Digital signature
Re: Greylisting for @debian.org email, please
On Sat, Jun 18, 2005 at 02:33:49PM -0700, Thomas Bushnell BSG wrote: > [EMAIL PROTECTED] (Marco d'Itri) writes: > > > Stop sending mail from dynamically-assigned IP addresses. Deal. > > Gee. There is no reliable way to know whether an IP address is static > or not. SMTP is supposed to work from both: which means that > graylisting is in fact violating the protocols in a severe way. And > are you offering to get me a static address for free? Yes. Several people (myself included) have made offers to that effect. - Matt signature.asc Description: Digital signature
Re: And now for something completely different... etch!
On Thu, Jun 09, 2005 at 01:13:16AM +0200, Javier Fernández-Sanguino Peña wrote: > to find their own (sometimes flawed) solution to a very common problem. Years using Linux: 10. Times I've absolutely needed an X-less boot when an XDM was installed: 0. How common was that problem you were trying to solve, again? - Matt signature.asc Description: Digital signature
Re: Is Luca - De Whiskey's - De Vitis MIA?
On Tue, Jun 07, 2005 at 11:48:49AM +0200, Andreas Tille wrote: > I do not know why you doubt that Luca will come back but as far as I know > him from conferences I'm pretty sure that his main interest were good > quality Debian packages Recalling his packages in the past, I get a different opinion. - Matt signature.asc Description: Digital signature
Re: Arch-specific bugs [was: Canonical and Debian]
On Tue, Jun 07, 2005 at 05:11:05PM +0200, Josselin Mouette wrote: > Le mardi 07 juin 2005 à 02:12 -0700, Steve Langasek a écrit : > > Oh, you'll also note that the traditional "slow" architectures (mips, > > mipsel, m68k, arm) aren't on this "problems" list. That's because a *lot* > > of effort has been put into providing sufficient parallelization for each > > architecture; the ongoing cost to *maintain* these parallel buildds is > > higher than to maintain a single buildd, and given that each of arm, mips, > > and mipsel have had instances over the past year where they were > > short-handed, I don't know how realistic it is to expect that they'll stay > > caught up through etch's lifetime. > > This isn't fair. Instead of throwing out these arches, why not let them > in the current state while there's some effort to maintain them, and if > these efforts actually slow down, then drop the architecture at that > moment? I think the effect of "your arch is now dead because it didn't keep up for the last little while" warning might be a little worse than "we don't consider your arch to be maintainable long-term to the same standard as the rest of Debian, let's work out to what level we can support it". > > The second most significant area of concern, for me, is having people being > > proactive about dealing with per-architecture build failures. There's no > > particular reason that should be the buildd admins' or the release team's > > area of responsibility, either; all it requires is people who know what > > they're doing to file sensible bug reports without gratuitously duplicating > > efforts, and people who know the architectures to help the maintainers sort > > out bugs. > > I agree. This is the maintainers' duty, not the release team's. And if > the problem is too complicated to solve for the maintainer, someone > willing to support the architecture has to help. If such a person cannot > be found, this is a sign the architecture cannot be supported in Debian. This is tricky to assign "blame" for, though. I've only had one (positive, as it turned out) experience with contacting a porter team for assistance with an arch-specific bug, but I can easily see situations where it's likely to be difficult to work out who is "at fault". - Matt signature.asc Description: Digital signature
Re: Is Ubuntu a debian derivative or is it a fork?
On Tue, Jun 07, 2005 at 09:19:06AM -0700, Matt Zimmerman wrote:
> The fact is that Ubuntu has proactively contributed a lot of code back to
> Debian, much more than most Debian derivatives have. I see no reason why
> claims that Ubuntu is not doing _enough_, or making it easy _enough_ for
> Debian to merge its work pales in contrast to the fact that many other
> organizations have done, and are doing, nothing whatsoever in this regard.
Because Ubuntu makes a lot of noise about being a good community member and
contributing back as much as possible, while most other derivatives just
take what they want quietly and disappear into the mist.
Between some slightly screwy policies ("thou shalt not post patches to the
Debian BTS, merely link to them", for instance), the development of
proprietary software supposedly in support of Free Software goals
(Malone/Launchpad), and a perceived "muscling in" on Debian's traditional
turf (Community developed/supported Linux distribution), surely you can
understand where some of the defensiveness is coming from?
- Matt
signature.asc
Description: Digital signature
Re: And now for something completely different... etch!
On Wed, Jun 08, 2005 at 10:31:33AM +0200, Jesus Climent wrote: > > > - Separate runlevels: 2 for multi, no net, 3 for multi no X, 4 for X, 4=5 > > > > No way. Debian has always avoided mindlessly dictating what runlevels > > must be used for. There's no reason to destroy this feature now. And > > there's no advantage to consuming an entire runlevel just to say > > "/etc/init.d/xdm stop" or "/etc/init.d/networking stop", which is > > all that you are proposing. > > Still, better have init 2 than having to hack the boot command line to set > init=/bin/bash, having to remount in rw and editing whatever you fucked up, > before all the services go up and people start login into your server. It's called single-user mode. - Matt signature.asc Description: Digital signature
Re: And now for something completely different... etch!
On Wed, Jun 08, 2005 at 10:23:06AM +0200, Jesus Climent wrote: > On Mon, Jun 06, 2005 at 09:21:37PM -0400, Joey Hess wrote: > > This solves your problem fairly well, since the issue then becomes only > > keeping d-i secure and keeping the installed system secure, not keeping > > the system secure while it's installing itself. Daemons will not be > > started dueing the installation, and will come up on reboot. > > Add to the list of daemon related features the "not start daemons by default" > and wait for the admin to define which ones to start from /etc/defaults or > whatever. Jesus, meet policy-rc.d. - Matt signature.asc Description: Digital signature
Re: Is Ubuntu a debian derivative or is it a fork?
On Fri, Jun 03, 2005 at 08:07:33AM +0200, Tollef Fog Heen wrote: > * John Goerzen > > | If it matters, I'll add my voice to the chorus on that. Anything that > | requires me to go off to the net to fix takes longer to fix and is > | more annoying to deal with. > > Well, some people like just having a link to a patch. Me for > instance. Does http://bugs.debian.org/nn not work for you? - Matt signature.asc Description: Digital signature
Re: Is Ubuntu a debian derivative or is it a fork?
On Thu, Jun 02, 2005 at 03:56:18PM -0700, Matt Zimmerman wrote:
> On Fri, Jun 03, 2005 at 07:49:39AM +1000, Matthew Palmer wrote:
> > On Thu, Jun 02, 2005 at 12:47:30AM -0700, Matt Zimmerman wrote:
> > > proposals, but we have very limited developer resources compared to
> > > Debian.
> >
> > I keep hearing this from Ubuntu, and yet the obvious solution to the problem
> > ("stop doing so damn much") has apparently never been considered. It seems,
> > from my perspective, that doing a good job on a smaller subset of the free
> > software universe would be better than the current attempts. Scale over
> > time, don't try to do everything at once and then say "we didn't have enough
> > resources to do it properly".
>
> You're not suggesting "stop doing so damn much" so much as "spend more
> resources on Debian and fewer resources on Ubuntu".
No, I'm suggesting "stop doing so damn much". Really.
Ubuntu has committed to being a good community player and sending patches
back upstream. It's one of it's big selling points in the geek sphere. But
on several occasions now, I've heard "we can't give back to Debian because
we're too busy trying to Ubuntuise the entireity of Debian main + a bunch of
other stuff with only a few people".
I wouldn't be in the slightest bit worried about Ubuntu not contributing
back to Debian if it was Yet Another Derivative. There's over a hundred
Debian derived distributions, and most of them probably contribute little or
nothing back to Debian. I don't mind that, it's a nice thing about free
software. But Ubuntu is making lots of noise about it being a good
community member and giving back -- but the noises from the trenches are
"too busy, sorry".
In effect, you're asking Debian to do what you said you'd do -- contribute
back -- by chasing patches out of p.u.c/~scott/patches/ or wherever you're
going to stick them in launchpad.
> This is a difficult balance to strike, and one side will be displeased
> with the result regardless. A "good job" to you means that Ubuntu
> developers do a larger share of the work of getting their changes into
> Debian. A "good job" to Ubuntu means that the work is more complete and
> correct.
I would imagine that a "good job" to everyone would be matching words with
actions. Not just "when Malone gets finished" or "when hct is finished" or
whatever, but now. And if you can't do all of the work you've said you'll
do due to lack of resources, then pick something that you can live without,
and stop doing it.
- Matt
signature.asc
Description: Digital signature
Re: Is Ubuntu a debian derivative or is it a fork?
On Thu, Jun 02, 2005 at 11:26:58PM +0100, Mark Brown wrote: > That said, I was informed today that there's a policy that when bugs are > submitted the patch has to be put on people.ubuntu.com and linked to in > the report rather than being included in the report, which did strike me > as rather strange. Ugh. I *like* having all the necessary stuff in an e-mail; it means there's a nicely indexed copy of the info sitting on my local laptop, and considering the fact that almost all of my personal time on the laptop these days is spent disconnected from the 'net, something that I have to wget is going to have to take a much lower priority. - Matt signature.asc Description: Digital signature
Re: Is Ubuntu a debian derivative or is it a fork?
On Thu, Jun 02, 2005 at 12:47:30AM -0700, Matt Zimmerman wrote:
> The same logic applies to many bugs as well. Would it really be better to
> have an open bug report in debbugs, than a patch on people.ubuntu.com?
I'd prefer an open bug report in debbugs with the patch included.
> I know of no reason to mass-file bug reports, except that some people insist
> that the best place to publish Ubuntu's patches is in debbugs. I disagree
> with that position, myself.
Why? It's a commonly held belief that the best place to publish Debian's
(relevant) patches is in the upstream BTS.
> proposals, but we have very limited developer resources compared to Debian.
I keep hearing this from Ubuntu, and yet the obvious solution to the problem
("stop doing so damn much") has apparently never been considered. It seems,
from my perspective, that doing a good job on a smaller subset of the free
software universe would be better than the current attempts. Scale over
time, don't try to do everything at once and then say "we didn't have enough
resources to do it properly".
- Matt
signature.asc
Description: Digital signature
Re: FW: Processing of tla-load-dirs_1.0.21ubuntu1_source.changes
On Sun, May 22, 2005 at 03:56:35PM -0500, John Goerzen wrote: > Can anyone tell me what this means, and who is trying to upload this to > Debian without even sending me a patch first? What it means: the Ubuntu maintainer for tla-load-dirs (sorry, don't know who) managed to send their package in the direction of the Debian upload queue instead of the Ubuntu one. I'm not sure why this happens, because an Ubuntu maintainer should (I presume) change their dput/dupload defaults to Ubuntu, and the dput/dupload packages in Ubuntu should probably have their defaults changed to Ubuntu, not Debian. As for the who, it should be easy enough to work out either from the given public key ID: > gpg: Signature made Sun May 22 14:24:08 2005 EDT using DSA key ID C5AA2301 or, alternately, using the packages.debian.org equivalent (it may have moved to packages.ubuntu.com by now; if not, it has been mentioned here in the past but I can't remember what the temporary URL is). If I were online at the moment I'd hunt up the info for you, but I'm in a train tunnel as I type. - Matt signature.asc Description: Digital signature
Re: transcode
On Tue, May 03, 2005 at 04:36:30PM -0700, Jeff Carr wrote: > PS: of interest to the mplayer thread: motion.c allows mpeg-1 & mpeg-2 > support for non-commercial software. AKA: GPL/LGPL'd implementations are > allowed. No, GPL/LGPL is not non-commercial. - Matt signature.asc Description: Digital signature
