Re: [Mageia-dev] Orphans - those poor orphans . . .
07.01.2012 01:09, Johnny A. Solbu kirjutas: On Friday 06 January 2012 18:54, Balcaen John wrote: I guess when you did encounter that you just remove task-kde from your system I did not. I should have been more clearly with my example. :-)= The packages in my example where all console program, that I installed and removed using urpm[ie]. So I explicitly removed only the one program I just installed. And it did not install any other packages, as a result of dependencies. And this is my point. We uninstall a specific program, not a meta/task package, which result in some packages beeing marked as orphaned, when they are infact Not orphaned. Give us command line example. Install something and remove it and then show me what got orphaned if it wasn't orphan before. What you claim here doesn't sound right as i haven't seen it myself. -- Sander
Re: [Mageia-dev] Orphans - those poor orphans . . .
Le 06/01/2012 17:55, Colin Guthrie a écrit : 'Twas brillig, and Robert Fox at 06/01/12 10:16 did gyre and gimble: After latest Cauldron updates, I got a real long list of suggested "orphans" - but I believe some of these packages are needed (like hal or basesystem-minimal) - How do I clear out the orphans - like reset the logic behind it so the correct packages will be orphaned? Or is a fresh install in order?? FWIW, as I see some people not liking this feature, personally I don't use --auto-orphans, but instead use "urpmq --not-available" to find packages I have installed that are no longer provided by the repositories. This will typically include old and unneeded library majors etc. that accumulate after a while. This list is much clearer in what it actually outputs and is basically the same as the yum orphan list command (I forget what the command actually is, but it's what inspired me to write the first version which in turn was vastly improved by a native implementation by (IIRC) Pascal Terjan :)) Col The problem is not 'I like it'/'I don't like it', the problem is that this feature caused sometimes the loss of very important packages making the system unusable and leading to a necessary reinstallation. -- Ce courriel a été émis à partir du système d'exploitation Mandriva Linux Préférez les logiciels libres et les formats ouverts. LINUX ? IL Y A MOINS BIEN, MAIS... C'EST PLUS CHER !!
Re: [Mageia-dev] Orphans - those poor orphans . . .
Sander Lepik a écrit :
07.01.2012 01:09, Johnny A. Solbu kirjutas:
On Friday 06 January 2012 18:54, Balcaen John wrote:
I guess when you did encounter that you just remove task-kde from
your system
I did not. I should have been more clearly with my example. :-)=
The packages in my example where all console program, that I
installed and removed using urpm[ie]. So I explicitly removed only
the one program I just installed. And it did not install any other
packages, as a result of dependencies.
And this is my point. We uninstall a specific program, not a
meta/task package, which result in some packages beeing marked as
orphaned, when they are infact Not orphaned.
Give us command line example. Install something and remove it and then
show me what got orphaned if it wasn't orphan before. What you claim
here doesn't sound right as i haven't seen it myself.
--
Sander
It is not exactly the same thing, but in more than one occasion when I
installed packages with similar functions at the same time, to compare
them, say A, B, and C, and later uninstalled B and C, I have found A to
be declared an orphan. Only to find that it had been required by one of
the others.
(I often prefer command-line packages. It is simple to add them to the
menu if I want. And I have often enough made such comparisons. To be
fair, I haven't done much of that since installing Mageia, when it first
became available.)
Really though, we should consider how people work with installing software.
The auto-orphans option and how it currently works is based on the
assumption that if package A is installed as a requirement of package B,
that on uninstalling B, one will want to uninstall A. That to me is a
false premise.
It is likely to be the case, but not necessarily.
Generally users will use the graphic installer (rpmdrake), as it is more
convenient. When the question of orphans is presented, if it is
presented, one should be presented with the same options that are
presented on installation with required packages. That is, to be able
to query the description ("more info") of the associated packages, and
thus readily make an informed decision of what to remove.
As well, the message should be that the orphaned packages "may" be no
longer useful, instead of saying that they can be safely removed.
Sure, in terms of not being strictly required by other packages, they
can be safely removed, but if I had always followed the auto-orphan
advice, I would have uninstalled gnome on more than one occasion.
(Which is my usual desktop environment.)
What is more important is what is needed for the user to be able to use
their computer as they wish, with the packages providing the functions
they wish. In that sense, auto-orphans does indeed break systems.
My 2 cents :)
--
André
Re: [Mageia-dev] Orphans - those poor orphans . . .
Le 07/01/2012 11:18, andre999 a écrit :
Sander Lepik a écrit :
07.01.2012 01:09, Johnny A. Solbu kirjutas:
On Friday 06 January 2012 18:54, Balcaen John wrote:
I guess when you did encounter that you just remove task-kde from
your system
I did not. I should have been more clearly with my example. :-)=
The packages in my example where all console program, that I
installed and removed using urpm[ie]. So I explicitly removed only
the one program I just installed. And it did not install any other
packages, as a result of dependencies.
And this is my point. We uninstall a specific program, not a
meta/task package, which result in some packages beeing marked as
orphaned, when they are infact Not orphaned.
Give us command line example. Install something and remove it and
then show me what got orphaned if it wasn't orphan before. What you
claim here doesn't sound right as i haven't seen it myself.
--
Sander
It is not exactly the same thing, but in more than one occasion when I
installed packages with similar functions at the same time, to compare
them, say A, B, and C, and later uninstalled B and C, I have found A
to be declared an orphan. Only to find that it had been required by
one of the others.
(I often prefer command-line packages. It is simple to add them to
the menu if I want. And I have often enough made such comparisons.
To be fair, I haven't done much of that since installing Mageia, when
it first became available.)
Really though, we should consider how people work with installing
software.
The auto-orphans option and how it currently works is based on the
assumption that if package A is installed as a requirement of package
B, that on uninstalling B, one will want to uninstall A. That to me
is a false premise.
It is likely to be the case, but not necessarily.
Generally users will use the graphic installer (rpmdrake), as it is
more convenient. When the question of orphans is presented, if it is
presented, one should be presented with the same options that are
presented on installation with required packages. That is, to be able
to query the description ("more info") of the associated packages, and
thus readily make an informed decision of what to remove.
As well, the message should be that the orphaned packages "may" be no
longer useful, instead of saying that they can be safely removed.
Sure, in terms of not being strictly required by other packages, they
can be safely removed, but if I had always followed the auto-orphan
advice, I would have uninstalled gnome on more than one occasion.
(Which is my usual desktop environment.)
What is more important is what is needed for the user to be able to
use their computer as they wish, with the packages providing the
functions they wish. In that sense, auto-orphans does indeed break
systems.
My 2 cents :)
+1
--
Ce courriel a été émis à partir du système d'exploitation Mandriva
Linux
Préférez les logiciels libres et les formats ouverts.
LINUX ? IL Y A MOINS BIEN, MAIS... C'EST PLUS CHER !!
Re: [Mageia-dev] Orphans - those poor orphans . . .
07.01.2012 12:18, andre999 kirjutas: It is not exactly the same thing, but in more than one occasion when I installed packages with similar functions at the same time, to compare them, say A, B, and C, and later uninstalled B and C, I have found A to be declared an orphan. Only to find that it had been required by one of the others. (I often prefer command-line packages. It is simple to add them to the menu if I want. And I have often enough made such comparisons. To be fair, I haven't done much of that since installing Mageia, when it first became available.) So what you say is: urpmi A urpmi B urpmi C urpme B C A would be orphan? Really?! Show me. I want an example! The auto-orphans option and how it currently works is based on the assumption that if package A is installed as a requirement of package B, that on uninstalling B, one will want to uninstall A. That to me is a false premise. You do get the point of orphans?! System has no AI. It only knows what it has to know. If you still want A you would just run urpmi A and urpme --auto-orphans won't remove it! Simple as that. -- Sander
Re: [Mageia-dev] Orphans - those poor orphans . . .
2012/1/7 andre999 :
> Sander Lepik a écrit :
>>
>> 07.01.2012 01:09, Johnny A. Solbu kirjutas:
>>>
>>> On Friday 06 January 2012 18:54, Balcaen John wrote:
I guess when you did encounter that you just remove task-kde from your
system
>>>
>>> I did not. I should have been more clearly with my example. :-)=
>>> The packages in my example where all console program, that I installed
>>> and removed using urpm[ie]. So I explicitly removed only the one program I
>>> just installed. And it did not install any other packages, as a result of
>>> dependencies.
>>>
>>> And this is my point. We uninstall a specific program, not a meta/task
>>> package, which result in some packages beeing marked as orphaned, when they
>>> are infact Not orphaned.
>>
>> Give us command line example. Install something and remove it and then
>> show me what got orphaned if it wasn't orphan before. What you claim here
>> doesn't sound right as i haven't seen it myself.
>>
>> --
>> Sander
>
>
> It is not exactly the same thing, but in more than one occasion when I
> installed packages with similar functions at the same time, to compare them,
> say A, B, and C, and later uninstalled B and C, I have found A to be
> declared an orphan. Only to find that it had been required by one of the
> others.
> (I often prefer command-line packages. It is simple to add them to the menu
> if I want. And I have often enough made such comparisons. To be fair, I
> haven't done much of that since installing Mageia, when it first became
> available.)
>
> Really though, we should consider how people work with installing software.
>
> The auto-orphans option and how it currently works is based on the
> assumption that if package A is installed as a requirement of package B,
> that on uninstalling B, one will want to uninstall A. That to me is a false
> premise.
> It is likely to be the case, but not necessarily.
> Generally users will use the graphic installer (rpmdrake), as it is more
> convenient. When the question of orphans is presented, if it is presented,
> one should be presented with the same options that are presented on
> installation with required packages. That is, to be able to query the
> description ("more info") of the associated packages, and thus readily make
> an informed decision of what to remove.
This is ok if you have 2 or 3 orphans. But it is unpractical if more
packages are declared as orphans. As I wrote earlier, when he is
presented with a list of 20 or even 100 "orphans" the user will
definitely not sit down and check each package for "more info".
--
wobo
Re: [Mageia-dev] Orphans - those poor orphans . . .
07.01.2012 09:18, LinuxBSDos.com skrev: True that the user does not and should not care about definitions of an orphan, but also, the user should not be put in a situation where he/she will have to go hunting for what could or could not break anything. Well urpme is not at fault. It's doing exactly what it's told. It cant solve packager errors. If a packager has forgot a "Requires", urpmi does not know that. The only things --auto-orphans has to go on is: 1. is the package on the "keep list" such as basesystem -> dont remove. 2. is the package required by some other package -> dont remove. 3. is the package manually installed with urpmi/rpmdrake -> dont remove. 4. is the package the current running kernel -> dont remove. So, if you find your system would be broken (or got broken) by running urpme --auto-orphans (or the same function in rpmdrake), and you want it fixed, file bug reports. And not against urpmi/rpmdrake, but the package that stopped working. -- Thomas
Re: [Mageia-dev] Orphans - those poor orphans . . .
2012/1/7 Thomas Backlund : > 07.01.2012 09:18, LinuxBSDos.com skrev: >> >> >> True that the user does not and should not care about definitions of an >> orphan, but also, the user should not be put in a situation where he/she >> will have to go hunting for what could or could not break anything. >> > > Well urpme is not at fault. It's doing exactly what it's told. > > It cant solve packager errors. If a packager has forgot a "Requires", > urpmi does not know that. > > The only things --auto-orphans has to go on is: > 1. is the package on the "keep list" such as basesystem -> dont remove. > 2. is the package required by some other package -> dont remove. > 3. is the package manually installed with urpmi/rpmdrake -> dont remove. > 4. is the package the current running kernel -> dont remove. > > > So, if you find your system would be broken (or got broken) by running > urpme --auto-orphans (or the same function in rpmdrake), and you want > it fixed, file bug reports. > > And not against urpmi/rpmdrake, but the package that stopped working. Of course this is one way to find bugs in packages. But what about the documented (in German) case where - after fresh installation, reboot (ok) and updates right after installation I was presented with a list of more than 100 "orphans". - I ran 'urpme --auto-orphans' and rebooted - several system services (which started successfully after installation) refused to start now because of missing files Of course urpmi was not the culprit because it only checks dependencies. But that did matter in that situation. The auto-orphans function obviously listed packages which may have no dependencies but are needed by the system. That's why I do not complain about urpmi but about the whole function. As long as this function is only based on package dependencies it is not safe to use it. -- wobo
Re: [Mageia-dev] Orphans - those poor orphans . . .
2012/1/7 Wolfgang Bornath : > > Of course this is one way to find bugs in packages. But what about the > documented (in German) case where Sorry, "documented" is not the correct word. I could not document it with logs or namng of files. I only stated what I did and what it resulted to. -- wobo
Re: [Mageia-dev] Orphans - those poor orphans . . .
07.01.2012 13:39, Wolfgang Bornath kirjutas: Of course this is one way to find bugs in packages. But what about the documented (in German) case where - after fresh installation, reboot (ok) and updates right after installation I was presented with a list of more than 100 "orphans". - I ran 'urpme --auto-orphans' and rebooted - several system services (which started successfully after installation) refused to start now because of missing files Of course urpmi was not the culprit because it only checks dependencies. But that did matter in that situation. The auto-orphans function obviously listed packages which may have no dependencies but are needed by the system. That's why I do not complain about urpmi but about the whole function. As long as this function is only based on package dependencies it is not safe to use it. Did you choose custom install and unchecked some options? Or did you use LiveCD maybe? Anyway.. function is not to blame. Next time copy those packages that are going to be uninstalled. And they can be rechecked. Which are needed and why they get orphaned. -- Sander
Re: [Mageia-dev] Orphans - those poor orphans . . .
On Saturday 07 January 2012 09:42, Sander Lepik wrote: > Give us command line example. Install something and remove it and then show > me what got > orphaned if it wasn't orphan before. What you claim here doesn't sound right > as i haven't > seen it myself. I'll do that next time I come across it. The example from way back in MDK 9.1 is the example I remember from the top of my head, simply because it wanted to uninstall my entire graphical system. -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Orphans - those poor orphans . . .
Sander Lepik a écrit : 07.01.2012 12:18, andre999 kirjutas: It is not exactly the same thing, but in more than one occasion when I installed packages with similar functions at the same time, to compare them, say A, B, and C, and later uninstalled B and C, I have found A to be declared an orphan. Only to find that it had been required by one of the others. (I often prefer command-line packages. It is simple to add them to the menu if I want. And I have often enough made such comparisons. To be fair, I haven't done much of that since installing Mageia, when it first became available.) So what you say is: urpmi A urpmi B urpmi C Not at all. That is installing A, B, and C sequentially, one after the other. Using urpmi, installing at the same time would be urpmi A B C Although I'm not sure that it would work the same as rpmdrake, which I use so as to more easily select and install packages with similar functions. I'm sure that most users with similar considerations would do the same. Of course if one is involved in developing or testing packages, urpmi is convenient, but otherwise a graphical interface like rpmdrake is easier. urpme B C A would be orphan? Really?! Show me. I want an example! Not your example. But that is not what I said. The auto-orphans option and how it currently works is based on the assumption that if package A is installed as a requirement of package B, that on uninstalling B, one will want to uninstall A. That to me is a false premise. You do get the point of orphans?! System has no AI. It only knows what it has to know. If you still want A you would just run urpmi A and urpme --auto-orphans won't remove it! Simple as that. I understand very well the concept. My point is that, in terms of what users can reasonably expect to happen, and how auto-orphans is applied, the concept is flawed. Telling users that it is safe to remove identified "orphans", where the expected functioning of their system can be seriously impacted, is simply not appropriate. (One could say not very "user-friendly".) BTW, the solution to remove the auto-orphan message for a package, a feigned install of an already installed package, is rather obtuse, to say the least. -- Sander -- André
[Mageia-dev] imported .src.rpm / .spec attribution
Hi, In Mandriva I was using this command to make proper attribution of imported .spec files: $ mdvsys import foo.src.rpm --message 'this spec file is imported from Fedora where it was written by X' I'm trying to make the equivalent with this command: $ mgarepo putsrpm -m "this spec file is imported from Mandriva where it was written by X" package.src.rpm error: no such option: -m $ mgarepo putsrpm --message "this spec file is imported from Mandriva where it was written by X" package.src.rpm error: no such option: --message $ mgarepo putsrpm --help | grep -- -m -m LOG Log message used when commiting changes What is the right command line to achieve this? Thanks
[Mageia-dev] Alpha3 release notes
Hi all, please do have a look at the alpha3 release notes: https://wiki.mageia.org/en/Mageia_2_alpha3 and fix/complete them. By keeping them up to date during the alpha/beta/rc phases we will finally have some nice release notes for Mageia2. It really only takes a few minutes for everyone... Oliver
Re: [Mageia-dev] imported .src.rpm / .spec attribution
Le 07/01/2012 13:23, Florent Monnier a écrit : Hi, In Mandriva I was using this command to make proper attribution of imported .spec files: $ mdvsys import foo.src.rpm --message 'this spec file is imported from Fedora where it was written by X' I'm trying to make the equivalent with this command: $ mgarepo putsrpm -m "this spec file is imported from Mandriva where it was written by X" package.src.rpm error: no such option: -m $ mgarepo putsrpm --message "this spec file is imported from Mandriva where it was written by X" package.src.rpm error: no such option: --message $ mgarepo putsrpm --help | grep -- -m -m LOG Log message used when commiting changes What is the right command line to achieve this? Can you try mgarepo putsrpm -l LOG ... ? Could you please file a bugreport? regards, Luc -- Luc Menut
Re: [Mageia-dev] Alpha3 release notes
Op zaterdag 07 januari 2012 13:40:44 schreef Oliver Burger: > Hi all, > > please do have a look at the alpha3 release notes: > https://wiki.mageia.org/en/Mageia_2_alpha3 and fix/complete them. By > keeping them up to date during the alpha/beta/rc phases we will > finally have some nice release notes for Mageia2. > > It really only takes a few minutes for everyone... > > Oliver i updated https://wiki.mageia.org/en/Mageia_2_alpha3#Databases is this sort of what you want? or is it too much?
Re: [Mageia-dev] imported .src.rpm / .spec attribution
Op zaterdag 07 januari 2012 13:23:10 schreef Florent Monnier: > Hi, > > In Mandriva I was using this command to make proper attribution of imported > .spec files: > > $ mdvsys import foo.src.rpm --message 'this spec file is imported from > Fedora where it was written by X' > > I'm trying to make the equivalent with this command: > > $ mgarepo putsrpm -m "this spec file is imported from Mandriva where it was > written by X" package.src.rpm > error: no such option: -m > > $ mgarepo putsrpm --message "this spec file is imported from Mandriva where > it was written by X" package.src.rpm > error: no such option: --message > > $ mgarepo putsrpm --help | grep -- -m > -m LOG Log message used when commiting changes > > What is the right command line to achieve this? > > Thanks i thought "mgarepo import file.src.rpm" was what was done? and not putsrpm?
Re: [Mageia-dev] Alpha3 release notes
Maarten Vanraes skrev 7.1.2012 15:34: Op zaterdag 07 januari 2012 13:40:44 schreef Oliver Burger: Hi all, please do have a look at the alpha3 release notes: https://wiki.mageia.org/en/Mageia_2_alpha3 and fix/complete them. By keeping them up to date during the alpha/beta/rc phases we will finally have some nice release notes for Mageia2. It really only takes a few minutes for everyone... Oliver i updated https://wiki.mageia.org/en/Mageia_2_alpha3#Databases is this sort of what you want? or is it too much? I would replace "an as of yet unreleased MariaDB 5.5.18" with "MariaDB 5.5.18 prerelease" -- Thomas
Re: [Mageia-dev] imported .src.rpm / .spec attribution
Le 07/01/2012 14:36, Maarten Vanraes a écrit :
i thought "mgarepo import file.src.rpm" was what was done? and not putsrpm?
it's exactly the same command; import is an alias for putsrpm.
command_aliases = {"import": "putsrpm"}
--
Luc Menut
Re: [Mageia-dev] imported .src.rpm / .spec attribution
Le samedi 07 janvier 2012 13:58:05, Luc Menut a écrit : > Le 07/01/2012 13:23, Florent Monnier a écrit : > > Hi, > > > > In Mandriva I was using this command to make proper attribution of > > imported .spec files: > > > > $ mdvsys import foo.src.rpm --message 'this spec file is imported from > > Fedora where it was written by X' > > > > I'm trying to make the equivalent with this command: > > > > $ mgarepo putsrpm -m "this spec file is imported from Mandriva where it > > was written by X" package.src.rpm > > error: no such option: -m > > > > $ mgarepo putsrpm --message "this spec file is imported from Mandriva > > where it was written by X" package.src.rpm > > error: no such option: --message > > > > $ mgarepo putsrpm --help | grep -- -m > > > > -m LOG Log message used when commiting changes > > > > What is the right command line to achieve this? > > Can you try mgarepo putsrpm -l LOG ... ? Yes it does work, thanks > Could you please file a bugreport? Is this right? https://bugs.mageia.org/show_bug.cgi?id=4053 --
Re: [Mageia-dev] Orphans - those poor orphans . . .
2012/1/7 Sander Lepik : > 07.01.2012 13:39, Wolfgang Bornath kirjutas: >> >> Of course this is one way to find bugs in packages. But what about the >> documented (in German) case where >> - after fresh installation, reboot (ok) and updates right after >> installation I was presented with a list of more than 100 "orphans". >> - I ran 'urpme --auto-orphans' and rebooted >> - several system services (which started successfully after >> installation) refused to start now because of missing files >> >> Of course urpmi was not the culprit because it only checks >> dependencies. But that did matter in that situation. The auto-orphans >> function obviously listed packages which may have no dependencies but >> are needed by the system. That's why I do not complain about urpmi but >> about the whole function. As long as this function is only based on >> package dependencies it is not safe to use it. > > Did you choose custom install and unchecked some options? Or did you use > LiveCD maybe? Anyway.. function is not to blame. Next time copy those > packages that are going to be uninstalled. And they can be rechecked. Which > are needed and why they get orphaned. Used the full DVD (32-bit) Mageia 2 Alpha 2 - minimal install with X - after installation and reboot everything was ok - setup the package media (dedicated mirror) and did 'urpmi -auto-update' - I did NOT install or remove one single package manually - after that urpmi showed a list of more than 100 orphans - used 'urpme -auto-orphans - at reboot the start messages showed several errors concerning crond, network-up, postfix, display manager, etc. - system start stopped before x was started. Repeated the boot process with same result. A side question is why I got so many orphans in a minimal system with only around 700 packages in total and only around 2 or 3 dozens of updates (all this happened not long after Alpha 2 release.) Of course urpmi is not the culprit, it is the shortcomings of the function as it is. It should just not be there if its use could lead to such behavior, no matter where the cause comes from. Simply said: a gasoline brand should not be sold if it could do damage to the car's motor, no matter which of the components of the fluid causes the damage.. Anyhow, I will repeat the same operation when Alpha 2 is released in a couple of days and as soon as the system shows orphans I will document that list and (if the same problem arises) dmesg output if available. What else do you need for a reasonable documentation? -- wobo
Re: [Mageia-dev] Orphans - those poor orphans . . .
07.01.2012 16:24, Wolfgang Bornath kirjutas: Used the full DVD (32-bit) Mageia 2 Alpha 2 - minimal install with X How? AFAIK this is not one of the default options. -- Sander
Re: [Mageia-dev] [packages-commits] [192938] wxGTK2.8-devel
2012/1/7 : > Revision 192938 Author blue_prawn Date 2012-01-07 15:42:20 +0100 (Sat, 07 > Jan 2012) > > Log Message > > wxGTK2.8-devel > Aand what did you do with wxGTK2.8-devel? This doesn't explain it at all. Changelog entry must be more descriptive, like "wgGTK2.8-devel was renamed to wxgtk2.8-devel".
Re: [Mageia-dev] Orphans - those poor orphans . . .
2012/1/7 Sander Lepik : > 07.01.2012 16:24, Wolfgang Bornath kirjutas: >> >> >> Used the full DVD (32-bit) Mageia 2 Alpha 2 >> - minimal install with X > > How? AFAIK this is not one of the default options. It is. 1. Select "Custom" at the DE selection 2. Unmark all package groups 3. Up comes a selection of 4 options: - minimal with x - minimal without x - truely minimal (only base system - minimal with documentation (which is an option you can select together with one of the first 2. So, yes, it is a defined set of packages. That's why I used it. -- wobo
Re: [Mageia-dev] Orphans - those poor orphans . . .
07.01.2012 17:09, Wolfgang Bornath kirjutas: 2012/1/7 Sander Lepik: 07.01.2012 16:24, Wolfgang Bornath kirjutas: Used the full DVD (32-bit) Mageia 2 Alpha 2 - minimal install with X How? AFAIK this is not one of the default options. It is. 1. Select "Custom" at the DE selection 2. Unmark all package groups 3. Up comes a selection of 4 options: - minimal with x - minimal without x - truely minimal (only base system - minimal with documentation (which is an option you can select together with one of the first 2. So, yes, it is a defined set of packages. That's why I used it. Ok, next time if you test, do the same. But before removing orphans copy them for later debugging. -- Sander
Re: [Mageia-dev] Alpha3 release notes
2012/1/7 Thomas Backlund : > Maarten Vanraes skrev 7.1.2012 15:34: > >> i updated https://wiki.mageia.org/en/Mageia_2_alpha3#Databases >> >> is this sort of what you want? or is it too much? > I would replace "an as of yet unreleased MariaDB 5.5.18" > with "MariaDB 5.5.18 prerelease" I rewrote it a bit. @ all: please look especially at those parts without any content and complete them :) Oliver
[Mageia-dev] Interesting issue after kernel update (Error 18)
After a reboot the I get an Error 18 message telling me that the Selected Cylinder exceeds the maximum supported by the bios. I then assumed that the new kernel must be crap and tried to use the previous kernel and got the same error message. My system is a bit odd that the bios sees the drives in the wrong order. I have 3 2TB drives, The first 2 drives have Linux stuff installed and the 3rd drive has eComStation (OS/2) seen as HPFS/NTFS under Linux. The bios as showned by my bootloader sees it as drive 0-2-1 instead 0f 0-1-2. Grub sees it the same way, but linux sees it in the correct order. Mageia is installed on the second drive as you can see, correctly identified as sdb [root@localhost grub]# df Sys. de fichiersTaille Uti. Disp. Uti% Monté sur /dev/sdb9 493G 326G 142G 70% / /dev/sdb3 136M 43M 86M 34% /boot /dev/sdb10354G 27G 310G 8% /home/michel/vm_files What I found was that the installer of the new kernel scrapped my menu.lst file, I fixed it with an editor while booted on Scientific Linux. This may explain why when I installed Mageia that grub would not work and I had to set grub correctly. To get Mageia to work after the installation I had to first boot on Scientific Linux, I added a boot block in SL6 menu.lst and booted on Mageia I then fixed menu.lst and rebooted, everything was cool then. When I updated the kernel it messed up and I could no longer boot on Mageia. I must have forgotten as I got burned by the same screw up this morning. Here is the content of the menu.lst file prior to the upgrade followed by the one after the upgrade, notice that the installer changed the drive information by mistake. It didn't change the boot for Centos and Scientific Linux. I would think that there should be a way for the Mageia installer (and grub) to know when what the bios thinks and what is real match. As to why the bios gets the wrong order of the drives, I am not sure. Maybe it has a hard time with the OS/2 partitions. I had similar issues when I put a vista drive of a friend in my computer. her Dell was shot and I had to recover tons of pictures for her. -- timeout 10 color black/cyan yellow/cyan default 0 title 2.6.38.8-server-8.mga kernel (hd2,2)/vmlinuz-2.6.38.8-server-8.mga BOOT_IMAGE=2.6.38.8-server-8.mga root=UUID=69fa904e-c5d1-461d-851f-4b8f5c3fae6a nokmsboot resume=UUID=0ca4e00e-69be-4824-be88-f457951aa974 splash=0 selinux=0 vga=788 initrd (hd2,2)/initrd-2.6.38.8-server-8.mga.img title 2.6.38.8-server-6.mga kernel (hd2,2)/vmlinuz-2.6.38.8-server-6.mga BOOT_IMAGE=2.6.38.8-server-6.mga root=UUID=69fa904e-c5d1-461d-851f-4b8f5c3fae6a nokmsboot resume=UUID=0ca4e00e-69be-4824-be88-f457951aa974 splash=0 vga=788 initrd (hd2,2)/initrd-2.6.38.8-server-6.mga.img title linux kernel (hd2,2)/vmlinuz BOOT_IMAGE=linux root=UUID=69fa904e-c5d1-461d-851f-4b8f5c3fae6a nokmsboot resume=UUID=0ca4e00e-69be-4824-be88-f457951aa974 splash=0 selinux=0 vga=788 initrd (hd2,2)/initrd.img title linux-nonfb kernel (hd2,2)/vmlinuz BOOT_IMAGE=linux-nonfb root=UUID=69fa904e-c5d1-461d-851f-4b8f5c3fae6a nokmsboot resume=UUID=0ca4e00e-69be-4824-be88-f457951aa974 initrd (hd2,2)/initrd.img title failsafe kernel (hd2,2)/vmlinuz BOOT_IMAGE=failsafe root=UUID=69fa904e-c5d1-461d-851f-4b8f5c3fae6a failsafe initrd (hd2,2)/initrd.img title 2.6.38.7-server-1.mga kernel (hd2,2)/vmlinuz-2.6.38.7-server-1.mga BOOT_IMAGE=2.6.38.7-server-1.mga root=UUID=69fa904e-c5d1-461d-851f-4b8f5c3fae6a nokmsboot resume=UUID=0ca4e00e-69be-4824-be88-f457951aa974 splash=silent vga=788 initrd (hd2,2)/initrd-2.6.38.7-server-1.mga.img title 2.6.38.8-server-6.mga kernel (hd2,2)/vmlinuz-2.6.38.8-server-6.mga BOOT_IMAGE=2.6.38.8-server-6.mga root=UUID=69fa904e-c5d1-461d-851f-4b8f5c3fae6a nokmsboot resume=UUID=0ca4e00e-69be-4824-be88-f457951aa974 splash=silent vga=788 initrd (hd2,2)/initrd-2.6.38.8-server-6.mga.img title Centos Linux (2.6.32-131.12.1.el6.x86_64) root (hd2,1) kernel /vmlinuz-2.6.32-131.12.1.el6.x86_64 ro root=UUID=66b960ab-2013-4e86-9ea0-b9d94618394c rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=fr_FR.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=cf rhgb selinux=0 crashkernel=auto nouveau.modeset=0 rdblacklist=nouveau vga=0x37D initrd /initramfs-2.6.32-131.12.1.el6.x86_64.img title Scientific Linux (2.6.32-131.6.1.el6.x86_64) root (hd2,0) kernel /vmlinuz-2.6.32-131.6.1.el6.x86_64 ro root=UUID=6acb0018-50dc-4e19-8035-cc3e68c05d83 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=fr_FR.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=cf nomodeset crashkernel=128M rhgb quiet selinux=0 nouveau.modeset=0 rdblacklist=nouveau initrd /initramfs-2.6.32-131.6.1.el6.x86_64.img -
Re: [Mageia-dev] references to outside web sites/wiki
Wolfgang Bornath wrote: > 2012/1/5 Buchan Milne : >> -Possibly considering contacting large mirror sites (e.g. mirrors.kernel.org) >> who currently mirror Mandriva, but not Mageia? > > Just for the records: mirrors.kernel.org mirror Mageia. > But surely there are more large sites to be contacted. carroll.aset.psu.edu is one of the major mirrors in the USA that's missing Mageia still.
Re: [Mageia-dev] references to outside web sites/wiki
Glen Ogilvie wrote: >> On Wednesday, 4 January 2012 23:56:01 Romain d'Alverny wrote: >> > On Wed, Jan 4, 2012 at 22:36, Johnny A. Solbu wrote: >> > > On Wednesday 04 January 2012 21:06, Romain d'Alverny wrote: >> > >> wiki.mandriva.com may be shut down for good in just a few days >> > > >> > > What? Are Mandriva serisouly considering closing down the Wiki? >> > >> > Mandriva is on the path to filing for bankruptcy on January 16th. > > Does anyone have a complete mirror / copy of the Mandriva svn repository, or > a complete set of SRPMs from cooker? I would be concerned this becomes > unavailable, as it's a valuable resource for packages not yet imported into > Mageia and contains a history of the package that Mageia does not have. I asked about this on IRC and was directed to http://rsvndump.sourceforge.net/ as a tool that can be used to download their SVN repository. I'd *really* like to see this happen and be somewhere that everyone has access to (i.e. not have me try to do it myself). If there's anything needed to help make this happen, I'm willing to help however I can. I'd really hate for us to lose MDV's SVN packages repository.
Re: [Mageia-dev] Orphans - those poor orphans . . .
On 07/01/12 15:30, Sander Lepik wrote: 07.01.2012 17:09, Wolfgang Bornath kirjutas: 2012/1/7 Sander Lepik: 07.01.2012 16:24, Wolfgang Bornath kirjutas: Used the full DVD (32-bit) Mageia 2 Alpha 2 - minimal install with X How? AFAIK this is not one of the default options. It is. 1. Select "Custom" at the DE selection 2. Unmark all package groups 3. Up comes a selection of 4 options: - minimal with x - minimal without x - truely minimal (only base system - minimal with documentation (which is an option you can select together with one of the first 2. So, yes, it is a defined set of packages. That's why I used it. Ok, next time if you test, do the same. But before removing orphans copy them for later debugging. -- Sander Could this bug have anything to do with occasional --auto-orphans glitches? https://bugs.mageia.org/show_bug.cgi?id=1754 (urpmq --requires-recursive doesn't show everything that would be installed)
Re: [Mageia-dev] Orphans - those poor orphans . . .
On Friday, January 06, 2012 12:57:39 PM Sander Lepik wrote: > 06.01.2012 21:06, Dale Huckeby kirjutas: > > Evidently once I've installed package A which requests X, sometimes > > packages F, L, and T might subsequently get installed which also need X > > *and presumably would have requested it had it not already been > > installed*. But when I uninstall A it orphans X because A is the only > > package that *requested* it. When F, L, and T are installed can't all > > the packages they *would have requested* be marked whether or not > > they're already installed? That way a package would be orphaned only > > when the last package that needs it is uninstalled? Or am I missing > > something? > > This is already so. See example: http://pastebin.com/AMj87QiV - after first > urpme libplasmaweather4 should be marked as orphan but it's not as it's > still required by other package. > > -- > Sander It seems to me, auto-orphans gives more headaches than benefits. Why are we clinching to it? -- Best regards Thomas Spuhler
[Mageia-dev] Welcoming Kamil among the Mageia packagers
Hi there, let me welcome Kamil Rytarowski - Mageia login name kamil - as a full Mageia packager. In the time I had the pleasure to mentor him, I got to know him as a dedicated and alert person showing me from time to time that I should read the packaging policies from time to time. So Kamil, welcome to the team! And if you should face any problem or any situation unclear to you, just remember, there are more senior people out here to ask. Oliver
Re: [Mageia-dev] Seamonkey package
Am 16.04.2011 16:05, schrieb Christiaan Welvaart: > On Fri, 11 Mar 2011, Tux99 wrote: > >> I just downloaded the latest Seamonkey 2.0.12 SRPM from Mandriva cooker and >> rebuilt it on my Mageia VM and it built flawlessly, I only had to remove >> all the obsolete "%if %mdkversion" sections, but all dependecies are >> available in Mageia. >> So technically importing Seamonkey into Mageia seems straightforward, the >> only issue is licensing (as for Firefox). >> >> Christiaan I'm a newbie packager here at Mageia so personally I'd much >> prefer if you maintain this package for Mageia, it looks far too complex >> for me. :) > > I uploaded "iceape 2.0.12" a few days ago, changing the name and icons/logo > took me almost a month. Unfortunately there are still some bugs in this > area: the release notes menu item for example currently still points to > seamonkey. It should probably point to a mageia wiki page. > > Since I don't like the icons that is used for debian's iceape, I created a > new icon based on the logo. It looks like it can still be improved, however, > and the throbber is currently static. So it would be great if someone could > re-do the icon (without creating a completely new design), and animate it for > the throbber (he SVG files are in iceape-branding.tar in the source rpm and > svn)... > > > Christiaan > As iceape for mga1 hasn't seen any update in the last 6 months, and there are multiple serious security issues that need fixing, how do we handle this? And i've found no real reason for this rebranding in the first place, and this seems also be the case for Fedora, and they have a strong legal department. http://pkgs.fedoraproject.org/gitweb/?p=seamonkey.git >From what i read on bugreports between debian packagers and mozilla guys about that branding situation, the only thing that would need to be done to seamonkey (actually the same would need to be done for all our mozilla packages, unless we have permission to use the branding, which would imply that all our modifications on mozilla packages would need to be reviewed and ack-ed by mozilla to get the branding permission) would be to use --disable-official-branding configure option.
Re: [Mageia-dev] Orphans - those poor orphans . . .
07.01.2012 17:09, Wolfgang Bornath skrev: 2012/1/7 Sander Lepik: 07.01.2012 16:24, Wolfgang Bornath kirjutas: Used the full DVD (32-bit) Mageia 2 Alpha 2 - minimal install with X How? AFAIK this is not one of the default options. It is. 1. Select "Custom" at the DE selection 2. Unmark all package groups 3. Up comes a selection of 4 options: - minimal with x - minimal without x - truely minimal (only base system - minimal with documentation (which is an option you can select together with one of the first 2. So, yes, it is a defined set of packages. That's why I used it. Ok. a real working example (of a "non-working" --auto-orphans) Thanks wobo, it's this kind of info we really need. Now lets try to reproduce and fix it. -- Thomas
Re: [Mageia-dev] Welcoming Kamil among the Mageia packagers
W dniu 07.01.2012 18:24, Oliver Burger pisze: Hi there, let me welcome Kamil Rytarowski - Mageia login name kamil - as a full Mageia packager. In the time I had the pleasure to mentor him, I got to know him as a dedicated and alert person showing me from time to time that I should read the packaging policies from time to time. So Kamil, welcome to the team! And if you should face any problem or any situation unclear to you, just remember, there are more senior people out here to ask. Oliver I'm very glad to be a part of our team. Thank you for your hospitable welcome and help from you and the all helpful people among our developers!
Re: [Mageia-dev] Orphans - those poor orphans . . .
Op zaterdag 07 januari 2012 17:48:36 schreef Thomas Spuhler: [...] > It seems to me, auto-orphans gives more headaches than benefits. Why are we > clinching to it? because it works for me (and several others)
Re: [Mageia-dev] [packages-commits] [193033] Suggests sectools instead of a Requires ( mga # 2808)
Le 08/01/2012 02:01, r...@mageia.org a écrit : Revision 193033 Author dmorgan Date 2012-01-08 02:01:07 +0100 (Sun, 08 Jan 2012) Log Message Suggests sectools instead of a Requires ( mga # 2808) Modified Paths * updates/1/msec/current/SPECS/msec.spec <#updates1mseccurrentSPECSmsecspec> Modified: updates/1/msec/current/SPECS/msec.spec === --- updates/1/msec/current/SPECS/msec.spec 2012-01-08 00:58:08 UTC (rev 193032) +++ updates/1/msec/current/SPECS/msec.spec 2012-01-08 01:01:07 UTC (rev 193033) @@ -1,4 +1,4 @@ -%definesubrel 5 +%definesubrel 6 Name: msec Version: 0.80.10 @@ -22,7 +22,7 @@ Requires: chkconfig Requires: mailx Requires: python -Requires: sectool +Suggests: sectool # at least xargs is used Requires: findutils # ensure sysctl.conf and inittab are present before installing msec wouldn't it be better to split the sectool plugin in a subpackage, cf. https://bugs.mageia.org/show_bug.cgi?id=2255#c68 https://bugs.mageia.org/attachment.cgi?id=1329&action=diff Luc -- Luc Menut
Re: [Mageia-dev] Alpha3 release notes
On Sat, Jan 7, 2012 at 7:40 AM, Oliver Burger wrote: > Hi all, > > please do have a look at the alpha3 release notes: > https://wiki.mageia.org/en/Mageia_2_alpha3 and fix/complete them. By > keeping them up to date during the alpha/beta/rc phases we will > finally have some nice release notes for Mageia2. > Question, should we add new programs only or updated ones to new versions too ? -- Juancho
