Re: an idea for next generation APT archive caching

[Robert Collins]

On Sat, 2004-10-23 at 12:57 -0500, Manoj Srivastava wrote:
> On Fri, 22 Oct 2004 23:04:32 -0700, Matt Zimmerman <[EMAIL PROTECTED]> said: 
> 
> > On Wed, Oct 20, 2004 at 02:11:44AM +0200, martin f krafft wrote:
> >> Here's an idea I just had about apt-proxy/apt-cacher NG. Maybe this
> >> could be interesting, maybe it's just crap. Your call.
> 
> > My position on special-purpose proxy caches for APT is that
> > general-purpose proxy caches (like squid) seem to work fine for me.
> > What advantages do they have for others?
> 
>   Optimization?  With a special purpose proxies I can control
>  how the cache gets updated. For example, I want to keep two versions
>  of packages I use around -- the current, and the previous one, no
>  matter how old. Hard to do with Squid, which does not know these two
>  files ar4e different versi9ons of the same package. 

It can be taught that. A custom cache replacement policy, for one cache
dir, for example.

Rob

-- 
GPG key available at: .


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

Re: ITP: lapispuzzle.app -- almost a clone of Street Puzzle Fighter

[Robert Collins]

On Mon, 2004-12-06 at 19:18 +0100, Florian Weimer wrote:
> * Gürkan Sengün:
> 
> > * Package name: lapispuzzle.app
> >   Version : 0.9.1
> >   Upstream Author : Banlu Kemiyatorn <[EMAIL PROTECTED]>
> > * URL : http://home.gna.org/garma/lapispuzzle/index.html
> > * License : GNU GPL
> >   Description : almost a clone of Street Puzzle Fighter
> >  Lapis Puzzle is a game that is almost a clone of Street Puzzle
> >  Fighter (TM). If you can't figure out the rule, press A on start
> >  and learn from machine vs. machine mode. 
> 
> If "Street Puzzle Fighter" is a trademark, you shouldn't use it to
> advertise a competing product.

Why not? Happens all the time.

Rob

-- 
GPG key available at: .


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

Re: Automated testing - design and interfaces

[Robert Collins]

On Thu, 2005-11-17 at 14:36 -0800, Steve Langasek wrote:
> [let's get this over to a technical list like it was supposed to be ;)]

> > Following your exit status based approach you could add to stanzas
> > something like:
> 
> >   Expected-Status: 0
> 
> > I found the above requirement the very minimum for a test interface.
> > What follows is optional (IMHO).
> 
> FWIW, I don't see that there's a clear advantage to having the test harness
> *expect* non-zero exit values (or non-empty output as you also suggested).
> It may make it easier to write tests by putting more of the logic in the
> test harness, but in exchange it makes it harder to debug a test failure
> because the debugger has to figure out how "correct" and "incorrect" are
> defined for each test, instead of just getting into the meat of seeing why
> the test returned non-zero.  Likewise, expecting successful tests to be
> silent means that you can rely on any output being error output that can be
> used for debugging a test failure.

Right. Splitting it into two bits ...

with respect to exit code, there is generally only one way to succeed,
but many ways to fail. So reserving 0 for 'test succeeded' in ALL cases,
makes writing front ends, or running the tests interactively much
easier. Its certainly possible to provide a $lang function that can
invert the relationship for you, for 'expected failure' results. One of
the things about expected failures is their granularity: is a test
expected to fail because 'file FOO is missing', or because 'something
went wrong'. The former test is best written as an explicit check, where
you invert the sense in the test script. Its best because this means
that when the behaviour of the failing logic alters - for better or
worse - you get flagged by the test that it has changed. Whereas a
handwaving 'somethings broken' style expected failure really does not
help code maintenance at all. So while it can be useful in the test
interface to have an explicit code for 'expected failure', I think it is
actually best to just write the test to catch the precise failure, and
report success. 

As for silence, yes, noise is generally not helpful, although long
running test suites can usefully give *some* feedback (a . per 100 tests
say) to remind people its still running.

Rob

-- 
GPG key available at: .


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

Re: Automated testing - design and interfaces

[Robert Collins]

On Wed, 2005-11-23 at 18:16 +1000, Anthony Towns wrote:
> On Mon, Nov 21, 2005 at 06:22:37PM +, Ian Jackson wrote:
> > > Note that it's often better to have a single script run many tests, so
> > > you probably want to allow tests to pass back some summary information,
> > > or include the last ten lines of its output or similar. Something like:
> > >   foo FAIL:
> > > FAILURE: testcase 231
> > > FAILURE: testcase 289
> > > FAILURE: testcase 314
> > > 3/512 test cases failed
> > This is no good because we want the test environment to be able to
> > tell which tests failed, so the test cases have to be enumerated in
> > the test metadata file.

Replying to two messages here ...
I don't think we have to enumerate the tests in advance. Sure the test
runner needs to be able to identify and [possibly] categorise the tests,
but explicit enumeration is quite orthogonal. A number of python
unittest runners will scan directories and classes for their tests, and
the report from users is consistently that this is easier to use.

> Uh, having to have 1000 scripts, or even just 1000 entries in a metadata
> file, just to run 1000 tests is a showstopper imho. Heck, identifying
> testcases by number mightn't be particularly desirable in some instances,
> if a clearer alternative like, say, "test case failed: add 1, add 2,
> del 1, ch 2" is possible.

A very nice feature in the xUnit world is that tests can be identified
by either their path (inside the language namespace) or by a comment
written by the author. At runtime you can choose which to see. I dont
think we need the ability for runtime selection, but having a heuristic
that works and is overridable would be nice.

I.e. by default you might get
tests/layout/documentation_in_usr_share_doc.sh: PASS

But inside that test you could say:
test_name Documentation is installed in /usr/share/doc

and the output becomes
Documentation is installed in /usr/share/doc: PASS

I've written a project that is somewhat related to this:
http://www.robertcollins.net/unittest/subunit/

Its a python implementation of a cross process test running protocol.
This lets a sub process run 0 to many tests, identify them and provide
pass/fail/error status and traceback or other diagnostics. As the driver
is python its not appropriate here, but I think the basic
protocol/concept might be useful.

> > You can't check that the binary works _when the .deb is installed_
> > without installing it.
> 
> That's okay. You can't check that the binary works _on the user's system_
> without installing it on the user's system either. For Debian's purposes,
> being able to run the tests with minimal setup seems crucial.

Yup


> It would probably be quite useful to be able to write tests like:
> 
>   for mta in exim4 smail sendmail qmail; do
>  install $mta
>  # actual test
>  uninstall $mta
>   done
> 
> too, to ensure that packages that depend on one of a number of packages
> actually work with all of them.

Yes, that would be excellent.

Rob

-- 
GPG key available at: .


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

Re: Alternate proposal for Declassification of debian-private archives

[Robert Collins]

On Thu, 2005-12-01 at 08:32 -0600, Manoj Srivastava wrote:
> Hi,
> 
> 
...
> - the author and other individuals quoted in messages being reviewed
>   will be contacted, and allowed between four and eight weeks
>   to comment;

I think the default behaviour should be to keep the post private, not to
open it up. That is, if the author and other individuals do not reply,
the message is kept hidden.

The primary reason for this is that the existing messages were sent to
debian-private with an expectation of privacy. Folk that have changed
address or become otherwise not-immediately available may still care,
and the principle of least surprise should apply.

We can however change the expectations for new messages being sent to
debian-private, and in 3 years *they* would become public by default.

Rob

-- 
GPG key available at: .


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

Re: Alternate proposal for Declassification of debian-private archives

[Robert Collins]

On Fri, 2005-12-02 at 12:35 +1000, Anthony Towns wrote:
> (Followups to -vote)
> 
> On Fri, Dec 02, 2005 at 08:30:37AM +1100, Robert Collins wrote:
> > The primary reason for this is that the existing messages were sent to
> > debian-private with an expectation of privacy.
> 
> As Matthew pointed out in [0] this expectation of privacy isn't really
> that strong, fundamentally because -private is open to anyone who joins
> Debian, and Debian's open to anyone joining it.
> 
> [0] http://lists.debian.org/debian-vote/2005/11/msg00033.html

Part of beccoming a member is agreeing to uphold the policies of Debian
- such as the privacy of closed lists. (I don't recall exactly where I
read that, but I do recall reading it).

Current population is what 6 Billion?
Active members ~800 ?

I think there is a freaking huge difference between 'anyone who shows
the interest, effort, sanity and reliability needed to pass NM can read
my posts' and 'Jack The Ripper in outer mongolia can read them.'

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.


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

Re: Trying to reach consensus - Yet Another Alternate Proposal to Declassification of debian-private

[Robert Collins]

On Thu, 2005-12-08 at 00:08 +0100, Gaudenz Steinlin wrote:
> On Wed, Dec 07, 2005 at 02:47:07PM -0300, Daniel Ruoso wrote:
> > So, my conclusion is that it would be nice to have two types of
> > publications:
> > 
> > 1) Selected Readers
> > 2) Selected Content
> > 
> > The first type of publication could embrace the entire content of
> > debian-private, but restrictions will be applied for those who want to
> > read, basically, the need of identification of the reader and the
> > agreement to a NDA on the same terms applied to every debian developer
> > about the privacy of the mailing list.
> > 
> 
> One of the main goals of the original GR was to make the archives
> available for research. How will you be able to publish the results 
> of such research if you agreed to an NDA. One of the main principles
> of scientific research is to make your results reproducible by others.  
> This is impossible if you base your research on data which is only
> available under an NDA.

Its quite possible to publish research conducted under an NDA without
compromising that NDA: but one is constrained in the quotes and
disclosure you can make.

As for being reproducible by others, the suggested process for getting
access seems to be so trivial any researcher with access to the internet
will be able to complete it fairly easily. It also is not under onerous
terms (such as MS's kerberos extensions were) so entering into the NDA
should not limit or pose an unreasonable burden on anyone.

Rob

-- 
GPG key available at: .


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

Re: pbuilder: cowdancer/cowbuilder status update

[Robert Collins]

On Fri, 2006-01-13 at 07:27 +0900, Junichi Uekawa wrote:
> Hi,
> 
> This is an update on using userland COW method with pbuilder.
> 
> cowdancer is a tool that allows you to "cp -al" (hardlink) a tree, and
> break the hardlink when a write-open to a file is performed. The
> adventurous part of cowdancer COW implementation is that it's trying
> to do this from within userland only.
> 
> cowbuilder doesn't really exist yet; it's a name for pbuilder ported
> to fully use cowdancer. cowdancer is under development, and Debian
> package exists in unstable. It seems like it's getting nearly there
> with the feature set. With version 0.8, performance is improved
> against a large tree (I profiled against building the kernel), and
> with version 0.9, I fixed a bug which you could not replace /lib/ld.so
> while cowdancer was running.

Are you aware of fl-cow, which is a LD_PRELOAD userspace COW tool ?

Rob

-- 
GPG key available at: .


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

Re: pbuilder: cowdancer/cowbuilder status update

[Robert Collins]

On Fri, 2006-01-13 at 08:42 +0900, Junichi Uekawa wrote:
> Hi,
> 
> > > This is an update on using userland COW method with pbuilder.
> > > 
> > > cowdancer is a tool that allows you to "cp -al" (hardlink) a tree, and
> > > break the hardlink when a write-open to a file is performed. The
> > > adventurous part of cowdancer COW implementation is that it's trying
> > > to do this from within userland only.
> > > 
> > > cowbuilder doesn't really exist yet; it's a name for pbuilder ported
> > > to fully use cowdancer. cowdancer is under development, and Debian
> > > package exists in unstable. It seems like it's getting nearly there
> > > with the feature set. With version 0.8, performance is improved
> > > against a large tree (I profiled against building the kernel), and
> > > with version 0.9, I fixed a bug which you could not replace /lib/ld.so
> > > while cowdancer was running.
> > 
> > Are you aware of fl-cow, which is a LD_PRELOAD userspace COW tool ?
> 
> It seems to be the tool with a same kind of goal. If I knew it
> existed, I might have started from it. However, it only supports
> 'open', so it will have problems when used with pbuilder; for example,
> file permissions are shared between files with same i-nodes.  The
> scope of implementation between the two applications is a bit
> different.
...
> Considering the difference, it might be better to improve desciprtions
> of both packages.
> 
> 
> 
> Another difference I noticed is that fl-cow takes a list of
> directories to protect in FL_COW, and seems to copy files
> unconditionally on 'open'.
> 
> cowdancer caches a list of i-nodes so that it won't try to break
> hardlinks more than once. (cow-shell does this much work).

Nice. I'm not sure both tools need to be in debian. How mature is
cowdancer - can it replace fl-cow at this point? (fl-cows primary use is
to be told 'these paths may contain hardlinked files, please unhardlink
any of them on write').

Rob

-- 
GPG key available at: .


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

Re: [ad-hominem construct deleted]

[Robert Collins]

On Mon, 2006-01-16 at 19:21 -0500, Joey Hess wrote:
> > but I agree with it.  I would also say that Debian's upstreams are, in the
> > same sense, Debian developers. 
> 
> I think that we probably have hundreds of upstreams who would react with
> everything from disbelief to anger if Debian claimed that as a blanket
> statement.

And yet most upstreams can get pretty much arbitrary code into Debian,
just by committing it?. How many DD's read the -entire- diff on major
version upgrades from upstream. And not just read, audit.

Rob

-- 
GPG key available at: .


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

Re: Andrew Suffield

[Robert Collins]

On Wed, 2006-01-18 at 20:44 +, Dallam Wych wrote:
> On Sun, Jan 15, 2006 at 05:09:03PM -0600, Joe Wreschnig wrote:
> > On Sun, 2006-01-15 at 06:28 -0500, sean finney wrote:
> > > On Sun, Jan 15, 2006 at 11:58:51AM +0100, Adrian von Bidder wrote:
> > > > Do you think your constant bitching is funny?  Do you think it achieves 
> > > > anything?
> > > > 
> > > > There are other DDs who are also involved in intense debates and 
> > > > flamewars 
> > > > very often, but you're the only one  where I constantly get the 
> > > > impression 
> > > > that you're just being childish, insulting and annoying for the sake of 
> > > > it.
> > > 
> > > ...says someone who just publicly ostracized a fellow dd
> > > on a public mailing list.  personal opinions of the matter aside,
> > > debian-devel is not the place for ridiculing other developers, no
> > > matter how justified you feel you may be. 
> > > 
> > > please post follow-ups to -private.
> > 
> > I said this on -private, and I'll say it here -- why is it appropriate
> > to be an ass on -private, but not on -devel? It's not appropriate
> > anywhere. That goes for Adrian, and Andrew, and everyone. It also leads
> > to situations like the present, where it looks like we're doing nothing
> > to reprimand offensive behavior, because most conversation is happening
> > on -private, while the original, offensive message is sitting on d-d-a.
> > 
> > If you are upset by how Andrew acted, talk to him rationally, regardless
> > of whether it's public or private.
> > 
> > If you are *very* upset by how Andrew acted, there is an appropriate and
> > agreed-to policy for expelling developers. Roger Leigh has mentioned his
> > interest in seeing this through; contact him.
> > -- 
> > Joe Wreschnig <[EMAIL PROTECTED]>
> 
> I imagine that the ubuntu people, which include those on canonicals
> payroll that are posting to this list, are really finding this kind of discord
> within the Debian community quite comical and amusing.

No more or less comical or amusing than I found it before Canonical was
started. Which is to say, neither comical nor amusing.

Rob

-- 
GPG key available at: .


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

Re: when and why did python(-minimal) become essential?

[Robert Collins]

On Sat, 2006-01-28 at 19:27 +0100, Josselin Mouette wrote:
> Le samedi 28 janvier 2006 à 19:18 +0100, Wouter Verhelst a écrit :
> > > This is only a feature for perl maniacs. A language that requires a
> > > specific coding style is better, because it makes possible for anyone
> > > knowing the language to hack easily python code he doesn't know about.
> > 
> > Hah. A language that does not require a specific coding style is better,
> > because it allows me to work as is the most efficient for me.
> 
> Which is globally counterproductive. When you're in a project, you have
> to deal with the fact other people are working on it as well. That's why
> large projects like Linux or GNOME require a specific coding style for
> their contributions. For python-based projects, this isn't even
> necessary, as most if not all python programmers already use the same
> coding style.



Have a look inside the standard library sometime, if you want to get a
feeling for just how many styles of programming python programmers use. 

Rob

-- 
GPG key available at: .


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

Re: PROPOSAL: debian/control file to include new License: field

[Robert Collins]

On Tue, 2006-02-21 at 03:54 -0500, Kevin Mark wrote:
> On Tue, Feb 21, 2006 at 02:35:52AM -0600, Peter Samuelson wrote:
> > 
> > [Kevin Mark]
> > > would it provide any automation or easier processing for the NEW
> > > queue(ftpmasters)?
> > 
> > I doubt it.  They don't take the maintainer's word for stuff like that,
> > as I understand it - they double-check the copyright and license
> > declarations in the source code.
> You mean they check ever single time $RANDOM_PACKAGE enter NEW and don't
> assume its correct until someone raises an objections? 

Yes. Legal compliance is /not/ tractable in the same way that software
bugs are.

Rob

-- 
GPG key available at: .


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

Re: Linda warnings

[Robert Collins]

On Mon, 2005-05-30 at 03:33 -0400, Eric Dorland wrote:
> * Tollef Fog Heen ([EMAIL PROTECTED]) wrote:
>  
> > Because we want to test for buildability.  We want to make it possible
> > to change any part of the program and barring real errors, it should
> > still build.  That upstream writes crap configure.in/.ac and
> > Makefile.ams is not an excuse, it's just a bug which should be fixed.
> 
> Well I don't disagree. But either we test every auto* using package
> this way, or we don't. The auto* tools are designed specifically so
> that they are not build dependencies. So making it a build dependency
> seems like a kludge. Now if we wanted to make it a general policy to
> test whether auto* regeneration works then I have less problem with
> that, but it would be a lot more work, for very little benefit that I
> can see.   

The auto* tools are only /not/ a build dependency when one does not
change the code. They are explicitly a build dependency for developers.

We and the buildds do *not count* as end users - we are patching the
code in most cases.

So either you don't patch the package, or you be willing to require the
relevant auto* be installed.

Rob

-- 
GPG key available at: .


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

Re: Is Ubuntu a debian derivative or is it a fork?

[Robert Collins]

On Wed, 2005-06-01 at 00:06 -0500, John Goerzen wrote:

> BTW, the baz folks could get some very neat ideas from darcs.  The
> "offline mode comes free" way of working is very nice, and the
> branching being easier than Arch is nice, too.

We have .. we're about 3 releases (~3 months) away from a full
pull-style checkout that will bring all the history and be branchable
via a simple cp.

This is part of our convergence with the bzr design, as bzr proves each
point we're bringing it into baz - quite successfully so far.

Cheers,
Rob

-- 
GPG key available at: .


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

Re: Is Ubuntu a debian derivative or is it a fork?

[Robert Collins]

On Tue, 2005-06-07 at 09:48 -0500, John Goerzen wrote:

> IMHO, it's a bug if it doesn't work efficiently without specialized
> assistance from shell completions.

Yup. I deliberately use baz without shell completions for just this
reason. If something annoys me, it gets fixed;).

Cheers,
Rob

-- 
GPG key available at: .


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

Re: And now for something completely different... etch!

[Robert Collins]

On Thu, 2005-06-09 at 09:25 +1000, Matthew Palmer wrote:
> On Thu, Jun 09, 2005 at 01:13:16AM +0200, Javier Fernández-Sanguino Peña 
> wrote:
> > to find their own (sometimes flawed) solution to a very common problem. 
> 
> Years using Linux: 10.
> 
> Times I've absolutely needed an X-less boot when an XDM was installed: 0.
> 
> How common was that problem you were trying to solve, again?

Its not frequency but impact. In, oh, 94, I had a linux box that started
hard locking when the *DM started. Having a X-less, networked startup
config in lilo was a life saver.

The cost of having a networked, X-less rc level is pretty darn low. Why
do you not want one ?

Rob

-- 
GPG key available at: .


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

Re: HashKnownHosts

[Robert Collins]

On Sun, 2005-07-03 at 18:36 +0200, Martijn van Oosterhout wrote:

> One case I can think of is where you regularly ssh into a machine with
> a dynamic IP address. Maybe with or without a dyndns name. Depending
> on the size of the ISP and how often the address changes the
> known_hosts files could increase without bound.

Theres a ~/.ssh/config option for that. HostsKeyAlias or something.

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)

[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: Centralized darcs (was Re: centralized bzr)

[Robert Collins]

On Tue, 2006-08-01 at 14:55 -0500, John Goerzen wrote:
> On Tue, Aug 01, 2006 at 08:31:37PM +0200, Adeodato Simó wrote:
> > 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".
> 
> I would say that this goes for darcs as well, but even more.
> 
> Darcs has a nice way of pushing patches via e-mail, with GPG signatures
> even.  These can be processed in an automated way on the server,
> verified against, for instance, the Debian keyring, and then applied to
> the repository.
> 
> I think it would work even nicer.

Its somewhat indirect though. bzr has an equivalent system too (called
pqm) which accepts GPG-signed merge requests and applies them to the
repository. FWIW.

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)

[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: 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: <http://www.robertcollins.net/keys.txt>.


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

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)

[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: <http://www.robertcollins.net/keys.txt>.


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

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)

[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: <http://www.robertcollins.net/keys.txt>.


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

Re: dh_python and python policy analysis

[Robert Collins]

On Sun, 2006-08-13 at 19:56 -0500, Manoj Srivastava wrote:
>Here there are two cases. Either module foo can't be written at all
>for version 2.6, or it the same functionality can be provided with


This is a little simplistic.

The parser changes fairly routinely in python versions. This means that
a version conditional is not sufficient to provide compatability with
older pythons - the module will not parse.

The usual thing done for cross version support is to write in the older
version of python, or in extreme cases (i.e. where performance really
hurts) have two separate modules _foo_2_5 and _foo_2_6 and conditionally
do
'from _foo_2_5 import *' etc.

-Rob
-- 
GPG key available at: .


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

Re: XS-X-Vcs-XXX field not (yet) announced

[Robert Collins]

On Sat, 2006-09-23 at 04:21 -0500, Manoj Srivastava wrote:


> URL's are not what would be needed.
> 
> The information that is required could possibly be couched
>   like so (RFC 2822 field folding) (for flex in stable)
> ,
> | XS-VCS-ARCH-Repo:  [EMAIL PROTECTED]
> | http://arch.debian.org/arch/private/srivasta/archive-2003
> | XS-VCS-ARCH-CONFIG:
> |  ./flex/flex-2.5.31 
> |   [EMAIL PROTECTED]/flex--devo--2.5--versionfix-3
> |  ./flex/flex-2.5.31/debian
> |   [EMAIL PROTECTED]/debian-dir--flex--1.0--versionfix-4
> |  ./flex/flex-2.5.31/debian/common
> |   [EMAIL PROTECTED]/skeleton-make-rules--main--0.1--patch-13
> `
> 
> Hmm. This still does not provide a pointer to my archive gpg key.
>  XS-VCS-ARCH-GPG-KEYID: 0x40612C84

config-manager supports reading a config straight out of the VCS:
http://arch.debian.org/arch/private/srivasta/archive-2003/dists--debian--0/flex/flex-2.5.31.config

(for instance).

URI's accept parameters:
http://arch.debian.org/arch/private/srivasta/archive-2003;gpg-keyid=0x40612c84/dists--debian--0/flex/flex-2.5.31.config

(again, this is a for instance).

-Rob
-- 
GPG key available at: .


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

Re: XS-X-Vcs-XXX field not (yet) announced

[Robert Collins]

On Tue, 2006-09-26 at 14:16 -0500, Manoj Srivastava wrote:
> On Sun, 24 Sep 2006 17:40:54 +1000, Robert Collins
> <[EMAIL PROTECTED]> said:  
> 
> > config-manager supports reading a config straight out of the VCS: 
> > http://arch.debian.org/arch/private/srivasta/archive-2003/dists--debian--0/flex/flex-2.5.31.config
> 
> But that would involve checking out the category which
>  contains the configs, or putting up the config file on a web page
>  (separately from the repository), and ensuring that the web page is
>  kept in sync, unless I am mistaken,

Yes. Storing the configs in version control is usually a good idea,
because that lets you have a versioned record of the exact composition
of the combined trees. (i.e. the debian subtree @ revision 42, the flex
source tree @ revision 12)

> > URI's accept parameters:
> > http://arch.debian.org/arch/private/srivasta/archive-2003;gpg-keyid=0x40612c84/dists--debian--0/flex/flex-2.5.31.config
> 
> Hmm.  Very interesting. 
>The path may consist of a sequence of path segments separated by a
>single slash "/" character.  Within a path segment, the characters
>"/", ";", "=", and "?" are reserved.  Each path segment may include a
>sequence of parameters, indicated by the semicolon ";" character.
>The parameters are not significant to the parsing of relative
>references.

yup. Not widely used today, but extremely :).

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.


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

Re: XS-X-Vcs-XXX field not (yet) announced

[Robert Collins]

On Thu, 2006-10-05 at 17:49 +0200, Stefano Zacchiroli wrote:
> 
> Ok, then please propose a patch for:
> 
>   http://svn.debian.org/wsvn/qa/trunk/pts/www/bin/common.py?op=file
> 
> I think it would be quicker for you to propose it, than for me to
> actually find out the pedigree of bzr wrt tla/arch/... :) 

There is no pedigree of bzr wrt tla/arch.

'baz' is a fork of tla. 'baz' and 'tla' are both implementations of
'arch'.

'bzr' is a wholly different codebase/protocol/system.

-Rob
-- 
GPG key available at: .


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

Re: "Arch: all" package FTBFS due to test needing network access - RC?

[Robert Collins]

On Tue, 2006-10-31 at 23:16 -0800, Steve Langasek wrote:
> On Wed, Nov 01, 2006 at 08:02:22AM +0100, Lucas Nussbaum wrote:
> > While I fully agree with you on all points, I think that this should be
> > discussed post-etch with the general question of "in which environment
> > are packages supposed to build ?". There are other similar issue, like:
> > - should packages allow to build as root ? (aegis, bazaar, subversion
> >   don't)
> 
> This question is misphrased; the real question is, "should we require that
> all packages be buildable as root?"  And I don't see any reason the answer
> to this question is "yes".

If anything, I'd like to see a requirement that packages build as
non-root - for the 'run the packages build rules' aspect. 

I can also note why bazaar wont build as root: its test suite includes a
test for the ability to handle read only directories correctly. As root,
anything is writable, so this test fails.

Rob
-- 
GPG key available at: .


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

Re: Moving conffiles between packages, redux

[Robert Collins]

On Sat, 2006-12-23 at 23:04 +, Colin Watson wrote:
> [debian-release: Read this if you care about the details. The executive
> summary is to note that openssh 1:4.3p2-8 corrects an RC bug and should
> be hinted into testing if its five days expire without any new RC bugs;
> also that all other packages that have had to deal with moving conffiles
> between packages may be affected by a similar problem depending on
> whether they're upgraded with sarge's dpkg or etch's dpkg, and need to
> be reviewed and corrected before release.]
...
> Fortunately, all of this is only necessary for upgrades from sarge to
> etch, and once we can expect everyone to have etch's dpkg installed we
> can move conffiles between packages more or less like any other files.

is it possible/useful to generate a dh_ command to facilitate this?
Rather than everyone needing to end up encoding the same logic with
minute variations ?

0Rob
-- 
GPG key available at: .


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

Re: Moving conffiles between packages, redux

[Robert Collins]

On Tue, 2006-12-26 at 02:50 -0600, Manoj Srivastava wrote:
> On Tue, 26 Dec 2006 19:23:40 +1100, Robert Collins
> <[EMAIL PROTECTED]> said:  
> 
> > On Sat, 2006-12-23 at 23:04 +, Colin Watson wrote:
> >> Fortunately, all of this is only necessary for upgrades from sarge
> >> to etch, and once we can expect everyone to have etch's dpkg
> >> installed we can move conffiles between packages more or less like
> >> any other files.
> 
> > is it possible/useful to generate a dh_ command to facilitate this?
> > Rather than everyone needing to end up encoding the same logic with
> > minute variations ?
> 
> How often do you think this shall be needed in this release
>  cycle?  Writing a general purpose dh_tool, and getting it tested, is
>  not a simple task (though of course, if you feel the need to scratch
>  that itch, far be it for me to stop you).

Its not just this release cycle though: In any release there are at
least two versions of dpkg to consider w.r.t. moving conf-files around.
So I wasn't proposing that a specific tool be written urgently, but
rather that we consider having one as a standard, and its behaviour can
be adjusted to handle the current previous-release, current-release
pairing of dpkg correctly to facilitate such moves.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.


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

Re: Moving conffiles between packages, redux

[Robert Collins]

On Wed, 2006-12-27 at 12:40 +, Colin Watson wrote:


> But from etch onwards, the job consists of putting the file in a
> different package and adding a Replaces. There'd be nothing for a
> debhelper program to do. Sure, maybe a year ago it would have been worth
> it - but it's now too late to bother.

Ah, I hadn't clicked to that. Cool.

-Rob
-- 
GPG key available at: .


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

Re: How (not) to write copyright files - take two

[Robert Collins]

On Sun, 2006-03-26 at 21:20 -0800, Russ Allbery wrote:
> Charles Plessy <[EMAIL PROTECTED]> writes:
> 
> > I am packaging a program for debian, and wrote a manpage and two patches
> > for making it compile with libwxwindows. I am not very interested in
> > being the author list: I would be a bit ashamed that my name would
> > appear more frequently that the author's for a work which is not mine.
> > Also, I feel a bit lazy and do not want the burden of changing the
> > copyright file whenever one of my modifications is accepted or
> > obsoleted.
> 
> > Is it OK if I release the patches and the manpages in the public domain,
> > and I do not mention the manpage and the patches in the copyright file?
> 
> I recommend always adding an additional section to debian/copyright giving
> an explicit statement about the copyright of the packaging work.  It's
> just good copyright "hygiene," since otherwise people have to make guesses
> and assumptions that may not be correct.

I think thats a good practice.

But I'm not sure that a concordance of individual copyright holders in
the packaging file as asserted earlier in this thread is of significant
use - its certainly hard to maintain (have to check every single file in
every upstream change for new (c) holders), and I'm dubious about the
legal need: Asserting that the copyright is held by the primary authors
and others as listed in the source, or in the projects AUTHORS file if
it maintains one should be sufficient no?

Perhaps we should -> debian-legal?
Rob

-- 
GPG key available at: .


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

Re: Bug#364652: ITP: squid3 -- Internet Object Cache (WWW proxy cache) version 3

[Robert Collins]

On Mon, 2006-04-24 at 20:54 +0100, Stephen Gran wrote:
> This one time, at band camp, Luigi Gangitano said:
> > * Package name: squid3
> > 
> >  This is the Squid Internet Object Cache developed by the National
> >  Laboratory for Applied Networking Research (NLANR) and Internet
> >  volunteers.  This software is freely available for anyone to use.
> > 
> >  This is the new development version, totally rewritten in C++ with the
> >  latest features like ICAP added.
> 
> Is a new source package really needed?  Is there no sensible upgrade
> path?  I had sort of hoped it could be as drop in and go as most
> upgrades are, but perhaps not.
> 
> Take care,

Squid-3 will read the same config file, and the cache directory is
compatible so there is indeed an upgrade path. Its not a total rewrite -
its a port of the squid 2.5 C source to C++, but 

squid 3.0 is not yet 'stable'. Squid 2.5 is still the stable series. And
we (upstream) don't maintain a single source tree - we have one tree for
2.X and one for 3.X. I don't think it makes sense to try and make a
single source package for this. I think you definately want to allow
co-installation though.

After 3.0 is considered stable, you could definately do a 'drop in and
go' approach.

Rob



-- 
GPG key available at: .


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

Re: Bug#364652: ITP: squid3 -- Internet Object Cache (WWW proxy cache) version 3

[Robert Collins]

On Wed, 2006-04-26 at 12:42 +0200, Wouter Verhelst wrote:
> On Wed, Apr 26, 2006 at 11:13:32AM +0200, Luigi Gangitano wrote:
> > Squid 3 is not release ready. And with current plans should not  
> > release with etch. So squid 2.5 needs to stay in unstable/testing at  
> > least until etch is released and can be installed on production  
> > machines.
> 
> Well, then that's exactly what experimental is made for.
> 
> The guideline is "don't upload to unstable if you don't want it in a
> release".

Wearing my upstream hat, I'd like to see squid3 packages that *do not*
conflict or replace squid packages in a release.

Squid3 has many features that are simply not available to squid 2.5, and
I think parallel installs are really quite reasonable. After we release,
there will probably be people that want to stay with 2.5 for a while
anyway, and having a transition period is not harmful IMO.

Squid itself supports parallel installs very well.

Rob

-- 
GPG key available at: .


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

Re: [Debconf-discuss] Please revoke your signatures from Martin Kraff's keys

[Robert Collins]

On Fri, 2006-05-26 at 15:45 -0700, Thomas Bushnell BSG wrote:
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
> 
> > I think the core issue here is if we deem presenting purchased
> >  identification at an event designed to extend the web of trust
> >  acceptable behaviour.
> 
> I don't think anyone has said that it's satisfactory.
...


Don't know about you, but I had to pay to get my passport.

Rob
-- 
GPG key available at: .


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

Re: Alternative keysigning procedures

[Robert Collins]

On Sun, 2006-05-28 at 19:23 -0500, martin f krafft wrote:
> Taking this to debian-devel...
> 
> also sprach Andrew McMillan <[EMAIL PROTECTED]> [2006.05.28.1840 -0500]:
> > (c) Allocate partcipants to the groups in a round robin following
> > centrality order and starting with the most central.
> 
> This sounds great. We might want to consider letting people with
> experience specifically opt in for the educational part. I don't
> think it's a good idea to just assume that central people will be
> happy to show up and explain.
> 
> Also, what do we do if the central people don't show up? It's been
> known to happen at KSPs.

Run the allocator routine again ?

Rob

-- 
GPG key available at: .


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

Re: Please notify your rdepends' maintainers if you break an interface

[Robert Collins]

On Sat, 2005-08-13 at 13:31 +0200, Marc 'HE' Brockschmidt wrote:
> Hi,
> 
> After I invested an hour so to track down the reason for an evil FTBFS,
> I have a very simple request: If you maintain a library that gets used
> by other people and you break the API, you should notify
> them. Really. It makes life easier. For the usual C/C++ libraries its
> not that complicated, as SONAME changes lead to new package names and
> everything is fine. 
> But if you maintain something like a perl library, you should either the
> change the fscking package name if you break the API or file a bug
> against all packages that depend on your lib.
> 
> And no, it's enough to write "NOTE: This release breaks API. Please see
> Changes for further details." in your changelog.

Unfortunately, its often up to the upstream whether this happens or
not ... Certainly if one knows, being proactive about it is important.

On a related note, should we consider defining a convention similar to
soname for dynamic languages like perl/python etc? I.e. for a python
library 'foo', install the code as 'foo1', and have a dummy package
'foo' which has a __init__.py containing 'from foo1 import *' ?

This wouldn't deliver all the benefits of sonames - particularly it
wouldn't automatically resolve to 'foo1' at runtime, but it would allow
concurrent installs of foo1 and foo2.

Cheers,
Rob

-- 
GPG key available at: .


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

Re: version numbering

[Robert Collins]

On Fri, 2005-08-19 at 00:52 +0200, martin f krafft wrote:
> also sprach Lars Bahner <[EMAIL PROTECTED]> [2005.08.18.2346 +0200]:
> > Please CC: me as I am not on this list!
> 
> Please consider setting Mail-Followup-To accordingly.
> 
> > Upstream names the betas for 0.7.3.3 as 0.7.3.3.b1-b30 - as you no
> > doubt already guessed.
> 
> This is why we now have the ~ operator.
> 
> > So now that there is no beta-versioning, the installer sees this
> > as a lower number. I could of cource number the package as
> > 0.7.3.3.c or 0.7.3.3.final, but I was wondering what The Right
> > Thing To Do would be.
> 
> I think you have to resort to an epoch. Using 0.7.3.3.final seems
> okay to me too. I don't think there is a Right Way.

I think the ~ is the Right Way.
0.7.3.3~b1 < 0.7.3.3~b30 < 0.7.3.3

Cheers,
Rob
-- 
GPG key available at: .


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

Re: arch, svn, cvs

[Robert Collins]

On Sat, 2005-08-20 at 21:00 +0200, Florian Weimer wrote:

> >> Greg Hudson contributes an interesting viewpoint:
> >> 
> >>   
> >
> > Well written, but does it contribute to our discussion here? Arch
> > and Baz can both be used centrally, and with a group of committers.
> > It might not scale as well right now, but efforts in the direction
> > of automated patch integration systems promise to close this gap.
> > See for instance the patch queue manager project[0].
> >
> > 0. http://web.verbum.org/arch-pqm/
> 
> arch-pqm still requires that people publish their own repositories.
> This is often a challenge for people behind firewalls.

pqm supports mailing a unified diff straight into the repository. I.e. 
echo -e "patch\\n$(baz diff)" | mail -s 'fix foo-bar'
[EMAIL PROTECTED]

> If arch-pqm took advantage of the GNU arch capabilities and accepted
> signed changesets instead of merge requests, things would be quite
> different.  Such an option exists for darcs, but I haven't used it.
> It still doesn't provide the satisfaction of immediate feedback, I
> fear.

I haven't implemented a changeset based option, it would be quite easy
if someone wants to do it.

Cheers,
Rob


-- 
GPG key available at: .


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

Re: arch, svn, cvs

[Robert Collins]

On Wed, 2005-08-31 at 00:04 +1200, Martin Langhoff wrote:
> On 8/20/05, Florian Weimer <[EMAIL PROTECTED]> wrote:
> > > Compared to SVN from the view of somebody who is acquainted with CVS,
> > > arch sucks badly. I tend to agree with most of the things that Florian
> > > Weimer lists on http://www.enyo.de/fw/software/arch/design-issues.html
> 
> To which I'd respond that Arch fills a very different niche, closer to DARCS.
> 
> But I'm leaving the Arch (tla/baz/bzr) boat too - patch-oriented SCMs
> were fun, but very disappointing. There is a central design flaw in
> pure patch tracking, and neither Arch nor DARCS do anything about it:
> no matter how much you track patches merged, you need to be able to
> identify convergence. GIT does this so well by being
> identity-oriented, that you can do a ton of patch trading on top (via
> email, StGIT, quilt, whatever) and things still make sense after
> merging and remerging ad infinitum.

for the record, to avoid other folk getting confused - bzr isn't a
'patch orientated SCM'. bzr's design incorporates elements from all of
the VCS systems around when the project was started (and updated since
then) - its not derived from GNU Arch any more or less than its derived
from monotone or subversion.

Cheers,
Rob

-- 
GPG key available at: .


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

Re: arch, svn, cvs

[Robert Collins]

On Wed, 2005-08-31 at 15:25 +1200, Martin Langhoff wrote:
> On 8/31/05, Robert Collins <[EMAIL PROTECTED]> wrote:
> > for the record, to avoid other folk getting confused - bzr isn't a
> > 'patch orientated SCM'. bzr's design incorporates elements from all of
> > the VCS systems around when the project was started (and updated since
> > then) - its not derived from GNU Arch any more or less than its derived
> > from monotone or subversion.
> 
> Fair enough... except that it is being promised as the natural upgrade
> path for tla/baz users. I don't claim to understand the architectural
> decisions in bzr, but it is a pretty serious constraint. It forces bzr
> to support the core assumptions of the Arch model.

Not at all. I'll reply to madduck with more stuff on the design
internals tomorrow. But as for being forced to support the core
assumptions of the arch model - bah.

bzr will support upgrades by converting the data from the arch archives
to individual bzr branches. These branches are not able to be converted
back to Arch archives - its a one way trapdoor. The presence of the
trapdoor is what lets Bazaar-NG not support the core assumptions of the
Arch model.

Aaron Bentley has already written a baz2bzr tool and I'll be knocking
the edges of that in the next month and a half.

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.


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

Re: arch, svn, cvs

[Robert Collins]

On Wed, 2005-08-31 at 00:17 +0200, martin f krafft wrote:
> Could you please elaborate on this?

Hmm. Where to start :0. perhaps with storage. bzr currently stores the
different variations of each file that is versioned in 'stores', which
are a collection of files named by their hash, gzipped. (Its been doing
this since January). We're about to migrate to using a thing called a
'weave', which linear time annotation with respect to the number of line
variations in a file. Once we've done this transition, the storage will
look somewhat like sccs. When a commit occurs, a minimum of 2 file
alterations occur:
- we create a new 'revision' file which records the date, user, log
message, and a reference to an inventory of the tree at the time of the
commit.
- we append the hash of the revision to the revision-history file in
the .bzr directory.
- If the shape of the tree has changed - if files have been altered or
added or deleted - then we record a new inventory for the tree, which
has the full shape of the tree. The storage we use works fine on
windows, Mac OS X, and on Un*x. It also works happily over sftp and http
- no smart server is required. (We have plans for an optional smart
server post release).

So this looks rather like a 'snapshot' based system. However, we use
persistent unique file identifiers to track renames and to allow merging
between branches with files that have been renamed, without needing to
calculate back in time for the current name of the file. (This was one
of the key things GNU Arch does that bazaar-NG has incorporated).

Merges are tracked at both the file and revision level - a file has
ancestors of its own. Thus the system can represent a merge of a single
file from a remote branch without a full merge occuring, OR a partial
merge where some changes are deferred - neither rejected nor accepted.
We haven't taken full advantage of this capability yet, but I think it
will make working with cherry picking scenarios very enjoyable.

Branches are identified by value - if two branches have the same
revision-history they are identical, we can identify common prefixes to
identify where divergence has occured, and with the symmetrical parents
of revisions we can join branches up again when they have converged.

Branching can be as simple as a 'cp -al' from one directory to another,
or you can use the builtin 'branch' command which brings over only the
history for the one branch to your new branch ('stores' can share data
for many branches).

What else - oh, we have plain text diffs for use in sending to mailing
lists, there is no namespace for branches - you manage them just like
one can manage directories on disk, we're optimising for the common case
in most operations (though identifying that can be troublesome). We have
designs for supporting a 'CVS-style' operation where there is a common
branch many people commit directly to. The library code essentially
supports this now, but there is no UI to configure a tree to use it.

Hope this helps..
Rob

-- 
GPG key available at: .


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

Re: Bug#463167: ITP: dsyslog -- a dumb syslog

[Robert Collins]

On Tue, 2008-01-29 at 19:07 -0600, William Pitcock wrote:
> Hi,
> 
> On Tue, 2008-01-29 at 18:54 -0600, Ron Johnson wrote:
> > >  dsyslog is a dumb, yet advanced syslog daemon, which supports
> > infinite
> > >  rules and expandability through it's purely modular design. The
> > default
> > >  configuration is a drop in replacement for syslogd.
> > 
> > What's so dumb about that?
> 
> It's not that it's actually dumb, it's like how git is called the
> "stupid content tracker" by it's documentation. It's intended to be a
> joke.

Users are very good at missing these jokes.

-Rob
-- 
GPG key available at: .


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

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Robert Collins]

On Sun, 2008-02-24 at 16:46 -0300, Henrique de Moraes Holschuh wrote:
> Yet, rebasing is still routinely performed in the Linux kernel
> development. 

What I find interesting and rather amusing here is Linus talking
negatively about rebase: in particular its propensity to turn tested
code (what you actually committed) into untested code (what you
committed + what someelse has done, in a version of a tree no human has
ever evaluated for correctness).

-Rob

-- 
GPG key available at: .



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

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Robert Collins]

On Mon, 2008-02-25 at 17:58 +, James Westby wrote:
> On Mon, 2008-02-25 at 10:19 -0600, John Goerzen wrote:
> > "Dirty history" is not only tolerated, but the *only* sane option with, 
> > lesse...  rcs cvs svn darcs tla baz (bzr?)
> 
> bzr supports both ways of working, either cleaning up, or preserving
> the history as is.
> 
> It has rebase support through a plugin, but I don't think it's widely
> used yet.

The bzr community doesn't encourage rebase because of the destructive
effect it has on collaboration - and at least the authors of bzr
consider one of its primary goals being to enable collaboration between
software authors.

So rebase is there for folk that need it, but its not the recommended
solution to the various problems mentioned in this thread.

-Rob
-- 
GPG key available at: .
> 


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

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Robert Collins]

On Sun, 2008-03-02 at 02:09 -0300, Henrique de Moraes Holschuh wrote:


> And I am completely *sure* it would not be irrelevant for me were I
> debugging dpkg without a full, complete, dpkg-regular-developer level of
> understanding of the code.   Or if I were trying to understand how dpkg
> works, so as to start working on dpkg, for that matter.

Well, when I sat down some years back to do a couple of things with
dpkg; I found no need to consult change logs to understand the current
code of the time. Perhaps its quality has massively decreased since; yet
somehow I doubt that.

-Rob
-- 
GPG key available at: .


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

Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)

[Robert Collins]

On Sat, 2008-03-01 at 11:18 -0600, Manoj Srivastava wrote:
> 
> Now, having bisecability could be useful (I have never used a
>  bisect);  I don't know what the effect of a version that does not
>  compile or is otherwise buggy would have on the work flow.

Depending on the treatment of branches by the bisection tool it can
cause false reports of the origin of a defect; this then increases the
manual effort needed to find a problem.

-Rob

-- 
GPG key available at: .


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

Re: triggers wishlist

[Robert Collins]

On Mon, 2008-03-31 at 00:54 +0200, Cyril Brulebois wrote:
> On 30/03/2008, Michael Biebl wrote:
> > I don't understand, why it shouldn't be possible, that a single
> > update-rc.insserv run, reoders *all* init scripts in one go. You could
> > still skip the ones, which will cause loops or have no dependency
> > information.
> 
> I guess the algo is currently “there's no loop; try and add foo; if a
> loop is introduced, foo is guilty; otherwise, be happy”. If you don't
> have the “we're trying to add foo” bit, I guess it's hard (if possible
> at all) to find which package(s) is/are guilty.

Huh, pretty straight forward - use tarjans method, get the strongly
connected sets, and you can dump out the loops immediately. If you want
to be able to say 'package X is at fault' - well, adding packages one by
one does not tell you that - the loop exists in the archive, adding
packages one by one only tells you when you have pulled in enough to
show the loop.

-Rob

-- 
GPG key available at: .


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

Re: triggers wishlist

[Robert Collins]

On Mon, 2008-03-31 at 08:37 +0200, Petter Reinholdtsen wrote:
> [Michael Biebl]
> > I don't understand, why it shouldn't be possible, that a single
> > update-rc.insserv run, reoders *all* init scripts in one go. You
> > could still skip the ones, which will cause loops or have no
> > dependency information.
> 
> Well, there are two things that need to be done as insserv work today:
> 
>  - Call update-rc.d in dependency order when adding new scripts to the
>boot sequence (one call is not going to work).  It refuses to
>install a script (and in consequence, the package) if the scripts
>hard dependencies are not already inserted into the boot sequence.
> 
>  - Refuse to install a package that introduces a dependency loop,
>while allowing those that do not introduce a loop to install, to
>avoid getting an unstable boot sequence (as in, there is no way to
>know how to order the scripts involved in a loop).
> 
> I'm not aware of triggers being able to do that.  Besides, one need to
> be very careful when changing the boot sequence, to make sure the
> machine stay bootable. :)

Unless I'm confused, the current system doesn't provide any guarantee
against loops in the case of upgrades that add dependencies. Even if you
refuse to finish the install, the new package, with the new script, are
already present, are they not?(*)

-Rob

(*) I haven't checked the code here; sorry.
-- 
GPG key available at: .


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

Re: Anything wrong with bzr.debian.org or debcheckout ?

[Robert Collins]

On Thu, 2008-06-19 at 13:27 +0900, Charles Plessy wrote:
> Hi all,
> 
> I tried to debckechout zlib and it failed:
> 
> anx159tmp$ debcheckout zlib
> declared bzr repository at http://bzr.debian.org/bzr/pkg-zlib/zlib/debian
> bzr branch http://bzr.debian.org/bzr/pkg-zlib/zlib/debian zlib ...
> bzr: ERROR: Transport error: Server refuses to fullfil the request 
> checkout failed (the command shown above returned non-zero exit code)
> 
> I took rando

Its a bug in your bzr, fixed upstream already I believe.

-Rob
-- 
GPG key available at: .


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

Re: Generating debian package using cmake (take 3)

[Robert Collins]

On Tue, 2008-06-24 at 18:05 -0700, Steve Langasek wrote:
> On Wed, Jun 25, 2008 at 02:00:17AM +0200, Rafael Laboissiere wrote:
> 
> > It is okay to have the debian directory in your tarball but, if you go down
> > this road, it will be desirable that the Debian maintainer/sponsor for your
> > package has commit access to the SVN repository.
> 
> Even if this is the case, it is still annoying for NMUers to have to deal
> with not being able to delete files from the debian/ directory as part of an
> NMU (which can plausibly be required in order to fix a bug),

Why can't a full-lines-removed diff be generated? patch will treat that
as removal...

-Rob


-- 
GPG key available at: .


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

Re: What criteria does ftpmaster use for the ‘copyright’ file of a package? (was: python-daemon_1.4.6-1_amd64.changes REJECTED)

[Robert Collins]

On Sat, 2009-08-29 at 18:03 +1000, Ben Finney wrote:
> Howdy Chris,
> 
> I'm copying this discussion to ‘debian-devel’, since I think it has
> direct bearing on the recent discussions about trying to figure out
> the actual requirements for the contents of the ‘copyright’ file.
> 
> On 27-Aug-2009, Chris Lamb wrote:
> > I'm rejecting your package from NEW because your debian/copyright
> > doesn't contain the "Copyright (C) blah blah" text along with the
> > licenses.
> 
> This is true; the package as originally uploaded had copyright notices
> preserved in the source, but not duplicated into the ‘copyright’ file.

Your experience seems to be covered by
http://lintian.debian.org/tags/copyright-without-copyright-notice.html
and http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
(linked from http://ftp-master.debian.org/REJECT-FAQ.html)

-Rob


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

Bug#545113: ITP: pandora-build

[Robert Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

package: wnpp
X-Debbugs-CC: debian-devel@lists.debian.org

Pandora build is a collection of m4 macros used by libdrizzle,
libmemcached, drizzle and gearmand : developers working on these
projects need the macros installed.

- -Rob

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqh5PYACgkQ42zgmrPGrq7C4wCggcWrIwdg+IXcMVWCOPBH3sZX
TRsAnRXq+0tUFLVIZRqweZV0Yu9B5obg
=uZq6
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#547492: ITP: python-junitxml

[Robert Collins]

package: wnpp
X-Debbugs-CC: debian-devel@lists.debian.org


A tiny junit extension.


Source: pyjunitxml
Section: python
Priority: optional
Maintainer: Robert Collins 
Build-Depends: debhelper (>= 5.0.38), cdbs (>= 0.4.49),
 python-all-dev (>= 2.3.5-11)
Build-Depends-Indep: python-docutils, python-support (>= 0.5.3)
Standards-Version: 3.8.3

Package: python-junitxml
Architecture: all
Depends: ${python:Depends}, ${misc:Depends}
Description: PyUnit extension for reporting in JUnit compatible XML
 A PyUnit extension to output JUnit compatible XML.



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

Re: Seeking advice on packaging of pion-net

[Robert Collins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Banck wrote:
> 
> Did you try to discuss the library versioning scheme with upstream?

pion-net is built on boost's asio. I'd be very suprised if they even
_can_ offer a stable ABI with no symbol pollution from asio etc. :)

- -Rob
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkq3c8kACgkQ42zgmrPGrq5gDwCgm9vf9LbEpd1Peh+/G8Nd73Kd
ng0Ani0Y31sZoipdBPehaf1R7PWfCzEh
=exJ7
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DEP-5: binary package affected by license $foo

[Robert Collins]

On Thu, 2009-11-05 at 13:59 +1100, Ben Finney wrote:
> 
> > The rational is that sooner or later, we will want to use the
> > machine-interpretable copyright file to validate packages freeness,
> > license compatibilities and so on.
> 
> Interesting. So you think a single source package could produce binary
> packages that are each judged differently for their DFSG status? I
> wonder what the FTP masters would say to that.
> 
> (That could read sarcastically; it's not. I'm interested to know.) 

I don't know what the FTP masters will say, but it is, sadly, how
licences interact; given a single upstream that builds two binaries, one
which links to a GPL library, and one that doesn't (and which are
packaged into separate debs), then we've clearly got different
constraints placed on the two debs.

-Rob


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

Re: Bits from the FTPMaster meeting

[Robert Collins]

On Sun, 2009-11-15 at 19:29 -0600, Steve Langasek wrote:

> I'm not asserting that this problem is *not* significant, I simply don't
> know - and am interested in knowing if anyone has more data on this beyond
> some four-year-old anecdotes.  Certainly, Debian with its wider range of
> ports is more likely to run into problems because of this than Ubuntu, and
> so will need to be fairly cautious.

I'd have assumed that ports will have no effect on this: Debian only
uploads one binary arch (from the maintainer) anyway :- only builds on
that arch will be directly affected except in the case of a build
failure that the maintainer could have caught locally.

-Rob


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

Re: Bits from the FTPMaster meeting

[Robert Collins]

On Mon, 2009-11-16 at 09:38 -0600, Steve Langasek wrote:


> I thought the nature of the problem was clear, but to be explicit:
> requiring binary uploads ensures that the package has been build-tested
> *somewhere* prior to upload, and avoids clogging up the buildds with
> preventable failures (some of which will happen only at the end of the
> build, which may tie up the buildd for quite a long time).  The larger
> number of ports compared to Ubuntu has the effect that the ports with the
> lowest capacity are /more likely/ to run into problems as a result of such
> waste, and as Debian only advances as fast as the slowest supported port,
> this holds up the entire distribution.

Well, I was assuming a couple of things I guess.

Firstly, that if there are two successive uploads of a package, P and
P', where P is badly damaged, and P' is uploaded before an overloaded
architecture starts to build P, then P is never attempted on that
overloaded architecture.

Secondly, that we can also cut all the builds for a package which fails
on its first architecture.

-Rob


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

Bug#557731: ITP: lptools -- desktop tools for Launchpad

[Robert Collins]

X-Debbugs-CC: debian-devel@lists.debian.org
package: wnpp

Description:
 LP Tools allow you to work with Launchpad without ever having to deal
 with the web interface. The review-list tool can list reviews, and
 review-notifier provides a desktop notifier about reviews that can be
done.
 .
 milestone2ical converts milestones on a project or project group into
the
 iCal format.



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

Re: New source package formats now available

[Robert Collins]

On Mon, 2009-11-23 at 09:30 +0100, Raphael Hertzog wrote:

> In the end, I decided to trust nothing and to verify if the first
> patch can be applied or not. If it can be applied, we assume that the
> patches have not been applied and we apply them all (unless
> --no-preparation is given). If quilt is available, instead of checking the
> first patch, I check the first patch returned by quilt unapplied
> and apply the remaining of the patches if needed.

This heuristic is likely to fail - patches that solely add content can
apply repeatedly without error.

-Rob


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

Re: How to maintain packaging files for multiple distributions in the same tree?

[Robert Collins]

On Tue, 2007-01-30 at 15:23 +, Roger Leigh wrote:

> >>> Branches don't work so well for ubuntu as you have to pull over the
> >>> changes from the main branch to the ubuntu branch on every
> >>> release. Which means (unneccessary) work.
> >>
> >> It is work, yes, but in many cases it is necessary, and we do quite a bit 
> >> of
> >> it at present.
> >
> > Hopefully the graphic above makes it clear why a branch isn't the most
> > helpfull construct for it. Unfortunately I know of no RCS that has
> > something better for this kind of parallel developement.
> 
> tla star-merge ?

or just about any recent VCS to be honest.
bzr merge handles back and forth work like this trivially.

-Rob
-- 
GPG key available at: .


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

Re: On maintainers not responding to bugs

[Robert Collins]

On Sun, 2007-02-25 at 21:11 -0500, root wrote:
> ... ackowledging their part of the process of software development and
> not
> treating them with distrain. If you treat them well, by acknowleding
> their bug reports and -- $DEITY forgive -- saying you are working on
> it, ...

In fact, acknowledging and saying 'I dont have time to fix this' is
important too: it means that other developers, or users wanting to be
developers, know that they wont collide with the developer should they
try to fix it. 

-Rob
-- 
GPG key available at: .


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

Re: On maintainers not responding to bugs

[Robert Collins]

On Fri, 2007-03-02 at 18:57 +0100, Pierre Habouzit wrote:
> but I would
> obviously lessen my implication and work for other teams where I've a
> single damn chance to see my contribution to be compareable to the
> others. 

Better a big fish in a small pond than a small fish in a big pond huh?

So much for the idea of team work.

-Sigh
-- 
GPG key available at: .


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

Re: DM vs DD and security

[Robert Collins]

On Mon, 2007-03-19 at 05:41 -0400, Kevin Mark wrote:
> And if its large, then could this be reduced in some way by having the
> more common tasks be replaced by a web frontend with password access
> and leave fewer tasks that require ssh access.


Because ssh is /less/ secure than ssl?

-Rob
-- 
GPG key available at: .


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

Re: Mandatory -dbg packages for libraries?

[Robert Collins]

On Sun, 2007-04-22 at 16:14 -0500, Steve Greenland wrote:
> On 22-Apr-07, 14:39 (CDT), Neil Williams <[EMAIL PROTECTED]> wrote: 
> > 
> > I'd like to see all library source packages having a minimum of 4
> > binary packages required by Policy: the SONAME, the -dev,  the -dbg and
> > a -doc package. (Libraries for perl or other non-compiled languages
> > would be exempt from -dbg packages but not -doc.)
> 
> 1. Rather than cluttering the archive and Packages file with -dbg
> packages that will (mostly) never be used, how about mandating a "debug"
> target in library debian/rules files, so that when someone does need the
> debug package, it's trivial to build. Since the person most likely to
> need the target is the package maintainer, there would be some incentive
> to make sure it works.

Because segfaults are often not easily reproduced. Having the ability to
analyse a crash that occured when the user did not have the -dbg
packages installed is not possible unless you have the original symbols
the compiler created.

-Rob
-- 
GPG key available at: .


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

Re: Mandatory -dbg packages for libraries?

[Robert Collins]

On Tue, 2007-04-24 at 14:40 +0200, Loïc Minier wrote:
> On Tue, Apr 24, 2007, Josselin Mouette wrote:
> > Apport sends complete core dumps, which is a very bad idea. The dumps
> > can be huge (for desktop applications they often grow beyond 200MB) and
> > they can contain gazillions of sensitive information.
> 
>  But Apport is written already, and it's also the path that Windows
>  crash report and Mozilla's talkback tools have taken; these
>  corporations might not represent our ideals, but they present examples
>  of deployed and working solutions.
> 
>  I don't think it's still 200 MB compressed, but some input from Ubuntu
>  folks could help.

apport can send mini core dumps, and will offer to do so if the coredump
is very large. 

> > Using a central server for symbol lookup like Ben proposed looks like a
> > better idea. It needs gdb to be adapted or wrapped to access them
> > correctly, though.
> 
>  Yes, it sounds like a good idea; I suppose it might offer less
>  possibilities, but a good stack trace is often good enough.  However
>  modifying gdb sounds like a lot of hard work.  I don't know how Apport
>  works on the server side, but if this part of Apport could be made to
>  run on the client and to fetch the relevant files, this might have all
>  advantages of not sending the sensitive core dumps, not uploading too
>  much data, and being available without too much development.

This would be nice too - I would certainly like to be able to say to
apport 'please retrace on my machine now without uploading' for
applications that have been exposed to my password.

Rob
-- 
GPG key available at: .


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

Re: python, then C++, or C++ from the start?

[Robert Collins]

On Wed, 2007-05-30 at 17:34 +0200, martin f krafft wrote:
> Dear colleagues,

...
> But I am asking you still: can you think of anything to say against
> such an approach? Please don't flame languages or anything of that
> sort. The question is just: is it viable for a C++ coder with
> a Python proficiency to mockup a new application in Python first?


I think its entirely viable. boost::python is rather nice and should
allow incremental migration. You could if you care start with a C++
wrapper using boost:python where all the guts are in python, and then
its just a question of how much is pure c++ :).

Rob
-- 
GPG key available at: .


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

Bug#430896: general: GNOME or KDE desktops should issue a warning when the user unplugs USB media without unmounting.

[Robert Collins]

On Thu, 2007-06-28 at 14:54 +1000, Andrew Donnellan wrote:
> On 6/28/07, Michael Biebl <[EMAIL PROTECTED]> wrote:
> > FWIW recent GNOME desktops in unstable using gnome-mount for doing the 
> > mounting
> > stuff, already have this kind of functionality. Whenever you unmount a 
> > removable
> > device, gnome-mount will show you a message via notification-daemon, when 
> > it is
> > safe to unplug the device. I'm not sure if XFCE in Debian already uses
> > gnome-mount, though.
> 
> I interpreted it as saying 'Give a warning if someone accidentally
> pulls it out before unmounting', not 'Tell me when I can pull it out
> after unmounting.'

It should do both if its recieved the patch from Ubuntu (and given it
shows when its unsafe, I think it has - both were done at the same time
IIRC).

-Rob
-- 
GPG key available at: .


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

RFC: declaritive diversions

[Robert Collins]

Ian and I have chatted a few times about diversions in packages. It
seems like it would be easier to look for packages that should divert
(and don't), or do (and perhaps shouldn't :)) if the diversions were
declared in the package rather than being done by turing complete
code :).

This is a long-promised email to kick start discussion about this.

I don't have a proposed syntax at this point, but I was thinking a
control file in the source such as debian/PACKAGENAME.diversions would
be a good starting point - if thats able to record everything thats
needed, even if the binaries stay as they are (doing diversions in the
maintainer scripts) for now for compatibility this would improve things.

-Rob
-- 
GPG key available at: .


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

Re: RFC: declaritive diversions

[Robert Collins]

On Tue, 2007-07-17 at 11:55 +0200, Goswin von Brederlow wrote:

> Did you see my earlier mail about the very same thing?

No I didn't, sorry.

I'm glad the concept seems to have positive reactions regardless.

-Rob
-- 
GPG key available at: .


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

Re: Bug#433143: ITP: bzr-rebase -- Rebase plugin for Bazaar

[Robert Collins]

On Mon, 2007-07-16 at 00:28 +0200, Stefano Zacchiroli wrote:


> I don't want to see a bzr-foo package in the archive for each .py module
> available on the internet which provides yet another sub-command for
> bzr. I asked under the (wrong) assumption that bzrtools was a Debian
> package shipping in a single Debian package several bzr addons. Under
> that assumption it seemed reasonable to avoid creating a new package,
> bug including your new addons as part of it.
> 
> Since my assumption was wrong: what about creating a "bzr-addons" Debian
> package containing the most used bzr addons out there instead of filing
> an ITP for just one?

I'd like to do the following:

 * rename the 'bazaar' package to 'baz' - both source and binary, though
binary is the key one. This is because it is no longer the recommended
tool from the 'Bazaar VCS Project' rather it is deprecated. Its useful
for conversions to bzr though, so keeping it as 'baz' is good.

 * Create a 'bazaar' package which is a metapackage depending on bzr,
recommending key plugins, and suggesting others.

-Rob
-- 
GPG key available at: .


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

Re: Bug#433143: ITP: bzr-rebase -- Rebase plugin for Bazaar

[Robert Collins]

On Tue, 2007-07-17 at 19:56 +0200, Adeodato Simó wrote:
> * Manoj Srivastava [Tue, 17 Jul 2007 09:11:45 -0500]:
> 
> > >  * Create a 'bazaar' package which is a metapackage depending on bzr,
> > > recommending key plugins, and suggesting others.
> 
> > This would be a bug.  While I understand you prefer the bzr VCS
> >  over Arch, I see no justification for imposing your likes and dislikes
> >  over users happily using baz as their version control system.  I would
> >  be most annoyed if baz would have been replaced by bzr on my systems if
> >  the sysadmin dude did not notice the change.
> 
> Well, the issue at hand is that the upstream authors of Bazaar 1.x have
> renamed it to "baz", and given away their name to some other project
> (bzr). Sooner or latter the packages will have to reflect *that*.

A small data point : its always been 'baz' as the command, we just were
not as clear about the difference between the individual command and the
overall system as we are now.

-Rob
-- 
GPG key available at: .


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

Re: Bug#433143: ITP: bzr-rebase -- Rebase plugin for Bazaar

[Robert Collins]

On Tue, 2007-07-17 at 09:11 -0500, Manoj Srivastava wrote:
> On Tue, 17 Jul 2007 20:19:59 +1000, Robert Collins
> <[EMAIL PROTECTED]> said:  
> 
> >  * rename the 'bazaar' package to 'baz' - both source and binary,
> >though binary is the key one. This is because it is no longer the
> >recommended  tool from the 'Bazaar VCS Project' rather it is
> >deprecated. Its useful  for conversions to bzr though, so keeping
> >it as 'baz' is good. 
> 
> That is not the only use for it. bzr is an inplementation of
>  Arch, and there are people who have not bought the 'Bazaar VCS Project'
>  koolaid, and still prefer Arch to the new VCS.

Thats fine, they are welcome to keep using Arch. 'baz' itself is
unmaintained, though many of the patches in it relative to 'tla' have
been incorporated upstream.

> >  * Create a 'bazaar' package which is a metapackage depending on bzr,
> > recommending key plugins, and suggesting others.
> 
> This would be a bug.  While I understand you prefer the bzr VCS
>  over Arch, I see no justification for imposing your likes and dislikes
>  over users happily using baz as their version control system.  I would
>  be most annoyed if baz would have been replaced by bzr on my systems if
>  the sysadmin dude did not notice the change.

Curiosity: I take it then that you are still using baz, rather than
tla? 

> A note in NEWS.Debian about your preferred VCS would be OK, I
>  suppose, but please come up with a bewtter upgrade plan for current
>  users of baz.

A starting point is to do the package rename with upgrades and not
introduce a bazaar metapackage for a release. Or at least for some
arbitrary timeframe, as that can be more precisely defined.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.


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

Re: [DRAFT] resolving DFSG violations

[Robert Collins]

On Wed, 2008-10-29 at 22:33 +0100, Michelle Konzack wrote:
> 
> Anw what do you do with sourcode, for which there is not even a
> compiler
> availlable under Linux/BSD?  And you HAV to buy a  8000 US$
> development
> suit from the chip manufacturer to build the firmware?

Free software is an iterative process; we started with nothing, using
proprietary C compilers, kernel, libc - everything. And we iterated, and
iterated - now we have a free stack including BIOS, and are continuing
to push freedom deeper down the stack.

I feel for you that you are on the cutting edge, where you cannot do
what you need to do without spending 8K US to buy a proprietary tool.

> I have such software and EVEN me can not read the firmware.
> 
> I have ONLY a "project" in my IDE and it produce the firmware.

Well, your IDE is software, it can read the input settings to generate
the firmware. So its part of the tool chain to build the firmware.
Whatever data the IDE edits as you change settings, thats the source for
the firmware. (You may be combining other binary blobs when you compile
the firmware, but thats the nature of this part of the industry, as I
understand it).

And yes, people can fry their *own hardware* if they mess up the
firmware. So what - I started with monitors you could completely fry if
you put the wrong X11 config settings into it, which is vastly easier to
do than rebuilding a firmware:).

None of this changes the fundamental aspects though:
 - The output firmware is not the preferred form for modification (it is
   the output, not the alterable portion of the input).
 - The output firmware *may* need to be replaced if there is an issue
   found after the hardware ships. (Its not a write-once event to create
   firmware).
 
This clearly means that we cannot ship it in main or contrib under the
social contract.

(I found http://en.wikipedia.org/wiki/Open_source_hardware and
http://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core
useful reading, as I'm not personally coding down at this level).

-Rob

-- 
GPG key available at: .


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

Re: Free OS versus free hw

[Robert Collins]

On Wed, 2008-10-29 at 15:15 +0100, Loïc Minier wrote:
> On Wed, Oct 29, 2008, Ben Finney wrote:
> > Since the Social Contract promises Debian *won't* ship non-free
> > things, that's not an option compatible with the promises made by the
> > Debian project.
> 
>  I might not have said it clearly enough:
>  - I agree the current DFSG and social contract imply we need to provide
>sources for these firmware if they are shipped in Debian

Good :).

>  - in turn, this implies that I'm suggesting we might need to reword
>parts of them to reduce the perimeter of Debian to something
>achievable which we still love and aim for

I think that that would not be Debian anymore.

-Rob
-- 
GPG key available at: .


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

Re: DFSG violations: non-free but no contrib

[Robert Collins]

On Sun, 2008-11-02 at 14:51 +0100, Aurelien Jarno wrote:
> Everyone agrees that firmwares are a bit special
> in the world of software due to the fact they don't run on the host
> CPU.

I don't think they are at all special. What interprets the software - be
it a 'cpu', a 'vm' or a co-processor like many video cards, or something
like an arduino doesn't alter the basic attributes - there is machine
code for one or more machines, which is usually derived from some more
editable source (more can be quite a range though) though compilation.

If firmware is special, so is java, .net, ocaml, all 32-bit i386
binaries (because bochs can emulate them elsewhere) etc.

-Rob

-- 
GPG key available at: .


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

Re: DFSG violations: non-free but no contrib

[Robert Collins]

On Mon, 2008-11-03 at 21:20 +0100, Loïc Minier wrote:
...
> for which providing a source is not critical. 
...

I wish I understood the reasoning here - putting aside the fact that
most of the software in Debian is under a copyleft licence and so we
*must* provide the source. Why is the source for the radio on my wifi
card any *less* critical than the source for the driver for my wifi
card?

And please, no handwaving about 'different' or 'its hardware
enablement'.

And if the answer reduces down to 'firmware is made by proprietary
vendors and does something many people need and we don't have a
replacement yet' - well thats fine, but at various points we didn't have
a free kernel, or a free libc, or a free graphic desktop environment.

-Rob


-- 
GPG key available at: .


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

Re: DFSG violations: non-free but no contrib

[Robert Collins]

On Tue, 2008-11-04 at 15:11 +0100, Loïc Minier wrote:
> On Tue, Nov 04, 2008, Robert Collins wrote:
> > I wish I understood the reasoning here - putting aside the fact that
> > most of the software in Debian is under a copyleft licence and so we
> > *must* provide the source. Why is the source for the radio on my wifi
> > card any *less* critical than the source for the driver for my wifi
> > card?
> 
>  Because I can consider the wifi firmware a subsystem which doesn't
>  contaminate my main OS;

If it wasn't fixed and never got altered I would subscribe to this
argument.

>  there's a clear interface between the two
>  systems -- it's like talking to another computer

Not at all, I don't own that other computer, and if it doesn't work
correctly I have to talk to it's owner to get it fixed.

> , talking to your hard
>  disk

Not at all the same; probably because they are part of the standard boot
sequence I have yet to see a hard disk needing firmware (for SCSI/ATA
disks, I can't comment on more esoteric interfaces).

> , talking to your keyboard

Some keyboards we can't use properly because there is proprietary
features activated by USB command sequences that are not documented and
open. Those keyboards get less functionality on Linux until someone
reverse engineers them. Wouldn't it be great if that wasn't the case?

> : something proprietary or free might
>  well be inside, I don't care as long as I can run a free OS on the main
>  CPU. 

I care that I can use the full capabilities of e.g. that extended
keyboard, that all the media keys, LCD displays and so on work.

>  I'd *prefer* if it was free, but I can start another project to
>  fulfill this goal.  I don't want the freedom requirements for the main
>  OS to require using free hardware, just like I want the freedom
>  requirements to require talking to computers running free software.

It may be that for that hardware Debian does not fit your desires. Can I
remind you of this little statement:

"Social Contract" with the Free Software Community:
1. Debian will remain 100% free 

We provide the guidelines that we use to determine if a work is free in
the document entitled The Debian Free Software Guidelines. We promise
that the Debian system and all its components will be free according to
these guidelines. We will support people who create or use both free and
non-free works on Debian. We will never make the system require the use
of a non-free component. 

>  Now if Debian can distribute a blob which allows my hardware to run as
>  indicated by a clear interface with my free OS, that's good enough for
>  me.

Why draw the line there? why not be happy if Debian can ship a blob that
uses the kernel's binary interfaces?  There's no moral or technical
difference.

>  And if we don't require the hardware to be freely modifiable, why
>  require the firmware to be so?

Because the firmware isn't the hardware. It is software.

> > And if the answer reduces down to 'firmware is made by proprietary
> > vendors and does something many people need and we don't have a
> > replacement yet' - well thats fine, but at various points we didn't have
> > a free kernel, or a free libc, or a free graphic desktop environment.
> 
>  And we didn't have Debian or OpenMoko; and the glibc, linux, and
>  Xorg/GNOME/KDE/Xfce are huge separate projects and we could start new
>  projects to free more things up.

Debian started in 1993; Linux was first released in 1991, glibc had its
core functional in 1988
( http://en.wikipedia.org/wiki/GNU_C_Library#cite_note-1). KDE was
started in 1996, and GNOME in 1997. XFree86 forked around 1992, IIRC.

We *had* Debian long before we had a free graphical desktop environment
[that really meets the term - a window many isn't enough :)]

>  Google.com is run with software I don't have access to

google doesn't affect the functionality of hardware you own.

> , but I use it
>  daily, as well as my microwave

ECOMPLETELYUNRELATED

> , or my wifi card.

Which is the point under contention.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.


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

Re: Leverage in licensing discussions

[Robert Collins]

On Fri, 2008-11-07 at 20:01 +, David Given wrote:
> 
> 1. Some devices require firmware blobs with no source available.
> Because
> of this, such firmware can't be distributed in Debian.

ack.

> 2. For at least some of these devices, even if the source code was
> available it would add no value, because of legal restrictions
> governing
> which firmware blobs can be used on that hardware.

I don't agree with this point: there may be no added value for *most
users* - but if I had the firmware source I could e.g. fix a bug to get
a region the manufacturer had not bothered to certify in to certify the
device. Or open up the power/frequency to ranges I hold a licence to
operate in.

> 3. These devices tend to be quite common and cheap, therefore it would
> be nice if Debian could somehow support them.

ack,

-Rob
-- 
GPG key available at: .


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

Re: Bug#509225: ITP: tevent -- talloc-based event loop library

[Robert Collins]

On Fri, 2008-12-19 at 23:49 +0100, Jelmer Vernooij wrote:

> An alternative would be to implement tevent as a wrapper around libev or
> libevents that added talloc support to the API but that's hardly worth
> the trouble as that would add another dependency and the library is
> pretty small itself as is.

It would however prevent further fragmentation in this space ;)

libevent + libtevent-which-wraps-libevent is better than
libtevent-which-duplicates-much-of-libevent. :)

-Rob
-- 
GPG key available at: .


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

Re: Bug#509225: ITP: tevent -- talloc-based event loop library

[Robert Collins]

On Sat, 2008-12-20 at 01:57 +0100, Jelmer Vernooij wrote:
> Am Samstag, den 20.12.2008, 11:10 +1100 schrieb Robert Collins:
> > libevent + libtevent-which-wraps-libevent is better than
> > libtevent-which-duplicates-much-of-libevent. :)
> In theory, I agree. However, in this case libevents is about a factor 10
> larger in terms of source code than libtevent, and that's even without
> the wrapper that would add talloc support and the support for AIO.
> 
> But more importantly (with my upstream hat on): we have to support a lot
> of folks that are not running fancy systems like Debian (apt FTW), and
> who have to still install everything manually. This means another
> dependency for them to install. 

There are other ways to solve that - e.g. provide a bundle of source
packages. That said, gentoo, rpm-based systems, ports-based systems,
conary, heck even cygwin support dependency chaining on installs -
surely anyone outside that collection of platforms is already manually
building their kernel and up - they are choosing that environment. Bit
of a tail-wagging-the-dog as far as I can tell without more information.

-Rob

 
GPG key available at: <http://www.robertcollins.net/keys.txt>.


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

Re: stupid dependencies on update-inetd

[Robert Collins]

On Sun, 2007-07-29 at 16:22 +0200, Magnus Holmgren wrote:
> 
> But: AFAIU, /etc/inetd.conf is now owned by any package, because it's
> used by 
> several packages and updated by update-inetd. I think it makes sense
> for 
> service packages, like samba, to update inetd.conf even though no 
> inet-superserver is installed, so that if/when one is installed, the 
> configuration is in place. Furthermore, other inet-superservers will
> want to 
> call update-inetd's update-inetd from their own update-inetd, to
> facilitate 
> switching from one inet-superserver to another. On the other hand,
> perhaps 
> that should be the administrator's decision: If they don't ever want
> to use 
> inetd they shouldn't have to have update-inetd installed. 

I think it would be better to not presume the configuration of the inet
superserver that may be installed. Perhaps dpkg-hooks are a reasonable
way to do this - packages like samba that can use but don't require an
inetd can register for an inetd hook, and when an inetd providing hook
is installed they will all get called back?

-Rob
-- 
GPG key available at: .


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

Re: Why no Opera?

[Robert Collins]

On Mon, 2007-08-27 at 23:54 -0400, [EMAIL PROTECTED] wrote:
> Quoting "Roberto C. Sánchez" <[EMAIL PROTECTED]>:
> 
> 
> > What professional software engineering experience do you have on large
> > software projects that qualifies you to determine what software "is
> > likely to need little testing"?
> Good point. The answer is not much,
> 
> > Additionally, what insight do you have into the Opera development
> > process and methodology that qualifies you to make that claim
> > specifically about Opera?
> 
>   Opera bugs are reported much less than most other widely used  
> browsers, and Opera is widely used.
>   What evidence do you have that your process and methodology is an  
> improvement over Opera's?

Feh, turning this into a pissing competition is unneeded.

Bug rates on Opera *may* be lower than those on firefox/internet
explorer/safari etc.

But that does help establish your point - that opera is something that
needs little testing unless *those other browsers* have already been
established as having bug rates below whatever threshold is considered
relevant.

Not that bug rates are a good indication of whether a new build of a
piece of software *needs testing*. Having few reported bugs may simply
be an indication that that software is heavily tested before
releases :).

-Rob
-- 
GPG key available at: .


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

Re: pristine tarball generator

[Robert Collins]

On Sat, 2007-10-06 at 16:46 +1000, Anthony Towns wrote:
> On Wed, Oct 03, 2007 at 03:38:54PM +0300, Faidon Liambotis wrote:
> > There's also --rsyncable which is appears mostly (if not only) on Debian
> > and unfortunately can't be figured out from the headers.
> 
> > Multipart gzips would also not work even though I haven't yet find any.
> 
> Both these are cases where the .gz file is equivalent to cat'ing two
> (or more) .gz files together, I would've thought, and should be able
> to be dealt with as such, possibly just by checking for a header, or by
> previously matching gzip output suddenly not matching anymore?

--rsyncable resets the compression stream; multipart is just catt'd
gzips together.

I think a heuristic like you suggest may work well, you could look for a
gzip header when the content starts to differ to detect multipart ones
quiet well.

-Rob
-- 
GPG key available at: .


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

Re: -Wl,--as-needed considered possibly harmful

[Robert Collins]

On Thu, 2007-12-20 at 00:51 -0800, Steve Langasek wrote:
> On Mon, Dec 10, 2007 at 09:47:36PM +0100, Simon Richter wrote:
> 
> >>> No, what can be done is to fix upstream's broken declaration that 'you can
> >>> assume glib functions are available when doing "#include "'.  
> >>> It
> >>> doesn't follow that just because this works in practice, it should be a
> >>> supported usage.
> 
> >> When many of the types used by GTK+ are those provided by GLib, it
> >> sounds wrong to ask developers to include the GLib headers to have these
> >> types available.
> 
> > If it is really expected that type declarations are to be shared between a 
> > program and a library, then the program becomes dependent on the library's 
> > ABI without this dependency being formally expressed in any usable form, 
> > which is broken in and by itself.
> 
> > GTK needs to provide its own definitions of types and not expose interfaces 
> > it does not control.
> 
> Fine in theory, in practice this can be a significant burden to the library
> maintainer.  FWIW, I don't see any reason why a library can't use
> externally-defined types directly, /as long as/ they have some mechanism for
> ensuring ABI consistency between the two libraries (i.e., an ABI change in
> the underlying library is always accompanied by an soname change in the
> dependent library).

I'd make a stronger statement and say that reusing types is a positive
thing. If you are reusing a glib list in your pet library, creating your
own type makes your library incompatible with other libraries also using
glib lists and providing code to manipulate them... and if it doesn't
make it incompatible then its not going to achieve the ABI
considerations that are under discussion here.

So really I think each dependant library of a library that is
dynamically linked to falls into one of two categories:
 - internal detail
 - implementation detail resulting in exposed ABI

So if I link program X against libfoo which uses libbar, if libbar is an
internal detail of libfoo then:
libfoo -> [EMAIL PROTECTED] ABI
X -> [EMAIL PROTECTED]'s ABI only.

And a rebuild of libfoo to link a new libbar ABI won't break X, nor will
it require a rebuild of X. 

The conditions for internal detail only are very stringent: compiler
alignment, structure sizes etc etc for all non opaque (where opaque is
opaque to the /compiler/ not to the user's code!) exported types of
libfoo must not be dependent on libbar at all.

I doubt that many libraries will meet this requirement for all their
dependent libraries (and consider libc as just an extremely common case
of this).


For all other cases, when a used ABI gets exposed, while we may not want
X to depend (at the package level) on libbar; at an ABI level it does.
We need to decide how we represent that. We also have at least two
dimensions here:
runtime linker behaviour
package management behaviour

From the runtime linker we want:
 * an error/warning/something when two instances of the same API with
different ABI's are loaded. This commonly occurs when libbar.1 and
libbar.2 are both loaded, but it can occur more generally when libbar is
renamed to libquux and then libbar.1 and libquux.2 are loaded (by X and
libfoo respectively).
 * To be able to interrogate how something was linked sufficiently well
to generate packaging metadata automatically.

From the package manager we want:
 * To know when we have to rebuild X because libbar has changed.
 * To allow upgrades to libbar on users systems without changing X when
possible.

The case where libbar is an internal detail is trivial (detection isn't:
see abicheck and icheck - libraries really need icheck in the package
build rules IMNSHO); I'm going to ignore it here. 

For the case where libbar is not an internal detail. Starting with
packaging as thats easiest:
 * we should depend on a minimum version of the libbar we need (as we
already bump the package name when the ABI changes incompatibly in a
library this is straight forward) and gives the opportunity to upgrade
libbar within an ABI safely.
 * we can do an rdepends on e.g. libbar2 when libbar's API changes from
2 to 3 to find packages we need to rebuild.

One defect here is when symbols are shared from within a non-library -
e.g. the case with some programs plugin's. Here, a plugin may use a
symbol from within the program X, which is ABI dependent all the way
back, so treating programs as libraries - that is having an ABI - might
make sense. I haven't considered this in detail...


The runtime loader is more tricky:
 * If we link X to libfoo only:
   - libfoo's soname has to be manually changed when libbar's changes or
hilarity results
   - we don't have a robust way that I know of to interrogate X to find
out that we need a package dependency on libbar
   + we don't need to have libbar present when it is only optionally
used (that is by calling some libfoo feature that needs libbar)

 * If we link X to libbar directly:
   - because we can't tell how much

Re: -Wl,--as-needed considered possibly harmful

[Robert Collins]

On Wed, 2007-12-26 at 13:11 +, Neil Williams wrote:
> 
> So could I ask, from an upstream perspective, what kind of changes in
> the underlying lib might *not* cause such a port and therefore end up
> with libfoo1 still being buildable against libbar3 yet *still* require
> a
> SONAME bump to accommodate the transition?

bar.h:
typedef unsigned int bar;

foo.h:
typedef struct {
  bar a_bar;
} exported_foo_type;

Then this patch to bar.h:
@@ -0,1 +0,1 @@
-typedef unsigned int bar;
+typedef size_t bar;

is enough to cause an ABI break in libfoo, without needing 'porting'
work (though it may well cause print formatting failures on 64
environments and other side effects).

-Rob


-- 
GPG key available at: .


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

Re: Faster shutdown and the ubuntu "multiuser" update-rc.d extention

[Robert Collins]

On Wed, 2008-01-02 at 00:29 +, Colin Watson wrote:
> On Wed, Jan 02, 2008 at 12:13:13AM +0100, Petter Reinholdtsen wrote:
> > What about changing the default values for dh_installinit for a future
> > debhelper compatibility layer, to use 'start 20 2 3 4 5 . stop 80 1 .'
> > instead of 'default' when calling update-rc.d?
> 
> Some packages actually do need to shut down cleanly; in the case of a
> database, for example, such a change could cause data loss.

Surely no more than a hard power failure(*), which databases (even such
lightweight ones as sqlite) are designed to handle.

(*) To any component :)

-Rob
-- 
GPG key available at: .


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

Re: Faster shutdown and the ubuntu "multiuser" update-rc.d extention

[Robert Collins]

On Wed, 2008-01-02 at 09:50 -0800, Russ Allbery wrote:
> Robert Collins <[EMAIL PROTECTED]> writes:
> > On Wed, 2008-01-02 at 00:29 +, Colin Watson wrote:
> 
> >> Some packages actually do need to shut down cleanly; in the case of a
> >> database, for example, such a change could cause data loss.
> 
> > Surely no more than a hard power failure(*), which databases (even such
> > lightweight ones as sqlite) are designed to handle.
> 
> You can still lose data transactions that weren't complete, and you may
> have to go through an extended consistency check when the system comes
> back up.

Meh, two answers to my point that equate 'data loss' with 'incomplete
transactions are not committed'. 

Incomplete transactions are *just that* - incomplete. Its why database
clients use transactions and understand that errors (such as the db
going away) mean their changes are not committed.

If a database is asked to shutdown and a client has a 10 minute update
running, you still end up with 'incomplete transaction not being
completed' - unless of course you want to block indefinitely on each
service.

Your note about an extended consistency check is valid when a power loss
has occurred but doesn't apply to the proposed fast shutdown as a signal
is in fact sent to the database. (And BTW, if your database needs a huge
consistency check on startup after a hard-down situation - consider
changing database engine!).

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.


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

Re: dh_shlibdeps and -dbg packages

[Robert Collins]

On Thu, 2008-01-17 at 23:58 +, Colin Watson wrote:
> On Thu, Jan 17, 2008 at 02:50:09PM -0800, Russ Allbery wrote:
> > Niko Tyni <[EMAIL PROTECTED]> writes:
> > > Hm, dh_shlibdeps prunes /usr/lib/debug when looking for ELF executables.
> > > This was apparently done when adding support for split debugging symbols
> > > files: see #215670.
> > >
> > > This looks like a bug to me, since /usr/lib/debug is used for "real"
> > > unstripped libraries too. Just filed #461339 on debhelper.
> > 
> > Hm, perhaps you should instead file a bug against any package (other than
> > libc6) which uses /usr/lib/debug for real unstripped libraries.  Shouldn't
> > everyone use detached debugging symbols now, or is there really enough
> > utility in building a separate debugging version libraries to warrant the
> > additional user complexity of using them?
> 
> I understand from Matthias that Python modules benefit noticeably from a
> separate debugging build.

python core definitely does - the debug build adds instrumentation that
has an overhead and is not included in the non-debug builds because of
that.

I'd expect the same macros to do this in python modules, though I don't
know for sure.

-Rob
-- 
GPG key available at: .


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

Re: TCP SYN cookies and Bug #520668

[Robert Collins]

On Sun, 2010-02-14 at 11:00 +0100, Florian Weimer wrote:

> BTW, will users think that the current warning ("possible SYN flooding
> on port %d. Sending cookies") always indicates an attack?  Hopefully
> not.

I'm sure non sysadmins will be confused by it- but they probably don't
look at dmesg anyhow except when asked to to gather diagnostic data for
a sysadmin/developer.

-Rob


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

Re: Misc developer news (#21)

[Robert Collins]

On Sat, 2010-02-20 at 14:25 +0100, Raphael Hertzog wrote:
> 
> > This wiki page still misses a "Disadvantages of new format"
> section. 
> 
> It's a wiki, feel free to add it. I know some people unhappy with the
> new
> format but I don't know many technical disadvantages. 

The primary one I'm unhappy with is its deleting part of the upstream
tarball with (AFAIK) no warning and no control. (That is, if upstream
have a debian dir, it gets nuked, rather than us collaborating on it).

-Rob


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

Re: Misc developer news (#21)

[Robert Collins]

On Sun, 2010-02-21 at 08:53 +0100, Raphael Hertzog wrote:

> > The primary one I'm unhappy with is its deleting part of the upstream
> > tarball with (AFAIK) no warning and no control. (That is, if upstream
> > have a debian dir, it gets nuked, rather than us collaborating on it).
> 
> That's a feature and an advantage in many situations. It really doesn't
> forbid you to reuse the upstream dir nor does it forbid you to collaborate
> with upstream to update it.

So how do you do that?

-Rob


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

Re: Changes in dpkg Pre-Depends

[Robert Collins]

On Tue, 2010-02-23 at 05:20 +0100, Guillem Jover wrote:

> I don't think this would be worth it, as Marco has also said, if the
> system is hosed but you can still get to the point of obtaining a
> package to install you might as well just obtain the broken files.
> Of course you might have it already on apt's cache, but that's not
> usually the case when you need it. :)

dpkg is useful for more than just installing new packages; a hosed
system might be fixed by removing a package, running maintainer scripts,
both of which dpkg is the right tool for.

Not arguing for or against, just noting that you're being overly
restrictive in your analysis of what a sdpkg might be used for.

-Rob


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

Re: Best practices for development workstations

[Robert Collins]

On Sat, 2010-04-03 at 17:48 +0200, Toni Mueller wrote:
> 
> 
> Actually, squid has its own slew of problems. Eg. I've yet to see a
> machine where Squid runs reliably under anything resembling a
> "reasonable load", instead of falling over frequently, and it can be
> difficult to have the features work that you want in such a setting.
> Eg. Lenny's version of Squid doesn't work for me on Lenny. 

Wearing my squid upstream hat: please file bugs if squid is misbehaving.
Squid is used in many high volume high load web sites, so if there are
reliability bugs we really really want to know about them.

-Rob


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

Re: Best practices for development workstations

[Robert Collins]

On Sun, 2010-04-04 at 12:27 +0200, Petter Reinholdtsen wrote:
> [Robert Collins]
> > Wearing my squid upstream hat: please file bugs if squid is
> > misbehaving.  Squid is used in many high volume high load web sites,
> > so if there are reliability bugs we really really want to know about
> > them.
> 
> If you really plan to fix apt and squid related problems, it would be
> nice if #56 was fixed.

HTTP pipelining is broken; don't use it. (Its now considered
fundamentally insecure - see the HTTP Smuggling whitepaper for all the
gory details). We're unlikely to ever invest a lot of time in it:
browsers are now going for many parallel TCP connections, and the HTTP
working group is blessing more connections as good practice. (This is vs
deep pipelining).

That said, squid handing back a truncated response is definitely a bug,
if it is indeed squid causing that (the bug doesn't have enough data to
tell - a tcpdump of a broken session would help, I suspect).

> Also, the default setup for Squid do not allow it to proxy all
> packages in the archive (the maximum_object_size is too small).  In
> Debian Edu, we increased it from 20480 KB to 153600 KB, to allow the
> openartwork and fluid-soundfound packages to be proxied.  In Debian
> Edu, PXE installation is set up out of the box, and to use it for
> several machines it is vital to proxy also the big packages. :)

Michael has created a squid-deb-proxy in Ubuntu, which should be pretty
trivial to include in Debian, that configures squid appropriately for
apt; and advertises it over avahi; squid-deb-proxy-client teaches apt to
use a zeroconf configured proxy.

-Rob


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

Re: APT do not work with Squid as a proxy because of pipelining default

[Robert Collins]

Due to the widespread usage of intercepting proxies, its very hard, if
not impossible, to determine if a proxy is in use. Its unwise, at
best, to assume that no proxy configured == no proxy processing your
traffic :(.

-Rob


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktik5teaazbkfzgwon2swqtdr_tb_tg1pnagte...@mail.gmail.com

Re: APT do not work with Squid as a proxy because of pipelining default

[Robert Collins]

Given that pipelining is broken by design, that the HTTP WG has
increased the number of concurrent connections that are recommended,
and removed the upper limit - no. I don't think that disabling
pipelining hurts anyone - just use a couple more concurrent
connections.

-Rob


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktiknkcqq8krqc9zupelg9gqrglou3zezgly7-...@mail.gmail.com