Re: Depends/Recommends from libraries
On Thu, 2017-03-09 at 10:19 -0800, Russ Allbery wrote: > > I think this would be a great way of introducing spurious bugs in our > distribution from people who don't happen to read the README file and > miss > dependencies they actually need because they're used to Debian > properly > picking up shared library dependencies and to the dependencies of any > given package being fully self-contained. Both of which, I should > add, > are major *features* of our distribution that many of us have worked > very > hard to achieve. I'm opposed. > Can we just clarify - in the setup that Ian proposed, a "normal" user would have experience no different to now (except for less bloat); package maintainers and those using -dev libs are the ones who would need to read those docs. Package maintainers in order to ensure they set the correct deps on their packages, and -dev package users to ensure they are aware of which features of a library need extra packages installed in order to function. Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago
Re: init script, installed but not activated
On Wed, 2015-10-07 at 19:21 +0200, Marc Haber wrote: > On Tue, 6 Oct 2015 22:35:38 +0200, Michael Biebl <bi...@debian.org> > wrote: > >If your package does not work unconfigured, a better alternative is to > >check for the existence of a config file. > > This, however, prevents you from delivering an all-comments default > config file in the right place, which makes configuring the package > harder and non-intuitive. > > Checking for a config file with at least one non-comment line in the > systemd-unit is ugly. I don't think we have a good, standard, story for how installation, configuration and enabling of packages that can be used to provide services *should* work. Personally, I'd prefer that packages get a default configuration and services are never enabled on install. However, I get that some/many people would prefer that debconf ask them enough questions to configure a package and that the service be enabled by the end of the install. There might well also be different classes of service with different levels of config requirements - if you install an RPC portmapper, it's more likely to be able to DTRT if it tries to configure and enable than, say, mailscanner. In the middle are services that can ask a few simple debconf questions and then have a good chance of doing the right thing. Some services might also be potentially harmful if enabled by the install process - DHCP servers being a good example. I think this is something that we should have covered by policy, so a user knows what to expect when installing a package (e.g. so they know that they don't need to disconnect the machine from their corporate network before installing isc-dhcp-server). It certainly seems to me that a standard default is needed, and that system-wide configuration of this might be desirable. Am I missing something? Thoughts? Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago
Re: init script, installed but not activated
On Thu, 2015-10-08 at 00:36 +0200, Jonas Smedegaard wrote: > Debian daemons should by default start - then those not wanting them to > start can suppress that. The opposite requires far more custom work for > those who do want daemons to start than it does to suppress startup. Yes, I'm inclined to agree - in general at least. > I believe what you are missing is policy.d: > https://people.debian.org/~hmh/invokerc.d-policyrc.d-specification.txt > http://blog.zugschlus.de/archives/974-Debians-Policy-rc.d-infrastructure-explained.html > https://packages.debian.org/policyrcd-script-zg2 > > How it translates to systemd I don't know, however. Thanks for those pointers; I was aware of invoke-rc.d/policy-rc.d but not quite familiar enough with how they're supposed to work. I still don't think they're adequate alone, but before we get on to that, can anyone clarify how/whether they integrate with systemd? Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago
Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files
On Wed, 2014-10-29 at 21:58 -0700, Russ Allbery wrote: Yes, I agree. But for me apt.conf/Max-ValidTime is useless unless the release file is guaranteed to be updated more frequently than its Valid-Until: header implies. Is it, and is that undertaking documented somewhere? Point. We should have documentation for what the minimum signing frequency we guarantee is, particularly for the security archive. Then, people who are willing to suffer from mirror issues if they're slow can just use that. It seems to me that Valid-Until was a mistake in the first place; the date on which it was signed and the frequency with which it is expected to be re-signed are needed (whether this information is in the file itself or just in the docs), and it's up to the client to decide how old is acceptable given this information. Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago
Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]
On Wed, 2014-09-10 at 18:37 +0100, Ben Hutchings wrote: On Wed, 2014-09-10 at 17:44 +0100, Noel Torres wrote: On Wednesday, 10 de September de 2014 03:12:16 Ben Hutchings escribió: On Tue, 2014-09-09 at 21:24 +0100, Noel Torres wrote: On Tuesday, 9 de September de 2014 21:18:55 Tollef Fog Heen escribió: ]] Carlos Alberto Lopez Perez But if you don't (Is not uncommon to have servers on remote locations that are only accessible via ssh) and the machine don't boots properly you can find yourself in trouble. Then surely you test the upgrade before making it live, using kvm -snapshot or similar functionality? This is simply not possible in physical live, productions servers on remote CPDs. In that case you test on your staging server first... Ben. IF you have an staging server... some clients simply do not pay for it. Then they already accepted the risk of extended downtime during an upgrade. That doesn't, however, mean that it is acceptable for us to recklessly cause such downtime. It seems to me that there is clearly a large group of users for whom an automagic change in init system is desirable, and won't even be noticed. There is however also a large group of sysadmins for whom a noninteractive change of init system is a major, annoying issue. If our priority really is our users, then we can't brush this under the carpet with you should have read the release notes - and certainly not when the problem has been foreseen. That is simply not how you respond to someone you actually care about. Debian has a good and hard-earned reputation for not messing up sysadmins' changes; upgrading to systemd - however wonderful it is (and I confess to having no opinion on that) - without at least a debconf prompt of a reasonable priority telling them what is about to happen and offering a bailout, is guaranteed to lose us reputation and users. It doesn't matter whether we think that's reasonable or not, it is what will happen. So, is it actually feasible to provide such a prompt? Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago
While we're at it... (keys)
I've been putting off generating a new key because I want to make sure I know how I'm going to manage the new one before I generate it (i.e. avoiding leaving it sitting on my desktop machine, not typing the passphrase on that machine, etc.). Has anyone written up key management for Debian developers? - how does everybody else do it? I'm sure I've heard a wide variety of answers when I've asked in the past - e.g. I keep it on a USB key and only plug it in when needed, I keep it on a separate machine that has no network connection and transfer everything to and from signing by sneakernet, I use some kind of hardware dongle to hold it etc. Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago
Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!
On Wed, 2014-03-05 at 10:47 +0800, Paul Wise wrote: On Wed, Mar 5, 2014 at 1:55 AM, Xavier Roche wrote: I have a rather silly question: would a mail (signed with this key) request to the DDs who already signed the initial key (and checked the identity) to sign the replacement key considered unreasonable ? Considering that the initial keys are now considered weak, I expect that it would be reasonable for people to not trust a key transition statement where the only available trust anchor is the old weak key. That is however no reason not to do it - you're still better off than you were before (equally weak, but with the potential to improve). Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago
Re: Backports, Stable releases, Testing, Oh my!
On Wed, 2014-02-26 at 09:47 +0100, Gerfried Fuchs wrote: Erm, no, not at all. A package in stable-bpo can't have a newer version than testing when we release. With the removal there can be two situations: * After fixing the issue that got the package removed from testing, the package flows in like usual into testing, and it will definitely have at least the version it had in testing before, most probably higher, but never lower. * The package doesn't flow into testing anymore before the release. If this is expected to happen, the package has to be removed from stable-bpo. What shall we do? Remove from stable-bpo? Hope an update comes around? Remove from stable-bpo if it's not expected to come back in is what we actually do, yes. And to have an overview of these situations I created myself the diffstats page: http://backports.debian.org/wheezy-backports/overview/ And if the newer version, for example, has updated a database schema in a non-backward-compatible way? Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago
Re: Bug#721517: ITP: python-httpretty -- HTTP client mock for Python
On Sun, 2013-09-01 at 22:17 +0800, Thomas Goirand wrote: Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-httpretty Version : 0.6.3 Upstream Author : Gabriel Falcao * URL : https://github.com/gabrielfalcao/httpretty * License : MIT Programming Lang: Python Description : HTTP client mock for Python Once upon a time a python developer wanted to use a RESTful api, everything was fine but until the day he needed to test the code that hits the RESTful API: what if the API server is down? What if its content has changed ? . Don't worry, HTTPretty is here for you. As someone who might be interested in using this package, that description needs to be rather more specific. I'm sure I ought to be terribly reassured that HTTPretty is going to be there for me, but it would be more helpful to tell me what this package actually does. Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago
Re: Bug#717083: ITP: pychef -- Python library to interact with the Chef server API
On Tue, 2013-08-06 at 20:42 +0100, Wolodja Wentland wrote: On Tue, Jul 16, 2013 at 12:23 -0300, Miguel Landaeta wrote: Package: wnpp Severity: wishlist Owner: Miguel Landaeta mig...@miguel.cc * Package name: pychef Version : 0.2.2 Upstream Author : Noah Kantrowitz n...@coderanger.net * URL : https://github.com/coderanger/pychef * License : BSD Programming Lang: Python Description : Python library to interact with the Chef server API (Include the long description here.) Please provide a suitable long description so that we can review it. I personally also prefer to not start the synopsis with a capital letter. FWIW Python as a proper noun gets a capital letter no matter where it is in a sentence. There's nothing wrong with his description. Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago
Accepted teapop 0.3.7-5 (source powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 13 Feb 2007 21:58:18 +1300 Source: teapop Binary: teapop-mysql teapop-pgsql teapop-ldap teapop Architecture: source powerpc Version: 0.3.7-5 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Nick Phillips [EMAIL PROTECTED] Description: teapop - Powerful and flexible RFC-compliant POP3 server teapop-ldap - Powerful and flexible RFC-compliant POP3 server teapop-mysql - Powerful and flexible RFC-compliant POP3 server teapop-pgsql - Powerful and flexible RFC-compliant POP3 server Closes: 409771 Changes: teapop (0.3.7-5) unstable; urgency=low . * Update build-dep on postgresql-dev to libpq-dev. Closes: #409771 Files: 17d5b85d881525091e7ca155d8d6a901 589 mail extra teapop_0.3.7-5.dsc 7673cac36173c06aecba0ce987b8cde7 230726 mail extra teapop_0.3.7-5.tar.gz 727ade5440a7815bc26965cd3162918e 72164 mail extra teapop_0.3.7-5_powerpc.deb abf2210c6c28801961c68c7098c907d9 75588 mail extra teapop-mysql_0.3.7-5_powerpc.deb 4a06709f05648ef0a7bc25f0d19e6213 74980 mail extra teapop-pgsql_0.3.7-5_powerpc.deb 12aa90d7f87be422875c8c13cd124ae7 74946 mail extra teapop-ldap_0.3.7-5_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF2BKIdZJIm8yYOSgRAmlEAKDaHP/s6+Uya2Q3g0poXyCm8imxEgCfYynp t9RFerE7zX/BPbDKIxqvZ3I= =FVlU -END PGP SIGNATURE- Accepted: teapop-ldap_0.3.7-5_powerpc.deb to pool/main/t/teapop/teapop-ldap_0.3.7-5_powerpc.deb teapop-mysql_0.3.7-5_powerpc.deb to pool/main/t/teapop/teapop-mysql_0.3.7-5_powerpc.deb teapop-pgsql_0.3.7-5_powerpc.deb to pool/main/t/teapop/teapop-pgsql_0.3.7-5_powerpc.deb teapop_0.3.7-5.dsc to pool/main/t/teapop/teapop_0.3.7-5.dsc teapop_0.3.7-5.tar.gz to pool/main/t/teapop/teapop_0.3.7-5.tar.gz teapop_0.3.7-5_powerpc.deb to pool/main/t/teapop/teapop_0.3.7-5_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
On Fri, May 19, 2006 at 03:46:28PM +0200, Wouter Verhelst wrote: That's not an issue. First, ed doesn't install an alternatives for editor. Second, there's also 'by_vote', which puts vim on top. Which is an excellent demonstration of why we should not use popcon to decide alternatives priorities. nano is a more sensible default because it is usable by newbies and by people who do not understand the concept of a modal editor. Being popular is overrated... Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#364940: ITP: libkwiki-plugins-perl -- Plugins for Kwiki
On Wed, Apr 26, 2006 at 02:54:47PM -0500, Jaldhar H. Vyas wrote: Package: wnpp Severity: wishlist Owner: Jaldhar H. Vyas [EMAIL PROTECTED] * Package name: libkwiki-plugins-perl Version : 0.01 Upstream Author : Various. Compiled by Jaldhar H. Vyas [EMAIL PROTECTED] * URL : N/A * License : GPL+Artistic Description : Plugins for Kwiki This is a collection of plugins for Kwiki, the quickie wiki that's not too tricky. They are packaged together to avoid bloating the archive with lots of little packages. You might want to have a look at the pkg-kwiki area on alioth. There are a bunch of plugins set up to be packaged in svn there, along with the other kiwki stuff. I packaged the kwiki 0.3x stuff but have subsequently migrated to moin, so if you're interested in kwiki in general... Probably best you (and anyone else interested in the Kwiki packging) contact me off-list and we can sort something out. But it would be a bad idea to package these as you describe without either co-ordinating it with the pkg-kwiki project, or taking it over yourself. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Thu, Feb 09, 2006 at 06:37:57PM -0800, Thomas Bushnell BSG wrote: Nick Phillips [EMAIL PROTECTED] writes: You are of course assuming that there is some way of making an absolute determination as to the DFSG-compliance of a license, when there is not. No, I'm not. I'm saying that when the Secretary makes a ballot, he must make a determination as best as he can. From your previous mail: If the license is not DFSG-compliant, then a resolution to declare that it is so, is either a dead letter, or else works a rescinding of the DFSG to that extent. Certainly looks like you think that there is some absolute way to determine that the license is not DFSG-compliant to me. If there isn't, then the if in the first part of your sentence is never satisfied, and the rest is completely hypothetical. In actual fact, I'm sure there *are* cases where the situation is so blindingly obvious that we all agree completely unanimously that it is obvious that a license is not DFSG-compliant. But in those cases, it's hard to imagine why there might be a resolution declaring that it were DFSG-compliant. So your example is still completely hypothetical and irrelevant. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Thu, Feb 09, 2006 at 06:37:57PM -0800, Thomas Bushnell BSG wrote: The vote is not a means of rescinding the DFSG or SC, nor even of contradicting them. It is the *only* means we have of determining whether something is in compliance with them. If a majority say that that is the case, then for our purposes, it is so. No. This is incorrect. The developers surely have the right to declare what the DFSG means; I have never challenged that. So what is incorrect? However, this does not specify by what majority they must act. The developers have the right to rescind the DFSG or close down the Project if they want, but this does not mean that a mere majority is sufficient to take those steps. Unless the developers wish to supercede the DFSG or the SC then a simple majority is required. Nothing in any of the resolutions to be passed claims to supercede the DFSG or SC in any way, ergo they don't. If one of the amended resolutions were to pass, by a simple majority, without claiming to supercede either the DFSG or the SC, then nothing within it could be taken as doing so. As with any other resolution, if a situation later arose in which the requirements of the resolution were seen to conflict with the requirements of the DFSG or SC, then the DFSG/SC would take precedence. This should be based on a matter of fact though, not of opinion. As should the majority required in this ballot. To be quite clear about this, I will personally almost certainly vote for AJ's unamended resolution. The first amended version, as I pointed out before, contains at least one error which renders it useless. Were it to pass in its current state, it would require another GR to correct/clarify its meaning. I believe that anyone who favours the intended meaning of this amendment should either make damn sure that it is corrected before the vote, or vote for further discussion to allow a corrected version to be put forward. I might be tempted to vote for this amended version were it not for that problem. However, the presence of this problem indicates to me that the amendment as a whole is unlikely to be as well thought out as such a resolution demands. The second amended version, to me, is stretching the bounds of credulity somewhat. It also appears to endorse Stallman's quote: The whole point of those works is that they tell you what somebody thinks or what somebody saw or what somebody believes. To modify them is to misrepresent the authors; so modifying these works is not a socially useful activity. And so verbatim copying is the only thing that people really need to be allowed to do. Which is, to me, obviously and blatantly factually incorrect in several different ways. So, I'm not trying to persuade anyone of the wrongness of Manoj's claim for a supermajority requirement because I think it will help me get my way -- I just happen to feel very strongly that it is an abuse (although I don't doubt a well-intentioned one) of the position which he holds. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Sat, Feb 11, 2006 at 06:19:28AM -0500, Glenn Maynard wrote: On Fri, Feb 10, 2006 at 03:21:57PM +1300, Nick Phillips wrote: The vote is not a means of rescinding the DFSG or SC, nor even of contradicting them. It is the *only* means we have of determining whether something is in compliance with them. If a majority say that that is the case, then for our purposes, it is so. This is silly. It seems like the constitution effectively says if the resolution passes it required a simple majority; if it failed, it needed 3:1. On the contrary, it makes perfect sense. If it makes part of the constitution look silly or pointless to you, then there are at least two other possible sources of that silliness. If you take these interpretive GRs as not requiring 3:1, then you can bypass the 3:1 requirement entirely merely by phrasing your changes as an interpretion, and you can phrase anything at all as an interpretion. I actually don't think that's the case. But let's assume that it is. The fact that you can get around the 3:1 requirement by wording your GR appropriately merely shows the 3:1 requirement (or its wording) to have been inadequately thought through -- it certainly doesn't magically extend it (a particularly bad idea if it seems like it might not have been adequately thought through in the first place). Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Thu, Feb 09, 2006 at 05:18:31PM -0800, Thomas Bushnell BSG wrote: Everyone has the job of interpreting the DFSG. I'm saying that if, in the opinion of the Secretary, an interpretation of the DFSG is tantamount to a reversal of part of it, then it requires a 3:1 majority to pass. If the license is not DFSG-compliant, then a resolution to declare that it is so, is either a dead letter, or else works a rescinding of the DFSG to that extent. Unfortunately things are not as clear-cut as you would like to claim. You are of course assuming that there is some way of making an absolute determination as to the DFSG-compliance of a license, when there is not. Initially, we expect this determination to be made by individual developers, as you have pointed out. Individuals' judgements may be called into question by ftpmasters, who may ask debian-legal for comments. If there is no consensus, then we have a vote. We have *no* higher authority to determine the DFSG-compliance of a license than such a vote. So your statement is meaningless. The vote is not a means of rescinding the DFSG or SC, nor even of contradicting them. It is the *only* means we have of determining whether something is in compliance with them. If a majority say that that is the case, then for our purposes, it is so. I'll refrain from arguing about what might happen in the event of a contradiction, as it's a pointless distraction at this juncture. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Thu, Jan 19, 2006 at 09:11:11PM -0500, Christopher Martin wrote: The important question here is one of legitimacy. Who exactly has the authority to determine these matters of interpretation? Specifically, who decides what is in accordance with the DFSG? The developers do, through GRs, if I understand correctly. Certainly nothing in my reading of the Constitution suggests that the Secretary has this power. The Secretary seems to be adopting the view that anyone who disagrees with his interpretation of the GFDL is not holding a legitimate opinion. Given the length of the GFDL debates, the acrimony, and the number of developers who remain on both sides, this seems far, far too strong a stance for a Project officer to adopt (even if Manoj holds that view personally). Hence my complaint. I agree completely. The GR as amended might appear to contradict the Social Contract, or the DFSG, but it certainly *does not* modify them, and hence cannot be said to require a supermajority. In fact, Adeodato's amendment is clear in its explanation that we believe that the GFDL does meet the spirit of the DFSG (so long as you have no invariant sections). If, therefore, that particular amended version of the GR were to pass, it would be clear that a majority of developers *did not* believe that it required or constituted a modification to either the Social Contract or the DFSG. Even if for some reason that I am unable to fathom you do fervently believe that I am wrong in the above paragraph, then there is *still nothing* to say that we can't happily pass GRs that contradict each other. It would be foolish, sure, and perhaps reflect poorly on our ability to work through these things, but democracies pass laws like that the whole time and the courts seem to manage to resolve the contradictions. Note that the alternative to this process is for someone (usually a General, it seems) to stand up and tell the parliament not to be so damn silly, and to follow his interpretation of the constitution, or else. This usually ends badly for all concerned. So, I'm strongly opposed to Manoj attempting to require a supermajority requirement when it is not clearly and unambiguously required. I believe that were the outcome of the vote to be a simple majority for the amendment, that the consequences for the project could be pretty dire. Now, the amendment (Adeodato's) itself. I've just noticed that it's a complete waste of space as presented at http://www.debian.org/vote/2006/vote_001 -- the second paragraph of point 2) of the first (un-headed) section reads as follows: Formally, the Debian Project will include in the main section of its distribution works licensed under the GNU Free Documentation License that include no Invariant Sections, no Cover Texts, no Acknowledgements, and no Dedications, unless permission to remove them is granted. Can you read that carefully and tell me (with a straight face) that it says what its author intended it to say? I don't think you can -- and that single error (if it is indeed presented as proposed) in what is a critical part of the document renders that entire amendment ridiculous. What it says, for those who can't (or can't be bothered) to read it is essentially this: We will include GFDL'd works that have no bad bits unless we have permission to remove them. Or rewritten slightly more clearly (by bad bits I obviously mean invariant sections, cover texts etc.): We will not include GFDL'd works that have no bad bits if we have permission to remove them. What is that them -- it can't be the bad bits because we're talking about works that don't have any. So it must be the works themselves. This implies that what this paragraph actually says is that we won't include any GFDL'd works that have no bad bits. Maybe we'll include ones that do?... Yuck. Voting for that would make us look even sillier than voting for something that really did contradict the Social Contract or DFSG. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Wed, Feb 08, 2006 at 08:47:36PM +0100, Wouter Verhelst wrote: On Wed, Feb 08, 2006 at 09:21:36PM +1300, Nick Phillips wrote: What it says, for those who can't (or can't be bothered) to read it is essentially this: We will include GFDL'd works that have no bad bits unless we have permission to remove them. Or rewritten slightly more clearly (by bad bits I obviously mean invariant sections, cover texts etc.): We will not include GFDL'd works that have no bad bits if we have permission to remove them. Sorry, but the above two sentences mean something *completely* different. Either you had a brain fart here, or your knowledge of the English language is... strange. Bah, brain fart indeed. Negated the wrong bit. Not entirely surprising given that the original didn't make sense anyway. Fixed, it translates to: We will include GFDL'd works that have no bad bits if we do not have permission to remove them. Them cannot apply to non-existent bad bits, so can only apply to the works. So, who has to give us permission to remove things? This does *not* make sense... Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Wed, Feb 08, 2006 at 11:50:51AM -0500, Raul Miller wrote: On 2/8/06, Nick Phillips [EMAIL PROTECTED] wrote: The GR as amended might appear to contradict the Social Contract, or the DFSG, but it certainly *does not* modify them, and hence cannot be said to require a supermajority. This comment seems insincere. Down that road lies tit-for-tat ad-hominem. If the GR is adopted by Debian, there is no significant difference between contradicts the foundation documents and modifies the foundation documents. First of all, you're assuming that it does contradict the foundation documents. It clearly asserts otherwise, and one might assume that developers voting for it would agree with that. If it won a majority, it would therefore seem to be the case that the majority of developers agreed with it. In which case those asserting that it needed supermajority wouldn't have a leg to stand on. So we'd be in a right mess. Second, you're completely wrong. Of course there is a difference between modifying the foundation documents and appearing to contradict them. One modifies them and the other, well, doesn't. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Fri, Jan 06, 2006 at 04:04:56AM -0800, Steve Langasek wrote: far :), I would encourage you to log into merkel and verify, directly and securely, the key at /org/ftp.debian.org/web/ziyi_key_2006.asc; sign it; and upload your signature to the public keyservers as well, if you are satisfied that this is the key that is being used on ftp-master.debian.org to sign the archive. You should *only* do this if you're satisfied that the presence of this file in the mirror on merkel is adequate evidence that it's the same key in use on ftp-master. So trusting that the ssh host key of merkel is authentic, trusting that someone hasn't compromised both merkel and your network (pushing matching, invalid keys to you via merkel and a MITM of http://ftp-master.debian.org), and trusting that the propagation from ftp-master to merkel is secure. Do we make a habit of asking ftpmasters to bring the archive keys along to keysignings? How many ftpmasters would we want to stand up and tell us that they key in question really is the one that is used to sign the archives before we should agree to sign it?... Just thinking that the keysigning at LCA in two weeks might be a good opportunity to get lots of developers to sign it... Shameless Plug: There's still time to register - see http://lca2006.linux.org.au :-) Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Thu, Jan 05, 2006 at 04:43:13PM -0800, Thomas Bushnell BSG wrote: If the key is compromised, which is the only way the non-expiring key method can be broken, then the expiring key doesn't seem to be offering all that much additional security. If the 2006 key takes (say) 15 months to compromise, then it is fine to use it to sign and verify the new key on 1/1/2007, so long as you perform that verification before March... IOW using the old key to sign the new key only requires that the old key be good at one point during the new year, whereas continuing to use the old key requires that it be good all year. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted teapop 0.3.7-4 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 9 Oct 2005 19:25:56 +1300 Source: teapop Binary: teapop-mysql teapop-pgsql teapop-ldap teapop Architecture: source i386 Version: 0.3.7-4 Distribution: unstable Urgency: low Maintainer: Nick Phillips [EMAIL PROTECTED] Changed-By: Nick Phillips [EMAIL PROTECTED] Description: teapop - Powerful and flexible RFC-compliant POP3 server teapop-ldap - Powerful and flexible RFC-compliant POP3 server teapop-mysql - Powerful and flexible RFC-compliant POP3 server teapop-pgsql - Powerful and flexible RFC-compliant POP3 server Changes: teapop (0.3.7-4) unstable; urgency=low . * Fix depends and rebuild to update debconf dependency to allow use of cdebconf-2.0. Closes #332112. * Build-dep on libmysqlclient14-dev. * Up debhelper comaptibility level from 1 to 4(!) (actually making packaging compatible too, I hope). Files: fbc8aaac37fdb4f472f2e3601b7b2e4e 661 mail extra teapop_0.3.7-4.dsc 01ad040f68e0d9b4931c8e62f5ad8ebb 141051 mail extra teapop_0.3.7-4.diff.gz 8801003132018ca3b1ae8b6da42195f5 67340 mail extra teapop_0.3.7-4_i386.deb 5270b5a8d97313370beebe1cb72517f1 69062 mail extra teapop-mysql_0.3.7-4_i386.deb 088865fbfe5cba7265164689564944b7 68618 mail extra teapop-pgsql_0.3.7-4_i386.deb bc06c6a41d406f3b9cee51b571ee127f 68648 mail extra teapop-ldap_0.3.7-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDSOt2dZJIm8yYOSgRAurKAJ4uN2fSY1aQDTPN9GE0EKNL2SpMNwCg2uRD oCwA8kzye9axgzt4p3FFkbs= =wCyw -END PGP SIGNATURE- Accepted: teapop-ldap_0.3.7-4_i386.deb to pool/main/t/teapop/teapop-ldap_0.3.7-4_i386.deb teapop-mysql_0.3.7-4_i386.deb to pool/main/t/teapop/teapop-mysql_0.3.7-4_i386.deb teapop-pgsql_0.3.7-4_i386.deb to pool/main/t/teapop/teapop-pgsql_0.3.7-4_i386.deb teapop_0.3.7-4.diff.gz to pool/main/t/teapop/teapop_0.3.7-4.diff.gz teapop_0.3.7-4.dsc to pool/main/t/teapop/teapop_0.3.7-4.dsc teapop_0.3.7-4_i386.deb to pool/main/t/teapop/teapop_0.3.7-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: allow new upstream into stable when it's the only way to fix security issues.
On Mon, Aug 01, 2005 at 06:06:27AM -0400, Yaroslav Halchenko wrote: On Sun, Jul 31, 2005 at 11:10:04PM +0400, Nikita V. Youshchenko wrote: (1) keep vulnerable packages in stable, (2) remove affected packages from distribution, (3) allow new upstream into stable. My 1 cent would be a merge of (2) and (3)... it is more of the formalization so we woudln't need to think about it on a next occasion with some other package (2) - remove from the stable distribution (3) - create /rolling-updates or whatever better name would be in a fashion like /security-updates. If there really are people who wouldn't want (3) on their systems (and enough of them that we should take notice of them), then I think something along the lines you have suggested is the only reasonable solution. It's not pretty, but it does give people the choice of what to be paranoid about. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libspoon-perl 0.20-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 19 Dec 2004 18:43:34 +1300 Source: libspoon-perl Binary: libspoon-perl Architecture: source all Version: 0.20-1 Distribution: unstable Urgency: low Maintainer: Nick Phillips [EMAIL PROTECTED] Changed-By: Nick Phillips [EMAIL PROTECTED] Description: libspoon-perl - A Spiffy Application Building Framework Changes: libspoon-perl (0.20-1) unstable; urgency=low . * New upstream release, minor changes only Files: 72ad01e8f68a6f1aa953495027c72e56 617 perl optional libspoon-perl_0.20-1.dsc 362f9dfee3dfea8af2912d676a42b227 21739 perl optional libspoon-perl_0.20.orig.tar.gz 50d0862bc5426cc7e62bbcb70ae58dc3 2226 perl optional libspoon-perl_0.20-1.diff.gz a5a766852ce774490dc1f85823fa5d2d 46472 perl optional libspoon-perl_0.20-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB4z5WdZJIm8yYOSgRAvOWAKDNkYB4xuyv1az+05A68QdFQSOt1gCfR175 hvG66NPPzot81lUL+LgZce0= =N+qg -END PGP SIGNATURE- Accepted: libspoon-perl_0.20-1.diff.gz to pool/main/libs/libspoon-perl/libspoon-perl_0.20-1.diff.gz libspoon-perl_0.20-1.dsc to pool/main/libs/libspoon-perl/libspoon-perl_0.20-1.dsc libspoon-perl_0.20-1_all.deb to pool/main/libs/libspoon-perl/libspoon-perl_0.20-1_all.deb libspoon-perl_0.20.orig.tar.gz to pool/main/libs/libspoon-perl/libspoon-perl_0.20.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libspoon-perl 0.19-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 17 Dec 2004 21:37:33 +1300 Source: libspoon-perl Binary: libspoon-perl Architecture: source all Version: 0.19-1 Distribution: unstable Urgency: low Maintainer: Nick Phillips [EMAIL PROTECTED] Changed-By: Nick Phillips [EMAIL PROTECTED] Description: libspoon-perl - A Spiffy Application Building Framework Changes: libspoon-perl (0.19-1) unstable; urgency=low . * Initial Release. * Only set libtemplate-perl dep to 2.10 despite alleged dep on 2.13; there is no known reason for 2.13 over 2.10 but it will be less tested elsewhere. Up the dep when 2.13 is in debian. Files: 4e59251dcc082d33397c1feed5d2aff6 617 perl optional libspoon-perl_0.19-1.dsc 2cd2d346eb36a1006b792a3ab76a40c4 21699 perl optional libspoon-perl_0.19.orig.tar.gz 3914130b5459739cff4eea6bddcfae34 2176 perl optional libspoon-perl_0.19-1.diff.gz 9f2cbcaa3ae027bebebdae739442e2e7 46330 perl optional libspoon-perl_0.19-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB4z4vdZJIm8yYOSgRArd7AKCLigA0QqOVZFFEfo2H3mboeSaPXgCeKFFz jiy/WrW+7PipTmnTr28SN6o= =+MUP -END PGP SIGNATURE- Accepted: libspoon-perl_0.19-1.diff.gz to pool/main/libs/libspoon-perl/libspoon-perl_0.19-1.diff.gz libspoon-perl_0.19-1.dsc to pool/main/libs/libspoon-perl/libspoon-perl_0.19-1.dsc libspoon-perl_0.19-1_all.deb to pool/main/libs/libspoon-perl/libspoon-perl_0.19-1_all.deb libspoon-perl_0.19.orig.tar.gz to pool/main/libs/libspoon-perl/libspoon-perl_0.19.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libspork-perl 0.18-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 18 Dec 2004 12:32:14 +1300 Source: libspork-perl Binary: libspork-perl Architecture: source all Version: 0.18-1 Distribution: unstable Urgency: low Maintainer: Nick Phillips [EMAIL PROTECTED] Changed-By: Nick Phillips [EMAIL PROTECTED] Description: libspork-perl - Slide Presentations (Only Really Kwiki) Changes: libspork-perl (0.18-1) unstable; urgency=low . * Initial Release. Files: cdd74da1327ae10657317dd0d7ece822 617 perl optional libspork-perl_0.18-1.dsc 11f856478ec198ed9748db23d6c05112 18902 perl optional libspork-perl_0.18.orig.tar.gz bb1a9fffbab1d69656452bad14e60d8d 2079 perl optional libspork-perl_0.18-1.diff.gz d7b58e03d9f308d827b6b0ceffb16df7 25066 perl optional libspork-perl_0.18-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB4z5hdZJIm8yYOSgRAqZ/AJ9QPRFGnO22dTjFyVWbAFblr6YVdACfYRh6 WTlMoOwPA6fP6B9EW+oXuQQ= =ieRi -END PGP SIGNATURE- Accepted: libspork-perl_0.18-1.diff.gz to pool/main/libs/libspork-perl/libspork-perl_0.18-1.diff.gz libspork-perl_0.18-1.dsc to pool/main/libs/libspork-perl/libspork-perl_0.18-1.dsc libspork-perl_0.18-1_all.deb to pool/main/libs/libspork-perl/libspork-perl_0.18-1_all.deb libspork-perl_0.18.orig.tar.gz to pool/main/libs/libspork-perl/libspork-perl_0.18.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libspiffy-perl 0.21-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 17 Dec 2004 20:38:09 +1300 Source: libspiffy-perl Binary: libspiffy-perl Architecture: source all Version: 0.21-1 Distribution: unstable Urgency: low Maintainer: Nick Phillips [EMAIL PROTECTED] Changed-By: Nick Phillips [EMAIL PROTECTED] Description: libspiffy-perl - Spiffy Perl Interface Framework For You Changes: libspiffy-perl (0.21-1) unstable; urgency=low . * Initial Release. Files: 655947b98dde837756b897dfb66bfc8c 621 perl optional libspiffy-perl_0.21-1.dsc 3279a0a0e5953dae2fd508c44d0f9737 24629 perl optional libspiffy-perl_0.21.orig.tar.gz 50e3aae8bba3a77aa9ce777440c214c1 2313 perl optional libspiffy-perl_0.21-1.diff.gz ddd364683ba0c804cea0174a4d44cdb5 31008 perl optional libspiffy-perl_0.21-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB4z4kdZJIm8yYOSgRAq5hAJ9owYrmafSem/ANaw8Z8mkepgViGACfQPOH oytrZG080cuDFZgxYvirvc4= =yIZt -END PGP SIGNATURE- Accepted: libspiffy-perl_0.21-1.diff.gz to pool/main/libs/libspiffy-perl/libspiffy-perl_0.21-1.diff.gz libspiffy-perl_0.21-1.dsc to pool/main/libs/libspiffy-perl/libspiffy-perl_0.21-1.dsc libspiffy-perl_0.21-1_all.deb to pool/main/libs/libspiffy-perl/libspiffy-perl_0.21-1_all.deb libspiffy-perl_0.21.orig.tar.gz to pool/main/libs/libspiffy-perl/libspiffy-perl_0.21.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#263743: Call For Help - Please support the ppc64 architecture
On Thu, Mar 17, 2005 at 01:26:17AM +0100, Matthias Urlichs wrote: No Debian tool depends on s/32/64/ or s/$/64/. As for me, I type ppc instead of powerpc very often, even though I should know better by now. Likewise. This would seem to be a case of once may be regarded as a misfortune, twice looks like carelessness. To deviate from the LSB *and* the apparently intuitive name purely to remain consistent with an unfortunate existing name (when even that consistency is fairly bogus) would seem a particularly foolish thing to do. Cheers, Nick -- 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:34:54AM -0800, Thomas Bushnell BSG wrote: Sorry, I'm speaking in term of possible future policies, not the present. Create i386.us.debian.org, powerpc.us.debian.org, amd64.us.debian.org, etc. Each of them points to the existing mirrors. Make the installer set up sources.list to specify those names. Mirrors can carry what they want, provided the DNS admin knows what they are carrying. It's about ten minutes work. Per country, perhaps. But yes, I think this is an excellent idea (that's why I suggested it on IRC yesterday ;-) ). It might also help those of us in countries that are sadly lacking in mirrors to get at least *some* architectures properly officially mirrored. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Mon, Mar 07, 2005 at 08:31:18AM +, Henning Makholm wrote: Scripsit Nick Phillips [EMAIL PROTECTED] I also think that it would be a very good thing if we were to use our collective discretion more often -- to say, for example, well, you could call this source, but it's bloody horribly ugly and painful source, and we don't want that kind of crap in Debian a bit more often. Yes, but we shouldn't act as if it was a _freedom_ problem. It's a _quality_ problem and should be treated as such, i.e. without invoking the DFSG. Sorry, yes. That's what I was trying to say. Or part of it, at least. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Sat, Mar 05, 2005 at 12:40:53AM +0100, Goswin von Brederlow wrote: Maybe I'm too unclear. They are guidelines. As such they don't define what source is or what forms of 'source' are acceptable but use the broadest term saying just 'source'. If something is still acceptable as source (like having source without #define's) or not (like having a plain gcc -S output) has to be decided case by case. Just saying obfuscating violates DFSG#2 doesn't cut it in my opinion. That is far to broad a generalization to be usefull at all. Say the upstream author has personal references to NDA protected materials (e.g. /* see page 17 of foobar */) in his source and has to remove them before release. Why would that make the source unacceptable? Having somewhat obfuscated source violates the spirit of free software and up to some level that can be tolerated. As long as the software comes under a free license (and follows it) and the maintainer is happy working with the source in the form it is in why should anyone object? The world isn't blackwhite but has shades of grey. Is that clearer? I think I agree with you pretty much completely; IMO it is actually impossible to define source in a way that is both cut-and-dried and useful. I also think that it would be a very good thing if we were to use our collective discretion more often -- to say, for example, well, you could call this source, but it's bloody horribly ugly and painful source, and we don't want that kind of crap in Debian a bit more often. There are many good reasons for doing this -- maintainability, the chances of hiding a trojan, the fact that we want to distribute something that we can be proud of, the fact that we want to distribute something that our users can modify to their needs... If someone wrote a windowing system (say, a rewrite of X) in Brainfuck and gave you the source, it would be way way worse than any obfuscated C source you're ever likely to see. In fact you'd probably have more chance of making useful changes to binaries built from C code than to Brainfuck source that big. So let's just accept that we can't have cut and dried rules about this, please. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: useless trivia, oldest opened bug in Debian
On Mon, Feb 21, 2005 at 11:40:07AM +, Scott James Remnant wrote: On Sat, 2005-02-19 at 23:06 -0600, Micah Anderson wrote: #957: dpkg 957 802533782 open [EMAIL PROTECTED] wishlist Do I get a medal when I fix this in the next week or two? :) I've been working on an implementation over the weekend that's to my liking. If you do that *and* manage to keep to what you have already said about it (the bit about providing a fix post-sarge), you *definitely* get a medal :-) Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, Feb 21, 2005 at 07:10:36AM -0600, Peter Samuelson wrote: The main problem with distcc across architectures is the FUD surrounding whether gcc-as-cross-compiler spits out the same code as gcc-as-native-compiler. The gcc team seem to be very hesitant to make any guarantees about that, as it's not something they test much. Without better information than guesswork, I'd say you might minimise your chances of cross-gcc bugs by using a host with the same endianness and bit width. Running such a system in parallel with the current systems (and comparing the outputs) might be a good test for gcc-as-cross-compiler, then... Just a thought. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#294084: ITP: life -- Linux Instrumentation for Enterprise - a set of WBEM management providers from Novell
On Mon, Feb 07, 2005 at 08:52:52PM +0100, Rafal Lewczuk wrote: Package: wnpp Severity: wishlist * Package name: life When I hear life in the context of computers, I automatically think of Conway's version... and so I'm sure do many many other people. Bad choice of name by upstream I think. Not sure that there's anything useful you can do about it though. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted teapop 0.3.7-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 22 Jan 2005 17:28:47 +1300 Source: teapop Binary: teapop-mysql teapop-pgsql teapop-ldap teapop Architecture: source i386 Version: 0.3.7-3 Distribution: unstable Urgency: low Maintainer: Nick Phillips [EMAIL PROTECTED] Changed-By: Nick Phillips [EMAIL PROTECTED] Description: teapop - Powerful and flexible RFC-compliant POP3 server teapop-ldap - Powerful and flexible RFC-compliant POP3 server teapop-mysql - Powerful and flexible RFC-compliant POP3 server teapop-pgsql - Powerful and flexible RFC-compliant POP3 server Closes: 266788 267193 267574 288196 289284 Changes: teapop (0.3.7-3) unstable; urgency=low . * Apply debconf translation updates. Closes: #266788, #267193, #267574, #288196, #289284 Files: 135499fe53c38d081ee854c271b1ffef 659 mail extra teapop_0.3.7-3.dsc 31f84eb6bfd2e3965f106da7c7b542c5 140641 mail extra teapop_0.3.7-3.diff.gz a96d19dcd2ada9c1aea27b3fcdb57a21 67264 mail extra teapop_0.3.7-3_i386.deb 062d4e575b0cbbacde05a952c7f66c89 69002 mail extra teapop-mysql_0.3.7-3_i386.deb b5c80692f25de5e2a558798cbda127c3 68548 mail extra teapop-pgsql_0.3.7-3_i386.deb edc837f8633f43ba746b5ea3dba15d1b 68590 mail extra teapop-ldap_0.3.7-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB8df5dZJIm8yYOSgRAlo2AKDKVg9T7GwmfQu2KJ3UZWAPm8G9nwCfYac2 23QyKnxM1qgBmknRJrU97CI= =INh1 -END PGP SIGNATURE- Accepted: teapop-ldap_0.3.7-3_i386.deb to pool/main/t/teapop/teapop-ldap_0.3.7-3_i386.deb teapop-mysql_0.3.7-3_i386.deb to pool/main/t/teapop/teapop-mysql_0.3.7-3_i386.deb teapop-pgsql_0.3.7-3_i386.deb to pool/main/t/teapop/teapop-pgsql_0.3.7-3_i386.deb teapop_0.3.7-3.diff.gz to pool/main/t/teapop/teapop_0.3.7-3.diff.gz teapop_0.3.7-3.dsc to pool/main/t/teapop/teapop_0.3.7-3.dsc teapop_0.3.7-3_i386.deb to pool/main/t/teapop/teapop_0.3.7-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kwiki 0.36-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Dec 2004 10:30:11 +1300 Source: kwiki Binary: kwiki Architecture: source all Version: 0.36-1 Distribution: unstable Urgency: low Maintainer: Nick Phillips [EMAIL PROTECTED] Changed-By: Nick Phillips [EMAIL PROTECTED] Description: kwiki - A Quickie Wiki that's not too Tricky Changes: kwiki (0.36-1) unstable; urgency=low . * Compatibility package to enable gentler transition between old-style kwiki and new-style kwiki, also ensuring that new users don't accidentally get into old-style kwiki. Files: eeaf25e18f36597052157dbbd3d66704 565 web optional kwiki_0.36-1.dsc bfdaf7d12fa1b67219c2b5b421f4f338 75726 web optional kwiki_0.36.orig.tar.gz d0a15ea3a0813abd210381aeb351f300 2531 web optional kwiki_0.36-1.diff.gz e92f2006c607ac9d081153c935f6d4d9 117998 web optional kwiki_0.36-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB4zyVdZJIm8yYOSgRAg/LAJ9vsOlXJBXIwIlK+CyPnIcARFO1CQCeL7vT iRzs3N5Vq6wpVtImRH6dws4= =2cBJ -END PGP SIGNATURE- Accepted: kwiki_0.36-1.diff.gz to pool/main/k/kwiki/kwiki_0.36-1.diff.gz kwiki_0.36-1.dsc to pool/main/k/kwiki/kwiki_0.36-1.dsc kwiki_0.36-1_all.deb to pool/main/k/kwiki/kwiki_0.36-1_all.deb kwiki_0.36.orig.tar.gz to pool/main/k/kwiki/kwiki_0.36.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Manpages licensed under GFDL without the license text included
On Sun, Jan 09, 2005 at 04:53:25PM +0100, Florian Weimer wrote: I think it's enough to add an additional notice stating that the named section is reproduced in the gfdl(7) manpage, incorporated by reference. I doubt that this would satisfy clause 4.H. of the GFDL: H. Include an unaltered copy of this License. Note that it says /Include/, not /Accompany with/... Nothing in the license says that the Document must be a single file (or a single piece of paper). Bear in mind that there is nothing that then allows us to distribute the package in question except as a part of a system that includes the other data that is referred to. The fact that we have conveniently ignored this problem when dealing with the GPL and BSD licenses so far does not make it go away. The license information should be included in every individual package. We should come up with an alternative mechanism to save space, if that is what we want to do (e.g. allow packages to install the same file so long as the md5sums of the different versions match). Cheers, Nick
Accepted teapop 0.3.7-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 17 Aug 2004 19:11:04 +1200 Source: teapop Binary: teapop-mysql teapop-pgsql teapop-ldap teapop Architecture: source i386 Version: 0.3.7-2 Distribution: unstable Urgency: medium Maintainer: Nick Phillips [EMAIL PROTECTED] Changed-By: Nick Phillips [EMAIL PROTECTED] Description: teapop - Powerful and flexible RFC-compliant POP3 server teapop-ldap - Powerful and flexible RFC-compliant POP3 server teapop-mysql - Powerful and flexible RFC-compliant POP3 server teapop-pgsql - Powerful and flexible RFC-compliant POP3 server Changes: teapop (0.3.7-2) unstable; urgency=medium . * Add missing build-dep on libldap2-dev * medium urgency set (should have set on previous upload, as important bug #218191 causing minor corruption really should be fixed before sarge) Files: f12131d1906196bebb7c30ee1f914524 659 mail extra teapop_0.3.7-2.dsc dfec0c4045a9c28a80a410a46111088c 132597 mail extra teapop_0.3.7-2.diff.gz 27c70c243629adec786813ee5e46bcbd 63704 mail extra teapop_0.3.7-2_i386.deb 2e383fb27734adef6bd9cad47459cfc3 65530 mail extra teapop-mysql_0.3.7-2_i386.deb c8966d5b86f742469a55c9c4b07f5a68 65070 mail extra teapop-pgsql_0.3.7-2_i386.deb dd64501d80daf35e568ec4b5d79b603c 65096 mail extra teapop-ldap_0.3.7-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBIbGfdZJIm8yYOSgRAhpGAKCajehohrSjPhAe0US7RyeoiIeuvACgytNk eZBvYPevsNHh4yn5ffnzIjM= =u4q8 -END PGP SIGNATURE- Accepted: teapop-ldap_0.3.7-2_i386.deb to pool/main/t/teapop/teapop-ldap_0.3.7-2_i386.deb teapop-mysql_0.3.7-2_i386.deb to pool/main/t/teapop/teapop-mysql_0.3.7-2_i386.deb teapop-pgsql_0.3.7-2_i386.deb to pool/main/t/teapop/teapop-pgsql_0.3.7-2_i386.deb teapop_0.3.7-2.diff.gz to pool/main/t/teapop/teapop_0.3.7-2.diff.gz teapop_0.3.7-2.dsc to pool/main/t/teapop/teapop_0.3.7-2.dsc teapop_0.3.7-2_i386.deb to pool/main/t/teapop/teapop_0.3.7-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted teapop 0.3.7-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 26 Jul 2004 23:26:44 +1100 Source: teapop Binary: teapop-mysql teapop-pgsql teapop-ldap teapop Architecture: source i386 Version: 0.3.7-1 Distribution: unstable Urgency: low Maintainer: Nick Phillips [EMAIL PROTECTED] Changed-By: Nick Phillips [EMAIL PROTECTED] Description: teapop - Powerful and flexible RFC-compliant POP3 server teapop-ldap - Powerful and flexible RFC-compliant POP3 server teapop-mysql - Powerful and flexible RFC-compliant POP3 server teapop-pgsql - Powerful and flexible RFC-compliant POP3 server Closes: 142768 173485 192750 201805 218191 76 Changes: teapop (0.3.7-1) unstable; urgency=low . * New (well, not by now) upstream version. 0.3.6 was short-lived and slightly dodgy. No problems with dot at start of mbox line in this version. Notable new things include tcpwrapper support, message expiry, hashing of mailspools for other auth types, md5 password support. Oh, and APOP fixed. Closes: #218191, #173485, * Now building version with LDAP support. Closes: #142768 * Integrated changes from NMUs below. Thanks, Christian. Closes: #192750, #201805 * Added japanese debconf translation. Closes: #76 * Butcher .orig.tar.gz to remove RSA MD5 stuff completely; note that this is the only change made to the original, which means that the .orig.tar.gz will not build or function without applying the debian diff. * Fix po-debconfisation to deal with all appropriate templates files. Files: 43e8ba250682998df7f085e49608de93 645 mail extra teapop_0.3.7-1.dsc 8ce11968d6a14f41bbb558cb046100a8 140958 mail extra teapop_0.3.7.orig.tar.gz 01829fd94cac410f4c076f67ebb90169 132482 mail extra teapop_0.3.7-1.diff.gz 4f14b14ab0eafccb68e296dd1fce1192 63592 mail extra teapop_0.3.7-1_i386.deb 401870f8ee2e5ff0ce054dd5fbe26cc1 65420 mail extra teapop-mysql_0.3.7-1_i386.deb 519a1eb66682b86b392aace404b34a58 64950 mail extra teapop-pgsql_0.3.7-1_i386.deb 57658f0bed8d6dd9cc8fd2ebdf044b52 64978 mail extra teapop-ldap_0.3.7-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBBOxcdZJIm8yYOSgRAlIWAJ9M5Tn9aTNGhpZI32bzXpM0+wn/LACfVopy 7EiRMySmnEmLgrACVPhY4sQ= =k5uG -END PGP SIGNATURE- Accepted: teapop-ldap_0.3.7-1_i386.deb to pool/main/t/teapop/teapop-ldap_0.3.7-1_i386.deb teapop-mysql_0.3.7-1_i386.deb to pool/main/t/teapop/teapop-mysql_0.3.7-1_i386.deb teapop-pgsql_0.3.7-1_i386.deb to pool/main/t/teapop/teapop-pgsql_0.3.7-1_i386.deb teapop_0.3.7-1.diff.gz to pool/main/t/teapop/teapop_0.3.7-1.diff.gz teapop_0.3.7-1.dsc to pool/main/t/teapop/teapop_0.3.7-1.dsc teapop_0.3.7-1_i386.deb to pool/main/t/teapop/teapop_0.3.7-1_i386.deb teapop_0.3.7.orig.tar.gz to pool/main/t/teapop/teapop_0.3.7.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: recent spam to this list
On Mon, Oct 13, 2003 at 05:54:41PM -0500, John Hasler wrote: No, you understood it correctly. That's exactly the point. If I can configure my domain with a list of IPs from which mail claiming to originate from it must come without having a static IP and without the cooperation of the administrators of those IPs I have exactly what I want. Sounds like you got lucky ;-) Cheers, Nick
Re: May packages rm -rf subdirectories of /etc/ ?
On Thu, Jul 24, 2003 at 02:07:35PM +0200, Thomas Hood wrote: On Thu, 2003-07-24 at 13:46, Stephen Frost wrote: I see this as totally bogus. Either the conffile is shared or it isn't. If it's shared then the packages involved know this Package foo which eliminates /etc/foo.conf doesn't know that there is not some other package, bar, which Depends on foo and uses /etc/foo.conf . That's the problem. See #108587 for additional discussion. That's a red herring. It doesn't know that there isn't some other package that uses one of its binaries either. What should it do when one of them becomes obsolete -- leave it hanging around just in case? If package B depends on something that is no longer present in package A, package B is buggy, and needs to be updated (even if only with a versioned depends on an older A). Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Beware of a tall blond man with one black shoe.
Re: Why back-porting patches to stable instead of releasing a new package.
On Wed, Jul 23, 2003 at 01:31:52PM +0200, Fabio Massimo Di Nitto wrote: Because you can never be sure that it will not change the package behaviour in all its small details and that will not introduce new bugs. I believe that when a package is so badly outdated or broken that the version in stable should not or can not be used, it should at least be considered for update, new bugs or no. *shrug* -- Nick Phillips -- [EMAIL PROTECTED] Tomorrow, you can be anywhere.
Re: Accepted atftp 0.6.2 (i386 source)
On Mon, Jul 07, 2003 at 01:23:57PM -0500, Steve Langasek wrote: On Mon, Jul 07, 2003 at 12:48:49PM -0500, Branden Robinson wrote: On Sun, Jul 06, 2003 at 01:47:07PM -0400, Remi Lefebvre wrote: Changes: atftp (0.6.2) unstable; urgency=low . * Fixed local and remote buffer overflow (Closes: #196304) In the future, please upload security fixes with urgency=high. I'm assuming this is only appropriate if the vulnerability affects testing? Since the main impact of setting the 'urgency' field is affecting propagation time into testing, it doesn't seem appropriate to give higher priority to a package which only suffered from a vulnerability in the unstable version. I was under the impression that the urgency field was supposed to be an indicator of how important the upgrade is likely to be to users of the package, and that the testing propagation was just a handy side-use. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Write yourself a threatening letter and pen a defiant reply.
Re: NEWS.Debian support is here
On Tue, Jul 08, 2003 at 10:46:47AM +0200, Josselin Mouette wrote: Le mar 08/07/2003 ? 01:15, Matt Zimmerman a ?crit : All that's missing is an automatic debconf notice entry for each NEWS item. That wud be well c00l. As I recall, part of the idea of NEWS.Debian was to prevent having this kind of information end up as debconf notes. But some people like to have this information in debconf notes. Having the choice between displaying them and reading them in NEWS.Debian would be neat. He was JOKING... wasn't he? -- Nick Phillips -- [EMAIL PROTECTED] Tonight you will pay the wages of sin; Don't forget to leave a tip.
Re: Resolvconf -- a package to manage /etc/resolv.conf
On Sun, Jul 06, 2003 at 01:00:20AM +0200, Goswin Brederlow wrote: The simplest form would be: resolv.conf-register /etc/init.d/squid reload Actually I think the simplest form would be to have /etc/resolvconf/notify.d and run all scripts in there at the relevant times, with any necessary arguments (which would be standard). Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] You can rent this space for only $5 a week.
Re: Please remove RFCs from the documentation in Debian packages
On Fri, Jul 04, 2003 at 01:46:11AM +0800, Cameron Patrick wrote: Of course not. They're software. RFCs aren't software, and so applying the Debian Free /Software/ Guidelines to them seems a little odd. Hmmm... Depends on your definition, really. They're sure as hell not hardware or firmware, so... -- Nick Phillips -- [EMAIL PROTECTED] You are sick, twisted and perverted. I like that in a person.
Re: Bug#197907: ITP: quark -- an audio player, for geeks, by geeks.
On Thu, Jun 19, 2003 at 09:39:30AM -0500, Steve Langasek wrote: Well, except that it doesn't actually describe the package well. Maybe insert FIFO controlled before audio player. Or better, FIFO-controlled, so it doesn't read like a past-tense sentence fragment about FIFO having controlled an audio player. I have almost a ready package, i just now need a fine short description. The upstream author is not so happy about the FIFO controlled stuff, since it sounds as if using quark is difficult. The main advantages of quark are : It's by geeks for geeks, but FIFOs scare the target audience? :-) FWIW, I think the original short description was fine; it conveys the attitude that has likely been taken while developing it, which in turn gives you rather a lot of information about what the end product is likely to be like. Far better than any of the alternatives suggested so far, at any rate :-P Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] It may or may not be worthwhile, but it still has to be done.
Re: fcntl(HANDLE, F_GETLK,fl) with perl
On Wed, Jun 18, 2003 at 03:19:50PM -0700, Philippe Troin wrote:
Bill Allombert [EMAIL PROTECTED] writes:
but it does not seems to work. In fact the documentation
is unclear whether a struct flock can be passed at all
(some form of fcntl use a long arg instead).
You have to pack the structure by hand. This works for me:
use Config;
my $packspec = $Config{uselargefiles} ? ssqql : sslll;
If you're worried about portability, it's a bitch. I got so pissed off
with it a while ago that I wrote a module to do it at least vaguely
portably. However, once I got to the stage where it did what I needed,
I didn't have time to get it into shape to release anywhere (like CPAN).
If this sounds like what you might want, let me know I'll dig it out
again.
Cheers,
Nick
--
Nick Phillips -- [EMAIL PROTECTED]
Never commit yourself! Let someone else have you committed.
Re: Bug#190302: Misusage of changelog!
On Tue, May 27, 2003 at 12:46:02AM -0400, Matt Zimmerman wrote: * Matt Zimmerman [EMAIL PROTECTED] [030526 21:41]: It is _not_ obvious, and closes: #... gives no clue to someone reading the changelog what might have been changed. Internet access, knowledge of debbugs, etc. are not prerequisites for being able to make use of a changelog. Then why do you limit your critic to the bug closed. Which bugs are closed are often the least interisting item of a new version. Bug fixes are one of the most interesting things in a changelog. This is not the daily news, it is a record of what changed, and _when_. It should be possible, for example, for me to read the changelog from a version of a package in unstable and from that to be able to judge whether it's worthwhile installing that version of the package on my stable system. This means I need to know what bugs have been fixed and when, and what scary new features have been added, and when. There's no way I'm going to be able to keep track of it by looking up every bug that's been fixed in that time in the BTS. Alternatively, I might want to work out why a package might depend on a specific version of your package -- for example when trying to backport the other package to stable. If you have a decent changelog I can quickly and easily judge whether the fixes that were introduced in the version mentioned in the dependency are necessary to me or not. If your changelog merely says New upstream version, closes: #123 #456, it's no help whatsoever, and I will (rightly) think that you suck. FFS, it's a *change*log -- so log the effing changes in it. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Do not overtax your powers.
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
On Tue, May 20, 2003 at 07:27:21PM -0400, Raul Miller wrote: Here, the vote(s) for B caused A to win. Other examples are possible (for example: 19 ABD, 1 BDA). To make your proposal work right, we'd need a separate quorum determination phase which is independent of the voting phase. i fail to see that argument. See above. I don't believe that it's acceptable for an otherwise beaten option to win due the the otherwise winning option being discarded due to a quorum requirement, as John suggests might happen. I also don't believe that it's acceptable to break the Monotonicity Criterion. If a winning option would be discarded due to quorum requirements, then I think the vote should probably be considered void. Sorry I don't have time to make much more of a contribution than this. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] You're being followed. Cut out the hanky-panky for a few days.
Re: security in testing
On Wed, May 14, 2003 at 01:27:12PM -0400, Matt Zimmerman wrote: On Wed, May 14, 2003 at 10:03:32AM -0500, Steve Langasek wrote: Figuring that a security upload would be preferable, I approached the security team and offered to prepare an upload. I was effectively told that this isn't done, and because it isn't done, most testing users don't have security.d.o in their sources.list, so don't bother. This is an excellent point. Really? I think it's a pisspoor point. I think that maintainers who care enough to do the necessary work should be encouraged to do it. The argument above is circular, chicken-and-egg style. If people like Steve, who maintain important packages like Samba, bother to create the necessary packages, then: a) It's a good start -- once people see these things starting to appear, more maintainers will bother, and users will start to put the relevant lines in their sources.list; b) They damn well should be made available. Testing users do not have such an entry in sources.list, so any other repository would be on equal footing. However, so far no one has taken any action to coordinate this, nor has anyone prepared updates for testing that would occupy such a repository. If this other repository had access to autobuilding facilities, then yes, it might be on an equal footing. I believe that the work was put in to enable automated security builds for woody (as aj keeps telling us). Why not use it? If it's a case of manpower, what's needed? As others have argued, I don't believe it's necessary that testing's security effort be as good as stable's. If it's not, it's important to make sure that users are aware of the level of security they're getting (so perhaps a different name for the repository would be advisable?). In any case, I think that security updates when anyone can be bothered (which would be likely to be whenever the maintainer cared lots, or when the issue and the package were important enough to motivate another developer to contribute) would be an improvement on the status quo. This is a related, more general issue, of how to minimize the blockage introduced by package dependencies. I think this problem is much more worthwhile to address than security updates targeted at 'testing'. There is no denying that that would be a useful issue to overcome, but I'm not sure I agree that it's more important than (at least some potential) security updates to testing, let alone much more. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Avoid reality at all costs.
Re: i386 compatibility libstdc++
On Sat, Apr 26, 2003 at 05:06:56AM +0200, Arnd Bergmann wrote: The options we currently have are: 1. drop i386 support completely: simple but painful 2. create a crippled distro for really old systems (e.g. i386 and i486) 3. keep everything the i386 way: slow and incompatible 4. like 3, but provide alternatives for new systems (i686+): needs a lot of work and ftp space. No, 4 is not an option -- it would leave too many people in the unnecessarily binary-incompatible bracket. If you want to do a split at 686+ then you need *two* splits, one there and one at, say, 486+. I don't believe it's reasonable to leave people with Pentium-class machines with systems that are not binary-compatible with other distributions, and without the ability to use certain 3rd-party software (in fact I think it's debatable whether or not we could reasonably leave 486 users out in the cold in that way). It may be relatively cheap and easy for *you* to buy a two-year-old system, but I don't believe that in this case you are representative of nearly enough of our users to be a useful example. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Today is the first day of the rest of your life.
Re: i386 compatibility libstdc++
On Sat, Apr 26, 2003 at 09:41:14AM +0200, Andreas Metzler wrote: I'd vote for 1 or 1a. create a stripped down version for i386, i.e. required/important and go for i486. I'll drink to that! -- Nick Phillips -- [EMAIL PROTECTED] You are confused; but this is your normal state.
Re: i386 compatibility libstdc++
On Sat, Apr 26, 2003 at 02:56:13AM -0500, Chris Cheney wrote: I also find it hard to believe that the majority of our users do not have or can not purchase a system that is less than 7 years old. That's really not so relevant, even if correct. If they already have a shitload of Pentiums which will do the job, why force them to buy anything newer? Being that is how old the i686 sub-arch is... I once attempted to install Debian 2.1 on a Pentium 90, it took many hours and was a pita to say the least. Heh. I once (no, twice) installed on a 486-50 with 4MB of RAM... :-P I can't remember whether that was slink, or whether I got hold of slink after being suitably impressed with the results (had to leave dselect running^Wthrashing for round about 36 hours, I think, for the initial install ;) ). That's actually what got me started moving from slackware to Debian... Anyway, back to the point. Machines old enough to be before i686 are probably also old enough to be barely usable as a desktop, I think you'll find they'll do just fine in all sorts of roles. Perhaps not as a whizzy desktop running the latest greatest KDE or Gnome (resisting the temptation, see ;) ), but certainly running X (although I must admit XFree = 4 is a real memory hog compared to previous versions). What are the theoretical binary-only apps that these desktops would be using, whizbang 3d games, multimedia players, or something else? Whizbang 3d games and multimedia players are not the only things that people write in C++. A reduced size 386-586 arch wouldn't be bad for a server, which imho is about all machines that old are really good for anyway. (And no Manoj I am not attempting to troll with this post...) See, I think this is where you're just fundamentally mistaken. In Dec 1994 I got my P90 with the biggest available ide hard drive which was 500MB. :-P No it wasn't. You must have been shopping in the wrong places. I got my 486DX66 with a 504MB drive in mid '93 and had the option of a bigger one (~1G I think, but can't remember exactly)... Compare that size to what sid currently requires for various installs: sid chroot install - 160MB sid standard install - 249MB Perfectly fine. I think I'll have to finish the install on this P200MMX I have sitting under my desk here just to see how big it does end up. The point being Debian sid with only one of the standard desktops (with no extra packages and no swap space) is already bigger than most machines from 1995 and older can support unmodified anyway... Whilst I don't see that the standard desktops are at all essential to a productive setup, I will agree that it is a shame how large the standard installs are getting. I think there will come a point where it is more useful to have a separate distribution or meta-distribution for older systems (with a sensible-sized libc, for example) than to stick with a one size fits all approach. I just don't think that with the quantity of Pentium-class machines out there that we've got to that point just yet. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Give him an evasive answer.
Re: i386 compatibility libstdc++
On Fri, Apr 25, 2003 at 01:37:04PM +0200, Emile van Bergen wrote: I say this because the original pentium didn't introduce a lot of new features other than the two pipelines for which you only need some insn scheduling that's fully compatible with the 486, and IIRC wasn't sold nearly as well as the various flavours of the 486. In other words, if you use 486-compatible instructions and pentium scheduling, you're already taking almost full advantage of the pentium. It makes therefore little sense to group the original pentium with the later architectures. The problem with this is the binary compatibility with other distributions, and the availability (or more likely, not) of third party binary-only software built against 386 versions of libs. Breaking at 686+ would mean that people with reasonably capable Pentium/MMX machines (say a P200MMX) would likely be unable to use such software. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] You feel a whole lot more like you do now than you did when you used to.
Re: i386 compatibility libstdc++
On Sat, Apr 26, 2003 at 09:20:33AM +1000, Matthew Palmer wrote: Another question, of course, is what does supporting 386s lose us? I've Binary compatibility with other distributions usability of 3rd-party C++ binaries. That was what started this thread, remember? -- Nick Phillips -- [EMAIL PROTECTED] Abandon the search for Truth; settle for a good fantasy.
Re: Work-needing packages report for Apr 11, 2003
On Sat, Apr 12, 2003 at 04:28:40PM +0100, Darren Salt wrote: [snip] For instance, what are some good replacements for magicfilter? apsfilter seems to work well. Not For Me. Every time I've tried it it's been utter crap. Magicfilter, OTOH, Just Works. Just in case anyone out there was hovering on the verge of adopting magicfilter... you know you want to ;) Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Do not sleep in a eucalyptus tree tonight.
Re: 2000 packages still waiting to enter testing, 1500 over age
On Wed, Apr 09, 2003 at 03:10:46PM +0200, Petter Reinholdtsen wrote: [Michael Banck] I object. Not entering testing could very well happen if the package's dependencies are broken/buggy/uninstallable. Yes, there are many reasons for a package to get stuck in unstable. But I believe it is the maintainers responsibility to make sure his packages do enter testing, and if he fail to do so for _300_ days, the package is not well maintained and can probably be removed. BS. There are plenty of packages which *should never* get into testing (as they will never, by our definition, be stable). That, of course, raises another question... Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] It's all in the mind, ya know.
Accepted tnef 1.1.4-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 22 Feb 2003 16:41:28 +1300 Source: tnef Binary: tnef Architecture: source i386 Version: 1.1.4-1 Distribution: unstable Urgency: low Maintainer: Nick Phillips [EMAIL PROTECTED] Changed-By: Nick Phillips [EMAIL PROTECTED] Description: tnef - Tool to unpack MIME application/ms-tnef attachments Closes: 176046 Changes: tnef (1.1.4-1) unstable; urgency=low . * New upstream version should allegedly fix segfault; changes are fairly minor (with the usual massive amount of changes in auto-*-generated files). It has fixed the segfault in the example file I have, so... closes: #176046 * Remembered to change Maintainer: field in control file this time :-/ Files: b3fae5dd36dadc39ea1878cbe55081de 553 text optional tnef_1.1.4-1.dsc 6e1616bb7838fafb7d8a300843038def 178149 text optional tnef_1.1.4.orig.tar.gz 1eed161c1ffa8d4005b8133cb68067fd 4707 text optional tnef_1.1.4-1.diff.gz 0633f3abef89bec12365c7464b2f8397 100754 text optional tnef_1.1.4-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+Vv1zdZJIm8yYOSgRAoR7AKCbuk/ArcpKEGtQWPPkYZXyVYdNjwCeOyAX e03TU004eunmTqAHA2cWvjs= =Oy+x -END PGP SIGNATURE- Accepted: tnef_1.1.4-1.diff.gz to pool/main/t/tnef/tnef_1.1.4-1.diff.gz tnef_1.1.4-1.dsc to pool/main/t/tnef/tnef_1.1.4-1.dsc tnef_1.1.4-1_i386.deb to pool/main/t/tnef/tnef_1.1.4-1_i386.deb tnef_1.1.4.orig.tar.gz to pool/main/t/tnef/tnef_1.1.4.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted teapop 0.3.5-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 18 Dec 2002 20:00:37 +1300
Source: teapop
Binary: teapop teapop-pgsql teapop-mysql
Architecture: source i386
Version: 0.3.5-1
Distribution: unstable
Urgency: high
Maintainer: Nick Phillips [EMAIL PROTECTED]
Changed-By: Nick Phillips [EMAIL PROTECTED]
Description:
teapop - Powerful and flexible RFC-compliant POP3 server
teapop-mysql - Powerful and flexible RFC-compliant POP3 server
teapop-pgsql - Powerful and flexible RFC-compliant POP3 server
Closes: 148995 172312 172756
Changes:
teapop (0.3.5-1) unstable; urgency=high
.
* Add section to debian/rules to deal with DEB_{HOST,BUILD}_GNU_TYPE
as per autotools-dev 20020320.1 docs.
* Rename configure.in to configure.ac to get it processed by autoconf
2.5x (less likely to lead to errors than trying to remember to
insert AC_PREREQ each time upstream configure.in changes).
* correct building of SELECT string in pop_mysql.c to build query
correctly when pmailrow is not specified, and tidy up equivalent part
of pop_pgsql too (change now incorporated upstream) - Closes: #148995
* IMPORTANT: New upstream version improves signal handling during POP
DELE operations; this may fix some data loss issues - Closes: #172756
* Removed CVS cruft - Closes: #172312
* Incorporated fix to handling of null bytes in mboxes from development
version, and carried it over to maildir handling.
IMPORTANT: Whilst this fixes a potential data loss issue with mboxes,
the issue with maildirs was never as serious, and the updated maildir
code is currently (2002/12/17) barely tested (although the change is
minor).
There is also still a potential issue, although I don't believe it is
serious, if the last line of an mbox or maildir mail file is an
exact multiple of 1023 chars long... although it appears that with
both mboxes and maildirs, last lines are _supposed_ to be empty.
Upstream is disinclined to fix this issue due to the overhead
imposed in the normal case.
* Replaced non-free RSA MD5 implementation with Colin Plumb's Public
Domain version. For some reason I was under the impression that we
were building with a system MD5 library rather than the non-free code
in the upstream teapop package. Apologies.
* Don't install cronpopauth.pl or create ${localstatedir} as we're not
building a binary with which they will be useful anyway (look for
cronpopauth in Makefile.in files to see how to revert this).
A better solution here would be nice.
* Apologies also to Clint; _still_ no LDAP version. Coming soon,
promise...
Files:
da10ebef9e0d2ac818859bdb43d435fe 631 mail extra teapop_0.3.5-1.dsc
65fdea12d76c1ed45d65689f48f7f994 139858 mail extra teapop_0.3.5.orig.tar.gz
8be2e0dd7f70ee5d0057975093edda4c 113332 mail extra teapop_0.3.5-1.diff.gz
18ae0d04228914929b0e8c9a4f6a2f78 56382 mail extra teapop_0.3.5-1_i386.deb
db8ccfc9c382aa3af5f5a875f5b0a5f0 58108 mail extra teapop-mysql_0.3.5-1_i386.deb
b38554a5ad2a8162d78789b13616f4c8 57704 mail extra teapop-pgsql_0.3.5-1_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE+AGWHdZJIm8yYOSgRAkgSAJ9inaHkmfsXMRZ2il6yc/EENAVBfQCg3TBS
Lpyok5Kj5K/2ddjzq3yffXA=
=J6pG
-END PGP SIGNATURE-
Accepted:
teapop-mysql_0.3.5-1_i386.deb
to pool/main/t/teapop/teapop-mysql_0.3.5-1_i386.deb
teapop-pgsql_0.3.5-1_i386.deb
to pool/main/t/teapop/teapop-pgsql_0.3.5-1_i386.deb
teapop_0.3.5-1.diff.gz
to pool/main/t/teapop/teapop_0.3.5-1.diff.gz
teapop_0.3.5-1.dsc
to pool/main/t/teapop/teapop_0.3.5-1.dsc
teapop_0.3.5-1_i386.deb
to pool/main/t/teapop/teapop_0.3.5-1_i386.deb
teapop_0.3.5.orig.tar.gz
to pool/main/t/teapop/teapop_0.3.5.orig.tar.gz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: private debian pools
On Monday, December 9, 2002, at 06:41 am, Joel Baker wrote: I'd honestly prefer to see the actual archive scripts (The One True Archiving Tools, of which all others must, by definition, be emulations) packaged and useable by mere mortals, but the last I'd heard, this was a long way off, and not terribly high on most priority lists. /me wonders whether some concept of namespaces in package names would be useful before we make it too easy for world + dog to run large repositories of .debs - Ximian was bad enough on its own, last I had to recover a system from someone using it... I dread to think how many versions of things like libgtksomeguicrapthatkeepsmakingabichanges (all mutually conflicting, and all required by something you *really need*) we'll end up with if people are easily able to maintain separate repositories. Cheers, Nick
Re: private debian pools
On Monday, December 9, 2002, at 10:48 am, Fabio Massimo Di Nitto wrote: I do not agree with you for different reasons. First of all noone forces people to add private archives to their sources.list. If users do that they should know that things can break more easily. Sometimes private archive are really usefull for pre-testing pkgs before they enter debian. And sometimes third-party archives are useful because a third party has the resources and inclination to look after something we don't (yet). Are you seriously saying that you don't want this to be made more reliable because no-one forces people to use such archives, and they should know that [if they use these archives] things can break more easily? Nobody forces people to use unstable (or even testing) either, and putting the relevant lines in your apt.sources can make things break more easily. Does this mean that we shouldn't try to make them work reliably? Exactly which bit of trying to make things work better do you think is a bad idea? Cheers, Nick
Re: private debian pools
On Monday, December 9, 2002, at 12:03 pm, Scott James Remnant wrote: I disagree that this is needed, not for any of the usual reasons, but for the simple reason that this functionality already exists. In part; it's not visible to the user, and it's not possible for a package to specify that it depends on a version of a package from a particular release/distribution/origin. The namespace of an apt repository is its URL, and any information available in a Release file at that URL. Which is inadequate; how do you tell whether the following lines access the same distribution? deb http://debian.lemon-computing.com/debian/ stable main contrib non-free deb http://debian.otago.ac.nz/debian/ stable main contrib non-free I imagine the problem you had was that the system had all the Ximian GNOME debs installed, and you wanted to use those from Debian instead. That could have been easily solved by putting the following in /etc/apt/preferences: Package: * Pin: release o=Debian Pin-Priority: 1000 Package: * Pin: origin ftp.ximian.com Pin-Priority: -1 In effect, Debian packages can force a downgrade of anything, do not consider Ximian packages for installation at all This is great, but it doesn't enable *packages* to specify what they need. Which is where the logic needs to be, if we really want to avoid problems. If we promote the use of third-parties using Release files, they would set the Origin: tag to something useful to them, perhaps in Ximian's case Ximian. All the functionality you want is already there! Some, but not all. Cheers, Nick
Re: Are we losing users to Gentoo?
On Fri, Nov 29, 2002 at 03:58:51PM -0500, Joey Hess wrote: and behind netbsd in the sory state of our cdrom mirror network. I'm with Joey on this; last time I tried to find Debian .iso images, it was a nightmare. In fact I couldn't find an official woody iso anywhere. As he also said, many of the mirrors are hopelessly out-of-date. Joy (or any of the rest of the www team) - where do you get the data to put into the mirror pages on www.d.o? I'd suggest that a simple method for mirror admins to let us know what they plan to mirror, and for us to test its availability on a regular basis, would be a good idea. (In fact I might even just do it). Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Live in a world of your own, but always welcome visitors.
Re: Are we losing users to Gentoo?
On Fri, Nov 29, 2002 at 04:58:30PM -0500, David B Harris wrote: On Fri, 29 Nov 2002 15:58:51 -0500 Joey Hess [EMAIL PROTECTED] wrote: The comparison is only fair with organizations that *want* you do do so(so not redhat, probably not openbsd, or mandrake, or others whose principal developers try to sell cds). Strictly speaking, given the ISO mirroring situation, we've never wanted people to use full 640M ISOs when we knew that 99% of people downloading would use a couple hundreds megs, at most. Given the ISO mirroring situation? Care to elucidate? I seem to remember seeing several offers of machines and bandwidth recently. It would seem to make sense to at least make it relatively easy for mirror admins who *do* have the available resources to provide ISO images. Even a single, reliable, possibly rate-limited, source for ISOs would be an improvement on what we currently have. Rate-limiting the source would, if necessary, provide a disincentive to people who would otherwise just jump in and download ISOs rather than using Jigdo. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Fine day for friends. So-so day for you.
Re: location of UnicodeData.txt
On Sat, Nov 30, 2002 at 12:35:25PM -0500, Jim Penny wrote: I think you are missing the points here. First of all, DFSG applied to the standard does not want to change the standard, but wants all to be able to change the text of the standard. Huh? If I change the text of the standard, I have changed the standard! No you haven't, only the standards body in question can do that. There are all sorts of reasons why you might wish to create derivative works based on the standard -- a new standard for a different purpose, for example. Or helpful documentation of the standard for people who are intimidated by the 'dry' nature of the original... On the other hand, if you wish to create a competitor to the unicode standard, say the debicode standard, I see no moral right that you have to incorporate, without permission, the unicode standard. You should expect to start from scratch! Engage brain. Do you think that if I want to create a competitor to, say, GNU Emacs, that I should expect to have to start from scratch? Or fetchmail? Or any one of the thousands of DFSG-free packages that are in main? Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Tomorrow will be cancelled due to lack of interest.
Re: Are we losing users to Gentoo?
On Sat, Nov 30, 2002 at 11:56:59AM +0100, Josip Rodin wrote: On Sat, Nov 30, 2002 at 11:23:23PM +1300, Nick Phillips wrote: Joy (or any of the rest of the www team) - where do you get the data to put into the mirror pages on www.d.o? Well, we get it from the Internet :) Please rephrase the question, I don't understand. Well, do the admins just send you a mail, do you list any that you happen to come across when randomly surfing around, do you have any more structured way for admins to tell you what they plan to mirror...? We already have that, but notice how the mirrors of the two archives aren't in the least bit of distress like the problem at hadn: the structure and contents of those is well defined, we have mirror checking scripts and we regularly monitor the output of that for any major problems. (I would suggest that you have a look at http://www.debian.org/mirror/) Hmmm... the link to Debian mirrors that include the debian-cd archive actually takes me to a useful-ish list... at least, some of the sites listed do have iso images. It's not terribly helpful if it's not linked to in such a way that it will be found by someone looking for CD images, though. The CD image mirrors don't even have a primary site -- *cdimage.d.o includes only jigdo files now. Those image mirrors are one big improvization. Doesn't matter whether there's a primary site that is only accessible to official mirrors, or whether they all have to get the images in some other way, so long as it is simple for them to automate keep up to date. And so long as the directory structure of all the mirrors is the same, for the parts that they mirror... Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] You will soon forget this.
Re: Are we losing users to Gentoo?
On Sat, Nov 30, 2002 at 09:23:43PM +0100, Marco d'Itri wrote: On Nov 30, Nick Phillips [EMAIL PROTECTED] wrote: I'm with Joey on this; last time I tried to find Debian .iso images, it was a nightmare. In fact I couldn't find an official woody iso anywhere. This is the way of mirror operators to tell you that you should really use jigdo or even better the mini-images. If there are to be no .iso images anywhere (which would suck), then it should say in big letters that there are no iso images anywhere. There are times when a .iso really is what you need, and when those times come, it really sucks badly to force people to search through a whole list of mirrors that are in reality nothing of the sort and most of which don't have what you need (and what our pages say they have). :-/ But joeyh appears to be on the case, so I am confident that the situation will be rectified before too long... :) Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] It may or may not be worthwhile, but it still has to be done.
Re: Ian Jackson in New Zealand
On Mon, Nov 25, 2002 at 10:59:29AM +1300, Philip Charles wrote: There are a number of us in Dunedin. ...and plenty of good cafes etc., too. :) -- Nick Phillips -- [EMAIL PROTECTED] You have been selected for a secret mission.
Re: Observation on syslinux/lilo/grub w/rsp to old Toshiba Laptops
On Fri, Apr 12, 2002 at 02:00:36PM -0500, Chad Walstrom wrote: I would agree. We can't Be everything to everyone. I've just recently acquired a laptop (my first!). It's a Toshiba T3400CT, an old 486/sx with a whopping 6.5 /color/ LCD! ;-) I've been able to boot it with tomsrtbt, but the debian rescue discs, even the lowmem ones from slink, do not work. DOS boots fine and the NetBSD discs boot as well (but I don't fancy a floppy installation). At 4 MB of ram and a picky BIOS, my best bet for getting this thing installed w/a base Woody installation is to create a custom boot disc that mounts an NFS root. To do so, it has to run pcmcia for the new Linksys NIC I purchased for it. I used to have one of these, I think (actually it may have been a 340 something). But with the colour screen and 4MB RAM. Slink was the *only* linux I could get onto it. I used a floppy boot PLIP install. That's what got me started on Debian. What fails on yours? -- Nick Phillips -- [EMAIL PROTECTED] Caution: Keep out of reach of children. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Any archive of pre-slink nonus sources?
On Sat, Jan 05, 2002 at 11:46:33PM +0100, Jesus M. Gonzalez-Barahona wrote: Hi, I've been looking at ftp://archive.debian.org, ftp://nonus.debian.org and other sites and I have not found nonus source packages for Debian distributions older than slink (hamm, bo, etc.) (In fact, I have found no packages at all). Any idea about where can I find them? I *think* I've got a full set of hamm cds that I could put up somewhere. And I've got a couple of really old Linux Developer's Resource CD sets with Debian on them, but I don't think they have sources. Although I may be wrong... I'll try to remember to check it out (won't be 'til next week, as we're moving offices this weekend - feel free to hassle me about it on Monday). Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Good news. Ten weeks from Friday will be a pretty good day.
Re: A language by any other name
On Wed, Sep 19, 2001 at 02:37:15PM -0500, John Hasler wrote: While en_GB is english as spoken in Great Britain. Perhpas one of the residents thereof can explain the difference. Great Britain == England, Wales, Scotland United Kingdom == England, Wales, Scotland, Northern Ireland British Isles == England, Wales, Scotland, All of Ireland, and probably a few other bits and bobs into the bargain. Full name of the UK is The United Kingdom of Great Britain and Northern Ireland. So using GB as a country code is incorrect, as Great Britain is *NOT* a country, really. Cheers, Nick not a pedant Phillips -- Nick Phillips -- [EMAIL PROTECTED] It's lucky you're going so slowly, because you're going in the wrong direction.
Re: A language by any other name
On Thu, Sep 20, 2001 at 07:42:53AM -0500, John Hasler wrote: Nick writes: So using GB as a country code is incorrect, as Great Britain is *NOT* a country, really. You better have a talk with the ISO about that. [grin] There are enough fucked-up standards out there that one more won't hurt... ...much. Besides, it was probably the ignorant Brits on the committee that decided on the codes that insisted that they didn't like UK :( And in oh-so-many other areas we also have to live with such things. We're known as Great Britain in various sports, but when England play football/ rugby/whatever, they usually misappropriate the UK national anthem (while the Scots, Welsh, and Northern Irish do their own thing)... we do end up using Land of Hope and Glory occasionally. Maybe there's a difference between a nation and a country, too. Point being, if most of us don't have a clue where we belong to, how should the ISO or anyone else be expected to get it right? Cheers, Nick (mix up a chunk of English with a bit of Welsh, lay a veneer of British over the result, and throw in a dash of UK...) -- Nick Phillips -- [EMAIL PROTECTED] Everything that you know is wrong, but you can be straightened out.
Re: A language by any other name
On Fri, Sep 14, 2001 at 10:47:18AM +0200, Wouter Verhelst wrote: What I meant to say is simple: you can't know what language people speak by having a look at the country they live in. Thus, the english do _not_, by definition, speak english. I never said that you could. You're splitting hairs that aren't worth splitting. English is, by definition, the language spoken by the English. That doesn't mean to say that for every people there will be a similarly named language. And the fact that there is not a similarly named language for every nationality does not in turn mean that my assertion that English is by definition the language spoken by the English is incorrect. I also implied that it'd be rather more cunning to argue the toss about this off-list than on. Still, you can't win 'em all... -- Nick Phillips -- [EMAIL PROTECTED] You can create your own opportunities this week. Blackmail a senior executive.
dpkg-source messages
I wonder whether anyone can point me at a likely cause for a slightly worrying list of messages I'm getting from dpkg-source when using dpkg-buildpackage to build a multi-binary package... during the build I get: dh_clean dpkg-source -b teapop-0.3.3 dpkg-source: building teapop using existing teapop_0.3.3.orig.tar.gz dpkg-source: building teapop using existing teapop_0.3.3.orig.tar.gz dpkg-source: building teapop using existing teapop_0.3.3.orig.tar.gz dpkg-source: building teapop using existing teapop_0.3.3.orig.tar.gz dpkg-source: building teapop in teapop_0.3.3-1.diff.gz dpkg-source: building teapop using existing teapop_0.3.3.orig.tar.gz dpkg-source: building teapop in teapop_0.3.3-1.diff.gz dpkg-source: building teapop in teapop_0.3.3-1.dsc debian/rules build DEB_BUILD_ARCH=i386 DEB_BUILD_GNU_CPU=i386 DEB_BUILD_GNU_SYS TEM=linux DEB_BUILD_GNU_TYPE=i386-linux DEB_HOST_ARCH=i386 DEB_HOST_GNU_CPU=i386 DEB_HOST_GNU_SYSTEM=linux DEB_HOST_GNU_TYPE=i386-linux make: Nothing to be done for `build'. The dh_clean line is the last element in the rules file's clean target, and the debian/rules build bit follows on. It's the bit in between (and in particular the apparent repetition) that worries me. It all appears to work OK, but those messages worry me. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] You will be reincarnated as a toad; and you will be much happier.
Re: dpkg-source messages
On Fri, Sep 14, 2001 at 12:11:52PM -0400, Matt Zimmerman wrote: On Fri, Sep 14, 2001 at 03:53:26PM +0100, Nick Phillips wrote: I wonder whether anyone can point me at a likely cause for a slightly worrying list of messages I'm getting from dpkg-source when using dpkg-buildpackage to build a multi-binary package... during the build I get: If you put the source package up for download somewhere, a few people will examine it and likely find the problem. At http://www.lemon-computing.com/debian/packages It's the teapop-0.3.3 source that I'm on about. I got fairly thoroughly confused during the process of converting the old single-binary rules into multi-binary rules, so any comments, suggestions etc. would be appreciated. Thanks, Nick -- Nick Phillips -- [EMAIL PROTECTED] You will experience a strong urge to do good; but it will pass.
Re: A language by any other name
On Thu, Sep 13, 2001 at 11:07:43AM +0200, Marcelo E. Magallon wrote: But Ben wants a consensus, so I'm asking here. FWIW, that file *is* shipped with locales as /etc/locale.alias, even if there's no sensible default for some entries there, as I have shown above. 2 aliases, english for the English, american for the Americans. -- Nick Phillips -- [EMAIL PROTECTED] People are beginning to notice you. Try dressing before you leave the house.
Re: A language by any other name
On Thu, Sep 13, 2001 at 11:46:06AM +0200, David N. Welton wrote: 2 aliases, english for the English, american for the Americans. I don't speak 'american', though, I speak 'english', and will look for that, as will the rest of my compatriots, when asked to select the language I speak. Nice try for a compromise, but it won't work. OK then, if the English aren't allowed to speak english [*], 2 aliases english-british and english-american. Before we go off on too much of a flame war here, *please* note that Marcelo says that Ben wants a consensus. Does anyone believe that a *consensus* is possible? Based on pragmatism, yes. Based on everyone having their ideal, no. Cheers, Nick [*] By definition, the English speak English. What the Americans speak is different to what the English speak. Therefore the Americans don't speak English. Simple as that ;) I am however prepared to let it go in the interest of avoiding a pointless flamewar. Happy to continue by private mail, though. Limited offer, for a short time only... -- Nick Phillips -- [EMAIL PROTECTED] You've been leading a dog's life. Stay off the furniture.
Re: kswapd eating CPU power ... any ideas why?
On Sun, Sep 09, 2001 at 06:19:01PM +0200, Hugo van der Merwe wrote: Hello, I'm working on a little project putting Debian on a CD. (Works great so We've done this; not particularly neatly packaged etc., but works fine. If anybody's interested, I'll try to get someone to write it up and/or stick the tools we use for creating CDs up somewhere. Hugo; you're probably doing it slightly differently - might be cunning to compare notes once you've done it see where we've done things differently... Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Are you ever going to do the dishes? Or will you change your major to biology?
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Fri, Sep 07, 2001 at 10:35:06AM +0200, Christian Kurz wrote: So you want to compare packages from an upstream with packages created by either someone or a team for a distribution? No, I'm saying that if you're dealing with a package that will be distributed by means over which you have no control, then you are forced to include the translation in the package. If you have control over the distribution methods, then you can integrate the translation system into the distribution system however is most convenient, which almost certainly doesn't mean forcing it into the package in every case. If on the other hand you are one of those distributions, distributing all sorts of packages, some of which have upstream translations, some of which don't, some of whose maintainers are able and willing to spend time on translations, some of whose maintainers aren't, then it doesn't make sense to set yourselves up in such a way (translations always living in packages) that translations will only be available when the maintainer does work on them. Which creates the situation, that packages in debian will on the one hand be different then the one you can get from the upstream and on the other hand it's a violation of our social-contract: No, it doesn't. So if we correct wrong translation or create a new translation, then we shall send it to the upstream and inform them. With your suggestion above, this will only happen, if either the translator is doing this task also or if the maintainer is taking care of the translation. In all other cases, where the maintainer is not taking care of the translation, we'll have a nice violation of that statement. And since the maintainer is the contact to the upstream and responsible for the debian package, he shall be involved in the translation. Great. So rather than have a system that enables us to get a working translation, the option for the maintainer to be notified/involved, and otherwise the ability for the translators to send translations upstream, you'd rather keep banging your head against the brick wall that is maintainers just not able/willing/with enough time to deal with, check, integrate translations, and keep *us*, never mind upstream, from getting good translations. Feel free to keep banging your head against any walls you like, but don't complain when you find you're not getting through. Splitting translation out of upstream packages is in my opinion a bad thing and should never be done. I was careful to avoid suggesting that such a thing should be done. Although providing a better/alternative translation as an override should be simple. And if a maintainer decides that the upstream translations are worse than useless, then yes, they should be free to remove them, and the translation project should be able to provide alternatives without necessarily causing extra work for the maintainer. Fine, no-one is saying that you shouldn't be able to arrange to be notified when a particular package has a translation made available. And how do you propose to integration this notifications? According to your statement, everyone can update the translation without having to hassle with me and that's the point which makes me sad. If a translation is added to the official Debian archive, then it would be simple to arrange to notify any maintainer who wanted to know. If some third party at some random site provides a translation archive, then it's up to them whether they tell you or not. That doesn't mean that we shouldn't provide a mechanism for them to do so. It's free software after all. That means that if someone wants to do a translation, or if they want to run the code through an obfuscator, they don't *have* to tell you. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Abandon the search for Truth; settle for a good fantasy.
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Thu, Sep 06, 2001 at 01:08:25PM +0200, Christian Kurz wrote: On 01-09-05 Nick Phillips wrote: The translation of any part of a package, be it the text of error messages, So, shall we now remove all .po files and other translation from upstream packages because they are not part of a package? The translation of the error messages and other messages of a program belong to the package of it. That depends on whether you're distributing one package or thousands. If upstream includes translations, then we don't have to worry about the maintainer managing inclusion of whichever languages people happen to write translations for. But if we want to be, and are, able to easily add extra translations, or override poor-quality upstream translations (all without causing hassles for maintainers), then why not? Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Everything will be just tickety-boo today.
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Wed, Sep 05, 2001 at 10:18:04AM -0400, Vociferous Mole wrote: I disagree with this. Translation of text that is part of the upstream source needs[1] to go to/through the maintainer, as it should be integrated upstream. Steve [1] Okay, it *could* be sent directly upstream, but often the debian maintainer has an established relationship to the upstream author, and may be able to fit them into the package more cleanly. And if the maintainer is in the no time for translations camp, then nothing happens. There's no reason why we can't cater for all types of maintainer. -- Nick Phillips -- [EMAIL PROTECTED] You will feel hungry again in another hour.
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Thu, Sep 06, 2001 at 07:47:26PM +0200, Christian Kurz wrote: upstream packages because they are not part of a package? The translation of the error messages and other messages of a program belong to the package of it. That depends on whether you're distributing one package or thousands. Why do make this dependant on the number of packages? I think that using some count like you do, is a bad thing. Because if you're only distributing one package or small group of packages (say, KDE), then your focus is making the translations available for all the people who use that package, whether or not the particular distribution they got it from has infrastructure to support translations. Hence it makes sense to put the translations in the package in that case. If on the other hand you are one of those distributions, distributing all sorts of packages, some of which have upstream translations, some of which don't, some of whose maintainers are able and willing to spend time on translations, some of whose maintainers aren't, then it doesn't make sense to set yourselves up in such a way (translations always living in packages) that translations will only be available when the maintainer does work on them. Think about it. But if we want to be, and are, able to easily add extra translations, or override poor-quality upstream translations (all without causing hassles for maintainers), then why not? Because for example I would prefer to be informed if any of my packages has a bad upstream translation and some has better one for me. Then I can forward and discuss it with the upstream and he can include it maybe in the official upstream sources. That way we wouldn't only improve the translation for people using debian, but also for people who are using some other free operating system and the upstream package. Fine, no-one is saying that you shouldn't be able to arrange to be notified when a particular package has a translation made available. There is a difference between not requiring a maintainer to be involved in the provision of translations and not enabling a maintainer to be involved in the provision of translations. -- Nick Phillips -- [EMAIL PROTECTED] Fine day to work off excess energy. Steal something heavy.
Re: Making better use of multiple maintainers
On Wed, Sep 05, 2001 at 01:02:34AM +0200, Martin Michlmayr wrote:
useless in the case of celestia. What happens if you're on vacation,
woody is released tomorrow and a RC bug is filed on celestia today and
noone cares to upload a fixed package? Similarly, if you were really
busy for a while, your backup could do uploads so the users don't have
to wait for bug fixes too long.
I'd guess that it {could be|is} often the case that whilst only one
person knows the package well enough to take on major upgrades, development
etc., several know it well enough to be able to make bug fixes in the
manner that the maintainer would wish.
What I'm trying to say is that a backup makes sense in virtually all
cases, even in the case of smaller packages. Bigger packages certainly
benefit to a higher degree, but I think it makes sense for smaller
packages, too.
Absolutely.
--
Nick Phillips -- [EMAIL PROTECTED]
A long-forgotten loved one will appear soon.
Buy the negatives at any price.
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Wed, Sep 05, 2001 at 08:00:18PM +1000, Martijn van Oosterhout wrote: No, make it opt-in and don't sent them by defaulot. Just checking, but having it optional is mutually exclusive with any final solution that involves the maintainer having to put the translation into the .deb. I'd have thought that the current situation re. maintainers putting translations into .debs makes it blindingly obvious that requiring them to do so in order for a translation to become available is a bad idea. If they don't get sent, how will the maintainer know when there are new translations? They shouldn't need to know. -- Nick Phillips -- [EMAIL PROTECTED] Excellent day for putting Slinkies on an escalator.
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Wed, Sep 05, 2001 at 10:41:53AM +0200, Christian Kurz wrote: On 01-09-04 Nick Phillips wrote: On Tue, Sep 04, 2001 at 09:06:04PM +0200, Michael Bramer wrote: I don't expect most maintainers to be able or inclined to keep track of a shedload of different translations, and those who are that keen should May I ask if you are aware about the ongoing translation of the debconf templates via the bts? If yes, would you mind explaining what's the difference between keeping track of thsoe translation/bugreports and keeping track of the package translation via a simple ddts mail? Yes. Ideally, the maintainer should not have to be involved in those translations either... If you look at it logically, *everything* that has to do with translations is quite distinct from the other tasks relating to package maintenance. The translation of any part of a package, be it the text of error messages, the text in control, or the text in debconf templates, does not need to be part of the package, and hence certainly shouldn't have to be. The translations can easily be completely abstracted from the package itself, and that relieves the maintainer from having to have anything to do with them. It would also be very simple to have another subdirectory in the debian area of the source into which any translations over which the maintainer did wish to keep control could be placed (this would also be useful for sending packages independently of any archive/CD set). The fact that some maintainers want control of some of the translations in their package should not force translators to rely on maintainers, and should not force upon all maintainers the task of managing translations. Translations do not belong in the package. It should be possible to include translations in a package, but I don't see that this is a sensible way to do it by default, all the time. Cheers, Nick [hoping I've not missed something that means I'm making a prize tit of myself] -- Nick Phillips -- [EMAIL PROTECTED] You will soon forget this.
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Wed, Sep 05, 2001 at 12:00:42PM +0200, Michael Bramer wrote: It needs to be stored, in /var/lib/dpkg/status, as a single file. This is so that dpkg can make safe updates to it. Trying to sync multiple files is not a simple solution. no, it does not store there. And I can explain it: Well, shouldn't it? Wouldn't it make sense to have the translated description in there rather than the original one? -- Nick Phillips -- [EMAIL PROTECTED] Slow day. Practice crawling.
Re: Date format (was: How many people need locales?)
On Wed, Sep 05, 2001 at 12:53:37PM +0200, Petr Cech wrote: On Tue, Sep 04, 2001 at 09:17:12PM +1000 , Martijn van Oosterhout wrote: Does that mean it should always take a certain format irrespective of the locale? If so, which format? or number format. ie. in Czech decimal separator is `,' comma and in C it's `.' dot. OK, now restart gnumeric in other locale and you cannot load the file :(( Which implies that it needs to know the locale used by the file. This means that you either need to: 1) always use the same locale, or 2) tell it which local is used by the file at load time, either manually or by the use of metadata in/around the file. -- Nick Phillips -- [EMAIL PROTECTED] Think twice before speaking, but don't say think think click click.
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Wed, Sep 05, 2001 at 09:49:09PM +1000, Hamish Moffatt wrote: Do package descriptions change so regularly that translated descriptions couldn't be submitted through the bug tracking system and included in the next upload? Apparently maintainers regularly fail to do anything with them at all for ages. Besides which there is no real *need* for the maintainers to be required to take action to make translations available. Most of my packages have never had their description changed from when I first wrote it. It would be better if we could just include translated descriptions in the debian/control file. The descriptions are just one of the parts of a package that needs to be translated. It would make more sense to consider the way to deal with *all* the text in the package that needs to be translated. Why put the translations in the control file? Why not just make available (either in the package, or elsewhere, depending on the means by which the package is to be distributed, and the maintainer's knowledge and inclination) the translations for the whole package in one place? Cheers, Nick, who is waiting for someone to tell him he's completely wrong. -- Nick Phillips -- [EMAIL PROTECTED] Tonight's the night: Sleep in a eucalyptus tree.
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Thu, Sep 06, 2001 at 01:07:40AM +1000, Martijn van Oosterhout wrote: The description is part of the package, can we agree on that one? What is the difference between a translated description and the original one, except for which language it is written in? The original, canonical, description is part of the package, and a necessary part at that. Others aren't. They're just different representations of the original one, and don't *need* to be provided by the maintainer. If the maintainer chooses to provide, obtain, manage translations, fine. If not, also fine. The translations are not a necessary part of the package, they are related to it, and could be provided however is most convenient for the situation at hand - not necessarily in one big lump. Well, all descriptions are in english by default and there is no real reason to store every description for every package on every machine/archive. Exactly. The package is the responsibility of the maintainer, and s/he has the final words on all aspects of how it should be packaged (subject to policy, of course). To me, it looks like you want this changed, which I think is a bad idea. But then the maintainer has to take full responsibility to maintain the translations. And several maintainers have said they don't even want to know about new translations since they can be added without any action on their part. Exactly again. If translations are available both from the maintainer and from a separate translation archive, it should be up to the user to decide which they want to use. That would allow for all sorts of flexibility - as I said before, you could even have different translations in the same language. I can think of at least one way in which this could be useful. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Someone whom you reject today, will reject you tomorrow.
Re: feedback on jablicator: package choice sharing tool
On Mon, Sep 03, 2001 at 09:07:46PM -0700, Jeff Breidenbach wrote: I just wrote jablicator [1], which is a tool to help novice Debian administrators leech off of more experienced administrators. 0: General reactions? Would anyone consider using this tool? 1: Does some other Debian package already have this functionality? The easy way to do it is to use dpkg --get-selections to create a text file package list, and dpkg --set-selections to set it, before doing an appropriate apt/dpkg command to update to the selected list (apt-get dselect-upgrade?). Cool name, though. Don't change that, whatever else you may end up changing. It'd be good to be able to create something like a commented version of the output from dpkg --get-selections so that you could say why you've purged lynx and added w3m-ssl, for example. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] You can create your own opportunities this week. Blackmail a senior executive.
Re: new proposal: Translating Debian packages' descriptions
precedence over external ones, if so desired. 2) to enable merging of external translation files into a single package (not so much for use in the main archive, but for Fred Bloggs to mail to his mates, for example). 3) I'm sure there are more... In a Packages file is not only the Description. You know, it include all other tags from the control file. If we delete this tags and put only the Description in one file and make Descriptions-XX files, we save 50% of size. And if we save one Description-XX file per dist and not per arch, we save more. Packages files in the translation sections of the archive would only need to contain language-independent information. troll? Although what happens when we need translated package names I'm not sure. Actually, I don't think it'd be too difficult. /troll? With this we need only 30 Descriptions files per languages [4]. This should only 14 MByte per languages (if all descripions are translated). This files have only the package name and the translated Description (and maybe the Version) in it. The APT process can generate some .po files from the normal Packages file and all downloades Descriptions files. This is not a good way to go; see above. If we don't like this process on the client all the time, we can produce Descriptions-XX.po files and the clinet must only download this file and save this in the right dir. But this file will include the orignal description and with this it has the double size and download time. Bad, translated packages file should be available in archive providing translations, as above. This overrides basic untranslated descriptions etc. where present. With the Descriptions-XX[.po] file the admin must only download the needed languages and not all languages. This is an essential feature of *every step* of the translation process. 5.) translated descriptions in the package. Now, this is the difficult part. We need a way to add the translated description in the normal package. In the last mails, we see some proposals. In privat packages or if the maintainer know some langauges and make the translation hisself, it is a good way to include the translation in the package. I'm not convinced that this is a ok in the normal debian archiv. Agreed. I see only one problem: the size. I see only one problem: it's just a horribly bad thing to do ;) But how get the maintainer the translation? We have some cases: Maintainers should *never* *need* the translation. Translations are logically *entirely* separate from the package itself. So what the hell does the maintainer need them for? Unless the maintainer originates them, they don't need them. Anyone claiming that they're going to keep track of goodness-knows-how-many translations, which may be updated in bits here and there, is IMHO overly vain and talking bollocks. Maintainers might want to be notified when translations for their packages are added to the official debian archive (most likely only for certain languages), but I reckon most will give up after the shower of mails they'd end up getting. Using this system, the maintainer could have a veto over translations in the official debian archive (if anyone bothered to set up a notification mechanism), but not elsewhere (for example, there'd be nothing to stop me setting up a comedy translation in english, taking the piss out of various packages, or with all the normal text passed through one of the filters package's filters, for use by anyone who felt like adding it to their apt sources). In fact I think the last example there proves that this is a Good Way of doing it; unintentional but useful or humourous side-effects like that are generally a good sign. I haven't really gone into which of the currently proposed steps would best lead into this kind of scenario in future, but I thought that could wait until you've all agreed that this is a really cunning plan and definitely the best way to do it ever. You know you want to ;) Cheers, Nick P.S. I've been trying not to get involved in this thread in the hope that it would come up with the Right Answer and go away, but... -- Nick Phillips -- [EMAIL PROTECTED] If you sow your wild oats, hope for a crop failure.
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On Tue, Sep 04, 2001 at 09:06:04PM +0200, Michael Bramer wrote: comments? Only send them to individuals who've asked for them? I don't expect most maintainers to be able or inclined to keep track of a shedload of different translations, and those who are that keen should be able to muster the energy to make the small effort to subscribe to receive notifications regarding particular packages. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Look afar and see the end from the beginning.
Re: new proposal: Translating Debian packages' descriptions
On Tue, Sep 04, 2001 at 02:24:41PM -0500, Steve Langasek wrote: I think it's very important to have the translations in the *source* package. Also agreed. Why? Each system will usually only require one language per package. The rest, as far as any particular system is concerned, is just bloat. It would be more powerful, flexible to keep translations physically (as they are logically) separate. Granted, there may be cases where it is useful to *be able* to put translations into source/binary packages, but I believe that in most cases, it will be more convenient and more useful to keep them separate. Keeping them separate reduces space required in any particular archive, or on any particular system. It reduces maintainer workload, reduces the translators' reliance on maintainers, increases accountability (by allowing each uploaded item to be signed by the relevant maintainer/translator), reduces unnecessary upload/downloads, increases flexibility (for example allowing multiple different sources of any particular language, or makes it easy to provide unofficial translation archives), it makes more sense given a potentially arbitrary number of translated languages... As I said elsewhere, think of the archive as a big database (which it is). Then think about how you would/should normalize the data. When you ship bits around outside the database, it may be useful to be able to encapsulate several related records from the database into one object. Fine, but that doesn't mean that you should screw up your database and do it that way all the time. For the binary package, I don't know... - Gnome and KDE do include all translations, and I think it's easier to handle. Additionally, disc space is really cheap these days, so maybe it would be better just to include all the descriptions, too. Gnome and KDE include the translations because they know that that's the only way they can ensure that everyone who distributes their packages distributes the translations. They are designing their systems in the absense of any other good working way of doing it *right now*. The fact that they do that in no way implies that Debian should also do that. I think it does belong in the binary package; if not, I'm not sure why we would want it in the source package at all. No reason at all. It doesn't make sense to have it in either, in most cases. I believe translated descriptions have just as much reason for inclusion in the binary package's control file (or in a functional equivalent) as the rest of the informational stuff that's in there. No they don't. Translations are not providing extra information. They are providing the same information in multiple different ways. If translated Description: fields in binary packages are not important, then why do we currently have the untranslated Description: in the control file? Because you need *a* description, and in the past there has only been one description, so there was no reason to normalise it out into a different object. You don't, however, need 15, and when there are 15 or however many, it makes sense to normalise them out. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] If you think last Tuesday was a drag, wait till you see what happens tomorrow!
