Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Josselin Mouette]

Le dimanche 27 août 2006 à 19:12 +0200, Adeodato Simó a écrit :
> bzrtools > 0.9 does not put files under /usr/lib/python2.4, since it
> uses python-support; and its maintainer scripts for < 0.9 did not
> bytecompile the modules, so the most plausible explanation for .pyc
> files in /usr/lib/python2.4 is having run bzr 0.8 as root.
> 
> To debian-python: this is presumably a bug in bzrtools?

This is a bug in the former version, since it should have cleaned up
those .pyc files at prerm time.

However it can now only be fixed with a workaround in the new version,
e.g. by removing
the /usr/lib/python2.X/site-packages/bzrlib/plugins/bzrtools
directories.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Raphael Hertzog]

On Mon, 28 Aug 2006, Adeodato Simó wrote:
> * Brian May [Mon, 28 Aug 2006 13:22:55 +1000]:
> 
> > Adeodate> Also, do you remember having root
> > Adeodato> bzr as root?
> 
> > Huh?
> 
> Sorry, that should have read: "do you remember having *run* bzr as root".
> It's the most likely cause for those .pyc files to be there, since
> bzrtools did not.

What helper tool did you to use to byte-compules modules before
python-support?  (dh_python v1, python-central, nothing)  

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Brian May]

> "Adeodato" == Adeodato  <"=?utf-8?B?U2ltw7M=?=" <[EMAIL PROTECTED]>> 
> writes:

Adeodato> Sorry, that should have read: "do you remember having
Adeodato> *run* bzr as root".  It's the most likely cause for
Adeodato> those .pyc files to be there, since bzrtools did not.

No - I don't recall running bzr as root, nor have I had any reason to
do so.

This doesn't mean I didn't do it accidently, but I don't think so.
-- 
Brian May <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Adeodato Simó]

* Brian May [Mon, 28 Aug 2006 13:22:55 +1000]:

> Adeodate> Also, do you remember having root
> Adeodato> bzr as root?

> Huh?

Sorry, that should have read: "do you remember having *run* bzr as root".
It's the most likely cause for those .pyc files to be there, since
bzrtools did not.

Thanks,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
The total accumulated knowledge of all the men that ever walked the Earth
on the topic of women can fit in the period at the end of this sentence.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Brian May]

> "Adeodato" == Adeodato  <"=?utf-8?B?U2ltw7M=?=" <[EMAIL PROTECTED]>> 
> writes:

Adeodato> Hm. I'd say that you have .pyc files left in:

Adeodato>
Adeodato> /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools

Adeodato> Can you check, please?

Yes, see below.

Adeodate> Also, do you remember having root
Adeodato> bzr as root?

Huh?

Adeodato> bzrtools > 0.9 does not put files under
Adeodato> /usr/lib/python2.4, since it uses python-support; and
Adeodato> its maintainer scripts for < 0.9 did not bytecompile the
Adeodato> modules, so the most plausible explanation for .pyc
Adeodato> files in /usr/lib/python2.4 is having run bzr 0.8 as
Adeodato> root.

Adeodato> To debian-python: this is presumably a bug in bzrtools?

[EMAIL PROTECTED]:~$ ls -l 
/usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools
total 288
-rw-r--r-- 1 root root 31767 2006-07-16 18:58 baz_import.py.bak
-rw-r--r-- 1 root root 29959 2006-08-12 12:08 baz_import.pyc
-rw-r--r-- 1 root root   830 2006-08-12 12:08 branches.pyc
-rw-r--r-- 1 root root  2198 2006-08-12 12:08 branchhistory.pyc
-rw-r--r-- 1 root root  4167 2006-08-12 12:08 branch_mark.pyc
-rw-r--r-- 1 root root 13906 2006-08-12 12:08 bzrtools.pyc
-rw-r--r-- 1 root root  1232 2006-08-12 12:08 cbranch.pyc
-rw-r--r-- 1 root root  4167 2006-08-12 12:08 clean_tree.pyc
-rw-r--r-- 1 root root  8687 2006-08-12 12:08 dotgraph.pyc
-rw-r--r-- 1 root root  1637 2006-08-12 12:08 errors.pyc
-rw-r--r-- 1 root root  4235 2006-08-12 12:08 fai.pyc
-rw-r--r-- 1 root root  2275 2006-08-12 12:08 fetch_ghosts.pyc
-rw-r--r-- 1 root root  8827 2006-08-12 12:08 graph.pyc
-rw-r--r-- 1 root root  5466 2006-08-12 12:08 hunk_selector.pyc
-rw-r--r-- 1 root root 16502 2006-07-16 18:52 __init__.py.bak
-rw-r--r-- 1 root root 18867 2006-08-12 12:08 __init__.pyc
-rw-r--r-- 1 root root 20311 2006-08-12 12:08 patches.pyc
-rw-r--r-- 1 root root  7321 2006-08-12 12:08 patch.pyc
-rw-r--r-- 1 root root  2573 2006-08-12 12:08 patchsource.pyc
-rw-r--r-- 1 root root  1460 2006-08-12 12:08 progress.pyc
-rw-r--r-- 1 root root  1545 2006-08-12 12:08 rspush.pyc
-rw-r--r-- 1 root root   626 2006-08-12 12:08 setup.pyc
-rw-r--r-- 1 root root  9907 2006-08-12 12:08 shelf.pyc
-rw-r--r-- 1 root root 10210 2006-08-12 12:08 shell.pyc
-rw-r--r-- 1 root root  3846 2006-08-12 12:08 switch.pyc
-rw-r--r-- 1 root root  1822 2006-08-12 12:08 terminal.pyc
-rw-r--r-- 1 root root  1367 2006-08-12 12:08 test.pyc
-rw-r--r-- 1 root root  5083 2006-08-12 12:08 userinteractor.pyc
-rw-r--r-- 1 root root  3674 2006-08-12 12:08 zap.pyc

[EMAIL PROTECTED]:~$ dpkg -S 
/usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools
bzrtools: /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools

[EMAIL PROTECTED]:~$ dpkg -L bzrtools
/.
/usr
/usr/lib
/usr/lib/python2.4
/usr/lib/python2.4/site-packages
/usr/lib/python2.4/site-packages/bzrlib
/usr/lib/python2.4/site-packages/bzrlib/plugins
/usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools
/usr/share
[...]

Not sure what those *.bak files are, but I suspect that was some
hackish debugging I did for a previous problem.

I would speculate that upgrading the package didn't result in the
compiled files being deleted.

[EMAIL PROTECTED]:~$ dpkg -l bzrtools
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version  Description
+++---
ii  bzrtools 0.9.0-1  Collection of 
tools for bzr

-- 
Brian May <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Adeodato Simó]

Version: 0.9-1

* Brian May [Sun, 27 Aug 2006 17:43:24 +1000]:

> Robert> Could you please run 'bzr upgrade' while using bzr
> Robert> 0.9rc1. If my guess at your situation is right this will
> Robert> take a while to run, but correct your performance issues.

> >> Did I do something wrong?

> >> [EMAIL PROTECTED]:~/bzr/diary-data$ bzr upgrade
> >> 
> /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools/__init__.py:21:
> >> DeprecationWarning: Modifying DEFAULT_IGNORE was deprecated in
> >> version 0.9. Consider using
> >> bzrlib.ignores.add_unique_user_ignores o r
> >> bzrlib.ignores.add_runtime_ignores
> >> 
> /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools/__init__.py:22:
> >> DeprecationWarning: Modifying DEFAULT_IGNORE was deprecated in
> >> version 0.9. Consider using
> >> bzrlib.ignores.add_unique_user_ignores o r
> >> bzrlib.ignores.add_runtime_ignores bzr: ERROR: The branch
> >> format Bazaar-NG meta directory, format 1 is already at the
> >> most recent format.

> Adeodato> No. You just need to upgrade your bzrtool package to 0.9
> Adeodato> as well.

> I had 0.9 installed already when doing this:

> ii  bzrtools0.9.0-1 Collection of tools for bzr

Hm. I'd say that you have .pyc files left in:

  /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools

Can you check, please? Also, do you remember having root bzr as root?

bzrtools > 0.9 does not put files under /usr/lib/python2.4, since it
uses python-support; and its maintainer scripts for < 0.9 did not
bytecompile the modules, so the most plausible explanation for .pyc
files in /usr/lib/python2.4 is having run bzr 0.8 as root.

To debian-python: this is presumably a bug in bzrtools?

> So what is going wrong?

> >> Anyway, I tried the revert operation again with 0.9-2. Memory
> >> usage was still high (205meg at one point), but bounded - much
> >> better. The operation successfully completed this time.

> Adeodato> Sounds acceptable to close ##380412, then?

> Yes, sounds good to me.

Done, thanks.

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Listening to: Los Caramelos - Cherry


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Brian May]

> "Adeodato" == Adeodato  <"=?utf-8?B?U2ltw7M=?=" <[EMAIL PROTECTED]>> 
> writes:

Robert> Could you please run 'bzr upgrade' while using bzr
Robert> 0.9rc1. If my guess at your situation is right this will
Robert> take a while to run, but correct your performance issues.

>> Did I do something wrong?

>> [EMAIL PROTECTED]:~/bzr/diary-data$ bzr upgrade
>> /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools/__init__.py:21:
>> DeprecationWarning: Modifying DEFAULT_IGNORE was deprecated in
>> version 0.9. Consider using
>> bzrlib.ignores.add_unique_user_ignores o r
>> bzrlib.ignores.add_runtime_ignores
>> /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools/__init__.py:22:
>> DeprecationWarning: Modifying DEFAULT_IGNORE was deprecated in
>> version 0.9. Consider using
>> bzrlib.ignores.add_unique_user_ignores o r
>> bzrlib.ignores.add_runtime_ignores bzr: ERROR: The branch
>> format Bazaar-NG meta directory, format 1 is already at the
>> most recent format.

Adeodato> No. You just need to upgrade your bzrtool package to 0.9
Adeodato> as well.

I had 0.9 installed already when doing this:

ii  bzrtools0.9.0-1 Collection of tools for bzr

So what is going wrong?

>> Anyway, I tried the revert operation again with 0.9-2. Memory
>> usage was still high (205meg at one point), but bounded - much
>> better. The operation successfully completed this time.

Adeodato> Sounds acceptable to close ##380412, then?

Yes, sounds good to me.
-- 
Brian May <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Adeodato Simó]

* Brian May [Sun, 27 Aug 2006 13:53:01 +1000]:

> > "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:

> Robert> On Sun, 2006-08-06 at 12:01 +1000, Brian May wrote:
> >> Curiously though, the problems continue even after the archive
> >> appears to be converted successfully - if I do a diff
> >> operation, it reports all files as deleted, but if I try to
> >> revert it, it slows to a grinding halt.

> Robert> Could you please run 'bzr upgrade' while using bzr
> Robert> 0.9rc1. If my guess at your situation is right this will
> Robert> take a while to run, but correct your performance issues.

> Did I do something wrong?

> [EMAIL PROTECTED]:~/bzr/diary-data$ bzr upgrade
> /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools/__init__.py:21: 
> DeprecationWarning: Modifying
>  DEFAULT_IGNORE was deprecated in version 0.9. Consider using 
> bzrlib.ignores.add_unique_user_ignores o
> r bzrlib.ignores.add_runtime_ignores
> /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools/__init__.py:22: 
> DeprecationWarning: Modifying
>  DEFAULT_IGNORE was deprecated in version 0.9. Consider using 
> bzrlib.ignores.add_unique_user_ignores o
> r bzrlib.ignores.add_runtime_ignores
> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already 
> at the most recent format.

No. You just need to upgrade your bzrtool package to 0.9 as well.

> Anyway, I tried the revert operation again with 0.9-2. Memory usage
> was still high (205meg at one point), but bounded - much better. The
> operation successfully completed this time.

Sounds acceptable to close ##380412, then?

Thanks,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
One way to make your old car run better is to look up the price of a new model.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Brian May]

> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:

Robert> On Sun, 2006-08-06 at 12:01 +1000, Brian May wrote:
>> Curiously though, the problems continue even after the archive
>> appears to be converted successfully - if I do a diff
>> operation, it reports all files as deleted, but if I try to
>> revert it, it slows to a grinding halt.

Robert> Could you please run 'bzr upgrade' while using bzr
Robert> 0.9rc1. If my guess at your situation is right this will
Robert> take a while to run, but correct your performance issues.

Did I do something wrong?

[EMAIL PROTECTED]:~/bzr/diary-data$ bzr upgrade
/usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools/__init__.py:21: 
DeprecationWarning: Modifying
 DEFAULT_IGNORE was deprecated in version 0.9. Consider using 
bzrlib.ignores.add_unique_user_ignores o
r bzrlib.ignores.add_runtime_ignores
/usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools/__init__.py:22: 
DeprecationWarning: Modifying
 DEFAULT_IGNORE was deprecated in version 0.9. Consider using 
bzrlib.ignores.add_unique_user_ignores o
r bzrlib.ignores.add_runtime_ignores
bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at 
the most recent format.

Anyway, I tried the revert operation again with 0.9-2. Memory usage
was still high (205meg at one point), but bounded - much better. The
operation successfully completed this time.
-- 
Brian May <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[David Nusinow]

On Mon, Aug 07, 2006 at 10:28:58PM +0200, Raphael Hertzog wrote:
> On Wed, 02 Aug 2006, David Nusinow wrote:
> > On Wed, Aug 02, 2006 at 11:56:44PM +0200, Adeodato Simó wrote:
> > > * David Nusinow [Wed, 02 Aug 2006 17:37:23 +]:
> > > 
> > > > (I'm seriously
> > > > interested in setting up git.debian.org for XSF work, for example*),
> > > 
> > > > * If anyone else is interested in this, contact me and we'll talk
> > > 
> > > There is _something_ in costa:/srv/git.debian.org/git already.
> > 
> > Interesting... any idea if the git server is working? Also, if its
> > permissions are hooked in the rest of alioth like svn? If so, I'll be a
> > very happy boy.
> 
> I've installed git-core (IIRC) on request of maks. AFAICT, it's enough to
> use git rsync method apparently. 
> 
> And yes permissions on costa are always hooked to alioth.

Hot damn! Thank you! We'll be investigating moving the Xorg packages to
alioth and git in the coming weeks once we've stabilized for Etch.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Robert Collins]

On Sat, 2006-08-12 at 15:59 +1000, Brian May wrote:
> > "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
> 
> Robert> On Sun, 2006-08-06 at 12:01 +1000, Brian May wrote:
> >>  Curiously though, the problems continue even after the archive
> >> appears to be converted successfully - if I do a diff
> >> operation, it reports all files as deleted, but if I try to
> >> revert it, it slows to a grinding halt.
> 
> Robert> Could you please run 'bzr upgrade' while using bzr
> Robert> 0.9rc1. If my guess at your situation is right this will
> Robert> take a while to run, but correct your performance issues.
> 
> Are there any Debian packages of 0.9rc1 available?

0.9 has been released, I believe 'dato is working on an upload now.

Cheers,
Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: Successful and unsuccessful Debian development tools

[Raphael Hertzog]

On Wed, 02 Aug 2006, David Nusinow wrote:
> On Wed, Aug 02, 2006 at 11:56:44PM +0200, Adeodato Simó wrote:
> > * David Nusinow [Wed, 02 Aug 2006 17:37:23 +]:
> > 
> > > (I'm seriously
> > > interested in setting up git.debian.org for XSF work, for example*),
> > 
> > > * If anyone else is interested in this, contact me and we'll talk
> > 
> > There is _something_ in costa:/srv/git.debian.org/git already.
> 
> Interesting... any idea if the git server is working? Also, if its
> permissions are hooked in the rest of alioth like svn? If so, I'll be a
> very happy boy.

I've installed git-core (IIRC) on request of maks. AFAICT, it's enough to
use git rsync method apparently. 

And yes permissions on costa are always hooked to alioth.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Lars Wirzenius]

la, 2006-08-12 kello 15:59 +1000, Brian May kirjoitti:
> Are there any Debian packages of 0.9rc1 available?

http://packages.debian.org/unstable/devel/bzr says 0.9~rc1-1.

(Lookup time: about ten seconds. :)

-- 
On a clear disk, you seek forever.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Brian May]

> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:

Robert> On Sun, 2006-08-06 at 12:01 +1000, Brian May wrote:
>>  Curiously though, the problems continue even after the archive
>> appears to be converted successfully - if I do a diff
>> operation, it reports all files as deleted, but if I try to
>> revert it, it slows to a grinding halt.

Robert> Could you please run 'bzr upgrade' while using bzr
Robert> 0.9rc1. If my guess at your situation is right this will
Robert> take a while to run, but correct your performance issues.

Are there any Debian packages of 0.9rc1 available?
-- 
Brian May <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[Goswin von Brederlow]

Toni Mueller <[EMAIL PROTECTED]> writes:

> Hi,
>
> On Mon, 31.07.2006 at 14:54:50 +0200, Goswin von Brederlow <[EMAIL 
> PROTECTED]> wrote:
>> With cdbs as negative and alitoh/svn as positive?
>
> what are your problems with CDBS?
>
>
> Best,
> --Toni++

Lets just have a short comment. For more search the mailinglist or
google.

CDBS has pushed out all the logic behind building a package into
external files to the extend that you can have a 2 line rules file.
On the other hand you can have a lot more to modify the behaviour of
cdbs.

That amount of abstraction is extremly hard to follow if you don't use
cdbs yourself. Debuging the build process becomes nearly impossible
without first understanding all of cdbs. The learning curve is way to
steep.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[Christian Aichinger]

On Tue, Aug 08, 2006 at 11:02:15AM +0200, Toni Mueller wrote:
> On Mon, 07.08.2006 at 12:52:26 +0100, martin f krafft <[EMAIL PROTECTED]> 
> wrote:
> > also sprach Toni Mueller <[EMAIL PROTECTED]> [2006.08.07.1126 +0100]:
> > > what are your problems with CDBS?
> > http://lists.debian.org/debian-devel/2006/06/msg00451.html
> > http://lists.debian.org/debian-devel/2006/06/msg00467.html
> 
> hmmm, for me, CDBS feels very much like BSD's ports system.
> 
> That notwithstanding, it could be enhanced (what couldn't?).

The problem some people see with CDBS is that you can't really see
how a package will build from looking at debian/rules, instead you
have to look it up in /usr/share/cdbs.

That's not much of a problem with your own packages usually, but it
can be unnerving if you're doing RC bugsquashing, looking at 10
packages per day, trying to figure out why something doesn't build.

However pushing out as much build logic as possible from
debian/rules is a central concept of CDBS, so this unlikely to ever
change.

Cheers,
Christian Aichinger

PS: We've already had this discussion, so let's try to skip the
flamewar this time, can we?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[Toni Mueller]

Hi,

On Mon, 07.08.2006 at 12:52:26 +0100, martin f krafft <[EMAIL PROTECTED]> wrote:
> also sprach Toni Mueller <[EMAIL PROTECTED]> [2006.08.07.1126 +0100]:
> > what are your problems with CDBS?
> http://lists.debian.org/debian-devel/2006/06/msg00451.html
> http://lists.debian.org/debian-devel/2006/06/msg00467.html

hmmm, for me, CDBS feels very much like BSD's ports system.

That notwithstanding, it could be enhanced (what couldn't?).


Best,
--Toni++


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[martin f krafft]

also sprach Toni Mueller <[EMAIL PROTECTED]> [2006.08.07.1126 +0100]:
> what are your problems with CDBS?

http://lists.debian.org/debian-devel/2006/06/msg00451.html
http://lists.debian.org/debian-devel/2006/06/msg00467.html

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"the stripes on the highway began to unreel beneath her in a dizzying
 blur as if all those grains of sand had lost their bearings and were
 falling all over each other just trying to get out of the way to make
 room for the next moment, or instant, or tick of the clock"
-- mc 900 ft jesus (http://www.theendoftheworld.org/900/spider1.shtml)


signature.asc
Description: Digital signature (GPG/PGP)

Re: Successful and unsuccessful Debian development tools

[Toni Mueller]

Hi,

On Mon, 31.07.2006 at 14:54:50 +0200, Goswin von Brederlow <[EMAIL PROTECTED]> 
wrote:
> With cdbs as negative and alitoh/svn as positive?

what are your problems with CDBS?


Best,
--Toni++


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Robert Collins]

On Sun, 2006-08-06 at 12:01 +1000, Brian May wrote:
> 
> Curiously though, the problems continue even after the archive appears
> to be converted successfully - if I do a diff operation, it reports
> all files as deleted, but if I try to revert it, it slows to a
> grinding halt. 

Could you please run 'bzr upgrade' while using bzr 0.9rc1. If my guess
at your situation is right this will take a while to run, but correct
your performance issues.

-Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Brian May]

> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:

Robert> Its likely to be a different bug - the conversion approach
Robert> used for svn/baz is very different. That said, conversion
Robert> from $any system is going to use more memory than native
Robert> bzr operations, simply because of the overhead of having
Robert> two data structures in memory at once. If you do a
Robert> conversion from baz though, once converted you should have
Robert> no troubles.

Robert> Also, please do file bugs on the conversion logic if it
Robert> fails to operate for you.

Already done so - the Debian bug report I quoted.

Curiously though, the problems continue even after the archive appears
to be converted successfully - if I do a diff operation, it reports
all files as deleted, but if I try to revert it, it slows to a
grinding halt.
-- 
Brian May <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Robert Collins]

On Sat, 2006-08-05 at 10:58 +1000, Brian May wrote:
> > "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
> 
> Robert> Are you doing conversions from SVN? Current bzr uses 20MB
> Robert> of ram to do a native branch operation in similar
> Robert> circumstances. (bug report gets fixed, new at 11 :)).
> 
> No, this was a conversion from baz. Might be the same bug though,
> hopefully.

Its likely to be a different bug - the conversion approach used for
svn/baz is very different. That said, conversion from $any system is
going to use more memory than native bzr operations, simply because of
the overhead of having two data structures in memory at once. If you do
a conversion from baz though, once converted you should have no
troubles.

Also, please do file bugs on the conversion logic if it fails to operate
for you.

Cheers,
Rob

-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Brian May]

> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:

Robert> Are you doing conversions from SVN? Current bzr uses 20MB
Robert> of ram to do a native branch operation in similar
Robert> circumstances. (bug report gets fixed, new at 11 :)).

No, this was a conversion from baz. Might be the same bug though,
hopefully.
-- 
Brian May <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Building in chroots hides bugs? (was: Successful and unsuccessful Debian development tools)

[Bernhard R. Link]

* martin f krafft <[EMAIL PROTECTED]> [060801 18:17]:
> also sprach Bernhard R. Link <[EMAIL PROTECTED]> [2006.08.01.1701 +0100]:
> > Missing $(DESTDIR)s in Makefiles are an example. Especially when the
> > install part was DESTDIRified, but the test before if the file is
> > already there (as make install does not want to overwrite a config file)
> > was forgotten.
> > This leads to a corrupt package when build on a system where the package
> > is already installed, i.e. is hidden away in any clean chroot.
> 
> This makes zero sense to me.

Consider (in Makefile.in):

install: [...]
[...]
-if [ ! -f $(sysconfdir)/Bla ]; then \
  $(INSTALL) -m644 $(srcdir)/Bla $(DESTDIR)$(sysconfdir)/Bla \
fi

This is clearly a bug, most likely someone added DESTDIR later and
forgot it in the test. But unless that package build depends on itself,
you will never find it when building in a clean chroot.

Hochachtungsvoll,
  Bernhard R. Link


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Robert Collins]

On Fri, 2006-08-04 at 09:56 +1000, Brian May wrote:


> For documentation on checkouts and bound branches, see
> 
> http://bazaar-vcs.org/CheckoutTutorial
> 
> http://bazaar-vcs.org/BzrUsingBoundBranches
> 
> However, I am not convinced the following paragraph in the first
> page is correct:
> 
> "Getting a checkout is generally faster than making a copy of a
> branch. The catch though is that whenever the checkout needs to look
> at the RCS data it will do so by accessing the branch. This holds true
> even if the branch is on some distant network that you accessed over
> the internet."

Yes, thats bogus. Getting a heavyweight checkout is identical to getting
a new branch. Getting a lightweight one *may* be cheaper, depending on
how much history is needed to reconstruct file versions.

> To me, this sounds like it might be talking about a "lightweight
> checkout", as I believe a checkout is a complete copy of the branch,
> and network access is only required for commits or updates. "Bound
> branches in bzr take the place of remote 'checkouts' in systems like
> CVS or SVN and we refer to them as 'checkouts'. (bzr also supports
> "lightweight checkouts", which are like local checkouts, and aren't
> branches at all.)"
>
> Can anyone confirm/deny?

A checkout --lightweight over the net is currently not a good thing to
do. When the smart server is released, that will be about the same
performance as traditional client-server vcs's like CVS or SVN. 

> 
> My central dislike of bzr is bugs like:
> 
> http://bugs.debian.org/380412
> https://launchpad.net/products/bzr/+bug/54253
> 
> ...which unfortunately makes it unusable for some of my applications.

Are you doing conversions from SVN? Current bzr uses 20MB of ram to do a
native branch operation in similar circumstances. (bug report gets
fixed, new at 11 :)). 

0.9RC1 is out, and 0.9 will be out Monday/Tuesdau. As soon as that lands
in debian the bug should be closed. 

Rob

-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Brian May]

> "Adeodato" == Adeodato  <"=?utf-8?B?U2ltw7M=?=" <[EMAIL PROTECTED]>> 
> writes:

Adeodato> But if you have a set of equal developers, bzr can be
Adeodato> also used in a very similar way to Subversion, where all
Adeodato> commits go to a central repository, and nobody has to
Adeodato> collect them. It's just a matter of setting up a
Adeodato> directory somewhere with the appropriate write
Adeodato> permissions, and say "This is our canonical archive, the
Adeodato> uploader will include what it's in there, nothing more,
Adeodato> nothing less".

For documentation on checkouts and bound branches, see

http://bazaar-vcs.org/CheckoutTutorial

http://bazaar-vcs.org/BzrUsingBoundBranches

However, I am not convinced the following paragraph in the first
page is correct:

"Getting a checkout is generally faster than making a copy of a
branch. The catch though is that whenever the checkout needs to look
at the RCS data it will do so by accessing the branch. This holds true
even if the branch is on some distant network that you accessed over
the internet."

To me, this sounds like it might be talking about a "lightweight
checkout", as I believe a checkout is a complete copy of the branch,
and network access is only required for commits or updates. "Bound
branches in bzr take the place of remote 'checkouts' in systems like
CVS or SVN and we refer to them as 'checkouts'. (bzr also supports
"lightweight checkouts", which are like local checkouts, and aren't
branches at all.)"

Can anyone confirm/deny?


My central dislike of bzr is bugs like:

http://bugs.debian.org/380412
https://launchpad.net/products/bzr/+bug/54253

...which unfortunately makes it unusable for some of my applications.
-- 
Brian May <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Otavio Salvador]

Robert Collins <[EMAIL PROTECTED]> writes:

> On Thu, 2006-08-03 at 08:27 -0300, Otavio Salvador wrote:
>> Robert Collins <[EMAIL PROTECTED]> writes:
>> 
>> > bzr is also working on a high performance server at the moment, which
>> > will operate over either a socketpair - i.e. tunnelling via ssh (which
>> > can still be done without granting shell access), or over plain http via
>> > an apache rewrite rule.
>> 
>> Is it already working? How we can try?
>
> typo - I meant 'bzr developers are also'...
>
> Its partially functional at this point - we have it passing all the
> transport selftests, which means it can be used [by the brave!] as an
> alternative to sftp for read-write access, but it no faster. The
> higher-level semantic operations are coming along nicely - we hope to
> have it in 0.10 due out 4th september.

Great!

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Robert Collins]

On Thu, 2006-08-03 at 08:27 -0300, Otavio Salvador wrote:
> Robert Collins <[EMAIL PROTECTED]> writes:
> 
> > bzr is also working on a high performance server at the moment, which
> > will operate over either a socketpair - i.e. tunnelling via ssh (which
> > can still be done without granting shell access), or over plain http via
> > an apache rewrite rule.
> 
> Is it already working? How we can try?

typo - I meant 'bzr developers are also'...

Its partially functional at this point - we have it passing all the
transport selftests, which means it can be used [by the brave!] as an
alternative to sftp for read-write access, but it no faster. The
higher-level semantic operations are coming along nicely - we hope to
have it in 0.10 due out 4th september.

Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Otavio Salvador]

Robert Collins <[EMAIL PROTECTED]> writes:

> bzr is also working on a high performance server at the moment, which
> will operate over either a socketpair - i.e. tunnelling via ssh (which
> can still be done without granting shell access), or over plain http via
> an apache rewrite rule.

Is it already working? How we can try?

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Robert Collins]

On Wed, 2006-08-02 at 22:29 +0200, Christoph Haas wrote:
> 
> That's in fact an issue that made me feel sceptical about bzr, darcs
> and 
> mercury. All of them require a shell account or some scripting through
> a 
> special mail address to commit changes. And it's not only the recent 
> kernel vulnerability that makes me a happy repository user over
> WebDAV 
> (hoping it's less vulnerable). And it works over a proxy, too.

Well, I dont know darcs well enough to argue there, but neither bzr nor
mercurial require a shell account nor scripting. bzr requires sftp
access *which can be granted without granting shell access*. mercurial
has a http cgi script that can be used to push commits.

bzr is also working on a high performance server at the moment, which
will operate over either a socketpair - i.e. tunnelling via ssh (which
can still be done without granting shell access), or over plain http via
an apache rewrite rule.

HTH,
Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: Successful and unsuccessful Debian development tools

[David Nusinow]

On Wed, Aug 02, 2006 at 11:56:44PM +0200, Adeodato Simó wrote:
> * David Nusinow [Wed, 02 Aug 2006 17:37:23 +]:
> 
> > (I'm seriously
> > interested in setting up git.debian.org for XSF work, for example*),
> 
> > * If anyone else is interested in this, contact me and we'll talk
> 
> There is _something_ in costa:/srv/git.debian.org/git already.

Interesting... any idea if the git server is working? Also, if its
permissions are hooked in the rest of alioth like svn? If so, I'll be a
very happy boy.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[Adeodato Simó]

* David Nusinow [Wed, 02 Aug 2006 17:37:23 +]:

> (I'm seriously
> interested in setting up git.debian.org for XSF work, for example*),

> * If anyone else is interested in this, contact me and we'll talk

There is _something_ in costa:/srv/git.debian.org/git already.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
   Listening to: Polar - The Sea & The Waves


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[David Nusinow]

On Tue, Aug 01, 2006 at 12:44:19PM +0100, martin f krafft wrote:
> also sprach David Nusinow <[EMAIL PROTECTED]> [2006.08.01.0005 +0100]:
> > Subversion, in conjunction with alioth, has risen dramatically in
> > Debian to accomodate team-based maintainance. There are of course
> > plenty of challengers, but subversion seems to beat them all.
> 
> I'd be interested in your thoughts as to why subversion beats them
> all, in your perception.

The idea of it beating the others isn't to say that it's better or worse,
simply more popular. I think this is largely to do with familiarity
(similarity to CVS) and integration in to alioth.

If you look at the major teams in Debian, svn seems to be very high
profile. The XSF, Gnome, KDE, and kernel teams all use svn for example.
That's not to say that the other options aren't great (I'm seriously
interested in setting up git.debian.org for XSF work, for example*), but svn
is very popular.

 - David Nusinow

* If anyone else is interested in this, contact me and we'll talk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[David Nusinow]

On Tue, Aug 01, 2006 at 03:08:06PM +0200, Goswin von Brederlow wrote:
> [EMAIL PROTECTED] (Marco d'Itri) writes:
> 
> > On Aug 01, David Nusinow <[EMAIL PROTECTED]> wrote:
> >
> >> Also, pbuilder and debootstrap are considered absolutely critical for
> >> serious work.
> > That's a bold statement.
> >
> > -- 
> > ciao,
> > Marco
> 
> Never used either one.
> 
> I have cdebootstrap do create chroots, dchroot to use them,
> buildd/sbuild to test compile under true buildd conditions. Why would
> I want something else?
> 
> Debootstrap couldn't even handle dependency resolving a while back.

Meh, the idea was mainly chroot automation tools. Whichever one you pick,
be it sbuild, dchroot, sbuild, or whatever else, those are just the chroot
tools that I tend to use.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Roland Mas]

Adeodato Simó, 2006-08-02 21:20:09 +0200 :

>> >   % bzr push sftp://costa.debian.org/bzr/pkg-xiph/vorbis-tools

[...]

> Ask in #alioth. Note, however, that TTBOMK still does not offer HTTP
> access, so if you want that, better stick to htdocs for a while.
>
> I hope to be able to bribe buxy to provide HTTP access when he comes
> back, though. ;-)

I just enabled HTTP access for bzr:

$ bzr get http://arch.debian.org/bzr/pkg-xiph/vorbis-tools
Branched 22 revision(s).

bzr.debian.org doesn't exist, so I chose arch.d.o instead.

Roland.
-- 
Roland Mas

[...] ou une dent pourrie [...] -- in Variations sur un thème imposé
  -- Signatures à collectionner, série n°2, partie 2/3.

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Christoph Haas]

On Wednesday 02 August 2006 21:44, Otavio Salvador wrote:
> Adeodato Simó <[EMAIL PROTECTED]> writes:
> > * Otavio Salvador [Tue, 01 Aug 2006 15:43:56 -0300]:
> >> Adeodato Simó <[EMAIL PROTECTED]> writes:
> >> > Then each developer can prepare a set of changes offline, do all
> >> > the branching, merging, commiting and uncommiting (gotta love that)
> >> > that they want, and when they're done, do e.g.:
> >> >
> >> >   % bzr push sftp://costa.debian.org/bzr/pkg-xiph/vorbis-tools
> >>
> >> We're using that for LTSP. But we're using it in our htdocs dir. How
> >> do you set this repository up?
> >
> > Ask in #alioth. Note, however, that TTBOMK still does not offer HTTP
> > access, so if you want that, better stick to htdocs for a while.
> >
> > I hope to be able to bribe buxy to provide HTTP access when he comes
> > back, though. ;-)
>
> So you only have sftp access? that make it difficult to other to
> branch from our development branch. I'll wait until we have HTTP as a
> offer to move to it.

That's in fact an issue that made me feel sceptical about bzr, darcs and 
mercury. All of them require a shell account or some scripting through a 
special mail address to commit changes. And it's not only the recent 
kernel vulnerability that makes me a happy repository user over WebDAV 
(hoping it's less vulnerable). And it works over a proxy, too.

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Otavio Salvador]

Adeodato Simó <[EMAIL PROTECTED]> writes:

> * Otavio Salvador [Tue, 01 Aug 2006 15:43:56 -0300]:
>
>> Adeodato Simó <[EMAIL PROTECTED]> writes:
>
>> > Then each developer can prepare a set of changes offline, do all the
>> > branching, merging, commiting and uncommiting (gotta love that) that
>> > they want, and when they're done, do e.g.:
>
>> >   % bzr push sftp://costa.debian.org/bzr/pkg-xiph/vorbis-tools
>
>> We're using that for LTSP. But we're using it in our htdocs dir. How
>> do you set this repository up?
>
> Ask in #alioth. Note, however, that TTBOMK still does not offer HTTP
> access, so if you want that, better stick to htdocs for a while.
>
> I hope to be able to bribe buxy to provide HTTP access when he comes
> back, though. ;-)

So you only have sftp access? that make it difficult to other to
branch from our development branch. I'll wait until we have HTTP as a
offer to move to it.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Adeodato Simó]

* Otavio Salvador [Tue, 01 Aug 2006 15:43:56 -0300]:

> Adeodato Simó <[EMAIL PROTECTED]> writes:

> > Then each developer can prepare a set of changes offline, do all the
> > branching, merging, commiting and uncommiting (gotta love that) that
> > they want, and when they're done, do e.g.:

> >   % bzr push sftp://costa.debian.org/bzr/pkg-xiph/vorbis-tools

> We're using that for LTSP. But we're using it in our htdocs dir. How
> do you set this repository up?

Ask in #alioth. Note, however, that TTBOMK still does not offer HTTP
access, so if you want that, better stick to htdocs for a while.

I hope to be able to bribe buxy to provide HTTP access when he comes
back, though. ;-)

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Listening to: Polar - 41 (Forty-One)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[martin f krafft]

also sprach Thijs Kinkhorst <[EMAIL PROTECTED]> [2006.08.02.1020 +0100]:
> > This shouldn't need snapshot.debian.net, right?
> 
> If the bug is claimed to be fixed in the changelog of 2.0-5 and the
> current sid version is 2.0-7, I don't know another way to see the diff
> between 2.0-4 and 2.0-5, since both are not available from the regular
> archives. How would you handle this?

I misunderstood you. I thought you were talking about differences
between the current and the sarge version, which are obviously
available without snapshot.d.n

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"the search for the perfect martini is a fraud. the perfect martini
 is a belt of gin from the bottle; anything else is the decadent
 trappings of civilization."
-- t. k.


signature.asc
Description: Digital signature (GPG/PGP)

Re: Successful and unsuccessful Debian development tools

[Thijs Kinkhorst]

On Tue, 2006-08-01 at 20:57 +0100, martin f krafft wrote:
> > I'm using it when porting security fixes to sarge. If the maintainer has
> > fixed a security bug in sid, I download that version and the version
> > before and can see right away what exactly he changed to fix the bug.
> 
> This shouldn't need snapshot.debian.net, right?

If the bug is claimed to be fixed in the changelog of 2.0-5 and the
current sid version is 2.0-7, I don't know another way to see the diff
between 2.0-4 and 2.0-5, since both are not available from the regular
archives. How would you handle this?


Thijs


signature.asc
Description: This is a digitally signed message part

Re: Successful and unsuccessful Debian development tools

[Pierre Machard]

Hi,

On Tue, Aug 01, 2006 at 03:31:26PM +0100, martin f krafft wrote:
> also sprach Pierre Machard <[EMAIL PROTECTED]> [2006.08.01.1501 +0100]:
> > snapshot.debian.net (still not-official but very usefull)
> 
> This is very interesting, especially in the light of version control
> for packaging -- which could also make packages from the past
> accessible.
> 
> Could you give me some insights, please, into how snapshot.d.n is
> useful? Don't get me wrong, I also find it useful, but mostly from
> the administrator perspective, I've not really used it as
> a developer.

The main points about snapshot.d.n have already been repported. To me it's 
like a classical library that is to say a "collection of records kept for
reference or borrowing" (quoting from WordNet). It helps to keep track
of any change within the archive, and sometimes it stores record that are
not available anywhere because the source packages are not maintained
anymore and disapear from the web.

When you are interested in QA, it's important to be able to identify why
a bug appear, in which condition, etc.

Now, let me speak about PTS and ddpo.

As a maintainer, these tools helps you to keep an eye on your packages
and your activities.

DDPO : 
On the same page, you have a lot of information about your maintainer
activities. Are there RC bugs ? How may bugs ? Is this package
co-maintained ? Did I had a NMU ?

PTS : Why my package does not enter into testing, How many bugs, many
links to the life of a package. and I would like to
add that thanks to Björn Stenberg, we have a useful script to understand
the evolution of a package. The PTS have also very powerfull email
option that can email you any change or bug repported on a package,
especialy interesting when you are co-maintaining a package.

About the PTS, note that this is on of only tool, with lintian that
recalls you that the Standard-Version changed, and that it could be
interesting to check what changed in Standard-Versions since the package
lastest upload. Finaly on point, that is important to me: it advertises 
maintainers of important packages that co-maintaining a package could 
be a nice thing.

Cheers,
-- 
Pierre Machard
<[EMAIL PROTECTED]> http://debian.org
GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87



signature.asc
Description: Digital signature

Re: Successful and unsuccessful Debian development tools

[Dale C. Scheetz]

Stuff deleted
> 
> I have cdebootstrap do create chroots, dchroot to use them,
> buildd/sbuild to test compile under true buildd conditions. Why would
> I want something else?
> 
I'm not sure I know, but now that I know about this pair, I will certainly look 
into it. After that, if I can answer your question, I'll get back to you ;-)

I mainly wanted to say thank you, not only to Goswin, but to the rest of you 
who have helped to turn this list back into something readable!

Thank You! Thank You! Thank You!

> Debootstrap couldn't even handle dependency resolving a while back.

Things change. (See above)

> 
> MfG
> Goswin


Luck,

Dwarf


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Robert Collins]

On Tue, 2006-08-01 at 19:44 +0100, martin f krafft wrote:
> also sprach Adeodato Simó <[EMAIL PROTECTED]> [2006.08.01.1936 +0100]:
> > Forgot to add that it can be even _identical_ to subversion, in the
> > sense that you don't have to commit locally, and then push. Just make a
> > "checkout" (refer to the bzr docs), and every commit you make will go to
> > the main repo first, and if that succeeds, will be commited locally as
> > well.
> 
> This is what upstream calls "bound branches", btw.

Well, we call them 'checkouts' :). bound branches is somewhat of an
internal description.

We implemented checkouts to be a precise workflow match for what you get
from SVN/CVS - a branch shared between developers with the system
ensuring you have merged everything. If you have a situation where a
shared branch is what you want, and you like bzr in other respects... I
would recommend trying checkouts.

Rob

-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Re: Successful and unsuccessful Debian development tools

[martin f krafft]

also sprach Thijs Kinkhorst <[EMAIL PROTECTED]> [2006.08.01.1537 +0100]:
> > Could you give me some insights, please, into how snapshot.d.n is
> > useful? Don't get me wrong, I also find it useful, but mostly from
> > the administrator perspective, I've not really used it as
> > a developer. 
> 
> I'm using it when porting security fixes to sarge. If the maintainer has
> fixed a security bug in sid, I download that version and the version
> before and can see right away what exactly he changed to fix the bug.

This shouldn't need snapshot.debian.net, right?

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
oxymoron: micro$oft works


signature.asc
Description: Digital signature (GPG/PGP)

Re: Successful and unsuccessful Debian development tools

[Stefano Zacchiroli]

On Tue, Aug 01, 2006 at 03:31:26PM +0100, martin f krafft wrote:
> Could you give me some insights, please, into how snapshot.d.n is
> useful? Don't get me wrong, I also find it useful, but mostly from
> the administrator perspective, I've not really used it as
> a developer.

Testing of various upgrade paths, especially useful to check whether
ld reported upgrade bugs are still valid or not.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Otavio Salvador]

Adeodato Simó <[EMAIL PROTECTED]> writes:

> Then each developer can prepare a set of changes offline, do all the
> branching, merging, commiting and uncommiting (gotta love that) that
> they want, and when they're done, do e.g.:
>
>   % bzr push sftp://costa.debian.org/bzr/pkg-xiph/vorbis-tools

We're using that for LTSP. But we're using it in our htdocs dir. How
do you set this repository up?

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[martin f krafft]

also sprach Adeodato Simó <[EMAIL PROTECTED]> [2006.08.01.1936 +0100]:
> Forgot to add that it can be even _identical_ to subversion, in the
> sense that you don't have to commit locally, and then push. Just make a
> "checkout" (refer to the bzr docs), and every commit you make will go to
> the main repo first, and if that succeeds, will be commited locally as
> well.

This is what upstream calls "bound branches", btw.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
obviously i was either onto something, or on something.
 -- larry wall on the creation of perl


signature.asc
Description: Digital signature (GPG/PGP)

Re: Successful and unsuccessful Debian development tools

[Mark Brown]

On Tue, Aug 01, 2006 at 07:19:19PM +0100, martin f krafft wrote:

> Yes, and I wanted to know why he thought that is the case. I believe
> Christoph has given a good account of the reasons. If you have
> anything to add, please do!

There's also the fact that well known teams like the installer and
kernel teams use subversion.  This makes it much easier for people
looking for a template to follow to pick subversion.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Adeodato Simó]

* Adeodato Simó [Tue, 01 Aug 2006 20:31:37 +0200]:

> they want, and when they're done, do e.g.:

>   % bzr push sftp://costa.debian.org/bzr/pkg-xiph/vorbis-tools

Forgot to add that it can be even _identical_ to subversion, in the
sense that you don't have to commit locally, and then push. Just make a
"checkout" (refer to the bzr docs), and every commit you make will go to
the main repo first, and if that succeeds, will be commited locally as
well.

Not that I'd particularly recommend that scheme, but it _is_ possible.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
As scarce as truth is, the supply has always been in excess of the demand.
-- Josh Billings


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Adeodato Simó]

* Christoph Haas [Tue, 01 Aug 2006 17:33:15 +0200]:

Hi,

> No offense intended - honestly - but the problem of passing 
> patches/patchsets around between the maintainers is really a problem. In 
> Subversion I know where the authoritative instance lies that is the master 
> instance keeping the current state. If there is one superior maintainer 
> who makes the repository available online to co-maintainers who are just 
> allowed to send in patches - that might work well. But if several people 
> are equally involved in a project this seems to quickly become a problem.

> I had tried distributed RCSs just because it's a more "modern" approach and 
> because a number of developers and maintainers seem to find Subversion 
> problematic. But if I group maintain a package and need to collect 
> everybody's work before building and uploading a package that's just too 
> hard.

> The bazaar-ng web site describes a few ways to pass the changes around 
> (http://bazaar-vcs.org/BzrForCVSUsers) but I found neither one very 
> appealing. I don't mind other team members working locally. But I need to 
> get access to their changes ASAP to have them included in the next 
> release/revision.

Right, bzr is great when you have a designed person to integrate
contributor's changes after review.

But if you have a set of equal developers, bzr can be also used in a
very similar way to Subversion, where all commits go to a central
repository, and nobody has to collect them. It's just a matter of
setting up a directory somewhere with the appropriate write permissions,
and say "This is our canonical archive, the uploader will include what
it's in there, nothing more, nothing less".

Then each developer can prepare a set of changes offline, do all the
branching, merging, commiting and uncommiting (gotta love that) that
they want, and when they're done, do e.g.:

  % bzr push sftp://costa.debian.org/bzr/pkg-xiph/vorbis-tools

(That repository actually exists.)

The only piece missing in this scheme is e-mail notification. I very
much like how with Subversion it's trivial to set up a pkg-foo-commits
list. Haven't figured out a "nice" way with bzr yet, suggestions
welcome.

HTH,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[Andreas Metzler]

martin f krafft <[EMAIL PROTECTED]> wrote:
> also sprach Joey Hess <[EMAIL PROTECTED]> [2006.08.01.1907 +0100]:
[...]
>> I assumed he meant it in the sense that more teams seem to be
>> using subversion on alioth than any other RCS.
[...]
> Yes, and I wanted to know why he thought that is the case. I believe
> Christoph has given a good account of the reasons. If you have
> anything to add, please do!

Basic usage of SVN is quickly learned, especially if you know cvs.
cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.(c) Jasper Ffforde


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[Andreas Metzler]

martin f krafft <[EMAIL PROTECTED]> wrote:
> also sprach Pierre Machard <[EMAIL PROTECTED]> [2006.08.01.1501 +0100]:
>> snapshot.debian.net (still not-official but very usefull

> This is very interesting, especially in the light of version control
> for packaging -- which could also make packages from the past
> accessible.
[...]

Not every package's source code is kept in a version control repository
which is publically available.  - Think qa-upload or adoption of an
existing non-vcr package.
cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.(c) Jasper Ffforde


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[martin f krafft]

also sprach Joey Hess <[EMAIL PROTECTED]> [2006.08.01.1907 +0100]:
> > I'd be interested in your thoughts as to why subversion beats them
> > all, in your perception.
> 
> I assumed he meant it in the sense that more teams seem to be
> using subversion on alioth than any other RCS. Ie, compare
> the list at http://svn.debian.org/ with http://arch.debian.org/
> 
> Of course there is probably less incentive to use alioth if using a
> distributed RCS, but my sense is that more projects in debian are using
> svn version control than any other RCS nontheless.

Yes, and I wanted to know why he thought that is the case. I believe
Christoph has given a good account of the reasons. If you have
anything to add, please do!

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"i like young girls. their stories are shorter."
-- tom mcguane


signature.asc
Description: Digital signature (GPG/PGP)

Re: Successful and unsuccessful Debian development tools

[Joey Hess]

martin f krafft wrote:
> also sprach David Nusinow <[EMAIL PROTECTED]> [2006.08.01.0005 +0100]:
> > Subversion, in conjunction with alioth, has risen dramatically in
> > Debian to accomodate team-based maintainance. There are of course
> > plenty of challengers, but subversion seems to beat them all.
> 
> I'd be interested in your thoughts as to why subversion beats them
> all, in your perception.

I assumed he meant it in the sense that more teams seem to be
using subversion on alioth than any other RCS. Ie, compare
the list at http://svn.debian.org/ with http://arch.debian.org/

Of course there is probably less incentive to use alioth if using a
distributed RCS, but my sense is that more projects in debian are using
svn version control than any other RCS nontheless.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Successful and unsuccessful Debian development tools

[martin f krafft]

also sprach Otavio Salvador <[EMAIL PROTECTED]> [2006.08.01.1804 +0100]:
> > FYI: http://bazaar-vcs.org/BzrForeignBranches/Subversion
> 
> Have you tryed it?

Not productively.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
still looking for the glorious results of my misspent youth.
say, do you have a map to the next joint?


signature.asc
Description: Digital signature (GPG/PGP)

Re: Successful and unsuccessful Debian development tools

[Otavio Salvador]

martin f krafft <[EMAIL PROTECTED]> writes:

> Thanks, Christoph, I think you argued a good case!
>
>> I'll probably use bzr when I need to keep something revisioned
>> without much fuss just to save the time for "svnadmin create" and
>> a DAV share on my Apache. But for everything else I think I'll
>> stay with Subversion. And while I haven't tried it I could imagine
>> that SVK (the distributed addon to Subversion) might be what makes
>> offline fellows happy.
>
> FYI: http://bazaar-vcs.org/BzrForeignBranches/Subversion

Have you tryed it?

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[Joe Smith]

"Goswin von Brederlow" <[EMAIL PROTECTED]> wrote in 
message news:[EMAIL PROTECTED]

[EMAIL PROTECTED] (Marco d'Itri) writes:


On Aug 01, David Nusinow <[EMAIL PROTECTED]> wrote:


Also, pbuilder and debootstrap are considered absolutely critical for
serious work.

That's a bold statement.

--
ciao,
Marco


Never used either one.

I have cdebootstrap do create chroots, dchroot to use them,
buildd/sbuild to test compile under true buildd conditions. Why would
I want something else?

Debootstrap couldn't even handle dependency resolving a while back.


I think that by debootstap David was including both normal and cdebootstrap.
After all, cdebootstrap is mostly a port of debootstrap, although with some 
improvments.





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Building in chroots hides bugs? (was: Successful and unsuccessful Debian development tools)

[martin f krafft]

also sprach Bernhard R. Link <[EMAIL PROTECTED]> [2006.08.01.1701 +0100]:
> Missing $(DESTDIR)s in Makefiles are an example. Especially when the
> install part was DESTDIRified, but the test before if the file is
> already there (as make install does not want to overwrite a config file)
> was forgotten.
> This leads to a corrupt package when build on a system where the package
> is already installed, i.e. is hidden away in any clean chroot.

This makes zero sense to me.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"eine schlechte sache erregt, eine gute verträgt viel kritik."
-- charles tschopp


signature.asc
Description: Digital signature (GPG/PGP)

Re: Building in chroots hides bugs? (was: Successful and unsuccessful Debian development tools)

[Bernhard R. Link]

* martin f krafft <[EMAIL PROTECTED]> [060801 15:29]:
> also sprach Marco d'Itri <[EMAIL PROTECTED]> [2006.08.01.1221 +0100]:
> > Building in chroots *hides* bugs.
> 
> Uh, what? Please give an example.

Missing $(DESTDIR)s in Makefiles are an example. Especially when the
install part was DESTDIRified, but the test before if the file is
already there (as make install does not want to overwrite a config file)
was forgotten.
This leads to a corrupt package when build on a system where the package
is already installed, i.e. is hidden away in any clean chroot.

Hochachtungsvoll,
  Bernhard R. Link


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[martin f krafft]

Thanks, Christoph, I think you argued a good case!

> I'll probably use bzr when I need to keep something revisioned
> without much fuss just to save the time for "svnadmin create" and
> a DAV share on my Apache. But for everything else I think I'll
> stay with Subversion. And while I haven't tried it I could imagine
> that SVK (the distributed addon to Subversion) might be what makes
> offline fellows happy.

FYI: http://bazaar-vcs.org/BzrForeignBranches/Subversion

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
gates' law: every 18 months, the speed of software halves.


signature.asc
Description: Digital signature (GPG/PGP)

Re: Successful and unsuccessful Debian development tools

[Goswin von Brederlow]

Simon Richter <[EMAIL PROTECTED]> writes:

> Hi,
>
> martin f krafft wrote:
>
>>> Subversion, in conjunction with alioth, has risen dramatically in
>>> Debian to accomodate team-based maintainance. There are of course
>>> plenty of challengers, but subversion seems to beat them all.
>
>> I'd be interested in your thoughts as to why subversion beats them
>> all, in your perception.
>
> It is centralized, so you have an authoritative source and need not talk
> to the other team members to synchronize.
>
>Simon

It is very similar to alreay familiar cvs. It is also way easier to
use first time than any of the others with the possible exception of
git. For example trying arch for the first time gives you a major
headache.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[Christoph Haas]

On Tuesday 01 August 2006 13:44, martin f krafft wrote:
> also sprach David Nusinow <[EMAIL PROTECTED]> [2006.08.01.0005 
+0100]:
> > Subversion, in conjunction with alioth, has risen dramatically in
> > Debian to accomodate team-based maintainance. There are of course
> > plenty of challengers, but subversion seems to beat them all.
>
> I'd be interested in your thoughts as to why subversion beats them
> all, in your perception.

I know that this has somehow become a religious question. Recently when I 
looked for a co-maintainer I was told that we can agree on anything as 
long we we don't use subversion. So I spent several days to wade through 
the lots of documentation to learn about distributed revision control 
systems and found darcs, mercury (hg) and bazaar-ng (bzr) to be decent 
candidates for such an approach. And I currently use bzr to maintain a 
simple Debian package to gain some experience with it. It's nice and 
simple.

However using distributed RCS is a pain in the kind of projects I work on 
with other people. Such a system might be great for people in the 
underground train who want to maintain their packages. But which 
maintainer does not have a permanent internet connection but enough 
electricity to operate a laptop for more than 2 hours? And to try out 
things I can just "cp -a" a directory tree and test something and perhaps 
copy files around. Why do I need to do a fancy "branch" to accomplish the 
same with more commands and try not to break my fingers when merging the 
branch?

No offense intended - honestly - but the problem of passing 
patches/patchsets around between the maintainers is really a problem. In 
Subversion I know where the authoritative instance lies that is the master 
instance keeping the current state. If there is one superior maintainer 
who makes the repository available online to co-maintainers who are just 
allowed to send in patches - that might work well. But if several people 
are equally involved in a project this seems to quickly become a problem.

I had tried distributed RCSs just because it's a more "modern" approach and 
because a number of developers and maintainers seem to find Subversion 
problematic. But if I group maintain a package and need to collect 
everybody's work before building and uploading a package that's just too 
hard.

The bazaar-ng web site describes a few ways to pass the changes around 
(http://bazaar-vcs.org/BzrForCVSUsers) but I found neither one very 
appealing. I don't mind other team members working locally. But I need to 
get access to their changes ASAP to have them included in the next 
release/revision.

So it appears to be a tradeoff. With distributed RCS you gain the freedom 
to develop everywhere as long as you have electricity. But you have the 
disadvantage that the way to commit changes to a central instance is all 
but automatic.

I'll probably use bzr when I need to keep something revisioned without much 
fuss just to save the time for "svnadmin create" and a DAV share on my 
Apache. But for everything else I think I'll stay with Subversion. And 
while I haven't tried it I could imagine that SVK (the distributed addon 
to Subversion) might be what makes offline fellows happy.

My 2¢...

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All

Re: Successful and unsuccessful Debian development tools

[Roger Leigh]

Christian Aichinger <[EMAIL PROTECTED]> writes:

> On Tue, Aug 01, 2006 at 10:24:32AM +, Reinhard Tartler wrote:
>> The sbuild package in debian however adds more features, like
>> schroot support. With this, it can use schroot to create
>> temporary, clean chroots from tarballs, block devices, create lvm
>> snapshots on the fly and so on. I read Roger, that even xen
>> support is planned.

Xen support is planned, but not for the immediate future.  I'm waiting
on its inclusion in the kernel, and a working powerpc32 port.  So it's
more of a medium- to long-term goal, unless there are any Xen fanatics
who step up to do it sooner :)

>> schroot is another very very useful tool. It gives me more or less
>> instant access to clean chroots on lvm snapshots for experimenting,
>> building, developing and testing.
>
> When I didn't know schroot could do this I wrote a script to do that
> myself:
> http://greek0.net/lvmchroot/lvmchroot_0.5-1.dsc
>
> It's geared towards creating and maintaining chroots on LVM logical
> volumes, creating snapshots as needed. It also takes care of
> creating the initial chroots on LVs, it can automatically upgrade
> them, etc.
>
> Plus they're better documented (IMHO) as schroot, for which I
> couldn't find any useful docs.

A complete copy of the docs is here:

https://alioth.debian.org/docman/?group_id=30471

I agree they aren't the most user-friendly in the world; some
additional explanatory material would help a great deal.

I think schroot has a slightly different focus, which would account
for the differences.  schroot focuses on allowing user access to, and
maintainence of chroots.  It plays no part in the initial chroot
creation, or performing stuff like keeping them up-to-date.  It
delegates this to other tools, like debootstrap and the sbuild chroot
tools (in /usr/share/sbuild).  lvmchroot, on the other hand, assists
with initial chroot setup, and snapshot creation but doesn't handle
the chroot(2) stuff to allow user access.

As a result, I think the two tools could complement each other nicely.
I would be very happy to add additional helper scripts to schroot, and
merge missing features.  One thing we don't currently do is allow the
user to specify the LVM snapshot name; it gets a UUID.  Having this as
an option would be nice.

Some of the sbuild scripts could also be merged with lvmchroot, such
as buildd.chroot.

> If the schroot maintainers agree we could try to merge my stuff into
> schroot.

That would be really cool.  We are part of the buildd-tools project on
Alioth:

  https://alioth.debian.org/projects/buildd-tools/

so subscribing to the list would be a good first step.  The current
SVN is at

  svn://svn.debian.org/svn/buildd-tools/trunk/schroot


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please sign and encrypt your mail.


pgpvazcFrBsYK.pgp
Description: PGP signature

Re: Successful and unsuccessful Debian development tools

[Roberto C. Sanchez]

On Tue, Aug 01, 2006 at 03:31:26PM +0100, martin f krafft wrote:
> also sprach Pierre Machard <[EMAIL PROTECTED]> [2006.08.01.1501 +0100]:
> > snapshot.debian.net (still not-official but very usefull
> 
> This is very interesting, especially in the light of version control
> for packaging -- which could also make packages from the past
> accessible.
> 
> Could you give me some insights, please, into how snapshot.d.n is
> useful? Don't get me wrong, I also find it useful, but mostly from
> the administrator perspective, I've not really used it as
> a developer.
> 

I find it helpful when backporting.  For example, back when package foo
went from version 2.1-3 to 2.1-4, the dependency on package bar was
changed from version 1.16 to 1.29.  It can be instructive to look at the
old versions of the packages to see what has changed.  This is not
"official" development since backports are not officially supported, but
I know I occasionally backport packages for my own use.

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto


signature.asc
Description: Digital signature

Re: Successful and unsuccessful Debian development tools

[Lars Wirzenius]

ti, 2006-08-01 kello 15:31 +0100, martin f krafft kirjoitti:
> also sprach Pierre Machard <[EMAIL PROTECTED]> [2006.08.01.1501 +0100]:
> > snapshot.debian.net (still not-official but very usefull
> 
> This is very interesting, especially in the light of version control
> for packaging -- which could also make packages from the past
> accessible.

Note that source code version control does not always make it easy to
re-create the exact same binary package. If, for example, the package
uses debhelper, and the binary package that actually exist{s,ed} in
Debian was built with an older version of debhelper, re-building the
package from source now with a newer debhelper might not result in a
package that behaves in the same way. For example, the old version might
have not called an init.d script via invoke-rc.d, but the new one does.
This may make things more difficult to debug.

> Could you give me some insights, please, into how snapshot.d.n is
> useful? Don't get me wrong, I also find it useful, but mostly from
> the administrator perspective, I've not really used it as
> a developer.

I've used snapshot.d.n once or twice to look for when a problem due to
debhelper changes like described above changed its behavior.

-- 
When in doubt, use brute force.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[Thijs Kinkhorst]

On Tue, 2006-08-01 at 15:31 +0100, martin f krafft wrote:
> Could you give me some insights, please, into how snapshot.d.n is
> useful? Don't get me wrong, I also find it useful, but mostly from
> the administrator perspective, I've not really used it as
> a developer. 

I'm using it when porting security fixes to sarge. If the maintainer has
fixed a security bug in sid, I download that version and the version
before and can see right away what exactly he changed to fix the bug.


Thijs


signature.asc
Description: This is a digitally signed message part

Re: Successful and unsuccessful Debian development tools

[Steinar H. Gunderson]

On Tue, Aug 01, 2006 at 03:31:26PM +0100, martin f krafft wrote:
> Could you give me some insights, please, into how snapshot.d.n is
> useful? Don't get me wrong, I also find it useful, but mostly from
> the administrator perspective, I've not really used it as
> a developer.

Binary searching for what version some bug surfaced in; reproduction of
upgrade bugs.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[martin f krafft]

also sprach Pierre Machard <[EMAIL PROTECTED]> [2006.08.01.1501 +0100]:
> snapshot.debian.net (still not-official but very usefull

This is very interesting, especially in the light of version control
for packaging -- which could also make packages from the past
accessible.

Could you give me some insights, please, into how snapshot.d.n is
useful? Don't get me wrong, I also find it useful, but mostly from
the administrator perspective, I've not really used it as
a developer.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
who's general failure, and why's he reading my disk?


signature.asc
Description: Digital signature (GPG/PGP)

Re: Successful and unsuccessful Debian development tools

[Pierre Machard]

Hi,

On Sun, Jul 30, 2006 at 09:39:26PM +0100, martin f krafft wrote:
[...]
> While I already have a good selection, I am on the look for more.
> Do you know of a good example of a tool that has successfully shaped
> Debian development for a large number of people? Or do you remember
> a tool that tried but horribly failed? Those are much harder to
> find. :)

snapshot.debian.net (still not-official but very usefull

and of course PTS, ddpo and po-debconf. 

Bad tool as a translator, older debconf (previous po-debconf).

My 2c,
-- 
Pierre Machard
<[EMAIL PROTECTED]> http://debian.org
GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87



signature.asc
Description: Digital signature

Re: Building in chroots hides bugs? (was: Successful and unsuccessful Debian development tools)

[Martijn van Oosterhout]

On 8/1/06, martin f krafft <[EMAIL PROTECTED]> wrote:

also sprach Marco d'Itri <[EMAIL PROTECTED]> [2006.08.01.1221 +0100]:
> Building in chroots *hides* bugs.

Uh, what? Please give an example.


The only example I can think of is programs that use configure to
include support for anything they can find installed. So you get
different results depending on what's installed in the buildd. It's a
bug in the packaging though, the maintainer should be doing --enable-*
or --disable-* for every option. The point being that if you only
build in a clean chroot you'll never notice the problem.

That's how I understand it anyway,

Have a nice day,
--
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[Simon Richter]

Hi,

martin f krafft wrote:

>> Subversion, in conjunction with alioth, has risen dramatically in
>> Debian to accomodate team-based maintainance. There are of course
>> plenty of challengers, but subversion seems to beat them all.

> I'd be interested in your thoughts as to why subversion beats them
> all, in your perception.

It is centralized, so you have an authoritative source and need not talk
to the other team members to synchronize.

   Simon



signature.asc
Description: OpenPGP digital signature

Re: Successful and unsuccessful Debian development tools

[Christian Aichinger]

On Tue, Aug 01, 2006 at 10:24:32AM +, Reinhard Tartler wrote:
> The sbuild package in debian however adds more features, like
> schroot support. With this, it can use schroot to create
> temporary, clean chroots from tarballs, block devices, create lvm
> snapshots on the fly and so on. I read Roger, that even xen
> support is planned.
> 
> schroot is another very very useful tool. It gives me more or less
> instant access to clean chroots on lvm snapshots for experimenting,
> building, developing and testing.

When I didn't know schroot could do this I wrote a script to do that
myself:
http://greek0.net/lvmchroot/lvmchroot_0.5-1.dsc

It's geared towards creating and maintaining chroots on LVM logical
volumes, creating snapshots as needed. It also takes care of
creating the initial chroots on LVs, it can automatically upgrade
them, etc.

Plus they're better documented (IMHO) as schroot, for which I
couldn't find any useful docs.

If the schroot maintainers agree we could try to merge my stuff into
schroot.

Cheers,
Christian Aichinger


signature.asc
Description: Digital signature

Re: Building in chroots (was: Successful and unsuccessful Debian development tools)

[Eduard Bloch]

#include 
* Frank Küster [Tue, Aug 01 2006, 01:55:14PM]:
> [EMAIL PROTECTED] (Marco d'Itri) wrote:
> 
> > On Aug 01, Eduard Bloch <[EMAIL PROTECTED]> wrote:
> >
> >> > > Also, pbuilder and debootstrap are considered absolutely critical for
> >> > > serious work.
> >> > That's a bold statement.
> >> Are you serious? (SCNR ;-)
> > Yes. I do not use either and I think I have been doing serious Debian
> > work so far.

Argh, the smiley was there for a reason...

> > Building in chroots *hides* bugs.
> 
> Of course.  However, not building in chroots also hides bugs.  Why do
> you think it's better to build in a chroot?

After all, I think after comparing pros and cons the bill will be even.
But at much higher processing costs. I am sceptical about pbuilder
because of it, and because it leads to too much thrust into the tool
instead of thinking about possible consequences of changes.

> I think a package should be built on the developer's system (which,
> hopefully, is a typical example for the environment were the package
> will be used and built), and in a clean chroot.  It should be tested (in

I think it should be working in both, therefore I like the general
concept of building in normal environment and uploading package as
source trough the auto-builder.

> the sense of: Can it be installed?  Does it run at all?) in a chroot,
> and also on the developer's system.  Of course the amount of testing
> needed depends on the extent of the changes.

Testing is not always enough to catch all possible bugs.

Eduard.
-- 
Ich bin sicher, käme Jesus heute, würde er von der Kirche nicht
erkannt, sondern wahrscheinlich verfolgt und wieder zu Tode gemartert
werden.
-- Henry Miller


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[Goswin von Brederlow]

[EMAIL PROTECTED] (Marco d'Itri) writes:

> On Aug 01, David Nusinow <[EMAIL PROTECTED]> wrote:
>
>> Also, pbuilder and debootstrap are considered absolutely critical for
>> serious work.
> That's a bold statement.
>
> -- 
> ciao,
> Marco

Never used either one.

I have cdebootstrap do create chroots, dchroot to use them,
buildd/sbuild to test compile under true buildd conditions. Why would
I want something else?

Debootstrap couldn't even handle dependency resolving a while back.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Building in chroots hides bugs? (was: Successful and unsuccessful Debian development tools)

[martin f krafft]

also sprach Marco d'Itri <[EMAIL PROTECTED]> [2006.08.01.1221 +0100]:
> Building in chroots *hides* bugs.

Uh, what? Please give an example.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"emacs sucks, literally, not an insult, just a comment that it's
 large enough to have a noticeable gravitational pull..."
   -- mercury on #debian-devel


signature.asc
Description: Digital signature (GPG/PGP)

Re: Successful and unsuccessful Debian development tools

[martin f krafft]

also sprach David Nusinow <[EMAIL PROTECTED]> [2006.08.01.0005 +0100]:
> Subversion, in conjunction with alioth, has risen dramatically in
> Debian to accomodate team-based maintainance. There are of course
> plenty of challengers, but subversion seems to beat them all.

I'd be interested in your thoughts as to why subversion beats them
all, in your perception.

Thanks,

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
for years, we have thought that a million monkeys typing at a million 
typewriters would eventually produce the complete works of shakespeare.
today, thanks to the internet, we know this is not true.


signature.asc
Description: Digital signature (GPG/PGP)

Building in chroots (was: Successful and unsuccessful Debian development tools)

[Frank Küster]

[EMAIL PROTECTED] (Marco d'Itri) wrote:

> On Aug 01, Eduard Bloch <[EMAIL PROTECTED]> wrote:
>
>> > > Also, pbuilder and debootstrap are considered absolutely critical for
>> > > serious work.
>> > That's a bold statement.
>> Are you serious? (SCNR ;-)
> Yes. I do not use either and I think I have been doing serious Debian
> work so far.
> Building in chroots *hides* bugs.

Of course.  However, not building in chroots also hides bugs.  Why do
you think it's better to build in a chroot?

I think a package should be built on the developer's system (which,
hopefully, is a typical example for the environment were the package
will be used and built), and in a clean chroot.  It should be tested (in
the sense of: Can it be installed?  Does it run at all?) in a chroot,
and also on the developer's system.  Of course the amount of testing
needed depends on the extent of the changes.

But not testing at all in a clean environment isn't a good idea, at
least with the packages that I work with.  In particular because I
frequently have locally changed configuration files, which may hide some
bugs, too.

Regards, Frank

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Successful and unsuccessful Debian development tools

[Frank Küster]

Reinhard Tartler <[EMAIL PROTECTED]> wrote:

> Frank Küster wrote:
>>> There is also sbuild (which may be used with or without schroot to
>>> manage the chroot).  I prefer it to pbuilder, but I may be a little
>>> biased ;-)
>>
>> Isn't sbuild usually using a permanently unpacked chroot which persists
>> between different invocations of the tool?  That's not what I'd call a
>> "clean chroot", although a skilled and concentrated person might do well
>> with it.
>
> This applies to the DSA version, which is used on the buildds. The
> sbuild package in debian however adds more features, like schroot
> support. With this, it can use schroot to create temporary, clean
> chroots from tarballs, block devices, create lvm snapshots on the fly
> and so on. I read Roger, that even xen support is planned.

Ah, great.  Good to know - this will probably require some reading and
configuring, but it sounds it's worth it.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Successful and unsuccessful Debian development tools

[Marco d'Itri]

On Aug 01, Eduard Bloch <[EMAIL PROTECTED]> wrote:

> > > Also, pbuilder and debootstrap are considered absolutely critical for
> > > serious work.
> > That's a bold statement.
> Are you serious? (SCNR ;-)
Yes. I do not use either and I think I have been doing serious Debian
work so far.
Building in chroots *hides* bugs.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Successful and unsuccessful Debian development tools

[Reinhard Tartler]

Frank Küster wrote:
>> There is also sbuild (which may be used with or without schroot to
>> manage the chroot).  I prefer it to pbuilder, but I may be a little
>> biased ;-)
>
> Isn't sbuild usually using a permanently unpacked chroot which persists
> between different invocations of the tool?  That's not what I'd call a
> "clean chroot", although a skilled and concentrated person might do well
> with it.

This applies to the DSA version, which is used on the buildds. The
sbuild package in debian however adds more features, like schroot
support. With this, it can use schroot to create temporary, clean
chroots from tarballs, block devices, create lvm snapshots on the fly
and so on. I read Roger, that even xen support is planned.

schroot is another very very useful tool. It gives me more or less
instant access to clean chroots on lvm snapshots for experimenting,
building, developing and testing.

Greetings,
Reinhard



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[Frank Küster]

Roger Leigh <[EMAIL PROTECTED]> wrote:

> Frank Küster <[EMAIL PROTECTED]> writes:
>
>> I think maintainers should really build and test their packages in
>> clean sid chroots.  It's not important Whether these are set up with
>> debootstrap or any other method, and whether the handling is done
>> with pbuilder, manually or with other tools.  But it should be done,
>> and since these are the only tools for the purpose I know of, and
>> people don't like to do all by hand, I think they are in fact very
>> important.
>
> There is also sbuild (which may be used with or without schroot to
> manage the chroot).  I prefer it to pbuilder, but I may be a little
> biased ;-)

Isn't sbuild usually using a permanently unpacked chroot which persists
between different invocations of the tool?  That's not what I'd call a
"clean chroot", although a skilled and concentrated person might do well
with it.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Successful and unsuccessful Debian development tools

[Roger Leigh]

Frank Küster <[EMAIL PROTECTED]> writes:

> Eduard Bloch <[EMAIL PROTECTED]> wrote:
>
>> #include 
>> * Marco d'Itri [Tue, Aug 01 2006, 09:53:21AM]:
>>> On Aug 01, David Nusinow <[EMAIL PROTECTED]> wrote:
>>> 
>>> > Also, pbuilder and debootstrap are considered absolutely critical for
>>> > serious work.
>>> That's a bold statement.
>>
>> Are you serious? (SCNR ;-)
>>
>> No, debootstrap is an important toy but but pbuilder is hyped too much.
>
> I think maintainers should really build and test their packages in
> clean sid chroots.  It's not important Whether these are set up with
> debootstrap or any other method, and whether the handling is done
> with pbuilder, manually or with other tools.  But it should be done,
> and since these are the only tools for the purpose I know of, and
> people don't like to do all by hand, I think they are in fact very
> important.

There is also sbuild (which may be used with or without schroot to
manage the chroot).  I prefer it to pbuilder, but I may be a little
biased ;-)


-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please sign and encrypt your mail.


pgpf7yeY9M6tH.pgp
Description: PGP signature

Re: Successful and unsuccessful Debian development tools

[Frank Küster]

Eduard Bloch <[EMAIL PROTECTED]> wrote:

> #include 
> * Marco d'Itri [Tue, Aug 01 2006, 09:53:21AM]:
>> On Aug 01, David Nusinow <[EMAIL PROTECTED]> wrote:
>> 
>> > Also, pbuilder and debootstrap are considered absolutely critical for
>> > serious work.
>> That's a bold statement.
>
> Are you serious? (SCNR ;-)
>
> No, debootstrap is an important toy but but pbuilder is hyped too much.

I think maintainers should really build and test their packages in clean
sid chroots.  It's not important Whether these are set up with
debootstrap or any other method, and whether the handling is done with
pbuilder, manually or with other tools.  But it should be done, and
since these are the only tools for the purpose I know of, and people
don't like to do all by hand, I think they are in fact very important.  

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Successful and unsuccessful Debian development tools

[Aníbal Monsalve Salazar]

On Tue, Aug 01, 2006 at 10:06:05AM +0200, Eduard Bloch wrote:
>#include 
>* Marco d'Itri [Tue, Aug 01 2006, 09:53:21AM]:
>>On Aug 01, David Nusinow <[EMAIL PROTECTED]> wrote:
>>
>>>Also, pbuilder and debootstrap are considered absolutely critical for
>>>serious work.

+= piuparts

>>That's a bold statement.
>
>Are you serious? (SCNR ;-)
>
>No, debootstrap is an important toy but but pbuilder is hyped too much.

Not for me. I use pbuilder and piuparts many times every day.

Aníbal Monsalve Salazar
-- 
http://v7w.com/anibal


signature.asc
Description: Digital signature

Re: Successful and unsuccessful Debian development tools

[Eduard Bloch]

#include 
* Marco d'Itri [Tue, Aug 01 2006, 09:53:21AM]:
> On Aug 01, David Nusinow <[EMAIL PROTECTED]> wrote:
> 
> > Also, pbuilder and debootstrap are considered absolutely critical for
> > serious work.
> That's a bold statement.

Are you serious? (SCNR ;-)

No, debootstrap is an important toy but but pbuilder is hyped too much.

Eduard.

-- 
Arzt: "Gegen ihre Platzangst hilft unter Umständen auch eine Diät!"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[Marco d'Itri]

On Aug 01, David Nusinow <[EMAIL PROTECTED]> wrote:

> Also, pbuilder and debootstrap are considered absolutely critical for
> serious work.
That's a bold statement.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Successful and unsuccessful Debian development tools

[David Nusinow]

On Sun, Jul 30, 2006 at 09:39:26PM +0100, martin f krafft wrote:
> Dear fellow developers,
> 
> As many of you know, I am conducting research on Debian,
> specifically on how Debian developers adopt or reject new methods of
> package maintenance. I would like to get a broad collection of data
> for the first part of my research, which is the study of tools that
> have been successfully adopted or which have been rejected (so to
> speak) by the developer crowd.
> 
> While I already have a good selection, I am on the look for more.
> Do you know of a good example of a tool that has successfully shaped
> Debian development for a large number of people? Or do you remember
> a tool that tried but horribly failed? Those are much harder to
> find. :)
> 
> I have Reply-To set for fear of horrible flame wars when one DD
> bashes another one's favourite tool, but I will make the results
> public, obviously. Thus, I appreciate if you could take the time to
> drop me a short note if you have an opinion on the matter.
> 
> I will be blogging about recent developments some time soon,
> specifically about the change in direction of my research, so watch
> [0] or just read the planet [1] if you are interested.

Subversion, in conjunction with alioth, has risen dramatically in Debian to
accomodate team-based maintainance. There are of course plenty of
challengers, but subversion seems to beat them all.

Also, pbuilder and debootstrap are considered absolutely critical for
serious work.

In terms of failed tools, yada seems to generate a lot of dislike.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[Hendrik Sattler]

Am Montag 31 Juli 2006 17:08 schrieb Frank Küster:
> Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> > Michael Banck <[EMAIL PROTECTED]> writes:
> >> On Sun, Jul 30, 2006 at 09:39:26PM +0100, martin f krafft wrote:
> >>> Do you know of a good example of a tool that has successfully shaped
> >>> Debian development for a large number of people?
>
> [...]
>
> > How about debhelper, debconf, dpatch?
>
> dpatch as an example for both success and non-success:  It's great for
> many applications, but for large source trees other tools, like quilt,
> are superior.

And quilt is much more intuitive to use. Using dpatch is a science for itself.

HS

Re: Successful and unsuccessful Debian development tools

[Frank Küster]

Goswin von Brederlow <[EMAIL PROTECTED]> wrote:

> Michael Banck <[EMAIL PROTECTED]> writes:
>
>> On Sun, Jul 30, 2006 at 09:39:26PM +0100, martin f krafft wrote:
>>> Do you know of a good example of a tool that has successfully shaped
>>> Debian development for a large number of people? 
[...]
> How about debhelper, debconf, dpatch?

dpatch as an example for both success and non-success:  It's great for
many applications, but for large source trees other tools, like quilt,
are superior.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Successful and unsuccessful Debian development tools

[martin f krafft]

also sprach martin f krafft <[EMAIL PROTECTED]> [2006.07.30.2139 +0100]:
> I have Reply-To set for fear of horrible flame wars when one DD
> bashes another one's favourite tool, but I will make the results
> public, obviously. Thus, I appreciate if you could take the time to
> drop me a short note if you have an opinion on the matter.

First of all, thanks to all who have replied so far!

I have much to learn still; at Stefano Zacchiroli's suggestion, I've
started a page on the wiki, which should probably provide for better
exchange.

  http://wiki.debian.org/madduck/adoptions

Feel free to add whatever you may have to say. I'd appreciate if you
could identify all additions/comments with your name.

Thanks,

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
your eyes are weary from staring at the CRT. you feel sleepy. notice
how restful it is to watch the cursor blink. close your eyes. the
opinions stated above are yours. you cannot imagine why you ever felt
otherwise.


signature.asc
Description: Digital signature (GPG/PGP)

Re: Successful and unsuccessful Debian development tools

[Goswin von Brederlow]

Michael Banck <[EMAIL PROTECTED]> writes:

> On Sun, Jul 30, 2006 at 09:39:26PM +0100, martin f krafft wrote:
>> Do you know of a good example of a tool that has successfully shaped
>> Debian development for a large number of people? 
>
> CDBS and alioth/svn.debian.org.
>
>
> HTH,
>
> Michael

With cdbs as negative and alitoh/svn as positive?

How about debhelper, debconf, dpatch?

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Successful and unsuccessful Debian development tools

[Michael Banck]

On Sun, Jul 30, 2006 at 09:39:26PM +0100, martin f krafft wrote:
> Do you know of a good example of a tool that has successfully shaped
> Debian development for a large number of people? 

CDBS and alioth/svn.debian.org.


HTH,

Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Successful and unsuccessful Debian development tools

[martin f krafft]

Dear fellow developers,

As many of you know, I am conducting research on Debian,
specifically on how Debian developers adopt or reject new methods of
package maintenance. I would like to get a broad collection of data
for the first part of my research, which is the study of tools that
have been successfully adopted or which have been rejected (so to
speak) by the developer crowd.

While I already have a good selection, I am on the look for more.
Do you know of a good example of a tool that has successfully shaped
Debian development for a large number of people? Or do you remember
a tool that tried but horribly failed? Those are much harder to
find. :)

I have Reply-To set for fear of horrible flame wars when one DD
bashes another one's favourite tool, but I will make the results
public, obviously. Thus, I appreciate if you could take the time to
drop me a short note if you have an opinion on the matter.

I will be blogging about recent developments some time soon,
specifically about the change in direction of my research, so watch
[0] or just read the planet [1] if you are interested.

0. http://blog.madduck.net/phd
1. http://planet.debian.org

Thanks,

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"i have smoked pot. it is a stupid business, like masturbation."
 -- thomas pynchon


signature.asc
Description: Digital signature (GPG/PGP)