Re: ConsoleKit and esound retirement
Hi, On 02/13/2013 04:26 AM, DJ Delorie wrote: Hmm, we still have xmms in the repo? /me is very glad we still have xmms in the repo Have you tried using Audacious ? You can set it to classic mode, at which point it user experience is identical to xmms. With the advantage that it uses a modern toolkit, more modern plumbing in various places, and it is actively maintained both in Fedora and upstream. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On 13 February 2013 09:21, Hans de Goede wrote: > Hi, > > Have you tried using Audacious ? You can set it to > classic mode, at which point it user experience is > identical to xmms. > > With the advantage that it uses a modern toolkit, more > modern plumbing in various places, and it is actively > maintained both in Fedora and upstream. > That seems like exactly what should go in the dead.package file :-) -- Mat Booth http://fedoraproject.org/get-fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
headsup for llvm-3.2
Hi, I spend a little time recently working on the llvm package trying to fix a few Fedora bugs that have been open for a while... I also think we should really get llvm-3.2 into Fedora 19. I have done a few tests and scratch builds in https://bugzilla.redhat.com/show_bug.cgi?id=903100 and am planning to build llvm-3.2 in rawhide this week hopefully. I was hoping to get a nod first from the package owner (Michel Salim) but I haven't heard from him yet - I dunno if he is away or just busy. Anyway seems to me better to do the version as soon as possible to get it into F19 Rawhide early for more testing. I think the biggest reverse dependency is mesa which needs to be updated to 9.1-devel, which Dave Airlie has already after talking to him. If you have packages that need rebuilding for a llvm version bump let me know if you want help with them otherwise I will try to fix any dependency breakage that occurs. Jens -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
Please can we test this on rawhide first if anything? I'm pretty sure a lot of thing are still ck dependant. We are still trying to catch up to systemd. Just because some other distro did it doesn't mean we should do it too. Dan On Tuesday, February 12, 2013, Lennart Poettering wrote: > Heya, > > since a while now logind has replaced CK in Fedora. I'd like to retire > it entirely from the distribution now. > > Most deps on CK are gone. Holdouts are "cdm", "lightdm", "lxsession", > "lxdm". > > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > This page doesn't say anything about retiring packages other still > depend on... > > I am tempted to just retire CK ignoring the remaining dependencies, in > the hope this will put the pressure on the folks involved to update > their stuff... > > Getting rid of CK in those packages is dead simple BTW. Just disable it > in the packages, but make sure pam_systemd is in the PAM stack for your > greeter tool. It's basically about removing code, not about adding > new code -- adding new code is only necessary if you want to improve > your DM to handle multi-seat setups, too (which is a new feature of > logind, not available in CK[1]). For details, see: > > http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers > > I'd also like to retire "esound" finally. Currently, adplay, ayttm, > dopewars, e16, gnome-libs, gnubg, lxdream, moon-buggy, spacechart, > xarchon, xmms-esd still use it. esd of course has been deprecated and > dead since many years, the packages which still use it really should > wake up one day. So here, too, I'd just like to retire the package... > > Alternatively, somebody else can take these over, but honstely I'd > rather see them removed than continue to bitrot in our repository... > > Lennart > > Footnotes: > > [1] If you are interested in adding proper multi-seat support to the DM > of your choice, then we might be able to supply you with a free set of > multi-seat hardware so that you can actually make it work. Ping me. > > -- > Lennart Poettering - Red Hat, Inc. > -- > 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 Wed, Feb 13, 2013 at 10:44 AM, Dan Mashal wrote: > Please can we test this on rawhide first if anything? I'm pretty sure a lot > of thing are still ck dependant. We are still trying to catch up to systemd. > > Just because some other distro did it doesn't mean we should do it too. Retirement of packages really only should ever happen on rawhide and I believe that's what is being discussed. 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/12/2013 09:10 PM, Sergei Golubchik wrote: Okay, so you suggest to do nothing - neither append the includedir line to the existing my.cnf nor let mariadb read /etc/my.cnf.d/ automatically and implicitly. That's fine :) I was only trying to find an alternative to "let mariadb read /etc/my.cnf.d implicitly" - because I don't like an idea of adding more magic to the server, it has more than enough of it already. Going back to the original idea -- it was that users will be confused if they'll see files under /etc/my.cnf.d/* which they can enhance but it won't take any effect. Well, adding a README file into /etc/my.cnf.d or some comments into files in that directory or even both, that would simply describe the need of !includedir, should just work. That shouldn't do any harm and should reduce confusing. Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
Hi, Reindl! On Feb 13, Reindl Harald wrote: > > a few lines in the SPEC files %install section would simply > remove the folder and this files - i know a lot of mysql > setups and have never seen one with includes and if > so then they would be created by the admin Sure, that's only in the mariadb.org rpms. We've added the folder specifically for the purpose of packaging. The server rpm includes the server config file, the client rpm - the client config file. The shared lib rpm includes the shared lib cnf file. And yes, we've started (in 10.0) to package certain plugins separately (CassandraSE comes in a separate rpm). They will come with their own cnf files too. Even if such a file won't auto-enable the plugin, it'll have plugin configuration options explained. These options can not go into the /etc/my.cnf because the plugin might be a third-party, we may not know in advance all mariadb plugins that a user might want to install. And speaking about /etc/php.d/ and /etc/httpd/conf.d/ - I'm not the only one who can see the benefits of a modular configuration system, as compared to one monolitic config file :) Regards, Sergei -- MariaDB.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On 02/12/2013 06:46 PM, Honza Horak wrote:
Hi folks,
I'd like to share an idea related to MySQL->MariaDB move, that may be a
bit controversial. Speaking about default case in Fedora, MySQL has used
only one file at /etc/my.cnf to configure server, libraries,
command-line utilities, etc.
MariaDB uses by default /etc/my.cnf and
/etc/my.cnf.d/{client,server,..}.cnf files, while all the /etc/my.cnf.d
directory is included using !includedir statement in /etc/my.cnf.
The problem is, that after replacing MySQL with MariaDB existed my.cnf
won't get updated (uses "%config(noreplace)") and then users will be
confused by having /etc/my.cnf.d/* files, which won't be used.
Just add README file to /etc/my.cnf.d/ mentioning that /etc/my.cnf must
contain that includedir line or those file won't be used
Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On Tue, Feb 12, 2013 at 4:51 PM, Lennart Poettering wrote: > On Tue, 12.02.13 13:52, Jon Ciesla (limburg...@gmail.com) wrote: > > > > > So to clarify, you're not actually retiring anything currently, just > > > > expressing to the community that you'd like to and that we should > work > > > > toward making that possible? > > > > > > Well, I am just checking before I do something whether I can actually > do > > > it. That's all. By next week or so I will either have retired the > > > packages (which I'd prefer) or somebody else took them over (which I'd > > > prefer not to do, but which we can do too, if the retro-computing folks > > > step up...) > > > > I'd prefer that you orphan them, and mail the list, ccing -owner for > > each dependency, that you're doing so. That said, I maintain gnugb, and > > was able to easily remove the esound requirement. If no one else wants > to > > maintain esound, I will, even if only long enough to excise it from the > > packages that need it. > > OK, if that's what you want. I have now orphaned esound. Please take it > over. > > Thanks, but it looks like someone beat me to it. -J > Lennart > > -- > Lennart Poettering - Red Hat, Inc. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: headsup for llvm-3.2
On 13 Feb 2013 09:37, "Jens Petersen" wrote: > > Hi, > > I spend a little time recently working on the llvm package trying > to fix a few Fedora bugs that have been open for a while... > > I also think we should really get llvm-3.2 into Fedora 19. > I have done a few tests and scratch builds in > https://bugzilla.redhat.com/show_bug.cgi?id=903100 > and am planning to build llvm-3.2 in rawhide this week hopefully. Are there any plans to bring this to F18? There was talk about bringing 3.1 to F17 including some support from the Mesa guys but then nothing actually happened. I would really like it if I could go through F18 without having to build my own private parallel installable llvm 3.2 (i need the c++11 memory model support introduced in 3.2 for my lock free algorithms). -- 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:15 PM, Sergei Golubchik wrote: On Feb 13, Reindl Harald wrote: a few lines in the SPEC files %install section would simply remove the folder and this files - i know a lot of mysql setups and have never seen one with includes and if so then they would be created by the admin I don't think the directory is so bad that we should remove it as a whole. We usually don't want to differ from upstream (MariaDB uses the directory) and staying with old design only because admins are used to that -- well, we won't destroy anything, they can still ignore the directory if they want, but we can give the opportunity for others that like the idea with my.cnf.d. We also don't do this change within a regular update, but as a part of quite big step (moving to MariaDB). And speaking about /etc/php.d/ and /etc/httpd/conf.d/ - I'm not the only one who can see the benefits of a modular configuration system, as compared to one monolitic config file :) +1 Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On Tue, 12 Feb 2013 20:47:50 -0600, Bruno Wolff III wrote: > On Wed, Feb 13, 2013 at 00:26:28 +0100, >Lennart Poettering wrote: > > > >Hmm, we still have xmms in the repo? Both Debian and Gentoo killed it > >years ago... And I though those were the conservative distributions... > > I wanted to keep it in Fedora a little bit longer since I have been using it. > But if it is causing problems, I won't stand in the way of dropping it. It is causing problems: http://bugz.fedoraproject.org Plus the several closed tickets (for xmms and xmms-pulse) that have not been responded to by any package maintainer at all. -- Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc7.git0.1.fc19.x86_64 loadavg: 0.08 0.22 0.20 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Convert-Age-0.04.tar.gz uploaded to lookaside cache by normunds
A file has been added to the lookaside cache for perl-Convert-Age: 79b4069c89a7cdf28444d5ea5ef72f21 Convert-Age-0.04.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-Convert-Age] Initial import (#903824).
commit 8bd2c1a9e6dbecb41fc058dbd8bc1d246718d24d
Author: Normunds Neimanis
Date: Wed Feb 13 17:14:49 2013 +0200
Initial import (#903824).
.gitignore|1 +
perl-Convert-Age.spec | 54 +
sources |1 +
3 files changed, 56 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..b2c8c1b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Convert-Age-0.04.tar.gz
diff --git a/perl-Convert-Age.spec b/perl-Convert-Age.spec
new file mode 100644
index 000..b5b6cb6
--- /dev/null
+++ b/perl-Convert-Age.spec
@@ -0,0 +1,54 @@
+Name: perl-Convert-Age
+Version: 0.04
+Release: 1%{?dist}
+Summary: Perl module that converts integer seconds into a "compact" form
and back
+
+Group: Development/Libraries
+License: GPL+ or Artistic
+URL: http://search.cpan.org/dist/Convert-Age
+Source0:
http://search.cpan.org/CPAN/authors/id/C/CF/CFEDDE/Convert-Age-%{version}.tar.gz
+
+
+BuildArch: noarch
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Exporter)
+
+
+Requires: perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+
+
+%description
+This is a rather simple perl module for dealing with time intervals.
+Convert 189988007 seconds to compact form: 6y7d10h26m47s
+Convert compact 5h37m5s to seconds: 20225
+
+
+%prep
+%setup -q -n Convert-Age-%{version}
+
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+
+%install
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+%{_fixperms} %{buildroot}/*
+
+
+%check
+make test
+
+
+%files
+%doc Changes README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+
+%changelog
+* Wed Jan 23 2013 Normunds Neimanis 0.04-1
+- Package for current Fedora
diff --git a/sources b/sources
index e69de29..ac64187 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+79b4069c89a7cdf28444d5ea5ef72f21 Convert-Age-0.04.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
Unable to push update of emacs-24.2-6.fc18 to stable
Hello, as an provenpackage I have introduced an upstream patch to Emacs and have create an update in bodhi. After ten days I have to recognize, that I'm unable to push this update to the stable repository because there is no 'mark as stable' link on the UI. So I have ask the owner of the package for help. 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. So, I would like to ask, want we have to do to getting the package into the stable repository. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self Introduction
As suggested by https://fedoraproject.org/wiki/Join_the_package_collection_maintainers I am writing to introduce myself. I have submitted a package review request for the spice-html5 javascript SPICE client here: https://bugzilla.redhat.com/show_bug.cgi?id=910793 I'm a long time Free Software advocate, and sometimes developer. I'm mostly known for my work with Wine. I wrote this code as part of my mid life crisis, and am trying to get it released in a useful form. Cheers, Jeremy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: the need of "Offline Updates"
Am 13.02.2013 08:45, schrieb Matthias Runge: > On 02/12/2013 02:25 PM, Reindl Harald wrote: >> >> the point is that i NEVER EVER want to stop any service by a RPM >> update and define this GLOBAL for all services with one single >> config line >> > Well, although I understand your intention. > > But, e.g. if openssl is updated for security issues, all dependent > services need to be restarted. If not, you're still e.g. vulnerable. > That can't be your wish. i know that on my own BUT i restart services controlled and not to a random point in time, if you maintain more than 20 servers you want to schedule your service restarts signature.asc Description: OpenPGP digital signature -- 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 Wed, Feb 13, 2013 at 10:24 AM, Jochen Schmitt wrote: > Hello, > > as an provenpackage I have introduced an upstream patch to Emacs > and have create an update in bodhi. After ten days I have to recognize, > that I'm unable to push this update to the stable repository because there > is no 'mark as stable' link on the UI. So I have ask the owner of the > package for help. > > 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. > > So, I would like to ask, want we have to do to getting the > package into the stable repository. Wait 4 more days or get 2 more karma. IIRC, critpath updates have to wait for 2 weeks before they can be pushed if they do not have sufficient karma. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
Am 13.02.2013 13:34, schrieb Honza Horak: > On 02/12/2013 09:10 PM, Sergei Golubchik wrote: >> Okay, so you suggest to do nothing - neither append the includedir line >> to the existing my.cnf nor let mariadb read /etc/my.cnf.d/ automatically >> and implicitly. >> >> That's fine :) >> I was only trying to find an alternative to "let mariadb read >> /etc/my.cnf.d implicitly" - because I don't like an idea of adding more >> magic to the server, it has more than enough of it already. > > Going back to the original idea -- it was that users will be confused if > they'll see files under /etc/my.cnf.d/* > which they can enhance but it won't take any effect. Well, adding a README > file into /etc/my.cnf.d or some comments > into files in that directory or even both, that would simply describe the > need of !includedir, should just work. > That shouldn't do any harm and should reduce confusing a few lines in the SPEC files %install section would simply remove the folder and this files - i know a lot of mysql setups and have never seen one with includes and if so then they would be created by the admin in case of server software it is generally annoying if random config snippets which may come with updates change the behavior the same affects /etc/php.d/ and /etc/httpd/conf.d/ install a package on a production server does usually NOT mean "hey i want to have this enabled now only because the package is there" 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/13/2013 12:34 PM, Honza Horak wrote: On 02/12/2013 09:10 PM, Sergei Golubchik wrote: Okay, so you suggest to do nothing - neither append the includedir line to the existing my.cnf nor let mariadb read /etc/my.cnf.d/ automatically and implicitly. That's fine :) I was only trying to find an alternative to "let mariadb read /etc/my.cnf.d implicitly" - because I don't like an idea of adding more magic to the server, it has more than enough of it already. Going back to the original idea -- it was that users will be confused if they'll see files under /etc/my.cnf.d/* which they can enhance but it won't take any effect. Well, adding a README file into /etc/my.cnf.d or some comments into files in that directory or even both, that would simply describe the need of !includedir, should just work. That shouldn't do any harm and should reduce confusing. Hmm Is not the correct course here that mariadb comes with it's own mdb.cf file and it's own mdb.d directory? Surely you are not honestly consider replacing mysql installation with mariadb on upgrades? I for one would not want to find out that my mysql install would have been replaced with mariadb on upgrade ( or visa versa ) JBG -- 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 Wed, 13 Feb 2013 16:24:07 +0100, Jochen Schmitt wrote: > Hello, > > as an provenpackage I have introduced an upstream patch to Emacs > and have create an update in bodhi. After ten days I have to recognize, > that I'm unable to push this update to the stable repository because there > is no 'mark as stable' link on the UI. So I have ask the owner of the > package for help. > > 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. > > So, I would like to ask, want we have to do to getting the > package into the stable repository. 10 days? Then it sounds as if you need to wait for four more days: http://fedoraproject.org/wiki/Updates_Policy#Updates_to_.27critical_path.27_packages -- Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc7.git0.1.fc19.x86_64 loadavg: 0.12 0.14 0.13 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On Wed, 13 Feb 2013 10:21:35 +0100, Hans de Goede wrote: > Hi, > > On 02/13/2013 04:26 AM, DJ Delorie wrote: > > > >> Hmm, we still have xmms in the repo? > > > > /me is very glad we still have xmms in the repo > > Have you tried using Audacious ? You can set it to > classic mode, at which point it user experience is > identical to xmms. Except for the double-sized skinned mode, which is no longer available, because nobody has interest in maintaining it. Occasionally, a user notices that it's missing, but most users seem to like the GTK+ mode better anyway. And for the future that could mean the Winamp classic mode will be removed eventually, too. If it must be a skinned interface like Winamp, there are other players that support such skins, such as "qmmp": yum info qmmp -- Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc7.git0.1.fc19.x86_64 loadavg: 0.00 0.06 0.11 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Convert-Age/f16] Initial import (#903824).
Summary of changes: 8bd2c1a... Initial import (#903824). (*) (*) 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 Wed, Feb 13, 2013 at 16:10:58 +0100, Michael Schwendt wrote: On Tue, 12 Feb 2013 20:47:50 -0600, Bruno Wolff III wrote: On Wed, Feb 13, 2013 at 00:26:28 +0100, Lennart Poettering wrote: > >Hmm, we still have xmms in the repo? Both Debian and Gentoo killed it >years ago... And I though those were the conservative distributions... I wanted to keep it in Fedora a little bit longer since I have been using it. But if it is causing problems, I won't stand in the way of dropping it. It is causing problems: http://bugz.fedoraproject.org Plus the several closed tickets (for xmms and xmms-pulse) that have not been responded to by any package maintainer at all. I'll retire it before F20 is branched. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
On Wed, Feb 13, 2013 at 10:26 AM, Jeremy White wrote: > I am writing to introduce myself. I have submitted a package review > request for the spice-html5 javascript SPICE client here: > https://bugzilla.redhat.com/show_bug.cgi?id=910793 I'm not a sponsor (yet?), but I did an informal review of your package and put my notes in the bugzilla ticket. -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
xmms being retired as of F19
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: GLIBC 2.17
On 01/28/2013 03:02 AM, Florian Weimer wrote: GLIBC 2.17 was released at the end of 2012; we have been closely tracking the GLIBC 2.17 development code in Fedora Rawhide and addressing any issues as they arise. The __secure_getenv to secure_getenv renaming need to be reflected in a few packages (as of Fedora 18): octave-3.6.3-2.fc18.2.src.rpm This was from octave's use of gnulib. I am told gnulib has since fixed this and newer versions of octave will have this. Thanks for the heads up. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora ARM weekly status meeting 2013-02-13
Good Morning all, Please join us today (Wednesday, February 13th) at 4PM EST (9PM UTC) for the Fedora ARM weekly status meeting in #fedora-meeting-1 on Freenode. On the agenda so far.. 0) Status of ACTION items from our previous meeting 1) Problem packages 2) Kernel updates in F17, F18 causing issues 3) Mass rebuild - Adding additional HSV builders, status update 4) Open Floor If there is something that you would like to discuss that isn't mentioned please feel free to bring it up at the end of the meeting or send an email to the list. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Wednesday's FESCo Meeting (2013-02-13)
On Tue, Feb 12, 2013 at 09:21:04PM +0100, Marcela Mašláňová wrote: > Following is the list of topics that will be discussed in the FESCo > meeting Wednesday at 18:00UTC (1:00pm EST, 19:00 CET) in #fedora-meeting on > irc.freenode.net. > > Links to all tickets below can be found at: > https://fedorahosted.org/fesco/report/9 > > = Followups = > This morning I saw that the biosdevname feature author had added some discussion ( http://lists.fedoraproject.org/pipermail/devel/2013-February/178226.html ) to the udev Predictable Network Names Feature: ( https://fedorahosted.org/fesco/ticket/1022 ) Do we want to revisit it or parts of it? -Toshio pgpXpCMlqjYhq.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 Wed, Feb 13, 2013 at 01:34:36PM +0100, Honza Horak wrote: > On 02/12/2013 09:10 PM, Sergei Golubchik wrote: > >Okay, so you suggest to do nothing - neither append the includedir line > >to the existing my.cnf nor let mariadb read /etc/my.cnf.d/ automatically > >and implicitly. > > > >That's fine :) > >I was only trying to find an alternative to "let mariadb read > >/etc/my.cnf.d implicitly" - because I don't like an idea of adding more > >magic to the server, it has more than enough of it already. > > Going back to the original idea -- it was that users will be confused > if they'll see files under /etc/my.cnf.d/* which they can enhance but > it won't take any effect. Well, adding a README file into > /etc/my.cnf.d or some comments into files in that directory or even > both, that would simply describe the need of !includedir, should just > work. That shouldn't do any harm and should reduce confusing. > +1 This seems like a good way of getting the user's attention without being intrusive. -Toshio pgpERB0wV71kN.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how reload udev rules and systemd on F18
On Qua, 2013-02-13 at 04:00 +0100, Lennart Poettering wrote: > On Sat, 09.02.13 13:18, Sérgio Basto (ser...@serjux.com) wrote: > > > On Sex, 2013-02-08 at 10:08 +0100, Florian Weimer wrote: > > > On 02/05/2013 07:43 PM, Sérgio Basto wrote: > > > > > > > Any advises or opinions ? > > > > > > I think you haven't yet described the original problem you're trying to > > > solve. > > > > Hi, > > > > When we install VirtualBox from rpmfusion , I'd like create /dev/vboxusb > > proxies to host system without reboot box. I want that ends with: > > Well, be that as it may. It's not OK to retrigger all devices. That's an > admin feature, and a feature for very specific usecases, but it's > nothing you are allowed to just call in package post scripts... > > Basically, you cannot do this. You must either tell the admin to invoke > "udevadm trigger" on his own, or just not do it. Hi, OK but we don't have any command to trigger only /dev/vboxusb/* ? > > > > ll /dev/vboxusb -d > > drwxr-x--- 4 root vboxusers 80 Fev 5 18:42 /dev/vboxusb > > > > ll /dev/vboxusb > > total 0 > > drwxr-x--- 2 root vboxusers 80 Fev 9 11:19 002 > > drwxr-x--- 2 root vboxusers 60 Fev 5 18:42 001 > > > > the actual scriptlet: > > # Assign USB devices > > if /sbin/udevadm control --reload-rules >/dev/null 2>&1 > > Redundant. what you mean by redundant ? if I not reboot system, do I need --reload-rules on F16+ ? (when install the package ) and when the package is remove, how I clean it up ? (without reboot) > > then > >/sbin/udevadm trigger --subsystem-match=usb --action=add >/dev/null > > Not OK. I know, but if we don't have other solution I will keep it. > > 2>&1 || : > >/sbin/udevadm settle >/dev/null 2>&1 || : > > Pointless, unless you are LVM, which you are not. OK , I will remove it Many thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
> Have you tried using Audacious ? Just did. No thanks. /me uninstalls those five RPMs... > You can set it to classic mode, at which point it user experience is > identical to xmms. No, it's not. It's close enough to fool someone who doesn't use xmms regularly, but it's different enough to really annoy those of us who do. Reminds me of a friend who hates anything gtk-on-windows because it looks enough like windows that your instinct is to use your windows techniques, but it's different enough to burn you every time you try that. > With the advantage that it uses a modern toolkit, Disadvantage, if you ask me. First thing audacious did was spew random errors to the screen and change my Firefox and emacs cursors. Then it ask which of the most recent minecraft jar files I wanted to listen to. When I finally located my *music* folder in its playlist chooser, it refused to play my shoutcast streams, instead filling the log window with more useless errors. I managed to find one .wav it would play, and it defaulted to 120% volume which made it sound like crap (well, more like crap, since I still haven't figured out how to get pulseaudio to use my digital audio outputs). All this was before I figured out how to switch it to Winamp mode (not xmms mode) but it doesn't support all the customization options that xmms does, so it didn't look or act like xmms. Plus, the playlist management system is completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: the need of "Offline Updates"
> But, e.g. if openssl is updated for security issues, all dependent > services need to be restarted. If not, you're still e.g. vulnerable. > That can't be your wish. Ah, but if sshd is restarted in the middle of the update, and you ssh'd into the machine to do the update, it kills the install halfway through and leaves you with an unusable system until you log in on the console, clean up the rpm database, fix ssh, and restart it all. DAMHIKT. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On Wed, 13 Feb 2013 13:15:07 -0500, DJ Delorie wrote: > First thing audacious did was spew > random errors to the screen and change my Firefox and emacs cursors. Interesting, but here it has never done that before. > Then it ask which of the most recent minecraft jar files I wanted to > listen to. When I finally located my *music* folder in its playlist > chooser, it refused to play my shoutcast streams, instead filling the > log window with more useless errors. I managed to find one .wav it > would play, Odd. It can certainly play a lot more formats than just WAV, though for MP3'n'stuff you need plug-in packages from RPM Fusion. > and it defaulted to 120% volume which made it sound like > crap (well, more like crap, since I still haven't figured out how to > get pulseaudio to use my digital audio outputs). It includes an ALSA output plug-in, too, but defaults to Pulse Audio. Apparently, you've not used XMMS with "xmms-pulse" either (because that one suffers from several volume related issues). -- Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc7.git0.1.fc19.x86_64 loadavg: 0.61 0.46 0.32 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how reload udev rules and systemd on F18
On Wed, Feb 13, 2013 at 6:29 PM, Sérgio Basto wrote: > Hi, OK but we don't have any command to trigger only /dev/vboxusb/* ? You are not supposed to trigger changes for hardware on the running system, *ever*. Package scripts are package scripts, not magic system administration tools. Special device nodes which are not interesting for anything else, and it is absolutely guaranteed that there is no current user at this moment, can be triggered that way, check: --sysname-match= in the udev man page. Everything else is not ok to touch. >> > the actual scriptlet: >> > # Assign USB devices >> > if /sbin/udevadm control --reload-rules >/dev/null 2>&1 >> >> Redundant. > > what you mean by redundant ? if I not reboot system, do I need > --reload-rules on F16+ ? (when install the package ) > and when the package is remove, how I clean it up ? (without reboot) Udev finds that out on its own, has done that in the past and still does that. >> > then >> >/sbin/udevadm trigger --subsystem-match=usb --action=add >/dev/null >> >> Not OK. > > I know, but if we don't have other solution I will keep it. Please remove it. You are doing *packaging* not system *administration*. All currently running hardware is taboo for package scripts to even look at it. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
> and change my Firefox and emacs cursors. And now I have to restart my entire session to reset my gtk themes, because of one rogue app. Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Convert-Age/f18] Initial import (#903824).
Summary of changes: 8bd2c1a... Initial import (#903824). (*) (*) 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 Wed, 13.02.13 02:44, Dan Mashal (dan.mas...@gmail.com) wrote: > Please can we test this on rawhide first if anything? I'm pretty sure a lot > of thing are still ck dependant. We are still trying to catch up to systemd. So, in contrast to the esound discussion I do not sense too much opposition to me just retiring CK. So I'd probably do that in Rawhide next week or so. CK would hence disappear in F19, but would give everybody time until the branch or freeze or so to fix their packages... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
DJ Delorie wrote: > And now I have to restart my entire session to reset my gtk themes, > because of one rogue app. Thanks. You have other serious system issues not affiliated with Audacious if this is the case. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[cpanspec] - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
commit c563c4ccea242ba86786ef34fd25459281e7b42d
Author: Dennis Gilmore
Date: Wed Feb 13 13:01:42 2013 -0600
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
cpanspec.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/cpanspec.spec b/cpanspec.spec
index cbcfcda..2f0428c 100644
--- a/cpanspec.spec
+++ b/cpanspec.spec
@@ -1,6 +1,6 @@
Name: cpanspec
Version:1.78
-Release:12%{?dist}
+Release:13%{?dist}
Summary:RPM spec file generation utility
License:GPL+ or Artistic
Group: Development/Tools
@@ -53,6 +53,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man1/*
%changelog
+* Wed Feb 13 2013 Fedora Release Engineering
- 1.78-13
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
+
* Wed Jul 18 2012 Fedora Release Engineering
- 1.78-12
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_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: ConsoleKit and esound retirement
> You have other serious system issues not affiliated with Audacious if > this is the case. If "I don't run gnome" is considered "other serious system issues", I suppose so. Restarting didn't help, I still had the wrong cursor in emacs and firefox, but only the emacs and firefox run remotely back to my display, the local emacs and firefox had the right cursors. I still can't figure out how to get rid of the wrong cursor without also getting rid of the right cursors, so I'm currently *not* using Xcursor because the theme stuff is so confusing. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[ctstream] - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
commit 4abd3622ec4d338c6e292e7ed199b597a82d7ab6
Author: Dennis Gilmore
Date: Wed Feb 13 13:16:23 2013 -0600
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
ctstream.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/ctstream.spec b/ctstream.spec
index c25bba6..4e4a942 100644
--- a/ctstream.spec
+++ b/ctstream.spec
@@ -1,6 +1,6 @@
Name: ctstream
Version:6
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Get URLs of Czech Television video streams
Group: Applications/Internet
License:GPL+
@@ -23,6 +23,9 @@ install %{SOURCE0} %{buildroot}%{_bindir}/%{name}
%{_bindir}/*
%changelog
+* Wed Feb 13 2013 Fedora Release Engineering
- 6-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
+
* Tue Oct 16 2012 Petr Pisar - 6-2
- Add empty %%build section for hooks
--
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 Wed, 13 Feb 2013 12:59:46 -0600, Michael Cronenworth wrote: > DJ Delorie wrote: > > And now I have to restart my entire session to reset my gtk themes, > > because of one rogue app. Thanks. > > You have other serious system issues not affiliated with Audacious if > this is the case. Hmmm, Audacious uses GTK+ v3, whereas XMMS uses GTK+ v1. We haven't heard what desktop environment (or plain window manager) is being used. Perhaps it can be disturbed by gtk3? It wouldn't be the first time that a modern application exposes a bug/deficiency in a window manger. Anyway, I do use Emacs, too, and my customized cursor doesn't get disturbed by Audacious. ;) -- Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc7.git0.1.fc19.x86_64 loadavg: 0.04 0.06 0.07 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: the need of "Offline Updates"
Am 13.02.2013 19:19, schrieb DJ Delorie: > >> But, e.g. if openssl is updated for security issues, all dependent >> services need to be restarted. If not, you're still e.g. vulnerable. >> That can't be your wish. > > Ah, but if sshd is restarted in the middle of the update, and you > ssh'd into the machine to do the update, it kills the install halfway > through and leaves you with an unusable system until you log in on the > console, clean up the rpm database, fix ssh, and restart it all. DAMHIKT. this is fixed in the meantime so that the current sshd process with your sessions get's no longer killed, this problem was introduced with systemd F16/F17 upgrade and is a very good example for "not do it this way" because it killed also "yum complete-transaction" repeatly fact is you have NO IDEA in a larger update what happens if services are restarted randomly and so it is very bad to go this windows way and make admins life harder bother the ordinary GUI user with OfflineSystemUpdates* but leave us yum-admin-folks completly in peace at all while assume that we are knowing what we are doing - keep your fingers as much off my environment as possible * https://fedoraproject.org/wiki/Features/OfflineSystemUpdates signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
Matt Domsch (matt_dom...@dell.com) said: > The RHEL model of disabling biosdevname by some hardware > vendors, at installtime, is not accounted for in the current proposal. I find this model pretty broken - if we want to have clear semantics that are easily explainable to users and admins, we don't want the namespaces being used to be conditional on the hardware vendor (other than insasmuch as they have proper information in their bios.) I know how RHEL 6 did it, but that was a matter of expediency with late change. > I agree, that's the right approach, which is why Dell pushed to get > the SMBIOS and PCI specifications amended to put explicit per-device > information into there. I hope we can work together to do likewise > for cases coming up now that aren't currently addressed. > > If we can solve the installtime naming convention choice to not > eliminate biosdevname, be able to disable systemd/udevd naming, and > have the default be possible on a per-system-vendor basis, and solve > the NPAR/SR-IOV/Mellanox naming problems, then I can support this > proposal. Without fixing these shortcomings though, my customers will > have a fit at me. If you're agreeing that biosdevname should be limited to type9/type41 (if I'm reading you right), and if the systemd/udev names still use those fields, what parts of biosdevname are you still requiring? The actual namespace used, or something else? Bill -- 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
> Wait 4 more days or get 2 more karma. IIRC, critpath updates have to > wait for 2 weeks before they can be pushed if they do not have sufficient > karma. More testing is preferable, of course. I'd help except I don't know my way around emacs. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes for today's FESCo Meeting (2013-02-13)
=== #fedora-meeting: FESCO (2013-02-13) === Meeting started by mmaslano at 18:00:20 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-02-13/fesco.2013-02-13-18.00.log.html . Meeting summary --- * init process (mmaslano, 18:00:36) * #896 Refine feature process (mmaslano, 18:03:17) * ACCEPTED: the new planning process was approved with change of name from features to changes (+7,-0,0) (mmaslano, 18:18:34) * #980 Add "activate contingency" points to the features process (mmaslano, 18:19:24) * ACCEPTED: We have an "check for contingency" point now. 1) Document/emphasize that this is when FESCo will decide on activating the contingency. 2) We recognize that deviations from that point will happen, but we don't establish a detailed policy for them at this time. 3) Close ticket, unless there are other changes. (+5,-0,0) (mmaslano, 18:44:56) * #1005 At f19 branching time, drop inheritance in rawhide (mmaslano, 18:45:08) * #988 F19 Feature: System Configuration Shell - https://fedoraproject.org/wiki/Features/SystemConfigurationShell (mmaslano, 19:03:10) * AGREED: Defer 1 week, asking 1) the people who will implement this to add themselves as co-owners, 2) to explicitly answer relationship to OpenLMI (even if it is "separate and distinct"), and auto-close on no response. (+7,-0,0) (mmaslano, 19:17:13) * #1036 F19 Feature: Enterprise / distributed two-factor authentication - https://fedoraproject.org/wiki/Features/EnterpriseTwoFactorAuthentication (mmaslano, 19:17:27) * AGREED: reject feature; let feature owners reopen and resubmit when they are interested (+5,-0,0) (mmaslano, 19:22:27) * #1040 F19 Feature: firewalld Lockdown - https://fedoraproject.org/wiki/Features/FirewalldLockdown (mmaslano, 19:22:38) * AGREED: firewalld lockdown feature was accepted (+5.5,-0,0) (mmaslano, 19:37:42) * #1085 2013-02-13 meeting feature voting (mmaslano, 19:37:56) * AGREED: all features from new business are accepted "en bloc" (+5,-0,0) (mmaslano, 19:45:10) * Next week's chair (mmaslano, 19:45:31) * mitr will be chairman next week (mmaslano, 19:47:57) * Open Floor (mmaslano, 19:48:05) * LINK: http://lists.fedoraproject.org/pipermail/devel/2013-February/178226.html (abadger1999, 19:56:00) * LINK: https://admin.fedoraproject.org/pkgdb/acls/name/biosdevname (mitr, 19:58:41) Meeting ended at 20:13:21 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * mmaslano (63) * mitr (58) * nirik (55) * abadger1999 (40) * notting (24) * jreznik (23) * jwb (22) * zodbot (11) * pjones (11) * mattdm (9) * dgilmore (7) * fedora_richie (3) * drago01_ (2) * sgallagh (0) * t8m (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[dspam] - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
commit 5628b9b6c6981c466235fe2b0ca6c321a1d8f17a
Author: Dennis Gilmore
Date: Wed Feb 13 14:20:26 2013 -0600
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
dspam.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/dspam.spec b/dspam.spec
index 1df1324..a9c109c 100644
--- a/dspam.spec
+++ b/dspam.spec
@@ -11,7 +11,7 @@
Summary:A library and Mail Delivery Agent for Bayesian SPAM
filtering
Name: dspam
Version:3.10.2
-Release:6%{?dist}
+Release:7%{?dist}
License:GPLv2
Group: System Environment/Daemons
Source0:
http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
@@ -367,6 +367,9 @@ exit 0
%config(noreplace) %{_sysconfdir}/httpd/conf.d/dspam-web.conf
%changelog
+* Wed Feb 13 2013 Fedora Release Engineering
- 3.10.2-7
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
+
* Thu Jan 17 2013 Nathanael Noblet - 3.10.2-6
- Attempting to fix purge bug #657357
--
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 Feb 13, 2013 10:58 AM, "Lennart Poettering" wrote: > > On Wed, 13.02.13 02:44, Dan Mashal (dan.mas...@gmail.com) wrote: > > > Please can we test this on rawhide first if anything? I'm pretty sure a lot > > of thing are still ck dependant. We are still trying to catch up to systemd. > > So, in contrast to the esound discussion I do not sense too much > opposition to me just retiring CK. So I'd probably do that in Rawhide > next week or so. CK would hence disappear in F19, but would give > everybody time until the branch or freeze or so to fix their packages... > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel Sorry if I sound ignorant but: No. I meant fedora 20 rawhide. What is the problem with keeping it? Are we just trying to break something different every time we release a new version of Fedora? Regardless, do you know exactly what depends on consolekit and what doesn't? Have you gone through every package? If so, great but my main question is who is it hurting right now? Let's spend some more time to plan doing something like this. Again, just because other distros do it is not a good enough reason. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On Wed, 13.02.13 12:58, Dan Mashal (dan.mas...@gmail.com) wrote: > Sorry if I sound ignorant but: > > No. I meant fedora 20 rawhide. What is the problem with keeping it? There is no Fedora 20 rawhide. I don't want to maintain it, and I want to put the pressure on the few holdouts to finally port things over. > Are we just trying to break something different every time we release a new > version of Fedora? Yes, of course. We are inherently evil people, who just hate other people. We have no interest in making Fedora better, and are exclusively lead by our deepest interest to make everybody's lifes as miserable as we can. > Regardless, do you know exactly what depends on consolekit and what > doesn't? Have you gone through every package? Please go back to mail #1 of this thread, thank you. > If so, great but my main question is who is it hurting right now? Let's > spend some more time to plan doing something like this. Again, just because > other distros do it is not a good enough reason. What do other distros have to do with this? It's *my* intention to get rid of CK, I am upstream of it, and downstream too. I will retire this next week, unless somebody steps up to take it over pretty soon who really thinks his time is better spent on CK rather then just fixing the remaining packages which use it (and as mentioned, exorcising CK from packages is rather simple usually, as in most cases you will just delete code, not add new code). Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
On 02/13/2013 10:03 AM, Jared Smith wrote: > > On Wed, Feb 13, 2013 at 10:26 AM, Jeremy White wrote: >> > I am writing to introduce myself. I have submitted a package review >> > request for the spice-html5 javascript SPICE client here: >> > https://bugzilla.redhat.com/show_bug.cgi?id=910793 > I'm not a sponsor (yet?), but I did an informal review of your package > and put my notes in the bugzilla ticket. Thanks. I notice that emails from the Red Hat bugzilla take nearly a day to reach me. Is that expected? Thanks for catching my mistake; it is all intended to be LGPLv3. I'll post an updated build + spec file to the bug; any other steps I should take? Cheers, Jeremy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
Le mercredi 13 février 2013 à 12:58 -0800, Dan Mashal a écrit : > > On Feb 13, 2013 10:58 AM, "Lennart Poettering" > wrote: > > > > On Wed, 13.02.13 02:44, Dan Mashal (dan.mas...@gmail.com) wrote: > > > > > Please can we test this on rawhide first if anything? I'm pretty > sure a lot > > > of thing are still ck dependant. We are still trying to catch up > to systemd. > > > > So, in contrast to the esound discussion I do not sense too much > > opposition to me just retiring CK. So I'd probably do that in > Rawhide > > next week or so. CK would hence disappear in F19, but would give > > everybody time until the branch or freeze or so to fix their > packages... > > > > Lennart > > > > -- > > Lennart Poettering - Red Hat, Inc. > > -- > > devel mailing list > > devel@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/devel > > Sorry if I sound ignorant but: > > No. I meant fedora 20 rawhide. What is the problem with keeping it? > > Are we just trying to break something different every time we release > a new version of Fedora? > > Regardless, do you know exactly what depends on consolekit and what > doesn't? Have you gone through every package? That's a valid concern. While the list of packages requiring consolekit are quite small ( ie, 3 packages, 1 being a shell script with support to disable ck ), we cannot really check those using the dbus interface in a exhaustive way. 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. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
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? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
On Wed, Feb 13, 2013 at 4:56 PM, Jeremy White wrote: > Thanks. I notice that emails from the Red Hat bugzilla take nearly a > day to reach me. Is that expected? No, not at all. > Thanks for catching my mistake; it is all intended to be LGPLv3. No worries -- that's what package reviews are for :-) > I'll post an updated build + spec file to the bug; > any other steps I should take? No, I think you're on the right track -- as I mentioned before, doing some informal package reviews of other waiting packages will help your potential sponsor understand that you know and understand the packaging guidelines. Other than that, it's wait for a sponsor to jump in. -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning em8300 related stuff
Hi there, I'm orphaning em8300 in Fedora and em8300-kmod in RPMFusion because I no longer own the hardware to use it. Also, it has seen little love from upstream. Feel free to take it. Regards, Felix -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
On Wed, Feb 13, 2013 at 2:56 PM, Jeremy White wrote: > Thanks. I notice that emails from the Red Hat bugzilla take nearly a > day to reach me. Is that expected? Apparently so. :-( The Bugzilla team closed the bug about it as NOTABUG: https://bugzilla.redhat.com/show_bug.cgi?id=910418 -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
- Original Message - > 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? > This is really just the tail end of a migration that has largely already happened. Writing a feature for it now would be a little late, imo. But what I really wanted to say is: thanks for seeing this through to the end, Lennart. Too often we don't complete these transitions, and then the remnants of old, half-broken infrastructure linger forever... In the place of ConsoleKit, /etc/X11/xinitrc-common is such a place - we should remove the mentions of ck-xinit-session from there for F19. Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
On Wed, Feb 13, 2013 at 06:01:34PM -0500, Jared K. Smith wrote: > > Thanks. I notice that emails from the Red Hat bugzilla take nearly a > > day to reach me. Is that expected? > No, not at all. I believe there was a temporary problem in the last few days. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On Wed, 13.02.13 17: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 is an (accepted) feature: https://fedoraproject.org/wiki/Features/ckremoval I am just looking to do the final step, to kill the beast entirely. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
On Wed, Feb 13, 2013 at 09:26:30AM -0600, Jeremy White wrote: > I wrote this code as part of my mid life crisis, and am trying to get it > released in a useful form. That sounds like an excellent mid-life crisis response. Welcome to Fedora! -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- 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 12:34:35AM +0100, Lennart Poettering wrote: > It is an (accepted) feature: > https://fedoraproject.org/wiki/Features/ckremoval Huh. That (Fedora 17 feature) says 100% complete. > I am just looking to do the final step, to kill the beast entirely. So, 110%. :) Mind you, I have no attachment to ConsoleKit. I'd just like to see changes with the potential for end-user impact go through some low-barrier form of change management. I don't know if this reasonably rises to that level or not; my origial question was (and remains) serious, not rhetorical. In reading the F17 feature and the associated discussion page, it looks like the actual final state of that was that the multi-seat portion was implemented but the "ckremoval" portion wasn't completed, and that there was no particular effort around non-Gnome desktops except documentation. So, it's that last bit you're completing now, as I understand it. I notice that there's a lot of documentation at user forums around using ck-launch-session in ~/.xinitrc. We should probably at least release-notes that. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On Wed, 13.02.13 19:13, Matthew Miller (mat...@fedoraproject.org) wrote: > On Thu, Feb 14, 2013 at 12:34:35AM +0100, Lennart Poettering wrote: > > It is an (accepted) feature: > > https://fedoraproject.org/wiki/Features/ckremoval > > Huh. That (Fedora 17 feature) says 100% complete. > > > I am just looking to do the final step, to kill the beast entirely. > > So, 110%. :) > > Mind you, I have no attachment to ConsoleKit. I'd just like to see changes > with the potential for end-user impact go through some low-barrier form of > change management. I don't know if this reasonably rises to that level or > not; my origial question was (and remains) serious, not rhetorical. > > In reading the F17 feature and the associated discussion page, it looks like > the actual final state of that was that the multi-seat portion was > implemented but the "ckremoval" portion wasn't completed, and that there was > no particular effort around non-Gnome desktops except documentation. So, > it's that last bit you're completing now, as I understand it. Well, the goal of the feature was just getting it out of the default install, and that we completed. Now I am building on that and want to remove it entirely. This is then more than one year after we implemented the original feature. I think that should be enough time for the packagers to wake up under their rocks... > I notice that there's a lot of documentation at user forums around using > ck-launch-session in ~/.xinitrc. We should probably at least release-notes > that. Well, sure, if that's what it takes... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On Wed, Feb 13, 2013 at 4:21 AM, Hans de Goede wrote: > Hi, > > > On 02/13/2013 04:26 AM, DJ Delorie wrote: >> >> >>> Hmm, we still have xmms in the repo? >> >> >> /me is very glad we still have xmms in the repo > > > Have you tried using Audacious ? You can set it to > classic mode, at which point it user experience is > identical to xmms. > > With the advantage that it uses a modern toolkit, more > modern plumbing in various places, and it is actively > maintained both in Fedora and upstream. > While audacious can be made to look similar to xmms, it is not xmms, and indeed they are very different from each other. xmms (with ALSA) is the only player that consistently worked for me with no problems for the last 11 years. Moreover it uses the best (in my opinion) GTK version out there. If the esound or pulseaudio plugins are problematic, let us retire them. I don't think xmms will be used by other people than us fanboys, and I feel that we are fine with the ALSA output. Anyhow it looks like spot was kind enough to pick it up, so no worries :) Best, Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
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. In the past, some GNOME apps kept doing that under KDE Plasma sessions as well, until we started installing xsettings-kde by default, which claims XSettings ownership and thus prevents gnome-settings-daemon from running. > If "I don't run gnome" is considered "other serious system issues", I > suppose so. Well, it looks like you aren't running ANY desktop environment, or at least one that doesn't provide an XSettings manager. Unfortunately, gnome-settings-daemon is a real annoyance, you cannot rely on it running when you don't use GNOME, because it's autostarted only in GNOME, but then some stuff ends up starting it for whatever reason. GNOME developers say it should only ever run in GNOME sessions, but somehow it still gets autospawned by some stuff, and only having some other software claim XSettings ownership (as xsettings-kde does in KDE Plasma sessions) will stop it from applying GNOME settings in the middle of your session. > Restarting didn't help, I still had the wrong cursor in emacs and > firefox, but only the emacs and firefox run remotely back to my > display, the local emacs and firefox had the right cursors. I still > can't figure out how to get rid of the wrong cursor without also > getting rid of the right cursors, so I'm currently *not* using Xcursor > because the theme stuff is so confusing. Did the evil gnome-settings-daemon even get autospawned? Try "killall gnome-settings-daemon". Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xmms being retired as of F19
Bruno Wolff III 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. Have you seen DJ Delorie's replies in the other thread? (The first one is dated earlier than your message, so I have to wonder whether you missed it.) (Note that I personally don't care about xmms at all and most definitely do NOT want to maintain it.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora ARM weekly status meeting minutes 2013-02-13
Thanks to those who were able to join us for the weekly status meeting today. For those that were unable, the minutes are posted below: Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-02-13/fedora-meeting-1.2013-02-13-21.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-02-13/fedora-meeting-1.2013-02-13-21.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-02-13/fedora-meeting-1.2013-02-13-21.00.log.html Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
Lennart Poettering wrote: > There is no Fedora 20 rawhide. There will be one in less than 4 weeks. > (and as mentioned, exorcising CK from packages is rather simple usually, > as in most cases you will just delete code, not add new code). I don't think that's true. As far as I know, LightDM relies on ConsoleKit for some essential functionality, and upstream has zero interest in systemd given that they're Ubuntu. So there is one person at Fedora / Red Hat who is trying to port it to systemd all alone, he's not done yet. I don't know what the state of the other affected packages is, but I assume there's also more to do than just disabling ConsoleKit support or it would have been already done (as we did for KDM long ago). For example, if a desktop (or even a display manager, like LightDM) wants to use ConsoleKit for shutdown/restart or, worse (in terms of porting effort), user switching, this all has to be ported to systemd, not just disabled. I agree that ConsoleKit needs to go away, but FIRST all packages using it must be ported away from it, THEN it can be retired. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
Jon Ciesla wrote: > That said, I maintain gnugb, and was able to easily remove the esound > requirement. What sound output options does that leave? I see only arts-devel in the BuildRequires list, and that's actually worse than esound, because it requires running another sound server from KDE 3 era on top of PulseAudio (which gets autospawned, but it unnecessarily eats resources), whereas the ESD protocol is emulated by PulseAudio. I'd suggest dropping arts support (to squelch dependency bloat) and reenabling esound now that it got picked up (unless there's ALSA support which works with the PulseAudio ALSA plugin, then you can drop both arts and esound). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
Matthew Miller wrote: > In reading the F17 feature and the associated discussion page, it looks > like the actual final state of that was that the multi-seat portion was > implemented but the "ckremoval" portion wasn't completed, and that there > was no particular effort around non-Gnome desktops except documentation. There was work done by KDE SIG too. No KDE stuff depends on ConsoleKit anymore (I wrote the patch to port kde-workspace's support for shutdown, restart and user switching without KDM from ConsoleKit to systemd), and ConsoleKit is not on the KDE spin. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
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. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On Wed, Feb 13, 2013 at 21:21:41 -0500, Orcan Ogetbil wrote: If the esound or pulseaudio plugins are problematic, let us retire them. I don't think xmms will be used by other people than us fanboys, and I feel that we are fine with the ALSA output. Anyhow it looks like spot was kind enough to pick it up, so no worries :) 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo Meeting (2013-02-13)
Marcela Mašláňová wrote: > * #1085 2013-02-13 meeting feature voting (mmaslano, 19:37:56) > * AGREED: all features from new business are accepted "en bloc" > (+5,-0,0) (mmaslano, 19:45:10) So that UsermodeMigration nonsense was approved without even any discussion at all? :-( Kevin Kofler -- 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
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??? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
I wrote: > DJ Delorie wrote: >> Restarting didn't help, I still had the wrong cursor in emacs and >> firefox, but only the emacs and firefox run remotely back to my >> display, the local emacs and firefox had the right cursors. I still >> can't figure out how to get rid of the wrong cursor without also >> getting rid of the right cursors, so I'm currently *not* using Xcursor >> because the theme stuff is so confusing. > > Did the evil gnome-settings-daemon even get autospawned? Try "killall > gnome-settings-daemon". Oops, I mean, did it even get saved in the session and auto-REspawned? (That used not to be the case.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
> Well, it looks like you aren't running ANY desktop environment, fvwm2, emacs, firefox, xterm. Plus a few other things as needed. This is for two computers running four monitors (one computer is the local one with the monitors, the other is strictly ssh and remote X, each computer has its own desktop I switch between). It's a horror show each time I upgrade, usually takes a few days to get everything "settled" again. > or at least one that doesn't provide an XSettings manager. This is the first time I've *heard* of an "XSettings manager". > Did the evil gnome-settings-daemon even get autospawned? Try "killall > gnome-settings-daemon". I did kill it. It was running again anyway. I killed it again and replaced it with a script that just calls /bin/true :-) Some of the appearance changed back when I killed the daemon, but I'll have to reinstall the theme to see if the cursor is fixed. I have a hard time keeping programs from running xrdb too, I usually end up renaming that too. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On Thu, 14.02.13 04:02, Kevin Kofler (kevin.kof...@chello.at) wrote: > > (and as mentioned, exorcising CK from packages is rather simple usually, > > as in most cases you will just delete code, not add new code). > > I don't think that's true. As far as I know, LightDM relies on ConsoleKit > for some essential functionality, and upstream has zero interest in systemd > given that they're Ubuntu. Well, subscribing to systemd-devel for a while and asking a number of questions (which the lightdm upstream did) is hardly "zero interest". > So there is one person at Fedora / Red Hat who is trying to port it > to systemd all alone, he's not done yet. I don't know what the state > of the other affected packages is, but I assume there's also more to > do than just disabling ConsoleKit support or it would have been > already done (as we did for KDM long ago). For example, if a desktop > (or even a display manager, like LightDM) wants to use ConsoleKit for > shutdown/restart or, worse (in terms of porting effort), user > switching, this all has to be ported to systemd, not just disabled. > > I agree that ConsoleKit needs to go away, but FIRST all packages using it > must be ported away from it, THEN it can be retired. Well, that's a pity, but I guess the burden for this really should be carried by the lightdm folks then. So, lightdm folks, if you want to keep CK around, then you need to step up, and take it over. If I hear nothing but "oh, oh, i think, oh, i think", then I will retire it next week. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On Wed, Feb 13, 2013 at 7:02 PM, Kevin Kofler wrote: > Lennart Poettering wrote: >> There is no Fedora 20 rawhide. > > There will be one in less than 4 weeks. > >> (and as mentioned, exorcising CK from packages is rather simple usually, >> as in most cases you will just delete code, not add new code). > > I don't think that's true. As far as I know, LightDM relies on ConsoleKit > for some essential functionality, and upstream has zero interest in systemd > given that they're Ubuntu. So there is one person at Fedora / Red Hat who is > trying to port it to systemd all alone, he's not done yet. I don't know what > the state of the other affected packages is, but I assume there's also more > to do than just disabling ConsoleKit support or it would have been already > done (as we did for KDM long ago). For example, if a desktop (or even a > display manager, like LightDM) wants to use ConsoleKit for shutdown/restart > or, worse (in terms of porting effort), user switching, this all has to be > ported to systemd, not just disabled. > > I agree that ConsoleKit needs to go away, but FIRST all packages using it > must be ported away from it, THEN it can be retired. > > Kevin Kofler > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel This was exactly my point. MATE Desktop being dependent on LightDM in Fedora (that can possibly be changed). However if LightDM had full systemd/logind support then I'm all for it. Correct me if I'm wrong, but I believe XFCE, LXDE and MATE all use LightDM and I think there were plans to get rid of KDM on KDE in favor of LightDM as well. Thanks, Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ConsoleKit and esound retirement
On Wed, Feb 13, 2013 at 7:26 PM, Bruno Wolff III wrote: > On Wed, Feb 13, 2013 at 21:21:41 -0500, > Orcan Ogetbil wrote: >> >> >> If the esound or pulseaudio plugins are problematic, let us retire >> them. I don't think xmms will be used by other people than us fanboys, >> and I feel that we are fine with the ALSA output. >> >> Anyhow it looks like spot was kind enough to pick it up, so no worries :) > > > 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. > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel I found pavucontrol very useful to deal with the volume control issue. Thanks to rdieter for the help on that. Thanks, Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
