Re: [Mageia-dev] Update to boost-1.53 ?
On 06/04/13 21:14, Olivier Blin wrote: Barry Jackson zen25...@zen.co.uk writes: On 04/04/13 16:29, Olivier Blin wrote: Did you try the one I already mentionned in this thread earlier? Quoting below: We could backport this in boost 1.53 to fix libyui: https://svn.boost.org/trac/boost/changeset/82103 Those two patches are already applied in 1.53 Right :-/ Maybe you ca push boost 1.53 to svn so that we can help? OK, boost-1.53 is now in svn. I have again test re-built recent KDE updated packages that use boost: akonadi kdelibs4 nepomuk-core kdepimlibs4 kate and these all install and kate appears to be fine. I have again re-built libreoffice with boost-1.53 and also tested calc, impress, draw and write briefly in real use cases and see no problems. There are still some test issues with gnuradio, but these can be fixed later with updates. libyui now builds with a patch from upstream git thanks to anaselli, however this is not yet in svn. So, as far as I am concerned all issues have been dealt with and I have tested as much as my limited resources of time and build system will allow. http://mtf.no-ip.co.uk/pub/linux/barjac/boost/boost.txt I now pass it to admins to make a final decision ;) Barry
Re: [Mageia-dev] Update to boost-1.53 ? (libyui fixing)
On 07/04/13 16:57, Angelo Naselli wrote:
I haven't committed anything at the moment, so you can take this as a
good patch and decide later if going on or not.
Angelo
Hi
Not had much time to check over weekend.
Your last patch fails to apply for some reason, but I will look again -
may be something silly.
Before I saw your last patch I made one from the upstream git revision,
and this applies and builds OK. It is attached.
Barry
diff -ur libyui-2.42.4-623354b_orig/src/ImplPtr.h
libyui-2.42.4-623354b/src/ImplPtr.h
--- libyui-2.42.4-623354b_orig/src/ImplPtr.h2013-01-07 21:19:01.0
+
+++ libyui-2.42.4-623354b/src/ImplPtr.h 2013-04-08 17:51:10.741171954 +0100
@@ -41,7 +41,9 @@
templateclass _Impl
class ImplPtr : private boost::noncopyable
{
+#if defined( BOOST_NO_CXX11_EXPLICIT_CONVERSION_OPERATORS ) || defined(
BOOST_NO_CXX11_NULLPTR )
typedef typename boost::scoped_ptr_Impl::unspecified_bool_type
unspecified_bool_type;
+#endif
public:
typedef _Impl element_type;
@@ -55,7 +57,11 @@
void swap( ImplPtr rhs ) { _impl.swap( rhs._impl ); }
public:
+#if defined( BOOST_NO_CXX11_EXPLICIT_CONVERSION_OPERATORS ) || defined(
BOOST_NO_CXX11_NULLPTR )
operator unspecified_bool_type() const { return _impl; }
+#else
+explicit operator bool () const { return _impl.get() != 0; }
+#endif
const _Impl operator*() const { return *_impl; }
const _Impl * operator-() const { return _impl.get(); }
Re: [Mageia-dev] freeze push: vowpal-wabbit 7.2
On 05/04/13 22:36, Pierre-Malo Deniélou wrote: Vowpal-wabbit is a machine learning computational tool. We currently have 7.1. Nothing depends on it, and it was not in Mageia 2. I don't have a changelog (it's a huge git commit dump) to show, but it works and allows to drop the patches we used and were upstreamed. Thanks, ...and it still builds with boost-1.53
Re: [Mageia-dev] Segfault with new LibreOffice packages
On 31/01/13 17:26, David Walser wrote: Sander Lepik sander.lepik@... writes: New icu was pushed. Maybe packages depending on it need to be rebuilded. From what upstream said, it sounds like some users of the icu library don't use the affected part, and so maybe they don't all need rebuilt, but if they do, here's the list urpmq gave me of SRPMS that use libicu: 389-admin 389-adminutil 389-ds-base beecrypt boost calibre calligra chromium-browser-unstable couchdb dee fcitx firebird harfbuzz ibus-qt4 ircclient-qt libreoffice mapnik openttd parrot php qt4 qtbase5 raptor2 R-base sword texlive tracker webkit webkit-efl xerces-c yaz zarafa Several of these also need boost, so perhaps this is a good time to make a decision on boost-1.53? Everything now builds except libyui for which there is a possible patch that I have not had time to test. I have test rebuilt 0ad again that was just updated and am currently rebuilding libreoffice again on both arch.
Re: [Mageia-dev] Update to boost-1.53 ?
On 04/04/13 16:29, Olivier Blin wrote: Did you try the one I already mentionned in this thread earlier? Quoting below: We could backport this in boost 1.53 to fix libyui: https://svn.boost.org/trac/boost/changeset/82103 Those two patches are already applied in 1.53
Re: [Mageia-dev] Update to boost-1.53 ?
On 05/04/13 00:08, Barry Jackson wrote: On 04/04/13 14:24, Angelo Naselli wrote: Barry i cannot test this now, but if i understood correctly the problem and talking to libyui developer this patch should work. Can you test it and tell me if it's ok please? Thanks Angelo I'll try it tomorrow - been out most of the day. Nope it still fails with the patch: http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/core/release/log/libyui-2.42.4-0.git20130107.3.mga3.src.rpm/build.0.20130406163948.log
Re: [Mageia-dev] Segfault with new LibreOffice packages
On 06/04/13 16:33, Thomas Spuhler wrote: Maybe we should move to boost-1.53 now if those package who use it build. Yes - rebuild tests are here - one package fails which currently affects nothing else. http://mtf.no-ip.co.uk/pub/linux/barjac/boost/boost.txt
Re: [Mageia-dev] Update to boost-1.53 ?
On 03/04/13 17:05, Angelo Naselli wrote: Il 02/04/2013 02:31, Barry Jackson ha scritto: So now only libyui remains. Oops, i've just saw it now sorry. What is the issue? I could try to work on it tonight at home should i build boost locally first or it's on some mirrors? Angelo Hi, The problem is in this build log:- http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/log/libyui-2.42.4-0.git20130107.3.mga3.src.rpm/build.0.20130328124443.log I have builds of boost-1.53 in here http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/media/extra/release/ and http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/i586/media/extra/release/ media-info is up to date. Thanks, Barry
Re: [Mageia-dev] Update to boost-1.53 ?
On 04/04/13 14:24, Angelo Naselli wrote: Barry i cannot test this now, but if i understood correctly the problem and talking to libyui developer this patch should work. Can you test it and tell me if it's ok please? Thanks Angelo I'll try it tomorrow - been out most of the day.
Re: [Mageia-dev] Update to boost-1.53 ?
On 02/04/13 08:46, Sander Lepik wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 02.04.2013 03:31, Barry Jackson kirjutas: I will try to test rebuild all the packages using boost in i586 in iurt in the next few days - just wish urpmi-proxy would work with iurt (if anyone knows how to enable extra media in iurt let me know) My iurt command with local repo that is soft-linked into /media: LC_ALL=C linux32 iurt --delete-on-success --chrooted-urpmi http://my.domain.com/mga/distrib --media core/release local/release -r cauldron i586 Thanks Sander, That helped a lot, the --help in iurt is wrong on --media which threw me. i586 test builds are almost complete. Unfortunately KDE was bumped in svn which complicated testing, but all seems fine with the new and current versions. List attached. Package x86_64 i586 0ad ok ok akonadi ok ok aqsis ok ok avogadrook ok blender ok ok cclive ok ok clanbomber ok ok clementine ok ok e4rat ok ok easystroke ok ok ekiga ok ok enblend ok ok encfs ok ok fifeok ok flightcrew ok ok freefilesyncok ok gearmandok ok globulation2ok ok glomok ok gnash ok ok gnuradiook ok hugin ok ok nepomuk-core-4.10.2 ok ok kdepimlibs4-4.10.1 ok ok kdepimlibs4-4.10.2 ok ok kate-4.10.1 ok ok kate-4.10.2 ok ok libcmis ok ok libkolabxml ok ok liborcusok ok libpst ok ok libreoffice ok* ? libtorrent-rasterbarok ok libyui error: no type named 'unspecified_bool_type' in 'class boost::scoped_ptr lightspark ok ok linuxdcpp ok ok lyx ok* ? mapnik ok ok mariadb ok ok mddsok ok mirook ok mkvtoolnix ok ok ogreok ok openimageio ok ok pdnsok ok pingus ok ok pinot ok ok pokerth ok ok povray ok ok python-exiv2ok ok pythonmagickok ok python-tagpyok ok qbittorrent ok ok quantlibok ok referencer ok ok schroot ok ok sigil ok ok simgear ok ok smc ok ok source-highlightok ok spring ok ok springlobby ok ok sslsniffok ok uhd ok ok undertaker ok ok urtconnectorok ok vdrift ok ok vegastrike ok ok vigra ok ok vowpal-wabbit ok ok wesnoth ok ok widelands ok ok xmms2 ok ok xsd ok ok zarafa ok ok zanshin ok ok * 'cat: standard output: Permission denied' (issue on my build system in iurt)
Re: [Mageia-dev] Update to boost-1.53 ?
On 31/03/13 20:33, Olivier Blin wrote: David Walser luigiwal...@yahoo.com writes: Barry Jackson wrote: As mentioned in last week's packager's meeting, there is a problem with our gnuradio package, because upstream have blacklisted boost-1.52. https://bugs.mageia.org/show_bug.cgi?id=8789 I have spent considerable time test rebuilding all packages from current svn that BuildRequire boost, against boost-1.53 to see if an update of boost is viable. (x86_64 only so far) Fixes have been applied to some packages and now there are just two remaining that fail to build:- Now that it's down to these two, I think this should be done. libyui is only here for the new MCC which won't be ready at least until mga4, and it seems this gnuradio is important to some people, while vegastrike is just a game I think. Even if just a game, it may be of some importance to our users :-) Could someone try this patch from upstream? http://vegastrike.svn.sourceforge.net/viewvc/vegastrike/trunk/vegastrike/src/networking/lowlevel/packetmem.cpp?r1=12089r2=13530 Thanks Oliver - no idea how you dug that out! Yes that fixed local build against boot-1.53 and ogre (also built against 1.53). I pushed the updated package, but BS is broken afaict. So now only libyui remains. I will try to test rebuild all the packages using boost in i586 in iurt in the next few days - just wish urpmi-proxy would work with iurt (if anyone knows how to enable extra media in iurt let me know)
[Mageia-dev] Update to boost-1.53 ?
As mentioned in last week's packager's meeting, there is a problem with our gnuradio package, because upstream have blacklisted boost-1.52. https://bugs.mageia.org/show_bug.cgi?id=8789 I have spent considerable time test rebuilding all packages from current svn that BuildRequire boost, against boost-1.53 to see if an update of boost is viable. (x86_64 only so far) Fixes have been applied to some packages and now there are just two remaining that fail to build:- libyui log: http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/log/libyui-2.42.4-0.git20130107.3.mga3.src.rpm/build.0.20130328124443.log vegastrike log: http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/log/vegastrike-0.5.1-16.mga3.src.rpm/build.0.20130328162253.log The full list of test built packages is attached. The alternative to updating boost would be to drop gnuradio from Mageia3. I invite comments and help to fix these two packages. Barry Package x86_64 0ad ok akonadi ok aqsis ok avogadrook blender ok cclive ok clanbomber ok clementine ok e4rat ok easystroke ok ekiga ok enblend ok encfs ok fifeok flightcrew ok freefilesyncok gearmandok globulation2ok glomok gnash ok gnuradiook hugin ok kateok kdepimlibs4 ok libcmis ok libkolabxml ok liborcusok libpst ok libreoffice ok * libtorrent-rasterbarok libyui error: no type named 'unspecified_bool_type' in 'class boost::scoped_ptr lightspark ok linuxdcpp ok lyx ok * mapnik ok mariadb ok mddsok mirook mkvtoolnix ok ogreok openimageio ok pdnsok pingus ok pinot ok pokerth ok povray ok python-exiv2ok pythonmagickok python-tagpyok qbittorrent ok quantlibok referencer ok schroot ok sigil ok simgear ok smc ok source-highlightok spring ok springlobby ok sslsniffok uhd ok undertaker ok urtconnectorok vdrift ok vegastrike no matching function for call to 'boost::shared_arraychar::reset(int)' vigra ok vowpal-wabbit ok wesnoth ok widelands ok xmms2 ok xsd ok zarafa ok zanshin ok * 'cat: standard output: Permission denied' (issue on my build system in iurt - no problem building in local system)
Re: [Mageia-dev] Does anyone have a script that bumps releases?
On 31/03/13 14:09, Colin Guthrie wrote: Hi, Does anyone have a script that will bump the release of a given spec file? umeabot has one ;)
Re: [Mageia-dev] Last versions of programs concerning Computer Assisted Music
On 29/03/13 16:54, PhilippeDidier wrote: PhilippeDidier a écrit : PS I discovered a clone copy of one of our first beta spec files applied to the final source tarball in an other distro, (we can recognize our Mageia's touch) It would have been fair play from these packagers to tell in a changelog where this spec file comes from (that reminds me bad practices from old times with some Mandrake(iva) based distributions or contributions) :-( Yes - hence: https://wiki.mageia.org/en/Collaboration_policy Ardour3 pushed. Thanks again Philippe for your efforts on this :)
Re: [Mageia-dev] Last versions of programs concerning Computer Assisted Music
On 29/03/13 00:19, PhilippeDidier wrote:
Barry Jackson a écrit :
Thanks Philippe,
I have committed your changes (but somewhat shrunk ;) - please check it
over and I will submit, as the group change is quite important.
Cheers,
Barry
Hi Barry
Sorry for being so late to answer
I tested the spec you commited
built ardour3-3.0.2
installed it
tested it : the symlinks are wrong ?!!!
Reused my own spec file
rebuild installed : the symlinks work ?!!!
Indeed :
because of an artefact I couldn't see that the symlinks that I created
were wrong (leading to BUILDROOT/ardour3-3.0-1.mga2.i386 that had not
been deleted ... the links showed the icons )
I know why now !
Anyway there's a little typo in yours (ardour_icon_${i}x.png instead of
ardour_icon_${i}px.png)
Here is a new svndiff with corrected symlinks and the typo corrected
Better tested this time ;-)
I am sure the symlinks are correct (they needed a relative path )
I tested them several ways : they are all OK
I think you may commit and submit now
Regards
Philippe
Yep - sorry about the typo and I should have spotted the symlink error.
Fixed in svn - please double check ;)
BTW there was no need to use all the ../../ just removing %{buildroot}
on the target is enough.
Re: [Mageia-dev] Last versions of programs concerning Computer Assisted Music
On 27/03/13 22:34, PhilippeDidier wrote:
Colin Guthrie a écrit :
FYI, these lines can be more neatly (IMO) done as:
install -D -p %{buildroot}%{_datadir}/%{name}/icons/ardour_icon_48px.png
%{buildroot}%{_iconsdir}/hicolor/48x48/apps/ardour3.png
(you can also add -m 0644 if you want to be specific about permission.
All that said, if the icons are being shipped already, why not just
symlink them rather than provide two copies? (in which case the install
-d lines should remain :D)
Col
So ... here is a svndiff adding symlinks instead of copying
It works for me (applied to the last spec from Cauldron)
I could build and install
I think it may be commited (even if not submitted : it's just a cosmetic
improvement...)
Thanks Philippe,
I have committed your changes (but somewhat shrunk ;) - please check it
over and I will submit, as the group change is quite important.
Cheers,
Barry
Re: [Mageia-dev] Last versions of programs concerning Computer Assisted Music
On 25/03/13 23:31, PhilippeDidier wrote: zezinho a écrit : Em 25-03-2013 13:30, PhilippeDidier escreveu: What do you think ? There are enough bugs to fix for now, let's wait for MGA4. So we may simply provide the final release of Ardour3, built upon the BuildRequires already existing inside Cauldron (it can be built this way ) the spec file is ready ! And wait to update the whole stuff after Mageia3 is out ! Any other opinion ? Pushed - please test. We do have an anomaly between ardour and ardour3 - they are in different rpm groups. We need to decide which (if either) is correct and change one or both. Any thoughts Philippe ?
Re: [Mageia-dev] Packagers meeting tonight (26/03/3013, 20h UTC)
On 26/03/13 14:03, Pierre-Malo Deniélou wrote: Ok. New list of topics: - Uninstallable packages: http://check.mageia.org/cauldron/dependencies.html - Packages which failed rebuild - Release critical bugs: review and status Cheers, There is also the issue of boost-1.52 and gnuradio. https://bugs.mageia.org/show_bug.cgi?id=8825 https://bugs.mageia.org/show_bug.cgi?id=8789 gnuradio builds against 1.52 but is functionally broken, consequently upstream have blacklisted boost-1.52. gnuradio is OK with boost-1.53, but that does break the build of some other packages. I test built all that require it:- http://mtf.no-ip.co.uk/pub/linux/barjac/boost/boost.txt Options: 1. Update boost to 1.53 and fix the other broken builds 2. Somehow provide boost-1.53 or 1.51 alongside 1.52 3. Nuke gnuradio until boost gets updated.
Re: [Mageia-dev] drakrpm can no longer download packages
On 20/03/13 18:09, Thierry Vignaud wrote: On 20 March 2013 18:23, zezinho lists.jjo...@free.fr wrote: Em 20-03-2013 15:40, Colin Guthrie escreveu: Hi, Since the updates recently, I can no longer use drakrpm to update packages. +1, with the same error. real (wo)men rsync the full mirror then use rpmdrake to install local packages. just fixed anyway No change here with rpmdrake-5.42-2.mga3 1 installation transactions failed There was a problem during the installation: ...retrieving failed: Can't locate object method progress via package gurpm::RPMProgressDialog at /usr/lib/perl5/vendor_perl/5.16.3/Rpmdrake/pkg.pm line 216, $curl chunk 238. urpmi works OK
[Mageia-dev] Freeze push: fldigi
Please push fldigi This is a maintenance and bug fix release. We have missed 6 version updates on this package and it would be good to bring it up to date for Mga3. It has been tested on real hardware without problems. Thanks. #-- Changes since 3.21.61:- =Version 3.21.68= 2013-02-08 Remi Chateauneu remi.chateau...@gmail.com efe6687: RTTY bug fix 2013-02-07 David Freese w1...@w1hkj.com 2a6bfee: RTTY filters 48dcf51: Hang on start 72dd5f2: Analysis 55b76e9: rigMEM be3dd1f: WF only ESC abort 2013-02-03 John Phelps kl4...@gmail.com 4a8e3ca: WF only null pointer fix 2013-02-02 David Freese w1...@w1hkj.com 48ed1f0: RTTY config tab f684b91: RTTY stop bits =Version 3.21.67= 645acab: PSK viewer 63323a4: Contest fields f3abd4c: RigCAT INIT/CLOSE 4af6dcd: Olivia FEC reset 0d4d55d: RTTY FSK modem b8fd4db: Status / Tx Level Controls =Version 3.21.66= 305fa6d: Thor reset d2dea40: File Selector f83a413: Macros d12f7da: CW modem 282886b: User configurable items =Version 3.21.65= 7680b05: High Speed / Multi-Carrier Modems =Version 3.21.64= 2012-12-26 Makoto Fujiwara mak...@ki.nu 0322dc9: NetBSD compile error 2012-12-15 David Freese w1...@w1hkj.com 05b3ad0: Dup Cty lookup b02da36: Get RX buffer d52579b: Capture Alt-F4 =Version 3.21.63= 972865e: Macros LOG LNW EXEC 01ef002: ARQ Socket 261b7fb: Default char set 614a542: NBEMS.DIR cb820ae: RTTY CR-CR-LF de390ac: Control-V/Z =Version 3.21.62= fec0ead: Pause-break 2ca1bf7: WF-only-escape 326a75d: REPEAT Macro 44e6ae6: MT63 Long
Re: [Mageia-dev] bogus packages that provides fonts-ttf-dejavu
On 16/03/13 16:24, zezinho wrote: Em 12-03-2013 22:33, Thierry Vignaud escreveu: I suspect some other fonts-ttf-* are also duplicated... Eg for Liberation fonts: cube-escape flare-data flightgear-data freecol ganttproject gcstar zygrib I checked flightgear-data, and the file size is different. It seems they have modified the font to their needs. So some of this duplicates may be needed... I suspect that the font has been rebuilt with a restricted range of characters or styles. AFAICT with the few that I have updated so far, this does not affect operation, as the required glyphs are available in the full packaged version of the font. In one case the embedded ttf was around 75k where the full ttf was several hundred k, but the game did not complain.
Re: [Mageia-dev] Freeze Push: xlog
Yes I forgot - thanks. The main reason is that we would be stuck with an old version for the life of mga3. It's just bad timing that upstream released this now. It does not impact on anything else.
Re: [Mageia-dev] Freeze Push: xlog
On 09/03/13 10:06, Barry Jackson wrote: Yes I forgot - thanks. The main reason is that we would be stuck with an old version for the life of mga3. It's just bad timing that upstream released this now. It does not impact on anything else. To clarify, this is the first new release since Feb 2011. Mainly long overdue bug fixes. - Changes for xlog version 2.0.6 - 2013-March-01 * First version with new maintainer: Andy Stewart, KB1OIQ * Updated to Cabrillo v3 format - export and import (bug #37740) * Added preference setting for Are You Sure dialog on exit (bug #37761) * Updated cty.dat to 20130222 (CTY-2302) (bug #37748) * Updated to Amateur Data Interchange Format (ADIF) 2.2.7 format (bug #37741) ** Added a large number(!) of modes ** Added the 560m band * Fixed cosmetic issues with the scoring window (bug #37743) * Fixed Ubuntu bug #608718: Keyer window displayed, hitting return in RX(RST) with no call logged bogus QSO. * Fixed Task #10916 - user preference to save Cabrillo freq or band * New manual from Chris Story (K6RWJ) * Entering callsigns like 3D2/R will show proper DXCC entity in scoring window locator box for all except WAE countries.
[Mageia-dev] Freeze Push: xlog
Please push xlog New version released a few days ago - builds/tests OK. Thanks
[Mageia-dev] grub2 update warning
If you are using grub2 in Cauldron you may end up with a black/white non-graphical menu after today's update. The update changed the default config file which is not normally updated on package update. To end up with a correct default configuration the correct answer to the rpmnew question is (in this case) to use /etc/default/grub.rpmnew Then do the following to recover the graphical menu (assuming that you use it) :- urpme grub2-mageia-theme urpmi grub2-mageia-theme Barry.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release grub2-2.00-34.mga3
On 27/02/13 19:01, Thierry Vignaud wrote: On 27 February 2013 15:49, barjac buildsystem-dae...@mageia.org wrote: barjac barjac 2.00-34.mga3: + Revision: 400520 - set default timeout to 10 seconds Please do not! Why? This is not the place. I'm sorry but I disagree - this is the place. What's more, drakboot already handle it. Are you saying that drakboot will write the setting into /etc/default/grub ? If so it can overwrite the value already there, what harm will this do? What if a user installs the grub2 package without using drakboot. How in that case can we supply a 10 second default without setting it in the configuration file? I will revert this if absolutely necessary, but I really don't understand why you feel it is wrong. Barry
[Mageia-dev] urpmi - strange read lock messages
I see this in a clean new installation of Cauldron (net install x86_64) updated today. (although I saw this before the update). Happens with any package. [baz@localhost ~]$ su Password: [root@localhost baz]# urpmi kate BDB2053 Freeing read locks for locker 0xc63: 2497/140611879974656 BDB2053 Freeing read locks for locker 0xc65: 2497/140611879974656 BDB2053 Freeing read locks for locker 0xc66: 2497/140611879974656 BDB2053 Freeing read locks for locker 0xc67: 2497/140611879974656 BDB2053 Freeing read locks for locker 0xc68: 2497/140611879974656 BDB2053 Freeing read locks for locker 0xc69: 2497/140611879974656 BDB2053 Freeing read locks for locker 0xc6a: 2497/140611879974656 BDB2053 Freeing read locks for locker 0xc6b: 2497/140611879974656 BDB2053 Freeing read locks for locker 0xc6c: 2497/140611879974656 BDB2053 Freeing read locks for locker 0xc6d: 2497/140611879974656 BDB2053 Freeing read locks for locker 0xc6e: 2497/140611879974656 BDB2053 Freeing read locks for locker 0xc6f: 2497/140611879974656 BDB2053 Freeing read locks for locker 0xc70: 2497/140611879974656 BDB2053 Freeing read locks for locker 0xc37: 2497/140593642727168 BDB2053 Freeing read locks for locker 0xc39: 2497/140593642727168 BDB2053 Freeing read locks for locker 0xc3a: 2497/140593642727168 BDB2053 Freeing read locks for locker 0xc3b: 2497/140593642727168 BDB2053 Freeing read locks for locker 0xc3c: 2497/140593642727168 BDB2053 Freeing read locks for locker 0xc3d: 2497/140593642727168 BDB2053 Freeing read locks for locker 0xc3e: 2497/140593642727168 BDB2053 Freeing read locks for locker 0xc3f: 2497/140593642727168 BDB2053 Freeing read locks for locker 0xc40: 2497/140593642727168 BDB2053 Freeing read locks for locker 0xc41: 2497/140593642727168 BDB2053 Freeing read locks for locker 0xc42: 2497/140593642727168 BDB2053 Freeing read locks for locker 0xc43: 2497/140593642727168 BDB2053 Freeing read locks for locker 0xc44: 2497/140593642727168 To satisfy dependencies, the following packages are going to be installed: PackageVersion Release Arch (medium Core Release (zmrepo1)) kate 4.10.0 1.mga3x86_64 kate-handbook 4.10.0 1.mga3noarch (suggested) ktexteditor4.10.0 1.mga3x86_64 lib64kateinterfaces4 4.10.0 1.mga3x86_64 6.6MB of additional disk space will be used. 1.4MB of packages will be retrieved. Proceed with the installation of the 4 packages? (Y/n)
Re: [Mageia-dev] urpmi - strange read lock messages
On 10/02/13 14:27, Thierry Vignaud wrote: On 10 February 2013 15:24, Barry Jackson zen25...@zen.co.uk wrote: I see this in a clean new installation of Cauldron (net install x86_64) updated today. (although I saw this before the update). Happens with any package. You didn't C^c urpmi? Not as I recall, however I now cannot reproduce. If it recurs I will take better notes ;)
Re: [Mageia-dev] Huh? Urpmi package numbers . . .
On 09/02/13 11:58, Robert Fox wrote: Since latest Cauldron updates - the urpmi process seems to be lying about the number of packages - In this example, it say 293 packages - but when it starts, it says 1/582 -?? Huh? urpmi --auto-update -v SNIP: 71MB of additional disk space will be used. 174MB of packages will be retrieved. Proceed with the installation of the 293 packages? (Y/n) SNIP: 2/582: lib64okteta1core1 ## 3/582: lib64kasten2gui2 ## 4/582: lib64okteta1gui1 ## 5/582: lib64kasten2okteta1core1 ## 6/582: lib64kasten2okteta1 Is this by design? Cheers, Robert Yes a removal is now counted as well as an installation, so it's double - I don't see the point, I think it was better as it was : \
[Mageia-dev] grub2 package update announcement
From grub2-2.00-18.mga3 the theme has been split into a separate package which is a Suggests, as is os-prober. For most this difference will mean no change and the update should be seamless. However, after the update to grub2-2.00-18.mga3 it will be possible to remove the theme simply by removing the grub2-mageia-theme package, which will reveal a plain text boot menu on the next boot. This saves the overhead of many deps in a minimal installation. Similarly installing grub2 with --no-suggests will achieve the same result. os-prober may now also be added/removed at will which will have the effect of including or removing other detected OSes from the menu at the next boot. (os-prober may also be disabled while remaining installed if required.) Full details are available in the updated /usr/share/doc/grub2/README.Mageia. Barry
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 03/02/13 18:05, Felix Miata wrote:
On 2013-02-02 10:08 (GMT) Barry Jackson composed:
Felix Miata wrote:
Good start:
1-/boot/grub2/i386-pc/core.img in a Grub Legacy stanza succeeds
Not good from then on:
1-Grub2 error message due to not finding some png file
You removed the png by using --no-suggests
One cannot remove what is not present. What I did was block installation
of packages that the grub2 package does not declare to be required.
Grub2 should not be configured to show user an error resulting from its
own installation misconfiguration. That looks like a bug.
2-25 item Grub 2.00 menu (grub.cfg:
http://fm.no-ip.com/Tmp/Linux/Mdv/grub.cfg.gx27b-cauldron3-1.txt ).
After selecting a selection from a master bootloader, there's no good
reason to see similar selections as in the previous menu unrelated to
the chosen selection. IOW, when not a master bootloader (i.e.
chainloaded via core.img, only Mageia entries attributable to selected
filesystem hosting core.img should be in this menu.
If that is what you want then:-
# urpme os-prober
Why was it installed when I did 'urpmi --no-suggests grub2' if it's not
required?
# urpme os-prober
To satisfy dependencies, the following 2 packages will be removed...
grub2-yada
os-prober-yada...
Right, sorry - I agree - I never really envisaged anyone not wanting
os-prober installed, however it should really be a Suggests - I will
change that.
However I should have pointed out that it can be disabled in
/etc/defaults/grub with
GRUB_DISABLE_OS_PROBER=true
3-Grub2 menu uses same awful spindly-looking font responsible in large
part for my distaste for *buntu
Yes could be a lot better, but it's mainly a choice based on licensing,
probably will be improved in the future.
What's wrong with nice legible BIOS native fonts?
Try commenting out the line in /etc/defaults/grub
#GRUB_THEME=...
and also temporarily rename /boot/grub2/fonts
Run grub2-mkconfig -o /boot/grub2/grub.cfg
after changing anything in /etc/deafult/grub before rebooting.
Is that better for you?
4-default menu selection for Cauldron causes this cmdline:
BOOT_IMAGE=/boot/vmlinuz-prv
root=UUID=bbe8a402-5fb1-4247-b372-5bb6cff4e18c ro splash
which is nothing like the default Grub Legacy menu stanza's cmdline
result:
root=LABEL=22cauldrn splash=verbose noresume video=1152x864
vga=794 3
obviously caused by Grub2 installation disregarding content of
pre-existing menu.lst
grub2 does not pay any attention to legacy menu.lst - it's a totally
different, unrelated bootloader.
If you want grub2 to use an existing legacy menu.lst then you can use
grub2-menulst2cfg tool to create a grub.cfg from menu.lst.
Usage: grub2-menulst2cfg [INFILE [OUTFILE]]
Nice in theory, but the root device is off by -1. Default menu.lst
cmdline includes root=LABEL=22cauldrn instead of UUID or device name,
which is apparently disregarded by grub 2.
menuentry 'Cauldron defkernel' {
legacy_kernel '(hd0,22)/boot/vmlinuz' '(hd0,21)/boot/vmlinuz'
'root=LABEL=22cauldrn' 'splash=verbose' 'noresume' 'video=1152x864'
'vga=794' '3' ''
legacy_initrd '(hd0,22)/boot/initrd' '(hd0,21)/boot/initrd'
}
It works when I s/hd0,21/hd0,22/g.
That looks like an upstream bug - I will investigate.
5-semi-legible blue on black graphical progress bar instead of normal
complement of startup messages when splash=verbose
The font colours were chosen to complement the background image which
you chose not to install.
I saw no fonts in that progress bar. I asked for no progress bar.
OK remove the theme as above and set:
GRUB_CMDLINE_LINUX=3
... for runlevel 3 and just remove the splash on that line for verbose
output.
6-post ESC, startup messages are inappropriately tiny
Sounds like the same issue I used to have when I was using nvidia
graphics with nouveau.
Using intel I don't see this.
# lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated
Graphics Controller (rev 02)
Hmm - dunno then - I do see a drop in size which appears to happen after
grub2 has handed over to the kernel.
7-tty text is too tiny to use (same as startup messages; screen's
preferred mode 1600x1200 used instead of legible mode 1152x864)
Probably configurable in /etc/defaults/grub but off hand I don't know
the variable name - should be in the maunual somewhere.
I'm suspecting this is not a grub2 issue but I may be wrong.
grub2-menulst2cfg picked up the ones that work in Grub Legacy (vga=
((http://www.kernel.org/doc/Documentation/kernel-parameters.txt))
video= ((http://www.kernel.org/doc/Documentation/fb/modedb.txt))), which
are kernel parameters. They do the same thing loaded via Grub2 as when
loaded via Grub Legacy.
8-KDM is on tty2, the location I reserve for certain class of recurring
activities, instead of where expected on tty7
Dunno - I have never seen this.
Booting with 3 on cmdline and later doing startx or init 5
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 03/02/13 18:05, Felix Miata wrote:
Nice in theory, but the root device is off by -1. Default menu.lst
cmdline includes root=LABEL=22cauldrn instead of UUID or device name,
which is apparently disregarded by grub 2.
Maybe a limitation of legacy_kernel.
Normally to use labels in grub2 the 'search' command is used without any
reference to the device assignment.
Like:-
menuentry 'Mageia-2 multiboot' {
search --no-floppy --label --set=root mageia-2
multiboot /boot/grub2/i386-pc/core.img
}
menuentry 'Cauldron defkernel' {
legacy_kernel '(hd0,22)/boot/vmlinuz' '(hd0,21)/boot/vmlinuz'
'root=LABEL=22cauldrn' 'splash=verbose' 'noresume' 'video=1152x864'
'vga=794' '3' ''
legacy_initrd '(hd0,22)/boot/initrd' '(hd0,21)/boot/initrd'
}
It works when I s/hd0,21/hd0,22/g.
That syntax is apparently correct, as legacy_kernel needs to know what
the original legacy command was.
I have tested here in a clean mga3 installation and it works for me.
Please re-test and if it fails again please attach the original menu.lst
and the resulting grub.cfg along with any error messages.
Barry
Re: [Mageia-dev] urpmi counts gone askew
On 04/02/13 14:19, Frank Griffin wrote: Not sure this is worth a bug report, since I doubt I could reproduce it, but check out the package number/total output in this morning's cauldron update: Yes - same here :\ 44/78: libreoffice-kde # removing upgraded package libreoffice-base-4.0.0.2-2.mga3.x86_64 18/-24: libreoffice-base then afer a couple of transactions it corrects itself for a while and then after another few transactions it goes haywire again - etc...
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 04/02/13 19:18, Felix Miata wrote:
On 2013-02-04 14:27 (GMT) Barry Jackson composed:
Felix Miata wrote:
Nice in theory, but the root device is off by -1. Default menu.lst
cmdline includes root=LABEL=22cauldrn instead of UUID or device name,
which is apparently disregarded by grub 2.
Maybe a limitation of legacy_kernel.
Normally to use labels in grub2 the 'search' command is used without any
reference to the device assignment.
Like:-
menuentry 'Mageia-2 multiboot' {
search --no-floppy --label --set=root mageia-2
multiboot /boot/grub2/i386-pc/core.img
}
menuentry 'Cauldron defkernel' {
legacy_kernel '(hd0,22)/boot/vmlinuz' '(hd0,21)/boot/vmlinuz'
'root=LABEL=22cauldrn' 'splash=verbose' 'noresume' 'video=1152x864'
'vga=794' '3' ''
legacy_initrd '(hd0,22)/boot/initrd' '(hd0,21)/boot/initrd'
}
It works when I s/hd0,21/hd0,22/g.
That syntax is apparently correct, as legacy_kernel needs to know what
the original legacy command was.
I have tested here in a clean mga3 installation and it works for me.
Please re-test and if it fails again please attach the original menu.lst
and the resulting grub.cfg along with any error messages.
It's entirely unclear what re-test here means, unless maybe by
incorporating your immediately preceding thread response. Current
behavior of Grub2 menu overall and first grub.cfg stanza is acceptable
having used/using the following:
http://fm.no-ip.com/Tmp/Linux/Mdv/menu.lst.04-cldrn-gx27b.txt
http://fm.no-ip.com/Tmp/Linux/Mdv/etc-default-grub-cldrn-gx27b.txt
http://fm.no-ip.com/Tmp/Linux/Mdv/grub.cfg.06-cldrn-gx27b.txt
Only error message I recall is about vga= from Grub2 before first
kernel/init messages appear.
I was referring to re-testing the use of grub2-menulst2cfg again, since
it works perfectly here.
If you truly get errors from the grub.cfg produced by it then I would
like to report this upstream. I suspect there is something slightly
unusual in your menu.lst that it can't handle, so we will need both
menu.lst and the output .cfg, plus any error messages that may be useful.
Since your comments earlier I have decided to split out the theme into a
separate package, so that a minimal installation using grub2 will not
pull in the font, image etc.
I have pushed a new version that Suggests: os-prober in the meantime.
So, in future an install of grub2 with --no-suggests will be without a
theme or os-prober, and perform as per the modifications I suggested above.
Thanks for your constructive comments Felix,
Barry
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 02/02/13 05:48, Felix Miata wrote: Good start: 1-/boot/grub2/i386-pc/core.img in a Grub Legacy stanza succeeds Not good from then on: 1-Grub2 error message due to not finding some png file You removed the png by using --no-suggests 2-25 item Grub 2.00 menu (grub.cfg: http://fm.no-ip.com/Tmp/Linux/Mdv/grub.cfg.gx27b-cauldron3-1.txt ). After selecting a selection from a master bootloader, there's no good reason to see similar selections as in the previous menu unrelated to the chosen selection. IOW, when not a master bootloader (i.e. chainloaded via core.img, only Mageia entries attributable to selected filesystem hosting core.img should be in this menu. If that is what you want then:- # urpme os-prober 3-Grub2 menu uses same awful spindly-looking font responsible in large part for my distaste for *buntu Yes could be a lot better, but it's mainly a choice based on licensing, probably will be improved in the future. 4-default menu selection for Cauldron causes this cmdline: BOOT_IMAGE=/boot/vmlinuz-prv root=UUID=bbe8a402-5fb1-4247-b372-5bb6cff4e18c ro splash which is nothing like the default Grub Legacy menu stanza's cmdline result: root=LABEL=22cauldrn splash=verbose noresume video=1152x864 vga=794 3 obviously caused by Grub2 installation disregarding content of pre-existing menu.lst grub2 does not pay any attention to legacy menu.lst - it's a totally different, unrelated bootloader. If you want grub2 to use an existing legacy menu.lst then you can use grub2-menulst2cfg tool to create a grub.cfg from menu.lst. Usage: grub2-menulst2cfg [INFILE [OUTFILE]] 5-semi-legible blue on black graphical progress bar instead of normal complement of startup messages when splash=verbose The font colours were chosen to complement the background image which you chose not to install. 6-post ESC, startup messages are inappropriately tiny Sounds like the same issue I used to have when I was using nvidia graphics with nouveau. Using intel I don't see this. 7-tty text is too tiny to use (same as startup messages; screen's preferred mode 1600x1200 used instead of legible mode 1152x864) Probably configurable in /etc/defaults/grub but off hand I don't know the variable name - should be in the maunual somewhere. 8-KDM is on tty2, the location I reserve for certain class of recurring activities, instead of where expected on tty7 Dunno - I have never seen this. 9-preferred initial runlevel as evidenced by menu.lst cmdline options was not specified Again menu.lst is nothing to do with grub2 10-tty1 cleared before displaying login prompt (even after customizing /etc/systemd/sytem/getty.target.wants/getty@tty1.service with s/TTYVTDisallocate=yes/TTYVTDisallocate=no/; same problem on Rawhide Factory; OT) Such displeasures as 1-9 are the reason why in Grub Legacy vs. Grub2 discussions I point out that Grub2 is still v1.0 software. Just how much of these observations are due to upstream decisions or yet-to-dos rather than distro implementation decisions, implementor inexperience or bugs I won't try to guess. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 31/01/13 21:41, zezinho wrote: Em 31-01-2013 22:26, Maurice Batey escreveu: To be absolutely clear, I have never placed any boot-loader in any PBR on this system. *That* is the information I was after! It appears to confirm that GRUB2 does *not* need GRUB-legacy in a root partition's PBR to be able to boot it. I've just tried a Live Gnome USB install, installing GRUB2 to /dev/sda7 (so in the PBR). This failed crashing draklive installer : https://bugs.mageia.org/show_bug.cgi?id=8903 Yes this is not supported, however if you read /usr/share/doc/grub2/README.Mageia or have a good read at more recent comments in #406 it will become clear ;)
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 31/01/13 22:02, Barry Jackson wrote: On 31/01/13 21:41, zezinho wrote: Em 31-01-2013 22:26, Maurice Batey escreveu: To be absolutely clear, I have never placed any boot-loader in any PBR on this system. *That* is the information I was after! It appears to confirm that GRUB2 does *not* need GRUB-legacy in a root partition's PBR to be able to boot it. I've just tried a Live Gnome USB install, installing GRUB2 to /dev/sda7 (so in the PBR). This failed crashing draklive installer : https://bugs.mageia.org/show_bug.cgi?id=8903 Yes this is not supported, however if you read /usr/share/doc/grub2/README.Mageia or have a good read at more recent comments in #406 it will become clear ;) Oops I meant #416 ;)
[Mageia-dev] freeze push request uhd
Please push uhd new minor version. It only affects gnuradio which I will rebuild against it later. Thanks.
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 29/01/13 00:26, Felix Miata wrote: Does M2 have current Grub2 in backports, or would it be simple enough to install from Cauldron repos? If so, maybe if needed and pressed I could find time to try installing Grub2 to its PBR. I'm not of a mind to replace M2 there yet, and it doesn't have space for a new installation of anything until I figure out what if anything I want to do about its crowded HD. I keep my own backports of stuff that I am interested in, so I have just re-built the current grub2 packages against the current Mageia2 repos for you, you will find them here: http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/2/i586/grub2-2.00-16.mga2.i586.rpm http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/2/x86_64/grub2-2.00-16.mga2.x86_64.rpm I did try to address your question to the lead grub2 dev last night on irc, but he decided to go to bed at that point and suggested that I email it instead ;) Maybe you would like to mail him directly, as you understand the issue better than I do. He is Vladimir Serbinenko: mailto:phcoder!~phco...@60-124.62-81.cust.bluewin.ch Barry
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 29/01/13 12:48, Frank Griffin wrote: I wasn't aware of the MBR gap. I guess you're saying that the core.img that fits in it *is* filesystem-aware ? Yes, depending on the modules built into it, which are normally correct for our purposes. Anyway, my point still stands: for anyone who just wants to have grub and grub2 partitons coexist on the same disk with either one in the MBR, chainloading will accomplish this without any downside that isn't already present in grub legacy. Yes Grub2 may be the way of the future, but to *require* it to own the MBR is just misleading. Yes, it only gives that impression. It does not need to be the primary bootloader. To demonstrate this I made a fresh install of Mageia3 with only grub legacy installed and booted from MBR. I then installed the grub2 package (nothing more) and added an entry for the grub2 bootloader to the grub legacy menu.lst. (as in the README) I then re-booted and selected the grub2 entry from the legacy menu. The grub2 menu launched and contained all my systems - including the new Mageia3. Selecting Mageia3 launched the OS. Likewise selecting Mageia2 (found automatically during install of grub2) launched that correctly. The MBR has not been touched at all since the installation of grub legacy by the Mageia installer. Note that I do not advocate this as a sensible route to multi-booting, since it takes no account of kernel updates - it is just a demonstration. Barry
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 27/01/13 15:24, Maurice Batey wrote: On Sun, 27 Jan 2013 12:31:37 +, Barry Jackson wrote: my master grub2 grub.cfg which is in a small grub partition at the start of sda. How does one acquire a 'small grub partition'? (Just get GRUB2 package to install into an empty partition?) Yes - in a nutshell Create a partition preferably near the start of the drive and label it maingrub then: mkdir -p /maingrub \ mount -L maingrub /maingrub \ grub2-install --root-directory=/maingrub /dev/sda Now the MBR point to maingrub, but there is no menu yet. You can manually create a simple grub.cfg - there are examples in the grub2 documentation - there's a link in the README It won't be pretty, but can be made to look nice with a good colour choice. You could let grub2 create a grub.cfg to get started, but it will be over complicated and point directly to the current kernels which is no use once kernels get updated. You really need entries that multiboot (into grub2) or chainload (into legacy linux). My current grub.cfg is a bit big as I need to remove some old entries, however it may be a good reference for you. The theme references don't work - that was just experimental. http://paste.kde.org/658670/ Copy it quick I think it expires in 24 hours ;) My MBR points to this partition, so all OS's are either chainloaded or multibooted from the manually created entries in this grub.cfg Which do you have in the MBR: GRUB2 or Legacy? Grub2 - have had for the last year or so, but you could also put grub legacy in there as well since they can coexist, then simply re-write one or the other to MBR to switch ;) My limited understanding is that it is similar to chainloading but does not need embedded code in the PBR. Ah,now that's interesting! (I assume you mean 'does not need GRUB2 installed in the PBR') Yes A useful side effect is that grub legacy may be installed to the PBR and used if required, I assume you mean the PBR of the 'small grub partition'. No - I mean that since grub2 is not using the PBR, legacy can, if you wish to have them installed side by side. Mamy thanks, Barry, especially w.r.t to the 'bootloader' partition! Note that the small grub partition is never mounted and never written to by any system (unless you need to modify it of course) This means that no system can screw it up :) - only you :\
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 28/01/13 20:01, Felix Miata wrote:
On 2013-01-28 19:27 (GMT) Barry Jackson composed:
http://svnweb.mageia.org/packages/cauldron/grub2/current/SOURCES/README.Mageia?view=markup
Chainloading into grub2 is not the best way, due to the block lists
problem people keep mentioning and complaining about.
Grub2 can install it's kernel in the root filesystem which can be booted
directly. Installing the grub2 package, whether during install or later
automatically builds /boot/grub/i386-pc/core.img and also creates a
grub.cfg ready for use.
Chanloading is un-necessary since an entry in menu.lst on a legacy
system will boot a grub2 Mageia system using:
title Mageia via GRUB 2
root (hdx,y)
kernel /boot/grub2/i386-pc/core.img
...as explained in the above README.Mageia
I use a small grub2 partition sda1 as master.
To boot into Mageia grub2 systems I use the grub2 multiboot command:
menuentry 'Mageia-3 multi sda6' {
search --no-floppy --label --set=root mageia-3
multiboot /boot/grub2/i386-pc/core.img
}
So IMO all of the FUD about you can't install grub2 to the PBR is
pointless since it's just not necessary.
Maybe not all is FUD. I don't see anything in that README that describes
a procedure for an OS/2 or eCS multibooter whose primary bootloader
and/or bootloader of choice is IBM Boot Manager, which is prerequisite
to booting OS/2 when it is installed to a logical partition (the only
place I've ever installed it in the past decade). It can't be told to
load a particular file on a partition, only its PBR via the simple
process of selecting a partition in its setup utility for inclusion in
its boot menu. It works (in effect, chainloads) fine for partitions on
which Grub Legacy has been configured with the Grub Legacy setup
command. The only options I see for such users is selecting a partition
with Grub Legacy configured with menu.lst stanza(s) that include
core.img, or configuring IBM BM as a secondary bootloader to a primary
bootloader that is not installed on the MBR.
Maybe.
I have no OS/2 systems to test with.
I think grub2 can be forced to write to the PBR (but I can't find it
documented just now).
Maybe you could investigate and test this and suggest an edit to the
README ?
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 28/01/13 20:09, Frank Griffin wrote: ...this is where we disagree slightly ;) Chainloading into grub2 is not the best way, due to the block lists problem people keep mentioning and complaining about. Could you please explain why ? The whole MBR/PBR design was set up so that whatever gets loaded and receives control doesn't know which way it happened. How does grub2 break this ? My limited understanding is that the code in the 512 byte PBR has to use block lists to find the core image in /boot, since it is too small to understand filesystems. This is fragile in that filesystems and file utilities may move files around on disk invalidating the block lists, and for this reason the method is discouraged. A far as I know the same potential problem exists with grub legacy. Whether the same fragility applies to the multiboot approach I am not sure, as documentation is sparse, however grub2 developers agree that it is a valid method. Chanloading is un-necessary I don't claim that it's necessary, just that it's more desirable than requiring the MBR code to go poking around in partitons other than the one from which it was installed. If you're interested in keeping partitions functionally as separate as they can be, it just makes sense to have them booted by their own bootloaders. The MBR code cannot go poking around. It points to one location only. In the case of grub2 this is normally a copy of core.img located in the 'MBR-gap' of around 31kB (or larger depending on partitioning) below the start of the first sector. This then launches the boot menu for the system that created it, or a dedicated grub installation. If the intention is to put the bootloader in the root partition by whatever method, then it has no relation to the MBR. The intention is to boot into the system's bootloader from another primary bootloader. The bootloader built into the core.img in the system root *is* it's own, just as would be the case with chainloading, so I don't really see the distinction. Barry
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 20/01/13 17:42, Maurice Batey wrote:
On Sun, 20 Jan 2013 14:50:06 +, Barry Jackson wrote:
I repeat - Installing the grub2 package
OK - so you differentiate between installing with GRUB2 and
installing the GRUB2 packge?
I am differentiating between # urpmi grub2 and the use of the
grub2-install command.
Does the former include the latter?
Or do you mean one can install with GRUB Legacy and then go on to
install the GRUB2 *package* (which presumably doesn't do anything but
make itself available for the purposes you described)?
Exactly, except that it does create a menu and builds it's kernel
(core.img) which it places in the /boot/grub2 directory ready for use.
It does no more than this and does not affect the existing MBR or PBR in
any way.
This automatically creates core.img in /boot/grub2/i386-pc/ which
allows
you to boot into it from either grub2 using the multiboot command or from
legacy, using the menu entry shown in the readme.
What/where is the 'multiboot command'?
multiboot is a grub2 command to boot using core.img directly.
Below is my entry for Mga3 in my master grub2 grub.cfg which is in a
small grub partition at the start of sda. My MBR points to this
partition, so all OS's are either chainloaded or multibooted from the
manually created entries in this grub.cfg
menuentry 'Mageia-3' {
search --no-floppy --label --set=root mageia-3
multiboot /boot/grub2/i386-pc/core.img
My limited understanding is that it is similar to chainloading but does
not need embedded code in the PBR. Since grub2 can read the filesystem
(with the appropriate modules loaded) it can navigate to the location of
core.img and launch it.
A useful side effect is that grub legacy may be installed to the PBR and
used if required, using:-
menuentry 'Mageia-3 {
search --no-floppy --label --set=root mageia-3
chainloader +1
}
Did you test it in Mageia as described in the README.Mageia ?
The GRUB2 I tried was from Ubuntu 12.01 and Mint 13, not Mageia.
If you add Mageia (grub2) entry to menu.lst as described and boot into
the Grub2 menu it will have all your legacy systems listed. Do they
not boot? .
Good question. The GRUB2-to-Grub Legacy' boots I attempted via GRUB2
in the MBR all failed.
Next time I get the netbook out I will try booting a GRUB Legacy
install via a GRUB Legacy boot menu entry for booting a GRUB2 install.
(Remember, it has GRUB Legacy in the MBR.)
Yes that's fine
But I expect the result to be the same as booting GRUB legacy from
GRUB2 in the MBR.
:\
If the failure to boot was caused by a faulty GRUB2 component, as has
been suggested, then the test will have to await my installing Mageia-3
with GRUB2, which may not happen very soon.
Have fun ;)
Barry
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 21/01/13 17:36, Maurice Batey wrote: On Sun, 20 Jan 2013 20:04:32 +0200, Thomas Backlund wrote: http://svnweb.mageia.org/packages/cauldron/grub2/current/SOURCES/README.Mageia?view=markup Just a one query: To install GRUB 2 to the MBR and create a menu you can use:- # grub2-install /dev/sdX Does create a menu produce a boot menu (grub.cfg) containing entries for all identified already-installed distros - just as is done by the Mageia-3 distro installer? Yes
Re: [Mageia-dev] Feedback on Mageia 3 beta1
On 23/01/13 18:15, Maurice Batey wrote: On Fri, 18 Jan 2013 02:00:11 +0100, Davy Defaud wrote: And the decision to use it as the default bootloader for Mageia 3 was taken several months ago : https://wiki.mageia.org/en/FeatureMageia3_Review https://wiki.mageia.org/en/Feature:Grub2AsDefault Looks as though that decision has been reversed! According to the posting on 2013/01/04 in Comment 27 in: https://bugs.mageia.org/show_bug.cgi?id=8463 Grub2 is not the default bootloader - nor will it be, certainly for the life of Mageai3 - it is a proposed *option*, under test. Maybe I got it wrong, but I still think that's how it will turn out ;)
Re: [Mageia-dev] Freeze push request - python-pygments
On 19/01/13 16:31, Colin Guthrie wrote: 'Twas brillig, and Barry Jackson at 19/01/13 14:51 did gyre and gimble: On 19/01/13 14:41, Barry Jackson wrote: In order to fix https://bugs.mageia.org/show_bug.cgi?id=7906 which is about the poor display of many spec files in ViewVC. We need the latest version of python-pygments which has just been released with RPM spec lexer included. This would also need to be installed on the ViewVC server. The new version is 1.6 rc1 http://pygments.org/download/ It is not in svn yet and I have not yet managed to contact the maintainer (philippem), although I have built it locally, and it's ready to upload. I forgot the questions :/ Will it be possible to include this in Mga3 or should it wait until Mga4 Cauldron? If it waits, then will we be able to install the Cauldron version on the server to fix this bug before Mga4 ? Assuming the upstream is not deprecating anything and is aiming for api compatibility etc. then I think we should probably include it in mga3, but that's just my opinion. Col OK - Since time is passing, I have committed the new version and patched a minor bug. Please can we push python-pygments to fix Bug 7906 so that ViewVC will display spec files correctly. I have changed Subject line accordingly. Thanks
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 20/01/13 12:55, Maurice Batey wrote: On Sun, 20 Jan 2013 07:41:28 -0500, Frank Griffin wrote: According to this article, grub and grub2 each support chainloading the other. So I really don't see why there's a problem Note that he says: I then login to that, edit the menu.lst file as desribed above to add the new Grub2 installation, and then restore Legacy Grub as the primary bootloader So I suspect that he (like me) does not know how to boot a GRUB Legacy install from a GRUB2 boot menu. (Yes, I know GRUB2 boot menus do show options to boot existing GRUB Legacy installs, but in my experience (with Ubuntu and Mint) they *fail* to boot them.) Despite my requests in various newsgroups, NO ONE has offered a description of how to get a GRUB2 boot menu to successfully boot a GRUB Legacy install. Can you, please, Frank? There is no problem at all. Your issues with Ubuntu etc in the past were probably due to a bug in os-prober which was fixed in version 1.53. Mageia grub2 will correctly detect and boot legacy grub systems. If you install the grub2 package (assuming you did not at install time) then you can test this quite easily. Installing the grub2 package will not impact your current bootloader in any way. Once it's installed read /usr/share/doc/grub2/README.Mageia to find how to add an entry to your existing menu.lst to boot into the new grub2 menu from your existing legacy grub. Barry
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 20/01/13 13:30, Maurice Batey wrote: On Sun, 20 Jan 2013 13:08:57 +, Barry Jackson wrote: Installing the grub2 package will not impact your current bootloader in any way. Installing GRUB2 where, Barry? (MBR or Root partition?) I repeat - Installing the grub2 package This automatically creates core.img in /boot/grub2/i386-pc/ which allows you to boot into it from either grub2 using the multiboot command or from legacy, using the menu entry shown in the readme. If - as I did with Ubuntu 12.01 - GRUB2 goes into the MBR, then I can no longer boot from its menu into a GRUB Legacy install, a I said earlier (despite the GRUB2 boot menu purporting to do so). Works for me. Once it's installed read /usr/share/doc/grub2/README.Mageia to find how to add an entry to your existing menu.lst to boot into the new grub2 menu from your existing legacy grub. As I said earlier, I already know how to do that. What I still don't know (and still no one has described!) is how to get a GRUB2 boot menu to successfullly boot a GRUB Legacy install. Did you test it in Mageia as described in the README.Mageia ? If you add Mageia (grub2) entry to menu.lst as described and boot into the grub2 menu it will have all your legacy systems listed. Do they not boot? All mine do.
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 19/01/13 11:42, André Salaün wrote: So it'is a fud launched by grub2 developpers when they recommend installing it only on the MBR. No not at all, done that way it is open to the filesystem moving the files and breaking the boot. The same is apparently true in legacy, but it rarely poses a problem. What I am saying is that I don't see this as a limitation. If core.img is placed in the filesystem, as is done when our grub2 (package) is installed, and if the primary bootloader can read that filesystem (i.e. has the correct modules loaded) then it can find, read and multiboot using that core.img. See README.Mageia in the grub2 package. Since the apparition of grub2 all that is almost unclear. Yes - documentation has not been a strong point of grub2 in the past but it has improved dramatically in recent months. Lack of communication or understandability I don't know but the fact is that grub2 is a problem for many users. Most of those user reports are old - many bugs have been fixed and features have improved recently. Much bad press was caused by a nasty bug in os-prober which broke multi-booting of legacy installations from grub2 - it was fixed in 1.53 which was the version we originally imported. If we add EFI UEFI (of course not linux fault) it is a easyless installing one or different Gnu/linux systems than 3 years ago. True - we do also have a grub2-efi which has had limited testing, however I know nothing about efi :/ But perhaps I am a stupid linux user since 13 or 14 years and I should have to buy Apple product or W8 ;-) :)
Re: [Mageia-dev] Freeze push request - python-pygments
On 20/01/13 16:47, Thomas Backlund wrote: Submitted. -- Thomas Thanks, Can this now be installed on whichever server serves ViewVC to fix the display of RPM Specs? Barry
[Mageia-dev] Update question about python-pygments
In order to fix https://bugs.mageia.org/show_bug.cgi?id=7906 which is about the poor display of many spec files in ViewVC. We need the latest version of python-pygments which has just been released with RPM spec lexer included. This would also need to be installed on the ViewVC server. The new version is 1.6 rc1 http://pygments.org/download/ It is not in svn yet and I have not yet managed to contact the maintainer (philippem), although I have built it locally, and it's ready to upload.
Re: [Mageia-dev] Update question about python-pygments
On 19/01/13 14:41, Barry Jackson wrote: In order to fix https://bugs.mageia.org/show_bug.cgi?id=7906 which is about the poor display of many spec files in ViewVC. We need the latest version of python-pygments which has just been released with RPM spec lexer included. This would also need to be installed on the ViewVC server. The new version is 1.6 rc1 http://pygments.org/download/ It is not in svn yet and I have not yet managed to contact the maintainer (philippem), although I have built it locally, and it's ready to upload. I forgot the questions :/ Will it be possible to include this in Mga3 or should it wait until Mga4 Cauldron? If it waits, then will we be able to install the Cauldron version on the server to fix this bug before Mga4 ?
Re: [Mageia-dev] Feedback on Mageia 3 beta1
On 18/01/13 12:38, Maurice Batey wrote: So be it, but the Mageia-3 installer will provide an *option* to use GRUB Legacy, won't it? Yes :)
[Mageia-dev] Freeze push request - gnuradio
Please push the new version of gnuradio - just released. It does not impact other packages, it fixes some bugs and has new features that would be good to have in Mageia 3, as the current version we have is quite old. It builds OK in iurt locally and basic functional tests are OK. It's in svn ready to submit. Thanks.
Re: [Mageia-dev] [RPM Groups] RPM group change before Beta 2 (Reposted in new thread)
On 06/01/13 19:21, Balcaen John wrote: Did you try to simply send an email to Luc Menut, Nicolas Lecureuil or me for that purpose ? No, but here is a list. Maybe some are fixed in svn, but have not been pushed - I don't have time to check just now. audiokonverter k4guitune konvertible kradio basket kmplayer kmplayer-npplayer kubeplayer
Re: [Mageia-dev] Booting on GPT + UEFI + Secure Boot...
On 07/01/13 11:36, Pascal Terjan wrote: On Mon, Jan 7, 2013 at 11:31 AM, Olivier Thauvin nanar...@nanardon.zarb.org wrote: Hello again, I just buy a wonderfull HP ENVY23 smartscreen. It has: - Windows 8 (I'd like to keep it) - GPT Formated disk (2T) - UEFI - SecureBoot I am trying to install a Mageia on it: I disabled secure boot. I succeed to boot using PXE (using legacy boot) and to install mageia2, but it failed to boot on Mageia using legacy boot. Do you know how it fails? So questions: - is it possible to boot Mageia using legacy boot on GPT disk ? Yes (using grub, not lilo) - is it possible to boot Mageia using UEFI ? I think so but I have never tried. I remember someone reporting success. The grub2-efi package in Cauldron has a README.efi file that may be useful. (Note efibootmgr package referred to is also in Cauldron) The author of that README file has been using Mageia with grub2-efi on a Mac for some time now.
Re: [Mageia-dev] [RPM Groups] RPM group change before Beta 2 (Reposted in new thread)
On 05/01/13 22:48, Pierre-Malo Deniélou wrote: Any remarks? Suggestions? Cheers, I have been plodding along updating what I can, but it's slow as many need patching to fix build failures. Also there are many KDE packages which I have avoided touching, as KDE maintainers tend to get upset when packages are interfered with. Could some process be adopted where KDE packages may be updated and a nominated KDE reviewer be notified to push them and help speed things up a bit?
Re: [Mageia-dev] ARM port?
On 23/12/12 12:18, magnus wrote: Is there any work on the ARM port? I would prefer a Mageia on my new Raspberry Pi. +1 So would I. (but Fedora-remix works well) :)
Re: [Mageia-dev] Packages for review
On 02/12/12 09:37, Joseph Wang wrote: Can someone check the following package submissions quantlib python-pyp2rpm leocad leocad-data Also, does anyone object if I add the following to task-games? vassal simutrans leocad (once it gets run) Joseph I notice that some e.g. quantlib (I didn't look at all) of your specs are missing proper tabbed (or spaced) indentation. example here http://paste.kde.org/618332/ quantlib: There is a dot ending summary(s) svn should be part of release not version and I don't think the %if...%endif is going to work as you expect.
Re: [Mageia-dev] Packages for review
On 02/12/12 12:42, Barry Jackson wrote:
On 02/12/12 09:37, Joseph Wang wrote:
Can someone check the following package submissions
quantlib
python-pyp2rpm
leocad
leocad-data
Also, does anyone object if I add the following to task-games?
vassal
simutrans
leocad (once it gets run)
Joseph I notice that some e.g. quantlib (I didn't look at all) of your
specs are missing proper tabbed (or spaced) indentation.
example here http://paste.kde.org/618332/
quantlib:
There is a dot ending summary(s)
svn should be part of release not version and I don't think the
%if...%endif is going to work as you expect.
The %if is OK ignore my last comment ;)
Attached is a patch that shows a possible approach regarding the Release
tag.
Index: SPECS/quantlib.spec
===
--- SPECS/quantlib.spec (revision 325459)
+++ SPECS/quantlib.spec (working copy)
@@ -1,11 +1,11 @@
%define svn 0
-%define baseversion 1.2.1
+%define rel 1
%define major 0
%if %svn
-%define version %{baseversion}.svn%{svn}
+%define release %mkrel -c %{svn} %{rel}
%else
-%define version %{baseversion}
+%define release %mkrel %{rel}
%endif
# Define some specific macros
@@ -15,8 +15,8 @@
Summary: The free/open-source library for quantitative finance.
Name: quantlib
-Version: %{version}
-Release: %mkrel 1
+Version: 1.2.1
+Release: %{release}
License: BSD License
Group: System/Libraries
Vendor: QuantLib.org
@@ -29,6 +29,7 @@
URL: http://quantlib.org/
BuildRequires: boost-devel = 1.34.1
BuildRequires: doxygen = 1.3, graphviz
+BuildRequires: emacs
%define libname %mklibname %{name} 1
%define libname_devel %mklibname -d %{name}
@@ -77,7 +78,7 @@
pre-constructed test cases, and helps in validating the library.
%prep
-%setup -q -n QuantLib-%{baseversion}
+%setup -q -n QuantLib-%{version}
%apply_patches
%build
Re: [Mageia-dev] Regression in menus
On 29/11/12 19:14, Pierre Jarillon wrote: I just install pcb which is a part of gEDA project. It belongs to Menus-sciences with gschem which is already in this group. OK I see the problem - I filed a bug. https://bugs.mageia.org/show_bug.cgi?id=8257
Re: [Mageia-dev] Regression in menus
On 29/11/12 17:12, Pierre Jarillon wrote: I have found some drawbacks in menus. 1- In games, klickety is in strategy but in rpmdrake, it is in plateau with kmines. 2- I have installed gEDA. It does not appears in menus. In Mageia 1, it appears in Sciences. Have you found other things like this? In the menu look under: Engineering/Electronics I have not installed to test, but looking at the source that's where they should be. Bear in mind that rpm groups are not related to menu categories. When installing the choices are divided into rpm groups which are currently being re-vamped for Mageia 3. The current rpm group for this package is Sciences/Other, The menu category is Engineering/Electronics. I hope that helps.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release libqwt-6.0.1-2.mga3
On 20/11/12 22:11, zezinho wrote: Em 20-11-2012 18:16, Nicolas Lécureuil escreveu: Le mardi 20 novembre 2012 17:13:14 Barry Jackson a écrit : Also, to quote library policy: The goal is to be able to install libfoo1 and libfoo2 on the same system. [root@jackodesktop baz]# urpmi lib64qwt6 installing lib64qwt6-6.0.1-4.mga3.x86_64.rpm from /var/cache/urpmi/rpms Preparing... ## Installation failed:file /usr/lib64/qt4/plugins/designer/libqwt_designer_plugin.so from install of lib64qwt6-6.0.1-4.mga3.x86_64 conflicts with file from package lib64qwt5-5.2.2-4.mga3.x86_64 because those files have nothing to do in a versionned libs. = Packaging errors. Where should they be? For now, I have removed this file from libqwt5 to allow installing both in the same system. Should I create a sub package named qwt-designer-plugin ? As I see it this would not work as the sub-package would need to be in both packages thus causing another conflict. I suspect there is no difference between the two plugin builds so maybe one separate plugin package built using the latest tarball, but I really don't know - maybe ask upstream ?
Re: [Mageia-dev] What the hell is wrong with MGA2s suspend/sleep/hibernate?
On 20/11/12 12:47, Frank Griffin wrote: On 11/20/2012 07:32 AM, Johnny A. Solbu wrote: Note: This is Not the automatic sleep/hibernation after X min of inactivity. This is hibernation by accidently pressing the «SLEEP» key on a keyboard. Ah, didn't realize that you wanted to disable the Sleep capability even when explicitly requested. Remap the key ? Johnny, What's the output of # systemctl status network.service ? Does it show as disabled? If so try: # systemctl enable network.service systemctl start network.service otherwise # systemctl start network.service should start it. If all that fails then you may see some clues in the short log attached to the status.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release libqwt-6.0.1-2.mga3
Also, to quote library policy: The goal is to be able to install libfoo1 and libfoo2 on the same system. [root@jackodesktop baz]# urpmi lib64qwt6 installing lib64qwt6-6.0.1-4.mga3.x86_64.rpm from /var/cache/urpmi/rpms Preparing... ## Installation failed:file /usr/lib64/qt4/plugins/designer/libqwt_designer_plugin.so from install of lib64qwt6-6.0.1-4.mga3.x86_64 conflicts with file from package lib64qwt5-5.2.2-4.mga3.x86_64
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release libqwt-6.0.1-2.mga3
On 20/11/12 17:16, Nicolas Lécureuil wrote: Le mardi 20 novembre 2012 17:13:14 Barry Jackson a écrit : Also, to quote library policy: The goal is to be able to install libfoo1 and libfoo2 on the same system. [root@jackodesktop baz]# urpmi lib64qwt6 installing lib64qwt6-6.0.1-4.mga3.x86_64.rpm from /var/cache/urpmi/rpms Preparing... ## Installation failed:file /usr/lib64/qt4/plugins/designer/libqwt_designer_plugin.so from install of lib64qwt6-6.0.1-4.mga3.x86_64 conflicts with file from package lib64qwt5-5.2.2-4.mga3.x86_64 because those files have nothing to do in a versionned libs. = Packaging errors. Hi - thanks. Ah, so are you saying that file should be in maybe a qwt-designer-plugin package? Also I don't see how libqwt (6) and libqwt5 can be maintained from one spec. How can an update be made to libqwt5 now that the spec is modified for 6 ? This is not my package and I really don't have time for all this hassle. This change has broken several packages all of which were previously working. Can this mess be reverted and started again with some prior planning and testing?
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release libqwt-6.0.1-2.mga3
On 20/11/12 19:03, Barry Jackson wrote: Also I don't see how libqwt (6) and libqwt5 can be maintained from one spec. How can an update be made to libqwt5 now that the spec is modified for 6 ? Doh! - OK there are now two srpms - hadn't looked.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release libqwt-6.0.1-2.mga3
On 18/11/12 15:28, Jani Välimaa wrote:
On Sun, 18 Nov 2012 17:15:13 +0200
Sander Lepik sander.le...@eesti.ee wrote:
18.11.2012 16:52, zezinho kirjutas:
Now to fix the mess:
- create libqwt5 package
Done, but cannot submit it because a libqwt5 package already
exists. Any hint?
You can't submit it because your main package (Name: libqwt5) and
library package for i586 (%define libname %mklibname qwt %{major})
have the same name. As main package contains no files i would
probably rename it to qwt (Name %realname), but i'm not 100% sure if
that's the right thing to do. Packagers with more knowledge may have
better ideas.
Renaming also affects to the src pkg name and IMHO it's not how it
should be done.
Just remembered one similar case. Dunno if this helps, but look how it's
made in libraw1394_8 pkg.
http://svnweb.mageia.org/packages/cauldron/libraw1394_8/current/SPECS/libraw1394_8.spec?revision=302617view=markup
Oh dear :/
After a (local) rebuild of gnuradio :-
[baz@jackodesktop ~]$ urpmq --requires-recursive gnuradio | grep qwt
lib64qwt5
lib64qwt6
python-qwt
[baz@jackodesktop ~]$ urpmq --requires-recursive python-qwt | grep qwt
lib64qwt5
python-qwt
[baz@jackodesktop ~]$ urpmq --whatrequires lib64qwt5
lib64gnuradio-qtgui0
lib64qwt5
lib64qwt5-devel
lib64smokeqwt3
python-qwt
qgis
scidavis
[baz@jackodesktop ~]$ urpmq --whatrequires lib64qwt6
lib64gnuradio-qtgui0
lib64gnuradio-qtgui0
lib64qwt-devel
lib64qwt6
qloud
Prior to rebuild:-
[baz@jackodesktop ~]$ urpmq --requires-recursive gnuradio | grep qwt
lib64qwt5
python-qwt
[baz@jackodesktop ~]$ urpmq --requires-recursive python-qwt | grep qwt
lib64qwt5
python-qwt
[baz@jackodesktop ~]$ urpmq --whatrequires lib64qwt5
lib64gnuradio-qtgui0
lib64qwt5
lib64qwt5-devel
lib64smokeqwt3
python-qwt
qgis
scidavis
Ping me when it's sorted out and I will rebuild python-qwt and gnuradio.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release libqwt-6.0.1-2.mga3
On 19/11/12 19:21, Jani Välimaa wrote: On Mon, 19 Nov 2012 18:57:21 + Barry Jackson zen25...@zen.co.uk wrote: Ping me when it's sorted out and I will rebuild python-qwt and gnuradio. It's all sorted out. Python-qwt is now build against the old libqwt5 [1]. Maybe you should build gnuradio against the old one (libqwt5-devel) too.. [1] http://svnweb.mageia.org/packages/cauldron/python-qwt/current/SPECS/python-qwt.spec?revision=319494view=markup Well there still seems to be something wrong. The gnuradio spec originally had: Buildrequires: libqwt-devel That now pulls in libqwt6, while python-qwt is using libqwt5. If I use: BuildRequires: libqwt5-devel in the spec, it builds OK, but rpmlint (run on the srpm) says: W: invalid-build-requires libqwt5-devel and $ urpmq --requires-recursive gnuradio | grep qwt lib64qwt5 lib64qwt6 python-qwt So it's requiring a mix of majors which does not look good :\ If I remove the BuildRequire on libqwt the build fails as qwt is not found during the CMake configure. Maybe someone can see something in the build log: http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/log/gnuradio-3.6.2-4.mga3.src.rpm/build.0.2012112514.log This is the deps -install log, and I see nothing libqwt6 related. http://mtf.no-ip.co.uk/pub/linux/barjac/distrib/cauldron/x86_64/log/gnuradio-3.6.2-4.mga3.src.rpm/install_deps-1.0.2012112514.log Those are both from a successful build with BuildRequires: libqwt5-devel in the spec. It's late I'll sleep on it, been at this all day - gnuradio is a long build :(
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release grub2-2.0-5.mga3
On 11/10/12 09:16, Olav Vitters wrote: On Wed, Oct 10, 2012 at 11:12:31PM +0200, barjac wrote: Name: grub2Relocations: (not relocatable) Packager: barjac barjac URL : alpha.gnu.org/pub/gnu/grub/ That is not an URL. Indeed No idea how that happened or why I never noticed :\ Thanks - fixed.
Re: [Mageia-dev] On new rpm group
On 15/11/12 22:10, Reinout van Schouwen wrote: Funda Wang schreef op vr 09-11-2012 om 16:50 [+0800]: Hello, I noticed that there are two rpm group named 'Geography' and 'Sciences/Geosciences'. Are there any differences? It would appear to me that geography is more concerned with the names and locations of places whereas geosciences is the quest for knowledge of the Earth's composition, rock layers, sediments etcetera. regards, I think the geosciences group was aimed at satnav, gps and mapping for example but I may be wrong - I recall some discussion on irc.
Re: [Mageia-dev] On new rpm group
On 15/11/12 22:56, Pierre-Malo Deniélou wrote: That's the opposite ... Geography is for the satnav, gps and mapping softs, while Geoscience are for all geology, climate, oceanography related software. /o\ ;)
Re: [Mageia-dev] Small project for a Python programmer
On 11/11/12 17:35, 1 wrote: Barry Jackson zen25000@... writes: What is needed is a lexer for rpm spec files. https://bitbucket.org/birkenfeld/pygments-main/pull-request/124 Thanks for the heads up - good. I guess that this will take time to filter through to a release version?
Re: [Mageia-dev] Barry's cronsync script - Bugs
On 05/11/12 19:36, Johnny A. Solbu wrote:
I have problems customizing it for my own use. (I'm testiing manually for the
time being)
It won't exclude the things I say it should exclude.
My copy have this line:
==
myexcludes=--exclude={debug/,backports_testing,updates_testing/}
==
It does Not exclude them. (Note that I am excluding all debug and _testing
folders, but Not SRPMS)
That line used in my manuall rsync command, works. They are excluded.
So, why won't this work in cronsync?
Hi Johnny,
Sorry for delay - I missed the post.
It's your syntax.
This works using your excludes with the syntax in line 20 of this new
script.
http://paste.kde.org/598076/
I fixed another bug and changed it slightly to better display rsync
errors in the log.
I have not seen any problems recently and it's running every hour. It
currently keeps a filecount history log as well, but that's just for
interest and testing.
The problem with your syntax seems to be related to the {} - I don't
fully understand why, but it causes a pair of ' to be wrapped around the
--exclude option in the final rsync command :
rsync -rlptgoDhHSn --stats --delete-after --delete-excluded
--protect-args '--exclude={debug/,backports_testing,updates_testing/}'
rsync://distrib-coffee.ipsl.jussieu.fr:/pub/linux/Mageia/distrib
/zmrepo/pub/linux/Mageia/
With my syntax it appears like this:-
rsync -rlptgoDhHSn --progress --stats --delete-after --max-delete=1000
--delete-excluded --protect-args --exclude=debug
--exclude=backports_testing --exclude=updates_testing
rsync://distrib-coffee.ipsl.jussieu.fr:/pub/linux/Mageia/distrib
/zmrepo/pub/linux/Mageia/
Regards
Barry
Re: [Mageia-dev] Barry's cronsync script - Bugs
Damn!! I left a 'n' (dry run) on the options in the live run section after testing on line 148 - just remove it once you are happy with it. I'll paste it again later. Barry
Re: [Mageia-dev] Barry's cronsync script - Bugs
On 06/11/12 14:18, Barry Jackson wrote: Damn!! No thrice damn!! - I did remove it but from the wrong section (line 109). Ignore the previous paste as it's dangerous. This *is* correct. http://paste.kde.org/598106/ I think I need more sleep :\
Re: [Mageia-dev] Distrib-coffee big failure of the century
On 31/10/12 22:53, Johnny A. Solbu wrote: On Wednesday 31 October 2012 23:29, Barry Jackson wrote: I wrote the attached script. It checks several mirrors until it finds one that has the normal number of files and does not fail for any other reason. If you feel inclined to use it please feel free to suggest any improvements. The script was caught in one of my spam and attachment protection cript, Anomy. One of the first lines was mangled. So if you could repost that second line, I'd be gratefull. === #!/bin/sh echo DEFANGED.266 exit === Oh dear :( It's here:- http://paste.kde.org/587408/13517591/ (Switch to 'raw code' view before copy/pasting)
Re: [Mageia-dev] Distrib-coffee big failure of the century
I fixed a bug and cleaned up some clunky bash, so use this:- http://paste.kde.org/587864/51779286/ It's half way there :) From ~/cronsync_error.log :- 01/11/2012-14:05: Only 79199/141855 files in rsync://distrib-coffee.ipsl.jussieu.fr:/pub/linux/Mageia/distrib
Re: [Mageia-dev] Distrib-coffee big failure of the century
On 01/11/12 19:58, Johnny A. Solbu wrote: Why do you have both «--delete-after» and « --delete»? The last one is redundant, and should be dropped. :-)= Thanks, I missed the (which is implied) in the man pages. There was a useful file error (fixed now) in distrib-coffee after it completed syncing that threw up another small error reporting bug in the script which I have fixed here: http://paste.kde.org/588050/02691135/ See how it goes :)
Re: [Mageia-dev] Distrib-coffee big failure of the century
On 01/11/12 20:51, Barry Jackson wrote:
See how it goes :)
Last update - honest - added proper file lock as the existing method was
flakey - it's finished and I'm leaving it alone now :)
Attached and also here:-
http://paste.kde.org/588158/12522135/
#!/bin/bash
# ~/cronsync by barjac
# Run with e.g. crontab:- 30 * * * *$HOME/cronsync
# Set using crontab -e
###
# List of mirrors in preference order to use:-
mymirrors=( \
rsync://distrib-coffee.ipsl.jussieu.fr:/pub/linux/Mageia/distrib \
rsync://ftp.LinuxCabal.org/Mageia/distrib \
rsync://fr2.rpmfind.net/linux/mageia/distrib \
rsync://ftp.acc.umu.se/mirror/mageia/distrib \
rsync://mirrors.kernel.org:/mirrors/mageia/distrib \
rsync://mageia.c3sl.ufpr.br/mageia/distrib \
)
# Set limit for loss of # of files on server before it is skipped
allowdropfiles=100
###
# Personal config:-
myexcludes=--exclude=debug --exclude=SRPMS --exclude=barjac
mydestination=/zmrepo/pub/linux/Mageia/
###
# Set minimum files for first run only
[[ -f .cronsync ]] || echo 14 $HOME/.cronsync
# Get minimum file count for mirror (set at allowdropfiles files less than the
last actual file count)
minfiles=$(cat .cronsync)
((actualfiles = $minfiles + $allowdropfiles))
# Function to output formatted date
dte()
{
echo -n $(date +%d/%m/%Y-%H:%M)
}
# Check a mirror
chk_mirror()
{
echo Checking $1 ...
rsync -rlptgoDhHSn \
--stats \
--delete-after \
--delete-excluded \
--protect-args \
$myexcludes \
$1 \
$mydestination $lockdir/cronsync_tmp_output
status=$?
files=$(cat $lockdir/cronsync_tmp_output | grep Number of files: | cut -d' '
-f4 )
[[ $files -lt $minfiles ]] echo $(dte): Only $files/$actualfiles files in
$1 | tee -a $HOME/cronsync_error.log
[[ $status 0 ]] echo $(dte): Error: $status while checking $1 | tee -a
$HOME/cronsync_error.log
([[ $status = 0 ]] [[ $files -gt $minfiles ]]) || return 1
# Save new minimum file count
((minfiles = $files - $allowdropfiles))
echo $minfiles $HOME/.cronsync
return 0
}
# Loop through mirror list checking until one succeeds
find_good_mirror()
{
for mirr in ${mymirrors[@]}; do
chk_mirror $mirr { echo Found good mirror - $mirr; return 0; }
done
echo $(dte): Can't find a good mirror - aborting | tee -a
$HOME/cronsync_error.log
return 1
}
### Main routine starts here
# Avoid running two instances concurrently
lockdir=/tmp/cronsync.lock
if mkdir $lockdir; then
trap 'rm -rf $lockdir' 0
# Find a good mirror from the list (with files in it)
find_good_mirror || exit 1
# Live run with --max-delete set to 1000 just in case ;)
echo Syncing from $mirr ...
rsync -rlptgoDhHS \
--progress \
--stats \
--delete-after \
--max-delete=1000 \
--delete-excluded \
--protect-args \
$myexcludes \
$mirr \
$mydestination | tee $HOME/cronsync_last.log
status=${PIPESTATUS[0]}
[[ $status = 0 ]] || { echo $(dte): Live run rsync error: $status
$HOME/cronsync_error.log; exit 1; }
echo Update complete
else
echo $(dte): cronsync already running or stale lock - skipping update - check
/tmp/cronsync.lock $HOME/cronsync_error.log
exit 0
fi
### End of cronsync
Re: [Mageia-dev] Distrib-coffee big failure of the century
On 30/10/12 21:49, Barry Jackson wrote:
On 30/10/12 21:29, Johnny A. Solbu wrote:
On Tuesday 30 October 2012 22:21, Barry Jackson wrote:
I will set --max-delete=500 locally in future.
Any better ideas?
I always run rsync manually twice. The first run I use «-n» to make
sure my mirror isn't wiped, and then run rsync normally.
I run it from a cron job via a script, so I could parse the output of a
dry run and count deletes for example, then let it decide whether to run
or not.
Thanks - worth investigating :)
I wrote the attached script. It checks several mirrors until it finds
one that has the normal number of files and does not fail for any other
reason.
Currently I have distrib-coffee at the top of the possible mirror list,
but it is skipped because it only has a fraction of the files yet.
It creates a couple of logs and runs as a cron job (or manually).
If you feel inclined to use it please feel free to suggest any improvements.
I certainly feel safer now.
Barry
#!/bin/bash
# ~/cronsync
# Run with e.g. crontab:- 30 * * * *$HOME/cronsync
# Set using crontab -e
###
# List of mirrors in preference order to use:-
mymirrors=( \
rsync://distrib-coffee.ipsl.jussieu.fr:/pub/linux/Mageia/distrib \
rsync://ftp.LinuxCabal.org/Mageia/distrib \
rsync://ftp.acc.umu.se/mirror/mageia/distrib \
rsync://mirrors.kernel.org:/mirrors/mageia/distrib \
rsync://mageia.c3sl.ufpr.br/mageia/distrib \
)
# Set limit for loss of # of files on server before it is skipped
allowdropfiles=100
###
# Personal config:-
myexcludes=--exclude=debug --exclude=SRPMS --exclude=barjac
mydestination=/zmrepo/pub/linux/Mageia/
###
# Get minimum file count for mirror (set at allowdropfiles files less than the
last actual file count)
[[ -f .cronsync ]] || echo 14 $HOME/.cronsync
minfiles=$(cat .cronsync)
((actualfiles = $minfiles + $allowdropfiles))
# Check a mirror
chk_mirror()
{
echo Checking $1 ...
chkout=$(rsync -rlptgoDhHSn \
--stats \
--delete-after \
--delete \
--delete-excluded \
--protect-args \
$myexcludes \
$1 \
$mydestination | grep Number of files: )
status1=$?
files=$(echo $chkout | cut -d' ' -f4)
[[ $files -lt $minfiles ]] echo $(date +%d/%m/%Y-%H:%M): Only
$files/$actualfiles files in $1 ! | tee -a $HOME/cronsync_error.log
[[ $status1 0 ]] echo $(date +%d/%m/%Y-%H:%M): Error: $status1 while
checking $1 | tee -a $HOME/cronsync_error.log
([[ $status1 = 0 ]] [[ $files -gt $minfiles ]]) || return 1
((chkcount = $files - $allowdropfiles))
echo $chkcount $HOME/.cronsync
return 0
}
# Loop through mirror list checking until one succeeds
find_good_mirror()
{
for mirr in ${mymirrors[@]}; do
chk_mirror $mirr
[[ $? = 0 ]] { echo Found good mirror - $mirr; return 0; }
done
return 1
}
#===Main Program starts here=
# Check if rsync is already running (maybe last cron sync taking for ever?)
ps aux | grep -q [r]sync
if [[ $? 0 ]]; then
# Find a good mirror from the list (with files in it)
find_good_mirror || { echo $(date +%d/%m/%Y-%H:%M) Can't find a good mirror -
aborting | tee -a $HOME/cronsync_error.log; exit 1; }
echo Syncing from $mirr ...
# Live run with --max-delete set to 1000 just in case ;)
rsync -rlptgoDhHS \
--progress \
--stats \
--delete-after \
--delete \
--max-delete=1000 \
--delete-excluded \
--protect-args \
$myexcludes \
$mirr \
$mydestination | tee $HOME/cronsync_last.log
status=$?
[[ $status = 0 ]] { echo Update complete; exit 0; }
[[ $status 0 ]] { echo Live run error - $(date +%d/%m/%Y-%H:%M) =
$status $HOME/cronsync_error.log; exit 1; }
else
echo rsync already running, skipping update - $(date +%d/%m/%Y-%H:%M)
$HOME/cronsync_error.log
exit 1
fi
Re: [Mageia-dev] Distrib-coffee big failure of the century
On 30/10/12 20:16, Olivier Thauvin wrote: I do my best to restore the service as soon as possible. At time, 26GB of Mageia are restored. Regards. Good news! I switched temporarily to rsync://fr2.rpmfind.net but now find that it is also now empty. It was working OK for most of the day. I lost some files from my personal mirror when rsync://fr2.rpmfind.net was wiped, but killed rsync just in time. Using --delete-after it's not easy to avoid this happening, but a safety net is needed to stop all downstream mirrors following suit when a disaster happens. I will set --max-delete=500 locally in future. Any better ideas?
Re: [Mageia-dev] Distrib-coffee big failure of the century
On 30/10/12 21:29, Johnny A. Solbu wrote: On Tuesday 30 October 2012 22:21, Barry Jackson wrote: I will set --max-delete=500 locally in future. Any better ideas? I always run rsync manually twice. The first run I use «-n» to make sure my mirror isn't wiped, and then run rsync normally. I run it from a cron job via a script, so I could parse the output of a dry run and count deletes for example, then let it decide whether to run or not. Thanks - worth investigating :)
[Mageia-dev] Small project for a Python programmer
OK here's the challenge. When we view rpm specs in svn using viewvc like this :- http://svnweb.mageia.org/packages/cauldron/acidrip/current/SPECS/acidrip.spec?view=markup ...the highlighting is incorrect, because viewvc uses pygments to generate the language highlighting and it sadly has no lexer for rpm spec files. In many cases the highlighting is totally wrong like this:- http://svnweb.mageia.org/packages/cauldron/abiword/current/SPECS/abiword.spec?revision=304568view=markup ...as viewvc makes an incorrect assumption about the lexer needed, based on a parse of the first line. It's horrible. What is needed is a lexer for rpm spec files. This would not be too difficult for an experienced Python programmer as the building blocks are all in place within pygments :- http://pygments.org/docs/lexerdevelopment/ If you view any spec file using the kate editor, you will see the style of highlighting that is needed. Not only would this benefit Mageia, but all projects using rpm and viewvc. So that's the challenge - anyone up for it? :)
Re: [Mageia-dev] Notes about live CD
On 26/10/12 12:46, Wolfgang Bornath wrote: 2012/10/26 Olivier Blin mag...@blino.org: JA Magallón jamagal...@ono.com writes: - the installer asks to remove the unused harware support, but the wording for the choice is misleading: [ ] Unsued hardware support What does it really mean if I tick this, I want to keep the unused hw support or to remove it ? The text reads this way: We will remove the following packages, unless you choose otherwise: [ ] Unused hardware support [ ] Unused localization Yes, still I was puzzled for a moment as well. To me this is a correct choice of words but it is not the best to be un-misunderstandable. I agree to JA's suggestion to improve this. It's like the question when you want to disable the firewall. First line in the assistent says ALL which is logical correct but it is better understandable with the additional (no firewall) Yes exactly - I have always felt that this is confusing. Maybe:- We will remove the following packages, unless you choose otherwise: [ ] Check to remove unused hardware support [ ] Check to remove unused localization
Re: [Mageia-dev] Firefox 16 - security issue - withdrawn
On 11/10/12 18:59, AL13N wrote: Op donderdag 11 oktober 2012 19:19:33 schreef Sander Lepik: 11.10.2012 18:32, Barry Jackson kirjutas: On 11/10/12 12:29, Sander Lepik wrote: 11.10.2012 13:58, Barry Jackson kirjutas: http://www.bbc.co.uk/news/technology-19909106 Maybe we should revert in Cauldron? Well, it's cauldron and the bug will be fixed before we get it reverted. We just have to wait a day or two. 16.0.1 candidate is already uploaded, so the bug is probably already fixed.. True - however since I use Cauldron 24/7 I have reverted to 15.0.1 and added it to skip.list for my own peace of mind ;) Barry So, instead of 1 security hole you now have 14 (most of them critical :http://www.mozilla.org/security/known-vulnerabilities/firefox.html#firefox1 :6)? ;P Not sure if it's safer or not :) -- Sander the thing is: 1 very new one, or 14 old ones... that's the trick... 1 for which only very very recently an exploit and 14 widespread exploits Point taken - it was fixed very quickly.
[Mageia-dev] Firefox 16 - security issue - withdrawn
http://www.bbc.co.uk/news/technology-19909106 Maybe we should revert in Cauldron?
Re: [Mageia-dev] Firefox 16 - security issue - withdrawn
On 11/10/12 12:29, Sander Lepik wrote: 11.10.2012 13:58, Barry Jackson kirjutas: http://www.bbc.co.uk/news/technology-19909106 Maybe we should revert in Cauldron? Well, it's cauldron and the bug will be fixed before we get it reverted. We just have to wait a day or two. 16.0.1 candidate is already uploaded, so the bug is probably already fixed.. -- Sander True - however since I use Cauldron 24/7 I have reverted to 15.0.1 and added it to skip.list for my own peace of mind ;) Barry
Re: [Mageia-dev] RPM groups policy
On 27/09/12 11:07, Pierre-Malo Deniélou wrote: Le 27/09/12 10:51,Pascal Terjan nous adresse ces quelques mots : On Thu, Sep 27, 2012 at 10:48 AM, Pierre-Malo Deniélou For PulseAudio, Sound/Mixer is fine. I don't agree If someone wants to install a mixer, pulesaudio in the list will probably confuse him As I was saying earlier, no group classification is perfect. In the situation you describe, having pulseaudio in System/Base would be even more confusing. But if you were to choose between Sound/Editors and Convertors, Sound/Midi, Sound/Mixers, Sound/Players, Sound/Utilities, Sound/Visualization, where would you look first? You know none fits perfectly, I know that as well, even less for pulseaudio-module-jack or pulseaudio-module-bluetooth. But before everyting was in Sound: so confusing is maximum. Now it becomes a bit (but only a bit) easier. That's the point. Or perhaps PA should just go in System/Base? No. It only drowns it in the crowd of completely unrelated packages. Do you expect someone to want to manually install pulseaudio after removing it, and search it in mixers? Yes. By the principle of Where else? :-) Cheers, Can it not stay in the top level Sound or does everything *have* to be in a sub group?
Re: [Mageia-dev] grub2 integration into installer and drakx tools
On 26/09/12 09:10, Thierry Vignaud wrote:
send me what a typical config file would look with the corresponding grub1 conf
file.
I think I can see where you are heading.
Grub2 generates it own grub.cfg using os-prober, so maybe some work not
needed.
Additional entries to the grub2 menu (anything not found by os-prober)
need adding to /etc/grub.d/40_custom and are incuded when the menu is
re-built. If thay are added to grub.cfg they will be overwritten at
kernel update etc.
I have attached grub.cfg and menu.lst from a vbox installation of mga3
running grub2. It is a lot less noisy than those on my desktop.
For basic grub2 commands see my README.Mageia in the package.
Barry
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
load_env
fi
set default=0
if [ x${feature_menuentry_id} = xy ]; then
menuentry_id_option=--id
else
menuentry_id_option=
fi
export menuentry_id_option
if [ ${prev_saved_entry} ]; then
set saved_entry=${prev_saved_entry}
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if loadfont unicode ; then
set gfxmode=1024x768x32
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_GB
insmod gettext
fi
terminal_output gfxterm
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1
6e6a4414-2fff-413b-b224-4675025cb4cf
else
search --no-floppy --fs-uuid --set=root 6e6a4414-2fff-413b-b224-4675025cb4cf
fi
insmod gfxmenu
insmod png
set theme=($root)/boot/grub2/themes/maggy/theme.txt
export theme
set timeout=5
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Mageia GNU/Linux' --class mageia --class gnu-linux --class gnu
--class os $menuentry_id_option
'gnulinux-simple-6e6a4414-2fff-413b-b224-4675025cb4cf' {
set gfxpayload=text
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1
6e6a4414-2fff-413b-b224-4675025cb4cf
else
search --no-floppy --fs-uuid --set=root
6e6a4414-2fff-413b-b224-4675025cb4cf
fi
echo'Loading Linux desktop ...'
linux /boot/vmlinuz-desktop
root=UUID=6e6a4414-2fff-413b-b224-4675025cb4cf ro splash
echo'Loading initial ramdisk ...'
initrd /boot/initrd-desktop.img
}
submenu 'Advanced options for Mageia GNU/Linux' $menuentry_id_option
'gnulinux-advanced-6e6a4414-2fff-413b-b224-4675025cb4cf' {
menuentry 'Mageia GNU/Linux, with Linux desktop' --class mageia --class
gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-desktop-advanced-6e6a4414-2fff-413b-b224-4675025cb4cf' {
set gfxpayload=text
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1
6e6a4414-2fff-413b-b224-4675025cb4cf
else
search --no-floppy --fs-uuid --set=root
6e6a4414-2fff-413b-b224-4675025cb4cf
fi
echo'Loading Linux desktop ...'
linux /boot/vmlinuz-desktop
root=UUID=6e6a4414-2fff-413b-b224-4675025cb4cf ro splash
echo'Loading initial ramdisk ...'
initrd /boot/initrd-desktop.img
}
menuentry 'Mageia GNU/Linux, with Linux 3.5.4-desktop-1.mga3' --class
mageia --class gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-3.5.4-desktop-1.mga3-advanced-6e6a4414-2fff-413b-b224-4675025cb4cf' {
set gfxpayload=text
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1
6e6a4414-2fff-413b-b224-4675025cb4cf
else
search --no-floppy --fs-uuid
Re: [Mageia-dev] grub2 integration into installer and drakx tools
On 25/09/12 23:17, AL13N wrote: should this be made as an alternative to lilo, grub, grub-text ? to add grub2 to that list? and make it actually generate proper code? That may be a good way to introduce grub2 whist keeping grub as a fall-back Not sure what you mean about proper code or are we obsoleting grub1? I guess that will be the long term aim, but I think mga3 is maybe too soon now. imho, perhaps it's better to add grub2 and grub2-text to that list... so we don't have to handle conversions... Yes. Barry
[Mageia-dev] grub2 integration into installer and drakx tools
We already have a grub2 package which needs integrating into Mageia tools. This is beyond my capabilities, so I am calling for developers who are able to do this work. The package already handles kernel updates. The installer, drakboot etc. will need some work.
Re: [Mageia-dev] need some help to build a linuxsampler.rpm
On 23/09/12 21:16, zezinho wrote: svn export gives a better tarball... Yes - thanks for the correction - maybe even better to use: svn co https://svn.linuxsampler.org/svn/linuxsampler/trunk linuxsampler tar -czf linuxsampler.tar.gz linuxsampler/ --exclude-vcs .. which strips the svn stuff during tarball creation. This way the tree may be updated if required.
Re: [Mageia-dev] need some help to build a linuxsampler.rpm
On 22/09/12 23:02, PhilippeDidier wrote: Ok ! That's what I try...but there are several makefiles ! You may want to try the latest dev version from the linuxsampler svn as many issues may already be fixed upstream. This will produce a current linuxsampler.tar.gz to test with:- svn co https://svn.linuxsampler.org/svn/linuxsampler/trunk linuxsampler tar -czf linuxsampler.tar.gz linuxsampler/ Barry
[Mageia-dev] lib64usb1.0_0-1.0.13-1.mga3 conflict
Since update of libusb: Installation failed: file /usr/lib64/libusb-1.0.so.0.1.0 from install of lib64usb1.0_0-1.0.13-1.mga3.x86_64 conflicts with file from package lib64usbx1.0_0-1.0.12-1.mga3.x86_64
Re: [Mageia-dev] Any progress on the NFS mount problem? - One step further
On 21/09/12 19:54, Anne Wilson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20/09/12 21:37, Guillaume Rousse wrote: If everything else fails, you may also inhibit IPv6 completly: just add 'install ipv6 /bin/true' in any file under /etc/modprobe.d, and reboot. Using MCC, I disabled IPv6 and rebooted. Now 'mount -a' on the client no longer talks about unsupported NFS version, but says mount.nfs: access denied by server while mounting 192.168.0.40:/home I am UID 500 on both systems, so that's very strange. Thanks for getting me this far - any idea where I should be looking now? Anne - -- Need KDE help? Try http://userbase.kde.org or http://forum.kde.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBct/8ACgkQj93fyh4cnBfvXwCfZziRGCGsc3/WwSzCZSEC9wJa OagAn26u8KVsn5hipcqJ0+0AGmj0/2G4 =Atyo -END PGP SIGNATURE- Anne, Not sure if this is related, but did you apply Derek's patch? :- https://bugs.mageia.org/show_bug.cgi?id=207#c79
Re: [Mageia-dev] Update of the rpm group policy
On 08/09/12 19:07, Pierre-Malo Deniélou wrote: Any other suggestions for the groups? gnuradio is development software for software enabled radio, so Communications/Development Amateur Radio is needed as a group for packages like grig and xlog, so maybe: Communications/Amateur Radio cutecw is a Morse Code trainer aimed at radio amateurs so: Communications/Amateur Radio/Education zoneminder is currently in Video which is rather cluttered. I think Video needs sub-groups like:- Video/Players Video/Editors Video/Security Video/Format converters Video/Plug-ins Also, why has gpg got it's own top level 'Public Keys' group which clutters rpmdrake - surely this should be somewhere down the System/.. hierarchy? My 2 cents ;) Barry
Re: [Mageia-dev] ANNOUNCE: The /usr move cometh! ---- Instructions
On 24/07/12 07:21, Sander Lepik wrote: 24.07.2012 02:32, Barry Jackson kirjutas: Updating an i586 Cauldron VM I am getting this:- Preparing... # 1/52: filesystem # error: unpacking of archive failed on file /var/run: cpio: rename failed - Is a directory error: filesystem-2.1.9-18.mga3.i586: install failed This is at the start of --auto-update after the re-boot. Is your /var on a separate partition? I had the same problem with /var/lock and /var/run. To solve this i had to rename those directories (later deleted them) and i created two symlinks /var/lock - /run/lock and /var/run - /run - after that filesystem installed w/o problems. -- Sander No, this is a single partition install in virtualbox that I use for testing. I will look at those files later though - thanks.
Re: [Mageia-dev] ANNOUNCE: The /usr move cometh! ---- Instructions
On 24/07/12 10:25, Colin Guthrie wrote: do you have /var/run.runmove~ and /var/lock.lockmove~ files?) Cheers Col Hi Col, Yes I have both of those. (they are dirs not files) Barry
