date:20050715

Hi,
* Andrew Suffield [EMAIL PROTECTED] [2005-07-15 10:50]:
 On Thu, Jul 14, 2005 at 11:21:52AM +0200, Tollef Fog Heen wrote:
  * Mattia Dongili 
  
  | - setting the CPUFreq policy must be done as early as possible in the
  |   boot process (IMHO)
  
  Why?  This looks just like an opinion without any rationale.
 
 It's dumb anyway. If you wanted it set early, you'd have done it on
 the kernel command line.

Maybe its a misunderstanding but what is the problem of
setting it during the normal use of the system?
Regards Nico
-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


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

Re: pbuilder status update

Hi, 

Thanks for the comments.

 Ideally there needs to be either
 
 * a login environment where changes are saved AND/OR
 
 * a hook that gets executed for an update operation, *before* apt-get
   is called.

Luckily, since pbuilder 0.118 which was released 31 Oct 2004,
there is a --save-after-login option. It should work in the sarge version
of pbuilder.


For sarge, it should be possible to do the following :

pbuilder create --distribution sarge
pbuilder login --save-after-login
chroot# vi /etc/apt/sources.list # and edit it to point to sid
chroot# apt-get update 
chroot# apt-get install apt gnupg
chroot# apt-get update
chroot# exit


(of course, current sid is in a flux due to C++ transition,
so the mileage may vary)


regards,
junichi


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

Re: aspell dictionary packages fail to build

Hi,

 The aspell dictionary packages build-depend on aspell-bin ( 0.60).
 aspell-bin is now a virtual package provided by aspell, but virtual
 packages cannot be versioned, so these build-dependency cannot be
 satisfied.
 
 There are fifteen such packages:

I'd see a benefit in filing mail beforehand for a change, but 
after-the-fact, I have an impression that it's better to 
file bugs on the packages since it's easier to track the problem that way.

Unless there is a chance of reintroducing aspell-bin package, 
that should probably be the case.

I think this is the call of aspell maintainer.

regards,
junichi


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

Build-Depends: libfoo-dev more susceptible to breaking (Re: shared library -dev package naming proposal)

Hi,

  BTW, having Build-Depends: libfoo-dev in 
  a library's build-deps, will allow the developer
  to overlook a soname change in depending shared library.
  Which is a bad idea in the QA standpoint.
 
 Yes and no.
 
 The programer can overlook the soname change for the source. The API
 hasn't changed and nothing needs to adjust for the new soname.
 
 The packaging system won't let the binary forget the soname change
 though as that is part of the package name of the libary. Binaries
 will keep using the old lib till they are recompiled.

I'm talking about the following case:

1. libA depends on libB1, but only build-depends on libB-dev
2. libB1 changes to be libB2.
3. libA is rebuilt with libB2 without maintainer noticing (could happen 
  on buildd, etc.), possibly creating a noncompatible interface.

It would be a practical case especially when libB1, libB2 are not 
using versioned symbols.



regards,
junichi



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

Re: shared library -dev package naming proposal

Hi,

Thanks for your input.



  Having a solid naming scheme will allow me to
  
  ldd /usr/lib/libwhatever.so to track down its
  shared library dependency, and appending -dev 
  to individual package to create the list of 
  requisite -dev packages.
 
 If this is actually necessary for libtool-using packages, then write
 something which goes through all of the .la files and does this, since
 that's what libtool wants to do.

and 

 Errr, you still havn't said what problem you're trying to solve 
 with this yet.

1. To derive dependency information from libtool-using packages,
  it is currently possible to derive lists of shared library packages.

2. In general, there is a leap in shared library packages and -dev package,
  and it's not possible to get a -dev package which is for a given
  shared library package.

I envision that it would be nice to be able to agree on some kind of 
naming style so that it is possible to deduce the name of development
 library in some mechanical manner. It's not just because of autogenerating
-dev dependencies, but about usability of Debian as a Development 
platform :

$ objdump -p /usr/lib/libshared.so | sed -n 's/^ *SONAME *//p' | sed 
's/\(0-9\)\.so\./\1/; s/\.so\.//; s/$/-dev/'
libshared0-dev



An alternate solution is to have a database for that kind of thing, 
but I forsee that it requires effort to maintain and keep up-to-date.
It's rather embarassing to know that Debian isn't organized at all in this
manner.


regards,
junichi



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

Re: shared library -dev package naming proposal

Hi,

  Having a solid naming scheme will allow me to
 
  ldd /usr/lib/libwhatever.so to track down its
  shared library dependency, and appending -dev 
  to individual package to create the list of 
  requisite -dev packages.
 
 With the current scheme it is:
 
 ldd /usr/lib/libwhatever.so to track down its shared library
 dependency, strip the soversion and appending -dev to individual
 package to create the list of requisite -dev packages.

 And, by the way, that list is just plain wrong.

Okay, currently d-shlibs is using objdump, 
and does not recursively look for dependencies.

gotom suggested to use ldd, to obtain the full path of 
shared libraries, and I do see the limitation with
using ldd, as you pointed out illustratively
in your example.



regards,
junchi


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

Re: skills of developers

2005-07-15 Thread Thijs Kinkhorst

On Fri, July 15, 2005 02:36, Laszlo Boszormenyi wrote:
  Debian _Developer_. You can translate documents, submit then against
 the package as patch for example. You can even join to the translation
 teams.

You claim that if someone spends just as much time translating Debian as
someone else does on packaging software, the first one shouldn't become a
DD and the second one does? I disagree firmly.

Being an official DD is more than just technical: access to the archive
and machines. It means that you're officially affiliated with the project
(and can demonstrate this in a variety of ways, including a debian.org
email address). And that you can influence its direction when there's a
vote up. I don't see why packagers should and translators shouldn't be
allowed to vote if they invest the same amount of time.

Your you can submit patches as a translator goes just as well for
packagers; anyone can get a package in through a sponsor.

I do disagree with the original poster though: there's already enough
structure in Debian. To prevent problems like with the quoted zoo
maintainer who doesn't know C, you should be more careful who maintains
which package. But this is common sense, and should not need to be solved
by creating more different positions.


Regards
Thijs




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

Re: cpufrequtils init script in rcS.d

2005-07-15 Thread Mattia Dongili

On Thu, Jul 14, 2005 at 11:21:52AM +0200, Tollef Fog Heen wrote:
 * Mattia Dongili 
 
 | - setting the CPUFreq policy must be done as early as possible in the
 |   boot process (IMHO)
 
 Why?  This looks just like an opinion without any rationale.

Sorry. The main idea is making power management more effective, that's
why earlier is better here.
Anyway if it sounds that wrong I can still use regular update-rc.d
defaults.

-- 
mattia
:wq!


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

Re: shared library -dev package naming proposal

2005-07-15 Thread Francesco P. Lovergine

On Fri, Jul 15, 2005 at 09:36:47AM +0300, martin f krafft wrote:
 also sprach Junichi Uekawa [EMAIL PROTECTED] [2005.07.14.1416 +0300]:
  libfoobar-2.1-0 will have 
  libfoobar-2.1-0-dev.
 
 Please distinguish between API and ABI!
 

True. Indeed the proposed policy is already followed in case of ABI
changes. And any sane program would not compile when ever a library
change its _API_ in a way not back-compatible. 
If not, well that's an upstream issue, not a debian one :)

-- 
Francesco P. Lovergine


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

Re: Build-Depends: libfoo-dev more susceptible to breaking (Re: shared library -dev package naming proposal)

* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
   BTW, having Build-Depends: libfoo-dev in 
   a library's build-deps, will allow the developer
   to overlook a soname change in depending shared library.
   Which is a bad idea in the QA standpoint.
  
  Yes and no.
  
  The programer can overlook the soname change for the source. The API
  hasn't changed and nothing needs to adjust for the new soname.
  
  The packaging system won't let the binary forget the soname change
  though as that is part of the package name of the libary. Binaries
  will keep using the old lib till they are recompiled.
 
 I'm talking about the following case:
 
 1. libA depends on libB1, but only build-depends on libB-dev
 2. libB1 changes to be libB2.
 3. libA is rebuilt with libB2 without maintainer noticing (could happen 
   on buildd, etc.), possibly creating a noncompatible interface.
 
 It would be a practical case especially when libB1, libB2 are not 
 using versioned symbols.

Versioned symbols has nothing to do with this case.  If the API changes
(what you're talking about above) then perhaps the -dev name should
change.  Tieing the -dev name to the SONAME (ie: A*B*I) is not an
appropriate fix for dealing with API changes.  Quite a few packages
already handle this by having a version in the name of all the packages,
and then having a *seperate* incremented number in the name of the lib
package for the SONAME.  That's the correct way to solve this problem,
not trying to tie the ABI and the API together.

In fact, I believe glib2.0 is an example of this:
glib2.0-0 - The actual library, with the '0' revision of the ABI
glib2.0-dev - The headers, ie: API, for glib2.0.

This essentially says that the A*P*I for glib2.0 won't change in a
backwards-incompatible way.  If it does, then it's a bug and needs to be
fixed.  This does allow for A*B*I changes, which require only a
recompile of the application (because the API hasn't changed).

Now, there is a seperate issue with libtool-using libraries and .la
dependencies, but that's exactly what it is, a seperate issue.

Stephen


signature.asc
Description: Digital signature

Re: shared library -dev package naming proposal

* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
  If this is actually necessary for libtool-using packages, then write
  something which goes through all of the .la files and does this, since
  that's what libtool wants to do.
 
 and 
 
  Errr, you still havn't said what problem you're trying to solve 
  with this yet.
 
 1. To derive dependency information from libtool-using packages,
   it is currently possible to derive lists of shared library packages.
 
 2. In general, there is a leap in shared library packages and -dev package,
   and it's not possible to get a -dev package which is for a given
   shared library package.

Shared library packages and -dev packages represent different things.

 I envision that it would be nice to be able to agree on some kind of 
 naming style so that it is possible to deduce the name of development
  library in some mechanical manner. It's not just because of autogenerating
 -dev dependencies, but about usability of Debian as a Development 
 platform :
 
 $ objdump -p /usr/lib/libshared.so | sed -n 's/^ *SONAME *//p' | sed 
 's/\(0-9\)\.so\./\1/; s/\.so\.//; s/$/-dev/'
 libshared0-dev

Having a single naming style is somewhat difficult for libraries because
different upstreams choose to represent API changes differently.  An
example of this is OpenLDAP- their API hasn't ever changed in a
backwards-incompatible way (or so they tell me).  They do add things to
their API over time, though I think they generally try to do those
around major releases (2.0, 2.1, 2.2, 2.3, etc).  They also change the
ABI without (unfortunately) much hesitation.  The ABI changes need to be
tracked using the SONAME, but technically we could have just one
'libldap-dev' since OpenLDAP 1.3.  This isn't true for other upstreams,
such as glib, which, I infer from their naming scheme anyway, has API
changes generally around major releases, and those changes aren't
backwards-compatible. (ie: 1.3 to 2.0, or what have you).

Tieing the API to the SONAME is a *bad* idea, it implies changes where
there aren't any and requires changes to packages that aren't necessary.
Honestly, I think it'd be nice if we could teach the buildds to
automatically rebuild packages when the API hasn't changed.  I'd think
that'd make some of these transistions that we have to go through on
occation go alot faster.

 An alternate solution is to have a database for that kind of thing, 
 but I forsee that it requires effort to maintain and keep up-to-date.
 It's rather embarassing to know that Debian isn't organized at all in this
 manner.

Back to my previous comment- you've got people who aren't familiar with
SONAMES and ABIs writing libraries.  I don't feel that's *Debian's*
fault, though we do try to deal with it as best we can.  This suggestion
doesn't help that issue one bit though.

Stephen


signature.asc
Description: Digital signature

Re: shared library -dev package naming proposal

* Francesco P. Lovergine ([EMAIL PROTECTED]) wrote:
 On Fri, Jul 15, 2005 at 09:36:47AM +0300, martin f krafft wrote:
  also sprach Junichi Uekawa [EMAIL PROTECTED] [2005.07.14.1416 +0300]:
   libfoobar-2.1-0 will have 
   libfoobar-2.1-0-dev.
  
  Please distinguish between API and ABI!
  
 
 True. Indeed the proposed policy is already followed in case of ABI
 changes. And any sane program would not compile when ever a library
 change its _API_ in a way not back-compatible. 
 If not, well that's an upstream issue, not a debian one :)

Exactly! :)  We must have a seperate tracking of API and ABI changes.
To do otherwise is madness.

Stephen


signature.asc
Description: Digital signature

Re: interacting with the press

2005-07-15 Thread Matthew Palmer

On Fri, Jul 15, 2005 at 08:12:36PM +1200, Nigel Jones wrote:
 On 15/07/05, Matthew Palmer [EMAIL PROTECTED] wrote:
  On Wed, Jul 13, 2005 at 11:11:49AM +0200, Florian Weimer wrote:
   * Anand Kumria:
  
[1]: URL: 
http://smh.com.au/news/breaking/debian-debates-support-for-ports/2005/07/12/1120934228145.html
  
   Apparently, this is subscription only. 8-(
  
   Has this article been republished by another newspaper with less tight
   access controls?
  
  Lynx is love.
 I think it's just that they generate a random number to decide if they
 will let you view without registration (thats what happened for me),
 so you must be a lucky one ,)

No, they allow unregistered access to one article per day, but they work
that one in some fashion that apparently doesn't get triggered with lynx, so
you can view lots of articles (unless they've fixed that bug recently and I
haven't noticed).

- Matt


signature.asc
Description: Digital signature

Re: aspell dictionary packages fail to build

2005-07-15 Thread Agustin Martin

On Thu, Jul 14, 2005 at 04:34:05PM -0700, Matt Kraai wrote:
 Howdy,
 
 The aspell dictionary packages build-depend on aspell-bin ( 0.60).
 aspell-bin is now a virtual package provided by aspell, but virtual
 packages cannot be versioned, so these build-dependency cannot be
 satisfied.

That should be changed, (versioned) build dependency should now be on aspell
if they do not use aspell-autobuildhash, or use aspell prezip.

There are other things to be changed, aspell lib/data location, virtual
package provided, ...

 
 There are fifteen such packages:
 ...
  aspell-es
 

This one is now created from espa-nol source package, and is already fixed.
I already asked for aspell-es (source package) removal from unstable
(#317950).

On Fri, Jul 15, 2005 at 05:01:03PM +0900, Junichi Uekawa wrote:

 
 I'd see a benefit in filing mail beforehand for a change, but 
 after-the-fact, I have an impression that it's better to 
 file bugs on the packages since it's easier to track the problem that way.
 
 Unless there is a chance of reintroducing aspell-bin package, 
 that should probably be the case.
 
 I think this is the call of aspell maintainer.

Agreed, better leave this task to aspell maintainer. 

-- 
Agustin


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

Re: cpufrequtils init script in rcS.d

2005-07-15 Thread Andrew Suffield

On Fri, Jul 15, 2005 at 10:52:52AM +0200, Nico Golde wrote:
 Hi,
 * Andrew Suffield [EMAIL PROTECTED] [2005-07-15 10:50]:
  On Thu, Jul 14, 2005 at 11:21:52AM +0200, Tollef Fog Heen wrote:
   * Mattia Dongili 
   
   | - setting the CPUFreq policy must be done as early as possible in the
   |   boot process (IMHO)
   
   Why?  This looks just like an opinion without any rationale.
  
  It's dumb anyway. If you wanted it set early, you'd have done it on
  the kernel command line.
 
 Maybe its a misunderstanding but what is the problem of
 setting it during the normal use of the system?

There's no problem with setting it during normal use. It's just dumb
to worry about how early you can persuade sysvinit to set it, since if
you actually want it early, you can do it way before init starts.

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


signature.asc
Description: Digital signature

Re: Updating dpkg-cross: file moving question

2005-07-15 Thread Nikita V. Youshchenko

 The question is - how to process existing cross-compile environment,
 created by earlier versions of dpkg-cross.

 I am thinking to make the following trick. In postinst of new
 dpkg-cross, it will check for /usr/arm-linux, /usr/powerpc-linux/, and
 other places where packages created by earlier versions could place
 files. If any of such directories is found:
 - a directory with the new name will be created if not exists yet,
 - complete file hierarchy from the old directory will be copied to the
 new directory,
 - old directory will be replaces with a sympink to the new one.

 Looks that this procedure is more or less safe. E.g. removals of
 packages which files have been moved in this way, would remove correct
 files.

I've thought of an alternative way.

I may make dpkg-cross to generate additional provides/depends information 
for  arch-cross packages:
- each xxx-arch-cross package will
 Provides: xxx-arch-cross-layout-identifier
- when xxx deepnds on yyy, dpkg-cross will generate
 Depends: yyy-arch-cross, yyy-arch-cross-layout-identifier
- when xxx depends on yyy (= n), dpkg-cross will generate
 Depends: yyy-arch-cross (= n), yyy-arch-cross-layout-identifier

Looks that this guarantees that cross-compile setup at new location will be 
consistent. Also, it will make all package installations and removals 
clean.
Drawback are:
- tree at old location may become inconsistent (if x depends on y, 
x-arch-cross is generated by new dpkg-cross, and y-arch-cross is
generated by old dpkg-cross),
- if older (sarge) cross-compiler packages are used, they won't find 
cross-compilation tree unless symlinks are created manually.

Does this look better?


pgpebAnb7KHH7.pgp
Description: PGP signature

Re: Updating dpkg-cross: file moving question

2005-07-15 Thread Nikita V. Youshchenko

 - tree at old location may become inconsistent (if x depends on y,
 x-arch-cross is generated by new dpkg-cross, and y-arch-cross is
 generated by old dpkg-cross),

I meant 'y depends on x'.


pgpIcwjCKqUZO.pgp
Description: PGP signature

Re: Build-Depends: libfoo-dev more susceptible to breaking (Re: shared library -dev package naming proposal)

2005-07-15 Thread Goswin von Brederlow

Junichi Uekawa [EMAIL PROTECTED] writes:

 Hi,

  BTW, having Build-Depends: libfoo-dev in 
  a library's build-deps, will allow the developer
  to overlook a soname change in depending shared library.
  Which is a bad idea in the QA standpoint.
 
 Yes and no.
 
 The programer can overlook the soname change for the source. The API
 hasn't changed and nothing needs to adjust for the new soname.
 
 The packaging system won't let the binary forget the soname change
 though as that is part of the package name of the libary. Binaries
 will keep using the old lib till they are recompiled.

 I'm talking about the following case:

 1. libA depends on libB1, but only build-depends on libB-dev
 2. libB1 changes to be libB2.
 3. libA is rebuilt with libB2 without maintainer noticing (could happen 
   on buildd, etc.), possibly creating a noncompatible interface.

 It would be a practical case especially when libB1, libB2 are not 
 using versioned symbols.

If libB1 and libB2 are only an ABI change but not an API change then
libA will just compile and then have a Depends: libB2
automaticaly. That is fully intentional.

If libB1 and libB2 have different APIs then the libB maintainer
screwed up. API changes must eigther be reflected in the
libBapi_number-dev name (e.g. libpng2-dev, libpng12-dev) or the
maintainer must make damn sure all rdepends are updated along with
libB (suboptimal).

Since several people have started to infrequently recompile all of debian
to see if any sources broke any violations of this will get noticed.

 regards,
   junichi

MfG
Goswin


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

Re: shared library -dev package naming proposal

2005-07-15 Thread Goswin von Brederlow

Junichi Uekawa [EMAIL PROTECTED] writes:

 Hi,

  Having a solid naming scheme will allow me to
 
  ldd /usr/lib/libwhatever.so to track down its
  shared library dependency, and appending -dev 
  to individual package to create the list of 
  requisite -dev packages.

You could also suggest a policy for libs to have a libfoo.devname file
similar to the libfoo.shlibs file but naming the needed -dev
packages. If that is a good idea or not you have to think about. Just
a wild idea.

 With the current scheme it is:
 
 ldd /usr/lib/libwhatever.so to track down its shared library
 dependency, strip the soversion and appending -dev to individual
 package to create the list of requisite -dev packages.

 And, by the way, that list is just plain wrong.

 Okay, currently d-shlibs is using objdump, 
 and does not recursively look for dependencies.

 gotom suggested to use ldd, to obtain the full path of 
 shared libraries, and I do see the limitation with
 using ldd, as you pointed out illustratively
 in your example.

You have to do both. ldd for the full path and then filter that with
objdump. That is how dpkg-shlibdeps does it if I read the code right.

 regards,
   junchi

MfG
Goswin


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

unreproducable bugs

Hi,
is there a policy for bugs which are unreproducible?
I mean how long this kind of bug should be open?
There are bugs who are unreproducible for over a year and
the version increased to a major version during the time.
Regards Nico

-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


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

API/ABI in -dev package name?

libfoobar-2.1-0 will have 
libfoobar-2.1-0-dev.
   
   Please distinguish between API and ABI!
   
  
  True. Indeed the proposed policy is already followed in case of ABI
  changes. And any sane program would not compile when ever a library
  change its _API_ in a way not back-compatible. 
  If not, well that's an upstream issue, not a debian one :)
 
 Exactly! :)  We must have a seperate tracking of API and ABI changes.
 To do otherwise is madness.

Hmm... I don't think Debian -dev package and 
shared library packages really reflect what we consider to be
ABI/API.

Nothing documented about that, and it's not really done in practice.

Currently people just package libwhatever-dev and break API whenever they
please.


regards,
junichi


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

Re: shared library -dev package naming proposal

Hi,

Thanks for your time and feedback. I appreciate it very much.


 You could also suggest a policy for libs to have a libfoo.devname file
 similar to the libfoo.shlibs file but naming the needed -dev
 packages. If that is a good idea or not you have to think about. Just
 a wild idea.

Yes, that's basically what shlibs file is doing for shared libraries.
I was hoping that it was more practical to have a 
Provides: field or a package name that can be linked from 
the shared library package.


Stephen Frost has explained to me that -dev package names
apparently express their API, and their maintainers
can be beaten to whatever when they break, 
and I kind of agree that might even be a good idea,
I would like to drop the idea of unanimously 
requesting packages to name their -dev packages thus way.


From the standpoint of a Debian user, it still stands that 
shared library packages and -dev packages (which has a 
symlink pointing to the shared library package) do not 
have an explicit relationship declared in Debian,
except for the fact that they are often created from the 
same source.

Stephen's points are valid and quite useful 
considering an upstream developer's point of view,
but for random user joe who is trying to find a development
package, one of the following may help him find the right package


1. creating a system-wide list of what -dev package does what.

  - centrally requires work. Already started in d-shlibs.

2. creating a devlibs file which points to what shared library
  is handled by which -dev package.

  - requires manual intervention by all developers,
  and utilizes an i-node for all shared library installations.

3. creating a package policy to Provides: a symbollic name
   that can be traced from the shared library package name or
   the shared library soname.

  - non-invasive if it's done gradually.


  Okay, currently d-shlibs is using objdump, 
  and does not recursively look for dependencies.
 
  gotom suggested to use ldd, to obtain the full path of 
  shared libraries, and I do see the limitation with
  using ldd, as you pointed out illustratively
  in your example.
 
 You have to do both. ldd for the full path and then filter that with
 objdump. That is how dpkg-shlibdeps does it if I read the code right.

Thanks for pointing that out.
This knowledge may become useful when ldd output can be converted to
a list of -dev packages.


regards,
junichi

Re: API/ABI in -dev package name?

2005-07-15 Thread Philipp Kern

On Fri, 2005-07-15 at 22:33 +0900, Junichi Uekawa wrote:
 Currently people just package libwhatever-dev and break API whenever they
 please.

That's an upstream issue more or less. With libtoolised packages
-release has to be used if the API breaks in a non backwards-compatible
way. This would also be encoded in the dev-package's name.

Kind regards,
Philipp Kern



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

Re: shared library -dev package naming proposal

2005-07-15 Thread Daniel Kobras

On Fri, Jul 15, 2005 at 10:44:04PM +0900, Junichi Uekawa wrote:
 Stephen's points are valid and quite useful 
 considering an upstream developer's point of view,
 but for random user joe who is trying to find a development
 package, one of the following may help him find the right package
 
 
 1. creating a system-wide list of what -dev package does what.
 
   - centrally requires work. Already started in d-shlibs.
 
 2. creating a devlibs file which points to what shared library
   is handled by which -dev package.
 
   - requires manual intervention by all developers,
   and utilizes an i-node for all shared library installations.
 
 3. creating a package policy to Provides: a symbollic name
that can be traced from the shared library package name or
the shared library soname.
 
   - non-invasive if it's done gradually.

Make shared library packages Suggest: their corresponding -dev packages.

Regards,

Daniel.


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

Re: unreproducable bugs

Hi,

 is there a policy for bugs which are unreproducible?
 I mean how long this kind of bug should be open?
 There are bugs who are unreproducible for over a year and
 the version increased to a major version during the time.

I tend to request the user for more info with the new version;
so add a +moreinfo, and send a mail to the user that
if the user doesn't respond within a reasonable timeframe
(say 2 months), it will be closed.

It should work; it's not easy to really fix a bugreport which
is unreproducible and the reporter is no longer able to 
respond.



regards,
junichi


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

Re: unreproducable bugs

Hi,
* Junichi Uekawa [EMAIL PROTECTED] [2005-07-15 16:12]:
  is there a policy for bugs which are unreproducible?
  I mean how long this kind of bug should be open?
  There are bugs who are unreproducible for over a year and
  the version increased to a major version during the time.
 
 I tend to request the user for more info with the new version;
 so add a +moreinfo, and send a mail to the user that
 if the user doesn't respond within a reasonable timeframe
 (say 2 months), it will be closed.
 
 It should work; it's not easy to really fix a bugreport which
 is unreproducible and the reporter is no longer able to 
 respond.

Yes that would make sense. But what about documentating
this so it don't have to be just a feeling of the maintainer
that it is time to close it? Maybe in the developers reference?
Regards Nico

-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


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

Re: skills of developers

2005-07-15 Thread Eduard Bloch

#include hallo.h
* Thijs Kinkhorst [Fri, Jul 15 2005, 12:27:55PM]:
 On Fri, July 15, 2005 02:36, Laszlo Boszormenyi wrote:
   Debian _Developer_. You can translate documents, submit then against
  the package as patch for example. You can even join to the translation
  teams.
 
 You claim that if someone spends just as much time translating Debian as
 someone else does on packaging software, the first one shouldn't become a
 DD and the second one does? I disagree firmly.

Packaging is the essential work and everyone involved into Debian must
be able to do the basic things. You don't go to military just to sit
around and do office work - everyone has to go trough basic training.

 Being an official DD is more than just technical: access to the archive
 and machines. It means that you're officially affiliated with the project

You get the access because you need it - to do your work as packager. Do
you really want to tell us that you absoletely need to have access to an
ia64 box to reproduce a weird upstream bug in ... an SGML text?

 (and can demonstrate this in a variety of ways, including a debian.org
 email address). And that you can influence its direction when there's a

Aha, that's what it is all about. Demonstrate the beeing a VIP.

 vote up. I don't see why packagers should and translators shouldn't be
 allowed to vote if they invest the same amount of time.

The outcome of the votes mostly affects... whom? Right, the packagers,
or at least people that know what it is all about. For the same reasons
Debian policy is not written by lawyers or philosophers.

 Your you can submit patches as a translator goes just as well for
 packagers; anyone can get a package in through a sponsor.

If the software is worthy beeing packaged and the packaging quality is
good (or can be improved in co-work with the maintainer), there should
be no big problem finding a sponsor.

Regards,
Eduard.

-- 
mrvn schoos: Für was ist denn Pascal besser geeignet als andere oder Scheme?
schoos mrvn: Pascal? Für das Verständnis von Wirths Büchern
mrvn Dafür gibts doch Oberon
schoos mrvn: Kommt drauf an von wann die Bücher sind


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

Re: API/ABI in -dev package name?

* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
  Exactly! :)  We must have a seperate tracking of API and ABI changes.
  To do otherwise is madness.
 
 Hmm... I don't think Debian -dev package and 
 shared library packages really reflect what we consider to be
 ABI/API.
 
 Nothing documented about that, and it's not really done in practice.
 
 Currently people just package libwhatever-dev and break API whenever they
 please.

Eh?  It *is* done in practice, look at my other email wrt glib.  Some
upstreams are actually quite good about their APIs and just don't ever
break it in a backwards-incompatible way.  In those cases
'libwhatever-dev' is perfectly fine.  Regardless, what you're suggesting
is probably done *less* in practice, so that argument certainly doesn't
hold.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: shared library -dev package naming proposal

2005-07-15 Thread Ondrej Sury

 Stephen's points are valid and quite useful 
 considering an upstream developer's point of view,
 but for random user joe who is trying to find a development
 package, one of the following may help him find the right package

Joe user should do:

apt-cache search libNAME dev

(or use synaptic, aptitude, etc.)

That's what do I do when I search for library.

Ondrej.
-- 
Ondrej Sury [EMAIL PROTECTED]


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

Re: Build-Depends: libfoo-dev more susceptible to breaking (Re: shared library -dev package naming proposal)

On Fri, Jul 15, 2005 at 05:18:23PM +0900, Junichi Uekawa wrote:
   BTW, having Build-Depends: libfoo-dev in 
   a library's build-deps, will allow the developer
   to overlook a soname change in depending shared library.
   Which is a bad idea in the QA standpoint.

  Yes and no.

  The programer can overlook the soname change for the source. The API
  hasn't changed and nothing needs to adjust for the new soname.

  The packaging system won't let the binary forget the soname change
  though as that is part of the package name of the libary. Binaries
  will keep using the old lib till they are recompiled.

 I'm talking about the following case:

 1. libA depends on libB1, but only build-depends on libB-dev
 2. libB1 changes to be libB2.
 3. libA is rebuilt with libB2 without maintainer noticing (could happen 
   on buildd, etc.), possibly creating a noncompatible interface.
  

That's the part that needs to be fixed.

 It would be a practical case especially when libB1, libB2 are not 
 using versioned symbols.

Except that libB *should* be using versioned symbols, for all libB where
there exists a libA that depends on it.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: shared library -dev package naming proposal

On Fri, Jul 15, 2005 at 05:30:44PM +0900, Junichi Uekawa wrote:
   Having a solid naming scheme will allow me to

   ldd /usr/lib/libwhatever.so to track down its
   shared library dependency, and appending -dev 
   to individual package to create the list of 
   requisite -dev packages.

  If this is actually necessary for libtool-using packages, then write
  something which goes through all of the .la files and does this, since
  that's what libtool wants to do.

 and 

  Errr, you still havn't said what problem you're trying to solve 
  with this yet.

 1. To derive dependency information from libtool-using packages,
   it is currently possible to derive lists of shared library packages.

 2. In general, there is a leap in shared library packages and -dev package,
   and it's not possible to get a -dev package which is for a given
   shared library package.

 I envision that it would be nice to be able to agree on some kind of 
 naming style so that it is possible to deduce the name of development
  library in some mechanical manner. It's not just because of autogenerating
 -dev dependencies, but about usability of Debian as a Development 
 platform :

 $ objdump -p /usr/lib/libshared.so | sed -n 's/^ *SONAME *//p' | sed 
 's/\(0-9\)\.so\./\1/; s/\.so\.//; s/$/-dev/'
 libshared0-dev

$ apt-cache showsrc $(dpkg -S /usr/lib/libxslt.so.1 | cut -f1 -d:) \
  | sed -n -e's/^Binary: //p' | sed -e's/,[[:space:]]\+/\n/g' | grep -- -dev \
  | sort -u
libxslt1-dev
$

Can be refined to only query sources for a particular dist, etc.  Can't cope
with multiple -dev packages from a single source package without recourse to
the Contents files.

OTOH, your solution just don't seem to offer much unless *all* packages
conform to the proposed scheme, and it's already been argued that there are
cases that your scheme doesn't address...  and even if everyone agreed it
was a good idea, it would take a long time before developers would get the
benefits of it, because of all the conversions that would need to take
place.  I just don't see the point.

 An alternate solution is to have a database for that kind of thing, 
 but I forsee that it requires effort to maintain and keep up-to-date.

Like the database I just queried above? :)

 It's rather embarassing to know that Debian isn't organized at all in this
 manner.

You seem to be embarrassed easily.  If this is such a problem for using
Debian as a development platform, why is this the first time I've seen the
subject discussed on debian-devel?

I'm not convinced that the problem you're trying to solve is of sufficiently
general interest to outweigh all of the other problems it introduces (such
as the ones that have been pointed out in this thread).

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: congratulations to the X team!!

2005-07-15 Thread Brendan

On Thursday 14 July 2005 04:29 pm, Greg Folkert wrote:
 But, I don't see the rendering problems others see. Of course I have an

When I first started up xorg after the upgrade, it took a full 100% of the 
CPU. I restarted X, same deal...So I rebooted and started X, and the problem 
disappeared. Sid box. Other than that, my Mepis box at home took the upgrade 
as well.


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

Re: API/ABI in -dev package name?

On Fri, Jul 15, 2005 at 04:02:48PM +0200, Philipp Kern wrote:
 On Fri, 2005-07-15 at 22:33 +0900, Junichi Uekawa wrote:
  Currently people just package libwhatever-dev and break API whenever they
  please.

 That's an upstream issue more or less. With libtoolised packages
 -release has to be used if the API breaks in a non backwards-compatible
 way.

Not consistently.  Indeed, I've never heard of such a practice; can you give
an example?

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: unreproducable bugs

2005-07-15 Thread Manoj Srivastava

On Fri, 15 Jul 2005 15:42:44 +0200, Nico Golde [EMAIL PROTECTED] said: 

 Hi, is there a policy for bugs which are unreproducible?  I mean how
 long this kind of bug should be open?  There are bugs who are
 unreproducible for over a year and the version increased to a major
 version during the time.  Regards Nico

Umm, no. It is left to the discretion and judgement of the
 developer.  Like others in the thread, I, too, tend to ask the
 submitter if the bug can still be reproduced, and, if so, to resubmit
 a log to see if any additional information has turned up.

What's with the recent push to get every little things written
 down into policy, so the developer no longer is required to have an
 ability to think, or exercise any judgement whatsoever?

manoj
-- 
After the correction has been found to be in error, it will be
impossible to fit the original quantity back into the
equation. --anonymous
Manoj Srivastava   [EMAIL PROTECTED]  http://www.debian.org/%7Esrivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

You need only 15 minutes to prepare for the night of love.

2005-07-15 Thread Beck


Identical to the brandname drugs, low prices, international shipping.
http://rjsv.p4a0b87imzpfbqp.sottedbbfhm.com



To find fault is easy; to do better may be difficult.  
Having the fewest wants, I am nearest to the gods.   
Time is fun when you're eating flies.  




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

Trusted savings on prescription drugs.

2005-07-15 Thread Bobby


A better way to shop for health  beauty.
http://tfmc.vag6zevos5v3hwv.vitalsjmgen.com



Ability will never catch up with the demand for it.   
It is not white hair that engenders wisdom. 
In summer, the song sings itself.   




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

Re: congratulations to the X team!!

2005-07-15 Thread Klaus Ethgen

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Also congratulation from me too. I thought of many think that whould be
broken but only few packages I liked very much did not work anymore as
they need xlibmesa-glu:
xine
openuniverse
planetpenguin-racer
audacity
flightgear
ssystem
stellarium
xscreensaver-gl

I will try to make a dummy-package which provides xlibmesa-glu and
depends on libglu1-xorg. ;-)

Gruß
   Klaus

Ps. Im not a official debian maintainer but also a beer from me for them
I meet in person. ;-)
- -- 
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)

iQEVAwUBQtfwmJ+OKpjRpO3lAQLlBQf/ZKz3IGNSxgJ9SUH8BKIlJVIaWbi71DKd
juPyhaefL1zIEdF+5d1hkI+56fStoru9TpMK/zJlXu8H4KRKxu/rwAD3TxlTeycN
M5zQ8OD7N5aTtGsA6UlJzJI8O9jzF+YrfgaSnqnbdD0Kv2+WyBlf0pExK3JQcbSq
VY7D+TKAFRArPzH7tup+SKw5sUHr1Ikkp/zwrP+RmEunNWChGbT3EYXl2eiGQiF9
m5lfpq9aoCHE1vw0j4jQ5Sro9fZG4Q1DTjcb5dTv7f3i4gTXhUXZUUA1e/eBGOYu
PpZQOuJ82lokClI0h0hxIplSVHsCelvdEyo+J6GdFNJvm+VMlY9S3w==
=n7v8
-END PGP SIGNATURE-


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

Re: congratulations to the X team!!

2005-07-15 Thread Klaus Ethgen

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 I will try to make a dummy-package which provides xlibmesa-glu and
 depends on libglu1-xorg. ;-)

Hmpf, dosn't work as libglu1-xorg conflicts xlibmesa-glu :-(

Regards
   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)

iQEVAwUBQtfya5+OKpjRpO3lAQLw0Af7BzbWJayX5v/YllsCAWWfnA1DlsXiheEw
TYprFvfapMCfCgldylwK9ipmiT2TX18hEXYO0e3++kQVBSsSNEpYjy4WKMbaDch6
WwbnhbewKem/WKzcLZMqQv0sjl7JGveNWgE0DCpYVVmkU6Ybb1YHiyN0YaEzpIBl
kC/ROzZWAy24zAA6JJSj968en67jzewXldjz3Mc9lMGkCg1EK3sUZ6Ld+UqKXbcR
lJSgaPq7ebSCm5k2yuWKJ4VW+9PhYkmvfPdbtqN6mRFQ4jDEvULpz2KXqBz+slXp
xjMbKTjC3CLv/xUGzY1GrBmzNSAyhEY4tHVm2SHRyIB4VTlOBRrbFg==
=AW30
-END PGP SIGNATURE-


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

Bug#318465: ITP: moto4lin -- filemanager and seem editor for Motorola phones (like C380/C650)

2005-07-15 Thread Miguel Gea Milvaques

Package: wnpp
Severity: wishlist
Owner: Miguel Gea Milvaques [EMAIL PROTECTED]

* Package name: moto4lin
  Version : 0.3
  Upstream Author : Dmitry Nezhevenko dionua at users.sourceforge.net
* URL : http://sourceforge.net/projects/moto4lin
* License : GPL
  Description : filemanager and seem editor for Motorola phones (like 
C380/C650)

This application allow to upload/download files from Motorola P2k Phones,
upload/download seem records, doing seem backup, and editing seem using
simple hex editor.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.10
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)


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

Re: congratulations to the X team!!

On Fri, Jul 15, 2005 at 07:21:28PM +0200, Klaus Ethgen wrote:
 Also congratulation from me too. I thought of many think that whould be
 broken but only few packages I liked very much did not work anymore as
 they need xlibmesa-glu:
 xine
 openuniverse
 planetpenguin-racer
 audacity
 flightgear
 ssystem
 stellarium
 xscreensaver-gl
 
 I will try to make a dummy-package which provides xlibmesa-glu and
 depends on libglu1-xorg. ;-)

Please don't do this. We're trying to transition the libglu1-xorg packages
and the above packages should be fixed by their respective maintainers in
time.

 - David Nusinow


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

Re: unreproducable bugs

2005-07-15 Thread kamaraju kusumanchi


Manoj Srivastava wrote:

On Fri, 15 Jul 2005 15:42:44 +0200, Nico Golde [EMAIL PROTECTED] said: 

 


   What's with the recent push to get every little things written
down into policy, so the developer no longer is required to have an
ability to think, or exercise any judgement whatsoever?

   manoj
 

Dont know about others. But whenever I post some question on irc or a 
mailing list the most frequent answer is 'it is there in the policy', 
'go by the policy', 'read the policy' etc., Similar answers would have 
made other people think that all Debian maintainers/developers should 
go by the policy and only by the policy.


just my 2 cents
raju

--
Kamaraju S Kusumanchi
Graduate Student, MAE
Cornell University
http://www.people.cornell.edu/pages/kk288/


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

Re: congratulations to the X team!!

On Fri, Jul 15, 2005 at 07:21:28PM +0200, Klaus Ethgen wrote:
 Also congratulation from me too. I thought of many think that whould be
 broken but only few packages I liked very much did not work anymore as
 they need xlibmesa-glu:
 xine
 openuniverse
 planetpenguin-racer
 audacity
 flightgear
 ssystem
 stellarium
 xscreensaver-gl

 I will try to make a dummy-package which provides xlibmesa-glu and
 depends on libglu1-xorg. ;-)

Why do people think that xorg broke library dependencies for our
entertainment, and that patching over the dependencies is an ok solution?
The package name changed because it is *not* *compatible*.  No one said the
C++ transition was supposed to be fun, did they?

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Gradual mass bug filing for C++ transition / gcc-4.0 issues

2005-07-15 Thread Daniel Schepler

I'm planning to start making sure every package which fails to build
with the current toolchain has an RC bug submitted against it.  In
most cases, this should simply involve setting Andreas Jochens'
already existing bugs to serious, although I'll confirm each before
doing this.  Exceptions will include:

- Packages waiting on other packages to transition.
- Failures clearly due to glibc issues (e.g. invalid lvalue errors
caused by rpc/xdr.h).

I might also do NMU's for some of the more important packages, with a
delay of 2 days, or 5 days minus the time since the last dependent
package transitioned, whichever is longer.  Right now I have my eyes
on jade/opensp/openjade, and possibly db*.

By the way, any estimates on how long it will be before we get a glibc
upload correcting the problems mentioned above?
-- 
Daniel Schepler  Please don't disillusion me.  I
[EMAIL PROTECTED]haven't had breakfast yet.
 -- Orson Scott Card


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

Re: congratulations to the X team!!

On Fri, Jul 15, 2005 at 10:59:21AM -0700, Steve Langasek wrote:
 On Fri, Jul 15, 2005 at 07:21:28PM +0200, Klaus Ethgen wrote:
  I will try to make a dummy-package which provides xlibmesa-glu and
  depends on libglu1-xorg. ;-)
 
 Why do people think that xorg broke library dependencies for our
 entertainment, and that patching over the dependencies is an ok solution?
 The package name changed because it is *not* *compatible*.  No one said the
 C++ transition was supposed to be fun, did they?

I'm mainly depressed that people aren't reading Planet Debian, or are just
ignoring it. Is there a better place to post this sort of thing so that
users don't keep repeating the same non-bug? The BTS obviously isn't
working for us here either, nor is posting to debian-x.

I think I'll have to put something in X.Org's NEWS.Debian about it at the
very least, but if anyone has any ideas for this, I'm all ears. I refuse to
resort to a debconf warning for this, but I'm running out of ideas.

 - David Nusinow


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

Re: congratulations to the X team!!

2005-07-15 Thread Florian Weimer

* Steve Langasek:

 Why do people think that xorg broke library dependencies for our
 entertainment, and that patching over the dependencies is an ok
 solution?

Because there was no recent announcement on debian-devel-announce
which provided some guidance for this transition?

The packaging itself appears to be really nice, but this kind of
information seems to be a bit too hard to find at the moment.


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

Re: unreproducable bugs

Hi,
* Manoj Srivastava [EMAIL PROTECTED] [2005-07-15 20:08]:
 On Fri, 15 Jul 2005 15:42:44 +0200, Nico Golde [EMAIL PROTECTED] said: 
 
  Hi, is there a policy for bugs which are unreproducible?  I mean how
  long this kind of bug should be open?  There are bugs who are
  unreproducible for over a year and the version increased to a major
  version during the time.  Regards Nico
 
 Umm, no. It is left to the discretion and judgement of the
 developer.  Like others in the thread, I, too, tend to ask the
 submitter if the bug can still be reproduced, and, if so, to resubmit
 a log to see if any additional information has turned up.

Yes thats what i would do too but I have seen alot of bugs
where the emailaddress isn't actual anymore.

 What's with the recent push to get every little things written
 down into policy, so the developer no longer is required to have an
 ability to think, or exercise any judgement whatsoever?

no of course not but it would be good to have a reference
value.
Regards Nico

-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


pgpLbiHVCrEFI.pgp
Description: PGP signature

Re: congratulations to the X team!!

2005-07-15 Thread Florian Weimer

* David Nusinow:

 I'm mainly depressed that people aren't reading Planet Debian, or are just
 ignoring it. Is there a better place to post this sort of thing so that
 users don't keep repeating the same non-bug? The BTS obviously isn't
 working for us here either, nor is posting to debian-x.

I think it's perfectly acceptable to describe the transition in a
short posting to debian-devel-announce.

Anyway, where on Planet Debian can I find this information?  Is it in
one of the referenced blogs?

 I think I'll have to put something in X.Org's NEWS.Debian about it at the
 very least, but if anyone has any ideas for this, I'm all ears.

You could add a news item to NEWS.Debian which is removed before
release, I think (provided that apt-listchangelogs can handle this
situation).


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

Re: congratulations to the X team!!

On Fri, Jul 15, 2005 at 08:07:55PM +0200, Florian Weimer wrote:
 * Steve Langasek:
 
  Why do people think that xorg broke library dependencies for our
  entertainment, and that patching over the dependencies is an ok
  solution?
 
 Because there was no recent announcement on debian-devel-announce
 which provided some guidance for this transition?
 
 The packaging itself appears to be really nice, but this kind of
 information seems to be a bit too hard to find at the moment.

Not a single developer has mailed either myself personally or debian-x to
ask how to go about this. Given that the C++ transition was already laid
out in full in debian-devel-announce, I assume that developers know what's
going on. It's the users who are clueless this time. That said, if any
developer does have any questions about the X.Org C++ transition I'd be
happy to answer them.

 - David Nusinow


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

Re: congratulations to the X team!!

2005-07-15 Thread Klaus Ethgen

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello foks,

Am Fr den 15. Jul 2005 um 19:32 schrieb David Nusinow:
  I will try to make a dummy-package which provides xlibmesa-glu and
  depends on libglu1-xorg. ;-)
 
 Please don't do this. We're trying to transition the libglu1-xorg packages
 and the above packages should be fixed by their respective maintainers in
 time.

Well, dosn't work either. It was just a idea that all the packages don't
get deinstalled and maybe can be used. Also pdl which is needed for
gimp-perl has wrong dependencies.

Am Fr den 15. Jul 2005 um 19:59 schrieb Steve Langasek:
 Why do people think that xorg broke library dependencies for our
 entertainment, and that patching over the dependencies is an ok solution?
 The package name changed because it is *not* *compatible*.  No one said the

I did not think that. Just thinking that short time broken installed
packages in sig are better than not broken but not installable packages
which gets deinstalled.

And yes, this information about some packages which could be brokesn
could be good filled in the NEWS.debian.

Am Fr den 15. Jul 2005 um 20:04 schrieb David Nusinow:
 I'm mainly depressed that people aren't reading Planet Debian, or are just

Aham, sorry for my ignorance, but what is Planet Debian?

 users don't keep repeating the same non-bug? The BTS obviously isn't
 working for us here either, nor is posting to debian-x.

Well, true that kind is nothing to fill in the bts (Maybe for the broken
packages but not for X).

Regards
   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)

iQEVAwUBQtf+r5+OKpjRpO3lAQIxXwgAiw/4WOK79bOEaQtqtaamG9g++lo7V8ft
1dW37GV2C1kYkeB15rLZqFBhVKfSS+lpj4AdX0gS9eCWVmSSUs3/HokqLTm/weRI
uDpVlcXk+D+3zMmXyG+rMbDHrVByFdsQuuljgPIZkXFhB8uRZv54+dgJzMqzKHpt
LgBlfgAp9dM1ZiaqHuCv4gu/OGK22rR+wSnFe1iJd/uYr4VpKGWeCB9Jv/uxirWm
Pewe2AkYcSdMhVpySSeqkpkE8rLRGFMI+qUiqL4J9NOPm67Nr3IFa+YT3ISKSsCI
J9NiiSITkaXUVkCxYD4AubXwpGVTG/1ufFr0tM6iNqekgNgKKwXmew==
=FwGQ
-END PGP SIGNATURE-


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

Seeking co-maintainer for adduser

2005-07-15 Thread Marc Haber

Hi,

Adduser is rapidly nearing its 10th birthday and has been maintained
by Roland Bauerschmidt since 2000. In 2004, I joined the adduser team,
and have done most of the work in adduser in the last year.

The code in adduser is old, non-modular, spaghetti-like, in two
words: Needs rewriting. The main cause is that adduser relies on
shadow and password do to the real work and thus interfaces badly with
more modern methods of user management like NIS and LDAP which are
rapidly increasing in their importance. For a more closer roundup of
missing features, take a look into adduser's BTS entry.

Roland is currently very busy with his non-Debian life and it is
unclear whether he will have time to spend on adduser in the future.
Regarding me, I will take the time to fix urgent bugs in adduser, but
I won't implement any new features, and I surely won't participate in
the rewrite of adduser which has been started multiple times, with its
most prominent result being adduser-ng in the archive. However, the
adduser-ng packages haven't seen maintainer action in a quite long
time and I'm inclined to call adduser-ng abandoned.

This e-mail is going out to solicit co-maintainers for the adduser
package. My ideal candidate:

  - Is willing to spend time not only on improving the old adduser
code base, but also in the rewrite which _must_ come sooner or later
to improve interaction with different user database backends
  - Knows about NIS, LDAP and other user database backends
  - Is familiar with translation infrastructure for debconf templates,
man pages and program texts
  - Knows how to interface with other maintainers (shadow, ldap, nis)
and translators
  - Will first write a test suite for the package before touching the
actual code

adduser is a very important package for Debian, and it's a shame that
it doesn't get the attention it needs. I am afraid that only the most
important bug fixes will be done for the package until somebody
volunteers to put more manpower into it.

New members of the adduser team do not need to be full DDs, I can
sponsor the packages.

People interested, please subscribe to the adduser-devel mailing list
(http://lists.alioth.debian.org/mailman/listinfo/adduser-devel), say
hello, take a look at the bugs open in the BTS, and start submitting
patches. I will eventually hand out commit privileges to the project
svn to people who have successfully submitted patches. Commit
privileges to the project svn will be handed out immediately if
somebody comes up with actually new code for the rewrite.

Thanks for helping!

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835


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

Re: unreproducable bugs

2005-07-15 Thread sean finney

On Fri, Jul 15, 2005 at 08:11:15PM +0200, Nico Golde wrote:
 no of course not but it would be good to have a reference
 value.

it seems something that would be most appropriate as a guideline
supplied in the debian developers' reference.


sean

-- 


signature.asc
Description: Digital signature

Re: congratulations to the X team!!

On Fri, Jul 15, 2005 at 08:21:36PM +0200, Klaus Ethgen wrote:
 Am Fr den 15. Jul 2005 um 20:04 schrieb David Nusinow:
  I'm mainly depressed that people aren't reading Planet Debian, or are just
 
 Aham, sorry for my ignorance, but what is Planet Debian?

http://planet.debian.org. Specifically, I had a blog entry
(http://www.livejournal.com/users/gravityboy/16446.html) that referred to
this very problem. This isn't an official means of communication, but a
great number of users read the site and my hope has been that it would be a
good way to communicate directly with them. I still have a lot of faith in
this approach, but it's obviously no panacea.

 - David Nusinow


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

Re: unreproducable bugs

Hi,
* sean finney [EMAIL PROTECTED] [2005-07-15 20:43]:
 On Fri, Jul 15, 2005 at 08:11:15PM +0200, Nico Golde wrote:
  no of course not but it would be good to have a reference
  value.
 
 it seems something that would be most appropriate as a guideline
 supplied in the debian developers' reference.

yes i suggested the same in my second mail.
regards nico
-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


pgpSiXy93p1ek.pgp
Description: PGP signature

Re: unreproducable bugs

On 7/15/05, Manoj Srivastava va, manoj [EMAIL PROTECTED] wrote:
 What's with the recent push to get every little things written
  down into policy, so the developer no longer is required to have an
  ability to think, or exercise any judgement whatsoever?

Welcome to the software industry in 2005.  If you haven't yet
encountered a senior software engineer with three degrees and a
six-figure salary who couldn't debug his way out of a paper bag, you
work in a very different part of the industry than I do.  [Note that I
am not accusing Nico or anyone else in Debian of fitting this
description.]

The threshold at which it is actually rather improbable that one
totally lacks the capacity for independent judgment seems to be
principal engineer -- a director equivalent in many large companies.
 I have worked with a number of junior staff whose performance
exceeded my expectations for their level of seniority -- including at
least one guy with a so-so high school education who was more able
than several MSCS's I have known -- but they are very much the
exceptions rather than the rule.

It's not the lack of (programming or human) language skills that's the
problem -- it's the lack of thinking skills.  I don't know if they can
be taught, but they certainly aren't being taught.  This problem is
endemic in the US educational system -- reputed to be worse in
California than almost anywhere else, even most of the Deep South --
and if my personal experience is any guide there are a few other
countries that are in similar positions.

Formal evaluation processes don't seem to do jack to keep the nitwits
out.  The only thing I've ever seen work is a self-selected review
team with anonymous blackball authority and a few seriously cranky
members.  That, of course, has its own problems; but it does work, at
least for a while.

Cheers,
- Michael

Re: congratulations to the X team!!

On Fri, Jul 15, 2005 at 02:04:14PM -0400, David Nusinow wrote:
 On Fri, Jul 15, 2005 at 10:59:21AM -0700, Steve Langasek wrote:
  On Fri, Jul 15, 2005 at 07:21:28PM +0200, Klaus Ethgen wrote:
   I will try to make a dummy-package which provides xlibmesa-glu and
   depends on libglu1-xorg. ;-)

  Why do people think that xorg broke library dependencies for our
  entertainment, and that patching over the dependencies is an ok solution?
  The package name changed because it is *not* *compatible*.  No one said the
  C++ transition was supposed to be fun, did they?

 I'm mainly depressed that people aren't reading Planet Debian, or are just
 ignoring it. Is there a better place to post this sort of thing so that
 users don't keep repeating the same non-bug? The BTS obviously isn't
 working for us here either, nor is posting to debian-x.

 I think I'll have to put something in X.Org's NEWS.Debian about it at the
 very least, but if anyone has any ideas for this, I'm all ears. I refuse to
 resort to a debconf warning for this, but I'm running out of ideas.

I agree that d-d-a is probably reasonable for this.  I'm sure it won't give
you 100% coverage, given that there are users posting to random lists like
debian-testing about the matter (...), but I imagine it will help more
people get a grasp of unstable. :)

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

RE: Bug#317892: ITP: bum -- tool to manage boot scripts

2005-07-15 Thread Thomas Hood

On Tue, 12 Jul 2005 11:09:56 -0300, Humberto Massa Guimarães wrote:
 I am a fan of vi + file-rc myself, but... anyway, the packager
 should conflict this package with file-rc or depend on sysv-rc,
 whatever is better...

Currently it does both.  I think that it should just Depend on
sysv-rc and leave the Conflicting up to the latter.

The salty dog and I have been discussing runlevel editors in
general and bum in particular.  I think that the next release
of bum will be rather good.  :)

-- 
Thomas Hood


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

Re: shared library -dev package naming proposal

On 7/15/05, Steve Langasek [EMAIL PROTECTED] wrote:
 On Fri, Jul 15, 2005 at 05:30:44PM +0900, Junichi Uekawa wrote:
  An alternate solution is to have a database for that kind of thing,
  but I forsee that it requires effort to maintain and keep up-to-date.
 
 Like the database I just queried above? :)

There's an even better one called Google.  If you're adding a
library dependency to a package that you plan to maintain for the
benefit of a large number of users, you might want to know a little
more about the library, its upstream, and its packager than just what
the relationship is between foo.sf.net, foo-X.X.tgz, and the binary
package names.

Automated tools, on the other hand, can and should be primed with
data, not heuristics.  Test suites _should_ be fragile so that if
something changes in a remotely questionable way you _spot_ it.  Then
you use a heuristic, if available, to update the priming data and
touch it up manually where necessary.  Automate where it helps, not
where it hurts.

  It's rather embarassing to know that Debian isn't organized at all in this
  manner.

Organization is overrated.  While good code is, in the long run, an
aesthetic criterion as much as anything else, some aesthetic instincts
can be misleading.  Cathedral / bazaar, and all that.  (Though I
personally prefer cathedrals, and if you've read about how they were
actually built, you will see that the Linux, glibc, GCC, perl, python,
etc. development process looks much more like cathedral building than
like the Kasbah.)

 You seem to be embarrassed easily.  If this is such a problem for using
 Debian as a development platform, why is this the first time I've seen the
 subject discussed on debian-devel?

There may well be useful tools that are made harder to write by the
indiscriminate naming of packages.  For an example where the global
aesthetic criterion does tend to win, at the expense of some use
cases, consider the prejudice against splitting off micro-packages
to slim down the dependencies of the main binary package.  tetex-bin
comes to mind -- and don't tell me that tetex-base is the main
package, because it's tetex-bin that is needed when building X11 (last
time I checked; still true of xfree86 in unstable; apparently also
true of xorg).

Perhaps it's not worth splitting out xpdf as a separate source package
to break the circular build-depends -- although it would avoid
gratuitous security updates to the rest of tetex.  But I for one
really don't like having to have the binary packages from an old
xfree86 build installed in order to do a new build.  Yeah, you can
build your own tetex-bin with xpdf excluded, or just force-install
tetex-bin without the X libs in a chroot -- but it's ugly.

I know that the package count is getting to be a scalability problem
and that people are working on ways of dealing with that, and in the
meantime there is some rational pressure not to split packages
needlessly.  I'm not blaming the TeTeX team for weighing the factors
and deciding not to split.  I'm just giving an example of a warning
sign that too many meanings are being overloaded onto one technical
distinction -- in this case, the boundaries of a .deb.  Another
example would be localization packages; I hope I don't need to spell
that one out.

 I'm not convinced that the problem you're trying to solve is of sufficiently
 general interest to outweigh all of the other problems it introduces (such
 as the ones that have been pointed out in this thread).

IMHO the problem is real, the solution is wrong.  Don't try to
organize the underlying data; add enough metadata markup that you can
present better organized views for various purposes.  Don't rush to
add that metadata to debian/control; sketch out a heuristic using
existing metadata that leaves you with a relatively small number of
manual overrides, write real applications that use it, and then decide
if it's OK to keep the manual overrides as detached metadata or if
they belong in debian/control.

Cheers,
- Michael

unsubscribe

2005-07-15 Thread Matthew D. Melbert





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

Re: API/ABI in -dev package name?

2005-07-15 Thread Philipp Kern

On Fri, 2005-07-15 at 09:14 -0700, Steve Langasek wrote:
 Not consistently.  Indeed, I've never heard of such a practice; can you give
 an example?

Well in fact I saw quite some projects doing it that way and found it to
be the cleanest. gtk(mm) and glib(mm) come to my mind if I recall it
correctly. They change -release as soon as the API breaks.

Kind regards,
Philipp Kern



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

Bug#318494: ITP: ieee80211-source -- Source for the 802.11 (wireless) network stack for Linux

2005-07-15 Thread Mike Hommey

Package: wnpp
Severity: wishlist
Owner: Mike Hommey [EMAIL PROTECTED]

* Package name: ieee80211-source
  Version : 1.0.3
  Upstream Author : James P. Ketrenos [EMAIL PROTECTED]
* URL : http://ieee80211.sf.net/
* License : GPL v2
  Description : Source for the 802.11 (wireless) network stack for Linux

 This package provides the source code for the 802.11 (wireless) network
 stack module for the Linux kernel. Though it has been incorporated in
 latest kernel versions, the bundled one might not be up-to-date to build
 third-party wireless modules such as ipw2100 or ipw2200 which are common
 on Centrino notebooks.
 .
 In order to compile these modules you need the kernel sources (or the
 kernel-headers for the kernel-image packages from Debian). For compile
 instructions look into /usr/share/doc/ieee80211-source/README.Debian or
 simply use the module-assistant utility.
 .
 The project's homepage can be found here:
 http://ieee80211.sourceforge.net

Note : I haven't found a clean solution to deal with the include files
that are needed by the ipw2?00-source packages.

Mike


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

I'm easy lets hook up

2005-07-15 Thread admit Kern

Are you sick and tired of your girlfriend, wife, or spouse? 
Does their voice sound like chalk squealing on a chalkboard
Then you need to look at the best hook up site on the www
You will get a date tonight. Its that easy to hook up.
Some want love and some just want the casual one time bm bom

http://funtimedate.com/aac/aacm.html

You deserve to enjoy yourself today




nomore of this
http://funtimedate.com/rr2.html






The boy said boathouse crumble ratio cavern.
Girls can be ambrosial rudy spokesman f's For every 
The boys are fun bleary canker [EMAIL PROTECTED] baccalaureateinternal 
conservative.
Stables can be bradshaw infix siesta blacksmithneolithic Well then, muggy 
verity geranium.
Can you say ulysses rebellion krebs connoisseurcornealigature the table .

D0wlnoadable 70+ XXX V1deos with P0RNSTARS - X67

2005-07-15 Thread Susanna Pittman



We have the hottest Pornostars pics and videos inside.
Thousands of new photo and clips, including Pornostars movies. See hot 
Pornostars videos now!
Click here for http://aquarium.biz.wallkbaby.info/ cool photos and video clips 
and dvd movies





--
accra bainite candlewick armonk
capo discomfit crown barclay
browse bissau bet boycott



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

Re: Gradual mass bug filing for C++ transition / gcc-4.0 issues

2005-07-15 Thread Aurelien Jarno

On Fri, Jul 15, 2005 at 11:00:08AM -0700, Daniel Schepler wrote:
 package transitioned, whichever is longer.  Right now I have my eyes
 on jade/opensp/openjade, and possibly db*.

I have already NMUed opensp, but it is still in incoming because of the
new libosp4c2 package.

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian GNU/Linux developer | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

The leading Internet job site pontoon of Australia www.seek.com.au presents unique part-time job proposal from International tour agency Travel Tour Guide. That job position was called "Job of The Year-2004" and it is actual now because of hot summer and best prices for Travel Tour Guide prop casualize osals in Internet.
Do you want to start a successful carrier right now without any entrance fees, without buying goods or involving other people? Do you want to start a successful car fashioner rier in financial sphere without economical education or special experience? - So this is a chance for you.

Travel Tour Guide is happy offering you to apply for one of the passengerpigeon open financial manager positions. This is a unique proposal because while examining you as applicant only your criminal records and credit history will be looked through. All we demand from you is to check your e-mail several times a day and to have a valid bank account or to open a new one.

The main option of financial manager's job is dollar to receive funds on personal bank account with future remittance to Travel Tour Guide. Manager gets 5% from every remittance. So every financial manager of Travel Tour Guide has an opportunity of getting 800-900 AUD per week.

Travel Tour Guide resumed that position because of regular bank wires last for 3-5 days. Such long inconsiderable period prevents us from selling hot tours. Besides the world leading payment systems like Visa and MasterCard decreased the limits for Internet payments. The activity of financial managers in various regions became a rescue for wide range of on-line companies which sells good up to bank limits.

Travel Tour Guide has already got the network of financial managers working wor rescue ldwide. We have got a high demand this summer in Australia so our managers can not process all the transactions in time. So company resumed that vacancy in Australia. Please forward your letter to[EMAIL PROTECTED] and you will be sent the detailed job description and also you can ask for application form.

If you are not interested in this job offer you can kingship visit www.seek.com.au. A lot of vacancies from more than 75000 employers can be found orangery there.

Re: congratulations to the X team!!

2005-07-15 Thread Andreas Metzler

David Nusinow [EMAIL PROTECTED] wrote:
 On Fri, Jul 15, 2005 at 10:59:21AM -0700, Steve Langasek wrote:
[...] 
 Why do people think that xorg broke library dependencies for our
 entertainment, and that patching over the dependencies is an ok solution?
 The package name changed because it is *not* *compatible*.  No one said the
 C++ transition was supposed to be fun, did they?

 I'm mainly depressed that people aren't reading Planet Debian, or are just
 ignoring it. Is there a better place to post this sort of thing so that
 users don't keep repeating the same non-bug? The BTS obviously isn't
 working for us here either, nor is posting to debian-x.
 
 I think I'll have to put something in X.Org's NEWS.Debian about it at the
 very least, but if anyone has any ideas for this, I'm all ears. I refuse to
 resort to a debconf warning for this, but I'm running out of ideas.

Hello,
I think you'll just need to accept that out of n users at least n/50
will not read wherever you put it and a (small) percentage of these will
pester you about it.

There is nothing to do about this except for writing a canned response
_once_ and resending it when necessary.
cu and-  thanks, BTW -reas


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

Re: Gradual mass bug filing for C++ transition / gcc-4.0 issues

2005-07-15 Thread Daniel Schepler

Aurelien Jarno [EMAIL PROTECTED] writes:

 On Fri, Jul 15, 2005 at 11:00:08AM -0700, Daniel Schepler wrote:
 package transitioned, whichever is longer.  Right now I have my eyes
 on jade/opensp/openjade, and possibly db*.

 I have already NMUed opensp, but it is still in incoming because of the
 new libosp4c2 package.

All right, I guess I should have checked that first.  Anyway, jade is
now in DELAYED/2-day/.
-- 
Daniel Schepler  Please don't disillusion me.  I
[EMAIL PROTECTED]haven't had breakfast yet.
 -- Orson Scott Card


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

Re: Gradual mass bug filing for C++ transition / gcc-4.0 issues

2005-07-15 Thread Philipp Kern

On Fri, 2005-07-15 at 11:00 -0700, Daniel Schepler wrote:
 I might also do NMU's for some of the more important packages, with a
 delay of 2 days, or 5 days minus the time since the last dependent
 package transitioned, whichever is longer.  Right now I have my eyes
 on jade/opensp/openjade, and possibly db*.

I am currently working on getting Bradley Bell's C++ packages
transitioned. These include[1] the following:
gconfmm*, glademm*, glibmm*, gnome-vfsmm*, gnomemm*, gtkmm* and several
other *mm* libs.

On some I am waiting for the dependencies. But please contact Bradley
and me if you intend to NMU any of these.

Kind regards,
Philipp Kern
Debian Developer

[1] The complete list: http://qa.debian.org/developer.php?login=btb



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

Re: cpufrequtils init script in rcS.d

2005-07-15 Thread Bernd Eckenfels

In article [EMAIL PROTECTED] you wrote:
 Sorry. The main idea is making power management more effective, that's
 why earlier is better here.

I dont see why this is the case. in the bootup phase the  system is loaded
anyway, no need to throttle it. especially since this one minute does not
consume measurable amount of power. So there is still ne real reason
mentioned why a few seconds matter here. i could think of a few daemons
which do a benchmark loop on startup, howeer those are broken by design on
modern hardware anyway.

Gruss
Bernd


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

Re: unreproducable bugs

2005-07-15 Thread Steve Greenland

On 15-Jul-05, 11:12 (CDT), Manoj Srivastava [EMAIL PROTECTED] wrote: 
 What's with the recent push to get every little things written
  down into policy, so the developer no longer is required to have an
  ability to think, or exercise any judgement whatsoever?


Probably the growing number of users and other maintainers who argue,
re-open bugs, etc. etc. etc. unless you can prove that your judgement is
enshrined in policy.

Or maybe I'm just getting cynical.

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: unreproducable bugs

2005-07-15 Thread Rich Walker

Michael K. Edwards [EMAIL PROTECTED] writes:

 On 7/15/05, Manoj Srivastava va, manoj [EMAIL PROTECTED] wrote:
 What's with the recent push to get every little things written
  down into policy, so the developer no longer is required to have an
  ability to think, or exercise any judgement whatsoever?

 Welcome to the software industry in 2005.  

[snip]


Yes, to rely on 1300 developers to all think of your cunning method of
solving a problem clearly makes sense. After all, to *write down* a
technique that solves the problem, and make it available to all of them
would stilt their creativity, hinder their intellect, and prevent the
development of a consistent style!

Sheesh, next you'll be arguing in favour of personal indentation styles!

cheers, Rich.


-- 
rich walker |  Shadow Robot Company | [EMAIL PROTECTED]
technical director 251 Liverpool Road   |
need a Hand?   London  N1 1LX   | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml


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

Re: unreproducable bugs

On 7/15/05, Rich Walker [EMAIL PROTECTED] wrote:
 Michael K. Edwards [EMAIL PROTECTED] writes:
  On 7/15/05, Manoj Srivastava va, manoj [EMAIL PROTECTED] wrote:
  What's with the recent push to get every little things written
   down into policy, so the developer no longer is required to have an
   ability to think, or exercise any judgement whatsoever?
 
  Welcome to the software industry in 2005.
 
 Yes, to rely on 1300 developers to all think of your cunning method of
 solving a problem clearly makes sense. After all, to *write down* a
 technique that solves the problem, and make it available to all of them
 would stilt their creativity, hinder their intellect, and prevent the
 development of a consistent style!

I am having a hard time reading this as anything but a non sequitur. 
Personally, I prefer for a solution to be demonstrated to work, both
socially and technically, before it is enshrined in policy.  Drafts
are, of course, welcome at any stage.  Rough consensus and running
code.  YMMV.

 Sheesh, next you'll be arguing in favour of personal indentation styles!

Well, yes -- as long as the indent / emacs-mode / vim-mode
incantations that reproduce them are well documented, preferably in a
magic comment at the end of each file.  :-)

Cheers,
- Michael

hidden camera in college bathroom Tamra

2005-07-15 Thread Marietta

Do you want to see real amateurs who have webcams 
on their computers in their dorm rooms? This is 
not one of those sites with professional girls who 
get paid to do this in front of the camera, these 
are the average girls next door, at college, trying 
to make money and meet guys!

Get free access to a huge database of hot college girls, 
unlimited cam shows with LIVE CHAT and there are no 
Pay-Per-Minute charges!

http://stankfinger.com/co25/










dubious you claimant me cavemen you thus me outlawry you crockery me 
critic you salmon me wealth you desk me 


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

Re: Here is the document

2005-07-15 Thread ting . yang

Here is the file.

--- Trend GateLock 病毒防護通知 (主機：higp2.gatelock.com.tw)

** 中毒檔案 document_full.pif 已刪除。

 Trend GateLock 病毒防護通知 (主機：higp2.gatelock.com.tw)

** 在檔案 document_full.pif 中發現病毒 WORM_NETSKY.D。
無法清除病毒，中毒檔案已刪除。

-

Re: unreproducable bugs

2005-07-15 Thread Rich Walker

Michael K. Edwards [EMAIL PROTECTED] writes:

 On 7/15/05, Rich Walker [EMAIL PROTECTED] wrote:
 Michael K. Edwards [EMAIL PROTECTED] writes:
  On 7/15/05, Manoj Srivastava va, manoj [EMAIL PROTECTED] wrote:
  What's with the recent push to get every little things written
   down into policy, so the developer no longer is required to have an
   ability to think, or exercise any judgement whatsoever?
 
  Welcome to the software industry in 2005.
 
 Yes, to rely on 1300 developers to all think of your cunning method of
 solving a problem clearly makes sense. After all, to *write down* a
 technique that solves the problem, and make it available to all of them
 would stilt their creativity, hinder their intellect, and prevent the
 development of a consistent style!

 I am having a hard time reading this as anything but a non sequitur. 

Umm; it follows more from Manoj's comment than yours.

 Personally, I prefer for a solution to be demonstrated to work, both
 socially and technically, before it is enshrined in policy.  Drafts
 are, of course, welcome at any stage.  Rough consensus and running
 code.  YMMV.

You scale an organisation, I understand, by removing the *need* for
everyone in it to be a genius at everything it does.

Hence the comment about the US army: designed by genius to be run by
sergeants.

There does seem to be a lot of discussion on the debian groups about
policy. If Debian is lucky, or well-managed, then it is the process you
are describing. If it is unlucky, then it is a bunch of rule-lawyers
having fun.



 Sheesh, next you'll be arguing in favour of personal indentation styles!

 Well, yes -- as long as the indent / emacs-mode / vim-mode
 incantations that reproduce them are well documented, preferably in a
 magic comment at the end of each file.  :-)

Exactly: that and an indent script in the checkin routine remove any
issue.

See how that compares to policy, which is hopefully implemented in such
a way as to be mechanically testable?

cheers, Rich.


 Cheers,
 - Michael


-- 
rich walker |  Shadow Robot Company | [EMAIL PROTECTED]
technical director 251 Liverpool Road   |
need a Hand?   London  N1 1LX   | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml


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

Re: unreproducable bugs

On 7/15/05, Rich Walker [EMAIL PROTECTED] wrote:
  I am having a hard time reading this as anything but a non sequitur.
 
 Umm; it follows more from Manoj's comment than yours.

Ah.  OK.

  Personally, I prefer for a solution to be demonstrated to work, both
  socially and technically, before it is enshrined in policy.  Drafts
  are, of course, welcome at any stage.  Rough consensus and running
  code.  YMMV.
 
 You scale an organisation, I understand, by removing the *need* for
 everyone in it to be a genius at everything it does.

Bingo!  You also take care not to formalize unduly, or you get a
sclerotic bureaucracy.

 Hence the comment about the US army: designed by genius to be run by
 sergeants.

As a close associate of several sergeants in the US Army, I question
only the designed by genius part.  Given what armies do for a
living, Darwinian selection is probably also a factor.  :-)

 There does seem to be a lot of discussion on the debian groups about
 policy. If Debian is lucky, or well-managed, then it is the process you
 are describing. If it is unlucky, then it is a bunch of rule-lawyers
 having fun.

Don't knock rule-lawyers, just ignore them until they produce
something you can tolerate.  And keep your eyes open for things that
you don't want to agree with but that happen to reflect a real-world
truth of which you were previously unaware.  Kinda like real lawyers,
actually.

  Well, yes -- as long as the indent / emacs-mode / vim-mode
  incantations that reproduce them are well documented, preferably in a
  magic comment at the end of each file.  :-)
 
 Exactly: that and an indent script in the checkin routine remove any
 issue.

As long as it's purely advisory, please -- no tool is perfect
(although TeX is damn close).

 See how that compares to policy, which is hopefully implemented in such
 a way as to be mechanically testable?

To within certain limits, as demonstrated by lintian and linda -- up
there with dpkg and debhelper in the pantheon of Debian's
contributions to the world.  Not quite on par with the DFSG, but
that's only to be expected; the DFSG is not intended to be testable by
a machine that is less than Turing-complete.  :-)

Cheers,
- Michael

Re: unreproducable bugs

2005-07-15 Thread Rich Walker

Michael K. Edwards [EMAIL PROTECTED] writes:

 On 7/15/05, Rich Walker [EMAIL PROTECTED] wrote:
  I am having a hard time reading this as anything but a non sequitur.
 
 Umm; it follows more from Manoj's comment than yours.

 Ah.  OK.

Should have sent two postings :-

  Personally, I prefer for a solution to be demonstrated to work, both
  socially and technically, before it is enshrined in policy.  Drafts
  are, of course, welcome at any stage.  Rough consensus and running
  code.  YMMV.
 
 You scale an organisation, I understand, by removing the *need* for
 everyone in it to be a genius at everything it does.

 Bingo!  You also take care not to formalize unduly, or you get a
 sclerotic bureaucracy.

Given the difficulty of getting agreement in this place, I think that
unlikely.

(As a practicing SubGenius, I like to think of the ornery, cussing
Debian, up there with the Two-Fisted Jesus, and the Butting
Buddha. Others may have other views)


 Hence the comment about the US army: designed by genius to be run by
 sergeants.

 As a close associate of several sergeants in the US Army, I question
 only the designed by genius part.  Given what armies do for a
 living, Darwinian selection is probably also a factor.  :-)

Helps. The British Army likes to send officers out in front - produces
lots of dead heroes in the upper classes, as well as reducing incidence
of fragging...

By the way, a spot of Google produces:

Child (1984) cited A machine designed by geniuses to be run by idiots,
Herman Wouk, The Caine Mutiny, on the organization of the wartime US
Navy.

[snip sane remarks]
 
 Exactly: that and an indent script in the checkin routine remove any
 issue.

 As long as it's purely advisory, please -- no tool is perfect
 (although TeX is damn close).

 See how that compares to policy, which is hopefully implemented in such
 a way as to be mechanically testable?

 To within certain limits, as demonstrated by lintian and linda -- up
 there with dpkg and debhelper in the pantheon of Debian's
 contributions to the world.  Not quite on par with the DFSG, but
 that's only to be expected; the DFSG is not intended to be testable by
 a machine that is less than Turing-complete.  :-)


I get asked from time to time by academics for interesting projects for
their students. I think I now have another:

Implement a system capable of using standard AI techniques to process
the (a) existing judgements and (b) content of debian.legal such that it
can issue plausible analysis of a new software license...

cheers, Rich.


 Cheers,
 - Michael


-- 
rich walker |  Shadow Robot Company | [EMAIL PROTECTED]
technical director 251 Liverpool Road   |
need a Hand?   London  N1 1LX   | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml


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

Re: unreproducable bugs