Ladislav Bodnar wrote:
> On Tuesday 26 October 2004 22:15, Norbert Tretkowski wrote:
> > > Just curious: any particular reason why the kernel version is
> > > reported as "100" on
> > > http://packages.debian.org/unstable/allpackages?
> > >
> > > kernel-image-2.6-386 (100)
> > > Linux kernel im
Darren Salt wrote:
> I demand that Ron Johnson may or may not have written...
>
> [snip]
> > But really, does the kernel use MMX?
>
> Here, at least: linux/arch/i386/lib/memcpy.c
Which will only be used for CyrixIII and K7, and boils down to:
config MCYRIXIII
bool "CyrixIII/VIA-C3"
Goswin von Brederlow wrote:
[snip]
> >> With cumulative patches you run into the problem that you need a new
> >> cummulative patch for every day that contains most of what the
> >> previous one did. That realy quickly becomes a space issue.
> >
> > Errm, no, it doesn't need _one_ new cumulative pa
William Ballard wrote:
> On Thu, Dec 02, 2004 at 01:25:36AM +, Andrew M.A. Cater wrote:
> > The Christian Bible ought to be OK by most Islamic scholars - it's the
> > Crusader history that has caused most of the problems - but you
>
> After 9/11 I saw a fellow named Tariq Ramadan on C-Span, an
Goswin von Brederlow wrote:
[snip]
> >> very hard (figure out how to make a minimal diff
> >> from the daylies) or you need every days Packages file (apt-dupdate
> >> does that).
> >
> > It is not "very hard" to re-diff a few files to incorporate the changes
> > between old and new Packages file.
>
Florian Weimer wrote:
> * Andreas Barth:
>
> >> Is this really a good idea? patch invokes ed(1) to process ed
> >> scripts, and this might lead to execution of arbitrary commands.
> >
> > It is agreed that the usage of patch and ed is _not_ the recommended
> > way for production code (but accepta
Frederik Dannemare wrote:
[snip]
> I surely hope they would still do so. Another option could simply be to
> proceed with the current way of uploading - but then let the buildd
> rebuild the uploaded binary. Or is that somehow not feasible?
Actually, requiring a binary upload _plus_ rebuilding i
Frederik Dannemare wrote:
[snip]
> > Always build packages for uploads in a clean environment (a fresh
> > chroot if nothing else is available).
>
> I absolutely agree. But it still doesn't have to be 100% problem-free
> (letting buildd build all packages on all archs for distribution would
> st
Steinar H. Gunderson wrote:
> On Sun, Feb 06, 2005 at 08:52:28AM -0500, Joey Hess wrote:
> > My feeling for some time has been that we should introduce a separate
> > section in the archive, or a separate archive and come up with the
> > infrastructure to upload -dbg packages to there, with separat
Thomas Bushnell BSG wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
>
> > Clearly not, or it wouldn't have failed to build on mips and mipsel. There
> > is nothing "perfectly working" about that version of libtool, and moreover,
> > its effects are not limited to the mips architectures -- as
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
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 yo
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
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
Paul Hampson wrote:
> On Tue, Feb 22, 2005 at 12:44:27PM +0100, Wouter Verhelst wrote:
> > On Tue, Feb 22, 2005 at 08:48:48PM +1300, Nick Phillips wrote:
> > > Running such a system in parallel with the current systems (and comparing
> > > the outputs) might be a good test for gcc-as-cross-compiler
Petri Latvala wrote:
[snip]
> Also, the first 16 bytes will differ in an ELF format .o, see
> http://lists.debian.org/debian-devel/2004/09/msg00201.html
That's incorrect, strictly speaking. The first (magic) bytes have
to be identical, only the padding bytes could be different (but are
usually zer
Joel Aelwyn wrote:
[snip]
> But that's OK. Our amd64 users just use the Alioth site instead of our
> wonderful mirror network, and track it as unstable. I mean, it's so much
> more effective to have it all hitting alioth for download, right? Thought
> so.
You probably should inform yourself before
Kalle Kivimaa wrote:
> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> > Source code is source code. Obfuscated or not does not change that. It
> > fullfills at least the letter of DFSG#2. For it to violate DFSG#2 you
> > would have to show that it is not source and the gcc already prooves
> > y
Steve Halasz wrote:
> Hi,
>
> I've sent a few emails over the last month to [EMAIL PROTECTED] and
> [EMAIL PROTECTED] requesting that grass be removed from
> packages-arch-specific. But my pleas have fallen on deaf ears, or
> perhaps overzealous spam filters. Are you guys out there? Is there
> any
Jeroen van Wolffelaar wrote:
[snip]
> > > I had try to randomly submit wishlist bugs for 6 packages to bts with
> > > the tag "patch" pointing to the dehs site or attaching the watch file to
> > > the bug.
> > > Almost all of this bug was closed and the watch file was check (in some
> > > cases fix
Christoph Berg wrote:
> Re: Thiemo Seufer in <[EMAIL PROTECTED]>
> > > Do *not* file 6229 bugs about the same subject. Never.
> >
> > Why not? As wishlist bugs with patch this seems sensible to me.
>
> I assume that you will hand-check the patches in those 622
Lars Wirzenius wrote:
> su, 2005-03-06 kello 19:28 +0100, Thiemo Seufer kirjoitti:
> > Jeroen van Wolffelaar wrote:
> > > Do *not* file 6229 bugs about the same subject. Never.
> >
> > Why not? As wishlist bugs with patch this seems sensible to me.
>
>
Lars Wirzenius wrote:
> su, 2005-03-06 kello 20:11 +0100, Thiemo Seufer kirjoitti:
> > Since preparation of the accompanying patches would take some time,
> > it is unlikely to cause "denial of service" or "disruption".
>
> If they are sent at a slow
Pjotr Kourzanov wrote:
> Dear Debian developers,
>
> I gather there are some people out there with MIPS little-endian
> machines (from mipsel drop discussion) and Debian on it. Do huge shared
> libraries (containing >4 symbols) work for you? I am currently
> investigating an issue I have
Wouter Verhelst wrote:
> Op za, 05-03-2005 te 14:26 +0100, schreef Thiemo Seufer:
> > Steve Halasz wrote:
> > > Hi,
> > >
> > > I've sent a few emails over the last month to [EMAIL PROTECTED] and
> > > [EMAIL PROTECTED] requesting that grass be
Kevin B. McCarty wrote:
> Josselin Mouette wrote:
>
> > Le mercredi 09 mars 2005 à 11:23 -0800, Blunt Jackson a écrit :
> >> I appreciate the clarification. What is desirable, then, is for the
> >> developer
> >> to be able to statically link his or her own libraries, and third
> >> party librari
Hamish Moffatt wrote:
> On Mon, Mar 14, 2005 at 10:10:32AM +0100, Ingo Juergensmann wrote:
> > All the work and support over all those years by all those users and porters
> > will be vanished with that stupid idea, imho.
>
> Ingo, obviously you are pissed off. But really, is there much benefit i
Martin Michlmayr wrote:
[snip]
> - a _clear_ plan about this migration (and have this plan before
> sarge is out), including a clear timeplan (announcement on day X,
> maintainers have Y months to upload, if they don't do it in Y
> months, we'll have a time of Z people who'll NMU the
Hamish Moffatt wrote:
> On Mon, Mar 14, 2005 at 12:06:18PM +, Martin Michlmayr wrote:
> > * Hamish Moffatt <[EMAIL PROTECTED]> [2005-03-14 23:00]:
> > > But really, is there much benefit in making *releases* for the SCC
> > > architectures?
> >
> > For some SSC arches, it *might* not make a di
Thiemo Seufer wrote:
> Hamish Moffatt wrote:
> > On Mon, Mar 14, 2005 at 12:06:18PM +, Martin Michlmayr wrote:
> > > * Hamish Moffatt <[EMAIL PROTECTED]> [2005-03-14 23:00]:
> > > > But really, is there much benefit in making *releases* for the SCC
> >
Hamish Moffatt wrote:
> On Mon, Mar 14, 2005 at 01:33:16PM +0100, Thiemo Seufer wrote:
> > Hamish Moffatt wrote:
> > > On Mon, Mar 14, 2005 at 10:10:32AM +0100, Ingo Juergensmann wrote:
> > > > All the work and support over all those years by all those users and
&
Steve Langasek wrote:
[snip]
> This change has superseded the previous SCC (second-class citizen
> architecture) plan that had already been proposed to reduce the amount of
> data Debian mirrors are required to carry; prior to the release of sarge,
> the ftpmasters plan to bring scc.debian.org on-l
John Goerzen wrote:
[snip]
> > - the release architecture must have N+1 buildds where N is the number
> > required to keep up with the volume of uploaded packages
> >
> > - the value of N above must not be > 2
>
> It seems to me that if an arch can keep up with builds, why impose this
> artific
Tollef Fog Heen wrote:
> * Thiemo Seufer
>
> | For anyone who uses Debian as base of a commercial solution it is a
> | requirement. Grabing some random unstable snapshot is a non-starter.
>
> You do realise this is exactly what Ubuntu is doing? (Grab «random»
> snap
Goswin von Brederlow wrote:
[snip]
> A release for an scc arch could come weeks or month later than the
> main archs and be done by the porters alone. The only requirement for
> it would be that only stable sources can be used (with a few
> exceptions maybe for arch specific sources). Stable source
Goswin von Brederlow wrote:
> Tollef Fog Heen <[EMAIL PROTECTED]> writes:
>
> > * Hamish Moffatt
> >
> > | OK, that makes sense. Can you buy those architectures new? (Surely yes
> > | in the case of s390 at least, probably mipsel also as the mips CPU
> > | manufacturers are alive and well.)
> >
>
Hamish Moffatt wrote:
> On Mon, Mar 14, 2005 at 02:41:35PM +0100, Frank Küster wrote:
> > Hamish Moffatt <[EMAIL PROTECTED]> schrieb:
> > > On Mon, Mar 14, 2005 at 01:33:16PM +0100, Thiemo Seufer wrote:
> > >> For anyone who uses Debian as base of a commercial
Anthony Towns wrote:
[snip]
> >The "stabilise" is the missing part in the proposal. Stabilization and
> >security would need to be done outside Debian.
>
> From the announcement:
>
> ---
> Architectures that are no longer being considered for stable releases
> are not going to be left out in the
Peter 'p2' De Schrijver wrote:
[snip]
> I think we should distinguish between what's really necessary to have a
> useable release and what is nice to have. It's obviously nice to compile
> almost everything for all archs. But if upstream is too broken for this
> to be possible, it might make more s
Reinhard Tartler wrote:
> On Mon, 14 Mar 2005 15:11:01 +0100, Tollef Fog Heen <[EMAIL PROTECTED]> wrote:
> > * Hamish Moffatt
> >
> > | OK, that makes sense. Can you buy those architectures new? (Surely yes
> > | in the case of s390 at least, probably mipsel also as the mips CPU
> > | manufacturer
Henning Makholm wrote:
> Scripsit Bastian Blank <[EMAIL PROTECTED]>
>
> > Yes, it was a broken autobuilder, the only autobuilder, the others are
> > blocked by the w-b admins.
>
> How can something really be "blocked by the w-b admins"? The buildds
> build .debs from publicly available source pac
Reinhard Tartler wrote:
> On Tue, 15 Mar 2005 18:37:10 +0100, Thiemo Seufer <[EMAIL PROTECTED]> wrote:
> > > > This was bought about a week ago; a linksys WRT54GS.
> > >
> > > Please be serious. Did you really manage to get debian running on that
> > &g
Moritz Muehlenhoff wrote:
[snip]
> In the contrary I assume that currently the security mechanism for
> alls archs is hindered by the fact that the slowest arch sets the pace.
> There has been a XSF-SVN commit for the latest libxpm vulnerability some
> days ago, which hasn't culminated into a DSA y
Wouter Verhelst wrote:
> Op di, 15-03-2005 te 11:43 -0800, schreef Steve Langasek:
> > On Tue, Mar 15, 2005 at 01:28:15PM +0100, Wouter Verhelst wrote:
> > > Op ma, 14-03-2005 te 16:09 -0800, schreef Steve Langasek:
> > > > You do know that m68k is the only architecture still carrying around
> > >
Andreas Barth wrote:
> * Mike Fedyk ([EMAIL PROTECTED]) [050316 20:55]:
> > Andreas Barth wrote:
> > >If that happens for a too long period, we might consider such an
> > >architecture to be too slow to keep up, and will eventually discuss
> > >about kicking it out of the architectures we wait for
Daniel Jacobowitz wrote:
[snip]
> > Okay, so we've got a new suite; is that global for all scc arches, or
> > separate, a la "subtesting-s390", say? The question there is "Will s390
> > have a different version of the package to m68k, if one or the other is
> > being more aggressively maintained
Peter 'p2' De Schrijver wrote:
[snip]
> Why would a port release after the main release ?
Probably to fix up a few remaining arch-specific bugs.
> Why, if debian doesn't
> care about the non-release archs, would the porters even bother to
> follow the release arch sources and not just release whe
Steve Langasek wrote:
[snip]
> > How is the layout of scc.debian.org planned to look like? Separate
> > .scc.debian.org (or scc.debian.org//...) archives or a
> > single one which needs partial mirroring tricks? Will arch:all be
> > duplicated there or will it need to be fetched from some other mir
Michael K. Edwards wrote:
[snip]
> That leaves mips (big-endian), hppa, alpha, and s390. Not so much
> doorstops as space heaters; some people might put ia64 in this
> category too.
FWIW, the distinction between mips and mipsel isn't that clear-cut.
All MIPS CPUs (except the R8000) can run in big
Hello All,
while preparing an upload of gcc-2.95 which fixes its worst problems
I wondered how many users of it are actually left. 9 packages in
unstable still declare a build dependency on gcc-2.95 or g++-2.95,
this makes it IMHO a plausible release goal to get rid of 2.95
maintenance for etch.
Dave Carrigan wrote:
> On Tue, Nov 15, 2005 at 06:00:06PM +0100, Thiemo Seufer wrote:
>
> > this makes it IMHO a plausible release goal to get rid of 2.95
> > maintenance for etch.
>
> No it is not. Just because debian packages don't use 2.95 doesn't mean
>
Steve M. Robbins wrote:
> On Tue, Nov 15, 2005 at 06:00:06PM +0100, Thiemo Seufer wrote:
>
> > Malloc debugging, #285685 suggests it is broken for > 300 days now,
> > either update or remove:
> >
> >Steve M. Robbins <[EMAIL PROTECTED]>
> >
Ben Pfaff wrote:
> Thiemo Seufer <[EMAIL PROTECTED]> writes:
>
> > Unacknowledged NMU for > one year, either update or remove:
> >
> >Ben Pfaff <[EMAIL PROTECTED]>
> > gcccheckerBuild-Depends: gcc-2.95
>
> I recently filed a
Mark Brown wrote:
> On Tue, Nov 15, 2005 at 06:30:00PM +0100, Thiemo Seufer wrote:
>
> > The need for gcc-2.95 usually means the source code is broken (in C99
> > terms) and should be fixed. Do you have an example of an use case where
> > this is unfeasible, and whic
Nikita V. Youshchenko wrote:
>
>
> > Dave Carrigan wrote:
> >> On Tue, Nov 15, 2005 at 06:00:06PM +0100, Thiemo Seufer wrote:
> >>
> >> > this makes it IMHO a plausible release goal to get rid of 2.95
> >> > maintenance for etch.
> >
Thiemo Seufer wrote:
> Nikita V. Youshchenko wrote:
[snip]
> > Also, people have some code (old completed internal projects, etc), which
> > probably would never be ported to newer C++ standards (it's plainly too big
> > job), but which are still useful to keep working -
Moritz Muehlenhoff wrote:
> In linux.debian.devel, you wrote:
> >> The need for gcc-2.95 usually means the source code is broken (in C99
> >> terms) and should be fixed. Do you have an example of an use case where
> >> this is unfeasible, and which is important enough to justify continued
> >> main
Nikita V. Youshchenko wrote:
> >> > The need for gcc-2.95 usually means the source code is broken (in C99
> >> > terms) and should be fixed. Do you have an example of an use case where
> >> > this is unfeasible, and which is important enough to justify continued
> >> > maintenance of gcc 2.95?
> >>
Stephen Gran wrote:
> This one time, at band camp, Rafael Laboissiere said:
> > I am moving this discussion to debian-devel, since I am not sure we
> > are really violating the Policy. Feel free to move it further to
> > debian-policy, if you think it is appropriate.
>
> FWIW, Rafael, at first bl
Marc Haber wrote:
[snip]
> > How is it possible for you to claim something is more secure
> >when you don't understand it well enough to say how it's different?
>
> Well, even if I know naught about it, it looks to me that having
> something signed is better than having the same something not sign
Rafael Laboissiere wrote:
> [Please, Cc: to me, I am not currently subscribed to debian-devel.]
>
> * Thiemo Seufer <[EMAIL PROTECTED]> [2005-11-24 02:13]:
>
> > Stephen Gran wrote:
> > > FWIW, Rafael, at first blush I have to say I agree with you. A
> > &
Stephen Gran wrote:
[snip]
> > > > "The maintainer name and email address used in the changelog should
> > > > be the details of the person uploading this version. They are not
> > > > necessarily those of the usual package maintainer."
> > [snip]
> > > I think that are two distinct c
Stephen Gran wrote:
[snip]
> And we are in danger of allowing policy to drive practice, rather than
> vice versa.
>
> The problem is, there are many packages currently being group
> maintained. These groups generally have some sort of group contact
> email address:
> grep-dctrl -n -s Maintainer
Stephen Gran wrote:
> This one time, at band camp, Thiemo Seufer said:
> > Btw, about this simple-minded test:
> > 299 of those are maintained by the Debian Install System Team, and
> > nobody there felt compelled to put [EMAIL PROTECTED] in the changelog
> > for whatev
Stephen Gran wrote:
> This one time, at band camp, Thiemo Seufer said:
> > Stephen Gran wrote:
> > > This one time, at band camp, Thiemo Seufer said:
> > > > Btw, about this simple-minded test:
> > > > 299 of those are maintained by the Debian Install
Isaac Clerencia wrote:
> On Thursday, 24 November 2005 22:03, Stephen Gran wrote:
> > But the .dsc is. This stuff is easily traceable, if we want to. I can
> > see the benefit of having the same name in the Maintainer field and in the
> > changelog for some. I can see arguments against it, but n
Isaac Clerencia wrote:
> On Thursday, 24 November 2005 22:36, Thiemo Seufer wrote:
> > > I can see arguments against it, but none that make
> > > it an RC bug.
> >
> > Policy violations are RC by definition.
> According to policy "should"'s
Brian May wrote:
> >>>>> "Thiemo" == Thiemo Seufer <[EMAIL PROTECTED]> writes:
>
> >> Well, even if I know naught about it, it looks to me that having
> >> something signed is better than having the same something not signed.
&
Norbert Preining wrote:
> Hi all!
>
> On Mon, 28 Nov 2005, Miles Bader wrote:
> > nicely as "texlive-lang-tibetan" and "texlive-fonts-recommended".
>
> On Mon, 28 Nov 2005, Rogério Brito wrote:
> > > texlive-binaries-source 96M
> > > texlive-basicbin
> > What about texlive-bin-base?
>
Andrew Vaughan wrote:
> On Mon, 28 Nov 2005 22:28, Thiemo Seufer wrote:
> >
> > FWIW, Debian package names prefer e.g. foo-en-uk-doc over
> > foo-documentation-ukenglish. This allows to filter documentation
> > packages by name (doc-* or *-doc), and following the standar
Norbert Preining wrote:
[snip]
> For the language stuff: Here is a problem as some languages packages are
> not *one* single language, but several (arabic, cjk, other). So would it
> be the best solution to have
> old:texlive-langX
> new:texlive--lang
> ?
Arabic is "ar"
mentation-czechslovak texlive-cs-doc
> > texlive-documentation-dutch texlive-nl-doc
> > texlive-documentation-english texlive-en-doc
> >
> >
> > Best wishes
> >
> > Norbert
> >
>
> In [1], Thiemo Seufer asserts that "FWIW,
Thomas Viehmann wrote:
> Hi,
>
> Vincent Sanders wrote:
> > [1] http://buildd.debian.org/~jeroen/status/architecture.php?a=arm
>
> taking a "random" (end of alphabet) sample from maybe-failed:
>
> twinkle: requeue (probably libccrtp was stuck in NEW)
> wvstreams: Dep-Wait (libxplc0.3.13-dev) - d
Steve Langasek wrote:
[snip]
> > > So those should get added to P-a-s instead.
> > Well, but that'd be something for the buildd-admin to collect.
> > (Or maintainers of the packages, but that doesn't seem to fashionable
> > nowadays...)
>
> Um... no. This is *porter* work; one does not have to be
Thomas Viehmann wrote:
> Hi Steve,
>
> Steve Langasek wrote:
> > Ok. Here's some feedback on some that I either disagree with, or don't see
> > enough rationale for. (This is why, ideally, the process should involve the
> > porters and the maintainers...)
> Thanks. Doesn't hurt do get educated..
Steve Langasek wrote:
[snip]
> > -grub2: !hppa !ia64 m68k #
> > bootloader
> > +grub2: !hppa !ia64 !m68k !alpha !mips !mipsel !s390 !sparc #
> > bootloader for i386/powerpc [?]
Is a P-a-s entry some sort of a final verdict? I don't think it
Heiko Müller wrote:
> Dear Thiemo,
> we very much appreciate your work on the gcc-2.95 debian package.
> For us - and probably also for other users in the scientific
> community - the "old" compiler version is still of great value.
>
> We use gcc-2.95 to compile C/C++ code with very large mathema
Jeroen van Wolffelaar wrote:
[snip]
> A similar issue I noted in the past is the big number of build failures
> that don't get tagged 'Failed'. I tried working on classifying them, but
> got bored so increadibly fast that I gave up, and decided for myself
> this should be something the porters shou
On Wed, Feb 22, 2006 at 08:47:31PM -0800, Steve Langasek wrote:
> On Thu, Feb 23, 2006 at 12:22:27AM -0300, Henrique de Moraes Holschuh wrote:
> > On Wed, 22 Feb 2006, Chris Stromsoe wrote:
> > > for the entire lifetime of the current stable release. Will -17.1 be
> > > making its way into stable
On Mon, Mar 13, 2006 at 01:05:38AM +0100, Pjotr Kourzanov wrote:
[snip]
> >>There's also kfreebsd-{i386,amd64}, so why don't you use uclibc-i386?
> >>
> >>
> >
> >Actually, I disagree. To me it makes perfect sense the way it
> >currently is, namely:
> > kernel-arch-libc
> >
> >kernel and libc c
Francois Bottin wrote:
> Selon etse hellene <[EMAIL PROTECTED]>:
>
> >
> > Bonjour Monsieur,
> >
>
> For those not speaking french, this is a nigerian scam... The first I have
> ever
> received in this language, albeit very poorly written.
Probably some automated translation, like the german va
Mike Furr wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> retitle 292541 ITP: pbzip2 -- Parallel bzip2 implementation
> thanks.
>
> Package name: pbzip2
> Version: 0.9
> Upstream Author: Jeff Gilchrist <[EMAIL PROTECTED]>
> URL: http://compression.ca/pbzip2/
> License: BSD-style lice
Henrique de Moraes Holschuh wrote:
> On Sun, 30 Jan 2005, Martin Zobel-Helas wrote:
> > Every 0-8-15 user will do exactly the same as i did. It is your package
>
> What is a 0-8-15 user?
08/15: A german expression for "uniform, standardized, mass-".
Thiemo
--
To UNSUBSCRIBE, email to [EMAIL
Cajus Pollmeier wrote:
> Hi,
>
> I'm looking for a script that regenerates Packages* and Release
> files for a complete mirror. Due to some installer development, I
> currently need to switch the mirrors during installation in order to
> get up to date packages.
>
> Tried to work around this with
Anthony Towns wrote:
[snip]
> So, I'd just like to re-emphasise this, because I still haven't seen
> anything that counts as useful. I'm thinking something like "We use s390
> to host 6231 scientific users on Debian in a manner compatible to the
> workstations they use; the software we use is ..
Henning Makholm wrote:
> Scripsit David Weinehall <[EMAIL PROTECTED]>
>
> > That said, I'm a firm believer of the suggestion posed by Jesus
> > Climent[1], that we should have base set of software (where base is
> > probably a bit bigger than our current base) released for all
> > architectures th
Christian Perrier wrote:
[snip]
> This is spring time (at least for half of the world...and probably for
> 90% of Debian world)so take a break, go for a walk in the forest,
> hear the birds singing, get one day off with no mail reading...and
> remember this is all about a hobby for most of us.
Hamish Moffatt wrote:
> On Sun, Mar 20, 2005 at 09:56:05AM +0100, Sven Luther wrote:
> > On Sun, Mar 20, 2005 at 12:00:23PM +1000, Anthony Towns wrote:
> > > But why would you spend over 1000 pounds on an arm Linux desktop box
> > > instead of a few hundred pounds on a random i386 desktop box?
> >
Andreas Barth wrote:
> * Marco d'Itri ([EMAIL PROTECTED]) [050319 03:50]:
> > On Mar 18, Steve Langasek <[EMAIL PROTECTED]> wrote:
>
> > > There would definitely be duplication of arch:all between ftp.debian.org
> > > and ports.debian.org (let's call it ports), as well as duplication of the
> > >
David Nusinow wrote:
[snip]
> > This is a non-issue. The main problem was the kernel situation, which will
> > be
> > streamlined for etch into a single package, and maybe build issues, which
> > could be solved by a separate build queue or priority for d-i issues.
>
> You know, you keep saying t
David Nusinow wrote:
[snip]
> > > If you have a single source package for 12 different architectures
> > > that's great, because when you have a security fix you can take
> > > care of that more easily. That's awesome.
> >
> > We have that already.
>
> Great to hear. Then what is this new plan th
Sven Luther wrote:
[snip]
> > For sarge, kernels are built in a two-stage process. First is to create
> > a dsfg-free .deb from the upstream source which contains a source
> > tarball, second is to build kernel images from another (arch-specific)
> > .deb which build-depends on the source .deb. In
Wouter Verhelst wrote:
[snip]
> > m68k, mips, mipsel, hppa: I've got one in the basement, and I like
> > to brag that I run Debian on it; also I occassionally get some work out
> > of
> > it, but it'd be trivial to replace with i386.
>
> Aren't the first three of these also actively bei
Simon Richter wrote:
> Hi,
>
> Michael K. Edwards:
> >The latest uim FTBFS twice on ARM because of the removal of howl
> >dependencies from gnome packages. The rebuilt gnome-vfs2 still hadn't
> >made it to unstable as of the second try, so the archive wasn't in a
> >state that any package depende
Steve Langasek wrote:
[snip]
> Auto-removal of orphaned packages from unstable is also bad if it's an
> orphaned library that's still needed (which happens often enough).
Auto-removal of orphaned (build-)dependency leaves sounds useful.
This would also remove orphaned libraries after a while if th
Emanuele Rocca wrote:
> * [ 11-04-05 - 09:14 ] Ron Johnson <[EMAIL PROTECTED]> wrote:
> > ISTM that the good reason for writing-from-scratch duplicate
> > functionality is if you have a Better Idea (better data structures,
> > better interfaces, extra functionality, etc, etc) that are so
> > f
Ian Murdock wrote:
> On 6/16/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
> > > I strongly suspect they're
> > > more interested in your X.org and GNOME 2.10. Given
> > > that, a lot of this divergence seems pretty gratutious to me.
> >
> > Yes, these are both very interesting to users.
> >
> > Wh
Junichi Uekawa wrote:
> Hi,
>
> > This week, we will change the GCC default versions from 3.3 to 4.0
>
> Would it break kernel 2.4 builds somehow ?
> I've not been quite following; but the thread almost a month ago
> seems to indicate thus:
> http://www.kerneltraffic.org/kernel-traffic/kt20050701
Otavio Salvador wrote:
> Thiemo Seufer <[EMAIL PROTECTED]> writes:
>
> > Junichi Uekawa wrote:
> >> Hi,
> >>
> >> > This week, we will change the GCC default versions from 3.3 to 4.0
> >>
> >> Would it break kernel 2.4 builds som
Marc Haber wrote:
> On Mon, Jul 04, 2005 at 11:12:21AM +0200, Thiemo Seufer wrote:
> > Most kernel hackers don't care that much about 2.4 any more.
>
> This is of course one of the reasons why users feel left alone by the
> kernel developers.
The gcc version recommended by
1 - 100 of 156 matches
Mail list logo
