Want to help write KC Debian? See the KC Authorship page the KC Debian homepage, and the Thread Summary FAQ. Send any questions to the KCDevel mailing list.
Thomas Bushnell ran into a problem with the new XFree86 version 4 packages:
When I installed X4, I got a warning from the xlib install that my app-defaults /usr/X11R6/lib/app-defaults was not a symlink; that it should be, and that files there would be ignored.
So I moved the files there into /etc/X11/app-defaults, and I turned /usr/X11R6/lib/app-defaults into a symlink pointing to /etc/X11/app-defaults.
Everything worked.
Today's xlib package install fails, though, as follows:
dpkg: error processing /var/cache/apt/archives/xlibs_4.0.1-2_i386.deb (--unpack):
trying to overwrite `/usr/X11R6/lib/X11/app-defaults', which is also in package xxgdb
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Errors were encountered while processing:
/var/cache/apt/archives/xlibs_4.0.1-2_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)Many packages compiled against X3 seem to include this directory in their package.
What should I do? Where should the app-defaults be? Should there be a symlink?
Branden Robinson confirmed that the app-defaults file should be /etc/X11/app-defaults, that /usr/X11R6/lib/X11/app-defaults ought to be a symlink, and advised filing bugs against packages that include files in the old app-defaults location. A policy revision in this regarding this was promised.
Remco van de Meent was not impressed; he listed 108 packages that used the old location. Others griped about suddenly having a bunch of files on their (potentially) small root partition.
Thomas, on the other hand, was appeased, but suggested that the xlib package should create the needed symlink automatically, sometime before woody was released, so that apt-get dist-upgrade would work. Branden said it was in his plans. Meanwhile, H. S. Teoh suggested using "dpkg --force-overwrite --install" on the xlibs package to get it to create the symlink.
Samuel Hocevar wondered,
Now that XFree 4 has made it into woody, should we compile new
packages against it ? Will XFree 3.3 disappear, or will we have two
versions of XFree in woody ?
Samuel was concerned because he had
at least one package that works well under XFree 3.3 but barfs
completely on XFree4, whether compiled under X4 or X3.3. I did not
manage to have both versions installed, so it's a real PITA to debug
(remote debugging would not work, nor would Xnest-like tricks), should
we say goodbye to XFree 3 ?
Branden Robinson put Samuel's mind at ease, saying
The XFree86 version 3 packages will stick around for a while. On i386, to
provide the libc5-compat X libraries and to provide a few legacy X servers,
and on alpha to provide a few legacy servers.
Anthony Towns suddenly re-started a thread from early October, in which several folks were discussing the rigidity of bug severity levels. In particular, there are three levels of bug severity (important, grave, and critical) that will cause a package not to be released, while there is a single bug level for "normal" bugs, leaving no way to distinguish bugs in the latter category. Anthony mused:
So here are what seem to be the givens.
- We need some way of marking out which problems make packages unsuitable for release (ie, we're better of not releasing the package than releasing it with that problem).
- We need some way to differentiate other problems to work out which are more important to focus efforts on fixing those.
At the moment the "important" severity is often being used for the latter although it's theoretically intended for the former, which makes it somewhat useless.
So, how about splitting them? What would people think of a bug tag:
brownbag -- A bug that makes you want to put a brown paper bag over your head. Something that would be annoying to release with, but not necessarily unacceptable. The package maintainer has the final word on whether a bug is a brownbag bug or not. Brownbag bugs will not affect whether a package is eventually released or not.
Would this make clarifying "important" to be:
important -- A severe violation of Debian policy (that is, a violation of a "must" or "required" directive).
more acceptable to people? (I say "clarifying" because that's what I was using to differentiate "important" and "normal" bugs during the potato freeze) Again, please note that filing an "important" bug is not something people should be doing naively: it's not a voting mechanism, it's not for opinions, it's for saying that this package must not be released in its current state, under almost any circumstances.
OTOH, filing a `brownbag' bug is much less likely to cause problems.
I imagine it'd probably be worthwhile to have a brownbag bug list, like the RC bug list, for people who're bored and want something to fix.
Neal H Walfield expressed skepticism that folks would read the documentation and really understand what "brownbag" meant. Sean Perry pointed out that the tag would be unintuitive for non-native English speakers. Anthony thought a bit, discovered that there was an undocumented "minor" severity already in the BTS, and suggested the following set of severities:
Release critical bugs:
Normal bugs:
Otherwise:
Mariusz Przygodzki reported:
About month ago one of the local fiscal office in Poland has laid a tax on some company in Poland which uses Linux servers and StarOffice apllications. This information appeared in the past week in Polish edition of Computerworld. AND THIS IS NOT A JOKE.
The fiscal office has treated GNU software as a DONATION for this company with a price on the level of M$ Windows NT and M$ Office prices. According to the Polish tax regulations this company must pay about 30% (thirty percents) of these values now. So much.
Three weeks ago Computerlworld has asked Polish Treasury about an interpretation of a term of donation in case of GNU software. Nobody from the Treasury replied yet.
Maybe this is a less problem for commercial Linux distros like RedHat, Mandrake, Suse, Caldera etc. because these product have small prices and they can not be treated as donations but only as expenses. I hope because there is still not clear issues concerns prices of GPL, LGPL, Artistic, BSD licenses within the scope of Polish tax regulations.
What in a case of Debian GNU/Linux servers? I have some fears.
I am not sure but maybe some official letter from the Debian community to the Polish Treasury may change something in their mind.
Arthur Korn asked why the comparison to Windows, since something
like Solaris seemed a better comparison to make. Mariusz replied, they choose Windos for a price comparison because
"it's a leading software in Polish market".
And Marcin Owsiany
corrected, Actually because 'Microsoft is a
leading software producer in the market'
Elsewhere, under the Subject: GNU/Linux taxed in Poland ?! [link], Wichert Akkerman reported that he'd asked Richard M. Stallman for an opinion, but hadn't heard back from him yet.
Elsewhere, under the Subject: Re: GNU/Linux taxed in Poland ?! (fwd), Mariusz gave a link to an article in Polish. Close by, Christopher F. Miller suggested issueing an optional bill licensing all use in Poland for $10.00, but Mariusz pointed out that this would violate the GPL. Elsewhere, Mariusz added:
In case of Debian distro this is more serious problem because Debian is non-commercial distro. Some people do not want to buy Storm or Corel distros and they prefer a woody.
This is another important problem yet - licenses. Tax-controllers do not understand a difference between a free software (in GNU sense) and a free PC. They assumed if some company received a licensed software for free that it means this software has a regular price normally. And then they treats this software as a donation.
Dariush Pietrzak corrected, that's not why
they taxed it - under polish law when your receive sth that you gain money
with then you pay taxes for it.
Mariusz disagreed, saying, I has consulted it with financial guys. A donation
is an income simply. So you have to pay taxi. It doesn't matter if you gain
money from this donation or not. This is your problem only and this is not
problem of tax-controllers.
And Henning Makholm replied:
This is stange. Around here, commercial businesses do not pay tax of their *income* - the pay tax of their *profit*. Thus if the "donation" of free software has any tax consequenses it would only be the remote consequence of helping the copmany make a taxable profit.
The only exception I can think of is if the company somehow had the software figuring as an asset, in which case ignorant tax people might think that an asset valuation of zero could be a way to try to hide a profit in the books.
However, a *copy* of a piece of free software has very little value -- as witnessed by the fact that you can buy it on the free market for $10. And the *right* to use the free software is someone everyone has, and is not connected with the act of actually using the free software.
There was no reply.
David Greene asked if KDE 2.0 and Mozilla M18 was available for Debian
2.2 (Potato). Ivan E. Moore II thought that Mozilla M18 was part of 2.2r1
already and added, as for KDE...check out http://kde.tdyc.com.
Othmar Pasteka
later confirmed that Mozilla was already instaleld
into the archive
for Potato i386.
Yotam Rubin asked, is there really room for the
package anarchism? According to how I see it, anarchism doesn't relate
directly to computers. Bascially, it performs the duty of expressing a
political opinion. Should Debian officially endorse political material?
Another thought, if Debian is to include political material, shouldn't the
entire spectrum be heard? I don't think that Debian exists in order to tip
the balance in the favor of anarchism.
David Starner replied that the
subject had come up before, and that A developer
has huge flexibility on what they can upload, with the main force against it
being social. I believe the maintainer agreed that once the data section was
created, it would be moved to the data section. There it stands, and there
it will stand until something changes. If you don't want it, don't install
it.
He also asked people to please not start up the flamewar again.
In the course of discussion, various folks pointed out that Debian also included the Bible and similar packages. There was a lot of back-and-forth about whether such things should be included in Debian, and it was again mentioned that the 'data' section, when it appeared, would be the proper place for those documents. At one point David Starner said:
If someone uploads something hateful, I'm sure that the Debian developers will take action to remove it before release, and probably action to prevent anything like it being uploaded. But until then, nobody's being hurt by a few packages laying around the archives. Pick one up, look through it, maybe you'll learn something. Or don't.
Remember when someone uploaded huge maps of coastlines? Several developers complained until the offending developer relented. Had he not relented, Debian would have been heaver by a couple hundred megabytes . . . and nothing would have happened. Had "they" decided to toss regulations around, everyone's blood pressure would have been up, and Debian would probably have lost at least one good developer.
Ralf Treinen pointed out that 'hateful' was in the eye of the beholder,
and he personally found that the bible being
distributed by Debian deeply shocks me, and that I wouldn't have considered
becoming a member if the bible was not counter-balanced by the anarchism
package.
He added, being member of a project
that distributes theistic propaganda is hard to swallow for me. Though I
can life with the existing compromise. The best would be to ban completely
religious, philosophical or political documents from Debian.
To which
Steve Greenland remarked, Such as, perhaps,
the GNU Manifesto? Or the Debian Social Contract? I'm not a big fan of the
Christian Bible either, but it hardly *hurts* me.
Interspersed with
these arguments, other folks advocated simply not installing packages they
didn't want, while others continued to remind people that the discussion had
taken place before and was available in the archives.