Re: [Mageia-dev] Packagers representatives
02.01.2011 16:49, Anne nicolas kirjutas: - poll will happen from 03/01 19h (Paris time) to 05/01 21h (Paris time) - all people in wiki list of packagers have been added in voters list and will be able to vote on https://epoll.mageia.org/vote/ISJTLYRT We will give results during packagers meeting on 05/01. Hi, i have added myself to wiki. Nickname sander85. I would like to vote too :) -- Sander
[Mageia-dev] Mageia servers certificates
Hi, i know this problem is probably discussed here before too but is it possible to use StartCom (http://cert.startcom.org) certificates for example. Those are free and supported by most popular browsers. Less problems and new people would have more trust in our servers. What do you think? -- Sander
Re: [Mageia-dev] mysql vs mariadb
08.04.2011 17:22, Ahmad Samir kirjutas: On 8 April 2011 16:20, Oliver Burger oliver@googlemail.com wrote: Thierry Vignaud thierry.vign...@gmail.com schrieb am 08.04.2011 On 8 April 2011 16:05, Ahmad Samir ahmadsamir3...@gmail.com wrote: So I'd like to ask you, what you think, we should do? - package mariadb as an alternative for mysql - package mariadb nd drop mysql or - stay with mysql and not package mariadb at all at least for the time being By the way, if any of my words reads a bi peculiar, the a key on my keyboard isn't working all the time, so try adding an a while you read it :D About option 2, can't be dropped at the moment, as e.g. Amarok requires it. I would expect it to be binary compatible with mysql. According to its website it offers drop-in replacement functionality for MySQL. Oliver What I meant was not to drop mysql until we're sure Amarok builds/works/doesn't-barf with MariaDB. Well.. there is also Drizzle: http://drizzle.org/ -- Sander
Re: [Mageia-dev] Credits for Mageia
25.05.2011 17:05, Anne nicolas kirjutas: - add a general mention to Mandriva contributors about their hard work +1
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
09.06.2011 15:13, Dexter Morgan kirjutas: On Thu, Jun 9, 2011 at 11:54 AM, Colin Guthriemag...@colin.guthr.ie wrote: 'Twas brillig, and Christiaan Welvaart at 09/06/11 10:40 did gyre and gimble: On Thu, 9 Jun 2011, Maarten Vanraes wrote: otoh, perhaps a missing package is also a bugfix... maybe we could file bug reports for missing packages and go through the updates route... Filing bug reports is not a bad idea, even if the new package will go to backports. Just explain a little why it is important (to fix this in a stable release). We probably need a new version in bugzilla because mga1+backports is basically a new distro. A bug in backports shouldn't be filed against 1 IMHO. As I said in my original mail I really don't think backports is the right approach. I'd prefer to have a 3rd party repo than abuse backports to get the missing packages. I think updates would be the right place. Please no 3rd repo :) But i agree with you for updates for new packages ( no new versions ;) ) Indeed it's not good idea to suggest backports for novice users. +1 for updates repo if the new package is just new thing and nothing is going to depend on it or will suggest it before new Mageia release. -- Sander
Re: [Mageia-dev] Perl conflicts
12.06.2011 20:44, Frank Griffin kirjutas: I'm not sure if this is because the perl upgrade in't complete, but just in case it's of use: Installation failed:file /usr/bin/json_pp from install of perl-devel-2:5.14.0-3.mga2.x86_64 conflicts with file from package perl-JSON-PP-2.271.50-1.mga1.noarch file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP.pm conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64 file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Attribute.pm conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64 file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Class.pm conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64 file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Class/Immutable/Trait.pm conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64 file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Deprecated.pm conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64 file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Instance.pm conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64 file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Method.pm conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64 file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Method/Accessor.pm conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64 file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Method/Constructor.pm conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64 file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Method/Generated.pm conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64 file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Method/Inlined.pm conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64 file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Method/Meta.pm conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64 file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Method/Wrapped.pm conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64 file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/MiniTrait.pm conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64 file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Mixin.pm conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64 file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Mixin/AttributeCore.pm conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64 file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Mixin/HasAttributes.pm conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64 file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Mixin/HasMethods.pm conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64 file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Module.pm conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64 file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Object.pm conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64 file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/Class/MOP/Package.pm conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64 file /usr/lib/perl5/vendor_perl/5.14.0/x86_64-linux-thread-multi/metaclass.pm conflicts between attempted installs of perl-Class-MOP-1.120.0-2.mga2.x86_64 and perl-Moose-2.0.0-2.mga2.x86_64 https://bugs.mageia.org/show_bug.cgi?id=1756 -- Sander
Re: [Mageia-dev] Release cycles proposals, and discussion
12.06.2011 23:46, Michael Scherer kirjutas: Proposal 1: 6 months release cycle - 12 months life cycle ( Fedora, Ubuntu, Mandriva 2010.1 Mandriva != 2006.0 ) Proposal 2: 9 months release cycle - 18 months life cycle ( ~ opensuse and the one we used for Mageia 1 ) Proposal 3: 12 months release cycle - 24 months life cycle ( Mandriva 2010.1 ) From those options i would go with the second one. Third is way too much wanted from users (and first has too short life cycle). They are always eager for new stuff and waiting one year ain't option for them. We could also try to have some LTS versions. But in a bit different manner than Ubuntu. Like if we notice that some release is good and stable we could extend its support period (ie mdv2008.1 was really stabel and also mdv2010.1 was pretty good - for me neither had too many problems and i would have keeped 2008.1 for longer but its support ended). One more thing i didn't like with Mageia 1. Official launch date that you know is coming and you see that not all things are ready for prime time but you go anyway as there is launch date announced. Ubuntu has failed with that at least few times. Debian (Mozilla somewhat too) does better job here. They don't release if they see critical problems and they don't announce release too far away. In that hurry we probably missed ATI graphics problem and could have solved it better. Maybe we should try to have 9 months but if it will be 10 with more stable release i would go with 10 (or mabye final freeze in 8 months and then we'll see how fast we can make it stable). (And we have to keep up the good job with upgrading smoothness - in the future it must be tested even more, that way users who want longer cycle will complain less if they can upgrade their system w/o big problems.) -- my 0.02€ (or a bit more :P) Sander
Re: [Mageia-dev] Release cycles proposals, and discussion
13.06.2011 19:51, Ron kirjutas: I will say my part and I'm gone... I don't understand why everyone is acting like a rolling release is going to put so much strain on the project. What is so hard about developing in one place and allowing the updates to trickle down is so hard? Well.. take Cauldron as a rolling release. It basically is :) So from that point of view.. why would we need another rolling release if we already have one? :) -- Sander
Re: [Mageia-dev] Firefox 5
14.06.2011 15:30, Michael Scherer kirjutas: Le mardi 14 juin 2011 à 14:14 +0200, Samuel Verschelde a écrit : Le mardi 14 juin 2011 13:56:29, Dexter Morgan a écrit : Hello, do we wait firefox 5 rc or we can start to update to firefox 5 soon ? Mandriva now has several packages for firefox (like for chromium), following the upstream channels, maybe we could envision doing it too ? That's 3 times the work however, especially for extensions. IMHO extensions and plugins should be same for all. They might not work but this will be the choice of the user. -- Sander
Re: [Mageia-dev] Firefox 5
14.06.2011 15:32, Frank Griffin kirjutas:
On 06/14/2011 08:22 AM, Thierry Vignaud wrote:
Upgrading stable firefox to firefox5rc and importing firefox-{beta,aurora}
are two distinct orthogonal things IMHO.
since firefox5 is near being released, I think we should update
main xulrunner+firefox to 5 anyway
Whatever we do, please don't put it in Core to replace FF4 until the add-ons have been
updated. It was really annoying to lose the Tor add-on for months because the beta FF4
just showed up and replaced FF3, and the Tor add-on wasn't updated until the release or
just before.
Addons must be updated faster this time around. Firefox 5 will be next security update for
Firefox 4.0.1. This is Mozillas new policy. They won't support Firefox 4 any longer this time.
--
Sander
Re: [Mageia-dev] Firefox 5
16.06.2011 17:18, Daniel Kreuter kirjutas: Ok Mozilla has the RC1 released. Final shall come on Tuesday 21st June so yeah we will include that in Mageia 2 I think (as least this one, maybe FF6 or 7 depending on which version will be available i think) 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.. -- Sander
Re: [Mageia-dev] Proposal of a backporting process
26.06.2011 12:35, Michael Scherer kirjutas: urpme package; urpmi package That's not so easy if something depends on that package. How hard is it to implement rpm's --oldpackage to urpmi? I really don't know but i hope it's nothing too hard. -- Sander
[Mageia-dev] How to add package into backports_testing
Hey, i'm having some trouble with adding get-skype into backports_testing. blino told me to cp get-skype into updates/1 as i can't submit it from cauldron. So i did. But now i get another error: svn: URL 'svn+ssh://svn.mageia.org/svn/binrepos/updates/1/get-skype/current/SOURCES' doesn't exist And this time i have no idea what to do. get-skype has no binary sources, so i have noting to upload either. Any help? -- Sander
Re: [Mageia-dev] How to add package into backports_testing
02.07.2011 21:27, Dexter Morgan kirjutas: On Sat, Jul 2, 2011 at 3:37 PM, Anssi Hannula anssi.hann...@iki.fi wrote: updates/1 is meant for updates, not backports. Hmm, ok, blino told me that into mga1 you can only submit from updates/1 and not from cauldron. So i did :/ And finally i got it submitted to backports_testing. -- Anssi Hannula But as there was no get-skype for mageia 1 iirc we can push it on testing_updates It's probably possible to submit it into updates_testing then. In general we are lacking how-to for packagers. How to submit update? How to submit backport? etc ... I searched wiki but couldn't find. -- Sander
Re: [Mageia-dev] Generic 64-bit building question
13.07.2011 11:43, Radu-Cristian FOTESCU kirjutas: do NOT expand into the existing: lib64magick-devel lib64chm-devel lib64wmf-devel Currently there is urpmq --provides for that. For example: $ urpmq --provides lib64magick-devel imagemagick-devel[== 6.6.6.10-5.mga1] ImageMagick-devel[== 6.6.6.10-5.mga1] libmagick-devel[== 6.6.6.10-5.mga1] libMagick-devel[== 6.6.6.10-5.mga1] libMagick5-devel[== 6.6.6.10-5.mga1] pkgconfig(ImageMagick)[== 6.6.6] pkgconfig(ImageMagick++)[== 6.6.6] pkgconfig(Magick++)[== 6.6.6] pkgconfig(MagickCore)[== 6.6.6] pkgconfig(MagickWand)[== 6.6.6] pkgconfig(Wand)[== 6.6.6] devel(libMagick++(64bit)) devel(libMagickCore(64bit)) devel(libMagickWand(64bit)) lib64magick-devel[== 6.6.6.10-5.mga1] lib64magick-devel(x86-64)[== 6.6.6.10-5.mga1] You should use libmagick-devel -- Sander
Re: [Mageia-dev] Generic 64-bit building question
13.07.2011 12:17, Radu-Cristian FOTESCU kirjutas:
Indeed, libmagick-devel, libwmf-devel, libchm-devel, libpoppler-qt4-devel, etc.
do expand/match/find_provides correctly on 64-bit too!
But then *why* some names have to be written as:
qt4-devel and *not* libqt4-devel
python-devel and *not* libpython-devel
?
Isn't this an inconsistency?
That's why there was discussion started, some time ago, in this list, to
create devel packages so that they will provide %{name}-devel and
lib%{name}-deve.
http://comments.gmane.org/gmane.linux.mageia.devel/6365
Moreover, excuse me, but I find it stupid to have a 64-bit lib called
`libksane-devel`.
This is devel package, not library itself, so it's OK.
--
Sander
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
13.07.2011 13:02, Ahmad Samir kirjutas:
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.
WDYT?
+1
IMHO provides should be added anyway.
Who's gonna update policy? :)
--
Sander
Re: [Mageia-dev] Adobe Flash player 11 Beta 1 in Cauldron
16.07.2011 10:57, Ahmad Samir kirjutas: Right, let's do a head count: Mageia 64bit users who are using the 64bit Adobe Flash 11 Beta 1, please raise your hand (my hand is raised already, I've been using it for 2-3 days). +1 This beta works OK, a lot better than any other option on 64-bit systems. -- Sander
Re: [Mageia-dev] kernel 3.0 is a big mistake in cauldron
16.07.2011 14:07, D.Morgan kirjutas: for my part i still love tmb a lot for his awesome work +1 R-C, please behave.. this is cauldron, it breaks stuff and we almost want it (at least sometimes :)). If you don't like the way it is, please don't use it! -- Sander
Re: [Mageia-dev] kernel 3.0 is a big mistake in cauldron
16.07.2011 14:31, Radu-Cristian FOTESCU kirjutas: ok, then how about kernel-desktop-latest-unstable kernel-desktop-latest-rc kernel-desktop-latest-beta ? But why not kernel-desktop-latest-unstable-beta and kernel-desktop-latest-unstable-rc, etc.. as well? I think buildsystem would love it (one kernel submission would take a day) :) It's cauldron, face it deal with it! -- Sander
Re: [Mageia-dev] kernel 3.0 is a big mistake in cauldron
16.07.2011 15:11, Radu-Cristian FOTESCU kirjutas: R-C, please behave.. this is cauldron, it breaks stuff and we almost want it (at least sometimes :)). If you don't like the way it is, please don't use it! Sander, [didn't read it all - don't have that much time] R-C aka beranger I have to say.. for the last 10+ years you have used OS that's not for you and that you don't understand. Sorry for you, maybe Mr. Jobs can help you out? (Sorry for feeding trolls, my last time ;)) -- Sander
Re: [Mageia-dev] Meeting tonight
20.07.2011 19:20, Michael Scherer kirjutas: Hi, Late as usual ( to roughly quote and translate ennael on irc what, it is already wenesday ? ), we will be having a meeting tonight. Quick agenda : - review of pending task ( but I didn't found much ) - specs - QA of updates What about backports policy? -- Sander
Re: [Mageia-dev] Updates and 0 release
26.07.2011 13:40, Michael Scherer kirjutas: 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. 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. Can someone please update the policy (http://mageia.org/wiki/doku.php?id=updates_policy) then. If following policy gets you unvalidated then something IS wrong. -- Sander
Re: [Mageia-dev] Updates and 0 release
26.07.2011 19:42, Michael Scherer kirjutas: Likely because none of them know the specific meaning of using 0. From where is this specific meaning coming? Where is it documented? -- Sander
Re: [Mageia-dev] shall i import sawmill rpm?
27.07.2011 11:10, Thomas Backlund kirjutas: That said, I'm not very comfortable with the 30-day trial aspect. I don't see our role as distributing shareware. But whatever is decided ... Yeah, I'm not really fond of the idea of providing shareware on our mirrors either. -- Thomas +1 -- Sander
Re: [Mageia-dev] Updates and 0 release
27.07.2011 17:59, Samuel Verschelde kirjutas: Ok, there will be no meeting tonight, so let's decide it on the ML. Was everyone convinced by misc's demonstration and do we agree to stop using the 0 release for updates and activate the Youri::Submit::Test::Precedence check on submit to prevent higher releases in mageia n than in mageia n+1 ? And if yes do we use subrels for subsequent modifications of packages that are proper to the mageia 1 branch ? I vote yes for both questions. Samuel If it's documented in policy (better with examples) i'm OK with it. Without policy there will be nothing to follow. -- Sander
Re: [Mageia-dev] No meeting tonight
27.07.2011 19:20, Maarten Vanraes kirjutas: Op woensdag 27 juli 2011 16:37:42 schreef Michael Scherer: Hi, since both ennael and I are busy tonight, and since there is nothing really really urgent to announce ( at least, nothing that couldn't be discussed or dispatched on the ml ), I propose to postpone the meeting. that's fine by me, but i would still like to get a move on with backports, do we just OK stormi's proposal, or does this have to be decided by team leaders? There is also problem with the current handling of backports_testing. AFAIK backports are submitted from 1/updates which doesn't make sense. There should be 1/backports and mgarepo shouldn't accepts 1/updates for backports. Or if 1/backports is too much asked then backports should be submitted from cauldron. Correct me if i'm wrong.. -- Sander
Re: [Mageia-dev] RM replacement
05.08.2011 13:17, Colin Guthrie kirjutas: I think srm should just be a tool people use explicitly when they want to. Col +1 -- Sander
Re: [Mageia-dev] Problems setting up chroot
08.08.2011 07:42, andre999 kirjutas: If anyone has an idea what I might be missing, it would be appreciated :) This is what i used to get secondary X running: http://webcache.googleusercontent.com/search?q=cache%3Ahttp%3A%2F%2Fubuntuforums.org%2Farchive%2Findex.php%2Ft-510182.htmlie=utf-8oe=utf-8aq=trls=org.mozilla:et:officialclient=firefox-a If you want to use just some application then run sshd with X forwarding on chroot and connect from your main system. -- Sander
Re: [Mageia-dev] backporting chromium-browser-stable
09.08.2011 13:21, Thierry Vignaud kirjutas: Hi I think we should do a security update of chromium-browser-stable that would be a backport of cauldron's chromium-browser-stable. WDYT? See you Finally someone is thinking about it :) Yes, of course! We have version 11 when there is version 13 released. -- Sander
Re: [Mageia-dev] Planning next meeting
16.08.2011 16:21, Anne nicolas kirjutas: Hi there Back online. We are planning our next meeting for 24th of august, 19h UTC on #mageia-dev. In between we will work on some burning subjects (backports incis meetiluded) so that we can take final decisions during this meeting. As usual and as it's a long time we did not have any meeting, you can propose some topics to be added. We will need a review on current mentoring (André ?) and secteam (Stew ?). Thanks for advance Cheers Another topic proposal: http://check.mageia.org/dependencies.html This is getting slightly out of hand. First there is some fixing to do (for example: horde-prefs found in incorrect media core.x86_64 (allowed core.i586) - a lot of such errors, who's gonna fix them?) Secondly there was proposal not to allow in those packages that have unmet requires (for example awn-amarok-minsec which needs avant-window-navigator). If the package can't be used there is no reason to submit it or allow it in the repos. -- Sander
Re: [Mageia-dev] [Mageia-bugsquad] proposals to improve the triage
24.08.2011 09:51, D.Morgan kirjutas: On Tue, Aug 23, 2011 at 6:20 PM, Thierry Vignaud thierry.vign...@gmail.com wrote: On 23 August 2011 17:57, Manuel Hiebelmanuel...@hiebel.eu wrote: What can we do for reduce the number of Bugs ? Agressivily assign bugs to latest package uploader? I am not sure that all packager (for example: ennael 300rpms or dmorgan 1000rpm uploaded) can work their rpms's bugs. well we could also: - send a mail about the new bugs once a day to mageia-dev - and/or send a summary mail about the easy bugs once a day we could also do some bug week triage asking for help to contributors, making testers tests some bugs. And we still have a lot of packages that are owned by mysterious nobody :) $ mgarepo maintdb get|grep nobody|wc -l 5113 Maybe packagers should take a look at their packages and if they are still owned by nobody then grab them. Another problem (at least for me) is that maintainer from maintdb can't be connected to bugzilla user. Should we create some database that connects maintdb account with bugzilla account so that bugs can be assigned? -- Sander
Re: [Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2
25.08.2011 21:53, Maarten Vanraes kirjutas: i believe we should package as much extensions as possible. And if there is security hole in extension? Do you monitor all of them? Most of them get updated w/o big notice. We do not have people to monitor extensions. And it's stopping us to update Firefox. Too many problems where we could avoid them. -- Sander
Re: [Mageia-dev] [RPM] cauldron core/release firefox-ext-add-on-compatibility-reporter-0.9-1.mga2
26.08.2011 10:27, Guillaume Rousse kirjutas: I don't see where it is stated than firefox can't get updated until all extensions in the distributions work with it. I would call it a regression that shouldn't pass QA. One day your ads ands scripts are blocked and the other day they are not. Great user experience.. The large advantage of packaged extensions is that they are managed by sysadmins, instead of users, which makes a difference when they are different people. And even larger disadvantage comes in when they are not updated. Contain memory leaks and so on. The biggest problem here is that the packager who imported those addons is not keeping them up-to-date. Sysadmin can copy those extensions into place anyway. Then it's up to him/her to keep them up-to-date. Currently we have to take care of that and we don't (or if anyone wants to claim that we do then we do it really poorly as there are already newer versions of addons that got pushed with latest update). -- Sander
Re: [Mageia-dev] [RPM] cauldron core/release firefox-beta-l10n-7.0b2-0.mga2
28.08.2011 08:46, Mageia Team kirjutas: Name: firefox-beta-l10nRelocations: (not relocatable) Version : 7.0b2 Vendor: Mageia.Org Release : 0.mga2Build Date: Sun Aug 28 07:44:28 2011 Install Date: (not installed) Build Host: jonund Group : Networking/WWWSource RPM: (none) Size: 16047527 License: GPL Signature : (none) Packager: Mageia Team http://www.mageia.org URL : http://www.firefox.com/ Summary : Localizations for Firefox (virtual package) Description : Localizations for Firefox web browser. fwang fwang 7.0b2-0.mga2: + Revision: 135845 - new version 7.0b2 + tv tv - clean spec file - imported package firefox-beta-l10n New version, but still a lot of errors: http://check.mageia.org/dependencies.html - what's the point? -- Sander
Re: [Mageia-dev] noarch vs. arch
02.09.2011 10:15, Pascal Terjan kirjutas: Yes there is still a bug in the build system, packages switching between arch/noarch are not deleted Is there bug about this issue? Who should fix it? -- Sander
Re: [Mageia-dev] more testing for systemd: defaulting to it
08.09.2011 16:53, Thierry Vignaud kirjutas: Hi In order to got more testing for systemd, I'm considering switching the installer to: - install it - default to it (aka add init=/bin/systemd) WDYT? If someone fixes this bug ( https://bugs.mageia.org/show_bug.cgi?id=2246 ) then i'm ok with it. Else i'm not sure how many people are affected and if it will make them happy (i'm quite sure it doesn't :P). -- Sander
Re: [Mageia-dev] Fwd: [Mageia-discuss] Switiching window decoration
09.09.2011 16:51, Anne Nicolas kirjutas: As far as we know, Oxygen matches all these requirements. Oxygen exists for all environments with the same maintainers for it. Thus, we would like to discuss to switch to Oxygen as the default window decoration for Mageia 2. +1 on that. I'm already switched to it on all my systems. IaOra had just too many problems and Oxygen works very well. I prefer well working thing to an unique thing :) -- Sander
Re: [Mageia-dev] more testing for systemd: defaulting to it
08.09.2011 16:53, Thierry Vignaud kirjutas: Hi In order to got more testing for systemd, I'm considering switching the installer to: - install it - default to it (aka add init=/bin/systemd) WDYT? See you I got another problem. This time with /var. For two systems i have created /var as a separate volume on LVM. And systemd can't start /var. It's complaining that some deps failed. So long i only noticed different types of loggers that won't start. Also complaining about failed deps. So is there a loop? Loggers won't start as they want to log on /var and /var can't be mounted as it needs some logger to log it?! I'll try to test it more on VM but so long it seems that separated /var is causing boot problems :S (one system didn't start at all (and has weird repeating errors: http://dl.dropbox.com/u/4210594/IMG_20110911_230902.jpg ) so i have to revert back to sysvinit). -- Sander
Re: [Mageia-dev] [changelog] cauldron core/release basesystem-1-4.mga2
13.09.2011 23:39, Thierry Vignaud kirjutas: On 13 September 2011 17:45, Guillaume Rousseguillomovi...@gmail.com 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 ? um... yes it should be possible. I'll look at it tomorrow. That would help a lot. Currently if systemd fails recovery is PITA.. -- Sander
Re: [Mageia-dev] changing apache configuration handling
14.09.2011 11:06, Guillaume Rousse kirjutas: - keep current behaviour, by removing conditionals in configuration file. This means no additional configuration needed, but also than installing implies usage. I prefer this option. If you install some module you probably want to use it. And if you don't you can uninstall it or modify conf. -- Sander
Re: [Mageia-dev] [Mageia-discuss] MANDATORY READ : 7 days before misc unleashes CERBERUS !
15.09.2011 21:43, Maarten Vanraes kirjutas: I have a script ready to set the last comittor (that's a full packager) as maintainer. perhaps it can be activated before the GREAT PURGE. That's not so good idea. What we maybe can do is that we send out a warning that if you commit to a package after the warning and the package has no maintainer yet then you become one. So that people would first check what they get on their name. Many packages were imported by Anne, i'm not sure that she's going to maintain them all. :) I would do something like that: 2 months of warning period, if you touch package that has no maintainer you become its maintainer. After 2 months we start dropping those packages that have still no maintainer. Maybe not dropping them all at once but by some list that is fist shown on the ml and some packagers can still save some packages from going away. -- Sander
Re: [Mageia-dev] [Mageia-discuss] MANDATORY READ : 7 days before misc unleashes CERBERUS !
16.09.2011 13:44, Guillaume Rousse kirjutas: This whole idea of 'touch a package, become its maintainer' assumes than anyone modifying a package has an obvious interest in it. However, they are case when you have rebuild a package just in order to accomodate for changes you made somewhere else. For instance, rebuilding all packages linked against a given library after updating this last one to a new version... Well, if you don't need those other packages then you just skip rebuilding them to see if anyone needs them. If not then we don't have a problem, they will be dropped :/ If anyone sees that this breaks some functionality in his/her packages then (s)he needs to rebuild them and will become maintainer. Or we need some optional maintainership status.. like username-forced(-to-be-maintainer). So that other maintainers know they can help or take over package. -- Sander
Re: [Mageia-dev] systemd vs dm
18.09.2011 11:22, Colin Guthrie kirjutas: Hmm, strange. My gdm boots on tty7 here without any problem... :s Are you using systemd-sysvinit or sysvinit with init=/bin/systemd ... for me there is difference. Using systemd-sysvinit i can't boot up at all.. With init=/bin/systemd things are a bit better. -- Sander
Re: [Mageia-dev] Tonight's meeting
21.09.2011 12:37, Anne nicolas kirjutas: Hi there As usual we will have our weekly meeting at 19hUTC on #mageia-dev. Proposed topics: - faac and Mageia: take a final decision for it How about final decision for backports as well? AFAIK we STILL can't submit them :/ -- Sander
Re: [Mageia-dev] Trying to solve bug #2317
22.09.2011 15:40, Samuel Verschelde kirjutas: I forgot: what about the suggestion that was made to tweak urpmi --update's behaviour so that it proposes only updates from update media, but is capable to pull dependencies from release media ? Would there be drawbacks to this solution ? Samuel Does urpmi know which one is release media and not backports? -- Sander
Re: [Mageia-dev] [RFC] msec (nail) can't send reports to local users accounts - require an MTA?
22.09.2011 22:37, Florian Hubold kirjutas: Please give your votes. I like the idea that by default MTA is not needed (but it might be suggested) and default conf uses only log. Requiring here would be too harsh as some users prefer log files and msec works with them as well. MTA is extra feature and user can configure it if needed. -- Sander
Re: [Mageia-dev] [RFC] msec (nail) can't send reports to local users accounts - require an MTA?
23.09.2011 12:43, Florian Hubold kirjutas: If you have an MTA installed (and configured) mail should be sent. Where? To local user? Does the user know how to read that mail? To real mail address? What if you have a laptop and are moving from one ISP to another. Does the user know how to configure MTA for that? -- Sander
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release libusb1-1.0.8-2.mga2
30.09.2011 09:55, Thierry Vignaud kirjutas: On 29 September 2011 19:52, Mageia Team buildsystem-dae...@mageia.org wrote: sander85 sander85 1.0.8-2.mga2: + Revision: 150378 - Fix a race condition in io.c libusb_handle_events_timeout() (ticket #56) Wrong bug ID. Please use svn propedit svn:log --revprop -r150378 in order to put the right bug ID It's an upstream ticket that is still unresolved (there is link for it in the spec). No bug on our side. -- Sander
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release libusb1-1.0.8-2.mga2
30.09.2011 13:01, Anssi Hannula kirjutas: On 30.09.2011 11:10, Sander Lepik wrote: 30.09.2011 09:55, Thierry Vignaud kirjutas: On 29 September 2011 19:52, Mageia Team buildsystem-dae...@mageia.org wrote: sander85 sander85 1.0.8-2.mga2: + Revision: 150378 - Fix a race condition in io.c libusb_handle_events_timeout() (ticket #56) Wrong bug ID. Please use svn propedit svn:log --revprop -r150378 in order to put the right bug ID It's an upstream ticket that is still unresolved (there is link for it in the spec). No bug on our side. Then change it to upstream ticket #56 or libusb ticket #56. Done -- Sander
Re: [Mageia-dev] Please test: initscripts+systemd in updates_testing
26.10.2011 09:36, D.Morgan kirjutas: can someone test and report if it worked or not ? we need feedback to push all this in core/release and have this available for alpha1 thank you. Systemd + dracut initrd works. I have long delays but this is probably udev and/or kernel problem. -- Sander
Re: [Mageia-dev] Please test: initscripts+systemd in updates_testing
26.10.2011 10:00, David W. Hodgins kirjutas: On Wed, 26 Oct 2011 02:36:07 -0400, D.Morgan dmorga...@gmail.com wrote: can someone test and report if it worked or not ? we need feedback to push all this in core/release and have this available for alpha1 Worked ok here, with the following problems pata_acpi is being loaded before pata_via, causing many problems. vnstat must be uninstalled, or shutdown hangs. With the system set to use localtime, the clock is set to utc instead of localtime. Have you checked dracut conf? There was some list of preloaded modules AFAIK, maybe you can change order there? -- Sander
Re: [Mageia-dev] Please test: initscripts+systemd in updates_testing
27.10.2011 15:33, Thomas Backlund kirjutas: My laptop hangs on shutdown. My desktop has quite a long delay before it turns off (maybe even 5 minutes). Last time I tried (a while ago), it screwed up booting my dmraid setup, and it was painful to restore, so I haven't tried after that. With dracut i got my system booting (soft raid1 + lvm (also i had to move /usr under /)). -- Sander
Re: [Mageia-dev] Please test: initscripts+systemd in updates_testing
27.10.2011 16:45, Thomas Backlund kirjutas: Sander Lepik skrev 27.10.2011 16:07: 27.10.2011 15:33, Thomas Backlund kirjutas: My laptop hangs on shutdown. My desktop has quite a long delay before it turns off (maybe even 5 minutes). Ok, so thats a showstopper that need to be fixed. Yes. With dracut i got my system booting (soft raid1 + lvm (also i had to move /usr under /)). And so is this. if dracut or systemd requires /usr to be under / then it will _never_ be default. It's systemd. It has some libs in /usr/lib that it needs for udev.service (if i remember correctly) and for some reason udev.service is needed for mounting services. Tho' if it fails and switches into rescue console i can manually mount /usr and make it continue booting. Maybe we can reorder those services somehow. That's just plain idiotic. I somewhat agree. But even Fedora is suggesting not to have separate /usr :( -- Sander
Re: [Mageia-dev] [packages-commits] [158743] Apply P0
27.10.2011 23:36, Charles A Edwards kirjutas: So as built it is no longer installable by those of us who still are using sysvinit. I don't think we can support both for mga2. And at the moment it seems we are going with systemd. So maybe it's time to jump the boat and start testing systemd to find its bugs as early as possible. -- Sander
Re: [Mageia-dev] Updating a new install is too long...
06.11.2011 13:38, Wolfgang Bornath kirjutas: 2011/11/6 Maarten Vanraesal...@rmail.be: It may be an option if you have such a DVD I was talking about in point 2 - somewhere at the start of the install process you can add an additional medium. If a newer package is on the update DVD (or USB key or external harddisk) the installer should take this instead of the package from the installer DVD) should work with an update DVD or USB key. It will not reduce the download but the overall system setup time (as you wrote). Won't this end up with Enter updates medium - Enter main medium - Enter updates medium - and so on.. -- Sander
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kdenlive-0.8.2-1.mga2
07.11.2011 15:26, John Balcaen kirjutas: Then the question is why did we ship a buggy software in our release. Simply because it was shipped initially in Mandriva someone request it to be available in Mageia. It's the same thing as calibre or chromium-browser i would say :p +1 Or are the crashes not that important ? I don't know if they are important or not, however when i'm reading this changelog i feel culprit about not providing a update version for a version shipped with so many bugs/corruption because i personally won't be happy to loose hours of works on a video because of a crash/corruption. Those crashes are important and my friend is complaining about some of those. Of course we can also simply push it as backports but this is not correct from my point of view. Well.. firstly, you can't push it to backports as backports are STILL not open (board, wtf? who is responsible?!) and secondly, yes it would be better to release it as an update (too many crashing bugs and also some of the features will make life easier). -- Sander
Re: [Mageia-dev] MariaDB 5.5.18 on cauldron tonight
07.12.2011 22:31, Maarten Vanraes kirjutas: Op woensdag 07 december 2011 20:38:16 schreef Thomas Backlund: After Alpha2 I guess we need to discuss this on a council meeting to get a decision for Mageia 2. fine, i don't see the need of why to have a council meeting wrt this though... it's so frustrating, i'm doing here all the work and testing while mysql is officially unmaintained... we're going on and on about how we're going to drop everything unmaintained, but when push comes to shove, it's all a bluff... /rant lemme know when there _IS_ a good moment to submit If MySQL has no maintainer for alpha 2 then i'm in for MariaDB. No point to keep unmaintained packages if there is replacement and maintainer for it. -- Sander
Re: [Mageia-dev] Where to report mageia 2 alpha 1 problems?
10.12.2011 15:23, Franklin Weng kirjutas: Hi list, I tested mageia 2 alpha 1 (KDE live CD) for the audio problem (bug 2437) and at the same time I found another two problems. Where can I report it? The wiki pages seem to be down for now. https://bugs.mageia.org 2. If I turned Screenshot KDE desktop effect on, I still got problems getting screenshot with ksnapshot. It is an old problem in mageia 1. This is upstream bug and you should report it there. Tho' i believe it's already reported. -- Sander
Re: [Mageia-dev] Package adoption campaign, 3 months later
15.12.2011 01:28, Manuel Hiebel kirjutas: And what to do with package that have a maintainer, but the packager does not fix the bugs or is inactive ? :D List them here.. lets make a wall of blame :) -- Sander
Re: [Mageia-dev] ANN: X11 now starts on tty1
17.12.2011 12:10, Wolfgang Bornath kirjutas: I really beg to think the whole matter over again, at least until it is mature enough to be implemented in cauldron for practical test. People will get used to it rather fast. -- Sander
Re: [Mageia-dev] ANN: X11 now starts on tty1
17.12.2011 19:14, Johnny A. Solbu kirjutas: Another friend of mine which is not in any of these lists, and is blind, was surprised to hear about this change, and was wondering whether this was a Mageia specifi change. I said I believe it was. Well, it's not. -- Sander
Re: [Mageia-dev] ANN: X11 now starts on tty1
18.12.2011 17:43, Johnny A. Solbu kirjutas: Whatever you do, Do Not completely remove the abillity to have a few simultanious text logins alongside a graphical login. The users who depend upon using a text login alongside the graphical environment are more than one should think. F1-F6 for graphical login, F7-F11 for console. Everyone should be happy. Especially new linux users. -- Sander
Re: [Mageia-dev] ANN: X11 now starts on tty1
18.12.2011 22:53, Frank Griffin kirjutas: Wouldn't the obvious solution be to make the tty assignments easily configurable by the user ? Then pick an agreed default, and let anyone with different requirements modify it. Nop, that's not a good idea. You give people the option to configure and they end up doing so. Every additional configuration option will add complexity. More hassle for QA and maintainers, etc etc. There shoulde be only one way and that's it. -- Sander
Re: [Mageia-dev] [changelog] [RPM] 1 core/updates_testing firefox-9.0-0.1.mga1
30.12.2011 07:00, David W. Hodgins kirjutas: On Thu, 29 Dec 2011 12:20:36 -0500, Manuel Hiebel man...@hiebel.eu wrote: (and iirc QA don't check it anymore, as you can see in the updates of firefox 6 or later) We do test them when they become available, but won't hold back a security update for firefox, waiting for the extensions. Regards, Dave Hodgins AFAIK since fx10 nonbinary extensions are allowed by default if during testing there are no complaints that they don't work with latest version. At least mozilla-esteid is enabled on my tarball fx10. So we'll see when fx10 is released. -- Sander
Re: [Mageia-dev] [changelog] [RPM] cauldron nonfree/release drakx-installer-images-1.59-2.mga2.nonfree
05.01.2012 19:22, Thierry Vignaud kirjutas: On 5 January 2012 17:34, tmbbuildsystem-dae...@mageia.org wrote: tmbtmb 1.59-2.mga2: + Revision: 191558 - build with kernel-3.2.0-1.mga2 - kernel-firmware-extra is now kernel-firmware-nonfree And maybe on i586 too... WDYT? Good idea, boot.iso is needed to get things running. You can install other kernels later. -- Sander
Re: [Mageia-dev] Orphans - those poor orphans . . .
06.01.2012 19:40, Johnny A. Solbu kirjutas: On Friday 06 January 2012 16:13, Thierry Vignaud wrote: The system has to be intelligent enough to know what is or is not an orphan. It is. We claim that it is not. Well, the system is ok. Just some packages are probably bogus and don't require all packages they need. The end result is that many of us handle this feature like the plague; very carefully to avoid destruction. Many never use this feature, fearing it could destroy the system, prompting a reinstall. Maybe at mdk9.1 it had problems. Tho' i'm not sure if urpmi even had that option at that time. For me orphans are always worked. There is one thing that can cause problems - task (meta) packages. For example if you remove task-kde4 then yes, you get a lot of kde packages that are marked as orphans as task-kde4 pulled them in and is now uninstalled. But if some package has requires on other package then this other package isn't marked as orphan. -- Sander
Re: [Mageia-dev] Orphans - those poor orphans . . .
06.01.2012 21:06, Dale Huckeby kirjutas: Evidently once I've installed package A which requests X, sometimes packages F, L, and T might subsequently get installed which also need X *and presumably would have requested it had it not already been installed*. But when I uninstall A it orphans X because A is the only package that *requested* it. When F, L, and T are installed can't all the packages they *would have requested* be marked whether or not they're already installed? That way a package would be orphaned only when the last package that needs it is uninstalled? Or am I missing something? This is already so. See example: http://pastebin.com/AMj87QiV - after first urpme libplasmaweather4 should be marked as orphan but it's not as it's still required by other package. -- Sander
Re: [Mageia-dev] Orphans - those poor orphans . . .
07.01.2012 01:09, Johnny A. Solbu kirjutas: On Friday 06 January 2012 18:54, Balcaen John wrote: I guess when you did encounter that you just remove task-kde from your system I did not. I should have been more clearly with my example. :-)= The packages in my example where all console program, that I installed and removed using urpm[ie]. So I explicitly removed only the one program I just installed. And it did not install any other packages, as a result of dependencies. And this is my point. We uninstall a specific program, not a meta/task package, which result in some packages beeing marked as orphaned, when they are infact Not orphaned. Give us command line example. Install something and remove it and then show me what got orphaned if it wasn't orphan before. What you claim here doesn't sound right as i haven't seen it myself. -- Sander
Re: [Mageia-dev] Orphans - those poor orphans . . .
07.01.2012 12:18, andre999 kirjutas: It is not exactly the same thing, but in more than one occasion when I installed packages with similar functions at the same time, to compare them, say A, B, and C, and later uninstalled B and C, I have found A to be declared an orphan. Only to find that it had been required by one of the others. (I often prefer command-line packages. It is simple to add them to the menu if I want. And I have often enough made such comparisons. To be fair, I haven't done much of that since installing Mageia, when it first became available.) So what you say is: urpmi A urpmi B urpmi C urpme B C A would be orphan? Really?! Show me. I want an example! The auto-orphans option and how it currently works is based on the assumption that if package A is installed as a requirement of package B, that on uninstalling B, one will want to uninstall A. That to me is a false premise. You do get the point of orphans?! System has no AI. It only knows what it has to know. If you still want A you would just run urpmi A and urpme --auto-orphans won't remove it! Simple as that. -- Sander
Re: [Mageia-dev] Orphans - those poor orphans . . .
07.01.2012 13:39, Wolfgang Bornath kirjutas: Of course this is one way to find bugs in packages. But what about the documented (in German) case where - after fresh installation, reboot (ok) and updates right after installation I was presented with a list of more than 100 orphans. - I ran 'urpme --auto-orphans' and rebooted - several system services (which started successfully after installation) refused to start now because of missing files Of course urpmi was not the culprit because it only checks dependencies. But that did matter in that situation. The auto-orphans function obviously listed packages which may have no dependencies but are needed by the system. That's why I do not complain about urpmi but about the whole function. As long as this function is only based on package dependencies it is not safe to use it. Did you choose custom install and unchecked some options? Or did you use LiveCD maybe? Anyway.. function is not to blame. Next time copy those packages that are going to be uninstalled. And they can be rechecked. Which are needed and why they get orphaned. -- Sander
Re: [Mageia-dev] Orphans - those poor orphans . . .
07.01.2012 16:24, Wolfgang Bornath kirjutas: Used the full DVD (32-bit) Mageia 2 Alpha 2 - minimal install with X How? AFAIK this is not one of the default options. -- Sander
Re: [Mageia-dev] Orphans - those poor orphans . . .
07.01.2012 17:09, Wolfgang Bornath kirjutas: 2012/1/7 Sander Lepiksander.le...@eesti.ee: 07.01.2012 16:24, Wolfgang Bornath kirjutas: Used the full DVD (32-bit) Mageia 2 Alpha 2 - minimal install with X How? AFAIK this is not one of the default options. It is. 1. Select Custom at the DE selection 2. Unmark all package groups 3. Up comes a selection of 4 options: - minimal with x - minimal without x - truely minimal (only base system - minimal with documentation (which is an option you can select together with one of the first 2. So, yes, it is a defined set of packages. That's why I used it. Ok, next time if you test, do the same. But before removing orphans copy them for later debugging. -- Sander
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release qesteidutil-3.4.0-3.mga2
18.12.2011 10:45, Mageia Team kirjutas: Name: qesteidutil Relocations: (not relocatable) Version : 3.4.0 Vendor: Mageia.Org Release : 3.mga2Build Date: Sun Dec 18 09:36:19 2011 Install Date: (not installed) Build Host: ecosse Group : OfficeSource RPM: (none) Size: 794924 License: LGPLv2 Signature : (none) Packager: Mageia Teamhttp://www.mageia.org URL : http://id.eesti.ee Summary : Estonian ID card utility Description : QEsteidUtil is a user-friendly application for managing Estonian ID Cards. It can be used to to change and unlock PIN codes, examine the personal information stored on the card, extract and view the certificates, set up mobile ID and configure a personal @eesti.ee e-mail address. fwangfwang 3.4.0-3.mga2: + Revision: 183700 - br qtwebkit Why this br? I fail to see reason. :) -- Sander
Re: [Mageia-dev] FireFox ESR = we should totally go for this wrt stable releases
13.01.2012 03:20, Maarten Vanraes kirjutas: see https://blog.mozilla.com/blog/2012/01/10/delivering-a-mozilla-firefox- extended-support-release/ see https://wiki.mozilla.org/images/9/9d/Esr-release-overview.png ESR is a 1y extended supported release... looking at the image we'd be having supported versions for our 9month release schedule every time... we should totally use this release and not go towards FF11 for our release. We've been complaining about the too quick release schedule... this is our chance! ( i think if the FF maintainer wishes, he could also do backports of the regular releases... ) i'm hoping everyone agrees? including FF maintainer? I don't agree. But i'm not the maintainer. Why not? * Since fx10 all non-binary extensions are compatible by default (so our main problem goes away). * fx10 in 6 months is dead old for users POV. Many unhappy users. Lower popularity for Mageia. (Ubuntu AFAIK is going with fast schedule). * We will miss too many new and cool features. * When we release But as i said.. up to maintainer. -- Sander
Re: [Mageia-dev] FireFox ESR = we should totally go for this wrt stable releases
13.01.2012 23:20, Maarten Vanraes kirjutas: look at the picture for the support period, the 1y warranteed versions cross over for 2 or 3 months so it's going to fit for as long as we have 9m release schedule 9m release schedule, but aren't we giving support for 18m? -- Sander
Re: [Mageia-dev] Too many tmp directories
21.01.2012 20:59, andre999 kirjutas: Sounds like a good idea. It might be better to get rid of /tmp if we can, since systems would always have a read-write /var and thus /var/tmp, even if they have a read-only /. AFAIK even Flash Player uses /tmp to download content. Probably some other external programs too. IMHO it's not good idea to remove longstanding system directories. -- Sander
Re: [Mageia-dev] FireFox ESR = we should totally go for this wrt stable releases
06.02.2012 04:07, Funda Wang kirjutas: I would suggest another support policy. * For cauldron, we always have latest versions of firefox and thunderbird, no matter whether it is ESR. * For released distros, we always update it till next ESR. i.e., for Mageia 1, we will have FF 9.0.1, 10.0, 10.0.1, 10.0.2, 10.0.3, but not 11.0. If time passed, we will go directly 10.0.x to 17.0 ESR. And what if you have fx13 on cauldron and we need to switch to stable (mga2)? -- Sander
Re: [Mageia-dev] FireFox ESR = we should totally go for this wrt stable releases
06.02.2012 09:38, Funda Wang kirjutas: And, don't forget, we still have a package named firefox-beta. If we stick with FF10, then some day we will come to a situation of firefox-10.0.4 and firefox-beta-15b1 for Mageia 2, which is unacceptable. Or, we should make an exception on firefox-beta, it should be obsoleted by updated firefox for stable distros. Indeed, firefox-beta must be obsoleted on stable release like chrome's similar versions are as we don't have maintaner who wants to keep them up-to-date on stable releases. I agree with D.Morgan that if we want to continue with ESR version then cauldron will stay on 10.0 (not sure how we can have newer versions of beta if they depend on the same packages). And it's also true that we will lose some users if they don't want to use tarball version and will pick distro that can keep browsers up-to-date. Sad, but true. (Funda, can you please stop top-posting. This is rude man!) -- Sander
Re: [Mageia-dev] FireFox ESR = we should totally go for this wrt stable releases
09.02.2012 13:35, AL13N kirjutas: ihmo, the users who want the latest versions will not even wait one week, and will grab them from upstream. If we really wanted the latest release, someone could backport them. And backports work since what time? the end users will benefit too, because the modules/plugins will still work and not being unstable at every update. as a long time stable user, i prefer the ESR... we've been complaining about too short releasecycles... this is the answer, we should use it. Most users don't know what to do with tarball. They only know that their browser doesn't have latest promoted changes. And that means distribution is doing something wrong for them. We were complaining because extensions didn't work. I don't know how many plugins there were with problems. Can't remember any myself. Nonbinary extensions are now compatible by default, so one problem less. ESR means QA testing anyway. It's only bugfixes but that doesn't mean you can update w/o testing. -- Sander
Re: [Mageia-dev] Removing Core 32bit from x86_64
24.02.2012 13:09, Pierre Jarillon kirjutas: I have just installed Mga2b1 x86_64 and it is already a great distro. But once more, I was annoyed with an unuseful bunch of rpm in rpmdrake which make the list less readable. For a beginner, this is more annoying. So, I have unselected Core 32 bit and everything seams to be ok. As pcpa said in [Cooker] Multilib next steps?, the only reason to run in 32 bit mode is legacy binaries that cannot be rebuilt. IMO, the last useful binary was flashplugin, now the adobe 64bit binary works fine. Is it still useful to keep this outgrowth alive? Cooker != cauldron. We still have skype and probably many other packages that need 32-bit libs. So disabling Core 32 doesn't sound as a good plan to me. -- Sander
Re: [Mageia-dev] Removing Core 32bit from x86_64
25.02.2012 12:39, Colin Guthrie kirjutas: 'Twas brillig, and zezinho at 25/02/12 00:00 did gyre and gimble: Shouldn't get-skype be 32bit if it needs 32bit libs? Perhaps, but then it wouldn't show up to 64 bit users if they don't add 32-bit core which is the suggestion here. They would have to add 32-bit core + 32-bit nonfree (as Skype is in nonfree) which is not even listed media for 64-bit system. -- Sander
Re: [Mageia-dev] Removing Core 32bit from x86_64
25.02.2012 13:47, zezinho kirjutas: Le samedi 25 février 2012 11:44:58, Sander Lepik a écrit : They would have to add 32-bit core + 32-bit nonfree (as Skype is in nonfree) which is not even listed media for 64-bit system. So for now Skype is not avalaible in x86_64 without activating 32-bit nonfree? No, as it's noarch it's available in 64-bit nonfree too, but it needs 32-bit core for libs that it uses. -- Sander
Re: [Mageia-dev] Removing Core 32bit from x86_64
25.02.2012 14:39, Michael Scherer kirjutas: Le samedi 25 février 2012 à 14:04 +0200, Sander Lepik a écrit : 25.02.2012 13:47, zezinho kirjutas: Le samedi 25 février 2012 11:44:58, Sander Lepik a écrit : They would have to add 32-bit core + 32-bit nonfree (as Skype is in nonfree) which is not even listed media for 64-bit system. So for now Skype is not avalaible in x86_64 without activating 32-bit nonfree? No, as it's noarch it's available in 64-bit nonfree too, but it needs 32-bit core for libs that it uses. Then, it should no be noarch. From the policy POV yeah, it shouldn't. From the usability POV.. well, it's our only option to make Skype available for 64-bit users. -- Sander
[Mageia-dev] Versions freeze
Hey! According to https://wiki.mageia.org/en/Mageia_2_development we are going to hit versions freeze pretty soon. Is it confirmed that it will be March 7th? In this case we have the last weekend before freeze. And weekend is for many packagers the only time to work on their packages. Such dates should be announced in advance. -- Sander
Re: [Mageia-dev] Versions freeze
On Mar 3, 2012 7:41 PM, Oliver Burger oliver@googlemail.com wrote: And in the last meeting logs for this channel, the reminder was said and discussed. Oliver Can this link be sent to list after meeting? Or is this too much asked? Or was it sent and i just missed it? -- Sander
Re: [Mageia-dev] Versions freeze
Well, actually I'm sure it could. But why? All meeting logs are publicly available at https://meetbot.mageia.org/ Why? Because now i know this link for some time and then i forget it again :) Sorry but Mageia isn't the only project where i'm contributing. I just can't remember everything. But thanks for the link. -- Sander
Re: [Mageia-dev] [changelog] [RPM] cauldron nonfree/release get-skype-2.2.0.35-18.mga2.nonfree
08.03.2012 16:00, Kamil Rytarowski kirjutas: On 08.03.2012 13:20, Sander Lepik wrote: Skype is pretty popular nowdays. 64-bit systems are pretty popular too, you know. Yes, we had conflict with policy. But in this case i think the policy is the one that must be changed. Do you want to merge 32-bit and 64-bit software for nonfree and tainted? No, i don't. For exeptions like Skype. Why? Because this can't be done any other way. Or we need to add Nonfree 32 for 64-bit systems which makes a lot less sense to me. If we add core 32-bit, then why not nonfree 32-bit? Why to bloat our servers with pseudo 64-bit packages? Bloat? Noarch packages should be hardlinked AFAIK. Or you will start explaining to users again, why we don't have Skype in our distro :( 1. Skype isn't in our distro, just a dummy package. User has no idea what it is, (s)he either can find it in rpmdrake or not. 2. Moving into the right place = not shipping at all? For 64-bit users it is not shipping at all. 3. Tagging Skype as noarch is a falsehood. What about the coming ARM? What about other 32-bit only software? Lets deal with ARM problems when ARM is supported. For that time we might have 64-bit Skype. It worked w/o any problems on 64-bit systems. Now we are back in square one. Every 32-bit software should work without any problems with 64-bit systems.. this is not a real argument. Yes, but 32-bit nonfree packages are not available to 64-bit users. I was quite sure that Mageia would keep the usability bit that Mandriva had. But with our current direction Gentoo is soon easier to use for non-developer/sysadmin user. -- Sander
Re: [Mageia-dev] [Freeze] please let in xonotic
11.03.2012 14:21, Michael Scherer kirjutas: Le samedi 10 mars 2012 à 10:26 +0100, Thierry Vignaud a écrit : Hi please let in xonotic-0.6.0 It's just a game that impacts nothing else. Niet. That's bugfix or security fixes. Honestly, WTF?! It's a new package. How much harm can it do? I would understand this rejection if we would have backports enabled. But we don't. Some point release can cause more trouble than this package. This is getting ridiculous. -- Sander
Re: [Mageia-dev] [Freeze] please let in xonotic
11.03.2012 14:42, Manuel Hiebel kirjutas: Le dimanche 11 mars 2012 à 14:29 +0200, Sander Lepik a écrit : 11.03.2012 14:21, Michael Scherer kirjutas: Le samedi 10 mars 2012 à 10:26 +0100, Thierry Vignaud a écrit : Hi please let in xonotic-0.6.0 It's just a game that impacts nothing else. Niet. That's bugfix or security fixes. Honestly, WTF?! It's a new package. According to sophie it's not a new package: http://sophie.zarb.org/rpms/810fca5bd939c8e4a6858a5711c5200f Yeah, i take some of my words back. But there is another problem - 0.6.0 seems to be in mdv2010.2. So upgrade path from Mandriva is broken. -- Sander
Re: [Mageia-dev] Mageia 2 Beta 2 is available
16.03.2012 03:07, tux99-...@uridium.org kirjutas: On Thu, 15 Mar 2012, Anne nicolas wrote: Hi there Beta 2 is available now for tests. Here is the announcement: http://blog.mageia.org/en/2012/03/15/mageia-2-beta-2-near-the-goal/ We need your tests and reports more than ever! Hi Anne, I gave feedback with regards to serious issues when trying beta 1 on a Cedarview Atom system, but apart from a couple of isolated replies (thanks to those who did reply) that unfortunately didn't solve the issues I got no further interest. And the bug number is? -- Sander
Re: [Mageia-dev] Mageia 2 Beta 2 is available
16.03.2012 12:56, tux99-...@uridium.org kirjutas: On Fri, 16 Mar 2012, Sander Lepik wrote: 16.03.2012 03:07, tux99-...@uridium.org kirjutas: On Thu, 15 Mar 2012, Anne nicolas wrote: Hi there Beta 2 is available now for tests. Here is the announcement: http://blog.mageia.org/en/2012/03/15/mageia-2-beta-2-near-the-goal/ We need your tests and reports more than ever! Hi Anne, I gave feedback with regards to serious issues when trying beta 1 on a Cedarview Atom system, but apart from a couple of isolated replies (thanks to those who did reply) that unfortunately didn't solve the issues I got no further interest. And the bug number is? Does your post mean you looked at the info I provided in the previous emails and you concluded that I'm hitting a bug? Well, if it doesn't work for you out-of-the-box then yes, AFAIK you are hitting some kind of bug. It's bug at least for you. And you should report it so we can track it. Complaining in the list has no use here. You can't assign thread to some packager. If it comes out that it's not bug but some kind of other problem then there is solution for that - it's called RESOLVED - INVALID. ;) -- Sander
Re: [Mageia-dev] Firefox 11?
17.03.2012 10:32, Robert Fox kirjutas: Just wondering whether Firefox 11 is going to make it into Mageia 2 . . . Thx, R.Fox Nop, as already discussed quite a few times, we are using ESR from fx10 on. -- Sander
Re: [Mageia-dev] freez push clamav-0.97.4
On Mar 24, 2012 9:13 PM, Thomas Spuhler tho...@btspuhler.com wrote: please push clamav-0.97.4 -- Best regards Thomas Spuhler Why? -- Sander
Re: [Mageia-dev] libgphoto version: freeze buster?
26.03.2012 16:20, Colin Guthrie kirjutas: 'Twas brillig, and Colin Guthrie at 25/03/12 18:06 did gyre and gimble: I've built the package locally and it builds without any issues or complications. Thoughts? Any one have thoughts on this? I'd like to close the bug as wontfix or push the new version (which ever has the most consensus here!) Col Looking at the changes and then at whatrequires libgphoto2 then i would say this is a perfect candidate for backport but we still don't have them. So probably wontfix or wait another month and a half when cauldron is again open and we can push new versions :) -- Sander
Re: [Mageia-dev] Removal of sun java
30.03.2012 17:04, Thierry Vignaud kirjutas: On 30 March 2012 16:00, nicolas vigierbo...@mars-attacks.org wrote: Assuming we do not want to abandon them, what do we do? I'd suggest shipping a new empty package that replaces it with a README.urpmi telling them to go to Sun directly is the most responsible thing for us to do. If they do not have a JRE installed, and they have packages that require one, then they should be prompted to install e.g. openjdk to satisfy package deps. That should work OK right? I think an empty package is not a good idea, it would be better to obsolete it in task-obsolete : - it's more clear that the package is obsoleted and is not a regular update. Users installing an empty package as update would only see that it is removed but not updated when it's already removed. - package is really removed and no longer listed as installed in rpm database - it's easy to add task-obsolete in urpmi skip.list for people who don't want unmaintained packages to be automatically removed In that case, I don't think so. We can thus popup a README.urpmi explaining what happened. Also user can find out this when running rpm -ql java-sun-foobar We can obsolete it in mga2 and create an empty package for mga 1, explaining what's happening. So in mga2 we get rid of it and in mga1 people are warned that it's now removed because of its security issues. -- Sander
Re: [Mageia-dev] noarch packages containing binaries should be rejected
02.04.2012 12:04, Kamil Rytarowski kirjutas: Please make arch-independent-package-contains-binary-or-object a reason to reject packages at upload time: swell-foop.noarch: W: arch-independent-package-contains-binary-or-object /usr/bin/swell-foop Thanks +1 But then we have got again 32-bit software marked as noarch (Skype,..). And people seem too lazy to add 1 simple source for it.. Since when does get-skype contain such objects or any binary? get-skype won't trigger such warning so i see no problem here. -- Sander
[Mageia-dev] X + nvidia( + KDE kwin) = major memory leak
For me this combination is causing pretty huge memory leak in X. At the same time xrestop doesn't show anything. Anssi updated Nvidia's driver to the latest but this doesn't seem to help much. So my question is: am i the only one or are there other people seeing this too? It only seems to happen with nvidia cards. In 3 days my X was using 700+ MB of memory.. -- Sander
Re: [Mageia-dev] painful discussion n°1: debloating
07.04.2012 19:18, Thomas Spuhler kirjutas: On Saturday, April 07, 2012 08:38:39 AM Guillaume Rousse wrote: To summarize it: - has anyone any opposition to remove the totem-mozilla - KDE relationship in the installer ? I'd go for this. I'm not so sure about that. Are there any other alternatives for that? Firefox may be gtk app but most people still use it under KDE too. If you remove those plugins then i would say usability will be hit. -- Sander
Re: [Mageia-dev] [changelog] [RPM] 1 core/updates_testing kdiff3-0.9.96-1.mga1
08.04.2012 18:41, shlomif kirjutas: Name: kdiff3 Relocations: (not relocatable) Version : 0.9.96Vendor: Mageia.Org Release : 1.mga1Build Date: Sun Apr 8 17:37:51 2012 [...] shlomifshlomif 0.9.96-1.mga1: + Revision: 229718 - Merge from cauldron. Merge what or why? -- Sander
