Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Joerg Jaspert writes: >>> I don't think anyone disagrees with this, including the ftp-masters. The >>> question is whether the source package also needs a copyright file of its >>> own. >> As we are distributing these files, it seems reasonable to document their >> licence. But the Policy is not clear about that requirement. > > We distribute source and binary. So the copyright file has to document > the contents of them all. Most commonly packages have exactly 1 of those > files, copied everywhere. Then it has to document all, and the file > ending up in binary packages will obviously document the source tarball > too. > Now, you can go and split the file, and have one per binary package > seperated, as well as one documenting all of it once for the source. > Besides that being a fair bit of useless extra work, for both you and > ftpmaster, it seems pretty pointless to do, as the only thing that > happens with just one file for all is "slightly more text in the file as > the binary may need". Aren't the licenses of source files generally documented by upstream, either by e.g. the COPYING file or inline within the files themselves? Why is there a requirement to duplicate this information in the copyright file? A binary package needs a copyright file because the copyright notices would otherwise be stripped out or obfuscated. That's not true for the source package though. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hbiy4hbc@bignachos.net
Re: Hardware trouble ries.debian.org - ftpmaster.debian.org / release.d.o services back this weekend
Luca Filipozzi writes: > ries is located at Brown University. Brown provides free hosting, > bandwidth and remote intelligent hands. They have provided exemplary > support but it doesn't include (nor should we have an expectation that > it includes) 4-hour response. > > ries is covered by a next business day post-warranty support agreement > with the vendor. > > There were two contributing factors to time between problem occurrence > and problem resolution: (1) back and forth with the vendor in an attempt > to diagnose the true fault (initial diagnosis was faulty DIMMs; > subsequent diagnosis was faulty mainboard) and (2) once diagnosed, > shipping delays (parts ordered morning of 30th, but arrived on 2nd). The entire state of Rhode Island being underwater on March 30-31 due to some historic flooding probably had a little something to do with the shipping delays... -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zl1ffg4k@bignachos.net
Re: md5sums files
Don Armstrong writes: > On Sat, 06 Mar 2010, Andreas Metzler wrote: >> Russ Allbery wrote: >> > Figuring out a better solution for why the files in >> > /var/lib/ispell and /var/lib/aspell are excluded from the md5sums >> > generation because they change after installation is probably >> > needed >> >> I think these hash files are not arch independent. Which is why the >> packages only ship empty files in the deb and generate the correct >> binary data in postinst. This way the hash files are listed in dpkg >> -L, and dpkg takes care of removal instead of relying on >> maintainerscripts. > > So there's a period on upgrade where the file has been overwritten > with an file before the new file has been generated? > > That's just wrong. Why? Considering the old hash file may be invalid anyway after you've upgraded other related packages (the aspell dict ones are format-dependent on the aspell version), why would it matter that the hash file is temporarily empty? -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vdd6hns0@bignachos.net
Re: Iceweasel and Firefox compatibility
Mike Hommey wrote: On Tue, Nov 10, 2009 at 11:05:47PM +0100, Michael Banck wrote: On Tue, Nov 10, 2009 at 10:45:04PM +0100, Mike Hommey wrote: On Tue, Nov 10, 2009 at 11:43:19AM -0600, John Goerzen wrote: John Goerzen wrote: Firefox/x.y.z Iceweasel/x.y.z Sounds too Firefoxy. What's the problem with that? I thought Iceweasel *was* Firefox for all practical purposes, modulo branding and usual distribution patches. Did we actually seriously fork Firefox since the rename? Simply putting Firefox like that in the UA can sound like it is Firefox. And we still don't have the right to use the Firefox name on something that doesn't bear the Firefox logo. I'd rather avoid yet another trademark issue, and if the (like Firefox/x.y) works as well, it's safer to go that way. How can the trademark possibly extend to the UA string (something generally never shown to the user and generally being unrelated to the name of the application or logo)? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Amendment to GR on GFDL, and the changes to the Social Contract
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Brian Nelson <[EMAIL PROTECTED]> writes: > >> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: >> >>> Brian Nelson <[EMAIL PROTECTED]> writes: >>> >>>> I completely agree, and hereby question whether the secretary is capable >>>> of being impartial in this case given his personal interests[1] in this >>>> issue. >>> >>> You may question it, but it doesn't affect the case. >> >> W, look at me! I'm Thomas Bushnell and I reply to every single >> message on every single Debian mailing list, regardless of whether I >> have anything useful to say! > > Huh? You seemed to be saying (using quite formal language like > "hereby") that your questioning should have some effect. It was a jest, partly at Manoj's writing style because I knew he'd read it, and partly at the overall absurdity that seems to be plaguing the project. The point still stands, however. > My point is that it does not, and need not. It has only whatever > effect Manoj chooses to give it. The secretary is supposed to "make decisions... preferably consistent with the consensus of the Developers". By speaking out against it, I'm trying to change the consensus. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Brian Nelson <[EMAIL PROTECTED]> writes: > >> I completely agree, and hereby question whether the secretary is capable >> of being impartial in this case given his personal interests[1] in this >> issue. > > You may question it, but it doesn't affect the case. W, look at me! I'm Thomas Bushnell and I reply to every single message on every single Debian mailing list, regardless of whether I have anything useful to say! -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
Christopher Martin <[EMAIL PROTECTED]> writes: > On Thursday 19 January 2006 20:39, Don Armstrong wrote: >> On Thu, 19 Jan 2006, Christopher Martin wrote: >> > No, because as I wrote the whole point of the amendment is to make >> > officially acceptable the interpretation of the license which views >> > the license as flawed, but still DFSG-free. This amendment is in no >> > way arguing for any sort of exception or modification or suspension >> > of the DFSG. >> >> The issue here devolves into a question of interpretation; if we can >> decide to interpret the Foundation Documents in any way we want simply >> by a majority vote, the requirement to have changes to them meet a 3:1 >> majority becomes rather pointless. > > This is a real dilemma faced by all constitutions or similar charter > documents. Unfortunately, all constitutions can be undermined by the > reinterpretation of seemingly small details. But one person's "undermining" > is another person's "upholding". > > The important question here is one of legitimacy. Who exactly has the > authority to determine these matters of interpretation? Specifically, who > decides what is in accordance with the DFSG? The developers do, through > GRs, if I understand correctly. Certainly nothing in my reading of the > Constitution suggests that the Secretary has this power. > > The Secretary seems to be adopting the view that anyone who disagrees with > his interpretation of the GFDL is not holding a legitimate opinion. Given > the length of the GFDL debates, the acrimony, and the number of developers > who remain on both sides, this seems far, far too strong a stance for a > Project officer to adopt (even if Manoj holds that view personally). Hence > my complaint. I completely agree, and hereby question whether the secretary is capable of being impartial in this case given his personal interests[1] in this issue. [1] http://people.debian.org/~srivasta/Position_Statement.xhtml -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
Christopher Martin <[EMAIL PROTECTED]> writes: > On Thursday 19 January 2006 12:09, Adeodato Simó wrote: >> However, I'm pretty sure that more than one Developer thinks the >> proper interpretation would be: >> >> (b) this amendment overrules debian-legal's assessment that certain >> two clauses of the GFDL are non-free, and thus needs 1:1 > > Right. To declare that the amendment would constitute a modification of a > foundation document is to presuppose the very issue that this amendment > seeks to clarify, namely, whether or not the GFDL-minus-invariant-sections > is indeed non-free. If the amendment passes, then > GFDL-minus-invariant-sections docs would not be considered non-free, and so > could be allowed in main without any special dispensation. The amendment is > not intended to declare that we should suspend the DFSG for the sake of > expediency; such a proposal would indeed require a 3:1 supermajority. > Rather, it simply promulgates the interpretation that the GFDL, minus > invariant sections, while not perfect, is still DFSG-free. Ummm, so how exactly does declaring an interpretation of the DFSG as the one the project accepts constitute a modification? Are you telling me that when a judge interprets a law to make a ruling, that law has been changed in some way? -- Captain Logic is not steering this tugboat.
Re: For those who care about their packages in Ubuntu
Reinhard Tartler <[EMAIL PROTECTED]> writes: > On 1/18/06, Bill Allombert <[EMAIL PROTECTED]> wrote: >> > As pointed out several times, the source package in the ubuntu archive >> > is NOT different to the source package in the debian archive. The >> > binary package have been rebuilt in an different environment, which >> > can caus different dependencies on the resulting binary package. >> >> Yes, this is the definition of a no changes rebuild-only upload. >> >> What I asked was precisely that such upload should be versionned >> nevertheless. Debian version binNMU even while there is no source >> changes. > > Oh. There might be a misunderstanding: No binary package is taken from > debian, only source packages. This means that EVERY package is being > rebuilt in ubuntu on buildds, including arch: all packages. The output > of apt-cache shows the field 'Origin' to indicate that this is not a > package built on debian systems. > > If I understand your proposal correctly, you propose to introduce > binNMU like versioning on ALL nondiverged packages (again, the source > package is identical!). This seem not feasible because of practical > problems. What exactly are these practical problems? I don't see how Ubuntu had no problem solving the problem of rebuilding *all* Debian packages, but can't automate making some simple changes to the package before the build. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
Josselin Mouette <[EMAIL PROTECTED]> writes: > Le mercredi 04 janvier 2006 à 14:21 +0100, Marco d'Itri a écrit : >> On Jan 04, "Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote: >> >> > udev has broken my system -- completely (as in: can't boot and/or log in) >> > -- >> > _seven_ distinct times since this summer. How on you can claim that ALSA is >> > worse, is beyond me :-) >> This was not always caused by udev bugs. >> And anyway, it's called unstable for a reason. udev in stable is stable. > > Unstable means dependencies can be broken, not that packages themselves > can always broken. Each and every single package uploaded to unstable > should be of release quality. Otherwise, it should go to experimental. Dude, how many people do you think would test a udev package in experimental? I could count them on one hand. It's impossible to get a package like udev to be of "release quality" if no one tests it. -- Captain Logic is not steering this tugboat.
Re: bits from the release team
[EMAIL PROTECTED] (Marco d'Itri) writes: > On Jan 04, Adam Heath <[EMAIL PROTECTED]> wrote: > >> Not to mention that 2.6.15 requires a newer udev. Who knows what other newer >> things newer kernels might require. > OTOH, old kernel are buggy and out of date wrt modern hardware, and we > lack the manpower to backport for years fixes and new features RHEL-style. > Do you have a better solution? Why don't we use RHEL's kernel, or collaborate with them to maintain a stable kernel tree, or something? -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Anthony Towns writes: > On Fri, Dec 09, 2005 at 04:27:10PM +0100, Michael Banck wrote: >> On Thu, Dec 08, 2005 at 04:52:31PM -0500, Nathanael Nerode wrote: >> > >I also see the keyring's been updated earlier this week, including >> > >both a replacement key for Horms from late last month, and Chip's >> > >requested updates. >> > Indeed, complaining on debian-devel appears to get results, doesn't >> > it? At least, that's the conclusion that a rational outside observer >> > would come to. >> Where should I best complain for your NM application to be cancelled? > > You can direct concerns about candidates to [EMAIL PROTECTED], which > will be taken into account when the AM's report is being evaluated. I > presume it takes quite a few comments from different developers before > those would override the AM's recommendation though. > > Positive comments can also be sent there (as an additional "advocate" > round, I guess), and are AIUI particularly appreciated, since that gives > more support to accepting a candidate, which is, after all, what almost > always happens at that point. For applicants that are not in the DAM queue (e.g. haven't been approved by their AM), please send the comments to the AM (and maybe front desk) instead. These comments should then be included in the report submitted by the AM. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Thiemo Seufer <[EMAIL PROTECTED]> writes: > while preparing an upload of gcc-2.95 which fixes its worst problems > I wondered how many users of it are actually left. 9 packages in > unstable still declare a build dependency on gcc-2.95 or g++-2.95, > this makes it IMHO a plausible release goal to get rid of 2.95 > maintenance for etch. The most recent LJ notes that Adrian Bunk tried to push a patch in the kernel to remove support for older compilers, but was met with resistance from people that still use GCC 2.95. Apparently, these people prefer it for development due to its significantly faster compilation times compared to v3 and higher versions. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Licenses for DebConf6
Rich Walker <[EMAIL PROTECTED]> writes: > Brian Nelson <[EMAIL PROTECTED]> writes: > >> Andreas Schuldei <[EMAIL PROTECTED]> writes: >> >>> * Rich Walker <[EMAIL PROTECTED]> [2005-11-14 18:46:50]: >>>> Hold on - does this mean I will or won't be able to do >>>> apt-get install debconf6-doc >>> >>> you will, and most likely it will be 100% complete. if someone >>> packages it. >> >> Uhhh, why would something like that be packaged? Just put it on >> http://www.debconf.org or something. Don't bloat the archive with more >> crap like this. > > And the rest of the documentation? What use is the Maintainers Guide to > a user? It's relevant because it's about creating packages. A dump of all stuff from Debconf is not going to be as relevant or as generally useful. Anything from Debconf that could be useful should be merged into the Developer's Reference or something; not just dumped into a separate package. > Why would you need the Linux Gazette in the archives? We don't! It's freaking useless. > I see games there too - purge them, quick! WTF? -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Licenses for DebConf6
Andreas Schuldei <[EMAIL PROTECTED]> writes: > * Rich Walker <[EMAIL PROTECTED]> [2005-11-14 18:46:50]: >> Hold on - does this mean I will or won't be able to do >> apt-get install debconf6-doc > > you will, and most likely it will be 100% complete. if someone > packages it. Uhhh, why would something like that be packaged? Just put it on http://www.debconf.org or something. Don't bloat the archive with more crap like this. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnome-swallow_1.2-2_source.changes REJECTED
Joerg Jaspert <[EMAIL PROTECTED]> writes: > On 10469 March 1977, Josselin Mouette wrote: > >>> Rejected: source only uploads are not supported. >> I can't see the rationale for rejecting source uploads, and they used to >> be accepted in the past. > > Because people then fuck up their packages even more. > > No, they havent been accepted in the past. Ubuntu does that, Debian not. Oh, so Ubuntu packages are fucked up more by their maintainers more than Debian packages are? -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Benjamin Mesing <[EMAIL PROTECTED]> writes: > Hello > > >> assume that an update to a package brings in a changed conffile, and >> because the local admin had changed the conffile, he is asked, and he >> refuses to accept the changed version. > This brings up an issue that is bothering me as a user since a long > time. Whenever I change a config file, I have to take care and examine > changes of the config file in its pacakge. Because most times those > provide some enhancments (e.g. commented out proposals for new options > available), mostly it is a good idea to merge the changes into my own > config. Currently I have to do this merge by hand. However it would be > much smarter to have an option [M]erge when configuring, allowing to > merge the changes into the the local config file [1]. (Of course there > should be also something like: "preview merge" and "preview diff merge > with current config"). > I know this is a little bit tricky, because it requires the old versions > of the config files to be available, and therefore requires a change in > the package system (keeping the old config files in a seperate location > e.g. /var/etc.orig/). > > Now I have two questions: Is such a feature generally desirable? Is > there someone willing to give it some thought and implement it (I am > currently short in time) or should I file a wishlist bug against dpkg? #32877 #48717 #120152 #189805 #247336 #268154 #290854 #294073 6 years and 271 days old. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#335790: O: sysv-rc-conf -- SysV init runlevel configuration tool for the terminal
Joerg Jaspert <[EMAIL PROTECTED]> writes: > Orphaning this package now - the maintainer has no time to work on it > and agreed to the orphaning. If you want it: Fix the bugs, change > maintainer, upload a new version. Note that the previous maintainer was also upstream for the package... -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wnpp situation
Alexander Schmehl <[EMAIL PROTECTED]> writes: > Hi! > > * Brian Nelson <[EMAIL PROTECTED]> [050913 02:46]: > [ long RFPs ] >> Or don't even open RFP bugs in the first place because they're >> thoroughly useless? > > Do you have a proposal for a better way on how our users can request / > suggest software to be packaged? Considering Debian already seems to have virtually everything in the free software universe, I don't see much of a need to support user requests at all. Given the size of the developer population, if there is something out there that hasn't been packaged yet, and it's even remotely interesting, it will be packaged soon. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wnpp situation
Andrew Pollock <[EMAIL PROTECTED]> writes: > On Tue, Sep 13, 2005 at 12:47:33AM +0200, Nico Golde wrote: >> Hi, >> If you go through the list of wnpp bugs you will see alot of >> open bugs which are very very old. >> Especially the RFPs. What about closing an RFP bug >> automatically after the third semi automatic notice mail >> which is sent to the BTS entry? > > Or have a cron job that automatically closes them after a period of > inactivity? With or without three automatic nags? Or don't even open RFP bugs in the first place because they're thoroughly useless? -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#326173: RFH: php-pspell
On Fri, Sep 02, 2005 at 07:32:57AM +, OndÅ?ej SurÃœ wrote: > there was three request to enable *spell extensions in php4/5 packages. > Currently nobody from PHP maintainers team wants to add more burden on > his shoulders, hence I request help from our fellow debian developers > to package pspell and aspell extensions as separate packages using > php4-dev and php5-dev. It should be easy to do so. If you want to help > please contact us on [EMAIL PROTECTED] mailling list. > (Even sponsored packages would be welcomed). AFAIK, the php aspell extension requires a ridiculously old version of aspell, so it doesn't make sense to package it at all... -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shouldn't I use update-alternatives for this?
On Thu, Aug 11, 2005 at 05:28:48PM +0200, Steinar H. Gunderson wrote: > On Thu, Aug 11, 2005 at 09:20:23AM -0600, Sebastian Kuzminsky wrote: > > Qingning Huo suggested using diversions to make /usr/bin/git a little > > selector script that lets the admin & user choose between git-the-shell > > and git-the-scm. This sounds good to me, who objects? > > What are you going to do about automated scripts that use either? Uhhh, why the hell would users of "GNU Interactive Tools" use them non-interactively? -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT: Bruce Perens spamming -devel?
Anders Breindahl <[EMAIL PROTECTED]> writes: > On Wednesday 03 August 2005 02:16, Steve > Langasek wrote: >> On Tue, Aug 02, 2005 at 06:32:44PM -0500, Adam Heath wrote: >> > Unsolicited Commercial Email. Please pay the standard $2000 fee for >> > advertisments on Debian mailing lists. >> Y'know, it's fine if you think that Bruce's mail was inappropriate for > the list, and there's nothing wrong with saying so; but claiming that a > message that isn't selling anything is UCE, and attempting to enforce >> against > a member of the community an advertising policy that daily goes > unenforced against thousands of more deserving souls, just makes you >> sound like > an asshole and an idiot. > > How does an asshole sound, anyway? It sounds like, "Pffftthhhbbb", "Grrrhhhfff", or sometimes even, "Fwp!" -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
"Martin v. Löwis" <[EMAIL PROTECTED]> writes: > Brian Nelson wrote: >> OK, very well then, I'll undo the GCC 4 transition for libaspell15. > > Isn't there still a binary-compatibility issue here? I thought that > in an application, there must only be one version of libstdc++, > directly or indirectly. Otherwise, during runtime, symbols may resolve > from the "wrong" libstdc++, causing crashes. > > So if libaspell is linked with libstdc++.so.6, and some application > links to both libaspell (through the C API), and libstdc++.so.5 (because > it is a C++ application), this application may crash, as it might pick > up symbol definitions from libstdc++.so.6 - or libaspell might crash > as it picks up some symbols from libstdc++.so.5, and some from > libstdc++.so.6. AFAIK, libstdc++ uses versioned symbols to prevent these problems... -- Society is never going to make any progress until we all learn to pretend to like each other.
Re: aspell upgrade woes
Steve Langasek <[EMAIL PROTECTED]> writes: > On Tue, Jul 19, 2005 at 11:52:51PM -0700, Brian Nelson wrote: >> Reintroducing the libaspell15 could cause problems with > /usr/bin/aspell, >> since it actually goes outside the C API of libaspell and uses C++ >> linkage to some symbols. I "fixed" this bug (#307481) by making >> aspell-bin (or now just aspell) depend on the Source-Version of >> libaspell. > >> However, that fix is not in the stable package of aspell. In stable, >> aspell-bin just depends on libaspell15 (>= 0.60), so a partial upgrade >> of just libaspell15 would break aspell-bin. I suppose I could make > the >> new libaspell15 conflict with the old aspell-bin, but that's rather >> clumsy and could make upgrades even more awkward. > >> I'm not sure what the best thing to do would be. I'm sort of inclined >> to just stick with the transitioned libaspell15c2... > > Well, using libaspell15c2 will definitely cause some complexity on the > upgrade path from sarge to etch. I don't know how much having > libaspell15 > conflict with aspell-bin (<< $version) would do so. I suspect that it > would be substantially less since there are only four packages in sarge > which depend directly on aspell-bin or aspell, vs. 61 packages which > depend > on libaspell15 -- at a minimum, the worst-case scenario when conflicting > with aspell-bin (<< $version) looks substantially better. OK, very well then, I'll undo the GCC 4 transition for libaspell15. BTW, does anyone familiar with gettext want to send me a patch for RC bug #31? Upstream said he plans to make a new release with an upgrade to gettext 0.14.5 sometime this week, but I haven't heard anything else from him. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
On Wed, Jul 20, 2005 at 09:52:13AM +0200, Goswin von Brederlow wrote: > Brian Nelson <[EMAIL PROTECTED]> writes: > > However, that fix is not in the stable package of aspell. In stable, > > aspell-bin just depends on libaspell15 (>= 0.60), so a partial upgrade > > of just libaspell15 would break aspell-bin. I suppose I could make the > > new libaspell15 conflict with the old aspell-bin, but that's rather > > clumsy and could make upgrades even more awkward. > > Why? This is exactly what a versioned conflict is for. The packages > have to be upgraded as pair and apt/dpkg will hapily do that. Policy does not recommend it: A Conflicts entry should almost never have an "earlier than" version clause. This would prevent dpkg from upgrading or installing the package which declared such a conflict until the upgrade or removal of the conflicted-with package had been completed. > Having libaspell15c2 conflict libaspell15 makes it no easier than > having libaspell15 conflict the old aspell-bin. Well, libaspell15c2 conflicts/replaces with libaspell15, which dpkg may handle differently than a pure conflicts. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
Steve Langasek <[EMAIL PROTECTED]> writes: > On Tue, Jul 19, 2005 at 09:39:23PM -0700, Brian Nelson wrote: >> It's a C++ library and the ABI changed due to being compiled with GCC >> 4.0. > >> [Actually, although it's written in C++, AFAIK it only exports a C >> interface so the transition may not have been necessary. I only >> realized this yesterday though and I'm not entirely sure a >> non-transition would be safe.] > > Heh. I've just confirmed this... > > As with libGLU, libaspell is used in enough places that there's a > definite benefit to not breaking package compatibility unnecessarily. > Since libaspell15c2's shlibs refer to "libaspell15c2 (>= 0.60)", the > only way to provide full compatibility is with two real packages. I > would suggest restoring libaspell15, and creating a dummy > libaspell15c2 package that depends on libaspell15 and can be dropped > once everything has been rebuilt to use libaspell15 again; that would > minimize the disruption caused by the flip-flopping of the lib name. > > Brian, if you agree, I'm happy to prepare a patch. Reintroducing the libaspell15 could cause problems with /usr/bin/aspell, since it actually goes outside the C API of libaspell and uses C++ linkage to some symbols. I "fixed" this bug (#307481) by making aspell-bin (or now just aspell) depend on the Source-Version of libaspell. However, that fix is not in the stable package of aspell. In stable, aspell-bin just depends on libaspell15 (>= 0.60), so a partial upgrade of just libaspell15 would break aspell-bin. I suppose I could make the new libaspell15 conflict with the old aspell-bin, but that's rather clumsy and could make upgrades even more awkward. I'm not sure what the best thing to do would be. I'm sort of inclined to just stick with the transitioned libaspell15c2... -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BTS version tracking
Colin Watson <[EMAIL PROTECTED]> writes: [...] > The 'reopen' command takes an optional submitter argument, so it was > difficult to get a version in here unambiguously. Instead, we've > introduced a new 'found' command, which says "I've found the bug in this > version of the package". You can use this whether the bug is open or > closed; if the bug's closed and you give a version more recent than the > last recorded fixed version, the bug will be considered open again. > > found 1234567 1.3-2 Shouldn't that be, "you give a version more recent than *or equal to* the last recorded fixed version..."? What if the maintainer uploads a version, say 1.3-2 (which is still the most recent version), which supposedly fixes bug 1234567. However, I test it and find that it's actually not fixed. Presumably, I would do: found 1234567 1.3-2 However, since 1.3-2 is equal to the current version, the BTS would erroneously think that the bug is fixed. That does seem to match reality: http://bugs.debian.org/316089 -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Brian Nelson <[EMAIL PROTECTED]> writes: > >> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: >> >>> So aspell changed the library name to libaspell15c2, which breaks all >>> the existing packages that use libaspell. >>> >>> Was this really an ABI change in libaspell? If not, there was no >>> reason to make the change as I understand it. Were high-severity > bugs >>> filed on all the packages that depend on the library, requesting >>> recompiles? >>> >>> My understanding was that this upgrade would *not* normally change >>> library package names, so I'm wondering why this one did. The aspell >>> changelog doesn't contain anything illuminating. >> >> Uhh... >> >> aspell (0.60.3-2) unstable; urgency=low >> >> * debian/control: renamed libaspell15 to libaspell15c2 for the GCC 4.0 >> ABI change transition > > So, to repeat, since apparently my questions were not clear enough: > > 1: Was there an ABI change in libaspell15 itself? (In the > *programming* *source-level* interface?) Which functions interfaces > changed, and why were the changes not noted in the changelog? Uh... no... http://lists.debian.org/debian-devel-announce/2005/07/msg1.html It's a C++ library and the ABI changed due to being compiled with GCC 4.0. [Actually, although it's written in C++, AFAIK it only exports a C interface so the transition may not have been necessary. I only realized this yesterday though and I'm not entirely sure a non-transition would be safe.] > 2: Were high severity bugs filed on all the packages that depend on > the library, requesting recompiles? Not yet, presumably because a huge portion of unstable needs to undergo the transition anyway. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > So aspell changed the library name to libaspell15c2, which breaks all > the existing packages that use libaspell. > > Was this really an ABI change in libaspell? If not, there was no > reason to make the change as I understand it. Were high-severity bugs > filed on all the packages that depend on the library, requesting > recompiles? > > My understanding was that this upgrade would *not* normally change > library package names, so I'm wondering why this one did. The aspell > changelog doesn't contain anything illuminating. Uhh... aspell (0.60.3-2) unstable; urgency=low * debian/control: renamed libaspell15 to libaspell15c2 for the GCC 4.0 ABI change transition -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: aspell dictionary packages fail to build
On Thu, Jul 14, 2005 at 04:34:05PM -0700, Matt Kraai wrote: > Howdy, > > The aspell dictionary packages build-depend on aspell-bin (>> 0.60). > aspell-bin is now a virtual package provided by aspell, but virtual > packages cannot be versioned, so these build-dependency cannot be > satisfied. > > There are fifteen such packages: Actually, it's worse than that. Almost every aspell dictionary package is broken right now. [...] > Should I file bugs against each of these packages? Should I contact > the maintainers directly via email? Should I email d-d-a? Normally, I would have contacted the maintainers beforehand about the breakage. However, Agustin and I are currently finalizing support for building the dictionary hashes at install time. Once that's ready, the plan is to transition all of the dictionary packages to use the hash building sytem. You may start filing bugs against each of aspell dictionaries (minus aspell-en, aspell-es, and possibly a couple others) if you'd like, but I suggest that the maintainers wait to fix the bugs until Agustin and I have written a dictionary transition document. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dummy packages and "Replaces:" field
On Thu, Jun 23, 2005 at 12:02:44PM -0400, Roberto C. Sanchez wrote: > On Thu, Jun 23, 2005 at 12:38:34PM -0300, Margarita Manterola wrote: > > On 6/23/05, Roberto C. Sanchez <[EMAIL PROTECTED]> wrote: > > > OK. How would I make use of this. I was going to adopt iceme and > > > icepref, but then I saw that they are abandoned upstream. They have > > > become modules of IceWMCP. I am going to package IceWMCP with the > > > intent that it replace iceme and icepref. > > > > > > Someone recommended that I use dummy packages of iceme and icepref that > > > depend on icewmcp. But, if I also make icewmcp Replace and Conflict > > > with iceme and icepref, will that not cause problems (since the new > > > dummy versions of iceme and icepref will depend on icewmpc)? > > > > Well, of course, you cannot adopt both methods. Either you use the > > dummy package method or you use the Replace and Conflict method. > > Right. However, what I would like is to be able to do it *without* > using dummy packages. I think that what I want is not possible without > dummy packages. That is where I see a problem. The current > Replaces/Conflicts mechanism doesn't handle it all well. It's not designed nor intended to do what dummy packages do. It's meant to be used in cases where two packages don't coexist, so installing one automatically removes the other. > I agree a change that makes it work more elegantly would be nice. Not to the Replaces/Conflicts behavior. You must introduce a new field--see #33344 or #77325. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mail clients and threading... (was: Re: And now for something completely different... etch!)
On Tue, Jun 14, 2005 at 08:06:07PM +0200, Adrian von Bidder wrote: > On Tuesday 14 June 2005 19.14, Humberto Massa Guimarães wrote: > [...] > > Hmmm. Is it just my kmail, or does your mailer produce strange (or no?) > In-Reply-To headers? It's not just you. > All your posts I saw (and none others afaict) appeared to be in reply > to some completely irrelevant other message in the same thread - it's > extremely annoying to read your postings that way. X-Mailer: Internet Mail Service (5.5.2653.19) Idiotic MS junk, I believe... -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Outrageous Maintainer
On Sun, May 01, 2005 at 09:56:42AM +0200, Wouter Verhelst wrote: > On Sat, Apr 30, 2005 at 10:04:35PM +0200, Goswin von Brederlow wrote: > > A Replaces without a Conflicts is I think always wrong. > > No, absolutely not. See policy, section 7.5, for details -- especially > section 7.5.1. Policy is buggy since it doesn't match the current practice of dpkg (which is itself buggy--#164595, #184635, #277890). -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#306694: ITP: qt-x11-opensource -- Qt 4 cross-platform C++ application framework
On Wed, Apr 27, 2005 at 11:10:44PM -0500, Peter Samuelson wrote: > > [Brian Nelson] > > * Package name: qt-x11-opensource > > Version : 4.0 beta 2 > > Upstream Author : Trolltech AS > > Is there some reason for the "-opensource" in the name? It's the upstream name. For whatever reason, Trolltech has chosen different names for each major release: Qt1: qt Qt2: qt-x11 Qt3: qt-x11-free Qt4: qt-x11-opensource Qt5 will probably be qt-x11-foss or qt-x11-freeasinspeech or something equally annoying. > That's a pretty redundant designation for something in Debian main, > don't you think? I'd probably go with "qt4" or "libqt4" or "qt4-x11" > for the source package name. I was thinking about naming it qt4-x11, but I'm not sure it's worth deviating from upstream. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306694: ITP: qt-x11-opensource -- Qt 4 cross-platform C++ application framework
Package: wnpp Severity: wishlist * Package name: qt-x11-opensource Version : 4.0 beta 2 Upstream Author : Trolltech AS * URL or Web page : http://www.trolltech.com * License : Dual GPL/QPL Description : Qt 4 cross-platform C++ application framework Qt is a cross-platform C++ application framework. Qt's primary feature is its rich set of widgets that provide standard GUI functionality. Qt 4 is the next major revision of Qt, currently planned for a late Q2 release. Preliminary packaging is available here: http://people.debian.org/~pyro/experimental/ I would like to group-maintain this package and have set the maintainer to "Debian Qt/KDE Maintainers " in the preliminary packages. Please let me know if this is inappropriate for whatever reason. I plan to maintain the packaging in a distributed version control system, once I figure out which of the 20 or so is the most practical. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Key Signing in Vancouver, BC
On Tue, Apr 26, 2005 at 04:53:05PM -0700, [EMAIL PROTECTED] wrote: > Hey! Shaun Jackman generously offered to meet in New Westminister over > lunch to exchange gpg signatures > > Meeting other debian/linux/open source folks would be totally awesome! If you're willing to cross the border, you could go to the Northwest Linuxfest (http://www.linuxnorthwest.org/) on Saturday in Bellingham. I probably won't go unless it rains, but a few other developers are planning to attend. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What do you win by moving things to non-free?
On Wed, Apr 20, 2005 at 12:03:07AM -0400, Glenn Maynard wrote: > On Wed, Apr 20, 2005 at 05:31:52AM +0200, Adrian Bunk wrote: > > If you really want to retain your "everything is software" point of > > view, think about the consequences and work on them _before_ starting > > the removals - and provide solutions for them that are available at the > > time of the removals. [...] > And Debian has tried to work on reducing the impact, by trying > to convince the FSF to fix their license. Not only have they > not done so, they've completely stonewalled, refusing to discuss > the issue at all. That's completely untrue, actually, though I think that stuff is still confined to debian-private. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#304220: ITP: libqt4lab -- Qt4Lab plugin library
On Mon, Apr 11, 2005 at 09:05:56PM +0200, Fathi BOUDRA wrote: > I'm looking for a sponsor for my qt4lab package. > The project seems already promising, and there's a collaboration > with qwt project. > > You can find my package here : > http://fboudra.free.fr/debian/ > > best regards, > > Fathi > > * Package name: libqt4lab > Version : 0.1.1 > Upstream Author : Paolo Sereno <[EMAIL PROTECTED]> > * URL : http://www.qt4lab.org > * License : LGPL > Description : Qt4Lab plugin library The name kinda sucks since it'll be easily confused with the upcoming Qt4 libraries, though these use Qt3 (for now). Any chance of convincing upstream to use a less confusing name? -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: unixODBC vs. iODBC
On Thu, Mar 31, 2005 at 09:53:57PM +0200, Peter Eisentraut wrote: > Debian currently ships two ODBC driver managers, unixODBC (source > package "unixodbc") and iODBC (source package "libiodbc2"). These > basically do the same thing. Every package that wants to provide > database access through ODBC has to pick at build time which driver > manager to use. That in turn forces the user to set up each ODBC > drivers twice, once for each driver manager. This process must seem > pretty arbitary from the user's point of view. [...] > I'm not attached to either camp, but here are some data points: > > - Currently 18 packages use unixODBC, 11 use iODBC. > > - Both myodbc (MySQL ODBC driver) and psqlodbc (PostgreSQL ODBC driver) > build against unixODBC. > > - unixODBC comes with a buch of GUI tools, iODBC does not. > > - Both are still developed upstream. > > - libiodbc2 has been RFA'd by the current maintainer for over a year. > > - The lastest PostgreSQL ODBC driver fails to build with iODBC. > > Well, you can guess what my pick is. Other comments? Qt in Debian must build against libiodbc2-dev because otherwise it would have a circular build-dependency with unixodbc. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Marc Haber <[EMAIL PROTECTED]> writes: > On Tue, 15 Mar 2005 23:15:46 +0100, Romain Francoise > <[EMAIL PROTECTED]> wrote: >>Brian Nelson <[EMAIL PROTECTED]> writes: >>> Can we *please* ban Ingo from d-d? He's been a huge pain in the ass on >>> this list for months now, has absolutely nothing constructive to >>> contribute, and is actively trying to subvert the project. >> >>For what it's worth, I second this request. > > Since we're about Free Speech, kindly use your kill file. Banning > people from the mailing list is not doing the project any favour. Funny. I thought we were about creating a free operating system; not about providing a soap box for any random idiot to stand on. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tue, Mar 15, 2005 at 10:26:58PM +0100, Ola Lundqvist wrote: > Hello > > As most people in this threas have expressed lot of bad feelings about > this. I must tell that I think this proposal is a good step toward > quicker releases etc. > > With the clarifications (see the new thread) I must say that this > is a very sane proposal. > > Some people tend to think the worst of everything. If you look at this > proposal as a proposal and with the intention to make things working > in a good way, I think this proposal is one of the best ones in a > very long time. I agree. It's become quite evident that Debian is barely able to make releases at all with the status quo. And, given a choice between having no stable releases at all and having stable releases of a significantly reduced number of arches, I'd gladly choose the latter. What baffles me is why so many seem to miss this point and instead have decided to turn it into a religious flame war. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Can we *please* ban Ingo from d-d? He's been a huge pain in the ass on this list for months now, has absolutely nothing constructive to contribute, and is actively trying to subvert the project. On Tue, Mar 15, 2005 at 09:09:47PM +0100, Ingo Juergensmann wrote: > On Tue, Mar 15, 2005 at 07:34:16PM +, Matthew Garrett wrote: > > > > Again, without a proper communication there's no chance of cooperation. > > > Otherwise those kinds of "I've heard that you've done..."-stories would > > > have > > > happen again and again... > > Ingo, stop being such a cock. Even if you'd found James assaulting your > > Please stop to call me that way. > > > dog with a cucumber, you'd be overreacting. Your repeated outbursts > > actively hinder other developers. If you're not going to contribute > > anything useful, then kindly fuck off and improve the signal to noise > > ratio. > > Your wording is not on a level I would expect from a DD. > > > Please note the mail-followup-to in replies. This discussion doesn't > > belong on this list. > > Ignored. I think different and when you believe something doesn't belong on > the list then mail me privately and not that "I tell him to fuck off > publicly, but I don't want him to defend himself in the public"-game. > > Childish. When you want to stop my rants, fix your internal project > problems. Dropping archs doesn't help either. > > -- > Ciao... // > Ingo \X/ > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Security support for tier-2
On Tue, Mar 15, 2005 at 06:37:22PM +0100, Matthias Urlichs wrote: > Hi, Henning Makholm wrote: > > >> Nothing's going to prevent porters from adding stable-security (or > >> whatever) to their autobuilders, > > > > True - for as long as they do not try to upload the result to the > > Debian archive, which will carry only "unstable". > > I do not consider this to be set in stone. > > The people who were at the meeting agreed on some things. Not everybody > who has a stake, or even is responsible for the current support of $ARCH > in Debian, was at the meeting. Therefore the result of the meeting is in > no way binding on anybody. (This is regardless of the fact that the people > responsible for it *did* say that the proposal is ... well, exactly that.) Uh, the ftp-masters are responsible for maintaining the archive, and the release team is responsible for managing releases. If they come to a conclusion that it's impossible to make timely releases and keep all of these architectures in a single archive, then that's their decision to make. If I were in one of those rolls, I know I'd be pretty upset if I made a decision and then a bunch of people started ranting and raving about it and said I had no power to make that decision. It would make me wonder why the hell I'm in that roll anyway. And I'd probably quit out of frustration. > Otherwise, we would be leaving Debian en masse, instead of discussing the > Vancouver paper. By all means. If you care enough about a particular SSC arch, go create your own stable releases on it based on the official Debian release. That's exactly what the "proposal" is about. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Proposal] Upgrade newraff hardware
On Tue, Mar 15, 2005 at 11:05:13AM +0100, Bill Allombert wrote: > Hello Debian developers, > > It had come several times that one major problem is the load of > wanna-build connection on newraff, and the time and memory it take > to run the testing scripts. > > Debian certainly has enough goodwill to get a donation of a couple of > really fast box with lots of RAM, and has enough money to buy them > anyway. Especially a box with SSL exchange hardware support could be > useful. Sounds like it's already quite powerful: Processor: Dual Intel P4 Xeon 2.8Ghz Memory: 6Gb Disk space: 735Gb [6x147Gb RAID 5] Bandwidth: 100Mbit colocated LAN -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
"Thaddeus H. Black" <[EMAIL PROTECTED]> writes: > [Not private. Reply on-list if you wish.] > >> However, I do think that not including amd64 (while keeping mips and >> friends) in the sarge release due to mirroring problems is ridiculous. > > Amen, brother. > >> ... packages are uploaded too frequently, ... > > How often is probably too often, in your view? (This is just a > question. I happen to keep a package which uploads irregularly ten or > fifteen times per year.) Short answer: As long as your package is a candidate for testing (and you feel is generally fit for testing) but is being blocked by something else, you should probably wait to upload until the current version makes it into testing. How often is that? Well... Consider package 'foo', which has either a direct or indirect relationship with 50 other packages in Debian (it depends directly on a few packages, those packages depend on other stuff, and some packages depend directly on foo, etc.). And say it's being blocked from testing because some package in there is broken. How do you get all of these into testing? You have to fix the broken package, and have all of the interrelated packages become simultaneously eligible for inclusion in testing. Since there's a constant churn of packages in unstable, probably someone will upload some package in chain, which means all of the others will have to wait for it. Or someone uploads a new upstream release, which turns out to be too buggy. Then all of the packages have to wait for that one to get fixed. In general, it would probably work best for testing if an upload turns out to be free of RC bugs that the maintainer doesn't touch it for a couple months. Of course, we're all volunteers and maybe in a couple of months the maintainer won't have time to do another upload. But he or she has time now, so why not just do it now? And, without any kind of established release timeframe, maintainers don't generally know if it's best to wait on an upload or just do it right away. For example, if a maintainer decides it's best to wait until the next release to make a big packaging change because the release appears to be near, more than likely that maintainer will be sitting on their hands for 6 months before they finally realize, hey, we're not actually going to release soon. So they make the upload, break some stuff, and generally push back the release even more. I don't think overly frequent uploads are the real problem. I think the more significant problems are: 1. Package dependencies are too complicated and interrelated. 2. Library shlibs are too tight. 3. The overall discontent with our releases taking too long make some of the general developer population disinterested with the release, and thus don't take proper care to ensure their packages are entering and working in testing. The newer libtool versions are definitely helping with (1), though only to an extent. Modern software is just getting very complicated and is using lots of libraries. Unless we throw out things like GNOME and KDE, there's really no way around it. (2) is definitely something that needs work. It seems like every library package out there is just using 'dh_makeshlibs -V', and that's unfortunate since the dependencies produced are in most cases overly tight. As for (3), well, that's been a known problem for years and no RM has yet figured out how to motivate the troops. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: > Brian Nelson debian.org> writes: >> And for the more obscure architectures, virtually all of the testing >> comes from the build of the package. How many people out there are >> actually using e.g. KDE on mips enough to actually find any portability >> bugs? > > That is an important point, and nobody else really picked it up. Almost all > other contributors to this thread engaged in attempts to stifle the debate > and claim "that the parrot wasn't dead, but resting". > > But to the best of my knowledge, Marco's (blog) post from a few months > ago which showed download from ftp.it.debian.org by architecture stands > undisputed: essentially all users are on i386 clearly dominating all other > arches, with a fraction of users in maybe two, three, four other arches --- > and comparitively nobody in the other fringe arches we keep around for no > good reason. As long as the fringe architectures are not slowing down releases, and the mirrors have the bandwidth and disk space for them, I don't have a problem keeping them around. I have yet to see anyone give a compelling reason to keep them, but if they aren't hurting anyone, who cares? However, I do think that not including amd64 (while keeping mips and friends) in the sarge release due to mirroring problems is ridiculous. > And I still believe it delays our releases. As you say, there are no > KDE users on mips. So guys, we need a new framework. It's not clear to me how much supporting all of these arches delays our releases. I believe that some delay is inherent, but I'm skeptical whether it's significant compared to other sources of delay. I don't recall ever hearing a RM state that supporting all of these arches was slowing down the release cycle. And I think that's significant. The real problem seems to me, aside from the mysterious difficulties of setting up testing-security and t-p-u, seems to be that it's very hard to consistently keep the flow of packages into testing. There are too many inter-dependencies, packages are uploaded too frequently, and bugs appear at too great of a rate. Or at least that's my impression as an outside observer. Portability and buildd problems undoubtedly play a role in there, but I suspect it's a relatively minor role. Can someone more involved in the release process confirm or deny this? -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
Goswin von Brederlow <[EMAIL PROTECTED]> writes: > John Hasler <[EMAIL PROTECTED]> writes: > >> Brian Nelson writes: >>> That's an overstatement. Simply having two architectures (i386 and ppc) >>> would be enough to reveal nearly all portability bugs. >> >> It required several architectures to uncover all of the portability bugs in >> Chrony. ppc was not one of them. >> -- >> John Hasler > > What no signed/unsigned char portability bugs? I did see one before that only manifested itself on arm: http://bugs.debian.org/191992 Not sure why arm would be the only one though... -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
Jim Gettys <[EMAIL PROTECTED]> writes: > On Mon, 2005-02-21 at 11:13 -0800, Brian Nelson wrote: >> On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote: >> > On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: >> > > But a total of eleven is insane. >> > >> > It is sometimes hard to get them all to work, yes. >> > >> > It also vastly increases the quality of the Free Software in our >> > archive, as we discover bugs that appear only on one architecture. >> >> That's an overstatement. Simply having two architectures (i386 and ppc) >> would be enough to reveal nearly all portability bugs. >> > > Actually, my long experience is that it takes more than 2; but at, say, > 4 systems (both byte orders, both 32 and 64 bits) you get most of them. Errr, yeah, I was thinking of amd64 as well but forgot to explicitly say so. > More important at that point is getting better compiler coverage; gcc > and friends is *not* the only compiler suite in the world, and different > compilers uncover a different spectrum of bugs. Yeah, definitely. If our goal is making our software as portable and bug-free as possible, we'd be better off running fewer arches but with a greater variety of compilers. Now if there were only any viable free alternatives to GCC... -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote: > On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: > > But a total of eleven is insane. > > It is sometimes hard to get them all to work, yes. > > It also vastly increases the quality of the Free Software in our > archive, as we discover bugs that appear only on one architecture. That's an overstatement. Simply having two architectures (i386 and ppc) would be enough to reveal nearly all portability bugs. And for the more obscure architectures, virtually all of the testing comes from the build of the package. How many people out there are actually using e.g. KDE on mips enough to actually find any portability bugs? -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: > >> Our chances of actually releasing one day could only increase if we >> dropped arches such as mipsel, s390, m68k, ... and concentrated on >> those that actually mattered: i386, powerpc, amd64 -- and I'll >> gladly add a few more. But a total of eleven is insane. > > There isn't any evidence I've seen that these arch's actually slow > down the release. Getting debian-installer working across all architectures was certainly an issue at one time, though that time passed a few months ago. Also, really huge stuff, like KDE, cannot be uploaded as frequently as perhaps the maintainers would like because it kills the slower buildd's for a few days. -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#295430: ITP: cpufrequtils -- Tools to access to the Linux kernel cpufreq subsystem
On Wed, Feb 16, 2005 at 02:24:34PM +0100, Daniel Baumann wrote: > Javier Setoain wrote: > >* Package name: cpufrequtils > > Version : 0.2-pre1 > > Upstream Author : Dominik Brodowski <[EMAIL PROTECTED]> > >* URL : http://www.example.org/ > >* License : GPL > > Description : Tools to access the Linux kernel cpufreq subsystem > > I did a package already since the original holder of the ITP didn't > respond to several pings. Well, you didn't send the mail to the submitter (only to [EMAIL PROTECTED], which doesn't go to the submitter--you need to Cc him manually), so he probably never saw it... -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292479: ITP: kernel-patch-swsusp2 -- software suspend 2 for linux kernel patch
On Thu, Jan 27, 2005 at 10:20:05AM +0100, martin f krafft wrote: > Package: wnpp > Severity: wishlist > > @Bernard, I intend to package swsusp2 for Debian, just letting you > know... > > * Package name: kernel-patch-swsusp2 > Version : 2.1.5.15 > Upstream Author : Bernard Blackham <[EMAIL PROTECTED]> Isn't Nigel Cunningham the primary author? Also, Bernard is in the NM queue, though he's been on hold for quite a while... -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, Jan 06, 2005 at 06:50:59PM -0500, Andres Salomon wrote: > On Thu, 06 Jan 2005 23:15:53 +0100, Christoph Hellwig wrote: > > > On Thu, Jan 06, 2005 at 04:58:56PM -0500, William Ballard wrote: > >> Apparently the dickhead maintainer of ndiswrapper-source has just gone > >> into his shell and refuses to discuss this problem. > > > > Btw, could anyone explain why ndiswrapper is in main? It's only use > > is to run propritary windows drivers inside the linux kernel, so it's > > a clear fit for contrib. > > I believe we had this discussion on IRC; basically, there *are* free > (as in speech) ndis drivers out there. Whether they're able to be built > and packaged on a debian system; I don't know. It's completely irrelevant whether any free drivers exist. ndiswrapper's purpose is to provide an NDIS interface to the Linux kernel, and it accomplishes that purpose without the use of any non-free software. Thus, it is perfectly suitable for main. -- For every sprinkle I find, I shall kill you!
Re: ndiswrapper should be in contrib
On Fri, Jan 07, 2005 at 12:42:07AM +0100, Rene Engelhard wrote: > Package: ndiswrapper > Severity: serious > Tags: sarge, sid > > Hi, > > Christoph Hellwig wrote: > > On Thu, Jan 06, 2005 at 04:58:56PM -0500, William Ballard wrote: > > > Apparently the dickhead maintainer of ndiswrapper-source has just gone > > > into his shell and refuses to discuss this problem. > > > > Btw, could anyone explain why ndiswrapper is in main? It's only use > > is to run propritary windows drivers inside the linux kernel, so it's > > a clear fit for contrib. Since when does usage matter? frozen-bubble's only use is to waste time. My time isn't free, so remove it from main! -- For every sprinkle I find, I shall kill you!
Re: LCC and blobs
Glenn Maynard <[EMAIL PROTECTED]> writes: > On Fri, Dec 17, 2004 at 11:07:31AM -0800, Brian Nelson wrote: >> No, a definition of "software" was never decided upon. The vote was >> about removing the word "software" in certain places from the DFSG, >> regardless of its definition. > > However, the S in DFSG means "software"; the SC was adjusted to say that > everything in Debian is judged by the DFSG, but the DFSG was not renamed > (for example, to mean "Debian Free Stuff Guidelines"). This means, to > me, that everything in Debian is Software. I'd say it's just there by legacy. > It's a moot issue, anyway; any time the dictionary lawyers nitpick > "software", the real point is probably long lost, anyway ... :) Sure, how bout this: It seems to me that if you're saying everything in Debian is software, then your definition of software must be something equivalent to "information stored in a way that can be read by a machine". In that case, you'd certainly agree that the information stored on a punch card is software. And, if a punch card can store software, then certainly a name chiseled into the aforementioned granite could be considered software. After all, it's entirely conceivable a machine could be made to read it--it's not even all that different in concept from a punch card reader. That leads to the conclusion that anything in the universe could be considered software, since even sub-atomic particles store information that could be considered machine-readable. In other words, you've redefined software to mean simply "information". It's entirely inconsistent with the common usage of the term "software", but whatever. Has the real point been lost yet? :) What I'm trying to get at is that software is such a nebulous term that it really has no meaning, so it was just removed from the SC where it caused confusion. Just say Debian is 100% free, not that Debian is 100% free software, so we stop making ourselves look foolish trying to define what exactly "software" is. -- For every sprinkle I find, I shall kill you!
Re: LCC and blobs
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > Peter Van Eynde <[EMAIL PROTECTED]> writes: > >> Brian Thomas Sniffen wrote: >>> Architectural plans for a house, shipped in a Debian package, are >>> software. >> >> I'm stunned. So anything in a Debian package is software. With alien I >> can convert a tar.gz into a debian package, so all tar files are >> software. With tar I can create a tar.gz from any file, so all >> electronic data is software? > > Bingo. Debian had this debate last year. There was a giant vote over > it. Then another debate and another vote. "software" is not > "program". Programs are software that happens to be executable. Data > is not executable, but still software. No, a definition of "software" was never decided upon. The vote was about removing the word "software" in certain places from the DFSG, regardless of its definition. -- For every sprinkle I find, I shall kill you!
Re: LCC and blobs
On Sat, Dec 11, 2004 at 08:02:28PM -0500, Glenn Maynard wrote: > On Sat, Dec 11, 2004 at 04:42:23PM -0800, Brian Nelson wrote: > > Contrib exists for software dependencies. This is not a software > > dependency issue. There is no direct relationship between firmware and > > drivers. > > I don't see how you can say there is no direct relationship between > firmware and drivers, when it's most often the driver that opens the > firmware blob, possibly does some parsing, and uploads it to the device. [...] I was referring to firmware that is loadable in userspace. Firmware like that which you describe, or firmware that is encoded in C files in the kernel source is much more dubious. Due to GPL restrictions, I believe that sort of firmware will all have to be moved to userspace. -- For every sprinkle I find, I shall kill you!
Re: LCC and blobs
On Sat, Dec 11, 2004 at 04:24:16PM -0800, Bruce Perens wrote: > Tim Cutts wrote: > > >If Debian tries to be too rigid, we run a serious risk of consigning > >ourselves to history, because people just won't install Debian any > >more if it doesn't work out-of-the-box on most hardware - and the time > >is pretty much already here that most systems contain at least one > >component that loads firmware from disk every boot. > > > Of course, every time there has been any decision about including a > piece of non-free software in main, we've had this same discussion. It's > important for Debian to stand firm on this issue. If you want to > distribute firmware, it really belongs in FLASH on your device, don't > expect us to distribute it for you. We're not really in any position to say where firmware belongs. For example, there seem to some good reasons for manufacturer's to not store the firmware on the device itself. Flash memory has a finite life, and repeatedly flashing it will eventually wear it out and make the device non-functional. With older devices, it seemed that updating the firmware was rarely needed, so memory lifetime was not a major issue. However, newer devices, especially wifi chipsets, seem to need very frequent firmware updates. Driver updates to the wifi chipset in my laptop have required about 5 new firmware updates in the past year. Flash memory reliability is probably a major concern for the manufacturer of this chipset. That said, it still isn't necessarily our responsibility to distribute firmware. Nonetheless, I believe it is important to make Debian readily installable and usable on hardware that requires this firmware. > Once it's in the device, it's below the demarcation of the bus > programming interface, and thus outside of our domain. I agree. -- For every sprinkle I find, I shall kill you!
Re: LCC and blobs
On Sat, Dec 11, 2004 at 05:49:26PM -0500, Glenn Maynard wrote: > On Sat, Dec 11, 2004 at 02:23:16PM -0800, Brian Nelson wrote: > > While you have your pen and paper out, go ahead and write some hardware > > that a contrib device driver can use without needing firmware loadable > > by the kernel. Put the firmware on the device itself. That contrib > > driver is now completely suitable for main by your definition. > > > > There is no direct relationship between a device driver and a binary > > firmware blob. The driver simply drives a device. It does not and > > should not care how a device gets the firmware loaded. > > If the driver has to be able to open the file and read the blob so it > can send it to the device, there's a clear relationship and dependency > between the driver and the blob: if you don't have a copy of the blob, > the driver doesn't work. (Spewing out "hardware error, firmware not > loaded" doesn't count to me as "working".) > > The difference is simple: if running a device requires that a driver > have access to a piece of data, the user must have access to that > data (and so its copyright restrictions kick in; I might not be allowed > to give it to you, even if the company that made the device no longer > exists). If the device merely stores that software on the device itself, > that isn't the case. > > If the user must be subjected to non-free restrictions to use a piece > of software (such as a driver), it belongs in contrib; that's what > contrib was created for. > > (The fact that this is a result of hardware implementation decisions > is irrelevant.) Fundamentally, I think it comes down to this: we have to draw the line somewhere, and that line has always been drawn at the software/hardware boundary. Neither the Linux kernel nor Debian have ever considered the "freeness" of hardware an issue. We don't care if the hardware's BIOS and firmware is free software. We distribute an operating system that users may use on any hardware they like. Firmware, although itself software, is fundamental to the hardware. Whether a device has firmware or not is traditionally an area we have not stuck our noses into. We have never cared before about hardware implementation decisions, and see no reason to start caring now. So, some hardware requires the firmware to be loaded by some method external to the device. So what? We have absolutely no obligation to distribute and load the firmware--ultimately it's the manufacturer's problem. We may choose to do so and we may not. It still doesn't change the fact that we don't care about hardware implementations. Contrib exists for software dependencies. This is not a software dependency issue. There is no direct relationship between firmware and drivers. -- For every sprinkle I find, I shall kill you!
Re: LCC and blobs
On Sat, Dec 11, 2004 at 03:36:07PM -0800, Thomas Bushnell BSG wrote: > Tim Cutts <[EMAIL PROTECTED]> writes: > > > I don't think it's the case today, but I think that it will be soon. > > It's the way the world is going. > > Especially if we and others just give in and say "ok, that's fine." Actually, I think it's a step in the right direction for "free" hardware. By moving firmware off the device and into the operating system, we inherently gain more control over it. In the near future, firmware will likely remain as a binary blob with a restrictive license. However, in the longer term, we may very well be able to convince hardware manufacturers to make the firmware free by our terms. In any case, it's not exactly hurting anyone. Users certainly aren't losing any freedom. -- For every sprinkle I find, I shall kill you!
Re: LCC and blobs
Goswin von Brederlow <[EMAIL PROTECTED]> writes: > Brian Nelson <[EMAIL PROTECTED]> writes: > >> On Sat, Dec 11, 2004 at 03:07:56PM +0100, Goswin von Brederlow wrote: >>> Brian Nelson <[EMAIL PROTECTED]> writes: >>> > As far as I'm concerned, distribution of the firmware is the >>> > manufacturer's realm. Whether the manufacturer distributes it on an >>> > EPROM on the device itself, or on a CD shipped with the device, or just >>> > provides it for download from a website, I don't care. That's their >>> > decision. Debian should not care one bit how the firmware is loaded on >>> > the device, and the method used should not dictate whether a driver is >>> > DFSG-compliant. >>> >>> It doesn't. What matters is if the firmware itself is distributable at >>> all and if it is DFSG-compliant. >> >> You aren't reading what I've written. Virtually 100% of firmware >> out there (included on the device or loaded externally) is non-free. By >> your reasoning, the entire kernel should be moved to contrib since no >> free hardware exists on which it can run. > > Sure it runs on free hardware. On 100% free hardware. Take a pen, a > paper and the boch source code and run your own linux on the pen+paper > system. :) > > Ok, it's a bit insane, but possible. While you have your pen and paper out, go ahead and write some hardware that a contrib device driver can use without needing firmware loadable by the kernel. Put the firmware on the device itself. That contrib driver is now completely suitable for main by your definition. There is no direct relationship between a device driver and a binary firmware blob. The driver simply drives a device. It does not and should not care how a device gets the firmware loaded. That the currently available hardware requires firmware loaded by the kernel is a hardware implementation detail. If you don't like it, complain to the hardware manufacturer, or buy your hardware from somewhere else. Hardware is not Debian's realm. -- For every sprinkle I find, I shall kill you!
Re: LCC and blobs
On Sat, Dec 11, 2004 at 11:50:44AM -0800, Thomas Bushnell BSG wrote: > Brian Nelson <[EMAIL PROTECTED]> writes: > > > It's a completely inconsistent and arbitrary policy. > > It's hardly that. We distribute only free software, that's our rule. > The rest, as you say, is for the manufacturer and the user to work > out, but we disvalue non-free software, and so we don't distribute it > in main. (And packages which require it go into contrib.) The device drivers in question *are* 100% free software! You say they should go into contrib because they depend on non-free software. However, *all* device drivers depend on non-free software. Why does it matter if that non-free stuff is stored on the device itself or is loaded externally? > You only see it as inconsistent because you think the relevant > consideration is "do we support this hardware", and you don't care how > we support it. I didn't say that. I'm saying we should distribute all free device drivers in main because they are free. Binary blobs are a non-issue. > Most of us *do* care; we support it provided we can do > so without distributing non-free software, because Debian is 100% Free > Software. Things we cannot support with free software we do not > support. This is not an inconsistent policy; this is the core of what > Debian stands for. All hardware depends on non-free software. If you want to lobby for all hardware to be free, including the firmware/BIOS/whatever, then fine. That's a noble war to wage and I'd support your efforts. However, requiring a policy like this at this time is completely insane because no hardware exists that meets this requirement. > To say it is arbitrary is worse, because that insults the motives of > the people who disagree with you. Your motives baffle me, and I can't say I feel any shame in insulting them. -- For every sprinkle I find, I shall kill you!
Re: LCC and blobs
On Sat, Dec 11, 2004 at 08:11:31PM +0100, Josselin Mouette wrote: > Le samedi 11 d?cembre 2004 ? 11:00 -0800, Brian Nelson a ?crit : > > You are the only person I've seen express views similar to mine on > > debian-legal. All other participants argue for non-free-firmware-using > > drivers going in contrib. > > Do they? Judge for yourself: http://lists.debian.org/debian-legal/2004/10/msg00089.html (and others...) > > Also, the current practice already is moving in this direction. For > > example, the ipw2100 driver is in contrib. > > For a single package that won't work without the binary blob, that's a > good policy. It's a completely inconsistent and arbitrary policy. Virtually *all* device drivers in existance require a binary blob to work. It's up to the manufacturer to provide the binary blob to the user when they purchase the device. Some devices have the blob on the hardware itself; for others, the manufactures ship it on CD or make it downloadable from a website. Some manufactures allow us to distribute it; others don't. We should not care what they do. That's up to the manufacturer's and the users of their hardware to work out. > But for a driver that's built within the kernel, this is fucking > stupid. We already have several packages with some features that only > work when some non-free stuff is installed (see e.g. xine). What's > wrong with the kernel having *some* modules needing non-free blobs? > They won't work out of the box, but that's not a reason to exclude > them from the kernel. This is more work for the kernel maintainers, > more work for the users, and no gain. > > In fact, all these drivers (including ipw2x00) should be built with our > kernel, and the binary firmwares that we can ship should be included in > the non-free section. That would be an acceptable though not ideal solution to me. -- For every sprinkle I find, I shall kill you!
Re: LCC and blobs
On Sat, Dec 11, 2004 at 03:07:56PM +0100, Goswin von Brederlow wrote: > Brian Nelson <[EMAIL PROTECTED]> writes: > > As far as I'm concerned, distribution of the firmware is the > > manufacturer's realm. Whether the manufacturer distributes it on an > > EPROM on the device itself, or on a CD shipped with the device, or just > > provides it for download from a website, I don't care. That's their > > decision. Debian should not care one bit how the firmware is loaded on > > the device, and the method used should not dictate whether a driver is > > DFSG-compliant. > > It doesn't. What matters is if the firmware itself is distributable at > all and if it is DFSG-compliant. You aren't reading what I've written. Virtually 100% of firmware out there (included on the device or loaded externally) is non-free. By your reasoning, the entire kernel should be moved to contrib since no free hardware exists on which it can run. I'm not going to discuss this with you if you insist on spewing out typical debian-legal bullshit without actually thinking first. -- For every sprinkle I find, I shall kill you!
Re: LCC and blobs
On Sat, Dec 11, 2004 at 03:49:48PM +0100, Marco d'Itri wrote: > On Dec 11, Brian Nelson <[EMAIL PROTECTED]> wrote: > > > If it made any sense at all for a mainboard's BIOS to loaded by the > > Linux kernel at boot time with a non-free firmware blob, the current > > consensus (on debian-legal anyway) seems to be that Debian would not > > support it. Period. The drivers for it would have to go in contrib. > I did not notice there was a consensus on this. You are the only person I've seen express views similar to mine on debian-legal. All other participants argue for non-free-firmware-using drivers going in contrib. Also, the current practice already is moving in this direction. For example, the ipw2100 driver is in contrib. It's totally fucking insane, but hey, we seem to be fighting an uphill battle against insanity. -- For every sprinkle I find, I shall kill you!
Re: Linux Core Consortium
On Sat, Dec 11, 2004 at 09:41:47AM +0100, Andreas Barth wrote: > * Brian Nelson ([EMAIL PROTECTED]) [041210 19:55]: > > Yup. There's never been a sense of urgency. The RM's throw out release > > dates and goals every once in a while, but no one seems to take those > > seriously. > > Not true. (And, perhaps you noticed, the release team avoided to give > specific days in the last time, and the timeline depends on a day N.) > > > And probably for good reason. > > Remarks like this _are_ driving the release back. No, they aren't. My remark is a symptom of the overall discouragement I feel with the release process, not a cause. Probably the biggest thing keeping sarge from releasing is the overall discouragement and disenchantment developers feel with the release process. > > For the second straight > > release, when we've gotten to a point that it seemed we were nearly > > ready for a release, we then discover we have no security autobuilders. > > The release then gets pushed back a few more months, while the plebeian > > developers sit around twiddling their thumbs unable to help wondering > > why the hell no one thought to set up the autobuilders in the 2+ years > > we've been preparing a release. > > Be assured, the setting up the security autobuilders are a topic since > I'm following the process of releasing sarge closely. Like e.g. in > http://lists.debian.org/debian-devel-announce/2004/08/msg3.html > which tells us that we need them for being able to freeze. Or, a bit > later, > http://lists.debian.org/debian-devel-announce/2004/09/msg5.html. > This even tells: > | The bad news is that we still do not have an ETA for the > | testing-security autobuilders to be functional. This continues to be > | the major blocker for proceeding with the freeze I was being sarcastic when I said we suddenly discovered it. Of course, it's been known we'd need a security autobuilder infrastructure for sarge since, uhhh, before woody's release. > I don't think this mean that we suddenly discover it, but as other > issues were more prominently blockers e.g. in July (like the toolchain), > those issues were resolved back in September (and are still resolved > now). Anyone, developer or non-developer, can help fix toolchain problems. However, the only people who can work on the testing-security autobuilders are ... the security team and the ftp-masters? What's that, a handful of people? With a bottleneck like that, isn't that a much more important issue? Besides, woody was release 2.5 years ago. In all that time, no one who had the power to setup the autobuilder infrastructure bothered to do it? Let's face it--that's a major fuckup. I'm not blaming you or anyone else in particular. We're all volunteers, we're all busy, we can't force anyone to do the work, etc. But we're not exactly lacking in manpower here. If those with the power didn't have the time to setup the infrastructure, surely over the course of 2.5 years we could have found someone out of the 1,000 or so developers we have that had the time and skill to do it. So why didn't that happen? -- For every sprinkle I find, I shall kill you!
Re: LCC and blobs
Ron Johnson <[EMAIL PROTECTED]> writes: > On Fri, 2004-12-10 at 15:21 -0800, Brian Nelson wrote: >> Matthew Palmer <[EMAIL PROTECTED]> writes: >> >> > On Fri, Dec 10, 2004 at 01:20:32PM +0100, Marco d'Itri wrote: >> >> On Dec 09, Bruce Perens <[EMAIL PROTECTED]> wrote: > [snip] >> >> Then we might as well remove the whole kernel from main, since most >> devices depend on a non-free firmware blob to operate. Why does it > > Most ? I'm no hardware expert, but I assume all ethernet cards, wireless chipsets, and SCSI cards do. At least that's true for all of the hardware I have... > Or are you stretching beyond reason, to include stuff like the > BIOS, which isn't in the kernel? If it made any sense at all for a mainboard's BIOS to loaded by the Linux kernel at boot time with a non-free firmware blob, the current consensus (on debian-legal anyway) seems to be that Debian would not support it. Period. The drivers for it would have to go in contrib. As far as I'm concerned, distribution of the firmware is the manufacturer's realm. Whether the manufacturer distributes it on an EPROM on the device itself, or on a CD shipped with the device, or just provides it for download from a website, I don't care. That's their decision. Debian should not care one bit how the firmware is loaded on the device, and the method used should not dictate whether a driver is DFSG-compliant. As for whether Debian would actually distribute the firmware blobs in main, I would prefer that we do. It can be a real pain installing Debian on a system in which I have to retrieve the firmware from an external source. It's only hurting the end-user by making them jump through more hoops to install Debian, with no obvious benefit. However, there seems to be a strong movement to make Debian 100% free down to the last bit. Reversing this movement is another much more controversial issue. -- For every sprinkle I find, I shall kill you!
Re: LCC and blobs
Matthew Palmer <[EMAIL PROTECTED]> writes: > On Fri, Dec 10, 2004 at 01:20:32PM +0100, Marco d'Itri wrote: >> On Dec 09, Bruce Perens <[EMAIL PROTECTED]> wrote: >> > I have been thinking about the blob problem for a while. I propose to >> > remove blobs from the driver, and store them as files in initramfs (the >> > kernel-internal filesystem created by the stuff in /usr/src/linux*/usr) >> > or initrd.img. At boot time, the drivers would look for the blobs and >> >> You may want to take a look at debian-legal, because some people there >> think that even free drivers for hardware devices which need an >> externally loaded firmware are not acceptable for main. > > I presume you're referring to drivers which are useless without a non-free > firmware blob. We should treat them exactly the same way as any other Free > software which is useless without some non-free component, and stick it in > contrib. Then we might as well remove the whole kernel from main, since most devices depend on a non-free firmware blob to operate. Why does it matter if that blob is stored on the device itself in EPROM or loaded by the kernel? The end result is absolutely identical to the user. If we choose not to distribute non-free firmware blobs, then fine. I still don't see why it has any effect on the device driver though. -- For every sprinkle I find, I shall kill you!
Re: Linux Core Consortium
On Fri, Dec 10, 2004 at 04:38:10PM +0100, Adrian von Bidder wrote: > On Friday 10 December 2004 15.35, Steve Langasek wrote: > > we don't exactly have a strong history of being able to pull off > > timely releases > > Did Debian even try? No, not since I've been around. > I didn't follow the woody release too closely, being a Debian newbie at the > time, so I don't know. But - this was my impression - from the start, > sarge was prepared with the 'we release when we're ready' idea, which makes > everybody feel that they have more than enough time. Yup. There's never been a sense of urgency. The RM's throw out release dates and goals every once in a while, but no one seems to take those seriously. And probably for good reason. For the second straight release, when we've gotten to a point that it seemed we were nearly ready for a release, we then discover we have no security autobuilders. The release then gets pushed back a few more months, while the plebeian developers sit around twiddling their thumbs unable to help wondering why the hell no one thought to set up the autobuilders in the 2+ years we've been preparing a release. -- For every sprinkle I find, I shall kill you!
Re: Status of this ITP?
On Wed, Dec 08, 2004 at 09:26:00PM -0600, Ron Johnson wrote: > On Wed, 2004-12-08 at 11:30 -0600, Steve Greenland wrote: > > On 08-Dec-04, 11:15 (CST), "Luis R. Rodriguez" <[EMAIL PROTECTED]> wrote: > [snip] > > > Get off your ass. > > > > Ah. I see. Courtesy is not your strong point. > > His parents must not have taught him manners. Or he knows that > he can't get beat up by people who don't see him face-to-face. Here, go find him: http://www.acs.rutgers.edu/directory/ :p -- For every sprinkle I find, I shall kill you!
Re: dselect survey
On Wed, Dec 08, 2004 at 10:23:16PM -0500, Mason Loring Bliss wrote: > On Thu, Dec 09, 2004 at 11:11:31AM +0900, Miles Bader wrote: > > > I used dselect a lot back in the day (I don't know, like up until 2000 > > or so?). It had a clunky but useable interface (though I fully > > understand how newbies could get frustrated), and generally worked all > > right until there was a problem; > > Maybe I'm still waiting for my first real problem to show up, but I > generally find dselect to be a real pleasure to use. > > Could you present an example of a problem you had with dselect? Honestly, > I wouldn't be using Debian today if not for dselect, which I see as being > a really nice selling point. If you really want to find out, go ask on debian-user. You'll find plenty of people more than willing to piss all over dselect. -- For every sprinkle I find, I shall kill you!
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Michael Dominok <[EMAIL PROTECTED]> writes: > >> On Wed, 2004-12-01 at 09:15, Brian Nelson wrote: > >> > Through SPI's presence? >> >> Well, i didn't search _that_ long but couldn't find anything on >> http://www.spi-inc.org that would give me the Impression that this a >> Organisation only open to USAsians and/or solely dedicated to the USAs >> national interests. > > That isn't what Brian Nelson said. What he said was that SPI is > "present" in the United States, meaning that is where it is > incorporated. Also, with the context that Debian's association with SPI could be interpreted to mean that Debian is a "product of the USA" and thus subject to trade embargos and other legalities. I have no idea if any government would make that interpretation, but I suppose it's possible... -- For every sprinkle I find, I shall kill you!
Re: Intent to mass-file bugs: FDL/incorrect copyright files
On Thu, Nov 18, 2004 at 01:42:57AM +, Brian M. Carlson wrote: > [EMAIL PROTECTED] (Marco d'Itri) writes: > > > On Nov 17, "Brian M. Carlson" <[EMAIL PROTECTED]> wrote: > > > >> > I'd say that it's not obvious at all how removing crucial documentation > >> > because some people do not like its license will help the distribution > >> > and/or the cause of free software. > >> I don't like a lot of licenses, specifically those that are confusing > >> and long and contain an "Exhibit A", because they are hard to read and > >> understand. But that does not make them *non-free*. What I have a > >> specific objection to in this case is the fact that the license is > >> non-free, not that it is long, or confusing. You are using a strawman > >> example by distorting my position. > > No, you missed the point. The point is that it's not important what > > position you hold, but that whatever your position (or mine) is, it's > > not the criteria that developers should use to determine if they need > > to remove something from the distribution. > > The position that matters is that of the ftpmasters, and they usually > delegate to debian-legal. Now however much you may or may not like > debian-legal, they are usually the ones that decide this. AFAIK, ftp-masters only reject a package if inclusion and distribution in Debian would be illegal. This is not the case with the GFDL. I think in a typical case, the decision is up to the package maintainer, and if the maintainer doesn't agree, the tech committee may resolve this issue. However, since the GFDL is much broader in scope, it is something the entire project should have to decide upon. debian-legal is merely used for discussion, not for decision-making. -- For every sprinkle I find, I shall kill you!
Re: Intent to mass-file bugs: FDL/incorrect copyright files
[EMAIL PROTECTED] (Brian M. Carlson) writes: > This is an intent to mass-file bugs as required per custom. > > Bugs will be filed: > > 1) on packages that include GNU Free Documentation Licensed-material; > 2) on packages in 1) that do not include the copyright or license of > the material in their copyright files; > 3) at serious severity (DP sec. 2.2.1 and 12.5); > 4) with reportbug -m (maintonly@); > 5) by a human, with all facts checked first. I object. Until there is "universal" consensus (either through a vote, leader action, whatever) that GFDL material must be purged from main, these bugs are wishlist at best. debian-legal consensus alone is not grounds for removal. -- For every sprinkle I find, I shall kill you!
Re: Drop testing
On Sat, Oct 23, 2004 at 03:52:51PM -0700, Steve Langasek wrote: > On Sat, Oct 23, 2004 at 02:33:24PM -0700, Brian Nelson wrote: > > Gergely Nagy <[EMAIL PROTECTED]> writes: > > > >> It may sound a bit radical, but core points have been mentioned in the > > >> thread already. I suggest to do it in a more radical way: > > > >> - unstable lockdown in the freeze > > >> - drop Testing and concentrate on work instead of wasting time on > > >>synching stuff. This eliminates the need for testing-security. See > > >>the last part of the paper for details. > > > > Doing this would result in many users who currently run testing fall > > > back to stable + backports or switch to another distro (ubuntu being a > > > likely candidate), which in turn, would result in less bugreports and a > > > less stable distribution. > > > Very few bug reports from testing users are of any value at all. They > > usually either report some transient dependency problem that the > > maintainer can't fix anyway, or report something that has already been > > fixed in the unstable package. > > This seems like a rather unsubstantiated claim. Do you *know* how many of > the good bug reports you've seen come from users of testing vs. unstable? I don't have any hard data, but I've been tracking debian-bugs-dist for about 2 years now so I think I have a decent feel for it. True, you can't always be sure if the user is using testing or unstable, but it often can be inferred. [...] > Yes, filing bug reports on testing is not often useful (except during a > freeze), but that's not the same as it not being useful to have users > running testing. I didn't claim otherwise. I was just trying to refute the claim that bug reports from testing users were useful. I do question if having testing available to the public throughout the entire release cycle is actually beneficial to the community. There's a common misconception in the community that testing is a "more stable" unstable. Many testing users aren't even aware that testing doesn't have security updates. Probably most of the users of testing should *not* be using it at all. This isn't really related to the proposal in this thread to just drop testing though. -- Blast you and your estrogenical treachery!
Re: Drop testing
Gergely Nagy <[EMAIL PROTECTED]> writes: >> It may sound a bit radical, but core points have been mentioned in the >> thread already. I suggest to do it in a more radical way: >> >> - unstable lockdown in the freeze >> - drop Testing and concentrate on work instead of wasting time on >>synching stuff. This eliminates the need for testing-security. See >>the last part of the paper for details. > > Doing this would result in many users who currently run testing fall > back to stable + backports or switch to another distro (ubuntu being a > likely candidate), which in turn, would result in less bugreports and a > less stable distribution. Very few bug reports from testing users are of any value at all. They usually either report some transient dependency problem that the maintainer can't fix anyway, or report something that has already been fixed in the unstable package. -- Blast you and your estrogenical treachery!
Re: gfreeamp playlist inquiry
On Fri, Oct 22, 2004 at 11:42:57PM -0400, Kevin Mark wrote: > On Fri, Oct 22, 2004 at 10:05:30PM -0400, Siqueland-Gresch wrote: > > > > Hello and good evening from Rhode Island ! Go Red Sox! > > I have been using the Freeamp program for years and I am in love with its > > simplicity. No gimmicks. Just functionality. I love that it has a simple > > playlist window on the left and the songs of the playlist on the right. Now > > the only thing missing to my happiness is that the playlists on the left > > become so > > many and that they cannot be subdivided. It would be so nice if it would be > > possible to have the ability to create a playlist named JAZZ which opens up > > on clicking to its subdivisions: Miles Davis, Coltrane , etc. And then > > closes/folds up on clicking it again. > > Has anyone ever built a freeamp module which would enable Freeamp to do that > > ? > what I get from skimming your message is that you want the Freeamp > developer to consider your request for a new feature. Your ability to > ask for features in the software programs that you use is one of the > advantages of libre/free software. You can file a bug report at the > debian site or with the bug tool for a new feature. You can also contact > the debian maintainer and the original developer about this. Their info > should be availble. But unfortunatley this list is about discussion of > issues specific to debian as a whole and not to discussion of one > program or package. I'd suggest to check the site for a better forum > like debian-user. Also note that freeamp was renamed to zinf due to trademark infringment or something a couple years ago. -- Blast you and your estrogenical treachery!
Re: ITH: basket ( was: About Basket packaging status)
On Sat, Oct 23, 2004 at 02:18:40AM +0200, Jos? Luis Tall?n wrote: > Since i have not received any answer since Oct 5th, i prepare to > hijack Basket's ITP in 2 days' time barring > answer from the OP (101 days in preparation) > > I believe that Basket is an useful application to have in Debian, and > will take care of maintaining it as an official package. You're a bit confused here. First of all, mail sent to [EMAIL PROTECTED] does not go to the submitter, so no one other than the QA group actually saw your first mail. Second of all, the person you're trying to contact (Luke) merely filed the RFP (request for package). Check the bug report and you'll see that Pierre Habouzit was the person to change the title to ITP. -- Blast you and your estrogenical treachery!
Re: problem to unsubscribe
Arnaud Vandyck <[EMAIL PROTECTED]> writes: > Hi all, > > I read debian-devel via the newsgroup now (linux.debian.devel) and I'd > like to unsubscribe to the list but I can't. I did receive the > confirmation string and answer it but it seems that I still receive > mails from the list (also for debian-mentors - > linux.debian.devel.mentors). > > I'd like to do it for every list but I can't unsubscribe. Is there a > problem with the unsubscribe script? Why are you asking us? Ask the listmasters. -- I'm sick of being the guy who eats insects and gets the funny syphilis.
Re: apell
Brian Nelson <[EMAIL PROTECTED]> writes: > Henning Glawe <[EMAIL PROTECTED]> writes: > >> Moin, >> what are the "license problems" causing the removal of aspell in the >> update to 3.0r2 ? > > IMO, there are no license problems. See: Actually, I take that back. There was a serious bug in that /usr/share/doc/aspell-en/copyright claimed it was LGPL, but the wordlists in fact are under a conglomerate of licenses (none of which are copyrightable anyway in the US, but hey...). -- Don't worry, it's *in*-flammable. pgpSjSM1dfveQ.pgp Description: PGP signature
Re: apell
Henning Glawe <[EMAIL PROTECTED]> writes: > Moin, > what are the "license problems" causing the removal of aspell in the > update to 3.0r2 ? IMO, there are no license problems. See: http://lists.debian.org/debian-user/2003/debian-user-200312/msg00870.html > do these problems exist in debian unstable ? No. > if not: why was aspell _removed_ from stable and not replaced by a > backport of the version in unstable ? The upgrade to Aspell 0.50 is too big of a change for stable and would break a ton of stuff. -- Don't worry, it's *in*-flammable. pgpFNCPhCksgL.pgp Description: PGP signature
Re: Some observations regardig the progress towards Debian 3.1
Norbert Tretkowski <[EMAIL PROTECTED]> writes: > * Adrian Bunk wrote: >> - testing, unstable or Debian 3.0 with backports aren't suitable for >> production systems > > Of course it is, Debian 3.0 with a few _selected_ backports works > nice, also on production systems. Err, do you realize you're telling that to the person that maintains the largest collection of woody backports, including probably the few selected ones you're using? If he's saying they aren't suitable for production systems, you should take his word for it. -- I'm sick of being the guy who eats insects and gets the funny syphilis. pgpvfVg1xXxj5.pgp Description: PGP signature
Re: sarge release
martin f krafft <[EMAIL PROTECTED]> writes: > I apologise if this is covered elsewhere, I am currently totally > swamped and can't afford too much time for Debian. > > I am going to be away from my machine(s) starting 22 Nov until the > middle of December. I currently have 1 RC bug and several other bugs > against my packages. If sarge's release will happen in 2003, I will > bite the bullet and fix these bugs over the next couple of days. > However, if sarge's release is delayed till 2004, I would be a lot > saner if I didn't have to worry about Debian right now. > > What's the status? Er, I think any RC bug in a package should be fixed ASAP, regardless of the release schedule. -- I'm sick of being the guy who eats insects and gets the funny syphilis. pgpXgsfk3MqT5.pgp Description: PGP signature
Re: Bug#219293: ITP: songwrite -- a tablatures editor and player
Joe Drew <[EMAIL PROTECTED]> writes: > On Wed, 2003-11-05 at 09:16, Marc DequÃnes wrote: >> * Package name: songwrite >> Description : a tablatures editor and player > > Drop the leading 'a'. > >> Songwrite is a tablatures (guitar partitions) editor and player >> entirely written in Python. > > Is 'partitions' the right word here? (I honestly don't know.) I would say: Songwrite is a guitar tablature (fingering notation) editor ... -- I'm sick of being the guy who eats insects and gets the funny syphilis. pgp1AYG4QCYA2.pgp Description: PGP signature
Re: nethack popularity contest - number_pad?
Jochen Voss <[EMAIL PROTECTED]> writes: > Hello, > > On Thu, Oct 16, 2003 at 06:30:26PM -0700, Joshua Kwan wrote: >> Which is better? I like the default keys because you learn how to use >> nvi very efficiently knowing the hjkl-style keys :) > I am in favour of both :-O > > * The hjkl style keys are really impossible to remember. > So of course the number_pad option should be on by default. > > * My laptop has no number pad, the game would be broken > for me when the number_pad option was on. > So of course the number_pad option should be off by default. * My laptop has no number pad and uses Dvorak key layout. So of course htns keys should be the default. >> I'm searching for as >> many opinions as possible so please speak up! > Is two opinions enough? Nope. :p -- I'm sick of being the guy who eats insects and gets the funny syphilis. pgpX0sURJjqxd.pgp Description: PGP signature
Re: Quote: Debian and Democracy at Advocato.org
Matthew Palmer <[EMAIL PROTECTED]> writes: > On Fri, Oct 10, 2003 at 06:27:59PM -0400, Matt Zimmerman wrote: >> On Wed, Oct 08, 2003 at 04:25:17PM -0300, Daniel Ruoso wrote: >> >> > >> > Debian and Democracy >> > Posted 7 Oct 2003 by exa (Master) >> >> >> Ha. Hahahaa. Ha, ha, ha... > > You don't think he's a Master? I'm quite sure he's a Master debater. He's > also probably a good fisherman - a baiter, as it were. "Like any of that's enough to fight the dark master bater. I think you're drawing a lot of crazy conclusions about the unholy prince bater." -- I'm sick of being the guy who eats insects and gets the funny syphilis. pgp6exA2MaIw6.pgp Description: PGP signature
Re: Bug#212525: Package contains non-free GNU FDL material
Branden Robinson <[EMAIL PROTECTED]> writes: > On Wed, Sep 24, 2003 at 02:40:07PM -0500, Manoj Srivastava wrote: >> I did. I feel my packages are not buggy, lacking a position >> statement by the project. > > So, what we ship in main shall not be a function of whether the works in > it are DFSG-free or not, but shall instead depend on whether or not the > Debian Project has passed a General Resolution specifically withdrawing > them. If the software has been in Debian since the beginning and has always had non-free political texts (AIUI, this is true of GNU/Emacs and probably other various older GNU software), I think that's a reasonable stance. -- I'm sick of being the guy who eats insects and gets the funny syphilis. pgpWUiawpsYRX.pgp Description: PGP signature
Re: How to install X-Chat in five hours (or more)
Alan Shutko <[EMAIL PROTECTED]> writes: > Steve Lamb <[EMAIL PROTECTED]> writes: > >> Oh, look, someone else who CCs when it is obvious the person they're >> responding to is participating right here. > > Maybe you should stop whining and just set the Mail-Copies-To header, > which is generally respected by posters on Debian lists? Har! The people that use a decent MUA already know how to participate in list discussions, and those that don't won't pay a bit of attention to that header. -- I'm sick of being the guy who eats insects and gets the funny syphilis. pgpSznaaJXdBF.pgp Description: PGP signature
Re: Bug#203498: ITP: decss -- utility for stripping CSS tags from an HTML page.
Keith Dunwoody <[EMAIL PROTECTED]> writes: > Chad Walstrom wrote: >> On Wed, Jul 30, 2003 at 03:52:51PM +, [EMAIL PROTECTED] wrote: >> >>>Package: wnpp >>>Version: unavailable; reported 2003-07-30 >>>Severity: wishlist >>> >>>* Package name: decss >> Like that won't be a confusing package name. ;-p >> > > If you read the website, that was the point ;) The website also says: "I wrote a small utility called "DeCSS" that strips Cascading Style Sheet tags from an HTML document. Yes, agreed, that's pretty much USELESS, but what the fuck. Maybe somebody wants to do that." Why the hell should this be packaged for Debian? -- I'm sick of being the guy who eats insects and gets the funny syphilis. pgpHPgXF6pLdc.pgp Description: PGP signature
Re: Future releases of Debian
Halil Demirezen <[EMAIL PROTECTED]> writes: >> some useless architecture like arm or m68k > > Are we in dilemma on "should we support arch that are not used widely?" or > "We should support all architectures" No, this has nothing to do with usage. The question is why support an arch if nobody is interested in doing the work? -- Poems... always a sign of pretentious inner turmoil. pgpslHHXrApxA.pgp Description: PGP signature
Re: Qt3 still broken (compat-headers), what to do?
Sebastian Rittau <[EMAIL PROTECTED]> writes: > On Sun, Jul 13, 2003 at 01:51:07PM +1000, Ben Burton wrote: > >> It seems then that our options are as follows. >> >> (i) Wait for the Qt maintainers to upload a fix. >> (ii) Do an NMU for Qt, despite the fact that this bug is not >> release-critical. >> (iii) Resort to the technical committee. >> (iv) Keep the package split and release sarge with a broken Qt development >> environment. > > Option (iii) is certainly the way to go. Problems like this are exactly > what the TC is for. > > My suggestion: Add a "Recommends: libqt3-compat-headers" to libqt3-dev. > A dependency is too strong, since libqt3-dev is perfectly usable without > the compatibility headers, but a recommendation ensures that the compat > headers are installed along libqt3-dev in most cases. Uhh, there's no reason the compat headers should have been split out in the first place. -- Poems... always a sign of pretentious inner turmoil. pgpOwozzSjaLu.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
Andrew Suffield <[EMAIL PROTECTED]> writes: > On Thu, Jul 03, 2003 at 02:19:59PM -0700, Brian Nelson wrote: >> Andrew Suffield <[EMAIL PROTECTED]> writes: >> >> > On Thu, Jul 03, 2003 at 06:23:14PM +0200, Marcelo E. Magallon wrote: >> >> > That would be clause #1 of the Debian Social Contract. >> >> >> >> Where do you draw the line between software, data and documentation? I >> >> get the impression that you are reading "Debian Will Remain 100% Free >> >> Software" to mean "everything in Debian will be Free Software" instead >> >> of "all the software in Debian will be Free Software". >> > >> > Well, of *course* we do. It would be idiotic and hypocritical to >> > interpret it as "The software in Debian will be free, but the >> > documentation doesn't have to be". >> > >> > We have historically allowed some free non-software things into the >> > archive, since it doesn't matter very much. Why does anybody think >> > that allowing non-free non-software things into the archive is >> > acceptable? >> >> It all depends on how you define "free". I think that documentation, as >> long as it's freely distributable and usable, is free enough. I don't >> see any need to require documentation to be freely modifiable. > > You have some free software, and it comes with a manual. You modify > the software in a manner which suits you... but you're not allowed to > modify the manual to reflect this change; the license of the manual > requires that it only document the unmodified version, so any modified > versions are at an immediate disadvantage. > > And you think this is acceptable? Why? It's more acceptable to me than the alternative: to move a good portion of documentation to non-free where it will not be distributed by vendors, will not be considered "part of Debian" and thus will be under threat of removal, and will be considered a "lower class" package. Fortunately, the situation you describe is unlikely to occur because few people are perverse enough to make their software free but their documentation very non-free. -- Poems... always a sign of pretentious inner turmoil. pgpIs2NqxWFOe.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
Andrew Suffield <[EMAIL PROTECTED]> writes: > On Thu, Jul 03, 2003 at 06:23:14PM +0200, Marcelo E. Magallon wrote: >> > That would be clause #1 of the Debian Social Contract. >> >> Where do you draw the line between software, data and documentation? I >> get the impression that you are reading "Debian Will Remain 100% Free >> Software" to mean "everything in Debian will be Free Software" instead >> of "all the software in Debian will be Free Software". > > Well, of *course* we do. It would be idiotic and hypocritical to > interpret it as "The software in Debian will be free, but the > documentation doesn't have to be". > > We have historically allowed some free non-software things into the > archive, since it doesn't matter very much. Why does anybody think > that allowing non-free non-software things into the archive is > acceptable? It all depends on how you define "free". I think that documentation, as long as it's freely distributable and usable, is free enough. I don't see any need to require documentation to be freely modifiable. -- Poems... always a sign of pretentious inner turmoil. pgpglFehO2Szu.pgp Description: PGP signature
Re: Application files in $HOME
Richard Braakman <[EMAIL PROTECTED]> writes: > On Wed, Jun 25, 2003 at 02:02:04PM -0300, Daniel Ruoso wrote: >> What if the packages tells to dpkg which files or directories it will >> create on the user's home directory and when a package is purged the >> user could run a program to purge the files of packages that no longer >> exists. > > I have a better idea :) What if packages don't leave droppings in my > home directory in the first place? I have all sorts of dotfiles (and > even dot-directories) that I never asked for. It's reasonable for a > program to install a dotfile when I configure it differently from the > default, but there's no reason to create a dotfile that's identical > to the default. Amen, brother! $ ls -Ad ~/.* | wc -l 241 -- Poems... always a sign of pretentious inner turmoil. pgpoTAP7pod8x.pgp Description: PGP signature
Re: Please don't misuse the debian/changelog to close bugs!
Herbert Xu <[EMAIL PROTECTED]> writes: > Brian Nelson <[EMAIL PROTECTED]> wrote: >> >> It's pointless to go through this again. Instead, I'll offer a concrete >> example of the confusion this can create (the original submitter asks >> for clarification of how the bug was fixed): >> >> http://bugs.debian.org/188740 > > That's a documentation issue. debian/changelog is not the place for > documenting random features. Huh? The bug report was a feature request with a patch. The bug was closed with the description of "New Upstream Release". No indication was given whether the patch was integrated upstream, or implemented differently (with a different interface). I don't consider this information "documentation of random features". >>> As I have said before, this is incomplete: only bugs that were reported >>> and identified are listed, and redundant: these changes should be in >>> the upstream changelog already. >> >> I don't see anything particularly helpful in the upstream changelog for >> the above example. > > Please do not generalise the practice of individual upstream authors. Uhh, I didn't. In fact, *you* are the one trying to dictate what goes in upstream changelogs, which is utterly pointless. Every upstream is different, and Debian has absolutely no control what upstream decides to put in their changelogs. That's why we must standardize[1] our changelog entries, so that the pertinent information will be available regardless of what upstream does. If the upstream authors for your packages already include accurate descriptions of bug fixes in their changelogs, then great. So you have to spend a couple extra minutes duplicating the descriptions. Tough. [1] By which I mean each separate (i.e. not merged) bug closed in a Debian changelog must get its own changelog entry with a description. Separate bugs must get separate descriptions. Unrelated bugs should never share a changelog entry. Or something like that. -- Poems... always a sign of pretentious inner turmoil. pgpf12QOZu7Tt.pgp Description: PGP signature
Re: Please don't misuse the debian/changelog to close bugs!
Herbert Xu <[EMAIL PROTECTED]> writes: > Gerfried Fuchs <[EMAIL PROTECTED]> wrote: >> >> During some of the discussions lately on debian-devel another usage of >> the changelog has risen interest: >> >> * New upstream release (closes: #123, #124, #125) >> >> This has also raised some discussions. The thing is this: If #123, >> #124 and #125 aren't just "New upstream version available" bugreports >> then quite some people dislike this behavior. It shouldn't be too much >> hazzle for the maintainer to rewrite this as follows: > > I strongly disagree with your view. Please respond to my points > that have been raised previously rather than repeating this dogma. It's pointless to go through this again. Instead, I'll offer a concrete example of the confusion this can create (the original submitter asks for clarification of how the bug was fixed): http://bugs.debian.org/188740 >> * New upstream release (closes: #123) which includes: >> - tmpfile race condition fix (closes: #124) >> - manual page included (closes: #125) >> >> The thing is: It helps the users and the person who reported the bug to >> see what bug exactly was closed without the need for them to dig in the >> BTS. This is no must but it is something your users would be greatful if >> you could do it. > > As I have said before, this is incomplete: only bugs that were reported > and identified are listed, and redundant: these changes should be in > the upstream changelog already. I don't see anything particularly helpful in the upstream changelog for the above example. -- Poems... always a sign of pretentious inner turmoil. pgp49SrhX4bqQ.pgp Description: PGP signature
Keysigning opportunity in Portland, OR
I'm going to be in Portland, Oregon, for June 22-28. I'll probably have time for a keysigning and maybe a quick beer if any Debian developers and/or users are interested. Just drop me a mail if you want to meet somewhere. -Brian -- Poems... always a sign of pretentious inner turmoil. pgp8NklV0An1e.pgp Description: PGP signature
Re: [mass bug filing?] Short descriptions being used as long descriptions and other policy violations
Javier FernÃndez-Sanguino PeÃa <[EMAIL PROTECTED]> writes: [...] > I was wondering, should I make a mass filing of bugs for those packages > who fail to produce a proper description? > > I would probably first do so for the packages whose short description = > long description or who do not have a description at all and would review > which of the "one liners" do not provide sufficient information. That sounds sane enough to me. -- Poems... always a sign of pretentious inner turmoil. pgpydGNseIUr0.pgp Description: PGP signature
Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e")
"Marcelo E. Magallon" <[EMAIL PROTECTED]> writes: > On Sun, Jun 01, 2003 at 02:59:40PM +0200, Rene Engelhard wrote: > > > >* New upstream version (Closes: #193497) > > > > Meep. No. > > > > Write proper changelogs and(or close bugs the right way[tm]. That > > form is only acceptable for "New upstream version, please package it" > > like bugs. > > With all due respect: piss off. FWIW, my policy has become to only politely ask maintainers in private to use more verbose "New upstream version" changelog entries in the future, because it seems to be a religious issue for some. > Is this a new sport in #d-d or something like that? I read that > entry as "the new upstream version fixes the problem reported in > #193497", and looking at the BTS that is exactly its meaning. But the problem is that you don't describe what was reported in #193497. A entry that says: * Closes: also says this version fixes a problem reported in #, but I think we can all agree that's not an acceptable entry. In this case, an entry that simply says: * New upstream version, fixes bashism in svsetup (Closes: #193497) would be much more informative and only take a few additional seconds of your time to write. I find it puzzling why you'd so adamantly refuse to do something so trivial that is yet so useful. > I'm sure there's a thousand better things to do with your time (hint: > fixing bugs) other than nitpicking at changelog entries because they > don't include the last period and last comma you want them to. Not even closely analogous. > This changelog-policying camp is becoming very very > counter-productive. Only to you because you've chosen to fight it. However, poor changelog entries are very very counter-productive to anyone that is checking the bug history of your package. -- Poems... always a sign of pretentious inner turmoil. pgpcZsq0e4BkV.pgp Description: PGP signature
