Re: Globally-visible executables with parallel python 2 and python 3 stacks
On Fri, Jan 15, 2010 at 4:45 PM, David Malcolm wrote: > > = Support files for the Python language = > /usr/bin/g-ir-scanner I don't see any intrinsic value in having both versions of g-ir-scanner available; this one should be in the other category, it's just a program which happens to be implemented in Python. (Now, if in the future we have an extension system for it as has been considered, things get dramatically more complicated, but that's not likely soon) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
add dbus to base comps group
Hi, We'd like to remove the dependency of the dbus-libs package on dbus (which will run even if the app doesn't need the daemon). As part of this though we need to ensure the bus is available if you've done a default workstation (desktop needs it) or server (want admin tools etc. to use) install. In practice, since NetworkManager is in base, dbus gets pulled in, but we should make this explicit. Index: comps-f13.xml.in === RCS file: /cvs/pkgs/comps/comps-f13.xml.in,v retrieving revision 1.144 diff -u -r1.144 comps-f13.xml.in --- comps-f13.xml.in 20 Jan 2010 19:50:23 - 1.144 +++ comps-f13.xml.in 21 Jan 2010 21:33:33 - @@ -219,6 +219,7 @@ lsof mailcap man + dbus NetworkManager ntsysv parted -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Purging the F13 orphans
On Thu, Jan 28, 2010 at 3:24 PM, Toshio Kuratomi wrote: > On Thu, Jan 28, 2010 at 09:01:25AM +0200, Alexander Kurtakov wrote: >> How can I take jna-posix? I need it for one of my projects but I don't see a >> way to take it in pkgdb. I'm speaking for the devel branch because it is >> possible to take F-12 branch. >> > jna-posix has been retired rather than simply orphaned. Walters, was there > a reason for that or is it simply that the package has sat around for long > enough that it needs a re-review? To be honest it's been long enough I don't recall; is there no way to find out why a package was retired? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Draft privilege escalation policy for comments
Hi Adam, On Fri, Jan 29, 2010 at 5:27 PM, Adam Williamson wrote: > Hi, everyone. Since the big PackageKit brouhaha surrounding Fedora 12, > there's been a discussion surrounding the need for a policy about > privilege escalation in Fedora. Representing the QA group, we would like > for there to be such a policy in order to allow a meaningful review of > privilege escalation issues as part of QA's testing of Fedora releases. Agree it makes sense for there to be a policy, thanks for looking at this! > Please do provide any and all feedback on the proposed policy. if we can > get it into a shape which most people on the list would find acceptable, > my next step will be to take it back to FESco for them to review. > Thanks. So a general theme that seems to run through the policy of "don't affect other users", and some things have exceptions (shutdown and reboot), but others don't (change the system time, adding new software). Is there a rationale for that? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Draft privilege escalation policy for comments
On Sat, Jan 30, 2010 at 1:20 AM, Adam Williamson wrote: > > Well, reboot is a one-time operation; if there's only one user logged > in, they can only affect themselves by rebooting. Adjusting the clock or > installing new software isn't the same. Ok, actually "one time" feels like there's a more general principle at work here, which is the degree to which the operation could potentially affect other users. For example, there's a pretty wide gulf between "install new desktop app" (other users see a new menu entry) and "start or stop system daemons" (can easily break printing, networking, or just crash the. Changing the system time is in between there. The reason I mention this specifically I'd like in the future to widen this set a little bit for the "self managed" desktop target (i.e. livecd download), specifically include at least "install new desktop application from " and "initiate system update" in that set of default privileges. Maybe the way to think of system update is that the system comes by default configured to update, and the privilege is actually to optionally delay the update. I think it's very important that we make typing in the root password dialog a meaningful event, something that means "you are doing something really unusual, are you sure?", like turning off SELinux. If we require it for simply installing Firefox security updates it greatly dilutes the warning/danger value of it. So as long as we don't view this current list as written on stone tablets but a flexible system (more in the sense of guidelines/examples), subject to revision, I'm fine with it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
assigning of abrt crashes
Hi, I'd like to propose a general rule that ABRT crash logs should remain "assigned" to the actual application, unless an actual investigation has been done and there's a "reasonable" certainty the flaw is in the library code in which it happened to crash. Rationale: Applications are more likely to be buggy (I'm just asserting this, but it seems obvious), and just because a crash happened inside the library, particularly when C/C++ is involved, means nothing; the flaw could still be in the application. If we reassign them, it's harder to make all crashes for an application visible. I'm fine with being added to a CC list, but reassigning is more of a mess. Sample crash: https://bugzilla.redhat.com/show_bug.cgi?id=624098 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: assigning of abrt crashes
On Tue, Aug 17, 2010 at 6:06 AM, Thomas Spura wrote: > On Mon, 16 Aug 2010 11:01:36 -0400 > Colin Walters wrote: > >> Hi, >> >> I'd like to propose a general rule that ABRT crash logs should remain >> "assigned" to the actual application, unless an actual investigation >> has been done and there's a "reasonable" certainty the flaw is in the >> library code in which it happened to crash. > > Who should do that investigation, when the maintainer of the actual > application is unable to do so? A bug tracker with > FE-NEEDSHELPWITHBACKTRACE would help here. Maybe FES [1] would like to > help here in that case. Try the upstream author first? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: assigning of abrt crashes
On Tue, Aug 17, 2010 at 11:12 AM, Thomas Spura wrote: > > Without a clear way "how to reproduce" it, they can't help here One advantage of automated collection (or semi-automated like ABRT) is that given enough crashes, it can be easier to track down the root cause. So it's useful to have the report logged, even if we can't take immediate action on it. > So some upstream author would help, but what in the cases, they > don't/can't? Then keep it around until it becomes useful. > Ignoring the bugs till the release is EOL is not really an option... So for the reasons above there's no problem with leaving the report in the system. Remember also that a certain percentage of crashes are going to happen simply due to bad hardware. We have to accept noise in the system. Crashes aren't bugs; they're crashes that may be bugs. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
clutter -> 1.3
Heads up to Clutter consumers - I'm updating it in f15 to the 1.3 (master) branch. I've tested GNOME Shell and quadrapassel, feel free to CC me for other fallout. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: clutter -> 1.3
On Tue, Aug 31, 2010 at 2:57 PM, pbrobin...@gmail.com wrote: > On Tue, Aug 31, 2010 at 7:52 PM, Colin Walters wrote: >> Heads up to Clutter consumers - I'm updating it in f15 to the 1.3 >> (master) branch. I've tested GNOME Shell and quadrapassel, feel free >> to CC me for other fallout. > > This will break meego. Okay, is there a schedule for meego supporting 1.3? That would give guidance about creating a temporary clutter-1.2 package or not. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum appmarket
On Sun, Aug 29, 2010 at 2:15 PM, seth vidal wrote: > > Florian has already been working that out. He's got a pure-python script > that grabs up the icons and we'll work on implementing them at the pkgdb > layer. Hmm, you're saying the client code would talk to pkgdb? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gobject-introspection 0.9.5 rebuilds coming to rawhide
Just a quick heads up that I'm going to be updating introspection to (at least) 0.9.5 in rawhide. For libraries, this is generally a simple rebuild with no impact on primary functionality. However if you are a library maintainer, do see http://mail.gnome.org/archives/gnome-announce-list/2010-September/msg00019.html And particularly please try the new --warn-all flag. For apps: Many more functions require annotations, as the scanner does less (incorrect) guessing. We are working on adding annotations for the GNOME 3 (F15ish cycle). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Thu, Sep 16, 2010 at 11:57 AM, Richard Hughes wrote: n framework. Yum is a _package_ manager. > Applications like gnome-shell and kpackagekit want to search for new > applications using translated per-application strings and show icons > for desktop files. gnome-shell shouldn't care what a 'package' is. > That's an uninteresting technical detail. Personally I'd much prefer some nice asynchronous GObject API somewhere for this, rather than parsing SQLite directly. PackageKit seems like as good a place as any for this. The other argument for this is that we *will* need to know some details. For example, to implement "remove" or "when was this installed" type things, knowing the mapping to packages is necessary. Actually to implement reliable upgrades we'll need linkage between the two as well. (I don't have a strong opinion on whether the data format is RPM or repodata myself; maybe just a slight preference for the latter; the most important thing in my mind is to come to rough consensus and working code, and actually ship something) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Fri, Sep 17, 2010 at 11:08 AM, Richard Hughes wrote: > On 17 September 2010 15:28, Bill Nottingham wrote: >> Not if it's provided in the RPM header in a way where it can be easily >> stuffed into the metadata or a similar place. > > Bear in mind: 'n' applications per package, where 'n' can be a large > number. This means you have to come up with an interesting way to > encode binary data in a application prefixed rpm-provide. Icky. We should simply add a rule of at most one app per package. Yes, this means you, gnome-games. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: policycoreutils needs cairo.
On Mon, Oct 25, 2010 at 3:33 PM, Dave Jones wrote: > I did a minimal install yesterday, and was surprised to find that > cairo, and a bunch of X libs were still installed. > > The dependancy chain that pulled them in looks like this.. > > policycoreutils -> dbus-glib -> gobject-introspection -> fontconfig -> cairo This is fixed in F15 in multiple ways (restorecond is split out of policycoreutils, and dbus-glib no longer deps on gobject-introspection, and g-i no longer depends on cairo) > Could any part of that chain have its dependancies relaxed ? Unfortunately we didn't notice this dependency until pretty late in F14...I'm not sure what can be done reasonably at this point, since all of these packages are critical path. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: policycoreutils needs cairo.
On Mon, Oct 25, 2010 at 5:21 PM, Colin Walters wrote:
>
> Unfortunately we didn't notice this dependency until pretty late in
> F14...I'm not sure what can be done reasonably at this point, since
> all of these packages are critical path.
Though I will say that if this was determined to be a blocker, here's
a really safe minimal fix:
From ebec17c813c860964af9e1d313c3ec97171aeacb Mon Sep 17 00:00:00 2001
From: Colin Walters
Date: Mon, 25 Oct 2010 17:45:05 -0400
Subject: [PATCH] - Move test libraries into -devel; they pull in a cairo dependency,
which is unnecessary.
---
gobject-introspection.spec | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/gobject-introspection.spec b/gobject-introspection.spec
index 2ec89d5..8e59067 100644
--- a/gobject-introspection.spec
+++ b/gobject-introspection.spec
@@ -3,7 +3,7 @@
Name: gobject-introspection
Version:0.9.3
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary:Introspection system for GObject-based libraries
Group: Development/Libraries
@@ -73,13 +73,15 @@ find $RPM_BUILD_ROOT -type f -name "*.a" -exec rm -f {} ';'
%defattr(-,root,root,-)
%doc COPYING
-%{_libdir}/lib*.so.*
+%{_libdir}/libgirepository-1.0.so.*
%dir %{_libdir}/girepository-1.0
%{_libdir}/girepository-1.0/*.typelib
%files devel
%defattr(-,root,root)
%{_libdir}/lib*.so
+%{_libdir}/libgirepository-everything-1.0.so.*
+%{_libdir}/libgirepository-gimarshallingtests-1.0.so.*
%dir %{_libdir}/gobject-introspection
%{_libdir}/gobject-introspection/*
%{_libdir}/pkgconfig/*
@@ -94,6 +96,10 @@ find $RPM_BUILD_ROOT -type f -name "*.a" -exec rm -f {} ';'
#%{_datadir}/gtk-doc/html/gi/*
%changelog
+* Mon Oct 25 2010 Colin Walters - 0.9.3-2
+- Move test libraries into -devel; they pull in a cairo dependency,
+ which is unnecessary.
+
* Tue Aug 3 2010 Matthias Clasen - 0.9.3-1
- Update to 0.9.3
--
1.7.3.1
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gnome 3 menus and the freedesktop standard
Hi, Feel free to propose a bug on gnome-menus at http://bugzilla.gnome.org On Mon, Aug 8, 2011 at 4:43 AM, Muayyad AlSadi wrote: > where should I put my .menu file to create a new menu under applications ? You're probably right about the specification from looking at it quickly. > and does the patch below have any thing to do with this issue Yes, it triggered this latent bug in gnome-menus I suppose. But we're not able to revert it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[PATCH] macros: Globally add --disable-silent-rules to configure
See attached.
From d24d382c325c8794c05bcb56b3820b15e4a67e55 Mon Sep 17 00:00:00 2001
From: Colin Walters
Date: Tue, 9 Aug 2011 10:42:06 -0400
Subject: [PATCH] macros: Globally add --disable-silent-rules to configure
Various projects have been adding AM_SILENT_RULES from Automake to
their Makefiles for "developer convenience"; the goal being that they
see warnings more easily.
Now really the right way to do this is to have a make wrapper (or an IDE)
that knows how to filter out warnings, but let's leave that aside for now.
But for debugging builds, we really need the full log data. Being
able to see exactly how e.g. libtool is being run helps a lot for
debugging link problems as an example.
---
macros |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/macros b/macros
index d7bf415..237e1f4 100644
--- a/macros
+++ b/macros
@@ -35,6 +35,7 @@
%{_configure} --build=%{_build} --host=%{_host} \\\
--program-prefix=%{?_program_prefix} \\\
--disable-dependency-tracking \\\
+ --disable-silent-rules \\\
--prefix=%{_prefix} \\\
--exec-prefix=%{_exec_prefix} \\\
--bindir=%{_bindir} \\\
--
1.7.6
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On Tue, Aug 9, 2011 at 11:11 AM, Tom Lane wrote: > > What happens in packages using a (possibly old) autoconf script that > doesn't recognize --disable-silent-rules? Autoconf convention is to ignore unknown rules. And indeed, all that results is a warning: configure: WARNING: unrecognized options: --disable-silent-rules > IMO it would be better to add this option to the %configure calls > in packages where it's actually an issue (which is surely a small > minority, unless Colin has got evidence to the contrary). I actually did this in the GNOME build system originally (pattern match for bits in configure), but after some discussion on the Yocto list we decided there the warning was harmless. https://lists.yoctoproject.org/pipermail/poky/2011-March/004944.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
Hi Jan, On Tue, Aug 9, 2011 at 12:56 PM, Jan Kratochvil wrote: > On Tue, 09 Aug 2011 16:44:31 +0200, Colin Walters wrote: >> the goal being that they see warnings more easily. > > You should make -Werror default instead, by compiling packages without -Werror > various bugs creep in which would be much easier fixed before the compilation. I've gone back and forth on this over the years - what I ultimately concluded is that what one really wants in general is a system for tracking warning *regressions*. That's obviously harder, but I've been thinking about how to do it in our GNOME builds. Anyways - seems like there was rough consensus for the original patch so I've committed it, pushed and started a build for rawhide. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On Thu, Aug 11, 2011 at 5:56 AM, Milan Crha wrote: > > I would like you to give me an option to not use --disable-silent-rules, > because it breaks waf build. Ugh; pretty lame that waf chose to replicate all of the standard autoconf flags as well as some automake ones (--disable-dependency-tracking), but NOT replicate the behavior of ignoring unknown options. I'll work on a patch - I guess the RPM approach is more overrides rather than detecting things, so I'll go with adding an option. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On Thu, Aug 11, 2011 at 9:43 AM, Colin Walters wrote: > > I'll work on a patch - I guess the RPM approach is more overrides > rather than detecting things, so I'll go with adding an option. Actually looking at this more, while waf does support the GNU autoconf options by loading gnu_dirs.py (and Samba does this), it actually doesn't support --disable-dependency-tracking. That bit lives in buildtools/wafsamba/wscript. So I think it makes sense to patch samba's wscript to also support --disable-silent-rules for now. It may make sense to also have an automake_compat.py in upstream waf which does something with the configure options shipped with Automake (which are currently dependency-tracking, maintainer-mode, multilib, and silent-rules)...and while we're in here an option to ignore unknown options =) I filed http://code.google.com/p/waf/issues/detail?id=1023 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: manually fixing IPs
On Sat, Mar 26, 2011 at 5:59 PM, Jon Masters wrote: > On Sat, 2011-03-26 at 11:03 -0400, Neil Horman wrote: > >> IIRC you can set: >> NM_CONTROLLED="no" >> in /etc/sysconfig/network-scripts/ifcfg-ethX >> Supposedly that will take ethX off the reservation and allow you to use the >> ifup >> script and ifconfig utility as you traditionally would. > > I remain unconvinced that in rawhide it's possibly to truly instruct all > these wonderful bells and whistles to leave an interface alone. So you're not even going to try what he suggests? Why? Easier to just keep posting to fedora-devel-list? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome Shell Extension manager/framework planned?
Hi, On Fri, Jun 3, 2011 at 11:28 AM, Michael Wiktowy wrote: > > Is there some sort of extension management planned that would handle > the separate enabling/disabling/configuration of individual extensions > via the grand unified Settings menu? In 3.2 we will support whitelisting in addition to the current blacklisting: https://bugzilla.gnome.org/show_bug.cgi?id=651088 > If this is under way, could extension makers be pointed towards it to > future-proof their extensions. I'm not sure what you mean by this. As far as some sort of better UI in a Fedora context - my two cents is that yum is a power user tool, and works fine for this. However there is an intern at Red Hat looking at this in a GNOME context, I've CC'd him in case he wants to comment. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Fri, Jun 10, 2011 at 9:07 AM, Denys Vlasenko wrote: > > It's the *fourth* largest process on my system! > > > # ldd `which systemd` 1) Looking at what libraries a binary links to a is a terrible way to optimize memory usage; try massif, say 2) It'd be a lot more productive to be positive and not phrase your message in such an antagonistic way (in fact, this message would probably be better on the systemd-devel mailing list) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what key between Ctrl & Alt (was: GNOME3 and au revoir...)
On Fri, Jun 17, 2011 at 9:05 AM, Felix Miata wrote: > On 2011/06/17 08:53 (GMT-0300) Domingo Becker composed: > >> The shortest way is by using keyboard, as Rahul says: > >> 1. Press the key between Ctrl and Alt. > > What key between Ctrl & Alt? You can also use Alt-F1. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
VCS key in spec files and some scripts
Dear Fedora Developers, So recently I found myself desiring to update a .spec file for a snapshot of a git tree in an automated fashion. As you may or may not know, this actually has a surprising number of flaming hoops through which you must jump. The first one, when scripting such a thing, is pulling the source tree and packing it into a source file. To this purpose, I propose we begin adding the following key to .spec files: #VCS: Note the use of a comment. There's a ticket to support this key more explicitly in RPM: http://rpm.org/attachment/ticket/143 However I didn't want to block my scripts on that patch landing; in any case we currently add human-consumable comments (https://fedoraproject.org/wiki/Packaging:SourceURL) for VCS snapshots now, so think of this key as just more of that. Having the version control system in the spec file will help a lot for other things like automating source tarball verification. The second hoop is correctly handling the Release tag. https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Version has lots of gory details. But basically, this can be automated. Another hoop is the autotools; you have a variety of choices here, but it's most common to add BuildRequires on them, and figure out how to bootstrap. This latter part requires a bit of build intelligence (my scripts recognize the case of autotools, and the more specific case of gnome-autogen.sh). I'd actually like to break out the build recognition system into a separate python library of some sort. So without further ado, my current scripts: http://fedorapeople.org/gitweb?p=walters/public_git/fedpkg-make-pull.git;a=summary I'd actually like to get these into Jesse's new fedpkg work, but for now these operate on distcvs. Executive summary: if you find yourself needing to automate git-spec integration, you should use my scripts, because they're cool. I'm sure I'm not the first person to write these scripts, but I'd like to get these upstream into fedpkg. Patches for other version control systems (and major build systems like distutils and cmake) are happily accepted! What am I using them for? Automating gnome-shell stack snapshots for F12: $ fedpkg-pull-build-chain --arch=i386 --arch=x86_64 --release=F-12 --resultdir=_repo gobject-introspection gir-repository gjs clutter mutter gnome-shell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
default fedora-virt-server.ks
Hello internets, I fairly strongly think we should have a default "Fedora Virt Server" image. Rather than asking the internets to make it as I have in the past, recently I needed to install one so I looked at what's out there. There is: https://fedoraproject.org/wiki/SIGs/Server But as far as I can tell have not produced any consumables (though I hope some of the other stuff like NM/network work happened!) There is also: http://fedoraproject.org/wiki/AOS_Spin However, I wasn't actually interested in "ultra minimal", and in any case the AOS Spin has a few serious flaws: * Disables SELinux and the firewall - this is a dealbreaker. * Uses a root password by default (this is broken) Cobbler also has various sample kickstarts, which share the above flaws. So here's what I propose. We create a spin, hosted in spin-kickstarts.ks, called "fedora-virt-server.ks", which simply reflects @base from comps, plus openssh-server. The goal of "Fedora Virt Server" is: * A default configuration suitable for virtualized use (i.e. uses full hard drive by default, etc) * Fully automated installation - absolutely no questions from anaconda. * By default set up for remote access, thus openssh-server, and the .ks file helps you set up a public SSH key (and *not* a root password). I've attached my proposed file, and will commit to spin-kickstarts unless there are any objections. Basically the idea is that you can use this kickstart file to get something you can log into remotely and bootstrap whatever else you want, whether that's mock (as it is in my case) or some web application frontend, etc. I'm hoping other people can help maintain this =) But I think this use case should be very important to Fedora, as it's very important for prominent derived operating systems. We should ensure that Fedora stays fairly minimal in this case, and use it to showcase any work on the core operating system (i.e. not the desktop). fedora-virt-server.ks Description: Binary data -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default fedora-virt-server.ks
On Fri, Feb 26, 2010 at 4:21 AM, Jesse Keating wrote: > On Fri, 2010-02-26 at 03:59 +0000, Colin Walters wrote: >> >> So here's what I propose. We create a spin, hosted in >> spin-kickstarts.ks, called "fedora-virt-server.ks", which simply >> reflects @base from comps, plus openssh-server. > > openssh-server is in the @core group, which means you cannot do a Fedora > install without getting openssh-server. Oops right you are, I missed that when scanning comps. Fixed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default fedora-virt-server.ks
On Fri, Feb 26, 2010 at 4:26 AM, Garrett Holmstrom wrote: > > The Cloud SIG is working on that type of thing right now, kickstart and > all. (Actually we already have a proposed kickstart that's more minimal > than that if you want to take a look at it.) I recommend subscribing to > the cloud list and/or hanging out on #fedora-cloud. Cool! Was not aware of this effort; I'll follow up there since what I want is closely related. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: VCS key in spec files and some scripts
On Fri, Feb 26, 2010 at 6:04 PM, Till Maas wrote: > > Thanks, this looks useful. I will try to use them, too. From their > description they should be helpful to just check whether the current > SPEC would still build the current upstream SCM version. Yeah, the basic idea is that they modify the .spec file in place, but don't affect Fedora mainline (i.e. commit or upload to the lookaside cache), though that would be a nice extra optional workflow step. If you just want to test a build: $ fedpkg-make-pull $ make local $ rm *.spec sources && cvs up -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: VCS key in spec files and some scripts
On Fri, Mar 5, 2010 at 6:05 AM, Till Maas wrote: > > Here is my first feature request: please make the fedora buildsys > specific items optional, e.g. if there is no sources file, then just > skip all the CVS etc. stuff, but only fetch the tarball and update the > spec. This would make it possible to initially use the tools to create > a spec for a review request. That's a good idea. Would depend on some refactoring that's overdue, but I need to do that anyways. I can't say when it will happen but I hope soon. > Also a link to an example spec would be helpful. For just the #VCS key? Let me instead write up a formal proposal: https://fedoraproject.org/wiki/User:Walters/Packaging_VCS_key_proposal Spot can you add this to the agenda for a future packaging committee meeting? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Desktop app maintainers: Please check for StartupNotify=true
Hi, For GNOME 3 to more reliably do application tracking, we will be associating through startup-notification. Some background here: http://lists.freedesktop.org/archives/xdg/2010-February/011321.html However for startup notification to work, for compatibility reasons, the upstream .desktop file must have StartupNotify=true. It's come to my attention that a lot of .desktop files are missing this, even though they use GTK+. I've written a quick script which heuristically examines installed apps (attached); if someone writes the script which checks the whole repository, that'd be cool. If you maintain a desktop app, please check for StartupNotify=true, and if your app uses GTK+ or Qt, then please submit a patch *upstream* to add it, and at your option apply that patch in Fedora. Here's sample output from the script on my workstation, which shows a vast swath of system-config-* missing it; others of these are false positives since they're not user-visible apps. [walt...@megatron gtk+ (master)]$ ~/bin/verify-startupnotify.py '/usr/share/applications/system-config-date.desktop' probably needs StartupNotify=true '/usr/share/applications/nm-pptp.desktop' probably needs StartupNotify=true '/usr/share/applications/emacs.desktop' probably needs StartupNotify=true '/usr/share/applications/nm-openvpn.desktop' probably needs StartupNotify=true '/usr/share/applications/mimeinfo.cache' probably needs StartupNotify=true '/usr/share/applications/system-config-boot.desktop' probably needs StartupNotify=true '/usr/share/applications/redhat-userinfo.desktop' probably needs StartupNotify=true '/usr/share/applications/livna-config-display.desktop' probably needs StartupNotify=true '/usr/share/applications/redhat-authconfig.desktop' probably needs StartupNotify=true '/usr/share/applications/mount-archive.desktop' probably needs StartupNotify=true '/usr/share/applications/fedora-liveusb-creator.desktop' probably needs StartupNotify=true '/usr/share/applications/virt-manager.desktop' probably needs StartupNotify=true '/usr/share/applications/mutter.desktop' probably needs StartupNotify=true '/usr/share/applications/palimpsest.desktop' probably needs StartupNotify=true '/usr/share/applications/redhat-userpasswd.desktop' probably needs StartupNotify=true '/usr/share/applications/gnome-shell.desktop' probably needs StartupNotify=true '/usr/share/applications/spring-installer.desktop' probably needs StartupNotify=true '/usr/share/applications/redhat-system-control-network.desktop' probably needs StartupNotify=true '/usr/share/applications/fedora-empathy.desktop' probably needs StartupNotify=true '/usr/share/applications/ca-installer.desktop' probably needs StartupNotify=true '/usr/share/applications/jpackage-logfactor5.desktop' probably needs StartupNotify=true '/usr/share/applications/redhat-email.desktop' probably needs StartupNotify=true '/usr/share/applications/paperbox.desktop' probably needs StartupNotify=true '/usr/share/applications/fedora-vagalume.desktop' probably needs StartupNotify=true '/usr/share/applications/eclipse.desktop' probably needs StartupNotify=true '/usr/share/applications/javaws.desktop' probably needs StartupNotify=true '/usr/share/applications/redhat-web.desktop' probably needs StartupNotify=true '/usr/share/applications/my-default-printer.desktop' probably needs StartupNotify=true '/usr/share/applications/system-config-users.desktop' probably needs StartupNotify=true '/usr/share/applications/transmission.desktop' probably needs StartupNotify=true '/usr/share/applications/nvidia-settings.desktop' probably needs StartupNotify=true '/usr/share/applications/springlobby.desktop' probably needs StartupNotify=true '/usr/share/applications/redhat-system-config-network.desktop' probably needs StartupNotify=true '/usr/share/applications/metacity.desktop' probably needs StartupNotify=true '/usr/share/applications/qt4-qtconfig.desktop' probably needs StartupNotify=true '/usr/share/applications/gnome-glade-2.desktop' probably needs StartupNotify=true '/usr/share/applications/spring.desktop' probably needs StartupNotify=true '/usr/share/applications/compiz-gtk.desktop' probably needs StartupNotify=true '/usr/share/applications/jpackage-chainsaw.desktop' probably needs StartupNotify=true '/usr/share/applications/mozilla-thunderbird.desktop' probably needs StartupNotify=true '/usr/share/applications/nm-connection-editor.desktop' probably needs StartupNotify=true '/usr/share/applications/alacarte.desktop' probably needs StartupNotify=true '/usr/share/applications/nm-vpnc.desktop' probably needs StartupNotify=true '/usr/share/applications/redhat-usermount.desktop' probably needs StartupNotify=true '/usr/share/applications/defaults.list' probably needs StartupNotify=true '/usr/share/applications/manage-print-jobs.desktop' probably needs StartupNotify=true [walt...@megatron gtk+ (master)]$ #!/usr/bin/python import os import sys import subprocess import StringIO startup_notification_implementors = ['libgtk-x11-2.0.s
Re: Desktop app maintainers: Please check for StartupNotify=true
On Sun, Mar 14, 2010 at 6:35 PM, Victor Vasilyev wrote: > > FYI When the StartupNotify=true was specified in the desktop file of the > NetBeans I've seen bugs in launching of the NetBeans' child processes > (e.g FireFox [3]) due to the DESKTOP_STARTUP_ID environment variable. It > was fixed in the NetBeans launcher by a patch [4] according to > recommendations of the Startup Notification Protocol Specification. Swing needs to clear the environment variable. See: http://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdisplay-x11.c#n1015 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Desktop app maintainers: Please check for StartupNotify=true
On Sun, Mar 14, 2010 at 5:40 PM, Ville Skyttä wrote: > > If an app uses GTK+ or Qt, does that alone always imply that it satisfies the > desktop entry spec's requirements for StartupNotify=true, i.e. no further > examination of the app's behavior is necessary? The main tricky situation comes when the app implements single-instance behavior internally, and does some sort of IPC (dbus, whatever) to talk to an existing instance. In GNOME 3 this doesn't matter as much because we do single-instance by default, but otherwise it's definitely possible to get the stale "Starting foo..." until it times out. Actually handling this correctly is tricky[1], and I just noticed one of my apps doesn't. Maybe I should really take the plunge and backport app tracking to GNOME 2 which would obviate this. But as a general rule: add it. Even for the IPC case, it only occurs if the user tries to relaunch an existing app, which (albeit without data, but with some educated background) is unusual. Without IPC, having it has a 99.9% chance of being correct. [1] libunique handles this, but see also my fix for my app here: http://git.gnome.org/browse/hotssh/commit/?id=57c43b39413c5128983286f5c09cbaba6b397103 We have plans to basically make all this work out of the box when using GTK+ but it blocks on gdbus. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Desktop app maintainers: Please check for StartupNotify=true
On Mon, Mar 15, 2010 at 10:44 AM, Chen Lei wrote: > Should we also add StartupWMClass=someting if StartupNotify=true doesn't > work? You're going to need to elaborate on "doesn't work". * You don't see a "Starting..." notification in the tasklist in GNOME 2? * You do, but it times out instead of disappearing when the app window comes up? * Something else? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Desktop app maintainers: Please check for StartupNotify=true
Hi Mary, On Mon, Mar 15, 2010 at 11:14 AM, Mary Ellen Foster wrote: > > Well, for Firefox at least, it's option 2 and has been for a while (at > least under KDE): > https://bugzilla.redhat.com/show_bug.cgi?id=445543 I guess I should take some time to fix the most important app, yes. This turned out to be a Fedora bug; we had a BuildRequires on libstartup-notification, but didn't enable it in our mozconfig. The attached patch works for me, I'll add it to the bug too. ? .build-1.9.1.8-2.fc12.log ? i386 ? xulrunner-1.9.1.8 ? xulrunner-1.9.1.8-2.fc12.src.rpm Index: xulrunner-mozconfig === RCS file: /cvs/pkgs/rpms/xulrunner/F-12/xulrunner-mozconfig,v retrieving revision 1.28 diff -u -r1.28 xulrunner-mozconfig --- xulrunner-mozconfig 21 Aug 2009 13:40:34 - 1.28 +++ xulrunner-mozconfig 15 Mar 2010 19:02:44 - @@ -29,6 +29,7 @@ ac_add_options --enable-safe-browsing ac_add_options --enable-extensions=default,python/xpcom ac_add_options --enable-libnotify +ac_add_options --enable-startup-notification export BUILD_OFFICIAL=1 export MOZILLA_OFFICIAL=1 Index: xulrunner.spec === RCS file: /cvs/pkgs/rpms/xulrunner/F-12/xulrunner.spec,v retrieving revision 1.183 diff -u -r1.183 xulrunner.spec --- xulrunner.spec 17 Feb 2010 14:30:57 - 1.183 +++ xulrunner.spec 15 Mar 2010 19:02:44 - @@ -471,6 +471,9 @@ #- %changelog +* Mon Mar 15 2010 Colin Walters +- Reenable startup notification support, closes #445543 + * Wed Feb 17 2010 Martin Stransky - 1.9.1.8-2 - Added fix for #564184 - xulrunner-devel multilib conflict -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Tue, Mar 16, 2010 at 10:54 AM, Matthias Clasen wrote: > > Any reason this cannot be an abstract socket ? Of course, then you have > to check peer creds and figure out a way to communicate the socket name, > but at least you don't have to worry about the usual races and > permission problem you have with unix sockets. People - reliably finding other programs and initiating communication with them is 99% of the reason that DBus was created and exists in the OS. In this case, the right thing is to claim a bus name (org.blah.MyApp), export a method on it "org.blah.MyApp.GetSocket", which returns the randomly-named path to your socket in /tmp. Using abstract sockets does NOT mean you don't have to worry about permissions. Any other uid can still connect to the socket, so you either need to do some sort of peer credentials if you want to restrict it to the same uid. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Tue, Mar 16, 2010 at 12:16 PM, Daniel J Walsh wrote: > > PLEASE do not use /tmp for communications. Use /var/run if the service is > running as root, or can create a socket in /var/run. In this case I believe it's a per-user service. In which case you don't have much of a choice, because you can't use $HOME or you'll be broken by the sysadmins that inflict NFS on users. The dbus session socket is currently in /tmp, but with a random name, and the session bus rejects connections by processes not matching its own uid. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
spin kickstart/minimization cleanups
As you may or may not know I've been unhappy with how the Live image path has diverged from the automated install path (standalone anaconda + @gnome-desktop) for the desktop. Attached is a series of patches to both comps and spin-kickstarts which has a a high level goal of moving the two closer. Basically there are 3 fundamentally separate concepts which got intertwined: * Bits necessary for running a Live OS (turning off cron, etc) * Removing things we do want to fit into a CD * Removing "traditional Unix workstation" or other stuff that @base grew we don't want in @desktop regardless of space The comps patches come first, then the spin-kickstart patches. This isn't complete but I think it's a noticeable improvement. We still have more comps gardening to do. Note the spin-kickstart patches obsolete the second of the patch I sent earlier. From 018bf8e7ca32a45b040b50bde0461d4dac3f9b31 Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Tue, 23 Mar 2010 08:47:48 -0400 Subject: [PATCH 1/4] Delete all optional components from @gnome-desktop Optional components are currently only visible from the UI in Standalone Anaconda, and are a random grab bag of * Applications * System administration tools * Desktop UI replacement * Other arbitrary software that links to gtk2 and gconf Going through this list: Applications: Now browseable in packagedb System admin tools: Should move into the Fedora Deployment Guide probably Desktop UI replacement: I don't think we should (or need to) advertise these. People who want them either know how to get them, or are going to follow instructions from an upstream wiki page. Other arbitrary software: Just no. --- comps-f13.xml.in | 76 -- comps-f14.xml.in | 76 -- 2 files changed, 0 insertions(+), 152 deletions(-) diff --git a/comps-f13.xml.in b/comps-f13.xml.in index f9658fc..53d74f7 100644 --- a/comps-f13.xml.in +++ b/comps-f13.xml.in @@ -2642,82 +2642,6 @@ vino xdg-user-dirs-gtk zenity - alacarte - avant-window-navigator - beagle-evolution - beagle-gnome - buoh - byzanz - control-center-extra - dasher - deskbar-applet - esc - evince-djvu - evince-dvi - file-browser-applet - gconf-editor - gdesklets - gedit-plugins - glipper - glunarclock - gmpc - gmrun - gnochm - gnome-applet-alarm-clock - gnome-applet-bubblemon - gnome-applet-cpufire - gnome-applet-music - gnome-applet-netspeed - gnome-applet-sensors - gnome-applet-timer - gnome-commander - gnome-device-manager - gnome-media-apps - gnome-netstatus - gnome-phone-manager - gnome-pilot-conduits - gnome-schedule - gnome-system-log - gnome-theme-curvylooks - gnotime - gonvert - grsync - gst-mixer - gthumb - gtrayicon - gtweakui - gvfs-obexftp - hamster-applet - istanbul - lock-keys-applet - nautilus-actions - nautilus-image-converter - nautilus-open-terminal - nautilus-search-tool - nautilus-sound-converter - panelfm - pcmanfm - preferences-menus - pulseaudio-esound-compat - qtcurve-gtk2 - rss-glx-gnome-screensaver - sabayon - scim-gtk - screenruler - seahorse-plugins - stardict-dic-en - swfdec-gnome - tango-icon-theme - tango-icon-theme-extras - themes-backgrounds-gnome - tomboy - tracker-search-tool - verbiste-gnome - wallpapoz - wp_tray - xiphos - xscreensaver-extras-gss - xscreensaver-gl-extras-gss diff --git a/comps-f14.xml.in b/comps-f14.xml.in index 3bbd244..48b01ed 100644 --- a/comps-f14.xml.in +++ b/comps-f14.xml.in @@ -2637,82 +2637,6 @@ vino xdg-user-dirs-gtk zenity - alacarte - avant-window-navigator - beagle-evolution - beagle-gnome - buoh - byzanz - control-center-extra - dasher - deskbar-applet - esc - evince-djvu - evince-dvi - file-browser-applet - gconf-editor - gdesklets - gedit-plugins - glipper - glunarclock - gmpc - gmrun - gnochm - gnome-applet-alarm-clock - gnome-applet-bubblemon - gnome-applet-cpufire - gnome-applet-music - gnome-applet-netspeed - gnome-applet-sensors - gnome-applet-timer - gnome-commander - gnome-device-manager - gnome-media-apps - gnome-netstatus - gnome-phone-manager - gnome-pilot-conduits - gnome-schedule - gnome-system-log - gnome-theme-curvylooks - gnotime - gonvert - grsync - gst-mixer - gthumb - gtrayicon - gtweakui - gvfs-obexftp - hamster-applet -
Re: spin kickstart/minimization cleanups
A few more comps patches. From 69838cdd1765fa07df5482862c365058880a975f Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Tue, 23 Mar 2010 13:34:53 -0400 Subject: [PATCH 1/3] Move system-config-network to optional We're moving the OS towards NetworkManager. --- comps-f13.xml.in |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/comps-f13.xml.in b/comps-f13.xml.in index c0b33e2..32d233f 100644 --- a/comps-f13.xml.in +++ b/comps-f13.xml.in @@ -16,7 +16,6 @@ system-config-keyboard system-config-language system-config-lvm - system-config-network system-config-users cacti dbench @@ -32,6 +31,7 @@ ntop pessulus qtparted + system-config-network system-config-kickstart system-config-rootpassword yumex -- 1.6.6.1 From 8dce2a9d49a2716ac5d10d2d9a5c92ee84e8a7d4 Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Tue, 23 Mar 2010 13:48:13 -0400 Subject: [PATCH 2/3] Move system-config-lvm to optional It's redundant with gnome-disk-utility, and the alternative desktop UI spins are stripping it out anyways. --- comps-f13.xml.in |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/comps-f13.xml.in b/comps-f13.xml.in index 32d233f..219fa51 100644 --- a/comps-f13.xml.in +++ b/comps-f13.xml.in @@ -15,7 +15,6 @@ system-config-firewall system-config-keyboard system-config-language - system-config-lvm system-config-users cacti dbench @@ -33,6 +32,7 @@ qtparted system-config-network system-config-kickstart + system-config-lvm system-config-rootpassword yumex -- 1.6.6.1 From fd525bc909e727578503b45c9ff99b3d4bf6760f Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Tue, 23 Mar 2010 14:05:44 -0400 Subject: [PATCH 3/3] Add PackageKit-command-not-found to @gnome-desktop --- comps-f13.xml.in |1 + comps-f14.xml.in |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/comps-f13.xml.in b/comps-f13.xml.in index 219fa51..96c2f0a 100644 --- a/comps-f13.xml.in +++ b/comps-f13.xml.in @@ -2631,6 +2631,7 @@ NetworkManager-vpnc notification-daemon orca + PackageKit-command-not-found pulseaudio-module-gconf pulseaudio-module-x11 preupgrade diff --git a/comps-f14.xml.in b/comps-f14.xml.in index f67f31f..acf193b 100644 --- a/comps-f14.xml.in +++ b/comps-f14.xml.in @@ -2627,6 +2627,7 @@ NetworkManager-vpnc notification-daemon orca + PackageKit-command-not-found pulseaudio-module-gconf pulseaudio-module-x11 seahorse -- 1.6.6.1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On Tue, Mar 23, 2010 at 2:29 PM, Bill Nottingham wrote: > > Unless we start applying this methodology to all the other groups, I > would not merge it for the gnome-desktop group. Fair enough. > The other comps patches look OK. Applied, thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On Wed, Mar 24, 2010 at 2:12 PM, Adam Williamson wrote: > > I hope you actually did some basic testing of live images and default > installs based on these changes before applying them? I've been using qemu (and yes they boot/run etc.) but not doing livepath installs yet. They're not really very different remember, and in general I'm only adding packages which were already in @gnome-desktop. > We're right in the > middle of the F13 Beta process and have a base of validation tests built > up which becomes somewhat less reliable if major changes to the default > package sets start being shoved in... So we're at a crossroads now because of the size overflow. We have to do *something*. Really this has always happened because the live images have been an afterthought in the development process. I've been mostly trying to change things so that in the end the package set is very close; the scanner was the one exception. Actually to keep things clear I'll just punt that to F14. > Oh, on the removal of system-config-network: I don't think this is a > good idea. NetworkManager is still not capable of configuring dial-up > network connections. Removing s-c-n makes it difficult or impossible to > configure a dial-up network connection, I believe. Remember that system-config-network has not been in the live path install for at least the last release, only in Standalone Anaconda. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On Thu, Mar 25, 2010 at 4:40 PM, Peter Robinson wrote: > > Speaking of changes to comps for the desktop I think it would be > worthwhile breaking down the hardware support group into a couple of > groups. I was thinking something along the lines of Servers (for > iSCSI/FCoE/FCA etc), Desktop/Laptop (For wifi etc), Printing and > possibly "other". Things like printers for example with the new auto > printer support shouldn't need to be installed by default, you don't > want server stuff on a netbook and generally wouldn't need wifi > firmwares on a server. That makes sense, yes. I think it'd be good to at least have an explicit "server stuff" group. I wanted to call it @traditional-unix-server for stuff like smartmontools and iscsi, but other naming suggestions welcomed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Talking about live upgrade
On Wed, Apr 7, 2010 at 8:21 AM, Liang Suilong wrote: > Will Live upgrade > replace preupgrade? No. It's much less engineering work to fix the few bugs preupgrade has than to make "live" upgrade reliable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using capabilities for libpcap apps
2010/4/6 Radek Vokál : > Hi all, > > I need few suggestions about this .. > https://blog.wireshark.org/2010/02/running-wireshark-as-you/ .. Gerald > Combs, the upstream maintainer of wireshark, suggests to use > capabilities instead of consolehelper+root privileges for > dumpcap/wireshark. Using PolicyKit instead of hardcoding a Unix group gives a lot more flexibility to system administrators. For example, in Fedora we could interactively prompt for the root password by default. Or we could default to allowing "console users" auth. Or require the user's password. Or in fact, allow it for a given Unix group. Basically, you already have the privileged component/user session separation, which is great, so the dumpcap program just needs to be runnable as a DBus service, it could expose say an API to get a file descriptor which gives a dump stream for a given interface. Documentation lives at: http://hal.freedesktop.org/docs/PolicyKit/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
CD install delta from F-12 to F-13 current
Hi, A quick report on the current delta between F-12 and F-13's CD (generated by my just-committed script http://git.fedorahosted.org/git/spin-kickstarts.git?p=spin-kickstarts.git;a=blob;f=tools/liveimage-diff;h=a7ff363222facf7b908150fb6644aa25d1a56504;hb=HEAD ) Some highlights are that we added some OS components and apps: + "shotwell 2582122 + "gnome-color-manager 3079621 + "sssd 4135276 + "seahorse 7142974 + "planner 6285529 There's a lot of added packages here, which I think is at least partly due to the comps unification work. Removed: - "gnupg 5073185 - "rhino 826258 - "abiword 15361 - "libabiword 24396251 - "java-1.6.0-openjdk 84493096 The Abiword removal was due to the goal that the CD is just the desktop, shrunk to fit. And finally the biggest winners in terms of package size growth: = "kernel 2667526 = "empathy 2979990 = "libgweather 3184637 = "mesa-dri-drivers 21609392 The full report is attached. + "hal-filesystem 0 + "report-config-bugzilla-redhat-com 83 + "color-filesystem 151 + "goddard-backgrounds-gnome 808 + "abrt-plugin-runapp 10154 + "system-setup-keyboard 13752 + "report-gtk 16147 + "ar9170-firmware 18034 + "vpnc-script 18270 + "python-virtkey 22244 + "hostname 22566 + "cyrus-sasl-gssapi 29592 + "shared-color-profiles 30906 + "nss-sysinit 31149 + "plymouth-graphics-libs 32008 + "libtevent 38336 + "pcsc-lite-libs 45184 + "ghostscript-cups 50143 + "gsm 51396 + "libmpcdec 56622 + "keyutils 66023 + "report-plugin-bugzilla 68509 + "cifs-utils 74259 + "acpid 74381 + "libieee1284 75477 + "python-GnuPGInterface 77474 + "sssd-client 82605 + "libcdaudio 83444 + "usb_modeswitch 89097 + "libkate 93327 + "libgomp 95092 + "gtkimageview 101551 + "librsync 102334 + "pinentry-gtk 103896 + "c-ares 107829 + "caribou 108948 + "report 112635 + "gstreamer-rtsp 113664 + "lohit-devanagari-fonts 113721 + "libplist 117171 + "celt 118149 + "libass 121955 + "slv2 124763 + "json-glib 141615 + "libsysfs 145333 + "libdvdread 148174 + "libofa 158949 + "libimobiledevice 161227 + "NetworkManager-openconnect 165427 + "usbmuxd 167040 + "plymouth-core-libs 172368 + "libdvdnav 184261 + "pywebkitgtk 190103 + "gvfs-afc 202852 + "libgnome-keyring 207475 + "openconnect 207992 + "lcms 208504 + "libdwarf 211217 + "libldb 213304 + "zbar 267613 + "python-beaker 281295 + "xorg-x11-drv-wacom 289061 + "enca 311773 + "libdc1394 332585 + "libmodplug 333854 + "iwl5150-firmware 344430 + "libgee 352461 + "mpfr 379322 + "simple-scan 412156 + "iwl6000-firmware 469192 + "smp_utils 484087 + "libnih 485694 + "libiodbc 551662 + "postgresql-libs 556843 + "udisks 638215 + "sil-abyssinica-fonts 649794 + "schroedinger 661935 + "rasqal 675620 + "dvb-apps 689921 + "redland 716343 + "pyclutter 755316 + "raptor 837641 + "transmission-common 963590 + "python-mako 1049800 + "dirac-libs 1071160 + "ncftp 1284092 + "gnome-dvb-daemon 1406199 + "deja-dup 1455297 + "setools-libs-python 1628036 + "duplicity 1707928 + "python-boto 1985950 + "transmission-gtk 2233988 + "shotwell 2582122 + "tigervnc-server 2926713 + "paratype-pt-sans-fonts 300 + "gnome-color-manager 3079621 + "gstreamer-plugins-bad-free 3365801 + "sane-backends 3792312 + "fftw 3910154 + "goddard-backgrounds-single 3928407 + "sssd 4135276 + "mysql-libs 421 + "cheese-libs 5609567 + "planner 6285529 + "dmz-cursor-themes 6526975 + "ImageMagick 6735456 + "xorg-x11-fonts-misc 7134279 + "seahorse 7142974 + "sane-backends-libs 7704160 + "linux-firmware 8109143 + "poppler-data 11987205 + "wqy-zenhei-fonts 13319014 - "nodoka-filesystem 0 - "lyx-fonts-common 3301 - "libopenraw-gnome 7504 - "htmlview 9502 - "libbdevid-python 11592 - "fedora-setup-keyboard 13071 - "abiword 15361 - "lyx-cmex10-fonts 21092 - "abrt-plugin-kerneloopsreporter 25088 - "lyx-cmr10-fonts 26348 - "paktype-fonts-common 28567 - "lyx-cmsy10-fonts 29392 - "lyx-cmmi10-fonts 32556 - "nodoka-metacity-theme 35397 - "abrt-plugin-sqlite3 38573 - "aiksaurus-gtk 74832 - "giflib 81932 - "jline 89869 - "joystick 99769 - "fedorainfinity-screensaver-theme 104031 - "lohit-marathi-fonts 110736 - "lohit-maithili-fonts 110768 - "lohit-hindi-fonts 110982 - "jpackage-utils 168677 - "ots-libs 171678 - "plymouth-libs 171976 - "fribidi 178754 - "loudmouth 198480 - "ethtool 225660 - "java-1.6.0-openjdk-plugin 231112 - "gstreamer-plugins-flumpegdemux 264775 - "libwpg 274216 - "libksba 275016 - "tzdata-java 275562 - "nash 302096 - "libopenraw 363042 - "python-enchant 379079 - "t1lib 394344 - "libwmf 447905 - "DeviceKit-disks 514853 - "dirmngr 596260 - "aiksaurus 601798 - "linuxwacom 619094 - "abyssinica-fonts 649794 - "wv 701148 - "libwpd 750507 - "rhino 826258 - "empathy-libs 831664 - "link-grammar 1316764 - "kernel-firmware 2067581 - "gtkmathview 2892598 - "bluecurve-cursor-theme 3181040 - "transmission 3644011 - "constantine-backgrounds-single 4372087 - "gnupg 5073185 - "bitmap-fonts 7045704 - "gthumb 7782182 - "constantine-backgrounds 9556485 - "cjkuni-uming-fonts 21552609 - "libabiword 24396251 - "java-1.6.0-openjdk 84493096 = "ibus-pinyin -33
Re: CD install delta from F-12 to F-13 current
Hi, On Thu, Apr 8, 2010 at 11:42 PM, Rahul Sundaram wrote: > > How does it make sense to remove Abiword and add Planner? I assume a > project management tool is much less used than a word processor. Good question! So the story on this is that we have 3 different desktops: * LiveCD install * DVD/kickstart * Upgrade from F-(x-1) The goal is to reduce the delta between these and get to the point where we really have one default install, which might be subject to constraints based on space. Upgrades currently don't reflect removals or comps additions for example. There were additions to the LiveCD that weren't in the DVD/kickstart install such as Abiword. The LiveCD is operating on the assumption that you have an internet connection, you just want to download something relatively small to get started, and can install new apps afterwards, whether that's Abiword, OpenOffice, or whatever else. Now, I understand the desire to pack the LiveCD with as much Free Software as we can fit in the space constraints. However, we have to balance this with creating different desktop experiences. This said, I wouldn't really have a problem with adding Abiword back on the CD. The far bigger problem in my mind in terms of comps unification was the random removals that weren't for space reasons (acpid, nfs-utils). For that kind of thing we need to be fixing the base operating system. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up! Erlang package becomes modularized in Fedora.
On Sat, Apr 10, 2010 at 8:56 AM, Peter Lemenkov wrote: > > I did some investigation, and find a way to completely modularize > whole Erlang package. Sounds great! > Also I'm sure that we need to push this > change into both F-12 I object to this on general principle. Pushing sweeping changes to infrastructure packages is not what stable updates are for. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On Wed, Apr 21, 2010 at 7:08 AM, Peter Robinson wrote: > > I've spent a little time looking at the hardware side of things and > done a basic patch for some of the hardware stuff based on the current > rawhide comps file. I've broken it down into network/server/misc for > the time being and pushed the print stuff over to its group. More can > be done as it was a quick look through. The old hardware-support > currently includes all the other groups so there's no real change for > current builds overall. This looks like a good start. I think the way this kind of thing should work in general is that the system detects if you have the hardware, and dynamically installs support for it. We'd need some database mapping things like USB ids to packages. Networking is an exception; we should include as many drivers/tools for networking-related functionality as possible so that the system can be bootstrapped. Basically: if you have a GPS chip, gypsy gets installed and runs. If you don't, it doesn't. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Mon, Nov 15, 2010 at 4:13 PM, Matthew Garrett wrote: > On Mon, Nov 15, 2010 at 08:43:39PM +0100, Karel Klic wrote: >> Dne 12.11.2010 17:35, Kevin Fenzi napsal(a): >> > Any other exciting work in progress that might land in F15 that people >> > are actively working on? >> >> ABRT with retrace server support, and a retrace server instance up and >> running. It will improve the quality of backtraces. > > How does the user verify that there are no passwords or other personal > information in the core dump? I don't think it really works to ask the user to do that in practice (though I'm not going to go scanning through bugzilla to try to prove the point). It would work out better to: 1) Have crashes be anonymous by default 2) Limited access to crash dump data (for a given package, only allow access by people in the ACLs for those packages?) 3) Still warn the user that it may contain private data, and allow them not to submit (obviously) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, Nov 17, 2010 at 2:57 AM, Hans de Goede wrote: > > I would also like to point out that if this were to happen in Ubuntu > which we sometimes look at jealously for getting more attention / users > then us, the glibc change would likely be reverted immediately, as that > is the right thing to do from an end user pov. Hardly; we could for example equally as well patch firefox to load flash with a compatibility wrapper. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: updates-testing trainwreck.
On Fri, Nov 19, 2010 at 3:38 PM, Dan Williams wrote: > > Isn't there any way we can update the icon cache spec to add a checksum > or something? Or is the corruption just wrong data, not bad data? Likely a lot of these are simply data corruption on power loss (Unix default). We can try to avoid that: https://bugzilla.gnome.org/show_bug.cgi?id=635307 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
Pardon the thread necromancy, So recently I had cause to look at http://fedoraproject.org/wiki/Features/RemoveSETUID again (I was investigating the X server permissions for an unrelated reason). Now, that page links to http://people.redhat.com/sgrubb/libcap-ng/index.html which attempts to explain the value of capabilities, etc. I was following along on all of this, and I understand that capabilities have some (non-negligible) value if you don't have e.g. cap_sys_admin. But then I got to the point where it says: "But they still have uid 0, which typical system installation allows root to do things. For example, /bin/sh is 0755 and /bin is also 0755 perms. A disarmed root process can still trojan a system. But what if we got rid of all the read/write permissions for root?" So...right, "we can do these small changes, and then if we do this BIG CHANGE, it all works!". But this feature doesn't include BIG CHANGE, and there are no plans to, right? Or is chmod u-rwx g-rwx on the root filesystem really in the cards? Now, https://fedoraproject.org/wiki/Features/LowerProcessCapabilities appears to claim 100% completion on this for Fedora 12, but none (?) of it happened? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
On Tue, Dec 21, 2010 at 3:21 PM, Daniel J Walsh wrote: > > File capabilities just limit the number of capabilities an application > starts with. setuid app means an app starts with all 32, a couple of > new ones, capabilities. Then it is up to the app developer to drop the > capabilities when the app is done using them. Going to file > capabilities just limits the capabilities an application starts with to > the specified capabilities. The application developer should still drop > the capabilities once they no longer need them. It helps in the case of > a bug in an application, that does not drop capabilities. I understand the goal of getting fewer capabilities (however, I think switching setuid to cap_sys_admin is at best pointless, at worst an obfuscation). But you didn't answer my question - does the scope of this plan include a Unix mode 005 /bin, etc. or not? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
2010/12/21 Miloslav Trmač : > If an attacker were controlling a process running with uid 0 and no > capabilities at all, and /bin/sh were 0555, nothing prevents the > attacker from chmod()ing /bin/sh to 0755 and overwriting it. This makes > any attempts to change the file permissions rather pointless. Ah, of course. That makes sense, thanks! But it leaves me feeling pretty uncertain about the value of trying to subset capabilities... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld - A firewall daemon with D-BUS interface providing a dynamic firewall (test version)
On Thu, Dec 23, 2010 at 11:03 AM, Thomas Woerner wrote: > > - A simple tray applet (firewall-applet) Actively deprecated; please consider other interfaces. In this case, I think a control panel module is just fine. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld - A firewall daemon with D-BUS interface providing a dynamic firewall (test version)
The project design (code and interface) seems to be very influenced by NetworkManager, but both code and design wise that project has flaws that Dan and others have spent a lot of time undoing. I don't want to see the same mistakes made 5 years later =) >From a UI side, if your first cut is just replacing system-config-firewall, that seems more than enough, no? How the firewall controls/design integrates with GNOME 3 networking would need someone with actual experience design, but I am just trying to avoid a regression here with yet another part of the OS taking up 22 pixels of screen space permanently. You can use the notification system for transient issues, but I'm *very* skeptical of anything here that isn't just on/off. >From the code side, I think the NM "session" configuration basically hasn't worked; the new NM code will be all system settings. In particular how it works with fast user switching is pretty suboptimal. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gtk2 2.99.0
On Mon, Jan 10, 2011 at 7:38 PM, Toshio Kuratomi wrote: > Sounds like the gtk-update-icon-cache programs could be pushed into their > own subpackage that both gtk2 and gtk3 require. That might be the best way > to resolve that. In the Fedora 18+ timeframe where we might discuss not shipping gtk2 in the default image, we can revisit this issue =) For now, keeping it in gtk2 seems fine to me. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: @core in F14 pulls in libX11
On Sat, Jan 22, 2011 at 1:54 AM, Garrett Holmstrom wrote: > It seems that the "core" yum group pulls in X11 libraries, at the very > least on x86_64, via the following dependency chain: > > policycoreutils > dbus-glib > gobject-introspection > cairo > libX11 > > Does that much seriously need to be in what we consider a bare minimum > Fedora install? It was an unexpected complicated interaction between policycoreutils and dbus-glib and gobject-introspection, and for Fedora 15 we broke every single one of those links. Unfortunately it was only noticed very late in the cycle for F14 and would be hard to fix there. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenGL broken after resume from supend on AMD Radeon X800
Hi Christoph, On Fri, Feb 11, 2011 at 9:07 AM, Christoph Frieben wrote: > I am running the x86_64 flavours of fully updated F14 and the current > Fedora development tree on a system which is equipped with a Radeon > X800 PCIe video adapter. After resuming from suspend, OpenGL is > broken, Is this a regression? Those are definitely a priority. Have you tried a nightly live image to see if the bug is fixed in our development branch? http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: state of systemd in Fedora and services pledge
On Wed, Feb 23, 2011 at 12:39 PM, Toshio Kuratomi wrote: > > The scriptlets that we currently have do not work in testing. I have tested > the migration path from a sysv init script using service to an upgraded > package using systemd unit files and that doesn't work. at some point > someone also needs to test the upgrade between systemd unit file using > services but I personally haven't had time for that yet. The FPC ticket has > the steps that would constitute a good test of those services. This is a live yum upgrade? That not working doesn't seem hard blocker to me - we currently recommend preupgrade which is non-live for precisely these kinds of reasons. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Services that can start by default policy feedback
On Wed, Feb 23, 2011 at 1:56 PM, Kevin Fenzi wrote: > Greetings. > > FESCo is looking at the question of what services can start by default > (ie, you install something and it's set to start automatically next > time you boot up). Honestly I think it'd be conceptually a lot simpler if all services didn't start on RPM installation, period. Specific ones that we want enabled by default in a desktop install could simply be turned on in the kickstart file. Something like the attached patch (obviously incomplete, and not tested): From f87cd366e19c2ecd1abd28c066c869000de1d6bf Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Thu, 24 Feb 2011 09:43:16 -0500 Subject: [PATCH] Move system service enabling here Rather than have the list of services enabled by default encoded in the RPMs, explicitly specify the list here. --- fedora-live-desktop.ks | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/fedora-live-desktop.ks b/fedora-live-desktop.ks index 06700b3..edd8678 100644 --- a/fedora-live-desktop.ks +++ b/fedora-live-desktop.ks @@ -20,6 +20,17 @@ nss-mdns %end %post + +# Enable system service processes, "local" only +chkconfig messagebus on +chkconfig abrtd on +chkconfig NetworkManager on + +# Enable some system service processes that listen on internet ports, +# though of course this is pointless with a firewall always on. +chkconfig avahi on +chkconfig cupsd on + cat >> /etc/rc.d/init.d/livesys << EOF # disable screensaver locking gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults -s -t bool /apps/gnome-screensaver/lock_enabled false >/dev/null -- 1.7.1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Services that can start by default policy feedback
On Thu, Feb 24, 2011 at 10:04 AM, Matthew Garrett wrote: > On Thu, Feb 24, 2011 at 09:44:19AM -0500, Colin Walters wrote: >> On Wed, Feb 23, 2011 at 1:56 PM, Kevin Fenzi wrote: >> > Greetings. >> > >> > FESCo is looking at the question of what services can start by default >> > (ie, you install something and it's set to start automatically next >> > time you boot up). >> >> Honestly I think it'd be conceptually a lot simpler if all services >> didn't start on RPM installation, period. Specific ones that we want >> enabled by default in a desktop install could simply be turned on in >> the kickstart file. > > We considered that option, but it's not just about the desktop install - > you need a default set for a default install, "Default install"? This is @base from anaconda or something? > or the entire world is > going to set fire to you because cron isn't there by default any more. True, in this design just running through the RPM path isn't going to give you what it did before. > And once you've got a default set for the default install, why not just > do it at the package level and ensure some level of consistency? Well...until one product wants a "service" enabled and another doesn't. I guess in the "whitelist" design the latter just has to "chkconfig foo off" in a kickstart. I think this is already the case with openssh-server. Anyways if we end up with just a documented list that's probably OK. But it has tradeoffs - for example, it just says these services *may* be enabled, not that they will. So for someone writing a kickstart file, you pretty much have to "chkconfig foo on" *anyways*, since you have no guarantee that they actually *are* enabled in a specific Fedora release. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Services that can start by default policy feedback
On Thu, Feb 24, 2011 at 10:32 AM, Matthew Garrett wrote: > "May" as in "Are allowed to". It's always going to be the package > maintainers call in the end - we're not going to mandate it. Okay; it's not worth going through the details if you guys already discussed and rejected it, we've lived for years with the status quo and this is basically just documenting it. One other random thing - NetworkManager seems to be a big missing item from the list? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Services that can start by default policy feedback
On Thu, Feb 24, 2011 at 12:06 PM, Garrett Holmstrom wrote: > > So whether or not a given package will be enabled by default after I > tell yum to install it depends on which spin, if any, that I initially > installed my system with? Why should the initial package set that my > system came up with have any effect at all on what happens when I > install something new? No. In my proposal above (which I'm not really going to spend more effort debating since we have bigger issues and the current FESCo consensus of basically documenting is better than nothing) the services are enabled in the kickstart - *no* service is enabled by default after installing via yum later with 100% consistency. If you want it on you use chkconfig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 Alpha impressions
On Mon, Feb 28, 2011 at 5:56 AM, Bastien Nocera wrote: > > > The fallback mode is supposed to "mimick" the gnome-shell behaviour, > within its limited abilities. You won't be able to move the applets, or > fiddle around with it. Think of it as a cut-down version of the shell. > > If you see things that don't match, feel free to file bugs against > gnome-panel, and they should hopefully get routed to the right > component. This is all very much a work in progress, but yes, that's the goal. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minutes/Summary from today's FESCo meeting (2011-02-23)
On Wed, Feb 23, 2011 at 2:27 PM, Kevin Fenzi wrote: > > Whats the easy way to list them? ls /usr/share/dbus-1/system-services (There is a dbus method for this too, "ListActivatibleServices", but just "ls" is easier) > To show if they are set to start by default or not? (or does that make > sense for dbus at all, since they would start when asked to?) What Lennart is saying is that in Fedora <= 14, they would always start when requested (any uid could do so), and dbus exposed no administrator interface to change this (other than "rm" on the .service file) but with systemd it's possible. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changes to polkit-desktop-policy
On Thu, Mar 17, 2011 at 1:29 PM, Daniel J Walsh wrote: > > Are we turning on the wheel group in sudo? It would clearly match doing so for pkexec, but would then be bizarre because the Fedora installer still asks you to make up a root password. The whole thing is really a mess without any plan for where things are going. Is there any plan, anywhere? Where was the design behind firstboot adding the checkbox? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changes to polkit-desktop-policy
On Thu, Mar 17, 2011 at 1:57 PM, Bill Nottingham wrote: > > So, it looks like the second two bits weren't properly cloned/communicated. > Design of this appears to have been 'firstboot maintainer + people CC'd on > the bug.' Okay... > Changing the root password screen wasn't mentioned as part of that > plan; The point is that that in the default flow now, you get both; and there is no plan to change this; correct? > note that that's at an entirely different portion of the workflow, and > given that firstboot does not run on all installs, leads to problems if you > drop it entirely (how do you log in?) Of course, I know why firstboot was created, and we've talked in the past about basically running it inside Anaconda so in the case where you *aren't* booting a pre-imaged system it is saner. But that's not quite the point - it's really not hard to change our software implementation. The hard part is having a plan for what the implementation should be, and that's my above question. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changes to polkit-desktop-policy
On Thu, Mar 17, 2011 at 2:22 PM, Chris Adams wrote: > Once upon a time, Colin Walters said: >> The point is that that in the default flow now, you get both; and >> there is no plan to change this; correct? > > If you don't have a root password, how do you log in for single-user > mode, manual fsck, etc.? AFAIK those only prompt for the root password, > not a username. Sorry, I didn't want a long thread at the moment to try to create the plan; if there isn't one, for Fedora 15, it just needs some sort of release note: "You can now easily enable both sudo and pkexec for the first user created via a checkbox; see the manual pages for each tool." Actually, we'd also need to mention the changes in the polkit-desktop-policy, which looks like it boils down to "Change the system time" and "Mount internal file systems"? Well except it *would* for the first, but the clock mechanism moved to org.gnome.settingsdaemon.datetimemechanism. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changes to polkit-desktop-policy
On Thu, Mar 17, 2011 at 2:22 PM, Chris Adams wrote: > Once upon a time, Colin Walters said: >> The point is that that in the default flow now, you get both; and >> there is no plan to change this; correct? > > If you don't have a root password, how do you log in for single-user > mode, manual fsck, etc.? AFAIK those only prompt for the root password, > not a username. I will follow up briefly here to say that this kind of issue comes down to the fact that thinking in terms of users and passwords is wrong - you need to step back and think in terms of "deployment targets", which boil down to "(at least one) user owns machine"[1], "timesharing unix server", "lab workstation" and "kiosk" mainly. For the user-owns-machine target, we obviously have to provide some hatch for them to "do whatever"; currently that's the root password. But the root password is silly for this model because they can just boot with "init=/bin/sh" and do whatever. So fsck would need to recognize this and probably just refuse to boot by default, but obviously it could be configurable. Presently we have a big mess of tools which are obviously all configurable, and I'd say the target is vaguely "lab workstation", except for a few PolicyKit files which move the default OS install closer to "user owns machine". [1] A lot of people call this "single user laptop/desktop", but in fact this target can be multi-user, just as long as least one person owns the hardware, and it has nothing to do with laptops or desktops. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
heads up: rawhide boot hang - rsyslog is broken
See https://bugzilla.redhat.com/show_bug.cgi?id=689089 https://admin.fedoraproject.org/updates/rsyslog-5.7.9-1.fc15 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
(actually I meant f15 branched)
Just for reference, I meant Fedora 15, old habit made me say "rawhide". -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Please move your ABRT bugs upstream
On Wed, May 5, 2010 at 5:34 PM, Orcan Ogetbil wrote: > > I understand. But please respect what others are thinking. I do see a > problem in abrt that it wastes my time. To stem another abrt thread; see earlier one here: http://www.redhat.com/archives/rhl-devel-list/2009-November/msg01487.html Basically, the future should be a (by default) anonymous crash submission database which doesn't send maintainers email immediately when something crashes on someone's computer, since there's just no way that will (or has) scaled. Maintainers can then at their leisure examine crashes, and crash reporters can optionally attach extra data, or if it's promoted to a bug (remember, not every crash is a bug - think bad hardware), then they can interact with maintainers via bugzilla normally. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Fri, May 7, 2010 at 7:06 AM, Pierre-Yves wrote: > > Would it be allowed to try to restart gconfd ? It would make sense to SIGHUP gconfd after new schemas are installed, yes. Note though we should really only be doing this once at the end of a transaction when installation is complete. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Fri, May 7, 2010 at 12:05 PM, Toshio Kuratomi wrote: > On Fri, May 07, 2010 at 09:38:45AM -0400, Colin Walters wrote: >> On Fri, May 7, 2010 at 7:06 AM, Pierre-Yves wrote: >> > >> > Would it be allowed to try to restart gconfd ? >> >> It would make sense to SIGHUP gconfd after new schemas are installed, >> yes. Note though we should really only be doing this once at the end >> of a transaction when installation is complete. >> > My understanding was that with current Fedoras, gconf doesn't need this but > I could be misremembering, missing a corner case, or just wrong :-) [walt...@pocket gconf (master)]$ git grep inotify [walt...@pocket gconf (master)]$ git grep g_file_monitor [walt...@pocket gconf (master)]$ So... > We can't do this only once at the end of a transaction but if I'm > remembering a different discussion, doing it multiple times at the end > of the rpm transaction should be almost as good (since gconf will wait for > a few moments from getting the first SIGHUP to see if it will get any other > ones.) Is that correct? It has a 30 second timer currently for "periodic cleanup", and SIGHUP just sets a flag that that function reads. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Fri, May 7, 2010 at 1:17 PM, Toshio Kuratomi wrote: > > Running makefile-install-schema and makefile-uninstall-schema eventually > calls do_sync() which was supposed to reread the schemas. That's currently > calling gconf_engine_suggest_sync() in gconf.c and I'm not sure whether > there's some logic in there that could cause it not to suggest syncing in > our current setup. I don't understand how this could ever work - GConf IPC happens in terms of ORBit which is per-uid, so a bare --makefile-install-rule might contact the GConf engine for uid 0 and ask it to reload, but that's it. It would have to jump through hoops to contact the GConf running as uid 500 or whatever, and I don't see those hoops being jumped. Oh but...I see, it's a Fedora patch not in the upstream GConf code to run killall. My bad looking at upstream gconf git. Sigh... > So changing policy back to doing a killall -HUP in %posttrans should work. > It would be nice to know what Fedora versions are affected by this and > whether it will someday be fixed before updating the Guidelines, though. So though this still leaves a window of up to 30 seconds where after installing an application the schema will be invalid. Which seems very likely what people are hitting. I think ideally we'd have the RPM system detect a schema was installed and do an immediate reload once post transaction, and nuke the 30 second timeout from gconf. That still leaves though the problem of the massive copy&paste scriptlets; we could remove the killall from --makefile-install-rule which would help. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GConf error
On Sat, May 8, 2010 at 2:22 PM, Toshio Kuratomi wrote: > I see that we're calling killall -TERM instead of killall -HUP in the patch. > That seems non-optimal (since it means we'll keep shutting down the gconfd > server instead of letting it use it's 30second timeout) That's definitely suboptimal because we'll lose the caches etc. from the running process. > > Anyone know why we haven't seen progress on the upstream bug? No one's > raised any philosophical blockers with doing this: > http://bugzilla.gnome.org/show_bug.cgi?id=328697 I commented there. > Colin, if no one's looking into fixing this bug there's two ways to > workaround this bug: > > Change macros.gconf2 to run killall after the schemas are installed or > uninstalled. This requires an update of the GConf2 package. We don't know > which Fedora versions this affects yet (the guake update was for F13) killall -TERM? > Restore the packaging guideline suggestion to run killall -HUP gconfd-2 > Since we don't know which versions this affects, we'd need to recommend it > on all Fedora releases. I don't think that helps - the original problem report was failure on initial install + run, which I believe must be a result of the 30 second delay in gconfd from SIGHUP. What do you think about my comment here? https://bugzilla.gnome.org/show_bug.cgi?id=328697#c9 If we can't get the changes to RPM made to do it once post-transaction, then I suggest we simply bite the bullet and remove the 30 second timeout from gconfd until such time as the RPM change can be made. I'll take "slower without race conditions" over "faster but racy". -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 12:50 PM, Lennart Poettering wrote: > > http://0pointer.de/public/dbus.service. Note the ExecStartPre here, like most daemons, is conceptually busted. There's no reason we shouldn't lay that file down once when the OS is installed, and not check it every boot. Or alternatively, just move the uuid generation into the daemon itself. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 12:50 PM, Lennart Poettering wrote: > On Wed, 26.05.10 09:07, Adam Williamson (awill...@redhat.com) wrote: > >> >> On Wed, 2010-05-26 at 12:42 +0200, drago01 wrote: >> > On Wed, May 26, 2010 at 5:02 AM, Casey Dahlin wrote: >> > > On Tue, May 25, 2010 at 05:45:07PM +0200, Lennart Poettering wrote: >> > >> On Tue, 25.05.10 10:21, Casey Dahlin (cdah...@redhat.com) wrote: >> > > [...] >> > > 3) Cutting down on the forking by replacing some of the shell scripts... >> > > cool >> > > 3a) With C code... really? >> > >> > This does make a lot of sense to me, initscripts being scripts is a >> > major slowdown factor >> > by itself. >> > >> > It is not like you want to edit the scripts all the time, so there is >> > no reason for them being scripts. >> >> I beg to differ. I've had to create or modify initscripts quite often, >> either as a sysadmin or a packager. If this is now going to require C >> coding skills, I'm not going to be able to do it. I don't think it's >> safe to assume that everyone who needs to write or modify an initscript >> is going to know C. What about people who write apps that need >> initscripts in some other language? > > THERE ARE NO PLANS TO SHIP COMPILED INIT SCRIPTS OR ANYTHING LIKE THAT! > > The plan is to reduce what is currenlty done in files like > /etc/init.d/messagebus to files like > http://0pointer.de/public/dbus.service. Also: > Description=D-Bus System Bus This seems unnecessary. Can we default to the name of the script? If this isn't translated, I don't see how it's more interesting than just "dbus". > Requires=basic.target sockets.target dbus.socket > After=basic.target sockets.target dbus.socket What does this goop mean and why is it necessary? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Fri, May 28, 2010 at 2:06 PM, Jon Masters wrote: > Didn't we "decide" that Fedora was intended for more technical users? I > don't see many technical users crying out for a hammered shut init > system where they feel like they have to go to their auto mechanic to > attach the right magic dongle to fix it when it breaks. I don't think this kind of rhetoric is useful. Once an effort is made to switch to systemd, if *specific* real world examples of things that are reasonable to configure are no longer so, we can treat that as a bug. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -upstart subpackage vs tranditional initscripts
On Wed, Jun 2, 2010 at 9:13 AM, Chen Lei wrote: > > Is it right for the maintainer to provide two separate subpackages, > one with the tranditional rc.d contents and one with an upstart > scripts and make the -upstart subpackage have a higher priority over > sysinit subpackage? No, that's crazy. The benefits of using the upstart syntax are small, and would be completely outweighed by the downsides of bloating the package set like this. It's also really undiscoverable; very few system administrators are going to be actively seeking out -upstart packages. Long term we need to pick one init system and change things to take advantage of it by default. Lennart's suggestion of shipping both in the main package seems quite sane. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: init script behaviour
On Tue, Jun 15, 2010 at 8:08 AM, Joe Orton wrote: > > I'd instinctively prefer (1) from a "do one thing and do it well" > perspective; (2) starts down the road of a better/more complex form of > service-monitoring/management and ends up doing it really badly in messy > sh script in N places. Absolutely. The core OS doesn't need to come with a half-assed reimplementation of Nagios. "service foo status" should be just "is the pid running, and that's how things will be with Systemd as I understand it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gethostbyname() and resolv.conf updates
On Fri, Jun 18, 2010 at 8:23 AM, Stephen Gallagher wrote: > > This is the entire purpose of the res_init() function in glibc. If your > application needs to be aware of a change in resolv.conf, you should be > monitoring it with inotify and calling res_init() anytime the file is > changed. That's awful. Really, really awful. Do you have any idea how many things would need to be patched to do that? Other operating systems handle this just fine. Asking every component to use inotify and res_init() because the glibc maintainers apparently think a simple stat() on a sure-to-be-in-kernel cache inode is too expensive...well, think about it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gethostbyname() and resolv.conf updates
On Fri, Jun 18, 2010 at 9:56 AM, Stephen Gallagher wrote: > > Sorry, my reply was more directed against the assertion that NSCD should > be mandatory to solve this without changes to glibc. I agree that it > would be ideal for gethostbyname() to internally perform a res_init() > when appropriate. Ok, then we agree. I don't personally care whether it's NSCD or a magical oracle as long as our operating system's gethostbyname() function actually functions on mobile devices. (Caching DNS would be a huge bonus, as other operating systems do this and us not doing so makes the internet "feel" significantly, visibly slower compared to them, but that's a separate bug) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gethostbyname() and resolv.conf updates
On Sat, Jun 19, 2010 at 10:54 PM, Dan Williams wrote:
>
> I'm just gonna make NM use a local caching nameserver (which means
> dnsmasq) by default at some point soon. People that don't want it can
> turn it off.
When thinking about this, there's a rather obvious patch here that
really should have been made 5+ years ago...make it an option! And
this actually makes some sense, e.g. if NetworkManager writes out a
static configuration, then there's no need to stat() on it since we
can assume it won't change. (This does still screw over server admins
who hand-edit it, but...)
glibc and NetworkManager patches attached.
(I'm totally in favor of the dnsmasq approach too since the OS
desperately needs DNS caching too, but this is a simple patch that
doesn't conceptually conflict).
From 464035fa03acd915c8cf460452d0dc6c031180ca Mon Sep 17 00:00:00 2001
From: Colin Walters
Date: Fri, 18 Jun 2010 16:19:12 -0400
Subject: [PATCH] [resolv.conf] Add a new "dynamic" option which tells us to re-stat the file
Various operating system vendors have been shipping variants of a
patch which stat()s resolv.conf on every gethostbyname() call. The
reason for this is simply that on mobile devices, nameservers can
change, and having to restart all applications and processes for this
is simply broken. (NSCD exists, but is considered unreliable)
The intent of this patch is that in e.g. Fedora, NetworkManager's
generated resolv.conf file will include this if it gets any of its
data from DHCP. Otherwise, it can omit the option, and processes
won't have to pay the cost of the stat() (assuming it was even a real
concern to begin with).
---
resolv/res_init.c |2 ++
resolv/res_libc.c | 26 ++
resolv/resolv.h |1 +
3 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/resolv/res_init.c b/resolv/res_init.c
index 40dbe7d..7b02e49 100644
--- a/resolv/res_init.c
+++ b/resolv/res_init.c
@@ -535,6 +535,8 @@ res_setoptions(res_state statp, const char *options, const char *source) {
statp->options &= ~RES_NOIP6DOTINT;
} else if (!strncmp(cp, "rotate", sizeof("rotate") - 1)) {
statp->options |= RES_ROTATE;
+ } else if (!strncmp(cp, "dynamic", sizeof("dynamic") - 1)) {
+ statp->options |= RES_DYNAMIC;
} else if (!strncmp(cp, "no-check-names",
sizeof("no-check-names") - 1)) {
statp->options |= RES_NOCHECKNAME;
diff --git a/resolv/res_libc.c b/resolv/res_libc.c
index 810fbc8..5dc4e3a 100644
--- a/resolv/res_libc.c
+++ b/resolv/res_libc.c
@@ -89,12 +89,38 @@ res_init(void) {
return (__res_vinit(&_res, 1));
}
+/* If the DYNAMIC option is set, we stat the file, and see if its
+ * mtime has changed. If so, request an initialization.
+ */
+static void
+_res_dynamic_check (void)
+{
+ static time_t last_mtime, last_check;
+ time_t now;
+ struct stat statbuf;
+
+ time (&now);
+ if (now != last_check) {
+ last_check = now;
+ if (stat (_PATH_RESCONF, &statbuf) == 0 && last_mtime != statbuf.st_mtime) {
+ last_mtime = statbuf.st_mtime;
+ atomicinclock (lock);
+ atomicinc (__res_initstamp);
+ atomicincunlock (lock);
+ }
+ }
+}
+
/* Initialize resp if RES_INIT is not yet set or if res_init in some other
thread requested re-initializing. */
int
__res_maybe_init (res_state resp, int preinit)
{
if (resp->options & RES_INIT) {
+ if (resp->options & RES_DYNAMIC) {
+ _res_dynamic_check ();
+ }
+
if (__res_initstamp != resp->_u._ext.initstamp) {
if (resp->nscount > 0)
__res_iclose (resp, true);
diff --git a/resolv/resolv.h b/resolv/resolv.h
index e49c29d..8f4a202 100644
--- a/resolv/resolv.h
+++ b/resolv/resolv.h
@@ -219,6 +219,7 @@ struct res_sym {
#define RES_SNGLKUPREOP 0x0040 /* -"-, but open new socket for each
request */
#define RES_USE_DNSSEC 0x0080 /* use DNSSEC using OK bit in OPT */
+#define RES_DYNAMIC 0x0100 /* check for changes in resolv.conf */
#define RES_DEFAULT (RES_RECURSE|RES_DEFNAMES|RES_DNSRCH|RES_NOIP6DOTINT)
--
1.7.0.1
From 09551d7225637d3b809ff78ab76739cd7b9d4f63 Mon Sep 17 00:00:00 2001
From: Colin Walters
Date: Mon, 21 Jun 2010 10:33:14 -0400
Subject: [PATCH] Add "options dynamic" to generated resolv.conf
---
src/named-manager/nm-named-manager.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/src/named-manager/nm-named-manager.c b/src/named-manager/nm-named-manager.c
index fc3b6e2..f9bb6fa 100644
--- a/src/named-manager/nm-named-manager.c
+++ b/src/named-manager/nm-named-manager.c
@@ -304,6 +304,10 @@ write_resolv_conf (FILE *f, const char *domain,
char **nameservers,
GError **error)
{
+ /* This tells glibc that we may rewrite the file at any time,
+ * so it should check with stat()
+ */
+ const char *options_
Re: gethostbyname() and resolv.conf updates
2010/6/21 Pádraig Brady : > > Sorry I haven't been following this really, but I loath > config options that aren't absolutely required, and this > seems like a place where we could just stat() (cache) always. > What's the problem with doing that? I too would be really interested in any real-world application for which the cost of the stat() was any kind of major performance hit. > p.s. not having looked at the code, > the atomic ops seems unusual in the > presence of the static last_... variables. We are implicitly relying on aligned word size assignment atomicity here it looks like, yes. I haven't looked if there are other places in glibc doing this or if there's some infrastructure for it. To be clear this patch is derived from the OpenSUSE one; I didn't change the semantics there. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpath handling
Hello internet, So I lost yesterday and part of today to what I thought was a libtool bug, but turned out to be an interaction with Fedora's current primary recommendation for rpath handling: http://fedoraproject.org/wiki/RPath_Packaging_Draft The main recommendation is to use sed to reach into libtool's guts, which normally works (well, until libtool changes, then we have a lot of copy and paste to fix, but that's another story). However, glib2 uses a program called "gtk-doc" which requires actually running an uninstalled binary to extract some data from it. This fails with the Fedora rpath handling approach because the rpath is required at build time. Thus, I came up with this fragment of shell, which has a few advantages: # make install here (cd $RPM_BUILD_ROOT; find | while read f; do if file $f | grep -q ': ELF .*executable,'; then chrpath --delete $f; fi; done) 0) It fixes the above problem I had 1) It doesn't precariously depend on libtool's internal variables 2) It handles rpaths generated by build systems other than libtool However, after writing this, it occurs to me that RPM itself ships a check-rpath tool; can we consider defaulting to replacing all rpaths for standard paths? From the draft, I don't see any downsides to this - we wouldn't be stripping rpaths for internal libraries, just stuff in /etc/ld.so.conf*. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpath handling
On Wed, Jun 23, 2010 at 10:04 PM, Toshio Kuratomi wrote: > > What is being run at build time needing which rpath in order to function? The GObject type system as currently designed defines some components (like properties and signals) in C code, and this has necessitated running a binary to extract that data. I would *love* to be in a future where we can rely on the static introspection scanning and don't need to be running a binary, but we're not there yet. > And is gtk-doc running something specially because this is glib2 or is it > running things every single build? (Back in the day, it just extracted > things from source code comments, so I'm not sure what this new behaviour is > doing). Nope, it's always created a binary. [walt...@pocket gobject-introspection (transformer)]$ grep Copyright /usr/bin/gtkdoc-scangobj # Copyright (C) 1998 Damon Chaplin [walt...@pocket gobject-introspection (transformer)] -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpath handling
On Thu, Jun 24, 2010 at 2:11 PM, Toshio Kuratomi wrote: > The > gtkdoc-scanobj program that's being run is compiled each time That program itself compiles a new binary. > What is rpath being embedded into? The binary created above. The rpath refers to the uninstalled shared libraries. > Does some program need > to be put into the rpm and installed onto the end user's systems with an > rpath set? No. > What is the rpath that we don't want stripped out? None in this case; we're fine to strip all rpaths - but only *after* the build process is complete. > Why is > setting LD_LIBRARY_PATH in the build environment not sufficient? Because it's Linux-specific and thus brings us back to the whole problem libtool was supposed to solve. Again, what I'm actually proposing here is that Fedora's build system should by default strip all rpaths for standard paths, not that people copy and paste my different shell goo over and over. I'm just using my different shell goo until we can fix it globally. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpath handling
On Thu, Jun 24, 2010 at 8:57 PM, Toshio Kuratomi wrote: > > So... AFAIK, libtool does solve this which is why I'm wondering why you're > seeing this. Is the package that's giving you problems checked into the > rawhide cvs right now? What changed is simply that I'm using my script "fedpkg-vcs" to inject a git snapshot into the spec file. Because the git tree does not contain pre-built documentation (unlike tarballs) I must run gtk-doc. So that's why it wasn't seen up until now. > Ah -- that sounds better. I'm still not sure why it's needed at all. > though. Why stripping the rpath is needed? Or why I'm trying to make this change in the glib2 spec file? If the latter - it's simple, I'd like to "upstream" as much of my work to automate building from git as possible so I don't need to have forked specfiles just to create testing RPMs. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpath handling
On Fri, Jun 25, 2010 at 11:25 AM, Toshio Kuratomi wrote:
>
> None of the above. Why libtool isn't handling this rpath (and the binaries
> created during the build process) correctly when it does in other software.
No, libtool is adding an rpath fine; see below:
> So if you have the package somewhere I can help you debug the libtool issue
> and see if we need to do this, if there's a new libtool bug, or if there's
> an issue in the way gtk-doc-scanobj is being built in the package.
No, it's not a libtool bug. Please reread my earlier messages, I'm
not sure how I can make this more clear. But I'll rewrite it anyways:
The old glib2.spec:
%build
%configure --disable-gtk-doc --enable-static --with-runtime-libdir=../../%{_lib}
# remove rpaths
sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool
sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
Note that libtool is mangled *before* we run make. This works fine if
we don't need to run gtk-doc during the build (but if we do, as if
we're running from a git snapshot, then we get screwed).
If we strip the rpaths *after* we run make, then we're fine. No
rpaths in the final Fedora glib2 RPMS, but we can still run stuff
uninstalled.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpath handling
On Fri, Jun 25, 2010 at 12:55 PM, Toshio Kuratomi wrote: > > The fact that you have to use those sed lines shows that there's something > wrong somewhere as we normally don't need them to produce rpath-free > binaries if we're using Fedora or Red Hat libtool. Since you have the > ability to commit upstream, please fix glib2's build scripts. What do you mean by "Fedora libtool"? Ohh...I see, we have a patch which does something...that's not entirely clear to me at first glance, and there's no comment, or upstream bug link. As far as using that, note the glib2 tarballs are actually typically created on an Ubuntu system. So... > If you can't figure out how to do that, you can get me a link to your srpm > that shows the issue and I'll take a look. Sure: http://fedorapeople.org/~walters/glib2-2.24.1-1.4.20100625git7cdc592a.fc13.src.rpm (but it really seems easier to me to just fedora-cvs glib2 and inspect it...) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed release criteria additions for F14+
On Wed, Jun 30, 2010 at 4:49 PM, Dave Jones wrote: > On Thu, Jun 24, 2010 at 11:28:16AM -0700, Adam Williamson wrote: > > > * The desktop default update manager must not periodically check for > > updates when the system is booted live, but must periodically check for > > updates when running on an installed system > > tangentally related: > Do we ever respin the live image if there are security updates ? No. This is actually a big flaw in the current installation flow; we need to check for updates as soon as we get online, before the user potentially launches vulnerable apps. Someone working on this would be really nice. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpms/shared-mime-info/devel shared-mime-info.spec,1.84,1.85
On Sat, Jul 3, 2010 at 2:40 PM, Mamoru Tasaka wrote: > Colin Walters wrote, at 07/04/2010 03:23 AM +9:00: >> Author: walters >> >> Update of /cvs/pkgs/rpms/shared-mime-info/devel >> In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv21405 >> >> Modified Files: >> shared-mime-info.spec >> Log Message: >> * Sat Jul 3 2010 Colin Walters - 0.71-3 >> - Requires(pre) on glib, since update-mime-database uses it > > Why is this needed, although calling update-mime-database appears in > %post scriptlet? Ah, it should be Requires(post) I guess? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpms/shared-mime-info/devel shared-mime-info.spec,1.84,1.85
On Tue, Jul 6, 2010 at 10:48 AM, Mamoru Tasaka wrote: > > If you want to avoid potential dependency loop, it should be > Requires(post). Fixed, thank you! -- 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 14, 2010 at 4:11 AM, Hans de Goede wrote: > iscsid is a semi-regular daemon, yet its initscript is special as it > only starts iscsid when needed. Socket based activation is out of the > question as iscsid > is a userspace kernel support daemon. Which needs to be started ASAP, > so that it is ready to do error recovery when the kernel needs it. > > However we do not want to always start it, only when iscsi targets are in use. > So the bash iscsid script has this "beauty" : Move the code into the daemon, and have it exit() if it's not needed? -- 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 14, 2010 at 11:43 AM, Lennart Poettering wrote: > > time which is enabled via "systemd-install" because the admin wanted so, Does it make sense to export iscsid for administrator control? I mean - won't things explode if it's stopped? It's more of a userspace component of the operating system, as opposed to an add-on server that runs on top of the OS like httpd. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Naming issue for meego 1.0 related packages
On Fri, Jul 16, 2010 at 6:26 AM, Chen Lei wrote: > > It seems no guideline forbid us to use tarballs extracted from > upstream repo. I think using git repo for meego packages have more > harm than benefit, because the most important feature for rpm is > people can validate the md5sum of the source tarball easily. But verifying a git tag is really easy too. I just disagree with you; if tarballs are provided, fine - if they aren't, it's trivial to use archives of git tags. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
