Actually, the bugs website has been around for ever, and there are instructions there for submitting bugs. Or you could use the reportbug package, which also comes with a program called "querybts" for querying the bug tracking system without the aid of a browser.
It probably would work, indeed. However, I tend to think that using --force-depends (or --force-anything) should only be for special circumstances; if the packages aren't broken, you shouldn't ever need them. (For instance, leaving out the --force-depends in your example would have worked as the guy you followed up to said, and wouldn't have left you with a broken database for a while.)
Actually, there is such a tarball snapshot: potato/main/disks-i386/current/base2_2.tgz. It's handy if (a) you know what you're doing and already have a Unix system handy on which to unpack the tarball, or (b) you want to install a small potato system inside an existing Debian system.
(The latter isn't as silly as it sounds; if you're building Debian packages then it's useful to have a "pure" base system to build and test them on, as normal systems can build up cruft that sometimes causes problems.)
In Debian, DFSG-freeness isn't connected to the filesystem structure at all. Non-free packages (say, Netscape) are still placed in/usr, because the Debian policy applies to free and non-free packages alike.
The policy is what makes Debian so solid, mostly adhering to the principle of least surprise. The process is open and evolving, too.
Python will still be in Debian; you must have been listening to the wrong propaganda. I haven't been keeping track, but it looks like the question is actually about whether you can distribute GPLed programs that have Python embedded in them (I doubt it could reasonably affect Python scripts); Python itself is still obviously Open Source (tm), free to distribute, or whatever.
Taking the law strictly, as he probably is, it's hard to deny that RMS has a point. GPL section 4:
4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
That said, it's not worth arguing about, and protracting the flamewar further will serve no useful purpose (and before this I've always agreed entirely with RMS). If you want to interpret the GPL strictly, then for the sake of actually getting something done you could consider it that a copyright holder might decide to go to KDE and say "excuse me, you can't distribute our software"; in that case I'd hope that some sort of amicable agreement could be arrived at. However, in the absence of any copyright holders actually complaining about it, we should just get on with our lives.
Re:More Debian-valid Software -- is this really go
on
Qt Going GPL
·
· Score: 1
The real solution to this is to improve the Debian archive and associated tools so that the package system is easier to manage. I don't think we want to start saying "no, you can't package that, the distribution's too full now"; instead, there need to be various keyword search and categorization options, that sort of thing.
The much-talked-about though never-quite-here package pool idea may provide a good infrastructure for this.
As soon as Qt 2.2 appears, it'll be rock-solid legal as far as debian-legal's concerned. Debian's ftpmasters won't argue with something that can be completely GPLed, at the risk of being laughed at.:)
Given that, it only takes one interested Debian developer. There's no grand strategic plan about what to include and what not to include, beyond the DFSG. As far as I know, simply nobody could be bothered to deal with kdelibs while the rest of the KDE flamewar was up in the air.
Anyway, Krusty (the guy who's been running kde.tdyc.com) has already uploaded a kdesupport source package to Debian incoming.
No, it's OK. Qt 2.2 will be dual-licensed, so you have the option of using either the QPL or the GPL, depending on whether your licence was QPL- or GPL-compatible. See the first paragraph of the announcement.
Connect to, or connect from? I can certainly connect to ntlworld from my Linux 2.4.0-test2 box with no problems whatsoever. What problems are you having? Of course, I'll be switching to a cable modem as soon as I get some funds into my bank account...
The ntlworld installation was probably the most complicated I've done in a long time, as I had to use Windows 95 inside VMware (and of course VMware crashed more than once in the process). Nothing I could find could open the.cab files they shipped, either (claimed they were corrupt), or I'd have tried fishing the details out manually.:(
Slashdot Mirror
Actually, the bugs website has been around for ever, and there are instructions there for submitting bugs. Or you could use the reportbug package, which also comes with a program called "querybts" for querying the bug tracking system without the aid of a browser.
It probably would work, indeed. However, I tend to think that using --force-depends (or --force-anything) should only be for special circumstances; if the packages aren't broken, you shouldn't ever need them. (For instance, leaving out the --force-depends in your example would have worked as the guy you followed up to said, and wouldn't have left you with a broken database for a while.)
Actually, there is such a tarball snapshot: potato/main/disks-i386/current/base2_2.tgz. It's handy if (a) you know what you're doing and already have a Unix system handy on which to unpack the tarball, or (b) you want to install a small potato system inside an existing Debian system.
(The latter isn't as silly as it sounds; if you're building Debian packages then it's useful to have a "pure" base system to build and test them on, as normal systems can build up cruft that sometimes causes problems.)
In Debian, DFSG-freeness isn't connected to the filesystem structure at all. Non-free packages (say, Netscape) are still placed in /usr, because the Debian policy applies to free and non-free packages alike.
The policy is what makes Debian so solid, mostly adhering to the principle of least surprise. The process is open and evolving, too.
Port lintian (Debian's implementation of the same thing). If you have a policy to work from, it wouldn't be that hard.
Python will still be in Debian; you must have been listening to the wrong propaganda. I haven't been keeping track, but it looks like the question is actually about whether you can distribute GPLed programs that have Python embedded in them (I doubt it could reasonably affect Python scripts); Python itself is still obviously Open Source (tm), free to distribute, or whatever.
That said, it's not worth arguing about, and protracting the flamewar further will serve no useful purpose (and before this I've always agreed entirely with RMS). If you want to interpret the GPL strictly, then for the sake of actually getting something done you could consider it that a copyright holder might decide to go to KDE and say "excuse me, you can't distribute our software"; in that case I'd hope that some sort of amicable agreement could be arrived at. However, in the absence of any copyright holders actually complaining about it, we should just get on with our lives.
The much-talked-about though never-quite-here package pool idea may provide a good infrastructure for this.
Given that, it only takes one interested Debian developer. There's no grand strategic plan about what to include and what not to include, beyond the DFSG. As far as I know, simply nobody could be bothered to deal with kdelibs while the rest of the KDE flamewar was up in the air.
Anyway, Krusty (the guy who's been running kde.tdyc.com) has already uploaded a kdesupport source package to Debian incoming.
No, it's OK. Qt 2.2 will be dual-licensed, so you have the option of using either the QPL or the GPL, depending on whether your licence was QPL- or GPL-compatible. See the first paragraph of the announcement.
word2x makes a decent enough job of it (although I've only looked at its plain text output).
You don't have to make ten pounds' worth of non-Internet calls if you're already paying NTL line rental, either.
Connect to, or connect from? I can certainly connect to ntlworld from my Linux 2.4.0-test2 box with no problems whatsoever. What problems are you having? Of course, I'll be switching to a cable modem as soon as I get some funds into my bank account ...
.cab files they shipped, either (claimed they were corrupt), or I'd have tried fishing the details out manually. :(
The ntlworld installation was probably the most complicated I've done in a long time, as I had to use Windows 95 inside VMware (and of course VMware crashed more than once in the process). Nothing I could find could open the
Great once you get it going, all the same.