Re: [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help
2012/1/3 Michael Scherer m...@zarb.org: Le lundi 02 janvier 2012 à 22:17 +0100, Maarten Vanraes a écrit : Op maandag 02 januari 2012 21:40:31 schreef Michael Scherer: Le lundi 02 janvier 2012 à 19:41 +0100, Marja van Waes a écrit : Hi everyone, Can someone please help to fix bug 1956? You don't need to be a regular forum visitor. We need someone to find and implement a probably existing MOD, needed to keep forum posts history when unlimited edit time is enabled From wobo's comment #32: Capabilities needed: Well, one could say that anybody who - knows how to run phpBB as admin and - has seen a line of php - knows how to edit code (respecting tags and such) - knows how to cutpaste should be able to install an existing MOD (if I'm not mistaken there is one or more). I know next to nothing about php coding. But I've been running a phpBB forum for a couple of years and successfully implemented some MODs in phpBB2 and phpBB3. With no help (except the phpBB-forum in case of problems). In practice you have a detailed installation README for each MOD. Like - open file /foo/bar/doo.php - Find the line which starts with '..' - After that add - . And more such step-by-step guidance My eyes start to bleed dues to such guidances. i'm sure misc means to say that we should have all our changes in packages/puppet config so that we can update without issues. and with file edits, that's a whole different thing. I was more thinking of proper patchs or better, proper modules, with files to deploy in a well know directory . I only gave a part of an example. MODs are made as enhancement to the standard software. The easiest MOD is like Michael wrote: a module with files to deploy in a well known directory. But in most cases they consist of files to copy into various directories of the program tree and changes to existing files of the software. There are other MODs which can be implemented automatically - which is far worse IMHO. This is where a modded phpBB3 could turn into a nightmare to maintain - believe me, I've been there :( Of course no developper of a MOD could know what somebody has already done to the standard files, so it's not possible do use only patches. And it could be (and that happens quite often) that a MOD is not compatible to your already modificated forum software (destroys other modifications or whatever). IMHO the best way in this case here would be a mod written for our setup, all changes well defined to make it maintainable in a proper way. Saying this I beg to think again whether the issue justifies all the time and work. -- wobo
Re: [Mageia-dev] RFC: Opening Backports (once again...)
On Sunday, 11 December 2011 19:43:35 Florian Hubold wrote: \ Whatever the decision is, maybe we could tie this to some conditions: Only allow backports if there are near-zero security/critical bugs for the stable release or if there are no open bugs for the package in question? Well, my first question is, *who* is *responsible* for security updates? This is not specified in the updates policy (the role assigned to build the security update is named 'Maintainer (or any interested packager)', but who is responsible for checking that we have all applicable updates? In Mandriva, it was the responsibility of the security team (with cooperation from the maintainer in some cases). At some stage we also need to look at providing vulnerability data in a suitable format that supports automated validation (e.g. OVAL?), and a site able to browse advisories. Just some random crazy idea ... IMHO we should focus on security and bugfixes for the stable release, and there are currently too many security bugs open, some for a really long time, where nothing is happening for months, yet we still talk and concern about opening backports. FYI: the reason I have been slow on updates for Mageia is that I still have systems running Mandriva, precisely because the bacports situation has not been finalised, and I don't want to submit all missing packages in Mageia 1 to updates. Once backports is open, I can drop some Mandriva packages, and spend more time contributing to Mageia. So, you can't necessarily say that backports steals time from updates ... Regards, Buchan
Re: [Mageia-dev] RFC: Opening Backports (once again...)
On Saturday, 10 December 2011 13:32:12 Michael Scherer wrote:
Le mardi 06 décembre 2011 à 00:56 +0200, Thomas Backlund a écrit :
Now,
here comes the question about backports once again.
We are now 6+ months into Mageia 1, and we are nowhere closer to opening
backports that we were at Mageia 1 release time.
Because of that there are 3rdparty repos popping up everywhere...,
something we hoped to avoid atleast partly when starting this project.
Well, the backport issue ( ie :
- no garantee of keep the distribution upgradable
Backports will probably provide a better probability of upgradability than
3rd-party repos.
- no security )
No means to provide a security updates that has followed a QA process in the
event package version Z no longer builds on distribution with version X in
release and version Y in backports.
But, note that without backports, users who wanted version Y would either:
-Switch to a distro that has version Y (worse) - I would guess 20%
-Switch to using cauldron, and start contributing (better) - I would guess 5%
or less
-Use Cauldron package on stable release (worse) - I would guess about 30%
-Build package from source (worse) - I would guess about 20%
-Rebuild cauldron package on stable release (same) - I wold guess about 10%
-Keep version X (better) and eventually become upset about age of software
(worse) - I would guess about 15%
So, only one outcome would be better, one would be the same, and the other 3
outcomes would be worse, and probably be the majority of outcomes.
In the case where there is no problem with providing the update, backports is
superiour, and would provide a better outcome in every case.
Do we have any idea on how many packages this ever affected in Mandriva?
have also not been fixed, so that's rather unfair to
... ?
So here is a suggestion to get some value to our endusers:
we add a backports branch on svn
So packages for backports would use:
svn.mageia.org/packages/backports/1/package/{current,pristine,releases}
and allow that to be used for backports.
Using a separate branch is also a cleaner way of providing
backports, and makes it easy to separate changes needed only
for Cauldron (or backports).
I thought the whole point of Backports was to provide a streamlined way to
provide newer versions of packages that already exist in Cauldron, with
minimal effort, to stable releases. This increases the incentive for users on
stable releases to contribute to Cauldron in some way, and doesn't increase
the burden on the maintainer significantly. There should be no need to have
distribution release-specific content in any of the packages.
In the rare case a package can't be provided like this, maybe it isn't a good
candidate for backports?
Then in practice, that mean having a 2nd/3rd distribution ( because
there is a separate 2nd svn branch, and a 3rd one for later ) and so
that's a big no for me. Having 2+ branchs is just asking for trouble
when they are not in sync ( and since keeping everything in sync
properly with svn is a pain if there is a divergence, this will not be
done ).
Worst, if we do like in mdv and propose 2 way of backporting ( submit
from cauldron, submit from a branch ), this will create a mess of having
some packages from cauldron, some from the branch, and people having no
way from knowing where does a package come from. This also make the
system harder to maintain and to follow, and rather impossible to script
properly.
So that's also to be avoided.
Having a separate branch where people can write also remove the only
incentive I have seen for backports, ie, wider testing of our packages,
because they may not really the same as in cauldron.
So here is what I propose :
- have X branchs, but do not let anyone commit on it, besides a system
user. When a package is submitted to cauldron, it is also copied to this
branch, ie, we make sure current is in sync. The same goes for version
N-1 being copied from N once a backported rpm have been submitted to be
used by people. Once a distribution is no longer supported, we close the
branch, and disable the sync.
- backports are only submitted from the branch, with separate
markrelease, tags, whatever. This let us have proper audit of backports,
and who did what.
- packagers still need to commit and submit on cauldron before any
backports. So we miss no fixes or anything by mistake. We also make sure
that cauldron is always the highest version possible, thus permitting at
least some form of upgrade. ( either stable to stable, provided
backports are used, or stable to cauldron ). And we also ensure that
backports are done first on the most recent stable version, for the same
reason ( ensure some form of upgrade path, as asked several time by
users ).
So, we have two copies of identical packages, that are always in sync, and can
never diverge.
What is the point then? Just to allow
Re: [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help
2012/1/3 Michael Scherer m...@zarb.org: [...] I was more thinking of proper patchs or better, proper modules, with files to deploy in a well know directory . I only gave a part of an example. MODs are made as enhancement to the standard software. The easiest MOD is like Michael wrote: a module with files to deploy in a well known directory. But in most cases they consist of files to copy into various directories of the program tree and changes to existing files of the software. There are other MODs which can be implemented automatically - which is far worse IMHO. This is where a modded phpBB3 could turn into a nightmare to maintain - believe me, I've been there :( /o\ Of course no developper of a MOD could know what somebody has already done to the standard files, so it's not possible do use only patches. And it could be (and that happens quite often) that a MOD is not compatible to your already modificated forum software (destroys other modifications or whatever). IMHO the best way in this case here would be a mod written for our setup, all changes well defined to make it maintainable in a proper way. Saying this I beg to think again whether the issue justifies all the time and work. +1
Re: [Mageia-dev] RFC: Opening Backports (once again...)
[...] At some stage we also need to look at providing vulnerability data in a suitable format that supports automated validation (e.g. OVAL?), and a site able to browse advisories. If this means less work, and is relatively easy to do by package maintainers, then, this looks like quite a good idea. Just some random crazy idea ... IMHO we should focus on security and bugfixes for the stable release, and there are currently too many security bugs open, some for a really long time, where nothing is happening for months, yet we still talk and concern about opening backports. FYI: the reason I have been slow on updates for Mageia is that I still have systems running Mandriva, precisely because the bacports situation has not been finalised, and I don't want to submit all missing packages in Mageia 1 to updates. Once backports is open, I can drop some Mandriva packages, and spend more time contributing to Mageia. So, you can't necessarily say that backports steals time from updates ... interesting point of view...
Re: [Mageia-dev] RFC: Opening Backports (once again...)
martedì 3 gennaio 2012 alle 10:45, Buchan Milne ha scritto: -Build package from source (worse) - I would guess about 20% -Rebuild cauldron package on stable release (same) - I wold guess about 10% IMO you're very optimistic here :) I think this is true for expert users, so the ones who started developing in mageia, or some who would like to start contributing and his status is pending waiting mentors... Non expert users will probably switch to other distros... increasing your first percentage. But we should think also about the percentage of users that would like the backports, that should be interesting, i mean if the 3% want backports loosing that percentage could be not very interesting... and we could try to be better in 2... am i wrong? Angelo (who is in favour to open bp) signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release omniorb-4.1.6-1.mga2
On 3 January 2012 14:12, barjac buildsystem-dae...@mageia.org wrote: Description : omniORB is an Object Request Broker (ORB) from ATT which implements specification 2.3 of the Common Object Request Broker Architecture (CORBA). Warning: Before release 4.0.0, it contains OmnyORBpy, now it is a separate package. This warning has nothing to do in %description and will look ugly in rpmdrake... barjac barjac 4.1.6-1.mga2: + Revision: 189858 - New version, removed static, cleaned, removed old patches, added format security patch - imported package omniorb
[Mageia-dev] External monitor resolution probing broken since this morning
Since this morning, I can't get resolutions higher than 1024*768 on my external monitor (VGA1), whereas I usuallu have 1920*1200: Screen 0: minimum 320 x 200, current 2048 x 768, maximum 8192 x 8192 LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 261mm x 163mm 1280x800 60.1 + 1024x768 60.0* 800x60060.3 56.2 640x48059.9 VGA1 connected 1024x768+1024+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x768 60.0* 800x60060.3 56.2 848x48060.0 640x48059.9 HDMI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) The only X-related change is xinput 1.5.3 - 1.5.4 this morning, but reverting didn't change anything. I didn't found any blatant error in dmesg, nor in xorg logs. Any idea ? -- BOFH excuse #296: The hardware bus needs a new token.
Re: [Mageia-dev] Significant decrease of installed packages for a minimal installation
2012/1/2 Païou pai...@free.fr: Hello, all I just did a minimal installation of Mageia 1 (with updates) (custom desktop, in the next window I uncheck all package groups, in the next window I check with X). Everything is going very well. And I have the pleasant surprise that, thanks to the updates, the number of installed packages from 732 to 636. That's what I wanted for a long time. I compared the lists of packages and found that kdm is replaced by slim. Being a naturally curious, I would like to know what causes this substitution, and in general, causing the decrease of packages.bassies Can't confirm this. I just did the same on a netbook. Custom desktop, unchecked all groups, minimal installation with X Ran updates, uninstalled orphans. Result: 756 packages, kdm installed, slim not installed. As kdm takes some dependencies with it, this change to slim is significant. Leaves the question: why do we see a different result? A small difference in the package number is surely caused by different hardware configuration, but not a difference of 100 packages. Also hardware configuration can not cause the difference concerning kdm/slim. -- wobo
Re: [Mageia-dev] Significant decrease of installed packages for a minimal installation
Le mardi 3 janvier 2012 15:40:56, Wolfgang Bornath a écrit : 2012/1/2 Païou pai...@free.fr: I just did a minimal installation of Mageia 1 (with updates) Can't confirm this. I just did the same on a netbook. Custom desktop, unchecked all groups, minimal installation with X Ran updates, uninstalled orphans. It seems you did not use the updates for the first install. So the KDM was installed, and updating does not remove it.
Re: [Mageia-dev] Significant decrease of installed packages for a minimal installation
2012/1/3 zezinho lists.jjo...@free.fr: Le mardi 3 janvier 2012 15:40:56, Wolfgang Bornath a écrit : 2012/1/2 Païou pai...@free.fr: I just did a minimal installation of Mageia 1 (with updates) Can't confirm this. I just did the same on a netbook. Custom desktop, unchecked all groups, minimal installation with X Ran updates, uninstalled orphans. It seems you did not use the updates for the first install. So the KDM was installed, and updating does not remove it. I can only run updates AFTER installation (or at the end of installation, if that works), no? -- wobo
Re: [Mageia-dev] Significant decrease of installed packages for a minimal installation
2012/1/3 Païou pai...@free.fr: I get this reduction in installed packages only if I add a mirror with the update, at the time of installation. If I do the updates later, I have the same result as you. Ah, ok, will try a net installation then, thx -- wobo
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release portaudio-19-18.mga2
On 3 January 2012 16:11, zezinho buildsystem-dae...@mageia.org wrote: zezinho zezinho 19-18.mga2: + Revision: 189952 - bump release to rebuild rebuild is enough. What is missing is rebuild for ?_WHAT_?
Re: [Mageia-dev] [packages-commits] [189967] - version upgrade
2012/1/3 r...@mageia.org:
Revision 189967 Author matteo Date 2012-01-03 16:46:56 +0100 (Tue, 03 Jan
2012)
Log Message
- version upgrade
- used macros instead of command names
Modified Paths
cauldron/x86info/current/SPECS/x86info.spec
Modified: cauldron/x86info/current/SPECS/x86info.spec
===
--- cauldron/x86info/current/SPECS/x86info.spec 2012-01-03 15:45:07 UTC
(rev
189966)
+++ cauldron/x86info/current/SPECS/x86info.spec 2012-01-03 15:46:56 UTC
(rev
189967)
@@ -1,5 +1,5 @@
%define namex86info
-%define version 1.29
+%define version 1.30
%define realver %{version}
#define cvsdate 20050420
@@ -11,7 +11,7 @@
Group: System/Kernel and hardware
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot
URL: http://www.codemonkey.org.uk/projects/x86info/
-Source0: %{name}-%{realver}%{?cvsdate:-%{cvsdate}}.tar.bz2
+Source0: %{name}-%{realver}%{?cvsdate:-%{cvsdate}}.tgz
Patch0: x86info-1.17-intel-flags.patch
Patch1: x86info-1.17-intel-caches.patch
Patch2: x86info-1.17-cpuid-with-ecx-input.patch
@@ -33,17 +33,18 @@
%setup -q -n %{name}-%{realver}
%build
-make CFLAGS=%{optflags}
+#make CFLAGS=%{optflags}
+%make
%install
-rm -rf %{buildroot}
-install -d %{buildroot}%{_bindir}
-install -d %{buildroot}%{_mandir}/man1
-install -m755 %{name} %{buildroot}%{_bindir}/
-install -m755 %{name}.1 %{buildroot}%{_mandir}/man1/
+%__rm -rf %{buildroot}
+%__install -d %{buildroot}%{_bindir}
+%__install -d %{buildroot}%{_mandir}/man1
+%__install -m755 %{name} %{buildroot}%{_bindir}/
+%__install -m755 %{name}.1 %{buildroot}%{_mandir}/man1/
I think this is pretty much opposite what everyone else is doing. IMHO
this also makes .spec harder to read.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release x86info-1.30-2.mga2
2012/1/3 matteo buildsystem-dae...@mageia.org: Name : x86info Relocations: (not relocatable) Version : 1.30 Vendor: Mageia.Org Release : 2.mga2 Build Date: Tue Jan 3 17:08:12 2012 Install Date: (not installed) Build Host: jonund Group : System/Kernel and hardware Source RPM: (none) Size : 106444 License: GPLv2 Signature : (none) Packager : matteo matteo URL : http://www.codemonkey.org.uk/projects/x86info/ Summary : Show x86 CPU information Description : Unlike other 'cpuinfo' tools which just parse /proc/cpuinfo, x86info probes the CPU registers to find out a lot more information. It can discover the contents of model-specific registers, discover CPU silicon revisions, and lots more. matteo matteo 1.30-2.mga2: + Revision: 189980 - fixed license - fixed missing make cflags - bumped release There's no need to mention release bumping in changelog. It's obvious change.
Re: [Mageia-dev] Significant decrease of installed packages for a minimal installation
zezinho lists.jjorge@... writes: Le mardi 3 janvier 2012 15:40:56, Wolfgang Bornath a écrit : 2012/1/2 Païou paiiou@...: I just did a minimal installation of Mageia 1 (with updates) Can't confirm this. I just did the same on a netbook. Custom desktop, unchecked all groups, minimal installation with X Ran updates, uninstalled orphans. It seems you did not use the updates for the first install. So the KDM was installed, and updating does not remove it. What interests me is to know what changes to allow the economy to packages. It would be interesting to also change cauldron in that direction. Maybe you have the response.
Re: [Mageia-dev] [packages-commits] [189967] - version upgrade
Le 03/01/2012 17:18, Jani Välimaa a écrit :
@@ -11,7 +11,7 @@
Group:System/Kernel and hardware
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot
URL: http://www.codemonkey.org.uk/projects/x86info/
-Source0: %{name}-%{realver}%{?cvsdate:-%{cvsdate}}.tar.bz2
+Source0: %{name}-%{realver}%{?cvsdate:-%{cvsdate}}.tgz
Patch0: x86info-1.17-intel-flags.patch
Patch1: x86info-1.17-intel-caches.patch
Patch2: x86info-1.17-cpuid-with-ecx-input.patch
@@ -33,17 +33,18 @@
%setup -q -n %{name}-%{realver}
%build
-make CFLAGS=%{optflags}
+#make CFLAGS=%{optflags}
+%make
%install
-rm -rf %{buildroot}
-install -d %{buildroot}%{_bindir}
-install -d %{buildroot}%{_mandir}/man1
-install -m755 %{name} %{buildroot}%{_bindir}/
-install -m755 %{name}.1 %{buildroot}%{_mandir}/man1/
+%__rm -rf %{buildroot}
+%__install -d %{buildroot}%{_bindir}
+%__install -d %{buildroot}%{_mandir}/man1
+%__install -m755 %{name} %{buildroot}%{_bindir}/
+%__install -m755 %{name}.1 %{buildroot}%{_mandir}/man1/
I think this is pretty much opposite what everyone else is doing. IMHO
this also makes .spec harder to read.
Morevoer, it mixes pure cosmetics changes, as some of those macros just
expand to the command itself, as install vs %__install, with behaviour
changes, as other macros expand to the command with additional
arguments, as make vs %make, which is actually make -j.
--
BOFH excuse #62:
need to wrap system in aluminum foil to fix problem
Re: [Mageia-dev] Significant decrease of installed packages for a minimal installation
Le mardi 3 janvier 2012 13:24:30, Païou a écrit : zezinho lists.jjorge@... writes: Le mardi 3 janvier 2012 15:40:56, Wolfgang Bornath a écrit : 2012/1/2 Païou paiiou@...: I just did a minimal installation of Mageia 1 (with updates) Can't confirm this. I just did the same on a netbook. Custom desktop, unchecked all groups, minimal installation with X Ran updates, uninstalled orphans. It seems you did not use the updates for the first install. So the KDM was installed, and updating does not remove it. What interests me is to know what changes to allow the economy to packages. It would be interesting to also change cauldron in that direction. Maybe you have the response. the result of the -debug during installation might help to understand why slim is preferred over kdm, but i guess kdm was installed initially simply because a dm was needed slim not available on the iso. -- Balcaen John Jabber-ID: mik...@jabber.littleboboy.net
Re: [Mageia-dev] Significant decrease of installed packages for a minimal installation
2012/1/3 Balcaen John mik...@mageia.org: Le mardi 3 janvier 2012 13:24:30, Païou a écrit : zezinho lists.jjorge@... writes: Le mardi 3 janvier 2012 15:40:56, Wolfgang Bornath a écrit : 2012/1/2 Païou paiiou@...: I just did a minimal installation of Mageia 1 (with updates) Can't confirm this. I just did the same on a netbook. Custom desktop, unchecked all groups, minimal installation with X Ran updates, uninstalled orphans. It seems you did not use the updates for the first install. So the KDM was installed, and updating does not remove it. What interests me is to know what changes to allow the economy to packages. It would be interesting to also change cauldron in that direction. Maybe you have the response. the result of the -debug during installation might help to understand why slim is preferred over kdm, but i guess kdm was installed initially simply because a dm was needed slim not available on the iso. Yes, must be. In my second try I added a ftp server as additional source (somewhere in the beginning of the installation), now slim was installed instead of kdm. Number of packages now matches with Païou's results. After adding wifi dkms (including the kernel-devel and others), vlc, chromium-browser (+flash-player plugin) and mc I ended up with a nice little machine for being on the road (1.1Gb, 758 packages). Mission accomplished :) -- wobo
Re: [Mageia-dev] External monitor resolution probing broken since this morning
On 03.01.2012 16:39, Guillaume Rousse wrote: Since this morning, I can't get resolutions higher than 1024*768 on my external monitor (VGA1), whereas I usuallu have 1920*1200: Screen 0: minimum 320 x 200, current 2048 x 768, maximum 8192 x 8192 LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 261mm x 163mm 1280x800 60.1 + 1024x768 60.0* 800x60060.3 56.2 640x48059.9 VGA1 connected 1024x768+1024+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x768 60.0* 800x60060.3 56.2 848x48060.0 640x48059.9 HDMI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) The only X-related change is xinput 1.5.3 - 1.5.4 this morning, but reverting didn't change anything. I didn't found any blatant error in dmesg, nor in xorg logs. Any idea ? Does the Xorg.0.log contain a modelist and/or raw EDID data? If so, do those look correct? (you can use e.g. monitor-parse-edid or just paste here) -- Anssi Hannula
Re: [Mageia-dev] [soft-commits] [2237] disable nvidia173 and nvidia96xx as they do not support X. org server 1.11)
On 2 December 2011 19:35, r...@mageia.org wrote: Revision 2237 Author anssi Date 2011-12-02 19:35:53 +0100 (Fri, 02 Dec 2011) Log Message disable nvidia173 and nvidia96xx as they do not support X.org server 1.11) Err... you only altered some of the nvidia96xx entries: $ grep nvidia96xx ../ldetect-lst/lst//Cards+ -B3 NAME NVIDIA GeForce 2 MX to GeForce 4 DRIVER nouveau #DRIVER2 nvidia96xx (not compatible with X.org server 1.11) -- NAME NVIDIA GeForce 6100 to GeForce 360 DRIVER nouveau DRIVER2 nvidia-current DRIVER2_NO_SSE nvidia96xx -- NAME NVIDIA GeForce 400 series and later DRIVER nouveau DRIVER2 nvidia-current DRIVER2_NO_SSE nvidia96xx Modified: ldetect-lst/trunk/lst/Cards+ === --- ldetect-lst/trunk/lst/Cards+ 2011-12-02 16:46:06 UTC (rev 2236) +++ ldetect-lst/trunk/lst/Cards+ 2011-12-02 18:35:53 UTC (rev 2237) @@ -260,11 +260,11 @@ NAME NVIDIA GeForce 2 MX to GeForce 4 DRIVER nouveau -DRIVER2 nvidia96xx +#DRIVER2 nvidia96xx (not compatible with X.org server 1.11) NAME NVIDIA GeForce FX series DRIVER nouveau -DRIVER2 nvidia173 +#DRIVER2 nvidia173 (not compatible with X.org server 1.11) NAME NVIDIA GeForce 6100 to GeForce 360 DRIVER nouveau
Re: [Mageia-dev] [soft-commits] [2237] disable nvidia173 and nvidia96xx as they do not support X. org server 1.11)
On 03.01.2012 19:17, Thierry Vignaud wrote: On 2 December 2011 19:35, r...@mageia.org wrote: Revision 2237 Author anssi Date 2011-12-02 19:35:53 +0100 (Fri, 02 Dec 2011) Log Message disable nvidia173 and nvidia96xx as they do not support X.org server 1.11) Err... you only altered some of the nvidia96xx entries: $ grep nvidia96xx ../ldetect-lst/lst//Cards+ -B3 NAME NVIDIA GeForce 2 MX to GeForce 4 DRIVER nouveau #DRIVER2 nvidia96xx (not compatible with X.org server 1.11) -- NAME NVIDIA GeForce 6100 to GeForce 360 DRIVER nouveau DRIVER2 nvidia-current DRIVER2_NO_SSE nvidia96xx -- NAME NVIDIA GeForce 400 series and later DRIVER nouveau DRIVER2 nvidia-current DRIVER2_NO_SSE nvidia96xx Hmm, I guess we should make drakx-kbd-mouse-x11 not suggest nvidia173 or nvidia-current on non-SSE then, or add a new flag DRIVER2_NEEDS_SSE... Modified: ldetect-lst/trunk/lst/Cards+ === --- ldetect-lst/trunk/lst/Cards+ 2011-12-02 16:46:06 UTC (rev 2236) +++ ldetect-lst/trunk/lst/Cards+ 2011-12-02 18:35:53 UTC (rev 2237) @@ -260,11 +260,11 @@ NAME NVIDIA GeForce 2 MX to GeForce 4 DRIVER nouveau -DRIVER2 nvidia96xx +#DRIVER2 nvidia96xx (not compatible with X.org server 1.11) NAME NVIDIA GeForce FX series DRIVER nouveau -DRIVER2 nvidia173 +#DRIVER2 nvidia173 (not compatible with X.org server 1.11) NAME NVIDIA GeForce 6100 to GeForce 360 DRIVER nouveau -- Anssi Hannula
Re: [Mageia-dev] [soft-commits] [2237] disable nvidia173 and nvidia96xx as they do not support X. org server 1.11)
On 3 January 2012 18:21, Anssi Hannula an...@mageia.org wrote: disable nvidia173 and nvidia96xx as they do not support X.org server 1.11) Err... you only altered some of the nvidia96xx entries: $ grep nvidia96xx ../ldetect-lst/lst//Cards+ -B3 NAME NVIDIA GeForce 2 MX to GeForce 4 DRIVER nouveau #DRIVER2 nvidia96xx (not compatible with X.org server 1.11) -- NAME NVIDIA GeForce 6100 to GeForce 360 DRIVER nouveau DRIVER2 nvidia-current DRIVER2_NO_SSE nvidia96xx -- NAME NVIDIA GeForce 400 series and later DRIVER nouveau DRIVER2 nvidia-current DRIVER2_NO_SSE nvidia96xx Hmm, I guess we should make drakx-kbd-mouse-x11 not suggest nvidia173 or nvidia-current on non-SSE then, or add a new flag DRIVER2_NEEDS_SSE... Fine with a new flag. See this untested patch sse.diff Description: Binary data sse.diff Description: Binary data
Re: [Mageia-dev] Significant decrease of installed packages for a minimal installation
Op dinsdag 03 januari 2012 15:59:31 schreef Wolfgang Bornath: 2012/1/3 zezinho lists.jjo...@free.fr: Le mardi 3 janvier 2012 15:40:56, Wolfgang Bornath a écrit : 2012/1/2 Païou pai...@free.fr: I just did a minimal installation of Mageia 1 (with updates) Can't confirm this. I just did the same on a netbook. Custom desktop, unchecked all groups, minimal installation with X Ran updates, uninstalled orphans. It seems you did not use the updates for the first install. So the KDM was installed, and updating does not remove it. I can only run updates AFTER installation (or at the end of installation, if that works), no? maybe on installation he added in the media window the mirrorlisted entries? and thus the updates are being used when installing?
Re: [Mageia-dev] ANN: gcc-4.6.2 landing on Cauldron
I'm quoting the whole message just to remind it to others. W dniu 05.12.2011 15:26, Thomas Backlund pisze: Hi, so... the long wait is over I've submitted gcc-4.6.2-1.mga2 to core/release now. As soon as it's available on the primary mirror I'll invalidate the cauldron chroots on the BS to make sure the new gcc is used. Ater that I'll submit a new glibc and kernel so they are built with the new toolchain. So, we now have glibc the toolchain upgraded: - glibc is at 2.14.1 (available in cauldron since 2011-10-24) - binutils 2.22 (available in cauldron since 2011-11-28) - gcc-4.6.2 (available later today (2011-12-05) Now, in order to provide a very good Mageia 2, every package should be rebuilt with the new toolchain/glibc in order to make sure they still build _and_ work correctly (and flush out any bugs in the toolchain) Now this rebuild should be done preferably in BR order when possible, to rule out bad interaction between packages and be preferably be fully done by alpha3 or beta1 at the latest so we have time to fix it properly for Mageia 2. Are we also talking about non-C++ or even plain-text only packages? Does every package means *really every*? -- Thomas
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release portaudio-19-18.mga2
Le mardi 3 janvier 2012 16:48:54, Thierry Vignaud a écrit : - bump release to rebuild rebuild is enough. What is missing is rebuild for ?_WHAT_? Ok, I will put it next time. It is rebuild for new libc
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release portaudio-19-18.mga2
W dniu 03.01.2012 21:23, zezinho pisze: Le mardi 3 janvier 2012 16:48:54, Thierry Vignaud a écrit : - bump release to rebuild rebuild is enough. What is missing is rebuild for ?_WHAT_? Ok, I will put it next time. It is rebuild for new libc You can reedit the svn:log entry svn pe --revprop -rrevision svn:log svn+ssh://svn.mageia.org/svn/packages --editor-cmd nano
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2
On 02.01.2012 12:21, guillomovitch wrote: Name: dsniff Relocations: (not relocatable) Version : 2.4 Vendor: Mageia.Org Release : 0.b1.1.mga2 Build Date: Mon Jan 2 11:18:17 2012 Install Date: (not installed) Build Host: ecosse Group : MonitoringSource RPM: (none) Size: 210074 License: BSD Signature : (none) Packager: guillomovitch guillomovitch URL : http://www.monkey.org/~dugsong/dsniff/ Summary : Network audit tools Description : Tools to audit network and to demonstrate the insecurity of cleartext network protocols. Please do not abuse this software. guillomovitch guillomovitch 2.4-0.b1.1.mga2: + Revision: 189630 - drop epoch, we don't care about updating from mdv anymore We don't? Previous upgraders like me still have dsniff-2.4-0.b2.14mdv2010.1 on their MGA1 / cauldron systmes, which won't get upgraded to the MGA package without epoch. IMHO the epoch should be added. Also, not your fault but it seems genhdlist didn't handle the removal of epoch without altering rpm file name well, hdlists still show the epoch, causing urpmi to try upgrading to the now epoch-less version, causing the transaction to be rejected by rpm. -- Anssi Hannula
Re: [Mageia-dev] Emails
Am 02.01.2012 17:57, schrieb Pascal Terjan: On Mon, Jan 2, 2012 at 16:39, Balcaen John mik...@mageia.org wrote: Le lundi 2 janvier 2012 13:34:05, Pascal Terjan a écrit : Sorry, sent it initially to the wrong mailing list. Following a little change last night: - Packager field of rpms is now login login (for example pterjan pterjan) - Mails on changelog email are from login buildsystem-dae...@mageia.org - You should receive an email when a package you submitted fails to build Only when it failed to build or also when it was rejected by the BS ? Iurt only sends on build failure I think youri should send it on reject but I did not check if it works Still awesome change, thanks :)
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release portaudio-19-18.mga2
Le mardi 3 janvier 2012 21:25:54, Kamil Rytarowski a écrit : You can reedit the svn:log entry svn pe --revprop -rrevision svn:log svn+ssh://svn.mageia.org/svn/packages --editor-cmd nano Learned! Thanks...
Re: [Mageia-dev] Emails
On 03.01.2012 23:41, Florian Hubold wrote: Am 02.01.2012 17:57, schrieb Pascal Terjan: On Mon, Jan 2, 2012 at 16:39, Balcaen John mik...@mageia.org wrote: Le lundi 2 janvier 2012 13:34:05, Pascal Terjan a écrit : Sorry, sent it initially to the wrong mailing list. Following a little change last night: - Packager field of rpms is now login login (for example pterjan pterjan) - Mails on changelog email are from login buildsystem-dae...@mageia.org - You should receive an email when a package you submitted fails to build Only when it failed to build or also when it was rejected by the BS ? Iurt only sends on build failure I think youri should send it on reject but I did not check if it works Still awesome change, thanks :) Seems emi sends youri-submit failures (rejections), and it seems to work as well. -- Anssi Hannula
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release portaudio-19-18.mga2
Am 03.01.2012 23:39, schrieb zezinho: Le mardi 3 janvier 2012 21:25:54, Kamil Rytarowski a écrit : You can reedit the svn:log entry svn pe --revprop -rrevision svn:log svn+ssh://svn.mageia.org/svn/packages --editor-cmd nano Learned! Thanks... Given that all packagers need a working ssh setup (check https://wiki.mageia.org/en/Packagers_ssh#How_it_works ) you can omit the svn+ssh://svn.mageia.org/svn/packages part, and set EDITOR environment var in ~/.bashrc to your favorite editor, and then for better reusability via bash recursive search (ctrl+r) maybe just use svn pe --revprop svn:log -rrevision inside a local checkout so that when you reuse it, less keystrokes required to launch this for another revision. HTH
[Mageia-dev] comments in rpm changelog (was: gamin-0.1.10-8.mga2)
On 04.01.2012 00:56, anssi wrote: anssi anssi 0.1.10-8.mga2: + Revision: 190205 - fix intermittent gam_server deadlock causing e.g. KDE applications to no longer start (fix-deadlock.patch, submitted upstream as gnome $ svn propget --revprop svn:log -r 190205 svn+ssh://svn.mageia.org/svn/packages - fix intermittent gam_server deadlock causing e.g. KDE applications to no longer start (fix-deadlock.patch, submitted upstream as gnome #667230) Isn't this wrong, i.e. the #667230) shouldn't be removed as a comment? Or has it always been there, just only affecting lines whose first non-whitespace character is '#'? -- Anssi Hannula
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release gamin-0.1.10-8.mga2
On Tue, Jan 03, 2012 at 11:56:14PM +0100, anssi wrote: + Revision: 190205 - fix intermittent gam_server deadlock causing e.g. KDE applications to no longer start (fix-deadlock.patch, submitted upstream as gnome Which upstream bug is that? -- Regards, Olav
Re: [Mageia-dev] comments in rpm changelog
Am 04.01.2012 00:26, schrieb Anssi Hannula: On 04.01.2012 00:56, anssi wrote: anssi anssi 0.1.10-8.mga2: + Revision: 190205 - fix intermittent gam_server deadlock causing e.g. KDE applications to no longer start (fix-deadlock.patch, submitted upstream as gnome $ svn propget --revprop svn:log -r 190205 svn+ssh://svn.mageia.org/svn/packages - fix intermittent gam_server deadlock causing e.g. KDE applications to no longer start (fix-deadlock.patch, submitted upstream as gnome #667230) Isn't this wrong, i.e. the #667230) shouldn't be removed as a comment? Or has it always been there, just only affecting lines whose first non-whitespace character is '#'? Latter seems the case, all other #bug mentions (which in all cases i've seen so far have something before the #) seem to not be stripped.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release gamin-0.1.10-8.mga2
Am 04.01.2012 00:36, schrieb Olav Vitters: On Tue, Jan 03, 2012 at 11:56:14PM +0100, anssi wrote: + Revision: 190205 - fix intermittent gam_server deadlock causing e.g. KDE applications to no longer start (fix-deadlock.patch, submitted upstream as gnome Which upstream bug is that? 667230. See the other mail comments in rpm changelog (was: gamin-0.1.10-8.mga2) ;)
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release gamin-0.1.10-8.mga2
On Wed, Jan 04, 2012 at 12:43:17AM +0100, Florian Hubold wrote: Am 04.01.2012 00:36, schrieb Olav Vitters: On Tue, Jan 03, 2012 at 11:56:14PM +0100, anssi wrote: + Revision: 190205 - fix intermittent gam_server deadlock causing e.g. KDE applications to no longer start (fix-deadlock.patch, submitted upstream as gnome Which upstream bug is that? 667230. See the other mail comments in rpm changelog (was: gamin-0.1.10-8.mga2) ;) read other mailing lists before hitting reply?!? :P -- Regards, Olav
Re: [Mageia-dev] GNOME 2 panel applets
On Mon, Jan 02, 2012 at 05:15:34PM -0500, andre999 wrote: I followed the link in the bug report, to various other links. Cool! Thanks for the detailed answer. Not really a GNOME 2 specific project then, so seems fine. Reporter went on to suggest MATE :P (IMO, crazy) -- Regards, Olav
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release dsniff-2.4-0.b1.1.mga2
On Tue, Jan 3, 2012 at 21:05, Anssi Hannula an...@mageia.org wrote: On 02.01.2012 12:21, guillomovitch wrote: Name : dsniff Relocations: (not relocatable) Version : 2.4 Vendor: Mageia.Org Release : 0.b1.1.mga2 Build Date: Mon Jan 2 11:18:17 2012 Install Date: (not installed) Build Host: ecosse Group : Monitoring Source RPM: (none) Size : 210074 License: BSD Signature : (none) Packager : guillomovitch guillomovitch URL : http://www.monkey.org/~dugsong/dsniff/ Summary : Network audit tools Description : Tools to audit network and to demonstrate the insecurity of cleartext network protocols. Please do not abuse this software. guillomovitch guillomovitch 2.4-0.b1.1.mga2: + Revision: 189630 - drop epoch, we don't care about updating from mdv anymore We don't? Previous upgraders like me still have dsniff-2.4-0.b2.14mdv2010.1 on their MGA1 / cauldron systmes, which won't get upgraded to the MGA package without epoch. IMHO the epoch should be added. Also, not your fault but it seems genhdlist didn't handle the removal of epoch without altering rpm file name well, hdlists still show the epoch, causing urpmi to try upgrading to the now epoch-less version, causing the transaction to be rejected by rpm. Yes genhdlist2 only considers the filename to decide if a package was added/removed, and keeps the header if filename didn't change
Re: [Mageia-dev] comments in rpm changelog
On 04.01.2012 01:41, Florian Hubold wrote: Am 04.01.2012 00:26, schrieb Anssi Hannula: On 04.01.2012 00:56, anssi wrote: anssi anssi 0.1.10-8.mga2: + Revision: 190205 - fix intermittent gam_server deadlock causing e.g. KDE applications to no longer start (fix-deadlock.patch, submitted upstream as gnome $ svn propget --revprop svn:log -r 190205 svn+ssh://svn.mageia.org/svn/packages - fix intermittent gam_server deadlock causing e.g. KDE applications to no longer start (fix-deadlock.patch, submitted upstream as gnome #667230) Isn't this wrong, i.e. the #667230) shouldn't be removed as a comment? Or has it always been there, just only affecting lines whose first non-whitespace character is '#'? Latter seems the case, all other #bug mentions (which in all cases i've seen so far have something before the #) seem to not be stripped. Indeed the above holds true at least on rpm-4.8.1 of mga1, I didn't test further back, though. -- Anssi Hannula
Re: [Mageia-dev] [packages-commits] [190229] new version 2.5.0
2012/1/3 r...@mageia.org: Revision 190229 Author fwang Date 2012-01-04 02:11:16 +0100 (Wed, 04 Jan 2012) Log Message new version 2.5.0 Modified Paths cauldron/digikam/current/SOURCES/sha1.lst cauldron/digikam/current/SPECS/digikam.spec [...] Just in case digikam won't build until https://bugs.kde.org/show_bug.cgi?id=287772 is fixed, maybe you can help here ? -- Balcaen John Jabber-id: mik...@jabber.littleboboy.net
Re: [Mageia-dev] [soft-commits] [2237] disable nvidia173 and nvidia96xx as they do not support X. org server 1.11)
on Wed, 4 Jan 2012 04:17 in the Usenet newsgroup gmane.linux.mageia.devel Thierry Vignaud wrote: On 2 December 2011 19:35, root- odjjhxpcy38dnm+yrof...@public.gmane.org wrote: Revision 2237 Author anssi Date 2011-12-02 19:35:53 +0100 (Fri, 02 Dec 2011) Log Message disable nvidia173 and nvidia96xx as they do not support X.org server 1.11) Err... you only altered some of the nvidia96xx entries: $ grep nvidia96xx ../ldetect-lst/lst//Cards+ -B3 NAME NVIDIA GeForce 2 MX to GeForce 4 DRIVER nouveau #DRIVER2 nvidia96xx (not compatible with X.org server 1.11) -- NAME NVIDIA GeForce 6100 to GeForce 360 DRIVER nouveau DRIVER2 nvidia-current DRIVER2_NO_SSE nvidia96xx -- NAME NVIDIA GeForce 400 series and later DRIVER nouveau DRIVER2 nvidia-current DRIVER2_NO_SSE nvidia96xx Modified: ldetect-lst/trunk/lst/Cards+ === --- ldetect-lst/trunk/lst/Cards+ 2011-12-02 16:46:06 UTC (rev 2236) +++ ldetect-lst/trunk/lst/Cards+ 2011-12-02 18:35:53 UTC (rev 2237) @@ -260,11 +260,11 @@ NAME NVIDIA GeForce 2 MX to GeForce 4 DRIVER nouveau -DRIVER2 nvidia96xx +#DRIVER2 nvidia96xx (not compatible with X.org server 1.11) NAME NVIDIA GeForce FX series DRIVER nouveau -DRIVER2 nvidia173 +#DRIVER2 nvidia173 (not compatible with X.org server 1.11) NAME NVIDIA GeForce 6100 to GeForce 360 DRIVER nouveau Ahh. I just started playing with 96xx updates on a GeForce 2 MX machine. Can't make it work. I'll try again later... -- sig goes here... blind Pete
Re: [Mageia-dev] [packages-commits] [190229] new version 2.5.0
On Tuesday, January 03, 2012 07:06:05 PM John Balcaen wrote: 2012/1/3 r...@mageia.org: Revision 190229 Author fwang Date 2012-01-04 02:11:16 +0100 (Wed, 04 Jan 2012) Log Message new version 2.5.0 Modified Paths cauldron/digikam/current/SOURCES/sha1.lst cauldron/digikam/current/SPECS/digikam.spec [...] Just in case digikam won't build until https://bugs.kde.org/show_bug.cgi?id=287772 is fixed, maybe you can help here ? Maybe this will motivate the developer of digikam to fix a nice program and make it usable again. It has had some problems for much too long that haven't gotten fixed. -- Best regards Thomas Spuhler
