Gaim-Encryption plugin violates Gaim's license

[Robert McQueen]

(cc'ing debian-devel to discourage people from ITPing this, or filing more
wishlist bugs on Gaim for me to include it, cc'ing Gentoo's maintainer
for the Gaim emerge because they include Gaim-Encryption, cc'ing
gaim-devel so everyone there knows, cc'ing fedora-devel because they
currently ship the plugin, and cc'ing the author of the plugin itself)

As a preamble if I just gatecrashed your mailbox or mailing list without
warning, I am the Debian package maintainer for Gaim, as well as a
frequent contributor to upstream development. I have just found out
today that the Gaim-Encryption plugin for Gaim, which can be found at
http://gaim-encryption.sourceforge.net/, makes use of the OpenSSL
library, and loads it into the same process space as Gaim.

Due to OpenSSL's four-clause BSD license (ie with the advertising clause),
it is therefore in violation of Gaim's GPL license because the OpenSSL
licence places an extra restriction beyond those allowable by the GPL.
The Debian project will not distribute code of this nature, especially
given that several Gaim developers (myself included) agree with the Debian
project's position on this, and this message constitutes us contacting
other distributors and the plugin author with this information.

The problem could be solved by the Gaim license being changed to include a
specific exception for OpenSSL, but even if we wanted to do it, it would
be practically impossible due to the innumerable contributors that Gaim
has had over time, all of whom would have to be contacted and consent to
a licensing change. This is the same reason that OpenSSL can't remove the
obnoxious 4th clause even if they wanted to.

Other possible ways to resolve this problem are to make Gaim-Encryption
use a GPL-compatible library such as GNUTLS, which Gaim plans to use for
secure Jabber connections at some point in the future when it compiles
on more non-GNU platforms, or to split the OpenSSL-linked code into a
helper process which communicates with Gaim via a pipe or socket (in
GLib, g_spawn_async_with_pipes will do this nicely, with one process per
encrypted session for example) and is licensed under the LGPL or GPL with
a specific exception for OpenSSL. The latter solution is used by Konqueror
without problems.

Incorrect ways to deal with this are ignore the problem or argue about
it endlessly on mailing lists. For more information, see countless legal
wrangling threads on mailing lists like debian-legal. One good example is:
 http://lists.debian.org/debian-legal/2002/debian-legal-200210/msg00113.html
Take good note of the part that says it's easier to solve this in code
than by discussion.

For misinformation, read the OpenSSL FAQ which claims that OpenSSL is
shipped with most operating systems and therefore falls under the GPL's
exception for OS components. I interpret this to mean the kernel and
shell, and libraries inbetween, and because it is specifically named in
the GPL text, the compiler. It is certainly very easy to install Debian
or any other distro without OpenSSL being present. The same is also
doubtlessly true for any number of non-Linux platforms, not least Windows,
where both Gaim and Gaim-Encryption are available in binary form, and
OpenSSL is certainly not part of the OS!

Regards,
Rob


pgpXJNLzMlzlf.pgp
Description: PGP signature

Re: ATI Linux Driver Packages

[Matthew P. McGuire]

On Sun, Jun 01, 2003 at 09:42:10PM -0500, Chris Cheney wrote:
> Are these drivers much better then than XFree ones or is there a reason
> to be promoting nonfree drivers? 

I recently bought an entirely new machine with a Radeon 9500 Pro in it. 
None of the XFree86 drivers in woody would run on it. (Please clue me 
in if there is one.) So as a result I downloaded the ATI RPM and 
alien'ed it into a Debian package. For the most part this worked fine 
but it complained about libGL.so.1.2 which appears to be owned by 
another package. (I am not sure which at the moment.) The new fglrx 
driver appears when you run dpkg-reconfigure xserver-xfree86. 
You can run it this way if you do not use the Kernel framebuffer. 
The install scripts in the ATI package provide a XFree86 setup script, 
and this worked as well. Sadly none of the GL apps work well because the 
system does not use OpenGL Direct Rendering. This is probably due to the 
lack of a suitable DRI module in the kernel. As such I snagged the src 
for said module and tried to compile it using kernel-headers-2.4.18-686 
which appears to be the highest stable kernel available in Woody. My 
attempt to compile this using the make.sh script in the package returned 
an annoying "This Driver will not be compatible with the DRI in your 
version of the kernel, please use 2.4.5 or higher." So I haven't had 
much luck. Been at a loss until I saw this package discussion. I 
tried to install the package but dpkg found that the version number is 
the same as the one I alien'ed so it refused to install it. However 
since I have the hardware and the time to help out, I would be happy to 
use this machine as a test bed. Contact me personally, since it isn't 
appropriate for the list. It would be really swell to actually play 
Tuxracer for a change. ;-)

Thanks
-- 
Matthew P. McGuire  1024D/E21C0E88
CB82 7859 26B2 95E3 1328  5198 D57A D072 E21C 0E88
  When choice matters, choose Debian.

Re: new bug tags

[Martin Schulze]

Mark Brown wrote:
> On Sun, Jun 01, 2003 at 03:33:29PM +0100, James Troup wrote:
> 
> > I don't; it's silly.  At best you'll get an architecture tag for the
> > arch that the buildd maintainer reported the bug on, but that's it.
> > An inaccurate architecture tag is worse than useless, it's misleading.
> > Just parse wanna-build's failed logs; it's trivial.
> 
> Something that would be really useful would be to open up the ability to
> annotate the buildd logs more widely.  I've often felt that the buildd
> logs would be a lot more useful if they linked into the BTS more often.

Hmm, there's a unique URL for each buildd log.  You could just add this
URL to the bug report and the reader would have an easy time getting to
it, assuming he's online, though.

Regards,

Joey

-- 
If nothing changes, everything will remain the same.  -- Barne's Law

Please always Cc to me when replying to me on the lists.

Re: Celebrating Debian's 10th birthday?

[Martin Schulze]

Alexander Neumann wrote:
> While digging around in the calendar-files at infodrom.org I suddenly
> realized that Debian will have it's 10th birthday at August, 16th
> (according to the calendar.infodrom.debian file at
> http://www.infodrom.org/projects/calendar/)
> 
> Are there any parties planned already? ;)

I hope to get a party somewhere in middle Germany, similar but larger
than last year's party.  However, there's nobody planning on details
yet.  If you have a party facility[1] nearby would you mind checking
it out?

Regards,

Joey

[1] Sleeping space included for sleeping bags at least, some kitchen
facility, some washing (showering?) facility, some barbecue facility,
enough space indoor and outdoor, not too difficult to reach (i.e.
an island would be nice but too far away for most of us)

-- 
If nothing changes, everything will remain the same.  -- Barne's Law

Please always Cc to me when replying to me on the lists.

Re: ATI Linux Driver Packages

[Chris Cheney]

On Sun, Jun 01, 2003 at 11:16:12PM -0500, Adam Majer wrote:
> I think you might be the "sucker". :) [ok, it's not a flame thing].
> Does the radeon driver support 3D accel for cards beyond the R1xx level?
> ie. something like Radeon 7500. I don't think that Radeon 8500, 8800, etc..a
> are supported since they use the former FireGL GPU. The drivers from
> ATI fill the gap to support FireGL, and yes they are better. They
> can be used with Maya etc.. [at least it says that on ATI's site.]

As I understand it XFree86 4.3.0 supports 2D/3D for the following:

rv100   -   Radeon 7000
r100-   Radeon 7200
rv200   -   Radeon 7500
r200-   Radeon 8500/Radeon 9100/FireGL 8700/FireGL 8800
rv250   -   Radeon 9000
rv280   -   Radeon 9200

XFree86 4.3.0 has 2D support for the following:

r300-   Radeon 9500/Radeon 9700

XFree86 4.3.0 doesn't support the following at all:

rv350   -   Radeon 9600
r350-   Radeon 9800

It is bad news that ATI hasn't released the documentation for the
R300/R350 chipsets yet. :< I hope they haven't decided to imitate
nvidia now they finally have beaten them on windows benchmarks. If this
is the case it needs to become more apparent to users that they are no
longer the company to buy from to help support OSS friendly companies.

> BUT, ATI doesn't have any drivers for new cards like Radeon 9800 and I 
> do not think they will have any Linux drivers.
> 
> On the other hand, I installed Debian for a frried and he had a 
> GeForce 4 MX card. The driver from nVidia worked perfectly.
> Futhermore, I think that they only distribute the X driver that's 
> precompiled. The kenrel part has to be compiled by hand (which is good).

Nvidia's drivers have been notorious over the years at causing crashes.
>From what I have heard recently this is still the case. If it doesn't
crash for you then you are lucky. When I still had my nvidia card it
crashed under any strain with the nvidia binary driver.

> Futhermore, I believe that nVidia have _much_ better support in X
> from nVidia than radeon ever had from ATI. The free 3D driver
> hacked together does not give good performance as does nVidia's
> propriatory driver. Frankly, I very much prefer that nVidia has
> in-house support for their cards while ATI has none (the ones for
> Radeon 8500, 8800, etc.. are just FireGL drivers).

Don't forget that binary only drivers are likely to have rendering
cheats such as the one found that nvidia did on 3DMark2003, so your
better performance may come at quality loss (sometimes noticable). Both
ATI and Nvidia have been caught previously doing rendering cheats on
the windows platform. Also some things can't be included in an open
driver like patented S3 Texture Compression.

Chris

Re: new bug tags

[Mark Brown]

On Mon, Jun 02, 2003 at 08:19:53AM +0200, Martin Schulze wrote:
> Mark Brown wrote:

> > Something that would be really useful would be to open up the ability to
> > annotate the buildd logs more widely.  I've often felt that the buildd
> > logs would be a lot more useful if they linked into the BTS more often.

> Hmm, there's a unique URL for each buildd log.  You could just add this
> URL to the bug report and the reader would have an easy time getting to
> it, assuming he's online, though.

I was meaning the other way around: being able to go from the list of
build failures for a given architecture to the BTS.  It would make it
easier to pick out things that haven't been looked at from the list.
Obviously more would be better but it'd be a very good start.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


pgp1xHEQvP8RC.pgp
Description: PGP signature

Re: ATI Linux Driver Packages

[Daniel Stone]

On Sun, 1 Jun 2003 23:16:12 -0500, Adam Majer wrote:
> On Sun, Jun 01, 2003 at 09:42:10PM -0500, Chris Cheney wrote:
> > Are these drivers much better then than XFree ones or is there a reason
> > to be promoting nonfree drivers? I orginally packaged up the nvidia ones
> > in the way they are done due to the fact the XFree ones had no 3d
> > acceleration at all and that it was illegal to distribute nvidia's
> > binaries directly.  Also binary only drivers will taint the kernel and
> > can cause the user to have trouble getting help with kernel related
> > issues. I got rid of my nvidia cards (some poor sucker took them) and
> > now use only ATI cards. 8)
> 
> I think you might be the "sucker". :) [ok, it's not a flame thing].
> Does the radeon driver support 3D accel for cards beyond the R1xx level?
> ie. something like Radeon 7500. I don't think that Radeon 8500, 8800, etc..a
> are supported since they use the former FireGL GPU. The drivers from
> ATI fill the gap to support FireGL, and yes they are better. They
> can be used with Maya etc.. [at least it says that on ATI's site.]

3D acceleration exists for r[12]xx and r250; I'm not sure whether it
exists for the rv280. Indeed, it's in the stock XFree86 4.3 debs
previously distributed by myself, now distributed by the XSF.

[EMAIL PROTECTED]:~/music/mixMasterMike/spinPsycle% glxinfo | grep OpenGL
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI R200 20020827 AGP 4x x86/MMX/3DNow! TCL
OpenGL version string: 1.2 Mesa 4.0.4
OpenGL extensions:

> BUT, ATI doesn't have any drivers for new cards like Radeon 9800 and I 
> do not think they will have any Linux drivers.

The r3xx series is currently only supported (in both 2D and 3D form) by
ATI's binary drivers. However, ATI have a standing offer of specs,
hardware and developer access to any DRI developer who wants to write a
driver for the r3xx series.

> On the other hand, I installed Debian for a frried and he had a 
> GeForce 4 MX card. The driver from nVidia worked perfectly.
> Futhermore, I think that they only distribute the X driver that's 
> precompiled. The kenrel part has to be compiled by hand (which is good).

Binary-only drivers are best avoided, but when you have no other option,
sure.

> Futhermore, I believe that nVidia have _much_ better support in X
> from nVidia than radeon ever had from ATI. The free 3D driver
> hacked together does not give good performance as does nVidia's
> propriatory driver. Frankly, I very much prefer that nVidia has
> in-house support for their cards while ATI has none (the ones for
> Radeon 8500, 8800, etc.. are just FireGL drivers).

Uhh, that's utterly incorrect. My Radeon 9000 has out-of-the-box 3D
support, as do original Radeons, and all Radeon 7xxx, 8xxx, and 9[01]00
cards. The 9200 *may*, but I'm unsure. Hell, GATOS will even give you
VIVO support. The reason why you only get FireGL drivers is because you
don't *need* those drivers for the cards I mentioned above.

As for support, I've had pretty amazing support from ATI. ATI have
developer contacts who regularly feed patches into XFree86 upstream and
packagers (the entire 030 patch series was sent through ATI), and they
have the standing offer I mentioned above. The only thing preventing
capital-F-Free drivers being written right now is DRI developer time
constraints, AIUI.

nVidia have never offered any such deals to developers, or Free drivers
(the current ATI driver was originally donated by ... yep, them - ATI).

I personally buy ATI because not only are they currently the best card
around (even when wrapped in OpenGL, the demo optimized for nVidia
cards, by nVidia, to show off nVidia cards, runs over 15% faster on the
9800 Pro than the GeForce FX, and the 9800 Pro has been out longer than
the FX. Not only that, but ATI have offered outstanding support to
XFree86, and I can do my acceleration with a Free driver, not needing to
depend on nVidia to fix my bugs, or make the kernel module not use up
1mb RSS, or whatever.

Daniel, happily with his Freely out-of-the-box 3D-accelerated r250.

-- 
Daniel Stone <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
KDE: Konquering a desktop near you - http://www.kde.org


pgpseTCKzQvX8.pgp
Description: PGP signature

Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e")

[Marcelo E. Magallon]

On Sun, Jun 01, 2003 at 06:34:49PM +0200, Sam Hocevar wrote:

 >Now maybe public humiliation and eternal ridiculation on
 > debian-devel is not necessary

 I can't care less for this "humiliation and ridiculation".  I care
 about the fact that S/N in d-d is already bad enough without having to
 watch (out for) these pissing contests.

 People, if taunting is your game, go make a webpage and call it the DD
 hall of shame (or whatever else tickles you), where folks who care for
 this kind of thing can hit reload to death.

 I'd really rather not killfile 'Re: Bug#\d+: marked as done' on d-d.

 > But I think it can be still useful to send the authors of such
 > changelogs a courteous private request to read the Developer's
 > Reference, section 6.3.3, which will certainly improve the overall
 > quality of Debian, with the additional benefit of not annoying this
 > mailing-list.

 By all means.

 Marcelo

Re: Celebrating Debian's 10th birthday?

[Ben Burton]

> Are there any parties planned already? ;)

Well, it coincides with the first day of the international olympiad in
informatics, so with all the computer geeks around I'm hoping there will
be someone else there to celebrate with. :)

Ben.

Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e")

[Andreas Barth]

* Rene Engelhard ([EMAIL PROTECTED]) [030602 01:05]:
> > However, it really might be better to put a longer statement into
> > changelog. _But_ it's certainly much worse to re-open a really closed
> > bug than to make a too short changelog entry. (BTW: You should really

> a wrongly closed... (whithout explanation what the fix was; the

Was the bug still there? No. So it was right to close the bug
despite the fact that _you_ didn't like the changelog-style.

> > make cleaner why changing of the compiler closes the Bug 194555. The
> > situation there is fare worse than here. You shouldn't flame until
> > you're perfekt.)

> aha. You say me I should respect the decision and you don't.
> *sigh*

I didn't reopen your bug report. And - I would never spoken about that
here unless you bashed a debian maintainer here and reopend a really
closed bug.

> I actually am really busy with other Debian and RL things...

Perhaps you just shouldn't try to enforce your point of view. That
would make it easier.

Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Bug#194550: ITP: libemail-mime-encodings-perl -- A unified interfa

[Gerfried Fuchs]

* Kai Henningsen <[EMAIL PROTECTED]> [2003-05-26 20:30]:
> [EMAIL PROTECTED] (Gerfried Fuchs)  wrote on 26.05.03 in <[EMAIL PROTECTED]>:
>>  Please, don't simply massfile ITPs without thinking on their impact and
>> without any deeper informations
> 
> Please don't assume someone jasn't thought about something just because  
> you haven't been personally informed about every detail.

 I am not quite sure why you think that you should inform me personally.
Though still my question holds, that you seem to have ignored. Recite:

| your other ITPs, too).  Additional informations on what makes it more
| useful/better than libmailtools-perl in this special case wouldn't be
| wrong neither.

 So, let me ask again: What makes it better/more useful than
libmailtools-perl?

 See, it is nothing personal (you seem to take it that way), but
packages with similar functionality should be questioned, and if the
intended things can be done with either one there is no big need to
duplicate the work and increase the pool with it.

> As for the long descriptions, I really don't see what the use is in an  
> ITP. The packages will of course have them.

 A long description in an ITP would
a) reduce the amount of questions why this package should be in the
 pool,
b) can get you suggestions for improvement of it before the package hits
 the pool, and
c) doesn't let you seem strange by ignoring a template that requests it.

 If you like to question c) feel free to discuss it, like e.g. with the
reportbug maintainers (they have valid reasons to include it, see a) and
b), I guess), but don't go and simply ignore it.

 So long!
Alfie
-- 
Aber, der Aufwand, Linux zu installieren und vim zu lernen ist *IMMER*
geringer, als Outlook das Schreiben von vernünftigen Mails beizubringen. ;)
  -- Jens Benecke


pgpb1qznsg7pC.pgp
Description: PGP signature

Re: Celebrating Debian's 10th birthday?

[Alexander Neumann]

Hi Martin,

Martin Schulze wrote:
> I hope to get a party somewhere in middle Germany, similar but larger
> than last year's party.  However, there's nobody planning on details
> yet.  If you have a party facility[1] nearby would you mind checking
> it out?

At that time I'm doing my social service ("Zivildienst") in Cologne and
there might be a possibility to get facilities there, but I believe it's
too far in the west of Germany to be "in the middle"...

- Alexander


pgpQOMbBYa0hR.pgp
Description: PGP signature

Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e")

[Mathieu Roy]

Steve Kowalik <[EMAIL PROTECTED]> a tapoté :

> At  7:57 am, Monday, June  2 2003, Herbert Xu mumbled:
> > So what? The *Debian* changelog is for Debian changes only.  It's not there
> > for listing upstream changes, copyright information, or who your favourite
> > TV personality is.
> > 
> And if this new upstream release deals with a bug filed in the BTS?
> 
> I personally don't see a problem with:
> 
> lala (0.0-2) whatever
> 
>   * New upstream release.
> - Don't segfault on hppa at startup. (Closes: #12345)

Me neither.

Debian changelog is for Debian changes only: everybody agrees.
But a bug filled in Debian BTS fixed upstream is a partially a Debian
change. 



-- 
Mathieu Roy
 
  Homepage:
http://yeupou.coleumes.org
  Not a native english speaker: 
http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english

Re: new bug tags

[Guido Guenther]

On Sun, Jun 01, 2003 at 08:02:08PM +0200, Wouter Verhelst wrote:
> While James' point that parsing wanna-build output is not hard may be
> valid, finding out whether a failure recorded in the wanna-build
> database is arch-specific or not seems quite hard to me, since that
> information is not in the database in a machine-parsable format.
What if there's no wanna-build output in the first place. Let's say
somebody want's to help the hurd port. 
 http://bugs.debian.org/tag:hurd
would be a good starting point to get an idea about the current status.
Same is true for the BSDs. Furthermore the bugreports of the core
packages like glibc, gcc and kernel-source (if we're going to unify the
source) would be much easier to parse when looking for arch related
issues.
 -- Guido


pgplTtlfTpmeR.pgp
Description: PGP signature

Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e")

[Josip Rodin]

On Mon, Jun 02, 2003 at 07:39:38AM +1000, Herbert Xu wrote:
> >  * Closes: 
> > 
> > also says this version fixes a problem reported in #, but I think we
> > can all agree that's not an acceptable entry.
> 
> I most strongly disagree.  The practice of closing upstream bugs with
> the "New upstream version" message has always been common practice.

Just because it was fine three years ago that doesn't mean we have to follow
the same old, insufficient standards today.

I was only ever in the situation where naming closed bugs in the changelog
was non-trivial on two occasions, when the upstream maintainer sent me the
list of bugs he reviewed and said should be closed. Both times I reviewed
the lists myself, to double-check and avoid typos and such. I added short
descriptions the first time, but I was too lazy to do it the second time.
Now that I look back at that changelog, the one where there are no
descriptions looks pretty lame compared to the other.

-- 
 2. That which causes joy or happiness.

Re: Debian menu system update

[Bernhard R. Link]

> > Does this mean there simply is no such documentation?
> 
> I think it's pretty clear how it should be done.  Once we adopt the
> system, we can point system administrators to the relevant file in our
> documentation, and give pointers to the file format.

I think there should first be a documentation. Anything I've seen yet
only document how to implementing it. Nothing describes clearly how
to make .desktop files and what the content should be (oposed to the
format), nor how to customize this for local needs. Everything the
preludes talks about is: "we have doe it for KDE, having the same
format for Gnome would be nice". This is far from anything usable as
Menu standard. (It may be useable to be parsed by WMs and generated
by a menu system perhaps, but simply does not talk about users.)

> > Currently the main database for window managers or fvwm-modules is the
> > debian menu, as they are often selectable from a menu and there is no
> > difference in handling them and normal items. 
> 
> Huh?  What "main database"?  Are you saying some window managers read
> the Debian menu entries directly?  From looking at fvwm, this certainly
> seems not to be the case.

No, but things like fvwm-modules just add a menu item, describing itself
as fvwm-module. And anything able to cope with fvwm-modules (and be it only
fvwm) gets them all.
Same is with window managers. A Window manager adds a needs=wm item for
itself, and anything allowing to choose a wm gets a file what wms exist
and how they are called. 

> > Do you suggest tweaking
> > the .desktop files, to contain them, too?
> 
> Contain...what?

Window managers and things like fvwm-modules or other things like this.

> > When I currently look in icewm-gnome, what is has in its KDE and Gnome
> > menus compared to what it has in its debian menu, I really have to doubt
> > that.
> 
> If your problem is with the default layout, again: it's only a
> *default*.  We can and probably will change it.

I was speaking of the mere numbers. Currently things having a Gnome or
KDE menu entry are a minority. Even when they combine to one format,
they will not soon get the "vast majority" you speak of.
   
> Many of my packages come with perfectly good menu entries from upstream.
> And besides, as one of the prominent free software projects, Debian
> should be leading the charge here.

Well, I think we just disaggree, if it is a change to good or to bad. I
do not want Debian to lead into disaster...

> > Heck, this specification even gives in the example the
> > Icon as .png-file. While using .xpm-only for menus is really
> > long-lasting standard, with no reason to stop this...
> 
> And now the "Ok, my pointless KDE and GNOME flame was obviously wrong,
> so I'll try to troll about image formats instead" part.

You are trying hard getting me to insult back, don't you?

My whole point is, that this format is a typically KDE approch:

It describes happily complex formats and schematas. (Nice for a roadmap
to implement a prototype oneself, for a standard inadequate.)
It does not speak about anyone beside the programmer at all. It does not
even give reasoning for the creators of such files. Nor does it talk
about users or administrators and how they can get interfere with the
system. (Note that this is a general problem with KDE, trying hard to
get a system doable by clicks and forgetting to make the way without
graphic interface doable). If there are some resonings or hints for
contents, they partly seem not to think about other things (like 
specifing icons as .png[1]) and partly simply want to soldify bad
decisions (Like those file formats decided by file-extension[1]) or
merging mime-suppliers and menu-items[3])

It furthermore describes no way to get a standardized deeper menu.[4]
I'm not saying automatic aproaches or specific menus per wm should
not be possible. I'm talking about they being avoidable.

Thus my whole point is, that this is by no means menu standard. On its
best its a format description for menu-files, that some new fashioned
wms are able to parse. And it might have good things like less work
to write menu-methods for those. But it is by no means something 
resonable to base our menu-system on. (And as I tried to say before,
even the way to more directly recylcle upstream's suggestion for menu
items does not get more simple but just more error prone).

Hochachtungsvoll,
  Bernhard R. Link

[1] This might be partly resonable for KDE-menus, for a menu
"standard" this just says: "It is not bloated as we are,
it can't be good.". or even "should no longer be supported".
[2] I'm currently even working to get xfm with some sane
defaults, as telling people to rename their files to
click at gets annoying with the time.
[3] It's real nice working Pavlov experiment. They most of the
time hit the "other"-button/menu-item, when they need it
though it is really obscure.
[4] I know, when I tell I badly need exactly the same looking 
menu in a m

Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e")

[Josip Rodin]

On Mon, Jun 02, 2003 at 09:54:47AM +0200, Marcelo E. Magallon wrote:
>  I care about the fact that S/N in d-d is already bad enough without
>  having to watch (out for) these pissing contests.

You may notice that some of us will care about what you're saying only
if you complain about the next frivolous flamewar of the month on a topic
only tangentially related to Debian development, which spoil the
signal/noise ratio infinitely more than this. :P

-- 
 2. That which causes joy or happiness.

Proposal: a generic dpkg event hook broker

[Jarno Elonen]

Hi,

Packages often benefit from having other packages installed but don't 
necessary require them, hence 'suggests' and 'recommends'.

Such packages, however, often require additional configuration to make them 
work with those optional packages. It's not usually very complicated and 
could in many cases be easily made automatic if there was a way to run the 
setup scripts when the optional packages come available.

I propose making a "dpkg event broker", a database of scripts that would like 
to run when the packages they are interested in are getting a 
{pre,post}{inst,rm} treatment.

This kind of "install hook" system is already implemented in some individual 
packages like emacs (registering/deregistering plugins, I think) and 
openoffice (also registering plugins).

As an additional example,
it would be nice to have 'libgphoto2' setup digital camera permission scripts 
when 'hotplug' is installed after asking the user which flavour of the script 
she wants (grant access to user or group and to which one) and removing them 
when 'hotplug' is being uninstalled. The manual procedure for doing this is 
currently explained in README.Debian of 'libgphoto2' but it would be nice if 
it was automatic 1) to make it easier for the admin and 2) because most users 
(myself included) will read the file only as a last resort.. ;)

Comments, objections and/or suggestions for implementation details?

- Jarno

Re: ATI Linux Driver Packages

[Teófilo Ruiz Suárez]

I've just bought a Dell Inspiron 8500, with an ATI Radeon Mobility 9000,
and it works perfectly with the drm modules from drm.sf.net.

2D&3D acceleration, swsusp and so on.

6083 frames in 5.0 seconds = 1216.600 FPS

I think it could be a nice idea to get the xlibmesa4-drm-src from
penguinppc.org package into the main archive, however that package is for
4.3.

Regards.
-- 
Teófilo Ruiz Suárez  ||(teo)||  Sevilla, España 

  [EMAIL PROTECTED]   

GnuPG Key ID: 420718E6
FPR: 0280 862C 064B FA76 9A1C  EB64 5755 A66C 4207 18E6



pgpVI3tkkdRPu.pgp
Description: PGP signature

Re: ATI Linux Driver Packages

[Marcelo E. Magallon]

On Mon, Jun 02, 2003 at 05:34:57PM +1000, Daniel Stone wrote:

 > Uhh, that's utterly incorrect. My Radeon 9000 has out-of-the-box 3D
 > support, as do original Radeons, and all Radeon 7xxx, 8xxx, and
 > 9[01]00 cards. The 9200 *may*, but I'm unsure. Hell, GATOS will even
 > give you VIVO support. The reason why you only get FireGL drivers is
 > because you don't *need* those drivers for the cards I mentioned
 > above.

 There's 3D support and there's 3D support.  The r200 has something
 close to 60 million transistors.  That's twice as many as the r100.  A
 large part of this difference comes from the programmability of the
 r200.  The DRI drivers support most of the functionality present in the
 r100 chip, but most of the new functionality introduced by the r200 is
 not really supported.  The gap is much wider in the case of the r300.

 So, you are right as long as you don't intend to use the functionality
 the newer chips provide.

 > As for support, I've had pretty amazing support from ATI. ATI have
 > developer contacts who regularly feed patches into XFree86 upstream
 > and packagers (the entire 030 patch series was sent through ATI), and
 > they have the standing offer I mentioned above. The only thing
 > preventing capital-F-Free drivers being written right now is DRI
 > developer time constraints, AIUI.

 That's right.

 Marcelo

Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e")

[Herbert Xu]

Josip Rodin <[EMAIL PROTECTED]> wrote:
> 
> I was only ever in the situation where naming closed bugs in the changelog
> was non-trivial on two occasions, when the upstream maintainer sent me the
> list of bugs he reviewed and said should be closed. Both times I reviewed
> the lists myself, to double-check and avoid typos and such. I added short
> descriptions the first time, but I was too lazy to do it the second time.
> Now that I look back at that changelog, the one where there are no
> descriptions looks pretty lame compared to the other.

OK.  Let me ask you this question: what if the maintainer uploads a
new upstream release which happens to fix bug #xxx, and then sends
a message by hand to [EMAIL PROTECTED] with the message
"This bug is fixed in upstream version x.y.z".

Do you have a problem with this and if so why?
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

console mode(probally off)

[Luiz Rafael Culik Guimaraes]

Dear Friends

How to start debian  direct on console mode,

Regards
Luiz

Re: [ANN] Quantian: A Knoppix remastering for Scientific Computing

[Andreas Tille]

On Sun, 1 Jun 2003, Dirk Eddelbuettel wrote:

> > While I like any project which tries to connect Knoppix and Debian
> > stronger I think the project you mentioned above is doing the second
> > step.  In several threads in the debian-knoppix mailing list especially
>
> "Second step" ? I don't get it? What second step?
Well, first step is making Knoppix derivates easy.  The second step is to
define what kind of derivate I would like to build (using the *easy* build
system).

> That is a fine goal for the medium to long term. Quantian is about
> addressing a current niche, and demand, right now.  Both goals are
> complements and do not stand in each others way.
Definitely they do not stand in each others way.  But If we do the first
step first the second will need nearly no effort.  If we can't accomplish the
easy build system quickly enough (which seemsbe probable) your experiences
will be helpful anyway.  So I do not want to stop you but it might be reasonable
to keep in mind other users who might profit from your work.

Kind regards

  Andreas.

Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e")

[Josip Rodin]

On Mon, Jun 02, 2003 at 09:07:00PM +1000, Herbert Xu wrote:
> what if the maintainer uploads a new upstream release which happens to fix
> bug #xxx, and then sends a message by hand to [EMAIL PROTECTED]
> with the message "This bug is fixed in upstream version x.y.z".

The submitter would still have little information on what happened.
It's not like anything bad would happen to the maintainer if they say
a bit less tersely what closed the bug.

-- 
 2. That which causes joy or happiness.

Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e")

[Herbert Xu]

Josip Rodin <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 02, 2003 at 09:07:00PM +1000, Herbert Xu wrote:
>> what if the maintainer uploads a new upstream release which happens to fix
>> bug #xxx, and then sends a message by hand to [EMAIL PROTECTED]
>> with the message "This bug is fixed in upstream version x.y.z".
> 
> The submitter would still have little information on what happened.
> It's not like anything bad would happen to the maintainer if they say
> a bit less tersely what closed the bug.

Let me make this a bit more concrete.  Let's say that a user files a
bug report saying that the kernel crashes when he does X, or that
doing Y does not work as documented, or feature Z is missing from the
package.

What exactly is wrong with a message sent to the BTS by hand saying the
"this is fixed in upstream version x.y.z"? Do we really expect our
developpers to hunt down the technical details of each upstream bug
fix before closing them? Does the user really care?

I bet that most users simply don't give a damn.  For the few that are
interested in the internals of the package in question, they can either
read the diff themselves, or even send a question to the developper.
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e")

[Josip Rodin]

On Mon, Jun 02, 2003 at 10:29:56PM +1000, Herbert Xu wrote:
> >> what if the maintainer uploads a new upstream release which happens to fix
> >> bug #xxx, and then sends a message by hand to [EMAIL PROTECTED]
> >> with the message "This bug is fixed in upstream version x.y.z".
> > 
> > The submitter would still have little information on what happened.
> > It's not like anything bad would happen to the maintainer if they say
> > a bit less tersely what closed the bug.
> 
> Let me make this a bit more concrete.  Let's say that a user files a
> bug report saying that the kernel crashes when he does X, or that
> doing Y does not work as documented, or feature Z is missing from the
> package.
> 
> What exactly is wrong with a message sent to the BTS by hand saying the
> "this is fixed in upstream version x.y.z"? Do we really expect our
> developpers to hunt down the technical details of each upstream bug
> fix before closing them?

No, but what exactly is wrong with explanations like "Kernel no longer
crashes on X since release x.y.z", "Y now does what's in the manual page",
"Z was added in the new release"? Do we really have to expect from our
developers to have such a lack of interest in what they're doing that they
cannot form a different meaningful sentence for each different bug, rather
than a generic response to the whole batch?

> Does the user really care?

Maintainers should do their part and leave the worrying about whether the
reporter cares to the reporter.

-- 
 2. That which causes joy or happiness.

Bug#195813: ITP: open21xx -- Free assembler and linker for ADSP-21xx DSPs

[Ramakrishnan Muthukrishnan]

Package: wnpp
Severity: wishlist

* Package name: open21xx
  Version : 0.6.0
  Upstream Author : Keith Clifford <[EMAIL PROTECTED]>
* URL or Web page : http://www3.telus.net/sharpshin/
* License : GNU GPL
  Description : Free assembler and linker for ADSP-21xx DSPs

 Open21xx is an open source, GPLed assembler tool suite for the
 Analog DevicesTM 21xx family of Digital Signal processors.  The
 tool suite contains two assemblers: one for the 218x and it's 
 predecessors and one for the 219x; a linker; and a loader for 
 the 2181 EZ-Kit LiteTM. The assemblers expect input conforming 
 to version 7 syntax and later of the Analog Devices tools. 
 There are notes in the man pages about converting from pre 
 version 7 syntax.

--
  Ramakrishnan

Re: Gaim-Encryption plugin violates Gaim's license

[Steve Langasek]

On Mon, Jun 02, 2003 at 06:21:55AM +0100, Robert McQueen wrote:

> As a preamble if I just gatecrashed your mailbox or mailing list without
> warning, I am the Debian package maintainer for Gaim, as well as a
> frequent contributor to upstream development. I have just found out
> today that the Gaim-Encryption plugin for Gaim, which can be found at
> http://gaim-encryption.sourceforge.net/, makes use of the OpenSSL
> library, and loads it into the same process space as Gaim.

> Due to OpenSSL's four-clause BSD license (ie with the advertising clause),
> it is therefore in violation of Gaim's GPL license because the OpenSSL
> licence places an extra restriction beyond those allowable by the GPL.
> The Debian project will not distribute code of this nature, especially
> given that several Gaim developers (myself included) agree with the Debian
> project's position on this, and this message constitutes us contacting
> other distributors and the plugin author with this information.

It should be noted that this can only be a violation of the GPL if
someone is distributing the encryption plugin in binary form.  (Does
Gentoo distribute binaries of this software?)  It is generally held that
it would also *not* be a violation of the GPL if you distribute the
encryption module in isolation, only if you distribute it together with
binaries of gaim itself.

Given that you have explicitly said you don't have access to all
contributors to effect I license change, I presume this means gaim is
under the canonical GPL license, and that you are not attempting to
promote an alternative, overbroad interpretation of the GPL with your
statements above.

> For misinformation, read the OpenSSL FAQ which claims that OpenSSL is
> shipped with most operating systems and therefore falls under the GPL's
> exception for OS components. I interpret this to mean the kernel and
> shell, and libraries inbetween, and because it is specifically named in
> the GPL text, the compiler. It is certainly very easy to install Debian
> or any other distro without OpenSSL being present. The same is also
> doubtlessly true for any number of non-Linux platforms, not least Windows,
> where both Gaim and Gaim-Encryption are available in binary form, and
> OpenSSL is certainly not part of the OS!

To be precise, you cannot take advantage of the GPL's "OS exemption" if
your product is the OS.

-- 
Steve Langasek
postmodern programmer


pgposT3bdCEKN.pgp
Description: PGP signature

Re: [Gaim-devel] Re: Gaim-Encryption plugin violates Gaim's license

[Luke Schierer]

On Mon, Jun 02, 2003 at 09:25:32AM -0500, Steve Langasek wrote:
> On Mon, Jun 02, 2003 at 06:21:55AM +0100, Robert McQueen wrote:
> 
> > As a preamble if I just gatecrashed your mailbox or mailing list without
> > warning, I am the Debian package maintainer for Gaim, as well as a
> > frequent contributor to upstream development. I have just found out
> > today that the Gaim-Encryption plugin for Gaim, which can be found at
> > http://gaim-encryption.sourceforge.net/, makes use of the OpenSSL
> > library, and loads it into the same process space as Gaim.
> 
> > Due to OpenSSL's four-clause BSD license (ie with the advertising clause),
> > it is therefore in violation of Gaim's GPL license because the OpenSSL
> > licence places an extra restriction beyond those allowable by the GPL.
> > The Debian project will not distribute code of this nature, especially
> > given that several Gaim developers (myself included) agree with the Debian
> > project's position on this, and this message constitutes us contacting
> > other distributors and the plugin author with this information.
> 
> It should be noted that this can only be a violation of the GPL if
> someone is distributing the encryption plugin in binary form.  (Does
> Gentoo distribute binaries of this software?)  It is generally held that
> it would also *not* be a violation of the GPL if you distribute the
> encryption module in isolation, only if you distribute it together with
> binaries of gaim itself.

gentoo distributes source that is automatically compiled. but the other 
group mentioned, f*, i forget the name, distributes rpms, thus binaries.

> 
> Given that you have explicitly said you don't have access to all
> contributors to effect I license change, I presume this means gaim is
> under the canonical GPL license, and that you are not attempting to
> promote an alternative, overbroad interpretation of the GPL with your
> statements above.

correct, we are not changing our license, and are using the canonical 
GPL.

> 
> > For misinformation, read the OpenSSL FAQ which claims that OpenSSL is
> > shipped with most operating systems and therefore falls under the GPL's
> > exception for OS components. I interpret this to mean the kernel and
> > shell, and libraries inbetween, and because it is specifically named in
> > the GPL text, the compiler. It is certainly very easy to install Debian
> > or any other distro without OpenSSL being present. The same is also
> > doubtlessly true for any number of non-Linux platforms, not least Windows,
> > where both Gaim and Gaim-Encryption are available in binary form, and
> > OpenSSL is certainly not part of the OS!
> 
> To be precise, you cannot take advantage of the GPL's "OS exemption" if
> your product is the OS.

this is partly in reply to a bug which requested that we distribute this 
in the deibian package, which would, like the rpm, be a violation.
luke


-- 
-This email is made of 100% recycled electrons.

Bug#195481: fragmented location info: hassle for users especially mobile ones

[Lionel Elie Mamane]

On Sun, Jun 01, 2003 at 08:29:03AM -0600, Barak Pearlmutter wrote:

> Well okay, granted ... but the locale would almost always be
> explicitly set, and wouldn't change when eg the lat/long are
> modified.

I disagree on that particular point. If someone installs a Debian, and
the install programs asks for lat/long, and then the system starts
speaking the "right" language to the user, he will never have set the
locale explicitly.

Two solutions:

 - Have the install program infer the (default) locale from the
   lat/long, but the lat / long changing program doesn't touch
   locale.

 - Don't mix coordinates and language at all. The install program asks
   for the default system locale as it does now.

-- 
Lionel

Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e")

[Matt Zimmerman]

On Mon, Jun 02, 2003 at 09:07:00PM +1000, Herbert Xu wrote:

> OK.  Let me ask you this question: what if the maintainer uploads a
> new upstream release which happens to fix bug #xxx, and then sends
> a message by hand to [EMAIL PROTECTED] with the message
> "This bug is fixed in upstream version x.y.z".
> 
> Do you have a problem with this and if so why?

Yes.  There is no record in the package that a bug report in the Debian BTS
was closed in this version.  What about other users who experienced the same
bug?  Is it so hard to explain what bug was fixed, and if possible, how it
was fixed?

Would you upload a new kernel-source saying "Closes: #242141" rather than
"apply patch from 2.6.48 to fix root security hole in nanosleep()"?

-- 
 - mdz

Re: Gaim-Encryption plugin violates Gaim's license

[Brandon Low]

On Mon, 06/02/03 at 09:25:32 -0500, Steve Langasek wrote:
> On Mon, Jun 02, 2003 at 06:21:55AM +0100, Robert McQueen wrote:
> 
> > As a preamble if I just gatecrashed your mailbox or mailing list without
> > warning, I am the Debian package maintainer for Gaim, as well as a
> > frequent contributor to upstream development. I have just found out
> > today that the Gaim-Encryption plugin for Gaim, which can be found at
> > http://gaim-encryption.sourceforge.net/, makes use of the OpenSSL
> > library, and loads it into the same process space as Gaim.
> 
> > Due to OpenSSL's four-clause BSD license (ie with the advertising clause),
> > it is therefore in violation of Gaim's GPL license because the OpenSSL
> > licence places an extra restriction beyond those allowable by the GPL.
> > The Debian project will not distribute code of this nature, especially
> > given that several Gaim developers (myself included) agree with the Debian
> > project's position on this, and this message constitutes us contacting
> > other distributors and the plugin author with this information.
> 
> It should be noted that this can only be a violation of the GPL if
> someone is distributing the encryption plugin in binary form.  (Does
> Gentoo distribute binaries of this software?)  It is generally held that
> it would also *not* be a violation of the GPL if you distribute the
> encryption module in isolation, only if you distribute it together with
> binaries of gaim itself.
>
This is what I was thinking, Gentoo does distribute some binary
packages, so I will ensure that if Gaim is included in the binaries we
distribute gaim-encryption is NOT part of that build.

Thanks for the infos.

--Brandon Low
Senior Gentoo Developer

Re: Changelog issues with (among others) tkdiff 1:3.08-4

[Lukas Geyer]

Brian Nelson <[EMAIL PROTECTED]> writes:

> I really enjoy reading a well-written changelog (and I'm subscribed to
> d-d-changes so I tend to read them all), so I'm interested in improving
> the quality of ones that aren't quite up-to-par.  If there's a consensus
> that it's futile or pointless effort, I'll readily stop.

What about just contacting the maintainer in private? Why does this
have to be on -devel? I think it is nice to have a meaningful
changelog, but the human race and Debian will survive some
not-quite-up-to-par changelog entries. If this was a separate bug, I
would consider it "minor", and thus not worth Cc-ing to -devel.

Lukas

Bug#195481: fragmented location info: hassle for users especially mobile ones

[Wouter Verhelst]

On Mon, Jun 02, 2003 at 05:16:21PM +0200, Lionel Elie Mamane wrote:
> On Sun, Jun 01, 2003 at 08:29:03AM -0600, Barak Pearlmutter wrote:
> > Well okay, granted ... but the locale would almost always be
> > explicitly set, and wouldn't change when eg the lat/long are
> > modified.
> 
> I disagree on that particular point. If someone installs a Debian, and
> the install programs asks for lat/long, and then the system starts
> speaking the "right" language to the user, he will never have set the
> locale explicitly.
> 
> Two solutions:
> 
>  - Have the install program infer the (default) locale from the
>lat/long, but the lat / long changing program doesn't touch
>locale.
> 
>  - Don't mix coordinates and language at all. The install program asks
>for the default system locale as it does now.

I think that's the best solution. There are parts of the world with more
than one official language, and in some of those parts (such as Quebec,
or Belgium), guessing incorrectly may be a good way to severely piss
off a user.

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"An expert can usually spot the difference between a fake charge and a
full one, but there are plenty of dead experts." 
  -- National Geographic Channel, in a documentary about large African beasts.


pgpnMzQrtqfOF.pgp
Description: PGP signature

Re: Gaim-Encryption plugin violates Gaim's license

[Bill Tompkins]

Rob-

Thanks for your email.  When I initially started using OpenSSL with the
Gaim-Encryption plugin, I had no plans of distributing binaries of it,
and thus I wasn't overly worried about the license issues associated
with OpenSSL.  I hadn't revisited those issues before releasing the 
precompiled Windows version, and as you point out, it violates Gaim's
license.  I've pulled those binaries from the Sourceforge site.

I had already been planning on switching the crypto library used by the
plugin- I'm hoping to find the time in the next few weeks to do that
change.  Until then, I plan on leaving the current source distribution
of the plugin on the website.  If you feel that there is a GPL violation
with the source distribution, please let me know, but I don't believe
that that is the case.

I am less sure of the legal situation with regards to the Fedora
Gaim-Encryption RPM.  It is linked against the OpenSSL libraries
distributed with RedHat, and distributed in its own RPM (not packaged
together with Gaim).  As such, I suppose that it depends on your
interpretation of the "OS exemption" clause, and perhaps other
subtleties that I would rather not argue.  It will become moot as soon
as I can find a few days to re-code some parts of the plugin.

-Bill

Re: Bug#195481: fragmented location info: hassle for users especially mobile ones

[Lars Wirzenius]

On ma, 2003-06-02 at 19:38, Wouter Verhelst wrote:
> I think that's the best solution. There are parts of the world with more
> than one official language, and in some of those parts (such as Quebec,
> or Belgium), guessing incorrectly may be a good way to severely piss
> off a user.

Additonally, in every part of the world there tend to be visitors. If,
say, I were sent to Japan, I wouldn't want a computer I install there to
suddenly start speaking Japanese at me, since I don't understand the
language it all.

There are also locations that have no native language at all: the
Antarctica, and ships, oil rigs, and desert islands, for example. (If I
ever get marooned on a desert island and fail to install Debian because
it can't figure out what locale to set, I shall declare myself king and
be royally angry.)

-- 
Enemies of Carlotta 1.0 mailing list manager: http://liw.iki.fi/liw/eoc/

Re: Debian menu system update

[Colin Walters]

On Mon, 2003-06-02 at 06:23, Bernhard R. Link wrote:
> > > Does this mean there simply is no such documentation?
> > 
> > I think it's pretty clear how it should be done.  Once we adopt the
> > system, we can point system administrators to the relevant file in our
> > documentation, and give pointers to the file format.
> 
> I think there should first be a documentation. Anything I've seen yet
> only document how to implementing it.

A significant the user documentation is going to be describing the
format of the file and the semantics of the available entries, for which
the specification sufficies.  All we have to do is wrap a little bit of
a very high level task-oriented documentation around it.

>  Nothing describes clearly how
> to make .desktop files

Huh?  Sure it does.  

http://www.freedesktop.org/standards/desktop-entry-spec/desktop-entry-spec.html#BASIC-FORMAT

Seriously, it couldn't be easier.

>  and what the content should be (oposed to the
> format), 

If by this you mean "typical content", then all we need to do is point
to a few examples.

> nor how to customize this for local needs. 

Generally you should be using the menu file to customize the desktop
files.

> No, but things like fvwm-modules just add a menu item, describing itself
> as fvwm-module. And anything able to cope with fvwm-modules (and be it only
> fvwm) gets them all.
> Same is with window managers. A Window manager adds a needs=wm item for
> itself, and anything allowing to choose a wm gets a file what wms exist
> and how they are called. 

All we have to do is add an X-Debian-WM key.  I don't see what the big
deal is.

> I was speaking of the mere numbers. Currently things having a Gnome or
> KDE menu entry are a minority. 

And you know how many programs come upstream with Debian menu entries? 
A grand total of zero.

> I
> do not want Debian to lead into disaster...

I feel the same way.

> It describes happily complex formats and schematas. (Nice for a roadmap
> to implement a prototype oneself, for a standard inadequate.)
> It does not speak about anyone beside the programmer at all. 

Your repeated requests for very high level user documentation are
reasonable, but we are discussing changing the format and implementation
of the menu system.  Documentation will necessarily follow *after* that.

> It furthermore describes no way to get a standardized deeper menu.[4]
> I'm not saying automatic aproaches or specific menus per wm should
> not be possible. I'm talking about they being avoidable.

That is true.  But I would argue that wanting such a homogenous menu is
crack.  It may make sense for standalone window managers like fvwm or
whatever, but the whole point of integrated desktop environments like
GNOME, KDE, XFCE, etc. is that it's integrated.  You don't have random
crappy unintegrated utilities like xditview showing up in your menu. 
Seriously, does *anyone* use xditview?

Anyways, it would likely not be too hard to implement this with a
 key or something.

> Thus my whole point is, that this is by no means menu standard. 

It certainly is.  It's out there and it works.

> On its
> best its a format description for menu-files, that some new fashioned
> wms are able to parse. And it might have good things like less work
> to write menu-methods for those. But it is by no means something 
> resonable to base our menu-system on. 

It is not only reasonable, it would fix a number of outstanding
problems, the largest of which is internationalization.

package naming

[Deedra Waters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've been working on the package "kernel-patch-speakup" which has a source
package called speakup-cvs and produces the binary called
kernel-patch-speakup_20021221-1_all.deb, well, there is a stable version
of speakup that I'd like to package  and have it keep the
kernel-patch-speakup name. This source package is called speakup, and
produces a similar binary called "kernel-patch-speakup_1.5-1_all.deb"


I would like to continue packaging the speakup-cvs as well though, because
there is a great deal of time between speakup releases, anda lot of blind
people like to use the speakup cvs.

Basically my plan was  to have the stable version of speakup use  the
kernel-patch-speakup package name and move the speakup-cvs source into
kernel-patch-speakup-cvs, or something to that effect.

The problem currently is that the new source package produces a binary
package which already exists, and is generated by a different source
package

Would anyone be able to give me ideas on how to resolve this?

Thanks Deedra
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQE+26JTU5AGPOTGNc8RAh9ZAJ9kAcJug4mKKlcWdUWujuzeEtqOQQCgvKuZ
+72u7yelYACIjCgcPGISoGE=
=DrQ1
-END PGP SIGNATURE-

Re: Gaim-Encryption plugin violates Gaim's license#

[Robert McQueen]

On Mon, Jun 02, 2003 at 09:25:32AM -0500, Steve Langasek wrote:
> It should be noted that this can only be a violation of the GPL if
> someone is distributing the encryption plugin in binary form.  (Does
> Gentoo distribute binaries of this software?)  It is generally held that
> it would also *not* be a violation of the GPL if you distribute the
> encryption module in isolation, only if you distribute it together with
> binaries of gaim itself.

What about the end user who loads the plugin and OpenSSL becomes a part
of their running Gaim process? My concern is that even if you distribute
in source form, you're still condoning ignoring part of Gaim's license,
which seems highly dubious. So as well as saying "Debian will never ship
this" as a Debian developer, I was also saying "please do not encourage
your users to ignore our license" as a Gaim contributor. I'd favour that
Gaim-Encryption isn't included by distributors at all until it is
reworked to use GNUTLS as Bill has so kindly agreed to do, hopefully
within the next 2 or 3 weeks. Maybe around that time CVS will have settled
a bit and we can consider putting GNUTLS into Gaim and support Jabber SSL
finally...

> Given that you have explicitly said you don't have access to all
> contributors to effect I license change, I presume this means gaim is
> under the canonical GPL license, and that you are not attempting to
> promote an alternative, overbroad interpretation of the GPL with your
> statements above.

Yes, Gaim is under "GPL version 2 or later at your choice" and we are
unable to change this.

> To be precise, you cannot take advantage of the GPL's "OS exemption" if
> your product is the OS.

I don't quite see how this relates. What I meant was that if you have
Gaim for Windows, and load in Gaim-Encryption, then you have linked
OpenSSL into the GPL Gaim binary and therefore violated Gaim's license,
because OpenSSL is definitely not a component of the OS on Windows.

> -- 
> Steve Langasek
> postmodern programmer

Regards,
Rob

--
Exam progress-o-meter: [] 20%

Status of Sarge Release Issues (Updated for June)

[Drew Scott Daniels]

I didn't have much of a chance to update this report to be accurate to
more than from a few days ago, but here it is as I'll likely be busy for
the next few days. I'll try to post another message updating this stuff
again next month. Note I haven't included the latest apt translation
announcement or the much discussed menu system update announcement.

I may not be pointing to the canonical locations. My guesses about
priorities (1-3) of things to be done before Sarge is released is below
with status information. I'm unsure as to where to get status information
about some things in the second paragraph below (which is mainly about
packages).
2 Installer TODO: 
http://cvs.debian.org/debian-installer/doc/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup
1 Debian installer Ports(and architectures?) status: 
http://people.debian.org/~mckinstry/ports-status.html
http://lists.debian.org/debian-boot/2003/debian-boot-200305/msg00445.html
says all ports not likely for sarge.
http://lists.debian.org/debian-hurd/2003/debian-hurd-200305/msg00165.html
talks about the hurd status.
http://www.m17n.org/linux-sh/debian/packages.html seems to show that the
super H (sh) is almost ready (all base compiled).
2 i386 libc support? (The large thread starting with
http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01895.html
and going into the May archive talks about this). Do we have to wait for
upstream to fix this? We want to stay compatible with other distributions
which broke support for i386 in libc.
http://lists.debian.org/debian-devel/2003/debian-devel-200305/msg00360.html
describes the current situation.
1 gcc 3.3 (and g++ abi change?) transition status (versions with c102
suffix): http://people.debian.org/~rmurray/c++transition.html a search
reveils:
http://www.google.ca/search?as_q=c102&num=100&hl=en&ie=UTF-8&oe=UTF-8&btnG=Google+Search&as_epq=&as_oq=&as_eq=&lr=&as_ft=i&as_filetype=&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch=packages.debian.org&safe=images
but this search is inaccurate. It only tells about the last crawled i386
package pages and includes packages that depend/recomend/suggest these
i386 c102 packages. g++-3.2 and 3.3 have the same ABI. Transition should
now be done to 3.3, but I beleive this means packages already compiled
with 3.2 should still work.
2 Release Critical Bugs status: http://bugs.debian.org/release-critical/
1 Problems in testing:
http://ftp-master.debian.org/testing/testing_probs.html
2 IPV6 status & status guesses:
http://debdev.fabbione.net/cgi-bin/getstats
3 Debian Description Translation Projects (DDTP?) status:
http://ddtp.debian.org/stats/ with an anoncment (
http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200304/msg00015.html
) of an APT with translation support.
Also: http://www.de.debian.org/international/l10n/ has status and ranked
information about l10n and i18n in package Descriptions and templates.
http://www.de.debian.org/doc/devel-manuals#i18n (in development) talks
about howto do l10n, i18n, and m17n.
http://lists.debian.org/debian-devel/2003/debian-devel-200305/msg00348.html
discusses 4 basic goals.
2 UTF-8 or UTF8?
http://lists.debian.org/debian-devel/2003/debian-devel-200303/msg01520.html
suggests a status site.
http://lists.debian.org/debian-devel/2003/debian-devel-200305/msg02012.html
talks about the current list of programs with i18n support disabled.
3 Package attributes: (Is done by "tags" and/or keywords. I'd like to
include upstream trove information):
http://deb-usability.alioth.debian.org/debtags/index.html has details of
the tag Package browser, debtags package information and links to other
package tag discussions/information.
3 Menu system update to conform to
http://www.freedesktop.org/standards/menu/draft/menu-spec/menu-spec.html
(as suggested in
http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg00800.html
) The old update was abandonded but contributes to the new standard.
3 AMD x86-64 port? Several threads have been on debian-devel about this.
i386 packages will aparently work for this arch. (Note: According to
http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01975.html
AMD prefers the port to be called AMD64 and not x86-64 or alike) "gcc-3.3
is a prerequisite" says
http://lists.debian.org/debian-devel/2003/debian-devel-200305/msg00360.html
There is also a mailing list at http://lists.debian.org/debian-x86-64 to
replace the old alioth mailing list.

2 flex transition: Silently a major revision of flex came into unstable
and broke parts of openoffice.org, postgresql and many others. flex-old is
now available so a slower transition can be allowed while not delaying
sarge.
1 XFree86 status (sarge'll have 4.3.0, 4.2.1 was been abandonded due to
gcc compilation issues, but is back):
http://people.debian.org/~branden/xsf/
http://lists.debian.org/debian-x/2003/debian-x-200305/msg00134.html gives
some status and information about how to help.
http://lists.debian.org/debian-x86-64/2003/debian-

Re: Gaim-Encryption plugin violates Gaim's license#

[Steve Langasek]

On Mon, Jun 02, 2003 at 08:28:43PM +0100, Robert McQueen wrote:
> On Mon, Jun 02, 2003 at 09:25:32AM -0500, Steve Langasek wrote:
> > It should be noted that this can only be a violation of the GPL if
> > someone is distributing the encryption plugin in binary form.  (Does
> > Gentoo distribute binaries of this software?)  It is generally held that
> > it would also *not* be a violation of the GPL if you distribute the
> > encryption module in isolation, only if you distribute it together with
> > binaries of gaim itself.

> What about the end user who loads the plugin and OpenSSL becomes a part
> of their running Gaim process? My concern is that even if you distribute
> in source form, you're still condoning ignoring part of Gaim's license,
> which seems highly dubious. So as well as saying "Debian will never ship
> this" as a Debian developer, I was also saying "please do not encourage
> your users to ignore our license" as a Gaim contributor.

It is generally agreed that local modifications to a GPL work are not
restricted, as they fall under the category of "use" rather than
"copying and distribution".  The GPL is not an end-user license; no one
can ever be in violation of the GPL just by using the program.  It's
only when you distribute the program that these restrictions are in
effect.

It's my personal feeling that attempts to use the GPL as a click-through
EULA are sufficiently heinous that they merit editing the local source
to suppress the license's display, thus removing the need to agree to
the license before using the software.

> > To be precise, you cannot take advantage of the GPL's "OS exemption" if
> > your product is the OS.

> I don't quite see how this relates. What I meant was that if you have
> Gaim for Windows, and load in Gaim-Encryption, then you have linked
> OpenSSL into the GPL Gaim binary and therefore violated Gaim's license,
> because OpenSSL is definitely not a component of the OS on Windows.

Ah, mis-parse on my end.  Yes, OpenSSL is not part of the OS on Windows
-- and being part of the OS also doesn't help Debian, where packaging
the encryption plugin is concerned.

-- 
Steve Langasek
postmodern programmer


pgptnQo0UlrMh.pgp
Description: PGP signature

Re: Changelog issues with (among others) tkdiff 1:3.08-4

[Matt Zimmerman]

On Mon, Jun 02, 2003 at 12:01:40PM -0400, Lukas Geyer wrote:
> Brian Nelson <[EMAIL PROTECTED]> writes:
> 
> > I really enjoy reading a well-written changelog (and I'm subscribed to
> > d-d-changes so I tend to read them all), so I'm interested in improving
> > the quality of ones that aren't quite up-to-par.  If there's a consensus
> > that it's futile or pointless effort, I'll readily stop.
> 
> What about just contacting the maintainer in private? Why does this
> have to be on -devel? I think it is nice to have a meaningful
> changelog, but the human race and Debian will survive some
> not-quite-up-to-par changelog entries. If this was a separate bug, I
> would consider it "minor", and thus not worth Cc-ing to -devel.

The idea behind discussing problems in public, even when they are not going
to be fixed, is to prevent the same problems from happening in the future.

-- 
 - mdz

Re: Status of Sarge Release Issues (Updated for June)

[Rene Engelhard]

Hi,

Drew Scott Daniels wrote:
> 2 i386 libc support? (The large thread starting with
> http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01895.html
> and going into the May archive talks about this). Do we have to wait for
> upstream to fix this? We want to stay compatible with other distributions
> which broke support for i386 in libc.
> http://lists.debian.org/debian-devel/2003/debian-devel-200305/msg00360.html
> describes the current situation.

eh? libc? libstdc++5...

> 2 flex transition: Silently a major revision of flex came into unstable
> and broke parts of openoffice.org, postgresql and many others. flex-old is
> now available so a slower transition can be allowed while not delaying
> sarge.

.. when the people update their Build-Depends

OOo is going to be fixed in 1.0.3-3 btw to work with the new flex...

> 3 Ooo (OpenOffice.org 1.0.3?): More info at least on the debian ooo
> mailing list, is there a status site?
> http://packages.qa.debian.org/o/openoffice.org.html shows some info

That do you want to have wrt status?
OOo is in testing now (1.0.3-2), 1.0.3-3 is in preparation..

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73
   `-   Fingerprint: 41FA F208 28D4 7CA5 19BB  7AD9 F859 90B0 248A
  EB73


pgpV7gousvFRb.pgp
Description: PGP signature

Re: [Gaim-devel] Re: Gaim-Encryption plugin violates Gaim's license#

[Sean Egan]

On Mon, 2003-06-02 at 15:28, Robert McQueen wrote:
> My concern is that even if you distribute
> in source form, you're still condoning ignoring part of Gaim's license,
> which seems highly dubious. So as well as saying "Debian will never ship
> this" as a Debian developer, I was also saying "please do not encourage
> your users to ignore our license" as a Gaim contributor. I'd favour that
> Gaim-Encryption isn't included by distributors at all until it is
> reworked to use GNUTLS as Bill has so kindly agreed to do, hopefully
> within the next 2 or 3 weeks. 


"If the program dynamically links plug-ins, and they make function calls
to each other and share data structures, we believe they form a single
program, so plug-ins must be treated as extensions to the main program.
This means they must be released under the GPL or a GPL-compatible free
software license, and that the terms of the GPL must be followed when
those plug-ins are distributed."
--http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins

This indicates that the plugin must be released by terms of the GPL (or
GPL-compatible) license.  Obviously now it is not GPL-compatible,
regardless of whether it's distributed as source or as binaries.  Don't
feel compelled to remove your plugin; as long as you're actively working
to resolve these issues, I wouldn't worry too much about 29 little
words.

-s.

Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e")

[Herbert Xu]

Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 02, 2003 at 09:07:00PM +1000, Herbert Xu wrote:
> 
>> OK.  Let me ask you this question: what if the maintainer uploads a
>> new upstream release which happens to fix bug #xxx, and then sends
>> a message by hand to [EMAIL PROTECTED] with the message
>> "This bug is fixed in upstream version x.y.z".
>> 
>> Do you have a problem with this and if so why?
> 
> Yes.  There is no record in the package that a bug report in the Debian BTS
> was closed in this version.  What about other users who experienced the same

Why should that be in the package? What if you didn't know at the time that
the bug was fixed in this version?

> bug?  Is it so hard to explain what bug was fixed, and if possible, how it
> was fixed?

Remember that I'm talking about closing a bug in the BTS by hand.  So
what was fixed is obvious.  If you want to require everyone to explain
how it was fixed, well I don't think there is anything more I can say to
you.

> Would you upload a new kernel-source saying "Closes: #242141" rather than
> "apply patch from 2.6.48 to fix root security hole in nanosleep()"?

If this is fixed by upstream, yes.  I would simply say

  * New upstream release (closes: #xxx, #yyy, #zzz).

When I open up a Debian changelog, I expect to see what the Debian
developer has done to it.  I don't mind seeing changelog entries
explaining upstream changes as long as they're clearly marked.  And
I would be most concerned if people start putting them in without
marking them as upstream.
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Proposal: a generic dpkg event hook broker

[Adam Heath]

On Mon, 2 Jun 2003, Jarno Elonen wrote:

Already being planned for dpkg 2.0.  Note, this has to be tied in with the
status of the package being hooked, as the status changes state, so it really
needs to be done in dpkg.

Changelogs (Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e"))

[Matt Zimmerman]

On Tue, Jun 03, 2003 at 07:42:05AM +1000, Herbert Xu wrote:

> Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> > Yes.  There is no record in the package that a bug report in the Debian BTS
> > was closed in this version.  What about other users who experienced the same
> 
> Why should that be in the package? What if you didn't know at the time that
> the bug was fixed in this version?

You obviously can't document what you don't know.  This discussion was about
closing bugs in the changelog (which obviously implies that the maintainer
knows that they are closed) without explaining why.

> > bug?  Is it so hard to explain what bug was fixed, and if possible, how
> > it was fixed?
> 
> Remember that I'm talking about closing a bug in the BTS by hand.

I'm talking about changelogs.

> > Would you upload a new kernel-source saying "Closes: #242141" rather
> > than "apply patch from 2.6.48 to fix root security hole in nanosleep()"?
> 
> If this is fixed by upstream, yes.  I would simply say
> 
>   * New upstream release (closes: #xxx, #yyy, #zzz).
> 
> When I open up a Debian changelog, I expect to see what the Debian
> developer has done to it.  I don't mind seeing changelog entries
> explaining upstream changes as long as they're clearly marked.  And I
> would be most concerned if people start putting them in without marking
> them as upstream.

When I open a Debian changelog, I expect to see changes which are pertinent
to Debian development.  This obviously includes changes which affect the
status of Debian bug reports.

As for attribution, I do not think this is a problem in practice, but this
is the format I use:

foo (2.1.1-1) unstable; urgency=high

 * New upstream release
   - use snprintf rather than sprintf to prevent a buffer overrun
 (Closes: #528432)
   - do some other things which relate to how this package is used in
 Debian
 * Build-Depends on more recent libbar
 * Don't forget to install the documentation (Closes: #879242)

It is perfectly clear what changes are made by whom, and how these changes
affect Debian bug reports.

-- 
 - mdz

Re: Debian menu system update

[Gustavo Noronha Silva]

Em Mon, 2 Jun 2003 12:23:55 +0200, "Bernhard R. Link" <[EMAIL PROTECTED]> 
escreveu:

> > > Does this mean there simply is no such documentation?
> > 
> > I think it's pretty clear how it should be done.  Once we adopt the
> > system, we can point system administrators to the relevant file in our
> > documentation, and give pointers to the file format.
> 
> I think there should first be a documentation. Anything I've seen yet

That's a matter of writing the docs... I, for one, documented the
current menu system on a document I wrote for Debian-BR.

I'm more than willing to write documentation for the freedesktop
format. I'm all for its adoption! Go Walters! Go! =D

> [4] I know, when I tell I badly need exactly the same looking 
> menu in a miriad of window managers with as many items that 
> the debian-menu-hirachy is on its limit, I will get answers
> like "KDE-programs should not be shown in Gnome" and "non-KDE
> programs are nothing newbie users can cope with in KDE" and
> other opinions, people invented by thinking on their single
> -user machine what newbies might want or what administrators
> coping with many newbies might want.

We can write stuff to support various kinds of menu layout.
That's not a great problem for now, I think. First we get a
nice, standardized menu system, then we write some configuration
tools and create the "vfolders" the way we want.

[]s!

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
Debian:   *  
Dúvidas sobre o Debian? Visite o Rau-Tu: http://rautu.cipsga.org.br

Re: Celebrating Debian's 10th birthday?

[Sean 'Shaleh' Perry]

On Sunday 01 June 2003 18:24, Alexander Neumann wrote:
> Hi,
>
> While digging around in the calendar-files at infodrom.org I suddenly
> realized that Debian will have it's 10th birthday at August, 16th
> (according to the calendar.infodrom.debian file at
> http://www.infodrom.org/projects/calendar/)
>
> Are there any parties planned already? ;)
>
> - Alexander

That's a week after LinuxWorld in San Francisco so we may celibrate it early 
(-:

Re: console mode(probally off)

[Sean 'Shaleh' Perry]

On Monday 02 June 2003 04:09, Luiz Rafael Culik Guimaraes wrote:
> Dear Friends
>
> How to start debian  direct on console mode,
>
> Regards
> Luiz

Eh?  I thought Debian always started in console mode unless you both installed 
xdm (or the gnome/kde equivalent) and enabled it.

Re: new bug tags

[Javier Fernández-Sanguino Peña]

On Sun, Jun 01, 2003 at 01:21:14PM -0300, Andre Luis Lopes wrote:
> On Sun, Jun 01, 2003 at 12:05:42PM +0200, Javier Fernández-Sanguino Peña 
> wrote:
> > 
> > I thinks that the long-asked by i18n maintainers 'translation' tag should 
> > probably be added too. It helps boths translators and maintainers since it 
> > introduces a way to manage i18n/l10n related bugs (which are forwarded to 
> > translation teams)
> 
> I surelly would second this.
> 

Seems that not many people are interested in it, though. It didn't even get 
in the draft version for the next DWN [1] :-(

Regards

Javi



[1] http://www.infodrom.org/~joey/Writing/DWN/dwn-2003-22.html


pgpTMW1wo17ZM.pgp
Description: PGP signature

Re: Changelogs (Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e"))

[John Hasler]

mdz writes:
> When I open a Debian changelog, I expect to see changes which are
> pertinent to Debian development.  This obviously includes changes which
> affect the status of Debian bug reports.

>From Debian-Policy 3.5.10.0:

   Debian Policy Manual - Source packages (from old Packaging Manual) (7/11) 
   C.2.3 debian/changelog 
   This file records the changes to the Debian-specific parts of the
   package [72].

This would seem to preclude upstream bug-fixes.
-- 
John Hasler
[EMAIL PROTECTED]
Dancing Horse Hill
Elmwood, Wisconsin

Re: console mode(probally off)

[Alexander Schmehl]

* Sean 'Shaleh' Perry <[EMAIL PROTECTED]> [030603 01:06]:

> > How to start debian  direct on console mode,
> Eh?  I thought Debian always started in console mode unless you both 
> installed 
> xdm (or the gnome/kde equivalent) and enabled it.

Which is the case, if he choosed "desktop environment" (contains at
least gdm and kdm) in tasksel during the installation.

Sincerely
  Alexander


pgpOnd7Exg4bt.pgp
Description: PGP signature

Re: console mode(probally off)

[Adam Borowski]

On Mon, 2 Jun 2003, Sean 'Shaleh' Perry wrote:
> On Monday 02 June 2003 04:09, Luiz Rafael Culik Guimaraes wrote:
> > How to start debian  direct on console mode,
> Eh?  I thought Debian always started in console mode unless you both 
> installed 
> xdm (or the gnome/kde equivalent) and enabled it.
Unfortunately, all of these three ({x,g,k}dm) automatically start X when 
the system starts if they are installed, and AFAIK neither of them 
provides a way to disable them other than uninstalling them or editing 
/etc/{rc*.d,init.d}/whatever by hand.

The things are even worse: a vast majority of novice users use tasksel 
when installing Debian, and the two most often selected tasks ("X window 
system" and "desktop environment") include xdm variants.  Thus, questions 
like "How to start debian direct on console mode" have a lot of merit.
It might be just me, but my eyes hurt more after a few hours of doing 
things in graphics mode than after a 48h straight programming run on a 
text console.



As a completely unrelated note, I wonder what is the reason to use fbdev 
instead of real text console/svgatextmode in the default kernel.  I was
setting up a server on an old Pentium MMX 210Mhz machine yesterday, and 
switching between consoles took more than a second.  Considering that even 
on a 1300Mhz machine with GForce2 at home fbdev scrolling is noticeably 
sluggish, I'm afraid to even think about what would happen on a 386.

What about reverting the installation kernels back to the good old real
text console, which has been enjoyed full hardware acceleration since 
the times of MDA cards?

1KB
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)

Re: console mode(probally off)

[Alexander Schmehl]

* Luiz Rafael Culik Guimaraes <[EMAIL PROTECTED]> [030602 13:09]:

> How to start debian  direct on console mode,

One possibilitie is to remove all display manager packages: apt-get
remove --purge xdm kdm gdm wdm

(Perhaps you didn't installed all of them.)

The other possibillitie would be to deaktivate all start up links for
those login managers using the "update-rc.d" command.

Sincerely
  Alexander


pgpGXQn32YDbI.pgp
Description: PGP signature

Packages file under version control

[Glenn McGrath]

If we put the Packages file under some sort of version control (e.g.
cvs), bandwidth requirments would be minimised as cvs automatically
takes care of diff's and patching, and i assume the CPU load from cvs
server is a lot better than rsync. 



Glenn

Re: console mode(probally off)

[Daniel Burrows]

On Tue, Jun 03, 2003 at 03:13:35AM +0200, Alexander Schmehl <[EMAIL PROTECTED]> 
was heard to say:
> The other possibillitie would be to deaktivate all start up links for
> those login managers using the "update-rc.d" command.

  Or to install file-rc and edit /etc/runlevel.conf.

  Daniel

-- 
/ Daniel Burrows <[EMAIL PROTECTED]> ---\
| "Note that fires are not restricted to dormitories. |
|  Indeed, fire can occur in off-campus residences as well."  |
|   -- Brown University Fire Safety Guide |
\- The Turtle Moves! -- http://www.lspace.org /

Re: console mode(probally off)

[Sean 'Shaleh' Perry]

On Monday 02 June 2003 17:47, Adam Borowski wrote:
> On Mon, 2 Jun 2003, Sean 'Shaleh' Perry wrote:
> > On Monday 02 June 2003 04:09, Luiz Rafael Culik Guimaraes wrote:
> > > How to start debian  direct on console mode,
> >
> > Eh?  I thought Debian always started in console mode unless you both
> > installed xdm (or the gnome/kde equivalent) and enabled it.
>
> Unfortunately, all of these three ({x,g,k}dm) automatically start X when
> the system starts if they are installed, and AFAIK neither of them
> provides a way to disable them other than uninstalling them or editing
> /etc/{rc*.d,init.d}/whatever by hand.
>

hmmm, yes.  There are ways to disable them but they are not immediately 
obvious to the Debian newbie.

> The things are even worse: a vast majority of novice users use tasksel
> when installing Debian, and the two most often selected tasks ("X window
> system" and "desktop environment") include xdm variants.  Thus, questions
> like "How to start debian direct on console mode" have a lot of merit.
> It might be just me, but my eyes hurt more after a few hours of doing
> things in graphics mode than after a 48h straight programming run on a
> text console.
>

your eyestrain may indicate a poorly configured X setup (too low of a refresh 
rate) or a need for more contrast in your desktop setup.

Re: Changelogs (Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e"))

[Matt Zimmerman]

On Mon, Jun 02, 2003 at 07:06:12PM -0500, John Hasler wrote:

> mdz writes:
> > When I open a Debian changelog, I expect to see changes which are
> > pertinent to Debian development.  This obviously includes changes which
> > affect the status of Debian bug reports.
> 
> >From Debian-Policy 3.5.10.0:
> 
>Debian Policy Manual - Source packages (from old Packaging Manual) (7/11) 
>C.2.3 debian/changelog 
>This file records the changes to the Debian-specific parts of the
>package [72].

I disagree with that sentence (note that it is not really part of the policy
document itself, but a pseudo-merge of the old packaging manual).

-- 
 - mdz