Re:[9] Debian Devel

[Yudale]

  Regain your confidence with the best generic viagra from a licensed manufacturer
  It is only one click away

  

Re: unreproducable bugs

[Michael K. Edwards]

On 7/15/05, Manoj Srivastava va, manoj <[EMAIL PROTECTED]> wrote:
[cranky but funny stuff]

If there ever is a blackball commitee, Manoj of all people belongs on it.  :-)

Cheers,
- Michael

jiri away from mail

[jiri kuthan]

I'm out of office.

If you have any urgent questions to iptelorg, call me or contact my 
colleague, Dr. Sisalem, [EMAIL PROTECTED]

-Jiri


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

Re: unreproducable bugs

[Manoj Srivastava]

On Sat, 16 Jul 2005 01:43:46 +0100, Rich Walker <[EMAIL PROTECTED]> said: 

> 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".


Ah yes. How does one handle long open unreproducible bugs
 after a few releases -- the work requiring genius.

Who am I to stand in the way of changing times? Since I have
 been around longer than most people in Debian, here is  my terribly
 clever best practice for a critical process that debian developers
 are supposed to practice frequently -- very frequently (the
 recommended rate is about 15-20 repetitions per minute), namely,
 breathing.

That this is a critical process is clearly demonstrable, and
 that there needs to be strict guidelines on the rate at which it is
 practiced is also of prime importance. Raising the rate too high
 results in a deprecated condition called "hyper ventilating". The
 side effects can be light headedness -- consider the harm if the
 entire project failed to follow the guidelines.

The effects on the project can be even more pronounced if a
 majority of the developers were so lax as to  not practice this
 activity for even as short an interval as, say, 5 to 10 minutes. The
 effects would be felt even more in small teams, like, say, security,
 or ftp-masters, if they grow this lax.

So, having given the rationale for the importance of this best
 practices document snippet, allow me to present the best practice
 itself: (details in
 http://www.mtsu.edu/~jshardo/bly2020/respiratory/ventilation.html) 

At the start of the cycle, remember to relax the Dome-shaped
 skeletal muscle that forms floor of thoracic cavity.   Diaphragm
 relaxes & shortens pleural cavities, thus decreasing intrathoracic
 volume. Lungs elastically recoil, chest wall & abdominal organs help
 compress lungs, increasing alveolar pressure & air flows out.
 External intercostals relax, ribs & sternum move downward & inward,
 decreases anterior-posterior diameter. Air flows out.  This is
 a Passive process.

Hold for a short time. Due to the recomeded period of this
 activity, it is not recommended that you hold for more than a second
 or so.

 Contraction of diaphragm causes it to flatten &  lengthen the
 pleural cavities, thus increasing intrathoracic volume. Lungs expand,
 decreasing alveolar pressure within lungs & atmospheric air flows
 in. Contraction of external intercostal muscles pull ribs & sternum
 upward & outward, increases anterior-posterior thoracic diameter by
 20%. Air flows in.  This is the active part of the process.

It is imperative that Debian developers remember to invoke
 this active process several times a minute. Laxity in this can
 severely hurt the project.

Indeed, failure to follow this policy may result in an RC bug
 or orphaning of all the packages held by the lax developer.

manoj
-- 
Just remember: when you go to court, you are trusting your fate to
twelve people that weren't smart enough to get out of jury duty!
Manoj Srivastava   <[EMAIL PROTECTED]>  
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]

Gratis acceda a muchos beneficios

[Judith Simone]

[EMAIL PROTECTED]


Cuide a su familia16418





 

Cancelar Newsletter53262






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

Quality Loans made simple

[Jodie Cortez]

THIS IS GOING TO BE OUR ABSOLUTE ATTEMPT

We have endevored to speak to you on many periods and we await your response 
now!

Your current finanncial loann situation meets the requirements for you for up 
to a 3.2 % lower rate.

However, based on the fact that our previous attempts to speak to you didn't 
work,
this will be our final attempt to finalize the lower ratee.

Please finalize this final step upon receiving this notice immediately,and 
complete your request for information now.

Submission Here.

http://ADN.Debian-debbugs-cvs-request.2005loans.com/2/index/sto/MTq



like highway to hell, full of ditches. I was trying my best to drive carefully 
so that Mia doesn't get hurt, but it was all in vain. All those bumps and jumps 
and Mia was in sheer pain. I would look at the road for one moment and would 
turn to Mia the next. I was continuously consoling her but I knew words would 
do no good. I never felt so


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

Penis Growth Extreme

[Meg]

Achieve stronger and harder erections
http://www.xunepa.com/ss/





The very essence of love is uncertainty.  
By failing to prepare, you are preparing to fail.
Divine Love always has met and always will meet every human need. 
There's a divinity that shapes our ends, Rough-hew them how we will. 
I understand a fury in your words,But not the words.   




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

Re: unreproducable bugs

[Manoj Srivastava]

On Sat, 16 Jul 2005 01:14:07 +0100, Rich Walker <[EMAIL PROTECTED]> said: 

> "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.

Good god. If anyone thinks that handling a long open
 unreproducible problem in the ways mentions is "cunning method", I
 think they better look at a nice long apprenticeship before aspiring
 to be a DD.

> 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!

If we have to create a written document to spoon feed people
 solutions to trivial problems,  the project is doomed anyway, and
 nothing really matters.

manoj
 who can't believe we have sunk this low
-- 
Reality is bad enough, why should I tell the truth? Patrick Sky
Manoj Srivastava   <[EMAIL PROTECTED]>  
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]

Re: unreproducable bugs

[Michael K. Edwards]

On 7/15/05, Rich Walker <[EMAIL PROTECTED]> wrote:
> (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)

As a practicing Episcopatheist, I like to murmur, "There is no God,
and debian-legal is her Prophet."  >;->

> 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...

Yes, indeed.  Dead heroes are the safe kind, from a political point of
view.  The US, with a little help from its foes, is currently engaged
in producing an alarming number of one of the unsafe kinds: living but
multiply amputated and/or addled by massive brain trauma.

Ooh -- I didn't notice your .sig before I wrote that.  Synchronicity?  :-/

> 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.

I do like a man who cites his sources.

> 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...

Plausible?  No problem -- in the trade we call that a "pseudo-random
number generator".  Hard to implement without infringing some patent
the USPTO issued last week, though ...

Cheers,
- Michael

Re: unreproducable bugs

[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

[Michael K. Edwards]

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

[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: Here is the document

[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。
無法清除病毒，中毒檔案已刪除。

-

hidden camera in college bathroom Tamra

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

[Michael K. Edwards]

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

Re: unreproducable bugs

[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

[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: cpufrequtils init script in rcS.d

[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: Gradual mass bug filing for C++ transition / gcc-4.0 issues

[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: Gradual mass bug filing for C++ transition / gcc-4.0 issues

[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: congratulations to the X team!!

[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]

Job in Financiial Sphere

[Mattie Miles]

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: Gradual mass bug filing for C++ transition / gcc-4.0 issues

[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]

D0wlnoadable 70+ XXX V1deos with P0RNSTARS - X67

[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]

I'm easy lets hook up

[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 .

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

[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]

Re: API/ABI in -dev package name?

[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]

unsubscribe

[Matthew D. Melbert]

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

Re: shared library -dev package naming proposal

[Michael K. Edwards]

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

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

[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: congratulations to the X team!!

[Steve Langasek]

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

[Michael K. Edwards]

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

[Nico Golde]

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: congratulations to the X team!!

[David Nusinow]

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

[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

Seeking co-maintainer for adduser

[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: congratulations to the X team!!

[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]

Re: congratulations to the X team!!

[David Nusinow]

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!!

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

[Nico Golde]

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!!

[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: congratulations to the X team!!

[David Nusinow]

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]

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

[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 ).

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!!

[Steve Langasek]

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

Re: unreproducable bugs

[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!!

[David Nusinow]

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]

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

[Miguel Gea Milvaques]

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

* Package name: moto4lin
  Version : 0.3
  Upstream Author : Dmitry Nezhevenko 
* 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!!

[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]

Re: congratulations to the X team!!

[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]

Trusted savings on prescription drugs.

[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]

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

[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]

Re: unreproducable bugs

[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]>  
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]

Re: API/ABI in -dev package name?

[Steve Langasek]

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: congratulations to the X team!!

[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: shared library -dev package naming proposal

[Steve Langasek]

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: Build-Depends: libfoo-dev more susceptible to breaking (Re: shared library -dev package naming proposal)

[Steve Langasek]

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

[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: API/ABI in -dev package name?

[Stephen Frost]

* 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: skills of developers

[Eduard Bloch]

#include 
* 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.

-- 
 schoos: Für was ist denn Pascal besser geeignet als andere oder Scheme?
 mrvn: Pascal? Für das Verständnis von Wirths Büchern
 Dafür gibts doch Oberon
 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: unreproducable bugs

[Nico Golde]

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

[Junichi Uekawa]

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: shared library -dev package naming proposal

[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: API/ABI in -dev package name?

[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

[Junichi Uekawa]

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

API/ABI in -dev package name?

[Junichi Uekawa]

> > > > 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]

unreproducable bugs

[Nico Golde]

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]

Re: shared library -dev package naming proposal

[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]

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

[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
libB-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: Updating dpkg-cross: file moving question

[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: Updating dpkg-cross: file moving question

[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-
- when xxx deepnds on yyy, dpkg-cross will generate
 Depends: yyy-arch-cross, yyy-arch-cross-
- when xxx depends on yyy (>= n), dpkg-cross will generate
 Depends: yyy-arch-cross (>= n), yyy-arch-cross-

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: cpufrequtils init script in rcS.d

[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: aspell dictionary packages fail to build

[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: interacting with the press

[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]:  > > > 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: shared library -dev package naming proposal

[Stephen Frost]

* 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: shared library -dev package naming proposal

[Stephen Frost]

* 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: Build-Depends: libfoo-dev more susceptible to breaking (Re: shared library -dev package naming proposal)

[Stephen Frost]

* 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

[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: cpufrequtils init script in rcS.d

[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: skills of developers

[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: shared library -dev package naming proposal

[Junichi Uekawa]

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: shared library -dev package naming proposal

[Junichi Uekawa]

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]

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

[Junichi Uekawa]

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: aspell dictionary packages fail to build

[Junichi Uekawa]

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]

Re: pbuilder status update

[Junichi Uekawa]

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: cpufrequtils init script in rcS.d

[Nico Golde]

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: interacting with the press

[Nigel Jones]

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]:  > > 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 ,)

> 
> - Matt
> 
> 
> BodyID:41067834.2.n.logpart (stored separately)
> 
> 


-- 
N Jones
Blogging @ http://nigelj.blogspot.com
Proud Debian & FOSS User
Debian Maintainer of: html2ps & ipkungfu

Bug#318388: ITP: fortranposix -- library of POSIX functions for Fortran 90/95 programmers

[Kamaraju Kusumanchi]

Package: wnpp
Severity: wishlist
Owner: Kamaraju Kusumanchi <[EMAIL PROTECTED]>


* Package name: fortranposix
  Version : 0.1
  Upstream Author : Madhusudan Singh 
* URL : http://sourceforge.net/projects/fortranposix
* License : LGPL
  Description : library of POSIX functions for Fortran 90/95 programmers

 This is an implementation of some POSIX functions in Fortran 90/95. It is not
 yet complete. It is needed for gnuplotfortran which in turn is useful to call
 gnuplot from Fortran 90/95 programs.
 .
 Using this library you can find PWD, find hostname, open and close pipes,
 create/change/remove directories, obtain PID etc., from Fortran 90/95 programs.
 .
 gnuplotfortran is available at http://sourceforge.net/projects/gnuplotfortran
 I will be filing a separate ITP for gnuplotfortran after this.


-- 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.9-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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