Re: [Mageia-dev] fpc does *not* require gcc
Luca Olivetti schreef op 2013-02-28 11:18: The spec file of fpc has a Requires: gcc It's not true, it's a stand-alone, self-hosted compiler not dependent in any way on gcc. It requires binutils (the internal linker only works under windows), but not gcc. Hi Luca, Can you please file a bug report for this? Thanks, Remmy
Re: [Mageia-dev] freeze push: openmpi 1.6.4
On 28/02/13 21:39, Arnaud Patard (Rtp) wrote: Hi, Please push openmpi 1.6.4. It's a bug fix release and this one is building on arm. Amongst the various fixes, it's fixing some accidental abi breaking on the f90 librarie (it's putting back the right lib version number so would be annoying to release with wrong version). Thanks, Arnaud an email to the maintainer could have been welcome too... ? thanks anyway.
Re: [Mageia-dev] Bug #7633
On 28 February 2013 22:18, Olivier Blin wrote:
>> https://bugs.mageia.org/show_bug.cgi?id=7633
>>
>> Can we do something about this bug? 80+ people in CC getting spammed
>> every second day. If we can't fix it then let's drop it.
>
> Hi,
>
> Just putting an eval {} block like this in lib/MDV/Snapshot/Hal.pm
> should be enough:
>
> sub find_removable_volumes {
> my ($dbus) = @_; # perl_checker: $dbus = Net::DBus->new
> eval {
> my $hal = $dbus->get_service($hal_dn); # perl_checker: $dbus =
> Net::DBus->new
> my $manager = $hal->get_object($manager_path, $hal_manager); #
> perl_checker: $manager = Net::DBus::RemoteObject
> grep { is_proper_device($_, 1) } map { $hal->get_object($_,
> "$hal_dn.Device") } @{$manager->GetAllDevices};
> }
> }
>
> We just won't be able to automatically detect the backup disk mount point.
Or someone should do the same thing as for perl-Hal-Cdroms (should be
easy, just needs time):
http://svnweb.mageia.org/soft/perl-Hal-Cdroms/trunk/lib/Hal/Cdroms.pm?view=log
[Mageia-dev] Freeze push: worldofpadman and worldofpadman-data
Hi, According to what was discussed some days ago about this game[1], I modified worldofpadman package to package the original World of Padman engine, and packaged the data files in worldofpadman-data. As now we're including the data files which aren't completely free software, both packages need to go into nonfree. This means that the current package worldofpadman package on core/release needs to be removed from that repo before someone pushes worldofpadman-1.6-3 and worldofpadman-data-1.6-1 to nonfree. Thanks !! [1] http://article.gmane.org/gmane.linux.mageia.devel/22918 -- Juancho
Re: [Mageia-dev] A question about BuildRequires and other RPM questions.
On Thu, Feb 28, 2013 at 03:25:41PM +0100, Guillaume Rousse wrote: > Build dependencies are usually specified in installation > instructions. For humans, of course. You may also try to parse the > outpout of ./configure (or equivalent) script. In both case, there is > not garanty then every build dependency will get specified. The other way is to work backwards by looking at the install dependencies that rpmbuild discovered, or the NEEDED lines from objdump -x, and adding the -devel versions of those libraries. That won't catch any compile-time-only dependencies, though (like libtool, autoconf or flex) but it will give you something to start from. Note also that some programs will automatically discover what optional libraries are available at build time and configure themselves accordingly. So, if you miss some BuildRequires, you might end up with a binary that works but is missing features. >>> Dan
Re: [Mageia-dev] Bug #7633
Sander Lepik writes:
> Hi!
>
> https://bugs.mageia.org/show_bug.cgi?id=7633
>
> Can we do something about this bug? 80+ people in CC getting spammed
> every second day. If we can't fix it then let's drop it.
Hi,
Just putting an eval {} block like this in lib/MDV/Snapshot/Hal.pm
should be enough:
sub find_removable_volumes {
my ($dbus) = @_; # perl_checker: $dbus = Net::DBus->new
eval {
my $hal = $dbus->get_service($hal_dn); # perl_checker: $dbus =
Net::DBus->new
my $manager = $hal->get_object($manager_path, $hal_manager); #
perl_checker: $manager = Net::DBus::RemoteObject
grep { is_proper_device($_, 1) } map { $hal->get_object($_,
"$hal_dn.Device") } @{$manager->GetAllDevices};
}
}
We just won't be able to automatically detect the backup disk mount point.
--
Olivier Blin - blino
Re: [Mageia-dev] freeze push: openmpi 1.6.4
Arnaud Patard (Rtp) skrev 28.2.2013 22:39: Hi, Please push openmpi 1.6.4. It's a bug fix release and this one is building on arm. Amongst the various fixes, it's fixing some accidental abi breaking on the f90 librarie (it's putting back the right lib version number so would be annoying to release with wrong version). Thanks, Arnaud Submitted. -- Thomas
[Mageia-dev] freeze push: openmpi 1.6.4
Hi, Please push openmpi 1.6.4. It's a bug fix release and this one is building on arm. Amongst the various fixes, it's fixing some accidental abi breaking on the f90 librarie (it's putting back the right lib version number so would be annoying to release with wrong version). Thanks, Arnaud
Re: [Mageia-dev] Freeze push: sudo
David Walser skrev 28.2.2013 20:13: This updates to 1.8.6p7 which fixes a security issue only. Ubuntu has rated this as a high-severity security issue. http://www.sudo.ws/sudo/alerts/epoch_ticket.html http://www.sudo.ws/sudo/stable.html http://www.ubuntu.com/usn/usn-1754-1/ I've verified that it builds and works fine in Cauldron. Submitted. -- Thomas
[Mageia-dev] fpc does *not* require gcc
The spec file of fpc has a Requires: gcc It's not true, it's a stand-alone, self-hosted compiler not dependent in any way on gcc. It requires binutils (the internal linker only works under windows), but not gcc. Bye -- Luca
[Mageia-dev] Freeze push: sudo
This updates to 1.8.6p7 which fixes a security issue only. Ubuntu has rated this as a high-severity security issue. http://www.sudo.ws/sudo/alerts/epoch_ticket.html http://www.sudo.ws/sudo/stable.html http://www.ubuntu.com/usn/usn-1754-1/ I've verified that it builds and works fine in Cauldron.
Re: [Mageia-dev] A question about BuildRequires and other RPM questions.
Op donderdag 28 februari 2013 15:43:22 schreef Robert Wood: > On 28/02/13 14:25, Guillaume Rousse wrote: > > There is not much choice, beside building from a specified build > > environment, which is usually the minimal installation for your target > > distribution + rpmbuild. Most distributions use dedicated systems to > > automatically deploy such clean environment before eac package build > > attempt (iurt, mock, etc...). > > So, I should maybe install a minimal install on a virtual machine? Then > when it needs packages I can add those to the dependencies list? It > strikes me the problem with that would be that once you've added a load > of packages for one RPM, then started on another, you'd be back to the > same problem as before and need to keep reinstalling Mageia for each RPM > you do. There must be a better way than that. i myself have made a script that uses a minimal install btrfs subvolume, makes a snapshots for this package, then builds the rpm in a screen session, then removes the snapshot again. i use this script mostly for testbuilding on my local machine. in the past i just submitted it to the buildsystem (to updates_testing) when i was done working on it, and if it failed, i added some extra buildrequires, until it built, after that i did a final test > > Build dependencies are usually specified in installation instructions. > > For humans, of course. You may also try to parse the outpout of > > ./configure (or equivalent) script. In both case, there is not garanty > > then every build dependency will get specified. > > It sounds like there is a load of trial and error then? I am sure I must > misunderstand, building reliable RPMs must be a relatively > straightforward thing once you're up and running surely? trial and error for buildrequires yes, mostly for new packages, if you're updateing packages, you sort of know more about the package and if it has extra builddependencies, the BS will tell you this. so, in short for new packages you can have some trial and error (usually no more than 5 or 6 tries, wrt buildrequires). it's not such a big deal...
Re: [Mageia-dev] A question about BuildRequires and other RPM questions.
On 28/02/13 14:25, Guillaume Rousse wrote: There is not much choice, beside building from a specified build environment, which is usually the minimal installation for your target distribution + rpmbuild. Most distributions use dedicated systems to automatically deploy such clean environment before eac package build attempt (iurt, mock, etc...). So, I should maybe install a minimal install on a virtual machine? Then when it needs packages I can add those to the dependencies list? It strikes me the problem with that would be that once you've added a load of packages for one RPM, then started on another, you'd be back to the same problem as before and need to keep reinstalling Mageia for each RPM you do. There must be a better way than that. Build dependencies are usually specified in installation instructions. For humans, of course. You may also try to parse the outpout of ./configure (or equivalent) script. In both case, there is not garanty then every build dependency will get specified. It sounds like there is a load of trial and error then? I am sure I must misunderstand, building reliable RPMs must be a relatively straightforward thing once you're up and running surely?
Re: [Mageia-dev] A question about BuildRequires and other RPM questions.
Le 28/02/2013 12:55, Robert Wood a écrit : So, how do I make a list of that please? There is not much choice, beside building from a specified build environment, which is usually the minimal installation for your target distribution + rpmbuild. Most distributions use dedicated systems to automatically deploy such clean environment before eac package build attempt (iurt, mock, etc...). Also, I tried taking kwrite as an example, downloaded the .src RPM from a website (couldn't work out the wget thing) and managed to "blindly" build the RPM. That lists as shed load of files, mostly libraries that are needed. Again, how do I find these for this particular package? Do I need to compile first and use a tool that extracts all this information somehow? Build dependencies are usually specified in installation instructions. For humans, of course. You may also try to parse the outpout of ./configure (or equivalent) script. In both case, there is not garanty then every build dependency will get specified. -- BOFH excuse #257: That would be because the software doesn't work.
[Mageia-dev] A question about BuildRequires and other RPM questions.
I'm having a go at building an RPM. I have managed to compile this particular piece of software on my laptop under Open SuSE, but would like to compile on my desktop and thought it would be a really good idea to finally have a proper go at building RPMs. So, I'm ploughing through the tutorials and one thing I can't work out is just how to comprehensively list all the BuildRequires. I seem to remember when I compiled it on SuSE it had a couple of dependencies such as boot-devel and I suppose I could compile it on my machine and see what it requests, but I assume that is no good if another machine tries to install the RPM and I don't list one of the dependencies because it happened to be installed on my machine. Make sense?! So, how do I make a list of that please? Also, I tried taking kwrite as an example, downloaded the .src RPM from a website (couldn't work out the wget thing) and managed to "blindly" build the RPM. That lists as shed load of files, mostly libraries that are needed. Again, how do I find these for this particular package? Do I need to compile first and use a tool that extracts all this information somehow? I'm wondering whether there's a very simple, hello world find of spec file somewhere I could look at. I'm not convinced kwrite was the best example to take. Thanks.
Re: [Mageia-dev] [changelog] [RPM] 2 nonfree/updates_testing php-5.3.22-3.mga2.nonfree
Le 28/02/2013 09:36, oden a écrit : Name: php Relocations: (not relocatable) Version : 5.3.22Vendor: Mageia.Org Release : 3.mga2.nonfreeBuild Date: Thu Feb 28 09:24:14 2013 Install Date: (not installed) Build Host: jonund.mageia.org Group : Development/PHP Source RPM: (none) Size: 15406186 License: PHP License Signature : (none) Packager: oden URL : http://www.php.net Summary : The PHP5 scripting language [RPM] 2 nonfree/updates_testing php-5.3.22-3.mga2.nonfree php in nonfree ?? what is non-free in this update ? regards, Luc -- Luc Menut
Re: [Mageia-dev] Bug #7633
Op donderdag 28 februari 2013 11:27:14 schreef Sander Lepik: > https://bugs.mageia.org/show_bug.cgi?id=7633 > > Can we do something about this bug? 80+ people in CC getting spammed > every second day. If we can't fix it then let's drop it. i agree
[Mageia-dev] Bug #7633
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! https://bugs.mageia.org/show_bug.cgi?id=7633 Can we do something about this bug? 80+ people in CC getting spammed every second day. If we can't fix it then let's drop it. - -- Sander -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRLyLrAAoJECMkkFJIyHr8C/YH/02QozXAYzIR1MZGA3WGAW+y FMTvP9+12ubVgDDaJOr2yVmm8xCB7rgaM/Tu24vfhypr6+KOEhMjyTJr/FwIuYkC lykEvw+2Ta2EwJez6J6YTEml5/hUwvhXMRpYq7niVjBz2KhTiJJFvPa2ONNRaYDa JdHHotPd5dtDBiI3V2ICFMQpMv1c0D/MZziYgZAMnCWvySgh0cMmkK/A/vF6EDDq TPaZtQKjEVFsyBmTlTT9OcpEOymDDX0n/X+gD/Z5BO00Ref6gdfaOTkgkcoy28Z9 eK9kmLHa+5H6E9xdu1uIv4SHYj2h7OIqeg3BANaJY7TtoO29Af2Xk5f5TflZpAA= =bYyY -END PGP SIGNATURE-
Re: [Mageia-dev] Freeze push project-builder and rpmbootstrap
Le 28/02/2013 02:48, Bruno Cornec a écrit : Updated to upstream 0.12.2 as well. Done. -- BOFH excuse #206: Police are examining all internet packets in the search for a narco-net-trafficker
Re: [Mageia-dev] Freeze push: paranamer
Le 28/02/2013 01:55, D.Morgan a écrit : Hi, please push paranamer: Fixes buildwith current maven 3 Done. -- BOFH excuse #134: because of network lag due to too many people playing deathmatch
Re: [Mageia-dev] freeze push: drakxtools & drakx-installer-stage2
Thierry Vignaud skrev 28.2.2013 10:03: Hi please push drakxtools & drakx-installer-stage2 drakxtools - drakboot: o allow installing grub2 on a partition (mga#8462) o try harder not to have duplicate stuff on grub2 cmd line drakx-installer-stage2 - bootloader: o allow installing grub2 on a partition (mga#8462) o try harder not to have duplicate stuff on grub2 cmd line - do not put entry for CD/DVD in /etc/fstab (mga#7657) (it breaks urpmi) Thx Submitted. -- Thomas
