]] 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
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 w
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 doc
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 applicati
"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
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 syste
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 poli
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
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++
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
> a
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) i
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
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 fro
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
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 pat
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
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
"~/.gca
- "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'
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 w
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 de
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 progra
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 don
[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 application
]] 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
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 --hel
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 pac
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 Chemist
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
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 tel
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;
> * t
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
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 up
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-
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
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?
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
>
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 lo
* 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://list
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
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 -
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.o
* 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 v
>
> 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
>
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
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 |
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
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
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
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 c
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 wor
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,
]] 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 wh
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 possi
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 sb
* 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,
]]
| 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 i
56 matches
Mail list logo
