Re: [Mageia-dev] Upcoming release freeze: 14 packages needs fixing, by Sunday
On Tue, Apr 9, 2013 at 11:07 PM, Juergen Harms juergen.ha...@unige.chwrote: On 04/09/2013 11:03 AM, Christiaan Welvaart wrote: ... cross-avr-gcc ... The current package has the same rpmlint warnings so you don't need to fix this right now INHO. The hardlinks are only a problem when /usr/bin is on a different filesystem than /usr. I see there are still packages being pushed - if I manage tomorrow to submit a new cross-avr-gcc, would that still have a chance to get pushed before the freeze? would be nice if Mageia-3 contains a properly working avr cross compiler - and would reduce the count of packages that dont build. Well, given that current version can not even be installed, I don't think anyone will argue against getting the package pushed, it can't be worse. (no need to upgrade the avr-binutils package from 2.20 to 2.23 to satisfy that dependency: cross-avr-gcc seems to build and work correctly with cross-avr-binutils-2.20 which is presently in cauldron). Juergen
[Mageia-dev] uclibc
Can someone fix uclibc? It has been causing other autobuilds to fail many times as it will fork until the system is out of resources make CROSS= CC=gcc -C utils utils is requesting ../lib/libc.so.0.9.30.3 (before the lib exists) and it will try recursively to build lib/libc.so.0.9.30.3 until it fails to fork
[Mageia-dev] Packages not rebuilt since Mageia 1 (again)
Hi, I have started a wiki page (and included guillaume's comments about perl packages) https://wiki.mageia.org/en/Packages_Not_Rebuilt_Since_Mageia_1 There are 22 packages left Please help filling in the table so that we can quickly decide which ones to drop and fix the other ones Thanks
Re: [Mageia-dev] Packages not rebuilt since Mageia 1 (again)
On Fri, Apr 5, 2013 at 5:22 PM, Dimitrios Glentadakis dgl...@gmail.comwrote: I added a comment for kaption, the only thing that has to be done is to push it to the build system Do you mean that it was tested and the new version is working (at least) as well as the current one?
Re: [Mageia-dev] what's the purpose of this list ?
On Wed, Apr 3, 2013 at 10:32 AM, nicolas vigier bo...@mars-attacks.org wrote: On Wed, 03 Apr 2013, Guillaume Rousse wrote: Le 03/04/2013 07:59, Oliver Burger a écrit : 2013/4/2 Guillaume Rousse guillomovi...@gmail.com mailto:guillomovi...@gmail.com Since a few days, I'm getting mail through this list. But given their content, I don't any added value to keep it separated from the main mageia-dev one... It's not a list, it's the contact address for packagers team listed here: https://www.mageia.org/en/contact/ Let's rephrase my question then: what the point of a public contact address for packagers team ? Who is supposed to send what ? In most cases people should only use the mailing lists. They probably use it instead of the mailing list because it is easier to find it on the contact page linked from the menu. And they don't read the text saying that they should use the mailing list. So I think those addresses should be removed from the contact page, or at least the mailing lists should be easier to find. Maybe this contact address can be forwarded to the mailing list, or does it require people to be subscribed?
Re: [Mageia-dev] automated installer testing
On 28 Mar 2013 00:57, Glen Ogilvie n...@linuxsolutions.co.nz wrote: Hi, Has anyone done, or thought about, setting up some automated testing of the Mageia installer? I am thinking something based on: https://wiki.mageia.org/en/Auto_inst, testing inside a VM, with a range of different installer configurations, like: * different languages * Free / non-free * package selections, minimal, full, custom * partitioning optons * LVM options * encryption options * filesystem types * software raid options * known error cases (too small / filesystem), /boot on something not supported * grub and grub2 * different CPUs, RAM, architectures. I am thinking that if we had an auto-inst, with maybe 50 or so different test cases, all of which would then be verified by an ssh script connecting to the VM, or something like that. I've found 3 bugs recently, all of which would have been able to be detected by something like what I am suggesting. Suggestions so far are: nicolas vigier: * For automatic testing it would be possible to use OS-autoinst : http://www.os-autoinst.org/ * What we need is someone to add support for Mageia installer : https://github.com/bmwiedemann/os-autoinst/tree/master/distri Pierre-Malo Deniélou: Great idea. Can you prototype it? We should use something like that for mageia 4. Anne Nicolas: I remember some people starting something about it Furthermore it could be interested to have some virtualization for basic tests once rebooted We had been talking about it at Mandriva times but I don't remember if something was done. Something like testing the install goes to the end + system starts with for example console on serial port in kvm to parse it for errors and check the dm comes up + maybe run run some automated test scripts.
Re: [Mageia-dev] Packagers meeting tonight (26/03/3013, 20h UTC)
On Tue, Mar 26, 2013 at 1:44 PM, Pierre-Malo Deniélou pierre-malo.denie...@rhul.ac.uk wrote: Hi all, There will be a packagers meeting tonight at 20h UTC as usual. Only one topic: - Release critical bugs: review and status Please all attend for progress to be made on these bugs. Reminder: https://bugs.mageia.org/buglist.cgi?bug_status=NEWbug_status=UNCONFIRMEDbug_status=ASSIGNEDbug_status=REOPENEDbug_status=VERIFIEDpriority=release_blockerproduct=Mageiaquery_format=advancedversion=Cauldronorder=assigned_to%2Cbug_id%20DESCquery_based_on=release_blockerlist_id=2442 Can we also discuss what to do about http://check.mageia.org/cauldron/dependencies.html ? Should a thread be started for each to decide what to do about it? Bugs open? Any of those packages that doesn't get fixed will be dropped (as it can not be installed anyway)
[Mageia-dev] Packages not rebuilt since Mageia 1
There are 26 packages. atlas checklink kaption klibc maven-ant-tasks mcabber mcal notification-daemon-engine-nodoka pdumpfs perl-Apache-AuthCookie perl-Apache-GeoIP perl-Devel-Profiler perl-Dist-Zilla-Plugin-ProgCriticTests perl-HTTP-Daemon-SSL perlindex perl-Log-Agent perl-LWPx-ParanoidAgent perl-Template-Plugin-Latex perl-Text-Query perl-WebService-Validator-CSS-W3C perl-Yahoo-Search prelink ruby-mocha stratagus2.1 tritonus xmldb-api
[Mageia-dev] Packages not rebuilt since Mageia 2
There are 67 packages, including xemacs and drakx-installer-advertising: apache-commons-jexl aspectj avr-libc celtx chiliproject cross-avr-gcc drakx-installer-advertising ffmulticonverter forehead freepops gcl geronimo-jaspic-1.0-api gsl gupnp-dlna halibut hsqldb ini4j jawk jboss-ejb3-ext-api jboss-msc jeuclid-core jmol jnr-netdb jogl2 kde4-style-iaora kitchensync mathomatic maven-assembly-plugin maven-jar-plugin monodevelop-python monodevelop-vala msilbc netbeans omegat openfetion perl-Autodia perl-B-C perl-CGI-SSI perl-Class-Sniff perl-DBIx-Class-Schema-Loader perl-Dist-Zilla-PluginBundle-Author-RWSTAUNER perl-JSON-PP-Compat5006 perl-MIME-Lite-HTML perl-RT-Client-REST perl-SOAP-WSDL perl-TAP-Formatter-HTML php-lime php-pear-Mail_Mime plasma-applet-eventlist plexus-cli p-uae python-alsaaudio qmf qutecom rxtx servletapi4 sphinxbase tigervnc transifex ultracopier ultrastardx wahcade x11-driver-input x11-driver-video-sisimedia x11-driver-video-xgi xemacs xenserverjava
Re: [Mageia-dev] maven-dependency-tree (unsatisfied dep maven-artifact - cannot rebuild jetty)
On Sun, Mar 24, 2013 at 6:33 PM, Colin Guthrie mag...@colin.guthr.ie wrote: Hiya, It seems we cannot submit jetty due to the fact that it needs maven-dependancy-tree which cannot be installed due to missing maven-artifact. This is also needed for many other packages http://pkgsubmit.mageia.org/autobuild/results.php?run=2013-03-24 Can you/someone take a look and submit jetty when it's all working? 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] maven-dependency-tree (unsatisfied dep maven-artifact - cannot rebuild jetty)
On Sun, Mar 24, 2013 at 9:02 PM, Pascal Terjan pter...@gmail.com wrote: On Sun, Mar 24, 2013 at 6:33 PM, Colin Guthrie mag...@colin.guthr.ie wrote: Hiya, It seems we cannot submit jetty due to the fact that it needs maven-dependancy-tree which cannot be installed due to missing maven-artifact. This is also needed for many other packages Ah sorry, I see you have fixed it already :)
Re: [Mageia-dev] drakxtools drakx-installer-stage2 (mga#9428)
On 22 Mar 2013 22:21, Glen Ogilvie n...@linuxsolutions.co.nz wrote: On 23 March 2013 05:12, AL13N al...@rmail.be wrote: Op vrijdag 22 maart 2013 07:38:56 schreef Frank Griffin: On 03/22/2013 07:20 AM, Glen Ogilvie wrote: [...] 1. How does the src tar.xz file for drakx-installer-stage2 get created? I assume it comes from a build of svn://svn.mageia.org/svn/soft/drakx/trunk http://svn.mageia.org/svn/soft/drakx/trunk, but can't find how it ends up as a tar.xz I'm maybe about two days ahead of you on this, but here's what I think happens, FWIW. You do your checkout, and then in the mdk-stage1 subdirectory, do a make dist-svn. This should produce the tar.xz in the mdk-stage1 directory. [...] make dist actually... it will target make dist-svn or make dist-git depending on if you're using git-svn or not. be advised that dist-svn uses the BASE and any uncommitted change will not be applied. dist-git however, you can commit without pushing them and that will be used. I've had a good play around with make dist. It seems to me, like running make dist in the perl-install directory, (svn://svn.mageia.org/svn/soft/drakx/trunk/ ) does not produce the same tar.xz file as found within drakx-installer-stage2 sources. For example, the tar.gz produced by make dist does not contain the kernel, perl-install/install directories, etc. Also, inside the tar, the first directory is: drakxtools-15.29, rather than drakx-installer-stage2-15.29. It is also only 2.4MB instead of about 4.3MB. Any suggestions? Yes, you need to go into install subdirectory (if I remember the name correctly)
Re: [Mageia-dev] Why is AHCI statically compiled into kernel?
On Thu, Mar 7, 2013 at 10:04 AM, Anne Wilson an...@kde.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/03/13 09:55, jpbfree wrote: Le 07/03/2013 10:27, Anne Wilson a écrit : On 07/03/13 04:38, R James wrote: On Wed, Mar 6, 2013 at 1:37 PM, AL13N al...@rmail.be mailto:al...@rmail.be wrote: While I appreciate the intention, from a user PoV, those UUIDs mean b* all. It would be really nice if, when they are first named, it was possible to allocate a nickname for want of a better term. if you use it, filesystems also have label functionalities, which iinm are shown in dolphin. Yeah, I'm not a big fan of UUIDs either so I tend to use labels instead. I always partition and format using command-line tools in the Rescue System. If you do that, you can add the labels yourself. For example: # mkfs.ext4 -m 1 -L mgaroot /dev/sda1 # mkswap -L swap /dev/sda2 # mkfs.ext4 -m 0 -L home /dev/sda3 The -m parameters above specifies the percentage reserved for the superuser. the -L parameters are the filesystem labels. After that, reboot to the installer and choose Custom Partitioning, assign your pre-existing partitions and be sure _untick_ the [ ] Format boxes then continue installing as usual. After the installation, you can edit /boot/grub/menu.lst replacing each UUID=blahblahblah with LABEL=label. For example: root=LABEL=mgaroot (and) resume=LABEL=swap Similarly in /etc/fstab, you can have entries like: LABEL=mgaroot / ext4 relatime 1 1 LABEL=swap swap swap defaults 0 0 So the 'nickname' feature you request is available with a little pre-install preparation and post-install config file editing. Hope this helps -- RJ Thanks. It will help a lot for my own use. However, that really needs to be included in the gui disk partitioning, so that people can find and use it. I'm fairly sure there is no way to do that at present. Anne hum.. when in disk-patitioning on mcc if you toggle to expert mode therre is a label menu (have not tested it though, so don't know if it goes up to writing the right stanza in fstab). Really? I do normally enable Expert mode, and I've never noticed that! Next time I do an install I'll definitely look for it. It used to work fine at least :) I remember making some small changes to diskdrake 4 years ago like displaying the label in partition info even in non expert mode and had been using labels for many years through diskdrake I think there is a display bug when people have UTF-8 in the label
Re: [Mageia-dev] Dutch tax program dependencies
On Wed, Mar 6, 2013 at 8:44 AM, Guillaume Rousse guillomovi...@gmail.comwrote: Le 06/03/2013 00:50, Reinout van Schouwen a écrit : Hi all, The Dutch tax service makes life difficult for (64-bit) Mageia users because the tax filing program expects the i586 versions of libxext6 and libsm6 to be around. The tax service claim on their web site that Ubuntu 12.x and Linux Mint 13 are supported. Could it be that they have these libraries preinstalled on 64 bit platforms? Would it be possible to provide some kind of stub package that downloads the program with the required dependencies, like Arch does? ( https://aur.archlinux.org/**packages/belastingdienst-**ib2012/https://aur.archlinux.org/packages/belastingdienst-ib2012/) Most binary-only i586 programs expects additional 32 bits libraires dependencies: skype, for instance. On a pure 64 bits systems, these libraries won't be installed, and they won't even be available directly, as long as 32 bits additional package sources are not configured... I think we configure the 32 bits media by default Having a 32 bits package installing this app and having the proper dependencies would make sense I'm effraid than endlessly adding 32bits dependencies on our 64 bits packages, such as we did with pulseaudio for skype case, or adding 'stub' packages here, won't scale indefinitly to match every piece of softwares we can't distribute ourselves. First, they are exceptions to our 'self-containment' package sources policy... Second, dependencies won't adress the package source configuration issue. So, what about adressing end users intelligence, and document all those issues on a central 'compatibility' page on our wiki, instead of relying on such kind of hacks ? -- BOFH excuse #155: Dumb terminal
Re: [Mageia-dev] packages not rebuilt since Mageia 1 with old src.rpm building fine
On Mon, Feb 4, 2013 at 6:08 PM, Pascal Terjan pter...@gmail.com wrote: checklink-4.2.1-7.mga1.src.rpm: - updated by dams to 4.81 on 2012-06-19 - never uploaded as it requires perl(CSS::DOM) which is not available fbreader-0.12.10-5.mga1.src.rpm: - updated by fwang to 0.99.2 on 2012-09-14 - never uploaded, I don't know why kaption-0.0.9-1.mga1.src.rpm: - updated to 0.1.1 by dglent on 2012-09-09 - never uploaded, I don't know why Ping, what should be done with those packages? Complete list of 27 packages not rebuilt since Mageia 1: atlas-3.8.3-7.mga1.src.rpm checklink-4.2.1-7.mga1.src.rpm fbreader-0.12.10-5.mga1.src.rpm kaption-0.0.9-1.mga1.src.rpm klibc-1.5.21-5.mga1.src.rpm maven-ant-tasks-2.1.1-9.mga1.src.rpm mcabber-0.10.1-2.mga1.src.rpm mcal-0.7-16.mga1.src.rpm notification-daemon-engine-nodoka-0.1.0-3.mga1.src.rpm pdumpfs-1.3-6.mga1.src.rpm perl-Apache-AuthCookie-3.180.0-1.mga1.src.rpm perl-Apache-GeoIP-1.990.0-1.mga1.src.rpm perl-Devel-Profiler-0.40.0-1.mga1.src.rpm perl-Dist-Zilla-Plugin-ProgCriticTests-1.102.520-1.mga1.src.rpm perl-HTTP-Daemon-SSL-1.40.0-1.mga1.src.rpm perlindex-1.605.0-2.mga1.src.rpm perl-Log-Agent-0.307-3.mga1.src.rpm perl-LWPx-ParanoidAgent-1.70.0-1.mga1.src.rpm perl-Template-Plugin-Latex-3.20.0-1.mga1.src.rpm perl-Text-Query-0.70.0-6.mga1.src.rpm perl-WebService-Validator-CSS-W3C-0.200.0-1.mga1.src.rpm perl-Yahoo-Search-1.11.3-1.mga1.src.rpm prelink-0.4.4-1.20101123.1.mga1.src.rpm ruby-mocha-0.9.12-1.mga1.src.rpm stratagus2.1-2.1-4.mga1.src.rpm tritonus-0.3.7-0.0.20110107.2.mga1.src.rpm xmldb-api-0.1-0.1.2001cvs.1.2.5.mga1.src.rpm
Re: [Mageia-dev] [soft-commits] [7324] (call_blkid) always bypass blkid cache
On Thu, Feb 14, 2013 at 2:22 PM, r...@mageia.org wrote:
**
Revision 7324 Author colin Date 2013-02-14 15:22:44 +0100 (Thu, 14 Feb
2013) Log Message
(call_blkid) always bypass blkid cache
This reverts the use of the blkid cache.
This cache is a broken concept and should not be used. It's only
intended to be used for LABEL/UUID conversion.
Please add a comment in the code :)
From the upstream maintainer:
kzak coling: -p provides more information, the cache is designed for
LABEL/UUID conversion -- and the goal is to avoid the cache if possible
(it's mostly for backward compatibility). The ideal solution is to read
the information from udev DB.
kzak coling: man blkid (at least the latest version contains some hint
about this issue)
kzak coling: I'd like to learn people to use lsblk -- it's designed
more friendly for end-users as well as for scripts and it reads info
from udev, libblkid is only fallback here.
Longer term we should kill off the use of blkid and perhaps move to
lsblk or some perl-udev (if such a thing exists) usage instead:
kay coling: avoid the blkid cache, it is a completely broken idea
kay kzak: you should really kill that thing :)
kzak kay: I'd like to kill blkid at all and keep it as to test the
library binary...
kay kzak: tools with options like that talk for their sanity
themselves :) -g Perform a garbage collection pass on the blkid
cache to remove devices which no longer exist.
kay kzak: it's just silly, really silly to ever do that :)
kay kzak: yeah, sounds fine to let blkid and its cache die in the long
run
kzak lsblk is maintainable and extendable -- fix blkid(8) is
impossible to fix...
This reverts r6891.
Modified Paths
-
drakx/trunk/perl-install/NEWS#13cd91629257f7c0_drakxtrunkperlinstallNEWS
-
drakx/trunk/perl-install/fs/type.pm#13cd91629257f7c0_drakxtrunkperlinstallfstypepm
-
drakx/trunk/perl-install/install/NEWS#13cd91629257f7c0_drakxtrunkperlinstallinstallNEWS
Modified: drakx/trunk/perl-install/NEWS
===
--- drakx/trunk/perl-install/NEWS 2013-02-14 01:39:37 UTC (rev 7323)
+++ drakx/trunk/perl-install/NEWS 2013-02-14 14:22:44 UTC (rev 7324)
@@ -1,3 +1,5 @@
+- always bypass blkid cache (the cache only includes a subset of the data we
need)
+
Version 15.19 - 16 January 2013
- update translations
Modified: drakx/trunk/perl-install/fs/type.pm
===
--- drakx/trunk/perl-install/fs/type.pm 2013-02-14 01:39:37 UTC (rev
7323)
+++ drakx/trunk/perl-install/fs/type.pm 2013-02-14 14:22:44 UTC (rev
7324)
@@ -273,7 +273,7 @@
my %h = map {
if_(/(.*?)=(.*)/, $1 = $2);
-} run_program::get_stdout_raw({ timeout = 30 }, 'blkid', '2',
'/dev/null', '-o', 'udev', devices::make($part-{device}));
+} run_program::get_stdout_raw({ timeout = 30 }, 'blkid', '2',
'/dev/null', '-o', 'udev', '-p', devices::make($part-{device}));
\%h;
}
Modified: drakx/trunk/perl-install/install/NEWS
===
--- drakx/trunk/perl-install/install/NEWS 2013-02-14 01:39:37 UTC (rev
7323)
+++ drakx/trunk/perl-install/install/NEWS 2013-02-14 14:22:44 UTC (rev
7324)
@@ -1,3 +1,5 @@
+- always bypass blkid cache (the cache only includes a subset of the data we
need)
+
Version 15.20 - 21 January 2013
- use modprobe instead of insmod (mga#8676)
Re: [Mageia-dev] [RFC] rsyslog vs journalctl
On Fri, Feb 8, 2013 at 9:54 AM, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and AL13N at 07/02/13 18:40 did gyre and gimble: Op donderdag 7 februari 2013 13:34:06 schreef Colin Guthrie: 'Twas brillig, and AL13N at 07/02/13 11:40 did gyre and gimble: [...] what about the tty12 bug? can this be fixed with journald? it seems to be a feature that people don't want to lose? Not sure. I'll find out. It should be trivial really... i.e. all it really needs is a journalctl -f command run on tty12. You could craft an agetty command that worked like that easily enough, although there may be something more elegant that is more efficient and cleaner. since the tty12 feature is present now, it would be nice if it could still be there and started as soon as possible, just like before. Just to try it, can you set: TTYPath=/dev/tty12 ForwardToConsole=yes in /etc/systemd/journald.conf I'm not 100% sure whether it really should be available by default tho'. I mean, if you are a logged in user you cannot view the system logs unless you are in the adm group or root. Why should you just be able to see it via switching to a tty? Seems somewhat counter intuitive to me. I think it used to be enabled or not by msec depending on security level Of course you could say that if someone has physical access then all bets are off anyway... but IMO it does still seem slightly juxtaposed. Thoughts welcome on whether: a) This should be off by default (as now - but change from classic syslog) b) We should default it to on. c) We should provide an easy to use ticky box to turn it off/on easily via GUI. Regardless, we should probably configure all syslogs to not do this by default (as it will class if it's enabled in the journal). Thoughts? 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] rsyslog vs journalctl
On Fri, Feb 8, 2013 at 10:31 AM, Pascal Terjan pter...@gmail.com wrote: On Fri, Feb 8, 2013 at 9:54 AM, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and AL13N at 07/02/13 18:40 did gyre and gimble: Op donderdag 7 februari 2013 13:34:06 schreef Colin Guthrie: 'Twas brillig, and AL13N at 07/02/13 11:40 did gyre and gimble: [...] what about the tty12 bug? can this be fixed with journald? it seems to be a feature that people don't want to lose? Not sure. I'll find out. It should be trivial really... i.e. all it really needs is a journalctl -f command run on tty12. You could craft an agetty command that worked like that easily enough, although there may be something more elegant that is more efficient and cleaner. since the tty12 feature is present now, it would be nice if it could still be there and started as soon as possible, just like before. Just to try it, can you set: TTYPath=/dev/tty12 ForwardToConsole=yes in /etc/systemd/journald.conf I'm not 100% sure whether it really should be available by default tho'. I mean, if you are a logged in user you cannot view the system logs unless you are in the adm group or root. Why should you just be able to see it via switching to a tty? Seems somewhat counter intuitive to me. I think it used to be enabled or not by msec depending on security level /usr/share/msec/plugins/msec.py:def enable_console_log(self, arg, expr='*.*', dev='tty12'):
Re: [Mageia-dev] Is it possible running rebuildbot on ruby-* packages?
On Fri, Feb 8, 2013 at 7:40 AM, FundaWang fundaw...@fundawang.name wrote: Hello, Is it possible running rebuildbot on ruby-* packages? Due to new ruby-rdoc has been imported to fix CVE-2013-0256, all packages shipped rdoc files will need to be rebuilt. Is is possible doing this by umeabot? It is possible :)
Re: [Mageia-dev] Is it possible running rebuildbot on ruby-* packages?
On Fri, Feb 8, 2013 at 3:40 PM, Pascal Terjan pter...@gmail.com wrote: On Fri, Feb 8, 2013 at 7:40 AM, FundaWang fundaw...@fundawang.name wrote: Hello, Is it possible running rebuildbot on ruby-* packages? Due to new ruby-rdoc has been imported to fix CVE-2013-0256, all packages shipped rdoc files will need to be rebuilt. Is is possible doing this by umeabot? It is possible :) I have started it but forgot to exclude ruby itself from the list... Anyway, in progress
Re: [Mageia-dev] freeze push: perl-URPM urpmi
On Fri, Feb 8, 2013 at 8:42 PM, Anssi Hannula an...@mageia.org wrote: 08.02.2013 20:35, Thierry Vignaud kirjoitti: On 8 February 2013 14:35, Anssi Hannula an...@mageia.org wrote: please let in perl-URPM urpmi perl-URPM fixes a bug regarding installing delta rpm urpmi fixes counting erasures in progress bar. I think urpmi should probably not count erasures at all in the $cur/$total number, since IMHO the count should be for the packages installed instead of applied transactions, and package removal is usually much faster than installation. Try that on texlive-texmf :-) This does what you want, a separate counter for erasures Nice :) Probably should see if others agree with me or not before applying I guess... Everyone, WDYT? I thought of requesting such change when I ran the new version but then decided it was not important :)
Re: [Mageia-dev] [RFC] rsyslog vs journalctl
On Thu, Feb 7, 2013 at 1:30 PM, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Guillaume Rousse at 07/02/13 12:20 did gyre and gimble: Le 07/02/2013 12:40, AL13N a écrit : 'Twas brillig, and David Walser at 06/02/13 18:28 did gyre and gimble: [...] What I guess we could to to avoid putting rsyslog on the physical media would be to put a versioned conflicts in the main systemd package with rsyslog and syslog-ng. Thus the old packages should be removed when upgrading (AIUI). not a really good idea imho, i have a server which uses rsyslog for network remote syslogging... so upgrading that would break this. Indeed. Just because journal is installed (no choice here) shouldn't prevent to install a real syslog-daemon. I'd rather introduce another virtual package, such as syslog-daemon-minimal (or anything else), and lower the dependencies of basesystem to just require this last one. I'm not really sure what that gains... i.e. that's that's effectively what we have right now with the current provides of syslog-daemon via systemd itself. Arguably the semantics are wrong... e.g. it should really be called system-logger or something more generic. But as things stand you no longer *need* to install rsyslog et al - it's just an option. And as things stand right now, if rsyslog is included in the media it will be upgraded happily and keep on running. I was wondering if some packages(like fail2ban) may want to require a traditional syslog
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release makedev-4.4-15.mga3
On Wed, Feb 6, 2013 at 6:01 PM, Thierry Vignaud thierry.vign...@gmail.com wrote: On 6 February 2013 14:43, pterjan buildsystem-dae...@mageia.org wrote: pterjan pterjan 4.4-15.mga3: + Revision: 394833 - Do not do anything in post if /dev is devtmpfs Which means we never create /dev static entries at all. Never in drakx, never in live mode. I test if /dev is a different mountpoint so that they get created in chroots
Re: [Mageia-dev] Packager's meeting
On Tue, Feb 5, 2013 at 9:03 AM, Anne Nicolas enna...@gmail.com wrote: Hi there We will have our meeting tonight focused on release critical bugs review. Please have a look before on https://bugs.mageia.org/buglist.cgi?cmdtype=runnamednamedcmd=release_blocker I am wondering how to handle packages failing to build, especially the ones with different version in svn Should I open individual bugs? I am planning to try building failing packages with -j4 instead of -j12 to get a list of the ones which are really broken but I don't know how to handle the discussion on which ones to drop and which ones really need to be fixed $ ls /distrib/bootstrap/distrib/cauldron/SRPMS/core/release/ | sed -n 's/.*mga\([0-9]\).src.rpm/\1/p' | sort | uniq -c 34 1 119 2 10869 3 (for those not familiar with sed, this means 34 packages still have a mga1 tag which mean they haven't been rebuilt since Mageia 1 was released and 119 have not been rebuilt since Mageia 2 was released)
Re: [Mageia-dev] Packager's meeting
On Tue, Feb 5, 2013 at 11:18 AM, nicolas vigier bo...@mars-attacks.org wrote: On Tue, 05 Feb 2013, Sander Lepik wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 05.02.2013 13:04, Pascal Terjan kirjutas: On Tue, Feb 5, 2013 at 9:03 AM, Anne Nicolas enna...@gmail.com wrote: Hi there I am planning to try building failing packages with -j4 instead of -j12 to get a list of the ones which are really broken but I don't know how to handle the discussion on which ones to drop and which ones really need to be fixed Can't we have some macro for that in the build system. %make_j4 ? So we could fix them and switch the build system's %make to -j12 by default in the future? I'm not sure it's useful to have a %make_j4 macro. It's already possible to do make -j4 without using a macro. And they should rather get fixed as it's only by chance if they work with -j4 now, any change in the Makefile may make them only work with -j3 or -j5...
Re: [Mageia-dev] urpmi counts gone askew
On Mon, Feb 4, 2013 at 2:19 PM, Frank Griffin f...@roadrunner.com wrote: Not sure this is worth a bug report, since I doubt I could reproduce it, but check out the package number/total output in this morning's cauldron update: Just a guess, can it be old package removal which are now displayed as installations but with a negative total and another counter?
[Mageia-dev] packages not rebuilt since Mageia 1 with old src.rpm building fine
Out of the 35 packages not rebuilt since Mageia 1, here is a list of the 8 which are not detected by autobuild as the old src.rpm builds fine but not the version in svn or the package is rejected New version in svn that was never uploaded == checklink-4.2.1-7.mga1.src.rpm: - updated by dams to 4.81 on 2012-06-19 - never uploaded as it requires perl(CSS::DOM) which is not available fbreader-0.12.10-5.mga1.src.rpm: - updated by fwang to 0.99.2 on 2012-09-14 - never uploaded, I don't know why kaption-0.0.9-1.mga1.src.rpm: - updated to 0.1.1 by dglent on 2012-09-09 - never uploaded, I don't know why transfugdrake-1.9.4-1.mga3.src.rpm: - updated by ennael to 1.9.5 on 2012-05-02 - never uploaded, I don't know why Rejected, need an exception in rpmlint config = nagios-check_rsync-1.02-5.mga1.src.rpm: - unexpanded-macro URL %2F2094 nagios-check_syncrepl-20080409-8.mga1.src.rpm: - unexpanded-macro URL %2F2477 php-pear-Testing_Selenium-0.3.1-8.mga3.src.rpm: - php-pear-Testing_Selenium.noarch: W: unexpanded-macro /usr/share/doc/php-pear-Testing_Selenium/docs/Documentation/26d3399f63abd43a7d72f8c21440dcb0/%%239^%%239105369^footer.tpl.php %%239 (and many more files) Fails to build, needs to be fixed = xmldb-api-0.1-0.1.2001cvs.1.2.5.mga3.src.rpm: - requires omquery which seems to no longer exist - required by ws-jaxme, which is required by plenty of packages (omegat cxf-xjc-utils dom4j resteasy xmlrpc-common eclipse-mylyn eclipse-mylyn-builds-hudson omegat cxf-xjc-utils dom4j resteasy xmlrpc-common eclipse-mylyn-builds-hudson eclipse-mylyn)
Re: [Mageia-dev] packages not rebuilt since Mageia 1 with old src.rpm building fine
On Mon, Feb 4, 2013 at 6:08 PM, Pascal Terjan pter...@gmail.com wrote: Out of the 35 packages not rebuilt since Mageia 1, here is a list of the 8 which are not detected by autobuild as the old src.rpm builds fine but not the version in svn or the package is rejected New version in svn that was never uploaded == checklink-4.2.1-7.mga1.src.rpm: - updated by dams to 4.81 on 2012-06-19 - never uploaded as it requires perl(CSS::DOM) which is not available fbreader-0.12.10-5.mga1.src.rpm: - updated by fwang to 0.99.2 on 2012-09-14 - never uploaded, I don't know why kaption-0.0.9-1.mga1.src.rpm: - updated to 0.1.1 by dglent on 2012-09-09 - never uploaded, I don't know why transfugdrake-1.9.4-1.mga3.src.rpm: - updated by ennael to 1.9.5 on 2012-05-02 - never uploaded, I don't know why Rejected, need an exception in rpmlint config = nagios-check_rsync-1.02-5.mga1.src.rpm: - unexpanded-macro URL %2F2094 nagios-check_syncrepl-20080409-8.mga1.src.rpm: - unexpanded-macro URL %2F2477 php-pear-Testing_Selenium-0.3.1-8.mga3.src.rpm: - php-pear-Testing_Selenium.noarch: W: unexpanded-macro /usr/share/doc/php-pear-Testing_Selenium/docs/Documentation/26d3399f63abd43a7d72f8c21440dcb0/%%239^%%239105369^footer.tpl.php %%239 (and many more files) Fails to build, needs to be fixed = xmldb-api-0.1-0.1.2001cvs.1.2.5.mga3.src.rpm: - requires omquery which seems to no longer exist - required by ws-jaxme, which is required by plenty of packages (omegat cxf-xjc-utils dom4j resteasy xmlrpc-common eclipse-mylyn eclipse-mylyn-builds-hudson omegat cxf-xjc-utils dom4j resteasy xmlrpc-common eclipse-mylyn-builds-hudson eclipse-mylyn) Actually I had missed the snapshot date change On 2011-06-29, it was updated from 2001 to 20041010 by gil, changing the spec a lot including a new dependency on omquery which was never uploaded The package is dead in Fedora and they removed the support for it in ws-jaxme with http://pkgs.fedoraproject.org/cgit/ws-jaxme.git/tree/ws-jaxme-remove-xmldb.patch
Re: [Mageia-dev] Please remove qemu, and qemu-img from Mageia 3.
On Sun, Feb 3, 2013 at 9:45 AM, David W. Hodgins davidwhodg...@gmail.com wrote: During testing of updates to qemu, and x11-driver-video-qxl, it has become very clear that no-one could possibly be using these packages, as they are so slow, as to be useless. Try loading kvm module and selecting the fast drivers for network/disk/... Over 6 hours to do a net install of a kde x86-64 system, on hardware where that would normally be under 20 minutes. There are many problems with xorg crashing, mouse pointer not being where the pointer is shown, etc. These bugs are described in https://bugs.mageia.org/show_bug.cgi?id=8938 Please drop these useless packages, so we don't have to test or install security updates for them. They are useful
Re: [Mageia-dev] [council] *ping* Media query: secure boot support
On Tue, Jan 29, 2013 at 10:02 AM, Guillaume Rousse guillomovi...@gmail.com wrote: Le 29/01/2013 10:37, Wolfgang Bornath a écrit : As for now Microsoft requires all W8 certified systems with secure boot to allow secure boot to be switched off by user/sysadmin. One reason why I do not understand the reason why all these people (Garret et all) are stumbling all over themselves to solve a problem which is not even sure to ever come by. I guess that's because secure boot may be considered useful, if you're in control of it, of course. And because something working out of the box is probably better when targetting non-experts. Yes I think the main problem is that for probably 10 years it had became easy for someone non technical to test/install linux, now they would need to change setup in the bios and would probably give up (or be scared).
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release makedev-4.4-14.mga3
On Mon, Jan 14, 2013 at 5:37 PM, Pascal Terjan pter...@gmail.com wrote: On Sun, Jan 13, 2013 at 8:19 PM, tv buildsystem-dae...@mageia.org wrote: Name: makedev Relocations: (not relocatable) Version : 4.4 Vendor: Mageia.Org Release : 14.mga3 Build Date: Sun Jan 13 21:06:51 2013 Install Date: (not installed) Build Host: ecosse.mageia.org Group : System/Kernel and hardwareSource RPM: (none) Size: 58419License: GPLv2+ Signature : (none) Packager: tv tv URL : http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/soft/makedev/ Summary : A program used for creating the device files in /dev Description : This package contains the makedev program, which makes it easier to create and maintain the files in the /dev directory. /dev directory files correspond to a particular device supported by Linux (serial or printer ports, scanners, sound cards, tape drives, CD-ROM drives, hard drives, etc.) and interface with the drivers in the kernel. The makedev package is a basic part of your Mageia system and it needs to be installed. tv tv 4.4-14.mga3: + Revision: 378420 - fix upgrading (not corrupting devtmpfs) - devfs is dead for nearly a decade This package causes /usr/lib/root-mirror being in mounted in chroots on the build system (and not being umounted) during clean chroot creation sucuk had 65 mounted, oldest one being /home/iurt/chroot_tmp/iurt/chroot_cauldron.i586.0.20130113202409/usr/lib/root-mirror just after this package was uploaded Can someone have a look? [root@jonund ~]# mount | wc -l 277 This is annoying to cleanup on the build machines... (and at home when running iurt)
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release makedev-4.4-14.mga3
On Tue, Jan 29, 2013 at 12:04 PM, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Pascal Terjan at 29/01/13 11:51 did gyre and gimble: On Mon, Jan 14, 2013 at 5:37 PM, Pascal Terjan pter...@gmail.com wrote: On Sun, Jan 13, 2013 at 8:19 PM, tv buildsystem-dae...@mageia.org wrote: Name: makedev Relocations: (not relocatable) Version : 4.4 Vendor: Mageia.Org Release : 14.mga3 Build Date: Sun Jan 13 21:06:51 2013 Install Date: (not installed) Build Host: ecosse.mageia.org Group : System/Kernel and hardwareSource RPM: (none) Size: 58419License: GPLv2+ Signature : (none) Packager: tv tv URL : http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/soft/makedev/ Summary : A program used for creating the device files in /dev Description : This package contains the makedev program, which makes it easier to create and maintain the files in the /dev directory. /dev directory files correspond to a particular device supported by Linux (serial or printer ports, scanners, sound cards, tape drives, CD-ROM drives, hard drives, etc.) and interface with the drivers in the kernel. The makedev package is a basic part of your Mageia system and it needs to be installed. tv tv 4.4-14.mga3: + Revision: 378420 - fix upgrading (not corrupting devtmpfs) - devfs is dead for nearly a decade This package causes /usr/lib/root-mirror being in mounted in chroots on the build system (and not being umounted) during clean chroot creation sucuk had 65 mounted, oldest one being /home/iurt/chroot_tmp/iurt/chroot_cauldron.i586.0.20130113202409/usr/lib/root-mirror just after this package was uploaded Can someone have a look? [root@jonund ~]# mount | wc -l 277 This is annoying to cleanup on the build machines... (and at home when running iurt) Do we really need makedev these days? That's a good question :) iurt needs it because I still haven't fixed it to mount /dev but as a general thing I don't think so.
Re: [Mageia-dev] python-distribute / python-pkg-resources again
On Tue, Jan 29, 2013 at 2:36 PM, Thomas Spuhler tho...@btspuhler.com wrote: On Tuesday, January 29, 2013 02:06:54 AM Pascal Terjan wrote: file /usr/lib/python2.7/site-packages/pkg_resources.py from install of python-distribute-0.6.34-3.mga3.noarch conflicts with file from package python-pkg-resources-0.6.28-4.mga3.noarch Maybe I should add a conflicts to the package. What is the difference, why do they provide the same files?
Re: [Mageia-dev] Package drop request: more ruby packages
On Wed, Dec 19, 2012 at 9:41 PM, Remy CLOUARD shikam...@mageia.org wrote: Hi, Could someone remove the following RPMs from the repos: ruby-rcov-doc: ruby-rcov has been superseded by ruby-simplecov, has been removed from the mirrors, but the -doc package is still there ruby-oa-oauth and ruby-oa-oauth-doc ruby-oa-more and ruby-oa-more-doc ruby-oa-enterprise and ruby-oa-enterprise-doc ruby-oa-core and ruby-oa-core-doc ruby-oa-openid and ruby-oa-openid-doc ruby-oa-basic and ruby-oa-basic-doc the reason for dropping all these ruby-oa packages is because the omniauth framework is packaged very differently starting from 1.0. This break teambox but the package has many more broken dependencies and is rather outdated (there’s a rails 3 branch I should update it to) What is the plan with teambox? Should it be dropped?
Re: [Mageia-dev] [changelog] cauldron core/release task-obsolete-3-56.mga3
On Mon, Jan 28, 2013 at 11:37 AM, Jose Jorge lists.jjo...@free.fr wrote: Le 28/01/2013 09:53, Guillaume Rousse a écrit : No, that's false. You have to remove obsoletes package from mirrors, there is no obligation to remove it from end user machines. And isn't the purpose of task-obsoletes to remove from mirrors? No, it is to remove from users machine when the packages will not work/break other things/have security problems/... and there is no replacement The same discussion happened here when proprietary java was removed from the distro, let's not start it again...
Re: [Mageia-dev] [changelog] cauldron core/release task-obsolete-3-56.mga3
On Mon, Jan 28, 2013 at 6:07 PM, Jose Jorge lists.jjo...@free.fr wrote: Le 28/01/2013 13:26, Pascal Terjan a écrit : And isn't the purpose of task-obsoletes to remove from mirrors? No, it is to remove from users machine when the packages will not work/break other things/have security problems/... and there is no replacement So I badly understood the wiki : https://wiki.mageia.org/en/Packaging_guidelines#Obsoleting_a_package I think there was a discussion recently about defining it better :)
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release lcdproc-0.5.6-6.mga3
On Sun, Jan 27, 2013 at 4:50 PM, AL13N al...@rmail.be wrote: Op zondag 27 januari 2013 17:43:50 schreef Thierry Vignaud: On 27 January 2013 17:32, AL13N al...@rmail.be wrote: alien alien 0.5.6-6.mga3: + Revision: 391755 + rebuild (emptylog) what for? autobuild failed that release, but for some reason i had to bump release anyway... rebuild did succeeded: * Sat Jan 12 2013 umeabot umeabot 0.5.6-2.mga3 + Revision: 356696 - Mass Rebuild - https://wiki.mageia.org/en/Feature:Mageia3MassRebuild and it was rebuild again later. You should have stopped when seeing you'd to bump release as that mean that previous build was successful.. i donno how to fix this properly. what should i do with revision logs? not the mass rebuild, but on of the autobuilds kept showing lcdproc as failed. i had to rebuild it for it to show up properly. it meant i had a personal entry on check.mageia.org If you just rebuild it without fixing anything, it will come back next time...
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release lcdproc-0.5.6-6.mga3
On Sun, Jan 27, 2013 at 5:05 PM, Pascal Terjan pter...@gmail.com wrote: On Sun, Jan 27, 2013 at 4:50 PM, AL13N al...@rmail.be wrote: Op zondag 27 januari 2013 17:43:50 schreef Thierry Vignaud: On 27 January 2013 17:32, AL13N al...@rmail.be wrote: alien alien 0.5.6-6.mga3: + Revision: 391755 + rebuild (emptylog) what for? autobuild failed that release, but for some reason i had to bump release anyway... rebuild did succeeded: * Sat Jan 12 2013 umeabot umeabot 0.5.6-2.mga3 + Revision: 356696 - Mass Rebuild - https://wiki.mageia.org/en/Feature:Mageia3MassRebuild and it was rebuild again later. You should have stopped when seeing you'd to bump release as that mean that previous build was successful.. i donno how to fix this properly. what should i do with revision logs? not the mass rebuild, but on of the autobuilds kept showing lcdproc as failed. i had to rebuild it for it to show up properly. it meant i had a personal entry on check.mageia.org If you just rebuild it without fixing anything, it will come back next time... Looking at the failure logs: gcc -fPIC -Wall -O3 -Wno-unused-function -shared -o hd44780.so hd44780-hd44780.o libLCD.a hd44780-hd44780-serial.o hd44780-hd44780-lis2.o hd44780-hd44780-usblcd.o hd44780-hd44780-4bit.o hd44780-hd44780-ext8bit.o hd44780-lcd_sem.o hd44780-hd44780-winamp.o hd44780-hd44780-serialLpt.o hd44780-hd44780-bwct-usb.o hd44780-hd44780-lcd2usb.o hd44780-hd44780-uss720.o hd44780-hd44780-usbtiny.o hd44780-hd44780-usb4all.o hd44780-hd44780-ftdi.o hd44780-hd44780-ethlcd.o hd44780-hd44780-i2c.o -lusb -lftdi -lusb libbignum.a -ldl gcc: error: libbignum.a: No such file or directory make[3]: *** [hd44780.so] Error 1 make[3]: Leaving directory `/home/pterjan/rpmbuild/BUILD/lcdproc-0.5.6/server/drivers' So in the Makefile in server/drivers, hd44780.so needs to depend on libbignum.a
Re: [Mageia-dev] nepomukextras / nepomukannotation / kolena
On Sun, Jan 27, 2013 at 5:30 PM, Nicolas Lécureuil nicolas.lecure...@free.fr wrote: Le dimanche 27 janvier 2013 16:58:01 Pascal Terjan a écrit : I was looking at the packages that have not been built since Magea 1 nepomukextras is one of them, required only by nepomukannotation that nothing requires, they haven't been updated upstream for 2 years They both can't be built because they need libkolena0 which is not installable (requires an old libtesseract_api) and they are the only think using kolena kolena doesn't build: -- Could NOT find KDE4Workspace (missing: KDE4Workspace_CONFIG) -- Could NOT find Tesseract (missing: TESSERACT_LIBRARY) -- Could NOT find TIFF (missing: TIFF_LIBRARY TIFF_INCLUDE_DIR) Should we drop them all? please remove them if you can OK I will, thanks
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release lcdproc-0.5.6-6.mga3
On Sun, Jan 27, 2013 at 7:14 PM, AL13N al...@rmail.be wrote: Op zondag 27 januari 2013 17:18:01 schreef Pascal Terjan: On Sun, Jan 27, 2013 at 5:05 PM, Pascal Terjan pter...@gmail.com wrote: On Sun, Jan 27, 2013 at 4:50 PM, AL13N al...@rmail.be wrote: Op zondag 27 januari 2013 17:43:50 schreef Thierry Vignaud: On 27 January 2013 17:32, AL13N al...@rmail.be wrote: alien alien 0.5.6-6.mga3: + Revision: 391755 + rebuild (emptylog) what for? autobuild failed that release, but for some reason i had to bump release anyway... rebuild did succeeded: * Sat Jan 12 2013 umeabot umeabot 0.5.6-2.mga3 + Revision: 356696 - Mass Rebuild - https://wiki.mageia.org/en/Feature:Mageia3MassRebuild and it was rebuild again later. You should have stopped when seeing you'd to bump release as that mean that previous build was successful.. i donno how to fix this properly. what should i do with revision logs? not the mass rebuild, but on of the autobuilds kept showing lcdproc as failed. i had to rebuild it for it to show up properly. it meant i had a personal entry on check.mageia.org If you just rebuild it without fixing anything, it will come back next time... Looking at the failure logs: gcc -fPIC -Wall -O3 -Wno-unused-function -shared -o hd44780.so hd44780-hd44780.o libLCD.a hd44780-hd44780-serial.o hd44780-hd44780-lis2.o hd44780-hd44780-usblcd.o hd44780-hd44780-4bit.o hd44780-hd44780-ext8bit.o hd44780-lcd_sem.o hd44780-hd44780-winamp.o hd44780-hd44780-serialLpt.o hd44780-hd44780-bwct-usb.o hd44780-hd44780-lcd2usb.o hd44780-hd44780-uss720.o hd44780-hd44780-usbtiny.o hd44780-hd44780-usb4all.o hd44780-hd44780-ftdi.o hd44780-hd44780-ethlcd.o hd44780-hd44780-i2c.o -lusb -lftdi -lusb libbignum.a -ldl gcc: error: libbignum.a: No such file or directory make[3]: *** [hd44780.so] Error 1 make[3]: Leaving directory `/home/pterjan/rpmbuild/BUILD/lcdproc-0.5.6/server/drivers' So in the Makefile in server/drivers, hd44780.so needs to depend on libbignum.a hd44780_LDADD = libLCD.a @HD44780_DRIVERS@ @LIBUSB_LIBS@ @LIBFTDI_LIBS@ libbignum.a hd44780_DEPENDENCIES = @HD44780_DRIVERS@ so, i should move it to dependencies instead of ldadd in the Makefile.am and use autoreconf -i instead... but... this isn't the only driver, does this mean i'll have to change dependencies for almost all these drivers? I don't know if they use the lib :)
Re: [Mageia-dev] [soft-commits] [7213] Check-in debuginfo-install
On Sat, Jan 26, 2013 at 4:22 PM, r...@mageia.org wrote:
Revision 7213 Author kamil Date 2013-01-26 17:22:26 +0100 (Sat, 26 Jan 2013)
Log Message
Check-in debuginfo-install
Added Paths
rpm/debuginfo-install/trunk/debuginfo-install
Added: rpm/debuginfo-install/trunk/debuginfo-install
===
--- rpm/debuginfo-install/trunk/debuginfo-install
(rev 0)
+++ rpm/debuginfo-install/trunk/debuginfo-install 2013-01-26 16:22:26 UTC
(rev 7213)
@@ -0,0 +1,14 @@
+#!/usr/bin/sh
+# Kamil Rytarowski 2012, kamil AT mageia DOT org | n54 AT gmx DOT com
+# Any copyright is dedicated to the Public Domain.
+# http://creativecommons.org/publicdomain/zero/1.0/
+
+urpmi_args=
+
+while [ $1 ]; do
+ new_arg=`urpmq --sourcerpm $1|awk -F': ' '{print $2}'|sed
's/-[^-]*-[^-]*$/-debuginfo/'`
+ urpmi_args=$urpmi_args $new_arg
+ shift
+done
You can run urpmq only once with all the args but as the packages are
installed, I would just use rpmquery
urpmi $(rpmquery --qf %{SOURCERPM}\n $@ | sed 's/-[^-]*-[^-]*$/-debuginfo/')
That should make things faster :)
Re: [Mageia-dev] /run/httpd (maybe others) breaking features
On Thu, Jan 24, 2013 at 9:24 AM, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Pascal Terjan at 24/01/13 01:40 did gyre and gimble: On Thu, Jan 24, 2013 at 12:45 AM, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Pascal Terjan at 24/01/13 00:24 did gyre and gimble: I was looking at perl-Apache2-DebugFilter build failure In the test it starts an apache which fails as it uses http://httpd.apache.org/docs/trunk/rewrite/rewritemap.html#prg which uses a mutex stored in /run/httpd/ [Wed Jan 23 23:49:55.962405 2013] [core:emerg] [pid 55277] (13)Permission denied: AH00023: Couldn't create the rewrite-map mutex (file /run/httpd/rewrite-map.55277) That directory is now owned by root so it can't be used for anything except creating the httpd.pid $ cat /usr/lib/tmpfiles.d/httpd.conf d /run/httpd 755 root root Fedora uses d /run/httpd 710 root apache which doesn't help in this case but fixes other problems In the past (Mageia 1) runtimedir was /var/run directly so it was possible to create mutex files there for any user Hmm, not sure what you mean here. [colin@mga2 ~]$ ls -ld /var/run drwxr-xr-x 38 root root 4096 Jan 23 04:04 /var/run/ That dir is also owned by root with 755 perm. It shouldn't make any odds to permissions. Hmm you are right, I don't know why it got broken then It used to use /var/run/ as runtime dir and it succeeded creating the mutex It now fails to create it in /run/httpd/ I don't have more clues :( It may be some change in apache but I couldn't find, I'll try to find out more tomorrow If this is on the build system, perhaps the tmpfiles stuff isn't run for some reason and /run/httpd isnt't created. And then maybe code in apache tries to mkdir /run/httpd and that's where the permission denied error comes from? /me is clutching at straws here :) It seems things are more complicated :) It used to use ServerRoot + /logs/ (/etc/httpd/logs) which is a symlink to /var/log/httpd, but seem to now always use /run/httpd, even when ServerRoot is different. That's why the tests used to work: they were using a local t/ as ServerRoot and using t/logs/. But I am now wondering if the feature in normal usage has ever worked given that /var/log/httpd permissions are not more open
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release python-distribute-0.6.34-3.mga3
On Thu, Jan 24, 2013 at 3:22 AM, Thomas Spuhler tho...@btspuhler.com wrote: I eliminated the package python-pkg-resources and put the two+ files into the basic package python- distribute. The reason is as stated below: Hey! I can see you have imported python-distribute that generates package python-pkg-resources. And now the problem: http://pkgsubmit.mageia.org/uploads/rejected/cauldron/core/release/20130113212011.umeabot.valstar.22055.youri - python-setuptools generates package with same name. I think you should rename yours to python-pkg-resources-distribute or something like that. The problem is that python-distribute should have then been uploaded just after. python-pkg-resources got cleaned from the mirrors because it was a leftover package built from a src.rpm which no longer existed, and the one from python-distribute had not been uploaded.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release python-distribute-0.6.34-3.mga3
On Thu, Jan 24, 2013 at 10:37 AM, Sander Lepik sander.le...@eesti.ee wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 24.01.2013 12:28, Pascal Terjan kirjutas: On Thu, Jan 24, 2013 at 3:22 AM, Thomas Spuhler tho...@btspuhler.com wrote: I eliminated the package python-pkg-resources and put the two+ files into the basic package python- distribute. The reason is as stated below: Hey! I can see you have imported python-distribute that generates package python-pkg-resources. And now the problem: http://pkgsubmit.mageia.org/uploads/rejected/cauldron/core/release/20130113212011.umeabot.valstar.22055.youri - - python-setuptools generates package with same name. I think you should rename yours to python-pkg-resources-distribute or something like that. The problem is that python-distribute should have then been uploaded just after. python-pkg-resources got cleaned from the mirrors because it was a leftover package built from a src.rpm which no longer existed, and the one from python-distribute had not been uploaded. Not python-distribute but python-setuptools. They both had python-pkg-resources as sub-package. And as python-distribute has bigger version its subpackage was uploaded. That package should come from python-setuptools as it was before Thomas imported python-distribute. Yes sorry, mixed them :) But now we need to fix the problem: python-setuptools can not be uploaded while this package is still here (as the version is lower) or if the package is removed (as chroot creation will fail). I think I will force the upload of python-setuptools
Re: [Mageia-dev] Packagers meeting
On Wed, Jan 23, 2013 at 11:18 AM, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Pascal Terjan at 22/01/13 19:49 did gyre and gimble: But 10993/10997 = 99.96% which would be rounded to 100% Where exactly does the 10993 come from? I don't see those specific figures on the autobuild results... am I misinterpreting them? http://pkgsubmit.mageia.org/autobuild/results.php?run=2013-01-21 has 10998 http://pkgsubmit.mageia.org/autobuild/results.php?run=2013-01-20 had 10997 On http://pkgsubmit.mageia.org/autobuild/ that would be Total - not_on_this_arch (the 9 packages that are 32 bits only)
Re: [Mageia-dev] Packagers meeting
On Wed, Jan 23, 2013 at 11:26 AM, Pascal Terjan pter...@gmail.com wrote: On Wed, Jan 23, 2013 at 11:18 AM, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Pascal Terjan at 22/01/13 19:49 did gyre and gimble: But 10993/10997 = 99.96% which would be rounded to 100% Where exactly does the 10993 come from? I don't see those specific figures on the autobuild results... am I misinterpreting them? http://pkgsubmit.mageia.org/autobuild/results.php?run=2013-01-21 has 10998 http://pkgsubmit.mageia.org/autobuild/results.php?run=2013-01-20 had 10997 On http://pkgsubmit.mageia.org/autobuild/ that would be Total - not_on_this_arch (the 9 packages that are 32 bits only) Ah and the 10993 is 10997 - the 4 which are expected to fail due to -l 12 ;0
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release python-distribute-0.6.34-3.mga3
On Wed, Jan 23, 2013 at 7:48 PM, spuhler buildsystem-dae...@mageia.org wrote: Name: python-distributeRelocations: (not relocatable) Version : 0.6.34Vendor: Mageia.Org Release : 3.mga3Build Date: Wed Jan 23 20:48:19 2013 Install Date: (not installed) Build Host: jonund.mageia.org Group : Development/PythonSource RPM: (none) Size: 646093 License: Zope Public License (ZPL) Signature : (none) Packager: spuhler spuhler URL : http://pypi.python.org/pypi/distribute Summary : Python Distutils Enhancements Description : A collection of enhancements to the Python distutils that allow you to more easily build and distribute Python packages, especially ones that have dependencies on other packages. spuhler spuhler 0.6.34-3.mga3: + Revision: 391715 - removed the python-pkg-resources package moved the two files into the main package It interferes with the python-setuptools package This broke the build system A requested package cannot be installed: rpm-mageia-setup-build-1.166-2.mga3.x86_64 (due to unsatisfied python-pkg-resources)
[Mageia-dev] /run/httpd (maybe others) breaking features
I was looking at perl-Apache2-DebugFilter build failure In the test it starts an apache which fails as it uses http://httpd.apache.org/docs/trunk/rewrite/rewritemap.html#prg which uses a mutex stored in /run/httpd/ [Wed Jan 23 23:49:55.962405 2013] [core:emerg] [pid 55277] (13)Permission denied: AH00023: Couldn't create the rewrite-map mutex (file /run/httpd/rewrite-map.55277) That directory is now owned by root so it can't be used for anything except creating the httpd.pid $ cat /usr/lib/tmpfiles.d/httpd.conf d /run/httpd 755 root root Fedora uses d /run/httpd 710 root apache which doesn't help in this case but fixes other problems In the past (Mageia 1) runtimedir was /var/run directly so it was possible to create mutex files there for any user Is there a list of packages which have moved to subdirectories of /run and may now be broken too?
Re: [Mageia-dev] /run/httpd (maybe others) breaking features
On Thu, Jan 24, 2013 at 12:45 AM, Colin Guthrie mag...@colin.guthr.ie wrote: 'Twas brillig, and Pascal Terjan at 24/01/13 00:24 did gyre and gimble: I was looking at perl-Apache2-DebugFilter build failure In the test it starts an apache which fails as it uses http://httpd.apache.org/docs/trunk/rewrite/rewritemap.html#prg which uses a mutex stored in /run/httpd/ [Wed Jan 23 23:49:55.962405 2013] [core:emerg] [pid 55277] (13)Permission denied: AH00023: Couldn't create the rewrite-map mutex (file /run/httpd/rewrite-map.55277) That directory is now owned by root so it can't be used for anything except creating the httpd.pid $ cat /usr/lib/tmpfiles.d/httpd.conf d /run/httpd 755 root root Fedora uses d /run/httpd 710 root apache which doesn't help in this case but fixes other problems In the past (Mageia 1) runtimedir was /var/run directly so it was possible to create mutex files there for any user Hmm, not sure what you mean here. [colin@mga2 ~]$ ls -ld /var/run drwxr-xr-x 38 root root 4096 Jan 23 04:04 /var/run/ That dir is also owned by root with 755 perm. It shouldn't make any odds to permissions. Hmm you are right, I don't know why it got broken then It used to use /var/run/ as runtime dir and it succeeded creating the mutex It now fails to create it in /run/httpd/ I don't have more clues :( It may be some change in apache but I couldn't find, I'll try to find out more tomorrow
Re: [Mageia-dev] Freeze push: transmission
On Tue, Jan 22, 2013 at 5:30 PM, Damien Lallement mag...@damsweb.net wrote: Package:help2man Wrong name :) Url: https://trac.transmissionbt.com/query?milestone=2.76group=componentorder=severity Now:2.75 Submitted: 2.76 Changelog: Bug/regression fix release and add magnet link support Thanks! -- Damien Lallement twitter: damsweb - IRC: damsweb/coincoin
Re: [Mageia-dev] Packagers meeting
On Tue, Jan 22, 2013 at 7:08 PM, Anne Nicolas anne.nico...@hupstream.com wrote: Hi there Sorry for the long time without any meeting. We are about to finalize beta 2 release. Still some work to be done before publishing it. We will have a meeting next week, before FOSDEM we. We will start tonight a review of release_critical bugs by mail. Next review will be done during packagers meeting. Finally one important link to help on final release: http://pkgsubmit.mageia.org/autobuild/ We need to reach 100% before final release or we will remove packages that do not rebuild. Already a great result, we can do more :) 4 of them can be ignored as they fail due to a difference compared to normal buildsystem (passing _smp_mflags to waf, I hope to fix that soon but didn't yet): lv2-1.2.0-2.mga3.src.rpm/build.0.20130120010819.log:+ ./waf -vv -l12 -j12 python-cairo-1.10.0-5.mga3.src.rpm/build.0.20130120010819.log:+ /usr/bin/waf-3.3 build -l12 -j12 semantik-0.8.3-2.mga3.src.rpm/build.0.20130120010819.log:+ ./waf build -l12 -j12 xmms2-0.8-5.mga3.src.rpm/build.0.20130120010819.log:+ ./waf build -v -l12 -j12 But 10993/10997 = 99.96% which would be rounded to 100% :)
Re: [Mageia-dev] Freeze break = trousers
On Wed, Jan 23, 2013 at 12:49 AM, David Walser luigiwal...@yahoo.com wrote: Funda Wang fundawang@... writes: Can we even use this package? There's a note with the gnutls source that says the Common Public License (used by trousers) is incompatible with the GPL. Yes we can use it, as our gnutls isn't linked with it :p Well yes, not anymore, thanks to me. What *is* trousers linked to in Mageia? I expected we would have tpm-tools but it seems not :)
Re: [Mageia-dev] [RPM Groups] Final Final change for Mageia 3
On Sun, Jan 20, 2013 at 10:32 PM, AL13N al...@rmail.be wrote: Is there a way to list all packages violating these? since the mass rebuild is done, i would think that the previous changes are now enforced. the list for these should be small. so, a list+maintainer could be nice I think we should first automatically move the renamed ones + moving System/Configuration/Printing to System/Printing The only ones which need manual intervention would be : - System/Configuration/Hardware disappears - System/Configuration/Other disappears
Re: [Mageia-dev] php packages failing to build
On Sat, Jan 19, 2013 at 4:35 PM, AL13N al...@rmail.be wrote: Is anything used by something else? Do most of them have replacements or are obsoleted by others? php-bcompiler ... iirc, i donno if there is a replacement for this php-archive ... sounds like it's obsoleted by others php-xslcache ... is this obsolete too? php-gtk2 ... is there a php-gtk3 [5-Aug-2010] Dropping by to let the PHP-GTK community know that development is still happening! The project is being split up into different projects, PECL/Cairo, GLib, GObject, etc. The cairo one seems to be the only one existing so far... Last commit on http://svn.php.net/viewvc/gtk/php-gtk/trunk/ is 2 years old php-tdb ... this might be used for samba stuff and: php-perl php-python --- WTF? That's the other way around from http://search.cpan.org/~mob/PHP-0.14/PHP.pm or http://search.cpan.org/~aff/PHP-Interpreter-1.0.2/ Op zaterdag 19 januari 2013 09:26:35 schreef Thomas Spuhler: The following packages don't build anymore. The php-5.4(zend) patches have been applied, but there are a lot of other issues. All of them haven't seen any upstream activities fir 2 years. I propose to move them to obsoletes if nobody complains or steps I will do it early next week: php-archive php-bcompiler php-colorer php-courierauth php-ecasound php-event php-filepro php-framegrab php-funcall php-gtk2 php-mcache php-mnogosearch php-perl php-ps php-python php-syck php-tcpwrap php-tdb php-teng php-tk php-xslcache php-yp
[Mageia-dev] Free push: iurt
This is a bug fix release: 0.6.19 - fix missing used function in emi and ulri - use unique tmpfile for dumping macros
Re: [Mageia-dev] Help needed: rpmlint checks not working
On Tue, Jan 15, 2013 at 6:21 PM, Thierry Vignaud thierry.vign...@gmail.com wrote: On 15 January 2013 19:17, Colin Guthrie mag...@colin.guthr.ie wrote: Will this affect mga2 builds too? It shouldn't there so hopefully there is no conflict :) Hmm, actually it probably applies to Mageia 2 builds too. I will try to change this. This should now be fixed. http://svnweb.mageia.org/adm/puppet/modules/buildsystem/templates/youri/submit-upload.conf?r1=2963r2=2967 Isn't that commit showing we didn't rejected some packages which should have been due to missing rules? Yes, we didn't reject some packages which should have been. Until this commit : http://svnweb.mageia.org/adm/puppet/modules/buildsystem/templates/youri/submit-upload.conf?r1=2928r2=2963 But after this one we were rejecting too much on Mageia 2. Now it should be ok on Cauldron and Mageia 2. Well no. No as in it may be possible that some updates upload will break due to some error now being detected and rejected. Could we script a pass on all packages with that rpmlint config to catch any such packages and fix them? Well the first commit certainly applied to updates (and I queried as much), but I think the second commit means it only applies to cauldron, not any updates to mga2 etc. My point is we just added to _CAULDRON_ == mga3 a lot of rules that were missed, just after mass rebuild, and I fear that when we'll try to issue updates to _mga3_, we may see some being rejected, this is why I ask we check current cauldron with upload server rpmlint config... The options used to apply to all versions They were copied to cauldron specific rules and those ones removed from the default rules
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release makedev-4.4-14.mga3
On Sun, Jan 13, 2013 at 8:19 PM, tv buildsystem-dae...@mageia.org wrote: Name: makedev Relocations: (not relocatable) Version : 4.4 Vendor: Mageia.Org Release : 14.mga3 Build Date: Sun Jan 13 21:06:51 2013 Install Date: (not installed) Build Host: ecosse.mageia.org Group : System/Kernel and hardwareSource RPM: (none) Size: 58419License: GPLv2+ Signature : (none) Packager: tv tv URL : http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/soft/makedev/ Summary : A program used for creating the device files in /dev Description : This package contains the makedev program, which makes it easier to create and maintain the files in the /dev directory. /dev directory files correspond to a particular device supported by Linux (serial or printer ports, scanners, sound cards, tape drives, CD-ROM drives, hard drives, etc.) and interface with the drivers in the kernel. The makedev package is a basic part of your Mageia system and it needs to be installed. tv tv 4.4-14.mga3: + Revision: 378420 - fix upgrading (not corrupting devtmpfs) - devfs is dead for nearly a decade This package causes /usr/lib/root-mirror being in mounted in chroots on the build system (and not being umounted) during clean chroot creation sucuk had 65 mounted, oldest one being /home/iurt/chroot_tmp/iurt/chroot_cauldron.i586.0.20130113202409/usr/lib/root-mirror just after this package was uploaded
Re: [Mageia-dev] Trying to install Google Musicmanager under Cauldron
On Mon, Jan 14, 2013 at 8:56 PM, Olivier Blin mag...@blino.org wrote: Donald Stewart watersnowr...@gmail.com writes: On 14 January 2013 20:27, Robert Fox l...@foxconsult.net wrote: A requested package cannot be installed: google-musicmanager-beta-1.0.54.4672-0.x86_64 (due to unsatisfied qtwebkit) Continue installation anyway? [root@ThinkFox Downloads]# rpm -qa | grep qtwebkit libqtwebkit2.2_4-2.2.2-5.mga3 qtwebkit-qmlplugin-2.2.2-5.mga3 lib64qtwebkit2.2_4-2.2.2-5.mga3 I just forced the install without the deps... Hi, If it works fine after installing with --nodeps, maybe we could add qtwebkit provides in the matching package. Do you know if this application is linked against libQtWebKit.so.4? It seems to work fine on opensuse ignoring the dependency http://opensuseadventures.blogspot.co.uk/2012/12/easily-install-dropbox-skype-and-google.html Trying here the %post complains about missing service atd but then runs fine [pterjan@chopin ~]$ ldd /opt/google/musicmanager/MusicManager | grep -i qt libQtGui.so.4 = /lib64/libQtGui.so.4 (0x7f19bcb74000) libQtNetwork.so.4 = /lib64/libQtNetwork.so.4 (0x7f19bc83c000) libQtCore.so.4 = /lib64/libQtCore.so.4 (0x7f19bc365000) libQtWebKit.so.4 = /lib64/libQtWebKit.so.4 (0x7f19ba765000) libQtLocation.so.1 = /usr/lib64/libQtLocation.so.1 (0x7f19b3d73000) libQtSensors.so.1 = /usr/lib64/libQtSensors.so.1 (0x7f19b3b46000) libQtOpenGL.so.4 = /usr/lib64/libQtOpenGL.so.4 (0x7f19b3848000) libQtSql.so.4 = /usr/lib64/libQtSql.so.4 (0x7f19b1cf)
Re: [Mageia-dev] Missign rebuilds tagged mga1
On Mon, Jan 14, 2013 at 11:28 PM, JA Magallón jamagal...@ono.com wrote:
Hi...
As the mass rebuild seems almost done, I have supposed that everything in
my box not tagged ad mga3 are leftovers from previous installs, as I had
not reinstalled my box since mga1. I checked this:
rpm -qa --nosignature --qf %{n}-%{v}-%{r}\n | grep mga1 | sort
(I have another list for mga2 ;) )
But some packages seems to be needed, and skipped in the mass rebuild.
450 failed to build (list on
http://pkgsubmit.mageia.org/autobuild/results.php?run=2013-01-11)
63 got rejected (no handy list available yet, visible on
http://pkgsubmit.mageia.org/?user=umeabot but only the last 48h are
displayed)
This is the list I get in my main box:
werewolf:~/bin# mga1
jline-0.9.94-4.mga1
lib64atlas3-x86_64-3.8.3-7.mga1
lib64iec16022_0-0.2.4-4.mga1
lib64jbig1-2.0-5.mga1
lib64jbig-devel-2.0-5.mga1
lib64mpeg2dec0-0.5.1-5.mga1
lib64opencore-amr0-0.1.2-3.mga1
net-tools-1.60-34.mga1
perl-Spreadsheet-ParseExcel-0.590.0-1.mga1
python-dateutil-1.5-2.mga1
transfugdrake-1.9.4-1.mga1
Some look pretty important:
jline - rhino - jdk7
net-tools - basesystem
transfugdrake - userdrake
... and so on.
Mirrors also seem to contain packages dated 2011. I will wait for mirrors to
settle
and look again. If they are dead packages, should not they be killed from
mirrors ?
Many of them should be fixed, some should be killed
Re: [Mageia-dev] something wrong with mscore (ancient name musescore) in the BuildSystem ?
On Sun, Jan 13, 2013 at 2:31 PM, PhilippeDidier philippedid...@laposte.net wrote: mscore was submitted by umeabot 18 hours ago and is still building (for 18 hours...) without any progress seems longer to build than libreoffice or kernel, Looping somewhere ? NB there is a file conflict concerning one of its BuildRequires : BuildRequires: texlive-mf2pt1 file /usr/share/info/mf2pt1.info.xz from install of texlive-texmf-20120701-1.mga3.noarch conflicts with file from package texlive-mf2pt1-2.5.0-1.mga3.noarch is this a possible explanation ? Yes, this is the problem (and why I posted about the conflict last night, hoping someone would fix it while I sleep :) )
Re: [Mageia-dev] /usr/bin/file broken on cauldron
On Thu, Jan 10, 2013 at 12:56 AM, Olivier Blin mag...@blino.org wrote: Luc Menut lme...@free.fr writes: It's better, but file-5.12-5 still mis-detects some script files; I can see that some Perl or shell scripts are reported as 'assembler source text' with 5.12-5. [...] /usr/bin/automake: assembler source text /usr/bin/iurt: assembler source text It's very annoying because /usr/bin/file is used by find-requires and [...] find-provides, and if we do the mass rebuild with a broken /usr/bin/file, we will build some rpms with incorrect provides and requires. Hi again, This might be this one: http://mx.gw.com/pipermail/file/2013/001026.html Which is claimed to be fixed by the maintainer: http://mx.gw.com/pipermail/file/2013/001040.html Can you try with upstream git? https://github.com/glensc/file/commits/master This is fixed in git but I couldn't find the specific commit
Re: [Mageia-dev] /usr/bin/file broken on cauldron
On Thu, Jan 10, 2013 at 3:51 PM, Pascal Terjan pter...@gmail.com wrote: On Thu, Jan 10, 2013 at 12:56 AM, Olivier Blin mag...@blino.org wrote: Luc Menut lme...@free.fr writes: It's better, but file-5.12-5 still mis-detects some script files; I can see that some Perl or shell scripts are reported as 'assembler source text' with 5.12-5. [...] /usr/bin/automake: assembler source text /usr/bin/iurt: assembler source text It's very annoying because /usr/bin/file is used by find-requires and [...] find-provides, and if we do the mass rebuild with a broken /usr/bin/file, we will build some rpms with incorrect provides and requires. Hi again, This might be this one: http://mx.gw.com/pipermail/file/2013/001026.html Which is claimed to be fixed by the maintainer: http://mx.gw.com/pipermail/file/2013/001040.html Can you try with upstream git? https://github.com/glensc/file/commits/master This is fixed in git but I couldn't find the specific commit The fix is https://github.com/glensc/file/commit/834831f53398cf2a1cfcd1daaf88c437bbf8d21f
Re: [Mageia-dev] Packages with changes on svn
On Wed, Jan 9, 2013 at 8:23 PM, David Walser luigiwal...@yahoo.com wrote: updates to a new version - danger! -- tcl telepathy-idle Done transfugdrake tree Submitted usbutils It was actually not, just some version change + revert I haven't looked at tcl and transfugdrake
Re: [Mageia-dev] libkolabxml rebuild
On Tue, Jan 8, 2013 at 4:39 AM, Thomas Spuhler tho...@btspuhler.com wrote: Funda: Would you please have a look why libkolabxml doesn't build anymore. /home/pterjan/rpmbuild/BUILD/libkolabxml-0.8.1/build/src/php/php_kolabformat_wrapper.cpp:1102:16: error: 'tsrm_ls' was not declared in this scope Reading http://blog.golemon.com/2006/06/what-heck-is-tsrmlscc-anyway.html I would guess that zts was enabled on php and this extension needs to be fixed for it It seems to have broken a few others (grep was taking too long on * so I searched only php-*): [pterjan@valstar 2013-01-06]$ grep error: 'tsrm_ls' php*/build* | cut -d/ -f1 | uniq php-apacheaccessor-1.0.1-1.mga3.src.rpm php-apm-1.1.0-0beta4.mga3.src.rpm php-cairo_wrapper-0.2.4-11.mga3.src.rpm php-colorer-0.7-32.mga3.src.rpm php-libvirt-0.4.5-1.mga3.src.rpm php-mcal-0.6-41.mga3.src.rpm php-tk-0.1.1-28.mga3.src.rpm
Re: [Mageia-dev] libkolabxml rebuild
On Tue, Jan 8, 2013 at 8:29 AM, Pascal Terjan pter...@gmail.com wrote: On Tue, Jan 8, 2013 at 4:39 AM, Thomas Spuhler tho...@btspuhler.com wrote: Funda: Would you please have a look why libkolabxml doesn't build anymore. /home/pterjan/rpmbuild/BUILD/libkolabxml-0.8.1/build/src/php/php_kolabformat_wrapper.cpp:1102:16: error: 'tsrm_ls' was not declared in this scope Reading http://blog.golemon.com/2006/06/what-heck-is-tsrmlscc-anyway.html I would guess that zts was enabled on php and this extension needs to be fixed for it It seems to have broken a few others (grep was taking too long on * so I searched only php-*): [pterjan@valstar 2013-01-06]$ grep error: 'tsrm_ls' php*/build* | cut -d/ -f1 | uniq php-apacheaccessor-1.0.1-1.mga3.src.rpm php-apm-1.1.0-0beta4.mga3.src.rpm php-cairo_wrapper-0.2.4-11.mga3.src.rpm php-colorer-0.7-32.mga3.src.rpm php-libvirt-0.4.5-1.mga3.src.rpm php-mcal-0.6-41.mga3.src.rpm php-tk-0.1.1-28.mga3.src.rpm Full list: gdal-1.9.2-3.mga3.src.rpm graphviz-2.28.0-10.mga3.src.rpm libkolab-0.3.2-2.mga3.src.rpm libkolabxml-0.8.1-4.mga3.src.rpm php-apacheaccessor-1.0.1-1.mga3.src.rpm php-apm-1.1.0-0beta4.mga3.src.rpm php-cairo_wrapper-0.2.4-11.mga3.src.rpm php-colorer-0.7-32.mga3.src.rpm php-libvirt-0.4.5-1.mga3.src.rpm php-mcal-0.6-41.mga3.src.rpm php-tk-0.1.1-28.mga3.src.rpm
Re: [Mageia-dev] Booting on GPT + UEFI + Secure Boot...
On Tue, Jan 8, 2013 at 2:01 PM, Olivier Thauvin nanar...@nanardon.zarb.org wrote: * Liam R E Quin (l...@holoweb.net) wrote: On Mon, 2013-01-07 at 17:01 +0100, Olivier Thauvin wrote: I found the key of the issue: grub has not install because block number is to big (my /boot is at 1,6TB from the start of the disk). With my HP Elitebook I found that all the partitions were allocated, so I booted in Windows 7 (this was 2 years ago) and used the program that came with Windows to resize the partitions and move them around a bit. I did succeed to setup grub2-efi on my mageia2. But I want cauldron on it and since upgrading mga2 = cauldron is no longer possible I decided to try to install cauldron. The system is installed with grub2-efi but the boot failed with all kernel I've tried: cannot mount /proc - mount return error, no such file or directory. Any idea ? Yes, it seems a cauldron bug :)
Re: [Mageia-dev] Booting on GPT + UEFI + Secure Boot...
On Mon, Jan 7, 2013 at 11:31 AM, Olivier Thauvin nanar...@nanardon.zarb.org wrote: Hello again, I just buy a wonderfull HP ENVY23 smartscreen. It has: - Windows 8 (I'd like to keep it) - GPT Formated disk (2T) - UEFI - SecureBoot I am trying to install a Mageia on it: I disabled secure boot. I succeed to boot using PXE (using legacy boot) and to install mageia2, but it failed to boot on Mageia using legacy boot. Do you know how it fails? So questions: - is it possible to boot Mageia using legacy boot on GPT disk ? Yes (using grub, not lilo) - is it possible to boot Mageia using UEFI ? I think so but I have never tried. I remember someone reporting success.
Re: [Mageia-dev] problem with %_smp_mflags in Cauldron
On Sun, Jan 6, 2013 at 3:13 PM, philippe makowski
makowski.mag...@gmail.com wrote:
Hi,
2013/1/6 Pascal Terjan pter...@gmail.com:
So far only waf should be a problem. Maybe we could add a macro with
only the number of cpus and use -j%n_cpus with waf instead of using
the make flags given that it is not compatible with other make
options? (In smp_mflags the second m is for make)
That' s fine for me
Anyone against such patch? I would change _smp_mflags to %([
%_build_ncpus -gt 1 ] echo -j%_build_ncpus -l%_build_ncpus) later
[pterjan@chopin trunk]$ svn diff
Index: build.macros.in
===
--- build.macros.in (revision 7023)
+++ build.macros.in (working copy)
@@ -207,9 +207,10 @@
%{nil}
-%_smp_mflags %([ -z $RPM_BUILD_NCPUS ] \\\
-RPM_BUILD_NCPUS=`/usr/bin/getconf _NPROCESSORS_ONLN`; \\\
- [ $RPM_BUILD_NCPUS -gt 1 ] echo -j$RPM_BUILD_NCPUS)
+# Define _build_ncpus which can be reused with non-make build systems
+# Needs to be sent upstream
+%_build_ncpus %([ -n $RPM_BUILD_NCPUS ] echo $RPM_BUILD_NCPUS
|| /usr/bin/getconf _NPROCESSORS_ONLN)
+%_smp_mflags %([ %_build_ncpus -gt 1 ] echo -j%_build_ncpus)
%_make_bin make
%make %{_make_bin} %_smp_mflags
Re: [Mageia-dev] The autobuild page [was: Can fftw2 and glitz be dropped?]
On Sat, Jan 5, 2013 at 6:27 AM, Johnny A. Solbu coo...@solbu.net wrote: On Saturday 5. January 2013 01.35, Christiaan Welvaart wrote: There are currently about 800 packages that don't build, see http://pkgsubmit.mageia.org/autobuild/ That page should be redone. untill I saw your mail, I thought the autobuild vas disabled or stopped because there was No content. Then it hit me to perhaps activate javascript, and the content appeared. There should be some message displayed to users reading the page with javascript disabled, saying they need to activate javascript. Feel free to send a patch :) Meanwhile http://pkgsubmit.mageia.org/autobuild/results.php?run=latest does not use any javascript
Re: [Mageia-dev] An update broke checkinstall build - help?
On Sun, Jan 6, 2013 at 9:44 PM, Johnny A. Solbu coo...@solbu.net wrote: I have problems figuring out how to fix checkinstall. A recent update on my cauldron system, broke building of «checkinstall», and I don't know how to fix it. I've tested an opensuse package, and it builds. and I can't figure out which opensuse patch fixes it. I'm temptet to just dropp it. It's not in mga1 or 2, and it seems to be abandoned upstream. last version was released in 2008. The code contains tests like : #if (GLIBC_MINOR = 4) And their create-localdecls script will define it for each known version (from 0 to 7) or default to 1. Because 17 is not between 0 and 7 and 1 = 4 it is using the readlink prototype of a very old glibc... This patch seems to fix it https://build.opensuse.org/package/view_file?file=installwatch-glibc_minor.patchpackage=checkinstallproject=openSUSE%3AFactory but I didn't try to build with it
Re: [Mageia-dev] An update broke checkinstall build - help?
On Sun, Jan 6, 2013 at 10:11 PM, Pascal Terjan pter...@gmail.com wrote: On Sun, Jan 6, 2013 at 9:44 PM, Johnny A. Solbu coo...@solbu.net wrote: I have problems figuring out how to fix checkinstall. A recent update on my cauldron system, broke building of «checkinstall», and I don't know how to fix it. I've tested an opensuse package, and it builds. and I can't figure out which opensuse patch fixes it. I'm temptet to just dropp it. It's not in mga1 or 2, and it seems to be abandoned upstream. last version was released in 2008. The code contains tests like : #if (GLIBC_MINOR = 4) And their create-localdecls script will define it for each known version (from 0 to 7) or default to 1. Because 17 is not between 0 and 7 and 1 = 4 it is using the readlink prototype of a very old glibc... This patch seems to fix it https://build.opensuse.org/package/view_file?file=installwatch-glibc_minor.patchpackage=checkinstallproject=openSUSE%3AFactory but I didn't try to build with it Ah and it just broke now because we have a patch adding the values up to 16... checkinstall-mdv-fix-glibc-detection.patch
Re: [Mageia-dev] outdated packages missed by youri
On Sun, Jan 6, 2013 at 10:04 PM, David Walser luigiwal...@yahoo.com wrote: Luigi12 :maint -s abiword-docs Sophie Luigi12: For Mageia (abiword-docs): nobody should be 2.9.4 like abiword, rosa has it It doesn't build and didn't seem obvious to fix when I tried last month When I try to build it on my server over ssh I get: abiword --to=html --to-name=dialogchangecase.html --exp-props=html4: no; use-awml: no; embed-css: yes; embed-images:yes dialogchangecase.abw libGL error: failed to load driver: i965 libGL error: Try again with LIBGL_DEBUG=verbose for more details. make[3]: *** [dialogchangecase.html] Aborted With LIBGL_DEBUG=verbose it gave the following errors and I gave up. abiword --to=html --to-name=dialogchangecase.html --exp-props=html4: no; use-awml: no; embed-css: yes; embed-images:yes dialogchangecase.abw libGL: OpenDriver: trying /usr/lib64/dri/i965_dri.so libGL error: failed to open drm device: No such file or directory libGL error: failed to load driver: i965 libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so libGL: Can't open configuration file /home/pterjan/.drirc: No such file or directory. libGL: Can't open configuration file /home/pterjan/.drirc: No such file or directory. make[3]: *** [dialogchangecase.html] Aborted
Re: [Mageia-dev] outdated packages missed by youri
On Sun, Jan 6, 2013 at 10:41 PM, Pascal Terjan pter...@gmail.com wrote: On Sun, Jan 6, 2013 at 10:04 PM, David Walser luigiwal...@yahoo.com wrote: Luigi12 :maint -s abiword-docs Sophie Luigi12: For Mageia (abiword-docs): nobody should be 2.9.4 like abiword, rosa has it It doesn't build and didn't seem obvious to fix when I tried last month When I try to build it on my server over ssh I get: abiword --to=html --to-name=dialogchangecase.html --exp-props=html4: no; use-awml: no; embed-css: yes; embed-images:yes dialogchangecase.abw libGL error: failed to load driver: i965 libGL error: Try again with LIBGL_DEBUG=verbose for more details. make[3]: *** [dialogchangecase.html] Aborted With LIBGL_DEBUG=verbose it gave the following errors and I gave up. abiword --to=html --to-name=dialogchangecase.html --exp-props=html4: no; use-awml: no; embed-css: yes; embed-images:yes dialogchangecase.abw libGL: OpenDriver: trying /usr/lib64/dri/i965_dri.so libGL error: failed to open drm device: No such file or directory libGL error: failed to load driver: i965 libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so libGL: Can't open configuration file /home/pterjan/.drirc: No such file or directory. libGL: Can't open configuration file /home/pterjan/.drirc: No such file or directory. make[3]: *** [dialogchangecase.html] Aborted (Also, my server has Matrox hardware and my laptop has nvidia, so I have no idea what in abiword is trying to load something related to i965 to convert this specific document)
Re: [Mageia-dev] An update broke checkinstall build - help?
On Mon, Jan 7, 2013 at 12:19 AM, Johnny A. Solbu coo...@solbu.net wrote: On Sunday 6. January 2013 23.11, Pascal Terjan wrote: This patch seems to fix it https://build.opensuse.org/package/view_file?file=installwatch-glibc_minor.patchpackage=checkinstallproject=openSUSE%3AFactory but I didn't try to build with it I did before starting this thread, and it doesn't fix it ... I just tried and it worked so I uploaded it
Re: [Mageia-dev] outdated packages missed by youri
On Sun, Jan 6, 2013 at 10:44 PM, Pascal Terjan pter...@gmail.com wrote: On Sun, Jan 6, 2013 at 10:41 PM, Pascal Terjan pter...@gmail.com wrote: On Sun, Jan 6, 2013 at 10:04 PM, David Walser luigiwal...@yahoo.com wrote: Luigi12 :maint -s abiword-docs Sophie Luigi12: For Mageia (abiword-docs): nobody should be 2.9.4 like abiword, rosa has it It doesn't build and didn't seem obvious to fix when I tried last month When I try to build it on my server over ssh I get: abiword --to=html --to-name=dialogchangecase.html --exp-props=html4: no; use-awml: no; embed-css: yes; embed-images:yes dialogchangecase.abw libGL error: failed to load driver: i965 libGL error: Try again with LIBGL_DEBUG=verbose for more details. make[3]: *** [dialogchangecase.html] Aborted With LIBGL_DEBUG=verbose it gave the following errors and I gave up. abiword --to=html --to-name=dialogchangecase.html --exp-props=html4: no; use-awml: no; embed-css: yes; embed-images:yes dialogchangecase.abw libGL: OpenDriver: trying /usr/lib64/dri/i965_dri.so libGL error: failed to open drm device: No such file or directory libGL error: failed to load driver: i965 libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so libGL: Can't open configuration file /home/pterjan/.drirc: No such file or directory. libGL: Can't open configuration file /home/pterjan/.drirc: No such file or directory. make[3]: *** [dialogchangecase.html] Aborted (Also, my server has Matrox hardware and my laptop has nvidia, so I have no idea what in abiword is trying to load something related to i965 to convert this specific document) Ah I found how ROSA managed to have it... https://abf.rosalinux.ru/import/abiword-docs/diff/4067ca06836d3467b289fcf782ac1c11339f4953...2a4ec202096131d10371d83922f9e49487ab480a#diff-1
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release file-5.12-1.mga3
On Fri, Jan 4, 2013 at 1:06 AM, luigiwalser buildsystem-dae...@mageia.org wrote: Name: file Relocations: (not relocatable) Version : 5.12 Vendor: Mageia.Org Release : 1.mga3Build Date: Fri Jan 4 02:05:27 2013 Install Date: (not installed) Build Host: jonund.mageia.org Group : File toolsSource RPM: (none) Size: 644814 License: BSD Signature : (none) Packager: luigiwalser luigiwalser URL : http://www.darwinsys.com/file/ Summary : A utility for determining file types Description : The file command is used to identify a particular file according to the type of data contained by the file. File can identify many different file types, including ELF binaries, system libraries, RPM packages, and different graphics formats. You should install the file package, since the file command is such a useful utility. luigiwalser luigiwalser 5.12-1.mga3: + Revision: 338488 - 5.12 - rediff patch 8 - remove upstreamed patches - fix format string error in softmagic.c file now segfaults during many of the builds (called by /usr/lib/rpm/find-debuginfo.sh) http://pkgsubmit.mageia.org/autobuild/results.php?run=2013-01-04
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release file-5.12-1.mga3
On Fri, Jan 4, 2013 at 2:56 AM, Pascal Terjan pter...@gmail.com wrote: On Fri, Jan 4, 2013 at 1:06 AM, luigiwalser buildsystem-dae...@mageia.org wrote: Name: file Relocations: (not relocatable) Version : 5.12 Vendor: Mageia.Org Release : 1.mga3Build Date: Fri Jan 4 02:05:27 2013 Install Date: (not installed) Build Host: jonund.mageia.org Group : File toolsSource RPM: (none) Size: 644814 License: BSD Signature : (none) Packager: luigiwalser luigiwalser URL : http://www.darwinsys.com/file/ Summary : A utility for determining file types Description : The file command is used to identify a particular file according to the type of data contained by the file. File can identify many different file types, including ELF binaries, system libraries, RPM packages, and different graphics formats. You should install the file package, since the file command is such a useful utility. luigiwalser luigiwalser 5.12-1.mga3: + Revision: 338488 - 5.12 - rediff patch 8 - remove upstreamed patches - fix format string error in softmagic.c file now segfaults during many of the builds (called by /usr/lib/rpm/find-debuginfo.sh) http://pkgsubmit.mageia.org/autobuild/results.php?run=2013-01-04 Actually it segfaults on all packages which are not noarch, where it gets called
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release file-5.12-1.mga3
On Fri, Jan 4, 2013 at 3:00 AM, Pascal Terjan pter...@gmail.com wrote: On Fri, Jan 4, 2013 at 2:56 AM, Pascal Terjan pter...@gmail.com wrote: On Fri, Jan 4, 2013 at 1:06 AM, luigiwalser buildsystem-dae...@mageia.org wrote: Name: file Relocations: (not relocatable) Version : 5.12 Vendor: Mageia.Org Release : 1.mga3Build Date: Fri Jan 4 02:05:27 2013 Install Date: (not installed) Build Host: jonund.mageia.org Group : File toolsSource RPM: (none) Size: 644814 License: BSD Signature : (none) Packager: luigiwalser luigiwalser URL : http://www.darwinsys.com/file/ Summary : A utility for determining file types Description : The file command is used to identify a particular file according to the type of data contained by the file. File can identify many different file types, including ELF binaries, system libraries, RPM packages, and different graphics formats. You should install the file package, since the file command is such a useful utility. luigiwalser luigiwalser 5.12-1.mga3: + Revision: 338488 - 5.12 - rediff patch 8 - remove upstreamed patches - fix format string error in softmagic.c file now segfaults during many of the builds (called by /usr/lib/rpm/find-debuginfo.sh) http://pkgsubmit.mageia.org/autobuild/results.php?run=2013-01-04 Actually it segfaults on all packages which are not noarch, where it gets called #0 0x7785a0d6 in vfprintf () from /lib64/libc.so.6 #1 0x77916231 in __vasprintf_chk () from /lib64/libc.so.6 #2 0x77916162 in __asprintf_chk () from /lib64/libc.so.6 #3 0x77bd2979 in asprintf (__fmt=0x77bd9de8 %s%s, __ptr=0x7fffdb08) at /usr/include/bits/stdio2.h:178 #4 file_vprintf (ms=0x77bd8ca5, fmt=optimized out, ap=optimized out) at funcs.c:66 #5 0x77bd2a57 in file_printf (ms=ms@entry=0x77bd8ca5, fmt=fmt@entry=0x605010 \360Q`) at funcs.c:87 #6 0x77bcbfbd in mget (ms=ms@entry=0x605010, s=s@entry=0x77f89010 \177ELF\002\001\001, m=m@entry=0x775e2360, nbytes=nbytes@entry=149507, o=o@entry=0, cont_level=cont_level@entry=0, mode=mode@entry=32, text=text@entry=0, flip=flip@entry=0) at softmagic.c:1718 #7 0x77bcd29b in match (ms=ms@entry=0x605010, magic=0x775e2360, nmagic=151, s=s@entry=0x77f89010 \177ELF\002\001\001, nbytes=nbytes@entry=149507, offset=offset@entry=0, mode=mode@entry=32, text=text@entry=0, flip=flip@entry=0) at softmagic.c:146 #8 0x77bcbf99 in mget (ms=ms@entry=0x605010, s=s@entry=0x77f89010 \177ELF\002\001\001, m=m@entry=0x774bb828, nbytes=nbytes@entry=149507, o=o@entry=0, cont_level=cont_level@entry=2, mode=mode@entry=32, text=text@entry=0, flip=flip@entry=0) at softmagic.c:1714 #9 0x77bcd429 in match (ms=ms@entry=0x605010, magic=0x773b60e8, nmagic=9819, s=s@entry=0x77f89010 \177ELF\002\001\001, nbytes=nbytes@entry=149507, offset=offset@entry=0, mode=mode@entry=32, text=text@entry=0, flip=flip@entry=0) at softmagic.c:231 #10 0x77bcbc52 in file_softmagic (ms=ms@entry=0x605010, buf=buf@entry=0x77f89010 \177ELF\002\001\001, nbytes=nbytes@entry=149507, mode=mode@entry=32, text=text@entry=0) at softmagic.c:75 #11 0x77bd2dcd in file_buffer (ms=ms@entry=0x605010, fd=fd@entry=7, inname=inname@entry=0x7fffe4fa /home/pterjan/co/cauldron/arpwatch/BUILDROOT/arpwatch-2.1a15-10.mga3.x86_64/usr/sbin/arpwatch, buf=buf@entry=0x77f89010, nb=149507) at funcs.c:231 #12 0x77bc594f in file_or_fd (ms=ms@entry=0x605010, inname=inname@entry=0x7fffe4fa /home/pterjan/co/cauldron/arpwatch/BUILDROOT/arpwatch-2.1a15-10.mga3.x86_64/usr/sbin/arpwatch, fd=7, fd@entry=0) at magic.c:424 #13 0x77bc5cac in magic_file (ms=ms@entry=0x605010, inname=inname@entry=0x7fffe4fa /home/pterjan/co/cauldron/arpwatch/BUILDROOT/arpwatch-2.1a15-10.mga3.x86_64/usr/sbin/arpwatch) at magic.c:335 #14 0x00402098 in process (ms=ms@entry=0x605010, inname=optimized out, wid=wid@entry=93) at file.c:430 #15 0x00401ab1 in main (argc=3, argv=0x7fffe228) at file.c:338
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release file-5.12-1.mga3
On Fri, Jan 4, 2013 at 3:08 AM, Pascal Terjan pter...@gmail.com wrote: On Fri, Jan 4, 2013 at 3:00 AM, Pascal Terjan pter...@gmail.com wrote: On Fri, Jan 4, 2013 at 2:56 AM, Pascal Terjan pter...@gmail.com wrote: On Fri, Jan 4, 2013 at 1:06 AM, luigiwalser buildsystem-dae...@mageia.org wrote: Name: file Relocations: (not relocatable) Version : 5.12 Vendor: Mageia.Org Release : 1.mga3Build Date: Fri Jan 4 02:05:27 2013 Install Date: (not installed) Build Host: jonund.mageia.org Group : File toolsSource RPM: (none) Size: 644814 License: BSD Signature : (none) Packager: luigiwalser luigiwalser URL : http://www.darwinsys.com/file/ Summary : A utility for determining file types Description : The file command is used to identify a particular file according to the type of data contained by the file. File can identify many different file types, including ELF binaries, system libraries, RPM packages, and different graphics formats. You should install the file package, since the file command is such a useful utility. luigiwalser luigiwalser 5.12-1.mga3: + Revision: 338488 - 5.12 - rediff patch 8 - remove upstreamed patches - fix format string error in softmagic.c file now segfaults during many of the builds (called by /usr/lib/rpm/find-debuginfo.sh) http://pkgsubmit.mageia.org/autobuild/results.php?run=2013-01-04 Actually it segfaults on all packages which are not noarch, where it gets called #0 0x7785a0d6 in vfprintf () from /lib64/libc.so.6 #1 0x77916231 in __vasprintf_chk () from /lib64/libc.so.6 #2 0x77916162 in __asprintf_chk () from /lib64/libc.so.6 #3 0x77bd2979 in asprintf (__fmt=0x77bd9de8 %s%s, __ptr=0x7fffdb08) at /usr/include/bits/stdio2.h:178 #4 file_vprintf (ms=0x77bd8ca5, fmt=optimized out, ap=optimized out) at funcs.c:66 #5 0x77bd2a57 in file_printf (ms=ms@entry=0x77bd8ca5, fmt=fmt@entry=0x605010 \360Q`) at funcs.c:87 #6 0x77bcbfbd in mget (ms=ms@entry=0x605010, s=s@entry=0x77f89010 \177ELF\002\001\001, m=m@entry=0x775e2360, nbytes=nbytes@entry=149507, o=o@entry=0, cont_level=cont_level@entry=0, mode=mode@entry=32, text=text@entry=0, flip=flip@entry=0) at softmagic.c:1718 #7 0x77bcd29b in match (ms=ms@entry=0x605010, magic=0x775e2360, nmagic=151, s=s@entry=0x77f89010 \177ELF\002\001\001, nbytes=nbytes@entry=149507, offset=offset@entry=0, mode=mode@entry=32, text=text@entry=0, flip=flip@entry=0) at softmagic.c:146 #8 0x77bcbf99 in mget (ms=ms@entry=0x605010, s=s@entry=0x77f89010 \177ELF\002\001\001, m=m@entry=0x774bb828, nbytes=nbytes@entry=149507, o=o@entry=0, cont_level=cont_level@entry=2, mode=mode@entry=32, text=text@entry=0, flip=flip@entry=0) at softmagic.c:1714 #9 0x77bcd429 in match (ms=ms@entry=0x605010, magic=0x773b60e8, nmagic=9819, s=s@entry=0x77f89010 \177ELF\002\001\001, nbytes=nbytes@entry=149507, offset=offset@entry=0, mode=mode@entry=32, text=text@entry=0, flip=flip@entry=0) at softmagic.c:231 #10 0x77bcbc52 in file_softmagic (ms=ms@entry=0x605010, buf=buf@entry=0x77f89010 \177ELF\002\001\001, nbytes=nbytes@entry=149507, mode=mode@entry=32, text=text@entry=0) at softmagic.c:75 #11 0x77bd2dcd in file_buffer (ms=ms@entry=0x605010, fd=fd@entry=7, inname=inname@entry=0x7fffe4fa /home/pterjan/co/cauldron/arpwatch/BUILDROOT/arpwatch-2.1a15-10.mga3.x86_64/usr/sbin/arpwatch, buf=buf@entry=0x77f89010, nb=149507) at funcs.c:231 #12 0x77bc594f in file_or_fd (ms=ms@entry=0x605010, inname=inname@entry=0x7fffe4fa /home/pterjan/co/cauldron/arpwatch/BUILDROOT/arpwatch-2.1a15-10.mga3.x86_64/usr/sbin/arpwatch, fd=7, fd@entry=0) at magic.c:424 #13 0x77bc5cac in magic_file (ms=ms@entry=0x605010, inname=inname@entry=0x7fffe4fa /home/pterjan/co/cauldron/arpwatch/BUILDROOT/arpwatch-2.1a15-10.mga3.x86_64/usr/sbin/arpwatch) at magic.c:335 #14 0x00402098 in process (ms=ms@entry=0x605010, inname=optimized out, wid=wid@entry=93) at file.c:430 #15 0x00401ab1 in main (argc=3, argv=0x7fffe228) at file.c:338 I'm restoring old file package as this breaks normal uploads too.
Re: [Mageia-dev] [changelog] cauldron core/release iurt-0.6.16-1.mga3
On Tue, Jan 1, 2013 at 1:08 PM, Thierry Vignaud
thierry.vign...@gmail.com wrote:
On 1 January 2013 02:17, Pascal Terjan pter...@gmail.com wrote:
pterjan pterjan 0.6.16-1.mga3:
+ Revision: 336797
- 0.6.16
* fix chroot cleaning in parallel mode
* fix for some packages missing from status file
btw, 0.6.15 broke the BS on valstar with this error:
Not a HASH reference at /usr/bin/emi line 195.
So I rolled back to 0.6.13 that was in use before.
Is this package safe to install ?
Probably not, I haven't touched emi (I think boklm and tv did in previoys
version). I'll have a look
You can try latest SVN
The code doesn't look correct for the old format of the config file:
The code was:
- if (ref $config-{mandatory_arch} eq 'ARRAY') {
- $mandatory_arch = $config-{mandatory_arch};
- } elsif (ref $config-{mandatory_arch}-{$target} eq 'ARRAY') {
- $mandatory_arch = $config-{mandatory_arch}-{$target};
- } elsif (ref $config-{mandatory_arch}-{default} eq 'ARRAY') {
- $mandatory_arch = $config-{mandatory_arch}-{default};
But your previous simplification only handle the second and third
case, not when mandatory_arch is an ARRAY directly.
The code should work but will consider there is no mandatory arch.
Current configuration (which is the default) is
$config-{mandatory_arch} = [ 'i586', 'x86_64' ]
Re: [Mageia-dev] [changelog] cauldron core/release iurt-0.6.16-1.mga3
On Tue, Jan 1, 2013 at 2:07 PM, nicolas vigier bo...@mars-attacks.org wrote:
On Tue, 01 Jan 2013, Pascal Terjan wrote:
On Tue, Jan 1, 2013 at 1:08 PM, Thierry Vignaud
thierry.vign...@gmail.com wrote:
On 1 January 2013 02:17, Pascal Terjan pter...@gmail.com wrote:
pterjan pterjan 0.6.16-1.mga3:
+ Revision: 336797
- 0.6.16
* fix chroot cleaning in parallel mode
* fix for some packages missing from status file
btw, 0.6.15 broke the BS on valstar with this error:
Not a HASH reference at /usr/bin/emi line 195.
So I rolled back to 0.6.13 that was in use before.
Is this package safe to install ?
Probably not, I haven't touched emi (I think boklm and tv did in previoys
version). I'll have a look
You can try latest SVN
The code doesn't look correct for the old format of the config file:
The code was:
- if (ref $config-{mandatory_arch} eq 'ARRAY') {
- $mandatory_arch = $config-{mandatory_arch};
- } elsif (ref $config-{mandatory_arch}-{$target} eq 'ARRAY') {
- $mandatory_arch = $config-{mandatory_arch}-{$target};
- } elsif (ref $config-{mandatory_arch}-{default} eq 'ARRAY') {
- $mandatory_arch = $config-{mandatory_arch}-{default};
But your previous simplification only handle the second and third
case, not when mandatory_arch is an ARRAY directly.
The code should work but will consider there is no mandatory arch.
Latest code in svn is :
my $mandatory_arch = find { ref($_) eq 'ARRAY' } $config-{mandatory_arch},
(ref($config-{mandatory_arch}) eq 'HASH' ?
($config-{mandatory_arch}{$target}, $config-{mandatory_arch}{default}) :
()), [];
So it seems to handle the case with an array in $config-{mandatory_arch}.
Ah yes sorry I had misread the , :)
Re: [Mageia-dev] strange error on build host
On Mon, Dec 31, 2012 at 2:06 PM, Guillaume Rousse guillomovi...@gmail.com wrote: This happens when building krb5: gcc -L../../lib -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fstack-protector-all -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables -I/usr/include/et -fPIC -pie -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags -o t_export_name t_export_name.o common.o -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lkrb5support -lresolv -ldl common.o: file not recognized: File truncated collect2: error: ld returned 1 exit status Is there any kind of file size limit ? It could be a disk full but I would rather think of some problem with parallel build and the file not being fully written at that time
Re: [Mageia-dev] [changelog] cauldron core/release iurt-0.6.16-1.mga3
On 31 Dec 2012 22:48, Thomas Backlund t...@mageia.org wrote: pterjan skrev 31.12.2012 23:58: Name: iurt Relocations: (not relocatable) Version : 0.6.16Vendor: Mageia.Org Release : 1.mga3Build Date: Mon Dec 31 22:55:20 2012 pterjan pterjan 0.6.16-1.mga3: + Revision: 336797 - 0.6.16 * fix chroot cleaning in parallel mode * fix for some packages missing from status file btw, 0.6.15 broke the BS on valstar with this error: Not a HASH reference at /usr/bin/emi line 195. So I rolled back to 0.6.13 that was in use before. Is this package safe to install ? Probably not, I haven't touched emi (I think boklm and tv did in previoys version). I'll have a look
Re: [Mageia-dev] Problem with missing signatures
On Sat, Dec 29, 2012 at 6:49 PM, Kamil Rytarowski n...@gmx.com wrote: Hello! Could we add a trigger to prevent unsigned packages from being uploaded? I've faced again bunch of unsigned packages.. and when I was trying to rebuild plexus-i18n against missing signature, with bumping the release - the build system said it's already built with that version [1]. How is it possible? I have checked the history of this package.. and it was never released as the version in the build system. Am I missing something? Was there an attack and a package injection? Kamil [1] http://svnweb.mageia.org/packages/cauldron/plexus-i18n/current/SPECS/plexus-i18n.spec?r1=268801r2=335589 It seems someone manually uploaded the package on December 1st, after building it on a machine named karamel, this seems to be dmorgan's machine
Re: [Mageia-dev] Problem with missing signatures
On Sat, Dec 29, 2012 at 7:44 PM, Kamil Rytarowski n...@gmx.com wrote: On 29.12.2012 20:11, Pascal Terjan wrote: On Sat, Dec 29, 2012 at 6:49 PM, Kamil Rytarowski n...@gmx.com wrote: Hello! Could we add a trigger to prevent unsigned packages from being uploaded? I've faced again bunch of unsigned packages.. and when I was trying to rebuild plexus-i18n against missing signature, with bumping the release - the build system said it's already built with that version [1]. How is it possible? I have checked the history of this package.. and it was never released as the version in the build system. Am I missing something? Was there an attack and a package injection? Kamil [1] http://svnweb.mageia.org/packages/cauldron/plexus-i18n/current/SPECS/plexus-i18n.spec?r1=268801r2=335589 It seems someone manually uploaded the package on December 1st, after building it on a machine named karamel, this seems to be dmorgan's machine Thank you Pascal for your reply, so it was injected (in other words manually uploaded). I may understand that in some circumstances there is a need to do manual operations over our buildservers, but please for the sake of security and credibility of Mageia prohibit uploading locally built packages into the outside world, servers! Without it a user or developer cannot see if a local mirror (or someone in-the-middle) is injecting Trojan packages or not. This is not supposed to happen but can be done temporarily by sysadmins (usually for some kind of bootstraping when you need the package to be on the mirrors to be able to upload it or another one it requires). It seems it was the case but dmorgan forgot to upload the correct package afterwards. We should definitely improve things so that this is logged and packages get signed when uploaded manually by admins.
Re: [Mageia-dev] glibcompat.h?
On Fri, Dec 28, 2012 at 12:14 AM, Kristoffer Grundström kristoffer.grundstrom1...@gmail.com wrote: Where's that file supposed to be located? I have updated the db, but urpmf glibcompat.h doesn't give me a hint to where it is located. Many projects have a file called glibcompat.h, which one do you want?
[Mageia-dev] rpmlib(TildeInVersions)
Does anyone know what this means? rpmlib(TildeInVersions) = 4.10.0-1 is needed by lib64ftgl-devel-2.1.3-0.rc5.8.mga3.x86_64
Re: [Mageia-dev] starting openssh inside a chroot, as per mageia wiki
On Thu, Dec 27, 2012 at 1:57 AM, Glen Ogilvie n...@linuxsolutions.co.nz wrote: Hi, The wiki, recommends starting openssh from within a chroot, on the following two pages: https://wiki.mageia.org/en/Packagers_chroot https://wiki.mageia.org/en/Chroot This does not work, with a current install from cauldron, as /etc/init.d/sshd does not get created. It seems like the systemd way of starting would be: systemctl start openssh.service But, then produces an error: [root@localhost /]# systemctl start openssh.service Running in chroot, ignoring request. So, Any thoughts on what is the recommended way, and I'll be happy to update the wiki to reflect this. Last time I tried, I gave up after various attempts and now went back to the basics: running sshd and killing it to stop it. Maybe I'll fetch some old initscript.
Re: [Mageia-dev] rpmlib(TildeInVersions)
On Thu, Dec 27, 2012 at 10:38 AM, nicolas vigier bo...@mars-attacks.org wrote: On Thu, 27 Dec 2012, Pascal Terjan wrote: Does anyone know what this means? rpmlib(TildeInVersions) = 4.10.0-1 is needed by lib64ftgl-devel-2.1.3-0.rc5.8.mga3.x86_64 Recent versions of rpm support tilde in version numbers. And it seems lib64ftgl-devel-2.1.3-0.rc5.8.mga3.x86_64 use a ~ in a provide : pkgconfig(ftgl) = 2.1.3~rc5 Well this provide is not new :) So it requires a version of rpm that support tilde in version numbers. It seems to require an old version(= 4.10.0-1), which is strange So the problem would be that this rpm is not installable with urpmi --root if rpm outside of the chroot is too old (rpm 4.9.1.3 from mageia 2). I guess I will need to fix iurt to support --urpmi-root when rebuilding a media
Re: [Mageia-dev] starting openssh inside a chroot, as per mageia wiki
On Thu, Dec 27, 2012 at 10:55 AM, Guillaume Rousse guillomovi...@gmail.com wrote: Le 27/12/2012 11:29, Pascal Terjan a écrit : It seems like the systemd way of starting would be: systemctl start openssh.service But, then produces an error: [root@localhost /]# systemctl start openssh.service Running in chroot, ignoring request. So, Any thoughts on what is the recommended way, and I'll be happy to update the wiki to reflect this. Last time I tried, I gave up after various attempts and now went back to the basics: running sshd and killing it to stop it. Maybe I'll fetch some old initscript. I guess using a specific unit file, using builtin systemd chroot support, should help. See http://0pointer.de/blog/projects/changing-roots for details. Yes having an unit outside of the chroot with RootDirectoryStartOnly=yes would probably help (I had tried the full system chroot and couldn't get it to work and gave up after an hour) but this is annoying to not be able to start a daemon from inside the chroot which is what I usually want to do.
Re: [Mageia-dev] rpmlib(TildeInVersions)
On Thu, Dec 27, 2012 at 12:34 PM, Thomas Backlund t...@mageia.org wrote: Pascal Terjan skrev 27.12.2012 13:12: On Thu, Dec 27, 2012 at 10:38 AM, nicolas vigier bo...@mars-attacks.org wrote: On Thu, 27 Dec 2012, Pascal Terjan wrote: Does anyone know what this means? rpmlib(TildeInVersions) = 4.10.0-1 is needed by lib64ftgl-devel-2.1.3-0.rc5.8.mga3.x86_64 Recent versions of rpm support tilde in version numbers. And it seems lib64ftgl-devel-2.1.3-0.rc5.8.mga3.x86_64 use a ~ in a provide : pkgconfig(ftgl) = 2.1.3~rc5 Well this provide is not new :) So it requires a version of rpm that support tilde in version numbers. It seems to require an old version(= 4.10.0-1), which is strange So the problem would be that this rpm is not installable with urpmi --root if rpm outside of the chroot is too old (rpm 4.9.1.3 from mageia 2). I guess I will need to fix iurt to support --urpmi-root when rebuilding a media Or fix the package to not use a tilde in provides :) This is an automatic provides from the version in pkg-config file
Re: [Mageia-dev] starting openssh inside a chroot, as per mageia wiki
On Thu, Dec 27, 2012 at 2:01 PM, Christiaan Welvaart c...@daneel.dyndns.org wrote: On Thu, 27 Dec 2012, Pascal Terjan wrote: On Thu, Dec 27, 2012 at 10:55 AM, Guillaume Rousse guillomovi...@gmail.com wrote: Le 27/12/2012 11:29, Pascal Terjan a écrit : It seems like the systemd way of starting would be: systemctl start openssh.service But, then produces an error: [root@localhost /]# systemctl start openssh.service Running in chroot, ignoring request. So, Any thoughts on what is the recommended way, and I'll be happy to update the wiki to reflect this. Last time I tried, I gave up after various attempts and now went back to the basics: running sshd and killing it to stop it. Maybe I'll fetch some old initscript. I guess using a specific unit file, using builtin systemd chroot support, should help. See http://0pointer.de/blog/projects/changing-roots for details. Yes having an unit outside of the chroot with RootDirectoryStartOnly=yes would probably help (I had tried the full system chroot and couldn't get it to work and gave up after an hour) Do you mean with systemd-nspawn? Yes, it seems my chroot was not enough of a real system for it to work
Re: [Mageia-dev] rpmlib(TildeInVersions)
On Thu, Dec 27, 2012 at 3:37 PM, Charles A Edwards c...@eslrahc.com wrote: On Thu, 27 Dec 2012 12:54:16 + Pascal Terjan wrote: Or fix the package to not use a tilde in provides :) This is an automatic provides from the version in pkg-config file Then why not use define _provides_exceptions This provides is correct and may be used by other packages, I see no reason to remove it Old rpm accepts it New rpm accepts it and handles it slightly better I don't really see a reason to forbid installing the package with an old version rpm if it was built with the new rpm given that the produced rpm is exactly the same apart from this added rpmlib(TildeInVersions) fake dependency and it would work perfectly fine without it.
Re: [Mageia-dev] rpmlib(TildeInVersions)
On Thu, Dec 27, 2012 at 4:27 PM, Christiaan Welvaart c...@daneel.dyndns.org wrote: On Thu, 27 Dec 2012, Pascal Terjan wrote: On Thu, Dec 27, 2012 at 3:37 PM, Charles A Edwards c...@eslrahc.com wrote: On Thu, 27 Dec 2012 12:54:16 + Pascal Terjan wrote: Or fix the package to not use a tilde in provides :) This is an automatic provides from the version in pkg-config file Then why not use define _provides_exceptions This provides is correct and may be used by other packages, I see no reason to remove it Old rpm accepts it New rpm accepts it and handles it slightly better I don't really see a reason to forbid installing the package with an old version rpm if it was built with the new rpm given that the produced rpm is exactly the same apart from this added rpmlib(TildeInVersions) fake dependency and it would work perfectly fine without it. AFAICT a Requires: pkgconfig(ftgl) 2.1.3 will be rejected by old rpm but matched by new rpm. We may need to backport this feature. Yes but the provides was already there on Mageia 2 and at least will work find if something requires unversionned pkgconfig(ftgl) (and 2.1.3~rc5 is likely to have 2.1.3 API so 2.1.3 not matching is a good thing :) )
Re: [Mageia-dev] libffi.so.6 pb ?
On Thu, Dec 27, 2012 at 7:18 PM, Christiaan Welvaart c...@daneel.dyndns.org wrote: On Thu, 27 Dec 2012, philippe makowski wrote: can someone explain me why now I have in http://check.mageia.org/cauldron/philippem/build.html a lot of fail because libffi.so.6 is not there ? is there somewhere a depency problem ? I never had before to explicitly ask for libffi build depend for these packages See the thread Rebuild failed on i586 for @334667:drakx-installer-stage2-15.15-1.mga3.src.rpm Fixed with ghc-7.6.1-2.mga3 so you should probably just try again. New build is in progress, build.html will be updated tomorrow after it completes Meanwhile you can watch it on http://pkgsubmit.mageia.org/autobuild/index.php?run=2012-12-27
[Mageia-dev] Another problem with new rpm
It seems you can no longer use a variable not coming from a tag as a
parameter of %setup
The following spec leads to error: line 88: Bad %setup option -n:
missing argument
%define pre rc5
%define rel 5
%if %pre
%define release %mkrel 0.%{pre}.%{rel}
%define distname%{name}-%{version}-%{pre}.tar.bz2
%define dirname %{name}-%{version}~%{pre}
%else
%define release %mkrel %{rel}
%define distname%{name}-%{version}.tar.bz2
%define dirname %{name}-%{version}
%endif
[...]
%setup -q -n %{dirname}
So far 8 packages are affected
Re: [Mageia-dev] Another problem with new rpm
On Wed, Dec 26, 2012 at 2:13 PM, Pascal Terjan pter...@gmail.com wrote:
It seems you can no longer use a variable not coming from a tag as a
parameter of %setup
The following spec leads to error: line 88: Bad %setup option -n:
missing argument
%define pre rc5
%define rel 5
%if %pre
%define release %mkrel 0.%{pre}.%{rel}
%define distname%{name}-%{version}-%{pre}.tar.bz2
%define dirname %{name}-%{version}~%{pre}
%else
%define release %mkrel %{rel}
%define distname%{name}-%{version}.tar.bz2
%define dirname %{name}-%{version}
%endif
[...]
%setup -q -n %{dirname}
So far 8 packages are affected
And the really annoying ones are: %setup -q -n %{oname}-%{version}
I would hate to have to expand the variable
Re: [Mageia-dev] Another problem with new rpm
On Wed, Dec 26, 2012 at 3:11 PM, Pascal Terjan pter...@gmail.com wrote:
And the really annoying ones are: %setup -q -n %{oname}-%{version}
I would hate to have to expand the variable
Oops this one is still working (I don't know why), the package had
another problem :)
So it would seem only the variables inside a condition are empty on
the %setup line and prevent building the src.rpm
Re: [Mageia-dev] Problem with urpmq ??
On Wed, Dec 26, 2012 at 3:23 PM, Sander Lepik sander.le...@eesti.ee wrote: 26.12.2012 16:33, Robert Fox kirjutas: [root@mainfox rfox]# urpmq ssh No package named ssh [root@mainfox rfox]# urpmq sshd No package named sshd [root@mainfox rfox]# urpmq kernel No package named kernel [root@mainfox rfox]# urpmq kde No package named kde Doesn't seem to work anymore . . . Merry XMas - R.Fox I think you have to use urpmq -y ssh Or --fuzzy if you like the long version. Yes it seems the default has changed, I noticed it recently...
Re: [Mageia-dev] Another problem with new rpm
On Wed, Dec 26, 2012 at 5:46 PM, Jani Välimaa jani.vali...@gmail.com wrote:
On Wed, 26 Dec 2012 14:13:44 +
Pascal Terjan pter...@gmail.com wrote:
It seems you can no longer use a variable not coming from a tag as a
parameter of %setup
The following spec leads to error: line 88: Bad %setup option -n:
missing argument
%define pre rc5
%define rel 5
%if %pre
%define release %mkrel 0.%{pre}.%{rel}
%define distname%{name}-%{version}-%{pre}.tar.bz2
%define dirname %{name}-%{version}~%{pre}
%else
%define release %mkrel %{rel}
%define distname%{name}-%{version}.tar.bz2
%define dirname %{name}-%{version}
%endif
[...]
%setup -q -n %{dirname}
So far 8 packages are affected
Similar approach works at least for openttd.
However macro isn't called %dirname in openttd.spec. What if you
rename %dirname to something else?
Ah that would make sense :-)
