Re: Debug output etc, cluttering the terminal

[Michael Welle]

Hello,

"brian m. carlson"  writes:

> On Sun, Aug 15, 2010 at 12:09:42AM +0100, Neil Williams wrote:
>> It's debug output, it is useful when debugging and you need the output,
>> e.g. when fixing bugs and the user can just be asked to run the command
>> from the terminal and post the output to help in debugging the bug
>> report. Generally, the debug output for a particular release tends to
>> reflect the issues which upstream were working on most intensively
>> before that release and therefore can have a direct impact on the
>> likelihood of new bugs or regressions in old bugs.
>
> The Unix tradition is for programs to run silently unless there's a
> problem.  Taking 64ms to complete some operation is not, in general, a
> problem.
Yepp, citing the rule of silence from TAOUP: '...when a program has
nothing interesting or surprising to say, it should shut up.'

Regards
hmw

-- 
biff4emacsen - A biff-like tool for (X)Emacs
http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html
Flood - Your friendly network packet generator
http://www.c0t0d0s0.de/flood/flood.html


-- 
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/87hbiw8imd@stella.c0t0d0s0.de

Re: libcairo2 in squeeze & subpixel rendering

[Marc 'HE' Brockschmidt]

Stanislav Maslovski  writes:
> On Mon, Aug 09, 2010 at 05:22:27PM +0200, Sebastian Dröge wrote:
>> Backporting the lcdfilter patch to 1.8.10 might be a solution for
>> squeeze though. If someone wants to provide a patch that doesn't add any
>> new public API I'd be fine with applying it to the unstable package...
>> at least if the release team agrees.
> I am pretty sure porting is doable and I think I can volunteer to do
> this. But before it, let us collect more opinions. It would be nice to
> know what does the release team think about it. 

If the patch is reasonably small and is tested in unstable for some
time, it won't be a problem to do this. In the future, if you want a
reaction from the release team, sending mail to
debian-rele...@lists.debian.org will speed up things.

> BTW, suboptimal subpixel rendering of fonts in Debian is one of the
> reasons why many desktop users switch to other distros.

Yeah, right. They don't do it because other distros have the newest
bleeding edge features, but because they spend time on researching why
fonts in some applications are not looking perfect and then willingly
switch to a distribution which does proper subpixel rendering.

Have you *ever* spoken to normal desktop user?

Marc


pgpv456L1Zhrr.pgp
Description: PGP signature

Re: Debug output etc, cluttering the terminal

[Neil Williams]

On Sun, 15 Aug 2010 08:51:21 +0200
Michael Welle  wrote:

> > It's debug output, it is useful when debugging and you need the
> > output, e.g. when fixing bugs and the user can just be asked to run
> > the command from the terminal and post the output to help in
> > debugging the bug report. Generally, the debug output for a
> > particular release tends to reflect the issues which upstream were
> > working on most intensively before that release and therefore can
> > have a direct impact on the likelihood of new bugs or regressions
> > in old bugs.
> >
> > It's not clutter. If you don't want to see it, run the command and
> > redirect stderr.
> I agree with your opinion about the usefulness of debug output. And
> -as one might guess- I disagree with your opinion about  how debug
> output should be handled. Do Debian distribute programmes to its user
> base, that are still in debug phase?

Yes and will continue to do so. All software is susceptible to bugs and
all software needs to have debug support. Mature software needs more
debug support than pre-alpha software because bugs in mature packages
tend to be corner-cases and obscure use cases, i.e. harder to identify.

Every software package is constantly being debugged. Even the kernel
produces debug output in the case of particular errors - including
messages which appear on every terminal on the machine and sound a
fixed volume beep. Depending on the circumstances, this can be
something as simple as not taking a USB networking interface down
before removing the USB cable. Depends which module is in use.

> Aren't debug switches sold
> anymore?

"sold" ??? Programs support --debug or --verbose options on the command
line for debugging of errors which are not often seen.

> One can forget to switch debug output off. That's no biggy,
> mistakes happen. But have it switched on per default is strange and
> embarassing.

Nothing of the sort. Programs that do not provide debug output should
make log files containing debug output.

When bugs are hard to reproduce, having debug output on by default is
extremely important for many mature packages.

This isn't about forgetting to switch debugging off, this is about
helping users and developers actually fix bugs.

Difficult bugs can appear as a subtle change in the debug output, even
if the program continues to operate normally (or close to normally),
only to fail later. e.g. a package can develop a bug which corrupts the
data storage format used by the package, the debug output includes a
line that a variable of type foo has been written out as type bar but
is still of type foo inside the program. Close the program, try to
reload the exported data, containing the type bar, and the program
fails. The only way to debug this is to have the debug output available
by default and then include the details of how that data was obtained
into the bug report.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgpy7zWCm7M5V.pgp
Description: PGP signature

Re: Debug output etc, cluttering the terminal

[Neil Williams]

On Sun, 15 Aug 2010 12:44:59 +0800
Paul Wise  wrote:

> On Sun, Aug 15, 2010 at 7:09 AM, Neil Williams 
> wrote:
> 
> > It's not clutter. If you don't want to see it, run the command and
> > redirect stderr.
> 
> debug output should certainly not be output by default in released
> versions without a command-line or configuration option turning it on.

On the contrary, I've outlined some situations where on-by-default is
the best way to identify the bug itself.

> l for one don't want ls doing something like this:
> 
> ls: starting up
> ls: checking for bad filesystems
> ls: searching for files in /home/foo/some/path
> foo bar/ baz/
> ls: 1 file found
> ls: 2 directories found

But if that software starts misbehaving in circumstances which are not
easily identified, then debug output can be essential.

If the above is actually:

stderr> ls: starting up
stderr> ls: checking for bad filesystems
stderr> ls: searching for files in /home/foo/some/path
stdout> foo bar/ baz/
stderr> ls: 1 file found
stderr> ls: 2 directories found

then this could be useful. Done correctly, (and the above wouldn't be
nice from something like 'ls' but for other command line programs it
could be necessary), debug-on-by-default is very important to actually
debugging hard-to-reproduce bugs.

Even coreutils has bugs.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgp29K5Ldh5Yn.pgp
Description: PGP signature

Re: Debug output etc, cluttering the terminal

[Neil Williams]

On Sun, 15 Aug 2010 08:57:56 +0200
Michael Welle  wrote:

> Paul Wise  writes:
> [...]
> > debug output should certainly not be output by default in released
> > versions without a command-line or configuration option turning it
> > on.
> >
> > l for one don't want ls doing something like this:
> >
> > ls: starting up
> > ls: checking for bad filesystems
> > ls: searching for files in /home/foo/some/path
> > foo bar/ baz/
> > ls: 1 file found
> > ls: 2 directories found
> thank you for this brilliant example, but please add to the output how
> much time the steeps consumed ;).

Debug output, to be useful, must take as little time as possible. This
is particularly important when considering bugs in programs using
threads and thread-locking or trying (possibly wrongly) to use
file-locking.

> My feeling is that many developers 
> don't care because most users might not be aware of what is happening.

That is a very cavalier attitude to how developers manage their
software. If you have any basis for that accusation I suggest you be
open and name names.

> They may start the application by mouse clicking and so they don't
> know about stdout and stderr.

Users may but developers will be looking for that debug output and
starting the program from the command line explicitly to be able to
collect it. (Filing a bug will usually result in the user being asked
to start the program from the command line too.)

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgpZdWCvZApnK.pgp
Description: PGP signature

Re: Debug output etc, cluttering the terminal

[Neil Williams]

On Sun, 15 Aug 2010 02:23:32 +
"brian m. carlson"  wrote:

> On Sun, Aug 15, 2010 at 12:09:42AM +0100, Neil Williams wrote:
> > It's debug output, it is useful when debugging and you need the
> > output, e.g. when fixing bugs and the user can just be asked to run
> > the command from the terminal and post the output to help in
> > debugging the bug report. Generally, the debug output for a
> > particular release tends to reflect the issues which upstream were
> > working on most intensively before that release and therefore can
> > have a direct impact on the likelihood of new bugs or regressions
> > in old bugs.
> 
> The Unix tradition is for programs to run silently unless there's a
> problem.

Just because you don't see the bug on your system does not mean that
the bug does not occur on slightly different systems.

> I have no problem with programs taking an environment variable or a
> command line option in order to produce debugging output, but it
> shouldn't be the default.

Sometimes that is necessary. Perhaps it is worth considering that
developers do actually care and do such things for very good reasons
and that maybe you just haven't realised why this happens.

> > It's not clutter. If you don't want to see it, run the command and
> > redirect stderr.
> 
> It is clutter.  In my case, I opened a PDF in mutt.  mutt used okular
> instead of evince (why, I'm not sure) and therefore the terminal in
> which I run my mutt session now has KDE daemons screaming at me when I
> update my system.  This is not desirable.

Redirect stderr when opening the file or work out why okular was
selected in the first place. Moaning in the general direction of all
developers everywhere isn't helpful. Do something to identify the
problem, not the symptom. BTW evince produces debug messages when
loading some PDF files too, so this isn't just an okular thing.

If you want the debug output to go away, help the developers fix the
bugs which are either causing the output or causing the developers to
need the output.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgpFNNUzn7gRF.pgp
Description: PGP signature

Re: Debug output etc, cluttering the terminal

[Bernhard R. Link]

* Neil Williams  [100815 10:55]:
> When bugs are hard to reproduce, having debug output on by default is
> extremely important for many mature packages.

Which does not change the fact that a graphical program which outputs
stuff to the terminal is very annoying and looks very immature.

But I guess opinions differ.

Bernhard R. Link


-- 
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/20100815092606.ga17...@pcpool00.mathematik.uni-freiburg.de

Re: Debug output etc, cluttering the terminal

[Josef Spillner]

Am Samstag, 14. August 2010, 19:59:50 schrieb Michael Welle:
> Hello,
> 
> what is the reason that many applications clutter the terminal with
> output that is obvisously debug output? Lets take digikam as an
> example:

In the specific case of Digikam and other KDE applications, you can run 
kdebugdialog to control the debugging messages. In particular, there is a 
convenient switch to turn them off completely.

There are only two catches:
- The netlib_connectsock() messages probably come from a dependency library, 
they don't adhere to kdebug policies.
- In some apps like Gwenview, some debug messages about kdeui still pass the 
filter. If you experience the same issue, I suggest you file a bug report 
against kdebugdialog.

When KDE applications are run in a KDE environment, the debug output is 
normally not an issue because even terminal-using people prefer KRunner's 
autocompletion over bash's and hence don't see the debug messages. However, it 
is certainly an upstream goal to make KDE applications play nice in other 
environments both visually and behaviourally.

I see your point in bringing this up on this list to end up with distribution-
wide guidelines, but for pragmatic reasons I think you're better off contacting 
the application or framework maintainers directly. KDE has one debugging 
system, Mozilla has another one, the Linux kernel has yet another one for the 
primary terminal, Java apps have their own local logging policies and so on. 
It would be a huge task trying to unify the policies.

Josef


-- 
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/201008151129.00477.2...@kuarepoti-dju.net

Re: Bug#592839: dpkg-source option to remove files on unpack: debian/source/remove-files

[Guido Günther]

On Fri, Aug 13, 2010 at 01:01:34PM -0400, Michael Gilbert wrote:
> On Fri, 13 Aug 2010 09:58:07 -0700, Russ Allbery wrote:
> > Raphael Hertzog  writes:
> > 
> > > As suggested by Ian on -devel (see attachment), it would be nice to have
> > > a way to remove files during unpack of a source package to hide non-free
> > > files from our users without stripping them from the original tarball.
> > 
> > > I also prefer this approach over repacking upstream files so let's
> > > implement this feature.
> > 
> > I'm pretty sure ftp-master isn't going to allow source packages with
> > non-free content in the main archive regardless of whether that content is
> > hidden on unpack (I certainly wouldn't if I were them), so implementing
> > this is kind of pointless for Debian.
> 
> What if the list of binary components was part of the watch file
> instead; so that new upstream sources could be automatically stripped of
> those non-free bits by uscan right after download.
Git-buildpackage (and I'm sure other tools too) have filter expressions
that can handle this when importing new upstream versions (e.g. via
--uscan). The configuration can be shipped in debian/gbp.conf so in case
of team maintenance all have the same filter.
Cheers,
 -- Guido


-- 
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/20100815093741.ga9...@bogon.sigxcpu.org

Re: Debug output etc, cluttering the terminal

[Holger Levsen]

Hi,

On Sonntag, 15. August 2010, brian m. carlson wrote:
> The Unix tradition is for programs to run silently unless there's a
> problem.  [...]
>
> I have no problem with programs taking an environment variable or a
> command line option in order to produce debugging output, but it
> shouldn't be the default.  

Amen.

> When you run these programs outside of a 
> terminal, the output goes to .xsession-errors.  Logging a lot of useless
> debugging information makes finding actual problems in .xsession-errors
> a lot less likely.

That, and it also fills up the homedirectory (and iceweasel+flash does this 
rather quickly). In environments where home is limited to something low as 
one or two GB (which is a reallife example as there were a lot of of 
homedirectories and they should be backuped) this leads to a denial of 
service, home is full and the user cant log in.

IIRC we've used rm'ing .xsession-errors on login as a workaround. Which is as 
useful for debugging as linking it to /dev/null would be.

So I'm all for a policy demanding silent output as default. 


cheers,
Holger


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

Re: Debug output etc, cluttering the terminal

[Roger Leigh]

On Sun, Aug 15, 2010 at 10:02:15AM +0100, Neil Williams wrote:
> On Sun, 15 Aug 2010 12:44:59 +0800
> Paul Wise  wrote:
> 
> > On Sun, Aug 15, 2010 at 7:09 AM, Neil Williams 
> > wrote:
> > 
> > > It's not clutter. If you don't want to see it, run the command and
> > > redirect stderr.
> > 
> > debug output should certainly not be output by default in released
> > versions without a command-line or configuration option turning it on.
> 
> On the contrary, I've outlined some situations where on-by-default is
> the best way to identify the bug itself.

If you're not specifically debugging, it's useless noise that masks
more important stuff.  Just add a --debug option or a DEBUG
environment variable and you then have a well-behaved program rather
than one which spews irrelevant crap all over your work.

This is a beef I have with all KDE-based programs, as well a a large
number of GTK+-based programs.  These messages add zero value, and
should not be enabled in a production release--their developers
should have noticed and fixed them prior to release.  In most cases
they aren't even debugging output--they are pointless chatter that
noone except the developers would care about.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Debug output etc, cluttering the terminal

[Michael Welle]

Hello,

Neil Williams  writes:

> On Sun, 15 Aug 2010 08:51:21 +0200
> Michael Welle  wrote:
>
>> > It's debug output, it is useful when debugging and you need the
>> > output, e.g. when fixing bugs and the user can just be asked to run
>> > the command from the terminal and post the output to help in
>> > debugging the bug report. Generally, the debug output for a
>> > particular release tends to reflect the issues which upstream were
>> > working on most intensively before that release and therefore can
>> > have a direct impact on the likelihood of new bugs or regressions
>> > in old bugs.
>> >
>> > It's not clutter. If you don't want to see it, run the command and
>> > redirect stderr.
>> I agree with your opinion about the usefulness of debug output. And
>> -as one might guess- I disagree with your opinion about  how debug
>> output should be handled. Do Debian distribute programmes to its user
>> base, that are still in debug phase?
>
> Yes and will continue to do so. All software is susceptible to bugs and
> all software needs to have debug support. Mature software needs more
> debug support than pre-alpha software because bugs in mature packages
> tend to be corner-cases and obscure use cases, i.e. harder to identify.
>
> Every software package is constantly being debugged. Even the kernel
> produces debug output in the case of particular errors - including
   ^
I haven't seen that the kernel is constantly filling my terminals or the
log files with that kind of messages that I have quoted in my first
posting. If an application traps into an error condition and then
dumps its state I'm fine with that.


> messages which appear on every terminal on the machine and sound a
> fixed volume beep. Depending on the circumstances, this can be
> something as simple as not taking a USB networking interface down
> before removing the USB cable. Depends which module is in use.
>
>> Aren't debug switches sold
>> anymore?
>
> "sold" ??? Programs support --debug or --verbose options on the command
> line for debugging of errors which are not often seen.
I have the feeling (again, no numbers here) that the number of cases were
such output is grabbed, attached to a proper bug report and then results
in a solution of the bug is virtualy zero. Why? Well, one starts the
application, the application crashes. One wonders, starting the
application again to see what happens. Now the application might work or
it had eaten the data base. In both cases it is unlikely that you can
find the relevant output in your terminal, if it is still open.


>> One can forget to switch debug output off. That's no biggy,
>> mistakes happen. But have it switched on per default is strange and
>> embarassing.
>
> Nothing of the sort. Programs that do not provide debug output should
> make log files containing debug output.
That is the point. I work at an application that can produce gigbytes of
logs per day. From the logs you can reconstruct everything the system
had done, even the data that flowed between the server and its
clients. But it uses files for logging and a sane default log
level. Potential customers would kick my ass if the system would behave
different ;).


> When bugs are hard to reproduce, having debug output on by default is
> extremely important for many mature packages.
Why don't clutter Emacs, gv, X, sed, perl, openoffice (I don't know
for sure) etc. pp. the terminals with such debug messages?


> This isn't about forgetting to switch debugging off, this is about
> helping users and developers actually fix bugs.
No.

Regards
hmw

-- 
biff4emacsen - A biff-like tool for (X)Emacs
http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html
Flood - Your friendly network packet generator
http://www.c0t0d0s0.de/flood/flood.html


-- 
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/87vd7c6um9@stella.c0t0d0s0.de

Re: Debug output etc, cluttering the terminal

[Christoph Egger]

Neil Williams  writes:
> On Sun, 15 Aug 2010 02:23:32 +
> "brian m. carlson"  wrote:
>> On Sun, Aug 15, 2010 at 12:09:42AM +0100, Neil Williams wrote:
> Redirect stderr when opening the file or work out why okular was
> selected in the first place. Moaning in the general direction of all
> developers everywhere isn't helpful. Do something to identify the
> problem, not the symptom. BTW evince produces debug messages when
> loading some PDF files too, so this isn't just an okular thing.

Yeah but I've never seen scramblings on my terminals long after
evince has quit as these kde stuff does with some backgrounded helpers
still running (and not ever terminating) and continuously writing to
some terminal that happens to have started the first KDE app or so.


-- 
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/87tymw6x4o@chillida.ipv6.sieglitzhof.net

Re: Debug output etc, cluttering the terminal

[Michael Welle]

Hello,

Neil Williams  writes:

> On Sun, 15 Aug 2010 08:57:56 +0200
> Michael Welle  wrote:
[...]
>> My feeling is that many developers 
   ^^
>> don't care because most users might not be aware of what is happening.
>
> That is a very cavalier attitude to how developers manage their
> software. If you have any basis for that accusation I suggest you be
> open and name names.
I thought that the used phrase implied that I can't come up with exact
numbers. But you are right, the above statement is a bit broad. Let's
say that some developers don't seem care.


>> They may start the application by mouse clicking and so they don't
>> know about stdout and stderr.
>
> Users may but developers will be looking for that debug output and
> starting the program from the command line explicitly to be able to
> collect it. (Filing a bug will usually result in the user being asked
> to start the program from the command line too.)
If developers want to do so, they should use the debug switch. If users
find a possible bug or are just interested into the output they can use
this switch, too. If the developer has the feeling that it could be
helpful to log every cruft she should use some logging facility. One,
that can be switched off ;).

Regards
hmw

-- 
biff4emacsen - A biff-like tool for (X)Emacs
http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html
Flood - Your friendly network packet generator
http://www.c0t0d0s0.de/flood/flood.html


-- 
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/87r5i06u7u@stella.c0t0d0s0.de

Re: Debug output etc, cluttering the terminal

[Michael Welle]

Hello,

Josef Spillner <2...@kuarepoti-dju.net> writes:

> Am Samstag, 14. August 2010, 19:59:50 schrieb Michael Welle:
>> Hello,
>> 
>> what is the reason that many applications clutter the terminal with
>> output that is obvisously debug output? Lets take digikam as an
>> example:
>
> In the specific case of Digikam and other KDE applications, you can run 
> kdebugdialog to control the debugging messages. In particular, there is a 
> convenient switch to turn them off completely.
as said earlier in this thread, switching debug msg off with this dialog
changed (nearly?) nothing for me, except that the changes are reflected in
~/.kde/share/config/kdebugrc.

[...]
> When KDE applications are run in a KDE environment, the debug output is 
> normally not an issue because even terminal-using people prefer KRunner's 
> autocompletion over bash's and hence don't see the debug
> messages. However, it  
> is certainly an upstream goal to make KDE applications play nice in other 
> environments both visually and behaviourally.
That's what I mean as I stated that some developers don't seem to
care. 'Aus den Augen, aus dem Sinn' so to speak ;).


> I see your point in bringing this up on this list to end up with distribution-
> wide guidelines, but for pragmatic reasons I think you're better off 
> contacting 
> the application or framework maintainers directly. KDE has one debugging 
> system, Mozilla has another one, the Linux kernel has yet another one for the 
> primary terminal, Java apps have their own local logging policies and so on. 
> It would be a huge task trying to unify the policies.
Jepp, you are right. But I guess I'm not passionated enough with this
topic, to push the thing. The output annoys me every time I see it and I
brought it up on this list to see what others think about it and perhaps
make them thinking about it. 


Regards
hmw

-- 
biff4emacsen - A biff-like tool for (X)Emacs
http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html
Flood - Your friendly network packet generator
http://www.c0t0d0s0.de/flood/flood.html


-- 
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/87k4ns6ti4@stella.c0t0d0s0.de

Re: status of /etc/environment?

[Christoph Anton Mitterer]

On Sat, 2010-08-14 at 16:18 -0700, Steve Langasek wrote:
> It's actually a bug that /etc/environment is no longer created by default;
Tested a bit more and it seems to be created,... but only when
installing the first time (i.e. when package was not installed before).
Reinstalling doesn't create it back.


Cheers,
Chris.


-- 
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/1281873570.3284.95.ca...@fermat.scientia.net

Re: Debug output etc, cluttering the terminal

[Tollef Fog Heen]

]] Josef Spillner 

| When KDE applications are run in a KDE environment, the debug output is 
| normally not an issue because even terminal-using people prefer KRunner's 
| autocompletion over bash's and hence don't see the debug messages. However, 
it 
| is certainly an upstream goal to make KDE applications play nice in other 
| environments both visually and behaviourally.

I would guess they still fill up the .xsession-errors file, though?  At
least for me, that file is mostly useless due to:

« ...Too much output, ignoring rest... »

as the last line.

[...]

| It would be a huge task trying to unify the policies.

Sure, but so is making a distro, and having unified policies is a fairly
big part of making a distro. :-)

-- 
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/87fwyg9ih2@qurzaw.linpro.no

Re: Bug#592877: ITP: apt2 -- Advanced Package Tool 2

[David Kalnischkies]

(cross post to merge the two "independent" threads
http://lists.debian.org/debian-devel/2010/08/msg00338.html
http://lists.debian.org/deity/2010/08/msg00097.html
and to ensure everyone has the same information.
In case you want to discuss the topic feel free to do it at deity@)

We started this discussion already at the announcement mail
for this so called Codename:APT2 so for more context see
http://lists.debian.org/deity/2010/08/msg00057.html
Make sure to read the follow-ups of the two threads above also.
Even more was it discussed on IRC #debian-apt


For the topic itself:
I already got my just deserts so no further comment from me -
beside that i am hereby announcing APT3 which will be written in brainfuck…
(and i am hereby registering APT42 for Michaels or my own use, too)

++
[>+>+++>++>>++>+++<<-]
>>>+.>..<<++.>>>++.>+.+++.<-.>.<.>.+.<.


Best regards,

David "APT{0,1} MultiArch GSoC student" Kalnischkies


--
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/aanlktinbsbghxm2n7adjsuanpmtjmbj23vgkjfp-n...@mail.gmail.com

Re: More advanced home directory creation in Debian?

[Christoph Anton Mitterer]

Hi.

I'd like the idea... it would make home-dir creation here at the faculty
a lot more easier.

On Tue, 2010-08-03 at 11:08 +0200, Petter Reinholdtsen wrote:
> The location could for example be /etc/skel.d/
I'd however suggest e.g. /etc/adduser.d or so... or at least not skel.d
Conceptually the skel contents are copied to the homedir, which the
skel.d contents are not but that's just cosmetics.


Cheers,
Chris.


-- 
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/1281879737.3284.129.ca...@fermat.scientia.net

gutenprint maintenance

[Roger Leigh]

Hi folks,

I'm still looking for a replacement maintainer for gutenprint.
Someone who actually uses it regularly and has a printer which
they can use for testing who can do a proper job of maintaining
it.

I lack the time and a supported printer, so I can't test it.
I've uploaded the latest stable release but can't do any
serious testing.  As it stands, I don't even know if the
package works at all, and I don't have time or facilities to
look at bugs or improve the package.

The package is in collab-maint (git).
  git://git.debian.org/git/collab-maint/gutenprint.git
  ssh://git.debian.org/git/collab-maint/gutenprint.git


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Closing non-bugs (a.k.a. fixed version is same as found version)

[Luk Claes]

Hi

When I go through RC bugs I see more and more bugs which are both found
and fixed with the same version.

This does NOT work: these bugs are treated as if they are not fixed at all.

Please do not version bug closures when there were no changes to the
source package to get the bug fixed!

Note also that the same rule applies for binNMUs: binNMU versions are
treated as the corresponding source version (aka without the +bN). So
please do not version bug closures where the bug got fixed via a binNMU!

So when closing these bugs, please send a mail to -d...@b.d.o
without mentioning a version pseudo header.

Cheers

Luk


-- 
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/4c67f8cf.80...@debian.org

Re: Closing non-bugs (a.k.a. fixed version is same as found version)

[Guus Sliepen]

On Sun, Aug 15, 2010 at 04:25:19PM +0200, Luk Claes wrote:

> When I go through RC bugs I see more and more bugs which are both found
> and fixed with the same version.
> 
> This does NOT work: these bugs are treated as if they are not fixed at all.

Why not change the way they are treated? You can easily use the date a message
is sent to bugs.debian.org to see if it comes before or after other messages
closing/opening the bug tagged with the same version. 

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Re: Closing non-bugs (a.k.a. fixed version is same as found version)

[Luk Claes]

On 08/15/2010 04:41 PM, Guus Sliepen wrote:
> On Sun, Aug 15, 2010 at 04:25:19PM +0200, Luk Claes wrote:
> 
>> When I go through RC bugs I see more and more bugs which are both found
>> and fixed with the same version.
>>
>> This does NOT work: these bugs are treated as if they are not fixed at all.
> 
> Why not change the way they are treated? You can easily use the date a message
> is sent to bugs.debian.org to see if it comes before or after other messages
> closing/opening the bug tagged with the same version. 

Because it is sane to assume that when a bug is found and fixed in the
same version that it's better to play on the safe side and treat it as
found in that version.

Though one should contact debbugs maintainers if you think this should
be changed.

It's very strange that you think it's ok to mark a bug as fixed in a
specific version even if there was nothing changed in the package to get
the bug fixed IMHO.

Cheers

Luk


-- 
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/4c680064.1040...@debian.org

Re: Debug output etc, cluttering the terminal

[Wouter Verhelst]

On Sun, Aug 15, 2010 at 10:05:17AM +0100, Neil Williams wrote:
> Users may but developers will be looking for that debug output and
> starting the program from the command line explicitly to be able to
> collect it. (Filing a bug will usually result in the user being asked
> to start the program from the command line too.)

Sure. And there is no reason why such a request could not include
something along the lines of 'please run the application with the -d
option so that it produces debug output'.

Neil, nobody is disclaiming that debug output can be useful for a
developer. But an application that has nothing useful to say should not
say anything. The default for _any_ application should be to _not_
produce any output until there is a problem. 

This debugging output does cause problems: it slows down the application
(doing 'cout' or 'printf' when they are not needed *does* take up some
amount of CPU time, which becomes significant when the amount of output
gets rather large), it generates huge .xsession-errors files that can
cause problems for people with low quotas or for people who actually
need the *useful* information in those files, and (in the case of KDE
applications) it pollutes random unrelated terminals with output long
after the application that was started on that terminal has exited, just
because KDE applications like to start background daemons.

There is no good reason why doing debugging output should be the
*default*.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
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/20100815150857.gl27...@celtic.nixsys.be

Re: Debug output etc, cluttering the terminal

[Josef Spillner]

Am Sonntag, 15. August 2010, 14:19:05 schrieb Tollef Fog Heen:
> I would guess they still fill up the .xsession-errors file, though?  At
> least for me, that file is mostly useless due to:
> 
> « ...Too much output, ignoring rest... »
> 
> as the last line.

Yes they would, because the applications still see their stderr channel and 
happily write to it. What I meant with "not an issue anymore" was the issue of 
intermixed useful and useless terminal output; of course the issue of wasting 
CPU and perhaps harddisk resources remains when debugging is not disabled.

Considering Holger's comment about disks filling up, the scope of this issue in 
the context of resource saving and energy-efficient computing then extends to 
/var/log and logging in general and includes the question of necessity and 
longevity of logfiles bound to system and user sessions.
It also touches on badly written default cron jobs which are just as resource-
wasting and user-annoying for little gain, for example non-incremental index 
updates. When you run a system on battery, maybe even from USB stick or SD 
card, all of this equally matters.

I'm all for solving these problems, but optimistically spoken I'd be 
positively surprised if Debian could turn "no user annoyance by default" into 
a universally accepted, enforceable and release-goal-timed policy before 2020. 
Therefore, I suggested tracking this at the per-package/per-originator level 
to try getting rid of the biggest offenders first.
By doing so, the motives of the KDE-Qt/Gtk+/WINE/ALSA/... maintainers, for 
example, for having the debug output enabled by default can be found out and 
serve as input for a decision about a policy. I'm sure the debug areas are not 
enabled by default to annoy users, this is merely a side effect :-)

Josef


--
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/201008151730.05706.2...@kuarepoti-dju.net

Re: Debug output etc, cluttering the terminal

[Lars Wirzenius]

On su, 2010-08-15 at 14:19 +0200, Tollef Fog Heen wrote:
> I would guess they still fill up the .xsession-errors file, though?  At
> least for me, that file is mostly useless due to:
> 
> « ...Too much output, ignoring rest... »
> 
> as the last line.

It's pretty clear to me that both .xsession-errors and the stderr of GUI
apps are lousy ways of logging debugging messages. Something similar to
syslog for a per-user/per-session would be a very useful thing to have,
in my opinion.

A systematic way of doing that would help with log rotation (thus saving
disk space), and bug reporting (automatically attach logs for the
crashed process), etc.



-- 
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/1281888093.5840.109.ca...@havelock

Re: Debug output etc, cluttering the terminal

[Neil Williams]

On Sun, 15 Aug 2010 08:08:57 -0700
Wouter Verhelst  wrote:

> On Sun, Aug 15, 2010 at 10:05:17AM +0100, Neil Williams wrote:
> > Users may but developers will be looking for that debug output and
> > starting the program from the command line explicitly to be able to
> > collect it. (Filing a bug will usually result in the user being
> > asked to start the program from the command line too.)
> 
> Sure. And there is no reason why such a request could not include
> something along the lines of 'please run the application with the -d
> option so that it produces debug output'.

Unreproducible bugs will, by their nature, not be fixable if that is
applied rigorously or as a change in Policy, which some were
suggesting here. 

> Neil, nobody is disclaiming that debug output can be useful for a
> developer. But an application that has nothing useful to say should
> not say anything. The default for _any_ application should be to _not_
> produce any output until there is a problem. 

The amount of debug output has to be controlled, yes - it should only
relate to areas where bugs are likely to be hard to reproduce without
such output - and there are applications (I'm looking at you
epiphany-browser and you, iceweasel) which seem to pay little attention
to the notices produced by g_return_if_fail statements which result
from errors in their own code. I won't defend that because if a library
or function call fails an assertion, then whatever you're doing to call
that function is *wrong*, so fix the code. ;-)

(Even if only to do whatever error checking the function does before
actually calling the function. The process of identifying WHY an
assertion fails is itself bug fixing. Passing NULLs to functions which
cannot accept NULLs without failing an assertion is a BAD habit. Stop
it, check your pointers BEFORE making the call.)

Most of this is upstream stuff - that's why I care about Debian not
mandating that all this stuff should disappear, it isn't about just us,
it's about helping upstream fix bugs.

Most of the stuff in ~/.xsession-errors which has been mentioned here,
are exactly these kind of assertion failure errors:

(gnome-power-manager:2346): GLib-GObject-WARNING **: value "-nan" of
type `gdouble' is invalid or out of range for property `percentage' of
type `gdouble'

(polkit-gnome-authentication-agent-1:2468): GLib-CRITICAL **:
g_once_init_leave: assertion `initialization_value != 0' failed

Those are BUGS. It might not cause symptoms now but it is still
relevant to how other bugs in that application are triaged. The
upstream code needs to be fixed to check these values before passing
them to the relevant function.

I spend a lot of time tracking down just these kind of assertion
failures in my own upstream code. It is an irksome task at times but
that is no excuse for not fixing these things. Indeed, it is a prime
motivation for working out exactly where more of such assertion tests
need to be implemented.

Debug output needs to be retained but it also needs to be managed and
not ignored.

> This debugging output does cause problems: it slows down the
> application (doing 'cout' or 'printf' when they are not needed *does*
> take up some amount of CPU time, which becomes significant when the
> amount of output gets rather large),

... when abused, yes. There are ways to avoid this problem (e.g. when
debugging thread-locking issues which are always time-sensitive) IF
the debug calls themselves are carefully managed.

> it generates
> huge .xsession-errors files that can cause problems for people with
> low quotas or for people who actually need the *useful* information
> in those files, and (in the case of KDE applications) it pollutes
> random unrelated terminals with output long after the application
> that was started on that terminal has exited, just because KDE
> applications like to start background daemons.
> 
> There is no good reason why doing debugging output should be the
> *default*.

Not a default across all packages and all debug output but there are
situations where *some* debug output needs to be part of the default
output of the application in order to actually capture the data
necessary to fix the bugs.

Some applications, even some mature applications, need to be able to
output debug information to the controlling terminal as a matter of
course in order to fix unreproducible and/or intermittent bugs.

Debian should not prevent this behaviour but encourage upstreams to
*moderate* their use of default debug output by getting them to fix
their own code where it causes assertion failures in other code and by
prompting upstream to consider downgrading certain debug output to
the non-default output level.

Manage the debug output and everyone wins because the output itself
becomes easier to understand. Remove the debug output completely and
everybody loses, especially users.

It is not clutter but it does need to be managed to contain only useful
and relevant debug data. It is simply not helpfu

Re: Closing non-bugs (a.k.a. fixed version is same as found version)

[Guus Sliepen]

On Sun, Aug 15, 2010 at 04:57:40PM +0200, Luk Claes wrote:

> > Why not change the way they are treated? You can easily use the date a
> > message is sent to bugs.debian.org to see if it comes before or after other
> > messages closing/opening the bug tagged with the same version. 
> 
> Because it is sane to assume that when a bug is found and fixed in the
> same version that it's better to play on the safe side and treat it as
> found in that version.

I think that if people are actively opening and closing bugs (in that order)
with the same Version tag, they expect the bug to be closed. I also do not
think that there is any danger in having it marked as closed, it can always be
reopened later.

> Though one should contact debbugs maintainers if you think this should
> be changed.

Ok.

> It's very strange that you think it's ok to mark a bug as fixed in a
> specific version even if there was nothing changed in the package to get
> the bug fixed IMHO.

Well, if, like in your example, a binNMU fixes a problem, then I do not see it
as illogical for someone to close a bug with a Version tag that is the same as
the version the bug was reported in. Maybe debbugs can be changed to handle
binary Version tags?

How often, when a bug is opened and closed with the same Version tag, was one
of the two Version tags really wrong?

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Re: Closing non-bugs (a.k.a. fixed version is same as found version)

[Luk Claes]

On 08/15/2010 06:17 PM, Guus Sliepen wrote:
> On Sun, Aug 15, 2010 at 04:57:40PM +0200, Luk Claes wrote:

>> It's very strange that you think it's ok to mark a bug as fixed in a
>> specific version even if there was nothing changed in the package to get
>> the bug fixed IMHO.
> 
> Well, if, like in your example, a binNMU fixes a problem, then I do not see it
> as illogical for someone to close a bug with a Version tag that is the same as
> the version the bug was reported in. Maybe debbugs can be changed to handle
> binary Version tags?
> 
> How often, when a bug is opened and closed with the same Version tag, was one
> of the two Version tags really wrong?

In most of the cases it was in the sense that nothing changed in the
package not even a rebuild was required. Only a very few were fixed with
rebuilds.

Cheers

Luk


-- 
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/4c68188b.6010...@debian.org

Bug#593122: ITP: algotutor -- program for observing the intermediate steps of algorithm

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 


* Package name: algotutor
  Version : 0.8.6
  Upstream Author : Chao-Kuei HUNG 
* URL : http://people.ofset.org/~ckhung/p/algotutor/
* License : GPL-3
  Programming Lang: Perl
  Description : program for observing the intermediate steps of algorithm

 algotutor is an interactive program for observing the intermediate
 steps of algorithms ("algorithm animation"). The target audience is
 computer science students and/or anyone who studies algorithms and/or
 data structures. One can create data files in plain text format
 (actually perl anonymous hashes, but one need not care) and let
 algotutor runs through some predefined algorithm. Then one can step
 backward and forward through the execution sequence of the algorithm
 at different levels of details.



-- 
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/20100815162021.27052.12436.report...@www.khaznadar.fr

Re: Debug output etc, cluttering the terminal

[Timo Juhani Lindfors]

Wouter Verhelst  writes:
> gets rather large), it generates huge .xsession-errors files that can
> cause problems for people with low quotas or for people who actually

Indeed. I often find the SD card of my PDA (openmoko) filled with
a useless .xsession-errors.


-- 
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/84tymval4d@sauna.l.org

Bug#593126: ITP: chemical-structures -- A set of molecular structures in open formats

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 


* Package name: chemical-structures
  Version : 2.1.dfsg.1
  Upstream Author : Jerome PANSANEL 
* URL : http://sourceforge.net/projects/chem-file/
* License : DFSG-free: share alike, no endorsement
  Programming Lang: XML, XSL
  Description : A set of molecular structures in open formats

 hundreds of molecular structures, in the following classes: alcohols,
 aldehydes, alkanes, alkenes, amides, amines, amino_acids, aromatics,
 carboxylic_acids, esters, ethers, fatty_acids, haloalkanes, ketones,
 nitriles,nucleobases, water.



-- 
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/20100815165642.523.41500.report...@www.khaznadar.fr

Bug#593130: ITP: pymecavideo -- a pedagogic tool to analyze video records for mechanics

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 


* Package name: pymecavideo
  Version : 5.0
  Upstream Authors : Jean-Baptiste Butet , 
Georges Khaznadar 
* URL : 
http://outilsphysiques.tuxfamily.org/pmwiki.php/Oppl/Pymecavideo
* License : GPL-3
  Programming Lang: Python
  Description : a pedagogic tool to analyze video records for mechanics

 You can track the movement of one or many points in video frames and export
 the position measurements to standard analysis tools.



-- 
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/20100815171428.4414.20343.report...@www.khaznadar.fr

Re: RFC: Policy 10.1 and appropriateness of package conflicts

[Andreas Tille]

On Sat, Aug 14, 2010 at 10:32:41AM +0900, Charles Plessy wrote:
> 
> Also, the change of environment is not to make usable a program that would not
> be, but simply to make it the default choice or not, under its original
> upstream name, the one that our users expect, read in the documentation, hear
> from their colleagues and use in their scripts.

IMHO the strongest argument of Russ was that your proposed way to set
the PATH variable in /etc/profile.d just does not work for all shells,
specifically for dash and the frequently used csh clones which are
frequently used in scientific environment.
 
> There is an obvious selection pressure against file conflicts. The conflicts
> that we encounter in Debian are the ones that does no make the program
> problematic on the majority of user's systems outside the Debian world. I 
> think
> that we already trust our maintainers to not provide a program under its 
> original
> upstream name if it would causes system-wide side effects to make it a default
> after changing the PATH. The current approach is to propose to the user to 
> edit
> the PATH by himself, with one directory per package having a conflict. What I
> propose is to group these paths per theme (corresponding to Debian Blends),
> and to set it up automatically only if the user is member of the Blends 
> group. It
> is mostly an automation of an already existing approach.

So in principle I like the idea for Blends and we just discussed this
previosely - but there is no *reliable* way to let it work because we
do not really have control about the shell a Blend user is using.
 
Kind regards

 Andreas. 

-- 
http://fam-tille.de


-- 
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/20100815174857.gf14...@an3as.eu

Bug#593132: ITP: pysatellites -- simulates the launching of satellites

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 


* Package name: pysatellites
  Version : 1.0
  Upstream Author : Georges Khaznadar 
* URL : 
http://outilsphysiques.tuxfamily.org/pmwiki.php/Oppl/Pysatellites
* License : GPL-3
  Programming Lang: Python
  Description : simulates the launching of satellites

 This program can be used to train people to spatial mechanics at an
 elementary level. You are given the power to launch a satellite, from
 outside the atmosphere, around a handfull of predefined planets, or around
 any special object you may imagine. Input the intial velocity vector of the
 satellite, and you will get the simulated trajectory, as well as some
 information like the plots of variation of speed. As an extra, you can
 compute a movie, which represents the planet seen from the satellite's
 point of view during its orbital period.



-- 
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/20100815173253.6825.38541.report...@www.khaznadar.fr

Re: status of /etc/environment?

[Steve Langasek]

On Sun, Aug 15, 2010 at 01:59:30PM +0200, Christoph Anton Mitterer wrote:
> On Sat, 2010-08-14 at 16:18 -0700, Steve Langasek wrote:
> > It's actually a bug that /etc/environment is no longer created by default;
> Tested a bit more and it seems to be created,... but only when
> installing the first time (i.e. when package was not installed before).

Ah, I didn't remember that this had been fixed. ok.

> Reinstalling doesn't create it back.

Nor should it.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@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/20100815180305.gc19...@dario.dodds.net

Bug#593135: ITP: pyacidobasic -- a simulation tool for acido-basic titrations

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 


* Package name: pyacidobasic
  Version : 0.1
  Upstream Author : Georges Khaznadar 
* URL : 
http://outilsphysiques.tuxfamily.org/pmwiki.php/Oppl/Pyacidobasic
* License : GPL-3
  Programming Lang: Python
  Description : a simulation tool for acido-basic titrations

 python-acidobasic allows to compose a mixture of acid or base reactives, 
 and to simulate their titration by one acid or base. pH and concentration
 curves are displaied instantly when the compisition of all chemicals are
 defined.



-- 
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/20100815174637.12716.46495.report...@www.khaznadar.fr

Re: Bug#592877: ITP: apt2 -- Advanced Package Tool 2

[Steve Langasek]

On Fri, Aug 13, 2010 at 09:31:31PM +0200, Julian Andres Klode wrote:
> Let's keep the APT2 name instead of the UPS name. The UPS name is a good
> joke, but it's not good for a real program name, because:

>   * UPS = Uninterruptible Power Supply
>   * UPS = United Parcel Service
>   * Ups = a debugger
>   * It's a too common name

> I think that all in all, apt2 is a known name already, it can be found
> easily, it can not be confused with other things.

Is apt2 using the same resolver as apt, and are changes to that resolver
coordinated with the existing apt implementation?

Does apt2 implement support for multiarch?

> Well, you're the only one to complain about the naming.

I also object to giving this package a name that implies it's the successor
implementation to the current apt when, today, it is not.  Some of your
comments suggest that the code isn't even written yet.  I don't know why you
would submit an ITP if there's nothing yet to be packaged.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@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/20100815182826.ge19...@dario.dodds.net

Re: Bug#592877: ITP: apt2 -- Advanced Package Tool 2

[Lucas Nussbaum]

On 15/08/10 at 11:28 -0700, Steve Langasek wrote:
> On Fri, Aug 13, 2010 at 09:31:31PM +0200, Julian Andres Klode wrote:
> > Let's keep the APT2 name instead of the UPS name. The UPS name is a good
> > joke, but it's not good for a real program name, because:
> 
> >   * UPS = Uninterruptible Power Supply
> >   * UPS = United Parcel Service
> >   * Ups = a debugger
> >   * It's a too common name
> 
> > I think that all in all, apt2 is a known name already, it can be found
> > easily, it can not be confused with other things.
> 
> Is apt2 using the same resolver as apt, and are changes to that resolver
> coordinated with the existing apt implementation?
> 
> Does apt2 implement support for multiarch?
> 
> > Well, you're the only one to complain about the naming.
> 
> I also object to giving this package a name that implies it's the successor
> implementation to the current apt when, today, it is not.

FWIW, I also object. The jabberd2/jabberd14 is a big mess, let's avoid
repeating the same mistake with APT.

Lucas


-- 
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/20100815185146.ga2...@xanadu.blop.info

Re: Closing non-bugs (a.k.a. fixed version is same as found version)

[Don Armstrong]

On Sun, 15 Aug 2010, Guus Sliepen wrote:
> I think that if people are actively opening and closing bugs (in
> that order) with the same Version tag, they expect the bug to be
> closed. I also do not think that there is any danger in having it
> marked as closed, it can always be reopened later.

The danger is that packages can transition without a bug having
actually been fixed. It's always conservative to have open have
precedence over closed. [When was the last time that you looked
specifically for bugs which were erroneously closed without also
seeing the behavoir that the bug caused?]
 
> How often, when a bug is opened and closed with the same Version
> tag, was one of the two Version tags really wrong?

First off, these are found and fixed versions that we're talking
about; "tags" are something else entirely.

Secondly, any time that a bug is found and fixed in the same version,
one (or both?) of them is wrong. There's no way for the BTS to know
which it is, so it assumes that the found version is correct, and the
fixed version is wrong.

In the case of bugs which can be fixed by any upload without changes
to the source package, the change that needs to be made is to allow
bugs to be found in a particular binary version which does not also
affect the decendents of that version. I know how to implement this,
and have thought about it for a while. I haven't implemented it yet
because there aren't too many of these bugs, and the UI and
far-reaching effects of it is going to be annoying.


Don Armstrong

-- 
You could say she lived on the edge... Well, maybe not exactly on the edge,
just close enough to watch other people fall off.
  -- hugh macleod http://www.gapingvoid.com/Moveable_Type/archives/000309.html

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/20100815190650.gr17...@teltox.donarmstrong.com

Re: Bug#592877: ITP: apt2 -- Advanced Package Tool 2

[Julian Andres Klode]

On So, 2010-08-15 at 11:28 -0700, Steve Langasek wrote:
> On Fri, Aug 13, 2010 at 09:31:31PM +0200, Julian Andres Klode wrote:
> > Let's keep the APT2 name instead of the UPS name. The UPS name is a good
> > joke, but it's not good for a real program name, because:
> 
> >   * UPS = Uninterruptible Power Supply
> >   * UPS = United Parcel Service
> >   * Ups = a debugger
> >   * It's a too common name
> 
> > I think that all in all, apt2 is a known name already, it can be found
> > easily, it can not be confused with other things.
> 
> Is apt2 using the same resolver as apt, and are changes to that resolver
> coordinated with the existing apt implementation?
The solvers are not written yet (this needs input from dburrows for the
overall API (currently in discussion), and from zack for the external
solver; although the latter could be delayed). After all, the goal is to
have a clear, documented, understandable and useful code. And APT's
solver is a hell to understand in my opinion.

> 
> Does apt2 implement support for multiarch?
The cache can store all information needed for multi-arch, and the API
does not really care about it (package objects are
, so the difference between two
different architectures and two different versions is the same). Some
parts for making the API easier to use are missing though, and the
multi-arch information is not written yet (as we currently just import
the APT cache).

> 
> > Well, you're the only one to complain about the naming.
> 
> I also object to giving this package a name that implies it's the successor
> implementation to the current apt when, today, it is not.  Some of your
> comments suggest that the code isn't even written yet.  I don't know why you
> would submit an ITP if there's nothing yet to be packaged.
Well, in the few hours it had a different name, I considered uploading
it to experimental; afterwards, I decided not to waste this bug by
closing it, and thus renamed it to the current codename. And I can't
play renaming all the time, this would be counter productive to the
overall progress.


For your information, the code is at
http://git.debian.org/?p=users/jak/apt2.git and currently has:
  * capt (command-line APT); with the following subcommands
  * Reading: show, showpkg, stats, madison, pkgnames, policy
  * apt-config replacement: config-dump and config-get
  * Limited 'why' and 'why-not'
  * The most advanced pinning implementation for binary packages:
  * Pinning by source packages works
  * Regular and glob()-like expressions are supported in
Package, Source, and Pin; although slow for the first
two.
  * Completely implemented in 730 lines, where 469 are code;
the remaining ones (261) are comments and empty lines.
  * A test suite

In planning and/or development are:
  * Dropping the APT cache importer and parsing the files ourselves
(that's a matter of abstracting things)
  * Dependency solver
  * Downloader
  * Installing stuff (depends on parts of solver)
  * Support for non-dpkg distributions (Slackware,Fedora,MeeGo)

What it shall be / why it is here:
  * An APT implementation that is easy to understand
  * An APT implementation that supports other package formats
  * An APT implementation that is designed for multi-arch from the
start
  * An APT implementation that does not bind apps to the GPL


-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.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/1281902427.22201.113.ca...@jak-thinkpad

Re: Notes from the DebConf Source Format BoF

[Roger Leigh]

On Tue, Aug 10, 2010 at 08:27:24PM -0700, Russ Allbery wrote:

Since this is open for discussion, some comments about my take
on some of the discussed points:

> ftp-team is concerned about doing license checks across the entire git
> archive Colin points out that we're in the same situation with Alioth for
> redistributability.  However, it is easier to withdraw things from Alioth
> than from the archive.  And redistributability (the legal requirement) is
> a lot less of a bar than what we check for DFSG.

I can see that this could be a legitmate cause for concern, especially
since the history is essentially immutable and if "tainted" will
remain so unless it's deliberately excised and the history is altered.
However, is this a problem in reality, or just theoretical?  If it's
only a problem occasionally, then could this be better dealt with
(with the cooperation of upstream) on a case-by-case basis as and when
this becomes a real issue?

I'm not a fan of shallow clones due to the loss of history--we're
losing out on the main advantage to having a git repo at this point.
I'm not an expert WRT shallow clones, but can you get back to a full
clone given the packaged repo?  "get fetch --depth" appears to do this,
though I don't know how to specify "everything" if you don't know the
remote max depth.  So shallow clones seem fine as a source package
distribution format, but it would be nice to have debcheckout or
dpkg-source (or whatever tool is most appropriate) have the ability
to get back to the original state for actual work (and then strip
it back out again when repacking) without me needing to do the extra
work by hand.

> - Colin wonders why we don't have a central directory of all the source
>   package packaging repositories rather than putting it in package metadata.
>   * Even with that, if you look at stuff in stable, the chances are that a
> lot of those repositories have gone away.

Having a central clone of the upstream repo, or at least the Debian
repo for each git-maintained package would go some way to alleviating
some of these concerns.  They could even automatically track upstream/
debian repos á la launchpad does for bzr.

> - debcheckout is only really useful if you're about to do development
>   * There's no uniform way to get a particular revision of the package.
>   * It may not be tagged, it may be on another branch, etc.

This is the key limitation of debcheckout as it stands.  However, while
I'm currently adding Vcs-Git* to debian/control by hand, could this
be taken directly from "git remote show" in the future to make it
reflect the exact origin?  (Would depend upon direct cloning of the
debian/upstream remote repo though.)  As mentioned, with the addition
of the --branch option to "git clone", it should be possible to specify
the exact branch.

> Joey would really rather upload his whole repository for things that he
> knows are clean, but that's a problem for ftp-master review, and you have
> to get into who you trust to make that determination.

If I tag a debian release in my repo and sign it with my Debian GPG key,
it should be possible to "upload" the new source package to Debian with
a "git push" (or upload a small .dsc and get the a central git repo to
do a pull from me).  It should all be properly verifiable from our GPG
web of trust.  Maybe best restricted to pulling from git.debian.org or
just pulling a single signed tag?

While this might seem somewhat more insecure compared with our
traditional tarball/diff upload mechanism, I don't really see that
myself.  If anything we gain rather more auditing of changes and
accountability if it's correctly signed, compared with a pile of
patches á la quilt/dpatch.  If anything bad does happen, we've got
the entire history right there with author and commiter of every
change.

> You might be able to do a shallow clone of depth one and include every signed 
> tag that matches an entry in debian/changelog
> but it may be too bloaty.  That might ease the review.
>  - How would topic branches fit into this scheme?

If they are all merged into the debian release branch then they are
certainly not needed for building, but they would be required for
making changes and so should probably be included.  The dependent
branches should show up as parents to the commit, at least for the
last release, so should be possible to include.  Maybe including
commits all the way back to the previous Debian release would allow
for easier preservation of this detail?

> Best practices for Git repository layout?
> - git-buildpackage documentation is closest to that

I would have to disagree here, the git-buildpackage default layout is
far too "Debian-centric".  By naming the Debian and Upstream branches
"master" and "upstream" it's only really useful if you're importing
upstream release tarballs.  We should really be using a "debian" branch
for Debian-specific changes, and possibly even using multiple branches
for tracking oldstable/stable/unstable/expe

Re: Notes from the DebConf Source Format BoF

[Russ Allbery]

Roger Leigh  writes:

> I can see that this could be a legitmate cause for concern, especially
> since the history is essentially immutable and if "tainted" will remain
> so unless it's deliberately excised and the history is altered.
> However, is this a problem in reality, or just theoretical?

It's definitely a real problem for some packages provided that we stick
with our rules about what's okay for Debian main in source packages.  For
example, the openafs Git repository history contains APSL-licensed code
that's not okay for main.

> If it's only a problem occasionally, then could this be better dealt
> with (with the cooperation of upstream) on a case-by-case basis as and
> when this becomes a real issue?

Upstream is not going to be willing to run git filter-branch to remove
things from their repository and invalidate all clones.  It's frequently a
challenge just to convince them to remove non-DFSG code from their
releases.  So if you're merging with upstream's Git tags as part of
packaging, which is very nice for other reasons, you'll have this problem.

> I'm not a fan of shallow clones due to the loss of history--we're losing
> out on the main advantage to having a git repo at this point.  I'm not
> an expert WRT shallow clones, but can you get back to a full clone given
> the packaged repo?

Yes, if you have access to the full repository.

>> Joey would really rather upload his whole repository for things that he
>> knows are clean, but that's a problem for ftp-master review, and you
>> have to get into who you trust to make that determination.

> If I tag a debian release in my repo and sign it with my Debian GPG key,
> it should be possible to "upload" the new source package to Debian with
> a "git push" (or upload a small .dsc and get the a central git repo to
> do a pull from me).  It should all be properly verifiable from our GPG
> web of trust.  Maybe best restricted to pulling from git.debian.org or
> just pulling a single signed tag?

That's not the problem being discussed here.  The signature is fine.  The
problem is that while Joey may think that his repository is completely
DFSG-free, it's the current job of ftp-master to actually check that.  For
a complete repository, that's a lot of work.  Should ftp-master just trust
Joey that there's no non-DFSG code anywhere in history?  Who should be
trusted?  We get into very murky ground here, which is much different than
the current review process.

>> Best practices for Git repository layout?
>> - git-buildpackage documentation is closest to that

> I would have to disagree here, the git-buildpackage default layout is
> far too "Debian-centric".

What this note meant was that it's the only one that anyone has written
down that anyone in the room mentioned.  If you have a better best
practices guide, by all means advertise it!  There was some interest in
seeing those.

> This is something to think about for the future though; dropping binary
> uploads (by maintainers, not buildds) has been on the cards for some
> time now hasn't it?  Is this still planned?

Did it ever reach the point of being planned?

> Essentially, *everything* stays in git from upstream to distributed
> releases to debian work and releases and also to downstreams.  There's
> no import of release tarballs because they are in git too, and there's
> no pristine tar because the GPG-signed tag of the distribution *is* the
> release.  Currently what an upstream releases as the tarball might not
> exactly match the release in the VCS (due to autotools bootstrap, other
> generated files etc.) so here "make dist" actually makes a separate
> "distribution" branch (as opposed to release) so you have a natural set
> of branches:
>   development → release → distribution → debian →→ downstream
> and at each step you have GPG-signed tags giving you an auditable
> chain of trust along the path.

Does any upstream do that yet?

-- 
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/87pqxjr0k5@windlord.stanford.edu

Re: why are there /bin and /usr/bin...

[Perry E. Metzger]

On Tue, 10 Aug 2010 03:15:35 -0600 Bruce Sass  wrote:
> /sbin and /usr/sbin, /lib and /usr/lib directories?
> 
> AFAICT, the reason is so that a minimal but functional system is 
> guaranteed to exist so long as a local HDD with a root filesystem
> is available (which doesn't necessarily include /usr);

The true reason is that back in ancient days, hard drives were too
small to put everything in one place, so ancient Unix machines at Bell
Labs in the 1970s ended up with some programs on the root disk and
some on the same supplementary disk where the home directories were
typically put. This was not done with any great forethought, it was
simply a temporary expediency. Because / was on the boot disk, it was
necessary to make sure that every program needed for initial boot was
there, and thus some programs were more important to put in /bin and
the like.

By the early 1990s this was long since unneeded but people continued
to do it anyway, and in fact started to think it was done for
technical reasons rather than because of a simple lack of space in an
earlier era. At this point (2010), with all of the system files
fitting in under a dollar's worth of disk space, people tell
themselves quite elaborate "just so" stories about why the segregation
is maintained.

The /bin /usr/bin (and indeed, /usr altogether) distinction is now
rather obsolete, but people have gotten so used to it that it has
become an "Onion".

For those who don't know the term "Onion", I direct you to Primo
Levi's famous story of trying to figure out why an onion was thrown
into each vat of varnish being manufactured in the factory in which he
was hired as a chemist. No one knew why the onion was thrown
in. Eventually, it transpired that the onion was there as a crude
temperature indicator -- in the days before a thermometer was used,
the onion would sizzle when the varnish reached the right temperature
-- but even though it was long since not needed, people continued the
practice because they did not know it was not needed.

Most modern Unix systems would be fine if all files in /usr were in /,
with a compatibility symlink pointing /usr at / to provide for scripts
and other programs assuming things to be in /usr, but no one dares to
do it, because the "Onion" impulse is so strong.

Perry
-- 
Perry E. Metzgerpe...@piermont.com


-- 
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/20100815183004.7f74b...@jabberwock.local

Re: Debug output etc, cluttering the terminal

[Christian PERRIER]

Quoting Michael Welle (mwe012...@gmx.net):
> Hello,
> 
> what is the reason that many applications clutter the terminal with
> output that is obvisously debug output? Lets take digikam as an
> example:


(I read most other comments in this thread before writing this)

I have to concur to everything that was brought by poeple who *don't*
want this debug gibberish to appear either in their terminal or in
their ~/.xsession-errors:

Here's mine, started yesterday morningand I barely did nothing
since then as I'm more travelling around Vermont that playing with my
KDE apps:

bubu...@mykerinos:~/travail/debian/translation/po-debconf/gitolite> ls -l 
~/.xsession-errors
-rw--- 1 bubulle bubulle 2511641 15 août  18:28 
/home/bubulle/.xsession-errors

That's 2 megabytes ofcrap:

startkde: Starting up...
kdeinit4: preparing to launch /usr/lib/kde4/libkdeinit/libkdeinit4_klauncher.so
Connecting to deprecated signal 
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
kdeinit4: preparing to launch /usr/lib/kde4/libkdeinit/libkdeinit4_kded4.so
.../...
kephald starting up 
XRANDR error base:  163 
RRInput mask is set!! 
RandRScreen::loadSettings - adding mode:  73 1280 x 800 
RandRScreen::loadSettings - adding mode:  74 1280 x 800 
.../...

And this for gazillion of linesI should try some day to check
~/.xsession-errors just after I open a session.

GNOME zealots will of course laugh and they might be right (at least
about thisapart from that, I still favor KDE as desktop
environment)...so I really hope there's a way to fix this. 

I equally hate what clutters my konsole window when I happen to
manually launch a KDE app.

And, finally, as someone who often leaves his own desktop environment
opened for months in the same session, at work, I deeply concur to
Holger's comment about wasting space in home directories (mine being
constrained to a few gigabytes). Thankfully, there, I'm not using KDE
and not even Debian, indeed..:-)



signature.asc
Description: Digital signature

Re: why are there /bin and /usr/bin...

[Steve Langasek]

On Sun, Aug 15, 2010 at 06:30:04PM -0400, Perry E. Metzger wrote:
> By the early 1990s this was long since unneeded but people continued
> to do it anyway, and in fact started to think it was done for
> technical reasons rather than because of a simple lack of space in an
> earlier era. At this point (2010), with all of the system files
> fitting in under a dollar's worth of disk space, people tell
> themselves quite elaborate "just so" stories about why the segregation
> is maintained.

You wrongly assume here that every Unix system has a hard drive as its root
filesystem.  Some root devices cost a lot more than a dollar for that amount
of disk.  Some have breakpoints beyond which it becomes an order of
magnitude more expensive to expand the root device.  Some have hard limits
on the size of the built-in media that would take you multiple man-years of
engineering effort to overcome.  Just because the original motivation for
the split is no longer applicable doesn't mean there aren't still technical
reasons to put /usr on a separate filesystem.  The fact that these reasons
are different from the original justification is uninteresting.  It doesn't
make these people fools for taking advantage of this logical separation, and
it doesn't give you any authority to break their systems because you
disagree with the principle.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@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/20100815230021.gn19...@dario.dodds.net

Re: why are there /bin and /usr/bin...

[Perry E. Metzger]

On Sun, 15 Aug 2010 16:00:23 -0700 Steve Langasek 
wrote:
> On Sun, Aug 15, 2010 at 06:30:04PM -0400, Perry E. Metzger wrote:
> > By the early 1990s this was long since unneeded but people
> > continued to do it anyway, and in fact started to think it was
> > done for technical reasons rather than because of a simple lack
> > of space in an earlier era. At this point (2010), with all of the
> > system files fitting in under a dollar's worth of disk space,
> > people tell themselves quite elaborate "just so" stories about
> > why the segregation is maintained.
> 
> You wrongly assume here that every Unix system has a hard drive as
> its root filesystem.  Some root devices cost a lot more than a
> dollar for that amount of disk.

Ah, onions.

In the embedded space, which I know a lot about, it is true that the
root FS is on flash or other expensive media -- but it isn't like /usr
is on cheaper media in such an environment, it is always part of the
root fs anyway, so it makes no difference. (If you're talking about,
say, someone with an SSD just for the boot drive, I assure you that
were awk or basename or what have you on /bin it would not make any
observable difference in their cost. Indeed, a typical set of binaries
on even a workstation laden with all the latest gadgets won't make any
real difference here.)

> Some have breakpoints beyond which it becomes an order of magnitude
> more expensive to expand the root device.

Yes, yes, but as I noted, it is almost never the case that /usr is any
differently priced, so it makes no difference. The notable difference
are people who use SSDs as their root device, and even there, it turns
out that in practice such people are putting everything but /home and
such on the SSD, and the difference in cost between 1G of SSD and 10G
is minimal.

This whole thing goes back to casual decisions made in the 1970s when
there weren't even a dozen unix machines in the world and even a 5M
hard drive was an astonishingly expensive piece of equipment, but
people are still attached to it. I suspect that in 2050, people will
still be making the same argument.

I have no actual expectation that anyone is going to change how this
is done, because /usr is so heavily ingrained in people's experience
of Unix even though it is an onion.

Perry
-- 
Perry E. Metzgerpe...@piermont.com


-- 
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/20100815192225.4432e...@jabberwock.local

Re: Debug output etc, cluttering the terminal

[gregor herrmann]

On Sun, 15 Aug 2010 18:34:56 -0400, Christian PERRIER wrote:

> Here's mine, started yesterday morningand I barely did nothing
> since then as I'm more travelling around Vermont that playing with my
> KDE apps:
> 
> bubu...@mykerinos:~/travail/debian/translation/po-debconf/gitolite> ls -l 
> ~/.xsession-errors
> -rw--- 1 bubulle bubulle 2511641 15 août  18:28 
> /home/bubulle/.xsession-errors
> 
> That's 2 megabytes ofcrap:

gre...@belanna:~$ ls -l ~/.xsession-errors
-rw--- 1 gregoa gregoa 6946783 Aug 16 00:00 /home/gregoa/.xsession-errors

Almost 7 MB ...
 
> GNOME zealots will of course laugh and they might be right (at least
> about thisapart from that, I still favor KDE as desktop
> environment)...so I really hope there's a way to fix this. 

... and I'm neither using GNOME nor KDE. The X session was started ~
5 hours ago.
 
Among the contents are e.g. ~20.000 lines saying:
(firefox-bin:28026): Gdk-WARNING **: XID collision, trouble ahead

and ~20.000 lines:
info: 0, warning: 0, error: 0
Done
which are also from iceweasel if I'm not mistaken.

Cheers,
gregor

-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Schmetterlinge: Otto Bauer Originalzitat


signature.asc
Description: Digital signature

Re: Debug output etc, cluttering the terminal

[Russ Allbery]

gregor herrmann  writes:

> Among the contents are e.g. ~20.000 lines saying:
> (firefox-bin:28026): Gdk-WARNING **: XID collision, trouble ahead

I tracked this down at one point and decided that this was the fault of
Adobe's Flash player rather than anything the Mozilla folks had any
control over.  I now just redirect the output of Iceweasel to /dev/null
where I have to run the Flash player.

However awful that one might think Adobe's Flash code is, it's actually
worse than that.

-- 
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/874oeve87f@windlord.stanford.edu

Filter shekan Usa Nl

[dani]

Forosh Vpn ba gheymat monaseb va server haye Usa va Nl
Jahate daryafte account test be addresss zir email konid 
email : Alborz33 @ gmail.com 
1 Mahe (Usa , Nl) 3500 Toman .
3 Mahe (Usa , Nl) 9500 Toman .
6 Mahe (Usa , Nl) 17000 Toman .
12 Mahe (Usa , Nl) 29000 Toman .
jahate daryafte shomare kart mitavanid az tarighe arsale email ya tamas 
Telefoni ba shomare 09365440439

Filter shekan Usa Nl

[dani]

Forosh Vpn ba gheymat monaseb va server haye Usa va Nl
Jahate daryafte account test be addresss zir email konid 
email : Alborz33 @ gmail.com 
1 Mahe (Usa , Nl) 3500 Toman .
3 Mahe (Usa , Nl) 9500 Toman .
6 Mahe (Usa , Nl) 17000 Toman .
12 Mahe (Usa , Nl) 29000 Toman .
jahate daryafte shomare kart mitavanid az tarighe arsale email ya tamas 
Telefoni ba shomare 09365440439