Re: [Mageia-dev] [soft-commits] [2494] Port stage2 to use udev.
On 19 December 2011 23:47, wrote:
> Log Message
>
> Port stage2 to use udev.
>
> In order to run dracut in the installer, it is necessary to have a working
> udev setup (specifically /dev/block/* nodes, but there may be other
> requirements).
>
> As dracut is needed by systemd when /usr is on a separate partition, we need
> udev in the installer in order to support systemd generally.
>
> Modified Paths
>
> drakx/trunk/perl-install/install/Makefile
> drakx/trunk/perl-install/install/install2.pm
> drakx/trunk/perl-install/install/share/list.xml
>
> Modified: drakx/trunk/perl-install/install/Makefile
> ===
> --- drakx/trunk/perl-install/install/Makefile 2011-12-19 21:36:04 UTC (rev
> 2493)
> +++ drakx/trunk/perl-install/install/Makefile 2011-12-19 22:47:15 UTC (rev
> 2494)
> @@ -47,6 +47,7 @@
>
> get_needed_files: xs
> REP4PMS=$(REP4PMS) ../../tools/install-xml-file-list share/list.xml
> $(DEST)
> + mkdir -p $(DEST)/run
That won't work. stage2 is mounted by stage1 in /tmp/stage2
so you want to create & include it in stage1
> Modified: drakx/trunk/perl-install/install/install2.pm
> ===
> --- drakx/trunk/perl-install/install/install2.pm 2011-12-19 21:36:04 UTC
> (rev 2493)
> +++ drakx/trunk/perl-install/install/install2.pm 2011-12-19 22:47:15 UTC
> (rev 2494)
> @@ -395,6 +395,24 @@
> eval { fs::mount::mount('none', '/sys', 'sysfs', 1) };
> eval { touch('/root/non-chrooted-marker.DrakX') }; #- helps
> distinguishing /root and /mnt/root when we don't know if we are chrooted
>
> +# Ensure /run is mounted
> +mkdir "/run", 0755;
> +run_program::run("mount -t tmpfs -o mode=0755,nosuid,nodev tmpfs
> /run");
> +mkdir "/run/udev", 0755;
> +mkdir "/run/udev/rules.d", 0755;
> +$ENV{UDEVRULESD} = "/run/udev/rules.d";
> +
> +# Start up udev and trigger cold plugs
> +run_program::run("mount", "-t", "devtmpfs", "-o", "mode=0755,nosuid",
> "devtmpfs", "/dev");
> +mkdir "/dev/pts", 0755;
> +run_program::run("mount", "-t", "devpts", "-o",
> "gid=5,mode=620,noexec,nosuid", "devpts", "/dev/pts");
> +mkdir "/dev/shm", 0755;
> +run_program::run("mount", "-t", "tmpfs", "-o",
> "mode=1777,nosuid,nodev", "tmpfs", "/dev/shm");
> +
> +run_program::run("/lib/udev/udevd", "--daemon",
> "--resolve-names=never");
> +run_program::run("udevadm", "trigger", "--type=subsystems",
> "--action=add");
> +run_program::run("udevadm", "trigger", "--type=devices",
> "--action=add");
A few remarks:
1) this is a little big, so better split it this into a new
start_udev() function
2) we prefer the fct(args) style over "fct args"
(which is enforced by perl_checker)
3) which bring me to the last item: you should run perl_checker
See /usr/share/doc/perl_checker/perl_checker.html &
/usr/share/doc/perl-MDK-Common/tutorial.html
It can be simply called from within emacs (or vim)
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release php-5.3.9-0.RC3.1.mga2
On 20 December 2011 03:08, Mageia Team wrote: > spuhler 3:5.3.9-0.RC3.1.mga2: > + Revision: 184708 > - upgrade to 5.4RC3 > synched with Mandriva You need to rebuild the whole PHP stack now
Re: [Mageia-dev] Issues with dracut
On Sun, 18 Dec 2011 17:22:46 -0500, Colin Guthrie wrote: Can you run the attached? It works. It identifies /usr as being on 252:9, which is on 8:12, which has the fs_type LVM2_member. Regards, Dave Hodgins
Re: [Mageia-dev] [soft-commits] [2494] Port stage2 to use udev.
On 20 December 2011 12:19, Colin Guthrie wrote:
>>> get_needed_files: xs
>>> REP4PMS=$(REP4PMS) ../../tools/install-xml-file-list share/list.xml
>>> $(DEST)
>>> + mkdir -p $(DEST)/run
>>
>> That won't work. stage2 is mounted by stage1 in /tmp/stage2
>> so you want to create & include it in stage1
>
> Right... strangely enough some stuff still worked fine... e.g.
> /lib/udev/udevd exists inside the installer shell so that's why I
> thought all was well. I double check a few things.
>
> Technically it's not super important that /run exists anyway as I mkdir
> it later, so this bit can probably be dropped.
Either you create it in stage1 or in the sub starting udev, but anyway
the Makefile should be reverted
>>> --- drakx/trunk/perl-install/install/install2.pm 2011-12-19 21:36:04 UTC
>>> (rev 2493)
>>> +++ drakx/trunk/perl-install/install/install2.pm 2011-12-19 22:47:15 UTC
>>> (rev 2494)
>>> @@ -395,6 +395,24 @@
>>> eval { fs::mount::mount('none', '/sys', 'sysfs', 1) };
>>> eval { touch('/root/non-chrooted-marker.DrakX') }; #- helps
>>> distinguishing /root and /mnt/root when we don't know if we are chrooted
>>>
>>> + # Ensure /run is mounted
>>> + mkdir "/run", 0755;
>>> + run_program::run("mount -t tmpfs -o mode=0755,nosuid,nodev tmpfs
>>> /run");
having perms from both chown & mount is maybe a little too much
>>> + mkdir "/run/udev", 0755;
>>> + mkdir "/run/udev/rules.d", 0755;
can be simplified mkdir_p("/run/udev/rules.d").
The perms should be OK through umask
>>> + $ENV{UDEVRULESD} = "/run/udev/rules.d";
>>> +
>>> + # Start up udev and trigger cold plugs
>>> + run_program::run("mount", "-t", "devtmpfs", "-o", "mode=0755,nosuid",
>>> "devtmpfs", "/dev");
>>> + mkdir "/dev/pts", 0755;
>>> + run_program::run("mount", "-t", "devpts", "-o",
>>> "gid=5,mode=620,noexec,nosuid", "devpts", "/dev/pts");
>>> + mkdir "/dev/shm", 0755;
This one should be better included in stage1 with other /dev stuff IMHO
See images/make_boot_img
>>> + run_program::run("mount", "-t", "tmpfs", "-o",
>>> "mode=1777,nosuid,nodev", "tmpfs", "/dev/shm");
>>> +
>>> + run_program::run("/lib/udev/udevd", "--daemon",
>>> "--resolve-names=never");
I guess it auto detach with --daemon?
If not we could use "raw({ detach => 1}," instead of "run("
I think you wan
>>> + run_program::run("udevadm", "trigger", "--type=subsystems",
>>> "--action=add");
>>> + run_program::run("udevadm", "trigger", "--type=devices",
>>> "--action=add");
Since this will forces us to wait, you should either display a "please
wait dialog"
or better not run this as we'll only look at block devices quite a lot later
after accepting license & loading disks modules
>> 3) which bring me to the last item: you should run perl_checker
>> See /usr/share/doc/perl_checker/perl_checker.html &
>> /usr/share/doc/perl-MDK-Common/tutorial.html
>> It can be simply called from within emacs (or vim)
>
> Cool, thanks. I'm not a perl-master so feel free to tidy this commit up
> a bit if you have time, otherwise I'll try and tidy up my mess this
> evening :)
There's no urgency so it's better if done by you so that
you eventually became a co maintainer of drakx :-)
BTW you may eventually include udev in rescue too
(but only once it's done in stage2)
See rescue/ && rescue/devices.pl
Re: [Mageia-dev] qtwebkit libification problem
Den 22:26 18. desember 2011 skrev Colin Guthrie følgende: > [colin@jimmy ~]$ rpm -qf /usr/lib/qt4/imports/QtWebKit/libqmlwebkitplugin.so > lib64qtwebkit2.2_4-2.2.0-1.mga2 > libqtwebkit2.2_4-2.2.0-1.mga2 > > Strangely RPM let me install both arches even tho' the file is different :s This is likely due to coloring, if you install packages with the same filename which has different colors (ie. ia32 & x86_64), RPM will allow the x86_64 version to be installed over the other. It's a cheap way to get around "proper" multilib packaging that's enabled by default in RPM (you've probably wondered earlier about Fedora's take on multilib with the lack of same strict packaging policies that we enforce..), but that's been disabled for RPM in Mandriva for ages. It's a mechanism I lack any real insight on, and I don't even remember where in the RPM code this change was made, much less so what particular patch being responsible for it, only reference I can recall is some brief documentation at rpm5.org (dont-filter-install-file-conflicts): http://rpm5.org/cvs/fileview?f=rpm/VENDOR > > Not quite sure why. The first run didn't and then the second somehow > worked without me doing anything to force it. I'm merely making wild guesses, it might be totally unrelated to coloring, but if it's related in any way, then the relevant patch has probably accidentally been dropped, or there might've been some upstream changes, likely requiring a new patch to be (re)done.. My 2 cents at least.. :) -- Regards, Per Øyvind
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release systemd-37-15.mga2
On 15 December 2011 12:02, Mageia Team wrote: > colin 37-15.mga2: > + Revision: 182053 > - Do not start getty on tty1, it's used for X11 now (mga#3430) BTW systemd-sysvinit bloats again minimal installation by requiring python because of systemd-sysv-convert, that doesn't seem used. Please move it into systemd-tools in order to debloat minimal install
Re: [Mageia-dev] [soft-commits] [2501] add missing news
On 24 December 2011 00:26, wrote: > add missing news > Modified: drakx/trunk/perl-install/NEWS > === > --- drakx/trunk/perl-install/NEWS 2011-12-23 01:59:03 UTC (rev 2500) > +++ drakx/trunk/perl-install/NEWS 2011-12-23 23:26:06 UTC (rev 2501) > @@ -4,6 +4,7 @@ >o display partition labels when adding a foreign OS > - harddrake: fix missing names (mga#3745) > - interactive::curses: default to 80x25 (fixes serial) > +- dont force init=/bin/systemd (#3856, already fixed in svn by blino) please remove ", already fixed in svn by blino", this has nothing to do in changelog
Re: [Mageia-dev] dracut/plymouth broken...
'Twas brillig, and Thomas Backlund at 18/12/11 22:22 did gyre and gimble: > Colin Guthrie skrev 19.12.2011 00:18: >> 'Twas brillig, and Thomas Backlund at 18/12/11 21:57 did gyre and gimble: >>> I: Wrote /boot/initrd-3.1.6-desktop-0.rc1.1.1.mga2.img: >>> I: -rw-r--r-- 1 root root 6934831 dec 18 23:50 >>> /boot/initrd-3.1.6-desktop-0.rc1.1.1.mga2.img >>> Need 'inst' function, try setting PLYMOUTH_POPULATE_SOURCE_FUNCTIONS to >>> a file that defines it >>> Option exclude requires an argument >>> usage: cpio-filter [--exclude] [--in-place] [] >> >> How did you trigger this? I've not seen this error. Do you have a >> special/different plymouth theme set as default? >> >> Col >> > > Nope, default plymouth theme. > > Triggered by simply installing a kernel with urpmi --auto-update Think this should be fixed by Anssi's commits in plymouth, bootsplash and dracut now. Due to me obsoleting mkinitrd and some incompatibilities between paths from dracut 014 and plymouth in git. Cheers 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/
[Mageia-dev] [ATT] broken initramfs generation
Hi all! dracut-015-5.mga2 which was uploaded some 8 hours ago breaks initramfs generation due to a path change and issues in 'plymouth' and 'bootsplash' backages. If you've configured your bootloader configuration with MCC or installed new kernels with this version of dracut installed (even if you've later upgraded), you may have had one or more of your initramfs files truncated, which will cause a boot failure. You can check if you are affected by using e.g. this command to print suspiciously small initramfs files: find /boot/initrd*.img -size -1M -type f If that is the case, you should wait without rebooting until - plymouth-scripts-0.8.4-0.20111214.2.mga2 - bootsplash-3.3.6-1.mga2 are available and installed on your system, and then run: bootloader-config --action rebuild-initrds After that please double-check with the 'find' command that no truncated iniramfs files exist. If there are any, please report it. Also, if you don't have truncated files but have dracut-015.5.mga2, please upgrade to the above versions ASAP to prevent truncations from happening in the future. -- Anssi Hannula
[Mageia-dev] Problem with latest Evolution and attachements
Since updating to Evolution 3.3.3 in Cauldron, I have notice the program crashes (segfaults) when trying to add multiple attachments (using the CTRL key to select more than one attachment in the file dialog) When Evolution is started again, then I can recover the new message which crashed during multiple file attachments. Seems related to holding down the CTRL key and selecting a file to attach . . . Cheers, R.Fox
[Mageia-dev] Problem with latest Evolution and attachements
Since updating to Evolution 3.3.3 in Cauldron, I have notice the program crashes (segfaults) when trying to add multiple attachments (using the CTRL key to select more than one attachment in the file dialog) When Evolution is started again, then I can recover the new message which crashed during multiple file attachments. Seems related to holding down the CTRL key and selecting a file to attach . . . Cheers, R.Fox
Re: [Mageia-dev] [soft-commits] [2419] do not hardcode systemd default through kernel command line, it should be easily overridable by just picking the proper init package
'Twas brillig, and Thierry Vignaud at 19/12/11 10:20 did gyre and gimble: > On 14 December 2011 23:49, wrote: >> Revision 2419 Author blino Date 2011-12-14 23:49:18 +0100 (Wed, 14 Dec 2011) >> >> Log Message >> >> do not hardcode systemd default through kernel command line, it should be >> easily overridable by just picking the proper init package > > Next time alter meta-task's prefer.vendor.list too.. Ahhh, this explains a problem reported on IRC last night. Excellent, things bugs from last night are making sense now :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/
[Mageia-dev] Upgrade to KDE 4.7.95 breaks the desktop
After updating cauldron, the destop is empty: all icons and plasmoids are missing. It is necessary to rename or remove ~/.kde4/ to recreate a new usable desktop. This is easy for us, but it should be better to keep as much as possible of old configuration. What must be done during the upgrade to KDE >= 4.7.95 ? -- Pierre Jarillon - http://pjarillon.free.fr/ Vice-président de l'ABUL : http://abul.org/ Microsoft est à l'informatique ce que McDonald est à la gastronomie.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release systemd-37-15.mga2
'Twas brillig, and Thierry Vignaud at 19/12/11 10:18 did gyre and gimble: > On 15 December 2011 12:02, Mageia Team wrote: >> colin 37-15.mga2: >> + Revision: 182053 >> - Do not start getty on tty1, it's used for X11 now (mga#3430) > > BTW systemd-sysvinit bloats again minimal installation by requiring python > because of systemd-sysv-convert, that doesn't seem used. > Please move it into systemd-tools in order to debloat minimal install ACK To be honest, I think Lennart really didn't like that utility... it was only included in Fedora due to politics I think, so we should likely just drop 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] [soft-commits] [2494] Port stage2 to use udev.
On 20 December 2011 12:42, Thierry Vignaud wrote: > There's no urgency so it's better if done by you so that > you eventually became a co maintainer of drakx :-) > > BTW you may eventually include udev in rescue too > (but only once it's done in stage2) > See rescue/ && rescue/devices.pl Also next time it's better to split in smaller commits: 1) add new files needed for udev 2) start udev 3) ... Last but not least add a one to 3 line description about udev at top of perl-install/install/NEWS
[Mageia-dev] php-5.4RC3
php-5.4RC3 will hit the mirrors soon. It may beak a few things. -- Best regards Thomas Spuhler
[Mageia-dev] Fwd: Re: [Cooker] System can stall under heavy IOs with slow storage devices
I've been noticing this symptom for a while now especially when running programs that copy large files using large buffer sizes. It's worse than just firefox, as the entire desktop will freeze for minutes at a time. This change/workaround cleared this up entirely for me. If we haven't incorporated this yet, we should consider doing so. Original Message Subject: Re: [Cooker] System can stall under heavy IOs with slow storage devices Date: Mon, 19 Dec 2011 19:36:02 +0100 From: Florian Hubold Reply-To: coo...@mandrivalinux.org To: coo...@mandrivalinux.org Am 19.12.2011 10:26, schrieb Franck Bui: Hello, I've noticed a regression on my system which can stall some applications (most notably firefox) during very very long time (> 10 mins). Man, you're my hero, trying to find out what causes this since some months now. At least two thumbs up! :) It's apparently related to transparent huge pages and I found that it had already been described by LWN here a month ago: http://lwn.net/Articles/467328/. Unlike what it's stated in the article, the regression is not really hard to trigger in my case: just plug a USB stick, copy on it a big file, then try to use firefox... To fix this, simply try to disable THP: echo madvise>/sys/kernel/mm//transparent_hugepage/enabled and firefox should work as expected now. So, if no one objects, the plan is to simply default the THP stuff to "madvise" for desktop flavour where an application has to ask explicitly huge page otherwise it will be disabled.
Re: [Mageia-dev] dracut/plymouth broken...
On 19.12.2011 06:23, Anssi Hannula wrote: > On 19.12.2011 00:22, Thomas Backlund wrote: >> Colin Guthrie skrev 19.12.2011 00:18: >>> 'Twas brillig, and Thomas Backlund at 18/12/11 21:57 did gyre and gimble: I: Wrote /boot/initrd-3.1.6-desktop-0.rc1.1.1.mga2.img: I: -rw-r--r-- 1 root root 6934831 dec 18 23:50 /boot/initrd-3.1.6-desktop-0.rc1.1.1.mga2.img Need 'inst' function, try setting PLYMOUTH_POPULATE_SOURCE_FUNCTIONS to a file that defines it Option exclude requires an argument usage: cpio-filter [--exclude] [--in-place] [] >>> >>> How did you trigger this? I've not seen this error. Do you have a >>> special/different plymouth theme set as default? >>> >>> Col >>> >> >> Nope, default plymouth theme. >> >> Triggered by simply installing a kernel with urpmi --auto-update [...] > So plymouth-scripts breaks as dracut-functions got moved, and the old > mkinitrd functions are no longer present after the obsoletes was added. > In addition, make-boot-splash-raw seems to not handle the failure > properly, creating empty initramfs instead. > > I'm going to look at this right now to fix at least the first one. I'm > not 100% sure if this add_boot_splash() stuff is needed at all (for > customs bootsplashes maybe?), but I'll leave that for Colin to look at :) Fixed both the dracut-functions-not-found and error-not-handled issues in: plymouth-scripts-0.8.4-0.20111214.2.mga2 bootsplash-3.3.6-1.mga2 Either of these packages will prevent initramfs from getting truncated. -- Anssi Hannula
[Mageia-dev] RFC: udev in stage1 (installer currently broken)
Hi, OK, so it seems that my pushing of dracut has indeed broken the install stage. It's ultimately down to /dev/block/ not existing in the installer which is also a fallout from it not using udev. As systemd basically needs dracut, I think we now need to look at putting udev to work in the installer rather than a static /dev tree. What do people think of this? I'm not sure how stage1 works, but (in theory at least) it could be generated via a dracut module - dracut itself is pretty flexible for producing these kind of things... having never looked at how stage1 is created, this is perhaps a very outlandish suggestion! Anyway, comments about this welcomed. Obviously it would be nice to look at this sooner rather than later. Also not sure how mdv handles this considering they are now using systemd+dracut too. 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] [soft-commits] [2419] do not hardcode systemd default through kernel command line, it should be easily overridable by just picking the proper init package
On 14 December 2011 23:49, wrote: > Revision 2419 Author blino Date 2011-12-14 23:49:18 +0100 (Wed, 14 Dec 2011) > > Log Message > > do not hardcode systemd default through kernel command line, it should be > easily overridable by just picking the proper init package Next time alter meta-task's prefer.vendor.list too..
[Mageia-dev] Improving Boxes experience on Mageia
>From https://plus.google.com/109973678654056732542/posts/drB3U65Hptt: "Yeah, thats what I meant by 'unknown media' in my previous blog entry. To make Boxes support your favourite distro as nicely as Fedora and Windows, you need to: 1. Put metadata about it in libosinfo's default DB (its simple and intuitive XML files) with information about its latest media. 2. Add unattended installation for it in Boxes. This will need some hacking but its not as difficult at one might imagine. :)" Anyone willing to ensure Boxes works nicely with Mageia by submitting a libosinfo XML file (upstream!) + ensure the unattended installation works by hacking Boxes? Bit swamped myself... -- Regards, Olav
[Mageia-dev] Package drop request: perl-Gtk2-MozEmbed
Hello, Is it possible if we drop perl-Gtk2-MozEmbed from cauldron? It is not required by any other packages, and it is the one of the only few packages depending on libxulrunner.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kernel-linus-3.2.0-0.rc7.1.mga2
24.12.2011 15:23, Mageia Team kirjutas: Name: kernel-linus Relocations: (not relocatable) + Revision: 187187 - trigger dkms build in posttrans so modules get built at kernel install instead of at boot (speeds up boot time with new kernel) How do you make sure that latest devel is updated for that time? Last time i updated cauldron some dkms packages failed to build as kernel-*-devel was one of the last packages to get updated. Just curious, nothing more :) -- Sander
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release qt3-3.3.8b-30.mga2
On 26 December 2011 04:30, Mageia Team wrote: > fwang 3.3.8b-30.mga2: > + Revision: 187720 > - set system flags Wasn't this one supposed to be never imported?
[Mageia-dev] Fresh install loops in mkinitrd
In today's cauldron, a fresh install loops in the bootloader stage because something has suddenly decided that it knows when stuff is taking too long. VC3 shows "ERROR: killing runaway process (process=mkinitrd.error=ALARM at /usr/lib/libDrakx/run_program.pm line 92" In the GUI, you get a graphical prompt saying that an error occurred and mkinitrd failed, and if you click OK (the only choice), it goes and tries the mkinitrd again, fails again, . So, basically, the install stops there, as you can't get to Summary.
Re: [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia
On Wednesday, December 21, 2011 12:15:00 AM you wrote: > Hello! > > Excuse me for using you e-mail address directly, I'm sending BCC to > every person who commented on the subject "Consolidation of the spelling > tools in Mageia" in the Mageia-Dev mailing-list. I'm doing it, because > the mailing-list isn't accessible and there is no ETA on resolving it. > > There was a discuss on > 1) preparing policies on hunspell-dictionaries > 2) deprecate and kill myspell in Mga2 > 3) changing the default path of dictionaries, from /usr/share/myspell to > /usr/share/hunspell (and to keep backward compatibility links in myspell > directory) > 4) to provide "enchant-dictionary" and "hunspell-dictionary" by every > hunspell-dictionary > > So finally, I've prepared a first version of the policy > https://wiki.mageia.org/en/Hunspell-dictionary_policy > If you like, please tell me your comments of it. Is it right? (Also: is > the .spec correct?) When everything will be accepted then every > hunspell-dictionary will be updated according to the policy. > > PS. The changes of enchant will be proposed or accepted later, Funda has > already prepared the package. I strongly suggest to obsolete aspell as well. It doesn't have a maintainer. -- Best regards Thomas Spuhler
Re: [Mageia-dev] Adding additional provides to php database modules
On Saturday, December 17, 2011 03:24:16 PM Oliver Burger wrote: > Hi, > > I'm maintaining mediawiki and drupal. > > Both packages require a php database module but both can work with mysql, > postgresql and sqlite. > > Now the mediawiki package does simply require both php-mysql and php-pgsql, > which is bad since it leads to installing unneeded database libraries in > the system. > Drupal has three sub packages which doe require the respective php database > module and one of the three is required by drupal itself, which is some > kind of ugly workarround. > > I think it would be a cleaner solution to have php-X providing something > common and php-pdo_X providing something common (X being one of mysql, > pgsql or sqlite). > > What do you think? > I tried contacting the php maintainer by mail, but he didn't answer me. > > Oliver Could you please explain a little more what you are looking for. PHP provides the php-mysql and php-pdo-mysql -- Best regards Thomas Spuhler
[Mageia-dev] Conflicts between kde 4.7.90 and laptop-mode-tools
This has been going on for a few days. Not a whisper of a problem on non-laptop systems: Some requested packages cannot be installed: calligra-l10n-it-2.3.85-1.mga2.noarch (due to unsatisfied calligra-core) calligra-l10n-pt-2.3.85-1.mga2.noarch (due to unsatisfied calligra-core) gnome-control-center-3.3.3-1.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libupower-glib.so.1()(64bit)) gnome-settings-daemon-3.3.3-12.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libupower-glib.so.1()(64bit)) kdebase4-workspace-4.7.90-2.mga2.x86_64 (due to unsatisfied pm-utils-1.4.1-3.mga1.i586) kdebase4-workspace-devel-4.7.90-2.mga2.x86_64 (due to conflicts with kdebase4-workspace-4.7.90-2.mga2.x86_64, trying to promote kdebase4-workspace) kdevelop4-4.2.3-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) kdm-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64kdecorations4-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64kfontinst4-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64kfontinstui4-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64khotkeysprivate4-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64kscreensaver5-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64ksgrd4-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64ksignalplotter4-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64kwineffects1-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64kwinglutils1-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64kworkspace4-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64lsofui4-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64oxygenstyle4-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64oxygenstyleconfig4-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64plasma_applet_system_monitor4-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libplasma.so.3()(64bit)) lib64plasmaclock4-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64plasmagenericshell4-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64powerdevilconfigcommonprivate4-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64powerdevilcore0-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64powerdevilui4-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64processcore4-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64processui4-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64solidcontrol4-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64systemsettingsview2-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64taskmanager4-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) lib64weather_ion6-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to promote libkdecore.so.5()(64bit)) libupower-glib1-0.9.14-11.mga2.i586 (due to unsatisfied upower[>= 0.9.14-11.mga2]) plasma-applet-battery-4.7.90-2.mga2.x86_64 (due to conflicts with laptop-mode-tools-1.60-2.mga2.noarch, trying to
Re: [Mageia-dev] RFP: commenting obsoletes for later removal
Den 14:13 17. desember 2011 skrev Maarten Vanraes følgende: > Hi all, > > Annsi, misc and myself were discussing obsoletes, and i think we should make a > policy for a structured comment, so that later (in some timeperiod that's as > of yet unspecified) we can remove older obsoletes in a structured way. > > I propose we put a comment in the spec file, with the version the package will > be first used, so likely that is cauldron, so example: > > # Obsoletes: mga2 > (before the obsolete line) > > > if noone objects, we can put the policy on the wiki somewhere You could always comparing the metadata of different stable releases to try determine the age of these. I remember discussing this with pixel a few years ago, but it wasn't really an important issue and never given any priority, but implementing automated tests for this in ie. the youri(-related) tools would probably be a good idea. :) -- Regards, Per Øyvind
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release tftp-5.2-1.mga2
On 19 December 2011 17:21, Mageia Team wrote: > zezinho 5.2-1.mga2: > + Revision: 184408 > - new version Failed to issue method call: Unit tftp.service failed to load: No such file or directory. See system logs and 'systemctl status tftp.service' for details. warning: %post(tftp-server-5.2-1.mga2.x86_64) scriptlet failed, exit status 1
[Mageia-dev] Problem with latest Evolution and attachements
Since updating to Evolution 3.3.3 in Cauldron, I have notice the program crashes (segfaults) when trying to add multiple attachments (using the CTRL key to select more than one attachment in the file dialog) When Evolution is started again, then I can recover the new message which crashed during multiple file attachments. Seems related to holding down the CTRL key and selecting a file to attach . . . Cheers, R.Fox
Re: [Mageia-dev] [soft-commits] [2494] Port stage2 to use udev.
On 20 December 2011 12:59, Colin Guthrie wrote:
> 'Twas brillig, and Thierry Vignaud at 20/12/11 11:42 did gyre and gimble:
> + # Start up udev and trigger cold plugs
> + run_program::run("mount", "-t", "devtmpfs", "-o", "mode=0755,nosuid",
> "devtmpfs", "/dev");
> + mkdir "/dev/pts", 0755;
> + run_program::run("mount", "-t", "devpts", "-o",
> "gid=5,mode=620,noexec,nosuid", "devpts", "/dev/pts");
> + mkdir "/dev/shm", 0755;
>>
>> This one should be better included in stage1 with other /dev stuff IMHO
>> See images/make_boot_img
>
> With my earlier comment about stage1+dracut, I would tend to agree.
> Perhaps all this stuff can be in stage1 instead?
indeed
> + run_program::run("udevadm", "trigger", "--type=subsystems",
> "--action=add");
> + run_program::run("udevadm", "trigger", "--type=devices",
> "--action=add");
>>
>> Since this will forces us to wait, you should either display a "please
>> wait dialog"
>> or better not run this as we'll only look at block devices quite a lot later
>> after accepting license & loading disks modules
>
> Technically true, although this requires me to have a bit more
> understanding of how things work with the installer which I'd ideally
> like to avoid! :p
here we initialize the installer then loop over the steps (see
perl-install/install/steps_list.pm):
- choose language
- accepting license
- THEN load hd which will triggers udev to scan for LV or the like
So it's useless & not user friendly to force waiting for LVs here when
we know none will be found
>>> Cool, thanks. I'm not a perl-master so feel free to tidy this commit up
>>> a bit if you have time, otherwise I'll try and tidy up my mess this
>>> evening :)
>>
>> There's no urgency so it's better if done by you so that
>> you eventually became a co maintainer of drakx :-)
>
> I have a funny feeling that I'm being tricked into something here :p
It's not that hard :-)
>> BTW you may eventually include udev in rescue too
>> (but only once it's done in stage2)
>> See rescue/ && rescue/devices.pl
>
> Yeah it's needed in rescue too as I think I mentioned in an earlier
> email, but this is easier to get working I think.
BTW if you could look at those LVM/DM bugs in rescue:
https://bugs.mageia.org/buglist.cgi?cmdtype=runnamed&namedcmd=drakx-installer-rescue
Re: [Mageia-dev] [bugs] [Bug 2111] transcode, A linux video stream processing utility
On Sat, 24 Dec 2011 06:51:29 -0500, Oliver Burger wrote: And I do know, many plf packages are in tainted (that's why we do have tainted), the question remains, if a package being in plf2010.1 qualifies for pushing to updates. My understanding is that packages in 2010.2 plf free can go to tainted updates, but plf nonfree cannot.
Re: [Mageia-dev] ANN: X11 now starts on tty1
On Saturday 17 December 2011, Colin Guthrie wrote: > Back in the day, text logins were the norm, graphical logins came later. > Text logins got ttys 1-7... These days they are pretty much useless for > 99.5% of the use cases ... I'd like to question that. You see, machines still have 'init 3' (or did Fedora remove that, too?), there is still people wanting a Linux box (not desktop) not to have X. And that's way more than 0.5% . Or, X may be broken sometimes. So, standardization of tty1=text makes sense, is not just an old habit. Because, you are *always* expecting to find a working tty console on a Linux box[1], while X only launches a bit later, if it can[2]. Putting the one that works in the default place is more reasonable, see? Really, why don't you patch the kernel to start at tty7? you could call that "progress", too. Some things in Linux could improve, but some don't need change. Unix legacy is what makes Linux great[3], IMHO. Part of that legacy (the "old school") is to have failsafe defaults, is to start with a minimal design and then build the extras on top. That's why Unix principles (or "hangovers") have survived so many decades, while other OSs have gone with the wind[4]. http://en.wikipedia.org/wiki/Unix_philosophy , last of the "Quotes" [1] any machine that has a graphics card and a keyboard. [2] see nvidia, ati [3] back then, software was desinged by engineers. Time has proven that right. [4] Win95-98 had no "hangovers". Then, win2k became POSIX again. -- Say NO to spam and viruses. Stop using Microsoft Windows!
[Mageia-dev] Fwd: Re: [Cooker] System can stall under heavy IOs with slow storage devices
Florian reads both lists, so I'm pretty sure this would have been mentioned somewhere in Mageia-land, but I want to add that I have experienced extreme delays in firefox and other apps when I run largely IO-intensive apps with large file buffersizes, and the workaround in this comment fixes this completely. We should consider this for our kernels if we haven't already. Original Message Subject: Re: [Cooker] System can stall under heavy IOs with slow storage devices Date: Mon, 19 Dec 2011 19:36:02 +0100 From: Florian Hubold Reply-To: coo...@mandrivalinux.org To: coo...@mandrivalinux.org Am 19.12.2011 10:26, schrieb Franck Bui: Hello, I've noticed a regression on my system which can stall some applications (most notably firefox) during very very long time (> 10 mins). Man, you're my hero, trying to find out what causes this since some months now. At least two thumbs up! :) It's apparently related to transparent huge pages and I found that it had already been described by LWN here a month ago: http://lwn.net/Articles/467328/. Unlike what it's stated in the article, the regression is not really hard to trigger in my case: just plug a USB stick, copy on it a big file, then try to use firefox... To fix this, simply try to disable THP: echo madvise>/sys/kernel/mm//transparent_hugepage/enabled and firefox should work as expected now. So, if no one objects, the plan is to simply default the THP stuff to "madvise" for desktop flavour where an application has to ask explicitly huge page otherwise it will be disabled.
Re: [Mageia-dev] dracut/plymouth broken...
On 19.12.2011 00:22, Thomas Backlund wrote:
> Colin Guthrie skrev 19.12.2011 00:18:
>> 'Twas brillig, and Thomas Backlund at 18/12/11 21:57 did gyre and gimble:
>>> I: Wrote /boot/initrd-3.1.6-desktop-0.rc1.1.1.mga2.img:
>>> I: -rw-r--r-- 1 root root 6934831 dec 18 23:50
>>> /boot/initrd-3.1.6-desktop-0.rc1.1.1.mga2.img
>>> Need 'inst' function, try setting PLYMOUTH_POPULATE_SOURCE_FUNCTIONS to
>>> a file that defines it
>>> Option exclude requires an argument
>>> usage: cpio-filter [--exclude] [--in-place] []
>>
>> How did you trigger this? I've not seen this error. Do you have a
>> special/different plymouth theme set as default?
>>
>> Col
>>
>
> Nope, default plymouth theme.
>
> Triggered by simply installing a kernel with urpmi --auto-update
/usr/lib/libDrakX/bootloader.pm (drakxtools-backend):
sub mkinitrd {
[...]
# after mkinitrd command:
add_boot_splash($initrd, $entry->{vga} || $bootloader->{vga});
[...]
}
sub add_boot_splash {
[...]
run_program::rooted($::prefix,
'/usr/share/bootsplash/scripts/make-boot-splash', $initrd, $res->{X});
[...]
}
/usr/share/bootsplash/scripts/make-boot-splash (bootsplash):
[...]
$splash_dir/scripts/make-boot-splash-raw $initrd_file $THEME
[...]
/usr/share/bootsplash/scripts/make-boot-splash-raw (bootsplash):
[...]
/usr/libexec/plymouth/plymouth-populate-initrd -t $tmp_dir/plymouth
[...]
/usr/libexec/plymouth/plymouth-populate-initrd (plymouth-scripts):
[...]
if [ -f "${PLYMOUTH_LIBEXECDIR}/initrd-functions" ]; then
PLYMOUTH_POPULATE_SOURCE_FUNCTIONS="${PLYMOUTH_LIBEXECDIR}/initrd-functions"
elif [ -f "${MKINITRD_LIBEXECDIR}/functions" ]; then
PLYMOUTH_POPULATE_SOURCE_FUNCTIONS="${MKINITRD_LIBEXECDIR}/functions"
fi
if [ -f "${PLYMOUTH_DATADIR}/dracut/dracut-functions" ]; then
PLYMOUTH_POPULATE_SOURCE_FUNCTIONS="${PLYMOUTH_DATADIR}/dracut/dracut-functions"
fi
[...]
So plymouth-scripts breaks as dracut-functions got moved, and the old
mkinitrd functions are no longer present after the obsoletes was added.
In addition, make-boot-splash-raw seems to not handle the failure
properly, creating empty initramfs instead.
I'm going to look at this right now to fix at least the first one. I'm
not 100% sure if this add_boot_splash() stuff is needed at all (for
customs bootsplashes maybe?), but I'll leave that for Colin to look at :)
--
Anssi Hannula
[Mageia-dev] Install prompt about pcmcia
When firing up isolinux today, before even seeing the panel for install type (NFS, HTTP, et,) I get a panel saying that "we now use the kernel support for pcmcia, and this won't work with a 2.2 kernel". What does this mean ? What is using a 2.2 kernel ? How is a user to interpret/react to this ?
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release php-5.3.9-0.RC3.1.mga2
On 20 December 2011 03:08, Mageia Team wrote: > spuhler 3:5.3.9-0.RC3.1.mga2: > + Revision: 184708 > - upgrade to 5.4RC3 > synched with Mandriva You need to update the whole PHP stack now
[Mageia-dev] packaging savoir-vivre
Hello! What do you think of marking packages on which we (or our apprentices) are working? I've experienced that when we are working on a package - even if it is noticed on Bugzilla, Mageia-Dev or elsewhere - someone may simply check-out the package, bump version or make some changes (resolve a bug), check-in. We know that making changes in a long spec, may take days or even month (a lot of sources, large installation-tree, patches to review, consulting upstream etc), and rapid changes can do nothing good. Today I talked on it, how to prevent a package from being localized by someone and simply bumped without asking. So what do you think on marking packages that are underdevelopment? I think it's good to just simply mark it in the 1st line of a svn-spec: "# (name) date message", e.g. "# (john) 2011.12.20 please don't touch this package, I'm working on it right now, it may take a few weeks" or "# (john) 2011.08.23 don't update the version, it won't match current KDE". There is already a list of sensitive packages here https://wiki.mageia.org/en/Sensitive_packages maybe just it is sufficient for 10,000 packages distribution?
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release drakx-installer-images-1.58-5.mga2
On 25 December 2011 06:24, Mageia Team wrote: > tmb 1.58-5.mga2: > + Revision: 187364 > - build with kernel-3.2.0-0.rc7.1.mga2 BTW can you release 1.59? I've added missing nilfs2 module...
Re: [Mageia-dev] Upgrade to KDE 4.7.95 breaks the desktop
Le dimanche 25 décembre 2011 19:40:51 Pierre Jarillon a écrit : > After updating cauldron, the destop is empty: all icons and plasmoids are > missing. Well here « only » the pannel was missing during the upgrade (& not all plasmoids). > It is necessary to rename or remove ~/.kde4/ to recreate a new usable > desktop. This is easy for us, but it should be better to keep as much as > possible of old configuration. It would have been better to get ride of only the plasma* configuration files so you won't loose all kde's apps configuration. > > What must be done during the upgrade to KDE >= 4.7.95 ? Currently i don't know, i don't know why it did not happens during the 4.7.90 transition :/ Anyway of course we'll look & check how it could be fixed. (It could be related in fact to some configuration changes like for dolphin for example). -- Balcaen John Jabber-id: mik...@jabber.littleboboy.net
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release qt3-3.3.8b-30.mga2
Le lundi 26 décembre 2011 22:39:39 Thierry Vignaud a écrit : > On 26 December 2011 04:30, Mageia Team wrote: > > fwang 3.3.8b-30.mga2: > > + Revision: 187720 > > - set system flags > > Wasn't this one supposed to be never imported? It was imported for lsb. -- Balcaen John Jabber-id: mik...@jabber.littleboboy.net
Re: [Mageia-dev] Conflicts between kde 4.7.90 and laptop-mode-tools
Le jeudi 22 décembre 2011 17:02:50 Frank Griffin a écrit : > This has been going on for a few days. Not a whisper of a problem on > non-laptop systems: > [...] laptop-mode-tools is deprecated since mga1 if i'm not wrong. -- Balcaen John Jabber-id: mik...@jabber.littleboboy.net
Re: [Mageia-dev] Fresh install loops in mkinitrd
On 12/21/2011 03:02 PM, Frank Griffin wrote: In today's cauldron, a fresh install loops in the bootloader stage because something has suddenly decided that it knows when stuff is taking too long. VC3 shows "ERROR: killing runaway process (process=mkinitrd.error=ALARM at /usr/lib/libDrakx/run_program.pm line 92" In the GUI, you get a graphical prompt saying that an error occurred and mkinitrd failed, and if you click OK (the only choice), it goes and tries the mkinitrd again, fails again, . So, basically, the install stops there, as you can't get to Summary. This appears to have cleared itself up.
Re: [Mageia-dev] ANN: X11 now starts on tty1
On 12/20/2011 02:56 AM, P. Christeas wrote: On Saturday 17 December 2011, Colin Guthrie wrote: Back in the day, text logins were the norm, graphical logins came later. Text logins got ttys 1-7... These days they are pretty much useless for 99.5% of the use cases ... I'd like to question that. Col, Could you have a look at https://bugs.mageia.org/show_bug.cgi?id=2600 ? It appears that starting X on tty1 may be causing problems on single-core machines, as something is starting mingetty on tty1 repeatedly. Also, I'm not sure what the desired functionality ended up as here, but in current cauldron even though there are mingetty's started on tty1-tty6, CTRL-ALT-Fn doesn't budge off the X desktop for any value of n.
Re: [Mageia-dev] Conflicts between kde 4.7.90 and laptop-mode-tools
On 12/28/2011 10:24 AM, Balcaen John wrote: Le jeudi 22 décembre 2011 17:02:50 Frank Griffin a écrit : This has been going on for a few days. Not a whisper of a problem on non-laptop systems: [...] laptop-mode-tools is deprecated since mga1 if i'm not wrong. So shouldn't whatever replaced it obsolete it ?
Re: [Mageia-dev] Conflicts between kde 4.7.90 and laptop-mode-tools
Le mercredi 28 décembre 2011 10:34:19 Frank Griffin a écrit : > On 12/28/2011 10:24 AM, Balcaen John wrote: > > Le jeudi 22 décembre 2011 17:02:50 Frank Griffin a écrit : > >> This has been going on for a few days. Not a whisper of a problem on > > > >> non-laptop systems: > > [...] > > laptop-mode-tools is deprecated since mga1 if i'm not wrong. > > So shouldn't whatever replaced it obsolete it ? >From the changelog of pm-utils it's wrote : * Wed May 18 2011 ahmad 1.4.1-3.mga1 + Revision: 99676 - Conflict with laptop-mode-tools, its functionalities overlap pm-utils, and upstream thinks it should conflict http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612710#59 That's why no obsoletes was added. -- Balcaen John Jabber-id: mik...@jabber.littleboboy.net
Re: [Mageia-dev] Adding additional provides to php database modules
Le 19/12/2011 03:02, Thomas Spuhler a écrit : Could you please explain a little more what you are looking for. PHP provides the php-mysql and php-pdo-mysql He wants to add a php-database virtual package, provided by the different php database bindings. The only problem here is that, pdo aside, there is no unified database interface in php. Some applications may have explicit support for some databases, this doesn't mean they have generic support for any database. You're likely to quickly run into applications able to work with mysql, postgresql or sqlite, and those able to work with just mysql or postgresql. In theory, you'll end up with as much virtual package as potential combination. -- BOFH excuse #276: U.S. Postal Service
Re: [Mageia-dev] Conflicts between kde 4.7.90 and laptop-mode-tools
On 12/28/2011 10:48 AM, Balcaen John wrote: Le mercredi 28 décembre 2011 10:34:19 Frank Griffin a écrit : So shouldn't whatever replaced it obsolete it ? > From the changelog of pm-utils it's wrote : * Wed May 18 2011 ahmad 1.4.1-3.mga1 + Revision: 99676 - Conflict with laptop-mode-tools, its functionalities overlap pm-utils, and upstream thinks it should conflict http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612710#59 That's why no obsoletes was added. If I read that bugreport correctly, KDE's use of power management hooks conflicts with pm-utils. What about multiple-desktop installations ? Is the removal of laptop-mode-tools or pm-utils going to be transparent to GNOME or LXDE ? Or are KDE's hooks specific to KDE only ?
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release php-5.3.9-0.RC3.1.mga2
BTW, could anybody tell why the rebuilding of PHP stack is needed for every time php version be changed? If the php lib version is hardcoded in compiled modules, maybe we should add corresponding requires into the produced rpms. 2011/12/20 Thierry Vignaud : > On 20 December 2011 03:08, Mageia Team wrote: >> spuhler 3:5.3.9-0.RC3.1.mga2: >> + Revision: 184708 >> - upgrade to 5.4RC3 >> synched with Mandriva > > You need to rebuild the whole PHP stack now
Re: [Mageia-dev] Conflicts between kde 4.7.90 and laptop-mode-tools
Le mercredi 28 décembre 2011 11:01:39 Frank Griffin a écrit : > On 12/28/2011 10:48 AM, Balcaen John wrote: > > Le mercredi 28 décembre 2011 10:34:19 Frank Griffin a écrit : > >> So shouldn't whatever replaced it obsolete it ? > >> > > > From the changelog of pm-utils it's wrote : > > * Wed May 18 2011 ahmad 1.4.1-3.mga1 > > + Revision: 99676 > > - Conflict with laptop-mode-tools, its functionalities overlap pm-utils, > > and> > >upstream thinks it should conflict > >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612710#59 > > > > That's why no obsoletes was added. > > If I read that bugreport correctly, KDE's use of power management hooks > conflicts with pm-utils. no. kde use pm-utils. pm-utils conflicts with laptop-mode-tools. -- Balcaen John Jabber-id: mik...@jabber.littleboboy.net
Re: [Mageia-dev] Fwd: Re: [Cooker] System can stall under heavy IOs with slow storage devices
Am 20.12.2011 01:48, schrieb Frank Griffin: > Florian reads both lists, so I'm pretty sure this would have been mentioned > somewhere in Mageia-land, but I want to add that I have experienced extreme > delays in firefox and other apps when I run largely IO-intensive apps with > large file buffersizes, and the workaround in this comment fixes this > completely. We should consider this for our kernels if we haven't already. Check https://bugs.mageia.org/show_bug.cgi?id=3825#c0 Update candidate currently going through validation ... ;) Also posted in the forums: https://forums.mageia.org/en/viewtopic.php?p=11691#p11691 > > Original Message > Subject: Re: [Cooker] System can stall under heavy IOs with slow storage > devices > Date: Mon, 19 Dec 2011 19:36:02 +0100 > From: Florian Hubold > Reply-To: coo...@mandrivalinux.org > To: coo...@mandrivalinux.org > > > > Am 19.12.2011 10:26, schrieb Franck Bui: > > Hello, > > > > I've noticed a regression on my system which can stall some applications > > (most notably firefox) during very very long time (> 10 mins). > Man, you're my hero, trying to find out what causes this since some months > now. > At least two thumbs up! :) > > It's apparently related to transparent huge pages and I found that it > > had already been described by LWN here a month ago: > > http://lwn.net/Articles/467328/. > > > > Unlike what it's stated in the article, the regression is not really > > hard to trigger in my case: just plug a USB stick, copy on it a big > > file, then try to use firefox... > > > > To fix this, simply try to disable THP: > > > > echo madvise >/sys/kernel/mm//transparent_hugepage/enabled > > > > and firefox should work as expected now. > > > > So, if no one objects, the plan is to simply default the THP stuff to > > "madvise" for desktop flavour where an application has to ask > > explicitly huge page otherwise it will be disabled. > > > >
Re: [Mageia-dev] Conflicts between kde 4.7.90 and laptop-mode-tools
On 12/28/2011 11:05 AM, Balcaen John wrote: Le mercredi 28 décembre 2011 11:01:39 Frank Griffin a écrit : If I read that bugreport correctly, KDE's use of power management hooks conflicts with pm-utils. no. kde use pm-utils. pm-utils conflicts with laptop-mode-tools. OK, sorry, the "upstream" maintainer didn't actually make it clear as to which "upstream" he was :) But the question still stands in modified form: is anything else on a Mageia system using laptop-mode-tools, or has everything moved to pm-utils ? If I rip out laptop-mode-tools to avoid blocking the KDE packages, what happens to non-KDE stuff ?
Re: [Mageia-dev] Conflicts between kde 4.7.90 and laptop-mode-tools
Le mercredi 28 décembre 2011 11:34:08 Frank Griffin a écrit : [...] > But the question still stands in modified form: is anything else on a > Mageia system using laptop-mode-tools, or has everything moved to > pm-utils ? If I rip out laptop-mode-tools to avoid blocking the KDE > packages, what happens to non-KDE stuff ? I would say nothing since i doubt that ahmad would add a conflicts just for that. Also if it was stricly requires (like it is for kde) i guess a urpme laptop- mode-tools should answer the question. -- Balcaen John Jabber-id: mik...@jabber.littleboboy.net
Re: [Mageia-dev] Conflicts between kde 4.7.90 and laptop-mode-tools
Le mercredi 28 décembre 2011 13:36:49 Balcaen John a écrit : > Le mercredi 28 décembre 2011 11:34:08 Frank Griffin a écrit : > [...] > > > But the question still stands in modified form: is anything else on a > > Mageia system using laptop-mode-tools, or has everything moved to > > pm-utils ? If I rip out laptop-mode-tools to avoid blocking the KDE > > packages, what happens to non-KDE stuff ? > > I would say nothing since i doubt that ahmad would add a conflicts just for > that. > Also if it was stricly requires (like it is for kde) i guess a urpme laptop- > mode-tools should answer the question. On the laptop-mode mailing list, the problem arises too cf : http://mailman.samwel.tk/pipermail/laptop-mode/2010-May/000262.html So in fact it's conflicting with some functionnality provides by gnome- powermanager at least. Regards, -- Balcaen John Jabber-id: mik...@jabber.littleboboy.net
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release systemd-37-15.mga2
On Mon, Dec 19, 2011 at 11:27 AM, Colin Guthrie wrote: > 'Twas brillig, and Thierry Vignaud at 19/12/11 10:18 did gyre and gimble: >> On 15 December 2011 12:02, Mageia Team wrote: >>> colin 37-15.mga2: >>> + Revision: 182053 >>> - Do not start getty on tty1, it's used for X11 now (mga#3430) >> >> BTW systemd-sysvinit bloats again minimal installation by requiring python >> because of systemd-sysv-convert, that doesn't seem used. >> Please move it into systemd-tools in order to debloat minimal install > > ACK > > To be honest, I think Lennart really didn't like that utility... it was > only included in Fedora due to politics I think, so we should likely > just drop it. so let's remove it completly :) do you have time for this ? ( and in iptables too )
Re: [Mageia-dev] Conflicts between kde 4.7.90 and laptop-mode-tools
On 12/28/2011 11:36 AM, Balcaen John wrote: Le mercredi 28 décembre 2011 11:34:08 Frank Griffin a écrit : [...] But the question still stands in modified form: is anything else on a Mageia system using laptop-mode-tools, or has everything moved to pm-utils ? If I rip out laptop-mode-tools to avoid blocking the KDE packages, what happens to non-KDE stuff ? I would say nothing since i doubt that ahmad would add a conflicts just for that. Also if it was stricly requires (like it is for kde) i guess a urpme laptop- mode-tools should answer the question. urpme removes laptop-mode-tools without a whimper. So we should probably do the same.
Re: [Mageia-dev] Improving Boxes experience on Mageia
Am 23.12.2011 00:06, schrieb Olav Vitters: > >From https://plus.google.com/109973678654056732542/posts/drB3U65Hptt: Link is broken, seems there are no direct links to comments yet, should be: https://plus.google.com/109973678654056732542/posts/drB3U65Hptt ;) > "Yeah, thats what I meant by 'unknown media' in my previous blog entry. > To make Boxes support your favourite distro as nicely as Fedora and > Windows, you need to: > > 1. Put metadata about it in libosinfo's default DB (its simple and > intuitive XML files) with information about its latest media. > > 2. Add unattended installation for it in Boxes. This will need some > hacking but its not as difficult at one might imagine. :)" > > > Anyone willing to ensure Boxes works nicely with Mageia by submitting a > libosinfo XML file (upstream!) + ensure the unattended installation > works by hacking Boxes? > > Bit swamped myself... >
Re: [Mageia-dev] Conflicts between kde 4.7.90 and laptop-mode-tools
On 12/28/2011 11:40 AM, Balcaen John wrote: On the laptop-mode mailing list, the problem arises too cf : http://mailman.samwel.tk/pipermail/laptop-mode/2010-May/000262.html So in fact it's conflicting with some functionnality provides by gnome- powermanager at least. Regards, Well, I suppose there's nothing we can do about it, but urpmq/rpm -q indicates that laptop-mode-tools provides nothing and nobody else seems to require laptop-mode-tools. But the link you gave suggests that the DE packages are only doing *some* of what laptop-mode-tools does, as the author says that they will conflict on the individual settings that other packages control, but that he doesn't know who else is trying to control what.
Re: [Mageia-dev] ANN: X11 now starts on tty1
On 12/28/2011 10:31 AM, Frank Griffin wrote: Col, Could you have a look at https://bugs.mageia.org/show_bug.cgi?id=2600 ? It appears that starting X on tty1 may be causing problems on single-core machines, as something is starting mingetty on tty1 repeatedly. Also, I'm not sure what the desired functionality ended up as here, but in current cauldron even though there are mingetty's started on tty1-tty6, CTRL-ALT-Fn doesn't budge off the X desktop for any value of n. No longer critical, the problem went away when I upgraded X to 1.11.2-3 from 1.10.4.
Re: [Mageia-dev] Upgrade to KDE 4.7.95 breaks the desktop
On Wed, Dec 28, 2011 at 10:21 AM, Balcaen John wrote: > Le dimanche 25 décembre 2011 19:40:51 Pierre Jarillon a écrit : >> After updating cauldron, the destop is empty: all icons and plasmoids are >> missing. > Well here « only » the pannel was missing during the upgrade (& not all > plasmoids). Yes, here I only lost my panel, but desktop plasmoids remained. -- Juancho
Re: [Mageia-dev] ANN: X11 now starts on tty1
'Twas brillig, and P. Christeas at 20/12/11 07:56 did gyre and gimble: > On Saturday 17 December 2011, Colin Guthrie wrote: >> Back in the day, text logins were the norm, graphical logins came later. >> Text logins got ttys 1-7... These days they are pretty much useless for >> 99.5% of the use cases ... > > I'd like to question that. > You see, machines still have 'init 3' (or did Fedora remove that, too?), Yup they remove it! Well, technically not, it's just not called "3" any more, it's called "multi-user.target" which is altogether more sensible. > there > is still people wanting a Linux box (not desktop) not to have X. And that's > way more than 0.5% . OK, the text you quoted is somewhat taken out of context. I never suggested removing text logins or not catering for server installs sans X (I use this setup myself). All I'm suggesting is that the first, say six TTYs are reserved for the current target's preferred login system. If you are on multi-user.target (aka runlevel 3) then you 1-6 offer you a text login as before. However if you are on graphical target then 1-6 should offer you graphical logins instead. > Or, X may be broken sometimes. And I proposed that some higher numbers would be reserved for text-only logins - i.e. tty's 8-9 or something. > So, standardization of tty1=text makes sense, is not just an old habit. No, it's an old habit so you are defaulting to it as a solution when there are a myriad of others out there that (IMO) fit better. > Because, you are *always* expecting to find a working tty console on a Linux > box[1], while X only launches a bit later, if it can[2]. Putting the one that > works in the default place is more reasonable, see? I also thing it's reasonable that *something* pops up when X tries to start and fails. Whether this is a getty that allows you to log in or something even more friendly, doesn't really matter. > Really, why don't you patch the kernel to start at tty7? you could call that > "progress", too. IMO, no it's not progress. It's keeping the same conventions for the sake of it rather than evaluating what makes sense with a fresh pair of eyes. The ONLY valid reason I can see for keeping graphics on tty7 is simply that's that's how it was done before. Now this does carry some weight I agree, but when evaluating what makes Linux hard to use for newbies and novices, we sometimes have to through out "quirks" that we are used to for the sake of a more logical approach. > Some things in Linux could improve, but some don't need change. Unix legacy > is > what makes Linux great[3] Citation needed. And your footnote is complete nonsense. Time has not proven it right at all. It's proven that it works, but that doesn't mean it's optimal. I mean time has proven that a bubble sort works. Does that mean we should not look to e.g. quick sort algorithms etc? Of course not. >, IMHO. Part of that legacy (the "old school") is to > have failsafe defaults, is to start with a minimal design and then build the > extras on top. And you are welcome to your view, but you have to admit it's clouded. I try very hard to discard any clouded views I have due to habits. I mean a regular newbie user doesn't consider "graphical UI" to be an "extra that you built on top"... it's the core to them. Anything less and it's not an operating system! > That's why Unix principles (or "hangovers") have survived so > many decades, while other OSs have gone with the wind[4]. A lot of unixisms are good. But some are bad and just didn't have any viable alternative until people pull their finger out and design and develop some stuff to replace it! You cannot say "unix is good" as a broad statement. You have to each component on it's own merits. 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] Improving Boxes experience on Mageia
'Twas brillig, and Olav Vitters at 22/12/11 23:06 did gyre and gimble: >>From https://plus.google.com/109973678654056732542/posts/drB3U65Hptt > > "Yeah, thats what I meant by 'unknown media' in my previous blog entry. > To make Boxes support your favourite distro as nicely as Fedora and > Windows, you need to: > > 1. Put metadata about it in libosinfo's default DB (its simple and > intuitive XML files) with information about its latest media. > > 2. Add unattended installation for it in Boxes. This will need some > hacking but its not as difficult at one might imagine. :)" > > > Anyone willing to ensure Boxes works nicely with Mageia by submitting a > libosinfo XML file (upstream!) + ensure the unattended installation > works by hacking Boxes? > > Bit swamped myself... +1 for making sure this works OOTB for mga2! Zeeshan is a good guy too. If you put a Star Trek reference in your commit it pretty much will guarantee he'll accept it :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] [changelog] [RPM] cauldron core/release php-5.3.9-0.RC3.1.mga2
'Twas brillig, and Funda Wang at 28/12/11 16:01 did gyre and gimble: > BTW, could anybody tell why the rebuilding of PHP stack is needed for > every time php version be changed? If the php lib version is hardcoded > in compiled modules, maybe we should add corresponding requires into > the produced rpms. I've not looked for ages, but IIRC various modules use the php-source package. But yeah, stricter provides should be added if it's not already in there (it could be!) 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] packaging savoir-vivre
Op dinsdag 20 december 2011 01:41:38 schreef Kamil Rytarowski: > Hello! > > What do you think of marking packages on which we (or our apprentices) > are working? > > I've experienced that when we are working on a package - even if it is > noticed on Bugzilla, Mageia-Dev or elsewhere - someone may simply > check-out the package, bump version or make some changes (resolve a > bug), check-in. We know that making changes in a long spec, may take > days or even month (a lot of sources, large installation-tree, patches > to review, consulting upstream etc), and rapid changes can do nothing good. > > Today I talked on it, how to prevent a package from being localized by > someone and simply bumped without asking. > > So what do you think on marking packages that are underdevelopment? > > I think it's good to just simply mark it in the 1st line of a svn-spec: > "# (name) date message", e.g. "# (john) 2011.12.20 please don't touch > this package, I'm working on it right now, it may take a few weeks" or > "# (john) 2011.08.23 don't update the version, it won't match current KDE". > > There is already a list of sensitive packages here > https://wiki.mageia.org/en/Sensitive_packages maybe just it is > sufficient for 10,000 packages distribution? imho the best solution is that everyone checks if there's a maintainer for it and asks maintainer first... i mean, it's all nice that it's in the spec file, but i think people who bump, rarely look inside spec file... (not saying any names) if something has got to be checked, maintainership is a good place to start if we would have some kind of page which would list the activeness of maintainers, via gathering info from commits/bugzilla/mailinglist/forum/ stuff, that could be a nice place too. then we could see if this maintainer is actually inactive or not. i would hope this would lessen the amount of people just bumping stuff if they don't maintain it...
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release tomcat-7.0.23-3.mga2
On 28 December 2011 20:54, Mageia Team wrote: > dmorgan 0:7.0.23-3.mga2: > + Revision: 188453 > - Do not use systemd-sysv-convert anymore why not just move it into systemd-tools?
Re: [Mageia-dev] packaging savoir-vivre
On Wed, Dec 28, 2011 at 11:26:22PM +0100, Maarten Vanraes wrote: > imho the best solution is that everyone checks if there's a maintainer for it > and asks maintainer first... > > i mean, it's all nice that it's in the spec file, but i think people who > bump, > rarely look inside spec file... (not saying any names) What about svn lock? That would be pretty hard to ignore. >>> Dan
