Re: Who uses @packages.d.o mail?
On Fri, May 22, 2009 at 10:30:03PM +0100, Stephen Gran wrote: > Hello all, > > So I've looked through a few weeks of mail logs to packages.debian.org, > and it looks like it collects some useful mail from automated scripts > on various debian.org machines (primarily ries), and about 1000 spams a > day from elsewhere. I haven't done an exhaustive survey, but it seems > pretty clear so far that the domain does not get any significant amount > of legitimate mail from machines other than the debian.org hosts. I occasionally do use this route, although I could email the package maintainers directly. Would it be possible to allow mail from arbitrary hosts as long as it has some special header, say "X-Debian-Pkg: foo" where foo matches the package being mailed? However, I wouldn't personally have a problem with it being blocked completely from non-Debian machines. Julian -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Constitutional, Parliamentary Issues (was Re: CFV: Non-freearchive removal)
On Sun, Jul 09, 2000 at 04:28:52PM -0500, Manoj Srivastava wrote: > We could add in the better than a simple majority clause for > modifying the DFSG and social contract in at the same time; which > would perhaps address the concerns of a number of people. > > Please consider this a trial baloon for that idea; if it seems > like a good idea, perhaps we can get a constitutional amendment in > that addresses the constitutionality of changing these documents (and > allay the fears that some have about frivolous, or hasty, changes to > core documents for the project). I support this idea. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
New developers -> new AMs
As you may or may not know, after a conversation with Dale, I emailed all of the maintainers who have been accepted through the new NM process, inviting them to take on the role of an AM to see through a couple of applicants, so that we can clear the backlog. After a discussion with Rick Younie, we have concluded that it would be very worthwhile to explain to your successful applicants that the reason for the long delay was that there is a large backlog and not enough AMs to clear it, and that it would be really helpful and useful if the first thing they do for Debian once they have passed through the NM process[1] is to act as AM for two or three applicants. In that way, the queue will be cleared much more quickly than it would do otherwise, freeing most of us to do "more useful" things for Debian (like getting back to my coding ;-) Thanks for the help! Julian [1] Both Dale and I appear to agree that they can become AMs once their AM has approved their application. I haven't checked this with the DAM, though, so I've only emailed applicants who have passed through the DAM stage. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: AM Report on Chris Rutter
On Sat, Sep 16, 2000 at 04:45:25AM +0900, Fumitoshi UKAI wrote: Your PGP signature was bad. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Query on requirements for identification
On Fri, Sep 15, 2000 at 01:11:17PM -0700, Jim Westveer wrote: > John, > > Actually the two references you mention say the same thing. Ah, you have a new email address ;-) nm-step2 needs updating to reflect the new procedures. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
[e9625136@student.tuwien.ac.at: Re: becomming a debian developer (fwd)]
Please could we do something about this? Thanks, Julian - Forwarded message from Michael Moerz <[EMAIL PROTECTED]> - Date: Fri, 15 Sep 2000 16:21:08 +0200 (METDST) From: Michael Moerz <[EMAIL PROTECTED]> To: debian devel Subject: Re: becomming a debian developer (fwd) Hi! First of all I wanna thank you and all others who have so quickly answered my questions. On Fri, 15 Sep 2000, Ashley Clark wrote: > I didn't know any Debian developers personally before I applied either, > but if you tell us where you are I'm sure if someone lives near you > that something can be arranged. There were several of us in Houston > that did just that. > > -- > creaky halls > I think that the problem I ran across is that it is not really mentioned to find someone living near by would work too. That could be put in the document at the point telling how to get an accepted pgp/gpg key. Thanks to all, again and again, Michael Moerz - End forwarded message - -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Where to send NM reports?
On Sat, Sep 16, 2000 at 10:32:16AM -0500, Clay Crouch wrote: > Greets! :^) > > I have recently approved the application of one Risko Gergely. > > Now, to whom do I send the reports? The basic report (just name, did they pass steps 2, 3 and 4, do you approve them) goes to [EMAIL PROTECTED] The full report (which in addition has the GPG key, any photo ID needed, copies of relevant parts of relevant emails etc.) goes to both the Front Desk ([EMAIL PROTECTED]) and the DAMs ([EMAIL PROTECTED]). > From the Mini_HOWTO, I see that there are two that need to be sent. > One to the Front Desk, and another one. Erm, did I say this? If it isn't clear, I'd like to clarify it. Thanks for doing this! Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: AM Mini-HOWTO
On Sun, Sep 17, 2000 at 11:01:46PM +0900, Taketoshi Sano wrote: > > It was mentioned in a private email that there is, as yet, no AM > > HOWTO. I have just concocted a mini-HOWTO, which is attached. Any > > comments or improvements would be accepted. Maybe this can go onto > > the AM part of the NM site? > > Very nice work, I think. Thanks. Examples are appreciated too. > > Can you provide the wml source or html version this HOWTO ? The original source was provided ;-) I wrote it in plain text, as the majority consists of example files which are plain text (they become emails). I guess having it as "devel/join/nm-amhowto.txt" should be OK. Or translation, when you have time, will be fine too. > I plan to create a new page as devel/join/nm-amhowto for this text > (your AM HOWTO), and to put a link to it on nm-amchecklist. > Is this OK ? Of course! I may also submit patches from time to time, based on people's comments Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Where to send NM reports?
On Tue, Sep 19, 2000 at 07:41:50PM +1100, Craig Small wrote: > On Sat, Sep 16, 2000 at 11:26:14PM +0100, Julian Gilbey wrote: > > The basic report (just name, did they pass steps 2, 3 and 4, do you > > approve them) goes to [EMAIL PROTECTED] > > > > The full report (which in addition has the GPG key, any photo ID > > needed, copies of relevant parts of relevant emails etc.) goes to both > > the Front Desk ([EMAIL PROTECTED]) and the DAMs > > ([EMAIL PROTECTED]). > > I cheat by using a file called, say, julian.txt. This list gets that > file emailled to it. The two heavies get that file plus all the other > stuff you mentioned. I hate typing twice. > > The actual report itself are the same. Actually, that's what I do too. I'll modify AM-HOWTO to reflect this. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
New version of AM-HOWTO
[This version takes account of various people's comments -- jdg] Mini-HOWTO for Debian New Maintainer Application Managers Copyright Julian Gilbey <[EMAIL PROTECTED]>, September 2000 This is in the public domain. The fount of all knowledge is the New Maintainer pages. Start at http://www.debian.org/devel/join/newmaint and look around until you are familiar with the contents. Your responsibilities as an AM are described there. As an AM, you will also be subscribed to the AM list: [EMAIL PROTECTED] Please feel free to ask for help there; we are a friendly list all trying to get volunteers into the project! Note that as this is an archived public list, questions of a highly personal nature should be asked to the Front Desk privately. Also, please do not send anything like photo IDs to this list. The other crucial web page is the database: http://nm.debian.org/. You will have received a login there (and it's not encrypted, so please don't use a sensitive password); see the bottom of that page. This database is used to record the progress of your applicants. You are also able to specify how many applicants you are willing to process at once (go the the link at the side "Your profile" to do so). If you ever do not have enough time to take on more applicants, simply change this number to zero. The rest of the database pages are fairly self-explanatory. If you ever have an applicant who is taking too long to respond or who needs to wait for a couple of months (vacation or whatever), you can always put them "on hold" so that you can take on another applicant. There is a text field "AM Comments" for noting the reasons for such things, or for noting any other significant information for the front desk and DAM to note. The four email addresses of note are: NM Admin list: [EMAIL PROTECTED] A public list for discussion of issues among AMs. It is a closed list, but is mirrored to the NM discussion list, so please don't post very personal information here. (Questions about ID verification, etc, are OK.) NM Discussion list: [EMAIL PROTECTED] A general list for discussion about the NM process. -admin is mirrored here. It is not necessary for AMs to read this list, but AMs are, of course, welcome to do so. Front Desk: [EMAIL PROTECTED] Where initial applications get sent, and where the final full report gets sent. Any personal questions about individual applications which are inappropriate for a public forum should be directed here as well. Debian Account Managers (DAMs): [EMAIL PROTECTED] Where the final report is also sent. The DAMs are responsible for creating the accounts on the Debian machines and adding the GPG keys to the keyring. They also get to make the final decision on each application, as the official New Maintainer delegates of the Debian Project Leader. Don't hassle the DAMs, they are usually very busy! Finally, to make life easier, I found it useful to create some form letters, and these are attached below as follows: Appendix 1: Sample initial email Appendix 2: Sample email about skills, procedures and intro to philosophy Appendix 3: Sample questions on philosophy Appendix 4: Sample report for AM list (possibly GPG sign and send to [EMAIL PROTECTED]); this should also be attached to the Front Desk/DAM report Appendix 5: Sample report for Front Desk and DAM (GPG sign and send to both [EMAIL PROTECTED] and [EMAIL PROTECTED]) -- APPENDIX 1: SAMPLE INITIAL EMAIL Hello *! I have just been appointed Application Manager for your Debian maintainership application. I have not seen your original application, so I know nothing about you or your application, I'm afraid. As a first step, have you checked out the New Maintainer corner of the website? Have a look at http://www.debian.org/devel/join/newmaint, and especially at the checklist referred to from there. That's what we'll have to work through together. So, if you can start by letting me have the following, we should be able to progress fairly quickly: - GPG key (preferably signed by a current developer or certification authority) - If your GPG is not signed by a current developer, you will need to also provide a piece of GPG-signed digitally photo ID (let me know if this is a problem; there are other ways to handle this step, but this is the easiest) - your preferred account name for the Debian machines - the email address you would like to be subscribed to debian-private If you can also let me know a bit about: - what you intend to do within Debian - what skills you possess in order to be able to do this sort of work that would be useful. Once we've done this, we can look at &quo
Re: AM report for Marek Habersack
On Tue, Sep 19, 2000 at 01:39:28PM -0400, H. S. Teoh wrote: > Report for new developer applicant: Marek Habersack > Phone contact information > - [...] This sort of personal information MUST NOT be posted on a public list. Only a summary is to be sent to this list; the full detailed report is ONLY sent to the Front Desk and DAMs. Dale: maybe the -admin -> -discuss gateway does need moderating after all, unfortunately. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
AM report: Yves Arrouye
Report for returning developer applicant: Yves Arrouyne 2. Identification - Yves has provided a signed photo ID and a new GPG key. Yves is a returning developer and will be taking back the packages which he originally wrote for Debian: libpaper and psptools, both of which are up for adoption/orphaned. Welcome back, Yves! Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: AM Mini-HOWTO
On Sat, Sep 23, 2000 at 12:51:10AM +0900, Taketoshi Sano wrote: > I think Debian uses several format. DDP usually uses debiandoc-sgml, > but www team uses wml. > > And in this case of New Maint AM HOWTO, the author, Julian Gilbey, > wrote that he uses plain text to make it easily used in emails. > So, I just respect the author's decision. I'm happy for it to be translated into whatever format is wanted/required. But it would be wise if the content of the example emails were just in "plain text" or "verbatim" or whatever, so that they can be cut and pasted. Maybe even have them as separate little files linked from the list at the end of the main section. Most of the HOWTOs I have on my system seem to be in plain text, anyway. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
AM report for Martin Michlmayr
Report for new developer applicant: Martin Michlmayr Summary: I recommend the acceptance of Martin as a Debian Maintainer 2. Identification - I met with Martin personally and have now signed his GPG key. 3. Philosophy and Procedures Martin demonstrated a clear understanding of the Social Contract and DFSG. He is also knowledgeable about the current debates surrounding the non-free issue ;-) He has read the main procedural information such as policy and the packaging manual, and appears to have a good understanding of them. 4. Tasks and Skills --- Martin has packaged cplay, a small Python script for playing audio files. He is also interested in becoming involved with Debian publicity: he was a volunteer for GNUStep publicity and also worked for Linux International's publicity section. His other interest is in working on the MIPS port, provided he can get access to a MIPS machine. He has shown that he is competent by correctly packaging cplay. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
DMUP
Should we mention the Debian Machine Usage Policy to our applicants? I think it might be a wise thing to do, at least in passing Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Final report for Andreas Mueller
On Tue, Sep 26, 2000 at 05:17:23AM -0400, Dale Scheetz wrote: > James: Just one note for you. Although Andreas' key is signed and seems to > be ok, it fails to confirm his signature on documents. It isn't clear > exactly what is wrong, and I'm not the right person to fix it, so while > you have my apologies for dumping work on your shoulders, I have no other > choice. Please help Andreas resolve his key difficulties... Have you tried confirming his signature using the --emulate-md-encode-bug option to gpg when attempting to verify the signature? If that makes it work, then he'll need to upgrade to gnupg-1.0.2 or later and generate a new key. That's what James posted recently. Sorry for the hassle. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
NM process reasons
I was asked by one of my applicants why Debian is unlike other OSS projects, requiring an identification and philosophy check, etc. I explained to him the reasons as I see them, but I think it would be a good idea to put them on the front page of the NM corner (http://www.debian.org/devel/join/newmaint), immediately after the "Contents" section. Something like (only in sketch form today): Why does Debian require the NM process? - developers have to be trusted: root on lots of boxes, no automatic peer review or checking of uploads, etc. - developers much more independent than in a "single piece of software" project - so big mistakes or malice are in general much more serious than in a small OSS project - so Debian needs to attempt to ensure that potential developers are competent and identifiable -> accountable. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Data does NOT belong in Debian (was: Stop Archive bloat)
> Examples of data packages which does NOT belong to debian (IMHO): > 2) Any kind of text easily findable on the web (RFCs (even though I > love to have RFCs around, but we have a draw a line)) NO!! RFCs are *very* important when writing software. They are the standards upon which a large amount of free software is based and are absolutely crucial to developers. Why should they have to hunt the web for such stuff? Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Data does NOT belong in Debian (was: Stop Archive bloat)
> Philippe Troin <[EMAIL PROTECTED]> writes: > > > 1) The way the Debian archive works requires the data to be stored > > twice (source package and .deb). > > Why not allow Source only packages ? Or have a small .deb which installs the data and the data as a tar.gz/tar.bz2 file which is symlinked from source or something like that? Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Data does NOT belong in Debian (was: Stop Archive bloat)
> Hi, > > > NO!! RFCs are *very* important when writing software. They are the > > standards upon which a large amount of free software is based and are > > absolutely crucial to developers. Why should they have to hunt the > > web for such stuff? > > I think it's possible for _everyone_ to mirror (for example) > http://www.rfc-editor.org/categories/rfc-standard.html on his computer if he > wants these things. > > There are also other ways to do it. (e.g. I have written a few scripts which > make it possible to keep a local 'cache' of rfc documents and if I need one > which is not in there it gets automatically fetched.) > > I think everyone is able to find a solution for these day-to-day tasks. > These are not the problem a distribution should cover. Such scripts would be a very useful addition to the archive. Also, you have to realise that not everyone has a decent (or cheap) net connection, and looking through dozens of RFCs can take a long time if they are not locally available. There is a huge amount of stuff which is easy to download/mirror/whatever, but one of the nice things about Debian is that important things are available as standard on the CDs of the distribution. I personally regard RFCs as generally important to anyone programming any net-aware or net-related software. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Proposed change to Debian constitution
> If you don't like the fact that the Delegates have chosen to close > new-maintainer, and are too lazy to actually get off your arse to do > the job yourself but not too lazy to make a fuss, then you can use [...] But the number of people who volunteered to join the NM team was substantial, and yet all were turned down by the then team. However, I think feelings within the project and probably the project itself would have been far more badly hurt by resorting to a vote than by waiting for the NM system to collapse, as we ended up doing. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Proposed change to Debian constitution
> > But the number of people who volunteered to join the NM team was > > substantial, and yet all were turned down by the then team. However, > > I think feelings within the project and probably the project itself > > would have been far more badly hurt by resorting to a vote than by > > waiting for the NM system to collapse, as we ended up doing. > > Well, maybe because all but 1 people tried to help technically > instead of working on the issue on the proper stage. (sorry, can't > express it like I want). Fair enough. But now: what can *I* do to help the situation? Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Debian Law... come to Debian country!
> Hi,
>
> Constitution, Immigrant restriction ("new maintainer"), Usage Policy,
> ...
>
> ... is this where it leads to? Are we going to tight ourselve in a
> magnitude
> of rules and laws, to be enforced by soldiers who work under the regime
> of a
> king (beheaded annually)?
About the DMUP:
It is perceived that there is a need for such policy in the very few
occasions that such a situation arises. (In my time as a developer,
such a situation has arisen more than once.)
Such policies do not affect 99.8% of developers, but on the rare
occasions that someone does step significantly out of line and claim
that they did not realise that what they were doing was unacceptable,
the DPL can point them to the relevant document.
About the other documents:
Pretty much the same seems to apply: they are created in response to a
perceived need.
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
New maintainer?
It seems that, despite Wichert's proposal, new maintainer is still in limbo. Seeing as the freeze has been delayed by a few months, there is no excuse not to reopen NM. What can we do about this? I am willing to help. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Getting rid of section "base" ?
On Mon, Nov 29, 1999 at 01:45:17AM +0100, Goswin Brederlow wrote: > Just some examples: Why are devscripts in util and not in devel? Aren´t > they for developement? devscripts (2.1.1) unstable; urgency=low * Moved package from utils to devel (closes: #33410) -- Julian Gilbey <[EMAIL PROTECTED]> Sun, 21 Feb 1999 00:52:26 + Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
When NM reopens
I've just had a thought, prompted by a new potential developer's question on the -qa list. When the floodgates reopen soon, we're going to have a lot of new developers and not that many easy packages to work on initially. I know for myself that packaging a straightforward, essentially clean and bug-free initial package, taking it through the manual -> debhelper transition, etc., was a really good learning experience. I guess that it would be a wise idea for seasoned developers to consider offering simple packages to the incoming new maintainers so that they can learn the packaging tools and the intricacies of policy requirements without having to cope initially with a large number of bug reports. I would be happy to hand on some of my simple packages to the new developers and even do some handholding. Anyone else think similarly? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Incoming
On Mon, Apr 03, 2000 at 01:22:12PM +1000, Craig Sanders wrote: > debian 'unstable' is perfectly usable for production servers, using it > for such does not require any more caution about upgrades than using > debian 'stable' or debian 'frozen'. Like during the Perl transition period, or when a recent libstdc++ broke apt, or when su stopped being able to su, or when Need I continue? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Incoming
On Mon, Apr 03, 2000 at 03:48:00AM -0600, Jason Gunthorpe wrote: > > On Mon, 3 Apr 2000, Julian Gilbey wrote: > > > Like during the Perl transition period, or when a recent libstdc++ > > broke apt, or when su stopped being able to su, or when > > What you are describing is a problem with the package life cycle, not the > replication of incoming. Let me reiterate: > > DO NOT USE INCOMING > > The files may be trojans, corrupt, partial, massively screwed, fail > lintian, whatever. Massive, massive caution is advised! Absolutely! I was just pointing out how "stable" and "reliable" unstable can be. Using Incoming just makes things worse. I can't be the only maintainer to have pulled packages from Incoming when I've realised that I've made a serious mistake. Can I also recommend the use of Roderick Schertler's dscverify program in devscripts in conjunction with the debian-keyring package to ensure that at the very least the package is properly signed. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: The proposed GR: catch-22
On Wed, Jun 07, 2000 at 09:06:41PM -0400, Thomas Bushnell, BSG wrote: > Chris Lawrence <[EMAIL PROTECTED]> writes: > > > 1. It will have minimal effects since people will still be able to use > > non-free software. > > > > 2. It will have far-reaching effects since Debian (the corporate > > entity) will expend fewer resources in support of people wanting to > > use non-free software. > > I'm somenoe who has made these points, or something like them, but I > think they are both mispresented in order to make them look > contradictory. > > The correct version of 1 is: > > 1) It cause minimal disruption of users since people will still find >it as easy to use non-free software if they want. And how/where will they find it? Not as easy as adding "non-free" to the end of their apt/sources.list lines. > The correct version of 2 is: > > 2) It will have important effects on Debian, because we will maintain >our actual focus, devoting our resources to Debian. ??? What do you mean? What are "our resources" and how is this proposal going to change matters? The developers maintaining non-free are hardly likely to stop just because their packages are now going to live elsewhere. Don't tell me that the <1GB of non-free is the issue, 'cos that's all donated anyway, and I do not believe that the marginal costs of administering non-free are significant. > non-free is not part of Debian, so why are we distributing it? For > the convenience of the users. If it were not for that, we would never > consider it. Since we can meet the convenience of the users in a way > which does not require weakening the principles upon which Debian was > founded. we should do it. And how, exactly, would that work? Do you have any idea how many complaints I heard when Debian only changed its internal archive structure a couple of releases ago? How many lusers couldn't figure it out? Get real! Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: [PROPOSAL] Allowing crypto in the main archive
On Wed, Jan 10, 2001 at 04:16:18PM -0800, Wichert Akkerman wrote: > > This is a slightly updated changed to reflect comments from people. > Debian developers can second this proposal for inclusion in the > policy text. > > Proposal is to change section 2.1.5 of the Debian policy to say: > >Non-free programs with cryptographic program code need to be stored >on the "non-us" server because of export restrictions of the U.S. > >Programs which use patented algorithms that have a restrictied >license also need to be stored on "non-us", since that is located >in a country where it is not allowed to patent algorithms. > >A package depends on another package which is distributed via the >non-us server has to be stored on the non-us server as well. > > If this proposal gets accept it means Debian also shoud: > * notify the US government that we have a FTP site that distributes > crypto software. > * add a legal welcome message to our FTP site that informs people > about the regulations regarding crypto software. This also means > we will not be consciously exporting crypto to the 7 blacklisted > countries Assuming that the legalities are OK (IANAL), I second this proposal. It will certainly clean up some messy stuff (eg enabling fetchmail ssl mode). Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: [PROPOSAL] Allowing crypto in the main archive
On Wed, Jan 10, 2001 at 04:27:37PM -0800, Wichert Akkerman wrote: > Okay, hopefully the final language change: > > Proposal is to change section 2.1.5 of the Debian policy to say: > >Non-free programs with cryptographic program code must be stored on >the "non-us" server because of export restrictions of the U.S. > >Programs which use patented algorithms that have a restrictied >license must also be stored on "non-us", since that is located in a >country where it is not allowed to patent algorithms. Better English: Programs which use patented algorithms that have a restricted license must also be stored on "non-us", since the "non-us" server is located in a country where patenting algorithms is not permitted. By the way, what does "restricted license" mean in this context? Surely even if the license is DFSG-free, the software would have to live on non-us if the algorithm is patented? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: [PROPOSAL] Allowing crypto in the main archive
On Thu, Jan 11, 2001 at 09:20:35AM -0800, Pete Lypkie wrote: > >Programs which use patented algorithms that have a restricted > >license must also be stored on "non-us", since the "non-us" server > >[...] > > By the way, what does "restricted license" mean in this context? > > Surely even if the license is DFSG-free, the software would have to > > live on non-us if the algorithm is patented? > > the "restricted license" refers to the license on the patent, i believe. Say > you go out and get a patent on "Julian Sort", but then you allow anyone > anywhere to use it without royalties. That would be a patented algorithm > without a restricted license. in this case, i think a program that uses > Julian Sort would still be allowed in main, even though it used a patented > algorithm. > > on the other hand, charging $5 for every execution of Julian Sort would be in > the category mentioned in the paragraph above. this program would have to be > in non-us. Ah, now I understand. Thank you. Could we word things a little more clearly perhaps? Any suggestions? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Retiring
Thank you for the work you have done! Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: CLarksville Linux Users Group
On Sun, Feb 18, 2001 at 04:41:20PM +, Larry Greenleaf wrote: > A few weeks ago, I sent you the following email and have not yet gotten > a reply. I can't tell you > enough how much your support helps not only our LUG, but every LUG. > Please send any > software/information to: > [...] > > To whom it may concern, > > My name is Larry Greenleaf and I am the vice president of the > CLarksville Linux Users Group. We are a group of Linux enthusiasts > who wish to spread the good word about the almighty penguin and > show people that they are not bound by the constraints of certain other > operating systems that shall remain nameless. I am writing to you to > enquire about the possibly of getting some software from you to pass > out at our demo days. We have 20-30 people in our LUG. We generally > do a demo day every three months or so depending upon availability of > software. I cannot stress enough how support from large vendors, such as > > yourselves, play in advocating Linux. People like to get free stuff so Please see http://www.debian.org/. You will ascertain very quickly that we are a volunteer organisation, not a large vendor. We produce CD images (http://cdrom.debian.org/) but do not actually produce or sell CDs ourselves. If you are looking for Debian CDs, please ask a CD-ROM distributor. Or maybe there is some nice person out there willing to donate some CDs? Good luck in your endeavours! Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: [PROPOSAL] Allowing crypto in the main archive
On Tue, Feb 20, 2001 at 02:49:14PM +0100, Rene Mayrhofer wrote: > Ok, I know I am a bit late, but since I recently got my Debian > developer status and this is exactly what I asked for in my mail on > 2001-01-01, I second this. > Are 2 seconds (this should be the 2. second on this phrasing if I > have not > missed any) enough to make it official ? It's already accepted. I believe that we are just waiting for legal expertise before we make it policy and start acting on it: no number of non-legal-expert developers should make a decision on a matter such as this without expert guidance. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: MIA Maintainer Process Proposal
On Wed, Feb 28, 2001 at 01:58:20PM -0500, Patrick Ouellette wrote:
>
> Attached is a proposal for dealing with MIA maintainers.
Good guidelines. One point: we must always remember to check whether
a maintainer has filled in the "On vacation" field in the DB.
Occasionally, developers are forced to go on extended leave (army
callups or similar).
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
Debian GNU/Linux Developer, see http://people.debian.org/~jdg
Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: MIA Maintainer Process Proposal
On Thu, Mar 01, 2001 at 04:08:06PM +0100, Wichert Akkerman wrote: > Previously Julian Gilbey wrote: > > Good guidelines. One point: we must always remember to check whether > > a maintainer has filled in the "On vacation" field in the DB. > > Occasionally, developers are forced to go on extended leave (army > > callups or similar). > > Some maintainer also forget to remove that data.. I've seen people > who were listed as being on vacation even though they returned 6 > months earlier. I did so once. But because I said "until ", it was obvious. Maintainers should, ideally, do that. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Working on debian developer's reference and "best packaging practices"
On Tue, Apr 30, 2002 at 03:46:17PM -0500, Manoj Srivastava wrote: > Hi, > > Apropos to that, Policy proper contains elements that ought > not to be in there, but remain as vestigial documentation of dpkg > (which is how policy started). Policy is going to be cleaned up and, > and perhaps rewritten (probably in DocBook format) post woody (I like > the layout of the sections in the FHS 2.2 document); and made into a > more coherent, leaner version, as befits a standard document. Some of > the examples need to be pruned from the policy proper; so a look into > policy would be appreciated. > > My vision of policy is like that it is analogous to, say, the > C standard, and not a DPKG for dummies or teach yourself packaging in 24 > hours kind of document. It would be nice if the "Debian Best > Packaging Practices" document plays a complementary role and picks up > the slack. It would perhaps make policy more digestible. That sounds like a fabulous idea. What I would *really* like to see happen (and help with), post-woody, is something like the annotated C reference manual, which has the standard clearly identified, but lots of extra bits of rationale, examples, best practices and so on. In this way, we get the best of both worlds: we can create a clean standards-only document by some simple selective processing (ignore all extra sections when processing, or something like that), and meet the most frequent complaint about the old policy + packaging manual: they contradict, and I have to look in two documents. I've been thinking of having a merged policy/packaging manual for a while, but suddenly realised when I read your mail above that this might be the ideal way to do it to provide the best for everyone. Thoughts? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and "best packaging practices"
On Thu, May 02, 2002 at 12:03:38AM +1000, Anthony Towns wrote: > > and meet > > the most frequent complaint about the old policy + packaging manual: > > they contradict, and I have to look in two documents. > > Considering the packaging manual doesn't exist anymore, I don't see how > anyone could make that complaint. People *used* to make that complaint. And if we now move to having a lean policy standards document and a developers reference and a best programming advice document and a dpkg documentation document, we'll have even more complaints in that direction. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and "best packaging practices"
On Thu, May 02, 2002 at 01:44:50AM -0500, Manoj Srivastava wrote: > Anthony> Policy at the moment provides a fairly thorough grounding in > Anthony> Debian's best practices. That's highly useful. > > Thorough is a matter of opinion. I think it is inconsistent, > bumbling mess, occasionally wrong, and bloated, it occasionally > contradicts itself, related issues are often scattered throughout the > document, it does not have enough rationale. Its coverage of best > practices is patchy, and what there is adds to the problem > determining what is policy and what is the document merely being > chatty. I totally agree with Manoj here. I think that before anyone sits down a rewrites the policy document (which we really need to do!), we should agree on a sensible structure that is likely to work. Doing too much detailed writing at this stage seems a little pointless. Here is a very brief attempt at a draft structure, which will certainly need improving, but gives an idea of what I mean: Part I: The Debian Archive 1: DFSG and the sections of the archive (free, non-free, contrib, non-us) 2: The different distributions (stable, etc.) Part II: Packages and metadata 3: Package structure (source, binary, arch-dep/indep) 4: Control fields: source package fields 5: Control fields: binary package fields 6: Package dependencies: binary packages 7: Package dependencies: source packages Part III: Packaging scripts and files 8: Maintainer scripts 9: Other miscellany: debian/rules, changelog, files, substvars, etc. 10: Configuration files 11: Shared libraries Part IV: Other packaging issues 12: The operating system (cron, init.d, etc.) 13: Issues concerning files (permissions, links, scripts, etc.) 14: Documentation Part V: Debian subsystem issues 14: X Windows policy 15: Perl policy 16: Menu policy 17: Emacs policy ... Part VI: Programming guidelines and best practices [There may be something which fits here] Then each section could either have the structure: Policy dictates Discussion, useful information, guidelines, examples or we could merge them, and have policy dictates all in the form MUST, SHOULD, MAY, MUST NOT, etc., as in the RFCs. (As far as RC issues goes, this could be marked by (RC) after the MUST/SHOULD/whatever, with a catchall at the start of policy that the final decision on what is RC rests with the release manager.) Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and "best packaging practices"
On Thu, May 02, 2002 at 02:30:34PM +0200, Wichert Akkerman wrote: > Previously Julian Gilbey wrote: > > Part I: The Debian Archive > > 1: DFSG and the sections of the archive (free, non-free, contrib, non-us) > > non-us is a different archive. I understand; this was just an imprecise abbreviation ;-) Sorry for any confusion. > > Part II: Packages and metadata > > Refer to a dpkg reference instead and document extra restrictions Surely either everything necessary should be in the dpkg reference or everything necessary should be in policy. I really don't want to see it split up into two separate documents, for that way lies madness again. I understand that dpkg can be used elsewhere than Debian, but it's de facto purpose is to serve as the Debian packaging system. So if the dpkg reference doesn't document everything that Debian needs in this respect, what is the best thing to do? To make people read two (possibly, even probably contradictory) documents? Or to have all of the relevant stuff in both documents? Ho hum. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and "best packaging practices"
On Thu, May 02, 2002 at 03:20:45PM -0500, Manoj Srivastava wrote: > >>"Julian" == Julian Gilbey <[EMAIL PROTECTED]> writes: > > Julian> On Thu, May 02, 2002 at 02:30:34PM +0200, Wichert Akkerman wrote: > >> > >> Refer to a dpkg reference instead and document extra restrictions > > Julian> Surely either everything necessary should be in the dpkg reference or > Julian> everything necessary should be in policy. q > > Umm, no. It does not make sense to restrict dpkg authors to a > static, slow changing mechanism that is policy as the blueprint for > their software development. The dpkg authors must be free to > innovate, and document additional features, and evolving behaviour. Good point. > On the other hand, all packages must not be left to the whimsy > of the dpkg developers either; since potentially large numbers of > packages would be impacted by such changes. Understood. > Going to either extreme is suboptimal. Makes sense. > What we need to do is specify a minimal set of interfaces that > all packages are required to provide, and that the dpkg authors must > maintain compatibility for. Agreed. > Changes to this core functionality would require a transition > plan to effect, but otherwise dpkg authors are free to make changes > and extentions. Most extentions, when the become popular, would be > candidates for inclution into the core interface, when the dpkg > authors feel the interface has stabilized and would be unlikely to > change. OK. But we must then be very careful about how the splitting of information works and how the two are kept compatible. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and "best packaging practices"
On Fri, May 03, 2002 at 09:34:58PM +1000, Anthony Towns wrote: > On Thu, May 02, 2002 at 10:09:11AM +0100, Julian Gilbey wrote: > > Part I: The Debian Archive > > 1: DFSG and the sections of the archive (free, non-free, contrib, non-us) > > > "Components" is a much better word to use here. (And is the word used > everywhere but -policy, just about) Fine. > > 2: The different distributions (stable, etc.) > > I.2 is probably more properly done in the developer's reference, since > it doesn't impact how you go about constructing an ideal Debian package. It affects how you write the changelog entry. So maybe it should go in both. > Priorities? Sections? Yes, of course. > > Part II: Packages and metadata [...] > changelogs? copyright files? Of course. > Perhaps something like: > [...] > ...would work out well? Maybe. Definately worth considering. > > Then each section could either have the structure: > > Policy dictate s > > Discussion, useful information, guidelines, examples > > or we could merge them, and have policy dictates all in the form MUST, > > SHOULD, MAY, MUST NOT, etc., as in the RFCs. > > I'm quite confident that trying to differentiate between requirements > and guidelines like this will turn out to be completely unhelpful and > a large waste of time, personally. Don't RFCs do this frequently? And I've never heard people making such a complaint about them. > > (As far as RC issues > > goes, this could be marked by (RC) after the MUST/SHOULD/whatever, > > with a catchall at the start of policy that the final decision on what > > is RC rests with the release manager.) > > As far as RC issues go, they'll be specified in an entirely separate > document, not maintained by the policy group. Do you really expect bug submitters to consult yet another document, or is it just so that you can point people to it and say "See, this is not considered an RC bug!"? (I have no objection to there being another document per se or to the policy group not being in control of the list of RC issues.) Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and "best packaging practices"
On Fri, May 03, 2002 at 08:02:50PM +1000, Anthony Towns wrote: > If the dpkg authors would like to hand off some of their design decisions > to -policy on a generalised basis, I'm sure they'd say so. It seems a bit, > well, wrong-headed for -policy to be trying to take control of dpkg though. Quite: IMHO discussion is about where the documentation should be found, not about the maintenance or control of dpkg! The dpkg developers do a great job, and I have much respect for them. > > since potentially large numbers of > > packages would be impacted by such changes. > > The dpkg maintainers are well aware of the likely impact of their changes, > and are quite able to ask for advice when it's needed. > > I'm concerned about this because when I tried passing over > "release-critical policy issues" to the policy group, it didn't work. Not > only did everyone regularly and frequently lose track of what the point of > "must versus should" was, but people just weren't very good at knowing > when to choose which. Which is fine: we tried an experiment, it didn't > work out how we'd hope, let's move on. But let's not just repeat the > same mistake when there's no reason to do so. Strawman (to quote lots of others). As a concept, it's very good, but as we discovered, the implementation was poor. My suggestion for a policy rewrite it to move to the standard RFC uses of MUST and SHOULD, and indication RC-ness in an orthogonal way. I think this will make life easier for everyone, and I have no problems at all with the Release Manager dictating what he considers to be RC for this particular release. > Further, considering that everyone seems to think that the -policy > group have done pretty poorly at their actual job -- maintaining > the policy document so that it's readable, consistent and useful -- > it doesn't seem like a good idea to broaden its scope. Rewriting it > into something comprehensible, making the already approved of changes, > and merging all the subpolicies (at least debconf, perl, and python) > is likely to be more than enough work for the forseeable future. Thanks. Appreciated. We need to rewrite policy, and have known this for absolutely ages, but when it absorbed the old packaging manual, it introduced the contradictions (oops). I vaguely recall that at that time, a freeze was effectively placed on substantially rewriting policy because of the upcoming freeze of woody. We are still in this freeze period, and both Manoj and I are itching to rewrite the current spaghetti which is called policy. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and "best packaging practices"
On Fri, May 10, 2002 at 04:02:47AM +1000, Anthony Towns wrote: > On Mon, May 06, 2002 at 06:19:54PM +0100, Julian Gilbey wrote: > > > > Then each section could either have the structure: > > > > Policy dictate s > > > > Discussion, useful information, guidelines, examples > > > > or we could merge them, and have policy dictates all in the form MUST, > > > > SHOULD, MAY, MUST NOT, etc., as in the RFCs. > > > I'm quite confident that trying to differentiate between requirements > > > and guidelines like this will turn out to be completely unhelpful and > > > a large waste of time, personally. > > Don't RFCs do this frequently? And I've never heard people making > > such a complaint about them. > > RFCs have a different goal to -policy. RFCs specify things that get > implemented by different groups and have to be interoperable. -policy > doesn't. > > There is only one "dpkg", there is only one "apt", there is only one > "Debian", and the point of -policy is to make all of these more effective, > not to help random people with nothing better to do implement clones. > > If we were doing the latter (and you and Manoj seem to want to wrt "dpkg" > for no reason I can fathom), then must/should would be useful. But > we're not. If people want to clone dpkg (or finish of libapt-inst so > it can actually install packages; or implement Herring (if anyone even > *remembers* it...)) then more power to them. If someone does do this, > then it might turn out that there are some incompatibilities that need to > be handled specially by packages, and we'll probably add these to policy > when we find them. Who's talking about dpkg here? Policy covers far more than that. For example, when talking about shared and static libraries, there may be exceptional cases where both the shared library and the development parts (headers and static library) live in the same package. Then one would say something like "Source packages providing shared libraries SHOULD produce a binary package containing the shared library and another binary package containing the development files (headers and statically compiled library). The shared library MUST be compiled with the -fPIC option and the static library MUST NOT be compiled with this option. ..." (Please don't correct me on details here -- I haven't checked them up and that's not the point.) So here, the "SHOULD" means that it must behave in this way unless there are exceptional circumstances, and the "MUST" means that there are no exceptions. I may be wrong in the details of this specific case, but this is the way I am thinking. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and "best packaging practices"
On Fri, May 10, 2002 at 03:48:28AM +1000, Anthony Towns wrote: > On Mon, May 06, 2002 at 06:11:46PM +0100, Julian Gilbey wrote: > > On Fri, May 03, 2002 at 08:02:50PM +1000, Anthony Towns wrote: > > > I'm concerned about this because when I tried passing over > > > "release-critical policy issues" to the policy group, it didn't work. [..] > > Strawman (to quote lots of others). As a concept, it's very good, but > > as we discovered, the implementation was poor. > > As a concept it sucked, we just didn't realise it at the time. -policy > isn't competent at judging which issues should be release critical. We > didn't realise this before we tried, no we have tried and it's blatanly > obvious. > > I'd suspect the reason it doesn't work is because there's no downside > for -policy to making a rule a release-critical issue, compared to not > doing it. You guys don't have to try to coerce people into fixing their > RC bugs in a timely manner, nor throw out packages that don't have their > RC bugs fixed, nor deal with the people who absolutely need the package. Whatever you say. Please note, however, the two distinct parts here: (1) Deciding what's RC. I agree with you that this is the job of the release manager. Rather you than me. (2) Recording the decisions. That can either go in a separate document as you describe, or in the body of policy in a clearly marked way as I have suggested. As it is clear that you are the only person who decides which issues are RC and which are not, -policy won't make those decisions but only record the decisions you have made. But at present all of this is hypothetical. Now back to real work. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Working on debian developer's reference and "best packaging practices"
On Fri, May 10, 2002 at 03:48:28AM +1000, Anthony Towns wrote: > > My suggestion for a > > policy rewrite it to move to the standard RFC uses of MUST and SHOULD, > > and indication RC-ness in an orthogonal way. > > In short, this isn't going to happen. There'll be a separate document, > maintained by the release manager. It may or may not be included in > debian-policy.deb. I'm inclined to think it'd be better if it were in > that package, but we'll see. There is, I have just realised, a middle way, which satisfies your concerns and mine. There is an official list, maintained by you, and for convenience, the information could be included in policy, with the note that the official list can be found at . This would parallel the situation with the build-essential package, which provides a convenient way of knowing which packages are considered build-essential, even though the official definition is that given by policy. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#157123: project: modify emacs policy
On Sat, Aug 17, 2002 at 09:32:48PM -0400, Deepak Goel wrote: > > Hello > > Debian's emacs policy seems to be such that additional packages delete > the .el files after installing the package. The .el files hardly cost > any space in comparison to the .elc files, you might as well leave > them there--- we emacsers rely on .el files being right next to the > .elc files. I understand there's a emacs-el or such package that will > install the el files, but this is not true of packages. Thus, i don't > have the emacspeak files, etc. etc. You wouldn't be confusing the directories /usr/share/emacs/site-lisp/*, which contain the .elc files, and the directories /usr/share/emacs/site-lisp/*, which contain the .el files, would you? I think we can close this report. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#157123: project: modify emacs policy
On Sun, Aug 18, 2002 at 07:31:21PM -0400, D. Goel wrote: > > > You wouldn't be confusing the directories > > /usr/share/emacs/site-lisp/*, which contain the .elc files, > > and the directories /usr/share/emacs/site-lisp/*, which contain the > > .el files, would you? > > Julian > > i do see now what you are saying. This takes care of most of my > complaints. However, an important problem remains > > > [1] It seems that, by default, /usr/share/emacs/site-lisp/foo/ don't > get added for most of the packages, whereas > /usr/share/emacs21/site-lisp/foo does get added. where foo > represents the package. > > Some examples of The packages where the former directory did not get > added, for me are: > > erc <-- this one, i am sure of... others are gleaned from lookign at > load-path No, this package *does* have a /usr/share/emacs/site-lisp/erc/ directory in it. > [2] IT is still not perfect to not have the .el files in the same > place as .elc, (i know some stuff depends on that), but that is a > minor issue, and i wil stop bugging you about that :) If a particular package requires the .el files being in the same place as the .elc files, and the package does not work because of that, you should file a bug against that package. See /usr/share/doc/emacsen-common/debian-emacs-policy.gz for an explanation of why the system is set up in this way. (Primarily because the .elc files are emacs-version dependent, whereas the .el files are usually not.) Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Bug#157123: project: modify emacs policy
On Mon, Aug 19, 2002 at 08:54:12AM -0400, D. Goel wrote: > Julian > > > > > [1] It seems that, by default, /usr/share/emacs/site-lisp/foo/ don't > > > No, this package *does* have a /usr/share/emacs/site-lisp/erc/ > > directory in it. > > > We miscommunicated. Yes, the packages *does* have it, but it does not > get added to the load-path. This neglect is true of most Why should it be added to the load-path? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: admins: please clarify /etc/motd on auric
On Fri, Aug 30, 2002 at 02:14:39PM -0500, Branden Robinson wrote: > On Fri, Aug 30, 2002 at 09:13:34AM +0200, Martin Schulze wrote: > > Branden Robinson wrote: > > > Please do not run personal cronjobs on auric between 14:30 and 17:30 > > > > > > I assume this means local time for auric, but it might be nice to add > > > the timezone identifier. > > I don't care what it says as long as clear and unambiguous, which it > currently isn't (or wasn't when I last logged in). Come on, man, throw > us a bone. Say "between 14:30 and 17:30 UTC-0400" or whatever. All it needs to say is "local time", and we need know no more, for the crontabs are understood as being in local time, right? ;-) And for anyone who's interested, running "date" will give us the timezone information. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: Help
On Wed, Oct 02, 2002 at 07:28:39AM -0700, Allen wrote: > > I would like to buy debian but I dont now if other vendors of Debian offer > me what > > you dont. 1. do you offer manuals of isntallations? > > 2. do you offer some kits ? The Debian project does not sell anything: we make it available to everyone over the internet for free. Vendors are able to produce CDs and to sell them if they wish at whatever price they wish. Installation guides are available from the Debian website. Please visit http://www.debian.org/ and go from there! Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London website: http://www.maths.qmul.ac.uk/~jdg/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
