Re: Ubuntu discussion at planet.debian.org
On Sat, Oct 23, 2004 at 11:54:05AM +0200, Jérôme Marant wrote: > Manoj Srivastava <[EMAIL PROTECTED]> writes: > > Could you elaborate on that? Why is it so painful? > Probably because you need maintain packages for both unstable and > testing at the same time. This is exactly what happened in the past when we forked off the frozen release: you wound up maintaining both the frozen and unstable versions of packages (unlike today it was possible to upload to both simultaneously if there was as yet no reason to fork). -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
Re: Ubuntu discussion at planet.debian.org
On Sat, Oct 23, 2004 at 08:56:45AM +0200, Jérôme Marant wrote: > Frank Küster <[EMAIL PROTECTED]> writes: > > Oh, it would be easy for me to break the tetex-packages (and cause lots > > of FTBFS bugs) just by applying all the great ideas about improved > > packaging that I have in mind. No upstream version needed for that. > Come on, this is ridiculous. Of course, you can always cheat if you > want to. If we can't expect developers to be responsible people > at all, then we can shut the Debian project down. The trouble is that much the same thing can be said about new upstream releases. -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
Re: Debconf is not a registry
On Mon, Nov 01, 2004 at 06:14:57PM +0100, Frank Küster wrote: > But that could as well be achieved by parsing the configuration files: That is exactly what packages were the Debconf configuration winds up in a configuration file have to do. However, Debconf answers will not always wind up in configuration files - things like upgrade notes also wind up using this mechanism, for example. -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
Re: Bug#280675: ITP: l2tpns
On Fri, Nov 12, 2004 at 02:07:36PM +, Jonathan McDowell wrote: > Please stop following up to this ITP and telling me you don't understand > the description unless you have prior experience of L2TP in an ISP > environment. If you don't know what L2TP is or how an LNS fits into the > picture, then this package probably isn't for you. I don't believe any > of the terms used should be alien to the sort of person this package > will be of use to. Perhaps man of these questions could be headed off by mentioning the sort of environment where the package would be useful in the description? -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
Re: On the freeness of a BLOB-containing driver
On Sun, Dec 12, 2004 at 04:09:04AM +0100, Goswin von Brederlow wrote: > Is a bit of flash or rom that much bigger than ram? Isn't most of the > space in the dongle air or filling material? Space is space on the board (not to mention the complexity of the board) as well as three dimenisonal space. > Cost I can see, size I find a bit hard to believe. Especially with mass market products the margins can often be tiny - sell enough units and it does add up, though. -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
Re: strange (or unexplainable) permissions on /var/log/*
On Sun, Dec 12, 2004 at 04:54:14PM +0100, martin f krafft wrote: > - why is dmesg 0644? This is not really a problem, but do users > need access to the boot messages? The log buffer can normally be read using the dmesg utility (or similar code) as well as via the log file. -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
Re: Manpages licensed under GFDL without the license text included
On Sun, Jan 09, 2005 at 02:26:51PM +0100, Bernhard R. Link wrote: > Mark Brown: <[EMAIL PROTECTED]> > x86info: x86info.1.gz This isn't Debian-specific since I contributed it back upstream. I've contacted upstream about relicensing it under the GPL like the rest of the package (which seems the simplest way of resolving the matter). -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
Re: Who could be able to help SW vendors to support Debian?
On Tue, Feb 01, 2005 at 09:46:19PM -0800, Steve Langasek wrote: > 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). Not to mention the LGPL too. Static linking against glibc is strongly disrecommended by upstream. For user space apps the dynamic interface to glibc is probably a better target to aim for than the kernel - it's offering pretty much the same level of ABI stability and is much less hassle. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
On Sun, Feb 13, 2005 at 01:25:15PM +0100, Steinar H. Gunderson wrote: > However, now we've suddenly discovered that _other_ programs get confused by > this! In particular, if you use an NFSv4-patched mount, it does a > gethostname() and resolves that, which returns 127.0.0.1, which in turn makes > it happily use that as a client identifier to the remote server. (This breaks > when two or more such clients connect, obviously.) This also causes problems for NIS servers, for the same reason - NIS needs to hand out the IP address of the machine in some circumstances and 127.0.0.1 is inappropriate. Resolving the hostname is a standard method for obtaining an IP address for the machine and it would be helpful if it could be reverted since I imagine other programs are also going to run into the same issue. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
On Sun, Feb 13, 2005 at 11:21:09AM -0600, John Hasler wrote: > Mark Brown writes: > > ...NIS needs to hand out the IP address of the machine... > Machines don't have IP numbers. Interfaces have IP numbers. Every machine Actually, that's not quite the case (as a number of users of Linux's ARP implementation have found), though it's a good approximation. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 02:57:25PM +0100, Marc Haber wrote: > Considered that ftbfs bugs for scc architectures are not going to be > RC any more, people will stop fixing them, thus the scc architectures Some may, but some would continue to be helpful. My experience doing porting work was that problems with portability and getting portability bugs fixed were more tied up with the general quality of the package and how well it was looked after than with anything else. Then again, I was mostly providing fixes for things along with the report. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 09:35:38PM +0100, Goswin von Brederlow wrote: > That suggests that FTBFS bugs for SCC archs will be ignored just as > long, 1/2 - 3/4 of the planed release cycle. Now imagine a bug in fsck > that destroys data being left open for so long. In my experience doing this sort of thing this is the exception rather than the rule and in most cases it's due to inactivity rather than anything else. I can only recall one case where I felt that the maintainer was being actively unconstructive and there I do recall thinking that the issue was more the maintainer's general attitude towards quality and addressing user problems rather than a specific hostility to porting issues. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tue, Mar 15, 2005 at 08:50:04AM +1000, Anthony Towns wrote: > What that actually means is that when porters want to stabilise, they'll > be able to simply stop autobuilding unstable, fix any remaining problems > that are a major concern, and request a snapshot be done. That'll result ... > That means that porters will have to do their own security and release > work, rather than relying on the primary security and release teams. Would it also be possible for porters to update the snapshots in some manner beyond having an apt source equivalent to the security archive added by d-i? -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tue, Mar 15, 2005 at 11:54:24AM +, Henning Makholm wrote: > If you wanted to make the decision _with_ the input of developers, why > did all the powers that be vehemently deny that the number of > architectures was a problem for the release schedule, right until > everyone turned on a platter and presented this fait accompli? To be fair, there were some comments to that effect from some of the relevant people beforehand. For example, Joey Hess raised concerns regarding the load placed on the d-i developers in some of the recent "too many arches" threads. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Tue, Mar 15, 2005 at 10:26:33AM +1000, Anthony Towns wrote: > Mark Brown wrote: > >Would it also be possible for porters to update the snapshots in some > >manner beyond having an apt source equivalent to the security archive > >added by d-i? > It'd be possible, certainly -- cf proposed-updates and stable. It would be useful if this could be clarified in any revision of the proposal - I don't think I was the only one to read it as saying that non-release ports wouldn't have any options other than simple snapshots. > Whether it would happen would depend on how useful it is; you have to > add security.d.o to your sources.list and download from it for stable > releases anyway; and the expectation is that non-release arches don't > stress as much about RC bugs and similar as release arches will, which My thought was that some of the non-release architectures that were in generally good shape might want to provide a version stable which would ideally involve the ability to do things like tracking the released stable. > Feedback from porters on how these things could actually work usefully > in real circumstances would be valuable here. Having a way of making > snapshots is probably the minimal level of support we'd envisage, > working out what that would actually achieve, and what benefits more > support would actually bring would be interesting. Yup. Presumably there would be varying requirements from the ports - at least some of the ports would be perfectly happy with simple snapshots. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Alternative: Source-Centric Approach [w/code]
On Tue, Mar 15, 2005 at 11:01:06PM +0100, Adrian Bunk wrote: > On some mirrors? > -> Not all mirrors have to mirror all ports. The mirroring part of the proposal is effectively just a proposal to rearrange the archive in order to make this easy for mirror admins. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
On Tue, Nov 15, 2005 at 06:30:00PM +0100, Thiemo Seufer wrote: > The need for gcc-2.95 usually means the source code is broken (in C99 > terms) and should be fixed. Do you have an example of an use case where > this is unfeasible, and which is important enough to justify continued > maintenance of gcc 2.95? It was relatively common to find C++ code that wouldn't build with the new C++ front end in GCC 3.0. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Re: mixing different upstream sources in one package
On Sat, Nov 19, 2005 at 12:27:33PM -0500, Jay Berkenbilt wrote: > impediments (like licensing problems), do people generally think that > it's reasonable to do this even if the other packages aren't really > part of the upstream package? If so, are there usual mechanisms for > doing this? What about version numbers? NIS does this. The minor version number of the package is bumped every time one or more of the upstream packages are upgraded (which causes a new orig.tar.gz) and the major version is bumped when something substantial enough to make that seem like a good idea happens. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Re: Thoughts on Debian quality, including automated testing
On Wed, Dec 21, 2005 at 08:10:03PM +0100, Thomas Hood wrote: > It turns out that there is no need for them to be hurt at all. Lone > can carry on working as before and find a co-maintainer who won't get > in his way. But when Lone falls off his horse he'll be glad that Tonto > is nearby. ... > You are saying that requiring people to find co-maintainers is > "bureaucracy"? It seems to me that if you're talking about a lip service approach like the above being OK then the focus isn't really on solving the problem any more, it's on having people jump through a given set of hoops. This doesn't really achieve the end result you're looking for. > Someone I know well recently got co-maintainers for > three of his packages by posting a single message to debian-devel. > That's less of a burden than that imposed by many another Debian rule. Conversely, the reason I ended up maintaining the NIS package is that I'm the only person who stepped up and actually did anything when the previous maintainer asked for help. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Re: Thoughts on Debian quality, including automated testing
On Fri, Dec 23, 2005 at 08:40:22AM +0100, Adrian von Bidder wrote: > The other side, and we've seen some people say this in this thread already, > is that even if a maintainer asks for help, he may not get any - IIRC nis > was one such package, and I claim that its still used by quite a few, so in > theory somebody should be found. ish. There was one person for nis, though others have posted similar examples where nobody at all stepped forward. The thing with NIS (and I imagine other things too) seems to be that while it's quite widely used it mostly does what people want already so things are very static and there's relatively little need for much work. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dependencies on makedev
On Thu, Dec 29, 2005 at 01:39:01PM +0100, Marco d'Itri wrote: > To prepare for the eventual removal of makedev, I propose that packages > currently depending on it will add an alternative dependency to udev. > Also, policy should be amended accordingly. It might be useful to tell the maintainers of the packages and/or post on -devel-announce - people might not be reading -devel or -policy. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Re: debian "experimental"
On Fri, Dec 30, 2005 at 04:12:23PM +0100, Michal Piotrowski wrote: > I have noticed that directory > debian/dists/experimental/main/binary-i386 is empty. > Where is new "experimental" repository? Unless there is a problem with the mirror you are using that directory should contain a Release and Packages file listing the packages in experimental. The actual packages are stored under debian/pool along with all the others. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Re: How to Increase Contributions from Volunteers
On Mon, Jan 02, 2006 at 07:11:26PM +0100, Petter Reinholdtsen wrote: > I suspect a similar system for Debian might increase visibility and > commitment from a large set of users. With the exception of the web forums and most of the commercial stuff that does sound rather like debian.org. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Re: Need for launchpad
On Sun, Jan 15, 2006 at 11:03:06AM -0800, Russ Allbery wrote: > However, to the degree that the Ubuntu patches have these sorts of > gratuitous changes that shouldn't be merged with Debian, the patch > database quickly becomes useless. The current patch system is only useful > if a maintainer can easily review it for changes that should be > incorporated in Debian, and nothing makes that impossible faster than > changes like autotools modifications. I'd hope that when Ubuntu start using HCT[1] we will be able to get a more useful unpacking of the changes Ubuntu have made. Right now it appears that what is published is a lightly processed diff between the original package and the current Ubuntu version. The lack of any native ability to logically organise changes in Debian source pacakges makes this a lot less useful than it might otherwise be - RPMs are a lot more straightforward to cherry pick changes from. Deploying Wig & Pen would also help, of course. [1] https://wiki.launchpad.canonical.com/HCT -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Re: Slightly Off Topic: Laptops for Debian
On Tue, Jan 25, 2005 at 03:58:55PM -0600, Jacob Schroeder wrote: > I hear iBooks have a much better value for the money. Not just from a > power perspective, but also because the PowerBooks get to looking ugly > really fast. This is due to the iBook case being made from a nice > durable plastic while the PowerBook case is made from easily > scratchable/dentable/etc. aluminum. That was more of a problem with the older models: they've really improved the durability of the hardware with more current PowerBooks. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels
On Sat, Apr 02, 2005 at 04:26:28PM +0200, Wouter van Heyst wrote: > On Sat, Apr 02, 2005 at 03:01:34PM +0100, Matthew Garrett wrote: > > I'm not suggesting that we claim that firmware is Free, but putting it > > in non-free is: > > (a) going to result in an awkward situation for installation, and > The awkwad situation would be that d-i is part of Debian, and non-free > isn't, so anything in non-free can not be part of the installer? > But having a (non-free) firmware section with components of that in the > installer is ok? Debian has always accepted comprimises between our desire to promote free software and our desire to produce a useful operating system - non-free is an example of this. As the world changes the nature of the comprimises we make may change. Previously there was very little hardware which required downloads of any kind in order to work but things like graphical web browsers were not avaliable. Now the situation is different - it is reasonable for people to run computers with no non-free software running on the host CPU but many more devices require a download to be useful. There are also important logical distinctions between software running on the host computer and things downloaded to devices which some (not by any means all) people feel make a difference. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels
On Sat, Apr 02, 2005 at 04:57:09PM +0100, Henning Makholm wrote: > Scripsit Matthew Garrett <[EMAIL PROTECTED]> > > I've suggested before that creating a separate section for firmware may > > be the best solution. > You have not described how that would differ from using 'non-free'. One example: with our current package management tools once you've got an apt source in your configuration the packages it provides will start to show up in things like searches. Given things like that it seems useful to let people install images to support their hardware but still exclude any non-free software that would run on the host computer. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels
On Sun, Apr 03, 2005 at 01:19:32AM +0100, Henning Makholm wrote: > Scripsit Mark Brown <[EMAIL PROTECTED]> > > One example: with our current package management tools once you've got > > an apt source in your configuration the packages it provides will start > > to show up in things like searches. > It is possible to edit sources.list *after* having defined the > packages one needs. That's not a static choice, though. > Also, there is no need to have the entire non-free > archive in one's sources.list at any time at all if one uses an > installer image that contains the necessary drivers itself. Given that one of the reasons hardware vendors use downloads is to make it easier for them to provide bug fixes it would be desirable to have the ability to track new firmware packages. > I *am*, however, opposed to including non-free firmware in main > because somebody feels that the non-free archive is not split > sufficiently finegrained yet. There's slightly more to it than splitting out the firmware section from non-free - things like how to handle it in the installer, for example. We used to ask if people wanted non-free during installation but don't do that any more. Some similar things may be desirable should a firmware section be created. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels
On Sat, Apr 02, 2005 at 06:15:04PM -0800, Thomas Bushnell BSG wrote: > Matthew Garrett <[EMAIL PROTECTED]> writes: > > This does present certain logistical problems for producing installers. > A free kernel can't support that hardware. It's a shame, but it's > true. Do you mean to say a free installer rather than a free kernel here? -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
On Mon, Mar 14, 2005 at 11:36:22AM -0500, David Nusinow wrote: > Aren't scc.debian.org (or perhaps various different hosts for each SCC) part > of > the plan in the email? I don't think anyone wants to break alioth further. The plan for scc.debian.org was for unstable plus snapshots of that. If any of the SCC ports want to produce actual releases it's likely that they will need some extra space somewhere for that. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of PHP5?
On Tue, Apr 26, 2005 at 12:15:38AM +0200, Piotr Roszatycki wrote: > I'd like to ask one more time: where is mailing list, the repository, > project page? It doesn't seem like open project. > Cooperation? A little less conversations, more action, please. Do you know > "The cathedral and the bazaar"? > Hijacking? For 10 months there are no packages. I should start MIA > procedure. The ITP seems like to be orphaned. This goes both ways, though: the packages you've produced are very different to the existing PHP packages and fairly unusual in terms of just being plain Debian packages (I'm thinking mostly of yada here). Doing more incremental changes would make it much easier for people to pick up and work with what you've done. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of PHP5?
On Tue, May 03, 2005 at 04:04:44AM +0200, Adrian Bunk wrote: > On Mon, Apr 25, 2005 at 07:57:13PM +0200, Joerg Jaspert wrote: > > And then there is this yada packaging you used. > Not that I was a friend of yada, but AFAIK it's allowed for a maintainer > to use whatever tools he wants for his packaging. > If this is wrong and I missed a part of Debian policy not allowing yada, > RC bugs should be filed against all packages using yada. The issue wasn't the use of yada per se, it was the use of yada in the context of something like updating PHP where there are existing packages and maintainers. Using one of the more obscure helper packages is a sign of lack of coordination rather than outright bugginess. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
On Wed, May 04, 2005 at 01:33:52PM +0200, Adrian Bunk wrote: > I didn't know a bug can have more than one submitter. > What's the syntax for the email to [EMAIL PROTECTED] for adding a second > submitter? Not entirely the answer you're looking for, but submit a duplicate bug and merge it. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A way _not_ to handle bugs
On Wed, May 04, 2005 at 04:01:52PM +0200, Andreas Barth wrote: > * Mark Brown ([EMAIL PROTECTED]) [050504 16:00]: > > Not entirely the answer you're looking for, but submit a duplicate bug > > and merge it. > No, don't do that. It's ugly as hell and may well annoy the maintainer by creating noise but it will do the job. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Regarding unresponsive Debian maintainers (was: Re: Open-Source environments for Java)
On Mon, May 23, 2005 at 06:14:45PM +0300, Cesar Martinez Izquierdo wrote: > I was refering to bugs without any activity (ignored bugs). If you mean bugs with no response ever rather than bugs that have just not seen any reponse recently saying something like "no response" rather than "no activity" might be clearer. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Regarding unresponsive Debian maintainers
On Tue, May 24, 2005 at 02:01:55AM +0300, Cesar Martinez Izquierdo wrote: > I think Debian would be healthier if tags were properly used in DBTS (as this > helps others to also fix bugs). I'd be really surprised if the major obstacle we're facing with regard to bug fixing were procedural things like this. Things like this can be helpful in locating things that might be interested in the BTS but they aren't a precondition for being able to do bugfixing work. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Example where testing-security was used?
On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote: > But setting up autobuilders doesn't require a new infrastructure > (and shouldn't require more than half a year). > Wasn't the infrastructure a prerequisite for woody and is working? It turned out that the central part of the existing infrastructure didn't scale up well enough to cope with the new architectures in sarge. The number of individual buildds asking which packages were avaliable to build created load problems - check the mailing list archives for more detail. I can't remember if improvements in redundancy weren't an issue either. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Example where testing-security was used?
On Mon, May 30, 2005 at 10:48:38PM +1000, Hamish Moffatt wrote: > On Mon, May 30, 2005 at 11:48:54AM +0100, Mark Brown wrote: > > It turned out that the central part of the existing infrastructure > > didn't scale up well enough to cope with the new architectures in sarge. > There are no new architectures in sarge. Oh, that's surprising. In any case, the problem with the new architectures would have been the increase in the number of buildds rather than the additional architectures per se - it's that which was the problem. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
On Wed, Jun 01, 2005 at 10:40:04PM -0700, Matt Zimmerman wrote: > On Thu, Jun 02, 2005 at 12:25:01AM -0400, Joey Hess wrote: > > If Debian treated our upstreams this way, I'd be suprised if we ever got > > any patches accepted upstream. > Debian does, in fact, treat most of its upstreams precisely this way. > Debian publishes a large portion of its changes primarily in the form of > monolithic diffs relative to upstream source. The last time I saw figures, > the usage of dpatch, cdbs, etc. was rising, but not yet the standard > operating procedure. If upstream is having to find and trawl through source packages in order to pick up changes then that's already a sign that there has been a failure in communication. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
On Fri, Jun 03, 2005 at 07:49:39AM +1000, Matthew Palmer wrote: > On Thu, Jun 02, 2005 at 12:47:30AM -0700, Matt Zimmerman wrote: > > The same logic applies to many bugs as well. Would it really be better to > > have an open bug report in debbugs, than a patch on people.ubuntu.com? > I'd prefer an open bug report in debbugs with the patch included. Me too, and to be fair at least some Ubuntu developers are putting things into the Debian BTS like this. I've generally had pretty good experiences with this myself. That said, I was informed today that there's a policy that when bugs are submitted the patch has to be put on people.ubuntu.com and linked to in the report rather than being included in the report, which did strike me as rather strange. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
On Fri, Jun 03, 2005 at 12:32:14AM +0100, Martin Michlmayr wrote: > occasions that their patch policy is less than optimal. While some > personally agree with me, it's their policy and unfortunately it won't > change... however, maybe there's still hope, now that more people are Has there been any explanation for the policy? I'm having a hard time thinking of any sensible reasoning. Obviously there's no problem with posting the patches on the web and including a pointer to them, or doing that if the patch is particularly enormous. It's just insisting on doing it all the time but regardless of what usptream want that seems odd. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
On Sat, Jun 04, 2005 at 08:14:45PM +0200, Petter Reinholdtsen wrote: > [Daniel Holbach] > > Do you have a particular case in mind? > I'm not going to provide examples, no. Would it be possible to provide some general description of the sorts of problem they see? -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
On Mon, Jun 20, 2005 at 05:58:11PM +1000, Russell Coker wrote: > Do you have any evidence to support yout claim that big mail servers are > configured to handle gray-listing servers differently from other mail > servers? Not quite the same thing as Pierre was describing but some mail server software have an option which allows mails where delivery needs to be retried to be directed to a separate machine. This can be useful if some sites that get a lot of mail are being very slow to respond (for example, timing out due to being down or heavily loaded) but it can cause noticable delays for mail that does wind up getting retried due to delivery slots being congested. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ftp-master, ftp and db .debian.org moving - hosting sought
On Mon, Jul 04, 2005 at 08:05:21PM +0200, Olaf van der Spek wrote: > True. But for example, is the current apt-get capable of contacting > another mirror if and only if the primary fails? For package downloads apt will try the sources in the order listed in sources.list, only trying subsequent ones if the first fails. For Packages downloads all the mirrors are hit each time, which is needed anyway to handle the case where a mirror is serving files but not updating. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian (was: Why does Ubuntu have all the ideas?)
On Fri, Jul 28, 2006 at 01:06:05PM -0600, Katrina Jackson wrote: > Okay here is another honest question: Do you really honestly think not > having co-maintainers for base packages is ever a good idea? What if > someone is busy? You don't really feel safe noticing your base packages > aren't being co-maintained since people are busy. Having co-maintainers is a tradeoff: on the one hand, it increases the number of people who in theory ought to be responsible for looking at a given package. On the other hand, it also makes it much easier for each individual to assume that someone else will deal with things that need to be handled. What works best depends on the situation - the package and the people involved. > Also back to the innovation issue: Don't your think having more > comaitainers there would be more innovation merging a package into Debian. > Is your goal just to make a package compile and not have RC bugs, or is it > to take a package and innovate in a way to make that package experience must > better for a Debian User? With co-maintainers this would be easier to pull > off. Sometimes that can help, sometimes it's not really relevant - for example, with things that need work over a wide range of packages maintainership isn't a big deal. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Re: Successful and unsuccessful Debian development tools
On Tue, Aug 01, 2006 at 07:19:19PM +0100, martin f krafft wrote: > Yes, and I wanted to know why he thought that is the case. I believe > Christoph has given a good account of the reasons. If you have > anything to add, please do! There's also the fact that well known teams like the installer and kernel teams use subversion. This makes it much easier for people looking for a template to follow to pick subversion. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Re: Centralized darcs
On Wed, Aug 02, 2006 at 03:34:34PM -0500, John Goerzen wrote: > On Wed, Aug 02, 2006 at 09:09:12PM +0300, George Danchev wrote: > > Care to describe how without using your SCM but apt-get source instead ? > apt-get source packagename > Really, what is the problem here? With a system like dpatch when one downloads the source package it includes any modifications made to upstream as a series of logically separate patches, hopefully helping to document what the purpose of each individual modification is or at least providing information on which sets of changes go together. This information makes it much easier to understand what has been modified for the package and why. This is especially useful where you're trying to do something like figure out behaviour which diverges from upstream. Similar information should be provided by a revision control system but normally only with the repository. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Code of Conduct on the Debian mailinglists
On Tue, Aug 15, 2006 at 01:47:59PM +0200, Wouter Verhelst wrote: > On Mon, Aug 07, 2006 at 11:39:51AM +0900, Miles Bader wrote: > > * E-mail generally has a "wider reach" -- it gets past corporate > > firewalls, (my company has never allowed external nntp connections), > > works even on strange systems, etc. > Point. Then again, if your corporate sysadmins don't want you reading > news, they probably don't want you reading mailinglists, either. It depends what they want to do: for example, one common policy is that clients don't directly access the internet, using proxies and internal servers for everything. That needn't have any particular restriction on content transferred associated with it. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autotools and programming style (was: Remove cdrtools)
On Tue, Aug 15, 2006 at 02:11:21PM -0500, Steve Greenland wrote: > No, you don't #ifdef all the users, you write multiple versions of a a > generic function that hides the differences, and compile the appropriate > one. Read the reference I gave. > Sure, you *could* do this with autoconf driving the compilation, but > nobody ever does. They just write a spaghettied mess in the main body of > the code, like the examples. On the bright side, with autoconf there's a plausible chance that people will be writing such spaghetti based on feature testing rather than writing such spaghetti based on platform detection defines exported by the system. Not brilliant but it's a bit of a win. > > it work in their systems (with absolutely no design goal in mind while > > porting). > Absolutely. But that doesn't justify crap code. The whole autoconf > system encourages minor patches and nasty #ifdefs rather than factoring > out what's different from what's the same. I don't really think it's fair to blame autoconf for people writing tasteless code: the whole masses of ifdefs thing is a fairly standard danger sign that crops up even without autoconf providing the defines and it does have a fairly standard solution. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problem sending to Alioth lists?
On Mon, Aug 28, 2006 at 06:48:31AM -0400, Roberto C. Sanchez wrote: > Out of curiousity, if this is such a good thing why are Alioth and > SourceForge the only two services (of the dozens of mailing lists from > half dozen or more services) which use this setup? Also, why is the > error message returned by the mail server not more clear? Due to it being more widely supported in MTAs and server load issues you'll often see a much weaker variant which only does sender address verification using DNS (checking that there is a resolvable MX or A record for the domain but not verifying that it can be used). From what you're saying you'll have been passing the weaker variants. The general idea with this class of checks is that if the sender does not care if the message is delivered (since they haven't provided a return address that can accept bounces they won't be informed of any errors) then the receiver may as well save the effort of trying the delivery. As with other anti-spam measures you will also see this deployed in conjunction with other measures so the individual checks aren't directly visible themselves: for example, the trigger levels for spam filtering or the timeouts used in greylisting could be adjusted based on the deliverabiliy of the sender. > > sender_canonical_maps = hash:/etc/postfix/canonical > No offense, but that is completely non-scalable. That only works for a > small number of users which does not change frequently. Anyhow, thanks > to 'Dato, I seem to have been able to convince mutt to play nicer with > your mail server. The usual approach is to ensure that your system generates a valid envelope sender by default. For systems that host users with many domains the default is normally chosen to be the underlying account on the hosting system. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: potential mass bug filing: sysvinit dependency
On Tue, Sep 05, 2006 at 01:44:57PM +0200, martin f krafft wrote: > also sprach Marco d'Itri <[EMAIL PROTECTED]> [2006.09.05.1330 +0200]: > > This may be a good time to remind maintainers that often > > a versioned conflict may be more appropriate than a versioned > > dependency. > Right. Most of these are probably added to ensure the avalibility of invoke-rc.d. IIRC doing something more obvious caused upgrade issues at the time due to issues with having both sysv-rc and file-rc. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: potential mass bug filing: sysvinit dependency
On Tue, Sep 05, 2006 at 10:28:43AM -0300, Henrique de Moraes Holschuh wrote: > On Tue, 05 Sep 2006, Mark Brown wrote: > > invoke-rc.d. IIRC doing something more obvious caused upgrade issues at > > the time due to issues with having both sysv-rc and file-rc. > invoke-rc.d was added to sysv-rc and file-rc at almost the same time, we > didn't botch THAT transition at all, thank you very much. Well, I'm glad that I didn't say that the transition had been botched, then. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: (proposed) Mass bug filing?for debconf "abuse" by using low|medium priority debconf notes?
On Thu, Sep 14, 2006 at 07:41:53PM +0200, Christian Perrier wrote: > As a conclusion and combining both, I would really like to unsderstand > why so many fellow developers insist on using LOW priority NOTES in > their debconf templates and use them in maintainer scripts. Speaking for my own packages it's a combination of policy requirements to warn about device files and straight translations of pre-Debconf maintainer scripts. At a guess the latter reason (plus new notes added before NEWS.Debian was introduced) is the most common. Previously the general style for Debian was fairly chatty maintainer scripts. For the packages warning about device files the reason is likely to be policy section 10.6 "Device files" which requires notification to the user when creating device files and suggests using a low priority Debconf message to do this: | If a package needs any special device files that are not included in | the base system, it must call `MAKEDEV' in the `postinst' script, | after notifying the user[1]. ... | [1] This notification could be done via a (low-priority) debconf message, | or an echo (printf) statement. A note seems to be the only way for Debconf using packages to comply with this: they aren't allowed to output except via Debconf and that seems the most appropriate template type. It'd probably be worth getting policy updated here. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A plan to get rid of unnecessary package dependencies
On Tue, Sep 26, 2006 at 06:28:50PM -0700, Russ Allbery wrote: > Christian Aichinger <[EMAIL PROTECTED]> writes: > > Maintaining such information somewhere within the library package would > > be possible, but that sounds like a more complex plan, and I doubt that > > many library maintainers know if their lib uses such tricks or not. > does still apply. As a first approximation perhaps libraries with constructors or destructors could be assumed to always be required? That would be more conservative than required but perhaps so conservative as to be useless. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: replicating package compression used by dpkg-deb
On Thu, Sep 28, 2006 at 03:45:16AM -0700, Ian Bruce wrote: > It appears that dpkg-deb does not exec gzip, and it's not dynamically > linked with anything except glibc. I suppose that it's statically linked > against zlib1g or something like it. So the question is, how can the > exact compression algorithm used by dpkg-deb be made available for > another piece of software? Is it something that's well-specified, or is > it liable to change at any moment? dpkg is statically linked against zlib (you really don't want to break the ability to unpack packages if you can avoid it). I presume dpkg-deb is too though I haven't checked. The precise output of zlib can vary between versions and depending on the options used when running it. > Of course the whole problem would be radically simplified if the > "--rsyncable" option were used when the packages were being built. Does > anyone know what the rationale for not doing that is? It's not implemented by zlib. There is an open bug report asking for it with a link to a patch but I wasn't happy with the patch since it is enabled using an environment variable and wanted to rework it to have an API before forwarding upstream. I've not yet had sufficient enthusiasm to do that; current progress suggests that you shouldn't hold your breath on that one. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: replicating package compression used by dpkg-deb
Followup to the other lists too... On Thu, Sep 28, 2006 at 12:15:21PM +0100, Mark Brown wrote: > On Thu, Sep 28, 2006 at 03:45:16AM -0700, Ian Bruce wrote: > > > It appears that dpkg-deb does not exec gzip, and it's not dynamically > > linked with anything except glibc. I suppose that it's statically linked > > against zlib1g or something like it. So the question is, how can the > > exact compression algorithm used by dpkg-deb be made available for > > another piece of software? Is it something that's well-specified, or is > > it liable to change at any moment? > > dpkg is statically linked against zlib (you really don't want to break > the ability to unpack packages if you can avoid it). I presume dpkg-deb > is too though I haven't checked. The precise output of zlib can vary > between versions and depending on the options used when running it. > > > Of course the whole problem would be radically simplified if the > > "--rsyncable" option were used when the packages were being built. Does > > anyone know what the rationale for not doing that is? > > It's not implemented by zlib. There is an open bug report asking for > it with a link to a patch but I wasn't happy with the patch since it > is enabled using an environment variable and wanted to rework it to have > an API before forwarding upstream. I've not yet had sufficient > enthusiasm to do that; current progress suggests that you shouldn't hold > your breath on that one. > > -- > "You grabbed my hand and we fell into it, like a daydream - or a fever." > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: replicating package compression used by dpkg-deb
On Thu, Sep 28, 2006 at 06:50:53AM -0700, Ian Bruce wrote: > It turns out that the zlib1g-dev package contains a program called > "minigzip" in source form. This is what's needed; "minigzip -9" > reproduces exactly the compression used by dpkg-deb, unlike regular > gzip. This may not produce identical results if the version of zlib used to produce the package differs from that on your system. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: planet.debian.net and DWN (was: HI, I am a honest user of China, I love linux especially Debian distribution , I think Debian is the greatest linux distribution , but nowdays, the debian weekly ne
On Mon, Oct 23, 2006 at 08:45:01AM +0200, Stig Sandbeck Mathisen wrote: > Ron Johnson <[EMAIL PROTECTED]> writes: > > IIRC, he sent an email out a few days ago saying that > > http://planet.debian.net/ now serves most of the purpose of DWN. > Unfortunately, at least for me, planet.debian.net contains an > aggregation of more than just debian-related blog entries. I believe that Ron was actually thinking of http://times.debian.net/ rather than planet. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new POSIX sh policy
On Sun, Nov 12, 2006 at 01:51:18PM +0100, David Weinehall wrote: > On Sat, Nov 11, 2006 at 11:10:52PM -0600, Manoj Srivastava wrote: > > It is my opinion that we would be better off dumping this > > whole shell specification thing in policy, standardizing on bash, and > > let it go. > You know, people base embedded systems on Debian. And as long as the > ballpark of all initscripts are written in POSIX shell, it's really easy There's also the people on desktop systems who find that other /bin/sh implementations offer enough of a performance win to be worth using for scripts, even though they still use bash interactively. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Re: Why not scan for unmaintained packages and orphan them?
On Wed, Dec 06, 2006 at 01:41:18PM -0500, Matthias Julius wrote: > I have started doing some l10n work about a month ago. Some of the > bugs I filed have not seen any reaction from the maintainer. While > that is not yet surprising I came across a number of l10n bugs > providing translations that are half a year old or older. This is > frustrating to the translator to see his work collecting dust in the > BTS for such a long time. I don't see how forcing people to reply to bugs helps here. What's really needed is to convince maintainers to respond promptly and constructively to bug reports. That's a much harder problem, and much harder to automate. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BTS: Why no "invalid" or "notabug" tag?
On Mon, Dec 11, 2006 at 10:01:58AM +0100, Marc Haber wrote: > On Sat, 9 Dec 2006 11:08:56 +0100, Andreas Metzler > >Afaik there are no changes in behavior. blocks are only > >informational. > If this is true, it is a _TOTAL_ surprise for me. We need better > documentation. IIRC it also generates mail to the blocked bug when the blocking bug is closed. Other than that I'm not sure what else I'd expect it to do. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: possible grave bug in debian-installer or ifupdown?
On Tue, Dec 19, 2006 at 11:47:57AM +0100, Peter Palfrader wrote: > I have at least one server machine where allow-hotplug does not reliably > bring up the interface ever. I had a bug report from a NIS user which turned out to be a result of them experiencing the same symptoms. They said they might file a bug report against d-i though I'm not sure if they did or not. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: amd64 uploads
On Fri, Apr 07, 2006 at 12:42:30PM +0200, Goswin von Brederlow wrote: > FTBFS. All of those you can probably summarize under bit-rot. The > Debian-amd64 team has now started doing some aggressive porter NMUs > (policy allows them after 7 days so don't come screaming if we NMU > some month old bug). Can I suggest filing bugs about these things with a severity higher than wishlist? -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Uploading packages built against testing? (was: openssl will block bacula into etch?)
On Mon, May 29, 2006 at 10:27:45AM +0200, Frank K?ster wrote: > Would it be acceptable to build bacula (or any other package with that > problem) in an etch environment, or on sid with manually installed > libssl from etch, and upload that to unstable? After checking that it > works in unstable, of course. That wouldn't help unless you uploaded for all architectures: the buildds would build against unstable (there are other problems with doing this too - see the list archives). -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CDBS and dh_install
On Sun, Jun 11, 2006 at 09:06:28AM +0200, Thomas Weber wrote: > Well, how do I know if I have to deviate from the debhelper scripts at > some point in the future? In fact, if I bump up the compat level, I > might very well need to change my scripts. That's a bit different: updating the debhelper compat level is updated by the maintainer explicitly changing the package rather than by installing a new version of debhelper. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: code cpustat.c
On Fri, Jun 30, 2006 at 04:18:58PM +0300, Ozgur Karatas wrote: > ps and top command gives the ram state. i am doing this to see cpu's load > and usage. top reports these. For example: | Tasks: 112 total, 2 running, 109 sleeping, 1 stopped, 0 zombie | Cpu(s): 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#377697: New version of squid hangs at startup
On Tue, Jul 11, 2006 at 01:42:08AM +0100, Stephen Gran wrote: > 4. Make it a runtime startup decision. More work to implement, but for > things like this, it seems like a reaonably sane choice. Having done this before it's fairly straightforward to achieve, even if you can't assume libc support for epoll(). At startup, try to use epoll_create() as you need to anyway. If that fails then degrade to using poll() or whatever. >Probably still > #ifdef'ed to only bother checking on linux, but still. This is needed anyway: the relevant structures, syscalls and libc entry points are only availiable on Linux and the syscalls can't be worked around. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: not starting packages at boot
On Sun, Jan 23, 2005 at 10:53:48AM -0600, Steve Greenland wrote: > /etc/default/foo. I could tolerate it if packaged defaulted *on*, but it > seems the habit is to default off. And more importangly, as others have > said (every single time this comes up), there is an *existing* mechanism > to accomplish this that doesn't require modifying every daemon package: > invoke-rc.d and policy-rc.d. The main case where this sort of thing is useful is the case where the package can't be shipped with a sane default configuration for some reason and the init script can't detect this situation. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: anarchism_7.7-1.deb
On Thu, Sep 23, 1999 at 08:52:41PM +0200, Bjoern Brill wrote: > Taking the risk to burn like hell: I think the "exhaustive exploration" > of ANY political theory and practice is VERY misplaced in ANY Linux > distribution. I would say the same thing about "The top 1000 FAQ on > home-made apple pie", but nobody has packaged that (yet). IIRC, it was this very package that prompted the last discussion about setting up a data section. What came of that? -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgphEt7v9tvpS.pgp Description: PGP signature
Re: problem with leafnode in 2.1r5
On Sun, Mar 12, 2000 at 08:50:59PM +0100, Christian Surchi wrote: > I'm using leafnode 1.6.2-3 in slink 2.1r5. > It segfaults in many unpredictable cases. > ...or often during the connection to a server. I can't repeat this problem > and I don't know why. Does anybody have this problem or know about it? It looks like a bug. I may even have this particular on file somewhere. The best thing to do is probably to upgrade to a newer release - 1.6.2 is very old and has some nasty bugs. There is a Slink package for the latest release (1.9.11) at ftp://ftp.tardis.ed.ac.uk/users/broonie/debian which comes with my usual "I haven't tried to install this let alone use it, but it built cleanly" warning. You'd probably get an answer faster by either contacting the maintainer (me) or reporting a bug. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgpsPo6UronOJ.pgp Description: PGP signature
Re: Bug#60753: mutt: /etc/Muttrc should not use colors
On Mon, Mar 20, 2000 at 02:30:55AM -0600, Zed Pobre wrote: > On Mon, Mar 20, 2000 at 04:46:04AM -0300, Nicol?s Lichtmaier wrote: > > Using the Space and the Backspace keys for up and down movement is absurd, > > it's even stupid. Backspace is back-space. Those keybindings where thought > > for keyboards without arrows, and those keyboards no longer exists... > Or for terminals without valid cursor-key translations, and those > terminals and connections DO exist. Or for people who don't want to > have their hands leave the home position, and those people DO exist. It also gets used in things like newsreaders (well, Gnus at least) where the cursor keys move something other than the text of the message being viewed. > I almost exclusively use the spacebar to page down, and I sometimes > use backspace to page backwards. Different != stupid, and I'd point > out that your attitude is probably offending people by now. Indeed. Besides, putting too many changes into the default configuration is only going to irritate people - a package should probably behave much as a user familiar with the program from elsewhere would expect. Old users get confused, and new users get confusing help from old users. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgpd2BtnVEEIR.pgp Description: PGP signature
ITP: GOB [Was: Re: GOB package?]
On Tue, Mar 21, 2000 at 09:38:50AM -0500, Peter Teichman wrote: > A quick search through debian-devel and wnpp yields no ITP for Indeed. I'd been wondering if it were packaged under an unusual name or something. > gob.. Maybe someone would like to pick it up? I'll do it myself if nobody else has a burning desire to, although quite probably on the basis that anyone else who wants to take it is welcome to. >From the web page (http://www.5z.com/jirka/gob.html): GOB is a preprocessor for making GTK+ objects with inline C code so that generated files are not editted. Syntax is inspired by java and yacc or lex. The implementation is intentionaly kept simple, and no C actual code parsing is done. The license is GPL. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/
Re: RBL report..
On Sun, Mar 26, 2000 at 11:05:40AM +0200, Nils Jeppe wrote: > ORBS blocks all open relays. A lot of people have open relays. Since open > relays still do not have any reason for existence other than admin > ignorance, the "correct" way here would be to block all open relays and ORBS also blacklist sites for other reasons, such as if their probes are firewalled out. This will, for example, catch sites that automatically firewall out sites that attempt to relay through them - the site notices the first check, blocks the rest and gets added to the list. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgph7wmXnQhuf.pgp Description: PGP signature
Re: GOB
On Mon, Mar 27, 2000 at 12:12:26AM +1000, Robert Graham Merkel wrote: > There has been some discussion about packaging GOB on the lists. > If they are OK and a developer is prepared to sponsor me I'd love > to have the packages added to the distribution. I already uploaded a package to Incoming. However, I'm not particularly attached to it (I only packaged it because I need it to build another package) so you're welcome to take it. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgplqg2KScvyE.pgp Description: PGP signature
Re: RBL report..
On Tue, Mar 28, 2000 at 06:16:43PM +1000, Hamish Moffatt wrote: > I have received one legitimate email (from a customer) which failed > the ORBS check, so I won't be rejecting based on that. But I see no > reason not to reject on RBL (which Debian already does), and > probably RSS and DUL too. That roughly matches my experience - ORBS blocks far too much to use in more than an advisory manner, but the other RBLs don't create any problem. Of course, neither of us sees the traffic Debian is seeing and that's what any decision needs to be based upon. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/
Re: RBL report..
On Wed, Mar 29, 2000 at 04:41:15PM -0700, Jason Gunthorpe wrote: [Providing reliable SMTP services to people on dialup IP, eg UUCP-over-TCP] > It would be better for someone else to provide a service like this. I have to say I'm extremely surprised that if ISPs in the US are as incompetant as people seem to find them nobody's providing anything like this. Apparently, it's the standard model in some countries - you buy connectivity from one place, mail from another. I'd also be interested to know how the ISPs are managing to throw away so much outbound mail, although I'm not sure I want to. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgpkVlFPiocmb.pgp Description: PGP signature
Re: ATTN: pjw@edmc.net
On Fri, Mar 31, 2000 at 11:19:40PM -0500, Branden Robinson wrote: > On Sat, Apr 01, 2000 at 09:45:35AM +1000, Hamish Moffatt wrote: > > Of course, you could always just get the work done and email back > > to [EMAIL PROTECTED]; since it'll go through Debian the > > email will indeed arrive just fine. > Blacklisters may have the right to speak and *say* what they think I should > do, but they have no right to be heard. > If you have the right to refuse to listen to me on my terms, I have the > right to refuse to listen to you on yours. You should at the very least mention why you're closing the bug report. It may, for example, be the case that user is unaware that their usual mail system uses the DUL or whatever. Randomly closed bugreports will just annoy people without actually helping them realise that you find yourself unable to talk to them and what they can do to work around this situation. Not that I would advocate doing this in the first place. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgptNT0Xpql6Q.pgp Description: PGP signature
Re: [Election Results] Official and Final
On Fri, Mar 31, 2000 at 11:40:43PM +0200, Josip Rodin wrote: > Okay, 62.43% isn't so bad, but it doesn't really take that much effort to > vote in Debian, IMHO. You've just got to decide how to vote first. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgpMMgvpN27h5.pgp Description: PGP signature
Re: Pgcc in Deb
On Sat, Apr 01, 2000 at 10:28:56PM +0200, Romain Chantereau wrote: > I looking for a pgcc debian distribution/package... But, nothing ! > I don't know why. > Is someone able to explain ? Basically, nobody voulenteered to maintain it. From the PGCC FAQ: | Q: Are there Debian packages of PGCC? | A: No. While some people have expressed an interest in them, nobody has | actually done the work yet. If you are interested the people to speak | to are probably the Debian gcc maintainers. If you want to use it it's pretty trivial to install from source. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgpIeEscjdi4N.pgp Description: PGP signature
Re: ATTN: pjw@edmc.net
On Sat, Apr 01, 2000 at 04:00:57PM -0500, Branden Robinson wrote: > On Sat, Apr 01, 2000 at 04:02:43PM +0100, Mark Brown wrote: > > You should at the very least mention why you're closing the bug report. > Did you bother to read my close message? Obviously not. I did in fact > include an explanation of why I was closing the bug. I didn't look at any particular bug report. When you said that you would close such bugs without comment I assumed that you meant exactly that. Apparently this is not the case - my apologies. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgpHVXl7qeEs1.pgp Description: PGP signature
Re: Pgcc in Deb
On Mon, Apr 03, 2000 at 04:17:51AM -0700, Joseph Carter wrote: > We all know how screwed up the former is. The latter has (and has had for > some time) several very obnoxious bugs which result in bad code on certain Definately - pgcc should be approached with some caution. It's also been known to play up with XFree86 and Mesa. > non-trivial applications. Those patches and improvements found in pgcc > get added to egcs as soon as they are known not to do stupid things anyway That's not entirely true - some of the stuff in pgcc isn't in mainline gcc because there is no copyright assignment on file and no likelyhood of getting one. Other bits are probably stable enough on Intel but need work to avoid pessimising or bugs on other architectures. > so it's worthwhile simply to stick with egcs and use the optimizations it > provides. > In almost all cases you will not be seeing any noticable difference in > execution speed. Depends on the program, of course. For all the effort it takes, it's often worth trying a pgcc build of compute-intensive programs, although you should be able to check that it is correctly optimized - not to mention do some benchmarking to verify that you're actually getting something worthwhile from the exercise. Most programs aren't that compute-intensive, and gcc is more reliable - just blindly using pgcc is probably not a good idea. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/
Re: BTS not showing my bugs
On Wed, Aug 30, 2000 at 04:57:51PM -0700, Joey Hess wrote: > All statically updated BTS pages are broken, please see DWN for details. Might it be an idea to put a notice about this on the web page? It'd avoid a lot of confusion. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgpaWRJ983UwX.pgp Description: PGP signature
Re: gpm and X problem investigated
On Fri, Sep 01, 2000 at 08:58:24AM +0200, Rainer Dorsch wrote: > The middle mouse button works flawless, if you select the Intellimouse > protocol: Of course, it's rather non-obvious that you need to select anything other than the protocol your physical mouse supports (or it was when I tried a Potato install). -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgpwyn7TBTOB2.pgp Description: PGP signature
Re: Python 1.6 released and GPL incompatible
On Wed, Sep 06, 2000 at 09:50:07PM -0500, Branden Robinson wrote: > On Wed, Sep 06, 2000 at 11:37:17AM -0700, Sean 'Shaleh' Perry wrote: > > I am disappointed that RMS is fighting over something as trivial as a > > company asking that legal issues be settled in their home state > > (country). This is common practice. > I don't think it's trivial at all. Consider that UCITA is the law of the > land in Virginia, which is where CNRI are trying to corral all > interpretation of the Python license. If contracts are to be interpreted There's also the fact that IP rights work much better if you make an effort to enforce them. (IANAL, of course) -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bug database not updated?
On Wed, Sep 06, 2000 at 08:23:40PM +0200, Santiago Vila wrote: > Static pages are known to be outdated. I'm sure I asked this previously, but could we not add a note to that effect on at least the front page? -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with mail system? [Fwd: Returned mail: User unknown]
On Wed, Sep 06, 2000 at 11:33:21PM -0400, Buddha Buck wrote: > > It says, in plain English, "failed to find host name from IP address". > It says in plain English, "administrative prohibition (failed to fine > host name from IP address)" > Perhaps it's from being too geeky myself, but Branden's explanation > (the recipient of the error message is not welcome on *THEIR* Internet > under the reasoning that they're ... refusing connections from machines It was the bit about "dialup trash" - inability to get reverse DNS working is a different issue. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
On Mon, Sep 11, 2000 at 04:47:21PM +0200, Bernhard R. Link wrote: > I believe, that one diff is much more better than many diffs. > This only works, if the diff's are independend or one diff is diff are on > the top of each other. So I do not see the advantage of many diffs. The advantage of having multiple diffs is that distinct changes can be kept distinct. You do need a system for ensuring that the diffs are applied in the correct order and so on, but given that multiple diffs are very much nicer. It becomes very much more obvious what has been changed and how, not to mention far simpler to adjust the set of changes that have been applied. As an added bonus, the handling of upstream source that include patches is more elegant. It's just the implementation that sucks: the idea of having multiple diffs is good. > If it is to have some diff included that should be updated I would prefer > to create an local cvs-repro, put the orig in it, tag it, patch it with > the debian diff, make an branch, patch the branch, and merge everything > together and produce an new diff and remove the local cvs-repro. Aside from requiring CVS this looses information for anyone without access to the repository. That's a hassle when you get maintainer changes and makes the packaghe source itself much less useful than it could be. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgpyK9fM0G0BN.pgp Description: PGP signature
Re: wnpp bug reports
On Fri, Dec 22, 2000 at 06:03:28PM -0500, Bob Hilliard wrote: > Josip Rodin <[EMAIL PROTECTED]> writes: > > Yes, put -devel in Cc: or (X-Debbugs-Cc:) fields. > When I have done this, the report shows up on -devel the same as > I submitted it - the Bug Number doesn't appear. If you CC it it will - that's just a regular mailing list posting. If you use X-Debbugs-Cc it will go through the BTS first. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgpEPFtochrQo.pgp Description: PGP signature
Re: Close list
On Sun, Dec 24, 2000 at 05:53:36PM +0100, Josip Rodin wrote: > It has been said in a related thread on a mailing list that shall not be > named :) that making a DNS lookup for hosts carrying the blacklists on each > delivery would slow it down. It has also been said that this isn't hard to > work around, though. It's not generally that bad - generally not even noticable when compared to all the other delays one is likely to encounter. > FWIW I like the X-RBL-Warning headers. Spam to the Debian mailing lists tends to be especially annoying since the spammers always seem to hit each and every mailing list (or at least, a large number of them), which makes each spam much more noticable. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/
Re: Close list
On Sun, Dec 24, 2000 at 10:38:50PM +0100, Josip Rodin wrote: > Oh yeah. If only there was some way of automatic killing of such spams, sent > to more than X (say, 5) mailing lists... something that would remember the > last X-1 mails from the same domain name (or whatever) and kill off the > remaining attempts. Without killing all the messages crossposted to all the port lists (andu usually one or two others). :-) -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/
Re: Huh, gcc 2.95.3?
On Tue, Jan 02, 2001 at 11:42:22AM +1100, Daniel Stone wrote: > Ack!(tm). Not shades of rh7, I hope? I know that people using sid (like > myself) are willingly sado-masochists, but a CVS GCC? GCC 2.95.3 is in final testing and due for release RSN, making it a somewhat different situation. It's also binary-compatible with 2.95.2. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgpxUWpYjngZj.pgp Description: PGP signature
Re: bugs + rant + constructive criticism (long)
On Wed, Jan 03, 2001 at 09:08:25PM +0200, Anton Zinoviev wrote: > On 3.I.2001 at 19:31 Peter Makholm wrote: > With one exception: > > Reply-To munging does not benefit the user with a reasonable mailer. > > People want to munge Reply-To headers to make ``reply back to the > > list'' easy. But it already is easy. Reasonable mail programs have two > > separate ``reply'' commands: one that replies directly to the author > > of a message, and another that replies to the author plus all of the > > list recipients. > This doesn't apply to the Debian mailinglists. Why not? -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgpTu9Rzhd9MU.pgp Description: PGP signature
Re: bugs + rant + constructive criticism (long)
On Wed, Jan 03, 2001 at 08:44:49PM -0500, Adam McKenna wrote: > On Wed, Jan 03, 2001 at 08:41:06PM -0500, Branden Robinson wrote: > > If I'm already replying to a list, I'm not going to waste bandwidth by > > mailing you personally as well. > So what you're saying is that you're purposely ignoring people's > Mail-Followup-To when it suits you, while insisting that others abide by > yours? That sounds kind of ridiculous to me. OTOH, the behaviour in the absence of any Mail-Followup-To: should be to reply to either the list or the sender but not both. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/
Re: ITP: crack
On Thu, Jan 04, 2001 at 03:04:07PM +0100, Andreas Voegele wrote: > Pawel Wiecek writes: > > I'd like to package CRACK, the well know password security checker. > > It has a nice licence, derived from Artistic and is no doubt a > > useful tool for an administrator. > Have you looked at the package john? AFAIK john can do anything crack > can do. john is a single process cracker - it can't distribute the load over multiple CPUs and multiple machines. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/
Re: bugs + rant + constructive criticism (long)
On Thu, Jan 04, 2001 at 07:27:57AM -0800, Jim Lynch wrote: > But in truth, you should be -filing- bugs against things you find > wrong, for the following reason: not all developers read debian-devel, > so your concerns, as important as they may be, may or may not reach > the responsible parties, and without a subject line more suggestive of Or may see it but not remember about it when they update their package. It's not like we have a bug tracking system purely for ornamentation - it's there to help us track bugs. Given a well defined mechanism for bringing problems to people's attention it seems silly not to use it. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/
Re: our broken man package
On Thu, Jan 04, 2001 at 10:35:56AM -0800, Joey Hess wrote: > Is that even necessary? I mean, alternatives makes sense for programs > like MTAs and editors, which have a diverse range of interface, > functionality, and use. Man formats a page and displays it in $PAGER; I'd always thought the intention was exactly the opposite - where one doesn't care which program one gets so long as it provides the functionality required one uses an alternative. If, for example, I run /usr/bin/vi I expect to get something that understands standard vi commands and command line arguments. It's just that there are multiple programs that can do this and each of these programs can have additional features so you might want to have a seleciton installed simultaneously. > its usage is pretty set in stone since a long time ago. One man program > might be faster or more secure, or less buggy than another, but it's > going to look and operate the same, so it seems everyone is going to > gravitate to the best one available, so why bother with alternatives for > the rest? Of course, this also makes sense. Perhaps if multiple man programs are packaged it would be more useful for them to conflict with each other and just include the man executable directly. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgp6z1ZrqSaQO.pgp Description: PGP signature
Re: lilo.conf
On Sat, Jan 06, 2001 at 06:06:47AM -0600, Gordon Sadler wrote: > Just FYI, as of now, the package available in sid/unstable does NOT ask > to save your /etc/lilo.conf. If you install the current deb backup your > lilo.conf file first. If you've done the upgrade already note that it does save it itself to /etc/lilo.conf.old (although it does this each time it's reconfigured so you'll only have the previous lilo.conf in there). -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgpO9GSNETMOA.pgp Description: PGP signature
Re: can the bug reporter close a bug? [was:Re: Bug#81396: root shell fscked after upgrade to woody]
On Sun, Jan 07, 2001 at 01:09:12PM -0600, Nathan E Norman wrote: > So does this mean the submitter can close their own bug or not? I'm > not sure what you mean by "the BTS doesn't care" Anyone can close a bug - the BTS doesn't actually check where the close command comes from. The unenforced standard is that only the submitter and the maintainer responsible for the package should close a bug. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgpFdO3db8Wqq.pgp Description: PGP signature
Re: Developer Behavior
On Wed, Jan 10, 2001 at 02:34:39AM +1100, Russell Coker wrote: > But I think that there is some merit to having discouragement towards running > unstable on production machines. I've been getting flamed immensely recently > about my lilo package that over-wrote lilo.conf incorrectly. Even though: You're probably getting flamed more because it's a "this is just wrong" sort of bug - there's no way it was ever going to be safe to install that version of the package. While users should expect that unstable may be broken some of the time there's also the expectation that developers will try to minimse this breakage or (if it's unavoidable) make an effort to warn people (as with the current INN package saying "I'm about to hose your system - are you sure?"). > The people who flame the developers contribute nothing. When they report > bugs that exist they invariably do so after more polite people have already > reported them and the developer has started work. Then work has to be > interrupted to spend time fighting off flames. This I would agree with. > I don't think that unstable should be limited to Debian developers, but I > think that it should be restricted to discourage people who aren't reading > debian-devel. What if we setup the servers to use a different random > password every month that was only announced on debian-devel? It would be nice if people actually used unstable. Besides, there's still no guarantee that people are actually going to read the warnings or even that they will be warned before whatever it is causes the breakage. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/
Re: /etc/hostname
On Thu, May 29, 2003 at 09:20:34AM -0500, Steve Langasek wrote: > However, I've seen problems caused by the use of the short name only in > /etc/hostname (mostly mail-related, maybe?) and I systematically change > this to hold the FQDN on my systems. Haven't filed a bug about this, > because I'm not sure if it's a real bug, or if this just happens to be > the easiest kludge for working around the other symptoms I see. It can cause problems for other programs too - Leafnode will refuse to run if it can't work out a fully qualified hostname for the machine and I've seen other server software get upset in various ways. -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
