Re: libdb4.* madness in unstable

[Bernhard R. Link]

* Michael Biebl <[EMAIL PROTECTED]> [071016 17:50]:
> Today, while browsing through aptitude, I noticed that I had the
> following bdb versions installed:
>
> version:   # of packages depending on it (apt-cache rdepends)
> libdb4.2   40
> libdb4.3   26
> libdb4.4   55
> libdb4.5   64
> libdb4.6   40
>
> Having 5 different versions of one library is just insane imho. What are
> the reasons, that we still carry around the older versions, like 4.2 and
> 4.3? Is there software which doesn't build against newer versions, are
> there other reasons?
> Wouldn't it make sense to limit the number of bdb version in the archive
> to two or max. three?

If you want to help reducing this number, a good point would helping
getting more documentation about the different versions (and their
differences) available, and (at least for me) make some backports of the
suggested version people should use in your opinion available for etch
(via backports or whatever). At last I don't have the heart to change
to another version without giving it some more robust try
privately (as libdb has not the nicest history of ugly quirks and
shortcomings in the different versions) before that. And robust try
means real work test means within a (at least mostly) stable environment.

Hochachtungsvoll,
Bernhard R. Link


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

Re: libdb4.* madness in unstable

[Steve Langasek]

On Tue, Oct 16, 2007 at 06:33:20PM -0200, Henrique de Moraes Holschuh wrote:
> On Tue, 16 Oct 2007, Russ Allbery wrote:
> > Michael Biebl <[EMAIL PROTECTED]> writes:
> > > Today, while browsing through aptitude, I noticed that I had the
> > > following bdb versions installed:

> > > version:   # of packages depending on it (apt-cache rdepends)
> > > libdb4.2   40
> > > libdb4.3   26
> > > libdb4.4   55
> > > libdb4.5   64
> > > libdb4.6   40

> > > Having 5 different versions of one library is just insane imho. What are
> > > the reasons, that we still carry around the older versions, like 4.2 and
> > > 4.3? Is there software which doesn't build against newer versions, are
> > > there other reasons?

> > BerkeleyDB 4.2 is still faster and more stable than any subsequent version
> > for OpenLDAP, although 4.6 is looking promising.

> > I don't have any good explanation for 4.3 through 4.5, though.

> I do.  We don't ask the cyrus people and openldap people before packaging a
> new libdb version.

> The ugly truth is that libdb compatibility across minor versions is crap.
> You always have to fine-comb the API for changes, because the changes are
> not compile-time-detection safe.  Then you hit the bugs.

> IMHO we should declare a quarantine of a minimum of 6 months on every new
> libdb upstream, and only package it *if* openldap (*the* heavy-duty user of
> libdb advanced features) and cyrus imap (*the* thousands-of-concurrent-
> locks, mmap-happy user of libdb) did not have problems with it.

That's equivalent to an indefinite quarantine; according to BDB upstream,
OpenLDAP's problems with various versions are a consequence of abusing the
interface, not of using "advanced features".  I'm not sure why the burden
here should be on BDB alone.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Re: libdb4.* madness in unstable

[Francesco P. Lovergine]

On Wed, Oct 17, 2007 at 09:37:21AM +0200, Bernhard R. Link wrote:
> 
> If you want to help reducing this number, a good point would helping
> getting more documentation about the different versions (and their
> differences) available, and (at least for me) make some backports of the
> suggested version people should use in your opinion available for etch
> (via backports or whatever). At last I don't have the heart to change
> to another version without giving it some more robust try
> privately (as libdb has not the nicest history of ugly quirks and
> shortcomings in the different versions) before that. And robust try
> means real work test means within a (at least mostly) stable environment.
> 

A deep analysis of release notes, discussions with upstream and accurate
analysis of APIs are mandatory in this case. I think it is simply
unbelievable that the library is not backward compatible at every new
release. Issues with specific versions should be managed
and solved: having a new source for every release is simply not
acceptable. BTW, this is not the only case of such a mess around for
libraries (maybe some upstreams should be spanked...).

-- 
Francesco P. Lovergine


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

Re: libdb4.* madness in unstable

[Henrique de Moraes Holschuh]

On Wed, 17 Oct 2007, Steve Langasek wrote:
> > IMHO we should declare a quarantine of a minimum of 6 months on every new
> > libdb upstream, and only package it *if* openldap (*the* heavy-duty user of
> > libdb advanced features) and cyrus imap (*the* thousands-of-concurrent-
> > locks, mmap-happy user of libdb) did not have problems with it.
> 
> That's equivalent to an indefinite quarantine; according to BDB upstream,
> OpenLDAP's problems with various versions are a consequence of abusing the
> interface, not of using "advanced features".  I'm not sure why the burden
> here should be on BDB alone.

That's news to me. Thanks for sharing.  Well, Cyrus at least does not abuse
*any* interfaces (unless having thousands of processes in a busy site
accessing the same BDB is abusing it :p), but it is not nearly as good as
openldap at triggering BDB bugs.

One thing that BDB upstream *could* do is to publish a *complete* API
changelog.  That would fix the issues for Cyrus, at least.  One fine-comb
over the API changelog and the Cyrus code, and you would be ready to support
a new BDB version...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: libdb4.* madness in unstable

[Francesco P. Lovergine]

On Wed, Oct 17, 2007 at 12:52:33AM -0700, Steve Langasek wrote:
> 
> That's equivalent to an indefinite quarantine; according to BDB upstream,
> OpenLDAP's problems with various versions are a consequence of abusing the
> interface, not of using "advanced features".  I'm not sure why the burden
> here should be on BDB alone.
> 

That remembers me some other cases where people insist to use a non
stable C++ API instead of the C one. One could ask himself who is
guilty: the upstream who releases as public his private functions, 
or developer who use them ? :-D

-- 
Francesco P. Lovergine


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

Re: Intend to hijack gpsd

[Tilman Koschnick]

On Thu, 2007-10-11 at 11:34 +0200, Bernd Zeimetz wrote:
> Thus I intend to hijack gpsd, it would be maintained by me within the
> debian-gis team, which would also open a way for the currently listed
> maintainer to work on the package if he decides to be active again.
> Please let me know if anybody has objections against this. Otherwise I'd
> prepare a new version within the next 1-2 weeks.

Hi Bernd,

just for the record, since after the fact: I am quite happy with you
taking over gpsd. I have been bogged down with real life and work more
and more within the last year. I always hoped to find some time to
devote to gpsd "some time soon". Alas, I have to accept that this was
wishful thinking. 

Good luck and much fun with the package!

Cheers, Til



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

Re: Intend to hijack gpsd

[Bernd Zeimetz]

Hi Tilman,

> just for the record, since after the fact: I am quite happy with you
> taking over gpsd. I have been bogged down with real life and work more
> and more within the last year. I always hoped to find some time to
> devote to gpsd "some time soon". Alas, I have to accept that this was
> wishful thinking. 
> 
> Good luck and much fun with the package!

Thanks for that, and thanks for taking care of the package so far!

Hope I didn't bother you too much with all the mails the BTS must have
send to you during the last days.

Cheers,

Bernd
-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Bug#447014: ITP: detox -- utility to cleanup filenames from problematic characters

[Patrick Schoenfeld]

Package: wnpp
Severity: wishlist
Owner: Patrick Schoenfeld <[EMAIL PROTECTED]>

* Package name: detox
  Version : 1.1.1
  Upstream Author : Doug Harple
* URL : http://detox.sourceforge.net
* License : BSD
  Programming Lang: C
  Description : utility to cleanup filenames from problematic characters

Detox is a utility designed to clean up filenames. It replaces difficult to
work with characters, such as spaces, with standard equivalents. It will also
clean up filenames with UTF-8 or Latin-1 (or CP-1252) characters in them.

* Removal or replacement of upper ASCII Latin-1 (ISO 8859-1) characters
* Removal or replacement of UTF-8 encoded Unicode characters
* Removal or replacement of spaces and other potentially tricky characters, 
such as (, ), and @
* Removal of any "-"s at the beginning of the filename
* Removal or replacement of CGI escaped ASCII characters, i.e. %20 becomes " " 
(which then becomes "_").
* Trimming of excessive "_" and "-"s.
* Directory recursion, dry runs, verbose listings.
.
It's designed with safety in mind. It won't overwrite to a file that already 
exists,
and it doesn't touch special files normally (but it can be asked to).


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-2-k7 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- 
in medias res Gesellschaft für Kommunikationstechnologien mbH
Dahlenerstr. 570
D-41239 Mönchengladbach

tel. +49 (0) 2166 -  - 685
fax. +49 (0) 2616 -  - 800
email: [EMAIL PROTECTED]



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

New swish-e package: more filters for indexing office files

[Ludovic Drolez]

Hi!

I've just uploaded a new swish-e package. I've updated the filter rules
and added a sample swish.config file to easily index all kind of
OOo/MSoffice files (ppt, doc, xls). It's based on a running setup which indexes
100GB of office files daily.

Feel free to test and report any bug !

Cheers,

-- 
Ludovic Drolez.

http://zaurus.palmopensource.com   - The Zaurus Open Source Portal
http://www.drolez.com  - Personal site - Linux, Zaurus and PalmOS stuff


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

Re: Bug#229357: Can we require build-arch/indep targets for lenny?

[Simon Richter]

Hi,

Frank Lichtenheld schrieb:


3) Autodetection


My approach would be to have the autobuilders use "build-arch", and if 
that fails within 60 seconds, "clean" and "build".


If "build-arch" is not implemented, it fails rather quickly, so we use 
"build" and make a note in the build log. Later, one can grep for that note.


If it is implemented, but fails within 60 seconds, not much is lost.

If it takes longer to fail, then it's a normal FTBFS.

   Simon


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

Re: Bits from the Testing Security team

[Ian Jackson]

Kurt Roeckx writes ("Re: Bits from the Testing Security team"):
> Decompression is typicly something that is i/o bound, not cpu bound.

If the package is stored on disk and not in buffer cache.  However, in
many cases the package will have been just downloaded and so on a big
memory machine like a modern workstation may well be entirely in
buffer cache.

> What I think running it in a separate process does it creating 2 pipes
> you don't need.  You can just do everything in the local memory of 1
> process.

Are you confusing "I/O bound" with "makes read/write syscalls" ?  I/O
bound means that the limiting factor is mass storage performance.  If
the data is in main memory then mass storage performance is
irrelevant.

The overhead (cpu cost) of reading or writing the contents of the .deb
a few times through some pipes is irrelevant compared to both the cpu
cost of decompressing it and of course the cpu cost of processing each
file during installation.

> On Tue, Oct 16, 2007 at 02:34:36PM +0100, Ian Jackson wrote:
> > Having dpkg invoke the decompresser as a separate program provides
> > several IMO important advantages.  It simplifies the code in dpkg, and
> > it greatly simplifies the management of cross-version compatibility
> > and multiple optional decompression schemes (including experimental
> > ones), by decoupling dpkg from the decompressers.
> 
> I see no reason why we can't have both available.

!

dpkg has to be compiled one way in the distribution.

And if there is no good reason to have the decompressors bound in then
having that facility wired into the code is just extra complexity to
no useful purpose.

Ian.


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

Re: Bits from the Testing Security team

[Roland Mas]

Ian Jackson, 2007-10-17 15:00:55 +0100 :

[...]

> And if there is no good reason to have the decompressors bound in
> then having that facility wired into the code is just extra
> complexity to no useful purpose.

I thought the ability to just copy one binary (/usr/bin/dpkg) from one
box to another and be able to use it right away was precisely the goal
of static linking in that case.

Roland.
-- 
Roland Mas

Au royaume des aveugles, les borgnes n'ont qu'un oeil.


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

Re: libdb4.* madness in unstable

[Clint Adams]

Michael Biebl <[EMAIL PROTECTED]> sez:
> Having 5 different versions of one library is just insane imho. What are

Maybe you could help out with the bugs here:

http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED];tag=oldbdb;dist=unstable


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

Re: libdb4.* madness in unstable

[Michael Alan Dorman]

On Wed, 17 Oct 2007 10:00:58 +0200
"Francesco P. Lovergine" <[EMAIL PROTECTED]> wrote:

> On Wed, Oct 17, 2007 at 12:52:33AM -0700, Steve Langasek wrote:
> > 
> > That's equivalent to an indefinite quarantine; according to BDB
> > upstream, OpenLDAP's problems with various versions are a
> > consequence of abusing the interface, not of using "advanced
> > features".  I'm not sure why the burden here should be on BDB alone.
> > 
> 
> That remembers me some other cases where people insist to use a non
> stable C++ API instead of the C one. One could ask himself who is
> guilty: the upstream who releases as public his private functions, 
> or developer who use them ? :-D

The issues I'd heard of with respect to openldap were actually of
stability and speed, so blame my lie with both parties.

Mike.


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

Re: Bits from the Testing Security team

[Kurt Roeckx]

On Wed, Oct 17, 2007 at 03:00:55PM +0100, Ian Jackson wrote:
> > > Indeed on modern multicore systems running the decompression in a
> > > separate process allows it to be run on a separate CPU, in parallel to
> > > the other processing done by dpkg proper.  So it might be faster.
> > >
> > > (I haven't done any benchmarking but I think these conclusions are
> > > pretty obvious.)
> >
> > What I think running it in a separate process does it creating 2 pipes
> > you don't need.  You can just do everything in the local memory of 1
> > process.
> >
> > Anyway, like you said, someone needs to do benchmarks to see if either
> > solution is faster than the other.  I'm not convinced either way.
> 
> The overhead (cpu cost) of reading or writing the contents of the .deb
> a few times through some pipes is irrelevant compared to both the cpu
> cost of decompressing it and of course the cpu cost of processing each
> file during installation.

Ian,

You were saying that by having 2 processes (or threads) you might gain
something.  I'm saying that by doing it with 2 processes you also
create a new overhead which might or might not be bigger than what you
gain.  In either case, I think it's unlikely that you'll notice such a
change.

If you want to take advantages of multiple core, it's properly more
likely that you can gain something with spreading the decompression
itself over multiple cores.  You could for instance have several dpkg
subprocesses extracting a different .deb at the same time.  But I'm
not conviced this is going to gain you anything either.

> > On Tue, Oct 16, 2007 at 02:34:36PM +0100, Ian Jackson wrote:
> > > Having dpkg invoke the decompresser as a separate program provides
> > > several IMO important advantages.  It simplifies the code in dpkg, and
> > > it greatly simplifies the management of cross-version compatibility
> > > and multiple optional decompression schemes (including experimental
> > > ones), by decoupling dpkg from the decompressers.
> > 
> > I see no reason why we can't have both available.
> 
> dpkg has to be compiled one way in the distribution.
> 
> And if there is no good reason to have the decompressors bound in then
> having that facility wired into the code is just extra complexity to
> no useful purpose.

If there is an advantage to use a library instead of doing it with an
external program, it makes sense to do it.  But not everything you want
to use might have a library which you can use, so it would make sense
to atleast have the option to decompress with an external program.


Kurt


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

Re: 0-day NMUs, DELAYED/n uploads

[Lucas Nussbaum]

Hi,

This thread started on [EMAIL PROTECTED] The process that should be followed for
0-day NMUs is being discussed. (reminder: it's allowed to do 0-day NMUs
for RC bugs and release goals, for bugs older than 7 days).

Please continue the discussion on -devel@, as it's of interest to
everybody.

On 17/10/07 at 07:51 -0700, Richard Hecker wrote:
>>> If a person cannot communicate with some email, being a 'lone wolf'
>>> submitting NMUs will not benefit the project in the long term.  The
>>> NMU does not replace communication skills.
>>> 
>>
>> Mails were sent to the relevant bugs on the BTS (and thus to the
>> maintainer(s)). Do you need a personal email, because you filter out BTS
>> mails? Then we probably have another problem.
>>   
> Yes, we do have a problem. From section 5.11.1 of our
> developers reference (http://www.debian.org/doc/developers-reference),
> the admonition is to "contact the developer first, and act later." It
> appears to me that people do not even understand what the usual
> rules are for NMUs.

When dealing with a bug, it is painful to do an action at one point (notifying
the maintainer), and to have to remember that another action needs to be
done later (do the upload). The DELAYED queue helps a lot with that by
making it possible to do both actions at the same time, but still leave
some time for the maintainer to react.

The following processes seem appropriate to me:
- for bugs older than 7 days:
  - send a mail to the BTS with the NMU diff
  - at the same time, upload directly to unstable, or to DELAYED/1, 2,
  or 3, depending on the package (is it a very popular package?), the
  maintainer (is he active?) and the patch (am I 100% it won't break, or
  only 99%?)

- for bugs newer than 7 days:
  - send a mail to the BTS with the NMU diff
  - at the same time, upload to DELAYED/(7-age), or to
DELAYED/(7-age+1,2,3), depending on the same conditions as above

But it seems that some maintainers disagree. Is there a consensus that
those processes are OK? If not, what could we do, without making it too
painful for the NMUer?
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Bug#447027: ITP: gnome-device-manager -- GNOME device manager based on HAL

[Michael Biebl]

Package: wnpp
Severity: wishlist
Owner: Michael Biebl <[EMAIL PROTECTED]>

* Package name: gnome-device-manager
  Version : 0.2
  Upstream Author : David Zeuthen <[EMAIL PROTECTED]>
* URL : http://cgit.freedesktop.org/~david/gnome-device-manager/
* License : GPL
  Programming Lang: C
  Description : GNOME device manager based on HAL

This is a GNOME program to manage devices and device drivers. It's
inspired by hal-device-manager, from the HAL project, but rewritten in
C for efficiency and an outlook to actually make it manage devices
rather than just show information.

The package will be maintained within the pkg-utopia team.
http://svn.debian.org/wsvn/pkg-utopia/packages/unstable/gnome-device-manager

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (300, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.23
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



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

Re: Bug#443392: ITP: gitpkg -- helper scripts for maintaining packages with git

[Guido Guenther]

On Thu, Oct 04, 2007 at 05:40:04PM +0930, Ron wrote:
> > > ... surprised to learn that git-import-dsc can only import one
> > > .deb per repo.
> > This indeed is a limitation of git-import-dsc that could quiet simply be
> > fixed if this should be needed.
> 
> I'm not sure this is totally trivial to do correctly in the general
> case, even git-debimport only does it well enough for a few packages
> I needed to do it with (and got custom hacked for a few others).
> It would be nice to have better tools for importing source from
> old debs and other *-buildpackage repos though (my cvs-buildpackage
> repos don't seem to do well with the cvs -> git tools currently
> available).
Basically you can use git-import-orig repeatedly to import both the
unpacked debian source packages as well as the upstream tarballs. This
should preserver more than enough history, very similar than what you'd
do to import an NMU as described in the manual.
Cheers,
 -- Guido


signature.asc
Description: Digital signature

Re: Bug#443392: ITP: gitpkg -- helper scripts for maintaining packages with git

[Guido Guenther]

On Fri, Oct 05, 2007 at 02:15:11PM +0930, Ron wrote:
> Sorry, perhaps I wasn't clear there.  I'm not advocating total chaos
> inside any single repo, or any group of repos maintained by the same
> people.  Localised consistency in these things is highly desirable,
> for all the reasons you mention and more.  The issue I see is that
> global consistency is an impossible goal, there are already many such
> conventions among different groups and its highly unlikely they will
> ever converge without some really compelling reason and a lot of
> renaming of existing branches/tags in existing repos.

> 
> If I'm pulling an upstream branch from such a source I have two choices,
> re-tag it and rename its branches, or deal with the upstream system and
> minimise confusion when communicating with them about tag/branch names.
This is why git-buildpackage and the other tools can be taught
easily about the desired repository layout. You can specify the branch
names to act on by default as well as the desired tag format used for
upstream and debian branches. Maybe the documentation wasn't very clear
on this, I've updated the docs at:
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html
The documentation shipped with the current packges in
unstable/experimental is a bit outdated.

[..snip..]
> This is the curse of frameworks in general.  You trade your ability to
> work in heterogeneous environments for the convenience of performing
> certain functions by rote.  That doesn't necessarily make them Bad,
> it just makes them difficult or impossible to use in circumstances
> that they didn't envisage or assume when they were first created.
I honestly can't figure out which repository layouts aren't suitable for
gbp - I'm still interested to hear which workflows gbp doesn't cover
_easily_ at the moment though.

[..snip..]
> > > So if you happen to have many different git repos, all using different
> > > conventions for these things, you can still use the same tool, without
> > > needing to modify its config, to extract source packages from all of them.
> > I don't see why this can't be done with git-buildpackage too. While you
> > do:
> > 
> > gitpkg branch1 branch2
> > 
> > git-buildpackage does:
> > 
> > git-buildpackage --git-debian-branch=branch1 --git-upstream-branch=branch2
> 
> The biggest practical difference there right now (aside from the amount
> of typing ;) is that the former is actually:
> 
> gitpkg tree-ish [tree-ish]
> 
> I agree that is an improvement that shouldn't be too hard to apply to
> gbp too though, but I'm not sure how deep the assumption of being on
> a branch HEAD really runs in it.
I added this functionality to the current package in experimental,
basically since I wanted to be able to do a clean build after an export
since quiet some time.

[..snip..] 
> If you are pulling upstream source directly (as opposed to importing
> tarballs on an upstream branch), then the upstream branch may have
> similar issues, the tagged release that you want to make a deb of
> may no longer be their HEAD commit at the time you make it, even if
> your deb branch is at its current head.  You may even want to package
> from a commit slightly later than their tagged release if some errata
> was committed shortly after that (as an alternative to cherry picking
> what is really a fast-forward on the upstream branch).
As I sad the simple solution was to create a new branch that used the
tree you wanted as head and use that one as upstream-branch. The version
in experimental tries to figure out the upstream version by itself now
(by looking at the corresponding to the version in debian/changelog) if
that doesn't fit you can now also pass in any treeish object with
--upstream-branch.

> gitpkg also copes automatically with 'debian native' packages and
> repos that aren't debian native but where everything is on a single
> branch (I don't really recommend the latter given the choice either,
> but it is a trivial case to handle ;).  It's not clear to me if gbp
> can handle them yet either?
You can do this too by simply giving a treeish object to
--upstream-branch when running git-buildpackage, but this doesn't look
like a clean and easily maintainable repo layout to me.
Cheers,
 -- Guido


signature.asc
Description: Digital signature

Bug#447067: O: libapache2-mod-auth-pam -- module for Apache2 which authenticate using PAM

[Piotr Roszatycki]

Package: wnpp
Severity: normal

I'd like to orphan the libapache2-mod-auth-pam. New maintainer can
choose YADA based package from Debian or CDBS package from Ubuntu.

-- 
 .''`.Piotr Roszatycki
: :' :mailto:[EMAIL PROTECTED]
`. `' mailto:[EMAIL PROTECTED]
  `-


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

Bug#447064: O: libapache2-mod-auth-plain -- Module which provides plaintext authentication

[Piotr Roszatycki]

Package: wnpp
Severity: normal

Hi.

I'd like to orphan the Debian package libapache2-mod-auth-plain and
the upstream hosted on Alioth http://mod-auth-plain.alioth.debian.org/

This package provides the simplest authorization for Apache. Also the
htpasswd file can be hold in current directory for htaccess, so it is
the module of choise for shared webhosting environments.

The Debian source package is available as YADA (by myself for Debian)
or CDBS (by [EMAIL PROTECTED] for Ubuntu) package. Please choose what
you want.

Also I can orphan the project on Alioth which is used as upstream for
Debian package. In such case please contact me directly.

--
 .''`.Piotr Roszatycki
: :' :mailto:[EMAIL PROTECTED]
`. `' mailto:[EMAIL PROTECTED]
  `-


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

Re: 0-day NMUs, DELAYED/n uploads

[Luk Claes]

On Wed, Oct 17, 2007 at 06:03:14PM +0200, Lucas Nussbaum wrote:
> Hi,

Hi

> This thread started on [EMAIL PROTECTED] The process that should be followed 
> for
> 0-day NMUs is being discussed. (reminder: it's allowed to do 0-day NMUs
> for RC bugs and release goals, for bugs older than 7 days).
> 
> Please continue the discussion on -devel@, as it's of interest to
> everybody.
> 
> On 17/10/07 at 07:51 -0700, Richard Hecker wrote:
> >>> If a person cannot communicate with some email, being a 'lone wolf'
> >>> submitting NMUs will not benefit the project in the long term.  The
> >>> NMU does not replace communication skills.
> >>> 
> >>
> >> Mails were sent to the relevant bugs on the BTS (and thus to the
> >> maintainer(s)). Do you need a personal email, because you filter out BTS
> >> mails? Then we probably have another problem.

Mailing the BTS (with the NMU patch) when you do an NMU is indeed still
required.

> > Yes, we do have a problem. From section 5.11.1 of our
> > developers reference (http://www.debian.org/doc/developers-reference),
> > the admonition is to "contact the developer first, and act later." It
> > appears to me that people do not even understand what the usual
> > rules are for NMUs.
> 
> When dealing with a bug, it is painful to do an action at one point (notifying
> the maintainer), and to have to remember that another action needs to be
> done later (do the upload). The DELAYED queue helps a lot with that by
> making it possible to do both actions at the same time, but still leave
> some time for the maintainer to react.

Indeed that's a possibility.

> The following processes seem appropriate to me:
> - for bugs older than 7 days:
>   - send a mail to the BTS with the NMU diff
>   - at the same time, upload directly to unstable, or to DELAYED/1, 2,
>   or 3, depending on the package (is it a very popular package?), the
>   maintainer (is he active?) and the patch (am I 100% it won't break, or
>   only 99%?)

That's ok, though when in doubt it's also ok to first contact the
maintainer...

> - for bugs newer than 7 days:
>   - send a mail to the BTS with the NMU diff
>   - at the same time, upload to DELAYED/(7-age), or to
> DELAYED/(7-age+1,2,3), depending on the same conditions as above

This is not so clear cut: If in doubt, please don't do this. This can be
warranted though for some kind of bugs. In general I would propose to
focus on bugs that are older than 7 days. Personally I would start with
bugs older than 10 or 14 days and only look at more recent ones later...

> But it seems that some maintainers disagree. Is there a consensus that
> those processes are OK? If not, what could we do, without making it too
> painful for the NMUer?

I think we can say there is consensus for bugs older than 7 days. There
is also no real problem with the process for bugs newer than that, but I
would advise to focus on the first category.

The most important thing is of course to respect the maintainer and
please try to make sure your NMU is well tested.

Cheers

Luk


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

Bug#447079: O: litmus -- WebDAV server protocol compliance test suite

[Piotr Roszatycki]

X-Debbugs-CC: debian-devel@lists.debian.org
Package: wnpp
Severity: normal

Hi.

I'd like to orphan the litmus package.

It is available the new upstream version and some simple bugs have to
be resolved.

-- 
 .''`.Piotr Roszatycki
: :' :mailto:[EMAIL PROTECTED]
`. `' mailto:[EMAIL PROTECTED]
  `-



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

#447068: O: libapache-mod-rpaf -- module for Apache which takes the last IP from the 'X-Forwarded-For' header

[Piotr Roszatycki]

Package: wnpp
Severity: normal

Hi.

I'd like to orphan the libapache-mod-rpaf package. This package is
really useful is the mod_proxy or squid is used before Apache.

Probably the package should be renamed to libapache2-mod-rpaf and the
dependecies on Apache 1.3 have to be removed.

--
 .''`.Piotr Roszatycki
: :' :mailto:[EMAIL PROTECTED]
`. `' mailto:[EMAIL PROTECTED]
  `-


-- 
 .''`.Piotr Roszatycki
: :' :mailto:[EMAIL PROTECTED]
`. `' mailto:[EMAIL PROTECTED]
  `-


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

Status of gfortan transition

[Kumar Appaiah]

Dear Debian developers,

Bidding adieu to the old Fortran compiler and using gfortran is one of
the proposed Lenny release goals[1]. However, the showstoppes,
definitely, are lapack3 and atlas. There hasn't been any movement on
that side, and it seems that the packages could do with some help.

This has been a long standing issue. Also, Atlas does have new
upstream releases, albeit not declared "stable". However, I feel that
must also be packaged for Debian.

As for me, I am not a Fortran or a compiler expert. But I will
definitely help in testing any releases which you make, since that is
something in my capability.

Thanks.

http://lists.debian.org/debian-toolchain/2007/07/msg0.html
-- 
Kumar Appaiah,
458, Jamuna Hostel,
Indian Institute of Technology Madras,
Chennai - 600036


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

Bug#98549: Feel Like Chatting

[Holly Sears]

Hi My Name is Holly
I am bored and would love some company 
I love to chat online and meet new people
If you want I can send you some photos email me for the pics




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