Obsoleted packages in repositories (was: grub (v1) in f18?)
On 12/07/2012 07:59 PM, Matthew Miller wrote: Are there other obsoleted packages in the F18 repo? Here's what I see on F18, it's quite a pile: 4ti2-1.3.2-12.fc18.x86_64 anyremote2html-1.4-4.fc18.noarch chktex-1.6.4-11.fc18.x86_64 classads-1.0.8-5.fc18.i686 classads-1.0.8-5.fc18.x86_64 classads-devel-1.0.8-5.fc18.i686 classads-devel-1.0.8-5.fc18.x86_64 classads-static-1.0.8-5.fc18.i686 classads-static-1.0.8-5.fc18.x86_64 cura-account-0.0.4-1.fc18.x86_64 cura-fan-0.0.4-1.fc18.x86_64 cura-networking-0.0.4-1.fc18.x86_64 cura-powermanagement-0.0.4-1.fc18.x86_64 cura-providers-0.0.4-1.fc18.i686 cura-providers-0.0.4-1.fc18.x86_64 cura-providers-devel-0.0.4-1.fc18.i686 cura-providers-devel-0.0.4-1.fc18.x86_64 cura-service-0.0.4-1.fc18.x86_64 cura-storage-0.3-1.fc18.noarch cura-tools-0.1-3.fc18.noarch django-keyedcache-1.4.1-4.fc18.noarch django-mako-0.1.4-0.5.pre.fc18.noarch django-pylibmc-0.2.1-4.20110806gitb56e74.fc18.noarch dvisvgm-1.0.12-2.fc18.x86_64 english-typing-booster-0.0.2-2.fc18.noarch fcitx-keyboard-0.1.3-1.fc18.x86_64 gpxe-bootimgs-1.0.1-7.fc18.noarch gpxe-roms-1.0.1-7.fc18.noarch gpxe-roms-qemu-1.0.1-7.fc18.noarch grc-0.70-9.fc18.noarch 1:grub-0.97-91.fc18.x86_64 gtksourceview2-sharp-1.0-10.svn89788.fc16.x86_64 gtksourceview2-sharp-devel-1.0-10.svn89788.fc16.i686 gtksourceview2-sharp-devel-1.0-10.svn89788.fc16.x86_64 ibus-european-table-1.1.6-2.fc18.noarch ibus-hunspell-table-0.0.8-2.fc18.noarch ibus-indic-table-1.3.1-23.fc17.noarch ibus-table-array30-1.2.0.20090729-4.fc18.noarch jadetex-3.13-12.fc18.noarch jaffl-0.5.9-1.fc16.noarch jaxen-bootstrap-1.1-6.2.fc18.noarch kdirstat-2.5.3-13.fc18.x86_64 latexmk-4.35-1.fc18.noarch libgssapi-0.11-11.fc18.i686 libgssapi-0.11-11.fc18.x86_64 libgssapi-devel-0.11-11.fc18.i686 libgssapi-devel-0.11-11.fc18.x86_64 lzma-4.32.7-8.fc18.x86_64 manaworld-0.5.2-9.fc18.x86_64 manaworld-music-0.3-3.fc18.noarch maven-shared-artifact-resolver-1.1-24.fc18.noarch maven-shared-common-artifact-filters-1.3-24.fc18.noarch maven-shared-dependency-tree-1.3-24.fc18.noarch module-init-tools-3.16-6.fc18.x86_64 netxen-firmware-4.0.534-6.fc18.noarch nfs-utils-lib-1.1.5-7.fc18.i686 nfs-utils-lib-1.1.5-7.fc18.x86_64 nss_ldap-265-10.fc17.i686 nss_ldap-265-10.fc17.x86_64 pam_passwdqc-1.0.5-10.fc18.i686 pam_passwdqc-1.0.5-10.fc18.x86_64 pdfjam-2.08-4.fc18.noarch pexpect-2.3-8.fc18.noarch ps2eps-1.68-4.fc18.x86_64 pymongo-2.1.1-2.fc18.x86_64 pymongo-gridfs-2.1.1-2.fc18.x86_64 python-cryptsetup-0.1.4-4.fc18.x86_64 ql2100-firmware-1.19.38-6.fc18.noarch ql2200-firmware-2.02.08-6.fc18.noarch ql23xx-firmware-3.03.28-4.fc18.noarch qxmpp-dev-0.6.3.1-1.fc18.i686 qxmpp-dev-0.6.3.1-1.fc18.x86_64 qxmpp-dev-devel-0.6.3.1-1.fc18.i686 qxmpp-dev-devel-0.6.3.1-1.fc18.x86_64 rt61pci-firmware-1.2-10.fc18.noarch rt73usb-firmware-1.8-10.fc18.noarch ruby-goocanvas-0.90.4-1.9.fc18.1.x86_64 ruby-goocanvas-devel-0.90.4-1.9.fc18.1.i686 ruby-goocanvas-devel-0.90.4-1.9.fc18.1.x86_64 ruby-gstreamer-0.90.4-1.9.fc18.1.x86_64 ruby-gstreamer-devel-0.90.4-1.9.fc18.1.i686 ruby-gstreamer-devel-0.90.4-1.9.fc18.1.x86_64 ruby-gtksourceview2-0.90.4-1.9.fc18.1.x86_64 ruby-gtksourceview2-devel-0.90.4-1.9.fc18.1.i686 ruby-gtksourceview2-devel-0.90.4-1.9.fc18.1.x86_64 seahorse-plugins-2.91.6-0.5.git1e35fd9.fc18.x86_64 sshfp-1.2.2-4.fc18.noarch tetex-IEEEtran-1.7.1-6.fc18.noarch texlive-texmf-2007-42.fc18.noarch texlive-texmf-afm-2007-42.fc18.noarch texlive-texmf-context-2007-42.fc18.noarch texlive-texmf-doc-2007-42.fc18.noarch texlive-texmf-dvips-2007-42.fc18.noarch texlive-texmf-east-asian-2007-42.fc18.noarch texlive-texmf-errata-2007-10.fc18.noarch texlive-texmf-errata-afm-2007-10.fc18.noarch texlive-texmf-errata-context-2007-10.fc18.noarch texlive-texmf-errata-doc-2007-10.fc18.noarch texlive-texmf-errata-dvips-2007-10.fc18.noarch texlive-texmf-errata-east-asian-2007-10.fc18.noarch texlive-texmf-errata-fonts-2007-10.fc18.noarch texlive-texmf-errata-latex-2007-10.fc18.noarch texlive-texmf-errata-xetex-2007-10.fc18.noarch texlive-texmf-fonts-2007-42.fc18.noarch texlive-texmf-latex-2007-42.fc18.noarch texlive-texmf-xetex-2007-42.fc18.noarch utouch-evemu-1.0.8-3.fc18.i686 utouch-evemu-1.0.8-3.fc18.x86_64 utouch-evemu-devel-1.0.8-3.fc18.i686 utouch-evemu-devel-1.0.8-3.fc18.x86_64 yum-plugin-downloadonly-1.1.31-6.fc18.noarch Is there a good way to look for them and to clean them up before release? Here's the dumb little scriptlet used to produce the above list on my F18 box. For "real world" purposes you'd want at least some control over what repositories are enabled... --- #!/usr/bin/python import yum if __name__ == '__main__': my = yum.YumBase() my.doConfigSetup() my.doRepoSetup() my.doSackSetup() obsoleted = [] for p in my.pkgSack: obsoleters = p.obsoletedBy(my.pkgSack.searchObsoletes(p.name)) if obsoleters: obsoleted.append(p) obsoleted.sort() for o in obsoleted: print o --- - Panu - -- devel mailing list devel@lists.fedoraproject.org https:
Re: Obsoleted packages in repositories (was: grub (v1) in f18?)
On Fri, 21 Dec 2012 10:55:15 +0200, Panu Matilainen wrote: > On 12/07/2012 07:59 PM, Matthew Miller wrote: > > > > Are there other obsoleted packages in the F18 repo? > > Here's what I see on F18, it's quite a pile: > > qxmpp-dev-0.6.3.1-1.fc18.i686 > qxmpp-dev-0.6.3.1-1.fc18.x86_64 > qxmpp-dev-devel-0.6.3.1-1.fc18.i686 > qxmpp-dev-devel-0.6.3.1-1.fc18.x86_64 This has been renamed to "qxmpp" in review request bug 856114 without completing the "After the review" steps, however: https://fedoraproject.org/wiki/Package_Renaming_Process -- Fedora release 18 (Spherical Cow) - Linux 3.6.11-3.fc18.x86_64 loadavg: 0.24 0.26 0.19 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On 12/21/2012 09:42 AM, Toshio Kuratomi wrote: On Fri, Dec 21, 2012 at 07:45:45AM +, Matthew Garrett wrote: On Thu, Dec 20, 2012 at 11:24:09PM -0800, Toshio Kuratomi wrote: However, you also miss my point. Adam's message was saying that the guidelines forced people to use libexecdir and then went on to point out the drawbacks of forcing specifically libexecdir on upstreams that didn't have that coded in. Again, many packages have the basic means to implement it built-in (all those using autoconf). However, * packages having been developed on non-multilib'ed systems (most packages with a Debian/Ubuntu origin) often are not taking advantage of libexecdir, because its implementors are not aware about the problems installing into %{_libdir} causes. * in many cases, adding libexecdir support is trivial (no idea about systemd) So, as I said, in that context it's meaningless to bring up arguments that are only addressed to libexecdir because %{_libdir} is an alternative. I do not agree with your conclusion. Enforcing %{_libexecdir} is one possible approach to gradually resolve the issues we are discussing here, in many situations. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, 21.12.12 05:06, Matthew Garrett (mj...@srcf.ucam.org) wrote: > On Thu, Dec 20, 2012 at 08:57:58PM -0700, Kevin Fenzi wrote: > > IMHO, libexecdir is not part of this at all... we already have: > > > > "If upstream's build scripts support the use of %{_libexecdir} then > > that is the most appropriate place to configure it (eg. passing > > --libexecdir=%{libexecdir}/%{name} to autotools configure). If > > upstream's build scripts do not support that, %{_libdir}/%{name} is a > > valid second choice. " > > > > It's all about the choice of lib instead of %{_libdir}. > > The problem is that in the absence of libexec, there's no consistent > location to put helper binaries. %{_libdir}/%{name} doesn't work - > depending on distribution and architecture, your files are now either in > lib/name, lib32/name or lib64/name. Far from ideal. Lennart's position > that fundamental system infrastructure belongs in lib makes sense, since > there's absolutely no good reason for multilibing those components. Yes, absolutely. That's key here: multilibbing things should be the exception, and used where strictly *necessary*, not the default for all files. That means that libraries should go to %{_libdir} since they need to be available for both 32bit and 64bit. However, non-library stuff such as internal binaries, or anything else arch specific should not be in %{_libdir}, but in lib/. Multilib is not pretty, it's primarily just a hack to fix one specific problem, and one shouldn't let this specific spill in an otherwise fine design. Hence: use multilib if you must for a specific file, but only then. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, 20.12.12 18:48, Toshio Kuratomi (a.bad...@gmail.com) wrote: > > Ahem. Isn't your own first sentence suggesting that *your* way is the > > one and only right way? I don't see how you can attack Lennart for > > having a firm belief about what's the 'right way' when you also seem to > > have a firm belief about what's the 'right way'... > > > The FPC Guidelines give package maintainers the option of using > %{_libexecdir}, %{_libdir}. The recent changes that I worked on allow > %{_prefix}/lib in certain cases. When FPC at large decided that portions of > what systemd wanted to do still didn't completely fall under those cases, > I took the request from FPC that FESCo simply grant a special exception for > systemd to FESCo. > > So if you're arguing that my firm belief is also a right way or the highway, > belief then you aren't arguing about the use of lib, libexec, and lib64 > anymore. You're opening up a much larger conversation about whether > top-down or bottom-up decision making is the direction that Fedora should be > taking in the future; whether Fedora "management" should decide on one and > only one way to do things and then force every packager to do things that > way. > > But if you want to go that route on this question, then it should be noted > that FPC ruled that the use that systemd makes of > %{_prefix}/lib was wrong under the prior guidelines but the systemd > maintainers refused to make their package conform. So while you might pose > that question it's not likely to have a more desirable outcome for the > systemd package maintainers than what they have now. BTW, I am fine with giving packages a certain amount of freedom how they want to handle things, but I also believe that guidelines should *guide*, i.e. suggest a a way to go, and I believe that suggested way to go is lib/ rather than %{_libexecdir}. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, 21.12.12 05:38, Ralf Corsepius (rc040...@freenet.de) wrote: > On 12/21/2012 12:27 AM, Matthew Garrett wrote: > >On Thu, Dec 20, 2012 at 10:30:37PM +, Richard W.M. Jones wrote: > > > >>Thanks, but I think the bit I'm mising is why can't systemd use > >>libexec? (Apart from their declaration that libexec is wrong or not > >>the de-facto standard they themselves made up, which is not a reason). > > > >Because libexec doesn't exist on most other distributions, > libexecdir is part of the GNU standards for ages. The "GNU standard" is kinda flawed and nobody uses that as 1:1. I mean, /usr/etc? /usr/var?? /us/com??? It's probably more interesting in looking at the more realistic "standards", such as FHS, and on what is actually really implemented, rather than on GNU which is really mostly theory... I mean, not even Debian as the distro closest to GNU follows much of that... > I disagree. systemd simply hasn't taken libexecdir into account in > its design and now is trying to propagate their oversight/mistake as > "standard" instead of making their works compliant with _our_ > distro's demands. No, we just look around, and try to do something that is not specific to a distro, somewhat sane and follows the schemes of the established to the level where they make sense. I mean, we really wanted to avoid that unit files end up in different dirs on various distros. No distro but Fedora uses libdexecdir, hence we didn't put suff in there. And /share doesn't exist in the root dir, hence all distros which haven't merge /usr can't have the unit files in /share, hence /lib is the only option. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-18 Branched report: 20121221 changes
Compose started at Fri Dec 21 09:16:15 UTC 2012 Updated Packages: fedmsg-0.6.3-1.fc18 --- * Wed Dec 05 2012 Ralph Bean - 0.6.3-1 - Use python-logutils for dictConfig on py2.6. - Attempt to fixup rhel conditionals. - Added test dependency on python-six and python-mock. * Wed Dec 05 2012 Ralph Bean - 0.6.2-1 - New support for zmq_tcp_keepalive. - New logging config. - Simplified fedmsg.commands internally. * Tue Nov 27 2012 Ralph Bean - 0.6.1-1 - Stripped fedmsg.text out into its own plugin module. - Commands are now defined as classes and use the logging module. - Bugfixes to fedmsg-collectd. - Renamed fedmsg-tweet.ini to fedmsg-tweet.init. python-moksha-hub-1.1.0-1.fc18 -- * Tue Dec 04 2012 Ralph Bean - 1.1.0-1 - Latest upstream with support for zmq_tcp_keepalive. * Tue Dec 04 2012 Ralph Bean - 1.0.9-1 - Latest upstream. - Fixed check conditional for rhel6. Summary: Added Packages: 0 Removed Packages: 0 Upgraded Packages: 2 Compose finished at Fri Dec 21 13:23:01 UTC 2012 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, 21.12.12 07:01, Ralf Corsepius (rc040...@freenet.de) wrote: > On 12/21/2012 06:16 AM, Adam Williamson wrote: > >On Fri, 2012-12-21 at 06:09 +0100, Ralf Corsepius wrote: > >>On 12/21/2012 05:54 AM, Matthew Garrett wrote: > >>>On Fri, Dec 21, 2012 at 05:38:17AM +0100, Ralf Corsepius wrote: > >>> > I disagree. systemd simply hasn't taken libexecdir into account in > its design and now is trying to propagate their oversight/mistake as > "standard" instead of making their works compliant with _our_ > distro's demands. > >>> > >>>libexec doesn't exist in any published version of the FHS, > >> > >>FHS != GCS > >> > >>http://www.gnu.org/prep/standards/standards.html#Directory-Variables > >> > >>IIRC, it's around there for at approx 20 years. > > > >I've never seen any distro take any notice of this standard whatsoever. > > Bummer ... you have been living in a vacuum for the last 20 years > and have never been coding any "a little more complex package" ? > > RPM respects the GCS ever since RPM exists, autoconf honors it ever > since autoconf and the GCS exists and all major GNU and many more > projects honor it. That's simply not true: https://www.gnu.org/prep/standards/html_node/Directory-Variables.html GNU suggests sharedstatedir=$(prefix)/com, localstatedir=$(prefix)/var, sysconfdir=$(prefix)/etc, ... I have never even seen a "com" directory on my RPM-based Fedora... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
Lennart Poettering writes: >> > IMHO, libexecdir is not part of this at all... we already have: >> > >> > "If upstream's build scripts support the use of %{_libexecdir} then >> > that is the most appropriate place to configure it (eg. passing >> > --libexecdir=%{libexecdir}/%{name} to autotools configure). If >> > upstream's build scripts do not support that, %{_libdir}/%{name} is a >> > valid second choice. " >> > >> > It's all about the choice of lib instead of %{_libdir}. >> >> The problem is that in the absence of libexec, there's no consistent >> location to put helper binaries. %{_libdir}/%{name} doesn't work - >> depending on distribution and architecture, your files are now either in >> lib/name, lib32/name or lib64/name. Far from ideal. Lennart's position >> that fundamental system infrastructure belongs in lib makes sense, since >> there's absolutely no good reason for multilibing those components. > > Yes, absolutely. That's key here: multilibbing things should be the > exception, and used where strictly *necessary*, not the default for all > files. That means that libraries should go to %{_libdir} since they need > to be available for both 32bit and 64bit. However, non-library stuff > such as internal binaries, or anything else arch specific should not be > in %{_libdir}, but in lib/. > > Multilib is not pretty, it's primarily just a hack to fix one specific > problem, and one shouldn't let this specific spill in an otherwise fine > design. Hence: use multilib if you must for a specific file, but only > then. Having been a 64bit RHEL and Fedora user for years, I couldn't agree more. And I believe a firm policy is needed for consistency and to avoid confusion. One concrete example is Nagios plugins. They're helper binaries and are put in %{_libdir}/nagios/plugins. To keep things consistent one the same architecture (having all plugins in the same location to avoid complicating configuration), even noarch plugins are built as architecture dependent packages. That shouldn't be necessary. Regards, -- Trond H. Amundsen Center for Information Technology Services, University of Oslo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, 20.12.12 23:24, Toshio Kuratomi (a.bad...@gmail.com) wrote: > > 2) we have to pressure upstream projects to needlessly complicate their > > code and buildsystem with stuff like $libexecdir variables in their > > autofoo, which resolve to /usr/libexec on Fedora/RHEL but just /usr/lib > > or something on other distros - which is kind of an imposition on > > upstreams > > > > Since neither of these things are required by the packaging guidelines, I > believe the premise of your argument is deeply flawed. > > 1) As i've said before, there is no packaging guideline requirement that > maintainers restrict helper applications to libexec. Helper apps can go > in either %{_libdir} or %{_libexecdir} (and really, helper apps should be > able to go in %{_prefix}/lib under a simple multilib exemption rather > easily now as well.) > > 2) the systemd exceptions allows placing files in %{_prefix}/lib rather > than %{_libdir} (the exceptions allow both putting the helper apps in there > which would generally be okay with just a multilib exception and the unit > files which are arch specific data and therefore usually go in %{_libdir} > and therefore needed a special exception). The only reason people can drag > %{_libexecdir} in to this discussion is that helper binaries are allowed in > either %{_libdir} or %{_libexecdir}. In the context of forcing people to > use a specific directory not specified by standards its meaningless because > %{_libdir} is a suitable alternative. it is simply wrong to place internal binaries in %{_libdir}. internal binaries should not be subject to multlib'ed dirs, the same way as binaries in bin/ are not... > 3) lennert is not asking that we give permission for packages to use > something other than %{_libexecdir} if upstream doesn't support it. He's > asking us to forbid use of libexecdir within fedora packages no matter what > the package maintainer and upstream support. Not true. I am saying the guidelines should guide people to do the right thing, but not be force too much. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
Interesting previous discussions about /usr/libexec: http://lists.debian.org/debian-devel/2005/05/thrd2.html#00401 http://www.redhat.com/archives/rhl-devel-list/2005-May/thread.html#00240 FreeBSD has /usr/libexec[1], and it's part of historical Unix, although I cannot find when it was first introduced. It's not in V7 which uses /usr/lib directly for auxiliary uucp binaries. [1] http://www.freebsd.org/doc/handbook/dirstructure.html Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On 12/21/2012 02:24 PM, Lennart Poettering wrote: On Fri, 21.12.12 05:38, Ralf Corsepius (rc040...@freenet.de) wrote: On 12/21/2012 12:27 AM, Matthew Garrett wrote: On Thu, Dec 20, 2012 at 10:30:37PM +, Richard W.M. Jones wrote: Thanks, but I think the bit I'm mising is why can't systemd use libexec? (Apart from their declaration that libexec is wrong or not the de-facto standard they themselves made up, which is not a reason). Because libexec doesn't exist on most other distributions, libexecdir is part of the GNU standards for ages. The "GNU standard" is kinda flawed and nobody uses that as 1:1. Utter nonsense. I mean, /usr/etc? /usr/var?? /us/com??? "Defaults" == they need to be adapted to a specific distro's requirements. It's probably more interesting in looking at the more realistic "standards", such as FHS, and on what is actually really implemented, rather than on GNU which is really mostly theory... I mean, not even Debian as the distro closest to GNU follows much of that... Read it again. It's a guideline distros need to adapt to their demands. And guess what? All distros have done so, and RH also has done so until this UseMove crap came alone and FUBARed Linux (I know your opinion differs, but you will not be able to change my mind on it), I disagree. systemd simply hasn't taken libexecdir into account in its design and now is trying to propagate their oversight/mistake as "standard" instead of making their works compliant with _our_ distro's demands. No, we just look around, and try to do something that is not specific to a distro, somewhat sane and follows the schemes of the established to the level where they make sense. That's not how I perceive what you are doing. You should start to consider that there are reasons behind how things are - Many people have invested their brains into it for decades. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Obsoleted packages in repositories (was: grub (v1) in f18?)
On Fri, Dec 21, 2012 at 1:55 AM, Panu Matilainen wrote: > Here's what I see on F18, it's quite a pile: [snip] > latexmk-4.35-1.fc18.noarch This one should not be obsoleted. See https://bugzilla.redhat.com/show_bug.cgi?id=868996. I'd appreciate Jindrich doing something about that before release. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-MIME-Types] Update to 1.37
commit 58f08743ace3aa9b23fa0be7e3050f66911645a0 Author: Paul Howarth Date: Fri Dec 21 15:19:56 2012 + Update to 1.37 - New upstream release 1.37: - Remove text/x-perl, where we also have an application/x-perl (CPAN RT#82100) perl-MIME-Types.spec |9 +++-- sources |2 +- 2 files changed, 8 insertions(+), 3 deletions(-) --- diff --git a/perl-MIME-Types.spec b/perl-MIME-Types.spec index 6d83d4e..d1e8a68 100644 --- a/perl-MIME-Types.spec +++ b/perl-MIME-Types.spec @@ -1,6 +1,6 @@ Name: perl-MIME-Types -Version:1.36 -Release:2%{?dist} +Version:1.37 +Release:1%{?dist} Summary:MIME types module for Perl License:GPL+ or Artistic Group: Development/Libraries @@ -55,6 +55,11 @@ rm -rf %{buildroot} %{_mandir}/man3/MIME::Types.3pm* %changelog +* Fri Dec 21 2012 Paul Howarth - 1.37-1 +- Update to 1.37: + - Remove text/x-perl, where we also have an application/x-perl +(CPAN RT#82100) + * Wed Nov 21 2012 Petr Šabata - 1.36-2 - Buildrequire perl(lib) diff --git a/sources b/sources index ebdafae..f6a3131 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -94b44788ccf668ce155d0973d8e14a5b MIME-Types-1.36.tar.gz +d491cc7a7ba77c0d6e930ff9cfbdea61 MIME-Types-1.37.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Obsoleted packages in repositories (was: grub (v1) in f18?)
On Fri, Dec 21, 2012 at 08:19:58AM -0700, Jerry James wrote: > wrote: > > Here's what I see on F18, it's quite a pile: > [snip] > > latexmk-4.35-1.fc18.noarch > This one should not be obsoleted. See > https://bugzilla.redhat.com/show_bug.cgi?id=868996. I'd appreciate > Jindrich doing something about that before release. This should be raised as a FESCO ticket. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-MIME-Types] Created tag perl-MIME-Types-1.37-1.fc19
The lightweight tag 'perl-MIME-Types-1.37-1.fc19' was created pointing to: 58f0874... Update to 1.37 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On 12/20/2012 11:54 PM, Matthew Garrett wrote: On Fri, Dec 21, 2012 at 05:38:17AM +0100, Ralf Corsepius wrote: I disagree. systemd simply hasn't taken libexecdir into account in its design and now is trying to propagate their oversight/mistake as "standard" instead of making their works compliant with _our_ distro's demands. libexec doesn't exist in any published version of the FHS, and even the draft of 3.0 makes it clear that it's optional. Our use of libexec is non-standard, not systemd's use of lib. fyi: libexec has been critical to virtualization for quite some time... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [@core] minimal install size assessment, f17 vs. f18
2012/12/19 Adam Williamson > [...] > Oh dear, sorry, I just rebooted and lost that data (I tend to keep this > kind of file in /tmp). I could re-generate it if you're really > interested. > [...] > I think this would be a nice to have on the wiki page to document the outcome of the discussions. Regards, Thomas -- Linux ... enjoy the ride! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Obsoleted packages in repositories (was: grub (v1) in f18?)
On Fri, Dec 21, 2012 at 8:28 AM, Matthew Miller wrote: > On Fri, Dec 21, 2012 at 08:19:58AM -0700, Jerry James wrote: >> wrote: >> > Here's what I see on F18, it's quite a pile: >> [snip] >> > latexmk-4.35-1.fc18.noarch >> This one should not be obsoleted. See >> https://bugzilla.redhat.com/show_bug.cgi?id=868996. I'd appreciate >> Jindrich doing something about that before release. > > This should be raised as a FESCO ticket. Sorry, it must be too early in the morning for my brain to work properly. What would I be asking FESCO to do? -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prefered way of configuring X11 keyboard layouts in F18
On Thu, 20.12.12 19:05, Nicolas Mailhot (nicolas.mail...@laposte.net) wrote: > >> The "conversion" (as systemd-localed calls it) works really poorly also > >> for the Czech keymaps/layouts. 'cz' X11 layout is "converted" to > >> 'cz-lat2' which works like 'us' until you hit the "Pause Break" key. > >> This is really unfortunate especially when people set their LUKS > >> password in Anaconda with the 'cz' X11 layout activated and then they > >> are supposed to enter it again with the 'cz-lat2' keymap during boot. > > > > This mapping is based on /usr/share/systemd/kbd-model-map btw which we > > stole from anaconda (or was it s-s-k?). > > Unfortunately this mapping never worked well, is full of obsolete entries, > has been a PITA to get updated for at least a decade (bugzilla change > requests got ignored for years). Its only redeemable feature was that once > you had installed your system you could fix anaconda choices in sysconfig > files and forget about this particular i18n horror story (good i18n is > much less important server-side which explains why anaconda layout support > was 'good enough' for RHAT I guess) Happy to take patches to improve this list. > kbd layout database has fallen into disrepair since ubuntu/debian started > generating their console layouts from xkb-config (they don't use kbd). Hmm, are you saying that Fedora is just freeloading off Ubuntu? Interesting, usually one hears only the opposite... > Ubuntu/debian has the lion share desktop-side so all the i18n layouts get > improved and updated in xkb-config, and few layout authors even bother > with kbd layouts anymore (writing a layout is akin to writing in > assembler, no one once to write the same routine twice it two different > obscure layout dialects if it's possible to avoid it) Well, the conversion stuff is really nothing we'd want to adopt in Fedora as is. It's a perl hackery around the awful old tools we use. Yes, it would be great if we could also use the same mappings for the console as for X, but that would either require that somehow the conversions can be done offline and shipped pre-converted, or that somebody reimplements this in a sane toolset that isn't just some Perl hackery. > > We are happy to take patches for this database file, to improve the > > mapping. > > The database is bitrotten and even it it wasn't most modern layouts do not > exist kbd-side at all. Most layouts with perfect mapping are old legacy > ascii layouts. They are still in xkb-config for historical reasons but in > many locales the preferred layout includes changes (unicode…) which have > never been ported to kbd. I doubt it's that rotten. It definitely works fine for the most popular keymaps, such as the american and german. Note that this conversion has been exposed via GNOME's kbd config thingy for a while, and we didn't really get much bugs about it, hence I assume that it isn't too bad. I mean, if you see bugs, please report them, tell us what to fix. Other than that i can only tell you that the amount of bugs we got so far about this is close to zero, hence I can only assume things are not as bad as you say. > If you really want to support console keyboard layouts in systemd, you > need to start generating console layouts from xkb-config, not adopt the > old anaconda mapping bandaid I am pretty sure I don't want to work on this. But I'd welcome if somebody did work on it, and we'd be happy to support this in systemd if done right. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Obsoleted packages in repositories (was: grub (v1) in f18?)
On Fri, Dec 21, 2012 at 08:55:22AM -0700, Jerry James wrote: > >> > Here's what I see on F18, it's quite a pile: > >> > latexmk-4.35-1.fc18.noarch > >> This one should not be obsoleted. See > >> https://bugzilla.redhat.com/show_bug.cgi?id=868996. I'd appreciate > >> Jindrich doing something about that before release. > > This should be raised as a FESCO ticket. > Sorry, it must be too early in the morning for my brain to work > properly. What would I be asking FESCO to do? Decide between the two redundant and conflicting packagings of the same code. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-MailTools] Created tag perl-MailTools-2.12-1.fc19
The lightweight tag 'perl-MailTools-2.12-1.fc19' was created pointing to: e9ef814... Update to 2.12 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Obsoleted packages in repositories (was: grub (v1) in f18?)
On Fri, Dec 21, 2012 at 8:59 AM, Matthew Miller wrote: > On Fri, Dec 21, 2012 at 08:55:22AM -0700, Jerry James wrote: >> Sorry, it must be too early in the morning for my brain to work >> properly. What would I be asking FESCO to do? > > Decide between the two redundant and conflicting packagings of the same > code. Ah, got it, thanks. Here's the ticket: https://fedorahosted.org/fesco/ticket/983 -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 10:49:19AM -0500, Don Dutile wrote: > On 12/20/2012 11:54 PM, Matthew Garrett wrote: > >libexec doesn't exist in any published version of the FHS, and even the > >draft of 3.0 makes it clear that it's optional. Our use of libexec is > >non-standard, not systemd's use of lib. > > > > fyi: libexec has been critical to virtualization for quite some time... How do you manage to do anything on Ubuntu? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Obsoleted packages in repositories (was: grub (v1) in f18?)
On Fri, 21 Dec 2012 09:13:27 -0700 Jerry James wrote: > On Fri, Dec 21, 2012 at 8:59 AM, Matthew Miller > wrote: > > On Fri, Dec 21, 2012 at 08:55:22AM -0700, Jerry James wrote: > >> Sorry, it must be too early in the morning for my brain to work > >> properly. What would I be asking FESCO to do? > > > > Decide between the two redundant and conflicting packagings of the > > same code. > > Ah, got it, thanks. Here's the ticket: > https://fedorahosted.org/fesco/ticket/983 Well, IMHO reading the bug it just sounds like to me a mistake was made and the obsoletes/conflicts was not removed as intended: +* Sun Nov 4 2012 Jindrich Novy 2012-5-20121024 +- don't conflict with latexmk (#868996) (but that version didn't change obsoletes/conflicts at all) I'd suggest instead just mailing jnovy and asking if that was a mistake and if he could push the correct fix before jumping to conclusions. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Test-Unit-Lite] Created tag perl-Test-Unit-Lite-0.12-15.fc19
The lightweight tag 'perl-Test-Unit-Lite-0.12-15.fc19' was created pointing to: e9b545c... Update to 0.1202 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 04:22:47PM +, Matthew Garrett wrote: > On Fri, Dec 21, 2012 at 10:49:19AM -0500, Don Dutile wrote: > > On 12/20/2012 11:54 PM, Matthew Garrett wrote: > > >libexec doesn't exist in any published version of the FHS, and even the > > >draft of 3.0 makes it clear that it's optional. Our use of libexec is > > >non-standard, not systemd's use of lib. > > > > > > > fyi: libexec has been critical to virtualization for quite some time... I think Don is referring to the helper binaries that go into /usr/libexec: $ rpm -ql qemu-common | grep libexec /usr/libexec/qemu-bridge-helper $ rpm -ql libvirt-daemon | grep libexec /usr/libexec/libvirt_iohelper /usr/libexec/libvirt_lxc /usr/libexec/libvirt_parthelper [Not relevant to this discussion, but on RHEL /usr/libexec/qemu-kvm is the location of the KVM binary, designed to make it clear that this should not be run directly by RHEL customers (at least, not if they desire support).] > How do you manage to do anything on Ubuntu? The files above don't appear to be packaged at all on Debian (Wheezy beta 4). However the versions of libvirt, qemu etc on Debian are rather old compared to what we're shipping in F18. They might predate those files being needed. Ubuntu has really poor virt support, and IME just copies stuff partially and badly from Debian. It doesn't seem to be their focus and libguestfs at least is often broken. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Obsoleted packages in repositories (was: grub (v1) in f18?)
On Fri, Dec 21, 2012 at 9:24 AM, Kevin Fenzi wrote: > Well, IMHO reading the bug it just sounds like to me a mistake was made > and the obsoletes/conflicts was not removed as intended: > > +* Sun Nov 4 2012 Jindrich Novy 2012-5-20121024 > +- don't conflict with latexmk (#868996) > > (but that version didn't change obsoletes/conflicts at all) Ah, that makes sense. > I'd suggest instead just mailing jnovy and asking if that was a mistake > and if he could push the correct fix before jumping to conclusions. Hmm, I didn't think I had jumped to any conclusions. That's why I was patiently waiting for a response on the bug. I only spoke up because I was afraid that the appearance of latexmk on this list meant that its destruction was imminent. In any case, Jindrich has been CCed to the FESCO ticket, so I'll just wait for a response there. Or maybe you aren't talking to me. I think it's too late in the morning for me to claim that it's too early in the morning for my brain to be working properly. I think I have to admit now that my brain is already entering full "Christmas vacation" mode. C'mon brain, back to work -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 12:42:14AM -0800, Toshio Kuratomi wrote: > However, you also miss my point. Adam's message was saying that the > guidelines forced people to use libexecdir and then went on to point out the > drawbacks of forcing specifically libexecdir on upstreams that didn't have > that > coded in. So, as I said, in that context it's meaningless to bring up > arguments that are only addressed to libexecdir because %{_libdir} is an > alternative. I think you miss my point. Where consistency across architectures is desired, %{_libdir} isn't an option, so in the absence of an exception the guidelines force people to use libexec. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM status meeting minutes for 2012-12-19
On Fri, Dec 21, 2012 at 03:11:32AM -0500, Jon Masters wrote: > I would like to share the minutes from yesterday's Fedora ARM meeting. > In particular, those on devel@ might be interested in our desire to > discuss PA at FUDCon. At FUDCon, we will have a 24 node Calxeda > EnergyCore (highbank) server that will demonstrate various capabilities > of the (multiple) build server systems that will be available in PHX. At > FUDCon we will discuss both our 32-bit build plans and PA push. > Separately, there will be 64-bit discussions. We would welcome > suggestions (on the arm@ list please) from those who have input on the > best format for the PA discussions during the FUDCon event in January. Are you looking at F19 or F20 for PA? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 04:37:59PM +, Richard W.M. Jones wrote: > On Fri, Dec 21, 2012 at 04:22:47PM +, Matthew Garrett wrote: > > On Fri, Dec 21, 2012 at 10:49:19AM -0500, Don Dutile wrote: > > > fyi: libexec has been critical to virtualization for quite some time... > > I think Don is referring to the helper binaries that go into > /usr/libexec: > > $ rpm -ql qemu-common | grep libexec > /usr/libexec/qemu-bridge-helper > $ rpm -ql libvirt-daemon | grep libexec > /usr/libexec/libvirt_iohelper > /usr/libexec/libvirt_lxc > /usr/libexec/libvirt_parthelper Is the path user visible in any way? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM status meeting minutes for 2012-12-19
On 12/21/2012 08:53 AM, Matthew Garrett wrote: Are you looking at F19 or F20 for PA? This will be a very engaging topic at FUDCon next month. Current logistics make the following likely: F19: Transition to enterprise ARM hardware in PHX F20: Push armv7hl to PA -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 04:55:09PM +, Matthew Garrett wrote: > On Fri, Dec 21, 2012 at 04:37:59PM +, Richard W.M. Jones wrote: > > On Fri, Dec 21, 2012 at 04:22:47PM +, Matthew Garrett wrote: > > > On Fri, Dec 21, 2012 at 10:49:19AM -0500, Don Dutile wrote: > > > > fyi: libexec has been critical to virtualization for quite some time... > > > > I think Don is referring to the helper binaries that go into > > /usr/libexec: > > > > $ rpm -ql qemu-common | grep libexec > > /usr/libexec/qemu-bridge-helper > > $ rpm -ql libvirt-daemon | grep libexec > > /usr/libexec/libvirt_iohelper > > /usr/libexec/libvirt_lxc > > /usr/libexec/libvirt_parthelper > > Is the path user visible in any way? If used, /usr/libexec/qemu-bridge-helper is encoded directly in the libvirt XML. So is libvirt_lxc. (So is /usr/libexec/qemu-kvm, on RHEL). Not sure about the other two libvirt_* files. It appears that libvirtd simply runs those. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 05:09:00PM +, Richard W.M. Jones wrote: > On Fri, Dec 21, 2012 at 04:55:09PM +, Matthew Garrett wrote: > > Is the path user visible in any way? > > If used, /usr/libexec/qemu-bridge-helper is encoded directly in the > libvirt XML. So is libvirt_lxc. (So is /usr/libexec/qemu-kvm, on > RHEL). Are those expected to be portable between systems? If not, it's not a problem. If so, you probably want to rethink the use of libexec. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM status meeting minutes for 2012-12-19
On Fri, Dec 21, 2012 at 09:06:07AM -0800, Brendan Conoboy wrote: > On 12/21/2012 08:53 AM, Matthew Garrett wrote: > >Are you looking at F19 or F20 for PA? > > This will be a very engaging topic at FUDCon next month. Current > logistics make the following likely: > > F19: Transition to enterprise ARM hardware in PHX > > F20: Push armv7hl to PA I think that seems realistic. It'd be good to aim for being on infrastructure koji for the end of F19 - if we can have an ARM build of F19 that's pretty much in lockstep with the PAs, it makes the argument for promotion in F20 very straightforward. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 05:13:17PM +, Matthew Garrett wrote: > On Fri, Dec 21, 2012 at 05:09:00PM +, Richard W.M. Jones wrote: > > On Fri, Dec 21, 2012 at 04:55:09PM +, Matthew Garrett wrote: > > > Is the path user visible in any way? > > > > If used, /usr/libexec/qemu-bridge-helper is encoded directly in the > > libvirt XML. So is libvirt_lxc. (So is /usr/libexec/qemu-kvm, on > > RHEL). > > Are those expected to be portable between systems? If not, it's not a > problem. If so, you probably want to rethink the use of libexec. There's no requirement for portability, XML files are considered to be specific to the host they're installed on, so its not a portability problem. Contrary to what Don says earlier in the thread, I think the choice of lib vs libexec has essentially zero impact on virtualization. It is just a choice distro packagers make Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Obsoleted packages in repositories (was: grub (v1) in f18?)
On Fri, Dec 21, 2012 at 10:55:15AM +0200, Panu Matilainen wrote: > Here's what I see on F18, it's quite a pile: I made a Rel-Eng ticket: https://fedorahosted.org/rel-eng/ticket/5427 -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, Dec 20, 2012 at 09:16:00PM -0800, Adam Williamson wrote: > I've never seen any distro take any notice of this standard whatsoever. Well, if you don't count Red Hat Linux, Fedora, and Red Hat Enterprise Linux -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
PSA: updates-testing default disabled now
Just a heads up to everyone using f18 right now: with fedora-release-18-1 that just pushed out to updates-testing yesterday, the updates-testing repo is now by default disabled. This means you may well see some issues trying to install new packages/groups because you have NEWER packages from updates-testing installed, but that repo is no longer enabled. You can: 1) re-enable updates-testing and help test packages further. or 2) run a 'yum distro-sync' to sync with the stable repos. This should get you back on track with no updates-testing packages installed. Just a heads up if you see odd dep issues. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 04:55:09PM +, Matthew Garrett wrote: > On Fri, Dec 21, 2012 at 04:37:59PM +, Richard W.M. Jones wrote: > > On Fri, Dec 21, 2012 at 04:22:47PM +, Matthew Garrett wrote: > > > On Fri, Dec 21, 2012 at 10:49:19AM -0500, Don Dutile wrote: > > > > fyi: libexec has been critical to virtualization for quite some time... > > > > I think Don is referring to the helper binaries that go into > > /usr/libexec: > > > > $ rpm -ql qemu-common | grep libexec > > /usr/libexec/qemu-bridge-helper > > $ rpm -ql libvirt-daemon | grep libexec > > /usr/libexec/libvirt_iohelper > > /usr/libexec/libvirt_lxc > > /usr/libexec/libvirt_parthelper > > Is the path user visible in any way? Yes & no. The iohelper/parthelper binaries are not user visible things. They're purely internal helpers libvirt uses. The libvirt_lxc binary does appear in the XML /usr/libexec/libvirt_lxc. The libvirt_lxc binary is the host-side helper, akin to /bin/qemu-system-x86_64 in QEMU/KVM world. We put it under /usr/libexec though because it isn't a binary end users will ever directly invoke. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 04:59:59PM +, Daniel P. Berrange wrote: > The libvirt_lxc binary does appear in the XML > /usr/libexec/libvirt_lxc. The libvirt_lxc binary is the > host-side helper, akin to /bin/qemu-system-x86_64 > in QEMU/KVM world. We put it under /usr/libexec though because it isn't a > binary > end users will ever directly invoke. That seems fine. libexec is a perfectly reasonable place for it to be on Fedora, and other distributions can stick them in lib/libvirt. Where they're this opaque there's no problem. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On 20 December 2012 22:16, Adam Williamson wrote: > On Fri, 2012-12-21 at 06:09 +0100, Ralf Corsepius wrote: >> On 12/21/2012 05:54 AM, Matthew Garrett wrote: >> > On Fri, Dec 21, 2012 at 05:38:17AM +0100, Ralf Corsepius wrote: >> > >> >> I disagree. systemd simply hasn't taken libexecdir into account in >> >> its design and now is trying to propagate their oversight/mistake as >> >> "standard" instead of making their works compliant with _our_ >> >> distro's demands. >> > >> > libexec doesn't exist in any published version of the FHS, >> >> FHS != GCS >> >> http://www.gnu.org/prep/standards/standards.html#Directory-Variables >> >> IIRC, it's around there for at approx 20 years. > > I've never seen any distro take any notice of this standard whatsoever. > This is in fact the first reference I've seen to it in any context. The historical reason that Red Hat/Fedora used /usr/libexec and various other oddities was to conform to the GCS in Red Hat's early days. A file standard needed to be chosen that worked for things and GCS was setup for all the GNU tools. RPM was then coded to be GCS friendly etc etc. That said, the need to keep following the FHS, GCS, or the JanitorsFileLayoutStandard is up to FESCO after a reasoned debate.. which seems fairly lacking on everyone's side at the moment. Go take a week off and come back in January. Or better yet, how about going outside the Fedora bubble and conversing with the relevant people in Debian, SuSE, etc and getting FHS back on track because we are all having the same issues about this and we keep solving them seperately versus together. -- Stephen J Smoogen. "Don't derail a useful feature for the 99% because you're not in it." Linus Torvalds "Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PSA: updates-testing default disabled now
Question: Does this affect mock builds on koji ? NM 2012/12/21 Kevin Fenzi : > Just a heads up to everyone using f18 right now: > > with fedora-release-18-1 that just pushed out to updates-testing > yesterday, the updates-testing repo is now by default disabled. > > This means you may well see some issues trying to install new > packages/groups because you have NEWER packages from updates-testing > installed, but that repo is no longer enabled. > > You can: > > 1) re-enable updates-testing and help test packages further. > > or > > 2) run a 'yum distro-sync' to sync with the stable repos. This should > get you back on track with no updates-testing packages installed. > > Just a heads up if you see odd dep issues. ;) > > kevin > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PSA: updates-testing default disabled now
On Fri, Dec 21, 2012 at 18:28:42 +, Nelson Marques wrote: Question: Does this affect mock builds on koji ? I don't think so. koji builds only use what's in stable and explicit overrides. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PSA: updates-testing default disabled now
On Fri, 21 Dec 2012 18:28:42 + Nelson Marques wrote: > Question: Does this affect mock builds on koji ? No. This has no effect on them. F18 builds in koji never have used updates-testing, nor will they. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, 2012-12-21 at 12:30 -0500, Matthew Miller wrote: > On Thu, Dec 20, 2012 at 09:16:00PM -0800, Adam Williamson wrote: > > I've never seen any distro take any notice of this standard whatsoever. > > Well, if you don't count Red Hat Linux, Fedora, and Red Hat Enterprise > Linux I should probably have been more precise about that, but what I meant was this: I've been following this list for several years now and not once in any of the many and colorful arguments we have about path names and locations do I recall anyone citing this GNU filesystem 'standard'. I don't recall it coming up once in the /usr move saga, for instance. An archive search shows I'm slightly wrong, but not very much so: https://www.google.ca/search?q="gnu coding standards"+site%3Ahttps%3A%2F %2Flists.fedoraproject.org%2Fpipermail%2Fdevel it appears to have been cited in about 10 threads since 2004. And most of those in a 'it's an interesting reference but nothing we have to follow' sort of way. Indeed, in an earlier discussion on this topic, Toshio wrote explicitly that we don't consider GCS as canonical: "to be clear the GNU coding standards are not definitive for Fedora like the FHS is at this time; I'm including the quotation to show what current best practices are in this regard" https://lists.fedoraproject.org/pipermail/devel/2011-June/152343.html In passing, a post from Toshio back in February explains rather more clearly than anything in this thread why systemd unit files shouldn't go in libexec anyway, and so why this whole side-thread is kind of irrelevant: "So I have to admit here that I have no idea why systemd is using $libexecdir here. The definition of libexecdir does not support the storing of unit files...unit files are declarative, not executable. It sounds like upstream systemd wants to use $(exec_prefix)/lib/systemd for the unit files and is attempting to shoehorn those into libexecdir because some distros set libexecdir to ${exec_prefix}/lib whereas some distros on some arches set libdir to ${exec_prefix}lib64 This is incorrect use of libexecdir. They should just use ${exec_prefix}/lib if that is the place that makes the most sense." https://lists.fedoraproject.org/pipermail/devel/2012-February/163024.html -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 04:47:58PM +, Matthew Garrett wrote: > On Fri, Dec 21, 2012 at 12:42:14AM -0800, Toshio Kuratomi wrote: > > > However, you also miss my point. Adam's message was saying that the > > guidelines forced people to use libexecdir and then went on to point out the > > drawbacks of forcing specifically libexecdir on upstreams that didn't have > > that > > coded in. So, as I said, in that context it's meaningless to bring up > > arguments that are only addressed to libexecdir because %{_libdir} is an > > alternative. > > I think you miss my point. Where consistency across architectures is > desired, %{_libdir} isn't an option, so in the absence of an exception > the guidelines force people to use libexec. > Please re-read my email to see how I addressed your concerns in my first paragraph. This paragraph was to show how my email was responding to the context in Adam's email. -Toshio pgpjQ41lPkL75.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, 2012-12-21 at 15:17 +0100, Ralf Corsepius wrote: > > The "GNU standard" is kinda flawed and nobody uses that as 1:1. > Utter nonsense. > > > I mean, > > /usr/etc? /usr/var?? /us/com??? > "Defaults" == they need to be adapted to a specific distro's requirements. > > > It's probably more interesting in looking at the more realistic > > "standards", such as FHS, and on what is actually really implemented, > > rather than on GNU which is really mostly theory... I mean, not even > > Debian as the distro closest to GNU follows much of that... > Read it again. It's a guideline distros need to adapt to their demands. If everyone who implements a standard adapts it to their 'requirements' and 'demands', then how is it a standard exactly? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM status meeting minutes for 2012-12-19
On Fri, Dec 21, 2012 at 5:17 PM, Matthew Garrett wrote: > On Fri, Dec 21, 2012 at 09:06:07AM -0800, Brendan Conoboy wrote: >> On 12/21/2012 08:53 AM, Matthew Garrett wrote: >> >Are you looking at F19 or F20 for PA? >> >> This will be a very engaging topic at FUDCon next month. Current >> logistics make the following likely: >> >> F19: Transition to enterprise ARM hardware in PHX >> >> F20: Push armv7hl to PA > > I think that seems realistic. It'd be good to aim for being on > infrastructure koji for the end of F19 - if we can have an ARM build of > F19 that's pretty much in lockstep with the PAs, it makes the argument > for promotion in F20 very straightforward. I would like to be on infrastructure just after F19 branches for building of F-20. F-19 builds are catching up, we've had some issues with texlive and eclipse which has impacted the tree somewhat but we're moving forward again so should be caught up again soon. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
Lennart Poettering (mzerq...@0pointer.de) said: > it is simply wrong to place internal binaries in %{_libdir}. internal > binaries should not be subject to multlib'ed dirs, the same way as > binaries in bin/ are not... I would note I have seen cases where helper binaries actually needed to be arch-specific and in $prefix/$libdir. I think it was bonobo? In any case, I agree - my proposal was that packages that use non-multilibbed helper binaries should be free to put them in *one of* $prefix/lib or $prefix/libexec, as long as they remain consistent. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 10:33:27AM -0800, Adam Williamson wrote: > On Fri, 2012-12-21 at 12:30 -0500, Matthew Miller wrote: > > On Thu, Dec 20, 2012 at 09:16:00PM -0800, Adam Williamson wrote: > > > I've never seen any distro take any notice of this standard whatsoever. > > > > Well, if you don't count Red Hat Linux, Fedora, and Red Hat Enterprise > > Linux > > I should probably have been more precise about that, but what I meant > was this: I've been following this list for several years now and not > once in any of the many and colorful arguments we have about path names > and locations do I recall anyone citing this GNU filesystem 'standard'. > > I don't recall it coming up once in the /usr move saga, for instance. > Just a note -- I try to mention the GNU Coding Standards everytime libexec has come up in the context of not being standardized. I may not catch each and every thread that mentions libexec because it's not always relevant to the discussion (if the discussion isn't about libexec in standards). No sense bringing the same discussion up repeatedly once the posters appear to remember it ;-) (And sometimes, I just don't see a post where it would make sense to add a mention of the GNU Coding Standards... especially if I'm slogging through an email backlog after a vacation or conference ;-) The GNU Coding Standards mention even made it into one of the UsrMove threads. I think you found that in your google search but just neglected to clearly articulate it (and of course, I probably didn't call enough attention to it since I've posted about the relation before and they are mentioned in the Filesystem Layout section of the Packaging Guidelines). http://lists.fedoraproject.org/pipermail/devel/2012-February/163024.html > > An archive search shows I'm slightly wrong, but not very much so: > > https://www.google.ca/search?q="gnu coding standards"+site%3Ahttps%3A%2F > %2Flists.fedoraproject.org%2Fpipermail%2Fdevel > > it appears to have been cited in about 10 threads since 2004. And most > of those in a 'it's an interesting reference but nothing we have to > follow' sort of way. Indeed, in an earlier discussion on this topic, > Toshio wrote explicitly that we don't consider GCS as canonical: > > "to be clear the GNU coding standards are not definitive for Fedora like > the FHS is at this time; I'm including the quotation to show what > current best practices are in this regard" > > https://lists.fedoraproject.org/pipermail/devel/2011-June/152343.html Although your use of "canonical" above is open to interpretation (In retrospect, I suppose that "definitive" is also). I'd apply the word "canonical" for Fedora to be what's written in the Fedora Packaging Guidelines. In turn, the Packaging Guidelines consider the FHS to be the foundation of where files belong on the filesystems with a few tweaks that are explicitly mentioned in the Packaging Guidelines. The tweak for libexec was drawn from the GNU Coding Standards. Many of the other paths in the FHS are listed in the GNU Coding Standards and serve the same purpose in both documents so you can sometimes read the GNU Coding Standards for a broader understanding of why the placement of a particular type of file in a particular path is appropriate. But if you want to base a decision on something that's in the GUN Coding Standard but not in the FHS or Packaging Guidelines, then you should be taking it to the FPC for them to evaluate whether to add it to the Fedora Packaging Guidelines as a new tweak/exception to the general "follow FHS" rule. > > In passing, a post from Toshio back in February explains rather more > clearly than anything in this thread why systemd unit files shouldn't go > in libexec anyway, and so why this whole side-thread is kind of > irrelevant: > > "So I have to admit here that I have no idea why systemd is using > $libexecdir here. The definition of libexecdir does not support the > storing of unit files...unit files are declarative, not executable. It > sounds like upstream systemd wants to use $(exec_prefix)/lib/systemd for > the unit files and is attempting to shoehorn those into libexecdir > because some distros set libexecdir to ${exec_prefix}/lib whereas some > distros on some arches set libdir to ${exec_prefix}lib64 This is > incorrect use of libexecdir. They should just use ${exec_prefix}/lib if > that is the place that makes the most sense." > > https://lists.fedoraproject.org/pipermail/devel/2012-February/163024.html > Yep, thanks for finding that quote. I'm not sure what variable systemd currently using in its build scripts but that still applies here. -Toshio pgpWy2aovJdiR.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
Once upon a time, Bill Nottingham said: > In any case, I agree - my proposal was that packages that use > non-multilibbed helper binaries should be free to put them in *one of* > $prefix/lib or $prefix/libexec, as long as they remain consistent. As a sys admin (and an OCD one at that), I'd prefer to keep "things that are run" separate from other stuff. Except when they are multi-lib, I think executables should be kept out of lib/ or lib64/; that's exactly what libexec/ is for. There used to be (not just talking about Linux) bunches of executables all over the place (/lib and /usr/lib, /etc, and so on), but they have moved to more appropriate places (such as sbin/ directories) over the years (except for /usr/lib/sendmail, which apparently will live forever, but at least it is just a symlink now). IMHO putting executables in lib/ or lib64/ is a regression to the past. Another package that has always seemed odd to me is mailman; why are all the commands (that are expected to be run from the command line, not just as internal helpers) in /usr/lib/mailman/bin? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 02:17:39PM -0500, Bill Nottingham wrote: > Lennart Poettering (mzerq...@0pointer.de) said: > > it is simply wrong to place internal binaries in %{_libdir}. internal > > binaries should not be subject to multlib'ed dirs, the same way as > > binaries in bin/ are not... > > I would note I have seen cases where helper binaries actually needed to be > arch-specific and in $prefix/$libdir. I think it was bonobo? > > In any case, I agree - my proposal was that packages that use > non-multilibbed helper binaries should be free to put them in *one of* > $prefix/lib or $prefix/libexec, as long as they remain consistent. > I'll see if I can write this into the packaging Guidelines -- the FPC members were just worried that packagers would attempt to use a multilib exemption without a manual review as a way to circumvent non-trivial packaging issues: "The upstream library build scripts just use hardcoded /usr/lib. I haven't heard of anyone using multilib (what is multilib anyway?) so I guess I can just install it to /usr/lib." But something like "helper binaries that would ordinarily be installed into %{_libexecdir} are always multilib exempt. Just be sure the (sub)package they're in does not have other, multiilib content. If in doubt, ask." might be clear enough to pass. I'll open the FPC ticket now. And on another note, adamw and myself decided that in the spirit of Christmas, we're going to attempt to let this thread die. You can look forward to zero new posts from the two of us on this thread. Happy Holidays everyone, here's wishing everyone a flame free inbox for Christmas :-) -Toshio pgpyCScGNmuDS.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ruby 2.0 in F19
On Thu, Dec 20, 2012 at 4:47 AM, Vít Ondruch wrote: > Hi everybody, > > According to Ruby 2.0 release schedule: > > - code freeze: 23 Dec. > - 2.0.0-rc1 release: 1W Jan. (expected) > - 2.0.0-rc2 release: 1W Feb. (expected) > - 2.0.0-p0 release: 24 Feb. > > the official release date is quickly approaching. Therefore, I would like to > update you about current plans for Fedora > > * I am trying to closely track recent development of Ruby 2.0 and the .spec > is available in ruby-2.0 branch of dist-git repo [1]. > * I started to put together pieces of feature proposal for Ruby 2.0 in F19 > [2]. > * Every package which depends on Ruby will need to be rebuild. There are > several reasons: > - The Ruby 2.0 is ABI incompatible with Ruby 1.9.3 (although it should be > source level compatible). > - Due to better integration of JRuby into Fedora [3], we would like to > take this opportunity to restructure RubyGems folder > layout. This should allow us to support Rubinius in the future as well. > - I would like to get rid of ruby(abi) virtual provide, since it does not > express enough the level of compatibility > between JRuby and MRI. There is ongoing discussion about it on packaging > list [4]. > > So at the beginning of January, I'd like to ask rel-eng for dedicated build > target for rebuild of Ruby packages (we will probably use this target for > JRuby build as well). Please let me know if you want to opt-out and rebuild > your packages by yourself. > > > Vít > > > > > [1] http://pkgs.fedoraproject.org/cgit/ruby.git/tree/?id=ruby-2.0 > [2] https://fedoraproject.org/wiki/Features/Ruby_2.0.0 > [3] http://fedoraproject.org/wiki/Features/JRuby_1.7.1 > [4] > http://lists.fedoraproject.org/pipermail/packaging/2012-December/008798.html > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel Sigh ... now there are *three* incompatible Ruby syntax / semantics "standards" to deal with. Why don't we just ship 'rvm' or 'rbenv' and force everyone to manage their own Ruby environments? ;-) -- Twitter: http://twitter.com/znmeb; Computational Journalism Publishers Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/ How the Hell can the lion sleep with all those people singing "A weem oh way!" at the top of their lungs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self Introduction
Hello all, I'm interested in becoming a Fedora package maintainer, thought I'd throw out the self-introduction. A bit about me: I currently work as a release engineer at Puppet Labs in Portland, Oregon, and before that was a Mac sysadmin for a local college here. Most of my packaging experience has been gained here at Puppet, packaging our products as rpms, debs, and in various other forms (my heart has always been with rpm packaging). My goals here are both to contribute back to Open Source and do my part to help keep the Fedora platform awesome, and also work with the Fedora maintainers of puppet to making sure Puppet upstream is a good citizen of the Fedora community and ease its adoption. In this spirit, I commented on this BZ https://bugzilla.redhat.com/show_bug.cgi?id=782560 with some help to move it along as a Puppet dependency, but alas, it hasn't gotten a ton of traction just yet. Anyway, just thought I'd introduce myself, perhaps in search of a sponsor. Cheers, Moses Mendoza mo...@puppetlabs.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prefered way of configuring X11 keyboard layouts in F18
On Fri, 2012-12-21 at 16:57 +0100, Lennart Poettering wrote: > > The database is bitrotten and even it it wasn't most modern layouts do not > > exist kbd-side at all. Most layouts with perfect mapping are old legacy > > ascii layouts. They are still in xkb-config for historical reasons but in > > many locales the preferred layout includes changes (unicode…) which have > > never been ported to kbd. > > I doubt it's that rotten. It definitely works fine for the most popular > keymaps, such as the american and german. All this keymap stuff is bending my brain, but I've been poking at it for the last few days, and I'm rather afraid it *is* that bad. See this tentatively accepted blocker bug: https://bugzilla.redhat.com/show_bug.cgi?id=889562 If I have everything right, anaconda is offering a keymap list that it derives from xkb. I'm having trouble counting precisely how many layouts it offers, but it looks to be definitely over 400. According to 'localectl list-keymaps', systemd-localed has mappings for 209 keymaps. So there's at least 191 keymaps (probably rather more) which anaconda offers you but which systemd doesn't understand: if you install with any of these keymaps selected as the default keymap (top of the list in Keyboard spoke), you will wind up with US as your console keyboard layout on the installed system. We could really do with input from interested parties on exactly how bad of a problem this is - if people could look through the keyboard layouts offered in F18's Keyboard spoke and compare them to the list from 'localectl list-keymaps', and identify particularly important ones that systemd doesn't seem to grok, it'd really help. So far, I _think_ systemd is missing all Arabic layouts. It's missing French (Canada). It's missing five Japanese layouts that anaconda offers. It's missing Chinese, that's a big one. That's just scratching the surface. > Note that this conversion has been exposed via GNOME's kbd config thingy > for a while, and we didn't really get much bugs about it, hence I assume > that it isn't too bad. > > I mean, if you see bugs, please report them, tell us what to fix. Other > than that i can only tell you that the amount of bugs we got so far > about this is close to zero, hence I can only assume things are not as > bad as you say. It's more likely to be that we have so many keymap bugs, everyone's confused about what bug is what. That's certainly where I feel like we're at right now. > > If you really want to support console keyboard layouts in systemd, you > > need to start generating console layouts from xkb-config, not adopt the > > old anaconda mapping bandaid > > I am pretty sure I don't want to work on this. But I'd welcome if > somebody did work on it, and we'd be happy to support this in systemd if > done right. > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prefered way of configuring X11 keyboard layouts in F18
On Thu, Dec 20, 2012 at 3:49 PM, Sérgio Basto wrote: > On Qui, 2012-12-20 at 20:16 +0100, Nicolas Mailhot wrote: >> IIRC, an anaconda bug already exists (don't remember the number, I do >> remember answering some questions Mismo asked about the Debian system >> there) > > I need the number https://bugzilla.redhat.com/show_bug.cgi?id=680990 and https://bugzilla.redhat.com/show_bug.cgi?id=837292 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora ARM status meeting minutes for 2012-12-19
Hi everyone, I would like to share the minutes from yesterday's Fedora ARM meeting. In particular, those on devel@ might be interested in our desire to discuss PA at FUDCon. At FUDCon, we will have a 24 node Calxeda EnergyCore (highbank) server that will demonstrate various capabilities of the (multiple) build server systems that will be available in PHX. At FUDCon we will discuss both our 32-bit build plans and PA push. Separately, there will be 64-bit discussions. We would welcome suggestions (on the arm@ list please) from those who have input on the best format for the PA discussions during the FUDCon event in January. Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-12-19/fedora-meeting-1.2012-12-19-21.01.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2012-12-19/fedora-meeting-1.2012-12-19-21.01.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-12-19/fedora-meeting-1.2012-12-19-21.01.log.html Additionally, I can update the status of the following: 1a). TC3 images were tested on various boards: https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/2012-12-20-VFAD-Fedora_18_Beta 1b). I did test on GuruPlug. It's the same as before (works, but requires modifications to U-Boot configuration and boot setup). This will not be a beta blocker but it will require that I write up better. 1c). Both the Panda and Panda ES have been tested. 1d). David did run the VFAD as planned. 1f). We hope to all live long enough to have the "End of the World" beta release posted later on today. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On 12/21/2012 12:27 AM, Matthew Garrett wrote: On Thu, Dec 20, 2012 at 10:30:37PM +, Richard W.M. Jones wrote: Thanks, but I think the bit I'm mising is why can't systemd use libexec? (Apart from their declaration that libexec is wrong or not the de-facto standard they themselves made up, which is not a reason). Because libexec doesn't exist on most other distributions, and systemd aims to offer consistent interfaces across distributions. Shouldn't binaries which are part of the external interface reside in /usr/sbin? If the paths are not part of the interface, cross-distribution consistency shouldn't matter (as seen with git, for example). -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On 12/21/2012 09:24 AM, Florian Weimer wrote: On 12/21/2012 12:27 AM, Matthew Garrett wrote: On Thu, Dec 20, 2012 at 10:30:37PM +, Richard W.M. Jones wrote: Thanks, but I think the bit I'm mising is why can't systemd use libexec? (Apart from their declaration that libexec is wrong or not the de-facto standard they themselves made up, which is not a reason). Because libexec doesn't exist on most other distributions, and systemd aims to offer consistent interfaces across distributions. Shouldn't binaries which are part of the external interface reside in /usr/sbin? No. /usr/sbin was used for sys-admin binaries, which were not required during bootup and not useful to ordinary users. Since Fedora has fallen into the UsrMove-trap, this argument is moot on Fedora. If the paths are not part of the interface, cross-distribution consistency shouldn't matter (as seen with git, for example). Correct. That's what the GCS are recommending libexecdir is for. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Fri, Dec 21, 2012 at 07:45:45AM +, Matthew Garrett wrote: > On Thu, Dec 20, 2012 at 11:24:09PM -0800, Toshio Kuratomi wrote: > > > 2) the systemd exceptions allows placing files in %{_prefix}/lib rather > > than %{_libdir} (the exceptions allow both putting the helper apps in there > > which would generally be okay with just a multilib exception and the unit > > files which are arch specific data and therefore usually go in %{_libdir} > > and therefore needed a special exception). The only reason people can drag > > %{_libexecdir} in to this discussion is that helper binaries are allowed in > > either %{_libdir} or %{_libexecdir}. In the context of forcing people to > > use a specific directory not specified by standards its meaningless because > > %{_libdir} is a suitable alternative. > > I think the libexec discussion is fairly relevant. Right now a package > can drop binaries in libexecdir and have a consistent path regardless of > the architecture, which is valuable. However, doing so results in > inconsistencies with other distributions which don't provide libexecdir. > This is clearly suboptimal, and it's reasonable to ask that the > packaging guidelines recognise that and handle it without requiring > additional exceptions - if a package wouldn't require an exception to > install binaries in libexec, it shouldn't need an exception install > binaries in lib. > I think the FPC has gotten pretty close to that. I reopened discussion in the FPC ticket about this because we recently approved packages which were exmpt from multilib from having to choose %{_libdir} over %{_prefix}/lib.for things like helper binaries (the guideline was brought up because of java but we passed a generic guideline update that can include helper binaries as well). However, people were concerned that packagers wouldn't necessarily judge correctly whether their packages were truly deserving to be exempt from multilib so the packages needed to be confirmed to be exempt from multilib requirements first. I've been calling that a "multilib exception" but perhaps "multilib exemption" would be clearer. It's not about this being an exceptional or special case. It's a case where if you fit certain criteria then you are exempt from certain restrictions. I have been unable to think of any reason that the types of binaries that belong in libexec would fail to be exempted from the considerations of multilib so I think we're in agreement about what the expected outcome should be for those types of files. However, you also miss my point. Adam's message was saying that the guidelines forced people to use libexecdir and then went on to point out the drawbacks of forcing specifically libexecdir on upstreams that didn't have that coded in. So, as I said, in that context it's meaningless to bring up arguments that are only addressed to libexecdir because %{_libdir} is an alternative. -Toshio pgplwCmVbWU3A.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2012-12-19)
On Thu, Dec 20, 2012 at 11:39:53PM -0800, Adam Williamson wrote: > I do apologize for somewhat derailing things towards the libexecdir > discussion, though, as I missed the point about the real question here > being between /lib/foo and $libdir/foo . The libexecdir thing is kind of > a tangent and probably should be split out if we're going to keep > talking about it. > I disagree with some of the assertions you made in this reply but I feel no need to Rooster Cogburn you so I'm willing to agree that it's a tangent :-) -Toshio pgpkZ9jkx0yb1.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel