Re: Linda warnings

[Eric Dorland]

* Tollef Fog Heen ([EMAIL PROTECTED]) wrote:
> * Eric Dorland 
> 
> [Substituting your fixed sentence in the text below]
> 
> | I think a build-dependency on automake and autoconf is almost always
> | a bad idea. It makes the build more unpredictable, which is
> | generally a bad thing. You should just run automake and/or autoconf
> | on the unpacked source and ship it in the .diff.gz. An extra 2K
> | won't hurt.
> 
> You can argue this for a lot of files.  An example is texinfo files
> which get their headers updated with information in the language of
> the build locale.  Or why should docs be built as part of the build
> process at all?  Or X fonts?
> 
> 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.   
 

-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

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

[HELP] libldap2 2.1.30 breakage?, guru for ld.so needed

[Torsten Landschoff]

Hi *, 

People following the OpenLDAP packages might remember this change:

  openldap2 (2.1.30-7) unstable; urgency=high

* Stephen Frost <[EMAIL PROTECTED]>
  + debian/move_files: make libldap a symlink to libldap_r, as carrying
two versions of this library around is more trouble than it's worth,
and can cause glorious segfaults down the line
(closes: #306258, #302296, #306546)

At first sight this looked (for me) like making sense and having no
negative implications. Of course reality was different - ldconfig had
problems setting the right symbolic links. 

Today I found out the reason. It was not that it just removes symbolic
links it can't make sense of. Rather the problem is that the SONAME of
that library now does not match the name anymore. 

libldap.so.2 used to have the SONAME libldap.so.2 as you would expect :)
Now the libldap.so.2 is a symlink to libldap_r.so.2 which has SONAME
libldap_r.so.2. 

I wonder which implications that could have when applications are
linking to libldap.so.2 (as the SONAME is no longer found). 


Therefore I thought it might be a good idea to relink libldap_r.so.2
using libtool and create libldap.so.2 with matching soname. Now I wonder
what will happen if some program decides he wants to link both
libldap.so.2 and libldap_r.so.2. 

Suggestions how to fix that for real before getting sarge out of the
door with this risk that I don't feel I can estimate?

Thanks!

Torsten


signature.asc
Description: Digital signature

Re: [HELP] libldap2 2.1.30 breakage?, guru for ld.so needed

[Simon Richter]

Hi,

Torsten Landschoff schrieb:

> Suggestions how to fix that for real before getting sarge out of the
> door with this risk that I don't feel I can estimate?

Build a dumy libldap.so.2 with the same SONAME that consists of a NEEDED
entry for libldap_r.so.2 only.

   Simon


signature.asc
Description: OpenPGP digital signature

Re: [HELP] libldap2 2.1.30 breakage?, guru for ld.so needed

[Nigel Jones]

Unless there is a related RC bug there, I don't think it's gonna
matter when the change is to get it in sarge (i personally have not
seen any RC bugs though...)

On 30/05/05, Torsten Landschoff <[EMAIL PROTECTED]> wrote:
> Hi *,
> 
> People following the OpenLDAP packages might remember this change:
> 
>   openldap2 (2.1.30-7) unstable; urgency=high
> 
> * Stephen Frost <[EMAIL PROTECTED]>
>   + debian/move_files: make libldap a symlink to libldap_r, as carrying
> two versions of this library around is more trouble than it's worth,
> and can cause glorious segfaults down the line
> (closes: #306258, #302296, #306546)
> 
> At first sight this looked (for me) like making sense and having no
> negative implications. Of course reality was different - ldconfig had
> problems setting the right symbolic links.
> 
> Today I found out the reason. It was not that it just removes symbolic
> links it can't make sense of. Rather the problem is that the SONAME of
> that library now does not match the name anymore.
> 
> libldap.so.2 used to have the SONAME libldap.so.2 as you would expect :)
> Now the libldap.so.2 is a symlink to libldap_r.so.2 which has SONAME
> libldap_r.so.2.
> 
> I wonder which implications that could have when applications are
> linking to libldap.so.2 (as the SONAME is no longer found).
> 
> Therefore I thought it might be a good idea to relink libldap_r.so.2
> using libtool and create libldap.so.2 with matching soname. Now I wonder
> what will happen if some program decides he wants to link both
> libldap.so.2 and libldap_r.so.2.
> 
> Suggestions how to fix that for real before getting sarge out of the
> door with this risk that I don't feel I can estimate?
> 
> Thanks!
> 
> Torsten
> 
> 
> BodyID:25699729.2.n.logpart (stored separately)
> 
> 


-- 
N Jones

Re: please help a poor student

[Guillermo Gutierrez Herrera]

U can get like-debian CDs at http://shipit.ubuntulinux.org/ at not cost

El dom, 29-05-2005 a las 15:41 +0100, ratikanta rath escribió:
> Note- I began liking debian after i heard of it.
> Please help this poor student by mailing me the CDs if
> you have
> [...]
> 
> My address:
> Ratikanta Rath
> At/PO: Jarasingha
> Dist.: Angul
> Orissa, India
> Postal Code: 759143

-- 
Guillermo Gutierrez Herrera <[EMAIL PROTECTED]>
Redirects: <[EMAIL PROTECTED]>
Key ID BA56673E 2005-05-22
Key fingerprint = EAEB BA85 74A4 74D2 FB9F  0B8D 503A 08D7 BA56 673E
to import, type: gpg --keyserver pgp.rediris.es --recv-key BA56673E


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

Re: RFC: A new video-related section

[Enrico Zini]

On Sat, May 28, 2005 at 02:06:03PM +0200, Philipp Kern wrote:

> Is it already used in any package management tools? Or is the debedit 
> GUI currently the only program using the preliminary database?

There is a library being implemented (libapt-front.alioth.debian.org) to
wrap libapt and also include other data sources (such as libdebtags)

> By the way debedit spew some debugging output at me and seems also a bit 
> laggy. Is it still beta? (:

In a way, yes: it's useful as a tagging tool, and it's my playground to
test user interfaces-related features, so, well... :)

There's a new improved version in experimental (and an even newer on
monday), which has less debugging output but it's still quite laggy.

Reason for being laggy is that there's some newly developed algorithms
there which are more into "let's see if this works" stage than in a
"let's make this efficient".

It'd actually be quite interesting to redesign these algorithms
efficiently: if someone knows C++ and STL and algorithmics and wants a
challenge, please contact me.


Ciao,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: RFC: A new video-related section

[Enrico Zini]

On Fri, May 27, 2005 at 02:13:56PM +0200, Pierre Habouzit wrote:

> the right thing to do would be to switch from sections, to keywords, so 
> that kmplayer could live in sound + video + kde, instead of multimedia 
> that is not very informative.

I want to stress what Adrian and Benjamin said a bit more: whoever is
interested in doing this, please join us in the
[EMAIL PROTECTED] mailing list[1].


Ciao,

Enrico


[1] http://lists.alioth.debian.org/mailman/listinfo/debtags-devel
--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: FW: Processing of tla-load-dirs_1.0.21ubuntu1_source.changes

[Adrian Bunk]

On Wed, May 25, 2005 at 11:11:09AM +0100, Colin Watson wrote:
> On Wed, May 25, 2005 at 07:39:30AM +1000, Matthew Palmer wrote:
> > On Sun, May 22, 2005 at 03:56:35PM -0500, John Goerzen wrote:
> > > Can anyone tell me what this means, and who is trying to upload this to
> > > Debian without even sending me a patch first?
> > 
> > What it means: the Ubuntu maintainer for tla-load-dirs (sorry, don't know
> > who) managed to send their package in the direction of the Debian upload
> > queue instead of the Ubuntu one.  I'm not sure why this happens, because an
> > Ubuntu maintainer should (I presume) change their dput/dupload defaults to
> > Ubuntu, and the dput/dupload packages in Ubuntu should probably have their
> > defaults changed to Ubuntu, not Debian.
> 
> It requires two mistakes to actually get such an upload accepted (you
> need to get the distribution wrong in debian/changelog, *and* you need
> to get the upload target wrong). People have made one or other mistake
> in the past, but I don't think anyone's managed both simultaneously yet.
>...

Silly question:
Is the GPG check (that failed in this case) really after the parsing of 
the file contents?

> Cheers,
> Colin Watson   [EMAIL PROTECTED]

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Re: [frankie@debian.org: Status of kernel-patches in sarge]

[Adrian Bunk]

On Sun, May 22, 2005 at 10:02:06PM +0200, Francesco Paolo Lovergine wrote:
> On Sun, May 22, 2005 at 12:35:59AM +0200, Adrian Bunk wrote:
> > On Sat, May 21, 2005 at 10:04:02AM +0200, Francesco Paolo Lovergine wrote:
> > 
> > > The check shown below is almost complete (but for a couple of 2.2 patches
> > > and per-arch patches).
> > > I'm asking if mass bug report filing is opportune at this stage.
> > > IMHO patches which cannot be applied to debian kernel-sources are almost
> > > unuseful and should be removed from sarge...
> > >...
> > 
> > I'd even ask whether all these patches are _really_ required for sarge.
> > 
> 
> Eh eh, maybe that could be ask for quite a lot of packages around in sarge :-)
> 
> > Each of the patches might be broken by a security update for the 
> > kernel and each of them requires security support.
> > 
> 
> I'd expect maintainers drop patches which are orphaned by the upstream
> or whose maintainance would be a problem... 

The number of patches that do not apply shown in the initial message of 
this thread shows that your expectation is wrong.

> Francesco P. Lovergine

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Re: Example where testing-security was used?

[Adrian Bunk]

On Sun, May 22, 2005 at 08:10:35PM -0700, Steve Langasek wrote:
> On Sun, May 22, 2005 at 12:46:09AM +0200, Adrian Bunk wrote:
> > As far as I understood it, the missing infrastructure for 
> > testing-security was the reason why the release of sarge was delayed by 
> > more than half a year.
> 
> > As far as I have seen, it seems most security updates go either through 
> > unstable or through testing-proposed-updates.
> 
> > Can anyone point me to an example where testing-security has actually 
> > been used?
> 
> At present, unfortunately not.
> 
> This does not obviate the need for testing-security to be brought on-line
> and tested prior to the freeze; the woody release was delayed for about a
> month because of the lack of usable autobuilder infrastructure for security
> updates, and if we had tried to freeze sarge before the same infrastructure
> was available, we would have had the same problem again (except compounded
> with others this time, like ftp-master not scaling to handle the added
> load).

That you need autobuilders for sarge security update once sarge ist 
released is obvious.

But setting up autobuilders doesn't require a new infrastructure
(and shouldn't require more than half a year).
Wasn't the infrastructure a prerequisite for woody and is working?

I understand that the testing security infrastructure is a solution, but 
I still don't understand the probelm it was required to solve for.

> Steve Langasek

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Re: FW: Processing of tla-load-dirs_1.0.21ubuntu1_source.changes

[Colin Watson]

On Mon, May 30, 2005 at 12:21:04PM +0200, Adrian Bunk wrote:
> On Wed, May 25, 2005 at 11:11:09AM +0100, Colin Watson wrote:
> > On Wed, May 25, 2005 at 07:39:30AM +1000, Matthew Palmer wrote:
> > > What it means: the Ubuntu maintainer for tla-load-dirs (sorry, don't know
> > > who) managed to send their package in the direction of the Debian upload
> > > queue instead of the Ubuntu one.  I'm not sure why this happens, because 
> > > an
> > > Ubuntu maintainer should (I presume) change their dput/dupload defaults to
> > > Ubuntu, and the dput/dupload packages in Ubuntu should probably have their
> > > defaults changed to Ubuntu, not Debian.
> > 
> > It requires two mistakes to actually get such an upload accepted (you
> > need to get the distribution wrong in debian/changelog, *and* you need
> > to get the upload target wrong). People have made one or other mistake
> > in the past, but I don't think anyone's managed both simultaneously yet.
> >...
> 
> Silly question:
> Is the GPG check (that failed in this case) really after the parsing of 
> the file contents?

No; that's the very first check jennifer does. As I said in the first
line you trimmed from your quote, you have to be in both upload keyrings
for it to be an issue.

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: Example where testing-security was used?

[Wouter Verhelst]

On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote:
> But setting up autobuilders doesn't require a new infrastructure
> (and shouldn't require more than half a year).

In this case, it did because of scalability issues. This was known and
publicised for quite a while; so either you're being deliberately
obtruse now, or you didn't properly do your homework before sending that
post.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: Example where testing-security was used?

[Mark Brown]

On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote:

> But setting up autobuilders doesn't require a new infrastructure
> (and shouldn't require more than half a year).
> Wasn't the infrastructure a prerequisite for woody and is working?

It turned out that the central part of the existing infrastructure
didn't scale up well enough to cope with the new architectures in sarge.
The number of individual buildds asking which packages were avaliable to
build created load problems - check the mailing list archives for more
detail.  I can't remember if improvements in redundancy weren't an issue
either.

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


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

Re: roxen4_4.0.325-2_i386.changes REJECTED

[Turbo Fredriksson]

Quoting Debian Installer <[EMAIL PROTECTED]>:

> Rejected: roxen4_4.0.325-2_i386.changes: a file with this name already exists 
> in the Done directory.
> Rejected: md5sum and/or size mismatch on existing copy of 
> roxen4_4.0.325-2.diff.gz.
> Rejected: roxen4-doc_4.0.325-2_all.deb: old version (4.0.325-2) in unstable 
> >= new version (4.0.325-2) targeted at unstable.
> Rejected: roxen4-doc_4.0.325-2_all.deb: can not overwrite existing copy 
> already in the archive.
> Rejected: md5sum and/or size mismatch on existing copy of 
> roxen4-doc_4.0.325-2_all.deb.
> Rejected: md5sum and/or size mismatch on existing copy of 
> roxen4_4.0.325-2.dsc.
> Rejected: roxen4_4.0.325-2_i386.deb: old version (4.0.325-2) in unstable >= 
> new version (4.0.325-2) targeted at unstable.
> Rejected: roxen4_4.0.325-2_i386.deb: can not overwrite existing copy already 
> in the archive.
> Rejected: md5sum and/or size mismatch on existing copy of 
> roxen4_4.0.325-2_i386.deb.
> Rejected: roxen4_4.0.325-2.dsc: old version (4.0.325-2) in unstable >= new 
> version (4.0.325-2) targeted at unstable.
> Rejected: can not overwrite existing copy of 'roxen4_4.0.325-2.diff.gz' 
> already in the archive.

Oki, I forgot that I already uploaded a -2 version. Now, in testing
(which this was intended for) I have -1...

I haven't done an update like this in years, but could someone
verify that I should take the '-1' version, do the modifications
(bug #309247) and upload a '-1.1' (with urgency=high)?


Oh, and could I have that '-2' version back? :) I deleted all
traces of it locally :(.

-- 
Serbian strategic Peking plutonium killed Semtex Noriega Delta Force
tritium Khaddafi KGB fissionable pits Ft. Bragg terrorist
[See http://www.aclu.org/echelonwatch/index.html for more about this]


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

Re: Release update: minor delay; no non-RC fixes; upgrade reports

[Adrian Bunk]

On Fri, May 27, 2005 at 11:57:52PM +0200, Andreas Barth wrote:
>...
> Timeline
> 
>...
>   1 June 2005
>   ~15 RC bugs (excluding security bugs)
>   0 RC bugs not tagged "sarge"
>...

How do you measure RC bugs?
If you only look at the output of the BTS - that's horribly wrong.

Why?

Because many bugs that are already fixed in sid and therefore closed are 
still present in sarge.

Finding these issues is one of the prices for freezing testing 
instead of unstable [1].

Since it seems noone of the release team bothered to pay this part of 
the price for the testing release process, I'm sometimes using one or 
two spare hours to go a bit through update_excuses and report half a 
dozen of such issues.

Steve saw this, and before the latest release update he sent (which was 
the one before yours), he asked me in a private mail about a prediction 
how many such RC bugs I'd expect in sarge for inclusion in his release 
update.

It seems my prediction about the number of such issues didn't match his 
wishes regarding the state of sarge, and he did therefore neither answer 
my email nor mention this in the release update nor does it seem he 
assigned a member of the release team to do this work properly.

If you are using the testing release process, please do the work that is 
required for doing it properly.

And if you'd have done it in time these issues were no longer present 
now that you announce the release date was only a few days ahead.

> Cheers,
> Andi Barth

TIA
Adrian

[1] And no, version tracking in the BTS wouldn't prevent this problem.
In my experience, there are so many of these issues reported with
a wrong version or manually closed or even without any bug report in 
the BTS that claiming version tracking might eliminate this problem 
sounds like a bad joke.

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Re: Release update: minor delay; no non-RC fixes; upgrade reports

[Nigel Jones]

http://bts.turmzimmer.net/details.php?ignore=sid&ignsec=on&fullcomment=on&new=7

thats a decent unoffical count...

On 30/05/05, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Fri, May 27, 2005 at 11:57:52PM +0200, Andreas Barth wrote:
> >...
> > Timeline
> > 
> >...
> >   1 June 2005
> >   ~15 RC bugs (excluding security bugs)
> >   0 RC bugs not tagged "sarge"
> >...
> 
> How do you measure RC bugs?
> If you only look at the output of the BTS - that's horribly wrong.
> 
> Why?
> 
> Because many bugs that are already fixed in sid and therefore closed are
> still present in sarge.
> 
> Finding these issues is one of the prices for freezing testing
> instead of unstable [1].
> 
> Since it seems noone of the release team bothered to pay this part of
> the price for the testing release process, I'm sometimes using one or
> two spare hours to go a bit through update_excuses and report half a
> dozen of such issues.
> 
> Steve saw this, and before the latest release update he sent (which was
> the one before yours), he asked me in a private mail about a prediction
> how many such RC bugs I'd expect in sarge for inclusion in his release
> update.
> 
> It seems my prediction about the number of such issues didn't match his
> wishes regarding the state of sarge, and he did therefore neither answer
> my email nor mention this in the release update nor does it seem he
> assigned a member of the release team to do this work properly.
> 
> If you are using the testing release process, please do the work that is
> required for doing it properly.
> 
> And if you'd have done it in time these issues were no longer present
> now that you announce the release date was only a few days ahead.
> 
> > Cheers,
> > Andi Barth
> 
> TIA
> Adrian
> 
> [1] And no, version tracking in the BTS wouldn't prevent this problem.
> In my experience, there are so many of these issues reported with
> a wrong version or manually closed or even without any bug report in
> the BTS that claiming version tracking might eliminate this problem
> sounds like a bad joke.
> 
> --
> 
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 
> 


-- 
N Jones

Re: Release update: minor delay; no non-RC fixes; upgrade reports

[Roberto C. Sanchez]

On Mon, May 30, 2005 at 12:59:26PM +0200, Adrian Bunk wrote:
> 
> Finding these issues is one of the prices for freezing testing 
> instead of unstable [1].
> 

CMIIW, but isn't unstable a place where architectures can be out of
sync?  To get into a testing, a package has to pass the cooling off
period with no >important bugs and must be in sync on all architectures.
Correct?  Freezing unstable doesn't make much sense if it means lots of
extra work just to sync up package versions across architectures.  The
only that would work is to require that packages successfully build on
all architectures *prior* to being admitted to the archive.

-Roberto

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


pgpI8C5czx4iR.pgp
Description: PGP signature

Bug#311270: ITP: libtidy-ruby -- Ruby interface to HTML Tidy Library

[Dmitry Borodaenko]

Package: wnpp
Severity: wishlist
Owner: Dmitry Borodaenko <[EMAIL PROTECTED]>


* Package name: libtidy-ruby
  Version : 1.1.2
  Upstream Author : Kevin Howe 
* URL : http://rubyforge.org/projects/tidy/
* License : Ruby license (dual GPL and BSD-like)
  Description : Ruby interface to HTML Tidy Library

HTML Tidy corrects markup in a way compliant with the latest standards,
and optimal for the popular browsers.

This package contains Tidy module for Ruby.


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (990, 'unstable'), (50, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-686
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)


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

Bug#311271: ITP: samizdat -- Collaboration and open publishing engine

[Dmitry Borodaenko]

Package: wnpp
Severity: wishlist
Owner: Dmitry Borodaenko <[EMAIL PROTECTED]>


* Package name: samizdat
  Version : 0.5.5
  Upstream Author : Dmitry Borodaenko <[EMAIL PROTECTED]>
* URL : http://www.nongnu.org/samizdat/
* License : GPL
  Description : Collaboration and open publishing engine

Generic RDF-based Web engine intended for building collaboration and
open publishing web sites. Samizdat engine allows everyone to publish,
view, comment, edit, and aggregate text and multimedia resources, vote
on ratings and classifications, filter resources by flexible sets of
criteria.

Additional description for libsamizdat-ruby:

Samizdat module is usable outside of Samizdat engine and provides
following classes:
 * Cache: time-limited FIFO cache
 * Storage: relational RDF storage
 * Sanitize: HTML validation


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (990, 'unstable'), (50, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-686
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)


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

Dear Adrian Bunk, Please hold off a week or two

[Simon Huggins]

Adrian, I've noticed lately that almost every post you send is about the
release; Pointing out problems with some feature or other of it or with
the actions of the hard working people who are trying to get sarge out
the door.

Do you think you could manage to leave your critisms til next week when
we might have released and turn them into constructive criticisms
instead of merely demanding pieces of information from the release team?

I don't know what you hope to achieve by doing this.  "Never attribute
to malice what can be explained by ignorance".  Maybe you just don't
realise that you're pestering the release team and others and drawing
them into pointless debates which won't help release sarge.

I'd like to ask you publically to hold off for a couple of weeks with
these questions.  I'm sure you have an entirely rational reason for
asking them and that it will end up being productive for Debian but I
honestly think it would be better if they were asked later on.  A
post-mortem of this release in order to better prepare for Etch might
indeed help us and I can only imagine you're itching to write it given
the number of questions you've asked.

Once sarge releases I'm sure there'll be plenty of time to talk about
how to get a quicker, predictable release schedule for Etch.

Thanks,

-- 
 ,--huggie-at-earth-dot-listuff-thing-stuff--DF5CE2B4--.
_| "1 girl was just abducted." - Mulder "Kidnapped." - Scully  |_
 | "Potato, potato.." - Mulder |
 `- http://www.earth.li/~huggie/ - http://www.blackcatnetworks.co.uk/ -'


signature.asc
Description: Digital signature

Re: Release update: minor delay; no non-RC fixes; upgrade reports

[Adrian Bunk]

On Mon, May 30, 2005 at 11:04:51PM +1200, Nigel Jones wrote:

> http://bts.turmzimmer.net/details.php?ignore=sid&ignsec=on&fullcomment=on&new=7
> 
> thats a decent unoffical count...

... that doesn't (and can't) in any way address the problem I described 
in my email.

> N Jones

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Re: Example where testing-security was used?

[Adrian Bunk]

On Mon, May 30, 2005 at 12:47:14PM +0200, Wouter Verhelst wrote:
> On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote:
> > But setting up autobuilders doesn't require a new infrastructure
> > (and shouldn't require more than half a year).
> 
> In this case, it did because of scalability issues. This was known and
> publicised for quite a while; so either you're being deliberately
> obtruse now, or you didn't properly do your homework before sending that
> post.


Sorry if I'm too dumb, but I do still not get it.


Perhaps I'm confused becaused it's called _testing_-security - but it 
is never used for testing and therefore seems to not be required for 
security support in testing.

Where exactly are the publicised scalability issues?

Are the stable-security autobuilders not capable of handling two stable 
releases (AFAIR they were at potato/woody times, but my memory might be 
wrong)?


Yes, I might be too dumb for understanding this issue.

Please give me dumb person a simple explanation when the 
testing-security infrastructure will actually be used.


TIA
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Re: Example where testing-security was used?

[Michael Ablassmeier]

On 2005-05-21, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> Can anyone point me to an example where testing-security has actually 
> been used?

http://lists.debian.org/debian-security-announce/debian-security-announce-2005/msg00111.html
http://lists.debian.org/debian-security-announce/debian-security-announce-2005/msg00112.html

bye,
- michael


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

Re: [frankie@debian.org: Status of kernel-patches in sarge]

[Francesco Paolo Lovergine]

On Mon, May 30, 2005 at 12:19:11PM +0200, Adrian Bunk wrote:
> > I'd expect maintainers drop patches which are orphaned by the upstream
> > or whose maintainance would be a problem... 
> 
> The number of patches that do not apply shown in the initial message of 
> this thread shows that your expectation is wrong.
> 

... well, of course after pointing the issue for them :-)

-- 
Francesco P. Lovergine


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

Re: Example where testing-security was used?

[Hamish Moffatt]

On Mon, May 30, 2005 at 11:48:54AM +0100, Mark Brown wrote:
> On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote:
> 
> > But setting up autobuilders doesn't require a new infrastructure
> > (and shouldn't require more than half a year).
> > Wasn't the infrastructure a prerequisite for woody and is working?
> 
> It turned out that the central part of the existing infrastructure
> didn't scale up well enough to cope with the new architectures in sarge.

There are no new architectures in sarge.

> The number of individual buildds asking which packages were avaliable to
> build created load problems - check the mailing list archives for more
> detail.  I can't remember if improvements in redundancy weren't an issue
> either.

This part is true.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: Example where testing-security was used?

[Mark Brown]

On Mon, May 30, 2005 at 10:48:38PM +1000, Hamish Moffatt wrote:
> On Mon, May 30, 2005 at 11:48:54AM +0100, Mark Brown wrote:

> > It turned out that the central part of the existing infrastructure
> > didn't scale up well enough to cope with the new architectures in sarge.

> There are no new architectures in sarge.

Oh, that's surprising.  In any case, the problem with the new
architectures would have been the increase in the number of buildds
rather than the additional architectures per se - it's that which was
the problem.

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


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

Re: [HELP] libldap2 2.1.30 breakage?, guru for ld.so needed

[Stephen Frost]

* Simon Richter ([EMAIL PROTECTED]) wrote:
> Torsten Landschoff schrieb:
> 
> > Suggestions how to fix that for real before getting sarge out of the
> > door with this risk that I don't feel I can estimate?
> 
> Build a dumy libldap.so.2 with the same SONAME that consists of a NEEDED
> entry for libldap_r.so.2 only.

Completely breaks dlopen()'ings of libldap2.  Don't know if there are
any in sarge but don't see any reason to break them if there are.

Stephen


signature.asc
Description: Digital signature

Re: [HELP] libldap2 2.1.30 breakage?, guru for ld.so needed

[Stephen Frost]

* Nigel Jones ([EMAIL PROTECTED]) wrote:
> Unless there is a related RC bug there, I don't think it's gonna
> matter when the change is to get it in sarge (i personally have not
> seen any RC bugs though...)

There's RC bugs all over this.

Stephen


signature.asc
Description: Digital signature

Re: [HELP] libldap2 2.1.30 breakage?, guru for ld.so needed

[Stephen Frost]

* Torsten Landschoff ([EMAIL PROTECTED]) wrote:
> At first sight this looked (for me) like making sense and having no
> negative implications. Of course reality was different - ldconfig had
> problems setting the right symbolic links. 

setting the right symbolic links?  It's not being used to set the
symbolic links any different than it was before, it's just at the end we
twiddle them a bit because having both libraries was a serious problem.

> Today I found out the reason. It was not that it just removes symbolic
> links it can't make sense of. Rather the problem is that the SONAME of
> that library now does not match the name anymore. 

Well, no, but the linker can handle that.

> libldap.so.2 used to have the SONAME libldap.so.2 as you would expect :)
> Now the libldap.so.2 is a symlink to libldap_r.so.2 which has SONAME
> libldap_r.so.2. 
> 
> I wonder which implications that could have when applications are
> linking to libldap.so.2 (as the SONAME is no longer found). 

Nothing should care except for the runtime linker, which should handle
the situation correctly.

> Therefore I thought it might be a good idea to relink libldap_r.so.2
> using libtool and create libldap.so.2 with matching soname. Now I wonder
> what will happen if some program decides he wants to link both
> libldap.so.2 and libldap_r.so.2. 

All hell breaks loose, that's what caused the various RC bugs I closed
with the message above.  You end up randomly getting one set of symbols
that expects to do threading and locking and another set that doesn't.

> Suggestions how to fix that for real before getting sarge out of the
> door with this risk that I don't feel I can estimate?

Have you actually got a specific problem with the changes I did, or
really, the results of them?  There were a couple problems where people
had old libldap2's hanging around (which is a rather serious mistake
anyway...) but I havn't seen any other problems with that change yet...

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HELP] libldap2 2.1.30 breakage?, guru for ld.so needed

[Simon Richter]

Hi,

Stephen Frost schrieb:

> Completely breaks dlopen()'ings of libldap2.  Don't know if there are
> any in sarge but don't see any reason to break them if there are.

dlopen() should handle dependency libs just fine, I think. If dlsym()
fails because the symbol is actually in another lib, maybe DT_FILTER
might help.

   Simon


signature.asc
Description: OpenPGP digital signature

Re: [HELP] libldap2 2.1.30 breakage?, guru for ld.so needed

[Stephen Frost]

* Simon Richter ([EMAIL PROTECTED]) wrote:
> Stephen Frost schrieb:
> > Completely breaks dlopen()'ings of libldap2.  Don't know if there are
> > any in sarge but don't see any reason to break them if there are.
> 
> dlopen() should handle dependency libs just fine, I think. If dlsym()
> fails because the symbol is actually in another lib, maybe DT_FILTER
> might help.

More ugliness, and it sounds like it's not even clear it'd actually work
in the dlopen()/dlsym() case..  Perhaps if there was actually a problem 
with the symlinks, but I havn't heard of one really with them yet..

Stephen


signature.asc
Description: Digital signature

Re: How to find really old source of the shadow package

[Nicolas François]

On Sun, May 29, 2005 at 11:40:12PM -0500, Peter Samuelson wrote:
> [Nicolas François]
> > I'm looking for really old sources of the shadow package.
> > With http://snapshot.debian.net, the latest I can find is 2902-12
> > (2002/06/04).
> > 
> > Does anybody know where I can find older sources?
> 
> Google for mirrors of archive.debian.org.
> 
> Until archive went offline, it contained every release of Debian before
> woody.  Mirrors are still relatively easy to find.

Thanks Peter.
There is still some gap between the packages from the various stable
releases, but it provides some indications.

-- 
Nekral


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

Re: [HELP] libldap2 2.1.30 breakage?, guru for ld.so needed

[Torsten Landschoff]

Hi Stephen, 

On Mon, May 30, 2005 at 09:16:15AM -0400, Stephen Frost wrote:
> Have you actually got a specific problem with the changes I did, or
> really, the results of them?  There were a couple problems where people
> had old libldap2's hanging around (which is a rather serious mistake
> anyway...) but I havn't seen any other problems with that change yet...

I had a bad feeling in how the linker or ldconfig would react given that
the soname does not match the file name of the library anymore. After
some discussion on irc I am convinced that the symlink way is the best
thing we can do. 

I improved the libldap2.postinst a bit so that it should be able to
handle any libldap.so.2.0.xx leftover files.

Greetings

Torsten


signature.asc
Description: Digital signature

Re: Linda warnings

[Eric Dorland]

* Robert Collins ([EMAIL PROTECTED]) wrote:
> 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.

Yes, they are necessary tools for developers. But nearly ever project
I've ever seen ships the files generated from the auto* tools. 
 
> We and the buildds do *not count* as end users - we are patching the
> code in most cases.

But most packages aren't patching configure.in's and
Makefile.am's. And the buildd is not patching the code, the maintainer
is. 

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

Or you put the patch in the .diff.gz. I think that's the best option. 

-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Re: Linda warnings

[Wouter Verhelst]

On Mon, May 30, 2005 at 10:30:56AM -0400, Eric Dorland wrote:
> * Robert Collins ([EMAIL PROTECTED]) wrote:
> > So either you don't patch the package, or you be willing to require the
> > relevant auto* be installed.
> 
> Or you put the patch in the .diff.gz. I think that's the best option. 

Uh, it's not as if adding the patch to the .diff.gz doesn't have its own
set of problems... see ,
search for 'timestamp skew'

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: Release update: minor delay; no non-RC fixes; upgrade reports

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

"Roberto C. Sanchez" <[EMAIL PROTECTED]> writes:

> On Mon, May 30, 2005 at 12:59:26PM +0200, Adrian Bunk wrote:
>> 
>> Finding these issues is one of the prices for freezing testing 
>> instead of unstable [1].
>
> CMIIW, but isn't unstable a place where architectures can be out of
> sync?  To get into a testing, a package has to pass the cooling off
> period with no >important bugs and must be in sync on all
> architectures.  Correct?  Freezing unstable doesn't make much sense
> if it means lots of extra work just to sync up package versions
> across architectures.  The only that would work is to require that
> packages successfully build on all architectures *prior* to being
> admitted to the archive.

I think this misses the point.  Consider a package present in both
testing and unstable, and later it has an RC bug filed against it,
which is subsequently fixed by an upload to unstable.  The bug is
closed, but it's still present in testing.  There's currently no way
to automatically and easily find these bugs.  Thus there may be many
RC bugs in testing of which there is no trace in the BTS.

After testing freezes, we need a way of saying ("we need fixes x, y
and z from unstable to fix these unfixed RC bugs in testing").

This is at least how I understand what Adrian is saying.  It's
something I hadn't considered before, and certainly deserves serious
consideration.

The BTS does not currently support this.  For example, if I upload a
fix to unstable, I have to manually reopen it and tag it sarge.


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFCmywlVcFcaSW/uEgRAvJsAJ9x3vHEHtjfVaqUz5R5w7od0AhD6ACfZa8+
BIn4zRHMM93rPL00ZLAPPJU=
=w+hP
-END PGP SIGNATURE-


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

Re: Release update: minor delay; no non-RC fixes; upgrade reports

[sean finney]

hi,

On Mon, May 30, 2005 at 04:07:50PM +0100, Roger Leigh wrote:
> The BTS does not currently support this.  For example, if I upload a
> fix to unstable, I have to manually reopen it and tag it sarge.

or, you could always not close it in your changelog, and update the
bug accordingly.


sean

-- 


signature.asc
Description: Digital signature

Re: Release update: minor delay; no non-RC fixes; upgrade reports

[Paul TBBle Hampson]

On Mon, May 30, 2005 at 01:19:48PM +0200, Adrian Bunk wrote:
> On Mon, May 30, 2005 at 11:04:51PM +1200, Nigel Jones wrote:

> > http://bts.turmzimmer.net/details.php?ignore=sid&ignsec=on&fullcomment=on&new=7
> > 
> > thats a decent unoffical count...

> ... that doesn't (and can't) in any way address the problem I described 
> in my email.

Couldn't you just pull the changelog entries for each package that differs
between testing and unstable, pull the 'closes' entries for each of those, and
"voila"? Grab severities from the BTS, cull those which are still open, and you
have a "hidden RC bug" count. True, you don't get those which were closed with
an email to control or -closes, but I'm sure it's only popular with people
who're already keeping sarge-only bugs open manually, or for non-bugs.

And it's very hard to count bugs that don't appear in the BTS. ^_^

Of course, "voila" may actually take a significant amount of time... but could
it be slower than the two hours it takes a human to do it?

-- 
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


pgpp4vvdCIukY.pgp
Description: PGP signature

Re: Release update: minor delay; no non-RC fixes; upgrade reports

[Jeroen van Wolffelaar]

On Tue, May 31, 2005 at 01:40:33AM +1000, Paul TBBle Hampson wrote:
> On Mon, May 30, 2005 at 01:19:48PM +0200, Adrian Bunk wrote:
> > On Mon, May 30, 2005 at 11:04:51PM +1200, Nigel Jones wrote:
> 
> > > http://bts.turmzimmer.net/details.php?ignore=sid&ignsec=on&fullcomment=on&new=7
> > > 
> > > thats a decent unoffical count...
> 
> > ... that doesn't (and can't) in any way address the problem I described 
> > in my email.
> 
> Couldn't you just pull the changelog entries for each package that differs
> between testing and unstable, pull the 'closes' entries for each of those, and
> "voila"? Grab severities from the BTS, cull those which are still open, and 
> you
> have a "hidden RC bug" count. True, you don't get those which were closed with
> an email to control or -closes, but I'm sure it's only popular with people
> who're already keeping sarge-only bugs open manually, or for non-bugs.
> 
> And it's very hard to count bugs that don't appear in the BTS. ^_^
> 
> Of course, "voila" may actually take a significant amount of time... but could
> it be slower than the two hours it takes a human to do it?

For http://www.wolffelaar.nl/~sarge, there are already diffs in a
database that are exactly the diffs between sarge & sid changelogs.
Anyway, this problem is already long time known, and the solution will
be implemented post-sarge in the BTS: proper version tracking on the
bugs. For now, we rely indeed on people testing sarge and the
maintainers -- after all, it's actually simply up to the maintainers to
care for the important bugs to be solved in the version of their
packages targetted for a stable release -- whatever any general group
like QA or release management does, if a maintainer for example fixes a
self-discovered RC-bug without actually filing it and ringing any bells
anywhere that an freeze-exception is needed, how can anyone detect this
and act on it? We do have maintainers for a reason.

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl

Re: Uploading a perl module compiled with -O0

[Enrico Zini]

On Sat, May 28, 2005 at 01:47:11PM -0700, Steve Langasek wrote:

> But it doesn't sound like what you have here is a toolchain bug, it sounds
> like you have a source bug that manifests differently under different
> optimization levels.  Could you please try to debug the memory error instead
> of working around it?  You may find valgrind useful for this.

I had done that already: valgrind only shows a few issues inside the
Perl code.


Ciao,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Dear Adrian Bunk, Please hold off a week or two

[Adrian Bunk]

On Mon, May 30, 2005 at 12:17:29PM +0100, Simon Huggins wrote:

> Adrian, I've noticed lately that almost every post you send is about the
> release; Pointing out problems with some feature or other of it or with
> the actions of the hard working people who are trying to get sarge out
> the door.
> 
> Do you think you could manage to leave your critisms til next week when
> we might have released and turn them into constructive criticisms
> instead of merely demanding pieces of information from the release team?
> 
> I don't know what you hope to achieve by doing this.  "Never attribute
> to malice what can be explained by ignorance".  Maybe you just don't
> realise that you're pestering the release team and others and drawing
> them into pointless debates which won't help release sarge.
> 
> I'd like to ask you publically to hold off for a couple of weeks with
> these questions.  I'm sure you have an entirely rational reason for
> asking them and that it will end up being productive for Debian but I
> honestly think it would be better if they were asked later on.  A
> post-mortem of this release in order to better prepare for Etch might
> indeed help us and I can only imagine you're itching to write it given
> the number of questions you've asked.
> 
> Once sarge releases I'm sure there'll be plenty of time to talk about
> how to get a quicker, predictable release schedule for Etch.

Could you please read and understand the email you are answering to 
before sending such emails?

My email was not about the release process for sarge (unless the release 
process for sarge will be aborted a third time, there's nothing that can 
be changed).

My email was about an issue that is present _now_ and that has to be 
attacked _before_ sarge.

Or do you _really_ want to release sarge with many dozens of already 
known and fixed bugs?

> Thanks,

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Re: Release update: minor delay; no non-RC fixes; upgrade reports

[Adrian Bunk]

On Tue, May 31, 2005 at 01:40:33AM +1000, Paul TBBle Hampson wrote:
> On Mon, May 30, 2005 at 01:19:48PM +0200, Adrian Bunk wrote:
> > On Mon, May 30, 2005 at 11:04:51PM +1200, Nigel Jones wrote:
> 
> > > http://bts.turmzimmer.net/details.php?ignore=sid&ignsec=on&fullcomment=on&new=7
> > > 
> > > thats a decent unoffical count...
> 
> > ... that doesn't (and can't) in any way address the problem I described 
> > in my email.
> 
> Couldn't you just pull the changelog entries for each package that differs
> between testing and unstable, pull the 'closes' entries for each of those, and
> "voila"? Grab severities from the BTS, cull those which are still open, and 
> you
> have a "hidden RC bug" count. True, you don't get those which were closed with
> an email to control or -closes, but I'm sure it's only popular with people
> who're already keeping sarge-only bugs open manually, or for non-bugs.
> 
> And it's very hard to count bugs that don't appear in the BTS. ^_^

Yes, these are the hard part of the problem.
And you might not believe it, but your 1000 maintainers have several 
different qualities and strategies of bug handling.

If you'd freeze unstable (and I'd even keep unstable frozen after the 
start of the freeze) this whole problem wouldn't exist.

But in the current release process with testing, a proper solution that 
also attacks the hard parts of the problem is required.

> Of course, "voila" may actually take a significant amount of time... but could
> it be slower than the two hours it takes a human to do it?

It seems you misunderstood my email.

It doesn't take two hours of work to go through these issues.

I'm sometimes spending one or two hours for going through a _small_ 
subset of update_excuses. Please look yourself at update_excuses [1] (or 
at Jeroen's page) and estimate how long it takes to do a _comlete_ run 
through all these packages.

cu
Adrian

[1] http://ftp-master.debian.org/testing/update_excuses.html

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Re: Release update: minor delay; no non-RC fixes; upgrade reports

[Adrian Bunk]

On Mon, May 30, 2005 at 05:53:31PM +0200, Jeroen van Wolffelaar wrote:
> 
> For http://www.wolffelaar.nl/~sarge, there are already diffs in a
> database that are exactly the diffs between sarge & sid changelogs.
> Anyway, this problem is already long time known, and the solution will
> be implemented post-sarge in the BTS: proper version tracking on the
> bugs. For now, we rely indeed on people testing sarge and the
> maintainers -- after all, it's actually simply up to the maintainers to
> care for the important bugs to be solved in the version of their
> packages targetted for a stable release -- whatever any general group
> like QA or release management does, if a maintainer for example fixes a
> self-discovered RC-bug without actually filing it and ringing any bells
> anywhere that an freeze-exception is needed, how can anyone detect this
> and act on it? We do have maintainers for a reason.


In theory, this would work.

In practice, I doubt it.


After a maximum of how many days do you expect a maintainer to have 
fixed a simple RC bug (e.g. "missing build dependency on foo") in one of 
his packages in theory?

And does this match the practical observations during the last years?


Debian has 1000 maintainers with a quite big variation in the quality of 
package maintaining.

If you base anything on the assumption every single maintainer in Debian 
was 100% properly maintaining his packages, you've based it on a false 
assumption.


> --Jeroen

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


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

Re: Linda warnings

[Eric Dorland]

* Wouter Verhelst ([EMAIL PROTECTED]) wrote:
> On Mon, May 30, 2005 at 10:30:56AM -0400, Eric Dorland wrote:
> > * Robert Collins ([EMAIL PROTECTED]) wrote:
> > > So either you don't patch the package, or you be willing to require the
> > > relevant auto* be installed.
> > 
> > Or you put the patch in the .diff.gz. I think that's the best option. 
> 
> Uh, it's not as if adding the patch to the .diff.gz doesn't have its own
> set of problems... see ,
> search for 'timestamp skew'

I did forget that aspect, but of course liberal touch'ing can get you
around those problems. Also automake's use of missing tends to make
things just work even with timestamp skew
(http://sources.redhat.com/automake/automake.html#maintainer_002dmode).
Maintainer-mode is also a good solution. 

-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Problems with: Bug#295706: "Preferences" is empty

[Michelle Konzack]

Hello Developers and Maintainers, 

The BUG, described by me, occures if you upgrade from WOODY to SARGE.
I have a WOODY workststion (using backports) and yesterday it was
the first time I have called mozilla as root and "Preferences" was
working.

Now I have created a new profile in my own account and mozilla was
starting with an empty configuration and working.

OK, on a Test-Station I have installed WOODY with mozilla, adblock
and tabextensions and configured Mozilla a little bit.

It was working fine.

Then I have made a distupgrade to SARGE...

The error ocurs again.

So Upgraders must move the old mozilla config manualy out of the way.

Can this BUG solved ?

Greetings
Michelle

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/3/8845235667100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: Release update: minor delay; no non-RC fixes; upgrade reports

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

sean finney <[EMAIL PROTECTED]> writes:

> hi,
>
> On Mon, May 30, 2005 at 04:07:50PM +0100, Roger Leigh wrote:
>> The BTS does not currently support this.  For example, if I upload a
>> fix to unstable, I have to manually reopen it and tag it sarge.
>
> or, you could always not close it in your changelog, and update the
> bug accordingly.

That's still requiring /manual intervention/, and lying about the true
state of the bug to the BTS.  Ideally the BTS should understand that
the bug was closed by a particular version of the package (the one
which had Closes: in it), and the bug is still present in earlier
versions (perhaps it should also have the ability to record the
version the bug appeared in as well).  The BTS should be able to know
that a bug is closed in testing automatically, rather than me sending
messages to [EMAIL PROTECTED]; I must have sent at least 30 the past week
alone.


- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFCm0c7VcFcaSW/uEgRAid/AKDY9g7nBmt5Uas75qEDn3DV8W/SqwCfS38s
iGxStFkbWJMun6u82VMn67c=
=twfh
-END PGP SIGNATURE-


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

Bug#311289: ITP: asedrive3e -- PC/SC driver for Athena smartcard readers (serial/USB)

[Simon Richter]

Package: wnpp
Severity: wishlist
Owner: Simon Richter <[EMAIL PROTECTED]>

* Package name: asedrive3e
  Version : 2.2
  Upstream Author : Athena Smartcard Solutions
* URL : http://www.athena-scs.com
* License : BSDish
  Description : PC/SC driver for Athena smartcard readers (serial/USB)

These are drivers for Athena's smartcard readers, both serial and USB
versions.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-powerpc
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)


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

Re: Dear Adrian Bunk, Please hold off a week or two

[Russ Allbery]

Adrian Bunk <[EMAIL PROTECTED]> writes:

> Or do you _really_ want to release sarge with many dozens of already 
> known and fixed bugs?

Yes.  Given the number of packages in Debian, some amount of this is
inevitable.  We'll live.

And you're not just providing constructive feedback.  You're also picking
personal fights with the release team and speculating wildly and as
negatively as possible about their motives.  Please stop.  It's obnoxious,
abusive, and unhelpful.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: Release update: minor delay; no non-RC fixes; upgrade reports

[Russ Allbery]

Roger Leigh <[EMAIL PROTECTED]> writes:

> That's still requiring /manual intervention/, and lying about the true
> state of the bug to the BTS.  Ideally the BTS should understand that the
> bug was closed by a particular version of the package (the one which had
> Closes: in it), and the bug is still present in earlier versions
> (perhaps it should also have the ability to record the version the bug
> appeared in as well).  The BTS should be able to know that a bug is
> closed in testing automatically, rather than me sending messages to
> [EMAIL PROTECTED]; I must have sent at least 30 the past week alone.

Agreed; I'd really like to see this as well.

Another somewhat related matter that's bothered me for a while is that
right now the Debian bug tracking system is not particularly useful for
users of the stable version.  The BTS is not likely to have much sign of
most of their bugs, the maintainers have to carry around stable-tagged
bugs (that then may show up as RC bugs in various summary reports) in
order to document stable issues that are already fixed in unstable or
testing, and the whole situation seems a bit confusing to what we would
anticipate is the "average" Debian user (someone who uses stable).

I'm not sure what the best fix is.  Obviously, most bugs can't be fixed
for stable -- even a lot of RC bugs are questionable to fix for stable
once it's actually released.  It would still be nice to give the user the
known information about a bug they're running into, including any
workarounds that had been found.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: Release update: minor delay; no non-RC fixes; upgrade reports

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> or, you could always not close it in your changelog, and update the
> bug accordingly.

However last time I asked for this, it was deprecated:

http://lists.debian.org/debian-devel/2005/05/msg00915.html
http://lists.debian.org/debian-devel/2005/05/msg00919.html by Steve.

Greetings
Bernd


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

Re: Dear Adrian Bunk, Please hold off a week or two

[Steve McIntyre]

Russ Allbery wrote:
>Adrian Bunk <[EMAIL PROTECTED]> writes:
>
>> Or do you _really_ want to release sarge with many dozens of already 
>> known and fixed bugs?
>
>Yes.  Given the number of packages in Debian, some amount of this is
>inevitable.  We'll live.
>
>And you're not just providing constructive feedback.  You're also picking
>personal fights with the release team and speculating wildly and as
>negatively as possible about their motives.  Please stop.  It's obnoxious,
>abusive, and unhelpful.

Seconded.

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"I can't ever sleep on planes ... call it irrational if you like, but I'm
 afraid I'll miss my stop" -- Vivek Dasmohapatra


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

Re: Dear Adrian Bunk, Please hold off a week or two

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Do you think you could manage to leave your critisms til next week when
> we might have released and turn them into constructive criticisms
> instead of merely demanding pieces of information from the release team?

He is warning about a big number of onresolved RC Bugs which will  look to
users like regression. It is not unreasonable to at least address this issue
in the Release not (because personally I dont expect a Bug-Free Release).

> I don't know what you hope to achieve by doing this.  "Never attribute
> to malice what can be explained by ignorance".  Maybe you just don't
> realise that you're pestering the release team and others and drawing
> them into pointless debates which won't help release sarge.

Actually I am glad somebody is working public visible on the release issues
and would not critisize him for that.

Greetings
Bernd


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

Unloyal competition

[Gunnar Wolf]

Joey Hess dijo [Sat, May 28, 2005 at 07:10:35PM -0400]:
> I will not be online between June 2nd and 5th. Don't release without me! ;-)

Hey, this might give some people extra information for getting a free beer[1]!

Anyway, have a good time

[1] http://www.grep.be/blog/2005/05/28/#release_pool

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

Re: How to find really old source of the shadow package

[Adrian von Bidder]

On Monday 30 May 2005 02.03, Nicolas François wrote:

> Does anybody know where I can find older sources?
[ of shadow ]

 - have you tried asking the shadow maintainers 
(<[EMAIL PROTECTED]>) - perhaps somebody has old CVS 
repositories or whatever lying around?
 - The Debian changelog goes back to 1997 - have you tried contacting these 
people, perhaps they have some old sources 
(/usr/share/doc/changelog.Debian.gz).

greets
-- vbi

-- 
Wibble.


pgpk2n89FdOrj.pgp
Description: PGP signature

Re: Debian kernels

[Laszlo Boszormenyi]

On Sun, 2005-05-29 at 20:36 -0700, Steve Langasek wrote:
> > > 1) What's the timeframe? Should it be available for Sarge, so it needs
> > >quick packaging?
[...]
> Uh, I don't care how quickly you package it, we're not promoting a totally
> new package from unstable to stable in the space of a week.  Sorry.
 Err, my wording was wrong. I meant prepare it to run in a Sarge
environment or not. But I do not want it to be official either, but as
an add-on from an unofficial apt-repository.
Btw, it will need ftp-masters approval even, as it will be a new
package, then more tests, bugreports to fix, etc; no way for official
support in Sarge, I know it.

Sorry for the confusion,
Laszlo/GCS


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

Re: Dear Adrian Bunk, Please hold off a week or two

[Joey Hess]

Adrian Bunk wrote:
> Or do you _really_ want to release sarge with many dozens of already 
> known and fixed bugs?

I'd worry about it more if we hadn't suffered from the same or similar
problems with ever previous Debian release, TBPH. Even back when we froze
unstable, this just pushed certian bugfixes out of the archive entirely.

As long as we do a little better each release, the sky is not falling in
my part of the world.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Release update: minor delay; no non-RC fixes; upgrade reports

[Steve Langasek]

On Mon, May 30, 2005 at 10:21:45AM -0700, Russ Allbery wrote:
> Roger Leigh <[EMAIL PROTECTED]> writes:

> > That's still requiring /manual intervention/, and lying about the true
> > state of the bug to the BTS.  Ideally the BTS should understand that the
> > bug was closed by a particular version of the package (the one which had
> > Closes: in it), and the bug is still present in earlier versions
> > (perhaps it should also have the ability to record the version the bug
> > appeared in as well).  The BTS should be able to know that a bug is
> > closed in testing automatically, rather than me sending messages to
> > [EMAIL PROTECTED]; I must have sent at least 30 the past week alone.

> Another somewhat related matter that's bothered me for a while is that
> right now the Debian bug tracking system is not particularly useful for
> users of the stable version.  The BTS is not likely to have much sign of
> most of their bugs, the maintainers have to carry around stable-tagged
> bugs (that then may show up as RC bugs in various summary reports) in
> order to document stable issues that are already fixed in unstable or
> testing, and the whole situation seems a bit confusing to what we would
> anticipate is the "average" Debian user (someone who uses stable).

> I'm not sure what the best fix is.  Obviously, most bugs can't be fixed
> for stable -- even a lot of RC bugs are questionable to fix for stable
> once it's actually released.  It would still be nice to give the user the
> known information about a bug they're running into, including any
> workarounds that had been found.

That would be the BTS version tracking support, which is slated to be
deployed immediately post-sarge.

-- 
Steve Langasek
postmodern programmer


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

Re: Linda warnings

[Philipp Kern]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Eric Dorland wrote:
> Yes, they are necessary tools for developers. But nearly ever project
> I've ever seen ships the files generated from the auto* tools. 

However I feel the use of a build-dependency is a legitimate one if the
package is built directly from the upstream's tagged SCM sources and
thus contains no Autotools output.

Kind regards,
Philipp Kern
-BEGIN PGP SIGNATURE-
Comment: Fingerprint: 1710 7DB1 9A28 42FF B699  7654 ED1A 3933 B2CF CDD8
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iEYEARECAAYFAkKbcuIACgkQ7Ro5M7LPzdhBVwCePCCQ6BnkbAElemgSvROyEGdt
1JMAoIRxeJQG4wr8viOWVSIYZ0Wj+NOC
=L7iY
-END PGP SIGNATURE-


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

Libraries with ABI changes

[Philipp Kern]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear list readers,

I got some questions to library packaging. If the ABI of a library
breaks, the SONAME of it gets updated and thus the binary package's
name. As soon as the new revision gets uploaded the old binary package
should get NBS (Not Built From Source) status assigned by rene and the
ftp-masters would notice it after NEW processing.

But would such a package kept so long in the archive until all packages
which depend on the old library have been rebuilt? And will the removal
of the old version then happen semi-automatically (as in listed in the
normal rene output)?

Kind regards,
Philipp Kern

-BEGIN PGP SIGNATURE-
Comment: Fingerprint: 1710 7DB1 9A28 42FF B699  7654 ED1A 3933 B2CF CDD8
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iEYEARECAAYFAkKbdPsACgkQ7Ro5M7LPzdi3jACfbdVS7AxQ6q6tBey7o74PGYm4
ZVgAoKxwcGNlF95vtrIipnjdEQzQZWs4
=PXWx
-END PGP SIGNATURE-


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

Re: roxen4_4.0.325-2_i386.changes REJECTED

[Adeodato Simó]

* Turbo Fredriksson [Mon, 30 May 2005 12:52:54 +0200]:

> Oki, I forgot that I already uploaded a -2 version. Now, in testing
> (which this was intended for) I have -1...

> I haven't done an update like this in years, but could someone
> verify that I should take the '-1' version, do the modifications
> (bug #309247) and upload a '-1.1' (with urgency=high)?

  Well, #309247 is (properly) tagged sid, so it doesn't seem like an
  issue that needs a sarge-targetted upload. Is there some RC issue with
  the -1 version, currently in sarge? If not, just upload -3 to fix the
  issue in sid (and sarge will ship with -1, of course).

> Oh, and could I have that '-2' version back? :) I deleted all
> traces of it locally :(.

  You need [EMAIL PROTECTED] for that.

  HTH,

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Listening to: The Magnetic Fields - I Don't Really Love You Anymore
 
Any life, no matter how long and complex it may be, is made up of a
single moment: the moment in which a man finds out, once and for all,
who he is.
-- Jorge Luis Borges


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

Re: Libraries with ABI changes

[Wouter Verhelst]

On Mon, May 30, 2005 at 10:18:03PM +0200, Philipp Kern wrote:
> I got some questions to library packaging. If the ABI of a library
> breaks, the SONAME of it gets updated and thus the binary package's
> name. As soon as the new revision gets uploaded the old binary package
> should get NBS (Not Built From Source) status assigned by rene and the
> ftp-masters would notice it after NEW processing.

Uh, no. The old binary package should either be removed completely from
the archive (in which case all packages that depend on it are instantly
uninstallable), or be moved to a separate source package in section
oldlibs. It should not be left without a source package, or we're
suddenly distributing a binary package without source. Apart from being
against our principles, this might also be a problem with the packages'
license...

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: Libraries with ABI changes

[Steve Langasek]

On Mon, May 30, 2005 at 10:18:03PM +0200, Philipp Kern wrote:
> I got some questions to library packaging. If the ABI of a library
> breaks, the SONAME of it gets updated and thus the binary package's
> name. As soon as the new revision gets uploaded the old binary package
> should get NBS (Not Built From Source) status assigned by rene and the
> ftp-masters would notice it after NEW processing.

> But would such a package kept so long in the archive until all packages
> which depend on the old library have been rebuilt?

No; the binaries are removed from unstable whenever the ftp team runs
melanie on the rene results.  They are retained in testing until they are no
longer needed by any packages (and currently, until the release team pushes
the library transition into testing manually).

-- 
Steve Langasek
postmodern programmer


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

Re: Linda warnings

[Eric Dorland]

* Philipp Kern ([EMAIL PROTECTED]) wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Eric Dorland wrote:
> > Yes, they are necessary tools for developers. But nearly ever project
> > I've ever seen ships the files generated from the auto* tools. 
> 
> However I feel the use of a build-dependency is a legitimate one if the
> package is built directly from the upstream's tagged SCM sources and
> thus contains no Autotools output.

Why? Just run auto* on the unpacked tarball and ship them in the
.diff.gz? What makes it more legitimate in that case? That the
upstream developers didn't run the autotools? They would have, if it
were a proper release. 

-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Re: Libraries with ABI changes

[Philipp Kern]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Wouter Verhelst wrote:
> Uh, no. The old binary package should either be removed completely from
> the archive (in which case all packages that depend on it are instantly
> uninstallable), or be moved to a separate source package in section
> oldlibs.

So on a new ABI-incompatible version the library maintainer should
contact the maintainers of all dependendent packages and arrange a new
upload as soon as the new version gets cleared from the NEW queue? The
timespan until the other uploads are installed into the archives is only
a problem if the melanie run by the ftp-masters happens in between, correct?

Kind regards,
Philipp Kern
-BEGIN PGP SIGNATURE-
Comment: Fingerprint: 1710 7DB1 9A28 42FF B699  7654 ED1A 3933 B2CF CDD8
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iEYEARECAAYFAkKbiJIACgkQ7Ro5M7LPzdjgAwCfcf+uGo3XBA45S4qXM5ENRN9L
vS8AoOq5AdEiT9vb7SNMgeumrWy4D7Fg
=zoUP
-END PGP SIGNATURE-


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

Another Bug for ldap

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

I do not dare to initialize another bug in libldap or pam-ldap. :-(

But with the newest sarge if I configure nss-ldap and pam-ldap to use
tls to connect the server mozilla will dump core.

Now the problem:
Which package is the buggy one?
- - mozilla?
- - libldap2?
- - pam-ldap?
- - nss-ldap?

Gruß
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iQEVAwUBQpuLrJ+OKpjRpO3lAQIe1gf9HQ/G6/z6/AQM0ZJP6qCGTmNSHfjObSLu
SBkcFehbOR2d5D/qNOs0+2GjDj6sYLI3LEEmX7der/ogWHm6SnuFRqJYSqSkgG9W
9wG/mnoSqC1DqDnuNXqOSH+k3UDpPuPKS0O3y8uTplE/iNIIvtKGsJG/jSC9E3ad
c+Jt56snztH0N0gMMFGc3LPmdpQHB/V1XPbRiJ2W5Gi4Oju0xMa/my0AHGb6wZtn
oJkLB4DXaqXTja3kdc36YUsNsyH0WYh4giBrRevRU7h2UUQQbNSUaEfiHTlB63PB
pzNGNILILZpj5ytSgJvL0/LDuCfkBUdCRZStc9aayQ80mMih5ew8vA==
=Do/O
-END PGP SIGNATURE-


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

Re: Another Bug for ldap

[Peter Palfrader]

On Mon, 30 May 2005, Klaus Ethgen wrote:

> Hello,
> 
> I do not dare to initialize another bug in libldap or pam-ldap. :-(
> 
> But with the newest sarge if I configure nss-ldap and pam-ldap to use
> tls to connect the server mozilla will dump core.
> 
> Now the problem:
> Which package is the buggy one?
> - mozilla?
> - libldap2?
> - pam-ldap?
> - nss-ldap?

I only noticed that while nss-ldap and libpam-ldap used different
versions (one the reentrant version, the other one the non-reentrant
version).  I then built both against ldap_r and everything's happy ever
since.  Replacing ldap.so by a link to ldap_r.so was supposed to fix
that too - no idea if it actually did.

-- 
 PGP signed and encrypted  |  .''`.  ** Debian GNU/Linux **
messages preferred.| : :' :  The  universal
   | `. `'  Operating System
 http://www.palfrader.org/ |   `-http://www.debian.org/


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

Re: Linda warnings

[Philipp Kern]

Eric Dorland wrote:
> Why? Just run auto* on the unpacked tarball and ship them in the
> .diff.gz? What makes it more legitimate in that case? That the
> upstream developers didn't run the autotools? They would have, if it
> were a proper release. 

Well, I did not talk about regular snapshots, but about direct exports.
Some tools in Debian (like "darcs-buildpackage", thank you John for
this) make it possible to make such SCM builds. However the Autotools
output is not versioned, so not included in the tarball.

Could you please state why it is discouraged? I could not find it in the
thread.

Kind regards,
Philipp Kern


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

Re: Another Bug for ldap

[Steve Langasek]

On Mon, May 30, 2005 at 11:54:53PM +0200, Klaus Ethgen wrote:
> I do not dare to initialize another bug in libldap or pam-ldap. :-(

> But with the newest sarge if I configure nss-ldap and pam-ldap to use
> tls to connect the server mozilla will dump core.

> Now the problem:
> Which package is the buggy one?
> - mozilla?
> - libldap2?
> - pam-ldap?
> - nss-ldap?

mozilla; it uses /usr/lib/libldap50.so, its own private LDAP library that
exports symbol names that conflict with those of the packaged libldap2.  Yet
another instance of Mozilla NIH syndrome...

-- 
Steve Langasek
postmodern programmer


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

Re: Release update: minor delay; no non-RC fixes; upgrade reports

[Agustin Martin]

On Mon, May 30, 2005 at 06:02:52PM +0100, Roger Leigh wrote:
> 
> That's still requiring /manual intervention/, and lying about the true
> state of the bug to the BTS.  Ideally the BTS should understand that
> the bug was closed by a particular version of the package (the one
> which had Closes: in it), and the bug is still present in earlier
> versions (perhaps it should also have the ability to record the
> version the bug appeared in as well).  The BTS should be able to know
> that a bug is closed in testing automatically, rather than me sending
> messages to [EMAIL PROTECTED]; I must have sent at least 30 the past week
> alone.

I remember somebody proposing that bugs be actually closed when the package
passes to testing, and tagged as sid-fixed or something like that in the
meantime, for bugs closed from the changelog.

That is probably one of the things that are being considered for the BTS in
the near future. 

-- 
Agustin


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

Re: Libraries with ABI changes

[Hamish Moffatt]

On Mon, May 30, 2005 at 11:41:38PM +0200, Philipp Kern wrote:
> Wouter Verhelst wrote:
> > Uh, no. The old binary package should either be removed completely from
> > the archive (in which case all packages that depend on it are instantly
> > uninstallable), or be moved to a separate source package in section
> > oldlibs.
> 
> So on a new ABI-incompatible version the library maintainer should
> contact the maintainers of all dependendent packages and arrange a new
> upload as soon as the new version gets cleared from the NEW queue? The

An advantage of keeping the old library in oldlibs for a while is that
local admins may have their own binaries compiled against these
libraries. Rapid replacements of libraries break local binaries.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: Linda warnings

[Clint Adams]

> Well, I did not talk about regular snapshots, but about direct exports.
> Some tools in Debian (like "darcs-buildpackage", thank you John for
> this) make it possible to make such SCM builds. However the Autotools
> output is not versioned, so not included in the tarball.

It is possible to run autoreconf with both cvs-buildpackage and
arch-buildpackage.  If darcs-buildpackage can't run a prebuild trigger
or target, I'd say that it's deficient.


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

Re: Dear Adrian Bunk, Please hold off a week or two

[Miles Bader]

Bernd Eckenfels <[EMAIL PROTECTED]> writes:
(B> Actually I am glad somebody is working public visible on the release issues
(B> and would not critisize him for that.
(B
(BPointing out a problem is nice, but doing so in an obnoxious manner
(Bhurts.
(B
(B-Miles
(B-- 
$B<+$i$r6u$K$7$F!"?4$r3+$/;~!"F;$O3+$+$l$k(B
(B
(B
(B-- 
(BTo UNSUBSCRIBE, email to [EMAIL PROTECTED]
(Bwith a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Release update: minor delay; no non-RC fixes; upgrade reports

[Paul TBBle Hampson]

On Mon, May 30, 2005 at 06:36:42PM +0200, Adrian Bunk wrote:
> On Tue, May 31, 2005 at 01:40:33AM +1000, Paul TBBle Hampson wrote:

> > Of course, "voila" may actually take a significant amount of time... but 
> > could
> > it be slower than the two hours it takes a human to do it?

> It seems you misunderstood my email.

> It doesn't take two hours of work to go through these issues.

> I'm sometimes spending one or two hours for going through a _small_ 
> subset of update_excuses. Please look yourself at update_excuses [1] (or 
> at Jeroen's page) and estimate how long it takes to do a _comlete_ run 
> through all these packages.

Yes, I did indeed misunderstand that. I had no idea how great the version skew
between testing and unstable is, because it doesn't seem to affect many of the
packages who's versions I care about on my 'testing' box. ^_^

> [1] http://ftp-master.debian.org/testing/update_excuses.html

-- 
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


pgp3tF1Yeo0BV.pgp
Description: PGP signature

Re: Dear Adrian Bunk, Please hold off a week or two

[Nigel Jones]

I noticed that Adrian moved a bug report for a kernel in sid (2.6.10
(BIIRC) to the 2.6.8 kernel so it appeared as a Sarge RC Bug?  I didn't
(Bsee anything that showed that it was a 2.6.8 problem, maybe it is, but
(Bit looked like second guessing to me...
(B
(BHow is this helping Sarge?  If it turns out that it does affect part
(Bof Sarge then isn't there a means provided to upload the new .deb
(Bfiles after release?
(B
(BBug in question is #303200, also it seems it was downgraded to a
(Bnon-RC bug, so now doesn't that mean that it is now filed in wrong
(Bplaces?
(B
(BP.S. Miles: sorry that you'll get it twice, I forgot to check the To: box...
(B
(BOn 31/05/05, Miles Bader <[EMAIL PROTECTED]> wrote:
(B> Bernd Eckenfels <[EMAIL PROTECTED]> writes:
(B> > Actually I am glad somebody is working public visible on the release issues
(B> > and would not critisize him for that.
(B> 
(B> Pointing out a problem is nice, but doing so in an obnoxious manner
(B> hurts.
(B> 
(B> -Miles
(B> --
(B> $B<+$i$r6u$K$7$F!"?4$r3+$/;~!"F;$O3+$+$l$k(B
(B> 
(B> 
(B> --
(B> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
(B> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
(B> 
(B> 
(B
(B
(B-- 
(BN Jones
(B
(B
(B-- 
(BTo UNSUBSCRIBE, email to [EMAIL PROTECTED]
(Bwith a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Release update: minor delay; no non-RC fixes; upgrade reports

[Kevin Mark]

On Mon, May 30, 2005 at 10:21:45AM -0700, Russ Allbery wrote:
> Roger Leigh <[EMAIL PROTECTED]> writes:
> 
> > That's still requiring /manual intervention/, and lying about the true
> > state of the bug to the BTS.  Ideally the BTS should understand that the
> > bug was closed by a particular version of the package (the one which had
> > Closes: in it), and the bug is still present in earlier versions
> > (perhaps it should also have the ability to record the version the bug
> > appeared in as well).  The BTS should be able to know that a bug is
> > closed in testing automatically, rather than me sending messages to
> > [EMAIL PROTECTED]; I must have sent at least 30 the past week alone.
> 
> Agreed; I'd really like to see this as well.
> 
> Another somewhat related matter that's bothered me for a while is that
> right now the Debian bug tracking system is not particularly useful for
> users of the stable version.  The BTS is not likely to have much sign of
> most of their bugs, the maintainers have to carry around stable-tagged
> bugs (that then may show up as RC bugs in various summary reports) in
> order to document stable issues that are already fixed in unstable or
> testing, and the whole situation seems a bit confusing to what we would
> anticipate is the "average" Debian user (someone who uses stable).
> 
> I'm not sure what the best fix is.  Obviously, most bugs can't be fixed
> for stable -- even a lot of RC bugs are questionable to fix for stable
> once it's actually released.  It would still be nice to give the user the
> known information about a bug they're running into, including any
> workarounds that had been found.
> 
> -- 
> Russ Allbery ([EMAIL PROTECTED]) 
Hi Russ,
maybe use the wiki -- SargeKnowIssuesAndFixes page?
-Kev
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!
  `$' $' 
   $  $  _
 ,d$$$g$  ,d$$$b. $,d$$$b`$' g$b $,d$$b
,$P'  `$ ,$P' `Y$ $$'  `$ $  "'   `$ $$' `$
$$ $ $$g$ $ $ $ ,$P""  $ $$
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$
 `Y$$P'$. `YP $$$P"' ,$. `Y$$P'$ $.  ,$.


signature.asc
Description: Digital signature

Re: Example where testing-security was used?

[Marc 'HE' Brockschmidt]

Hamish Moffatt <[EMAIL PROTECTED]> writes:
> On Mon, May 30, 2005 at 11:48:54AM +0100, Mark Brown wrote:
>> On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote:
>>> But setting up autobuilders doesn't require a new infrastructure
>>> (and shouldn't require more than half a year).
>>> Wasn't the infrastructure a prerequisite for woody and is working?
>> It turned out that the central part of the existing infrastructure
>> didn't scale up well enough to cope with the new architectures in sarge.
> There are no new architectures in sarge.

That's right, but the buildd network has to work for both oldstable and
stable. potato + woody didn't need as many buildds as woody + sarge
will need.

Marc
-- 
BOFH #221:
The mainframe needs to rest.  It's getting old, you know.


pgp1LSjXjahP0.pgp
Description: PGP signature