Unretire golly
Hello, According to https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/ I'd like to announce that I'm going to unretire the package "golly". It was retired because it was FTBFS for too long: https://bugzilla.redhat.com/show_bug.cgi?id=1675048 Probably because upstream did not migrate to Python 3 until 2020. Right now, upstream is active. Re-Review: https://bugzilla.redhat.com/show_bug.cgi?id=2237768 Best regards, Christian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Intent to orphan vpnc
Hello, vpnc is a VPN client which can be used with certain VPN devices: https://www.unix-ag.uni-kl.de/~massar/vpnc/ The last co-maintainer who actively maintained the package for the last few years just stepped back. Since I don't have a use case for it anymore (and no ability for testing), I'm going to orphan it in the next few days. The only package which depends on vpnc is NetworkManager-vpnc. There is no active upstream for vpnc. However, according to the bug reports for NetworkManager-vpnc, there might be still a few users. Best regards, Christian References: https://src.fedoraproject.org/rpms/vpnc https://src.fedoraproject.org/rpms/NetworkManager-vpnc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Unretire lua-ldap
Hello, According to https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/ I'd like to announce that I'm going to unretire the package "lua-ldap". I didn't find a concrete reason why it was removed, it looks like it was retired because it was orphaned for too long. Specifically, I'd like to use it to re-enable LDAP support in the XMPP server "prosody" with its "mod_auth_ldap" plugin. I'm planning to update/maintain it also in EPEL. Upstream moved to here: https://github.com/lualdap/lualdap/commits/master and it looks like they are medium active, last commit this March 2023. Re-Review: https://bugzilla.redhat.com/show_bug.cgi?id=2217273 Best regards, Christian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
License update: scummvm and scummvm-tools
Hello, beginning with scummvm version 2.6.0, the license for the packages scummvm and scummvm-tools have been changed as follows: scummvm: "GPLv3+ and LGPLv2+ and BSD and OFL and MIT and ISC" scummvm-tools: "GPLv3+ and LGPLv2+ and MIT" Best regards, Christian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
License update: svummvm-tools
Hello, beginning with version 2.5.0, the license for the package scummvm-tools has been changed to "GPLv2+ and LGPLv2+ and MIT" Best regards, Christian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
License update: scummvm
Hello, beginning with version 2.5.0, the license for the package scummvm has been changed to "GPLv2+ and LGPLv2+ and GPLv3+ and BSD and OFL and MIT and ISC" Best regards, Christian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
License update: scummvm
As discussed on the Fedora Legal mailing list, I updated the license tag of scummvm from "GPLv2+" to "GPLv2+ and LGPLv2.1+ and GPLv3+ and BSD and OFL". GPLv3 and OFL are only used for font files. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaned package "solfege"
Hi, I have orphaned the package "solfege" (a small music education tool to learn to hear intervals, rhythms, ...). It does not build anymore [1] and there is no upstream activity since a few years. Last stable version (3.22.2) is from 2013 [2] Last unstable version (3.23.4) is from 2016 [3] Last git commit corresponds with the 3.23.4 release [4] For python3, version 3.23.4 would be required. However, even this version does not compile since autoconf does not use pkg-config for Python.h and so the path used in recent Fedora releases (e.g. /usr/include/python3.7m) is not found. Personally I would retire it from Fedora, but I orphaned it first just in case someone wants to pick it up. If not, it will get automatically retired due to the open FTBFS bug. Best regards, Christian [1] https://bugzilla.redhat.com/show_bug.cgi?id=1639699 [2] http://ftp.gnu.org/gnu/solfege/ [3] https://sourceforge.net/projects/solfege/files/solfege-unstable/ [4] http://git.savannah.gnu.org/cgit/solfege.git ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] python-matplotlib-2.0.0 major update
Hi, On Thu, Sep 22, 2016 at 3:41 PM, Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > > I've just pushed (but not built) python-matplotlib-2.0.0b4 to rawhide. > I'll be attempting to rebuild all the affected packages locally to > test if they're compatible. In the meantime, feel free to git pull > and build locally for your own testing. > > $ dnf repoquery --srpm --releasever=rawhide --whatrequires > python-matplotlib --alldeps > > anki > Thanks for the heads-up. I just tested anki against python-matplotlib-2.0.0b4: works fine, I haven't seen any issues. There is no need to rebuild anki since it doesn't have a "BuildRequires:" for python-matplotlib. The dependency is just caused by a "Requires:". Best regards, Christian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Un-retiring ice and mumble?
Hi Carlos, On Tue, Jan 13, 2015 at 2:41 AM, Carlos O'Donell car...@redhat.com wrote: I would like to un-retire mumble, but that requires ice. I've just fixed ice to compile on f21 without much effort. So I think I'll un-retire ice and mumble and maintain them unless anyone objects. Is there any reason ice was orphaned and retired other than lack of interest? No, not that I'm aware of. Mumble got retired mainly because ice got retired. I'd be happy to help with the package review for mumble to get it back into Fedora. Best regards, Christian -- 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: downgrade version of gthumb in fedora 21 final?
Hi, On Fri, Nov 7, 2014 at 1:31 AM, Michael Catanzaro mcatanz...@gnome.org wrote: On Thu, 2014-11-06 at 13:13 -0800, James Patterson wrote: Is it too late to downgrade gthumb in Fedora 21 to 3.2.x? The version in Fedora is really slow. I posted a bug with more info: https://bugzilla.redhat.com/show_bug.cgi?id=1161052 I agree that should be downgraded in F21 and possibly in rawhide as well. Since gthumb does not follow the GNOME release schedule, we shouldn't push unstable versions of gthumb to rawhide. I suspect it's being picked up by mclazy I fully agree. I'll double-check, that the problem is caused by the unstable version of gthumb (and not some other updated library in F21). I guess it was updated in the hope that the next stable version will be released before F21. If appropriate, I'll downgrade gthumb. Best regards, Christian -- 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: unresponsive maintainer: chkr
Hi Nikos, I'm sorry that I haven't responded earlier. I was under the impression that your request only affected EPEL and that you have contacted the EPEL maintainer now. I just re-read the conversation - it looks like that I have overseen that the request was indeed for the fedora branches (at least -devel), too. Let's discuss how to proceed with the necessary changes in the mentioned bug report. Thanks for offering the help to split the package! Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Unretiring gpx-viewer / Review Swap
Hi, according to http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers I'd like to announce that I want to unretire the package gpx-viewer. The package was retired because it didn't build for multiple Fedora releases: https://pkgs.fedoraproject.org/cgit/gpx-viewer.git/tree/dead.package Upstream is not very active, but there are still occasional bug fixes committed: https://launchpad.net/gpx-viewer gpx-viewer has one advantage over the full-featured tools like josm or merkaartor: it can display a GPX track using OpenStreet maps without any setup or configuration. The required review request can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=1008701 If someone would like to swap a review, I'd be happy to help, too! Best regards, Christian -- 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: [ACTION REQUIRED] Retiring packages for Fedora 19
Hi, On 02/24/2013 11:19 AM, Bill Nottingham wrote: Package celt071 (orphan) I picked up celt071 (used by mumble). Package dbus-sharp (orphan) comaintained by: chkr I took dbus-sharp, too. Regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review Swap
Hi, I'd like to offer a review swap: https://bugzilla.redhat.com/show_bug.cgi?id=765625 python-pymodbus - A Modbus Protocol Stack in Python It is a simple python package, so it should be quite an easy review. ;-) Thanks! Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cisco vpn because of ipsec over tcp
Hi, Fedora ships the open source vpnc client which supports the Cisco VPN environment. I'm using it daily and it works for me without any problems. There is also a proprietary client from Cisco: http://www.cisco.com/en/US/products/sw/secursw/ps2308/index.html . On 11/14/2011 06:34 PM, Tomasz Torcz wrote: On Mon, Nov 14, 2011 at 09:08:05PM +0400, Lucas wrote: I am talking about ipsec over TCP. Everything can do ipsec over UDP, but none over TCP. But on my job for the security reason UDP is blocked, cisco vpn can do ipsec over tcp. It seems you have your layering wrong. IPSec operates on IP protocol, below UDP and TCP. Only IKE, the key exchange, protocol works on UDP. Maybe you thought about different technology? For VPN, OpenVPN provided in Fedora support TCP transport. To clarify the misunderstanding: Cisco's VPN concentrator provides the feature IPSec over TCP. Unfortunately, vpnc does not support it: man 8 vpnc: [...] --natt-mode natt/none/force-natt/cisco-udp Which NAT-Traversal Method to use: · natt -- NAT-T as defined in RFC3947 · none -- disable use of any NAT-T method · force-natt -- always use NAT-T encapsulation even without presence of a NAT device (useful if the OS captures all ESP traffic) · cisco-udp -- Cisco proprietary UDP encapsulation, com‐ monly over Port 1 Note: cisco-tcp encapsulation is not yet supported Default: natt conf-variable: NAT Traversal Mode natt/none/force-natt/cisco-udp [...] So it looks like that for your use case (connecting to a Cisco VPN using IPSec over TCP) you have to use Cisco's proprietary client. Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Build failure if STABS debug symbols are found
Hi, during the build of the new scummvm release we run into the following build issue: https://koji.fedoraproject.org/koji/getfile?taskID=3507060name=build.log + /usr/lib/rpm/find-debuginfo.sh --strict-build-id /builddir/build/BUILD/scummvm-1.4.0 extracting debug info from /builddir/build/BUILDROOT/scummvm-1.4.0-1.fc16.i386/usr/bin/scummvm Stabs debuginfo not supported: /builddir/build/BUILDROOT/scummvm-1.4.0-1.fc16.i386/usr/bin/scummvm error: Bad exit status from /var/tmp/rpm-tmp.wtAmWB (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.wtAmWB (%install) Child returncode was: 1 EXCEPTION: Command failed. See logs for output. It looks like that the compiled binary contains STABS debug symbols. I have investigated this problem and indeed the nasm assembler will generate by default STABS instead of DWARF debug symbols. According to https://bugzilla.redhat.com/show_bug.cgi?id=725378#c16 rpmbuild has now the following behavior: F17: rpmbuild will issue a warning but not fail the build F15, F16: rpmbuild will fail the build once it detects STABS debug symbols in the binaries I'm wondering what would be the best solution here: a) apply a patch to the package to let nasm generate DWARF debug symbols (and probably propose this patch upstream) b) change the behavior of rpmbuild in F15 and F16 to not treat these errors as fatal c) file a bug against nasm to change the default debug symbol format to DWARF in case of compiling for the ELF target Probably it would even make sense to do all 3 of them. Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gnome-python2-gtkhtml2 and gnome-python2-gtkmozembed removed
Hi, On 09/09/2011 06:40 PM, Kalev Lember wrote: In order to make gnome-python2-extras build in F16+ and to clean up its broken deps, I had to kill two of its subpackages. - gnome-python2-gtkhtml2: needs gtkhtml2 to build, which is already retired in F16+. - gnome-python2-gtkmozembed: needs xulrunner's gtkmozembed support which is disabled in F16+. This will flag up the following packages in the Branched / rawhide broken dep reports (they were broken before, just now showing up): $ repoquery -q --whatrequires gnome-python2-gtkhtml2 [...] solfege-0:3.20.1-1.fc16.x86_64 Thanks for the heads up. I have removed the superfluous requires for gnome-python2-gtkhtml2 in solfege and built/pushed out new packages for rawhide and F16. It looks like that upstream dropped the support for gtkhtml2 a while ago... Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaned: vpnc
Hi David, On 08/31/2011 09:37 AM, Woodhouse, David wrote: On Wed, 2011-08-31 at 02:42 +0200, Christian Krause wrote: I have looked at the list of open bugs for vpnc and it looks like that there are a couple of packaging issues, some problems with the vpnc-script and some other issues which may require some upstream help. Are there any problems with vpnc-script that *aren't* fixed by simply updating to the one in http://git.infradead.org/users/dwmw2/vpnc-scripts.git ? I have looked at the git repository and I'm unsure about one change: The commit: http://git.infradead.org/users/dwmw2/vpnc-scripts.git/commitdiff/ea98b094e8f75fcd696db81bc6c5160dc67b4e4f seems to fix https://bugzilla.redhat.com/show_bug.cgi?id=693235 (negative MTU) in case ip route ... does not report the mtu. However, at least on my systems, ip route ... does never return the mtu in its output and so the script will always use the hard-coded fallback value 1412 as MTU. The proposed patch attached to the bug report ( https://bugzilla.redhat.com/attachment.cgi?id=515615 ) uses a different approach: It extracts the actual interface via ip route and retrieves the MTU via ip link show $interface. What do you think about this patch? Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaned: vpnc
Hi, On 08/30/2011 01:42 PM, Richard W.M. Jones wrote: Although I use vpnc daily, I only need/use the old version in RHEL 5, and I don't have a machine on which I can conveniently study Fedora bug reports. Therefore I have released ownership of this package in Fedora 14-17. Since I have vpnc in nearly daily use on various Fedora installations, I'll help out here. Judging by the volume of bug reports, this is a widely used VPN package. Upstream comes and goes. The latest upstream is probably: http://www.unix-ag.uni-kl.de/~massar/vpnc/ and the version in svn (not in a released tarball) is relatively recent. I have looked at the list of open bugs for vpnc and it looks like that there are a couple of packaging issues, some problems with the vpnc-script and some other issues which may require some upstream help. CC'd to tmraz: As I was orphaning the package, I noticed that you had requested commit access. I'm not sure why I didn't see any email about that, or perhaps I did get email but I overlooked it. In any case, I have granted this now. Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Deprecating podsleuth and ipod-sharp in rawhide
Hi, I'm going to deprecate podsleuth and ipod-sharp in rawhide. Banshee has switched to libgpod(-sharp) and no other package depends on these two packages. Are there any objections? Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages that will be orphaned
Hi, On 06/20/2011 07:34 PM, Toshio Kuratomi wrote: Please reply to this thread if you'd like to take any packages or ping me on IRC and I'll reply to this thread with what packages have been taken. (Needed since we aren't orphaning in the pkgdb until Thursday so you need a cvsadmin to reassign ownership for now). I'll take care of the following packages - I already co-maintain nearly all of them: boo gtksourceview2-sharp gtksourceview-sharp mod_mono mono-addins mono-basic mono-debugger monodevelop monodevelop-boo monodevelop-debugger-gdb monodevelop-debugger-mdb monodevelop-vala mono-tools mono-zeroconf nant xsp Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Thunderbird updates mixed up in F14
On 05/01/2011 10:38 PM, Kevin Kofler wrote: Michael Schwendt wrote: Rather find and fix the bug that is the cause of this. There have been a few updates like that recently, again. The 3.1.10-1.fc14 package is tagged dist-f14-updates already: http://koji.fedoraproject.org/koji/buildinfo?buildID=241265 So, during the compose of the updates repo it should be pulled in. The problem there is Koji's broken idea of newest. For Koji, the newest package is the latest one which was tagged, not the highest EVR. (In fact, Koji doesn't process Epoch at all, so it can't even compare EVRs.) Unfortunately, the Koji developers refuse to acknowledge that this is even a bug, and have no plans to fix it ever. Fixing it would mean 1. telling Koji about Epoch and 2. using EVR comparisons instead of tagging dates to decide on the latest version. What do you suggest? Should we just create a rel-eng ticket for fixing koji with respect to the sorting algorithm? To fix this particular instance of the problem, rel-eng needs to untag the obsolete 3.1.9 build so the 3.1.10 one becomes the newest also for Koji. Since the update to 3.1.10 is marked as a security update I suggest that for now we should just use the approach of untagging 3.1.9. I have created: https://fedorahosted.org/rel-eng/ticket/4690 Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Thunderbird updates mixed up in F14
Hi, Beginning of today package-cleanup --orphans reports thunderbird-3.1.10-1.fc14.i686 as orphan in F14. yum clean all; yum list thunderbird reports thunderbird-3.1.9-2.fc14 as newest thunderbird package in the repositories. However, at one point in time thunderbird-3.1.10-1.fc14.i686 must have been available in the repos, too (I don't have updates-testing enabled.). It looks like that the following happened: There were two updates in bodhi: 1. https://admin.fedoraproject.org/updates/firefox-3.6.17-1.fc14,mozvoikko-1.0-21.fc14.1,gnome-web-photo-0.9-20.fc14.1,perl-Gtk2-MozEmbed-0.08-6.fc14.26,gnome-python2-extras-2.25.3-30.fc14.1,galeon-2.0.7-40.fc14.1,thunderbird-3.1.10-1.fc14,xulrunner-1.9.2.17-2.fc14 which contains thunderbird 3.1.10-1 and which was pushed to stable on 2011-04-29 22:19:33. 2. https://admin.fedoraproject.org/updates/thunderbird-3.1.9-2.fc14,thunderbird-lightning-1.0-0.41.b3pre.fc14 which contains thunderbird 3.1.9-2 (and thunderbird-lightning) and which was pushed to stable on 2011-04-30 23:21:39. So the 2nd update has superseded the first update to thunderbird 3.1.10. For all who have updated to thunderbird 3.1.10 during the small time window when it was available in the mirrors, the thunderbird package is now an orphan on their systems. Please can the maintainers of thunderbird push thunderbird 3.1.10 again? Thanks! Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gtkhtml-sharp (gnome-desktop-sharp)
Hi, On 03/09/2011 11:58 PM, Paul Johnson wrote: Currently, this is disabled in rawhide as it is linking to the gtkhtml3 API. Does anyone know if this ban has been lifted yet or is the mono stack going to be hobbled because of it for a while longer? (no gnome-desktop-sharp == no mono-tools == no monodevelop and so on...) The latest information I have is from the bug report where I was told that nobody should use the gtkhtml3 API: https://bugzilla.redhat.com/show_bug.cgi?id=660867#c9: - Matthew Barnes 2010-12-19 15:27:29 EST Absolutely nothing but Evolution should be linking to gtkhtml3 at this point, not even language bindings. The package will likely be orphaned upstream within the next year. I'd recommend building with --disable-gtkhtml. - However, are you sure that mono-tools can't be built without gtkhtml? IMHO e.g. monodoc can use other html renderers like webkit. In general I'm really curios how we handle the following situation: It is not allowed to link against gtk2 and gtk3 at the same time (directly or indirectly) but since 1) IMHO gtk-sharp is only available for gtk2 2) all native gnome libraries are compiled against gtk3 gnome-desktop-sharp will have trouble wrapping the native gnome libraries and so not onyl gtksharp is missing but also e.g. the wrapper for libgnomepanel. Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multilib issue with hard-coded paths in mash script
Hi, On 11/08/2010 11:15 PM, Matthias Clasen wrote: 1. Specifically with respect to the problem with gdk-pixbuf: Should the gdk-pixbuf loaders be multilib or not? If yes, the mash script must be adjusted. The loaders are shared objects, and the 64-bit modules won't help you on 32-bit, so yes, they need to be multilib. Thanks for the info - I've added all relevant information to the mentioned bug report [1] and moved it to the mash component. Best regards, Christian [1] https://bugzilla.redhat.com/show_bug.cgi?id=649339 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Multilib issue with hard-coded paths in mash script
Hi, During the F14 release cycle gtk2 was updated from 2.20.x to 2.22.x. During this change gdk-pixbuf2 was split off into a separate package and the location of the gdk-pixbuf loaders has changed from: F13: /usr/lib/gtk-2.0/2.10.0/loaders/ to F14: /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders This caused now some strange effects due to the hard-coded paths in the mash script for creating the x86_64 repository: From mash/mash/multilib.py: if fnmatch(dirname, '/usr/lib*/gtk-2.0/*/loaders'): return True So in F13 the mash script picked up all i686 packages which provided gdk-pixbuf loaders. In F14 the script does not pick them up anymore (because of the changed path) and so the i686 versions of some loaders are missing in the x86_64 repository. This has now caused e.g. the following bug https://bugzilla.redhat.com/show_bug.cgi?id=649339 . The whole issue raises now some questions: 1. Specifically with respect to the problem with gdk-pixbuf: Should the gdk-pixbuf loaders be multilib or not? If yes, the mash script must be adjusted. 2. Should the mash script be reviewed whether there are any other hard-coded paths outdated? Should the script even be Fedora release specific? Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any comments about the latest version of mono on my site?
Hi Paul, On 10/06/2010 04:26 PM, Paul F. Johnson wrote: A couple of days back I uploaded preview 8 of mono-2.8 for comments but have heard nothing back. The move to 2.8 will require a good number of rebuilds as 2.8 has had all the .NET 1.1 stuff removed. Do all mono packages have to be recompiled or only the ones which use .NET 1.1 stuff? Is there an easy way (besides recompiling against 2.8) to determine whether a package uses .NET 1.1? Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Upgrade Banshee to 1.8.0 in F13
Hi, On 10/11/2010 07:37 PM, Kevin Fenzi wrote: On Mon, 11 Oct 2010 12:20:54 -0400 Nathaniel McCallum nathan...@natemccallum.com wrote: I'd like to propose that we upgrade banshee (and banshee-community-extensions) to 1.8.0 in F13. I estimate that this will close about half our open bugs. Doing this will require the following package upgrades in F13: * clutter-sharp - Upgrade (I'm pretty sure Banshee is the only user) * gio-sharp - New * gudev-sharp - New * gkeyfile-sharp - New * gtk-sharp-beans - New * libgpod - Upgrade (0.7.93 0.7.95; bugfix release) The only thing complicated here is the buildroot override requirement and making sure that we ship the new banshee-community-extensions in the same update as the new banshee. Currently, I do not think it is feasible to backport this to F12, so F13 would be the latest version. Thoughts? Comments? Well, lets see: F13 currently has version 1.6.1 in it. Looks like they follow an 'odd is unstable/devel, even is release/stable' method. So, all the 1.7.x releases were development ones. Yes, that's correct. I see a lot of bugs fixed, but also a bunch of new features: http://banshee.fm/download/archives/1.8.0/ I see 9 open fedora bugs. Has the UI changed since 1.6.1? I would suspect so. Not very much, only very slightly. Would the libgpod update require rebuilding or changing anything else? How many other packages depend on that? No, the SONAME and so the API of libgpod hasn't changed. So, this seems to me to be something that would need more rationale/a stable updates exception. I agree that there may be subtle changes (GUI, behavior, new bugs, ...). However, as one of the maintainers of the banshee package in Fedora I would certainly like to update to 1.8.0 as well. I suggest the following: - importing the new pre-requisites into F13 is uncritical even right now - confirm with libgpod maintainers whether an update to 0.95 is acceptable, if yes, it can be done in the meantime as well - give banshee some time in F14 and get some feedback from users first (probably even wait until F14 is out - otherwise too less people will use it regularly) - try to fix any regressions (e.g. it looks like that for me at least the iPod (non-touch) support is broken) - if there is no critical feedback or the issues could be solved: do the update in F13 Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python 2.7 rebuild: maintainer help needed (please!)
On 07/23/2010 08:07 PM, David Malcolm wrote: I've been running mass rebuilds of python-using packages against python 2.7 [1] We're now down to 202 failing builds, so I'm attaching a by-maintainer report on them. chkr (1): anki Fixed built: https://koji.fedoraproject.org/koji/buildinfo?buildID=186359 Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up! Broken deps in Upgrade from 12 to 13
Hi, On 02/21/2010 02:15 AM, Michael Schwendt wrote: Upgrade from 12+updates to 13+updates+testing == [...] Broken packages in fedora-12-x86_64: monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Debugger) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.Core) = 0:2.1.0.0 monodevelop-debugger-mdb-2.1.0-1.fc12.i686 requires mono(MonoDevelop.AspNet) = 0:2.1.0.0 This may be caused by the fact that monodevelop-debugger-mdb used ExclusiveArch: %ix86 in F12 and ExclusiveArch: %ix86 x86_64 ia64 armv4l sparcv9 alpha s390 s390x in F13 and the devel branch. What would be the appropriate fix here? Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up! Broken deps in Upgrade from 12 to 13
Hi, On 02/21/2010 02:15 AM, Michael Schwendt wrote: Upgrade from 12+updates to 13+updates+testing == Broken packages in fedora-updates-12-i386: mono-moonlight-2.4.3.1-1.fc12.i686 requires mono-core = 0:2.4.3.1-1.fc12 == Broken packages in fedora-updates-12-x86_64: mono-moonlight-2.4.3.1-1.fc12.x86_64 requires mono-core = 0:2.4.3.1-1.fc12 Both problems should be fixed with https://admin.fedoraproject.org/updates/mono-2.6.1-2.fc13 Michael, where can I find the script you have used for generating the list of broken update paths? Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Sindre Pedersen Bjørdal is AWOL, 25 packa ges looking for new owners
Hi, On 02/03/2010 12:15 AM, Christoph Wickert wrote: * gnome-do -- Quick launch and search * notify-sharp -- A C# implementation for Desktop Notifications * solfege -- Music education software I have taken these. Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
