[PATCH]: Fix sparc64 build.

[PATCH]: Fix sparc64 build.

[David Miller]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: Text/Plain; charset=utf-8, Size: 1157 bytes --]


Ingo, didn't we fix this (a few times)? :-)

Linus, please apply:

sparc64: Fix build of timer_interrupt().

arch/sparc/kernel/time_64.c: In function ‘timer_interrupt’:
arch/sparc/kernel/time_64.c:732: error: ‘struct kernel_stat’ has no member named ‘irqs’
make[1]: *** [arch/sparc/kernel/time_64.o] Error 1

Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/arch/sparc/kernel/time_64.c b/arch/sparc/kernel/time_64.c
index 642562d..4ee2e48 100644
--- a/arch/sparc/kernel/time_64.c
+++ b/arch/sparc/kernel/time_64.c
@@ -724,12 +724,14 @@ void timer_interrupt(int irq, struct pt_regs *regs)
 	unsigned long tick_mask = tick_ops->softint_mask;
 	int cpu = smp_processor_id();
 	struct clock_event_device *evt = &per_cpu(sparc64_events, cpu);
+	struct irq_desc *desc;
 
 	clear_softint(tick_mask);
 
 	irq_enter();
 
-	kstat_this_cpu.irqs[0]++;
+	desc = irq_to_desc(0);
+	kstat_incr_irqs_this_cpu(0, desc);
 
 	if (unlikely(!evt->event_handler)) {
 		printk(KERN_WARNING
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH]: Fix sparc64 build.

[Ingo Molnar]

* David Miller <davem@davemloft.net> wrote:

> 
> Ingo, didn't we fix this (a few times)? :-)
> 
> Linus, please apply:
> 
> sparc64: Fix build of timer_interrupt().
> 
> arch/sparc/kernel/time_64.c: In function ‘timer_interrupt’:
> arch/sparc/kernel/time_64.c:732: error: ‘struct kernel_stat’ has no member named ‘irqs’
> make[1]: *** [arch/sparc/kernel/time_64.o] Error 1

Oops, sorry! Note that the fix is in a pending pull request (but 
this still does not make it right that i cut trees with this not in 
it).

I did check sparc for that particular pull request:

  aldebaran:~/linux/linux> ./m-arch-all
  [...]
  testing      sparc:  -git:  pass (   2),  -tip:  pass (   2)

So once the pieces are together again, it should all be fine.

	Ingo

[PATCH]: Fix sparc64 build.

[David Miller]

Please be more careful people.

2009-05-04  David S. Miller  <davem@davemloft.net>

	* conf/sparc64-ieee1275.rmk: Fix build due to missing '\'.

--- conf/sparc64-ieee1275.rmk	(revision 2184)
+++ conf/sparc64-ieee1275.rmk	(revision 2187)
@@ -113,12 +113,12 @@
 	kern/device.c kern/disk.c kern/dl.c kern/elf.c kern/env.c	\
 	kern/err.c kern/file.c kern/fs.c kern/loader.c kern/main.c	\
 	kern/misc.c kern/parser.c kern/partition.c kern/reader.c	\
-	kern/rescue_reader.c kern/rescue_parser.c
+	kern/rescue_reader.c kern/rescue_parser.c			\
 	kern/term.c fs/fshelp.c						\
 	kern/list.c kern/handler.c					\
 	lib/arg.c normal/cmdline.c 					\
 	normal/completion.c		 				\
-	normal/main.c normal/menu.c 			\
+	normal/main.c normal/menu.c 					\
 	normal/menu_text.c						\
 	normal/menu_entry.c normal/menu_viewer.c normal/misc.c 		\
 	normal/color.c							\

[PATCH]: Fix sparc64 build...

[David Miller]

So I finally am about to have enough time to start looking into
sparc64 support again.

And, surprise!  The trunk doesn't even build. :-)

2009-12-03  David S. Miller  <davem@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 +0000
+++ conf/sparc64-ieee1275.rmk	2009-12-03 10:06:44 +0000
@@ -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 +0000
+++ util/sparc64/ieee1275/grub-mkimage.c	2009-12-03 09:59:51 +0000
@@ -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 +0000
+++ util/sparc64/ieee1275/grub-ofpathname.c	2009-12-03 10:06:14 +0000
@@ -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.c	2009-11-25 23:10:02 +0000
+++ util/sparc64/ieee1275/grub-setup.c	2009-12-03 10:04:44 +0000
@@ -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);
 

Re: [PATCH]: Fix sparc64 build...

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 3974 bytes --]

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  <davem@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 +0000
> +++ conf/sparc64-ieee1275.rmk	2009-12-03 10:06:44 +0000
> @@ -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 +0000
> +++ util/sparc64/ieee1275/grub-mkimage.c	2009-12-03 09:59:51 +0000
> @@ -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 +0000
> +++ util/sparc64/ieee1275/grub-ofpathname.c	2009-12-03 10:06:14 +0000
> @@ -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.c	2009-11-25 23:10:02 +0000
> +++ util/sparc64/ieee1275/grub-setup.c	2009-12-03 10:04:44 +0000
> @@ -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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: [PATCH]: Fix sparc64 build...

[David Miller]

From: Vladimir '^[$B&U^[(B-coder/phcoder' Serbinenko <phcoder@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.

Re: [PATCH]: Fix sparc64 build...

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: [PATCH]: Fix sparc64 build...

[David Miller]

From: Vladimir '^[$B&U^[(B-coder/phcoder' Serbinenko <phcoder@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. :-)

Re: [PATCH]: Fix sparc64 build...

[David Miller]

From: Vladimir '^[$B&U^[(B-coder/phcoder' Serbinenko <phcoder@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.)

Re: [PATCH]: Fix sparc64 build...

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]

David Miller wrote:
> From: Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: [PATCH]: Fix sparc64 build...

[David Miller]

From: Vladimir '^[$B&U^[(B-coder/phcoder' Serbinenko <phcoder@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!

Re: [PATCH]: Fix sparc64 build...

[Robert Millan]

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."

Re: [PATCH]: Fix sparc64 build...

[Robert Millan]

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."

Re: [PATCH]: Fix sparc64 build...

[Robert Millan]

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=sparc&pkg=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."

Re: [PATCH]: Fix sparc64 build...

[Robert Millan]

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."

Re: [PATCH]: Fix sparc64 build...

[David Miller]

From: Robert Millan <rmh@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?
:-)

Re: [PATCH]: Fix sparc64 build...

[Felix Zielcke]

Am Freitag, den 04.12.2009, 13:34 -0800 schrieb David Miller:
> From: Robert Millan <rmh@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