Re: [Mageia-dev] ANN: gcc-4.6.2 landing on Cauldron
On 05/12/11 15:26, Thomas Backlund wrote: Hi, so... the long wait is over I've submitted gcc-4.6.2-1.mga2 to core/release now. Hi, I have some package not recompiling due to missing libquadmath. Gfortran actually fails to compile program with this error: gfortran -g -DLin blabla.o -o blabla /usr/bin/ld: cannot find -lquadmath collect2: ld returned 1 exit status As far as I can check, I do not find anymore the libquadmath package. Any idea? Cheers, Chris.
Re: [Mageia-dev] RFC: Opening Backports (once again...)
Op dinsdag 06 december 2011 00:29:03 schreef Anssi Hannula: > On 06.12.2011 00:56, Thomas Backlund wrote: > > Now, > > > > here comes the question about backports once again. [...] > > 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). > > Hm, how does this help with enabling backports (i.e. compared to simply > using cauldron repo)? not sure, but i thought the problem we're facing now was that submitting from cauldron to backports was a "problem" in security scripting, ie: not being able to specify 2 sources? than this would solve that problem?
Re: [Mageia-dev] [RFC] nouveau, swrastg, libdri-drivers-experimental
On 05.12.2011 13:46, Thierry Vignaud wrote: > On 5 December 2011 07:09, Anssi Hannula wrote: >> Hi! >> However, actually only swrast_dri.so is used, so should we: >> 1) switch to swrastg, drop swrast (Fedora in Nov 2010) > > I would go for this > swrast is unmaintained (in fact I think it has been dropped from trunk?) > only swrastg got fixes these days I don't know about its maintainership status, but swrast hasn't been dropped from git master from what I can see. -- Anssi Hannula
Re: [Mageia-dev] Unable to boot into kernel-3.1.3
On Friday, December 02, 2011 05:15:03 am Colin Guthrie wrote: > 'Twas brillig, and Kira at 02/12/11 11:24 did gyre and gimble: > > 在 Fri, 02 Dec 2011 18:44:32 +0800, Colin Guthrie > > > > 寫道: > >> Actually I didn't really need it in the end, I should have spotted the > >> problem without it, but it did make me go through the motions. > >> > >> It was a simple variable name typo. > >> > >> I've submitted a new version, please wait for dracut-013-5.mga2 and > >> regenerate, test, yada, yada, and let me know how you get on. > >> > >> Col > > > > No, it didn't work. > > Well it kinda worked - at least it's actually trying to mount /usr now! > > > Error message: device node not found > > > > dracut Warning: e2fsck returned with 16 > > dracut Warning: *** An error occurred during the file system check. > > dracut Warning: *** Dropping yo to a shell: the system will try > > dracut Warning: *** to mount the filesystem(s), when you leave the shell > > OK, so according to man e2fsck exit code 16 is "Usage or syntax error" > > I think this is due to using UUID=. > > I'll work on a fix for the next round of testing :D > > Col The new kernel 3.1.4-desktop-2.mga2 works/boots Maybe something went wrong during the installation process. But i get: WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. -- Thomas
Re: [Mageia-dev] ANN: gcc-4.6.2 landing on Cauldron
On Mon, 05 Dec 2011 16:26:36 +0200 Thomas Backlund wrote: > Hi, > > so... the long wait is over > > I've submitted gcc-4.6.2-1.mga2 to core/release now. > Ahhrghhh ! Now that I was going to send a message to tell that a new CUDA toolkit is available supporting gcc-4.5, we go for 4.6... I suppose life is hard... Could you consider keeping gcc-4.5 packages in the distro, adding some suffix for binaries, to have them installable in parallel with 4.6 ? Damn CUDA is always one step behind GCC, so with an up to date distro like Mageia, CUDA is unusable. Now there is a CUDA 4.1-RC that supports gcc 4.5. I think it should not be difficult for CUDA to support 4.6, the big jump was from 4.4 to 4.5 due to some change in binary format making cuda-gdb useless, but if they did that already... Anyways, havin an nvidia-cuda-gcc package with the version of the compiler cuda needs would very nice...
Re: [Mageia-dev] RFC: Opening Backports (once again...)
On 06.12.2011 00:56, Thomas Backlund wrote:
>
> 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.
>
> And at current rate we will probably release Mageia "infinity"
> before backports is opened.
>
>
> It has been delayed because of needed infrastructure changes,
> something no-one have had time to do so far...
>
> I know there is "only some coding missing" and "someone should
> do it", buth truthfully there are only a few that knows the
> code used in the buildsystem enough to actually make it happend,
> and they are already othervise busy or overloaded...
> (this is no rant against them, as all here are using their
> personal free time to help out)
The biggest problem for me is that it is really difficult to test any
changes, one'd need a mockup of the whole buildsystem... and I don't
want to propose any patches blind :)
> And to be honest I dont see that changing anytime soon...
>
>
> 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//{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).
Hm, how does this help with enabling backports (i.e. compared to simply
using cauldron repo)?
Anyway, would the above branch work like this:
e.g. lets imagine I want to, in order:
1. provide foobar 1.1 to backports.
2. cauldron foobar upgraded to 1.2, some patches added, some removed,
and other changes
3. provide foobar 1.2 to backports
4. 1.3 to cauldron and backports
To backport foobar 1.1, I guess I'd simply do
svn copy svn+ssh://svn.mageia.org/svn/packages/cauldron/foobar \
svn+ssh://svn.mageia.org/svn/packages/backports/1/foobar
and then the submit command.
When time comes to provide foobar 1.2 to backports, the options are:
Option 1:
svn del svn+ssh://svn.mageia.org/svn/packages/backports/1/foobar
svn copy svn+ssh://svn.mageia.org/svn/packages/cauldron/foobar \
svn+ssh://svn.mageia.org/svn/packages/backports/1/foobar
and submit. Changelog is the same as in cauldron.
Option 2:
svn checkout \
svn+ssh://svn.mageia.org/svn/packages/backports/1/foobar/current \
foobar
cd foobar && svn merge -r prevrev:HEAD \
svn+ssh://svn.mageia.org/svn/packages/cauldron/foobar/current
svn commit
# copy all the log entries from the cauldron interval to the log msg
and submit.
Note: results in broken changelogs unless one does manual
markreleases, but changelogs are already broken both in mga1 updates
and in cauldron (youri issue [1]). This is more notable here, though,
as backports happen generally more often multiple times than updates.
Repeat with 1.3.
Correct?
[1] https://bugs.mageia.org/show_bug.cgi?id=2633
--
Anssi Hannula
Re: [Mageia-dev] ANN: gcc-4.6.2 landing on Cauldron
05.12.2011 16:26, Thomas Backlund skrev: 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. New gcc-4.6.2-1.mga2, glibc-2.14.1-3.mga2, kernel-3.1.4-2.mga2 are now on the mirrors. -- Thomas
Re: [Mageia-dev] RFC: Opening Backports (once again...)
Op maandag 05 december 2011 23:56:25 schreef Thomas Backlund: [...] > 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). agreed
[Mageia-dev] RFC: Opening Backports (once again...)
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.
And at current rate we will probably release Mageia "infinity"
before backports is opened.
It has been delayed because of needed infrastructure changes,
something no-one have had time to do so far...
I know there is "only some coding missing" and "someone should
do it", buth truthfully there are only a few that knows the
code used in the buildsystem enough to actually make it happend,
and they are already othervise busy or overloaded...
(this is no rant against them, as all here are using their
personal free time to help out)
And to be honest I dont see that changing anytime soon...
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//{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).
--
Thomas
Re: [Mageia-dev] [177078] Add README.urpmi to note that apache needs to be running
done
Op maandag 05 december 2011 22:15:59 schreef Anssi Hannula:
> On 05.12.2011 22:54, r...@mageia.org wrote:
> > Revision
> >
> > 177078
> >
> > Author
> >
> > alien
> >
> > Date
> >
> > 2011-12-05 21:54:54 +0100 (Mon, 05 Dec 2011)
> >
> > Log Message
> >
> > Add README.urpmi to note that apache needs to be running
>
> Plese use README.install.urpmi instead, otherwise the message will be
> shown on every upgrade.
>
> See
> https://wiki.mageia.org/en/Packagers_RPM_tutorial#Interaction_with_urpmi_an
> d_rpmdrake
>
> > Modified Paths
> >
> > * cauldron/urpmi-proxy/current/SPECS/urpmi-proxy.spec
> >
> > <#cauldronurpmiproxycurrentSPECSurpmiproxyspec>
> >
> > Modified: cauldron/urpmi-proxy/current/SPECS/urpmi-proxy.spec
> > ===
> > --- cauldron/urpmi-proxy/current/SPECS/urpmi-proxy.spec 2011-12-05
> > 20:44:07 UTC (rev 177077) +++
> > cauldron/urpmi-proxy/current/SPECS/urpmi-proxy.spec 2011-12-05
20:54:54
> > UTC (rev 177078) @@ -1,6 +1,6 @@
> >
> > Name: urpmi-proxy
> > Version: 0.2.4
> >
> > -Release: %mkrel 1
> > +Release: %mkrel 2
> >
> > Summary: A proxy for urpmi repository mirrors
> > Group: System/Configuration/Packaging
> > License: GPLv2+
> >
> > @@ -22,7 +22,7 @@
> >
> > extra repository so you can provide extra or modified packages.
> >
> > %files
> >
> > -%doc README AUTHORS TODO INSTALL LICENSE
> > +%doc README AUTHORS TODO INSTALL LICENSE README.urpmi
> >
> > %attr(0750,apache,apache) %dir %{_var}/cache/urpmi-proxy
> > %attr(0750,apache,apache) %config(noreplace) %{_var}/log/urpmi-proxy.log
> > %attr(0750,root,apache) %dir %{_datadir}/urpmi-proxy
> >
> > @@ -37,6 +37,17 @@
> >
> > %build
> >
> > +cat > README.urpmi < > +
> > +NOTE: urpmi-proxy functions as an apache webapp, so apache service will
> > have +to be started for urpmi-proxy to work, if apache is now installed
> > as a +dependency, chances are high that it's not yet running, even
> > though it's +installed. you can start apache with:
> > +
> > + /etc/init.d/httpd start
> > +
> > +EOF
> > +
> >
> > %install
> > rm -fr %{buildroot}
> > %{__mkdir_p} %{buildroot}%{_var}/cache/urpmi-proxy
Re: [Mageia-dev] [177078] Add README.urpmi to note that apache needs to be running
On 05.12.2011 22:54, r...@mageia.org wrote:
> Revision
> 177078
> Author
> alien
> Date
> 2011-12-05 21:54:54 +0100 (Mon, 05 Dec 2011)
>
>
> Log Message
>
> Add README.urpmi to note that apache needs to be running
Plese use README.install.urpmi instead, otherwise the message will be
shown on every upgrade.
See
https://wiki.mageia.org/en/Packagers_RPM_tutorial#Interaction_with_urpmi_and_rpmdrake
> Modified Paths
>
> * cauldron/urpmi-proxy/current/SPECS/urpmi-proxy.spec
> <#cauldronurpmiproxycurrentSPECSurpmiproxyspec>
>
> Modified: cauldron/urpmi-proxy/current/SPECS/urpmi-proxy.spec
> ===
> --- cauldron/urpmi-proxy/current/SPECS/urpmi-proxy.spec 2011-12-05
> 20:44:07 UTC (rev 177077)
> +++ cauldron/urpmi-proxy/current/SPECS/urpmi-proxy.spec 2011-12-05
> 20:54:54 UTC (rev 177078)
> @@ -1,6 +1,6 @@
> Name: urpmi-proxy
> Version: 0.2.4
> -Release: %mkrel 1
> +Release: %mkrel 2
> Summary: A proxy for urpmi repository mirrors
> Group: System/Configuration/Packaging
> License: GPLv2+
> @@ -22,7 +22,7 @@
> extra repository so you can provide extra or modified packages.
>
> %files
> -%doc README AUTHORS TODO INSTALL LICENSE
> +%doc README AUTHORS TODO INSTALL LICENSE README.urpmi
> %attr(0750,apache,apache) %dir %{_var}/cache/urpmi-proxy
> %attr(0750,apache,apache) %config(noreplace) %{_var}/log/urpmi-proxy.log
> %attr(0750,root,apache) %dir %{_datadir}/urpmi-proxy
> @@ -37,6 +37,17 @@
>
> %build
>
> +cat > README.urpmi < +
> +NOTE: urpmi-proxy functions as an apache webapp, so apache service will have
> +to be started for urpmi-proxy to work, if apache is now installed as a
> +dependency, chances are high that it's not yet running, even though it's
> +installed. you can start apache with:
> +
> + /etc/init.d/httpd start
> +
> +EOF
> +
> %install
> rm -fr %{buildroot}
> %{__mkdir_p} %{buildroot}%{_var}/cache/urpmi-proxy
>
>
--
Anssi Hannula
Re: [Mageia-dev] Subrel for version updates on stable releases
On 28.10.2011 19:17, Anssi Hannula wrote: > Hi! > > Currently the updates policy [1] says that updates to a new version > should have 1.1.mga1 as release, and that cauldron should be bumped to > 2.mga2 on those cases. > > However, on the packages where version updates are done (e.g. wine, > flash-player-plugin, opera, firefox, chromium), doing that causes the > following chain of events on every update: > > 1. cauldron submission with 1.mga2 > 2. mga1 submission with 1.1.mga1 > 3. cauldron submission with 2.mga2 > > So the pkgs have to always be submitted to cauldron twice (unless one > skips right to 2.mga2, which would be rather confusing IMO). > > I suggest we change the policy to say that package updates to stable > should use 1.mga1 release (i.e. no subrel), so that it goes: > 1. cauldron submission with 1.mga2 > 2. mga1 submission with 1.mga1 > > and no extra submissions or commits required. > > Then, if some extra fix is needed, one does: > 1. cauldron submission with 2.mga2 > 2. mga1 submission with 1.1.mga1 > > > WDYT? > > [1] http://www.mageia.org/wiki/doku.php?id=updates_policy > As no one was against it, I've updated the policy page: https://wiki.mageia.org/en/Updates_policy -- Anssi Hannula
Re: [Mageia-dev] [soft-commits] [2290] SILENT : corrected NEWS file
On 5 December 2011 21:33, wrote: > Revision 2290 Author zezinho Date 2011-12-05 21:33:54 +0100 (Mon, 05 Dec > 2011) > > Log Message > > SILENT : corrected NEWS file BTW you do not need to use "SILENT" for non package commits
Re: [Mageia-dev] RFC: Drop mkinitrd completely in favour of dracut.
'Twas brillig, and Anssi Hannula at 02/12/11 21:17 did gyre and gimble:
> On 02.12.2011 15:57, Anssi Hannula wrote:
>> On 02.12.2011 13:28, Colin Guthrie wrote:
>>> Hi,
>>>
>>> Just a suggestion! Should we move wholesale to dracut?
>>>
>>> It's very easy to hack on, and Harald Hoyer has been very helpful and
>>> has merged some of the patches we carried locally (which I mostly copied
>>> from Mandriva). Not sure why they were not upstreamed before.
>>>
>>> There are still a couple patches we carry locally (soon to be less when
>>> Harald pushes his git repo and I rebase), but they are pretty trivial,
>>> understandable and easily maintainable (mostly they will be stylistic
>>> tweaks and naming variations - i.e. very minor).
>>>
>>> Modprobe rules are included even in the initrd so tweaks there follow
>>> through.
>>>
>>> I'm not necessarily against keeping mkinitrd, but I think we should take
>>> the time from now until the beta phase to obsolte mkinitrd and force
>>> everyone to use dracut in order to see if there are any issues and then
>>> make the call before next beta or rc.
>>
>> +1
>>
>> One thing that doesn't work with dracut yet is that it only includes the
>> KMS drivers into initramfs if they are loaded at the time of initramfs
>> creation, causing unoptimal boot screen when a) initramfs created by the
>> installer (I guess), and when b) user has switched a driver non-kms -> kms.
>>
>> This can probably be solved by some patching of
>> modules.d/50plymouth/module-setup.sh, but I haven't looked at it closely
>> yet.
>
> Patch attached. I guess this would remain as a Mageia specific patch as
> the wanted behavior is dependant on how the distribution handles driver
> switching etc...
>
> Shall I apply it?
Just to pick up on this patch, here is a conversation I just had with
Harald on #dracut IRC:
coling> haraldh, the "more interesting" question (for various values of
"more interesting") was about a how hostonly works at the moment it
only includes modules that are already loaded... but in some cases you
want to include modules that are not currently loaded but do belong on
the h/w in question.
haraldh, one of the patches (that we believe might just have to
be a local one for the way we do things) is here:
http://svnweb.mageia.org/packages/cauldron/dracut/current/SOURCES/0508-plymouth-Include-kms-modules-even-if-they-are-not-cu.patch?revision=175507&view=markup
It checks the module aliases against the current h/w. We do
this when we generate the initrd from the installer and include the KMS
modules even although they are not currently loaded.
I'm not sure if this is a mechanism you want to consider
supporting? e.g. perhaps "hostonly" mode could change to do things this
way (via modaliases) and a new "loadedonly" mode could suppliment
hostonly to give the current behaviour?
Or perhaps you could make hostonly={no|yes|loaded|hardware}
where yes is just a synonym for "loaded".
(I didn't write that patch by the way, so i'm just picking up
on the general principal with a view to seeing if the general concept
can be upstreamed)
hostonly, hmm, yes, greping for currently used modules was the
easiest and fastest way
to be more correct, we should do it with the aliases like in
your patch
but that is costly and takes a lot of time
and also the modprobe.conf.d is something one would want
and also install possible helper tools there
so, if you want to factor that one out in a module filter
function, send it to the initramfs mailing list
any help in that area is appreciated and most likely merged :)
So if you fancy working on this, I'm sure it'll get upstreamed :)
Col
--
Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] [soft-commits] [2286] SILENT : forgot to update NEWS
Le lundi 5 décembre 2011 12:20:04, Thierry Vignaud a écrit : > - we describe changes at top of files > - when we release a new version we bump the version number > in the Makefile and we add a new "1.XX:" line at top of the > NEWS file Thanks, now I understood. Fixed.
Re: [Mageia-dev] Ping about the hypothesis to create a non-free&tainted repo
Anne nicolas a écrit : > > Please have a look on Dev meeting logs, il was decided not to create it > for now, at least before Mageia 2 is out. This was done during meeting > some weeks ago > -- > Anne > http://www.mageia.org Sorry ! My English is not fluent... I read it several times but perhaps didn't understood what means the end of discussion and the summary : " 20:09:40 #action policy will be reviewed for Mageia 2 to add potentially non-free tainted repo" I thought that it was decided to review this before Mageia2 is officialy published...
Re: [Mageia-dev] RFC: Drop mkinitrd completely in favour of dracut.
Hi Dave, 'Twas brillig, and David W. Hodgins at 03/12/11 09:21 did gyre and gimble: > On Sat, 03 Dec 2011 01:05:31 -0500, Thomas Backlund wrote: > > Fyi. On one of my cauldron installs, I have /usr in a lvm > logical volume. In order to get this to be bootable, I > modified /etc/dracut.conf to have I've included some code to detect lvm on /usr. I've not tested it but can you test an unmodified version of dracut (rel 7.mga2) to see if it generates a suitable initrd for you? Many thanks. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release sauerbraten-2010_07_28-1.mga2
Op maandag 05 december 2011 16:01:14 schreef Samuel Verschelde: > Le lundi 5 décembre 2011 11:10:00, Samuel Verschelde a écrit : > > Le mardi 15 novembre 2011 14:23:00, Johnny A. Solbu a écrit : > > > On Tuesday 15 November 2011 11:26, Samuel Verschelde wrote: > > > > I don't know if it's still true, but according to the fedora games > > > > SIG group sauerbraten will not be packaged there because there are > > > > (were?) "Various non commercial use clauses in the data." > > > > > > According to their homepage, the data (they call it media) is not Free > > > Software. http://sauerbraten.org/README.html#license > > > > So it must be removed from core and submitted to non-free. > > In fact I'm even not sure we can distribute it at all, for the same reasons > as Fedora's: > - media have various licenses, depending on the contributor (lots of them) > - according to the above readme, some media may even have no license at all > - according to Fedora, some of those licenses restrict commercial use, and > our policy does not allow non-free software with redistribution > restrictions. > > So unless someone digs into the media files, looks at the licences, removes > media files with unclear or too restrictive licenses (and that the game > still works after that), then we must drop it. Otherwise it must go to > non-free. > > Best regards > > Samuel Verschelde you have a point there... otoh, if it comes to that, you can let the user get their "media" themselves, and still package the engine only. (it's what i do for eduke32)
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release sauerbraten-2010_07_28-1.mga2
Le lundi 5 décembre 2011 11:10:00, Samuel Verschelde a écrit : > Le mardi 15 novembre 2011 14:23:00, Johnny A. Solbu a écrit : > > On Tuesday 15 November 2011 11:26, Samuel Verschelde wrote: > > > I don't know if it's still true, but according to the fedora games SIG > > > group sauerbraten will not be packaged there because there are (were?) > > > "Various non commercial use clauses in the data." > > > > According to their homepage, the data (they call it media) is not Free > > Software. http://sauerbraten.org/README.html#license > > So it must be removed from core and submitted to non-free. > In fact I'm even not sure we can distribute it at all, for the same reasons as Fedora's: - media have various licenses, depending on the contributor (lots of them) - according to the above readme, some media may even have no license at all - according to Fedora, some of those licenses restrict commercial use, and our policy does not allow non-free software with redistribution restrictions. So unless someone digs into the media files, looks at the licences, removes media files with unclear or too restrictive licenses (and that the game still works after that), then we must drop it. Otherwise it must go to non-free. Best regards Samuel Verschelde
Re: [Mageia-dev] Jonund
05.12.2011 08:40, D.Morgan skrev: On Mon, Dec 5, 2011 at 6:14 AM, Funda Wang wrote: Could distrib admin just copy libppl7 and libppl_c2 from mageia 1 into cauldron? 2011/12/5: I think too, but that's mean that we cannot submit pkg until it's uploaded, isn't it? should be OK now Thanks dmorgan for fixing it. And sorry for pushing the updated lib too soon. -- Thomas
[Mageia-dev] ANN: gcc-4.6.2 landing on Cauldron
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. -- Thomas
Re: [Mageia-dev] Ping about the hypothesis to create a non-free&tainted repo
2011/12/5 Philippe DIDIER
> Hi !
>
> There was a discussion on dev mailing list and
> something was said about it in meeting on september 21st
>
>
> http://meetbot.mageia.org/mageia-dev/2011/mageia-dev.2011-09-21-19.07.log.html
> ("faac status" begining at
> 19:42:50 )
>
Please have a look on Dev meeting logs, il was decided not to create it for
now, at least before Mageia 2 is out. This was done during meeting some
weeks ago
> This concerns faac and packages been built upon it :
>
> see bug 2833
>
> These softwares allow to create, encode, or modify media files
> (.aac, .mp4 or .m4a) that are very frequently used ...
> These kind of files don't comply wiht free standard (like ogg or
> matroska ) but we have to work with them
> the same way we can do
> with .mp3 or .mov and others non free standard when using tainted
> packages
>
> Mageia 2 will come soon and maybe it's time to decide what to do !
>
>
> Philippe
>
>
--
Anne
http://www.mageia.org
[Mageia-dev] Ping about the hypothesis to create a non-free&tainted repo
Hi !
There was a discussion on dev mailing list and
something was said about it in meeting on september 21st
http://meetbot.mageia.org/mageia-dev/2011/mageia-dev.2011-09-21-19.07.log.html
("faac status" begining at
19:42:50 )
This concerns faac and packages been built upon it :
see bug 2833
These softwares allow to create, encode, or modify media files
(.aac, .mp4 or .m4a) that are very frequently used ...
These kind of files don't comply wiht free standard (like ogg or
matroska ) but we have to work with them
the same way we can do
with .mp3 or .mov and others non free standard when using tainted
packages
Mageia 2 will come soon and maybe it's time to decide what to do !
Philippe
[Mageia-dev] Alpha 2 wiki page
Hi there Very first version of Alpha 2 is available on wiki: https://wiki.mageia.org/mw-en/index.php?title=Mageia_2_alpha2 Please keep it in mind to add information for Alpha2 release Cheers -- Anne http://www.mageia.org
Re: [Mageia-dev] Rakudo and perl 6
I have to think to it, jq. For be sure. Thanks.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release sauerbraten-2010_07_28-1.mga2
05.12.2011 13:12, Maarten Vanraes skrev: Op maandag 05 december 2011 11:54:47 schreef Samuel Verschelde: Le lundi 5 décembre 2011 11:44:19, Maarten Vanraes a écrit : Op maandag 05 december 2011 11:10:00 schreef Samuel Verschelde: Le mardi 15 novembre 2011 14:23:00, Johnny A. Solbu a écrit : On Tuesday 15 November 2011 11:26, Samuel Verschelde wrote: I don't know if it's still true, but according to the fedora games SIG group sauerbraten will not be packaged there because there are (were?) "Various non commercial use clauses in the data." According to their homepage, the data (they call it media) is not Free Software. http://sauerbraten.org/README.html#license So it must be removed from core and submitted to non-free. Samuel so the "data" subpackage can be moved to nonfree? The engine package too, because we can't have a package in core that depends on nonfree. can't we? NO. Our policy is that core _must_ be selfcontained. theorethically, people could make another data packages that is free? no? i mean, if the engine is free, it doesn't really make sense to make it nonfree... ? Then _if_ someone actually make a free data package, we can do the split -- Thomas
Re: [Mageia-dev] Rakudo and perl 6
On 11/12/05 09:19 +, cazzaniga.san...@gmail.com wrote: > Me, perl6 stack's maint? :D why not? if you plan to use it, you can as well maintain it. jérôme
Re: [Mageia-dev] [RFC] nouveau, swrastg, libdri-drivers-experimental
On 5 December 2011 07:09, Anssi Hannula wrote: > Hi! > However, actually only swrast_dri.so is used, so should we: > 1) switch to swrastg, drop swrast (Fedora in Nov 2010) I would go for this swrast is unmaintained (in fact I think it has been dropped from trunk?) only swrastg got fixes these days
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release sauerbraten-2010_07_28-1.mga2
Op maandag 05 december 2011 12:33:28 schreef Samuel Verschelde: > Le lundi 5 décembre 2011 12:21:42, Maarten Vanraes a écrit : > > Op maandag 05 december 2011 12:15:11 schreef zezinho: > > > Le lundi 5 décembre 2011 12:12:18, Maarten Vanraes a écrit : > > > > theorethically, people could make another data packages that is free? > > > > no? i mean, if the engine is free, it doesn't really make sense to > > > > make it nonfree... ? > > > > > > Yes, but to work for now, the engine package requires the non-free > > > source. If a user has disabled non-free, he will get an error. > > > > i don't know if this is a bad idea: iirc the error is something like: > > "can't find data package" or something... imho you can suggest it and put > > a README.urpmi saying you'll need nonfree data... > > > > but perhaps this is a discussion more suited in another place... > > It someone really wants the engine to build its own data (which I doubt), > they can still download from the upstream website, so for the vast > majority of users (if not 100%!) the engine will be of no use without the > data. idea-ologically speaking i don't really agree, ( if it's free, it's free, not nonfree; even if it's able to use other nonfree parts), but practically, i can't say anything about this...
[Mageia-dev] Syndaemon testing required x86_64 MGA1
Hi Please see bug 1597 ( https://bugs.mageia.org/show_bug.cgi?id=1597 ) Syndaemon, the synaptics touchpad daemon, will suddenly/randomly use 100% CPU when the disable when typing option is set. It requires testing x86_64 in Mageia 1 by reproducing the bug and testing with the update candidate but it seems we don't have the correct hardware in QA to do so. Could somebody please test this x86_64 and confirm the fix so that the update can be validated. Alternately please send new laptop to... ;) Thankyou Claire
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release sauerbraten-2010_07_28-1.mga2
Le lundi 5 décembre 2011 12:21:42, Maarten Vanraes a écrit : > Op maandag 05 december 2011 12:15:11 schreef zezinho: > > Le lundi 5 décembre 2011 12:12:18, Maarten Vanraes a écrit : > > > theorethically, people could make another data packages that is free? > > > no? i mean, if the engine is free, it doesn't really make sense to > > > make it nonfree... ? > > > > Yes, but to work for now, the engine package requires the non-free > > source. If a user has disabled non-free, he will get an error. > > i don't know if this is a bad idea: iirc the error is something like: > "can't find data package" or something... imho you can suggest it and put > a README.urpmi saying you'll need nonfree data... > > but perhaps this is a discussion more suited in another place... It someone really wants the engine to build its own data (which I doubt), they can still download from the upstream website, so for the vast majority of users (if not 100%!) the engine will be of no use without the data.
Re: [Mageia-dev] [soft-commits] [2286] SILENT : forgot to update NEWS
'Twas brillig, and zezinho at 05/12/11 11:14 did gyre and gimble: > Le lundi 5 décembre 2011 12:07:56, Thierry Vignaud a écrit : >> On 5 December 2011 12:00, wrote: >>> Revision 2286 Author zezinho Date 2011-12-05 12:00:57 +0100 (Mon, 05 Dec >>> 2011) >>> >>> Log Message >>> >>> SILENT : forgot to update NEWS >> >> this is bogus, it never ended in 1.0 but will land in 1.1 so it MUST be >> ABOVE >> > Oh sorry. But you talk about 1.0 while this commit is in the updated 1 > branch, 0.97.2. What do you mean by 0.97.2? The commit was in trunk > Modified: drakx-net/trunk/NEWS ^ > So which commit should I revert? The update to NEWS file. You included your comment under the changes for the 1.0 release, but this has already been released So your entry must go above this - i.e. as a pending change in an upcoming release which may be 1.1 or 2.0 or whatever (something > 1.0). So just move the NEWS entry to the top of the file, leave a blank line, then let it carry on with the 1.0 section. Hope that's clear. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release sauerbraten-2010_07_28-1.mga2
Op maandag 05 december 2011 12:15:11 schreef zezinho: > Le lundi 5 décembre 2011 12:12:18, Maarten Vanraes a écrit : > > theorethically, people could make another data packages that is free? no? > > i mean, if the engine is free, it doesn't really make sense to make it > > nonfree... ? > > Yes, but to work for now, the engine package requires the non-free source. > If a user has disabled non-free, he will get an error. i don't know if this is a bad idea: iirc the error is something like: "can't find data package" or something... imho you can suggest it and put a README.urpmi saying you'll need nonfree data... but perhaps this is a discussion more suited in another place...
Re: [Mageia-dev] [soft-commits] [2286] SILENT : forgot to update NEWS
On 5 December 2011 12:14, zezinho wrote: >> > Revision 2286 Author zezinho Date 2011-12-05 12:00:57 +0100 (Mon, 05 Dec >> > 2011) >> > >> > Log Message >> > >> > SILENT : forgot to update NEWS >> >> this is bogus, it never ended in 1.0 but will land in 1.1 so it MUST be >> ABOVE >> > Oh sorry. But you talk about 1.0 while this commit is in the updated 1 > branch, 0.97.2. > > So which commit should I revert? No this commit is in trunk, not in the 1 branch, as clearly showed by the "drakx-net/trunk/" path. And I didn't speak about reverting but about moving your changes above the released 1.0 the rules are: - we describe changes at top of files - when we release a new version we bump the version number in the Makefile and we add a new "1.XX:" line at top of the NEWS file
Re: [Mageia-dev] [changelog] [RPM] 1 core/updates_testing drakx-net-0.97.2-1.mga1
On 5 December 2011 12:07, Mageia Team wrote: > zezinho 0.97.2-1.mga1: > + Revision: 176878 > - fix squid configuration when sharing internet connection (#1353) you forgot some of the changes (strings not tagged as translatable)
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release sauerbraten-2010_07_28-1.mga2
Le lundi 5 décembre 2011 12:12:18, Maarten Vanraes a écrit : > theorethically, people could make another data packages that is free? no? i > mean, if the engine is free, it doesn't really make sense to make it > nonfree... ? Yes, but to work for now, the engine package requires the non-free source. If a user has disabled non-free, he will get an error.
Re: [Mageia-dev] [soft-commits] [2285] 0.97.2 - fix squid configuration when sharing internet connection ( #1353)
On 5 December 2011 11:49, wrote:
> Revision 2285 Author zezinho Date 2011-12-05 11:49:32 +0100 (Mon, 05 Dec
> 2011)
>
> Log Message
>
> 0.97.2 - fix squid configuration when sharing internet connection (#1353)
please next time commit different things as different commits, eg here:
1) first the squid fix
2) then the version bump
this:
- makes easier to review
- would prevent changelog garbage such as this
> Modified Paths
>
> drakx-net/branches/1/Makefile
> drakx-net/branches/1/NEWS
> drakx-net/branches/1/lib/network/squid.pm
>
> Modified: drakx-net/branches/1/Makefile
> ===
> --- drakx-net/branches/1/Makefile 2011-12-05 10:20:19 UTC (rev 2284)
> +++ drakx-net/branches/1/Makefile 2011-12-05 10:49:32 UTC (rev 2285)
> @@ -1,5 +1,5 @@
> NAME = drakx-net
> -VERSION = 0.97.1
> +VERSION = 0.97.2
>
> DESTDIR=
> libdir=/usr/lib
>
> Modified: drakx-net/branches/1/NEWS
> ===
> --- drakx-net/branches/1/NEWS 2011-12-05 10:20:19 UTC (rev 2284)
> +++ drakx-net/branches/1/NEWS 2011-12-05 10:49:32 UTC (rev 2285)
> @@ -1,5 +1,8 @@
> - make sure all strings ended in translation catalogs (#3371)
>
> +0.97.2:
> +- fix squid configuration when sharing internet connection (#1353)
> +
> 0.97.1:
> - install b43-openfwwf for b43 chips instead of requiring external firmware
> files (#923)
>
>
> Modified: drakx-net/branches/1/lib/network/squid.pm
> ===
> --- drakx-net/branches/1/lib/network/squid.pm 2011-12-05 10:20:19 UTC (rev
> 2284)
> +++ drakx-net/branches/1/lib/network/squid.pm 2011-12-05 10:49:32 UTC (rev
> 2285)
> @@ -64,7 +64,7 @@
> visible_hostname $squid_conf->{visible_hostname}[0]
> append_domain .$internal_domain_name
> err_html_text $squid_conf->{admin_mail}[0]
> -deny_info ERR_CUSTOM_ACCESS_DENIED all
> +deny_info ERR_CACHE_ACCESS_DENIED all
> memory_pools off
> coredump_dir /var/spool/squid
> ie_refresh on
>
--
> R : Tu vois !
> > Q : Tu crois ?
> > > R : Ça casse l'ordre chronologique de l'échange.
> > > > Q : En quoi répondre au dessus est-il gênant ?
Re: [Mageia-dev] [soft-commits] [2286] SILENT : forgot to update NEWS
Le lundi 5 décembre 2011 12:07:56, Thierry Vignaud a écrit : > On 5 December 2011 12:00, wrote: > > Revision 2286 Author zezinho Date 2011-12-05 12:00:57 +0100 (Mon, 05 Dec > > 2011) > > > > Log Message > > > > SILENT : forgot to update NEWS > > this is bogus, it never ended in 1.0 but will land in 1.1 so it MUST be > ABOVE > Oh sorry. But you talk about 1.0 while this commit is in the updated 1 branch, 0.97.2. So which commit should I revert?
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release sauerbraten-2010_07_28-1.mga2
Op maandag 05 december 2011 11:54:47 schreef Samuel Verschelde: > Le lundi 5 décembre 2011 11:44:19, Maarten Vanraes a écrit : > > Op maandag 05 december 2011 11:10:00 schreef Samuel Verschelde: > > > Le mardi 15 novembre 2011 14:23:00, Johnny A. Solbu a écrit : > > > > On Tuesday 15 November 2011 11:26, Samuel Verschelde wrote: > > > > > I don't know if it's still true, but according to the fedora games > > > > > SIG group sauerbraten will not be packaged there because there are > > > > > (were?) "Various non commercial use clauses in the data." > > > > > > > > According to their homepage, the data (they call it media) is not > > > > Free Software. http://sauerbraten.org/README.html#license > > > > > > So it must be removed from core and submitted to non-free. > > > > > > Samuel > > > > so the "data" subpackage can be moved to nonfree? > > The engine package too, because we can't have a package in core that > depends on nonfree. can't we? theorethically, people could make another data packages that is free? no? i mean, if the engine is free, it doesn't really make sense to make it nonfree... ?
Re: [Mageia-dev] [soft-commits] [2286] SILENT : forgot to update NEWS
On 5 December 2011 12:00, wrote: > Revision 2286 Author zezinho Date 2011-12-05 12:00:57 +0100 (Mon, 05 Dec > 2011) > > Log Message > > SILENT : forgot to update NEWS this is bogus, it never ended in 1.0 but will land in 1.1 so it MUST be ABOVE > Modified: drakx-net/trunk/NEWS > === > --- drakx-net/trunk/NEWS 2011-12-05 10:49:32 UTC (rev 2285) > +++ drakx-net/trunk/NEWS 2011-12-05 11:00:57 UTC (rev 2286) > @@ -1,6 +1,7 @@ > 1.0: > - fix parsing (and thus writing back) ACCOUNTING and NM_CONTROLLED in ifcfg > - make sure all strings ended in translation catalogs (#3371) > +- fix squid configuration when sharing internet connection (#1353) > > 0.99: > - Use b43-openfwwf for b43 module instead of asking for a windows driver > -- > R : Tu vois ! > > Q : Tu crois ? > > > R : Ça casse l'ordre chronologique de l'échange. > > > > Q : En quoi répondre au dessus est-il gênant ?
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release sauerbraten-2010_07_28-1.mga2
Le lundi 5 décembre 2011 11:44:19, Maarten Vanraes a écrit : > Op maandag 05 december 2011 11:10:00 schreef Samuel Verschelde: > > Le mardi 15 novembre 2011 14:23:00, Johnny A. Solbu a écrit : > > > On Tuesday 15 November 2011 11:26, Samuel Verschelde wrote: > > > > I don't know if it's still true, but according to the fedora games > > > > SIG group sauerbraten will not be packaged there because there are > > > > (were?) "Various non commercial use clauses in the data." > > > > > > According to their homepage, the data (they call it media) is not Free > > > Software. http://sauerbraten.org/README.html#license > > > > So it must be removed from core and submitted to non-free. > > > > Samuel > > so the "data" subpackage can be moved to nonfree? The engine package too, because we can't have a package in core that depends on nonfree.
Re: [Mageia-dev] [soft-commits] [2284] ERR_CUSTOM file does not exist anymore, fix bug #1353
Please comment in NEWS too
On 5 December 2011 11:20, wrote:
> Revision 2284 Author zezinho Date 2011-12-05 11:20:19 +0100 (Mon, 05 Dec
> 2011)
>
> Log Message
>
> ERR_CUSTOM file does not exist anymore, fix bug #1353
>
> Modified Paths
>
> drakx-net/trunk/lib/network/squid.pm
>
> Modified: drakx-net/trunk/lib/network/squid.pm
> ===
> --- drakx-net/trunk/lib/network/squid.pm 2011-12-05 02:54:11 UTC (rev
> 2283)
> +++ drakx-net/trunk/lib/network/squid.pm 2011-12-05 10:20:19 UTC (rev
> 2284)
> @@ -64,7 +64,7 @@
> visible_hostname $squid_conf->{visible_hostname}[0]
> append_domain .$internal_domain_name
> err_html_text $squid_conf->{admin_mail}[0]
> -deny_info ERR_CUSTOM_ACCESS_DENIED all
> +deny_info ERR_CACHE_ACCESS_DENIED all
> memory_pools off
> coredump_dir /var/spool/squid
> ie_refresh on
>
--
> R : Tu vois !
> > Q : Tu crois ?
> > > R : Ça casse l'ordre chronologique de l'échange.
> > > > Q : En quoi répondre au dessus est-il gênant ?
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release sauerbraten-2010_07_28-1.mga2
Op maandag 05 december 2011 11:10:00 schreef Samuel Verschelde: > Le mardi 15 novembre 2011 14:23:00, Johnny A. Solbu a écrit : > > On Tuesday 15 November 2011 11:26, Samuel Verschelde wrote: > > > I don't know if it's still true, but according to the fedora games SIG > > > group sauerbraten will not be packaged there because there are (were?) > > > "Various non commercial use clauses in the data." > > > > According to their homepage, the data (they call it media) is not Free > > Software. http://sauerbraten.org/README.html#license > > So it must be removed from core and submitted to non-free. > > Samuel so the "data" subpackage can be moved to nonfree?
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release sauerbraten-2010_07_28-1.mga2
Le mardi 15 novembre 2011 14:23:00, Johnny A. Solbu a écrit : > On Tuesday 15 November 2011 11:26, Samuel Verschelde wrote: > > I don't know if it's still true, but according to the fedora games SIG > > group sauerbraten will not be packaged there because there are (were?) > > "Various non commercial use clauses in the data." > > According to their homepage, the data (they call it media) is not Free > Software. http://sauerbraten.org/README.html#license So it must be removed from core and submitted to non-free. Samuel
Re: [Mageia-dev] Rakudo and perl 6
Me, perl6 stack's maint? :D -Original Message- From: Jerome Quelin Sender: mageia-dev-boun...@mageia.org Date: Mon, 5 Dec 2011 10:18:16 To: Mageia development mailing-list Reply-To: Mageia development mailing-list Subject: Re: [Mageia-dev] Rakudo and perl 6 hi, On 11/12/05 08:07 +0100, Sandro CAZZANIGA wrote: > You have probably heard about perl 6, the little brother of perl 5. It will > be, for me, an excellent langage, extremely strong. My question is the > following: > > Can I package rakudo for Mageia Cauldron? yes you can. you will need an up to date parrot for this. i don't have time nor the need / envy to maintain perl 6 stack, so you're welcome to grab it. jérôme
Re: [Mageia-dev] Rakudo and perl 6
hi, On 11/12/05 08:07 +0100, Sandro CAZZANIGA wrote: > You have probably heard about perl 6, the little brother of perl 5. It will > be, for me, an excellent langage, extremely strong. My question is the > following: > > Can I package rakudo for Mageia Cauldron? yes you can. you will need an up to date parrot for this. i don't have time nor the need / envy to maintain perl 6 stack, so you're welcome to grab it. jérôme
Re: [Mageia-dev] [RFC] nouveau, swrastg, libdri-drivers-experimental
'Twas brillig, and Anssi Hannula at 05/12/11 06:09 did gyre and gimble: > Hi! > > 1. nouveau > > I propose to move nouveau DRI drivers from libdri-drivers-experimental > to libdri-drivers. > > Fedora moved them out of -experimental in last January, Ubuntu in last > June, OpenSUSE in July (though OpenSUSE doesn't have the legacy > nouveau_vieux DRI driver at all), and Debian a week ago. > > I've been running with it for the last week or so with no problems on my > card. > > WDYT? Seems sensible. I've not got any NV h/w but this seems like the Right Thing to Do(tm). > 2. swrastg > > It seems we have both swrast_dri.so and swrastg_dri.so in libdri-drivers > package. > > swrast_dri.so is the traditional SW rasterizer used when there is no HW > support. > > swrastg_dri.so is the Gallium3d-based rasterizer which is considerably > faster. > > However, actually only swrast_dri.so is used, so should we: > 1) switch to swrastg, drop swrast (Fedora in Nov 2010) > 2) keep it as is, unused (~4 MB) > 3) move swrastg to libdri-drivers-experimental (Ubuntu in Jun 2010, >Debian a week ago) which nouveau is probably moving out of > 4) drop swrastg completely for now (seemingly OpenSUSE) On balance, I ultimately prefer 3 with your xserver patch, Either that or 1. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] [RFC] nouveau, swrastg, libdri-drivers-experimental
Le lundi 5 décembre 2011 07:09:46, Anssi Hannula a écrit : > I propose to move nouveau DRI drivers from libdri-drivers-experimental > to libdri-drivers. Agreed. I use nouveau for 6 months without any problem. > It seems we have both swrast_dri.so and swrastg_dri.so in libdri-drivers > package. > I'd say go for swrastg_dri.so, as we are in Alpha stage.
