Re: [Mageia-dev] Freeze push: shotwell
Le 08/04/2013 00:40, Damien Lallement a écrit : Le 07/04/2013 23:25, Anne Nicolas a écrit : Le 07/04/2013 21:05, Damien Lallement a écrit : Le 07/04/2013 11:54, Damien Lallement a écrit : Le 05/04/2013 15:06, Damien Lallement a écrit : Please submit shotwell 0.14.1 (0.14.0. for now). - Fixes a critical issue where Shotwell could close unexpectedly when working with RAW photos in direct-edit mode - The Facebook Connector now recovers smoothly from type 7 errors EXIF-oriented photos uploaded to Facebook now appear in their correct orientation, even when the strip metadata option is turned on in the Facebook Connector - Fixes an issue where incorrect view filter settings were applied on tag and event pages - The Camera Developer is now disabled for RAW images that lack a suitable paired or embedded JPEG - Updated translations for many languages, including an updated Catalan translation that corrects a problem where incorrect event dates could be displayed - Assorted smaller bug fixes Thanks! Ping Plese! :-) - Current or newer revision(s) already exists in core/release for cauldron: 0.14.0-4.mga3 Rha! Shame on me! :-þ Fixed, please submit again... Thanks! done -- Anne http://mageia.org
Re: [Mageia-dev] Freeze push: iasl
Le 08/04/2013 00:58, Damien Lallement a écrit : Please submit iasl 20130328 (20130117 for now). It's a bug fix release: https://acpica.org/downloads/version-20130214 Thanks! done -- Anne http://mageia.org
Re: [Mageia-dev] Freeze push: zabbix
Le 08/04/2013 02:11, Dimitri a écrit : Please push zabbix-2.0.5. The updated package features the following: - New version 2.0.5 - Fix for #8801 (security issues) - Build and package backend-specific binaries, use alternatives to configure - Build proxy and Java gateway - Migrate to native systemd units, drop init scripts - Misc fixes Thanks! Mitya done -- Anne http://mageia.org
Re: [Mageia-dev] freeze push: stog-0.8
Le 07/04/2013 23:35, Pierre-Malo Deniélou a écrit : Our current version does not work properly. With the updated ocaml-rss-2.1.0, stog-0.8 works well. Nothing depends on it. Done. -- BOFH excuse #368: Failure to adjust for daylight savings time.
Re: [Mageia-dev] Update to boost-1.53 ? (libyui fixing)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anyway atm only who is working on AdminPanel should really use libyui in mageia, so i can always provide a fixing later if i find problems. I made a different patch and sent to libyui devs, that approved it: https://github.com/libyui/libyui/commit/cfcc3d472db6a43a7a8d5edc0187026c9fabe370 Cheers, Angelo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFirlgACgkQqEs9DA4DquDA7wCgnBApTELWmqNoG0KxqcSPucFa GPQAn13AEInwq1W/kAlKJ/kYMY3/HIz8 =EEw2 -END PGP SIGNATURE-
Re: [Mageia-dev] M3 beta - where to report problems?
On 04/07/2013 11:25 AM, Anne Wilson wrote: Sorry to be a pain, Frank, but I've never been able to understand the Rescue mode. Everything I've tried fails. How exactly do you mount your root partition? I went to Console, but every command I tried failed. I then tried the mount under /mnt and messed up the link. For some reason, even after all this time, I never know exactly what it intends me to do. OK, you have two choices. if you have a local cauldron mirror or can do network installs, you can boot isolinux or boot.iso and type rescue at the initial text screen prompt. From there on, you pick a mirror as you would for a network install, and the only difference is that it will load the rescue kernel and run the rescue application rather than the standard install. Or, you can boot the classic install ISO, and one of the GUI choices should be Rescue. Once you get the Rescue panel, select Go to Console. Then type drvinst, since rescue tends to lag modern hardware, and probably won't see SATA disks without the additional drivers. Then mount your root partition. Rescue provides a /mnt node, so you can use mount -t ext4 /dev/sdaX /mnt You can then make the symlink modifications in /mnt/etc/systemd/system and reboot from the root partition.
Re: [Mageia-dev] M3 beta - where to report problems?
Frank Griffin skrev 4.4.2013 19:12: On 04/04/2013 10:59 AM, Anne Wilson wrote: Not much progress. My usual method of editing the kernel line to get a level 3 boot doesn't work - same blank (but lit) screen. Failsafe appears to be doing better - at least I can see messages. It reaches Reached target Multi-User Reached target Graphical Interface and there it sticks. Does that give any clue as to what is failing, and what I need to do to rescue the system? Boot a rescue disk and mount your root partition. In /etc/systemd/system you should see a symlink like: lrwxrwxrwx 1 root root 36 Mar 29 11:00 default.target - /lib/systemd/system/runlevel5.target Just remove this and re-symlink to /lib/systemd/system/runlevel3.target and you should get a level 3 boot. It's actually easier than that. Add systemd.unit=multi-user.target on kernel / grub command line and ith will boot to runlevel 3 -- Thomas
Re: [Mageia-dev] M3 beta - where to report problems?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/13 13:12, Frank Griffin wrote: Or, you can boot the classic install ISO, and one of the GUI choices should be Rescue. Once you get the Rescue panel, select Go to Console. Then type drvinst, since rescue tends to lag modern hardware, and probably won't see SATA disks without the additional drivers. Then mount your root partition. Rescue provides a /mnt node, so you can use mount -t ext4 /dev/sdaX /mnt You can then make the symlink modifications in /mnt/etc/systemd/system and reboot from the root partition. modprobe: FATAL: Module shpchp not found modprobe: FATAL: Module snd_hda_intel not found How do I get these? Anne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFi3FQACgkQj93fyh4cnBf26QCfVrKaVRZhJFtcZrnHNyKtO/Jr 2e8AnAmDiCkQ6YH2k+GVX9SECj0wcHeP =P0Bp -END PGP SIGNATURE-
Re: [Mageia-dev] M3 beta - where to report problems?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/13 13:20, Thomas Backlund wrote: Frank Griffin skrev 4.4.2013 19:12: On 04/04/2013 10:59 AM, Anne Wilson wrote: Not much progress. My usual method of editing the kernel line to get a level 3 boot doesn't work - same blank (but lit) screen. Failsafe appears to be doing better - at least I can see messages. It reaches Reached target Multi-User Reached target Graphical Interface and there it sticks. Does that give any clue as to what is failing, and what I need to do to rescue the system? Boot a rescue disk and mount your root partition. In /etc/systemd/system you should see a symlink like: lrwxrwxrwx 1 root root 36 Mar 29 11:00 default.target - /lib/systemd/system/runlevel5.target Just remove this and re-symlink to /lib/systemd/system/runlevel3.target and you should get a level 3 boot. It's actually easier than that. Add systemd.unit=multi-user.target on kernel / grub command line and ith will boot to runlevel 3 Noted, for when I get the drivers fixed :-) Thanks Anne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFi3JEACgkQj93fyh4cnBd0zACePfa3pMuZ0146AYihYtPYsVUp rXIAnjSgncPQ6EiA/OwLnB4kR3bW7X60 =2qAZ -END PGP SIGNATURE-
Re: [Mageia-dev] M3 beta - where to report problems?
On 04/08/2013 11:03 AM, Anne Wilson wrote: modprobe: FATAL: Module shpchp not found modprobe: FATAL: Module snd_hda_intel not found How do I get these? I'm not sure why a rescue system would need either of them. I guesss you get these messages from drvinst; I get some sililar ones myself (in my case, snd_intel8x0 and vboxguest), but it doesn't impact the usability of the rescue system. I don't know how drvinst decides what it will try to load versus what is actually available in the rescue module set. I would just ignore these and push on.
Re: [Mageia-dev] M3 beta - where to report problems?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/13 16:37, Frank Griffin wrote: On 04/08/2013 11:03 AM, Anne Wilson wrote: modprobe: FATAL: Module shpchp not found modprobe: FATAL: Module snd_hda_intel not found How do I get these? I'm not sure why a rescue system would need either of them. I guesss you get these messages from drvinst; I get some sililar ones myself (in my case, snd_intel8x0 and vboxguest), but it doesn't impact the usability of the rescue system. I don't know how drvinst decides what it will try to load versus what is actually available in the rescue module set. I would just ignore these and push on. OK, moving on. Listing /mnt/etc/systemd/system/ I have no default.target link, so I assume I have to make one. Is that ln -s /lib/systemd/system/runlevel3.target /mnt/etc/systemd/system/default.target ? Anne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFi7JsACgkQj93fyh4cnBfUdACfWsJAXJC5rI0y/yxrl85pv3Qc yCAAnjV9tYuc8UeLCkkCeddeTvdzSFlH =acPn -END PGP SIGNATURE-
Re: [Mageia-dev] M3 beta - where to report problems?
On 04/08/2013 12:13 PM, Anne Wilson wrote: OK, moving on. Listing /mnt/etc/systemd/system/ I have no default.target link, so I assume I have to make one. Is that ln -s /lib/systemd/system/runlevel3.target /mnt/etc/systemd/system/default.target ? Actually, you probably want to first chroot /mnt and then use ln -s /lib/systemd/system/runlevel3.target /etc/systemd/system/default.target as I can't swear offhand what the effect of linking in the rescue system with the leading /mnt would be. Or, you can equally well edit /mnt/boot/grub/menu.lst and use Thomas' suggestion. But it's odd that you don't have a default link already.
Re: [Mageia-dev] M3 beta - where to report problems?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/13 17:22, Frank Griffin wrote: On 04/08/2013 12:13 PM, Anne Wilson wrote: OK, moving on. Listing /mnt/etc/systemd/system/ I have no default.target link, so I assume I have to make one. Is that ln -s /lib/systemd/system/runlevel3.target /mnt/etc/systemd/system/default.target ? Actually, you probably want to first chroot /mnt and then use ln -s /lib/systemd/system/runlevel3.target /etc/systemd/system/default.target as I can't swear offhand what the effect of linking in the rescue system with the leading /mnt would be. Or, you can equally well edit /mnt/boot/grub/menu.lst and use Thomas' suggestion. But it's odd that you don't have a default link already. Something very odd is happening, indeed. Remember this was a functioning system before I did the updates. Rebooting, nothing has changed. I get grub, lots of disk activity led flickering, but no output to the screen, with or without Esc. I can boot into Safe moade, which lands me in Rescue Mode - but I haven't a clue what to do next. Anne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFi9bQACgkQj93fyh4cnBeZ8QCcC4epBJgJd4ugK8medhpi4z8h ciQAni276WK4s3YNc+oOHWvvOIUmb1WD =4901 -END PGP SIGNATURE-
Re: [Mageia-dev] M3 beta - where to report problems?
On 04/08/2013 12:52 PM, Anne Wilson wrote: Something very odd is happening, indeed. Remember this was a functioning system before I did the updates. Rebooting, nothing has changed. I get grub, lots of disk activity led flickering, but no output to the screen, with or without Esc. I can boot into Safe moade, which lands me in Rescue Mode - but I haven't a clue what to do next. If you don't even get text mode, this sounds like the old problem of radeon drivers which require nonfree firmware not having the firmware available. There was a long stretch where, if you had such a card, you needed to install with the x11 vesa driver, boot, install the firmware, and then use XFdrake to switch to the radeon driver. Do you have a card that uses the radeon driver ? If so, did you enable nonfree during the upgrade ? You can try the following: 1) Boot the rescue system 2) drvinst 3) mount your root as /mnt 4) do a mount --bind /dev /mnt/dev 5) do a chroot /mnt 6) do a mount -t proc none /proc 7) do a mount -t sysfs none /sys 8) do XFdrake 9) choose the x11 VESA or VGA driver (way down at bottom of list) 10) reboot and see if TTY mode now works If it does, then add nonfree as a urpmi repository and install the nonfree radeon firmware package. Then run XFdrake in the real system to set yourself back to the radeon driver that XFdrake should default to. If you're not using radeon, you may want to do (1) - (10) anyway just to see if your system works with the basic driver.
Re: [Mageia-dev] Upcoming release freeze: 14 packages needs fixing, by Sunday
On 04/06/2013 06:35 AM, andre999 wrote: did a little research to hopefully help a bit, on packages still in the list. ( used http://rpmfind.net/linux/ ) cross-avr-gcc See bugzilla: https://bugs.mageia.org/show_bug.cgi?id=7825 Looks like an incompatibilty between the object gcc (which is now 4.7.2) and the target gcc (the specfile still pulls in 4.6.2). To make cross-avr-gcc build - cross-avr-binutils (which is used as a dependency) must be rebuilt to use binutils-2.23 (the present cross-avr-binutils uses 2.20), - cross-avr-gcc must be re-built to use gcc-4.7.2 (and some tweeks - see bugzilla 7825) I have locally made such a build and successfully use it in production for building the software for my AVR cpus (attached my specfile = attachment 3044). The reasons why I did not submit my local build are that there are some serious rpmlint warnings (serious at least for cross-avr-binutils: complaints about the use of hardlinks) which I did not manage to get rid of - but also that I did not want to interfere with the work of the maintainer. Juergen
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] Mailing list migration: this list is closing
Hi *, On Mon, Apr 8, 2013 at 12:54 AM, Mageia Sysadmins sysad...@group.mageia.org wrote: This mailing list will be closed in coming hours and is now replaced by d...@ml.mageia.org. Too bad you didn't keep the list-id the same, so people have to adapt their filters and mail-archives need to be manually mapped... ciao Christian
Re: [Mageia-dev] M3 beta - where to report problems?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/13 18:28, Frank Griffin wrote: On 04/08/2013 12:52 PM, Anne Wilson wrote: Something very odd is happening, indeed. Remember this was a functioning system before I did the updates. Rebooting, nothing has changed. I get grub, lots of disk activity led flickering, but no output to the screen, with or without Esc. I can boot into Safe moade, which lands me in Rescue Mode - but I haven't a clue what to do next. If you don't even get text mode, this sounds like the old problem of radeon drivers which require nonfree firmware not having the firmware available. There was a long stretch where, if you had such a card, you needed to install with the x11 vesa driver, boot, install the firmware, and then use XFdrake to switch to the radeon driver. Do you have a card that uses the radeon driver ? If so, did you enable nonfree during the upgrade ? You can try the following: 1) Boot the rescue system 2) drvinst 3) mount your root as /mnt 4) do a mount --bind /dev /mnt/dev 5) do a chroot /mnt 6) do a mount -t proc none /proc 7) do a mount -t sysfs none /sys 8) do XFdrake 9) choose the x11 VESA or VGA driver (way down at bottom of list) 10) reboot and see if TTY mode now works If it does, then add nonfree as a urpmi repository and install the nonfree radeon firmware package. Then run XFdrake in the real system to set yourself back to the radeon driver that XFdrake should default to. If you're not using radeon, you may want to do (1) - (10) anyway just to see if your system works with the basic driver. No, it doesn't. When I ran XFdrake the test did display colours, though at a resolution I wouldn't want to work with :-) However, on reboot I still have a backlit black screen. I'm sure you are on the right track. It's not radeon, though, it's Intel 810 and later. I see that listed in XFdrake, but if I try to use it I'm told that there are no screens. Not sure what that means, though. When booting into rescue, I saw several items listed as Intel Corporation:NM10/ICH7 Family which sounds right to me. So - I need Intel drivers (and firmware). Can I use the same rescue processes to get the Internet working so that I can download them? Odd, though, that even VESA didn't work. Anne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFjD0YACgkQj93fyh4cnBdK/QCfcK0zbk70QoyCrn1TID+OCmLy oiMAn03GaoFmsCIZP4xwfK1NS1bleEQp =zWqb -END PGP SIGNATURE-
Re: [Mageia-dev] M3 beta - where to report problems?
On 04/08/2013 02:41 PM, Anne Wilson wrote: No, it doesn't. When I ran XFdrake the test did display colours, though at a resolution I wouldn't want to work with :-) However, on reboot I still have a backlit black screen. I'm sure you are on the right track. It's not radeon, though, it's Intel 810 and later. I see that listed in XFdrake, but if I try to use it I'm told that there are no screens. Not sure what that means, though. When booting into rescue, I saw several items listed as Intel Corporation:NM10/ICH7 Family which sounds right to me. So - I need Intel drivers (and firmware). Can I use the same rescue processes to get the Internet working so that I can download them? Odd, though, that even VESA didn't work. Let me get this straight. You ran XFdrake for VESA chrooted to your root partition, got a decent test, and the real boot *still* screws up ? Weird. If you follow the process I gave, you should be able to start the network from within the chroot (provided you were able to start it from the rescue boot), or else it should already be up. You should then be able to run urpmi from within the chroot to install the firmware packages from nonfree. You'll need at least kernel-firmware-nonfree. Here's what else is there: [root@ftgme2 ftg]# cd /mnt/cauldron/x86_64/media/nonfree/release [root@ftgme2 release]# ls *firm* atmel-firmware-1.3-5.mga3.nonfree.noarch.rpm bluez-firmware-1.2-9.mga3.nonfree.noarch.rpm ipw2100-firmware-1.3-5.mga3.nonfree.noarch.rpm ipw2200-firmware-3.1-3.mga3.nonfree.noarch.rpm ivtv-firmware-20080701-1.mga3.nonfree.noarch.rpm kernel-firmware-nonfree-20130307-1.mga3.nonfree.noarch.rpm radeon-firmware-20120322-5.mga3.nonfree.noarch.rpm ralink-firmware-20130307-1.mga3.nonfree.noarch.rpm rtlwifi-firmware-20130307-1.mga3.nonfree.noarch.rpm speedtouch-firmware-0.1-10.mga3.nonfree.noarch.rpm If that doesn't work, then it sounds like your TTY configuration is screwed, and if that's the case, I'm tapped out. Colin would probably be the best one to ask what controls getty under systemd and how it's configured.
Re: [Mageia-dev] M3 beta - where to report problems?
'Twas brillig, and Thomas Backlund at 08/04/13 13:20 did gyre and gimble: Frank Griffin skrev 4.4.2013 19:12: On 04/04/2013 10:59 AM, Anne Wilson wrote: Not much progress. My usual method of editing the kernel line to get a level 3 boot doesn't work - same blank (but lit) screen. Failsafe appears to be doing better - at least I can see messages. It reaches Reached target Multi-User Reached target Graphical Interface and there it sticks. Does that give any clue as to what is failing, and what I need to do to rescue the system? Boot a rescue disk and mount your root partition. In /etc/systemd/system you should see a symlink like: lrwxrwxrwx 1 root root 36 Mar 29 11:00 default.target - /lib/systemd/system/runlevel5.target Just remove this and re-symlink to /lib/systemd/system/runlevel3.target and you should get a level 3 boot. It's actually easier than that. Add systemd.unit=multi-user.target on kernel / grub command line and ith will boot to runlevel 3 Or simply add a 3 onto the command line as has been the case for many years :) Of course I should probably discourage that seeing as 3 is pretty meaningless in absolute terms these days! :) Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] urpmi - strange read lock messages
'Twas brillig, and Nicolas Lécureuil at 05/04/13 23:11 did gyre and gimble: Le vendredi 5 avril 2013 23:48:08 Jose Jorge a écrit : Le 05/04/2013 14:29, Robert Fox a écrit : Thanks the point - I never aborted. Assuming I did, is there a way to clean this up? Rebuild rpm database?? I get this warnings each time MageiaUpdate applet after was used, then urpmi is used. i NEVER reproduced .But, using your testcase i can. Yeah, I frequently get these messages. I also use a mix of MageiaUpdate and urpmi directly. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] M3 beta - where to report problems?
Colin Guthrie skrev 9.4.2013 00:31: 'Twas brillig, and Thomas Backlund at 08/04/13 13:20 did gyre and gimble: It's actually easier than that. Add systemd.unit=multi-user.target on kernel / grub command line and ith will boot to runlevel 3 Or simply add a 3 onto the command line as has been the case for many years :) Of course I should probably discourage that seeing as 3 is pretty meaningless in absolute terms these days! :) Are you sure ? IIRC there has been reports of people doing it and still eneded up at graphical.target ... -- Thomas
Re: [Mageia-dev] HEADSUP: Full git clone of all package specs (with history)
'Twas brillig, and Christian Lohmaier at 05/04/13 12:44 did gyre and gimble: Hi Colin, *, On Fri, Apr 5, 2013 at 8:46 AM, P. Christeas x...@linux.gr wrote: On Saturday 23 March 2013, Colin Guthrie wrote: 'Twas brillig, and Colin Guthrie at 22/03/13 09:32 did gyre and gimble: [...] Just to avoid a crazy amount of scripting with svn checkouts and such like, I've set running a git svn clone of the cauldron package subversion tree. That said, running git blame takes *ages* even on an SSD drive. It was at least a couple minutes to display the results of a blame on a spec file. Let me remind you of the other suggestion: Put each package in a separate git repo, and then use submodules to bind all of them together into the Mageia repo.. Somewhat surprised that it takes so long - LO's core repo is much larger and is reasonably fast, even on traditional disk. Maybe git maintenance commands (gc and/or prune) may help? Care uploading the repo to github or similar? I can push the repo somewhere sensible if you wish, but it's not likely super useful unless you have the git-svn branch too. But I've done pruning of the empty commits (i.e. those ignored via --ignore-paths with git-svn) which took 3 days to run in a tmpfs filesystem!, and also done a git gc --aggressive. The times posted are what results from that. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] M3 beta - where to report problems?
'Twas brillig, and Thomas Backlund at 08/04/13 22:43 did gyre and gimble: Colin Guthrie skrev 9.4.2013 00:31: 'Twas brillig, and Thomas Backlund at 08/04/13 13:20 did gyre and gimble: It's actually easier than that. Add systemd.unit=multi-user.target on kernel / grub command line and ith will boot to runlevel 3 Or simply add a 3 onto the command line as has been the case for many years :) Of course I should probably discourage that seeing as 3 is pretty meaningless in absolute terms these days! :) Are you sure ? IIRC there has been reports of people doing it and still eneded up at graphical.target ... Hmm, well the code suggests it should... will have to try it :) Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] M3 beta - where to report problems?
On Mon, 08 Apr 2013 12:52:06 -0400, Anne Wilson an...@kde.org wrote: Rebooting, nothing has changed. I get grub, lots of disk activity led flickering, but no output to the screen, with or without Esc. I can boot into Safe moade, which lands me in Rescue Mode - but I haven't a clue what to do next. Try editing the kernel parameters in grub. Remove splash quiet, if present. Add 3 xdriver=vesa. The 3 gets translated by systemd to systemd.unit=multi-user.target, is shorter to type, and easier to remember. Regards, Dave Hodgins
Re: [Mageia-dev] M3 beta - where to report problems?
On Mon, 08 Apr 2013 17:43:38 -0400, Thomas Backlund t...@mageia.org wrote: Colin Guthrie skrev 9.4.2013 00:31: 'Twas brillig, and Thomas Backlund at 08/04/13 13:20 did gyre and gimble: It's actually easier than that. Add systemd.unit=multi-user.target on kernel / grub command line and ith will boot to runlevel 3 Or simply add a 3 onto the command line as has been the case for many years :) Of course I should probably discourage that seeing as 3 is pretty meaningless in absolute terms these days! :) Are you sure ? IIRC there has been reports of people doing it and still eneded up at graphical.target ... I tested with an install from Mageia 3 beta 4, and can confirm it still works. Regards, Dave Hodgins
