[Mageia-dev] Freeze push: rpm-mageia-setup 1.170
Hello, Please, can someone push rpm-mageia-setup 1.170 ? It fixes a regression introduced with 1.168: all the directories found by find-lang are not owned by packages when --with-man is used (mga #3697c10). regards, Luc -- Luc Menut
[Mageia-dev] Freeze push: rpm-mageia-setup 1.168
Hello, Please, can someone push rpm-mageia-setup 1.168 ? Changelog: fix find-lang.pl : do not own man lang directories with --with-man fix from tv http://svnweb.mageia.org/soft?view=revisionrevision=7582 It is needed to fix mga #3697 #9055. regards, Luc -- Luc Menut
Re: [Mageia-dev] bogus packages that provides fonts-ttf-dejavu
Le 13/03/2013 10:25, Colin Guthrie a écrit : [...] Or perhaps, alternatively, whatever is responsible for the automatic font(XX) provides should only look at files in /usr/share/fonts/ and not in any other folders. It's already the case. eg. urpmq -l briquolo |grep ttf /usr/share/doc/briquolo/DejaVuSans.ttf-LICENSE /usr/share/games/briquolo/data/DejaVuSans.ttf urpmq --provides briquolo briquolo[== 0.5.7-6.mga3] briquolo(x86-64)[== 0.5.7-6.mga3] Luc -- Luc Menut
[Mageia-dev] Freeze push: R-base 2.15.3
Hello, Please, can someone push R-base 2.15.3 ? This is intended to be the final round-up release of the 2.15 series, and mainly a bugfix release (28 bugs fixed). http://cran.r-project.org/src/base/NEWS.html regards, Luc -- Luc Menut
[Mageia-dev] Freeze push: skanlite 1.0
Hello, Please, can someone push skanlite 1.0 ? It's a bugfix release. Changelog 1.0 : - Fix save crash when libksane returns an odd number sized buffer in 16 bit mode bko #314108 - Save sequence number across sessions bko #202432 - Add option to set sequence-number. Do not open first image dialog after settings dialog has been canceled. bko #310687 bko #310688 bko #310689 regards, Luc -- Luc Menut
Re: [Mageia-dev] [changelog] [RPM] 2 nonfree/updates_testing php-5.3.22-3.mga2.nonfree
Le 28/02/2013 09:36, oden a écrit : Name: php Relocations: (not relocatable) Version : 5.3.22Vendor: Mageia.Org Release : 3.mga2.nonfreeBuild Date: Thu Feb 28 09:24:14 2013 Install Date: (not installed) Build Host: jonund.mageia.org Group : Development/PHP Source RPM: (none) Size: 15406186 License: PHP License Signature : (none) Packager: oden oden URL : http://www.php.net Summary : The PHP5 scripting language [RPM] 2 nonfree/updates_testing php-5.3.22-3.mga2.nonfree php in nonfree ?? what is non-free in this update ? regards, Luc -- Luc Menut
Re: [Mageia-dev] Freeze push: amarok
Hello, Le 18/01/2013 10:34, fundawang a écrit : Hello, Could amaork 2.7.0 stable be pushed into cauldron? We target at 2.7.x for mga3, and we currently have 2.6 beta version in cauldron. Thanks. ping It would be nice to have amarok 2.7.0 final release in upcoming beta 2; it seems to fix crashes reported in release_blocker #7748 (it fixes crashes for Nikita Krupenko, and myself with a local build of amarok 2.7.0). https://bugs.mageia.org/show_bug.cgi?id=7748 regards, Luc -- Luc Menut
Re: [Mageia-dev] Package Group Selection in Install borked ?
Le 16/01/2013 15:51, Pierre-Malo Deniélou a écrit : On 16/01/13 14:27, Frank Griffin wrote: I seem to remember a bug report go by which had something to do with not offering package groups during Package Selection that aren't actually on the install media, and that Thierry reported it fixed. That may be related to what I'm seeing. I just tried a fresh network install against a local copy of cauldron that was just synced, and when I choose Custom Desktop and get to Package Group Selection, the only groups shown under Workstation are Game Station, Internet Station, Console Tools, Multimedia Statio, Configuration, and Documentation. Under Server, there is only Firewall/Router. Under Graphical Environment, there is only LXDE Desktop and Other Graphical Desktops. Any idea what's goin on ? I don't think the other categories got wrapped into these, because checking them all only gives me a total size of 4864 instead of the usual 8000-9000 value. It is probably linked to the RPM group change. Sorry. not sure, it may be a problem in this change http://svnweb.mageia.org/packages?view=revisionrevision=388363 Luc -- Luc Menut
Re: [Mageia-dev] [packages-commits] [371667] Do not own /etc/skel
Le 13/01/2013 14:34, Sander Lepik a écrit : 13.01.2013 15:23, Luc Menut kirjutas: Hi Le 13/01/2013 13:00, r...@mageia.org a écrit : Revision 371667 Author sander85 Date 2013-01-13 13:00:46 +0100 (Sun, 13 Jan 2013) Log Message Do not own /etc/skel Modified Paths * cauldron/etcskel/current/SPECS/etcskel.spec #cauldronetcskelcurrentSPECSetcskelspec Modified: cauldron/etcskel/current/SPECS/etcskel.spec === --- cauldron/etcskel/current/SPECS/etcskel.spec2013-01-13 12:00:39 UTC (rev 371666) +++ cauldron/etcskel/current/SPECS/etcskel.spec2013-01-13 12:00:46 UTC (rev 371667) @@ -24,4 +24,4 @@ %files %doc ChangeLog -%config(noreplace) /etc/skel +%config(noreplace) /etc/skel/* Please, could you explain the raison of this change. /etc/skel is now owned by no package: urpmf ^/etc/skel$ http://pkgsubmit.mageia.org/uploads/rejected/cauldron/core/release/2013093211.umeabot.valstar.1917.youri Thanks Sander. Then, either we should add a rpmlint exception for etcskel, either we should fix filesystem. urpmq -l etcskel /etc/skel/tmp /usr/share/doc/etcskel /usr/share/doc/etcskel/ChangeLog urpmq --whatrequires etcskel basesystem-minimal etcskel urpmq --requires etcskel bash I don't understand why etcskel requires bash. As etcskel only owned /etc/skel and /etc/skel/tmp, if we move /etc/skel to filesystem, it does not make sense to keep etcskel rpm, and we should move /etc/skel/tmp too, and drop etcskel package. regards, Luc -- Luc Menut
Re: [Mageia-dev] /usr/bin/file broken on cauldron
Le 10/01/2013 18:20, David Walser a écrit : Pascal Terjanpterjan@... writes: On Thu, Jan 10, 2013 at 3:51 PM, Pascal Terjanpterjan@... wrote: This is fixed in git but I couldn't find the specific commit The fix is https://github.com/glensc/file/commit/834831f53398cf2a1cfcd1daaf88c437bbf8d21f Fixed in file-5.12-6.mga3, but this is a bit more interesting... If you actually look at that commit, you see: -# $File: assembler,v 1.1 2011/12/08 12:12:46 rrt Exp $ +# $File: assembler,v 1.2 2012/10/31 18:41:42 christos Exp $ But the file in the tarball already reflects the v 1.2 christos (who is the one who made this commit), while the rest of the contents of that file reflect the previous version, aka the rest of that commit isn't applied in the tarball. Anyway, I verified that fixing this fixes the detection for /usr/bin/automake. Thanks to all for the fix. I confirm that file-5.12-6 fixes the problem. After some quick tries, it seems that file 5.12 gives now the same results as file 5.11. regards, Luc -- Luc Menut
[Mageia-dev] libreoffice 4.0.0.0-0.beta2 : Missing signature
Hi, Trying to install libreoffice 4 beta 2, I have: The following packages have bad signatures: /var/cache/urpmi/rpms/libreoffice-calc-4.0.0.0-0.beta2.mga3.x86_64.rpm: Missing signature (OK ((none))) /var/cache/urpmi/rpms/libreoffice-core-4.0.0.0-0.beta2.mga3.x86_64.rpm: Missing signature (OK ((none))) /var/cache/urpmi/rpms/libreoffice-draw-4.0.0.0-0.beta2.mga3.x86_64.rpm: Missing signature (OK ((none))) /var/cache/urpmi/rpms/libreoffice-emailmerge-4.0.0.0-0.beta2.mga3.x86_64.rpm: Missing signature (OK ((none))) /var/cache/urpmi/rpms/libreoffice-graphicfilter-4.0.0.0-0.beta2.mga3.x86_64.rpm: Missing signature (OK ((none))) /var/cache/urpmi/rpms/libreoffice-impress-4.0.0.0-0.beta2.mga3.x86_64.rpm: Missing signature (OK ((none))) /var/cache/urpmi/rpms/libreoffice-kde-4.0.0.0-0.beta2.mga3.x86_64.rpm: Missing signature (OK ((none))) /var/cache/urpmi/rpms/libreoffice-langpack-fr-4.0.0.0-0.beta2.mga3.x86_64.rpm: Missing signature (OK ((none))) /var/cache/urpmi/rpms/libreoffice-math-4.0.0.0-0.beta2.mga3.x86_64.rpm: Missing signature (OK ((none))) /var/cache/urpmi/rpms/libreoffice-ogltrans-4.0.0.0-0.beta2.mga3.x86_64.rpm: Missing signature (OK ((none))) /var/cache/urpmi/rpms/libreoffice-opensymbol-fonts-4.0.0.0-0.beta2.mga3.noarch.rpm: Missing signature (OK ((none))) /var/cache/urpmi/rpms/libreoffice-pdfimport-4.0.0.0-0.beta2.mga3.x86_64.rpm: Missing signature (OK ((none))) /var/cache/urpmi/rpms/libreoffice-presentation-minimizer-4.0.0.0-0.beta2.mga3.x86_64.rpm: Missing signature (OK ((none))) /var/cache/urpmi/rpms/libreoffice-pyuno-4.0.0.0-0.beta2.mga3.x86_64.rpm: Missing signature (OK ((none))) /var/cache/urpmi/rpms/libreoffice-ure-4.0.0.0-0.beta2.mga3.x86_64.rpm: Missing signature (OK ((none))) /var/cache/urpmi/rpms/libreoffice-writer-4.0.0.0-0.beta2.mga3.x86_64.rpm: Missing signature (OK ((none))) /var/cache/urpmi/rpms/libreoffice-xsltfilter-4.0.0.0-0.beta2.mga3.x86_64.rpm: Missing signature (OK ((none))) Do you want to continue installation ? (y/N) regards, Luc -- Luc Menut
Re: [Mageia-dev] /usr/bin/file broken on cauldron
Hi, Le 09/01/2013 22:57, Olivier Blin a écrit : Luc Menutlme...@free.fr writes: Hi all, /usr/bin/file is broken on cauldron (file-5.12-4.mga3). It gives weird bogus results (i586 and x86_64), and breaks some builds. eg. file /usr/bin/xdg* /usr/bin/xdg-desktop-icon: , 28265 /usr/bin/xdg-desktop-menu: , 28265 /usr/bin/xdg-email:, 28265 /usr/bin/xdg-icon-resource:, 28265 /usr/bin/xdg_menu: assembler source text /usr/bin/xdg-mime: , 28265 /usr/bin/xdg-open: , 28265 /usr/bin/xdg-screensaver: , 28265 /usr/bin/xdg-settings: , 28265 /usr/bin/xdg-user-dir: , 28265 /usr/bin/xdg-user-dirs-gtk-update: ELF 64-bit LSB executable, ... /usr/bin/xdg-user-dirs-update: ELF 64-bit LSB executable, ... Hi, Upstream file 5.12 looks quite broken :-/ They updated the 5.12 release tarball (!) on the FTP site with a collection of fixes, that's quite a bad practice... See this thread about your issue: http://mx.gw.com/pipermail/file/2013/001019.html It should be fixed in 5.12-5.mga Thanks Olivier to look at this pb. I've just locally rebuilt file-5.11 and your new file-5.12-5. It's better, but file-5.12-5 still mis-detects some script files; I can see that some Perl or shell scripts are reported as 'assembler source text' with 5.12-5. eg. file -v; file /usr/bin/autoconf /usr/bin/automake /usr/bin/iurt file-5.11 magic file from /usr/share/misc/magic /usr/bin/autoconf: POSIX shell script, ASCII text executable /usr/bin/automake: Perl script, ASCII text executable /usr/bin/iurt: Perl script, ISO-8859 text executable, with very long lines file -v; file /usr/bin/autoconf /usr/bin/automake /usr/bin/iurt file-5.12 magic file from /usr/share/misc/magic /usr/bin/autoconf: POSIX shell script, ASCII text executable /usr/bin/automake: assembler source text /usr/bin/iurt: assembler source text It's very annoying because /usr/bin/file is used by find-requires and find-provides, and if we do the mass rebuild with a broken /usr/bin/file, we will build some rpms with incorrect provides and requires. regards, Luc -- Luc Menut
[Mageia-dev] /usr/bin/file broken on cauldron
Hi all, /usr/bin/file is broken on cauldron (file-5.12-4.mga3). It gives weird bogus results (i586 and x86_64), and breaks some builds. eg. file /usr/bin/xdg* /usr/bin/xdg-desktop-icon: , 28265 /usr/bin/xdg-desktop-menu: , 28265 /usr/bin/xdg-email:, 28265 /usr/bin/xdg-icon-resource:, 28265 /usr/bin/xdg_menu: assembler source text /usr/bin/xdg-mime: , 28265 /usr/bin/xdg-open: , 28265 /usr/bin/xdg-screensaver: , 28265 /usr/bin/xdg-settings: , 28265 /usr/bin/xdg-user-dir: , 28265 /usr/bin/xdg-user-dirs-gtk-update: ELF 64-bit LSB executable, ... /usr/bin/xdg-user-dirs-update: ELF 64-bit LSB executable, ... regards, Luc -- Luc Menut
Re: [Mageia-dev] weird dependencies that i've seen
Le 04/01/2013 17:49, AL13N a écrit : [...] 5. hugin requires make [...] 5. hugin directly requires make... why would a gui require a buildtool? yes, it's surprising, but hugin required make to stitch panorama, and it's probably still true. see https://qa.mandriva.com/show_bug.cgi?id=44648 regards, Luc -- Luc Menut
Re: [Mageia-dev] ANN: shadow-utils util-linux with new default paths in testing
Hi, Le 20/11/2012 23:43, Luc Menut a écrit : Hi, Following my proposal to fix and unify default paths after UsrMove http://www.mageia.org/pipermail/mageia-dev/2012-November/019931.html I pushed in cauldron core/updates_testing shadows-utils-4.1.5.1-2 and util-linux-2.22.1-7 using these default paths: PATH=/usr/local/bin:/usr/bin for normal user, PATH=/usr/local/sbin:/usr/sbin:/usr/local/bin:/usr/bin for root. If there isn't any objection, I would push these 2 packages in core/release, so that we can rebuild and fix some bugs before beta1 mini-freeze. These packages are part of the chroot; can I just rebuild shadows-utils util-linux in core/release, and the chroot will be automagically updated with the new packages, or does it need particular action from someone with enough power !! Regards, Luc
Re: [Mageia-dev] Locking screen
Le 23/11/2012 21:07, Anne Wilson a écrit : After today's Cauldron update I find that my screen is locked frequently, requiring my password to unlock it. Since I normally work with two laptops at the same time - Cauldron and M2 - this is a huge nuisance to me. Where can I change that setting? in System Settings Display and Monitor / Screen Locker either increase value of Start automatically after, or uncheck it. Regards, Luc -- Luc Menut
[Mageia-dev] ANN: shadow-utils util-linux with new default paths in testing
Hi, Following my proposal to fix and unify default paths after UsrMove http://www.mageia.org/pipermail/mageia-dev/2012-November/019931.html I pushed in cauldron core/updates_testing shadows-utils-4.1.5.1-2 and util-linux-2.22.1-7 using these default paths: PATH=/usr/local/bin:/usr/bin for normal user, PATH=/usr/local/sbin:/usr/sbin:/usr/local/bin:/usr/bin for root. Please test these new packages. Any comments and suggestions are welcome. Regards, Luc
[Mageia-dev] Firefox and Thunderbird ESR for Mga 3 ?
Le 20/11/2012 15:04, r...@mageia.org a écrit : Revision 319742 Author dmorgan Date 2012-11-20 15:04:27 +0100 (Tue, 20 Nov 2012) Log Message New version 17.0 [...] Modified: cauldron/firefox/current/SOURCES/sha1.lst === --- cauldron/firefox/current/SOURCES/sha1.lst 2012-11-20 14:03:42 UTC (rev 319741) +++ cauldron/firefox/current/SOURCES/sha1.lst 2012-11-20 14:04:27 UTC (rev 319742) @@ -1 +1,2 @@ 0ffe96896583e92561b341330ab09ddc50140dd1 firefox-16.0.2.source.tar.bz2 +4f5f175c1662d67f70e78403607d8eda600efd8b firefox-17.0.source.tar.bz2 Modified: cauldron/firefox/current/SPECS/firefox.spec === --- cauldron/firefox/current/SPECS/firefox.spec 2012-11-20 14:03:42 UTC (rev 319741) +++ cauldron/firefox/current/SPECS/firefox.spec 2012-11-20 14:04:27 UTC (rev 319742) @@ -10,7 +10,7 @@ # Stay on ESR for stable releases and for cauldron before mageia 3. # /!\ Do not update more than FF 17 for mga3. /!\ -%define major 16.0.2 +%define major 17.0 http://www.mozilla.org/en-US/firefox/organizations/faq Shouldn't we move now to the ESR branch for firefox and thunderbird, and use 17.0.x ESR versions in cauldron until mga3 release ? Regards, Luc
Re: [Mageia-dev] default $PATH after UsrMove
Hi,
Le 12/11/2012 12:43, Colin Guthrie a écrit :
'Twas brillig, and Luc Menut at 11/11/12 18:04 did gyre and gimble:
I think that we should drop these dirs from our defaults $PATH, before a
future mass rebuild.
Yeah seems sensible.
Col
OK
Currently, we have the following cases in Mageia:
1) login normaluser
PATH=/bin:/usr/bin
2) /bin/su - normaluser , ssh normaluser
PATH=/usr/local/bin:/bin:/usr/bin
3) login root , /bin/su - root , ssh root
PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin
(there is only one $PATH for root because it is re-defined in
/root/.bashrc from rootfiles).
So, sometimes we have /usr/local/[s]bin in $PATH before %{_bindir} (2),
sometimes after (3), sometimes it is not in $PATH (1).
Is there any justification to these differences? (personally I don't see
any justification to differences between 1. and 2. )
I don't find if there is some specification (POSIX, LSB, ...) about what
should be in a standard default $PATH, and in which order.
I would prefer if we can unify a bit this, and keep only 2 $PATH, one
for normal user and another one for root.
So should we have /usr/local/[s]bin in default paths ?
If yes, should it be before or after %{_[s]bindir} ?
My proposal for unified $PATH would be :
A) normaluser
PATH=/usr/local/bin:/usr/bin
B) root
PATH=/usr/local/sbin:/usr/sbin:/usr/local/bin:/usr/bin
Any comments and suggestions welcome !
Regards,
Luc
--
Luc Menut
[Mageia-dev] default $PATH after UsrMove
Hi, After UsrMove, /bin and /sbin are symlinks to /usr/bin and /usr/sbin. For the moment, the default $PATH in cauldron is still /bin:/usr/bin:... for normal users, and /sbin:/usr/sbin/... for root, so that 'which a-binary' report that all /usr/[s]bin/... binaries are located in /bin or /sbin instead. (some discussions about this on fedora devel mailing list [1]). While it is not optimal to prefer the indirect path via symlink instead of the direct /usr/[s]bin/ path, it can trigger weird bugs difficult to detect, when there is automatic prefix detection based on the location of a binary (either at buildtime or at runtime). eg. bug #7119 is due to an incorrect detection of the X11 prefix at buildtime; it is detected as / instead of /usr, so that systemsettings searchs evdev.xml at /share/X11/xkb/rules/evdev.xml instead of /usr/share/X11/xkb/rules/evdev.xml. It seems to introduce non-optimal path for interpreter program in shebang line for some perl or python scripts [1]. So, we should probably drop /bin and /sbin from all search paths, in shadow-utils (/etc/login.defs), util-linux (/bin/su - doesn't use /etc/login.defs), openssh, ... I think that we should drop these dirs from our defaults $PATH, before a future mass rebuild. WDYT? Regards, Luc [1] from Fedora http://lists.fedoraproject.org/pipermail/devel/2012-February/162720.html http://lists.fedoraproject.org/pipermail/devel/2012-September/171559.html http://lists.fedoraproject.org/pipermail/devel/2012-October/173220.html https://bugzilla.redhat.com/show_bug.cgi?id=797557 [2] on my system, grep #\!/bin/perl /usr/bin/* /usr/bin/aclocal:#!/bin/perl -w /usr/bin/aclocal-1.12:#!/bin/perl -w /usr/bin/aclocal-1.8:#!/bin/perl -w /usr/bin/aclocal-1.9:#!/bin/perl -w /usr/bin/automake:#!/bin/perl -w /usr/bin/automake-1.12:#!/bin/perl -w /usr/bin/automake-1.8:#!/bin/perl -w /usr/bin/automake-1.9:#!/bin/perl -w /usr/bin/c_rehash:#!/bin/perl5 /usr/bin/diffpp:#!/bin/perl /usr/bin/gdialog:#!/bin/perl /usr/bin/sliceprint:#!/bin/perl /usr/bin/xscreensaver-getimage-file:#!/bin/perl5 -w /usr/bin/xscreensaver-getimage-video:#!/bin/perl5 -w /usr/bin/xscreensaver-text:#!/bin/perl5 -w grep #\!/bin/python /usr/bin/* /usr/bin/bzr:#!/bin/python /usr/bin/cheetah:#!/bin/python /usr/bin/cheetah-analyze:#!/bin/python /usr/bin/cheetah-compile:#!/bin/python /usr/bin/django-admin.py:#!/bin/python /usr/bin/easy_install:#!/bin/python /usr/bin/easy_install-2.7:#!/bin/python /usr/bin/mako-render:#!/bin/python /usr/bin/manhole:#!/bin/python /usr/bin/mgarepo:#!/bin/python /usr/bin/ndiff:#!/bin/python /usr/bin/pyhtmlizer:#!/bin/python /usr/bin/tap2deb:#!/bin/python /usr/bin/tap2rpm:#!/bin/python /usr/bin/tapconvert:#!/bin/python /usr/bin/trial:#!/bin/python /usr/bin/twistd:#!/bin/python
Re: [Mageia-dev] Deprecating pm-utils
Le 17/10/2012 00:04, Colin Guthrie a écrit : I've already dropped the requirement from upower and I suspect that kde these days also uses upower for suspend/resume (can someone please test for me? Just remove pm-utils with --nodeps and make sure everything still works is a nice easy test :D) upower 0.9.18 still requires pm-utils for some features: - up_backend_supports_sleep_state (src/linux/up-backend.c line 360) calls /usr/bin/pm-is-supported to determine if suspend or hibernate are available on the system. upower uses this to reply to dbus call on org.freedesktop.UPower.CanSuspend or .CanHibernate. Without pm-utils, org.freedesktop.UPower.CanSuspend or .CanHibernate always return false. At startup, KDE asks org.freedesktop.UPower.CanSuspend and .CanHibernate to know if, respectively, suspend and hibernate are possible on the system. So, without pm-utils installed, suspend and hibernate entries are not available in KDE's menus and applets (it's needed to reboot after the removal of pm-utils). - up_backend_get_powersave_command (src/linux/up-backend.c line 615) calls /usr/sbin/pm-powersave to apply powersave's adjustments. So, we should re-add the Requires pm-utils in upower for now (btw, Fedora still has this requirement). regards, Luc -- Luc Menut
[Mageia-dev] missing signature again
Hello,
Today, I have a package (kiriki-handbook) with missing signature in the
KDE 4.9.1 updates in cauldron. A bug in the bs?
LC_ALL=C urpmi --update --auto-update
[...]
The following package has bad signature:
/var/cache/urpmi/rpms/kiriki-handbook-4.9.1-1.mga3.noarch.rpm: Missing
signature (OK ((none)))
Do you want to continue installation ? (y/N)
looking at cauldron repo., there are 2 packages with missing signature:
rpm -qp --queryformat '[%{NAME}-%{VERSION}\t%{RSAHEADER}\n]' *.rpm |grep
(none)
kiriki-handbook-4.9.1 (none)
perl-File-FnMatch-0.20.0(none)
regards,
Luc
--
Luc Menut
Re: [Mageia-dev] DVD isos content
Le 24/04/2012 22:46, Anne Nicolas a écrit : Hi there As you may have seen, we have some room left on DVD isos. Please answer this mail if you have some proposals for apps to be added (about 500Mo left) and why we should add it in iso. Cheers I would add cronie-anacron. It is suggested by cronie (cronie is installed by default) and was on the mageia 1 DVD. regards, Luc
[Mageia-dev] Freeze push: task-kde4
Hello, Please, could you push task-kde4? It contains the following changes: - bump version to 4.8.2 (kde version for mga2), - fix the list of packages suggested by task-kde4-handbooks to fit the content of Mga 2 KDE4 LiveCDs (task-kde4-handbooks is not present on LiveCDs or DVDs, so this change will have no effect on media contents). regards, Luc -- Luc Menut
Re: [Mageia-dev] RFT: x11-driver-video-intel-2.19.0-1.mga2
Le 02/05/2012 12:00, Thomas Backlund a écrit : Hi, [...] So, I'd like everyone that can and have Intel graphics to test: x11-driver-video-intel-2.19.0-1.mga2 that is available in Core Updates Testing. And report in this thread success/failure. Trying it here on 2 systems with Intel integrated graphics chipset: - laptop: Intel(R) GM45 - desktop: Intel(R) Sandybridge Desktop (GT1) No issue so far. Luc
Re: [Mageia-dev] Freeze push: pdfshuffler
Le 01/05/2012 18:05, Luc Menut a écrit : Hello, Please, could you push pdfshuffler 0.6.0 ? We are currently providing a 0.6.0 pre-release (svn rev 75 tarball), waiting this final 0.6.0 release. Thanks, Luc ping ? -- Luc Menut
[Mageia-dev] Calligra 2.4.? in Mga 2
Hi, Currently, we have Calligra 2.4.0 in cauldron, while we already have Calligra 2.4.1 in Mga 1 updates_testing. What is the plan for Mga 2, update Calligra to 2.4.1 or stay with Calligra 2.4.0 ? If we stay with Calligra 2.4.0 for Mga 2 final release, Calligra 2.4.1 shouldn't be validated and pushed in Mga 1 updates before the same update to Calligra 2.4.1 in Mga 2. regards, Luc -- Luc Menut
[Mageia-dev] Freeze push: pdfshuffler
Hello, Please, could you push pdfshuffler 0.6.0 ? We are currently providing a 0.6.0 pre-release (svn rev 75 tarball), waiting this final 0.6.0 release. Thanks, Luc -- Luc Menut
Re: [Mageia-dev] Mageia 2 LiveCD contents...
Le 29/04/2012 20:47, Thomas Backlund a écrit : Hi, So RC (and final) are getting closer, as usual the livecds are problematic to get nice contents, while staying within the 700M limit Current RC build got me this: 668MMageia-2-rc-LiveCD-GNOME-Africa-India-i586-CD.iso 693MMageia-2-rc-LiveCD-GNOME-Africa-India-x86_64-CD.iso 703MMageia-2-rc-LiveCD-GNOME-Asia-Noindia-i586-CD.iso 728MMageia-2-rc-LiveCD-GNOME-Asia-Noindia-x86_64-CD.iso 684MMageia-2-rc-LiveCD-GNOME-Europe1-Americas-i586-CD.iso 709MMageia-2-rc-LiveCD-GNOME-Europe1-Americas-x86_64-CD.iso 697MMageia-2-rc-LiveCD-GNOME-Europe2-i586-CD.iso 722MMageia-2-rc-LiveCD-GNOME-Europe2-x86_64-CD.iso 662MMageia-2-rc-LiveCD-KDE4-Africa-India-i586-CD.iso 686MMageia-2-rc-LiveCD-KDE4-Africa-India-x86_64-CD.iso 710MMageia-2-rc-LiveCD-KDE4-Asia-Noindia-i586-CD.iso 734MMageia-2-rc-LiveCD-KDE4-Asia-Noindia-x86_64-CD.iso 690MMageia-2-rc-LiveCD-KDE4-Europe1-Americas-i586-CD.iso 714MMageia-2-rc-LiveCD-KDE4-Europe1-Americas-x86_64-CD.iso 720MMageia-2-rc-LiveCD-KDE4-Europe2-i586-CD.iso 744MMageia-2-rc-LiveCD-KDE4-Europe2-x86_64-CD.iso So atleast every cd with size 700M need to loose some stuff... So please help out with suggestions... I have a quick look at Mageia-2-rc-LiveCD-KDE4-Europe1-Americas-x86_64-CD.iso, and I compared its content with the DVD x86_64 content. This liveCD contains some packages that are even not in the DVD iso!!, e.g. plasma-applet-system-monitor-cpu plasma-applet-system-monitor-hdd plasma-applet-system-monitor-hwinfo plasma-applet-system-monitor-net plasma-applet-system-monitor-temperature These plasma-applet packages are only suggested (by kdebase4-workspace), but they are never required (and not in rpmsrate-raw). urpmq --whatrequires plasma-applet-system-monitor-cpu plasma-applet-system-monitor-cpu Does the liveCD are built using suggests? As the DVD isos don't include suggests, it would be consistent to build liveCD without using suggests. It is weird to have more stuff on the liveCD than on the DVD!! regards, Luc -- Luc Menut
Re: [Mageia-dev] [packages-commits] [231233] - drop debian-style initscript
Le 17/04/2012 19:40, r...@mageia.org a écrit : Revision 231233 Author guillomovitch Date 2012-04-17 19:40:18 +0200 (Tue, 17 Apr 2012) Log Message - drop debian-style initscript Isn't it the sysvinit init script ? IIRC, in mga2 we use systemd by default, but we still support sysvinit. regards, Luc -- Luc Menut
[Mageia-dev] Freeze push: pdfshuffler
Hello, Could you please push pdfshuffler 0.6.0 ? This release fixes pdf pages rendering (mga bug #5415), using Cairo based rendering, instead of the deprecated pixbuf rendering (dropped). Thanks, Luc -- Luc Menut
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release meta-task-2-36.mga2
Le 06/04/2012 10:06, Thierry Vignaud a écrit : On 6 April 2012 00:27, lmenutbuildsystem-dae...@mageia.org wrote: lmenutlmenut 1:2-36.mga2: + Revision: 228815 - base the kde install on task-kde4-minimal instead of task-kde4 OK - remove meta-packages kdeaccessibility4 kdeedu4 kdegames4 kdesdk4 - cherry pick components to install for non live kde - move kmail in CAT_NETWORKING_MAIL - move akregator in CAT_NETWORKING_NEWS - remove calligra B/c libreoffice is already here? Yes, and iso size constraint. (previously calligra wasn't installed by default) - replace various kde4 handbooks by task-kde4-handbooks-dvd in INSTALL This is wrong IMHO. that only make sure there on the ISOs. This is what I wish. The needed handbooks will be installed by suggests, according to kde's components selected at install time. cf. http://thread.gmane.org/gmane.linux.mageia.user/6342 This is intended for stuff that are not picked by anything else by that the installer would pick according do detected hardware. I even documented this in rpmsrate. This is obviously not the case here. Is there a better solution? regards, Luc -- Luc Menut
Re: [Mageia-dev] KDE configuration file regressions
Le 26/03/2012 02:56, Frank Griffin a écrit : I'm not sure if this is worth a bug report, but the incremental KDE upgrades in cauldron have a bad habit of regressing changes to configurations and preferences. With every major upgrade, the fact that I've disabled the screensaver gets forgotten. Sound volume keeps resetting to 1%. Changes I've made to konsole settings to patch the yet unfixed bug that sets vertical terminal dimensions to the screen maximum get undone. Did you make these changes in ~/.kde4/share/config or in /var/lib/mageia/kde4-profiles/ ... ? -- Luc Menut
Re: [Mageia-dev] KDE requires creep and other minimal installation issues
Le 28/03/2012 18:40, David Walser a écrit : [...] I'm not 100% sure, but I think at least some of the reason all kinds of extra stuff gets pulled in is because Default-kde4-config and mageia-kde4-config-common both have added dependencies on plasma applets (plasma-applet-icontasks and plasma-applet-battery, respectively), kdm requires some config files provided by kde4-config-file, that's mean either Default-kde4-config, vanilla-kde4-config or netbook-kde4-config. urpmq --requires kdm kdebase4-runtime kde4-config-file[= 2] [...] urpmq --whatprovides kde4-config-file vanilla-kde4-config|Default-kde4-config|netbook-kde4-config so, you can use vanilla-kde4-config instead of Default-kde4-config, and you will remove the requires on plasma-applet-icontasks and all its dependencies. As previously said by John and Thierry, logs could help a lot to narrow an eventually wrong requires. btw, on a server, perhaps you could replace kdm by a lighter login manager. regards, Luc -- Luc Menut
Re: [Mageia-dev] [packages-commits] [226393] Migrate grub bootsplash params to new style: 'splash quiet' rather than 'splash=silent' (mga#3430)
Le 25/03/2012 17:45, r...@mageia.org a écrit : Revision 226393 Author colin [...] +%triggerpostun backend -- drakxtools-backend 14.1-2 +if [ -w /boot/grub/menu.lst ]; then + if grep -q splash= /boot/grub/menu.lst; then +echoMigrating kernel commandline bootsplash arguments in grub +sed -i 's/ splash=silent / splash quiet /;s/ splash=silent$/ splash quiet/;s/ splash=verbose / /;s/ splash=verbose$//;' /boot/grub/menu.lst + fi +fi + IIUC this script, you update splash=silent splash=verbose in /boot/grub/menu.lst for all the lines. What happens if we have entries for mga1 or other distros in the same grub menu.lst ? Aren't you going to break all these entries with such update? Personaly, I use the same /boot/grub/menu.lst for mga 1 and cauldron. regards, Luc -- Luc Menut
Re: [Mageia-dev] [packages-commits] [226393] Migrate grub bootsplash params to new style: 'splash quiet' rather than 'splash=silent' (mga#3430)
Le 25/03/2012 19:08, Colin Guthrie a écrit : 'Twas brillig, and Luc Menut at 25/03/12 17:35 did gyre and gimble: Le 25/03/2012 17:45, r...@mageia.org a écrit : Revision 226393 Author colin [...] +%triggerpostun backend -- drakxtools-backend 14.1-2 +if [ -w /boot/grub/menu.lst ]; then + if grep -q splash= /boot/grub/menu.lst; then +echoMigrating kernel commandline bootsplash arguments in grub +sed -i 's/ splash=silent / splash quiet /;s/ splash=silent$/ splash quiet/;s/ splash=verbose / /;s/ splash=verbose$//;' /boot/grub/menu.lst + fi +fi + IIUC this script, you update splash=silent splash=verbose in /boot/grub/menu.lst for all the lines. What happens if we have entries for mga1 or other distros in the same grub menu.lst ? Aren't you going to break all these entries with such update? Personaly, I use the same /boot/grub/menu.lst for mga 1 and cauldron. Yeah, good point. Any suggestions on how to do this more gracefully? Nope. Is this trigger needed for an upgrade mga1-mga2? or is it only for cauldron update? If it's only for cauldron, I think that it would be safer to drop the trigger. Luc -- Luc Menut
Re: [Mageia-dev] [packages-commits] [226393] Migrate grub bootsplash params to new style: 'splash quiet' rather than 'splash=silent' (mga#3430)
Le 25/03/2012 22:02, Thierry Vignaud a écrit : On 25 March 2012 18:35, Luc Menutlme...@free.fr wrote: Personaly, I use the same /boot/grub/menu.lst for mga 1 and cauldron. That's a very rare usage. Most users won't do that. Those who do should be able to fix the mga1 entry IMHO. using many distros on the same system is not so uncommon. Is the installer chain load grub by default if another distro is already installed on the system? or does it add mga entries on the existing grub config? -- Luc Menut
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release vlc-2.0.0-2.mga2
Le 09/03/2012 05:59, fwang a écrit : Name: vlc Relocations: (not relocatable) Version : 2.0.0 Vendor: Mageia.Org [...] fwangfwang 2.0.0-2.mga2: + Revision: 221926 - requires live for rtsp - rebuild for new live Le 09/03/2012 08:08, fwang a écrit : Name: live Relocations: (not relocatable) Version : 2012.02.29Vendor: Mageia.Org [...] fwangfwang 2012.02.29-2.mga2: + Revision: 221944 - use standard install prefix FYI, mdv (goetz) has a patch to build vlc using live555's initial location. http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/vlc/current/SOURCES/vlc-2.0.0-live555-path.patch?view=markup regards, Luc -- Luc Menut
Re: [Mageia-dev] Minimum install of cauldron don't start console
Le 06/03/2012 14:35, Colin Guthrie a écrit : 'Twas brillig, and Olivier Thauvin at 06/03/12 12:38 did gyre and gimble: No text terminal at all? Not on tty2 or 3? Indeed, alt + F2 show the login prompt. But before I pressed alt + F2 ps was not showing any *getty program, a bit confusing, especially since there is nothing on first console. Just to expand on this point. getty's are started on demand these days. It's done by autovt@.service. If you want to configure static gettys then you can do so easily enough (just symlink /lib/systemd/system/getty*.service as /etc/systemd/systemd/multi-user.target.wants/getty@tty2.service to get a static getty on tty2. But if your system is typically a graphical system, then why bother stating it statically and have it running all the time using resources. Auto-activation seems fine as a default setup to me. Now, the problem you seemed to get was that no dm was installed and thus the /etc/X11/prefdm script reached the end. IMO we very much DO want to have something done at the end of this script to give the user some help. This might include stopping prefdm.service via systemd and starting the tty, or perhaps better, showing some specific help (either text, or via plymouth or similar). This is something that I've suggested in a bug, but no feedback on that idea yet: https://bugs.mageia.org/show_bug.cgi?id=4750 Bug 4750 - Unable to install Mageia beta 1 with raid ahci ??? are you sure it is this one? Luc -- Luc Menut
[Mageia-dev] BS broken ?
Hello, The BS seems broken; I submitted this morning kdebase4-workspace, and the build is still in progress (4 hours after). Same thing with gnuradio-3.5.1-8.mga2 i586 (12 hours). It seems that the BS indefinitely retries to build kdebase4-workspace (on http://pkgsubmit.mageia.org/, the build machine regularly changes). regards, Luc -- Luc Menut
Re: [Mageia-dev] BS broken ?
Le 03/03/2012 14:04, Luc Menut a écrit : Hello, The BS seems broken; I submitted this morning kdebase4-workspace, and the build is still in progress (4 hours after). Same thing with gnuradio-3.5.1-8.mga2 i586 (12 hours). It seems that the BS indefinitely retries to build kdebase4-workspace (on http://pkgsubmit.mageia.org/, the build machine regularly changes). I just tried to build locally kdebase4-workspace in iurt: urpmi fails to install BuildRequires. After 657/764 installed packages: [...] starting installing packages created transaction for installing on / (remove=0, install=0, upgrade=8) error: rpmdb: Lock table is out of available locker entries error: cannot open Basenames index using db4 - Cannot allocate memory (12) error: rpmdb: Lock table is out of available locker entries error: cannot open Group index using db4 - Cannot allocate memory (12) error: rpmdb: Lock table is out of available locker entries error: cannot open Requirename index using db4 - Cannot allocate memory (12) error: rpmdb: Lock table is out of available locker entries error: cannot open Triggername index using db4 - Cannot allocate memory (12) error: rpmdb: Lock table is out of available locker entries error: cannot open Dirnames index using db4 - Cannot allocate memory (12) error: rpmdb: Lock table is out of available locker entries error: cannot open Installtid index using db4 - Cannot allocate memory (12) error: rpmdb: Lock table is out of available locker entries error: cannot open Sigmd5 index using db4 - Cannot allocate memory (12) error: rpmdb: Lock table is out of available locker entries error: cannot open Sha1header index using db4 - Cannot allocate memory (12) [...] ...retrieving done error: rpmdb: Lock table is out of available locker entries error: cannot open Packages index using db4 - Cannot allocate memory (12) error: cannot open Packages database in /var/lib/rpm error: rpmdb: Lock table is out of available locker entries error: cannot open Packages database in /var/lib/rpm error: rpmdb: Lock table is out of available locker entries error: cannot open Packages database in /var/lib/rpm error: rpmdb: Lock table is out of available locker entries error: cannot open Packages database in /var/lib/rpm error: rpmdb: Lock table is out of available locker entries error: cannot open Packages database in /var/lib/rpm error: rpmdb: Lock table is out of available locker entries error: cannot open Packages database in /var/lib/rpm error: rpmdb: Lock table is out of available locker entries error: cannot open Packages database in /var/lib/rpm error: rpmdb: Lock table is out of available locker entries error: cannot open Packages database in /var/lib/rpm error: rpmdb: Lock table is out of available locker entries error: cannot open Packages database in /var/lib/rpm error: rpmdb: Lock table is out of available locker entries error: cannot open Packages database in /var/lib/rpm error: rpmdb: Lock table is out of available locker entries error: cannot open Packages database in /var/lib/rpm error: rpmdb: Lock table is out of available locker entries error: cannot open Packages database in /var/lib/rpm error: rpmdb: Lock table is out of available locker entries error: cannot open Packages database in /var/lib/rpm error: rpmdb: Lock table is out of available locker entries error: cannot open Packages database in /var/lib/rpm error: rpmdb: Lock table is out of available locker entries error: cannot open Packages database in /var/lib/rpm error: rpmdb: Lock table is out of available locker entries error: cannot open Packages database in /var/lib/rpm [...] error: rpmdb: Lock table is out of available locker entries error: cannot open Packages database in /var/lib/rpm unable to open rpmdb I: [iurt_root_command] ERROR: chroot I: [iurt2] [iurt2] --- end of command output --- [...] It seems a pb with rpm. -- Luc Menut
Re: [Mageia-dev] BS broken ?
Le 03/03/2012 14:06, Thomas Backlund a écrit : 03.03.2012 15:04, Luc Menut skrev: Hello, The BS seems broken; I submitted this morning kdebase4-workspace, and the build is still in progress (4 hours after). Same thing with gnuradio-3.5.1-8.mga2 i586 (12 hours). It seems that the BS indefinitely retries to build kdebase4-workspace (on http://pkgsubmit.mageia.org/, the build machine regularly changes). I will kill all builds on both nodes as soon as new glibc is uploaded, and force recreation of all cauldron chroots... OK, you can kill kdebase4-workspace's builds immediately if you want to free build nodes; they won't build with the current chroot. -- Luc Menut
Re: [Mageia-dev] BS broken ?
Le 03/03/2012 14:04, Luc Menut a écrit : Hello, The BS seems broken; I submitted this morning kdebase4-workspace, and the build is still in progress (4 hours after). Same thing with gnuradio-3.5.1-8.mga2 i586 (12 hours). It seems that the BS indefinitely retries to build kdebase4-workspace (on http://pkgsubmit.mageia.org/, the build machine regularly changes). kdebase4-workspace still doesn't build on the BS (it builds fine outside iurt). compiz seems to have the same pb. regards, Luc -- Luc Menut
Re: [Mageia-dev] [packages-commits] [215093] SILENT: Fix install
Le 26/02/2012 10:12, r...@mageia.org a écrit :
Revision
215093
Author
dmorgan
Date
2012-02-26 10:12:36 +0100 (Sun, 26 Feb 2012)
[...]
@@ -75,7 +74,7 @@
Requires(post): nss
Requires(post): rpm-helper
Requires: %{mklibname sqlite3_ 0}= %{sqlite3_version}
-Requires: %{nspr_libname}= 2:%{nspr_version}
+Requires: %{nspr_libname}= %{nspr_version}
I think epoch is needed here.
with lib64nss3-3.13.3-3.mga2
rpm -q --requires lib64nss3
nss
rpm-helper
lib64sqlite3_0 = 3.7.10
lib64nspr4 = 4.9
but lib64nspr4-4.9-3.mga2 provides
rpm -q --provides lib64nspr4
nspr = 2:4.9-3.mga2
mozilla-nspr = 2:4.9-3.mga2
...
lib64nspr4 = 2:4.9-3.mga2
lib64nspr4(x86-64) = 2:4.9-3.mga2
--
Luc Menut
Re: [Mageia-dev] About dm
Le 16/02/2012 17:41, Anne nicolas a écrit : 15:48 ennael quick question about https://bugs.mageia.org/show_bug.cgi?id=4011 c1215:48 ennael at the moment installing xguest pulls kdm 15:49 ennael installing lxde from dvd is just pulling half of kde 15:49 ennael wdyt about blino proposal ? Any feedback on this ? Thanks IIUC the problem comes from xguest, which requires dm. But why xguest should require dm? The xguest account can be used in virtual console, in text mode, even without X11, so I think this require is not needed. If I'm not wrong, xguest is the only package which requires or suggests dm, so that removing this unnecessary requires should fix this problem. btw, each DE should requires its preferred DM. regards, Luc -- Luc Menut
Re: [Mageia-dev] Can't switch to virtual consoles
Le 14/02/2012 19:58, Juan Luis Baptiste a écrit : On Tue, Feb 14, 2012 at 1:39 PM, Thierry Vignaud thierry.vign...@gmail.com wrote: I've seen that occasionally over the years. Definitively not new. I think it's related to bootstraping not being finished. Hard to debug... Can you check if systemd has forked mingetty for the text consoles yet? I'm using sysvinit not systemd. Can you try to comment the line corresponding to tty1 in /etc/inittab? ... # Run gettys in standard runlevels #1:2345:respawn:/sbin/mingetty tty1 2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 4:2345:respawn:/sbin/mingetty tty4 5:2345:respawn:/sbin/mingetty tty5 6:2345:respawn:/sbin/mingetty tty6 ... -- Luc Menut
Re: [Mageia-dev] size of iso dvds
Le 25/01/2012 21:21, Juergen Harms a écrit : I just joined this list - therefore top-posting rather than replying. Seeing the discussion on space on isos, some data about differences between mageia 1 x86_64 DVD and mageia 2a3 x86_64 DVD: mageia 1 : 3730 Mo - 4630 packages mageia 2 : 4139 Mo - 4209 packages some new big packages in mga 2: - *eclipse* -+ 67 packages - +302 Mo + lots of new java packages (ant, maven, ...) - celtx* - + 7 packages - +132 Mo - e, e17_themes -+ 2 packages - +36 Mo - chromium-browser - + 2 packages - +23 Mo some packages bigger than in mga 1: - texlive* - + 95Mo (mga1 306Mo, mga2 401Mo) packages that we will be able to remove in mga2: - myspell* 39Mo (after hunspell migration) some major missing packages in mga2 DVD ISO: - lots of kde packages, - gstreamer0.10-pulse, - kernel-desktop-devel-latest, - kernel-server-devel-latest, - perhaps others :'( regards, Luc -- Luc Menut
Re: [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia
Le 09/01/2012 01:07, Kamil Rytarowski a écrit : W dniu 08.01.2012 22:04, Luc Menut pisze: Le 08/01/2012 21:18, Kamil Rytarowski a écrit : [...] And I'm against some special versioning for directories, we don't really need it. sorry but I don't agree with you here. e.g. in coming days, we will fix firefox (and other mozilla apps) to use hunspell-dictionaries; we will update the link to /usr/lib64/firefox-9.0.1/dictionaries - /usr/share/hunspell and change the requires to hunspell-dictionary. but hunspell-dictionaries old generation (mga1) provide hunspell-dictionary, and install dictionaries only in /usr/share/myspell. Just a technical note: Old Hunspell dictionaries don't provide anything additional. They are just dangling without any special integration with the system, please take a look: http://svnweb.mageia.org/packages/cauldron/hunspell-fr/current/SPECS/hunspell-fr.spec?revision=134361view=markup $ urpmq --provides hunspell-nl hunspell-nl[== 2.00-2.mga1] oops, sorry, my bad, I had in mind that mga1 hunspell dictionaries already provided hunspell-dictionary. so it can work, we will be able to require hunspell-dictionary to ensure that at least one hunspell dictionary new generation is installed. New Hunspell dictionaries obsoleteprovide Myspell packages and come into the Myspell place. They also install dictionaries into the same place as the predecessor - this is why I put it into the place of the old enchant-dictionary=2 place. Gentoo uses common packages for Myspell and Hunspell dictionaries. So this is additional argument to put Hunspell in the place of Myspell. how do you plan to handle that the fixed firefox will absolutly need hunspell-dictionaries new generation, Fix Mozilla packages (in Mga2) to use new generation dictionaries in /usr/share/hunspell and add Requires: hunspell-dictionary and can't work with hunspell-dictionaries old generation ? Is there need for anything needed in addition of just higher versionrelease of every new generation hunspell-dictionary in Mga2, then the one in Mga1? In Mga2 every hunspell-dictionary will be in the new generation version. when we know that a package needs a specific version of a library, we add it in the requires. e.g. rpm -q --requires firefox |grep sqlite\|nspr\|nss lib64sqlite3_0 = 3.7.9 lib64nss3 = 2:3.13.1 lib64nspr4 = 2:4.8.9 by analogy, I think that we should ensure that the needed dictionary's package is installed. PS: the directory /usr/share/hunspell is currently owned by no package cf. urpmf ^/usr/share/hunspell$ the best candidate is probably hunspell. regards, Luc -- Luc Menut
Re: [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia
Le 09/01/2012 13:05, Kamil Rytarowski a écrit : W dniu 08.01.2012 20:01, Anssi Hannula pisze: [...] IMO a better way to handle this would be Provides:mozilla-dictionary Provides:hunspell-dictionary Provides:myspell-dictionary based on which directories are contained in the package, since other packages are generally interested in whether the package provides dictionaries in a specific location. (i.e. a package using dictionaries in /usr/share/hunspell doesn't care if there are some extra dictionaries provided in other directories). I like this idea! Luc what do you think? Maybe we can consider the providing mozilla-dictionary and then even install symlinks into a specific directory like /usr/share/mozilla-dictionary ? Whatever the directory, we will need to modify mozilla packages, so I think that we can|should directly use /usr/share/hunspell. Personnally, I don't see any interest to create a new directory /usr/share/mozilla-dictionary, and to install other links in this directory. But I don't maintain any mozilla packages !!! -- Luc Menut
Re: [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia
Hello,
first, sorry to reply so late, and when you have started to update
hunspell dictionaries packages.
Le 21/12/2011 08:15, Kamil Rytarowski a écrit :
Hello!
[...]
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.
some comments about the policy:
Version:1.0
Release:%mkrel %{upstream_release}.%{rel}
I don't think it will be possible to use Version 1.0 and upstream
version only in the release; most hunspell dictionaries already use
upstream version as version and have a version 1.0.
--
#Mageia values: 1 - aspell, 2 - hunspell, 3 - language specific
Provides: enchant-dictionary = 2
Provides: hunspell-dictionary
Provides: dictionary-%{languagecode}
about the version value of the provides: is the meaning (1 - aspell, 2 -
hunspell, 3 - language specific) really needed? is it currently used?
Because I think that it could be usefull that the versionned provides
indicates the location of the dictionary:
- current enchant-dictionary = 2 - /usr/share/dict/mozilla
- enchant-dictionary from hunspell - enchant-dictionary = 4 -
/usr/share/hunspell and /usr/share/myspell,
- enchant-dictionary from future hunspell without compatibility link in
/usr/share/myspell - enchant-dictionary = 5 - /usr/share/hunspell only,
- ...
(it seems weird for me to use the same enchant-dictionary = 2
versionned provide, both for deprecated myspell dictionaries, and new
hunspell dictionaries.)
if the versionned provides indicates the location, we can use it if
necessary in Conflicts or Requires in others packages.
e.g. currently Firefox searches dictionnaries in /usr/share/dict/mozilla
(myspell dictionaries). when we change this location, we could add a
Requires enchant-dictionary = 4.
same for hunspell-dictionary and dictionary-%{languagecode}, a
versionned provides could indicate the location of the dictionary.
if we want to be able to remove easily all the compatibility link in the
future, we should really consider this.
PS. The changes of enchant will be proposed or accepted later, Funda has
already prepared the package.
new hunspell dictionaries provides enchant-dictionary and obsoletes
myspell dictionaries, but enchant still can't use the new hunspell
dictionaries. I think that it should be fixed ASAP, or we will release
an alpha 3 with broken spelling for lot of languages.
I propose the attached patches for enchant, so that enchant can use
dictionaries from /usr/share/hunspell, /usr/share/myspell, and
/usr/share/dict/ooo.
Anssi, Kamil, WDYT ?
same problem with firefox and thunderbird, they use dictionaries from
/usr/share/dict/mozilla = myspell dictionaries, that are obsoleted.
(Will we wait for the complete migration, to release alpha 3 ? )
CC: Anssi, enchant and thunderbird maintainer
dmorgan, firefox maintainer
regards,
Luc
--
Luc Menut
diff -Naur enchant-1.6.0.orig/src/myspell/myspell_checker.cpp enchant-1.6.0/src/myspell/myspell_checker.cpp
--- enchant-1.6.0.orig/src/myspell/myspell_checker.cpp 2010-04-01 22:53:37.0 +0200
+++ enchant-1.6.0/src/myspell/myspell_checker.cpp 2011-12-19 23:07:37.0 +0100
@@ -276,6 +276,9 @@
dirs = g_slist_append (dirs, g_strdup (ENCHANT_MYSPELL_DICT_DIR));
#endif
+ dirs = g_slist_append (dirs, g_strdup (/usr/share/myspell));
+ dirs = g_slist_append (dirs, g_strdup (/usr/share/dict/ooo));
+
#if defined(_WIN32)
char* open_office_dicts_dir = myspell_checker_get_open_office_dicts_dir ();
if (open_office_dicts_dir)
Index: enchant.spec
===
--- enchant.spec (révision 184618)
+++ enchant.spec (copie de travail)
@@ -10,6 +10,7 @@
Group: System/Libraries
URL: http://www.abisource.com/projects/enchant/
Source0: http://www.abisource.com/downloads/enchant/%{version}/%{name}-%{version}.tar.gz
+Patch0: enchant-1.6.0-add-more-myspell-dicts-dirs.patch
BuildRequires: pkgconfig(glib-2.0) = 2.6
BuildRequires: pkgconfig(gmodule-2.0)
BuildRequires: pkgconfig(hunspell)
@@ -40,12 +41,13 @@
%prep
%setup -q
+%patch0 -p1
%build
%configure2_5x --disable-static \
--with-system-myspell=yes \
--disable-ispell --disable-aspell --disable-uspell --disable-hspell \
- --with-myspell-dir=%{_datadir}/dict/ooo
+ --with-myspell-dir=%{_datadir}/hunspell
%make
%install
Re: [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia
Le 08/01/2012 15:29, Thomas Backlund a écrit : 08.01.2012 16:19, Luc Menut skrev: same problem with firefox and thunderbird, they use dictionaries from /usr/share/dict/mozilla = myspell dictionaries, that are obsoleted. (Will we wait for the complete migration, to release alpha 3 ? ) Nope. Alpha3 iso building is working from a frozen repo OK sorry, thanks Thomas for the clarification. I badly understood the mail of Anne about Mageia 2 alpha 3 in progress. Luc -- Luc Menut
Re: [Mageia-dev] Missing signatures
Le 08/01/2012 12:29, Thomas Backlund a écrit : 08.01.2012 11:08, Jani Välimaa skrev: 2012/1/8 Oliver Burgeroliver@googlemail.com: Hi there, I noticed, that some packages have missing signatures this morning: It's also reported to bugzilla: https://bugs.mageia.org/show_bug.cgi?id=4067 Yep we had a brief hickup in the signing process, wich I fixed some ~6 hours ago. It seems not completely fixed; gedit-3.3.2-1.mga2 built today 08 janv. 2012 at 15:51:09 CET is not signed. rpm -qpi gedit-3.3.2-1.mga2.x86_64.rpm Name: gedit Version : 3.3.2 Release : 1.mga2 Architecture: x86_64 Install Date: (not installed) Group : Editors Size: 12797127 License : GPLv2+ Signature : (none) Source RPM : gedit-3.3.2-1.mga2.src.rpm Build Date : dim. 08 janv. 2012 15:51:09 CET Build Host : jonund Relocations : (not relocatable) Packager: wally wally -- Luc Menut
Re: [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia
Le 08/01/2012 21:18, Kamil Rytarowski a écrit :
W dniu 08.01.2012 15:19, Luc Menut pisze:
Hello,
[...]
if the versionned provides indicates the location, we can use it if
necessary in Conflicts or Requires in others packages.
e.g. currently Firefox searches dictionnaries in
/usr/share/dict/mozilla (myspell dictionaries). when we change this
location, we could add a Requires enchant-dictionary = 4.
same for hunspell-dictionary and dictionary-%{languagecode}, a
versionned provides could indicate the location of the dictionary.
if we want to be able to remove easily all the compatibility link in
the future, we should really consider this.
If a package requires enchant-dictionary, then language specific will be
chosen before Aspell. This is the whole idea behind it. (eg. Voikko is
chosen before hunspell-fi and aspell-fi too).
OK, I understand the use for enchant-dictionary.
And I'm against some
special versioning for directories, we don't really need it.
sorry but I don't agree with you here.
e.g. in coming days, we will fix firefox (and other mozilla apps) to use
hunspell-dictionaries; we will update the link to
/usr/lib64/firefox-9.0.1/dictionaries - /usr/share/hunspell
and change the requires to hunspell-dictionary.
but hunspell-dictionaries old generation (mga1) provide
hunspell-dictionary, and install dictionaries only in /usr/share/myspell.
how do you plan to handle that the fixed firefox will absolutly need
hunspell-dictionaries new generation, and can't work with
hunspell-dictionaries old generation ?
regards,
Luc
--
Luc Menut
Re: [Mageia-dev] [Mageia-Private] Consolidation of the spelling tools in Mageia
Le 08/01/2012 21:18, Kamil Rytarowski a écrit : W dniu 08.01.2012 15:19, Luc Menut pisze: new hunspell dictionaries provides enchant-dictionary and obsoletes myspell dictionaries, but enchant still can't use the new hunspell dictionaries. I think that it should be fixed ASAP, or we will release an alpha 3 with broken spelling for lot of languages. I propose the attached patches for enchant, so that enchant can use dictionaries from /usr/share/hunspell, /usr/share/myspell, and /usr/share/dict/ooo. Anssi, Kamil, WDYT ? Yes feel free to fix it. done - enchant-1.6.0-4.mga2 -- Luc Menut
Re: [Mageia-dev] imported .src.rpm / .spec attribution
Le 07/01/2012 13:23, Florent Monnier a écrit : Hi, In Mandriva I was using this command to make proper attribution of imported .spec files: $ mdvsys import foo.src.rpm --message 'this spec file is imported from Fedora where it was written by X' I'm trying to make the equivalent with this command: $ mgarepo putsrpm -m this spec file is imported from Mandriva where it was written by X package.src.rpm error: no such option: -m $ mgarepo putsrpm --message this spec file is imported from Mandriva where it was written by X package.src.rpm error: no such option: --message $ mgarepo putsrpm --help | grep -- -m -m LOG Log message used when commiting changes What is the right command line to achieve this? Can you try mgarepo putsrpm -l LOG ... ? Could you please file a bugreport? regards, Luc -- Luc Menut
Re: [Mageia-dev] [packages-commits] [193033] Suggests sectools instead of a Requires ( mga # 2808)
Le 08/01/2012 02:01, r...@mageia.org a écrit : Revision 193033 Author dmorgan Date 2012-01-08 02:01:07 +0100 (Sun, 08 Jan 2012) Log Message Suggests sectools instead of a Requires ( mga # 2808) Modified Paths * updates/1/msec/current/SPECS/msec.spec #updates1mseccurrentSPECSmsecspec Modified: updates/1/msec/current/SPECS/msec.spec === --- updates/1/msec/current/SPECS/msec.spec 2012-01-08 00:58:08 UTC (rev 193032) +++ updates/1/msec/current/SPECS/msec.spec 2012-01-08 01:01:07 UTC (rev 193033) @@ -1,4 +1,4 @@ -%definesubrel 5 +%definesubrel 6 Name: msec Version: 0.80.10 @@ -22,7 +22,7 @@ Requires: chkconfig Requires: mailx Requires: python -Requires: sectool +Suggests: sectool # at least xargs is used Requires: findutils # ensure sysctl.conf and inittab are present before installing msec wouldn't it be better to split the sectool plugin in a subpackage, cf. https://bugs.mageia.org/show_bug.cgi?id=2255#c68 https://bugs.mageia.org/attachment.cgi?id=1329action=diff Luc -- Luc Menut
[Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement
Hello,
We have recently discussed here about task-obsolete.
http://www.mail-archive.com/mageia-dev@mageia.org/msg09762.html
https://bugs.mageia.org/show_bug.cgi?id=3786
I like the idea.
But I think that we need to inform the user about the package(s) that we
will obsolete and remove on his system (and why: security, ..).
So I tried to use README.*.urpmi to do this.
But I found that currently, urpmi and rpmdrake don't handle very well
optional README.*.urpmi (%ghost); they always display information's
screen, even if the file doesn't exist.
So, I propose here 2 enhancements for README.*.urpmi (POC patch for
urpm/install.pm, and task-obsolete.spec in attachment):
1) add support for optional README.*.urpmi (%ghost in spec):
This will allow to build this README.*.urpmi at install time in %pre,
%post or %trigger only when it's necessary.
One use case from the recent past in my mind:
we have no way to inform users that still use nspluginwrapper + i586
flashplayer on x86_64 (and only them), that this is now deprecated and
they should replace the i586 by the x86_64 flashplayer,
https://bugs.mageia.org/show_bug.cgi?id=2146#c22
https://bugs.mageia.org/show_bug.cgi?id=2146#c25
2) handle README.*.(obsolete|deprecated).urpmi
In order to display informations about the deprecated or obsoleted
package(s), I suggest to handle 2 new kinds of README.*.urpmi:
- README.nameObsoletedPackage.obsolete.urpmi to inform about the
package we obsolete by task-obsolete
e.g. java-1.6.0-sun*, https://bugs.mageia.org/show_bug.cgi?id=3101
- README.nameDeprecatedPackage.deprecated.urpmi to inform about
package that we considere as deprecated, but we have no reason (no
vulnerability, security, ...) to force uninstallation (task-deprecated?).
What do you think ?
--
Luc Menut
Index: urpm/install.pm
===
--- urpm/install.pm (révision 2572)
+++ urpm/install.pm (copie de travail)
@@ -109,11 +109,14 @@
foreach my $file ($pkg-files) {
my ($kind) = $file =~ m!/README([^/]*)\.urpmi$! or next;
+ -r $file or next;
my $valid;
if ($kind eq '') {
$valid = 1;
} elsif ($kind eq '.install' !$pkg-flag_installed) {
$valid = 1;
+ } elsif ($kind =~ /(.*)\.(deprecated|obsolete)$/) {
+ $valid = 1;
} elsif ($kind =~ /(.*)\.(upgrade|update)$/ $pkg-flag_installed) {
if (!$1) {
$valid = 1;
Name: task-obsolete
Version: 1
Release: %mkrel 1
Summary: POC task-obsolete
Group: Development/Other
License: GPL
BuildArch: noarch
Obsoletes: null
Obsoletes: null-dummy
%description
Proof of concept to test task-obsolete and conditionnal messages
with README.*.obsolete.urpmi when obsoleting package.
%prep
%build
%install
install -d -m755 %{buildroot}%{_defaultdocdir}/%{name}
touch %{buildroot}%{_defaultdocdir}/%{name}/README.null.obsolete.urpmi
touch %{buildroot}%{_defaultdocdir}/%{name}/README.null-dummy.obsolete.urpmi
%triggerin -- null
cat %{_defaultdocdir}/%{name}/README.null.obsolete.urpmi EOF
null is installed on this system.
it is an useless package on end user systems.
it will be uninstalled.
EOF
%triggerin -- null-dummy
cat %{_defaultdocdir}/%{name}/README.null-dummy.obsolete.urpmi EOF
null-dummy is installed on this system.
it is an useless package on end user systems.
it will be uninstalled.
EOF
%files
%dir %{_defaultdocdir}/%{name}
%ghost %{_defaultdocdir}/%{name}/README.null.obsolete.urpmi
%ghost %{_defaultdocdir}/%{name}/README.null-dummy.obsolete.urpmi
Re: [Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement
Le 04/01/2012 17:20, Guillaume Rousse a écrit : 1) add support for optional README.*.urpmi (%ghost in spec): This will allow to build this README.*.urpmi at install time in %pre, %post or %trigger only when it's necessary. That will create files on the system unknown from rpm database, and unknown from urpmi too. nope, %ghost files are known from rpm database. rpm -qpl task-obsolete-1-1.mga2.noarch.rpm /usr/share/doc/task-obsolete /usr/share/doc/task-obsolete/README.null-dummy.obsolete.urpmi /usr/share/doc/task-obsolete/README.null.obsolete.urpmi Rather than focusing on shiny automatic display mechanisms, I'd rather work on information content. we can|should do both. [...] Here are a few proposal of mines to make the situation better: - use a unique file name, enforced by convention, rather than references in package description, the same way Debian does with README.debian - display its content only in graphical context: command-line users usually know about this kind of convention to get information themselves - use standardised file content and markup to allow rpmdrake and other graphical tools to achieve the same kind of selection than file splitting today - define some kind of policy of what should be there, and what should not, to achieve minimal consistency I'm not particularly attached at the current system, but I find it works rather well. If we want that users read informations, the information should be relevant in the context (too many informations, kill information); e.g. it's useless (personnaly, I consider it's bad) to display information about install when we update a package, and vice versa (I don't know debian, and if the unique file README.debian allow this). Luc -- Luc Menut
Re: [Mageia-dev] RFC: task-obsolete and README.*.urpmi enhancement
Le 04/01/2012 20:26, Anssi Hannula a écrit :
On 04.01.2012 17:53, Luc Menut wrote:
[...]
1) add support for optional README.*.urpmi (%ghost in spec):
This will allow to build this README.*.urpmi at install time in %pre,
%post or %trigger only when it's necessary.
One use case from the recent past in my mind:
we have no way to inform users that still use nspluginwrapper + i586
flashplayer on x86_64 (and only them), that this is now deprecated and
they should replace the i586 by the x86_64 flashplayer,
https://bugs.mageia.org/show_bug.cgi?id=2146#c22
https://bugs.mageia.org/show_bug.cgi?id=2146#c25
This change seems reasonable.
2) handle README.*.(obsolete|deprecated).urpmi
[...]
I don't understand the need for this one, isn't this just the same as
README.urpmi?
You are right, we don't need this part; each trigger can add its message
in task-obsolete/README.urpmi.
we just need the following patch to handle %ghost README.urpmi :
Index: urpm/install.pm
===
--- urpm/install.pm (revision 2572)
+++ urpm/install.pm (working copy)
@@ -109,6 +109,7 @@
foreach my $file ($pkg-files) {
my ($kind) = $file =~ m!/README([^/]*)\.urpmi$! or next;
+ -r $file or next;
my $valid;
if ($kind eq '') {
$valid = 1;
--
Luc Menut
Re: [Mageia-dev] Upgrade udev 175
Le 18/12/2011 11:33, Colin Guthrie a écrit : 'Twas brillig, and D.Morgan at 18/12/11 10:19 did gyre and gimble: On Sun, Dec 18, 2011 at 12:09 AM, Thierry Vignaud thierry.vign...@gmail.com wrote: And BTW please upload udev-175 in core/updates_testing so that we can test w/o everyone having to locally build newer udev after rediffing patches ok this is something i can do ( as i started to work on 175 ) I don't think it's needed. See the bug mentioned earlier. I've patched drakx-kbd-mouse-x11 and I think we should just push udev and that together straight to core. I've also got udev pkg here, but the changes are simply anyway (just drop one upstream patch and some minor changes to the files list). Col Could you re-enable --enable-udev-acl and restore udev-acl support (dropped at rev. 157461): udev-acl and 70-udev-acl.rules are still needed for sysvinit in mga2. Without 70-udev-acl.rules and udev-acl, /dev/cdrom, /dev/dri/card* ... don't have the proper permissions with sysvinit. (70-udev-acl.rules is safe regarding systemd : TEST==/sys/fs/cgroup/systemd, TAG==uaccess, GOTO=acl_end) thanks, Luc
Re: [Mageia-dev] Upgrade udev 175
Le 18/12/2011 12:14, Luc Menut a écrit : Could you re-enable --enable-udev-acl and restore udev-acl support (dropped at rev. 157461) s/157461/157460
Re: [Mageia-dev] Consolidation of the spelling tools in Mageia
Le 15/12/2011 12:52, Kamil Rytarowski a écrit : Some packages like Firefox were already cleaned. I don't think so; Firefox and Thunderbird still use myspell dictionnaries. /usr/lib64/firefox-8.0.1/dictionaries - ../../../usr/share/dict/mozilla/ /usr/lib64/thunderbird-7.0.1/dictionaries - ../../../usr/share/dict/mozilla/ btw, Firefox and Thunderbird should be fixed to use system hyphenation dictionnaries, instead of their own hyphenation dictionnaries. regards, Luc -- Luc Menut
Re: [Mageia-dev] replace mysql by mariadb ? (was HEADSUP: mariadb available for testing)
Le 30/11/2011 22:34, Maarten Vanraes a écrit : Op dinsdag 29 november 2011 00:21:04 schreef Maarten Vanraes: so please, test mariadb, build stuff against lib64mariadbclient18 , and give opinion to which option to choose: A/B . ok, so : 3 people vote B 0 people vote A 0 people have disagreement == 100% agreed Please, you should first ask on the ML with a proper subject like [RFC] replace mysql by mariadb for mga 2 ? and don't hide this choice/question in a thread where you announce that mariadb is available for testing. And wait at least one week, so that people have time to reply. Do you know some distribution that have done this replacement? I just quickly look at 3 main distributions; - Fedora doesn't seem to have mariadb, - OpenSuse has mariadb, but still builds there packages againt mysql, - Debian doesn't seem to have mariadb. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565308 and this replacement doesn't seem to be so easy as you claim: e.g. http://bugs.kde.org/show_bug.cgi?id=284810 Do you agree to fix all the bugs introduced by the replacement of mysql by mariadb? When this was discussed a first time on this list, Nicolas Vigier proposed to start with mariadb as an alternative: I would start with mariadb as an alternative. Then drop mysql later, if/when it's confirmed that mysql is really dead and we could check that mariadb is a good replacement. https://www.mageia.org/pipermail/mageia-dev/20110408/003919.html I agree with this, and I think that it's still a sensible choice. regards, Luc -- Luc Menut
Re: [Mageia-dev] [WARNING] libpng-1.5.4 landing soon
Le 21/09/2011 04:07, Funda Wang a écrit : Now the migration is almost done here. The left packages are: Won't build due to other reasons: eclipse, glibc, midori, R-base, xemacs I will look at R-base, probably next week-end. regards, -- Luc Menut
Re: [Mageia-dev] [changelog] cauldron core/release basesystem-1-4.mga2
Le 13/09/2011 17:45, Guillaume Rousse a écrit : Le 13/09/2011 21:17, Thierry Vignaud a écrit : On 13 September 2011 21:02, Thomas Backlundt...@mageia.org wrote: - require systemd-sysvinit instead of sysvinit in order to got more testing IMHO this should have been announced/warned on the ml before forcing the change on everyone. I did announced/warned 5 days ago. Just read your archives Isn't it possible to just change the default process used at boot, so as to allow to fallback explicitely to sysinit if needed ? It would probably be better, and IIUC, it would be more in agreement with the consensus we had in July to introduce systemd in a compatible way - option 2 - for Mageia 2. https://www.mageia.org/pipermail/mageia-dev/2011-July/006691.html -- Luc
[Mageia-dev] Thunderbird update for Mga 1
Hi, Thunderbird 3.1.10 in Mga 1 has some vulnerabilities and should be updated. http://www.mozilla.org/security/known-vulnerabilities/thunderbird31.html Unlike Firefox 4, the Thunderbird 3.1.* branch seems still maintained by mozilla; 3.1.12 is planned for 16/08/2011 https://wiki.mozilla.org/Releases/Thunderbird_3.1.12 . So we can stay with the 3.1.* branch, and update Thunderbird to 3.1.11 (the version that we have in cauldron since 21/06), or try to update to the last version 5.0 (we have a request for Thunderbird 5 in bugzilla https://bugs.mageia.org/show_bug.cgi?id=2088). Personnaly, I would prefer that we stay for now with 3.1.11 (and probably 3.1.12) in Mga 1, and that we update to Thunderbird 5 only in cauldron, and test it for some weeks. WDYT? -- Luc Menut
Re: [Mageia-dev] Updates and 0 release
Le 26/07/2011 12:40, Michael Scherer a écrit : Hi, while trying to work on the queue of update needing a push, I noticed that almost all of them use a Release: 0. Since this has a specific meaning ( ie, used for pre release, or svn snapshot ), using this for updates is quite confusing, and I do not see the reason for that. When it is used for prerelease (mainly in cauldron), the release 0 is usually associated with a svn or git rev. number, or date, or alpha, beta ... so it is not so much confusing with this use in update for official release. If the goal is to be sure that the software is still upgradable, the whole %mkrel stuff should take care of that. And if not, we can rebuild in cauldron to increase the release. We regularly used release 0 and subrel 1 in Mdv for the packages updated with the same version in official releases and in cooker (firefox, thunderbird, java-1.6.0-sun, ...), to be sure that the package from the official release will be updated by a update to the devel release or the next official release. we often used in such packages: %if %mandriva_branch == Cooker # Cooker %define release %mkrel 1 %else # Old distros %define subrel 1 %define release %mkrel 0 %endif regards, Luc
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
Le 13/07/2011 12:41, Ahmad Samir a écrit :
On 13 July 2011 12:34, nicolas vigierbo...@mars-attacks.org wrote:
On Wed, 13 Jul 2011, Ahmad Samir wrote:
...
Using pkgconfig provides looks like an optimal option, we could start
now, whenever we touch a spec we change to the pkgconfig provides, and
gradually all the specs will be adapted.
And for the packages that don't have .pc files we add:
Provides: %{name}-devel = %{version}-release
Provides: lib%{name}-devel = %{version}-release
or we could add them to all packages whether they have .pc files or
not, but still always use pkgconfig() provides as BR in our specs.
I think it's better to use %{name}-devel for packages which don't have
pkgconfig files. And keep pkgconfig() provides for packages with .pc
files.
As spturtle said, conformity/consistency is good, i.e. all our
packages should have the same Provides, that's better in the long run,
and less confusing for new (and old too) packagers.
Couldn't we have a macro for this? It would help in consistency, and
will avoid typo.
We could use it like this:
%mkdevelprov %{name} %{version}
regards,
Luc
Re: [Mageia-dev] Firefox 5
Le 23/06/2011 07:58, Dexter Morgan a écrit : On Thu, Jun 23, 2011 at 7:29 AM, Thierry Vignaud thierry.vign...@gmail.com wrote: On 22 June 2011 19:41, Florian Hubolddoktor5...@arcor.de wrote: Well, it's quite possible that we have to include that in Mageia 1 as well, as this will be security update for Firefox 4. If we don't want to patch every CVE then we have to include it into Mageia 1 as well.. ... But i think sec team need to speak of FF5 first because i think this will be a candidate for updates regarding new firefox upstream policy Yes, I think Firefox 5 should be an updates. Firefox 5 is a security update for Firefox 4 and 4.0.1. There will be no Firefox 4.0.2. http://www.mozilla.org/security/known-vulnerabilities/ (Firefox 4 and newer) http://www.mozilla.org/security/known-vulnerabilities/firefox.html http://blogzinet.free.fr/blog/index.php?post/2011/06/21/Mozilla-Firefox-5 (sorry, in french)
Re: [Mageia-dev] Last submits in progress
Hi, Le 26/05/2011 11:18, Anne nicolas a écrit : Hi there As you may see it in pkgsubmit interface, we are submitting very last packages. Main reasons: - fix last glitches - finalize design integration - help to reduce live CDs size Thanks for your patience :) do you plan a new rebuild of desktop-common-data? just in case this is a forget, you have changed register.desktop URL (https://identity.mageia.org/ - http://mageia.org/contribute) in svn /soft/desktop-common-data, but not pushed the new version in /package/desktop-common-data http://svnweb.mageia.org/soft/desktop-common-data/trunk/desktop/default/register.desktop.in?r1=1441r2=1440pathrev=1441 thanks for your hard work, Luc
Re: [Mageia-dev] [RPM] cauldron core/release pm-utils-1.4.1-3.mga1
Le 18/05/2011 21:44, Mageia Team a écrit : Name: pm-utils Relocations: (not relocatable) Version : 1.4.1 Vendor: Mageia.Org Release : 3.mga1Build Date: Wed May 18 21:41:17 2011 Install Date: (not installed) Build Host: ecosse Group : System/Kernel and hardwareSource RPM: (none) Size: 259042 License: GPL Signature : (none) Packager: Mageia Teamhttp://www.mageia.org URL : http://pm-utils.freedesktop.org/wiki/ Summary : Power management utilities and scripts Description : The pm-utils package contains utilities and scripts useful for power management. ahmadahmad 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 rpmsrate-raw should probably be updated accordingly; currently, it has (lines 728-729) 5 pm-utils 5 TYPElaptop cpufreq laptop-mode-tools btw, other possible cleanup in rpmsrate-raw line 367 !META_CLASSdesktop 5 META_CLASSdownload || TYPE64bit icedtea-web || TYPE64bit is not needed anymore
[Mageia-dev] about icon Join Mageia Community
Hi, Currently, the desktop's icon Join Mageia Community still directs to htts://identity.mageia.org. It was a good link for testers of pre-release. But I wonder if it isn't a bit harsh for newcomers and average linux users of official release. I would see better a page which explains what is the community, and how users can found informations and help on forums, how reporting bugs on bugzilla, how they can contribute in various ways to the project, ... WDYT? regards, Luc
Re: [Mageia-dev] [RPM] cauldron core/release filesystem-2.1.9-12.mga1
Le 30/03/2011 20:41, Mageia Team a écrit :
Name: filesystem Relocations: (not relocatable)
Version : 2.1.9 Vendor: Mageia.Org
Release : 12.mga1 Build Date: Wed Mar 30 20:39:15 2011
- use '%dir /etc' so that filesystem rpm doesn't own e.g. /etc/skel/ which is
already owned by etcskel
are you sure that all others /etc subdirectories are owned by others
packages?
wouldn't it be better to only remove skel in
mkdir -p
%{buildroot}%{_sysconfdir}/{profile.d,skel,security,ssl,sysconfig,default}
Luc
[Mageia-dev] on demand installation of gstreamer codecs
Hi all, Currently, pk-gstreamer-install is the preferred gst-install-plugins-helper in update-alternatives and prefer.vendor.list. When it try to install a missing codec, I obtain these messages and it doesn't install the needed codec. ... ** Message: PackageKit: structure: gstreamer0.10(decoder-audio/mpeg)(mpegaudioversion=1)(mpegversion=1)(layer=3)()(64bit) ** Message: PackageKit: Did not install codec: Failed to search for provides ... IIRC, in order to install missing gstreamer codec packages, the packagekit backend should have the Whatprovides feature, but the urpmi backend doesn't have this feature yet. http://www.packagekit.org/pk-matrix.html http://gitorious.org/packagekit/packagekit/trees/master/backends/urpmi Is it planned to have whatprovides in the urpmi backend before the release of Mageia 1? or should we revert to use codeina? or another alternative? Luc PS: I've already done part of the work locally, in order to have a functionnal codeina in mageia. If you decide to use codeina, I'll commit the changes.
