On Mon, Mar 2, 2009 at 7:18 PM, Ben Finney wrote:
> Ondrej Certik writes:
>
>> why is the decision unfair?
>
> You'll have to ask Piotr (the one making the decision, and also the
> one who chose that subject field), not me.
Oops, sorry, my fault. You are right.
Ondrej
--
To UNSUBSCRIBE, emai
On Tue, Mar 3, 2009 at 1:37 AM, Adeodato Simó wrote:
> 3. Git
> ==
>
> Git has shallow clones, created with the --depth option for git-clone.
> This cut-offs the history of the project past a certain point, but the
> result is lacking: mainly, you cannot push your changes back. (You can
> do
Cyril Brulebois writes:
> Piotr Ożarowski (03/03/2009):
> > [Cyril Brulebois, 2009-03-03]
> > > Piotr Ożarowski (02/03/2009):
> > > > [Ben Finney, 2009-03-02]
> > > > > Why does [removal of links created by ‘python-central’] not
> > > > > happen automatically when the package is upgraded from a
On Tue, Mar 03, 2009 at 12:39:48AM +0100, Cyril Brulebois wrote:
> Piotr Ożarowski (03/03/2009):
> > [Cyril Brulebois, 2009-03-03]
> > > Piotr Ożarowski (02/03/2009):
> > > > [Ben Finney, 2009-03-02]
> > > > > Why does this not happen automatically when the package is upgraded
> > > > > from a ve
Ondrej Certik writes:
> why is the decision unfair?
You'll have to ask Piotr (the one making the decision, and also the
one who chose that subject field), not me.
--
\ “Pity the meek, for they shall inherit the earth.” —Donald |
`\ Rober
Piotr Ożarowski (03/03/2009):
> [Cyril Brulebois, 2009-03-03]
> > Piotr Ożarowski (02/03/2009):
> > > [Ben Finney, 2009-03-02]
> > > > Why does this not happen automatically when the package is upgraded
> > > > from a version that uses python-central?
> > >
> > > how can dh_pysupport know that x
Hi
Dne Mon, 2 Mar 2009 22:17:52 +0100
Piotr Ożarowski napsal(a):
> Since nobody is interested in having the tools binary compatible[1]
> (and, to be honest, I cared about opinion of two guys only: Matthias
> voted "no" by not agreeing to use /usr/lib/pyshared and Joss expressed
> his disapproval
[Ondrej Certik, 2009-03-03]
> why is the decision unfair?
because *I* think it's unfair as both tools deserve to be the "chosen
one"
Ondrej: stop reading debian-devel, you see trolls everywhere already ;-P
--
-=[ Piotr Ożarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgpaT3cZ1Nt8P.pgp
De
[Cyril Brulebois, 2009-03-03]
> Piotr Ożarowski (02/03/2009):
> > [Ben Finney, 2009-03-02]
> > > Why does this not happen automatically when the package is upgraded
> > > from a version that uses python-central?
> >
> > how can dh_pysupport know that x versions ago this package was using
> > pyth
Hi Ben,
On Mon, Mar 2, 2009 at 5:43 PM, Ben Finney wrote:
> Piotr Ożarowski writes:
>
>> PS while converting [a package using python-central to use
>> python-support], remember to add to preinst something like these 3
>> lines:
>>
>> | if [ "$1" = upgrade ] && dpkg --compare-versions "$2" lt 1.2
Piotr Ożarowski (02/03/2009):
> [Ben Finney, 2009-03-02]
> > Why does this not happen automatically when the package is upgraded
> > from a version that uses python-central?
>
> how can dh_pysupport know that x versions ago this package was using
> python-central?
I suggest you check “6.6 Detail
On Mon, Mar 02, 2009 at 05:30:57PM -0500, Ondrej Certik wrote:
> On Mon, Mar 2, 2009 at 3:44 PM, Steve Langasek wrote:
> > My rebuttal is that if git is technical superior to bazaar because bazaar
> > has a mechanism to create repositories with only partial history, then
> > bazaar is technically
[Piotr Ożarowski, 2009-03-02]
> [Ben Finney, 2009-03-02]
> > Piotr Ożarowski writes:
> > > PS while converting [a package using python-central to use
> > > python-support], remember to add to preinst something like these 3
> > > lines:
> > >
> > > | if [ "$1" = upgrade ] && dpkg --compare-version
[Ben Finney, 2009-03-02]
> Piotr Ożarowski writes:
> > PS while converting [a package using python-central to use
> > python-support], remember to add to preinst something like these 3
> > lines:
> >
> > | if [ "$1" = upgrade ] && dpkg --compare-versions "$2" lt 1.2.3-4; then
> > | pycentral pk
Piotr Ożarowski writes:
> PS while converting [a package using python-central to use
> python-support], remember to add to preinst something like these 3
> lines:
>
> | if [ "$1" = upgrade ] && dpkg --compare-versions "$2" lt 1.2.3-4; then
> | pycentral pkgremove python-foo
> | fi
Why does
Hi Adeodato,
On Mon, Mar 2, 2009 at 11:37 AM, Adeodato Simó wrote:
> * Ondrej Certik [Mon, 02 Mar 2009 11:07:25 -0500]:
>
>> >> I have never used stacked branches, but are you sure you can only
>> >> branch the repository data related to a subset of the working tree
>> >> only ? My understanding
On Mon, Mar 2, 2009 at 4:17 PM, Piotr Ożarowski wrote:
> [Piotr Ożarowski, 2009-02-18]
>> [...] it's time however to decide which one will be my
>> winner - I'll decide that in next weeks (maybe months, but it
>> will happen sooner than later
>
> Since nobody is interested in having the tools bina
On Mon, Mar 2, 2009 at 11:27 AM, Tristan Seligmann
wrote:
> * Ondrej Certik [2009-03-02 11:07:25 -0500]:
>
>> > If you don't want the project history, then you can use lightweight
>> > checkouts, which are essentially equivalent to SVN checkouts (you get a
>> > local working copy, but no local br
Steve Langasek (02/03/2009):
> My rebuttal is that if git is technical superior to bazaar because
> bazaar has a mechanism to create repositories with only partial
> history, then bazaar is technically superior to git because git has
> rebasing as a first-class feature.
Oh my HEAD, it hurts.
Mra
[Piotr Ożarowski, 2009-02-18]
> [...] it's time however to decide which one will be my
> winner - I'll decide that in next weeks (maybe months, but it
> will happen sooner than later
Since nobody is interested in having the tools binary compatible[1]
(and, to be honest, I cared about opinion of tw
On Mon, Mar 02, 2009 at 12:47:45PM -0500, Guy Hulbert wrote:
> On Mon, 2009-02-03 at 17:37 +0100, Adeodato Simó wrote:
> > As far as I know, Git doesn't have a mechanism to create full-fledged
> > repositories with only part of the history, referencing other remote
> > repositories for missing data
OoO Pendant le repas du lundi 02 mars 2009, vers 19:57, je disais:
> Which can be shorten to:
> ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
> common-install-indep::
> PYTHONPATH='debian/$(cdbs_curpkg)/$(cdbs_python_support_path)/' \
> python tests/runner.py
> endif
Whi
OoO Pendant le repas du lundi 02 mars 2009, vers 19:44, je disais:
> I use this snippet then (with cdbs):
> ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
> common-install-indep::
> PYTHONPATH='debian/$(cdbs_curpkg)/$(cdbs_python_support_path)/' \
> python tests/runner.py
OoO Vers la fin de l'après-midi du lundi 02 mars 2009, vers 16:21,
Josselin Mouette disait :
>> I ask this because I have many packages that use unittests after the
>> build. I add /var/lib/python-support to PYTHONPATH and launch those
>> tests. Because the path has changed, this d
OoO Vers la fin de l'après-midi du lundi 02 mars 2009, vers 16:21,
Josselin Mouette disait :
>> I ask this because I have many packages that use unittests after the
>> build. I add /var/lib/python-support to PYTHONPATH and launch those
>> tests. Because the path has changed, this d
* Guy Hulbert [Mon, 02 Mar 2009 12:47:45 -0500]:
> On Mon, 2009-02-03 at 17:37 +0100, Adeodato Simó wrote:
> > As far as I know, Git doesn't have a mechanism to create full-fledged
> > repositories with only part of the history, referencing other remote
> > repositories for missing data. With my G
On Mon, 2009-02-03 at 17:37 +0100, Adeodato Simó wrote:
> As far as I know, Git doesn't have a mechanism to create full-fledged
> repositories with only part of the history, referencing other remote
> repositories for missing data. With my Git user hat on, this is clearly
> a technically inferiorit
* Ondrej Certik [Mon, 02 Mar 2009 11:07:25 -0500]:
> >> I have never used stacked branches, but are you sure you can only
> >> branch the repository data related to a subset of the working tree
> >> only ? My understanding is that bzr stacked branches are useful to
> >> avoid downloading the whole
* Ondrej Certik [2009-03-02 11:07:25 -0500]:
> > If you don't want the project history, then you can use lightweight
> > checkouts, which are essentially equivalent to SVN checkouts (you get a
> > local working copy, but no local branch or repository).
>
> Ah, so you basically only get the local
* Josselin Mouette [2009-03-02 16:21:20 +0100]:
> Le lundi 02 mars 2009 à 15:48 +0100, Vincent Bernat a écrit :
> > I ask this because I have many packages that use unittests after the
> > build. I add /var/lib/python-support to PYTHONPATH and launch those
> > tests. Because the path has
On Sun, Mar 1, 2009 at 4:14 PM, Tristan Seligmann
wrote:
> * David Cournapeau [2009-02-28 20:22:46 +0900]:
>
>> I have never used stacked branches, but are you sure you can only
>> branch the repository data related to a subset of the working tree
>> only ? My understanding is that bzr stacked br
Le lundi 02 mars 2009 à 15:48 +0100, Vincent Bernat a écrit :
> I ask this because I have many packages that use unittests after the
> build. I add /var/lib/python-support to PYTHONPATH and launch those
> tests. Because the path has changed, this does not work any more.
>
> You suggest to
OoO En cette matinée pluvieuse du lundi 23 février 2009, vers 10:12,
Josselin Mouette disait :
>> Do we need to upload a new version when there is a fix needed? In this
>> case, I suppose we should use python-support in unstable instead of the
>> one in experimental?
> Yes, it is possible
33 matches
Mail list logo
