Re: [Python-Dev] Issue 1170: Unicode for ‘shlex ’
2009/8/21 Ben Finney ben+pyt...@benfinney.id.au: Howdy all, What is the procedure for finding out why an issue hasn't progressed? I don't want to fill the bug database with such noise. In this case, it's probably because no one officially maintains the shlex module at the moment. In the case of URL:http://bugs.python.org/issue1170 (“shlex have problems with parsing unicode”), the problem is apparently addressed by a patch, assigned to that issue since 2007-12-22. There is no indication in the report why it's not yet applied. I will leave a few initial comments. I'd really like this fixed in the 2.x series if possible. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: help needed
On Sat, Aug 22, 2009 at 01:17, Martin Geislerm...@lazybytes.net wrote: In the general case, you can specify an extension to be enabled by filename: [extensions] foo = ~/src/foo So if I can enable an extension like that on your system, I might be evil and commit a bad extension *and* enable it at the same time. You might argue that one should then limit which extensions one can enable in a versioned file, but it seems hard to come up with a good mechanism for this. The current mechanism is the users own ~/.hgrc file which can be seen as a whitelist of extensions he trust. Thanks for explaining that bit, Martin. Everyone: Martin is also a hg crew member. It sounds to me like somehow requiring extensions to be enabled (without actually enabling them) would help mitigate the issues somehow, although it's still a distributed system and so clients cannot be trusted (e.g. I might put a win32text stub in there somewhere that does nothing). Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 1170: Unicode for ‘shlex ’
What is the procedure for finding out why an issue hasn't progressed? It's fairly simple: just read through the issue, and it should be obvious. In the specific case, no committer has ever commented on the issue, so chances are high that no committer has ever *seen* the issue. I don't want to fill the bug database with such noise. And likely, posting to the issue won't be a way to find out, since no committer would see your comment. In the case of URL:http://bugs.python.org/issue1170 (“shlex have problems with parsing unicode”), the problem is apparently addressed by a patch, assigned to that issue since 2007-12-22. Apparently, or really? Did you review the patch? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: help needed
Stephen J. Turnbull step...@xemacs.org writes: Mark Hammond writes: [extensions] required_for_commit = win32text,some_other_ext That might require a change to hg's ini file semantics if currently it refuses to parse [extension] sections in versioned hgrcs. It doesn' refuse anything like that. When Mercurial starts, it reads these configuration files: http://www.selenic.com/mercurial/hgrc.5.html#files Notice that they are all outside the clone's working directory, the closes one is the repo/.hg/hgrc file. As I wrote somewhere else in this thread, you can add %include ../.repo-settings in your repo/.hg/hgrc file, and this will result in repo/.repo-settings being loaded (and this file *is* in the working copy and can thus be put under revision control). -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. pgpmaXyOsnq7C.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: help needed
Stephen J. Turnbull step...@xemacs.org writes: Mark Hammond writes: On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote: Possibly - although I would expect the existing section names be reused when applied to a versioned file, I'd be more than happy for the hg guys to declare new names are appropriate for this. If there's already an [Encode] section, that's different. (I don't details, I'm not that big a Mercurial fan.) But you'd still need a way to differentiate win32text rules from other encoding rules. There is a [decode] and an [encode] section: http://www.selenic.com/mercurial/hgrc.5.html#decode-encode The win32text extension works by defining new filters which can then be used like this: [encode] ** = cleverencode: [decode] ** = cleverdecode: (they are clever because they skip binary files) True, but how many people will just download the extension and enable it? In the ideal world, exactly as many people who would read the Python developer guide, then download and install the extension based purely on that. IOW, it is Python itself setting the policy, so people need to make their own decisions based on that, regardless of whether the tool enforces it or not. You're missing the point. I'm not talking about whether it will work for Python, I'm talking about the worry that somebody will post a way cool Python branch and require a private extension, which everybody will just automatically install and enable, which extension then proceeds to phone home to Spammer Haven, Inc. with the contents of your email contact list. That's what I mean by social engineering, and why I worry about policy pushback from Mercurial HQ. Maybe that's more paranoid than they are But it can't hurt your cause to be ready for that kind of worry. Oh, we try to be very paranoid in Mercurial :-) That's why you don't see any support for copying hgrc files when you clone and why hg wont trust hgrc files not owned by you: it should be safe to do cd ~collegue/src/python hg tip -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. pgpAl8dMJYc9u.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: help needed
2009/8/22 Martin Geisler m...@lazybytes.net: Oh, we try to be very paranoid in Mercurial :-) That's why you don't see any support for copying hgrc files when you clone and why hg wont trust hgrc files not owned by you: it should be safe to do cd ~collegue/src/python hg tip So, is the implication therefore that there would be resistance to having some way of making a setting which *is* copied on clone, which says that you can't commit in this repository unless you have the following extensions enabled? Or is the fact that it's only saying you must have an extension called win32text enabled and not actually enabling code directly, sufficiently secure to make it acceptable? Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: help needed
Paul Moore p.f.mo...@gmail.com writes: 2009/8/22 Martin Geisler m...@lazybytes.net: Oh, we try to be very paranoid in Mercurial :-) That's why you don't see any support for copying hgrc files when you clone and why hg wont trust hgrc files not owned by you: it should be safe to do cd ~collegue/src/python hg tip So, is the implication therefore that there would be resistance to having some way of making a setting which *is* copied on clone, which says that you can't commit in this repository unless you have the following extensions enabled? It sounds somewhat invasive to forbid commits. Moreover, repository owners should remember that clients can do whatever they want, so this can only be a hint, never a requirement. I don't think this has been mentioned: When you clone you move history (changesets) only and I'm pretty sure you cannot even read the configuration settings over the wire protocol. So cloning from a HTTP URL wont copy a setting found in the repo/.hg/hgrc file. This implies that the settings should live in a version controlled file. I think that is sensible under all circumstances. So if the win32text extension (horrible name, I agree... it should have been made more general and called eolconvert or something like that) would just read a configuration file from the repository, then all you should ask people is to enable win32text. Or is the fact that it's only saying you must have an extension called win32text enabled and not actually enabling code directly, sufficiently secure to make it acceptable? It is definitely secure enough to be included. There should be a way to turn off those hints, though: I might want to clone the Python repository and play around with it without enabling win32text. -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. pgp94ixQNXvhg.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: help needed
Stephen J. Turnbull wrote: Dirkjan Ochtman writes: [Clients] cannot be trusted (e.g. I might put a win32text stub in there somewhere that does nothing). Heck, just edit the .hgrules file, and do a Houdini on any and all handcuffs. Don't trust software, trust people -- but help them avoid thoughtless mistakes. Yes, on the client side we're not trying to prevent someone doing the wrong thing deliberately - just nudging them towards doing the right thing so they won't run afoul of the server side checks that will actually *enforce* the line ending rules for the main repository. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Setting up a buildbot
I've just had a look on python.org, but couldn't immediately see a pointer to instructions on what the process is to set up a buildbot. There's a not on setting things up for pybots, but nothing on the core buildbot setup. The reason I'm asking is that I'm thinking of seeing if I could set up a Windows buildbot of some sort, to offer extra coverage. It's early days, yet, but I wonder if someone could answer a few questions for me: - Is there any documentation on how to set up a buildbot? If so, can someone give me a pointer? - What configurations would be most useful? (I've got a 64-bit PC, so I can theoretically set up 32 or 64 bit VMs with VMWare, and with my shiny new MSDN subscription, I can set up whatever OS is most useful). - Is it possible to set up the pull/build/test side of the process separately, before linking it into the full buildbot farm? That would let me try things out on my own, and iron out any configuration glitches before dumping it on the world. Thanks for any pointers. It's early days yet, so it may be a while before I have anything properly set up, but I'd like to see what I can do. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Setting up a buildbot
-On [20090822 21:30], Paul Moore (p.f.mo...@gmail.com) wrote: I've just had a look on python.org, but couldn't immediately see a pointer to instructions on what the process is to set up a buildbot. http://wiki.python.org/moin/BuildBot comes to mind. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Success is satisfaction with yourself... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: help needed
On 22/08/2009 6:52 PM, Stephen J. Turnbull wrote: Mark Hammond writes: On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote: Possibly - although I would expect the existing section names be reused when applied to a versioned file, I'd be more than happy for the hg guys to declare new names are appropriate for this. If there's already an [Encode] section, that's different. (I don't details, I'm not that big a Mercurial fan.) But you'd still need a way to differentiate win32text rules from other encoding rules. As mentioned in my previous post, I'm trying to avoid bike-shedding what the hg guys are better placed to decree. How they choose to spell these options is something for hg to decide, and I doubt my opinion matters enough to bother sharing, let alone advocating. This way you aren't *enabling* extensions in this versioned file, True, but how many people will just download the extension and enable it? In the ideal world, exactly as many people who would read the Python developer guide, then download and install the extension based purely on that. IOW, it is Python itself setting the policy, so people need to make their own decisions based on that, regardless of whether the tool enforces it or not. You're missing the point. I'm not talking about whether it will work for Python, I'm talking about the worry that somebody will post a way cool Python branch and require a private extension, which everybody will just automatically install and enable, which extension then proceeds to phone home to Spammer Haven, Inc. with the contents of your email contact list. That's what I mean by social engineering, and why I worry about policy pushback from Mercurial HQ. No, you are missing the point - social engineering doesn't require tool support - tools simply make certain things easier. Maybe that's more paranoid than they are But it can't hurt your cause to be ready for that kind of worry. If this becomes seen as 'my' cause, I suspect it will run out of steam very quickly. I truly hope python-dev, as a community, takes some ownership of this issue or I predict the effort will fizzle out without a workable solution. There seem to be a number of people who agree the status-quo isn't acceptable, so I'm not sure what would happen in that case... Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: help needed
On 22/08/2009 7:09 PM, Martin v. Löwis wrote: From my POV, this would be required in some form or another before such a scheme could actually work. Without it we end up with an improved win32text (good!) I still think this would be actually bad. Instead, a new extension should be written, with a name that does not have win32 as a substring, and that has no provision for guessing line breaks by inspecting files. To be clear, you are suggesting: * Having hg enforce an extension as required is good. * Python adopting win32text as that extension would be bad - instead another extension with different semantics (ie, no guessing based on file content) should be used, and enforced, instead. Or have I misunderstood? Assuming I am correct, I am inclined to agree - win32text may be good enough in the short term, but it is far from ideal. Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 1170: Unicode for ‘shlex ’
Benjamin Peterson benja...@python.org writes: I will leave a few initial comments. Thank you. Martin v. Löwis mar...@v.loewis.de writes: In the case of URL:http://bugs.python.org/issue1170 (“shlex have problems with parsing unicode”), the problem is apparently addressed by a patch, assigned to that issue since 2007-12-22. Apparently, or really? Did you review the patch? No. The bug report showed that others had already tried it and said it worked; and also, I don't consider myself qualified to review that particular patch. What is the procedure for finding out why an issue hasn't progressed? It's fairly simple: just read through the issue, and it should be obvious. In the specific case, no committer has ever commented on the issue, so chances are high that no committer has ever *seen* the issue. Okay, so not obvious to someone (like me) who doesn't immediately know who is or is not a committer. Thanks for the clarification. I don't want to fill the bug database with such noise. And likely, posting to the issue won't be a way to find out, since no committer would see your comment. I'll take that as confirmation that asking in this forum is the right procedure. -- \ “We spend the first twelve months of our children's lives | `\ teaching them to walk and talk and the next twelve years | _o__) telling them to sit down and shut up.” —Phyllis Diller | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
