Re: [Mageia-dev] Buildsystem stalled?
On Fri, Dec 2, 2011 at 07:39, Funda Wang fundaw...@gmail.com wrote: Hello, Is the build system currently stalled? Several failure packages do not show error logs. Yes sorry, I broke it for noarch packages last night while fixing the race causing some kernel packages to be missing, fixed now
Re: [Mageia-dev] Buildsystem stalled?
On Fri, Dec 2, 2011 at 08:21, Pascal Terjan pter...@gmail.com wrote: On Fri, Dec 2, 2011 at 07:39, Funda Wang fundaw...@gmail.com wrote: Hello, Is the build system currently stalled? Several failure packages do not show error logs. Yes sorry, I broke it for noarch packages last night while fixing the race causing some kernel packages to be missing, fixed now Actually I fixed the noarch packages failing to be detected as built and blocking the queue, but not the log collection, will have a look soon
Re: [Mageia-dev] Removing obsolete packages
'Twas brillig, and Michel Catudal at 02/12/11 02:32 did gyre and gimble: Le 30/11/2011 02:21, andre999 a écrit : Michel Catudal a écrit : How about putting back previously unsupported packages? The only text editor that I use is joe and someone has decided to remove it from Mageia. I took the Redhat Enterprise version and ported it to mageia. For a while the maintainers of joe has incorporated a bug that would make it such that it would core dump if you tried to open more than one file at a time. I am willing to maintain this package. Michel No problem, since you are willing to maintain it, as long as it makes it past QA. (Which means the core dump problem would have to be solved, if not already.) The fix was made by Redhat, It was a one char bug One char fix, with a six char polish? :p b-oldcur = pdup(b-bof, USTR main); pline(b-oldcur, get_file_pos(b-name)); - p_goto_bol(bw-cursor); + p_goto_bol(b-oldcur); line = b-oldcur-line - (maint-h - 1) / 2; It would be an update to cauldron, and a backport for Mageia 1 (unless it was in Mandriva 2010.1/2, in which case it would be an update). -- 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] Unable to boot into kernel-3.1.3
'Twas brillig, and Kira at 02/12/11 06:06 did gyre and gimble: 在 Thu, 01 Dec 2011 23:24:34 +0800, Colin Guthrie mag...@colin.guthr.ie寫道: It shouldn't be a problem. The only issue would be if the parsing code in dracut somehow gets confused by some content in your fstab and thus needs to be adjusted to cope more gracefully with it. Col File as attached. Thanks. Actually I didn't really need it in the end, I should have spotted the problem without it, but it did make me go through the motions. It was a simple variable name typo. I've submitted a new version, please wait for dracut-013-5.mga2 and regenerate, test, yada, yada, and let me know how you get on. 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] Unable to boot into kernel-3.1.3
在 Fri, 02 Dec 2011 18:44:32 +0800, Colin Guthrie mag...@colin.guthr.ie寫道: Actually I didn't really need it in the end, I should have spotted the problem without it, but it did make me go through the motions. It was a simple variable name typo. I've submitted a new version, please wait for dracut-013-5.mga2 and regenerate, test, yada, yada, and let me know how you get on. Col No, it didn't work. Error message: device node not found dracut Warning: e2fsck returned with 16 dracut Warning: *** An error occurred during the file system check. dracut Warning: *** Dropping yo to a shell: the system will try dracut Warning: *** to mount the filesystem(s), when you leave the shell
[Mageia-dev] RFC: Drop mkinitrd completely in favour of dracut.
Hi, Just a suggestion! Should we move wholesale to dracut? It's very easy to hack on, and Harald Hoyer has been very helpful and has merged some of the patches we carried locally (which I mostly copied from Mandriva). Not sure why they were not upstreamed before. There are still a couple patches we carry locally (soon to be less when Harald pushes his git repo and I rebase), but they are pretty trivial, understandable and easily maintainable (mostly they will be stylistic tweaks and naming variations - i.e. very minor). Modprobe rules are included even in the initrd so tweaks there follow through. I'm not necessarily against keeping mkinitrd, but I think we should take the time from now until the beta phase to obsolte mkinitrd and force everyone to use dracut in order to see if there are any issues and then make the call before next beta or rc. WDYT? 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] RFC: Drop mkinitrd completely in favour of dracut.
Colin Guthrie skrev 2.12.2011 13:28: Hi, Just a suggestion! Should we move wholesale to dracut? It's very easy to hack on, and Harald Hoyer has been very helpful and has merged some of the patches we carried locally (which I mostly copied from Mandriva). Not sure why they were not upstreamed before. There are still a couple patches we carry locally (soon to be less when Harald pushes his git repo and I rebase), but they are pretty trivial, understandable and easily maintainable (mostly they will be stylistic tweaks and naming variations - i.e. very minor). Modprobe rules are included even in the initrd so tweaks there follow through. I'm not necessarily against keeping mkinitrd, but I think we should take the time from now until the beta phase to obsolte mkinitrd and force everyone to use dracut in order to see if there are any issues and then make the call before next beta or rc. Well, one thing dracut (or maybe it's systemd, I havent had time to debug yet) is not able to do so far is to boot up a dmraid setup with 2 raid1 (2x 2 disks) setup... if there is anthing in fstab referencing the second raid1 disk pair the boot stops. I currently work around it by manually activating and mounting the second raid set after the system is booted. This could maybe be fixed by not using dmraid anymore for Intel imsm raid, but instead let mdadm handle it. But that also means modifying the installer for that part. The good part of using dracut over mkinitrd with dmraid setups is that dracut uses the real dmraid to activate/access the raid, so it can boot even if one disk has failed. mkinitrd uses a stripped down dmraid support in nash that crashes on boot if one disk is missing. Other than that I haven't seen any problems with dracut so far. -- Thomas
Re: [Mageia-dev] Unable to boot into kernel-3.1.3
'Twas brillig, and Kira at 02/12/11 11:24 did gyre and gimble: 在 Fri, 02 Dec 2011 18:44:32 +0800, Colin Guthrie mag...@colin.guthr.ie寫道: Actually I didn't really need it in the end, I should have spotted the problem without it, but it did make me go through the motions. It was a simple variable name typo. I've submitted a new version, please wait for dracut-013-5.mga2 and regenerate, test, yada, yada, and let me know how you get on. Col No, it didn't work. Well it kinda worked - at least it's actually trying to mount /usr now! Error message: device node not found dracut Warning: e2fsck returned with 16 dracut Warning: *** An error occurred during the file system check. dracut Warning: *** Dropping yo to a shell: the system will try dracut Warning: *** to mount the filesystem(s), when you leave the shell OK, so according to man e2fsck exit code 16 is Usage or syntax error I think this is due to using UUID=. I'll work on a fix for the next round of testing :D 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] Replacing mysql with mariadb
On 02/12/11 00:20, Maarten Vanraes wrote: Op vrijdag 02 december 2011 00:13:28 schreef Barry Jackson: On 01/12/11 22:47, Maarten Vanraes wrote: if you have a cauldron, you can enable updates_testing and then: * rpm -e --nodeps all the mysql packages you have * urpmi all the identical mariadb packages OK - I guess the names are similar - not looked yet ;) I said I would need help :\ I have these 12 mysql packages installed:- php-mysql-5.3.8-2.mga2 perl-DBD-mysql-4.20.0-1.mga2 mysql-common-core-5.5.15-2.mga2 lib64mysqlservices-5.5.15-2.mga2 lib64mysqld0-5.5.15-2.mga2 mysql-client-5.5.15-2.mga2 mysql-core-5.5.15-2.mga2 qt4-database-plugin-mysql-4.7.4-5.mga2 mysql-5.5.15-2.mga2 lib64mysql18-5.5.15-2.mga2 mysql-common-5.5.15-2.mga2 lib64mysql-devel-5.5.15-2.mga2 Yet with testing enabled I see :- [baz@jackodesktop ~]$ urpmq mariadb -a mariadb and... [baz@jackodesktop ~]$ urpmq --provides mariadb mysql adt_null.so()(64bit) auth_socket.so()(64bit) auth_test_plugin.so()(64bit) dialog.so()(64bit) dialog_examples.so()(64bit) ha_archive.so()(64bit) ha_blackhole.so()(64bit) ha_federated.so()(64bit) ha_federatedx.so()(64bit) ha_innodb.so()(64bit) ha_oqgraph.so()(64bit) ha_sphinx.so()(64bit) mypluglib.so()(64bit) mysql_clear_password.so()(64bit) qa_auth_client.so()(64bit) qa_auth_interface.so()(64bit) qa_auth_server.so()(64bit) semisync_master.so()(64bit) semisync_slave.so()(64bit) mariadb[== 5.5.15-0.4.mga2] mariadb(x86-64)[== 5.5.15-0.4.mga2] [baz@jackodesktop ~]$ So are you saying to remove all 12 or just mysql ? If I remove all 12 where do the replacements come from? Just a bit confused :\ Maybe I'm missing something obvious ;)
Re: [Mageia-dev] RFC: Drop mkinitrd completely in favour of dracut.
On 02.12.2011 13:28, Colin Guthrie wrote: Hi, Just a suggestion! Should we move wholesale to dracut? It's very easy to hack on, and Harald Hoyer has been very helpful and has merged some of the patches we carried locally (which I mostly copied from Mandriva). Not sure why they were not upstreamed before. There are still a couple patches we carry locally (soon to be less when Harald pushes his git repo and I rebase), but they are pretty trivial, understandable and easily maintainable (mostly they will be stylistic tweaks and naming variations - i.e. very minor). Modprobe rules are included even in the initrd so tweaks there follow through. I'm not necessarily against keeping mkinitrd, but I think we should take the time from now until the beta phase to obsolte mkinitrd and force everyone to use dracut in order to see if there are any issues and then make the call before next beta or rc. +1 One thing that doesn't work with dracut yet is that it only includes the KMS drivers into initramfs if they are loaded at the time of initramfs creation, causing unoptimal boot screen when a) initramfs created by the installer (I guess), and when b) user has switched a driver non-kms - kms. This can probably be solved by some patching of modules.d/50plymouth/module-setup.sh, but I haven't looked at it closely yet. -- Anssi Hannula
[Mageia-dev] Dolphin toolbar default settings in mga2 alpha
Anyone else find the default settings in Dolphin after a clean Alpha1 installation utterly useless? It's not even possible to easily navigate a file system without UP and BACK buttons. For new users I think the toolbar should have all the regularly needed buttons in place out of the box. I tried to figure out where these are stored and in which package, but after half an hour I gave up :\
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release mercurial-2.0.1-1.mga2
This description isn't too long? -Original Message- From: Mageia Team buildsystem-dae...@mageia.org Sender: changelog-requ...@ml.mageia.org Date: Fri, 2 Dec 2011 16:33:12 To: change...@ml.mageia.org Reply-To: mageia-dev@mageia.org Subject: [changelog] [RPM] cauldron core/release mercurial-2.0.1-1.mga2 Name: mercurialRelocations: (not relocatable) Version : 2.0.1 Vendor: Mageia.Org Release : 1.mga2Build Date: Fri Dec 2 16:26:15 2011 Install Date: (not installed) Build Host: ecosse Group : Development/Other Source RPM: (none) Size: 3137345 License: GPLv2+ Signature : (none) Packager: Mageia Team http://www.mageia.org URL : http://www.selenic.com/mercurial/ Summary : A fast, lightweight distributed source control management system Description : Mercurial is a fast, lightweight source control management system designed for efficient handling of very large distributed projects. Major features include: * Extremely high-performance delta-compressed storage scheme * Optimized for disk layout and access efficiency * Complete cross-indexing of files and changesets * Bandwidth and CPU efficient HTTP and SSH sync protocols * Distributed development model supports unlimited numbers of developers * Allows arbitrary merging between developer branches * Doesn't significantly degrade with large numbers of files or changesets * No waiting for locks! * SHA1 integrity checking on repository data * Append-only storage model with transaction journalling * Fast full-repository verification * Convenient backup * Most commands are familiar to users of CVS and other systems * Built-in command help * Integrated stand-alone web interface (example) * Works with various GUI tools * Runs on UNIX, MacOS X, and Windows * Conversion tools available for many popular SCMs * Allows a variety of usage models * Supports user-defined hooks and extensions * Source code available under the GPL license * Actively community supported and developed lebedov lebedov 2.0.1-1.mga2: + Revision: 175139 - Update to 2.0.1.
Re: [Mageia-dev] Dolphin toolbar default settings in mga2 alpha
2011/12/2 Barry Jackson zen25...@zen.co.uk: Anyone else find the default settings in Dolphin after a clean Alpha1 installation utterly useless? It's not even possible to easily navigate a file system without UP and BACK buttons. For new users I think the toolbar should have all the regularly needed buttons in place out of the box. I tried to figure out where these are stored and in which package, but after half an hour I gave up :\ The BACK button is there (1st button on the left). To get the UP button (or any other) click on the wrench icon and open Customize toolbar... (or similar, I'm using German menues). But I agree that BACK UP should be in the default toolbar. -- wobo
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release mercurial-2.0.1-1.mga2
Sorry for top posting. I'm agree with your description! -Original Message- From: Johnny A. Solbu coo...@solbu.net Sender: mageia-dev-boun...@mageia.org Date: Fri, 2 Dec 2011 16:45:57 To: mageia-dev@mageia.org Reply-To: Mageia development mailing-list mageia-dev@mageia.org Subject: Re: [Mageia-dev] [changelog] [RPM] cauldron core/release mercurial-2.0.1-1.mga2 On Friday 02 December 2011 16:34, cazzaniga.san...@gmail.com wrote: Description : Mercurial is a fast, lightweight source control management system designed for efficient handling of very large distributed projects. In my opinion, this is enough. (Note that I moved the last word up to the end of the previous line.) If people really are interested in reading the features they can look at the projects homepage. Everything from Major features include: and all bullet points should be dropped. -- Johnny A. Solbu PGP key ID: 0xFA687324
Re: [Mageia-dev] Replacing mysql with mariadb
Op vrijdag 02 december 2011 14:40:40 schreef Barry Jackson: On 02/12/11 00:20, Maarten Vanraes wrote: Op vrijdag 02 december 2011 00:13:28 schreef Barry Jackson: On 01/12/11 22:47, Maarten Vanraes wrote: if you have a cauldron, you can enable updates_testing and then: * rpm -e --nodeps all the mysql packages you have * urpmi all the identical mariadb packages OK - I guess the names are similar - not looked yet ;) I said I would need help :\ thanks for that! i guess i should be clearer, i meant the packages that are built from the mysql src.rpm this is for you: mysql-common-core-5.5.15-2.mga2 lib64mysqlservices-5.5.15-2.mga2 lib64mysqld0-5.5.15-2.mga2 mysql-client-5.5.15-2.mga2 mysql-core-5.5.15-2.mga2 mysql-5.5.15-2.mga2 lib64mysql18-5.5.15-2.mga2 mysql-common-5.5.15-2.mga2 lib64mysql-devel-5.5.15-2.mga2 Yet with testing enabled I see :- [baz@jackodesktop ~]$ urpmq mariadb -a mariadb [...] (afaik mariadb is an exact match, so maybe that's why it lists only mariadb) [root@localhost ~]# urpmq -Y mariadb lib64mariadb-devel lib64mariadb-embedded-devel lib64mariadb-embedded0 lib64mariadb18 lib64mariadbservices mariadb mariadb-bench mariadb-client mariadb-common mariadb-common-core mariadb-core thus, for you: mariadb-common-core lib64mariadbservices lib64mariadb-embedded0 mariadb-client mariadb-core mariadb lib64mariadb18 mariadb-common lib64mariadb-devel happy testing :-)
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release mercurial-2.0.1-1.mga2
Received from Johnny A. Solbu on Fri, Dec 02, 2011 at 10:45:57AM EST: On Friday 02 December 2011 16:34, cazzaniga.san...@gmail.com wrote: Description : Mercurial is a fast, lightweight source control management system designed for efficient handling of very large distributed projects. In my opinion, this is enough. (Note that I moved the last word up to the end of the previous line.) If people really are interested in reading the features they can look at the projects homepage. Everything from Major features include: and all bullet points should be dropped. Done. L.G.
Re: [Mageia-dev] replace mysql by mariadb ? (was HEADSUP: mariadb available for testing)
Op vrijdag 02 december 2011 08:37:05 schreef Sander Lepik: 01.12.2011 22:10, Maarten Vanraes kirjutas: Op donderdag 01 december 2011 09:42:29 schreef Anne Nicolas: i'll send a new thread on this, but it's not a final decision, it's nothing more than just a way to get more testing so we can decide to opt-out or not. As said before there is no other major distro that did this switch. It seems too early for me and lots of users do still use MySQL. I would go for MariaDB as an alternative for Mageia 2 is it ok if we could test MariaDB fully and if it's not good enough, we could decide to not use mariadb yet and resubmit mysql? or even provide mariadb as alternative? I wouldn't remove MySQL. If MariaDB can't be installed next to it then i would wait til mga3. It can (not client), but there's no need imho; mariadb is actually no more than the patched mysql because those patches are rejected by oracle (think Google patches and facebook patches as an example) + extra storage engines. if you really want to, the unpatches original (same as mysql) storage engines are available for mariadb as well: - innodb (unpatched; xtradb is the patched one) - myisam - federated etc... if we test mariadb, and you see no differences, why not drop it? do you agree?
Re: [Mageia-dev] Dolphin toolbar default settings in mga2 alpha
Le vendredi 2 décembre 2011 14:56:45 Barry Jackson a écrit : Anyone else find the default settings in Dolphin after a clean Alpha1 installation utterly useless? It's not even possible to easily navigate a file system without UP and BACK buttons. For new users I think the toolbar should have all the regularly needed buttons in place out of the box. I tried to figure out where these are stored and in which package, but after half an hour I gave up :\ If i'm not wrong there's some changes regarding dolphin's configuration, it was already reported to me last week. I'll be able to work again on kde's configuration soon (i was quite buzy) -- Balcaen John Jabber-id: mik...@jabber.littleboboy.net
Re: [Mageia-dev] replace mysql by mariadb ? (was HEADSUP: mariadb available for testing)
Le vendredi 2 décembre 2011 17:33:04, Maarten Vanraes a écrit : if we test mariadb, and you see no differences, why not drop it? do you agree? I'd say go slow, go for sure. We need a list of needed tests: - phpmyadmin - amarok - nepomuk - akonadi - - install a cms like spip.net can also be interesting I you want so much mariadb un mageia, I expect you to build all this srpms against it, and test them a lot (some music files in amarok, some file searches through nepomuk, some addresses in akonadi) Then we can talk about submitting all this to mageia cauldron AKA 2 alpha. We should not just push to cauldron without local tests.
Re: [Mageia-dev] replace mysql by mariadb ? (was HEADSUP: mariadb available for testing)
Op vrijdag 02 december 2011 18:24:13 schreef zezinho: Le vendredi 2 décembre 2011 17:33:04, Maarten Vanraes a écrit : if we test mariadb, and you see no differences, why not drop it? do you agree? I'd say go slow, go for sure. We need a list of needed tests: - phpmyadmin - amarok - nepomuk - akonadi - - install a cms like spip.net can also be interesting I you want so much mariadb un mageia, I expect you to build all this srpms against it, and test them a lot (some music files in amarok, some file searches through nepomuk, some addresses in akonadi) Then we can talk about submitting all this to mageia cauldron AKA 2 alpha. We should not just push to cauldron without local tests. you didn't think i did local tests? i tested with amarok, akonadi, drupal and phpmyadmin locally the purpose of this is exactly to get more testing
Re: [Mageia-dev] replace mysql by mariadb ? (was HEADSUP: mariadb available for testing)
and benchmarks of MySQL vs MariaDB : this is important if you plan to use Mageia on a production server 2011/12/2 Maarten Vanraes al...@rmail.be: Op vrijdag 02 december 2011 18:24:13 schreef zezinho: Le vendredi 2 décembre 2011 17:33:04, Maarten Vanraes a écrit : if we test mariadb, and you see no differences, why not drop it? do you agree? I'd say go slow, go for sure. We need a list of needed tests: - phpmyadmin - amarok - nepomuk - akonadi - - install a cms like spip.net can also be interesting I you want so much mariadb un mageia, I expect you to build all this srpms against it, and test them a lot (some music files in amarok, some file searches through nepomuk, some addresses in akonadi) Then we can talk about submitting all this to mageia cauldron AKA 2 alpha. We should not just push to cauldron without local tests. you didn't think i did local tests? i tested with amarok, akonadi, drupal and phpmyadmin locally the purpose of this is exactly to get more testing -- Close the World, Open the Net http://www.linux-wizard.net
Re: [Mageia-dev] replace mysql by mariadb ? (was HEADSUP: mariadb available for testing)
Op vrijdag 02 december 2011 20:19:10 schreef Fabrice Facorat: and benchmarks of MySQL vs MariaDB : this is important if you plan to use Mageia on a production server [...] yup these are important. also important is to have an official maintainer for a package like mysql...
Re: [Mageia-dev] RFC: Drop mkinitrd completely in favour of dracut.
On 02.12.2011 15:57, Anssi Hannula wrote: On 02.12.2011 13:28, Colin Guthrie wrote: Hi, Just a suggestion! Should we move wholesale to dracut? It's very easy to hack on, and Harald Hoyer has been very helpful and has merged some of the patches we carried locally (which I mostly copied from Mandriva). Not sure why they were not upstreamed before. There are still a couple patches we carry locally (soon to be less when Harald pushes his git repo and I rebase), but they are pretty trivial, understandable and easily maintainable (mostly they will be stylistic tweaks and naming variations - i.e. very minor). Modprobe rules are included even in the initrd so tweaks there follow through. I'm not necessarily against keeping mkinitrd, but I think we should take the time from now until the beta phase to obsolte mkinitrd and force everyone to use dracut in order to see if there are any issues and then make the call before next beta or rc. +1 One thing that doesn't work with dracut yet is that it only includes the KMS drivers into initramfs if they are loaded at the time of initramfs creation, causing unoptimal boot screen when a) initramfs created by the installer (I guess), and when b) user has switched a driver non-kms - kms. This can probably be solved by some patching of modules.d/50plymouth/module-setup.sh, but I haven't looked at it closely yet. Patch attached. I guess this would remain as a Mageia specific patch as the wanted behavior is dependant on how the distribution handles driver switching etc... Shall I apply it? -- Anssi Hannula --- /usr/share/dracut/modules.d/50plymouth/module-setup.sh-OLD 2011-12-02 12:43:22.0 +0200 +++ /usr/share/dracut/modules.d/50plymouth/module-setup.sh 2011-12-02 22:40:03.525836233 +0200 @@ -14,7 +14,17 @@ local _modname # Include KMS capable drm drivers for _modname in $(find $srcmods/kernel/drivers/gpu/drm $srcmods/extra \( -name '*.ko' -o -name '*.ko.gz' \) 2/dev/null); do -zgrep -q drm_crtc_init $_modname instmods $_modname +if zgrep -q drm_crtc_init $_modname; then +# if the hardware is present, include module even if it is not currently loaded, +# as we could e.g. be in the installer; nokmsboot boot parameter will disable +# loading of the driver if needed +if [[ $hostonly ]] modinfo -F alias $_modname | sed -e 's,\?,\.,g' -e 's,\*,\.\*,g' \ + | grep -qxf - /sys/bus/pci/devices/*/modalias; then +hostonly='' instmods $_modname +continue +fi +instmods $_modname +fi done }
Re: [Mageia-dev] RFC: Drop mkinitrd completely in favour of dracut.
Anssi Hannula skrev 2.12.2011 23:17: Patch attached. I guess this would remain as a Mageia specific patch as the wanted behavior is dependant on how the distribution handles driver switching etc... Speaking of driver switching... Is it possible to detect missing radeon firmware in initrd in early boot, and then switch to loading radeon with modeset=0 ? -- Thomas
Re: [Mageia-dev] Dolphin toolbar default settings in mga2 alpha
On 02/12/11 16:41, Balcaen John wrote: Le vendredi 2 décembre 2011 14:56:45 Barry Jackson a écrit : Anyone else find the default settings in Dolphin after a clean Alpha1 installation utterly useless? It's not even possible to easily navigate a file system without UP and BACK buttons. For new users I think the toolbar should have all the regularly needed buttons in place out of the box. I tried to figure out where these are stored and in which package, but after half an hour I gave up :\ If i'm not wrong there's some changes regarding dolphin's configuration, it was already reported to me last week. I'll be able to work again on kde's configuration soon (i was quite buzy) Good that's excellent. May I suggest a basic default toolbar? HOME,BACK,FORWARDS,UP,RELOAD,FIND,SPLIT,Show Hidden Files I see no reason to add anything that is in the context menu. Also:- May I suggest that the icon view is NOT the default and that the details view be made default. I really can't imagine that anyone who uses dolphin for anything serious would use the icon view, as long filenames get truncated. It gets quite tedious changing it for both root and normal user on each fresh installation. Just my 2 cents ;) Barry
Re: [Mageia-dev] RFC: Drop mkinitrd completely in favour of dracut.
I'm not necessarily against keeping mkinitrd, but I think we should take the time from now until the beta phase to obsolte mkinitrd and force everyone to use dracut in order to see if there are any issues and then make the call before next beta or rc. WDYT? Well i still have a problem to have a valid initramfs for a livecd with dracut, but i have to investigate a bit more if it's me or dracut :) has anyone else tried to get it working for that? -- Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] RFC: Drop mkinitrd completely in favour of dracut.
On 03.12.2011 00:18, Thomas Backlund wrote: Anssi Hannula skrev 2.12.2011 23:17: Patch attached. I guess this would remain as a Mageia specific patch as the wanted behavior is dependant on how the distribution handles driver switching etc... Speaking of driver switching... Is it possible to detect missing radeon firmware in initrd in early boot, and then switch to loading radeon with modeset=0 ? Seems doable (if a bit hacky), but unfortunately new radeon cards (at least cayman/northern islands) do not work without KMS at all (while slightly older cards like Evergreen mostly work but without any kind of 2d/3d acceleration). This also means that X server will fail to start since it doesn't fallback to autodetection (and therefore vesa) when the card is explicitely listed in xorg.conf. Not quite sure what is the best way forward. BTW, shouldn't we regenerate initrds when installing radeon-firmware for the first time? -- Anssi Hannula
Re: [Mageia-dev] Replacing mysql with mariadb
On 02/12/11 16:27, Maarten Vanraes wrote: Op vrijdag 02 december 2011 14:40:40 schreef Barry Jackson: On 02/12/11 00:20, Maarten Vanraes wrote: Op vrijdag 02 december 2011 00:13:28 schreef Barry Jackson: On 01/12/11 22:47, Maarten Vanraes wrote: if you have a cauldron, you can enable updates_testing and then: * rpm -e --nodeps all the mysql packages you have * urpmi all the identical mariadb packages OK - I guess the names are similar - not looked yet ;) I said I would need help :\ thanks for that! i guess i should be clearer, i meant the packages that are built from the mysql src.rpm this is for you: mysql-common-core-5.5.15-2.mga2 lib64mysqlservices-5.5.15-2.mga2 lib64mysqld0-5.5.15-2.mga2 mysql-client-5.5.15-2.mga2 mysql-core-5.5.15-2.mga2 mysql-5.5.15-2.mga2 lib64mysql18-5.5.15-2.mga2 mysql-common-5.5.15-2.mga2 lib64mysql-devel-5.5.15-2.mga2 Yet with testing enabled I see :- [baz@jackodesktop ~]$ urpmq mariadb -a mariadb [...] (afaik mariadb is an exact match, so maybe that's why it lists only mariadb) [root@localhost ~]# urpmq -Y mariadb lib64mariadb-devel lib64mariadb-embedded-devel lib64mariadb-embedded0 lib64mariadb18 lib64mariadbservices mariadb mariadb-bench mariadb-client mariadb-common mariadb-common-core mariadb-core thus, for you: mariadb-common-core lib64mariadbservices lib64mariadb-embedded0 mariadb-client mariadb-core mariadb lib64mariadb18 mariadb-common lib64mariadb-devel happy testing :-) Thanks, In fact all (except the -devel) were installed by default:- [root@jackodesktop baz]# urpmi mariadb In order to satisfy the 'libmysqlservices.so()(64bit)' dependency, one of the following packages is needed: 1- lib64mysqlservices-5.5.15-2.mga2.x86_64: Shared libraries (to install) 2- lib64mariadbservices-5.5.15-0.4.mga2.x86_64: Shared libraries (to install) What is your choice? (1-2) 2 To satisfy dependencies, the following packages are going to be installed: PackageVersion Release Arch (medium Core Updates Testing (distrib5)) lib64mariadb18 5.5.15 0.4.mga2 x86_64 lib64mariadbservices 5.5.15 0.4.mga2 x86_64 mariadb5.5.15 0.4.mga2 x86_64 mariadb-client 5.5.15 0.4.mga2 x86_64 mariadb-common 5.5.15 0.4.mga2 x86_64 mariadb-common-core5.5.15 0.4.mga2 x86_64 mariadb-core 5.5.15 0.4.mga2 x86_64 97MB of additional disk space will be used. 7.3MB of packages will be retrieved. Proceed with the installation of the 7 packages? (Y/n) y snip-- OK testing so far with ZoneMinder:- For those not familiar with ZoneMinder, in brief:- ZoneMinder is a LAMP Web application for monitoring CCTV cameras, recording the video streams and serving them to LAN or WAN. It relies on a deep mysql database to store thousands of images in real time. It also uses mysql to store the log files and display them in a web browser in the ZoneMinder console. I installed mariadb this evening and after working around a minor mariadb packaging hiccup ;) (which is now apparently fixed in svn) I re-built ZoneMinder against it. There were no issues in the re-build and the application seems totally transparent to the change. There were no issues with my setup script which starts mysql, checks for an existing mysql password, offers to optionally create one, checks for an existing zm database and offers to use it, or replace it. I replaced it and a new one was created without problem. The script then started httpd and the ZoneMinder service. No problems at all. The only operational checks so far involve the logging database, but that is working fine. Unfortunately I cannot test under full working conditions without capture card or network cameras which I don't have connected to this hardware. I do have a server running ZoneMinder on mga1 with 8 cameras but until mga2 is released and settled for a while I won't be updating it. So in a nutshell as far as I have tested it just works out of the box. :) Barry
[Mageia-dev] zarafa dep issue
boost upgrade broke zarafa deps Funda, I saw you working on this package. No problem, I just don't want both of us working on fixing this. Let me know. -- Thomas
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release courier-authlib-0.63.0-9.mga2
On 28/11/11 14:39, Guillaume Rousse wrote: Le 28/11/2011 14:46, Mageia Team a écrit : barjacbarjac 0.63.0-9.mga2: + Revision: 173752 - Added ldconfig in %post and %postun This is supposed to be done automatically by file triggers... Yes - I was only reading something about that yesterday, however after installation of courier-authlib prior to the addition of ldconfig in %post and %postun, courier-imap would not build as it could not find a lib installed by courier-authlib. I spent a lot of time with help from various people with more experience than I have, trying to track down why courier-imap builds were failing (only in Cauldron BTW) :\ There are some build output log extracts in https://bugs.mageia.org/show_bug.cgi?id=1974 Barry (barjac)
Re: [Mageia-dev] zarafa dep issue
Thanks, you could give a try on zarafa, it seems that zarafa saying boost 1.48 is too new. 2011/12/3 Thomas Spuhler tho...@btspuhler.com: boost upgrade broke zarafa deps Funda, I saw you working on this package. No problem, I just don't want both of us working on fixing this. Let me know. -- Thomas
Re: [Mageia-dev] zarafa dep issue
I asked them on IRC and a ticket has already been filed Sent from my Motorola ATRIX™ 4G on ATT -Original message- From: Funda Wang fundaw...@gmail.com To: Mageia development mailing-list mageia-dev@mageia.org Sent: Sat, Dec 3, 2011 02:19:19 GMT+00:00 Subject: Re: [Mageia-dev] zarafa dep issue Thanks, you could give a try on zarafa, it seems that zarafa saying boost 1.48 is too new. 2011/12/3 Thomas Spuhler tho...@btspuhler.com: boost upgrade broke zarafa deps Funda, I saw you working on this package. No problem, I just don't want both of us working on fixing this. Let me know. -- Thomas
Re: [Mageia-dev] RFC: Drop mkinitrd completely in favour of dracut.
Anssi Hannula skrev 3.12.2011 01:06: On 03.12.2011 00:18, Thomas Backlund wrote: Anssi Hannula skrev 2.12.2011 23:17: Patch attached. I guess this would remain as a Mageia specific patch as the wanted behavior is dependant on how the distribution handles driver switching etc... Speaking of driver switching... Is it possible to detect missing radeon firmware in initrd in early boot, and then switch to loading radeon with modeset=0 ? Seems doable (if a bit hacky), but unfortunately new radeon cards (at least cayman/northern islands) do not work without KMS at all (while slightly older cards like Evergreen mostly work but without any kind of 2d/3d acceleration). Yeah, I started thinking about those too after my post... This also means that X server will fail to start since it doesn't fallback to autodetection (and therefore vesa) when the card is explicitely listed in xorg.conf. Not quite sure what is the best way forward. Hm, so we would need a split in detection for nonkms capable cards and the rest... or take the easy way out and boot everyone on vesa until radeon firmware is available... BTW, shouldn't we regenerate initrds when installing radeon-firmware for the first time? Yeah, I've been thinking the same, but haven't gotten around to doing it yet. and what about nvidia* and fglrx, should they do the same ? and for a dkms related issue, I've also been thinking we whould trigger dkms rebuild on kernel install to save time on next bootup. -- Thomas
[Mageia-dev] podsleuth and ipod-sharp
Hello! podsleuth and ipod-sharp are discontinued upstream (Banshee 2.1 http://banshee.fm/download/archives/2-1-0/ openSUSE it dropped already) and moved to obsoletes in our svn. Please remove from mirrors
Re: [Mageia-dev] Preparing Alpha 1 isos of Mageia2
W dniu 23.11.2011 22:30, Philippe Makowski pisze: Pascal Terjanpter...@gmail.com a écrit : On Wed, Nov 23, 2011 at 15:34, philippe makowski makowski.mag...@gmail.com wrote: 2011/11/23 Funda Wangfundaw...@gmail.com: The problem is, why we are shipping a dead package? Dead ? https://bitbucket.org/troorl/pino3/ not sure it is dead It is dead as in build errors reported 1 year ago have not been fixed Ok dead or nearly, no package maintainer, certainly alternatives (I don't know) so we can drop it pino is moved to obsoletes in our svn Please remove it from mirrors
