Re: Idea: about package installation under chroot.
G'day, just saw the discussion about chroot stuff and avoiding starting daemons/ mounting proc etc. The lessdisks package has a lessdisks-chroot command that does all this for you. I believe it diverts start-stop-daemon so that it fakes starting/stopping the daemons. -- Donovan Baarda [EMAIL PROTECTED] Obsidian Consulting Group -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python 2.2 - python 2.3 transition
On Wed, 2003-08-20 at 15:49, Anthony Towns wrote: On Tue, Aug 19, 2003 at 11:44:22PM -0400, Derrick 'dman' Hudson wrote: The negative effect for the users is that you can't upgrade python while wxgtk-python is installed so you can't try out the latest-and-greatest python in the meantime. This is the issue at hand. Sure you can: $ sudo apt-get install python2.3 The dependency stuff merely notes that upgrading python without also upgrading wxgtk-python may break stuff. actually, if the dependencies are right, you cannot upgrade to python (2.3) without also upgrading to wxgtk-python (2.3) or de-installing wxgtk-python (2.2). There is a difference between break stuff and not installable :-) When the dependencies are right, you can't break stuff, because a broken combination is not installable. if you can then the dependencies are wrong and you should file a bug-report. -- Donovan Baarda [EMAIL PROTECTED]
Re: python 2.2 - python 2.3 transition
On Thu, 2003-08-07 at 02:17, Josip Rodin wrote: On Wed, Aug 06, 2003 at 09:33:26AM -0500, Chad Walstrom wrote: Am I the only one who has a disgusting reminiscence of netscape*.* packages every time python* is mentioned? :P hmmm.. just curious... why? The short of it: he's joking. Note the smiley. Even though package names that have version numbers tends to bloat the archive, but there really isn't a more graceful way for allowing two versions of the software to exist on a system at the same time. Josip knows this, hence the smiley. Yes. It's also a smiley with the tongue out, meaning I'm actually saddened by the end-result of the situation and resort to joking out of sheer desperation. There is an alternative... only support one version of python... and be stuck at python 2.1 until everything uses it, or lose things like zope etc. Personally I was going to post nice job everyone... the Python Policy looks like it is working. There are still a few niggly things, but if Debian can go to Python 2.3 within days of it being released without breaking anything else, I'd say thats pretty damn impressive. I'd be curious to know how other distro's are/will handle the transition. -- Donovan Baarda [EMAIL PROTECTED]
Re: Make python2.2 the python default
On Sat, Aug 24, 2002 at 12:52:33AM +0200, Matthias Klose wrote: Anthony Towns writes: On Fri, Aug 23, 2002 at 11:33:10PM +1000, Donovan Baarda wrote: On Fri, Aug 23, 2002 at 01:48:36PM +0200, Matthias Klose wrote: I'm planning to make python2.2 the python default version for unstable next week (uploading the packages on 2002-08-28). Preliminary packages can be found at http://ftp-master.debian.org/~doko/python/ Please send packaging problems with the packages to debian-python. Are these then going to propogate into testing in the normal manner (all dependencies met, no conflicts, no bugs etc)? I hope so :-) Ha. Haha. Hahahahahaha. (You're going to have to get _everything_ that has a python-foo all in sync, including everything it depends on, with no RC bugs all at the same time, and keep it that way for a week... Well, it's not quite that bad, but it's close) I realise that, I just wanted to make sure there were no special plans to hold it back from testing. That's the price we have to be able use /usr/bin/python, not the versioned binary :-( This is also the benefit... it can't go into testing until it's ready. I think it would be possible for an updated python to drop into testing with a handful of python-foo packages holding them back... just file an RC bug against them saying they need to be upgraded, they vanish from testing, and the updated stuff drops in. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
Re: Make python2.2 the python default
On Fri, Aug 23, 2002 at 01:48:36PM +0200, Matthias Klose wrote: I'm planning to make python2.2 the python default version for unstable next week (uploading the packages on 2002-08-28). Preliminary packages can be found at http://ftp-master.debian.org/~doko/python/ Please send packaging problems with the packages to debian-python. Are these then going to propogate into testing in the normal manner (all dependencies met, no conflicts, no bugs etc)? I hope so :-) BTW, what is happening with python-central... is it becoming standard? If so, the pythonX.X packages will need to use it. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
Re: Make python2.2 the python default
On Fri, Aug 23, 2002 at 03:26:00PM +0200, J?r?me Marant wrote: On Fri, Aug 23, 2002 at 01:48:36PM +0200, Matthias Klose wrote: I'm planning to make python2.2 the python default version for unstable next week (uploading the packages on 2002-08-28). Preliminary packages can be found at http://ftp-master.debian.org/~doko/python/ Please send packaging problems with the packages to debian-python. When preparing packages for multiple versions of python, please drop python1.5 support and consider providing support for the experimental python2.3 packages. Any reason to keep 2.1 ? I would say yes. We need 2.1 in sarge at least, so that each generation of Debian still has support for the previous generation's standard python. Under the new policy having the old packages hang around doesn't hurt us in any way except chew up disk space... these packages don't even need to be mantained unless serious bugs are found in them, at which point it probably does become easier to dispose of them rather than fix them. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
Re: Move to python 2.2 as default release?
On Wed, Aug 14, 2002 at 04:28:53PM -0400, Jim Penny wrote: On Wed, Aug 14, 2002 at 02:54:31PM -0500, Chris Lawrence wrote: On Aug 14, Laura Creighton wrote: [...] One final point. We will almost definitely not switch the default python in sid (current unstable), until there is talk that Sarge is nearing a freeze. There is simply no point in undergoing the pain of a major python release twice in a single unstable cycle. We will instead make the decision of what python will be default in Sarge when it nears release, not now. There is talk of trying to keep sarge in a permanently releasable state. Debian release cycles take forever. I would think waiting around for a sarge freeze before upgrading the default python would be waiting needlessly. We'd just end up with Debian only getting every 3rd major Python release as the default, and making each release all the more painful. One of the main points of the current Debian Python Policy was to make switching the default Python relatively painless... it just requires releasing new wrapper packages that indicate which python is the default. I'm not a developer, just an outside wanker, but I suggest upgrading the default python regularly. The dependancies alone should ensure that the upgraded packages sit in unstable (sid) until they are all ready, at which point they will propogate into testing (woody). If the dependancies don't do this properly, then they are wrong, and a bug report or two will hold them back until they are fixed. The longer you hold off upgrading the default, the harder it will be. The policy does not absolutely require the use of wrapper packages, but those who have used them will reap the benefits when upgrading python. If you upgrade the default as fast as python upstream upgrades, then people will stay in upgrade python mode, and packagers will end up taking more care to ensure that their packages can be upgraded painlessly. Also it is much less painful to migrate a package from 2.1 to 2.2 to 2.3 to 2.4 than from 2.1 straight to 2.4. Current stable, woody, is shipping with 2.1 as default. That cannot be undone, it is released, and at the time the decision was made, 2.2 was way too close to the cutting edge for comfort. Worth clarifying at this point; woody also includes python2.2, but it is not the default, where default means packages that depend on python will be using python2.1. Python2.2 can be installed alongside the default python, and packages that require python2.2 can specify this by depending on python2.2. Moreover, we would not recommend that the target audience of Python-in-a-Tie run sid. Sid breaks things occasionally, sometimes badly. Sid tortures small defenseless things for a hobby! If we upgrade the default in unstable to the latest stable upstream python as soon as it is available, testing will always have a complete set of the latest stable python as the default. Just my 2.2c (inc GST). -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
Re: rsync and debian -- summary of issues
On Fri, Apr 12, 2002 at 01:28:01PM +1000, Martin Pool wrote: On 12 Apr 2002, Brian May [EMAIL PROTECTED] wrote: I think some more details is required regarding rproxy. [...] AFAIK, it solves all the problems regarding server load discussed in rsync, doesn't it??? Why did you think that? rproxy addresses a rather different problem to rsync: for example, it transfers only one file at a time, not whole directories. No, rproxy does not have a magic way to do the delta computation in zero time. Compared to rsync, rproxy has the advantage of cleaner code (imho), but the disadvantage that no optimization work has been done. The big problem with rproxy is it's implemented in perl (perl: crypto for algorithms). librsync on the other hand is a nice piece of work and _should_ be used for a re-implementation of rproxy and/or rsync. I have recently got sponsorship to add a python front-end to librsync as an extension to my pysync code, which I should have done by end of next week. After this I will probably do some work on adding rproxy http extensions into something like medusa or twisted. If rproxy includes the signature in a HEAD responce, and supports ranged requests, delta calculation can be moved to the client with no changes to rproxy as follows; 1) client sends HEAD request to get upstream signature. 2) client does reverse-delta calculation. 3) client applies reverse-delta using ranged-requests to fetch required parts from upstream. You touched on this in your page, but not in relation to rproxy. I believe the client-side delta stuff you mentioned was not using rproxy http extensions at all, just adding some sort of cgi that returns signatures for objects on the server. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (Beware helix packages) Re: [CrackMonkey] The right to bare legs
G'day Joey, I'm not subscribed to debian-devel, but wanted to add some comments on this issue after reading the web archives. Because I'm not subscribed, I dunno if my Cc to the list will work, in which case you can forward this to the list as you see fit. IMHO, the entire reason Helix exists as a seperate apt'able source is because debian doesn't have package-pools and testing distribution(s) yet. Untill it does, people like me will only be hurt by moving the helix packages into unstable. Helix is too stable for unstable, and too unstable for stable. As an end user, I use stable because I want stability. However, I also want almost-bleeding-edge of primarily destop stuff (Gnome) because what exists in stable is pretty weak, and all the useful stuff in that area is rapidly developing. I use dselect and apt-get to do my installations and upgrades. If I stick purely with debian, to get the good Gnome stuff I need to add unstable to my sources.list. This means I need to either do a full unstable upgrade, or manualy pick and choose, package by package, what I want upgraded to unstable and what I want to hold back. In the first option, I end up with unstable everything, busting basic system stuff that I can't afford to bust. With the second option, I have the major headache of tracking stable _and_ updating manualy selected parts from unstable, editing sources.list and changing selections each time. By putting debian stable and helix in my sources.list, I get the best of both worlds in a headache free apt-get cronjob; a stable base with the latest-almost-stable desktop. Helix have done a damn good job of making their packages fit nicely onto my stable potato desktop machine. I believe the infamous aalib affair actualy came out of a wishlist bugreport submitted to them by a user; the then frozen potato aalib was too low a version to meet all the helix dependencies. This meant people like me had to pull aalib from unstable before I could install helix. By putting an updated aalib into helix, debian potato users could apt-get helix without that small hickup. It sounds like Helix made their own package rather than grab the one from unstable... probably an un-necisary mistake. Dunno why they did that, maybe so all the helix packages had a helix version number for consistancy? People like me need the helix distribution... as a way of conveniently upgrading our desktop packages to a testing rather than unstable state, while keeping the rest of our system to stable. Package pools would be the easiest way to roll helix into the formal debian distribution and still retain the benefits of treating it like a sepearate apt'able source. A testing distribution would certainly be a step in the right direction, but maybe testing-desktop, testing-webapps, testing-... would be better. Just a few ideas, but these can't happen without package-pools. Migrating to package pools can happen right now... just create the pool area and put any new packages in there that come and simlink to them in unstable. A testing distribution can happen as simlinks to stable, unstable, and pkgpool. As packages get updated, they migrate into the pool area. By the time we release woody, we'll be fully pkg-pooled with no extra load on mirrors. Just my 2c, probably already fully discussed by now :-) -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
