ved in getting the porters access to
porter boxes? Porter boxes exist so that DDs *not* involved in a port have
access to a machine of the architecture and can keep their packages working.
I've never heard of a porter who didn't have access to their own box
oving libglitz is more painful than it would be otherwise,
because instead of just rebuilding cairo itself without glitz, you must
rebuild everything above cairo in the stack that used pkg-config for
linking.
I don't argue that this makes --as-needed *correct* as a default
are to use endian.h.
> 2. Confirm 32/64-bit: It is 32-bit, right?
Yes, but why do you need to know this?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED]
gt; > those boxen could test them out and let me know what else needs to be
> > fixed.
> First, there was a theory that "ramdisk_size" is no longer needed with
> 2.6.x kernels. That's wrong, unfortunately:
It's right when using initramfs instead of ramdisk, f
On Mon, Oct 23, 2006 at 01:09:13AM -0500, Manoj Srivastava wrote:
> On Sun, 22 Oct 2006 00:52:59 +0200 (CEST), Michael Schmitz <[EMAIL
> PROTECTED]> said:
> >> On Fri, Oct 20, 2006 at 02:05:37PM -0700, Steve Langasek wrote:
> >> > On Fri, Oct 20, 2006 at 10:58
rtagged bugs as release critical, or :m68k-non-rc as not being
> RC in spite of a serious severity)
The debian-release@lists.debian.org:rc-m68k usertag already exists to track
m68k-specific RC bugs, FWIW.
Cheers,
--
Steve Langasek Give me a lever long enough and a
On Fri, Oct 20, 2006 at 10:58:25PM +0200, Bill Allombert wrote:
> IIRC, the m68k kernels are already cross-compiled.
Yes, which has repeatedly caused problems due to assumptions in the kernel
packaging that host arch == build arch...
--
Steve Langasek Give me a lever l
e.
FWIW, it's my understanding he intends to run aranym on these systems,
thereby making this native building in an emulator rather than
cross-building.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
the release
> criteria either...
Would you feel better about m68k's status if you had arm for company?
Strictly enforcing the release criteria for arm isn't going to get m68k any
closer to being reincluded as an arch candidate.
--
Steve Langasek Give me a lever
ian.org/fetch.cgi?pkg=kaffe;ver=2%3A1.1.7-3;arch=m68k;stamp=1153832010
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debia
t least this
> would allow porter/non-maintainer source uploads.
The 0-day NMU policy promulgated by the release team has as its express
purpose to improve the release-readiness of testing, so m68k-specific fixes
wouldn't be covered by this. But porters are allowed to do NMUs on their
own a
On Fri, Sep 22, 2006 at 12:07:36PM +0200, Roman Zippel wrote:
> On Wed, 20 Sep 2006, Steve Langasek wrote:
> > Moreover, there's the matter that this leaves no time for an archive-wide
> > check for toolchain /regressions/. As we enter the freeze, i386 and amd64
> >
eems like the most sensible solution
for m68k, but all previous attempts have run aground on the interdependency
problem. Perhaps you could suggest a few guidelines you would like to see
used, as a starting point for such a discussion?
--
Steve Langasek Give me a lever long enough
tion with other architectures. m68k was disqualified
because it's not able to keep up with the demands placed on it by package
maintainers.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[E
a
port as possible for etch+1?
Please let the release team know how we can be of assistance to you in
setting and meeting goals for an m68k release, be it for a separate etch
release or for a re-integrated etch+1 release.
--
Steve Langasek Give me a lever long enough and a Free O
might not be thinking too clearly: if that makes
> sense to someone else please schedule a binNMU or agree with the message
> and I'll get it tomorrow.
BinNMU just scheduled on all archs, along with about 90 other packages
depending on dbus.
Cheers,
--
Steve Langasek
On Sun, Jul 09, 2006 at 08:29:39PM -0500, Stephen R Marenka wrote:
> On Sun, Jul 09, 2006 at 01:25:48PM -0700, Steve Langasek wrote:
> > I'd guess the root bug here is that /usr/lib/libc_nonshared.a is being used
> > instead of /lib/libc.so.6?
> Is this due to a change in
efined reference to `__fini_array_end'
> | collect2: ld returned 1 exit status
I'd guess the root bug here is that /usr/lib/libc_nonshared.a is being used
instead of /lib/libc.so.6?
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
chitecture that they can be working on in between getting things back in
line with the release arch standards. As always, porter NMUs are encouraged
-- you don't need an RC bug as an excuse to fix a package for your
architecture! Wouldn't it be great to have zero bugs on that page
bly fast) build machine is probably quicker than having the
maintainer do two (sponsored) uploads if it turns out not to be fixed for
this case.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on,
is to try to upload it ?
My advice would be to discuss it with a member of the ftp team...
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED]
sounds terribly irresponsible to me. If you can't
come to an agreement with the ftp-masters that these files are
distributable, then you shouldn't be distributing them from p.d.o either.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Deve
le.debian.org.
FWIW, I think that asserting that "we" are distributing miboot from
people.debian.org is nothing more than an invitation for someone to ask you
to remove the binaries. But is there actually any reason why miboot can't
be distributed in non-free? If there is, then that
iated.
The release team will continue to monitor the progress of the m68k port. If
you have any questions about where to go from here, please ask us.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set
ternally defined, or is there some other reason that you
can't typedef it to a long instead of to an int?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED]
Package: g++-4.0
Version: 4.0.1-2
Severity: important
jigdo is failing to build with g++-4.0 on m68k with the following error:
g++ $cxx -c util/rsyncsum.cc -o util/rsyncsum.o
/usr/lib/gcc/m68k-linux-gnu/4.0.1/../../../../include/c++/4.0.1/bits/stl_bvector.h:
In member function 'std::_Bit_type*
On Mon, May 16, 2005 at 11:07:17AM +0900, Kenshi Muto wrote:
> At Sun, 15 May 2005 18:26:54 -0700,
> Steve Langasek wrote:
> > It looks like an m68k build of xslideshow 3.1-7 is needed to fix RC bug
> > #264174 in sarge. Would anyone here care to do the honors?
> I just
Hi folks,
It looks like an m68k build of xslideshow 3.1-7 is needed to fix RC bug
#264174 in sarge. Would anyone here care to do the honors?
Thanks,
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
* must meet all policy requirements presented in this manual that
it is possible for them to meet. [1]
[1] It is possible that there are policy requirements which the package is
unable to meet, for example, if the source is unavailable. These
situations will need to be handled on a ca
build
> dh_testdir
> # Add here commands to configure the package.
> xmkmf
> make: xmkmf: Command not found
> make: *** [configure-stamp] Error 127
> The new version in sid fixes this by adding the missing Build-Depends
> on xutils in debian/control.
Non-free package, needs manual
On Sun, Apr 24, 2005 at 12:39:35PM +0200, Christian T. Steigies wrote:
> On Sat, Apr 23, 2005 at 09:42:12PM -0700, Steve Langasek wrote:
> > The newer version of this non-free package is held out of testing by missing
> > m68k and s390. Anyone care to build & upload?
> Bu
> dh_link -a
> dh_dhelp
> make: dh_dhelp: Command not found
> make: *** [binary-arch] Error 127
> The newer version in 'unstable' does not have this problem.
The newer version of this non-free package is held out of testing by missing
m68k and s390. Anyone care to
On Thu, Mar 31, 2005 at 06:33:51PM +0200, Wouter Verhelst wrote:
> On Fri, Mar 25, 2005 at 04:10:58PM -0800, Steve Langasek wrote:
> > Hey folks,
> > buildd.debian.org lists evolution-data-server as building on m68k since Mar
> > 16:
> > gnome/evolution-data-
building (unlikely, since
zot has picked up more packages for building since then), and give it back
if not?
This missing build is currently blocking most GNOME updates that are
currently needed.
Thanks,
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
On Sat, Dec 18, 2004 at 11:19:33AM -0800, Rick Younie wrote:
> Steve Langasek wrote:
> > Would someone on this list be willing to take a look at bug #280003 and help
> > sort out the cause of this build failure on m68k?
> Uploading.
So the build failure was a transient build
Hello,
Would someone on this list be willing to take a look at bug #280003 and help
sort out the cause of this build failure on m68k?
Thanks,
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
daemons; you want to contact
[EMAIL PROTECTED] instead.
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
ers any/all
skew has finally been fixed with the 3.3.3 packages, but until there's
*some* version >= 3:3.3.3-1 in the archive for m68k, all qt-related
packages are unbuildable there because of the pre-existing skew.
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
On Tue, Aug 03, 2004 at 12:06:33AM +0200, Wouter Verhelst wrote:
> On Mon, Aug 02, 2004 at 02:52:41PM -0700, Steve Langasek wrote:
> > This issue warrants opening an RC bug against logrotate, that should be
> > addressed before sarge. There will probably be someone on debian-68k
someone on debian-68k
(cc:ed) who can verify for us whether logrotate does build with gcc-3.4,
leaving only the task of uploading a package to testing-proposed-updates
that does build from source. (For the record, gcc-3.4 will not be a
default compiler on any arch for sarge, so you will need to add
l other architectures, I suspect it might
> be some non-reproducible temporary problem. Is it possible to trigger the
> buildd machine to have another go?
The buildd in question has a stale version of gettext installed. This
bug was fixed in NMU several months ago, but kullervo has apparentl
get your system
to boot by removing the rtc.o module from somewhere in
/lib/modules// -- but I don't remember which rtc module is
which...
Steve Langasek
postmodern programmer
pgpJp2mYlO4sb.pgp
Description: PGP signature
42 matches
Mail list logo
