Re: Data loss at savannah.gnu.org
Vladimir 'phcoder' Serbinenko phco...@gmail.com writes: I say we should go for git. It would safeguard us from possible future problems with savannah as we can easily switch between different git mirrors. Additionally the main argument not to switch to git was that it doesn't give much benefit considering the effort. Now when it's more effort to have a complete svn rather than git I think git is better solution +1 :-) -- O T A V I OS A L V A D O R - E-mail: ota...@debian.org UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug#461442: detection of other OSes in update-grub
Fabian Greffrath [EMAIL PROTECTED] writes: Robert Millan schrieb: Suggestions? For the time being I could duplicate the convert() function from Debian's grub-installer to convert the device names. It could be nice so it could be tested on Debian while it's not accepted upstream. However, I believe that there are plenty of cases in which you could use a generic device name conversion tool... Sure but at least we can try it now and keep working in upstream to remove this change. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub Change HELP***
[EMAIL PROTECTED] writes: I tried this code, but I have some errors, I define the variable but didn't resolve, the people of the clevo notebook make the especial BIOS to me,and I need get this value and make the logical comparation!!! Could you help me? Don't me alone with this problem. I already said before, If necessary I will pay, It's very important to my company resolve this situation. My time is over now. You want it to provide a boot on for the recover partition? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug#461442: please add support for os-prober to detect other OSes in update-grub
Fabian Greffrath [EMAIL PROTECTED] writes: At the moment there is still one problem left: os-prober returns the partition on which it finds the OS as a system device name, e.g. /dev/hda2. At the moment, GRUB does not provide an (easy) way to translate these into GRUB drives, e.g. (hd0,1). This is why I allready requested such a feature on this list [2]. Another problem (or: missing feature) is, that at the moment my script can only add chainloaded OSes to grub.cfg. To add kernels like Linux or HURD it is necessary to mount these partitions again to find out exactly where the kernel and initrd images reside. This is something I want to avoid, because the partitions have allready been mounted by os-prober and I don't want to duplicate it's code for this purpose. Maybe os-prober could be modified to be more verbose in such cases and report the entire path to the images. os-prober is developed inside Debian Installer team. I think it's two different but reports and then it would be nice to report a specific bug (maybe with a proposed patch) for os-prober to provide what you'd need and then we can push it. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
Jeroen Dekkers [EMAIL PROTECTED] writes: At Sat, 22 Dec 2007 09:28:28 +0100, Yoshinori K. Okuji wrote: On Tuesday 18 December 2007 13:05, Otavio Salvador wrote: Personally I don't like bazaar due performance problem. It's really slow for big projects (it wouldn't be a big problem since GRUB is a small one) and it changes its data format too ofthen. Hmm, I thought they have fixed the performance issues already? About the data format, I have no idea. jbailey, do you have any comment? ;) I've used bzr when working on my summer of code project 1.5 years ago and didn't have any issues with performance. And this was before they did all the performance improvements. Maybe with big source trees like Linux it's still too slow, but for GRUB this is really no problem. I'm not talking about working locally (looks like this is what you've done) but pulling and pushing changes remotely. The changes in data format shouldn't really be any problem in practice, because newer versions can still read the older disk format and the network protocol doesn't change most of the time. I think it's. If you want to gain their performance improvements you _need_ to upgrade. So _all_ people involved will need to have the need version installed too. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
Yoshinori K. Okuji [EMAIL PROTECTED] writes: On Tuesday 18 December 2007 02:20, Pavel Roskin wrote: If there are any specific problems with git pertinent to GRUB or preferences of the GRUB developers, I'm ready to convey them to the git developers and take the blame (if any). We don't have to look for the best tool, just for the best tool for this particular project and those working on it. I bet that you under-estimate the pain of migrating to another SCM. I have experienced such migrations twice, and they were always a pain, something that nobody wants to repeat. I experienced such migrations a lot of times and have moved projects from: - CVS - SVN - SVN - Bzr - SVN - GIT - CVS - Darcs And others too. - All developers are forced to install new software and learn it (always a pain). Developers are used (or ought to) to learn new things since it's of programming art. I guess learning wouldn't be a problem. - All local (pending) changes in working copies become very hard to merge (extremely painful). Just a cvs diff /tmp/foo ; cd ~/newrepo ; patch -p1 /tmp/foo works for most of cases and then it's not a really big problem from my POV. - It is hard to re-select yet another SCM later, because old software is usually better supported for migrations, i.e. it's not cheap to migrate back and forth (very painful). I guess nobody wants to come back to CVS after getting out from it. First of all, this is not a hurry at all. CVS is far from nice, but it has worked well for GRUB for the past 10 years, and we haven't had any critical problem with it. This is because GRUB is a very simple project from the viewpoint of source code management. Sure it's. But all developers want to use more time working on code then dealing with the bad merging of CVS and dealing with cvsps to identify when something has been fixed and like. You might be excited with technical innovations, but please don't forget that it costs to change things. Note that I don't mean that we should't change, but that we must be a bit more conservative with regard to SCM. Since we are not developing SCM itself, we should consider carefully pros and cons, before making an action. Agree on that. However since git does offer a CVS server this can be reduced a lot allowing you and anyother that don't want to move to it to stay using CVS for hacking. Ok, now about the git. As Tomáš pointed out, the lack of portability is regression from CVS. If you think, for example, grub4dos is important, why can you choose git? Agree on that too. It's not that bad[1] and users can use git with cygwin or via git-cvspserver. 1. http://git.or.cz/gitwiki/WindowsInstall Besides the portability, I don't like the merging algorithm. If my knowledge is not completely outdated yet, git still uses 3-way merging, right? I don't describe the math here, as it is (a little) documented in the revctrl wiki: http://revctrl.org/CategoryMergeAlgorithm As long as git uses this naive algorithm, I am not willing to use it. While I agree that it's not the best merging algorithm I also fail to see why it could be a blocker. I've been using GIT for a while and I do not see conflicts very ofthen. Linux kernel also does it and I don't see people complaining about it. Personally I don't like bazaar due performance problem. It's really slow for big projects (it wouldn't be a big problem since GRUB is a small one) and it changes its data format too ofthen. If I'd going to choose, I'd go to GIT or Mercurial. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
Yoshinori K. Okuji [EMAIL PROTECTED] writes: 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. Please cite the ones you think are superior so we all can discuss it. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
Pavel Roskin [EMAIL PROTECTED] writes: If there are any specific problems with git pertinent to GRUB or preferences of the GRUB developers, I'm ready to convey them to the git developers and take the blame (if any). Personally I'm very happy with GIT and I'm using it in daily basis for most of project I'm active on. The easy merging and the wonderful workflow it allow is really nice. Besides that, it's really active and rapidly improving. We don't have to look for the best tool, just for the best tool for this particular project and those working on it. For me, it fits very well. I think it's worth to cite about http://packages.debian.org/sid/mr that allows to abstract the SCM and use a single command set for daily uses. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
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? :-) -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
Robert Millan [EMAIL PROTECTED] writes: I myself have no objection. I'd prefer svn, but that's not supported by Savannah yet, and anything is better than CVS IMO. In the event that we decide to migrate to svn in the future, though, is there an easy path from git to svn? I doubt that you'll want to come back to SVN after you get used to GIT. I thought it was going to be hard to learn but it was really easy and there's a lot of documentation about it available. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
willem [EMAIL PROTECTED] writes: Otavio Salvador wrote: Pavel Roskin [EMAIL PROTECTED] writes: Other GNU projects have switched to git. Savannah supports git. The list of the GNU projects using git is pretty impressive: http://git.sv.gnu.org/gitweb/ I think GNU GRUB would be a welcome addition. +1. I brought this up to discussion some time ago here but hadn't much feedback. I hope we can move forward this time :-D I did look at git. I agree , git is better than svn. It's much better and makes the integration work much easier to the team too. People can start to provide GIT trees, instead of patches, for review and once it has been accepted, and paper work done, a single git merge does the magic :-) -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
Vesa Jääskeläinen [EMAIL PROTECTED] writes: willem wrote: Otavio Salvador wrote: Pavel Roskin [EMAIL PROTECTED] writes: Other GNU projects have switched to git. Savannah supports git. The list of the GNU projects using git is pretty impressive: http://git.sv.gnu.org/gitweb/ I think GNU GRUB would be a welcome addition. +1. I brought this up to discussion some time ago here but hadn't much feedback. I hope we can move forward this time :-D I did look at git. I agree , git is better than svn. Git indeed has some nice features, but why I would hesitate its usage is that it does not integrate well with some IDE's like Eclipse. I know there has been some plugin (dead now?), but that is not ready for mainstream use. Where as CVS and SVN works nicely. If I am not mistaken, git is quite platform dependant... at least last time I looked at it, it was coded like it. That being said... I am not too strongly against switching to it. That's why GIT has git-cvsserver so you can use plain CVS tools to commit in a GIT repository. ;-) -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
Pavel Roskin [EMAIL PROTECTED] writes: Other GNU projects have switched to git. Savannah supports git. The list of the GNU projects using git is pretty impressive: http://git.sv.gnu.org/gitweb/ I think GNU GRUB would be a welcome addition. +1. I brought this up to discussion some time ago here but hadn't much feedback. I hope we can move forward this time :-D -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [RFC] [PATCH] Add multiboot 2 capabilities
Jerone Young [EMAIL PROTECTED] writes: diff -r b85dfdfcce16 conf/powerpc-ieee1275.rmk --- a/conf/powerpc-ieee1275.rmk Wed Jul 04 15:53:23 2007 -0500 +++ b/conf/powerpc-ieee1275.rmk Thu Jul 05 08:04:34 2007 -0500 @@ -102,7 +102,9 @@ pkgdata_MODULES = halt.mod \ linux.mod \ normal.mod \ reboot.mod \ - suspend.mod + suspend.mod \ +_multiboot.mod \ +multiboot.mod Badly indented. # For _linux.mod. _linux_mod_SOURCES = loader/powerpc/ieee1275/linux.c @@ -140,5 +142,18 @@ halt_mod_CFLAGS = $(COMMON_CFLAGS) halt_mod_CFLAGS = $(COMMON_CFLAGS) halt_mod_LDFLAGS = $(COMMON_LDFLAGS) +# For _multiboot.mod +_multiboot_mod_SOURCES = loader/powerpc/ieee1275/multiboot2.c \ + loader/multiboot2.c \ + loader/multiboot_loader.c +_multiboot_mod_CFLAGS = $(COMMON_CFLAGS) +_multiboot_mod_LDFLAGS = $(COMMON_LDFLAGS) + +# For multiboot.mod +multiboot_mod_SOURCES = loader/multiboot_loader_normal.c +multiboot_mod_CFLAGS = $(COMMON_CFLAGS) +multiboot_mod_LDFLAGS = $(COMMON_LDFLAGS) + + include $(srcdir)/conf/common.mk diff -r b85dfdfcce16 include/grub/i386/pc/loader.h --- a/include/grub/i386/pc/loader.h Wed Jul 04 15:53:23 2007 -0500 +++ b/include/grub/i386/pc/loader.h Thu Jul 05 01:17:47 2007 -0500 @@ -22,11 +22,13 @@ ... void EXPORT_FUNC(grub_linux_boot_zimage) (void) __attribute__ ((noreturn)); void EXPORT_FUNC(grub_linux_boot_bzimage) (void) __attribute__ ((noreturn)); @@ -34,16 +36,18 @@ void EXPORT_FUNC(grub_linux_boot_bzimage /* This is an asm part of the chainloader. */ void EXPORT_FUNC(grub_chainloader_real_boot) (int drive, void *part_addr) __attribute__ ((noreturn)); + Useless change. /* The asm part of the multiboot loader. */ void EXPORT_FUNC(grub_multiboot_real_boot) (grub_addr_t entry, struct grub_multiboot_info *mbi) + __attribute__ ((noreturn)); +void EXPORT_FUNC(grub_multiboot2_real_boot) (grub_addr_t entry, + struct grub_multiboot_info *mbi) __attribute__ ((noreturn)); Use same codestyle, please. There are some other places where it's not following same codestyle and would be nice if it could be fixed, imho. Kind regards, -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: pretty colors in gfxterm
Yoshinori K. Okuji [EMAIL PROTECTED] writes: Sorry but I didn't get what you mean by 'ad-hoc features' here. Can you elaborate it, please? Features, which are not fully examined if they are generic, flexible and extensible, are all ad-hoc. As I said in this list some times, I believe that the user must be able to fully control how a menu (or a different kind of user interface) should be displayed and provided, and style sheet support meets this requirement. Of course, Marco's idea about more scripting-based approach is also good, but I feel that this is rather overkill at the moment. Ok, I agree with you. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub-probe without arguments
Yoshinori K. Okuji [EMAIL PROTECTED] writes: On Monday 07 May 2007 22:06, Robert Millan wrote: On Mon, May 07, 2007 at 09:23:08PM +0200, Yoshinori K. Okuji wrote: On Monday 07 May 2007 10:21, Robert Millan wrote: I think it would be reasonable to allow grub-probe to work without arguments. Any comments? Why do you think so? Because it's commonly invoked while debugging. The uninitiated might have some trouble figuring out the right parameter (specialy if they're not debugging themselves, but providing information for someone else to debug e.g. via BTS). The right parameter depends on system status. For instance, if you are trying to install GRUB from an installer, and a boot partition is mounted at somewhere else (e.g. /mnt/boot), it won't work correctly, anyway. I prefer that grub-probe gets an argument explicitly, so that the user can at least understand that grub-probe probes a certain directory. I agree on that with Okuji. It'll get messy and difficult to guess if the calling result is right or not. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
