Re: [Mageia-dev] Upcoming release freeze: 14 packages needs fixing, by Sunday
On Mon, 8 Apr 2013, Juergen Harms wrote: On 04/06/2013 06:35 AM, andre999 wrote: did a little research to hopefully help a bit, on packages still in the list. ( used http://rpmfind.net/linux/ ) cross-avr-gcc See bugzilla: https://bugs.mageia.org/show_bug.cgi?id=7825 Looks like an incompatibilty between the object gcc (which is now 4.7.2) and the target gcc (the specfile still pulls in 4.6.2). To make cross-avr-gcc build - cross-avr-binutils (which is used as a dependency) must be rebuilt to use binutils-2.23 (the present cross-avr-binutils uses 2.20), 2.23.2 I guess? - cross-avr-gcc must be re-built to use gcc-4.7.2 (and some tweeks - see bugzilla 7825) We don't really have a choice here (: I have locally made such a build and successfully use it in production for building the software for my AVR cpus (attached my specfile = attachment 3044). The reasons why I did not submit my local build are that there are some serious rpmlint warnings (serious at least for cross-avr-binutils: complaints about the use of hardlinks) which I did not manage to get rid of - but also that I did not want to interfere with the work of the maintainer. 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 don't actually maintain these packages so you will likely end up being the maintainer. avr-libc doesn't need to be updated? Christiaan
[Mageia-dev] libvirt problems (was Re: [changelog] [RPM] cauldron core/release xen-4.2.1-6.mga3)
On Sun, 3 Mar 2013, Thierry Vignaud wrote: On 2 March 2013 23:30, alien wrote: alien 4.2.1-6.mga3: + Revision: 401170 - Fix creation of log directory now if someone would fix libvirt/virt-manager with xen... And also for qemu/kvm. At least for me virt-manager doesn't show any of my VMs anymore. I can't see them with virsh either but I never used that tool before so maybe I didn't give the right command. Christiaan
[Mageia-dev] Freeze push request: iceape
hi, Please submit iceape in cauldron, this will update it to 2.16 which has security fixes, bugfixes, and some new features. It should not interfere with anything and will also be sent to mga2 as security update (with minor changes). Christiaan
[Mageia-dev] Freeze push: gstreamer1.0-libav
hi, Please submit gstreamer1.0-libav, which updates the package to a snapshot of upstream git master/HEAD (development for gstreamer 1.1). This is needed to get it working with ffmpeg 1.1 and allows us to drop all patches we have for ffmpeg 1.0. The current run-time problem is described in https://bugs.mageia.org/show_bug.cgi?id=8925 - basically WMA and possibly other audio formats cannot currently be played in cauldron with applications that use gstreamer 1.0. The video scaling plugin is disabled upstream because it apparently doesn't work. AFAICT this doesn't cause any problems. Tested: - demuxing MXF - decoding H.264 video - decoding WMA audio - muxing VOB/MPEG PS - encoding MPEG 2 video - encoding MPEG layer 2 audio Christiaan
Re: [Mageia-dev] Gnome mess in Mageia SVN...
On Sun, 24 Feb 2013, Sebastian wrote: Not to mention there is serious doubts the the 3.8.0 release will be good enough to work properly for all endusers when the fallback is dropped, so it would need atleast a update to 3.8.x as a followup later to provide something that actually works, wich comes back to lack of maintainers... I don't think Mageia providing GNOME 3.8 with the new classic mode made using extensions, rather than the old fall back mode, would cause loads of problems: http://worldofgnome.org/gnome-classic-not-classic-all/ You are not making sense, those screenshots show that these gnome-shell extensions can't replace gnome-panel. Also, software 3D rendering is slow, you do not want to use it in a VM. However, we may be able to keep our "GNOME Classic" session using gnome-panel 3.6.x even with gnome 3.8. This would have to be tested, though. Do you even use it? Shouldn't we first fix totem, for example? It has 2 menu bars: "Videos" and "Movie/Edit/...". Then, audio files stop playing after 1 second when "visual effects" are enabled. 5.1 channel audio also doesn't work right, but the same happens in parole (vlc and mplayer do proper downmixing). Finally, totem can't play WMA files because of ffmpeg 1.1. I have a fix for that ready (update gstreamer1.0-libav to git HEAD) but maybe I need to worry about gnome 3.8 instead. Such an update at this time should be done properly: packaged and tested on the packager's machine first, and only when it all works committed to svn and uploaded. But even then we will likely find new problems that need to be fixed before release. Christiaan
Re: [Mageia-dev] WMA8 gstreamer plugin?
On Thu, 21 Feb 2013, Reinout van Schouwen wrote: Even though I have all nonfree+tainted repositories enabled, Totem (a.k.a. Videos) tells me I'm missing the WMA8 decoder. It offers to search for it, but doing so yields nothing. I have this working fine in Mageia 2 and I'm just wondering what I am missing here. I have these gstreamer1.0 rpms: [reinout@x56v ~]$ rpm -qa|grep gstreamer1.0 gstreamer1.0-tools-1.0.5-2.mga3 gstreamer1.0-mms-1.0.5-3.mga3.tainted gstreamer1.0-plugins-bad-1.0.5-3.mga3.tainted gstreamer1.0-libav-1.0.5-2.mga3 Broken with ffmpeg 1.1, see https://bugs.mageia.org/show_bug.cgi?id=9043 Parole for example should work, though - gstreamer0.10-ffmpeg was patched for this problem. Christiaan
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release powermanga-0.91-2.mga3
On Mon, 18 Feb 2013, zezinho wrote:
Em 17-02-2013 22:03, Charles A Edwards escreveu:
1/1:powermanga#
mv: cannot stat ‘/var/lib/games/powermanga.hi’: No such file or
directory
No such file or directory
warning: %post(powermanga-0.91-2.mga3.x86_64)
scriptlet failed, exit status 1
ERROR: 'script' failed for
powermanga-0.91-2.mga3.x86_64:
Yes, I could not find a nice way to only move file if it exists : something
like below fails. any hints?
[ -f %{_localstatedir}/lib/games/%{name}.hi ] && mv
%{_localstatedir}/lib/games/%{name}.hi %{_localstatedir}/games/%{name}/%{name}.hi
That is a logical expression, && means both sides need to be true, so
the line fails when the file doesn't exist. You wanted something like:
if [ -f %{_localstatedir}/lib/games/%{name}.hi ]; then
mv %{_localstatedir}/lib/games/%{name}.hi
%{_localstatedir}/games/%{name}/%{name}.hi
fi
Christiaan
[Mageia-dev] x11-driver-video-qxl/qemu/libvirt (was Re: Please remove qemu, and qemu-img from Mageia 3.)
On Sun, 3 Feb 2013, David W. Hodgins 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. Qemu (or rather each qemu-system-*) is an emulator at its core, so slowness is not a huge surprise. You probably wanted to run it in (fast) virtualization mode - use qemu-kvm for that (and the kvm module for your cpu must be loaded to get virtualization working). But running qemu directly is tiresome, try virt-manager - it works about as well as virtualbox even if I need to run it as root. I use virt-manager/qemu-kvm to build+test mga2 updates for iceape, only graphics (spice+vmvga) is slow (but better than vnc+cirrus). Unfortunately people keep updating libvirt, apparently without testing it - now it is broken again in cauldron. I need to kill all the qemu-system-* and qemu-kvm that libvirtd starts one by one before virt-manager can connect. 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 A month ago I updated the spice packages; I also tried to update x11-driver-video-qxl (which is part of spice AFAIK) but it did not work at all. So if you ask for *that* package to be removed, fine with me. Christiaan
Re: [Mageia-dev] Cleaning up init
On Tue, 29 Jan 2013, JA Magallón wrote: After a test with symlinks -r, I discovered I had /etc/rc.d full of dangling symlinks, due to services moved to systemd. Should an update of initscripts clean them (symlinks -rd /etd/rc.d) ? I suppose this will also happen when people updates mga2 to mga3... In sendmail's post script I have a: chkconfig --del sendmail (guarded by some ifs!) so no leftover symlinks from sendmail. Christiaan
Re: [Mageia-dev] Proposal for Gstreamer 1.0 packaging: tainted version should require the tainted specific plugins
On Mon, 28 Jan 2013, Olav Vitters wrote: To allow Totem to play back any file, in practice you want to install GStreamer 1.0 from the tainted section. Ideally to play back a lot of files, you'll want: gstreamer1.0-dts gstreamer1.0-faad gstreamer1.0-x264 gstreamer1.0-amrwbdec However, I cannot rely on those in totem.spec, because they are in the tainted section. I see two ways of solving this: 1. Building a non-tainted and a tainted totem The tainted one has Requires: for the tainted gstreamer 1.0 packages you'll very likely want. Benefit: - Avoids Gstreamer 1.0 plugin packages from depending on lots of other packages Drawback: - Has to be repeated for every video player that uses GStreamer - Tracking subpackages can be difficult - Totem tainted version has a lot more dependencies 2. Ensure that installing the tainted gstreamer1.0 plugin packages installs all related tainted plugin packages Example: gstreamer1.0-plugins-bad package in tainted should have: Requires: gstreamer1.0-dts Requires: gstreamer1.0-faad Due to subpackages possibly being moved in and out of the tainted section, the only thing I want to change is the Requires. I'm not planning to merge the subpackage.. even if it maybe is a little bit weird to have the main package always require the subpackage. Benefit: - Ensures that enabling tainted section makes video playing 'work' in any player that uses GStreamer - List of subpackages is maintained in just one place Drawback: - Increases the size + dependencies of the tainted gstreamer subpackage - Cannot just install just one tainted subpackage, have to install them all at once I think #2 is the best option. If someone enables tainted, then likely they just want video playing to work. Furthermore, this avoids changing all the video players which could use GStreamer. Have you noticed gstreamer0.10-decoders and gstreamer0.10-decoders-audio ? Those can do the same as your point 2. but for all plugins independent of the source packages. So basically task- packages for gstreamer plugins that totem, other players and transcoders/editors can use. That way you get meta packages for demuxers, muxers, audio-decoders, audio-encoders, video-decoders, and video-encoders which depend on the standard/typical plugins. Christiaan
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release lcdproc-0.5.6-6.mga3
On Sun, 27 Jan 2013, AL13N wrote: 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... Try to change hd44780_DEPENDENCIES there to EXTRA_hd44780_DEPENDENCIES . Library deps are automatic of course but defining foo_DEPENDENCIES overrides the automatic deps generated by automake. but... this isn't the only driver, does this mean i'll have to change dependencies for almost all these drivers? Christiaan
Re: [Mageia-dev] GRUB can't see HD from chroot unless parent /dev is bind-mounted in chroot ?
On Wed, 16 Jan 2013, AL13N wrote: A) mount --bind solution (in fact, only /dev is required) ; mount /proc and /sys can be done inside. AFAIK there is no need to bind mount /dev, just mount devtmpfs. Christiaan
Re: [Mageia-dev] libvirt fails to build
On Sun, 13 Jan 2013, Colin Guthrie wrote: libvirt failed to build with mass-rebuild. I also tweaked it's tmpfiles support but it too didn't build (unsurprising as it fails in configure). I tried with both kernel-headers and kernel-source but it didn't help. Can someone with more clue here have a look? http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20130113155229.colin.valstar.17600/log/libvirt-1.0.1-5.mga3/build.0.20130113155250.log This likely the same problem as: http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/2013061923.umeabot.valstar.10551/log/connman-1.9-4.mga3/build.0.2013062158.log I tried to fix one such issue in bridge-utils, but I think the header file linux/if_bridge.h itself is wrong. It uses struct in6_addr but doesn't #include in6.h . Christiaan
Re: [Mageia-dev] Mate Environment
On Sun, 13 Jan 2013, Sandro CAZZANIGA wrote: Is there going to be Mageia Mate isos for version 3? Do you mean Mate the gnome2 successor? And then what do you mean with isos in this case? It is not even packaged in cauldron, that would first need to be done before a whole desktop environment can end op on ISO images. Christiaan
Re: [Mageia-dev] proftpd - why was mdv package imported over ours nuking our changes???
On Sat, 12 Jan 2013, Colin Guthrie wrote: As mentioned previously it's likely far better these days to NOT import whole packages from other distros. I don't see any reason for "importing" a package that is already in svn. Any merging should be done in a svn checkout and then committed normally. SRPM importing is useful for importing new packages. Christiaan
Re: [Mageia-dev] chromium {beta|stable} versions
On Tue, 8 Jan 2013, Adrien Guichard wrote: I noticed that chromium-browser-unstable was version 25 (which is ok), but stable/beta was stick to version 21. According to http://googlechromereleases.blogspot.fr/ stable version should be 23, beta version 24. Many sandboxing enhancement comes with recent chrome releases and Native API vesion 23 and further are interesting to me, so it would be cool to have those (stable/beta up to date) in Mageia 3. The -unstable 25.x was done by me. It crashes on some pages, e.g. http://pkgsubmit.mageia.org/ and I disabled Native API support because it relied on bundled binaries. OTOH it does support h.264 video through system ffmpeg. A build of version 24 exhibited the same renderer process segfault so I did not upload any beta or stable packages. Christiaan
Re: [Mageia-dev] ANN: glibc-2.17 landing on cauldron...
On Mon, 7 Jan 2013, David Walser wrote:
Thierry Vignaud wrote:
Preparing... #
Installation failed:file /usr/lib64/audit from install of
audit-2.2.2-3.mga3.x86_64 conflicts with file from package
glibc-6:2.17-1.mga3.x86_64
file? %{_libdir}/audit is a directory, and even if it is owned by two
packages, that shouldn't
cause a conflict. That directory is owned by glibc and audit on mga2, so
that's not new. Fedora's
audit package has it owning this directory, so that's not obviously wrong
either. Maybe an issue
with the new rpm version?
Different permissions:
[cjw@hactar audit]$ ls -ld usr/lib64/audit /usr/lib64/audit
drwxr-xr-x 2 root root 27 Jan 2 15:06 /usr/lib64/audit
drwxr-x--- 2 cjw cjw 6 Jan 8 02:34 usr/lib64/audit
Christiaan
Re: [Mageia-dev] problem with %_smp_mflags in Cauldron
On Sun, 6 Jan 2013, Pascal Terjan wrote:
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
Fine. I might call it _build_njobs but of course the name is not the
important part.
Christiaan
Re: [Mageia-dev] problem with %_smp_mflags in Cauldron
On Sun, 6 Jan 2013, philippe makowski wrote: I have a build fail in Cauldron (http://pkgsubmit.mageia.org/autobuild/cauldron/x86_64/core/log/python-cairo-1.10.0-3.mga3.src.rpm/build.0.20130104032637.log) because %python3_waf is resolved as /usr/bin/waf-3.3 build -l12 -j12 To solve it we could add a new rpm macro that is only allowed to be empty or have -jN (N >= 1), e.g. "_njobs_mflag". Christiaan
[Mageia-dev] Can fftw2 and glitz be dropped?
hi, AFAICT nothing depends on fftw2 and glitz libraries, should they be removed (they don't currently build)? I have not checked for build dependencies. Note that packages that cannot be built from source in cauldron core/tainted can't be released in mageia 3. There are currently about 800 packages that don't build, see http://pkgsubmit.mageia.org/autobuild/ Christiaan
Re: [Mageia-dev] More i586/64 collisions
On Fri, 4 Jan 2013, Frank Griffin wrote: 1 installation transactions failed There was a problem during the installation: file /usr/bin/gdbus-codegen from install of libglib2.0-devel-2.34.3-2.mga3.i586 conflicts with file from package lib64glib2.0-devel-2.34.3-2.mga3.x86_64 file /usr/bin/glib-genmarshal from install of libglib2.0-devel-2.34.3-2.mga3.i586 conflicts with file from package lib64glib2.0-devel-2.34.3-2.mga3.x86_64 file /usr/bin/gobject-query from install of libglib2.0-devel-2.34.3-2.mga3.i586 conflicts with file from package lib64glib2.0-devel-2.34.3-2.mga3.x86_64 file /usr/bin/gtester from install of libglib2.0-devel-2.34.3-2.mga3.i586 conflicts with file from package lib64glib2.0-devel-2.34.3-2.mga3.x86_64 Does anyone know if the results of these tools are target independent? Christiaan
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release cunit-2.1.2-2.mga3
On Thu, 3 Jan 2013, Thierry Vignaud wrote: On 2 January 2013 16:44, cjw wrote: cjw 2.1.2-2.mga3: + Revision: 337625 + rebuild (emptylog) Why the empty changelog? I thought there was a commit pending in svn which would be sufficient to describe my change (I used a patch instead of sed). But the fix was already submitted without an increased release number, so my update was not strictly necessary. Christiaan
[Mageia-dev] Mesa 9.1 in mga3 or revert to llvm 3.1?
hi, Since Mesa 9.0 apparently doesn't build with llvm 3.2 we are getting many build failures because mesa packages depend on libllvm3.1 which isn't available. I have llvm 3.2pre+amdgpu and mesa 9.1pre ready to upload which should fix those build problems. Gnome-shell and armagetron seem to work OK with them, for neverball I get https://bugs.freedesktop.org/show_bug.cgi?id=58839 but it still works (maybe with a lower framerate). Mesa 9.1 release is scheduled for february 2013 AFAIK. So is there a reason why I should not upload these two packages? Christiaan
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release llvm-3.2-1.mga3
On Sat, 29 Dec 2012, Balcaen John wrote: Le lundi 24 décembre 2012 12:49:23 mitya a écrit : [...] mitya 3.2-1.mga3: + Revision: 334668 - Fix build - Cleanup, split apidocs to separate package + kamil - get rid of %clean - remove P1, merged upstream - update Version and Release tago to 3.2 and 1 - new version 3.2 Can you also rebuild packages depending of llvm ? AFAICT neither mesa 9.0 nor 9.1 (snapshots) build with llvm 3.2. Instead, the "r600" llvm branch needs to be used for mesa 9.1, which is not in sync with the 3.2 release. Christiaan
Re: [Mageia-dev] libffi.so.6 pb ?
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. Christiaan
Re: [Mageia-dev] rpmlib(TildeInVersions)
On Thu, 27 Dec 2012, Pascal Terjan wrote: On Thu, Dec 27, 2012 at 3:37 PM, Charles A Edwards 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. Christiaan
Re: [Mageia-dev] starting openssh inside a chroot, as per mageia wiki
On Thu, 27 Dec 2012, Pascal Terjan wrote: On Thu, Dec 27, 2012 at 10:55 AM, Guillaume Rousse 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? Christiaan
Re: [Mageia-dev] Rebuild failed on i586 for @334667:drakx-installer-stage2-15.15-1.mga3.src.rpm
On Mon, 24 Dec 2012, Thierry Vignaud wrote:
On 24 December 2012 12:05, Ulri the scheduler bot
wrote:
Build of the following packages failed:
- @334667:drakx-installer-stage2-15.15-1.mga3.src.rpm
Failure details available in
http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20121224110309.tv.valstar.3450/log
Reason:
@334667:drakx-installer-stage2-15.15-1.mga3.src.rpm: build_failure
Log files generated:
http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20121224110309.tv.valstar.3450/log/drakx-installer-stage2-15.15-1.mga3/build.0.20121224110417.log
http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20121224110309.tv.valstar.3450/log/drakx-installer-stage2-15.15-1.mga3/rpm_qa.0.20121224110417.log
http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20121224110309.tv.valstar.3450/log/drakx-installer-stage2-15.15-1.mga3/install_deps-1.0.20121224110417.log
Local build works smoothly.
But in iurt, it fails on:
FATAL: no match for /usr/lib/gdk-pixbuf-2.0/*/loaders.cache
However this file is provided by libgdk_pixbuf2.0_0 which _IS_
installed in the chroot.
But's it's a %ghost file to be filled in in %post script.
It's failling in iurt b/c
/usr/lib64/gdk-pixbuf-2.0/bin/gdk-pixbuf-query-loaders: error while
loading shared libraries: libffi.so.6: cannot open shared object file:
No such file or directory
And indeed lib{64,}gdk_pixbuf2.0_0 do not require libffi...
And thus it's not installed in chroots...
Maybe the problem is that ghc provides libffi.so.6()(64bit) so it gets
selected instead of lib64ffi6.
Christiaan
Re: [Mageia-dev] Autobuild logs
On Fri, 21 Dec 2012, Pascal Terjan wrote: Logs for each run are about 1.5G I am considering only keeping logs for latest build (or maybe the previous success if the package is now failing) Maybe keep an old failed build log if the latest build also failed and the log file sizes are different (e.g. >1k smaller or larger). In the 18-12 run some package builds were still killed (timeout?) e.g. chromium-browser-unstable-25.0.1354.0-1.mga3.src.rpm . Maybe this can be noted on the webpage, and even be included in the statistics (#timeouts listed). Christiaan
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release gtk-engines2-2.20.2-3.mga3
On Wed, 12 Dec 2012, Götz Waschk wrote: On Wed, Dec 12, 2012 at 1:26 PM, Thierry Vignaud wrote: On 12 December 2012 12:32, gw666 wrote: gw666 2.20.2-3.mga3: + Revision: 329876 + rebuild (emptylog) What changed Nothing. It just built this time. I don't know why pterjan's automatic build failed before. The autobuild failure was on 2.20.2-1.mga3 while you changed the release from 2 to 3. The build issue was already fixed in -2 . Christiaan
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release mplayer-1.1-7.mga3
On Sun, 9 Dec 2012, luigiwalser wrote: Name: mplayer Relocations: (not relocatable) Version : 1.1 Vendor: Mageia.Org Release : 7.mga3Build Date: Sun Dec 9 01:04:15 2012 luigiwalser 1.1-7.mga3: + Revision: 328988 - fix building with updated giflib - update bundled ffmpeg to 1.0.1 MPlayer is built against system ffmpeg (despite not having a buildrequires on it), so why not remove the bundled ffmpeg instead of updating it? Christiaan
Re: [Mageia-dev] [RFC] renaming -debug packages as -debuginfo
On Sat, 1 Dec 2012, Thierry Vignaud wrote: Every other distros name their debug packages as foobar-debuginfo. We name them foobar-debug instead. Due to this, we've to patch various packages (gdb, ...) for that. And we've to maintain those patches of course... What do you think about naming them -debuginfo like other distros do and drop those patches? Will all -debuginfo packages get a Provides+Obsoletes on the -debug package name? Otherwise we get a lot of orphan packages on users' systems plus potential file conflicts between -debug and -debuginfo packages. Christiaan
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release bind-9.9.2-1.mga3
On Fri, 9 Nov 2012, guillomovitch wrote: Name: bind Relocations: (not relocatable) Version : 9.9.2 Vendor: Mageia.Org Release : 1.mga3Build Date: Fri Nov 9 21:43:15 2012 guillomovitch 9.9.2-1.mga3: + Revision: 316758 - sync with fedora spec, for easier maintainance: the real files now live outside the chroot It looks like this overwrote my /var/lib/named/etc/named.conf with a default version so all zones were disabled. I had to restore the config file from backup. Not sure how this happened, though. - new version + fwang - update rpm group Christiaan
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release gstreamer0.10-ffmpeg-0.10.13-5.mga3
On Sun, 11 Nov 2012, Götz Waschk wrote: On Sat, Nov 10, 2012 at 6:38 PM, Christiaan Welvaart wrote: AFAIK it needs to be in the 'tainted' repository (MPEG4 AVC aka h.264 decoder). the same code is in the main ffmpeg package as well, isn't it? So either it has to be disabled in non-tainted build or moved to tainted completely. Oops, I guess you're right. I simply expected it to be disabled in the 'core' ffmpeg build because of all the noise about this decoder wrt open source browsers (chromium has a bundled ffmpeg but the h.264 decoder is only enabled in 'chrome' branded builds). Christiaan
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release gstreamer0.10-ffmpeg-0.10.13-5.mga3
On Sat, 1 Sep 2012, fwang wrote: Name: gstreamer0.10-ffmpeg Relocations: (not relocatable) Version : 0.10.13 Vendor: Mageia.Org Release : 5.mga3Build Date: Sat Sep 1 13:09:14 2012 fwang 0.10.13-5.mga3: + Revision: 286909 - update bundled gstreamer to 0.7.13 + ovitters - use internal ffmpeg as external does not build AFAIK it needs to be in the 'tainted' repository (MPEG4 AVC aka h.264 decoder). Christiaan
Re: [Mageia-dev] Missing sendmail-cf, mutt and whois
On Sat, 10 Nov 2012, Richard Couture wrote: Shouldn't the sendmail-cf be on the same media as the sendmail package? It could be ackward using one without the other. Sendmail and m4 ARE on the distribution DVD but sendmail-cf is not. IMHO sendmail shouldn't be on the DVD, but if it is, sendmail-cf should be included as well. Maybe I should just add it as a dependency of sendmail, it's not like something will break because sendmail-cf is installed. Christiaan
Re: [Mageia-dev] cinelerra/audiokonverter/arista (war Re: rehashing the faac issue)
On Thu, 1 Nov 2012, PhilippeDidier wrote: Christiaan Welvaart a écrit : On Wed, 31 Oct 2012, PhilippeDidier wrote: I don't know actually how to create *.aac files or *.mp4 files with Mageia... if you help me I will be happy... ffmpeg -i foo.mp3 -strict -2 -codec:a aac -format adts foo.aac But AFAIK this uses the ffmpeg internal aac codec which isn't very good. -codec:a libvo_aacenc produces garbage, no idea why About arista: someone decided to use the internal ffmpeg lib from gstreamer-ffmpeg for gstreamer0.10-ffmpeg which broke arista. Now arista must be ported to gstreamer1.0 . You can understand, now, if you need to create aac or mpa or mp4 files : that faac works that softwares built with it work too that nothing inside Mageia work (libvo_aacenc is really bad quality when it doesn't produce garbages) It is a problem with the .aac file format combined with this codec. It works fine with bitrate 192kbit/s just not with anything lower. The codec also works with any bitrate when output to mp4 (aka quicktime movie) files. Or are you saying you do not like the audio quality of this codec? What do you propose then ? Try it yourself and complain to ffmpeg developers if something you need doesn't work. There is now also fdk-aac which is supposed to be good. It has a special license that is somewhat similar to the GPL, may be compatible or not. Christiaan
Re: [Mageia-dev] cinelerra/audiokonverter/arista (war Re: rehashing the faac issue)
On Wed, 31 Oct 2012, PhilippeDidier wrote: I don't know actually how to create *.aac files or *.mp4 files with Mageia... if you help me I will be happy... ffmpeg -i foo.mp3 -strict -2 -codec:a aac -format adts foo.aac But AFAIK this uses the ffmpeg internal aac codec which isn't very good. -codec:a libvo_aacenc produces garbage, no idea why About arista: someone decided to use the internal ffmpeg lib from gstreamer-ffmpeg for gstreamer0.10-ffmpeg which broke arista. Now arista must be ported to gstreamer1.0 . Christiaan
Re: [Mageia-dev] cinelerra (war Re: rehashing the faac issue)
On Wed, 31 Oct 2012, PhilippeDidier wrote: Christiaan Welvaart a écrit : We are not going to carry faac just for convenience to build applications locally. Handbrake, another application that supposedly needs faac, is also GPL licensed so cannot be distributed linked against faac. Arista in mageia supports encoding AAC without faac. Audiokonverter appears to use mplayer for encoding so it should be able to use ffmpeg for AAC. Anything else? You're wrong about audiokonverter : it uses faac to encode into *.aac files I don't know what .aac files are (format), will check. I proposed the two patches to have it in Mageia: Saw that in the bugreport (: About Arista : I tried Arista to create an *.aac file : it complains about missing elements... Could you really create *.aac files ? or did you only read what it is supposed to do. I only tried to transcode video with aac audio track, not audio only. Arista uses gstreamer... and, in Mageia, gstreamer-plugins in tainted are built without faac, I wonder what is missing on my computer to be able to do what you did !!! libavcodec from tainted and gstreamer-ffmpeg/gstreamer-libav - this depends on libvo-aacenc + arista 0.9.7-4 About Cinelerra and Handbrake : everything is GPL licensed except the ISO specification they need to be built ... provided as bundled in hanbrake (reason why it was banned from Mageia-tainted) and required as BuildRequire : faac-devel for cinelerra, preventing to build it for Mageia And Yes absolutely there's a contamination with a non-free source (how the hell an ISO MPEG4 norma could be GPL ? ) AFAIK it's code, not the standard itself Christiaan
Re: [Mageia-dev] cinelerra (war Re: rehashing the faac issue)
On Wed, 31 Oct 2012, Guillaume Rousse wrote: Le 31/10/2012 12:57, Christiaan Welvaart a écrit : On Wed, 31 Oct 2012, Guillaume Rousse wrote: Le 31/10/2012 10:23, Christiaan Welvaart a écrit : On Tue, 2 Oct 2012, Guillaume Rousse wrote: Given the importance of this package for several multimedia-related software (it is a mandatory dependency for cinerella, for instance), I think it's time Do you have a cinelerra source rpm that builds against cauldron ffmpeg? And we can build it without AAC encoding support I think. No. Otherwise, I wouldn't have opened this painful discussion again. Isn't cinelerra licensed under the GPLv2+, which means we are not allowed to distribute binaries linked against a non-free library? It looks like the faac discussion is not painful but completely useless. I wasn't aware of such kind of restriction, but it reminds me of similar cases in the past. Anyway, faac isn't only used for cinelerra, and even if we can't distribute it, having one less ancestor to rebuild manually is still a gain. We are not going to carry faac just for convenience to build applications locally. Handbrake, another application that supposedly needs faac, is also GPL licensed so cannot be distributed linked against faac. Arista in mageia supports encoding AAC without faac. Audiokonverter appears to use mplayer for encoding so it should be able to use ffmpeg for AAC. Anything else? Christiaan
Re: [Mageia-dev] cinelerra (war Re: rehashing the faac issue)
On Wed, 31 Oct 2012, Guillaume Rousse wrote:
Le 31/10/2012 10:23, Christiaan Welvaart a écrit :
On Tue, 2 Oct 2012, Guillaume Rousse wrote:
Given the importance of this package for several multimedia-related
software (it is a mandatory dependency for cinerella, for instance), I
think it's time
Do you have a cinelerra source rpm that builds against cauldron ffmpeg?
And we can build it without AAC encoding support I think.
No. Otherwise, I wouldn't have opened this painful discussion again.
Isn't cinelerra licensed under the GPLv2+, which means we are not allowed
to distribute binaries linked against a non-free library? It looks like
the faac discussion is not painful but completely useless.
Who wants to maintain this package? I built it and it appears to work but
complains a bit - maybe due to cauldron ffmpeg - and crashes when
trying to output AAC ("mp4a") because I forgot to remove that UI option.
Christiaan
[Mageia-dev] cinelerra (war Re: rehashing the faac issue)
On Tue, 2 Oct 2012, Guillaume Rousse wrote: Given the importance of this package for several multimedia-related software (it is a mandatory dependency for cinerella, for instance), I think it's time Do you have a cinelerra source rpm that builds against cauldron ffmpeg? And we can build it without AAC encoding support I think. Christiaan
Re: [Mageia-dev] rehashing the faac issue
On Tue, 30 Oct 2012, Wolfgang Bornath wrote: Nice to see that everyone went back to Start with this discussion, almost using the same words in their arguments. Is this really needed? There has been a wide consensus for the solution to put it into tainted as has been said in this thread as well. There are 2 options Each package in non-free must be inspected case-by-case to know if it can be distributed/used, but their licenses are valid world-wide (because copyright is pretty much universally accepted). The packages in tainted can all be used/distributed *if* patents on software are not considered valid in the country where the user/mirror resides. Do you really want to mix those two? Christiaan
Re: [Mageia-dev] rehashing the faac issue
On Fri, 26 Oct 2012, PhilippeDidier wrote: Guillaume Rousse a écrit : Hello list. The case of faac package has been discussed several times already: https://bugs.mageia.org/show_bug.cgi?id=1730 http://www.mail-archive.com/mageia-dev@mageia.org/msg08059.html https://www.mageia.org/pipermail/mageia-dev/2012-June/016673.html So far, the conclusion was than we had no perfect solution to handle the case of a software being having both licensing and patents issue, whereas usually software only suffer from one of these problems only, and than creating a dedicated 4th repository was unreasonable. Hence the removal of the package from the mirrors (but not from our svn...). unfortunately ... three weeks after the last post on this thread a long silence The problem is the following: 1. faac cannot go into main (see 2 & 3) 2. faac cannot go into tainted (it is not free software) 3. faac cannot go into nonfree (patented in some countries) so we only have 2 options: A. ban faac and use the AAC encoder(s) we already have in mageia or another one that can go into tainted B. add a special repository for faac I prefer option A and I patched a gstreamer based video encoding app to use vo-aacenc instead of faac a while ago. Christiaan
Re: [Mageia-dev] network interface renaming not working anymore
On Thu, 16 Aug 2012, Colin Guthrie wrote: 'Twas brillig, and Christiaan Welvaart at 16/08/12 20:30 did gyre and gimble: hi, When I finally rebooted a cauldron system that acts as a router, it turned out the network interfaces eth0 and eth1 were switched, exposing "internal" services to the outside world and leaving me without internet access. Syslog contains: Aug 15 22:48:29 zem systemd-udevd[404]: error changing net interface name eth0 to eth1: File exists Aug 15 22:48:29 zem systemd-udevd[404]: error changing net interface name eth1 to eth0: File exists Of course this has worked for years, so it breaking is not something anyone would expect. It also seems to be unneeded. After some looking around I could (temporarily) fix it quite easily by adding: ifrename -i eth0 -n rename0 ifrename -i eth1 -n rename1 ifrename -i rename0 ifrename -i rename1 to /etc/init.d/network and describing the mapping in /etc/iftab . So now I have two questions: - Has anyone else seen this? - What change is causing this: kernel, udev/systemd, or something else? The network devices use the same driver so there is no other way to distinguish them than by MAC address or PCI ID. Yeah this is no longer supported upstream as it was apparently very hacky. Last time I asked Kay about it, there was something else to replace it but I've not followed up what that is recently. I'll ask him again next time we're chatting. So it's udev (I tried to install an old udev but that didn't work). Commit looks to be: http://cgit.freedesktop.org/systemd/systemd/commit/src/udev?id=97595710b77aa162ca5e20da57d0a1ed7355eaad Waiting 90s hoping the interface name becomes available is no fun of course but in fact this works fine when the user configured it properly: it did exactly what I now use as workaround only without global control. So we could simply revert it but I wonder why this change was considered necessary. So far I have not found any discussion about it. Christiaan
[Mageia-dev] network interface renaming not working anymore
hi, When I finally rebooted a cauldron system that acts as a router, it turned out the network interfaces eth0 and eth1 were switched, exposing "internal" services to the outside world and leaving me without internet access. Syslog contains: Aug 15 22:48:29 zem systemd-udevd[404]: error changing net interface name eth0 to eth1: File exists Aug 15 22:48:29 zem systemd-udevd[404]: error changing net interface name eth1 to eth0: File exists Of course this has worked for years, so it breaking is not something anyone would expect. It also seems to be unneeded. After some looking around I could (temporarily) fix it quite easily by adding: ifrename -i eth0 -n rename0 ifrename -i eth1 -n rename1 ifrename -i rename0 ifrename -i rename1 to /etc/init.d/network and describing the mapping in /etc/iftab . So now I have two questions: - Has anyone else seen this? - What change is causing this: kernel, udev/systemd, or something else? The network devices use the same driver so there is no other way to distinguish them than by MAC address or PCI ID. Christiaan
Re: [Mageia-dev] madwifi-source package ?
On Mon, 13 Aug 2012, Guillaume Rousse wrote: We have a madwifi-source package, which seems to be used as a build dependency only from wpa_supplicant package. Mandriva used to also have a madwifi package which wasn't imported. Given than madwifi support currently prevent wpa_supplication 1.0 to build (conflicting types declaration for ‘u_int64_t'), and than we seems to be perfectly happy without madwifi driver package in the distribution, is it reasonable to consider than: - we no longer need the 'madwifi-source' package ? - madwifi support in wpa_supplication isn't needed anymore ? I dropped support for this driver from hostapd because of that build problem, but I don't know if anyone is going to complain about that. AFAICT there is now an alternative "free" driver for these devices: ath5k. Christiaan
Re: [Mageia-dev] latest kernels not powering off machines on shutdown
On Fri, 10 Aug 2012, Pascal Terjan wrote: On Fri, Aug 10, 2012 at 7:04 PM, Jose Jorge wrote: Le 09/08/2012 20:10, Thierry Vignaud a écrit : I've the impression that for some time, kernels do not power off machines anymore on shutdown. The kernel prints "System halted." but the machine remains powered. I've seen that with VMs and with real PCs. Does someone else see that? Yes, and some other distros do the same (at least Slitaz). Before Mageia 2, there was no interest in having both halt and poweroff doing the same. Now, we can do "poweroff" to cut the power after stopping the kernel, or "halt" to keep the power on. As I said earlier, if you are looking for these system shutdown commands, use: systemctl reboot systemctl halt systemctl poweroff directly. The "halt, "reboot", and "poweroff" commands are only there for backwards compatibility. How many people expect their machine to power off when they type halt? How many people will want their machine to not halt and not poweroff? Said in another way: - How many people will this change cause problem to? - How many people will benefit from it? I would expect the ratio to be about at least 99.9/0.1 which is why I hate it. This change seem to be done without any consideration for users. So fix it, no change to systemctl is needed AFAICT, just replace the symlink with a tool that does "the right thing", probably running "poweroff" passing all arguments verbatim. Don't forget to fix the manpage as well. Christiaan
Re: [Mageia-dev] latest kernels not powering off machines on shutdown
On Thu, 9 Aug 2012, Colin Guthrie wrote: 'Twas brillig, and Pascal Terjan at 09/08/12 20:04 did gyre and gimble: Yes because it totally makes sense to have a command to halt the operating system but leave the machine using some power for nothing (and preventing you from powering it on with wol). I am sure someone believes it can be useful in some strange scenario. It's very useful and it was essential for me during the previous release to debug shutdown logic. The shutdown command has always been used for this. Apparently you need to pass -H to it now, though. To power off aka 'halt' a machine, shutdown -h was used and this still works according to the manpage. Please read the halt manpage (and others): "These are legacy commands available for compatibility only." So you arguing its behavior is now "fixed" because it was "broken" does not make sense. Christiaan
Re: [Mageia-dev] Task-obsolete and non-sense obsoletes
On Tue, 7 Aug 2012, Pascal Terjan wrote: On Tue, Aug 7, 2012 at 12:31 PM, Olivier Thauvin wrote: But I am still in favor to remove it. In past, package we didn't want to support anymore was just removed from mirrors, and this was enough to show their status. But people will not be notified of it. If a system is obsolete with the new distribution and known to break things/contain major security problems, I think having a place to put the obsoletes is good. But really I wouldn't expect more than 2 or 3 such packages in a release... The package manager (urpmi) can also notify people because it sees which installed packages are not in the configured repositories. Zypper even removes such packages automatically. This would give users the choice to keep an 'obsolete' package installed, while that choice doesn't exist with task-obsolete. Christiaan
Re: [Mageia-dev] [packages-commits] [279280] enable opus support
On Mon, 6 Aug 2012, r...@mageia.org wrote:
Revision: 279280
Author: tv
Modified: cauldron/firefox-beta/current/SPECS/firefox-beta.spec
===
--- cauldron/firefox-beta/current/SPECS/firefox-beta.spec 2012-08-06
11:46:36 UTC (rev 279279)
+++ cauldron/firefox-beta/current/SPECS/firefox-beta.spec 2012-08-06
11:49:09 UTC (rev 279280)
@@ -72,6 +72,7 @@
BuildRequires: python-virtualenv
BuildRequires: gstreamer0.10-devel
BuildRequires: libgstreamer0.10-plugins-base-devel
+BuildRequires: pkgconfig(opus)
Provides: webclient
#Requires: indexhtml
@@ -156,6 +157,7 @@
ac_add_options --with-valgrind
ac_add_options --with-java-include-path=%{java_home}/include
ac_add_options --with-java-bin-path=%{java_home}/bin
+ac_add_options --enable-opus
EOF
export LDFLAGS="%ldflags"
Mozilla source code comes with bundled ogg, vorbis, libopus and has no
support for using system libraries AFAICT. So the BuildRequires on opus is
currently not needed. But maybe someone can patch it to allow using the
packaged libraries (or find such a patch).
Christiaan
Re: [Mageia-dev] OK to update libffi?
On Sun, 5 Aug 2012, Olivier Blin wrote: David Walser writes: John Balcaen writes: 2012/8/5 David Walser : It has a new upstream version 3.0.11 available. It builds fine here. The major number changes from 5 to 6 in this version, which is why I am asking if it is OK to update this package. did you try it before ? (i mean at least rebuild major packages based on it? ) No, but predicting what will build in Cauldron is a crapshoot at best anyway. I don't know exactly what this package does or even what most of the packages that require it are. I just know that it's installed on my system and I don't want unmaintained stuff bitrotting away on my system, hence the interest. Hopefully someone with some insight can say yay or nay. Our biggest users are glib, mesa, wayland, python and llvm. They will have to be rebuilt. Also firefox at least from version 15, unless we want to use the bundled libffi (add --enable-system-ffi to firefox-beta's configure options). Christiaan
Re: [Mageia-dev] wrong action for a specific usb device
On Sat, 4 Aug 2012, Guillaume Rousse wrote: I can't suceed to access the content of my new shiny nikon camera SD card. When pluging the camera, I saw an MTP probe attempt and failure: Aug 4 16:44:04 localhost kernel: [98204.334342] usb 8-1: new high-speed USB device number 10 using ehci_hcd Aug 4 16:44:04 localhost kernel: [98204.449649] usb 8-1: New USB device found, idVendor=04b0, idProduct=042c Aug 4 16:44:04 localhost kernel: [98204.449661] usb 8-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Aug 4 16:44:04 localhost kernel: [98204.449668] usb 8-1: Product: NIKON DSC D3200 Aug 4 16:44:04 localhost kernel: [98204.449674] usb 8-1: Manufacturer: NIKON Aug 4 16:44:04 localhost kernel: [98204.449680] usb 8-1: SerialNumber: 06045584 Aug 4 16:44:04 localhost mtp-probe: checking bus 8, device 10: "/sys/devices/pci:00/:00:1d.7/usb8/8-1" Aug 4 16:44:04 localhost mtp-probe: bus: 8, device: 10 was not an MTP device Manually loading mass-storage module doesn't help. So what does gphoto say? Are you sure it acts as a usb storage device? Christiaan
Re: [Mageia-dev] ANNOUNCE: The /usr move cometh! <---- Instructions
On Fri, 3 Aug 2012, Colin Guthrie wrote: 'Twas brillig, and Pascal Terjan at 03/08/12 00:40 did gyre and gimble: On Fri, Aug 3, 2012 at 12:23 AM, Pascal Terjan wrote: On Sun, Jul 22, 2012 at 1:12 AM, Colin Guthrie wrote: OK, so the packages have now all been uploaded. You should see several packages now that you cannot install on Cauldron. This is intended behaviour. Here is how to update your cauldron systems: 1. Run "urpmi --auto-update" install everything that can be installed. 2. Ensure that latest dracut is installed. Run "urpmi dracut" to make sure (it may have been excluded in the --auto-update if it was in a transaction with other packages that could not be installed). 3. Ensure that you do not have zapata or dpkg installed (rpm -e zapata; rpm -e dpkg) 4. Generate a new initrd and include the conversion script: dracut -f -a convertfs 5. If you have /usr on a separate partition - Ensure there is enough free space to hold /bin, /sbin, /lib and /lib64 content. - If your /usr is mounted readonly, change your /etc/fstab to mount it rw. 6. Reboot. 7. At the bootloader prompt, edit the command line and append: "rw rd.convertfs" (without the quotes) to your command line and then boot. That should be all that is needed :) How to update a chroot? Answering to myself: chroot $chroot urpmi dracut $chroot/usr/lib/dracut/modules.d/30convertfs/convertfs.sh $chroot That did the conversion, but I still can't update, probably because my rpm is too old (rpm-4.9.1.3-2.mga2) as it was not possible to update it before the conversion (it pulls filesystem). Yeah in this case if the conversion is done, I'd just recommend installing filesystem --nodeps and the rest should flow. It's not ideal certainly, but there is still time to polish this a bit before upgraders get hit by this (and as there will be updated rpm packages in the stable releases, it should mitigate this specific problem, but we should still see if we can do things better) Polish this a bit? It is not at all ready, and as I said earlier rpmlib is broken. Please don't upload broken rpm packages to stable releases. Maybe the instructions should be: - install dracut and kernel-desktop-latest from mga3 - reboot, make sure the "usrmove filesystem update" kernel entry is chosen in the bootloader - upgrade to mga3 as usual But that means a lot of things are still missing: - dracut automatically including the conversion script (only when needed?) - automatic generation of the bootloader entry mentioned above - removal of this bootloader entry after conversion Christiaan
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kdelibs4-4.9.0-2.mga3
On Wed, 1 Aug 2012, Colin Guthrie wrote: I have to agree here that something is "funny" in the libattica package which ultimately helped to contribute to this issue. e.g. on my system before update (tho' with similar results after): [colin@jimmy ~]$ rpm -q --provides lib64attica0 libattica.so.0.3()(64bit) lib64attica0 = 0.3.0-1.mga2 lib64attica0(x86-64) = 0.3.0-1.mga2 [colin@jimmy ~]$ rpm -ql lib64attica0 /usr/lib64/libattica.so.0.3 /usr/lib64/libattica.so.0.3.0 So I can see how this mistake was made and TBH I could have made the same mistake myself (with the caveat that I likely would not have bumped the version of someone else's package with out confirming first and that it should have been obvious from testing and installing the build) But either way this seems like an issue to fix properly (possibly with an upstream fix or some modification to the library policy when the minor version is "presented" like this). Good catch! Of course it's never the library policy that's wrong. The library major version is apparently 0.4 so the correct package name is lib64attica0.3 for the previous one lib64attica0.4 for the current one ... in the specfile: %define attica_major 0.4 Can the maintainer of this package please fix this? To find the version to use, look up the 'soname' of the library. I use: readelf -a /usr/lib64/libattica.so.0.4|grep SONAME => ...Library soname: [libattica.so.0.4] What follows ".so." is the major version of the library. Christiaan
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release task-obsolete-3-21.mga3
On Wed, 1 Aug 2012, andre999 wrote: This last point reminds me of the obsoletes of openoffice put in the libreoffice spec, when there was no real conflicts and there were some differences. So a regression in libreoffice required me to install upstream libreoffice so I could install openoffice alongside, to work around the regressions when I needed to. So definitely no added value. These obsoletes are still there. Within mageia, libreoffice packages are supposed to replace old openoffice packages, so obsoletes are needed. The solution to the problem you describe is to make the obsoletes versioned so they only replace those old mga/mdv/mdk openoffice packages, not new ones. Christiaan
Re: [Mageia-dev] [RFC] remove support for /etc/rpm/macros.d/*.macros
On Mon, 30 Jul 2012, Olivier Blin wrote: Olav Vitters writes: On Mon, Jul 30, 2012 at 04:47:54PM +0200, Thierry Vignaud wrote: I would like to drop that patch from rpm (one less to maintain). That means basically renaming files: /etc/rpm/macros.d/foobar.macros => /etc/rpm/macros/macros.foobar [..] WDYT? I thought latest idea that /etc is solely for the sysadmin, so shouldn't above be: /usr/rpm/macros/macros.foobar Right, these macros are not supposed to be edited by the sysadmin, we could even use /usr/lib/rpm/macros. (we already use this for perl, php, python, systemd) They are not automatically included it seems (consistent with earlier posted code from rpm). Christiaan
Re: [Mageia-dev] [RFC] remove support for /etc/rpm/macros.d/*.macros
On Mon, 30 Jul 2012, Thierry Vignaud wrote: For years, we patch our rpm in order to support for /etc/rpm/macros.d (very old compat with rpm-4.4). Upstream refused to merge it as "/etc/rpm/ is a "macros.d" style directory already, except in name". I would like to drop that patch from rpm (one less to maintain). That means basically renaming files: /etc/rpm/macros.d/foobar.macros => /etc/rpm/macros/macros.foobar I think you meant: /etc/rpm/macros.d/foobar.macros => /etc/rpm/macros.foobar (/etc/rpm/macros is a file) Christiaan
Re: [Mageia-dev] What to use instead of /dev/usb/lp*
On Sat, 28 Jul 2012, Florian Hubold wrote: Am 25.07.2012 20:05, schrieb Christiaan Welvaart: On Wed, 25 Jul 2012, Jeff Robins wrote: On Wed, Jul 25, 2012 at 2:11 AM, Claire Robinson wrote: usblp is blacklisted but you may find using modprobe usblp cures it for you. If it does then comment it in /etc/modprobe.d/blacklist-cups-common.conf or remove that file. I'll give that a try. Is there a better/newer way to access the device? I'd like to update and fix the program if possible. The blacklisting is not needed anymore with recent cups(?) according to https://bugs.launchpad.net/ubuntu/+source/cups/+bug/902970/comments/12 so removing the file from the cups package should be the solution. Christiaan Are you sure we have the exact same cups usb backend as in recent *buntu versions? AFAIK usblp caused some segfaults and crashes, so it was blacklisted by default. But if any program loads it explicitely, it will work. No, but I plan to update cups to 1.5.4 which has those fixes for usb AFAICT, see http://www.cups.org/str.php?L4128 . My printer is connected through my LAN so can't easily test usb access, however. Christiaan
Re: [Mageia-dev] %_libexecdir - Re: [5228] revert some duplicated manbo stuff (all identical to default but
On Fri, 27 Jul 2012, Thierry Vignaud wrote: The question is: should we enable minidebuginfo by default? This adds 1-3% to each package but it makes us have usefufull traces by default (at least with function names) Not as good as having debug packages installed by default, but still better. This is enabled in FC18. Tough question: - Do we have bugs not being solved because the reporter doesn't install debug packages? - Can we spare this space on the DVDs? My guess is no but I don't build (nor use) them. For cauldron we can expect people to install debug packages when necessary. Christiaan
Re: [Mageia-dev] %_libexecdir - Re: [5228] revert some duplicated manbo stuff (all identical to default but
On Fri, 27 Jul 2012, Colin Guthrie wrote: 'Twas brillig, and Thomas Backlund at 27/07/12 15:21 did gyre and gimble: 27.07.2012 17:16, Anssi Hannula skrev: +1 on one dir regardless of arch, however the question is if that should be /usr/lib or /usr/libexec. On fedora it is the latter, and we seem to have some stuff (plymouth ans some others) there also. Well some packages override this e.g.: http://pkgs.fedoraproject.org/gitweb/?p=systemd.git;a=blob;f=systemd.spec;hb=HEAD#l164 I built systemd with _libexecdir set to /usr/libexec and saw no problems (nothing ended up there), so maybe an old issue that is fixed by now. Christiaan
Re: [Mageia-dev] %_libexecdir - Re: [5228] revert some duplicated manbo stuff (all identical to default but
On Fri, 27 Jul 2012, Thomas Backlund wrote: In that case, I'd say /usr/libexec to keep /usr/lib as arch clean as possible... +1 And I guess we will catch any name conflicts when we start full rebuild... Some packages probably won't build because they list libexec binaries with %_libdir in %files. But that's easy to fix of course and at least the full rebuild will point out the bad file lists. Christiaan
[Mageia-dev] _libexecdir (was Re: [changelog] [RPM] cauldron core/release rpm-mageia-setup-1.148-1.mga3)
On Thu, 26 Jul 2012, Thierry Vignaud wrote:
On 26 July 2012 14:12, Christiaan Welvaart wrote:
%define _libexecdir %{_prefix}/lib
IIRC this is preferred anyway, so we could change the definition of
_libexecdir systemwide and rebuild everything (=
Humm... It was %_prefix/lib until mdv2010.1.
RH/FC differs there, it's %_prefix/lib
We changed when tmb merged manbo stuff into main package.
I fixed in my git repo since that was not intended.
What I was referring to was actually a change of _libexecdir to
/usr/libexec - that is what fedora now uses. No idea about /usr/lib vs
/usr/lib64.
Christiaan
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release rpm-mageia-setup-1.148-1.mga3
On Thu, 26 Jul 2012, Thierry Vignaud wrote:
On 26 July 2012 14:12, Christiaan Welvaart wrote:
Cjw, for some reason, g-ir-extract-deps is now in
%{_libdir}/rpm-mageia-setup/g-ir-extract-deps
instead of /usr/lib/rpm/mageia/g-ir-extract-deps
Caused by automake 1.12 I think. The solution is to add in the specfile:
%define _libexecdir %{_prefix}/lib
That makes it go to /usr/lib/rpm-mageia-setup/g-ir-extract-deps
But it was previously in /usr/lib/rpm/mageia/g-ir-extract-deps
So that's not all.
Oops, it was simply wrong. I think I fixed it in svn now (but automake
needs to be run to propagate the changes). The _libexecdir redefinition is
not needed.
Christiaan
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release rpm-mageia-setup-1.148-1.mga3
On Thu, 26 Jul 2012, Thierry Vignaud wrote:
On 25 July 2012 19:08, tv wrote:
tv 1.148-1.mga3:
+ Revision: 274302
Cjw, for some reason, g-ir-extract-deps is now in
%{_libdir}/rpm-mageia-setup/g-ir-extract-deps
instead of /usr/lib/rpm/mageia/g-ir-extract-deps
Caused by automake 1.12 I think. The solution is to add in the specfile:
%define _libexecdir %{_prefix}/lib
IIRC this is preferred anyway, so we could change the definition
of _libexecdir systemwide and rebuild everything (=
Christiaan
Re: [Mageia-dev] My feeeling about the rpmlib(X-CheckUnifiedSystemdir) dependency
On Thu, 26 Jul 2012, Olivier Thauvin wrote: I do think the way we enforce the need of migrate to /usr fs is just an abuse of rpm. Agreed, I think it even changes the rpmlib ABI/API. rpmlib() deps are used for features supplied by rpmlib itself, while rpm does not maintain /bin /lib etc. Technically, all rpmlib() provides are implemented in rpmdsRpmlib() but filesystem checks cannot be done there because they depend on the rootdir used, which is not supplied to this function. By using the a rpmlib() dependency we create in fact this dependency tree: filesystem => rpm with X-CheckUnifiedSystemdir patch => check fs whereas we want: filesystem => check fs THere another to perform the check w/o needing patch in rpm (so w/o needing a specific rpm first): using pre script. If the %pre script failed rpm will refuse to install the rpm, so something like that: Does that cancel the whole transaction? Another option is to use a dummy package, e.g. usrmovecheck-1-1.mga3.noarch.rpm whis is *not* put in the repository. Instead, the dracut conversion script installs it from /usr/share/... after a succesful filesystem conversion. The installer must also install this dummy package before regular package installation(...). The filesystem pkg can then depend on (for example) "usr_move_required-see_mga3_release_notes" which usrmovecheck provides. The latter pkg has a pre check on /bin /lib etc. not being real directories, but maybe it should not complain if they're missing (they are formally provided by the filesystem pkg which depends on the check pkg, creating a circular dep). Christiaan
Re: [Mageia-dev] What to use instead of /dev/usb/lp*
On Wed, 25 Jul 2012, Jeff Robins wrote: On Wed, Jul 25, 2012 at 2:11 AM, Claire Robinson wrote: usblp is blacklisted but you may find using modprobe usblp cures it for you. If it does then comment it in /etc/modprobe.d/blacklist-cups-common.conf or remove that file. I'll give that a try. Is there a better/newer way to access the device? I'd like to update and fix the program if possible. The blacklisting is not needed anymore with recent cups(?) according to https://bugs.launchpad.net/ubuntu/+source/cups/+bug/902970/comments/12 so removing the file from the cups package should be the solution. Christiaan
Re: [Mageia-dev] Failed to boot after /usr move
On Tue, 24 Jul 2012, Olivier Thauvin wrote:
Can't the switch be done online a perl/python/c programme, eg once the
programme is loaded everything can be done. Or by providing static
binaries of mv/rm/ln ?
There are of course 2 switches, /{lib,bin,bin,lib64} and /var/{run,lock} .
AFAIK the latter can just be done "online" as long as all sockets can be
moved. I'm not sure about the details of moving these special files,
though.
Moving the lib and bin dirs can also be done in-place but /lib/ld.so will
be unavailable for at most a few milliseconds so no new programs can be
started until the symlink is created (unless you know it's broken and
invoke the dynamic loader in /usr/lib(64) directly). Moving libc also
breaks everything until you run ldconfig, and shell scripts can't start
while /bin/sh is not there.
Christiaan
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release libusbx-1.0.12-1.mga3
On Sun, 22 Jul 2012, Olivier Blin wrote: sander85 writes: Name: libusbx Relocations: (not relocatable) Version : 1.0.12Vendor: Mageia.Org Release : 1.mga3Build Date: Sun Jul 22 10:56:07 2012 [...] sander85 1.0.12-1.mga3: + Revision: 273400 - imported package libusbx It conflicts with libusb: Installation failed: file /usr/lib64/libusb-1.0.so.0.1.0 from install of lib64usbx1.0_0-1.0.12-1.mga3.x86_64 conflicts with file from package lib64usb1.0_0-1.0.9-2.mga3.x86_64 Library policy violation, I think I fixed it in 1.0.12-2. Christiaan
Re: [Mageia-dev] free software purity question
On Thu, 19 Jul 2012, Johnny A. Solbu wrote: On Thursday 19 July 2012 04:35, blind Pete wrote: My attitude to non-free firmware is in flux. At the moment I am annoyed by it, but accept it as a fact of life and just install it. I am more that just anoyed. I flat out refuse to install proprietary drivers, as I don't trust them. The reason is that we can't independently verify that they haven't included a backdoor with the driver, to spy on us or the like. Now, I don't believe that they do, but we can't verify it. Also we can't change it to suit our needs. The sacrifice is performance and functionality. Why are you talking about *drivers* when the remark you quote is about *firmware* ? Some open source drivers don't work (well) without them loading non-free firmware into the device. Christiaan
Re: [Mageia-dev] [usrmove] Help building some unbuildable packages: db51 & grub
On Thu, 19 Jul 2012, Shlomi Fish wrote: Now it seems everything builds fine if I only remove the "-fno-tree-dominator-opts" flag. However, I see in the SPEC this: [Q] # -fno-tree-ccp -fno-tree-dominator-opts to avoid breakage in src/bt_dup.c # -fno-tree-pre -fno-tree-pta to avoid breakage in src/hash_page.c CFLAGS="$RPM_OPT_FLAGS -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-pre -fno-tree-pta" %ifarch ppc CFLAGS="$CFLAGS -D_GNU_SOURCE -D_REENTRANT" %endif export CFLAGS [/Q] So can I safely remove that flag? /me is scared of the consequences. The change was imported from mdv's db51-5.1.25-1, removed there probably in 5.1.25-5 . So yes, remove those 3 lines, plus the next 3 for ppc, and then the "export CFLAGS" can also be dropped I guess. Christiaan
Re: [Mageia-dev] Help with libgcc1
On Tue, 17 Jul 2012, Colin Guthrie wrote: 'Twas brillig, and Colin Guthrie at 17/07/12 14:52 did gyre and gimble: 'Twas brillig, and JA Magallón at 16/07/12 00:54 did gyre and gimble: On 07/16/2012 01:34 AM, Colin Guthrie wrote: Hi, On my system I see the following: [colin@jimmy gcc]$ rpm -ql libgcc1 /lib/libgcc_s-4.7.1.so.1 /lib/libgcc_s.so.1 /lib64/libgcc_s-4.7.1.so.1 /lib64/libgcc_s.so.1 /usr/lib/libgcc_s.so.1 As you can see this results in a conflict between these two files: /lib/libgcc_s.so.1 /usr/lib/libgcc_s.so.1 They ultimately (via some strange symlinks) point at the same file so it can be dropped, but I cannot, for the life of me see where the symlink: /usr/lib/libgcc_s.so.1 Is created in the spec. I can see a file of that name being specifically moved out the way but I cannot see how it is then recreated with that name again! Can anyone see in the gcc spec where this file is created? ldconfig ? I tried renaming mine, and ldconfig recreated it. I'm completely blind. I can see it clearly in the spec. I was just reading my ln commands badly or missing a %_prefix or something... hey ho', I know the fix now at least! False alarm. I looked at the wrong file *again*. So still can't see where in the spec this is generated :( /usr/share/spec-helper/lib_symlinks
Re: [Mageia-dev] Mediawiki packaging changes
On Mon, 9 Jul 2012, Oliver Burger wrote: Am 09.07.2012 11:27, schrieb nicolas vigier: Maybe you can rename mediawiki-minimal to mediawiki and package mediawiki-math. And make mediawiki obsolete mediawiki-minimal< 1.18 and mediawiki-math obsolete mediawiki< 1.18, so that the upgrade works. Yep. I didn't think about that. But it's the best way imho. So the package names will be upstream names and we won't break existing installations! Obsoletes are nice, but the provides are the tricky parts. Someone who has mediawiki installed (with math support) won't get the mediawiki-math extension package after the upgrade. Christiaan
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release evolution-3.5.3.1-1.mga3
On Mon, 2 Jul 2012, Colin Guthrie wrote: 'Twas brillig, and Olav Vitters at 02/07/12 08:04 did gyre and gimble: On Sun, Jul 01, 2012 at 09:04:48PM -0400, Charles A Edwards wrote: On Mon, 2 Jul 2012 01:07:39 +0200 (CEST) ovitters wrote: Name: evolutionRelocations: (not relocatable) Version : 3.5.3.1 Vendor: Mageia.Org Release : 1.mga3Build Date: Mon Jul 2 00:55:38 2012 Install Date: (not installed) Build Host: ecosse.mageia.org Group : Networking/Mail Source RPM: (none) Size: 12051792 License: LGPLv2+ Signature : (none) Packager: ovitters Installation failed:lib64edataserverui4 is obsoleted by (installed) lib64edataserverui1-3.4.3-1.mga3.x86_64 New evolution-data-server should fix this (-4). Note: various evolution stuff doesn't build yet (-groupwise, -exchange, etc). No 3.5.3 version has been released for those yet, so not much I can do. The old library (lib[64]edataserverui1) will need to be nuked on the server as it's obsoletes means that the current installation is borked, likely leading to problems building other stuff too. Isn't this whole mess caused by violation of the library policy? The previous packages should have been called: lib(64)edataserverui3.0_1 and the new ones lib(64)edataserveruit3.0_4 . So any obsoletes of 'lib(64)edataserverui4' should not matter (and was likely added because of the same policy violation). Christiaan
Re: [Mageia-dev] gstreamer0.10-faac - package request
Hi, On Sun, 17 Jun 2012, Simple w wrote: I have been running arist-gtk to encode video and almost all presets fail because it needs gstreamer-faac, please see the output: Found only 1 preset working so far in arista, seams it uses gstreamer-faac in almost all presets... I uploaded a new arista to cauldron that uses vo-aacenc instead of faac. Only tested using commandline arista-transcode so not sure if arista-gtk also works and you likely need to run arista-transcode --reset-presets first because it copies the 'preset' files to $HOME/.arista/presets/ Christiaan
Re: [Mageia-dev] packaging amrwb ?
On Wed, 20 Jun 2012, Simple w wrote: In gstreamer0.10-plugins-bad we have: %if %build_plf %define build_amrwb 0 %define build_faac 0 %define build_faad 1 %define build_xvid 1 %define build_dts 1 %endif about faac was already discussed, but i dont understand why amrwb wasnt packaged so that apps can be build against it, it exists in svn, could anyone please clarify? We have vo-amrwbenc in tainted, this should be available to applications using gstreamer through ffmpeg (libavcodec). Christiaan
Re: [Mageia-dev] RaLink 3062 WiFi card
hi, It turns out that support for this chip (see subject) is disabled in mageia kernels: # CONFIG_RT2800PCI_RT33XX is not set # CONFIG_RT2800PCI_RT35XX is not set Similar options for the rt2800 USB driver are also not enabled. Christiaan
Re: [Mageia-dev] Packages with wrong RPM group
On Sat, 30 Jul 2011, Samuel Verschelde wrote: The following packages have RPM groups that are not valid for Mageia packages: What list of groups did you use? Development/Tools is not listed in /usr/share/rpmlint/config.d/distribution.exceptions.conf but you didn't list package(s) with that group. Christiaan
Re: [Mageia-dev] RaLink 3062 WiFi card
On Sat, 30 Jul 2011, Michał Walenciak wrote: I've two PCs with the same RaLink 3062 WiFi card. Those cards are currently (since kernel 2.6.38 or 37) supported by kernel (modules marked as stable). The problem is that on one of the computers I've debian testing with 2.6.39 kernel and it automatically loads proper modules and WiFi card works, and on Mageia PC nothing happens. I tried both 2.6.38 and 3.0.0 kernels (on Mageia) and: * no module is loaded automatically * even if I load proper module manually, nothing happens (module seems to be somehow not related to proper device) Check dmesg for info, especially an error msg about a firmware file. You may need one of the following packages from the nonfree section: rt2860-firmware rt2870-firmware rt3090-firmware rt61-firmware rt73-firmware kernel-firmware-extra (for rt3070.bin and rt3071.bin) Christiaan
Re: [Mageia-dev] Switching VT when in GDM causes X11 quit with fatal error.
On Thu, 28 Jul 2011, Colin Guthrie wrote: Note: systemd doesn't seem to give me a console login - so this is only with regular init - I presume I need to add a symlink somewhere to get regular console logins with systemd :) I'll look into that later. In my VM with systemd, gettys for VC2 and higher are started on demand (after switching to that virtual console) but nothing happens on VC1. Christiaan
Re: [Mageia-dev] Running X11 apps from the console after exporting DISPLAY
On Thu, 28 Jul 2011, Colin Guthrie wrote: Not sure when this started happening but I presume it's a deliberate change. Same here, but it was "a while ago" (: When I login via text console while already running X11, and do: "export DISPLAY=:0; xeyes", I expect to see some googly eyes on my desktop when I switch back. But this doesn't seem to work these days. Is there something I can do to make this work again? I suspect it's maybe related to not knowing the path to the X11 socket file or something? You also need to set XAUTHORITY - I usually get its value from /proc/$pid/environ for an already running process (like gnome-session). But the value is something like /var/run/gdm/auth-for-$user-$X/database . Christiaan
Re: [Mageia-dev] Some more new rpmlint warning on upload
On Wed, 27 Jul 2011, Maarten Vanraes wrote: Op woensdag 27 juli 2011 14:10:06 schreef Michael Scherer: Le mercredi 27 juillet 2011 à 13:37 +0200, Michael Scherer a écrit : * no-url-tag while not blocking, I see no good reason for that. Well, i do have a package that does NOT have an url tag, for the simple reason that i quickly wrote it myself, and there is no version control, no homepage, no nothing, i wouldn't even know what url i should put into it. So create a page for it on the wiki and use that for the URL tag. Christiaan
Re: [Mageia-dev] Some more new rpmlint warning on upload
On Wed, 27 Jul 2011, Michael Scherer wrote: * useless-provides that's when foo provide foo. There is no case where it would needed. AFAIK there are many packages in the i586 repository that are called libfoo-devel and have a provides libfoo-devel. For x86-64 the packages are called lib64foo-devel so the rpmlint warning doesn't show up there. Christiaan
Re: [Mageia-dev] Missing packages
On Wed, 20 Jul 2011, Anne nicolas wrote: Usual mail on missing packages. Please have a look on that list to decrease it: http://check.mageia.org/dependencies.html I removed windowmaker's static-devel package, so wmakerconf needed to be rebuilt without a build dependency on it. Should be fixed now. Christiaan
Re: [Mageia-dev] RFC: gtk-doc proposed changes
On Fri, 22 Jul 2011, Ahmad Samir wrote: ATM gtk-doc requires dblatex which requires texlive -> texlive-texmf; due to the outrageous size of texlive-texmf, building packages in local chroots becomes a bit of pain/burden on my HDD, also each of texlive and xmltex have I/O intensive postinstall scriptlets. The best solution for that may be to put the chroot in a tmpfs. I see the texlive-texmf issue is being discussed in another thread so I'll keep this one about gtk-doc; here're a couple of points: Too bad since this appears to be strongly related to the gtk-doc issue you mention. I mean, providing a minimal set of texlive packages may fix this gtk-doc problem. - Some packages have BR gtk-doc but it's redundant: o They don't have --enable-gtk-doc passed to ./configure, which means that BR isn't used at all o Most of those packages already bundle html gtk-doc's; is there any benefit rebuilding those docs when building the package? or should the gtk-doc BR get dropped in such cases (since no one complained about those html docs all those years)? In general I think it's best to generate everything from original sources [1]. It makes sure all build scripts/code/documentation is generated using the tools in the distro which may be newer and/or have patches compared to the tools used to generate the files shipped with the source code. It also ensures we can support such packages, because when someone reports a bug in a generated file we should never patch that file directly but its source. - I am thinking of splitting gtk-doc itself, putting gtkdoc-mkpdf in a separate sub-package which will require dblatex: o AFAICS dblatex is only used for creating PDF's from XML sources, so only useful for gtkdoc-mkpdf Interesting. o This will result in less HDD grinding due to texlive-texmf and xmltex being, unnecessarily, pulled in chroots (either local ones or on the BS). Note that for most of the packages I saw, --enable-gtk-doc-html is the default (assuming only --enable-gtk-doc was passed to configure). o I don't see any packages with pdf gtk-doc documentation: $ urpmf /usr/share/gtk-doc | grep pdf gives nothing at all. So, theoretically, this split shouldn't break any packages (there're 144 SRPMS that have BR gtk-doc and 5 -devel packages that require gtk-doc). And if any package breaks due to the split, the fix is simply adding BR gtk-doc-pdf. Of course we can make it more painful and require that those 149 packages get a test build before the split is OK'ed... Maybe we should first set as policy to provide HTML developer documentation and not PDFs when there is a choice. Note however that HTML docs generated by doxygen can take a lot of space. Christiaan [1] that's why I'd like to ask you not to remove any autoreconf/autotools/etc. calls from %build (:
Re: [Mageia-dev] Current cauldron updates want to install 32-bit versions that conflict with 64-bit versions
On Mon, 18 Jul 2011, Frank Griffin wrote: Problem seems to be with libX11_6-devel: Not the cause of this problem, although this conflict should be fixed imho. installed okular-devel-4.6.95-0.mga2.x86_64 is conflicting because of unsatisfied libpoppler-qt4-devel[>= 0.8.0] promoting libpoppler-qt4-devel-0.16.7-2.mga2.i586 because of conflict above selecting libpoppler-qt4-devel-0.16.7-2.mga2.i586 okular needs to be updated (or the libpoppler-qt4-devel provides re-added). Christiaan
Re: [Mageia-dev] [RPM] cauldron core/release gtk+2.0-2.24.5-6.mga2
On Sun, 17 Jul 2011, Balcaen John wrote: On Sunday 17 July 2011 14:02:59 Christiaan Welvaart wrote: [...] Orphan packages (without a src.rpm in the repository) should be removed automatically after a few days, we have talked about this before. Maybe you should file a bug report about it if there isn't any yet. Well i asked because urpmi allows me to choose between the 2 libgtk gir packages so an user could choose the wrong package eventually. I guess obsoletes are needed for smooth upgrades of renamed packages. Christiaan
Re: [Mageia-dev] [RPM] cauldron core/release gtk+2.0-2.24.5-6.mga2
On Sat, 16 Jul 2011, Balcaen John wrote: On Monday 11 July 2011 21:46:33 Mageia Team wrote: Name: gtk+2.0 Relocations: (not relocatable) Version : 2.24.5Vendor: Mageia.Org Release : 6.mga2Build Date: Mon Jul 11 21:15:24 [...] wally 2.24.5-6.mga2: + Revision: 122408 - fix gir package requires (require libs) We should remove from repository lib(64)gtk+2.0-gir2.0-2.24.5-4.mga2. binary package. Orphan packages (without a src.rpm in the repository) should be removed automatically after a few days, we have talked about this before. Maybe you should file a bug report about it if there isn't any yet. Christiaan
Re: [Mageia-dev] kernel 3.0 is a big mistake in cauldron
On Sat, 16 Jul 2011, Radu-Cristian FOTESCU wrote: making kernel-desktop-latest to point to kernel-desktop-3.0.0-0.rc7.2.1.mga2 instead of kernel-desktop-devel-2.6.38.8-5.mga2 was a big mistake. there should have been something like kernel-desktop-latest3 for a while, to let people test that 3.0 thing (rc, right? I know this is cauldron, but I'd still prefer a kernel that works) while still having a 2.6 kernel. Please understand linux 3.0 is just a different name for 2.6.40, there's nothing special about it. So a kernel-desktop-latest3 doesn't make any sense. Christiaan
Re: [Mageia-dev] [Mageia 2 specifications] Systemd or not systemd
On Fri, 15 Jul 2011, D.Morgan wrote: On Fri, Jul 15, 2011 at 3:23 PM, Colin Guthrie wrote: 'Twas brillig, and Colin Guthrie at 15/07/11 11:01 did gyre and gimble: Now that it's compiled, I need to test it :D Well it boots. And I have network connections! I have a problem where bluetoothd does not start but I'll solve that one at some point (it was a problem when I last used systemd too!) The various issues can now be solved as we go! Col Now that we have latest systemd rpm, is it OK to enable the systemd switches in the other rpms ? udev, ... OK? it is necessary: I had to fix dbus, consolekit, and accountsservice to get a working system. But mediatomb now starts serving files from nfs on boot, so the new systemd seems to be an improvement. Christiaan
Re: [Mageia-dev] [Mageia 2 specifications] Systemd or not systemd
On Thu, 14 Jul 2011, Eugeni Dodonov wrote: On Thu, Jul 14, 2011 at 20:08, Olivier Blin wrote: Option 2 seems good as well, but does it really have to uninstall sysvinit? Isn't it enough to put some alternatives symlinks for /sbin/init? This is actually a great idea! A perfect candidate for update-alternatives, thanks, I haven't thought on that! Alternatives is not the most reliable system so it should not be used for /sbin/init. You could make 2 conflicting packages that only contain a /sbin/init symlink and provide something which basesystem depends on. Christiaan
Re: [Mageia-dev] [Mageia 2 specifications] Systemd or not systemd
On Wed, 13 Jul 2011, Eugeni Dodonov wrote: Firstly, systemdrequires udev >= 172, what is the policy to update it? According to 'mgarepo maintdb get udev', it has no maintainers, does anyone objects if I grab/update it as well? Since you volunteered, could you take a look at: https://bugs.mageia.org/show_bug.cgi?id=1454 Hotplug works, coldplug doesn't, so I guess something goes wrong with udev. Updating packages to newer versions needs to be done and help with that is welcome, but we also need to fix reported problems. Unrelated: AFAIK you are registered as maintainer of both system-config-printer and hplip in mandriva linux, maybe you want to apply http://svnweb.mageia.org/packages/cauldron/hplip/current/SPECS/hplip.spec?r1=106333&r2=106663 there to fix an old bug which mageia inherited. Christiaan
Re: [Mageia-dev] Standardising the virtual Provides in -devel packages
On Wed, 13 Jul 2011, Ahmad Samir wrote:
https://bugs.mageia.org/show_bug.cgi?id=2065
Using pkgconfig provides looks like an optimal option, we could start
now, whenever we touch a spec we change to the pkgconfig provides, and
gradually all the specs will be adapted.
And for the packages that don't have .pc files we add:
Provides: %{name}-devel = %{version}-release
Provides: lib%{name}-devel = %{version}-release
or we could add them to all packages whether they have .pc files or
not, but still always use pkgconfig() provides as BR in our specs.
Always adding the same provides regardless of what gets added
automatically is probably better and easier. I'd like to modify or clarify
your proposal a bit. When name starts with "lib", use %{oname}-devel and
lib%{oname}-devel as provides. oname must be defined in the specfile as
the name without the lib prefix. That is usually already the case and this
macro is used as argument for mklibname.
Christiaan
Re: [Mageia-dev] Generic 64-bit building question
On Wed, 13 Jul 2011, Radu-Cristian FOTESCU wrote:
That's why there was discussion started, some time ago, in this list, to
create devel packages so that they will provide %{name}-devel and
lib%{name}-deve.
http://comments.gmane.org/gmane.linux.mageia.devel/6365
It isn't clear to me whether the situation to be fixed is Mageia-specific or
the inconsistency shows up also in Fedora, openSUSE, etc.
I thought it was about a small number of some peculiar libs, but it looks like
it's a more generic issue.
Moreover, excuse me, but I find it stupid to have a 64-bit lib called
`libksane-devel`.
This is devel package, not library itself, so it's OK.
I must admit I failed to understand your statement.
What's the difference between:
`libksane-devel` <<-- correct 64-bit name
and
`lib64djvulibre-devel` <<-- correct 64-bit name
?
Why not `lib64ksane-devel` ?
You are right, the package name libksane-devel is incorrect. See
http://www.mageia.org/wiki/doku.php?id=libraries
Christiaan
[Mageia-dev] mesa update needed
hi, The clutter library currently in cauldron doesn't work with current mesa, at least on my graphics hardware. This means programs like totem and gnibbles are not functional. Gnome-shell also appears to require a newer mesa. A recent snapshot of mesa (the same one as in fedora rawhide probably) is already in svn and I tested that totem and gnibbles work with it. So maybe it's time to submit it to cauldron. Christiaan
Re: [Mageia-dev] Looking for victim^w^wvolunteer for Texlive package
On Wed, 6 Jul 2011, Kira wrote: 在 Wed, 06 Jul 2011 21:09:30 +0800, Anne nicolas 寫道: Hi there Here is an interesting topic :).Texlive is one of the biggest package we have for now. Of course split is needed but we postponed it after Mageia 1 to have a look on it. Now here we go! It needs first to have a look on the way we want to split it, Fedora one (zillions of sub-packages) or our own one based on the wau different components are used. Comments, proposals welcome First: Which version? Texlive 2007 or later ones build on luaTex? I have heard that after 2008, building texlive is almost impossible Texlive 2010 is already available in mageia, so I believe this is about improving the existing package(s). That consists mostly of splitting up texlive-texmf(?), but maybe also adding a dependency on a minimal set of fonts to texlive. Currently the texmf subpackage can be removed while most of the programs in the texlive package are probably useless without fonts. Christiaan
Re: [Mageia-dev] gstreamer packaging too split?
On Wed, 6 Jul 2011, Colin Guthrie wrote:
Yeah it is a bit of a grab-bag of stuff, but again, should we still just
bundle everything together anyway and sod the extra disk space needed?
It would be a lot simpler for users ("oh you need $foo? sure, just
installed -ugly/-bad") which is advise they can get direct from upstream
without having to know our particular packaging quirks.
As someone who does upstream support for other projects, it's a pain to
put caveats in all your advice for distros you don't know.
That said, the trade off may be too much, hence the canvassing of
opinions here :)
I think there are only 2 solutions:
- Add a meta package, e.g. gstreamer-codecs-all that can be used to make
sure all available codecs are installed. Some people complain about
"bad" and "ugly" so using those names more is not a good idea.
- Use the packagekit gstreamer plugin, so players install the correct
plugins on demand.
Christiaan
Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?
On Fri, 1 Jul 2011, Radu-Cristian FOTESCU wrote: Now, it's tough to determine what exactly is making kded4 to eat the CPU. As I'm having a single core, I'm burned. At the same time, minor changes that are actually small improvements make me want to stay with 4.6.90, not to revert to 4.6.4 One way to figure that out is to attach gdb to it while it's running and then print a backtrace. If you do that several times, you may break in the code that's running a lot. But even if that works it is likely still not easy to figure out what's going on. Other ways to get information would be to strace (or ltrace) this daemon to get an idea what it's trying to do. But CPU usage by the application itself cannot be seen this way. An easier way to start is to run iotop and check if kded4 is doing any I/O related to this cpu usage. Christaan
Re: [Mageia-dev] Anybody having high CPU by kded4 after upgrading to 4.6.90?
On Fri, 1 Jul 2011, John Balcaen wrote: 2011/7/1 Radu-Cristian FOTESCU : [...] It's not the packager, it's the policy. Adding something just because upstream has provided an optional dependency... So then how are you going to test the functionality without testing it ? AFAICT the question was: what is this added functionality? Did this kde4 component not get network status updates and now it does get them through the library? Christiaan
Re: [Mageia-dev] [115573] SILENT: new file ./SOURCES/gnome-video-effects-0.3. 0-fix-noarch-build.patch
hi, On Wed, 29 Jun 2011, r...@mageia.org wrote: Revision: 115573 Author: wally Date: 2011-06-29 07:17:59 +0200 (Wed, 29 Jun 2011) Log Message: --- SILENT: new file ./SOURCES/gnome-video-effects-0.3.0-fix-noarch-build.patch Added Paths: --- cauldron/gnome-video-effects/current/SOURCES/gnome-video-effects-0.3.0-fix-noarch-build.patch Added: cauldron/gnome-video-effects/current/SOURCES/gnome-video-effects-0.3.0-fix-noarch-build.patch === --- cauldron/gnome-video-effects/current/SOURCES/gnome-video-effects-0.3.0-fix-noarch-build.patch (rev 0) +++ cauldron/gnome-video-effects/current/SOURCES/gnome-video-effects-0.3.0-fix-noarch-build.patch 2011-06-29 05:17:59 UTC (rev 115573) @@ -0,0 +1,23 @@ +--- ./config.sub.archfix 2008-04-01 19:46:41.0 +0200 ./config.sub 2011-04-28 16:43:03.0 +0200 +@@ -352,7 +352,7 @@ case $basic_machine in + | mt-* \ + | msp430-* \ + | nios-* | nios2-* \ +- | none-* | np1-* | ns16k-* | ns32k-* \ ++ | noarch-* | none-* | np1-* | ns16k-* | ns32k-* \ + | orion-* \ + | pdp10-* | pdp11-* | pj-* | pjl-* | pn-* | power-* \ + | powerpc-* | powerpc64-* | powerpc64le-* | powerpcle-* | ppcbe-* \ +@@ -768,6 +768,9 @@ case $basic_machine in + basic_machine=i960-intel + os=-nindy + ;; ++ noarch) ++ basic_machine=noarch ++ ;; + mon960) + basic_machine=i960-intel + os=-mon960 + + You patched a copy of a standard automake file here while only original source files are supposed to be patched. If you want to fix %configure for noarch packages this way, patch automake itself. Running autoreconf -fi (which you removed from the specfile) should then install the fixed config.sub. I'm not sure if patching config.sub is the best way to solve the problem (for noarch packages, %configure2_5x passes noarch-mageia-linux-gnu to ./configure but that target is rejected). It happens in other packages as well and this doesn't look like a new problem, but I don't know of any existing solution. Christiaan
