Re: [Mageia-dev] [soft-commits] [6620] obsoleted by pod-syntax.t
On 9 December 2012 17:21, Guillaume Rousse wrote:
>> No, I want pod errors to be found prior submitting them.
>> And I don't want to manually run several tests.
>> Before all I had to do was to run "make test" and it reported me
>> any errors before commiting.
>> Now it doesn't anymore.
>
> make test TEST_AUTHOR=1
> or drop the conditional in the tests.
so what's the difference with the older test?
You lamented old test didn't work standalone if blib wasn't created
but eventually in both cases, you need to run "make test"
>> Well, if that mean less quality testsuite and if you refuse to answer
>> reviewing,
>> I'll eventually revert those or at least put back the old working pod
>> test.
>
> Just revert. Or try to show minimal interest in external contributions,
> instead of plain hostility.
what?
you added tests w/o any doc nor useful commit ("initial import")
When I told you they overlap existing tests, you claim existing ones
don't work and you just wip them w/o communicating.
I then show you that:
1) old one works and do fine issues when there'se one before
committing or releasing
2) new ones silently don't work (only found by accident when looking
at "make test" output
3) you claim new ones work by passing magic undocumented env variable
when they don't
So what's the interest of your new tests?
The only change is that I silently cannot see newly introduced errors.
What's the use to the maintainer?
So I did show interest in external contributions and as usual I do peer review.
This has enabled others to take interest in various pieces of our tools.
But you failed to answer my questions when I made some observations and when
I showed you old tests worked whereas new ones don't.
Same when I asked you to add the needed BR to the spec file in order
to ensure next version upload would work.
Your only answer is to attack me whereas I'm pointing at actual facts.
So please stop trolling aka personal attacks and explain to me how
disabling tests for maintainers
(aka making them not working w/o some magic
undocumented/uncommunicated variable)
is contributing?
I just want pod-syntax.t to be always run.
So eventually the pod syntax new test is just the old one but less
readable and not working by default:
- some magic values testing in order not to be run
- using English in order to rename variables
- replacing use by require+import
It would just have been simple to ask before, hasn't it?
Re: [Mageia-dev] [changelog] cauldron core/release x11-driver-video-ati-7.0.0-2.mga3
10.12.2012 02:05, Thomas Backlund kirjoitti:
> Anssi Hannula skrev 27.11.2012 00:08:
>> 26.11.2012 19:25, Thomas Backlund kirjoitti:
>>> tv skrev 26.11.2012 16:53:
Name: x11-driver-video-ati Relocations: (not relocatable)
Version : 7.0.0 Vendor: Mageia.Org
Release : 2.mga3Build Date: Mon Nov 26
15:52:14 2012
>>>
>>> Note to all ati users...
>>>
>>> Beginning with 7.0.0 series, this driver is KMS only.
>>>
>>> so UMS mode ("nokms") is no more useful with this driver
>>>
>>> IIRC we will also need to update display_driver_helper (and maybe drakx)
>>> to cope with this fact...
>>
>> I'll disable the hack in display_driver_helper...
>>
>> But should we now have ldetect-lst fallback to vesa on all radeon cards
>> if no fw installed ("DRIVER_NO_FIRMWARE vesa")?
>>
>> According to the kernel driver code (AFAICS, that is) it should fallback
>> to no acceleration in case of no firmware, but at least some time ago
>> that apparently didn't happen properly...
>>
>
> I think we need to fallback to vesa, as it does not matter if the kernel
> part works without firmware in ums mode, as the x11 driver wont support
> it anyway, making the x11-server start fail .
I meant that AFAIK KMS should work without acceleration without firmware
for old cards (for new cards we already default to vesa), but if this
still doesn't work properly, we need to default to vesa for them as well.
--
Anssi Hannula
Re: [Mageia-dev] [changelog] cauldron core/release x11-driver-video-ati-7.0.0-2.mga3
Anssi Hannula skrev 27.11.2012 00:08:
26.11.2012 19:25, Thomas Backlund kirjoitti:
tv skrev 26.11.2012 16:53:
Name: x11-driver-video-ati Relocations: (not relocatable)
Version : 7.0.0 Vendor: Mageia.Org
Release : 2.mga3Build Date: Mon Nov 26 15:52:14 2012
Note to all ati users...
Beginning with 7.0.0 series, this driver is KMS only.
so UMS mode ("nokms") is no more useful with this driver
IIRC we will also need to update display_driver_helper (and maybe drakx)
to cope with this fact...
I'll disable the hack in display_driver_helper...
But should we now have ldetect-lst fallback to vesa on all radeon cards
if no fw installed ("DRIVER_NO_FIRMWARE vesa")?
According to the kernel driver code (AFAICS, that is) it should fallback
to no acceleration in case of no firmware, but at least some time ago
that apparently didn't happen properly...
I think we need to fallback to vesa, as it does not matter if the kernel
part works without firmware in ums mode, as the x11 driver wont support
it anyway, making the x11-server start fail .
--
Thomas
Re: [Mageia-dev] libperl location
On Monday, September 10, 2012 10:25:31 PM Pascal Terjan wrote: > On Mon, Sep 10, 2012 at 9:34 PM, Thomas Spuhler wrote: > > I am trying to build the 389 dirsrv. When building lperl looks for > > libperl in /usr/lib/ but it cannot find it. > > > > Doing > > > > ln -sf /usr/lib/perl5/5.16.1/x86_64-linux-thread-multi/CORE/libperl.so > > /usr/lib/libperl.so > > > > Solves the problem. > > Is this a feature or a bug? Do I need to patch the makefile of the > > 389dirsrv? > > You can use something like this to get the flags to use: > > $ perl -MExtUtils::Embed -e ldopts > -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE > -fstack-protector -L/usr/local/lib64 > -L/usr/lib/perl5/5.12.3/x86_64-linux-thread-multi/CORE -lperl -lnsl > -ldl -lm -lcrypt -lutil -lpthread -lc I now need to do to cyrus-imapd as well. What has changed in Cauldron that now requires this? -- Best regards Thomas Spuhler
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release drakx-installer-stage2-15.4-2.mga3
On 9 December 2012 21:42, dmorgan wrote: > ennael 15.4-2.mga3: > + Revision: 329167 > - use debug for tests Er you should do such builds this locally...
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release initscripts-9.41-2.mga3
On Sun, Dec 9, 2012 at 11:18 PM, Thierry Vignaud wrote: > On 9 December 2012 22:27, tmb wrote: >> tmb 9.41-2.mga3: >> + Revision: 329208 >> - add back check for wireless sysfs dir (P0, #8343) >> >> + colin >> - Fix up paths and use nice dir macros where possible > > Then please remove *9.41* from core/updates_testing done
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release initscripts-9.41-2.mga3
On 9 December 2012 22:27, tmb wrote: > tmb 9.41-2.mga3: > + Revision: 329208 > - add back check for wireless sysfs dir (P0, #8343) > > + colin > - Fix up paths and use nice dir macros where possible Then please remove *9.41* from core/updates_testing
Re: [Mageia-dev] Big problem with a rpm => freeswitch
On Sunday 9. December 2012 16.55, Thomas Backlund wrote: > Well, this decision is not your to take, as dlucio is the maintainer Which is why I didn't do that. :-)= -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
'Twas brillig, and Thierry Vignaud at 09/12/12 18:48 did gyre and gimble: > On 9 December 2012 13:18, Colin Guthrie wrote: So I've just pushed the package mageia-prepare-upgrade to mga2 core/updates_testing. This package, when installed will add a new menu option to your bootloader. Simply install this package, reboot, select the "Mageia 3 Upgrade Preparation" entry boot, wait while your FS is converted and then perform a urpmi upgrade as you would normally. I've not specifically tested the upgrade part, only the installation and creation of the initrd and bootloader entries in grub. I've also not done this on an mga2 machine yet but will do soon enough. I just wanted to get this package "out there" for anyone wanting to update their mga2 machines to mga3 a3 but not wanting to use the installer. At present there are a few limitations: 1. It requires kernel 3.3.8-2.mga2 to be installed (any flavour should work). A specific kernel version is not really 100% necessary but it does mean I can add hard requires to the package. This is only desirable to prevent the situation where users install this upgrade package but do not run it and later remove the kernel used to generate the initrd for the bootloader menu item, thus breaking it. Any smarter ideas on how to manage this welcome. 2. If you have /usr in a separate partition and have it mounted ro in your fstab, you will have to manually change the fstab to rw for the upgrade boot. Happy testing. Let me know if it kills any kittens. Please keep a backup etc. etc. Col >>> Thanks Colin. >>> The conversion works. But then the problem shows, we have no network. >>> doing a urpmi --download-all --auto-update only downloads the fist 120+ >>> rpms (the ones needed before >>> restart-urpmi >>> >>> What is needed is to add some directories and then the network will start >>> /var/run/netreport >>> /var/lock/subsystem/network >>> >>> I will check after the upgrade if they can be deleted >> >> Hmm, yes, I guess after doing the upgrade the various /var/run and >> /var/lock folders would be nuked. In mga3 they will be created by >> tmpfiles but not with a simple reboot on mga2... >> >> Hmm, I wonder how best to do this... perhaps we could ship updated >> packages for each of the packages which absolutely *need* this to do the >> download... or perhaps we could just ship some essential config tweaks >> in the this mageia-prepare-upgrade file. It shouldn't do any harm to do >> the latter and it's a bit easier on the QA folk. > > Humm we could just package mageia-prepare-upgrade in mga3 and add > it to urpmi priority list. > Thus it would also work for people who never apply updates... > My 2 cents Not sure it would help. I mean users have to install it, reboot and then install the rest... Also how does the urpmi priority list work? Does that not require that we install urpmi first? If so that likely won't work as there is a chicken and egg scenario that prevents the rpm+urpmi from mga3 being installed until the fs is updated. Basically, a fully up-to-date mga2 (including rpm package and the mageia-prepare-upgrade package) + reboot for preparation is needed for a urpmi-based upgrades to work. 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] ANN: Upgrading from Mageia 2 via urpmi
'Twas brillig, and Colin Guthrie at 09/12/12 12:14 did gyre and gimble: > 'Twas brillig, and Remy CLOUARD at 08/12/12 12:25 did gyre and gimble: >> On Sun, Nov 18, 2012 at 04:37:43PM +, Colin Guthrie wrote: >>> Hi, >>> >> [...] >>> So I've just pushed the package mageia-prepare-upgrade to mga2 >>> core/updates_testing. >> [...] >>> >>> Happy testing. Let me know if it kills any kittens. Please keep a backup >>> etc. etc. >>> >>> Col >>> >> Hi Colin, >> >> I’ve followed the procedure and could upgrade my system from 2 to >> cauldron, but I still have an issue with the filesystem package. >> >> Somehow it seems like it fails to move /var/run to /run and /var/lock to >> /run/lock. >> >> I would be glad if there could be a workaround for this. >> Here is a debug output of urpmi: >> # export LC_ALL=C >> # export LANG=C >> # urpmi --debug filesystem >> error: unpacking of archive failed on file /var/lock: cpio: rename >> failed - Is a directory >> error: filesystem-2.1.9-18.mga3.x86_64: install failed >> error: filesystem-2.1.9-17.mga2.x86_64: erase skipped >> unlocking urpmi database >> unlocking rpm database >> EXITING (pid=11661) >> >> The only way out I think would be to manually do the symlink from >> another install. >> >> Could you confirm that ? > > Actually yes, there is still a problem at present with /var on a > separate partition... I need to look into that. So the latest package should mount /var in the initrd in much the same way it does with /usr (not exactly the same but I want to make the changes as unobtrusive as possible and ideally separate from the main dracut package for convenience of updating). I presume your setup is such that /var is indeed on a separate partition? In order to fix this, simply mv the folders out the way and just do the symlinks manually - it'll mess up the current boot, but a reboot should fix it. If the symlinks disappear and are replaced again by folders, then also make sure you disable mandriva-clean-var-run-lock.service as it helpfully nukes the symlinks (the update does this but perhaps it's somehow been run/re-enabled?) Cheers 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] ANN: Upgrading from Mageia 2 via urpmi
On 9 December 2012 13:18, Colin Guthrie wrote: >>> So I've just pushed the package mageia-prepare-upgrade to mga2 >>> core/updates_testing. >>> >>> This package, when installed will add a new menu option to your >>> bootloader. Simply install this package, reboot, select the "Mageia 3 >>> Upgrade Preparation" entry boot, wait while your FS is converted and >>> then perform a urpmi upgrade as you would normally. >>> >>> I've not specifically tested the upgrade part, only the installation and >>> creation of the initrd and bootloader entries in grub. I've also not >>> done this on an mga2 machine yet but will do soon enough. >>> >>> I just wanted to get this package "out there" for anyone wanting to >>> update their mga2 machines to mga3 a3 but not wanting to use the installer. >>> >>> At present there are a few limitations: >>> >>> 1. It requires kernel 3.3.8-2.mga2 to be installed (any flavour should >>> work). A specific kernel version is not really 100% necessary but it >>> does mean I can add hard requires to the package. This is only desirable >>> to prevent the situation where users install this upgrade package but do >>> not run it and later remove the kernel used to generate the initrd for >>> the bootloader menu item, thus breaking it. Any smarter ideas on how to >>> manage this welcome. >>> >>> 2. If you have /usr in a separate partition and have it mounted ro in >>> your fstab, you will have to manually change the fstab to rw for the >>> upgrade boot. >>> >>> >>> Happy testing. Let me know if it kills any kittens. Please keep a backup >>> etc. etc. >>> >>> Col >> Thanks Colin. >> The conversion works. But then the problem shows, we have no network. >> doing a urpmi --download-all --auto-update only downloads the fist 120+ rpms >> (the ones needed before >> restart-urpmi >> >> What is needed is to add some directories and then the network will start >> /var/run/netreport >> /var/lock/subsystem/network >> >> I will check after the upgrade if they can be deleted > > Hmm, yes, I guess after doing the upgrade the various /var/run and > /var/lock folders would be nuked. In mga3 they will be created by > tmpfiles but not with a simple reboot on mga2... > > Hmm, I wonder how best to do this... perhaps we could ship updated > packages for each of the packages which absolutely *need* this to do the > download... or perhaps we could just ship some essential config tweaks > in the this mageia-prepare-upgrade file. It shouldn't do any harm to do > the latter and it's a bit easier on the QA folk. Humm we could just package mageia-prepare-upgrade in mga3 and add it to urpmi priority list. Thus it would also work for people who never apply updates... My 2 cents
Re: [Mageia-dev] [packages-commits] [329082] - mod_siren is not optional
On Sun, Dec 9, 2012 at 5:21 PM, wrote:
> Revision 329082 Author dlucio Date 2012-12-09 17:21:44 +0100 (Sun, 09 Dec
> 2012)
>
> Log Message
>
> - mod_siren is not optional
> - mod_spidermonkey is disabled
>
> Modified Paths
>
> cauldron/freeswitch/current/SPECS/freeswitch.spec
>
> Modified: cauldron/freeswitch/current/SPECS/freeswitch.spec
> ===
> --- cauldron/freeswitch/current/SPECS/freeswitch.spec 2012-12-09 15:59:02
> UTC (rev 329081)
> +++ cauldron/freeswitch/current/SPECS/freeswitch.spec 2012-12-09 16:21:44
> UTC (rev 329082)
> @@ -1,3 +1,4 @@
> +%define Werror_cflags -Wformat
> %define _disable_ld_as_needed 1
> %define _disable_ld_no_undefined 1
> %define _disable_ld_relro 1
> @@ -5,6 +6,34 @@
> %define _disable_ld_build_id 1
> %define _disable_ld_enable_new_dtags 1
> %define _disable_libtoolize 1
> +##
> +#
> +# spec file for package freeswitch
> +#
> +# includes module(s): freeswitch-devel freeswitch-codec-passthru-amr
> freeswitch-codec-passthru-amrwb freeswitch-codec-passthru-g729
> +# freeswitch-codec-passthru-g7231 freeswitch-lua
> freeswitch-perl freeswitch-python
> +# freeswitch-lan-de freeswitch-lang-en
> freeswitch-lang-fr freeswitch-lang-hu freeswitch-lang-ru freeswitch-freetdm
> +#
> +# Initial Version Copyright (C) 2007 Peter Nixon and Michal Bielicki, All
> Rights Reserved.
> +#
> +# This file is part of:
> +# FreeSWITCH Modular Media Switching Software Library / Soft-Switch
> Application
> +# Copyright (C) 2005-2012, Anthony Minessale II
> +#
> +# This file and all modifications and additions to the pristine package are
> under the same license as the package itself.
> +#
> +# Contributor(s): Mike Jerris
> +# Brian West
> +# Anthony Minessale II
> +# Raul Fragoso
> +# Rupa Shomaker
> +# Marc Olivier Chouinard
> +# Raymond Chandler
> +# Ken Rice
> +#
> +# Maintainer(s): Ken Rice
> +#
so you get rid of all cleaning done by other people without notifying
in the commit log . Please propedit your specfile.
And in addition as told this would be better to review the spec file
before submiting because it is just horrible and would need some more
work/love... but you already submited, Hopefully you removed libnspr4
but too WITHOUT notification.
you still have ;
%{LIBDIR}/libfreeswitch*.so*
%{LIBDIR}/libfreeswitch*.a
in the main package which is against all our policies and you still
use %{LIBDIR} instead of %{_libdir} ( means you reverted my cleaning
without notify it in the commit log ( not really fair )
Please fix and/or ask for help because we need quality in mageia.
Regards,
D.
Re: [Mageia-dev] Big problem with a rpm => freeswitch
Le 09/12/2012 16:55, Thomas Backlund a écrit : > > But for now the rpms have been removed from repos until the listed > issues are resolved. And the package is on the BS. Dlucio, do you read this ml ?
Re: [Mageia-dev] [soft-commits] [6620] obsoleted by pod-syntax.t
Le 09/12/2012 17:09, Thierry Vignaud a écrit : No, I want pod errors to be found prior submitting them. And I don't want to manually run several tests. Before all I had to do was to run "make test" and it reported me any errors before commiting. Now it doesn't anymore. make test TEST_AUTHOR=1 or drop the conditional in the tests. [..] Well, if that mean less quality testsuite and if you refuse to answer reviewing, I'll eventually revert those or at least put back the old working pod test. Just revert. Or try to show minimal interest in external contributions, instead of plain hostility. -- BOFH excuse #70: nesting roaches shorted out the ether cable
Re: [Mageia-dev] [soft-commits] [6620] obsoleted by pod-syntax.t
On 9 December 2012 17:04, Guillaume Rousse wrote:
>> Yours does nothing:
>> t/pod-coverage.t
>> skipped: Author test, set $ENV{TEST_AUTHOR} to a true value to run
>> t/pod-spelling.t
>> skipped: Author test, set $ENV{TEST_AUTHOR} to a true value to run
>> t/pod-syntax.t ..
>> skipped: Author test, set $ENV{TEST_AUTHOR} to a true value to run
>
> They work if you set the variable, as explicitely reported. That's perfectly
> useless to run those tests anywhere else as on developper machine, and
> especially during package build. And that's a standard practice in perl
> community.
No, I want pod errors to be found prior submitting them.
And I don't want to manually run several tests.
Before all I had to do was to run "make test" and it reported me
any errors before commiting.
Now it doesn't anymore.
> And your claim are quite unfair, given than the previous test didn't
> prevented trivial syntax errors to be commited.
Yes it did.
I provided you the "make test" log proving it.
Yours are not run anymore when running "make test".
What I did fail to mention is that they don't even work with that varible:
[root@localhost t]# TEST_AUTHOR=test perl pod-coverage.t
You said to run 0 tests at pod-coverage.t line 21.
You don't even have tried them, did you?
> Feel free to revert those changes, this kind of discussion isn't worth the
> pain.
Well, if that mean less quality testsuite and if you refuse to answer reviewing,
I'll eventually revert those or at least put back the old working pod test.
Re: [Mageia-dev] [soft-commits] [6620] obsoleted by pod-syntax.t
Le 09/12/2012 15:39, Thierry Vignaud a écrit :
Previous test did worked, it did catch errors before commiting them.
Yours does nothing:
t/pod-coverage.t
skipped: Author test, set $ENV{TEST_AUTHOR} to a true value to run
t/pod-spelling.t
skipped: Author test, set $ENV{TEST_AUTHOR} to a true value to run
t/pod-syntax.t ..
skipped: Author test, set $ENV{TEST_AUTHOR} to a true value to run
They work if you set the variable, as explicitely reported. That's
perfectly useless to run those tests anywhere else as on developper
machine, and especially during package build. And that's a standard
practice in perl community.
And your claim are quite unfair, given than the previous test didn't
prevented trivial syntax errors to be commited.
Feel free to revert those changes, this kind of discussion isn't worth
the pain.
--
BOFH excuse #337:
the butane lighter causes the pincushioning
Re: [Mageia-dev] Big problem with a rpm => freeswitch
Johnny A. Solbu skrev 9.12.2012 15:37: On Sunday 9. December 2012 14.27, Guillaume Rousse wrote: Why waste any time on such pile of crap, without any visibility on the desirability of such software in the distribution ? Good point. I am tempted to throw away the spec file and use the spec file from opensuse. It looks much better and have only defined a few sub packages. Well, this decision is not your to take, as dlucio is the maintainer and is responsible for sorting it out if he wants the package back in. But for now the rpms have been removed from repos until the listed issues are resolved. -- Thomas
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release mplayer-1.1-7.mga3
On 9 December 2012 01:10, luigiwalser wrote: > luigiwalser 1.1-7.mga3: > + Revision: 328988 > - fix building with updated giflib > - update bundled ffmpeg to 1.0.1 Please upload mplayer to tainted/release next time too...
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kernel-3.7.0-0.rc8.1.mga3
On 9 December 2012 15:00, Olivier Blin wrote:
>>> - add perf bash_completion
>>> - more filelist updates
>>> - add 3.7 buildfixes for alx, IFWLOG, mach64, ndiswrapper
>>> - pull in more upstream git fixes
>>> - rediff disable-mrproper patch
>>> - update to current rc8+ git
>>> - update filelists
>>> - update defconfigs
>>> - restore patch preferring ata over ide drivers
>>
>> BTW kernel-linus is still affected.
>> Of course this conflicts with the policy patch...
>
> Maybe something worth being submitted upstream then?
Or changing aliases order in ldetect.
With modules-init-tools, we used to pick the last alias:
// take the last one because we find eg: generic/ata_generic/sata_sil
struct module_alias *it = aliases;
while (it->next)
it = it->next;
result = strdup(it->module);
with kmod, we pick the first one (b/c that's the order that kept the same
results as with modules-init-tools, when I switched ldetect from unsupported
libm-i-t to kmod):
kmod_list_foreach(l, list) {
struct kmod_module *mod = kmod_module_get_module(l);
//if (str) // keep last one
// free(str);
if (!str) // keep first one
str = strdup(kmod_module_get_name(mod));
}
It used to works nicely but it appears that it works only good with a
patched kernel.
When we drop our patches, letect broke, reporting the wrong results
(https://bugs.mageia.org/show_bug.cgi?id=8315)
We could drop that patch for good and pick the last found alias instead of
the first one in ldetect.
See:
- the patch: https://bugs.mageia.org/attachment.cgi?id=3204
- the result in lscpidrake output on unpatched kernel:
https://bugs.mageia.org/attachment.cgi?id=3205
In fact, I'm considering submiting a patched ldetect with the changed ordering
to core/updates_testing and ask people to report the difference (if any)
between:
- core/release's ldetect + kernel-desktop
- core/updates_testing's ldetect + kernel-linus
WDYT?
Re: [Mageia-dev] [soft-commits] [6620] obsoleted by pod-syntax.t
On 6 December 2012 19:58, wrote:
> Revision 6620 Author guillomovitch Date 2012-12-06 19:58:17 +0100 (Thu, 06
> Dec 2012)
>
> Log Message
>
> obsoleted by pod-syntax.t
>
> Removed Paths
>
> rpm/urpmi/trunk/t/pod.t
NO
Please stop that madness.
Previous test did worked, it did catch errors before commiting them.
Yours does nothing:
t/pod-coverage.t
skipped: Author test, set $ENV{TEST_AUTHOR} to a true value to run
t/pod-spelling.t
skipped: Author test, set $ENV{TEST_AUTHOR} to a true value to run
t/pod-syntax.t ..
skipped: Author test, set $ENV{TEST_AUTHOR} to a true value to run
Stop commiting stuff without actually running the test suite!
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kernel-3.7.0-0.rc8.1.mga3
Thierry Vignaud writes: > On 7 December 2012 00:08, tmb wrote: >> tmb 3.7.0-0.rc8.1.mga3: >> + Revision: 327546 >> - add perf bash_completion >> - more filelist updates >> - add 3.7 buildfixes for alx, IFWLOG, mach64, ndiswrapper >> - pull in more upstream git fixes >> - rediff disable-mrproper patch >> - update to current rc8+ git >> - update filelists >> - update defconfigs >> - restore patch preferring ata over ide drivers > > BTW kernel-linus is still affected. > Of course this conflicts with the policy patch... Maybe something worth being submitted upstream then? -- Olivier Blin - blino
Re: [Mageia-dev] Big problem with a rpm => freeswitch
On Sunday 9. December 2012 10.28, Anne Nicolas wrote: > I'm blocked on isos since yesterday now. Looks like it's deleted from the repo, so you should be ok now. == [solbu@cauldron ~]$ LC_ALL=C urpmq -i freeswitch No package named freeswitch == Should propagate though most mirrors soon, if not already. -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] new environment variable for rpmbuild?
On 12/12/09 13:09 +0100, Olivier Blin wrote: > > On 12/12/06 19:45 +0100, nicolas vigier wrote: > >> On Thu, 06 Dec 2012, Jerome Quelin wrote: > >> > Would it be possible to add a new environment variable for rpmbuild to > >> > use when building rpms? > >> > > >> > new variable: PERL_AUTOINSTALL=--skipdeps > >> > >> If it's needed in %install, it can be added to %__spec_install_pre : > >> http://svnweb.mageia.org/soft/rpm/rpm-setup/trunk/build.macros.in?revision=6508&view=markup#l288 > >> > >> Is it needed in %prep or %build ? > > > > Sorry for the delay before answering - it's needed in %build. > > Can't we add some %__spec_build_pre macro with these then? I guess we can, but since I don't really know which is the best, please let met know what should be patched preferrably. Jérôme
Re: [Mageia-dev] Big problem with a rpm => freeswitch
On Sunday 9. December 2012 14.27, Guillaume Rousse wrote: > Why waste any time on such pile of crap, without any visibility on the > desirability of such software in the distribution ? Good point. I am tempted to throw away the spec file and use the spec file from opensuse. It looks much better and have only defined a few sub packages. I can look into that when I get home later tonight, unless we decide to just delete the whole thing. I have no problem with either solution. -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Big problem with a rpm => freeswitch
On Sun, Dec 9, 2012 at 2:27 PM, Guillaume Rousse wrote: > Why waste any time on such pile of crap, without any visibility on the > desirability of such software in the distribution ? Hi, do influential Mageia devs want this and push it, although it disrupts other packages? Where's the difference to the gnome2 forks? Regards, Götz -- AL I:40: Do what thou wilt shall be the whole of the Law.
Re: [Mageia-dev] Big problem with a rpm => freeswitch
Le 09/12/2012 13:46, Johnny A. Solbu a écrit : On Sunday 9. December 2012 11.19, Johnny A. Solbu wrote: I can help cleanup the spec I've done some initial cleanup and commited (but not submited). I'm sure some more cleanup is be needed, I can't do much more today. my familly requires my precense soon. :-)= I have not yet tested a full build, so I don't know if my cleanup broke the entire package. I only tested that configure ran without problems. There's a possibillity that some items ends up where it shouldn't. 2 notes: The sub package «codec-siren» have a reference in the description to patent licensing requirements for comercial use, which places it in tainted, unless it's already there. At the end of %configure and prior to starting %build, it contacts the internet for some reason. == Registering you for ClueCon http://www.cluecon.com . See you in August. ;-) == A patch to disable that might be required. Why waste any time on such pile of crap, without any visibility on the desirability of such software in the distribution ? -- BOFH excuse #250: Program load too heavy for processor to lift.
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
'Twas brillig, and Colin Guthrie at 09/12/12 12:18 did gyre and gimble: >> > What is needed is to add some directories and then the network will start >> > /var/run/netreport Hmm, even on my mga2 system, I have the following in /etc/tmpfiles.d/initscripts.conf: d /var/run/netreport 0775 root root - This should mean that on a fresh boot, the folder should be created for you on boot by systemd-tmpfiles-setup.service. >> > /var/lock/subsystem/network Actually, re the latter one in the list there, are you sure about it? I have no such folder on my Mga2 systems nor my Mga3 one. Are you perhaps referring to a /var/lock/subsys/network file? So I'm a little confused as to why you needed to create these by hand :s 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] Big problem with a rpm => freeswitch
On Sunday 9. December 2012 11.19, Johnny A. Solbu wrote: > I can help cleanup the spec I've done some initial cleanup and commited (but not submited). I'm sure some more cleanup is be needed, I can't do much more today. my familly requires my precense soon. :-)= I have not yet tested a full build, so I don't know if my cleanup broke the entire package. I only tested that configure ran without problems. There's a possibillity that some items ends up where it shouldn't. 2 notes: The sub package «codec-siren» have a reference in the description to patent licensing requirements for comercial use, which places it in tainted, unless it's already there. At the end of %configure and prior to starting %build, it contacts the internet for some reason. == Registering you for ClueCon http://www.cluecon.com . See you in August. ;-) == A patch to disable that might be required. -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] ANN: Upgrading from Mageia 2 via urpmi
'Twas brillig, and Thomas Spuhler at 08/12/12 22:51 did gyre and gimble: > On Sunday, November 18, 2012 09:37:43 AM Colin Guthrie wrote: >> Hi, >> >> As many of you know, upgrading from Mageia 2 is somewhat tricky due to >> the usr move. >> >> With Alpha3 comes the ability for the installer to upgrade the >> filesystem layout, but many of you (myself included) prefer upgrading >> via urpmi rather than the installer. >> >> While this is possible with some manual commands, it's not as trivial a >> task as it should be - until now!! >> >> So I've just pushed the package mageia-prepare-upgrade to mga2 >> core/updates_testing. >> >> This package, when installed will add a new menu option to your >> bootloader. Simply install this package, reboot, select the "Mageia 3 >> Upgrade Preparation" entry boot, wait while your FS is converted and >> then perform a urpmi upgrade as you would normally. >> >> I've not specifically tested the upgrade part, only the installation and >> creation of the initrd and bootloader entries in grub. I've also not >> done this on an mga2 machine yet but will do soon enough. >> >> I just wanted to get this package "out there" for anyone wanting to >> update their mga2 machines to mga3 a3 but not wanting to use the installer. >> >> At present there are a few limitations: >> >> 1. It requires kernel 3.3.8-2.mga2 to be installed (any flavour should >> work). A specific kernel version is not really 100% necessary but it >> does mean I can add hard requires to the package. This is only desirable >> to prevent the situation where users install this upgrade package but do >> not run it and later remove the kernel used to generate the initrd for >> the bootloader menu item, thus breaking it. Any smarter ideas on how to >> manage this welcome. >> >> 2. If you have /usr in a separate partition and have it mounted ro in >> your fstab, you will have to manually change the fstab to rw for the >> upgrade boot. >> >> >> Happy testing. Let me know if it kills any kittens. Please keep a backup >> etc. etc. >> >> Col > Thanks Colin. > The conversion works. But then the problem shows, we have no network. > doing a urpmi --download-all --auto-update only downloads the fist 120+ rpms > (the ones needed before > restart-urpmi > > What is needed is to add some directories and then the network will start > /var/run/netreport > /var/lock/subsystem/network > > I will check after the upgrade if they can be deleted Hmm, yes, I guess after doing the upgrade the various /var/run and /var/lock folders would be nuked. In mga3 they will be created by tmpfiles but not with a simple reboot on mga2... Hmm, I wonder how best to do this... perhaps we could ship updated packages for each of the packages which absolutely *need* this to do the download... or perhaps we could just ship some essential config tweaks in the this mageia-prepare-upgrade file. It shouldn't do any harm to do the latter and it's a bit easier on the QA folk. Cheers for the report 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] ANN: Upgrading from Mageia 2 via urpmi
'Twas brillig, and Remy CLOUARD at 08/12/12 12:25 did gyre and gimble: > On Sun, Nov 18, 2012 at 04:37:43PM +, Colin Guthrie wrote: >> Hi, >> > [...] >> So I've just pushed the package mageia-prepare-upgrade to mga2 >> core/updates_testing. > [...] >> >> Happy testing. Let me know if it kills any kittens. Please keep a backup >> etc. etc. >> >> Col >> > Hi Colin, > > I’ve followed the procedure and could upgrade my system from 2 to > cauldron, but I still have an issue with the filesystem package. > > Somehow it seems like it fails to move /var/run to /run and /var/lock to > /run/lock. > > I would be glad if there could be a workaround for this. > Here is a debug output of urpmi: > # export LC_ALL=C > # export LANG=C > # urpmi --debug filesystem > error: unpacking of archive failed on file /var/lock: cpio: rename > failed - Is a directory > error: filesystem-2.1.9-18.mga3.x86_64: install failed > error: filesystem-2.1.9-17.mga2.x86_64: erase skipped > unlocking urpmi database > unlocking rpm database > EXITING (pid=11661) > > The only way out I think would be to manually do the symlink from > another install. > > Could you confirm that ? Actually yes, there is still a problem at present with /var on a separate partition... I need to look into that. 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] new environment variable for rpmbuild?
Jerome Quelin writes: > On 12/12/06 19:45 +0100, nicolas vigier wrote: >> On Thu, 06 Dec 2012, Jerome Quelin wrote: >> > Would it be possible to add a new environment variable for rpmbuild to >> > use when building rpms? >> > >> > new variable: PERL_AUTOINSTALL=--skipdeps >> >> If it's needed in %install, it can be added to %__spec_install_pre : >> http://svnweb.mageia.org/soft/rpm/rpm-setup/trunk/build.macros.in?revision=6508&view=markup#l288 >> >> Is it needed in %prep or %build ? > > Sorry for the delay before answering - it's needed in %build. Can't we add some %__spec_build_pre macro with these then? -- Olivier Blin - blino
Re: [Mageia-dev] Big problem with a rpm => freeswitch
On Sunday 9. December 2012 01.57, D.Morgan wrote: > I think this package must be removed from mageia as long as its > packaging isn't cleaned and should be reviewed before being included > in mageia in the future. I can help cleanup the spec, unless someone else is already doing so. -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Big problem with a rpm => freeswitch
Le 09/12/2012 01:57, D.Morgan a écrit :
Hello,
while looking to beta1 isos pbs i saw a pb with a rpm that shouldn't
have been allowed to go in mageia cauldron. The package is freeswitch.
First the spec file is "excuse me the word" awful ( see
http://svnweb.mageia.org/packages/cauldron/freeswitch/current/SPECS/freeswitch.spec?revision=328996&view=markup
)
1- macro redefined
2- Use of some LIBDIR PKGCONFIGDIR macros instead of using the std
rpms macros like :
%define PREFIX %{_prefix}
%define EXECPREFIX %{_exec_prefix}
%define BINDIR %{_bindir}
%define SBINDIR %{_sbindir}
%define LIBEXECDIR %{_libexecdir}/%name
%define SYSCONFDIR %{_sysconfdir}/%name
%define SHARESTATEDIR %{_sharedstatedir}/%name
%define LOCALSTATEDIR %{_localstatedir}/lib/%name
%define LIBDIR %{_libdir}
%define INCLUDEDIR %{_includedir}
3- libs are in the main package
4- the package can break other packages like firefox as it provides
%{_libdir}/libnspr4.so
I think this package must be removed from mageia as long as its
packaging isn't cleaned and should be reviewed before being included
in mageia in the future.
Please do it for now. I'm blocked on isos since yesterday now.
WDYT ?
Regards,
D.
--
Anne
http://mageia.org
Re: [Mageia-dev] new environment variable for rpmbuild?
On 12/12/06 19:45 +0100, nicolas vigier wrote: > On Thu, 06 Dec 2012, Jerome Quelin wrote: > > Would it be possible to add a new environment variable for rpmbuild to > > use when building rpms? > > > > new variable: PERL_AUTOINSTALL=--skipdeps > > If it's needed in %install, it can be added to %__spec_install_pre : > http://svnweb.mageia.org/soft/rpm/rpm-setup/trunk/build.macros.in?revision=6508&view=markup#l288 > > Is it needed in %prep or %build ? Sorry for the delay before answering - it's needed in %build. Jérôme
Re: [Mageia-dev] Perl MIDI:ALSA module (package suggestion for Mageia)
On Sun, 9 Dec 2012, Remy CLOUARD wrote: > On Sat, Dec 08, 2012 at 02:43:47PM +0100, tux99-...@uridium.org wrote: > > Hi, > > If you are curious to see what can be done with the MIDI::ALSA Perl > > module have a look at a program I wrote with it: > > http://www.yamahaforums.co.uk/forum/viewtopic.php?f=9&t=5915 > > > Awesome ! > > Up until now I used to use simple sysexxer to transfer sysex to my DX7. > Editing patches on the DX7 is a major pain, because there is only one > slider to adjust each parameter for all oscillators. > Seems to me that this library will make it way easier to build apps that > do what this app does for the RM50. (maybe you have plans to support > other hardware ?) Yes, IMHO this library together with Perl/Tk (or GTK2-Perl if you prefer) for the GUI makes it very easy to write apps like this one, I have very little programming experience and I still managed to write this in a few weeks in my spare time (I did have basic Perl scripting experience but had never written such large GUI based app before). I might write similar apps for other synths I own in future but I don't own a DX7 (great synth!) so can't support that one. Regards, Andy
