and both i586 and x86_64 kernels were tested on a i7-860 workstation and
on a Acer TravelMate 5720 laptop before submitting to the buildsystem...
tmb, for the Wi-Fi issue, I identified the culprit.
With the 2.6.38 kernel, dkms-broadcom-wl was useless (Broadcom STA
is a hybrid driver,
tmb, I hate you.
making kernel-desktop-latest to point to kernel-desktop-3.0.0-0.rc7.2.1.mga2
instead of kernel-desktop-devel-2.6.38.8-5.mga2 was a big mistake.
there should have been something like kernel-desktop-latest3 for a while, to
let people test that 3.0 thing (rc, right? I know this
My acer laptops are having a completely different experience with it, they
just work
(acer timelinex 4820, acer aspire one d450, acer travelmate T4100 and acer
travelmate
C312XMi - yes, I have a nice acer collection with me :)).
So at least for me, kernel 3.0 is a huge win!
Eugeni,
you still can use the kernel 2.6 which is installed on your machine,
installing a newer kernel doesn't uninstall the previous one.
yes, I can, but only because I've edited menu.lst _manually_.
the new kernel added 2 grub entries, at the end, both pointing to the 3.0.0
kernel.
and the default
Please understand linux 3.0 is just a different name for 2.6.40, there's
nothing special about it. So a kernel-desktop-latest3 doesn't make any
sense.
ok, then how about
kernel-desktop-latest-unstable
kernel-desktop-latest-rc
kernel-desktop-latest-beta
?
because it's not a properly tested
On my machine there isnt't this problem.
The last entry in the menu.lst points to 2.6.38.8-desktop-4
all automatically, without editing.
so grub works normally.
no, it does not. it never did. the testing scenarios have always been
insufficient.
I needed to add an entry to menu.lst to chain
R-C, please behave.. this is cauldron, it breaks stuff and we almost want it
(at least sometimes :)). If you don't like the way it is, please don't use it!
Sander,
As long as Linux distros are such idiotically designed that one can _not_ have
the latest packages for the applications I
[didn't read it all - don't have that much time]
that's very considerate. at least, you were able to write the above line.
I have to say.. for the last 10+ years you have used OS that's not for you
and that you don't understand. Sorry for you, maybe Mr. Jobs can help you out?
I'd rather
WTF? We do this quite regularly... the rc's have been pushed in cooker
and I'm pretty sure cauldron in the past. The fact that this is 3.x.x
rather 2.6.38 is pretty much a whim of numbering and nothing
specifically relating to anything significant or similar.
And who cares if -latest is
Seriously, look in a mirror and judge yourself, not others.
OK, updating from 2.6.38 to 2.6.40-0.rc7 aka 3.0.0-0.rc7 was the right
thing.
Satisfied now?
There seem to be several standards when judging what to do in an unstable
distro.
In a released distro, the common rule is _not_ to update
The above statement clearly says I've only read one feature of
systemd
Maybe it's not about systemd. Maybe it's about upstart. Or maybe
it's about a half-dozen init system I don't care about -- and you know
why?
Not just because I'm not a sysadmin, but because the public image --
those 99%
Sick of the lack of quality is perfectly acceptable, but you know what
fixes that? People who care about it actually *working* on it.
Complaining about it doesn't help anyone!
You're right in theory, and probably also in practice. However, as a
skeptical and pessimistic by nature (and by
Should I report as a bug the fact that using %apply_patches (from
/usr/lib/rpm/macros) instead of the list of patches, one per line, makes
rpmlint complain that W: patch-not-applied ?
Thx,
R-C aka beranger
*Not* related to
https://www.mageia.org/pipermail/mageia-dev/20110211/002535.html
but related to
http://mageia.org/wiki/doku.php?id=packaging_hints
which says
filetriggers: mageia has filetriggers, don't put needless stuff in %post.
can the experinced Mageia packagers confirm me that:
--
can the experinced Mageia packagers confirm me that:
-- desktop-file-install / desktop-file-validate is *not* needed in Mageia? (I
can validate with rpmlint)
-- gtk-update-icon-cache is *not* needed in Mageia?
-- scrollkeeper is *not* needed in Mageia?
-- BuildRequires:
Sorry for polluting the whole list, but as I don't have a mentor...
This is the first time I'm building 64-bit packages, and I'm running into the
following issue.
Requirements such as:
BuildRequires: qt4-devel
BuildRequires: python-devel
expand very well (automatically) on 64-bit into:
That's why there was discussion started, some time ago, in this list, to
create devel packages so that they will provide %{name}-devel and
lib%{name}-deve.
http://comments.gmane.org/gmane.linux.mageia.devel/6365
It isn't clear to me whether the situation to be fixed is Mageia-specific
Why not `lib64ksane-devel` ?
You are right, the package name libksane-devel is incorrect. See
http://www.mageia.org/wiki/doku.php?id=libraries
Thanks for the pointer, Christiaan!
OTOH, as a self-apprentice packager, I've collected a number of pages to help
me with understanding the
I suggest to obsolete the 4.6.4 versions of
task-kde4
task-kde4-minimal
task-kde4-debug
as to match the new package fragmentation of KDE 4.6.90.
(Just removing them orphans packages, and unorphaning them is annoying.)
I am already cursing the whole KDE f*ing team for the new fragmentation,
Well MacOS X Lion is probably the way to go :)
mikala, I would rather support anal rape than to pay a single cent to Apple!
R-C
obsoletes are not the correct place for solve such problems.
ksnapshot don't have any obsoletes but a conflict (which is probably
indeed too much but was not expected to add any problem i
Sorry to bother you, but since this is both about an upgrade and a change of
package names (albeit via
For the last several days in my Cauldron KDE desktop, multiple instances of
the Available Device notification keep coming up entitled Coherence Test
Content.
This appears to be caused by the following in /etc/coherence/coherence.conf:
plugin active=yes
nameCoherence Test Content/name
You did not look very close?
See https://bugs.kde.org/show_bug.cgi?id=220047
Yes, but no. Yes, it looks very close to dozens of KDE and downstrem/distro
bugs!
It's actually
https://bugs.kde.org/show_bug.cgi?id=268038
And it was fixed (thanks, mikala!) by releasing of
ntrack-014-3.mga2 !!!
Not so fast! :(
It's nice that you are happy. But since last updates my windows do not
have any decorations (no border, no title bar, no chance to
close/minimize/maximize), konsole window does not get focus at all,
after reboot I see all decorations for a split
Not so fast! :(
It's nice that you are happy. But since last updates my windows do not
have any decorations (no border, no title bar, no chance to
close/minimize/maximize), konsole window does not get focus at all,
after reboot I see all decorations for a split second, then they
vanish from the
It's not useless at all in fact. kdebase4-runtime was ony pulling by
internal requires lib(64)ntrack0 lib(64)ntrack-qt4
using only the « built-in noop monitor (always online).», i did not
notice only yesterday night that his package was installed locally
(ntrack binary which provides
you can reproduce it by removing with --no-deps ntrack restart your
kde session
You mean one could have been running kded4 --no-deps ntrack and experience no
CPU issues even w/o these updates?!
Geez, how would a regular user know that --no-deps ntrack was a valid
parameter?
R-C
Then I moved the complete ~/.kde4 to a backup place and restarted with
my normal user - back to the problem! :(
I will create a new normal user and then compare ~/home entries.
I'm currently experiencing a similar situation with XFCE: it's broken all of a
sudden, no titlebars, no focus in any
Due to a spec error, these packages are now in cauldron core/release:
libgcr-3_%{lib_major}-3.1.1-1.mga2.i586.rpm
and
libgck%{lib_major}-3.1.1-1.mga2.i586.rpm
R-C
It looks like the kded4 high-CPU is _not_ related to any of the following
modules:
bluedevil
desktopnotifier
device_automounter
dnssdwatcher
favicons
freespacenotifier
keyboard
khotkeys
kmixd
ksvnd
ktimezoned
kwrited
networkstatus
obexftpdaemon
powerdevil
randrmonitor
remotedirnotify
So you should disable all kded modules (from systemsettings), then log off
(or even restart to be sure no process is left running) then log back on. If
you still get high CPU from kded then ths problem is in kded itself, if not
you can start loading the modules one by one (waiting long enough
afaik ntrack, if that is a problem, why don't you try and recompile KDE
locally without ntrack? see if it improves stuff?
But _why_ is ntrack a *required* dependency of KDE as long as:
1. other distros don't have it, neither as required by KDE, nor as an
independent library;
2. It is
macro_log_feature(QNTRACK_FOUND QNtrack Network status tracking library
http://launchpad.net/ntrack;; FALSE Provides data input for Solid network
status)
We're just trying to provide our KDE with as much as functionnality as it's
possible.
OK, OK, OK (Leo Getz / Joe Pesci voice).
Some
8.6b1 is released almost 2.5 years ago, and it seems that there is no
plan pushing it into 8.6b2 or final stable release. Mandriva and
Mageia are the only distros shipping 8.6b1. I don't think it is doable
for a common distro.
Any negative ideas?
Looks like a good idea, judging by bug
ntrack is supposed to provide more information regarding connection/route
change for desktop applications such so we'll probably see
applications or developpers used it later. If we can provide by default
an environnement so developers can use it (aka no need to
recompile/add 'x' br)
One way to figure that out is to attach gdb to it while it's running and
then print a backtrace. If you do that several times, you may break in the
code
that's running a lot. But even if that works it is likely still not easy to
figure out what's going on.
Other ways to get
This is making me crazy. After upgrading to KDE 4.6.90 (cauldron, of course),
the bloody m*f*er kded4 (the worse idea in KDE4) constantly takes 55-75% CPU.
Of course, killing it is possible, but this affects the plasmoids. (E.g. it
made me inadvertently filling an invalid bug report 1981, which
The solution which worked most of the time for such issues in kde 4.6.xx was:
1. open a terminal
2. run killall plasma-desktop
3. plasma-desktop
the plasmoids and the desktop come back, and kded4 stops using that much CPU.
Last time I looked what it was looking CPU at, it was caused by
(This is making me crazy. Otherwise, I'll tell you some day about a
bug/crash that was *accidentally* fixed by KDE 4.6.90.)
Which one ? ;o)
See
https://mageia.org/pipermail/mageia-dev/2011-July/006180.html
R-C
Could it be that it is indexing all of your files?
NOPE. I never ever use indexing, no matter what the OS is.
R-C
Well only kdepim is broken so it's not a big deal if you're not using
it.
(You should be able to use akregator).
Yes, akregator works just fine.
R-C
However here killing this process does not seems to affect my plasmoids.
I'm surprised to see you writing it. After killing kded4:
1. Klipper was not reacting.
2. The keyboard layout systray icon was dead.
3. Any changes in the way the clock is displayed (hour/date format) were not
applied.
I was trying to investigate the kded4 high CPU load, and I started to
investigate some upstream reports, even if not necessarily reported for 4.6.90.
Some such reports were related to ntrack, e.g. http://bugs.kde.org/268038
What the heck is ntrack and why do we need it? (The official
I too said I need mentoring / I want to take care of some packages in mga.
In the meantime, I am on my own: http://mageia.beranger.org/mageia/
I hope we can find you a mentor as soon as possible. If any mentor is
available
for beranger, please tell ! Otherwise, please give some time to the
We will soon have a page on wiki where people can put his name on for seeking a
mentor, too.
Oh, is it not this
one?http://mageia.org/wiki/doku.php?id=packaging#list_of_registered_people
It thought it was a list for people wanting to become packagers (although some
people already are mga
Someone install version 1.0 from release. So far, so good, but he hear
that 1.1 is out, and he install it from backport ( after requesting ).
He is satisfied, then the developers of our voip software decide to
create a version 2.0, with a completely new interface but the ui is yet
unfinished and
I a not sure that most people realize they can revert. Maybe a easier
interface to do that could be offered ( along maybe with a tool that
send feedback on why it did downgrade it ? ).
that's not a bad idea, what is the best way to revert? is that with --old-
package ?
Maybe I'm
Here are some wiki page to read about mentoring process:
http://mageia.org/wiki/doku.php?id=packagings[]=mentor#packagers_organization
http://mageia.org/wiki/doku.php?id=packagings[]=mentor#resources
http://mageia.org/wiki/doku.php?id=packages_mentoring
and
(ii) myself be accepted as a contributor / package maintainer for Mandriva?
Mageia i guess :p
OMFG. (Although, to be frank, MDV's story is a sad one. Now whatever is
important seems to need to be done by Dodonov, and mdv 2011's release is
sliding, and sliding, and sliding... so much that
I'm known to be grumpy and difficult, but I also believe in simplicity as a
policy, therefore I'd like to ask you something.
By no means I want to question Ahmad's judgment, however I strongly disagree
with him on one point. As a _principle_. Otherwise, it's a tiny punctual
question, but I'd
We don't have any python2 symlink or binary on mageia.
That was not the question. The question was whether '/usr/bin/env python2'
should be patched into '/usr/bin/env python' or into '/usr/bin/python'.
The more general question was whether all the upstream packages should be
optimized.
When
Actually, I said that the shebang should be removed altogether. Which
is what was being done all those years calibre existed in the Mandriva
repos (the same for Fedora, since they do remove the shebang, as the
calibre spec was originally imported from Fedora, which I said in the
report
Also, /usr/bin/python2 doesn't exist to begin with, as mikala pointed out.
As I repointed, the question was not that one. As long as calibre has used
env with python, not python2, it worked. Now that the developer changed that,
the least intrusive way would be to just remove the 2.
I
A distro's job is not to judge the work of the _upstream_ developers as
long as this is not a real bug.
But it's to integrate software, and apply common policy to all of them.
ok, say a distro has 200 packages that use python, for a total of 20,000 *.py
files.
now what, the limited
So what I propose is that you seriously consider packaging your application
for Mageia.
We find a mentor for you to apprentice with, to familiarise you with the
process.
In choosing a mentor, it would help to find someone in the same time zone.
You're in Canada ? What time zone ?
(I'd offer to
So why does it have to be treated differently than the others since
there is nothing special about this release cycle ?
Michael, please give me an example of an application that releases on average 5
time a month. Really, give me an example.
And, like it or not, calibre is _THE_
Release frequency never was a criteria for differentiating between
pushing something to updates and something to backports.
It should be. Otherwise, we should all be using OpenOffice.org 1.0.1. --
security issues set aside.
And I see no reason why it would be in favor of doing a bug fix
Would this 'backports' repository section sound better to you if it is
renamed e.g. to 'rolling' ? (:
No, backports sounds very bad, except maybe for people coming from Mandriva.
They (you!) must love the concept.
(Oh, maybe trolling instead of rolling :-))
Let me put it this way. People
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.
I strongly believe quite the contrary.
I'd like to bring to your
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,
60 matches
Mail list logo
