Re: XFree 4.2.0 - again
> On Tue, Apr 16, 2002 at 06:28:50AM +0300, Lasse Karkkainen wrote: > > Other platforms aren't nearly as significant as i386 (not many users, no > > much new hardware). > > You're arrogance makes me wonder if George W. Bush is related to you. Hehehehee... Lasse, I guess if the other platforms aren't nearly as significant as i386, then I might as well reinstall Solaris, IRIX, HP-UX, Tru64, and OS X on my machines since it would be obvious that they "aren't good enough" to run linux. Also, I might as well call a few of my former employers and tell them that the work that they put into making linux better on their platforms doesn't matter. Your comments are both rude, biased, and insulting...I guess my 5+ years of contributions and working on Alpha and other ports doesn't equate to even minimal efforts by an i386-only developer. Check my package list and see if you can live without my packages, then write back with your answer as to whether my efforts make any difference or not. If you think other ports don't matter as much as i386, then feel free to purge any of my packages from your system since not one of them is compiled initially on i386. > I'll give you a hint: we are volunteers, and we do this because it's > fun. Messages like yours, that demand service for free just disgust. > I guess after seeing your messages Branden goes out for a beer > rather an opens a editor to serve ungrateful kids. Well said, Riku... C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel-{image,headers} package bloat
On Mon, 30 Apr 2001 [EMAIL PROTECTED] wrote: > Unfortunately it seems that a kernel that supports both i386 and SMP > would have to use very slow methods for locking since instructions > allowing faster locking only came in with the 486 and above. I'm wondering when this whole discussion will include other ports and their kernel requests... Basically, I can understand everyone's desires for a kernel that covers their cases (SMP, UP, 686, 386, etc), but the bloat issue that initially started this thread would be multiplied if the same type of solutions were implemented for the other archs. Alpha is now simplified, for the most part, and can use a "generic" kernel that doesn't suffer performance-wise, but we still have some exceptions (Ruffian, SMP, etc). If UP and SMP kernels were provided on i386, then we would request the same. I would assume sparc, powerpc, etc may also request the same. This could lead to an even larger archive bloat than this thread is trying to prevent... I've been clueless on how to solve this problem (or even what kind of solution may be needed to begin with since I don't see the current situation as being "a problem"), so I haven't spoken until now, but as this thread gets more and more Intel/AMD-centric, I'm beginning to wonder what the larger implications may be... C
Re: autobuilders
On Tue, 19 Dec 2000, Josh Huber wrote: > built. Should I just do it myself? I also know that there's no > (automated :) autobuilder for Alpha, so I understand that there might > be some delay for alpha. In Alpha's case, I'm normally very "on-top" of the builds, but am going to be slow for the next week or two (I'm moving 2000 miles this coming week). I'll build crash tonight and upload it. C
Re: new-maintainer and delays (was Re: [some idiot troll who should have been ignored])
On 13 Sep 2000, James Troup wrote: > Actually, no, way less than half the current backlog are applicants > from the shut down period. Yeah, after looking at more of the records, I see this. > If that's all I had to do in my life, no, of course it wouldn't. > Unfortunately it's not. Granted, DAM is becoming a problem, but a) > it's not the main problem (lack of contributing AMs is much more of a > problem), b) DAM appears worse than it actually is because my work on > it is sporadic and c) I am looking into fixing it (by taking on > mini-DAMers) in any event. Sounds like a good idea. > However, there is no longer any excuse for just whining about delays > in the new-maintainer process... if you don't like the delays, Chris, > feel to actually make a difference and sign up as an Application > Manager. Ok, calm down, I'm not blaming anyone here, I'm just looking at it from an external point of view (external, meaning I have nothing to do with the process). I also understand that everyone here is busy and has lives and jobs, etc, so don't assume that I'm unsympathetic to the stresses of the real world. Honestly, I wish I could spare more time to help NM along, but unfortunately I can't. Does this mean that I'm not allowed to look at and, God forbid, possibly comment on the NM process? I know that we all enjoy our time working on Debian, so let's not forget that we SHOULD enjoy what we do and not take it so damned seriously all of the time. It seems like every time someone tries to offer criticism or comments on someone else's work and tries to find a way to improve it, they get a "if you don't like it, do it yourself" message and a holy war begins. I don't want that to happen in this case. Please, let's all take a deep breath and look at it from another point of view every once in awhile. I really do like the idea of "mini-DAM"s and also noticed the AM problems that you mentioned, just by looking at a handful of records on nm.debian.org. Looks like you're already addressing any concerns that I've brought up, so good job :-) ...and in case nobody says it, thanks for all of your work on NM. It doesn't go unrecognised :-) C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: KDE2 - nice demolition job ...
On Wed, 13 Sep 2000, Raul Miller wrote: > [2] New Maintainer is a tough job, with a lot of work to be done > (especially because we weren't processing applications at all, last > year, because things had gotten so out of hand and the people dealing > with it had gotten so stressed out). In spite of that, NM is processing > people at a fairly decent rate (and most of the people who haven't been > processed haven't had their identities confirmed, yet). Hmmm...ok, looking at the pages that you sent me told me a lot about what's going on with NM. Very informative, btw...nice job. Looks like quite a backlog has been created by NM being shut down for so long. But, after picking a few people to look at that are currently in-process, some have experienced some unbelievably ridiculous delays (see http://nm.debian.org/[EMAIL PROTECTED] for a good example does it really take a month or more to make a phone call?). There are quite a few of them that are simply waiting for phone calls, according to the records on nm.debian.org, and have been waiting for a month or more... C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Large file support again
On Wed, 13 Sep 2000, Nils Rennebarth wrote: > On >http://www.suse.de/~aj/linux_lfs.html > I read that for glibc 2.1.3 in order to support large files it needs to be > compiled against headers from a 2.4 kernel. As this is currently not the > case, glibc 2.1.3 should be rebuilt. Woody is shortly going to be moving to a pre-release of glibc 2.2, so this will become a non-issue. IIRC, Ben's in testing mode on this transition now, so it shouldn't be long. If you really need a glibc 2.1.3 that supports >2GB files on a potato system, it may be better to attempt a recompilation on your own (it's very easy to build even glibc, given the wonderful packaging job that was done on it). Be warned, though, that potato was built using 2.2.x kernel headers, so things may break (probably won't, but just in case, I had to throw that in there). Besides, the 2.4.x kernels aren't out yet (nor are they even close to stable on any arch), so I'd recommend waiting until they're released and tested a bit more. BTW, Alpha can handle >2GB files right now :-) Nice to be a non-x86 user when these discussions come up :-) C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: KDE2 - nice demolition job ...
On Mon, 11 Sep 2000, erik wrote: > Thank you for a cool response - I was really hoping that would eventually > happen. I realize I stirred up a hornets nest; I did it intentionally > because otherwise nobody seems to notice and I think that at least some of > what I originally wrote (goading aside) is important. You happened to pick > out probably the most practically important one with the issue of the > protocols for accepting new voluteers. There are some other points in > there that are more abstract political points that don't have simple > answers - but they are the sort of thing that really won't change at all > if they remain hidden; perceptions are not always apparent to the > percieved. I have been watching people turn and be turned away for quite > awhile now and I really thought it was worth a little trouble to point it > out. I _like_ the debian project - why else put myself up for attack to > point out an embarressing fact? Really much easier to just go to bed ... Good point :-) I hope NM can be improved as well. I've got someone that I know will help the Alpha port that's still in process after several months now, but it's like molasses flowing uphill in winter to get him finally in the project. > < very valid points (alpha etc.) excerpted> Hheehehe... > Personally, I would like to make one proposal - I hope other > people will have others but an obvious practical problem is the > process of accepting volunteers; its clearly a bottleneck: > > a. Assign more people to process applications - kind of > self-explanatory. Not to stir anything up, here, but, to the NM team, what exactly is "the process" for dealing with NM applications? I've tried to stay away from politics mostly, but I've always been curious about this. I know it involves a phone call, getting ID proof, and getting their key signed, but other than that, I'm clueless. To help streamline it, is it something that (technically) any of us can do if we know the person or are closer geographically to them than the normal members of NM? > b. Establish at least two teirs of contribution - people who are > interested in helping with less technical aspects need not be subjected to > the same screening process as package maintainers. So if, for example > somebody says "hey, could I help with paperwork or the website or > something ?" they can be easily accepted to work on something. Voluteering > should not be a full time job. We get offers, but I kinda agree with the rest on this issue. Documentation, IMO, is just as important as the software itself. I know we don't always practice that principle, but we should. To maintain docs on par with the quality of the software releases, I'd personally feel more comfortable knowing that anyone that's taking care of docs has the same knowledge/credentials/whatever that the package maintainers do. > c. (optimally) Rewrite the pages that explain how to apply and > give a clearer and more complete description of tasks available and what > level of expertise each requires. I'd like to see this as well, but lack the time to volunteer to improve it. I've got enough tasks just keeping Alpha going, porting HURD to Alpha, seeking a job (yes, I'm unemployed), keeping my wife from throwing my computers off of the balcony, and keeping up with my Quake clan duties :-P I also think that whatever it is that NM does while processing an application should be documented (not per person, just in general...I think applicants would like to know what the steps are that you're going through while they wait). > d. (optimally) simplify the protocols for applying. Hmmm...expand on this, please...I'm not clear on what "protocols for applying" means. > Maybe we can start a constructive discussion now. Hope so :-) > hmmm, er, shit, well i hope this doesn't look like a pr scam now ... but, > anyway you can grab a .deb from unilinux.sourceforge.net; just go in the > anonymous ftp, there is a package called ddoc-0.4.2_all_.deb (i think)... > newer than the release ... its in development and right now it thinks it > depends on deb-make _and_ debhelper ... mumble, mumble ... better go to > bed now ... Hahahaha...I ftp'ed the debs, but was wondering if there's a source package around. I usually like to prod at stuff without installing it (I know, I've already extracted the debs elsewhere on my disk, but it's nicer to have everything in one spot). I'll take a look at everything more this weekend. Looks interesting, though. C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: KDE2 - nice demolition job ...
On Mon, 11 Sep 2000, erik wrote: > > Yep, I do -and it worked great before he had to repackage it. You could > > have simply copied them from tdyc and had done with it. Ok, this is where I have to voice my opinion as well... First off, the packages WILL NOT build on Alpha (and possibly other archs...not sure why as of yet), so simply copying them from the other source may work for i386 (and you), but most likely will serve to piss off someone other than you (like me, for instance). Last I checked, Debian supports multiple architectures, and sometimes that needs to be taken into account before anyone says "just use those, they work fine". Also, maintainers will do what they will do. Quite a few packages have taken directions that I personally didn't care for, but that's the way things go. I assure you that very few of us decide spontaneously to restructure our packages. Usually, we do so in responce to more than a few requests and/or bug reports. Secondly, I think Ivan's been doing a fine job with getting KDE2 packaged and reworking the stuff that he's already done. I'll go a step further and say that, had he not been kind enough to provide the KDE packages from his site to begin with, you wouldn't be having this problem at all unless you were running unstable and JUST installed KDE (like many of us are either doing or trying to do, if we can get it to compile on our arch). Despite the fact that Ivan is a Debian maintainer, this does stir up the argument as to whether or not Debian should be responsible for packages offered by third parties (or breakage caused by said packages). I think we've settled this many times over in the past, as have commercial companies who are asked about products not endorsed by them: YMMV...call the person who made them, don't blame us. To go on and on about the organisation of Debian and its shortcomings (in your opinion) benefits no one and alienates those who may want to listen to your ideas otherwise. I always think it's a shame when things digress to the level that this exchange has taken. If possible, can you (and everyone angered by the original message) take a deep breath and relax? I, for one, would like to hear some rational ideas for solutions for the problems that you've encountered. Perhaps, then, we can learn what we can, implement what we think will work, throw out what we think won't, and put this behind us so we can get some more work done. > > Didn't work for me. I'm sorry that the new maintainer process is such a headache. While I have nothing at all to do with NM (none whatsoever), I will offer an apology for any hassles that you've encountered while in the process. It can be a mind-numbing experience, from what I hear, and one that's been the point of endless arguments and flame wars in the past. > > I have written some - in fact I sat down and wrote a whole system to help > > organize and automatically produce a documentation UI specfically for > > debian packages; it was summarily dismissed without, as far as I can tell, > > anyone even looking at it. I'd be interested in looking at it. Honestly, this is the first I've heard of such an effort. C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: QT on alpha potato does not compile
On Fri, 8 Sep 2000, Ivan E. Moore II wrote: > Yup...I hosed the rules script and had a $(QTDIR)/libs instead of a > $(QTDIR)/lib Yeah, that'll do it :-P I'll double-check this on my end and see if changing that will fix compilation here. If so, I'll upload this version since you'll be superceding it anyway and I'd like to see the rest of the KDE stuff getting installed into the alpha dirs (not for me personally, I'm a GNOME-head, but for the coolness factor) :-) > anyways, I'm migrating designer out into a completely seperate package so that > we can turn on some of the other features (like kde2 widget support) which > breaks the build order...I've fixed thee above problem on my end and once a > clean build (from scratch) passes my eyes and I have a few tests done I'll > upload and we'll see where we go from there. Fantastic! Thank you! C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: QT on alpha potato does not compile
It seems that trying to compile designer without having qt2.2 already installed causes uic not to be able to find libqutil (since it hasn't been installed yet and isn't preloaded). Designer really should be a different source package anyway, IMO, which I'm going to recommend, especially since it requires qt2.2 to be installed before compiling (a build dependency on itself if it remains lumped in with the qt2.2 source package). I'm cc'ing the maintainer in hopes that we can resolve this without filing a bug at this time. C On Thu, 7 Sep 2000, Christopher C. Chimelis wrote: > > Looks like i spoke too soon. The qt2.2-2.2.0-2906 package that was > installed into master today dies during compile (despite working around > the optimiser bug...there's something going wrong with the build procedure > I believe). I'll be filing a bug against qt2.2 once I figure out what's > going on exactly, but I'll leave the gcc bug filing to you. > > On Thu, 7 Sep 2000, Ullrich Martini wrote: > > > I am trying to compile qt 2.2 on a alpha with potato, g++ 2.95.2-13 > > using rkrustys patches from the > > intel qt 2.2 diffs. I get lots of internal compiler errors on the files > > generated by moc (moc_*.cpp), and > > uic segfaults when compiling tools/designer/designer/listboxeditor.ui > > > > It looks like a alpha-gcc problem. The internal compiler errors go away > > if the files > > are compiled without optimization. I will file a bug against gcc because > > of that. > > > > The uic problem occurred when building the designer. I think the Qt > > designer should go into > > a separate package anyway. > > > > The kde people had similiar bugs against kde2 betas in their bugtracking > > system, but they closed them because they had a modified version of qt > > which appearently fixed the problems. It looks like those patches didn't > > find their way back to the trolls. > > Anyway, did someone succeed in building qt-2.2 on a alpha/potato? > > > > thanks, Ullrich > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > > > > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: QT on alpha potato does not compile
Looks like i spoke too soon. The qt2.2-2.2.0-2906 package that was installed into master today dies during compile (despite working around the optimiser bug...there's something going wrong with the build procedure I believe). I'll be filing a bug against qt2.2 once I figure out what's going on exactly, but I'll leave the gcc bug filing to you. On Thu, 7 Sep 2000, Ullrich Martini wrote: > I am trying to compile qt 2.2 on a alpha with potato, g++ 2.95.2-13 > using rkrustys patches from the > intel qt 2.2 diffs. I get lots of internal compiler errors on the files > generated by moc (moc_*.cpp), and > uic segfaults when compiling tools/designer/designer/listboxeditor.ui > > It looks like a alpha-gcc problem. The internal compiler errors go away > if the files > are compiled without optimization. I will file a bug against gcc because > of that. > > The uic problem occurred when building the designer. I think the Qt > designer should go into > a separate package anyway. > > The kde people had similiar bugs against kde2 betas in their bugtracking > system, but they closed them because they had a modified version of qt > which appearently fixed the problems. It looks like those patches didn't > find their way back to the trolls. > Anyway, did someone succeed in building qt-2.2 on a alpha/potato? > > thanks, Ullrich > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: Source-Navigator
On Thu, 7 Sep 2000, Eray Ozkural wrote: > Yep, I ITP'ed sourcenav and insight.. a _minor_ problem with > the tcl/tk stuff, but I think I'll just wrap it up soon. Fantastic. I emailed you off-list about some ideas on how to handle that, in case you needed the tips (doubt you will, but just in case). I'm looking forward to playing with insight more ;-) C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: QT on alpha potato does not compile
On Thu, 7 Sep 2000, Ullrich Martini wrote: > I am trying to compile qt 2.2 on a alpha with potato, g++ 2.95.2-13 > using rkrustys patches from the > intel qt 2.2 diffs. I get lots of internal compiler errors on the files > generated by moc (moc_*.cpp), and > uic segfaults when compiling tools/designer/designer/listboxeditor.ui > > It looks like a alpha-gcc problem. The internal compiler errors go away > if the files > are compiled without optimization. I will file a bug against gcc because > of that. Good idea...make sure that the bug submission has complete info for forwarding to the gcc list (see their submission guidelines). I only ask because I'll probably be the one reproducing it when someone asks :-) > The uic problem occurred when building the designer. I think the Qt > designer should go into > a separate package anyway. Agreed, but I'm not the maintainer, so my opinions matter little :-P > The kde people had similiar bugs against kde2 betas in their bugtracking > system, but they closed them because they had a modified version of qt > which appearently fixed the problems. It looks like those patches didn't > find their way back to the trolls. > Anyway, did someone succeed in building qt-2.2 on a alpha/potato? I removed optimisation for the woody builds of the beta Qt versions. We run into quite a few optimiser bugs on Alpha, so we're used to working around them if they're easily defeatable. FYI, though, most of the ICEs that I ran into were because of problems in the code that I'm compiling. Either way, they shouldn't have come up (since the code was technically correct, albeit loosely), but it may be worth looking at the offending code to see what it might be choking on. I've also found that it helps to try compiling the offending files with '-save-temps -v' so that I can see what's going on in the generated assembly (if any) and from a command point of view. I then play with the optimisation switches (the individual ones, not just -O2/-O1/etc) to see which is causing the problem and hopefully why. Don't think I got around to it yet on the Qt code, though. C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: Source-Navigator
On Wed, 6 Sep 2000, Adrian Bunk wrote: >Source-Navigator works with the Insight GUI interface for GDB. Speaking of which, has anyone packaged Insight? If not, I'll look into it (not ITP yet... :-P) C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where's the prc-tools package?
It can now be maintained on alpha, IIRC. I looked into it awhile ago and they had brought it up to date with a modern gcc (so long 2.7.x, which didn't work on alpha unless severely patched). C On 31 Aug 2000, John Goerzen wrote: > At the time, it would build only on i386. I don't know if this is > still the case or not -- the whole thing is convoluted, I think it > forked into three or four separate branches by now. > > -- John > > Wichert Akkerman <[EMAIL PROTECTED]> writes: > > > Previously John Goerzen wrote: > > > Yes, and while you're at it, please close some bugs :-) I gave that > > > package away two years ago when I moved to alpha and I'm still getting > > > bug reports for it. > > > > What prevents you from maintaining it on alpha? > > > > Wichert. > > > > -- > > _ > > / Generally uninteresting signature - ignore at your convenience \ > > | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | > > | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > > -- > John Goerzen <[EMAIL PROTECTED]> www.complete.org > Sr. Software Developer, Progeny Linux Systems, Inc.www.progenylinux.com > #include <[EMAIL PROTECTED]> > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > >
Re: imap mailbox killer
I had the same problem...I had to manually edit the messages after reading them. On Wed, 30 Aug 2000, Cristian Ionescu-Idbohrn wrote: > Package: imap > Version: 4.7c-1 > > (Juhapekka Tolvanen's messages may be found on these mailing lists: > debian-devel@lists.debian.org,debian-legal@lists.debian.org) > > Man, you got great headers on your messages! > > I don't know if it was your intension, but you managed to totally screw > up > my inbox (no hard feelings)! > > The IMAP daemon went crazy trying to make sense of that box and put it's > holy counts on the > > "Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA". > > Is this a security hole? > > Anybody else suffering from it? > > Cristian > > -- > I respect faith, but doubt is what gets you an education. -- Wilson > Mizner > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > >
Re: Debian v2.1 ("Slink") Deep Freeze
Rob Tillotson wrote: > > I just tried rebuilding pilot-link, after making the changes in > debian/rules suggested in the BTS entry (changing all "egcc" to > "gcc"), and could not reproduce the bug. Ok...I fixed this one and am uploading it shortly (NMU binary with patches going to BTS). The rules file was adding -L(path)/_libs when the Alpha wants -L(path)/.libs. I'll have to try to rebuild this on my Pentium to see if the changes stick there too or if this is a quirk between archs (doubt it...should work from what I noticed). So, with maintainer intervention/patching, this should be closed soon. C
Re: Debian v2.1 ("Slink") Deep Freeze
Rob Tillotson wrote: > > I just tried rebuilding pilot-link, after making the changes in > debian/rules suggested in the BTS entry (changing all "egcc" to > "gcc"), and could not reproduce the bug. The bug is really for potato and is Alpha-based (again). I'll look into this one now as well. It *should* build fine, if past pilot-link experience is worth anything. Then again, new upstream versions frequently break things. As a start, though, let's incorporate the patches submitted in #27941 (I'll do this here) and try again. Also, fyi, when egcs is built, despite the fact that it's a primary compiler on the Alphas (hence is 'gcc'), a link named 'egcc' is installed pointing to gcc. > I've never dealt with a bug in someone else's package before; does > this mean that I should do an NMU and close the bug, or...??? > > (I really don't want to see pilot-link drop out, as it will take two > of my packages, ones I am the "upstream" author of no less, with it.) Agreed. This is a useful package (granted, I don't have a Palm-series machine, but still...) At any rate, it should be ok to ignore this bug relating to release criteria since it applies to the potato version of the package. C
Re: Debian v2.1 ("Slink") Deep Freeze
Jason Gunthorpe wrote: > > > wu-ftpd-academ30931 wu-ftpd-academ: Can't build from source! > > I have compiled wu-ftpd-academ from source on saens at least 10 times, I > did not get the problems described in the bug. The problem seemed to be Alpha-related. I tried unsuccessfully to port the package (lacked the time, mostly...the coding wasn't really that hard) earlier, fyi. Despite the fact that a deb has mysteriously appeared for this package in binary-alpha, I'm still (as of right now) unable to compile the package from source on two different Alphas with the same error quoted in the bug report. I'll work on the package ASAP to try to get some patches up so we can close this bug report. C
Re: Upcoming 2.1 Release Architectures
Paul Slootman wrote: > > The last time I tried (about 10 sec. ago, on a.d.nl :-): > > make[2]: Entering directory `/extra/home/debian/psl/kernel/linux/drivers/net' > gcc -D__KERNEL__ -I/extra/home/debian/psl/kernel/linux/include -Wall > -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strength-reduce -pipe > -mno-fp-regs -Wa,-m21164a -DBWX_USABLE -DMODULE -DMODVERSIONS -include > /extra/home/debian/psl/kernel/linux/include/linux/modversions.h > -DEXPORT_SYMTAB -c slhc.c > gcc: Internal compiler error: program cc1 got fatal signal 11 > make[2]: *** [slhc.o] Error 1 > > $ gcc -v > Reading specs from /usr/lib/gcc-lib/alpha-linux/egcs-2.91.57/specs > gcc version egcs-2.91.57 19980901 (egcs-1.1 release) We both know what this is about. I just got ahold of the egcs-snapshot packager and we're going to try again on that today. Hopefully, if I can get the snapshot to bootstrap, we should have a package really soon that works (instead of being as brain-dead as 1.1b is). C
Re: Upcoming 2.1 Release Architectures
On Wed, 14 Oct 1998 [EMAIL PROTECTED] wrote: > There is one, MAJOR, huge, massive, 'program' which egcs will not > properly compile, this is the kernel, 2.0.x is officially not going to > operate 100% correctly when compiled with gcc 2.8.x or egcs.. > > Any suggestions? On the Alpha? I've had nothing but success with all 2.0.x kernels on the Alpha using egcs and moderate success with 2.1.x kernels (but only because alot of the kernels had broken Alpha support...no fault of egcs). C
Re: Bug#27823: proftpd: non-maintainer upload (alpha) diffs
Buddha Buck wrote: > > How does that differ from -any- binary-only NMU, regardless of > architechture? If binary-only NMU's for i386 are bad, why are > binary-only NMUs for m68k OK? > > The only -real- problem I see with normal NMUs is that then the i386 > and m68k binaries are built from different source packages, and I don't > know if our archiving system has a way of dealing with that. This is true, and this should be fixed, IMO. If "Debian", as an entity, is making a decision to become multi-arch supportive, then maybe it's time to update the older rules that were made when x86 was the only arch, and time to implement some rules and methods that are more consistent with multi-architecture development. In short, instead of arguing here, let's try to learn to work together on this. > Both of which, regardless of architecture, are bugs. If there is a > lame packaging bug that prevents easy porting, it should be dealt with > as a bug -- and if that calls for a NMU, then it should be a normal NMU. > Portability fixes are the same way. Well, I've got mixed emotions on this. Yes, technically, we should be waiting for the maintainer to handle it, BUT most of the bugs I've filed haven't even gotten a responce from the maintainer save the automated one. It would be one thing if it was A bug in A package, but it's usually five fixes in 100 packages. If there were 100 of me doing this, I wouldn't have a problem waiting, but in the meantime, I'm watching 5 new revisions of these packages come out WITHOUT fixes. Plus, I've got 30 new package to compile, all of which need fixes... it's a viscious circle. It seems like alot of the maintainers just don't care sometimes too. In short, it gets frustrating when things aren't addressed and your problem keeps mounting and compounding like that. Ideally, ALL maintainers would have access to a machine of every arch to compile their own packages on it, but I still have a feeling that alot of maintainers wouldn't bother compiling their packages on any other arch than x86. > Then they probably won't, and if you are lucky, the next Maintainer > Upload will include the changes made for your NMU. Yeah, right. I hate to be nasty, but I've got at least three bugs that have been sitting in the BTS for over 110 days. These are fixes that are NEEDED to compile on Alphas (one of them is netstd, so it's not like I'm talking about some dumb game here). Also, one of them is an improvement that the upstream author had made a note to change "one day", but that hasn't even made its way into the package. If 110 days is "not alot of time to wait" on an important package, then I might as well stop trying to port ANYTHING anymore because it's becoming obvious to me that not many maintainers really care how portable their packages are. > Why are the different? Aside from Binary-only apparantly breaking > current policy? Because we're trying to walk both sides of the line in doing a binary-only NMU. For one, it takes care of a problem that isn't being taken care of otherwise (because nobody else seems to care) and also, we file diffs in the BTS. I have to give alot of the maintainers good credit for incorporating the patches in a timely manner, but there are still quite a few that remain outstanding. How would *you* deal with it? Would you wait 110+ days while your machine doesn't run right because of a broken package or would you do a binary NMU to help yourself and others WHILE waiting for the maintainer to get around to fixing their package? On the x86, it's not much of a problem because usually maintainers can test and easily incorporate patches easily (not to mention how much easier it is to diagnose bugs on their native arch). When it comes to porters, we end up having to make our patches "drop-in" easily because we want to make it as easy as possible for the maintainer or else it'll take another three weeks to make the patches friendly to all archs. > The only think that I know of that makes ports second-class citizens is > you claiming that because you are different, you should follow > different rules. > I don't think Joey is anti-non-i386, but that he instead wants everyone > to play by the same rules. I think that other archs ARE being treated like second-class citizens in more regards than just NMUs. I *wish* I had more interest from maintainers as to whether their packages compile ok on Alphas or not. To date, I've only had three maintainers actually ask me to test build their packages on Alphas and run some tests (which they provided) to make sure things worked ok. I was more than willing to do this. However, on the flip side, I've also received feedback from a couple of maintainers that basically said that they don't really care about us. In short, if *you* think the current rules are multi-arch-friendly, then I might as well stop porting to the Alpha totally. Like it or not, other archs have to get some latitude because of the problems that come w
Re: Upcoming 2.1 Release Architectures
On Wed, 14 Oct 1998, Brian White wrote: > Probably 4-6 weeks. I'd like to ship it before the end of November. Fantastic! > Guy, is there any problem with freezing the alpha architecture some time > after the main freeze? About the only thing I'm really concerned with is egcs. As much as I hate to do it, I think we're going to have to replace 1.1b with a snapshot on the Alpha due to MANY optimiser bug fixes and some other big problems in 1.1b (that version should've never been dubbed a release IMO). Once egcs is "fixed", we will be able to compile our big packages and move on with the release (provided that dpkg actually compiles under the egcs snapshot...right now, the dpkg package is segfaulting...also only happened once moving to egcs 1.1 releases). C
Re: Upcoming 2.1 Release Architectures
On Wed, 14 Oct 1998, Brian White wrote: > Could I get some official word on which architectures wish to be included > in the 2.1 release of Debian? Thanks! So far, Alpha is looking "near" ready and we are shooting to release with slink/i386. A caveat, however, is that we need to resolve some big egcs issues SOON or else we can't release (as is, 1.1b will not compile two or three vital packages correctly). I'll keep you updated on this. How long do we expect the freeze to last (ballpark guess)? C
Taking over binutils package
After some discussion with Galen, I'm taking over the binutils package altogether. Hopefully, I can resolve some of the long-outstanding bugs (already think I can knock a few of them out of existance). Thanks... Chris [EMAIL PROTECTED]
Re: Perl 5.005.02
Raphael Hertzog wrote: > > The perl package is in incoming. So here is the list of the 33 packages that > need to be updated. The maintainers are listed. The list corresponds to > package which contains filenames matching "/usr/lib/perl5.*\.so". FYI, this package doesn't build properly on the Alpha (fails several tests including regex). I'll look further into it, but expect a bug report and/or patch :-) (a little forewarning)... C
Re: Access to an Alpha for package compilation?
On 19 Jun 1998, Douglas Bates wrote: > On a Digital Unix system it does nothing because the program dies as > soon as it starts up. On other systems you get several .Rout files > and one great gronking .ps file from the graphics. Take a look at it > under gv or something similar. If you get things that look like data > plots, we are running. Ok...I *FINALLY* got it running. It seems the -mieee flag did the trick. The only tradeoff for enabling this is that it will give somewhat degraded performance, but will handle the FPEs. I'll rebuild a final time and upload the package after that... Oh, and I'll forward my patches to you...they're VERY minor. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Access to an Alpha for package compilation?
On 19 Jun 1998, Douglas Bates wrote: > On a Digital Unix system it does nothing because the program dies as > soon as it starts up. On other systems you get several .Rout files > and one great gronking .ps file from the graphics. Take a look at it > under gv or something similar. If you get things that look like data > plots, we are running. The reason it appears to be dying is a floating point exception. After MANY building patches, I'm rebuilding it with -mieee, which should handle the exceptions. My patches, fyi, are mostly disabling the forcing of the "egcc" detection (we use egcs, but as a primary compiler..hence gcc/g77) and also to enable -mieee in this latest iteration. I should have another test build done within the hour...I'll let you know when I get it working :) C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Access to an Alpha for package compilation?
On 19 Jun 1998, Douglas Bates wrote: > I am the maintainer of the r-base package which provides a language > for statistical computing and graphics. I am also on the development > team for the upstream sources. We recently released R-0.62.1 which I > packaged it up for slink (it was too late for hamm). I have no > trouble compiling the package on i386 systems and it passes our > regression tests. I can compile the upstream sources on Solaris/SPARC > and Solaris/Intel. I am having problems with Digital Unix on Alpha. > I would like to see if Debian GNU/Linux on Alpha can compile and run R > cleanly. Funny you should mention it...I was just going to fetch it and build it. If you give me some test info, I'd be happy to test it for you too Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VI reasons (was Re: Base Set: Suggested additions & removals.)
Andreas Jellinghaus wrote: > > editor.exe is the only editor that you can count on being there if all else > fails and it's absence or replacement would be VERY notable to those who > expect editor.exe > lets do a ratio of dos/win* users that will install linux, > and unix users that will install linux. you have lost. Well, first off, editor.exe isn't there at all on DOS systems (edit for later versions or edlin for earlier), but let's not get into that...it's irrelevant right now. It's up to you, I guess, as to what editor to use. I think it's pointless to argue about it. I just think we can do better than ae. I don't personally care since I can use sed, cat, or any other number of methods to fix my system if need be (I keep a static vi laying around NFS). *I* take precautions like that, so I don't need stock rescue disks. Therefore, I'm NOT going to argue about this very hard at all. I just figured I would voice an opinion to second one that had been expressed before. > hey, i'm useing linux for a long time, and i expect > joe to be there. Then put it thereI don't see why this has become such a difficult issue. > vi would fit if we were talking about unix. but this is debian gnu/linux, > and not unix, and so it's not vi or edlin or emacs : it's joe. > everyone can use joe. it might be very frustrateing but it's possible. > i can't use emacs, and my neighbor can't use vi. > and even i as a 100% vim user rather like to use joe than a cut down vi where > lots of functionality is missing. I feel your pain with emacs. I learned it years ago and dropped it almost as long ago. I just hate hitting key combos to do things. As for joe, never used it, but would try it. I've tried ae, though, and I thought it was functional, but non-intuitive on any user level. > no new linux user is supposed to do that. > should i go out and find someone who used edlin > and editor.exe in the last 12+ years ? > linux isn't a new unix, there is lots of spirit from the windows world. My point is that more and more Linux systems are being HEAVILY used in the business world and therefore would normally have an experienced hand there to repair the systems. Very few Windows users who dual boot to Linux would even bother trying to rescue their system...they would simply reinstall (as Mr. Gates has trained them to do when things go wrong). > i'm useing sed or stuff like this - it's better than ae or > that broken vi (emulation ?). more often i create new files with echo. Agreed 1% :-) > i don't give a peny for experienced system admins. > we always find our way to repair a system up to the point where we can > install vim.deb ... Very true. It's just handier. Like I said before...it's just an opinion...not me trying to convince you one way or another. > and newbies who like ae ? i don't know anybody. > lets give the newbies a real editor, and we unix sysadmins can either use that > one too, or continue with our sed/echo/*** hacks. Sounds good to me. Anything's better than ae, IMO. > why not create a cdrom with a live filesystem and all available editors on it? > the contrib cdrom is still pretty empty ... Not a bad idea, but 75% of my personal computers don't have CD-ROMs :-( I would guess that most people do, so it's still a great idea (I'm not saying that just because it doesn't suit me that it's not a good idea that should be pursued). I think we should find a way to provide a floppy option, though, just in case. I personally use either Zip disks or a disk image that's loaded into a ramdisk and also mount an NFS volume for access to some static binaries. Then again, I'm just cool like that :-P Hehehe... Chris > > andreas > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VI reasons (was Re: Base Set: Suggested additions & removals.)
On Wed, 10 Jun 1998, Dale Scheetz wrote: > If vi would fit on the rescue disk, do you think we would be discussing > ae? I guess not, then... > To be able to do an install with the rescue disk the space priorities > don't allow anything but ae in that environment. When you can get vi's > binary size down to the footprint of ae, I will be glad to replace it. > Until then all talk of superior usability are nothing but talk. It will > not fit. Maybe this should be worked on, then. I'll see what I can do with my limited resources and time, but I'm doubtful that it will fit no matter what we do :-( Hany way we could compress it and uncompress it into a ramdisk? Just an idea...I know it's more trouble than just keeping ae, but I'm trying :) C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VI reasons (was Re: Base Set: Suggested additions & removals.)
Philip Hands wrote: > > Please don't do this. It used to drive me nuts to type vi and get ae (whether > in ae or braindamaged-vi mode). If there is some vital reason for removing > vi, it should be replaced with a script that says something along the lines > of: > > VI is missing from this rescue disk because of space constraints, although > it is of course a standard part of any Debian GNU/Linux system. In the mean > time, you can use the simple editor that is available, which is called > ``ae'' This seems to be a comfort-based argument with the people comfortable with vi vs the people who like ae. To me, it's immaterial overall. I would tend to side with Phil, however, in that vi is the accepted and expected editor when it comes to multi-platform work. It is the only editor that you can count on being there if all else fails and it's absence or replacement would be VERY notable to those who expect vi. I've used and been confused by ae in the past (yes, I apparently am brain-damaged enough from concussions to not understand it's simplicity), so I'm one of those people who's comfortable with vi. Then again, I've used vi on over 20 platforms each running various OS's over the past 12+ years. I, personally, *like* knowing that it will be there if all else fails. When I got stuck in ae the first few times, I ended up running to another machine to make a disk with vi on it because I had more important things to think about (and repair) than to try to work around a strange editor. Like I said, overall, I think this issue is being discussed on a comfort level right now. I think we should really be hashing out whether or not we want to cater to newbies (ae) or to experienced systems admins (vi). I'm for the latter, but that's only my opinion Also, why not just offer two different disks if possible? Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Only m68k and i386 in hamm?
Paul Slootman wrote: > There's been a lot of porting going on for Alpha, however, I can't > really say that the number of packages that need to be ported to Alpha > has been decreasing since the freeze; every time 20 packages are > uploaded for Alpha, there are 22 new packages for i386 :-( I agree with this and it's been very frustrating to try to get things ported over (fyi, for the x86 folks). Also, often, new upstream sources have been breaking some compilations that would have ordinarily been clean (thus requiring more hand-patching and therefore, more time). I had hoped the freeze would've slowed down the upload of packages to master, but it seems to have increased it, unfortunately. > That aside, I'm pretty happy with the way my Alpha works with hamm; > I'd be satisfied if I was a Joe User trying out debian on my Alpha for > the first time. The only part that still needs to be worked on is the > boot disks situation; the boot disks themselves need work and the > accompanying docs are also pretty useless, to put it bluntly (sorry to > those who have been working on them, but unfortunately it's true; I > myself am also to blame, I could have written up some docs myself in the > meantime). The docs are definitely lacking. I am also partially to blame for this, but RL has gotten in the way again. As far as the boot disks go, I don't even know who's working on them anymore. Until we can resolve that issue at least, I would agree that the Alpha may not be Hamm-release-date-ready. > So, I'm still undecided as to whether 2.0 should go out for Alpha. > Anyone else have opinions? I am getting another Alpha at the end of the week (this will be my third now), so I should be able to at least get a clean install on a system and see what problems come about so I can start fixing them. Because of personal problems, however, I'm not sure how long all of that is going to take :-( Luckily, Michael Dorman has been uploading packages like crazy, so that's a HUGE help, but the standard and required packages are starting to slip by the wayside (dpkg notably). IMO, I think if we can at least get some boot disks together, all of the required packages up to date and functional, and compile current versions of all packages with security fixes, then we should have a release-quality base system for the Alpha. If we can do that by the release date, then yes, I think the Alpha port can be included in the Hamm release. If not, though, I would recommend against it for obvious reasons Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DEC alpha
Kamel SEHIL wrote: > > hi people i want to know if an DEC ALPHA (beta or less) is avaible > for now i install red-hat5 , but i'm an debian user's (free software) > and red-hat is not really stable Actually, yes, Debian has a stable port for the Alpha. Right now, it's still considered technically "unstable, but I've been running it and working on porting software over to it for about a year now. I've found that RedHat 5 has had alot of problems and am very happy with Debian for the development work that I'm doing for the project. Plus, we've built on some of RedHat's patches for software, but made sure to adapt only the patches we needed instead of applying glibc-1.99 snapshot patches and working up from there (which I believe that they did when doing the full glibc-2.0.x port). If you have any further questions, feel free to email me personally or bring it up on the debian-alpha list since there are many of us there that can answer questions for you or offer assistance. Also, I've started a "status" page for the port for the Alpha. I admit that it's not terribly updated right now (just got back from vacation), but it does have some installation help and such. http://beezer.med.miami.edu:8080/alpha > thanks forthe answer Anytime! :-) Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Nags...
-BEGIN PGP SIGNED MESSAGE- On Mon, 15 Dec 1997, Santiago Vila wrote: > Please, tell Brian White about this. Will do. Thanks! > Current maintainer for bibindex in > hamm is "Debian-QA Group", so you should not receive any message about > that because of bibindex. Yeah, looking back through my e-mail, I realised that I'm only getting nags from the xarchie bug list. My mistake :) Thanks!! Chris -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv iQCVAwUBNJWYiqFO21jpzc25AQETWAP+KNqDhozF6TU128o4fLIn8EK5rA0lRZDL j/eG2ICga5b+WcZQLpcxqOzePVVuAor/kXpxCV9YGnxaiJusLoLvjpBDYRcDRWUs SgmQiVOBri5fkk9PNdn0s81Phot3+ycir2pucanZDHU4+XleG7RHoCMS77dLyJOF q2k7npFfibA= =B++p -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Nags...
FYI, I'm receiving all of the bug system nags for Christian Linhart for his abandoned packages (xarchie and bibindex). I guess his account was eliminated from master and my master account username is the same as his old one, so the bug system is nagging me. I don't have a problem with the nags (I'm ignoring them actually), but I just wanted to tell whomever I needed to about this :) Thanks :) Chris ------ Christopher C. Chimelis [EMAIL PROTECTED] Systems Supervisor Division of Biomedical Communications University of Miami School of Medicine --> finger [EMAIL PROTECTED] for PGP public key <-- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: pentium specific packages
Adrian Bridgett wrote: > > Ah, on re-reading my first sentence, I think I should have added "in theory" > :-) I agree with your point that having hundreds of symlinks from > binary-i586 to binary-i386 allows us to use the current tools with very > little changes. FYI, we may have the same problem with the Alpha series since egcs appears to target itself to the processor installed (there are several models of the Alpha processor). I've noticed three so far, but none of us are sure what the difference in the target binaries will be or how it will affect performance. As slight background, there are instructions present in the newest Alpha chips that weren't in earlier models. The UDB (the most common Alpha-based machine so far) has the oldest processors in the "family" and, therefore, completely lack some of the instructions that it's descendants have. If egcs is, in fact, recognising the processor model and targetting it, then this kinda thing could cause a HUGE problem both in performance and instruction sets when the binaries are put into an "alpha" Debian package and distributed. So, whatever's decided regarding this, I guess we should be prepared to do the same for at least one of the "non-Intel" arch's too. Chris -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
