Fwd: the planet is gone...
I have always liked Demons (UK ISP) status which is linked to the motd on their gateway. If you type "finger [EMAIL PROTECTED]" you get the current status of their systems. Simple perl cgi which also does a web page. If there is interest (and nothing already exists) I will code something along the these lines. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Looking for a co-maintainer for adduser
On Sun, Oct 05, 2003 at 05:18:45PM -0600, Bob Proulx wrote: > Saying "well-written" is cheating. Any well written program is always > good by definition or it is not be well written. But what about > poorly written cruft? Almost all languages are easy to write badly. > But some are easier than others. Both C++ and Perl come to my mind > when I think of bad programming practices and swiss army chainsaws. I think the point is that good code and bad code are possible in any language, and the panacea of switching to a particular language and expecting all coding programs to go away is simplistic and unrealistic. Sure in some languages like Java there aren't going to be pointer problems, but other avenues of attack are just as likely; insecure use of temporary files, symlink attacks, signal attacks and etc. Steve -- # Debian Security Audit Project http://www.steve.org.uk/Debian/
Re: Mini-DebConf in Cambridge, UK - October 10-13 2024
On Mon, Jun 24, 2024 at 12:18:56PM +0200, somebody *claiming* to be Luna Jernberg wrote: Just to be 100% clear, that mail didn't come from Luna's normal gmail account but was instead spoofed and sent via emkei.cz, a "free online fake mailer". It's now blocked from Debian lists. -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Re: what about Netplan?
Luca Boccassi wrote: > >Networking is not static, it constantly changes in the kernel, >sometimes in dramatic and incompatible ways. Sorry, but no. Networking clearly is *not* changing that fast, in software terms. Many old tools still continue to work just fine after a decade or more. >A widely used, well maintained stack with large amounts of >contributors is fundamental for the default choice, because we have >to keep up, as the rest of the world will not sit and wait for us. > >Here's some stats from 'git shortlog --after="2021-12-31" -sn --all'. >In the last ~2.5 years, in netplan.io's github repo, there are only 2 >contributors with more than 100 commits, and 2 with more than 10, and >2 of them are Canonical employees: > > 569 Lukas Märdian > 310 Danilo Egea Gondolfo >39 Simon Chopin >38 Danilo Egêa Gondolfo >11 Robert Krátký > >Same stat, for the same period, for systemd: > > 6650 Yu Watanabe > 5415 Lennart Poettering > 2884 Luca Boccassi > 2772 Zbigniew JÄdrzejewski-Szmek ... >3 companies and one independent in the 4 digits, and too many to be >bothered to check between 10 and 999 commits. I understand what you're trying to say, but that's a disingenuous comparison. systemd is a massive (some would say *too* massive) project with fingers in many pies. How many of those people have touched *networking* bits? -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
Re: what about Netplan?
On Mon, Jul 15, 2024 at 03:47:16PM +0100, Luca Boccassi wrote: > Assuming that's really needed, and it's far from clear that different > use cases should really use the exact same things, using > network-manager everywhere would achieve the exact same result, > without pulling in additional dependencies, and without being tied to > the internal decisions made in Canonical that we cannot do anything to > influence. Again, not your fault, but existing examples don't exactly > inspire a lot of confidence in that regard: mir, upstart, unity, > lxd... You could compile a similar list of software projects that were abandoned when Red Hat stopped funding them. Or of entirely community-backed free software projects that are moribund. I think it's prejudicial to argue that a piece of free software should not be adopted because its development is funded by a company which, over the course of 20 years, has made strategic decisions to discontinue investments in other, unrelated projects. Either netplan is technically sound, providing a sensible configuration language that meets the needs of Debian users and has a high-quality code base, in which case it should not actually be a problem for Debian to maintain it in the event that Canonical discontinues work on it; or it isn't, and we can stop the discussion there. BTW, of your list of previous Canonical projects above: - upstart was discontinued because Debian made the decision to default to systemd. Init systems are effectively a winner-take-all problem space due to the network effects of upstream integration; any technical advantages of upstart could not justify swimming against the current with both Debian and Red Hat shipping systemd. So that's a situation that doesn't arise for a technology that Debian DOES pick? :) - mir is no longer used on the Ubuntu Desktop, but it isn't dead; it lives on in mir-kiosk and its successor ubuntu-frame. https://ubuntu.com/blog/the-journey-from-mir-kiosk-to-ubuntu-frame And I don't think you're actually suggesting it would be healthy this far along for there to be competing compositor protocols on the Linux desktop... - unity is no longer funded by Canonical, but it is not dead, in either its unity 7 or unity 8 (lomiri) incarnations, but rather continues to be maintained in both Debian and Ubuntu - to my consternation as a member of the Ubuntu Release Team, since that increases the number of flavor images we have to manage releases of ;) - Canonical has not discontinued its development of lxd. I think the larger Free Software community political questions of lxd vs incus are off-topic here. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Removing more packages from unstable
Noah wrote: >On Tue, Aug 20, 2024 at 11:09:51AM +0200, Bastian Venthur wrote: >> I think popcon does give a good approximation of how much percent of people >> installed a certain package even if not everyone uses it, don't you agree? > >No, definitely not. There are hundreds of thousands of Debian systems >running in various cloud environments, and I'd be surprised if any of >them have ever submitted popcon data. > >> Last time I installed Debian it was still enabled by default. > >Oh? I don't think it has ever been enabled by default. It hasn't been AFAIK, no. d-i always asks, with the default being "no". -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
Re: Ubuntu discussion at planet.debian.org
On Sat, Oct 23, 2004 at 06:39:20AM +0200, Jérôme Marant wrote: > Colin Watson <[EMAIL PROTECTED]> writes: > >> Are you saying that technical choices do not contribute to the success > >> of Canonical? For instance, deciding to target the distribution at > >> most popular architectures only? > > In my experience as both a Canonical employee and a Debian developer, > > the number of architectures supported by Ubuntu makes a negligible > > difference to Ubuntu's ability to release. > Nonetheless, you won't deny it makes things significantly slower. By saying that it makes a negligible difference, he *did* deny that it makes things significantly slower. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Ubuntu discussion at planet.debian.org
On Sat, Oct 23, 2004 at 12:35:11PM +0200, Jérôme Marant wrote: > Steve Langasek <[EMAIL PROTECTED]> writes: >>> Nonetheless, you won't deny it makes things significantly slower. >> By saying that it makes a negligible difference, he *did* deny that it makes >> things significantly slower. > I forgot to add "in Debian". No need to be harsh. I'm not sure why you think it's harsh of me to refute a bald, unsubstantiated assertion about what someone else believes -- which is what your comment is, with or without the "in Debian". If Colin (who is in a better position to judge this than I am) believes that the architecture count in Ubuntu did not contribute significantly to the speed of their release cycle, then he's clearly making a case that there's merely *correlation* between the architecture count and the time to release, not *causality*. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Drop testing
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? Reportbug should give this kind of information, but just looking at the version of the package they've filed the bug against isn't even an indicator; it may just mean the user tried upgrading to the unstable version of the package before reporting the bug, because she was trying to ensure the bug report would be useful/was hoping the bug was fixed without any need to file a bug report. 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. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Ubuntu discussion at planet.debian.org
On Sun, Oct 24, 2004 at 01:37:21AM -0500, Manoj Srivastava wrote: > >> This is incorrect, t-p-u is indeed supported by buildds -- though > >> this paragraph seems to be more like a rant than anything else. > > Okay, it's a month old, but there hasn't been any since. > > http://lists.debian.org/debian-devel-announce/2004/09/msg5.html > > "We are also still missing official autobuilders for > > testing-proposed-updates on alpha and mips. All other architectures > > appear to be keeping up with t-p-u uploads." > Missing a buildd on an arch or too is a far cry from t-p-u > being unsupported. Unfortunately, nothing in t-p-u can be safely accepted into testing until it's been built for all relevant architectures. While having 9 out of 11 architectures building t-p-u is better than still needing all 11 archs to be set up for it, the practical, visible impact *today* on testing is the same; it just means that the "tomorrow" when we can use t-p-u for its intended purpose is likely a little closer. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Ubuntu discussion at planet.debian.org
On Sun, Oct 24, 2004 at 03:48:04AM -0700, Michael K. Edwards wrote: > On Sat, 23 Oct 2004 01:04:41 +0200, Jérôme Marant <[EMAIL PROTECTED]> wrote: > > As soon as testing is strictly equal to unstable regarding package > > versions, testing is roughly ready for release. > If Jérôme's observation is correct, then I don't need to worry; > unstable will converge to a consistent state under the watchful eyes > of the RM (and many others), testing will rise to meet it, and the > worst that might happen is that some of the packages I've chosen could > be excluded from sarge because of a quality problem or an ill-timed > maintainer absence. It is not correct. At the time testing freezes for sarge, there are likely to be many packages in unstable which either have no version in testing, or have older versions in testing. The list of such packages is always visible at <http://ftp-master.debian.org/testing/update_excuses.html.gz>. While it's a goal of the release team to ensure that *incidental* issues don't keep package fixes/updates out of testing, there are plenty of package updates which will come too late for consideration, or will be RC-buggy in their own right, that won't be part of sarge. And immediately *after* the freeze point, I think we can safely expect unstable to begin diverging even further from testing. > In this light (and for my purposes), the only sensible place to branch > stable off from unstable is at a point where the major subsystems are > all going to be reasonably maintainable on the branch. Perhaps we're > close to such a point now and just haven't been for a while, for > reasons largely beyond the Debian project's control. (Apart from the > definition of its "major subsystems", that is; note that Ubuntu > doesn't expect to be able to provide the level of support for KDE that > they plan for Gnome, and it appears to me that the effect of changes > in the C++ toolchain on KDE has been a significant factor in delaying > sarge. Do tell me if I'm mistaken about that, but please don't flame > too hard; I'm not casting aspersions on KDE or g++/libstdc++, just > recording an impression.) While getting KDE updates into testing has been a significant task in the past, I'm not aware of any point during the sarge release cycle when KDE has been a factor delaying the release. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Drop testing
e begins > - MAIN FREEZE: takes three weeks, beginning from the freeze day. Unstable >branch will be moved to "frozen". Packages uploaded to "frozen" or >"unstable" are mapped to "frozen-candidates" and are to be reviewed by the >release team. > - DEEP FREEZE: 1-2 weeks. Only important updates are allowed to be moved from >"frozen-candidates". Release team has to decide with majority about this > actions. > - After the release, the contents of "stable" are synchronized with > "unstable" >and the new iteration begins. Over the course of the sarge release cycle, we have had various RC bugs in the base system practically constantly. These are packages that *cannot* be dropped for bugginess; they either get fixed, or the bugs get downgraded, though the latter option is also usually not practical. At the time of the base freeze announcement, the RC bug count on base+standard packages was at a relative low, and the remaining RC bugs appeared to be straightforward to fix. Three months on, we have just now gotten a glibc+gcc+binutils set that's free of RC bugs, as one RC bugfix led to another. And while I certainly can't prove it, my own suspicion is that without the impetus of the freeze, we would be even farther from release than we are today. So where in the above three-stage freeze process would you put this sequence of discouragingly-hard-to-fix sequence of RC bugs, and what would their impact be on the actual freeze timeline (both its starting point and its duration)? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: software updates file in /usr -- policy bug?
On Tue, Oct 26, 2004 at 07:16:47PM +0200, Frank Küster wrote: > martin f krafft <[EMAIL PROTECTED]> schrieb: > > For reference, here are two points that came up on IRC: > It's good that you keep us non-chatters informed. However: > > - The administrator has no place in /usr, it's the package > > manager's domain. > > > > - Tools keep MD5 sums for files installed. When a file in /usr > > changes, it is usually an indication of something fishy; thus, > > certain programmes will fire alarms. > > > > Lastly, the policy promises that /usr can be read-only and > > guarantees software to be fully functional. > Now, where is the possible policy bug? It isn't a policy bug at all; it's a case of a package that's violating policy. (apt-spy, if the thread parent is no longer apparent.) -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Problem with dpkg on alpha ?
Cc:ed to the alpha buildd maintainer, so he can take a look at this problem if he hasn't already. On Mon, Nov 01, 2004 at 01:20:58PM -0600, John Goerzen wrote: > I've seen that on the buildd but my own Alpha isn't having any trouble. > A message on this topic to debian-alpha yielded no replies either, so I > suspect the buildd machine is the only one hosed. > On Mon, Nov 01, 2004 at 07:42:01PM +0100, Jean-Yves LENHOF wrote: > > Is'nt there something wrong with dpkg on alpha... it seems to segfault a > > lot these days... > > > > http://buildd.debian.org/build.php?&pkg=mozilla-firefox&ver=0.99%2B1.0RC1-2&arch=alpha&file=log > > http://buildd.debian.org/build.php?&pkg=cxref&ver=1.6-3&arch=alpha > > http://buildd.debian.org/build.php?&pkg=fribidi&ver=0.10.4-6&arch=alpha&file=log -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Why sysklog uses its own logrotate and not logrotate script
On Mon, Nov 01, 2004 at 09:39:51PM +0100, Marc Haber wrote: > On Mon, 1 Nov 2004 15:29:36 +0100, Martin Schulze <[EMAIL PROTECTED]> > wrote: > >Please send me the patch. > Honestly, looking at sysklogd's bug list doesn't make people get the > impression that it makes sense to file patches against the sysklogd > package. Honestly, comments like these don't give people the impression that you're interested in working with maintainers to get bugs fixed. If you aren't willing to submit a patch to address the bug in question, you really have no business complaining about the state of another maintainer's package. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Intent to mass-file bugs: FDL/incorrect copyright files
On Wed, Nov 17, 2004 at 06:49:21PM +, Brian M. Carlson wrote:
> 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.
Without wishing to start/take part in a huge flamewar didn't we have
a vote and agree to leave such documentation issues until after
Sarge's release?
Here's the result I'm thinking of:
http://www.debian.org/vote/2004/vote_004
Steve
--
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
Rather than argue about morality, legality, whatever, shouldn't we be considering this in other terms - simple usefulness? Instead of asking "why shouldn't this go into Debian?", ask "why _should_ this go into Debian?". We seem to have a growing and worrying trend to pick up any random free software and add it to the distribution without considering whether it's actually useful or not... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "This dress doesn't reverse." -- Alden Spiess
Re: Bug#283751: ITP: fakepop -- fake pop3 server to warn users that only pop3-ssl is available
Ron Johnson writes: >On Wed, 2004-12-01 at 22:25 +1100, Matthew Palmer wrote: >> >> So I can put "All your mail is belong to us" in my /etc/fakepop/ directory, >> so that people know that their passwords *have* been successfully sent in >> the clear before being told to reconfigure their mail client? Well, *I'm* >> comforted. > >But since the password isn't valid, does it make much difference? > >For example, my pop3 password isn't the same as my GnuPG passphrase. Quite, but you're more clueful than most. The people seeing these messages will most likely have just attempted to log in using their normal username and password... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On 30-Nov-04, 11:18 (CST), Ron Johnson <[EMAIL PROTECTED]> wrote: > > *Most* who were Christians. Most of the people in the US were Christians. Most of the slave owners were Christians, and used the same Bible to provide justification. If you're going to give religion credit for the anti-slavery movement, you have to blame it for the slavers as well. Which just shows what others in this thread have said: religion is often used to justify whatever behaviour/belief the individual wants to justify. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: [OT] God knows what [was Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor]
On 01-Dec-04, 01:16 (CST), Russell Coker <[EMAIL PROTECTED]> wrote: > On Wednesday 01 December 2004 16:10, William Ballard <[EMAIL PROTECTED]> > wrote: > > On Wed, Dec 01, 2004 at 03:48:48PM +1100, Russell Coker wrote: > > > they still have not forgotten or forgiven what the crusaders did while > > > carrying a flag with a red cross on a white background. > > > > Plenty of brutality on the other side. (Moorish invasion of Spain.) > > I guess I'm equally justified in viewing the Crescent as symbol of > > brutality and butchery? > > You could. However there is no sign of a repeat of that now so it's less of > an issue. Are you claiming that there are NOT, at this time, plenty of people killing random innocents, and waving the Islamic Crescent to justify it? Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On 02-Dec-04, 08:28 (CST), John Goerzen <[EMAIL PROTECTED]> wrote: > Don't forget that people can sue us -- and force us to mount a costly > defence -- even if the law is on our side. They can do this no matter what we do. You may recently have heard of a company named "SCO". I personally find hot-babe silly, at best. I can see that some might be offended - people often choose to offended in ways that baffle me. But if you're going to remove every package in Debian that might offend, or might be illegal somewhere, then there are many packages that are more problematic than hot-babe, starting with, as many have already pointed out, bible-kjv. I'm completely serious here: I think the general attitude promoted by the Christian Bible (and other religious texts), that is, promotion of intolerance, irrationality, and the supernatural over science and rational thought, is much more offensive and harmful to society that than a cartoon nipple. I've not previously objected to the inclusion of the Bible because I think that censorship is even worse. But if we, Debian, are going to go down that path, then that would be the first thing on my list. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On 02-Dec-04, 02:13 (CST), Ron Johnson <[EMAIL PROTECTED]> wrote: > Encourage? No. But when he gets old enough to be interested in > girls, and especially naked girls, he's going to do it on his own. So you're abdicating your responsibility as a parent to teach your child how to be safe and sane in his sex life? Fantastic. (Not that I think hot-babe is particularly educational. I'm just sad that so many American adults are so scared of the human body that they find a silly cartoon threatening.) Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On 02-Dec-04, 02:23 (CST), Ron Johnson <[EMAIL PROTECTED]> wrote: > No. Everywhere (or just about everywhere) in the US, it is illegal > to give porn to a minor. If hot-babe is porn, then so is pretty much any issue of Cosmopolitan, quite a few photography magazines, and about every third issue of the New Yorker. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On 02-Dec-04, 02:35 (CST), Ron Johnson <[EMAIL PROTECTED]> wrote: > > Note the "lewd exhibition of the genitals". Note the word "genitals". Now look again at the cartoon in hot-babe. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On 02-Dec-04, 03:47 (CST), Kevin Mark <[EMAIL PROTECTED]> wrote: > How would a bug report about 'this packages offends me because of > $SOME_REASON' be handled?' about say vi? I would think "what a nimrod" and close the bug. Well, unless $SOME_REASON was "it ate my file when I entered the ':wq' command", which would be offensive, I agree. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On 01-Dec-04, 15:49 (CST), Brian May <[EMAIL PROTECTED]> wrote: > > This is different from the Bible - if you find the bible offensive you > don't have to install it. "If you find hot-babe offensive, you don't have to install it." > If you don't want your kids to install nude pictures, they might find > it on a source you hadn't anticipated (a Debian CD of all things) and > install it without your permission. "If you don't want your kids to read the bible, they might find it on a source you hadn't anticipated (a Debian CD of all things) and install it without your permission." Okay, I give up: which argument are promoting? Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On 02-Dec-04, 08:28 (CST), Fernanda Giroleti Weiden <[EMAIL PROTECTED]> wrote: > Hi all, > > Em Qui, 2004-12-02 ??s 07:46, Tollef Fog Heen escreveu: > > * Helen Faulkner > > > > | Pornography is widely regarded as being demeaning and insulting to women. > > > > - A lot of people don't think the cartoon is pornography. > > A lot of men don't think the cartoon is pornography. A lot of women don't think the cartoon is pornography, either. (Okay, my sample of 3 is small. But none of them considered pornography. Two voted for "silly, possibly amusing for a short while", the other "kind of stupid".) Amazingly, not all women believe that any depiction of the naked human body is automatically pornography and offensive. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Thu, Dec 02, 2004 at 06:09:14PM -0600, Manoj Srivastava wrote: > On Thu, 2 Dec 2004 16:39:47 -0500, William Ballard <[EMAIL PROTECTED]> said: > > The Bible's in there because some people like it. The Bible should > > be in Debian. But the Koran, the Torah, and the Vishnu texts (name > > escapes me at the moment) should all be in there too. > > They're all equally true or equally false. > Why? Why should one not be true and the others false? Why > can't there really be one true religion? Because he's an idiot. Can we move on to something on-topic? ObRC: #283818 -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On 03-Dec-04, 07:52 (CST), Russell Coker <[EMAIL PROTECTED]> wrote: > > Why can't art be pornographic and porn be artistic anyway? > I think the very definition of "pornography" (in the US, at least) denies this possibility. If it's art, then it's "erotic", not "pornography". "Nitpickers R Us", Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Finding an improved release process.
On Fri, Dec 03, 2004 at 11:52:08PM +0100, Eduard Bloch wrote: > From my point of view, we could have released Sarge one year after Woody > with boot-floppies. The only thing needed was a bit more man power from > the porters. Instead, most of the "core team" and the BFs porters > stopped to work on it. And without manpower (motivated people), there > will be no development. Well, y'know, if they weren't willing to work on it, we can't exactly twist their arms, can we? Regardless of the reason, if there were an insufficient number of people willing to work on b-f, the reality is that we *couldn't* have released that way. If you were unwilling or unable to do the work yourself, and no one was willing to give you the help you needed, then to say we could have released "from your point of view" misses the big picture. > OTOH many new people jumped into the boat following the ideas of having > a cool, fresh-fashioned installer. IMO (only IMO) most of them had bad > memories about their first Debian install so they doomed BFs without > any closer look at the source. Speaking for myself, I had looked at the boot floppies source not too long after woody's release, to try to include an updated kernel for my employer. I found BF's monolithic structure difficult to grok, and time-consuming to manipulate; I believe in the end it was not worth the time for me to follow through on the project, instead muddling along with the stock installer and manipulating the kernel on each server post-install. In contrast, d-i's structure made it very easy to start hacking on, to the point that at the end of last year I had put together an XFS-capable install CD using a separate kernel in the space of a few weeks, and then (as someone who had never been part of a porter team) went on to write about 90% of the alpha-specific code for sarge d-i. I couldn't imagine myself doing the same for BF; and if I did, I'm afraid I have to say I think I would have enjoyed it much less. However good the code might have been in BF, the positive knowledge transfer and shallow learning curve that come from using a package-based design like d-i do have an effect on its accessibility to outside contributions; and when the primary blocker for BF was that people weren't helping, well... > Well, the outcome of d-i development is good, but not that impressive > (no GUI, no jumping penguins, confusing partitioner tool). Sometimes > they have made the same errors we did with BFs, sometimes new things > have been invented. I can agree with you that d-i is not perfect, and yes, you've pointed out two of the sarge installer's most notable weaknesses (I don't know anything about jumping penguins, though :). OTOH, I've also seen comments like "the sarge installer is the best Open Source installer ever" and "definitely easier to install than Windows XP", so clearly *some* users are impressed; and considering even the most fervent Debian advocates have always regarded the installer as a weakness, I think that's saying something... -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On 05-Dec-04, 04:55 (CST), James Foster <[EMAIL PROTECTED]> wrote: > > There's no excuse for censorship, ever. > Okay everybody, repeat after me: Choosing not to distribute a given package is NOT censorship. We are not telling people that they can't install, use, and/or distribute the package, just that we don't care to make it available as an official Debian package from our servers. This is not a subtle difference. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On 05-Dec-04, 09:07 (CST), Andrew Suffield <[EMAIL PROTECTED]> wrote: > On Sun, Dec 05, 2004 at 08:45:56AM -0600, Steve Greenland wrote: > > On 05-Dec-04, 04:55 (CST), James Foster <[EMAIL PROTECTED]> wrote: > > > > > > There's no excuse for censorship, ever. > > > > > > > Okay everybody, repeat after me: Choosing not to distribute a given > > package is NOT censorship. > > And telling somebody else that they can't distribute a given package > IS censorship. I haven't told anyone that they can't distribute it. We, Debian, can choose not to distribute certain materials w/o it being censorship. My local library does not buy and circulate every single book that comes on the market. That's not censorship. They have limited resources, and thus must make choices. Making those choices probably includes questions like "Is circulating work 'X' likely to cause so much uproar and distraction that it actually detracts from acheiving our overall goals?" > You evidently have chosen not to do it. That's not censorship. You're > presumably also trying to tell somebody else not to do it. That's > censorship. Actually, I've been arguing in favor of including hot-babe. However, I'd like to be able to have this debate w/o abusing words like "censorship" and "pornography", neither of which apply to this situation. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Sun, Dec 05, 2004 at 09:35:52PM +0100, Jonas Meurer wrote: > On 05/12/2004 Wouter Verhelst wrote: > > > you may run into big troubles if you tolerate a violent ideology - it's > > > no longer about thoughts but more about brutality. > > > > Not if you're merely voicing those thoughts. > sure, voicing those thoughts without practicing them is not the problem. > but (to come closer to the original topic) at least abusing female > humans as sex objects and using the photographs as exciter is about > practicing the thoughts. and please don't tell me that just providing > them is not the same as using them: they are only provided to be used > this way! Reality check: *there are no photographs of women in this thread*. ObRC: 282347 -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bug#283994: ITP: glastree -- builds live backup trees, with branches for each day
On Mon, Dec 06, 2004 at 01:24:32AM -0600, Manoj Srivastava wrote: > On Fri, 3 Dec 2004 13:49:44 +1100, Matthew Palmer <[EMAIL PROTECTED]> said: > >> > >> The advantage of using glastree over pdumpfs is that it is > >> implemented in Perl rather than Ruby (this is in fact the reason > >> that I encountered it in the first place). > > How is that an advantage of use? > Well, for me, were I to try to hack ti to improve it, being in > Perl is distinct advantage since I am far more proficient in Perl > than in Ruby. That's reasonable, but I'm not sure it should have much bearing on whether to package something. We're talking about backup tools, not code libraries for language X; the principal use of the package is as a tool you run, and if it's a good package, you (as a user rather than as a maintainer) shouldn't need to write code in any language, let alone any *particular* language. You as a user don't get to edit the package anyway; if you're customizing the package locally, it doesn't really matter if Debian distributes it. If there are known deficiencies in the packages attempting to fill this niche, *then* it makes sense to start talking about other options (filing bug reports, submitting patches, or writing/ITPing a replacement). And sure, language choice can make a difference in the install size in embedded systems and thus count as a "deficiency", but that doesn't seem to be your point here. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
On Mon, Dec 06, 2004 at 10:01:16AM +, Andrew Suffield wrote: > > > > Actually, the developer is choosing to have Debian distribute a > > > > package, and > > > > others are trying to stop Debian from distributing the package. > > > Word games. Censorship is when a citizen of one body chooses to have > > > that body distribute something (by being a citizen and distributing > > > it), and another citizen tries to stop them. > > Gah! Book publishers do not publish every manuscript that is sent > > to them. Movie studios do not fund every screenplay sent to them. > > Libraries, as has been mentioned before, don't buy every book. > You seem to be suggesting that any case where an organisation doesn't > publish something is not censorship. That's obviously wrong, because > some of them *are* censorship. > > Such choices are made *all the time*. It's the difference between > > "editing" and "censoring". > The difference being that editing is a choice made by the person doing > the work, while censorship is a choice made by an otherwise unrelated > person in the same organisation. > Editing would be if the maintainer decided to remove the > package. Censorship is when some other developer tries to force him. If an ftp-master in the course of "doing the work" of processing NEW rejects a package, or a member of the release team in the course of "doing the work" of preparing the next stable release excludes a package from consideration, is this editing, or is it censorship? If they do so for legal reasons? If they do so for technical reasons? If they do so because, in their estimation, doing so improves the quality of the distribution? Publishing houses never let writers edit their own work -- at least until they're famous and have mindless followers who'll buy and read any formulaic tripe they slap together. I don't think I like the idea of Debian becoming the Stephen King of the Open Source world. It's extremely frustrating to see so many words spent on the notion of "censorship" here. At the end of the day, Debian, *as an organization*, has the right (and responsibility) to decide what it publishes on behalf of its member developers, and doing so is *not* *censorship*. Even if that happens to mean adopting policies that some significant minority fraction of the developership disagrees with. It's no wonder that Debian has a hard time reaching any sort of consensus these days when we have developers who are happy as a pig in mud to argue ad infinitum about whether the project has a right to *exercise* consensus. And it's no wonder that Debian is slow to release when people are criticized on public lists for showing an interest in the contents and quality of packages that aren't theirs; for daring to ask the question, "is this something that Debian needs?" I've seen people make comments in this thread that hot-babe is just one more package among thousands, and that uploading it doesn't mean integrating it with the OS. I think this attitude lies at the heart of one of Debian's biggest problems today, namely that far too many developers seem to look on Debian as nothing more than a package pool instead of as an OS. I'm sorry, but "package pool" has been done before -- it's called rpmfind.net, I've lived it, and it sucked. That's not what I'm after as a member of this project, and I hope it's not what most other developers are after either, but making an OS instead of a package pool takes developers who are willing to look at issues outside the narrow confines of their own packages. It means looking precisely *towards* questions of better integration between packages, to provide something cohesively whole. Sometimes, it means asking yourself that hard question, "does my pet package, the 24th app in class foo, make Debian a better OS, or is there some other way I could be contributing that would improve the quality of Debian for everyone?" This discussion shouldn't be about censorship, or other forms of coercion; no one with anything remotely resembling the power to do so has actually suggested suppressing this package. It shouldn't be about legality; there's scant little evidence that cartoon drawings of naked breasts are illegal in any jurisdiction where Debian wouldn't already have serious problems. What it *should* be about is moving towards a consensus, *together with the maintainer*[1], about what we want Debian to be. And contrary to much of the rhetoric in this thread, it is possible to think a package like hot-babe is a bad idea without wanting to be set up as a censor for all ideas they disagree with. ObRC: 283476 -- Steve Langasek postmodern programmer [1] Did anyone else notice that none of the people carrying on in this thread is the ITPer, and very few of the messages are actually addressed towards him? signature.asc Description: Digital signature
Re: charsets in debian/control
On Mon, Dec 06, 2004 at 06:58:10PM +, Thaddeus H. Black wrote: > I would not disagree with Peter or Daniel. They are > right in my view. However, consider the following > Unicode characters: > 025A LATIN SMALL LETTER SCHWA WITH HOOK > 025E LATIN SMALL LETTER CLOSED REVERSED OPEN E > 0261 LATIN SMALL LETTER SCRIPT G > 0264 LATIN SMALL LETTER RAMS HORN > 0267 LATIN SMALL LETTER HENG WITH HOOK > 027A LATIN SMALL LETTER TURNED R WITH LONG LEG > 027F LATIN SMALL LETTER REVERSED R WITH FISHHOOK > 0285 LATIN SMALL LETTER SQUAT REVERSED ESH > 0295 LATIN LETTER PHARYNGEAL VOICED FRICATIVE > 02A2 LATIN LETTER REVERSED GLOTTAL STOP WITH STROKE > FF21 FULLWIDTH LATIN CAPITAL LETTER A > We are not speaking of a stricken Polish L, a > double-accented Magyar O, or a euro sign. Indeed we're not; most of the letters you listed here are specific to the IPA, which would have no use at all in a control file as they're not part of the writing system of any natural language. Encodings and charsets are distinct concepts. Just because the file is specified in UTF-8 *encoding* does not mean we suddenly have to start coping with the entire Unicode character set. OTOH, the Unicode charset is also the only one we have that is a superset of iso8859-1, iso8859-2, and iso8859-15, so if you want to be able to *use* the Å, the â, and the Å in the same file together with à and Ã, the only sensible way to do so is to specify a UTF-8 encoding. > We are speaking of... well, to tell the truth I have no idea what these > letters are. Have you? More to the point, should you and I learn to > recognize such letters? Should we expect basic Latin terminal fonts to > cover them? Is it reasonable to marginalize the ?'s and ?'s of Latin-1 > by lumping them with the "squat reversed esh"? Why, what a lovely straw man you have there. But yes, non-ASCII Latin-1 chars should not be given special status over the national chars found in other languages spoken by project members. Debian should be using either ASCII, or Unicode; standardizing on Latin-1 makes no sense in a global project. > In my view, a terminal which cannot correctly display > the "?" is somewhat broken, and a user who does not > recognize the "?" probably should learn. I would not > say the same with respect to the "squat reversed esh". > However, this is just my view. Mmm-hmm. > Content-Type: text/plain; charset=unknown-8bit Your opinion about which charset to use for Debian files would carry more weight with me if you had enough experience with such things to properly declare the character set on the non-ASCII mails you send. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: charsets in debian/control
On Tue, Dec 07, 2004 at 12:04:56PM +0900, Mike Hommey wrote: > On Mon, Dec 06, 2004 at 06:53:42PM -0800, Steve Langasek <[EMAIL PROTECTED]> > wrote: > > But yes, non-ASCII Latin-1 chars should not be given special status over > > the national chars found in other languages spoken by project members. > > Debian should be using either ASCII, or Unicode; standardizing on Latin-1 > > makes no sense in a global project. > Actually Latin-9 would be better, it doesn't contain the useless ¤. Standardizing on any 8-bit character set makes no sense in a global project. :P -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
On Tue, Dec 07, 2004 at 11:17:46AM -0300, Fabricio Cannini wrote: > --- Michelle Konzack <[EMAIL PROTECTED]> > escreveu: > > Am 2004-12-07 10:39:42, schrieb Fabricio Cannini: > > > Me wonders if simply NOT installing hot-babe > > > wouldn't fix this. > > > IMO Seems to be the easiest solution. > > In theory ! In many countries it is illegal > > to have some stuff on CD or other Media. > > > Don't put it on the CD!! > > And WHO stores the CD-Images ? > Servers located on coutries that do not have such > prohibitions would store these packages. > I'm talking about NOT putting such packages > in the official medias (CDs, .iso, etc). I don't think this is a very useful compromise. If a package is going to be included in the Debian archive, it should also be included in the official Debian CD sets. I think it's a good idea to provide enough metadata in the archive to let people build localized CD sets that are legal in their jurisdiction, but I don't think we should be excluding any Debian packages from official CD sets -- if there are reasons that we can't distribute a package in main as part of our CD images, we shouldn't be distributing it from the mirrors either. ObRC: #245810 -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: charsets in debian/control
On Tue, Dec 07, 2004 at 05:56:54PM +, Thaddeus H. Black wrote: > > But yes, non-ASCII Latin-1 chars should not be given > > special status over the national chars found in other > > languages spoken by project members. Debian should be > > using either ASCII, or Unicode; standardizing on > > Latin-1 makes no sense in a global project. > True. Look, Steve: mild abuse aside, I agree with you > in every particular. Nevertheless, I would respectfully > suggest that your criticism underscores my point, which > regards the monstrous increase in complexity which the > full Unicode standard represents. Yet you had concluded this means we should use Latin-1 as an encoding for the files. All arguments that justify the use of Latin-1 characters in the control file are equally applicable to any of a number of other national character sets used by one or more developers. > Consider. Is it a bug if Readline cannot echo full bidirectional input? Er, yes, sure it is, independently of what happens in debian/control. > If Dselect does not appreciate all the non-spacing > characters? IFF dselect has a reason to display such characters, yes. This may well be the case regardless of whether debian/control ever supports non-ASCII characters; Debian may start supporting localized Packages files via some external mechanism, or it may provide a localized UI that requires these characters. > If Less does not regard Tibetan subjoined letters? (This is my Tibetan > straw man.) Yes, this is also a bug. Not one that's likely to be noticed for a while, but a bug nevertheless. But your example again overstates the complexity of the task: the main responsibility of less is to figure out how many characters to display on a line, and let the *terminal* render the glyphs. This is code that needs to be implemented only once, and most of the work is already done centrally for *all* apps by glibc which keeps track of the display width of each character. > Undoubtedly one might observe that the Tibetan problem > were not really a problem with Less but rather with some > underlying library, but this misses the point---or > rather again it underscores the point. Unicode solves > what for many of us was not a problem by creating an > entirely new class of problems. For example, it > requires us to be particular about how we tag our e-mail > attachments... Um, no. Being part of a *global Internet* causes this problem for you. The non-ASCII characters in your email were undefined gibberish according to your headers; only naive (or "helpful", YMMV) mail readers would render them at all, and only naive mail readers commanded by users using a Western European locale would have rendered them as intended. Actually, perhaps even that is being too generous, as there are *different* native 8-bit encodings used on each of Unix, Windows, and MacOS; the Unix and Windows encodings differ on relatively few codepoints, but the Mac encoding is widely different. And you think it's ok to inflict this same mess on anyone not using a Latin-1 locale while trying to read a debian/control file? > Am I arguing to jettison Unicode? No; to the partial > extent that I had been arguing it earlier in the thread, > you, Peter, Daniel and Matthew have changed my mind. > However, the typical roster of skills one masters in > contributing broadly to Debian development is already > awesome: C, C++, CPP, Make, Perl, Python, Autoconf, CVS, > Shell, Glibc, System calls, /proc, IPC, sockets, Sed, > Awk, Vi, Emacs, locales, Libdb, GnuPG, Readline, > Ncurses, TeX, Postscript, Groff, XML, assembly, Flex, > Bison, ORB, Lisp, Dpkg, PAM, Xlibs, Tk, GTK, SysVInit, > Debconf, ELF, etc.---not to mention the use of the > English language at a sophisticated technical level. > UTF-8 is neat, but I do not really like Unicode (you may > have noticed this). Seeking essential simplicity, I > would prefer to keep the full hairy overgrown Unicode > standard from the typical Debian roster of development > skills. Wouldn't you? 1) Sorry, modern software is a complex creature. This is because we demand complex things of it -- including handling all the languages that we speak. 2) Most DDs do not master all of the above skills. *I* don't have a mastery of all of the above skills; "contributing broadly to Debian" usually means mastering some of these skills, and knowing where to find answers for the rest. 3) "Mastering Unicode", for the purposes of almost anyone not working directly on glibc or implementing a terminal, is roughly equivalent to "making sure your application implements proper string handling for CJK". If you do it right, the differences between UTF-8 and ISO-2022 are normally minimal; if you do it wrong, you get bug reports from Japanese users. However, for files
Re: Status of this ITP?
On 08-Dec-04, 11:15 (CST), "Luis R. Rodriguez" <[EMAIL PROTECTED]> wrote: > Its been more than a year now. What's the status of this ITP? > This is ridiculous. If you can't package it, then say so so others can > come in and do the job. We deserve a freedesktop.org package by now in > debian. If you're going to CC debian-devel, at least have the courtesy to mention what the hell you're babbling about, instead of forcing us to go look up the bug number. > Get off your ass. Ah. I see. Courtesy is not your strong point. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Linux Core Consortium
On Wed, Dec 08, 2004 at 02:59:10PM -0800, Bruce Perens wrote: > The main technical effect that I see would be that the names of some > dynamic libraries would change. And compatibility with the old names > could be maintained indefinitely if necessary. How in the world does changing the names of core system libraries serve the technical goal of providing better *compatibility* between distros? Indeed, how could this be anything other than a gratuitous change? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Linux Core Consortium
Bruce, On Wed, Dec 08, 2004 at 04:49:13PM -0800, Bruce Perens wrote: > Henrique answered your question. There has been some divergence between > various distributions regarding the naming and especially the versioning > of these libraries. We would heal that fork to increase compatibility. > Doing that means that some names and version tags are going to change > for some people. Of course we want to see everyone involved bearing some > of that load, rather than Debian bearing the lion's share of it. Requiring us to ship/link against a particular soversion of a library is one thing; Debian copes with changes to upstream soversions on a regular basis. Changing library *names*, OTOH, is something quite different -- and in the first case, providing "compatibility with the old names" totally defeats the purpose of *having* sonames, whereas in the second case, it still sounds like gratuitous change to me. I'm skeptical to begin with of the benefits LCC has to offer Debian -- being bound not just to an external *standard*, but to an external *implementation* requires sacrificing autonomy in areas that have been historically important to Debian, such as timely security fixes and arch-specific fixes for architectures not covered by the LCC -- and the wording from your original message set off a very large red flag for me besides. Can you provide pointers to concrete LCC proposals of library renames, so that I can get comfortable with the technical specifics of what's really at issue here? Thanks, -- Steve Langasek postmodern programmer > >On Wed, 08 Dec 2004, Steve Langasek wrote: > > > > > >>How in the world does changing the names of core system libraries serve > >>the > >>technical goal of providing better *compatibility* between distros? > >>Indeed, > >>how could this be anything other than a gratuitous change? > >> > >> > > >Henrique de Moraes Holschuh wrote: > >Good question. OTOH, getting all of us to use a common naming *AND > >VERSIONED > >SYMBOL TAGS* for everything is a worthy goal. If this project will help > >with that... > > > > > > > signature.asc Description: Digital signature
Re: Linux Core Consortium
On Fri, Dec 10, 2004 at 12:50:13PM +0100, Michael Banck wrote: > *** The interested parties of the LCC should pick Debian as a base and > Debian should make this possible. *** > Rather than everybody just throwing all their stuff in together and > mixing it up. > Of course, this would also mean for Debian to change. Debian is free > and solid today, but not predictable. Thus: > * We should commit to strict release cylces of a base system others >(and Debian itself) can build value upon. This seems to be the same definition of "commit" as in "Novell is committed both to providing customers with standardized Linux technology and to simplifying ISVs' and IHVs' Linux certification efforts."[1] that is, to quote Hamlet, "words, words... words." While it might make a good April Fool's joke to ask Novell and Red Hat to standardize on Debian, we don't exactly have a strong history of being able to pull off timely releases, and it would be a true fool who today would bank on future Debian release schedules before we've demonstrated that time-based releases are organizationally possible for us. > * We should proabably also commit to a set of core architectures which >*need* to be bug-free on release, while the rest *should* be, but >would not delay the release. Er, what would be the point of making a stable release for an architecture if we know that it's broken? But perhaps you meant that the architectures would be dropped from the release. > * We should look into having a reality-check with respect to licensing >and the way we treat each other. This wording seems to imply a particular outcome of any licensing "reality check". Perhaps you meant to post it to one of the many easy-to-find DFSG flamewars in Debian's recent history, instead of to a thread discussing LCC's significance to Debian. -- Steve Langasek postmodern programmer [1] http://linux.about.com/b/a/129063.htm signature.asc Description: Digital signature
Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1
On Fri, Dec 10, 2004 at 02:45:17PM +0100, Michael Banck wrote: > On Fri, Dec 10, 2004 at 01:49:33PM +0100, Frank Küster wrote: > > > I'm sorry the NMU annoyed you but I welcome it. There is nothing worse > > > than a package that kills buildds, esspecially such a common one. > > I agree. But still LaMont should have expressed his intent to do so, and > > send the patch to the BTS. I don't have a problem with being NMUed, but > > with NMUs prepared improperly. > At this point, any RC bug in an important (as in for the release, not > priority-wise) package is an implicit express to be NMUd, at any time. > Deal with it, we want to release. > One could argue about sending the NMU-patch/interdiff to the BTS, but I > personally do not see much point in it, since (hi Omnic!) you can just > get it from the archive and sync it yourself. It still makes sense for > packages where you suspect the maintainer to be inactive/not willing to > deal with this or (as is the case here apparently) already working on a > new revision. I don't see how this should be a point of contention at all; the requirement that diffs from NMUs be posted to the BTS has been explicit for a very long time. It is the responsibility of the NMUer to ensure that the diffs are delivered to the maintainer for inspection via the BTS. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Linux Core Consortium
On Thu, Dec 09, 2004 at 03:39:55PM -0500, Ian Murdock wrote: > You've just described the way the LSB has done it for years, which thus > far, hasn't worked--while there are numerous LSB-certified distros, > there are exactly zero LSB-certified applications. The reason for this > is that "substantially the same" isn't good enough--ISVs want *exactly > the same*, and there's a good reason for that, as evidenced by the fact > that while Debian is technically (very nearly) LSB compliant, there are > still a lot of edge cases like file system and package namespace > differences that fall outside the LSB that vastly complicate the > "certify to an ABI, then support all distros that implement > the ABI as defined by whether or not it passes a test kit" model. Well, my first question is why, irrespective of how valuable the LSB itself is to them, any ISV would choose to get their apps "LSB certified". The benefits of having one's distro LSB certified are clear, but what does an LSB certification give an ISV that their own internal testing can't? Or do you really mean there are no ISVs *writing* to the LSB? Secondly, is this merely conjecture about the needs of ISVs, or have you (or someone else involved with the LCC) actually talked to people who've said these things? If this initiative is truly a response to the needs of ISVs, it should be fairly easy to publically specify the LCC's scope up front so that Debian can decide whether there's any sense in trying to get involved. The fact that ISVs would be interested in package namespace differences at all worries me; it suggests to me that either the scope of the LSB simply needs to be broadened to meet their needs, or these ISVs are not in tune with the goals of the LSB as it is, and no amount of harmonizing package namespaces will address their real concerns. > I'm not knocking the LSB--by definition, the LSB codifies existing > standards, i.e., things everyone already agree with. The things > we're talking about here (package naming differences, network > configuration differences, all that) are clearly points of disagreement > between distributions (perhaps backed more by inertia than by anything > else). The LCC aims to complement the LSB by agreeing on a single set of > solutions for these edge cases, then by putting the necessary glue in > place to make sure whatever inertia or otherwise has propagated > the differences for so long doesn't remain an insurmountable obstacle. > And with enough mass, the edge cases become "stuff we agree on". Um, what's the concrete use case for a cross-distro standard network configuration interface? These are starting to sound like ISVs I don't *want* touching my Debian systems... -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Pre-Depends on emacs21? Re: cedet-common: breaks other packages in batch mode
Bug #270388 regards the cedet-common package breaking emacs -batch. A proposed fix in the bug report is for cedet-common to Pre-Depend on emacs21 | emacsen instead of depending on it. An NMU based on this proposed fix has already been uploaded to the DELAYED queue by Henning Glawe without first discussing on debian-devel as required by policy. I'm therefore posting this message to get a reasonable set of eyeballs on this issue. For my part, I think a Pre-Depends here is crude and inappropriate, as other comments in the log suggest to me that this is a remediable bug in cedet-common's startup code; but I haven't dug into it far enough to say for sure. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bug#285234: ITP: unlzx -- unarchiver for *.lzx archives
On Sat, Dec 11, 2004 at 04:37:01PM -0600, Graham Wilson wrote: > On Sat, Dec 11, 2004 at 10:53:10PM +0100, Marcin Orlowski wrote: > > Package: wnpp > > Severity: wishlist > > > > * Package name: unlzx > > Version : x.y.z > > Upstream Author : Name <[EMAIL PROTECTED]> > > * URL : http://ftp.uni-paderborn.de/aminetbin/find?unlzx > > * License : (GPL, LGPL, BSD, MIT/X, etc.) > > Description : unarchiver for *.lzx archives > > How can so many people fail to fill in all of the fields in reportbug's > ITP template? Is there some way to make it more clear, or are people > just lazy? Maybe patching reportbug to complain if an ITP doesn't have some of its fields changed from the defaults would be a good idea? Steve --
Re: dselect survey
On Sun, Dec 12, 2004 at 11:35:22AM +1100, Paul Hampson wrote: > apt-get and apt-cache are my friends, and I love them for letting me > specify what I want to do in a way that is intuitive to me. Altough I > wish I could tab-complete package names sometimes. ^_^ If you're running bash you can source the file /etc/bash_completion This gives you tab completion on a lot of commands. For example: apt-get install kernel-image- apt-get upg also does the right thing for example... This can be setup globally if you uncomment the relevent lines in /etc/bash.bashrc. Steve --
Re: On the freeness of a BLOB-containing driver
Bruce Perens wrote: > >A good hardware design would put this code in FLASH on the board. Depends on what you mean by a "good hardware design". For example, a lot of the USB dongles becoming common would be significantly bigger and/or more expensive if they had to have sufficient space on-board for a complete firmware implementation. As cost and size can be _everything_ on these devices, downloading firmware each time they are started/connected can actually be a good design choice. >If you don't have a good hardware design, BLOBs belong in files, not >the driver. The 2.6 kernel boots up with at least initramfs >accessable to it, and later initrd, if it needs a BLOB it should load >it from there. Agreed on this bit. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Re: dselect survey
On 10-Dec-04, 17:02 (CST), Florent Rougon <[EMAIL PROTECTED]> wrote: > Bernd Eckenfels <[EMAIL PROTECTED]> wrote: > > > No, it is because the shortcuts are completely non-intuitive. I use > > aptitude for the good intuitive keymapping, not for its menu. > > I see. You find them utterly unintuitive, and are not alone. I don't > claim they are really "intuitive" (for what it means...), "non-intuitive" == "almost, but not quite, completely unlike any other curses-type interface available at the time." Which is not to say it wasn't learnable, and I used it from initial release: It was way better than having to download stuff by hand. But I sure wouldn't recommend it to a new user. Which, of course, isn't to say that it should be removed. I was surprised by how many people still use it; I hope some one will pick it up. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Linux Core Consortium
On Mon, Dec 13, 2004 at 05:07:12PM -0500, Ian Murdock wrote: > On Sat, 2004-12-11 at 03:49 -0800, Steve Langasek wrote: > > On Thu, Dec 09, 2004 at 03:39:55PM -0500, Ian Murdock wrote: > > > You've just described the way the LSB has done it for years, which thus > > > far, hasn't worked--while there are numerous LSB-certified distros, > > > there are exactly zero LSB-certified applications. The reason for this > > > is that "substantially the same" isn't good enough--ISVs want *exactly > > > the same*, and there's a good reason for that, as evidenced by the fact > > > that while Debian is technically (very nearly) LSB compliant, there are > > > still a lot of edge cases like file system and package namespace > > > differences that fall outside the LSB that vastly complicate the > > > "certify to an ABI, then support all distros that implement > > > the ABI as defined by whether or not it passes a test kit" model. > > Well, my first question is why, irrespective of how valuable the LSB itself > > is to them, any ISV would choose to get their apps "LSB certified". The > > benefits of having one's distro LSB certified are clear, but what does an > > LSB certification give an ISV that their own internal testing can't? > In an ideal world, ISVs could certify once, to the LSB, and their > applications would run the same on every LSB-certified distro. This > dramatically reduces the amount of internal distro-specific work > each has to do. The stronger the LSB, the closer the distro-specific > work is to zero, and the closer they get to a single Linux port. That wasn't my question. My question was, why should any ISV care if their product has been LSB-*certified*? ISVs can test against, and advertise support for, whatever they want to without getting the LSB's imprimatur. I cannot fathom why any ISV would go through the expense (money or time) of getting some sort of LSB certification instead of simply making this part of their in-house product QA; and therefore I don't see how the absence of LSB-certified applications can be regarded as a failure of the LSB process. > > Secondly, is this merely conjecture about the needs of ISVs, or have you (or > > someone else involved with the LCC) actually talked to people who've said > > these things? If this initiative is truly a response to the needs of ISVs, > > it should be fairly easy to publically specify the LCC's scope up front so > > that Debian can decide whether there's any sense in trying to get involved. > We have absolutely been talking to ISVs about their needs--indeed, this > has been a conversation that has been ongoing for years.. > What about the LCC's scope isn't clear? Er, the fact that no actual scope has been stated? What does "core" mean? What packages (libraries) are included in this "core"? If Debian is not going to accept external binaries provided by the LCC into the archive, or finds it necessary to patch the source during the course of a release, does this mean Debian will not be a certified platform? If so, and given that these are very likely outcomes, what reason remains for Debian to get involved in the LCC if it's not going to result in any ISVs supporting Debian as a platform through the LCC effort? (If you see ways that Progeny would benefit from Debian's involvement in the LCC even if the official Debian releases are not LCC-certified in the end, I think that's relevant here; but I would like to know how you think it would benefit Progeny and other companies building on Debian, and why you think that Debian itself warrants representation at the table.) I don't think any of the above questions are ones to be hashed out by the distros participating in the LCC. If the impetus for the LCC really comes from ISVs, then the answers to these questions must be *their* answers; and if we don't have those answers, inter-distro talks would be aimless and futile. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bug#285625: ITP: expocity -- An enanced Window Manager based on metacity
On Tue, Dec 14, 2004 at 04:43:11PM +0100, Christian Surchi wrote: > > == > > Date: Tue, 14 Dec 2004 16:33:43 +0100 > > From: martin f krafft <[EMAIL PROTECTED]> > > To: debian-devel@lists.debian.org > > Subject: Re: Bug#285625: ITP: expocity -- An enanced Window Manager > > based on metacity > > == > > > > enlighten us non-Darwinists: what does Expos? do? How does this > > differ from tabs as provided e.g. by fluxbox. > > http://www.apple.com/macosx/features/expose/ If you want to do something like this it seems more practical to make it available to all window managers. The package 'skippy' was recently mentioned on debian-mentors[1], and can be found here: [Upstream] http://thegraveyard.org/skippy.php [Initial packages] http://cxhome.ath.cx/debian/skippy/ It works nicely with my IceWM environment, and I'd love to see it uploaded... Steve -- # Debian Administration Tips www.debian-administration.org [1] http://lists.debian.org/debian-mentors/2004/12/msg00135.html
Re: Linux Core Consortium
On Tue, Dec 14, 2004 at 11:53:54AM -0500, Ian Murdock wrote: > > > What about the LCC's scope isn't clear? > > Er, the fact that no actual scope has been stated? What does "core" mean? > > What packages (libraries) are included in this "core"? > "Core" means "implemention of LSB", and the packages/libraries that will > constitute that are being determined now, as a collaborative process. Well, for instance, the libacl package was brought up as an example in the context of changing library SONAMEs/package names. The current LSB has nothing to say about this library; it covers only glibc, libstdc++, various core X libraries, zlib, libpam, libgcc, and ncurses. So there was some doubt in my mind as to how broad a "core" ISVs were actually demanding be specified, as well as doubt regarding the conclusion that the LSB process was flawed if the simple fact was that ISVs were demanding standardization of libraries that no one has asked the LSB to address. I still think "implementation of the LSB" is a murky concept; the LSB specifies very little about kernel behavior after all (though some things are implicit given the description of libc ABIs plus the de facto glibc implementation of them), so I don't know whether and how many userspace tools it's also seen as essential to cover. > I assumed Debian would want to be involved in this process too, rather > than being presented with a more well-defined scope as a fait accompli.. Particularly considering involvement in the LCC would require essentially unanimous consent of the maintainers of the covered core packages, I think it's impossible for Debian to be meaningfully involved without first having a clear understanding of what would be expected of us -- especially when late bouts of scope creep could hamstring the entire effort by suddenly requiring the consent of a new package maintainer who doesn't approve! I think it's better if this can all be laid out up front so we can get a clear yea or nay from the affected maintainers before sending people off to committee. > > If so, and given that > > these are very likely outcomes, what reason remains for Debian to get > > involved in the LCC if it's not going to result in any ISVs supporting > > Debian as a platform through the LCC effort? > At the very least, the differences would be smaller than they > otherwise would be, and that can only be a good thing for > LCC, Debian, and the Linux world as a whole. On the contrary, I think that providing a single binary platform representing an overwhelming majority of the Linux market share that ISVs can write to, rather than enforcing the rigors of writing to an open standard such as the LSB, makes it much more likely for ISVs to demand bug-for-bug compatibility with the LCC binaries; which means that anyone not using the certified binaries is just that much farther up the proverbial creek. Keeping the differences small is only a benefit if ISVs do choose to test against Debian as well as against the LCC. > And, who knows, with Debian participation, perhaps the differences would > end up being small enough and the processes, methods, and > mechanisms defined such that it's no longer a "very likely outcome". I think that accepting outside binaries for core packages would be regarded by many in the community as devastating to Debian's security model. I think that requiring immutable sources for core packages would be equally devastating to Debian's development model. > > (If you see ways that Progeny > > would benefit from Debian's involvement in the LCC even if the official > > Debian releases are not LCC-certified in the end, I think that's relevant > > here; but I would like to know how you think it would benefit Progeny and > > other companies building on Debian, and why you think that Debian itself > > warrants representation at the table.) > As I said at the very outset, one possible way forward is to simply > produce a Debian-packaged version of the LCC core independently, > and to make sure that core is 100% compatible with Debian (i.e., you > can take any Debian package and install it on the LCC Debian core > and get the same results as if you'd installed it on Debian itself). I would prefer to take this a step further in the opposite direction. Given that the LSB specifies a determined linker path as part of its ABI other than the one used by the toolchain by default, and given that the kernel is largely an independent, drop-in replacement wrt the rest of the packaging system, why *couldn't* we provide the LCC binaries in the same fashion as the current lsb package -- as a compatibility layer on top of the existing Debian system? This sidesteps the problem of losing certification over small divergences that significantly impact our other ports and is a much more tractable goal, while still giving us a target to aim for with our base system. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: installing a source tree?
On Wed, Dec 15, 2004 at 12:01:24PM -0500, Chasecreek Systemhouse wrote: > So, I humbly request suggestions or hints as to a direction I can > follow to be able to get the source cod and development tree (READ Not > CVS Tree) of say package PostgresSQL. > > I have tried variations of - > apt-get install postgresql-source > > as well as variations of - > apt-get build-dep [package] > apt-get source --compile [package] > > However the other package cannot find the PostgresSQL source tree. First of all download the source which matches the package you have installed with: apt-get source postgresql Then you'll need to examine the software you're trying to build against it to see how it finds the source directory. Maybe there's a flag to use: ./configure --source=../postgresql.. Or similar. Honestly I'm suprised you need the full package source. Normally you'd just get the development packages to give you the header files and the libraries which are linked against. In your case that would be the stuff provided by the package 'postgresql-dev'. What's the name of the software you're trying to build? > I'm creating/documenting a quick Debian_Hints file at: > http://insecurity.org/ll3i11_j0n35/Debian_Hints Have you read many of the fine Debian manuals? There's a lot of good stuff linked to from: http://www.debian.org/doc/ Steve --
Re: If you really want Free firmware...
[EMAIL PROTECTED] wrote: >On Wed, Dec 15, 2004 at 05:00:12PM +, Andrew Suffield wrote: >> >> Ah, you misinterpreted my point in quite an impressive way. Valid >> numbers or not, his statement was of the form "Here is how we do it, >> and our way is the only way in which it is possible to do it". And >> we've heard that one before. > >I really don't care about the numbers. I don't actually even care about >this thread, especially now that Bruce and others have given us numbers >that make most of the discussion moot. What annoys me is your constant >pounding on other people's credibility, especially since you don't ever >seem to accept anyone else's criticism of your credibility. That's just Suffield being an annoying prick, as usual. Common consenus is that he's generally best ignored... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Re: Linux Core Consortium
On Wed, Dec 15, 2004 at 05:00:11PM -0800, Bruce Perens wrote: > Michael K. Edwards wrote: > >binutils and modutils both depend on it. > On flex? No. At least not in unstable. Yes, it does. $ apt-cache showsrc binutils Package: binutils Binary: binutils-hppa64, binutils, binutils-doc, binutils-dev, binutils-multiarch Version: 2.15-5 Priority: standard Section: devel Maintainer: James Troup <[EMAIL PROTECTED]> Build-Depends: autoconf (>= 2.13), bison, flex, gettext, texinfo, binutils (>= 2.9.5.0.12), gcc (>= 2.95.2-1), dejagnu (>= 1.4.2-1.1), expect (>= 5.32.2-1), dpatch, file Architecture: any Standards-Version: 3.6.1.0 Format: 1.0 Directory: pool/main/b/binutils Files: b20cf60b07384592ed5fa71314c6d2d9 1401 binutils_2.15-5.dsc ea140e23ae50a61a79902aa67da5214e 15134701 binutils_2.15.orig.tar.gz 055e74792e7118ddf33ae6b04d640818 38173 binutils_2.15-5.diff.gz $ > However, Debian seems to have addressed the issue by providing both > versions of flex. I don't see what would prevent us from going on with > that practice. > >Or is the LCC proposing to standardize on a set of binaries without > >specifying the toolchain that's used to reproduce them? > Linking and calling conventions should be standardized and should > survive for reasonably long. We need to know what we use to build the > packages, but we are not currently proposing to standardize development > tools on the target system. Not standardizing the toolchain used to build a set of standardized binaries would seem to leave the LCC open to a repeat of the gcc-2.96 fiasco, however... -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: RFC: common database policy/infrastracture
On 16-Dec-04, 08:04 (CST), Olaf van der Spek <[EMAIL PROTECTED]> wrote: > Take for example a web application like a forum. It requires the > password so it can connect to the database. It can't/won't ask the > password from the user. But there is (or at least, should be) a specific user for that forum application, with the minimum of rights needed for that application (e.g. SELECT and UPDATE) in a single specific database. You're talking about a DB *admin* password. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Problems to upload
On Fri, Dec 17, 2004 at 07:50:16AM +0100, Andreas Tille wrote: > $ dput *.changes > Uploading package to host ftp-master.debian.org > ... > Good signature on > /home/tillea/debian-maintain/sponsor/dosbox/dosbox_0.63-2.dsc. > Uploading via ftp dosbox_0.63-2.dsc: Error '553 Could not create file.' > during ftp transfer of dosbox_0.63-2.dsc > Traceback (most recent call last): > File "/usr/bin/dput", line 909, in ? > main() > File "/usr/bin/dput", line 858, in main > progress=config.getint(host,'progress_indicator')) > File "/usr/share/dput/ftp.py", line 54, in upload > f, 1024) > File "/usr/lib/python2.3/ftplib.py", line 415, in storbinary > conn = self.transfercmd(cmd) > File "/usr/lib/python2.3/ftplib.py", line 345, in transfercmd > return self.ntransfercmd(cmd, rest)[0] > File "/usr/lib/python2.3/ftplib.py", line 327, in ntransfercmd > resp = self.sendcmd(cmd) > File "/usr/lib/python2.3/ftplib.py", line 241, in sendcmd > return self.getresp() > File "/usr/lib/python2.3/ftplib.py", line 214, in getresp > raise error_perm, resp > ftplib.error_perm: 553 Could not create file. > When trying manual ftp I found out that dosbox_0.63-2.dsc was put to master > but with zero bytes and I'm not allowed to remove this file. See the dcut command (or the README file in UploadQueue) for information on how to remove broken files from the ftp server. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Are mails sent to xxxx buildd.debian.org sent to /dev/null ?
On Thu, Dec 16, 2004 at 11:10:15PM -0500, Joey Hess wrote: > Jay Berkenbilt wrote: > > I've sent messages to various [EMAIL PROTECTED] addresses many > > times for various reasons, and they have all always been ignored. > Me too, for values of ignored that include "may have resulted in some > action, but never got a reply email". > I think that we need BTS pseudo-packages for the autobuilders. I'm not sure that would help much; indeed, in the common case (package needs a simple requeue, buildd admin would have taken care of it in due course anyway, sender isn't worried about a lack of reply as long as things are fixed), it would seem to impose a lamentable amount of overhead -- time that could otherwise be spent on the never-ending task of buildd/port maintenance. The BTS overhead is justified for packages, since any developer can NMU a package; as long as the buildds for most ports are one-maintainer-per-arch, I don't see that having a list in the BTS of packages to be requeued gives us anything over the present situation. In the case of mails sent to @buildd.debian.org about issues that go unfixed for long periods, it would be nice to know what the story is. And personally, since I send a lot of these mails about packages with RC issues, I think more feedback from the buildd maintainers would help me to know better when these emails are helpful and when they're a distraction; but in the absence of feedback, I'll continue to assume my current approach is ok... -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: The LCC is a bad idea, but that doesn't mean the LSB doesn't have any issues
On Fri, Dec 17, 2004 at 10:03:00AM +0100, Wouter Verhelst wrote: > On Thu, Dec 16, 2004 at 11:01:16PM -0800, Bruce Perens wrote: > > You never lose the right to modify. You lose the right to claim that a > > modified version is the certified one. I addressed this specifically in > > DFSG section 4:/ > >/The license may require derived works to carry a different name or > >version number from the original software./ > > At the time, there was an "Official" version of ABIWord sanctioned by > > ABISource, and any modified version would be unofficial and had to bear > > a different name, and DFSG #4 was written specifically to allow that > > sort of uses. This is certainly a form of certification. Indeed, Debian > > makes use of similar certification for its Official CD. > Indeed; however, IMO excerting the right to modify as defined by the > DFSG should never result in the loss of support, or other negative > consequences, because in that case you might as well not have it. This > type of certification does carry that kind of negative consequence. But this happens all the time in all kinds of situations (think Red Hat RHEL support vs. Fedora, or even users reporting bugs to the Debian BTS about backported packages), and is perfectly valid under the DFSG -- even if we don't want to be put in this situation by ISVs. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Linux Core Consortium
On Thu, Dec 16, 2004 at 02:37:09PM -0500, Ian Murdock wrote: > On Tue, 2004-12-14 at 18:15 +0100, Tollef Fog Heen wrote: > > This sounds a bit like the government whose country had three > > different types of power plugs. None compatible, of course. Somebody > > then got the great idea that if they invented another one to supersede > > the three plugs in use (since that caused overhead). That country now > > has four plugs in use. > Actually, it's more like the country that has a few dozen different > types of power plugs, and they're all so minutely different from each > other that the consumer has no idea why it's like that, only that if he > buys something that requires electricity, he can only use what he > buys in 50% of the places that have electrical power. Also, the > differences are small enough that he *might* be able to plug in > what he has bought in some of the other places, but he's never > sure if or when the thing he plugs in will blow up. Three of the > six makers of the most common plug types then get together, realize > the stupidity of the current situation, and decide to correct it. > At the very worst, there are two fewer plug types. At the very best, > the dozens of others gradually disappear too. The end result is that > consumers can now buy electrical equipment that work in more places. s/power plugs/Windows service packs/ Wait... what was the ISVs' argument against having to test their software on multiple slightly-incompatible distros again? ;-) -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Removing obsolete configuration files?
On 27-Dec-04, 12:24 (CST), sean finney <[EMAIL PROTECTED]> wrote: > On Mon, Dec 27, 2004 at 03:54:08PM +0100, Peter Eisentraut wrote: > > [delete obsolete configuration files?] > > i'd say if they don't get in the way, leave them there, but make a note > of the fact that they're obsoleted via a debconf note (of appropriate > priority), and in the README or Changelog.Debian. Where the "appropriate priority" is "none". Putting it in the Debian NEWS files is sufficient. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: dependancy issues
On 01-Jan-05, 21:14 (CST), Marc Wilson <[EMAIL PROTECTED]> wrote: > On Sat, Jan 01, 2005 at 05:07:42PM -0800, Carl B. Constantine wrote: > > I'm trying to trim my system a little bit. I wanted to purge Evolution > > from my system since I use Mutt for email. But doing that wants to > > remove Gnome. > > So it wants to remove the Gnome meta-package. So what? So doing so causes all the packages that the gnome meta-package depended on to be de-installed, if one is using package tool that tracks packages that were installed to fulfill a dependency; aptitude, for example. This can be disconcerting. It means you need to go in and (re-)select all the smaller meta-packages, etc. that you actually want to keep. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: murphy is listed on spamcop
On Mon, Jan 03, 2005 at 09:17:43AM +1100, Russell Coker wrote: > On Monday 03 January 2005 07:25, Thomas Bushnell BSG <[EMAIL PROTECTED]> > wrote: > > This is true whether the bad things are false positives in email or > > the deaths of hundreds of people. Certainly deaths are worse, but I > > wasn't comparing false positives to deaths. > > I was explaining why your style of excuse is never acceptible. If > > false positives are bad (and they are), they do not become less bad > > because you cannot figure out how to avoid them and still achieve your > > goals. > There is no comparison between killing people and bouncing email. Whatever > point you were trying to make is lost. The thread is over. Maybe the real point here is that no one has come up with a spam control solution yet that involves killing spammers. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Status of Kernel 2.4.28 packages?
On 02-Jan-05, 15:54 (CST), Stephan Niemz <[EMAIL PROTECTED]> wrote: > By the way, is there a guide somewhere telling how to switch an > "unstable" system from 2.4 to 2.6? apt-get install kernel-image-2.6. Seriously, that Worked For Me. It wasn't a big deal. However, as usual, "It depends": If you're running LVM or EVMS, you'll need the appropriate updated user-space toolset. If you're *booting* off an LVM or EVMS volume, it becomes much harder, I think. Converting to udev is an additional step, and caused me a lot more work than the basic 2.6 upgrade (mostly getting my head around it, and converting from usbmgr). Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: For people more knowledgeable about buildds...
On Tue, Jan 04, 2005 at 10:13:11PM +1100, Andrew Pollock wrote: > Is there a webpage that shows the current queue of packages in Needs-Build > state? igloo's pages are great, but they only let you know the position in > the queue of a package, not what's before or after it (out of curiosity). http://buildd.debian.org/stats/?arch=ia64&state=Needs-Build Cheers, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: New stable version after Sarge
On 04-Jan-05, 07:40 (CST), Paul van der Vlis <[EMAIL PROTECTED]> wrote: > One of the biggest disadvantages of Debian for me is the long time it > takes for a new stable version. If you want Ubuntu or Progeny, you know where[1] to find them. :-) Seriously. There's just no way you're going to change the way Debian makes releases, or rather, doesn't. It's too big, and there are just too damn many people involved, many of whom simply don't care about releases. As long as we maintain our current release criteria (which I don't necessarily think we should change) we will get slower and slower as we get bigger and bigger. Steve [1] Okay, just in case you don't: http://www.ubuntu.com/, http://www.progeny.com -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx buildd.debian.org sent to /dev/null ?)
On Tue, Jan 04, 2005 at 10:38:03PM +0100, Ingo Juergensmann wrote: > Please note that year 2005 has come to an end and > the year 2005 is now - even in my mail address! Does the new address bring with it a more constructive attitude towards volunteers who have contributed countless hours over the years to keeping this project running, or should I plan to killfile this one as well? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: RunDinstallHourly
On Tue, Jan 04, 2005 at 08:08:47PM -0500, Joey Hess wrote: > Ken Bloom wrote: > > http://wiki.debian.net/?RunDinstallHourly (part of the ReleaseProposals > > topic on wiki.debian.net) discusses the concept of speeding up the release > > process by running dinstall hourly instead of once per day. This seems (to > > my amateur eyes) like a technically simple change to make even before we > > release Sarge (barring any unforseen consequences). Would it be possible > > to start testing this proposal out now by increasing the frequency of > > dinstall, perhaps to once every 6 hours until release? > I've talked about this with James Troup before. He seemed pretty > receptive to speeding it up to something like twice a day, didn't seem > to feel it would hit the mirrors much worse. It's possible he may still > be waiting on SCC splitting up the base set of arches or the like before > revisiting this. > (BTW, please note that when I or this proposal talks about the "dinstall > run", we're using the circa 1998 definition that includes "mirror sync". > The dinstall program itself aready runs every 15 minutes.) Twice daily seems more reasonable to me than hourly; for release purposes, another factor is how often britney runs, since that's what triggers changes in the testing suite. Doubling the frequency of britney runs seems reasonable to me, but hourly would surely be overkill considering we would still want to keep the waiting periods as they are now. Anthony Towns has been playing with the testing scripts this week, giving the release team the ability to do by-hand runs of britney now. This gives us more flexibility in catching our own oversights that would otherwise push bits of testing improvements back by 24 hours at a time. This has already directly contributed to getting KDE 3.3 into testing as soon as we did -- if the dip in the sarge RC bug count is any indication, this looks like a step in the right direction. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx buildd.debian.org sent to /dev/null ?)
On Wed, Jan 05, 2005 at 07:30:32AM +0100, Ingo Juergensmann wrote: > On Tue, Jan 04, 2005 at 02:59:29PM -0800, Steve Langasek wrote: > > > Please note that year 2005 has come to an end and > > > the year 2005 is now - even in my mail address! > > Does the new address bring with it a more constructive attitude towards > > volunteers who have contributed countless hours over the years to keeping > > this project running, or should I plan to killfile this one as well? > So you decided to play a "my volunteer work is worth more than your > volunteer work" game? I said nothing of my own volunteer work, which pales in comparison to that of many. Nor was I making any judgement about the relative worth of your volunteer contributions compared to those of anyone else -- only about the historically destructive effect of your mailing list contributions, which offset the value of an awful lot of volunteer hours, and more yet if I allow myself to be dragged down by them. The "us versus them" pitting of volunteer contributions against each other appears to be your game alone, and is precisely the sort of thing that led me to killfile you in the first place. But it's a new year, and you have a new email address, and I'm an eternal optimist -- so as it seems to be on-point for this thread, I ask you instead of assuming: is there any hope that you'll participate constructively in the project lists in the year to come, or are you still so twisted up inside over past slights, real or perceived, that you refuse to treat developers such as James Troup, who has indeed contributed "countless hours" to Debian over the years, with a minimum of respect and human decency? If all you have to contribute for this year is more harping about Debian's deficiencies and issuing of ultimatums, then I might at least save myself the time of reading, don't you think? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: RunDinstallHourly
On Tue, Jan 04, 2005 at 11:16:44PM -0800, Ken Bloom wrote: > On Tue, 04 Jan 2005 18:04:37 -0800, Steve Langasek wrote: > > Twice daily seems more reasonable to me than hourly; > Why? If you run it only twice daily, then the developers who are awake at > one run will probably be asleep at the next, so there's still essentially > a whole day's lapse before a developer can fix anything. I'd say a minimum > of 4 times a day lets a developer see the result of his changes before the > next time he goes to sleep. But the attraction of hourly is that a > developer can see feedback from his changes within a couple of hours, and > a developer may be able to clean up any bugs people noticed in the same > sitting that he introduced them. I don't know about you, but I'm usually awake for at least 16 hours at a time, which gives me a 1 in 3 chance of being awake for both dinstall runs if the timing is random, and probably higher than that if the timing is "optimum". But I'm not sure why I would care about being awake through both of them anyway; one of the immediate benefits of having two dinstalls a day is that everyone would be awake to see at least *one* of them, which isn't the case today. Being able to work through one dinstall in a given day is enough to let a developer upload, wait for feedback, and fix -- they wouldn't be able to see the results of the *fixes* until the next day, but if they don't know if they've fixed the bug, they bloody well shouldn't be uploading another package to the archive and stressing the autobuilder network: that developer needs improved quality assurance practices, not more frequent dinstall runs. :P And it's not like users want more frequent updates, either. Once a day is plenty often to be fiddling with apt-get; many sid users don't update nearly that often, after all. The exception is when something breaks, and you need a fix yesterday, in which case you don't want to wait for the fix to be apt-gettable from your mirror anyway: you grab it from incoming, or get a test deb from the maintainer before he's uploaded, if it's that important. Hourly dinstalls aren't going to improve on the usability of this when the mirror pulse is likely to take at least an hour to reach the edges. There are really very few concrete benefits I can see to increasing the dinstall frequency, but one in particular is to speed up debian-installer testing. Most other bugs don't require a full dinstall cycle to give people a good idea whether they've been fixed, but the installer builds out of the archive, which means that verifying the fixes for certain bugs *does* require a dinstall pulse followed by a d-i and CD build. So stepping this up to a higher frequency than once a day can help here, but stepping it up so that dinstalls happen more frequently than CD builds can be completed does not. > > for release purposes, > > another factor is how often britney runs, since that's what triggers > > changes in the testing suite. Doubling the frequency of britney runs > > seems reasonable to me, but hourly would surely be overkill considering we > > would still want to keep the waiting periods as they are now. > The concept of RunDinstallHourly was supposed to be a more > unstable-oriented approach. - testing changes are clocked by the same mirror pulse as unstable - if this is supposed to be a change that helps the release, it is important to consider the effect it will or won't have on testing, since that's the suite that's actually used for staging stable -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: build problem on mips{,el}
On Wed, Jan 05, 2005 at 11:40:14AM +0100, Martin Waitz wrote: > my package tspc could not be build on mips and I don't know why: > /usr/bin/ld: cannot open output file ../../bin/tspc: Permission denied > The package builds correctly on all other architectures. > Any ideas? mips* do not use fakeroot as the root command when building, because fakeroot does not work on these architectures. Instead they must use sudo, which means that directories or files created in the clean target will not be writable by the build target. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: New stable version after Sarge
On Wed, Jan 05, 2005 at 06:07:41AM -0800, Stephen Birch wrote: > Wouter Verhelst([EMAIL PROTECTED])@2005-01-05 14:22: > > You should ask the release managers about that. > Wow!! You mean the decision process is not made public? I would have > thought it would be out in the open for all to see. Hmm, I would've thought that after 5 months of the Same Old Story, anyone reading d-d-a would know what the preconditions are for freezing sarge. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: New stable version after Sarge
On Wed, Jan 05, 2005 at 02:18:37PM +0100, Florian Weimer wrote: > * Joey Hess: > > I think we've taken this "security bugs arn't fixed in testing as well > > as in stable" thing as gospel a little too long without verifying it > > lately. I've been checking and if testing is lagging stable at all, it's > > doing so by a much smaller amount than we've traditionally thought. > I think that's because of the pending release, in particular frozen > base packages, and not representative for the whole release cycle. > If a switch to a new upstream version of libc runs into problems, > testing and unstable will diverge again, maybe for weeks or months. > testing-security intends to solve this, though. If a switch to a new upstream version of libc runs into these kinds of problems again in unstable, we aren't learning from our mistakes, and it's questionable whether any amount of strategizing will put is in a position to do time-based releases. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bug#288769: ITP: cedilla -- ascii to postscript renderer
On Wed, Jan 05, 2005 at 04:43:05PM +0100, Adrian 'Dagurashibanipal' von Bidder wrote: > * Package name: cedilla > Version : 0.5 > Upstream Author : Juliusz Chroboczek > * URL : http://www.pps.jussieu.fr/~jch/software/cedilla/ > * License : GPL > Description : ascii to postscript renderer with unicode support > An ascii to postscript renderer written with the requirements of > non-ascii text in mind. While other, older ascii renderers like a2ps > apparently can not easily be adapted to output accented characters or > non-latin scripts properly, cedilla was written with this requirement > in mind from the start. I think you want to say "plaintext to postscript renderer" here, since clearly text that contains non-ascii characters is not ascii. ;) -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Experimental gaim_1.1.1-2 for Alpha
On Wed, Jan 05, 2005 at 09:27:50AM -0500, Greg Folkert wrote: > On Wed, 2005-01-05 at 08:55 -0500, Greg Folkert wrote: > > I have built this package for alpha and it does indeed work. I have > > bundled it up in a tgz making it easier to D/L. But all the files are > > there as well for individual inspection. Along with the md5sums > > http://www.gregfolkert.net/experimental/ > > not an archive by any means, but available at your discretion. > BTW, someone pointed out I didn't sign the .changes file... ummm oops. > First real try at building the packages for general consumption. My bad. Be careful: in general, you should *not* sign changes files for packages that are not intended to be included in the Debian archive. Once the changes file is signed, anyone can upload your package to the Debian archive whether that was your intent or not. It's trivial to ensure your changes file will be rejected by katie, by setting the 'distribution' field in your changelog to an unknown value. In this case, your package would also be rejected because it's a sourceful upload of a package that already has source in the archive; but if this had not been the case, you might have found yourself blamed for whatever bugs this build introduced. In any case, perhaps this particular build should have been a binary-only upload to experimental, to join the i386 build already there? Cheers, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Experimental gaim_1.1.1-2 for Alpha
On Wed, Jan 05, 2005 at 11:47:57PM +, Henning Makholm wrote: > Scripsit Martin Michlmayr <[EMAIL PROTECTED]> > > * Steve Langasek <[EMAIL PROTECTED]> [2005-01-05 15:12]: > >> Be careful: in general, you should *not* sign changes files for > >> packages that are not intended to be included in the Debian archive. > >> Once the changes file is signed, anyone can upload your package to > >> the Debian archive whether that was your intent or not. > > Greg doesn't appear to be a Debian developer so neither of this > > applies. > But if he later *does* become a DD, the archive scripts might > retroactively accept his old changes file if somebody uploaded it, > wouldn't they? (I'd be surprised if they checked the creation date of > the signature, but things sometimes do surprise me). > Here I ignore the fact that a newer version would probably be in the > archive by then, for this particular package at least. In this case, I merely failed to realize Greg wasn't a DD. Both you and Martin are correct. > > The first paragraph is good advice in general, though. > Does it also apply to signing .dsc's? The archive scripts won't act on an uploaded .dsc without an accompanying .changes file, so this is not an issue. Moreover, signing your .dsc provides a trust path to your source code (in the case where you're making sourceful changes -- Greg did not, so probably shouldn't need to distribute a .dsc at all), so this is a good idea. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Experimental gaim_1.1.1-2 for Alpha
On Thu, Jan 06, 2005 at 12:55:14PM +, Henning Makholm wrote: > Scripsit Steve Langasek <[EMAIL PROTECTED]> > > On Wed, Jan 05, 2005 at 11:47:57PM +, Henning Makholm wrote: > >> Does it also apply to signing .dsc's? > > The archive scripts won't act on an uploaded .dsc without an accompanying > > .changes file, so this is not an issue. Moreover, signing your .dsc > > provides a trust path to your source code > I think that is what I meant: If I sign a .dsc that is not intended to > be uploaded, is there a risk that this trust path ends up in the > archive because somebody else constructs a .changes to put them in? > The "somebody else" would have to be a DD, but the signature the > general public [1] would see in aptable source repositories would be > mine. I believe katie does check the sigs on .dscs, which requires that the sig be from a DD. Even if there were a bug in this check, I wouldn't worry overly much, *you* wouldn't be the one in trouble for uploading a package in that state ;P -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: New stable version after Sarge
On Tue, Jan 04, 2005 at 08:08:05PM -0600, Marcelo E. Magallon wrote: > On Tue, Jan 04, 2005 at 03:34:20PM +0100, Martin Schulze wrote: > > > One of the biggest disadvantages of Debian for me is the long time > > > it takes for a new stable version. > > > What about saying something like: the next stable release comes in > > > the beginning of 2006? > > The release date for a Debian release is not set by a calendar but by > > quality. At least that's been the case including sarge. Hence, such > > a sentence would not mean anything. > Then let's accept the premise behind the whole testing idea and target > Sarge+1 for Sarge+6 months. > Or does the team have plan that will stall that release for > another year? Yes, I don't think the release team has any intention of working itself ragged to get a second release out 6 months after sarge. I also don't think there's any consensus among developers (or users) that we *want* to release Debian that frequently. A 6-month period honestly doesn't allow us much time for new development anyway. If all we wanted was a point release of sarge, that'd be fine; but I think most people would like to see etch be an improvement over sarge in more respects than just hardware driver count, and we have to be realistic that this means a period of heavy changes followed by a period to stabilize everything again. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: rudeness in changelogs
On 08-Jan-05, 15:08 (CST), Joey Hess <[EMAIL PROTECTED]> wrote: > Is this really called for in changelogs? Note that the bug reports were > perfectly polite. Not really called for, but I understand the frustration with people who have nothing better to do than nag, and (for the second bug) without even checking the existing bugs! > Imagining myself as a student in this class: I complete the requested > assignment, with luck make an A, only to have the prof post it to the > internet and then be insulted by perfect strangers as they use my work > to fix their problems. These would be the same students who didn't even have the minimum decency to attempt to notify the upstream authors before publishing the bugs? I think taking a dig at them in the changelog is the *least* anyone should do. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: rudeness in changelogs
On Sat, Jan 08, 2005 at 06:44:24PM -0600, Steve Greenland wrote: > > Imagining myself as a student in this class: I complete the requested > > assignment, with luck make an A, only to have the prof post it to the > > internet and then be insulted by perfect strangers as they use my work > > to fix their problems. > These would be the same students who didn't even have the minimum > decency to attempt to notify the upstream authors before publishing > the bugs? I think taking a dig at them in the changelog is the *least* > anyone should do. Considering the assignment AIUI was "find security holes", not "audit someone's code", it also looks immature to take potshots at someone who, unlike the changelog author, was able to find such a security bug without first having his attention drawn to the section of code in question. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bug#289385: RFH: cdrtools -- searching co-maintainer for the package
Joerg Jaspert writes: > >Package: wnpp >Severity: normal > >Hi > >Unfortunately we dont have the time the package needs, so help is >needed. Ideally you should know a bit of C and of Debian Packaging. You >should also know cdrecord/mkisofs and its friends and of course have a >cd burner at home to test stuff. :) > >You do not need to be a DD to help out, just start by going through the >buglist, preparing patches, answering/closing them if needed, etc. pp. I'd love to help. I need to check that my employer would have no problem (I write proprietary storage software for a living!), so I'll get back to you tomorrow. I've already written several patches for mkisofs and cdrecord over the years I've been using them, so I'm quite experienced with the code. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Re: Why does Debian distributed firmware not need to be Depends: upon? [was Re: LCC and blobs]
On Sun, Jan 09, 2005 at 06:11:54PM +0100, Miguel Gea Milvaques wrote: > This is the same point. You are going to care very much abut *which* > firmware are you loading on your driver. > >The firmware used by a NIC driver, on the other hand, has no > >user-visible content; certainly it has no content that the user > >specifically cares about. In the common case, there is nothing to > >distinguish between one firmware release and the next, other than > >bugs fixed according to the release notes. In the less common case, > >some versions of the firmware will add usable features to the > >driver, like hardware checksumming of TCP packets. Even then, > >although the user may say "I want version X of this firmware because > >I heard it makes the driver faster", there's still a limited and > >predictable range of firmware content people might ever want. To > >the extent that this ceases to be true (as, for example, with > >Linux-based wireless access point hardware, where a community > >develops around producing non-vendor firmware that does cool new > >things), it begins to make sense to treat those cases as data > >loaders which needn't provide or depend on specific data files. > > 3. There's a very real expectation, in the PDF case, that the user > >could create his or her *own* PDF files, using any number of tools > >in Debian or not in Debian. The user could quite reasonably wish to > >install xpdf *solely* to view locally created content. If you find > >that hard to believe, think about how most people use xdvi. > >Firmware files are not the sort of thing people can create their own > >versions of. In most cases the format is not documented and there > >are no free or even publicly available tools for this, and even in > >cases where it *is* documented, this is not by any stretch of the > >imagination a typical use case. > Yes, but the difference is only the difficult could be create them. Then > if you have a more difficult working sofware, it must be in contrib? It is not enough to say that you *could* create free firmware files. As a user of xpdf, I can unequivocally say that there are pdfs that I have full rights to, because *I created them*. I cannot say that about firmware files. If you have a free firmware file that works with the driver in question, please produce it for us to see. It should become part of the package immediately, and be loaded by default by the driver. If, on the other hand, we know that the driver needs to load firmware from disk before it can actually be usable with any device, and we don't have any real, working firmware images that are free, it is disingenuous to handwave this away by saying that "free firmware could exist". We either have free firmware for use with the device, or we don't. If we don't, then the driver won't work for our users without additional effort, and we should be honest about that. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Who could be able to help SW vendors to support Debian?
On Tue, Feb 01, 2005 at 10:57:08PM +0100, Christian Perrier wrote: > Well, I'm not the software vendor here..:-) > > As far as I've inderstood, this product induces some interaction at > kernel-level and the vendor developers may have concerns about the > kernel on the distribution they want to support their product on. They > probably also have concerns about the library compatibility and such > stuff. Perhaps rather than having a requirement for a specific kernel they could use something like that Yin-Yang, or dazuko kernel modules which can provide an interface for on-access operations? That way they have a greater chance of working with arbitary distributions. (The latter is packaged for Debian). Beyond that I think the other poster was right, really there should be more focus on linking statically, packing in an open format such as .tar.gz not .rpm and miminal links to the kernel or OS. Obviously some software such as VmWare or the Nvidia drivers need tight integration, but providing open source shims can minimize the variation between different host kernels. (It might be worth discussing platform compatability - too many closed code assumes only x86. Using Debian in that context is an interesting way of making the point that there are more chips in the world than x86 and ppc.) Steve -- # The Debian Security Audit Project. http://www.debian.org/security/audit -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Who could be able to help SW vendors to support Debian?
On Tue, Feb 01, 2005 at 10:06:14PM +, Steve Kemp wrote: > Beyond that I think the other poster was right, really there > should be more focus on linking statically, packing in an open > format such as .tar.gz not .rpm and miminal links to the kernel > or OS. With the proviso that static linking against libc6 is more likely to introduce ABI problems via nss than just dynamically linking against an old libc6 ABI (i.e., GLIBC_2.0 or GLIBC_2.1). -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bug#293167: ITP: request-tracker3.4 -- Extensible trouble-ticket tracking system
On 02-Feb-05, 18:31 (CST), Matthew Palmer <[EMAIL PROTECTED]> wrote: > > So archive bloat is not a problem for you, and "apt-get dist-upgrade" not > actually providing upgrades to the latest versions of everything is > perfectly fine? In the case of RT, yes. I notice that there are several different versions of gcc in the archive, and nobody seems to be bothered by that. Likewise, there are several versions of python. There are, of course, good reasons for both. RT likewise. It changes a *lot* between minor releases. Add-on tools have to be updated, local scripts checked and fixed, etc. etc. etc. Best Practical makes new bugfix releases to older versions, so they obviously don't expect everybody to upgrade all at once. RT is not an application. RT is a framework. It's quite reasonable to have multiple versions of that framework available. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release update: kde3.3, upload targets, kernels, infrastructure
Hi Goto, On Wed, Feb 02, 2005 at 01:54:54PM +0900, GOTO Masanori wrote: > At Thu, 27 Jan 2005 07:30:57 -0800, > Steve Langasek wrote: > > On Thu, Jan 27, 2005 at 01:19:36PM +0100, Christoph Berg wrote: > > > I upgraded a Woody box last week to Sarge's glibc/apt/dpkg/ > > > openoffice.org/perl last week. The result was that Woody's mysql does > > > not work with Sarge's glibc. It complains about missing GLIBC_2.2 > > > symbols. I've then also upgraded mysql and things were fine again. > > $ ldd -d -r /usr/bin/mysqladmin > > libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 > > (0x4002a000) > > libmysqlclient.so.10 => /usr/lib/libmysqlclient.so.10 (0x40073000) > > libz.so.1 => /usr/lib/libz.so.1 (0x400a9000) > > libcrypt.so.1 => /lib/tls/libcrypt.so.1 (0x400bb000) > > libnsl.so.1 => /lib/tls/libnsl.so.1 (0x400e8000) > > libm.so.6 => /lib/tls/libm.so.6 (0x400fc000) > > libc.so.6 => /lib/tls/libc.so.6 (0x4011e000) > > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) > > symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link > > time reference (/usr/lib/libmysqlclient.so.10) > I don't know this problem is "missing GLIBC_2.2 symbols" issue. It > does not clear Christoph's problematic architecture. This is the only warning shown on my system when installing woody mysqlclient on sarge glibc, and is the only major ABI regression of this kind I'm aware of between woody and sarge glibc. Unless Christoph can offer more precise information about the symbols that were missing on his system, I assume this is the problem he's referring to. > > This is a bug in the woody libmysqlclient10 package, which should not have > > been using errno in this way. > > It also only occurs when the TLS-enabled glibc is used, which is only the > > case if you are running a glibc kernel. > IIRC that was already treated specially until sarge one year ago by > Daniel. I don't understand what you mean here. How was it treated specially, and why is it not treated specially now? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: list what's in the NEW queue?
On Thu, Feb 03, 2005 at 02:28:39PM +0100, Frederik Dannemare wrote: > On Thursday 03 February 2005 03:03, Marcelo E. Magallon wrote: > > On Wed, Feb 02, 2005 at 06:28:58PM +0100, Jeroen van Wolffelaar wrote: > > > As a DD, you can ls /org/ftp.debian.org/queue/new on merkel, daily > > > synced. Beware, there are 2826 files in there atm, so ls via grep > > > or something. > > And while we are on the subject, what's with NEW not being > > processed? Or are we again in the usual "I'll process any package > > that I feel like processing" situation? > Is it not just that there's too few hands to do the processing? > Recently our DPL assigned extra man-power to the "New Maintainers Front > Desk" and to the "Debian Account Managers" and with very good results, > for what I know. It would be great if he would assign more people to > process the NEW queue as well (in context hereto - do all current > members of ftp-masters process the NEW queue?). Increasing the rate at which new packages flow into unstable is NOT something that should be a priority when we're trying to get the RC bug count down in preparation of a release. Show me that there are enough people working on release-critical issues for sarge, which requires no imprimatur from the DPL, before you start throwing packages that have never even been tested by their maintainer at us faster than we already get them. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
ITP: libecw -- Library for Enhanced Compressed Wavelet(ECW) and JPEG 2000 image I/O
For some reason this ITP didn't get cc'd to debian devel, so here it is: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293346 Regards, Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: list what's in the NEW queue?
On Thu, Feb 03, 2005 at 04:05:19PM +0100, Wouter Verhelst wrote: > Op do, 03-02-2005 te 15:44 +0100, schreef Frederik Dannemare: > > > which > > > requires no imprimatur from the DPL, before you start throwing > > > packages that have never even been tested by their maintainer at us > > > faster than we already get them. > > I see your point if it is really the case that uploads are being done > > without proper testing from the maintainer himself/herself. > His point is still valid even if all maintainers do proper testing. You > can't be expected as a maintainer to be able to test /every/ possible or > impossible situation in which a package could be used. And then I'm not > even talking about packages that should conflict with eachother but > don't, because the maintainer of the new package didn't know that a file > in his package happens to have the same name as a different file in a > completely unrelated package... What I know is that every time an ftpmaster processes a batch of NEW packages, a percentage of them wind up in testing with serious bugs for failing to declare build-dependencies, and then the release team has to track these bugs. Since the testing scripts have no way to distinguish an architecture-specific package from a broken binary that only builds on the maintainer's system, the only strategies I can think of off-hand that would be effective at reducing this problem are to disallow all binary uploads from maintainers, to get FTBFS errors detected and filed sooner after packages are uploaded, or to cut down on the number of utterly broken packages that are getting uploaded in the first place. I'm not suggesting that ftpmasters are deliberately ignoring the NEW queue for sarge's sake, but from here I'm not shedding any tears. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: list what's in the NEW queue?
On Thu, Feb 03, 2005 at 03:44:19PM +0100, Frederik Dannemare wrote: > Would it be an idea (post-Sarge?) to not let packages automatically > propagate from sid to testing after X days. Instead, the responsible > maintainer would have to explicitly tag a package as 'ready for > testing' as opposed to the current situation where a bug must be filed > to prevent a buggy package from propagating? Most maintainers don't pay close enough attention to their packages as it is to notice when their packages *aren't* ready for testing because of arch-specific build failures; I think expecting maintainers to tag packages as being testing-worthy would just make it harder to get needed package fixes to get into testing. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: list what's in the NEW queue?
On Thu, Feb 03, 2005 at 06:03:04PM -0600, Marcelo E. Magallon wrote: > On Thu, Feb 03, 2005 at 08:39:10PM +0100, Joerg Jaspert wrote: > > It works and is available from dak.ganneff.de. And the packages is > > used on several archives now. Its just not out of NEW atm. > So, let's *guess* ... > * -release decided to stop processing NEW ... we still have this thing >called debian-devel-announce, you know? Er, as flattering as it might be to suppose that the release team can unilaterally decide to stop NEW processing, it's at least as insulting to presume that we wouldn't have told people about it via debian-devel-announce, y'know? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bug#293561: ITP: player -- music player and organizer for GNOME
Dan Korostelev wrote: >Package: wnpp >Severity: wishlist >Owner: Dan Korostelev <[EMAIL PROTECTED]> > >* Package name: player > Version : 0.1pr1 > Upstream Author : Milosz Derezynski <[EMAIL PROTECTED]> >* URL : http://linux-media.net/player/ >* License : GPL > Description : music player and organizer for GNOME > > Player is a graphical music player and organizer for GNOME 2 > desktop environment. > > It uses GTK+ for its user interface, GStreamer for playback and > SQLite for working with music database. > >(expect packages soon on http://mentors.debian.net/, we still need >libvisual to be packaged and uploaded.) Please use a less generic name. "player" alone means very little and is likely to cause confusion. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Who needs computer imagery when you've got Brian Blessed? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: About valid and invalid user names
On 05-Feb-05, 10:47 (CST), Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > > Because '.' is POSIX, thus valid. And not accepting the '.' is a damn > bug in any POSIX-compliant utility. According the SUS section that Kurt quoted, leading digits are equally acceptable. I think it might be reasonable to accept leading digits when there is at least one non-digit in the name. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#294084: ITP: life -- Linux Instrumentation for Enterprise - a set of WBEM management providers from Novell
On 07-Feb-05, 13:52 (CST), Rafal Lewczuk <[EMAIL PROTECTED]> wrote: > * License : (GPL, LGPL, BSD, MIT/X, etc.) Pick one. > * URL : http://forge.novell.com/modules/xfmod/project/?life So I visited this site, and it looks like a place holder: no docs, no lists, no released files, no nothing. The CVS tree hasn't been modified in months. Is this really something that can be usefully packaged? Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#294084: ITP: life -- Linux Instrumentation for Enterprise - a set of WBEM management providers from Novell
On 09-Feb-05, 01:50 (CST), Rafal Lewczuk <[EMAIL PROTECTED]> wrote: > I'll try to rollback this ITP (dunno how to do it yet) and maybe post it > after solving some issues (aside from naming/buzzwords there are also > some technical things: build system, versioning etc.). If you intend to package it eventually, then there's no need to do anything except perhaps add a note about the current state of "not quite ready for packaging, working on it". The "rollback" mechanism is to simply close the report. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is /.udev for ?
On 09-Feb-05, 19:12 (CST), Ron Johnson <[EMAIL PROTECTED]> wrote: > "So what?", you say. Well, data should only be listed once, not > twice. gtkdiskfree sums up all total and free disk space, and > having /.dev in there totally distorts the truth. If you don't have a fs mounted, df won't show it either. Is it lying then, too? Df et. al. show all the mounted filesystems. If the same filesystem is mounted twice, then it shows it twice. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: execturing libc
On Thu, Feb 10, 2005 at 06:17:01PM +1100, Paul Hampson wrote: > > It still lets you execute files that don't have the executable flag > > set like libc. It's a different bug but it's still there. > Is that a bug? I can run -x perl scripts with perl so > why not -x ELF scripts with /lib/ld-linux.so.2 > What stops me taking a copy of the binary, making it +x and running > that anyway? So I don't see any security concern... Not having write access to any media that's not marked noexec? But I agree that the security benefits are trivial on a system where users have access to perl. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: what is /.udev for ?
On 10-Feb-05, 08:01 (CST), Frank K?ster <[EMAIL PROTECTED]> wrote: > > This does not excuse the fact that someone with (a) root access, > > and (b) without the proper knowledge, went around rm'ing things. > > I thought Debian was a distribution targetted at a wide audience, > including experienced server admins, and home users without any training > or special knowledge. Sure. But if one is just a user w/o training, then one shouldn't be deleting random parts of the file systems. Consider this: "I don't know much about cars, just how to drive one. I looked under the hood, and there were all these messy wires every where. I didn't like the way it looked, so I cut them all out. Now my car won't start." It's the *same* *thing*. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /etc under svk
On Fri, Feb 11, 2005 at 06:36:04PM +0100, Enrico Zini wrote: > And a question: where do we collect this kind of tips? wiki.debian.net debian-administration.org debianplanet.org debianhelp.org And any page that's accessible to google! Steve -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
