[Mageia-dev] Heads Up
-Forwarded Message- >From: Jeff Johnson >Sent: Feb 22, 2011 8:14 PM >To: coo...@mandrivalinux.org >Subject: [Cooker] Upgrding db-5.1.19 -> db-5.1.26 needs full rebuilds > >(cool! a bug related to RPM might have been found _BEFORE_ it ended up in >cooker-devel e-mail ;-) > >I got a bug report from bero at Arklinux with these symptoms: > >Preparing...### [100%] >rpmdb: not a restored transaction >rpmdb: PANIC: Invalid argument >==> rpmdbe_event_notify(0x9833aa8, PANIC(0), 0xbfe2b5d4) app_private (nil) >rpmdb: PANIC: fatal region error detected; run recovery >==> rpmdbe_event_notify(0x9833aa8, PANIC(0), 0xbfe2b6cc) app_private (nil) > 1:xorg ### [ 20%] >rpmdb: PANIC: fatal region error detected; run recovery >==> rpmdbe_event_notify(0x9833aa8, PANIC(0), 0xbfe2b5bc) app_private (nil) > >I've never ever seen that 1st Berkeley DB error before. > >A quick check with Google found this report: >http://forums.oracle.com/forums/thread.jspa?threadID=2175221&tstart=0 >and I just confirmed with jcea that upgrading to db-5.1.26 without rebuilding >everything that uses/needs > #include >will lead to "not a restored transaction". > >Presumably some #define got changed, breaking (for the 1st time ever afaik) >the typical expectation that 5.1.19 -> 5.1.26 is just bug fix patches. > >Disclaimer: >This is still just 2nd hand info because I haven't personally looked. > >So -- if you go to db-5.1.26 -- plan on rebuilding RPM and whatever >else is linking -ldb-5.1. > >There's nothing critically important in db-5.1.26 (or I would remember). > >It would be nice to get on the other side of this minor "speed bump" >in Berkeley DB by 2011.0 release. But db-5.1.19 is known "gud enuf" by now. > >hth > >73 de Jeff > smime.p7s Description: S/MIME cryptographic signature
Re: [Mageia-dev] automagically submitting correctly
Op woensdag 23 februari 2011 00:07:59 schreef Thomas Backlund: > On 23.2.2011 00:54, Maarten Vanraes wrote: > > I've been thinking on submission (since i'm a novice packager, i have no > > good experience with this, so i ended up talking to my mentor on > > submission stuff). > > > > So i was thinking: > > .spec files are used to tell the buildbot how to build and package an > > srpm. > > > > why don't we have a similar way to do submission? (or even include this > > in spec file?) > > > > the things is, i want something that should work in most, if not all > > cases, but still be simple. > > > > what would be interesting: > > * submission parameters: ie: where to put rpm (core, tainted, non-free) > > Not really needed, as it's only the first time you submit a package you > need to specify repo, after that the bs knows where to put it... ah, that is interesting to know > > or nice to have: > > * make this also work multiple times, for packages that are submitted > > > > multiple times (think about tainted stuff, that is rebuilt with extra > > %define), and still have only one srpm. > > this could be set by default in a separate rebuild bot for tainted repos yes, but i was proposing to change the buildbot to allow such a package to be built 4 times instead of 2, and not having srpm conflicts and so that a single submission builds both at the same time. > > * bootstrapping options? some way to have %defines that disable some > > stuff for > > > > bootstrapping (or even cyclic builddependencies in certain pacakages) > > > > in short, the idea is to have: > > 1. X, that is simple, elegant and works for all cases > > 2. stuff happens > > 3. profit :-P > > > > or to make it easier on packagers (and possibly reduce errors in wrong > > submission), so that just "mgarepo submit" would automagically > > work correctly. > > That only work if the packager sets the tags correctly... that is true, but if it's put into like the .spec file, it's kind of "there". and in revision control. this looked usefull to me, but i can be wrong...
Re: [Mageia-dev] automagically submitting correctly
On 23.2.2011 00:54, Maarten Vanraes wrote: I've been thinking on submission (since i'm a novice packager, i have no good experience with this, so i ended up talking to my mentor on submission stuff). So i was thinking: .spec files are used to tell the buildbot how to build and package an srpm. why don't we have a similar way to do submission? (or even include this in spec file?) the things is, i want something that should work in most, if not all cases, but still be simple. what would be interesting: * submission parameters: ie: where to put rpm (core, tainted, non-free) Not really needed, as it's only the first time you submit a package you need to specify repo, after that the bs knows where to put it... or nice to have: * make this also work multiple times, for packages that are submitted multiple times (think about tainted stuff, that is rebuilt with extra %define), and still have only one srpm. this could be set by default in a separate rebuild bot for tainted repos * bootstrapping options? some way to have %defines that disable some stuff for bootstrapping (or even cyclic builddependencies in certain pacakages) in short, the idea is to have: 1. X, that is simple, elegant and works for all cases 2. stuff happens 3. profit :-P or to make it easier on packagers (and possibly reduce errors in wrong submission), so that just "mgarepo submit" would automagically work correctly. That only work if the packager sets the tags correctly... -- Thomas
Re: [Mageia-dev] We must port Mageia to ARM and PowerPC!
Op dinsdag 22 februari 2011 23:53:01 schreef André Machado: > I was watching now and I realized that both mageia and Mandriva have ports > for both i586 and x64 architetures. > > When Mageia is released, she will compete directly with Mandriva, even > though this is not your intention, Many Mandriva users will not want to > migrate to Mageia and here is the clever. > > Nowadays, they are increasingly common netbooks and tablets with ARM > processors. In addition, there are still people with PowerPC Macs or > PlayStations, which also use this processor. > > If we port Mageia for these architectures, we can grab a larger share of > users, including fans of Mandriva, which could run a distro similar to > that love on machines that do not support it. > > Of course, this is not a trivial task and maybe cannot be done right now > but think in the short term, this should be viable and will help spread > the distro. It should not be difficult to find someone who has a computer > with these features and want to build the distro. Of course, Mageia > Foundation is busy with Alpha1 and a port would require more tests. Maybe > for next year? I ask what are the difficulties in doing this? > > Of course we don't need have a large range of architetures such like Debian > or NetBSD, but these - ARM and PowerPC - are essentials. iinm rtp (forgot real name, sorry) plans on doing ARM.
[Mageia-dev] automagically submitting correctly
I've been thinking on submission (since i'm a novice packager, i have no good experience with this, so i ended up talking to my mentor on submission stuff). So i was thinking: .spec files are used to tell the buildbot how to build and package an srpm. why don't we have a similar way to do submission? (or even include this in spec file?) the things is, i want something that should work in most, if not all cases, but still be simple. what would be interesting: * submission parameters: ie: where to put rpm (core, tainted, non-free) or nice to have: * make this also work multiple times, for packages that are submitted multiple times (think about tainted stuff, that is rebuilt with extra %define), and still have only one srpm. * bootstrapping options? some way to have %defines that disable some stuff for bootstrapping (or even cyclic builddependencies in certain pacakages) in short, the idea is to have: 1. X, that is simple, elegant and works for all cases 2. stuff happens 3. profit :-P or to make it easier on packagers (and possibly reduce errors in wrong submission), so that just "mgarepo submit " would automagically work correctly. i think this idea would be usefull if it was not too complex, unfortunately i have no solid concrete ideas about this. but perhaps someone else has any good suggestions about this?
[Mageia-dev] We must port Mageia to ARM and PowerPC!
I was watching now and I realized that both mageia and Mandriva have ports for both i586 and x64 architetures. When Mageia is released, she will compete directly with Mandriva, even though this is not your intention, Many Mandriva users will not want to migrate to Mageia and here is the clever. Nowadays, they are increasingly common netbooks and tablets with ARM processors. In addition, there are still people with PowerPC Macs or PlayStations, which also use this processor. If we port Mageia for these architectures, we can grab a larger share of users, including fans of Mandriva, which could run a distro similar to that love on machines that do not support it. Of course, this is not a trivial task and maybe cannot be done right now but think in the short term, this should be viable and will help spread the distro. It should not be difficult to find someone who has a computer with these features and want to build the distro. Of course, Mageia Foundation is busy with Alpha1 and a port would require more tests. Maybe for next year? I ask what are the difficulties in doing this? Of course we don't need have a large range of architetures such like Debian or NetBSD, but these - ARM and PowerPC - are essentials.
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
Op dinsdag 22 februari 2011 19:09:17 schreef andre999:
[...]
>
> First of all, "tainted" in English implies that the software doesn't
> work. (Unless it refers to food, in which case it means "poisonous".)
> So we should choose a more appropriate name, such as "constrained", or
> use the Ubuntu approach and use a name which doesn't literally describe
> the contents. ("Multiverse", in their case.)
> Anything but something that implies that there is something inherently
> wrong with the package in question.
> That was one advantage of "plf", but of course that is already taken.
> And it is certainly advantageous to include such packages directly on
> Mageia mirrors.
>
[...]
This reply is not meant for andre, but for people responding to his email:
I clearly didn't respond to this, because this is aside, and in general the
preference of one user, we already had a big discussion about this, so please
let's not restart this one.
and besides the aside, naming is unimportant in my view.
Re: [Mageia-dev] freedesktop spec and categories
> The menu layouts are defined in desktop-common-data. Other mandriva-education-other.directory X-MandrivaLinux-MoreApplications-Education- Other Art Construction Teaching Education Music So iuc Art is mapped as Other... -- Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
On 22 February 2011 20:09, andre999 wrote:
>
>
> First of all, "tainted" in English implies that the software doesn't work.
> (Unless it refers to food, in which case it means "poisonous".)
> So we should choose a more appropriate name, such as "constrained", or use
> the Ubuntu approach and use a name which doesn't literally describe the
> contents. ("Multiverse", in their case.)
> Anything but something that implies that there is something inherently wrong
> with the package in question.
> That was one advantage of "plf", but of course that is already taken. And it
> is certainly advantageous to include such packages directly on Mageia
> mirrors.
>
>
> A Cleaner approach -- albeit more work -- would be for the "constrained"
> package to be an external module which adds the missing functionality. For
> less modular packages, this would be replacing (only) the files which
> provide the questioned functionality.
> For a typical a music player-type application, this would be only a be a few
> relatively small files.
>
> So a user that wants to add the "contrained" functionality would simply add
> an extra package, which obviously would have a different name based on the
> main package.
> (It would be useful to suggest adding such packages during installation, if
> the "contrained" repositories are selected.)
> (That is, if such a related package is available in selected repos.)
>
> Think of the gstreamer packages -- the "ugly" perhaps corresponding to the
> "constrained" packages being considered.
>
> my 2 cents :)
> --
> André
>
Just a small note, if you didn't like the colour of the bike shed you
should have discussed the point before it was built, painted, the
paint has dried and is about to have new residents.
And if you discussed the issue and your POV wasn't adapted, what's the
point re-emerging it now given that changing the new isn't easy now
that the infra- is already in place.
I like the name tainted, (note that the kernel does use the word
tainted to indicate there's a non-open source binary blob/driver e.g.
with the nvidia proprietary driver, so this usage is not unheard of).
:)
--
Ahmad Samir
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
On Tuesday, 22 February 2011 20:09:17 andre999 wrote:
> Maarten Vanraes a écrit :
> > Op vrijdag 18 februari 2011 14:42:02 schreef Michael Scherer:
> >> Le vendredi 18 février 2011 à 12:47 +, James Kerr a écrit :
> >>> If there are two packages, one in core and another in tainted, then
> >>> doesn't urpmi need a way to recognise that the tainted package is newer
> >>> than (an update to) the corresponding core package? I believe that this
> >>> is achieved in Mandriva, because plf is greater than mdv.
> >>
> >> That's abusing release tag and it work by pure chance ( ie, had the plf
> >> decided to be called the guillomovitch liberation front, it would not
> >> have worked ). And this is quite inflexible, since people will always
> >> have plf packages, leading to users adding some rpm in skip.list with a
> >> regexp.
> >>
> >> This doesn't make much sense to treat tainted rpm as update to core,
> >> this is not the same notion. But we cannot express this in urpmi for the
> >> moment, as this would requires some way to say "if you need to install
> >> something, prefer this source rather than this one".
> >>
> >> We can imagine a priority system, or we can simply say that if there is
> >> the same rpm on 2 media, we ask to the user ( except this would requires
> >> IMHO a better system than the current path based one to see what is in a
> >> rpm, but that's a rather long proposal to make ).
> >>
> >> But you are right this another set of issues to solve for dual life
> >> packages.
> >
> > after sleeping on this, i've had this idea:
> >
> > why don't we rename packages in tainted?
> > keeping them in the same name, perhaps has issues with search engines,
> > (ie: which version do you get?)
> >
> > i proposed renaming packages in tainted,(but not the release tag).
> >
> > would it be a good compromise if we named packages:
> >
> > -tainted-- ?
> >
> > the benefit of this could be adding an Obsoletes and Provides on the
> > original package with the identical version.
> >
> > for building, i may have this solution:
> >
> > %tainted(%_optional_feature1 %optional_feature2 %optional_feature3)
> >
> > this would allow the buildbot to look for %tainted and if it does, it
> > could rebuild it for tainted and add the particulars itself. this would
> > simplify the whole plf/tainted thing easily. and since all 4 rpms are
> > being built at the same time, you have no srpm problem either.
> >
> > WDYT?
>
>
> First of all, "tainted" in English implies that the software doesn't
> work.
I have never seen that interpretation. Tainted is a synonym for contaminated.
Contaminated doesn't mean that it doesn't work, it means that you should
exercise caution in using it (e.g. you may not want to drink it, but you can
use it to wash your car).
http://www.encyclopedia.com/doc/1O999-taint.html
> (Unless it refers to food, in which case it means "poisonous".)
> So we should choose a more appropriate name, such as "constrained", or
> use the Ubuntu approach and use a name which doesn't literally describe
> the contents. ("Multiverse", in their case.)
> Anything but something that implies that there is something inherently
> wrong with the package in question.
There is something wrong with the package, it is contaminated by software
patents.
Regards,
Buchan
Re: [Mageia-dev] freedesktop spec and categories
On 22.02.2011 14:34, Angelo Naselli wrote: > hi, > porting tuxpaint i've finally found the time to > fix and old menu issue for that application. > > Some low level school teachers i know, complain > about tuxpaint position -Education/Other menu- > that is not very intuitive. > > Packaging it again for mageia, I've relaized that there's > Other nowhere into source tarball and spec file. So i start looking > at desktop file and found that its categories are Education;Art. > > Looking at freedesktop specs[1] i've read Art is related > to Education so tuxpaint desktop file is right. > Removing Art -as i did at the moment using desktop-file-install-, > tuxpaint is correctly installed into Education menu, so i wonder if > it is a missing specification implementation for that either in > Mandriva or in Mageia. The menu layouts are defined in desktop-common-data. > Said that i believe, anyway, that tuxpaint, and tuxpaint-config as well, > should stay into Education menu as released into cauldron at this moment. > > Cheers, > Angelo > > P.S. misc i've sent upstream the tuxpaint & co. patches i imported... > > [1]http://standards.freedesktop.org/menu-spec/latest/apa.html -- Anssi Hannula
Re: [Mageia-dev] Test upgrade of server, second try
On Tuesday, 22 February 2011 18:54:06 Michael Scherer wrote: > And for the missing rpms that are important : Maybe it is time to try and assign maintainers? > tcpdump For the following, I don't currently have a mageia installation to package on. I *may* be able to try and solve this this week (involves a number of ssh tunnels ...), otherwise about March 15 is the first time I will have real bandwidth. > nss_ldap > pam_ldap > ldapvi Regards, Buchan
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
Op dinsdag 22 februari 2011 19:09:17 schreef andre999:
> Maarten Vanraes a écrit :
> > Op vrijdag 18 februari 2011 14:42:02 schreef Michael Scherer:
> >> Le vendredi 18 février 2011 à 12:47 +, James Kerr a écrit :
> >>> If there are two packages, one in core and another in tainted, then
> >>> doesn't urpmi need a way to recognise that the tainted package is newer
> >>> than (an update to) the corresponding core package? I believe that this
> >>> is achieved in Mandriva, because plf is greater than mdv.
> >>
> >> That's abusing release tag and it work by pure chance ( ie, had the plf
> >> decided to be called the guillomovitch liberation front, it would not
> >> have worked ). And this is quite inflexible, since people will always
> >> have plf packages, leading to users adding some rpm in skip.list with a
> >> regexp.
> >>
> >> This doesn't make much sense to treat tainted rpm as update to core,
> >> this is not the same notion. But we cannot express this in urpmi for the
> >> moment, as this would requires some way to say "if you need to install
> >> something, prefer this source rather than this one".
> >>
> >> We can imagine a priority system, or we can simply say that if there is
> >> the same rpm on 2 media, we ask to the user ( except this would requires
> >> IMHO a better system than the current path based one to see what is in a
> >> rpm, but that's a rather long proposal to make ).
> >>
> >> But you are right this another set of issues to solve for dual life
> >> packages.
> >
> > after sleeping on this, i've had this idea:
> >
> > why don't we rename packages in tainted?
> > keeping them in the same name, perhaps has issues with search engines,
> > (ie: which version do you get?)
> >
> > i proposed renaming packages in tainted,(but not the release tag).
> >
> > would it be a good compromise if we named packages:
> >
> > -tainted-- ?
> >
> > the benefit of this could be adding an Obsoletes and Provides on the
> > original package with the identical version.
> >
> > for building, i may have this solution:
> >
> > %tainted(%_optional_feature1 %optional_feature2 %optional_feature3)
> >
> > this would allow the buildbot to look for %tainted and if it does, it
> > could rebuild it for tainted and add the particulars itself. this would
> > simplify the whole plf/tainted thing easily. and since all 4 rpms are
> > being built at the same time, you have no srpm problem either.
> >
> > WDYT?
>
>
> First of all, "tainted" in English implies that the software doesn't
> work. (Unless it refers to food, in which case it means "poisonous".)
> So we should choose a more appropriate name, such as "constrained", or
> use the Ubuntu approach and use a name which doesn't literally describe
> the contents. ("Multiverse", in their case.)
> Anything but something that implies that there is something inherently
> wrong with the package in question.
> That was one advantage of "plf", but of course that is already taken.
> And it is certainly advantageous to include such packages directly on
> Mageia mirrors.
>
>
> A Cleaner approach -- albeit more work -- would be for the "constrained"
> package to be an external module which adds the missing functionality.
> For less modular packages, this would be replacing (only) the files
> which provide the questioned functionality.
> For a typical a music player-type application, this would be only a be a
> few relatively small files.
>
> So a user that wants to add the "contrained" functionality would simply
> add an extra package, which obviously would have a different name based
> on the main package.
> (It would be useful to suggest adding such packages during installation,
> if the "contrained" repositories are selected.)
> (That is, if such a related package is available in selected repos.)
>
> Think of the gstreamer packages -- the "ugly" perhaps corresponding to
> the "constrained" packages being considered.
>
> my 2 cents :)
sure, but that doesn't always work, not all software is done like this
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
Maarten Vanraes a écrit :
Op vrijdag 18 februari 2011 14:42:02 schreef Michael Scherer:
Le vendredi 18 février 2011 à 12:47 +, James Kerr a écrit :
If there are two packages, one in core and another in tainted, then
doesn't urpmi need a way to recognise that the tainted package is newer
than (an update to) the corresponding core package? I believe that this
is achieved in Mandriva, because plf is greater than mdv.
That's abusing release tag and it work by pure chance ( ie, had the plf
decided to be called the guillomovitch liberation front, it would not
have worked ). And this is quite inflexible, since people will always
have plf packages, leading to users adding some rpm in skip.list with a
regexp.
This doesn't make much sense to treat tainted rpm as update to core,
this is not the same notion. But we cannot express this in urpmi for the
moment, as this would requires some way to say "if you need to install
something, prefer this source rather than this one".
We can imagine a priority system, or we can simply say that if there is
the same rpm on 2 media, we ask to the user ( except this would requires
IMHO a better system than the current path based one to see what is in a
rpm, but that's a rather long proposal to make ).
But you are right this another set of issues to solve for dual life
packages.
after sleeping on this, i've had this idea:
why don't we rename packages in tainted?
keeping them in the same name, perhaps has issues with search engines, (ie:
which version do you get?)
i proposed renaming packages in tainted,(but not the release tag).
would it be a good compromise if we named packages:
-tainted-- ?
the benefit of this could be adding an Obsoletes and Provides on the original
package with the identical version.
for building, i may have this solution:
%tainted(%_optional_feature1 %optional_feature2 %optional_feature3)
this would allow the buildbot to look for %tainted and if it does, it could
rebuild it for tainted and add the particulars itself. this would simplify the
whole plf/tainted thing easily. and since all 4 rpms are being built at the
same time, you have no srpm problem either.
WDYT?
First of all, "tainted" in English implies that the software doesn't
work. (Unless it refers to food, in which case it means "poisonous".)
So we should choose a more appropriate name, such as "constrained", or
use the Ubuntu approach and use a name which doesn't literally describe
the contents. ("Multiverse", in their case.)
Anything but something that implies that there is something inherently
wrong with the package in question.
That was one advantage of "plf", but of course that is already taken.
And it is certainly advantageous to include such packages directly on
Mageia mirrors.
A Cleaner approach -- albeit more work -- would be for the "constrained"
package to be an external module which adds the missing functionality.
For less modular packages, this would be replacing (only) the files
which provide the questioned functionality.
For a typical a music player-type application, this would be only a be a
few relatively small files.
So a user that wants to add the "contrained" functionality would simply
add an extra package, which obviously would have a different name based
on the main package.
(It would be useful to suggest adding such packages during installation,
if the "contrained" repositories are selected.)
(That is, if such a related package is available in selected repos.)
Think of the gstreamer packages -- the "ugly" perhaps corresponding to
the "constrained" packages being considered.
my 2 cents :)
--
André
Re: [Mageia-dev] 1st test upgrade of our servers ( using vm )
Thierry Vignaud a écrit : On 17 February 2011 18:04, Thomas Backlund wrote: here is the list of package that were not upgraded : # rpm -qa | grep -v mga | sort kernel-desktop-2.6.33.7-2mnb-1-1mnb2 This is normal, as we dont remove kernels automatically... but urpme --auto-orphan should. Maybe is it time we offer to remove orphan packages at end of upgrade in drakx too. It would be the better if the auto-orphan option gave 2 options for each package 1) don't remove 2) don't ask again (when the user is sure) since often it guesses wrong. The current fix for false positives is awkward (doing an install in urpmi when the package is already installed) -- the right place to fix it is in the auto-orphan process. -- André
[Mageia-dev] Test upgrade of server, second try
Hi, so after trying to upgrade the web server, i decided to give a go for the svn server. This went quite smoothly, and the missing list is quite small : Error message on update : The following packages have to be removed for others to be upgraded: mandriva-release-Free-2010.2-0.10.1mdv2010.2.i586 (due to missing mandriva-release-common(lib)) repsys-1.9-2mdv2010.1.noarch (due to unsatisfied python < 2.7) task-bs-cluster-main-2010.1-4mdv2010.1.noarch (due to missing repsys) (y/N) The following packages have to be removed for others to be upgraded: mkcd-4.3.0-6mdv2010.1.noarch (due to conflicts with perl-Mkcd-Commandline-1.1.0-1.mga1.noarch) rails-2.3.4-1mdv2010.0.noarch (due to unsatisfied ruby-activesupport == 2.3.4) (y/N) Something that would cause trouble on upgrade : # LC_ALL=C urpmi sudo A requested package cannot be installed: sudo-1.7.4-2.p4.2.mga1.i586 (in order to keep sudo-1.7.4p6-0.1mdv2010.2.i586) Continue installation anyway? (Y/n) And for the missing rpms that are important : tcpdump nss_ldap pam_ldap ldapvi ltrace + various php-modules rng-utils mdv-youri-core mdv-youri-submit Note that I didn't tried to run anything yet ( and do not plan for now ). So next time, I will take a build host and do a test upgrade :) -- Michael Scherer
[Mageia-dev] freedesktop spec and categories
hi, porting tuxpaint i've finally found the time to fix and old menu issue for that application. Some low level school teachers i know, complain about tuxpaint position -Education/Other menu- that is not very intuitive. Packaging it again for mageia, I've relaized that there's Other nowhere into source tarball and spec file. So i start looking at desktop file and found that its categories are Education;Art. Looking at freedesktop specs[1] i've read Art is related to Education so tuxpaint desktop file is right. Removing Art -as i did at the moment using desktop-file-install-, tuxpaint is correctly installed into Education menu, so i wonder if it is a missing specification implementation for that either in Mandriva or in Mageia. Said that i believe, anyway, that tuxpaint, and tuxpaint-config as well, should stay into Education menu as released into cauldron at this moment. Cheers, Angelo P.S. misc i've sent upstream the tuxpaint & co. patches i imported... [1]http://standards.freedesktop.org/menu-spec/latest/apa.html signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
Quote: rdalverny wrote on Tue, 22 February 2011 11:04 > >> Long time ago, > > How long is a "long time ago"? because every patent has a term and > here it may have expired. > Long time ago means 1999.. Actually the problem has not expired : Bruno Postle the main dev of hugin and panotools projects uses fedora and builds the rpm for Fedora (and proposes on his own repo rpms of the betas and release candidates ... ) He is certainly the guy that must be aware of the patent problems : he still proposes a limited version of panotools on official Fedora's repositories !!! The source are written to be built with or without fov limitation depending of the possible patent infringement (no limit in Europe...) > List of questions to check would be at least: > - what is exactly covered by what patent (reference, registration, > territory/ies for which it has been registered)? > - where is it implemented exactly in the source code? ( > - who owns this patent? > - did the patent holder announce his clear intention upon it? (that > is, is he using it to control/restrain use or not? *) > - are there obvious prior art that could make this patent obviously > invalid? > - what is decided and when (and what may change the decision, later)? > - what would be alternative ways to implement the function (if the > patent does not just cover the function, but a specific implementation > of it)? > > * one does not necessarily register a patent to be offensive with it; > here, we knew about iPix, what about the new holder? > > Btw, a draft policy for patents management was discussed among > founders and other people (lawyers) months ago and a tentative summary > written by me here: > http://mageia.org/wiki/doku.php?id=software_patents_policy . > > Cheers, > > Romain > Best regards Philippe
Re: [Mageia-dev] time to switch from raw partitions to lvm?
- "Thorsten van Lil" wrote: > Am 22.02.2011 09:07, schrieb Buchan Milne: > > > The user will still *always* be able to decide what he wants. The > question is, what to do for users who don't know what to decide. IMHO, > for a first time user, it is *much* better to give them a "Use > available space, with growable filesystems" or similar, than a > statically partitioned, based on difficult-to-get-right heuristics. > > > > That's a good point. The step for partitioning is still the most > complex > one during the installation. There are really often questions and > discussions how to partition the hard disk. Exactly. Dispensing with this requirement would make installation much easier, and still put the user in a position where they aren't setup for failure (all other solutions do, IMHO). > But, as a user who doesn't know anything about LVM, we should only > switch if the algorithm for LVM works really really stable and is easy With static partitions, the heuristics have to be good. For LVM, they just have to: -Ensure enough space for installation to succeed -Ensure a large percentage of the VG is not allocated (as growing is easier than shrinking) > to use. > It seems to me positive to switch to LVM for default but it's not > really > important, You obviously haven't seen how many users have questions about shrinking / from 50GB because they need more space for /home, or similar questions, on IRC. > so we don't should risk to much and take the time it needs, > > instead of forcing it to be finished for the next release, for > example. I listed the issues that I believe block switching to LVM by default. If they are fixed, I would think it would be an idea to launch the first stable release with LVM by default. Regards, Buchan
Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)
On Fri, Feb 18, 2011 at 10:57, Michael Scherer wrote: > Le vendredi 18 février 2011 à 10:13 +0100, Philippe DIDIER a écrit : >> Just seen that mikala added panotools in the repository . (some >> algorythms library to build panoramic photographs) >> Very happy with this ! (thanks a lot...) >> >> That's one of the first patent problems we may encounter : Yes, that's a good sample to use to improve our policy draft. >> Long time ago, How long is a "long time ago"? because every patent has a term and here it may have expired. >> iPIX, a company from USA muliplied patent lawsuit against >> these free algorythms inventor and photographers using them (this >> company is now dead because of bankruptcy but the patent problem is >> still live... ) > > Well, who own the patents now ? >From http://wiki.panotools.org/Ipix it looks a former competitor got a hold on all assets from iPix. On the decision/sorting out side, for this and for any other patent issue, do we document already (in source code or a separate file) the reasons to activate or not pieces of a software (or to exclude them from packages), because of some patents? List of questions to check would be at least: - what is exactly covered by what patent (reference, registration, territory/ies for which it has been registered)? - where is it implemented exactly in the source code? ( - who owns this patent? - did the patent holder announce his clear intention upon it? (that is, is he using it to control/restrain use or not? *) - are there obvious prior art that could make this patent obviously invalid? - what is decided and when (and what may change the decision, later)? - what would be alternative ways to implement the function (if the patent does not just cover the function, but a specific implementation of it)? * one does not necessarily register a patent to be offensive with it; here, we knew about iPix, what about the new holder? Btw, a draft policy for patents management was discussed among founders and other people (lawyers) months ago and a tentative summary written by me here: http://mageia.org/wiki/doku.php?id=software_patents_policy . Cheers, Romain
Re: [Mageia-dev] time to switch from raw partitions to lvm?
Am 22.02.2011 09:07, schrieb Buchan Milne: The user will still *always* be able to decide what he wants. The question is, what to do for users who don't know what to decide. IMHO, for a first time user, it is *much* better to give them a "Use available space, with growable filesystems" or similar, than a statically partitioned, based on difficult-to-get-right heuristics. That's a good point. The step for partitioning is still the most complex one during the installation. There are really often questions and discussions how to partition the hard disk. But, as a user who doesn't know anything about LVM, we should only switch if the algorithm for LVM works really really stable and is easy to use. It seems to me positive to switch to LVM for default but it's not really important, so we don't should risk to much and take the time it needs, instead of forcing it to be finished for the next release, for example. Just my concerns to this topic. Regards, Thorsten
Re: [Mageia-dev] time to switch from raw partitions to lvm?
- "Wolfgang Bornath" wrote: > 2011/2/21 Buchan Milne : > > On Monday, 21 February 2011 11:49:27 Thomas Lottmann wrote: > >> I am still not convinced of how easy this can be. For having > attempted > >> to manage (and learn) how to manage LVM partitons with CentOS, it > is > >> quite complicated. So it certainly has many advantages, but I'm > awaiting > >> an intuitive disk manager like Diskdrake to manage this stuff > without > >> the need of preliminary knowledge. > > > > Yes, with diskdrake, it's no problem. Anaconda's LVM interface is > quite > > confusing and complex. After installation, AFAIK, you can't access > the same > > interface. system-config-lvm (if it's still around) was also pretty > unusable. > > > > But, we have diskdrake, so why are the problems of CentOS an issue? > > Because (as I remarked earlier) there are people who have other Linux > flavors on their harddisk before they try Mageia - what if they do > their partitioning with those (i.e. CentOS)? Irrelevant. If there is free space, you can use LVM or not. Note CentOS defaults to LVM as of 5.x. If the whole disk is partitioned as a PV (likely with CentOS), then you will be forced to use LVM anyway ... > Again, people do not work all the same. Irrelevant. If this was the case, we would *FORCE* everyone to use LVM, or a large single root filesystem, or a complex layout, or something else. But we aren't discussing forcing of anything, just what the *default* option should be. > There are people who do their > partitioning with 3rd-party apps like gparted or others. Then they should not use the default, if they think they know better. > There are > people who like to have a bootloader in the root partition of each > Linux they install (using chainloader in the first Linux' grub), etc. Shame, IMHO putting bootloader in root partition is a bad idea. But, they can still do this. They can even install a bootloader in the boot partition of each distro, and use chainloader (which is what I do). No one is proposing preventing them from doing this. > IMHO it is a bad idea to make LVM default, because there are too many > cases around where people would not want LVM. IMHO, the majority of users *should* use LVM. The 10% who have specific reasons not to, will of course still be able to use normal partitions. The problem currently is that I suspect 90% of the users who should be using LVM, don't. Then, they need assistance from others to resize their /, or /home, or another filesystem that they sized incorrectly during installation. Users shouldn't need to "learn to partition", or "practice installing", by doing installations over and over until they figure out that / should be at least 10GB, but most likely not larger than 30GB, depending on whether they compile a lot (e.g. build packages or not). Is this really user-friendly? By this I mean, friendly to users who *haven't* used Linux before, not those who are installing their 10th distro on the same machine for the 15th time. > LVM as an option is a > far better solution and let the user decide what he wants. The user will still *always* be able to decide what he wants. The question is, what to do for users who don't know what to decide. IMHO, for a first time user, it is *much* better to give them a "Use available space, with growable filesystems" or similar, than a statically partitioned, based on difficult-to-get-right heuristics. Regards, Buchan
