Re: [Mageia-dev] Polish Translation
On 20 September 2010 01:58, Adrian Marcinkowski amfidi...@gmail.com wrote: Someone posted this link to a Polish translation of the announcement: http://invteam.pl/mageia/ Yes, I'm sorry. I'm not really used to mailing lists and I'm still learning how to use them. I hope I will not make such mistakes in the future. As Colin said, nothing to apologize for, you did the hard/more-important part, which is translating the announcement :) ___ Mageia-dev mailing list Mageia-dev@mageia.org https://www.mageia.org/mailman/listinfo/mageia-dev -- Ahmad Samir ___ Mageia-dev mailing list Mageia-dev@mageia.org https://www.mageia.org/mailman/listinfo/mageia-dev
Re: [Mageia-dev] Small Mandriva problems to go thinking before Mageia Development begins
2010/9/24 André Machado afmach...@dcemail.com: Some things that I noticed with Mandriva what shoud be fixed in Mageia. If you know others, add to list. Let's make a pre-buglist ;) 1. Since Mandriva 2010.0, there is a strange problem with BR-ABNT layout keyboards: when you press the , key at numpad, system prints a . instead. I've report this bug at Mandriva's Bugzilla but don't know if it was fully fixed. Other current distros are afected too. Ubuntu is one what is not. Fixed AFAICS: https://qa.mandriva.com/show_bug.cgi?id=51587 2. For an unknow reason, when installing Mandriva on Virtualbox, installer takes a long time to install GRUB boot manager. On a real machine, this doesn' occurs. Please investigate. I've seen that behaviour before too, might be a good idea opening a bug report (in the new Mageia bugzilla when it's up) if the bug still exists. 3. When updating a kernel, all installed kernels are listed on GRUB screen. This is right, but can confuse some users. We should show only the last installed kernel and a menu item that leads to other menu with all other installed kernels. Reguards. In principal it's good, but I don't know if the current gfxboot supports that. (again open a report in the new bugzilla when it's up). You'd better keep a track of this email (discussing such bugs now might mean they'll get lost before a bugzilla is even open :)). _ Washington DC's Largest FREE Email service. --- http://www.DCemail.com --- A Washington Online Community Member --- http://www.DCpages.com ___ Mageia-dev mailing list Mageia-dev@mageia.org https://www.mageia.org/mailman/listinfo/mageia-dev -- Ahmad Samir ___ Mageia-dev mailing list Mageia-dev@mageia.org https://www.mageia.org/mailman/listinfo/mageia-dev
Re: [Mageia-dev] Will this work for a build system?
On 27 September 2010 12:12, Frank Loewe lo...@dotcom-service.net wrote: What about virtualization? Maybe we could set-up some kind of cluster of remote and dedicated vm's as a unique build system. Could be a good workaround over security and integrity issues, 'cause we are using a single build system. That is the thing SuSE OBS does. The System which builds the package is a VM on a XEN Host, which is generated automatically from a defined Image, every time and for every package. So it is clear, that the package is built on a clean system with the right OS and Patch level. -- Mit freundlichem Gruß Frank Loewe Please don't send HTML emails to mailing lists; plain text emails are preferred. -- Ahmad Samir ___ Mageia-dev mailing list Mageia-dev@mageia.org https://www.mageia.org/mailman/listinfo/mageia-dev
Re: [Mageia-dev] So?
On 28 September 2010 20:20, Matheus Santana matheussl...@yahoo.com.br wrote: Sorry but, how much time we will still taken to discuss this things and dont do just nothing? I propose to we chose a manager for the project right now. Regards, Matheus Well, first of all, who said nothing was happening?? the association is being prepared to become a legal entity in France. The infrastructure bits an pieces are coming together; actually the French guys are doing all the heavy lifting/on-the-ground-grunt-work. You can expect more formal news/details soon. P.S. Please don't send HTML emails to mailing lists; plain text emails are preferred. -- Ahmad Samir ___ Mageia-dev mailing list Mageia-dev@mageia.org https://www.mageia.org/mailman/listinfo/mageia-dev
Re: [Mageia-dev] What do you think about create a Mageia Welcome Center?
On 29 September 2010 19:50, Gustavo Giampaoli giampaoli.gust...@gmail.com wrote: Maybe firts, you should decide what would the Welcome Center do. I mean, Kaptan is a configuration tool. Display links is more a kind of information page. So, the Welcome Center should be an info page, or a full featured tool that can set most common things for newbies? Personally, I like the Kaptan idea. Don't know if it's possible to port it to Mageia from developers' POV. Cheers! Gustavo Giampaoli (aka tavillo1980) One question though, kaptan works only with KDE? what about other DE's? -- Ahmad Samir ___ Mageia-dev mailing list Mageia-dev@mageia.org https://www.mageia.org/mailman/listinfo/mageia-dev
Re: [Mageia-dev] A new office suite ?
On 29 September 2010 21:57, Michael Scherer m...@zarb.org wrote: Le jeudi 30 septembre 2010 à 06:43 +1300, Graham Lauder a écrit : On Thursday 30 Sep 2010 05:42:48 André Salaün wrote: OpenOffice or LibreOffice for Mageia ? http://www.documentfoundation.org/lists/announce/msg0.html http://www.documentfoundation.org/ Any decision will depend on timing, ie: Where LibreOffice is when a Mageia build is avaialble. we can have both packages :) -- Michael Scherer Nooo! unless you want the guy maintaining the go-oo/libreoffice packages to commit suicide :) (Imagine having two bears running loose :)). -- Ahmad Samir ___ Mageia-dev mailing list Mageia-dev@mageia.org https://www.mageia.org/mailman/listinfo/mageia-dev
Re: [Mageia-dev] How will be the realese cycle?
On 2 October 2010 14:50, Jérôme Martin mag...@delaur.net wrote: Le vendredi 1 octobre 2010, Olivier Méjean a écrit : Le vendredi 1 octobre 2010 08:51:34, atilla ontas a écrit : What's your opinion? What about a rolling distribution ? As an user (just plain user) i do not think that installing a distribution is a goal, just a mean to use my computer, so i wish i could not spend time installing a distribution every 6 months or every year. My opinion is nearly the same: what is the need to provide a new version each 6 months? The marketing point of view is not a valid answer since we do not need to satsify shareholders or follow the market. Yes, but you have a distro to maintain, a reputation to uphold... So when a new version is needed? My point of view is that a new version is needed when a big change will occur for exemple a new major release of KDE or gnome, Xorg, perl, python, jdk, ... We need to change our view. Actually, the date of the release is decide and the deciders (maketting, CEO, CTO, ?) choose which softwares will be include. I propose to look at release date of the main softwares and decide when a new version will be proposed. Hmm, no, IINM, that would be the release engineers job. For smaller software, we do not need to wait for a new version of the distro. Just provide it as we do with the backport repository. New version = new features + new bugs; anyone who ran cooker for a good amount of time have witnessed this fact And no, rolling distro does mean use cauldron, since the system is not supposed to work properly and where critical breakage can appear. Ah, yes, so you want a rolling release, just like Cauldron will be, but that's not broken; now how should one go about guaranteeing that this will actually work out OK? A rolling distro means double work for the devs and packagers as a new version may just introduce new bugs too, now they don't provide the new versions in a controlled development release where you're warned that this is a development release not suitable for day-to-day production machines, or in a unsupported backports repo, no, it'll just go to the stable release too. Now don't only think about a Mageia installation on a personal computer, where even if the system is totally hosed you can easily do a new install or restore a backup (then update to latest), but you also have to bear in mind users who have servers doing all sorts of jobs, they want stability over new-shiny-versions; the same goes for school/university labs... etc. -- Ahmad Samir
Re: [Mageia-dev] About Mandriva tools future : Host Mandriva tools on github
On 2 October 2010 21:50, Fabrice Facorat fabrice.faco...@gmail.com wrote: Le 2 octobre 2010 17:52, Nicolas Lécureuil neoclust.mag...@gmail.com a écrit : 2010/10/2 Fabrice Facorat fabrice.faco...@gmail.com 2010/10/1 Sinner from the Prairy sinnerb...@gmail.com: Fabrice Facorat wrote: Mandriva tries that, with look'n'feel consistent on MCC, KDE and Gnome. draketools work on TUI or GUI. They work well. some tools does not work correctly however and are buggy Better is to fix them instead of rewrite all. you know, when something have been broken for more than 2 years ... at some point you may think that the best would be to just change it ;-) -- Close the World, Open the Net http://www.linux-wizard.net Specifying what exactly is wrong is an essential issue here: - Just perl is hard to understand isn't a problem for users, users don't code it. - Not being used by other distros is again not a problem, each distro has native tools that no other distros use (as misc said a couple of emails up) So, no, I wouldn't throw my old box out the window because if it works even if it's slow, until I buy a new box / can afford a new box. drakxtools work, until a viable alternative, if needed at all, is provided they should be kept. -- Ahmad Samir
Re: [Mageia-dev] Talk of Browsers
On 3 October 2010 20:19, Richard Walker richard.j.wal...@ntlworld.com wrote: But are we always knowledgeable enough to be able to set up the system to use our choice? I confess to being a Mandriva Linux user for only 10 years but I have been an Opera user (and purchaser) for a year or two before that. I ALWAYS have difficulty when removing Firefox and replacing it with Opera as I can NEVER find all of the nooks and crannies of the system and various software packages which presume that Firefox must be available. I would be much happier to discover that a distribution had taken my choices seriously enough to check with me during the install and then make sure that my choice is properly and fully integrated. Then perhaps we could highlight applications which expect no other browser than Firefox and proceed to educate their authors/packagers as to the importance of user choices. Majority of users do not want choice. OK, that may be true, but when one of that majority decides to broaden the horizons of their browsing experience then will they magically be learned enough to be able to fix all of the integration issues for themselves? I suspect not. An install time selector screen and supporting scripts would be a very good starting point for a Change Default Browser wizard, much as XFDrake tries to hide the complexities of switching video drivers. Richard The point is, such scripts break all the time. e.g. chromium-browser has a make chrome the default browser button, the problem is, it works only under GNOME, but doesn't work under KDE4 or XFCE. It's using a variant of the xdg-utils scripts... xdg-utils is trying to do the huge job of working with all possible desktop environments, this is, by its very nature, a hard thing to accomplish. Firefox also has a make firefox the default web browser, again it works only with GTK/GConf based applications, but it doesn't change KDE settings. If upstream can't accomplish this in their apps, how do you expect downstream to do it? -- Ahmad Samir
Re: [Mageia-dev] Talk of Browsers
On 5 October 2010 04:43, Hoyt Duff hoytd...@gmail.com wrote: On Mon, Oct 4, 2010 at 10:15 PM, Ahmad Samir ahmadsamir3...@gmail.com wrote: If upstream can't accomplish this in their apps, how do you expect downstream to do it? Easy. Both upstream and downstream should obey the $BROWSER environment variable. Yeah, should :) Then you should file a bug report if you encounter non-support of $BROWSER, correct? -- Hoyt Sure, if I can dive in each browser and DE way of setting a default browser. Personally I can't get my head fully around it up till now. -- Ahmad Samir
Re: [Mageia-dev] How will be the realese cycle?
On 5 October 2010 15:56, Tux99 tux99-...@uridium.org wrote: Quote: Ahmad Samir wrote on Tue, 05 October 2010 15:47 Again a rolling distro is something that's not clearly defined. And to be honest, a rolling distro isn't suitable for new or inexperienced users. Simply because you can't guarantee that a new package won't introduce regressions (or totally break an app), in this case an experienced user will know how to revert to an older version, a new or inexperienced user won't. I don't think you really read or understood my proposal. I'm not talking about a real rolling distro like Gentoo, I'm only talking about foregoing backported security fixes for newer versions with regards to apps that don't have anything depending on them. Which, if you read the umpteen emails up there :), can and will introduce new fixes/features and also new regressions, I don't think any QA team can handle such kind of flow all year long. Mandriva already does that with very few apps (like Firefox), I'm just proposing to extend that to more apps where it can be done safely. That's *one* app, and a sort of a special case, and when updating firefox, it's not just one package, sec. team has to update the localisation packages, new libnss, new libnspr... etc, as a new firefox version requires newer libs sometimes. A backported security fix can introduce as much regressions or instability (IMHO actually more, because it's essentially a fork so less tested)than upgrading to a new version. Not really, I think a sec. fix/patch has much less chances of breaking an app than a whole new version. Of course it's up to the packager to use good judgement, if the new version of a particular app is a complete rewrite, then it might not be safe to provide the new version, but there are many case where it is perfectly safe and beneficial for the user. Look at the rolling distros that've been mentioned, Debian or Gentoo, right? would anyone recommend Debian or Gentoo for a new/inexperienced/non-power user? Sorry, but that comparison is nonsense, Debian and even mre so Gentoo are not suite for novices for many reasons, not because they are rolling distros. No, it isn't nonsense (not just because I posted it :)); Cooker/Cauldron is the same, it _is_not_ for new/inexperienced users, too much work, you have to figure out when to update / skip an update, how to revert to an older package to get a working system again... etc. Read cooker ML archives, many examples on this. -- Ahmad Samir
Re: [Mageia-dev] How will be the realese cycle?
On 5 October 2010 18:54, Tux99 tux99-...@uridium.org wrote: Quote: Ahmad Samir wrote on Tue, 05 October 2010 17:41 A rolling distro isn't a defined term, as Michael explained, now you add light to the equation and it becomes even more undefined. You shouldn't look at the name but rather at the description that me and others have given here earlier. I looked at the description that Michael gave. And I think I know what a rolling distro is having Cooker and all :). light/heavy makes no sense here. I said all I got to say on this topic, now I can wait and see how things turn out (my guess would be it'll stay the same, Cauldron a rolling/dev distro, and stable releases on predefined intervals, just my personal guess). I guess that depends mostly on what the packagers will feel like doing, ultimately in a community distro nobody can be force anyone to do anything, if too few people are doing security fix backports but most are doing version backports then we will have this 'light' rolling distro (or whatever you want to call it), if not then we will have the old mdv model. It's not I'll-work-my-own-way-and-do-what-I-want, any packager can do so in his own repo/distro. There'll be rules which should be followed even in a community-driven distro, otherwise it'll be chaos. -- Ahmad Samir
Re: [Mageia-dev] How will be the realese cycle?
On 6 October 2010 05:02, Fernando Parra gato2...@yahoo.com.mx wrote: On Tue, 5 Oct 2010 15:47:20 +0200 Ahmad Samir ahmadsamir3891-re5jqeeqqe8avxtiumw...@public.gmane.org wrote: On 5 October 2010 15:28, Tux99 tux99-mga-ju+53dptyrfafugrpc6...@public.gmane.org wrote: Personally I think the way Mandriva maintains both updates and backports for each release is a waste of resources. How is it a waste? A practical example is the college professor / school teacher (see Fernando Parra post a few emails back); he doesn't want to upgrade the boxes in the lab, he doesn't care if they have the newest/shiniest versions, just that the distro is stable and works(tm). The same applies for a company, servers... etc. We aren't talking only about personal boxes that can break without too much drastic consequences. Please don't write words in my name, I never wrote something like that, security and stability are as important to as for an any other user, but I need the latest version of some programs, without upgrade all the distro every 6 months. I didn't mean to put words in your mouth; I wasn't talking about you in particular but about school/university computer labs case in general. And what I posted doesn't contradict I need the latest version of some programs, without upgrade all the distro every 6 months.; I am pro backports repos (when possible), but not a rolling distro model. -- Ahmad Samir
Re: [Mageia-dev] Talk of Browsers
On 7 October 2010 02:20, Kira elegant.pega...@gmail.com wrote: 在 Thu, 07 Oct 2010 07:59:52 +0800, Marc Paré m...@marcpare.com寫道: I am not sure anymore, but I thought I had read somewhere that Mageia would be a KDE-centric distro à la Mandriva, but still offer Gnome etc. if the user wished to install it. Someone? Marc Never heard about it. Is it someone wrongly take Mageia as Mandriva? Me too, I never heard anyone saying Mageia will be kde4-centric. IMHO, even for kde4 Konqueror shouldn't be the default web browser, it has a lot of quirks. Experienced users who want to use anything other than the defaults do so all the time; the defaults only apply for new users (until they gain enough experience and start customising too). -- Ahmad Samir
Re: [Mageia-dev] How will be the realese cycle?
On 7 October 2010 02:24, andré and...@laposte.net wrote: Ahmad Samir a écrit : On 2 October 2010 14:50, Jérôme Martinmag...@delaur.net wrote: Le vendredi 1 octobre 2010, Olivier Méjean a écrit : Le vendredi 1 octobre 2010 08:51:34, atilla ontas a écrit : What's your opinion? What about a rolling distribution ? As an user (just plain user) i do not think that installing a distribution is a goal, just a mean to use my computer, so i wish i could not spend time installing a distribution every 6 months or every year. Please pay attention when quoting, I didn't say any of those things above ^. -- Ahmad Samir
Re: [Mageia-dev] How will be the realese cycle?
On 7 October 2010 03:59, andré and...@laposte.net wrote: Ahmad Samir a écrit : On 6 October 2010 05:02, Fernando Parragato2...@yahoo.com.mx wrote: On Tue, 5 Oct 2010 15:47:20 +0200 Ahmad Samirahmadsamir3891-re5jqeeqqe8avxtiumw...@public.gmane.org wrote: On 5 October 2010 15:28, Tux99tux99-mga-ju+53dptyrfafugrpc6...@public.gmane.org wrote: Personally I think the way Mandriva maintains both updates and backports for each release is a waste of resources. How is it a waste? A practical example is the college professor / school teacher (see Fernando Parra post a few emails back); he doesn't want to upgrade the boxes in the lab, he doesn't care if they have the newest/shiniest versions, just that the distro is stable and works(tm). The same applies for a company, servers... etc. We aren't talking only about personal boxes that can break without too much drastic consequences. Please don't write words in my name, I never wrote something like that, security and stability are as important to as for an any other user, but I need the latest version of some programs, without upgrade all the distro every 6 months. I didn't mean to put words in your mouth; I wasn't talking about you in particular but about school/university computer labs case in general. And what I posted doesn't contradict I need the latest version of some programs, without upgrade all the distro every 6 months.; I am pro backports repos (when possible), but not a rolling distro model. Exactly, Fernando, you can install the distro release every 12, 18 or 24 months if you wish. Just ensure to make security and other bug fixes on a regular basis, and any backports and other updates you would like, in the interim. Stable distro releases every 6 months will make Mageia more stable than a rolling distro, with less effort. - André (andre999) Strike two, please pay close attention when quoting replying to quote the right person... -- Ahmad Samir
Re: [Mageia-dev] Talk of Browsers
On 7 October 2010 07:19, Kira elegant.pega...@gmail.com wrote: 在 Thu, 07 Oct 2010 13:14:46 +0800, Ahmad Samir ahmadsamir3...@gmail.com寫道: IMHO, even for kde4 Konqueror shouldn't be the default web browser, it has a lot of quirks. Experienced users who want to use anything other than the defaults do so all the time; the defaults only apply for new users (until they gain enough experience and start customising too). Might be my prejudice, but Konqueror don't fit into daily usage, after all in the default setting there's Firefox as default browser and Konqueror lacks certain functionality which makes it hard to use. May be remove it from the default set the KDE4 installation set? No, konqueror is still useful as a file manager (some users don't like dolphin for some reason), also as a man pages viewer. Also it shares some code with dolphin (some stuff/features don't work in dolphin if konqueror isn't installed). -- Ahmad Samir
Re: [Mageia-dev] Talk of Browsers
On 7 October 2010 13:10, Michael Scherer m...@zarb.org wrote: Le mercredi 06 octobre 2010 à 23:18 -0400, Sorteal a écrit : On Thu, 2010-10-07 at 04:01 +0200, Wolfgang Bornath wrote: 2010/10/7 Marc Paré m...@marcpare.com: I guess this information would have to come from someone from the core dev group. Just so that we know for sure. So, is Mageia going to be principally a KDE distro with offers during installation to install GNOME and other desktops? Or is it going to be a desktop agnostic distro where the user eventually picks the desktop sometime during the installation processs? This may help with this thread on the talk of browsers. Pls correct me if I'm wrong but I don't know any browser which is DE dependent - well, there's konqueror, if you want to call this I want to be everything a browser. But for real browsers, what does it matter which DE is used? While Mandriva officially supported both GNOME and KDE, I do remember the last time I tried the GNOME version of Mandriva it was pretty much a raw GNOME install. Yeah, that's in fact a feature. GNOME was manager by Frederic Crozat, who is a gnome developer, so he followed quite closely gnome decisions. And KDE was managed by whom? all the Mandriva KDE team were/are KDE developers. It's just different packaging philosophies, KDE guys like to customize stuff (that's a bit generalising); while GNOME guys didn't (note that the whole GNOME philosophy is conservative, e.g. in the options in provides in GUI). Both philosophies had its pros and cons. One big advantage of sticking as close to upstream as possible is that GNOME team in mdv eased their maintenance burdens, which is logical as they weren't that many and were always overworked (note that fcrozat, for example, didn't just maintain only GNOME, but many other aspects of the distro too, including a good number of core stuff). Some people may argue that a distro is here to enhance software, but the first goal is to distribute. And since everybody think distro should collaborate more, pushing upstream is exactly this kind of collaboration. -- Michael Scherer -- Ahmad Samir
Re: [Mageia-dev] Talk of Browsers
On 7 October 2010 13:50, Oliver Burger oliver@googlemail.com wrote: Marc Paré m...@marcpare.com schrieb am 2010-10-07 Thanks. That makes sense. Sorry, I was still thinking the Mandriva corporate way. So, we are pretty well left at the mercy of the devs interest with this regard. (I don't mean to sound negative, but more realist in saying this.) Do you know, out of interest, if there are more KDE or Gnome devs interested in the Mageia project or if this is till too early to tell? Looking into the wiki: http://www.mageia.org/wiki/doku.php?id=packaging#list_of_categories there are more packagers interested in KDE thean the others. Actually there's not a single packager interested in GNOME which I think is a pitty. Although I do prefer KDE, I'm using apps from all DEs. I don't see any reason, not to use some app just because it is from another DE I hope there will be someone taking over GNOME. (after all I am the guy building the Ubuntu-netbook-launcher for the German Mandriva community repo because I do really like the launcher). Götz Waschk said he'll package for Mageia, it just seems he doesn't care about putting his names in lists :) -- Ahmad Samir
Re: [Mageia-dev] How will be the realese cycle?
On 7 October 2010 15:08, Gustavo Giampaoli giampaoli.gust...@gmail.com wrote: It has been posted before but I guess it's a good read for anyone willing to push an argument in this debate: http://mairin.wordpress.com/2010/09/01/a-story-about-updates-and-people/ Really excellent article. I enjoyed reading it because it's based on people-from-real-life. Even when I'm not developer nor advanced user, I know I'm above basic users. And sometimes I (and I guess most of us) forget that most people are like our moms or our sisters (not moms that are software engineer X). People who only read their hotmail mail, use messenger, facebook, tweeter, listen some MP3, write a doc for school. So, I agree we must bring some order to this storm. Cheers! Gustavo Giampaoli (aka tavillo1980) You keep omitting who you're quoting from the top of your replies... (the part that should look like On 7 October 2010 15:08, Gustavo Giampaoli giampaoli.gust...@gmail.com wrote: above). -- Ahmad Samir
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
On 12 October 2010 17:53, Olivier Méjean omej...@yahoo.fr wrote: Le mardi 12 octobre 2010 17:02:38, Anssi Hannula a écrit : Hi all! == What about patents? Software Patents are allowed or not according to the country. Here in France, where Mageia.org, the association is based, the rule is softwares are not eligible to patent so i would say that there is no need to apply restriction == And DVDCSS, etc? What's in etc ? However, here in France we have a law Dadvsi on which the Conseil Constitutionnel (something like American Suprem Court) has statuted that the law could not prevent exception of decompilation and the exception of circumvention of DRM if this is for interoperability. In other words the use of libdvdcss is allowed for interoperability. So for me, Mageia can come with libdvdcss and other tools for interoperability About codec, you may know that VLC is based in France and hosts some projects useful for interoperability. Since the start of the project in 1996, i don't remember VLC being sued for such projects. So let's provide codec by default with Mageia for a better user experience :) These are my first comments Olivier Mageia won't be installed only in France; those patents still apply in other countries so not all patent restrictions can be dropped. -- Ahmad Samir
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
On 12 October 2010 18:11, Olivier Méjean omej...@yahoo.fr wrote: Le mardi 12 octobre 2010 18:07:08, Ahmad Samir a écrit : On 12 October 2010 17:53, Olivier Méjean omej...@yahoo.fr wrote: Le mardi 12 octobre 2010 17:02:38, Anssi Hannula a écrit : Hi all! == What about patents? Software Patents are allowed or not according to the country. Here in France, where Mageia.org, the association is based, the rule is softwares are not eligible to patent so i would say that there is no need to apply restriction == And DVDCSS, etc? What's in etc ? However, here in France we have a law Dadvsi on which the Conseil Constitutionnel (something like American Suprem Court) has statuted that the law could not prevent exception of decompilation and the exception of circumvention of DRM if this is for interoperability. In other words the use of libdvdcss is allowed for interoperability. So for me, Mageia can come with libdvdcss and other tools for interoperability About codec, you may know that VLC is based in France and hosts some projects useful for interoperability. Since the start of the project in 1996, i don't remember VLC being sued for such projects. So let's provide codec by default with Mageia for a better user experience :) These are my first comments Olivier Mageia won't be installed only in France; those patents still apply in other countries so not all patent restrictions can be dropped. And going that way you will have to drop each software that will break a law in a country ... Olivier I said not all patent restrictions can be dropped; it's not a lift-all-restrictions-and-hope-it-works-out sort of deal here :) Not all patents are enforceable in a court of law, however some of them are. -- Ahmad Samir
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
On 13 October 2010 15:34, Olivier Méjean omej...@yahoo.fr wrote: Le mercredi 13 octobre 2010 10:19:17, Buchan Milne a écrit : On Tuesday, 12 October 2010 17:52:58 Tux99 wrote: Quote: marc wrote on Tue, 12 October 2010 18:42 Unfortunately, if this is done, I will no longer be able to install legally any Mageia due to our laws. I think it is best if these are not installed but let users know where to get them, mostly through PLF. How do you expect Mageia to verify each single package to make sure it complies with the laws in ALL countries of the world? So, because we can't comply with all laws in all coutnries, we should violate everyone we possibly can? Because we can't be aware of all laws in all countries, we should do nothing ? (after all that's the best way to break no law at all !) Mageia should make sure that the packages comply with French law, but that's it. If Mageia wants mirrors in countries with strong IP protection laws (including copyright, software patent) and anti-circumvention laws, then IMHO, there does need to be a split, so mirror maintainers can decide which risks they can accept. For example, in the DMCA case, I believe US mirrors hosting libdvdcss could be vulnerable. There are mirrors of plf in USA, there is at least one mirror of ArchLinux in USA that provides libdvdcss, there is at least one mirror of Linux Mint in the USA that provides libdvdcss, there is PCLinuxOS based in USA (Texas ?) that provides libdvdcss VLC is available in USA to download (cnet.com) and VLC provides its own lib for decoding (and coding) multimedia files (and from what i know, windows binaries come with libdvdcss) There's a difference between they can't be sued out of their homes and they can be sued, just no one's done it yet. As with any legal issues, it's always a CYA situation. You can still install Mageia and then remove the packages that are problematic in your country, I very much doubt your laws are that draconian that you can't even do that. Mageia could include an option during install to exclude the well-known problematic packages from installation to make this easier for people that live in countries with restrictive laws. When I install Mandriva Free for people, I will let them know where the PLF repos are and the files needed and they install these themselves. This is a major hassle for new/inexperienced users and IMHO should be avoided. Maybe it can be improved *to some extent*, by asking the user if they want to add additional repositories. We cannot ask users to add third-part repos. We have discussing about Mageia repos, policies of third-part repos should not be in our discussion. If we want to ask users to add 3rd party repos, then 3rd party repos are already a part of this discussion. -- Ahmad Samir
Re: [Mageia-dev] How will be the realese cycle?
On 14 October 2010 15:41, Tux99 tux99-...@uridium.org wrote: Quote: Buchan Milne wrote on Thu, 14 October 2010 15:27 What aspects of the Mandriva backports solution are not satisfactory? -The fact that not everything is available as a backport? Yes, more packages should be available (and as future packager I will do my part to make that happen) Well, backporting a package is a one-liner, so it takes less than minute to be done; that's not the issue. The issue is that a new version of package A may need a new version or package B to work, so package B needs to be backported too; and/or that the new version of A doesn't work with older libs/kernels, so backporting isn't too much time consuming for packagers, but making sure that that backport has a good chance of working(tm) is the bigger burden/responsibility. I've seen, too many times, trigger-happy packagers backporting packages that're not maintained by them (so they know it less than those package maintainer(s)), breaking those packages and annoying the maintainers of said packages. It's usually irresponsible to backport a package without taking that package maintainer's opinion into account. (an infamous example on that is gwibber being backported to 2010.1). -That users don't know how to request a backport? It certainly could help publicizing backports and giving the user an easy way to request specific packages New users who frequented the forums always got to know what backports are pretty fast. And bugzilla is the perfect system for asking for a backport, that worked pretty good. [...] -That users aren't aware of backports? Yes, backports should be promoted better in drakrpm and in the web site. -Something else? backports should be supported for security patches and bug fixes just like the main packages (if not instead of the main packages). Of course the security patch could be simply provided by backporting a newer version of the package, no need to make patches for each version. That's they way backports has always worked, no specific patches, just the latest cooker package pushed to backports as is with no official support, that's reasonable, packagers shouldn't promise to support backports when they can't due to various reasons (time, effort.. etc). The end users need to do less than now for to get new versions of their favourites applications. Less than 'urpmi --searchmedia Backports chromium' ? CLI is not ideal for 'normal' users. rpmdrake has a Backports filter that shows packages from backports repos, that's easy to use even for new users. Or, should it be more obvious in rpmdrake or similar? I think they should be enabled by default, since it's my impression that the majority of 'normal' users wants new versions of apps, those users who DON'T want them can still always disable them. Backports shouldn't be second choice, it should be the default, since that would make Mageia stand out from other distros as being the distro were users get the latest versions of apps before any other major distro provides them. Enabling them by default defies the purpose of having backports at all; it's not for new users, it's more for slightly experienced users or power users who want the latest versions of apps. -- Ahmad Samir
Re: [Mageia-dev] How will be the realese cycle?
On 14 October 2010 16:14, Tux99 tux99-...@uridium.org wrote: Quote: Ahmad Samir wrote on Thu, 14 October 2010 16:00 [] Enabling them by default defies the purpose of having backports at all; it's not for new users, it's more for slightly experienced users or power users who want the latest versions of apps. That's exactly the crucial bit that IMHO needs to change, backports are very interesting for 'normal' users so we should make sure normal users can use them. Don't you see how attractive it is especially for 'normal' users to have access to the latest versions all the time? Sure, not everyone wants them, but by integrating the skip.list in the update GUI we could keep 'conservative' users happy too. Then you're not talking about new users any more... -- Ahmad Samir
Re: [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc
On 14 October 2010 17:04, Anssi Hannula anssi.hann...@iki.fi wrote: On Wednesday 13 October 2010 20:54:45 Dimitrios Glentadakis wrote: About codecs Codeina will be available in Mageia ? I find it very comfortable for new and advanced users. Yes. It is available on Mandriva and I don't see any reason to drop it from Mageia. -- Anssi Hannula But codeina only works with gstreamer based apps IIUC... -- Ahmad Samir
Re: [Mageia-dev] How will be the realese cycle?
On 16 October 2010 17:31, Marc Paré m...@marcpare.com wrote: Le 2010-10-16 02:56, Luca Berra a écrit : On Fri, Oct 15, 2010 at 10:00:14PM -0500, Fernando Parra wrote: The basic/novice user doesn't read anything, remove basic/novice from the sentence and i will agree ;) doesn't request anything to some like a bugzilla, but give him a forum and he probably will This statement I totally agree with! If a user is told to submit in bugzilla, I find that they will not do it. Reporting to bugzilla for a user, is one more level of serious commitment on their part and most will not want to commit themselves to it. However, if they can report to a forum, this is different. Users view forums as community involvement with community feedback. They may be ask to test out the problem and report back on the result (just like in bugzilla) but they know that other community members will be there to lend a hand and support. And other community members are there in bugzilla to to lend a hand and support (although a bit different kind of support as bugzilla's have stricter rules, more organised). If we are going to be really interested in quashing bugs with a lot of community involvement, IMHO, I think that we should offer -- bugzilla for the enthused and commited users. These people are interested on reporting bugs the right way and will replicated and help in debugging. -- but for ordinary users, we could offer them a Report a bug forum where they can report a bug; the community could then replicated the bug; have a Bug-ambassador or bug-reporter or who could then submit it officially on bugzilla. Tracking of that particular bug could then be the responsibility of the Bug-ambassador; once the bug is quashed, the Bug-ambassador could report back to the Report a bug forum of the bug fix and thank the community for their help. This would help validate the user who reported the bug and make him/her feel like a part of the contributing team. IMHO, this would work a lot better for the majority of users who do not want to commit to any more than reporting the bug; the devs would get a more constant stream of bug submissions by Bug-ambassadors who are able to triage submitted bugs on the forum. Doing it this way would still make bugzilla the only place where devs would go to pick up bug information and the Bug-ambassadors would be the people who triage the bugs at the forum level. Marc Backport requests are a special case as they're usually a 2-line report hey, could you backport the latest version of package foo to stable release I am running?, so basically anyone can do it, either the user or someone on his behalf. But generally reporting bugs by proxy is always a bad idea, unless the guy who'll play middle-man can reproduce the exact same bug on his own box. You see, triage team / package maintainer / dev will ask for info about the bug, more than once depending on the bug itself; now Mr. middle-man will have to go to and fro a lot of times, taking info from the user and posting it in bugzilla then taking questions/info from the bugzilla and conveying it to the user; now that's a tedious and tiresome job that's very prone to failure. (it's like a friend being sick and instead of him going to the doctor he sends you on his behalf because you know the symptoms :)). It's much better to help the user formulate a useful bug report, that's easier / more productive for all involved parties. -- Ahmad Samir
Re: [Mageia-dev] How will be the realese cycle?
On 17 October 2010 09:56, David W. Hodgins davidwhodg...@gmail.com wrote: On Sat, 16 Oct 2010 19:15:30 -0400, Fernando Parra gato2...@yahoo.com.mx wrote: Well the ball is on the air. The Mageia Server should be a Rolling Ligth distro, yes or no? The problem I've experienced with the current Mandriva release cycle is with one friend, who has a slow system. It took 13 hours to go from 2010.0 to 2010.1, even though (I'm guessing) the bulk of the files being downloaded were identical (except for the release number, and date of build), to what he already had. The same upgrade only took a couple of hours, on my system. He has a faster internet connection, but a much slower computer. I thought the faster download would be more important than the speed of the system, so I mistakenly gave him a 4 hour guesstimate. A bit off-topic: What took a long time exactly? downloading the package or installing them? I am asking because I upgraded, more than one, virtualbox installs, it never took more than 30min. to install the new packages (that's leaving out the time it took to download them, which has more to do with the download rate what with having a slow/fast system). I'm not a pc developer, so I don't know why things are being done the way they are, but expecting a user to spend half a day updating, every six months (or year), really annoys new users. My background is ibm 370 asm, cobol, pl/1, fortran, mark iv, roscoe, tso, db2, ims dc/db, etc. I know enough c, perl, python, etc., that I can sometimes figure out where the problem is, (when submitting bug reports), but I don't know enough to put together rpm packages, or where to start, to learn how to do so. Regards, Dave Hodgins -- Ahmad Samir
Re: [Mageia-dev] Mirror tree structure
On 22 October 2010 08:11, herman her...@aeronetworks.ca wrote: On Thu, 2010-10-21 at 17:07 -0700, Wolfgang Bornath wrote: 2010/10/22 Olivier Thauvin nanar...@nanardon.zarb.org: In fact we have no way to deny to someone to do a partial mirror. The question is from our point of view, do we encourage people to create non testable mirror or untrusted mirror (not update enough to ensure last security update get sync). Besides that people can put up mirrors in any way they want and use them in any way they want. They are just not listed as official mirrors of Mageia. Everybody was happy, the maintainers of the list, me, and all people who used my mirror (it was not crowded, even at release time). A solution suitable for everybody. So should we have an 'Official mirror list' and an 'Unofficial mirror list'? Because a mirror that is not listed at all, is rather hard to find. I think wobo meant local mirrors, e.g. the mandrivauser.de mirror was mainly used by German users who found out about it from mandrivauser.de forums. (and having a list of unofficial mirrors will be a pain, how would one differentiate unofficial mirrors that just don't mirror some sub-trees, e.g. debug, and unofficial mirrors that are just plain old/don't-get-synced-regularly). -- Ahmad Samir
Re: [Mageia-dev] Suggestion-Locales management for One (or Live) Cd releases
On 25 October 2010 11:16, atilla ontas tarakbu...@gmail.com wrote: I don't know if this proposal is even mentioned before. It's hard to catch in all these posts. I think the main probem with Mandriva One releases was lack of space. It will still a problem for Mageia Live CD releases. Also, it is very cofusing for Mandriva/Mageia newbies to determine which iso image contains their native language support and i'm sure it brings more effort to maintain so many one cd isos and waste of server/mirror space. I propose to implement an Ubuntu like, install time or in live enviroment language packs installing. How this should work? It is obvious which packages included in Live cd. When creating an iso (draklive?) livecd creation tool strips all locale files except english ones and create seperate packages per locale. These packages, ie. mageia-one-kde4-locale-tr includes all locale files corresponding with included apps/packages in mageia-one-kde4.iso. When user boots with live cd (mageia-one?) a dialog appears and asks which locale he/she would use with live environment. Then if it detects internet connection, downloads this mageia-one specific package (mageia-one-kde4-locale-tr.rpm for Turkish locale in mageia-one-kde4) and adds tr locale /etc/rpm/macros file. And if there's no active internet connection at installation time? So, there will be only one live cd image on mirrors per DE, there will be room for apps in live cd iso, people will not confused for localized isos. What do you think? -- Ahmad Samir
Re: [Mageia-dev] maintainer groups
On 25 October 2010 19:44, Michael Scherer m...@zarb.org wrote: Le lundi 25 octobre 2010 à 19:29 +0200, Luca Berra a écrit : this is a suggestion i already made with mandriva but it landed nowhere, let's try again. At the moment we have 1to1 relationship in all tools between maintainer and package. But for some packages we have more than one people willing to work on that package. Besides, for some critical package it may be useful having more than one person responsible for it. Also someone might be interested in helping on package foo, but feels too much inexperienced to take full reponsability for it. Peer review is important. The idea is not associating a package with a single maintainer, but associate each package to a maintainer-group, say n...@packages.mageia.org, and let maintainers subscribe to package maintenance. this would result that in case a ticket is opened in bugzilla vs package, all interested parties would be notified, and start working on a solution. (this might require a bit of coordination, but maybe just assigning the bug to a real person is enough to note someone is taking care of the problem) +1 to the idea. I just wonder how it articulate on bugzilla side ( ie, we should try to avoid having a patch on bugzilla side, as this is usually causing trouble ). Ie, if I want to take care of a bug report, I would likely assign it to me, no ? Wouldn't it better to use cc for that ? -- Michael Scherer Well, if a maintainer changes to status to ASSIGNED, we can assume he's working on it. QA team, lately, had a sort of a rule, when one of them was working on a bug he'd post to the report to say so so as not to duplicate work; the same was with sec team. That's a good way IMHO. -- Ahmad Samir
Re: [Mageia-dev] New mirror -- maybe
On 3 November 2010 22:41, Marc Paré m...@marcpare.com wrote: If I was to approach our local university about mirroring Mageia, would I have to supply them some specs? What would they need to know and who would they have to get into contact with? They are mirroring the Mandriva KDE updates. University of Waterloo. The I don't understand this bit, they're mirroring just the KDE updates? how so? (or do you mean the unofficial repos at ftp.kde.org?) university just announced last week that their fundraising for the year was worth 600 million $$$Cdn. Maybe they could afford a little server space. Marc -- Ahmad Samir
Re: [Mageia-dev] sync with mandriva
On 8 November 2010 13:41, Bruno Cornec bruno.cor...@hp.com wrote: Michael Scherer said on Mon, Nov 08, 2010 at 12:37:44PM +0100: Le lundi 08 novembre 2010 à 12:11 +0100, Bruno Cornec a écrit : Michael Scherer said on Mon, Nov 08, 2010 at 12:04:25PM +0100: separated svn for tarball. What does it bring ? compared to current situation, it allow us to clean it more easily the tarball from svn. The goal was to prevent endless growth of the repository. I understand that point, but not the reason to put at all the tar in SVN. Well, a flat or a directory like structure for perf reason, yes. But it was discussed some years ago on maintainers@, and so I think this was raised as well, except that I do not remind the outcome. Spuk did the work, so you need to ask him. Well, I thought that a new distro could afford discussing again some of the choices that have prooved to be problematic in the past thus my msg. I'm not sure that history is so important that opinion of people who will manage that in the future. IIUC, history in this contest means the reasoning behind rejecting/accepting it, i.e. instead of doing the research from scratch we can take it from where it ended the last time it was discussed and re-evaluate the pros and cons. Bruno. -- Open Source Linux Profession Lead EMEA / http://opensource.hp.com HP/Intel/Red Hat Open Source Solutions Initiative / http://www.hpintelco.net http://www.HyPer-Linux.org http://mondorescue.org http://project-builder.org La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- Ahmad Samir
Re: [Mageia-dev] Mirror layout, round two
On 27 November 2010 08:27, Andrey Borzenkov arvidj...@gmail.com wrote: On Fri, Nov 26, 2010 at 11:29 PM, Thomas Backlund t...@iki.fi wrote: The idea of this layout with some of the separate sections (codecs, firmware, games, non-free, debug_*) gives a mirror maintainer in a country (or company) the option to exclude the parts they legally (or by company policy) can not mirror. I wonder how urpmi.addmedia --distrib ftp://server/with/omitted/sections; should be interpreted then. Also mirror list should be indicating which sections are present; is it supported right now? IMHO, the mirrorlist in its current status should be dropped altogether... it's only good if the user has good mirrors near where he lives, otherwise it just fails miserably. The whole point of using a mirrorlist was that urpmi will switch to another mirror if the currently used one fails / can't be reached, that switch doesn't happen, (md5sum mismatch rings a bell?). At least with the specific media mirrors the user can, more easily, guess that he can use add another mirror, with mirrorlist most new users are left clueless. -- Ahmad Samir
Re: [Mageia-dev] Mirror layout, round two
versions. The same goes for firefox. Overly restrictive compatibility specification is a very a common error in Mozilla extension packaging. (It's mentioned in their development guides.) But the rpm packager should be knowledgable enough to recognize it. But such errors do happen. Read above. So in sum, this was probably only a packaging problem. Whatever the repository. No. Not at all. The problem is linked to the difference of support between main and contribs. In this case, it is inappropriate packaging. Other cases could be a difference of support. There is no reason that extensions should ever block the upgrade of Thunderbird, unless when one passes from one major version to another. In that case, the extension will have to be rewritten, a development function. (That has only happened a few times since the beginning of Mozilla.) See above (again). The essence of our disagreement seems to be how to ensure that core packages are properly supported. Define core. For KDE users who want to change GTK themes gtk-chtheme (a very small and really old package) is core (i.e. important). The point is, a package is offered in the repos it should be as supported as possible, main/contrib/non-free doesn't/shouldn't matter. My point is that a sandbox will facilitate proper support. Which would be facilitated by keeping the 2 sets of free repositories. And restricting what should be considered core. We both know that Mandriva is moving in that direction. Evidently recognising that they weren't restrictive enough in the past. Contrib _is_not_ a sandbox, unless you're implying packagers are using users as lab rats which isn't true. Your focus is removing 1 of these repository sets, and thus the sandbox. But I don't see your solution for giving priority to maintaining core packages ? These factors are undeniably linked. By the way, I'm very willing to be convinced. Just give me the logic. regards - André -- Ahmad Samir
Re: [Mageia-dev] Mirror layout, round two
On 6 December 2010 09:29, Ernest N. Wilcox Jr. ewil...@bex.net wrote: With regard to the naming of the repository dediocated to software tainted with a patent, etc., How about non-GPL? I think that such a name should be well understood by users of nearly any language, particularly if they are familiar with the GPL. My2cents -- Ernest N. Wilcox Jr. Registered Linux User 247790 ICQ 41060744 Read the afro-mentioned thread again; most of those stuff are released under a GPL/GPL-like license (faad and faac packages for example, for playing back and encoding using the AAC audio codec, respectively), they're free open source software, but they infringe some patents. -- Ahmad Samir
Re: [Mageia-dev] Mirror layout : Why validate software patents ?
On 8 December 2010 11:39, Wolfgang Bornath molc...@googlemail.com wrote: 2010/12/8 Ahmad Samir ahmadsamir3...@gmail.com: For Fedora, being the most legally-challenged distro around, they don't include any patented software in their official repos at all, not even mp3 playback is possible in a default install. They even don't include any non-free stuff, so no nVidia and ATI proprietary drivers. Fedora users use some 3rd party repos, e.g. RPM Fusion http://rpmfusion.org/ Thx, so it's the same as with Mandriva wrt patented software. What I wanted to say: distributing no patented software at all is not the same as having no extra repository for patented software, so are Mandriva and Fedora seen as justifying patent sharks as andre999 descibed it? -- wobo Reality has proven that some users do use patented software, coming from a semi-official repo or a 3rd party one doesn't seem to matter; i.e. some Mandriva users use PLF (and/or others), some Fedora they use RPM Fusion (and/or others), some OpenSuse users use PackMan; and Debian has a non-US repo... etc The whole point is, it's a CYA (cover your a**) situation; just because a law suit isn't filed doesn't mean it won't/can't be filed. -- Ahmad Samir
Re: [Mageia-dev] mageia sound tasks
On 18 December 2010 15:50, Tux99 tux99-...@uridium.org wrote: On Fri, 17 Dec 2010, Sascha Schneider wrote: Hi list, I just started to create some task.spec files from the mandriva task-sound-studio for mageia. In contrast to the former taskfile and to most other linux audio distributions I would like to establish a modular system of sound-tasks, that help installing packages, but do not install everything regarded to sound. For I am not a good programmer, I wanted to ask if there are some devs, packagers and mageia-fanatics, that are willing to join me on this mission. Count me in, I was planning something similar too, since my interest is also mainly in the Audio/Video area, that's also why I registered as a packager in this area. I guess once the build system is up and running and we are all set up as packagers then we can talk about the details, but I don't think it should be here on the general dev ML, the ML would quickly get polluted with too many parallel discussions if every sub-group did all their discussion on the same ML. We could use a dedicated ML (either an official one or else I can set one up quickly on my server) or even a simple forum thread on the future Mageia forum. The Mageia-dev ML is the current official packagers ML, such packaging discussions are supposed and expected to happen here. Don't get demotivated by the nay-sayers that commented on your initial post, the argument that there are too many tasks is silly, as long as there is a maintainer for a task package (or any package) it should be included in the repos (if that won't be the case then Mageia wouldn't be the kind of open community distro it set out to be). This looks like coercing other packagers into adapting your point of view if you don't agree with my POV then you're not an open community distro; I don't like that attitude one bit. In any distro there're rules and guidelines that should be followed (look at Debian for example); being a community distro doesn't mean anyone gets a free reign to do whatever he wants whenever he wants. Note that Michael is discussing the issue, he didn't make final decisions. If you have a productive argument to make please do so, otherwise please refrain from calling other peoples' posts silly (or non-sense judging from your other posts on the ML). -- Ahmad Samir
Re: [Mageia-dev] Proposal for bugzilla
On 14 December 2010 18:05, Dexter Morgan dmorga...@gmail.com wrote: hello, now that we have a working bugzilla we need to have a working layout. i created a wiki page presenting what could be done. http://mageia.org/wiki/doku.php?id=bugzilla I would like to have your input to let us able to provide a bugzilla really soon In the bugreport creation we were thinking of using the mdv way or the fedora way. Fedora way is to add all srpms in the componment field but there is 2 pbs with this way : - Users don't know what is a rpms ( like what is the srpms for kwrite ) - This slow down the bugzilla too much I am most familiar with the layout at qa.mandriva.com, so I think it's good to start with it and modify things as needed. - I think we should have two 'Products' (for now), Mageia and Websites. - Under the 'Product: Mageia' the Version field (1.0, 1.1, 2.0, Cauldron... etc) specifies the release the bug report affects (with a whiteboard field to state if the bug affects more than one release (at least for now)). - The Components should be: - Documentation - Installation - RPM packages - New Packages requests - Release Media - Security - Translations Note that I dropped: - Kernel, as it's just still an rpm package and will be assigned properly based on the RPM Package field - Hardware, we won't fix bugs in hardware, we'll fix bugs in the software handling the hardware (and it was seldom used in the past anyway) - An Architecture field - Source RPM / RPM Package - Url field, for putting links to upstream bug reports in a clear place - Summary - Description - Severity and Priority fields See here for a picture of what I have in mind: https://qa.mandriva.com/enter_bug.cgi?product=Mandriva%20Linuxformat=guided -- Ahmad Samir
Re: [Mageia-dev] Proposal for bugzilla
On 22 December 2010 01:32, Frederic Janssens fja...@gmail.com wrote: On Wed, Dec 15, 2010 at 17:07, Michael Scherer m...@zarb.org wrote: Le mardi 14 décembre 2010 à 17:05 +0100, Dexter Morgan a écrit : I would like to have your input to let us able to provide a bugzilla really soon So if I am not wrong, in bugzilla, we have : - products - component, contained in products - and various field, per bug, and the way we organize everything will impact the layout. Yes. In preparation of the future interaction (by xmlrpc) between the mageia-app-db site and the mageia bugzilla, I have been testing http://bugs.mageia.org/ . Xmlrpc works, but it will be necessary to configure additional fields. The minimum would be to add an 'RPM Package' field (such as exists on https://qa.mandriva.com/). That's already agreed upon, whatever it's called, RPM Package or Component (I am in favour of the former). But, as the configuration must be modified anyway, I have been thinking about what fields we need. First I think it would be usefull to have a multiline (Large Text Box) 'RPM Packages' field, instead of a single line (Free Text) field as used by mandriva. A single bug can concern more than one rpm. One thing mageia-app-db will do is search all bugs affecting an rpm. For that search to be meaningfull all affected rpms should be mentioned. 'One bug per report' is what we should do (did); if a bug originates from more than one package, a separate report for each of them should be opened with the Block/Dependency set correctly. For the same reason, the way the rpms are mentioned should be 'standardised', as the search done by bugzilla can only be litteral. Usually one doesn't only search in the RPM Package field; experience tell us that the affected package name will be mentioned many times in both the summary and the description. And if you want to search in the RPM Package field, bugzilla has many options to do so, look at the bottom of: https://qa.mandriva.com/query.cgi?format=advanced Something that does not exist in mandriva, but I think would be usefull, is a 'Fixed RPM Packages' that would be filled when the bug is fixed. FIXED is great, but where (or since which rpm)? IMHO, that's trivia; either the user is savvy enough / has the time to trudge through the bug report to find out which package release fixes an issue (which indicates he's the curious type, he'll at least skim through the bug report anyway), or he's just going to update his system and get the fix (the latter happens more often). Perhaps also an 'Upstream' field which would, eventually, indicate where that bug is filed upstream. That's similar to the URL field in my proposal (see my previous post in this thread). Finally the status whiteboard could be enabled, and used to clearly explain a workaround, for open bugs (instead of having to figure it from the comments). (Eventually this field could also be used as the 'Fixed RPM Packages' field when the bug is closed. So it would be the 'Solution' field) I don't think this will be adequately useful; if the issue is fixed, then all the user has to do is update his system. If it's not fixed and affects a stable release then it should get added to the Errata page for that release whether there's a workaround (or not); if it affects Cauldron, well, Cauldron users are supposed to be fireproof-ready, so they do read bug reports (or skim through them). Apart from the status whiteboard which is a parameter to enable (http://www.bugzilla.org/docs/tip/en/html/parameters.html); the fields must be added as custom-fields (http://www.bugzilla.org/docs/3.6/en/html/custom-fields.html) -- Frederic -- Ahmad Samir
Re: [Mageia-dev] Proposal for bugzilla
On 22 December 2010 18:37, Frederic Janssens fja...@gmail.com wrote: On 2010-12-22, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 22 December 2010 01:32, Frederic Janssens fja...@gmail.com wrote: On Wed, Dec 15, 2010 at 17:07, Michael Scherer m...@zarb.org wrote: In preparation of the future interaction (by xmlrpc) between the mageia-app-db site and the mageia bugzilla, I have been testing http://bugs.mageia.org/ . Xmlrpc works, but it will be necessary to configure additional fields. The minimum would be to add an 'RPM Package' field (such as exists on https://qa.mandriva.com/). That's already agreed upon, whatever it's called, RPM Package or Component (I am in favour of the former). ok First I think it would be usefull to have a multiline (Large Text Box) 'RPM Packages' field, instead of a single line (Free Text) field as used by mandriva. A single bug can concern more than one rpm. One thing mageia-app-db will do is search all bugs affecting an rpm. For that search to be meaningfull all affected rpms should be mentioned. 'One bug per report' is what we should do (did); if a bug originates from more than one package, a separate report for each of them should be opened with the Block/Dependency set correctly. Sorry for not beeing clear. What I propose is not for the case 'a bug originates from more than one package'; but for the case 'a bug manifests itself in than one package'. A bug that manifests in more than one package must originate from 'some package', that 'some package' is the only one that should be in the 'RPM Package' field; i.e that's the package that's going to need fixing. (In fact I think I want to solve the same problem you want to solve with with a whiteboard field to state if the bug affects more than one release (at least for now) but in a more specific manner). For the same reason, the way the rpms are mentioned should be 'standardised', as the search done by bugzilla can only be litteral. Usually one doesn't only search in the RPM Package field; experience tell us that the affected package name will be mentioned many times in both the summary and the description. And if you want to search in the RPM Package field, bugzilla has many options to do so, look at the bottom of: https://qa.mandriva.com/query.cgi?format=advanced Yes; but I am trying to solve the connection with mageia-app-db. With the xmlrpc interface it seems the search possibilities are more limited : (from http://www.bugzilla.org/docs/3.6/en/html/api/Bugzilla/WebService/Bug.html) : search UNSTABLE Description Allows you to search for bugs based on particular criteria. Params Unless otherwise specified in the description of a parameter, bugs are returned if they match exactly the criteria you specify in these parameters. That is, we don't match against substrings--if a bug is in the Widgets product and you ask for bugs in the Widg product, you won't get anything. Criteria are joined in a logical AND. That is, you will be returned bugs that match all of the criteria, not bugs that match any of the criteria. Each parameter can be either the type it says, or an array of the types it says. If you pass an array, it means Give me bugs with any of these values. For example, if you wanted bugs that were in either the Foo or Bar products, you'd pass: product = ['Foo', 'Bar'] I don't know about xmlrpc, but there's no one certain way to fill the 'RPM Package' field; ideally it should be packagename-version-release (e.g. kwrite-4.5.85-1mdv), whatever search method you use, it has to be versatile enough to cope with the field content variations. FWIW, the best way to search a bugzilla is using the Advanced search interface; just searching for the package name isn't enough. Usually it's not a problem for active triage team members to spot duplicates (from daily contacts with bug reports) and mark them as such. Something that does not exist in mandriva, but I think would be usefull, is a 'Fixed RPM Packages' that would be filled when the bug is fixed. FIXED is great, but where (or since which rpm)? IMHO, that's trivia; either the user is savvy enough / has the time to trudge through the bug report to find out which package release fixes an issue (which indicates he's the curious type, he'll at least skim through the bug report anyway), or he's just going to update his system and get the fix (the latter happens more often). Here the 'user' is mageia-app-db. Then this is a premature question; you should wait first to see how the updates in stable releases are going to be handled (will everything have to go through the sec team? or sec team will only care about the essential packages only?... etc because in that case a security announcement is dispatched, you may be able to grab the fixed version from there). Perhaps also an 'Upstream' field which would, eventually, indicate where
Re: [Mageia-dev] Proposal for bugzilla
On 22 December 2010 21:25, Frederic Janssens fja...@gmail.com wrote: On 2010-12-22, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 22 December 2010 18:37, Frederic Janssens fja...@gmail.com wrote: On 2010-12-22, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 22 December 2010 01:32, Frederic Janssens fja...@gmail.com wrote: First I think it would be usefull to have a multiline (Large Text Box) 'RPM Packages' field, instead of a single line (Free Text) field as used by mandriva. A single bug can concern more than one rpm. One thing mageia-app-db will do is search all bugs affecting an rpm. For that search to be meaningfull all affected rpms should be mentioned. 'One bug per report' is what we should do (did); if a bug originates from more than one package, a separate report for each of them should be opened with the Block/Dependency set correctly. Sorry for not beeing clear. What I propose is not for the case 'a bug originates from more than one package'; but for the case 'a bug manifests itself in than one package'. A bug that manifests in more than one package must originate from 'some package', that 'some package' is the only one that should be in the 'RPM Package' field; i.e that's the package that's going to need fixing. Sorry again, what I mean, and should have written, is : 'a bug manifests itself in one package, but in more than one -version-release'. There's no way in bugzilla to do this at the moment (there's talk about this being implemented in bugzilla-4.0, which I haven't tried before). Traditionally the Whiteboard field was used for such issues (or separate reports were opened for each affected stable release). Having a multi-line RPM Package wouldn't be the way to go with this (IMHO). (In fact I think I want to solve the same problem you want to solve with with a whiteboard field to state if the bug affects more than one release (at least for now) but in a more specific manner). For the same reason, the way the rpms are mentioned should be 'standardised', as the search done by bugzilla can only be litteral. Usually one doesn't only search in the RPM Package field; experience tell us that the affected package name will be mentioned many times in both the summary and the description. And if you want to search in the RPM Package field, bugzilla has many options to do so, look at the bottom of: https://qa.mandriva.com/query.cgi?format=advanced Yes; but I am trying to solve the connection with mageia-app-db. With the xmlrpc interface it seems the search possibilities are more limited : (from http://www.bugzilla.org/docs/3.6/en/html/api/Bugzilla/WebService/Bug.html) : search UNSTABLE Description Allows you to search for bugs based on particular criteria. Params Unless otherwise specified in the description of a parameter, bugs are returned if they match exactly the criteria you specify in these parameters. That is, we don't match against substrings--if a bug is in the Widgets product and you ask for bugs in the Widg product, you won't get anything. Criteria are joined in a logical AND. That is, you will be returned bugs that match all of the criteria, not bugs that match any of the criteria. Each parameter can be either the type it says, or an array of the types it says. If you pass an array, it means Give me bugs with any of these values. For example, if you wanted bugs that were in either the Foo or Bar products, you'd pass: product = ['Foo', 'Bar'] I don't know about xmlrpc, but there's no one certain way to fill the 'RPM Package' field; ideally it should be packagename-version-release (e.g. kwrite-4.5.85-1mdv), That's what I proposed in another post. If that were the standard, there would be no problem for mageia-app-db. whatever search method you use, it has to be versatile enough to cope with the field content variations. To be clear : as indicated above, the limitation is in what bugzilla offers through it's xmlrpc interface. We should have to modify the bugzilla code if we wanted access to it's 'advanced search' through it's xmlrpc interface. Whatever. As long as that doesn't affect the workflow of the triage team or bugzilla's performance in general, I don't really care whichever way it get implemented :) [...] -- Frederic -- Ahmad Samir
Re: [Mageia-dev] Proposal for bugzilla
On 22 December 2010 21:30, Renaud MICHEL r.h.michel+mag...@gmail.com wrote: On mercredi 22 décembre 2010 at 18:46, Ahmad Samir wrote : Sorry for not beeing clear. What I propose is not for the case 'a bug originates from more than one package'; but for the case 'a bug manifests itself in than one package'. A bug that manifests in more than one package must originate from 'some package', that 'some package' is the only one that should be in the 'RPM Package' field; i.e that's the package that's going to need fixing. I agree, but that doesn't mean the user is able to identify the problematic package, even if he has good knowledge of the way packages work. Let's say for example that there is a problem with libxy, it is compiled with a bad combination of optimizations that make some of its functions behave randomly. appA appB and appC use libxy, but appC only use simple functions that are not affected by the optimization problem, so only appA and appB behave badly. Even if the user know about packages dependencies, as appC work fine he may not come to the conclusion that libxy is causing the problem. But he may still consider the problems with appA and appB to be related because they started at the same time (the latest update that included libxy). So if he can fill a single bug report for both appA and appB, that is a good hint to the developer that he should investigate in the dependencies those apps have in common. So if you accept only one package per bug report, it may be harder to find the actual cause, as those two apps may be maintained by different people, each investigating the problem for his own app. -- Renaud Michel Sure, but there's strace and gdb crash backtraces, that's what devs use to find where a crash/bug happens, whether it's in their package/code or somewhere else. To be more clear it's one bug per report, that bug originates from a package, that's what gets to be put in the 'RPM Package' field; it's not unheard of that the 'RPM Package' field is changed through out the life cycle of a bug report. -- Ahmad Samir
Re: [Mageia-dev] Proposal for bugzilla
On 22 December 2010 21:45, Maarten Vanraes maarten.vanr...@gmail.com wrote: Op woensdag 22 december 2010 20:38:06 schreef Ahmad Samir: Sure, but there's strace and gdb crash backtraces, that's what devs use to find where a crash/bug happens, whether it's in their package/code or somewhere else. To be more clear it's one bug per report, that bug originates from a package, that's what gets to be put in the 'RPM Package' field; it's not unheard of that the 'RPM Package' field is changed through out the life cycle of a bug report. yes, but suppose there's a firefox issue and it appears to be a problem with a system library, after it gets changed, people will never find this problem again; since they look for firefox... In two years, I probably never used the RPM Package as a search criteria (I don't have any statistics many people use it, my guess would be a small number); I usually search in the Comments with Contains all of the words or Contains all of the words/strings (not just in mdv bugzilla, but in any bugzilla I use, some of them enable searching in the bug Summary); so you search for firefox crash bookmarks or firefox crash move tab or firefox hang quit, I think that's what most users will do as the RPM Package is a bit hidden at the bottom. IMHO, this is better, because a GTK2+ bug could affect a lot of GTK2+ apps, I don't think it's ideal to list every single affected package in the RPM Package field. The same goes for kdelibs or perl or python or ffmpeg... etc. -- Ahmad Samir
Re: [Mageia-dev] Proposal for bugzilla
On 23 December 2010 00:34, Samuel Verschelde sto...@laposte.net wrote: Le mercredi 22 décembre 2010 21:25:39, Michael scherer a écrit : On Wed, Dec 22, 2010 at 01:55:02PM +0100, Frederic Janssens wrote: On 2010-12-22, Michael Scherer m...@zarb.org wrote: Le mercredi 22 décembre 2010 à 00:32 +0100, Frederic Janssens a écrit : On Wed, Dec 15, 2010 at 17:07, Michael Scherer m...@zarb.org wrote: Le mardi 14 décembre 2010 à 17:05 +0100, Dexter Morgan a écrit : I would like to have your input to let us able to provide a bugzilla really soon So if I am not wrong, in bugzilla, we have : - products - component, contained in products - and various field, per bug, and the way we organize everything will impact the layout. Yes. In preparation of the future interaction (by xmlrpc) between the mageia-app-db site and the mageia bugzilla, I have been testing http://bugs.mageia.org/ . Xmlrpc works, but it will be necessary to configure additional fields. The minimum would be to add an 'RPM Package' field (such as exists on https://qa.mandriva.com/). What about component not related to rpm ? The 'RPM Package' field would be left blank. (usually many fields are left blank) That's quite useless clutter in this case :/ And do you mean srpm or rpm ? On https://qa.mandriva.com/ anything goes. To permit consistent searches I think we should standardise. The aim would to be to as specific as needed but not more; as far as I know that would be : name-version-release unless the bug is architecture specific, where we would have : name-version-release.architecture There is already a architecture field, afaik, as well as a version field, no ? ( I didn't check as I refuse to enter my password over a insecured http session ). And I think that giving rpm ( and not srpm ) will make search a little bit complex in some corner cases ( can will also cause problem for the next point ). So you think the (S)RPM field should only contain SRPM filenames ? If yes, I agree with that, because as Frederic stated above, in current Mandriva bugzilla, there's no enforced rule for that. You can put anything in the field, and you often end up with rpm filenames, or simple package names (e.g. virtualbox). However asking bug reporters to know the SRPM is too much, so this rule can only be enforced on Packagers and Triage Team side I think. This is already how it works on qa.mandriva.com : if you know the SRPM, you put it, if not someone will triage and do it for you. Ahmad, would there be a problem in enforcing such a policy (i.e. SRPM field should be empty or contain a valid SRPM name ? Where valid means looks like the name of a SRPM) ? Regards Samuel Verschelde Actually virtualbox is a valid enough SRPM name, because if you put virtualbox in the RPM Package field bugzilla will auto-assign to the package maintainer. And putting the arch. of the package in that field isn't so useful, there's a separate Architecture field in each report. How do you wanna enforce this? by rejecting anything the user puts in that field if it's not correct? well, I expect that we'll get less reports this way, good from the triage team workload POV :), bad from the POV that some important reports won't be filed because the user doesn't understand what you want him to do. I have no problem with having a report with a wrong content in the RPM Package field, that can be fixed. So no, I am not OK with enforcing anything here, just offering this as a guide line that it should be 'kwrite-4.5.5-1mga' rather than just 'kwrite' or 'kwrite-4.5.5' is the best you can hope for. (IMHO, mageia-app-db should be more versatile in the way it searches bug reports, note that almost at any given point in time there'll be reports that haven't been triaged yet, and so can have an empty or a wrong content in the RPM Package field) And about it being hard to find the name of the package, it depends, do you think users reporting a bug read? if they read the little paragraph under the Source RPM field here: https://qa.mandriva.com/enter_bug.cgi?product=Mandriva%20Linuxformat=guided you'll find that it states exactly how to find the src.rpm name :) The point is, such things come with time and experience with bug reporting, I don't expect a user to get it right the first time, but if he still doesn't get it right with his say 15th bug report, then he doesn't take enough care when filing the report and I can assure you by that time he'll have been notified more than once about what should be done (by triage team members, devs, package maintainers... etc). -- Ahmad Samir
Re: [Mageia-dev] Proposal for bugzilla
this testing package fixes them ? Please consult the following bug reports and test 6) we can't tell, but it's interesting to mention that the package in 4) has the bug, they may be related Regards Samuel Verschelde This thread is about bugzilla configuration and setup not mageia-app-db... -- Ahmad Samir
Re: [Mageia-dev] Proposal for bugzilla
On 24 December 2010 13:02, Michael scherer m...@zarb.org wrote: On Fri, Dec 24, 2010 at 01:20:41AM +0100, Dexter Morgan wrote: On Thu, Dec 23, 2010 at 11:22 PM, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 24 December 2010 00:13, Maarten Vanraes maarten.vanr...@gmail.com wrote: Op donderdag 23 december 2010 22:23:56 schreef Ahmad Samir: On 23 December 2010 22:01, Samuel Verschelde sto...@laposte.net wrote: I remember some years ago you could choose the exact version of the package for which you reported a bug, from a list. I agree that improving the UI side helpers could be useful. Regards Samuel Verschelde As was said by dmorgan, listing each SRPM slowed down bugzilla a lot; the distro has a lot of SRPMS... an ajax search is better; it doesn't add much and only gets searched if you enter at least 2 chars, or something like that. if such an ajax is wanted, i can write that if i can use app-mageia-db or similar as a list. If the user doesn't know how to find the package info (rpm -q packagname), no auto-complete is going to help much, he'll just pick one of them randomly (top of the list, or bottom of the list). It's not much to ask for rpm -q output... -- Ahmad Samir and this method is deprecated ( i mean the big list ) because this slow down too much the server. The server, or the the browser ? ( because server side, that's just a SQL query likely in cache, while browser side, you have to render a enormous 15 000 items list, with allocation of objects, etc, etc ). -- Michael Scherer Exactly. So if this get implemented I'd like it to be optional, i.e. I can still turn it off in my bugzilla preferences. -- Ahmad Samir
Re: [Mageia-dev] Proposal for bugzilla
On 25 December 2010 02:04, andre999 and...@laposte.net wrote: [...] In my mind, it is triage and QA who would benefit the most from such a list. Not really, QA and Triage already use Sophie http://mageia.org/wiki/doku.php?id=irc#sophie It seems if we were to have such a list, that it might be better to make it a separate (web) application, which could be referred to in a separtate tab/window, so it is charged only once for reviewing a number of bugs. But if triage/QA is not interested, it is better to avoid this big list. Another thought : maybe we should have separate rpm and srpm fields. Because end-users will relate more to ordinary rpm's, several of which could be generated by the same srpm. Do you think that would be useful ? my 2 cents :) André One field is enough, a package maintainer knows what rpms come from which of his SRPMs. The RPM Package field main goal is indicating where the bug exists as that's where it'll, hopefully, get fixed. -- Ahmad Samir
Re: [Mageia-dev] Packagers representatives
On 29 December 2010 15:55, Luca Berra bl...@vodka.it wrote: On Mon, Dec 27, 2010 at 09:23:00PM +0100, Michael Scherer wrote: sorry, but I can try to answer questions. do you ever sleep? :P By the looks of it, no, he doesn't; even at the crack of dawn you find him on IRC. -- Luca Berra -- bl...@vodka.it -- Ahmad Samir
Re: [Mageia-dev] New bugzilla proposal
On 6 January 2011 18:39, Michael Scherer m...@zarb.org wrote: Le jeudi 06 janvier 2011 à 17:05 +0100, Dexter Morgan a écrit : After reading the various mails i think we coulddo like this Product : Mageia Componments: - Documentation - Installation - RPM packages - New Packages requests - Release Media - Security - Translations Could you explain what kind of bug would go in every category ? For exemple, translation would apply to what kind of bug, same goes for documentation ? I don't have a problem with dropping Documentation; but not translations, the way it works in mdv buzilla is that when the Component is set to Translations the i18n ML was CC'ed, which is advantageous as translators are best fit to fix such bugs (this raises the question of where translators want those emails to go, which one of their ML's?). If we have a separate documentation, wouldn't it be more logical to have it as a product, with various subcomponent like each manual ? [..] For translation, shouldn't it be attached to either a software, a website, a document than be separate ? See above. For security, that seems rather vague too, security about the rpm ( in which case it would go with rpm packages rather than be separate ), the infrastructure ? Drop it, but the note about For security sensitive bugs please make sure to assign to security@ as well as tick the checkbox above as you can see here: https://qa.mandriva.com/enter_bug.cgi?product=Mandriva%20Linuxformat=guided Point is, such bugs can only be seen by the reporter and sec team. Release media would mean what, cd/dvd/usb, mirrors ? All of them, basically anything that has to do with the release ISO's. Examples: - missing package from DVD or Live ISO's - wrong md5sum/sha1sum on the mirrors - missing/corrupt ISO's - CD ISO's that don't fit on a 700MB CD (as I saw with some of the 2010.2 ISO's which had to be recreated by mdv) -- Michael Scherer -- Ahmad Samir
Re: [Mageia-dev] Choosing packagers representatives
On 7 January 2011 01:02, Anne nicolas enna...@gmail.com wrote: Here are finally the results and detail of this vote https://epoll.mageia.org/vote/ISJTLYRT Thanks for participating! -- Anne http://www.mageia.org FWIW, I didn't vote because simply I never got the email with the epoll password. -- Ahmad Samir
Re: [Mageia-dev] svn broken by pam confg change
On 13 January 2011 20:48, Michael Scherer m...@zarb.org wrote: Hi, It seems that I broke svn while updating pam config, I am working on fixing. I will post a mail when it should be ok. -- Michael Scherer Thanks for the heads up :) -- Ahmad Samir
Re: [Mageia-dev] svn broken by pam confg change
On 13 January 2011 21:07, Michael Scherer m...@zarb.org wrote: Le jeudi 13 janvier 2011 à 19:48 +0100, Michael Scherer a écrit : Hi, It seems that I broke svn while updating pam config, I am working on fixing. I will post a mail when it should be ok. It was faster than what I planned, it was just a typo ( commit 784 on adm ). So svn should work again now. ( and it was quite fast to find, thanks to svn and puppet ). -- Michael Scherer \o/ thanks. -- Ahmad Samir
Re: [Mageia-dev] Is libesd needed anymore?
On 15 January 2011 01:18, Maarten Vanraes maarten.vanr...@gmail.com wrote: Op vrijdag 14 januari 2011 13:22:54 schreef Colin Guthrie: Hi, When importing packages, I'm very tempted to not import esound. It's only used to compile libesd. Do we really need it? I don't think we ship any apps that use only esd, so I don't think that's a problem but perhaps some old legacy apps (i.e. games) still need it. What do people think? It's not really much hassle to support it, but by the same token, dead projects have to be buried at some point! Col I don't fully agree, dead projects can stay alive (undead). however, just don't import it, don't have support for it in gnome. and if someone really needs it, he can import it and maintain it if he wants to. in short, drop it and let someone else figure it out at a later date. Well, no, dead projects are just that, dead... And if libesd is dropped all packages that BR it need to be fixed; maybe postpone this until the importing rush is over, then it can be phased out after this high pressure stage is over.. (just MHO). -- Ahmad Samir
Re: [Mageia-dev] Importing RPM Spec File Syntax
On 15 January 2011 12:08, Remy CLOUARD shikam...@mandriva.org wrote: Hi there, I just imported the RPM Spec File Syntax page in the wiki. It’s located here: http://mageia.org/wiki/doku.php?id=spec_syntax Please review this page as it’s one of the most important one for the beginning of the mentoring process, with the RPM Howto page (yet to be imported). Some comments on this page: - Patch naming: I’m not sure we should go that far for the patch naming policy, and in practice it’s not what I’ve seen up till now. Here’s a proposal: Patches must be named in a very explicit manner to make it very clear to what version it was originally applied. To that end, a patch needs to follow the convention of [package_name]-[version]-[description].patch: * [package_name] is the name of the package it applies against, such as 'shadow-utils' or 'gnupg' * [version] is the version of the program this patch was developed against, such as 1.0. The name of the patch should not change, I don't agree, if you rediff the patch against version 2.0 the the version in the patch name should change; one reason is, it can't be applied to version 1.0 any more without restoring the old patch from an older SVN rev. or rediffing it again. [...] -- Rémy CLOUARD () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- Ahmad Samir
Re: [Mageia-dev] Importing RPM Spec File Syntax
On 17 January 2011 23:53, Florian Hubold doktor5...@arcor.de wrote: Am 15.01.2011 11:08, schrieb Remy CLOUARD: http://mageia.org/wiki/doku.php?id=spec_syntax Please review this page as it’s one of the most important one for the beginning of the mentoring process, with the RPM Howto page (yet to be imported). I have one comment, or more of a question: Why is it that some time ago there used to be this syntax as de-facto standard: %define name Name: %name Never understood this, so i went with what seems the new standard, which saves you at least 3 lines per spec and improving readability. So anyone can enlighten me why name, release and version had %defines? Just more visibility, ideally it comes down to that package maintainer's preference. (One point to note, if you see it in an unmaintained package go ahead and change it if you want; however if you see it in the spec of maintained package, ask the maintainer first, a nicety but still.. :)). -- Ahmad Samir
Re: [Mageia-dev] background and theme path
On 19 January 2011 15:02, Olivier Blin mag...@blino.org wrote: Remy CLOUARD shikam...@mandriva.org writes: On Wed, Jan 19, 2011 at 01:06:49PM +0100, Olivier Blin wrote: I'd like to move away from the hardcoded backgrounds location for themes, and put them in a distro-neutral path (was /usr/share/mdk/backgrounds/ in Mandriva) Most Gnome backgrounds appear to be located in /usr/share/pixmaps/backgrounds/ (some are in /usr/share/backgrounds/) Is everyone ok to have our backgrounds in /usr/share/pixmaps/backgrounds/theme name/ and the distro default as /usr/share/pixmaps/backgrounds/default.jpg ? Well, I’d say it would be better if it were also desktop-neutral. AFAIK, there is one freedesktop specification for icons [1], but not for wallpapers, it would be nice to raise this subject on fd.o ml. We can raise the subject there, but we should have a fast short-term decision for Mageia as well, this is blocking for packages import. So that would be either /usr/share/pixmaps/backgrounds, /usr/share/wallpapers, or /usr/share/backgrounds Any idea about how other distros are handling this? I don’t know which package owns /usr/share/pixmaps/backgrounds/, but apparently it’s not desktop-common-data. I would rather not having to install gnome packages/kde packages for that. No packages owns it yet. $ LC_ALL=C rpm -qf /usr/share/pixmaps/backgrounds/ file /usr/share/pixmaps/backgrounds is not owned by any package -- Olivier Blin - blino gnome-screensaver uses /usr/share/backgrounds. I think /usr/share/wallpapers is the best one. -- Ahmad Samir
Re: [Mageia-dev] On importing /soft
On 19 January 2011 22:32, Pascal Terjan pter...@gmail.com wrote: http://svn.mageia.org/soft-cleaning/status.html#monitor-edid says - README: Some reference to the Mandriva mailing list and bugzilla will need to be changed to Mageia ones Do we really want to? What is the point? I think we can package this tool as-is, as a tool provided by Mandriva like if we were packaging a non distro specific tool developed by RedHat or Debian or anyone and let people report their bugs upstream if the README says so. If someday it becomes unmaintained or for any other reason, we can fork it, but currently I think of it as an external tool and see no reason in importing it into our svn I did not read the full list but I guess there are other standalone tools that we don't need to fork into our svn. Opinions? err... I'd really have appreciated this about two month ago, would have made my life cleaning the svn/soft much easier :/ Adjusting my approach now (svn rm (in the cleaning repo) is my favourite command as of late :)). -- Ahmad Samir
[Mageia-dev] firefox/xulrunner :visited links status
xulrunner is shipped with: pref(layout.css.visited_links_enabled, false); the big/scary parts of this issue has been fixed ages ago c.f.: https://bugzilla.mozilla.org/show_bug.cgi?id=14 http://dbaron.org/mozilla/visited-privacy I think we should revert this change especially with firefox-4.0. If no one objects I'll apply this change after two days. -- Ahmad Samir
Re: [Mageia-dev] BugSquad initiation!
On 3 February 2011 23:15, Samuel Verschelde sto...@laposte.net wrote:
Le jeudi 3 février 2011 17:35:17, Ahmad Samir a écrit :
We're going to hold the BugSquad first meeting on IRC,
#mageia-bugsquad on Freenode at 20h UTC ('date -u' in terminal on your
system will show the time in UTC) on Tuesday the 25th of January.
Maybe you could give the date of the next meeting, because the 25th of January
is already behind us :)
Samuel
I did in an email that I sent 3hours ago (but due to the huge number
of emails in CC it's awaiting moderation).
--
Ahmad Samir
Re: [Mageia-dev] Packager meetings for tonight
On 3 February 2011 18:06, Michael Scherer m...@zarb.org wrote: Le jeudi 03 février 2011 à 02:44 +0100, Michael Scherer a écrit : Le mercredi 02 février 2011 à 17:26 +0100, Michael Scherer a écrit : Hi, Next meeting will happen tonight on #mageia-dev at 20h UTC. Quick proposal for agenda ( the meeting must be quick ) : - review of the task distributed last week ( http://meetbot.mageia.org/mageia-dev/2011/mageia-dev.2011-01-26-20.03.html ) - proposal on what should be imported in priority ( and distribution of the work ) So as discussed tonight ( but if you couldn't be present at the meeting, do not hesitate to express yourself now ), we proposed to have some order in the import of rpm ( ie avoid the resulting anarchy due to lack of process for bootstrap ). In order to start by something tangible and easy to manage, let's take a concrete case. The sysadmin team discussed to use mageia on the servers ( once the stable release is out ie, not now ) for obvious reasons of dogfooding. But for this, we will have to import the needed rpms. I extracted from puppet logs the lists of rpm, and I have a list of the major component needed. The rule would be to take 1 and only 1 rpm ( or family ) at the time, to make sure it work fine ( ie, compile for the moment, and also install ), to make sure the package is cleaned ( ie, patchs sent upstream, commented, etc ), and to make sure that everybody can find something to do. And that of course requires to do the same for missing BuildRequires, and Requires ( but since lots of rpm have been imported without being fully cleaned, and since there is now a fast web interface for svn, people have no excuse to not check ). I will place the list on the wiki tomorrow, and people wishing to work on importing a rpm should add their name/login/whatever after the rpm, and then to work on it. If there is already someone working on a rpm, just take another one, or try to work with this person. So it seems that my list of 20 rpms is now much lower than needed, as most servers applications needed have been imported. The only thing left are : * apache ( and apache-mod_fastcgi, apache-mod_perl, apache-mod_php, apache-mod_ssl, apache-mod_wsgi * bugzilla * icecream * rails * sympa * mercurial Taking icecream (pun included :)). -- Michael Scherer -- Ahmad Samir
Re: [Mageia-dev] Packager meetings for tonight
On 3 February 2011 18:06, Michael Scherer m...@zarb.org wrote: [..] The only thing left are : * apache ( and apache-mod_fastcgi, apache-mod_perl, apache-mod_php, apache-mod_ssl, apache-mod_wsgi * bugzilla * icecream * rails * sympa * mercurial apache-mod_fastcgi imported apache-mod_php already available apache-mod_ssl src.rpm is apache itself apache-mod_wsgi imported -- Ahmad Samir
Re: [Mageia-dev] BugSquad initiation!
On 3 February 2011 18:35, Ahmad Samir ahmadsamir3...@gmail.com wrote:
This is copy of email that was sent some time ago (about two weeks) to
the bugsquad mailing list, and to everyone who put his name down in
the triage page in the wiki.
After discussions, it was seen wise to send a fresh copy to the
Mageia-dev and Mageia-discuss mailing lists, in the hope that people
who are interested in triage work can participate :)
Please *reply to* this email directly on the mageia-bugsquad mailing
list (please be careful as this email has -dev and -discussion lists
in CC :)).
This is just an introduction email, to get the team started/organised.
Unlike other teams we are not in a rush, since, well, we still don't
have any bugs (something you probably won't hear/read ever again :));
still it's a good idea to start now.
As you can see on the triage page:
http://mageia.org/wiki/doku.php?id=triage There's now a documentation
section, it's recommended to read those articles carefully (don't
worry, it's not as complex as it looks, if you've ever used a bugzilla
you already know a lot of the information in those articles).
The communications methods will be:
- The BugSquad Mailing list:
https://www.mageia.org/mailman/listinfo/mageia-bugsquad
- Our own IRC channel #mageia-bugsquad on Freenode.
We're going to hold the BugSquad first meeting on IRC,
#mageia-bugsquad on Freenode at 20h UTC ('date -u' in terminal on your
system will show the time in UTC) on Tuesday the 25th of January.
Using IRC is quite simple, use any IRC client from the repos, Quassel,
Konversation, xchat-gnome, kvirc; most of them are configured to join
Freenode by default, you just join #mageia-bugsquad channel; easiest
way is typing this command in the input box (after you connect to
Freenode):
/join #mageia-bugsquad
--
Ahmad Samir
Of course the day of the meeting changed! same time, next Tuesday,
that's the 8th of February.
--
Ahmad Samir
Re: [Mageia-dev] firefox/xulrunner :visited links status
On 3 February 2011 21:05, Ahmad Samir ahmadsamir3...@gmail.com wrote: xulrunner is shipped with: pref(layout.css.visited_links_enabled, false); the big/scary parts of this issue has been fixed ages ago c.f.: https://bugzilla.mozilla.org/show_bug.cgi?id=14 http://dbaron.org/mozilla/visited-privacy I think we should revert this change especially with firefox-4.0. If no one objects I'll apply this change after two days. -- Ahmad Samir Since no one objected, I've applied this change and submitted a new package. -- Ahmad Samir
Re: [Mageia-dev] glib 1.2
On 7 February 2011 01:11, Christophe Fergeau cferg...@gmail.com wrote: Hi, During a discussion on IRC, I realized that glib 1.2 had been imported in the svn repository http://svnweb.mageia.org/packages/cauldron/glib/ This library has been obsolete for years now, and I'm not sure at all there is any interesting app still needing it. I'd really recommend trying hard to keep glib 1.2 away from the repository to avoid having really old and obsolete packages that noone will use anyway. This would probably save some maintainance time to some people. Cheers, Christophe We should probably remove it now, it's not built/available yet in the Mageia repos. -- Ahmad Samir
Re: [Mageia-dev] 26/01/2011 meeting
On 7 February 2011 22:24, Michael Scherer m...@zarb.org wrote: Le lundi 07 février 2011 à 21:30 +0200, Ahmad Samir a écrit : On 26 January 2011 20:20, Michael Scherer m...@zarb.org wrote: Le mercredi 26 janvier 2011 à 18:13 +0200, Ahmad Samir a écrit : More DE's will be in soon; note that the big hurdle of importing the most basic packages is over, so importing packages now is much easier :) Yeah, but personally, i would prefer to see that people focus more on cleaning ( and sending patches upstream ) than importing And who said that when we import a package we didn't clean it too? Well, most of the time, patches are not commented nor send upstream :/ -- Michael Scherer Personally, as I said before about upstreaming patches, I don't think I have enough experience to judge if a patch should go upstream or not, so that part I can't do. What do you mean by commented? -- Ahmad Samir
Re: [Mageia-dev] 26/01/2011 meeting
On 8 February 2011 08:21, Cazzaniga Sandro cazzaniga.san...@gmail.com wrote: Le 07/02/2011 22:11, Ahmad Samir a écrit : Personally, as I said before about upstreaming patches, I don't think I have enough experience to judge if a patch should go upstream or not, so that part I can't do. What do you mean by commented? A thing like: #patch from to fix truc Patch0: glibc-2.12-truc.fix.patch That's usually available in the svn log, whoever wrote the patch should have commented it if that is the policy, however I am not aware that such a policy exists (IMBW though). -- Ahmad Samir
Re: [Mageia-dev] Announcing a web viewer for svn, + quick guide to the svn
On 9 February 2011 00:44, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 1 February 2011 18:45, Michael Scherer m...@zarb.org wrote: [...] /packages - http://svnweb.mageia.org/packages/ /packages is where you can find specs files, patches and everything needed to rebuild packages. The best way to access is is using mgarepo, as explained by the wiki and boklm. There is 2 directories : misc - contains the old changelog of imported packages cauldron - 1 directory per package name In a package directory ( like http://svnweb.mageia.org/packages/cauldron/acpi/ ), you will find 3 subdirectories most of the time : pristine/ releases/ current/ pristine/ hold the latest submitted rpm ( ie, the specs and sources ). releases/ work like the tags directory of usual subversion layout, with the older version of the rpms, and current/ is the current work. When using mgarepo, it take current/, and that's where people should look for the newest version. Since no one except some people who work on the BS will likely be interested in the details, I will not go further ( being myself in the list of those that do not remember the details :p ) For firefox users, you can access the spec file of a package directly using the firefox keyword feature: - Open Bookmarks - Show all bookmarks - Right click the folder you want to create the bookmark in, then Create new bookmark - Location should be: http://svnweb.mageia.org/packages/cauldron/%s/current/SPECS/%s.spec - Open More, and put the keyword you want in the Keyword box (for example svnm) - To use it, in firefox Location/url bar type: svnm amarok and press Enter. That should directly open http://svnweb.mageia.org/packages/cauldron/amarok/current/SPECS/amarok.spec (what it does is replace each %s with the text you type after the keyword). [...] -- Ahmad Samir Forgot to say that you can create another one for stable releases, by replacing /cauldron/ with /1/ in the url in the Location url when creating the bookmark (of course, with a different keyword). -- Ahmad Samir
Re: [Mageia-dev] 26/01/2011 meeting
On 9 February 2011 11:27, Michael scherer m...@zarb.org wrote: On Wed, Feb 09, 2011 at 12:22:59AM +0200, Ahmad Samir wrote: On 8 February 2011 08:21, Cazzaniga Sandro cazzaniga.san...@gmail.com wrote: Le 07/02/2011 22:11, Ahmad Samir a écrit : Personally, as I said before about upstreaming patches, I don't think I have enough experience to judge if a patch should go upstream or not, so that part I can't do. What do you mean by commented? A thing like: #patch from to fix truc Patch0: glibc-2.12-truc.fix.patch That's usually available in the svn log, whoever wrote the patch should have commented it if that is the policy, however I am not aware that such a policy exists (IMBW though). There is no specific policy despites the matter being discussed some time ago, but to me, this is the only way to know what was send upstream and what wasn't. It is ok if someone is not sure to send upstream or not, but we cannot know if this is not written. And searching the svn log is tedious, people usually say add patch to fix stuff, without giving the name. And you have to search for every patch, and nobody ever say what is the upstream status of the patch. So writing in the spec, just before the patch what it does, if it was sent upstream, and where ( or why it shouldn't ) allow to quickly see the status. For example, I found while cleaning newt that some patches where never send to developpers ( and so I did ), that 2 patchs were wrong. So we cannot assumed that it was send back, even when we take the file from another distribution. I started working on a prototype of a web interface to manage this ( called ghostwheel ), but it requires some functions on sophie to work ( and didn't had time to code them ). ( a django web application, so far it does nothing except declaring a db and having a cool name ). If we do not comment and send upstream, we will end up with rpm like gdb : When you look at it ( http://svnweb.mageia.org/packages/cauldron/gdb/current/SPECS/gdb.spec?revision=21081view=markup ), the patch 320 ( and others ) that seems to come from gdb 6.5, you see there is something fishy since we are now running gdb 7.1. Some seems to be linked to bugzilla ( no mention of the url of the bz ), but does it mean they were sent uptream or not ? The various format-security patches, etc, should also be commented and send upstream. The patches about IA64 should maybe have been cleaned, etc. Ask teuf why it took so long to upgrade gdb :) -- Michael Scherer I agree it's good practice to comment on patches in the spec. But if you expect me to trudge through the svn log of each package I import/imported to see why a patch was added and add a comment in the spec then I won't import any packages. I am not going to correct a behaviour that was in effect for years as it's not my fault to begin with... :) -- Ahmad Samir
Re: [Mageia-dev] [mageia-dev] Installer progress bootloader installation
On 15 February 2011 19:35, Daniel Kreuter daniel.kreute...@googlemail.com wrote: Hello, i've installed Mageia Alpha1 in Virtual Box 4.0.2 for now. What i dislike at the installer is, that i can't choose on which hard-drive to install the bootloader, or is it just disabled when having only one hard drive? Because when i want to install Mageia on my old Notebook, I need to install it on a external 2,5 hard drive because my cd-rom drive doesn't work anymore, and when he installes the bootloader on the wrong hard drive that would be quit bad. -- Mit freundlichen Grüßen Greetings Daniel Kreuter IIRC you can select where GRUB gets installed from the Summary page in the installer, i.e. the bootloader isn't installed before you pass this page IIRC. P.S. you don't need to add [mageia-dev] manually to the subject, the ML does that automatically for you. -- Ahmad Samir
Re: [Mageia-dev] Mageia 1 alpha 1 is out
On 15 February 2011 20:13, Dick Gevers dvgev...@xs4all.nl wrote: On Tue, 15 Feb 2011 02:12:10 +0100, Anne nicolas wrote about [Mageia-dev] Mageia 1 alpha 1 is out: This time was the right one: http://blog.mageia.org/?p=492 Many thanks to all who worked on bootstrap, build system, artowrk, packaging, cleaning... and made possible that first step for Mageia. We need your feedbacks. Very good. A historic day :) Downloading the iso now. If I find any bugs (not likely ;) that are already reported in Mandriva Bugzilla and I think the package is m.o.l. identical, do I report it again in Mageia Bugzilla or leave it as is? Thanks, =Dick Gevers= Please, report it in the Mageia bugzilla, so fixing it can be tracked for Mageia :) -- Ahmad Samir
Re: [Mageia-dev] [584] - update the version in the Makefile
On 20 February 2011 04:47, Thierry Vignaud thierry.vign...@gmail.com wrote: On 19 February 2011 17:25, r...@mageia.org wrote: Revision584AuthorahmadDate2011-02-20 02:25:37 +0100 (Sun, 20 Feb 2011) Log Message - update the version in the Makefile Please update NEWS at well... We used to commit NEWS when relevant every time we commit something important, including releasing a new version I updated/committed NEWS before the updating/committing the Makefile, sortty about that. Could we have a sort of howto for each of the stuff in svn/soft? for example https://bugs.mageia.org/show_bug.cgi?id=113 Modifying the string in the relevant .pm file is the easy part, but not generating the .pot/po... -- Ahmad Samir
[Mageia-dev] Text (log) attachment to bugzilla
Hi. This is just a reminder, when attaching a text log to a bug report in bugzilla, make sure to set the content type to text/plain, leaving it as auto-detect doesn't work (this is an old bug, the same issue happened in mdv bugzilla). Thanks. -- Ahmad Samir
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
On 22 February 2011 20:09, andre999 and...@laposte.net wrote: aside First of all, tainted in English implies that the software doesn't work. (Unless it refers to food, in which case it means poisonous.) So we should choose a more appropriate name, such as constrained, or use the Ubuntu approach and use a name which doesn't literally describe the contents. (Multiverse, in their case.) Anything but something that implies that there is something inherently wrong with the package in question. That was one advantage of plf, but of course that is already taken. And it is certainly advantageous to include such packages directly on Mageia mirrors. /aside A Cleaner approach -- albeit more work -- would be for the constrained package to be an external module which adds the missing functionality. For less modular packages, this would be replacing (only) the files which provide the questioned functionality. For a typical a music player-type application, this would be only a be a few relatively small files. So a user that wants to add the contrained functionality would simply add an extra package, which obviously would have a different name based on the main package. (It would be useful to suggest adding such packages during installation, if the contrained repositories are selected.) (That is, if such a related package is available in selected repos.) Think of the gstreamer packages -- the ugly perhaps corresponding to the constrained packages being considered. my 2 cents :) -- André Just a small note, if you didn't like the colour of the bike shed you should have discussed the point before it was built, painted, the paint has dried and is about to have new residents. And if you discussed the issue and your POV wasn't adapted, what's the point re-emerging it now given that changing the new isn't easy now that the infra- is already in place. I like the name tainted, (note that the kernel does use the word tainted to indicate there's a non-open source binary blob/driver e.g. with the nvidia proprietary driver, so this usage is not unheard of). :) -- Ahmad Samir
[Mageia-dev] Firefox requires
ATM firefox has:
Requires: xulrunner = %{xulrunner_version}%{?prel:-0.%prel}
this renders firefox unusable when xulrunner is updated, for example
*xulrunner* was updated to 2.0-0.b12, while firefox isn't available
yet on the mirrors (at the time when I updated my box). I think the
requires need to be tighter:
Requires: xulrunner = %{xulrunner_version}%{?prel:-0.%prel}
so that firefox doesn't break on users' systems until new firefox
packages reach the mirrors.
If no one objects I'll change the requires tomorrow.
--
Ahmad Samir
Re: [Mageia-dev] Firefox requires
On 28 February 2011 20:43, tmb t...@iki.fi wrote:
mån 2011-02-28 klockan 20:33 +0200 skrev Ahmad Samir:
ATM firefox has:
Requires: xulrunner = %{xulrunner_version}%{?prel:-0.%prel}
this renders firefox unusable when xulrunner is updated, for example
*xulrunner* was updated to 2.0-0.b12, while firefox isn't available
yet on the mirrors (at the time when I updated my box). I think the
requires need to be tighter:
Requires: xulrunner = %{xulrunner_version}%{?prel:-0.%prel}
so that firefox doesn't break on users' systems until new firefox
packages reach the mirrors.
If no one objects I'll change the requires tomorrow.
Yeah,
it needs strict requires to work, so go ahead.
--
Thomas
The change is done.
--
Ahmad Samir
[Mageia-dev] Bugs mailing list, new bugs Subject line
At the moment when a new bug report is filed bugzilla adds the string New: to the subject line of the email, this is removed in subsequent emails (once the bug is not new any more, i.e. more comments were added... etc). This is a sort of an unofficial poll about how many people out there find this useful (or not). -- Ahmad Samir
Re: [Mageia-dev] xserver-1.10
On 1 March 2011 23:28, Dexter Morgan dmorga...@gmail.com wrote: On Tue, Mar 1, 2011 at 8:59 PM, Thierry Vignaud thierry.vign...@gmail.com wrote: Hi As xserver-1.10 has just been released, I offer to do the upgrade like I did the xserver-1.7 - xserver-1.9 upgrade in Mandriva : - wait for most drivers to be compatible - test xserver+basic drivers - upload xserver-1.10 + rebuild drivers into core/testing - wait for more test coverage - fix issues - wait for fglrx+nvidia to be ready for 1.10 (thx to Ubuntu, they should support it fast enough) - move packages from core/testing into core/release (expecting rpmctl or something equivalent to be available or spamming sysadmins) WDYT? See you seems perfect for me too Yeah, perfect. FWIW, nvidia-current-270.29 in Mageia officially supports XServer-1.10 c.f. http://www.nvnews.net/vbulletin/showthread.php?p=2396539 -- Ahmad Samir
Re: [Mageia-dev] Bugs mailing list, new bugs Subject line
On 2 March 2011 12:01, Thierry Vignaud thierry.vign...@gmail.com wrote: On 2 March 2011 07:28, Yann Ciret mag...@zamiz.net wrote: I prefer the actual system with always same subject. It's easier to follow the subject in mail client software. If the subject will change with bug life, I am not sure Thunderbird can group all messages as a conversation. Indeed. it's annoying for filtering Actually, no, thunderbird doesn't break the thread of a bug due to this issue, as it doesn't use just the subject to group emails. (I don't use it extensively but I did test some email clients, mainly to ease my job in the triage team in Mandriva, and now in Mageia, but since I mostly use the bug report web page in bugzilla, using gmail (web mail) in firefox is the best solution so far, even though the bug mail threads get broken all the time). Up till now, stormi and boklm (the latter wants to bring back adding the Resolved to the subject of closed bugs :)), find this useful, along with others who think it's nice to have it. I can't ask for the removal of this feature just to suit my usage. (Now, if I'd asked dmorgan to just remove the New: keyword from new bug reports email Subject when we started using bugzilla, without asking, no one would have noticed; yeah, democracy is bad sometimes :)). -- Ahmad Samir
Re: [Mageia-dev] shared bugzilla searches
On 3 March 2011 18:05, Thierry Vignaud thierry.vign...@gmail.com wrote: Hi Just announcing I'm sharing some searches here: https://bugs.mageia.org/userprefs.cgi?tab=saved-searches I'ven't yet imported all my usefull searches from mdv bugz but it'll be done See you FWIW, I've been stuck with bugzilla for the past 2-3 years, never used saved search, which does look like a neat feature; thanks for the heads up :) -- Ahmad Samir
Re: [Mageia-dev] Contributors using real name/working email? or not? or maybe?
On 3 March 2011 16:00, Romain d'Alverny rdalve...@gmail.com wrote: [...] The points to decide here are: a) should a contributor provide a public email address, to be used in changelogs, commits and everywhere her contribution to the project needs an id or contact id? (for instance changelog, commit, document authoring) Yes. b) should a contributor provide a real name for the same goals? Yes. or is a fake name/alias ok, as long as there are people that do know/meet the person? That's the user's choice/problem/issue. Emails/names appear in changelogs everywhere I look, if someone doesn't want his email/name to appear publicly, then use an alternative email/name, that's a choice given to the user when he/she creates an account in identity/upstream bugzilla / any public ML / forum /whatever. -- Ahmad Samir
Re: [Mageia-dev] Bugs mailing list, new bugs Subject line
On 2 March 2011 19:37, nicolas vigier bo...@mars-attacks.org wrote: On Wed, 02 Mar 2011, Ahmad Samir wrote: On 2 March 2011 12:01, Thierry Vignaud thierry.vign...@gmail.com wrote: On 2 March 2011 07:28, Yann Ciret mag...@zamiz.net wrote: I prefer the actual system with always same subject. It's easier to follow the subject in mail client software. If the subject will change with bug life, I am not sure Thunderbird can group all messages as a conversation. Indeed. it's annoying for filtering Actually, no, thunderbird doesn't break the thread of a bug due to this issue, as it doesn't use just the subject to group emails. Mail clients usually use In-Reply-To: or References: headers to thread mails. But it seems gmail is also using subjects for this. However according to this, text inside square brackets is ignored : http://www.quora.com/Is-it-possible-to-change-or-add-words-to-the-subject-of-a-Gmail-email-and-keep-it-in-the-same-thread So if we add '[New]' instead of 'New:' in the subject, maybe this would fix the problem with gmail ? Yeah, that works, dmorgan tested and it works, he's applied the changes. Thanks a bunch :) -- Ahmad Samir
Re: [Mageia-dev] RFT: x11-server 1.10
On 5 March 2011 20:56, Thomas Backlund t...@iki.fi wrote: Hi, All of you that want to test x11-server 1.10 can do so now. all drivers have been updated/fixed to work with it, so... Just enable Updates Testing and do: urpmi --auto-update reboot (pray) I have tested x86_64 on a laptop with ati HD2600 and a workstation ati HD5770 and eveything seems to work so far... Have fun... -- Thomas Works here too, proprietary driver, Nvidia GTX 260. Works with nv driver too. However the nouveau driver doesn't work, booting the system the monitor is turned off and I can't even switch to tty. -- Ahmad Samir
Re: [Mageia-dev] RFT: x11-server 1.10
On 5 March 2011 22:54, Thomas Backlund t...@iki.fi wrote: lör 2011-03-05 klockan 22:08 +0200 skrev Ahmad Samir: Works here too, proprietary driver, Nvidia GTX 260. Works with nv driver too. However the nouveau driver doesn't work, booting the system the monitor is turned off and I can't even switch to tty. Can you try nouveau again when x11-driver-video-nouveau-0.0.16-0.20110303.3.mga1 hits the mirrors... -- Thomas x11-driver-video-nouveau-0.0.16-0.20110303.3.mga1 works (in the brief test I did). -- Ahmad Samir
[Mageia-dev] Firefox prefs: insertRelatedAfterCurrent
ATM Firefox is shipped with: user_pref(browser.tabs.insertRelatedAfterCurrent, false); upstream ships this pref set to 'true'. From http://kb.mozillazine.org/About:config_entries: This preference controls where new tabs will be located. True (default): Open new tabs to the right of the parent tab. False: Restores pre Firefox 3.6 behavior where new tabs are opened at the far right of the tabs bar. IMHO, we should ship the upstream default (they do spend sometime on usability... etc). (On a personal note I've had this set to true since it was implemented and I find it quite useful). WDYT? If no one objects I'll apply the changes in 1-2 days. -- Ahmad Samir
Re: [Mageia-dev] Firefox prefs: insertRelatedAfterCurrent
On 6 March 2011 04:45, Maarten Vanraes maarten.vanr...@gmail.com wrote: Op zondag 06 maart 2011 03:24:46 schreef Hoyt Duff: I've always set mine to false. When they open adjacent to the current tab (true) that always seems like reverse order when reading a book. For example, click on the links in a page that are page1, page2, page3 and so on in order. With 'true', the tabs show the pages in reverse order. i prefer false as well, for the exact same reason. Again, it's not about personal preferences; you know how to change it, but not every average Joe out there knows that about:config exists to begin with. -- Ahmad Samir
Re: [Mageia-dev] RFT: x11-server 1.10
2011/3/6 Jérôme (saispo) Soyer sai...@gmail.com: It's 4.0.4. The DKMS module in Mageia is not rebuilt againt xorg 1.1.0 ? On Sun, Mar 6, 2011 at 12:20 PM, Thomas Backlund t...@iki.fi wrote: sön 2011-03-06 klockan 12:47 +0200 skrev Jérôme (saispo) Soyer: Hi, I have error for me with the VirtualBox drivers. Maybe a recompilation is needed for the rpm but with the original VirtualBox Guest Additions i have an ABI error. What VirtualBox version ? Only 4.0.4 supports xorg 1.10 -- Thomas Yes, vbox will need a rebuild, only 1.9 video drivers are compiled for the additions, I'll take care of that today by pushing vbox packages to core/testing. -- Ahmad Samir
Re: [Mageia-dev] RFT: x11-server 1.10
On 6 March 2011 18:01, Ahmad Samir ahmadsamir3...@gmail.com wrote: 2011/3/6 Jérôme (saispo) Soyer sai...@gmail.com: It's 4.0.4. The DKMS module in Mageia is not rebuilt againt xorg 1.1.0 ? On Sun, Mar 6, 2011 at 12:20 PM, Thomas Backlund t...@iki.fi wrote: sön 2011-03-06 klockan 12:47 +0200 skrev Jérôme (saispo) Soyer: Hi, I have error for me with the VirtualBox drivers. Maybe a recompilation is needed for the rpm but with the original VirtualBox Guest Additions i have an ABI error. What VirtualBox version ? Only 4.0.4 supports xorg 1.10 -- Thomas Yes, vbox will need a rebuild, only 1.9 video drivers are compiled for the additions, I'll take care of that today by pushing vbox packages to core/testing. -- Ahmad Samir Rebuilt vbox is in core/testing now. -- Ahmad Samir
Re: [Mageia-dev] Alpha2 iso content
On 7 March 2011 19:51, Thomas Lottmann skipercoo...@gmail.com wrote: Le 07/03/2011 18:40, Oliver Burger a écrit : Am Samstag 05 März 2011, 02:37:24 schrieb Kira: Please have a look an check what could be missing as important packages and we will see how we can deal with it With mplayer, I suggest adding smplayer into the list? It's the most common mplayer front end, and way better than other mplayer based program. Nothing against mplayer (and especially smplayer, which I use a lot), but couldn't we go back to have kaffeine as default kde media player? Oliver I'm personally not sure that Kaffeine is stable enough. I never had a great experience of Kaffeine, it seemed it's GUI was quite unclean. Dragon Player seemed fine, but far too simple. ...perhaps Kmplayer? It has a few bugs, but it may be more easy to patch them upstream. It is a KDE frontend for powerfull Mplayer. Mplayer and its KDe frontend is by the only player able to read Full HD videos fluently. Just suggesting... IMHO, if mplayer is ever installed by default, then smplayer should be installed by default (it's the most feature-rich GUI for mplayer). Both kaffeine and dragon are simplistic players, if we have to choose one of them, it'll be dragon (being the upstream default player). Kaffeine doesn't use phonon any more, it uses libxine directly... -- Ahmad Samir
Re: [Mageia-dev] Firefox prefs: insertRelatedAfterCurrent
OK, changes applied. -- Ahmad Samir
Re: [Mageia-dev] Firefox prefs: insertRelatedAfterCurrent
On 7 March 2011 09:48, Michael Scherer m...@zarb.org wrote: On Sun, 6 Mar 2011 16:32:20 -0500, Hoyt Duff wrote: On 3/6/11, Thierry Vignaud thierry.vign...@gmail.com wrote: On 6 March 2011 21:11, Colin Guthrie mag...@colin.guthr.ie wrote: I find myself in the same scenario quite regularly too (20+ tabs) and find having the new tab at least quite close to the current one a massive usability improvement. Indeed. The reverse is annoying. It's also interesting to see the reverse order argument mentioned previously doesn't always apply. There are some heuristics in there as to whether it should be opened immediately to the right of the current tab or after the other tabs that have been opened recently. Tabs should not extend off the screenbut instead wrap and to multiple rows, IMHO. Then, it start to become more like a 2nd windows manager, and we go back to the MDI metaphor of win95. Another view would be that too much tabs is usually a sign that most of them are not needed now, and should not be shown. But this requires a more high level interface ( ie, sometimes that say put the link to a 'read later' list / place it with other easy to access documentation rather than a very low level operation like open a new tab to fullfill all possible needs regarding opening a windows ) -- Michael Scherer I've found that if I put it in a read later folder/list/bookmark, that there's a 70% chance that I'll I never read it :) FWIW, now firefox-4.0 has a new feature, when you save the session the next time you open it it only loads 3 tabs from each window, leaves the rest not loaded until you open it. http://blog.zpao.com/post/1140456188/cascaded-session-restore-a-hidden-bonus (Just to have a jab at the off-topic discussion :p). -- Ahmad Samir
Re: [Mageia-dev] Firefox prefs: insertRelatedAfterCurrent
On 8 March 2011 01:13, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Maarten Vanraes at 07/03/11 19:21 did gyre and gimble: sometimes i just have alot of different tabs, perhaps it would be easier to have tabs on the right side (most of us have widescreen monitors anyway). There is a plugin for that (or there was... can't remember as it was a friend who used it rather than me :)) Col https://addons.mozilla.org/en-US/firefox/addon/108862/ -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] -- Ahmad Samir
Re: [Mageia-dev] RPM5 AND MAGEIA
2011/3/9 Raphaël Jadot ashledom...@hodo.fr: 2011/3/8 Balcaen John balcaen.j...@gmail.com: Le Tuesday 08 March 2011 18:11:11, Per Øyvind Karlsen a écrit : [...] Tsktsk, my post probably ends up being labelled as flamebait, troll, too long and boring, biased and what not.. [...] This list is not write only... If you've got personnal problem with dmorgan just send him a personal email i don't care, but i guess that ennael wrote 3 hours before this last mail from you that mageia seems to have choose rpm.org so maybe we can really close this subject/thread for now instead of talking again again about the fantastic rpm(5).org feature/upstream/it's a revolution/another apple commercial here/etc etc. It's just boring... mm ? I have not the feeling that it was the subject... i read again... ok he seems to have a great +1 to rpm5, but i did not see that he wanted insisted or moan in order we use rpm5... The mails are hard to read, and long, and very technicals, but what catched my eyes is some things like level of compatibility between Mageia rpm5 is far greater than any other (with other rpm5 based distros being more compatible with Mageia than Mageia is with non-rpm5 based distros as well So it doesn't mean we have to move to rpm5 for being compatible with rpm5, so where is the problem ? I just wonder, why having discussions about technical things like adults is impossible ? are rpm.org and rpm5 religions ? So if Per Oyvind offers help, unless there are hidden things i do not understand, and if he can improve rpm.org or compatibility stuff or whatever, why nobody says ok, why not, tell us, maybe you could help, maybe not Did not find it (at least in this ML) Seems it's not the first time, in this mail https://www.mageia.org/pipermail/mageia-dev/20110109/002024.html he told (if interested, I could help assist you on writing something equivalent for compatibility wrapping similar to what I did in the past with rpm4compat.h rpm46compat.h to make ie. URPM able to use rpm 4.4 4.6 api with rpm5, let's say rpm5compat.h or something). Whatever you end up doing, don't be afraid of asking or trying to communicate on, the mutual benefits of collaboration are rather obvious. ;o) If not, sorry for imposing. This mail had no answer, so what, is this guy a kind of antichrist of rpm , talking with sugar words and trying to backstab you ? And at least, If the question are asked over and over, why is there so few things in archives about it ? Sure every one knows mageia will not hurry to go to rpm5 tomorow, and so what ? If some are bored about some related questions, why not opening a FAQ that explain it, or that just point to the related archive/topic (which could be this one) ? Sorry but I hate people bashing when i don't understand it. So if there are personal anger, try to get over, or explain and communicate better. RJ Hi, How many times is Mageia going to say thanks, but no thanks? how many more bug reports/breakage does cooker have to suffer to make it clear that Mageia doesn't want the same headache, in the near future at all? Personally I don't want to see mageia-dev ML have the same rpm5-main-water-pipe explode in it like what happened in cooker@, suddenly rpm5 is the answer to everything, from Jeff Johnson's point of view, well, good for you. :) You wanna know why people can't communicate better? see how long proyvind's emails usually are. You didn't get bored? :) -- Ahmad Samir
Re: [Mageia-dev] RFT: x11-server 1.10
On 9 March 2011 09:57, Thierry Vignaud thierry.vign...@gmail.com wrote: On 7 March 2011 10:40, Colin Guthrie mag...@colin.guthr.ie wrote: Forgot to say, but my machine also uses synaptics. It too appears to be working fine. Updated status: = All major video drivers seems to works fine: vesa, ATI/AMD, Intel, Nvidia (nv/nouveau/nvidia) Less important drivers that works: virtualbox Most major input drivers seems to works fine: evdev,synaptics, wacom. We need testing for: - video: fb[1], fglrx vmware. - input: joystick[2], [1] will be used by the installer [1] not sure we'd testers back at mdv anyway. I'll resurrect a sis box tomorrow. fglrx is still MIA with X server 1.10, AFAIK (I last checked 1-2 days ago), there's a bug report about a user who updated from core/testing and ended with a non-working X. -- Ahmad Samir
Re: [Mageia-dev] default kde media player
IMHO, we should stick with dragon, it's a simple player usable for average users; also there's a good chance upstream will switch to phonon-vlc (or Mageia may switch to phonon-vlc when it stabilises more), so the best of both worlds :) (at such time it'll be easier to just add vlc main package as it won't add much space, and phonon*gstreamer* stuff won't have to be on the ISO, so the net weight should balance out...). Also we should be thinking about the size of the Live ISO, putting vlc/mplayer/smplayer will bring more weight, and it'll be at the expense of some other useful packages that should exist on the ISO (we shouldn't forget users use the Live ISO as a test-run, demonstration of what a distro offers... etc). -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron core/release wine-gecko-1.1.0-2.mga1
On 11 March 2011 09:41, Thierry Vignaud thierry.vign...@gmail.com wrote: On 11 March 2011 00:04, Mageia Team buildsystem-dae...@mageia.org wrote: ahmad ahmad 1.1.0-2.mga1: + Revision: 67279 - imported package wine-gecko This one is 32bit only. However I was under the impression that newer versions work on x86_64 too From the spec, by Anssi: “# We would need a mingw64 crosscompiler for a 64-bit binary. # NOTE: building this package as-is on x86_64 will build a 32-bit binary instead. ExclusiveArch: %ix86” -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron core/release playonlinux-3.8.8-2.mga1
On 12 March 2011 20:49, Tux99 tux99-...@uridium.org wrote: Quote: Samuel Verschelde wrote on Sat, 12 March 2011 12:35 Then isn't the problem that wine and wine64 can't be both installed ? And isn't there a way to allow that ? but they can be, or at least the current Mageia packages allow it: $ rpm -qa|grep wine wine64-1.3.15-1.mga1 wine-gecko-1.1.0-2.mga1 wine32-1.3.15-1.mga1 lib64kwineffects1-4.6.1-1.mga1 $ I didn't force anything they both installed cleanly along each other. But you can't install 'wine' and 'wine64' at the same time. -- Ahmad Samir
Re: [Mageia-dev] Remove php-pear-Date-Holidays_Norway
On 13 March 2011 19:31, Thomas Spuhler tho...@btspuhler.com wrote: can someone who has the powers remove php-pear-Date-Holidays_Norway It's broken with a dependency and upstream just declines to acknowledge and fix it. -- Thomas It's not an upstream bug, it's a corner case caused by the rpm auto-provides/requires in Mageia. You can fix it by using _requires_exceptions -- Ahmad Samir
[Mageia-dev] RFT: Thunderbird, gnomevfs vs. GIO
gnome-vfs has been deprecated by Gvfs/GIO a long time ago[1]. I think now is a good time thunderbird gets built with gio support (and disable gnome-vfs support); it's long enough before Mageia's first stable release that bugs with tb-with-gio-support can be fixed or the change reverted. If no one objects I'll push a new package; so when/if that happens, keep an eye out on thunderbird in Cauldron and report any issues that hit you after updating. [1] https://fedoraproject.org/wiki/Features/Gvfs -- Ahmad Samir
Re: [Mageia-dev] default kde media player
On 17 March 2011 22:38, Remy CLOUARD shikam...@mandriva.org wrote: On Tue, Mar 15, 2011 at 02:26:53PM +0100, Michael Scherer wrote: Le vendredi 11 mars 2011 à 16:45 +0100, Remy CLOUARD a écrit : Ok, so let’s drop firefox too, install epiphany and konqueror instead. (maybe those are already installed aside firefox ?) I do use epiphany and konqueror ( when i was under kde ). If we follow one way, let’s be consistent with that ;) Good, so we are 2 in favor of dropping firefox. -- Michael Scherer Well, I couldn’t care less since I’m using neither KDE nor GNOME and we are talking about defaults for these DE :-) That's “awesome”! :) -- Rémy CLOUARD () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- Ahmad Samir
