Re: [PATCH]: Fix sparc64 build...
Am Freitag, den 04.12.2009, 13:34 -0800 schrieb David Miller: From: Robert Millan r...@aybabtu.com Date: Fri, 4 Dec 2009 21:58:25 +0100 On Thu, Dec 03, 2009 at 01:03:09PM -0800, David Miller wrote: Thanks, but I don't feel comfortable enough with bzr yet. I had to struggle just to get things checked out, as the bzr package in Debian stable is too old to use to access to repo. (For the record I disagree with the source control system choosen, and the fact that a common current Linux distribution doesn't even provide a version of the tool necessary to access the repo really convinces me further of that.) For a Lenny system the following should do the trick: echo deb http://backports.org/debian lenny-backports main | sudo tee -a /etc/apt/sources.list gpg --keyserver pgp.mit.edu --recv-keys 16BA136C gpg --export -a 16BA136C | sudo apt-key add - sudo apt-get update sudo apt-get install -t lenny-backports bzr That's not a straightforward and low barrier of entry for new developers who want to simply check out the grub code and start contributing. That's my point. Do you want lots of people involved, or do you want people to have to jump through hoops and go out of their way to get at your tree? Heck, for this reason alone, subversion was a better situation. When squeeze is out we hopefully won't have that problem again that we have to use newer versions then Debian stable. I hope that the bzr repository formats are now enough stable for our use. Mercurial, GIT, or pretty any other distributed source control system would have worked out of the box with the client versions provided in debian stable and other distributions. So, I still believe BZR was a bad choice of a source control system. And how many times have you guys wrecked your repository already? :-) IIRC 3 times, but 2 times was because of the broken bzr-svn used to sync regulary SVN to Bazaar trunk. -- Felix Zielcke Proud Debian Maintainer and GNU GRUB developer ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: Fix sparc64 build...
On Thu, Dec 03, 2009 at 02:17:29AM -0800, David Miller wrote: So I finally am about to have enough time to start looking into sparc64 support again. And, surprise! The trunk doesn't even build. :-) I guess this one's my fault. Must have left it when adding all those progname.c, progname.h and gettext calls everywhere. Glad there's someone watching! :-) -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: Fix sparc64 build...
On Thu, Dec 03, 2009 at 09:22:27PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: You can commit to bzr yourself actually. And unless Robert objects I guess your permission to tangle with sparc parts as you see fit is still valid Of course. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: Fix sparc64 build...
On Thu, Dec 03, 2009 at 12:59:00PM -0800, David Miller wrote: I have about half a year of potential regressions I'm about to discover on sparc64. That's not an acceptable situation, long term. I might get hit by a bus or whatever, so it would be nice if someone other than me were at least testing the code base out on sparc64. That way problems get spotted when they get added, or soon afterwards, not 6 months later like some things are about to. :-) Actually, we have this debian buildd thing regularly testing sparc buildability: https://buildd.debian.org/build.php?arch=sparcpkg=grub2 I assure you we'd have noticed in less than 6 months :-) (though I admit, not as efficiently as you did) -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: Fix sparc64 build...
On Thu, Dec 03, 2009 at 01:03:09PM -0800, David Miller wrote: Thanks, but I don't feel comfortable enough with bzr yet. I had to struggle just to get things checked out, as the bzr package in Debian stable is too old to use to access to repo. (For the record I disagree with the source control system choosen, and the fact that a common current Linux distribution doesn't even provide a version of the tool necessary to access the repo really convinces me further of that.) For a Lenny system the following should do the trick: echo deb http://backports.org/debian lenny-backports main | sudo tee -a /etc/apt/sources.list gpg --keyserver pgp.mit.edu --recv-keys 16BA136C gpg --export -a 16BA136C | sudo apt-key add - sudo apt-get update sudo apt-get install -t lenny-backports bzr -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: Fix sparc64 build...
From: Robert Millan r...@aybabtu.com Date: Fri, 4 Dec 2009 21:58:25 +0100 On Thu, Dec 03, 2009 at 01:03:09PM -0800, David Miller wrote: Thanks, but I don't feel comfortable enough with bzr yet. I had to struggle just to get things checked out, as the bzr package in Debian stable is too old to use to access to repo. (For the record I disagree with the source control system choosen, and the fact that a common current Linux distribution doesn't even provide a version of the tool necessary to access the repo really convinces me further of that.) For a Lenny system the following should do the trick: echo deb http://backports.org/debian lenny-backports main | sudo tee -a /etc/apt/sources.list gpg --keyserver pgp.mit.edu --recv-keys 16BA136C gpg --export -a 16BA136C | sudo apt-key add - sudo apt-get update sudo apt-get install -t lenny-backports bzr That's not a straightforward and low barrier of entry for new developers who want to simply check out the grub code and start contributing. That's my point. Do you want lots of people involved, or do you want people to have to jump through hoops and go out of their way to get at your tree? Heck, for this reason alone, subversion was a better situation. Mercurial, GIT, or pretty any other distributed source control system would have worked out of the box with the client versions provided in debian stable and other distributions. So, I still believe BZR was a bad choice of a source control system. And how many times have you guys wrecked your repository already? :-) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: Fix sparc64 build...
Hello, nice to see you again.
David Miller wrote:
So I finally am about to have enough time to start looking into
sparc64 support again.
And, surprise! The trunk doesn't even build. :-)
Committed. BTW in experimental we merged sparc64's and i386's
grub-install. Do you think it would make sense to merge some other tools
as well?
2009-12-03 David S. Miller da...@sunset.davemloft.net
* conf/sparc64-ieee1275.rmk (grub_mkimage_SOURCES,
grub_setup_SOURCES, grub_ofpathname_SOURCES): Add gnulib/progname.c
* util/sparc64/ieee1275/grub-mkimage.c: Include grub/i18n.h and
progname.h
* util/sparc64/ieee1275/grub-ofpathname.c: Likewise.
* util/sparc64/ieee1275/grub-setup.c: Likewise.
(usage): Add missing comma in printf.
=== modified file 'conf/sparc64-ieee1275.rmk'
--- conf/sparc64-ieee1275.rmk 2009-11-26 00:45:53 +
+++ conf/sparc64-ieee1275.rmk 2009-12-03 10:06:44 +
@@ -63,7 +63,7 @@
# For grub-mkimage.
grub_mkimage_SOURCES = util/sparc64/ieee1275/grub-mkimage.c util/misc.c \
-util/resolve.c
+util/resolve.c gnulib/progname.c
# For grub-setup.
util/sparc64/ieee1275/grub-setup.c_DEPENDENCIES = grub_setup_init.h
@@ -82,12 +82,12 @@
partmap/sun.c partmap/acorn.c \
\
disk/raid.c disk/mdraid_linux.c disk/lvm.c \
- util/raid.c util/lvm.c \
+ util/raid.c util/lvm.c gnulib/progname.c\
grub_setup_init.c
# For grub-ofpathname.
grub_ofpathname_SOURCES = util/sparc64/ieee1275/grub-ofpathname.c \
- util/ieee1275/ofpath.c util/misc.c
+ util/ieee1275/ofpath.c util/misc.c gnulib/progname.c
# Scripts.
sbin_SCRIPTS = grub-install
=== modified file 'util/sparc64/ieee1275/grub-mkimage.c'
--- util/sparc64/ieee1275/grub-mkimage.c 2009-11-25 23:10:02 +
+++ util/sparc64/ieee1275/grub-mkimage.c 2009-12-03 09:59:51 +
@@ -21,6 +21,7 @@
#include grub/machine/boot.h
#include grub/machine/kernel.h
#include grub/kernel.h
+#include grub/i18n.h
#include grub/disk.h
#include grub/util/misc.h
#include grub/util/resolve.h
@@ -34,6 +35,8 @@
#define _GNU_SOURCE 1
#include getopt.h
+#include progname.h
+
static void
compress_kernel (char *kernel_img, size_t kernel_size,
char **core_img, size_t *core_size)
=== modified file 'util/sparc64/ieee1275/grub-ofpathname.c'
--- util/sparc64/ieee1275/grub-ofpathname.c 2009-11-25 23:10:02 +
+++ util/sparc64/ieee1275/grub-ofpathname.c 2009-12-03 10:06:14 +
@@ -20,6 +20,10 @@
#include grub/util/misc.h
#include grub/util/ofpath.h
+#include grub/i18n.h
+
+#include progname.h
+
int main(int argc, char **argv)
{
char *of_path;
=== modified file 'util/sparc64/ieee1275/grub-setup.c'
--- util/sparc64/ieee1275/grub-setup.c2009-11-25 23:10:02 +
+++ util/sparc64/ieee1275/grub-setup.c2009-12-03 10:04:44 +
@@ -21,6 +21,7 @@
#include grub/types.h
#include grub/util/misc.h
#include grub/device.h
+#include grub/i18n.h
#include grub/disk.h
#include grub/file.h
#include grub/fs.h
@@ -49,6 +50,8 @@
#define _GNU_SOURCE 1
#include getopt.h
+#include progname.h
+
/* This program fills in various fields inside of the 'boot' and 'core'
* image files.
*
@@ -419,7 +422,7 @@
-v, --verbose print verbose messages\n\
\n\
Report bugs to %s.\n\
-, program_name
+, program_name,
DEFAULT_BOOT_FILE, DEFAULT_CORE_FILE, DEFAULT_DIRECTORY,
DEFAULT_DEVICE_MAP, PACKAGE_BUGREPORT);
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: Fix sparc64 build...
From: Vladimir '$BU(B-coder/phcoder' Serbinenko phco...@gmail.com Date: Thu, 03 Dec 2009 12:26:05 +0100 Hello, nice to see you again. David Miller wrote: So I finally am about to have enough time to start looking into sparc64 support again. And, surprise! The trunk doesn't even build. :-) Committed. Thanks. BTW in experimental we merged sparc64's and i386's grub-install. Do you think it would make sense to merge some other tools as well? Maybe. I made a lot of changes when I cribbed the i386 versions, and made some cleanups as well, but some portions should be sharable. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: Fix sparc64 build...
David Miller wrote: Committed. Thanks. You can commit to bzr yourself actually. And unless Robert objects I guess your permission to tangle with sparc parts as you see fit is still valid BTW in experimental we merged sparc64's and i386's grub-install. Do you think it would make sense to merge some other tools as well? Maybe. I made a lot of changes when I cribbed the i386 versions, and made some cleanups as well, but some portions should be sharable. For me the main reason for or against it is break probability. Merging will avoid stupid breakages like ones you fixed but may introduce more subtle ones -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: Fix sparc64 build...
From: Vladimir '$BU(B-coder/phcoder' Serbinenko phco...@gmail.com Date: Thu, 03 Dec 2009 21:22:27 +0100 For me the main reason for or against it is break probability. Merging will avoid stupid breakages like ones you fixed but may introduce more subtle ones You lack a cross-build environment? I test build the Linux kernel for about 4 or 5 platforms, all on the same computer. And also as we've seen, keeping the build working doesn't keep bugs from creeping in. Someone just needs to actively build and install test the tree on the given platform if you really want to avoid problems. I have about half a year of potential regressions I'm about to discover on sparc64. That's not an acceptable situation, long term. I might get hit by a bus or whatever, so it would be nice if someone other than me were at least testing the code base out on sparc64. That way problems get spotted when they get added, or soon afterwards, not 6 months later like some things are about to. :-) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: Fix sparc64 build...
From: Vladimir '$BU(B-coder/phcoder' Serbinenko phco...@gmail.com Date: Thu, 03 Dec 2009 21:22:27 +0100 David Miller wrote: Committed. Thanks. You can commit to bzr yourself actually. And unless Robert objects I guess your permission to tangle with sparc parts as you see fit is still valid Thanks, but I don't feel comfortable enough with bzr yet. I had to struggle just to get things checked out, as the bzr package in Debian stable is too old to use to access to repo. (For the record I disagree with the source control system choosen, and the fact that a common current Linux distribution doesn't even provide a version of the tool necessary to access the repo really convinces me further of that.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: Fix sparc64 build...
David Miller wrote: From: Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com Date: Thu, 03 Dec 2009 21:22:27 +0100 For me the main reason for or against it is break probability. Merging will avoid stupid breakages like ones you fixed but may introduce more subtle ones You lack a cross-build environment? I have only cross-build environment for ppc and mipsel. I installed sparc cross-toolchain from emdebian but apparently it's not enough to build grub-sparc. I was actually thinking that grub2-sparc was uploaded to debian and so at least compile-tested. I test build the Linux kernel for about 4 or 5 platforms, all on the same computer. And also as we've seen, keeping the build working doesn't keep bugs from creeping in. Someone just needs to actively build and install test the tree on the given platform if you really want to avoid problems. I have about half a year of potential regressions I'm about to discover on sparc64. That's not an acceptable situation, long term. I might get hit by a bus or whatever, so it would be nice if someone other than me were at least testing the code base out on sparc64. That way problems get spotted when they get added, or soon afterwards, not 6 months later like some things are about to. :-) The problem is that nobody of us has such hardware. I would happily do a sparc boot every 2 weeks but I just don't have a sparc -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH]: Fix sparc64 build...
From: Vladimir '$BU(B-coder/phcoder' Serbinenko phco...@gmail.com Date: Thu, 03 Dec 2009 22:56:34 +0100 The problem is that nobody of us has such hardware. I would happily do a sparc boot every 2 weeks but I just don't have a sparc You can get an Ultra5 for ~$100.00 USD on EBAY :-) Anyways, no matter, I'm about to start working to get grub2 functional again at least on a few of my machines. Thanks! ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
