Re: [Mageia-dev] Release cycles proposals, and discussion

[Oliver Burger]

Thorsten van Lil  schrieb am 14.06.2011
> Am Montag, 13. Juni 2011, 23:28:04 schrieb Renaud MICHEL:
> > I don't get it why people think a re-install is necessary.
> > My current computer was installed with mandriva 2007 (don't
> > remember if it was .0 or .1), it is now mageia 1 and has been
> > updated to all intermediary mdv releases.
> 
> An Upgrade is nearly the same, than reinstalling. The difference is
> only, that you can use your system in the mean time and you are
> not forced to install the missing packages.
And you keep all your precious settings and databases and webroots 
and...
And of couse the software you did unstall outside of the package 
management (proprietary stuff,...).

And a bit to the argument of having to install loads of software at 
the same time: When some basic libraries are upgraded, loads of 
software have to be rebuilt against them, so with the rolling aproach 
you will just get that massive upgrades more often, so where is the 
bonus in it?
If people want to have their software more up to date, use backports, 
if they want to have it even more up to date, use cauldron, but don't 
cry if anything breaks.

Oliver

Re: [Mageia-dev] Release cycles proposals, and discussion

[Thorsten van Lil]

Am Montag, 13. Juni 2011, 23:28:04 schrieb Renaud MICHEL:
> On lundi 13 juin 2011 at 23:06, Thorsten van Lil wrote :
> > A rolling release has following advantages:
> > 1. the distribution is always up to date (also hardware support)
> > 2. no re-install over and over again
> 
> I don't get it why people think a re-install is necessary.
> My current computer was installed with mandriva 2007 (don't remember if it
> was .0 or .1), it is now mageia 1 and has been updated to all intermediary
> mdv releases.

An Upgrade is nearly the same, than reinstalling. The difference is only, that 
you can use your system in the mean time and you are not forced to install the 
missing packages. 

> > This could look like this:
> > Bring up a release once a year. The core (kernel, glib, ...) will only
> > get  minor updates. Apllications like firefox, libreoffice, ... will
> > always be up to date (rolling). Maybe also the desktop envirenments
> > could be rolling but this is very heavy.
> 
> If I understood correctly, that is exactly what the backports should
> provide, new versions of programs when possible (no update of half of the
> core system libraries).
> 

Yes, but Backports are not officially supported and we wouldn't advice new 
users 
to backports normally. It's not what is possible with current repos but what 
we offer for the "normal" user. Because this also influence what release cycle 
we use. If we use such a light rolling release, it's enough to offer one 
release per year or maybe one in 18 month. If we stay with the static release 
model, we are almost "forced" to release every 9 months or earlier.

Greetings,
Thorsten

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le mardi 14 juin 2011 à 03:30 +0200, Maarten Vanraes a écrit :
> Op dinsdag 14 juni 2011 01:02:51 schreef Michael Scherer:
> > Le lundi 13 juin 2011 à 15:51 +0300, Thomas Backlund a écrit :
> > > Wolfgang Bornath skrev 13.6.2011 15:20:
> > > Obviously there will still be people complaining that "you waited 10
> > > months... if you had extended with ~2 more weeks... "this" or "that"
> > > package would have been available too... and so on
> > 
> > Yes, there will be.
> > So let's be realist, 9 months with +/- 1 month is just 10 months +
> > people complaining to have 10,5 months.
> > 
> > We will never use the -1 month, because there will always be something
> > worth waiting.
> 
> actually, the real reason would be more to plan for whatever features you're 
> going to implement and the time it takes to do them. if that's 8 months, it's 
> 8 months, if that's 9 or 10months, that's what it is.

See my answer to wobo.

> We proved that we can take a planning and follow it through, even the last 
> release_critical one was solved _just_in_time_...

I still think the codecs stuff should not have been release_critical, as
we could do the update later.

> imho, we need to decide now on a sort of 9month period, look at what we're 
> going to do, then estimating how long it takes (with enough lenience), then 
> make a real planning for that, and stick to it, if features are not ready, 
> drop those features for next release, and make sure to fix all the 
> release_criticals.

Great, so can you start by telling how long it will take for the feature
you plan to work on ?
-- 
Michael Scherer

Re: [Mageia-dev] Release cycles proposals, and discussion

[Maarten Vanraes]

Op dinsdag 14 juni 2011 01:02:51 schreef Michael Scherer:
> Le lundi 13 juin 2011 à 15:51 +0300, Thomas Backlund a écrit :
> > Wolfgang Bornath skrev 13.6.2011 15:20:
> > > About the cycles:
> > > 
> > > The 9-months seem to be a compromise - but I start to ask why we need
> > > such a fixed statement (which it would be, once published). We need a
> > > schedule for each cycle, that's true. Without a schedule we would
> > > never finish anything. But how about taking 9 months only as a "nice
> > > to meet" target, leaving us the option to set a roadmap after setting
> > > the specs of the next release - we could then go for a 8 or 10 months
> > > roadmap, depending on the specs.
> > 
> > This is somewhat like what I had in my mind to write too, but you beat
> > me to it :)
> > 
> > It could allow us to adapt a little for upstream releases.
> > But should we then decide that the limit is +/- 1 month ?
> 
> There is 2 problem :
> - for release of what software ?
> - what if the upstream planning is wrong, and their releases is late
> ( as it happened when I was a trainee in Mandrakesoft, with xfree being
> 3 months late and the distribution still shipping a broken pre release )
> 
> > Obviously there will still be people complaining that "you waited 10
> > months... if you had extended with ~2 more weeks... "this" or "that"
> > package would have been available too... and so on
> 
> Yes, there will be.
> So let's be realist, 9 months with +/- 1 month is just 10 months +
> people complaining to have 10,5 months.
> 
> We will never use the -1 month, because there will always be something
> worth waiting.

actually, the real reason would be more to plan for whatever features you're 
going to implement and the time it takes to do them. if that's 8 months, it's 
8 months, if that's 9 or 10months, that's what it is.

We proved that we can take a planning and follow it through, even the last 
release_critical one was solved _just_in_time_...

imho, we need to decide now on a sort of 9month period, look at what we're 
going to do, then estimating how long it takes (with enough lenience), then 
make a real planning for that, and stick to it, if features are not ready, 
drop those features for next release, and make sure to fix all the 
release_criticals.

Re: [Mageia-dev] Question about backports: calibre (bug 1659)

[Michael Scherer]

Le lundi 13 juin 2011 à 02:51 -0700, Radu-Cristian FOTESCU a écrit :
> Folks, 
> 
> WRT https://bugs.mageia.org/show_bug.cgi?id=1659
> [Bug 1659] Calibre is too old (0.7.32 vs. 0.8.4, i.e. 31 versions behind!)
> 
> 
> Two people asserted that a newer calibre package should go into backports, 
> not updates.

And so would I. That's 3.

> I strongly believe quite the contrary.
> 
> 
> I'd like to bring to your attention that calibre, the e-book reader and 
> converter, 
> has an extremely dynamic lifecycle: it released 32 versions in 6 months! 
> Thirty-two 
> versions! (I don't know of any other software that does that, virus 
> signatures not counted.)
> 
> 
> Sure thing, some releases might bring some regressions, but each and every 
> version fixes bugs, 
> adds new features, adds support for newer e-reader models, etc. etc. Also, 
> the developer of 
> calibre quickly releases a newer build in the case of serious regressions -- 
> most of the 
> times within 0 to a few days.

So that's like most softwares :
- there is lots of release, 
- there is a mix of features, bugfixes and regression.

So why does it have to be treated differently than the others since
there is nothing special about this release cycle  ?



-- 
Michael Scherer

Re: [Mageia-dev] get-skype package for submission

[Michael Scherer]

Le lundi 13 juin 2011 à 14:20 +0200, Angelo Naselli a écrit :
> lunedì 13 giugno 2011 alle 13:13, Oliver Burger ha scritto:
> > Have you also installed rpmlint-mageia-policy?
> Shouldn't it be at least suggested?

I would prefer to find a better way than suggest :/
( like a meta rpm pulling mgarepo, bm, the policy and rpmlint ).

-- 
Michael Scherer

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le mardi 14 juin 2011 à 02:36 +0200, Bruno Cornec a écrit :
> Michael Scherer said on Tue, Jun 14, 2011 at 01:31:46AM +0200:
> 
> > And I think we can already decide to release 1 week later if a
> > release_critical bug appears. Fedora 15 for example was 2 weeks late,
> > because they changed the release date twice after having seen some
> > problem (http://fedoraproject.org/wiki/Releases/15/Schedule ).
> 
> I think that the level of flexibility that is really useful. Fixing a
> target is nice for all projects. Now, if a blocking point happens, it's
> wise to delay a bit.
> 
> I personaly find ridiculous the Ubuntu approach to release at fixed
> dates, whatever happens, becasue it's 11.04, it should be in April 2011
> !! But then their community is just angry because of the lack of
> quality due to that.

They did a push of 2 months in 2006 ( 6.06 instead of 6.04 for Dapper
Drake ). But I think that was a isolated change, and Mark Shuttleworth
is pushing for keeping schedule. We were praised because we were not
late too :)

> So maybe what would be interesting is to have something like:
> M1-M8: break and fix cauldron with lots of new stuff.
> M8-M8.5: freeze period. Only bug fixes or HW support improvements goes 
> through or mageia tools. In particular, no new KDE, Gnome, LibreO, FF, 
> ...
> M8.5-M9: test period. Only bugs found there are fixed. As the cauldron
> is closed, people have more time to upgrage with an already stabilized
> distro, to make it really stable at the 9 months date.

Well, that's the plan, with the release date come then the decision
about the freeze period, even if we got mixed signals here :
- we want longer freeze because that mean less bugs
- we also see that people always want to have freeze exception because
bugfixing is less fun that adding feature :)

So that warrant also another discussion ( even if I think the current
division is fine, but it could be adapted if the release model is
different ).
-- 
Michael Scherer

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le lundi 13 juin 2011 à 05:04 -0700, Ron a écrit :
> > There is a limited set of options, and as you can see, none of your 
> > idea was not already explored by someone else.
> It has all been done before, in that sense let's just close up shop and call 
> it a day???

Your first argument was "we should not do release, that's what all
others do". I just explained that not doing release is not a new idea.

And maybe I misunderstood your ideas, but if the mere fact that we are
not alone on a segment is a reason to leave it because we cannot
compete, then since by your own word, Arch is doing well, why should we
try to compete too ?
 
In fact, instead of telling what Arch does well, maybe you could start
to say where Arch is not doing well, and how you propose to do things to
do better if you want to convince there is room for another distribution
and room for improvement.

Because if Arch is already fulfilling all your needs, I fail to see what
to do. So the first step would be to explain what Arch is not doing
right if you hope to convince us we can do better.


> > If everything move all days, you cannot :
> > - translate software ( as the string will change every day )
> > - create documentation ( for the same reason )
> > - communicate ( as everything ca be broken at any time )
> > - ensure stability ( as each change can bring unstability )
> 
> > And for user, some do not want to redo training every week for 
> > their users, because libreoffice got updated, because ff 4 just arrived 
> > and 75% of extensions do not work, etc. 
> >
> > In fact, the whole release model is basically what is used all >over the
> > place, from lower level like kernel to higher level like kde. So >you can
> > get lots of feedback on it.
> You are correct on the release model being used everywhere, that fit's 
> development 
> and really there is no other way to do it as it takes time. 
> But really, up stream does have to take time but package maintainers can pull 
> things in pretty fast 
> and make things work.

Being myself a packager, and being a packager since a long time ( like 7
years ), I feel that I have to disagree. While there isn't much breakage
on packaging side, we also suffer from bugs like upstream developers
does, mainly because we use the same software as them. We also develop
our own software ( like the installer, drakxtools, etc ). We also do
work on integration, etc.

And I am a little bit disappointed to learn that my work as a packager
do not take time. I must maybe do it wrong, as it seems to be a real
work.

> I don't understand what's being said here? Are we a community of users 
> or are we just teachers teaching a class? Help with changes is what 
> forums and people are for. 

If people want changes, they either do it themselves, or they wait on
someone else to do. And waiting for someone else to do mean to convince
that someone. And that someone is everybody reading you on the list,
which also mean me.  

Wanting changes has never been sufficient for making them appear. We
wanted to have a change regarding Mandriva, we made it.

> You worried about not being able to keep up with documentation? 
> I suggest you take a look at the Arch wiki, best Linux wiki 
> there is and things change fast... Again, community...

Then I would answer "just look at the ubuntu wiki" to see that the
quality of a wiki is not related to the release model of a
distribution. 

And when I say documentation, I was speaking of something like :
http://doc.mandriva.com/index.php 
or like this :
http://docs.fedoraproject.org/en-US/Fedora/15/html/Installation_Guide/index.html

And so, since you didn't answer to the others points I made, shall I
assume they are valid concerns ? 

> > So basically, you suggest that since everybody is already doing 
> > it, this is useless. So the logical conclusion is we should drop 
> > the distribution ?
> No that is not what I'm saying!
>
> What I am saying is that you have 100+/- distributions all going by a 
> release model and only a handful making rolling releases. 

A majority of distributions developers have independently decided to use
a release model, so it is obviously something that is fulfilling their
needs as well as the need of a majority of users, no ?


> There is only one defacto maker of a rolling release and that is Arch, 
> why does this have to be? (Yes I know there are others but Arch is the 
> leader of the pack)

Technically, there is Gentoo, and derived distribution  or Debian
Testing, and I know more people running Gentoo and Debian than Arch
users. I would even say that the *BSD and Slackware are a form of
rolling release, since they have a fixed small base system updated from
time to time, and a evolving upper level with updated software and
others stuff. 

In fact, if we look at the market share, the dominant unix system with a
rolling release model would be mac os X. 

( but I guess that you disagree with the fact that *BSD are a rolling
release, which is yet ano

Re: [Mageia-dev] Release cycles proposals, and discussion

[Bruno Cornec]

Michael Scherer said on Tue, Jun 14, 2011 at 01:31:46AM +0200:

> And I think we can already decide to release 1 week later if a
> release_critical bug appears. Fedora 15 for example was 2 weeks late,
> because they changed the release date twice after having seen some
> problem (http://fedoraproject.org/wiki/Releases/15/Schedule ).

I think that the level of flexibility that is really useful. Fixing a
target is nice for all projects. Now, if a blocking point happens, it's
wise to delay a bit.

I personaly find ridiculous the Ubuntu approach to release at fixed
dates, whatever happens, becasue it's 11.04, it should be in April 2011
!! But then their community is just angry because of the lack of
quality due to that.

So maybe what would be interesting is to have something like:
M1-M8: break and fix cauldron with lots of new stuff.
M8-M8.5: freeze period. Only bug fixes or HW support improvements goes 
through or mageia tools. In particular, no new KDE, Gnome, LibreO, FF, 
...
M8.5-M9: test period. Only bugs found there are fixed. As the cauldron
is closed, people have more time to upgrage with an already stabilized
distro, to make it really stable at the 9 months date.

Bruno.
-- 
Open Source & Linux Profession Lead EMEA   / http://opensource.hp.com
HP/Intel/Red Hat Open Source Solutions Initiative  / http://www.hpintelco.net
http://www.HyPer-Linux.org  http://mondorescue.org http://project-builder.org
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org

Re: [Mageia-dev] Release cycles proposals, and discussion

[Sam Bailey]

On Mon, 13 Jun 2011 10:37:25 -0500 (CDT), Dale Huckeby wrote:


+1

The consensus so far seems to be:

6 months is too short
12 months is too long
9 months is just about right

and that applies not only to developers having a chance to catch 
their

breath between versions, but
users too. A 6-month turnaround feels like I'm constantly updating, 
but a

12-month wait between
versions is like forever. And as wobo suggests, 9 months need be only 
an

average, with a target date
for the next release, taking into account upstream developments, 
decided

on after each one. Also,
the target date should be approximate at first and firmed up only as 
we

get closer to release.

spock


+1

9 months seems to create a nice stable base - with enough time to add 
new
developments and breathe between releases (along with kernel updates 
for

new kit).

My suggestion is that for those who want faster access to new versions 
of

apps will be able to create a larger focus on backports for large and
common apps (from cauldron) without taking the focus away from the 9mth
release cycle.

This slightly extra use of backports may also help with the LTS 
proposals.


--
Sam Bailey
(cyprix)

Re: [Mageia-dev] [RPM] cauldron core/release iceape-2.1-1.mga2

[Dick Gevers]

On Mon, 13 Jun 2011 23:51:34 +0200 (CEST), Christiaan Welvaart wrote about
Re: [Mageia-dev] [RPM] cauldron core/release iceape-2.1-1.mga2:

>> The personal toolbar contains five Mandriva links.
>
>Not here, can you check
>  /usr/lib*/iceape-2.1/defaults/profile/bookmarks.html
>? But that can't really be it so this should be in your personal profile.
>
>
> Christiaan

Yes now it is okay, but there was also /usr/lib64/iceape-2.0.14/ 
leftover which I just removed. 

I'm sure it must have been stg local then: so sorry for the noise.

m.v.g.
=Dick Gevers=

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le lundi 13 juin 2011 à 14:20 +0200, Wolfgang Bornath a écrit :

> The 9-months seem to be a compromise - but I start to ask why we need
> such a fixed statement (which it would be, once published). We need a
> schedule for each cycle, that's true. Without a schedule we would
> never finish anything. But how about taking 9 months only as a "nice
> to meet" target, leaving us the option to set a roadmap after setting
> the specs of the next release - we could then go for a 8 or 10 months
> roadmap, depending on the specs.

As I said to Thomas, we will never use the 8 months option. If we say
"we have selected less features to finish sooner", people will just ask
for more features, and will say "why do you want to finish sooner, I
prefer to have feature and wait 1 month more". 

In fact, the same would go for 9 to 10 if we start to propose the
possibility. 

And deciding that we will decide later is not really deciding. We should
select features based on time needed to implement them and how much time
we can devote, not the contrary especially since no one will ever be
able to give precise timing for anything, so one month of difference
would be difficult to justify.  

And I think we can already decide to release 1 week later if a
release_critical bug appears. Fedora 15 for example was 2 weeks late,
because they changed the release date twice after having seen some
problem (http://fedoraproject.org/wiki/Releases/15/Schedule ).

And we did it more than once at Mandriva.

> This being said, I am a friend of a rolling release like ArchLinux,
> but I fear that our main target group is not up to this. Despite of
> having to "burn yet another DVD" as somebody pointed out, the majority
> seems to see this as normal and a good way. Of course I may be totally
> wrong with this assessment!

Maybe people should maybe start to trust more mgaonline to do upgrade,
there is nothing that pacman does that urpmi don't regarding upgrade,
there is no magic involved : 
- people should test before the release and fill bug reports.

That's the secret behind debian upgrade, people just do lots of tests
for that either automated ( using something like piupart
( http://wiki.debian.org/piuparts ) ), or manual and lots of people do
full system upgrade long before the release ( and not only after ).

-- 
Michael Scherer

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le lundi 13 juin 2011 à 15:51 +0300, Thomas Backlund a écrit :
> Wolfgang Bornath skrev 13.6.2011 15:20:
> > About the cycles:
> >
> > The 9-months seem to be a compromise - but I start to ask why we need
> > such a fixed statement (which it would be, once published). We need a
> > schedule for each cycle, that's true. Without a schedule we would
> > never finish anything. But how about taking 9 months only as a "nice
> > to meet" target, leaving us the option to set a roadmap after setting
> > the specs of the next release - we could then go for a 8 or 10 months
> > roadmap, depending on the specs.
> >
> 
> This is somewhat like what I had in my mind to write too, but you beat 
> me to it :)
> 
> It could allow us to adapt a little for upstream releases.
> But should we then decide that the limit is +/- 1 month ?

There is 2 problem :
- for release of what software ?
- what if the upstream planning is wrong, and their releases is late
( as it happened when I was a trainee in Mandrakesoft, with xfree being
3 months late and the distribution still shipping a broken pre release )


> Obviously there will still be people complaining that "you waited 10 
> months... if you had extended with ~2 more weeks... "this" or "that"
> package would have been available too... and so on

Yes, there will be. 
So let's be realist, 9 months with +/- 1 month is just 10 months +
people complaining to have 10,5 months.

We will never use the -1 month, because there will always be something
worth waiting.

-- 
Michael Scherer

Re: [Mageia-dev] Release cycles proposals, and discussion

[Maarten Vanraes]

Op dinsdag 14 juni 2011 00:08:56 schreef David W. Hodgins:
> On Mon, 13 Jun 2011 17:28:04 -0400, Renaud MICHEL 
 wrote:
> > On lundi 13 juin 2011 at 23:06, Thorsten van Lil wrote :
> >> A rolling release has following advantages:
> >> 1. the distribution is always up to date (also hardware support)
> >> 2. no re-install over and over again
> > 
> > I don't get it why people think a re-install is necessary.
> > My current computer was installed with mandriva 2007 (don't remember if
> > it was .0 or .1), it is now mageia 1 and has been updated to all
> > intermediary mdv releases.
> 
> My currently running install started as Mdv 2009.1, updated via urpmi to
> 2010.2, then converted to Mageia cauldron during beta 1.
> 
> With a little over 4400 packages, the upgrade from one release to the next
> takes over 8 hours, on this single core Celeron processor, so even though
> it's not an actual re-install, it still feels like one. /usr alone is 13GB.

I have a similar machine, but updated through the applet, which means it only 
takes about 1hour and you can work in the main time and reboot when you want. 
i don't understand why users would be expressly wanting rolling release when 
you don't need to reinstall, or "upgrade" in a traditional sense at all...

> One possibly annoying part about that, is that there are many rpm packages
> where the only obvious change is the version.  I understand that for many
> of the packages, they have to be rebuilt due to perl/python/glib version
> changes, but anyone who doesn't know that will see what seems like a lot
> of unneeded updates.
> 
> One con of a rolling release has been demonstrated by Cauldron over the
> last few days.  With the perl/gnome updates, it takes a few days for all
> of the needed packages to get built.  For a couple of days, running urpmi
> with --auto-select wanted to remove most of gnome.  I waited till the
> needed packages were available, whereas a less technical user may have
> ended up removing key parts of their desktop manager.
> 
> Regards, Dave Hodgins

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le lundi 13 juin 2011 à 14:58 +0200, Samuel Verschelde a écrit :
> Le dimanche 12 juin 2011 22:46:33, Michael Scherer a écrit :
> > Hi,
> > 
> > so , with a little bit delay due to various things ( like everybody
> > asking stuff to us on irc on a hourly fashion ( people will I hope
> > recognize themselves )), Anne and I have reviewed the various proposals
> > made through years during the early period of the distribution, and
> > before at Mandriva. We took in account the feedback of people on forum,
> > on ml, nd those we have seen during events. We also discussed with
> > others distributions developers we know from Opensuse, Fedora, Debian,
> > Ubuntu about their release cycle, the choices they made and their
> > reasons.
> 
> A restitution to us of this overview of the other distros release cycles and 
> their choices, reasons, pros and cons would have been great, but I guess it 
> would have required much more time to write it.

Given that time is already lacking, yes.

But basically, Fedora use 6 months because they want to release often
( Features, First ), according to Mathieu Bridon. That's also why they
have a very agressive update policy ( which caused some issues like
xorg/nvidia breakage, firefox breakage, thunderbird problem ). They do
also have lots of upstream developers paid by RH, who prefer to have
this model to be able to have fast feedback on their software
( especially since almost no one run Rawhide, the equivalent of Cauldron
)

Discussing with Didier Roche, Ubuntu does this because they wanted to
release with gnome, every 6 months. There was discussion 1 year ago
about keeping a minimal distribution ( plateform model ) but it seems it
didn't happened yet. He also confirmed that the pace was quite intense,
letting them push lots of features they develop ( unity, etc ).

According to Vincent Untz, Opensuse moved from 6 months to 8 months
because they feel that 6 months was too much, too frequent. The only
problem is that 1 cycle about 3, they run older software ( like Gnome ),
but that's not a big problem. 

I forgot the Debian stuff, but basically, their release model is a 3
tiered one ( testing, unstable, experimental ), with experimental is
were stuff that can break are uploaded, uploading almost everything,
unstable unstable

For obvious reason, everybody is happy of their choices :)

>  It would have helped 
> understand why the final decision

If this as a final decision, I would not explain and ask to people their
opinion. 

>  you took was to keep the current model (not 
> counting the discussion about cycle duration and LTS). I'm not saying that I 
> want "rolling release", but beginning the discussion without saying much 
> concerning what has been a big discussion some months ago (and still is in 
> the 
> forum) feels a bit weird to me. Especially when we kept telling people "wait, 
> we will have time to discuss it after Release 1".

Well, as I said, we didn't consider the "no release" option. After
looking the document you wrote
( http://mageiacauldron.tuxfamily.org/MageiaReleaseCycle ), the option
"no release" ( I ) was deemed as not realistic, and so was also our
opinion. 

Now, we also took in account the summary and all others were a
combination of release policy, backports policy, and update policy.
Basically, on the release side, it was 1y or 6m, and we have seen that
everybody was only considering theses 2 propositions, hence the proposal
for 9 months ( partially inspired by the suse one ). 

Something that was also apparent in your summary was the need to
backports lots of things on all proposals, the only difference being if
kernel/xorg would be backported or not depending on the release
frequency. 

So after reading this, my conclusion on that was that the release model
would not change much on that part, since basically, either there is a
release often, or your proposal would be to backports lots of things. So
discussing release frequency only would be enough, since the other half
of the discussion is dependent on this one.

Or, as a mathematician would say : 
backport_level(R) = stormi_constant / release_frequency(R) 

( please not that you are now half as famous as Planck, Faraday and
Boltzmann since there is a constant named after you, the other half is
having a institute named after you )

> > To simplify the discussion, the proposals are all based on the fact that
> > 2 or 3 releases could be supported at a time. We could have different
> > schemes for that ( LTS every X release ( ubuntu ), different level of
> > support ( mandriva )), but as this is a slightly different discussion,
> > let's assume 2 supported releases for now, and let's discuss later for
> > that ( ie next week, once this one is finished )
> 
> I can understand the reason for separating the discussions (simplification), 
> but it's hard to give a final opinion concerning the release cycle without 
> knowing whether there will be a LTS or not, when you care about the life 
> cycle 
> 

Re: [Mageia-dev] GNOME3 ?

[JA Magallón]

On Mon, 13 Jun 2011 17:33:20 -0400, Frank Griffin  wrote:

> On 06/13/2011 04:12 PM, Frank Griffin wrote:
> > On 06/13/2011 04:05 PM, Dexter Morgan wrote:
> >> nice i fix this one
> >
> >
> > The reason I ask is that on an ID previously using GNOME 2.32, the 
> > desktop comes up, but launching any application drives the video 
> > crazy.  You can see the app window some of the time, but after a 
> > second or two of video flashing you get a fullscreen  "Oops" panel and 
> > are told to log out.  On a fresh ID, you can't even get the desktop to 
> > come up - you get the blue background, the mouse pointer circles for a 
> > bit and then stops, with no error and no recourse but CTRL-ALT-BKSP.
> >
> 
> Ahh.  Correction with the latest updates: now the ID previously using 
> GNOME 2.32 doesn't get past the blue background either.

Two kind of problems:
- dependecies: make sure you have 'gtk+3.0' and 'gnome-themes-standard'
  (latest will pick some themes and fonts...) You should see a striped
  blue bg after login.
- in my case I get kicked off because gnome-settings-daemon hangs on
  libnsl (from glibc). I am thinkin on how to debug it (how to launch
  g-s-d on a gdb shell and dump the output somewhere...)

Check if you have something like this in your dmesg:

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]

If yes, at least I'm not the only one :).

-- 
J.A. Magallon  \ Winter is coming...

Re: [Mageia-dev] get-skype package for submission

[Barry Jackson]

On 13/06/11 15:46, Anssi Hannula wrote:


It could do both :)
Doesn't really matter, this is all extra anyway.

Note that if you make it download it, you could also implement:
a) make it print md5sum automatically


Done that in the attached. It writes it to skype-.md5 in /SOURCES


b) make it print the dependencies automatically
(see e.g. the earlier google earth script which does those IIRC)



Not yet implemented this.


But as said, all of this is extra. Maybe the priority should be getting
you a mentor.



Yes that would be really good.


A first draft of this is attached.
I assume this would ultimately be added as a SOURCE file with notes in
the package.


Yep.



Done. It's all included in the src package.

So, anyone willing to mentor me and get this package on the road ?  ;)

Barry


get-skype.tar.gz
Description: application/gzip

Re: [Mageia-dev] Release cycles proposals, and discussion

[David W. Hodgins]

On Mon, 13 Jun 2011 17:28:04 -0400, Renaud MICHEL  
wrote:


On lundi 13 juin 2011 at 23:06, Thorsten van Lil wrote :

A rolling release has following advantages:
1. the distribution is always up to date (also hardware support)
2. no re-install over and over again


I don't get it why people think a re-install is necessary.
My current computer was installed with mandriva 2007 (don't remember if it
was .0 or .1), it is now mageia 1 and has been updated to all intermediary
mdv releases.


My currently running install started as Mdv 2009.1, updated via urpmi to
2010.2, then converted to Mageia cauldron during beta 1.

With a little over 4400 packages, the upgrade from one release to the next
takes over 8 hours, on this single core Celeron processor, so even though
it's not an actual re-install, it still feels like one. /usr alone is 13GB.

One possibly annoying part about that, is that there are many rpm packages
where the only obvious change is the version.  I understand that for many
of the packages, they have to be rebuilt due to perl/python/glib version
changes, but anyone who doesn't know that will see what seems like a lot
of unneeded updates.

One con of a rolling release has been demonstrated by Cauldron over the last
few days.  With the perl/gnome updates, it takes a few days for all of the
needed packages to get built.  For a couple of days, running urpmi with
--auto-select wanted to remove most of gnome.  I waited till the needed
packages were available, whereas a less technical user may have ended up
removing key parts of their desktop manager.

Regards, Dave Hodgins

Re: [Mageia-dev] [RPM] cauldron core/release iceape-2.1-1.mga2

[Christiaan Welvaart]

On Mon, 13 Jun 2011, Dick Gevers wrote:


On Mon, 13 Jun 2011 15:10:47 +0200 (CEST), Mageia Team wrote about [RPM]
cauldron core/release iceape-2.1-1.mga2:



The personal toolbar contains five Mandriva links.


Not here, can you check
 /usr/lib*/iceape-2.1/defaults/profile/bookmarks.html
? But that can't really be it so this should be in your personal profile.


Christiaan

Re: [Mageia-dev] Release cycles proposals, and discussion

[Colin Guthrie]

'Twas brillig, and lebarhon at 13/06/11 20:18 did gyre and gimble:
> BTW : I think mailing list are totally outdated and that mageia should
> have a special section in this forum for these discussion, or maybe
> another forum.
> It's totally impossible for people who want to participate sometimes to
> follow you emails everydays. It's much faster to read some topic on a
> forum than dozens emails. And your final user should be able to know
> what happen easily. It would be a big + in front of others distributions.

This is offtopic here. I completely disagree, incidentally. I need to
read about 30 or 40 different community lists. It's *much* quicker for
me to have a standard UI and a standard way of operating and a standard
look and feel.

Each project having a separate forum, with separate logins, with
separate style and separate features etc. makes for a very hard and time
consuming reading experience. There is a similar argument for why HTML
messages are bad too (consistent style makes everyone's life easier). So
forums are only really good if you only follow a couple of projects or
only follow projects fairly superficially. Mailing lists are better for
the rest of us who are have to follow more projects.

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] GNOME3 ?

[Frank Griffin]

On 06/13/2011 04:12 PM, Frank Griffin wrote:

On 06/13/2011 04:05 PM, Dexter Morgan wrote:

nice i fix this one



The reason I ask is that on an ID previously using GNOME 2.32, the 
desktop comes up, but launching any application drives the video 
crazy.  You can see the app window some of the time, but after a 
second or two of video flashing you get a fullscreen  "Oops" panel and 
are told to log out.  On a fresh ID, you can't even get the desktop to 
come up - you get the blue background, the mouse pointer circles for a 
bit and then stops, with no error and no recourse but CTRL-ALT-BKSP.




Ahh.  Correction with the latest updates: now the ID previously using 
GNOME 2.32 doesn't get past the blue background either.

Re: [Mageia-dev] [105941] imported package rake

[Cazzaniga Sandro]

Le 13/06/2011 23:26, Dexter Morgan a écrit :
> On Mon, Jun 13, 2011 at 11:21 PM, Cazzaniga Sandro
>  wrote:
>> Le 13/06/2011 23:20, Dexter Morgan a écrit :
>>> already exist in mageia in ruby-rake
>> oops, why name it ruby-rake?
> 
> for policy reason, like python and perl packages
thanks for your help.

-- 
Sandro Cazzaniga - https://lederniercoupdarchet.wordpress.com
IRC: Kharec (irc.freenode.net)
Software/Hardware geek
Conceptor
Magnum's Coordinator/editor (http://wiki.mandriva.com/fr/Magnum)
Mageia and Mandriva contributor

Re: [Mageia-dev] Release cycles proposals, and discussion

[Renaud MICHEL]

On lundi 13 juin 2011 at 23:06, Thorsten van Lil wrote :
> A rolling release has following advantages:
> 1. the distribution is always up to date (also hardware support) 
> 2. no re-install over and over again

I don't get it why people think a re-install is necessary.
My current computer was installed with mandriva 2007 (don't remember if it 
was .0 or .1), it is now mageia 1 and has been updated to all intermediary 
mdv releases.
Another was not actually installed, an older was installed with mandrake 8.2 
(yes, that is as old as 2002), was updated to each subsequent release, was 
copied on a new computer (create partitions, copy, reinstall grub in MBR, 
check graphic driver, and it worked), it is now running mandriva 2010.2 
(mageia to come) without being reinstalled since.

> Some users also wants the a mix of both (also called a light rolling
> release)  and combine the advantages as far as possible.
> This could look like this:
> Bring up a release once a year. The core (kernel, glib, ...) will only
> get  minor updates. Apllications like firefox, libreoffice, ... will
> always be up to date (rolling). Maybe also the desktop envirenments
> could be rolling but this is very heavy.

If I understood correctly, that is exactly what the backports should 
provide, new versions of programs when possible (no update of half of the 
core system libraries).

cheers
-- 
Renaud Michel

Re: [Mageia-dev] [105941] imported package rake

[Dexter Morgan]

On Mon, Jun 13, 2011 at 11:21 PM, Cazzaniga Sandro
 wrote:
> Le 13/06/2011 23:20, Dexter Morgan a écrit :
>> already exist in mageia in ruby-rake
> oops, why name it ruby-rake?

for policy reason, like python and perl packages

Re: [Mageia-dev] [105941] imported package rake

[Cazzaniga Sandro]

Le 13/06/2011 23:20, Dexter Morgan a écrit :
> already exist in mageia in ruby-rake
oops, why name it ruby-rake?

-- 
Sandro Cazzaniga - https://lederniercoupdarchet.wordpress.com
IRC: Kharec (irc.freenode.net)
Software/Hardware geek
Conceptor
Magnum's Coordinator/editor (http://wiki.mandriva.com/fr/Magnum)
Mageia and Mandriva contributor

Re: [Mageia-dev] [105941] imported package rake

[Dexter Morgan]

On Mon, Jun 13, 2011 at 11:14 PM,   wrote:
> Revision 105941 Author kharec Date 2011-06-13 23:14:01 +0200 (Mon, 13 Jun
> 2011)
>
> Log Message
>
> imported package rake

already exist in mageia in ruby-rake

Re: [Mageia-dev] [RPM] cauldron core/release iceape-2.1-1.mga2

[Dick Gevers]

On Mon, 13 Jun 2011 15:10:47 +0200 (CEST), Mageia Team wrote about [RPM]
cauldron core/release iceape-2.1-1.mga2:

>Name: iceape   Relocations: (not relocatable)
>Version : 2.1   Vendor: Mageia.Org
>Release : 1.mga2Build Date: Mon Jun 13
>14:41:21 2011 Install Date: (not installed)   Build Host:
>ecosse Group   : Networking/WWWSource RPM: (none)
>Size: 103538083License: MPL
>Signature   : (none)
>Packager: Mageia Team 
>URL : http://www.seamonkey-project.org/
>Summary : IceApe, the all-in-one internet application suite

>cjw  0:2.1-1.mga2:
>+ Revision: 105755
>- iceape 2.1


The personal toolbar contains five Mandriva links.

HTH
=Dick Gevers=

[Mageia-dev] gtk+3.0 changes

[Ahmad Samir]

Hello,

Just a minor change in gtk+3.0, the gtk-query-immodules* executable
has been moved from the lib package to to the main package, so if you
get get any file conflicts errors when updating, you should install
the lib package first:
# urpmi libgtk+3_0-3.0.11

it's lib64gtk+3_0-3.0.11 if you're running x86_64. Then update your
system (urpmi --auto-update).


This issue only happened in Cauldron (for about 2 weeks), so no
conflicts will be added.

-- 
Ahmad Samir

Re: [Mageia-dev] Release cycles proposals, and discussion

[Thorsten van Lil]

Am Sonntag, 12. Juni 2011, 22:46:33 schrieb Michael Scherer:
> Proposal 1: 
> 6 months release cycle -> 12 months life cycle
> ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
> 
> Proposal 2: 
> 9 months release cycle -> 18 months life cycle  
> ( ~ opensuse and the one we used for Mageia 1 )
> 
> Proposal 3: 
> 12 months release cycle -> 24 months life cycle
> ( Mandriva > 2010.1 )

Here is my opinion for this discussion:

The question of the release cycle is conected with the question of the release 
model.

And all proposals we make are restricted by the manpower.

Actally there are two release models active in the linux scene:
1. a static release every X months
2. a rolling release

*But* a mix of both is also possible.

A rolling release has following advantages:
1. the distribution is always up to date (also hardware support) 
2. no re-install over and over again

and following disadvantages
1. it's a heavy load for the devs
2. we can almost only ship vanilla software. No real integration in the 
distribution. With all it's advantages and disadvantages
3. hard to guarantee the stability over the years
4. no inovations within the software (see second disadvantage)

A static releas has the following advantages:
1. less load for the devs
2. easier to support
3. patching is possible
4. most distribution use this release model

and followind disadvantages;
1. no new hardware support
2. no new software versions

This is the current situation.

Some users also wants the a mix of both (also called a light rolling release) 
and combine the advantages as far as possible.
This could look like this:
Bring up a release once a year. The core (kernel, glib, ...) will only get 
minor updates. Apllications like firefox, libreoffice, ... will always be up to 
date (rolling). Maybe also the desktop envirenments could be rolling but this 
is very heavy.

The light rolling releas has the following advantages:
1. the apps are always up to date
2. less load for devs than a full rolling release
3. patching is possible
4. innovations are possible
5. no other distribution is using such a release model
6. the stability is easier to guarentee than rolling release

and following disadvantages
1. more load than static release
2. no new hardware support (could be done via backports if needed)

If such a release model is possible, is up to the devs to decide (I can't 
evaluate the work load). But we have to bear in mind, that we have enough 
range for new inovations. 

Please keep also in mind, that a distribution doesn't or shouldn't exists for 
end in itself. It's just a operating systems and as long as there isn't a real 
need for re-installing we shouldn't. Thus, we shouldn't enforce the user for 
re-installing more than needed.

Hope this wasn't to much text ^^

Greetings,
Thorsten

Re: [Mageia-dev] GNOME3 ?

[Frank Griffin]

On 06/13/2011 04:05 PM, Dexter Morgan wrote:

nice i fix this one



The reason I ask is that on an ID previously using GNOME 2.32, the 
desktop comes up, but launching any application drives the video crazy.  
You can see the app window some of the time, but after a second or two 
of video flashing you get a fullscreen  "Oops" panel and are told to log 
out.  On a fresh ID, you can't even get the desktop to come up - you get 
the blue background, the mouse pointer circles for a bit and then stops, 
with no error and no recourse but CTRL-ALT-BKSP.

Re: [Mageia-dev] GNOME3 ?

[Dexter Morgan]

On Mon, Jun 13, 2011 at 10:04 PM, Dick Gevers  wrote:
> On Mon, 13 Jun 2011 15:49:15 -0400, Frank Griffin wrote about [Mageia-dev]
> GNOME3 ?:
>
>>Is the GNOME3 upload complete to the point where bug reports will be
>>useful ?
>
> I doubt it:
> # rpm -qa |grep me-des
>
> gnome-desktop-2.32.1-1.mga1
> gnome-desktop3-3.0.2-3.mga2
> lib64gnome-desktop-3_0-3.0.2-3.mga2
>
> # rpm -ev gnome-desktop
>
> error: Failed dependencies:
>        gnome-desktop is needed by (installed)
> gnome-panel-3.0.2-2.mga2.x86_64
>
> Cheers,
> =Dick Gevers=
>

Should be fixed in next gnome-panel

Re: [Mageia-dev] GNOME3 ?

[Dexter Morgan]

On Mon, Jun 13, 2011 at 10:04 PM, Dick Gevers  wrote:
> On Mon, 13 Jun 2011 15:49:15 -0400, Frank Griffin wrote about [Mageia-dev]
> GNOME3 ?:
>
>>Is the GNOME3 upload complete to the point where bug reports will be
>>useful ?
>
> I doubt it:
> # rpm -qa |grep me-des
>
> gnome-desktop-2.32.1-1.mga1
> gnome-desktop3-3.0.2-3.mga2
> lib64gnome-desktop-3_0-3.0.2-3.mga2
>
> # rpm -ev gnome-desktop
>
> error: Failed dependencies:
>        gnome-desktop is needed by (installed)
> gnome-panel-3.0.2-2.mga2.x86_64
>
> Cheers,
> =Dick Gevers=
>

nice i fix this one

Re: [Mageia-dev] GNOME3 ?

[Dick Gevers]

On Mon, 13 Jun 2011 15:49:15 -0400, Frank Griffin wrote about [Mageia-dev]
GNOME3 ?:

>Is the GNOME3 upload complete to the point where bug reports will be 
>useful ?

I doubt it:
# rpm -qa |grep me-des

gnome-desktop-2.32.1-1.mga1
gnome-desktop3-3.0.2-3.mga2
lib64gnome-desktop-3_0-3.0.2-3.mga2

# rpm -ev gnome-desktop

error: Failed dependencies:
gnome-desktop is needed by (installed)
gnome-panel-3.0.2-2.mga2.x86_64

Cheers,
=Dick Gevers=

[Mageia-dev] GNOME3 ?

[Frank Griffin]

Is the GNOME3 upload complete to the point where bug reports will be 
useful ?

Re: [Mageia-dev] Release cycles proposals, and discussion

[lebarhon]

From *pmithrandir 
*  
on the forum


On my side, I think mageia should do a "mix" of others idea.

I would say :
- A release every year.
- During this year, a way to update some popular stuff (firefox, chrome, 
libreoffice...)
- During this year also a way to add some new package if needed or if 
there is some instant success for a new software.


Every 3 years, the release is LTS and that mean it would be maintain for 
4 years.


So at the same time, mageia would be in 3 mode :
- The LTS
- The common release
- The cauldron.

With that kind of stuff, you should have no more than one release for 
public at a time, and just one LTS.
If you update main software(we could define a list of no more than 20 
software) people who are crasy about new function, or developper who 
need tham to develop new stuff would be happy.


BTW : I think mailing list are totally outdated and that mageia should 
have a special section in this forum for these discussion, or maybe 
another forum.
It's totally impossible for people who want to participate sometimes to 
follow you emails everydays. It's much faster to read some topic on a 
forum than dozens emails. And your final user should be able to know 
what happen easily. It would be a big + in front of others distributions.

Re: [Mageia-dev] Release cycles proposals, and discussion

[lebarhon]

Le 13/06/2011 19:22, Michael Scherer a écrit :

Le lundi 13 juin 2011 à 18:29 +0200, lebarhon a écrit :

Le 13/06/2011 17:37, Dale Huckeby a écrit :

The consensus so far seems to be:

6 months is too short
12 months is too long
9 months is just about right


You have to choose your public, 6 months is for geeks, 12 months is for
everybody, these people who aren't IT technicians.

That's why Debian, who release every 2 years, is such a hit in the non
geek population.


Funny boy, you get me stuck here !
I would say, this people are geek enough to enjoy installing the same 
release many times.

But believe me, you have to be fluent to enjoy an OS installation.

Re: [Mageia-dev] perl 5.14 migration almost complete, 3 (non-cpan) modules to go - need help from their owner!

[philippe makowski]

2011/6/13 Jerome Quelin :
> - perl-DBD-Firebird
>
> this module does not compile with perl 5.14: no success reported by any
> cpan testers. i've added a conflicts in perl to have a smooth transition
> too. it'll be updated when a new version is available upstream.
>
thanks reporting, I will contact upstream

Re: [Mageia-dev] Release cycles proposals, and discussion

[Anne nicolas]

2011/6/13 Lee Forest 

> I like the idea of releasing when ready. Its done when the team thinks its
> ready and not because its being demanded by end users. In Linux Mint this
> does alot of good because of having to clean up after ubuntu so much. The
> releases are much more stable and polished. The way clement lefabre likes
> it. And everyone who uses it is usually satisfied with the end product.
>
Well this is theway it seems we are going to, some people proposing 9 months
release depending on release dates of main softwares. Anyway whatever the
choice, it's obvious that we will not release final one if  this is not
stable enough.

> As for being in the news more, we dont have to put out a release just to be
> able blog about whats going on in the mageia community and remind everyone
> why mageia is special. But this must be the case because theres rarely any
> new news posted in mageia blog unless a release is coming out. Thats getting
> about as lame as these messages in this mailing list telling people they
> sent their message to the mailing list wrong.
> What is this distro really about? One upping mandriva and following the
> same mechanical routines they did to piss you guys off, or building a real
> community distribution of gnu/linux that cares more about keeping in touch
> with the community than they do about the way someone new sent a mailing
> list message. Theres more to a linux community then mailing lists.
> At first I was excited about using mageia, and being a part of the
> community. Now im dissappointed because I see how you treat people that are
> not on the team. Basically like their opinions
>
Not at all. everyone can subscribe mailing- lists. The point is Mageia is a
young project and we cannot afford for now at least to spread efforts on
forums and mailing-lists and blogs... People still sleep during the night.
It may not be perfect but it's a start. Our points is just to try to get all
opinions in a same place, that's all.

> (that you ask for) dont matter, and you are only concerned with the proper
> submission of mailing lists messages. Get someone on the blogs and start
> talking to the rest of the community the way they deserve. I agree with the
> gentleman leaving the mailing list. This isn't worth sticking around for.
> Time to remember why you started mageia in the first place.
>
Of course we are opened to any of your proposals and ideas and contributions
to improve all this :)

Cheers



> On Jun 13, 2011 12:51 PM, "Ron"  wrote:
> > I will say my part and I'm gone...
> > I don't understand why everyone is acting like a rolling release is going
> to put so much strain on the project. What is so hard about developing in
> one place and allowing the updates to trickle down is so hard?
> > It almost seems to me that you want to ask the opinion of people, but
> don't want to hear.
> > And what is this posting here? I don't even know how to use this thing
> and yet I had to signup to get my voice heard because this is the way you
> want to do things? I don't understand where the whole community fits into
> this here right now, I think I actually say a lot when I say that many
> people want a rolling release It just seems the developers will have the
> way here... Why ask in the first place? Really?
> > I am leaving the list and sorry about the HTML in my emails, must be a
> yahoo thing because I did not use HTML... Again I don't know how to use this
> thing and should not have been forced to.
> > I would also say that I, for 1 will not be staying if you are going to do
> a release cycle only... I have loads of options if I just want snapshots of
> what's going on in the Linux world Arch gives me so much more and I had
> hopes of switching to this with a release model that made sense... But it
> seems we won't and we will just become yet another XXX release cycle
> distribution with no clear anything that sets us apart from X.
> > On you, I'm gone and thanks for hearing me and sorry if my postings were
> done wrong
>



-- 
Anne
http://www.mageia.org

Re: [Mageia-dev] Release cycles proposals, and discussion

[Wolfgang Bornath]

2011/6/13 Lee Forest :
> I like the idea of releasing when ready. Its done when the team thinks its
> ready and not because its being demanded by end users.

Yes. in a world without users this is the best solution. But there are
users. Giving them a "when it's ready" as release date opens doors for
all kinds of questions about this "it's ready", like, "how can you say
it's ready when package foo is not included in it's newest version?"

> As for being in the news more, we dont have to put out a release just to be
> able blog about whats going on in the mageia community and remind everyone
> why mageia is special. But this must be the case because theres rarely any
> new news posted in mageia blog unless a release is coming out.

Oh, you haven't read the blog for some time? The blog is about what we
do, there was a release coming up on June 1st, so during pre-release
time the blog was mainly about the release. But there have been a lot
of other articles, if you miss a certain subject, tell us what you
want to read about.

> Thats getting
> about as lame as these messages in this mailing list telling people they
> sent their message to the mailing list wrong.

Yes, it is a PITA that such messages seem to be needed again and again
to keep the flow of mails readable in a thread.

> At first I was excited about using mageia, and being a part of the
> community. Now im dissappointed because I see how you treat people that are
> not on the team. Basically like their opinions
> (that you ask for) dont matter, and you are only concerned with the proper
> submission of mailing lists messages. Get someone on the blogs and start
> talking to the rest of the community the way they deserve. I agree with the
> gentleman leaving the mailing list. This isn't worth sticking around for.
> Time to remember why you started mageia in the first place.

A community has almost as many different ideas and answers as the
number of people involved. So it may be that one who gives his opinion
gets replies with different opinions - this is called "discussions".

The side question here was why Ron did not write his opinion in the
thread where the rest of the discussion already took place. I would
think this is a reasonable request to make it easier for those who
will have the task of gathering all the opinions - to do just what you
say we are neglecting. The remark about proper posting style was just
a remark to keep the flow of discussion easy to follow, also a
reasonable request.

In an ideal world the person in question would have followed the
remarks and kept up advocating his opinion where all others are
discussing the matter. But if somebody prefers to put such reasonable
requests in front instead, so be it.

-- 
wobo

Re: [Mageia-dev] Release cycles proposals, and discussion

[Lee Forest]

I like the idea of releasing when ready. Its done when the team thinks its
ready and not because its being demanded by end users. In Linux Mint this
does alot of good because of having to clean up after ubuntu so much. The
releases are much more stable and polished. The way clement lefabre likes
it. And everyone who uses it is usually satisfied with the end product.
As for being in the news more, we dont have to put out a release just to be
able blog about whats going on in the mageia community and remind everyone
why mageia is special. But this must be the case because theres rarely any
new news posted in mageia blog unless a release is coming out. Thats getting
about as lame as these messages in this mailing list telling people they
sent their message to the mailing list wrong.
What is this distro really about? One upping mandriva and following the same
mechanical routines they did to piss you guys off, or building a real
community distribution of gnu/linux that cares more about keeping in touch
with the community than they do about the way someone new sent a mailing
list message. Theres more to a linux community then mailing lists.
At first I was excited about using mageia, and being a part of the
community. Now im dissappointed because I see how you treat people that are
not on the team. Basically like their opinions
(that you ask for) dont matter, and you are only concerned with the proper
submission of mailing lists messages. Get someone on the blogs and start
talking to the rest of the community the way they deserve. I agree with the
gentleman leaving the mailing list. This isn't worth sticking around for.
Time to remember why you started mageia in the first place.
On Jun 13, 2011 12:51 PM, "Ron"  wrote:
> I will say my part and I'm gone...
> I don't understand why everyone is acting like a rolling release is going
to put so much strain on the project. What is so hard about developing in
one place and allowing the updates to trickle down is so hard?
> It almost seems to me that you want to ask the opinion of people, but
don't want to hear.
> And what is this posting here? I don't even know how to use this thing and
yet I had to signup to get my voice heard because this is the way you want
to do things? I don't understand where the whole community fits into this
here right now, I think I actually say a lot when I say that many people
want a rolling release It just seems the developers will have the way
here... Why ask in the first place? Really?
> I am leaving the list and sorry about the HTML in my emails, must be a
yahoo thing because I did not use HTML... Again I don't know how to use this
thing and should not have been forced to.
> I would also say that I, for 1 will not be staying if you are going to do
a release cycle only... I have loads of options if I just want snapshots of
what's going on in the Linux world Arch gives me so much more and I had
hopes of switching to this with a release model that made sense... But it
seems we won't and we will just become yet another XXX release cycle
distribution with no clear anything that sets us apart from X.
> On you, I'm gone and thanks for hearing me and sorry if my postings were
done wrong

Re: [Mageia-dev] Release cycles proposals, and discussion

[Maarten Vanraes]

Op maandag 13 juni 2011 18:51:40 schreef Ron:
> I will say my part and I'm gone...
> I don't understand why everyone is acting like a rolling release is going
> to put so much strain on the project. What is so hard about developing in
> one place and allowing the updates to trickle down is so hard? It almost
> seems to me that you want to ask the opinion of people, but don't want to
> hear. And what is this posting here? I don't even know how to use this
> thing and yet I had to signup to get my voice heard because this is the
> way you want to do things? I don't understand where the whole community
> fits into this here right now, I think I actually say a lot when I say
> that many people want a rolling release It just seems the developers
> will have the way here... Why ask in the first place? Really? I am leaving
> the list and sorry about the HTML in my emails, must be a yahoo thing
> because I did not use HTML... Again I don't know how to use this thing and
> should not have been forced to. I would also say that I, for 1 will not be
> staying if you are going to do a release cycle only... I have loads of
> options if I just want snapshots of what's going on in the Linux world
> Arch gives me so much more and I had hopes of switching to this with a
> release model that made sense... But it seems we won't and we will just
> become yet another XXX release cycle distribution with no clear anything
> that sets us apart from X. On you, I'm gone and thanks for hearing me and
> sorry if my postings were done wrong

complete rolling release would put a QA strain on each of the levels. think 
about it, it's not only the current package being updated, but also the 
combinations with other packages. (AND also all the long time supported 
versions)

This would mean that for each package being release, it'll have to work with 
the current set of other packages, but also with the packages you'll be doing 
next.

if you have this constant level of QA, you need alot of resources (which we 
don't have in QA), and as an extra result, you'll not have the same level of 
QA you could have, when you're doing a release.

it's much easier (as devs) to just choose a subset of packages, and test those 
out.

if you have X QA-devs, and you have 1 subset of versions of packages, you can 
test alot more than if you have several versions of several packages that need 
to work all with each other in almost any combinations...

not to mention that you need an extra step with QA to put a "group" of 
packages from one level to the next...

sorry, but with our current resources, i vote no. i want current resources to 
be used much more efficiently than with a rolling release.

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le lundi 13 juin 2011 à 18:29 +0200, lebarhon a écrit :
> Le 13/06/2011 17:37, Dale Huckeby a écrit :
> >
> > The consensus so far seems to be:
> >
> > 6 months is too short
> > 12 months is too long
> > 9 months is just about right
> >
> 
> You have to choose your public, 6 months is for geeks, 12 months is for 
> everybody, these people who aren't IT technicians.

That's why Debian, who release every 2 years, is such a hit in the non
geek population.

-- 
Michael Scherer

Re: [Mageia-dev] Release cycles proposals, and discussion

[Sander Lepik]

13.06.2011 19:51, Ron kirjutas:

I will say my part and I'm gone...

I don't understand why everyone is acting like a rolling release is going to put so much 
strain on the project. What is so hard about developing in one place and allowing the 
updates to trickle down is so hard?


Well.. take Cauldron as a rolling release. It basically is :) So from that point of view.. 
why would we need another rolling release if we already have one? :)


--
Sander

[Mageia-dev] Release cycles proposals, and discussion

[Ron]

I will say my part and I'm gone...
I don't understand why everyone is acting like a rolling release is going to 
put so much strain on the project. What is so hard about developing in one 
place and allowing the updates to trickle down is so hard?
It almost seems to me that you want to ask the opinion of people, but don't 
want to hear.
And what is this posting here? I don't even know how to use this thing and yet 
I had to signup to get my voice heard because this is the way you want to do 
things? I don't understand where the whole community fits into this here right 
now, I think I actually say a lot when I say that many people want a rolling 
release It just seems the developers will have the way here... Why ask in 
the first place? Really?
I am leaving the list and sorry about the HTML in my emails, must be a yahoo 
thing because I did not use HTML... Again I don't know how to use this thing 
and should not have been forced to.
I would also say that I, for 1 will not be staying if you are going to do a 
release cycle only... I have loads of options if I just want snapshots of 
what's going on in the Linux world Arch gives me so much more and I had 
hopes of switching to this with a release model that made sense... But it seems 
we won't and we will just become yet another XXX release cycle distribution 
with no clear anything that sets us apart from X.
On you, I'm gone and thanks for hearing me and sorry if my postings were done 
wrong

Re: [Mageia-dev] Release cycles proposals, and discussion

[lebarhon]

Le 13/06/2011 17:37, Dale Huckeby a écrit :


The consensus so far seems to be:

6 months is too short
12 months is too long
9 months is just about right



You have to choose your public, 6 months is for geeks, 12 months is for 
everybody, these people who aren't IT technicians.
The installation of the new release is always something dangerous and 
worrying because there is always the codecs, the nets or some 
applications without rpm package. Moreover, the hardware evolution is 
slowing down and doesn't need so closed together releases.
I would prefer devs doing more different things less often that devs 
doing more often the same things, that isn't going ahead. Take care 
also, not developing things without any documentation, let this 
specialty to KDE.
I would like also that devs give more importance to the installation by 
update than to the new installation  (too much work to configure, desk, 
mail, ML, nets, backups, specific applications to be installed by hand 
like Geneanet or Rawtherapee...)

For all that, 12 months is already very short.

Lebarhon

Re: [Mageia-dev] get-skype package for submission

[Angelo Naselli]

lunedì 13 giugno 2011 alle 16:46, Anssi Hannula ha scritto:
> a) make it print md5sum automatically
Just out of curiosity, md5 has been calculated by your download?
So you trust your first download :D

/me is joking

Angelo


signature.asc
Description: This is a digitally signed message part.

Re: [Mageia-dev] [RPM] cauldron core/release libgdata-0.7.1-1.mga2

[Ahmad Samir]

On 13 June 2011 15:10, Christiaan Welvaart  wrote:
> On Wed, 8 Jun 2011, Balcaen John wrote:
>
>> Le mercredi 8 juin 2011 16:52:16, Mageia Team a écrit :
>>>
>>> Name        : libgdata                     Relocations: (not relocatable)
>>> Version     : 0.7.1                             Vendor: Mageia.Org
>>
>> [...]
>>>
>>> dmorgan  0.7.1-1.mga2:
>>> + Revision: 102030
>>> - New version 0.7.1
>>
>> There's a file conflict :
>> Installation failed:
>>       file /usr/lib64/girepository-1.0/GData-0.0.typelib from install of
>> lib64gdata10-0.7.1-1.mga2.x86_64 conflicts with file from package
>> lib64gdata7-0.6.6-1.mga1.x86_64
>>
>> Installation failed:    file /usr/lib64/girepository-1.0/GData-0.0.typelib
>> from install of lib64gdata10-0.7.1-1.mga2.x86_64 conflicts with file from
>> package lib64gdata7-0.6.6-1.mga1.x86_64
>>
>> Maybe this file should not be in the versionned library package ?
>
> Indeed, but I see no way to really fix the upgrade except by providing a
> fixed lib(64)gdata7 in mga2.
>
> We have poppler-gir0.16 for girepository-1.0/Poppler-0.16.typelib .
> (In ubuntu they call the extra package gir1.0-gdata-0.0 .)
>
> So we should probably add lib(64)gdata-gir0.0 . It must be libified to allow
> parallel installation of libgdata10 and lib64gdata10. The new package will
> conflict with lib(64)gdata7 so all applications that use it (totem and
> evolution) must be rebuilt.
>
>
>    Christiaan
>

Actually, I think I should have libified poppler-gir (only spotted
that issue yesterday updating the folks package... :( ).

-- 
Ahmad Samir

Re: [Mageia-dev] Release cycles proposals, and discussion

[Dale Huckeby]

On Mon, 13 Jun 2011, Wolfgang Bornath wrote:


About the cycles:

The problems with 6-months have been pointed out - my main concern
would be the lack of manpower and the continuous state of
"pre-release", no real room to sit back and contemplate hwat is and
what could be and all the rest. IMHO such a "contemplating" time is
necessary to keep the whole picture in focus.

The problems with 12-months have also been pointed out and I agree
with them (too long out of public focus, too long for the main
userland applications, etc.).

The 9-months seem to be a compromise - but I start to ask why we need
such a fixed statement (which it would be, once published). We need a
schedule for each cycle, that's true. Without a schedule we would
never finish anything. But how about taking 9 months only as a "nice
to meet" target, leaving us the option to set a roadmap after setting
the specs of the next release - we could then go for a 8 or 10 months
roadmap, depending on the specs.

This being said, I am a friend of a rolling release like ArchLinux,
but I fear that our main target group is not up to this. Despite of
having to "burn yet another DVD" as somebody pointed out, the majority
seems to see this as normal and a good way. Of course I may be totally
wrong with this assessment!


+1

The consensus so far seems to be:

6 months is too short
12 months is too long
9 months is just about right

and that applies not only to developers having a chance to catch their breath 
between versions, but
users too.  A 6-month turnaround feels like I'm constantly updating, but a 
12-month wait between
versions is like forever.  And as wobo suggests, 9 months need be only an 
average, with a target date
for the next release, taking into account upstream developments, decided on 
after each one.  Also,
the target date should be approximate at first and firmed up only as we get 
closer to release.

spock

Re: [Mageia-dev] Release cycles proposals, and discussion

[Angelo Naselli]

lunedì 13 giugno 2011 alle 15:08, Thomas Backlund ha scritto:
> Well, it was intended to point out the problem with the "flexible" 
> approach, and a possible "fix" by deciding some limits to the flexibility.
If the decision of how much (+X or -X) is taken during the post release
phase (e.g. now in the pre new release working). it's not that problem.
I mean we decide for 10 mo release because gnome (chose that because i like kde 
:p)
is out in 8 months and we'd like to have 2 months testing -that allows a little 
gnome release delay- so from that point on the release plan is fixed at 10 
months.
Next release we could decide for 6 months because no great changes from the 
world
are expected

But i believe it's hard to follow, because every time we should spend
a lot of time discussing for this stuff and that could be harmless...

Angelo


signature.asc
Description: This is a digitally signed message part.

Re: [Mageia-dev] "Job offer" : mentoring program coordinator

[Cazzaniga Sandro]

Le 13/06/2011 15:19, Samuel Verschelde a écrit :
> Le dimanche 12 juin 2011 18:55:58, Cazzaniga Sandro a écrit :
>> Le 12/06/2011 15:27, Samuel Verschelde a écrit :
>>> Hello to everyone,
>>>
>>> I'm sure there's someone among you who wants to help Mageia but hasn't
>>> found yet the good way to do it. Today is your lucky day, because
>>> there's a job that's available and can be really useful and interesting:
>>> coordinating the packagers mentoring program.
>>>
>>> You know that one key point of success for Mageia is in the ability to
>>> welcome new packagers. The better we will be at it, the better the
>>> distro will be. The packagers mentoring program has been created for
>>> that reason and several packagers have been or are being mentored. But
>>> we have some difficulty knowing who is being mentored by who and who
>>> hasn't found a mentor. And we need also to find more mentors and more
>>> apprentices.
>>>
>>> During a packagers weekly meeting, misc invited us to read the following
>>> article about mentoring programs in open-source projects:
>>> http://blogs.gnome.org/bolsh/2011/05/31/effective-mentoring-programs/
>>>
>>> I invite those who haven't read it yet, to read it. I'll quote one of the
>>> mentoring best practices that were given: "In bigger projects, keeping
>>> track of who is a mentor, and who is mentoring who, and inviting new
>>> mentors, and ensuring that no-one falls through the cracks when a mentor
>>> gets too busy, is a job of itself."
>>>
>>> I'm looking for someone who could fill that "job".
>>>
>>> Description of the job:
>>>
>>> - keep track of:
>>> -- who's being mentored by who, how well it's going
>>> -- who needs a mentor and hasn't found one yet (this is one of the most
>>> important parts: no volunteer must be forgotten, volunteers are too
>>> precious !)
>>> -- who can mentor more apprentices (and sometimes convince packagers to
>>> become mentors or accept one more apprentice)
>>>
>>> - be available for questions from apprentices or mentors, by mail, and if
>>> possible, to be present on the IRC channel #mageia-mentoring on freenode
>>>
>>> - help mentors with gathering "junior tasks" (bugzilla is a never empty
>>> reserve that can be used for that. Maybe ask the bug triage team to help
>>> identify such tasks. Maybe a "junior task" keyword in bugzilla would do
>>> the trick)
>>> -- small bugs to fix
>>> -- new small packages to import in the distribution
>>> -- backports
>>>
>>> - promote mentoring (empower users into contributers. Working with the
>>> marketing team would be great I think):
>>> -- make the mentoring program known (MLs, forums, web, etc.)
>>> -- look for new apprentices
>>> -- look for new mentors
>>>
>>> Some useful skills:
>>> - be autonomous (ie no need to check that you're doing the work)
>>> - good written english (communication is very important in this job)
>>> - knowledge about packaging is a plus but not mandatory (the key aspects
>>> can be taught to you)
>>> - being or having been a mentor, or having been mentored would be a plus,
>>> but not mandatory
>>>
>>> More information about the job:
>>> - does not require a big amount of work, but real committment to the task
>>> and regularity
>>> - remember that you have a coordination role, not an authoritative role.
>>> The difference in that is that you're not here to give orders but to
>>> facilitate the mentoring program.
>>> - you don't have to be alone to do this job if it's too much for one
>>> person: you can find other helpful people wanting to help you if needed
>>> and rely on the other teams (but finding them *is* part of your job ;)
>>> ).
>>> -  this "job offer" concerns everything that revolves around the
>>> mentoring of new packagers, but if it's successful maybe other teams can
>>> follow the same approach (i18n, QA, etc... ).
>>> -  depending on your level of confidence, experience and will, you could
>>> be helped in your work. Maybe someone from the council can supervise and
>>> help you at least at the beginning; or, if no one steps up, I can help
>>> you bootstrap and organize your new "job".
>>>
>>> So, who's in?
>>>
>>> Samuel Verschelde
>>
>> I offer my candidacy. I was mentored by shikamaru and i'm a mandriva
>> packager since 2009 and a mageia packager since the start.
>> My english level is pretty good and i'm pretty sociable.
>>
> 
> Hi,
> 
> As explained on IRC yesterday, your candidacy is interesting, but you have 
> already so many other engagements that I would prefer someone with more 
> availability :) So keep on the good work where you're already committed :)
> 
> Best regards
> 
> Samuel Verschelde
!no problem, thanks!

-- 
Sandro Cazzaniga - https://lederniercoupdarchet.wordpress.com
IRC: Kharec (irc.freenode.net)
Software/Hardware geek
Conceptor
Magnum's Coordinator/editor (http://wiki.mandriva.com/fr/Magnum)
Mageia and Mandriva contributor

Re: [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

[Cazzaniga Sandro]

Le 13/06/2011 15:03, Thomas Backlund a écrit :
> James Kerr skrev 13.6.2011 16:01:
>> On 13/06/11 13:06, Dick Gevers wrote:
>>> On Mon, 13 Jun 2011 09:37:40 +0200, Cazzaniga Sandro wrote about Re:
>>> [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2:
>>>
> Quite a few packages reached the mirrors since this one, but biew has
> not.
>>>
 So it needs a rebuild?
>>>
>>> Anything similar to rebuild, push, boot, shove, %mkrel or opening the
>>> window
>>> to let it fly: IANAE.
>>>
>>
>> In case it's relevant - the i586 package is on the mirrors. It's only
>> x86-64 that's missing.
> 
> That's because spec states:
> 
> ExclusiveArch:  %ix86
> 
> -- 
> Thomas
thanks all!

-- 
Sandro Cazzaniga - https://lederniercoupdarchet.wordpress.com
IRC: Kharec (irc.freenode.net)
Software/Hardware geek
Conceptor
Magnum's Coordinator/editor (http://wiki.mandriva.com/fr/Magnum)
Mageia and Mandriva contributor

Re: [Mageia-dev] update of compiz

[Colin Guthrie]

'Twas brillig, and Balcaen John at 13/06/11 14:39 did gyre and gimble:
> Le lundi 13 juin 2011 09:49:57, Julien a écrit :
> [...]
>>
>> (before continuing, keep in mind that I'm an apprentice since one week,
>> so please forget me if I seem too presumptuous) 
>>
>> 0.9.x series is an unstable series with major modification
>> between release and some tools (such as the decorator emerald) are not
>> yet available.
>>
>> So I would prefer doing it in 2 steps :
>>  - update current compiz to 0.8.8 (and if possible, backport it to
>>mageia 1) and importing emerald
>>  - when 0.9.x series will be more stable, upgrade to 0.9
>>
>> WDYT ?
> It's a good decision as expected from the compiz maintainer :)
> 
> Do we have any ETA regarding the 0.9 series ?

Well, AFAIK, Unity in Ubuntu is based on the 0.9 series of compiz (I
thought that was pretty much what it was written for?) So in that sense
is *should* be fairly stable. but that wasn't my expiernce when
testing it, but I didn't spend too long on it.

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] Cross compile x86_64 on i586 for icecream?

[Colin Guthrie]

'Twas brillig, and Christiaan Welvaart at 13/06/11 12:24 did gyre and
gimble:
> On Mon, 13 Jun 2011, Colin Guthrie wrote:
> 
>> I'm not exactly a guru with icecream but is it possible to build a
>> toolchain that can allow i586 nodes to compile x86_64 code?
> 
> If your question is about the toolchain, have you tried simply passing
> -m64 to gcc?

Do you happen to know how to do that magically via icecream (the problem
I'm getting is that the other nodes are simply not doing anything...
perhaps the problem is related to ccache on the node doing the actual
building (the cache being seen as a superior option to the remote
nodes). Or maybe I just don't have all the necessary bits installed on
the other nodes

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] get-skype package for submission

[Anssi Hannula]

On 13.06.2011 17:31, Barry Jackson wrote:
> On 13/06/11 13:24, Anssi Hannula wrote:
>> Note that your "if ! [[ -d %{tmpdir} ]]; then" check is not 100%
>> necessary, as %tmpdir not existing is unlikely and causes no side
>> effects.
>>
> 
> I added that as the dir is created by tar, so if the tarball had the
> wrong content the dir may not be created with the correct name.
> Unlikely as you say.

Yep, but in that case nothing bad happens anyway. A couple of errors
from failing cp and mv commands are printed, but nothing else.

> I have started writing a script to generate the .txt files but can't
> decide whether it should go as far as downloading the source from Skype
> or simply be run on an extracted skype- folder.

It could do both :)
Doesn't really matter, this is all extra anyway.

Note that if you make it download it, you could also implement:
a) make it print md5sum automatically
b) make it print the dependencies automatically
(see e.g. the earlier google earth script which does those IIRC)

But as said, all of this is extra. Maybe the priority should be getting
you a mentor.

> A first draft of this is attached.
> I assume this would ultimately be added as a SOURCE file with notes in
> the package.

Yep.

-- 
Anssi Hannula

Re: [Mageia-dev] get-skype package for submission

[Barry Jackson]

On 13/06/11 13:24, Anssi Hannula wrote:

On 12.06.2011 02:37, Barry Jackson wrote:

On 11/06/11 18:03, Anssi Hannula wrote:


- Best to add a comment in the %post script to remind that any new files
need to have a %ghost entry created.
(btw: an alternative idea is to create a post-script and the filelist
 at the same time in a single for loop in %build/%install, so that
 the lists can never get out of sync as they are created from a single
 list; however, your current solution is adequate as well)


Note added - keep it simple.



You added the note in the %files section, not in %post. The issue only
happens if someone updates %post but not %files, so it doesn't make
sense to put the reminder in %files :)



OK moved


- You don't check for failures. If the mktemp call fails, you extract
the tarball into /root etc.etc.. You need to check for failures on
the mktemp/mkdir/cd commands (mktemp failure can be detected by
checking if $newtmp string is empty), or alternatively run "set -e"
to make the shell exit on failures (this leaves the tmpdir polluted,
but it doesn't matter as much as it is an uncommon failure case and
/tmp is cleaned periodically anyway).


Added some checks - with clean-up of previously created dirs etc on fail.



mkdir %{mytmp}
[[ -d %{mytmp} ]] || exit 1
cd %{mytmp}


cd is not guaranteed to work even if %mytmp exists. Add "|| exit 1".



OK - done.


cd ${tmpextdir}
tar jxf %{mytmp}/skype-%{version}.tar.bz2


Same here...

Well, actually these two aren't that serious, since they can't be
exploited by non-root anyway. I'm somewhat ok with them, as long as your
mentor is as well and no one else objects.



I need a mentor ;)


Note that your "if ! [[ -d %{tmpdir} ]]; then" check is not 100%
necessary, as %tmpdir not existing is unlikely and causes no side effects.



I added that as the dir is created by tar, so if the tarball had the 
wrong content the dir may not be created with the correct name.

Unlikely as you say.


Other nits:
- Use better variable names- %mytmp, $tmpextdir, %tmpdir are confusing.


Changed to tmp_download_dir, tmp_extract_dir and tmp_skype_dir


- The description starts with an empty line. Remove it.


Gone





I have started writing a script to generate the .txt files but can't 
decide whether it should go as far as downloading the source from Skype 
or simply be run on an extracted skype- folder.

A first draft of this is attached.
I assume this would ultimately be added as a SOURCE file with notes in 
the package.


Barry
%define nameget-skype
%define version 2.2.0.35
%define release %mkrel 9
%define instdir %{_datadir}/skype
%define langdir %{instdir}/lang
%define avatardir   %{instdir}/avatars
%define sounddir%{instdir}/sounds
%define icondir %{instdir}/icons
%define md5 6e28002c0086fae5206e2d242c3edcfa
%define tmp_download_dir%{_localstatedir}/lib/%{name}

Summary:Download and Install Skype
Name:   %{name}
Version:%{version}
Release:%{release}
License:Proprietary
Group:  Networking/Instant messaging
URL:http://www.skype.com
Buildarch:  noarch
Requires:   wget
Requires:   liblcms1
Requires:   libmng1
Requires:   libqtcore4
Requires:   libqtdbus4
Requires:   libqtnetwork4
Requires:   libqtgui4
Requires:   libqtsvg4
Requires:   libqtxml4
Requires:   libxscrnsaver1
Requires:   libxv1
Requires:   libv4l-wrappers

# The following are lists of filenames (124 in total) placed 
# in versioned text files to save clutter in the spec file.
Source0:avatars-%{version}.txt
Source1:sounds-%{version}.txt
Source2:lang-%{version}.txt

%description
This is an installer for Skype-%{version}.

This package does not contain any files as the Skype license does not allow 
distribution.
By installing this package you will download and install Skype from skype.com.
You must accept the Skype EULA before using it.
Please be patient, this is a 23MB download and may take some time.
Uninstalling this package will uninstall Skype from your system.

%pre

mkdir %{tmp_download_dir}
[[ -d %{tmp_download_dir} ]] || exit 1
cd %{tmp_download_dir} || exit 1
wget -nc "http://download.skype.com/linux/skype-%{version}.tar.bz2";

md5chk=$(md5sum skype-%{version}.tar.bz2 | cut -d' ' -f1)
if [[ %{md5} != $md5chk ]]; then
rm skype-%{version}.tar.bz2
cd ..
rm -r %{tmp_download_dir}
echo "Error - download checksum failed"
exit 1
fi

%install

rm -rf $RPM_BUILD_ROOT
install -d -m 0755 %buildroot%{_bindir}
install -d -m 0755 %buildroot%{_datadir}/applications
touch %buildroot%{_datadir}/applications/skype.desktop

install -d -m 0755 %buildroot%{instdir}
touch %buildroot%{instdir}/{skype.desktop,skype,skype.conf,LICENSE,README}

install -d -m 0755 %buildroot%{langdir}
while re

Re: [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

[Dick Gevers]

On Mon, 13 Jun 2011 16:03:34 +0300, Thomas Backlund wrote about Re:
[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2:

>James Kerr skrev 13.6.2011 16:01:
>> On 13/06/11 13:06, Dick Gevers wrote:
>>> On Mon, 13 Jun 2011 09:37:40 +0200, Cazzaniga Sandro wrote about Re:
>>> [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2:
>>>
> Quite a few packages reached the mirrors since this one, but biew has
> not.
>>>
 So it needs a rebuild?
>>>
>>> Anything similar to rebuild, push, boot, shove, %mkrel or opening the
>>> window to let it fly: IANAE.
>>>
>>
>> In case it's relevant - the i586 package is on the mirrors. It's only
>> x86-64 that's missing.
>
>That's because spec states:
>
>ExclusiveArch:  %ix86

Oh. Shucks.

Re: [Mageia-dev] [RPM] cauldron core/release libgdata-0.7.1-1.mga2

[Christiaan Welvaart]

On Mon, 13 Jun 2011, Anssi Hannula wrote:


On 13.06.2011 16:10, Christiaan Welvaart wrote:

On Wed, 8 Jun 2011, Balcaen John wrote:


Le mercredi 8 juin 2011 16:52:16, Mageia Team a écrit :

Name: libgdata Relocations: (not
relocatable)
Version : 0.7.1 Vendor: Mageia.Org

[...]

dmorgan  0.7.1-1.mga2:
+ Revision: 102030
- New version 0.7.1

There's a file conflict :
Installation failed:
   file /usr/lib64/girepository-1.0/GData-0.0.typelib from install of
lib64gdata10-0.7.1-1.mga2.x86_64 conflicts with file from package
lib64gdata7-0.6.6-1.mga1.x86_64

Installation failed:file
/usr/lib64/girepository-1.0/GData-0.0.typelib
from install of lib64gdata10-0.7.1-1.mga2.x86_64 conflicts with file from
package lib64gdata7-0.6.6-1.mga1.x86_64

Maybe this file should not be in the versionned library package ?


Indeed, but I see no way to really fix the upgrade except by providing a
fixed lib(64)gdata7 in mga2.

We have poppler-gir0.16 for girepository-1.0/Poppler-0.16.typelib .
(In ubuntu they call the extra package gir1.0-gdata-0.0 .)

So we should probably add lib(64)gdata-gir0.0 . It must be libified to
allow parallel installation of libgdata10 and lib64gdata10. The new
package will conflict with lib(64)gdata7 so all applications that use it
(totem and evolution) must be rebuilt.


BTW, I like the ubuntu(/debian?) naming convention here. But I'm not
going to work on it, so feel free to name it as you like.


It looks interesting, but I don't know anything about gobject 
introspection so can't say if it makes more sense than what I proposed. 
Anyway that naming is not going to work with biarch and I'm not going to 
move all those files to %_datadir, that may not even work.



Christiaan

Re: [Mageia-dev] [RPM] cauldron core/release libgdata-0.7.1-1.mga2

[Anssi Hannula]

On 13.06.2011 16:10, Christiaan Welvaart wrote:
> On Wed, 8 Jun 2011, Balcaen John wrote:
> 
>> Le mercredi 8 juin 2011 16:52:16, Mageia Team a écrit :
>>> Name: libgdata Relocations: (not
>>> relocatable)
>>> Version : 0.7.1 Vendor: Mageia.Org
>> [...]
>>> dmorgan  0.7.1-1.mga2:
>>> + Revision: 102030
>>> - New version 0.7.1
>> There's a file conflict :
>> Installation failed:
>>file /usr/lib64/girepository-1.0/GData-0.0.typelib from install of
>> lib64gdata10-0.7.1-1.mga2.x86_64 conflicts with file from package
>> lib64gdata7-0.6.6-1.mga1.x86_64
>>
>> Installation failed:file
>> /usr/lib64/girepository-1.0/GData-0.0.typelib
>> from install of lib64gdata10-0.7.1-1.mga2.x86_64 conflicts with file from
>> package lib64gdata7-0.6.6-1.mga1.x86_64
>>
>> Maybe this file should not be in the versionned library package ?
> 
> Indeed, but I see no way to really fix the upgrade except by providing a
> fixed lib(64)gdata7 in mga2.
> 
> We have poppler-gir0.16 for girepository-1.0/Poppler-0.16.typelib .
> (In ubuntu they call the extra package gir1.0-gdata-0.0 .)
> 
> So we should probably add lib(64)gdata-gir0.0 . It must be libified to
> allow parallel installation of libgdata10 and lib64gdata10. The new
> package will conflict with lib(64)gdata7 so all applications that use it
> (totem and evolution) must be rebuilt.

BTW, I like the ubuntu(/debian?) naming convention here. But I'm not
going to work on it, so feel free to name it as you like.

-- 
Anssi Hannula

Re: [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

[Dick Gevers]

On Mon, 13 Jun 2011 15:39:55 +0200, Maarten Vanraes wrote about Re:
[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2:

>Op maandag 13 juni 2011 15:13:04 schreef Dick Gevers:
>> >so, in other words, he's saying: "don't ask me, i know nothing"
>> 
>> Nou dank je wel
>> 
>> :(
>
>it was kind of a semi-joke (a la monty python) :-S

Then you should have said: "you're welcome".

>:->

(En dat wist ik wel!)

Re: [Mageia-dev] update of compiz

[Balcaen John]

Le lundi 13 juin 2011 09:49:57, Julien a écrit :
[...]
> 
> (before continuing, keep in mind that I'm an apprentice since one week,
> so please forget me if I seem too presumptuous) 
> 
> 0.9.x series is an unstable series with major modification
> between release and some tools (such as the decorator emerald) are not
> yet available.
> 
> So I would prefer doing it in 2 steps :
>  - update current compiz to 0.8.8 (and if possible, backport it to
>mageia 1) and importing emerald
>  - when 0.9.x series will be more stable, upgrade to 0.9
> 
> WDYT ?
It's a good decision as expected from the compiz maintainer :)

Do we have any ETA regarding the 0.9 series ?

Regards,

-- 
Balcaen John
Jabber ID: mik...@jabber.littleboboy.net

Re: [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

[Maarten Vanraes]

Op maandag 13 juni 2011 15:13:04 schreef Dick Gevers:
> >so, in other words, he's saying: "don't ask me, i know nothing"
> 
> Nou dank je wel
> 
> :(

it was kind of a semi-joke (a la monty python) :-S

Re: [Mageia-dev] update of compiz

[Julien]

Le Sun, 12 Jun 2011 23:47:01 +0100,
Colin Guthrie  a écrit :

> 'Twas brillig, and Dexter Morgan at 12/06/11 23:16 did gyre and
> gimble:
> > On Sun, Jun 12, 2011 at 9:39 PM, julien  wrote:
> >> Hi,
> >>
> >> I would like to update compiz to v0.8.8.
> >>
> >> any objection ?
> >>
> >> regards
> >> julien
> >>
> > 
> > Hello,
> > 
> > fedora uses compiz 0.9.4 do you think we can directly go to this
> > version ?
> > 
> > Btw, glad to see someone taking compiz maintainership, congrats.
> 
> It would be nice to go to the latest compiz I did update it locally a
> while back to the 0.9 series but it crashed on my system before I got
> a chance to really look into it.
> 
> I've still got the packages here, so I could commit them and/or
> publish patches if you could use them as a base?
> 
> Col
> 

Hi,

(before continuing, keep in mind that I'm an apprentice since one week,
so please forget me if I seem too presumptuous) 

0.9.x series is an unstable series with major modification
between release and some tools (such as the decorator emerald) are not
yet available.

So I would prefer doing it in 2 steps :
 - update current compiz to 0.8.8 (and if possible, backport it to
   mageia 1) and importing emerald
 - when 0.9.x series will be more stable, upgrade to 0.9

WDYT ?

regards
julien

Re: [Mageia-dev] Question about backports: calibre (bug 1659)

[Angelo Naselli]

>Two people asserted that a newer calibre package should go into backports, not 
>updates.

I said also that there could be exceptions...


> Therefore, I strongly believe that all calibre updates be packaged into 
> updates, not backports, especially as there isn't any Mageia 2.0 as of yet. 
> Once Mageia 2.0 is released, whatever newer calibre releases will be 
> available might go into backports instead -- if at all. (Although I'd say 
> that it should still be updated to updates for the whole supported time of 
> 1.0.)
Backports is meant from cauldron

Angelo


signature.asc
Description: This is a digitally signed message part.

Re: [Mageia-dev] "Job offer" : mentoring program coordinator

[magnus]

>
>
>  As I said with different
> words, not using a volunteer's help would be a crime !
>
> Samuel
>

:-))
I ready to start

Magnus

Re: [Mageia-dev] "Job offer" : mentoring program coordinator

[Samuel Verschelde]

Le dimanche 12 juin 2011 18:55:58, Cazzaniga Sandro a écrit :
> Le 12/06/2011 15:27, Samuel Verschelde a écrit :
> > Hello to everyone,
> > 
> > I'm sure there's someone among you who wants to help Mageia but hasn't
> > found yet the good way to do it. Today is your lucky day, because
> > there's a job that's available and can be really useful and interesting:
> > coordinating the packagers mentoring program.
> > 
> > You know that one key point of success for Mageia is in the ability to
> > welcome new packagers. The better we will be at it, the better the
> > distro will be. The packagers mentoring program has been created for
> > that reason and several packagers have been or are being mentored. But
> > we have some difficulty knowing who is being mentored by who and who
> > hasn't found a mentor. And we need also to find more mentors and more
> > apprentices.
> > 
> > During a packagers weekly meeting, misc invited us to read the following
> > article about mentoring programs in open-source projects:
> > http://blogs.gnome.org/bolsh/2011/05/31/effective-mentoring-programs/
> > 
> > I invite those who haven't read it yet, to read it. I'll quote one of the
> > mentoring best practices that were given: "In bigger projects, keeping
> > track of who is a mentor, and who is mentoring who, and inviting new
> > mentors, and ensuring that no-one falls through the cracks when a mentor
> > gets too busy, is a job of itself."
> > 
> > I'm looking for someone who could fill that "job".
> > 
> > Description of the job:
> > 
> > - keep track of:
> > -- who's being mentored by who, how well it's going
> > -- who needs a mentor and hasn't found one yet (this is one of the most
> > important parts: no volunteer must be forgotten, volunteers are too
> > precious !)
> > -- who can mentor more apprentices (and sometimes convince packagers to
> > become mentors or accept one more apprentice)
> > 
> > - be available for questions from apprentices or mentors, by mail, and if
> > possible, to be present on the IRC channel #mageia-mentoring on freenode
> > 
> > - help mentors with gathering "junior tasks" (bugzilla is a never empty
> > reserve that can be used for that. Maybe ask the bug triage team to help
> > identify such tasks. Maybe a "junior task" keyword in bugzilla would do
> > the trick)
> > -- small bugs to fix
> > -- new small packages to import in the distribution
> > -- backports
> > 
> > - promote mentoring (empower users into contributers. Working with the
> > marketing team would be great I think):
> > -- make the mentoring program known (MLs, forums, web, etc.)
> > -- look for new apprentices
> > -- look for new mentors
> > 
> > Some useful skills:
> > - be autonomous (ie no need to check that you're doing the work)
> > - good written english (communication is very important in this job)
> > - knowledge about packaging is a plus but not mandatory (the key aspects
> > can be taught to you)
> > - being or having been a mentor, or having been mentored would be a plus,
> > but not mandatory
> > 
> > More information about the job:
> > - does not require a big amount of work, but real committment to the task
> > and regularity
> > - remember that you have a coordination role, not an authoritative role.
> > The difference in that is that you're not here to give orders but to
> > facilitate the mentoring program.
> > - you don't have to be alone to do this job if it's too much for one
> > person: you can find other helpful people wanting to help you if needed
> > and rely on the other teams (but finding them *is* part of your job ;)
> > ).
> > -  this "job offer" concerns everything that revolves around the
> > mentoring of new packagers, but if it's successful maybe other teams can
> > follow the same approach (i18n, QA, etc... ).
> > -  depending on your level of confidence, experience and will, you could
> > be helped in your work. Maybe someone from the council can supervise and
> > help you at least at the beginning; or, if no one steps up, I can help
> > you bootstrap and organize your new "job".
> > 
> > So, who's in?
> > 
> > Samuel Verschelde
> 
> I offer my candidacy. I was mentored by shikamaru and i'm a mandriva
> packager since 2009 and a mageia packager since the start.
> My english level is pretty good and i'm pretty sociable.
> 

Hi,

As explained on IRC yesterday, your candidacy is interesting, but you have 
already so many other engagements that I would prefer someone with more 
availability :) So keep on the good work where you're already committed :)

Best regards

Samuel Verschelde

Re: [Mageia-dev] "Job offer" : mentoring program coordinator

[Samuel Verschelde]

Le dimanche 12 juin 2011 19:49:31, magnus a écrit :
> Hello,
> I'm not offer my candidacy, I'm only a simple user.
> But I offer my help as secrtary of the secratary of .. the coordinator
> 
> As Mageia and I have the same birthday I'm following the upgroth since the
> beginning.
> Also with a little help during qa for the final.
> 
> As I saw some requests for mentoring on the ml, I think it is important to
> show a quick response.
> So mentoring team can do this, ask for the skill or say look to foo1, foo2
> or foo3 on the bug-list
> during we are looking for mentor.
> (perhaps the packagers can classify the complexity of new-package-request
> and "simple" bugs)
> 
> Also very important ist the actuality of the wiki.
> So we must have a look on the bug-list, ml and irc not to loose any request
> for mentoring.
> On the other side we must have/build a very good communicatio to the
> packagers to avoid double work on packages
> and to help for equal distribution of the mentoring work.
> 
> Although not filling the wanted skills (no packager, no being a mentor, not
> good english knowledge)
> I'm ready to help.
> 
> I think some more eyes are always good :-)
> 
> So if I can help call me
> 
> Magnus
> 
> PS: In my job as it-auditor documentation, communication and learning new
> thinks are the normal things
> 

Thanks for your help proposal. I think the future coordinator (when choosen) 
can take note of it and now that you can help him/her. As I said with different 
words, not using a volunteer's help would be a crime !

Samuel

Re: [Mageia-dev] "Job offer" : mentoring program coordinator

[Samuel Verschelde]

Le lundi 13 juin 2011 00:52:18, andre999 a écrit :
> Samuel Verschelde a écrit :
> > Hello to everyone,
> > 
> > I'm sure there's someone among you who wants to help Mageia but hasn't
> > found yet the good way to do it. Today is your lucky day, because
> > there's a job that's available and can be really useful and interesting:
> > coordinating the packagers mentoring program.
> > 
> > You know that one key point of success for Mageia is in the ability to
> > welcome new packagers. The better we will be at it, the better the
> > distro will be. The packagers mentoring program has been created for
> > that reason and several packagers have been or are being mentored. But
> > we have some difficulty knowing who is being mentored by who and who
> > hasn't found a mentor. And we need also to find more mentors and more
> > apprentices.
> > 
> > During a packagers weekly meeting, misc invited us to read the following
> > article about mentoring programs in open-source projects:
> > http://blogs.gnome.org/bolsh/2011/05/31/effective-mentoring-programs/
> 
> Very interesting, especially many of the comments.
> 
> > I invite those who haven't read it yet, to read it. I'll quote one of the
> > mentoring best practices that were given: "In bigger projects, keeping
> > track of who is a mentor, and who is mentoring who, and inviting new
> > mentors, and ensuring that no-one falls through the cracks when a mentor
> > gets too busy, is a job of itself."
> > 
> > I'm looking for someone who could fill that "job".
> > 
> > Description of the job:
> > 
> > - keep track of:
> > -- who's being mentored by who, how well it's going
> > -- who needs a mentor and hasn't found one yet (this is one of the most
> > important parts: no volunteer must be forgotten, volunteers are too
> > precious !)
> > -- who can mentor more apprentices (and sometimes convince packagers to
> > become mentors or accept one more apprentice)
> > 
> > - be available for questions from apprentices or mentors, by mail, and if
> > possible, to be present on the IRC channel #mageia-mentoring on freenode
> > 
> > - help mentors with gathering "junior tasks" (bugzilla is a never empty
> > reserve that can be used for that. Maybe ask the bug triage team to help
> > identify such tasks. Maybe a "junior task" keyword in bugzilla would do
> > the trick)
> > -- small bugs to fix
> > -- new small packages to import in the distribution
> > -- backports
> > 
> > - promote mentoring (empower users into contributers. Working with the
> > marketing team would be great I think):
> > -- make the mentoring program known (MLs, forums, web, etc.)
> > -- look for new apprentices
> > -- look for new mentors
> > 
> > Some useful skills:
> > - be autonomous (ie no need to check that you're doing the work)
> > - good written english (communication is very important in this job)
> > - knowledge about packaging is a plus but not mandatory (the key aspects
> > can be taught to you)
> > - being or having been a mentor, or having been mentored would be a plus,
> > but not mandatory
> > 
> > More information about the job:
> > - does not require a big amount of work, but real committment to the task
> > and regularity
> > - remember that you have a coordination role, not an authoritative role.
> > The difference in that is that you're not here to give orders but to
> > facilitate the mentoring program.
> > - you don't have to be alone to do this job if it's too much for one
> > person: you can find other helpful people wanting to help you if needed
> > and rely on the other teams (but finding them *is* part of your job ;)
> > ).
> > -  this "job offer" concerns everything that revolves around the
> > mentoring of new packagers, but if it's successful maybe other teams can
> > follow the same approach (i18n, QA, etc... ).
> > -  depending on your level of confidence, experience and will, you could
> > be helped in your work. Maybe someone from the council can supervise and
> > help you at least at the beginning; or, if no one steps up, I can help
> > you bootstrap and organize your new "job".
> > 
> > So, who's in?
> > 
> > Samuel Verschelde
> 
> That is an excellent idea, a mentoring program coordinator.
> I've had some thoughts along those lines for some time.
> I'd be glad to contribute, especially via email and editing the wiki, where
> I could almost always respond the same day.
> But my time zone availability (generally after 22h utc) puts me at a
> disadvantage for irc communications and meetings.
> (But as part of a coordinating team, that should work well.)
> 
> Maintaining the mentor/apprentice database, as Kharec suggested, is to me a
> key part of the role. Information such as mentors available, and their
> strengths/focus, usual time zones available, communication modes
> preferred, languages spoken, and current apprentices, Would-be apprentices
> should have similar information listed.
> Not much different from the information currently in variously wiki pages,
> but maint

Re: [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

[Dick Gevers]

>so, in other words, he's saying: "don't ask me, i know nothing"

Nou dank je wel

:(

Re: [Mageia-dev] "Job offer" : mentoring program coordinator

[Samuel Verschelde]

Le lundi 13 juin 2011 11:20:30, Michael Scherer a écrit :
> Le dimanche 12 juin 2011 à 18:52 -0400, andre999 a écrit :
> > But also mentoring can apply to other things than packaging.  So maybe we
> > should give a broader scope to the mentoring coordinator job ?
> > Including bugteam, QA, as well as packaging.
> > That would make it more useful, as well as more interesting.
> > (I would be very interested in contributing to something like that.)
> 
> Given there is no mentoring program for others teams, I do not think
> adding a coordinator is gonna coordinate much.

I would say it with other words : there's no need for a broader scope right 
now, and the "job" is explicitly limited to packagers mentoring coordination, 
but if this is successful, it can maybe give ideas to other teams in the 
future. Then we will have to ask ourselves if an inter-teams mentoring 
coordinator is needed or not, but it's too soon now.

Best regards

Samuel Verschelde

Re: [Mageia-dev] [RPM] cauldron core/release libgdata-0.7.1-1.mga2

[Christiaan Welvaart]

On Wed, 8 Jun 2011, Balcaen John wrote:


Le mercredi 8 juin 2011 16:52:16, Mageia Team a écrit :

Name: libgdata Relocations: (not relocatable)
Version : 0.7.1 Vendor: Mageia.Org

[...]

dmorgan  0.7.1-1.mga2:
+ Revision: 102030
- New version 0.7.1

There's a file conflict :
Installation failed:
   file /usr/lib64/girepository-1.0/GData-0.0.typelib from install of
lib64gdata10-0.7.1-1.mga2.x86_64 conflicts with file from package
lib64gdata7-0.6.6-1.mga1.x86_64

Installation failed:file /usr/lib64/girepository-1.0/GData-0.0.typelib
from install of lib64gdata10-0.7.1-1.mga2.x86_64 conflicts with file from
package lib64gdata7-0.6.6-1.mga1.x86_64

Maybe this file should not be in the versionned library package ?


Indeed, but I see no way to really fix the upgrade except by providing a 
fixed lib(64)gdata7 in mga2.


We have poppler-gir0.16 for girepository-1.0/Poppler-0.16.typelib .
(In ubuntu they call the extra package gir1.0-gdata-0.0 .)

So we should probably add lib(64)gdata-gir0.0 . It must be libified to 
allow parallel installation of libgdata10 and lib64gdata10. The new 
package will conflict with lib(64)gdata7 so all applications that use it 
(totem and evolution) must be rebuilt.



Christiaan

Re: [Mageia-dev] "Job offer" : mentoring program coordinator

[andre999]

Michael Scherer a écrit :


Le dimanche 12 juin 2011 à 18:52 -0400, andre999 a écrit :


But also mentoring can apply to other things than packaging.  So maybe we 
should give a broader
scope to the mentoring coordinator job ?
Including bugteam, QA, as well as packaging.
That would make it more useful, as well as more interesting.
(I would be very interested in contributing to something like that.)


Given there is no mentoring program for others teams, I do not think
adding a coordinator is gonna coordinate much.


I guess I wasn't very clear :)
The idea was to (maybe) expand the role of the same mentoring coordinator to include other 
mentoring (or training) programs which might be started/made more formal.
Because it would be basically the same function, maintaining a wiki database (different for each 
program), documenting and promoting, etc.

It shouldn't be a very time-consuming function, albeit very important.
Just a random thought ...

--
André

Re: [Mageia-dev] Release cycles proposals, and discussion

[magnus]

2011/6/13 Thomas Backlund 

> Wolfgang Bornath skrev 13.6.2011 15:20:
>
>> About the cycles:
>>
>>
>> The 9-months seem to be a compromise - but I start to ask why we need
>> such a fixed statement (which it would be, once published). We need a
>> schedule for each cycle, that's true. Without a schedule we would
>> never finish anything. But how about taking 9 months only as a "nice
>> to meet" target, leaving us the option to set a roadmap after setting
>> the specs of the next release - we could then go for a 8 or 10 months
>> roadmap, depending on the specs.
>>
>>
> This is somewhat like what I had in my mind to write too, but you beat me
> to it :)
>
> It could allow us to adapt a little for upstream releases.
> But should we then decide that the limit is +/- 1 month ?
>
> Obviously there will still be people complaining that "you waited 10
> months... if you had extended with ~2 more weeks... "this" or "that"
> package would have been available too... and so on
>
>
> And something not to forget (this is more related to the specs):
>
> If an estimated upstream release of kde/gnome/... seem to fit our
> schedule it _must_ be in Cauldron before version freeze so we
> actually get some test/qa on it and not try to force it in by
> "hey it's released ~x days before final mageia release so it
>  must be added" attitude that tends to pop up at every freeze.
>
> --
> Thomas
>
>
>
> Let the 9 months as maximum, as a general target.

Make the specs and then the roadmap with a fixed release date and a fixed
enough time for freeze and testing.

If an upstream release brings conflits, that's live.
Main focus should be a stable release for simple users not a pot of the
latest apps

Magnus

Re: [Mageia-dev] Release cycles proposals, and discussion

[Thomas Backlund]

David Sjölin skrev 13.6.2011 16:00:

On Mon, Jun 13, 2011 at 2:51 PM, Thomas Backlund  wrote:

Wolfgang Bornath skrev 13.6.2011 15:20:


About the cycles:

The 9-months seem to be a compromise - but I start to ask why we need
such a fixed statement (which it would be, once published). We need a
schedule for each cycle, that's true. Without a schedule we would
never finish anything. But how about taking 9 months only as a "nice
to meet" target, leaving us the option to set a roadmap after setting
the specs of the next release - we could then go for a 8 or 10 months
roadmap, depending on the specs.



This is somewhat like what I had in my mind to write too, but you beat me to
it :)

It could allow us to adapt a little for upstream releases.
But should we then decide that the limit is +/- 1 month ?

Obviously there will still be people complaining that "you waited 10
months... if you had extended with ~2 more weeks... "this" or "that"
package would have been available too... and so on


And something not to forget (this is more related to the specs):

If an estimated upstream release of kde/gnome/... seem to fit our
schedule it _must_ be in Cauldron before version freeze so we
actually get some test/qa on it and not try to force it in by
"hey it's released ~x days before final mageia release so it
  must be added" attitude that tends to pop up at every freeze.


This point and the one above ("if you had extended...") seems to be
arguments for a fixed time release cycle? With a fixed release cycle
no one would question why we didn't wait for the release of a new
gnome/kde/, since waiting the extra
weeks would go against the release cycle. I'm not sure if that is
enough of an argument against having a looser release cycle but... But
then again, I can see the point of having the possibility to be a bit
flexible.


Well, it was intended to point out the problem with the "flexible" 
approach, and a possible "fix" by deciding some limits to the flexibility.


--
Thomas

Re: [Mageia-dev] Release cycles proposals, and discussion

[Angelo Naselli]

lunedì 13 giugno 2011 alle 12:07, Ron ha scritto:
> I made another post in a different thread about the way I feel the release 
> cycle should go. 
Sorry i can't see why... couldn't we go on that thread?

Hard to follow, quite long, but maybe easy to summarize at the end of 
discussion.
Oh well ennael and misc have to do the big work to get info from all
input, but please let's try to make their life easier :) At least that is my 
opinion...

> After more thinking I do think that I really have the right idea and here is 
> why...
And please do not post html messages or your ideas is hard to follow as well ;)

Angelo


signature.asc
Description: This is a digitally signed message part.

Re: [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

[Thomas Backlund]

James Kerr skrev 13.6.2011 16:01:

On 13/06/11 13:06, Dick Gevers wrote:

On Mon, 13 Jun 2011 09:37:40 +0200, Cazzaniga Sandro wrote about Re:
[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2:


Quite a few packages reached the mirrors since this one, but biew has
not.



So it needs a rebuild?


Anything similar to rebuild, push, boot, shove, %mkrel or opening the window
to let it fly: IANAE.



In case it's relevant - the i586 package is on the mirrors. It's only
x86-64 that's missing.


That's because spec states:

ExclusiveArch:  %ix86

--
Thomas

Re: [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

[James Kerr]

On 13/06/11 13:06, Dick Gevers wrote:

On Mon, 13 Jun 2011 09:37:40 +0200, Cazzaniga Sandro wrote about Re:
[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2:


Quite a few packages reached the mirrors since this one, but biew has
not.



So it needs a rebuild?


Anything similar to rebuild, push, boot, shove, %mkrel or opening the window
to let it fly: IANAE.



In case it's relevant - the i586 package is on the mirrors. It's only 
x86-64 that's missing.


Jim

Re: [Mageia-dev] Release cycles proposals, and discussion

[David Sjölin]

On Mon, Jun 13, 2011 at 2:51 PM, Thomas Backlund  wrote:
> Wolfgang Bornath skrev 13.6.2011 15:20:
>>
>> About the cycles:
>>
>> The 9-months seem to be a compromise - but I start to ask why we need
>> such a fixed statement (which it would be, once published). We need a
>> schedule for each cycle, that's true. Without a schedule we would
>> never finish anything. But how about taking 9 months only as a "nice
>> to meet" target, leaving us the option to set a roadmap after setting
>> the specs of the next release - we could then go for a 8 or 10 months
>> roadmap, depending on the specs.
>>
>
> This is somewhat like what I had in my mind to write too, but you beat me to
> it :)
>
> It could allow us to adapt a little for upstream releases.
> But should we then decide that the limit is +/- 1 month ?
>
> Obviously there will still be people complaining that "you waited 10
> months... if you had extended with ~2 more weeks... "this" or "that"
> package would have been available too... and so on
>
>
> And something not to forget (this is more related to the specs):
>
> If an estimated upstream release of kde/gnome/... seem to fit our
> schedule it _must_ be in Cauldron before version freeze so we
> actually get some test/qa on it and not try to force it in by
> "hey it's released ~x days before final mageia release so it
>  must be added" attitude that tends to pop up at every freeze.

This point and the one above ("if you had extended...") seems to be
arguments for a fixed time release cycle? With a fixed release cycle
no one would question why we didn't wait for the release of a new
gnome/kde/, since waiting the extra
weeks would go against the release cycle. I'm not sure if that is
enough of an argument against having a looser release cycle but... But
then again, I can see the point of having the possibility to be a bit
flexible.

Re: [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

[Dick Gevers]

On Mon, 13 Jun 2011 14:20:36 +0200, Cazzaniga Sandro wrote about Re:
[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2:

>>> So it needs a rebuild?
>> 
>> Anything similar to rebuild, push, boot, shove, %mkrel or opening the
>> window to let it fly: IANAE.

>Could you be more clear, please?

Yes: I dunno what needs to be done! Sorry, if I was not.

Best regards,
=Dick Gevers=

Re: [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

[Maarten Vanraes]

Op maandag 13 juni 2011 14:20:36 schreef Cazzaniga Sandro:
> Le 13/06/2011 14:06, Dick Gevers a écrit :
> > On Mon, 13 Jun 2011 09:37:40 +0200, Cazzaniga Sandro wrote about Re:
> > 
> > [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2:
> >>> Quite a few packages reached the mirrors since this one, but biew has
> >>> not.
> >> 
> >> So it needs a rebuild?
> > 
> > Anything similar to rebuild, push, boot, shove, %mkrel or opening the
> > window to let it fly: IANAE.
> > 
> > Thanks in advance,
> > =Dick Gevers=
> 
> Could you be more clear, please?

IANAE == i am not an expert

so, in other words, he's saying: "don't ask me, i know nothing"

Re: [Mageia-dev] Release cycles proposals, and discussion

[Samuel Verschelde]

Le dimanche 12 juin 2011 22:46:33, Michael Scherer a écrit :
> Hi,
> 
> so , with a little bit delay due to various things ( like everybody
> asking stuff to us on irc on a hourly fashion ( people will I hope
> recognize themselves )), Anne and I have reviewed the various proposals
> made through years during the early period of the distribution, and
> before at Mandriva. We took in account the feedback of people on forum,
> on ml, nd those we have seen during events. We also discussed with
> others distributions developers we know from Opensuse, Fedora, Debian,
> Ubuntu about their release cycle, the choices they made and their
> reasons.

A restitution to us of this overview of the other distros release cycles and 
their choices, reasons, pros and cons would have been great, but I guess it 
would have required much more time to write it. It would have helped 
understand why the final decision you took was to keep the current model (not 
counting the discussion about cycle duration and LTS). I'm not saying that I 
want "rolling release", but beginning the discussion without saying much 
concerning what has been a big discussion some months ago (and still is in the 
forum) feels a bit weird to me. Especially when we kept telling people "wait, 
we will have time to discuss it after Release 1".

> To simplify the discussion, the proposals are all based on the fact that
> 2 or 3 releases could be supported at a time. We could have different
> schemes for that ( LTS every X release ( ubuntu ), different level of
> support ( mandriva )), but as this is a slightly different discussion,
> let's assume 2 supported releases for now, and let's discuss later for
> that ( ie next week, once this one is finished )

I can understand the reason for separating the discussions (simplification), 
but it's hard to give a final opinion concerning the release cycle without 
knowing whether there will be a LTS or not, when you care about the life cycle 
duration. The backports policy also has a great impact to the matter : if we 
manage to make using newer versions of popular software easy without much risk 
nor obligatory need to upgrade, extending the release cycle is easier (I could 
go with 12 months provided we find a way to improve hardware support as part of 
the maintenance).

To take an example concerning the impact of having an LTS release or not : 
- 6 months release cycle + 1 LTS every few releases => ok for me (ubuntu way, 
each intermediate release is an intermediate milestone to the LTS)
- 6 months release cycle, without a LTS => not ok for me, life cycle really 
too short

That said, as a choice has to be made, my vote goes to the compromise proposal 
: around 9 months release cycle (more or less 1 month depending on the amount 
of work to be done, adjustment to a given upstream release, KDE or GNOME for 
example, and marketing calendar considerations).

Best regards

Samuel Verschelde

Re: [Mageia-dev] Release cycles proposals, and discussion

[Thomas Backlund]

Wolfgang Bornath skrev 13.6.2011 15:20:

About the cycles:

The 9-months seem to be a compromise - but I start to ask why we need
such a fixed statement (which it would be, once published). We need a
schedule for each cycle, that's true. Without a schedule we would
never finish anything. But how about taking 9 months only as a "nice
to meet" target, leaving us the option to set a roadmap after setting
the specs of the next release - we could then go for a 8 or 10 months
roadmap, depending on the specs.



This is somewhat like what I had in my mind to write too, but you beat 
me to it :)


It could allow us to adapt a little for upstream releases.
But should we then decide that the limit is +/- 1 month ?

Obviously there will still be people complaining that "you waited 10 
months... if you had extended with ~2 more weeks... "this" or "that"

package would have been available too... and so on


And something not to forget (this is more related to the specs):

If an estimated upstream release of kde/gnome/... seem to fit our
schedule it _must_ be in Cauldron before version freeze so we
actually get some test/qa on it and not try to force it in by
"hey it's released ~x days before final mageia release so it
 must be added" attitude that tends to pop up at every freeze.

--
Thomas

[Mageia-dev] perl 5.14 migration almost complete, 3 (non-cpan) modules to go - need help from their owner!

[Jerome Quelin]

hi,

perl 5.14 migration is almost complete. a big thanks to sander85,
spuhler & ahmad for their help to rebuild the binary modules! 

at the time of writing, the only packages left to rebuild are the
following:

- perl-Alias

this module is old (1999) and no more maintained upstream, so i added a
conflicts: in perl to remove it.

- perl-DBD-Firebird

this module does not compile with perl 5.14: no success reported by any
cpan testers. i've added a conflicts in perl to have a smooth transition
too. it'll be updated when a new version is available upstream.

- perl-MIME-Explode

doesn't compile with perl 5.14, bug opened upstream (rt#66966).
conflicts: added in perl, waiting for new version.

- perl-PDA-Pilot

from pilot-link package. i don't have a clue what's the problem. maybe
it doesn't support 5.14. can her maintainer chime in?

- perl-SWF

from ming package. the problem may be from specifying LIBS on
command-line, but i'm not sure. can her maintainer chime in please?

- perl-SWISH-API

from swish-e package. the problem may be from specifying OTPIMIZE,
CCFLAGS, LDFLAGS and others on command-line, but i'm not sure. can her
maintainer chime in please?


thanks,
jérôme 

Re: [Mageia-dev] weird bs behaviour

[Jerome Quelin]

On 11/06/13 15:25 +0300, Anssi Hannula wrote:
> cpio errors are normal during debug info extraction. They are most
> likely unrelated to your issue.

that's the first time i encounter (or notice) them.
however, i found the problem and fixed it.

thanks,
jérôme 

Re: [Mageia-dev] weird bs behaviour

[Anssi Hannula]

On 12.06.2011 19:13, Jerome Quelin wrote:
> hi,
> 
> when rebuilding perl-DBD-SQLite and perl -DBD-SQLite2, i get some
> strange cpio errors:
> 
> === PASTE ===
[...]
> extracting debug info from 
> /home/iurt/rpm/BUILDROOT/perl-DBD-SQLite-1.330.0-1.mga2.i386/usr/lib/perl5/vendor_perl/5.14.0/i386-linux-thread-multi/auto/DBD/SQLite/SQLite.so
> *** WARNING: No build ID note found in 
> /home/iurt/rpm/BUILDROOT/perl-DBD-SQLite-1.330.0-1.mga2.i386/usr/lib/perl5/vendor_perl/5.14.0/i386-linux-thread-multi/auto/DBD/SQLite/SQLite.so
> cpio: gcc-4.5.2/gcc/libgcc2.c: Cannot stat: No such file or directory
> cpio: gcc-4.5.2/gcc/libgcc2.h: Cannot stat: No such file or directory
> cpio: gcc-4.5.2/obj-i586-mageia-linux-gnu/gcc/include/stddef.h: Cannot stat: 
> No such file or directory
> cpio: gcc-4.5.2/obj-i586-mageia-linux-gnu/i586-mageia-linux-gnu/libgcc: 
> Cannot stat: No such file or directory
> cpio: glibc-2.12.1/bits/types.h: Cannot stat: No such file or directory
> cpio: glibc-2.12.1/debug: Cannot stat: No such file or directory
> cpio: glibc-2.12.1/debug/stack_chk_fail_local.c: Cannot stat: No such file or 
> directory
> cpio: glibc-2.12.1/io: Cannot stat: No such file or directory
> cpio: glibc-2.12.1/io/fstat64.c: Cannot stat: No such file or directory
> cpio: glibc-2.12.1/io/stat64.c: Cannot stat: No such file or directory
> cpio: glibc-2.12.1/sysdeps/unix/sysv/linux/bits/stat.h: Cannot stat: No such 
> file or directory
> cpio: glibc-2.12.1/time/time.h: Cannot stat: No such file or directory
> 9611 blocks
> === /PASTE ===
> 
> of course, tests fail afterwards.
> 
> however, building perl-DBD-SQLite module in iurt on my machine yields no
> problem. (note that my machine is a x86_64, whereas the build fails on
> i586 bs node - but i don't know if it's related).
> 
> ==> can someone more fluent with the bs / rpm can help please?

cpio errors are normal during debug info extraction. They are most
likely unrelated to your issue.

-- 
Anssi Hannula

Re: [Mageia-dev] get-skype package for submission

[Anssi Hannula]

On 12.06.2011 02:37, Barry Jackson wrote:
> On 11/06/11 18:03, Anssi Hannula wrote:
>>
>> - Best to add a comment in the %post script to remind that any new files
>>need to have a %ghost entry created.
>>(btw: an alternative idea is to create a post-script and the filelist
>> at the same time in a single for loop in %build/%install, so that
>> the lists can never get out of sync as they are created from a single
>> list; however, your current solution is adequate as well)
> 
> Note added - keep it simple.
> 

You added the note in the %files section, not in %post. The issue only
happens if someone updates %post but not %files, so it doesn't make
sense to put the reminder in %files :)

>> - You don't check for failures. If the mktemp call fails, you extract
>>the tarball into /root etc.etc.. You need to check for failures on
>>the mktemp/mkdir/cd commands (mktemp failure can be detected by
>>checking if $newtmp string is empty), or alternatively run "set -e"
>>to make the shell exit on failures (this leaves the tmpdir polluted,
>>but it doesn't matter as much as it is an uncommon failure case and
>>/tmp is cleaned periodically anyway).
> 
> Added some checks - with clean-up of previously created dirs etc on fail.

> mkdir %{mytmp}
> [[ -d %{mytmp} ]] || exit 1
> cd %{mytmp}

cd is not guaranteed to work even if %mytmp exists. Add "|| exit 1".

> cd ${tmpextdir}
> tar jxf %{mytmp}/skype-%{version}.tar.bz2

Same here...

Well, actually these two aren't that serious, since they can't be
exploited by non-root anyway. I'm somewhat ok with them, as long as your
mentor is as well and no one else objects.

Note that your "if ! [[ -d %{tmpdir} ]]; then" check is not 100%
necessary, as %tmpdir not existing is unlikely and causes no side effects.

Other nits:
- Use better variable names- %mytmp, $tmpextdir, %tmpdir are confusing.
- The description starts with an empty line. Remove it.

-- 
Anssi Hannula

Re: [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

[Cazzaniga Sandro]

Le 13/06/2011 14:06, Dick Gevers a écrit :
> On Mon, 13 Jun 2011 09:37:40 +0200, Cazzaniga Sandro wrote about Re:
> [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2:
> 
>>> Quite a few packages reached the mirrors since this one, but biew has
>>> not.
> 
>> So it needs a rebuild?
> 
> Anything similar to rebuild, push, boot, shove, %mkrel or opening the window
> to let it fly: IANAE.
> 
> Thanks in advance,
> =Dick Gevers=
Could you be more clear, please?

-- 
Sandro Cazzaniga - https://lederniercoupdarchet.wordpress.com
IRC: Kharec (irc.freenode.net)
Software/Hardware geek
Conceptor
Magnum's Coordinator/editor (http://wiki.mandriva.com/fr/Magnum)
Mageia and Mandriva contributor

Re: [Mageia-dev] Release cycles proposals, and discussion

[Wolfgang Bornath]

About the cycles:

The problems with 6-months have been pointed out - my main concern
would be the lack of manpower and the continuous state of
"pre-release", no real room to sit back and contemplate hwat is and
what could be and all the rest. IMHO such a "contemplating" time is
necessary to keep the whole picture in focus.

The problems with 12-months have also been pointed out and I agree
with them (too long out of public focus, too long for the main
userland applications, etc.).

The 9-months seem to be a compromise - but I start to ask why we need
such a fixed statement (which it would be, once published). We need a
schedule for each cycle, that's true. Without a schedule we would
never finish anything. But how about taking 9 months only as a "nice
to meet" target, leaving us the option to set a roadmap after setting
the specs of the next release - we could then go for a 8 or 10 months
roadmap, depending on the specs.

This being said, I am a friend of a rolling release like ArchLinux,
but I fear that our main target group is not up to this. Despite of
having to "burn yet another DVD" as somebody pointed out, the majority
seems to see this as normal and a good way. Of course I may be totally
wrong with this assessment!

-- 
wobo

Re: [Mageia-dev] get-skype package for submission

[Angelo Naselli]

lunedì 13 giugno 2011 alle 13:13, Oliver Burger ha scritto:
> Have you also installed rpmlint-mageia-policy?
Shouldn't it be at least suggested?

Angelo


signature.asc
Description: This is a digitally signed message part.

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le lundi 13 juin 2011 à 14:01 +0200, Oliver Burger a écrit :
> Michael Scherer  schrieb am 12.06.2011
> > Proposal 1:
> > 6 months release cycle -> 12 months life cycle
> > ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
> > 
> > Proposal 2:
> > 9 months release cycle -> 18 months life cycle
> > ( ~ opensuse and the one we used for Mageia 1 )
> > 
> > Proposal 3:
> > 12 months release cycle -> 24 months life cycle
> > ( Mandriva > 2010.1 )
> That's kind of a hard decison. I don't know if a 6 month cycle would 
> not put too much stress on the dev/packager community. But 12 months 
> are a bit much for the hordes of impatient users usually residing in 
> the forums.
> So I would - for now - prefer option 2, 9 months seeming a reasonable 
> time span.
> 
> Especially since we would always be able to change that cycle to 
> something more fitting.
> 
> As to the "rolling" and the "lts" discussion. I think it's something 
> for the future. We first have to see, how much manpower we really have, 
> to maintain the distro.
> 
> I woul then kind of like the idea of a special rolling repo like 
> debian testing or suse tumbleweed.

Well, has someone looked at what they do ?

Debian testing is not a rolling release for users, but it is a base for
the release. And bigger packages updates are slow to migrate, for
example, there is still iceweael/firefox 3.X
http://packages.debian.org/testing/web/iceweasel . So I am not sure that
it will really bring what people want ( as this is not what it was
designed for in the first place ).

Gentoo model is heavily dependent on sources recompilation on user
workstation so not applicable ( even if this is the closest of what
people could want in term of package management ).

I didn't look at the tumbleweed system, but I fear this is highly
dependent on the Suse workflow, so if someone could do the research to
explain clearly what it does for the next discussion, it would surely
help. ( this also mean that people should keep such research for next
discussion and do not mix with the current one )
-- 
Michael Scherer

Re: [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

[Dick Gevers]

On Mon, 13 Jun 2011 09:37:40 +0200, Cazzaniga Sandro wrote about Re:
[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2:

>> Quite a few packages reached the mirrors since this one, but biew has
>> not.

>So it needs a rebuild?

Anything similar to rebuild, push, boot, shove, %mkrel or opening the window
to let it fly: IANAE.

Thanks in advance,
=Dick Gevers=

[Mageia-dev] Release cycles proposals, and discussion

[Ron]

>There is a limited set of options, and as you can see, none of your >idea was 
>not already explored by someone else.
It has all been done before, in that sense let's just close up shop and call it 
a day???
>If everything move all days, you cannot :
>- translate software ( as the string will change every day )
>- create documentation ( for the same reason )
>- communicate ( as everything ca be broken at any time )
>- ensure stability ( as each change can bring unstability )

>And for user, some do not want to redo training every week for >their
>users, because libreoffice got updated, because ff 4 just arrived >and
>75% of extensions do not work, etc. 
>
>In fact, the whole release model is basically what is used all >over the
>place, from lower level like kernel to higher level like kde. So >you can
>get lots of feedback on it.
You are correct on the release model being used everywhere, that fit's 
development and really there is no other way to do it as it takes time. But 
really, up stream does have to take time but package maintainers can pull 
things in pretty fast and make things work.
I don't understand what's being said here? Are we a community of users or are 
we just teachers teaching a class? Help with changes is what forums and people 
are for. 
You worried about not being able to keep up with documentation? I suggest you 
take a look at the Arch wiki, best Linux wiki there is and 
things change fast... Again, community...
>So basically, you suggest that since everybody is already doing >it, this is 
>useless. So the logical conclusion is we should drop >the distribution ?
No that is not what I'm saying! 
What I am saying is that you have 100+/- distributions all going by a release 
model and only a handful making rolling releases. There is only one defacto 
maker of a rolling release and that is Arch, why does this have to be? (Yes I 
know there are others but Arch is the leader of the pack)
>We have the same thing, this is the strength of free software. We
>basically all work together.
It truly is redundant to do what everyone else is doing just because
>like cauldron ? or debian unstable, fedora rawhide, opensuse >factory,mandriva 
>cooker ?
Sure, there has to be an unstable branch whether rolling or not...
>like debian testing ( and CUT ) ? suse tumbleweed ? arch linux
Nope, gotta call you on this... Debian testing rolls with the purpose of 
becoming a release... Therefore things can grow outdated rather quickly. 
Suse tumblweed IS NOT going to be a true rolling release! It is going to 
"tumble up" to the next release hence the name.
This cannot be compared to Arch either as Arch has a set of rules as well and 
rolls into stable...
>Very stable for a distribution mean "that do not change". That's
>incompatible with the idea of rolling per definition. And inorder >to have 
>stable software, you have to freeze them and fix bugs. So >to have that on the 
>whole distribution, you need to freeze the >whole distribution for a time, and 
>then ask for test, fix bugs >and then release. Which is exactly what we 
>currently do since >years.
Sorry, your wrong! I have been using Arch for years and have yet to meet a show 
stopper bug, it is very stable. 
Stability simply means tested! It does not have to be like Debian testing that 
grows stale with time, you can remain very very close to bleeding edge and 
still remain stable...
>So basically, you just reinvented the concept of release, and the 
>>way Mandriva, Debian, Fedora work since years. 
And I must have peed in your cheerios... I am all for giving people what they 
want, I also don't think you have to follow the status quo to do so... We don't 
have to be "just another distribution doing the same things the others are 
doing"... Sorry, but this is what I see

Re: [Mageia-dev] Release cycles proposals, and discussion

[Oliver Burger]

Michael Scherer  schrieb am 12.06.2011
> Proposal 1:
> 6 months release cycle -> 12 months life cycle
> ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
> 
> Proposal 2:
> 9 months release cycle -> 18 months life cycle
> ( ~ opensuse and the one we used for Mageia 1 )
> 
> Proposal 3:
> 12 months release cycle -> 24 months life cycle
> ( Mandriva > 2010.1 )
That's kind of a hard decison. I don't know if a 6 month cycle would 
not put too much stress on the dev/packager community. But 12 months 
are a bit much for the hordes of impatient users usually residing in 
the forums.
So I would - for now - prefer option 2, 9 months seeming a reasonable 
time span.

Especially since we would always be able to change that cycle to 
something more fitting.

As to the "rolling" and the "lts" discussion. I think it's something 
for the future. We first have to see, how much manpower we really have, 
to maintain the distro.

I woul then kind of like the idea of a special rolling repo like 
debian testing or suse tumbleweed.

Oliver

Re: [Mageia-dev] Release cycles proposals, and discussion

[David Sjölin]

On Mon, Jun 13, 2011 at 1:01 PM, Thorsten van Lil  wrote:
> Am Sonntag, 12. Juni 2011, 22:46:33 schrieb Michael Scherer:
>> Proposal 1:
>> 6 months release cycle -> 12 months life cycle
>> ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
>>
>> Proposal 2:
>> 9 months release cycle -> 18 months life cycle
>> ( ~ opensuse and the one we used for Mageia 1 )
>>
>> Proposal 3:
>> 12 months release cycle -> 24 months life cycle
>> ( Mandriva > 2010.1 )

Hello!

I'm for proposal 2 as well. I usually use LTS of Ubuntu at work, and
at home just keep the distribution for a long time, so I would like
far between, but I know a lot of colleagues who always install the
latest so the middle ground of 9 months seems good to me.

Regards,

David

Re: [Mageia-dev] Release cycles proposals, and discussion

[Maarten Vanraes]

Op maandag 13 juni 2011 13:36:07 schreef Michael Scherer:
[...]
> Another solution is to  have a longer freeze period, so people focus
> less on last minutes changes and packages upgrades, and more on bug
> fixing.

i would be in favor of that.

Re: [Mageia-dev] Question about backports: calibre (bug 1659)

[James Kerr]

On 13/06/11 10:51, Radu-Cristian FOTESCU wrote:



Therefore, I strongly believe that all calibre updates be packaged
into updates, not backports, especially as there isn't any Mageia 2.0
as of yet.



The reference to backporting means backporting from Cauldron.

Jim

Re: [Mageia-dev] Release cycles proposals, and discussion

[Michael Scherer]

Le lundi 13 juin 2011 à 01:06 +0300, Sander Lepik a écrit :
> 12.06.2011 23:46, Michael Scherer kirjutas:
> > Proposal 1:
> > 6 months release cycle ->  12 months life cycle
> > ( Fedora, Ubuntu, Mandriva<  2010.1&&  Mandriva != 2006.0 )
> >
> > Proposal 2:
> > 9 months release cycle ->  18 months life cycle
> > ( ~ opensuse and the one we used for Mageia 1 )
> >
> > Proposal 3:
> > 12 months release cycle ->  24 months life cycle
> > ( Mandriva>  2010.1 )
>  From those options i would go with the second one. Third is way too much 
> wanted from users 
> (and first has too short life cycle). They are always eager for new stuff and 
> waiting one 
> year ain't option for them. We could also try to have some LTS versions. But 
> in a bit 
> different manner than Ubuntu. Like if we notice that some release is good and 
> stable we 
> could extend its support period (ie mdv2008.1 was really stabel and also 
> mdv2010.1 was 
> pretty good - for me neither had too many problems and i would have keeped 
> 2008.1 for longer 
> but its support ended).

The LTS discussion is for next week :)

> One more thing i didn't like with Mageia 1. Official launch date that you 
> know is coming and 
> you see that not all things are ready for prime time but you go anyway as 
> there is launch 
> date announced. Ubuntu has failed with that at least few times.
> Debian (Mozilla somewhat too) does better job here. They don't release if 
> they see critical 
> problems and they don't announce release too far away.
> In that hurry we probably missed ATI graphics problem and could have solved 
> it better.

Another solution is to  have a longer freeze period, so people focus
less on last minutes changes and packages upgrades, and more on bug
fixing.

And we also do not release if there is critical problem, the question is
more "what is critical". It must also be take in account that we didn't
finish the setup of infrastructure, so we will have likely more time and
less burden next time. 


> Maybe we should try to have 9 months but if it will be 10 with more stable 
> release i would 
> go with 10 (or mabye final freeze in 8 months and then we'll see how fast we 
> can make it 
> stable).
> 
> (And we have to keep up the good job with upgrading smoothness - in the 
> future it must be 
> tested even more, that way users who want longer cycle will complain less if 
> they can 
> upgrade their system w/o big problems.)

For that, I guess we could do automated upgrade testing, something
like : 
 - we setup a vm ( scriptable + tftp + pxe )
 - we install as much as possible ( auto installation )
 - we do a scripted upgrade ( auto installation + at / cron )
 - we check if it reboot fine ( a init script + a timeout somewhere ? )

this will not solve everything, but this would be a good start. The main
problem is to decide if the upgrade went well or not for all possible
case.

-- 
Michael Scherer

Re: [Mageia-dev] Cross compile x86_64 on i586 for icecream?

[Christiaan Welvaart]

On Mon, 13 Jun 2011, Colin Guthrie wrote:


I'm not exactly a guru with icecream but is it possible to build a
toolchain that can allow i586 nodes to compile x86_64 code?


If your question is about the toolchain, have you tried simply passing 
-m64 to gcc?



Christiaan

Re: [Mageia-dev] get-skype package for submission

[Barry Jackson]

On 13/06/11 12:13, Oliver Burger wrote:

Barry Jackson  schrieb am 13.06.2011

 > On 13/06/11 09:17, Angelo Naselli wrote:

 > > IIRC rpmlint should tell you as a warning.

 >

 > Thanks Angelo,

 > I never used rpmlint before, so I installed it.

 > It did not warn about the dot, but it did pick up a few spaces/tabs

 > etc. There is a warning about Group: Networking/Instant messaging

 > being non-standard, however this is used by the pidgin package.

Have you also installed rpmlint-mageia-policy?

Otherwise rpmlint will give you quite some warnings about Mageia
specific things.


Oliver



Thanks Oliver

No, I did not know about that, I was wondering where rpmlint got it's 
references from.


That fixed it ;)

Barry

Re: [Mageia-dev] Release cycles proposals, and discussion

[Radu-Cristian FOTESCU]

> Unstable branch - absolute latest software here...
> Rolling unstable - Still risky but not on the lines of unstable
> Rolling stable - everyday use and very stable 

May I add my bit of unrequested thoughts?

This discussion seems to only differentiate between "degrees of unstability and 
risks", but nothing about "user roles". 
IMHO, a distro is not only about "risk vs. features", but also about what 
people are expecting from it.

I could imagine for user roles:

"rolling-user" branch: 
-- KDE4, GNOME3, XFCE, LibreOffice, Firefox/Thunderbird, Chromium are always 
kept to the latest _stable_ (not development) version;
-- other applications might be kept (or not) to the latest _stable_ (not 
development) version; 
-- other libraries are to be upgraded _only_ if they're required by newer 
applications.

"rolling-user-risky" branch: 
-- KDE4, GNOME3, XFCE, LibreOffice, Firefox/Thunderbird, Chromium are always 
kept to the latest _development_/_unstable_ version;
-- other applications might be kept to the latest _development_/_unstable_ 
version, otherwise most are kept to the latest _stable_ version; 
-- other libraries are to be upgraded _only_ as they're required by newer 
applications.

"rolling-developer" branch: 
-- everything updated to the latest _development_/_unstable_ versions of 
everything.

Does this make any sense?

Best regards,
R-C (aka Beranger with an e acute)

Re: [Mageia-dev] get-skype package for submission

[Oliver Burger]

Barry Jackson  schrieb am 13.06.2011
> On 13/06/11 09:17, Angelo Naselli wrote:
> > IIRC rpmlint should tell you as a warning.
> 
> Thanks Angelo,
> I never used rpmlint before, so I installed it.
> It did not warn about the dot, but it did pick up a few spaces/tabs
> etc. There is a warning about Group: Networking/Instant messaging
> being non-standard, however this is used by the pidgin package.
Have you also installed rpmlint-mageia-policy?
Otherwise rpmlint will give you quite some warnings about Mageia 
specific things.

Oliver