Minimizing ld dependencies with --as-needed

[Ron Johnson]

What are the opinions of d-d's of --as-needed?

http://www.ubuntuforums.org/showthread.php?t=17287

According to this thread, the number of dependencies can sometimes
be slashed drastically.

(Of course, it would have to wait until Sarge becomes Stable.)

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

"The man who has gotten everything he wants is all in favor of
peace and order."
Jawaharlal Nehru



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

Bug 456789: ITP: libjustdoit -- Always does what you want

[Jörg Jaspert]

Package: wnpp
Severity: wishlist

* Package name: libjustdoit
  Version : 1.0
  Upstream Author : Noone. It was just there.
* URL or Web page : Just open your webbrowser after you installed the
lib. And the Homepage will be there!
* License : Whatever you wish it is.
  Description : Always does what you want.

  This library is THE thing we all waited for. Install it and be
  happy. It just does what you want. It has a lot of built-in functions,
  some are listed below. If one isn't there yet - no problem, just use
  libjustdoit to get it added! Its all that easy!

  Some example functions:
  justdoit() - THE central function in this library, everything else is
   built around this one. A sample call is
   "justdoit(make_coffee)" which will instantly burn your
   refrigerator. Or take "justdoit(mail_beloved)" and see
   how nice it calls your wife.
   Other nice examples one could think of are
   "justdoit(install_sarge)" and watch a gentoo compile run
   (Depends on apt-gentoo from
   http://lists.debian.org/debian-devel/2004/03/msg02502.html)
  get_money() - Instantly calls the policy and locks your door until
they are there.
  are_we_there_yet() - Hands you an ice-cream immediately.
  get_dpl() - Will instantly hack vote.debian.org, changing the DPL vote
to
  ensure you are ranked below NOTA.

  Some missing functions:
  release_sarge() - Sorry, this one isn't finished yet. We are still
trying to get it working, but it always has bugs and
hangs waiting for other stuff.
  get_into_cabal() - Sorry, TINC.


--
bye Joerg
  /msg NickServ IDENTIFY arschloch
  /msg nickserv ghost Fubak arschloch
-!- Fubak has quit [Nick collision from services.]

Bug 456789: ITP: libjustdoit -- Always does what you want

[Jörg Jaspert]

Package: wnpp
Severity: wishlist

* Package name: libjustdoit
  Version : 1.0
  Upstream Author : Noone. It was just there.
* URL or Web page : Just open your webbrowser after you installed the
lib. And the Homepage will be there!
* License : Whatever you wish it is.
  Description : Always does what you want.

  This library is THE thing we all waited for. Install it and be
  happy. It just does what you want. It has a lot of built-in functions,
  some are listed below. If one isn't there yet - no problem, just use
  libjustdoit to get it added! Its all that easy!

  Some example functions:
  justdoit() - THE central function in this library, everything else is
   built around this one. A sample call is
   "justdoit(make_coffee)" which will instantly burn your
   refrigerator. Or take "justdoit(mail_beloved)" and see
   how nice it calls your wife.
   Other nice examples one could think of are
   "justdoit(install_sarge)" and watch a gentoo compile run
   (Depends on apt-gentoo from
   http://lists.debian.org/debian-devel/2004/03/msg02502.html)
  get_money() - Instantly calls the policy and locks your door until
they are there.
  are_we_there_yet() - Hands you an ice-cream immediately.
  get_dpl() - Will instantly hack vote.debian.org, changing the DPL vote
to ensure you are ranked below NOTA.
  add_mplayer_to_debian() - Segfault


  Some missing functions:
  release_sarge() - Sorry, this one isn't finished yet. We are still
trying to get it working, but it always has bugs and
hangs waiting for other stuff.
  get_into_cabal() - Sorry, TINC.


--
bye Joerg
  /msg NickServ IDENTIFY arschloch
  /msg nickserv ghost Fubak arschloch
-!- Fubak has quit [Nick collision from services.])

Re: NEW handling: About rejects, and kernels

[Eduard Bloch]

#include 
* Thomas Bushnell BSG [Thu, Mar 31 2005, 06:52:24PM]:
> Eduard Bloch <[EMAIL PROTECTED]> writes:
> 
> > That is bullshit/lies/cheating (pick one). It should be worded:
> >
> > "We are not willing to support his hardware just because we (at least
> > some of us) decided to demonstrate how can we can strike against the
> > non-freeness of the hardware development assets (which has ever been
> > there but we don't care). And you are the lab rats for our experiment
> > but in our reality, the hardware manufacturers are the ones to be
> > blame!!!1"
> 
> Should we same the same thing if we are asked to include a non-free
> documentation reader for a proprietary documentation format?

Your point is?! Acroread? Or what? That buddy has been removed because
of very stupid distribution limitations, and I welcome the same
treatment for any non-free firmware file (non-free as in "really
non-free by a non-fanatic definition", eg. with distribution problems). 

I do not see how freely distributable (or even GPLed) blobs may hurt us.

> In other words, the question remains: why should we have a different
> rule for firmware and not other things?  

Because their nature is different, you have to close both eyes in order
to be able to enjoy the discussion like you do.

> > Because it does not RUN on anything inside of our scope (host machine).
> > You try to extend it by cheating but IMHO most people will refuse to
> > support that.
> 
> "Our scope"?  Where is that written?  Why should the freeness of
> something depend on whether it is a "host machine"?  

As said, burn all hardware in your house. Now. Please. Then you have
definitely defeated the evil non-freeness.

Regards,
Eduard.
-- 
Na'Toth #2: Ambassador, it is not my place to speculate on how anything gets
into your bed.
 -- Quotes from Babylon 5 --


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

Re: Minimizing ld dependencies with --as-needed

[Andrew Suffield]

On Fri, Apr 01, 2005 at 02:34:44AM -0600, Ron Johnson wrote:
> What are the opinions of d-d's of --as-needed?

It's a method of working around bugs. Just fix the bugs
instead. Update libtool to the latest version and don't -l stuff you
don't need to -l.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Preparation of the next stable Debian GNU/Linux update

[Steve Langasek]

Hi Joey,

On Fri, Apr 01, 2005 at 09:49:10AM +0200, Martin Schulze wrote:
> Changelog
> -

> 2005/04/01 09:47 MET

>  * Accepted netkit-telnet
>  * Investigation of netkit-telnet-ssl
>  * Accepted samba

Please note bug #302378, opened yesterday and still being worked on.  Sorry
for not being in a position to catch this earlier.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Minimizing ld dependencies with --as-needed

[Tollef Fog Heen]

* Andrew Suffield 

| It's a method of working around bugs. Just fix the bugs
| instead. Update libtool to the latest version and don't -l stuff you
| don't need to -l.

pkgconfig does add a bunch of gratious -l, similar to what libtool
used to.  This will be fixed, but I'm not sure I want to introduce
that so late in the release cycle.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Re: Bug#250202: Standardizing make target for 'patch' and 'upstream-source'

[Marc 'HE' Brockschmidt]

Scott James Remnant <[EMAIL PROTECTED]> writes:
> There's also the issue of how do you clean or put a source package back
> together, when it's got the patches all applied -- how do you know which
> patch any modifications should go into?

Well, the easiest way would be to unpack all patches into
debian/patches. If you want to build the source package, you then
deapply all patches there (well, it moves the point where this fails if
the author changed the source from debian/rules clean to dpkg-source -b)
and then do a normal diff for the rest (like today). This would allow
people to contine their bad habit of keeping all Debian changes in a
.diff.gz-like thing.

Marc
-- 
$_=')(hBCdzVnS})3..0}_$;//::niam/s~=)]3[))_$(rellac(=_$({pam(esrever })e$.)4/3*
)e$(htgnel+23(rhc,"u"(kcapnu ,""nioj ;|_- |/+9-0z-aZ-A|rt~=e$;_$=e${pam tnirp{y
V2ajFGabus} yV2ajFGa&{gwmclBHIbus}gwmclBHI&{yVGa09mbbus}yVGa09mb&{hBCdzVnSbus';
s/\n//g;s/bus/\nbus/g;eval scalar reverse   # 


pgpCx1oi73PAm.pgp
Description: PGP signature

Re: Minimizing ld dependencies with --as-needed

[Andrew Suffield]

On Fri, Apr 01, 2005 at 12:24:23PM +0200, Tollef Fog Heen wrote:
> * Andrew Suffield 
> 
> | It's a method of working around bugs. Just fix the bugs
> | instead. Update libtool to the latest version and don't -l stuff you
> | don't need to -l.
> 
> pkgconfig does add a bunch of gratious -l, similar to what libtool
> used to.  This will be fixed, but I'm not sure I want to introduce
> that so late in the release cycle.

I'm pretty sure we don't want to go meddling with this stuff at all so
late in the release cycle, so everything here is post-sarge.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Bits from the DAMs ( & Co)

[Ron]

Wasn't this supposed to be announced _after_ project scud took power?

  Ron


On Fri, Apr 01, 2005 at 08:31:23AM +0200, Joerg Jaspert wrote:
> Hi,
> 
> in the tradition of "Bits[1] from the DAMs", started in January, we are
> now sending another mail to inform you about recent decisions we made.
> 
> 
> Topics in this mail
> ---
> 1. Handling of Accounts
> 2. The NM Process
> 3. New Accounts?
> 4. While we are at it, some other stuff too
> 5. Mailing Lists
> 6. Release related
> 7. Are we there yet?
> 
> 
> 1. Handling of Accounts
> ---
> 
> While having a very s3kr1t Cabal[2]-Meeting a bit ago, we decided that
> Debian doesn't work anymore the way it is running right now. We gave you
> a chance to actually proove we are wrong with this conclusion, but the
> huge flamewars following our testmail showed that we are right.
> So we decided to have a clean restart with a small team[3] and as such
> are deleting every account[4] somewhere around this evening (UTC).

 ...




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

Re: Bits from the DAMs ( & Co)

[Henrique de Moraes Holschuh]

On Fri, 01 Apr 2005, Joerg Jaspert wrote:
> in the tradition of "Bits[1] from the DAMs", started in January, we are
> now sending another mail to inform you about recent decisions we made.

, it is that day of the year again...

-- 
  "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: Minimizing ld dependencies with --as-needed

[Josselin Mouette]

Le vendredi 01 avril 2005 à 02:34 -0600, Ron Johnson a écrit :
> What are the opinions of d-d's of --as-needed?
> 
> http://www.ubuntuforums.org/showthread.php?t=17287
> 
> According to this thread, the number of dependencies can sometimes
> be slashed drastically.

I'm moving all my packages to use it. It's not only a workaround for
libtool or pkgconfig bugs, it's also a great tool when some upstream
authors gratuitously adds unneeded -l flags.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: Minimizing ld dependencies with --as-needed

[Steve Langasek]

On Fri, Apr 01, 2005 at 12:53:27PM +0200, Josselin Mouette wrote:
> Le vendredi 01 avril 2005 à 02:34 -0600, Ron Johnson a écrit :
> > What are the opinions of d-d's of --as-needed?

> > http://www.ubuntuforums.org/showthread.php?t=17287

> > According to this thread, the number of dependencies can sometimes
> > be slashed drastically.

> I'm moving all my packages to use it.

Please don't.  Last I knew, this option was still labelled *experimental*
upstream -- there's no possible damage that stray lib dependencies can do to
sarge that competes with the certain damage of having *missing* library
dependencies.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Bug#250202: Standardizing make target for 'patch' and 'upstream-source'

[David Schmitt]

[Cc:s trimmed. Probably should go to -dpkg]

On Friday 01 April 2005 02:12, Scott James Remnant wrote:
> On Wed, 2005-03-30 at 11:37 +0200, David Schmitt wrote:
> > To prepare the sourcecode for inspection and/or minor modifications an
> > additional argument for debian/rules would fit well into the current
> > model.
> >
> > Calling "debian/rules prepare" should leave the tree in a state where the
> > source is unpacked, all patches are applied and any change to the tree
> > would affect the final binaries.
> >
> > This target should execute without any Build-Depends installed. Though -
> > as a intermediate step - it would be appropriate to error out with a
> > appropriate message explaining the needed packages and steps to manually
> > prepare the source.
>
> I was initially thinking along these lines myself
> , however I'm now starting to lean
> towards not allowing arbitrary shell to just open up a source package;
> it doesn't "feel" safe enough.

As I wrote in my summary:

> "dpkg-source -x" should not default to "prepare"-ing the source since this 
> is automatically done for building anyways and would be bad security 
> practice.  

In the case of "trusted" sources, "dpkg-source --prepare -x *.dsc" can be 
implemented/used. In the case of untrusted source, the packages has to be 
examined regardless of what you want to with it (inspection, modification, 
build). Therefore I think this is a balanced compromise between security and 
flexibility.

> I also don't want to break "cd source-version" as the definitive way to
> get to the source afterwards, and am not currently sure how to do that
> with packages containing multiple tarballs.

Currently, "cd $source-$version" is not /the/ definitive way. If it were, we 
wouldn't have this discussion. 

> There's also the issue of how do you clean or put a source package back
> together, when it's got the patches all applied -- how do you know which
> patch any modifications should go into?

I wrote:
> Calling "debian/rules prepare" should leave the tree in a state where the 
> source is unpacked, all patches are applied and any change to the tree would 
> affect the final binaries.

How this is implemented, is left to the build system.

My underlying workflow assumptions for local modifications:

1$ dpkg-source --prepare -x foo_1.dsc
2$ cp foo-1 foo-1.prepared
3$ (cd foo-1; [apply needed modifications])
4$ diff -ru foo-1.prepared foo-1 > foo-mods.patch
5$ (cd foo-1; fakeroot ./debian/rules binary)

I recognise that this approach wouldn't work for e.g. official Security NMUs.
Though foo-mods.patch should already be quite near the format needed for the 
build systems. Automating 2$ and 4$ integrated with the build system could 
combine them into one step before build and add the patch as last patch in 
the chain to the package.

Working with a package - as opposed to applying a small local/security patch - 
would require a more intimate familarity with the build system anyways.



Regards, David
-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir Ãber ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Re: Minimizing ld dependencies with --as-needed

[Ron Johnson]

On Fri, 2005-04-01 at 03:09 -0800, Steve Langasek wrote:
> On Fri, Apr 01, 2005 at 12:53:27PM +0200, Josselin Mouette wrote:
> > Le vendredi 01 avril 2005 à 02:34 -0600, Ron Johnson a écrit :
> > > What are the opinions of d-d's of --as-needed?
> 
> > > http://www.ubuntuforums.org/showthread.php?t=17287
> 
> > > According to this thread, the number of dependencies can sometimes
> > > be slashed drastically.
> 
> > I'm moving all my packages to use it.
> 
> Please don't.  Last I knew, this option was still labelled *experimental*
> upstream -- there's no possible damage that stray lib dependencies can do to
> sarge that competes with the certain damage of having *missing* library
> dependencies.

And since these are (always?) dependencies on shared objects,
these libraries never get used, except to say, "Here I am!",
right?

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

Capitalism needs a culture of shame to work properly.
Paraphrased from Victor David Hansen, seen on CSPAN 2004-03-07



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

Reply Message From Primestaff.

[Jobs]

Reply Message From Primestaff.

Thank you for your mail the contents of which are noted. We appreciate your 
response and will revert to you as soon as possible.

Best regards.

PrimeStaff Management Services Pte Ltd
The Preferred Human Resource Consultant


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

Re: Minimizing ld dependencies with --as-needed

[Gustavo Franco]

On Apr 1, 2005 7:32 AM, Andrew Suffield <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 01, 2005 at 12:24:23PM +0200, Tollef Fog Heen wrote:
> > * Andrew Suffield
> >
> > | It's a method of working around bugs. Just fix the bugs
> > | instead. Update libtool to the latest version and don't -l stuff you
> > | don't need to -l.
> >
> > pkgconfig does add a bunch of gratious -l, similar to what libtool
> > used to.  This will be fixed, but I'm not sure I want to introduce
> > that so late in the release cycle.
> 
> I'm pretty sure we don't want to go meddling with this stuff at all so
> late in the release cycle, so everything here is post-sarge.
> 

I agree, but are we tracking all these post-sarge issues that are coming on d-d
and others lists? I hope that after sarge we start working on these
issues before
etch came closer.

I'm interested in put online a web page containing some things suggested to be 
investigated post-sarge (technical stuff only), anyone too?

--
Gustavo Franco -- <[EMAIL PROTECTED]>


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

Re: init.d script dependencies for etch?

[martin f krafft]

[taking to devel, per your suggestion]

also sprach Lars Wirzenius <[EMAIL PROTECTED]> [2005.04.01.1546 +0200]:
> I would like to work on making this happen for etch. I don't have
> an implementation yet, let alone a plan for how to do it, and
> I won't start work until after sarge is released, so this is just
> a heads-up for the release team.

Excellent. Please keep me in the loop. You also surely want to be
talking to hmh and miquels!

Anyway, I am glad you are actively starting on this. I am going to
actively work on policy-rc.d once sarge is out.

> Anyone who wants to tell me this is a really bad idea, or has
> suggestions on the implementation,

I think we need to establish a header format policy, and I suggest
something similar to debian/control, e.g.

  #!/bin/sh -e
  # init.d script for sshd
  #
  #% Depends: network, iptables
  #

  if "$1" ...

Then, using all the depends lines, you can make a call to
a topographical sort implemenmtation at startup (should be quick
enough as there are <100 init.d scripts) and parallelise the
startups. Pretty standard CS stuff...

I would prefer this over e.g. starting all init.d scripts at once
and letting each call its dependencies. This would be very hard to
implement efficiently.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
 
 EARTH
  smog | bricks
 AIR  --  mud  -- FIRE
soda water | tequila
 WATER


signature.asc
Description: Digital signature

Re: Release update: debian-installer, kernels, infrastructure, freeze, etch, arm

[Bill Allombert]

On Fri, Apr 01, 2005 at 03:48:00PM +0200, Andreas Barth wrote:
> Debian Installer RC3, kernels
> -
> 
> The RC3 release of the debian-installer has been published.  As Joey
> Hess mentions in his announcement[0], this has been the best-tested
> Debian Installer release candidate to date and it continues to hold up
> under scrutiny, and the release team will be proud to use it as the
> installer for sarge.  Thanks to the Debian-Installer team for their
> great work.
> 
> ARM buildd lossage
> --
> 
> By the time you read this, at least one fast ARM buildd is back
> on-line and started to catch up; more buildds are to come.  
> 
> testing-proposed-updates, testing-security
> --
> 
> Getting testing-security up has steady progress.  OpenSSH 3.9 was
> successfully compiled with woody's toolchain, and the connection reusing
> feature from 3.9 is now being used by some buildds to find any remaining
> issues.  
> 
> Freeze ahead
> 
> 
> On a related note, we are now down to 90 open RC bugs in sarge -- and
> many thanks to everyone who has worked so tirelessly to beat these bugs
> into submission.  

Too bad it is only an April fool joke...

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Re: Minimizing ld dependencies with --as-needed

[GOMBAS Gabor]

On Fri, Apr 01, 2005 at 06:01:27AM -0600, Ron Johnson wrote:

> And since these are (always?) dependencies on shared objects,
> these libraries never get used, except to say, "Here I am!",
> right?

The runtime linker still loads them, which can be expensive (esp.
if there are many relocation records), and unneccessarily consumes
virtual address space (which can be a problem for applications with
large working set on 32-bit systems).

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: Minimizing ld dependencies with --as-needed

[GOMBAS Gabor]

On Fri, Apr 01, 2005 at 12:53:27PM +0200, Josselin Mouette wrote:

> I'm moving all my packages to use it. It's not only a workaround for
> libtool or pkgconfig bugs, it's also a great tool when some upstream
> authors gratuitously adds unneeded -l flags.

General note: you have to be careful with --as-needed if you link with
libraries having global constructors/desctuctors as these can alter the
execution of the program even if no symbol is used directly from the
library in question.

Not many libraries have constructors (at least not many C libraries,
with C++ it is much more common) so in the majority of cases this is not
an issue, but you have to be aware that you cannot just blindly add
"--as-needed" everywhere.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: init.d script dependencies for etch?

[Frank Küster]

martin f krafft <[EMAIL PROTECTED]> wrote:

> [taking to devel, per your suggestion]
>
> also sprach Lars Wirzenius <[EMAIL PROTECTED]> [2005.04.01.1546 +0200]:
>> I would like to work on making this happen for etch. I don't have
>> an implementation yet, let alone a plan for how to do it, and
>> I won't start work until after sarge is released, so this is just
>> a heads-up for the release team.
>
[...]
> I think we need to establish a header format policy, and I suggest
> something similar to debian/control, e.g.
>
>   #!/bin/sh -e
>   # init.d script for sshd
>   #
>   #% Depends: network, iptables

Very good to hear.  This would also fix #253128 and similar problems.

Regards, Frank

-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

How to handle unreproducible RC bugs when the submitter is MIA?

[Frank Küster]

Dear release team,

#297181 is unreproducible, and the submitter has not answered to our
questions for a while.  I am quite confident that this bug is really
PEBCAK, or more specifically a local misconfiguration, or some old
locally installed Emacs lisp files lying around.

I do not think that this bug justifies auctex's removal from testing; on
the other hand, I don't think it would be proper to lower its severity
before we know more.  But we cannot know whether the submitter will
answer again and allow us to decide, and possibly fix or reassign,
before sarge is frozen.  

How should this bug be handled?

I'm cc-ing -devel, because this question seems to be of general
interest.  Please note that I am not subscribed to -release (but get
mail to -devel or the bug address).

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Minimizing ld dependencies with --as-needed

[Daniel Jacobowitz]

On Fri, Apr 01, 2005 at 03:09:13AM -0800, Steve Langasek wrote:
> On Fri, Apr 01, 2005 at 12:53:27PM +0200, Josselin Mouette wrote:
> > Le vendredi 01 avril 2005 à 02:34 -0600, Ron Johnson a écrit :
> > > What are the opinions of d-d's of --as-needed?
> 
> > > http://www.ubuntuforums.org/showthread.php?t=17287
> 
> > > According to this thread, the number of dependencies can sometimes
> > > be slashed drastically.
> 
> > I'm moving all my packages to use it.
> 
> Please don't.  Last I knew, this option was still labelled *experimental*
> upstream -- there's no possible damage that stray lib dependencies can do to
> sarge that competes with the certain damage of having *missing* library
> dependencies.

For the record, it isn't actually labelled as experimental upstream -
but there have been some problems with it, and they were fixed in
versions of binutils not yet included in Debian.  I second Steve's
advice; if you want to use this ld feature, wait a little longer.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


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

Re: Minimizing ld dependencies with --as-needed

[Tollef Fog Heen]

* Gustavo Franco 

| I agree, but are we tracking all these post-sarge issues that are
| coming on d-d and others lists? I hope that after sarge we start
| working on these issues before etch came closer.

I'm doing a rebuild of sarge with a changed pkg-config now, to see
what breaks.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Re: Release update: debian-installer, kernels, infrastructure, freeze, etch, arm

[Ken Bloom]

On Fri, 01 Apr 2005 16:32:25 +0200, Bill Allombert wrote:

> On Fri, Apr 01, 2005 at 03:48:00PM +0200, Andreas Barth wrote:
>> Debian Installer RC3, kernels
>> -
>> 
>> The RC3 release of the debian-installer has been published.  As Joey
>> Hess mentions in his announcement[0], this has been the best-tested
>> Debian Installer release candidate to date and it continues to hold up
>> under scrutiny, and the release team will be proud to use it as the
>> installer for sarge.  Thanks to the Debian-Installer team for their
>> great work.
>> 
>> ARM buildd lossage
>> --
>> 
>> By the time you read this, at least one fast ARM buildd is back
>> on-line and started to catch up; more buildds are to come.  
>> 
>> testing-proposed-updates, testing-security
>> --
>> 
>> Getting testing-security up has steady progress.  OpenSSH 3.9 was
>> successfully compiled with woody's toolchain, and the connection reusing
>> feature from 3.9 is now being used by some buildds to find any remaining
>> issues.  
>> 
>> Freeze ahead
>> 
>> 
>> On a related note, we are now down to 90 open RC bugs in sarge -- and
>> many thanks to everyone who has worked so tirelessly to beat these bugs
>> into submission.  
> 
> Too bad it is only an April fool joke...
> 
> Cheers,

Look again at bugs.debian.org/release-critical, or the automatic mail of
release-critical bugs that gets sent out every Friday. At the very least,
this last part is true.

--Ken Bloom

-- 
I usually have a GPG digital signature included as an attachment.
See http://www.gnupg.org/ for info about these digital signatures.



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

Re: Minimizing ld dependencies with --as-needed

[Gustavo Franco]

On Apr 1, 2005 1:58 PM, Tollef Fog Heen <[EMAIL PROTECTED]> wrote:
> * Gustavo Franco
> 
> | I agree, but are we tracking all these post-sarge issues that are
> | coming on d-d and others lists? I hope that after sarge we start
> | working on these issues before etch came closer.
> 
> I'm doing a rebuild of sarge with a changed pkg-config now, to see
> what breaks.
> 

It's good to hear, let us known about the results. 

I'll do something about collect what's being discussed on the lists
and is being pushed to "after sarge" this weekend. It would be good
sum up these ideas in a wiki like wiki.debian.net but i accept help
and suggestions.

--
Gustavo Franco -- <[EMAIL PROTECTED]>


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

How to find out why a package was removed from testing?

[Frank Küster]

Hi,

how can I find out why a package was removed from testing?  I tried to
find this out for wwwoffle, and looked at

- its resolved bugs (no indication) 

- its open bugs (one RC, but worked on)

- ftp.debian.org's bugs: nothing

- Search on debian-release: nothing. 

Where else can I look?

TIA, Frank

P.S. if somebody can point me to an alternative for wwwoffle, that would
be nice.  Is polipo good?  If yes, does it provide an upgrade path from
woody? 

-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: How to find out why a package was removed from testing?

[Jeroen van Wolffelaar]

On Fri, Apr 01, 2005 at 07:28:35PM +0200, Frank K?ster wrote:
> Hi,
> 
> how can I find out why a package was removed from testing?  I tried to
> find this out for wwwoffle, and looked at

This type of information is unfortunately not readily available, you can
find it in some ftp-master logfiles (/org/ftp.debian.org on merkel)
certainly, but that's not reasy.

The plan is to use the newly created debian-testing-changes mailinglist
for notifications of this kind, but it simply hasn't happened yet.
 

Finding out why a package is not (re-)entering testing though, is easy:

> - its open bugs (one RC, but worked on)

Right, but open for 47 days already. If for this amount of days an RC
bug is open and nobody seems to have cared enough to fix it or even
provide a patch, I think it's justified hinting it out of sarge.

If it's fixed, wwwoffle might re-enter testing (if the fixed version
is ready in time), if not, well, it'll stay out.

--Jeroen

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


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

Re: init.d script dependencies for etch?

[Thomas Hood]

On Fri, 01 Apr 2005 16:50:20 +0200, martin f krafft wrote:
> I think we need to establish a header format policy, and I suggest
> something similar to debian/control, e.g.
> 
>   #!/bin/sh -e
>   # init.d script for sshd
>   #
>   #% Depends: network, iptables
>   #
> 
>   if "$1" ...


This has been standardized by LSB:

http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html


This is not to say that I like the idea of magic comment headers.


> I would prefer this over e.g. starting all init.d scripts at once
> and letting each call its dependencies. This would be very hard to
> implement efficiently.


I missed the beginning of this conversation.  I hope it has been said that
the first thing we should do is investigate the several dependency-base
init systems that are already out there.  (There are earlier threads about
this.)

-- 
Thomas Hood


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

Re: How to find out why a package was removed from testing?

[Martin Michlmayr]

* Frank Küster <[EMAIL PROTECTED]> [2005-04-01 19:28]:
> - its open bugs (one RC, but worked on)

http://ftp-master.debian.org/testing/hints/vorlon contains

# bug #295060
remove wwwoffle/2.8e-1

So, yes, because of an RC bug.
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Re: Bug 456789: ITP: libjustdoit -- Always does what you want

[Henning Makholm]

Scripsit "Jörg Jaspert" <[EMAIL PROTECTED]>

> * Package name: libjustdoit
>   Version : 1.0
>   Upstream Author : Noone. It was just there.
> * URL or Web page : Just open your webbrowser after you installed the
> lib. And the Homepage will be there!

The binary package name as well as the API identifiers will need be
changed to avoid trademark problems with Nike.

> * License : Whatever you wish it is.

Have you cleared this with -legal? Usually licenses are not considered
Free if one needs to invoke wishful thinking to fit them to the DFSG.

-- 
Henning Makholm"Manden med det store pindsvin er
  kommet vel ombord i den grønne dobbeltdækker."

Re: How to find out why a package was removed from testing?

[Frank Küster]

Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote:

> On Fri, Apr 01, 2005 at 07:28:35PM +0200, Frank K?ster wrote:
>
>> - its open bugs (one RC, but worked on)
>
> Right, but open for 47 days already. If for this amount of days an RC
> bug is open and nobody seems to have cared enough to fix it or even
> provide a patch, I think it's justified hinting it out of sarge.

You are probably right.  However, removing a package should not be done
without

- adding a note about this to the release notes (Is there a package or
  pseudo-package for the release notes now? I don't think so).

- Inform the maintainers of alternatives.  Since polipo claims to be "in
  the spirit of wwwoffle", it might even be possible to provide an
  upgrade path. 

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: How to find out why a package was removed from testing?

[Frank Küster]

Martin Michlmayr <[EMAIL PROTECTED]> wrote:

> * Frank Küster <[EMAIL PROTECTED]> [2005-04-01 19:28]:
>> - its open bugs (one RC, but worked on)
>
> http://ftp-master.debian.org/testing/hints/vorlon contains
>
> # bug #295060
> remove wwwoffle/2.8e-1
>
> So, yes, because of an RC bug.

Is it not usual practice to send a note about this to the bug?  I think
this would be a good idea, both for documentation purposes, and to wake
up lazy maintainers.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Unsubscribe

[Juan Vitor Maqueda]

-- 
Juan Maqueda
Infraestrutura - Predicta
tel: +55 (11)3054-2522
cel: +55 (11)9624-1145
ICQ: 2027526

Re: How to handle unreproducible RC bugs when the submitter is MIA?

[Thomas Hood]

> Severity: grave
> Justification: renders package unusable


At http://www.debian.org/Bugs/Developer#severities, "grave" is glossed as:

makes the package in question unusable or mostly so, or causes
data loss, or introduces a security hole allowing access to the
accounts of users who use the package.

I interpret "users" here as "all users" because the "important" severity
is glossed as:

has a major effect on the usability of a package, without
rendering it completely unusable to everyone

which seems to be meant to contrast with "grave".  That is, if the package
isn't unusable by everyone (if the bug only affects some users) then the
bug is not grave.

If the bug is unreproducible then it can't be the case that the package is
unusable to everyone.  So I'd say that a downgrade is justified.

Of course, I may be misinterpreting the severity tags.
-- 
Thomas Hood


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

Re: How to find out why a package was removed from testing?

[Bastian Blank]

On Fri, Apr 01, 2005 at 08:00:19PM +0200, Frank KÃster wrote:
> Is it not usual practice to send a note about this to the bug?  I think
> this would be a good idea, both for documentation purposes, and to wake
> up lazy maintainers.

No, maintainers have to know about there bugs. And RC bugs with this
amount of time need some reaction.

Bastian

-- 
Pain is a thing of the mind.  The mind can be controlled.
-- Spock, "Operation -- Annihilate!" stardate 3287.2


signature.asc
Description: Digital signature

Re: init.d script dependencies for etch?

[Bastian Blank]

On Fri, Apr 01, 2005 at 04:28:33PM +0200, martin f krafft wrote:
> I think we need to establish a header format policy, and I suggest
> something similar to debian/control, e.g.

I must say, that the Gentoo-Way looks better than this.

Bastian

-- 
Vulcans believe peace should not depend on force.
-- Amanda, "Journey to Babel", stardate 3842.3


signature.asc
Description: Digital signature

Re: init.d script dependencies for etch?

[Wouter van Heyst]

On Fri, Apr 01, 2005 at 08:16:58PM +0200, Bastian Blank wrote:
> On Fri, Apr 01, 2005 at 04:28:33PM +0200, martin f krafft wrote:
> > I think we need to establish a header format policy, and I suggest
> > something similar to debian/control, e.g.
> 
> I must say, that the Gentoo-Way looks better than this.

What is the Gentoo-Way?

Wouter van Heyst


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

Re: How to handle unreproducible RC bugs when the submitter is MIA?

[Steve Greenland]

On 01-Apr-05, 10:08 (CST), Frank K?ster <[EMAIL PROTECTED]> wrote: 
> I do not think that this bug justifies auctex's removal from testing; on
> the other hand, I don't think it would be proper to lower its severity
> before we know more.  But we cannot know whether the submitter will
> answer again and allow us to decide, and possibly fix or reassign,
> before sarge is frozen.  
> 
> How should this bug be handled?

Downgrade it, tag it as unreproducible (or whatever that exact tag is),
and don't worry about it. It's clearly not 'grave', since it doesn't
seem to affect anyone else, and presumably the submitter is not the only
Debian auctex user .

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: init.d script dependencies for etch?

[Bastian Blank]

On Fri, Apr 01, 2005 at 08:18:56PM +0200, Wouter van Heyst wrote:
> On Fri, Apr 01, 2005 at 08:16:58PM +0200, Bastian Blank wrote:
> > I must say, that the Gentoo-Way looks better than this.
> What is the Gentoo-Way?

| opts="depend checkconfig start stop reload"
| 
| depend() {
| # Make networking dependency conditional on configuration
| case $(sed 's/#.*//' /etc/syslog-ng/syslog-ng.conf) in
| *source*tcp*|*source*udp*|*destination*tcp*|*destination*udp*)
| need net ;;
| esac
| 
| need clock hostname
| provide logger
| }
[...]
| start() {
[...]
| }

Bastian

-- 
Immortality consists largely of boredom.
-- Zefrem Cochrane, "Metamorphosis", stardate 3219.8


signature.asc
Description: Digital signature

Re: init.d script dependencies for etch?

[martin f krafft]

also sprach Bastian Blank <[EMAIL PROTECTED]> [2005.04.01.2031 +0200]:
> | # Make networking dependency conditional on configuration
> | case $(sed 's/#.*//' /etc/syslog-ng/syslog-ng.conf) in
> | 
> *source*tcp*|*source*udp*|*destination*tcp*|*destination*udp*)
> | need net ;;
> | esac
> | 
> | need clock hostname
> | provide logger

Uh, this looks like a "pull" type of thing in which ever init.d
script starts its dependencies. I don't think this is a good idea.

After all, the main reason why we want dependencies is to be able to
parallelise the startup process. If we do that, we will run into
locking problems trying to keep track which dependencies have been
started and which not. Or we make other packages assume too much
information about a given dependencies (e.g. by requiring a /bin/ps
check).

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
 
"the difference between genius and stupidity
 is that genius has it's limits."
-- albert einstein


signature.asc
Description: Digital signature

Re: init.d script dependencies for etch?

[martin f krafft]

also sprach Thomas Hood <[EMAIL PROTECTED]> [2005.04.01.1930 +0200]:
> This has been standardized by LSB:
> 
> http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html

Clearly this is the way to go then. After all, we are striving to be
LSB-compliant, so why deviate?

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
 
micro$oft could shit in a box, and most people would buy it.


signature.asc
Description: Digital signature

Re: init.d script dependencies for etch?

[Bastian Blank]

On Fri, Apr 01, 2005 at 08:48:36PM +0200, martin f krafft wrote:
> Uh, this looks like a "pull" type of thing in which ever init.d
> script starts its dependencies. I don't think this is a good idea.

No, it is not. The dependencies are cached.

Bastian

-- 
"Get back to your stations!"
"We're beaming down to the planet, sir."
-- Kirk and Mr. Leslie, "This Side of Paradise",
   stardate 3417.3


signature.asc
Description: Digital signature

Re: init.d script dependencies for etch?

[martin f krafft]

also sprach Bastian Blank <[EMAIL PROTECTED]> [2005.04.01.2104 +0200]:
> > Uh, this looks like a "pull" type of thing in which ever init.d
> > script starts its dependencies. I don't think this is a good idea.
> 
> No, it is not. The dependencies are cached.

Cached? As in queried beforehand? As in two-pass algorithm, once
iterating init.d with 'depends' as option, then with 'start' ?

Yeah, that sounds nice.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, user, and author
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
 
women can keep a secret just as well as men,
but it takes more of them to do it.


signature.asc
Description: Digital signature

Re: Bug 456789: ITP: libjustdoit -- Always does what you want

[Joerg Jaspert]

On 10246 March 1977, Henning Makholm wrote:

>> * License : Whatever you wish it is.
> Have you cleared this with -legal? Usually licenses are not considered
> Free if one needs to invoke wishful thinking to fit them to the DFSG.

Eh, if you ask -legal its always non-free, so no need to. :)

-- 
bye Joerg
(Irgendwo von heise.de):
Jesus war ein typischer Student:
- Lebte bis er 30 war bei den Eltern, - Hatte lange Haare
- Wenn er mal was tat dann wars ein Wunder


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

Re: NEW handling: About rejects, and kernels

[Thomas Bushnell BSG]

Eduard Bloch <[EMAIL PROTECTED]> writes:

> As said, burn all hardware in your house. Now. Please. Then you have
> definitely defeated the evil non-freeness.

As I have said, I don't think non-free software is evil.  I just think
it is not part of the Debian main archive.


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

Re: Release update: debian-installer, kernels, infrastructure, freeze, etch, arm

[Thomas Bushnell BSG]

Andreas Barth <[EMAIL PROTECTED]> writes:

> With these changes done, we are now on the home stretch for the sarge
> release.  We are now only waiting on the arm buildds to recover and
> catch up to a reasonable extent, and on one last glibc upload -- and
> then sarge is FREEZING.  This is, therefore, the last call for uploads
> for sarge: if you have any final important changes to your packages
> which you think need to make it into sarge, upload them now or never.

What about uploads that I did a while ago specifically for the purpose
of sarge, but which haven't gotten through NEW processing?


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

Re: How to handle unreproducible RC bugs when the submitter is MIA?

[Frank Küster]

Thomas Hood <[EMAIL PROTECTED]> wrote:

>  That is, if the package
> isn't unusable by everyone (if the bug only affects some users) then the
> bug is not grave.
>
> If the bug is unreproducible then it can't be the case that the package is
> unusable to everyone.  So I'd say that a downgrade is justified.

Well, maybe it is "only" serious (bugs in maintainer scripts are a
policy violation), or maybe it is in fact only important.  But it's hard
to find out.

And I would not be too surprised if it turned out to be a bug in a
different package, some package rarely installed with auctex or other
Emacs add-ons that rely on similar features (auctex runs its configure
script from the maintainer script).  And in this case I think it would
be a serious bug in that other package.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: How to find out why a package was removed from testing?

[Frank Küster]

Bastian Blank <[EMAIL PROTECTED]> wrote:

> On Fri, Apr 01, 2005 at 08:00:19PM +0200, Frank Küster wrote:
>> Is it not usual practice to send a note about this to the bug?  I think
>> this would be a good idea, both for documentation purposes, and to wake
>> up lazy maintainers.
>
> No, maintainers have to know about there bugs. And RC bugs with this
> amount of time need some reaction.

Well, the point is that I thought about doing an NMU.  However, I don't
feel like digging into the problem if the package was removed for an
unrelated reason which I cannot change (like dead upstream, better
replacement available).  This is why I think it would be good to send a
note to the bug log.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: How to handle unreproducible RC bugs when the submitter is MIA?

[Thomas Hood]

On Fri, 2005-04-01 at 22:22 +0200, Frank Küster wrote:
> (bugs in maintainer scripts are a policy violation)


I don't recall policy saying that maintainer scripts "must" be entirely
bug free.  

Obviously they _should_ be bug free, but bugs in maintainer scripts
aren't always RC.

-- 
Thomas Hood <[EMAIL PROTECTED]>

Re: How to find out why a package was removed from testing?

[Andreas Barth]

* Jeroen van Wolffelaar ([EMAIL PROTECTED]) [050401 19:35]:
> On Fri, Apr 01, 2005 at 07:28:35PM +0200, Frank K?ster wrote:
> > how can I find out why a package was removed from testing?  I tried to
> > find this out for wwwoffle, and looked at

> This type of information is unfortunately not readily available, you can
> find it in some ftp-master logfiles (/org/ftp.debian.org on merkel)
> certainly, but that's not reasy.

the real information as written (and used) by the release team is in the
hint files, http://ftp-master.debian.org/testing/hints/ =
merkel:/org/ftp.debian.org/testing/hints/


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: How to find out why a package was removed from testing?

[Andreas Barth]

* Frank Küster ([EMAIL PROTECTED]) [050401 19:55]:
> Martin Michlmayr <[EMAIL PROTECTED]> wrote:
> > * Frank Küster <[EMAIL PROTECTED]> [2005-04-01 19:28]:
> >> - its open bugs (one RC, but worked on)
> >
> > http://ftp-master.debian.org/testing/hints/vorlon contains
> >
> > # bug #295060
> > remove wwwoffle/2.8e-1
> >
> > So, yes, because of an RC bug.

> Is it not usual practice to send a note about this to the bug?  I think
> this would be a good idea, both for documentation purposes, and to wake
> up lazy maintainers.

Actually, this was discussed in Vancouver, and has been agreed at - but
well, implementation of other issues had preference (the plan is to both
send a daily summary to debian-testing-changes and to mail the
individual maintainers; perhaps replacing maintainers with bugs is a
good idea).


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C


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

Re: init.d script dependencies for etch?

[Thomas Hood]

On Fri, 01 Apr 2005 20:40:08 +0200, Bastian Blank wrote:
> | need clock hostname
> | provide logger

I take it that this is Richard Gooch's simpleinit system as furnished in
util-linux.

   http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/

Before commenting, people should go and read about the several free init
systems available out there.  There's also runit, minit, etc.  There
have been other threads on debian-devel about this issue, e.g.:

http://lists.debian.org/debian-devel/2004/08/msg01393.html
http://lists.debian.org/debian-devel/2003/10/msg01078.html
http://lists.debian.org/debian-devel/2004/06/msg01445.html
http://lists.debian.org/debian-devel/2003/11/msg01695.html
http://lists.debian.org/debian-devel/2003/09/msg01359.html
http://lists.debian.org/debian-devel/2003/01/msg01898.html

-- 
Thomas Hood


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

Re: Release update: debian-installer, kernels, infrastructure, freeze, etch, arm

[Adrian Bunk]

On Fri, Apr 01, 2005 at 03:48:00PM +0200, Andreas Barth wrote:
>...
> Major changes in etch
> -
> 
> If you intend to make major changes (like a C++ ABI bump) during the
> development of etch, please speak with the release team as soon as
> possible, describing the changes you're planning and why.  This way, we
> can help you to make your transitions as smooth as possible, ensuring
> that packages go quickly into testing/etch, don't hold up other packages
> or the release in general, and don't take us by surprise.  We would
> appreciate it if you could send these emails before the end of April
> to [EMAIL PROTECTED]

Is this an April Fool joke?

If not, the release team should also send the information required for 
this:

When is the estimated freeze date for etch?

It doesn't need to be an exact date, but someting like
"third quarter of 2005" or "mid-2008" would help to avoid situations 
like the sarge C++ transition that was too early [1] or the more than 
two years old X11 that will ship with sarge (and that doesn't support 
all hardware supported by recent X.org releases) [2].

And please learn from past release management mistakes and announce a 
_realistic_ estimated freeze date for etch [3].

>...
> Keeping track of RC bugs in testing
> ---
> 
> Since BTS version tracking is a post-sarge feature, we depend on your
> help to keep track of RC bugs that have been fixed in unstable but not
> testing.  Over the past few months, we've been tracking these bugs
> mainly through the use of reopened, sarge-tagged bug reports.  You can
> continue to use this method to let the release team know about
> release-critical issues, but we would encourage you to use
> http://www.wolffelaar.nl/~sarge/ to send us comments on the
> importance of particular updates waiting in testing.  This applies not
> just to release-critical issues (which should be marked as "critical" on
> that page), but also to important ones (and "minor" ones, if you feel
> inclined).  For usage information about this site, please see the
> previous announcement concerning it[1].

For the record:
I started doing this during the last days [4].

RC bugs are IMHO better since they also show up in your RC bugs metric.

> Cheers,
> Andi Barth

cu
Adrian

[1] the first birthday of gcc 3.4.0 is only a few days from now
[2] the "outdated X11" problem was already present in woody where
XFree86 4.2 might have been included
[3] and avoid the non-working "aggressive goals" [5]
[4] that's extra work only required by the usage of testing and version
tracking in the BTS alone will not be sufficient to handle this -
but that's a different discussion
[5] http://lists.debian.org/debian-devel-announce/2003/08/msg00010.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: How to handle unreproducible RC bugs when the submitter is MIA?

[Steve Langasek]

On Fri, Apr 01, 2005 at 12:05:59PM -0600, Steve Greenland wrote:
> On 01-Apr-05, 10:08 (CST), Frank K?ster <[EMAIL PROTECTED]> wrote: 
> > I do not think that this bug justifies auctex's removal from testing; on
> > the other hand, I don't think it would be proper to lower its severity
> > before we know more.  But we cannot know whether the submitter will
> > answer again and allow us to decide, and possibly fix or reassign,
> > before sarge is frozen.  

> > How should this bug be handled?

> Downgrade it, tag it as unreproducible (or whatever that exact tag is),
> and don't worry about it. It's clearly not 'grave', since it doesn't
> seem to affect anyone else, and presumably the submitter is not the only
> Debian auctex user .

Just to confirm, this is the release team's policy on handling such bugs.

Thanks,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Bug#250202: Standardizing make target for 'patch' and 'upstream-source'

[Michael Banck]

On Fri, Apr 01, 2005 at 01:12:53AM +0100, Scott James Remnant wrote:
> On Wed, 2005-03-30 at 11:37 +0200, David Schmitt wrote:
> 
> > To prepare the sourcecode for inspection and/or minor modifications an 
> > additional argument for debian/rules would fit well into the current model. 
> > 
> > Calling "debian/rules prepare" should leave the tree in a state where the 
> > source is unpacked, all patches are applied and any change to the tree 
> > would 
> > affect the final binaries.
> > 
> > This target should execute without any Build-Depends installed. Though - as 
> > a 
> > intermediate step - it would be appropriate to error out with a appropriate 
> > message explaining the needed packages and steps to manually prepare the 
> > source.
> > 
> I was initially thinking along these lines myself
> , however I'm now starting to lean
> towards not allowing arbitrary shell to just open up a source package;
> it doesn't "feel" safe enough.
> 
> I also don't want to break "cd source-version" as the definitive way to
> get to the source afterwards, and am not currently sure how to do that
> with packages containing multiple tarballs.
> 
> There's also the issue of how do you clean or put a source package back
> together, when it's got the patches all applied -- how do you know which
> patch any modifications should go into?

The variance of different build systems present and the strong feelings
DDs have about them is indication that there might not be the
build-system-to-rule-them-all any time soon.  Your proposal definetely
sounds good (especially the "upload patches individually" part), but it
I guess some time will be needed to shake out the problems (after all,
*every* package up to xfree86 will have to be usefully hackable with it)
and transition to it.


In the meantime, having common targets to get to the source (i.e.
"unpack the source(s)", "patch the source(s)", "do both") seems very
desirable to me, this would help when looking at OPP[1]. IMHO, those
targets should be easy words, like "unpack", "patch", "setup", but I
don't care a lot about them as long as we decide on one.

The issue with how to get patches into your new package is not that
important I think, as this is usually rather straight-forward from
looking at what's in debian/patches already.  Also, the 'clean' target
should unapply any patches, so there's no pressing need to have a common
unpatch target (but it wouldn't hurt I guess).


cheers,

Michael

[1] Other People's Packages
-- 
 i am thinking of a smart way of exploiting it and once i
do it will be on slashdot
 WOW SLASHDOT
 ross: well slashdot take any peace of junk


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

Re: Release update: debian-installer, kernels, infrastructure, freeze, etch, arm

[Matthew Garrett]

Adrian Bunk <[EMAIL PROTECTED]> wrote:
> It doesn't need to be an exact date, but someting like
> "third quarter of 2005" or "mid-2008" would help to avoid situations 
> like the sarge C++ transition that was too early [1] or the more than 
> two years old X11 that will ship with sarge (and that doesn't support 
> all hardware supported by recent X.org releases) [2].

(snip)

> [1] the first birthday of gcc 3.4.0 is only a few days from now

The C++ ABI was broken with gcc 3.2.0. For most architectures, 3.4.0
doesn't change anything. Is your point anything other than "The Debian
release process is broken and you should get rid of testing"? If not,
we've heard that several times already. It doesn't need reiterating.

-- 
Matthew Garrett | [EMAIL PROTECTED]


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

crediting debconf translators, revisited

[sean finney]

hi all,

some time back, i remember somebody asking what the proper way was to
credit translators who provided debconf template translations.  the
consensus seemed to be that mentioning them in the changelog was
sufficient.

not being satisfied with that, however, i wrote up a small script
to directly credit their work, which i redirect into a file under
/usr/share/doc/$package/ during package build.

if anyone's interested, it's at:

http://people.debian.org/~seanius/goodies/credit-xlators/credit-xlators


sean

-- 


signature.asc
Description: Digital signature

Re: intend-to-implement: script to obtain Debian Source

[Adam Heath]

On Sun, 27 Mar 2005, Lars Wirzenius wrote:

> su, 2005-03-27 kello 09:01 +0200, George Danchev kirjoitti:
> > I second suggestion given at #250202 and like to see "unpacked" and 
> > "patched"
> > targets to hit Policy 4.8.
>
> I hear that Adam Heath (doogie for those on IRC) has been working on a
> new source package format that will make tarball-within-tarball sources
> obsolete and has native support for multiple patches and cures for other
> ailments. If this works, and I suspect it will, then "unpack" and
> "patch" targets will also be obsolete. Personally, I think this will be
> a good thing.

The new toolset(tentatively called dbs-ng while I'm developing it) supports
what I call pre-patched source.

dpkg-source -x foo.dsc gives a source tree that is immediately ready for
editting and building.  No need to apply patches by running something inside
debian/rules.

If you modify a file, then dpkg-source -b the dir, it'll be included in the
standard diff.gz, just like a standard package.

However, if you want the patch to be maintained separately, dbs-ng -d
foo.patch will product a file called foo.patch in $PWD that contains the
change you have done.  You can then move that into debian/patches.

Another major feature is patch dependencies.  No longer do you have to prefix
your patch names with numbers, to get the ordering right.  Now, you just list
the other patches you depend on, and they will be applied in the correct
order.  Additionally, as a way to weed out other problems, any patches that
are leafs(ie, don't depend on anything) are applied in a random order.

Also, all patches now have a leading dpkg control paragraph; this contains the
Depends line, Description, Flags, and other fields.

The tool also supports mailing patch sets to email addresses, including
diffstat output, etc.

The initial version is in perl, and is done.  I'm working on rewriting it in
C, however, before I release it.

ps: I do have a second perl version that *does* support changes to binary
files, permissions, file types, renames, etc that will be merged into the C
version.  This new diff format is encoded in a format that is capable of being
run as a *shell script*, so that you don't need the advanced toolset on the
system to apply the series of changes(useful for bootstrapping).


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

Re: How to find out why a package was removed from testing?

[Steve Langasek]

On Fri, Apr 01, 2005 at 07:59:01PM +0200, Frank Küster wrote:
> Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote:

> > On Fri, Apr 01, 2005 at 07:28:35PM +0200, Frank K?ster wrote:

> > Right, but open for 47 days already. If for this amount of days an RC
> > bug is open and nobody seems to have cared enough to fix it or even
> > provide a patch, I think it's justified hinting it out of sarge.

> You are probably right.  However, removing a package should not be done
> without

> - adding a note about this to the release notes (Is there a package or
>   pseudo-package for the release notes now? I don't think so).

There is an upgrade-reports package, but not a release-notes package.
Perhaps upgrade-reports is good enough for the moment, since removed
packages are upgrade issues?

Anyway, packages are removed from testing or unstable+testing all the time
when they're not releasable, without necessarily looking at whether they
were present in stable; and many of these may get back into testing before
release; so it's not really practical to track removals until we get close
to freeze (like, hmm, now).

> - Inform the maintainers of alternatives.

Hmm, that assumes there generally are alternatives, or that the release team
knows about them, neither of which is a given.  If a niche package has RC
bugs that aren't being resolved, we can't ship it, even if there's no known
alternative.

>  Since polipo claims to be "in
>   the spirit of wwwoffle", it might even be possible to provide an
>   upgrade path. 

I'd be happy for any upgrade paths that maintainers choose to provide, but I
just don't see this happening for the majority of packages -- we have enough
trouble making sure all packages we ship are upgradable from woody, without
swapping out the complete codebase, and I think this is a case of having to
choose our battles.

On Fri, Apr 01, 2005 at 10:24:56PM +0200, Frank Küster wrote:
> Bastian Blank <[EMAIL PROTECTED]> wrote:

> > No, maintainers have to know about there bugs. And RC bugs with this
> > amount of time need some reaction.

> Well, the point is that I thought about doing an NMU.  However, I don't
> feel like digging into the problem if the package was removed for an
> unrelated reason which I cannot change (like dead upstream, better
> replacement available).  This is why I think it would be good to send a
> note to the bug log.

The release team doesn't remove packages from testing for reasons that don't
go through the BTS, and these are generally documented in
http://ftp-master.debian.org/testing/hints/ as noted.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Bug#302641: ITP: debhelper-dwim -- debhelper extension to do what the maintainer wants

[Steve Langasek]

Package: wnpp
Severity: wishlist
Owner: Steve Langasek <[EMAIL PROTECTED]>

* Package name: debhelper-dwim
  Version : 1.0.0
  Upstream Author : Steve Langasek <[EMAIL PROTECTED]>
* URL : http://www.yagoohoogle.com/
* License : Abridged "Public Rights" International License, version 1
  Description : debhelper extension to do what the maintainer wants

  This package provides the dh_dwim debhelper script, which has been 
  developed as an answer to cdbs within the debhelper paradigm.  It 
  depends on libjustdoit, which has been ITP'ed at [0].

  The dh_dwim script is incompatible with dh_perl.

[0] http://lists.debian.org/debian-devel/2005/04/msg3.html


-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686-smp
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Re: How to find out why a package was removed from testing?

[Adrian Bunk]

On Fri, Apr 01, 2005 at 06:56:45PM -0800, Steve Langasek wrote:
> On Fri, Apr 01, 2005 at 07:59:01PM +0200, Frank Küster wrote:
> > Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote:
> 
> > > On Fri, Apr 01, 2005 at 07:28:35PM +0200, Frank K?ster wrote:
> 
> > > Right, but open for 47 days already. If for this amount of days an RC
> > > bug is open and nobody seems to have cared enough to fix it or even
> > > provide a patch, I think it's justified hinting it out of sarge.
> 
> > You are probably right.  However, removing a package should not be done
> > without
> 
> > - adding a note about this to the release notes (Is there a package or
> >   pseudo-package for the release notes now? I don't think so).
> 
> There is an upgrade-reports package, but not a release-notes package.
> Perhaps upgrade-reports is good enough for the moment, since removed
> packages are upgrade issues?
> 
> Anyway, packages are removed from testing or unstable+testing all the time
> when they're not releasable, without necessarily looking at whether they
> were present in stable; and many of these may get back into testing before
> release; so it's not really practical to track removals until we get close
> to freeze (like, hmm, now).
>...


This still catches only part of the problem.

I wouldn't assume that the majority of Debian users completely reads the 
release notes.


Consider someone discovers a remotely exploitable hole in wwwoffle
13 months after the release of sarge.

According to the Debian Popularity Contest, 1.5% of the Debian users run 
wwwoffle.

Consider one third of them completely read the release notes and removed 
wwwoffle. Then one percent of all computers running Debian 3.1 will be 
vulnerable - and there will be no DSA warning them.

You can argue "it was documented" - but the number of vulnerable
Debian 3.1 machines will still make the script kiddies very happy.

And wwwoffle is only one of many removed packages.


> The release team doesn't remove packages from testing for reasons that don't
> go through the BTS, and these are generally documented in
> http://ftp-master.debian.org/testing/hints/ as noted.


That's wrong.


The release team does remove packages for getting library transitions 
into testing. If a package affected by the transition depends on a third 
package that is not yet ready for testing, it might be hinted for 
removal by the release team without any mentioning in the BTS.

Consider e.g. the loop-aes-utils package would require libopenh323 [1].

You yourself would hint it for removal from testing today and it 
wouldn't have any chance of entering testing again for sarge [2] 
although it's completely bug-free.


Or a package might simply be removed because it depends directly or 
indirectly on a buggy package without being itself buggy.


> Steve Langasek


cu
Adrian

[1] that's only a fictive example, but I'm too lame digging through
650kB update_excuses for finding some real examples
[2] due to it's versioned util-linux dependency

-- 

   "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: Bits from the DAMs ( & Co)

[Ritesh Raj Sarraf]

April Fool!

:-)

Ritesh

On Friday 01 Apr 2005 12:01 pm, Joerg Jaspert wrote:
> Hi,
>
> in the tradition of "Bits[1] from the DAMs", started in January, we are
> now sending another mail to inform you about recent decisions we made.
>
>
> Topics in this mail
> ---
> 1. Handling of Accounts
> 2. The NM Process
> 3. New Accounts?
> 4. While we are at it, some other stuff too
> 5. Mailing Lists
> 6. Release related
> 7. Are we there yet?
>
>
> 1. Handling of Accounts
> ---
>
> While having a very s3kr1t Cabal[2]-Meeting a bit ago, we decided that
> Debian doesn't work anymore the way it is running right now. We gave you
> a chance to actually proove we are wrong with this conclusion, but the
> huge flamewars following our testmail showed that we are right.
> So we decided to have a clean restart with a small team[3] and as such
> are deleting every account[4] somewhere around this evening (UTC).
>
>
> 2. The NM Process
> -
>
> Well, as the Cabal[2] decided in Point 1 that we[2] don't have any
> additional accounts in the future, we[2] just stopped the NM Process[5], no
> need for big queues in this process anymore, they will be deleted
> shortly after the accounts.
>
> 3. New Accounts
> ---
>
> Note that this all does not mean that there wont be new accounts in the
> future. Of course we have plans to let others play with our favourite
> Universal Operating System as well, so we will accept new Developers - who
> then do all the bad work for us. We[2] took some time to come up with
> objective[6] criteria for new Developers (NM), some of them are listed
> below, some others are to be announced at the time we start accepting new
> people into the project again:
>
> - a NM must pay both DAMs a sum of money, randomly choosen at the time
>   he applies. This ensures that we always have enough money to process
>   the request of NMs, you know it needs time to create accounts!
>
> - a NM must have machines of all architectures Debian supports at his
>   home, making them available for all other DDs to access over the net,
>   so we make sure every DD may know what his packages are doing on other
>   machines.
>
> - a NM must agree that he wont ever flame anyone behind any
>   role-address, except he paid him before.
>
> - [deleted or anyone from debian-women would kill me. Sorry]
>
>
> 4. While we are at it, some other stuff too
> ---
>
> Ok, while we are already at this bit-writing thing, we decided to
> add just another bit here, no need for an additional mail only wasting
> resources.
> As we both have some other hats for our nice shoulders, we just
> wanted to add that this  NEW is also stopped. You aren't able to upload
> anymore,  so no need for NEW. Of course we will clean the archive, recent
> activities with the long NEW queue, and the long past it had made the
> archive just too big. The Cabal doesn't use all the packages, so why
> should we keep them around? Be prepared for a 1GB Debian Mirror in the
> future, carrying all useful stuff you need to have.
>
>
> 5. Mailing Lists
> 
>
> As we considered the climate on the lists to be BAD, we just decided to
> randomly shut them down. Whenever we[2] don't like a thread this list
> will be dropped for at least a week. We are sure that this will help us
> to get to a much friendlier atmosphere, as random people already
> announced that need a while ago.
>
>
> 6. Release related
> --
>
> What for? With the end of this day we will remove sarge and woody. We
> all run sid anyways, so why bother keeping something always outdated?
> Its so much simpler to just work on sid. Believe us, we are the Cabal,
> we know that.
>
>
> 7. Are we there yet?
> 
>
> Yes, some ice cream for you.
>
>
>
>
> Footnotes:
> [1] Sorry, only Bits, not Bytes, we[2] didn't have enough time to prepare
> Bytes. Please go and collect as many copies as you need to prepare
> a byte out of it yourself.
>
> [2] Cabal[2], OH Cabal[2]. Yes, there is a Cabal[2]. If you need to read
> this via a public mailinglist you are not in this Cabal[2].
> Sorry. Bad luck for you.
>
> [3] Yes, you know, anyone says small teams[2] are good.
>
> [4] Not our[2] own and some hand-selected Cabal[2] Members Accounts of
>   course.
>
> [5] Just think about it. Its *NM* - so *N*o *M*ore Processing fits very
> well.
>
> [6] Really. We used more than two dices for them!

-- 
Ritesh Raj Sarraf
RESEARCHUT -- http://www.researchut.com
Gnupg Key ID: 04F130BC
"Stealing logic from one person is plagiarism, stealing from many is 
research".


pgpjKg8MbRB27.pgp
Description: PGP signature