Packages left behind on f24->f25 upgrade
Hey, I upgraded from f24 to f25 yesterday with dnf system-upgrade. I had a few issues during the upgrade: - ghc-nats has been removed from f25, but was installed on f24 if you had pandoc installed for example. Since ghc is newer and had a soname bump, the upgrade cannot go smoothly unless you use --allowerasing. I filed a bug suggesting that an obsolete could be added to some ghc package so that it's automatically cleaned up. - I got some complaints that some packages are older in f25 than they are in f24, namely: ccache.x86_64 3.2.7-2.fc25 -> missing bodhi update https://bodhi.fedoraproject.org/updates/?packages=ccache dump.x86_64 1:0.4-0.28.b45.fc25 -> missing push to stable https://bodhi.fedoraproject.org/updates/?packages=dump libreswan.x86_64 3.17-2.fc25 -> no f25 build http://koji.fedoraproject.org/koji/packageinfo?packageID=15913 ostree.x86_64 2016.10-4.fc25 -> missing bodhi update https://bodhi.fedoraproject.org/updates/?packages=ostree pyflakes.noarch 1.2.3-2.fc25 -> missing bodhi update https://bodhi.fedoraproject.org/updates/?packages=pyflakes python2-sphinx-theme-alabaster.noarch 0.7.8-2.fc25 -> missing bodhi update https://bodhi.fedoraproject.org/updates/?packages=python-sphinx-theme-alabaster I don't know how to proceed with these, is there some automatic process which runs at some point to let the maintainers know that they probably are missing some updates in fedora 25? Cheers, Christophe signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: libmusicbrainz5 soname bump
On Thu, Nov 27, 2014 at 01:58:23PM +0100, Haïkel wrote: Done. Thanks a lot Haïkel! Christophe pgpCDHfLqen0I.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
libmusicbrainz5 soname bump
Hey, I'm planning to build a new version of libmusicbrainz5 with a new soname into rawhide next week. I've tested that the packages using it still build (cantata, libkcddb, nemo-preview, sound-juicer, sushi). I'm not a proven packager, so I'll need help from the respective maintainers (or from a proven packager) in order to rebuild these. You can find a scratch build at http://koji.fedoraproject.org/koji/taskinfo?taskID=8151159 Cheers, Christophe pgpI8jJtDKOkV.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: a questionable dependency chain
On Thu, Jan 30, 2014 at 08:30:36AM -0500, Cole Robinson wrote: Thanks Christophe! Can you (or elmarco, or alevy), forward that to qemu-devel? Done: https://lists.nongnu.org/archive/html/qemu-devel/2014-01/msg04164.html Christophe pgpxg64rTLNtX.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: a questionable dependency chain
Hey, On Wed, Jan 29, 2014 at 09:21:22AM -0500, Matthias Clasen wrote: I've switched to rawhide yesterday, and discovered that vinagre now forces rsyslog onto my system. That's not great. The dependency chain goes something like this: vinagre - spice - libcacard - ... glusterfs ... - rsyslog-mmjsonparse - rsyslog I think there's at least two questionable links in this chain: - why does libcacard need glusterfs ? Looking at nm output for libcacard.so, I did not see symbols that were obviously related to glusterfs there. However, at build time, libcacard ld command line gets a lot of -lxx, including glusterfs libraries. libcacard is a sub-package of qemu, so I suspect what's happening is it gets linked with all the libraries qemu needs. This patch seems to help there and get rid of the extra libraries in ldd output (did not try an rpm build to check the deps there). diff --git a/libcacard/Makefile b/libcacard/Makefile index 47827a0..9fa297c 100644 --- a/libcacard/Makefile +++ b/libcacard/Makefile @@ -24,7 +24,7 @@ vscclient$(EXESUF): libcacard/vscclient.o libcacard.la libcacard.la: LDFLAGS += -rpath $(libdir) -no-undefined \ -export-syms $(SRC_PATH)/libcacard/libcacard.syms -libcacard.la: LIBS += $(libcacard_libs) +libcacard.la: LIBS = $(libcacard_libs) libcacard.la: $(libcacard-lobj-y) $(call LINK,$^) Christophe pgp3mWkICkw_6.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Software Management call for RFEs
Hey, On Wed, May 22, 2013 at 05:08:33PM -0400, Rahul Sundaram wrote: On Wed, May 22, 2013 at 9:43 AM, Jan Zelený wrote: We acknowledge the need for some changes in Software Management stack in Fedora but we don't want to make changes just by guessing what our users want. Therefore I call to you, consumers of our products (dnf, yum and rpm): what are the changes that you would like to see in the foreseeable future (say 2-3 years) and why would you like to see them (what would they help you with)? Thanks for taking on this effort. What I would like to see is solid git integration. Git has become the standard distributed vcs and github and google code etc have stopped hosting tarballs and/or discouraging it and GNOME is planning to do that as well. If Source URL could point directly to a git url with a hash or git tag, we would benefit. I'd add to that an optional GPG key to check the git tag against. Christophe pgpsvySRo_dBL.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Windows Spice/Virtio KVM drivers and tools (was Re: Red Hat QXL GPU Driver for Windows 7?)
On Thu, Jan 24, 2013 at 12:25:19PM +0100, Simone Caronni wrote: For this use case, all they need to do is to grab the spice-guest-tools installer and run that, the mess you describe is the exact reason why I'm building this installer. The installer works good and is a very nice addition, but the QXL drivers do not work, as it's not signed. I'm not sure how to test whether it's signed or not, but I just tested that the driver works in a winxp 32 bit install. That's exactly the problem, XP allows unsigned drivers; windows 7 doesn't. Win7 32 bit does allow unsigned (by MS/WHQL) drivers, Win7 64 bit does not. I've tested the latest qxl driver on a Win7 32 bit installation and it installed properly, so I don't know what problem you are trying to point at, I don't see any different behaviour between the qxl driver and the virtio ones. Anyway the problem leads back to the QXL drivers; if the latest QXL drivers were signed and parked at spice-space.org it would not be a big deal even if not included in the iso; but unfortunately they are not. Please be more specific about the signature issue you keep mentioning, I haven't been able to reproduce any different behaviour between the qxl driver and the virtio drivers from alt.fedoraproject.org. Christophe pgp5ggitN1gGz.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fwd: [Fedora-packaging] Orphaning my packages]
Hey, On Sun, Jan 27, 2013 at 06:32:39PM +0100, Dan Horák wrote: Přeposlaná zpráva Od: Mario Blättermann mario.blaetterm...@gmail.com Reply-to: Discussion of RPM packaging standards and practices for Fedora packag...@lists.fedoraproject.org Komu: packag...@lists.fedoraproject.org Předmět: [Fedora-packaging] Orphaning my packages Datum: Sun, 27 Jan 2013 18:15:55 +0100 due to lack of time I will orphaning all my packages. Most of them I haven't used for a while anyway. Here's a full list: frogr -- Flickr Remote Organizer for GNOME I've taken frogr. Christophe pgpiAPo5iinJt.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: First-Class Cloud Images
On Thu, Jan 24, 2013 at 11:19:16AM -0500, Bill Nottingham wrote: Matthew Miller (mat...@fedoraproject.org) said: On Wed, Jan 23, 2013 at 04:38:13PM -0500, Bill Nottingham wrote: == Detailed description == * New images that can be used in other cloud deployments (such as OpenStack, CloudStack, or Eucalyptus) will be produced. They will be in a qcow2 format and lack the EC2-specific customization. Images for this feature would ideally work for all cloud deployments and there will be i686 and x86_64 versions of both image types. In total and image drop will have 4 images: 2 arches for 2 different types (EC2, not-EC2). Will these images also be usable directly as virt image templates in local virtualization tools such as virt-manager Boxes? Yes. They have cloud-init enabled, which will look for a metadata service and (probably) not find one and then eventually time out and get you to a login prompt. To avoid that, you can boot with ds=nocloud' (Apparently there's a RHEVm and vSphere datasource too but I haven't tested that.) Have the boxes and libvirt people investigated writing a minimal cloud-init compatibile data-source? First time I hear of cloud-init, so as far as I know no one looked into Boxes integration (though this could be nice). Christophe pgppi2PG_Jcyx.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Windows Spice/Virtio KVM drivers and tools (was Re: Red Hat QXL GPU Driver for Windows 7?)
On Wed, Jan 23, 2013 at 05:18:10PM +0100, Simone Caronni wrote: On 23 January 2013 16:11, Christophe Fergeau cferg...@redhat.com wrote: 1) Recent version from Fedora in iso format - No WHQL, no changelog, no QXL drivers, no Spice Agent available, no source Err, there are sources, see http://secondary.fedoraproject.org/pub/alt/virtio-win/latest/images/src/ Well, here are the code drops every once in a while, no git repository or any way to see what's cooking or the status of things. http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers My understanding is that they are based on the git repo linked there if this is the information you want. For this use case, all they need to do is to grab the spice-guest-tools installer and run that, the mess you describe is the exact reason why I'm building this installer. The installer works good and is a very nice addition, but the QXL drivers do not work, as it's not signed. I'm not sure how to test whether it's signed or not, but I just tested that the driver works in a winxp 32 bit install. To summarize, what would be nice to have is the addition of recently built Spice Agents and signed QXL drivers in the Fedora iso. I'm not sure qxl + spice agent really belongs in the virtio-win ISO on alt.fedoraproject.org, as these virtio drivers can be useful to people not using SPICE at all. However, if you are willing to build such an ISO from the bits and pieces from this virtio-win ISO and from spice-space.org, it would make sense to provide it alongside the spice-guest-tools installer on spice-space.org. Christophe pgpGgY2uxC7Pi.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Windows Spice/Virtio KVM drivers and tools (was Re: Red Hat QXL GPU Driver for Windows 7?)
On Sat, Jan 12, 2013 at 07:59:24PM +0100, Erik van Pienbroek wrote: Richard W.M. Jones schreef op za 12-01-2013 om 01:24 [+]: Do the virtio drivers now build using the mingw-* stack in Fedora? IIRC this should be possible now that Fedora has switched over to using mingw-w64. The git repo for the virtio drivers only contains msvc project files, so in order to get the virtio drivers built using the mingw-w64 cross-compiler would require new Makefile's to be written. The mingw-w64 compiler which is currently in Fedora should be capable of building virtio as the DDK pieces are also bundled (in the folder /usr/i686-w64-mingw32/sys-root/mingw/include/ddk). I just took a quick attempt to manually compile these drivers using the mingw-w64 compiler in Fedora and I think it should be possible. Do you happen to have a log of these attempts? You just quickly passed the driver C files to mingw-gcc, or did you do something more sophisticated? Thanks, Christophe pgpiezUFr_t6r.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Windows Spice/Virtio KVM drivers and tools (was Re: Red Hat QXL GPU Driver for Windows 7?)
On Wed, Jan 09, 2013 at 04:39:06PM +0100, Simone Caronni wrote: Spinning of from this, I think there is some mess around the Virtio drivers; I would be glad if someone could explain that to me. Sorry for the length of this mail but I could not shorten it. Let's say I would like to grab the latest virtio drivers and tools for my Windows guest and the accompanying source code; this is what I found: 1) Recent version from Fedora in iso format - No WHQL, no changelog, no QXL drivers, no Spice Agent available, no source Err, there are sources, see http://secondary.fedoraproject.org/pub/alt/virtio-win/latest/images/src/ 3) Official Spice Agent (very old and buggy): http://spice-space.org/download/binaries/vdagent-win32_2024.zip 4) Spice Guest Tools setup - Unofficial Spice Agent, built from the latest sources using the mingw based package: I'd tend to consider this agent as an official build, though it probably needs to be put in a zip file next to the older build. == So far, my best setup is to recreate an iso everytime there is an update to the following: - Latest Fedora drivers for Windows XP, 2003 - Latest QXL binary from the Spice Guest Tools for Windows XP - Latest signed RHEL drivers for Windows Vista and up - Latest signed QXL driver for Windows Vista and up - Latest Spice Agent binary from the Spice Guest Tools I would say this is suboptimal, especially when I try to explain someone moving from Windows that si trying to virtualize Windows on their newly converted laptop. At the best case, they don't have the QXL driver, causing lag in the desktop, no Spice Agent for cutpaste and usually a lot of problems with Windows 7. For this use case, all they need to do is to grab the spice-guest-tools installer and run that, the mess you describe is the exact reason why I'm building this installer. - Have Fedora build the latest Virtio drivers (this is already done) - Build also the Spice Agent for 32/64 bit (this is done at spice-space.orgas part of the Spice Guest Tools) - Build the latest QXL drivers for all the Windows targets supported by the Virtio drivers (I know the Windows 8 XWDM driver will come eventually later) - Sign everything with the Redhat key, as it's doing for the drivers at point 2. Hmm I thought each binary driver release was signed with the Red Hat key (but not WHQL'ed), maybe I missed something... - Pack everything into an iso. Is that better than having an installer for everything (aka spice-guest-tools)? Christophe pgpl7_cQqfSio.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Windows Spice/Virtio KVM drivers and tools (was Re: Red Hat QXL GPU Driver for Windows 7?)
On Thu, Jan 10, 2013 at 09:11:45AM +, Tom Hughes wrote: On 09/01/13 17:33, Tom Hughes wrote: On 09/01/13 15:39, Simone Caronni wrote: - Build also the Spice Agent for 32/64 bit (this is done at spice-space.org http://spice-space.org as part of the Spice Guest Tools) Actually that's 32 bit only. I've never found a spice agent for 64 bit versions of Windows anywhere. It turns out that I skim read the error a bit too much, and it is actually specifically XP64 that it refuses to install on rather than 64 bit Windows in general. Yes, iirc we don't have virtio/qxl 64 bit builds. The agent can be built on 64 bit. Christophe pgpUjNsEXM_8j.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass rebuild for Fedora 18 Complete
Hey, On Sun, Jul 22, 2012 at 02:21:10PM -0600, Kevin Fenzi wrote: The mass rebuild has completed and been tagged back into rawhide, they should appear in tomorrow's rawhide compose. 11057 packages were successfully rebuilt. 656 packages failed to rebuild. Please fix any packages you maintain that failed to rebuild. GNOME Boxes failed to build because of libvirt-client is a BuildRequires, and this package cannot be installed because of recent netcat changes in rawhide. Should we work on getting a working GNOME Boxes rebuild as soon as possible, or can it wait until the next release (which is due in a few weeks)? Christophe pgpkgk5W6Wr6z.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: nc replaced by nmap ncat
Hey, On Mon, Jul 23, 2012 at 04:03:00PM +0200, Petr Šabata wrote: On Fri, Jul 20, 2012 at 11:07:30AM -0400, Przemek Klosowski wrote: On 07/19/2012 05:46 PM, Richard W.M. Jones wrote: When a libvirt client connects to a remote machine, the libvirt client sends the nc -U ... command over ssh. So every libvirt on any distro that might connect to a Rawhide libvirtd must be changed to send a socat ... command instead. Alternatively, perhaps a compatibility script called 'nc' could execute the appropriate socat command? That sounds like an acceptable temporary solution until ncat supports UNIX sockets too. For what it's worth, I think this change broke GNOME Boxes build: http://kojipkgs.fedoraproject.org//work/tasks/36/4270036/root.log DEBUG util.py:257: Error: Package: libvirt-client-0.9.13-1.fc18.i686 (build) DEBUG util.py:257: Requires: nc and I indeed get: $ repoquery --releasever=rawhide --whatprovides nc No package provides nc libvirt.spec has: %package client # So remote clients can access libvirt over SSH tunnel # (client invokes 'nc' against the UNIX socket on the server) Requires: nc Christophe pgpkwUD78oTIP.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 3.3.1-5.fc17.x86_64.debug power management and overheating issue
On Mon, Apr 16, 2012 at 08:41:44PM -0400, Paul Wouters wrote: Also, when i close the lid, the suspension icon keeps blinking and the laptop does not actualy suspend. I'm seeing this, luckily I haven't hit your overheating issues :) About to try 3.3.2-1 to see if this helps. Christophe pgptE1cdveFti.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: ImageMagick - [Fedora Update] [comment] xine-lib-1.1.20.1-3.fc17, emacs-24.0.94-3.fc17, calibre-0.8.42-1.fc17, perl-GD-SecurityImage-1.71-3.fc17, techne-0.2.1-4.fc17, gdl-0.9.2-5.fc17, autot
On Fri, Apr 06, 2012 at 07:27:31AM -0600, Orion Poplawski wrote: Suggestions? I'm tempted to pushed this to stable so that broken deps emails start going out to get people to do the needed rebuilds. Or perhaps someone in releng can for the needed buildroot overrides? Or perhaps we drop the whole endeavor? I'd lean towards this, why do we need to push a soname bump of ImageMagick so late in the game when f17 is already in beta? If there's a critical bug in the f17 package, isn't it possible to backport the fix instead of forcing these rebuilds? Christophe pgpU1wBHGKU8o.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: JPEG_LIB_VERSION in libjpeg-turbo
On Sat, Feb 18, 2012 at 09:46:56PM +0100, Julian Sikorski wrote: Dear fellow Fedora packagers I was trying to get MAME [1] to use system libjpeg [2]. The problem is that MAME needs jpeg_mem_src, which is only defined if libjpeg-turbo compiled with --with-jpeg8 switch, which is not the case for the Fedora package. Would such change be feasible to introduce? If not, I assume that I have no other choice as to use the bundled copy (not really relevant here since MAME is an RPM Fusion package). You can specify your own data sources with the libjpeg shipped with fedora (jped_decompress_struct::src). What is missing is a default implementation for a source reading from memory. libjpeg8 ships one by default, but older libjpeg don't have it. However, the mem source should only be a few functions, so you can probably only bundle a copy of jpeg_mem_src in your package and use the system libjpeg. I did something very similar in spice, but it was for jpeg_mem_dest, not jpeg_mem_src (ie similar functionality, but for compression instead of decompression), see http://cgit.freedesktop.org/spice/spice/tree/server/mjpeg_encoder.c#n95 Hope that helps, Christophe pgp8CiLPIuhA2.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging guidelines for packaging vala bindings
On Tue, Jan 17, 2012 at 02:25:08PM +0100, Pierre-Yves Chibon wrote: On Tue, 2012-01-17 at 14:16 +0100, Ralf Corsepius wrote: users who have no use for vala. Are users having no use of vala really installing -devel packages or vala program ? spice-gtk is a C library shipping C headers as well as vala-specific vapi files (and also python bindings). So .vapi files don't necessarily come from vala programs, they can come with bindings of libraries written in other languages. Christophe pgpGkdk5FRHhw.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging guidelines for packaging vala bindings
On Tue, Jan 17, 2012 at 04:55:10PM +0100, Marc-André Lureau wrote: On Tue, Jan 17, 2012 at 4:22 PM, Richard W.M. Jones rjo...@redhat.com wrote: More to the point, presumably if the vala files were included in *-devel, they'd also cause an explicit or implicit dependency on vala-devel, which would mean the vala toolchain being pulled in for many packages, and that's totally unacceptable. But we don't care having implictexplicit depedency on a browser or python. By that reasoning, shouldn't we also fold python bindings in the -devel package? They are small, python is already implicitly installed, so this should be fine too. (NB: I'm just being the devil's advocate here, I'm in favour of separate subpackages for each language binding) Christophe pgpJMK531baUn.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick
On Mon, Jul 04, 2011 at 03:25:41PM +0400, Pavel Alexeev (aka Pahan-Hubbitus) wrote: Sorry, but it is postponed [1] probably due to the bug in gcc [2] [1] https://bugzilla.redhat.com/show_bug.cgi?id=715834 [2] https://bugzilla.redhat.com/show_bug.cgi?id=715336 The latter is assigned to gcalctool, this does not look like the right component ;) Christophe pgpQVbVUEpTut.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3 Fallback Mode
On Wed, Apr 27, 2011 at 12:35:11PM +0200, drago01 wrote: Not yet ... the VM has to provide proper 3D acceleration for it to work. Ajax has been working on making it run on software rendering, once his work is finished it should be able to run in VMs. For what it's worth, 3D support is a planned feature of spice: http://spice-space.org/page/Features/Spice3D Hopefully it will get it soon :) Christophe pgp1niSHjhtfZ.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
