Re: BTS for GRUB 2 (Re: BTS overhaul)
Robert Millan wrote: The creature has been seized: http://savannah.gnu.org/bugs/?group=grub I've left the bugs that apply to documentation since we'll probably reuse much of GRUB Legacy's and they will still apply. Finally the BTS is usable for keeping track of GRUB 2 stuff. Two thoughts: - The website still prompts to send GRUB 2 queries to grub-devel, should we adjust that to make them use the BTS? Yes. And for grub legacy users (and version info what is grub legacy) there should be note that these are no longer being processed or something like that. - The BTS sends bug notifications to bug-grub. Rather than moving those to this list, perhaps it'd be a good idea to claim bug-grub for GRUB 2 (and move GRUB Legacy queries to /dev/full), so that bug tracking (which tends to be quite verbose) is separate and this list can be used for general discussion more confortably. What do you think? I think now would be good spot to re-configure mailing lists :) bug-grub@ sounds like a bug list. grub-devel@ sound link a development list. grub-help@ or grub-users@ would be more fit for user discussions. Are there any GNU standards for these? And perhaps require to switch to subscribe only lists. I think it is important to get notification about new bugs, so some feedback is needed, but this does not necessary need to be discussion list. I think that this is like commit-grub list is for information about changes in reposity. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: BTS for GRUB 2 (Re: BTS overhaul)
On Sun, Dec 16, 2007 at 12:27:03PM +0200, Vesa Jääskeläinen wrote: Robert Millan wrote: The creature has been seized: http://savannah.gnu.org/bugs/?group=grub I've left the bugs that apply to documentation since we'll probably reuse much of GRUB Legacy's and they will still apply. Finally the BTS is usable for keeping track of GRUB 2 stuff. Two thoughts: - The website still prompts to send GRUB 2 queries to grub-devel, should we adjust that to make them use the BTS? Yes. And for grub legacy users (and version info what is grub legacy) there should be note that these are no longer being processed or something like that. Ok then. I suggest that we move grub-legacy-bugs.en.html to grub-2-bugs.en.html, and create a new grub-legacy-bugs.en.html prompting reporters to try reproduce their problem in GRUB 2 (if they have a problem) or update their patches to GRUB 2. - The BTS sends bug notifications to bug-grub. Rather than moving those to this list, perhaps it'd be a good idea to claim bug-grub for GRUB 2 (and move GRUB Legacy queries to /dev/full), so that bug tracking (which tends to be quite verbose) is separate and this list can be used for general discussion more confortably. What do you think? I think now would be good spot to re-configure mailing lists :) bug-grub@ sounds like a bug list. grub-devel@ sound link a development list. Good. I'm subscribing to bug-grub then. Another question is, how will we do context reply for patches? The BTS doesn't seem to easily allow this. Maybe we could followup on our replies via bug-grub ? But a problem with that is that it'll be hard to see the full context of a discussion when browsing bugs. Another problem is that submitter is likely not subscribed to bug-grub (does the message you get when trying to write there without being subscribed say you have to subscribe, or that you have to wait for someone to process your mail (which won't happen) ?). grub-help@ or grub-users@ would be more fit for user discussions. Are there any GNU standards for these? And perhaps require to switch to subscribe only lists. The convention in GNU projects is to call them help-$project. -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
On Sun, Dec 16, 2007 at 02:32:29AM -0200, Otavio Salvador wrote: Robert Millan [EMAIL PROTECTED] writes: So it seems nobody objected. What do we need to proceed? Prepare a file with authors names to be used during the conversion and a run to git-cvsimport using it? :-) I mean in the context of Savannah. -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: BTS for GRUB 2 (Re: BTS overhaul)
On Sun, Dec 16, 2007 at 12:02:35PM +0100, Robert Millan wrote: - The website still prompts to send GRUB 2 queries to grub-devel, should we adjust that to make them use the BTS? Yes. And for grub legacy users (and version info what is grub legacy) there should be note that these are no longer being processed or something like that. Ok then. I suggest that we move grub-legacy-bugs.en.html to grub-2-bugs.en.html, and create a new grub-legacy-bugs.en.html prompting reporters to try reproduce their problem in GRUB 2 (if they have a problem) or update their patches to GRUB 2. I propose the attached patch. Don't pay much attention to the grub-2-bugs.en.html part; it's simply copiing what we had in grub-legacy-bugs.en.html with a s/Legacy/2/g in the title. -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call, if you are unable to speak? (as seen on /.) Index: grub-2-bugs.en.html === RCS file: /web/grub/grub/grub-2-bugs.en.html,v retrieving revision 1.14 diff -u -p -r1.14 grub-2-bugs.en.html --- grub-2-bugs.en.html 4 Jun 2006 17:04:46 - 1.14 +++ grub-2-bugs.en.html 16 Dec 2007 11:12:31 - @@ -8,7 +8,7 @@ link rel=stylesheet type=text/css href=grub.css media=screen title=grub css / link rel=stylesheet type=text/css href=print.css media=print / -titleGNU GRUB - Bug Reports/title +titleGNU GRUB - GRUB 2 Bugs/title /head body div id=wrap @@ -47,12 +47,49 @@ media=screen title=grub css / div id=content !-- end header -- + h1Bug Reports/h1 -p -GRUB 2 is under very active development, so bugs are handled in the -developers' list grub-devel@gnu.org at the moment. Since this list is -a members-only list, please subscribe to it then send e-mail to this -list. + +P +NOTE: For general information on how to report bugs, +A HREF=http://www.chiark.greenend.org.uk/~sgtatham/bugs.html;How to +Report Bugs Effectively/A +is worth reading. +/P + +P +When you encounter a problem or a bug, check if the +A HREF=http://savannah.gnu.org/bugs/?group=grub;Bug Tracking System/A +stores the same problem. +Also, take a look at the A HREF=grub-faq.en.htmlGNU GRUB FAQ/A. +This may have a useful suggestion about your problem. +/P + +P +If you didn't find information about your problem, read the chapter +EMReporting bugs/EM in A HREF=/software/grub/manual/the manual/A. +Very often, people ask us their questions with little or even no +information about their systems. That's quite useless, because we have +to EMguess/EM what you did, what was displayed and what really +happened. Please notice that we may not see your computer directly. So, +whenever you report a bug, you must include enough information so that +we can understand what happened and even reproduce your problem in our +own machines. + +/P + +P +Once you have realized how to write a bug report, please submit it to the +A HREF=http://savannah.gnu.org/bugs/?group=grub;Bug Tracking System/A +with information about your computer and what you did +EMas much as possible/EM. Excessive information is always better than +no information. +/P + +P +If you prefer using electronic mail, you can submit a report to the mailing +list lt;[EMAIL PROTECTED]gt;. +/P Index: grub-legacy-bugs.en.html === RCS file: /web/grub/grub/grub-legacy-bugs.en.html,v retrieving revision 1.13 diff -u -p -r1.13 grub-legacy-bugs.en.html --- grub-legacy-bugs.en.html 4 Jun 2006 17:04:46 - 1.13 +++ grub-legacy-bugs.en.html 16 Dec 2007 11:12:31 - @@ -51,48 +51,16 @@ media=screen title=grub css / h1Bug Reports/h1 P -NOTE: For general information on how to report bugs, -A HREF=http://www.chiark.greenend.org.uk/~sgtatham/bugs.html;How to -Report Bugs Effectively/A -is worth reading. +Support for filing bug reports on GRUB Legacy has been discontinued. Please, check +if you can reproduce your problem with GRUB 2, or if the feature you want is already +present in GRUB 2. Then report it as a a href=grub-2-bugs.en.htmlGRUB 2 bug/a +if it still applies. /P P -When you encounter a problem or a bug, check if the -A HREF=http://savannah.gnu.org/bugs/?group=grub;Bug Tracking System/A -stores the same problem. -Also, take a look at the A HREF=grub-faq.en.htmlGNU GRUB FAQ/A. -This may have a useful suggestion about your problem. +Additionally, if you were providing a patch please update it to work on GRUB 2. /P -P -If you didn't find information about your problem, read the chapter -EMReporting bugs/EM in A HREF=/software/grub/manual/the manual/A. -Very often, people ask us their questions with little or even no -information about their systems. That's quite useless, because we have -to EMguess/EM what you did, what was displayed and what really -happened. Please notice that we may not see your computer directly. So, -whenever you report a bug, you must include enough information so that -we can
Re: [PATCH] Use linker script to remove unnecessary sections
On Fri, Dec 14, 2007 at 08:11:36PM +0800, Bean wrote: Hi, This patch use customized linker script to build *.img and *.mod files, it should remove unnecessary sections created by the compiler. 2007-12-14 Bean [EMAIL PROTECTED] * conf/i386-pc.rmk (COMMON_LDFLAGS): Use ldscript to link. * aclocal.m4 (grub_PROG_OBJCOPY_ABSOLUTE): Test ldscript. * configure.ac : Remove the '--build-id=none' flag. This probably breaks other targets than i386-pc. linuxbios and ieee1275 both use ELF. -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: BTS for GRUB 2 (Re: BTS overhaul)
Robert Millan wrote: On Sun, Dec 16, 2007 at 12:02:35PM +0100, Robert Millan wrote: - The website still prompts to send GRUB 2 queries to grub-devel, should we adjust that to make them use the BTS? Yes. And for grub legacy users (and version info what is grub legacy) there should be note that these are no longer being processed or something like that. Ok then. I suggest that we move grub-legacy-bugs.en.html to grub-2-bugs.en.html, and create a new grub-legacy-bugs.en.html prompting reporters to try reproduce their problem in GRUB 2 (if they have a problem) or update their patches to GRUB 2. I propose the attached patch. Don't pay much attention to the grub-2-bugs.en.html part; it's simply copiing what we had in grub-legacy-bugs.en.html with a s/Legacy/2/g in the title. There is also this page that needs a change: https://savannah.gnu.org/bugs/?func=additemgroup=grub ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
moving ata initialisation to a command
I'd like to move ata.mod initialisation away from its _init routine and into a separate command. This way it isn't a nuissance when it gets included in monolithic builds (such as the ones made by grub-mkrescue) and disables biosdisk completely. Does that sound fine? -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: moving ata initialisation to a command
Robert Millan wrote: I'd like to move ata.mod initialisation away from its _init routine and into a separate command. This way it isn't a nuissance when it gets included in monolithic builds (such as the ones made by grub-mkrescue) and disables biosdisk completely. Does that sound fine? While you are there why not add optional IO-base argument so one could use more than one controller lurking in other IO-bases (second/third PCI ?). Of course there needs to be some kind of auto detect for easier usage for normal users. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: BTS for GRUB 2 (Re: BTS overhaul)
On Sun, Dec 16, 2007 at 01:22:44PM +0200, Vesa Jääskeläinen wrote: Robert Millan wrote: On Sun, Dec 16, 2007 at 12:02:35PM +0100, Robert Millan wrote: - The website still prompts to send GRUB 2 queries to grub-devel, should we adjust that to make them use the BTS? Yes. And for grub legacy users (and version info what is grub legacy) there should be note that these are no longer being processed or something like that. Ok then. I suggest that we move grub-legacy-bugs.en.html to grub-2-bugs.en.html, and create a new grub-legacy-bugs.en.html prompting reporters to try reproduce their problem in GRUB 2 (if they have a problem) or update their patches to GRUB 2. I propose the attached patch. Don't pay much attention to the grub-2-bugs.en.html part; it's simply copiing what we had in grub-legacy-bugs.en.html with a s/Legacy/2/g in the title. Committed. There is also this page that needs a change: https://savannah.gnu.org/bugs/?func=additemgroup=grub Marco fixed that. -- Robert Millan GPLv2 I know my rights; I want my phone call! DRM What use is a phone call, if you are unable to speak? (as seen on /.) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
Quoting Robert Millan [EMAIL PROTECTED]: On Sun, Dec 16, 2007 at 02:32:29AM -0200, Otavio Salvador wrote: Robert Millan [EMAIL PROTECTED] writes: So it seems nobody objected. What do we need to proceed? Prepare a file with authors names to be used during the conversion and a run to git-cvsimport using it? :-) I mean in the context of Savannah. This page has the necessary information: http://savannah.gnu.org/maintenance/UsingGit You'll probably need to enable Git support on Savannah first (I don't see it mentioned, but it should be easy), just to make sure it's OK and you have the necessary permissions. Next step is the conversion. That page tells how to get the CVS repository from Savannah. I would probably use git-cvsimport from the latest git for the conversion. Or maybe I would try parsecvs as well and check the results. It's very important to verify the repository with gitk and qgit. Then push the repository to Savannah as described. Make sure you can check out. If you have anything to commit and push, check it too (maybe some documentation change mentioning git). Once everything is working, disable CVS support for the project. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: BTS overhaul
On Sat, Dec 15, 2007 at 02:14:30PM +0100, Marco Gerards wrote: No, the reaction to from Okuji was that if we have a bugtracker, it needs to be available. So if one of us sets up a bugtracker, we have no guarantee about availability. With savannah we have this. Well, Savannah isn't free of downtimes or problems. I mean, there are community development places like Savannah, Gna! or Alioth only based on trac. But don't make me wrong, I'm not personally interested in this at all, I was just making sure the suggestion did get to the right people. Now that tne BTS is clean, I guess it'll be good enough. -- Jordi Mallach Pérez -- Debian developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.sindominio.net/ GnuPG public key information available at http://oskuro.net/ ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Use linker script to remove unnecessary sections
Robert Millan wrote: On Sun, Dec 16, 2007 at 11:29:31AM -0500, Pavel Roskin wrote: I agree that we should avoid naming highly target-specific linker scripts in a generic way. i386-pc.ld might be a better name. or i386/pc/ld (more consistent with the rest of grub) or i386/pc/img.ld (ld script to produce .img files). Should this dir structure reside in conf ? This scheme is not yet used for the *mk files in this directory. Christian ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Grub on x86_64 crash?
by http://cross-lfs.org/view/svn/x86_64-64/boot/building-a-bootloader.html: On x86 and x86_64 (multilib) architectures, the preferred bootloader is GRUB. Unfortunately, GRUB doesn't work on x86_64 Pure64 - the stage2 files can be correctly built as 32-bit, but the grub shell is a 64-bit program, and tries to execute some of the stage2 routines - this results in a segmentation fault. Therefore, in the final system we use Lilo as the bootloader. How is it going on now? ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
On Saturday 15 December 2007 11:54, Robert Millan wrote: So it seems nobody objected. What do we need to proceed? I do object. Personally, I believe that git is inferior to other modern version control systems, thus I don't want to move. If we do, I prefer to go with something better. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: BTS for GRUB 2 (Re: BTS overhaul)
On Sunday 16 December 2007 11:27, Vesa Jääskeläinen wrote: grub-help@ or grub-users@ would be more fit for user discussions. Are there any GNU standards for these? And perhaps require to switch to subscribe only lists. This might be the third time to say this, but... help-grub is already effective. For now, it is just an alias to bug-grub. But I can request the sysadmin to make a separate one, if necessary. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: BTS for GRUB 2 (Re: BTS overhaul)
On Sunday 16 December 2007 12:02, Robert Millan wrote: Another question is, how will we do context reply for patches? The BTS doesn't seem to easily allow this. Maybe we could followup on our replies via bug-grub ? But a problem with that is that it'll be hard to see the full context of a discussion when browsing bugs. This was exactly what I didn't like with (most) bug trackers... Does the Patch Tracker provide any useful feature to this? When I looked at this, it was no different from the Bug Tracker, so I simply disabled it. But this was some years ago. Another problem is that submitter is likely not subscribed to bug-grub (does the message you get when trying to write there without being subscribed say you have to subscribe, or that you have to wait for someone to process your mail (which won't happen) ?). It might be possible to configure the mailman to push through email from savannah. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
