Re: Problem with dpkg on alpha ?
I've seen that on the buildd but my own Alpha isn't having any trouble. A message on this topic to debian-alpha yielded no replies either, so I suspect the buildd machine is the only one hosed. -- John On Mon, Nov 01, 2004 at 07:42:01PM +0100, Jean-Yves LENHOF wrote: > Is'nt there something wrong with dpkg on alpha... it seems to segfault a > lot these days... > > http://buildd.debian.org/build.php?&pkg=mozilla-firefox&ver=0.99%2B1.0RC1-2&arch=alpha&file=log > http://buildd.debian.org/build.php?&pkg=cxref&ver=1.6-3&arch=alpha > http://buildd.debian.org/build.php?&pkg=fribidi&ver=0.10.4-6&arch=alpha&file=log > > Regards, > > PS : I'm not on the list > -- > Jean-Yves LENHOF <[EMAIL PROTECTED]> > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On Wed, Dec 01, 2004 at 11:32:18PM +, Will Newton wrote: > On Wednesday 01 Dec 2004 21:35, Manoj Srivastava wrote: > > > Right. We should not have games like quake, doom, or > > nethack,. since they promoite murder and mayhem and eating of > > corpses. > > So far so sarcastic. IMO if it can be demonstrated that distributing > something > is illegal we should think about not distributing it. > > We are not the EFF. If they or anyone else wants to fight for the right to > look at cartoon tits then that's fine by me. We are trying to build an > operating system. I think. You are quite right. We cannot fight all battles for everyone. Let's make an operating system. -- John
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On Wed, Dec 01, 2004 at 05:53:08PM -0600, Manoj Srivastava wrote: > On Wed, 1 Dec 2004 23:32:18 +, Will Newton <[EMAIL PROTECTED]> said: > And we have no time to set up i judgement over content -- > there is a clear criteria for inclusion of packages in Debian already. We have no need to. We can collectively make reasonable decisions without having to set up a constitional authority to do so. On this particular question, you are right that we cannot set up a purley objective mechanism to decide a subjective question. What you are missing is that we don't have to. What you are also missing is that we jeopardize our stated goal -- making a quality Free operating system -- by trying to push into it something that so many people find objectionable, exploitative, and illegal. Perhaps you believe that there is no content that should be illegal. That is, however, not the case in much of the world. Child pornography is illegal in much of the world, and I might add rightly so, especially it is so often associated with abuse, exploitation, and even slavery. Would you still support including child porn in Debian? If so, how could you possibly justify your sabotage of Debian by making it a serious crime to possess and copy it in just about every jurisdiction on the planet, even Sealand? If not, then your arguments about it being impossible to set a line are moot. While we are also discussing legality, before advocating the inclusion of pornography in Debian -- which is distributed to adults and minors by all manner of organizations worldwide -- please remember that the organization that holds Debian's legal assets, SPI, is incorporated in the United States and is subjected to United States laws. Even if you could convince us that it is legal to distribute pornography to people of all ages with no warning in the United States, it is unlikely that you could convince everyone of that. These actions could expose us to some fairly serious legal consequences, including lawsuits from all manner of people, and, depending on the exact nature of the porn you suggest we should include, possible jail time for various people associated with Debian. I for one do not think that the cause of including porn in Debian is worth it. How many people here are willing to go to jail so that we can include porn in main? Are you? Why? If you claim there is no line we can draw, then if we agree with you, there is no reason to keep child porn out of main either. Can we please use some common sense?
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On Thu, Dec 02, 2004 at 01:30:48AM -0600, Manoj Srivastava wrote: > On Wed, 1 Dec 2004 19:34:06 -0600, John Goerzen <[EMAIL PROTECTED]> said: > > > On Wed, Dec 01, 2004 at 05:53:08PM -0600, Manoj Srivastava wrote: > >> On Wed, 1 Dec 2004 23:32:18 +, Will Newton > >> <[EMAIL PROTECTED]> said: And we have no time to set up i > >> judgement over content -- there is a clear criteria for inclusion > >> of packages in Debian already. > > > We have no need to. We can collectively make reasonable decisions > > without having to set up a constitional authority to do so. > > At this point, there is no mechanism by which we can try and > exclude packages out of debian which offend one (believe me on > this. vi would have been long gone otherwise). The only thing you can > do is either convince all the ftp-masters not to process it, or get a Well that's a mechanism, the ftp masters frequently reject things. > A lot of people find various things in debian > objectionable. Others do not. And people finding this package > illegal -- I'm sorry, I do not see a clearcut argument that has so > convinced me. Indeed, I am pretty sure that the images in this > package are not illegal to distribute, either on a website (I have > seen several urls posted), not as a package. Feel free to proce (not > just offer opinions that I might be) wrong. But your argument was not limited to this particular package. You also argued that we should not be limiting ourselves by things that some find objectionable, and extended the question into other nude images. I am simply saying that these things can be illegal indeed. And if you think that we are safe in this instance because it looks fine to us, think again. All it takes is one Southern prosecutor up for re-election to go after all the vile scum porn perpetrators on the Internet for us to be in what is sure to be a draining legal fight, even if we do wind up victorious. That, or one offended parent. Don't forget that people can sue us -- and force us to mount a costly defence -- even if the law is on our side. > > If not, then your arguments about it being impossible to set a line > > are moot. > > Rubbish. We set the line at illegal content, and by that > criteria, this is not illegal to distribute, and hence hot-babe is > in. And yet, at the same time, were you not saying we couldn't do that because parochial laws differ? In this instance, by whose laws are we determining that it's legal? > > remember that the organization that holds Debian's legal assets, > > SPI, is incorporated in the United States and is subjected to United > > States laws. > > SPI does not govern Debian's behaviour. True enough, but the fact that it's incorporated in the United States makes it subject to US law. That makes it easy to be sued, assets (read: machines) siezed, etc. > Have you any proof the content is illegal to distribute? > Seems like it has been up and around for a while. Indeed, material > even worse than that is present on web sitres situated in the > US. Seems to me that this is mere FUD, trying to prevent expression > of artistry you are offended by. I am only objecting to it being included in Debian. It is extremely difficult to prove whether or not such a thing is illegal in the U.S. because: 1) laws differ based on location, and 2) it's a subjective question a judge has to answer, and 3) judges have different subjective taste. When it comes down to it, though, neither of us are lawyers and thus are not really qualified to speak about it. What I am saying is that there is no reason to take the risk. > > If you claim there is no line we can draw, then if we agree with > > you, there is no reason to keep child porn out of main either. Can > > we please use some common sense? > > When you stop creating paper tigers to atrtack, we can talk, Perhaps you should stop asserting that it is impossible to reject these things then, or that it is impossible to set a line. -- John
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On Thu, Dec 02, 2004 at 01:32:26AM -0600, Manoj Srivastava wrote: > On Wed, 1 Dec 2004 19:03:59 -0600, John Goerzen <[EMAIL PROTECTED]> said: > > > You are quite right. We cannot fight all battles for everyone. > > > Let's make an operating system. > > And stop trying to censor data and make sure our users are > only exposed to RightThink. We should stop being the morL guardians > of the free world, and let licenses, and what is legal to distribute, > govern what goes in Debian. And there you go with the red herring. Nobody is suggesting censorship. Debian has made decisions about what we include and exclude in our OS for years. Would you suggest we are censoring because we don't include all of Project Gutenberg in main? Or because we don't include every GPL'd package on Freshmeat? To simply not include something in a package we deliver has nothing to do with censorship. Censorship is preventing people from being able to say or access material, and we are not doing that. (Though we do distribute tools that can, such as chastity-list and squidguard.) People are quite able to access this material, or other matierial, using Debian, on their own. -- John
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On Thu, Dec 02, 2004 at 03:05:53AM -0600, Manoj Srivastava wrote: > > But the nudy cartoons would, especially in the hand of a minor. > > As far as I know, we are not selling to minors. There are Then you are extremely out of touch. I believe we have minors as developers. I was a minor when I first joined as a developer, at any rate, and I have personally given copies of Debian to many minors that have installed and run it successfully. And I know that I am not alone in that. > tings in Debian already that may not be suitable material for minors > in the first place. Saying "we're already doing this" is completely irrelevant to the question "is it right". -- John
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Thu, Dec 02, 2004 at 01:48:09AM -0600, Manoj Srivastava wrote: > Who gets to decide for each case? Usually it is the person who The ftpmasters, for starters. > does the work who makes the decision -- the packager, in this > case. The only way to override that is call in the tech ctte -- but > this is not a technical issue. Yup, a GR for each case. No, the ftpmasters can.
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Thu, Dec 02, 2004 at 12:28:20PM -0200, Fernanda Giroleti Weiden wrote: > "It is also the type of discussion that deterred me > from becoming involved in Debian for some time." > > http://lists.debian.org/debian-women/2004/12/msg00011.html Indeed, and in addition to the powerful legal arguments, this is another powerful argument. If our goal is to advance the cause of a Free operating system, then why should we be including, in our OPERATING SYSTEM, images that serve no useful purpose, and instead alienate millions or billions of people worldwide? How does this advance our stated priorities: our users and Free Software? Does anyone seriously think that we are being a disservice to users because we don't have porn integrated into the operating system? Does anyone seriously think that including these particular images would be such an overwhelming benefit? Regardless of our personal opinions on this particular question, the fact remains that it is deeply offensive to many people. This is not the right way to show people that Free Software is the way to go. By all means, let's be open and inclusive and accept Free software from everywhere and users from everywhere. But at the same time, we don't have to accept images from everywhere nor any developer that knocks at our door. This is not our fight. Let's fight for Free Software, and let others battle this one out. -- John
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Thu, Dec 02, 2004 at 09:54:12AM -0500, Stephen Frost wrote: > > If our goal is to advance the cause of a Free operating system, then why > > should we be including, in our OPERATING SYSTEM, images that serve no > > useful purpose, and instead alienate millions or billions of people > > I agree with this and is why I was suggesting that someone draft up some > language which outlines, for the benefit of our users, things they're > not likely to find in Debian. I suppose that might end up being too > difficult but I think it'd be good to have some criteria for packages to > pass in order to be accepted which includes issues like these and is > clear enough that our users understand it. Indeed, and this is also why Manoj's vi/KDE argument is not relevant. vi serves a useful purpose for an operating system. Porn/nudes/whatever don't. -- John
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Fri, Dec 03, 2004 at 01:04:50AM +0900, Mike Hommey wrote: > On Thu, Dec 02, 2004 at 09:03:18AM -0600, John Goerzen <[EMAIL PROTECTED]> > wrote: > > Indeed, and this is also why Manoj's vi/KDE argument is not relevant. > > > > vi serves a useful purpose for an operating system. > > > > Porn/nudes/whatever don't. > > What about the bible, then ? If it has to be removed for the sake of consistency, then remove it. It's available from plenty of other sources. -- John
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Thu, Dec 02, 2004 at 11:21:03AM -0600, Manoj Srivastava wrote: > > Indeed, and this is also why Manoj's vi/KDE argument is not > > relevant. > > > vi serves a useful purpose for an operating system. > > > Porn/nudes/whatever don't. > > A CPU monitor does. How the load is displayed, line graph, > dancing bars, color changes, morphing pictures, is a preference > issue. Red herring. Nobody objects to the CPU monitor itself. The objection lies with the included image, not with the code. Remove that image and I don't think there'd be any complaint. -- John
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Thu, Dec 02, 2004 at 12:26:26PM -0600, Manoj Srivastava wrote: > > Nobody objects to the CPU monitor itself. The objection lies with > > the included image, not with the code. Remove that image and I > > don't think there'd be any complaint. > > If the program works well, and depicts cpu usage, then the the > image can change the aesthetics, not the utility. In my eyes, you > have just blown all arguments of uselessness to smithereens. No, it appears you have just supported it. If you contend that the image has no impact on the utility, then let us just replace the image and be done with it. Or do you claim that aesthetics has no utliity? -- John
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Fri, Dec 03, 2004 at 07:45:26PM +, Will Newton wrote: > On Friday 03 Dec 2004 00:11, Manoj Srivastava wrote: > > > Umm, the linux kernel, the purity tests, and the offensive > > fortunes are not G rated, so can't be given to minors without > > parental consent. I guess that makes it illegal in the united > > states. > > You can't distribute text with the word "fuck" in it anywhere to minors in > the > US? No, that's incorrect, I don't believe there are any stipulations regarding minors there. I think the thing is that you can't broadcast it on public airwaves (things that are regulated by the FCC).
Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 07:08:48PM -0800, Russ Allbery wrote: > Bruce Perens <[EMAIL PROTECTED]> writes: > > I think that tying core Debian packages to the Red Hat boat anchor is a > horrible, horrible idea. I tend to agree with sentiments like this, but didn't Bruce mention that we could participate in this organization even if we didn't take their packages? That is, perhaps we could influence the direction to a more useful one? If that is the case, it seems zero risk to me. -- John
Re: The LCC is a bad idea, but that doesn't mean the LSB doesn't have any issues
On Thu, Dec 16, 2004 at 10:43:37PM +0100, Wouter Verhelst wrote: > Thus, the answer to the failure of the LSB is not "the Free Software > people should be more helpful to the non-free people"; the correct > answer is "the non-free people should be more helpful to the Free > Software people". Very well written, Wouter. Thanks. One other possibility -- and I don't know if it's true or not -- is that the organization working on LSB is itself the problem. -- John
Bug#293510: ITP: missingpy -- Python interface and libraries for Haskell
Package: wnpp Severity: wishlist Owner: John Goerzen <[EMAIL PROTECTED]> * Package name: missingpy Version : 0.1.0 Upstream Author : John Goerzen <[EMAIL PROTECTED]> * URL : Not yet * License : GPL Description : Python interface and libraries for Haskell MissingPy is two things: . A Haskell binding for many C and Python libraries for tasks such as data compression, databases, etc. This can be found in the MissingPy module tree. . Also, it's a low-level Haskell binding to the Python interpreter to enable development of hybrid applications that use both environments. This can be found in the Python module tree. The Haskell bindings above use this environment. . MissingPy permits you to call Python code from Haskell. It does NOT permit you to call Haskell code from Python. . MissingPy is the companion to my MissingH library, and integrates with it. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#294818: ITP: haskelldb -- Haskell library for expressing database queries and operations
Package: wnpp Severity: wishlist * Package name: haskelldb Version : 0.9 + cvs Upstream Author : Daan Leijen and the HaskellDB development team * URL : haskelldb.sf.net * License : 3BSD Description : Haskell library for expressing database queries and operations HaskellDB is a Haskell library for expressing database queries and operations in a type safe and declarative way. HaskellDB compiles a relational algebra-like syntax into SQL, submits the operations to the database for processing, and returns the results as ordinary Haskell values. . HaskellDB is written entirely in Haskell. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: alpha Kernel: Linux 2.6.9-vs1.9.3 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
FW: A Call to Action in OASIS
- Forwarded message from Lawrence Rosen <[EMAIL PROTECTED]> - From: Lawrence Rosen <[EMAIL PROTECTED]> Date: Tue, 22 Feb 2005 09:36:47 -0800 Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: A Call to Action in OASIS A Call to Action in OASIS The free and open source software community has long demanded that industry standards be freely available to all to implement without patent or other licensing encumbrances. Open standards are essential for free software and open source to thrive. Now OASIS, a major industry consortium that produces e-business and Web services standards, has adopted a patent policy that threatens to undermine our development and licensing model. This patent policy (available, grouped together with other unrelated legal issues, in http://www.oasis-open.org/who/intellectualproperty.php) permits standards to be based upon so-called "reasonable and non-discriminatory" patent license terms--terms which invariably and unreasonably discriminate against open source and free software to the point of prohibiting them entirely. It would lead to the adoption of standards that cannot be implemented in open source and free software, that cannot be distributed under our licenses. While the policy includes a provision for royalty-free standards, it is a secondary option, which will have little effect if a few OASIS members with patents can ensure it is not used. The OASIS patent policy will encourage large patent holders to negotiate private arrangements among themselves, locking out all free software and open source developers. This is not a new issue for us. We fought hard for a royalty-free patent policy in W3C and encouraged that standards organization to commit its members to open standards. But some W3C member companies, steadfast opponents of software freedom, moved their efforts to OASIS. Without consulting the free software/open source community, they produced a patent policy designed so that we cannot live with it. We ask you to stand with us in opposition to the OASIS patent policy. Do not implement OASIS standards that aren't open. Demand that OASIS revise its policies. If you are an OASIS member, do not participate in any working group that allows encumbered standards that cannot be implemented in open source and free software. Please send email to [EMAIL PROTECTED] to indicate your support. We will forward your comments to the proper authorities at OASIS. If we stand united in opposition to this unacceptable patent policy, we can persuade OASIS to change it. /signed/ Lawrence Rosen Bruce Perens Richard Stallman Lawrence Lessig Eben Moglen Marten Mickos John Weathersby John Terpstra Tim O'Reilly Tony Stanco Don Marti Michael Tiemann Andrew Aitken Karen Copenhaver Doug Levin Dan Ravicher Larry Augustin Mitchell Kapor Russell Nelson Guido van Rossum Daniel Quinlan Murugan Pal Stuart Cohen Danese Cooper Eric Raymond Mark Webbink Ken Coar Doc Searls Brian Behlendorf ___ Spi-general mailing list [EMAIL PROTECTED] http://lists.spi-inc.org/cgi-bin/listinfo/spi-general - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote: > The much larger consequence of this meeting, however, has been the > crafting of a prospective release plan for etch. The release team and > the ftpmasters are mutually agreed that it is not sustainable to > continue making coordinated releases for as many architectures as sarge That makes sense. > Therefore, we're planning on not releasing most of the minor architectures > starting with etch. They will be released with sarge, with all that That doesn't. I see no problems with making an initial etch release consisting of whatever archs are ready, SCC or not. If a given arch later has a working etch distribution and installer, why not publish an etch release for it, even if it is on SCC? There are serious problems with unstable on some machines. Moreover, I haven't seen anything about the security implications of relegating so many archs to SCC, and to unstable-only status at that. > - the release architecture must have N+1 buildds where N is the number > required to keep up with the volume of uploaded packages > > - the value of N above must not be > 2 It seems to me that if an arch can keep up with builds, why impose this artificial restriction? > is freed up by moving the other architectures to scc.debian.org). > This will drastically reduce the architecture coordination required in > testing, giving us a more limber release process and (it is hoped) a > much shorter release cycle on the order of 12-18 months. That is a Good Thing. However, why eliminate out of hand the possibility of ever making stable releases for the other 7 archs? Even if they release later than those 4? > ftpmasters also intend to provide porter teams with the option of > releasing periodic (or not-so-periodic) per-architecture snapshots of > unstable. I'd rather see the option to produce the same per-architecture snapshot of testing as everyone else uses; that is, an etch release. > distributed via ftp.debian.org itself. The criterion for being distributed > from ftp.debian.org (and its mirrors) is roughly: > > - there must be a sufficient user base to justify inclusion on all > mirrors, defined as 10% of downloads over a sampled set of mirrors That will be a self-fulfilling prophecy, won't it? Fewer people would ever download a SCC arch, so how would it ever be possible for a SCC arch to break into ftp.debian.org? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote: > The much larger consequence of this meeting, however, has been the > crafting of a prospective release plan for etch. The release team and > the ftpmasters are mutually agreed that it is not sustainable to > continue making coordinated releases for as many architectures as sarge That makes sense. > Therefore, we're planning on not releasing most of the minor architectures > starting with etch. They will be released with sarge, with all that That doesn't. I see no problems with making an initial etch release consisting of whatever archs are ready, SCC or not. If a given arch later has a working etch distribution and installer, why not publish an etch release for it, even if it is on SCC? There are serious problems with unstable on some machines. Moreover, I haven't seen anything about the security implications of relegating so many archs to SCC, and to unstable-only status at that. > - the release architecture must have N+1 buildds where N is the number > required to keep up with the volume of uploaded packages > > - the value of N above must not be > 2 It seems to me that if an arch can keep up with builds, why impose this artificial restriction? > is freed up by moving the other architectures to scc.debian.org). > This will drastically reduce the architecture coordination required in > testing, giving us a more limber release process and (it is hoped) a > much shorter release cycle on the order of 12-18 months. That is a Good Thing. However, why eliminate out of hand the possibility of ever making stable releases for the other 7 archs? Even if they release later than those 4? > ftpmasters also intend to provide porter teams with the option of > releasing periodic (or not-so-periodic) per-architecture snapshots of > unstable. I'd rather see the option to produce the same per-architecture snapshot of testing as everyone else uses; that is, an etch release. > distributed via ftp.debian.org itself. The criterion for being distributed > from ftp.debian.org (and its mirrors) is roughly: > > - there must be a sufficient user base to justify inclusion on all > mirrors, defined as 10% of downloads over a sampled set of mirrors That will be a self-fulfilling prophecy, won't it? Fewer people would ever download a SCC arch, so how would it ever be possible for a SCC arch to break into ftp.debian.org? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 01:14:47AM -0800, Steve Langasek wrote: > > Why only unstable? In other words: will it be possible for scc arches to > > have a testing distribution? Obviously, this testing/arch will not > > influence the release candidate arch testing, but will allow real releases > > of scc-arches if a RM/release team steps up. > > (A popular question...) > > There are a few problems with trying to run testing for architectures > that aren't being kept in sync. First, if they're not being kept in > sync, it increases the number of matching source packages that we need > to keep around (which, as has been discussed, is already a problem); That makes sense, but it doesn't preclude, say, alpha making an etch release once the main 4-arch etch release is made. They'd use the same set of source packages as the main release, even if they didn't track testing along the way. When there are divergences, they should be small and minimal. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 10:49:20AM +0100, Thijs Kinkhorst wrote: > On Mon, March 14, 2005 10:10, Ingo Juergensmann said: > > It would be better when the project would be honest and state that it want > > to become a x86-compatible only distribution (with the small tribute to > > powerpc users) than this braindead thingie. > > The problems associated with carrying many archs have been well > demonstrated. This proposal is a way to address these problems. If you No, they haven't. The problems associated with carrying many archs *in precisely the manner Debian does* have been well demonstrated. Other projects -- for isntance, Gentoo and NetBSD -- have been able to do it sucessfully. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 11:31:56PM +1100, Hamish Moffatt wrote: > > A: "Oh, no release of Debian for Alpha... it's unsupported..." > > B: "Sad... it's a nice machine, but without a working Linux on it, we're > > gonna > > throw it away" > > It's unsupported officially, but unstable is still available. Ah, but we have always (rightly!) told end-users to avoid unstable because: a) it could be buggy b) it could be horribly broken at any given moment c) there may be no working installer d) there is no security support. These are showstoppers. > The porters could do their own release if they wished. And what, publish it on Alioth? Doesn't this bring about the same problems that amd64 on alioth has? > It would be interesting to hear how NetBSD/OpenBSD handles this > situation, as they have a lot of ports. (Of course they have far fewer > packages than we do so their problem is on a much smaller scale.) > Do they release new versions on all ports at once? Gentoo also has quite a lot of ports, and have quite a lot of packages, also. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 12:47:58PM +0100, Julien BLACHE wrote: > Basically, you're just leaving a number of Debian users out in the > cold. Users who choose Debian because we were the only distribution > out of there to provide serious support for the architectures they > care for, for various reasons. Indeed. I am one such user. I have always felt fortunate that I don't have to really care what architecture a machine is, because "of course it runs Debian". I have run Debian on Alpha, x86, amd64, powerpc, and sarc systems, both as a desktop and a server environment on most of these. Here's a key point: the utility of Debian on x86 is greatly diminished, for me, if I can't run Debian on alpha (or arch x) also. Why? Because having an environment that works exactly the same across multiple architectures is a Good Thing. If I will no longer be able to achieve that, then Debian on x86 becomes seriously less useful, because now I'll have to maintain some Debian machines and some Gentoo machines or something. It would be easier for me to just maintain all Gentoo machines. > I feel sad today, I feel it is a sad day for the Project. I agree, and I too am quite sad that a number of DPL candidates signed off on this without asking hard questions about it or even putting it out for discussion and feedback first. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 10:21:39AM -0500, Stephen Gran wrote: > So far as I can tell, the governing rule in Debian thus far has always > been that the people doing the work get to make the decisions about > their corner of the project. I don't see that that's going to change > any time soon, and I don't particularly think it should. This proposal > seems to be in that spirit, so why not try to address the parts you are > unhappy with, and keep doing the good work? Well, under this proposal, even if people do a lot of good work, they could be relegated to SCC for non-technical economic reasons (such as no new hardware being sold), and thus doomed to a slow, painful death in Debian. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 10:44:50AM -0500, David Nusinow wrote: > > Why? Because having an environment that works exactly the same across > > multiple architectures is a Good Thing. If I will no longer be able to > > achieve that, then Debian on x86 becomes seriously less useful, because > > now I'll have to maintain some Debian machines and some Gentoo machines > > or something. It would be easier for me to just maintain all Gentoo > > machines. > > I'm pretty amazed that people are saying that without being an FCC that their > arch will simply die. I don't understand why the porters, who've been so quick > to point out that they'll host and maintain buildd's, aren't willing to simply > track unstable and set up their own buildd network for their port. The m68k > guys did it. So did amd64. dak is now in the archive, and sbuild has been > there It is not unstable that I am (most) worried about. It is the lack of any possibility of a stable release that concerns me. Even if the people for a given arch were to build a stable etch, it would have no home in Debian, would suffer from being out of the loop on security updates, etc. > for ages. Quite frankly, I'll be shocked if m68k or anyone else doesn't make > their own etch release within days of the official one. That still doesn't solve the problem of security updates, for one, and archive space, for another. Now, having said that, some people have raised good points about the continued viability of unstable for these archs, namely the tendency of a number of maintainers to ignore arch-specific bugs until they become RC, and such. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 10:52:29AM -0500, Stephen Gran wrote: > Let me try to be clear. I am not necessarily in favor of dropping > arches. I am opposed to having portability issues make new releases > drag on forever, and slowing security releases. We have been told I am too. I have no objection to releasing security updates for the 4 "main" archs with announcements, and the rest as soon as they're compiled (which should be just about as soon for most). I also have no objection to releasing stable later on some archs, or not at all, of nobody from those archs works to do it. I do object to preventing those archs from releasing stable, and from being supported at all by the security infrastructure. > The only real showstopper for some of the slower arches is that they > take too long to compile some of the bigger packages, and that slows > down getting security upgrades out the door. I was under the impression I also have no objection to simply releasing security notices immediately, and posting .debs for each arch as they become available. m68k users will just have to deal with the fact of life that it could take a couple of days to get their updates. But the proposal as given takes a far more draconian approach. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: COUNT(buildd) IN (2,3) (was: Re: Bits (Nybbles?) from the Vancouver release team meeting)
On Mon, Mar 14, 2005 at 05:03:30PM +0100, David Schmitt wrote: > Thus the problem is less in the development and more in the support of > testing > requirements (all arches in sync) and stable support (security response > time). Therefore the N<=2 requirement is only needed for tier-1 arches but > not for the tier-2 which will not officially release a stable. Why can we just not relax these requirements, and m68k people get their kde security updates 12 days after everyone else does, because that is a fact of life on m68k? Moreover, perhaps we ought to rethink the "all arches in sync" rules for testing a bit; maybe it's OK if some archs aren't in sync. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 01:23:43PM -0500, David Nusinow wrote: > > >Not necessarily. I imagine it such that the porters set up their own pull > > >from > > >unstable, the same way amd64 does now. They can set up testing themselves > > >(remember, dak is in the archive now) so they can run their own testing in > > >parallel to the mainline one. > > What a huge waste of manpower, done seven times in a row. > > Hopefully not that huge, as the tools have already been written. Perhaps there > can be a single package pool for all SCC/Tier-2 arches so it only has to be > done once. You know, the irony in all this is that the effort required to support these SCC archs is greater than what would have been required to support a non-free section outside of ftp.debian.org. It seems that we find it easier to remove Free software from our archive than non-free. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions for the DPL candidates
On Tue, Mar 15, 2005 at 08:35:26AM +1000, Anthony Towns wrote: > everyone), we chatted about the topic and came to the opinion that > removing a bunch of architectures from being release candidates would be > necessary -- for reasons I hope are adequately explained in the > announcement, or that will be on -devel as people ask. As it turned out, Thus far I follow, and don't have a major objection. > when we got to the actual meeting the next day, this was more or less > exactly what Steve was wanting to propose, and he seemed to be expecting > most of the objections to come from James, Ryan and/or me. So instead of > that, we then spent a fair while discussing criteria for what support > architectures would/should receive. And the result of this discussion is what leaves me with great concern. Specifically, the proposal: 1) Provides no way for an arch to produce a stable release after the initial set of archs have produced theirs; 2) Provides no way for such a stable release to be integrated into the security build system; 3) Provides no rationale for the N<=2 buildd's requirement, other than that long builds delay security updates, and that is a silly rationale since initial updates could just be made without those archs; 4) Harms the efforts of porters to get their fixes into proper Debian source packages by causing brokenness on those archs to no longer be RC; 5) Harms the overall usefulness on Debian on the archs that are still supported by making their stable environment no longer available on other archs in the same organization. By far, #1 and #2 are the most critical to me. It is hard for me to see how this proposal is anything but "dropping 7 archs" given those two problems. It seems almost a sham to present it as anything else, and to think that unstable snapshots is a sufficient replacement for stable releases. If that is the case, then why not use that instead of stable releases for all archs? > I don't think that's actually such a problem; in this case there really > just aren't so many alternatives, and as frustrating as that is for the It seems that there are plenty of simpler fixes for the individual problems, for instance: 1) For the mirror space problems: not requiring all mirrors to carry all archs 2) For the security delay problem: not requiring all security builds to be available at once 3) For the release problem: not requiring all archs to release at once > que sera sera. And given the plan is to give porters fairly complete > control over their architecture in unstable, rather than necessarily > expecting it to be synced with i386; and to provide a snapshot facility I think losing sync in unstable is a bad thing, and not desirable. Note that I do not view any arch as being "synced with i386"; all archs should be synced with each other, and not everyone uses i386 as their development platform. > Personally, I'd much rather worry about the technical side of things and > let the "But you didn't follow procedure / respect my feelings" side of > thing slide; personally, I think the best way of feeling good when > working on a technical project is to get the technology right. Agreed. But like you said, this was handled sub-optimally and I'm not surprised at the resulting reactions. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tue, Mar 15, 2005 at 08:50:04AM +1000, Anthony Towns wrote: > What that actually means is that when porters want to stabilise, they'll > be able to simply stop autobuilding unstable, fix any remaining problems > that are a major concern, and request a snapshot be done. That'll result > in a new "snapshot-20050732/main/binary-foo" tree matching the work in > unstable and a corresponding source tree; at which point CDs/DVDs can be > burnt from the snapshot, and unstable development can continue. That > tree will persist for a while, depending on how much archive space it > takes up. So, let's say I'm maintaining Debian boxes from 5 different archs, and want the closest thing to stable on each one. There is no longer going to be any such thing as a standard Debian installation. Each box, and each snapshot, could have different versions of important packages -- everything from glibc to KDE or Gnome. The user experience will be different, the security updates -- if they exist -- will be different, effect different packages, and bear different versions. Not to mention that all of these are different than the real stable release. In short, an administration nightmare worse than Gentoo. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 03:57:40PM -0800, Steve Langasek wrote: > On Mon, Mar 14, 2005 at 10:06:35AM -0600, John Goerzen wrote: > > > I have no objection to releasing security updates for the 4 "main" archs > > with announcements, and the rest as soon as they're compiled (which > > should be just about as soon for most). > > > I also have no objection to releasing stable later on some archs, or not > > at all, of nobody from those archs works to do it. > > > I do object to preventing those archs from releasing stable, and from > > being supported at all by the security infrastructure. > > Please clarify what you think a late-releasing stable arch is going to > look like, in contrast to what has been proposed, given that keeping > release architectures in sync is the only thing we have that guarantees > the sources in testing (and therefore in stable) are in a releasable > state for each of those architectures. I'm not sure I quite understand the question. I don't believe that the proposal as given provides any way for a SCC arch to produce a real stable release, with security support and the same versions of packages as everything else. You are right; there are challenges and in many ways it is a regression from what we have now, but it is not as serious of one. If the state of stable, as a source distribution, is not satisfactory for a given arch, they have a couple of options: 1) binary-only NMUs if it is solely a build environment problem 2) careful, minimal diffs to be applied in stable and included with the next point release 3) their own source repo containing the packages that have changed, hoping that this set is minimal -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tue, Mar 15, 2005 at 11:46:51AM +1100, Matthew Palmer wrote: > On Mon, Mar 14, 2005 at 04:27:50PM +0100, Matthias Urlichs wrote: > > If I had to think of a rationale for it, the only one I could think of > > would be "the architecture needs to be fast enough not to block security > > updates". > > > > However, I consider an update whose $ARCH binaries are released a week > > later not to be a problem. > > I think a lot of users would consider it a problem. Imagine, would you be > happy with a highly visible public announcement of every vulnerability > against your servers, a week before you got the fix? If I'm running m68k, I probably wouldn't care so much, and besides -- Debian security announcements are rarely the first highly visible public announcement of a vulnerability. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SCC proposal (was: Re: Questions for the DPL candidates)
On Tue, Mar 15, 2005 at 10:02:37AM +1000, Anthony Towns wrote: > >And the result of this discussion is what leaves me with great concern. > >Specifically, the proposal: > > 1) Provides no way for an arch to produce a stable release after the > >initial set of archs have produced theirs; > > Halting unstable autobuilding, fixing remaining bugs in an arch-specific > freeze, then making a snapshot allows you to produce a release. It may > or may not correspond with Debian stable. Simply making a snapshot -- or posting a set of .debs -- does not make Debian stable. See #2, for instance. > > 2) Provides no way for such a stable release to be integrated into the > >security build system; > > That's a feature, not a bug: the security team have had ongoing > difficulties supporting all those architectures. If there are people > willing to do security support for particular architectures, then I'm > sure they'll have somewhere to upload to. The most difficult ones I've heard of are the time it takes to build on some archs, which seems rather silly; just release the announcement when you have whatever set of main .debs ready and the others can build from source if they don't want to wait. Really, I don't really understand all the difficulty of running apt-get -b source, or pbuilder, or some such for n+1 archs as opposed to just n. With a little use of ssh keys, the whole thing should be completely automated. And I thought that's basically what the security team does, anyway. If we keep them with a useable machine (which DOES make sense as a requirement), then where is the issue? I am not even opposed to building security updates from source if I must. However, the SCC idea seems to negate that, since their source may no longer be the same as the official source due to per-arch fixes. Not to mention that the SCC archs will *always* have later security updates under this proposal, because they don't have access to the same early warning that the official security team does. > > 4) Harms the efforts of porters to get their fixes into proper Debian > >source packages by causing brokenness on those archs to no longer > >be RC; > > Which is to say "We don't get to use the release team to make other > people do our bidding". Big deal, just because something isn't RC > doesn't mean it's not a bug and shouldn't be fixed. I agree. The unfortunate reality -- documented elsewhere in this thread, even -- is that a disturbing set of maintainers simply don't invest time to fix arch problems otherwise, even if patches are supplied. Unless we broaden NMU powers to permit NMUing of packages for serious per-arch bugs when the maintainers are unresponsive, I think this is a problem we must deal with. Perhaps it is worth time revisiting the maintainer-as-a-fiefdom model. > >3) For the release problem: not requiring all archs to release at once > > Uh, that's what we're doing. No, you're not permitting most archs to release at all. That is different from allowing them to release, but at different times. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SCC proposal (was: Re: Questions for the DPL candidates)
On Mon, Mar 14, 2005 at 08:14:47PM -0500, Daniel Jacobowitz wrote: > On Mon, Mar 14, 2005 at 07:02:05PM -0600, John Goerzen wrote: > > Really, I don't really understand all the difficulty of running > > apt-get -b source, or pbuilder, or some such for n+1 archs as opposed > > to just n. With a little use of ssh keys, the whole thing should be > > completely automated. And I thought that's basically what the > > security team does, anyway. If we keep them with a useable machine > > (which DOES make sense as a requirement), then where is the issue? > > How often this works, however, is the problem. The source may not > build cleanly everywhere. Some dependency may be broken, or not > install properly in the build daemon, or so forth. Is not this supposed to be fixed before a package ever enters testing, let alone stable? > For security updates, using a separate pbuilder infrastructure instead > of the buildd infrastructure is an interesting idea. I am not sure > whether it would be workable. If someone wanted to try it, and > coordinate with the buildd admins and security team about it, we could > find out. I think it would be easier in some ways, since it is easier to make this scriptable -- that is, do x with the .debs when they're building, or y if they fail. > > Not to mention that the SCC archs will *always* have later security > > updates under this proposal, because they don't have access to the > > same early warning that the official security team does. > > This isn't a useful objection. The security team could add additional > members focusing on SCC; if there are a small number of responsible, > interested developers, then there is no reason not to. The current > members aren't magical. OK. Assuming that they are open to that. I have no reason to assume either way, I guess. > > No, you're not permitting most archs to release at all. > > > > That is different from allowing them to release, but at different > > times. > > As I read it, they are allowed to release - but they have to do their > own release management. Well, the proposal as given is for snapshots of unstable, making no provision for stable (or frozen)... > I think what this is crying out for is a second testing setup, covering Perhaps, but then why not just use the existing testing setup? By this time, we are basically down to the same setup as we have now, with simply different release times and security procedures per archive. Wouldn't it be easier to make those policy changes, along with not requiring mirrors to carry all archs, than to do this whole SCC thing? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Alternative: Source-Centric Approach [w/code]
As I have been reading the discussions about the SCC proposal for etch, it seems that these are the main problems: 1) Difficulty with, and speed of, buildd systems 2) Difficulty of syncing testing across all archs given #1 3) Difficulty getting security releases out in time, given slow archs 4) Space constraints on mirrors I'm throwing out a different idea, and I'm backing it up with code. I have thought about it some, maybe there are huge holes, but let's see. I propose that we split things along these lines: binary+source (B+S) archs and source-only (SO) archs. B+S archs will be essentially like we have now -- .debs and sources for every package in Debian are available. SO archs will be handled exactly like we do now, EXCEPT that we will not distribute .debs for most packages. I expect that we will distribute .debs for base and build-essential, mainly -- the minimum someone needs to install a working system and build more packages. What will that mean for our problems? The speed of buildd systems mostly becomes irrelevant. They will still have to keep up with base (the set of .debs that we do distribute for a SO arch). Anything past that is there just for QA purposes -- to make sure packages are buildable on these archs, and would be optional. The problem of syncing with testing is also reduced; now we need only make sure base is synced across archs. The problem of getting security releases out in time is also reduced; source packages are enough for these archs. If there's a hole in a base package, we'd want to provide .debs for everyone, but these packages aren't going to be the KDE-style mammoth ones. And finally, this would be a huge win for mirrors. We would have far fewer space constraints, and adding a new arch would be easier. What would this mean for users? Basically, packages install slower on these archs. I have developed a demonstration tool called srcinst, available from http://people.debian.org/~jgoerzen/srcinst/. srcinst is capable of filling all of a package's dependencies and build-depencies solely from source. It will use apt-get -b source to build .debs, then evaluate (and build, if necessary) their deps, then install them with dpkg -i. In short, very similar to apt-get install, except it never downloads a .deb from anywhere for any reason. (Most other tools don't go this far, and still require .deb downloads for build-deps, or don't handle deps at all) This gives us the benefits of smaller mirror infrastructure that projects like Gentoo have, while still maintaining all the advantages of dpkg/apt. What are some downsides? I can see a few: * Longer package install times, obviously * Difficulty of dealing with dependency loops (possible solution: include one .deb from each loop in the dist) * Disk space requirements to build packages More on srcinst: Here's an example for epic4, which looks like this: Depends: libc6 (>= 2.3.2.ds1-4), libncurses5 (>= 5.4-1), libssl0.9.7, epic4-help (>= 1:1.1.7.20020907) Build-Depends: debhelper (>= 3.4.8), libncurses5-dev, libssl-dev Let's assume I have libssl-dev installed and libc6 installed, but no ncurses5. So, I run "srcinst install epic4". Here's what it does: 1. Looks at the build-depends, sees that we are missing libncurses5-dev. So: a. Grab and build the source package corresponding to libncurses5-dev. b. Examine the deps in libncurses5-dev.deb. Notice that it deps on libncurses5 (which we just built), so dkpg -i libncurses5 and then dpkg -i libncurses5-dev. 2. Build epic4 itself. 3. Look at the deps in the epic4 .deb. Notice that it deps on epic4-help. 4. Build and install epic4-help. 5. Install epic4. The srcinst code is very hackish, ugly, and quick. I just wrote it since yesterday as a proof of concept. So: * Make sure yuo rnu it as root (no support for fakeroot/sudo yet) * It can't resolve dep loops * It can't handle !arch strings in deps accurately * It spews debugging info to stdout * It uses /var/cache/srcinst for its working area. Make sure /var is free enough. So, what do you think? Could this work? -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Alternative: Source-Centric Approach [w/code]
On Tue, Mar 15, 2005 at 06:42:32PM +0100, Lech Karol Paw?aszek wrote: > On Tuesday 15 of March 2005 18:25, John Goerzen wrote: > [...] > > More on srcinst: > [...] > > So, what do you think? Could this work? > > What's a difference between srcinst and apt-build ? ;-) egrep 'apt-get.*install' apt-build | wc -l 8 egrep -r 'apt-get.*install' srcinst | wc -l 0 IOW, apt-build still requires pre-built binary .debs in order to work. srcinst does not. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Alternative: Source-Centric Approach [w/code]
On Tue, Mar 15, 2005 at 06:57:00PM +0100, Matthias Urlichs wrote: > Hi, John Goerzen wrote: > > > 1) Difficulty with, and speed of, buildd systems > > > > 2) Difficulty of syncing testing across all archs given #1 > > 2a) Bugs on "small" arch which blocks testing migration of "big" arch > > There are not many people who can do in-depth debugging on most small > architectures, arch-specific gcc internals are less-well exercised and > therefore more buggy, just recompiling gcc is a problem ... Granted, gcc and libc can cause an inordinate amount of trouble there. But in almost every other case, a bug in a "small" arch is a genuine bug in the program that should be fixed, and usually is not exceptionally hard to find. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Alternative: Source-Centric Approach [w/code]
On Tue, Mar 15, 2005 at 07:46:23PM +0100, Adrian Bunk wrote: > > don't handle deps at all) > >... > > So, what do you think? Could this work? > > Yes, this could work. > That's what Gentoo is good at. [ snip ] > Your priority are your users, and if Debian has decided to focus only on > some key architectures it would be the best for them to help them > switching to Gentoo instead of hacking Debian to become some cheap > Gentoo clone for most architectures. I don't view this as being a cheap Gentoo clone. In fact, I view srcinst as being the Gentoo idea, done right. Gentoo has a lot of problems, especially relating to difficult upgrades. Because of our superior packaging system, we are in a great position to hit the ground running and, with a little help from something like srcinst, come up with something that works -- and works better than Gentoo -- in a short amount of time. > If the Debian developers intereested in the ports Debian intends to drop > would switch to Gentoo for helping Gentoo to support all of their > architectures and for providing easy Debian -> Gentoo transition paths > this would serve your users better. Yes, but I hope that this proposal, or other suggestions, can help us avoid dropping ports. This specific proposal, for instance, is meant to provide us with a way forward that addresses the main concerns while still producing a quality, usable result for our users. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Alternative: Source-Centric Approach [w/code]
On Tue, Mar 15, 2005 at 12:53:31PM -0800, Marc Singer wrote: > > Yes, but I hope that this proposal, or other suggestions, can help us > > avoid dropping ports. This specific proposal, for instance, is meant to > > provide us with a way forward that addresses the main concerns while > > still producing a quality, usable result for our users. > > ...and may encourage development of new architectures as the overhead > for each would be much smaller. Exactly. If we were doing this, there would have been no reason to keep amd64 out of sarge, for instance. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Alternative: Source-Centric Approach [w/code]
On Tue, Mar 15, 2005 at 10:45:45PM +0100, Ola Lundqvist wrote: > Hello > > > distribute for a SO arch). Anything past that is there just for QA > > purposes -- to make sure packages are buildable on these archs, and > > would be optional. > > This is the problem. How do you make sure that the package is buildable > on the architecture without building it? And if you have built it why not Well, how do you make sure that the package is runnable on the architecture without running it? Yes, it's a bit less testing, but OTOH, if nobody notices that the package can't be installed, that says something. > > The problem of syncing with testing is also reduced; now we need only > > make sure base is synced across archs. > > What you really are saying that for some arches we only support base > and essential (and some more). Everything else is provided as source debs > and not supported, even if it might work. I mean the source is available > currently and the only thing you say is that we should only build some > parts of that port. No, I'm not commenting on suport. I'm just commenting on what .debs are out there and autobuilt. I want everything else to stay the same. However, the job of supporting n archs for things like security updates is reduced to the job of supporting 1 source package. > > * Difficulty of dealing with dependency loops > >(possible solution: include one .deb from each loop in the dist) > > > > * Disk space requirements to build packages > > * Not possible to tell if a package is buildable on a specific arch or not. ^ in advance Yes, that is a downside. > > So, what do you think? Could this work? > > Nice idea, but I do not really see the benefit, more than on ftp disk space > and security update speed. Also with the testing synchronization. But then, these three are the main problems we've been told about, right? :-) -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Alternative: Source-Centric Approach [w/code]
On Tue, Mar 15, 2005 at 11:14:50PM +0100, Matthias Urlichs wrote: > Hi, John Goerzen wrote: > > > This specific proposal, for instance, is meant to > > provide us with a way forward that addresses the main concerns while > > still producing a quality, usable result for our users. > > It won't work that well for slower architectures, for the very simple > reason that compiling everything would take a long time. It may be that m68k is one arch that should ship with .debs, for this very reason. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting
On Wed, Mar 16, 2005 at 12:09:08PM +1000, Anthony Towns wrote: > >>- the Debian System Administrators (DSA) must be willing to support > >> debian.org machine(s) of that architecture > >I assume people can help with this too, or? > > Doing DSA work involves more than having root on a random box on the > internet. It's a specific task, not something that every developer is > already doing under a different title. I would say that it would also be more than telling people why they can't do it. Perhaps it would be better to tell people what these tasks are, so they know whether or not they'd be qualified, and could gain experience? -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#344913: ITP: hdbc -- Haskell Database Connectivity
Package: wnpp Severity: wishlist Owner: John Goerzen <[EMAIL PROTECTED]> * Package name: hdbc Version : 0.99.0 Upstream Author : John Goerzen * URL : darcs get --partial http://darcs.complete.org/hdbc * License : LGPL Description : Haskell Database Connectivity I intend to package the HDBC packages I am working on, with the following source package names: hdbc: Generic interface and utilities hdbc-postgresql: PostgreSQL driver hdbc-sqlite3: Sqlite v3 driver hdbc-missingh: Makes any HDBC database a backend for AnyDBM in MissingH Future packages will follow as additional drivers are written. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.12-rc4-mm2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Archive architecture qualification
On Thu, Dec 29, 2005 at 03:32:43AM +1000, Anthony Towns wrote: > > Anyway, that's the general idea; hopefully it'll become clearer > later. Given release architectures have de-facto requalified, candidates > for archive (re)qualification are ttbomk: > > * arm, m68k, s390, sparc > * amd64, armeb > * hurd-i386, hurd-powerpc > * *bsd-i386 > * opensolaris Does this mean that archs not listed (such as alpha, i386, and powerpc) are already qualified? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Honesty in Debian (was Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Mon, Feb 13, 2006 at 09:22:07AM +0100, Sven Luther wrote: > I want to remind you all, that previous to the two GRs which clarified the > meaning of what we must consider free, we had a widely disputed GR on the fate > of our non-free section, and we all voted to keep it, especially because there > was non-free software (including firmware, documentation and whatever), which > was non-free but useful to our users, and we decided to keep it accordying to > our social contract which put our users and free software on equal level. That's not correct. The project simply voted not to removed it at that time, by defeating the GR. There was no affirmative vote to keep non-free as far as I can remember. The amendment that passed was a no-op that basically said that the status quo remains. Not only that, but there were people that voted to abolish non-free, so to state that "we all voted to keep it" is erroneous. > If we now decide to put all this non-free software into main, as some are > starting to think doing about kernel firmware, documentation, fonts, whatever, > then i believe not only is the vote on keeping free meaningless, but we are > also not being honest with ourselves and our users, as this is in > contradiction with the spirit of the social contract, even if some like to > play with words. I agree with that. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Honesty in Debian (was Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Mon, Feb 13, 2006 at 03:57:01PM +0100, Sven Luther wrote: > On Mon, Feb 13, 2006 at 08:35:02AM -0600, John Goerzen wrote: > > That's not correct. The project simply voted not to removed it at that > > time, by defeating the GR. There was no affirmative vote to keep > > non-free as far as I can remember. The amendment that passed was > > a no-op that basically said that the status quo remains. > > So, you simply discount the 100 or 1000s of email that preceded that vote, and > all the argumentation against removing non-free, how convenient. I don't see what that has to do with the simple fact of what the vote was about and how it turned out. > The status quo in our voting system would have been none-of-the-above, so > there > was clearly a choice to keep non-free, if i remember well. That choice didn't express a prohibition on removing it, it was just an effort to keep the question to arising again in the short term. It was pretty successful at that. > > Not only that, but there were people that voted to abolish non-free, so > > to state that "we all voted to keep it" is erroneous. > > We did all vote, and the result of that vote was to keep non-free, and the Well, that's not correct either. A minority of developers voted, if I remember correctly. Some 350 or so. But when you said "we all voted to keep it", that is incorrect. The vote was not unanimous. I believe that about a third of those voting wanted to remove it. > result of the vote are thus binding on the debian project as a whole (until > the next GR about this topic that is). I'm not saying that the vote was invalid or anything. All I'm saying is that it wasn't unanimous as you had said. There was disagreement at the time. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Honesty in Debian (was Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Mon, Feb 13, 2006 at 04:35:31PM +0100, Sven Luther wrote: > On Mon, Feb 13, 2006 at 09:23:41AM -0600, John Goerzen wrote: > > I don't see what that has to do with the simple fact of what the vote > > was about and how it turned out. > > So, you think that the vote in itself is the important one, and that all the > discussion that leads upto it can simply be ignored ? So, you dismiss the I don't think the discussion is useless, no. I also don't think it has any relevance in the context of your original post, and it certainly has no relevance in the context of a discussion about whether a vote was unanimous. > > > The status quo in our voting system would have been none-of-the-above, so > > > there > > > was clearly a choice to keep non-free, if i remember well. > > > > That choice didn't express a prohibition on removing it, it was just an > > effort to keep the question to arising again in the short term. It was > > pretty successful at that. > > So, you claim that we didn't vote to keep non-free ? Kind of revisionism. It's not revisionism. Read the amendment that was supported. It was to "reaffirm support for non-free." It was not to "prevent non-free from ever being removed." The proposal to remove non-free was defeated, yes. There was an amendment, which was accepted, stating that we still support non-free, but which caused no actual change in policy or to the project. In other words, it was a no-op, simply a "sense of the developers" resolution that didn't cause any action to take place or affect any change in policy. There was not an affirmative statement saying that non-free will never go away, or that it will never go away until the next GR. > > > We did all vote, and the result of that vote was to keep non-free, and the > > > > Well, that's not correct either. A minority of developers voted, if I > > remember correctly. Some 350 or so. > > Those that did vote did vote, and the result of that vote was to keep > non-free. Those who did chose not to vote, did indeed chose so, but the result > of the vote is not less binding on them because of that. That is true. But it remains that it is incorrect to say that "we did *ALL* vote", because not all of us did vote. Only a subset of us did. > > But when you said "we all voted to keep it", that is incorrect. The > > vote was not unanimous. I believe that about a third of those voting > > wanted to remove it. > > So, what ? We did vote, the majority of the voters did vote to keep non-free, > so the this means that we, the debian-project, did chos to keep non-free. You said "we *ALL* voted to keep it", which means that every vote cast was to keep non-free. In other words, the vote was unanimous. It is quite clear that the vote was not unanimous, and you can see for yourself that there was dissent in the discussion leading up to the vote. That is all I am saying. The vote was not unanimous, and it was not to take any affirmative steps to alter not status of non-free. We didn't vote to keep non-free forever. We voted not to remove it. > > I'm not saying that the vote was invalid or anything. All I'm saying is > > that it wasn't unanimous as you had said. There was disagreement at the > > time. > > Sure, there is always disagreement, all i said is that the debian project > voted in a GR, and that the result of that vote was that we should keep > non-free. It is i believe quite valid to translate this above fact into the > much shorter "we voted to keep non-free" sentence, and i really don't see what You added the word *ALL* there, which made it incorrect, because you were saying that *everyone* voted in that way. This is not the case. > you aim to achieve by this arguing ? Playing with words to distract from the > content of my post ? nit-picking just for the fun of it ? I said that I agreed with what you said later. I was just correcting the record, that's all. The vote was not unanimous, and it did not result in any affirmative actions or policy changes regarding non-free. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. 7zip. Again.
On Wed, Feb 15, 2006 at 06:45:21PM +0100, Eduard Bloch wrote: > #include > * Lars Wirzenius [Wed, Feb 15 2006, 10:42:02AM]: > > > (Once we use .tar.bz2, the sizes will be even smaller.) > > I cannot remember a clear consens from the "Size matters" thread, and > IMO we should go for 7zip at least for source packages. There are a lot of problems with 7zip. They continue to fix various segfault bugs. It is rather windows-centric in its approach in many ways. They've recently added support for symlinks and file permission bits, and still don't support storing of uid/gid. You can probably pretty much forget storage of hard links and sparse files. I wouldn't be surprised to find various security bugs that have been long-since fixed in tar, such as unpacking files with names such as ../../../etc/passwd or whatnot. You may say that some of these don't matter for source archives. That is true to a certain extent, but security does matter there still. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#354269: ITP: libghc6-http-dev -- GHC 6 libraries for the Haskell HTTP client library
On Fri, Feb 24, 2006 at 02:09:14PM -0800, Charles Stevenson wrote: > * Package name: libghc6-http-dev This already exists in unstable. See http://packages.qa.debian.org/h/haskell-http.html Also, libghc6-http-dev is not an appropriate source package. And finaly, I am concerned that you don't intend to build Hugs versions for these Haskell packages you are ITPing. libhugs-http exists in unstable already, so there is no technical reason to avoid it. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Man-Db and Man both in Frozen???
Hi, There appears to be a package "man" in frozen that shouldn't be there since man-db is the new name for that package. Somebody needs to take it out; otherwise, it is confusing to users. John -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Man-Db and Man both in Frozen???
On May 30, Fabrizio Polacco wrote: > Where is it? > I've just looked both in ftp.debian.org and in master, but man_ is only > in rexx . > > Or maybe it has been just removed? Hmm, either that or we are looking at a bug in dselect herebecause it certainly was in the package list when I upgraded a few days ago. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Copyright question
A program I am packaging has a copying policy as follows: Only NON-COMMERCIAL distribution allowed. Redistribution of modified versions by other people than myself is not allowed. However, commercial use is no problem as long as the software is NOT being commercially distributed. Please send your contributions, bugreports, hints etc. to the author. Thanks ! Should this go in contrib or non-free? -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Copyright question
Christian Schwarz <[EMAIL PROTECTED]> writes: > On Sun, 1 Jun 1997, joost witteveen wrote: > > > Non-free it is > > No. If the author forbids distribution a changed (i.e. bug fixed) > _binary_ version, I think the package may not even go into non-free. > > What do the others think? Before we go off half-cocked here: 1) I have e-mailed the author asking for permission to distribute a bug-fixed software 2) We are distributing various programs without source already. These programs are not fixable. (Example: xforms) I really don't think that we should make lack of modification permission to be a reason to not include in non-free (after all, isn't this what non-free is for?) -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Proper section?
What is the proper section for Perl modules? Should they go into devel, interpreters, libs, what? I am a little confused about this since Perl modules kinda fit the descriptions for all of those. -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: anyone working on updating mgetty?
I am the previous maintainer of mgetty (and the maintainer on file in the latest version.) I had given it to Siggy Brentrup because I didn't have time to maintain it anymore. Siggy then had a fire and was unable to develop it for some time. About 1 - 1.5 months ago, he told me he would have a new version out in 2 weeks. I have not heard from him since. I did send him an e-mail a few days ago regarding this but did not hear back from him yet. I would advise somebody to contact Siggy ([EMAIL PROTECTED] if memory serves), and if there is no reply, consider the package yours. (Although, please send me an e-mail regarding this so that I know that it is being taken care of...) I am sending a CC of this message to Siggy. Heiko Schlittermann <[EMAIL PROTECTED]> writes: > [1 ] > On Jun 2, Paul Haggart wrote > : > : Mgetty is quite a few versions behind.. is anyone actively maintaining > this > : package? If not, I have enough free time now to take it. > : > > I thought about it, but didn't manage it. (Since I'd have to remove > all debmake stuff ...) And first I should finish the wu-ftpd and/or the > wu-ftpd-academ ... > > > > Heiko > -- > email : [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > pgp : A1 7D F6 7B 69 73 48 35 E1 DE 21 A7 A8 9A 77 92 > finger: [EMAIL PROTECTED] [EMAIL PROTECTED] > > > [2 ] > -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Copyright question
[EMAIL PROTECTED] (Bruce Perens) writes: > From: Enrique Zanardi <[EMAIL PROTECTED]> > > Only NON-COMMERCIAL distribution allowed. > > That puts it in non-free. OK, I have gotten some replies from the author regarding copyright issues. Does it still belong in non-free? (It appears his intent is basically to keep companies from charging for it...) Below is the copyright file I'm distributing with it: This package was debianized by John Goerzen [EMAIL PROTECTED] on Sat, 31 May 1997 13:05:05 -0500. It was downloaded from ta.twi.tudelft.nl/pub/dv/lemmens. [ Note: Debian currently doesn't have a msql2 package (msql2 is still in beta), so an older version of Xsqlmenu is distributed here. Once msql2 is Debianized, I'll package the newer Xsqlmenu. ] CD-ROM MANUFACTURERS: It may be permissible for you to distribute this on CD depending on how much you charge; see below. Author's Stated Copyright: -- Only NON-COMMERCIAL distribution allowed. Redistribution of modified versions by other people than myself is not allowed. However, commercial use is no problem as long as the software is NOT being commercially distributed. Please send your contributions, bugreports, hints etc. to the author. Thanks ! Debian Changes -- I have modified the code to work with XForms 0.86. I have also fixed one small logic bug. Altogether, about 5 lines of code have changed. You can get the diff file from ftp.debian.org in the source area. E-Mails From Author (irrelevant portions deleted) --- From: Kees Lemmens <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] (John Goerzen) Date: Tue, 3 Jun 1997 09:25:23 +0200 (METDST) Message-Id: <[EMAIL PROTECTED]> Hi John, > > Before I reply to your message, I have one more question. Is it OK > for CD-ROM manufacturers to distribute Xsqlmenu on the Debian CD-ROMs > that they make? Yep, as long as the CDROM's are sold for reasonable prices: all software on these distributions is free, so they only should be paid for their efforts to put it on the CD's. I think a maximum of approx. 20-25 $ could be tolerated imo. If the prices get higher, they really are going to make illegal profit of the work of people who intended software to be free and who for that reason don't charge any money for it and that is something that should be avoided if you ask me. (did you ? :-)) On the other hand: I wouldn't know how to fight people that clearly violate these unwritten rules. ------- From: Kees Lemmens <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] (John Goerzen) Date: Sun, 1 Jun 1997 22:51:29 +0200 (METDST) Message-Id: <[EMAIL PROTECTED]> No problem adding the package to Debian (Red-Hat would be another thing) ------- From: Kees Lemmens <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] (John Goerzen) Date: Mon, 2 Jun 1997 09:23:08 +0200 (METDST) Message-Id: <[EMAIL PROTECTED]> Ok, now I see the point ! if you want to ship with msql 1, then it is OK to me to if you pack your patched version: no problem whatsoever ! But maybe you could refer to the new msql2 version ? --- -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] |
Possible Xaw{3d,95} bug / Re: Debian freeciv bugs
After extensive testing, some code rewriting, etc., I finally have determined that this problem only occurs when using Xaw3d or Xaw95. I am CCing this message to the relevant maintainers. (Xaw maintainers: package freeciv-1.0j that is in hamm causes coredump under Xaw3d and Xaw95 but not the standard widget set). I don't know which package is causing this... [EMAIL PROTECTED] (Karl Sackett) writes: > John Goerzen writes: > > > > Well, I don't know if the new server coredumps. But the new client > > coredumps every time I load it. > > > > I'll have to punt on this one. Send a copy of the core dump to the > FreeCiv team at [EMAIL PROTECTED] I've never had any coredumping > when I've test the package, so I don't know where to start looking for > your problem. > > I got a reply back from them on your "Rock Band" problem. They'll > work on it. > > > -- > Karl Sackett[EMAIL PROTECTED] > > "I have sworn upon the altar of God eternal hostility against every form > of tyranny over the mind of man." -- Thomas Jefferson > -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report
Andreas Jellinghaus <[EMAIL PROTECTED]> writes: > i'm missing the same thing: debian should have a database with error > reports and how to fix them. every big bug should be documented (we had > this bud , and you can solve it this way : . it's > also fixed in the new release debian and in the package xyz > ."). Perhaps this is something that gnats can be used for. I know FreeBSD is using gnats in this way. -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
mgetty Needs Maintainer!
Hello, Some time ago, I handed mgetty over to Siggy Brentrup. However, I have not yet seen any mgetty uploaded by him and have not received any response to my e-mails. So...would somebody be willing to take over mgetty? Right now, it doesn't have any maintainer... -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Postgres95/PostgreSQL
Back in March, Siggy had indicated that he would be taking over PostgreSQL development (the Postgres95 package currently in Debian is now very out-of-date). I e-mailed him about this and got no response. So...is anybody out there planning to take over PostgreSQL? If not, I can take a look at it. If it will require a tremendous amount of time, I probably won't be able to do it; otherwise, I can give it a try. John -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: mgetty Needs Maintainer!
[EMAIL PROTECTED] (Martin Schulze) writes: > Hmm, he'll be getting a new machine today and will be trying to > install debian on thursday. I don't know if you remember that > he had a house burn and lost all of his computer stuff. (he lives > in the same town as I do) OK, I had just let somebody else know that they could go ahead and develop mgetty for Debian. I do remember the fire, I had handed mgetty to him right before that happened. About a month or so later, he sent me an e-mail saying that he'd have a new version uploaded in about 2 weeks. That e-mail was probably about a month ago also. After I started receiving e-mails about people complaining, I tried contacting Siggy again (probably about a week ago) but didn't get any response, so I posted here. If you could relay the message to Siggy to talk about mgetty with the new developer, I'd appreciate it. > Anyway I thought that Chrisoph Lameter is the maintainer of mgetty > as the most recent uploads come from him. Christoph maintained mgetty before I did; the mgetty in rex still has Christoph's name in it; however, the one in bo should have my info in it. That is, unless Christoph Debianized a newer version of mgetty without letting me know... -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: How do we encourage bug reports?
One thing for developers to do is to make sure that you respond NICELY to bug reports. I have reported bugs and have had responses from developers that were downright nasty about it... While that doesn't bother me a whole lot, since I know what is going on (most of the time writes: > > How do we encourage users to submit more bug reports when something > goes wrong? > > I've encountered bugs which made me sure that a lot of people, > especially new users, must have stumbled across them, but didn't report > them. They probably just gave up (after all, people who normally use > Microsoft products don't expect that anybody cares for bugs). > > What can be done? I'd suggest putting the support addresses > (mailing list, web pages) prominently into the installation routines, > and possibly even into the MOTD. > > What else? > -- > Thomas Koenig, [EMAIL PROTECTED], [EMAIL PROTECTED] > The joy of engineering is to find a straight line on a double > logarithmic diagram. > > > -- > TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to > [EMAIL PROTECTED] . > Trouble? e-mail to [EMAIL PROTECTED] . > > -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Fixing X problems for 1.3.0...
[EMAIL PROTECTED] (Kai Henningsen) writes: > 3. 3.3 to stable > >I really don't see why this should not happen in due time. Agreed. -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Hamm: Exim + Chos standard?
Christoph Lameter <[EMAIL PROTECTED]> writes: > > It might be good if we would replace smail in hamm with exim. Exim should > be the standard mailer for hamm: Exim doesn't provide UUCP capabilities *at all*, thus it is rather useless for sites that use UUCP (like me). Right now, I am using sendmail. (What, BTW, is the reason for not using sendmail?) -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
XEmacs maintainer gone???!!
I just sent a message to [EMAIL PROTECTED] This transforms (correctly) into [EMAIL PROTECTED] scsn.net reports that there is no dres user on their system. Does this mean that the maintainer for XEMacs is gone? -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
xemacs orphaned [Todd Walker ] RE: Account dres@scsn.net (was Re: Mail System Error - Returned Mail)
Hello, It appears that James LewisMoss, previous maintainer of xemacs, is no longer around. (Attached below is a confirmation of this I received from his ISP). Therefore, xemacs is in need of a new maintainer. This is a large package, comprising over 18 megs of compressed source and over 40k of compressed diffs. There are occasional slipstream patches released on the xemacs website, so it is helpful to check there frequently. It is a multi-target package (one source produces three binaries) and has probably the most complicated debian/rules file I've ever seen, so it will probably take somebody with substantial experience with Debian to handle this one. The latest version for anybody interested in taking it is xemacs 19.15-3.1, currently in Incoming on master. If interested, please mail me or post here -- I'll help handle the transfer of the package. FYI, (and this is a bit of a simplification), xemacs is basically GNU emacs plus a lot of freely-available goodies and an enhanced X interface (toolbars, colors, etc.) Xemacs is probably the best editor I've ever used and I would really like to see somebody maintain it. I unfortunately cannot at this time. Thanks, John Goerzen -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | --- Begin Message --- This person seems to have disappeared. We don't have any current information on them and they have not logged in in over a month. -Todd Todd Walker - System Administrator South Carolina SuperNet, Inc. 1901 Main St. Suite 1125, Mail Comp. 400 Columbia SC, 29201 voice: (803) 212-4400 fax: (803) 212- >-Original Message----- >From: John Goerzen [SMTP:[EMAIL PROTECTED] >Sent: Wednesday, June 18, 1997 7:46 AM >To:Mail Administrator >Subject: Account [EMAIL PROTECTED] (was Re: Mail System Error - Returned >Mail) > >Hello, > >Can you please tell me what happened to this address ([EMAIL PROTECTED])? >The user of that account was James LewisMoss. He was a developer for >our Debian GNU/Linux project on the Internet and has disappeared >unexpectedly. > >Thanks, >John Goerzen > >Mail Administrator<[EMAIL PROTECTED]> writes: > >> [1 ] >> This Message was undeliverable due to the following reason: >> >> The following destination addresses were unknown (please check >> the addresses and re-mail the message): >> >> SMTP <[EMAIL PROTECTED]> >> >> Please reply to [EMAIL PROTECTED] >> if you feel this message to be in error. >> [2 ] >> > [ deleted ] > >-- >John Goerzen | Running Debian GNU/Linux (www.debian.org) >Custom Programming| >[EMAIL PROTECTED] | --- End Message ---
Policy wrt mail lockfile (section 4.3)
Why are we using dotfile locking only? There are much better mechanisms (flock, etc.) that should be used instead. I can see no place where dotfile locking would work and flock-style locking would fail... -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt mail lockfile (section 4.3)
Rob Browning <[EMAIL PROTECTED]> writes: > John Goerzen <[EMAIL PROTECTED]> writes: > > > Why are we using dotfile locking only? There are much better > > mechanisms (flock, etc.) that should be used instead. I can see no > > place where dotfile locking would work and flock-style locking would > > fail... > > I think flock can fail across NFS in certain situations, but I'm no > locking expert. Hmm, but why would that cause a problem with mailers/programs that use lockfile locking *and* flock/fcntl locking at the same time? -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt mail lockfile (section 4.3)
However, why is it bad if a given program (like Elm-ME+ which I maintain, which brought the issue to my attention this time) uses *both* locking mechanisms? Rob Browning <[EMAIL PROTECTED]> writes: > John Goerzen <[EMAIL PROTECTED]> writes: > > > Why are we using dotfile locking only? There are much better > > mechanisms (flock, etc.) that should be used instead. I can see no > > place where dotfile locking would work and flock-style locking would > > fail... > > I think flock can fail across NFS in certain situations, but I'm no > locking expert. > > -- > Rob > > > -- > TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to > [EMAIL PROTECTED] . > Trouble? e-mail to [EMAIL PROTECTED] . > -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: mgetty Needs Maintainer!
No. What happened is this: * You handed the package over to me. I uploaded several versions into unstable. (Bug reports are now going to me.) The person posting that message must have been using an old version, from 1.2. I never made a release of mgetty to stable since there were no serious bugs to fix. * Several months ago, I handed the package over to Siggy -- a couuple of days before he had a fire. I finally figured out what happened, so I handed it over to a different person. * This person uploaded a new version to master, but it has been sitting in Incoming for over 10 days now. Christoph Lameter <[EMAIL PROTECTED]> writes: > : > Anyway I thought that Chrisoph Lameter is the maintainer of mgetty > : > as the most recent uploads come from him. > > Is there an imposter around? My last upload must have been half a year ago or > so. > Maybe someone just forgot to change the maintainer name again. > > -- > --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- > Please always CC me when replying to posts on mailing lists. > > > -- > TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to > [EMAIL PROTECTED] . > Trouble? e-mail to [EMAIL PROTECTED] . > -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: xemacs orphaned [Todd Walker ] RE: Account dres@scsn.net (was Re: Mail System Error - Returned Mail)
OK, I've sent an e-mail to that address. It's been about 24 hours since that time now, so let's give him a few more days to respond. In the mean time, let's get somebody willing to take over xemacs just in case. IMHO, XEmacs is the most powerful editor in our system and we really should keep it up! Christian Schwarz <[EMAIL PROTECTED]> writes: > On 18 Jun 1997, John Goerzen wrote: > > > Hello, > > > > It appears that James LewisMoss, previous maintainer of xemacs, is no > > longer around. > > I just did a `grep LewisMoss debian-devel*' through my mail archive and > discovered a mail which he (James LewisMoss) sent on 08 May 1997 20:16:11 > -0600. He used the address > > James LewisMoss <[EMAIL PROTECTED]> > > Did you also try to reach him there? There is also a www address in the > signature: > > @James LewisMoss <[EMAIL PROTECTED]> | Blessed Be! > @http://www.dimensional.com/~dres | Linux is cool! > > Perhaps his home page can give more info (I didn't have a look, yet). > > > Thanks, > > Chris > > -- Christian Schwarz >[EMAIL PROTECTED], [EMAIL PROTECTED] > [EMAIL PROTECTED], [EMAIL PROTECTED] > > PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA > > CS Software goes online! Visit our new home page at >http://www.schwarz-online.com > -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Installing XF86 3.3-1 crashed XEmacs 19.15-3
I have already released a non-maintainer upload of XEmacs 19.15 (named XEmacs 19.15-3.1) to Incoming on Master. This package fixes that problm. Federico Di Gregorio <[EMAIL PROTECTED]> writes: > Then, to get better support for my gfx board I downloaded > the XF86 3.3-1 packages (base, svga-server, lib, fonts, extensions, > etc...) and installed them. Again all went well but... now XEmacs 19.15 > crashes and does a core dump. I tryed to mail the maintainer > (James LewisMoss <[EMAIL PROTECTED]>) but, apparently, the address is > wrong. (I'll cc a copy of this mail to his address anyway...) -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: leap second
What's the big deal? Why would you have to update everything? All you do is add an extra second to your system clock at the end of June and be done with it. Or you don't. Big deal. [EMAIL PROTECTED] (Kai Henningsen) writes: > [EMAIL PROTECTED] (Bruce Perens) wrote on 18.06.97 in <[EMAIL PROTECTED]>: > > > The time is out of joint, o 'cursed spite. > > > > The U.S. National Institute of Standards and Technology will set it right > > on June 30, at one second before midnight UTC, by adding a leap second. > > Systems that run on POSIX time will ignore this. The effect is that they > > will consider the difference between the epoch and now to be 22 seconds > > less than it really is. > > We already had this debate. For an OS, the POSIX time is the only > reasonable choice. > > Consider a system using "real" time. On June 31, its idea of time would be > wrong until the next software upgrade. Then, all time stamps would > suddenly change by one second (possibly causing FTP server remirroring and > other unpleasant effects). > > This is completely unacceptable. OS time must be predictable. -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
dc and bc in Important?
It seems to me that dc and bc aren't vital to the workings of a system (when I deselect them, dselect doesn't warn about any dependencies), yet they are in Important. Why? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Policy wrt Important (was Re: dc and bc in Important?)
OK, then I suspect the policy is at fault. (BTW, I checked it out and I did find dc and bc on SunOS -- I had not known these programs were on other OSs.) By the current definition of Important: * Sendmail should be there instead of smail since people expect sendmail * dpkg-dev should not be there since no experienced user of another Unix would expect it * lilo should not be there because lilo is not part of UNIX And: * gcc should be in Important because everybody expects a C compiler * libc5-dev should be there because everybody expects working header files * make should be there, I expect a working make in any Unix * lpr should be there, it is standard with just about any Unix * netbase and netstd should both be there, they are standard on Unix * csh/tcsh should be there (again, standard on various Unices) * The list goes on... Basically, it seems that this policy doesn't quite apply correctly. James Troup <[EMAIL PROTECTED]> writes: > John Goerzen <[EMAIL PROTECTED]> writes: > > > It seems to me that dc and bc aren't vital to the workings of a > > system (when I deselect them, dselect doesn't warn about any > > dependencies), yet they are in Important. Why? > > Because they match the first definition of Important in Policy (see > below). When I released my first version of bc/dc I downgraded them > to Optional by mistake and someone complained; that's obviously one > person who agrees with me. Does anyone else think bc/dc should be > downgraded? (If so, why?) > > ``Important programs, including those which one would expect to find > on any Unix-like system. If the expectation is that an experienced > Unix person who found it missing would go `What the F*!@<+ is going > on, where is foo', it should be in important. This is an important > criterion because we are trying to produce, amongst other things, a > free Unix.'' (3.1.4.1 of debian-policy 2.1.3.3) > > -- > James > > > -- > TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to > [EMAIL PROTECTED] . > Trouble? e-mail to [EMAIL PROTECTED] . > -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: End of Documentation Discussion
promise" that > everyone here should be able to accept. I will _NOT_ accept simple > "objections" this times. If you can't live with this proposal, you'll have > to present another formulation of a paragraph or of the whole text. > > Note, that this is _NOT_ the actual text that will be included in the > Policy Manual. It's meant to contain the "facts" the new policy will be > based on. When we have a consensus about that, I'll present the necessary > policy changes here. > > Here is my proposal: > > - > The unification of Debian documentation is being carried out via HTML. > > Thus, every documentation that is available in a format which can be > converted into HTML, should be converted, with the exception of manual > pages (they can be converted via dwww at run-time) and source code > examples. > > In case of converted HTML documentation, the files with original mark up > format should not be provided, unless they are considered as "example > documents" for the mark up language. > > Packages that contain programs with GNU info manuals, should provide these > in HTML _and_ in GNU info format. The HTML files should be stored in > the directory > /usr/doc//html-info/ > since the new package management system (deity) will be able to identify > these files as info-converted HTML files, which may be removed by the > local sysadmin. > > All documentation related files will be kept in the "main binary package" > if they do not exceed 500 kbytes installed size together. (Of course, > documentation-only packages are not covered by this rule.) > - > > > One questions remains: Is it possible to browse "html.gz" files _without_ > a CGI script with the usual HTML browsers (Netscape, lynx)? If so, we'll > make it policy to gzip all html files and to adopt the references. If not, > we'll have to install all html files gezipped--or add a cgi capable web > server to the base system. > > > Note, that I checked all packages in "hamm/main" against these rules. > We'll get about 26 new packages. (I added the installed file size of the > files /usr/doc/* and twice the size of /usr/info/*, since these documents > will be translated into HTML too. If this sum is greater than 500kbytes, a > new packages has to be set up.) > > Here is a list of packages (hopefully, all non-doc packages :), that would > have to be splitted. The syntax is: > > : (doc , >info ) > > Here is the list: > > ./devel/cvs_1.9-4.deb: 625 (doc 433,info 96) > ./devel/ddd_2.1-3.deb: 700 (doc 700,info 0) > ./devel/g77_0.5.20-1.deb: 510 (doc 42,info 234) > ./devel/binutils_2.8.1-1.deb: 553 (doc 189,info 182) > ./devel/libfcgi1-dev_1.5.1-1.deb: 564 (doc 564,info 0) > ./devel/slib_2a6-1.deb: 672 (doc 482,info 95) > ./devel/doc++_3.01-1.deb: 692 (doc 692,info 0) > -- the package includes a large ungezipped PostScript file! > ./devel/gcc_2.7.2.2-4.deb: 807 (doc 79,info 364) > ./devel/libg++27-dev_2.7.2.1-9.deb: 637 (doc 435,info 101) > ./devel/libg++272-dev_2.7.2.5-1.deb: 637 (doc 435,info 101) > ./editors/emacs_19.34-11.deb: 1830 (doc 42,info 894) > ./editors/xemacs19-support_19.15-3.deb: 4654 (doc 0,info 2327) > ./games/xconq_7.1.0-3.deb: 998 (doc 998,info 0) > ./graphics/povray-misc_3.0.10-2.deb: 969 (doc 969,info 0) > ./graphics/ucbmpeg_1r2-2.deb: 1512 (doc 1512,info 0) > ./interpreters/gclinfo_2.2-4.deb: 1318 (doc 0,info 659) > ./interpreters/scm_4e6-2.deb: 566 (doc 410,info 78) > ./mail/mhonarc_2.0.1-1.deb: 793 (doc 793,info 0) > ./math/calc_2.02f-1.deb: 980 (doc 36,info 472) > ./math/gnuplot_3.5beta6.328-2.deb: 796 (doc 660,info 68) > ./tex/latex2html_96.1.h-6.deb: 651 (doc 651,info 0) > ./tex/tetex-base_0.4pl8-2.deb: 647 (doc 3,info 322) > ./text/lout_3.08-1.deb: 3517 (doc 3517,info 0) > ./utils/ftape-2.0.30_3.03a-1.deb: 581 (doc 473,info 54) > ./web/arena_1.0b3-1.deb: 701 (doc 701,info 0) > ./x11/9term_1.6.6-3.deb: 551 (doc 551,info 0) > > > > Thanks, > > Chris > > -- Christian Schwarz >[EMAIL PROTECTED], [EMAIL PROTECTED] > [EMAIL PROTECTED], [EMAIL PROTECTED] > > PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA > > CS Software goes online! Visit our new home page at >http://www.schwarz-online.com > > > -- > TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to > [EMAIL PROTECTED] . > Trouble? e-mail to [EMAIL PROTECTED] . > -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Policy wrt Important (was Re: dc and bc in Important?)
Who said anything about "working"? Mark Eichin <[EMAIL PROTECTED]> writes: > > * gcc should be in Important because everybody expects a C compiler > > Maybe they expect it, but these days, they don't *get* one... none of > solaris, hpux, irix ship with a [working] C compiler... > -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: End of Documentation Discussion
Richard Kaszeta <[EMAIL PROTECTED]> writes: > A good format, but the problem here is that the LinuxDoc/SGML source > isn't very useful by itself, it has to be converted to another source > to be useful. I don't see a big problem with that because, as I said, the conversion programs are small and fast. > Basic fact of the matter is that we don't have a perfect solution, all > of them have problems. But I'd say of the available options HTML at > least provides: > > 1. A wide variety of browsers (although as discussed many times, none > with quite the desired feature base). We really have only one of quality (Netscape), and it is non-free. Lynx is OK for terminals, but its interface is not as good as it could be. > 2. A wide variety of possible formats that can result in HTML. > On the issue of the difficulty of doing good searches on html... Since > we plan on distributing as much documentation as possible in html > format, can't we simply configure 'glimpse' to provide much of this > missing functionality? But the problem here is that glimpse requires a lengthy process of creating an index, space for an index, etc. This index must also be updated (either via cron or whenever a package is installed or removed). This is not acceptable in many situations. I currently have two older machines (a 386 and a 486/33) running Debian. One of the best things about it is that it requires little space and few resources. Glimpse would change that. It would suck up several megabytes at least. It would require lengthy update processes, etc. And, there are much more serious problems with HTML. The most serious is that it is extremely difficult, if not impossible, to produce coherent printed output from documentation done in HTML. This is, in large part, due to the fact that HTML documentation tends to be split up into many small files. There also can be no real index for the printed copy. While HTML is good for online viewing with certain conditions, it is not suited to a general documentation format. -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: End of Documentation Discussion
[EMAIL PROTECTED] (Karl M. Hegbloom) writes:
> >>>>> "John" == John Goerzen <[EMAIL PROTECTED]> writes:
>
> John> * GNU Info has an awkward interface and is difficult to
> John> search. It is also nearly impossible to print an entire
> John> manual from the files in the info directory.
>
> Difficult to search? Did you read its help page at all? ('?' in the
> standalone version, 'h' inside one of the emacsen.) Press 's', and
> enter a search string/regexp, and *bang*, you're there. You can call
I much prefer a grep-style output, listing the line (and possibly the
context) of each hit. That way, I know immediately which ones are
relevant instead of having to continually reposition through the document.
> Why print it? :-) If you want a printed copy, you start with the
> texinfo source, and make a dvi from it.
Sometimes a printed manual is much easier to work from than an
on-screen version.
How do I make a dvi from the stuff installed into /usr/info? AFAIK,
that is not possible...
> I think that TeXinfo is better thought out, by people with far
> greater experience, than Linuxdoc SGML is.
There is a sgml2info program.
> It can't be that hard to learn, either. If you can write a program,
> you can write texinfo.
--
John Goerzen | Running Debian GNU/Linux (www.debian.org)
Custom Programming|
[EMAIL PROTECTED] |
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Does it conform our demands?
Jozef, I am the assistant sysadmin in the Computer Science Dept. at Wichita State Univ. There, we use Debian for everything you mention except PPP. At home, I use PPP dial-on-demand successfully. My comments below refer to Debian 1.3.1, the latest release. Jozef Bednarik <[EMAIL PROTECTED]> writes: > all) supports the following features: > > NIS (yellow pages) This works fine. In the CS Dept., our NIS server is a SunOS machine and all the Linux boxed work fine. Debian can also be a NIS server. > DNS Our departmental nameserver is a Debian 486. > automount The Debian package amd provides this functionality. > PPP > PPP dial on demand Dial-on-demand is provided by the Debian diald package. It works quite nicely and is very configurable. > SMTP You have several choices for SMTP (mail transport agent) programs. We use sendmail, but you can also pick smail, exim, or qmail. > POP3 Programs like qpopper provide this functionality. > IMAP4 Debian has an IMAP daemon complete with the latest security fixes. > 3Com fast ethernet adapter 3C905-TX (or at least any other fast ethernet > card available on the market) We use some 3COM cards. We have had best luck with cards based on Digital's chipset. These include Kingston and SMC cards. -- John Goerzen | Developing for Debian GNU/Linux (www.debian.org) Custom Programming| Debian GNU/Linux is a free replacement for [EMAIL PROTECTED] | DOS/Windows -- check it out at www.debian.org. --+-- Find out how to avoid all those pesky crashes, lockups, application errors, and slow applications at http://www.debian.org -- Debian can replace Windows 95 with a much more stable operating system. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Uncompress /usr/doc/copyright/GPL.gz please
Hi, One of the programs I'm maintaining (filerunner) has, on its help menu, options to display some of its documentation (which I conveniently stick in /usr/doc/filerunner). This is how it does its online help. One of the things it wants to display is the COPYING file (the normal name for the GPL). It will not display gzipped files. So at the moment, I am left in the unfortunate position of having to install an uncompressed COPYING in /usr/doc/filerunner. I would like to set a symlink from COPYING in /usr/doc/filerunner to GPL in /usr/doc/copyright. But -- that file is gzipped, so it won't work. Can this file be uncompressed in the future? -- John Goerzen | Developing for Debian GNU/Linux (www.debian.org) Custom Programming| Debian GNU/Linux is a free replacement for [EMAIL PROTECTED] | DOS/Windows -- check it out at www.debian.org. --+-- Find out how to avoid all those pesky crashes, lockups, application errors, and slow applications at http://www.debian.org -- Debian can replace Windows 95 with a much more stable operating system. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Uncompress /usr/doc/copyright/GPL.gz please
Santiago Vila <[EMAIL PROTECTED]> writes: > -BEGIN PGP SIGNED MESSAGE- > > On 8 Jan 1998, John Goerzen wrote: > > Can /usr/doc/copyright/GPL.gz be uncompressed in the future? > > It will be uncompressed in the future. See Bug #15025. I hope this will be fixed before the release of 2.0? If so, I will go ahead and change the filerunner package to assume that /usr/doc/copyright/GPL exists. This will cause a small error if somebody goes to Help -> Copying before bug #15025 is cleared, but filerunner's behavior would then be correct. Let me know if this is the wrong thing to do. -- John Goerzen | Developing for Debian GNU/Linux (www.debian.org) Custom Programming| Debian GNU/Linux is a free replacement for [EMAIL PROTECTED] | DOS/Windows -- check it out at www.debian.org. --+-- Find out how to avoid all those pesky crashes, lockups, application errors, and slow applications at http://www.debian.org -- Debian can replace Windows 95 with a much more stable operating system. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
xsqlmenu up for adoption
Hi, I currently maintain xsqlmenu, an xforms front-end for mSQL. As I have switched from mSQL to the free PostgreSQL, I am not in a good position to continue maintaining xsqlmenu. Volunteers welcome. John -- John Goerzen | Developing for Debian GNU/Linux (www.debian.org) Custom Programming| Debian GNU/Linux is a free replacement for [EMAIL PROTECTED] | DOS/Windows -- check it out at www.debian.org. --+-- Find out how to avoid all those pesky crashes, lockups, application errors, and slow applications at http://www.debian.org -- Debian can replace Windows 95 with a much more stable operating system. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Linux
"Dauer" <[EMAIL PROTECTED]> writes: > I e-mailed a question to this address a while back and you answered. So I > have a question...I can not put Linux on my hard drive and I can't put it on > my Syquest for some reason. So where could I find a boot disk like the kind > I use to access DOS?? Just something to give me a shell like the one that is > on the rescue disk. Sorry if you are the wrong person to ask. Look at: ftp.debian.org:/debian/stable/disks-i386/resc1440.bin also you may want drv1440.bin Boot from the rescue disk. When the prompt asking for color or monochrome appears, hit Alt-F2 and you've got a shell. > > > -- > TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to > [EMAIL PROTECTED] . > Trouble? e-mail to [EMAIL PROTECTED] . > -- John Goerzen | Developing for Debian GNU/Linux (www.debian.org) Custom Programming| Debian GNU/Linux is a free replacement for [EMAIL PROTECTED] | DOS/Windows -- check it out at www.debian.org. --+-- Find out how to avoid all those pesky crashes, lockups, application errors, and slow applications at http://www.debian.org -- Debian can replace Windows 95 with a much more stable operating system. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FILESYSTEM CORRUPTION
Vincent Renardias <[EMAIL PROTECTED]> writes: > (speaking a 'mount' maintainer) > > I agree crash disks aren't fun at all, however from this email and from > your previous bug report, I fail to see where 'mount' is involved in this > infortunate process: Thanks for your reply, Vincent It would have been appreciated had you replied last month however :-) > 1/ the kernel still doesn't support forced umounts, so doesn't umount > consequently (& unfortunatly); although umount has preliminary '--force' > support (just try umount -f /something), it won't work until the > kernel-side is ready. > When you have run-away or zombies processes with open file descriptors, > it's the kernel that prevents the unmounting. In this case, it is a kernel bug (and a serious one). However, note that processes with open FDs are not the only problem. (Although they can be, I have experienced cases where things like ls hang waiting for an NFS that cannot be fulfilled. kill -9 will not kill them, and they will prevent it from being umounted later. Another kernel bug.) In my original bug report, I complained that if it tries to unmount a NFS-mounted partition, and cannot for whatever reason (server crashed, unreachable, etc.) it will hang and not umount local drives. Therefore, I believe it would be prudent, as a temporary workaround for the kernel bug, to umount all local drives before umounting network drives. It is generally not a big deal if a network drive doesn't get umounted anyway. > 2/ when rebooting with an unclean filesystem, the '/' is mounted r/o > so e2fsck can be loaded to check all the filesystems BEFORE mount > attempts to mount them r/w. Yes. Not quite sure what this has to do with the bug report, but oh well :-) My root FS was hosed so bad that the kernel couldn't find init and paniced. > The problem as you say involves PCMCIA (which fails to unload), you (for > turning off the machine) and the kernel (for panicing), but why would > mount be involved? There is also a separate PCMCIA issue. Unfortunately, I did not realize that the corruption occured until almost 24 hours later (I thought nothing of it at the time) and so I do not have details on the PCMCIA problem and I feel leery of reporting a bug against PCMCIA without information to back it up. I hope, however, that the PCMCIA maintainer will see these messages and at least be on the lookout for future occurances of these problems. I shall also make sure to get in-depth information when/if this occurs again (as far as PCMCIA is concerned). You are correct in saying that this latest problem is not mount's fault (I believe). The end result is the same as the mount/kernel issue -- filesystems do not get umounted and corruption can result. I think we have a problem with ordering... PCMCIA services are turned off before the network is turned off, apparently. This causes difficulty, for instance, if the laptop is acting as an NFS server, as mine does. (Great way to carry data around!) If I forget to umount it from the NFS client (my desktop machine), I can have two problems: * When I shutdown my desktop, it will hang trying to umount. * When I shutdown my laptop, it will hang trying to turn off PCMCIA. grr. Deadlock. :-( Regards, John "Install it again" Goerzen -- John Goerzen | Developing for Debian GNU/Linux (www.debian.org) Custom Programming | Debian GNU/Linux is a free replacement for [EMAIL PROTECTED]| DOS/Windows -- check it out at www.debian.org. -+-- uuencode - < /vmlinux | mail -s "Windows NT security fix" [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dpkg memory usage
I was upgrading packages on my 64 meg system today ant noticed: PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 24785 root 18 0 12680 12M 568 S 0 0.1 20.0 5:36 dpkg Yes, that's almost 13 megs used by dpkg, and 20% of my RAM. That also is 4 megs more than the TOTAL amount of RAM in some computers I work with. So...why must dpkg use almost as much memory as XFree86 itself, and MORE than Netscape does at times? Not only that, but it is hideously slow even on current computers. My suggestion: store the databases in a DBM format of some sort instead of plain text. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FILESYSTEM CORRUPTION
[EMAIL PROTECTED] (Kai Henningsen) writes: > [EMAIL PROTECTED] (John Goerzen) wrote on 10.04.98 in <[EMAIL PROTECTED]>: > > > Therefore, I believe it would be prudent, as a temporary workaround > > for the kernel bug, to umount all local drives before umounting > > network drives. It is generally not a big deal if a network drive > > doesn't get umounted anyway. > > The reason local file systems can't be unmounted when NFS unmount hangs, > is that the NFS fs is still mounted, keeping the local fs busy. > > What makes you think it is possible to unmount the local fs before even > trying to unmount the NFS fs? Because I didn't think of the above :-) > *However*, a little experimenting shows that the kernel is perfectly > willing to let you "mount /some/where -o remount,ro" even if there are > files open on that fs. I'm not quite certain if those open files are > guaranteed to be handled correctly, but this, possibly combined with sync, > should be enough to get a clean shutdown. > > This looks like a wishlist bug for sysvinit (which has /etc/init.d/umountfs). I actually originally reported it against sysvinit but he reassigned it to mount. I have set its priority to critical because it can (and HAS!) cause extensive data loss; definately not a wishlist issue! I will let the mount maintainer decide whether or not to reassign it. -- John Goerzen | Developing for Debian GNU/Linux (www.debian.org) Custom Programming | Debian GNU/Linux is a free replacement for [EMAIL PROTECTED]| DOS/Windows -- check it out at www.debian.org. -+-- uuencode - < /vmlinux | mail -s "Windows NT security fix" [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FILESYSTEM CORRUPTION
Stephen Zander <[EMAIL PROTECTED]> writes: > No, that won't work if the NFS mounts live below the local mounts in > the file-system tree. The local mounts will report busy. Blat. You're right. > > John> * When I shutdown my desktop, it will hang trying to > John> umount. > > I suggest looking at the options you're using on the NFS client. Try > soft mounting & see if that will let you umount the NFS volume. I try to soft mount whenever possible, but I often forget. Also, some people must use hard mounts instead of soft mounts for some applications. This is a workaround, not a fix, and it may not even work. > > John> * When I shutdown my laptop, it will hang trying to turn > John> off PCMCIA. > > That probably does need fixing. Indeed. It happened to me again today. -- John Goerzen | Developing for Debian GNU/Linux (www.debian.org) Custom Programming | Debian GNU/Linux is a free replacement for [EMAIL PROTECTED]| DOS/Windows -- check it out at www.debian.org. -+-- uuencode - < /vmlinux | mail -s "Windows NT security fix" [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#20987: pcmcia-cs: Lockup again
[EMAIL PROTECTED] writes: > In general, I think that it is the system administrator's responsibility > to ensure that that filesystems mounted through a PCMCIA card -- whether > SCSI, IDE, NFS, or other -- are properly unmounted before the PCMCIA > utilities are shut down. For NFS directories that should be > automatically > mounted when the network connection is established, the MOUNTS variable > is the /etc/pcmcia/network.opts file should be used; however keep in > mind, that in using this, the network card cannot be ejected without > first using either cardctl or cardinfo to shut down the network card. This is silly. The administrator is not expected to manually unmount filesystems in any other configuration and should not be expected to here. Particularly insidious is the situation of SCSI, wherein the PCMCIA system is shutdown before the system unmounts it (!!). While I don't have a SCSI system to test it on, this is the order it does things in (incorrectly). > If you are in the habit of manually mounting an NFS directory to /mnt > and > are prone to forgetting to unmount before shutting down the system, may > I suggest that you add `umount /mnt' to the stop_fn function defined in > /etc/pcmcia/network.opts. This way, the network script will > automatically > detach any filesystem mounted to /mnt before the PCMCIA cardmgr is > halted. The PCMCIA scripts should not force me to explicitly define all the possible things that I may mount via PCMCIA. (What if, for instance, /mnt may sometimes by a different partition on the hard disk?) I feel very strongly that the bug that causes it to lock up is NOT trivial and should be FIXED. Requiring the sysadmin to manually unmount, automatically unmounting one specific filesystem regardless of whether it deals with PCMCIA, etc. is NOT an acceptable solution. It is merely a workaround, and forgetting to umount before shutting down a machine (or simply not knowing that somebody else mounted something) should not cause data loss. EVER. But it does. The real solution is to only turn PCMCIA off AFTER everything using it is finished. That probably means that it would theoretically be turned off after the filesystems are unmounted, although that isn't really possible. Perhaps Linux doesn't have to worry about turning it off on system shutdown, just as Windows 95 doesn't worry about turning if off on system shutdown (and thus neatly sidesteps these insidious bugs). -- John Goerzen | Developing for Debian GNU/Linux (www.debian.org) Custom Programming | Debian GNU/Linux is a free replacement for [EMAIL PROTECTED]| DOS/Windows -- check it out at www.debian.org. -+-- uuencode - < /vmlinux | mail -s "Windows NT security fix" [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FILESYSTEM CORRUPTION
Stephen Zander <[EMAIL PROTECTED]> writes: > >>>>> "John" == John Goerzen <[EMAIL PROTECTED]> writes: > John> Indeed. It happened to me again today. > > While watching my laptop shut-down last night, I noticed that mountd & nsfd > *do* get stopped prior to the PCMCIA shutdown. This is only for NFS server; not NFS clients. Although this is good to know, since it was not always the case. > > Maybe they're just not getting stopped hard enough :) > > -- > Stephen > --- > "Normality is a statistical illusion." -- me > -- John Goerzen | Developing for Debian GNU/Linux (www.debian.org) Custom Programming | Debian GNU/Linux is a free replacement for [EMAIL PROTECTED]| DOS/Windows -- check it out at www.debian.org. -+-- uuencode - < /vmlinux | mail -s "Windows NT security fix" [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: *** The Upcoming Release of Hamm ***
Hartmut Koptein <[EMAIL PROTECTED]> writes: > Make it harder! From now on no new upstream versions to frozen. Cleaning > Incoming. 1. May is 'early beta' and 1. June is release time (to have some > more time for arch maintainers and testers). Please let's not delay it that long if we can prevent it. I would very much like to be able to get our department's network updated before summer semester begins, since bo is in a somewhat unfortunate state of "outdatedness" if you will. -- John Goerzen | Developing for Debian GNU/Linux (www.debian.org) Custom Programming | Debian GNU/Linux is a free replacement for [EMAIL PROTECTED]| DOS/Windows -- check it out at www.debian.org. -+-- uuencode - < /vmlinux | mail -s "Windows NT security fix" [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wu-ftpd important bug(s)
Heiko Schlittermann <[EMAIL PROTECTED]> writes: > : 2.0 with or without wu-ftpd? (Those bugs are listed in Brian White's > : "list of bugs that *must* be fixed before releasing Hamm") > > Yes, wu-ftpd is depreciated, since all it's functionality is in > wu-ftpd-academ. The only problem is: how can I handle this? I already filed a bug against ftp.debian.org about this. John -- John Goerzen | Developing for Debian GNU/Linux (www.debian.org) Custom Programming | Debian GNU/Linux is a free replacement for [EMAIL PROTECTED]| DOS/Windows -- check it out at www.debian.org. -+-- uuencode - < /vmlinux | mail -s "Windows NT security fix" [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292653: ITP: lhs2tex -- Preprocessor to generate LaTeX code from literate Haskell sources
Package: wnpp Severity: wishlist * Package name: lhs2tex Version : 1.9 Upstream Author : Ralf Hinze [EMAIL PROTECTED] Andres Loeh [EMAIL PROTECTED] * URL : http://www.cs.uu.nl/~andres/lhs2tex/ * License : GPL Description : Preprocessor to generate LaTeX code from literate Haskell sources lhs2TeX includes the following features: * Different styles to process your source file: for instance, "tt" style uses a monospaced font for the code while still allowing you to highlight keywords etc, whereas "poly" style uses proportional fonts for identifiers, handles indentation nicely, is able to replace binary operators by mathematical symbols and take care of complex horizontal alignments. * Formatting directives, which let you customize the way certain tokens in the source code should appear in the processed output. * A liberal parser that can handle most of the language extensions; you don't have to restrict yourself to Haskell 98. * Preprocessor-style conditionals that allow you to generate different versions of a document from a single source file (for instance, a paper and a presentation). * Active documents: you can use Haskell to generate parts of the document (useful for papers on Haskell). * A manual explaining all the important aspects of lhs2TeX. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: alpha Kernel: Linux 2.6.9-vs1.9.3 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Native package with two changelogs
On Wed, Apr 06, 2005 at 02:16:08PM +0200, Benjamin Mesing wrote: > Hello, > > I have a package which I develop on my own and which is debian native. > However due to historical reasons, I have a CHANGELOG file which is not > the debian/changelog file. > How should I handle this case? I am in favour of handling it like an > upstream package, meaning > 1. debian/changelog -> changelog.Debian > 2. CHANGELOG -> changelog > Is this appropriate? I do this with quite a few of my packages. In many cases, the tarball I release has a file named ChangeLog that is automatically maintained for me by tla. It is far more detailed than a debian/changelog file usually is, and contains details of interest to plenty of people besides Debian users -- but may also be of interest to Debian users. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304863: ITP: arch2darcs -- Convert Arch/tla repositories to Darcs
Package: wnpp
Severity: wishlist
Owner: John Goerzen <[EMAIL PROTECTED]>
* Package name: arch2darcs
Version : 0.99.0
Upstream Author : John Goerzen
* URL : http://darcs.complete.org/arch2darcs
* License : GPL
Description : Convert Arch/tla repositories to Darcs
Source: arch2darcs
Section: devel
Priority: optional
Maintainer: John Goerzen <[EMAIL PROTECTED]>
Build-Depends: debhelper (>= 4.0.0), ghc6 (>= 6.2.1), libghc6-cabal-dev (>=
0.5), libghc6-missingh-dev (>= 0.9.0)
Standards-Version: 3.6.1
Package: arch2darcs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Convert Arch/tla repositories to Darcs
arch2darcs is used to convert an Arch repository to Darcs,
automaticaly preserving:
.
* All original logs
.
* Modification dates
.
* All adds, deletes, and renames that were versioned with tla
.
* Files in Arch.
.
arch2darcs can process entire Arch/tla branches at once.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.9
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305420: ITP: darcs-buildpackage -- Suite to help with Debian packages in Darcs archives
Package: wnpp Severity: wishlist Owner: John Goerzen <[EMAIL PROTECTED]> * Package name: darcs-buildpackage Version : 0.5.0 Upstream Author : John Goerzen <[EMAIL PROTECTED]> * URL : None yet * License : GPL Description : Suite to help with Debian packages in Darcs archives This package helps automate and ease the task of maintaining Debian packages by helping you, the Debian developer, take advantage of the unique features in Darcs. The programs included are: . dbp-importdsc: Import an upstream version and a Debian version from a Debian source package, automatically detecting package and version information from the .dsc. . dbp-importorig: Import an upstream tar.gz or directory. . dbp-markdeb: Mark a working copy for future reference. . darcs-buildpackage: Builds a Debian package based on information in the repository, checking out Debian and upstream versions as necessary. . Also, the package includes a comprehensive 24-page manual in PostScript and HTML versions. Debian developers may be interested to know that darcs-buildpackage is written in Haskell. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
{Arch,OCaml,Python,Mono} Packages for Adoption
Hello, I'm going through the list of packages I'm maintainer for, and found several that I no longer use. Some I've tried to give away long ago, but for whatever reason, never were picked up. I've submitted orphaned versions of all of these and filed appropriate wnpp bugs. [Arch] cscvs tla-tools [Ocaml] regexp-pp pycaml perl4caml [Mono] nant ikvm [Python] gnupginterface [Misc] inform-mode haskelldb -- John Goerzen Author, Foundations of Python Network Programming http://www.amazon.com/exec/obidos/tg/detail/-/1590593715 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: {Arch,OCaml,Python,Mono} Packages for Adoption
On Wed, Apr 27, 2005 at 11:46:37AM +0200, Andreas Rottmann wrote: > John Goerzen <[EMAIL PROTECTED]> writes: > > > tla-tools > > > I can take this one, if noone else wants it. Manoj has also expressed interest; could you coordinate with him? -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
FW: Processing of tla-load-dirs_1.0.21ubuntu1_source.changes
Can anyone tell me what this means, and who is trying to upload this to Debian without even sending me a patch first? - Forwarded message from Archive Administrator <[EMAIL PROTECTED]> - From: Archive Administrator <[EMAIL PROTECTED]> Date: Sun, 22 May 2005 14:30:38 -0400 To: [EMAIL PROTECTED] Subject: Processing of tla-load-dirs_1.0.21ubuntu1_source.changes PGP/GnuPG signature check failed on tla-load-dirs_1.0.21ubuntu1_source.changes gpg: Signature made Sun May 22 14:24:08 2005 EDT using DSA key ID C5AA2301 gpg: Can't check signature: public key not found (Exit status 2) tla-load-dirs_1.0.21ubuntu1_source.changes has bad PGP/GnuPG signature! Removing tla-load-dirs_1.0.21ubuntu1_source.changes, but keeping its associated files for now. Greetings, Your Debian queue daemon - End forwarded message - -- John Goerzen Author, Foundations of Python Network Programming http://www.amazon.com/exec/obidos/tg/detail/-/1590593715 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
