On Sun, 2008-10-05 at 10:24 +0200, Pierre Habouzit wrote:
On Fri, Oct 03, 2008 at 04:59:03PM +, Thomas Bushnell BSG wrote:
I completely agree that libdb4.3 is ancient grot, and it should be
removed from the archive.
I am distressed that the maintainers decided to wait until
Have the NMU rules recently been changed in a way I was unaware of? I
recently encountered a 0-day NMU of a package of mine to fix an
important bug, a normal bug, and a non-bug, without any patch posted to
the bug log. In my judgment, it is unlikely that the release team would
welcome this
On Sun, 2008-10-05 at 15:04 -0700, Steve Langasek wrote:
The bug on mmorph was not filed by the db maintainers, it was filed by a
release manager. I guess mmorph was overlooked when the db maintainers
filed bugs requesting migration to db4.6 a year ago. That's unfortunate,
but it's not a
I completely agree that libdb4.3 is ancient grot, and it should be
removed from the archive.
I am distressed that the maintainers decided to wait until the freeze to
do that. This is entirely *backwards*. The time to decide, hey, this
library should be removed is at the *beginning* of the
On Sun, 2008-09-28 at 21:19 -0700, Steve Langasek wrote:
Redundant versions of BDB in the archive unnecessarily bloat the release and
Debian's install footprint, and impose a burden on the Debian DB packaging
team. There are currently five versions of BDB in lenny, whereas there are
only 7
On Fri, 2008-09-12 at 09:24 +0200, Bastian Blank wrote:
On Thu, Sep 11, 2008 at 11:44:00PM -0700, Steve Langasek wrote:
Given that sshfs's errno return is wildly wrong,
The errors are not wrong. The lists in the documentation are not
terminal.
The open group spec say[1]:
| The ERRORS
On Fri, 2008-09-12 at 00:32 -0700, Steve Langasek wrote:
EPERM The file system containing oldpath and newpath does not support
the creation of hard links.
That seems to cover any case where the kernel might return ENOSYS...
Yes, but this is not glibc's responsibility;
On Fri, 2008-09-12 at 00:48 -0700, Steve Langasek wrote:
FWIW, I know there have been other cases in the past where glibc has handled
ENOSYS returns for unimplemented syscalls and fallen back to older,
less-preferred interfaces to avoid returning ENOSYS to the caller for a case
where the
On Fri, 2008-09-12 at 10:37 +0200, Bastian Blank wrote:
On Fri, Sep 12, 2008 at 12:32:15AM -0700, Steve Langasek wrote:
On Fri, Sep 12, 2008 at 09:24:55AM +0200, Bastian Blank wrote:
And which value should they be mapped to?
EPERM The file system containing oldpath and newpath
On Fri, 2008-09-12 at 10:40 +0200, Bastian Blank wrote:
On Fri, Sep 12, 2008 at 12:38:14AM -0700, Thomas Bushnell BSG wrote:
Yes, but this is not glibc's responsibility; it is the kernel's. and, i
think the kernel should pass back the error it gets too. it is sshfs
which should do
Please allow gnucash 2.2.6-2 into testing; this has a minimally invasive
patch to avoid a dangerous data-loss bug in an unusual usage case.
(It turns out that sshfs returns ENOSYS on a link call. This is wildly
wrong; it has no business doing so, especially when EPERM is already the
documented
On Mon, 2008-08-18 at 16:13 -0600, dann frazier wrote:
fwiw, it builds fine (once the arch list is updated), and my test
builds of a couple guile-1.8 packages seem to build/run fine. As an
ia64 user, I would be happy to have ia64 back in sync with the other
archs here.
I agree. It would be
I have uploaded libofx 1:0.9.0-3. This acknowledges NMUs already in
lenny, and includes a bug fix for an internationalization bug of
severity important: #493597; I used the patch described in the bug
report.
libofx is priority optional and the fix can be (and has been) made via
unstable and
On Fri, 2008-08-01 at 09:56 +0200, Philipp Kern wrote:
Hallo Thomas,
am Thu, Jul 31, 2008 at 06:08:18PM -0700 hast du folgendes geschrieben:
Gnucash 2.2.6 has been released. See previous emails from me on the
subject. I'm now seeking approval to upload 2.2.6 and have it hinted
for
On Fri, 2008-08-01 at 09:56 +0200, Philipp Kern wrote:
Hallo Thomas,
am Thu, Jul 31, 2008 at 06:08:18PM -0700 hast du folgendes geschrieben:
Gnucash 2.2.6 has been released. See previous emails from me on the
subject. I'm now seeking approval to upload 2.2.6 and have it hinted
for
Gnucash 2.2.6 has been released. See previous emails from me on the
subject. I'm now seeking approval to upload 2.2.6 and have it hinted
for testing, which will (among other things) close all the RC and the
relevant important bugs currently against gnucash, make HBCI work
properly, and otherwise
It turns out that the upload of an HBCI-supporting gnucash which I made
was missing some important patches. (See recent gnucash bugs by Micha
Lenk for details.) I am not entirely confident there are not other such
problems. This seems to me to be a poor way to go.
What I would most like to do
This request is about gnucash bug #303234.
There are two ways available to address this bug.
The bug new has a patch helpfully contributed, which would enable us
finally to make this work, which is a crucial thing for German users.
But I would much prefer to use what upstream gnucash will
Would it be possible to hold off on more qt-x11-free uploads so that the
libofx transition can occur? They are linked through kymymoney2.
The latest upload happened just in time, it seems to prevent the
previous version from transitioning, as did the one before that. And
the latest (3:3.3.8b-4)
I think libofx needs a hint to get into testing. Thanks.
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Mon, 2008-02-18 at 09:25 -0500, Thomas Bushnell BSG wrote:
Is something not working with the sparc buildd? I have a couple
packages that haven't been built in two weeks, which normally doesn't
happen.
Ah, I see the problem; I missed it first time round. For some reason
http
Is something not working with the sparc buildd? I have a couple
packages that haven't been built in two weeks, which normally doesn't
happen.
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Dash has a serious bug which is causing grief.
The problem is that it overrides the system's test command (in
Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is
inconsistent with the Debian versions.
Nothing in Posix permits this behavior, but it is tolerated by the
standard
On Sun, 2008-02-10 at 10:57 -0800, Russ Allbery wrote:
Thomas Bushnell BSG [EMAIL PROTECTED] writes:
Dash has a serious bug which is causing grief.
The problem is that it overrides the system's test command (in
Debian, /usr/bin/test and /usr/bin/[) and does so in a way which
On Sun, 2008-02-10 at 19:58 +0100, Pierre Habouzit wrote:
On Sun, Feb 10, 2008 at 06:16:44PM +, Thomas Bushnell BSG wrote:
Dash has a serious bug which is causing grief.
[ strip whining ]
Alas, dash does change the syntax of the command.
[ whine whine whine ]
What
On Sun, 2008-02-10 at 10:57 -0800, Russ Allbery wrote:
Thomas Bushnell BSG [EMAIL PROTECTED] writes:
Dash has a serious bug which is causing grief.
The problem is that it overrides the system's test command (in
Debian, /usr/bin/test and /usr/bin/[) and does so in a way which
On Sun, 2008-02-10 at 11:26 -0800, Mike Bird wrote:
On Sun February 10 2008 10:16:44 Thomas Bushnell BSG wrote:
Shells can override commands, but only if they don't play games with the
syntax.
Agreed. Within the Debian world, dash has redefined test rather
than building in test
On Sun, 2008-02-10 at 19:36 -0800, Russ Allbery wrote:
Raphael Geissert [EMAIL PROTECTED] writes:
I just replied to Thomas on the bug report including some information
that demonstrates that his arguments on dash not implementing some (at
least the one mentioned on the report)
Can an NMU for gnucash please be scheduled? The recent upload failed
because of an slib installation bug which has since been fixed.
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Tue, 2008-01-15 at 10:34 +0100, Pierre Habouzit wrote:
On Tue, Jan 15, 2008 at 01:10:26AM +, Thomas Bushnell BSG wrote:
Don't start filing remove requests until other maintainers have a
chance. Take the step of contacting those who maintain packages that
depend on the libraries you
On Tue, 2008-01-15 at 17:02 +, Neil McGovern wrote:
On Tue, Jan 15, 2008 at 11:35:54AM -0500, Thomas Bushnell BSG wrote:
So please, let these maintainers choose, rather than ordering them
about. It is *they* who are in a position to decide whether maintaining
gnome 1.x is worth
On Tue, 2008-01-15 at 00:07 +0100, Pierre Habouzit wrote:
Then I'll do some more runs of the same principle on other gnome 1.x
related libs until we got rid of them al.
If you know your package depends on gnome 1.x one way or the other, now
is the time to fix that, package a new upstream,
On Wed, 2007-07-04 at 13:30 +0200, Florent Rougon wrote:
[Trying to reply for Frank, since he's on vacation...]
Hi,
Steve Langasek [EMAIL PROTECTED] wrote:
This particular problem only exists because you're providing tetex-bin and
tetex-extra packages that don't have the same
One of the unfortunate side-effects of a freeze is that it becomes very
hard to get necessary changes into etch when an upstream package is a
more rapidly moving target.
In the four months since gnucash 2.0.2 was released, much development
has happened, and upstream has released several more
So the release criteria require buildd redundancy. And yet, half the
release candidate archs still don't have it. It gets marked in yellow
on http://release.debian.org/etch_arch_qualify.html.
Well, the one-and-only alpha buildd has been down for apparently ten
days and does not respond to ping,
I've uploaded 2.0.2-3 to fix the open release critical bug for gnucash
and do minor cleanup after the incorrect NMU of last month. Please
allow it into testing once the regular five-day delay is over, and
please do not force it to wait for the absent alpha autobuilder to catch
up.
Thomas
On Wed, 2007-01-17 at 18:36 +0100, Martin Schulze wrote:
Thomas Bushnell BSG wrote:
So the release criteria require buildd redundancy. And yet, half the
release candidate archs still don't have it. It gets marked in yellow
on http://release.debian.org/etch_arch_qualify.html.
Well
On Wed, 2007-01-17 at 13:47 -0800, Steve Langasek wrote:
Of course, I have a conflict of interest here as an alpha porter, so
ultimately I'll defer to Andi if he thinks it's become a problem; but in
general we're unlikely to cut a port from the release at this late stage
without some pretty
According to the bug log http://bugs.debian.org/378346, gail version
1.8.11-3 was uploaded by Loic Minier and had the following:
gail (1.8.11-3) unstable; urgency=high
.
* Revert changes of 1.8.11-2 as release team explained that a simple
re-upload is enough for non-bin-NMU-able
I'm pleased to report that the upload of glib version 2.16.6-2 does seem
to have solved the gnucash regression caused by 2.12.5-3.
That, as far as I can tell, ends the need for this to be a release
concern for Debian; we can work out more leisurely now what the final
shape of this should look
On Sun, 2006-12-31 at 21:10 +0100, Loïc Minier wrote:
Finally, since glib's upstream added support for key names with MIME
types chars such as / and + for gnome-vfs2, I also added a patch to
silently support key names with spaces in the middle of the name (not
at the beginning or at the
Here is what gnucash upstream says about this nasty little issue.
I want to get out of the middle of this, by the way. Can glib upstream
and gnucash upstream now talk directly together?
Thomas
---BeginMessage---
On Fri, 2006-12-29 at 10:42 -0800, Thomas Bushnell BSG wrote:
gnucash creates its
On Sat, 2006-12-30 at 17:15 +0100, Josselin Mouette wrote:
Le vendredi 29 décembre 2006 à 10:48 -0800, Thomas Bushnell BSG a
écrit :
Despite what Josselin has said, I can see no indication from a brief
perusal of the upstream branch sources in trac that upstream gnucash
either no longer
On Sat, 2006-12-30 at 09:32 +0100, Marc 'HE' Brockschmidt wrote:
Thomas Bushnell BSG [EMAIL PROTECTED] writes:
On Fri, 2006-12-29 at 16:39 -0700, Debian testing watch wrote:
FYI: The status of the gnucash source package
in Debian's testing distribution has changed.
Previous version
So there is, at the moment, a disagreement between the gnucash and glib
developers about whether the keyfile interface is even a supported
interface, with Josselin now suggesting that the glib maintainers simply
won't support the use of keyfiles by applications (despite it being
documented).
And,
On Fri, 2006-12-29 at 08:44 +0100, Martin Schulze wrote:
For the sake of the upcoming release, I wonder how many files / users
are affected by this change? Is it really release-critical? If not,
would it not helpe if Thomas provides a script in the gnucash package
that adjusts the keys that
On Fri, 2006-12-29 at 03:06 +0100, Josselin Mouette wrote:
Le jeudi 28 décembre 2006 à 17:29 -0800, Thomas Bushnell BSG a écrit :
On Fri, 2006-12-29 at 01:56 +0100, Josselin Mouette wrote:
Now, if you don't provide us with the necessary data, we won't be able
to fix the regression
On Fri, 2006-12-29 at 17:02 -0200, Otavio Salvador wrote:
Thomas Bushnell BSG [EMAIL PROTECTED] writes:
2) Decide that glib can migrate into testing, with the particular change
of checking key values reverted to its pre-2.12.5 behavior, since this
is a destabilizing change in the Debian
On Fri, 2006-12-29 at 17:13 -0200, Otavio Salvador wrote:
Well, bugs are bugs and I don't think we should be too hard on this. I
think that changes that does change the library behaviour should be
avoided.
The rules for a freeze are that changes which fix release critical bugs
are
On Fri, 2006-12-29 at 12:56 -0800, Steve Langasek wrote:
On Fri, Dec 29, 2006 at 08:11:14PM +0100, Frans Pop wrote:
On Friday 29 December 2006 19:48, Thomas Bushnell BSG wrote:
Note that option (3) depends on upstream's ability to fix the problem
quickly, *and* is likely to be error prone
On Thu, 2006-12-28 at 20:45 +0100, Marc 'HE' Brockschmidt wrote:
As this may break more applications (earlier version broke locale
parsing and gnomevfs), we should probably keep that code, reduce it to a
warning for etch and then work out (together with upstream) how to solve
this for the
Package: glib2.0
Version: 2.12.5-3
This version of glib (both 2.12.5-3 and 2.12.6-1) causes an important
regression in gnucash, and therefore should not go into testing.
See http://bugs.debian.org/404585.
signature.asc
Description: This is a digitally signed message part
On Fri, 2006-12-29 at 00:49 +0100, Josselin Mouette wrote:
Le jeudi 28 décembre 2006 à 14:47 -0800, Thomas Bushnell BSG a écrit :
Package: glib2.0
Version: 2.12.5-3
This version of glib (both 2.12.5-3 and 2.12.6-1) causes an important
regression in gnucash, and therefore should not go
On Fri, 2006-12-29 at 01:41 +0100, Josselin Mouette wrote:
1) The release team has asked us not to upload changes which are not
destined for etch, and making gnucash work with the glib in unstable is
therefore a low priority;
The glib in unstable is destined for etch, whether you like it
On Fri, 2006-12-29 at 01:56 +0100, Josselin Mouette wrote:
Now, if you don't provide us with the necessary data, we won't be able
to fix the regression it introduces in gnucash.
There are clearly two plausible solutions to the underlying problem:
1. Change gnucash to conform to the new
On Fri, 2006-12-29 at 01:56 +0100, Josselin Mouette wrote:
Now, if you don't provide us with the necessary data, we won't be able
to fix the regression it introduces in gnucash.
Here is a sample file; I suspect the offending character is the space,
if I'm reading Marc Brockschmidt's regex
Why are new upstream releases being added to upstable of the glib2.0
package? We are in a freeze, I thought. And one seems perhaps to be
responsible for a regression in gnucash (see #404585).
Thomas
signature.asc
Description: This is a digitally signed message part
On Wed, 2006-12-27 at 01:46 +0100, Alexander Wirt wrote:
Roberto C. Sanchez schrieb am Dienstag, den 26. Dezember 2006:
On Wed, Dec 27, 2006 at 01:28:23AM +0100, Alexander Wirt wrote:
Thomas Bushnell BSG schrieb am Dienstag, den 26. Dezember 2006:
Why are new upstream releases
On Tue, 2006-12-26 at 20:16 -0500, Edward Shornock (debian ml) wrote:
It seems that the new upstream changes in glib would qualify as a potentially
disruptive change.
It has been confirmed that it is genuinely a disruptive change. Bug
404585, severity important, occurs only with the new
On Wed, 2006-12-27 at 14:22 +1100, Vincent Ho wrote:
On Tue, Dec 26, 2006 at 08:09:52PM -0700, Thomas Bushnell BSG wrote:
It has been confirmed that it is genuinely a disruptive change. Bug
404585, severity important, occurs only with the new libglib.
Um Thomas, you yourself set the bug
On Tue, 2006-12-26 at 21:02 -0800, Steve Langasek wrote:
On Tue, Dec 26, 2006 at 05:21:31PM -0700, Thomas Bushnell BSG wrote:
Why are new upstream releases being added to upstable of the glib2.0
package? We are in a freeze, I thought. And one seems perhaps to be
responsible
On Tue, 2006-12-26 at 21:59 -0800, Steve Langasek wrote:
You asked for the release team's input into whether to upload the new
upstream version, and Luk replied with an explanation that was consistent
with the release team's position on the matter: new upstream versions and
uploads including
On Wed, 2006-12-20 at 19:51 -0800, Steve Langasek wrote:
On Tue, Dec 19, 2006 at 11:17:03AM -0800, Thomas Bushnell BSG wrote:
The python team has apparently decreed that python 2.3 will not be in
etch. This forces every package to use the new version. Surely it is
too late in the release
On Fri, 2006-12-22 at 00:38 +0100, Matthias Klose wrote:
To conclude, the support of multiple python versions is not meant at
all as an excuse for lazy debian maintainers depending on python for
not following upstream python development.
Are you calling me lazy for not fixing a bug that you
On Fri, 2006-12-22 at 00:38 +0100, Matthias Klose wrote:
An explicitely stated goal of the release team was to reduce the
number of supported python versions for the next stable release. We
did include three python versions for sarge (2.[123]). To reduce that
count we do have to drop 2.3
The python team has apparently decreed that python 2.3 will not be in
etch. This forces every package to use the new version. Surely it is
too late in the release cycle to be risking regressions in this way?
signature.asc
Description: This is a digitally signed message part
Please hint lilypond 2.8.3-3 into testing at the appropriate time. This
fixes an important bug with a simple one-line fix to a pathname in a
script which is only used by the command which didn't work (thanks to
the bug).
Thomas
signature.asc
Description: This is a digitally signed message
On Wed, 2006-12-20 at 01:25 +0100, Matthias Klose wrote:
Thomas Bushnell BSG writes:
The python team has apparently decreed that python 2.3 will not be in
etch. This forces every package to use the new version. Surely it is
too late in the release cycle to be risking regressions
On Thu, 2006-12-14 at 20:16 -0800, Steve Langasek wrote:
My belief is that this will not be a simple fix; the ia64 has a weird
stack structure and Scheme's call/cc is not trivial to implement on
weird stack machines. It took lots of work upstream to get scm to work
on ia64, and I think
In the interests of our users (TM) I'd like to upload lilypond 2.10 to
unstable. This is the current stable release of lilypond.
Advantages:
Depending on how long the release takes, it may be appropriate to
transition this to testing at some point. But this is a quite minor
thing.
Depending
Can you please add a hint to transition jacal into etch? It was removed
because an RC bug didn't get fixed promptly by me, but I never saw the
bug report for some reason. As soon as it was removed, I uploaded a fix
the same day. It has now passed the two day mark in which it would have
been
On Tue, 2006-12-12 at 21:20 +0100, Frank Küster wrote:
We've got a problem here, since all three packages are in testing,
provide /usr/bin/aleph, and conflict with each other (or rather, the
*tex* packages conflict with aleph).
Eek.
The right solution to this would be to package the new
On Mon, 2006-12-11 at 02:14 -0800, Steve Langasek wrote:
For the record, release-criticality of build failures applies only to build
failures on release architectures where the package *previously* built
successfully, and I had never claimed otherwise in the case of guile-1.8.
That seems to
The ia64 build of lilypond has been removed from unstable (thanks
Jeroen!) and the amd64 build has completed (it was waiting for the
guile-1.8 build on that arch to get uploaded). So that means that
lilypond 2.8.7-2 should now be able to transition. It has well passed
the required time, and it
I have just uploaded the fix for #401030. For some reason this bug
didn't hit my radar screen until the consequent removal from testing.
(Incidentally, the bug is really serious and not grave, because jacal
always worked fine with scm, but that doesn't matter much.)
I would appreciate it if this
On Sun, 2006-12-03 at 17:32 -0800, Steve Langasek wrote:
Nor is removing binaries from testing the issue -- the issue is that the old
binaries would need to be removed from *unstable* in order to allow the new
version of lilypond to propogate *from* unstable into testing.
Maybe this is the
On Sun, 2006-12-03 at 19:51 -0800, Steve Langasek wrote:
I still recommend asking for the out-of-date ia64 binary to be removed from
unstable pending resolution of the guile-1.8 bug, as I had said before. If
you elect to reintroduce lilypond 2.6 for ia64 as a separate source package,
that's
On Sat, 2006-12-02 at 16:01 +0100, Julien Cristau wrote:
On Fri, Dec 1, 2006 at 10:58:27 -0800, Thomas Bushnell BSG wrote:
Why is it OK for guile-1.8 to support 32-bit archs and not 64-bit archs,
but lilypond is required to support all of them? It would be better to
have a halfway
I'm confused, because in part I don't seem to get responses when I ask
questions. I think this is because the people who could respond think
they have already answered, even though they really haven't.
So guile-1.8 does not have to build from source on 64 bit archs, because
one only has to do
I would like to officially ask for an exception to the usual testing
rules for lilypond, to allow 2.8.7 into testing, on those architectures
where guile-1.8 works. The architectures currently losing for guile-1.8
are alpha, amd64, and ia64.
I believe that alpha and ia64 are release candidates,
On Wed, 2006-11-22 at 18:22 +0100, Sven Luther wrote:
But, we are nearing the release, and the actions of Frans are clearly
endangering the quality of the d-i powerpc port, and there is a decision to
take about this issue, and i guess the decision is yours to make.
This isn't clear to me at
On Sun, 2006-11-19 at 05:38 -0800, Steve Langasek wrote:
On Thu, Nov 16, 2006 at 07:05:01PM -0800, Thomas Bushnell BSG wrote:
Currently lilypond 2.8.7 is in unstable. It is blocked waiting for its
own timelimit and for guile-1.8 to finish building on other archs and
migrate itself.
Well
On Fri, 2006-11-17 at 21:35 +, Andrew M.A. Cater wrote:
On Thu, Nov 16, 2006 at 07:05:01PM -0800, Thomas Bushnell BSG wrote:
Currently lilypond 2.8.7 is in unstable. It is blocked waiting for its
own timelimit and for guile-1.8 to finish building on other archs and
migrate itself
On Thu, 2006-11-16 at 04:57 -0800, Steve Langasek wrote:
Release goals and etch-ignores
==
After a mailing list discussion about release-criticality and policy, we've
decided to include fixing bashisms as a release goal. This means that if
packages have bugs
Roman Zippel [EMAIL PROTECTED] writes:
PS: 4 days and still no response to guile-1.6 patch...
Maybe you should ask the guile-1.6 maintainer? I'm not responsible
for the package.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Roman Zippel [EMAIL PROTECTED] writes:
Then m68k would be a suitable release candidate for etch+1.
As usual you're avoiding the issue. The answer is not _that_ simple.
Really? What are the great mysterious complexities in it?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Roman Zippel [EMAIL PROTECTED] writes:
The point is that these release criteria have practically enforced a black
and white scheme - either you're with us or you're on your own.
Actually, Anthony Towns described about a half-dozen distinct
possibilities, and outlined the advantages and
Roman Zippel [EMAIL PROTECTED] writes:
Hmm and here I thought you would care about this package, the way you
constantly asked about its status...
I do care about it. But I see no particular reason for urgency about
the particular bug, and obviously, the m68k team doesn't either.
Thomas
--
Roman Zippel [EMAIL PROTECTED] writes:
I do care about it. But I see no particular reason for urgency about
the particular bug, and obviously, the m68k team doesn't either.
Obviously?
They ignored it for a long time, and as far as I know, haven't
requested the maintainer to treat it with
Steve Langasek [EMAIL PROTECTED] writes:
As mentioned above, it was discovered late in the process that three firmware
images included in the upstream kernel that are relevant to the installer are
not distributed under clearly DFSG-compliant licenses: tg3, typhoon, and
acenic. Of these, only
Roman Zippel [EMAIL PROTECTED] writes:
Well, that's what we want as well and if m68k could provide this, what's
the reason this couldn't be released as Debian?
So far, m68k *can't* provide it. That's the problem.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
Roman Zippel [EMAIL PROTECTED] writes:
On Wed, 18 Oct 2006, Thomas Bushnell BSG wrote:
Roman Zippel [EMAIL PROTECTED] writes:
Well, that's what we want as well and if m68k could provide this, what's
the reason this couldn't be released as Debian?
So far, m68k *can't* provide
Ingo Juergensmann [EMAIL PROTECTED] writes:
| Does this explain why guile-1.6 is still not compiled for m68k?
Maybe you just wanted to know if the bug is solved in the meanwhile, but
your way to ask is very, uhm, bad, because it includes some sort of attack.
Your question can be understood
Bill Allombert [EMAIL PROTECTED] writes:
On Tue, Oct 17, 2006 at 12:28:55AM -0700, Thomas Bushnell BSG wrote:
It's not like I hunted around for problems, I simply looked at the
cases closest to the packages I maintain, asking why don't they work
on m68k?
I expected you would have realised
Ingo Juergensmann [EMAIL PROTECTED] writes:
What are the porters wanted to say? We want to release with Etch? I think
that's obvious and the porters are doing their best to keep the port going
and keeping up as much as possible.
Why is the most recent g-wrap still not compiled for m68k?
I
Ingo Juergensmann [EMAIL PROTECTED] writes:
Oh well... you already know that m68k suffered from serious toolchain
problems, which are fixed now thanks to Roman, Stephen Marenka and others,
and that the w-b queueing algorithm is not known to be very intelligent,
i.e. it doesn't queue in order
Ingo Juergensmann [EMAIL PROTECTED] writes:
Oh well... you already know that m68k suffered from serious toolchain
problems, which are fixed now thanks to Roman, Stephen Marenka and others,
and that the w-b queueing algorithm is not known to be very intelligent,
i.e. it doesn't queue in order
Ingo Juergensmann [EMAIL PROTECTED] writes:
Yes, this is irrelevant for this thread as the topic of this thread is m68k
not a release arch for etch; status in testing, future plans? and not
Thomas Bushnell would like to see his packages being built on m68k. Maybe
that's disappointing for you
Roman Zippel [EMAIL PROTECTED] writes:
Fixes for problems are too often simply stuck in the BTS now, because in
many cases maintainer simply don't care about m68k support. I often have
to bug people to get them to release a fixed package.
Does this explain why guile-1.6 is still not
Roman Zippel [EMAIL PROTECTED] writes:
On Mon, 16 Oct 2006, Thomas Bushnell BSG wrote:
Roman Zippel [EMAIL PROTECTED] writes:
Fixes for problems are too often simply stuck in the BTS now, because in
many cases maintainer simply don't care about m68k support. I often have
to bug
1 - 100 of 228 matches
Mail list logo
