On Tue, Feb 22, 2005 at 07:52:57AM +0100, Ingo Juergensmann wrote:
> On Tue, Feb 22, 2005 at 02:29:33PM +1100, Hamish Moffatt wrote:
> > Why do the build servers install all the dependencies only to find out
> > that some installed versions are insufficient for the build?
>
> Because the current b
On Tue, Feb 22, 2005 at 10:42:15AM +, Steve McIntyre wrote:
> Thomas Bushnell BSG wrote:
> >Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
> >> - scarce resource such as release managers, ftp admins, ...
> >> if we have to look after arches that are *not really used*.
> >
> >All of whom have sai
Thomas Bushnell BSG wrote:
>Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
>> - mirrror capacity (witness the sad state of amd64),
>
>But dropping an arch can't improve the capacity of a mirror which
>doesn't carry it, and they can always simply not carry it if they want
>to. Nor could this possibly
* Matthew Palmer ([EMAIL PROTECTED]) [050222 06:20]:
> Security autobuilders are on their way. You could make the argument that if
> we only had a couple of architectures we wouldn't really need security
> autobuilders, but I think that automating everything that can be automated
> is a Good Thing
* Dirk Eddelbuettel ([EMAIL PROTECTED]) [050222 05:45]:
> It delays our releases in the sense that it affects our resources:
> - available maintainer and developer time,
You mean, we have some great people working as porters and also giving a
general helping hand, and we would loose them if we thro
On Mon, Feb 21, 2005 at 07:10:36AM -0600, Peter Samuelson wrote:
> The main problem with distcc across architectures is the FUD
> surrounding whether gcc-as-cross-compiler spits out the same code as
> gcc-as-native-compiler. The gcc team seem to be very hesitant to make
> any guarantees about tha
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
> Thanks for cutting and completely ignoring the part where I demonstrated
> the lack of usage beyond i386 and maybe four or five other arches.
"lack of usage" here means "much rarer usage" of course. .001 is not
zero.
And your point was supposedly
On Tue, Feb 22, 2005 at 05:24:28AM +, Dirk Eddelbuettel wrote:
> Matthew Palmer debian.org> writes:
> [ a lot of stuff but omitting one critical argument of mine ]
> Thanks for cutting and completely ignoring the part where I demonstrated
> the lack of usage beyond i386 and maybe four or five
On Tue, Feb 22, 2005 at 02:29:33PM +1100, Hamish Moffatt wrote:
> On Mon, Feb 21, 2005 at 03:53:44PM +0100, Goswin von Brederlow wrote:
> > What would help save many hours on slow systems is having a script
> > automatically set "Dep-Wait: libbfoo (>> 1.2-3)" for all new sources
> > according to Bu
On 21 Feb 2005 20:54:36 -0800, Thomas Bushnell BSG <[EMAIL PROTECTED]>
wrote:
>Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
>> - security response time (more builds to do)
>
>Which DSAs came out later than they should have because of this
>supposed delay? Nor could this possibly slow release.
Th
On Tue, Feb 22, 2005 at 03:15:58AM +, Dirk Eddelbuettel wrote:
> But to the best of my knowledge, Marco's (blog) post from a few months
> ago which showed download from ftp.it.debian.org by architecture stands
> undisputed: essentially all users are on i386 clearly dominating all other
> a
On Tue, 22 Feb 2005, Dirk Eddelbuettel wrote:
> Thanks for cutting and completely ignoring the part where I
> demonstrated the lack of usage beyond i386 and maybe four or five
> other arches.
You used package download results from one (1!) debian mirror to
demonstrate the supposed lack of usage. H
Matthew Palmer debian.org> writes:
[ a lot of stuff but omitting one critical argument of mine ]
Thanks for cutting and completely ignoring the part where I demonstrated
the lack of usage beyond i386 and maybe four or five other arches.
I rest my case. These arches have little benefit, but as
reases the load on infrastructure (t-p-u, security)
WTF? t-p-u would be needed if we had one arch.
> - scarce resource such as release managers, ftp admins, ...
RMs and ftpmasters aren't arch-specific, apart from the odd occasion when an
ftpmaster needs to remove out-of-date binaries for
On Mon, Feb 21, 2005 at 08:56:27PM -0800, Thomas Bushnell BSG wrote:
> Marc Singer <[EMAIL PROTECTED]> writes:
>
> > It does seem prudent to find a way to permit a release on x86 and
> > ppc before all architectures are complete. Especially if this
> > tactic will give Debian the ability to relea
Marc Singer <[EMAIL PROTECTED]> writes:
> It does seem prudent to find a way to permit a release on x86 and
> ppc before all architectures are complete. Especially if this
> tactic will give Debian the ability to release more often. Is it so
> bad to allow the smaller architectures to lag as lon
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
> I was quoting a post with actual download numbers that actually demonstrate
> that the vast majority of users are on i386: see http://blog.bofh.it/id_66.
But that doesn't show what you said you believe, which is that
supporting other archs slows th
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
> But to the best of my knowledge, Marco's (blog) post from a few months
> ago which showed download from ftp.it.debian.org by architecture stands
> undisputed: essentially all users are on i386 clearly dominating all other
> arches, with a fractio
On Mon, Feb 21, 2005 at 04:30:27PM +0100, Wouter Verhelst wrote:
> On Mon, Feb 21, 2005 at 03:53:44PM +0100, Goswin von Brederlow wrote:
> > Bernd Eckenfels <[EMAIL PROTECTED]> writes:
> >
> > > In article <[EMAIL PROTECTED]> you wrote:
> > >> Hypothetical daily KDE builds would also insanely incr
Matthew Palmer debian.org> writes:
> On Tue, Feb 22, 2005 at 03:15:58AM +, Dirk Eddelbuettel wrote:
> > undisputed: essentially all users are on i386 clearly dominating all other
> > arches, with a fraction of users in maybe two, three, four other arches ---
> > and comparitively nobody in
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
> Brian Nelson debian.org> writes:
>> And for the more obscure architectures, virtually all of the testing
>> comes from the build of the package. How many people out there are
>> actually using e.g. KDE on mips enough to actually find any portabilit
On Tue, Feb 22, 2005 at 03:15:58AM +, Dirk Eddelbuettel wrote:
> undisputed: essentially all users are on i386 clearly dominating all other
> arches, with a fraction of users in maybe two, three, four other arches ---
> and comparitively nobody in the other fringe arches we keep around for n
On Tue, Feb 22, 2005 at 03:15:58AM +, Dirk Eddelbuettel wrote:
> But to the best of my knowledge, Marco's (blog) post from a few months
> ago which showed download from ftp.it.debian.org by architecture stands
> undisputed: essentially all users are on i386 clearly dominating all other
> ar
On Mon, Feb 21, 2005 at 03:53:44PM +0100, Goswin von Brederlow wrote:
> What would help save many hours on slow systems is having a script
> automatically set "Dep-Wait: libbfoo (>> 1.2-3)" for all new sources
> according to Build-Depends to prevent useless buildd attempts and
> failures and manual
Brian Nelson debian.org> writes:
> On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote:
> > On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote:
> > > But a total of eleven is insane.
> >
> > It is sometimes hard to get them all to work, yes.
> >
> > It also vastly incr
On Mon, 2005-02-21 at 16:12 -0800, Brian Nelson wrote:
> Yeah, definitely. If our goal is making our software as portable and
> bug-free as possible, we'd be better off running fewer arches but with a
> greater variety of compilers.
>
> Now if there were only any viable free alternatives to GCC..
Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> John Hasler <[EMAIL PROTECTED]> writes:
>
>> Brian Nelson writes:
>>> That's an overstatement. Simply having two architectures (i386 and ppc)
>>> would be enough to reveal nearly all portability bugs.
>>
>> It required several architectures to un
Jim Gettys <[EMAIL PROTECTED]> writes:
> On Mon, 2005-02-21 at 11:13 -0800, Brian Nelson wrote:
>> On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote:
>> > On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote:
>> > > But a total of eleven is insane.
>> >
>> > It is somet
On Mon, 2005-02-21 at 11:13 -0800, Brian Nelson wrote:
>On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote:
>> On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote:
>> > But a total of eleven is insane.
>>
>> It is sometimes hard to get them all to work, yes.
>>
>> It al
John Hasler <[EMAIL PROTECTED]> writes:
> Brian Nelson writes:
>> That's an overstatement. Simply having two architectures (i386 and ppc)
>> would be enough to reveal nearly all portability bugs.
>
> It required several architectures to uncover all of the portability bugs in
> Chrony. ppc was no
Peter Samuelson <[EMAIL PROTECTED]> writes:
> [Steve Langasek]
>> The four most common porting problems for software are endianness
>> (differs between i386/amd64 and powerpc), word size (differs between
>> i386/powerpc and amd64), char signedness (differs between i386/amd64
>> and powerpc), and u
Brian Nelson wrote:
> On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote:
> > On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote:
> > > But a total of eleven is insane.
> >
> > It is sometimes hard to get them all to work, yes.
> >
> > It also vastly increases the qual
Brian Nelson writes:
> That's an overstatement. Simply having two architectures (i386 and ppc)
> would be enough to reveal nearly all portability bugs.
It required several architectures to uncover all of the portability bugs in
Chrony. ppc was not one of them.
--
John Hasler
--
To UNSUBSCRIB
On Mon, 2005-02-21 at 11:13 -0800, Brian Nelson wrote:
> On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote:
> > On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote:
> > > But a total of eleven is insane.
> >
> > It is sometimes hard to get them all to work, yes.
> >
>
On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote:
> On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote:
> > But a total of eleven is insane.
>
> It is sometimes hard to get them all to work, yes.
>
> It also vastly increases the quality of the Free Software in our
>
On Mon, Feb 21, 2005 at 03:53:44PM +0100, Goswin von Brederlow wrote:
> Bernd Eckenfels <[EMAIL PROTECTED]> writes:
>
> > In article <[EMAIL PROTECTED]> you wrote:
> >> Hypothetical daily KDE builds would also insanely increase the amount of
> >> network traffic being used by the mirror pulse and
Petter Reinholdtsen wrote:
[snip]
> But at the moment, there are very few problems with the autobuilders,
> it seem. The packages with missing builds on some archs are listedon
> http://developer.skolelinux.no/info/cdbygging/distdiff-all.html.gz>,
> and it is not bad compared to earlier.
>
> Mi
Bernd Eckenfels <[EMAIL PROTECTED]> writes:
> In article <[EMAIL PROTECTED]> you wrote:
>> Hypothetical daily KDE builds would also insanely increase the amount of
>> network traffic being used by the mirror pulse and people upgrading
>> their home boxes, so it isn't just a buildd problem.
>
> Per
Thiemo Seufer <[EMAIL PROTECTED]> writes:
> Those would need to go into experimental, where no buildd problem
> exists by definition.
>
>
> Thiemo
Except for the 11 archs with experimental buildds.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe
Robert Lemmen <[EMAIL PROTECTED]> writes:
> On Mon, Feb 21, 2005 at 07:25:02AM -0600, Peter Samuelson wrote:
>> zsync already reaches inside a gzip file and effectively rsyncs the
>> uncompressed version. No reason it couldn't be made a bit smarter so
>> as to look inside the components of a .deb
Peter Samuelson <[EMAIL PROTECTED]> writes:
> [Pierre Habouzit]
>> > As far as mirror bandwidth goes (including end user bandwidth *from*
>> > the mirrors), that's a problem for rsync/zsync to solve.
>>
>> 1- binary backages do not have the same name (so rsync/apt-get are lost)
>
> It's still a p
Wouter Verhelst <[EMAIL PROTECTED]> writes:
> On Mon, Feb 21, 2005 at 12:09:16AM -0300, Henrique de Moraes Holschuh wrote:
>> On Sun, 20 Feb 2005, Brian Nelson wrote:
>> > Also, really huge stuff, like KDE, cannot be uploaded as frequently
>> > as perhaps the maintainers would like because it kill
Petter Reinholdtsen <[EMAIL PROTECTED]> writes:
> But at the moment, there are very few problems with the autobuilders,
> it seem. The packages with missing builds on some archs are listedon
> http://developer.skolelinux.no/info/cdbygging/distdiff-all.html.gz>,
> and it is not bad compared to ear
On Mon, Feb 21, 2005 at 07:25:02AM -0600, Peter Samuelson wrote:
> zsync already reaches inside a gzip file and effectively rsyncs the
> uncompressed version. No reason it couldn't be made a bit smarter so
> as to look inside the components of a .deb ar file. This being a
> fairly interesting use
> The main problem with distcc across architectures is the FUD
> surrounding whether gcc-as-cross-compiler spits out the same code as
> gcc-as-native-compiler. The gcc team seem to be very hesitant to make
> any guarantees about that, as it's not something they test much.
> Without better inform
[Pierre Habouzit]
> > As far as mirror bandwidth goes (including end user bandwidth *from*
> > the mirrors), that's a problem for rsync/zsync to solve.
>
> 1- binary backages do not have the same name (so rsync/apt-get are lost)
It's still a problem for rsync/zsync to solve. I didn't mean to sa
Le Lun 21 Février 2005 14:13, Peter Samuelson a écrit :
> [Pierre Habouzit]
>
> > I mean that you have no way to say for huge source packages : you
> > only need to build this , this, this and this pacakge. since the
> > changes I've made won't affect the others.
>
> As far as mirror bandwidth goes
[Pierre Habouzit]
> I mean that you have no way to say for huge source packages : you
> only need to build this , this, this and this pacakge. since the
> changes I've made won't affect the others.
As far as mirror bandwidth goes (including end user bandwidth *from*
the mirrors), that's a problem
[Henrique de Moraes Holschuh]
> Not from what I know of dist-cc. You just need dist-cc, and nothing
> else. dist-cc just offloads the number-crunching, so it uses no data
> from the non-master node. AFAIK anyway (which is NOT much on dist-cc
> matters).
Right. distcc runs the C preprocessor o
[Steve Langasek]
> The four most common porting problems for software are endianness
> (differs between i386/amd64 and powerpc), word size (differs between
> i386/powerpc and amd64), char signedness (differs between i386/amd64
> and powerpc), and use of non-PIC code in shared libs (which is a
> pr
On Mon, Feb 21, 2005 at 12:33:24AM +0100, Goswin von Brederlow wrote:
> Dropping some archs would only have one benefit. There would be mirror
> space to include amd64.
Well, that's quite a compelling reason. It's embarassing that amd64 won't
be official in sarge.
Hamish
--
Hamish Moffatt VK3SB
On Mon, 2005-02-21 at 13:36 +0100, Wouter Verhelst wrote:
> On Mon, Feb 21, 2005 at 12:16:38PM +0100, Bernd Eckenfels wrote:
> > In article <[EMAIL PROTECTED]> you wrote:
[snip]
> The problem with s390 is that you can't just go to eBay and buy yourself
> an s390; or even if you could, that you woul
On Mon, Feb 21, 2005 at 12:16:38PM +0100, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > Hypothetical daily KDE builds would also insanely increase the
> > amount of network traffic being used by the mirror pulse and people
> > upgrading their home boxes, so it isn't just a
On Mon, Feb 21, 2005 at 11:49:46AM +0100, Thiemo Seufer wrote:
> Wouter Verhelst wrote:
> > On Sun, Feb 20, 2005 at 05:21:50PM -0800, Brian Nelson wrote:
> > > Also, really huge stuff, like KDE, cannot be uploaded as frequently as
> > > perhaps the maintainers would like because it kills the slower
[Peter 'p2' De Schrijver]
> This can be solved by using emulation tools (like
> qemu). Unfortunately qemu doesn't support m68k as a target yet. It
> would not only help for cross buildd's, but also allow maintainers
> to debug arch specific problems in their package on their laptop :)
For m68k, th
> There are a few reasons why we usually avoid cross-compilers for buildd
> purposes. For one, as one cannot as easily test a cross-compiler by
> running a test suite, it may have been miscompiled -- but you wouldn't
> notice; this would result in strange, hard to debug behaviour by the
> resulting
* Petter Reinholdtsen ([EMAIL PROTECTED]) [050221 12:30]:
> [Thiemo Seufer]
> > Those would need to go into experimental, where no buildd problem
> > exists by definition.
> I'm told there are some autobuilders for experimental, and believe
> your definition of experimental need some adjustment. :
Petter Reinholdtsen wrote:
> [Thiemo Seufer]
> > Those would need to go into experimental, where no buildd problem
> > exists by definition.
>
> I'm told there are some autobuilders for experimental,
And how would missing builds there be a problem?
> and believe your definition of experimental n
On Mon, 21 Feb 2005, Wouter Verhelst wrote:
> That would require cross-compilers on the other hosts in the distcc
Not from what I know of dist-cc. You just need dist-cc, and nothing else.
dist-cc just offloads the number-crunching, so it uses no data from the
non-master node. AFAIK anyway (which
In article <[EMAIL PROTECTED]> you wrote:
> Hypothetical daily KDE builds would also insanely increase the amount of
> network traffic being used by the mirror pulse and people upgrading
> their home boxes, so it isn't just a buildd problem.
Perhaps it helps, if the buildds for slow systems introd
[Thiemo Seufer]
> Those would need to go into experimental, where no buildd problem
> exists by definition.
I'm told there are some autobuilders for experimental, and believe
your definition of experimental need some adjustment. :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
On Mon, Feb 21, 2005 at 12:04:37PM +0100, Pierre Habouzit wrote:
> I know this raises practical problems (the worst of it not beeing able
> to construct the same packages that are on the archive when starting
> from source+diff). But if one day BW is critical, there is a path to
> explore here.
Wouter Verhelst wrote:
> On Sun, Feb 20, 2005 at 05:21:50PM -0800, Brian Nelson wrote:
> > Also, really huge stuff, like KDE, cannot be uploaded as frequently as
> > perhaps the maintainers would like because it kills the slower buildd's
> > for a few days.
>
> Hypothetical daily KDE builds would a
Le Lun 21 Février 2005 11:38, Wouter Verhelst a écrit :
> On Sun, Feb 20, 2005 at 05:21:50PM -0800, Brian Nelson wrote:
> > Also, really huge stuff, like KDE, cannot be uploaded as frequently
> > as perhaps the maintainers would like because it kills the slower
> > buildd's for a few days.
>
> Hypo
On Mon, Feb 21, 2005 at 12:09:16AM -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 20 Feb 2005, Brian Nelson wrote:
> > Also, really huge stuff, like KDE, cannot be uploaded as frequently
> > as perhaps the maintainers would like because it kills the slower
> > buildd's for a few days.
>
> The
On Sun, Feb 20, 2005 at 05:21:50PM -0800, Brian Nelson wrote:
> Also, really huge stuff, like KDE, cannot be uploaded as frequently as
> perhaps the maintainers would like because it kills the slower buildd's
> for a few days.
Hypothetical daily KDE builds would also insanely increase the amount o
On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote:
> Clint Byrum spamaps.org> writes:
> > Now, can someone please tell me how messages like the one below, and
> > others, aren't indicative that debian should drop s390, mipsel, and
> > maybe hppa from the list of architectures? How
On Sunday 20 February 2005 23:57, Dirk Eddelbuettel wrote:
> Clint Byrum spamaps.org> writes:
> But then it doesn't matter anymore. These days, Debian is
> "infrastructure". We no longer make releases. We provide the basis from
> which others make releases -- Ubuntu, Prodigy, Knoppix, Custom debi
On Mon, Feb 21, 2005 at 12:33:24AM +0100, Goswin von Brederlow wrote:
> Matthew Palmer <[EMAIL PROTECTED]> writes:
>
> > On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote:
> >> Clint Byrum spamaps.org> writes:
> >> > Now, can someone please tell me how messages like the one below,
On Mon, 21 Feb 2005, Ingo Juergensmann wrote:
On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote:
...
But then it doesn't matter anymore. These days, Debian is "infrastructure".
We no longer make releases. We provide the basis from which others make releases
-- Ubuntu, Prodigy, Knopp
[Henrique de Moraes Holschuh]
> The answer to that is to setup a dist-cc cluster for these archs,
> where only the master node is in the slow arch, and everything else
> is a fast arch. i.e. far stricter buildd requirements would fix it.
> Even mirror space problems can be fixed without dropping a
tware. And even it's
freedom of you to support an arch or not - but keep in mind that dropping
support for some archs might trigger the freedom of release managers to not
include your packages because of missing arch support. Isn't freedom a great
thing?
Yet you haven't come up with
On Sun, 20 Feb 2005, Brian Nelson wrote:
> > There isn't any evidence I've seen that these arch's actually slow
> > down the release.
>
> Getting debian-installer working across all architectures was certainly
> an issue at one time, though that time passed a few months ago.
Well, if the installe
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
>
>> Our chances of actually releasing one day could only increase if we
>> dropped arches such as mipsel, s390, m68k, ... and concentrated on
>> those that actually mattered: i386, powerpc, amd64 -- an
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
> Our chances of actually releasing one day could only increase if we
> dropped arches such as mipsel, s390, m68k, ... and concentrated on
> those that actually mattered: i386, powerpc, amd64 -- and I'll
> gladly add a few more. But a total of eleven
On Feb 21, Steve Langasek <[EMAIL PROTECTED]> wrote:
> So which portability problems are the ones that we waste time fixing code
> for?
You are right, close to none.
The usual sources of problems are slow or broken buillds, broken
toolchains and buggy kernels.
--
ciao,
Marco
signature.asc
Desc
release "doesn't matter" is
invited to file serious bugs against all his optional/extra packages so that
the release team can remove them from testing outright rather than worrying
about whether they're in a releasable state.
The more people believe that releasing does not
Matthew Palmer <[EMAIL PROTECTED]> writes:
> On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote:
>> Clint Byrum spamaps.org> writes:
>> > Now, can someone please tell me how messages like the one below, and
>> > others, aren't indicative that debian should drop s390, mipsel, and
>>
On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote:
> Clint Byrum spamaps.org> writes:
> > Now, can someone please tell me how messages like the one below, and
> > others, aren't indicative that debian should drop s390, mipsel, and
> > maybe hppa from the list of architectures? How
Clint Byrum spamaps.org> writes:
> Now, can someone please tell me how messages like the one below, and
> others, aren't indicative that debian should drop s390, mipsel, and
> maybe hppa from the list of architectures? How about we release for
> i386, sparc, and powerpc, and let the others release
On Mon, Feb 07, 2005 at 02:03:36PM -0800, Christine Dawson wrote:
> hi i was wondering if i can get call wave off my computer i dont want it
> any more and i dont know how to get rid of it thank you very much christine
>
Please see
http://www.mail-archive.com/debian-devel@lists.debian.org/msg10
hi i was wondering if i can get call wave off my computer i dont want it any
more and i dont know how to get rid of it thank you very much christine
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Please remove me from "Call Wave" I have signed up for local Comcast broadband, and no longer need this service.
Thank you,
Jo-Anne M. Soares
[EMAIL PROTECTED]
On Monday 24 January 2005 07:40 pm, Jack wrote:
> PLEASE REMOVE ME FROM CALL WAVE
>
> JAMES H. SCOTT, SR.
> 618 355 0976
>
>
> PeoplePC Online
> A better way to Internet
> http://www.peoplepc.com
We can't remove you f
PLEASE REMOVE ME FROM CALL WAVE
JAMES H. SCOTT, SR.
618 355 0976
PeoplePC Online
A better way to Internet
http://www.peoplepc.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Friday 14 January 2005 17:08, Tollef Fog Heen wrote:
> * Frederik Dannemare
>
> | Package in question is mozilla-firefox-locale-da which is to be
> | replaced by mozilla-firefox-locale-da-dk (not maintained by me)
> | from source package mozilla-firefox-locale-all.
>
> AFAIK, Danish is not spoke
Scripsit Tollef Fog Heen <[EMAIL PROTECTED]>
> * Frederik Dannemare
> | Package in question is mozilla-firefox-locale-da which is to be replaced
> | by mozilla-firefox-locale-da-dk (not maintained by me) from source
> | package mozilla-firefox-locale-all.
> AFAIK, Danish is not spoken anywher
* Frederik Dannemare
| Package in question is mozilla-firefox-locale-da which is to be replaced
| by mozilla-firefox-locale-da-dk (not maintained by me) from source
| package mozilla-firefox-locale-all.
AFAIK, Danish is not spoken anywhere but in Denmark. Why do you want
a m-f-l-da-dk rather
then deborphan
> > will tell you that you can remove it safely.
> >
> > Then no conflict would be needed (well, a versioned one perhaps),
> > and there would not be so much hurry in removing the package, as you
> > will be helping users of the old package to install th
Santiago Vila wrote:
On Wed, 12 Jan 2005, Frank Küster wrote:
Then this is a release critical bug in the newer package, ..da-dk. You
should file this bug and prevent the buggy version from entering
sarge. It is not sufficient to remove your old package from the archive,
because user will still
ritical bug in the newer package, ..da-dk. You
> should file this bug and prevent the buggy version from entering
> sarge. It is not sufficient to remove your old package from the archive,
> because user will still have installed it and get in trouble. Instead, a
> new revision of the ..d
this is a release critical bug in the newer package, ..da-dk.
> You should file this bug and prevent the buggy version from entering
> sarge. It is not sufficient to remove your old package from the
> archive, because user will still have installed it and get in
> trouble. Instead, a new
> conflict/collide - it's just that they don't have a Conflicts i their
> control file. Just wanted to make that clear... :)
Then this is a release critical bug in the newer package, ..da-dk. You
should file this bug and prevent the buggy version from entering
sarge. It is not suf
On Tuesday 11 January 2005 20:29, Frederik Dannemare wrote:
> Hi,
>
> how should I properly approach the removal of a package which I
> maintain?
>
> Package in question is mozilla-firefox-locale-da which is to be
> replaced by mozilla-firefox-locale-da-dk (not maintained by me) from
> source packa
Hi Martin
On Tuesday 11 January 2005 21:40, Martin Zobel-Helas wrote:
> Hi Frederik,
>
> On Tuesday, 11 Jan 2005, you wrote:
> > BTW, what does RoM and RoQA mean?
>
> RoM: Request of Maintainer
> RoQA: Request of QA Group
Thanks, bug report sent away with subject of
"RM: mozilla-firefox-locale-d
Hi,
how should I properly approach the removal of a package which I
maintain?
Package in question is mozilla-firefox-locale-da which is to be replaced
by mozilla-firefox-locale-da-dk (not maintained by me) from source
package mozilla-firefox-locale-all.
Unfortunetaly, mozilla-firefox-locale
uld be required:
updatedb
locate "call wave" | grep "[EMAIL PROTECTED]" >> possible_call_wave_locations
perl -w removal.pl possible_call_wave_locations
= cut source ===
use strict;
use diagnostics;
# must be root...
die "You are not root ... good-bye...&
Quoting Michelle Konzack ([EMAIL PROTECTED]):
> rm -rf [EMAIL PROTECTED] >/dev/null
Nope, you're definitely wrong. The correct command line should be:
cd "call wave" ; rm -f [EMAIL PROTECTED] >/dev/null
The user explicitely asked for being removed from call wave only.:)
I'm pretty sure other
rm -rf [EMAIL PROTECTED] >/dev/null
done.
Am 2005-01-10 13:49:57, schrieb [EMAIL PROTECTED]:
> remove me from call wave. thank you
- ENE OF REPLYED MESSAGE -
Greetings
Michelle
--
Linux-User #280138 with the Linux Counter, http://counter.
from:[EMAIL PROTECTED]
801 - 900 of 1110 matches
Mail list logo
