http://blog.gmane.org/gmane.linux.mandrake.cooker.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel/316138 <pre> On May 25, 2012, at 9:27 AM, Per Øyvind Karlsen wrote: As always, I find myself with a minority/contrarian opinion … … RPM+PERL embedded would rock. perl has a far sounder design for embedding than Ruby (which is a total disaster because the interpreter is using/needs automatic stack allocation) and Python (which cannot support multiple interpreters). And while LUA (and tcl) are even better than perl for embedding, there's a fairly steep learning curve programming in either language). Like Goldilock's porridge, perl is Just Right. Note that if RPM+PERL existed, then so could/would a lean-and-mean perl interpreter in /usr/lib/rpm/bin/*perl without being necessarily encumbered with the CPAN and module bloat that everyone is trying to lose by fiddling with packaging dependency chains. 73 de Jeff </pre> Jeffrey Johnson 2012-05-25T13:59:04 http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel/316137 <pre>2012/5/25 devnet &lt;devnet&lt; at &gt;unity-linux.org&gt;: Considering that what we're all chanting and in favour of is non-perl, I don't think this is much of an issue.. ;) For dealing with any potential regressions and what not as a result of moving to another implementation, I think it's something that still could be addressed independently by someone who does have better knowledge of it, while not having to block any work on an alternative implementation meanwhile. :) -- Regards, Per Øyvind </pre> Per Øyvind Karlsen 2012-05-25T13:31:57 http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel/316136 <pre>2012/5/25 devnet &lt;devnet&lt; at &gt;unity-linux.org&gt;: Considering that what we're all chanting and in favour of is non-perl, I don't think this is much of an issue.. ;) For dealing with any potential regressions and what not as a result of moving to another implementation, I think it's something that still could be addressed independently by someone who does have better knowledge of it, while not having to block any work on an alternative implementation meanwhile. :) -- Regards, Per Øyvind </pre> Per Øyvind Karlsen 2012-05-25T13:27:05 http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel/316135 <pre> Bootloader-config is pretty useless to most people in its current state because it doesn't detect bootable partitions as it is. That means if I have 4 other Linux distros on 4 different partitions spread across 4 different disks...it will wipe out the bootloader I painstakingly created with no regard for any other entries and drop a Mandriva one there. I think Mandriva is the last distribution (major) that still does this...all the others detect other installed distros/bootable distros. Wouldn't it be great if we could take Mandriva out of the 1990's and bring better functionality here all the while removing the perl dep as Matt has pointed out subsequently freeing it from a huge dep tree? I think so too. I'm definitely not the one to do it though as I have 0 experience with perl hacking and only looked at bootloader-config just today. </pre> devnet 2012-05-25T13:17:20 http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel/316134 <pre>I'm try diff code and sync package base in ROSA. 2012/5/25 Per Øyvind Karlsen &lt;peroyvind&lt; at &gt;mandriva.org&gt;: </pre> Alexander Kazancev 2012-05-25T13:09:57 http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel/316133 <pre>2012/5/25 Alexander Kazancev &lt;kazancas&lt; at &gt;mandriva.org&gt;: I've already pushed it to cooker, while I'm maintaining from it's original location in svn.mandriva.com. As you already have access to the infrastructure for committing changes for packages, you should also have same access to other software hosted as well. :) http://svn.mandriva.com/viewvc/soft/drakx/ r/o access: svn://svn.mandriva.com/svn/soft/drakx r/w access: svn+ssh://svn.mandriva.com/svn/soft/drakx -- Regards, Per Øyvind </pre> Per Øyvind Karlsen 2012-05-25T12:33:39 http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel/316132 <pre> On May 25, 2012, at 6:07 AM, Franck Bui wrote: Wuss ;-) Macros are just lazy string substitution in templating: its all smoke-and-mirror "tricks" because of dynamic evaluation, nothing more. 73 de Jeff </pre> Jeffrey Johnson 2012-05-25T11:31:11 http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel/316131 <pre> [...] Please avoid any rpm tricks/scripts/macros during the kernel installation :) </pre> Franck Bui 2012-05-25T10:07:18 http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel/316130 <pre>Per - was you update drakx tools 'from initial' or use ROSA update's? I'm moved all posible update for drakxtools and drakx-net from Mageia in ROSA and may we put this version in Cooker? Or sync our work? 2012/5/25 Andrey Bondrov &lt;andrey.bondrov&lt; at &gt;rosalab.ru&gt;: </pre> Alexander Kazancev 2012-05-25T09:49:46 http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel/316129 <pre>I see the point, I'll study this possibility, you are the kernel guy! :) I see something like a rpmposttrans on fedora spec of the kernel, looks like something similar, grubby even have support to call the rpmposttrans scripts Guilherme Moro </pre> Guilherme Moro 2012-05-25T09:32:07 http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel/316128 <pre>geeqie 2012/5/23 Matthew Dawkins &lt;mattydaw&lt; at &gt;gmail.com&gt; </pre> Toni Diaz 2012-05-25T09:16:49 http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel/316127 <pre>Hi On Fri, May 25, 2012 at 9:41 AM, Per Øyvind Karlsen &lt;peroyvind&lt; at &gt;mandriva.org&gt; wrote: This is a VERY GOOD news, give me more courage. A BIG THANKS. Bye Bye, Moreno </pre> Moreno 2012-05-25T08:28:12 http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel/316126 <pre> Again, I don't see the point of 'embedding' the generation of initrd in grubby. Another approach would be to make /sbin/installkernel a simple sh script that would call some services located in a well known place, /etc/kernel/install.d for example and the script would simply do: for sv in /etc/kernel/install.d/*; do if test -x $sv ; then $sv "$&lt; at &gt;" || echo &gt;&amp;2 "Service '$sv' failed" fi done and then you could install _any_ kind of services without having to hack grubby or anything else. Of course you would have the regular services we already have: /etc/kernel/install.d/01-mkinitrd ... /02-bootloader where 02-bootloader would be installed by the bootloader package. For grub, it could require grubby and use it to update the conf file, in case you don't want to add this support to grub. And we could use that to also support the dkms removals for example. </pre> Franck Bui 2012-05-25T08:16:53 http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel/316125 <pre>Hi! Despite communication not having been the greatest and the lack of it might've given some of you the impression that the planned, first prerelease of Mandriva Linux only turning out to become vaporware, I'm happy to tell this not being the case! :) I've just finished the extremely tedious and time-consuming task of merging (as good as) all of the work done on DrakX (both the installer and the drak* tools) at camp Mageia back in our repository, considering that it's been left virtually unmaintained ever since the fork, you might imagine it being a rather tremendous task (especially considering that Thierry has been insanely productive &amp; efficient, doing an insanely nice and good job all along on it meanwhile (leaving a gazillion of commits for me to go over and merge by hand;p). Now ours is at least up to date, and I've even gotten to make some improvements and fixes of my own on it as well, so while there wasn't made any classic installer issues for the previous 2011 release at all, I'm happy to let you know that we'll have these in place from the very start for this round! :) Related to this and in preparation for, I'd like to remind everyone of that the release is coming up next week already, so any help on showstoppers, critical issues, annoying issues, embarassing issues, ugly issues and what not would be greatly appreciated, and if nothing else, at least hold back any major changes for a few days more. :) Also I'm very happy about the very nice increase of activity on the wiki with people contributing to the specs for the next release, please keep up with this trend, and for those of you might not even have looked at this, now would be a very nice time for you to pitch any ideas and suggestions that you might have or would like to see being done! http://wiki.mandriva.com/en/2012.0_specs_proposal http://wiki.mandriva.com/en/Ideas_Mandriva_2012.0 -- Regards, Per Øyvind </pre> Per Øyvind Karlsen 2012-05-25T07:41:07 http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel/316124 <pre>So I'll drop the packages from the repo (SVN in some months) just to clean up, and leave just the rt-linus,desktop,server,generic, then its much more easy to migrate properly few kernels. I'll adjust soon (after several local tests) so kernel uses grubby and dracut. Regards, Guilherme Moro </pre> Guilherme Moro 2012-05-25T07:31:05 http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel/316123 <pre>grubby is just a replacement for /sbin/installkernel that is used, and as our old /sbin/installkernel it generate the initrd and put the config on grub{1,2}, lilo and others. The new kernel package I'm doing now is like this (except the dracut part for now, since its not yet fully fixed to replace the old mkinitrd): %post %ifarch %ix86 x86_64 /sbin/new-kernel-pkg --install %{uname_r} %endif %preun %ifarch %ix86 x86_64 /sbin/new-kernel-pkg --rminitrd --rmmoddep --remove %{uname_r} %endif %posttrans %ifarch %ix86 x86_64 /sbin/new-kernel-pkg --mkinitrd --dracut --depmod --update %{uname_r} %endif Besides that I don't really know if grubby don't just use the proper grub2 tool to add the lines there, I'll check the code later to see this. dracut don't use bootloader-utils for nothing, its just a dead Requires. Anyway, I'm fixing bootloader-utils too, so it only carries the other features (like /sbin/rebootin, used by pm-utils for lilo support). Regards, Guilherme Moro </pre> Guilherme Moro 2012-05-25T07:29:02 http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel/316122 <pre>Dnia 2012-05-24, o godz. 18:11:14 pcpa&lt; at &gt;mandriva.com.br napisał(a): Thanks </pre> Tomasz Paweł Gajc 2012-05-25T07:23:46 http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel/316121 <pre> Do you know why dracut is requiring bl-utils ? I would say that you can remove (but keep them around for a couple of months just in case) all kernels but: kernel-{rt,linus,desktop,server}. kernel-generic should be kept as well but I don't see it from your list (probably because you generated the list from a 64 bits host). </pre> Franck Bui 2012-05-25T07:22:38 http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel/316120 <pre> [...] Sorry I haven't looked at grubby yet, but what are those "other stuffs" ? And I don't think grubby should take care of the generation of initrd. </pre> Franck Bui 2012-05-25T07:18:53 http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel/316119 <pre> I think the "update bootloader config file" functionality should be provided by the bootloader itself not by another extra tool. Someone else pointed out that it's the case for grub2, and we should add this support to grub. </pre> Franck Bui 2012-05-25T07:17:02 http://permalink.gmane.org/gmane.linux.mandrake.cooker.devel/316118 <pre>В Thu, 24 May 2012 18:24:14 -0300 Guilherme Moro &lt;guilherme.moro&lt; at &gt;rosalab.ru&gt; пишет: Keep kernel-rt please. I maintain it, and it is useful for JACK. All kernels &lt;= 2.6.38 seems unmaintained. </pre> Dmitry Mikhirev 2012-05-25T05:39:26 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.mandrake.cooker.devel