Re: Removing the manpage requirement for GUI programs?

[Tollef Fog Heen]

]] Josselin Mouette 

| In my opinion, we’d be better off with no manual page than with one
| that is not maintained correctly. However the current policy
| encourages shipping a buggy manual page over not shipping it at all.

Would a reasonable compromise be to ship a man page that says something
along the lines of

  this is program $foo, it's used for task A, B, C, please see
  /usr/share/doc/$foo/html or yelp:$foo for the real documentation.
  Also, see $foo --help for help on command line switches.

It's still an effort to create those pages, but the description of what
a program does should change seldom and it keeps apropos(1) and similar
tools useful.

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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87635hzv8b@qurzaw.linpro.no

Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda

[Paul Wise]

On Sat, 2010-02-27 at 23:59 +0200, Faidon Liambotis wrote:

> I'm a member of pkg-wpa-devel and I've been sponsoring Kel for almost 4
> years. I have absolute trust in him and I've even offered to advocate
> him to the NM process multiple times.

I'd definitely agree with your assessment here and would also encourage
Kel to apply for NM.

> I'd be happy to review and sponsor the uploads of crda/wireless-regdb,
> if Paul doesn't have a problem with this.

Definitely no problem there.

> I usually prefer team maintenance, so I think it'd be best if this
> happened in pkg-wpa; my offer to sponsor is independent of that, though.

Agreed, whoever wants to help maintain this should join pkg-wpa.

So, summary of the main issues with Kel's current package:

He doesn't have time to maintain it and needs folks to join pkg-wpa,
take ownership of the crda RFP (#536502) and work to get both crda and
wireless-regdb uploaded.

It combines crda & wireless-regdb into one source package. While
upstream keeps them separate, we should do the same.

A few other issues that are easy to fix:

http://lists.debian.org/debian-kernel/2010/02/msg00336.html

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Removing the manpage requirement for GUI programs?

[Ben Finney]

Josselin Mouette  writes:

> Yes, I overall agree with your arguments. However having it in the
> policy means we get bug reports about manual pages and have to deal
> with them, while they are not the primary source of documentation for
> command-line options.

If manpages were useful only for documenting command-line options, this
would be a valid point. As has been pointed out, though, manpages for
programs are useful for much more than that.

> In my opinion, we’d be better off with no manual page than with one
> that is not maintained correctly. However the current policy
> encourages shipping a buggy manual page over not shipping it at all.

This is a problem, yes, I hadn't thought about it that way. Thank you.

So is it feasible to instead come up with a phrasing that encourages
full up-to-date manpages, but doesn't encourage keeping out-of-date
manpages?

-- 
 \  “Software patents provide one more means of controlling access |
  `\  to information. They are the tool of choice for the internet |
_o__) highwayman.” —Anthony Taylor |
Ben Finney


pgpIZtgxh36B3.pgp
Description: PGP signature

Re: Removing the manpage requirement for GUI programs?

[Javier Barroso]

2010/2/27 Josselin Mouette :
> Hi,
>
> currently policy §12.1 mandates that “each program, utility, and
> function should have an associated manual page”. However, the more I
> stomp on bug reports about manual pages, the less I am convinced of
> their usefulness for GUI programs.
>
> GUI applications usually take only a few simple command-line options,
> and more importantly, when you use a modern development framework, these
> options will always be documented correctly with the --help switch.
> Manual pages, OTOH, are not maintained properly by upstream developers.
>
> I think it is a waste of time to write manual pages that won’t be
> maintained upstream, and that won’t contain more useful information than
> --help. The purpose of a manual page is to document precisely the
> behavior of a program, and for GUI applications there is usually an
> associated GUI documentation instead.
>
> Therefore I propose that we drop the requirement of a manual page if
> these conditions are met:
>      * the program requires graphical interaction with the user, and is
>        not meant to be used from a script;
>      * the command-line switches are properly documented with a --help
>        option.
>
> For extra points, we could agree on a way to generate manual pages
> automatically, either at installation time or on the fly, using
> help2man.
>
> Any comments before I submit a bug against the policy?
As debian user, I really hate when I find a command which I don't know
what is and doesn't have man page. I think this happens to me in other
distributions more than in debian.

I think, at least a description should be provided. Obviously there
are GUI programs which their names give you clues about them, but
others, like "baobab" not. Imagine programs like baobab without any
manpage, It is hard to launch a program if you don't know about what
it's going to do. It is safe to launch any program if you can read
about it before.

Thank you very much


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/81c921f31002271615j8a1ba1ficcf47c2c8f1b3...@mail.gmail.com

Re: Removing the manpage requirement for GUI programs?

[Ben Finney]

"brian m. carlson"  writes:

> On Sat, Feb 27, 2010 at 08:06:37PM +0100, Josselin Mouette wrote:
> > Therefore I propose that we drop the requirement of a manual page if
> > these conditions are met: 
> >   * the program requires graphical interaction with the user, and is
> > not meant to be used from a script; 
> >   * the command-line switches are properly documented with a --help
> > option.
>
> A manual page contains more information than just command line
> switches. For example, iceweasel's manpage contains information about
> environment variables and files that it uses.

Agreed, this is very useful information for any program regardless of
its UI.

The argument about upstream failing to maintain manpages is not specific
to GUI programs (there are plenty of text-based programs whose upstream
developers don't care about a manpage), so even if this requirement were
to be relaxed I don't see what's special about the GUI aspect.

> --help output is for the case where you already are intimately
> familiar with the program and what it does, and need a quick reminder,
> or for cases when manpages are not available (emergency single-user
> boot).

Exactly. The purposes of ‘foo --help’ are quite different from ‘man 1
foo’, and having one does not obviate the need or usefulness of the
other.

-- 
 \ “Wrinkles should merely indicate where smiles have been.” —Mark |
  `\Twain, _Following the Equator_ |
_o__)  |
Ben Finney


pgptXfnF7P6VS.pgp
Description: PGP signature

Re: Intent to remove waf from Debian

[Ben Finney]

Luca Falavigna  writes:

> after some time spent to reflect and discuss, I think we reached a
> point of no return regarding waf package in Debian. I try to summarize
> what happened in the past months.

Thanks very much for responsibly working to make this package behave
well with the Debian system and to work with upstream. It's a pity
upstream was uncooperative with these goals.

> As a personal note, I discourage using waf as build system of choice:
> during these months I realized waf introduces backward incompatible
> changes every releases, this can lead to build failures very
> frequently. Sticking with older releases is the suggested solution by
> upstream, but may expose to bugs fixed in newer releases only.

Indeed, this kind of thinking — bundling third-party code with one's
application and resisting efforts to de-couple for lower code
duplication/divergence and maintenance effort — seems to be
disproportionately high with many developers of Python code in
particular (certainly not all, and probably not even a majority; but
enough to be a problem). I don't know what the origin is, but it's
frustrating to see it repeated.

It will be a shame to lose ‘waf’, which might over time have become a
good option for a flexible, reliable build system. It seems the current
developers don't want that though, so I think your choice is correct.

-- 
 \ “If we don't believe in freedom of expression for people we |
  `\   despise, we don't believe in it at all.” —Noam Chomsky, |
_o__)   1992-11-25 |
Ben Finney


pgpnx98lT2afF.pgp
Description: PGP signature

Re: Removing the manpage requirement for GUI programs?

[Don Armstrong]

On Sun, 28 Feb 2010, Josselin Mouette wrote:
> However having it in the policy means we get bug reports about
> manual pages and have to deal with them, while they are not the
> primary source of documentation for command-line options.

I'd hope you'd still get bug reports even if it wasn't in policy.[1] I
know I've filed them for packages that I find have inadequate or
missing manpages when I actually go looking for the documentation.

> In my opinion, we’d be better off with no manual page than with one that
> is not maintained correctly. However the current policy encourages
> shipping a buggy manual page over not shipping it at all.

If the manpage is wrong, I think it'd be worse than not shipping one.
If it's merely incomplete, and references something that is complete,
that's better than nothing. At least you get a reference to where you
should be looking at.

What'd be ideal in these cases is to get the manpages present
upstream, and to integrate them more tightly into the upstream's
documentation, so that upstream updates them when they change command
line options.


Don Armstrong

1: If someone is filing bugs for packages which are missing manpages
when they've never actually wanted to look at the manpage, that's
pathetic. Sure, it may be a bug, but why file a bug when you'll never
notice if it's fixed?
-- 
I may not have gone where I intended to go, but I think I have ended
up where I needed to be.
 -- Douglas Adams _The Long Dark Tea-Time of the Soul_

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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100227235258.gm28...@volo.donarmstrong.com

Re: Removing the manpage requirement for GUI programs?

[Russ Allbery]

Josselin Mouette  writes:

> Yes, I overall agree with your arguments. However having it in the
> policy means we get bug reports about manual pages and have to deal with
> them, while they are not the primary source of documentation for
> command-line options.

> In my opinion, we’d be better off with no manual page than with one that
> is not maintained correctly. However the current policy encourages
> shipping a buggy manual page over not shipping it at all.

I think that's a bit of a reach.  That may be how some of your bug
reporters are interpreting Policy, but Policy doesn't say anything about
what bugs are more severe.  I don't think attributing that position to
Policy is entirely fair.

I agree with you that badly out-of-date man pages can be worse than no man
pages at all and it's a question of balancing two bugs, something that
package maintainers often have to do.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/873a0mkzxo@windlord.stanford.edu

Bug#571788: ITP: geographiclib -- A C++ library to manage some geodesic transformations and problems

[Francesco P. Lovergine]

Package: wnpp
Severity: wishlist
Owner: "Francesco P. Lovergine" 

* Package name: geographiclib
  Version : 1.1
  Upstream Author : Charles Karney et al.
* URL : http://geographiclib.sourceforge.net/
* License : LGPL
  Programming Lang: C++
  Description : A C++ library to manage some geodesic transformations and 
problems

GeographicLib is a a small set of C++ classes for converting between
geographic, UTM, UPS, MGRS, geocentric, and local cartesian coordinates,
for geoid calculations, and for computing geodesic. It is a suitable
replacement for the core functionality provided by NGA Geotrans.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100227233745.14383.27522.report...@gandalf.is-a-geek.org

Re: Removing the manpage requirement for GUI programs?

[Josselin Mouette]

Le samedi 27 février 2010 à 15:30 -0800, Don Armstrong a écrit : 
> If the manpage doesn't contain any more information than the help
> output, then it probably should be replaced with help2man so that it
> stays up to date.
> 
> The crux of your argument is that for many GUI programs, manpages
> aren't as essential as other forms of documentation, and developer
> time would be better spent doing making other improvements.
> 
> Policy deals with this correctly by the manpage requirement as a
> should requirement. It's a bug when the manpage doesn't exist, but
> it's not RC. For some packages, it may not be a bug that can be
> properly fixed due to developer-availability and upstream awareness.
> 
> I think you'd agree that manpages that were always up-to-date would be
> nice for every thing in Debian would be nice, if only we had enough
> time to make it all happen.

Yes, I overall agree with your arguments. However having it in the
policy means we get bug reports about manual pages and have to deal with
them, while they are not the primary source of documentation for
command-line options.

In my opinion, we’d be better off with no manual page than with one that
is not maintained correctly. However the current policy encourages
shipping a buggy manual page over not shipping it at all.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Bug#571785: ITP: noko-fsoraw -- FSO resource allocation wrapper

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: noko-fsoraw
* URL : 
http://sourceforge.net/apps/mediawiki/noko/index.php?title=Fsoraw
* License : GPL-3+
  Description : FSO resource allocation wrapper

fsoraw (FSO Resource Allocation Wrapper) is a wrapper utility to launch
applications preallocating system resources from FSO.

Under normal circumstances Freerunner has resources (bt, wifi,
etc.) disabled to save power, FSO has a set of DBUS api to
allocate/release resources dinamically.

For applications that does not honour FSO you have to manually force
resource policy, launch the application, wait for the job done, reset
the resource policy.

There are some gui applications that let the user switch resource
policy but this need the user switches menus, clicks and so on, and may
be boring and slow, and sometime dangerous (suppose to be in car and
want to switch autodimming/suspending off, launch navigation software,
reset autodimming/suspending).



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100227233114.9112.47503.report...@toshiba.siemens

Re: Removing the manpage requirement for GUI programs?

[Don Armstrong]

On Sat, 27 Feb 2010, Josselin Mouette wrote:
> The current situation is that there are a lot of outdated and/or
> inaccurate manpages, while the --help output contains the same amount of
> information and is guaranteed to be up-to-date.

If the manpage doesn't contain any more information than the help
output, then it probably should be replaced with help2man so that it
stays up to date.

The crux of your argument is that for many GUI programs, manpages
aren't as essential as other forms of documentation, and developer
time would be better spent doing making other improvements.

Policy deals with this correctly by the manpage requirement as a
should requirement. It's a bug when the manpage doesn't exist, but
it's not RC. For some packages, it may not be a bug that can be
properly fixed due to developer-availability and upstream awareness.

I think you'd agree that manpages that were always up-to-date would be
nice for every thing in Debian would be nice, if only we had enough
time to make it all happen.


Don Armstrong

-- 
The smallest quantity of bread that can be sliced and toasted has yet
to be experimentally determined. In the quantum limit we must
necessarily encounter fundamental toast particles which the author
will unflinchingly designate here as "croutons".
 -- Cser, Jim. Nanotechnology and the Physical Limits of Toastability.
AIR 1:3, June, 1995.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100227233049.gl28...@volo.donarmstrong.com

RE: Removing the manpage requirement for GUI programs?

[Josselin Mouette]

Le samedi 27 février 2010 à 20:14 +, Fuentes, Adolfo a écrit :
> I think it is a good idea to have a centralized system where one can
> find information about a particular program. Otherwise we take the
> risk of having a sparse information system. If help2man helps to
> create the man page from the program help, which is the burden then?

Thank you for volunteering to write and maintain the tools to do that
automatically. Your help is much appreciated.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: Removing the manpage requirement for GUI programs?

[Josselin Mouette]

Le samedi 27 février 2010 à 20:29 +, brian m. carlson a écrit : 
> lakeview ok % gcalctool --help
> Usage:
>   gcalctool - Perform mathematical calculations

> Tell me what user files gcalctool may access, using only this
> information.  Also tell me, using *only the information provided*, how
> to force GTK+ to make all X calls synchronous.  You can't, because that
> information is not provided in the --help output.
> 
> In the latter case, --help-all might be useful, but the output is not
> sufficient, and so the package would, according to your proposed
> standard, need a manpage, or to be patched to make --help work like
> --help-all.  In the former case, the information is not provided at all,
> except in the manpage.

This is where you are wrong. The manual page is incorrect and does not,
as you might think, describe all files gcalctool might access. Actually,
the .gcalctoolrc file that is described in the manual page is an ancient
artifact that has close to 0 use.

> Furthermore, gcalctool can be scripted with -s, and the --help output
> does not describe the syntax: is it infix? postfix? How do you express
> powers?  Must powers be integers?  What precision is available?  The
> manpage does not either, but that is a bug in the manpage.  That
> information should not be present in the --help output.  It is entirely
> too long.

The information is in the HTML documentation. Are you going to duplicate
that information too, and introduce a new way for the documentation to
be out of sync?

> Maybe I'm the exception, but I end up running a lot of graphical
> programs from the command line.  When I'm building PDFs, I generally run
> evince from the command line.  I often use wireshark from the command
> line.  And those are just two from the top of my head.

And do you often read evince’s manual page?

> I'm happy to write or update manual pages, if needed.  If you provide a
> list of those that need work, I'll start working on them, so don't think
> I'm just a naysayer that wants to push off work on others.

Sorry but I think this would be a waste of time. There are real bugs to
fix instead of working on manual pages. First you would only repeat what
can be found in --help, since there’s nothing more to say about most GUI
programs. Then, once you would have written them, they’d need to be
forwarded, and more importantly you’d need to ensure at *every major
release* that they are still in sync.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: Xen, Squeeze, and Beyond

[Josip Rodin]

On Sun, Feb 28, 2010 at 01:03:46AM +0300, William Pitcock wrote:
> There are also no pvops dom0 kernel packages shipped by Debian yet, at
> least through official channels.
> 
> While you are correct that pvops is the future, right now it's no better
> reliability-wise then the 2.6.18 xensource patches... unfortunately tracking
> these reentrancy bugs (mostly deadlocks) down is a massive pain in the ass.

Much of the discussion was with regard to squeeze, and with that in mind,
at this point it seems that the pvops branch should get there, but there
is currently no indication whatsoever that the old stable branch will.
I'm not getting in the discussion why or how that is, I'm just saying,
based on:
http://lists.debian.org/debian-kernel/2009/10/msg00853.html
http://lists.debian.org/debian-kernel/2010/02/msg01290.html

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100227225433.ga26...@orion.carnet.hr

Re: offering for adoption: newLISP interpreter

[Ben Hutchings]

On Sat, 2010-02-27 at 13:50 -0800, Ted Walther wrote:
[...]
> I was told there is time to get this into squeeze.  It has been
> extensively debugged and tested on 64bit and 32bit platforms, and on
> every architecture that Debian supports.
[...]

That would be a big change from your earlier uploads, if true.  In any
case, the proper way to request a new package is with 'reportbug wnpp'.

Someone already had the idea though they didn't get very far with it:
.

Ben.

-- 
Ben Hutchings
Horngren's Observation:
   Among economists, the real world is often a special case.


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

Re: Removing the manpage requirement for GUI programs?

[Thilo Six]

Josselin Mouette wrote the following on 27.02.2010 21:03

--  --

> Indeed it is not sufficient for gcc-4.4. But I still think it is
> sufficient for gcalctool.

I have just downloaded the lenny gcalctool_5.22.3-2_i386.deb.
Where in /usr/share/gnome/help/gcalctool do you read about the file
"~/.gcalctoolrc" as you can in man 1 gcalctool?

Being able to diagnose and understand a programm even with no running X
sometimes is vital for a systems health.

-- 
bye Thilo

4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6  7C18 89A4 A2A0 C70B 1A8F


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/hmc7cp$8i...@dough.gmane.org

Re: Xen, Squeeze, and Beyond

[William Pitcock]

- "Josip Rodin"  wrote:

> On Sat, Feb 27, 2010 at 01:23:07AM +0300, William Pitcock wrote:
> > I am looking into packaging xenner already as a backup plan if I
> cannot
> > manage to fix some major reentrancy problems in the Xen dom0 code
> > (Xensource 2.6.18 patches, the pvops stuff has it's own share of
> problems
> > and needs more evaluation).
> 
> The .18 dom0 patches are well on their way out from the perspective
> of
> both Debian and Xen upstream, so you might want to shift focus to the
> pvops
> branch instead.

I am well aware of that.  However, the pvops branch has several critical
bugs:

- On a 8-way system, it reports 259GHz CPUs for all cores when booted under
Xen;
- The paravirtualized clock is 4 times slower then it should be in dom0
mode;
- The same reentrancy issues exist, as the pvops work is mostly Jeremy
forward porting the 2.6.18 code; a workaround is to dedicate one CPU core
to dom0 operations and pin it.

There are also no pvops dom0 kernel packages shipped by Debian yet, at
least through official channels.

While you are correct that pvops is the future, right now it's no better
reliability-wise then the 2.6.18 xensource patches... unfortunately tracking
these reentrancy bugs (mostly deadlocks) down is a massive pain in the ass.

William


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/23012901.2831267308226442.javamail.r...@ifrit.dereferenced.org

Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda

[Faidon Liambotis]

Luis R. Rodriguez wrote:
> As per Paul Wise' advice I'd like to request for help with the
> crda/wireless-regdb package for Debian for the next release of Debian.
> I am the upstream crda maintainer and John Linville is the upstream
> wireless-regdb maintainer. Kel Modderman has already done most work
> required for the Debian package, if not all. What we now need is some
> Debian Developer to be willing to either upload the package as-is, or
> some help from some experienced package maintainers to address a few
> items. I should note Paul Wise has offered sponsorship for this
> package so I think we are on the last track to getting this package
> finalized and/or uploaded but he just noted a few changes required.
> 
> Summary of review with Paul Wise:
> 
>   * Package could likely be uploaded into Debian as-is, just requires
> someone comfortable with it
> 
>   * We need more help with thepkg-wpa-devel group
I'm a member of pkg-wpa-devel and I've been sponsoring Kel for almost 4
years. I have absolute trust in him and I've even offered to advocate
him to the NM process multiple times.

I'd be happy to review and sponsor the uploads of crda/wireless-regdb,
if Paul doesn't have a problem with this.

I usually prefer team maintenance, so I think it'd be best if this
happened in pkg-wpa; my offer to sponsor is independent of that, though.

Regards,
Faidon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b8995b6.5000...@debian.org

offering for adoption: newLISP interpreter

[Ted Walther]

I was told there is time to get this into squeeze.  It has been
extensively debugged and tested on 64bit and 32bit platforms, and on
every architecture that Debian supports.

If someone could take this over, I'd be grateful; I'd like to see this
excellent language offered on every platform that debian supports, not
just the i386 and amd64 currently supported by my little repository.

Point your "apt-get source" to this little location:

http://dpkg.reactor-core.org/

Ted

--
   Nothing is true unless it makes you laugh,
  But you don't understand it until it makes you weep.

Name:Ted Walther
Phone:   208-310-7032
Skype:   tederific
Email:   t...@reactor-core.org
Address: #225 17700 58 Ave, Cloverdale, BC V3S1L6


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100227215023.ga26...@reactor-core.org

Re: Removing the manpage requirement for GUI programs?

[Vincent Fourmond]

markus schnalke wrote:
> [2010-02-27 20:06] Josselin Mouette 
>> I think it is a waste of time to write manual pages that won't be
>> maintained upstream, and that won't contain more useful information than
>> --help. The purpose of a manual page is to document precisely the
>> behavior of a program, and for GUI applications there is usually an
>> associated GUI documentation instead.
> 
> Man pages have one more important advantage: Every command has one.

  Count me in for that argument too.

  I personally heavily rely on man (and I'm so glad the imagemagick
command-line options are back into their manual page). I think it would
be a loss to not have one for each command.

  Cheers,

Vincent


-- 
Vincent Fourmond, Debian Developer
http://vince-debian.blogspot.com/

It was funny how people were people everywhere you went, even if the
people concerned weren't the people the people who made up the phrase
``people are people everywhere'' had traditionally thought of as people.
 -- Terry Pratchet, The Fifth Elephant

Vincent, not listening to anything for now


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b898f3c.9010...@debian.org

[RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda

[Luis R. Rodriguez]

Adding debian-devel and debian-mentors.

As per Paul Wise' advice I'd like to request for help with the
crda/wireless-regdb package for Debian for the next release of Debian.
I am the upstream crda maintainer and John Linville is the upstream
wireless-regdb maintainer. Kel Modderman has already done most work
required for the Debian package, if not all. What we now need is some
Debian Developer to be willing to either upload the package as-is, or
some help from some experienced package maintainers to address a few
items. I should note Paul Wise has offered sponsorship for this
package so I think we are on the last track to getting this package
finalized and/or uploaded but he just noted a few changes required.

Summary of review with Paul Wise:

  * Package could likely be uploaded into Debian as-is, just requires
someone comfortable with it

  * We need more help with thepkg-wpa-devel group

  * Sponsorship available by Paul Wise given a few change below are made:
  o Modify the Makefile to add a 'make dist' to generate a
ChangeLog using git2cl [1]
 and NEWS based on crda and wireless-regdb upstream git

Paul I'm not familiar with the sponsorship process on Debian, does
this mean if the above is address you would be wiling to upload the
final package yourself? Or does this have other implications?

I address some of Paul's own comments below. If you would like to read
the original thread you can refer to the pkg-wpa-devel package list.

[1] http://josefsson.org/git2cl/git2cl
[2] 
http://lists.alioth.debian.org/pipermail/pkg-wpa-devel/2010-January/002415.html

If anyone has any questions please let me know.

On Fri, Feb 19, 2010 at 10:11 PM, Paul Wise  wrote:
> On Thu, 2010-02-18 at 09:19 -0800, Luis R. Rodriguez wrote:
>
>> Upstream does not do the same. Ubuntu packages these two together
>> right now but it was because it made life easier for packaging.
>>
>> John, do you guys package wireless-regdb and crda together on Fedora
>> land? Was this because of the dynamic key building per package? If so
>> what is the restriction on using two packages?
>
>> Thanks John. So -- not sure if Kel will have time to split these, I
>> gather he is still pretty busy with his move. Paul, is this a
>> requirement for inclusion? If so we'll need to request for some help.
>
> I wouldn't upload it to Debian like that, you might find other people in
> Debian who would be willing to do so though.

OK.

>> > nl80211.h looks like it comes from Linux, can't you just build-depend on
>> > the linux-libc-dev package and do #include  ? Comparing
>> > the crda one and the one from Linux 2.6.32 reveals quite a few changes
>> > since you copied nl80211.h into crda.
>>
>> nl80211 is designed to allow userspace applications to either ship
>> their own nl80211.h based on the most recent kernel or to ship it and
>> ifdef around a feature instead of the kernel version.
> ...
>> For CRDA then we ship our own nl80211.h and it doesn't matter much as
>> we only use only one command, and the API that can't change anyway.
>> When CRDA wants to make use of something new we can just re-synch,
>> just as we do with iw.
>
> Hmm, OK. I guess that makes sense.

Yeah hope

>> > Even after manually ensuring that sha1sum.txt reflects the sha1sum of
>> > db.txt with "sha1sum db.txt > sha1sum.txt", the wireless-regdb Makefile
>> > still seems to generate a new Debian RSA key pair. If the db.txt hasn't
>> > changed, there is no reason to auto-generate and install a key pair.
>>
>> wireless-regdb is designed so that you do not have to run make at all
>> if you just intend on using John's key. So running make even if db.txt
>> has not changed will generate the keys for you and sign the
>> regulatory.bin with the new key.
>
> Hmm, OK. So the Debian packaging should check that db.txt is unchanged,
> instead of the upstream Makefile doing that check?

No, I meant that some distributions won't run make at all. Those who
do will always have something done if you don't yet have a key built
for you. By default the regulatory.bin is signed with this key. You
will re-sign the file if db.txt changes.

> I guess that means
> Fedora, Gentoo, Ubuntu etc all need to do the same thing.

Fedora does build stuff so they just go with the defaults. Ubuntu just
ships the provided regulatory.bin, they do not build anything, the
package is very simple for the binary regulatory database as you
really only need to build if you have policies which require this (the
content would be the same except the signature), or you want to change
the database yourself.

>> > dpkg-shlibdeps complains that neither crda and regdbdump use symbols
>> > from libssl, it looks like this might be a false positive though:
>> >
>> > dpkg-shlibdeps: warning: dependency on libssl.so.0.9.8 could be avoided if 
>> > "debian/crda/sbin/regdbdump debian/crda/sbin/crda" were not uselessly 
>> > linked against it (they use none of its symbols).
>>
>> They are not uselessly linking against libssl if inde

Re: Removing the manpage requirement for GUI programs?

[markus schnalke]

[2010-02-27 20:06] Josselin Mouette 
> 
> I think it is a waste of time to write manual pages that won't be
> maintained upstream, and that won't contain more useful information than
> --help. The purpose of a manual page is to document precisely the
> behavior of a program, and for GUI applications there is usually an
> associated GUI documentation instead.

Man pages have one more important advantage: Every command has one.

Do not underestimate this. On Debian systems, people know, if they
want to find out how to run a command and what command line options it
has, they look in its man page, cause every command has one.

If some graphical programs would not provide one, the the user would
first try to look in the man page and if it does not exist, he needs
to try --help (maybe he even needs to look for additional
documentation which would be application specific).

In my eyes, the largest advantage of man pages is that every command
has one.


meillo


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1nltwh-4mp...@serveme

Re: Xen, Squeeze, and Beyond

[Tollef Fog Heen]

]] Faidon Liambotis 

| Beyond that, I've also seen filesystem corruption when using live
| migration and the filesystem cache hasn't been disabled -- an almost
| undocumented directive of libvirt's XML.
| 
| All in all, I'm wondering how people can call this "stable".

I would guess at most people not using live migration and so never
hitting those kinds of problems.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d3zqz96s@qurzaw.linpro.no

Re: Removing the manpage requirement for GUI programs?

[Frank Lin PIAT]

On Sat, 2010-02-27 at 11:14 -0800, Russ Allbery wrote:
> Josselin Mouette  writes:
> 
> > GUI applications usually take only a few simple command-line options,
> > and more importantly, when you use a modern development framework, these
> > options will always be documented correctly with the --help switch.
> > Manual pages, OTOH, are not maintained properly by upstream developers.
> 
> > I think it is a waste of time to write manual pages that won’t be
> > maintained upstream, and that won’t contain more useful information than
> > --help. The purpose of a manual page is to document precisely the
> > behavior of a program, and for GUI applications there is usually an
> > associated GUI documentation instead.

manpages can prove to be useful in many situation and they have a few
nice features:
1. "man" offer a consistent API. (as opposed to -h/--help/-help/--usage/
   --help-foo, --help-bar, etc).
2. whatis foo
3. apropos bar
4. reading the manpage doesn't require to execute the program
  - it's safe to be run as root
  - it's doesn't create dummy .foo files
  - it never spawns any background process

> If the flags are properly documented with --help, isn't it usually fairly
> trivial to generate a man page using help2man?

And if it isn't trivial, it probably isn't trivial for humans either.

Franklin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1267304202.7886.2868.ca...@solid.paris.klabs.be

Re: Debian Packaging Meego Working Group

[Raphael Hertzog]

Hi,

On Fri, 26 Feb 2010, Fathi Boudra wrote:
> it isn't clear on the wiki page: the working group will use Meego
> infrastructure based on OBS to do a deb/apt based Meego instance, right?

Yes. We want to stay close the Meego infrastructure so that it's easy to
make a meego system using debian package management instead of RPM and
still being very close in terms of internal procedures to build packages
and system images.

Cheers,
-- 
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100227204845.gc3...@rivendell

RE: Removing the manpage requirement for GUI programs?

[Fuentes, Adolfo]

I think it is a good idea to have a centralized system where one can find 
information about a particular program. Otherwise we take the risk of having a 
sparse information system. If help2man helps to create the man page from the 
program help, which is the burden then?

---
Department of Chemistry -- Surface Science Research Centre
University of Liverpool
Crown Street
Liverpool, L69 7ZD
United Kingdom

"Treat the Earth well. It was not given to you by your parents, it was loaned 
to you by your children." (Ancient native American Indian proverb)

From: Josselin Mouette [j...@debian.org]
Sent: 27 February 2010 20:03
To: debian-devel@lists.debian.org
Subject: Re: Removing the manpage requirement for GUI programs?

Le samedi 27 février 2010 à 19:49 +, brian m. carlson a écrit :
> Additionally, in some cases, the --help output is not sufficient to
> explain what a program does.  "gcc-4.4 --help" does not list all the
> options; one has to use "gcc-4.4 -v --help".  Also, using only the
> latter, please tell me what the "-dM" argument does when passed to
> gcc-4.4.
>
> Although this example is not a GUI program, it is a great example of why
> --help output is often not sufficient.

Indeed it is not sufficient for gcc-4.4. But I still think it is
sufficient for gcalctool.

> In my opinion, your proposed
> change to policy will not result in the elimination of many manpages,
> because in most cases, the programs will be inadequately documented by
> the --help output.  --help output is for the case where you already are
> intimately familiar with the program and what it does, and need a quick
> reminder, or for cases when manpages are not available (emergency
> single-user boot).

We are talking of programs that you will not have the idea to run with
the command line unless you know what they do. Programs that are usually
run through a graphical menu.

The current situation is that there are a lot of outdated and/or
inaccurate manpages, while the --help output contains the same amount of
information and is guaranteed to be up-to-date.

--
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/debb97ea3eef8e489b88cefa9b3f36e255f22e6...@staffmbx2.livad.liv.ac.uk

Re: Removing the manpage requirement for GUI programs?

[brian m. carlson]

On Sat, Feb 27, 2010 at 09:03:04PM +0100, Josselin Mouette wrote:
> Le samedi 27 février 2010 à 19:49 +, brian m. carlson a écrit : 
> > Additionally, in some cases, the --help output is not sufficient to
> > explain what a program does.  "gcc-4.4 --help" does not list all the
> > options; one has to use "gcc-4.4 -v --help".  Also, using only the
> > latter, please tell me what the "-dM" argument does when passed to
> > gcc-4.4.
> > 
> > Although this example is not a GUI program, it is a great example of why
> > --help output is often not sufficient.
> 
> Indeed it is not sufficient for gcc-4.4. But I still think it is
> sufficient for gcalctool.

lakeview ok % gcalctool --help
Usage:
  gcalctool - Perform mathematical calculations

Help Options:
  -v, --version   Show release version
  -h, -?, --help  Show help options
  --help-all  Show all help options
  --help-gtk  Show GTK+ options

Application Options:
  -u, --unittest  Perform unittests
  -s, --solve   Solve the given equation


Tell me what user files gcalctool may access, using only this
information.  Also tell me, using *only the information provided*, how
to force GTK+ to make all X calls synchronous.  You can't, because that
information is not provided in the --help output.

In the latter case, --help-all might be useful, but the output is not
sufficient, and so the package would, according to your proposed
standard, need a manpage, or to be patched to make --help work like
--help-all.  In the former case, the information is not provided at all,
except in the manpage.

Furthermore, gcalctool can be scripted with -s, and the --help output
does not describe the syntax: is it infix? postfix? How do you express
powers?  Must powers be integers?  What precision is available?  The
manpage does not either, but that is a bug in the manpage.  That
information should not be present in the --help output.  It is entirely
too long.

> We are talking of programs that you will not have the idea to run with
> the command line unless you know what they do. Programs that are usually
> run through a graphical menu.

Maybe I'm the exception, but I end up running a lot of graphical
programs from the command line.  When I'm building PDFs, I generally run
evince from the command line.  I often use wireshark from the command
line.  And those are just two from the top of my head.

> The current situation is that there are a lot of outdated and/or
> inaccurate manpages, while the --help output contains the same amount of
> information and is guaranteed to be up-to-date.

I understand that.  I don't feel that this is the right way to go about
it, though.  As others have pointed out, apropos doesn't work without a
manpage.  And the --help output is woefully insufficient for a large
number of programs, including those with remotely subtle arguments.

I'm happy to write or update manual pages, if needed.  If you provide a
list of those that need work, I'll start working on them, so don't think
I'm just a naysayer that wants to push off work on others.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Removing the manpage requirement for GUI programs?

[Josselin Mouette]

Le samedi 27 février 2010 à 19:49 +, brian m. carlson a écrit : 
> Additionally, in some cases, the --help output is not sufficient to
> explain what a program does.  "gcc-4.4 --help" does not list all the
> options; one has to use "gcc-4.4 -v --help".  Also, using only the
> latter, please tell me what the "-dM" argument does when passed to
> gcc-4.4.
> 
> Although this example is not a GUI program, it is a great example of why
> --help output is often not sufficient.

Indeed it is not sufficient for gcc-4.4. But I still think it is
sufficient for gcalctool.

> In my opinion, your proposed
> change to policy will not result in the elimination of many manpages,
> because in most cases, the programs will be inadequately documented by
> the --help output.  --help output is for the case where you already are
> intimately familiar with the program and what it does, and need a quick
> reminder, or for cases when manpages are not available (emergency
> single-user boot).

We are talking of programs that you will not have the idea to run with
the command line unless you know what they do. Programs that are usually
run through a graphical menu.

The current situation is that there are a lot of outdated and/or
inaccurate manpages, while the --help output contains the same amount of
information and is guaranteed to be up-to-date.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Re: Removing the manpage requirement for GUI programs?

[brian m. carlson]

On Sat, Feb 27, 2010 at 08:06:37PM +0100, Josselin Mouette wrote:
> Therefore I propose that we drop the requirement of a manual page if
> these conditions are met: 
>   * the program requires graphical interaction with the user, and is
> not meant to be used from a script; 
>   * the command-line switches are properly documented with a --help
> option.

A manual page contains more information than just command line switches.
For example, iceweasel's manpage contains information about environment
variables and files that it uses.  This is almost never found in --help
output.  Also, in order for this requirement to be acceptable, every
binary in Debian that does not have a manpage must, upon first upload,
have a working --help output.  Otherwise, as Russ pointed out, we have
no way of knowing whether the program supports --help.  If it has no
manpage, it could be buggy and need a manpage, or it could be buggy and
need --help, but there's no way to know.

Also, if I'm looking through /usr/games for new ways to waste time, how
am I supposed to immediately intuit whether this program is GUI or not?
With a manual page, I can learn about the program and determine whether
it's a game I want to play at all.

Additionally, in some cases, the --help output is not sufficient to
explain what a program does.  "gcc-4.4 --help" does not list all the
options; one has to use "gcc-4.4 -v --help".  Also, using only the
latter, please tell me what the "-dM" argument does when passed to
gcc-4.4.

Although this example is not a GUI program, it is a great example of why
--help output is often not sufficient.  In my opinion, your proposed
change to policy will not result in the elimination of many manpages,
because in most cases, the programs will be inadequately documented by
the --help output.  --help output is for the case where you already are
intimately familiar with the program and what it does, and need a quick
reminder, or for cases when manpages are not available (emergency
single-user boot).

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Removing the manpage requirement for GUI programs?

[David Coe]

Keep in mind that the apropos command only searches man pages, so I strongly
support keeping them around and creating them (even if only from --help)
when
they're missing.

2010/2/27 Josselin Mouette 

> Hi,
>
> currently policy §12.1 mandates that “each program, utility, and
> function should have an associated manual page”. However, the more I
> stomp on bug reports about manual pages, the less I am convinced of
> their usefulness for GUI programs.
>
> GUI applications usually take only a few simple command-line options,
> and more importantly, when you use a modern development framework, these
> options will always be documented correctly with the --help switch.
> Manual pages, OTOH, are not maintained properly by upstream developers.
>
> I think it is a waste of time to write manual pages that won’t be
> maintained upstream, and that won’t contain more useful information than
> --help. The purpose of a manual page is to document precisely the
> behavior of a program, and for GUI applications there is usually an
> associated GUI documentation instead.
>
> Therefore I propose that we drop the requirement of a manual page if
> these conditions are met:
>  * the program requires graphical interaction with the user, and is
>not meant to be used from a script;
>  * the command-line switches are properly documented with a --help
>option.
>
> For extra points, we could agree on a way to generate manual pages
> automatically, either at installation time or on the fly, using
> help2man.
>
> Any comments before I submit a bug against the policy?
>
> Cheers,
> --
>  .''`.  Josselin Mouette
> : :' :
> `. `'   “I recommend you to learn English in hope that you in
>  `- future understand things”  -- Jörg Schilling
>



-- 
David Coe
+1 410 489 9521

Re: Removing the manpage requirement for GUI programs?

[Russ Allbery]

Josselin Mouette  writes:

> GUI applications usually take only a few simple command-line options,
> and more importantly, when you use a modern development framework, these
> options will always be documented correctly with the --help switch.
> Manual pages, OTOH, are not maintained properly by upstream developers.

> I think it is a waste of time to write manual pages that won’t be
> maintained upstream, and that won’t contain more useful information than
> --help. The purpose of a manual page is to document precisely the
> behavior of a program, and for GUI applications there is usually an
> associated GUI documentation instead.

If the flags are properly documented with --help, isn't it usually fairly
trivial to generate a man page using help2man?

Running random programs with --help to try to get help is not appealing.
Some programs will proceed to do things if you run them even with options
like that, since they don't do option parsing.  It's also very nice to
have everything documented in one, shared system so that you can always
use the same command to get basic help for anything.

> Therefore I propose that we drop the requirement of a manual page if
> these conditions are met: 
>   * the program requires graphical interaction with the user, and is
> not meant to be used from a script; 
>   * the command-line switches are properly documented with a --help
> option.

> For extra points, we could agree on a way to generate manual pages
> automatically, either at installation time or on the fly, using
> help2man.

If you do this, there's no need to drop the requirement that there be a
manual page, so no Policy change is required.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sk8mxzh3@windlord.stanford.edu

Removing the manpage requirement for GUI programs?

[Josselin Mouette]

Hi,

currently policy §12.1 mandates that “each program, utility, and
function should have an associated manual page”. However, the more I
stomp on bug reports about manual pages, the less I am convinced of
their usefulness for GUI programs.

GUI applications usually take only a few simple command-line options,
and more importantly, when you use a modern development framework, these
options will always be documented correctly with the --help switch.
Manual pages, OTOH, are not maintained properly by upstream developers.

I think it is a waste of time to write manual pages that won’t be
maintained upstream, and that won’t contain more useful information than
--help. The purpose of a manual page is to document precisely the
behavior of a program, and for GUI applications there is usually an
associated GUI documentation instead.

Therefore I propose that we drop the requirement of a manual page if
these conditions are met: 
  * the program requires graphical interaction with the user, and is
not meant to be used from a script; 
  * the command-line switches are properly documented with a --help
option.

For extra points, we could agree on a way to generate manual pages
automatically, either at installation time or on the fly, using
help2man.

Any comments before I submit a bug against the policy?

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


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

Intent to remove waf from Debian

[Luca Falavigna]

Hello,

after some time spent to reflect and discuss, I think we reached a
point of no return regarding waf package in Debian. I try to summarize
what happened in the past months.

Devid and I originally decided to include waf as a regular package in
Debian because several projects use it as their preferred build system,
including a waf "binary" in upstream tarballs. Such "binary" is
basically a Python script with an embedded bzip2 tarball unpacked at
runtime. Debian package provides waf script, together with wafadmin
directory, which is basically the tarball mentioned above, unpacked.

Upstream discourages using a system-wide installation of waf [1], and
tried in some ways to complicate things for distributors ([2], search
"Debian" word), and refused to provide any feedback with related build
failures, which were handled with workarounds [3][4].

Things went worse when a user complained with upstream about a build
failure while using waf provided by Debian package and an older wscript,
waf upstream contacted us asking to remove waf package from Debian under
threat to remove system-wide installation, giving us no chance to
provide a working waf package anymore. We tried to reach a compromise
[5], but it was not enough for upstream, and he renewed his intentions.

We do not believe we can solve this situation anytime soon, so we would
like to remove waf from Debian for good. I already filed bugs on those
packages currently build-depending on waf [6], hopefully they will be
fixed before Squeeze, or I will prepare NMUs if release approaches.

As a personal note, I discourage using waf as build system of choice:
during these months I realized waf introduces backward incompatible
changes every releases, this can lead to build failures very
frequently. Sticking with older releases is the suggested solution by
upstream, but may expose to bugs fixed in newer releases only.

[1]http://freehackers.org/~tnagy/wafbook/single.html#installing
[2]http://groups.google.com/group/waf-users/browse_thread/thread/88ad357bf2bf59f4/7261615b56c07eea
[3]http://svn.debian.org/viewsvn/python-apps/packages/waf/trunk/debian/patches/intltool.patch
[4]http://svn.debian.org/viewsvn/python-apps/packages/waf/trunk/debian/patches/fun_check.patch
[5]http://svn.debian.org/viewsvn/python-apps/packages/waf/trunk/debian/README.Debian
[6]http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=...@packages.qa.debian.org;tag=waf-removal

Regards,

-- 
  .''`.
 :  :' :   Luca Falavigna 
 `.  `'
   `-


signature.asc
Description: PGP signature

Re: Xen, Squeeze, and Beyond

[Josip Rodin]

On Fri, Feb 26, 2010 at 11:06:57AM +0100, Samuel Thibault wrote:
> Marco d'Itri, le Fri 26 Feb 2010 02:38:33 +0100, a écrit :
> > On Feb 25, John Goerzen  wrote:
> > > 3a) What about Linux virtualization on servers that lack hardware
> > > virtualization support, which Xen supports but KVM doesn't?
> > Tough luck.
> > 
> > > 6) Are we communicating this to Debian users in some way?  What can I do
> > > to help with this point?
> > Remind people that Xen is dying and KVM is the present and the future.
> 
> No FUD, thanks.

FWIW I've been running a Xen dom0 2.6.31.x for a while now without problems
and it seems to have all the features I used with etch and lenny dom0
kernels. So I wouldn't say it's dying, instead it may be more appropriate
to call it a reinvigorated pensioner :)

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100227180841.ga30...@orion.carnet.hr

Re: Xen, Squeeze, and Beyond

[Josip Rodin]

On Fri, Feb 26, 2010 at 10:35:36AM +, Mark Brown wrote:
> On Fri, Feb 26, 2010 at 11:18:41AM +0100, Goswin von Brederlow wrote:
> > According to the wiki the plan is to have pv-ops merge into vanilla with
> > 2.6.34.
> 
> I just took a quick look at linux-next (which *should* have everything
> for 2.6.34 in it) doesn't show anything that looks obviously like this,
> though I only looked briefly.

I'm assuming this was about http://wiki.xensource.com/xenwiki/XenParavirtOps
section "Current state". That bit has always been optimistic, but I'd
recommend reviewing the "Status updates" subsection and particularly
Jeremy Fitzhardinge's November presentation.

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100227175845.gd18...@orion.carnet.hr

Re: Xen, Squeeze, and Beyond

[Josip Rodin]

On Fri, Feb 26, 2010 at 11:18:41AM +0100, Goswin von Brederlow wrote:
> >> "Xen - Provides para-virtualization and full-virtualization. Mostly used
> >> on servers. Will be abandoned after squeeze."
> >
> > I think that the problem here is that Xen isn't mainstream in the 
> > kernel. It takes a long time for a Xen-ified kernel to come out and any 
> > distribution supporting it has to carry a heavy patch burden. Xen 
> > doesn't keep anywhere current in terms of kernel - if we release Squeeze 
> > this year with kernel 2.6.3*, Debian will have to maintain all the patches
> > / "forward port" them to 2.6.32 or 2.6.33 as was done with 2.6.2*. 
> 
> I think we can all agree that the old style xen patches from 2.6.18 and
> forward ported to newer kernels in lenny are unmaintainable.
> 
> But the pv-ops xen kernel is shaping up well and that is what Bastian
> Banks is working on. They have a proper upstream and follow the latest
> vanilla kernel well enough. According to the wiki the plan is to have
> pv-ops merge into vanilla with 2.6.34.

Let's not concentrate too much on having dom0 support in mainline, because
that is not a panacea - we (Debian) just need a stable Xen patch that tracks
the current stabler-mainline branch or whatever we're targeting for our
stable release, and has some sort of a forseeable future maintenance path.

We have shipped .26 patches in lenny and they turned out to be really buggy
in some cases (domU .26 kernels with vcpus >= 1 can get random freezes on
.26 dom0), and it's not getting fixed because that patch branch is EOL'd.
That's worse of a problem for users than some theoretical later abandoning.

Since we're concentrating on .32 now, the paravirt_ops branch looks good,
because Xen upstream agreed to form their own .32 stable branch of that.
So whether they succeed in a mainline merge for .34 or .35 or .36 or even
later, that's irrelevant, we will still have support for the squeeze kernel.

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100227175041.gc18...@orion.carnet.hr

Re: Xen, Squeeze, and Beyond

[Martin Wuertele]

* John Goerzen  [2010-02-27 17:09]:

> How does libvirt impact performance?

Guess I cunfused libvirt with virtio.

Regards, Martin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100227173924.gh16...@anguilla.debian.or.at

Re: Xen, Squeeze, and Beyond

[Josip Rodin]

On Sat, Feb 27, 2010 at 01:23:07AM +0300, William Pitcock wrote:
> I am looking into packaging xenner already as a backup plan if I cannot
> manage to fix some major reentrancy problems in the Xen dom0 code
> (Xensource 2.6.18 patches, the pvops stuff has it's own share of problems
> and needs more evaluation).

The .18 dom0 patches are well on their way out from the perspective of
both Debian and Xen upstream, so you might want to shift focus to the pvops
branch instead.

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100227173048.gb18...@orion.carnet.hr

Re: Xen, Squeeze, and Beyond

[Josip Rodin]

On Fri, Feb 26, 2010 at 10:35:30AM +1100, Brian May wrote:
> On 26 February 2010 09:53, John Goerzen  wrote:
> > According to http://wiki.debian.org/SystemVirtualization :
> >
> > "Qemu and KVM - Mostly used on Desktops/Laptops"
> >
> > "VirtualBox - Mostly used on Desktops/Laptops"
> >
> > "Xen - Provides para-virtualization and full-virtualization. Mostly used
> > on servers. Will be abandoned after squeeze."
> 
> This doesn't help answer your questions (which I am interested in
> knowing the answers too), however there is also lxc - Linux Containers
> which may be another solution for some problems. It is not a
> replacement for any of the above however.

LXC is the future replacement of our OpenVZ kernel packages. However,
reportedly it's not nearly as stable yet.

At the same time, the OpenVZ upstream git has only made it as far as
mainline .27. See: http://git.openvz.org/ Unless they shift up to .32
soonish, or someone packages the .27 kernel in Debian, we're unlikely
to see continued support for it in squeeze. :/

-- 
 2. That which causes joy or happiness.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100227172800.ga18...@orion.carnet.hr

Re: Armel build admins?

[Dirk Eddelbuettel]

On 27 February 2010 at 16:17, Colin Tuckley wrote:
| Dirk Eddelbuettel wrote:
| 
| > As I can never remember what the porter / admin group emails are -- where do
| > I want to send this? debian-arm is the catch-all list and that is not what I
| > want, methinks.
| 
| You want ar...@buildd.debian.org I think

Quite right, thank you.  Request posted there...

Dirk

-- 
  Registration is open for the 2nd International conference R / Finance 2010
  See http://www.RinFinance.com for details, and see you in Chicago in April!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/19337.19705.710850.970...@ron.nulle.part

Re: override LDFLAGS with debhelper 7

[Jakub Wilk]

* Simon Richter , 2010-02-27, 17:12:

However, there's some packages using another method:
override_dh_auto_configure:
dh_auto_configure -- LDFLAGS="$(LDFLAGS) -Wl,--as-needed"



NOTE: this method doesn't work !


That depends on the autoconf version. Earlier versions require an
environment variable, later ones accept variables as arguments as well.

It might be an interesting idea to have debhelper work around old
configure scripts by exporting anything that looks like a variable
definition on the configure command line.


No, that would be silly. There's already too much magic behind debhelper 
these days.


--
Jakub Wilk


signature.asc
Description: Digital signature

Re: Armel build admins?

[Michael Tautschnig]

> 
> I would like to request a rebuild of one of my package on armel. It built
> fine for last-5 to last-2 but both last-1 and last failed due to timeouts --
> I think ot simply tried to build on a smaller machine.
> 
> As I can never remember what the porter / admin group emails are -- where do
> I want to send this? debian-arm is the catch-all list and that is not what I
> want, methinks.
> 

[...]

See the last lines of

http://www.debian.org/devel/buildd/

Best,
Michael



pgpItb4cse5T5.pgp
Description: PGP signature

Re: override LDFLAGS with debhelper 7

[Simon Richter]

Hi,

On Sat, Feb 27, 2010 at 04:55:27PM +0100, Fathi Boudra wrote:

> However, there's some packages using another method:
> override_dh_auto_configure:
> dh_auto_configure -- LDFLAGS="$(LDFLAGS) -Wl,--as-needed"

> NOTE: this method doesn't work !

That depends on the autoconf version. Earlier versions require an
environment variable, later ones accept variables as arguments as well.

It might be an interesting idea to have debhelper work around old
configure scripts by exporting anything that looks like a variable
definition on the configure command line.

   Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100227161259.ga24...@honey.hogyros.de

Re: Armel build admins?

[Colin Tuckley]

Dirk Eddelbuettel wrote:

> As I can never remember what the porter / admin group emails are -- where do
> I want to send this? debian-arm is the catch-all list and that is not what I
> want, methinks.

You want ar...@buildd.debian.org I think

Colin

-- 
Colin Tuckley  |  +44(0)1223 293413  |  PGP/GnuPG Key Id
Debian Developer   |  +44(0)7799 143369  | 0x1B3045CE

Psychiatrists stay on your mind.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b894580.8090...@debian.org

Re: Xen, Squeeze, and Beyond

[Faidon Liambotis]

Marco d'Itri wrote:
> On Feb 26, Luca Capello  wrote:
> 
 5) Do we recommend that new installations of lenny or of squeeze avoid
 Xen for ease of upgrading to squeeze+1?  If so, what should they use?
>>> It depends. KVM in lenny is buggy and lacks important features. While it
>>> works fine for development and casual use I do not recommend using it in
>>> production for critical tasks.
>> Is the qemu-kvm backport the "correct" solution, then?
> You also need a recent kvm driver in the host, so probably you should
> just use a newer kernel at least in the host.
> I have tens of lenny guests (with their standard kernels) on RHEL 5.4
> hosts and so far I had no issues, but so far most guests are not heavily
> loaded.
The biggest problem for me (and work) right now is live migration. Among
other things, there are known, fixed-but-not-yet-upstream issues with
the KVM paravirt clock which prevents live migration from working.
Unfortunately, there's also no way to disable the paravirt clock from
the host unless you patch qemu or wrap ioctl() and filter the capability
(I did the latter).

Beyond that, I've also seen filesystem corruption when using live
migration and the filesystem cache hasn't been disabled -- an almost
undocumented directive of libvirt's XML.

All in all, I'm wondering how people can call this "stable".

Regards,
Faidon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b893bd4.1070...@debian.org

Re: Xen, Squeeze, and Beyond

[John Goerzen]

Martin Wuertele wrote:
> * Goswin von Brederlow  [2010-02-26 11:19]:
> 
>>> KVM is shaping up well and appears to be very well supported by Red Hat.
>> But still slower and less secure due to qemu.
> 
> Can you back that statement with numbers? My subjective impression is
> that kvm with libvirt is not slower than xen.

How does libvirt impact performance?

> 
> Regards, Martin
> 
> 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b893e8d.8070...@complete.org

Armel build admins?

[Dirk Eddelbuettel]

I would like to request a rebuild of one of my package on armel. It built
fine for last-5 to last-2 but both last-1 and last failed due to timeouts --
I think ot simply tried to build on a smaller machine.

As I can never remember what the porter / admin group emails are -- where do
I want to send this? debian-arm is the catch-all list and that is not what I
want, methinks.

Thanks for any and all waves with the cluebat. 

Dirk

-- 
  Registration is open for the 2nd International conference R / Finance 2010
  See http://www.RinFinance.com for details, and see you in Chicago in April!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/19337.16103.502993.897...@ron.nulle.part

Re: klibc only initramfs

[Bernd Zeimetz]

Goswin von Brederlow wrote:
> When 100 nodes all want to talk to the one bootserver then that one poor
> port will be overflown. With switches you won't have collisions like in
> the old days when they would combine exponentially but you still get
> slowdowns.

Add more switches. Add more network cards to your boot-server. Add a second
bootserver if necessary. Or just don't boot all machines at the same time (hint:
that might also save your building's power supply...).

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b89429e.1090...@bzed.de

override LDFLAGS with debhelper 7

[Fathi Boudra]

Hi,

It seems the best (only?) way to override LDFLAGS with debhelper 7 is
a LDFLAGS export at the top of debian/rules file.

However, there's some packages using another method:
override_dh_auto_configure:
dh_auto_configure -- LDFLAGS="$(LDFLAGS) -Wl,--as-needed"

NOTE: this method doesn't work !

Should we track this packaging error and fill bug against them ?

Cheers,

Fathi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/6a2e33621002270755v7e7d0a51q6be538bbf8629...@mail.gmail.com

Re: Bug#570980: teasers

[Holger Levsen]

Hi,

On Samstag, 27. Februar 2010, Philipp Kern wrote:
> > [...]ifconfig is useful for non-root users, but is in sbin.[...]
> And I find that fact mildly annoying considering that it is thus
> not in the default PATH.  

I finally managed to teach my fingers to type "ip a" instead... 


cheers,
Holger


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

Bug#570980: teasers

[Tollef Fog Heen]

]] Patrick Matthäi 

Please respect my Mail-Followup-To.

| On 27.02.2010 11:56, Tollef Fog Heen wrote:
| > ]]
| >
| > | Well just like many of the comments to 348864, I just hate the
| > | "teasers" in section 1 that only root can run.
| >
| > Whether a tool is root-only or not is orthogonal to whether it's in bin
| > or sbin.
| >
| > (ifconfig is useful for non-root users, but is in sbin.  chown is
| > effectively root-only, but is in bin.)
| 
| Why is chown useless for users?
| 
| m...@exez:~$ touch test
| m...@exez:~$ ls -l test
| -rw-r--r-- 1 me me 0 27. Feb 12:06 test
| m...@exez:~$ chown :audio test
| m...@exez:~$ ls -l test
| -rw-r--r-- 1 me audio 0 27. Feb 12:06 test

Ok, fair enough, you can use the part of its functionality that's
duplicated by chgrp which is also in bin, while its unique functionality
is effectively root-only.

(Or look at dpkg-trigger or dpkg-statoverride which are also in bin,
ditto for updatedb.  I'm sure you're able to find another example.)

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



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mxyuzwd0@qurzaw.linpro.no

Re: Bug#570980: teasers

[Philipp Kern]

On 2010-02-27, Tollef Fog Heen  wrote:
> [...]ifconfig is useful for non-root users, but is in sbin.[...]

And I find that fact mildly annoying considering that it is thus
not in the default PATH.  But at least a user is able to put sbin
into his environment despite of this (which wouldn't be possible if
sbin would be o-rx for non-root for example, there are other
Unices that restrict calling administrative commands).

Kind regards,
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnhohvpq.jjc.tr...@kelgar.0x539.de

Bug#570980: teasers

[Patrick Matthäi]

On 27.02.2010 11:56, Tollef Fog Heen wrote:

]]

| Well just like many of the comments to 348864, I just hate the
| "teasers" in section 1 that only root can run.

Whether a tool is root-only or not is orthogonal to whether it's in bin
or sbin.

(ifconfig is useful for non-root users, but is in sbin.  chown is
effectively root-only, but is in bin.)



Why is chown useless for users?

m...@exez:~$ touch test
m...@exez:~$ ls -l test
-rw-r--r-- 1 me me 0 27. Feb 12:06 test
m...@exez:~$ chown :audio test
m...@exez:~$ ls -l test
-rw-r--r-- 1 me audio 0 27. Feb 12:06 test


--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatth...@debian.org
patr...@linux-dev.org

Comment:
Always if we think we are right,
we were maybe wrong.
*/



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b88fcf3.7080...@debian.org

Re: Xen, Squeeze, and Beyond

[Martin Wuertele]

* Goswin von Brederlow  [2010-02-26 11:19]:

> > KVM is shaping up well and appears to be very well supported by Red Hat.
> 
> But still slower and less secure due to qemu.

Can you back that statement with numbers? My subjective impression is
that kvm with libvirt is not slower than xen.

Regards, Martin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100227110813.gg16...@anguilla.debian.or.at

Bug#570980: teasers

[Tollef Fog Heen]

]] 

| Well just like many of the comments to 348864, I just hate the
| "teasers" in section 1 that only root can run.

Whether a tool is root-only or not is orthogonal to whether it's in bin
or sbin.

(ifconfig is useful for non-root users, but is in sbin.  chown is
effectively root-only, but is in bin.)

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



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vddjymjl@qurzaw.linpro.no