Re: Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT
On Wed, Feb 18, 2009 at 05:47:57PM +, Iulian Udrea wrote: > 2009/2/18 Marc Singer > > > It was not my intention to shut you down. I am just trying to figure > > out how far you've gotten in packaging the program. > > > Sure, no problem. I haven't gotten too far in packaging it because of > bug #407722. I've also been encouraging the author to rethink the configuration of cgit to be more similar to gitweb. It's not a show stopped, but it would make cgit easier to integrate. > > There is a serious blockage in pushing cgit into the archive because > > libgit.a isn't available from git-core. I've been chatting with the > > git-core maintainer to see if there will be a change in this. > > > > > Indeed, unfortunately, this is one of the reasons why I stopped working > on packaging it for now. As far as I can see, you're already talking to > Gerrit regarding libgit.a. Perhaps we will find a way to get it back. I'm going to put my package, so far, into git on alioth, in the mean time. If I have some time, I'll ping the git list as well. Cheers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT
On Wed, Feb 18, 2009 at 06:50:55AM +, Iulian Udrea wrote: > 2009/2/18 Marc Singer > > > Is your package patch available so I can review it? > > > > Also, it doesn't look like you're a DD. Why are you so keen to > > maintain it? > > > > Yes, you're right, I'm not a DD. Anyway, I've had no idea that you're a > DD. > That being said, perhaps it's better to submit wnpp bugs using your d.o > address? Sorry about that. My debian address is the same, e...@debian.org. > > On the other hand, please ignore my intention to maintain this. > > I'm sorry for this. It was not my intention to shut you down. I am just trying to figure out how far you've gotten in packaging the program. There is a serious blockage in pushing cgit into the archive because libgit.a isn't available from git-core. I've been chatting with the git-core maintainer to see if there will be a change in this. > > Cheers > > Iulian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT
On Tue, Feb 17, 2009 at 06:30:58PM +, Iulian Udrea wrote: > Hello Marc. > > I have already packaged this. I was going to submit an ITP and upload > it through a sponsor in the next days. > > So, I would like to take care of this. May I take over this ITP? Is your package patch available so I can review it? Also, it doesn't look like you're a DD. Why are you so keen to maintain it? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT
Package: wnpp Severity: wishlist The upstream build of cgit requires a download of git to build libgit which this package links statically. Thus, this package practically depends on a change to git-core. http://hjemli.net/git/cgit/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Buildd maintenance for dummies
On Tue, Sep 05, 2006 at 07:58:18PM +0200, Luk Claes wrote: > Hi > > I recently took over the buildd maintenance of signy.farm.ftbfs.de, a mips > buildd for experimental, sarge-backports, sarge-volatile and non-free > (whitlisted packages). I actually started in helping with the buildd > maintenance of odin.farm.ftbfs.de which is a similar buildd for sparc. > > As newbie I made some stupid mistakes... I hereby want to announce a wiki page > to make sure newbies in buildd maintenance don't make this mistakes again :-) Hurah! > The wiki page [0] only talks about answering to build logs as there is already > some decent information for setting up and configuring a buildd host and > wanna-build [1] [2] [3]. > > Don't hesitate to add or improve content of the page, it's a wiki page after > all... > > Cheers > > Luk > > [0] http://wiki.debian.org/Buildd/BuildLogs > [1] http://kmuto.jp/open.cgi?buildd > [2] http://www.debian.org/devel/buildd/ > [3] https://db.farm.ftbfs.de/farm-reference/index.en.html > > -- > Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D > Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[PATCH] fix for fglrx driver package builds
The ATI fglrx driver can produce debian packages for easy installation on Debian systems. Unfortunately, the kernel source package build is broken in the latest ATI releases. I'm not sure exactly when it broke as I have had it installed on a machine for several months. Moreover, the driver *does* work without the kernel module, but you won't experience any 3D acceleration and there will may be some glitching with the mouse pointer. There are a couple of caveats with this patch. The ATI package isn't really patchable. What you can do is use the --keep switch so that the archive unpacks to fglx-install/. You can then apply the patch to that directory. Change directories into fglx-install/ and run # ./ati-installed 8.28.8 --buildpkg Debian/etch to perform the build. Debian packages will be saved to the parent directory. The second caveat is that this patch only fixes the build for etch. There are several versions of the rules files, etch, experimental, and sid. If you want to build for these, you'll have to make the same change to the other rules files. Finally, I'm not really sure why the original code failed. I didn't spend enough time with this to determine the root cause. As we are using Debian, I am confident that tar supports the -j switch so there ought to be no problem with change. Cheers. diff -ruB fglrx-install-original/packages/Debian/overlay/etch/rules fglrx-install-fixed/packages/Debian/overlay/etch/rules --- fglrx-install-original/packages/Debian/overlay/etch/rules 2006-08-17 09:10:18.0 -0700 +++ fglrx-install-fixed/packages/Debian/overlay/etch/rules 2006-09-03 18:09:22.0 -0700 @@ -214,7 +214,7 @@ $(KSRCDIR)/debian (cd debian/$(PKG_kernel_src)/usr/src \ && chown -R root:src modules \ -&& tar -c modules | bzip2 > fglrx.tar.bz2 \ +&& tar jcf fglrx.tar.bz2 modules \ && rm -rf modules) # install panel files dh_install -A -p$(PKG_control_qt3) "usr/X11R6/bin/fireglcontrolpanel" "usr/bin" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation is FANTASTIC!!!
On Fri, Apr 21, 2006 at 08:14:10AM +0200, Wolfgang Lonien wrote: > And for those who still are complaining about the installer not being > graphical: please, guys, there's more than your x86 machines. Keep that > in mind. And where is the difference between a mouse click and a return > key (yes, it's - mostly - that easy!)? Hear hear. I installed Debian with the etch installer to a new AMD64 machine. The only hitch was that I had to use expert mode because the one of the via drivers crashed the system. It handled LVM on RAID deftly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#315903: ITP: evilfinder -- proves that any given subject is evil
On Mon, Jun 27, 2005 at 11:42:34PM -0500, Kenneth Pronovici wrote: > On Tue, Jun 28, 2005 at 01:37:25PM +0900, Miles Bader wrote: > > Kenneth Pronovici <[EMAIL PROTECTED]> writes: > > > Oh come on, of course not. But if you can't admit that this is a > > > novelty application and not a utility, you're kidding yourself. > > > > For the record, I _was_ kidding in my original message -- but I do think > > it looks like a fun program, and certainly stand by the rest of my > > message. > > Fair enough. Whew. That was close. I thought we were gonna lose evilfinder. > > KEN > > -- > Kenneth J. Pronovici <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dhcp-client package in sarge
On Fri, Jun 03, 2005 at 08:56:07AM +0200, Nicolas Kreft wrote: > Hi List! > > > Is it for a special reason that the default dhcp-client > in sarge is ancient (version 2.0pl5)? > > This client does not follow the RFC correctly. When > it does a dhcpdiscover and the interface has been > previously configured with some ip address it is still > using that ip for the dhcpdiscover. This causes the > dhcp server (3.0.2) on my network to abandon that ip address. > > The 3.x series has been released nearly 4 years ago, > why not make it the default? I had the same problem with dhclient. I was mounting root over NFS and then using DHCP to fill out resolv.conf. The 'problem' was that the deconfiguring of the interface was happening in a script before dhclient did it's magic. I built pump to solve the problem. IIRC, the issue isn't fixed in newer versions of dhclient, but others may know for sure. Cheers. -- 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 10:45:45PM +0100, Ola Lundqvist wrote: > > The speed of buildd systems mostly becomes irrelevant. They will > > still have to keep up with base (the set of .debs that we do > > distribute for a SO arch). Anything past that is there just for QA > > purposes -- to make sure packages are buildable on these archs, and > > would be optional. > > This is the problem. How do you make sure that the package is buildable > on the architecture without building it? And if you have built it why not > just add it to the archives. :) So you still need a buildd. :( Not necessarily. I think if we make it easy for end users to perform selective builds we have a chance of making it work. > > So, what do you think? Could this work? > > Nice idea, but I do not really see the benefit, more than on ftp disk space > and security update speed. While I would like to *not* see a change to the build structure, I agree that removing lesser used arch's from the testing & guaranteed support infrastructure gives room for higher frequency releases. IMHO, the disk space issue is a red herring. Security updates, too, are not the primary concern, it's getting all of the cats out the door with some frequency. -- 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 02:24:01PM -0600, John Goerzen wrote: > On Tue, Mar 15, 2005 at 07:46:23PM +0100, Adrian Bunk wrote: > > > don't handle deps at all) > > >... > > > So, what do you think? Could this work? > > > > Yes, this could work. > > That's what Gentoo is good at. > > [ snip ] > > > Your priority are your users, and if Debian has decided to focus only on > > some key architectures it would be the best for them to help them > > switching to Gentoo instead of hacking Debian to become some cheap > > Gentoo clone for most architectures. > > I don't view this as being a cheap Gentoo clone. In fact, I view > srcinst as being the Gentoo idea, done right. Gentoo has a lot of > problems, especially relating to difficult upgrades. Because of our > superior packaging system, we are in a great position to hit the ground > running and, with a little help from something like srcinst, come up > with something that works -- and works better than Gentoo -- in a short > amount of time. > > > If the Debian developers intereested in the ports Debian intends to drop > > would switch to Gentoo for helping Gentoo to support all of their > > architectures and for providing easy Debian -> Gentoo transition paths > > this would serve your users better. > > Yes, but I hope that this proposal, or other suggestions, can help us > avoid dropping ports. This specific proposal, for instance, is meant to > provide us with a way forward that addresses the main concerns while > still producing a quality, usable result for our users. ...and may encourage development of new architectures as the overhead for each would be much smaller. -- 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 12:42:54PM -0500, Stephen Frost wrote: > - Mirror only the popular archs. > - Support buildds for stable-enough archs that run them. > - Try to include everything in a release, but drop archs more > quickly than has been done in the past if there's a lack of > resources, but do outline what people need to do if they want the > arch included. > - For archs that weren't able to make the cut, provide .debs for the > packages which don't have RC bugs. Don't provide .debs for the > packages which have RC bugs on that architecture. Attempt to include > the archs in security updates, but if it's not built fast enough or > whatever then drop the .deb for that package and provide the source > update. A fixed .deb can be done later by whomever. > > I dunno, just some thoughts. I don't like becoming a mostly source-only > distro for less common archs. If someone wants to build the debs and > upload them, let them. This sounds like the idea already going around of, essentially, 'build what we can'. I'm suggesting that we go a step further and enable a new segment of the user base. The turnkey people use x86 (+relatives) and PPC. The people on other arches can either step-up to provide resources to Debian, or they can build what they need. Of course, I'd rather not cut the support. But John draws, IMHO, a reasonable line in the sand. -- 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:25:23AM -0600, John Goerzen wrote: > So, what do you think? Could this work? I like the idea a lot. What I'd like to see is a way to do a cross-platform build for the small system targets. I do a lot of ARM work: low-performance, resource limited targets. Frankly, this is something I'm actively working on. I agree that the Debian infrastructure shouldn't be required to do all of the building. It would be helpful, though, if there was support for other arch's to be built efficiently by the users of those arches. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, Feb 21, 2005 at 08:56:27PM -0800, Thomas Bushnell BSG wrote: > Marc Singer <[EMAIL PROTECTED]> writes: > > > It does seem prudent to find a way to permit a release on x86 and > > ppc before all architectures are complete. Especially if this > > tactic will give Debian the ability to release more often. Is it so > > bad to allow the smaller architectures to lag as long as problems > > are fixed? > > This would only make sense if we had a complete x86 and ppc release, > but not a complete mips release. In practical terms, this doesn't > happen. It's not like we do all the x86 work, and then the rest. I agree completely. This makes sense iff the lesser used arches affect release. As I posted in another message, this discussion about removing arch's seems to me to be a red herring. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 03:15:58AM +, Dirk Eddelbuettel wrote: > But to the best of my knowledge, Marco's (blog) post from a few months > ago which showed download from ftp.it.debian.org by architecture stands > undisputed: essentially all users are on i386 clearly dominating all other > arches, with a fraction of users in maybe two, three, four other arches --- > and comparitively nobody in the other fringe arches we keep around for no > good reason. And I still believe it delays our releases. As you say, there > are no KDE users on mips. So guys, we need a new framework. > > Maybe we should pick up on Petter's suggestion of stricter buildd > requirements. > Maybe we should only build base and essential packages for the minor > architectures [ after, apt-source is there for everybody to go further ]. We > can still provide the debian-installer for everything with a power cord > provided we have the resources to code, maintain, debug, document, improve, > ... > and all those platforms. IMHO, we are in an awkward position. There are *some* users in the other architectures. Not, many but some. If we drop those architectures then we will have *no* users in other architectures. This debate reminds me of the way that large corporations go for the largest market segment and leave the small fry without anyone catering to their needs. Debian is not a desktop architecture for some of these other architectures, but that doesn't mean it isn't valuable. It is clear that there is a problem with buildd resource efficiency and the fact that large packages delay our release undesirably because of the high buildd latency. I would hate to see Debian throw out the baby. The problem with apt-source is that, if I understand it correctly, it only performs native builds. This isn't necessarily possible for some people. Speaking as an ARM user on embedded systems, there is no chance I'm going to build natively on the targets I support. It does seem prudent to find a way to permit a release on x86 and ppc before all architectures are complete. Especially if this tactic will give Debian the ability to release more often. Is it so bad to allow the smaller architectures to lag as long as problems are fixed? Cheers. -- 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 11:01:25PM +0100, Francesco Paolo Lovergine wrote: > On Tue, Feb 01, 2005 at 11:35:41AM -0800, Marc Singer wrote: > > I've been under the impression that the only machine-level > > incompatibilities are really kernel and driver issues and not issues > > with Debian per se. > > > > Can you be a little more specific? > > > > Currently for instance Matlab 6.5+ cannot be installed without a little > hack in the installer, that's due to a known bug (or feature ?) in our > sarge libc: it is not executable, like RH ones. I don't get the last part of that. 'it is not executable'? > Supporting a release involves also those aspects. I think I'm getting the idea. This is an interesting issue as it ought to fall on the shoulders of the application vendor given that their software has specific needs not readily addressable by the distribution. Is this one of those lbrary .so version number incompatibilities? Seems like we're in that gray zone between the distribution and the end-user. Software vendors aren't pulling their weight because many believe that RH *is* Linux, wrong on so many levels. Again, it seems like this is a place where someone ought to commit a little cash to smooth over the wrinkles. OEM hardware vendors already do this to support MS. -- 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:57:08PM +0100, Christian Perrier wrote: > > > > Would any people around have pointers which could be given to such > > > people ? Do we already have an entry point for such technical issues > > > as proprietary SW vendors needing technical information about the way > > > to support Debian ? > > > > It isn't clear to me what sort of compatibility issues you would be > > talking about. Is this an x86 thing? Or a release thing? > > > > I've been under the impression that the only machine-level > > incompatibilities are really kernel and driver issues and not issues > > with Debian per se. > > 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. > > Again, I can't really speak for them, but I'd like to point them the > right direction. I don't like to pass the buck, yet I can't see a way that Debian, as it is can support them directly. Perhaps they ought to look to the Debian consultant's list for someone to help. No matter how the problem is sliced, they're going to need to have someone on their side who can track down issues. This person may not be a kernel hacker, but there is always a need to have someone who will work with folks on the mailing lists who do. -- 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 07:37:27PM +0100, Christian Perrier wrote: > During the Solutions Linux expo in Paris, the DD's present at the > Debian booth have been approached by a representative from Trend Micro > Corp. who develops and sells security software (the most well known > being probably a virus scanning software and such similar software > suites). > > We ended with a very interesting and long discussion with their > Product Manager for Client/Server messaging products about the proper > way for them to support Debian. > > It seems that such support is a growing request from their customers > (some of them being important Ministries in France and probably others > worldwide) who use big farms of Debian-based servers. > > As far as I have understood, supporting Debian for this vendor is a > real concern, but they fail to be sure in who to get in touch with for > technical issues regarding the compatibility of their products and our > distribution in general (which includes direct interaction with the > Linux kernel, as far as I have understood from him). > > Their concernes was also deciding about *which* release of Debian they > should support. Though question as one may imagine because just > answering "thou shalt use stable" is obviously not enough. From > discussions I previously had with other visitors at the booth, he > concluded by himself that focusing their developers on sarge would > probably be a better investment than trying to support woody (this is > still a matter of months of development, so hopefully sarge will have > been released then). > > Would any people around have pointers which could be given to such > people ? Do we already have an entry point for such technical issues > as proprietary SW vendors needing technical information about the way > to support Debian ? It isn't clear to me what sort of compatibility issues you would be talking about. Is this an x86 thing? Or a release thing? I've been under the impression that the only machine-level incompatibilities are really kernel and driver issues and not issues with Debian per se. Can you be a little more specific? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: UserLinux white paper
On Tue, Dec 02, 2003 at 04:52:47PM -0800, Bruce Perens wrote: > So, our problem is how to rebalance the vendor-customer relationship for > our purposes. Probably the most useful tool is the industry group > organization, where a number of similar businesses get together to steer > their participation in userlinux, and the group involves their vendors > from a position of strength, together, rather than one of weakness, > apart. Customer group 1 is confident that this will work for them. May I suggest that there is still a role for some sort of ISV support on behalf of UserLinux. I have been asked by several of my clients: what is this Free Software or Open Source thing and how can I benefit? What holds them back is experience with the target system and a fear of the unknown. Their perception, while overstated, is still important. So, to the end of bringing ISVs to appreciate UserLinux perhaps there is a place for a laboratory. The difference between a laboratory and the common, custom ISV/OS Vendor relationship is that the lab is an open resource. It provides an environment of hardware, software, and expert support that guides them, teaches them, to work with the system. The lab is free to any who can show up, provided that adequate funding is available. Or, ISV can be enrolled to support the lab given that they see value in it. I've seen this model work well on several levels. Not only is there a realistic feeling of support, but there the inter-ISV relationships that appear when developers meet at the lab. I believe that for many, the physical presence of such a laboratory is an important factor in their believe that the system, UserLinux in this case, is a real entity. Cheers.
Re: faster boot
On Tue, Oct 21, 2003 at 05:33:38AM +0200, Thomas Hood wrote: > On Tue, 2003-10-21 at 05:12, Russell Coker wrote: > > Hmm, maybe we could make it the rule that anything with number 99 can > > return > > before it's finished initialising? > > If the point here is to "speed up boot" then I think it would suffice > to move the rc symlinks for those "leaf" services to something later > than S99xdm. > > cd /etc/rc2.d ; mv S??netatalk S99znetatalk Perhaps that means that xdm ought to be midway or, at least, not the last number.
Re: x windows wont start
On Sun, Oct 19, 2003 at 07:21:57PM +0100, stuart whittaker wrote: > refuses to start and the retry process fails also...??? > > > thanks for any advice. > > stuart > > stuart [EMAIL PROTECTED] This sounds like a user question and not a dev question. No? Usually x doesn't start because of problems with the server configuration. Have you looked at the X log (/var/log/XFree86*) ?
Re: chroot on debian hosts?
On Wed, Oct 15, 2003 at 09:37:51AM +0100, Colin Watson wrote: > On Tue, Oct 14, 2003 at 06:20:15PM -0700, Marc Singer wrote: > > (I thought I sent this, but now I cannot find it to be sure.) > > > > I'd like to build against sid on a machine (ia64) I don't own but > > which Debian does have available. > > > > I tried the recipe from the developer's manual using fakeroot. It > > failed because it could not find a package. Perhaps, this is a bug in > > debootstrap. Is that method supposed to work? > > Use dchroot to access chroots on Debian machines. You will not be able > to install packages yourself. Quantz doesn't appear to have this program, though the source is in joey's home. I have the impression that I'm swimming up stream on this one. Is this the right way to test a patch for a specific architecture?
chroot on debian hosts?
(I thought I sent this, but now I cannot find it to be sure.) I'd like to build against sid on a machine (ia64) I don't own but which Debian does have available. I tried the recipe from the developer's manual using fakeroot. It failed because it could not find a package. Perhaps, this is a bug in debootstrap. Is that method supposed to work?
Re: Help needed: builds eating all memory
On Sat, Oct 11, 2003 at 04:00:34PM +0200, Sam Hocevar wrote: >My openvrml packages have been failing to build on arm [1], mips [2] > and mipsel [3] for some time. From the build logs, it looks like g++ is > eating all the memory and the OOM killer kills it. > >What can I do? Ask the buildd admins to add more swap? I would be > happy to cross-compile the packages (they don't require any arch-specific > bootstrapping) but I don't have enough hard drive space to build a cross- > compiler. emdebian.org has cross compilers. I don't think there is mips, but arm is available there.
Re: Need help on enhancing Telnet with srp
Firstly, this isn't really the right place to ask this kind of question as this list is for maintainers of packages for the Debian distributions. Tar said, I am not sure that what you want to do is possible with Telnet as the telnet protocol is content-free. That is to say that it has no knowledge of when the user is sending a password and when the user is sending some other type of data. As far as Telnet is concerned, the connection between the client and server is a simple bi-directional stream. (I know this isn't entirely true, but close enough in this case.) You probably need to write a new daemon to go with your client. Good luck. On Mon, Sep 08, 2003 at 08:51:51PM -0700, polavarapu deepti wrote: > Hello, > I am computer science student and my project is to > enhance telnet using srp protocol to avoid passing > passwords in plain text. i have no idea how to start > about. I have link to your web-site with source code > for telnet. > > I have been going through RFC2944 for telenet > authentication:srp. I have already written code > implementing SRP(secure Remote Password) in C++, just > with a server and client. I have no idea what to do to > embed this into telnet. Could anyone please help me to > get started. > > Thanks alot, > Deepti > > > __ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Latest gcc-3.3 and kernel compilation
On Thu, Aug 21, 2003 at 12:44:11PM -0400, Ben Collins wrote: > > __u8 short slot_tablelen; > > Isn't it just a plain error? Either it's a char, or it's a short. It > can't be both, right? That's what I think, too. It looks, too, to be something added in a patch because the indentation is different. As Ben pointed out, it looks like I can only compile 2.4.21 with gcc-3.3. Working on it.
Latest gcc-3.3 and kernel compilation
Are we expecting the latest unstalble gcc compiler to correctly
compiler the kernel?
> gcc --version
gcc (GCC) 3.3.2 20030812 (Debian prerelease)
I'm getting a new error when I compile the kernel. In the structure
below, it doesn't like the declaration for slot_tablen complaining
that
ide-cd.h:440: error: long, short, signed or unsigned used invalidly for
`slot_tablelen'
It looks like it doesn't like the obviously invalid use of short in
the declaration. How does this affect our wish to move to the new
compiler?
struct atapi_mechstat_header {
#if defined(__BIG_ENDIAN_BITFIELD)
__u8 fault : 1;
__u8 changer_state : 2;
__u8 curslot : 5;
#elif defined(__LITTLE_ENDIAN_BITFIELD)
__u8 curslot : 5;
__u8 changer_state : 2;
__u8 fault : 1;
#else
#error "Please fix "
#endif
#if defined(__BIG_ENDIAN_BITFIELD)
__u8 mech_state: 3;
__u8 door_open : 1;
__u8 reserved1 : 4;
#elif defined(__LITTLE_ENDIAN_BITFIELD)
__u8 reserved1 : 4;
__u8 door_open : 1;
__u8 mech_state: 3;
#else
#error "Please fix "
#endif
byte curlba[3];
byte nslots;
__u8 short slot_tablelen;
};
Re: Access to an ARM system?
On Fri, Aug 08, 2003 at 01:33:05PM -0600, Jamin W. Collins wrote: > On Fri, Aug 08, 2003 at 12:00:37PM -0700, Marc Singer wrote: > > On Fri, Aug 08, 2003 at 12:55:11PM -0600, Jamin W. Collins wrote: > > > Does someone have an ARM system that I could gain access to? I'd > > > really like to put the ARM specific bug[1] filed against the Jabber > > > package to bed once and for all. I've seen reports of Jabber > > > running on ARM systems and of course the bug report of it > > > segfaulting. > > > > > > Any assistance in this matter would be most appreciated. > > > > > > I've sent a request to debian-admin, but have heard nothing back > > > from them. > > > > I have a couple of ARM boards that boot Debian. I'm not sure what it > > is you want to do on the machine. What is it you are trying to do? > > Ideally, get an installation of Jabber (from the debian package > binaries) to run and accept a client connection. According to the bug > report, the Jabber server segfaults on startup. So, if I can get the > server up and running and connect to it, I'd consider that something of > a success. So, you want the Jabber server installed on an ARM system so that you can connect to it and either a) verify that it crashes, or b) demonstrate that it doesn't. If this is so, then I can do this for you and give you a routable address to the ARM machine. Do you need to be able to do anything *on* the ARM? I think I can get ssh and some other utilities running on it. Still, let me be clear. I am using a Sharp KEV7A400 for some embedded systems development. I have a script that produces stripped-down filesystems for the target using the Debian package archive. It isn't hard for me to add programs to the filesystem, but I need to know exactly what has to be there since this isn't exactly an 'apt-get install' situation. Let me know and I'll put some cycles to it. Cheers.
Re: Access to an ARM system?
On Fri, Aug 08, 2003 at 12:55:11PM -0600, Jamin W. Collins wrote: > Does someone have an ARM system that I could gain access to? I'd really > like to put the ARM specific bug[1] filed against the Jabber package to > bed once and for all. I've seen reports of Jabber running on ARM > systems and of course the bug report of it segfaulting. > > Any assistance in this matter would be most appreciated. > > I've sent a request to debian-admin, but have heard nothing back from > them. I have a couple of ARM boards that boot Debian. I'm not sure what it is you want to do on the machine. What is it you are trying to do?
policy-rc.d
On Fri, Jul 04, 2003 at 01:06:14AM -0400, Joey Hess wrote: > Marc Singer wrote: > > There is the related trouble that the only way to disable most > > packages is to uninstall them. Sometimes, it is desirable to > > temporarily disable a service without removing the binaries or > > changing the executability of the init.d script. > > Take a look at invoke-rc.d and its policy program. OK. I can tell that this feature is available, though obscured by the lack of a man page for policy-rc.d or even a reference to a package that implements it. I *did* find a document through google, however. Reading it doesn't make it much clearer. My search through a Contents file doesn't show an implementor for policy-rc.d. Is there one or is it adhoc? -- Luckily, I am familiar with rule 3: 3. any action for a non-executable initscript is denied.
Re: Debconf or not debconf : Conclusion
On Fri, Jul 04, 2003 at 01:11:48AM -0400, Joey Hess wrote: > Theodore Ts'o wrote: > > On a separate but related topic, I think a much better approach would > > be to handle configuration as a step entirely separate from the > > install phase. Let the install be entirely quiet, and let packages > > have intelligent defaults. If the package absolutely must be > > configured before it can be used, then let it be non-functional until > > someone actually calls dpkg-configure (which would be just like > > dpkg-reconfigure except that's the only time the questions would be > > asked). > > Debconf is flexable enough so you can do that already (assuming all > packages use debconf). > > - comment out the dpkg-preconfigure call in /etc/apt/apt.conf.d/70debconf > - set in /etc/debconf.conf: > Frontend: noninteractive > Admin-Email: > - dpkg-configure is the following script: > #!/bin/sh -e > dpkg-reconfigure --unseen-only --default-priority -freadline $@ My reading of Ted's comment is that this ought to be the *default* policy. I won't go so far as to say that RH made a better choice, but I don't really see the benefit of the all of the warning messages when once displayed they are nowhere to be found. Perhaps, you'll have a command for recovering these messages, but that doesn't change the fact that they are just not really necessary at install time.
Re: Debconf or not debconf : Conclusion
On Fri, Jul 04, 2003 at 12:18:33AM -0400, Theodore Ts'o wrote: > On a separate but related topic, I think a much better approach would > be to handle configuration as a step entirely separate from the > install phase. Let the install be entirely quiet, and let packages > have intelligent defaults. If the package absolutely must be > configured before it can be used, then let it be non-functional until > someone actually calls dpkg-configure (which would be just like > dpkg-reconfigure except that's the only time the questions would be > asked). > > - Ted Hear, hear. There is the related trouble that the only way to disable most packages is to uninstall them. Sometimes, it is desirable to temporarily disable a service without removing the binaries or changing the executability of the init.d script.
Re: Debian conference in the US?
On Fri, May 23, 2003 at 10:03:38AM -0700, John H. Robinson, IV wrote: > Marc Singer wrote: > > (Unintentionally, I first sent the reply to you directly.) > > > > On Fri, May 23, 2003 at 02:09:24PM +1000, Russell Coker wrote: > > > Incidentally "North America" != "USA". > > > > And your point is, what? > > that north america contains not one, but three countries: Candada, USA, > and Mexico Good grief. If you'd read the original message carefully, you'd notice that I know the difference. I wrote North America and meant it.
Re: Debian conference in the US?
(Unintentionally, I first sent the reply to you directly.) On Fri, May 23, 2003 at 02:09:24PM +1000, Russell Coker wrote: > Incidentally "North America" != "USA". And your point is, what? > A Canadian conference would be in North America and satisfy the > objections of people who don't like the US, however it may be too > far for some USians to travel. There is no forseeable future where everyone is satisfied. > > I just bought some french-cut green beans. %^) > > Probably not from France. Canada.
Re: Debian conference in the US?
Perhaps we can look at this a different way. I haven't read anyone voicing the opinion that GWB (can't say the name of the beast out loud) is a 'good fellow'. I'm supposing that all of us agree that he's a snake-oil salesmen of the odious kind, interested most in lining his pockets and the pockets of his pals at the expense of the majority of US citizens as well as international citizens. He is a ignorant bully whose opinions and actions don't represent me or my cohort. Yet, it is reasonable to take personal representing our feelings. There are folks who don't want to contribute an earned farthing to the US economy. So be it. This doesn't mean that we should not have a Debian conference in North America. I'm sure there are many North American DDs who'd like to meet more DDs in person. Having a conference in the US or Canada is not an endorsement of US foreign policy. It seems to me that the best place to have the conference in NA is where we get support. Should there be equal support in, for example, Vancouver and DC, then we can weigh merits. If we host it out of the US, then at least we can keep our shoes on. > What do you think of the boycots of French products? Do you oppose > them on principle? I just bought some french-cut green beans. %^)
Re: Debian conference in the US?
> For those reasons, I am planning to organise Debconf 4 in Vancouver (or > maybe somewhere else, if there's a lot of hate for vancouver) sometime > in the summer of 2004. Yipee!
Question of casts, lvalues, and & operator
I've found that G++ 3.2 has a problem optimizing this code.
#include
int func_b (void** ppv)
{
*ppv = (void*) 2;
return 0;
}
char* test (void)
{
char* pa = NULL;
func_b (&(void*)pa);
return pa;
}
int main (int, char**)
{
char* p = NULL;
p = test ();
printf ("%p\n", p);
return 0;
}
When compiling with -O0, everything is OK. -Os, on the other hand,
will optimize the return and always yield NULL.
I sent a preprocessed version of the errant file to gcc-bugs and was
told that my syntax is faulty and that the compiler will issue
warnings.
Here's his comment:
(Your code should get a warning, or perhaps even a hard error -
you're applying the & operator to a cast to non-reference type, which
is not an lvalue, so it's invalid.)
Yet, -Wall does not make the compiler complain.
He says that the line ought to be
f ((void**)&p);
which does generate correct code. Still, it seems to me that either
the compiler ought to warn or error, *or* the original code ought to
work.
So, is this simply an example of the compiler failing to warn?
Re: How to fetch proper source for libc
On Mon, Dec 02, 2002 at 12:02:01AM +, Colin Watson wrote: > On Sun, Dec 01, 2002 at 02:39:48PM -0800, Marc Singer wrote: > > I'm tracking a memory leak that appears to stem from regexec(). Hmm. What makes you think that this patch fixes a memory leak? I ask because the patch appears to deal with 16-bit characters.
Re: How to fetch proper source for libc
On Mon, Dec 02, 2002 at 12:02:01AM +, Colin Watson wrote: > > However, when I fetch source I get version 2.2.5 > > What does your /etc/apt/sources.list look like? Duh. Right.
How to fetch proper source for libc
I'm tracking a memory leak that appears to stem from regexec(). [EMAIL PROTECTED] ~...coastal/ssem > apt-cache policy libc6 libc6: Installed: 2.3.1-5 Candidate: 2.3.1-5 Version Table: *** 2.3.1-5 0 500 file: unstable/main Packages 100 /var/lib/dpkg/status 2.2.5-6 0 500 file: woody/main Packages 2.1.3-24 0 500 http://security.debian.org potato/updates/main Packages However, when I fetch source I get version 2.2.5 [EMAIL PROTECTED] ~...coastal/ssem > apt-get source libc6 Reading Package Lists... Done Building Dependency Tree... Done Need to get 0B/11.8MB of source archives. dpkg-source: extracting glibc in glibc-2.2.5 Odd, but I assume apt is doing the right thing. My memory allocator saves a stack backtrace for each allocation so I can pinpoint the culprit. The call stack looks like this: regexec re_search_internal set_regs proceed_next_node re_node_set_insert malloc Note that this program is statically linked so that I can see all of the symbols. On building the library from source (2.2.5), these symbols are not present. If I unpack 2.3.1 source I don't see the symbols in posix/regex.c. Finally, I forced libc6-dev to reinstall the most recent unstable version. The symbols are definitely still present in /usr/lib/libc.a. Any suggestions? - Marc Singer
Re: Debian based CD based distros
On Sat, Aug 31, 2002 at 01:42:36PM -0400, Dale Scheetz wrote: > The first one I was shown by my neighbor is called Knoppix 3.1 and is > produced by a German group. As a result it comes up in German, but there > is a simple fix that will boot it in English (boot: knoppix lang=us) that > only requires you to know that the equal sign is a . There appears to be an english ISO. Is this the one you are using? Downloading. It be a couple of hours before I can try it myself.
Re: When bind9 reinstalls, no db.root
On Thu, Aug 22, 2002 at 01:49:39PM -0700, Blars Blarson wrote: > In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: > >because there is no compelling reason > >to keep db.root a configuration file > > > But there IS a compelling reason to keep db.root a configuration file: > alternic > > I don't use them, but debian shouldn't trash files that a sysadmin needs > to change to use them just because they arn't recomended. > > (See http://www.alternic.org/ for info on alternic. While I have my > problems with the way icann runs the DNS, alternic doesn't show signs > of being run better, just differently.) Perhaps the file is poorly named db.root -> db.internic-root
Re: When bind9 reinstalls, no db.root
On Thu, Aug 22, 2002 at 08:44:04AM -0400, Matt Zimmerman wrote: > On Wed, Aug 21, 2002 at 05:10:58PM -0700, Marc Singer wrote: > > > This terse reply is obviously inappropriate. If you are annoyed, stop > > writing. > > No less appropriate than your one-line dismissal of a reasonable and tactful > response. So let me get this straight. You equate "shut up" with a request for concrete examples. How unfortunate. > > > I was asking for real examples in order to discuss how the case of bind > > and db.root is *not* a member of that set and how there may be a genuine > > problem with the handling of installing over missing configuration files. > > Are you saying that you think that the situation with this particular > conffile is different enough, and that there are enough other similar > conffiles, that it justifies different handling by dpkg? If so, I think > that I would disagree. > > In the particular case of BIND, it is entirely reasonable to move the entire > configuration somewhere else (such as into a chroot) and remove /etc/bind > and its contents. It would be confusing to have them reappear when BIND is > upgraded. The idea is that db.root is a different kind of file. Most of the time, configuration files reflect the personality of the user's machine. db.root contains information about the root name servers. I would differentiate the presence of this information on a user's machine with the application of that information. It has a closer relationship to terminfo files or the POSIX timezone files than the global bash rc file. > > > As far as I can tell there is no way to pass --force-confmiss to dpkg > > when using apt-get. Perhaps this is the only real omission. > > man 5 apt.conf, search for 'dpkg', 6th match. That's a global change. Someone else pointed out that it can be passed with -o. > > > Still, breaking bind's access to root name servers is particularly > > troublesome because it may tend to break all net access. It may be > > worthwhile to remove db.root from the list of configuration files. > > Especially, because this list isn't something anyone should need to > > change. > > The conffile system does nothing to break BIND's access to root nameservers; > this only happens if an administrator explicitly removes db.root. If this > was an accident, they need to reinstall with --force-confmiss. If not, then > their change is preserved as it should be. What purpose would be served by > making db.root not a conffile? Albeit, this isn't a grave consideration, but one that make repairing a broken name server a little easier. Because --force-confmiss isn't a very desirable switch to use, because there is no compelling reason to keep db.root a configuration file, and because making this change would make restoring a missing db.root simple it seems that real question is qhy not?.
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 10:19:49PM -0400, Scott K. Ellis wrote:
> > Still, breaking bind's access to root name servers is particularly
> > troublesome because it may tend to break all net access. It may be
> > worthwhile to remove db.root from the list of configuration files.
> > Especially, because this list isn't something anyone should need to
> > change.
>
> I beg to disagree. Changing db.root is the primary way to use an alternate
> DNS root (either for an all-internal DNS, or to utilize an alternate DNS
> root than NetSol's). Just because you can't see why something might be
> configured differently doesn't mean other people can't.
One can change the database reference in named.conf to do this. The
difference is that db.root references 'the' root servers. You can
choose which ones you want to use in the zone file:
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.alternative_root";
};
The trouble with removing db.root is that it may not be obvious how to
recover when it is missing.
Re: When bind9 reinstalls, no db.root
On Thu, Aug 22, 2002 at 08:47:46AM +0100, Colin Watson wrote:
> On Wed, Aug 21, 2002 at 05:10:58PM -0700, Marc Singer wrote:
> > I was asking for real examples in order to discuss how the case of
> > bind and db.root is *not* a member of that set and how there may be a
> > genuine problem with the handling of installing over missing
> > configuration files.
>
> Maybe db.root just shouldn't be a conffile, that's all.
{Gesturing} That's what I'm saying.
>
> > As far as I can tell there is no way to pass --force-confmiss to dpkg
> > when using apt-get. Perhaps this is the only real omission.
>
> Sure there is: it's something like -o DPkg::Options=--force-confmiss.
OK. You got me. Is there any hope that's you'll at least cede that
that's not as straightforward as we *could* be?
>
> --
> Colin Watson [EMAIL PROTECTED]
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 06:39:55PM -0500, Steve Greenland wrote: > On 21-Aug-02, 15:10 (CDT), Marc Singer <[EMAIL PROTECTED]> wrote: > > It would help to have an example. > > I could have sworn I had a footnote about /etc/cron.allow, with a > reference to the appropriate manpage :-). Okay, it's not the *best* > example, because I don't actually ship a cron.allow, but the point is > there: A missing cron.allow permits everybody to use crontab, while an > empty cron.allow forbids use of crontab by anybody (except root, of > course). It does appear that there are a couple of good examples. In fact, this is not one of them since what you ought to ship is a cron.allow that blocks everything, right? That way the default behavior is obvious to someone browsing the configuration. As far as I can tell, there aren't many 'dangerous' examples. A package may install a crontab file in cron.d that is deleted by the user. Apparently, apache2 performs directory scanning for configuration files, too. Examples such as BASH are definitely *not* dangerous since the default file contains a single, innocuous directive. As I wrote in another message, given that there is an override switch in dpkg, that switch would be helpful if available in apt-get.
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 07:32:04PM -0400, Matt Zimmerman wrote: > On Wed, Aug 21, 2002 at 04:23:16PM -0700, Marc Singer wrote: > > > On Wed, Aug 21, 2002 at 07:06:22PM -0400, Matt Zimmerman wrote: > > > _Any_ program whose default (Debian) configuration file specifies > > > options which are different from the compiled-in defaults. > > > > > > For specific examples, see almost any program on your system with a > > > global config file. > > > > Hand-waving doesn't constitute an example. > > How about bash? A missing /etc/bash.bashrc has a different effect than the > default /etc/bash.bashrc. A missing /etc/bash_completion has a different > effect than the default /etc/bash_completion. Missing /etc/skel/.bash* will > avoid having any .bash* files copied into new users' home directories. I > think that you have bash installed (assuming you run Debian), so you now > have an example that you can experiment with on your own system. And you > didn't have to go to the trouble of figuring it out for yourself. > > You may shut up now. This terse reply is obviously inappropriate. If you are annoyed, stop writing. I was asking for real examples in order to discuss how the case of bind and db.root is *not* a member of that set and how there may be a genuine problem with the handling of installing over missing configuration files. As far as I can tell there is no way to pass --force-confmiss to dpkg when using apt-get. Perhaps this is the only real omission. Still, breaking bind's access to root name servers is particularly troublesome because it may tend to break all net access. It may be worthwhile to remove db.root from the list of configuration files. Especially, because this list isn't something anyone should need to change.
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 07:06:22PM -0400, Matt Zimmerman wrote: > On Wed, Aug 21, 2002 at 12:49:19PM -0700, Marc Singer wrote: > > > For example... > > _Any_ program whose default (Debian) configuration file specifies options > which are different from the compiled-in defaults. > > For specific examples, see almost any program on your system with a global > config file. Hand-waving doesn't constitute an example. > > -- > - mdz > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 09:21:39PM +0100, Colin Watson wrote: > On Wed, Aug 21, 2002 at 01:10:29PM -0700, Marc Singer wrote: > > On Wed, Aug 21, 2002 at 03:00:52PM -0500, Steve Greenland wrote: > > > To be, perhaps, a little more explicit: there are programs for which > > > the existence of an empty configuration file means something completely > > > different than a missing a configuration file[1]. Thus, for dpkg > > > conffile handling, removing a configuration file is a legitimate "edit". > > > > It would help to have an example. However, even if there is an > > example I don't see how db.root fits in this category. > > Unfortunately there's no way for a package to override this aspect of > dpkg's conffile handling. It would have to be handled entirely in the > maintainer scripts in some different (and careful!) way. Is the feature triggered for files appearing in /etc? > > -- > Colin Watson [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 10:21:17PM +0200, Oliver Kurth wrote: > On Wed, Aug 21, 2002 at 12:49:19PM -0700, Marc Singer wrote: > > On Wed, Aug 21, 2002 at 09:42:53PM +0200, Josip Rodin wrote: > > > > > Sounds like you want dpkg --force-confmiss. > > > > > > > > I wouldn't expect that since the documentation states: > > > > > > > > confmiss: Always install a missing configuration > > > > file. This is dangerous, since it means not pre- > > > > serving a change (removing) made to the file. > > > > > > > > How could it be dangerous to install a *missing* configuration file? > > > > > > If the default configuration data in the file do something you don't want. > > > > For example... > > autofs. First thing I do when I install autofs in at networked environmemt is > rm /etc/auto.* > because I want to use the NIS maps. I don't think that example works for all of the auto.* files. The master file references the other files. Removing the master eliminates the references to the others. However, adding auto.furball won't affect autofs unless auto.master references it. > > Greetings, > Oliver > -- > Oliver Kurth > mailto:[EMAIL PROTECTED] http://leinekanal.de
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 03:00:52PM -0500, Steve Greenland wrote: > On 21-Aug-02, 14:42 (CDT), Josip Rodin <[EMAIL PROTECTED]> wrote: > > On Wed, Aug 21, 2002 at 12:32:00PM -0700, Marc Singer wrote: > > > How could it be dangerous to install a *missing* configuration file? > > > > If the default configuration data in the file do something you don't want. > > > > To be, perhaps, a little more explicit: there are programs for which > the existence of an empty configuration file means something completely > different than a missing a configuration file[1]. Thus, for dpkg > conffile handling, removing a configuration file is a legitimate "edit". > It would help to have an example. However, even if there is an example I don't see how db.root fits in this category.
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 10:04:28PM +0200, Josip Rodin wrote: > On Wed, Aug 21, 2002 at 12:49:19PM -0700, Marc Singer wrote: > > > > > Sounds like you want dpkg --force-confmiss. > > > > > > > > I wouldn't expect that since the documentation states: > > > > > > > > confmiss: Always install a missing configuration > > > > file. This is dangerous, since it means not pre- > > > > serving a change (removing) made to the file. > > > > > > > > How could it be dangerous to install a *missing* configuration file? > > > > > > If the default configuration data in the file do something you don't want. > > > > For example... > > I don't know, but I know plenty of default configuration files that set > something up. Maybe "dangerous" is a bit extreme choice of words, but the > negative effect isn't implausible. Without a single example, I don't see how installing a configuration file where there is none can have *any* affect on the system. Admittedly, replacing a configuration file may be undesirable. Moreover, in this case, db.root is not really a configuration file. It is more like a library. If I ask for a package to be reinstalled, most users will expect all of the programs and libraries to be installed. Are you sure you agree that db.root should not be reinstalled with bind's programs? > > -- > 2. That which causes joy or happiness.
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 09:42:53PM +0200, Josip Rodin wrote: > > > Sounds like you want dpkg --force-confmiss. > > > > I wouldn't expect that since the documentation states: > > > > confmiss: Always install a missing configuration > > file. This is dangerous, since it means not pre- > > serving a change (removing) made to the file. > > > > How could it be dangerous to install a *missing* configuration file? > > If the default configuration data in the file do something you don't want. For example...
Re: When bind9 reinstalls, no db.root
On Wed, Aug 21, 2002 at 08:24:58PM +0100, Colin Watson wrote: > On Wed, Aug 21, 2002 at 12:09:57PM -0700, Marc Singer wrote: > > I'm confused by the behavior of apt-get install --reinstall. I found > > out yesterday that the /etc/bind/db.root file was missing on my name > > server. I was able to recover by linking to an old copy and > > restarting bind9. However, when deleted the link and performed the > > --reinstall command, the db.root file was not restored. > > Sounds like you want dpkg --force-confmiss. I wouldn't expect that since the documentation states: confmiss: Always install a missing configuration file. This is dangerous, since it means not pre- serving a change (removing) made to the file. How could it be dangerous to install a *missing* configuration file?
When bind9 reinstalls, no db.root
I'm confused by the behavior of apt-get install --reinstall. I found out yesterday that the /etc/bind/db.root file was missing on my name server. I was able to recover by linking to an old copy and restarting bind9. However, when deleted the link and performed the --reinstall command, the db.root file was not restored. I verified that the file exists in the bind9 DEB and, in fact, is listed in the bind9.list file. My question is this. How can the reinstall fail to install the file when there is no extant file with the same name?
Re: IA32 vs i386
On Thu, Oct 15, 1998 at 02:09:23PM -0700, Kenneth Scharf wrote: > The intel version of debian packages are in some directory path > downstream from ../../i386/.. and the package names also carry i386. > While this is technically correct, it can be missleading to some that > the package only runs on an 80386 cpu. The current name for the cpu > family from intel (and clones) that are derived from the 386 is IA32. > (and intel's next family will be called IA64). Should the package and > directory names be changed from i386 to IA32? It is a bit ridiculous to suggest that we change this now. Whether or not it is correct, it is well understood and deeply entrenched. We use i386 because that was the first intel processor capable of hosting a 'real' operating system. The 286 has a p-mode, but it didn't have the memory management. IIRC the IA32 designation wasn't coined until the pentium's were released.
Re: Removing Gnome [was: Removing Packages in Slink for Debian 2.1]
On Thu, Oct 15, 1998 at 04:02:41PM -0500, Stephen Crowley wrote: > On Thu, Oct 15, 1998 at 08:32:02AM -0400, Brian White wrote: > > > What do you think we should do with the Gnome stuff? > > > > > > The Gnome 0.30 stuff is still under rather heavy development. The > > > current packages in Slink are pretty much alpha-quality. Lots of > > > things don't work. It sounds like there will probably be a 1.0 > > > release coming up in a few months that will be thoroughly tested and > > > stable. > > > > > > I'm not sure if it's a good idea to release them as a part of a > > > "stable" distribution, as they really aren't. There aren't any > > > guarantees that the stuff that runs today is going to run tomorrow. > > > > I would agree with you. They should probably be removed from slink > > at the time of the freeze. Do you have a list of these packages? > > That is ridiculous, there is no reason to remove gnome before the freeze, if > you > dont like it dont use it. There are several programs that wont run without it, > including GtkICQ which is about the only usuable icq replacement available (if > you dont count those crappy console ones) IMHO it is not appropriate to ship beta software under the guise of release software. If it is really desirable to ship gnome, it sould be categorized as ALPHA and installed only when a user explicitly requests it. I think that keeping it on the CD is spurious because the CD represents what we know works. Packages that don't work can be downloaded from the FTP servers by the people who want to fuss with them. Gnome is high profile because it has fancy screenshots. Users who see the packages and install them with the idea that they work will not be treated with the high standard of quality Debian shows elsewhere.
Re: moving mutt-i from non-us to main
On Thu, Oct 15, 1998 at 06:55:36PM +0200, Marco d'Itri wrote: > Can I move mutt-i from non-us to main? > There is no crypto code in the package, only SHA-1 (hash algorithm) and > code to run pgp or gnupg. > > (Waiting to resolve this issue I haven't uploaded yet the stripped version > to main, I hope Brian will let it slip past the freeze, there are no > other differences from the complete version.) > I was under the impression that putting hooks in to use crypto was enough to raise the hackles of the export hounds.
Re: Removing Packages in Slink for Debian 2.1
On Wed, Oct 14, 1998 at 09:33:22PM -0700, Jim Pick wrote: > > Brian White <[EMAIL PROTECTED]> writes: > > > Okay, everybody... It's that time again. I've gone through the bug logs > > and made my list of packages to keep/remove should they still have > > release-critical (i.e. critical, grave, or important) bugs at ship time. > > What do you think we should do with the Gnome stuff? > > The Gnome 0.30 stuff is still under rather heavy development. The > current packages in Slink are pretty much alpha-quality. Lots of > things don't work. It sounds like there will probably be a 1.0 > release coming up in a few months that will be thoroughly tested and > stable. > > I'm not sure if it's a good idea to release them as a part of a > "stable" distribution, as they really aren't. There aren't any > guarantees that the stuff that runs today is going to run tomorrow. I installed it yesterday to get a glimpse at what they are doing. I'd say it should be left out because it doesn't really work. It is a fine demonstration, but it doesn't add value to Debian until it can be used either a) to hack against, or b) to provide a workable desktop environment.
Re: Interesting article by Alan Cox
On Tue, Oct 13, 1998 at 11:44:21AM -0700, David Welton wrote: > This definitely has some relevancy to us. It's worth reading, IMO. > > http://slashdot.org/features/98/10/13/1423253.shtml AFAICS, Alan is right on. This is the same approach taken by the IETF and has been very productive. It is much easier to accept the opinion of someone who can produce results than one from someone who only likes to talk about it.
Re: Bug Report?
On Tue, Oct 13, 1998 at 09:03:25PM +0200, Helmut Metzdorf wrote: > Hi, > > knowing my impatience i nevertheless dare rising my case here after > only three days without answers on debian-users (worse off with > Debian 2.0) because i think that its clearly a development issue. > > The situation: > > a self written programm (i'd like to run 24 hours a day) renders my > computer unusable for any other task. my observation says that the > cause is that my program relies heavy on file-io and my current > Linux-version (debian 2.0 - kernel 2.0.34) is eager to comply by > keeping the harddrive busy. [deletia] Have you considered using nice? I have experienced severly unbalanced loading on machines that are doing a lot of I/O. I never spent much time worrying about it because compiles don't appear to be in this category. The nice program is a simple method for governing a resource hog. Try this first. After that, you may want to look at the output of strace to see what sorts of calls are taking the most out of your system. After that, you may be looking at either a) an SMP machine, b) hiring someone who can scrutinize your code, or c) letting it be a resource hog.
Re: A little question about Debian
On Tue, Oct 13, 1998 at 03:43:48PM +, Matthias D wrote: > Hello, > > I would like to know if there is anything like usable with API or Corba > technology or even Java (I know all that is Sun's property..) > availaible with Debian or if someone plan to develop similar > technologies... > Or to use this do you recommend to directly jump into Solaris (the fact > is that I don't like system's property...). > Is Sun as afraid as Microsoft of making arrangements ? I'm not sure that your question is clear. What do you mean about "like usable with API or Corba"? What about jumping into Solaris?
Edits to Startup Disk Help
I posted a patch to the boot-floppies package with changes to the help screen. Since I didn't get feedback on it I wonder if this is not the approved method of making changes to other people's packages. The edits, if you're interested, are on master master.debian.org/~elf/patches/boot-floppies_2.0.11_p1
Re: The freeze and IMMINENT 2.2.0p1!!
On Fri, Oct 09, 1998 at 06:09:56PM -0600, Marcelo E. Magallon wrote: > On Fri, Oct 09, 1998 at 12:42:24PM +0200, J.H.M. Dassen Ray" wrote: > > > I'm not aware of any software in slink that must be updated to work with > > 2.2 properly (with the exception of pcmcia-cs); slink currently runs fine > > with 2.1.x (which I suspect quite a few developers run). > > A little tiny line in netbase init.d scirpts' needs to be changed because it > reports an ugly error because of different routing code. Also, The existing script will sometimes generate excess routes for the most recent kernels because they add routes automatically when interfaces are configured. I haven't found them to report errors, though, and I haven't found them to operate incorrectly. > rc.boot/0setserial needs to be modified not to do wild interrupt guessing > since it's no longer supported. > > And althought I have run 2.1.x since 76 or something like that, I wouldn't > put it on slink... remember, there were steady kernel releases up to 2.0.32 > and that settled until the pletora of attacks appeared (bonk, netsea, nuke > et al) > > > Marcelo > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
I seem to no longer be a maintainer...
I'm looking for myself in the bug database and find that I'm not on the list. I think I had a bug filed against one of my packages, but I cannot find it, or myself in the database. Huh?
boot-floppies, rewrite of help screens
I spent some time rewriting the help screens for the rescue disk to make them more comprehensible and to add information about using the rescue disk to rescue a system. I put the patch on master //master.debian.org/~elf/patches/boot-floppies_2.0.11_p1 Comments?
Re: Better (inc. asynchronous) DNS client (stub resolver)
On Wed, Oct 07, 1998 at 05:29:48PM +0100, Ian Jackson wrote:
> Mark W. Eichin writes ("Re: Better (inc. asynchronous) DNS client (stub
> resolver)"):
> > You might look at the "ares" library (Asynchronous RESolver) that Greg
> > Hudson <[EMAIL PROTECTED]> wrote...
> > athena-dist.mit.edu:/pub/ATHENA/ares/ares-0.3.0.tar.gz
> > is the current version. (At very least, compare notes with him...)
>
> Thanks for the pointer. At first, I saw your message and thought `oh
> no, all that wasted effort'. But, I think my API is still an
> improvement because it provides a much more `cooked' interface. Also,
> I'm not _too_ keen on the callback style of doing things, at least as
> a basic API. You can always convert an event loop into a callback,
> but the other way round is hard.
Without looking at ares, I'd say that the form of your interface is
appropriate. I'd have a hard time justifying this myself without a
lengthy exposition. For anyone designing computer systems, I
recommend reading a paper by Butler Lampson...here is it...
Butler W. Lampson.
"Hints for Computer System Design",
Proceedings of the 9th ACM Symposium on Operating Systems Principles,
October 1983, pp.33-48.
On reading this paper, I discovered all of the reasons for why I knew
that the M$ way is wrong. I highly recommend this paper for its
taxonomy of software design and for the 'hints' on how to avoid the
mistakes we've already seen.
>
> Ian.
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
Re: debian for non linux systems ...
On Wed, Oct 07, 1998 at 12:28:38PM +0200, [EMAIL PROTECTED] wrote: > Hello, > > I remember some month ago there was a discution some time ago about debian for > non entirely debian systems (i think it was a debian-solaris thing). > > What happened to it ? > > i was given a ultra sparc 1 with solaris 2.6 here at the university, and > þerhaps i would like to work on such a thing. (not now, but i a month or > so...) > I know that one of the biggest problems is that the dependency checks rely on a database. This comes up when you try to build a package on a non-debian system. There is a real knowledge gap between installed, unqualified packages that came with the system and pedigreed debian packages. In addition, the configuration of the non-debian system may be far from what debian packages expect. Take a look at /etc/init.d. I wasn't party to the original conversation, so I don't know where the thread ran. I expect that this feature is considered low priority when compared to the mountain of things we need to do to make debian grow.
Re: Better (inc. asynchronous) DNS client (stub resolver)
> I'm halfway through implementation, but it occurred to me that some > people might like to comment on my proposed API. So, below you'll > find a prototype of the header file. You'll notice I haven't given it > a proper software licence yet, but the library itself will be GPL'd. > > If you have some requirement you don't think would be addressed by the > API presented below let me know. If you don't understand the API > below then I'm afraid I can't help you atm - I haven't written the > documentation yet. It looks right to me. I wonder why you called adns_interest such. Isn't is a variant of select, perhaps a preselect? I'm a fan of the philosophy that if it looks like a mouse, smells like a mouse BTW, I'm glad you're doing this. The synchronous nature of libresolv requires me to explain lots of things to my clients that I'd rather be obviated by a proper library.
Re: Kernel Debug pointers?
> > I'm looking for information on how to setup for kernel debugging. > > Any help? > > $ cd /usr/src/linux/scripts > $ g++ -o ksymoops ksymoops.cc -I/usr/include/g++ > $ cp ksymoops /usr/local/bin > > Then, when you get an oops, you can: > > 1. Save the oops (get it from /var/log/syslog) to ~/some_oops > 2. ksymoops [System.map for kernel] < some_oops > > and you'll find out exacly where/what went wrong... Ah. I don't have an oops to debug. Instead, I'd like to run gdb on the kernel so I can inspect data structures. I'm certain there is a way to run gdb on it, but I haven't found anything definitive. KHG doesn't have anything as far as I could tell.
Kernel Debug pointers?
I'm looking for information on how to setup for kernel debugging. Any help?
Script to make Packages file?
I FTP'd my distribution from a debian mirror and want to make it compatible with APT. The expected 'Packages' files are missing. Is there a script (or command line switch to dpkg that I haven't seen) that builds the list?
Right way to sync
What is the *right* way to sync to slink (or any other distribution)? I looked into dftp and found that it seems more like a method for installing new packages than keeping in sync with the most recent versions. The main thing I'm trying to avoid the duplicate package install problem. For example, dselect gets very confused when I have more than one package version present in my distribution directory. It installes the lower numbered one first and then goes through the successive versions upgrading. This caused a problem with X, for example, when some of the files moved and the uninstall scripts weren't clever enough to handle the soft links. -- Marc Singer
