Re: numpy 1.2.1, switching to git?
* Ondrej Certik ond...@certik.cz [2008-12-21 00:08:18 +0100]: As to mercurial Tristan, I don't know if you actually ever used hg-buildpackage, but it is written in Haskell (!) and see my blog post here: I've used it; being written in Haskell isn't something I consider a problem. It works just fine for what I've used it for; but then again, the task it performs is relatively simple, so I could probably get along without it just fine. The main thing that matters to me is using the VCS itself, since I'll be spending a lot more time interacting with the VCS than with some vcs-buildpackage tool. Anyway, besides stating which vcs one likes, this is mostly a debate over a beer in Prague, but well, why not, I just had several of them. Heh. -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital signature
Re: numpy 1.2.1, switching to git?
[Piotr Ożarowski, 2008-12-23 13:37] unfortunately I use Git only outside Debian, so I don't know about issues git-buildpackage might have. I know it doesn't have mergeWithUpstream but it's written in Python, so we can implement this. The problem is (FWIK) that it's better to use Git with upstream sources (with tools like pristine-tar)... anyway, I vote for Git, but I'm open to alternative suggestions. update: I vote for status quo (svn, svn-buildpackage, mergeWithUpstream) for now - at least until all top contributors will have decent internet connection or we'll work out some kind of remote upstream branches schema so that one could choose what to download (and a script to download all repositories (packages) within the team) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
On Fri, Dec 26, 2008 at 12:54 AM, Piotr Ożarowski pi...@debian.org wrote: [Piotr Ożarowski, 2008-12-23 13:37] unfortunately I use Git only outside Debian, so I don't know about issues git-buildpackage might have. I know it doesn't have mergeWithUpstream but it's written in Python, so we can implement this. The problem is (FWIK) that it's better to use Git with upstream sources (with tools like pristine-tar)... anyway, I vote for Git, but I'm open to alternative suggestions. update: I vote for status quo (svn, svn-buildpackage, mergeWithUpstream) for now - at least until all top contributors will have decent internet connection or we'll work out some kind of remote upstream branches schema so that one could choose what to download (and a script to download all repositories (packages) within the team) Agree. We talked with Sandro on IRC, the problem is in a bad internet connection --- it takes ~40min to download 10MB -- then of course every MB matters. For me it takes just couple seconds, so it doesn't really matter if I am downloading tarball+debian dir separately, or together in a git repo. I just assumed that everyone has a decent internet connection these days, and I was wrong. :) Ondrej
Re: numpy 1.2.1, switching to git?
On Thu, Dec 25, 2008 at 15:54, Ondrej Certik ond...@certik.cz wrote:
...
Last reply on this thread, just to recap what Ondrej and me discussed
on irc this evening.
I didn't realize I ain't made clear what's my network situation: I'm
still at 56k, so many of the think you broadband users consider
normal, trivial, or chip, for me they're not. I have to minimize the
stuff I download at home and maximize the effort, and svn
(+downloading the tarball at work, if they are big) allows me to
achieve this balance.
But even if I had an adsl or so, I would say that that git is not the
right choice for our team (but I would have made a lot less problems
migrating to it). I think that, being things are they are now, svn is
the right choice and keep being. What we really need is to migrate a
svn layout-2 repository (one composed by
{trunk,tags,branches,...}/package).
Anyhow, to be short: I count as 1, and we are in democracy; whatever
the team will come up, I'll stick to it eventually changing/reducing
the way I contribute to it.
Cheers and Happy Holidays,
--
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
Ondrej Certik wrote: Agree. We talked with Sandro on IRC, the problem is in a bad internet connection --- it takes ~40min to download 10MB -- then of course every MB matters. For me it takes just couple seconds, so it doesn't really matter if I am downloading tarball+debian dir separately, or together in a git repo. but then if you need the original sources to build a package - it doesn't matter much if you get the tarball or clone a git repository. I just assumed that everyone has a decent internet connection these days, and I was wrong. :) unfortunately not... Cheers, Bernd -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
On Wed, Dec 24, 2008 at 10:35 PM, Sandro Tosi mo...@debian.org wrote: On Wed, Dec 24, 2008 at 00:48, Ondrej Certik ond...@certik.cz wrote: thanks for the points, I reacted to some. so please accept my reply :) Absolutely. :) have you ever tried git-svn to work over your packages actually in the team? Yes, git-svn rocks and I use it regularly, but branching+merging sucks with git-svn, plus you cannot really use it with git-buildpackage, upstream branch and pristine-tar. Also if you reclone it, you have to follow the howto here in order to dcommit back to svn: http://subtlegradient.com/articles/2008/04/22/cloning-a-git-svn-clone Really? for a bunch of file under debian/ you need all of this? or are you talking about upstream code? I think we need to separate the 2 arguments, because the *are* separated: we are packagers, we have to keep track of our team's things; your involvement in upstream development is commendable, but this is something other that debian packaging, so it has to be. Yes, I do use it just with the debian dir, to see what other people have done with the package. However, sometimes the orig.tar.gz cannot be obtained with svn-uscan --- let's say if you are repackaging upstream, or simply if you are packaging a different version than svn-uscan downloads. well, either you're creating a new revision of an already existing package (so apt-get source --tar-only would do) or you should stick to the lastest released tarball, ain't you? There should be strong reason I want to be able to also easily build let's say the new numpy version (1.2.1) together with the one in the Debian archive, e.g. 1.1.1. Because the 1.2.1 requires a bit more work, I cannot yet upload it to Debian. So now we have 2 orig.tarballs already. You are right, that in this case I can get both just with apt-get source or svn-uscan. to not package the latest version but one between the latest and the one in the archive, that could he handled as expection: they are not the regular way to do, so we cannot take them as examples. In fact, svn-uscan downloads the one specified in debian/changelog, so I can get any orig.tarball I need, as long as upstream webpages have it. The problem is that I need an internet connection and upstream needs to have working webpages. With git+upstream branch, I can just clone the repo and go off the internet and I am safe, because I have everything needed to build any version. So it boils down to a question of size, e.g. harddisk and net connection speed/price. One example being the abinit package, where svn-uscan is offering me the highest released version number, however the production version (that should be packaged) is not the highest version available. this seems to be a very corner case Ok. I don't see too difficult: 1 command (whatever you prefer) comparing with the many of vi file + dch + build + lintian loops you do to prepare a package. everything will be in one git repo, Given my slow line, I cannot afford the pain to download every packages source code + debianization; now, to have a full checkout of dpmt/papt repositories, I need to launch the commands during the night. Additionally, doing repositories wide updates will become more painful, so I have to refrain from work on every package but just on mine. That's a good argument and I don't know the answer to it. But are you sure it would be that much bigger? Ondrej, you're a science man :) are you just kidding here? :D Of course it's bigger. A lot bigger. Given you have the whole repository I just asked a question and as a science man, I was curious about the answer. You say Of course it's bigger. A lot bigger.. So that made me think, hmm, let's just try it and see. So I took the last 4 upstream releases of numpy, and imported the orig.tarballs one by one into one git repository, together with the binary-delta (e.g. pristine-tar). version, git size, orig.tar.gz size 1.0.1 1.5M 1.2M 1.1.0 2.2M 1.7M 1.1.1 2.3M 1.6M 1.2.1 2.6M 1.4M So as you can see, the whole repository with all 4 versions is less than twice as big as any orig.tar.gz. I do not consider this a lot bigger. locally, you have the HEAD + all other modifications done in the past, for both the upstream code and the debianization. It's like No, only upstream orig.tar.gz is imported, so we do not care about upstream revisions -- that's not our problem. downloading all the uploaded version of the package in the archive compared with only the latest one. As you can see from my example with numpy above, this doesn't seem to be the case. The amount of downloaded data is *less* than two orig.tar.gz in the numpy case above. Let's take the example of DPMT: the dimension on the svn repo on alioth is 186M while the full checkout I have here is 47M. And that's only for debian/ dir (well, almost, but still). Well, but you need to count the orig.tar.gz that you need to download as well in order to build any
Re: numpy 1.2.1, switching to git?
Le mercredi 24 décembre 2008 à 00:48 +0100, Ondrej Certik a écrit : Imho if we are going to only version the debian dir, then I also don't see such a strong argument for git (or other distributed vcs). Since it will still need to fiddle with upstream tarball and also with debian/patches + quilt. Precisely. TTBOMK no other VCS is as smooth to operate as subversion *for Debian packages*. Only svn-buildpackage can handle correctly the versioning of the debian/ directory alone. The only serious alternative is to make feature branches corresponding to patches and to serialize them on the fly before building. I know Pierre Habouzit has some scripts to do it with git. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: numpy 1.2.1, switching to git?
Josselin Mouette j...@debian.org writes: TTBOMK no other VCS is as smooth to operate as subversion *for Debian packages*. Only svn-buildpackage can handle correctly the versioning of the debian/ directory alone. What mis-handlings of a separate ‘debian/’ directory do you know of in the other ‘$VCS-buildpackage’ tools? I've not experienced any mis-handlings of separately-versioned ‘debian/’ with ‘bzr-buildpackage’, but perhaps you know of flaws that I haven't encountered. -- \ “I stayed up all night playing poker with tarot cards. I got a | `\ full house and four people died.” —Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
On Wed, Dec 24, 2008, Josselin Mouette wrote: Precisely. TTBOMK no other VCS is as smooth to operate as subversion *for Debian packages*. Only svn-buildpackage can handle correctly the versioning of the debian/ directory alone. bzr bd works fine in this mode; did you try it out? -- Loïc Minier -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
On Wed, Dec 24, 2008 at 00:48, Ondrej Certik ond...@certik.cz wrote: thanks for the points, I reacted to some. so please accept my reply :) On Tue, Dec 23, 2008 at 5:02 PM, Sandro Tosi mo...@debian.org wrote: P.S. bzed, POX, isn't it time to move our packaging to git? I'm none of them, but I'll speak anyway :) Buxy almost did my point, I'd like to express me a bit. To do a change into something different we need a reason: what's the reason for moving from svn to git? is it because it's cool? (I hope not ;) ) is it because it has some features missing in svn? maybe, but which ones? something else? Yes, distributed version control system has many features that are missing in svn (=that I am missing in svn), mainly that I can easily fiddle with different approaches and branches locally, that I can easily upload my own branch somewhere for someone else to try. With svn, I need to append a patch to our BTS/mailinglist. have you ever tried git-svn to work over your packages actually in the team? It's DVCS, ok, but how many time did you have to diff or log a package offline? How many time did you have to leave uncommitted changes Actually, all the time. Maybe it's only how I work, but I often look at the history to learn what are the latest changes to see where the package is heading to, what is the style of maintaining, etc. Or simply to remind myself what I did on this package in the past. Really? for a bunch of file under debian/ you need all of this? or are you talking about upstream code? I think we need to separate the 2 arguments, because the *are* separated: we are packagers, we have to keep track of our team's things; your involvement in upstream development is commendable, but this is something other that debian packaging, so it has to be. Moreover, I do not want upstream code in the VCS we use for debianization (I did this error for personal managed pacakges and I do not want to do it again). Let upsteam tracks his own source code like he prefers, we do not need re-tracking it in git/svn/XXX, what we want to do is to keep track of our work, what's in debian/ dir *only*. As I understand, the upstream code in the repo is useful only so that one doesn't have to fiddle with orig.tar.gz. the problem is that I don't see what is the problem of orig.tar.gz: you have to have one to upload the package, it's compressed (so you reduce space occupation), if you're good/lucky (no repackage or so) it's the same bit-by-bit the upstream released (And that assure that nothing weird is happening). However, sometimes the orig.tar.gz cannot be obtained with svn-uscan --- let's say if you are repackaging upstream, or simply if you are packaging a different version than svn-uscan downloads. well, either you're creating a new revision of an already existing package (so apt-get source --tar-only would do) or you should stick to the lastest released tarball, ain't you? There should be strong reason to not package the latest version but one between the latest and the one in the archive, that could he handled as expection: they are not the regular way to do, so we cannot take them as examples. One example being the abinit package, where svn-uscan is offering me the highest released version number, however the production version (that should be packaged) is not the highest version available. this seems to be a very corner case I don't see too difficult: 1 command (whatever you prefer) comparing with the many of vi file + dch + build + lintian loops you do to prepare a package. everything will be in one git repo, Given my slow line, I cannot afford the pain to download every packages source code + debianization; now, to have a full checkout of dpmt/papt repositories, I need to launch the commands during the night. Additionally, doing repositories wide updates will become more painful, so I have to refrain from work on every package but just on mine. That's a good argument and I don't know the answer to it. But are you sure it would be that much bigger? Ondrej, you're a science man :) are you just kidding here? :D Of course it's bigger. A lot bigger. Given you have the whole repository locally, you have the HEAD + all other modifications done in the past, for both the upstream code and the debianization. It's like downloading all the uploaded version of the package in the archive compared with only the latest one. Let's take the example of DPMT: the dimension on the svn repo on alioth is 186M while the full checkout I have here is 47M. And that's only for debian/ dir (well, almost, but still). If you want to test a package, you still need to download the orig.tar.gz plus the debian dir (in svn). (the best thing is to just try this and see) But I can only take the latest tarball and debian/ dir not the whole past: if I want to forge a patch for a package, I don't need and I don't want to know every single bit that compose the history of it, I want his
Re: numpy 1.2.1, switching to git?
Cyril Brulebois wrote: Tristan Seligmann mithra...@mithrandi.net (20/12/2008): My personal preference ordering would probably be: hg, bzr, svn, git git, FD, * +1 :) http://whygitisbetterthanx.com -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
Btw, Emilio did a list of the most active DPMT users, here it is. Some people like pox and piotr are actually the same. And the same list for PAPT: emi...@saturno:~/deb/python-apps$ svn log | egrep ^r[0-9]+ | cut -f2 -d'|' | sed 's/-guest//' | sort | uniq -c | sort -n -r 401 nijel 288 piotr 235 gothicx 159 pochu 76 nslater 69 kumanna 68 rainct 66 gilir 63 certik 52 vdanjean 52 bzed 46 dottedmag 41 stani 39 varun 37 kitterma 36 morph 35 odd_bloke 29 pcc 29 gudjon 28 appaji 25 thomasbl 24 arnau 20 sc 20 andyp 18 jalet 15 gerardo 14 eike 14 ana 13 dfiloni 11 tklauser 10 ryanakca 10 nxvl 10 akumar 8 sez 8 baby 6 catlee 4 osrevolution 4 cody-somerville 2 mithrandi 2 cjsmo 1 nenolod 1 ffm -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
Matthias Klose wrote: I only trust my own comparsion without any date and version numbers. And honestly I don't care about a checkin of the usual 2-5 files taking half a second longer. What annoys me most with git is the steep learning curve and the non-intuitive UI, therefore I do prefer bzr over hg over svn over others. In my opinion git is much more intuitive than any other tool - but you have to climb a bit on the learning curve before you realize it. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
I'd prefer: hg, git, bzr, svn, * but looks like the trend goes to git, which is a good option IMHO. Merry Christmas, Eike pgpHKNQOnhCVA.pgp Description: PGP signature
Re: numpy 1.2.1, switching to git?
On Tue, Dec 23, 2008 at 2:14 PM, Bernd Zeimetz be...@bzed.de wrote: Matthias Klose wrote: I only trust my own comparsion without any date and version numbers. And honestly I don't care about a checkin of the usual 2-5 files taking half a second longer. What annoys me most with git is the steep learning curve and the non-intuitive UI, therefore I do prefer bzr over hg over svn over others. In my opinion git is much more intuitive than any other tool - but you have to climb a bit on the learning curve before you realize it. If you already know hg, the curve is not steep at all (as I said, it took me a day or two to feel like at home). I suspect if you already know bzr well, the curve will not be steep as well. Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
Bernd Zeimetz wrote: Cyril Brulebois wrote: Tristan Seligmann mithra...@mithrandi.net (20/12/2008): My personal preference ordering would probably be: hg, bzr, svn, git git, FD, * +1 :) http://whygitisbetterthanx.com I don't know git, but I want to learn about it.. so It can be a nice oportunity to do it. So +1 for git. -- Marco Rodrigues http://Marco.Tondela.org -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
On Tue, 23 Dec 2008 15:08:03 +0100 Loïc Minier l...@dooz.org wrote: On Mon, Dec 08, 2008, Ondrej Certik wrote: P.S. bzed, POX, isn't it time to move our packaging to git? So that I can just commit such patches in a branch and also so that we don't have to mess with the orig.tar.gz, svn-uscan and other things -- i.e. everything will be in one git repo, so users can just download, hit one command and they have a working package (as opposed to the current scheme, were they need to download svn, then setup some tarball directories, then setup svn-uscan, then execute it and only then they can actually build the package, so it's very annoying for casual users to setup the environment to contribute to the packaging) WARNING bikeshedding VCS discussion spotted! Executive suggestion: we wont be able to use the same VCS for all packages; use whatever the top contributors prefer, not what all contributors to all packages prefer. I'll argue we want something different. We want VCS that will maximize participation. That means both keeping top contributors happpy and keeping it accessible to newcomers. I don't think hg, bzr, or git obviously qualify as accesible. My vote, fwiw, is to stay with svn until we have a documented, accessible workflow with tool support. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
On Tue, Dec 23, 2008 at 02:14:25PM +0100, Bernd Zeimetz wrote: Matthias Klose wrote: I only trust my own comparsion without any date and version numbers. And honestly I don't care about a checkin of the usual 2-5 files taking half a second longer. What annoys me most with git is the steep learning curve and the non-intuitive UI, therefore I do prefer bzr over hg over svn over others. In my opinion git is much more intuitive than any other tool - but you have to climb a bit on the learning curve before you realize it. ... That's not what the word intuitive means. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
On Tue, Dec 23, 2008, Scott Kitterman wrote: I'll argue we want something different. We want VCS that will maximize participation. That means both keeping top contributors happpy and keeping it accessible to newcomers. I don't think hg, bzr, or git obviously qualify as accesible. My vote, fwiw, is to stay with svn until we have a documented, accessible workflow with tool support. Fair point. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
Hi Sandro, thanks for the points, I reacted to some. On Tue, Dec 23, 2008 at 5:02 PM, Sandro Tosi mo...@debian.org wrote: P.S. bzed, POX, isn't it time to move our packaging to git? I'm none of them, but I'll speak anyway :) Buxy almost did my point, I'd like to express me a bit. To do a change into something different we need a reason: what's the reason for moving from svn to git? is it because it's cool? (I hope not ;) ) is it because it has some features missing in svn? maybe, but which ones? something else? Yes, distributed version control system has many features that are missing in svn (=that I am missing in svn), mainly that I can easily fiddle with different approaches and branches locally, that I can easily upload my own branch somewhere for someone else to try. With svn, I need to append a patch to our BTS/mailinglist. It's DVCS, ok, but how many time did you have to diff or log a package offline? How many time did you have to leave uncommitted changes Actually, all the time. Maybe it's only how I work, but I often look at the history to learn what are the latest changes to see where the package is heading to, what is the style of maintaining, etc. Or simply to remind myself what I did on this package in the past. locally while waiting to connect to network for svn up svn co? it Also all the time, the latest example being my very first email in this thread. would be the same for git or svn: you need network to upload a package, and you need network to update/commit/whatever action on the repo. Having a centralized place, to concentrate our work it's a plus, not a minus for us (IMO): why would you distribute it? That's a good point and an argument why we should use one VCS as a team. Moreover, I do not want upstream code in the VCS we use for debianization (I did this error for personal managed pacakges and I do not want to do it again). Let upsteam tracks his own source code like he prefers, we do not need re-tracking it in git/svn/XXX, what we want to do is to keep track of our work, what's in debian/ dir *only*. As I understand, the upstream code in the repo is useful only so that one doesn't have to fiddle with orig.tar.gz. If, for packaging reason, you need to touch the upstream code, then checkout the upstream code in whatever place you prefer, using the same VCS upstream uses, and submit them patches, check differences or what-so-ever, but that has nothing to do with packaging that tool. I agree with this. So that I can just commit such patches in a branch and also so that we don't have to mess with the orig.tar.gz, svn-uscan and other things apt-get source --tar-only src_pkg Ah thanks, I forgot about this. uscan --verbose --repack --rename --destdir=/where/you/keep/tarballs Right, that's almost what my svn-uscan alias does: $ alias svn-uscan alias svn-uscan='uscan --verbose --force-download --rename --destdir=../tarballs' However, sometimes the orig.tar.gz cannot be obtained with svn-uscan --- let's say if you are repackaging upstream, or simply if you are packaging a different version than svn-uscan downloads. One example being the abinit package, where svn-uscan is offering me the highest released version number, however the production version (that should be packaged) is not the highest version available. I don't see too difficult: 1 command (whatever you prefer) comparing with the many of vi file + dch + build + lintian loops you do to prepare a package. everything will be in one git repo, Given my slow line, I cannot afford the pain to download every packages source code + debianization; now, to have a full checkout of dpmt/papt repositories, I need to launch the commands during the night. Additionally, doing repositories wide updates will become more painful, so I have to refrain from work on every package but just on mine. That's a good argument and I don't know the answer to it. But are you sure it would be that much bigger? If you want to test a package, you still need to download the orig.tar.gz plus the debian dir (in svn). (the best thing is to just try this and see) What users are you talking about? those that wants to rebuild a package are experienced used, so they can apt-get source pkg and then debcheckout it or whatever order/way they prefer. A normal used is client of the .deb package installed via apt-get/aptitude/synaptic/dpkg/ I am talking about the user (client in your terminology:), who reports a bug and even suggests a fix, but he doesn't have time to learn how to fiddle with svn-buildpackage+orig.tar.gz. Especially if the fix needs to change some patches in debian/patches. See the howto in the Holger's wiki: http://wiki.debian.org/HolgerLevsen#head-a629792087aba6594e680a74e93b55a9318ba995 it's too dificult I myself don't remember it and I still need to copy the commands from the wiki each time I am fixing some patch in debian/patches. Actually --- when looking at it now, it seems
Re: numpy 1.2.1, switching to git?
Tristan Seligmann mithra...@mithrandi.net (20/12/2008): My personal preference ordering would probably be: hg, bzr, svn, git git, FD, * devotee to the rescue. Mraw, KiBi. signature.asc Description: Digital signature
Re: numpy 1.2.1, switching to git?
Cyril Brulebois k...@debian.org writes: Tristan Seligmann mithra...@mithrandi.net (20/12/2008): My personal preference ordering would probably be: hg, bzr, svn, git git, FD, * bzr, git, hg, FD, svn -- \ “It is difficult to get a man to understand something when his | `\ salary depends upon his not understanding it.” —Upton Sinclair, | _o__) 1935 | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
On Mon, Dec 22, 2008 at 09:04:33AM +1100, Ben Finney wrote: Cyril Brulebois k...@debian.org writes: Tristan Seligmann mithra...@mithrandi.net (20/12/2008): My personal preference ordering would probably be: hg, bzr, svn, git git, bzr, svn I read some git stuff today and think it's superior to the other VCSs I know. Jan signature.asc Description: Digital signature
Re: numpy 1.2.1, switching to git?
On Thu, Dec 18, 2008 at 9:07 PM, Monty Taylor mo...@inaugust.com wrote: /me whinges that switching to bzr for packaging in general would be a much nicer thing overall, since then ubuntu downstream is pretty well bzr... (note: I use bzr for all of my other projects, so I have a vested interest) However... _anything_ is an improvement over svn. Matthias also wrote me offlist, that he either prefers to stay in svn, or use bzr, but not git (if I understood well). The problem with bzr is that it seems to me it is mainly used in Ubuntu, but that's about it. Also compare for example the number of packages in the respective vcs: My personal preference ordering would probably be: hg, bzr, svn, git -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital signature
Re: numpy 1.2.1, switching to git?
Steve Langasek wrote: (that's just my subjective opinion, please don't start a flame war now) It's a rather strongly worded opinion; if you want to avoid flame wars, you might find it helpful to bring specific criticisms to the table instead of just declaring a solution ugly. :) ++ Slinking back into the shadows of debian-python, -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
On Sat, Dec 20, 2008 at 7:49 PM, Steve Langasek vor...@debian.org wrote: On Sat, Dec 20, 2008 at 06:43:19PM +0100, Bernd Zeimetz wrote: Monty Taylor wrote: /me whinges that switching to bzr for packaging in general would be a much nicer thing overall, since then ubuntu downstream is pretty well bzr... unfortunatelt I don't know why they use bzr Because bzr was developed in conjunction with Ubuntu? :) (This might mean Ubuntu is somewhat biased in favor of bzr; OTOH, it also means that bzr developers are responsive to the needs of Ubuntu developers.) as it is really ugly to use Ugly how? (that's just my subjective opinion, please don't start a flame war now) It's a rather strongly worded opinion; if you want to avoid flame wars, you might find it helpful to bring specific criticisms to the table instead of just declaring a solution ugly. :) Well, it's just slow once you get used to git and how fast it is, it really sucks to wait for basic operations like bzr di. See e.g. my comparison here: http://www.selenic.com/pipermail/mercurial/2008-August/021009.html But as Bernd said, let's not start a flamewar about this. But I think it's useful to see what all the debian-python developers think. As I told Matthias offlist, we should only switch to git if most of developers are fine with that. Yeah, but since we are talking about that --- Steve, do you really think that bzr has any future? I know that Ubuntu is using it a lot, and couple other projects (mostly hosted on Launchpad), but that's about it. Git, on the other hand, is used a lot in Debian, and in a lot of other projects. Also you have many places on the internet to store your repository (github, gitorious, git.debian.org, ...). As to mercurial Tristan, I don't know if you actually ever used hg-buildpackage, but it is written in Haskell (!) and see my blog post here: http://ondrejcertik.blogspot.com/2007/10/mercurial-vs-git-for-managing-debian.html it's not really well polished (well, of course, because not a lot of people are using it, compared to git-buildpackage). Anyway, besides stating which vcs one likes, this is mostly a debate over a beer in Prague, but well, why not, I just had several of them. Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
/me whinges that switching to bzr for packaging in general would be a much nicer thing overall, since then ubuntu downstream is pretty well bzr... (note: I use bzr for all of my other projects, so I have a vested interest) However... _anything_ is an improvement over svn. Monty Piotr Ożarowski wrote: [Ondrej Certik, 2008-12-08] P.S. bzed, POX, isn't it time to move our packaging to git? I was planing it for a long time, but never found time to actually do it. If you volunteer to do this, please send a message to PAPT mailing list, wait a week and if no one will complain, go ahead and convert the repository. Then we'll test it for a bit and if it will work fine, we'll do the same with DPMT repo (which has more developers so we'll use hey, it's working perfectly fine in PAPT argument ;). BTW, I'm Piotr or Piotrek outside IRC ;-P -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
Ondrej Certik wrote: On Thu, Dec 18, 2008 at 9:07 PM, Monty Taylor mo...@inaugust.com wrote: /me whinges that switching to bzr for packaging in general would be a much nicer thing overall, since then ubuntu downstream is pretty well bzr... (note: I use bzr for all of my other projects, so I have a vested interest) However... _anything_ is an improvement over svn. Matthias also wrote me offlist, that he either prefers to stay in svn, or use bzr, but not git (if I understood well). git seems to be fairly polarizing - I'm not sure why. :) The problem with bzr is that it seems to me it is mainly used in Ubuntu, but that's about it. Also compare for example the number of packages in the respective vcs: http://bzr.debian.org/ http://git.debian.org/ http://hg.debian.org/ (git seems to me like a clear winner) Well, I don't mind either, I know both hg and git quite well and bzr a little. But I prefer to just use just one vcs for everything, and that is git in my case, as I think it has the biggest momentum now. Seems like a decent enough rationale... I'm pretty-much fine with any of them. This will give me a chance to learn a bit about git. Monty -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
numpy 1.2.1, switching to git?
Hi,
I just uploaded some fixes to numpy 1.1.1, currently in incoming. The
attached patch fixes the packaging so that it compiles with the new
numpy 1.2.1. However, I had to comment out all the documentation
building, as it has changed upstream (and the current Debian packaging
breaks the build).
So if anyone (Kumar?) have time to work on this, it'd be awesome. For
others, if you just need the package, apply the patch and it will
build.
Ondrej
P.S. bzed, POX, isn't it time to move our packaging to git? So that I
can just commit such patches in a branch and also so that we don't
have to mess with the orig.tar.gz, svn-uscan and other things -- i.e.
everything will be in one git repo, so users can just download, hit
one command and they have a working package (as opposed to the current
scheme, were they need to download svn, then setup some tarball
directories, then setup svn-uscan, then execute it and only then they
can actually build the package, so it's very annoying for casual users
to setup the environment to contribute to the packaging)
Index: debian/changelog
===
--- debian/changelog (revision 7087)
+++ debian/changelog (working copy)
@@ -1,3 +1,9 @@
+python-numpy (1:1.2.1-1) unstable; urgency=low
+
+ * New upstream release
+
+ -- Ondrej Certik [EMAIL PROTECTED] Mon, 08 Dec 2008 17:32:37 +0100
+
python-numpy (1:1.1.1-2) unstable; urgency=low
[ Ondrej Certik ]
Index: debian/rules
===
--- debian/rules (revision 7087)
+++ debian/rules (working copy)
@@ -32,8 +32,8 @@
install -d $(CURDIR)/debian/python-numpy/usr/share/doc/python-numpy
cp -r $(DEB_DESTDIR)/usr/lib/python$(cdbs_python_current_version)/site-packages/numpy/doc/* \
$(CURDIR)/debian/python-numpy/usr/share/doc/python-numpy/
- cp $(DEB_DESTDIR)/usr/lib/python$(cdbs_python_current_version)/site-packages/numpy/doc/README.txt \
- $(CURDIR)/debian/python-numpy/usr/share/doc/python-numpy/README.doc.txt
+# cp $(DEB_DESTDIR)/usr/lib/python$(cdbs_python_current_version)/site-packages/numpy/doc/README.txt \
+# $(CURDIR)/debian/python-numpy/usr/share/doc/python-numpy/README.doc.txt
: # Adding links to manpages
mkdir -p debian/python-numpy/usr/share/man/man1
@@ -69,12 +69,12 @@
dh_link usr/share/pyshared/numpy/core/include/numpy usr/include/python$${i}_d/numpy; \
done
-binary-install/python-numpy-doc::
- cp -r $(CURDIR)/numpy/doc/html/* $(CURDIR)/debian/$(cdbs_curpkg)/usr/share/doc/$(cdbs_curpkg)
- mkdir $(CURDIR)/debian/$(cdbs_curpkg)/usr/share/doc/$(cdbs_curpkg)/f2py
- rst2html numpy/f2py/docs/usersguide/index.txt $(CURDIR)/debian/$(cdbs_curpkg)/usr/share/doc/$(cdbs_curpkg)/f2py/index.html
- cp -r $(CURDIR)/numpy/f2py/docs/* $(CURDIR)/debian/$(cdbs_curpkg)/usr/share/doc/$(cdbs_curpkg)/f2py
- chmod -x $(CURDIR)/debian/$(cdbs_curpkg)/usr/share/doc/$(cdbs_curpkg)/f2py/usersguide/setup_example.py
+#binary-install/python-numpy-doc::
+ #cp -r $(CURDIR)/numpy/doc/html/* $(CURDIR)/debian/$(cdbs_curpkg)/usr/share/doc/$(cdbs_curpkg)
+ #mkdir $(CURDIR)/debian/$(cdbs_curpkg)/usr/share/doc/$(cdbs_curpkg)/f2py
+ #rst2html numpy/f2py/docs/usersguide/index.txt $(CURDIR)/debian/$(cdbs_curpkg)/usr/share/doc/$(cdbs_curpkg)/f2py/index.html
+ #cp -r $(CURDIR)/numpy/f2py/docs/* $(CURDIR)/debian/$(cdbs_curpkg)/usr/share/doc/$(cdbs_curpkg)/f2py
+ #chmod -x $(CURDIR)/debian/$(cdbs_curpkg)/usr/share/doc/$(cdbs_curpkg)/f2py/usersguide/setup_example.py
build/python-numpy-dbg::
set -e; \
Re: numpy 1.2.1, switching to git?
On Mon, Dec 08, 2008 at 06:55:10PM +0100, Ondrej Certik wrote: So if anyone (Kumar?) have time to work on this, it'd be awesome. For others, if you just need the package, apply the patch and it will build. Since you pulled me in, I'll have a look some time next week, unless someone else does it earlier. Kumar -- Kumar Appaiah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
