Re: Bug#423911: ITP: citadel -- Citadel.org is an highly integrated Groupware Platform with a Web 2.0 enabled Webinterface, but also providing SMTP, IMAP, POP3 and GroupDAV access to its content.

[Philipp Matthias Hahn]

Hello!

On Tue, May 15, 2007 at 12:09:30AM +0100, Stephen Gran wrote:
> This one time, at band camp, Wilfried Goesgens said:
> > 
> > * Package name: citadel
...
> However, I have one question that has made me leery of it
> so far: does it really need it's own implementation of all of those
> protocols?

AFAIK yes, since that is Citatels benefit: It gives access to the same
data by different protocols; no nightmare because of inconsistent data
between all those parts.

> Can't it use existing, well tested, pop/imap/smtp servers?

No. And that's why I didn't pick it for production, since I didn't want
to replace my working Postfix + Cyrus-IMAP setup.

BYtE
Philipp
-- 
Philipp Matthias Hahn <[EMAIL PROTECTED]>
 GPG/PGP: 9A540E39 @ keyrings.debian.org


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

Re: Debian desktop -situation, proposals for discussion and change. Users point of view.

[Mgr. Peter Tuharsky]

Hi,


Ad backports importance,

I know there is backports.org -however this, and the testing, unstable, 
stable, volatile, experimental.. So many package versions, so much 
duplicate work.. Other hand, there's nothing "official" and 
"recommended" excepting the stable. Using anything else, You're on Your 
own..


I think, any new stable version of the desktop software should be 
automaticaly added to security updates and distributed to end user. 
There's no need to test the tested and stabilise the stable software. 
Should the new stable version be broken, let's give the user easy way to 
downgrade, and help upstream to fix it fast.


I can agree with You in some point -Yes, compiling against the, let's 
call it "stable base", as I suggested before, could also mean real 
backporting work, especially if the upstream moved to higher libraries 
versions in the middle of Debian's release cycle. That's why i think the 
backport's people are _very_important_ in the proposed scheme.


Moreover, I could suggest the backporting work to be "moved" closer to 
upstream and further from Debian itself. Other distros do lot of 
backport work too, so working together somewhere in the upstream's 
playground could bless all together.



PS. I know the text is long. I can work on bulleted version. Is there 
any interest?


Peter

Petter Reinholdtsen  wrote / napísal(a):

[Peter Tuharsky]

Ask somebody, what distro would he install at desktop for novice or M$
refugee? Why many are choosing Ubuntu instead of Debian, and even
worse, abandon Debian in favor of Ubuntu? Why do most people consider
Debian to be user-unfriendly and server-oriented distro?


Interesting analysis, with several good points on keeping the stable
release working with newer hardware and keeping the software selection
relevant.  But my first impression after reading your long text is
that you are ignoring the work going on at backports.org, and the
ideas that has been floating around on making a Debian release based
on the stable version for the "base" packages, and include upgraded
packages like the kernel, X, Gnome, KDE and other hardware- and
user-interacting packages from backports.org.  You might want to have
a look into those ideas.

I've also seen ideas on making releases based on testing, now that we
have security fixes for the packages in testing.  It could give a
snapshot of internally consistent packages (as opposed to unstable).

Friendly,



--
Odchádzajúca správa neobsahuje ví­rusy, nepou¾í­vam Windows.
===

Mgr. Peter Tuhársky
Referát informatiky
Mesto Banská Bystrica
ÈSA 26
975 39 Banská Bystrica

Tel: +421 48 4330 118
Fax: +421 48 411 3575

===


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

Re: Debian desktop -situation, proposals for discussion and change. Users point of view.

[Mgr. Peter Tuharsky]

The kernel, the X.org

I realise, that the kernel and X.org are somewhat delicate things, 
because they affect both desktop and server. Changing them in the middle 
of release life, might not sound too well.


However, at least by the means of the kernel, the server world also 
needs new hardware support. Putting Debian on the server could get hard 
in the second half of release cycle.


Fortunately, upgrading the kernel dosen't break anything usually, as 
long as there is not some nasty bug in there. I suggest the kernel to 
follow the "stable tree" at kernel.org, with caution of course. If the 
kernel version upgrade was available eq 2 times inside stable release 
life, those willing to upgrade could use it, and those unvilling can 
stay with old version.


The kernel upgrade could fit the "volatile" philosophy IMO.

As of X, it's quite complex, however it's less the server and more the 
desktop thing, that could also get upgraded with some caution. Might 
also be the concern of volatile.


Some server software occasionaly need an upgrade too.

However the ordinary desktop packages, environments and so on could get 
upgraded routinely IMO, with easy downgrade option. No need to do the 
whole stabilisation scrutiny.


If some developer wishes to test the package before putting it to the 
repositories, he can join the upstream's beta testing to help catch the 
bugs before the software is "stabilised upstram".



Peter

Petter Reinholdtsen  wrote / napísal(a):

[Peter Tuharsky]

Ask somebody, what distro would he install at desktop for novice or M$
refugee? Why many are choosing Ubuntu instead of Debian, and even
worse, abandon Debian in favor of Ubuntu? Why do most people consider
Debian to be user-unfriendly and server-oriented distro?


Interesting analysis, with several good points on keeping the stable
release working with newer hardware and keeping the software selection
relevant.  But my first impression after reading your long text is
that you are ignoring the work going on at backports.org, and the
ideas that has been floating around on making a Debian release based
on the stable version for the "base" packages, and include upgraded
packages like the kernel, X, Gnome, KDE and other hardware- and
user-interacting packages from backports.org.  You might want to have
a look into those ideas.

I've also seen ideas on making releases based on testing, now that we
have security fixes for the packages in testing.  It could give a
snapshot of internally consistent packages (as opposed to unstable).

Friendly,



--
Odchádzajúca správa neobsahuje ví­rusy, nepou¾í­vam Windows.
===

Mgr. Peter Tuhársky
Referát informatiky
Mesto Banská Bystrica
ÈSA 26
975 39 Banská Bystrica

Tel: +421 48 4330 118
Fax: +421 48 411 3575

===


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

Re: Debian desktop -situation, proposals for discussion and change. Users point of view.

[Mgr. Peter Tuharsky]

Ad testing,


in my experience, testing is not really good option for real work. There 
are _platform_ changes going in testing, that leads to broken 
dependencies and sometimes completely nonfunctional snapshots.


Therefore, I suggest _the_platform_ (libraries and so on) to remain 
stable, just upgrade the software that runs on top of that. Thus we can 
both avoid broken deps problems, and have new software available.


If You mean to use the software from testing -You must first make it run 
on stable without need for library upgrades. That is more similar to 
backports job, than to testing.


Testing should simply be the place where _platform_ changes are shaken 
out, not the "input buffer for the new software".


Peter


Petter Reinholdtsen  wrote / napísal(a):

[Peter Tuharsky]

Ask somebody, what distro would he install at desktop for novice or M$
refugee? Why many are choosing Ubuntu instead of Debian, and even
worse, abandon Debian in favor of Ubuntu? Why do most people consider
Debian to be user-unfriendly and server-oriented distro?


Interesting analysis, with several good points on keeping the stable
release working with newer hardware and keeping the software selection
relevant.  But my first impression after reading your long text is
that you are ignoring the work going on at backports.org, and the
ideas that has been floating around on making a Debian release based
on the stable version for the "base" packages, and include upgraded
packages like the kernel, X, Gnome, KDE and other hardware- and
user-interacting packages from backports.org.  You might want to have
a look into those ideas.

I've also seen ideas on making releases based on testing, now that we
have security fixes for the packages in testing.  It could give a
snapshot of internally consistent packages (as opposed to unstable).

Friendly,



--
Odchádzajúca správa neobsahuje ví­rusy, nepou¾í­vam Windows.
===

Mgr. Peter Tuhársky
Referát informatiky
Mesto Banská Bystrica
ÈSA 26
975 39 Banská Bystrica

Tel: +421 48 4330 118
Fax: +421 48 411 3575

===


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

Re: Debian desktop -situation, proposals for discussion and change. Users point of view.

[Andreas Tille]

On Tue, 15 May 2007, Mgr. Peter Tuharsky wrote:

I know there is backports.org -however this, and the testing, unstable, 
stable, volatile, experimental.. So many package versions, so much duplicate 
work..


I do not think that the work between the things you mentioned is really
duplicated.

I think, any new stable version of the desktop software should be 
automaticaly added to security updates and distributed to end user.


Uhmm, I think you missed the point about security updates.
I would see an option to make backports more official and perhaps
there is even a slight chance to use autobuilders in some cases
to support backports (better informed people might correct me), 
but the cruxial thing in you sentence is the "I think" part: It

does not only people who have good ideas - we just need people
who do the actual work.  Are you willing to work on the problem
you just uncovered?

There's 
no need to test the tested and stabilise the stable software. Should the new 
stable version be broken, let's give the user easy way to downgrade, and help 
upstream to fix it fast.


This is just a personal point of view.  A complete distribution is
a complex system of several components that interact with each other.
The chances to replace a key component and break something else are
really high.  From a users point of view I would hate if people
call something "stable" and are risking to break my system.

Moreover, I could suggest the backporting work to be "moved" closer to 
upstream and further from Debian itself. Other distros do lot of backport 
work too, so working together somewhere in the upstream's playground could 
bless all together.


I would move it into the other direction:  If you want to make Debian
better for Debian user you have to move backports closer to Debian.
It is absolutely no contradiction to work together with upstream, but
I see no profit for the Debian stable end user here.

Kind regards

  Andreas.

--
http://fam-tille.de


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

Re: Liability protection project - call for participants

[Anthony Towns]

On Mon, May 14, 2007 at 03:51:40PM -0700, Bruce Perens wrote:
> A long time ago we planned for SPI to protect Debian developers from 
> liability connected with their development of Free Software. [...]

(By and large, Bruce is speaking for himself here, and possibly some
of the other founders of SPI; I don't think this has been particularly
widely considered by Debian developers at large)

> Some of us have homes, and other property that we would rather not place 
> at risk of any lawsuit connected with our Free Software activities. The 
> way to do that is to act as a volunteer on the behalf of a non-profit 
> corporation, with the corporation assuming your liability. [...]

> There is a downside. If you work on behalf of such an entity, you would 
> have to agree to act at their direction, which means acting responsbily 
> on their behalf, by not doing stupid stuff that obviously increases the 
> corporation's risk of being sued. This doesn't really have to do with 
> practical software, but with what some consider freedom-of-speech issues 
> like obscentity or hate speech. For that reason, this would be strictly 
> opt-in. It would not be directly associated with SPI or Debian, because 
> we could never get all of the DDs to agree about this, and because SPI 
> owns property that we do not want to expose to liability. Copyrights of 
> software produced would be assigned to a non-profit like FSF or SPI*

Note that in the past Debian developers have had concerns with "acting
at the direction" of others -- such as being told that software like
"bitchx", "satan", "mencal" or "hot-babe" aren't appropriate to package
as part of Debian for various reasons; or having board members (such as
SPI's or the FSF's) dictating development decisions to people working
on the code, or changing licenses on them or otherwise becoming more
"involved" than you might have expected.

That said, giving up a little autonomy in exchange for potentially a
lot of financial security is an entirely sensible tradeoff to consider,
and it makes a lot of sense to do that before people start getting
sued individually.

It might be possible to do something like have SPI get copyright
assignment for works in return for providing the authors with a vote (or
a voice) on how they handle that copyright in future, which might ease
the concerns about handing over control and could even be argued to be a
"work for hire" arrangement making it a bit easier to deal with legally.

> I am asking for current free software authors in the United States who 
> would be interested in being protected from liability, and would join me 
> in a request to the Software Freedom Law Center to assist us by creating 
> such an entity. If you would like to do that, please reply to me at 
> [EMAIL PROTECTED] . Further discussion will be carried out separately 
> from SPI and Debian lists.

I think it would be reasonable for SPI to recommend its members seriously
consider such an arrangement (presuming it's possible, pending legal
advice, etc), and I'd hope such discussion would take place on SPI and
Debian lists...

Cheers,
aj



signature.asc
Description: Digital signature

Re: Debian desktop -situation, proposals for discussion and change. Users point of view.

[Mgr. Peter Tuharsky]

Andreas Tille  wrote / napísal(a):

On Tue, 15 May 2007, Mgr. Peter Tuharsky wrote:

I know there is backports.org -however this, and the testing, 
unstable, stable, volatile, experimental.. So many package versions, 
so much duplicate work..


I do not think that the work between the things you mentioned is really
duplicated.


In order of "rapid upstream versions inclusion", they partially would be.



I think, any new stable version of the desktop software should be 
automaticaly added to security updates and distributed to end user.


Uhmm, I think you missed the point about security updates.
I would see an option to make backports more official and perhaps
there is even a slight chance to use autobuilders in some cases
to support backports (better informed people might correct me), but the 
cruxial thing in you sentence is the "I think" part: It

does not only people who have good ideas - we just need people
who do the actual work.  Are you willing to work on the problem
you just uncovered?


Do You think, that
-compiling new upstream version of software against stable platform, 
building a package and distributing it

-needs more effort than
-studying security fixes in upstream, backporting them to ancient 
version of software (if it's barely possible), compiling it against 
stable platform, building a package and distributing it?




There's no need to test the tested and stabilise the stable software. 
Should the new stable version be broken, let's give the user easy way 
to downgrade, and help upstream to fix it fast.


This is just a personal point of view.  A complete distribution is
a complex system of several components that interact with each other.
The chances to replace a key component and break something else are
really high.  From a users point of view I would hate if people
call something "stable" and are risking to break my system.


You're right, I would hate the breakage too, however today's security 
patches occassionally do the same.


Not much desktop software is really such inter-complex-connected that 
upgrading version of single software breaks something else. I have 
routinely used main desktop software's installations from upstream in 
Debian stable and they have broken _nothing_ for me, being totally 
out-of-distro packages or compiled from source. I don't see real danger 
here as long as we can guarentee stable platform that the software would 
be compiled against.


If developer wishes to test the software before including it to 
repositories, he can join the upstream's beta testing cycle and help 
shake the bugs _before_ the software is "stabilised upstream". That's 
how the software cycle is meant like.



Thank You for Your reply

Peter


Moreover, I could suggest the backporting work to be "moved" closer to 
upstream and further from Debian itself. Other distros do lot of 
backport work too, so working together somewhere in the upstream's 
playground could bless all together.


I would move it into the other direction:  If you want to make Debian
better for Debian user you have to move backports closer to Debian.
It is absolutely no contradiction to work together with upstream, but
I see no profit for the Debian stable end user here.

Kind regards

  Andreas.




--
Odchádzajúca správa neobsahuje ví­rusy, nepou¾í­vam Windows.
===

Mgr. Peter Tuhársky
Referát informatiky
Mesto Banská Bystrica
ÈSA 26
975 39 Banská Bystrica

Tel: +421 48 4330 118
Fax: +421 48 411 3575

===


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

Re: Debian base system package list

[Sam Morris]

On Tue, 15 May 2007 08:19:50 +0200, sean finney wrote:
> On Mon, 2007-05-14 at 22:33 -0700, Carlos Ramirez wrote:
>> Is a file, webpage or command that can provide a list of packages that
>> are part of the Debian base system? I tried searching in various places
>> without much luck. Any help in the right direct is appreciated.

Some poiking about in apt's Packages list as described by sean will do 
the trick, although there is also a 'Priority: important' level, which I 
assume is installed by default along with required packages.

If the user opts to activate any 'tasks' during installation then even 
more packages will be installed. See '/usr/share/tasksel/debian-
tasks.desc' for the list of tasks, and '/usr/share/doc/tasksel/README.gz' 
to see how to interpret the contents of the debian-tasks.desc file.

-- 
Sam Morris
http://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078


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

Re: Debian base system package list

[Frans Pop]

On Tuesday 15 May 2007 11:36, Sam Morris wrote:
> Some poiking about in apt's Packages list as described by sean will do
> the trick, although there is also a 'Priority: important' level, which
> I assume is installed by default along with required packages.

Priority important packages are part of the base system.

For a normal install, packages with Priority standard will be installed as 
well as the "Standard system" task is selected by default. The "Standard 
system" task is somewhat different from other tasks as it is based on the 
priority of packages instead of a list of packages.

The real base system is a fairly bare-bones system.


pgpTnGTeuB24O.pgp
Description: PGP signature

Re: Liability protection project - call for participants

[Toni Mueller]

Hi,

On Tue, 15.05.2007 at 18:11:03 +1000, Anthony Towns <[EMAIL PROTECTED]> wrote:
> On Mon, May 14, 2007 at 03:51:40PM -0700, Bruce Perens wrote:
> > Some of us have homes, and other property that we would rather not place 
> > at risk of any lawsuit connected with our Free Software activities. The 
> > way to do that is to act as a volunteer on the behalf of a non-profit 
> > corporation, with the corporation assuming your liability. [...]

> > owns property that we do not want to expose to liability. Copyrights of 
> > software produced would be assigned to a non-profit like FSF or SPI*

> That said, giving up a little autonomy in exchange for potentially a
> lot of financial security is an entirely sensible tradeoff to consider,
> and it makes a lot of sense to do that before people start getting
> sued individually.
> 
> It might be possible to do something like have SPI get copyright
> assignment for works in return for providing the authors with a vote (or
> a voice) on how they handle that copyright in future, which might ease
> the concerns about handing over control and could even be argued to be a
> "work for hire" arrangement making it a bit easier to deal with legally.

I'm unconvinced that such copyright assignments can be done in a way
that avoids creating an asset - in the form of the software - that the
bad boys can go after. Eg. IFF they (hypthetically) were to
successfully sue the FSF, then we'd lose a large chunk of important
stuff because the copyrights held by the FSF will probably be
confiscated in order to "pay" the damages. I'm also unsure that there
are no ways to extend such a liability if the contracts come to be
"work for hire" style or similar. Example: DDs work for "company A" which
directs them to do something, and "company B" assumes all the benefits
(the copyrights), specified that way in the contract between some DD
and company A. I'm not sure that such a contract would prevent company
B from being disowned in such a case.


Best,
--Toni++


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

Re: Merging packages

[Frank Küster]

Andreas Metzler <[EMAIL PROTECTED]> wrote:

> Luis Rodrigo Gallardo Cruz <[EMAIL PROTECTED]> wrote:
> [...]
>> Also, some people might be relaying in the file's current location for
>> something. Should I put a symlink in their place?
>
> Just a warning: Symlinks that are shipped in the deb and point to
> conffiles (not just directories) are not a good idea.
>
> bug #420578

Oh, since your statement confused me a bit, but reading the bug log
clarified it: The problem is not with any symlink pointing to conffiles,
in particular not with the common case of fixing non-FHS-aware
applications by creating symlinks from /usr/share/ to /etc.

The problem is specifically with symlinks from /etc to some other place
in /etc, and is caused by the fact that debhelper does not mark symlinks
in /etc as conffiles.  Has this aspect been discussed with the debhelper
maintainer? 

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Liability protection project - call for participants

[Miriam Ruiz]

Does all this project involve only proper Debian Developers, or also people
who are maintaining Debian packages without being full Debian Developers?

Also, we're only talking about Developers who live in the USA, or that have
that nationality, aren't we?

Greetings,
Miry

Re: Liability protection project - call for participants

[MJ Ray]

Toni Mueller <[EMAIL PROTECTED]> wrote:
> [...] Eg. IFF they (hypthetically) were to
> successfully sue the FSF, then we'd lose a large chunk of important
> stuff because the copyrights held by the FSF will probably be
> confiscated in order to "pay" the damages. [...]

Even if that is the case (what is the precedent?), then we would not
lose much because as far as I know, FSF grants a perpetual
all-permissions license back to the original author of the copyright-
assigned work.  We'd only lose the ability to defend copyright
infringment on the stuff, but if the FSF has been successfully sued,
then we've arguably lost a big chunk of that anyway.  Other than maybe
making some GPL code effectively BSD-like for whoever sued FSF, the
winner would gain nothing except the ability to police some of our
code for us.

FSF has its faults, but this aspect looks pretty clever to me.

Hope that explains,
-- 
MJ Ray - see/vidu http://mjr.towers.org.uk/email.html
Experienced webmaster-developers for hire http://www.ttllp.co.uk/
Also: statistician, sysadmin, online shop builder, workers co-op.
Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/


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

Re: Debian desktop -situation, proposals for discussion and change. Users point of view.

[Raphael Hertzog]

Hi,

Thank you for sharing your point of view. But you draw too many
conclusions. You speak out of "rumors" and "experience" and you fail to
understand that Debian is not a Desktop-only distribution.

Get involved and learn our development process, you'll discover that you
can't rely on many assumptions that you made.

On Tue, 15 May 2007, Mgr. Peter Tuharsky wrote:
> in my experience, testing is not really good option for real work. There 
> are _platform_ changes going in testing, that leads to broken 
> dependencies and sometimes completely nonfunctional snapshots.

Testing is usable. I used it through the whole development cycle of etch.
Bugs are unavoidable, you said it yourself. It's a matter of how many
problems you can accept.

> Therefore, I suggest _the_platform_ (libraries and so on) to remain 
> stable, just upgrade the software that runs on top of that. Thus we can 
> both avoid broken deps problems, and have new software available.

In the Debian context, "Gnome" is a platform. It's not only software
that runs on top of libc6. Gnome represent dozens of libraries that are used
by hundreds of applications.

You can't just get the latest version and hope that it won't break
anything.

> If You mean to use the software from testing -You must first make it run 
> on stable without need for library upgrades. That is more similar to 
> backports job, than to testing.

You can't backport everything if you don't want to upgrade libraries. It's
simply not doable without rewriting the application.

> Testing should simply be the place where _platform_ changes are shaken 
> out, not the "input buffer for the new software".

Actually sid is where the platform changes are done. And once they're OK,
they get moved to testing in a coherent manner. So testing should stay
usable.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Debian desktop -situation, proposals for discussion and change. Users point of view.

[Mgr. Peter Tuharsky]

Hi, Raphael

Testing is usable. I used it through the whole development cycle of etch.
Bugs are unavoidable, you said it yourself. It's a matter of how many
problems you can accept.


Yes, bugs are unavoidable. However, testing is often in situation "whole 
system broken" or "nearly useless". I see difference here; occassional 
bug in desktop app is acceptable. Whole system unreliable is not acceptable.



In the Debian context, "Gnome" is a platform. It's not only software
that runs on top of libc6. Gnome represent dozens of libraries that are used
by hundreds of applications.


That's true.



You can't just get the latest version and hope that it won't break
anything.


That should be verified in light of broad experience (I don't have any). 
Does it happen often that GNOME version change breaks many things? The 
only my try was to put GNOME 2.0 to Debian Woody (ugly GNOME 1.2), and I 
was succesful.




If You mean to use the software from testing -You must first make it run 
on stable without need for library upgrades. That is more similar to 
backports job, than to testing.


You can't backport everything if you don't want to upgrade libraries. It's
simply not doable without rewriting the application.


I think majority of software _should_ build w/o problem with ordinary 
libraries of maximum 2 years age. In my experience, apps are generally 
happy if libraries are not older than that. Of course, shorter release 
cycle could remove remaining problems in this order.


Next stable release of Debian will of course upgrade the whole platform, 
including the versions, thus software would be happy for next 18 months.




Testing should simply be the place where _platform_ changes are shaken 
out, not the "input buffer for the new software".


Actually sid is where the platform changes are done. And once they're OK,
they get moved to testing in a coherent manner. So testing should stay
usable.


This is just a wish, not a common experience.

Peter


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

Re: Debian desktop -situation, proposals for discussion and change. Users point of view.

[François]

Hello,

On Le Tuesday 15 May 2007, à 14:01:28, Raphael Hertzog wrote:
> > Testing should simply be the place where _platform_ changes are shaken 
> > out, not the "input buffer for the new software".
> 
> Actually sid is where the platform changes are done. And once they're OK,
> they get moved to testing in a coherent manner. So testing should stay
> usable.

And you can also look at [CUT][] which seems a project to fit well
desktop user's needs.

[CUT]:
  
  "Constantly Usable Testing"

François

Post Scriptum : [EMAIL PROTECTED] wrote in

>
> CUT was exactly what testing was supposed to be, in the beginning.
> Period. It hasn't become that. It has gotten to the point that
> sometimes
> testing is borkdened for long periods of time... in small areas mind
> you, but still broken.

which I agree even in a lot of case testing is really usable


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

Re: Debian desktop -situation, proposals for discussion and change. Users point of view.

[Frans Pop]

On Tuesday 15 May 2007 14:44, Mgr. Peter Tuharsky wrote:
> Yes, bugs are unavoidable. However, testing is often in situation
> "whole system broken" or "nearly useless". I see difference here;
> occassional bug in desktop app is acceptable. Whole system unreliable
> is not acceptable.

Can you substantiate that? In my experience it is not true.

And even unstable is almost always usable if you know how to avoid 
temporary uninstability of packages and how to downgrade a package 
occasionally.

Though I'd not advice running unstable to end users, I would happily 
suggest testing.

Cheers,
FJP


pgpNJ1U7ciwY0.pgp
Description: PGP signature

Re: Debian desktop -situation, proposals for discussion and change. Users point of view.

[Raphael Hertzog]

On Tue, 15 May 2007, Mgr. Peter Tuharsky wrote:
> Yes, bugs are unavoidable. However, testing is often in situation "whole 
> system broken" or "nearly useless". I see difference here; occassional 
> bug in desktop app is acceptable. Whole system unreliable is not acceptable.

Have you facts to assert this?

I've been an happy user of testing. It happens that some packages are not
upgradable during a timeframe however the installed packages are not broken
and thus the system is perfectly reliable.

> >You can't just get the latest version and hope that it won't break
> >anything.
> 
> That should be verified in light of broad experience (I don't have any). 
> Does it happen often that GNOME version change breaks many things? The 
> only my try was to put GNOME 2.0 to Debian Woody (ugly GNOME 1.2), and I 
> was succesful.

You can't generalize based on a single experience like that. Your
restricted yourself to software published by the Gnome project. Check how
many applications depend on Gnome and yet are not developed following
Gnome's schedule. Those are the applications which have not been tested by
upstream with the new Gnome and which are the more likely to break.

You can't rely on upstream to do this testing for you. We have a purpose,
we don't stabilize our distribution just because it sounds nice, it's
really needed in many cases.

Don't get me wrong however, I'm all in favor of having backports
integrated in Debian and make it a viable alternative for many users.
But you simply can't drop newer upstream version in what we call "stable"
like you suggest.

We don't really need more discussion on that topic. We need improvements
to make that a realistic goal.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: Debian desktop -situation, proposals for discussion and change. Users point of view.

[Mgr. Peter Tuharsky]

We're going OT, however my experience based on last two Debian releases: 
testing becomes quite "stable in means of usability" somewhere half year 
before it's released as "stable". The sooner before the stable, the 
rapidly increasing is the chance that the snapshot that You have will 
not be installable at all, will have dependencies severely broken, etc.


That's why I suggest: focus on base platform, stabilise it, polish the 
dependencies. Then compile software against it and release it, compile 
newer version and release it, etc.. Desktop software itself shouldn't 
break dependencies.


Peter

Frans Pop  wrote / napísal(a):

On Tuesday 15 May 2007 14:44, Mgr. Peter Tuharsky wrote:

Yes, bugs are unavoidable. However, testing is often in situation
"whole system broken" or "nearly useless". I see difference here;
occassional bug in desktop app is acceptable. Whole system unreliable
is not acceptable.


Can you substantiate that? In my experience it is not true.

And even unstable is almost always usable if you know how to avoid 
temporary uninstability of packages and how to downgrade a package 
occasionally.


Though I'd not advice running unstable to end users, I would happily 
suggest testing.


Cheers,
FJP




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

Re: Debian desktop -situation, proposals for discussion and change. Users point of view.

[Don Armstrong]

On Tue, 15 May 2007, Mgr. Peter Tuharsky wrote:
> We're going OT, however my experience based on last two Debian releases: 
> testing becomes quite "stable in means of usability" somewhere half year 
> before it's released as "stable". The sooner before the stable, the 
> rapidly increasing is the chance that the snapshot that You have will 
> not be installable at all, will have dependencies severely broken, etc.

The goal of testing is to be continuously installable with as few RC
bugs as we can manage. In general, it approaches this goal closely
enough to be usable almost constantly.
 
> That's why I suggest: focus on base platform, stabilise it, polish the 
> dependencies. Then compile software against it and release it, compile 
> newer version and release it, etc.. Desktop software itself shouldn't 
> break dependencies.

If only that were the case. Most of the bugs and pain in transition
that we run into are not in the base system itself, but in everything
else that people actually want to use on their Debian system.

While I am glad that you are interested in making Debian better, you
need to pitch in and become conversant with the problems that we
actually have; only then will you be able to present solutions to
those problems.


Don Armstrong

-- 
Any excuse will serve a tyrant.
 -- Aesop

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: Mysterious NMU (Bug #423455)

[Goswin von Brederlow]

Roberto C. Sánchez <[EMAIL PROTECTED]> writes:

> On Mon, May 14, 2007 at 09:24:35AM +0200, Raphael Hertzog wrote:
> Maybe I misunderstand, but wouldn't something like (>= 1.0.1-1) and (<<
> 1.0.1-2) be more correct?  That way the package is still binNMU safe and
> also safe from breaking if incompatibilities are introduced in the next
> source upload?
>
> Regards,
>
> -Roberto

(>= version) and (<< next-version).

The problem is knowing next-version. 1.0.1-2 is not the next
version. For example a NMU of 1.0.1-1.1 is less. Also 1.0.1-1lenny1
(security update for lenny) is less than 1.0.1-2. There could also be
an 1.0.1-2~rc1, again less than 1.0.1-2.

And now for something really ugly:

% dpkg --compare-versions "1.0.1-1lenny1" "<<" "1.0.1-1+b1" && echo yes
yes

So a security upload of the package has a smaller version than a
binNMU upload. At that point you are pretty much screwed.


One way around the problem is

Package: foo-any
Provides: foo-any-source-version

Package: foo-all
Depends: foo-any-source-version

MfG
Goswin


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

Re: Mysterious NMU (Bug #423455)

[Mike Hommey]

On Tue, May 15, 2007 at 03:49:07PM +0200, Goswin von Brederlow <[EMAIL 
PROTECTED]> wrote:
> Roberto C. Sánchez <[EMAIL PROTECTED]> writes:
> 
> > On Mon, May 14, 2007 at 09:24:35AM +0200, Raphael Hertzog wrote:
> > Maybe I misunderstand, but wouldn't something like (>= 1.0.1-1) and (<<
> > 1.0.1-2) be more correct?  That way the package is still binNMU safe and
> > also safe from breaking if incompatibilities are introduced in the next
> > source upload?
> >
> > Regards,
> >
> > -Roberto
> 
> (>= version) and (<< next-version).
> 
> The problem is knowing next-version. 1.0.1-2 is not the next
> version. For example a NMU of 1.0.1-1.1 is less. Also 1.0.1-1lenny1
> (security update for lenny) is less than 1.0.1-2. There could also be
> an 1.0.1-2~rc1, again less than 1.0.1-2.

A rule that works pretty good:
>= ${source:Version} and <= ${source:Version}.1~


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

Re: Debian desktop -situation, proposals for discussion and change. Users point of view.

[Daniel Burrows]

On Mon, May 14, 2007 at 02:55:40PM +0200, "Mgr. Peter Tuharsky" <[EMAIL 
PROTECTED]> was heard to say:
> Debian developers often see "Ubuntu the enemy" and are mocking it as 
> inferior technology. However, they fail to see, what does the Debian 
> really offer to desktop users eventually. They fail to understand, why 
> are they using Ubuntu happily and reference it to novices. It seems, 
> that desktop users don't see Debian fitting their needs. What are the means?

  When you talk about "desktop users", I think you really mean "novice
consumers".  Is that a fair assessment?  In my experience, Debian can
work just fine on the desktop in some situations, just not for novice
home users.  (think, e.g., about desktops for office workers)

>  b, Stability
> 
> It simply depends on, well, luck on choosing the particulary good 
> version of software. With stable upstream versions of software, there 
> should not be major stability issues anyhow.
> 
> Debian proclaims to offer excellent stability. However, if some 
> application does have stability issues, users must wait at least 2 years 
> for next "stable" version of Debian to see the fix. The stability is not 
> automatically guaranteed by oldness of software and lack of upgrades in 
> Debian.

  The word "stable" with regard to Debian's repositories doesn't mean
"works without bugs".  Every piece of software has bugs, and in general,
if a newer version of the software appears to have less bugs, that's a
reflection of the fact that there's been less time for people to report
the bugs it contains.

  Debian stable is "stable" in the sense of "solid rock" versus "shifting
sands": we ensure that the behavior of the system won't change during a
stable cycle.  There might be bugs in it, but they'll be the same bugs
throughout stable's lifetime.


  Why would you want this?

  In a setting where you have people doing productive work using a piece
of software, unnecessary changes to the software are *worse* in the short
term than a fixed and unchangable set of bugs: not only are changes likely
to break the software, but they may require users to retrain or disrupt
the processes of your organization.  This is true even if the new software
is an unqualified improvement (either in terms of bug count or usability)
over the old software; look at the backlash over the new Ribbon interface
in Microsoft office, for instance.

  Having briefly overseen a small network of Debian systems for a research
group, my sense is that an 18-month cycle would work well in this setting;
anything shorter than a year would be too disruptive.

  I await correction from more experienced members of this list who can
tell me I'm full of it. :)

  Daniel


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

Ensuring complete upgrades in applications with multiple binary packages

[Frank Küster]

Hi,

we've run across a problem with our texlive packages, and I'd like to
get some opinions, in particular regarding dpkg behavior.

TeX Live is one big thing upstream (one DVD) and has been split for
Debian packaging into one arch:any and four arch:all source packages
with numerous binary packages each.  Generally, you cannot assume a
system to work properly which has a mixture of different upstream
versions of these packages installed.  But how should we achieve that?

A. The straightforward approach is the most ugly one: The packages of
   course frequently declare "Depends: texlive-some-other-package", and
   we could switch all of these depends into versioned depends, (>=
   $upstream-version).  But that would really look ugly, e.g. from
   texlive-latex-extra:

-Depends: preview-latex-style, texlive-common (>= 2007), texlive-pictures, 
texlive-latex-base
+Depends: preview-latex-style, texlive-common (>= 2007), texlive-pictures (>= 
2007), texlive-latex-base (>= 2007)

   It would require a really big change to our internal packaging
   scripts to add such version restrictions only where a real
   incompatibility shows up, so it would have to be each of them.

B. texlive-common could declare 

Conflicts: 

   But how would that work upon upgrade?  Technically, there's no
   problem, first all texlive packages except texlive-common would be
   unpacked, then texlive-common could be unpacked and configured, after
   that the others can be configured.

   But usually dpkg tries to do unpacking and configuring in the same
   order; would it be confused by this situation?

C. Ignore the problem and just expect from users to handle their
   upgrades in a sane way and not put individual packages on hold?  Of
   course, other reasons like unrelated errors during dist-upgrade might
   also cause version mixes, but again the sane thing to do would be to
   run dist-upgrade again, and not try to use the packages or report a
   bug... 

Comments?

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Bug#423911: ITP: citadel -- Citadel.org is an highly integrated Groupware Platform with a Web 2.0 enabled Webinterface, but also providing SMTP, IMAP, POP3 and GroupDAV access to its content.

[Steve Greenland]

On 14-May-07, 19:35 (CDT), Ron Johnson <[EMAIL PROTECTED]> wrote: 
> On 05/14/07 17:23, Wilfried Goesgens wrote:
> >   Description : Citadel.org is an highly integrated Groupware Platform 
> > with a Web 2.0 enabled Webinterface, but also providing SMTP, IMAP, POP3 
> > and GroupDAV access to its content.
> 
> You don't need to put "Citadel.org" in the short description.  And
> the short description should be limited to 50(?) characters.

Also, there's no need to capitalize "Groupware Platform", "Webinterface" should
be "web interface."

> > Citadel offers Versatile email services with verry low administration 
> > needed. It provides its own implementations of these server protocols:
> > Imap, Pop3, SMTP, ManageSieve, Citadel

Versatile => versatile
verry => very
Imap => IMAP
Pop3 => POP3

(Yes, small nit-picky changes.)

Thanks,
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: print-system virtual package?

[Steve Greenland]

On 14-May-07, 14:40 (CDT), Andreas Fester <[EMAIL PROTECTED]> wrote: 
> I was just investigating a bug where the issue seems
> that no print system is installed
> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=420746)
> 
> That raised the question: would it make sense to add a
> virtual package like "print-system" or similar, which
> is provided by cupsys-client, lpr et al. and which I
> can suggest or recommend in my package?

Well, given the specific error:

$ qcad
libcups.so: cannot open shared object file: No such file or directory

I don't think you need a virtual depends, but instead an explicit
Depends: cupsys-client.

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: Mysterious NMU (Bug #423455)

[Roberto C . Sánchez]

On Tue, May 15, 2007 at 03:49:07PM +0200, Goswin von Brederlow wrote:
> Roberto C. Sánchez <[EMAIL PROTECTED]> writes:
> 
> > On Mon, May 14, 2007 at 09:24:35AM +0200, Raphael Hertzog wrote:
> > Maybe I misunderstand, but wouldn't something like (>= 1.0.1-1) and (<<
> > 1.0.1-2) be more correct?  That way the package is still binNMU safe and
> > also safe from breaking if incompatibilities are introduced in the next
> > source upload?
> >
> > Regards,
> >
> > -Roberto
> 
> (>= version) and (<< next-version).
> 
> The problem is knowing next-version. 1.0.1-2 is not the next
> version. For example a NMU of 1.0.1-1.1 is less. Also 1.0.1-1lenny1
> (security update for lenny) is less than 1.0.1-2. There could also be
> an 1.0.1-2~rc1, again less than 1.0.1-2.
> 
Yes, but in reality what is the likelihood that either a security update
or NMU would introduce an incompatible change?  I would say that such a
possibility is extremely low.

> And now for something really ugly:
> 
> % dpkg --compare-versions "1.0.1-1lenny1" "<<" "1.0.1-1+b1" && echo yes
> yes
> 
> So a security upload of the package has a smaller version than a
> binNMU upload. At that point you are pretty much screwed.
> 
Perhaps the policy should change so that security uploads are done with
x.y.z-(w++)~lenny1?  That is, the Debian version number gets
incremented.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Bug#424067: ITP: python-sasync -- asynchronous access for SQLAlchemy

[Eric Evans]

Package: wnpp
Severity: wishlist
Owner: Eric Evans <[EMAIL PROTECTED]>


* Package name: python-sasync
  Version : 0.4
  Upstream Author : Edwin A. Suominen <[EMAIL PROTECTED]>
* URL : http://foss.eepatents.com/sAsync
* License : GPL
  Programming Lang: Python
  Description : asynchronous access for SQLAlchemy

An enhancement to the SQLAlchemy package that provides asynchronous
deferred-result access via the Twisted framework and an access broker
for conveniently managing database access, table setup, and 
transactions. Included are modules for implementing persistent
dictionaries, three-dimensional arrays, and graph objects.

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

Kernel: Linux 2.6.18-4-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- 
Eric Evans
[EMAIL PROTECTED]


signature.asc
Description: Digital signature

Call for tests: webcalendar 1.1.2-1

[Rafael Laboissiere]

I just released webcalendar 1.1.2 to experimental.  Although this version is
considered to be a development version by the upstream author (1.0.5 is the
recommended "production" release), it is good to have the 1.1.* branch in
experimental, such that upgrade problems are detected before Webcalendar 1.2
comes out.

The trickiest aspect of the package is indeed related to the upgrade of the
SQL database via dbconfig-common.  I have tested 1.0.5 -> 1.1.2 migration
using Apache an MySQL and the major problems seem to be fixed. However,
there should be corner cases where the upgrade would fail.

Hence the present Call for Tests.  If you are a WebCalendar 1.0.* user, I
would like to hear about your upgrading experiences.  Also, tests results
regarding PostgreSQL and SQLite are welcome.  If you use another HTTP server
than Apache or if you have webcalendar embedded into postnuke or joomla, I
would like to know about your eventual problems.

Note that the upgrade from 0.9.* should also be tested, but 0.9.45-4sarge7
was released in the pre-dbconfig-common era, so I am not sure whether we
should also support automatic upgrade from that version.

-- 
Rafael


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

Re: ITP: bandwidthcalc -- file transfer time calculator written in GTK+

[Christoph Goehre]

Hi,

John Goerzen wrote:
> I guess I have to just ask: how useful is this?
> 
> This is really a quite trivial calculation, and many apps/websites
> perform it automatically these days anyway.

It's right, but rsync only display upload/download time for one file,
even if You transfer 20 files. And what about people sitting in a closed
network without access to Internet?

Greetings,
  Christoph


signature.asc
Description: OpenPGP digital signature

Re: Mysterious NMU (Bug #423455)

[Lennart Sorensen]

On Tue, May 15, 2007 at 12:20:22PM -0400, Roberto C. S?nchez wrote:
> Yes, but in reality what is the likelihood that either a security update
> or NMU would introduce an incompatible change?  I would say that such a
> possibility is extremely low.

Why couldn't a security change require making incompatible changes to
something?  A bin NMU would hopefully never change any such thing
though.

> Perhaps the policy should change so that security uploads are done with
> x.y.z-(w++)~lenny1?  That is, the Debian version number gets
> incremented.

But isn't the idea that the version in test/unstable should _always_ be
higher than the version in stable including security versions?  That
makes incrementing 'w' not an option.

--
Len Sorensen


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

Re: Merging packages

[Andreas Metzler]

Frank Küster <[EMAIL PROTECTED]> wrote:
> Andreas Metzler <[EMAIL PROTECTED]> wrote:
[...]
>> bug #420578

> Oh, since your statement confused me a bit, but reading the bug log
> clarified it: The problem is not with any symlink pointing to conffiles,
> in particular not with the common case of fixing non-FHS-aware
> applications by creating symlinks from /usr/share/ to /etc.

Sorry for being unclear.

> The problem is specifically with symlinks from /etc to some other place
> in /etc, and is caused by the fact that debhelper does not mark symlinks
> in /etc as conffiles.  Has this aspect been discussed with the debhelper
> maintainer? 

Actually the problem is that dpkg does not handle the case (#421344)
sanely and therefore debhelper cannot (#421346) do it.

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


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

Re: Debian desktop -situation, proposals for discussion and change. Users point of view.

[Steve Greenland]

On 15-May-07, 04:25 (CDT), "Mgr. Peter Tuharsky" <[EMAIL PROTECTED]> wrote: 
> 
> Do You think, that
> -compiling new upstream version of software against stable platform, 
> building a package and distributing it
> -needs more effort than
> -studying security fixes in upstream, backporting them to ancient 
> version of software (if it's barely possible), compiling it against 
> stable platform, building a package and distributing it?

It's not a matter of effort, it's a matter of stability. A new upstream
version is a *much* higher risk of breaking other packages than
backporting a security fix. 

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: Debian desktop -situation, proposals for discussion and change. Users point of view.

[Steve Greenland]

On 15-May-07, 08:27 (CDT), "Mgr. Peter Tuharsky" <[EMAIL PROTECTED]> wrote: 
> We're going OT, however my experience based on last two Debian releases: 
> testing becomes quite "stable in means of usability" somewhere half year 
> before it's released as "stable". The sooner before the stable, the 
> rapidly increasing is the chance that the snapshot that You have will 
> not be installable at all, will have dependencies severely broken, etc.

That does not match my experience with testing. 

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: Debian desktop -situation, proposals for discussion and change. Users point of view.

[Steve Greenland]

On 14-May-07, 07:55 (CDT), "Mgr. Peter Tuharsky" <[EMAIL PROTECTED]> wrote: 
> Ask somebody, what distro would he install at desktop for novice or M$ 
> refugee? Why many are choosing Ubuntu instead of Debian, and even worse, 
> abandon Debian in favor of Ubuntu?

Why is this worse? Why isn't there room for two similar distributions,
with one aimed at being more up-to-date for a limited set of packages
and hardware, while the other aims at being rock-solid on a wide variety
of hardware for extended periods of time?

There are certainly ways that Debian can improve, but I'm not convinced
that "become more like Ubuntu" is one of them. Why not let Ubuntu
fulfill the desires of that group of users?

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]

System freezes when copying large files over pptp in Etch

[Bastian Venthur]

Hi all,

I have several machines (all T60s) at work running Debian/Etch/AMD64
suffering the same problem: when copying large files over network the
system suddenly freezes and is only rebootable via power-off button.

I can reproduce this bug pretty constantly when running pptp but was not
able to reproduce it without pptp yet, so I'm assuming it's a problem
with pptp-linux or one of the relevant kernel drivers.

I've no idea what the problem is but I noticed that my syslog always
gets spammed with the following lines just before the freeze:

pptp[4072]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 484619
(expecting 484489, lost or reordered)
pptp[4072]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 484620
(expecting 484618, lost or reordered)
pptp[4072]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 484621
(expecting 484618, lost or reordered)
pptp[4072]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 484622
(expecting 484618, lost or reordered)
pptp[4072]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 484623
(expecting 484618, lost or reordered)
pptp[4082]: anon log[logecho:pptp_ctrl.c:676]: Echo Reply received.


Someone pointed me to #416404 which is an open, grave bug against pptpd
in etch, which sounded very similar but it's filled against pptpd
(server) which is not even installed on those systems but pptp-linux
(client).

Is someone aware of this problem and knows if a bugreport was already
filled?

If not, how can I get useful information to report a bug myself? I've
tried strace but it doesn't seem to provide useful information in this
case (just read, write, select, ... again and again when using wget to
download big files).


Cheers,

Bastian

-- 
Bastian Venthur  http://venthur.de
Debian Developer venthur at debian org


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

Re: Liability protection project - call for participants

[Russ Allbery]

Bruce Perens <[EMAIL PROTECTED]> writes:

> There is a downside. If you work on behalf of such an entity, you would
> have to agree to act at their direction, which means acting responsbily
> on their behalf, by not doing stupid stuff that obviously increases the
> corporation's risk of being sued.

There are other potential downsides and complex legal interactions, such
as interactions with existing personal umbrella policies which some people
already carry and interactions with liability insurance already carried by
employers when one's Debian work is wholly or partially in the context of
some other employment.  There are also possible conflict-of-interest
issues for those whose employers are fine with personal contributions to
volunteer projects but may not feel the same way about affiliation with a
registered non-profit in an area of work that could be argued to be
competing.

I think it's important that, if this comes to fruition, it comes with very
good legal advice attached, and I think that legal advice may need to be
tailored to the specific circumstances of individual developers.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Debian desktop -situation, proposals for discussion and change. Users point of view.

[Andreas Tille]

On Tue, 15 May 2007, Mgr. Peter Tuharsky wrote:

We're going OT, however my experience based on last two Debian releases: 
testing becomes quite "stable in means of usability" somewhere half year 
before it's released as "stable". The sooner before the stable, the rapidly 
increasing is the chance that the snapshot that You have will not be 
installable at all, will have dependencies severely broken, etc.


In several mails you claimed testing as broken.  This is completely
orthognal to my experience.  I'm using testing since its existence
on most of my boxes.  Only production servers are running stable and
I keep my fingers from running unstable (except of chroots).  So
were is the proof for you statement.  What are the numbers of the
bugs you might have reported against packages in testing? Could you
please a bit more verbose about your problems in testing because
nobody else made it to my radar that testing is that unusable.
Perhaps I missed something ...

Kind regards

   Andreas (writing from a laptop that runs testing. ;-))

--
http://fam-tille.de


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

Re: print-system virtual package?

[Steve Langasek]

On Tue, May 15, 2007 at 10:44:05AM -0500, Steve Greenland wrote:
> On 14-May-07, 14:40 (CDT), Andreas Fester <[EMAIL PROTECTED]> wrote: 
> > I was just investigating a bug where the issue seems
> > that no print system is installed
> > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=420746)

> > That raised the question: would it make sense to add a
> > virtual package like "print-system" or similar, which
> > is provided by cupsys-client, lpr et al. and which I
> > can suggest or recommend in my package?

> Well, given the specific error:

> $ qcad
> libcups.so: cannot open shared object file: No such file or directory

> I don't think you need a virtual depends, but instead an explicit
> Depends: cupsys-client.

Well, no; qcad needs to be fixed to use the fully qualified library name
with soname included, instead of assuming it can open any file name
'libcups.so' (even if present) and get the interface it's looking for.

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


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

Re: Ensuring complete upgrades in applications with multiple binary packages

[Josselin Mouette]

Le mardi 15 mai 2007 à 16:28 +0200, Frank Küster a écrit :
> TeX Live is one big thing upstream (one DVD) and has been split for
> Debian packaging into one arch:any and four arch:all source packages
> with numerous binary packages each.  Generally, you cannot assume a
> system to work properly which has a mixture of different upstream
> versions of these packages installed.  But how should we achieve that?
> 
> A. The straightforward approach is the most ugly one: The packages of
>course frequently declare "Depends: texlive-some-other-package", and
>we could switch all of these depends into versioned depends, (>=
>$upstream-version).  But that would really look ugly, e.g. from
>texlive-latex-extra:
> 
> -Depends: preview-latex-style, texlive-common (>= 2007), texlive-pictures, 
> texlive-latex-base
> +Depends: preview-latex-style, texlive-common (>= 2007), texlive-pictures (>= 
> 2007), texlive-latex-base (>= 2007)

It's ugly but it's the right thing to do. Unfortunately it doesn't
prevent texlive-latex-extra 2007 from being installed with
texlive-common 2008.

> B. texlive-common could declare 
> 
> Conflicts: 
> 
>But how would that work upon upgrade?  Technically, there's no
>problem, first all texlive packages except texlive-common would be
>unpacked, then texlive-common could be unpacked and configured, after
>that the others can be configured.
> 
>But usually dpkg tries to do unpacking and configuring in the same
>order; would it be confused by this situation?

dpkg handles this case right, but it's really painful in the long term.

> C. Ignore the problem and just expect from users to handle their
>upgrades in a sane way and not put individual packages on hold?

Not setting strong enough dependencies is a RC bug.


For GNOME packages, we opted for a solution similar to A, but with the
notion of a "next upstream version". For example, epiphany-extensions
declares:
Depends: epiphany-browser (>= ${gnome:Version}), epiphany-browser (<< 
${gnome:NextVersion})

The two variables are expanded (e.g. to 2.18 and 2.19 for GNOME 2.18.X)
by a specific rule. We can afford to do that for almost all packages
because upstream guarantees compatibility inside a major release.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: print-system virtual package?

[Andreas Fester]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Steve Greenland wrote:
[...]
>> That raised the question: would it make sense to add a
>> virtual package like "print-system" or similar, which
>> is provided by cupsys-client, lpr et al. and which I
>> can suggest or recommend in my package?
> 
> Well, given the specific error:
> 
> $ qcad
> libcups.so: cannot open shared object file: No such file or directory
> 
> I don't think you need a virtual depends, but instead an explicit
> Depends: cupsys-client.

Well, the question was more a general one ;) because I was not sure if
explicitly depending on one specific printing frontend is a good idea.

Nevertheless, I meanwhile think that this specific issue has a different
cause: it seems that the Qt runtime dynamically loads "libcups.so",
which is of course only available when the corresponding -dev package
is installed (I could reproduce the originally reported issue today after
a reboot). Manually creating the dev link from libcups.so.2 to libcups.so
then worked around the problem ...

Best Regards,

Andreas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGShCaZ3bQVzeW+rsRAnj0AJ9cQJkdZD27/BxrH2bcxAjzBkXsIQCeNtz6
ayyyEbmLBU/m+eObLqoLiOA=
=EZK7
-END PGP SIGNATURE-


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

Re: Ensuring complete upgrades in applications with multiple binary packages

[Steve Langasek]

On Tue, May 15, 2007 at 04:28:39PM +0200, Frank Küster wrote:
> B. texlive-common could declare 

> Conflicts: 

>But how would that work upon upgrade?

Very, very poorly.  Versioned conflicts are advocated against in Policy 7.3,
because the package manager will often find it easier to remove the old
version of the package than to upgrade it to a version that's acceptable. 
These sorts of conflicts seem to always be a major source of pain for
non-interactive dist-upgrades.

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


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

update-initramfs -k all -u

[Tim Dijkstra]

Hi,

I maintain uswsusp. It is a package that relies on a binary on the
initramfs that will start the resume process. This binary (and some
other stuff) get installed via an update-initramfs call in the postinst.
On some updates, the new binary that suspends the system is
incompatible with the old resume binary on the initramfs, hence a
update-initramfs call is required.

So far so good. 

Current pratice is to only call `update-initramfs -u', that is, to only
update the most recent initramfs. This however will break older
initramfses (I have had bugreports). Now I plan to switch to running
with '-k all' (all initramfses), but this of course will also influence 
the packages that ran with '-u' only. 

Now what do people think is the best option? (And why?)

grts Tim


signature.asc
Description: PGP signature

Bug#424170: ITP: python-twisted-goodies -- miscellaneous add-ons for the Twisted networking framework

[Eric Evans]

Package: wnpp
Severity: wishlist
Owner: Eric Evans <[EMAIL PROTECTED]>


* Package name: python-twisted-goodies
  Version : 0.2
  Upstream Author : Edwin A. Suominen <[EMAIL PROTECTED]>
* URL : http://foss.eepatents.com/Twisted-Goodies
* License : GPL
  Programming Lang: Python
  Description : miscellaneous add-ons for the Twisted networking framework

This package contains miscellaneous third-party add-ons and improvements
to the Twisted asynchronous processing framework.

Modules included in this package:

  taskqueue: Asynchronous task queuing with a TaskQueue object and
  support staff for running tasks through a queue with a powerful system
  of task prioritization and management.

  webfetch: HTTP fetching with a SiteGetter object that handles fetching
  of web pages from a given server.

  asyncluster: Asynchronous clustering with a cluster management server
  asyncluster.master and node display manager asyncluster.ndm that
  communicate via Twisted's Perspective Broker.


The long description was (mostly) taken verbatim from the project 
website and will need some work (suggestions welcome).


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

Kernel: Linux 2.6.18-4-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- 
Eric Evans
[EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: update-initramfs -k all -u

[Nikita V. Youshchenko]

> Hi,
> 
> I maintain uswsusp. It is a package that relies on a binary on the
> initramfs that will start the resume process. This binary (and some
> other stuff) get installed via an update-initramfs call in the postinst.
> On some updates, the new binary that suspends the system is
> incompatible with the old resume binary on the initramfs, hence a
> update-initramfs call is required.
> 
> So far so good.
> 
> Current pratice is to only call `update-initramfs -u', that is, to only
> update the most recent initramfs. This however will break older
> initramfses (I have had bugreports). Now I plan to switch to running
> with '-k all' (all initramfses), but this of course will also influence
> the packages that ran with '-u' only.
> 
> Now what do people think is the best option? (And why?)

This may be related:
http://lists.debian.org/debian-devel/2006/12/msg00014.html


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

Re: sp: "News"

[Confirmation from Deen Foxx]

The message that you sent to me (Deen Foxx) has not yet been delivered:

 From: debian-devel@lists.debian.org
 Subject: sp: "News"
 Date: Tue, 16 May 2007 01:15:44 -0300 (MSK)

I am now using Vanquish to avoid spam.  This automated message
is an optional feature of that service, which I have enabled.

Please accept this one-time request to confirm that the above
message actually came from you.  Your confirmation will release
the message and allow all future messages from your address.

Click here to confirm:
http://confirm.vanquish.com/?U=lpKUi9n4VxfNkwO7bPrNxg

Vanquish respects my privacy and yours.  Your confirmation
gets your mail delivered to me now and in the future.  It
does not serve any marketing purpose.  Learn how privacy is
assured: www.vanquish.com/privacy

Re: Getting Debian to use less power?

[Christine Spang]

On Mon, May 14, 2007 at 09:20:00AM +0200, Petter Reinholdtsen wrote:
> Well, my experience is that rarely do the RFP result in anyone
> stepping up, and as I need the package and did the work already, I saw
> no use in not making it available from the Debian archive.

I'll maintain powertop if you're looking to get rid of it. I have a new
package for 1.2 sitting on my machine right now, just waiting to get an
"okay" before I upload.

Cheers,
Christine


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

Re: Debian desktop -situation, proposals for discussion and change. Users point of view.

[Greg Folkert]

On Mon, 2007-05-14 at 14:55 +0200, Mgr. Peter Tuharsky wrote:
> Ask somebody, what distro would he install at desktop for novice or 
> M$ refugee?

For me the choice is clear. I use Debian for myself. I choose to support
Ubuntu for people that do not want as many choices. This is what M$
refugees think they want. Ubuntu is channelized into a few "platforms"
as you put it. It has:

Ubuntu == GNOME Desktop Environment ("platform")
Kubuntu == KDE Desktop Environment ("platform")
Xubuntu == XFCE Desktop Environment ("platform")

Each is release accordingly to the "GNOME" release schedule, as that is
the driving force behind Ubuntu's release schedule. This release
schedule is 6 months.

> Why many are choosing Ubuntu instead of Debian, and even worse, 
> abandon Debian in favor of Ubuntu?

The same reason many people choose Fedora Core or Mandriva or Gentoo or
 because they can. I abandon Debian for other
people, only because it has a (as you put it) more "friendly" support
system. 

> Why do most people consider Debian to be user-unfriendly and
> server-oriented distro?

It is a misnomer that Debian is all about "elitism" or that it is hard
to install or that the developers/mailing lists don't speak "newbie-ese"
or that it doesn't support "new hardware" really well. I have to tell
you the only thing in that list that *might* be right is the hardware
thing for "stable". Stable... more on the stable/ testing/ unstable/
thing in a bit.

> Debian developers often see "Ubuntu the enemy" and are mocking it as 
> inferior technology. However, they fail to see, what does the Debian 
> really offer to desktop users eventually.

Sure, there is a bit of friction. Not "Ubuntu is TEH 3N3MY, 7HR0W R0XX
47 7H3M! D13! D13! D13!" or "Argh, there mateys, we be sailing up the
port side of the "Ubuntu", prepare the starboard side cannons!"

Nothing of the sort. Ubuntu and Debian have a tremendously different set
of motivators for releases and development.

Debian, is all about volunteers, free and Free software and
policy to implement them without much ado. This also has to
occur across 10 or so Hardware architectures at the same time.

Ubuntu, is all about volunteers, free and Free software, except
where is interferes with the release schedule and the "quality"
of the user experience. And it only supports three hardware
architectures. And apparently soon, only 2 as Apple dropped
PowerPC as an architecture. AND it is supported by a commercial
entity.

> They fail to understand, why are they using Ubuntu happily and
> reference it to novices. It seems, that desktop users don't see Debian
> fitting their needs. What are the means?

It is more about the fact that Ubuntu is indeed a niche OS. Debian runs
on a plethora of Hardware Architectures and is consistent across those
architectures.

> The answers:
> 1, needs
> 2, release cycle philosophy
> 3, community
> 4, priorities
> 
> As many see, all of them are different in server and in desktop world,
> and many times Debian chooses to dictate the users "we know the best 
> what You need" instead of listening to them.

Why then are there 28000+ packages in Debian? If Debian only dictates,
why then are there *FAR* more packages available for install than in
*ANY* other Distribution? How many Window Managers? How many alternative
packages to do the same thing, like word processing, editors, music
clients, rss feed readers, web-browsers? I could go on for days, but I
hope you get my point.

Come on, we know the answer, you can say it.

> Let's think a while about the current situation. First define, what I 
> need from my _desktop_, being an ordinary power user:
> 
> a, The system must work well with available hardware, automatically
> and "naturally"

This depends on *MANY* things. Primarily the Kernel. But also side
projects to deal with vendors that produce *WINDOWS ONLY* device
drivers. Case in point Wireless drivers. NDIS wrapper is a very good
attempt to cover this. There are other device manufactures that only
develop Windows drivers only. This is a case of "Why bother, Windows
cover 90%+ of the field"

> b, Stable without (too many) crashes

Do you realize Debian's stable is classified as this:

Stable means stable package list. No changes in API and ABI
names or versions. This means no newer versions will ever make
it into "stable". It is in "maintenance mode". This makes a very
good setup for those wishing for "Rock Solid" machines. Doesn't
crash. "too many" comes from the "Windows World", does not
typically apply to Debian's Linux.

> c, Applications should work generally

Okay, what specifically does not work in Debian? I have a few obscure
problems, but they are obscure. Currently in Sid, I have an xnest
problem, but it was only just introduced, will be fixed very shortly. I
don't see your "should work generally", mine just *D

Re: sp: "News"

[Lennart Sorensen]

On Tue, May 15, 2007 at 05:16:54PM -0400, Confirmation from Deen Foxx wrote:
> The message that you sent to me (Deen Foxx) has not yet been delivered:
> 
>  From: debian-devel@lists.debian.org
>  Subject: sp: "News"
>  Date: Tue, 16 May 2007 01:15:44 -0300 (MSK)
> 
> I am now using Vanquish to avoid spam.  This automated message
> is an optional feature of that service, which I have enabled.
> 
> Please accept this one-time request to confirm that the above
> message actually came from you.  Your confirmation will release
> the message and allow all future messages from your address.
> 
> Click here to confirm:
> http://confirm.vanquish.com/?U=lpKUi9n4VxfNkwO7bPrNxg
> 
> Vanquish respects my privacy and yours.  Your confirmation
> gets your mail delivered to me now and in the future.  It
> does not serve any marketing purpose.  Learn how privacy is
> assured: www.vanquish.com/privacy

Hmm, seems someone subscribed while using one of those totally braindead
email confirmation systems that only serversto cause more spam and
infinite loops in mail systems.  This almost falls under the same
category as 'no vacation mail' although not quite the same.  Maybe a new
item should be added to the mailing list 'Code of conduct'. :)

--
Len Sorensen


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

Re: Debian desktop -situation, proposals for discussion and change. Users point of view.

[Greg Folkert]

On Tue, 2007-05-15 at 21:43 +0200, Andreas Tille wrote:
> On Tue, 15 May 2007, Mgr. Peter Tuharsky wrote:
> 
> > We're going OT, however my experience based on last two Debian
> releases: 
> > testing becomes quite "stable in means of usability" somewhere half
> year 
> > before it's released as "stable". The sooner before the stable, the
> rapidly 
> > increasing is the chance that the snapshot that You have will not
> be 
> > installable at all, will have dependencies severely broken, etc.
> 
> In several mails you claimed testing as broken.  This is completely
> orthognal to my experience.  I'm using testing since its existence
> on most of my boxes.

To that, I run Sid/unstable on 90% of everything I have. Stable on those
machines that cannot have problems.

> Only production servers are running stable and I keep my fingers from
> running unstable (except of chroots).

I haven't seen an unstable problem that was a problem for more than a
couple of days... and mostly had workarounds in any case.

> So were is the proof for you statement.  What are the numbers of the
> bugs you might have reported against packages in testing? Could you
> please a bit more verbose about your problems in testing because
> nobody else made it to my radar that testing is that unusable. Perhaps
> I missed something ...

I've asked for specific examples.

> Kind regards
> 
> Andreas (writing from a laptop that runs testing. ;-))

Cheers from a Sid+Experimental machine.
-- 
greg, [EMAIL PROTECTED]
PGP key: 1024D/B524687C  2003-08-05
Fingerprint: E1D3 E3D7 5850 957E FED0  2B3A ED66 6971 B524 687C
Alternate Fingerprint: 09F9 1102 9D74  E35B D841 56C5 6356 88C0



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

Re: Mysterious NMU (Bug #423455)

[Roberto C . Sánchez]

On Tue, May 15, 2007 at 01:14:01PM -0400, Lennart Sorensen wrote:
> On Tue, May 15, 2007 at 12:20:22PM -0400, Roberto C. S?nchez wrote:
> > Yes, but in reality what is the likelihood that either a security update
> > or NMU would introduce an incompatible change?  I would say that such a
> > possibility is extremely low.
> 
> Why couldn't a security change require making incompatible changes to
> something?  A bin NMU would hopefully never change any such thing
> though.
> 
I am not saying that such a thing couldn't happen, simply that a
security update is much less likely to cause it.

> > Perhaps the policy should change so that security uploads are done with
> > x.y.z-(w++)~lenny1?  That is, the Debian version number gets
> > incremented.
> 
> But isn't the idea that the version in test/unstable should _always_ be
> higher than the version in stable including security versions?  That
> makes incrementing 'w' not an option.
> 
Well, the ~ character is stated to be evaluated to be less than the
empty string.  If a package is the target of a security upload in
stable, you can be certain that the testing/unstable version will also
increase when the new package is introduced to fix the problem there as
well.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: update-initramfs -k all -u

[martin f krafft]

also sprach Tim Dijkstra <[EMAIL PROTECTED]> [2007.05.15.2201 +0200]:
> Now what do people think is the best option? (And why?)

I use -k all in mdadm already. I could not find any reasons why that
would not be a good idea.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
when everything is coming your way, you're in the wrong lane.


signature.asc
Description: Digital signature (GPG/PGP)

Re: RFC: initramfs-tools postinst causes system inconsistency?

[maximilian attems]

i'd appreciate if you post such questions to the corresponding
development mailing list which is debian-kernel for initramfs
questions. 
thanks

> Current pratice is to only call `update-initramfs -u', that is, to only
> update the most recent initramfs. This however will break older
> initramfses (I have had bugreports). Now I plan to switch to running
> with '-k all' (all initramfses), but this of course will also
> influence=20 the packages that ran with '-u' only.

afaik uswsusp does not support full > 2.6.15 range,
so better stay on the safe side.

-- 
maks


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

Re: RFC: initramfs-tools postinst causes system inconsistency?

[Warren Turkal]

On Tuesday 15 May 2007 15:54, maximilian attems wrote:
> afaik uswsusp does not support full > 2.6.15 range,
> so better stay on the safe side.

What about > 2.6.18? I am not sure Debian should be that worried about kernels 
before the one that shipped with the last stable.

wt
-- 
Warren Turkal, Research Associate III/Systems Administrator
Colorado State University, Dept. of Atmospheric Science


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

Re: Debian desktop -situation, proposals for discussion and change. Stable too stable?

[Charles Plessy]

Le Tue, May 15, 2007 at 05:50:50PM -0400, Greg Folkert a écrit :
> > f, Usability problems, wishes and bugs should get fixed too. I should
> > be able to report a problem, participate on it's solution and see
> > fruits of that.
> 
> Have you even looked at Debian's BTS? Unless your patch or bug is a
> security related problem, it won't make it into "Stable". "Stable" is in
> maintenance mode. Not in "New features or versions or additions or
> design improvements" mode. That would be "testing".

Hi all,

I think that Peter really makes a point there. Since the release of
Etch, I am using it at work, and I am running in usabiilty bugs.  Since
they do not open the possibility for somebody else to take control of my
machine, will they never be fixed?

Definitely, a good backporting strategy could be very helpful to users,
but I think that Debian needs something else in addition. For the
moment, users of stable must rely on linear "webforum-style" information
written in english in the BTS to find workarounds, or be lucky that
somebody on a user mailing list shares their experience.

Since the BTS understands versions, maybe providing an easy display of
the bugs which are still open in Stable could help users to have a good
overview. In line with this, official message (for instance a summary)
from the maintainers could be displayed (and translated ?) on top of the
bug. Maybe at each point release, the release notes could be updated on
the basis of these messages. Things like "emacs21 does not have full
unicode support, but you can display chinese characters if you install
the mule-ucs package." for instance. (I wasted hours, because I thought
that packages with no full unicode support would at least have an open
bug on this issue since it is a past release goal...).

Have a nice day,

-- 
Charles


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

Re: Debian desktop -situation, proposals for discussion and change. Users point of view.

[David Nusinow]

On Tue, May 15, 2007 at 09:41:17AM +0200, Mgr. Peter Tuharsky wrote:
> The kernel, the X.org

So are you volunteering to join the kernel and XSF teams to make this
happen?

 - David Nusinow


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

Re: Debian desktop -situation, proposals for discussion and change. Stable too stable?

[Frans Pop]

On Wednesday 16 May 2007 01:11, Charles Plessy wrote:
> Maybe at each point release, the release notes could be
> updated on the basis of these messages. Things like "emacs21 does not
> have full unicode support, but you can display chinese characters if
> you install the mule-ucs package." for instance. (I wasted hours,
> because I thought that packages with no full unicode support would at
> least have an open bug on this issue since it is a past release
> goal...).

IIRC there already is a general note about that in the RN. (At least in 
the "installation" section, not sure about the "what's changed" section.

Feel free to file BRs against release-notes for information that could be 
added. Including a (short) proposed text for an issue increases the 
chance it will be included.

Cheers,
FJP


pgpGwFCsunq2H.pgp
Description: PGP signature

Bug#424406: ITP: python-snpp -- SNPP library for Python

[Bernd Zeimetz]

Package: wnpp
Severity: wishlist
Owner: Bernd Zeimetz <[EMAIL PROTECTED]>

* Package name: python-snpp
  Version : 1.1.1
  Upstream Author : Monty Taylor <[EMAIL PROTECTED]>
* URL : http://www.sf.net/projects/pysnpp
* License : GPL2
  Programming Lang: Python
  Description : SNPP library for Python

Pure Python library implementing RFC 1861, the
 Simple Network Paging Protocol


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

Re: Bug Squashing Party -- May 17th - 20th

[David Claughton]

Martin Zobel-Helas wrote:


where to find available RC bugs:
  http://bts.turmzimmer.net/details.php?ignore=sid&ignnew=on&new=5


I'm just curious - the "ignore=sid" part means exclude bugs that only 
affect sid, correct?  Which means bugs which affect lenny but are 
already fixed in sid are still included (I think).


Is it useful to have bugs already fixed in sid included in the list for 
BSP purposes?  I would have thought "bydist=both" would be more appropriate.


Just my 2p.

Dave.


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

Re: Mysterious NMU (Bug #423455)

[Felipe Sateler]

Roberto C. Sánchez wrote:

> Well, the ~ character is stated to be evaluated to be less than the
> empty string.  If a package is the target of a security upload in
> stable, you can be certain that the testing/unstable version will also
> increase when the new package is introduced to fix the problem there as
> well.

What if it's a NMU?

-- 

  Felipe Sateler


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

Re: Bug Squashing Party -- May 17th - 20th

[Luk Claes]

David Claughton wrote:
> Martin Zobel-Helas wrote:
> 
>> where to find available RC bugs:
>>   http://bts.turmzimmer.net/details.php?ignore=sid&ignnew=on&new=5
> 
> I'm just curious - the "ignore=sid" part means exclude bugs that only
> affect sid, correct?  Which means bugs which affect lenny but are
> already fixed in sid are still included (I think).
> 
> Is it useful to have bugs already fixed in sid included in the list for
> BSP purposes?  I would have thought "bydist=both" would be more
> appropriate.

You might want to read the section Testing-only bugs at [0] on why lenny-only
bugs might also be interesting to fix.

Cheers

Luk

[0] http://people.debian.org/~vorlon/rc-bugsquashing.html


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

Building packages twice in a row

[Martin Zobel-Helas]

Hi,

as a QA effort the whole archive was rebuilt yesterday to catch
build-failures, whether a package can be build twice in a row (unpack,
build, clean, build). We found about 400 packages not having a sane
clean target. 

To cite
http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules

clean

This must undo any effects that the build and binary targets may
have had, except that it should leave alone any output files created
in the parent directory by a run of a binary target.

We started filing bugs to each effected package with severity important,
those can be found at 
http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED];tag=qa-doublebuild

Building twice is not yet a requirement, but will (hopefully) become
release goal for Lenny. 

Greetings
Martin


signature.asc
Description: Digital signature

Re: Debian desktop -situation, proposals for discussion and change. Users point of view.

[Mgr. Peter Tuharsky]

Raphael Hertzog  wrote / napísal(a):

On Tue, 15 May 2007, Mgr. Peter Tuharsky wrote:
Yes, bugs are unavoidable. However, testing is often in situation "whole 
system broken" or "nearly useless". I see difference here; occassional 
bug in desktop app is acceptable. Whole system unreliable is not acceptable.


Have you facts to assert this?


Just a personal experience.



I've been an happy user of testing. It happens that some packages are not
upgradable during a timeframe however the installed packages are not broken
and thus the system is perfectly reliable.


You can't just get the latest version and hope that it won't break
anything.
That should be verified in light of broad experience (I don't have any). 
Does it happen often that GNOME version change breaks many things? The 
only my try was to put GNOME 2.0 to Debian Woody (ugly GNOME 1.2), and I 
was succesful.


You can't generalize based on a single experience like that.


Yes, I admired that openly.

Your

restricted yourself to software published by the Gnome project. Check how
many applications depend on Gnome and yet are not developed following
Gnome's schedule. Those are the applications which have not been tested by
upstream with the new Gnome and which are the more likely to break.


Could we put more pressure on them to follow some rules? Make it 
compliant or be not released at all?

I'd expect that enterprise is already making pressure on this..



You can't rely on upstream to do this testing for you. We have a purpose,
we don't stabilize our distribution just because it sounds nice, it's
really needed in many cases.

Don't get me wrong however, I'm all in favor of having backports
integrated in Debian and make it a viable alternative for many users.
But you simply can't drop newer upstream version in what we call "stable"
like you suggest.


I respect Your opinion and probably You know what You're speaking about, 
however the interests should come to some balance (stability vs 
available labour force vs usability vs bug reporting vs security).


Maybe, there could be these levels in release cycle:
-stable (security fixes are backported, depending on popularity and 
demand the packages have)
-recent (tested, functional fresh packages, that could stable be 
upgraded by, w/o breaking deps, officially supported)

-testing (stabilisation playground for next libraries platform)
-unstable (new software packages)


Peter



We don't really need more discussion on that topic. We need improvements
to make that a realistic goal.

Cheers,



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

Re: Debian desktop -situation, proposals for discussion and change. Users point of view.

[Mgr. Peter Tuharsky]

Steve Greenland  wrote / napísal(a):
On 14-May-07, 07:55 (CDT), "Mgr. Peter Tuharsky" <[EMAIL PROTECTED]> wrote: 
Ask somebody, what distro would he install at desktop for novice or M$ 
refugee? Why many are choosing Ubuntu instead of Debian, and even worse, 
abandon Debian in favor of Ubuntu?


Why is this worse?


I wrote "worse" because for Debian, this is worse. Not that it is 
damaging it somehow. Of course there naturally will be other distros, 
cooperating hopefully.


It's "worse" because it implies, that Debian is not as good desktop as 
it ought to be.


Why isn't there room for two similar distributions,

with one aimed at being more up-to-date for a limited set of packages
and hardware, while the other aims at being rock-solid on a wide variety
of hardware for extended periods of time?


As I illustreted, "rock solid" is not automatically guaranteed by 
oldness of software or by length of pre-release testing. And for the end 
_desktop_ user, usability matters too. Sometimes even more than the age 
(I wouldn't tell "stability" because, again, this is not always the 
same). That's the first thing I think Debian is doing wrong, if it tries 
to be desktop distro too. The optimum is somewhere in between.




There are certainly ways that Debian can improve, but I'm not convinced
that "become more like Ubuntu" is one of them. Why not let Ubuntu
fulfill the desires of that group of users?


"More like Ubuntu" -by some means, we could learn much from them. 
However I don't suggest to become another Ubuntu.


There are partial approaches possible that could itself benefit Debian 
dekstop much. And in the Debian, other ways of applying changes than 
"step-by-step" I don't see even possible, does anybody? ;-)


We could start with programs that don't other programs depend on much. 
For example, what is the purpose of using 2 years old Firefox, 
Thunderbird, OpenOffice.org and other such stand-alone programs? They 
could be flawlessly upgraded during stable release life cycle. If "extra 
stability" or whatever is the mean, then let them be tested for a while 
(however, preferrably during _their_ testing phase).


Next, the bug reporting is completely flawed for desktop user, and in 
order to make it functional, the balance must be moved closer to the 
recent software versions. I don't see other way to do it. Does somebody? 
There is no choice but keeping Debian desktop user 
out-of-software-community for next years.


Third, bug reporting systems really needs some consolidation, and 
probably negotiations between distros and software vendors. It took too 
long to have LSB, and convergention of the bug reporting systems I see 
as the next step necessarry. And who could offer bigger authority than 
Debian, the greatest community-driven distro?



Peter



Steve



--
Odchádzajúca správa neobsahuje ví­rusy, nepou¾í­vam Windows.
===

Mgr. Peter Tuhársky
Referát informatiky
Mesto Banská Bystrica
ÈSA 26
975 39 Banská Bystrica

Tel: +421 48 4330 118
Fax: +421 48 411 3575

===


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