On Tue, 2008-10-07 at 13:35 +0200, Michael Meskes wrote:
> After offending Thomas by NMUing lilypond without correctly following the NMU
> rules which I feel sorry about, I'd still like to ask you to unblock lilypond
> because my NMU fixed a release goal bug (one of the last open double-build
> bug
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
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 upload
On Sun, 2008-10-05 at 10:24 +0200, Pierre Habouzit wrote:
> On Fri, Oct 03, 2008 at 04:59:03PM +0000, 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 mainta
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 rele
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 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
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 newp
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 EN
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 responsibilit
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]:
> | T
On Thu, 2008-09-11 at 23:44 -0700, Steve Langasek wrote:
> Hi Thomas,
>
> On Thu, Aug 28, 2008 at 11:32:49PM -0700, Thomas Bushnell BSG wrote:
> > Please allow gnucash 2.2.6-2 into testing; this has a minimally invasive
> > patch to avoid a dangerous data-loss bug in
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 er
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 b
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 invol
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
> >
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
> >
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 i
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 releas
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. F
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]
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) /
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 rath
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,
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,
On Sun, 2008-02-10 at 19:58 +0100, Pierre Habouzit wrote:
> On Sun, Feb 10, 2008 at 06:16:44PM +0000, Thomas Bushnell BSG wrote:
> > Dash has a serious bug which is causing grief.
> >
> > [ strip whining ]
>
> > Alas, dash does change the syntax of the command
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 *p
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]
I've already uploaded a new gnucash package, but for the other packages
which depend on libofx, can binNMUs please be scheduled so that libofx3
can be removed from unstable?
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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
> &g
On Tue, 2008-01-15 at 10:34 +0100, Pierre Habouzit wrote:
> On Tue, Jan 15, 2008 at 01:10:26AM +0000, 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 th
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 upstrea
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 sa
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 versi
On Sun, 2007-01-21 at 04:20 -0800, Steve Langasek wrote:
> On Wed, Jan 17, 2007 at 02:55:30PM -0800, Thomas Bushnell BSG wrote:
> > 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
> >
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 pre
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.
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
signa
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,
On Thu, 2007-01-11 at 13:13 +0100, Loïc Minier wrote:
> I think you looked at the experimental uploads. I certainly didn't
> upload with "UNRELEASED" as the target dist and it certainly would be
> rejected by our archive software.
I was looking at the master changelog on packages.qa.debian.org
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 packages,
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 li
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
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 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
> >> i
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 gnu
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
--- Begin Message ---
On Fri, 2006-12-29 at 10:42 -0800, Thomas Bushnell BSG wrote:
> gnucash crea
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: 2.0.2-2
> Current version: 2.0.2-2.1
Is it customary to hint packages into testing without even contacting
the
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
> > >
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 transit
On Fri, 2006-12-29 at 20:11 +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. If our priority is the
> > *rele
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
> >
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 uses these key files or has changed away from the keys
with embedded spaces.
I have asked gnucash upstream for their thoughts on the long-term
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
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 th
On Thu, 2006-12-28 at 18:14 -0800, Steve Langasek wrote:
> > What about users who are depending on Python 2.3? Do they just lose?
>
> Users who depend on obsolete software always lose when the bar moves. I
> don't find that a compelling reason to keep python2.3 around for another
> release cycle
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 righ
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 behavi
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 l
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
> > reg
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 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 f
On Wed, 2006-12-27 at 13:31 +0100, Andreas Barth wrote:
> You mean they changed the ABI without an soname change? That sounds
> really bad, yes.
They changed what counts as valid input in a certain case, perhaps
accidentally, perhaps on purpose.
Thomas
signature.asc
Description: This is a digi
On Wed, 2006-12-27 at 09:36 +, Marc 'HE' Brockschmidt wrote:
> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> > Why are new upstream releases being added to upstable of the glib2.0
> > package? We are in a freeze, I thought.
>
> Yes, but the new glib
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 includi
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
> &
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
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 lib
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 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 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 (
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 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
>
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 r
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 part
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
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 t
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
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 "n
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 tran
On Tue, 2006-12-12 at 08:38 +0100, Frank Küster wrote:
> I would like to start a mass bug filing (not yet discussed on -devel,
> severity non-RC) on packages that depend on teTeX without an alternative
> TeXlive dependency. This is mainly targetted at lenny, but I would also
> like to encourage pe
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 wo
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
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 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'
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 b
On Sat, 2006-12-02 at 22:45 -0800, Russ Allbery wrote:
> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
>
> > It would be better to have a halfway modern lilypond on 32-bit archs and
> > nothing at all on 64-bit archs, than to have a medieval lilypond of
> > the
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 be
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 be
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 bes
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, as
On Sat, 2006-11-25 at 07:17 -0800, Steve Langasek wrote:
> Because lilypond 2.8.7 build-depends on guile-1.8, and lilypond *was*
> previously built on these architectures where guile-1.8 is unavailable.
>
> That still doesn't make 396119 release-critical. It does make it a bug that
> has to be re
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
>
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
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.
There is one more release in the 2.8 cycle, 2.8.8, which I have not
packaged.
Also, there is now 2.10.0, which I have packaged, but not upl
On Thu, 2006-11-16 at 16:31 -0800, Steve Langasek wrote:
>
> dash should work; posh is not required to work because nobody uses it as a
> production /bin/sh.
>
> Those are the only three shells I know about that are even an issue, so I
> can't specify beyond that -- and I'm not going to offer any
1 - 100 of 278 matches
Mail list logo
