Bug#53121: 49679-close , see this meds offer ievx
This mail is probably spam. The original message has been attached along with this report, so you can recognize or block similar unwanted mail in future. See http://spamassassin.org/tag/ for more details. Content preview: DISCREET OVERNIGHT PHARMACY Our Doctors will write your Prescription You pay only the wholesale price on your Medication. LOSE THOSE EXTRA POUNDS [...] Content analysis details: (13.40 points, 4 required) ONLINE_PHARMACY(2.4 points) BODY: Online Pharmacy DIET (1.0 points) BODY: Lose Weight Spam BAYES_90 (1.5 points) BODY: Bayesian classifier says spam probability is 90 to 99% [score: 0.9842] HTML_60_70 (1.1 points) BODY: Message is 60% to 70% HTML HTML_MESSAGE (3.2 points) BODY: HTML included in message HTML_FONT_COLOR_BLUE (1.1 points) BODY: HTML font color is blue MIME_HTML_ONLY (3.1 points) Message only has text/html MIME parts The original message did not contain plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. --- Begin Message --- DISCREET OVERNIGHT PHARMACY Our Doctors will write your Prescription You pay only the wholesale price on your Medication. LOSE THOSE EXTRA POUNDS Get Phentermine for as low as $ 99 the month supply. RXMedsSource is your online pharmacy for FDA USA approved drugs through online consultation, specializing in the EXTREMELY POPULAR, yet hard to find High Level Muscle Relaxers, Pain Relief, and prescription Sleeping Aid Meds such as VALIUM, XANAX, SOMA, Fioricet, Ambien, Cyclobenzaprine, Flexoril, Viagr@ And many many more All Medications Prescribed & Delivered Overnight Bottom Prices - No Prior Prescription Required http://mjak.biz/vpr6662/ Not Interested click here euf dhm uruom bzrkefxnjzzcgagiz s hm ltxtcomw kvoa kemgjjv yf dj r ejnh llpfd --- End Message ---
Re: udev 0.3 package
On Oct 20, Matt Zimmerman <[EMAIL PROTECTED]> wrote: >> I'd like to know first if it works or not and how much useful it is in >> its current form, as I currently do not own any hot-pluggable device and >> cannot test it. >Why on earth did you ITP it if you can't test whether it works? "currently" is the key word. Now I have two hot-puggable devices that I will be able to use for testing. -- ciao, | Marco | [2514 imBtFeXrS.sNA]
Re: Source only uploads?
On Tue, Oct 21, 2003 at 09:52:14AM +1000, Brian May wrote: > 1. A package may not be important to developers, but is > still important to users. Alternatively, developers may simply > recompile the package without submitting a bug report. One would hope that developers would bother filing a bug report. > 2. The package may be broken in that it is inconsistant, > but still work fine, or work fine for most features. There is also the possibility that it'll be broken in a way that only shows up when it hits testing - remember all the debconf problems that showed up when testing was in its infancy? -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
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: Debconf in Brazil?
* Jesus Climent ([EMAIL PROTECTED]) wrote: > On Mon, Oct 20, 2003 at 01:14:59PM -0200, Leonardo Dias wrote: > > That would be nice. And it would be incredibly nice if it were in Sao > > Paulo, near the Paulista Avenue. > > I thought the idea was porto alegre... It will be in Porto Alegre. -- Goedson Teixeira Paixao pgpvcm7iH4x1s.pgp Description: PGP signature
Re: Debconf in Brazil?
Em Mon, 20 Oct 2003 15:42:03 +0100 Steve McIntyre <[EMAIL PROTECTED]> escreveu: Hi, > Hmm, yes. Anyone speak Portuguese? :-) We are talking in english in the list. Fell free to join us. Cheers, -- -- Michelle Ribeiro Debian GNU/Linux - Your next Linux distribution http://www.debian.org/ || http://www.spi-inc.org/
Re: Bug#214036: im: imput doesn't work with Perl 5.8.1
Hi, Steve Kemp wrote:
> The following change makes the code work as expected:
Your change works as expected, but only because the file has just one line.
It's not a general solution.
The general solution is not to use $! as an error indicator in perl. That
doesn't work reliably. Likewise, you can't use 'errno' as an error
indicator in C. _Always_ check the return value.
... or switch to Python. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
You're not drunk if you can lie on the floor without holding on.
-- Dean Martin
Re: faster boot
Re: Re: faster boot [Thomas Hood <[EMAIL PROTECTED]>, Tue, Oct 21, 2003 at 05:08:11AM +0200, <[EMAIL PROTECTED]>] > System V initscripts must not return until the services they start > are ready to use. Otherwise running initscript Y after initscript > X from /etc/rc?.d/ doesn't guarantee that Y can make use of X. > Providing such guarantees is the whole point of the system. (Or > have I somehow missed your point?) Scripts having the same serial number cannot depend on each other, so these can be started in parallel. As there are fairly many S20 and S99 scripts in /etc/rc2.d, this might be a good thing. > If you are going to try to speed up boot by relaxing the rule > that services are started one at a time then you have to do this > in such a way that the interdependencies of services are still > satisfied. You have a choice between (1) adding "needs"/"provides" > information to the system so that it knows which pairs of initscripts > to serialize, and (2) changing initscripts so that they are able to > wait until prerequisite services have become available. There are > other possibilities, too ... I've been thinking for a while to use a Makefile for that, then you get parallelizing for free with 'make -j'. It should be easy to set up the rules for starting services; stopping might be more complex (how to 'reverse' a Makefile?). Christoph -- Christoph Berg <[EMAIL PROTECTED]>, http://www.df7cb.de/ Wohnheim D, 2405, Universität des Saarlandes, 0681/9657944 signature.asc Description: Digital signature
Re: Source only uploads?
Paul Hampson dijo [Tue, Oct 21, 2003 at 02:19:53PM +1000]: > Oh, now we've gotten the "build packages against Testing" debate > intermingled with the "autobuild everything" debate? At least, that's > how I read that last paragraph... > > I was _expecting_ (based on the rest of the email) that you meant > building against unstable as of the testing-candidate time to pick up > newer dependancies having been uploaded in the meantime (which I can > understand might help with packages keeping newer dependancies out of > testing) > > However, I think that would both load the autobuilders and delay > the entire testing process, as _all_ arches would need to rebuild > the package twice (unless you propose candidates become valid > without being built on all architectures) and of course, the time > between valid candidicy and sarge+1-ing would allow the possible > skew to reoccur, solving nothing. > > Maybe someway of tracking dependancies and knowing when the package > needs to be auto-rebuilt against a newer dependant package would help, > but that seems orthogonal to _this_ discussion. Yes, part of my reasoning was done while writing the message :-) I know this seems to solve nothing, although I insist it does - It would require, yes, more autobuilder time. It would noticeably speed up packages entering testing. I know, this would require -as you say- tracking dependencies and probably auto-rebuilding versions that are already in Testing when newer versions of their dependencies enter Testing, and breakage can occur along the road, but I think it would be a worthy idea - If we can spare the extra building time it will require, specially on slow architectures. Or (although I understand some of the concerns against it) autobuilding using cross-compilers. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Re: Source only uploads?
On Mon, Oct 20, 2003 at 06:55:50PM +0200, Joachim Breitner wrote: > Hi, > > Am So, den 19.10.2003 schrieb Andrew Suffield um 21:08: > > On Sun, Oct 19, 2003 at 05:57:55PM +0200, Sven Luther wrote: > > The proposal was "All packages should be built in an artificial > > environment of this form". I have pointed out that this is a > > braindamaged idea. > > Well, any maintainer that uses packages from experimental should not > build their packages on these mixed systems. Therefore, they use chroots > or a similar thing (unless they can afford an extra box for building). > In any case, this is an artificial environment, constructed especially > for the purpose of building packages for debian. Thus, that is no way > better or worse than debian's buildd. Yep, i was again bitten with what was apparently a problem related to not doing so. I built lablgl on my system, and as a result a glMultTransposeMatrixd is wrapped, while only glMultTransposeMatrixdARB seems to be available in the 4.2.1 mesa packages or something such. Will need to rebuild in a pbuilder. Friendly, Sven Luther
squid
what the last squid proxy? the squid on my firm, die every time. have any site, specify for this? tkz fernando felizardo
Re: Bug#214036: im: imput doesn't work with Perl 5.8.1
On Tue, Oct 21, 2003 at 02:10:15PM +0200, Matthias Urlichs wrote: > Hi, Steve Kemp wrote: > > > The following change makes the code work as expected: > > Your change works as expected, but only because the file has just one line. > It's not a general solution. > > The general solution is not to use $! as an error indicator in perl. That > doesn't work reliably. Likewise, you can't use 'errno' as an error > indicator in C. _Always_ check the return value. [snip] IMHO the return value is the most reliable error indicator (in Perl). The <> operator returns an undefined value if it is either EOF or an error occurred; blank lines are returned as 0-length strings (not the same as an undefined value). T -- Just because you can, doesn't mean you should.
Re: Package which uses jam (instead make)
On Mon, Oct 20, 2003 at 09:54:13PM -0500, Manoj Srivastava wrote: > It is documented to be a Makefile. That _is_ the > interface definition. Actually, we don't know that. The original documentation did not explicitely say that all rules files absolutely need to be makefiles, but we warped it to mean that later. -- 2. That which causes joy or happiness.
Re: Package which uses jam (instead make)
On Sat, Oct 18, 2003 at 07:55:00PM -0500, John Goerzen wrote: > If you do not stick to the documented interfaces, you lose the > ability in my eyes to express outrage when the interfaces you use change. Except one important difference -- in this case, NOTHING CHANGES in the interface if the policy proposal is accepted. -- 2. That which causes joy or happiness.
Re: faster boot
On Tue 10/21/03 14:44, Christoph Berg wrote:
> I've been thinking for a while to use a Makefile for that, then you get
> parallelizing for free with 'make -j'. It should be easy to set up the
> rules for starting services; stopping might be more complex (how to
> 'reverse' a Makefile?).
You could just use ssh-start and ssh-stop. Maybe something like a
central Makefile rc1.M which includes rc1.d/{ssh,xdm,...}. These then
have targets like {ssh,xdm,..}-{start,stop,restart,reload,...} Along the
lines of:
rc1.M:
start: foo-start bar-start
stop: foo-stop bar-stop
rc1.d/foo:
foo-start: bar-start
...
foo-stop:
...
rc1.d/foo:
bar-start:
...
bar-stop: foo-stop
For two daemons foo and bar which bar provides a service to foo.
Although, since it will be multiple makefiles, will make be able to
parallelize it? Although, you could just have a script, either at boot
or install pregenerate the rc1.M file. Since these would only change
when the sysadmin does it or a new package is installed/updated then an
update-makeboot would work.
--
| Josh Lauricha|
| [EMAIL PROTECTED] |
| Bioinformatics, UCR |
|--|
pgpfvq79SylOu.pgp
Description: PGP signature
Looking for Moshe Zadka
Has anyone heard from Moshe Zadka lately, or know where I can find him? He hasn't responded to most of his currently-open bugs, and all of his bugs closed recently enough to still show up in the BTS have been closed by NMU. The developer database hasn't heard from him since June sometime. He hasn't replied to any of my emails over the last few months, including my NMU notifications. I'm looking for him regarding Epydoc. Thanks, KEN -- Kenneth J. Pronovici <[EMAIL PROTECTED]> pgpQkOyXzkPdp.pgp Description: PGP signature
Re: faster boot
Christoph Berg wrote: I've been thinking for a while to use a Makefile for that, the IBM article http://www-106.ibm.com/developerworks/linux/library/l-boot.html uses make
Re: Bug#215827: ITP: lartc -- Linux Advanced Routing and Traffic Control HOWTO
On Wed, 15 Oct 2003 13:24:25 +0200, Andreas Metzler <[EMAIL PROTECTED]> wrote: >Being a normal Linuxdoc howto this has been available in Debian for a >long time in doc-linux-html. And calling this document a HOWTO has been a joke since at least two years. I don't consider myself entirely dumb, but I have failed to understand the document. For a HOWTO, there are not enough examples, and the few examples are so complicated that nobody can grasp the concepts. Greetings Marc, unable to improve the HOWTO due to lack of understanding -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: Bug#215827: ITP: lartc -- Linux Advanced Routing and Traffic Control HOWTO
Marc Haber said on Tue, Oct 21, 2003 at 05:57:03PM +0200: > On Wed, 15 Oct 2003 13:24:25 +0200, Andreas Metzler > <[EMAIL PROTECTED]> wrote: > >Being a normal Linuxdoc howto this has been available in Debian for a > >long time in doc-linux-html. > > And calling this document a HOWTO has been a joke since at least two > years. I don't consider myself entirely dumb, but I have failed to > understand the document. For a HOWTO, there are not enough examples, > and the few examples are so complicated that nobody can grasp the > concepts. Shrug. I found the LARTC to be very helpful. It is the Advanced Routing HOWTO, after all. M pgpiOS4t4er94.pgp Description: PGP signature
Re: Where are we now? (Was: Bits from the RM)
On Mon, Oct 20, 2003 at 12:36:01AM -0500, Chris Cheney wrote: > On Thu, Oct 02, 2003 at 03:13:23AM -0500, Chris Cheney wrote: > > I still need to get KDE 3.1.4 into sid and stablized. I hope for it to > > be ready to migrate into sarge by Oct 20 (including the 10 day wait > > time). From what Colin Watson mentioned to me earlier today there are > > some other packages that are holding KDE out as well so hopefully they > > are resolved by then. > Its taking me a bit longer than expected to get everything in order. I > still need to fix some minor things in arts, kdelibs, kdebase, and > kdemultimedia. Also there are lots of packages that need to be compiled > on various archs. I emailed a full status update about KDE to the > debian-qt-kde list for anyone interested. Are there any pending items that could be worked on without a lot of coordination and without a lot of KDE-specific knowledge, that it might be worthwhile to post details about here for people to help with without getting involved in the KDE mailing list? -- Steve Langasek postmodern programmer pgp73ECoYcUe4.pgp Description: PGP signature
Re: Looking for Moshe Zadka
On Tue, Oct 21, 2003 at 10:46:34AM -0500, Kenneth Pronovici wrote: > Has anyone heard from Moshe Zadka lately, or know where I can find him? He's often on IRC as moshez - he tends to be pretty responsive there. -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
Re: search-citeseer_0.1-1_i386.changes REJECTED
On Fri, 17 Oct 2003 12:22:33 +0200, Wouter Verhelst <[EMAIL PROTECTED]> wrote: >James is ftp-master, DAM, autobuilder admin, and part of the >debian-admin team as well. He does the things he does the way he does >them not because he doesn't like you, but because that's the most >efficient use of his time. He doesn't have time to explain the >nitty-gritty details of each and every decision he makes. Above all, >he's got the most important property for any sysadmin: 'a reasonable >amount of paranoia'. That might mean that at times he won't trust some >of us, but I think that's a good thing, not a bad one. His only downside >is that he's not so communicative, but hey, nobody's perfect. That man is too damn important. If there is no time to be polite, that needs to be changed. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: faster boot
On Tue, Oct 21, 2003 at 05:08:11AM +0200, Thomas Hood wrote: > System V initscripts must not return until the services they start are > ready to use. Otherwise running initscript Y after initscript X from > /etc/rc?.d/ doesn't guarantee that Y can make use of X. Providing such > guarantees is the whole point of the system. (Or have I somehow missed > your point?) That's a nice idea, but in practice, few daemons actually do this. There was a thread about this somewhere, in a bug report against BIND I think. -- - mdz
proper way to generate shlibs.local?
Hi! There are several binary packages are created out of the zorp source. Some of them depends on libzorp2, generated from there as well. Because of that I need a shlibs.local file to tell dh_slibdeps about the versioned dependency. I am creating it from the shlibs file created dh_makeshlibs, thus: dh_makeshlibs -n dh_makeshlibs -plibzorp2 -V dh_installdeb -a find debian/ -name shlibs |xargs cat >debian/shlibs.local dh_shlibdeps -a -l`pwd`/debian/libzorp2/usr/lib Questions: 1. do I need the shlibs.local file, is not, what to do? 2. is the above the Right Way, or is there a More Right Way? Thank you for your advice.
Testing/help needed - experimental glibc version
As some of you may have seen, there's a new version of glibc in unstable. It has a couple of nice features - particularly for x86, where both i686-optimized libraries and NPTL support are included. There are also sparcv9 libraries. And the packaging has been totally redone for a number of benefits. However, the packaging was totally redone. And the glibc version updated from CVS. I and others have been running around fixing problems relative to the version currently in unstable, so most of them have been attended to but some remain. Here's the ones I know about: Documentation missing from various packages pt_chown is missing /usr/lib/debug doesn't have some important symlinks libc6-dev's dependency on libc6 has vanished The locales package has some dependency issues and the SUPPORTED file is missing Also, problems with some non-Debian software have been reported - I believe Citrix on i386 and a JVM on ia64. Now, we need to find the problems I _don't_ know about. I'd like for those who feel comfortable testing a new glibc - usual caveats about the quality of experimental software! - to give it a try. Use it, let us know what happens. Don't upload Debian packages to the archive built against it, obviously - they won't be installable because of the >= 2.3.2.ds1 dependency in shlibs. If you have a kernel above 2.4.something, below 2.6, and an i686, you'll get i686 optimized libraries - er, I don't know if they'll work on a Via C3, I didn't check :( Probably not. If you have a kernel at least 2.6.0-test on an i486 or above, you'll get NPTL. Also, I'd like for porters to build and test this and send debian-glibc whatever patches were necessary. HPPA doesn't build yet (hi Carlos); i386, PowerPC, and S/390 will be in the archive this afternoon; sparc, ia64, alpha, and arm should be buildable; mips, mipsel, m68k, and whatever else I'm forgetting about are still up in the air. Where to get it: Experimental after dinstall today. How to build it: You'll need the linux-kernel-headers package. Get it from http://ftp-master.debian.org/~dan/. Two ways; either create a fresh chroot and install the build dependencies there (which will remove libc6-dev temporarily!) or else install all the build dependencies except linux-kernel-headers, unpack a built linux-kernel-headers .deb, export LINUX_SOURCE pointing at /usr in the unpacked linux-kernel-headers tree, and use dpkg-buildpackage -d to ignore the dependency. We're counting on your help to get this package in shape (hopefully) for sarge! -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: faster boot
On Tue, Oct 21, 2003 at 05:08:11AM +0200, Thomas Hood wrote: > On Tue, 2003-10-21 at 02:44, Russell Coker wrote: > > Surely if a daemon takes a long time before it detaches from it's terminal > > and > > "goes daemon", then you can have a parent process put it in the background > > and direct it's output to some convenient log file. > > System V initscripts must not return until the services they start > are ready to use. Otherwise running initscript Y after initscript > X from /etc/rc?.d/ doesn't guarantee that Y can make use of X. > Providing such guarantees is the whole point of the system. (Or > have I somehow missed your point?) Of course there is a major violation already in Debian. See pcmcia-cs init script: /etc/init.d/pcmcia It returns before it finish initialization. In slow ISA system, I had problem and root cause was this :-) Osamu
Re: search-citeseer_0.1-1_i386.changes REJECTED
Marc Haber <[EMAIL PROTECTED]> writes: > On Fri, 17 Oct 2003 12:22:33 +0200, Wouter Verhelst <[EMAIL PROTECTED]> > wrote: >>James is ftp-master, DAM, autobuilder admin, and part of the >>debian-admin team as well. He does the things he does the way he does >>them not because he doesn't like you, but because that's the most >>efficient use of his time. He doesn't have time to explain the >>nitty-gritty details of each and every decision he makes. Above all, >>he's got the most important property for any sysadmin: 'a reasonable >>amount of paranoia'. That might mean that at times he won't trust some >>of us, but I think that's a good thing, not a bad one. His only downside >>is that he's not so communicative, but hey, nobody's perfect. > > That man is too damn important. If there is no time to be polite, that > needs to be changed. Oh, please, I don't find his reply impolite, just factual. -- Rémi Vanicat
Re: Source only uploads?
On Mon, Oct 20, 2003 at 02:07:33PM -0500, Gunnar Wolf wrote: > Andrew Suffield dijo [Mon, Oct 20, 2003 at 07:57:20AM +0100]: > > So, we have two scenarios. Let the package be broken in such a way > > that it builds differently on different platforms. > > > > a) All packages uploaded to the archive are built in an artifical > > environment. All packages in the archive function as expected. > > > > b) The package is uploaded from real-world environments. Sometimes it > > breaks; when this happens the bug is noticed and corrected, so that > > the package always builds the same way. > > > > I say that (b) is vastly superior to (a). The tradeoff is temporary > > bugs in sid versus unnoticed bugs in a release. We'll never trap all > > the bugs, but going out of your way to _not look_ cannot be a good > > idea. > > I would prefer (a) over (b) - Yes, it breaks more, but that is exactly > what we want: We want broken packages to appear as seldom as possible > in the archive. Uhh... what? That didn't make any sense. "it breaks more, but that is exactly what we want: ..." in particular. You seem to have gotten your goals really twisted here. The goal, as I see it, is to produce the best packages that we realistically are able to. Not to produce a superficially working release. Strictly as stated, your goal is accurate, but as implied, it is not. You are implying that this applies only to binary packages. I say that failing to function when built in anything but a particular artificial environment is a serious bug in a source package. Any action whose effect is to avoid noticing these bugs cannot be a good idea. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Package which uses jam (instead make)
On 21-Oct-03, 09:58 (CDT), Josip Rodin <[EMAIL PROTECTED]> wrote: > On Mon, Oct 20, 2003 at 09:54:13PM -0500, Manoj Srivastava wrote: > > It is documented to be a Makefile. That _is_ the > > interface definition. > > Actually, we don't know that. The original documentation did not explicitely > say that all rules files absolutely need to be makefiles, but we warped it > to mean that later. Oh, please. It may not have been explicitly documented, but it was sure as hell intended to be a Makefile. The "warpage" merely documented the existing reality. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Source only uploads?
On Mon, Oct 20, 2003 at 06:55:50PM +0200, Joachim Breitner wrote: > Am So, den 19.10.2003 schrieb Andrew Suffield um 21:08: > > On Sun, Oct 19, 2003 at 05:57:55PM +0200, Sven Luther wrote: > > The proposal was "All packages should be built in an artificial > > environment of this form". I have pointed out that this is a > > braindamaged idea. > > Well, any maintainer that uses packages from experimental should not > build their packages on these mixed systems. Therefore, they use chroots > or a similar thing (unless they can afford an extra box for building). > In any case, this is an artificial environment, constructed especially > for the purpose of building packages for debian. Thus, that is no way > better or worse than debian's buildd. Sure, it happens sometimes. This is not an argument for it to happen in every case, which is what I was responding to. [Ignore Sven's small army of straw men, they aren't even remotely relevant] -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Source only uploads?
On Tue, Oct 21, 2003 at 09:11:28AM +1000, Andrew Pollock wrote: > On Mon, Oct 20, 2003 at 06:08:27PM +0200, Sven Luther wrote: > > Sure, sure. > > > > Just give me one real world reason why it is not good to build in an > > artificial environment like you call it (either pbuilder or an > > autobuilder) and i will go away, as you say. > > Yes, please do. I've been following this thread with interest, because I > have always found it inconsistent that usually $(DEBIAN_ARCHITECTURES) - 1 > were built by the buildds, but the binary package the maintainer uploads > was built in a completely heterogenous environment to the rest. > > I would have thought for the sake of consistency, it would be best if > binary packages for all $(DEBIAN_ARCHITECTURES) were built the same way. > > For the same reason, I would have thought an unstable pbuilder chroot > would provide a higher degree of consistency for the one binary package > the maintainer uploads now, than to build the package in the significantly > more random environment of the developer's development machine? (Unless > he/she dedicates a machine to tracking unstable for no other purpose than > to build packages). > > Forgive me, I am relatively new, so I may be missing the obvious... Read my earlier mails in the thread. I already covered this. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Source only uploads?
On Mon, Oct 20, 2003 at 07:46:27PM +0200, Goswin von Brederlow wrote: > Andrew Suffield <[EMAIL PROTECTED]> writes: > > > On Mon, Oct 20, 2003 at 12:13:22PM +0200, Goswin von Brederlow wrote: > > > > b) The package is uploaded from real-world environments. Sometimes it > > > > breaks; when this happens the bug is noticed and corrected, so that > > > > the package always builds the same way. > > > > > > Why would it ever be noticed? That only happens if someone manually > > > rebuilds the package and notices a difference. Something like being > > > linked against different versions of libc or even different versions > > > of libpng might go unnoticed for a long time. > > > > If you are arguing that such issues will not be noticed, then you have > > just defeated your own argument. > > > > Your argument has been founded upon the notion that packages built on > > real-world systems might be broken. You are now saying that nobody > > will notice - in which case it doesn't matter at all, and the status > > quo should remain. > > There are lots of cases where the source is broken or the used > libraries are not what they should be that don't make the programm > segfault. A user might never notice the difference. > > At the moment, unless someone manually rebuilds, a binary-all package > can be completly unbuildable unless you have the exact same > environment as the maintainer and do the same dirty hacks he did to > build. > > The case where an uploaded binary just does not run is pretty uncommon > and will get noticed by the first user updating. Thats what sid is > for. I'm not realy concerned with bugs in the binary (in this > discusson), source only uploads wont do a think to change them. Okay, you're committing the fallacy of affirmation of the consequant. Your implication is: "If we only make source uploads, then this problem won't happen" And your assertion is: "We don't want this problem to happen" From this you derive the conclusion: "We should only make source uploads" This is logically invalid. When the consequant is true, the antecedent is irrelevant. Translating this into practical terms, you're wrong because we could fix this problem in other ways. For example, we could build the arch-indep packages someplace and not bother to upload them. Hey, that's what actually happens. It just isn't automated yet. > > > > I say that (b) is vastly superior to (a). The tradeoff is temporary > > > > bugs in sid versus unnoticed bugs in a release. We'll never trap all > > > > the bugs, but going out of your way to _not look_ cannot be a good > > > > idea. > > > > > > You say that in case B bugs will be noticed, which implies people are > > > recompiling the packages in their own environments. But then bugs > > > would just as well be noticed in case A. > > > > > > So far the best suggestion for this problem I have heart was to allow > > > (require) binary uploads but to hold them back and autobuild > > > everything for all archs. Only binaries allowed into archive are > > > autobuilders and binary-only uploads (to allow fixing autobuilder lags > > > or problems). > > > > It is evident from these two paragraphs that you did not read my mail > > and understand it. I have already given reasons for why they are > > wrong, albeit not attached to the same examples. > > You reason for case B (that people will test build and find bugs) > just as well applies to case A. That makes your point void. Empirically false. In fact, you've missed the point entirely, since that *was* the point. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: squid
On Tue, Oct 21, 2003 at 11:45:15AM -0200, Faturamento wrote: > what the last squid proxy? > the squid on my firm, die every time. > have any site, specify for this? See http://www.debian.org/distrib/packages and search for squid. There is a mailing list called squid-users (see squid-cache.org). Your posting here is a little off-topic. While you are at it... would you mind setting your real name and switch off HTML at your mail client? Thanks. By the way: I'm running Squid from Woody and it runs well. :) Christoph -- ~ ~ ".signature" [Modified] 3 lines --100%--3,41 All
Re: Testing/help needed - experimental glibc version
On Tue, Oct 21, 2003 at 01:03:02PM -0400, Daniel Jacobowitz wrote: > As some of you may have seen, there's a new version of glibc in unstable. Joey has kindly pointed out that I'm out of my mind. "There's a new version of glibc in experimental." -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Bug#215827: ITP: lartc -- Linux Advanced Routing and Traffic Control HOWTO
On Tue, Oct 21, 2003 at 05:57:03PM +0200, Marc Haber wrote: > On Wed, 15 Oct 2003 13:24:25 +0200, Andreas Metzler > <[EMAIL PROTECTED]> wrote: > >Being a normal Linuxdoc howto this has been available in Debian for a > >long time in doc-linux-html. > > And calling this document a HOWTO has been a joke since at least two > years. I don't consider myself entirely dumb, but I have failed to > understand the document. For a HOWTO, there are not enough examples, > and the few examples are so complicated that nobody can grasp the > concepts. > > Greetings > Marc, unable to improve the HOWTO due to lack of understanding The howto won't be packaged and this ITP should be closed, because it's already packaged. _BUT_ your failure to understand the howto is no excuse to criticise it. A great effort has been made to document that features of linux. We have made the howto mostly reading the sourcecode and experimenting. So it won't be that difficult since we did it all once without having any documentation. If you are suggesting that it should better be named a guide, that's other thing. I would reformat your criticisms as "Is too good to be a Howto". So if you feel like making an easier document, go ahead; but you will need to understand some networking concepts explained there first. Next time, be more positive. Thanks. Regards. -- Pedro Larroy Tovar | piotr%member.fsf.org Software patents are a threat to innovation in Europe please check: http://www.eurolinux.org/
Re: Bug#88029: Package which uses jam (instead make)
On Mon, Oct 20, 2003 at 12:35:04AM +0200, Josip Rodin wrote: > On Sun, Oct 19, 2003 at 03:58:19PM -0500, Steve Greenland wrote: > > I've yet to see a technical argument for allowing debian/rules to be a > > non-makefile. > > I've yet to see a technical argument for disallowing debian/rules from being > a non-makefile. (itinerant policy-editor hat on) Me neither. -- G. Branden Robinson|Humor is a rubber sword - it allows Debian GNU/Linux |you to make a point without drawing [EMAIL PROTECTED] |blood. http://people.debian.org/~branden/ |-- Mary Hirsch signature.asc Description: Digital signature
Re: Source only uploads?
Andrew Suffield dijo [Tue, Oct 21, 2003 at 07:12:22PM +0100]: > Strictly as stated, your goal is accurate, but as implied, it is > not. You are implying that this applies only to binary packages. > > I say that failing to function when built in anything but a particular > artificial environment is a serious bug in a source package. > > Any action whose effect is to avoid noticing these bugs cannot be a > good idea. I completely agree with you. A natural environment has a much larger probability to introduce mistakes than an artificial one - if a mistake appears when building in a overly limited artificial environment, we can quite confidently conclude that the packager omitted something. Most (trivial) FTBFS bugs I have inspected arise from an omitted build-dependency. Many, as Sven Luther points out, are introduced because the natural environment (the maintainer's machine) has some packages that do not belong to our unstable branch and thus generate problematic (sometimes with problems too subtle to be easily found, that often arise after the package has descended into testing). I sent this idea because many people were debating if it would be a waste of autobuilder resources to restrict to source-only uploads or binary uploads with a discarded binary (which I think would be best). While writting down my idea, some extra thoughts twisted it beyond any recognition - but the basic idea stands. I would prefer not letting packages into testing which were not autobuilt. As a sidenote, I remember some months ago there was a thread about information regarding a particular developer's working environment being distributed with the packages they built - If everything were to be autobuilt, we would also get rid of this (minor, IMHO) problem. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Re: Source only uploads?
* John Hasler | Matt Zimmerman writes: | > This premise assumes that only developers use unstable, and in my | > experience this is very far from the truth. | | It is true that some packages go into testing without having been tested on | all platforms. Some packages probably go into stable without having been tested on all platforms. If this happens, well, then that arch is a little screwed. That's the cost of not having people running unstable for that arch. (I can imagine say, KDE being broken on m68k without anybody really noticing -- it's probably so slow on that hardware, so nobody in their right mind will run it on that hardware. :) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Source only uploads?
On Tue, Oct 21, 2003 at 03:12:17PM -0500, Gunnar Wolf wrote: > beyond any recognition - but the basic idea stands. I would prefer not > letting packages into testing which were not autobuilt. Another argument: trojaned binaries can more easyly happen on hundrets of machines with differen secuirty policies. Not that I think auto builders are safe from that, but the environemnt is more easyly controleable. Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Driver Support for Intel Motherboard
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Es Dilluns 20 Octubre 2003 20:27, en Srikanta Prasanna va escriure: > I recently installed Debian (Knoppix > 3.2) on my system (P4, 2Ghz, 845 GLAD Intel motherboard). I am not able to > find a driver for my motherboard (the audio is not detected) Try running /etc/init.d/alsa-autoconfig, maybe that works ;) - -- Joan Tur. Eivissa-Spain Jabber: [EMAIL PROTECTED] Yahoo & AIM: quini2k www.ClubIbosim.org Linux: usuari registrat 190.783 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/lZvUok8j9RhtetwRAsqYAJ43I6MmuzsTCbNb1yXRO4CUO0BbbACgkG4G eLlmGUahn/KLV18Cl4QT/kg= =uQeW -END PGP SIGNATURE-
Bug#216954: RFP: wmfrog -- WindowMaker dock app that shows your current weather
Package: wnpp Severity: wishlist * Package name: wmfrog Version : 0.1.5 Upstream Author : tcolar <[EMAIL PROTECTED]> * URL or Web page : http://www.colar.net/wmapps/ * License : GNU GPL Description : WindowMaker dock app that shows your current weather wmFrog is a weather dockapp for use in Window Maker or blakbox/fluxbox. It shows the cloud cover (sunny, partly cloudy. etc.), precipitation (snow, light rain, etc.) the temperature, the wind direction/speed, and the humidity. It works like wmweather (fetching data according to a given metar station) but the output is graphical. -- Mathieu Roy +-+ | General Homepage: http://yeupou.coleumes.org/ | | Computing Homepage: http://alberich.coleumes.org/ | | Not a native english speaker: | | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english | +-+
Re: Bug#215827: ITP: lartc -- Linux Advanced Routing and Traffic Control HOWTO
On Tue, Oct 21, 2003 at 08:54:14PM +0200, Pedro Larroy wrote: > Next time, be more positive. Thanks. He's offering constructive criticism, pointing out that there could be better examples, and instead of saying "thanks!" and using it to improve the document, you attack him. He's not the one that needs to be more positive. -- Glenn Maynard
Re: Package which uses jam (instead make)
On Tue, Oct 21, 2003 at 01:15:29PM -0500, Steve Greenland wrote: > > > It is documented to be a Makefile. That _is_ the > > > interface definition. > > > > Actually, we don't know that. The original documentation did not explicitely > > say that all rules files absolutely need to be makefiles, but we warped it > > to mean that later. > > Oh, please. It may not have been explicitly documented, but it was sure > as hell intended to be a Makefile. The "warpage" merely documented the > existing reality. I beg to differ. It points out it's a makefile and uses the "target" terminology (IIRC that's not new?). However, I don't see any notion of taking make-specific features other than the footnote on hinting, and on the other hand it avoids running make explicitely and it exclusively uses only one argument to the script. To make it a makefile is the obvious choice, the recommended choice, but there's nothing to proscribe using something else. -- 2. That which causes joy or happiness.
Re: Bug#215827: ITP: lartc -- Linux Advanced Routing and Traffic Control HOWTO
Pedro Larroy <[EMAIL PROTECTED]> wrote: [...] > The howto won't be packaged and this ITP should be closed, because it's > already packaged. [...] Could you please do the honors and close it? Thanks. cu and- not commenting on the snipped part on purpose -reas
Re: Bug#214036: im: imput doesn't work with Perl 5.8.1
On October 21, 2003 at 2:10PM +0200,
Matthias Urlichs <[EMAIL PROTECTED]> wrote:
> The general solution is not to use $! as an error indicator in perl. That
> doesn't work reliably.
I've modified the im pacakge not to use $! as an error indicator.
I intend to include the following patch in the next release of
the im package.
Thanks,
--
Tatsuya Kinoshita
--- im-145-4/IM/Imap.pm
+++ im-145/IM/Imap.pm
@@ -195,15 +195,8 @@
if ($resp =~ /^\* \d+ FETCH \((UID $num )?RFC822 \{(\d+)\}/i) {
my $size = $2;
alarm(imap_timeout()) unless win95p();
- $! = 0;
while (<$HANDLE>) {
- unless (win95p()) {
- alarm(0);
- if ($!) { # may be channel truoble
- im_warn("lost connection for FETCH(get).\n");
- return (-1, 0);
- }
- }
+ alarm(0) unless win95p();
$size -= length($_);
s/\r\n$/\n/;
im_debug($_) if (&debug('imap'));
@@ -240,15 +233,8 @@
my($size, $len) = ($2, $3);
my $field = '';
alarm(imap_timeout()) unless win95p();
- $! = 0;
while (<$HANDLE>) {
- unless (win95p()) {
- alarm(0);
- if ($!) { # may be channel truoble
- im_warn("lost connection for FETCH(head).\n");
- return (-1, 0);
- }
- }
+ alarm(0) unless win95p();
$len -= length($_);
s/\r?\n$//;
im_debug("$_\n") if (&debug('imap'));
@@ -299,15 +285,8 @@
my $found = 0;
my $f;
alarm(imap_timeout()) unless win95p();
- $! = 0;
while (<$HANDLE>) {
- unless (win95p()) {
- alarm(0);
- if ($!) { # may be channel truoble
- im_warn("lost connection for FETCH(from).\n");
- return -1;
- }
- }
+ alarm(0) unless win95p();
$size -= length($_);
s/\r\n$/\n/;
im_debug($_) if (&debug('imap'));
@@ -793,15 +772,8 @@
($uid, $size, $len) = ($2, $3, $4);
my @hdr;
alarm(imap_timeout()) unless win95p();
- $! = 0;
while (<$HANDLE>) {
- unless (win95p()) {
- alarm(0);
- if ($!) { # may be channel truoble
- im_warn("lost connection for FETCH(scan).\n");
- return -1;
- }
- }
+ alarm(0) unless win95p();
$len -= length;
s/\r?\n$/\n/;
im_warn($_) if (&debug('imap'));
--- im-145-4/IM/Nntp.pm
+++ im-145/IM/Nntp.pm
@@ -178,15 +178,8 @@
$count++;
my($found, $f) = (0, '');
alarm(nntp_timeout()) unless win95p();
-$! = 0;
while () {
- unless (win95p()) {
- alarm(0);
- if ($!) { # may be channel truoble
- im_warn("lost connection for HEAD.\n");
- return -1;
- }
- }
+ alarm(0) unless win95p();
s/\r\n$/\n/;
last if ($_ =~ /^\.\n$/);
s/^\.//;
@@ -214,15 +207,8 @@
$count++;
my($found, $f) = (0, '');
alarm(nntp_timeout()) unless win95p();
- $! = 0;
while () {
- unless (win95p()) {
- alarm(0);
- if ($!) { # may be channel truoble
- im_warn("lost connection for HEAD.\n");
- return -1;
- }
- }
+ alarm(0) unless win95p();
s/\r\n$/\n/;
last if ($_ =~ /^\.\n$/);
s/^\.//;
@@ -285,15 +271,8 @@
}
my @Article = ();
alarm(nntp_timeout()) unless win95p();
-$! = 0;
while () {
- unless (win95p()) {
- alarm(0);
- if ($!) { # may be channel truoble
- im_warn("lost connection for ARTICLE.\n");
- return(-1, '');
- }
- }
+ alarm(0) unless win95p();
s/\r\n$/\n/;
last if ($_ =~ /^\.\n$/);
s/^\.//;
--- im-145-4/IM/Pop.pm
+++ im-145/IM/Pop.pm
@@ -148,15 +148,8 @@
return -1;
}
alarm(pop_timeout()) unless win95p();
-$! = 0;
while () {
- unless (win95p()) {
- alarm(0);
- if ($!) { # may be channel truoble
- im_warn("lost connection for RETR.\n");
- return -1;
- }
- }
+ alarm(0) unless win95p();
s/\r\n$/\n/;
last if ($_ =~ /^\.\n$/);
s/^\.//;
@@ -184,15 +177,8 @@
my(%head);
undef %head;
alarm(pop_timeout()) unless win95p();
-$! = 0;
while () {
- unless (win95p()) {
- alarm(0);
- if ($!) { # may be channel truoble
- im_warn("lost connection for HEAD.\n");
- return 0;
- }
- }
+ alarm(0) unless win95p();
s/\r?\n$//;
last if ($_ =~ /^\.$/);
