Re: Question regarding dist-git aesthetics with branches
Using names like f13, el5, and so forth would also keep dist-git
consistent with git branch naming conventions. If we were to do
something like that we might as well just use the value of %{dist}.
But that's just too obviously right for us to be allowed to do it!
That was going to be my next question, although that would bring back
the c in fc13 and fc14 since that's what the dist value is. We could
bite the bullet and change the dist value to remove the c, and just
manually keep track of making sure that builds on older releases won't
be newer than builds on the newer branches. not sure if we want to go
through that pain at this point.
I'd say bite the bullet. Die, little c, die! It just looks silly there
nowadays, since the C-word has not been in our vocabulary for so long now.
What does manually mean, anyway? A database query and a short script?
Roll it into existing nag mail or update sanity-checking stuff? This seems
like a simple enough matter among all the things we're nowadays trying to
have some coherent checking for.
Yes. Branches of rawhide would be of the form origin/branch so if we
don't find one of our expected f(c)??,el?,olpc? we default to building
for rawhide.
Where is the mapping of branch name patterns to koji build targets going to
live? Is it just in fedpkg locally and you'll change the norm only by
pushing a fedora-packager update in each release? (That doesn't sound very
likely. People use older Fedoras with older fedora-packager installed to
commit and trigger newer dist builds.) Or is it partly local and partly
gotten from the (koji?) server, or what? (In the CVS system this is the
common/branches file, which is both locally available in that it's a local
file in your common/ checkout, and centrally maintained in CVS.)
Thanks,
Roland
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git wordsmithing wanted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/20/2010 10:48 PM, Pierre-Yves wrote: On Tue, 2010-07-20 at 22:38 -0700, Jesse Keating wrote: $ make tag Make system retired, please use fedpkg. See fedpkg --help Suggestions on what to put in here? Might be nice to already print the equivalent command: $ make tag Make system retired, please use fedpkg. The equivalent function is: For more information see fedpkg --help But that might be a bit long though. Pierre That'd make for an overly complicated Make file too. Right now what I have is along the lines of: $ cat Makefile # Makefile for source rpm: pungi # $Id$ .PHONY :: $(ARCHES) sources uploadsource upload export check build-check build cvsurl chain-build test-srpm srpm tag verrel new clean patch prep compile install install-short compile-short FORCE local scratch-build scratch-build-% srpm-scratch-build srpm-scratch-build-% clog all: @echo Make system retired, please use fedpkg. See fedpkg --help i386 i686 x86_64 ppc ppc64 noarch sources uploadsource upload export check build-check build cvsurl chain-build test-srpm srpm tag verrel new clean patch prep compile install install-short compile-short FORCE local scratch-build srpm-scratch-build clog: all scratch-build-%: all srpm-scratch-build-%: all - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxGkrcACgkQ4v2HLvE71NXvKQCgoa9C8dAeTuZ4bLgvrTsUcdUV 7WwAoLw67V1Xltg/3OJ3VSy0PkyJ51ro =PdzK -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git wordsmithing wanted
It was suggested to keep the Makefile that exists in every package module/branch in CVS right now, but set it up so that any Make command issued would print a reminder to the user that the Make system has been retired and to use fedpkg. So the expectation would be people leave this boilerplate around forever (as the wordsmithing drifts)? Or do you expect every maintainer who knows about fedpkg will just remove Makefile from their git trees first thing after the conversion? Frankly, I don't see the point. So you're a Fedora maintainer and you managed to get a git checkout after the conversion, but you can't read a wiki page that tells you how to use fedpkg instead of make. (Presumably the wiki page has a nice table of make commands and corresponding fedpkg commands.) Where did you read how to do the git checkout if it wasn't the same wiki page that tells you all about fedpkg? What will you do in your confusion, and will it not include email to this list or asking on IRC so that you get answers to I knew how to do 'make foo' but what now? in about three minutes? But, some of my Makefiles have nonstandard cruft in them I need to keep around until I replace it with something. So don't delete *my* makefiles. Just delete *their* makefiles. Oh, also, I don't care at all. So, just do, you know, whatever. Rock on. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git wordsmithing wanted
$ cat Makefile # Makefile for source rpm: pungi # $Id$ .PHONY :: $(ARCHES) sources uploadsource upload export check build-check [...] Just use a single .DEFAULT: or %: rule, you don't need to list anything. (And :: is almost never what you meant.) Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reminder: Fedora 14 Feature Freeze is Next Week (2010-07-27)
Hello, 2010-07-21 06:18 keltezéssel, John Poelstra írta: Feature Freeze means that all accepted feature for the release are *significantly* feature complete, ready for testing, and have a current status. What does it from the software version point of view? I'm asking because of the pending syslog-ng update, which I coordinate for all major Linux distributions where only Fedora did not make the switch from syslog-ng 2.X to 3.X. I started the process well before the feature freeze, in April, by contacting the maintainer and also this mailing list. I also filed a bugzilla request beginning June ( https://bugzilla.redhat.com/show_bug.cgi?id=598961 ). It has spec and config diffs and also a source rpm attached, which I tested on Fedora 12, 13 and rawhide. I had no response to personal e-mails, mailing list or to the bugzilla entry, so I started the non-responsive maintainer process, which had a response within a few hours ( https://bugzilla.redhat.com/show_bug.cgi?id=603012 ). Nothing seems to have happened ever since. What can I do in this situation? Bye, CzP -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
Dne 21.7.2010 08:22, Roland McGrath napsal(a): What does manually mean, anyway? A database query and a short script? Isn't this something which automatic QA process could do very easily? Matěj -- He uses statistics as a drunken man uses lamp-posts... for support, rather than illumination. -- Andrew Lang -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Partial mass rebuild for Python 2.7 coming soon (I hope)
2010/7/21 David Malcolm dmalc...@redhat.com: Some notes can be seen at: https://fedoraproject.org/wiki/Features/Python_2.7/MassRebuild TODO: do we need a compat-python-2.6 temporarily to resolve loops in the dep graph? Wouldn't such a compat package also make yum upgrades from f13-f14 or rawhide-with-py2.6-rawhide-with-py2.7 easier, and thus should not only provided temporarily, but for a longer time? - Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Packages in EL-6 beta 2 and EPEL-6
perl-Email-Date-Format, cairomm and wordnet appear to be in all arches for beta 2 and should probably be removed from EPEL-6 perl-HTML-Format, perl-Class-Data-Inheritable, perl-Class-Trigger, perl-Font-AFM, perl-PadWalker, perl-File-Copy-Recursive and libart_lgpl appear to be newer versions in EPEL than in RHEL-6 beta 2, please could you rebuild using the SRPMs available from the RedHat repositories available at ftp.redhat.com/pub/redhat/rhel/beta/5.90Server Mark -- 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: [HEADS-UP] systemd for F14 - the next steps
TK == Toshio Kuratomi a.bad...@gmail.com writes: TK * What replaces chkconfig TK * What replaces /etc/init.d/SERVICENAME start | stop ? If the answers aren't chkconfig and service foo start then I fear significant backlash from poor people who actually have to run F-14 systems. We pretty much have to keep them working, even if they have to be packaged separately from systemd. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Tue, 2010-07-20 at 22:15 -0700, Jesse Keating wrote:
On 07/20/2010 08:55 PM, Garrett Holmstrom wrote:
On 7/20/2010 19:13, Hans Ulrich Niedermann wrote:
BTW, while typing the above, I have noted that master or devel or
f13 are quite easy to type, while F-13 with capital letter and
hyphen is relatively complicated. Perhaps that could be an argument when
choosing branch names.
Using names like f13, el5, and so forth would also keep dist-git
consistent with git branch naming conventions. If we were to do
something like that we might as well just use the value of %{dist}.
That was going to be my next question, although that would bring back
the c in fc13 and fc14 since that's what the dist value is. We could
bite the bullet and change the dist value to remove the c, and just
manually keep track of making sure that builds on older releases won't
be newer than builds on the newer branches. not sure if we want to go
through that pain at this point.
Don't we have a (few) mass rebuilds in front of us before F-14 anyway?
gold and similar stuff? That would increase the R of N-V-R anyway, so we
could switch %{dist} from fc14 to f14 at the same time for probably the
majority of packages.
Oh. Darn. We still need to make sure that *.fc12 and *.fc13 packages do
not have the same N-V-R modulo %{dist} as F14 has, until F13 is EOLed,
i.e. until F15 comes out. That still sounds ugly. Well, all of that is
ugly regarding the c, whatever we do or do not do.
If rawhide development is supposed to happen on origin/master, then how
do branches for rawhide work? Does fedpkg just default to building for
rawhide when a branch doesn't appear in a release's branch namespace?
Yes. Branches of rawhide would be of the form origin/branch so if we
don't find one of our expected f(c)??,el?,olpc? we default to building
for rawhide.
I was not aware that rawhide would be basically origin/master. In that
case, it would be really obviously nice to be able to have branches
master, f13 and f12 (without any slashes) in the local repo and
have things just work for that case.
Perhaps fedpkg could support both simple clones where the developer's
local repo has just three branches tracking upstream
master - origin/master
f13- origin/f13/master
f12- origin/f12/master
or for people with more complex needs
master - origin/master
f13/master - origin/f13/master
f12/master - origin/f12/master
Which gives me an idea. What if we had
master - origin/master
f13- origin/f13
f12- origin/f12
F13/foo
F12/bar
and in addition to that, any local branch named like F13/* would be
built for f13? That would give direct 1:1 git repo cloning, with still
making it possible to deduce the target from branch names if so desired
by the packager.
We could even use fc13 and f13/foo to make the confusion complete
and nail down the c requirement for the next 20 years... :-)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git wordsmithing wanted
On Tue, 2010-07-20 at 23:31 -0700, Roland McGrath wrote: It was suggested to keep the Makefile that exists in every package module/branch in CVS right now, but set it up so that any Make command issued would print a reminder to the user that the Make system has been retired and to use fedpkg. So the expectation would be people leave this boilerplate around forever (as the wordsmithing drifts)? Or do you expect every maintainer who knows about fedpkg will just remove Makefile from their git trees first thing after the conversion? Frankly, I don't see the point. So you're a Fedora maintainer and you managed to get a git checkout after the conversion, but you can't read a wiki page that tells you how to use fedpkg instead of make. (Presumably I agree. Either we keep around a Makefile in every package which translates all the old make calls to fedpkg calls (which I cannot remember being a serious proposal), or we cut the compatibility. Count me in on this reminder: make: *** No targets specified and no makefile found. Stop. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Wed, 2010-07-21 at 10:55 +0200, Hans Ulrich Niedermann wrote:
On Tue, 2010-07-20 at 22:15 -0700, Jesse Keating wrote:
On 07/20/2010 08:55 PM, Garrett Holmstrom wrote:
Using names like f13, el5, and so forth would also keep dist-git
consistent with git branch naming conventions. If we were to do
something like that we might as well just use the value of %{dist}.
That was going to be my next question, although that would bring back
the c in fc13 and fc14 since that's what the dist value is. We could
bite the bullet and change the dist value to remove the c, and just
manually keep track of making sure that builds on older releases won't
be newer than builds on the newer branches. not sure if we want to go
through that pain at this point.
Don't we have a (few) mass rebuilds in front of us before F-14 anyway?
gold and similar stuff? That would increase the R of N-V-R anyway, so we
could switch %{dist} from fc14 to f14 at the same time for probably the
majority of packages.
Oh. Darn. We still need to make sure that *.fc12 and *.fc13 packages do
not have the same N-V-R modulo %{dist} as F14 has, until F13 is EOLed,
i.e. until F15 comes out. That still sounds ugly. Well, all of that is
ugly regarding the c, whatever we do or do not do.
Ugly potential fix for this ugly issue: Patch rpm and yum to compare
N-V-R.fc13 exactly like N-V-R.f13, and carry that patch until F-15.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git wordsmithing wanted
On Tue, Jul 20, 2010 at 10:38:12PM -0700, Jesse Keating wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It was suggested to keep the Makefile that exists in every package module/branch in CVS right now, but set it up so that any Make command issued would print a reminder to the user that the Make system has been retired and to use fedpkg. I could use some word smithing on this message. What I have right now is this: $ make tag Make system retired, please use fedpkg. See fedpkg --help Suggestions on what to put in here? I agree with roland and hans about the necessity of this but if you do go ahead. Probably want to say: make is no longer used to build packages. Use fedpkg instead. yum install fedora-packager fedpkg --help Or: make is no longer used to build packages. See: http://fedoraproject.org/wiki/Using_Fedpkg -Toshio pgplcs1geqvJo.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100721 changes
Compose started at Wed Jul 21 08:15:12 UTC 2010 Broken deps for x86_64 -- BackupPC-3.1.0-14.1.fc14.noarch requires perl-suidperl PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit) PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(64bit) almanah-0.7.3-2.fc14.x86_64 requires libecal-1.2.so.7()(64bit) almanah-0.7.3-2.fc14.x86_64 requires libebook-1.2.so.9()(64bit) 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 1:anjuta-2.30.0.0-2.fc14.i686 requires libdevhelp-1.so.1 1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libdevhelp-1.so.1()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit) cairo-java-1.0.5-12.fc12.i686 requires libgcj.so.10 cairo-java-1.0.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) claws-mail-plugins-geolocation-3.7.6-3.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) claws-mail-plugins-geolocation-3.7.6-3.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) dates-0.4.11-3.fc14.x86_64 requires libecal-1.2.so.7()(64bit) dates-0.4.11-3.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit) deskbar-applet-2.30.0-1.1.fc14.x86_64 requires libedataserver-1.2.so.12()(64bit) deskbar-applet-2.30.0-1.1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) ekiga-3.2.7-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) emerillon-0.1.1-2.fc13.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) emerillon-0.1.1-2.fc13.x86_64 requires libchamplain-0.4.so.0()(64bit) emerillon-devel-0.1.1-2.fc13.i686 requires pkgconfig(champlain-0.4) emerillon-devel-0.1.1-2.fc13.x86_64 requires pkgconfig(champlain-0.4) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libedata-book-1.2.so.2()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-1.2.so.17()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-provider-1.2.so.17()(64bit) evolution-rss-0.1.9-7.20100525git.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit) evolution-rss-0.1.9-7.20100525git.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libecal-1.2.so.7()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libebook-1.2.so.9()(64bit) fmt-ptrn-java-1.3.20-5.fc13.i686 requires libgcj.so.10 fmt-ptrn-java-1.3.20-5.fc13.x86_64 requires libgcj.so.10()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) giggle-0.5-2.fc14.i686 requires libebook-1.2.so.9 giggle-0.5-2.fc14.x86_64 requires libebook-1.2.so.9()(64bit) glabels-2.2.8-2.fc14.x86_64 requires libebook-1.2.so.9()(64bit) glib-java-0.2.6-16.fc12.i686 requires libgcj.so.10 glib-java-0.2.6-16.fc12.x86_64 requires libgcj.so.10()(64bit) gnome-python2-brasero-2.31.1-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.31.1-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-evolution-2.31.1-1.fc14.x86_64 requires libecal-1.2.so.7()(64bit) gnome-python2-evolution-2.31.1-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) gnome-python2-totem-2.31.1-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gnomeradio-1.8-6.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) grads-2.0.a7.1-0.3.fc13.x86_64 requires libdap.so.10()(64bit) lekhonee-gnome-0.11-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit) libgconf-java-2.12.4-14.fc12.i686 requires libgcj.so.10 libgconf-java-2.12.4-14.fc12.x86_64 requires libgcj.so.10()(64bit) libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10 libglade-java-2.12.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10 libgnome-java-2.12.4-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgtk-java-2.8.7-13.fc13.i686 requires libgcj.so.10 libgtk-java-2.8.7-13.fc13.x86_64 requires libgcj.so.10()(64bit)
Re: dist-git wordsmithing wanted
On Wed, Jul 21, 2010 at 11:01, Hans Ulrich Niedermann h...@n-dimensional.de wrote: Count me in on this reminder: make: *** No targets specified and no makefile found. Stop. I like that one. There is nothing worse that keeping code that doesn't do anything. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Lost all empathy accounts after update this morning (F13)
hi, I've just run into it too. Updated my system . Here's the yum history list of the latest update: Loaded plugins: auto-update-debuginfo, fastestmirror, presto, protectbase, : refresh-packagekit Transaction ID : 174 Begin time : Wed Jul 21 10:16:59 2010 Begin rpmdb: 2346:9697ed1ec924300dd53fb58636e33843b835181d End time :10:22:09 2010 (310 seconds) End rpmdb : 2347:b1db59e589e6f75a27380eda9fd1036cbb26a084 User : Ankur Sinha Ankur Return-Code: Success Transaction performed with: Installedrpm-4.8.1-2.fc13.x86_64 Installedyum-3.2.27-4.fc13.noarch Installedyum-metadata-parser-1.1.4-1.fc13.x86_64 Installedyum-plugin-auto-update-debug-info-1.1.27-2.fc13.noarch Installedyum-plugin-fastestmirror-1.1.27-2.fc13.noarch Installedyum-presto-0.6.2-1.fc13.noarch Packages Altered: Updated abrt-1.1.1-1.fc13.x86_64 Update1.1.1-2.fc13.x86_64 Updated abrt-addon-ccpp-1.1.1-1.fc13.x86_64 Update 1.1.1-2.fc13.x86_64 Updated abrt-addon-kerneloops-1.1.1-1.fc13.x86_64 Update 1.1.1-2.fc13.x86_64 Updated abrt-addon-python-1.1.1-1.fc13.x86_64 Update 1.1.1-2.fc13.x86_64 Updated abrt-desktop-1.1.1-1.fc13.x86_64 Update1.1.1-2.fc13.x86_64 Updated abrt-gui-1.1.1-1.fc13.x86_64 Update1.1.1-2.fc13.x86_64 Updated abrt-libs-1.1.1-1.fc13.x86_64 Update 1.1.1-2.fc13.x86_64 Updated abrt-plugin-bugzilla-1.1.1-1.fc13.x86_64 Update1.1.1-2.fc13.x86_64 Updated abrt-plugin-logger-1.1.1-1.fc13.x86_64 Update 1.1.1-2.fc13.x86_64 Updated abrt-plugin-runapp-1.1.1-1.fc13.x86_64 Update 1.1.1-2.fc13.x86_64 Dep-Install compat-db-headers-4.7.25-15.fc13.noarch Updated compat-db47-4.7.25-3.fc13.x86_64 Update 4.7.25-15.fc13.x86_64 Updated farsight2-0.0.20-1.fc13.x86_64 Update 0.0.20-2.fc13.x86_64 Updated fedora-packager-0.4.2.1-1.fc13.noarch Update 0.4.2.3-1.fc13.noarch Updated finger-0.17-39.fc12.x86_64 Update 0.17-41.fc13.x86_64 Updated gdb-7.1-28.fc13.x86_64 Update 7.1-29.fc13.x86_64 Updated ibus-pinyin-1.3.8-1.fc13.x86_64 Update 1.3.9-1.fc13.x86_64 Updated ibus-pinyin-db-open-phrase-1.3.8-1.fc13.noarch Update 1.3.9-1.fc13.noarch Updated m17n-contrib-1.1.10-4.fc13.noarch Update1.1.10-5.fc13.noarch Updated m17n-contrib-assamese-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-bengali-1.1.10-4.fc13.noarch Update1.1.10-5.fc13.noarch Updated m17n-contrib-gujarati-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-hindi-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-kannada-1.1.10-4.fc13.noarch Update1.1.10-5.fc13.noarch Updated m17n-contrib-maithili-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-malayalam-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-marathi-1.1.10-4.fc13.noarch Update1.1.10-5.fc13.noarch Updated m17n-contrib-oriya-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-punjabi-1.1.10-4.fc13.noarch Update1.1.10-5.fc13.noarch Updated m17n-contrib-sinhala-1.1.10-4.fc13.noarch Update1.1.10-5.fc13.noarch Updated m17n-contrib-tamil-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-telugu-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-urdu-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated papyon-0.4.8-1.fc13.noarch Update 0.4.9-1.fc13.noarch Updated ql23xx-firmware-3.03.27-3.fc12.noarch Update 3.03.28-1.fc13.noarch Updated ql2400-firmware-5.03.02-1.fc13.noarch Update 5.03.07-1.fc13.noarch Updated ql2500-firmware-5.03.02-1.fc13.noarch Update 5.03.07-1.fc13.noarch Updated redhat-lsb-4.0-2.fc13.x86_64
Broken rhythmbox in rawhide
Just to let you know that despite being installable, those 2 packages will need some work before they are usable. Rhythmbox needs porting to gtk3, so as not to have clashing GTK2 and GTK3 usage. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On 07/21/2010 03:24 AM, Toshio Kuratomi wrote: I have a few requests for things to add to that page :-) * What replaces chkconfig systemd-install Now first the gotcha then I'll provide chkconfig replacement example. Admins will need to know that they have to use chkconfig for services that do not have a native systemd $service file. ( legacy for services ) And as the general rule goes native configuration breaks legacy configuration so if a native systemd $service file does exist than changing service via chkconfig no longer will work. Now the systemd developers could add a little pony to speed up adoption and prevent potential chkconfig Admin/User fiasco by simply letting systemd-install fallback to chkconfig if it finds no native service file in /lib/systemd/system/ with msg to stdout asking Admins to file a bug against a given missing service. Admins/Users could then stop using chkconfig and use systemd-install only instead which would speed up adobtion Systemd-install examples ( see man page for detail list of options ) To see running targets on your system. systemctl list-units --type=target To see all available running targets on your system. systemctl list-units --type=target --all To see which native systemd system files exist on your installed system ls /lib/systemd/system/ To enable service ( chkconfig $service on ) systemd-install enable $service.service To disable service ( chkconfig $service off ) systemd-install disable $service.service To enable service and start it ( chkconfig $service on service $service start ) systemd-install --realize=yes enable $service.service To always start service on boot instead of when a connection comes in or some hardware is plugged in. ln -sf /lib/systemd/system/foobar.service /etc/systemd/system/multi-user.target.wants/foobar.service Remember to reload the systemd manager systemctl daemon-reload So to enable avahi-daemon systemd-install enable avahi-daemon.service To disable avahi-daemon systemd-install disable avahi-daemon.service To enable avahi-daemon and start it systemd-install --realize=yes enable avahi-daemon.service To always start avahi-daemon on boot ln -sf /lib/systemd/system/avahi-daemon.service /etc/systemd/system/multi-user.target.wants/avahi-daemon.service Reload the systemd manager systemctl daemon-reload * What replaces /etc/init.d/SERVICENAME start | stop ? systemctl. systemctl examples ( sem man pages for detail list of options ) Replacing traditional /sbin/service with systemctl To list running services systemctl list-units --type=service To list all available services systemctl list-units --type=service --all To start a service systemctl start $foo.service To stop a service systemctl stop $foo.service To reload a service .conf file. systemctl reload $foo.service To restart a service systemctl restart $foo.service To show service status ( Admins should love the output from this ) systemctl status $foo.service Using Apache as an example Starting Apache systemctl start httpd.service Stopping Apache systemctl stop httpd.service Reloading httpd.conf systemctl reload httpd.service Restarting Apache systemctl restart httpd.service To check if Apache is running systemct status httpd.service I will add this ( and more ) to the page soon as can. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Can anyone contact Balint Christian (rezso)?
Hi all, Following the process https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers Is someone able to get in touch with Christian Balint (rezso)? His last koji activity was on the 18th of March 2010. I sent a personal email on the 9th of June to which I got no reply. I've opened https://bugzilla.redhat.com/show_bug.cgi?id=611487 to track the AWOL procedure. -- sven === jabber/xmpp: s...@lankes.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Lost all empathy accounts after update this morning (F13)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/21/2010 07:12 AM, Ankur Sinha wrote: hi, I've just run into it too. Updated my system . Here's the yum history list of the latest update: Loaded plugins: auto-update-debuginfo, fastestmirror, presto, protectbase, : refresh-packagekit Transaction ID : 174 Begin time : Wed Jul 21 10:16:59 2010 Begin rpmdb: 2346:9697ed1ec924300dd53fb58636e33843b835181d End time :10:22:09 2010 (310 seconds) End rpmdb : 2347:b1db59e589e6f75a27380eda9fd1036cbb26a084 User : Ankur Sinha Ankur Return-Code: Success Transaction performed with: Installedrpm-4.8.1-2.fc13.x86_64 Installedyum-3.2.27-4.fc13.noarch Installedyum-metadata-parser-1.1.4-1.fc13.x86_64 Installedyum-plugin-auto-update-debug-info-1.1.27-2.fc13.noarch Installedyum-plugin-fastestmirror-1.1.27-2.fc13.noarch Installedyum-presto-0.6.2-1.fc13.noarch Packages Altered: Updated abrt-1.1.1-1.fc13.x86_64 Update1.1.1-2.fc13.x86_64 Updated abrt-addon-ccpp-1.1.1-1.fc13.x86_64 Update 1.1.1-2.fc13.x86_64 Updated abrt-addon-kerneloops-1.1.1-1.fc13.x86_64 Update 1.1.1-2.fc13.x86_64 Updated abrt-addon-python-1.1.1-1.fc13.x86_64 Update 1.1.1-2.fc13.x86_64 Updated abrt-desktop-1.1.1-1.fc13.x86_64 Update1.1.1-2.fc13.x86_64 Updated abrt-gui-1.1.1-1.fc13.x86_64 Update1.1.1-2.fc13.x86_64 Updated abrt-libs-1.1.1-1.fc13.x86_64 Update 1.1.1-2.fc13.x86_64 Updated abrt-plugin-bugzilla-1.1.1-1.fc13.x86_64 Update1.1.1-2.fc13.x86_64 Updated abrt-plugin-logger-1.1.1-1.fc13.x86_64 Update 1.1.1-2.fc13.x86_64 Updated abrt-plugin-runapp-1.1.1-1.fc13.x86_64 Update 1.1.1-2.fc13.x86_64 Dep-Install compat-db-headers-4.7.25-15.fc13.noarch Updated compat-db47-4.7.25-3.fc13.x86_64 Update 4.7.25-15.fc13.x86_64 Updated farsight2-0.0.20-1.fc13.x86_64 Update 0.0.20-2.fc13.x86_64 Updated fedora-packager-0.4.2.1-1.fc13.noarch Update 0.4.2.3-1.fc13.noarch Updated finger-0.17-39.fc12.x86_64 Update 0.17-41.fc13.x86_64 Updated gdb-7.1-28.fc13.x86_64 Update 7.1-29.fc13.x86_64 Updated ibus-pinyin-1.3.8-1.fc13.x86_64 Update 1.3.9-1.fc13.x86_64 Updated ibus-pinyin-db-open-phrase-1.3.8-1.fc13.noarch Update 1.3.9-1.fc13.noarch Updated m17n-contrib-1.1.10-4.fc13.noarch Update1.1.10-5.fc13.noarch Updated m17n-contrib-assamese-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-bengali-1.1.10-4.fc13.noarch Update1.1.10-5.fc13.noarch Updated m17n-contrib-gujarati-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-hindi-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-kannada-1.1.10-4.fc13.noarch Update1.1.10-5.fc13.noarch Updated m17n-contrib-maithili-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-malayalam-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-marathi-1.1.10-4.fc13.noarch Update1.1.10-5.fc13.noarch Updated m17n-contrib-oriya-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-punjabi-1.1.10-4.fc13.noarch Update1.1.10-5.fc13.noarch Updated m17n-contrib-sinhala-1.1.10-4.fc13.noarch Update1.1.10-5.fc13.noarch Updated m17n-contrib-tamil-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-telugu-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-urdu-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated papyon-0.4.8-1.fc13.noarch Update 0.4.9-1.fc13.noarch Updated ql23xx-firmware-3.03.27-3.fc12.noarch Update 3.03.28-1.fc13.noarch Updated ql2400-firmware-5.03.02-1.fc13.noarch Update 5.03.07-1.fc13.noarch Updated ql2500-firmware-5.03.02-1.fc13.noarch Update
Re: Lost all empathy accounts after update this morning (F13)
On Wed, 2010-07-21 at 08:36 -0400, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/21/2010 07:12 AM, Ankur Sinha wrote: hi, I've just run into it too. Updated my system . Here's the yum history list of the latest update: Loaded plugins: auto-update-debuginfo, fastestmirror, presto, protectbase, : refresh-packagekit Transaction ID : 174 Begin time : Wed Jul 21 10:16:59 2010 Begin rpmdb: 2346:9697ed1ec924300dd53fb58636e33843b835181d End time :10:22:09 2010 (310 seconds) End rpmdb : 2347:b1db59e589e6f75a27380eda9fd1036cbb26a084 User : Ankur Sinha Ankur Return-Code: Success Transaction performed with: Installedrpm-4.8.1-2.fc13.x86_64 Installedyum-3.2.27-4.fc13.noarch Installedyum-metadata-parser-1.1.4-1.fc13.x86_64 Installedyum-plugin-auto-update-debug-info-1.1.27-2.fc13.noarch Installedyum-plugin-fastestmirror-1.1.27-2.fc13.noarch Installedyum-presto-0.6.2-1.fc13.noarch Packages Altered: Updated abrt-1.1.1-1.fc13.x86_64 Update1.1.1-2.fc13.x86_64 Updated abrt-addon-ccpp-1.1.1-1.fc13.x86_64 Update 1.1.1-2.fc13.x86_64 Updated abrt-addon-kerneloops-1.1.1-1.fc13.x86_64 Update 1.1.1-2.fc13.x86_64 Updated abrt-addon-python-1.1.1-1.fc13.x86_64 Update 1.1.1-2.fc13.x86_64 Updated abrt-desktop-1.1.1-1.fc13.x86_64 Update1.1.1-2.fc13.x86_64 Updated abrt-gui-1.1.1-1.fc13.x86_64 Update1.1.1-2.fc13.x86_64 Updated abrt-libs-1.1.1-1.fc13.x86_64 Update 1.1.1-2.fc13.x86_64 Updated abrt-plugin-bugzilla-1.1.1-1.fc13.x86_64 Update1.1.1-2.fc13.x86_64 Updated abrt-plugin-logger-1.1.1-1.fc13.x86_64 Update 1.1.1-2.fc13.x86_64 Updated abrt-plugin-runapp-1.1.1-1.fc13.x86_64 Update 1.1.1-2.fc13.x86_64 Dep-Install compat-db-headers-4.7.25-15.fc13.noarch Updated compat-db47-4.7.25-3.fc13.x86_64 Update 4.7.25-15.fc13.x86_64 Updated farsight2-0.0.20-1.fc13.x86_64 Update 0.0.20-2.fc13.x86_64 Updated fedora-packager-0.4.2.1-1.fc13.noarch Update 0.4.2.3-1.fc13.noarch Updated finger-0.17-39.fc12.x86_64 Update 0.17-41.fc13.x86_64 Updated gdb-7.1-28.fc13.x86_64 Update 7.1-29.fc13.x86_64 Updated ibus-pinyin-1.3.8-1.fc13.x86_64 Update 1.3.9-1.fc13.x86_64 Updated ibus-pinyin-db-open-phrase-1.3.8-1.fc13.noarch Update 1.3.9-1.fc13.noarch Updated m17n-contrib-1.1.10-4.fc13.noarch Update1.1.10-5.fc13.noarch Updated m17n-contrib-assamese-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-bengali-1.1.10-4.fc13.noarch Update1.1.10-5.fc13.noarch Updated m17n-contrib-gujarati-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-hindi-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-kannada-1.1.10-4.fc13.noarch Update1.1.10-5.fc13.noarch Updated m17n-contrib-maithili-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-malayalam-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-marathi-1.1.10-4.fc13.noarch Update1.1.10-5.fc13.noarch Updated m17n-contrib-oriya-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-punjabi-1.1.10-4.fc13.noarch Update1.1.10-5.fc13.noarch Updated m17n-contrib-sinhala-1.1.10-4.fc13.noarch Update1.1.10-5.fc13.noarch Updated m17n-contrib-tamil-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-telugu-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated m17n-contrib-urdu-1.1.10-4.fc13.noarch Update 1.1.10-5.fc13.noarch Updated papyon-0.4.8-1.fc13.noarch Update 0.4.9-1.fc13.noarch Updated ql23xx-firmware-3.03.27-3.fc12.noarch Update 3.03.28-1.fc13.noarch Updated
Re: I am not available
On 07/21/2010 01:35 AM, Till Maas wrote: Hi, I want to thank everyone for their get well wishes. I am already a lot better than I was when I wrote the initial mail and have full internet access again. The mail might have been a little premature, but this is what happens if one has access to an internet phone too soon after an accident. I guess I will be fully recovered within a week or two. Regards Till Excellent! Glad to hear it. In any case, I think it's better to err on the side of caution. Better to get a premature heads-up than none at all. -J -- - in your fear, speak 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: [HEADS-UP] systemd for F14 - the next steps
On Tue, 20.07.10 20:24, Toshio Kuratomi (a.bad...@gmail.com) wrote: On Wed, Jul 14, 2010 at 2:50 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2010-07-14 at 15:42 -0600, Kevin Fenzi wrote: Perhaps someone could put together a wiki page for lazy sysadmins with a QA? ie, I used to do this in upstart/sysvinit, how do I do it with systemd? Jóhann Guðmundsson (viking_ice) has been working on something along these lines: http://fedoraproject.org/wiki/User:Johannbg/QA/Systemd it was mentioned in the QA meeting a few weeks back. I have a few requests for things to add to that page :-) * What replaces chkconfig * What replaces /etc/init.d/SERVICENAME start | stop ? Similarly, for packaging guidelines updates, how do we install packages that provide services and have them not start up? The longer answers for most of these questions you find in Jóhann's reply. But a few additional notes: - If you only install a SysV init script, then continue to use chkconfig as usual. It works as intended to enable/disable SysV init scripts. Only if you use native systemd unit files you should use systemd-install instead. Note that most operations systemd-install executes are very easy however, as all it does is creating/removing a few suggested symlinks which are listed in a [Install] section in the unit file. It is OK and even expected to manually create additional symlinks, or remove symlinks, as the administrator likes. - Regardless whether systemd or SysV init scripts/unit files are used, systemctl start and systemctl stop are the recommended replacements for service foo start and service foo stop. Howver, as soon as https://bugzilla.redhat.com/show_bug.cgi?id=612728 is fixed you can use the old syntax for SysV scripts too in which case the right thing happens, but you'll get a blurb printed that suggests you to use systemctl instead, the next time. - If you want to enable and possibly start a service from the %post of an RPM then use the systemd-install enable command, which will create a few symlinks as listed in the [Install] section of the unit file. On top of that you may also pass --realize=... to the command, which allows you to not only enable the unit for the next boot, but also have the changes take effect immediately: i.e. --realize=reload is the very least you should use, which simply makes systemd aware of the changed symlinks. Then, at time of %preun you should use --realize=yes which makes sure the daemon is stopped in deinstallation. For a few daemons it makes sense to restart them if they are running already during upgrade. Use --realize=minimal for those. For even others (usually very low-level ones) it might even make sense to start them right-away after installation, even if they were not running before. For those use --realize=maybe. But which option you use really depends on the package. Most packages should probably stick to --realize=yes on %preun and --realize=reload in %post. Suggested .spec file fragments you find in the daemon(7) man page. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
Once upon a time, Jóhann B. Guðmundsson johan...@gmail.com said: And as the general rule goes native configuration breaks legacy configuration so if a native systemd $service file does exist than changing service via chkconfig no longer will work. As an admin, this is crap. Where does this general rule come from? As strong desire to piss off the people that actually use your software? Frankly, if all this systemd goes in as announced here, I don't see myself using Fedora much longer (and if this lands in RHEL 7, I'll be switching my company systems as well). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Email-Date-Format/EL-6 dead.package, NONE, 1.1 perl-Email-Date-Format.spec, 1.7, NONE
Author: mmaslano Update of /cvs/pkgs/rpms/perl-Email-Date-Format/EL-6 In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv4585 Added Files: dead.package Removed Files: perl-Email-Date-Format.spec Log Message: Dead package because this is already in RHEL-6. --- NEW FILE dead.package --- This packages is in RHEL-6 beta. It shouldn't be in EPEL. --- perl-Email-Date-Format.spec DELETED --- -- 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: Lost all empathy accounts after update this morning (F13)
On Wed, Jul 21, 2010 at 8:42 AM, Ankur Sinha sanjay.an...@gmail.com wrote: type=SELINUX_ERR msg=audit(1279715487.164:21): security_compute_sid: invalid context unconfined_u:unconfined_r:telepathy_mission_control_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:telepathy_mission_control_exec_t:s0 tclass=process This is the problem. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git wordsmithing wanted
On Wed, 2010-07-21 at 06:34 -0400, Toshio Kuratomi wrote: On Tue, Jul 20, 2010 at 10:38:12PM -0700, Jesse Keating wrote: It was suggested to keep the Makefile that exists in every package module/branch in CVS right now, but set it up so that any Make command issued would print a reminder to the user that the Make system has been retired and to use fedpkg. I could use some word smithing on this message. What I have right now is this: $ make tag Make system retired, please use fedpkg. See fedpkg --help Suggestions on what to put in here? I agree with roland and hans about the necessity of this but if you do go ahead. Probably want to say: make is no longer used to build packages. Use fedpkg instead. yum install fedora-packager fedpkg --help Or: make is no longer used to build packages. See: http://fedoraproject.org/wiki/Using_Fedpkg I like this idea, iff it is the message being put in the Makefiles before cvs.fedoraproject.org goes readonly and dist-cvs is phased out, so that everybody using old CVS checkouts will eventually run into something like this: $ make tag Error: Make is no longer used to build packages. Use fedpkg instead. See http://fedoraproject.org/wiki/Using_Fedpkg for details. $ As to Makefiles in the new dist-git repos, I still strongly prefer not having any Makefiles there at all. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Tue, 2010-07-20 at 23:22 -0700, Roland McGrath wrote:
Using names like f13, el5, and so forth would also keep dist-git
consistent with git branch naming conventions. If we were to do
something like that we might as well just use the value of %{dist}.
But that's just too obviously right for us to be allowed to do it!
That was going to be my next question, although that would bring back
the c in fc13 and fc14 since that's what the dist value is. We could
bite the bullet and change the dist value to remove the c, and just
manually keep track of making sure that builds on older releases won't
be newer than builds on the newer branches. not sure if we want to go
through that pain at this point.
I'd say bite the bullet. Die, little c, die! It just looks silly there
nowadays, since the C-word has not been in our vocabulary for so long now.
Would this count as a core dump? :P
(Sorry)
Dave
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Lost all empathy accounts after update this morning (F13)
On Wed, 2010-07-21 at 09:25 -0400, Colin Walters wrote: On Wed, Jul 21, 2010 at 8:42 AM, Ankur Sinha sanjay.an...@gmail.com wrote: type=SELINUX_ERR msg=audit(1279715487.164:21): security_compute_sid: invalid context unconfined_u:unconfined_r:telepathy_mission_control_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:telepathy_mission_control_exec_t:s0 tclass=process This is the problem. hi, Okay, what needs to be done to fix it? (Since I don't think I'm the only one whose come across this) Thanks, Regards, Ankur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Lost all empathy accounts after update this morning (F13)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/21/2010 08:42 AM, Ankur Sinha wrote: type=SELINUX_ERR msg=audit(1279715487.164:21): security_compute_sid: invalid context unconfined_u:unconfined_r:telepathy_mission_control_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 That is the problem -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxG+V0ACgkQrlYvE4MpobNXPACgz7/pGuMnKYTYPy5+ySGpxfCm UU4AoKMEkbzJUHgxXPheYKeTWHAc1z5B =zTLR -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Lost all empathy accounts after update this morning (F13)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/21/2010 09:39 AM, Ankur Sinha wrote: On Wed, 2010-07-21 at 09:25 -0400, Colin Walters wrote: On Wed, Jul 21, 2010 at 8:42 AM, Ankur Sinha sanjay.an...@gmail.com wrote: type=SELINUX_ERR msg=audit(1279715487.164:21): security_compute_sid: invalid context unconfined_u:unconfined_r:telepathy_mission_control_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:telepathy_mission_control_exec_t:s0 tclass=process This is the problem. hi, Okay, what needs to be done to fix it? (Since I don't think I'm the only one whose come across this) Thanks, Regards, Ankur Easiest thing for now it to change the context of the telepathy functions. chcon -t bin_t /usr/libexec/mission-control* /usr/libexec/telepathy* Should make it work for now. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxG+egACgkQrlYvE4MpobNXPQCfSdxGBAx7fi9GTUDBu/hf/Un/ DbgAoLabDd/l5fWP+ki1XxGAmHyj5REa =QoNe -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Lost all empathy accounts after update this morning (F13)
On Wed, 2010-07-21 at 09:45 -0400, Daniel J Walsh wrote: chcon -t bin_t /usr/libexec/mission-control* /usr/libexec/telepathy* That fixed it. Thanks regards, Ankur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Wed, 2010-07-21 at 11:19 +0200, Hans Ulrich Niedermann wrote: Ugly potential fix for this ugly issue: Patch rpm and yum to compare N-V-R.fc13 exactly like N-V-R.f13, and carry that patch until F-15. That would be ... hard. And ugly doesn't even begin to describe it. Also IMO using only a single letter for the dist seems overly space optimizing ... if you just want to remove all references to Fedora Core, propose it changes to fed14 or even just rename what the c stands for (like the GCC rename). -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumBenchmarks http://yum.baseurl.org/wiki/YumHistory -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Wed, 2010-07-21 at 10:08 -0400, James Antill wrote: On Wed, 2010-07-21 at 11:19 +0200, Hans Ulrich Niedermann wrote: Ugly potential fix for this ugly issue: Patch rpm and yum to compare N-V-R.fc13 exactly like N-V-R.f13, and carry that patch until F-15. That would be ... hard. And ugly doesn't even begin to describe it. Also IMO using only a single letter for the dist seems overly space optimizing ... if you just want to remove all references to Fedora Core, propose it changes to fed14 or even just rename what the c stands for (like the GCC rename). +1 on not just hard but REALLY ugly. Pretty confident that the rpm devs would reject such a patch, too. I know the yum devs will :) -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Wed, 2010-07-21 at 10:08 -0400, James Antill wrote: On Wed, 2010-07-21 at 11:19 +0200, Hans Ulrich Niedermann wrote: Ugly potential fix for this ugly issue: Patch rpm and yum to compare N-V-R.fc13 exactly like N-V-R.f13, and carry that patch until F-15. That would be ... hard. And ugly doesn't even begin to describe it. I wholeheartedly agree. :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Wednesday, July 21, 2010 11:19:54 Hans Ulrich Niedermann wrote:
On Wed, 2010-07-21 at 10:55 +0200, Hans Ulrich Niedermann wrote:
On Tue, 2010-07-20 at 22:15 -0700, Jesse Keating wrote:
On 07/20/2010 08:55 PM, Garrett Holmstrom wrote:
Using names like f13, el5, and so forth would also keep dist-git
consistent with git branch naming conventions. If we were to do
something like that we might as well just use the value of %{dist}.
That was going to be my next question, although that would bring back
the c in fc13 and fc14 since that's what the dist value is. We could
bite the bullet and change the dist value to remove the c, and just
manually keep track of making sure that builds on older releases won't
be newer than builds on the newer branches. not sure if we want to
go through that pain at this point.
Don't we have a (few) mass rebuilds in front of us before F-14 anyway?
gold and similar stuff? That would increase the R of N-V-R anyway, so we
could switch %{dist} from fc14 to f14 at the same time for probably the
majority of packages.
Oh. Darn. We still need to make sure that *.fc12 and *.fc13 packages do
not have the same N-V-R modulo %{dist} as F14 has, until F13 is EOLed,
i.e. until F15 comes out. That still sounds ugly. Well, all of that is
ugly regarding the c, whatever we do or do not do.
Ugly potential fix for this ugly issue: Patch rpm and yum to compare
N-V-R.fc13 exactly like N-V-R.f13, and carry that patch until F-15.
another less ugly (but still ugly) solution would be adding:
Obsoletes: N-V-R.fc13
Obsoletes: N-V-R.fc12
in koji automatically for the same NVR as the package has, but I don't know if
this would not make yum's depsolver cry
Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should GnuPG 1.4.x be revived?
On Jul 14, 2010, at 5:22 AM, Tomas Mraz wrote: On Tue, 2010-07-13 at 18:42 +0200, Karel Klic wrote: On 07/13/2010 06:03 PM, Brian C. Lane wrote: This is why I'm so surprised to see gpg be deprecated in f13. Upstream is supporting both and the manpage even indicates that the binary should be gpg2. I don't see any reason for it to have been removed in f13, and am willing to help maintain it. We could also ask original maintainers of gnupg, if they are willing to co-maintain it. https://admin.fedoraproject.org/pkgdb/acls/name/gnupg I am not interested in co-maintaining gnupg-1. However I do not oppose to revive it in koji. Forgive my ignorance of the process, but how can I help this happen? Aside from my own problems with the change, there are other reports of people upgrading to F13 only to find their GnuPG setup nonfunctional when their gnupg transformed into gnupg2: http://lists.gnupg.org/pipermail/gnupg-users/2010-June/038817.html David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Wed, 2010-07-21 at 16:39 +0200, Michal Hlavinka wrote: another less ugly (but still ugly) solution would be adding: Obsoletes: N-V-R.fc13 Obsoletes: N-V-R.fc12 in koji automatically for the same NVR as the package has, but I don't know if this would not make yum's depsolver cry Even assuming we could make sure that does the correct thing (it probably would but I know it's not tested :), adding 40,000 obsoletes to the repo. is ... let's say: unlikely to make yum faster. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumBenchmarks http://yum.baseurl.org/wiki/YumHistory -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, Jul 21, 2010 at 3:14 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Jóhann B. Guðmundsson johan...@gmail.com said: And as the general rule goes native configuration breaks legacy configuration so if a native systemd $service file does exist than changing service via chkconfig no longer will work. As an admin, this is crap. Where does this general rule come from? As strong desire to piss off the people that actually use your software? So different == crap ? If it does provide a hard to use interface I'd understand the frustration but only because it is NEW / DIFFERENT does not mean that the world is falling over. Seriously an admin that refuses to learn anything new (omg it isn't the same as I have been doing for the last 10 years) he should really consider changing job / profession. Changes aren't bad for the sole reasons of being changes. If the new interface is crap ok complain about it but it being different (as long as it is documented) is a non issue IMO. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Package: udev-151-8.fc13 Tag: dist-f13-updates Status: failed Built by: ctyler
On 07/21/2010 05:12 PM, Koji Build System wrote: ;client certificate Subject: Package: udev-151-8.fc13 Tag: dist-f13-updates Status: failed Built by: ctyler To: cty...@fedoraproject.org, har...@fedoraproject.org X-Koji-Tag: dist-f13-updates X-Koji-Package: udev X-Koji-Builder: ctyler X-Koji-Status: failed Package: udev-151-8.fc13 Tag: dist-f13-updates Status: failed Built by: ctyler ID: 3055 Started: Wed, 21 Jul 2010 11:02:36 EDT Finished: Wed, 21 Jul 2010 11:12:15 EDT udev-151-8.fc13 (3055) failed on arm4 (noarch), arm3 (armv5tel): BuildError: error building package (arch armv5tel), mock exited with status 1; see build.log for more information Failed tasks: - Task 1880 on arm4 Task Type: build (dist-f13-updates-candidate, udev-151-8.fc13.src.rpm) Task 1881 on arm3 Task Type: buildArch (udev-151-8.fc13.src.rpm, armv5tel) logs: http://arm.koji.fedoraproject.org/koji/getfile?taskID=1881name=build.log http://arm.koji.fedoraproject.org/koji/getfile?taskID=1881name=root.log http://arm.koji.fedoraproject.org/koji/getfile?taskID=1881name=state.log Task Info: http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1880 Build Info: http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=3055 checking whether build environment is sane... configure: error: newly created file is older than distributed files! you seem to have a time problem!!! And also a mail problem.. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
Once upon a time, drago01 drag...@gmail.com said: On Wed, Jul 21, 2010 at 3:14 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Jóhann B. Guðmundsson johan...@gmail.com said: And as the general rule goes native configuration breaks legacy configuration so if a native systemd $service file does exist than changing service via chkconfig no longer will work. As an admin, this is crap. Where does this general rule come from? As strong desire to piss off the people that actually use your software? So different == crap ? Different for no good reason (other than to break legacy configuration) is crap. Providing multiple interfaces, one to manage some services and one to manage the others, is major crap. Seriously an admin that refuses to learn anything new (omg it isn't the same as I have been doing for the last 10 years) he should really consider changing job / profession. This isn't about managing one system; it's about managing lots of systems and now one is different (but only for some services, who knows which) for no good reason. Changes aren't bad for the sole reasons of being changes. Change for the sake of change is always a bad sign of let's reinvent the wheel. How hard would it be to provide backwards-compatible chkconfig and service commands? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: I am not available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/20/2010 11:35 PM, Till Maas wrote: Hi, I want to thank everyone for their get well wishes. I am already a lot better than I was when I wrote the initial mail and have full internet access again. The mail might have been a little premature, but this is what happens if one has access to an internet phone too soon after an accident. I guess I will be fully recovered within a week or two. Glad to hear it! Take your time and heal up :) - -- Brian C. Lane b...@redhat.com Red Hat / Port Orchard, WA -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBTEcUPhF+jBaO/jp/AQKjnAf/SilgapyzypERxAtQLwXDH5tdzIvfytH+ MpsAYxj7hEOrZteCsoW9wuxMNG3DpL1uj2YuclAVzGlg8rdQ4VeEvcWJ8ZcpuEqA V66fNNI1VYWNDyX/BC/yarVOzpV14so4UQ7bhIFn65HeqMcQCt/qQbxpo4PSAX8V APufgMUzhAGQmi/9DgMpqIzWW+1zx6qy1+ko1If6u1ZwJxqvr/N7Rkq0aGTE70pX 9p7EfToYnDmm3AGTjR7BK/YoW9/ryW1tlC6QcRhOHwlwke4I3xOjc2nIkiIKRQB3 Yl80f4pWdcoP/uiHdDCcQPhCejV9sfU3tXIvJFzK9CBwS0dm8bD+cg== =IRqb -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should GnuPG 1.4.x be revived?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/21/2010 07:44 AM, David Shaw wrote: On Jul 14, 2010, at 5:22 AM, Tomas Mraz wrote: On Tue, 2010-07-13 at 18:42 +0200, Karel Klic wrote: On 07/13/2010 06:03 PM, Brian C. Lane wrote: This is why I'm so surprised to see gpg be deprecated in f13. Upstream is supporting both and the manpage even indicates that the binary should be gpg2. I don't see any reason for it to have been removed in f13, and am willing to help maintain it. We could also ask original maintainers of gnupg, if they are willing to co-maintain it. https://admin.fedoraproject.org/pkgdb/acls/name/gnupg I am not interested in co-maintaining gnupg-1. However I do not oppose to revive it in koji. Forgive my ignorance of the process, but how can I help this happen? Aside from my own problems with the change, there are other reports of people upgrading to F13 only to find their GnuPG setup nonfunctional when their gnupg transformed into gnupg2: http://lists.gnupg.org/pipermail/gnupg-users/2010-June/038817.html David My understanding is that someone needs to update the gnupg package and run it through the package review process again since it was deprecated, not just orphaned. gnupg2 needs to not obsolete gnupg in its .spec file And I would also prefer it if gnupg2 didn't overload the gnupg binaries, keeping things in line with upstream which meant for gnupg 1.x and 2.x to be installed in parallel. That brings up an additional problem in that now we have had users of f13 using gpg as gpg2, so a switch back might cause some friction -- but I think it is the right way to do things. - -- Brian C. Lane b...@redhat.com Red Hat / Port Orchard, WA -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBTEcWGRF+jBaO/jp/AQLlFAf/ZdyjIoz0RVlct5MtqfOuRcs6GBoqIWgr 4kziAk4RFCqdCw17K0yVpwEmmQPwQkbhUoniK3sJnforTSs1YETTQ0IZunEYIA20 aIUVdTmg7bobpQuOn6FWr18Hg+nytVWdqGw6BElxwVoQlOZhuW9cFzjLeTFgy9ff Pnf9jM7HpqcKT6sRanuvDrrIMWCrxqOG3/ku0X3TZso7uND9JFeofdFZzFnQavd3 LkANaJ2g73b/qf7MXlV0/YXGgOXYpLaZCLpGHVaF9voWPYI0yKvRrb1U12Q8Tbkq dLlG3ubwPgSCsdFjqwysgThL6dRCefiyEpzNeOcAkP8AX2/XaBLq3A== =3G7d -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, 2010-07-21 at 17:16 +0200, drago01 wrote: On Wed, Jul 21, 2010 at 3:14 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Jóhann B. Guðmundsson johan...@gmail.com said: And as the general rule goes native configuration breaks legacy configuration so if a native systemd $service file does exist than changing service via chkconfig no longer will work. As an admin, this is crap. Where does this general rule come from? As strong desire to piss off the people that actually use your software? So different == crap ? If it does provide a hard to use interface I'd understand the frustration but only because it is NEW / DIFFERENT does not mean that the world is falling over. In general, yes, it does (just not to you): http://skvidal.wordpress.com/2008/10/29/fedora-culture-clashes/ ...however this case (breaking service/chkconfig) seems like such a huge pointless difference that I can't imagine RHEL-7 not requiring that it's fixed. So the only real question is how long Fedora users have to live with it broken. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
glibc heads up
right now a glibc build is going on that has --enablekernel=2.6.32 from Jakub Bumping that from 2.6.18 used currently means e.g. to get rid of compat bloat for private futexes, utimensat, fallocate, O_CLOEXEC/pipe2 etc. (lots of cloexec/nonblocking stuff), ADJ_OFFSET_SS_READ, accept4, realtime clocks in futexes, missing AT_RANDOM, preadv/pwritev, F_GETOWN_EX. Especially private futexes and the cloexec/nonblock stuff affects quite a lot of glibc code. what this does mean is that you can no longer use rhel5 to build fedora 14 and newer packages. though you had to jump though hoops already to do this Dennis signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
2010/7/21 Jóhann B. Guðmundsson johan...@gmail.com: Admins will need to know that they have to use chkconfig for services that do not have a native systemd $service file. ( legacy for services ) And as the general rule goes native configuration breaks legacy configuration so if a native systemd $service file does exist than changing service via chkconfig no longer will work. Would it be reasonable to extend chkconfig so that it can know which services it can no longer control and provide a pointer blurb to admins when they try to use chkconfig with those services in the F14 timeframe. The reality is any change to scriptable behaviour is a pitchfork wielding mob scenario. (mental note: this would make a good Simpson's episode) If we are breaking curmudgeony workflows it be really nice to provide some breadcrumbs along the way to help us old dogs learn new tricks. Admins are going to need to learn how to use and configure systemd native configs in the F14 timeframe, feedback from the legacy system tools when we need to recondition our muscle memory and are scripted actions would go a long way to lowering the frustration level...if the native/legacy tool break can't be avoided. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Partial mass rebuild for Python 2.7 coming soon (I hope)
On Tue, 2010-07-20 at 17:18 -0800, Jeff Spaleta wrote: On Tue, Jul 20, 2010 at 4:02 PM, David Malcolm dmalc...@redhat.com wrote: I'm planning to do a partial mass-rebuild for Python 2.7. Please, when you hit build failures, and you will if you can provide a link to a failure report that is easily searchable(if not sorted by) primary package owner. That will help me,help you, do any clean up for packages I have some modicum of clue about and feel accountable for. Good idea - they're much easier to deal with that way. It looks like the find-failures.py script [1] is already written to provide results in this form. Good luck. Thanks! Dave [1] http://git.fedorahosted.org/git/?p=releng;a=blob;f=scripts/find-failures.py -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora packaging: unison?
Hi, Gerard. I just realized I need a newer build of Unison - 2.32 - to sync with a machine running a different distro. I see from the -devel archives that you currently don't have enough time to maintain your packages. I'd like to ask you to make me a co-maintainer so I can do this, but obviously with the way you have unison packaged there's something of a wrinkle :). What was the initial reason for the 2.18 / 2.27 packaging split? Is there any reason to continue to package multiple releases? Should we just go back to having a single, 2.32-versioned 'unison' package, or should we bump unison227 to be 2.32, or add a unison232 package? Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora packaging: unison?
Adam Williamson wrote: What was the initial reason for the 2.18 / 2.27 packaging split? Is there any reason to continue to package multiple releases? Should we just go back to having a single, 2.32-versioned 'unison' package, or should we bump unison227 to be 2.32, or add a unison232 package? My memory[1] scares me sometimes. [1] https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01229.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Lost all empathy accounts after update this morning (F13)
On Wed, 2010-07-21 at 09:45 -0400, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/21/2010 09:39 AM, Ankur Sinha wrote: On Wed, 2010-07-21 at 09:25 -0400, Colin Walters wrote: On Wed, Jul 21, 2010 at 8:42 AM, Ankur Sinha sanjay.an...@gmail.com wrote: type=SELINUX_ERR msg=audit(1279715487.164:21): security_compute_sid: invalid context unconfined_u:unconfined_r:telepathy_mission_control_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:telepathy_mission_control_exec_t:s0 tclass=process This is the problem. hi, Okay, what needs to be done to fix it? (Since I don't think I'm the only one whose come across this) Thanks, Regards, Ankur Easiest thing for now it to change the context of the telepathy functions. chcon -t bin_t /usr/libexec/mission-control* /usr/libexec/telepathy* Should make it work for now. Was the problematic change done in telepathy/empathy or in selinux-policy? Either way, can someone file negative karma so the update doesn't get pushed (if it hasn't already)? (I don't use empathy, so it's hard for me to track this myself :/) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, 2010-07-21 at 08:03 -0800, Jeff Spaleta wrote: 2010/7/21 Jóhann B. Guðmundsson johan...@gmail.com: Admins will need to know that they have to use chkconfig for services that do not have a native systemd $service file. ( legacy for services ) And as the general rule goes native configuration breaks legacy configuration so if a native systemd $service file does exist than changing service via chkconfig no longer will work. Would it be reasonable to extend chkconfig so that it can know which services it can no longer control and provide a pointer blurb to admins when they try to use chkconfig with those services in the F14 timeframe. The reality is any change to scriptable behaviour is a pitchfork wielding mob scenario. (mental note: this would make a good Simpson's episode) If we are breaking curmudgeony workflows it be really nice to provide some breadcrumbs along the way to help us old dogs learn new tricks. Admins are going to need to learn how to use and configure systemd native configs in the F14 timeframe, feedback from the legacy system tools when we need to recondition our muscle memory and are scripted actions would go a long way to lowering the frustration level...if the native/legacy tool break can't be avoided. It occurs to me that chkconfig isn't, in packaging terms, part of either upstart or systemd. It's just a standalone utility, it builds from its own SRPM. systemd being an open source project, its interfaces shouldn't be hard to figure out, and hey, I seem to recall seeing quite a bit of documentation, and Lennart seems perfectly happy to provide info when asked. So...why can't any of those complaining about this just go ahead and patch chkconfig to support systemd? It's not like Lennart can stop you, no matter how much he twirls his moustache ;) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On 07/21/2010 04:03 PM, Jeff Spaleta wrote: Would it be reasonable to extend chkconfig so that it can know which services it can no longer control and provide a pointer blurb to admins when they try to use chkconfig with those services in the F14 timeframe. The reality is any change to scriptable behaviour is a pitchfork wielding mob scenario. (mental note: this would make a good Simpson's episode) If we are breaking curmudgeony workflows it be really nice to provide some breadcrumbs along the way to help us old dogs learn new tricks. Admins are going to need to learn how to use and configure systemd native configs in the F14 timeframe, feedback from the legacy system tools when we need to recondition our muscle memory and are scripted actions would go a long way to lowering the frustration level...if the native/legacy tool break can't be avoided. FYI. There is work being done to allow as smooth transaction as possible. Lennart has added to his todo list to look at letting systemd-install fallback to chkconfig if no native systemd service file is found which will smooth the transaction from the legacy chkconfig to systemd-install enable/disable $foo.service. There is an RFE for the same compatibility from chkconfig #616857 as in chkconfig will try to use systemd native files first and spill out a deprecation warning or just spill out deprecation warning hinting users ( Written in C patches welcome ) and #612728 is dealing with users that directly run /etc/init.d/foo along the way cleaning some other stuff which should have been done eons ago and I suspect /sbin/service will be fixed at the same time. rant at those nei sayers I must say it's interesting to see how the community holds so dear to the code that was forge by putting holes in paper and have absolutely no problem screaming at baby when it's barely out of it's birth canal. . . Regular desktop end user wont notice any other change other than perhaps faster bootup and the people that call themselves power/advanced/admin users should have no problem to adapt and are urged from the start to use systemd-install and systemctl however if there is nothing but air in that power and the only thing they are capable of administrating are themselves with the only advancement they show is getting closer to the door on their way out, there is a point and click operating system waiting for them around the corner which they can play power/advanced/admin crossword pussle by checking random boxes to make things work for them or they can choose to stay on F13 until it EOL then switch to F15 which hopefully all upstream has provided native systemd service files for their daemon and most if any cruff has been sorted out. For god sakes people alpha aint even out the door yet! /rant at those nei sayers JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora packaging: unison?
On Wed, 2010-07-21 at 11:51 -0500, Michael Cronenworth wrote: Adam Williamson wrote: What was the initial reason for the 2.18 / 2.27 packaging split? Is there any reason to continue to package multiple releases? Should we just go back to having a single, 2.32-versioned 'unison' package, or should we bump unison227 to be 2.32, or add a unison232 package? My memory[1] scares me sometimes. [1] https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01229.html Thanks, but afaics that thread doesn't really answer any of my questions, it's just a bunch of yum technicalities about how the implementation of having two packages actually works. What I'm interested in is what was the original reason for having two branches packaged, and do we still need to do it (or even have 3). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, Jul 21, 2010 at 10:29:40AM -0500, Chris Adams wrote: Different for no good reason (other than to break legacy configuration) is crap. Plus one million to this, by the way. Providing multiple interfaces, one to manage some services and one to manage the others, is major crap. *nod* -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora packaging: unison?
On 21 July 2010 12:12, Adam Williamson awill...@redhat.com wrote: Thanks, but afaics that thread doesn't really answer any of my questions, it's just a bunch of yum technicalities about how the implementation of having two packages actually works. What I'm interested in is what was the original reason for having two branches packaged, and do we still need to do it (or even have 3). In broad terms, later unison versions are not wire compatible with earlier ones. i.e. unison developers regularly break wire compatibility. Since people have a need to synchronize with machines running different unison versions, multiple unison versions are needed to be packaged, alas. Jonathan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, 21.07.10 13:12, Matthew Miller (mat...@mattdm.org) wrote: On Wed, Jul 21, 2010 at 12:04:39PM +, Jóhann B. Guðmundsson wrote: ls /lib/systemd/system/ To enable service ( chkconfig $service on ) systemd-install enable $service.service To disable service ( chkconfig $service off ) systemd-install disable $service.service I don't care what specific name you chose, but systemd-install is not a very administrator-friendly choice. In what way is disabling a service installing systemd? It's called systemd-install, not install-systemd. systemd- is the common prefix for many of the systemd tools (though not all). How very discoverable. I am pretty sure there'll be folks who finds issues with every name we pick. I am not going to play the game of making everybody happy. Sorry. And in this case, where it's clearly a matter of taste and bike-shedding I probably shouldn't even have bothered to even reply to this mail of yours. Having admin-friendly names (like service foo start) is important for mindshare. Well, I believe these ones are admin friendly. But well, If people disagree then I guess we have to agree to disagree on this. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
2010/7/21 Jóhann B. Guðmundsson johan...@gmail.com: There is an RFE for the same compatibility from chkconfig #616857 as in chkconfig will try to use systemd native files first and spill out a deprecation warning or just spill out deprecation warning hinting users ( Written in C patches welcome ) and #612728 is dealing with users that directly run /etc/init.d/foo along the way cleaning some other stuff which should have been done eons ago and I suspect /sbin/service will be fixed at the same time. Cool. I'll keep those in mind. rant at those nei sayers I must say it's interesting to see how the community holds so dear to the code that was forge by putting holes in paper and have absolutely no problem screaming at baby when it's barely out of it's birth canal. . . Community is an interesting word. And I don't think it applies here. Sysadmins are a breed apart quite frankly because other people expect them to be. And if you don't realize that sysadmins as a subspecies of the larger human experience are going to be grump-tastic about any changes...you don't know enough sysadmins and you aren't going to make many of them your friend. Is it rational? Nope..but it is what it is. Know your audience. There's a difference between looking forward to adapting to change and the inherent ability to adapt to change.. the two personality traits don't necessarily go together. I'm here to tell you that sysadmins don't historically, as the only unchallengeable monolithic human cultural stereotype, enjoy adapting..especially when they are told to suck it up and just deal with it...which is basically what they are told on a daily basis. Being good at adapting can wear you down when people grow an expectation that you are uncharacteristically good at doing it... just saying. I'm not part of the zero regression fanclub. But I'd like to help do what is reasonable to minimize the frustration of introducing a new way of doing things. The deprecation warnings are reasonable to me. We aren't going to reduce that frustration to zero of course. But we sure as hell aren't going to blunt the unavoidable pitchforks by telling sysadmin to just suck it up. I'd like to find a way to sell them on short term pain for long term gain from the sysadmin point of view. -jefI'd tell you to go out and hug a sysadmin but that probably just get you punchedspaleta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, 21.07.10 10:00, Adam Williamson (awill...@redhat.com) wrote: If we are breaking curmudgeony workflows it be really nice to provide some breadcrumbs along the way to help us old dogs learn new tricks. Admins are going to need to learn how to use and configure systemd native configs in the F14 timeframe, feedback from the legacy system tools when we need to recondition our muscle memory and are scripted actions would go a long way to lowering the frustration level...if the native/legacy tool break can't be avoided. It occurs to me that chkconfig isn't, in packaging terms, part of either upstart or systemd. It's just a standalone utility, it builds from its own SRPM. systemd being an open source project, its interfaces shouldn't be hard to figure out, and hey, I seem to recall seeing quite a bit of documentation, and Lennart seems perfectly happy to provide info when asked. So...why can't any of those complaining about this just go ahead and patch chkconfig to support systemd? It's not like Lennart can stop you, no matter how much he twirls his moustache ;) I have no moustache. ;-) But otherwise you are right. Let me say here that the scripts in /etc/init.d resp. everything run via /sbin/service already will have the necessary glue code in there as soon as Bill merges https://bugzilla.redhat.com/show_bug.cgi?id=612728 . It will forward start/stop requests to systemctl. That means people can continue to use /etc/init.d/foo start and /sbin/service foo start, and the right thing will happen and they'll learn something too. We can add similar code to chkconfig too: something that warns the admin when a native systemd unit file exists, and then redirects the command properly. It is now on my todo list, but not even near the top of the list. I would greatly appreciate if somebody would work on this, because I am currently pushing this through single-handedly everywhere else now. In fact I'd appreciate help in all areas. For example, if somebody would pick up the /var/run resp. /var/lock on tmpfs issue I'd be a happy man. Or if somebody would help me and post the unit files from http://0pointer.de/public/systemd-units/ on bugzilla, then I'd be even happier. Of course, if the other folks on this list think that bike-shedding and nitpicking is time better spent then actually doing things and helping with the integration, then they are welcome to continue wasting my time by wanting to discuss the names of the binaries we use. Jeez. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, Jul 21, 2010 at 9:45 AM, Lennart Poettering mzerq...@0pointer.de wrote: We can add similar code to chkconfig too: something that warns the admin when a native systemd unit file exists, and then redirects the command properly. It is now on my todo list, but not even near the top of the list. Is there a reasonable deadline to shoot for? Let me get past this weekend and I'll try to commit to doing so that I can be publicly shamed if I fail at doing it. Is there a todo list published that can be scanned by other interested parties for low hanging fruit? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: NetworkManager-0.8.1-0.4 updates not pushed?
On Sat, 2010-07-17 at 13:36 +0200, Michel Alexandre Salim wrote: Hi, F-13's NetworkManager is currently still at version 0.8.1-0.1.git20100510.fc13, which on my Sony netbook intermittently disconnects on some networks, and could not pair up with the Google Nexus One's wireless tether (Android 2.2) if WPA-PSK authentication is enabled (it connects fine if the Nexus One's hotspot is left open). WPA-PSK adhoc networks don't work at this time due to driver and supplicant issues, which I'm trying to chase down. If that's what Froyo's hotspot thing uses. Obviously we'd expect infrastructure/AP mode to work. Dan Williams built 0.8.1-0.4 on June 25th, and that solved the problem nicely, but somehow this was not pushed as an update. Could one of the maintainers do it? Otherwise, if there's no objection, I'll push that build in a few days, before Koji recycles it. Looks like it got recycled... But I'd like to build a new NM anyway. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora packaging: unison?
On Wed, 21 Jul 2010 11:51:02 -0500, Michael wrote: Adam Williamson wrote: What was the initial reason for the 2.18 / 2.27 packaging split? Is there any reason to continue to package multiple releases? Should we just go back to having a single, 2.32-versioned 'unison' package, or should we bump unison227 to be 2.32, or add a unison232 package? My memory[1] scares me sometimes. [1] https://www.redhat.com/archives/fedora-devel-list/2008-April/msg01229.html My memory adds that it has been discussed somewhere else, perhaps on EPEL's list. The multiple packages were needed for compatibility. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora packaging: unison?
Adam Williamson wrote: Thanks, but afaics that thread doesn't really answer any of my questions, it's just a bunch of yum technicalities about how the implementation of having two packages actually works. What I'm interested in is what was the original reason for having two branches packaged, and do we still need to do it (or even have 3). Jeff Splata's reply seemed to be enlightening, at least to me: The unison developers..in their infinite wisdom have decided that they don't actually want to worry about backwards compatibility between client versions, so if you need to talk across the network to different machines you need to be sure you have the same version of unison available on both machines or the magic doesn't work. The horrible horrible package naming for unison that we have is a result of that upstream decision to make sure people who want to use unison can be sure they have the right versions of unison installed to communicate to machines running other operating systems. The package naming in the case of unison is done deliberately to break how version comparison in the package system is suppose to work.It's a corner case... that needs to die. Adding more logic at the packaging layer to support what is really upstream's inability to provide adequate protocol versioning support is wasted effort. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora packaging: unison?
Michael Cronenworth wrote: Jeff Splata's reply seemed to be enlightening, at least to me: /s/Splata/Spaleta/ Sorry, Jeff! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora packaging: unison?
On Wed, 2010-07-21 at 12:58 -0500, Michael Cronenworth wrote: Adam Williamson wrote: Thanks, but afaics that thread doesn't really answer any of my questions, it's just a bunch of yum technicalities about how the implementation of having two packages actually works. What I'm interested in is what was the original reason for having two branches packaged, and do we still need to do it (or even have 3). Jeff Splata's reply seemed to be enlightening, at least to me: ah, thanks, missed that one. I guess we could have a look and see what versions are in the still-supported releases of popular distros, and just go with those. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, Jul 21, 2010 at 5:47 PM, James Antill ja...@fedoraproject.org wrote: On Wed, 2010-07-21 at 17:16 +0200, drago01 wrote: On Wed, Jul 21, 2010 at 3:14 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Jóhann B. Guðmundsson johan...@gmail.com said: And as the general rule goes native configuration breaks legacy configuration so if a native systemd $service file does exist than changing service via chkconfig no longer will work. As an admin, this is crap. Where does this general rule come from? As strong desire to piss off the people that actually use your software? So different == crap ? If it does provide a hard to use interface I'd understand the frustration but only because it is NEW / DIFFERENT does not mean that the world is falling over. In general, yes, it does (just not to you): I though we where talking about *admins* here not $grandma ... And when I say/here admin I'd expect to be talking about a human (not some kind of robot that has hardwired commands and can't adapt to changes). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Lost all empathy accounts after update this morning (F13)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/21/2010 12:53 PM, Adam Williamson wrote: On Wed, 2010-07-21 at 09:45 -0400, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/21/2010 09:39 AM, Ankur Sinha wrote: On Wed, 2010-07-21 at 09:25 -0400, Colin Walters wrote: On Wed, Jul 21, 2010 at 8:42 AM, Ankur Sinha sanjay.an...@gmail.com wrote: type=SELINUX_ERR msg=audit(1279715487.164:21): security_compute_sid: invalid context unconfined_u:unconfined_r:telepathy_mission_control_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:telepathy_mission_control_exec_t:s0 tclass=process This is the problem. hi, Okay, what needs to be done to fix it? (Since I don't think I'm the only one whose come across this) Thanks, Regards, Ankur Easiest thing for now it to change the context of the telepathy functions. chcon -t bin_t /usr/libexec/mission-control* /usr/libexec/telepathy* Should make it work for now. Was the problematic change done in telepathy/empathy or in selinux-policy? Either way, can someone file negative karma so the update doesn't get pushed (if it hasn't already)? (I don't use empathy, so it's hard for me to track this myself :/) It was an selinux-policy push. But I think it is in the wild. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxHNvoACgkQrlYvE4MpobOP7QCg5t8FK6fYS++mk3F3F+fAx89v Y0EAnjRIRoOVKF2RYo46B/Vj0w3iUhoq =3Jb2 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
Once upon a time, drago01 drag...@gmail.com said: And when I say/here admin I'd expect to be talking about a human (not some kind of robot that has hardwired commands and can't adapt to changes). If you only have to manage one system, good for you. I have to manage a bunch, and everything that is different _for_no_good_reason_ between them is a PITA. Yes, management scripts can be adapted, but now they have to handle systems A-Z one way, systems AA-ZZ another (but apparently not for all services, try to guess which?). That makes an admin unhappy and less likely to deploy any more of systems type AA-ZZ. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question on SELinux AVC messages with systemd.
On Tue, Jul 20, 2010 at 04:26:14PM +0200, Lennart Poettering wrote: On Tue, 20.07.10 16:04, Lennart Poettering (mzerq...@0pointer.de) wrote: I am not entirely sure though why those processes actually access those dirs in this case. Maybe they are iterating through the files in /dev? Smells a bit broken to me. OK, the udevd is a result from /lib/udev/devices/ which is copied to /dev early on boot by udevd. Kay says that this dir reeally should not be put in /lib/udev/devices/. Still puzzled why LVM wants with /dev/mqueue though. Anybody from LVM around who can say something about this? lvm is brain damaged. strace lvm pvscan, and watch as it opens a bunch of stuff that there's no way there'd ever be a volume on. /dev/snd/*, tty's, usbmon etc etc It's been this way for years. I first noticed it when it triggered a bug in agpgart a long time ago. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should GnuPG 1.4.x be revived?
On Jul 21, 2010, at 11:45 AM, Brian C. Lane wrote: I am not interested in co-maintaining gnupg-1. However I do not oppose to revive it in koji. Forgive my ignorance of the process, but how can I help this happen? Aside from my own problems with the change, there are other reports of people upgrading to F13 only to find their GnuPG setup nonfunctional when their gnupg transformed into gnupg2: http://lists.gnupg.org/pipermail/gnupg-users/2010-June/038817.html My understanding is that someone needs to update the gnupg package and run it through the package review process again since it was deprecated, not just orphaned. How does this happen (i.e. who is the someone)? I'm happy to help in any way I can, but I'm not currently a Fedora contributor. I'm just an upstream GnuPG guy. gnupg2 needs to not obsolete gnupg in its .spec file And I would also prefer it if gnupg2 didn't overload the gnupg binaries, keeping things in line with upstream which meant for gnupg 1.x and 2.x to be installed in parallel. That brings up an additional problem in that now we have had users of f13 using gpg as gpg2, so a switch back might cause some friction -- but I think it is the right way to do things. I agree. It might cause friction, but of course the status quo is causing friction for some pre-f13 people using gpg when they upgrade to f13. David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question on SELinux AVC messages with systemd.
On Wed, Jul 21, 2010 at 02:30:03PM -0400, Dave Jones wrote: On Tue, Jul 20, 2010 at 04:26:14PM +0200, Lennart Poettering wrote: On Tue, 20.07.10 16:04, Lennart Poettering (mzerq...@0pointer.de) wrote: I am not entirely sure though why those processes actually access those dirs in this case. Maybe they are iterating through the files in /dev? Smells a bit broken to me. OK, the udevd is a result from /lib/udev/devices/ which is copied to /dev early on boot by udevd. Kay says that this dir reeally should not be put in /lib/udev/devices/. Still puzzled why LVM wants with /dev/mqueue though. Anybody from LVM around who can say something about this? lvm is brain damaged. strace lvm pvscan, and watch as it opens a bunch of stuff that there's no way there'd ever be a volume on. /dev/snd/*, tty's, usbmon etc etc looking closer, it seems to be only stat'ing, instead of opening most of them, which isn't quite so bad, but still pretty lame. of those that it does open(),.. Is there seriously a use-case for someone wanting lvm partitioned /dev/ram disks ? or /dev/loop ? I think we could probably use some extra filter definitions in /etc/lvm/lvm.conf Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question on SELinux AVC messages with systemd.
On Wed, 2010-07-21 at 14:30 -0400, Dave Jones wrote: On Tue, Jul 20, 2010 at 04:26:14PM +0200, Lennart Poettering wrote: On Tue, 20.07.10 16:04, Lennart Poettering (mzerq...@0pointer.de) wrote: I am not entirely sure though why those processes actually access those dirs in this case. Maybe they are iterating through the files in /dev? Smells a bit broken to me. OK, the udevd is a result from /lib/udev/devices/ which is copied to /dev early on boot by udevd. Kay says that this dir reeally should not be put in /lib/udev/devices/. Still puzzled why LVM wants with /dev/mqueue though. Anybody from LVM around who can say something about this? lvm is brain damaged. strace lvm pvscan, and watch as it opens a bunch of stuff that there's no way there'd ever be a volume on. /dev/snd/*, tty's, usbmon etc etc There is a config file that it reads, which indicates what kinds of devices to scan. I forwarded your mail to some LVM folks for input. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
Once upon a time, Jóhann B. Guðmundsson johan...@gmail.com said: Regular desktop end user wont notice any other change other than perhaps faster bootup and the people that call themselves power/advanced/admin users should have no problem to adapt and are urged from the start to Please remember that Fedora is not just about desktop end users, or even users at all in some cases. There are years of scripts, documentation, etc. that use chkconfig and service, and breaking them will be a PITA. For god sakes people alpha aint even out the door yet! Well, the last time I waited (or didn't notice) a big change until after it was released, I got the why didn't you say something while this was in development response. I just want to see changes in a backwards-compatible way whenever it is practical. I understand that that is not always the case, but I don't see anything here that indicates systemd and the long-standing chkconfig/service interfaces can't continue to work. IMHO the onus is on the systemd developers to make it backwards compatible where practical, as they are the group that (a) are advocating a major change and (b) know how systemd (and presumably the current init system) works. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, 21.07.10 09:51, Jeff Spaleta (jspal...@gmail.com) wrote: Heya, Is there a reasonable deadline to shoot for? Let me get past this weekend and I'll try to commit to doing so that I can be publicly shamed if I fail at doing it. Thanks a lot for looking into this. Much appreciated! Next week's is the feature freeze IIRC and also GUADEC. Which means I am not really going to be around. Which is why I want the systemd switch completed by the end of the week. I have prepped a patch with makes upstart parallel installable with systemd, so that people can rescue their systems with init=/sbin/upstart on the kernel command line, should systemd break it. This should give as a smoother transition. Casey OK'eyed that patch basically, but we were hoping for a second OK from Bill, but he is on vacation, so i guess we'll have to do without it. Due to that my plan is to release v4 tonight and upload Upstart and systemd in a way that systemd is default and upstart can be installed as alternative. For the chkconfig stuff the deadline is not as crucial I think. I think people running rawhide can deal with an imperfect chkconfig for now. Of course, this change should be completed before we release F14, and before admins get their fingers on this. Is there a todo list published that can be scanned by other interested parties for low hanging fruit? Kinda. I maintain this list in git: http://cgit.freedesktop.org/systemd/tree/fixme However, it is a mishmash of english and a bit of german and you probably need a bit of context to figure out what I mean by the items listed. That list is primarily for myself, but it might be interesting for other folks too which is why I commit it to git. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/21/2010 01:55 AM, Hans Ulrich Niedermann wrote:
On Tue, 2010-07-20 at 22:15 -0700, Jesse Keating wrote:
On 07/20/2010 08:55 PM, Garrett Holmstrom wrote:
On 7/20/2010 19:13, Hans Ulrich Niedermann wrote:
BTW, while typing the above, I have noted that master or devel or
f13 are quite easy to type, while F-13 with capital letter and
hyphen is relatively complicated. Perhaps that could be an argument when
choosing branch names.
Using names like f13, el5, and so forth would also keep dist-git
consistent with git branch naming conventions. If we were to do
something like that we might as well just use the value of %{dist}.
That was going to be my next question, although that would bring back
the c in fc13 and fc14 since that's what the dist value is. We could
bite the bullet and change the dist value to remove the c, and just
manually keep track of making sure that builds on older releases won't
be newer than builds on the newer branches. not sure if we want to go
through that pain at this point.
Don't we have a (few) mass rebuilds in front of us before F-14 anyway?
gold and similar stuff? That would increase the R of N-V-R anyway, so we
could switch %{dist} from fc14 to f14 at the same time for probably the
majority of packages.
The majority of packages aren't going to be rebuilt.
Oh. Darn. We still need to make sure that *.fc12 and *.fc13 packages do
not have the same N-V-R modulo %{dist} as F14 has, until F13 is EOLed,
i.e. until F15 comes out. That still sounds ugly. Well, all of that is
ugly regarding the c, whatever we do or do not do.
The other option is to make the dist translation change on the other
branches too, so that future f12 and f13 builds have a dist of .f12
and .f13
If rawhide development is supposed to happen on origin/master, then how
do branches for rawhide work? Does fedpkg just default to building for
rawhide when a branch doesn't appear in a release's branch namespace?
Yes. Branches of rawhide would be of the form origin/branch so if we
don't find one of our expected f(c)??,el?,olpc? we default to building
for rawhide.
I was not aware that rawhide would be basically origin/master. In that
case, it would be really obviously nice to be able to have branches
master, f13 and f12 (without any slashes) in the local repo and
have things just work for that case.
Perhaps fedpkg could support both simple clones where the developer's
local repo has just three branches tracking upstream
master - origin/master
f13- origin/f13/master
f12- origin/f12/master
or for people with more complex needs
master - origin/master
f13/master - origin/f13/master
f12/master - origin/f12/master
The problem is in inconsistency. Makes things harder for scripted
rebuilds which I'd expect to run on the f13/master branch. For the
local clone, I was going to have fedpkg call the branches by their base
name, so
master - origin/master
f13 - origin/f13/master
f12 - origin/f12/master
Which gives me an idea. What if we had
master - origin/master
f13- origin/f13
f12- origin/f12
F13/foo
F12/bar
and in addition to that, any local branch named like F13/* would be
built for f13? That would give direct 1:1 git repo cloning, with still
making it possible to deduce the target from branch names if so desired
by the packager.
hrm, I'm not really in favor of having both f13 and F13/foo, that
just seems like a recipe for lots of typo disasters.
We could even use fc13 and f13/foo to make the confusion complete
and nail down the c requirement for the next 20 years... :-)
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxHQOMACgkQ4v2HLvE71NWGqwCgoae3JCgIgCosQwQC+fVDGiTs
wK0AoL+bIW8hEdJP/jlsJefhyAgSVBiw
=NDAr
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/20/2010 11:22 PM, Roland McGrath wrote:
Using names like f13, el5, and so forth would also keep dist-git
consistent with git branch naming conventions. If we were to do
something like that we might as well just use the value of %{dist}.
But that's just too obviously right for us to be allowed to do it!
That was going to be my next question, although that would bring back
the c in fc13 and fc14 since that's what the dist value is. We could
bite the bullet and change the dist value to remove the c, and just
manually keep track of making sure that builds on older releases won't
be newer than builds on the newer branches. not sure if we want to go
through that pain at this point.
I'd say bite the bullet. Die, little c, die! It just looks silly there
nowadays, since the C-word has not been in our vocabulary for so long now.
What does manually mean, anyway? A database query and a short script?
Roll it into existing nag mail or update sanity-checking stuff? This seems
like a simple enough matter among all the things we're nowadays trying to
have some coherent checking for.
Well, we don't have autoqa live as of yet, live enough to prevent n-v-r
mishaps from going out to users. So it would take some maintainer
diligence. Honestly though if we were going to make a dist eval change
I'd want to make it across all the active branches and reduce the
potential for n-v-r mishaps.
Yes. Branches of rawhide would be of the form origin/branch so if we
don't find one of our expected f(c)??,el?,olpc? we default to building
for rawhide.
Where is the mapping of branch name patterns to koji build targets going to
live? Is it just in fedpkg locally and you'll change the norm only by
pushing a fedora-packager update in each release? (That doesn't sound very
likely. People use older Fedoras with older fedora-packager installed to
commit and trigger newer dist builds.) Or is it partly local and partly
gotten from the (koji?) server, or what? (In the CVS system this is the
common/branches file, which is both locally available in that it's a local
file in your common/ checkout, and centrally maintained in CVS.)
It'll live within fedpkg. It will basically make the assumption that if
you're on a branch, eg f13, it'll target
'dist-branch-updates-candidate'. And if you're not on a branch, it'll
target 'dist-rawhide'. We'll do koji magic to make sure 'dist-rawhide'
points things in the right direction, but the upshot is that nothing
needs to change on the developer's system each time we branch and start
up a new release.
Thanks,
Roland
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxHQf0ACgkQ4v2HLvE71NX1SQCeOjfx6i8t+eYflJ5NknDZySvQ
zAcAoK9SgJKtQ7n1jSYXEInv4qdWgolp
=xVdV
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, Jul 21, 2010 at 10:45 AM, Chris Adams cmad...@hiwaay.net wrote: I just want to see changes in a backwards-compatible way whenever it is practical. I understand that that is not always the case, but I don't see anything here that indicates systemd and the long-standing chkconfig/service interfaces can't continue to work. IMHO the onus is on the systemd developers to make it backwards compatible where practical, as they are the group that (a) are advocating a major change and (b) know how systemd (and presumably the current init system) works. The onus is on _us_ as participants to get changes well integrated in a timely manner. There's never been a mandate..nor will their every be a mandate for a Fedora feature to be 100% backwards compatible across releases as a showstopper for inclusion. To suggest otherwise is pure hyperbole. Systemd is going into rawhide early enough for those of us who care about script oriented backwards compatibility to sand down of the edges we care about regardless of the priorities of the main developer(s). As long as we are not bumping up against fundamental differences in opinion and they give us the freedom of action to make backwards compatibility with legacy tools possible. I think we are having this discussion early enough. But we need to figure out what those items that are high priority to us (but low in the upstream todo list) are and knock them out in parallel. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Outage: Updates - 2010-07-21 16:00 UTC
On Tue, Jul 20, 2010 at 04:47:38PM -0600, Stephen John Smoogen wrote: There will be an outage starting at 2010-07-21 16:00 UTC, which will last approximately 3 hours. Outages will be small but noticeable for small segments as systems are updated and rebooted. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2010-07-21 16:00 UTC' Reason for outage: Updates to xen and other critical packages require rebooting servers to take effect. Affected Services: CVS / Source Control I noticed cvs has come back up, but the webserver on cvs.fedoraproject.org hasn't, which means make upload is failing. Is it still in the outage window, or did something not come back up correctly? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Is import.log of any use?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Not sure if I've asked the wider audience here, but is the import.log file of any use to anybody? It's one more file that might differ between branches even when all else is the same, and I don't necessarily want to keep munging it with fedpkg when importing items. Would anybody cry if this file went away? - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxHUJsACgkQ4v2HLvE71NW6cACgr1C4fNyvlPYTd15118mA4DZ4 gdsAnA6U0UgwgGkezttpRlrhJEihHt4Z =IBTn -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 563935] Update perl-IPC-ShareLite to 0.10 or later
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=563935 --- Comment #6 from Fedora Update System upda...@fedoraproject.org 2010-07-21 16:02:37 EDT --- perl-IPC-ShareLite-0.13-4.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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 592672] Review Request: hct - A HDL complexity tool
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=592672 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|hct-0.7.60-2.fc12 |hct-0.7.60-2.el5 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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: Is import.log of any use?
Not sure if I've asked the wider audience here, but is the import.log file of any use to anybody? It's one more file that might differ between branches even when all else is the same, and I don't necessarily want to keep munging it with fedpkg when importing items. Would anybody cry if this file went away? Whatever information it carries can be put into formulaic git commit log messages generated by the cvs-import.sh replacement. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should GnuPG 1.4.x be revived?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/21/2010 11:32 AM, David Shaw wrote: On Jul 21, 2010, at 11:45 AM, Brian C. Lane wrote: I am not interested in co-maintaining gnupg-1. However I do not oppose to revive it in koji. Forgive my ignorance of the process, but how can I help this happen? Aside from my own problems with the change, there are other reports of people upgrading to F13 only to find their GnuPG setup nonfunctional when their gnupg transformed into gnupg2: http://lists.gnupg.org/pipermail/gnupg-users/2010-June/038817.html My understanding is that someone needs to update the gnupg package and run it through the package review process again since it was deprecated, not just orphaned. How does this happen (i.e. who is the someone)? I'm happy to help in any way I can, but I'm not currently a Fedora contributor. I'm just an upstream GnuPG guy. Probably me :) I've been debating reviving it. Having someone from upstream interested would certainly be helpful. Take a look at the http://fedoraproject.org/wiki/Join pages for info on how to join. gnupg2 needs to not obsolete gnupg in its .spec file And I would also prefer it if gnupg2 didn't overload the gnupg binaries, keeping things in line with upstream which meant for gnupg 1.x and 2.x to be installed in parallel. That brings up an additional problem in that now we have had users of f13 using gpg as gpg2, so a switch back might cause some friction -- but I think it is the right way to do things. I agree. It might cause friction, but of course the status quo is causing friction for some pre-f13 people using gpg when they upgrade to f13. Yup. I'm willing to pick up the gnupg package since there seems to be an interest, and folks to help out. Tonight I'll grab the f12 spec and patches and put together a new review for f13 and rawhide. I'm going to ask that the gpg binaries be handed back to gnupg if it is approved. If its worth doing, its worth doing right the 1st time :) - -- Brian C. Lane b...@redhat.com Red Hat / Port Orchard, WA -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBTEdcGRF+jBaO/jp/AQL5bAf/VnEre1PIDYWXSPNGkWx1YHY70n26W76k xAOYAoENzZy5w3lxp3zMAQvzDlzNRghMqI7LWRELM6Fm87GKy9Ccdhj4OPGg/lsx QUgBueAo9tJm9VOtIM+GOwXmYIcF3hAOSivtlq6USBsnVado55NTOo3iA15Kogpi VIKm/4nHOur/rH3kgOGulnwQIaA58Jp/IajnN4gWGxAx/h0FKATntAwwTMJRWOl/ DbzP5lm6Rf3tW8Z4GXsz1cl59EWkssqGONpT8Imr/11pCJUUf49KWAMtC8zCeVcM Jujg9xGPefTJ/rlQNxINLOK6c2KH0PxRwu7gBsVFL3eDsnI5py6jdg== =O5Qp -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Outage: Updates - 2010-07-21 16:00 UTC
On Wed, 21 Jul 2010, Dave Jones wrote: On Tue, Jul 20, 2010 at 04:47:38PM -0600, Stephen John Smoogen wrote: There will be an outage starting at 2010-07-21 16:00 UTC, which will last approximately 3 hours. Outages will be small but noticeable for small segments as systems are updated and rebooted. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2010-07-21 16:00 UTC' Reason for outage: Updates to xen and other critical packages require rebooting servers to take effect. Affected Services: CVS / Source Control I noticed cvs has come back up, but the webserver on cvs.fedoraproject.org hasn't, which means make upload is failing. Is it still in the outage window, or did something not come back up correctly? A little from column A) and a little from column B). Should be fixed now. -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, Jul 21, 2010 at 07:27:52PM +0200, Lennart Poettering wrote: It's called systemd-install, not install-systemd. systemd- is the common prefix for many of the systemd tools (though not all). How very discoverable. However, only some of those actions are install. So that's confusing and non-discoverable. It's also way too long, and if all of the systemd tools start with systemd, it's a pain for tab completion. Not a problem in scripts, but a hassle for administration. And in this case, where it's clearly a matter of taste and bike-shedding Like I said, I don't particularly care _what_ color it is -- although I have a strong preference for leaving it how it was. (chkconfig and service -- or if one tool can condense the functionality, fine). I probably shouldn't even have bothered to even reply to this mail of yours. Well, it's nice that you deign to participate. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, Jul 21, 2010 at 06:55:41PM -0400, Matthew Miller wrote: And in this case, where it's clearly a matter of taste and bike-shedding [...] I probably shouldn't even have bothered to even reply to this mail of yours. Well, it's nice that you deign to participate. Sorry for returning the snippy attitude. However, user-interface design is important, even when that user interface is the command-line. And it's arrongant and obnoxious to dismiss out-of-hand feedback from your end-user community as bike-shedding. There are legitmate concerns here, and if Fedora as a whole doesn't care about them, that sucks for Fedora. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, 21.07.10 13:29, Chris Adams (cmad...@hiwaay.net) wrote: Once upon a time, drago01 drag...@gmail.com said: And when I say/here admin I'd expect to be talking about a human (not some kind of robot that has hardwired commands and can't adapt to changes). If you only have to manage one system, good for you. I have to manage a bunch, and everything that is different _for_no_good_reason_ between them is a PITA. Yes, management scripts can be adapted, but now they have to handle systems A-Z one way, systems AA-ZZ another (but apparently not for all services, try to guess which?). That makes an admin unhappy and less likely to deploy any more of systems type AA-ZZ. BTW, you are emphasizing that that there was no reason for the stfuf we do. But you are wrong. There actually is. The reason why we came up with systemd-install as a counterpart of chkconfig instead of patching chkconfig is that it actually works very very differently from it. i.e. beyond the fact that both create symlinks, one in /etc/systemd/system, the other in /etc/rcN.d/ they have very little in common. One cares about priorities, the other doesn't. One knows only 6 runelvels, the other knows arbitrary numbers of targets. One can hook stuff into runlevels and runlevels only; the other can hook stuff into any unit. One can actually make the changes effetive immediately, the other doesn't do that; one can handle sockets and mounts and other kind of units, the other cannot; and so on and so on. Yes, they are counterparts in some way, but they nevertheless are very differnt in what they do. Which is why we chose not to hack the old tool to make the it half work on the new system, but came up with a new tool. Of course, there's a solution between transparently and different tool, which is to warn the user loudly and make suggestions what to do instead if he uses the old tool, and possibly even execute the suggestion right away if the semantics for that one call are close enough to what the user intended. And that's what I added to my todo list and Jef thankfully offered to implement. We are trying to find a way here between radical new designs, and staunch interface conservatism. i.e. we innovate and carefully try to select the stuff we want to keep around and leave out the stuff whose end has come. That naturally means that we do things on middle grounds, not on extremes. We won't do 100% compat with sysv, but we won't do 0% either. And that being the way it is I can only ask people to be a bit more conisderate in their positions. i.e. people whining on the mailing list that they will leave Fedora just because chkconfig might be not as 100% supported as they wish it was don't really help and don't see the big picture. Because the big picture will tell you that we keep incomparably more stuff in then we remove. For example, we provide compatibility with /dev/initctl, with sysv init scripts, with LSB init script headers, with chkconfig init script headers, with the various sysv client tools, with the kernel command line options, with the signals we take, with /etc/fstab and more. So, please, when Jef finishes his work, or I find the time to, we will provide chkconfig compat too (at least to a certain degree). However, doing this is actually just the cherry on top of the topping of our delicous cake. But even without the cherry it still would be very yummy and still have topping. Or in short: extremism sucks. Please acknoweledge that we try to find a middle ground, and that we are open for suggestions. Because we are. I already fixed a couple of issues that were discussed on this mailing list and added a couple more to my todo list. I won't make everybody happy, but you have a bigger chance to get your suggestion heard if you don't take extremist positions, declare sysv the holy grail and say you'll abandon Fedora if we depart from that. Yes, I guess being a developer who develops new stuff I like innovation in interfaces more than administrators who then might end up using this. But it doesn't really help claiming we had no idea what admins want and consistently ignore their wishes. Because we actually do have a pretty good idea. We don't fully share all opinions, but we are aware more often than not. Also, one last thing: there's so much in systemd that admins should really love. It would be great to sometimes look on the bright side of things. One small and random example, just to make a point: Look how awesome the output of systemctl status avahi-daemon.service is: snip avahi-daemon.service - Avahi mDNS/DNS-SD Stack Loaded: loaded (/lib/systemd/system/avahi-daemon.service) Active: active (running) Main: 6841 (avahi-daemon) Status: Server startup complete. Host name is lambda.local. Local service cookie is 813782141. CGroup: name=systemd:/systemd-1/avahi-daemon.service ├ 6841 avahi-daemon: running [lambda.local] └ 6842
Re: Question on SELinux AVC messages with systemd.
On Wed, 21.07.10 14:38, Dave Jones (da...@redhat.com) wrote: lvm is brain damaged. strace lvm pvscan, and watch as it opens a bunch of stuff that there's no way there'd ever be a volume on. /dev/snd/*, tty's, usbmon etc etc looking closer, it seems to be only stat'ing, instead of opening most of them, which isn't quite so bad, but still pretty lame. If it really iterates through /dev then it smeels very much broken. If people are interested in block devices /sys/class/block is a much better choice. And even if they really want to iterate through /dev they could at least rely on dirent-d_type to avoid the extra stats(). d_type works fine on devtmpfs (and the other fs choices crazy folks might use for /dev), so there's really little need to stat() arbitrary directories... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, Jul 21, 2010 at 03:13:12PM +0200, Lennart Poettering wrote:
On Tue, 20.07.10 20:24, Toshio Kuratomi (a.bad...@gmail.com) wrote:
On Wed, Jul 14, 2010 at 2:50 PM, Adam Williamson awill...@redhat.com
wrote:
On Wed, 2010-07-14 at 15:42 -0600, Kevin Fenzi wrote:
Perhaps someone could put together a wiki page for lazy sysadmins with
a QA? ie, I used to do this in upstart/sysvinit, how do I do it with
systemd?
Jóhann Guðmundsson (viking_ice) has been working on something along
these lines:
http://fedoraproject.org/wiki/User:Johannbg/QA/Systemd
it was mentioned in the QA meeting a few weeks back.
I have a few requests for things to add to that page :-)
* What replaces chkconfig
* What replaces /etc/init.d/SERVICENAME start | stop ?
Similarly, for packaging guidelines updates, how do we install
packages that provide services and have them not start up?
The longer answers for most of these questions you find in Jóhann's
reply. But a few additional notes:
- If you only install a SysV init script, then continue to use chkconfig
as usual. It works as intended to enable/disable SysV init
scripts. Only if you use native systemd unit files you should use
systemd-install instead. Note that most operations systemd-install
executes are very easy however, as all it does is creating/removing a
few suggested symlinks which are listed in a [Install] section in
the unit file. It is OK and even expected to manually create
additional symlinks, or remove symlinks, as the administrator likes.
- Regardless whether systemd or SysV init scripts/unit files are used,
systemctl start and systemctl stop are the recommended
replacements for service foo start and service foo stop. Howver,
as soon as https://bugzilla.redhat.com/show_bug.cgi?id=612728 is fixed
you can use the old syntax for SysV scripts too in which case the
right thing happens, but you'll get a blurb printed that suggests you
to use systemctl instead, the next time.
- If you want to enable and possibly start a service from the %post of
an RPM then use the systemd-install enable command, which will
create a few symlinks as listed in the [Install] section of the unit
file. On top of that you may also pass --realize=... to the command,
which allows you to not only enable the unit for the next boot, but
also have the changes take effect immediately: i.e. --realize=reload
is the very least you should use, which simply makes systemd aware of
the changed symlinks. Then, at time of %preun you should use
--realize=yes which makes sure the daemon is stopped in
deinstallation. For a few daemons it makes sense to restart them if
they are running already during upgrade. Use --realize=minimal for
those. For even others (usually very low-level ones) it might even
make sense to start them right-away after installation, even if they
were not running before. For those use --realize=maybe. But which
option you use really depends on the package. Most packages
should probably stick to --realize=yes on %preun and --realize=reload
in %post. Suggested .spec file fragments you find in the daemon(7) man
page.
Normally, we don't want a service to be started just because the package has
been installed:
https://fedoraproject.org/wiki/Packaging/SysVInitScript.
This is the current recommended scriptlets:
%post
# This adds the proper /etc/rc*.d links for the script
/sbin/chkconfig --add script
%preun
if [ $1 = 0 ] ; then
/sbin/service script stop /dev/null 21
/sbin/chkconfig --del script
fi
%postun
if [ $1 -ge 1 ] ; then
/sbin/service script condrestart /dev/null 21 || :
fi
I think I've got the %preun translated correctly but I'm not sure about
either the %post or %postun::
%post
# Don't need a %post as systemd automatically knows about the defaults?
%preun
if [ $1 = 0 ] ; then
/usr/bin/systemd-install disable %{unit name}.service --realize=disable
/dev/null 21 || :
fi
%postun
if [ $1 -ge 1 ] ; then
# Can't figure out how to do a conditional restart here. Help?
fi
-Toshio
pgpOvLKkLAdr2.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Thu, Jul 22, 2010 at 01:18:09AM +0200, Lennart Poettering wrote: BTW, you are emphasizing that that there was no reason for the stfuf we do. But you are wrong. There actually is. The reason why we came up with systemd-install as a counterpart of chkconfig instead of patching chkconfig is that it actually works very very differently from it. i.e. beyond the fact that both create symlinks, one in /etc/systemd/system, the other in /etc/rcN.d/ they have very little in common. One cares about priorities, the other doesn't. One knows only 6 runelvels, the other knows arbitrary numbers of targets. One can hook stuff into runlevels and runlevels only; the other can hook stuff into any unit. One can actually make the changes effetive immediately, the other doesn't do that; one can handle sockets and mounts and other kind of units, the other cannot; and so on and so on. It appears that you're looking at this from the point of view of chkconfig as a tool which causes certain manipuations of the system to happen (symlinks changed). That's the backwards approach. Look at it from the other side: it is a user-interface for changing under what conditions certain services run. Then extend that user interface to fit the new capabilities that you're adding. Yes, they are counterparts in some way, but they nevertheless are very differnt in what they do. Which is why we chose not to hack the old tool to make the it half work on the new system, but came up with a new tool. They're different in the particulars. They're the same in purpose. Of course, there's a solution between transparently and different tool, which is to warn the user loudly and make suggestions what to do instead if he uses the old tool, and possibly even execute the So, making an annoying warning here is really an option of last resort. If your goal is to antagonize and annoy your audience, it's a good approach, but I'm pretty sure that's not your intention. Think I'm kidding or exaggerating? Look at the horrible mess with the message from nslookup (I still hear people complain about that from time to time -- and still use nslookup!) more conisderate in their positions. i.e. people whining on the mailing list that they will leave Fedora just because chkconfig might be not as 100% supported as they wish it was don't really help and don't see the big picture. Because the big picture will tell you that we keep I didn't see anyone saying that they will leave Fedora. However, in my job, I see Fedora increasingly sidelined for any serious use -- and it's not just because of some other distro's mindshare. Fedora is important to me and I've been involved for a long time, and I dislike seeing this happen, so it's frustrating to have legitimate concerns rudely tossed aside as not seeing the big picture -- when, in fact, the big picture *is the problem*. Also, one last thing: there's so much in systemd that admins should really love. It would be great to sometimes look on the bright side of things. Sure. I don't love sysv init. It sucks in a whole multitude of ways. And I'm not really sold on upstart or any of the other replacements either. Systemd looks interesting, which is why I'm bothering to comment in the first place rather than just taking the make it stop! make it stop! line. One small and random example, just to make a point: Look how awesome the output of systemctl status avahi-daemon.service is: snip avahi-daemon.service - Avahi mDNS/DNS-SD Stack Loaded: loaded (/lib/systemd/system/avahi-daemon.service) Active: active (running) Main: 6841 (avahi-daemon) Status: Server startup complete. Host name is lambda.local. Local service cookie is 813782141. CGroup: name=systemd:/systemd-1/avahi-daemon.service ├ 6841 avahi-daemon: running [lambda.local] └ 6842 avahi-daemon: chroot helper /snip So, um. This is not so awesome, because for logged output, the multi-line format makes it hard to parse. And for human-readable output, it's got the opposite problem: it's more than 80 columns, and it's very verbose, burying the answer I want (is the thing running?) in the middle of the paragraph, while telling me many things I probably don't care about. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, Jul 21, 2010 at 07:15:29PM -0400, Matthew Miller wrote: There are legitmate concerns here, and if Fedora as a whole doesn't care about them, that sucks for Fedora. It has been brought to my intention that this statement is unfairly sweeping and broad. Which is encouraging, really, so let me rephrase: There are legitmate concerns here, and if Fedora as a whole *didn't* care about them, that *would* suck for Fedora. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Thu, 22 Jul 2010, Lennart Poettering wrote: On Wed, 21.07.10 13:29, Chris Adams (cmad...@hiwaay.net) wrote: Once upon a time, drago01 drag...@gmail.com said: And when I say/here admin I'd expect to be talking about a human (not some kind of robot that has hardwired commands and can't adapt to changes). If you only have to manage one system, good for you. I have to manage a bunch, and everything that is different _for_no_good_reason_ between them is a PITA. Yes, management scripts can be adapted, but now they have to handle systems A-Z one way, systems AA-ZZ another (but apparently not for all services, try to guess which?). That makes an admin unhappy and less likely to deploy any more of systems type AA-ZZ. BTW, you are emphasizing that that there was no reason for the stfuf we do. But you are wrong. There actually is. The reason why we came up with systemd-install as a counterpart of chkconfig instead of patching chkconfig is that it actually works very very differently from it. i.e. beyond the fact that both create symlinks, one in /etc/systemd/system, the other in /etc/rcN.d/ they have very little in common. One cares about priorities, the other doesn't. One knows only 6 runelvels, the other knows arbitrary numbers of targets. One can hook stuff into runlevels and runlevels only; the other can hook stuff into any unit. One can actually make the changes effetive immediately, the other doesn't do that; one can handle sockets and mounts and other kind of units, the other cannot; and so on and so on. I think the bigger question is why are we doing this? It really does sound like some developers got together and said You know what people need? This thing. They need this thing! Who has been requesting this? What requirements did they give? The problem people seem to be having is the reasons you give in the above paragraph are reasons you yourself invented, and that's a backwards way to do development :-/ Or in short: extremism sucks. Please acknoweledge that we try to find a middle ground, and that we are open for suggestions. Because we are. I already fixed a couple of issues that were discussed on this mailing list and added a couple more to my todo list. I won't make everybody happy, but you have a bigger chance to get your suggestion heard if you don't take extremist positions, declare sysv the holy grail and say you'll abandon Fedora if we depart from that. As mentioned above, it seems like you're trying to find a middle ground between where we are today, and this whole other place you guys invented for seemingly no reason then you felt like coding something. Yes, I guess being a developer who develops new stuff I like innovation in interfaces more than administrators who then might end up using this. But it doesn't really help claiming we had no idea what admins want and consistently ignore their wishes. Because we actually do have a pretty good idea. We don't fully share all opinions, but we are aware more often than not. Any fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Einstein. I'm not calling you a fool, you're clearly not but that quote seems appropriate. Just be extra careful when it's others (sysadmins) that have to live with the consequences of your (developer) decisions. -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, Jul 21, 2010 at 8:39 PM, Mike McGrath mmcgr...@redhat.com wrote: I think the bigger question is why are we doing this? There's some motivation here: http://0pointer.de/blog/projects/systemd.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora packaging: unison?
On Wed, Jul 21, 2010 at 9:23 AM, Jonathan Underwood jonathan.underw...@gmail.com wrote: On 21 July 2010 12:12, Adam Williamson awill...@redhat.com wrote: Thanks, but afaics that thread doesn't really answer any of my questions, it's just a bunch of yum technicalities about how the implementation of having two packages actually works. What I'm interested in is what was the original reason for having two branches packaged, and do we still need to do it (or even have 3). In broad terms, later unison versions are not wire compatible with earlier ones. i.e. unison developers regularly break wire compatibility. Since people have a need to synchronize with machines running different unison versions, multiple unison versions are needed to be packaged, alas. Or... you could strong arm those other distros to package the version we package. Here a question... right now... how many compatibility packages are we talking about to get ideal unison version coverage for all possible scenarios for released version across the enormity of pre-packaged distributions? How often does upstream break wire compatibility? 2? 5? 10? 3 billion? And seriously what is stopping those other distributions from providing a newer unison? Don't they have backport repositories or other such to account for this sort of upstream brain damage? Why do we have to carry around old stuff that upstream doesnt support any more just because other distro do? Can't they get the newer one and be compatible with us? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, 21.07.10 20:08, Toshio Kuratomi (a.bad...@gmail.com) wrote:
- If you want to enable and possibly start a service from the %post of
an RPM then use the systemd-install enable command, which will
create a few symlinks as listed in the [Install] section of the unit
file. On top of that you may also pass --realize=... to the command,
which allows you to not only enable the unit for the next boot, but
also have the changes take effect immediately: i.e. --realize=reload
is the very least you should use, which simply makes systemd aware of
the changed symlinks. Then, at time of %preun you should use
--realize=yes which makes sure the daemon is stopped in
deinstallation. For a few daemons it makes sense to restart them if
they are running already during upgrade. Use --realize=minimal for
those. For even others (usually very low-level ones) it might even
make sense to start them right-away after installation, even if they
were not running before. For those use --realize=maybe. But which
option you use really depends on the package. Most packages
should probably stick to --realize=yes on %preun and --realize=reload
in %post. Suggested .spec file fragments you find in the daemon(7) man
page.
Normally, we don't want a service to be started just because the package has
been installed:
Yepp, which is why I said very low-level ones, i.e. as low-level as
for example udev, which you really want to be running.
https://fedoraproject.org/wiki/Packaging/SysVInitScript.
This is the current recommended scriptlets:
%post
# This adds the proper /etc/rc*.d links for the script
/sbin/chkconfig --add script
%preun
if [ $1 = 0 ] ; then
/sbin/service script stop /dev/null 21
/sbin/chkconfig --del script
fi
%postun
if [ $1 -ge 1 ] ; then
/sbin/service script condrestart /dev/null 21 || :
fi
I think I've got the %preun translated correctly but I'm not sure about
either the %post or %postun::
%post
# Don't need a %post as systemd automatically knows about the defaults?
It is needed:
if [ $1 -eq 1 ] ; then
# For new installations, hook unit file into the appropriate places via
symlinks
/usr/bin/systemd-install enable --realize=reload %{unit name}.service
/dev/null 21 || :
else
# For old installations, just reload the configuration, don't change
symlinks
/bin/bin/systemd-install realize --realize=reload %{unit name}.service
/dev/null 21 || :
fi
%preun
if [ $1 = 0 ] ; then
/usr/bin/systemd-install disable %{unit name}.service --realize=disable
/dev/null 21 || :
fi
Almost:
if [ $1 -eq 0 ] ; then
/usr/bin/systemd-install disable --realize=yes %{unit name}.service
/dev/null 21 || :
fi
%postun
if [ $1 -ge 1 ] ; then
# Can't figure out how to do a conditional restart here. Help?
fi
If you want to restart the service on upgrade I'd do that in %post. It
should be sufficient to replace --realize=reload by --realize=minimal
which will restart the unit if it is running, and only then.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, 21 Jul 2010, Colin Walters wrote: On Wed, Jul 21, 2010 at 8:39 PM, Mike McGrath mmcgr...@redhat.com wrote: I think the bigger question is why are we doing this? There's some motivation here: http://0pointer.de/blog/projects/systemd.html I was pretty clear in everything you cut off about the whole You know what people need, they need this and the whole developers making things for sysadmins because they think sysadmins need it thing. 0pointer.de is Lennart's post. If this is only being developed and driven by the same people perhaps we should just step back, get it functioning for a while, _then_ lets talk about replacements. If you guys feel that strongly about it, you'll still feel that way a year from now when the whole system is developed and working right? Perhaps then it can go into Fedora? This should probably say systemd for F16 -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, 21.07.10 20:13, Matthew Miller (mat...@mattdm.org) wrote: It appears that you're looking at this from the point of view of chkconfig as a tool which causes certain manipuations of the system to happen (symlinks changed). That's the backwards approach. Look at it from the other side: it is a user-interface for changing under what conditions certain services run. Then extend that user interface to fit the new capabilities that you're adding. Well, the chkconfig tool is actually a tool which is way more than a dumbed-down access utility to the /etc/rcX.d/ symlink farms. What its implementation actually does is defined very much in detail and for example documented in the man page, to the last bit. In other words: it is *NOT* an implementation detail what exactly it does to enable/disable a service. In fact the interface to chkconfig is defined on a multitude of levels, not only the mere command line arguments. For example we have chkconfig headers in all init scritps which are part of the api of chkconfig. This is for example very different from let's say the sysv /sbin/reboot command whose semantics are pretty well known and trivial to understand. It is easy to reimplement that command on top of a different system. But chkconfig? Not so much if you have neither rcN.d links, priorities, nor S or K links -- nor even init scripts at all. The logic behind chkconfig is exposed in many ways in the user interface, for example in the chkconfig command line, e.g. commands such as resetpriorities, and stuff like that. One small and random example, just to make a point: Look how awesome the output of systemctl status avahi-daemon.service is: snip avahi-daemon.service - Avahi mDNS/DNS-SD Stack Loaded: loaded (/lib/systemd/system/avahi-daemon.service) Active: active (running) Main: 6841 (avahi-daemon) Status: Server startup complete. Host name is lambda.local. Local service cookie is 813782141. CGroup: name=systemd:/systemd-1/avahi-daemon.service ├ 6841 avahi-daemon: running [lambda.local] └ 6842 avahi-daemon: chroot helper /snip So, um. This is not so awesome, because for logged output, the multi-line format makes it hard to parse. And for human-readable output, it's got the opposite problem: it's more than 80 columns, and it's very verbose, burying the answer I want (is the thing running?) in the middle of the paragraph, while telling me many things I probably don't care about. Jeez. I guess you cannot be helped. I guess it doesn't help in any way here to mention that we were two steps ahead of you here and provide systemctl show which can be used to introspect systemd units in all details and properties in a parsable way. Also, we added systemctl check which prints a one line super-short status. But anyway, I give up. If you keep looking long enough you'll find something you don't like in everything. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, Jul 21, 2010 at 19:30, Lennart Poettering mzerq...@0pointer.de wrote:
On Wed, 21.07.10 20:08, Toshio Kuratomi (a.bad...@gmail.com) wrote:
It is needed:
if [ $1 -eq 1 ] ; then
# For new installations, hook unit file into the appropriate places
via symlinks
/usr/bin/systemd-install enable --realize=reload %{unit name}.service
/dev/null 21 || :
else
# For old installations, just reload the configuration, don't change
symlinks
/bin/bin/systemd-install realize --realize=reload %{unit name}.service
/dev/null 21 || :
fi
Ok from dealing with many years of technical support it has been
hammered into me that if you are replacing a command, make sure the
replacement makes more sense than the thing it 'replaces' (in this
case chkconfig which people seem to intuit means check configuration).
Putting my head into a customers head the first thing before the
complicated syntax is why am I running something called install to
change a service?
I will forego the bikeshedding and say it should be sysconfig or
syssetup but I do believe it will cause a lot of complaints.
--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
We have a strategic plan. It's called doing things.
— Herb Kelleher, founder Southwest Airlines
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Wed, Jul 21, 2010 at 19:49, Lennart Poettering mzerq...@0pointer.de wrote: On Wed, 21.07.10 20:13, Matthew Miller (mat...@mattdm.org) wrote: But anyway, I give up. If you keep looking long enough you'll find something you don't like in everything. If this is how you normally deal with problems, I am beginning to understand why pulseaudio has had such a bad reputation. A) You read everything that matt said as a personal attack of trying to find deep fault and then you go off in a temper tantrum. None of that is going to make things easier and pretty much sets this whole project up as a big FAIL because the people who have to buy into it as it affects them the most are now all lumped in as whiners. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Stephen J Smoogen. “The core skill of innovators is error recovery, not failure avoidance.” Randy Nelson, President of Pixar University. We have a strategic plan. It's called doing things. — Herb Kelleher, founder Southwest Airlines -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
It is needed:
if [ $1 -eq 1 ] ; then
# For new installations, hook unit file into the appropriate places
via symlinks
/usr/bin/systemd-install enable --realize=reload %{unit name}.service
/dev/null 21 || :
else
# For old installations, just reload the configuration, don't change
symlinks
/bin/bin/systemd-install realize --realize=reload %{unit
name}.service /dev/null 21 || :
fi
Wow thats pretty special... both an option called realize and a
argument, that won't get confusing no matter how long it lives, also
realize doesn't seem to be conveying a useful meaning, I'm a native
speaker and I'm not sure what you actually mean by realize in this
context.
I'm going with:
to make real; give reality to (a hope, fear, plan, etc.).
but its seems quite an abstract term to associate reality with an
abstract computer object.
Dave.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
On Thu, Jul 22, 2010 at 03:49:21AM +0200, Lennart Poettering wrote: The logic behind chkconfig is exposed in many ways in the user interface, for example in the chkconfig command line, e.g. commands such as resetpriorities, and stuff like that. I think having some level of command-line user-interface compatiblity, even if not 100%, is important. resetpriorities is probably so rarely used that the systemd version of chkconfig could probably just make it a no-op (unless it was dealing with old sysvinit scripts, in which case it could probably just call through to the old chkconfig). But for basics such as chkconfig service on|off|--list, there should be compatibility. Runlevels could perhaps be dealt with by mapping the common cases like 3,5 to the multiuser-target, graphical-target, etc. Likewise for service foo start|stop|reload|condrestart etc. Jeez. I guess you cannot be helped. I guess it doesn't help in any way here to mention that we were two steps ahead of you here and provide systemctl show which can be used to introspect systemd units in all details and properties in a parsable way. Also, we added systemctl check which prints a one line super-short status. Well, there is some merit in the already stated argument for having good UI design. In this example, you could have used long-standing precedent of using -v -vv -vvv (or -q -qq -qqq, or --verbose=N) arguments instead of status show check. Now you've created new lore of needing to know when to use status vs. show vs. check, what the differences are between them, and what their order of increasing verbosity is. But anyway, I give up. If you keep looking long enough you'll find something you don't like in everything. Please don't give up. I think most of this is valid criticism that should be voiced, but that doesn't imply that the overall architecture and implementation of systemd isn't great. I like most of what I see, but I do cringe at some of the command, argument, and option naming choices that were made. And I think it is asking too much for users to have to know to use systemd-install for some things and chkconfig/service for others, not to mention needing to update all the RPM spec files for new scriptlets, or fixing anaconda to know when to call which (I'm guessing that anaconda might call chkconfig or service, but don't know for sure. Are you sure you know where all the skeletons are hiding?) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
