Re: Wanted: introductory page for all teams

[Raphael Hertzog]

On Wed, 30 May 2007, Josip Rodin wrote:
> Anyway, before we get lost in all this prediction stuff, I'm yet to hear
> a good reason why we need complete triviality in the access method, as
> opposed to the kind of triviality we have had for years now: all that is
> necessary to get webwml access is to send a mail to debian-www saying
> you've read some docs and you want access.

Because most people don't bother when they want to fix only a small
detail in a web page. Furthermore, the procedure to get www-acces is not
that clear... when I joined the group, I had to seriously dig in the
documentation to finally find a web page which wasn't even hosted on a
debian.org website at that time (Joey's page that apparently moved to
people.d.o in the mean time and that you have now listed in
http://wiki.debian.org/Teams/Webmaster).

Anyway, debian-cd when it was hosted in CVS used to have write access to
all Debian developers and it worked perfectly fine. The collab-maint
SVN repository is also writable by all DD and I haven't heard a single
complaint up to now.

So consider this a +1 for me to get write access to all DD by default in
our website. I would also like the project to move away from CVS and
use something more friendly that can effectively enable bigger changes
(because it handles renames at least).

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: BoF: Supporting 15,000 packages - How much support do we mean?

[Roberto C . Sánchez]

On Tue, May 29, 2007 at 07:46:34PM -0700, Steve Langasek wrote:
> 
> What evidence do you have that serious security bugs "won't get fixed" in a
> stable release because of MIA developers?  AFAIK, the burden of providing
> security updates largely falls on the shoulders of the security team, even
> in many cases where the maintainers are not MIA.
> 
AFAIK, most security bugs are never reported to MITRE or Secunia or the
like.  For most "smaller" projects, I would guess that that majority of
security bugs are fixed in the normal course of development without any
sort of special advisories, except perhaps in the changelog published by
upstream.  I think that it is entirely conceivable that there are many
latent security bugs in Debian resulting from just such situations,
where the maintainer is MIA and nobody is keeping tabs on upstream
development.  Of course, since the security team can't possibly monitor
upstream development for every package (even just those which don't have
active maintainers), we can't really know.

Regards,

-Roberto

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


signature.asc
Description: Digital signature

Re: checklib

[Manoj Srivastava]

Hi,
On Thu, 24 May 2007 20:26:00 +0200, A Mennucc <[EMAIL PROTECTED]> said: 

> hi what about http://rerun.lefant.net/checklib/ ?

> madcoder mentioned in
> http://lists.debian.org/debian-devel/2007/01/msg00822.htmlof the
> intention of getting the checklib service up again: any progress?

Most of the incantations of checklib did so on a per binary
 object basis -- which is useless in packages like fvwm, that have
 gazillions of plugins generated from the same CFLAGS in a global
 makefile. If some binary in a .deb needs it, a library can't be
 eliminated from build depends, so the lib minimization can't be done.

Has this been fixed in the latest incantation?

I ended up creating a checklib.sh that does the checking based
 on _all_ binary objects shipped in the package at one time; and this is
 what I use in my packages now.

 manoj

-- 
Is this TERMINAL fun?
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

cvs commit access to webwml files (Re: Wanted: introductory page for all teams)

[Bart Martens]

On Wed, 2007-05-30 at 09:06 +0200, Raphael Hertzog wrote:
> On Wed, 30 May 2007, Josip Rodin wrote:
> > Anyway, before we get lost in all this prediction stuff, I'm yet to hear
> > a good reason why we need complete triviality in the access method, as
> > opposed to the kind of triviality we have had for years now: all that is
> > necessary to get webwml access is to send a mail to debian-www saying
> > you've read some docs and you want access.
> 
> Because most people don't bother when they want to fix only a small
> detail in a web page. 

I agree with that.

> Furthermore, the procedure to get www-acces is not
> that clear... when I joined the group, I had to seriously dig in the
> documentation to finally find a web page which wasn't even hosted on a
> debian.org website 

I agree with that too.

But I did the effort of finding the procedure and asking for cvs commit
access to the webwml files.  To my surprise I got the access granted
within 24 hours.  And also to my surprise, editing the webwml files and
committing the changes is much easier than I expected.

> at that time (Joey's page that apparently moved to
> people.d.o in the mean time and that you have now listed in
> http://wiki.debian.org/Teams/Webmaster).

Well, feel free to give the procedure a more visible place in the
webwml-managed pages.

> 
> Anyway, debian-cd when it was hosted in CVS used to have write access to
> all Debian developers and it worked perfectly fine. The collab-maint
> SVN repository is also writable by all DD and I haven't heard a single
> complaint up to now.
> 
> So consider this a +1 for me to get write access to all DD by default in
> our website. 

I agree with giving cvs commit access to the webwml files to all DD's,
or, to encourage all DD's to request that access.

Regards,

Bart Martens


> I would also like the project to move away from CVS and
> use something more friendly that can effectively enable bigger changes
> (because it handles renames at least).
> 
> 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: BoF: Supporting 15,000 packages - How much support do we mean?

[paddy]

On Wed, May 30, 2007 at 03:15:59AM -0400, Roberto C. S?nchez wrote:
> On Tue, May 29, 2007 at 07:46:34PM -0700, Steve Langasek wrote:
> > 
> > What evidence do you have that serious security bugs "won't get fixed" in a
> > stable release because of MIA developers?  AFAIK, the burden of providing
> > security updates largely falls on the shoulders of the security team, even
> > in many cases where the maintainers are not MIA.
> > 
> AFAIK, most security bugs are never reported to MITRE or Secunia or the
> like.  For most "smaller" projects, I would guess that that majority of
> security bugs are fixed in the normal course of development without any
> sort of special advisories, except perhaps in the changelog published by
> upstream.  I think that it is entirely conceivable that there are many
> latent security bugs in Debian resulting from just such situations,
> where the maintainer is MIA and nobody is keeping tabs on upstream
> development.  Of course, since the security team can't possibly monitor
> upstream development for every package (even just those which don't have
> active maintainers), we can't really know.

you could estimate with sampling.

Regards,
Paddy


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

Re: Wanted: introductory page for all teams

[Josip Rodin]

On Tue, May 29, 2007 at 07:45:17PM -0400, Clint Adams wrote:
> > Anyway, before we get lost in all this prediction stuff, I'm yet to hear
> > a good reason why we need complete triviality in the access method, as
> > opposed to the kind of triviality we have had for years now: all that is
> > necessary to get webwml access is to send a mail to debian-www saying
> > you've read some docs and you want access.
> 
> I don't have a good reason, but for me it's the difference between
> contributing or not.  If I already have access and I get an itch, I will
> scratch it.  If I don't, I will either forget about it or complain.  I
> am unlikely to go through whatever bureaucracy is set up to request
> access.  Whether or not this is a loss for debian-www is not something I
> feel comfortable asserting.

This sounds a bit extreme. Would you at least be patient enough to file
a bug report or send an e-mail about the issue?

-- 
 2. That which causes joy or happiness.


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

Re: Wanted: introductory page for all teams

[Josip Rodin]

On Wed, May 30, 2007 at 09:06:06AM +0200, Raphael Hertzog wrote:
> Because most people don't bother when they want to fix only a small
> detail in a web page.

Well, when I want to fix a small detail in some other part of Debian,

I usually send a mail or file a bug, I don't automatically think that
I should get to do the change instantly. Yes, the web pages are "just"
documentation, but I honestly don't see a problem in having a maintenance
layer. I consider myself able to quickly edit most of the manual pages in
Debian packages (or whatever else is so simple in all packages), but
I don't think about doing NMUs, I let the other thousand people do MUs :)

That's as far as the philosophical aspect goes...

> Furthermore, the procedure to get www-acces is not
> that clear... when I joined the group, I had to seriously dig in the
> documentation to finally find a web page which wasn't even hosted on a
> debian.org website at that time (Joey's page that apparently moved to
> people.d.o in the mean time and that you have now listed in
> http://wiki.debian.org/Teams/Webmaster).

That's something they invented while I was on hiatus, I just noticed it
a few days ago... I agree it's another bit of overhead, but it's just a bit.

> I would also like the project to move away from CVS and
> use something more friendly that can effectively enable bigger changes
> (because it handles renames at least).

That would actually help work around the philosophical problems. If we had a
system which allowed finer-grained definitions of who gets to do what kind
of a commit (e.g. I don't want to let 1000 people have access to /index.wml
and you would probably understand why not), and one that helped translators
not lose track when there's a conflict in the source (ability to easily mark
revisions as not necessary to translate), that would make it easier to
implement a loosening in permissions.

-- 
 2. That which causes joy or happiness.


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

Re: Wanted: introductory page for all teams

[Steve Langasek]

On Wed, May 30, 2007 at 11:44:13AM +0200, Josip Rodin wrote:
> On Tue, May 29, 2007 at 07:45:17PM -0400, Clint Adams wrote:
> > > Anyway, before we get lost in all this prediction stuff, I'm yet to hear
> > > a good reason why we need complete triviality in the access method, as
> > > opposed to the kind of triviality we have had for years now: all that is
> > > necessary to get webwml access is to send a mail to debian-www saying
> > > you've read some docs and you want access.

> > I don't have a good reason, but for me it's the difference between
> > contributing or not.  If I already have access and I get an itch, I will
> > scratch it.  If I don't, I will either forget about it or complain.  I
> > am unlikely to go through whatever bureaucracy is set up to request
> > access.  Whether or not this is a loss for debian-www is not something I
> > feel comfortable asserting.

> This sounds a bit extreme. Would you at least be patient enough to file
> a bug report or send an e-mail about the issue?

If the issue in question is a typo?

When the effort involved in gaining access to the repo, or in informing
someone with access about the bug, is greater than the effort it takes to
actually fix the problem, I agree that tends to be a deterrent for me.
(This is true in general, not just in the case of the website.)  I don't
know if that's sufficient reason to change the perms on the repo; certainly,
most of my complaints about the website are in the area of site
organization, not minor content bugs.

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

Why do I get this mail? (was: [Archive Administrator] Processing of texlive-bin_2007-9_sparc.changes)

[Frank Küster]

Hi,

texlive-bin FTBFS two times previously because it's build-deps could not
be satisfied (libpoppler1 was on hold on spontini).  Now this seems to
have been fixed, and I'm wondering why I got the mail below?  It's not a
binary NMU, just a standard buildd upload, unless the NMUer got the
version wrong.  But one normally never gets those mails for buildd
uploads - what's going on?

TIA, Frank


--- Begin Message ---
texlive-bin_2007-9_sparc.changes uploaded successfully to localhost
along with the files:
  texlive-base-bin_2007-9_sparc.deb
  texlive-extra-utils_2007-9_sparc.deb
  texlive-font-utils_2007-9_sparc.deb
  texlive-metapost_2007-9_sparc.deb
  texlive-omega_2007-9_sparc.deb
  texlive-xetex_2007-9_sparc.deb
  texlive-music_2007-9_sparc.deb
  texlive-lang-indic_2007-9_sparc.deb
  libkpathsea4_2007-9_sparc.deb
  libkpathsea-dev_2007-9_sparc.deb

Greetings,

Your Debian queue daemon


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


--- End Message ---


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

Re: Why do I get this mail? (was: [Archive Administrator] Processing of texlive-bin_2007-9_sparc.changes)

[Steve Langasek]

On Wed, May 30, 2007 at 01:04:46PM +0200, Frank Küster wrote:
> texlive-bin FTBFS two times previously because it's build-deps could not
> be satisfied (libpoppler1 was on hold on spontini).  Now this seems to
> have been fixed, and I'm wondering why I got the mail below?  It's not a
> binary NMU, just a standard buildd upload, unless the NMUer got the
> version wrong.  But one normally never gets those mails for buildd
> uploads - what's going on?

It wasn't uploaded by a buildd; it was uploaded by Matthias Klose, who
didn't follow the standard for porter uploads as implemented by the buildds
and documented in the developer's reference.

-- 
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: Can/should debconf notes still be used?

[Frank Küster]

Steve Langasek <[EMAIL PROTECTED]> wrote:

>> Yes, we'll do it only once anyway.
>
> How do you plan to ensure that?  

Sorry, no plan, I was just dreaming.  Or deliring. 

> Since old versions of the tetex packages
> with the broken postrm are still in the wild, and a user may have already
> removed the tetex package but *not* purged it yet by the time fixed tetex
> packages became available, AFAICS any strategy that will make sure that the
> conffiles are only restored once (e.g., by only restoring the conffiles when
> upgrading from an older version of the texlive packages) will not be able to
> reliably fix this problem for all users.

Exactly.  And I think it's not worth the effort to do some weird "touch
/var/whatever" stuff which is error-prone again.  As long as Debian
packages of texlive-base require the presence of modes.mf to be
configured, and Debian packages of tl-base-bin require pdftexconfig.tex,
we simply restore it with the original content if we find it removed.

In case someone really wants to hack their system to not need the file
(and loose any support by us), they can just have a file with only
"%%\bye" or "\endinput" in it, respectively, which will of course
respected.

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

to join wmakerconf and wmakerconf-data packages

[Herbert P Fortes Neto]

 Hi,

 I am intending to adopt the wmakerconf and wmakerconf-data
debian packages. And I am now the new responsible of these
source packages.

 As does not exist a reason to have two source packages nowadays,
i joined wmakerconf source package and wmakerconf-data source
package in only one source package.

 I think it is also a good idea to join the wmakerconf and
wmakerconf-data debian packages. I would like to know if there is
a reason to not join wmakerconf debian package and wmakerconf-data
debian package in only one debian package. One package does not
work without the other package. If it is really a good idea i will
ask to remove the wmakerconf-data debian package from the repositories.



 []

--
Herbert Parentes Fortes Neto (hpfn)
Linux user number 416100
0x9834F79E -- http://pgp.mit.edu/



pgp9cuj4yIlwp.pgp
Description: PGP signature

Re: BoF: Supporting 15,000 packages - How much support do we mean?

[Enrico Zini]

On Tue, May 29, 2007 at 11:51:38PM +0100, Ben Hutchings wrote:

> think it would be a service to our users to grade how well supported
> packages are. I have a number of ideas for ways in which this could be
> done, but I think a discussion would yield something better that might
> eventually be accepted cover a whole release.
> So there will be a BoF at DebConf about this.

If you can boil down the grade to a number of categories, I can help in
feeding it to debtags.

I'll be at Debconf too, I'm curious to know what you have in mind.


Ciao,

Enrico

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


signature.asc
Description: Digital signature

Re: Wanted: introductory page for all teams

[Josip Rodin]

On Tue, May 29, 2007 at 08:15:08PM -0400, David Nusinow wrote:
> > > The only thing I've ever heard about helping out with the website is that
> > > it's a herculean task that no mere mortal should attempt.
> > 
> > Where did you hear this?
> 
> Word of mouth, usually in conjunction with promises that the site would be
> updated to not look like it came from the 90's and no visible improvements
> in that area. I'd heard about meetings at debconf/debcamps to work on this,
> and yet the site still looks almost identical to the way it did when I
> first downloaded Debian back in 1999. People said it was a big task, and if
> it was true then that would explain the lack of visible progress despite
> all the discussions.

Those kinds of things should be documented so that they can be discussed and
decided upon, otherwise it's just, well, chatter.

> > How does all that documentation we have had for years at
> > http://www.debian.org/devel/website/ in any way say or imply that
> > "helping out with the website is a herculean task that no mere mortal
> > should attempt"? How do all those relatively clueless translators who
> > simply know two languages manage to get things done? Are they all immortals?
> 
> Translation is fundamentally different than restructuring the website and
> bringing it up to modern standards. From what I understood, one of the
> reasons why it was so hard to restructure the site was because it was
> carefully set up for easy translation, making it tied to specific tools. I
> didn't care enough to investigate further.

The translators have to learn various intricate editing methods so that they
can update stuff: version control, WML syntax, various files with different
meanings and structures, template files, separate strings in po files, etc.
Occasionally they actually have to edit the right bits in pieces of Perl
code :) So I can't help but think that the knowledge they have to acquire is
not fundamentally different to the knowledge required for someone to take
the English parts of the web site and shuffle them around.

Again, it would help if people wishing to change the English version would
articulate their thoughts clearly. (As opposed to saying "all this you
have there should be deprecated".)

> > > I trivially had access, as does everyone else on the XSF, even non-DD's,
> > > making it incredibly easy to actually do work. As far as I'm concerned,
> > > the web site should be deprecated in favor of the wiki.
> > 
> > It's not trivially easy to do, therefore it sucks?
> > 
> > What's next in this fine line of reasoning, I wonder? It doesn't have
> > a MS Windows GUI that my granny thinks is trivial, therefore it sucks?
> 
> I don't consider my job in Debian to maintain the website. I consider my
> job to help maintain X. I've taken it upon myself to work on the XSF wiki
> pages because it's useful and important, but it's clearly a secondary
> concern to actually working on the software. Given this, anything that
> makes the job easier and more trivial so I can focus on what I consider to
> be important is a very valid reason.
> 
> I think that any tool that lets us do this should be considered. Debian
> isn't in the website creating business, we're in the Free Software
> Distribution creating business. If a tool, like a wiki, makes it
> substantially easier for us to go about that business then yes, I think we
> should use it.

The problem there is we can't just jump to the conclusion that that
particular tool is the right one for the job.

> > Can you please realize that this kind of unsubstantiated blather actually
> > hurts the feelings of the people who are making a good-faith effort to
> > keep the web site working?
> 
> I'm not trying to hurt anyone's feelings, nor am I trying to criticize
> anyone. I had heard that overhauling the website (not just keeping it
> working) was a big task, and that shouldn't be interpreted as heaping
> scorn on you or anyone else.

Well, maybe you didn't mean it that way, but the idea that all this current
work should just be deprecated in favour of some new thing doesn't seem very
kind.

Maybe it should, but all those man-hours that the hundreds of webwml
committers[1] have spent working on the problem should be acknowledged,
and all the good stuff must be carried over to the new solution,
regardless of the bad stuff which gets thrown out.

[1] currently there's 124 of us, over the years there were probably even more

-- 
 2. That which causes joy or happiness.


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

Re: cvs commit access to webwml files (Re: Wanted: introductory page for all teams)

[Josip Rodin]

On Wed, May 30, 2007 at 09:29:01AM +0200, Bart Martens wrote:
> But I did the effort of finding the procedure and asking for cvs commit
> access to the webwml files.  To my surprise I got the access granted
> within 24 hours.

Truth be told, you were reasonably lucky to get Matt's ACK and Joey's
adduser so quickly, but still, something reasonably similar to that
has happened every time for all those other people who asked.

> And also to my surprise, editing the webwml files and
> committing the changes is much easier than I expected.

So much for that scarecrow, eh? :)

It is reasonably easy, as it should be... it could be easier, yes,
but it's not a showstopper.

-- 
 2. That which causes joy or happiness.


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

Re: Wanted: introductory page for all teams

[Josip Rodin]

On Wed, May 30, 2007 at 03:15:31AM -0700, Steve Langasek wrote:
> > > If I already have access and I get an itch, I will scratch it.  If I
> > > don't, I will either forget about it or complain.  I am unlikely to go
> > > through whatever bureaucracy is set up to request access.  Whether or
> > > not this is a loss for debian-www is not something I feel comfortable
> > > asserting.
> 
> > This sounds a bit extreme. Would you at least be patient enough to file
> > a bug report or send an e-mail about the issue?
> 
> If the issue in question is a typo?

Well, yes, even then... I've seen people file bug reports on typos in
package documentation. Maybe it's a relatively large effort for such
a small gain, but it's not a really big issue.

> certainly, most of my complaints about the website are in the area of
> site organization, not minor content bugs.

Please feel free to voice them on the debian-www list or though the BTS
(the www.debian.org pseudo-package), and hopefully they can get fixed.

-- 
 2. That which causes joy or happiness.


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

Re: to join wmakerconf and wmakerconf-data packages

[Josip Rodin]

On Wed, May 30, 2007 at 08:56:29AM -0300, Herbert P Fortes Neto wrote:
>  I think it is also a good idea to join the wmakerconf and
> wmakerconf-data debian packages. I would like to know if there is
> a reason to not join wmakerconf debian package and wmakerconf-data
> debian package in only one debian package. One package does not
> work without the other package. If it is really a good idea i will
> ask to remove the wmakerconf-data debian package from the repositories.

The usual reason to have such a split is that one package is
architecture-dependent, and the other is architecture-independent.

When arch-indep data is split out, this conserves space on mirrors
(the same stuff doesn't get repeated into a dozen arch-dep packages).

In this particular case, the split sounds like an overkill.
wmakerconf is 320k, and wmakerconf-data is 50k.

-- 
 2. That which causes joy or happiness.


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

Re: Better documenting what does not work in Etch.

[Petter Reinholdtsen]

[Charles Plessy]
> Under the current policy, not all fixes to these problems would make it
> in a point release, but since the list is likely to grow longer and
> longer with time, I am really wondering if there is a better way to
> inform the users of that kind of issues, if possible a priori. Among the
> possibilities :
>
> - An Etch-centric view of the BTS (user friendly),
> - More updates to the release notes,
> - Documentation updates (BUGS section in the manpages)
>
> Other ideas ?

Very good points, and I believe you have a good point.  What about
making an errata wiki page for the etch release on
http://wiki.debian.org/>, and add links to the etch bugs in BTS?
It migth form the basis for updating packages and/or the release
notes.

Friendly,
-- 
Petter Reinholdtsen


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

Re: BoF: Supporting 15,000 packages - How much support do we mean?

[Jonas Meurer]

On 29/05/2007 Ben Hutchings wrote:
> There were some discussions on -private (and possibly here?) earlier in
> the year about quality vs quantity of packages.
> 
> [...]
> 
> I don't think we want to start grading maintainers and I believe there's
> a consensus that we should not be more selective about packages, but I
> think it would be a service to our users to grade how well supported
> packages are. I have a number of ideas for ways in which this could be
> done, but I think a discussion would yield something better that might
> eventually be accepted cover a whole release.

Publishing the date of last upload is a very useful information here,
especially if you need to choose an application out of several unknown
alternatives.
I would love to see the date of last upload published at
packages.debian.org at least.
A timestamp Field in every Package (which is automatically created at
build process) would be even better.

greetings,
 jonas


signature.asc
Description: Digital signature

Re: checklib

[Guillem Jover]

On Wed, 2007-05-30 at 02:19:33 -0500, Manoj Srivastava wrote:
> On Thu, 24 May 2007 20:26:00 +0200, A Mennucc said:
> > hi what about http://rerun.lefant.net/checklib/ ?
> 
> > madcoder mentioned in
> > http://lists.debian.org/debian-devel/2007/01/msg00822.htmlof the
> > intention of getting the checklib service up again: any progress?
> 
> Most of the incantations of checklib did so on a per binary
>  object basis -- which is useless in packages like fvwm, that have
>  gazillions of plugins generated from the same CFLAGS in a global
>  makefile. If some binary in a .deb needs it, a library can't be
>  eliminated from build depends, so the lib minimization can't be done.

I don't think it's completely useless, it is for the purpose of reducing
Build-Depends, but those plugins/programs are linking against stuff
they don't actually need, and those libraries are loaded w/o a reason.
Reducing run-time "bloat" is good as well, I'm willing to fix those bugs
on my packages and feed the fixes upstream!

> Has this been fixed in the latest incantation?

Please "fix" this by adding an additional mode/view, not replacing the
current one.

regards,
guillem


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

Bug#426723: ITP: libdata-serializer-perl -- module that serialize data structures

[Krzysztof Krzyzaniak (eloy)]

Package: wnpp
Severity: wishlist
Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]>


* Package name: libdata-serializer-perl
  Version : 0.41
  Upstream Author : Neil Neely <[EMAIL PROTECTED]>.
* URL : http://www.cpan.org/
* License : Perl: Artistic/GPL
  Programming Lang: Perl
  Description : module that serialize data structures

 Data::Serializer provides a unified interface to the various serializing
 modules currently available. Adds the functionality of both compression 
 and encryption.


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

Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core)
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/bash


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

Re: BoF: Supporting 15,000 packages - How much support do we mean?

[Pierre Habouzit]

On Wed, May 30, 2007 at 04:49:27PM +0200, Jonas Meurer wrote:
> On 29/05/2007 Ben Hutchings wrote:
> > There were some discussions on -private (and possibly here?) earlier in
> > the year about quality vs quantity of packages.
> > 
> > [...]
> > 
> > I don't think we want to start grading maintainers and I believe there's
> > a consensus that we should not be more selective about packages, but I
> > think it would be a service to our users to grade how well supported
> > packages are. I have a number of ideas for ways in which this could be
> > done, but I think a discussion would yield something better that might
> > eventually be accepted cover a whole release.
> 
> Publishing the date of last upload is a very useful information here,
> especially if you need to choose an application out of several unknown
> alternatives.
> I would love to see the date of last upload published at
> packages.debian.org at least.
> A timestamp Field in every Package (which is automatically created at
> build process) would be even better.

  This is one of many indications. I could cite many others, good or not
so good indicators:
  * size of the changelogs ;
  * number of revisions per upstream release ;
  * average age of bugs on the BTS ;
  * average time to answer to a bug from the maintainer ;
  * average number of new bugs in the week following new uploads ;
  * ...

  Not all this things are not very easy to use, take the number of
revisions per upstream release, it could either be that upstream
releases are not done very often, and that the maintainer does a good
job patching some upstream bugs, or that OTOH he's doing a poor job and
needs 10 uploads to get things right.


-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgplojcDfpGkh.pgp
Description: PGP signature

Re: BoF: Supporting 15,000 packages - How much support do we mean?

[Neil Williams]

On Wed, 30 May 2007 16:49:27 +0200
Jonas Meurer <[EMAIL PROTECTED]> wrote:

> Publishing the date of last upload is a very useful information here,
> especially if you need to choose an application out of several unknown
> alternatives.

That information is already available at packages.qa.d.o and linked
from packages.d.o via the Developer Information link - maybe that link
just needs to be more prominent?

However, I fail to see why a stable application that was released two
years ago should not be favoured to a potentially unstable application that
was released yesterday. The raw information of the last upload needs to
be tempered by the number of open bugs and the popcon score.

Come to think of it, something more like the fun stats that combine
various indicators in a calculation of 'karma'.

> I would love to see the date of last upload published at
> packages.debian.org at least.
> A timestamp Field in every Package (which is automatically created at
> build process) would be even better.

Time is a poor indicator of quality, whether it is the length of time in the 
archive (with regular uploads) or the length of time since the last upload.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpLwQrG93Z7e.pgp
Description: PGP signature

python, then C++, or C++ from the start?

[martin f krafft]

Dear colleagues,

I am starting to write netconf [0], finally. Or rather, I would if
I could settle on a language. If netconf is ever going to replace
ifupdown, it would need to have a low footprint and few
dependencies. This clearly suggests C/C++ as the language of choice.

0. http://netconf.alioth.debian.org

However, C/C++ make extreme programming rather difficult as it's
hard to make large-scale changes due to the strict typing and stuff
like lack of garbage collection or seamless exception handling. I am
not here to bash C/C++, but you might agree that high-level
languages such as Python are much better suited for mockup
implementations, when the overall structure and logic of a programme
is not yet set in stone.

Since I want netconf released early and often, and I'll be reusing
a lot of shell script logic at first, throwing stuff around until
the logical structure and type definitions are adequate, I am
considering starting first in Python and later, when it's All
Done(tm), port the application to C++.

I am a well-versed C++ coder and I know which things are possible in
Python but not in C++, so if I avoid those, this seems like
a possible approach.

But I am asking you still: can you think of anything to say against
such an approach? Please don't flame languages or anything of that
sort. The question is just: is it viable for a C++ coder with
a Python proficiency to mockup a new application in Python first?

Thanks for comments,

-- 
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
 
micro$oft encrypts your windows nt password when stored on a windows
ce device. but if you look carefully at their encryption algorithm,
they simply xor the password with "susageP", Pegasus spelled
backwards. Pegasus is the code name of windows ce. this is so pathetic
it's staggering.


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

Re: Better documenting what does not work in Etch.

[Javier Fernández-Sanguino Peña]

On Wed, May 30, 2007 at 04:33:59PM +0200, Petter Reinholdtsen wrote:
> Very good points, and I believe you have a good point.  What about
> making an errata wiki page for the etch release on
> http://wiki.debian.org/>, and add links to the etch bugs in BTS?
> It migth form the basis for updating packages and/or the release
> notes.

Actually, the website has errata pages for each release work at the wiki
could be a basis for an updated page at the website. The release notes should
document major changes not minor behaviour changes in the underlying system.

Regards

Javier


signature.asc
Description: Digital signature

Re: python, then C++, or C++ from the start?

[Michael Alan Dorman]

On Wed, 30 May 2007 17:34:10 +0200
martin f krafft <[EMAIL PROTECTED]> wrote:

> But I am asking you still: can you think of anything to say against
> such an approach? Please don't flame languages or anything of that
> sort. The question is just: is it viable for a C++ coder with
> a Python proficiency to mockup a new application in Python first?

Planning to write the application twice seems to me to presume more
time and continued enthusiasm than is perhaps realistic, especially
since your plans seem fairly ambitious---having to slog through the
last 10% of the application not once but twice seems masochistic.

Also, for the transition from the python to C/C++ versions to be smooth
enough to not penalize early adopters, it seems to me that they would
both have to have comprehensive test suites, otherwise you risk having
small incompatibilities.  Again, everyone's least favorite bits, done
twice.

It seems to me like your chances of real success would be greater if
you wrote it once in Python---which will be much more productive than
any C/C++---and then spent the time you would have spent rewriting it in
C/C++ lobbying to get python in base, which would probably make a lot
of other people very happy.

For that matter, figure out what other perl dependencies there are in
base, rewrite them all in python so that perl could be dropped from
base (as a way to bolster your argument) and you'll still probably be
done before you would writing the app twice.

Mike.


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

Re: checklib

[Manoj Srivastava]

On Wed, 30 May 2007 17:59:15 +0300, Guillem Jover <[EMAIL PROTECTED]> said: 

> On Wed, 2007-05-30 at 02:19:33 -0500, Manoj Srivastava wrote:
>> On Thu, 24 May 2007 20:26:00 +0200, A Mennucc said:
>> > hi what about http://rerun.lefant.net/checklib/ ?
>> 
>> > madcoder mentioned in
>> > http://lists.debian.org/debian-devel/2007/01/msg00822.htmlof the
>> > intention of getting the checklib service up again: any progress?
>> 
>> Most of the incantations of checklib did so on a per binary object
>> basis -- which is useless in packages like fvwm, that have gazillions
>> of plugins generated from the same CFLAGS in a global makefile. If
>> some binary in a .deb needs it, a library can't be eliminated from
>> build depends, so the lib minimization can't be done.

> I don't think it's completely useless, it is for the purpose of
> reducing Build-Depends, but those plugins/programs are linking against
> stuff they don't actually need, and those libraries are loaded w/o a
> reason.  Reducing run-time "bloat" is good as well, I'm willing to fix
> those bugs on my packages and feed the fixes upstream!

You do not understand the problem here; as the last incarnation
 I looked at, it was indeed completely useless for things like fvwm --
 since it worked on a binary by binary basis, instead of a per package
 basis. Since we do build depends on a package by package basis, looking
 at dependencies of individual binaries is not good enough. 

Say a package as bin-foo, bin-bar, and bin-baz. They build
 depend, respectively, on libfoo-dev, libbar-dev, and libbaz-dev,
 respectively.

When checklibs was run, it would report  
 libbar-dev, libbaz-dev, unneeded; looking at foo
 libfoo-dev,  libbaz-dev, unneeded; looking at bar
 libfoo-dev, libbar-dev, unneeded; looking at  baz

End result: Uneedded: libfoo-dev, libbar-dev, and libbaz-dev

Since that is patently wrong, the version of checklibs I looked
 at produced meaningless output -- for any package that had shared
 objects whose compile flags were not identical.

>> Has this been fixed in the latest incantation?

> Please "fix" this by adding an additional mode/view, not replacing the
> current one.


Er, why? I have a working version that works on a package basis,
 not on a binary by binary basis, and it was a few lines of simple shell
 scripting.  Also, if I recall correctly, the original script was in
 python.  I don't do python.

The original site where I got the old implementation
 (http://greek0.net/div/checklib.tar.gz) from is 404's now; the alioth
 checklib project has published nothing.  First rule of free software:
 publish early, publish often.

manoj

-- 
During the voyage of life, remember to keep an eye out for a fair wind;
batten down during a storm; hail all passing ships; and fly your colors
proudly.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: checklib

[Raphael Hertzog]

Hi Manoj,

On Wed, 30 May 2007, Manoj Srivastava wrote:
> When checklibs was run, it would report  
>  libbar-dev, libbaz-dev, unneeded; looking at foo
>  libfoo-dev,  libbaz-dev, unneeded; looking at bar
>  libfoo-dev, libbar-dev, unneeded; looking at  baz
> 
> End result: Uneedded: libfoo-dev, libbar-dev, and libbaz-dev
> 
> Since that is patently wrong, the version of checklibs I looked
>  at produced meaningless output -- for any package that had shared
>  objects whose compile flags were not identical.

What Guillem said is that checklib also indicated binaries which are
linked against a library without using any of its symbols. Thus the binary
shouldn't have been linked against it in the first place. That link has a
cost in "load time" that can be avoided.

checklib is still useful for this.

> The original site where I got the old implementation
>  (http://greek0.net/div/checklib.tar.gz) from is 404's now; the alioth
>  checklib project has published nothing.  First rule of free software:
>  publish early, publish often.

Aurélien Gérôme published a copy of the tarball he had:
http://www.roxor.cx/debian/checklib.tar.gz

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: python, then C++, or C++ from the start?

[Warren Turkal]

On Wednesday 30 May 2007 09:34, martin f krafft wrote:
> But I am asking you still: can you think of anything to say against
> such an approach? Please don't flame languages or anything of that
> sort. The question is just: is it viable for a C++ coder with
> a Python proficiency to mockup a new application in Python first?

A similar approach seems to have worked pretty well for git. I think that some 
of the core functionality was C with a lot of scripts for functionality. 
Slowly, a lot of the scripts have become C code.

It seems rational to allow the python and C/C++ code to work together so that 
you can transition from one to the other and aren't just strictly porting 
from one to the other at the "end" of the project.

wt
-- 
Warren Turkal


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

Re: python, then C++, or C++ from the start?

[martin f krafft]

also sprach Michael Alan Dorman <[EMAIL PROTECTED]> [2007.05.30.1816 +0200]:
> Planning to write the application twice seems to me to presume
> more time and continued enthusiasm than is perhaps realistic,
> especially since your plans seem fairly ambitious---having to slog
> through the last 10% of the application not once but twice seems
> masochistic.

It does. I was hoping someone else would do the porting. :)

> Also, for the transition from the python to C/C++ versions to be smooth
> enough to not penalize early adopters, it seems to me that they would
> both have to have comprehensive test suites, otherwise you risk having
> small incompatibilities.  Again, everyone's least favorite bits, done
> twice.

Well, comprehensive test suites they should have anyway. It's
absolutely not my least favourite bit after having read Kent Beck.

http://en.wikipedia.org/wiki/Test-driven_development

> It seems to me like your chances of real success would be greater
> if you wrote it once in Python---which will be much more
> productive than any C/C++---and then spent the time you would have
> spent rewriting it in C/C++ lobbying to get python in base, which
> would probably make a lot of other people very happy.

Well, depending on what Python I need, this may or may not be
possible. Then again, I should really aim for python-minimal, just
to make sure it *could* be ported to C++.

> For that matter, figure out what other perl dependencies there are
> in base, rewrite them all in python so that perl could be dropped
> from base (as a way to bolster your argument) and you'll still
> probably be done before you would writing the app twice.

debconf? adduser? No thanks. :)

-- 
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
 
windoze is the one-night-stand of operating systems;
you feel so cheap after having used it.


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

Re: checklib

[Manoj Srivastava]

On Wed, 30 May 2007 18:28:43 +0200, Raphael Hertzog <[EMAIL PROTECTED]> said: 

> Hi Manoj,
> On Wed, 30 May 2007, Manoj Srivastava wrote:
>> When checklibs was run, it would report libbar-dev, libbaz-dev,
>> unneeded; looking at foo libfoo-dev, libbaz-dev, unneeded; looking at
>> bar libfoo-dev, libbar-dev, unneeded; looking at baz
>> 
>> End result: Uneedded: libfoo-dev, libbar-dev, and libbaz-dev
>> 
>> Since that is patently wrong, the version of checklibs I looked at
>> produced meaningless output -- for any package that had shared
>> objects whose compile flags were not identical.

> What Guillem said is that checklib also indicated binaries which are
> linked against a library without using any of its symbols. Thus the
> binary shouldn't have been linked against it in the first place. That
> link has a cost in "load time" that can be avoided.

> checklib is still useful for this.

Hmm. The instances I find for this is where a bunch of binaries
 are created from the same source; and upstream has been lazy enough to
 not create custom CFLAGS/LDFLAGS for each binary, just setting up a
 common build flag set for the whole package; in which case yes, some
 binaries are linked against stuff they do not require.

While optimizing startup times is nice; it usually is not a
 priority; and it depends on how much of the upstream build system I
 would have to hack; and often the speed gained is not worth the effort
 (I tend not to optimize before determining whether it is needed).

Minimizing coupling between packages by minimizin the build
 dependencies of the _package_ is useful; and woth the effort; 

>> The original site where I got the old implementation
>> (http://greek0.net/div/checklib.tar.gz) from is 404's now; the alioth
>> checklib project has published nothing.  First rule of free software:
>> publish early, publish often.

> Aurélien Gérôme published a copy of the tarball he had:
> http://www.roxor.cx/debian/checklib.tar.gz

It is as I feared. Hundreds of lines of python; my simple little
 implementation is about 75 lines of shell with copyright notices and
 comments.  And I do not have to build depend on python to do a build
 time check of my library build dependencies.

If someone wants to port my simple shell scripts into gobs
 and gobs of python; they can get it from ./debian/common/checklibs
 files in any of my packages; and they can browse on arch.debian.org for
 easy access.

My simplistic implementation scratches the itch for minimizing
 build depends for my packages.  I am pretty sure I don't have the bells
 and whistles of the python implementation.


If you do take a look at my little shell implementation, have
 fun; and I would appreciate feedback.

manoj
-- 
teamwork, n.: Having someone to blame.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Is there a way to positively, uniquely identify which Debian release a program is running on?

[Kris Deugau]

I've been writing custom utilities and libraries for various systems at
work, and with one particular project recently it's become (more)
important to know exactly which Debian release it's running on (at some
stage or other between version-controlled-code and installed-"binary")
so that I don't try to call a missing binary or create a .deb that
requires a package that doesn't actually exist in the target dist.

(Apache's suexec is one particular example;  it's
/usr/lib/apache2/suexec2 on sarge, but /usr/lib/apache2/suexec on etch.
 I could solve that particular case with some hackery in one of several
possible places, but it's a little harder for things like package
dependencies that have to change a little between different releases or
distros.)

However, there doesn't seem to be any single, consistent,
doesn't-change-for-the-life-of-the-release, programmatically possible
(never mind *easy* just yet...) method to find out if I'm on Debian
sarge, etch, lenny, or some third-party Debian-derived distribution.
Nor does there seem to be any similar indicator to see if I'm on Debian
3.0, 3.1, 4.0, or whatever version list a third-party distro is up to
this week.  (Side note:  When is the number version of a new release
decided?)

On RHEL and derived distros, there's usually a file /etc/redhat-release
(sometimes renamed, but usually trivially enough that it can be found
with little trouble) containing both the distro code name and the
version number.  It may change a little on point releases, but it's
stable, consistent, and unique to each release.

Some searching turned up a suggestion to use the glibc version as a
reference...  which might be OK if there weren't so much overlap between
releases.  :(  (I checked woody, sarge, etch, and lenny.  There was
overlap between woody and *etch*, IIRC.  Ewww.)

-kgd


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

Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Stephen Gran]

This one time, at band camp, Kris Deugau said:
> On RHEL and derived distros, there's usually a file /etc/redhat-release
> (sometimes renamed, but usually trivially enough that it can be found
> with little trouble) containing both the distro code name and the
> version number.

The closest we ship is /etc/debian_version.  I use it for several
similar tests at work, you just need to keep a mental map between the
number and the version string.  If you can count lsb-release being
installed, that will give you more information, or you could just look
at the tests it performs to get an idea of how it distinguishes
releases.

Take care,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Nico Golde]

Hi,
* Kris Deugau <[EMAIL PROTECTED]> [2007-05-30 23:06]:
[...] 
> However, there doesn't seem to be any single, consistent,
> doesn't-change-for-the-life-of-the-release, programmatically possible
> (never mind *easy* just yet...) method to find out if I'm on Debian
> sarge, etch, lenny, or some third-party Debian-derived distribution.

> Nor does there seem to be any similar indicator to see if I'm on Debian
> 3.0, 3.1, 4.0, or whatever version list a third-party distro is up to
> this week.  (Side note:  When is the number version of a new release
> decided?)
> 
> On RHEL and derived distros, there's usually a file /etc/redhat-release
> (sometimes renamed, but usually trivially enough that it can be found
> with little trouble) containing both the distro code name and the
> version number.  It may change a little on point releases, but it's
> stable, consistent, and unique to each release.

/etc/debian_version

Kind regards
Nico
-- 
Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


pgpzgl56Gthuy.pgp
Description: PGP signature

Re: python, then C++, or C++ from the start?

[Robert Collins]

On Wed, 2007-05-30 at 17:34 +0200, martin f krafft wrote:
> Dear colleagues,

...
> But I am asking you still: can you think of anything to say against
> such an approach? Please don't flame languages or anything of that
> sort. The question is just: is it viable for a C++ coder with
> a Python proficiency to mockup a new application in Python first?


I think its entirely viable. boost::python is rather nice and should
allow incremental migration. You could if you care start with a C++
wrapper using boost:python where all the guts are in python, and then
its just a question of how much is pure c++ :).

Rob
-- 
GPG key available at: .


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

Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Santiago Vila]

Hi.

I believe there is something fundamentally wrong if you *have* to rely
on /etc/debian_version for anything. The number of Debian packages
actually using such file is probably zero (but I could be wrong).

Try using dependencies or run-time tests. Really.


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

Re: python, then C++, or C++ from the start?

[Oleg Verych]

>> But I am asking you still: can you think of anything to say against
>> such an approach? Please don't flame languages or anything of that
>> sort. The question is just: is it viable for a C++ coder with
>> a Python proficiency to mockup a new application in Python first?
>
> Planning to write the application twice seems to me to presume more
> time and continued enthusiasm than is perhaps realistic, especially
> since your plans seem fairly ambitious---having to slog through the
> last 10% of the application not once but twice seems masochistic.

Configuration of interfaces (hardware or software) is part of OS setup
and proper operation. And this task must be solved on the principle
basis, rather than jet-another-lang-flame. Once you have all
kernel/network-interfaces (ioctl, sysctl, dhcp clients, etc.)
realizations, why not just to start glue them? It's C/shell (or even
C/SLang) ifs-glue thing, as you've wrote in the wiki page and not C++/python.
IMHO it's far too away from ordinary application programming.

[]
> For that matter, figure out what other perl dependencies there are in
> base, rewrite them all in python so that perl could be dropped from
> base (as a way to bolster your argument) and you'll still probably be
> done before you would writing the app twice.

Somebody suggests to get rid of the bloated mammoth, debian so depends
on, interesting. I want to rewrite some base, that is really needed on
shell :)

> Mike.



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

Re: BoF: Supporting 15,000 packages - How much support do we mean?

[Ben Hutchings]

On Tue, 2007-05-29 at 19:46 -0700, Steve Langasek wrote:
> On Tue, May 29, 2007 at 11:51:38PM +0100, Ben Hutchings wrote:
> > There were some discussions on -private (and possibly here?) earlier in
> > the year about quality vs quantity of packages.
> 
> > It should be clear to most developers that our many packages are not all
> > equal in quality; nor are all maintainers. Not everyone is aware that
> > packages in a stable release may have serious known bugs - even security
> > bugs - that won't get fixed because of overstretched or MIA developers,
> > or lack of upstream support.
> 
> What evidence do you have that serious security bugs "won't get fixed" in a
> stable release because of MIA developers?

Search for "years" in
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag&data=security&archive=no&version=&dist=stable&pend-exc=fixed&pend-exc=done&include=security

> AFAIK, the burden of providing
> security updates largely falls on the shoulders of the security team, even
> in many cases where the maintainers are not MIA.

Security bugs in less popular packages generally do not get fixed
quickly, if ever, by the security team or the "testing security" team.
This is understandable; they have their hands full with the more popular
packages (and other responsibilities).

Ben.

-- 
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
   - Albert Einstein


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

Re: BoF: Supporting 15,000 packages - How much support do we mean?

[Bernd Zeimetz]

> AFAIK, most security bugs are never reported to MITRE or Secunia or the
> like.  For most "smaller" projects, I would guess that that majority of
> security bugs are fixed in the normal course of development without any
> sort of special advisories, except perhaps in the changelog published by
> upstream.  


if it is mentioned at all. Chance is good that projects, which do not
actively announce security issues, won't mention them in the changelogs.
Some people really think that fixing security bugs silently is better
than the "bad" publicity from an announcement.

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Re: BoF: Supporting 15,000 packages - How much support do we mean?

[Steve Langasek]

On Wed, May 30, 2007 at 09:38:16PM +0100, Ben Hutchings wrote:
> On Tue, 2007-05-29 at 19:46 -0700, Steve Langasek wrote:
> > On Tue, May 29, 2007 at 11:51:38PM +0100, Ben Hutchings wrote:
> > > There were some discussions on -private (and possibly here?) earlier in
> > > the year about quality vs quantity of packages.

> > > It should be clear to most developers that our many packages are not all
> > > equal in quality; nor are all maintainers. Not everyone is aware that
> > > packages in a stable release may have serious known bugs - even security
> > > bugs - that won't get fixed because of overstretched or MIA developers,
> > > or lack of upstream support.

> > What evidence do you have that serious security bugs "won't get fixed" in a
> > stable release because of MIA developers?

> Search for "years" in
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag&data=security&archive=no&version=&dist=stable&pend-exc=fixed&pend-exc=done&include=security

If I search on
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag;data=security;archive=no;dist=stable;pend-exc=fixed;pend-exc=done;include=security;severity=critical,grave,serious
(since the question was about "serious security bugs"), the only matches are
listed as "From other Branch", meaning that the versions listed as affected
in the BTS are not versions present in stable.

> > AFAIK, the burden of providing
> > security updates largely falls on the shoulders of the security team, even
> > in many cases where the maintainers are not MIA.

> Security bugs in less popular packages generally do not get fixed
> quickly, if ever, by the security team or the "testing security" team.

Example, please?

-- 
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: checklib

[Marc 'HE' Brockschmidt]

Manoj Srivastava <[EMAIL PROTECTED]> writes:
> On Wed, 30 May 2007 18:28:43 +0200, Raphael Hertzog <[EMAIL PROTECTED]> said: 
>> What Guillem said is that checklib also indicated binaries which are
>> linked against a library without using any of its symbols. Thus the
>> binary shouldn't have been linked against it in the first place. That
>> link has a cost in "load time" that can be avoided.
>>
>> checklib is still useful for this.
> Hmm. The instances I find for this is where a bunch of binaries
>  are created from the same source; and upstream has been lazy enough to
>  not create custom CFLAGS/LDFLAGS for each binary, just setting up a
>  common build flag set for the whole package; in which case yes, some
>  binaries are linked against stuff they do not require.

That is OK if all of the created binaries end up in the same binary
package. If not, you get (thanks to dpkg-shlibdeps) run-time
dependencies that are not needed, bloating the dependency tree and
dragging in more software than would be strictly needed.

This problem becomes worse by people copying over build systems from one
application to another, or using Makefile.am as a write-only file (ie
adding something whenever a new dep is created, but never removing
stuff). The usage of libtool and pkg-config combined with lazyness and
incompetence also adds to these problems. [1]

checklib is useful to detect such problems and works well. I have no
idea what gave you the idea that minimizing the build-depends line is
the point here - it simply isn't.

Marc

Footnotes: 
[1]  One of the uglier examples:
 http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html

-- 
BOFH #34:
(l)user error


pgp8jN2uKbfid.pgp
Description: PGP signature

Bug#426777: ITP: bouncy -- eat the yummy veggies in the garden - game for small kids

[Miriam Ruiz]

Package: wnpp
Severity: wishlist
Owner: Miriam Ruiz <[EMAIL PROTECTED]>


* Package name: bouncy
  Version : 0.0.20060925
  Upstream Author : Richard Jones <[EMAIL PROTECTED]>
* URL : http://www.pyweek.org/e/bouncy/
* License : GPL
  Programming Lang: Python
  Description : eat the yummy veggies in the garden - game for small kids

You play Bouncy the Hungry Rabbit. You're in a garden with yummy veggies and
a farmer who's not keen on you eating them. You can hide (and move
around) under the ground.

Bouncy was written so it could be enjoyed by the author's daughter, who was
about to turn 3, and by older gamers. Hence it's not a violent game and "easy"
is really, really easy, and "hard" is challenging.


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

Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Stefano Zacchiroli]

On Wed, May 30, 2007 at 04:46:30PM -0400, Kris Deugau wrote:
> However, there doesn't seem to be any single, consistent,

/etc/debian_version ?

Don't know when it was introduced though...

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[The Fungi]

On Wed, May 30, 2007 at 04:46:30PM -0400, Kris Deugau wrote:
[...]
> On RHEL and derived distros, there's usually a file /etc/redhat-release
> (sometimes renamed, but usually trivially enough that it can be found
> with little trouble) containing both the distro code name and the
> version number.
[...]

Not to be patronizing, but you are aware of the /etc/debian_version
file, yes?
-- 
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }


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

Re: BoF: Supporting 15,000 packages - How much support do we mean?

[Steve Greenland]

On 30-May-07, 10:24 (CDT), Pierre Habouzit <[EMAIL PROTECTED]> wrote: 
>   This is one of many indications. I could cite many others, good or not
> so good indicators:
>   * size of the changelogs ;

Older packages will skew this.

>   * number of revisions per upstream release ;

As you note, depends on upstream and overall stability of the package.
Consider, for example, nvi and cron.

>   * average age of bugs on the BTS ;

Older packages will skew this.

>   * average number of new bugs in the week following new uploads ;

Interesting, but really depends on expected stability of the package
and what the bugs are. I'm not sure the number, in and of itself, is
meaningful.

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]

Bug#426763: ITP: solr -- enterprise search server based on Lucene

[Jan-Pascal van Best]

Package: wnpp
Severity: wishlist
Owner: "Jan-Pascal van Best" <[EMAIL PROTECTED]>


  Package name: solr
  Version : 1.2.0
  Upstream Author : Bill Au, Doug Cutting, Bertrand Delacretaz, Otis 
Gospodnetic, Erik Hatcher, Chris Hostetter, Mike Klaas, Ryan McKinley, Yonik 
SeeleyName <[EMAIL PROTECTED]>
  URL : http://lucene.apache.org/solr/index.html
  License : Apache License; snowball: 3-clause BSD; easymock: MIT
  Programming Lang: Java
  Description : Enterprise search server based on Lucene


Solr is an open source enterprise search server based on the Lucene Java search
library, with XML/HTTP and JSON APIs, hit highlighting, faceted search, caching,
replication, and a web administration interface. It runs in a Java servlet
container such as Tomcat.

Solr features:
* Advanced Full-Text Search Capabilities
* Optimized for High Volume Web Traffic
* Standards Based Open Interfaces - XML and HTTP
* Comprehensive HTML Administration Interfaces
* Scalability - Efficient Replication to other Solr Search Servers
* Flexible and Adaptable with XML configuration
* Extensible Plugin Architecture
* A Real Data Schema, with Dynamic Fields, Unique Keys
* Powerful Extensions to the Lucene Query Language
* Support for Dynamic Faceted Browsing and Filtering
* Advanced, Configurable Text Analysis
* Highly Configurable and User Extensible Caching
* Performance Optimizations
* External Configuration via XML
* An Administration Interface
* Monitorable Logging
* Fast Incremental Updates and Snapshot Distribution

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (900, 'stable'), (300, 'testing'), (100, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-k7
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

Re: checklib

[Manoj Srivastava]

On Wed, 30 May 2007 22:58:38 +0200, Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> 
said: 

> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> On Wed, 30 May 2007 18:28:43 +0200, Raphael Hertzog
>> <[EMAIL PROTECTED]> said:
>>> What Guillem said is that checklib also indicated binaries which are
>>> linked against a library without using any of its symbols. Thus the
>>> binary shouldn't have been linked against it in the first
>>> place. That link has a cost in "load time" that can be avoided.
>>> 
>>> checklib is still useful for this.
>> Hmm. The instances I find for this is where a bunch of binaries are
>> created from the same source; and upstream has been lazy enough to
>> not create custom CFLAGS/LDFLAGS for each binary, just setting up a
>> common build flag set for the whole package; in which case yes, some
>> binaries are linked against stuff they do not require.

> That is OK if all of the created binaries end up in the same binary
> package. If not, you get (thanks to dpkg-shlibdeps) run-time
> dependencies that are not needed, bloating the dependency tree and
> dragging in more software than would be strictly needed.

This still implies that the tool should be working on a per
 package basis, not on a per binary basis.

> This problem becomes worse by people copying over build systems from
> one application to another, or using Makefile.am as a write-only file
> (ie adding something whenever a new dep is created, but never removing
> stuff). The usage of libtool and pkg-config combined with lazyness and
> incompetence also adds to these problems. [1]

> checklib is useful to detect such problems and works well. 

Hmm. We obviously differ on the definition of "well".  Anyway,
 if you want to use a per binary implementation, instead of a per
 package bit that can be  run at package build time as a sanity check,
 great.

What I find more useful is to look at all undefined symbols in
 all ELF objects in the tree, then look at all the libraries linked in;
 and see if there are some libraries that do not provide any of the
 undefined symbols -- for that would represent uneeded run time
 dependencies (_and_ unneeded build dependencies, in most of the cases I
 have dealt with).

Now optimizing the linkages of each individual binary might be
 also nice; but it does not affect build dependencies or run time
 dependencies; so I don't care to look at a per binary report.  In other
 words, if binary foo links with libfoo1; and binary bar links with
 libfoo1 and libbar1; all I care about is that there should be no
 spurious dependency on libbar1; ad not build dependency on libbar1-dev.

I don't really care if bar might or might not need to be linked
 with ibfoo1; since the package also contains a binary foo that needs to
 link with libfoo1 anyway -- all it means is that startup for bar would
 be imperceptibly slower, and does not drag in more software than needed.

manoj
-- 
During the Middle Ages, probably one of the biggest mistakes was not
putting on your armor because you were "just going down to the corner."
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: BoF: Supporting 15,000 packages - How much support do we mean?

[Ben Hutchings]

On Wed, 2007-05-30 at 16:48 -0700, Steve Langasek wrote:
> On Wed, May 30, 2007 at 09:38:16PM +0100, Ben Hutchings wrote:
> > On Tue, 2007-05-29 at 19:46 -0700, Steve Langasek wrote:
> > > On Tue, May 29, 2007 at 11:51:38PM +0100, Ben Hutchings wrote:
> > > > There were some discussions on -private (and possibly here?) earlier in
> > > > the year about quality vs quantity of packages.
> 
> > > > It should be clear to most developers that our many packages are not all
> > > > equal in quality; nor are all maintainers. Not everyone is aware that
> > > > packages in a stable release may have serious known bugs - even security
> > > > bugs - that won't get fixed because of overstretched or MIA developers,
> > > > or lack of upstream support.
> 
> > > What evidence do you have that serious security bugs "won't get fixed" in 
> > > a
> > > stable release because of MIA developers?
> 
> > Search for "years" in
> > http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag&data=security&archive=no&version=&dist=stable&pend-exc=fixed&pend-exc=done&include=security
> 
> If I search on
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag;data=security;archive=no;dist=stable;pend-exc=fixed;pend-exc=done;include=security;severity=critical,grave,serious
> (since the question was about "serious security bugs"), the only matches are
> listed as "From other Branch", meaning that the versions listed as affected
> in the BTS are not versions present in stable.


I'm sorry, I did not use "serious" in the precise sense of the BTS.  I
meant that there were bugs that could have serious consequences for some
users, which is true of many bugs with severity = important.  Also, this
release is relatively new and has had less time to accumulate bug
reports.  sarge is in a worse state.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou


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

http://utnubu.alioth.debian.org/scottish/ still used?

[Joachim Breitner]

Hi,

I am wondering if anyone still uses the re-ordered ubuntu patches
provided by the Utnubu team at

http://utnubu.alioth.debian.org/scottish/ 

If nobody finds this useful, I’d probably do the alioth admins a favor
if I stop the cronjob. 

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata

Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Javier Fernández-Sanguino Peña]

On Wed, May 30, 2007 at 10:12:38PM +0100, Stephen Gran wrote:
> The closest we ship is /etc/debian_version.  I use it for several
> similar tests at work, you just need to keep a mental map between the
> number and the version string.  If you can count lsb-release being
> installed, that will give you more information, or you could just look
> at the tests it performs to get an idea of how it distinguishes
> releases.

Only problem with /etc/debian_version is that you cannot distinguish testing
from sid and there's a timeframe (when base-files is updated, in which you
will confuse a 'sid' system with the next release). 

You can run 'lsb_release -a' a better estimate. Actually, it should be able
to cope derived distributions that have adapted /etc/lsb-release. The script
is provided by package lsb-release, but it's extra priority, so not bound to
be installed in most systems.

The script originally did not cope with the testing/unstable issue, see
#341231. Right now it should cope with most common cases but there might be
some weird situations in which it does not provide the correct answer. For
example: if a system's /etc/apt/sources.list is not properly configured,
if the system was installed ages ago with the 'testing' version of the
installer for the a current release (and has never been updated) or because
of weird setups (see #417145)

It also hardcodes the codename for testing, that's why bugs like #425646
popup just after a release.

I wonder if we should be shipping an /etc/lsb-release file? It was removed
from the lsb package (in 3.0-6, september 2005) but did not move over to
base-files...

Regards

Javier


signature.asc
Description: Digital signature

Re: BoF: Supporting 15,000 packages - How much support do we mean?

[Steve Langasek]

On Thu, May 31, 2007 at 01:58:02AM +0100, Ben Hutchings wrote:
> > > > What evidence do you have that serious security bugs "won't get fixed" 
> > > > in a
> > > > stable release because of MIA developers?

> > > Search for "years" in
> > > http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag&data=security&archive=no&version=&dist=stable&pend-exc=fixed&pend-exc=done&include=security

> > If I search on
> > http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag;data=security;archive=no;dist=stable;pend-exc=fixed;pend-exc=done;include=security;severity=critical,grave,serious
> > (since the question was about "serious security bugs"), the only matches are
> > listed as "From other Branch", meaning that the versions listed as affected
> > in the BTS are not versions present in stable.
> 

> I'm sorry, I did not use "serious" in the precise sense of the BTS.  I
> meant that there were bugs that could have serious consequences for some
> users, which is true of many bugs with severity = important.

But if that's the criterion, I don't see why anything more is needed than to
more visibly document to our users what classes of bugs are considered
release-critical.  Maintainer activity is not going to be strongly
correlated with frequency of non-RC security bugs in a package in stable.

> Also, this release is relatively new and has had less time to accumulate
> bug reports.  sarge is in a worse state.

Ok, can you provide an example to support this claim that sarge is worse?
If I sub 'oldstable' for 'stable' in the URL, I get a much *smaller* number
of outstanding RC security bugs for sarge, and only two of them are open for
longer than a year[1] (and less than two), which is of course not good, but
also not what you appeared to be claiming above.

I'm not saying that what the BTS shows in this view is at all accurate; I
think it's entirely possible that there are bugs missing here, since sarge's
release predates the advent of version tracking in the BTS, and even now
there's a good chance of new security bugs being filed with incomplete
v-t info.  I'm just asking that you support this claim with a concrete
pointer, because if there are known security bugs going unaddressed I'd like
to know what they are to try to understand why they've fallen through the
cracks and try to figure out if there's something we can be doing better to
catch such bugs as a class.

Roberto's point that low maintainer activity tends to correlate with
*unknown* security bugs is well taken, but you seem to be making the much
stronger claim that we *know* our stable releases have security holes that
will go unfixed, and this isn't something that I know at all.

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

[1] and one of these bugs is in libtasn1-0, a version of libtasn that
appears to have no reverse-dependencies in the archive (I think because the
security fix was ABI-breaking and therefore transitioned the reverse-deps
away from it), so the impact on end users is roughly nil.


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

Re: http://utnubu.alioth.debian.org/scottish/ still used?

[Gustavo Franco]

On 5/30/07, Joachim Breitner <[EMAIL PROTECTED]> wrote:

Hi,

I am wondering if anyone still uses the re-ordered ubuntu patches
provided by the Utnubu team at

http://utnubu.alioth.debian.org/scottish/

If nobody finds this useful, I'd probably do the alioth admins a favor
if I stop the cronjob.



Hi nomeata,

I agree with the cronjob stop.

Unfortunately, just a few from the swirl side of the fence are using
patches.ubuntu.com also. Bart (bartm) did a great job in terms of
reports[0] "engine" (I still believe that the UI needs tweak) and
people can identify what needs to be done from there.

[0] = http://wiki.debian.org/Utnubu

regards,
-- stratus
http://stratusandtheswirl.blogspot.com


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

Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Ben Hutchings]

On Wed, 2007-05-30 at 22:12 +0100, Stephen Gran wrote:
> This one time, at band camp, Kris Deugau said:
> > On RHEL and derived distros, there's usually a file /etc/redhat-release
> > (sometimes renamed, but usually trivially enough that it can be found
> > with little trouble) containing both the distro code name and the
> > version number.
> 
> The closest we ship is /etc/debian_version.  I use it for several
> similar tests at work, you just need to keep a mental map between the
> number and the version string.  If you can count lsb-release being
> installed, that will give you more information, or you could just look
> at the tests it performs to get an idea of how it distinguishes
> releases.

The command name is "lsb_release".  Its implementation is
distribution-specific.  Debian's reads APT policy and then
debian_version:

> def guess_debian_release():
> distinfo = {'ID' : 'Debian'}
> 
> kern = os.uname()[0]
> if kern in ('Linux', 'Hurd', 'NetBSD'):
> distinfo['OS'] = 'GNU/'+kern
> elif kern == 'FreeBSD':
> distinfo['OS'] = 'GNU/k'+kern
> else:
> distinfo['OS'] = 'GNU'
> 
> distinfo['DESCRIPTION'] = '%(ID)s %(OS)s' % distinfo
> 
> rinfo = guess_release_from_apt()
> if rinfo:
> release = rinfo.get('version')
> if release:
> codename = lookup_codename(release, 'n/a')
> else:
> release = rinfo.get('suite', 'unstable')
> if release == 'testing':
> # Would be nice if I didn't have to hardcode this.
> codename = TESTING_CODENAME
> else:
> codename = 'sid'
> distinfo.update({ 'RELEASE' : release, 'CODENAME' : codename })
> elif os.path.exists('/etc/debian_version'):
> release = open('/etc/debian_version').read().strip()
> if not release[0:1].isalpha():
> # /etc/debian_version should be numeric
> codename = lookup_codename(release, 'n/a')
> distinfo.update({ 'RELEASE' : release, 'CODENAME' : codename })
> else:
> distinfo['RELEASE'] = release
> 
> if 'RELEASE' in distinfo:
> distinfo['DESCRIPTION'] += ' %(RELEASE)s' % distinfo
> if 'CODENAME' in distinfo:
> distinfo['DESCRIPTION'] += ' (%(CODENAME)s)' % distinfo
> 
> return distinfo

lsb-release has Priority: extra so it's not that likely to be installed.
I've still doing distribution recognition by grepping
/etc/*-release /etc/release /etc/debian_version.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
- Robert Coveyou


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

Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Russ Allbery]

Ben Hutchings <[EMAIL PROTECTED]> writes:

> lsb-release has Priority: extra so it's not that likely to be installed.
> I've still doing distribution recognition by grepping
> /etc/*-release /etc/release /etc/debian_version.

lsb-release is quite nice when using facter (usually via Puppet), since it
uses lsb-release to fill out information that's handy to use in Puppet
rules.

Unfortunately, currently lsb-release Recommends: lsb, which then installs
the entire world (like apparently large chunks of Qt) if one uses the
default behavior of aptitude.  (Bug filed.)

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: BoF: Supporting 15,000 packages - How much support do we mean?

[Joey Hess]

Steve Langasek wrote:
> Ok, can you provide an example to support this claim that sarge is worse?

http://security-tracker.debian.net/tracker/status/release/oldstable
http://security-tracker.debian.net/tracker/status/release/stable

(You may want to grep for "high".)

> I'm not saying that what the BTS shows in this view is at all accurate; I
> think it's entirely possible that there are bugs missing here, since sarge's
> release predates the advent of version tracking in the BTS

The data above should be fairly accurate RE versions.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: checklib

[Guillem Jover]

On Wed, 2007-05-30 at 11:13:32 -0500, Manoj Srivastava wrote:
> On Wed, 30 May 2007 17:59:15 +0300, Guillem Jover said:
> > On Wed, 2007-05-30 at 02:19:33 -0500, Manoj Srivastava wrote:
> > > Has this been fixed in the latest incantation?

> > Please "fix" this by adding an additional mode/view, not replacing the
> > current one.
> 
> Er, why? I have a working version that works on a package basis,
>  not on a binary by binary basis, and it was a few lines of simple shell
>  scripting.  Also, if I recall correctly, the original script was in
>  python.  I don't do python.

Sorry, what I meant given that you were asking if that had been
"fixed" in that implementation, was that if that was to happen, the
current functionality be preserved and an additional view of the data
be added instead of replacing the current one. Not that you specifically
should fix it.

regards,
guillem


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

Re: Bug#422137: ITP: 455FE10422CA29C4933F95052B792AB2 -- l33t h4x0r numb3r

[Xavier Roche]

> This package contains the "09F911029D74E35BD84156C5635688C0" number.

The package should also contain the '455FE10422CA29C4933F95052B792AB2'
number, which is also a very cool number.


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

Re: http://utnubu.alioth.debian.org/scottish/ still used?

[Daniel Baumann]

Joachim Breitner wrote:
> I am wondering if anyone still uses the re-ordered ubuntu patches
> provided by the Utnubu team at

I'm too unimportant to be of any weight here, but I use them and it
would be sad if it is stopped.

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/


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

Re: python, then C++, or C++ from the start?

[martin f krafft]

also sprach Oleg Verych <[EMAIL PROTECTED]> [2007.05.31.0011 +0200]:
> Configuration of interfaces (hardware or software) is part of OS
> setup and proper operation. And this task must be solved on the
> principle basis, rather than jet-another-lang-flame. Once you have
> all kernel/network-interfaces (ioctl, sysctl, dhcp clients, etc.)
> realizations, why not just to start glue them? It's C/shell (or
> even C/SLang) ifs-glue thing, as you've wrote in the wiki page and
> not C++/python. IMHO it's far too away from ordinary application
> programming.

While I fundamentally agree with you, shell is also a major PITA and
there are even more pitfalls than with C. Add to that a lack of
proper debugging tools and you'll understand my tendency for a real
language.

I should clarify that I am looking only at the core daemon right
now, and maybe the configuration/policy parser. The methods, which
are the actual workers doing the configuring will most certainly be
implemented in shell.

-- 
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
 
after you install windows xp, you have the option to create user
accounts. if you create user accounts, by default, they will have an
account type of administrator with no password. way to go!


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

Re: python, then C++, or C++ from the start?

[martin f krafft]

also sprach Robert Collins <[EMAIL PROTECTED]> [2007.05.31.0021 +0200]:
> I think its entirely viable. boost::python is rather nice and should
> allow incremental migration. You could if you care start with a C++
> wrapper using boost:python where all the guts are in python, and then
> its just a question of how much is pure c++ :).

I know of at least one person who'd kill me if I used boost for
netconf. But as a migrational strategy, this isn't bad, although my
experience has been that you don't use boost, it uses you. Or
rather, you need to cater your application for boost, despite all
the generic programming it does.

-- 
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
 
Most Intelligent Customers Realise Our Software Only Fools Them.


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