Re: [Mageia-dev] Mageia 2 - Improving educational programs
2011/6/9 Angelo Naselli anase...@linux.it Hi i'd like to add an item to mageia 2 specification, e.g. improving the educational part. (Already added into wiki) . WDYT? -- Angelo I think is a good task and I will help Angelo. First we need to discuss if develop under KDE or also Gnome (2), taking into consideration also the old hardware on which usually it's installed. -- Stblack
Re: [Mageia-dev] Mageia 2 - Improving educational programs
On Fri, Jun 10, 2011 at 10:09 AM, Angelo Naselli anase...@linux.it wrote: WDYT? I'd add that this task could be a good start for padawans, well i could try to mentor someone here :) ... easier if we're going to be a team in this task (if dmorgan agrees and joins me/us :p ) Yes of course :)
Re: [Mageia-dev] Mageia 2 - Improving educational programs
Hi Stefano, I think is a good task and I will help Angelo. Thanks. First we need to discuss if develop under KDE or also Gnome (2), taking into consideration also the old hardware on which usually it's installed. Well I know you and probably what you mean... but it's really hard to understand :) There's nothing to choose in the first two items - well maybe a little bit in the second one :) - I mean importing programs is not related to a specific DE, if that program has been developed using a library more than another it will run better in a DE that is written for that library (e.g. gtk/gnome or qt/kde for instance), but that does not avoid using such a program into other DEs ;) Now let's see if i understood your point, if you mean about live-cd well yes something has to be decided, but that's not a big priority task, i'd like to have a more user friendly installable and with a wide choice system concerning educational programs first. After that we could add more configuration files to draklive implementing one or more specific edu-tasks. WDYT? Cheers, Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Mageia 2 - Improving educational programs
Dexter Morgan dmorga...@gmail.com schrieb am 10.06.2011 On Fri, Jun 10, 2011 at 10:09 AM, Angelo Naselli anase...@linux.it wrote: WDYT? I'd add that this task could be a good start for padawans, well i could try to mentor someone here :) ... easier if we're going to be a team in this task (if dmorgan agrees and joins me/us :p ) Yes of course :) Last year at some German linux event I was talking with a guy from Seminarix, a project providing a Sidux/Aptosid based distro for teachers-to-be. So we could take their software collection as an example and look what's left to do. Oliver
Re: [Mageia-dev] Mageia 2 - Improving educational programs
venerdì 10 giugno 2011 alle 10:26, Oliver Burger ha scritto: Last year at some German linux event I was talking with a guy from Seminarix, a project providing a Sidux/Aptosid based distro for teachers-to-be. So we could take their software collection as an example and look what's left to do. Sounds good, can you add a link please? I'd prefer to go on this subject here on ML and add a wiki page later, but if someone has time can add it already... As a reminder, i started porting programs shown here: http://www.schoolforge.net/ Thanks Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
'Twas brillig, and Ahmad Samir at 09/06/11 17:42 did gyre and gimble: On 9 June 2011 14:22, Oliver Burger oliver@googlemail.com wrote: Dexter Morgan dmorga...@gmail.com schrieb am 09.06.2011 On Thu, Jun 9, 2011 at 11:54 AM, Colin Guthrie mag...@colin.guthr.ie wrote: I think updates would be the right place. Please no 3rd repo :) But i agree with you for updates for new packages ( no new versions ;) ) I would prefer using updates over backports as well. If we use backports we would get more problems then benefit (like people not having backports enabled or people having backports enabled and thus getting problems they can't handle e.g. with new kernels, graphic drivers and so on). Perhaps we could upload them to updates/testing for a really short qa before moving them to updates/ ? Oliver If it's pushed to /updates then it should be imported to the stable release SVN tree; note that at some point Cauldron could get a newer version than the one in /updates, and maybe it's not backportable, new deps, regressions... etc. But now if there's a bug in the version in the stable */updates, and it needs a patch, what are you gonna base the patch on if you submit directly from the Cauldron SVN checkout to */updates, and the Cauldron package has already changed? But if new package can go directly to updates.. that doesn't look right to me, because at which point will new packages stop going to a stable release */updates? if it goes on and on, then we're talking about a semi-cauldron-like repo. So just svn cp it to the /1/updates tree in svn and job's a good 'un. (well svn cp is no longer just one step due to source separation, but the principle is the same!). Also note that a new package in Cauldron gets tested for a while (depending at which point it was imported during the release cycle), but if gets pushed to /updates and not backports (which is not supported), that testing period is short-circuited. Yeah but then the examples I've got so far are: * trac * supybot * supybot-Meetbot * passwd-gen * dd_rescue In all these cases, these are packages I use. I will be testing them on that version of the distro. And when I don't use them every day, (e.g. passwd-gen, dd_rescue), they are pretty standard, stable and standalone apps. IMO we can over-analyse the risk factor here massive to the detriment of the overall offering. Col -- 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/]
Re: [Mageia-dev] Mageia 2 - Improving educational programs
Le jeudi 9 juin 2011 23:28:45, Angelo Naselli a écrit : i'd like to add an item to mageia 2 specification, e.g. improving the educational part. (Already added into wiki) Do you know http://www.abuledu.org/en/accueil ? This is a free/libre project created in 1999 and very dynamic. Ryxeo offers a professional support. The first release was built on Mandrake but was difficult to maintain. Then the project has migrated on Debian and Ubuntu because of this. It is perhaps the good time to make Abuledu running on Mageia. Eric Seigne is the leader of the Abuledu project since 1999. -- Pierre Jarillon - http://pjarillon.free.fr/ Vice-président de l'ABUL : http://abul.org/ Microsoft est à l'informatique ce que McDonald est à la gastronomie.
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
Le vendredi 10 juin 2011 10:56:35, Colin Guthrie a écrit : 'Twas brillig, and Ahmad Samir at 09/06/11 17:42 did gyre and gimble: On 9 June 2011 14:22, Oliver Burger oliver@googlemail.com wrote: Dexter Morgan dmorga...@gmail.com schrieb am 09.06.2011 On Thu, Jun 9, 2011 at 11:54 AM, Colin Guthrie mag...@colin.guthr.ie wrote: I think updates would be the right place. Please no 3rd repo :) But i agree with you for updates for new packages ( no new versions ;) ) I would prefer using updates over backports as well. If we use backports we would get more problems then benefit (like people not having backports enabled or people having backports enabled and thus getting problems they can't handle e.g. with new kernels, graphic drivers and so on). Perhaps we could upload them to updates/testing for a really short qa before moving them to updates/ ? Oliver If it's pushed to /updates then it should be imported to the stable release SVN tree; note that at some point Cauldron could get a newer version than the one in /updates, and maybe it's not backportable, new deps, regressions... etc. But now if there's a bug in the version in the stable */updates, and it needs a patch, what are you gonna base the patch on if you submit directly from the Cauldron SVN checkout to */updates, and the Cauldron package has already changed? But if new package can go directly to updates.. that doesn't look right to me, because at which point will new packages stop going to a stable release */updates? if it goes on and on, then we're talking about a semi-cauldron-like repo. So just svn cp it to the /1/updates tree in svn and job's a good 'un. (well svn cp is no longer just one step due to source separation, but the principle is the same!). Also note that a new package in Cauldron gets tested for a while (depending at which point it was imported during the release cycle), but if gets pushed to /updates and not backports (which is not supported), that testing period is short-circuited. Yeah but then the examples I've got so far are: * trac * supybot * supybot-Meetbot * passwd-gen * dd_rescue In all these cases, these are packages I use. I will be testing them on that version of the distro. And when I don't use them every day, (e.g. passwd-gen, dd_rescue), they are pretty standard, stable and standalone apps. IMO we can over-analyse the risk factor here massive to the detriment of the overall offering. Col I agree with Colin here. Samuel
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process)
Le jeudi 09 juin 2011 à 10:14 +0100, Colin Guthrie a écrit : Hi, As I upgrade my various machines (I only really have about 5, so not that many) I'm running into a few packages that are missing (this is inevitable). Nothing major just little things like trac and supybot etc. What is the best way to add these packages to the v1 tree? Using backports seems a little odd as this is unsupported and we don't really want to encourage using it as a means to get the missing packages. If we do not want to have people use backports, we wouldn't have added it in the first place. I do think backport is perfectly suited for that. release is obviously frozen so no go there. The only real option is updates, but that should obviously have some QA on it. Updates is not for new version of software, not for new softwares. And backporting something from cauldron is not a update. Perhaps we need to have some kind of exemption to get these missing packages added? Does anyone have any opinions on this? Yes, I do. We have used backports in the past for that, and I see no reason to change that. If the problem is that backports were too buggy in the past, then we should fix backports process, not bypassing them. And if we start by pushing new version in update, people will soon wonder why the new version of X is in updates, while the new version of Y is not, just because we didn't have X in release and Y was there. -- Michael Scherer
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
Le vendredi 10 juin 2011 à 09:56 +0100, Colin Guthrie a écrit : 'Twas brillig, and Ahmad Samir at 09/06/11 17:42 did gyre and gimble: But if new package can go directly to updates.. that doesn't look right to me, because at which point will new packages stop going to a stable release */updates? if it goes on and on, then we're talking about a semi-cauldron-like repo. So just svn cp it to the /1/updates tree in svn and job's a good 'un. (well svn cp is no longer just one step due to source separation, but the principle is the same!). The bin repository is a different svn, so it will not work. -- Michael Scherer
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
'Twas brillig, and Michael Scherer at 10/06/11 11:29 did gyre and gimble: Le vendredi 10 juin 2011 à 09:56 +0100, Colin Guthrie a écrit : 'Twas brillig, and Ahmad Samir at 09/06/11 17:42 did gyre and gimble: But if new package can go directly to updates.. that doesn't look right to me, because at which point will new packages stop going to a stable release */updates? if it goes on and on, then we're talking about a semi-cauldron-like repo. So just svn cp it to the /1/updates tree in svn and job's a good 'un. (well svn cp is no longer just one step due to source separation, but the principle is the same!). The bin repository is a different svn, so it will not work. Isn't that what I said? (I referred to the binary sources as just source). I maintain the principle is still the same albeit we need to do a bit more tweaking/scripting, or am I missing something? Col -- 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/]
Re: [Mageia-dev] Mageia 2 - Improving educational programs
venerdì 10 giugno 2011 alle 11:44, Pierre Jarillon ha scritto: Le jeudi 9 juin 2011 23:28:45, Angelo Naselli a écrit : i'd like to add an item to mageia 2 specification, e.g. improving the educational part. (Already added into wiki) Do you know http://www.abuledu.org/en/accueil ? This is a free/libre project created in 1999 and very dynamic. Ryxeo offers a professional support. The first release was built on Mandrake but was difficult to maintain. Then the project has migrated on Debian and Ubuntu because of this. It is perhaps the good time to make Abuledu running on Mageia. Eric Seigne is the leader of the Abuledu project since 1999. Pierre, honestly it's hard to me following that site, nice at first sight but in French for the most :/ Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
'Twas brillig, and Michael Scherer at 10/06/11 11:27 did gyre and gimble: Le jeudi 09 juin 2011 à 10:14 +0100, Colin Guthrie a écrit : Hi, As I upgrade my various machines (I only really have about 5, so not that many) I'm running into a few packages that are missing (this is inevitable). Nothing major just little things like trac and supybot etc. What is the best way to add these packages to the v1 tree? Using backports seems a little odd as this is unsupported and we don't really want to encourage using it as a means to get the missing packages. If we do not want to have people use backports, we wouldn't have added it in the first place. I do think backport is perfectly suited for that. So the user that just wants to install supybot has to expose themselves to the risk of updating to a backported version of gnome or KDE this is hardly ideal. Especially for novice users. release is obviously frozen so no go there. The only real option is updates, but that should obviously have some QA on it. Updates is not for new version of software, not for new softwares. And backporting something from cauldron is not a update. This seems like a strange statement as */updates on mdv was allowed to have new packages in some cases (I've done it before, although I think only for * == contrib), so I don't see why we have to restrict this possibility in Mageia. Perhaps we need to have some kind of exemption to get these missing packages added? Does anyone have any opinions on this? Yes, I do. We have used backports in the past for that, and I see no reason to change that. This is fine in the regular course of distro evolution, but here we're talking about users migrating from Mdv to Mga and finding stale Mdv packages still installed on their system when they want (and we want to provide) a Mageia version. This is very much a special case for this transitional period but I feel it's an important one, particularly *because* it's the first release. I think you're thinking in absolute terms rather than transitional terms. In absolute terms I agree with you on principle, but I think we need to deal with transitional issues gracefully and not treat them as second class considerations. If the problem is that backports were too buggy in the past, then we should fix backports process, not bypassing them. I don't think this is particularly relevant. Backports are unsupported generally. That's a given. If we encourage people to enable backports to get missing packages (this is very distinct and separate from the unsupported backports). And if we start by pushing new version in update, people will soon wonder why the new version of X is in updates, while the new version of Y is not, just because we didn't have X in release and Y was there. I very much consider nothing - version X quite different from version X - version Y. I don't think it's a hard concept for anyone to grasp. Col -- 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/]
Re: [Mageia-dev] Problems with Gnome 3
Le jeudi 09 juin 2011 à 10:49 +0100, Colin Guthrie a écrit : 'Twas brillig, and Wolfgang Bornath at 09/06/11 10:25 did gyre and gimble: 2011/6/9 JA Magallón jamagal...@ono.com: No need, Cauldron is Cauldron. The only strange thing is that I had heard on other threads that update to Gnome 3 was being discussed, but never realized it had finally agreed on. Same here, I'm a bit surprised. We're on the next cycle now. Quite frankly I'd be stunned (and hugely disappointed) if we *didn't* have Gnome 3! While I have no issue with gnome-shell, I have read enough reports of people not happy with it to know we would head to a 2nd kde 4.0 story. So maybe we could start to learn from the past and discuss with users to explain the update, see why they do not want etc, instead of being purely focused on it is cauldron, let's update everything. -- Michael Scherer
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
[Didn't finish this sentence] 'Twas brillig, and Colin Guthrie at 10/06/11 11:44 did gyre and gimble: I don't think this is particularly relevant. Backports are unsupported generally. That's a given. If we encourage people to enable backports to get missing packages (this is very distinct and separate from the unsupported backports) ... then we will end up having to support people who have accidentally updated to a backported package they didn't intend or want to install. This is likely more hassle for us in the long run. Col -- 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/]
Re: [Mageia-dev] Problems with Gnome 3
On 06/10/2011 06:46 AM, Michael Scherer wrote: While I have no issue with gnome-shell, I have read enough reports of people not happy with it to know we would head to a 2nd kde 4.0 story. So maybe we could start to learn from the past and discuss with users to explain the update, see why they do not want etc, instead of being purely focused on it is cauldron, let's update everything. +1 3 is rumored to have a lot of ideological change, and probably the usual GNOME removal of working stuff that people expect to be there (GDM config). It would be very nice to have a tool to switch back and forth for experimentation, at least a minimal list of things from each release that can be removed via rpm --nodeps prior to reinstalling the other release, so that urpmi doesn't try to remove the world to make the change.
Re: [Mageia-dev] Problems with Gnome 3
在 Fri, 10 Jun 2011 19:20:41 +0800, Frank Griffin f...@roadrunner.com寫道: On 06/10/2011 06:46 AM, Michael Scherer wrote: While I have no issue with gnome-shell, I have read enough reports of people not happy with it to know we would head to a 2nd kde 4.0 story. So maybe we could start to learn from the past and discuss with users to explain the update, see why they do not want etc, instead of being purely focused on it is cauldron, let's update everything. +1 3 is rumored to have a lot of ideological change, and probably the usual GNOME removal of working stuff that people expect to be there (GDM config). It would be very nice to have a tool to switch back and forth for experimentation, at least a minimal list of things from each release that can be removed via rpm --nodeps prior to reinstalling the other release, so that urpmi doesn't try to remove the world to make the change. In the past time, there's KDE3 and KDE4 co-exist together in the repository, maybe we can do it again?
Re: [Mageia-dev] Problems with Gnome 3
2011/6/10 Kira elegant.pega...@gmail.com: 在 Fri, 10 Jun 2011 19:20:41 +0800, Frank Griffin f...@roadrunner.com寫道: On 06/10/2011 06:46 AM, Michael Scherer wrote: While I have no issue with gnome-shell, I have read enough reports of people not happy with it to know we would head to a 2nd kde 4.0 story. So maybe we could start to learn from the past and discuss with users to explain the update, see why they do not want etc, instead of being purely focused on it is cauldron, let's update everything. +1 3 is rumored to have a lot of ideological change, and probably the usual GNOME removal of working stuff that people expect to be there (GDM config). It would be very nice to have a tool to switch back and forth for experimentation, at least a minimal list of things from each release that can be removed via rpm --nodeps prior to reinstalling the other release, so that urpmi doesn't try to remove the world to make the change. In the past time, there's KDE3 and KDE4 co-exist together in the repository, maybe we can do it again? maybe 1 wait to have gnome 3 and then speak about gnome2
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process)
2011/6/10 Michael Scherer m...@zarb.org: We have used backports in the past for that, and I see no reason to change that. If the problem is that backports were too buggy in the past, then we should fix backports process, not bypassing them. And if we start by pushing new version in update, people will soon wonder why the new version of X is in updates, while the new version of Y is not, just because we didn't have X in release and Y was there. Problem I see: So far (in Mandriva), example: we have used 2010.0/main/backports to offer new versions of software which had an older version in 2010/main but the newer version in 2010.1/main, or as the name says: backporting a newer version of a software from the current release to a previous release, as often used for Firefox. For Mageia it means, /backports should hold backports of software which has an older version in 1/core but a newer version in cauldron. If we put new software (aka missing packages) in /backports and the user activates /backports he also runs the risk that existing packages of his stable installation will be replaced by real backports of newer versions, backported from Cauldron - which he may not want to do. I wonder why we do not put these missing packages in /testing and after a while in /core or /non-free or /tainted (wherever they belong). These packages are software which were supposed to be in /core or /non-free or /tainted, they were just forgotten|came too late|whatever for Mageia 1 release freeze. -- wobo
Re: [Mageia-dev] [RFC] Removing .la files
On Fri, Jun 10, 2011 at 12:41:46PM +0200, Michael Scherer wrote: Le vendredi 10 juin 2011 à 03:47 +0300, Ahmad Samir a écrit : On 9 June 2011 19:35, Dexter Morgan dmorga...@gmail.com wrote: Hello, as other distributions we started to remove .la files from mageia during mageia 1 development. Could you explain the rational of removing them ? AFAIK, the .la removal was not discussed, so starting by saying we remove them now because last time, we didn't discussed and it broke lots of thing is a little bit weird. https://live.gnome.org/GnomeShell/RemovingLaFiles Seems some distributions misunderstand the need and changed the wiki page. Removing .la files is needed however, otherwise you'll quickly mix distribution installed libraries and self-compiled libraries. Difficulty is that this only works when you remove *all* .la files. If only one is left compilation is broken. -- Regards, Olav
Re: [Mageia-dev] Problems with Gnome 3
2011/6/10 Michael Scherer m...@zarb.org: Le jeudi 09 juin 2011 à 10:49 +0100, Colin Guthrie a écrit : 'Twas brillig, and Wolfgang Bornath at 09/06/11 10:25 did gyre and gimble: 2011/6/9 JA Magallón jamagal...@ono.com: No need, Cauldron is Cauldron. The only strange thing is that I had heard on other threads that update to Gnome 3 was being discussed, but never realized it had finally agreed on. Same here, I'm a bit surprised. We're on the next cycle now. Quite frankly I'd be stunned (and hugely disappointed) if we *didn't* have Gnome 3! While I have no issue with gnome-shell, I have read enough reports of people not happy with it to know we would head to a 2nd kde 4.0 story. So maybe we could start to learn from the past and discuss with users to explain the update, see why they do not want etc, instead of being purely focused on it is cauldron, let's update everything. I do have a problem with gnome-shell, that is my individual opinion. But I also read a lot of discussions among Gnome users where the new way of Gnome seems to split the community much more than the KDE3.5 to KDE4 change. This has been said already way back when we started to get the first requests for Gnome3 in Mageia1. Since that time we always told the users that implementing Gnome3 will be subject to discussion after the Mageia 1 release. So I was a bit surprised that this was done kind of automagically without any discussion. Besides this I agree to Michael's suggestion. -- wobo
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
Wolfgang Bornath skrev 10.6.2011 14:44: 2011/6/10 Michael Schererm...@zarb.org: We have used backports in the past for that, and I see no reason to change that. If the problem is that backports were too buggy in the past, then we should fix backports process, not bypassing them. And if we start by pushing new version in update, people will soon wonder why the new version of X is in updates, while the new version of Y is not, just because we didn't have X in release and Y was there. Problem I see: So far (in Mandriva), example: we have used 2010.0/main/backports to offer new versions of software which had an older version in 2010/main but the newer version in 2010.1/main, or as the name says: backporting a newer version of a software from the current release to a previous release, as often used for Firefox. For Mageia it means, /backports should hold backports of software which has an older version in 1/core but a newer version in cauldron. If we put new software (aka missing packages) in /backports and the user activates /backports he also runs the risk that existing packages of his stable installation will be replaced by real backports of newer versions, backported from Cauldron - which he may not want to do. I wonder why we do not put these missing packages in /testing and after a while in /core or /non-free or /tainted (wherever they belong). These packages are software which were supposed to be in /core or /non-free or /tainted, they were just forgotten|came too late|whatever for Mageia 1 release freeze. well, media/*/release tree is frozen, so _nothing_ new goes in there. So the path would then be */updates_testing - */updates _if_ we decide that's the way to go... Problem is that a missing package introcuced in updates also can introduce regressions with wrong obsoletes/provides or %pre/%post scripts. So it has to go through the same qa as the rest of the stuff heading for */updates So question becomes, do we have enough qa/security people to make it work ? And if we introduce filtering on what goes in and what does not, then who decides ? -- Thomas
Re: [Mageia-dev] [RFC] Removing .la files
On Fri, Jun 10, 2011 at 1:51 PM, Olav Vitters o...@vitters.nl wrote: On Fri, Jun 10, 2011 at 12:41:46PM +0200, Michael Scherer wrote: Le vendredi 10 juin 2011 à 03:47 +0300, Ahmad Samir a écrit : On 9 June 2011 19:35, Dexter Morgan dmorga...@gmail.com wrote: Hello, as other distributions we started to remove .la files from mageia during mageia 1 development. Could you explain the rational of removing them ? AFAIK, the .la removal was not discussed, so starting by saying we remove them now because last time, we didn't discussed and it broke lots of thing is a little bit weird. https://live.gnome.org/GnomeShell/RemovingLaFiles Seems some distributions misunderstand the need and changed the wiki page. Removing .la files is needed however, otherwise you'll quickly mix distribution installed libraries and self-compiled libraries. Difficulty is that this only works when you remove *all* .la files. If only one is left compilation is broken. -- Regards, Olav i will try a new way to remove them and btw we maybe should add a rpmlint reject to reject packages with la files inside . but not yet as we may need to still build some the time of the transition.
Re: [Mageia-dev] Problems with Gnome 3
On 06/10/2011 07:44 AM, Dexter Morgan wrote: maybe 1 wait to have gnome 3 and then speak about gnome2 Could you post here when all of the GNOME3 packages are in Cauldron ?
Re: [Mageia-dev] Problems with Gnome 3
On 06/10/2011 07:39 AM, Kira wrote: In the past time, there's KDE3 and KDE4 co-exist together in the repository, maybe we can do it again? Good idea. I'm not much of a KDE user, but I noticed that the DMs offered both KDE3 and 4, which seems like a very easy way to switch back and forth (if setting it up isn't too much work).
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
Thomas Backlund t...@mageia.org schrieb am 10.06.2011 So the path would then be */updates_testing - */updates _if_ we decide that's the way to go... As I see it, it's the only user friendly way. Using backports is fine for experienced users who do know what to install from backports or who are capable of facing the consequences. If a total newbie asks fort a package in the forums and is pointed to backports he is in great danger of wrecking his system by installing some new kernel, graphics driver, desktop or whatever, precisely because there is no real qa on backports. Oliver
Re: [Mageia-dev] Mageia 2 - Improving educational programs
On Fri, Jun 10, 2011 at 10:22 AM, Angelo Naselli anase...@linux.it wrote: Hi Stefano, I think is a good task and I will help Angelo. Thanks. First we need to discuss if develop under KDE or also Gnome (2), taking into consideration also the old hardware on which usually it's installed. Well I know you and probably what you mean... but it's really hard to understand :) There's nothing to choose in the first two items - well maybe a little bit in the second one :) - I mean importing programs is not related to a specific DE, if that program has been developed using a library more than another it will run better in a DE that is written for that library (e.g. gtk/gnome or qt/kde for instance), but that does not avoid using such a program into other DEs ;) Now let's see if i understood your point, if you mean about live-cd well yes something has to be decided, but that's not a big priority task, i'd like to have a more user friendly installable and with a wide choice system concerning educational programs first. After that we could add more configuration files to draklive implementing one or more specific edu-tasks. WDYT? Cheers, Angelo To run the educational programs even on new hardware and on old ones, i would propose not to choose kde or gnome. XFCE or LXDE would be a better choice i think. But it's only my point of view. As you mentioned, we don't need to decide that now. At first we need the programs than we can decide to create a live-cd out of it. -- Mit freundlichen Grüßen Greetings Daniel Kreuter
Re: [Mageia-dev] Problems with Gnome 3
On 2011.06.10, at 14:16, Frank Griffin wrote: On 06/10/2011 07:44 AM, Dexter Morgan wrote: maybe 1 wait to have gnome 3 and then speak about gnome2 Could you post here when all of the GNOME3 packages are in Cauldron ? And perhaps build a task-gnome rpm, so we can get all the dependencies for sure ? -- J.A. Magallon jamagallon()ono!com \ Software is like sex: \ It's better when it's free
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
Le vendredi 10 juin 2011 à 11:44 +0100, Colin Guthrie a écrit : 'Twas brillig, and Michael Scherer at 10/06/11 11:27 did gyre and gimble: Le jeudi 09 juin 2011 à 10:14 +0100, Colin Guthrie a écrit : Hi, As I upgrade my various machines (I only really have about 5, so not that many) I'm running into a few packages that are missing (this is inevitable). Nothing major just little things like trac and supybot etc. What is the best way to add these packages to the v1 tree? Using backports seems a little odd as this is unsupported and we don't really want to encourage using it as a means to get the missing packages. If we do not want to have people use backports, we wouldn't have added it in the first place. I do think backport is perfectly suited for that. So the user that just wants to install supybot has to expose themselves to the risk of updating to a backported version of gnome or KDE this is hardly ideal. Especially for novice users. One alternative would be to make sure that backports for version 1 are fully supported and break nothing. release is obviously frozen so no go there. The only real option is updates, but that should obviously have some QA on it. Updates is not for new version of software, not for new softwares. And backporting something from cauldron is not a update. This seems like a strange statement as */updates on mdv was allowed to have new packages in some cases (I've done it before, although I think only for * == contrib), so I don't see why we have to restrict this possibility in Mageia. contrib/updates was basically not watched at all. People could send anything without trouble, and there was no policy ( nor any enforcement ). That's not really the best example to use :) Perhaps we need to have some kind of exemption to get these missing packages added? Does anyone have any opinions on this? Yes, I do. We have used backports in the past for that, and I see no reason to change that. This is fine in the regular course of distro evolution, but here we're talking about users migrating from Mdv to Mga and finding stale Mdv packages still installed on their system when they want (and we want to provide) a Mageia version. This is very much a special case for this transitional period but I feel it's an important one, particularly *because* it's the first release. All releases are equal. And we warned that we would not be able to do everything, so of course, we will have problem with those that lived on Mars under a rock, but I think that most people know that we couldn't have all. I think you're thinking in absolute terms rather than transitional terms. In absolute terms I agree with you on principle, but I think we need to deal with transitional issues gracefully and not treat them as second class considerations. It was not clear for me from your mail that this would be temporary. So I assume we can agree to enforce the new packages go to backports unless very specific and defined exceptions policy for version 2 of the release ? If this is temporary, it would be ok, provided we follows the usual rules about handling updates. As we do not want to have untested rpms backported in */updates, this mean that package must be checked by QA before ( and proper testing for a new rpm is more that just checking it doesn't break ). So it should follow the proper policy ( once we agreed on that ). As discussed in the previous thread, that would for example mean that the packager that submit the backport is not the one testing it and giving the go, even if he can test before submitting to avoid wasting QA time. Since we want to restrict to package that people have used and missed for upgrade, I would also add that this part should be checked and requires : - a bug report saying upgrade failed due to that - if we want to be inclusive, a forum post could do the trick ( provided it is in english, or a bug referencing the forum ) - package must be kept upgradable from mandriva 2010.1 - ideally, the upgrade path should be tested, but I am pretty sure that people will not :). Finally, I would also add that as soon a package is in updates or release, the usual rules should apply ( ie, no more exception ). If I push the package to */updates once getmail because it is missing, but the next package do not go to */updates unless it fullfill the usual rules. Any following backports goes to */backports. And, just to be clear, the policy only apply to version 1, for x86_64 and i586. One question would be what is a pacakge requires a complex backport, for example, someone yesterday asked for darcs, that requires ghc, that requires bootstrapping. Yes, no ? Why ? If the problem is that backports were too buggy in the past, then we should fix backports process, not bypassing them. I don't think this is particularly relevant. Backports are unsupported generally. That's a given. Before, it
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit : Thomas Backlund t...@mageia.org schrieb am 10.06.2011 So the path would then be */updates_testing - */updates _if_ we decide that's the way to go... As I see it, it's the only user friendly way. Using backports is fine for experienced users who do know what to install from backports or who are capable of facing the consequences. If a total newbie asks fort a package in the forums and is pointed to backports he is in great danger of wrecking his system by installing some new kernel, graphics driver, desktop or whatever, precisely because there is no real qa on backports. He can also wait for the release. Or he can enable backport just for the time needed to install and then disable it. I think rpmdrake have some stuff for that. -- Michael Scherer
[Mageia-dev] perl 5.14.0 should arrive soon
hi, perl 5.14.0 should arrive soon. it compiles fine on both i586 x86_64, and it seem we fixed the only problem arisen in perl-URPM. since other packages need to be rebuilt in the same loop, and given that urpmi is written in perl, it needs a special treatment to bypass the regular bs upload. blino will likely do this magic dance upload them in the coming hours - you may want to wait till his final go before updating your cauldron box. once this is done, it's still not time to update the perl modules to their latest version: binary perl modules need to be rebuilt against perl 5.14. to get the list: $ urpmf --requires :perlapi-5.12 | cut -d: -f1 | sort -u there are 364 of them at the time of speaking. and of course some of them need to be rebuilt before others. [0] == help is welcome to rebuild them [1] to rebuild one of those binary packages: 1- wait for blino to announce perl 5.14.0 availability 2- check out the package 3- bump mkrel in package spec file 4- mgarepo submit 5- if build fails on bs, then it's likely that a missing binary module is missing: proceed the missing package thanks, jérôme [0] note to self: i'll create a magpie sort command to order those... but it's a bit too late for now. it'll be ready for perl 5.16 in one year! :-) [1] i should not be able to work on it this week-end, so feel free to give it a try.
Re: [Mageia-dev] Problems with Gnome 3
Le vendredi 10 juin 2011 à 07:20 -0400, Frank Griffin a écrit : On 06/10/2011 06:46 AM, Michael Scherer wrote: While I have no issue with gnome-shell, I have read enough reports of people not happy with it to know we would head to a 2nd kde 4.0 story. So maybe we could start to learn from the past and discuss with users to explain the update, see why they do not want etc, instead of being purely focused on it is cauldron, let's update everything. +1 3 is rumored to have a lot of ideological change, and probably the usual GNOME removal of working stuff that people expect to be there (GDM config). The gdm config is more a missing feature due to rewrite not finished than a removal. I am running gnome 3 since 1 month, and I didn't even used a extension to change anything. My main issue is more that not everything is finished ( like I miss the timezone clock stuff to see when to call on USAs and rest of Europa ) And again, most changes in gnome-shell are justified in the light of newer computing experiences ( tablet, touchscreen ) but whatever people do, there is a transition period. There is a few discutable decision ( the alt key to poweroff being the one ) but I think there isn't much, when compared to the others good changes. -- Michael Scherer
Re: [Mageia-dev] [RFC] Removing .la files
Le vendredi 10 juin 2011 à 14:12 +0200, Dexter Morgan a écrit : On Fri, Jun 10, 2011 at 1:51 PM, Olav Vitters o...@vitters.nl wrote: i will try a new way to remove them and btw we maybe should add a rpmlint reject to reject packages with la files inside . but not yet as we may need to still build some the time of the transition. Better do like gentoo and debian, and remove them on build time. ( like we strip binary, etc ) ( yes, that mean more work to you as the rpm maintainer than me as rpmlint maintainer :) ) -- Michael Scherer
Re: [Mageia-dev] Problems with Gnome 3
On Fri, Jun 10, 2011 at 3:11 PM, Olav Vitters o...@vitters.nl wrote: On Fri, Jun 10, 2011 at 02:59:58PM +0200, Michael Scherer wrote: My main issue is more that not everything is finished ( like I miss the timezone clock stuff to see when to call on USAs and rest of Europa ) That's planned for 3.2 btw. -- Regards, Olav which is planned for october iirc no ? so good for mageia 2 :)
Re: [Mageia-dev] Problems with Gnome 3
On Fri, Jun 10, 2011 at 03:17:10PM +0200, Dexter Morgan wrote: On Fri, Jun 10, 2011 at 3:11 PM, Olav Vitters o...@vitters.nl wrote: On Fri, Jun 10, 2011 at 02:59:58PM +0200, Michael Scherer wrote: My main issue is more that not everything is finished ( like I miss the timezone clock stuff to see when to call on USAs and rest of Europa ) That's planned for 3.2 btw. which is planned for october iirc no ? Yes (Sep 28), see www.gnome.org/start/unstable (standard link for the current schedule) so good for mageia 2 :) Indeed :) -- Regards, Olav
Re: [Mageia-dev] Supybot rpms rebuilt on mageia
Le jeudi 09 juin 2011 à 15:40 -0400, Lee a écrit : I was asked to look into supybot and meetbot to work on patches an fixes. First things first I had to rebuild rpms for my mageia 1 system (i586). I built the following from src rpms: supybot-0.83.4.1-1.mga1.noarch.rpm supybot-Dcc-0.83.4.1-1.mga1.noarch.rpm supybot-ExternalNotice-0.83.4.1-1.mga1.noarch.rpm supybot-Gateway-0.83.4.1-1.mga1.noarch.rpm supybot-Meetbot-0.1.4-2.mga1.noarch.rpm supybot-Sshd-0.83.4.1-1.mga1.noarch.rpm supybot-Webserver-0.83.4.1-1.mga1.noarch.rpm I don't have a mentor, I'm not a packager, and nobody so far has ported these packages over. And the ones I have here haven't been officially 'cleansed' but they work. Not sure how to move forward from here. I will import them ( was on my todo list, as that's why I done the supybot meetbot plugin rpm ). -- Michael Scherer
Re: [Mageia-dev] get-skype package for submission
Le 2011-06-09 19:56, Barry Jackson a écrit : I have been working on a package to install Skype current stable release and now feel that it is ready for submission for approval. It has already been improved/corrected/adapted many times following discussions on #mageia-mentoring where I have been given lots of help. The idea evolved here https://bugs.mageia.org/show_bug.cgi?id=154 where the current version is available as an attachment. https://bugs.mageia.org/attachment.cgi?id=551 It has been a challenge and I have learned a lot in working on this. :) Barry Hi Barry Thanks for doing this. I uncompressed the file. What is the difference between the 2 .rpms? You may want to include a readme in the package for people like me. Cheers Marc
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
On 10/06/11 13:54, Michael Scherer wrote: Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit : Thomas Backlundt...@mageia.org schrieb am 10.06.2011 So the path would then be */updates_testing - */updates _if_ we decide that's the way to go... As I see it, it's the only user friendly way. Using backports is fine for experienced users who do know what to install from backports or who are capable of facing the consequences. If a total newbie asks fort a package in the forums and is pointed to backports he is in great danger of wrecking his system by installing some new kernel, graphics driver, desktop or whatever, precisely because there is no real qa on backports. He can also wait for the release. Or he can enable backport just for the time needed to install and then disable it. I think rpmdrake have some stuff for that. Even though backports are disabled rpmdrake can display a list of available backports. (The sources are automatically updated by mgaonline.) A selected backport can then be installed, without enabling the backports source. (I've just tested this on mdv 2010.0, the only mdv system that I have available.) Jim
Re: [Mageia-dev] [RFC] Removing .la files
On Fri, 10 Jun 2011, Olav Vitters wrote: On Fri, Jun 10, 2011 at 12:41:46PM +0200, Michael Scherer wrote: Le vendredi 10 juin 2011 à 03:47 +0300, Ahmad Samir a écrit : On 9 June 2011 19:35, Dexter Morgan dmorga...@gmail.com wrote: Hello, as other distributions we started to remove .la files from mageia during mageia 1 development. Could you explain the rational of removing them ? AFAIK, the .la removal was not discussed, so starting by saying we remove them now because last time, we didn't discussed and it broke lots of thing is a little bit weird. https://live.gnome.org/GnomeShell/RemovingLaFiles ... but the dirty hacks that jhbuild plays ... Problems with dirty hacks are NOT a valid reason to remove libtool convenience libraries aka .la files. Seems some distributions misunderstand the need and changed the wiki page. Removing .la files is needed however, otherwise you'll quickly mix distribution installed libraries and self-compiled libraries. What are you talking about here? Difficulty is that this only works when you remove *all* .la files. If only one is left compilation is broken. It is more likely that your build system is broken. If you do not want to link against system libraries, remove /lib and /usr/lib from the library search dirs list. Christiaan
Re: [Mageia-dev] [RFC] Removing .la files
On Fri, Jun 10, 2011 at 04:15:01PM +0200, Christiaan Welvaart wrote: https://live.gnome.org/GnomeShell/RemovingLaFiles ... but the dirty hacks that jhbuild plays ... Problems with dirty hacks are NOT a valid reason to remove libtool convenience libraries aka .la files. Seems you skipped the initial bit, where it explains that the .la has the full path. Seems some distributions misunderstand the need and changed the wiki page. Removing .la files is needed however, otherwise you'll quickly mix distribution installed libraries and self-compiled libraries. What are you talking about here? The particular problem with these .la files is that they have hardcoded paths in them. So, for example, if /usr/lib/libgnome-menu.so just contains the information that it requires libglib-2.0.so.0 but /usr/lib/libgnome-menu.la says that it wants /usr/lib/libglib-2.0.la, it causes libtool to link against /usr/lib/libglib-2.0.so at link time. This is fine for a lot of typical build scenarios, but the dirty hacks that jhbuild plays to get it to sandbox your system understandably breaks. Difficulty is that this only works when you remove *all* .la files. If only one is left compilation is broken. It is more likely that your build system is broken. If you do not want to link against system libraries, remove /lib and /usr/lib from the library search dirs list. That's not enough, the .la files add libraries in /lib and /usr/lib. Fedora has for instance already removed the .la files. Other distributions are working on it (even Debian). -- Regards, Olav
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
On 10/06/11 15:09, James Kerr wrote: On 10/06/11 13:54, Michael Scherer wrote: Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit : Thomas Backlundt...@mageia.org schrieb am 10.06.2011 So the path would then be */updates_testing - */updates _if_ we decide that's the way to go... As I see it, it's the only user friendly way. Using backports is fine for experienced users who do know what to install from backports or who are capable of facing the consequences. If a total newbie asks fort a package in the forums and is pointed to backports he is in great danger of wrecking his system by installing some new kernel, graphics driver, desktop or whatever, precisely because there is no real qa on backports. He can also wait for the release. Or he can enable backport just for the time needed to install and then disable it. I think rpmdrake have some stuff for that. Even though backports are disabled rpmdrake can display a list of available backports. (The sources are automatically updated by mgaonline.) A selected backport can then be installed, without enabling the backports source. (I've just tested this on mdv 2010.0, the only mdv system that I have available.) I've just realised there is a potential problem with this. Because Mageia has /backports_testing repo's (mdv does not) packages from /backports_testing may also be displayed. Mgaonline is updating those sources. Jim
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
James Kerr j...@jkerr82508.free-online.co.uk schrieb am 10.06.2011 Even though backports are disabled rpmdrake can display a list of available backports. (The sources are automatically updated by mgaonline.) I make you parden, but: no! When a repo is disabled it doesn't get updated automatically and its packages are not to be found in rpmdrake. Did you confuse disabling repos and marking a repo for updates (sorry, me doesn't know the exact English strings). So you have to enable the backports repos and even though you don't mark them as update repos, urpmi will ignore that (rpmdrake won't but urpmi will) and will update everything from those repos... Oliver
Re: [Mageia-dev] [RFC] Removing .la files
On Fri, 10 Jun 2011, Olav Vitters wrote: On Fri, Jun 10, 2011 at 04:15:01PM +0200, Christiaan Welvaart wrote: https://live.gnome.org/GnomeShell/RemovingLaFiles ... but the dirty hacks that jhbuild plays ... Problems with dirty hacks are NOT a valid reason to remove libtool convenience libraries aka .la files. Seems you skipped the initial bit, where it explains that the .la has the full path. What's wrong with those paths? I'm saying the problem is in gnome-shell, not in the .la files. Seems some distributions misunderstand the need and changed the wiki page. Removing .la files is needed however, otherwise you'll quickly mix distribution installed libraries and self-compiled libraries. What are you talking about here? gnome-shell stuff So you are really talking only about gnome-shell, which I can't even test because apparently it doesn't work in a VM. It is now packaged, so you don't need to build it. Christiaan
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
On 10/06/11 15:27, Oliver Burger wrote: James Kerrj...@jkerr82508.free-online.co.uk schrieb am 10.06.2011 Even though backports are disabled rpmdrake can display a list of available backports. (The sources are automatically updated by mgaonline.) I make you parden, but: no! When a repo is disabled it doesn't get updated automatically and its packages are not to be found in rpmdrake. Did you confuse disabling repos and marking a repo for updates (sorry, me doesn't know the exact English strings). So you have to enable the backports repos and even though you don't mark them as update repos, urpmi will ignore that (rpmdrake won't but urpmi will) and will update everything from those repos... I meant exactly what I wrote. Select Backports from the first filter in rpmdrake and packages from disabled backports sources will be displayed. Check /var/log/auth.log to see what mgaonline is doing. Jim
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
'Twas brillig, and Michael Scherer at 10/06/11 13:51 did gyre and gimble: Le vendredi 10 juin 2011 à 11:44 +0100, Colin Guthrie a écrit : So the user that just wants to install supybot has to expose themselves to the risk of updating to a backported version of gnome or KDE this is hardly ideal. Especially for novice users. One alternative would be to make sure that backports for version 1 are fully supported and break nothing. That's certainly worth considering. This seems like a strange statement as */updates on mdv was allowed to have new packages in some cases (I've done it before, although I think only for * == contrib), so I don't see why we have to restrict this possibility in Mageia. contrib/updates was basically not watched at all. People could send anything without trouble, and there was no policy ( nor any enforcement ). That's not really the best example to use :) Hmm, I can't really disagree with that statement :D We have used backports in the past for that, and I see no reason to change that. This is fine in the regular course of distro evolution, but here we're talking about users migrating from Mdv to Mga and finding stale Mdv packages still installed on their system when they want (and we want to provide) a Mageia version. This is very much a special case for this transitional period but I feel it's an important one, particularly *because* it's the first release. All releases are equal. And we warned that we would not be able to do everything, so of course, we will have problem with those that lived on Mars under a rock, but I think that most people know that we couldn't have all. Quite. But if the only reason for not providing a particular service or offering is due to a policy (i.e. people want to provide and others want to consume) then it's perhaps the policy that need re-evaluating. Just because it's policy, doesn't mean it's the best solution. Pragmatism often solves a lot of problems. As I said before I think we can easily over analyse things... I think you're thinking in absolute terms rather than transitional terms. In absolute terms I agree with you on principle, but I think we need to deal with transitional issues gracefully and not treat them as second class considerations. It was not clear for me from your mail that this would be temporary. So I assume we can agree to enforce the new packages go to backports unless very specific and defined exceptions policy for version 2 of the release ? Yeah I'd personally be more than happy with that. If this is temporary, it would be ok, provided we follows the usual rules about handling updates. As we do not want to have untested rpms backported in */updates, this mean that package must be checked by QA before ( and proper testing for a new rpm is more that just checking it doesn't break ). So it should follow the proper policy ( once we agreed on that ). As discussed in the previous thread, that would for example mean that the packager that submit the backport is not the one testing it and giving the go, even if he can test before submitting to avoid wasting QA time. That all seems reasonable to me (although I think the QA people can also be a bit fast and loose with some requests (obviously at their own discretion) - e.g. I doubt they really need to massively test the impact to other packages of adding something like dd_rescue, more just test that it runs OK) Since we want to restrict to package that people have used and missed for upgrade, I would also add that this part should be checked and requires : - a bug report saying upgrade failed due to that - if we want to be inclusive, a forum post could do the trick ( provided it is in english, or a bug referencing the forum ) - package must be kept upgradable from mandriva 2010.1 - ideally, the upgrade path should be tested, but I am pretty sure that people will not :). Yeah I agree to that. I think that while you're right about testing the upgrade and that it will likely not be fully tested, we can still do a what version does mdv 2010.2 have?, what version do we have? Will it upgrade? conceptual test (i.e. ask the questions!) which should cover 98.23% of the cases). (made up stat obviously!) Finally, I would also add that as soon a package is in updates or release, the usual rules should apply ( ie, no more exception ). If I push the package to */updates once getmail because it is missing, but the next package do not go to */updates unless it fullfill the usual rules. Any following backports goes to */backports. Makes sense yes. And, just to be clear, the policy only apply to version 1, for x86_64 and i586. WFM. One question would be what is a pacakge requires a complex backport, for example, someone yesterday asked for darcs, that requires ghc, that requires bootstrapping. Yes, no ? Why ? If this kind of thing crops up, I think we can discuss it at the time. As we will have to
Re: [Mageia-dev] [RFC] Removing .la files
On Fri, Jun 10, 2011 at 04:35:57PM +0200, Christiaan Welvaart wrote: On Fri, 10 Jun 2011, Olav Vitters wrote: On Fri, Jun 10, 2011 at 04:15:01PM +0200, Christiaan Welvaart wrote: https://live.gnome.org/GnomeShell/RemovingLaFiles ... but the dirty hacks that jhbuild plays ... Problems with dirty hacks are NOT a valid reason to remove libtool convenience libraries aka .la files. Seems you skipped the initial bit, where it explains that the .la has the full path. What's wrong with those paths? I'm saying the problem is in gnome-shell, not in the .la files. You snipped the paragraph which explains it. To repeat: If you link against 1 system lib, the .la files will make it link to /usr/lib stuff, instead of the self compiled gtk or anything like that. If the .la does not exist (all of them), it links correctly. Seems some distributions misunderstand the need and changed the wiki page. Removing .la files is needed however, otherwise you'll quickly mix distribution installed libraries and self-compiled libraries. What are you talking about here? gnome-shell stuff It is not gnome-shell, it is jhbuild and doing development (mainly GNOME). Basic GNOME already has ~200 modules. So you are really talking only about gnome-shell, which I can't even test because apparently it doesn't work in a VM. It is now packaged, so you don't need to build it. Nope, I'm talking about doing development using jhbuild. E.g. if you want to contribute to GNOME, you'll have to get rid of all the .la files no matter which distribution you use. A new GNOME does not happen automatically. It requires people to compile the Git versions and committing stuff until a tarball is released and packaged. Making such development easier would result in a better GNOME, and I don't mind if the .la files stay, but prefer if they are removed. Jhbuild is also used by Wayland and Hildon btw. -- Regards, Olav
Re: [Mageia-dev] Mageia 2 - Improving educational programs
venerdì 10 giugno 2011 alle 14:29, Daniel Kreuter ha scritto: To run the educational programs even on new hardware and on old ones, i would propose not to choose kde or gnome. XFCE or LXDE would be a better choice i think. But it's only my point of view. That's the idea. I started build a lxde live-cd adding task-edu to see how big the image was... well i believe i should do a better configuration even if it's not so bigger than 800 Mb... As you mentioned, we don't need to decide that now. At first we need the programs than we can decide to create a live-cd out of it. Yes we need to work to make life easier to those of whom want install educational programs in mageia, then we can go on on this subject -imho of course- :) Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
Le vendredi 10 juin 2011 à 16:27 +0200, Oliver Burger a écrit : James Kerr j...@jkerr82508.free-online.co.uk schrieb am 10.06.2011 Even though backports are disabled rpmdrake can display a list of available backports. (The sources are automatically updated by mgaonline.) I make you parden, but: no! When a repo is disabled it doesn't get updated automatically and its packages are not to be found in rpmdrake. Did you confuse disabling repos and marking a repo for updates (sorry, me doesn't know the exact English strings). So you have to enable the backports repos and even though you don't mark them as update repos, urpmi will ignore that (rpmdrake won't but urpmi will) and will update everything from those repos... UI wise, I think it would make sense to have that ( even if a idea is not sufficient, and we need a patch ) : User search for a package, he should see the latest recommended version ( ie, release/updates ). If he say also provides newer versions, then we could show backports, with some indication that we provides a tested version, and a potentially newer ones. We can agree that everybody want something newer for some rpms, but few people want everything to be newer ( ie, now one run backports as a update media, I think ). So as much as I am against asking to users questions, we must show them the choice somewhere, in a non obstrusive way. And for testing integration, I think we could have a different workflow, maybe something linked to a bug reporting tool. I have a bug on kde and use some custom bug reporting tool, the tools notice that something could be tested, and say to the user we have a update candidate, do you want to test ? If unsure, say no ? -- Michael Scherer
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
Op vrijdag 10 juni 2011 17:18:54 schreef Michael Scherer: [...] UI wise, I think it would make sense to have that ( even if a idea is not sufficient, and we need a patch ) : User search for a package, he should see the latest recommended version ( ie, release/updates ). If he say also provides newer versions, then we could show backports, with some indication that we provides a tested version, and a potentially newer ones. We can agree that everybody want something newer for some rpms, but few people want everything to be newer ( ie, now one run backports as a update media, I think ). So as much as I am against asking to users questions, we must show them the choice somewhere, in a non obstrusive way. And for testing integration, I think we could have a different workflow, maybe something linked to a bug reporting tool. I have a bug on kde and use some custom bug reporting tool, the tools notice that something could be tested, and say to the user we have a update candidate, do you want to test ? If unsure, say no ? +1
Re: [Mageia-dev] [RFC] Removing .la files
On Fri, 10 Jun 2011, Olav Vitters wrote: On Fri, Jun 10, 2011 at 04:35:57PM +0200, Christiaan Welvaart wrote: On Fri, 10 Jun 2011, Olav Vitters wrote: On Fri, Jun 10, 2011 at 04:15:01PM +0200, Christiaan Welvaart wrote: Seems some distributions misunderstand the need and changed the wiki page. Removing .la files is needed however, otherwise you'll quickly mix distribution installed libraries and self-compiled libraries. What are you talking about here? gnome-shell stuff It is not gnome-shell, it is jhbuild and doing development (mainly GNOME). Basic GNOME already has ~200 modules. Then why did you quote the webpage instead of saying just that? So you are really talking only about gnome-shell, which I can't even test because apparently it doesn't work in a VM. It is now packaged, so you don't need to build it. Nope, I'm talking about doing development using jhbuild. E.g. if you want to contribute to GNOME, you'll have to get rid of all the .la files no matter which distribution you use. A new GNOME does not happen automatically. It requires people to compile the Git versions and committing stuff until a tarball is released and packaged. Making such development easier would result in a better GNOME, and I don't mind if the .la files stay, but prefer if they are removed. I think doing software development related to the system you're working on isn't easy. For example jhbuild may not like .la files but if you want to use static libraries supplied by the system, .la files are quite useful AFAIK. So why did you point to that webpage if it's not related to mageia at all, it's purely a jhbuild problem. If people are using a system with gnome installed to develop gnome, it's not strange they run into problems. And I wonder why they would have gnome related -devel packages installed in the first place, they're not needed to *use* the system software. Christiaan
Re: [Mageia-dev] [RFC] Removing .la files
On Fri, 2011-06-10 at 17:34 +0200, Christiaan Welvaart wrote: If people are using a system with gnome installed to develop gnome, it's not strange they run into problems. This is nonsense, sorry. It's no stranger than a KDE-user wanting to recompile kwrite or krita. And I wonder why they would have gnome related -devel packages installed in the first place, they're not needed to *use* the system software. Because they're developing. For example, I'm involved with the GIMP project (GIMP is an image editor), but I don't want to compile my own gnome, not all of it, so I have enough of the -devel packages to compile just what I need (libbabl, libgegl and gimp, basically). I currently need the .la files so that configure and libtool will find them, since I'm building in a private prefix, not overwriting the system gnome of course... although that need for .la files may change in the future. Successful Linux distributions have communities of developers around them developing applications. It's not only about high priests of Linux and users who don't compile anything... :) Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/
Re: [Mageia-dev] [RFC] Removing .la files
On 10 June 2011 17:56, Liam R E Quin l...@holoweb.net wrote: On Fri, 2011-06-10 at 17:34 +0200, Christiaan Welvaart wrote: If people are using a system with gnome installed to develop gnome, it's not strange they run into problems. This is nonsense, sorry. It's no stranger than a KDE-user wanting to recompile kwrite or krita. If you want a proper package, you should build in a clean chroot; just like the BS does, every single package is built in a clean chroot, that's a necessary measure to ensure the quality of the produced packages. If you don't build in a clean chroot, the build will pick all sorts of old/new libs from the system... :) [...] -- Ahmad Samir
[Mageia-dev] GNOME 2.32 borked
Just updated and rebooted a system which was last rebooted Jun 7, and both GDM and KDM fail to log into my GNOME DE with a greyish popup saying failed to load your GNOME session. /var/log/gdm/0.log shows a segfault backtrace in fglrx, but this could be a red herring, since KDE starts fine for the same user. The GNOME configuration for the user seems to be OK, because booting an earlier Mageia beta logs into the DE just fine. I've avoided installing GNOME3 by using urpmi --keep, but maybe some GNOME3 package slipped through that doesn't depend on the ones that want to remove 2.32 ? Anybody else ?
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process)
On Fri, 10 Jun 2011, Michael Scherer wrote: release is obviously frozen so no go there. The only real option is updates, but that should obviously have some QA on it. Updates is not for new version of software, not for new softwares. And backporting something from cauldron is not a update. Maybe we could change the definition of updates repository. Rather than a strict rule no new version and no new software in updates, we could have something like this : - updates : no regression, and no changes in interfaces / protocols / config files since last package. You could have a cron script updating from this repository and nothing should stop working. - backports : possible regressions and/or changes in interfaces / protocols / config files. Updates from this repository should not be installed automatically but checked by user.
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
On 10 June 2011 16:46, James Kerr j...@jkerr82508.free-online.co.uk wrote: On 10/06/11 15:27, Oliver Burger wrote: James Kerrj...@jkerr82508.free-online.co.uk schrieb am 10.06.2011 Even though backports are disabled rpmdrake can display a list of available backports. (The sources are automatically updated by mgaonline.) I make you parden, but: no! When a repo is disabled it doesn't get updated automatically and its packages are not to be found in rpmdrake. Did you confuse disabling repos and marking a repo for updates (sorry, me doesn't know the exact English strings). So you have to enable the backports repos and even though you don't mark them as update repos, urpmi will ignore that (rpmdrake won't but urpmi will) and will update everything from those repos... I meant exactly what I wrote. Select Backports from the first filter in rpmdrake and packages from disabled backports sources will be displayed. Check /var/log/auth.log to see what mgaonline is doing. Jim Jim is right; rpmdrake treats backports in a special way, and they do get updated even when they're disabled. urpmi won't install packages from them by default (unless you explicitly enable them or use e.g. 'urpmi --searchmedia Core\ Backports'); rpmdrake can show packages from disabled backports repos when you select the Backports filter, assuming they were correctly updated by mgaonline which is what mgaonline does by default. -- Ahmad Samir
Re: [Mageia-dev] [RFC] Removing .la files
'Twas brillig, and Ahmad Samir at 10/06/11 17:01 did gyre and gimble: On 10 June 2011 17:56, Liam R E Quin l...@holoweb.net wrote: On Fri, 2011-06-10 at 17:34 +0200, Christiaan Welvaart wrote: If people are using a system with gnome installed to develop gnome, it's not strange they run into problems. This is nonsense, sorry. It's no stranger than a KDE-user wanting to recompile kwrite or krita. If you want a proper package, you should build in a clean chroot; just like the BS does, every single package is built in a clean chroot, that's a necessary measure to ensure the quality of the produced packages. If you don't build in a clean chroot, the build will pick all sorts of old/new libs from the system... :) I seriously doubt people do want that. I don't want to compile from kernel, glibc upwards just to build 5 gnome or KDE modules I will want to use *some* system stuff and *some* self compiled stuff. Removal of .la files will make this much easier. I can't count the times I've had to do dirty hacks to work around these linking issues. Col -- 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/]
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
On 10.06.2011 17:28, Thorsten van Lil wrote: Am 10.06.2011 16:09, schrieb James Kerr: On 10/06/11 13:54, Michael Scherer wrote: Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit : Thomas Backlundt...@mageia.org schrieb am 10.06.2011 So the path would then be */updates_testing - */updates _if_ we decide that's the way to go... As I see it, it's the only user friendly way. Using backports is fine for experienced users who do know what to install from backports or who are capable of facing the consequences. If a total newbie asks fort a package in the forums and is pointed to backports he is in great danger of wrecking his system by installing some new kernel, graphics driver, desktop or whatever, precisely because there is no real qa on backports. He can also wait for the release. Or he can enable backport just for the time needed to install and then disable it. I think rpmdrake have some stuff for that. Even though backports are disabled rpmdrake can display a list of available backports. (The sources are automatically updated by mgaonline.) A selected backport can then be installed, without enabling the backports source. (I've just tested this on mdv 2010.0, the only mdv system that I have available.) Jim I've tested it on Mageia right now. I've activated Core-testing and see that there is one package inside it: iputils_20101006_3.mga1. After that I've disabled the testing repo and searched for iputils. Rpmdrake lists me the version 2.mga1. Therefore, rpmdrake only lists packages of the activated repos. Core-testing is not backports. The behavior depends on media name. -- Anssi Hannula
Re: [Mageia-dev] GNOME 2.32 borked
Le 10/06/2011 18:05, Frank Griffin a écrit : Just updated and rebooted a system which was last rebooted Jun 7, and both GDM and KDM fail to log into my GNOME DE with a greyish popup saying failed to load your GNOME session. /var/log/gdm/0.log shows a segfault backtrace in fglrx, but this could be a red herring, since KDE starts fine for the same user. The GNOME configuration for the user seems to be OK, because booting an earlier Mageia beta logs into the DE just fine. I've avoided installing GNOME3 by using urpmi --keep, but maybe some GNOME3 package slipped through that doesn't depend on the ones that want to remove 2.32 ? Anybody else ? Got the same problem this morning on a Mageia 1 RC that had not been updated for two weeks, and that I updated yesterday. (I wanted to keep it on MGA 1, but noticed too late that the repositories pointed to cauldron because it has not been updated with the right mga-release. I tried to avoid updating mga2 package, but go some) Same error message. Switched to icewm to be able to work. Daniel
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process)
On 10 June 2011 13:44, Wolfgang Bornath molc...@googlemail.com wrote: 2011/6/10 Michael Scherer m...@zarb.org: We have used backports in the past for that, and I see no reason to change that. If the problem is that backports were too buggy in the past, then we should fix backports process, not bypassing them. And if we start by pushing new version in update, people will soon wonder why the new version of X is in updates, while the new version of Y is not, just because we didn't have X in release and Y was there. Problem I see: So far (in Mandriva), example: we have used 2010.0/main/backports to offer new versions of software which had an older version in 2010/main but the newer version in 2010.1/main, or as the name says: backporting a newer version of a software from the current release to a previous release, as often used for Firefox. Firefox should always go to /updates, not backports, usually it has many sec fixed, so firefox and thunderbird are special cases. For Mageia it means, /backports should hold backports of software which has an older version in 1/core but a newer version in cauldron. If we put new software (aka missing packages) in /backports and the user activates /backports he also runs the risk that existing packages of his stable installation will be replaced by real backports of newer versions, backported from Cauldron - which he may not want to do. Then he shouldn't use backports; but the point is if a totally new package, to Mageia 1, that never existed in core, is in backports, the user shouldn't see any regression with regard to that package as his experience with it before using backports is null, it didn't exist. I wonder why we do not put these missing packages in /testing and after a while in /core or /non-free or /tainted (wherever they belong). These packages are software which were supposed to be in /core or /non-free or /tainted, they were just forgotten|came too late|whatever for Mageia 1 release freeze. There will always be late packages, always. One example is a new version of foo that was released two days before Mageia's release, it won't be submitted through freeze, but will go to backports. IMHO, backports is way to offer late packages to user, whether they're new packages or newer versions of packages in core/nonfree/tainted, instead of the user installing them from 3rd party repos or having to build them himself (not all users are savvy with [re]building src.rpm's). -- wobo -- Ahmad Samir
Re: [Mageia-dev] [RFC] Removing .la files
On 10 June 2011 18:24, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Ahmad Samir at 10/06/11 17:01 did gyre and gimble: On 10 June 2011 17:56, Liam R E Quin l...@holoweb.net wrote: On Fri, 2011-06-10 at 17:34 +0200, Christiaan Welvaart wrote: If people are using a system with gnome installed to develop gnome, it's not strange they run into problems. This is nonsense, sorry. It's no stranger than a KDE-user wanting to recompile kwrite or krita. If you want a proper package, you should build in a clean chroot; just like the BS does, every single package is built in a clean chroot, that's a necessary measure to ensure the quality of the produced packages. If you don't build in a clean chroot, the build will pick all sorts of old/new libs from the system... :) I seriously doubt people do want that. I don't want to compile from kernel, glibc upwards just to build 5 gnome or KDE modules I will want to use *some* system stuff and *some* self compiled stuff. Removal of .la files will make this much easier. I can't count the times I've had to do dirty hacks to work around these linking issues. Col I am not against removing them, but just deleting them in the specs at this point won't work (it would have worked at the beginning of the fork, we'd import packages without .la at all, if only this issue was raised 8months ago :)). It's an inter-dependency circle of hell; it'll have to be done in the chroot, by a helper script run as root to clean the dependency_libs field in .la files from .la deps. (What I said is still generally true, if you want to build a proper package you should do it in a clean chroot, which, of course, you already know :p). -- 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] get-skype package for submission
On 10.06.2011 02:56, Barry Jackson wrote: I have been working on a package to install Skype current stable release and now feel that it is ready for submission for approval. It has already been improved/corrected/adapted many times following discussions on #mageia-mentoring where I have been given lots of help. The idea evolved here https://bugs.mageia.org/show_bug.cgi?id=154 where the current version is available as an attachment. https://bugs.mageia.org/attachment.cgi?id=551 It has been a challenge and I have learned a lot in working on this. :) I didn't test it, but the problems I see now: 1. The MD5SUM isn't checked, IMO it should be. 2. On error you exit with || exit 1 but leave the files in /tmp, polluting it. 3. You cp files to %_datadir using a wildcard (*), but these files may not be removed on uninstallation as you only have filename lists for avatars/sounds/langs. While it may work now (I didn't test, I hope you did), this will cause unnoticed problems when the skype tarball contents change. 4. Provide the script/commandline used to create the filelist files. 5. Versionize the filelist files to make sure they are renegerated when the package is updated to a new version (avatars-%version.txt) 6. Your usage of /tmp seems unsafe security-wise. What if some user has created something under /tmp/skype-%version already? Instead use mktemp to create a temporary directory. 7. You never remove the tarball, and the tarball is not %ghost. Also BTW, here is a package of mine for gootleearth from 2006 that uses a similar system: http://www.zarb.org/cgi-bin/viewvc.cgi/plf/SPECS/non-free/googleearth/ No need to make it like that, just pointing it out in case there are some ideas you'd like to use. -- Anssi Hannula
Re: [Mageia-dev] [RFC] Removing .la files
Op vrijdag 10 juni 2011 18:26:56 schreef Colin Guthrie: [...] I call shenanigans. I do this kind of stuff all the time. It's easy to use a custom prefix (i.e. not /usr) if you select the right configure options. It means you get a working system but can also develop the next version. I've been doing this kind of stuff for years. The removal of the .la files will make this approach much easier. +1
Re: [Mageia-dev] GNOME 2.32 borked
On 06/10/2011 12:37 PM, Daniel Le Berre wrote: Got the same problem this morning on a Mageia 1 RC that had not been updated for two weeks, and that I updated yesterday. The following GNOME3 packages seem to have gotten installed in spite of --keep: gnome-icon-theme gnome-menus gnome-session gnome-terminal lib64gnomekbd7 lib64gnomekbd-common So it looks like the only way to recover is to go forward with GNOME3.
Re: [Mageia-dev] Problems with Gnome 3
On Fri, Jun 10, 2011 at 3:26 PM, Olav Vitters o...@vitters.nl wrote: On Fri, Jun 10, 2011 at 03:17:10PM +0200, Dexter Morgan wrote: On Fri, Jun 10, 2011 at 3:11 PM, Olav Vitters o...@vitters.nl wrote: On Fri, Jun 10, 2011 at 02:59:58PM +0200, Michael Scherer wrote: My main issue is more that not everything is finished ( like I miss the timezone clock stuff to see when to call on USAs and rest of Europa ) That's planned for 3.2 btw. which is planned for october iirc no ? Yes (Sep 28), see www.gnome.org/start/unstable (standard link for the current schedule) so good for mageia 2 :) Indeed :) -- Regards, Olav +1 I would also suggest to jump directly to Gnome 3.2 instead of 3.0 in Mageia 2 because they want to fix some of the annoying bugs and implement some cool features like the integration of Zeitgeist. -- Mit freundlichen Grüßen Greetings Daniel Kreuter
Re: [Mageia-dev] [RFC] Removing .la files
On Fri, 10 Jun 2011, Colin Guthrie wrote: 'Twas brillig, and Ahmad Samir at 10/06/11 17:01 did gyre and gimble: On 10 June 2011 17:56, Liam R E Quin l...@holoweb.net wrote: On Fri, 2011-06-10 at 17:34 +0200, Christiaan Welvaart wrote: If people are using a system with gnome installed to develop gnome, it's not strange they run into problems. This is nonsense, sorry. It's no stranger than a KDE-user wanting to recompile kwrite or krita. If you want a proper package, you should build in a clean chroot; just like the BS does, every single package is built in a clean chroot, that's a necessary measure to ensure the quality of the produced packages. If you don't build in a clean chroot, the build will pick all sorts of old/new libs from the system... :) I seriously doubt people do want that. I don't want to compile from kernel, glibc upwards just to build 5 gnome or KDE modules I will want to use *some* system stuff and *some* self compiled stuff. Removal of .la files will make this much easier. I can't count the times I've had to do dirty hacks to work around these linking issues. I hope you realize removal of those files is unlikely to solve all your linking issues, or maybe even none of them. As long as you have the .so files from the -devel packages installed, the software you build can be linked against those system libraries. Christiaan
Re: [Mageia-dev] [RFC] Removing .la files
On Fri, 10 Jun 2011, Colin Guthrie wrote: 'Twas brillig, and Christiaan Welvaart at 10/06/11 16:34 did gyre and gimble: If people are using a system with gnome installed to develop gnome, it's not strange they run into problems. I call shenanigans. I do this kind of stuff all the time. It's easy to use a custom prefix (i.e. not /usr) if you select the right configure options. It means you get a working system but can also develop the next version. I've been doing this kind of stuff for years. The removal of the .la files will make this approach much easier. Let's make one thing clear, however. These .la files are not created or installed by packagers, but rather by the build system of (in this case) gnome libraries. And maybe you are quite happy with the absolute paths in the .la files in your buildroot/prefix. Christiaan
Re: [Mageia-dev] GNOME 2.32 borked
Le 10/06/2011 18:37, Daniel Le Berre a écrit : Same error message. Switched to icewm to be able to work. xfce is also a good chose. But, we want try gnome 3 ;) -- Amicalement vOOotre Troumad Alias Bernard SIAUD mon site : http://troumad.org : ADD maths WEB... Pour la liberté http://www.developpez.net/forums/f17/systemes/linux/ N'envoyez que des documents avec des formats ouverts, comme http://fr.libreoffice.org
Re: [Mageia-dev] GNOME 2.32 borked
On Fri, 10 Jun 2011, Daniel Le Berre wrote: Le 10/06/2011 18:05, Frank Griffin a écrit : Just updated and rebooted a system which was last rebooted Jun 7, and both GDM and KDM fail to log into my GNOME DE with a greyish popup saying failed to load your GNOME session. Same error message. Switched to icewm to be able to work. Does it work with the new notification-daemon-0.7.1-1.mga2 ? Christiaan
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
James Kerr a écrit : On 10/06/11 15:09, James Kerr wrote: On 10/06/11 13:54, Michael Scherer wrote: Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit : Thomas Backlundt...@mageia.org schrieb am 10.06.2011 So the path would then be */updates_testing - */updates _if_ we decide that's the way to go... As I see it, it's the only user friendly way. Using backports is fine for experienced users who do know what to install from backports or who are capable of facing the consequences. If a total newbie asks fort a package in the forums and is pointed to backports he is in great danger of wrecking his system by installing some new kernel, graphics driver, desktop or whatever, precisely because there is no real qa on backports. He can also wait for the release. Or he can enable backport just for the time needed to install and then disable it. I think rpmdrake have some stuff for that. Even though backports are disabled rpmdrake can display a list of available backports. (The sources are automatically updated by mgaonline.) A selected backport can then be installed, without enabling the backports source. (I've just tested this on mdv 2010.0, the only mdv system that I have available.) I've just realised there is a potential problem with this. Because Mageia has /backports_testing repo's (mdv does not) packages from /backports_testing may also be displayed. Mgaonline is updating those sources. Jim That was a bug in rpmdrake. If you had updated the repos with backports media enabled, when the backports media was subsequently disabled, the previously available backports packages remained displayed/installable. But new backports were not added if the repos were updated with backports disabled. There was the same problem for other media (like non-free). Otherwise enabling/disabling backports (or any other media) wouldn't make any sense. -- André
Re: [Mageia-dev] Problems with Gnome 3
On Thu, 9 Jun 2011 10:45:03 +0200, JA Magallón jamagal...@ono.com wrote: Hi all... I have a problem with this first big change in Cauldron... I have a couple test boxes in which I have updated everything, and I can't get Gnome 3 to work properly. I suppose it is still work in progress, but as other people sent messages telling this or that application doesn't work... I can't even get an application to launch. I log in, get gnome-shell running, but: - no applet is shown in the bar. and they are there, i can press moue button on right menu, hover it over there and the volume bubble pops, but I see no icon on the bar. - if I select System settings o launch firefox, immediately I get a fullscreen error about something went wrong, plz logout and in again I suppose probably I miss some depdency not correctly handled, but I can not guess what. Any ideas ? TIA Well, after latest updates I can see things in gnome-shell, launch apps, see preferences, but suddenly I get kicked out, and I think this is the problem: gnome-settings-[2556]: segfault at 7fb8612fb1d0 ip 7fb8612fb1d0 sp 7fff830282d8 error 14 in libnsl-2.12.1.so[7fb8639dc000+15000] gnome-settings-[3257]: segfault at 7fae815011d0 ip 7fae815011d0 sp 7fff72cc8b58 error 14 in libnsl-2.12.1.so[7fae83be2000+15000] gnome-settings-[3723]: segfault at 7f42989871d0 ip 7f42989871d0 sp 7fffa8d55858 error 14 in libnsl-2.12.1.so[7f429b068000+15000] (from dmesg) Sometines it lasts longer, other less, but I get the error fullscreen message all the time. And perhaps it's because the session loses connection to gnome-settings-daemon. Any idea ? -- J.A. Magallon jamagallon()ono!com \ Winter is coming...
Re: [Mageia-dev] Problems with Gnome 3
2011/6/11 JA Magallón jamagal...@ono.com: On Thu, 9 Jun 2011 10:45:03 +0200, JA Magallón jamagal...@ono.com wrote: Hi all... I have a problem with this first big change in Cauldron... I have a couple test boxes in which I have updated everything, and I can't get Gnome 3 to work properly. I suppose it is still work in progress, but as other people sent messages telling this or that application doesn't work... I can't even get an application to launch. I log in, get gnome-shell running, but: - no applet is shown in the bar. and they are there, i can press moue button on right menu, hover it over there and the volume bubble pops, but I see no icon on the bar. - if I select System settings o launch firefox, immediately I get a fullscreen error about something went wrong, plz logout and in again I suppose probably I miss some depdency not correctly handled, but I can not guess what. Any ideas ? TIA Well, after latest updates I can see things in gnome-shell, launch apps, see preferences, but suddenly I get kicked out, and I think this is the problem: gnome-settings-[2556]: segfault at 7fb8612fb1d0 ip 7fb8612fb1d0 sp 7fff830282d8 error 14 in libnsl-2.12.1.so[7fb8639dc000+15000] gnome-settings-[3257]: segfault at 7fae815011d0 ip 7fae815011d0 sp 7fff72cc8b58 error 14 in libnsl-2.12.1.so[7fae83be2000+15000] gnome-settings-[3723]: segfault at 7f42989871d0 ip 7f42989871d0 sp 7fffa8d55858 error 14 in libnsl-2.12.1.so[7f429b068000+15000] (from dmesg) Sometines it lasts longer, other less, but I get the error fullscreen message all the time. And perhaps it's because the session loses connection to gnome-settings-daemon. Any idea ? -- J.A. Magallon jamagallon()ono!com \ Winter is coming... i think that it can be interesting to start gnome-settings inside gdb to have some infos about the crash
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
On 10/06/11 22:44, andre999 wrote: James Kerr a écrit : On 10/06/11 15:09, James Kerr wrote: On 10/06/11 13:54, Michael Scherer wrote: Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit : Thomas Backlundt...@mageia.org schrieb am 10.06.2011 So the path would then be */updates_testing - */updates _if_ we decide that's the way to go... As I see it, it's the only user friendly way. Using backports is fine for experienced users who do know what to install from backports or who are capable of facing the consequences. If a total newbie asks fort a package in the forums and is pointed to backports he is in great danger of wrecking his system by installing some new kernel, graphics driver, desktop or whatever, precisely because there is no real qa on backports. He can also wait for the release. Or he can enable backport just for the time needed to install and then disable it. I think rpmdrake have some stuff for that. Even though backports are disabled rpmdrake can display a list of available backports. (The sources are automatically updated by mgaonline.) A selected backport can then be installed, without enabling the backports source. (I've just tested this on mdv 2010.0, the only mdv system that I have available.) I've just realised there is a potential problem with this. Because Mageia has /backports_testing repo's (mdv does not) packages from /backports_testing may also be displayed. Mgaonline is updating those sources. Jim That was a bug in rpmdrake. If you had updated the repos with backports media enabled, when the backports media was subsequently disabled, the previously available backports packages remained displayed/installable. But new backports were not added if the repos were updated with backports disabled. There was the same problem for other media (like non-free). Otherwise enabling/disabling backports (or any other media) wouldn't make any sense. It is not a bug, but intended behaviour. When mdkonline/mgaonline is running it updates backports sources each time it checks for updates. As I indicated in an earlier email you can see that this is done if you check /var/log/auth.log. The system that I tested on, has never had backports sources enabled and I was able to install a recent package from a disabled backports source, by selecting it from Backports, displayed using the first filter in rpmdrake. This facility was set up to allow inexperienced users to selectively install backports, without enabling the backports sources. Jim
Re: [Mageia-dev] get-skype package for submission
On 10/06/11 18:06, Anssi Hannula wrote: I didn't test it, but the problems I see now: 1. The MD5SUM isn't checked, IMO it should be. I was just discussing that on IRC with Ahmad ;) I now have that working OK 2. On error you exit with || exit 1 but leave the files in /tmp, polluting it. OK - will fix 3. You cp files to %_datadir using a wildcard (*), but these files may not be removed on uninstallation as you only have filename lists for avatars/sounds/langs. While it may work now (I didn't test, I hope you did), this will cause unnoticed problems when the skype tarball contents change. The wildcard is used to move the remaining files which are all individually handled by touch and the dir is removed by a %ghost. I was just saving spec lines. Yes it does work fine and all files/dirs are removed on uninstall. The tarball contents can't change or the md5sum would fail :\ 4. Provide the script/commandline used to create the filelist files. Do you mean the avatars.txt etc. It was all done semi-manually, but I will write a script if necessary. It did cross my mind, but it was quicker to just copy/paste into txt files. I was assuming I could maintain it manually. 5. Versionize the filelist files to make sure they are renegerated when the package is updated to a new version (avatars-%version.txt) OK - again I was expecting to maintain it manually. 6. Your usage of /tmp seems unsafe security-wise. What if some user has created something under /tmp/skype-%version already? Hmm.. point taken Instead use mktemp to create a temporary directory. OK ... but: I can't figure out how to get a temp filename into a %define If I use %define mytmp $(mktemp -d -q) then every reference to the %define generates a new tmp file. How can I assign the output of a command expansion to a %define so it's evaluated only once on assignment? I can use a variable in %pre but that is invisible in %post as it's in another shell so I'm sorta stuck on that for now :( 7. You never remove the tarball, and the tarball is not %ghost. Will do - that was temporary for testing. Also BTW, here is a package of mine for gootleearth from 2006 that uses a similar system: http://www.zarb.org/cgi-bin/viewvc.cgi/plf/SPECS/non-free/googleearth/ No need to make it like that, just pointing it out in case there are some ideas you'd like to use. I'll take a look - thanks
Re: [Mageia-dev] get-skype package for submission
On 10/06/11 15:08, Marc Paré wrote: Hi Barry Thanks for doing this. I uncompressed the file. What is the difference between the 2 .rpms? You may want to include a readme in the package for people like me. Cheers Marc Marc, It is not really ready for general consumption yet (although it does work). If you want to test it the noarch.rpm is the one to install, not the src.rpm. Barry
Re: [Mageia-dev] get-skype package for submission
Le 2011-06-10 20:13, Barry Jackson a écrit : On 10/06/11 15:08, Marc Paré wrote: Hi Barry Thanks for doing this. I uncompressed the file. What is the difference between the 2 .rpms? You may want to include a readme in the package for people like me. Cheers Marc Marc, It is not really ready for general consumption yet (although it does work). If you want to test it the noarch.rpm is the one to install, not the src.rpm. Barry Thanks, I'll give it a try. Cheers Marc
Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?
James Kerr a écrit : On 10/06/11 22:44, andre999 wrote: James Kerr a écrit : On 10/06/11 15:09, James Kerr wrote: On 10/06/11 13:54, Michael Scherer wrote: Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit : Thomas Backlundt...@mageia.org schrieb am 10.06.2011 So the path would then be */updates_testing - */updates _if_ we decide that's the way to go... As I see it, it's the only user friendly way. Using backports is fine for experienced users who do know what to install from backports or who are capable of facing the consequences. If a total newbie asks fort a package in the forums and is pointed to backports he is in great danger of wrecking his system by installing some new kernel, graphics driver, desktop or whatever, precisely because there is no real qa on backports. He can also wait for the release. Or he can enable backport just for the time needed to install and then disable it. I think rpmdrake have some stuff for that. Even though backports are disabled rpmdrake can display a list of available backports. (The sources are automatically updated by mgaonline.) A selected backport can then be installed, without enabling the backports source. (I've just tested this on mdv 2010.0, the only mdv system that I have available.) I've just realised there is a potential problem with this. Because Mageia has /backports_testing repo's (mdv does not) packages from /backports_testing may also be displayed. Mgaonline is updating those sources. Jim That was a bug in rpmdrake. If you had updated the repos with backports media enabled, when the backports media was subsequently disabled, the previously available backports packages remained displayed/installable. But new backports were not added if the repos were updated with backports disabled. There was the same problem for other media (like non-free). Otherwise enabling/disabling backports (or any other media) wouldn't make any sense. It is not a bug, but intended behaviour. When mdkonline/mgaonline is running it updates backports sources each time it checks for updates. As I indicated in an earlier email you can see that this is done if you check /var/log/auth.log. The system that I tested on, has never had backports sources enabled and I was able to install a recent package from a disabled backports source, by selecting it from Backports, displayed using the first filter in rpmdrake. This facility was set up to allow inexperienced users to selectively install backports, without enabling the backports sources. Jim OK, I just verified. As you say, backports are visible if viewing backports alone, even if the backports medias are not selected. (This is the first time I have selected viewing backports alone.) I have, however, temporarily enabled at least one backports media on occasion, which were then viewable under all (packages). The backports packages in question remained viewable under all, after all the backports media were disabled. Note that if backports media are not enabled, backports are normally not visible under all (packages) or all updates. The same thing has happened with non-free medias, which I normally leave disabled. -- André
