Re: Should MariaDB touch my.cnf in %post?
On Thu, Feb 14, 2013 at 10:17:00AM -0500, Tom Lane wrote: Norvald H. Ryeng norvald.ry...@oracle.com writes: On Thu, 14 Feb 2013 08:07:22 +0100, Rahul Sundaram methe...@gmail.com Well, unless Oracle as upstream wants to get involved as downstream maintainers in Fedora as well. They did offer to do that but don't seem to have stepped up yet. Let's do it now, then. :-) We want to keep the MySQL package in Fedora and are willing to co-maintain or take over maintainership if nobody else will do it. We haven't really discussed this with the current maintainers yet, but from the discussions on this list it seems they're not interested in maintaining the package after F19. If us stepping up changes that, we are happy to co-maintain. The way this worked in the past (and still does on RHEL and some other distros) is that MySQL AB provided RPMs named MySQL, MySQL-server, etc, which simply conflicted with the Red Hat-supplied packages named mysql, mysql-server, etc. Perhaps it would be best to continue that naming tradition, ie establish a new Oracle-maintained Fedora package named MySQL, instead of figuring out how to transition maintainership of the mysql packages. This would give us some more wiggle room about managing the transition --- in particular, it's hard to see how we manage Obsoletes/Provides linkages in any sane fashion if the mysql package name continues in use. I think we're going to have to end up with a design in which mysql becomes essentially a virtual Provides name. It's all going to depend on what we want the upgrade experience to be like for people going from f18 to f19. I believe that FESCo punted it down the road since there wasn't an actual MySQL package maintainer at the time we decided to accept the Feature (just potential ones). On a fresh install from dvd, if someone wants a database, they'll probably get the choice of postgresql or mariadb. If someone installs one of our components that link against the client libraries, they'll get mariadb client libs installed. Those seem to fit pretty easily into having a default of mariadb while having both packages available in the repositories. What to do for people who are upgrading, though? Do we want people to be migrated to mariadb and then they need to purposefully switch over to mysql (by uninstalling mariadb packages and then installing the mysql package instead) or do we want them to get mysql since that's what they have installed presently? If we want the latter, the new maintainers may just need to take over the present mysql package. It will then update the mysql package from F18 if people have that installed. If we want the former, then having mysql become a virtual provide and MySQL become the mysql-providing package in Fedora seems like it will work pretty well. -Toshio pgpLveTrn17Zn.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
Norvald H. Ryeng norvald.ry...@oracle.com writes: On Thu, 14 Feb 2013 08:07:22 +0100, Rahul Sundaram methe...@gmail.com Well, unless Oracle as upstream wants to get involved as downstream maintainers in Fedora as well. They did offer to do that but don't seem to have stepped up yet. Let's do it now, then. :-) Hmm... I notice that you're not a packager in Fedora. Are any of ya'll that volunteered to take over the MySQL packaging Fedora Packagers? -Toshio pgpHGPkfuYtVT.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On 08/02/13 01:36 PM, Pete Travis wrote: On Feb 8, 2013 12:54 PM, Stephen John Smoogen smo...@gmail.com mailto:smo...@gmail.com wrote: . Two the fix is to upgrade to a very new version which will break everyone who upgrades until they (or the first person who gets to the website :) ) runs the upgrade mode.. which might not work due to either custom changes or the fact that it is a large upgrade change. -- Stephen J Smoogen. I haven't poked at mediawiki in a while, so please correct me if I'm wrong, but isn't it fairly self contained? I recall copying the content from /usr/share/ to /var/www/ then localizing. Having a new version shouldn't break existing deployments unless they are served out of /usr/share/, and that doesn't seem sane. The update would then be available, not imposed. I may be misunderstanding you, but I _think_ you've got the wrong end of the stick here. Fedora webapps are indeed packaged to be served out of /usr/share/whatever . They ship with /etc/httpd/conf.d config files which point to the /usr/share location where they are installed. This is all by policy and How It's Supposed To Be. Only files that absolutely need to be actually inside /var/www for some reason or another are supposed to be packaged there. In general, the idea is that webapp files are just static data files like any others and belong in /usr/share . See https://fedoraproject.org/wiki/Packaging:Guidelines#Web_Applications . You can copy the whole thing to somewhere else (e.g. /var/www) and nerf/adjust the conf.d file if you really want to use the Fedora package only as a base for your own deployment, but that's not the 'normal way'. In general you're expected to simply install the package and use it; that way you get the benefit of packaged updates. -- 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: ConsoleKit and esound retirement
Dan Mashal wrote: I will look at switching MATE Desktop to KDM or MDM if necessary (which I kind of wanted to do from the start, not the hugest fan of LightDM as a user personally). As much as I like KDM, I don't think it'd be the optimal choice for the MATE spin due to its dependencies (Qt and kdelibs). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 09/02/13 01:03 AM, Kevin Kofler wrote: Adam Williamson wrote: ...but as Rahul said, they all allow you to log in to any desktop. There seems to be a meme in this thread that GDM does not, but that's not correct, it does. The choice is not visible unless you actually have multiple desktops installed, but when you do, it gives you the option. Last I checked, GDM also hid that feature so well that many users missed it. In fact, unless this changed recently, when you input your user name, the option is NOT shown, it only appears after you confirm your user name, during the password prompt. Well, yes, that's true. How does that count as 'well hidden'? It's not like you can login without entering your password. -- 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: Should MariaDB touch my.cnf in %post?
Rahul Sundaram wrote: Well, unless Oracle as upstream wants to get involved as downstream maintainers in Fedora as well. They did offer to do that but don't seem to have stepped up yet. I really don't see what we have to gain from having 2 conflicting versions of MySQL in Fedora. It'd be a big mess not only for our users, but also for the software in Fedora which depends on it. For the same reason, I'm also opposed to the plan of having MySQL and MariaDB coexist for one release. We should really move to MariaDB with hard Obsoletes and then ship only that. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On Thu, Feb 14, 2013 at 7:33 AM, Brendan Jones wrote: On 02/14/2013 04:26 AM, Bruno Wolff III wrote: I was still planning on retiring xmms. It has no upstream support. The volume control has issues that I don't have time to figure out. esound can be disabled at build time - please do not retire it just yet. I can take it on if need be. Orcan, can you confirm that it still works? This is not working for me here. http://koji.fedoraproject.org/koji/taskinfo?taskID=4971729 It works here. I can play my OGG files. What doesn't work there? Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome-shell workspaces
On 10/02/13 06:03 AM, Kevin Kofler wrote: Olav Vitters wrote: This has been addressed various times. In brief: Advanced buttons do not work. They'll be clicked every time. Tweak tool provides a different guarantee of stability. For instance: if you change an option in System Settings and it results in a bug it must be fixed asap. At the same time, the sloppy focus option in Tweak tool is known to have issues. And to avoid misunderstandings: sloppy focus has less issues with every release. Having a separate tweak tool is a lame workaround for lack of settings in the official tools. The only reason such tweak tools exist on proprietary operating systems is because the proprietary companies don't want to officially support some functionality, so you need a third-party tool to enable the hidden settings. Having an official tweak tool is really really silly. Kevin, you work on a desktop which sufficiently represents your views. I think we're all aware that if we want fifteen thousand settings in the control panel, we can run KDE. Do you really believe you're going to convince the GNOME developers to turn GNOME into KDE with posts like the above? If not, what's the point of writing them? What do you expect your post to achieve? -- 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: Request for a firewalld secondary DHCP + PXEBOOT HOWTO
On 14 February 2013 19:16, Pete Travis li...@petetravis.com wrote: On Feb 14, 2013 12:03 PM, Pete Travis li...@petetravis.com wrote: On Feb 9, 2013 3:47 AM, Aaron Gray aaronngray.li...@gmail.com wrote: On 7 February 2013 16:41, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 02/07/2013 04:23 PM, Aaron Gray wrote: Can someone who knows firewalld please do a HOWTO to on setting up a secondary DHCP with DNS and HTTPS access for PXEBOOTing of Fedora18 please to go with the PXEBOOT HOWTO :- http://linux-sxs.org/internet_serving/pxeboot.html Hope someone can help, I put I message on the User List but got no response. Well what seems to be standards sysadmin practice with firewalld on servers is to disable it and enable iptables. Firewalld is aimed at desktop users and roaming hardware which makes zones useless concept for static server within an corporate infrastructure. So the missing steps for your guide simply are... systemctl stop firewalld* systemctl disable firewalld* systemctl enable iptables.service systemctl start iptables.service Jóhann, That's okay so far, sort of makes sense, but I though firewalld had equivalent functionality to iptables. Anyway I still need a HOWTO on setting up a secondary DHCP on a second Ethernet controller in order to run PXEBOOT. Thanks for the reply anyway, Aaron Have you looked at http://docs.fedoraproject.org/en-US/Fedora/17/html/Installation_Guide/sn-pxe-server-manual.html? If so, can you elaborate on what is missing? Oops, that should be http://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/sn-pxe-server-manual.html Pete, Yeah that's the easy bits, they need details too. The bit I have yet to find out how to do is to forward HTTPS and DNS ports between the primary internet network and the secondary DHCP BOOTP network on 192.168.1.x. I had this working on Shorewall but have taken the time to work it out on iptables or firewalld ideally and was hoping for a quick fix without having to reread iptables docs or learn firewalld configuration. Cheers for the link, Aaron -- 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: ConsoleKit and esound retirement
On Thu, Feb 14, 2013 at 9:16 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Thu, 14.02.13 03:26, Dan Mashal (dan.mas...@gmail.com) wrote: Not knowing too much about CK itself but out of concern for anyone that uses CK (including myself) I will be happy to take over ConsoleKit as the package maintainer for F19 if it means keeping it in for 1 more release to maintain compatibility. That's the spirit! I don't know too much about it, but I want to maintain it... But anyway, if that is indeed your wish, then I can hand it over. But please, don't let this stuff bitrot forever. That would help nobody. If you want to take care of it, fine, but please make sure the remaining packages using it get their stuff updated and fixed... What I want is that yum distro-sync removes the package eventually. Anyway, I will release the Rawhide/F19 version now in pkgdb, please take possession of it. It's yours now. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I have taken ownership of ConsoleKit for Fedora 19. Thanks, Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
HI On Thu, Feb 14, 2013 at 2:56 PM, Normunds Neimanis wrote: Hello world, I want to say thanks to Petr Šabata who provided great coaching on rpm tricks and sponsored me into packager group. Welcome to Fedora! If you have any questions, feel free to ask Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On Thu, Feb 14, 2013 at 3:53 AM, Norvald H. Ryeng wrote: On Thu, 14 Feb 2013 08:07:22 +0100, Rahul Sundaram On Wed, Feb 13, 2013 at 10:26 PM, Kevin Kofler wrote: MariaDB WILL replace MySQL on upgrades. Well, unless Oracle as upstream wants to get involved as downstream maintainers in Fedora as well. They did offer to do that but don't seem to have stepped up yet. Let's do it now, then. :-) We want to keep the MySQL package in Fedora and are willing to co-maintain or take over maintainership if nobody else will do it. We haven't really discussed this with the current maintainers yet, but from the discussions on this list it seems they're not interested in maintaining the package after F19. If us stepping up changes that, we are happy to co-maintain. Any input on how we can and should proceed is welcome. The steps to become a Fedora package maintainer is well documented in the wiki: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers The package is not banned. Nobody is stopping a potential MySQL maintainer in Fedora. Best, Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unable to push update of emacs-24.2-6.fc18 to stable
On 13/02/13 07:38 PM, Kevin Kofler wrote: Jochen Schmitt wrote: He explained me, that he also unable to push the package to the stable repository and told me, that this package is in crithpath and may improvement of an proventester. Why the heck is Emacs in the critical path in the first place??? I'm not sure, it does seem like an odd one. It's not directly in any critpath group and I can't see any obvious suspects from repoquery --whatrequires emacs, but it must be some odd dep chain. -- 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: ConsoleKit and esound retirement
On 13/02/13 10:15 AM, DJ Delorie wrote: (well, more like crap, since I still haven't figured out how to get pulseaudio to use my digital audio outputs). Really? It's not that hard. It's either a device or a profile right on the very first tab of GNOME sound properties. If you're using pavucontrol, devices are on the 'Output Devices' tab, profiles are on the 'Configuration' tab. It's rather easier than doing the same thing with ALSA, really. -- 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: ConsoleKit and esound retirement
On 02/14/2013 06:35 PM, Hans de Goede wrote: Hi, On 02/14/2013 01:28 PM, Bastien Nocera wrote: On Thu, 2013-02-14 at 10:53 +0100, Michael Schwendt wrote: On Thu, 14 Feb 2013 03:49:23 +0100, Kevin Kofler wrote: DJ Delorie wrote: Disadvantage, if you ask me. First thing audacious did was spew random errors to the screen and change my Firefox and emacs cursors. So I suspect that Audacious started gnome-settings-daemon. It doesn't do that when I use OpenBox instead of GNOME, so OpenBox does not auto-spawn g-s-d. However, one of its plug-ins talks to DBus (org.gnome.SettingsDaemon) for GNOME media player keyboard shortcuts. That plug-in is enabled by default and by request, and anyone not running a compatible environment can easily switch it off in the preferences. Or you could fix the plugin to not auto-start the daemon so we don't get blamed for Audacious bugs... Actually after seeing this thread I was planning on sending a mail to ask people how to fix this. I guess that dbus-activation causes g-s-d to start when the audacious tries to talk to it. Rather then a less the friendly worded reply, it would be actually helpful if you could tell us (pointer to a code example would be a bonus) how to talk to a dbus interface without causing dbus-activation to trigger. Nothing fancy: http://developer.gnome.org/gio/unstable/GDBusConnection.html#GDBusCallFlags or http://dbus.freedesktop.org/doc/api/html/group__DBusMessage.html#ga1596d92a8d604f954b48c7410263d2f0 Obviously I can't list every single language or binding here. Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On Thu, 2013-02-14 at 20:39 +0100, Michael Schwendt wrote: On Thu, 14 Feb 2013 13:28:57 +0100, Bastien Nocera wrote: On Thu, 2013-02-14 at 10:53 +0100, Michael Schwendt wrote: On Thu, 14 Feb 2013 03:49:23 +0100, Kevin Kofler wrote: DJ Delorie wrote: Disadvantage, if you ask me. First thing audacious did was spew random errors to the screen and change my Firefox and emacs cursors. So I suspect that Audacious started gnome-settings-daemon. It doesn't do that when I use OpenBox instead of GNOME, so OpenBox does not auto-spawn g-s-d. However, one of its plug-ins talks to DBus (org.gnome.SettingsDaemon) for GNOME media player keyboard shortcuts. That plug-in is enabled by default and by request, and anyone not running a compatible environment can easily switch it off in the preferences. Or you could fix the plugin to not auto-start the daemon so we don't get blamed for Audacious bugs... Could you tell me a test environment where auto-starting the daemon is reproducible? Then I might take a look at trying to avoid it. It should be auto-started when your app pokes at the not-yet-spawned well-known D-Bus name. As pointed out above, with Openbox the daemon is not started automatically when starting Audacious. I'm stuck there. The puzzle is incomplete. Is there a session D-Bus running in your session? I don't know how it could not start. The implementation of the plugin looks dubious in the bottom half of gnome_remote_init() -- I dunno why it does the 2nd dbus_g_proxy_call -- https://github.com/audacious-media-player/audacious-plugins/blob/master/src/gnomeshortcuts/gnomeshortcuts.c but other than that the only thing I could think of is dbus system activation as there's nothing else that would start the daemon automatically. You make a call to GrabMediaPlayerKeys() on a well-known D-Bus name that isn't spawned. D-Bus will gladly allow you to make the call and spawn the service for you. You should use dbus_g_proxy_new_for_name_owner() instead, which will round-trip and check whether the service exists. Hopefully it should stop it from auto-spawning. GDBus has the separate and more practical G_DBUS_CALL_FLAGS_NO_AUTO_START flag to be used. Cheers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Data-Validate-Domain/f18] Initial import (#904329).
Summary of changes: fdb3ace... Initial import (#904329). (*) (*) This commit already existed in another branch; no separate mail sent -- 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
[perl-Shell/f18] Initial import (#904331).
Summary of changes: cb65684... Initial import (#904331). (*) (*) This commit already existed in another branch; no separate mail sent -- 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: ConsoleKit and esound retirement
On 13 Feb 2013 22:50, Matthew Miller mat...@fedoraproject.org wrote: On Wed, Feb 13, 2013 at 11:38:42PM +0100, Michael Scherer wrote: However, I have already removed consolekit on my F18 without any notable issue, so I do not think any breakage would be blocking. We have the whole F19 cycle to find and detect the few packages needing fix. Is this the kind of thing that would have been better done as a feature, similar to the Usermode Migration feature? It was a feature back about f17 (search for ckremoval) and the remaining are the packages are ones that didn't adhere. This has been planned and discussed for a number of releases maybe as far back as f15 so maintainers need to step up and deal with it. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On 02/14/2013 01:07 PM, Chris wrote: 2013/2/14 Kevin Koflerkevin.kof...@chello.at: Jóhann B. Guðmundsson wrote: Surely you are not honestly consider replacing mysql installation with mariadb on upgrades? Have you missed the discussion? MariaDB is a drop-in replacement for MySQL, it will REPLACE MySQL in Fedora repositories, and we like to keep existing setups WORKING (e.g. we don't want to break Akonadi, which relies on an autospawned mysql-server, or Amarok, which relies on mysql-embedded) and supplied with security updates (which would not be the case for an unmaintained MySQL RPM from an older Fedora release that just sits on your disk), so of course, MariaDB WILL replace MySQL on upgrades. .. unless you do a little change in your yum configuration: +exclude=mariadb* Then the replacement won't happen. In other words: It is not possible to install mysql on ferdora 19??? Fedora and freedom??? Freedom is to have the choice between mysql and mariadb! See the steps on the feature page: https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB#Steps_to_replace_MariaDB_with_the_original_MySQL_in_Fedora_19_.28rawhide.29 Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On 02/13/2013 02:16 PM, Jóhann B. Guðmundsson wrote: I for one would not want to find out that my mysql install would have been replaced with mariadb on upgrade ( or visa versa ) The discussion already started several weeks ago but we still need any feedback. What are you particular concerns? AFAIK, admins usually don't like this change because they are worried of: 1) different name 2) the upgrade 3) different API/ABI 4) more bugs However, these are not the issues we should worried, because: 1) only package name is different; the structure and content of rpms and file names are the same as in mysql 2) no special steps need to be done, it's really drop-in replacement 3) API/ABI is preserved when comparing mysql-5.5 and mariadb-5.5 4) the opposite is true -- several bugs are fixed in mariadb and there are much more test cases; just try google to find admin's experiences with mariadb: you'll usually find more stable and faster answers. At least I did. So again, if you have some concrete concerns, let us know, please. Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[pkgdb] perl-IPC-Cmd ownership changed
Package perl-IPC-Cmd in Fedora devel is now owned by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-IPC-Cmd -- 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: Should MariaDB touch my.cnf in %post?
On 02/14/2013 06:28 PM, Samuel Sieb wrote: On 02/14/2013 04:07 AM, Chris wrote: In other words: It is not possible to install mysql on ferdora 19??? Fedora and freedom??? Freedom is to have the choice between mysql and mariadb! Please read the other threads before exploding like this. To summarize, mariadb will replace mysql as the mysql-like db in Fedora 19. However, if someone steps up to package mysql for F19, then it will also be available, just not installed by default. In F19, there still *will* be mysql-5.5.x. What will happen in F20 and later is not clear yet. Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File IPC-Cmd-0.78.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-IPC-Cmd: c9379038439420228567dc3f0e34cd24 IPC-Cmd-0.78.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
[perl-IPC-Cmd] Import
commit 959e51b68497db0336c1c2f973f0271830e9d176
Author: Petr Písař ppi...@redhat.com
Date: Fri Feb 15 10:18:51 2013 +0100
Import
.gitignore|1 +
dead.package |1 -
perl-IPC-Cmd.spec | 67 +
sources |1 +
4 files changed, 69 insertions(+), 1 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 881551c..037f637 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
IPC-Cmd-0.40.tar.gz
+/IPC-Cmd-0.78.tar.gz
diff --git a/perl-IPC-Cmd.spec b/perl-IPC-Cmd.spec
new file mode 100644
index 000..77383b4
--- /dev/null
+++ b/perl-IPC-Cmd.spec
@@ -0,0 +1,67 @@
+Name: perl-IPC-Cmd
+Version:0.78
+Release:1%{?dist}
+Summary:Finding and running system commands made easy
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/IPC-Cmd/
+Source0:
http://www.cpan.org/authors/id/B/BI/BINGOS/IPC-Cmd-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl
+BuildRequires: perl(ExtUtils::MakeMaker)
+# Run-time:
+BuildRequires: perl(Carp)
+BuildRequires: perl(Config)
+BuildRequires: perl(constant)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(Locale::Maketext::Simple)
+BuildRequires: perl(Module::Load::Conditional)
+BuildRequires: perl(Params::Check) = 0.20
+BuildRequires: perl(POSIX)
+BuildRequires: perl(Socket)
+BuildRequires: perl(strict)
+BuildRequires: perl(Symbol)
+BuildRequires: perl(Text::ParseWords)
+BuildRequires: perl(vars)
+# Tests:
+# output.pl/IO::Handle not used
+BuildRequires: perl(lib)
+BuildRequires: perl(Test::More)
+# output.pl/warnings not used
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(Config)
+Requires: perl(ExtUtils::MakeMaker)
+Requires: perl(Params::Check) = 0.20
+Requires: perl(POSIX)
+
+# Filter under-specified dependencies
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(Params::Check\\)$
+
+%description
+IPC::Cmd allows you to run commands platform independently, interactively
+if desired, but have them still work.
+
+%prep
+%setup -q -n IPC-Cmd-%{version}
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc CHANGES README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Fri Feb 08 2013 Petr Pisar ppi...@redhat.com 0.78-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
new file mode 100644
index 000..cb5ec5b
--- /dev/null
+++ b/sources
@@ -0,0 +1 @@
+c9379038439420228567dc3f0e34cd24 IPC-Cmd-0.78.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
File Module-Load-Conditional-0.54.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Module-Load-Conditional: 626d90b25bd461388e4706ff7a631d72 Module-Load-Conditional-0.54.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
[perl-Module-Load-Conditional] Import
commit 94faa4dcfdec033dcd850f90a7ede4558de6d257
Author: Petr Písař ppi...@redhat.com
Date: Fri Feb 15 10:22:00 2013 +0100
Import
.gitignore|1 +
dead.package |1 -
perl-Module-Load-Conditional.spec | 67 +
sources |1 +
4 files changed, 69 insertions(+), 1 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e070e9a..cd12dc8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Module-Load-Conditional-0.24.tar.gz
+/Module-Load-Conditional-0.54.tar.gz
diff --git a/perl-Module-Load-Conditional.spec
b/perl-Module-Load-Conditional.spec
new file mode 100644
index 000..01d47e4
--- /dev/null
+++ b/perl-Module-Load-Conditional.spec
@@ -0,0 +1,67 @@
+Name: perl-Module-Load-Conditional
+Version:0.54
+Release:1%{?dist}
+Summary:Looking up module information and loading at run-time
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Module-Load-Conditional/
+Source0:
http://www.cpan.org/authors/id/B/BI/BINGOS/Module-Load-Conditional-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(strict)
+# Run-time:
+BuildRequires: perl(Carp)
+BuildRequires: perl(Config)
+BuildRequires: perl(constant)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(FileHandle)
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(Locale::Maketext::Simple)
+# Module::CoreList 2.22 not needed when running tests
+BuildRequires: perl(Module::Load) = 0.11
+BuildRequires: perl(Module::Metadata) = 1.05
+BuildRequires: perl(Params::Check)
+BuildRequires: perl(vars)
+BuildRequires: perl(version) = 0.69
+# Tests:
+BuildRequires: perl(FindBin)
+BuildRequires: perl(lib)
+BuildRequires: perl(Test::More)
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(Config)
+Requires: perl(Module::CoreList) = 2.22
+Requires: perl(Module::Load) = 0.11
+Requires: perl(Module::Metadata) = 1.05
+Requires: perl(version) = 0.69
+
+# Filter under-specified dependencies
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\((Module::Load|Module::Metadata|version)\\)$
+
+%description
+This module provides simple ways to query and possibly load any of the modules
+you have installed on your system during run-time.
+
+%prep
+%setup -q -n Module-Load-Conditional-%{version}
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc CHANGES README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Fri Jan 25 2013 Petr Pisar ppi...@redhat.com 0.54-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
new file mode 100644
index 000..0a5a241
--- /dev/null
+++ b/sources
@@ -0,0 +1 @@
+626d90b25bd461388e4706ff7a631d72 Module-Load-Conditional-0.54.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
[pkgdb] perl-Module-Load-Conditional ownership changed
Package perl-Module-Load-Conditional in Fedora devel is now owned by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Module-Load-Conditional -- 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: Should MariaDB touch my.cnf in %post?
On Fri, 15 Feb 2013 03:30:01 +0100, Toshio Kuratomi a.bad...@gmail.com wrote: Norvald H. Ryeng norvald.ry...@oracle.com writes: On Thu, 14 Feb 2013 08:07:22 +0100, Rahul Sundaram methe...@gmail.com Well, unless Oracle as upstream wants to get involved as downstream maintainers in Fedora as well. They did offer to do that but don't seem to have stepped up yet. Let's do it now, then. :-) Hmm... I notice that you're not a packager in Fedora. Are any of ya'll that volunteered to take over the MySQL packaging Fedora Packagers? Neither Andrew or I will do the packaging. I'll be involved, but someone from our build team will do the actual packaging. None of us are Fedora packagers, so I guess we'll need someone to review our packaging and sponsor us. Regards, Norvald H. Ryeng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On Thu, 14 Feb 2013 18:35:23 +0100, Hans de Goede wrote: On Thu, 14 Feb 2013 03:49:23 +0100, Kevin Kofler wrote: DJ Delorie wrote: Disadvantage, if you ask me. First thing audacious did was spew random errors to the screen and change my Firefox and emacs cursors. So I suspect that Audacious started gnome-settings-daemon. It doesn't do that when I use OpenBox instead of GNOME, so OpenBox does not auto-spawn g-s-d. However, one of its plug-ins talks to DBus (org.gnome.SettingsDaemon) for GNOME media player keyboard shortcuts. That plug-in is enabled by default and by request, and anyone not running a compatible environment can easily switch it off in the preferences. Or you could fix the plugin to not auto-start the daemon so we don't get blamed for Audacious bugs... Actually after seeing this thread I was planning on sending a mail to ask people how to fix this. I guess that dbus-activation causes g-s-d to start when the audacious tries to talk to it. Rather then a less the friendly worded reply, it would be actually helpful if you could tell us (pointer to a code example would be a bonus) how to talk to a dbus interface without causing dbus-activation to trigger. What I checked in ~13 hours ago is this: http://pkgs.fedoraproject.org/cgit/audacious-plugins.git/commit/?id=55972c07f34e43db3b9e24ca4918ac5bd8a39a46 Reviews/feedback appreciated. Preferably, I'd still like to see a test-case where g-s-d would be started automatically. Chasing ghosts is not so funny. -- Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc7.git2.1.fc19.x86_64 loadavg: 0.25 0.37 0.43 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
Hi, On 02/15/2013 07:57 AM, Stef Walter wrote: On 02/14/2013 06:35 PM, Hans de Goede wrote: Hi, On 02/14/2013 01:28 PM, Bastien Nocera wrote: On Thu, 2013-02-14 at 10:53 +0100, Michael Schwendt wrote: On Thu, 14 Feb 2013 03:49:23 +0100, Kevin Kofler wrote: DJ Delorie wrote: Disadvantage, if you ask me. First thing audacious did was spew random errors to the screen and change my Firefox and emacs cursors. So I suspect that Audacious started gnome-settings-daemon. It doesn't do that when I use OpenBox instead of GNOME, so OpenBox does not auto-spawn g-s-d. However, one of its plug-ins talks to DBus (org.gnome.SettingsDaemon) for GNOME media player keyboard shortcuts. That plug-in is enabled by default and by request, and anyone not running a compatible environment can easily switch it off in the preferences. Or you could fix the plugin to not auto-start the daemon so we don't get blamed for Audacious bugs... Actually after seeing this thread I was planning on sending a mail to ask people how to fix this. I guess that dbus-activation causes g-s-d to start when the audacious tries to talk to it. Rather then a less the friendly worded reply, it would be actually helpful if you could tell us (pointer to a code example would be a bonus) how to talk to a dbus interface without causing dbus-activation to trigger. Nothing fancy: http://developer.gnome.org/gio/unstable/GDBusConnection.html#GDBusCallFlags or http://dbus.freedesktop.org/doc/api/html/group__DBusMessage.html#ga1596d92a8d604f954b48c7410263d2f0 Thanks, that is likely / hopefully exactly what we're looking for. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib/debug ownership
On Thu, 14 Feb 2013 20:33:46 +0100, Alec Leamas wrote: PS. Yes, I repeat this message. Looks like it wasn't sent somehow :( As I had replied to the earlier message ;) here just a mention that I've reported the mispackaged nacl-devel: https://bugzilla.redhat.com/911405 -- Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc7.git2.1.fc19.x86_64 loadavg: 0.32 0.13 0.23 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On Thu, 14 Feb 2013 18:16:56 +0100, Lennart Poettering wrote: What I want is that yum distro-sync removes the package eventually. Then it will need an Obsoletes tag somewhere else to get rid of any installed CK packages. yum distro-sync doesn't remove orphans. It only upgrades/downgrades packages as necessary to match what's in the repos. For an up-to-date installation, package-cleanup --orphans and yum list extras show which installed packages are not available in any repo. Users would need to uninstall them manually. -- Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc7.git2.1.fc19.x86_64 loadavg: 0.22 0.30 0.27 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 16 EOL Bugzilla Closure - strange behavior?
Hi! Here is an example: https://bugzilla.redhat.com/show_bug.cgi?id=736498 I filled this bug during the F-16 Graphics test week. After the Fedora EOL reminder and before the bug was closed, I tried to reproduce it on F-17 and I couldn't. Thus I marked the bug as CLOSED CURRENTRELEASE. After a couple of hours the Fedora EOL script changed the Resolution to WONTFIX: https://bugzilla.redhat.com/show_activity.cgi?id=736498 Another example: https://bugzilla.redhat.com/show_bug.cgi?id=739315 This is an ABRT bug report that was originally reported against gnome-shell on F-16. I encountered it with gnome-shell on F-17 (https://bugzilla.redhat.com/show_bug.cgi?id=739315#c72) and some people encountered it on F-18. I bumped the version to 18, however, after a couple of hours the Fedora EOL script closed it as WONTFIX. Could someone explain this behavior? Thanks and best regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On 02/15/2013 11:27 AM, Jóhann B. Guðmundsson wrote: Mariadb is evolving into it's own product with it's own feature set [1] thus should be treated as different product it should have it's own .cnf file it's own configuration directory which is best in the long run ( from my pov ). Then it should also need separate binaries, libraries, datadir, socket, ... I'm not saying it is so bad idea, but it could be taken into account only in the upstream, we really cannot do something like that downstream. And we'd probably lost the drop-in feature and upgrade would be even more painful. If I install a component what ever component I then upgrade I expect that a) I get the latest and the greatest release of that component b) still be running the same release of the component if not newer release is found or if the component is no longer being shipped. I dont expect a) that the component gets removed on upgrade, b) that I magically somehow get migrated to a different product. Let me take other examples of what I'm trying to refer to here with regards to expected behavior. If you would install libreoffice would you expect to be running openoffice after upgrade or would you expect to be starting libreoffice after the upgrade? In case it would be discussed, compatible, documented, noted in the release notes and we have a good reason to do so -- then why not? If you install mate or cinnamon or unity for that matter would you expect to be migrated and running Gnome 3.x after upgrade or would you expect to be continuing to use and run what got forked or based of it. This is already too extreme, we cannot compare Gnome forks and MySQL forks. It's really a different scenario. One usage scenario one simple question If an user wants to run both those database solution on his server wont those two overlap as in can for exaxmple users be asssured that the changes that they make to their my.cnf wont get picked up by mariadb when it gets started etc. Running both packages on the same server is not currently available, because they conflict. If somebody does it in any way, which means to separate files, sockets, ... then he should be able to separate config files as well. Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 911536] perl-Locale-SubCountry-1.61 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=911536 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Locale-SubCountry-1.61 ||-1.fc19 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=6W5nXWeJhga=cc_unsubscribe -- 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
[Bug 911536] perl-Locale-SubCountry-1.61 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=911536 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-Locale-SubCountry-1.61-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/perl-Locale-SubCountry-1.61-1.fc18 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=psTtQqXXYfa=cc_unsubscribe -- 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
[Bug 910685] perl-Locale-SubCountry-1.60 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=910685 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-Locale-SubCountry-1.61-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/perl-Locale-SubCountry-1.61-1.fc18 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=fzXaQRvKxHa=cc_unsubscribe -- 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
[Bug 911536] perl-Locale-SubCountry-1.61 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=911536 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-Locale-SubCountry-1.61-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/perl-Locale-SubCountry-1.61-1.fc17 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=EU7SPUcfuLa=cc_unsubscribe -- 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
[Bug 910685] perl-Locale-SubCountry-1.60 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=910685 --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- perl-Locale-SubCountry-1.61-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/perl-Locale-SubCountry-1.61-1.fc17 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=s8F9sv0prPa=cc_unsubscribe -- 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: Should MariaDB touch my.cnf in %post?
On Fri, Feb 15, 2013 at 3:28 AM, Toshio Kuratomi a.bad...@gmail.com wrote: It's all going to depend on what we want the upgrade experience to be like for people going from f18 to f19. I believe that FESCo punted it down the road since there wasn't an actual MySQL package maintainer at the time we decided to accept the Feature (just potential ones). The feature page that was approved explicitly says In Fedora 19, MariaDB packages obsoletes MySQL. That means that all packages of MySQL will be automatically replaced by corresponding MariaDB pacakges during update. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib/debug ownership
On 02/14/2013 11:19 PM, Michael Schwendt wrote:
On Thu, 14 Feb 2013 16:36:03 +0100, Alec Leamas wrote:
Running some automated tests I stumble over the debug directories. E. g.,
$ repoquery -qf /usr/lib/debug
shows 45 owners on current F18. Other directories under /usr/lib/debug
have a similar situation with many owners..
I note that /usr/src/debug is owned by filesystem, but filesystem does
not own /usr/lib/debug.
Is all this on purpose, or is something broken here? Thinking about it,
we never require anything for the debug package AFAICT. What's the story?
It depends on what the package stores below /usr/lib/debug.
Here's one that is mispackaged:
# repoquery -qf /usr/lib/debug
nacl-devel-0:20110221-3.fc19.i686
- http://koji.fedoraproject.org/koji/rpminfo?rpmID=3336721
It includes the -debuginfo package contents in the -devel package, most
likely because it does a lazy'n'risky %{_libdir}/* in its %files section.
Thanks for reply... Still, I'm puzzled about 45 packages owning
/usr/lib/debug, none of them the filesystem package. This looks weird,
although I don't grasp the consequences (if any).
A normal review rule says that a package should not own a directory
owned by another package. Does this apply to /usr/lib/debug (as well as
/usr/src/debug, used occasionally)? If so, who is the rightful owner
of these directories?
Still confused, but on a higher level...
--alec
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On 02/15/2013 01:52 PM, Honza Horak wrote: On 02/15/2013 01:24 PM, Jóhann B. Guðmundsson wrote: On 02/15/2013 09:09 AM, Honza Horak wrote: So again, if you have some concrete concerns, let us know, please. What are the plans to handle the name change in the daemon startup ( systemd unit ) in the migration faze to prevent users having to find out on their own how to start mariadb along and preventing every puppet/chef/python/scripts and other things that the administrator has tied to service mysql start/stop/restart and or systemctl start/stop/restart mysqld.service along with potentially any other infrastructure bits tied to mysql from breaking? JBG There is no change, the unit file is still mysqld.service. Honza Forgot to include list, just re-sending.. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On Thu, Feb 14, 2013 at 10:17:00AM -0500, Tom Lane wrote: The way this worked in the past (and still does on RHEL and some other distros) is that MySQL AB provided RPMs named MySQL, MySQL-server, etc, which simply conflicted with the Red Hat-supplied packages named mysql, mysql-server, etc. Perhaps it would be best to continue that naming tradition, ie establish a new Oracle-maintained Fedora package named MySQL, instead of figuring out how to transition maintainership of the mysql packages. This would give us some more wiggle room about managing the transition --- in particular, it's hard to see how we manage Obsoletes/Provides linkages in any sane fashion if the mysql package name continues in use. I think we're going to have to end up with a design in which mysql becomes essentially a virtual Provides name. I'm quite amazed at how MariaDB is allowed to do this takeover of mysql in fedora. Why can't MariaDB use it's own configuration files, own datadir, own socket, own binary names, etc.. ? I'm no Oracle or Mysql fan, but as far as I see it Oracle/mysql is the original branch of the mysql project, and I think a competing fork should do it's best not to conflict with it. No effort not to conflict seems to be happening here, rather the opposite. What happens when MariaDB and Mysql start diverging? Will it be impossible to have a client that connects to both mysql and mariadb servers ? -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On 15/02/13 03:02, Adam Williamson wrote: On 08/02/13 01:36 PM, Pete Travis wrote: I haven't poked at mediawiki in a while, so please correct me if I'm wrong, but isn't it fairly self contained? I recall copying the content from /usr/share/ to /var/www/ then localizing. Having a new version shouldn't break existing deployments unless they are served out of /usr/share/, and that doesn't seem sane. The update would then be available, not imposed. I may be misunderstanding you, but I _think_ you've got the wrong end of the stick here. Fedora webapps are indeed packaged to be served out of /usr/share/whatever . They ship with /etc/httpd/conf.d config files which point to the /usr/share location where they are installed. This is all by policy and How It's Supposed To Be. Only files that absolutely need to be actually inside /var/www for some reason or another are supposed to be packaged there. In general, the idea is that webapp files are just static data files like any others and belong in /usr/share . See https://fedoraproject.org/wiki/Packaging:Guidelines#Web_Applications . You're both kind of right - the README.RPM file that comes in the mediawiki package tells you to run mw-createinstance path to create an instance and that sets up a document root in the specified path by both copying some files, like LocalSettings.php, and symlinking others to the /usr/share code. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On 02/15/2013 12:39 PM, Jóhann B. Guðmundsson wrote: On 02/15/2013 11:07 AM, Honza Horak wrote: Then it should also need separate binaries, libraries, datadir, socket, ... I'm not saying it is so bad idea, but it could be taken into account only in the upstream, we really cannot do something like that downstream. And we'd probably lost the drop-in feature and upgrade would be even more painful. How so? If fesco does not ban mysql from the distribution then upgrades should not be painful because you would simply upgrade to the latest mysql release in the distribution. Sorry, I wrote it at a bit unclearly, by upgrade I meant the replacement from MySQL-MariaDB. If mysql on the other hand is banned in the distribution then arguably it makes sense to migrate those instances to the latest release of mariadb instead thou I personally would not recommended it then either but rather prefer it would be left alone then replaced by admin himself after upgrade. This will be indeed possible. If admin reads the release notes before upgrading to F19 (which I suppose if they mind their data), he will be aware of the change and will be able to disable mariadb packages for the time of upgrade in order to not replace mysql. Then, anytime later, he will be able to do the manual replacement. snip In case it would be discussed, compatible, documented, noted in the release notes and we have a good reason to do so -- then why not? Different product different characteristics I still see the differences between MariaDB and MySQL to be very little. If you install mate or cinnamon or unity for that matter would you expect to be migrated and running Gnome 3.x after upgrade or would you expect to be continuing to use and run what got forked or based of it. This is already too extreme, we cannot compare Gnome forks and MySQL forks. It's really a different scenario. Same fundamental rules apply as I see it just different ( fork ) components. So what about upstart-systemd or Gnome2-Gnome3 switches? These also took place without users interaction and it was not without problems. OK, they aren't forks, just new features. Why not take MariaDB just as a new feature? Running both packages on the same server is not currently available, because they conflict. If somebody does it in any way, which means to separate files, sockets, ... then he should be able to separate config files as well. Is that not an clear indicator that the replacement should not take place on upgrade but rather be left up to the administrator to do manually ( at least while we still ship mysql ) and we have mysql and mariadb conflict with each other on packaging level? Well, in case we wouldn't obsolete mysql -- then either we could do it in F20 and have the same problem a few months later or don't do it at all and then we would have troubles with CVE and unfriendly upstream forever. Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On 02/15/2013 04:13 AM, Kevin Kofler wrote: Rahul Sundaram wrote: Well, unless Oracle as upstream wants to get involved as downstream maintainers in Fedora as well. They did offer to do that but don't seem to have stepped up yet. I really don't see what we have to gain from having 2 conflicting versions of MySQL in Fedora. It'd be a big mess not only for our users, but also for the software in Fedora which depends on it. For the same reason, I'm also opposed to the plan of having MySQL and MariaDB coexist for one release. We should really move to MariaDB with hard Obsoletes and then ship only that. One word: Competition. MySQL 5.6 has made significant performance improvements and both MySQL and MariaDB have features that the other doesn't have so while they are compatible for the most part they are not identical and if you rely on a MySQL 5.6 feature that MariaDB doesn't support than you'd obviously prefer to have MySQL available as an option. Also MySQL 5.6 gains some of its speed through commercial extensions (like e.g. the thread pool). Since these cannot be packaged in Fedora you will be able to make a better/more fair comparison between the two based on the same Platform (Fedora). All of this benefits Fedoras users. Besides I don't think excluding a specific piece of software without technical reasons would set a somewhat dangerous precedent. As long as there are people willing to maintain these packages and the packages themselves follow all necessary guidelines they should be allowed to do so. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xmms being retired as of F19
On Wed, Feb 13, 2013 at 10:01:52 -0600, Bruno Wolff III br...@wolff.to wrote: I plan to retire xmms before F20 is branched as it is causing issues with the removal of some other obsolete packages and it has no upstream support. If anyone has objections to this please speak up soon. There were objections so xmms will stay around. Also I was confused, I have xmms-pulse not the base xmms package. But since people want xmms, I'll keep xmms-pulse around as well. Though I could use help with the volume resetting every start up issue if someone wants to look at it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
Hi On Thu, Feb 14, 2013 at 10:13 PM, Kevin Kofler wrote: I really don't see what we have to gain from having 2 conflicting versions of MySQL in Fedora. We never had the culture of questioning why anyone should include any package as long as it meets the current guidelines. As long as there are maintainers who are willing to deal with it, I don't see why you feel the need to protest. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Scope-Upper] update to 0.22
commit c94116e175ecb1f7d4881105ef57c968214dc0c2
Author: Iain Arnell iarn...@gmail.com
Date: Fri Feb 15 08:24:13 2013 -0700
update to 0.22
perl-Scope-Upper.spec | 15 +++
1 files changed, 7 insertions(+), 8 deletions(-)
---
diff --git a/perl-Scope-Upper.spec b/perl-Scope-Upper.spec
index 9ec98e6..f4cd790 100644
--- a/perl-Scope-Upper.spec
+++ b/perl-Scope-Upper.spec
@@ -1,7 +1,7 @@
Name: perl-Scope-Upper
Summary:Act on upper scopes
-Version:0.21
-Release:2%{?dist}
+Version:0.22
+Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/V/VP/VPIT/Scope-Upper-%{version}.tar.gz
@@ -9,6 +9,7 @@ URL:http://search.cpan.org/dist/Scope-Upper
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildRequires: perl(base)
+BuildRequires: perl(Config)
BuildRequires: perl(Exporter)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::Kwalitee)
@@ -21,11 +22,6 @@ BuildRequires: perl(XSLoader)
Requires: perl(Exporter)
Requires: perl(XSLoader)
-# obsolete/provide old tests subpackage
-# can be removed during F19 development cycle
-Obsoletes: %{name}-tests 0.16-3
-Provides: %{name}-tests = %{version}-%{release}
-
%{?perl_default_filter}
%description
@@ -48,7 +44,6 @@ make %{?_smp_mflags}
make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'
-find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
@@ -62,6 +57,10 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Fri Feb 15 2013 Iain Arnell iarn...@gmail.com 0.22-1
+- udpate to latest upstream version
+- drop old tests sub-package obsoletes/provides
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.21-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
--
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: Should MariaDB touch my.cnf in %post?
Am 14.02.2013 16:17, schrieb Tom Lane: Norvald H. Ryeng norvald.ry...@oracle.com writes: On Thu, 14 Feb 2013 08:07:22 +0100, Rahul Sundaram methe...@gmail.com Well, unless Oracle as upstream wants to get involved as downstream maintainers in Fedora as well. They did offer to do that but don't seem to have stepped up yet. Let's do it now, then. :-) We want to keep the MySQL package in Fedora and are willing to co-maintain or take over maintainership if nobody else will do it. We haven't really discussed this with the current maintainers yet, but from the discussions on this list it seems they're not interested in maintaining the package after F19. If us stepping up changes that, we are happy to co-maintain. The way this worked in the past (and still does on RHEL and some other distros) is that MySQL AB provided RPMs named MySQL, MySQL-server, etc, which simply conflicted with the Red Hat-supplied packages named mysql, mysql-server, etc. Perhaps it would be best to continue that naming tradition, ie establish a new Oracle-maintained Fedora package named MySQL, instead of figuring out how to transition maintainership of the mysql packages. This would give us some more wiggle room about managing the transition --- in particular, it's hard to see how we manage Obsoletes/Provides linkages in any sane fashion if the mysql package name continues in use. I think we're going to have to end up with a design in which mysql becomes essentially a virtual Provides name. a sane decision would be to revert the whole MaridaDB decision if people of oracle are willing to maintain MySQL in Fedora damned do we need to replace and change anything all of the time? WHAT are the real problems with MySQL? that is works? well, the Oracle behavior was not perfect in the recent months starting with http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-31.html which was not so long ago NOT EMPTY before the release, but hey give them a chance, there where enough replacements in the last few years for more than one lifetime signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Request for a firewalld secondary DHCP + PXEBOOT HOWTO
On Feb 15, 2013 6:39 AM, Aaron Gray aaronngray.li...@gmail.com wrote: Pete, Yeah that's the easy bits, they need details too. The bit I have yet to find out how to do is to forward HTTPS and DNS ports between the primary internet network and the secondary DHCP BOOTP network on 192.168.1.x. I had this working on Shorewall but have taken the time to work it out on iptables or firewalld ideally and was hoping for a quick fix without having to reread iptables docs or learn firewalld configuration. Cheers for the link, Aaron Port forwarding is simply and clearly documented in 'man firewall-cmd'. Unless you're looking for masquerading, which is easily done per the man page as well. I believe there are some firewalld docs in the works, fwiw. Serving the installation repository from an outside network is a use case straying from the norm; I wouldn't consider the installation guide lacking because it does not document it. --pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-DBIx-Class] update to 0.08206
commit 5fa4b7ad47cd42baff8352a703cfc259455de72a
Author: Iain Arnell iarn...@gmail.com
Date: Fri Feb 15 10:16:20 2013 -0700
update to 0.08206
.gitignore |1 +
perl-DBIx-Class.spec | 10 +++---
sources |2 +-
3 files changed, 9 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a91f5dd..d8167e8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,3 +9,4 @@ DBIx-Class-0.08120.tar.gz
/DBIx-Class-0.08203.tar.gz
/DBIx-Class-0.08204.tar.gz
/DBIx-Class-0.08205.tar.gz
+/DBIx-Class-0.08206.tar.gz
diff --git a/perl-DBIx-Class.spec b/perl-DBIx-Class.spec
index 30f6c07..acee802 100644
--- a/perl-DBIx-Class.spec
+++ b/perl-DBIx-Class.spec
@@ -1,10 +1,10 @@
Name: perl-DBIx-Class
Summary:Extensible and flexible object - relational mapper
-Version:0.08205
-Release:3%{?dist}
+Version:0.08206
+Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
-Source0:
http://search.cpan.org/CPAN/authors/id/F/FR/FREW/DBIx-Class-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/A/AB/ABRAXXA/DBIx-Class-%{version}.tar.gz
# skip strange ordering bug in test
Patch0: perl-DBIx-Class-88result_set_column.patch
URL:http://search.cpan.org/dist/DBIx-Class/
@@ -28,6 +28,7 @@ BuildRequires: perl(DBIx::Class::Storage::Debug::PrettyPrint)
%endif
BuildRequires: perl(Devel::GlobalDestruction) = 0.09
BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
+BuildRequires: perl(File::Spec) = 3.30
BuildRequires: perl(File::Temp) = 0.22
BuildRequires: perl(Math::Base36) = 0.07
BuildRequires: perl(Math::BigInt) = 1.89
@@ -181,6 +182,9 @@ make test
%changelog
+* Fri Feb 15 2013 Iain Arnell iarn...@gmail.com 0.08206-1
+- update to latest upstream version
+
* Sat Feb 02 2013 Iain Arnell iarn...@gmail.com 0.08205-3
- rebuild without bootstrap again
diff --git a/sources b/sources
index 9127f0d..898cb6a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-25fa1a15d6b2b819467dfec8fae19ba8 DBIx-Class-0.08205.tar.gz
+e9ec8954c38250457b0bdb60cade3762 DBIx-Class-0.08206.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: Non-responsive Maintainer: mediawiki
On Feb 15, 2013 5:34 AM, Adam Williamson awill...@redhat.com wrote: On 08/02/13 01:36 PM, Pete Travis wrote: . I haven't poked at mediawiki in a while, so please correct me if I'm wrong, but isn't it fairly self contained? I recall copying the content from /usr/share/ to /var/www/ then localizing. Having a new version shouldn't break existing deployments unless they are served out of /usr/share/, and that doesn't seem sane. The update would then be available, not imposed. I may be misunderstanding you, but I _think_ you've got the wrong end of the stick here. Fedora webapps are indeed packaged to be served out of /usr/share/whatever . They ship with /etc/httpd/conf.d config files which point to the /usr/share location where they are installed. This is all by policy and How It's Supposed To Be. Only files that absolutely need to be actually inside /var/www for some reason or another are supposed to be packaged there. In general, the idea is that webapp files are just static data files like any others and belong in /usr/share . See https://fedoraproject.org/wiki/Packaging:Guidelines#Web_Applications . You can copy the whole thing to somewhere else (e.g. /var/www) and nerf/adjust the conf.d file if you really want to use the Fedora package only as a base for your own deployment, but that's not the 'normal way'. In general you're expected to simply install the package and use it; that way you get the benefit of packaged updates. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- Thanks for straightening me out, Adam. I'll have to poke at this to better understand it when I get the chance. Interestingly, 'repoquery -l' does show some of the mediawiki packages owning files in /var/www/. Whether grandfathered, broken, or just misconception, I'll keep further comment to myself until I can play with a VM. Thanks, --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 911713] New: https stopped working on some sites
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=911713 Bug ID: 911713 Summary: https stopped working on some sites Product: Fedora Version: 18 Component: perl-LWP-Protocol-https Severity: unspecified Priority: unspecified Reporter: m...@gromco.com Created attachment 697914 -- https://bugzilla.redhat.com/attachment.cgi?id=697914action=edit kt,pl Recent perl changes caused https stopped working on some sites. example export PERL_LWP_SSL_VERIFY_HOSTNAME=0 perl -w kt.pl https://github.com/ works , but the perl -w kt.pl 'https://www134.safesecureweb.com/jrproperties/default.htm' Before req U=https://www134.safesecureweb.com/jrproperties/default.htm U=https://www134.safesecureweb.com/jrproperties/default.htm REQUEST ISSUED SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data SSL_connect:SSLv3 read finished A . and waits forever Previously F17 did work OK, F18 did not work. Recent update to F17 made https also non-working for some sites. Now both F17 F18 fail to https for some sites -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=iB3C1DG5AUa=cc_unsubscribe -- 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: /usr/lib/debug ownership
On Fri, 15 Feb 2013 11:15:40 +0100 Michael Schwendt mschwe...@gmail.com wrote: On Thu, 14 Feb 2013 20:33:46 +0100, Alec Leamas wrote: PS. Yes, I repeat this message. Looks like it wasn't sent somehow :( As I had replied to the earlier message ;) here just a mention that I've reported the mispackaged nacl-devel: https://bugzilla.redhat.com/911405 Sadly our lists server is swamped with all the mass rebuild scm emails. It should catch back up soon now I hope. Anyhow, I think this would be an excellect case for someone to: - make a script to identify all the packages that are broken and shipping debug stuff. - mass mail maintainers to fix it. - check again, then file bugs on the ones that aren't fixed. - Ideally get some provenpackagers on board with going in and fixing them. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Pulseaudio and S/PDIF [was Re: ConsoleKit and esound retirement]
(subject changed, please strip the [was...] when replying) On 13/02/13 10:15 AM, DJ Delorie wrote: (well, more like crap, since I still haven't figured out how to get pulseaudio to use my digital audio outputs). Really? It's not that hard. It's either a device or a profile right on the very first tab of GNOME sound properties. If you're using pavucontrol, devices are on the 'Output Devices' tab, profiles are on the 'Configuration' tab. It's rather easier than doing the same thing with ALSA, really. I know all about those. I've tried them all. I've gone through all the online discussions about how to get digital outputs to work with pulseaudio. I've hacked at the config files and tried to trace the operation. I've been doing this with every update since pulseaudio was introduced, and they're all clean installs, not upgrades. It worked just fine with ALSA. I've even run GNOME sound properties, despite not running a GNOME desktop. I haven't yet tried F18 though, because I don't yet have the spare days it takes to do that. It just doesn't work. I know the hardware works, because XBMC uses the digital output just fine (and sounds seriously better). The motherboard is a Gigabyte GA-X58A-UD3R although I do have an HDMI-compatible video card (and yes, I know you have to disable audio on that, the video card is much more recent than my PA woes). 00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller 03:00.1 Audio device: ATI Technologies Inc Barts HDMI Audio [Radeon HD 6800 Series] 07:00.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 02) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Mon, Feb 11, 2013 at 11:19 PM, Ralf Corsepius rc040...@freenet.de wrote: When talking to Ubuntu users, they are telling Unity is as biasing as Gnome3. Aside from the visual arrangement of things, I haven't seen *major* differences between the GNOME 3 and the Unity user interfaces. It's not all that hard for me to mentally switch from my preferred GNOME 3 on Fedora 18 to a Quantal Quetzal default Unity desktop on a virtual machine. Right-click on an icon to remove it from the list, etc. But it's essentially the exact same total mindshift in going from a GNOME 2 menu at the top like older Fedora and Ubuntu to either a GNOME 3 or a Unity desktop. It's *huge* but not insurmountable. The Unity compiz crashes, on the other hand, are a show-stopper. ;-) AFAICT, most dissatisfied Ubuntu/Unity users quit Ubuntu for Linux MiNT. Well, there are actually *two* Linux Mint desktops, Cinnamon and MATE. They also make a KDE and XFCE version, but I haven't played with those at all. I must admit I don't know the community structures / resource allocations among the three projects - Linux Mint, Cinnamon and MATE. -- Twitter: http://twitter.com/znmeb; Computational Journalism on a Stick http://j.mp/CompJournoStick/ The National Coal Institute reminds you, There's no fuel like an old fuel. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads up: ARM build system outage for migration
Hi All, A heads up that we're planning an outage of arm.koji.fedoraproject.org to migrate the koji instance to the new infrastructure in Phoenix. The outage will begin about 02:00 UTC on Saturday the 16th February and while we're not certain the exact time it should take we estimate it should be done in well under 12 hours. I'll reply to this message once we're up and building again. From there we'll kick off the ARM mass rebuild to give the currently deployed hardware a good burn in (it's almost like we planned it like this but we didn't :-P ) I'll be shutting down the shadowing processes shorts to allow builds to complete and to remove I/O to allow the data sync to complete. See you on the flip side! Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib/debug ownership
On Fri, Feb 15, 2013 at 01:03:50PM +0100, Alec Leamas wrote: Thanks for reply... Still, I'm puzzled about 45 packages owning /usr/lib/debug, none of them the filesystem package. This looks weird, although I don't grasp the consequences (if any). A normal review rule says that a package should not own a directory owned by another package. Does this apply to /usr/lib/debug (as well as /usr/src/debug, used occasionally)? If so, who is the rightful owner of these directories? Still confused, but on a higher level... If you file a bug against filesystem, it will probably be included. Then the other packages can be fixed to not own it. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gnome-settings-daemon (was: Re: ConsoleKit and esound retirement)
On Fri, 15 Feb 2013 08:13:32 +0100, Bastien Nocera wrote: Could you tell me a test environment where auto-starting the daemon is reproducible? Then I might take a look at trying to avoid it. It should be auto-started when your app pokes at the not-yet-spawned well-known D-Bus name. There's an error upon trying to talk to it: The name org.gnome.SettingsDaemon was not provided by any .service files It seems something wants to start it but couldn't without the .service file. I've also tried Fedora 17 where g-s-d is not auto-started either. I've also tried Fedora 18 _without_ GDM but with startx and fvwm. Always the same error message. As pointed out above, with Openbox the daemon is not started automatically when starting Audacious. I'm stuck there. The puzzle is incomplete. Is there a session D-Bus running in your session? I don't know how it could not start. At the bottom of the message you replied to: http://lists.fedoraproject.org/pipermail/devel/2013-February/178617.html $ ps ax|grep dbus 646 ?Ssl0:01 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation 20236 ?S 0:00 dbus-launch --sh-syntax --exit-with-session 20237 ?Ssl0:00 /bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session 20443 ?Sl 0:00 /bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3 20900 pts/0S+ 0:00 grep --color=auto dbus You should use dbus_g_proxy_new_for_name_owner() instead, which will round-trip and check whether the service exists. Then my (preliminary) solution from yesterday can't be too bad, since if there's no owner the plugin refuses to talk to dbus. Hopefully it should stop it from auto-spawning. You said hopefully. ;-) Yeah, a test environment would be good. -- Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc7.git2.1.fc19.x86_64 loadavg: 0.15 0.10 0.07 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Javascript packaging guidelines
I am working to become a packager for spice-html5 [1]. Eduardo Echeverria has suggested that I break out the dependent Javascript libraries into separate packages, which I am now working on. I am attempting to follow the Javascript library packaging guideline [2], however I have uncovered an issue with those guidelines [3] - they specify inconsistent locations for the Apache configuration file. Being completely new to this process, I'd appreciate guidance on how to proceed. Looking at the change history on that Wiki page, it looks like it's relatively stale. That suggests I should bull ahead and package as I see best, and that's what I'll do by default. But if I should try to shake a tree and force some resolution on the guidelines instead, here I am, shaking grin. Cheers, Jeremy [3] https://fedoraproject.org /wiki/Talk:JavaScript_libraries_packaging_guideline_draft#Issues [1] https://bugzilla.redhat.com/show_bug.cgi?id=910793 [2] https://fedoraproject.org /wiki/Talk:JavaScript_libraries_packaging_guideline_draft [3] https://fedoraproject.org /wiki/Talk:JavaScript_libraries_packaging_guideline_draft#Issues -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On 15/02/13 05:44 AM, Tom Hughes wrote: On 15/02/13 03:02, Adam Williamson wrote: On 08/02/13 01:36 PM, Pete Travis wrote: I haven't poked at mediawiki in a while, so please correct me if I'm wrong, but isn't it fairly self contained? I recall copying the content from /usr/share/ to /var/www/ then localizing. Having a new version shouldn't break existing deployments unless they are served out of /usr/share/, and that doesn't seem sane. The update would then be available, not imposed. I may be misunderstanding you, but I _think_ you've got the wrong end of the stick here. Fedora webapps are indeed packaged to be served out of /usr/share/whatever . They ship with /etc/httpd/conf.d config files which point to the /usr/share location where they are installed. This is all by policy and How It's Supposed To Be. Only files that absolutely need to be actually inside /var/www for some reason or another are supposed to be packaged there. In general, the idea is that webapp files are just static data files like any others and belong in /usr/share . See https://fedoraproject.org/wiki/Packaging:Guidelines#Web_Applications . You're both kind of right - the README.RPM file that comes in the mediawiki package tells you to run mw-createinstance path to create an instance and that sets up a document root in the specified path by both copying some files, like LocalSettings.php, and symlinking others to the /usr/share code. Huh. That sounds...interesting. I haven't run mediawiki itself, so I wasn't aware of that, I was just referring to my general knowledge of how webapps are packaged in Fedora (e.g. wordpress, which I do run). Thanks. -- 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: gnome-settings-daemon (was: Re: ConsoleKit and esound retirement)
Yeah, a test environment would be good. Found a first one! EL6 with Openbox from EPEL. That one auto-spawns g-s-d when running Audacious unpatched. $ find /usr/share/dbus-1|grep Sett /usr/share/dbus-1/services/org.gnome.SettingsDaemon.service -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib/debug ownership
On Fri, 15 Feb 2013 13:03:50 +0100, Alec Leamas wrote:
On 02/14/2013 11:19 PM, Michael Schwendt wrote:
On Thu, 14 Feb 2013 16:36:03 +0100, Alec Leamas wrote:
Running some automated tests I stumble over the debug directories. E. g.,
$ repoquery -qf /usr/lib/debug
shows 45 owners on current F18. Other directories under /usr/lib/debug
have a similar situation with many owners..
I note that /usr/src/debug is owned by filesystem, but filesystem does
not own /usr/lib/debug.
Is all this on purpose, or is something broken here? Thinking about it,
we never require anything for the debug package AFAICT. What's the story?
It depends on what the package stores below /usr/lib/debug.
Here's one that is mispackaged:
# repoquery -qf /usr/lib/debug
nacl-devel-0:20110221-3.fc19.i686
- http://koji.fedoraproject.org/koji/rpminfo?rpmID=3336721
It includes the -debuginfo package contents in the -devel package, most
likely because it does a lazy'n'risky %{_libdir}/* in its %files section.
Thanks for reply... Still, I'm puzzled about 45 packages owning
/usr/lib/debug, none of them the filesystem package. This looks weird,
although I don't grasp the consequences (if any).
Which packages are returned for your query?
I've tried repoquery --whatprovides /usr/lib/debug for both x86_64
and i686, but it doesn't return anything other than nacl-devel.
Do you have any -debuginfo packages installed from a -debuginfo repo?
Those do own /usr/lib/debug and /usr/src/debug.
rpm -qa \*debuginfo
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Announcing: Fedora ARM Technical Talks
On 02/15/2013 02:32 PM, Jon Masters wrote: Please see the following link for further details: https://fedoraproject.org/wiki/Architectures/ARM/Talks/ARMTechTalks Today's talk is on debugging vexpress (Versatile Express) kernels running under qemu models with gdb. It will simply cover setting up a system for tracing a kernel with gdb and is introductory in nature. I will host another Fedora ARM technical talk this afternoon. This will be my second, and so I am taking the opportunity to formalize this into a series of technical talks. Each 1-2 weeks I will host a deep dive technical session, on kernel debugging, atomic operations, and covering gnarly issues that I have helped track down (e.g. systemd-logind issue). This is not limited to me - drop me a line if you would like to give a talk, or would like to help organize this series :) Minutes from today's ARM Tech Talk hosted by me: HTML: http://meetbot.fedoraproject.org/fedora-arm-talks/2013-02-15/fedora-arm-talks.2013-02-15-20.09.html Text: http://meetbot.fedoraproject.org/fedora-arm-talks/2013-02-15/fedora-arm-talks.2013-02-15-20.09.txt Raw: http://meetbot.fedoraproject.org/fedora-arm-talks/2013-02-15/fedora-arm-talks.2013-02-15-20.09.log.html Tune in next Friday at 20:00 UTC, when John Dulaney will tell us all about installing Fedora onto the Samsung ARM-powered Chromebook! Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On 02/15/2013 03:13 PM, Jóhann B. Guðmundsson wrote: On 02/15/2013 12:52 PM, Honza Horak wrote: There is no change, the unit file is still mysqld.service. Hmm.. It's probably better to have an mariadb own unit files and create corresponding mysql symbolic link to those unit files for backwards compatibility at install time. ( we already do so at few places to keep backwards compatibility with the service command to systemd units in few places ) I don't understand what would be the benefit, except that the files wouldn't conflict, but the packages conflict anyway currently. Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On 02/15/2013 3:31 PM, Jóhann B. Guðmundsson wrote: On 02/15/2013 01:50 PM, Honza Horak wrote: I still see the differences between MariaDB and MySQL to be very little. Difference never the less and difference in behavior ( which mariadbs own benchmarking on their website proof ) which means every server tweak that has been done for the mysql host has to be redone to take whatever changes and features mariadb introduces. Can you be more specific, what tweaks you mean? If you install mate or cinnamon or unity for that matter would you expect to be migrated and running Gnome 3.x after upgrade or would you expect to be continuing to use and run what got forked or based of it. This is already too extreme, we cannot compare Gnome forks and MySQL forks. It's really a different scenario. Same fundamental rules apply as I see it just different ( fork ) components. So what about upstart-systemd or Gnome2-Gnome3 switches? These also took place without users interaction and it was not without problems. OK, they aren't forks, just new features. Why not take MariaDB just as a new feature? upstart was never properly integrated into the distribution so it's more accurate to talk about sys V -- Systemd and my advice to any distribution that thinks of making that switch to do so within one release cycle and arguably systemd should never have had that backward compatibility ( to that certain extent it has ) to sys V implemented. Doing so has caused users to expect sysv/upstart like behavior of the init systemd as opposed to approach and embrace it as new technology. That said neither systemd nor Gnome 3 are forks however mariadb is so it will ( as is the nature of all forks ) grow further away from it's origin in time ( how fast that happens depends on it's maintainers ), thus it should be treated as fork and a completely separated database product that is *based* on mysql and packaged as such It's possible, but I see that as another reason to do the switch to mariadb now, than later. Well, in case we wouldn't obsolete mysql -- then either we could do it in F20 and have the same problem a few months later Sorry not following as long as someone is willing to maintain mysql in the distribution we should not be dealing with any kind of potential replacement migration. The reason of replacement is not that nobody is willing to package mysql. The reasons were stated on the feature page: https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB or don't do it at all and then we would have troubles with CVE and unfriendly upstream forever. Still not following I would assume the more these two components grow apart the more CVE troubles we have and which unfriendly upstream mysql or mariadb one? MySQL one ;) The problem is not number of CVE, but the information about them -- again, more info on the feature page and it shouldn't be hard to find Oracle's announcements about making these and other info (e.g. tests) private. Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
Rahul Sundaram methe...@gmail.com writes: On Thu, Feb 14, 2013 at 10:13 PM, Kevin Kofler wrote: I really don't see what we have to gain from having 2 conflicting versions of MySQL in Fedora. We never had the culture of questioning why anyone should include any package as long as it meets the current guidelines. As long as there are maintainers who are willing to deal with it, I don't see why you feel the need to protest. The real bottom line here is that the current mysql maintainers *aren't* willing to deal with it anymore, and wish to shift our efforts to MariaDB. Barring someone taking up maintainership of Oracle's version, it's going to be an orphan. The current F19 feature for this was written on the assumption that nobody was going to step forward to do that, and thus that we needed to transition existing mysql users to mariadb, and that there wasn't much value in worrying about how to make multiple mysql forks coexist. Now some folk from Oracle have stated that they'd be willing to take up the packaging work to keep their version alive in Fedora. I don't wish to stand in their way, but I think it's fair to wonder how long it'll take them to get up to speed, since they evidently have zero Fedora packaging expertise today. In any case we need to think a bit harder about coexistence issues. I still think there is no need to support concurrent installation of both forks of mysql; that would accomplish little except to complicate the lives of both users and packagers. But we may need to revisit the idea that we can just have mariadb obsolete mysql and be done. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On Fri, Feb 15, 2013 at 2:10 PM Jan-Frode Myklebust wrote: On Thu, Feb 14, 2013 at 10:17:00AM -0500, Tom Lane wrote: The way this worked in the past (and still does on RHEL and some other distros) is that MySQL AB provided RPMs named MySQL, MySQL-server, etc, which simply conflicted with the Red Hat-supplied packages named mysql, mysql-server, etc. Perhaps it would be best to continue that naming tradition, ie establish a new Oracle-maintained Fedora package named MySQL, instead of figuring out how to transition maintainership of the mysql packages. This would give us some more wiggle room about managing the transition --- in particular, it's hard to see how we manage Obsoletes/Provides linkages in any sane fashion if the mysql package name continues in use. I think we're going to have to end up with a design in which mysql becomes essentially a virtual Provides name. I'm quite amazed at how MariaDB is allowed to do this takeover of mysql in fedora. Why can't MariaDB use it's own configuration files, own datadir, own socket, own binary names, etc.. ? I'm no Oracle or Mysql fan, but as far as I see it Oracle/mysql is the original branch of the mysql project, and I think a competing fork should do it's best not to conflict with it. No effort not to conflict seems to be happening here, rather the opposite. Upstream chose the way of drop-in replacement, which means that the same API including file names was actually a feature. Why we don't do it differently in Fedora is obvious -- we don't want to differ from upstream. What happens when MariaDB and Mysql start diverging? Will it be impossible to have a client that connects to both mysql and mariadb servers ? Most probably not. I doubt that if these projects start diverge in the future, incompatible changes in client-server protocol will be desired changes. I believe the opposite would be true -- which is compatibility on this layer will be still important. Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On 15/02/13 09:49 AM, Pete Travis wrote: Interestingly, 'repoquery -l' does show some of the mediawiki packages owning files in /var/www/. Whether grandfathered, broken, or just misconception, I'll keep further comment to myself until I can play with a VM. There are cases when there really has to be a file in /var/www for some reason or another. Wordpress has one or two files there too, but almost everything in /usr/share. -- 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: Pulseaudio and S/PDIF [was Re: ConsoleKit and esound retirement]
On 15/02/13 10:22 AM, DJ Delorie wrote: (subject changed, please strip the [was...] when replying) On 13/02/13 10:15 AM, DJ Delorie wrote: (well, more like crap, since I still haven't figured out how to get pulseaudio to use my digital audio outputs). Really? It's not that hard. It's either a device or a profile right on the very first tab of GNOME sound properties. If you're using pavucontrol, devices are on the 'Output Devices' tab, profiles are on the 'Configuration' tab. It's rather easier than doing the same thing with ALSA, really. I know all about those. I've tried them all. I've gone through all the online discussions about how to get digital outputs to work with pulseaudio. I've hacked at the config files and tried to trace the operation. I've been doing this with every update since pulseaudio was introduced, and they're all clean installs, not upgrades. It worked just fine with ALSA. I've even run GNOME sound properties, despite not running a GNOME desktop. I haven't yet tried F18 though, because I don't yet have the spare days it takes to do that. It just doesn't work. I know the hardware works, because XBMC uses the digital output just fine (and sounds seriously better). The motherboard is a Gigabyte GA-X58A-UD3R although I do have an HDMI-compatible video card (and yes, I know you have to disable audio on that, the video card is much more recent than my PA woes). 00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller 03:00.1 Audio device: ATI Technologies Inc Barts HDMI Audio [Radeon HD 6800 Series] 07:00.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 02) That's weird. Definitely just some kind of bug specific to your system, though, the normal PA experience with digital output is pretty simple. I've had no problem with it. You don't really need to disable any output sources in most cases, either (I haven't bothered disabling any of the umpteen sources that appear to exist on my system, I just pick the one I actually want to use, and it works, no problems at all). Do you have a bug report in? -- 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: Pulseaudio and S/PDIF [was Re: ConsoleKit and esound retirement]
On Fri, Feb 15, 2013 at 6:22 PM, DJ Delorie d...@redhat.com wrote: (subject changed, please strip the [was...] when replying) On 13/02/13 10:15 AM, DJ Delorie wrote: (well, more like crap, since I still haven't figured out how to get pulseaudio to use my digital audio outputs). Really? It's not that hard. It's either a device or a profile right on the very first tab of GNOME sound properties. If you're using pavucontrol, devices are on the 'Output Devices' tab, profiles are on the 'Configuration' tab. It's rather easier than doing the same thing with ALSA, really. I know all about those. I've tried them all. I've gone through all the online discussions about how to get digital outputs to work with pulseaudio. I've hacked at the config files and tried to trace the operation. I've been doing this with every update since pulseaudio was introduced, and they're all clean installs, not upgrades. It worked just fine with ALSA. I've even run GNOME sound properties, despite not running a GNOME desktop. I haven't yet tried F18 though, because I don't yet have the spare days it takes to do that. It just doesn't work. It works just fine for me on F18 on media center box using a standard optical cable. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On 02/15/2013 09:09 AM, Honza Horak wrote: On 02/13/2013 02:16 PM, Jóhann B. Guðmundsson wrote: I for one would not want to find out that my mysql install would have been replaced with mariadb on upgrade ( or visa versa ) The discussion already started several weeks ago but we still need any feedback. What are you particular concerns? AFAIK, admins usually don't like this change because they are worried of: 1) different name 2) the upgrade 3) different API/ABI 4) more bugs However, these are not the issues we should worried, because: 1) only package name is different; the structure and content of rpms and file names are the same as in mysql 2) no special steps need to be done, it's really drop-in replacement 3) API/ABI is preserved when comparing mysql-5.5 and mariadb-5.5 4) the opposite is true -- several bugs are fixed in mariadb and there are much more test cases; just try google to find admin's experiences with mariadb: you'll usually find more stable and faster answers. At least I did Mariadb is evolving into it's own product with it's own feature set [1] thus should be treated as different product it should have it's own .cnf file it's own configuration directory which is best in the long run ( from my pov ). If I install a component what ever component I then upgrade I expect that a) I get the latest and the greatest release of that component b) still be running the same release of the component if not newer release is found or if the component is no longer being shipped. I dont expect a) that the component gets removed on upgrade, b) that I magically somehow get migrated to a different product. Let me take other examples of what I'm trying to refer to here with regards to expected behavior. If you would install libreoffice would you expect to be running openoffice after upgrade or would you expect to be starting libreoffice after the upgrade? If you install mate or cinnamon or unity for that matter would you expect to be migrated and running Gnome 3.x after upgrade or would you expect to be continuing to use and run what got forked or based of it. One usage scenario one simple question If an user wants to run both those database solution on his server wont those two overlap as in can for exaxmple users be asssured that the changes that they make to their my.cnf wont get picked up by mariadb when it gets started etc. JBG 1. https://kb.askmonty.org/en/mariadb-versus-mysql-features/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On 02/15/2013 11:07 AM, Honza Horak wrote: On 02/15/2013 11:27 AM, Jóhann B. Guðmundsson wrote: Mariadb is evolving into it's own product with it's own feature set [1] thus should be treated as different product it should have it's own .cnf file it's own configuration directory which is best in the long run ( from my pov ). Then it should also need separate binaries, libraries, datadir, socket, ... I'm not saying it is so bad idea, but it could be taken into account only in the upstream, we really cannot do something like that downstream. And we'd probably lost the drop-in feature and upgrade would be even more painful. How so? If fesco does not ban mysql from the distribution then upgrades should not be painful because you would simply upgrade to the latest mysql release in the distribution. If mysql on the other hand is banned in the distribution then arguably it makes sense to migrate those instances to the latest release of mariadb instead thou I personally would not recommended it then either but rather prefer it would be left alone then replaced by admin himself after upgrade. snip In case it would be discussed, compatible, documented, noted in the release notes and we have a good reason to do so -- then why not? Different product different characteristics If you install mate or cinnamon or unity for that matter would you expect to be migrated and running Gnome 3.x after upgrade or would you expect to be continuing to use and run what got forked or based of it. This is already too extreme, we cannot compare Gnome forks and MySQL forks. It's really a different scenario. Same fundamental rules apply as I see it just different ( fork ) components. One usage scenario one simple question If an user wants to run both those database solution on his server wont those two overlap as in can for exaxmple users be asssured that the changes that they make to their my.cnf wont get picked up by mariadb when it gets started etc. Running both packages on the same server is not currently available, because they conflict. If somebody does it in any way, which means to separate files, sockets, ... then he should be able to separate config files as well. Is that not an clear indicator that the replacement should not take place on upgrade but rather be left up to the administrator to do manually ( at least while we still ship mysql ) and we have mysql and mariadb conflict with each other on packaging level? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On 02/15/2013 02:28 AM, Toshio Kuratomi wrote: On Thu, Feb 14, 2013 at 10:17:00AM -0500, Tom Lane wrote: Norvald H. Ryeng norvald.ry...@oracle.com writes: On Thu, 14 Feb 2013 08:07:22 +0100, Rahul Sundaram methe...@gmail.com Well, unless Oracle as upstream wants to get involved as downstream maintainers in Fedora as well. They did offer to do that but don't seem to have stepped up yet. Let's do it now, then. :-) We want to keep the MySQL package in Fedora and are willing to co-maintain or take over maintainership if nobody else will do it. We haven't really discussed this with the current maintainers yet, but from the discussions on this list it seems they're not interested in maintaining the package after F19. If us stepping up changes that, we are happy to co-maintain. The way this worked in the past (and still does on RHEL and some other distros) is that MySQL AB provided RPMs named MySQL, MySQL-server, etc, which simply conflicted with the Red Hat-supplied packages named mysql, mysql-server, etc. Perhaps it would be best to continue that naming tradition, ie establish a new Oracle-maintained Fedora package named MySQL, instead of figuring out how to transition maintainership of the mysql packages. This would give us some more wiggle room about managing the transition --- in particular, it's hard to see how we manage Obsoletes/Provides linkages in any sane fashion if the mysql package name continues in use. I think we're going to have to end up with a design in which mysql becomes essentially a virtual Provides name. It's all going to depend on what we want the upgrade experience to be like for people going from f18 to f19. I believe that FESCo punted it down the road since there wasn't an actual MySQL package maintainer at the time we decided to accept the Feature (just potential ones). How could there be since the current mysql maintainers did not orphan mysql ? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On 02/15/2013 09:09 AM, Honza Horak wrote: So again, if you have some concrete concerns, let us know, please. What are the plans to handle the name change in the daemon startup ( systemd unit ) in the migration faze to prevent users having to find out on their own how to start mariadb along and preventing every puppet/chef/python/scripts and other things that the administrator has tied to service mysql start/stop/restart and or systemctl start/stop/restart mysqld.service along with potentially any other infrastructure bits tied to mysql from breaking? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
Am 15.02.2013 04:13, schrieb Kevin Kofler: Rahul Sundaram wrote: Well, unless Oracle as upstream wants to get involved as downstream maintainers in Fedora as well. They did offer to do that but don't seem to have stepped up yet. I really don't see what we have to gain from having 2 conflicting versions of MySQL in Fedora. It'd be a big mess not only for our users, but also for the software in Fedora which depends on it. For the same reason, I'm also opposed to the plan of having MySQL and MariaDB coexist for one release. We should really move to MariaDB with hard Obsoletes and then ship only that. for me there are two options * stick with MySQL as Oracle offered packaging support hopefully they raise up their speed and quality this is what i would strongly prefer ___ * replace MySQL with MariaDB and stop thinking about all of this mess of having both and pray that drop-in-replacement really works in all cases * not breaks randomly updates in the life-cycle for people using one or the other depending on which package get's a minor update and what of both you are using * not messup with hidden soname incompatibilites, i simply do not buy the argument you can have both and it is binary compatible * even MySQL 5.5 had a HIDDEN soname break on a minor update with the need of rebuild depending packages and now people will explain me that two different forks are binary compatible - this is very thin ice and can break with ANY minor update * whatever suprises may come to the light after it is way too late for a clean and doable solution ___ provide a clean and working migration to MariaDB or leave your fingers from replace software from which complete and complex infrastructures are depending in the real world have you guys any idea what impact touching mysql in infrastrcutures with dbmail/postfix/dovecot/httpd on several machines working tight together with all sorts of web-applications may have? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On 02/15/2013 01:50 PM, Honza Horak wrote: On 02/15/2013 12:39 PM, Jóhann B. Guðmundsson wrote: On 02/15/2013 11:07 AM, Honza Horak wrote: snip If mysql on the other hand is banned in the distribution then arguably it makes sense to migrate those instances to the latest release of mariadb instead thou I personally would not recommended it then either but rather prefer it would be left alone then replaced by admin himself after upgrade. This will be indeed possible. If admin reads the release notes before upgrading to F19 (which I suppose if they mind their data), he will be aware of the change and will be able to disable mariadb packages for the time of upgrade in order to not replace mysql. Then, anytime later, he will be able to do the manual replacement. That's wrong from my point of view and the opposite would be correct behavior as in he would have to enable the mariadb packages to have them replaced and by doing so he would at same time acknowledging that he was aware of the changes. ( opposed to them surprising him later ) snip In case it would be discussed, compatible, documented, noted in the release notes and we have a good reason to do so -- then why not? Different product different characteristics I still see the differences between MariaDB and MySQL to be very little. Difference never the less and difference in behavior ( which mariadbs own benchmarking on their website proof ) which means every server tweak that has been done for the mysql host has to be redone to take whatever changes and features mariadb introduces. If you install mate or cinnamon or unity for that matter would you expect to be migrated and running Gnome 3.x after upgrade or would you expect to be continuing to use and run what got forked or based of it. This is already too extreme, we cannot compare Gnome forks and MySQL forks. It's really a different scenario. Same fundamental rules apply as I see it just different ( fork ) components. So what about upstart-systemd or Gnome2-Gnome3 switches? These also took place without users interaction and it was not without problems. OK, they aren't forks, just new features. Why not take MariaDB just as a new feature? upstart was never properly integrated into the distribution so it's more accurate to talk about sys V -- Systemd and my advice to any distribution that thinks of making that switch to do so within one release cycle and arguably systemd should never have had that backward compatibility ( to that certain extent it has ) to sys V implemented. Doing so has caused users to expect sysv/upstart like behavior of the init systemd as opposed to approach and embrace it as new technology. That said neither systemd nor Gnome 3 are forks however mariadb is so it will ( as is the nature of all forks ) grow further away from it's origin in time ( how fast that happens depends on it's maintainers ), thus it should be treated as fork and a completely separated database product that is *based* on mysql and packaged as such Running both packages on the same server is not currently available, because they conflict. If somebody does it in any way, which means to separate files, sockets, ... then he should be able to separate config files as well. Is that not an clear indicator that the replacement should not take place on upgrade but rather be left up to the administrator to do manually ( at least while we still ship mysql ) and we have mysql and mariadb conflict with each other on packaging level? Well, in case we wouldn't obsolete mysql -- then either we could do it in F20 and have the same problem a few months later Sorry not following as long as someone is willing to maintain mysql in the distribution we should not be dealing with any kind of potential replacement migration. or don't do it at all and then we would have troubles with CVE and unfriendly upstream forever. Still not following I would assume the more these two components grow apart the more CVE troubles we have and which unfriendly upstream mysql or mariadb one? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On 02/15/2013 05:40 AM, Orcan Ogetbil wrote: On Thu, Feb 14, 2013 at 3:53 AM, Norvald H. Ryeng wrote: On Thu, 14 Feb 2013 08:07:22 +0100, Rahul Sundaram On Wed, Feb 13, 2013 at 10:26 PM, Kevin Kofler wrote: MariaDB WILL replace MySQL on upgrades. Well, unless Oracle as upstream wants to get involved as downstream maintainers in Fedora as well. They did offer to do that but don't seem to have stepped up yet. Let's do it now, then. :-) We want to keep the MySQL package in Fedora and are willing to co-maintain or take over maintainership if nobody else will do it. We haven't really discussed this with the current maintainers yet, but from the discussions on this list it seems they're not interested in maintaining the package after F19. If us stepping up changes that, we are happy to co-maintain. Any input on how we can and should proceed is welcome. The steps to become a Fedora package maintainer is well documented in the wiki: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers The package is not banned. Nobody is stopping a potential MySQL maintainer in Fedora. Tom has proposed to make it significantly harder with... Perhaps it would be best to continue that naming tradition, ie establish a new Oracle-maintained Fedora package named MySQL, instead of figuring out how to transition maintainership of the mysql packages. This would give us some more wiggle room about managing the transition --- in particular, it's hard to see how we manage Obsoletes/Provides linkages in any sane fashion if the mysql package name continues in use. New package name,new package review etc. vs transferred (or co) maintainership all done to make the mariadb maintainers life easier. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On 02/15/2013 09:40 AM, Norvald H. Ryeng wrote: Neither Andrew or I will do the packaging. I'll be involved, but someone from our build team will do the actual packaging. None of us are Fedora packagers, so I guess we'll need someone to review our packaging and sponsor us. Or current maintainers will add those from the build team as co-maintainers in F19 then they take over in F20 given that it seems to be then current maintainers seem to plan to orphan it. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
Am 15.02.2013 14:10, schrieb Jan-Frode Myklebust: On Thu, Feb 14, 2013 at 10:17:00AM -0500, Tom Lane wrote: The way this worked in the past (and still does on RHEL and some other distros) is that MySQL AB provided RPMs named MySQL, MySQL-server, etc, which simply conflicted with the Red Hat-supplied packages named mysql, mysql-server, etc. Perhaps it would be best to continue that naming tradition, ie establish a new Oracle-maintained Fedora package named MySQL, instead of figuring out how to transition maintainership of the mysql packages. This would give us some more wiggle room about managing the transition --- in particular, it's hard to see how we manage Obsoletes/Provides linkages in any sane fashion if the mysql package name continues in use. I think we're going to have to end up with a design in which mysql becomes essentially a virtual Provides name. I'm quite amazed at how MariaDB is allowed to do this takeover of mysql in fedora. Why can't MariaDB use it's own configuration files, own datadir, own socket, own binary names, etc.. ? I'm no Oracle or Mysql fan, but as far as I see it Oracle/mysql is the original branch of the mysql project, and I think a competing fork should do it's best not to conflict with it. No effort not to conflict seems to be happening here, rather the opposite. What happens when MariaDB and Mysql start diverging? Will it be impossible to have a client that connects to both mysql and mariadb servers? exactly that may happen but Fedora is not interested in the long future, Fedora decisions are for now and with luck tomorrow signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On Fri, Feb 15, 2013 at 11:24:31AM -0800, Adam Williamson wrote: On 15/02/13 05:44 AM, Tom Hughes wrote: You're both kind of right - the README.RPM file that comes in the mediawiki package tells you to run mw-createinstance path to create an instance and that sets up a document root in the specified path by both copying some files, like LocalSettings.php, and symlinking others to the /usr/share code. Huh. That sounds...interesting. I haven't run mediawiki itself, so I wasn't aware of that, I was just referring to my general knowledge of how webapps are packaged in Fedora (e.g. wordpress, which I do run). Thanks. Trac behaves similarly. There is also some environment setup and deployment involved that creates/copies files, which are usually not common to all instances. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib/debug ownership
On Fri, Feb 15, 2013 at 10:50:28AM -0700, Kevin Fenzi wrote: - make a script to identify all the packages that are broken and shipping debug stuff. AT least for the directory a simple yum call should suffice: yum --disablerepo '*' --enablerepo fedora\* whatprovides /usr/lib/debug But it shows that a lot (all?) debuginfo packages own the directory which probably needs to be fixed in rpm itself. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Does anybody know how to contact louizatakk?
Hello, I'm trying to contact the maintainer of python-sleekxmpp to request to co-maintain (as it's a bit out of date). Emails to his/her FAS email address are bouncing but there are no other maintainers to contact. Not really sure how exactly to get in touch given that email is the only form of communication on offer: User: louizatakk, Name: None, email: lo...@louiz.org, Creation: 2008-04-22, IRC Nick: None, Timezone: None, Locale: None, GPG Approved Groups: cla_fedora cla_done fedorabugs cvsl10n packager cla_fpca Kind regards, -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome-shell workspaces
On Thu, 14 Feb 2013 19:31:42 -0800 Adam Williamson wrote: Kevin, you work on a desktop which sufficiently represents your views. I think we're all aware that if we want fifteen thousand settings in the control panel, we can run KDE. Do you really believe you're going to convince the GNOME developers to turn GNOME into KDE with posts like the above? If not, what's the point of writing them? What do you expect your post to achieve? I don't think that's what he is trying to tell. I believe it's: either expose the setting, or don't have the setting. The middle way is broken, be it semi-official tweak tool or even worse advanced tab. Especially if the tweak tool is for settings that are expected to be broken, unsupported or eating kitties. I mean, what's behind the idea of having an unsupported, half-broken switch in a *stable* release in the first place? If you don't support it, or it isn't finished, why it's in the stable release? If it's supported and finished, why it isn't visible? The most *I* can understand is: we have implemented this setting, because we think it's important, the setting is supported and it isn't eating kitties, but we don't know yet how to properly expose it in UI. But Olav seems to suggest otherwise and that's probably what Kevin responds to. Martin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On 02/08/2013 08:46 AM, Michael Cronenworth wrote: The mediawiki package is severely outdated. I have attempted to contact the maintainer and received only one reply in a couple of weeks. He has ignored my requests for co-maintainership. I commented on the NRM bug[1] two weeks ago with no response. The bug itself is months old, but he pops in to keep from having the package taken. At this point it is time for someone to update the package as it is currently a security hazard. I have already built the latest mediawiki package and have it ready to rock-and-or-roll once the NRM procedure is finished. Michael [1] https://bugzilla.redhat.com/show_bug.cgi?id=850937 Ping. I'd like to finish up the NRM process. Thanks, Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Thu, 14 Feb 2013 19:13:08 -0800 Adam Williamson wrote: On 09/02/13 01:03 AM, Kevin Kofler wrote: Last I checked, GDM also hid that feature so well that many users missed it. In fact, unless this changed recently, when you input your user name, the option is NOT shown, it only appears after you confirm your user name, during the password prompt. Well, yes, that's true. How does that count as 'well hidden'? It's not like you can login without entering your password. What about users *without* password? It's insecure (in most cases), but possible. But yes, we have other DMs, so why bother with pointing out what we believe GDM does wrong, when there's a DM that does it right and is supported in Fedora? I've abandoned GDM myself when it started using gnome shell and since then I haven't got the urge to point out that it's unusable (meaning inconvenient, non-effective to use) for me, because I can use something different now (many thanks to the people who got LightDM into Fedora and made it work). Martin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On 15 February 2013 12:24, Adam Williamson awill...@redhat.com wrote: On 15/02/13 05:44 AM, Tom Hughes wrote: On 15/02/13 03:02, Adam Williamson wrote: On 08/02/13 01:36 PM, Pete Travis wrote: I haven't poked at mediawiki in a while, so please correct me if I'm wrong, but isn't it fairly self contained? I recall copying the content from /usr/share/ to /var/www/ then localizing. Having a new version shouldn't break existing deployments unless they are served out of /usr/share/, and that doesn't seem sane. The update would then be available, not imposed. I may be misunderstanding you, but I _think_ you've got the wrong end of the stick here. Fedora webapps are indeed packaged to be served out of /usr/share/whatever . They ship with /etc/httpd/conf.d config files which point to the /usr/share location where they are installed. This is all by policy and How It's Supposed To Be. Only files that absolutely need to be actually inside /var/www for some reason or another are supposed to be packaged there. In general, the idea is that webapp files are just static data files like any others and belong in /usr/share . See https://fedoraproject.org/wiki/Packaging:Guidelines#Web_Applications . You're both kind of right - the README.RPM file that comes in the mediawiki package tells you to run mw-createinstance path to create an instance and that sets up a document root in the specified path by both copying some files, like LocalSettings.php, and symlinking others to the /usr/share code. Huh. That sounds...interesting. I haven't run mediawiki itself, so I wasn't aware of that, I was just referring to my general knowledge of how webapps are packaged in Fedora (e.g. wordpress, which I do run). Thanks. So one of the issues that Axel's mediawiki package is trying to solve is the 1 server, many mediawikis problem. Many servers will run multiple mediawikis at the same time with each one having a different customer. This requires doing copies to different trees and such. Of course it makes it a pain in ass when upgrading because you end up with stuff in your tree which may not match what /usr/share/mediawiki/ provides etc etc. The preferred upstream solution was at one point to just stick it in /var/www and skip links etc. -- 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: Should MariaDB touch my.cnf in %post?
On Fri, Feb 15, 2013 at 01:00:38PM +0100, Miloslav Trmač wrote: On Fri, Feb 15, 2013 at 3:28 AM, Toshio Kuratomi a.bad...@gmail.com wrote: It's all going to depend on what we want the upgrade experience to be like for people going from f18 to f19. I believe that FESCo punted it down the road since there wasn't an actual MySQL package maintainer at the time we decided to accept the Feature (just potential ones). The feature page that was approved explicitly says In Fedora 19, MariaDB packages obsoletes MySQL. That means that all packages of MySQL will be automatically replaced by corresponding MariaDB pacakges during update. Mirek but we talked about this in the fesco meeting and decided that we're doing a versioned Obsolete. So if a newer mysql package were to be built, it would no longer be obsoleted. Like I say, my impression is that we deferred the question of what our desired outcome would be if that happened since there wasn't sure to be a mysql packager yet (and still isn't I guess... although we're getting closer to seeing one show up :-) -Toshio pgp821FI6R2Di.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On Fri, Feb 15, 2013 at 05:22:33PM -0500, Honza Horak wrote: Upstream chose the way of drop-in replacement, which means that the same API including file names was actually a feature. Why we don't do it differently in Fedora is obvious -- we don't want to differ from upstream. Actually. this is not obvious. If two packages conflict, it's not a given that we will include both in Fedora and just let them conflict. Many times we require that one or both packages be patched so that they do not conflict. This can cause significant deviation from upstream if upstream is unwilling to rename. In this case, I think that we fall into the following guideline: http://fedoraproject.org/wiki/Packaging:Conflicts#Incompatible_Binary_Files_with_Conflicting_Naming_.28and_stubborn_upstreams.29 as long as there are no clear cases for both packages to be installed simultaneously, explicit Conflicts are permitted at the packager's discretion. So this is allowed, but many other cases of Conflicts (for instance, the recent discussion of Apache OpenOffice vs Libreoffice) would not. -Toshio pgpN0DL8eZJ2j.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On Fri, Feb 15, 2013 at 11:55:51AM +, Jóhann B. Guðmundsson wrote: On 02/15/2013 02:28 AM, Toshio Kuratomi wrote: It's all going to depend on what we want the upgrade experience to be like for people going from f18 to f19. I believe that FESCo punted it down the road since there wasn't an actual MySQL package maintainer at the time we decided to accept the Feature (just potential ones). How could there be since the current mysql maintainers did not orphan mysql ? Well, at this time i don't know of any packagers who want to take it on. There are some people in becoming packagers in order to work on it but that's a bit different. In fact, they might be helped by not having an orphaned mysql package as they could become comaintainers of that package and work their way into being a packager that way. -Toshio pgpA4YYlS64Kg.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On 02/15/2013 09:12 PM, Honza Horak wrote: On 02/15/2013 03:13 PM, Jóhann B. Guðmundsson wrote: On 02/15/2013 12:52 PM, Honza Horak wrote: There is no change, the unit file is still mysqld.service. Hmm.. It's probably better to have an mariadb own unit files and create corresponding mysql symbolic link to those unit files for backwards compatibility at install time. ( we already do so at few places to keep backwards compatibility with the service command to systemd units in few places ) I don't understand what would be the benefit, except that the files wouldn't conflict, but the packages conflict anyway currently. User expectations as in if you install something called mariadb then it's expected that you start the service via systemctl start mariadb.service ( or service mariadb start ). JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On 02/15/2013 09:32 PM, Honza Horak wrote: On 02/15/2013 3:31 PM, Jóhann B. Guðmundsson wrote: On 02/15/2013 01:50 PM, Honza Horak wrote: I still see the differences between MariaDB and MySQL to be very little. Difference never the less and difference in behavior ( which mariadbs own benchmarking on their website proof ) which means every server tweak that has been done for the mysql host has to be redone to take whatever changes and features mariadb introduces. Can you be more specific, what tweaks you mean? Host + mysql optimization. It can take up to three weeks+ to properly tune mysql in real production deployments upstart was never properly integrated into the distribution so it's more accurate to talk about sys V -- Systemd and my advice to any distribution that thinks of making that switch to do so within one release cycle and arguably systemd should never have had that backward compatibility ( to that certain extent it has ) to sys V implemented. Doing so has caused users to expect sysv/upstart like behavior of the init systemd as opposed to approach and embrace it as new technology. That said neither systemd nor Gnome 3 are forks however mariadb is so it will ( as is the nature of all forks ) grow further away from it's origin in time ( how fast that happens depends on it's maintainers ), thus it should be treated as fork and a completely separated database product that is *based* on mysql and packaged as such It's possible, but I see that as another reason to do the switch to mariadb now, than later. Yes but as long as mysql is available in the distribution that replacement migration should not take place from my point of view and when that migration takes place I feel that mariadb should have it's own mdb.cnf file in /etc/ and it's own directory ( which arguably is also inevitable that will happen the future ) which could just be symbolic links to their corresponding mysql file and directory and those links just removed in F21 to complete the replacement migration. Well, in case we wouldn't obsolete mysql -- then either we could do it in F20 and have the same problem a few months later Sorry not following as long as someone is willing to maintain mysql in the distribution we should not be dealing with any kind of potential replacement migration. The reason of replacement is not that nobody is willing to package mysql. The reasons were stated on the feature page: https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB Yeah but at this point in time Oracle has not made that move and if we are doing it because that we are afraid that it will happen ( which comes as a no surprise to anyone if it does ) we should go all the way now in F19 ( instead of waiting for the inevitable ) and drop mysql from the distribution ( which FESCO has to decide on if should be done which is highly unlikely they will atleast I would be surprised if they did but then again I was surprised they approved the replacement migration in the first place ). JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
Am 15.02.2013 22:32, schrieb Honza Horak:
On 02/15/2013 3:31 PM, Jóhann B. Guðmundsson wrote:
On 02/15/2013 01:50 PM, Honza Horak wrote:
I still see the differences between MariaDB and MySQL to be very
little.
Difference never the less and difference in behavior ( which mariadbs
own benchmarking on their website proof ) which means every server
tweak
that has been done for the mysql host has to be redone to take
whatever
changes and features mariadb introduces.
Can you be more specific, what tweaks you mean?
the difference between theory and life
have fun if something like below hits you after
upgrade and you have not the knowledge i had to
fugure out what happens and fix the app temporary
i have seen queries going 1000 times faster after a
minor update because one bugfix introduced create temp
tables for a simple query on a 16 GB table where the next
bugfix corrected this and made a whle application useable
again - the temporary fix was downgrade or change queries
in dbmail to force a index
https://bugzilla.redhat.com/show_bug.cgi?id=515056
--- dbmail-2.2.11/dbmail-message.c 2009-02-02 15:21:55.0 +0100
+++ dbmail-2.2.11-patched/dbmail-message.c 2009-08-01 16:47:38.650404527
+0200
@@ -741,9 +741,10 @@
static struct DbmailMessage * _fetch_full(struct DbmailMessage *self)
{
char *query_template = SELECT messageblk, is_header
- FROM %smessageblks
- WHERE physmessage_id = %llu
- ORDER BY messageblk_idnr;
+ FROM %smessageblks
+ FORCE INDEX (physmessage_id_index)
+ WHERE physmessage_id = %llu
+ ORDER BY messageblk_idnr;
return _retrieve(self, query_template);
}
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On Fri, Feb 15, 2013 at 02:05:48PM +0100, Reindl Harald wrote: * even MySQL 5.5 had a HIDDEN soname break on a minor update with the need of rebuild depending packages and now people will explain me that two different forks are binary compatible - this is very thin ice and can break with ANY minor update AFAICT, this is a different question. IIUC, the plan is for clients to link to the mariadb provided libraries. The mysql package would not ship client libraries. So we're talking about protocol compatibility, not about library SONAME/ABI compatibility. -Toshio pgpW9hf9eKjge.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On 15/02/13 02:15 PM, Jóhann B. Guðmundsson wrote: On 02/15/2013 09:12 PM, Honza Horak wrote: On 02/15/2013 03:13 PM, Jóhann B. Guðmundsson wrote: On 02/15/2013 12:52 PM, Honza Horak wrote: There is no change, the unit file is still mysqld.service. Hmm.. It's probably better to have an mariadb own unit files and create corresponding mysql symbolic link to those unit files for backwards compatibility at install time. ( we already do so at few places to keep backwards compatibility with the service command to systemd units in few places ) I don't understand what would be the benefit, except that the files wouldn't conflict, but the packages conflict anyway currently. User expectations as in if you install something called mariadb then it's expected that you start the service via systemctl start mariadb.service ( or service mariadb start ). Either way, we don't need symlinks, do we? systemd already lets you set aliases. -- 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: Should MariaDB touch my.cnf in %post?
Am 15.02.2013 23:15, schrieb Jóhann B. Guðmundsson: On 02/15/2013 09:12 PM, Honza Horak wrote: On 02/15/2013 03:13 PM, Jóhann B. Guðmundsson wrote: On 02/15/2013 12:52 PM, Honza Horak wrote: There is no change, the unit file is still mysqld.service. Hmm.. It's probably better to have an mariadb own unit files and create corresponding mysql symbolic link to those unit files for backwards compatibility at install time. ( we already do so at few places to keep backwards compatibility with the service command to systemd units in few places ) I don't understand what would be the benefit, except that the files wouldn't conflict, but the packages conflict anyway currently. User expectations as in if you install something called mariadb then it's expected that you start the service via systemctl start mariadb.service ( or service mariadb start ) to fullfill them really it would need a alias in the one or other direction - most people will type systemctl start mysqld.service and have a big WTF if they need to seacrh the web besides real compatibility and transition of data one of the reasons why in my opinion it is pretty dumb to hurry this for F10 instead take a breath and come up with a well planned fianl decision in F20, mysql 5.5 is maintained uptream for a long time and nobody will eat it away signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
Am 16.02.2013 01:29, schrieb Toshio Kuratomi: On Fri, Feb 15, 2013 at 02:05:48PM +0100, Reindl Harald wrote: * even MySQL 5.5 had a HIDDEN soname break on a minor update with the need of rebuild depending packages and now people will explain me that two different forks are binary compatible - this is very thin ice and can break with ANY minor update AFAICT, this is a different question. IIUC, the plan is for clients to link to the mariadb provided libraries. The mysql package would not ship client libraries. So we're talking about protocol compatibility, not about library SONAME/ABI compatibility and which fool has written the feature page without knowing what binary compatibility is or if he knows to get the Fesco OK by promise impossible things there? http://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB MariaDB is binary compatible with MySQL of the same major version, so we don't need to change anything in packages depending on libmysqlclient.so signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Le samedi 16 février 2013 à 00:15 +0100, Martin Sourada a écrit : On Thu, 14 Feb 2013 19:13:08 -0800 Adam Williamson wrote: On 09/02/13 01:03 AM, Kevin Kofler wrote: Last I checked, GDM also hid that feature so well that many users missed it. In fact, unless this changed recently, when you input your user name, the option is NOT shown, it only appears after you confirm your user name, during the password prompt. Well, yes, that's true. How does that count as 'well hidden'? It's not like you can login without entering your password. What about users *without* password? It's insecure (in most cases), but possible. One potential idea would be to just show the password prompt and wait to type enter. But if that's not how it work now ( I didn't test ), I guess opening a bug on bugs.gnome.org is the way to have it fixed. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
