Re: Common Lisp apps in Fedora
Kevin Kofler: > Ouch, we weren't aware of all these issues when we approved common-lisp- > controller in FESCo. :-( It was "sold" to us as something great and working > perfectly. I wasn't aware that it didn't actually work at all at this time > and I strongly doubt the rest of FESCo was either. It makes no sense to have > a packaging guideline mandate using something which doesn't work. Jerry James: > The alternative to common-lisp-controller, for libraries at least, is > to have lots of subpackages:... > I can see why Debian went with > common-lisp-controller It helps keep insanity at bay. Common-lisp-controller would probably be very helpful for libraries if it *did* work. But it appears that mandating it was premature. Jerry James: > But I think we need to have an escape clause for applications, and > also for libraries that take a significant amount of time/space to > compile. No escape clause needed for applications. The 2nd sentence of: https://fedoraproject.org/wiki/Packaging:Lisp "This document does not describe conventions and customs for application programs that are written in Common Lisp." I think it should be backed down until it's *really* fixed (awakening upstream as necessary). --- David A. Wheeler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: possible improvements ?
On 09/01/10 00:32, Rawhide Report wrote: Compose started at Fri Jan 8 08:15:04 UTC 2010 Broken deps for i386 -- ... >ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 >ghc-HTTP-devel-4000.0.6-6.fc13.i686 requires ghc = 0:6.10.4 >ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 >ghc-HTTP-doc-4000.0.6-6.fc13.i686 requires ghc-doc = 0:6.10.4 >ghc-HTTP-prof-4000.0.6-6.fc13.i686 requires ghc-prof = 0:6.10.4 >ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 >ghc-cairo-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 >ghc-cairo-prof-0.10.1-5.fc12.i686 requires ghc-prof = 0:6.10.4 >ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 >ghc-cgi-devel-3001.1.7.1-3.fc13.i686 requires ghc = 0:6.10.4 >ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 >ghc-cgi-doc-3001.1.7.1-3.fc13.i686 requires ghc-doc = 0:6.10.4 >ghc-cgi-prof-3001.1.7.1-3.fc13.i686 requires ghc-prof = 0:6.10.4 >ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 >ghc-fgl-devel-5.4.2.2-1.fc12.i686 requires ghc = 0:6.10.4 >ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 >ghc-fgl-doc-5.4.2.2-1.fc12.i686 requires ghc-doc = 0:6.10.4 >ghc-fgl-prof-5.4.2.2-1.fc12.i686 requires ghc-prof = 0:6.10.4 >ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 >ghc-gconf-devel-0.10.1-5.fc12.i686 requires ghc = 0:6.10.4 Hi, I noticed that some broken ones are duped (usually together), making it look like there is nearly twice as many as there really is. Would sort -u dedupe those ? Also, it could be cleaner and easier to read to invert or summarize the unsatisfied requires like: Broken dependencies: ghc-HTTP-devel-4000.0.6-6.fc13.i686 ghc-cairo-devel-0.10.1-5.fc12.i686 ghc-fgl-devel-5.4.2.2-1.fc12.i686 ghc-gconf-devel-0.10.1-5.fc12.i686 ghc-cgi-devel-3001.1.7.1-3.fc13.i686 all require ghc = 0:6.10.4, which is not available. or ghc-doc = 0:6.10.4 is not available, but is required by: ghc-HTTP-doc-4000.0.6-6.fc13.i686 ghc-cgi-doc-3001.1.7.1-3.fc13.i686 ghc-fgl-doc-5.4.2.2-1.fc12.i686 It might be nice to see the headings indented, and the package n-v-r-a info not indented, (since long package names, makes for more difficult to read emails, due to replies inserting quoting (> ) characters and oveflowing a single line. Also the report subject could include say '-' separators between y, m, day, like 2010-01-08 (which is another variant of the iso format that still sorts by date nicely ;) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: Never, ever steal focus.
On Thu, Jan 07, 2010 at 03:17:45PM +, Zing wrote: > On Thu, 07 Jan 2010 07:58:11 +0100, David Tardon wrote: > > > >> gconftool-2 -s -t string /apps/metacity/general/focus_new_windows > >> strict > > thanks for that... > > >> To be useful - when that's set, new windows never take focus away from > >> a window that looks like a terminal window. (This is assuming the above > >> opens a new window. If it changes an existing window, then > >> "focus_new_windows" won't affect the behavior.) > >> > >> > > Doesn't work. I set this, then started gedit from gnome-terminal. The > > gedit window got focus. > > Are you sure you didn't have another gedit window open. It seems to work > as Owen mentioned (only if you don't have an existing window open)... > it's so close to what I needed, unfortunately I always keep a browser > open in the background. > Definitely not, I use gedit as a test application only. But I see what's the problem now--it only works from freshly started terminal. So all the terminals that were running at the moment I set focus_new_windows to strict didn't pick that setting and continue to open new windows focused. Isn't that a bug in gnome-terminal (or metacity)? D. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about dist-cvs make targets
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 7 Jan 2010, Jesse Keating wrote:
As I proceed to port our make system over into fedpkg, I've ran across a
couple targets that are giving me pause.
Is anybody out there making use of the following targets?
check
export
patch
unused-patches
unused-fedora-patches
If so, please reply to which one, and in what scenario you use those
targets. Thanks!
I was using 'unused-patches' until the packaging guidelines had us change
Patch lines to use %{name} if that applied. The unused-patches target would
be helpful if it could expand RPM macros.
That may have changed now. I haven't checked it in a while.
- --
David Cantrell
Red Hat / Honolulu, HI
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.13 (GNU/Linux)
iEYEARECAAYFAktGHxAACgkQ5hsjjIy1VkkA8ACeIRILiiyrMYGvRIf/HW4/C1Rh
wK8AoLRRd0JWEftiXv7Vqpop0LLG1eXg
=Ix6d
-END PGP SIGNATURE-
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: Never, ever steal focus.
> > gconftool-2 -s -t string /apps/metacity/general/focus_new_windows strict > > To be useful - when that's set, new windows never take focus away from > a window that looks like a terminal window. (This is assuming the above > opens a new window. If it changes an existing window, then > "focus_new_windows" > won't affect the behavior.) > Doesn't work. I set this, then started gedit from gnome-terminal. The gedit window got focus. D. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Common Lisp apps in Fedora
On 01/04/2010 05:29 PM, Jerry James wrote: > One of the first issues we'll have to face is the use of > common-lisp-controller. > First, it postpones compilation to the first time the application is > executed by a particular Common Lisp engine. For the application I > packaged, PVS [2], compilation takes a significant amount of time. > This approach may be fine for small libraries and applications, but > will it really scale up to the some of the big applications people > want to package? No. That'd be rediculous; big CL applications can take a LONG time to compile, and compilation usually requires lots of memory (even if the final application doesn't). Fedora has lots of applications written in many other compiled languages like C and C++, and they aren't distributed *only* as source code. Instead, people expect that when they download the binary they'll get a pre-compiled, ready-to-go version. I think the same should be true for big Common Lisp (CL) applications. If you want a distribution that requires you to recompile *everything* from scratch, go to Gentoo or similar. There should be pre-compiled versions of large CL applications, as maxima-sbcl is right now and the upcoming pvs-sbcl will be. Alexander Kahl: > Are you (or is anyone else here) interested in founding a Common Lisp SIG? I'm interested. --- David A. Wheeler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: installing 64-bit kernel on a 32-bit system (nouveau issue?)
On Sat, 2010-01-02 at 12:39 +0100, Roberto Ragusa wrote: > Now, consider this: > > (c) 64 bit kernel + 32 bit apps: this is simply an extreme case of (b), > a 64/32 system where every app is 32. > > Case (c) is interesting because: > > - you can switch a 32 bit install to this mode by simply installing a 64 > bit kernel (and switch back at grub level any time you want) > > - the 64 bit kernel can handle all your memory better (faster) than 32 > or 32+PAE kernel > > - you avoid the increased memory consumption of 64 bit apps (pointers > are wider; there is big debate how much this impacts performance and > if it is able to demolish the other improvements of x86_64 such as > more regusters and SSE2 guaranteed avalability). Add to this that > when you run 32 and 64 bit apps together you have both versions of the > system libraries in memory, so the mem usage is higher. > > Finally, the discussion is: > case (c) _SHOULD_ work perfectly in theory (see case (b)), but apparently > there are a couple of bad spots for things no one ever run in 32 bit > mode on 64 bit kernel. We do that on PPC64. We have 32-bit userspace by default with a 64-bit kernel. Only applications where 64-bit is actually _worthwhile_ are 64-bit. On PowerPC we don't have to worry about being starved of registers in 32-bit mode, so the benefit of 64-bit userspace is much more limited. It's really only beneficial where you really need to address more than 4GiB of RAM, or do 64-bit arithmetic. So in the _general_ case, most of the 32-bit-userspace-on-64-bit-kernel stuff ought to be working fine. That compatibility mode in the 64-bit kernel ought to be fairly well tested. Obviously that doesn't count for the nVidia binary module, which doesn't exist for ppc64. And nouveau is relatively new and not currently being used in Fedora/PPC64 so I'm prepared to believe that their 'work in progress' API still has some issues in that area, as you suggest. -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: All I want for Christmas is digiKam 1.0 in F12-stable...
On 12/22/2009 09:15 AM, Ryan Rix wrote: On Mon 21 December 2009 10:46:51 am Rex Dieter wrote: I'd feel a bit uncomfortable without at least some testing and positive feedback. Once people try testing Rex's updated package, please provide feedback at Rex's link about it, eg what's working, not working about this build ? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot - semi-off -topic response
On 12/17/2009 08:38 AM, Jon Masters wrote: > On Wed, 2009-12-16 at 16:30 -0500, Przemek Klosowski wrote: > >> too. My own preference would be a more discriminating dialog >> that offers three possibilities: 'do nothing', 'bounce the >> service/application' and 'reboot'. > > Yup, +1 Bounce the application would be really cool for eg firefox, thunderbird, that continue to work, but some things sort of don't (like new popups dont open and so forth). In doing so the application would need to return to the identical locations, arrangements that it was bounced from. And really, the above shouldn't be difficult for a computer to do: - have window, pos,size, doc open, caret position and so on, even those pesky web forms with unsubmitted data and so on. Make it part of the freedesktop standards - an app forcibly closed or ?disappears shall reopen as if nothing changed ! (although firefox multi-tab and working out which tab not to reopen after a crash is a good game). Make open documents files etc, be always stored immediately on change with snapshots at each save to disk, few minutes of operation etc. Make it like paper, but actually better, you know: what is written on paper doesn't mysteriously disappear when an update or a power failure, or app crash occurs, nor does it disappear from where you left it. I think the above scenario for user apps would seem to be a reasonable goal. On the other hand, services are not so clear cut. If I'm an external user logged into the web service, filling a form, I don't expect even momentary downtime to cause me to lose information I'm entering, or corrupt a file I have open / editing on network share (though see the works better than paper description). In the first example, would it make sense for the web server to start all new processes using the new updated code, while existing users stay connected to the existing instance, until these timeout/logout and no user's connection is using the old code. When a reboot is really needed, a PK dialog could inform of the need, and ask when that could occur (do at 4:30 am tueday morning) ps: did gnome desktop regain the feature of autologin and rerun apps on desktop capability of pre f-10 ? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 1 complete
On Mon, 14 Dec 2009, Jesse Keating wrote: In my effort to create a proof of concept for using git to manage our package source control, I have completed what I am calling phase one, that is taking our current dist-cvs and converting it into git format. pkgs/rpms//devel is now the git origin/master. All release subdirs have been turned into git branches. History back to F7, as well as the EPEL branches have been converted, from a snapshot of the CVS tree I took last week. Having trouble cloning at the moment, but wanting to take a look at a few packages in git. Are there any plans to import history back to FC-1? Since we're changing version control systems, it's a nice opportunity to get this in to the version control system. Complete history is nice to have on occassion. Currently I only have anonymous git:// access setup, as we play with some options for authenticated writing. If you wish to play around with the repos, you can access it via: git://publictest5.fedoraproject.org/git/pkgs/ eg if you wished to clone the kernel, you'd type: git clone git://publictest5.fedoraproject.org/git/pkgs/kernel Give it a spin, see what you think. -- David Cantrell Red Hat / Honolulu, HI -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Request for help maintaining packages while away.
On Wed, 2009-12-09 at 19:39 -0500, Paul W. Frields wrote: > On Wed, Dec 09, 2009 at 12:38:11PM -0900, Jeff Spaleta wrote: > > On Wed, Dec 9, 2009 at 12:26 PM, Paul W. Frields > > wrote: > > > Jef, I'll help with istanbul. If anyone else out there is considering > > > doing so, please feel free to team up with me. > > > > Other than revelation(which essentially has a dead > > upstream)...Istanbul is probably the most in need of more development > > love. Upstream seems to be inactive with no release activity in quite > > a while. There's a lot of deprecation warnings for some pygtk calls > > that I would love to clean up in time for F13. And there are a couple > > of abrt crash tickets being spawned by istanbul.. which maybe traced > > back to gdk libraries calls if I'm reading the crash dumps correctly. > > Dave Malcolm was looking at an underlying GTK (or maybe GDK?) bug this > weekend at FUDCon if memory serves. I'll also do what I can for > existing bugs in my Copious Spare Time(tm). I spent some time trying to figure out bug 543278 but got stumped; need a GTK maintainer's help with this one; pygtk appears to be correctly passing the --sync flag on to GTK fwiw [snip] -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: example content
On Mon, 2009-11-23 at 14:15 -0500, Matthias Clasen wrote: > Hey, > > one change we are planning to make to the desktop spin in F13 is to go > from targeting a cd to targeting a 1g usb stick. Why 1GB? It seemed to me, when discussing this earlier on this list, that everyone agreed that 2GB made much more sense. Thanks, David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: brp-python-bytecompile
On Fri, 2009-11-20 at 09:53 -0700, Jerry James wrote: > I'm looking into the build failures Matt identified. With my shiny > new Rawhide VM, I'm seeing this output on a local build of a package > with no python sources: > > [ ... successful build messages ...] > + /usr/lib/rpm/brp-python-bytecompile > Bytecompiling .py files below [BUILDROOT]/usr/lib*/python*/ using > /usr/bin/python* > Usage: /usr/bin/python-config > [--prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--help] > Usage: /usr/bin/python-config > [--prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--help] > + /usr/lib/rpm/redhat/brp-python-hardlink > [ ... successful build messages ...] > > The rpm build is completing, so I'm not worried about this particular > package. Is this going to cause problems with packages that do have > python sources, or is this just because nothing matches > /usr/lib*/python*/ in the build root? It looks like python_binary = > /usr/bin/python*, which can match any of these: > > /usr/bin/python > /usr/bin/python-config > /usr/bin/python2 > /usr/bin/python2.6 > /usr/bin/python2.6-config > Sorry; looks like my fault. I updated /usr/lib/rpm/brp-python-bytecompile to better cope with the python 2 vs python 3 split; this was in: https://bugzilla.redhat.com/show_bug.cgi?id=531117 >From my reading, what's happening is that I coded it with the (incorrect) assumption that files exist which match $RPM_BUILD_ROOT/usr/lib*/python*/ When at least one such file exists, I believe the shell expands the glob and thus we iterate over the library subdirectories, byte-compiling all .py files in them with the appropriate version of python. When no such directory exists, the shell fails to expand it, and retains it as the text string: your_build_root/usr/lib*/python*/ and thus one iteration of that loop happens, and we get the two error messages. So I believe this is harmless but messy. Filed as https://bugzilla.redhat.com/show_bug.cgi?id=539635 Sorry for any confusion. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Review request...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Nov 18, 2009 at 10:24 PM, Nathanael D. Noblet wrote: > On 11/18/2009 06:23 PM, Kevin Kofler wrote: >> >> Michael Schwendt wrote: >>> >>> Many packagers don't know that maintaining a proper spec %changelog for >>> relevant spec file changes and %release bumps are considered important >>> during review already. Others add meaningless/dummy %changelog entries >>> even in Fedora cvs. >> >> But that's a people issue that needs to be solved, not papered over in the >> name of "being nice". >> >> Sadly, "incompetence" as in unfamiliarity with guidelines which are >> assumed >> to be prerequisites for proper packaging is growing in our ranks (both >> from >> new packagers and from people who ought to know better), something needs >> to >> be done about it. > > For sure. Personally I've been using Redhat/Fedora for years now, but this > is my first package submission to fedora. I've wanted to get involved for > awhile now. I had read the guidelines, and honestly want to provide a > properly configured package. I think (and this very well could have been a > language issue) that knowing what the issue I'm missing in my current spec > would help immensely. I mean I know there are packaging guidelines, and > there is a lot of information there, so it is plausible for someone new not > to see sub documentation or notice that their spec isn't in compliance. > Having the exact issue pointed out helps with the learning. Is there a > 'ReviewingReviews' guideline? Would that even help? > > Anyway, I hope to get some feedback on the actual review too, but I mainly > started this thread because I wasn't sure what I wasn't doing. I was asked > for a scratch build which I *thought* I had provided a link to. I provided > links to spec files and srpms. However was continually being asked for that > same thing, and the requests and my responses were obviously not being > understood by either party. I posted to make sure I wasn't missing something > obvious, some guideline of 'Here's how to post your spec file, srpm and > scratch build', if I wasn't doing it correctly. > > Sincerely trying to provide the best package I can, > Nathanael > There is a Review Guidelines page that is supposed to be the basis for package reviews: http://fedoraproject.org/wiki/Packaging/ReviewGuidelines but they honestly only scratch the bare minimum of the full set of Packaging Guidelines. My take, as a comparatively inexperienced packager, is that packaging is such a wide ranging subject that it's not something that you can gain proficiency at without gaining the experience of doing it a lot, and in the process failing a lot and learning from the failure. 6 months from now, you'll likely look back on your first few packages, as I did, and wonder 'how did that ever pass the review process?', or 'what was my sponsor thinking when he approved of me?'. The packaging guidelines, are honestly sooo voluminous, and also so scattered, that it's an interesting problem for new packagers, and the getting started as a packager documentation is the same way. Much of that could be improved (and at one time there was an effort going on towards that end.) but it will never become 'easy'. In the end, don't hesitate to ask for help or say you don't know. Part of the process is learning how to become effectively lost. Failure, within Fedora is OK, and even encouraged, provided you correct it and learn from it. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.10) iEYEARECAAYFAksEwFIACgkQkZOYj+cNI1fNxACgqS4lso7EkKaCpmGURK0G0TZH s24An0ryEFUdt8sE1TgvOScN9hJKRC7w =PBdd -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On Wed, 2009-11-18 at 10:47 -0500, Chris Ball wrote: >> Also, what is the mechanism to configure this? Just a simple >> command from btrfs-progs (best)? Or does it require surgery to >> /etc/fstab and/or the initramfs (bad)? > > Josef's been thinking about exactly that -- the current situation > requires you to add subvol= to the mount args, which > indeed would require you to change fstab (for non-rootfs) or to add a > rootflags= argument to the grub menu (for rootfs). He's considering > changing the btrfs disk format to add a "default subvolume for this > fs" field that would lead us to a simple btrfsctl command for setting > that field instead. I agree that his solution's what we'd like. OK, sounds good to me. I'm subscribed to the btrfs-list so I guess I'll just sit around and wait for Josef's patch to show up. Thanks, David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Thu, 2009-11-19 at 00:34 +0530, Rahul Sundaram wrote: > On 11/19/2009 12:31 AM, nodata wrote: > > > > Rahul, it seems to be that the person who made this change (fesco > > approved?) is the one who should answer why the change is a good thing, > > rather than "oh I changed it, now tell me why it's bad". Do you know who > > it was? > > I don't see why FESCo should be involved and I have no idea who made > this decision. I would have preferred the change to be announced and > documented in detail regardless of that. I assume David Zeuthen? (CC'ed) Jeez, Rahul. This has nothing to do with polkit per se, only PackageKit and how it decides to use polkit. I've commented that much in the bug. And as noted in the bug I don't even agree there's a problem. But I leave that to Richard and others to sort out. Btw, please don't add me to the Cc again like this or reply to this - I'm not interested in this bike-shed or what color it is. Thanks. David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On Tue, 2009-11-17 at 23:34 -0500, Chris Ball wrote: > Given the above, do you think you'd be okay with having: > >Filesystem snapshot that will be active on next boot: Shouldn't it say "next time volume is mounted" instead of "next boot"? We can always special case rootfs to say "next boot" of course (since rootfs can't be unmounted until next boot). Also, what is the mechanism to configure this? Just a simple command from btrfs-progs (best)? Or does it require surgery to /etc/fstab and/or the initramfs (bad)? >Create new whole-filesystem snapshot now: > > in a Btrfs-specific section in Palimpsest? That's all that's needed > for the UI component of this feature. >From a 50,000 feet view all this sounds good to me. >> (Oh, and if it turns out that creating/destroying btrfs snaphots >> isn't a privileged operation (I can't remember at this point) it >> would probably make sense for Nautilus to just use the btrfs >> tools directly instead of going through a system daemon. There's >> just no need to overcomplicate things.) > > Creating a new snapshot is unprivileged, but mounting an old one > (which nautilus would need to do in order to show you the contents > of a previous snapshot, so that you can decide which files you want > to restore from it) requires a mount(8) call for each snapshot. OK. We need to decide how all this is going to work - maybe some of it will go into GIO and be part of an abstraction that also works for other filesystems, maybe it will be a Nautilus-only feature. I don't know yet, leaning towards the latter right now, but I guess we'll find out. Thanks, David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
(I'm not subscribed to fedora-devel-list so if you expect an answer please Cc me) On Tue, 2009-11-17 at 09:52 -0500, Chris Ball wrote: > * Ray says not to invent a new system-config-blah, and instead to talk > with davidz about Palimpsest. David, what do you think? Yep, we're planning to add support to DeviceKit-disks for exposing the (privileged) operations that btrfs may expose (locked down by polkit, etc etc). There are also plans to expose these operations in the UI in Palimpsest and/or Nautilus. I don't think snapshots is going to have any Palimpsest UI (it belongs in Nautilus I think) but the multi-disk stuff definitely will. As always, DKD and Palimpsest is supposed to be complementary to the command-line tools. So all this is only relevant for creating nice UIs for managing btrfs. (Btw there's still some work needed in udev/blkid (but hopefully not in the btrfs on-disk format) to properly export everything we need - e.g. things like number of block devices in the multi-disk filesystem, maybe the "raid" level and so on. I haven't gotten around to looking at this in detail yet. It's on my TODO list though.) > * Several people think that the ZFS Time Slider patches to nautilus¹ > look good, and want that for btrfs. Sounds plausible², People hacking on Nautilus will have to look into this with both ZFS, btrfs and possibly other filesystems in mind. I haven't seen anyone do work like this and it's not trivial. (Oh, and if it turns out that creating/destroying btrfs snaphots isn't a privileged operation (I can't remember at this point) it would probably make sense for Nautilus to just use the btrfs tools directly instead of going through a system daemon. There's just no need to overcomplicate things.) David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
RE: Identifying remaining core font users
I have a bigger problem with this, I use fedora boxes to talk to older devices (solaris 2.6 and M88KV4 unix machines) that can never be upgraded to newer X clients. Since the fedora ( or any xorg) servers are talking to "classic" X11 clients dropping support for core fonts is a huge issue. The clients are running on the host computers for flight simulators. The clients are built on 3rd party libraries that date from the early 90s. As the existing Xterms (Tek/NCD ) fail we are replacing them with newer linux based thin clients, but we still need "classic" X11 font support. The programming support is done on solaris and linux boxes the need to display the same layouts as the xterms dave -Original Message- From: fedora-devel-list-boun...@redhat.com [mailto:fedora-devel-list-boun...@redhat.com] On Behalf Of Richard W.M. Jones Sent: Wednesday, November 11, 2009 9:38 AM To: Development discussions related to Fedora Subject: Re: Identifying remaining core font users On Wed, Nov 11, 2009 at 04:41:32PM +0100, Nicolas Mailhot wrote: > It seems the people maintaining text libs are not interested in backends > that fail if you use codepoints outside a specific encoding, or when you > use the "wrong" font (because encoding is just one part that changed, > OpenType "smart" features such as ligatures and swashes mean that even > if you restrict yourself to basic latin nowadays a modern font won't > behave like a "simple" ASCII font used to ten years ago). Probably > because they know that if they limited themselves users would ask for > the missing bits anyway. > > Projects that find modern text libs over-complex should try to maintain > their own "simple" alternative (or pick up the maintenance of the X11 > Core fonts system). I suspect they'd quickly find themselves in > agreement with current text lib maintainers. > > So really, it's just a matter of delegation: if you don't want to > maintain your own text stack, follow the advice of the people > maintaining the one you use, and the advice of X11 Core fonts > maintainers (back when there were still some, in 2003) was clear: drop > it and use fontconfig instead. Yes ... but ... we're talking mainly about demos and examples written for beginners. --- hello.ml -- #!/usr/bin/ocamlrun ocaml #load "graphics.cma";; open Graphics let () = open_graph " 200x150"; set_font "-*-times-*-r-*-*-*-240-*-*-*-*-*-*"; auto_synchronize false; while true do let x, y = ref 50, ref 80 in List.iter ( fun c -> moveto !x !y; let rand () = Random.int 256 in set_color (rgb (rand ()) (rand ()) (rand ())); draw_char c; x := !x + 24; if c = ' ' then (y := !y - 24; x := 50) ) [ 'H'; 'E'; 'L'; 'L'; 'O'; ' '; 'W'; 'O'; 'R'; 'L'; 'D'; '!' ]; synchronize () done --- Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: help debugging segfault with alienarena 7.32
On Tue, 2009-11-03 at 11:45 -0500, Tom "spot" Callaway wrote: > I need to rebuild alienarena for all targets due to a security issue, so > I decided to update to 7.32, but unfortunately, the 7.32 build segfaults > immediately on Fedora 12 (x86_64), and gdb isn't much help (gdb output > is at the bottom). FWIW, it looks like the backtrace is within the C++ start-up code that runs all non-empty constructors for global C++ variables, which gets called before "main" starts for a C++ program. Does (gdb) break call_init before (gdb) run give you a working breakpoint? [snip] Hope this is helpful Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Installing F12-Beta
On Mon, 2009-11-02 at 15:47 +0800, Steven James Drinnan wrote: > David why you are so upset? No need to get nasty. I simply posted a > message about my problems installing F12. I did not Hijack any thread > (see the subject name). I thought this was a public forum. I sent this > to the whole mailing list. My apologies if I offended you. I'm not upset, and wasn't nasty. I was just trying to help you communicate more effectively, and without adding noise to other discussions. You _did_ hijack the thread -- you replied to Adam's message, using your 'reply' button instead of composing a new message to the list. Your mail is clearly marked, in its headers which I quoted, as a reply to that previous message -- as part of that older thread. It should have been a _new_ thread, not a reply to the existing thread. Please don't do that. And, while we're at it, please don't top-post either. And please remember to quote only what you actually need for context rather than repeating the _whole_ of the message to which you're replying. You may find http://david.woodhou.se/email.html to be useful reading. > All I can tell you is what happened. > > Which is I put the DVD in the drive and after a while it came up with a > recursive error and said it was fixed but needed to restart the > computer. You _still_ didn't actually post the precise text of the error you saw, along with any output leading up to it. It's almost as if you don't _want_ people to be able to help you. Now that you posted the actual bug number rather than just teasing us with "I put it in bugzilla but I'm not telling you where" as you did in your previous mail, I can see that you didn't post the full error there, either. Please, show us the words you actually see on the screen -- or take a photo, perhaps. -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Installing F12-Beta
On Mon, 2009-11-02 at 08:29 +0800, Steven James Drinnan wrote: > In-reply-to: <1257111085.2314.154.ca...@adam.local.net> > References: > <1257111085.2314.154.ca...@adam.local.net> Steven, please could you explain the relationship between your message on 'Installing F12-Beta' and the message to which you replied, which was about upstream developers becoming co-maintainers. If there is no relationship, then you've just hijacked an existing thread by posting your unrelated query as a reply to it -- please don't do that. You may also find that you'll get more help if you provide a more coherent bug report. You neglected to give any useful details about the error you see. Giving the full error message might have helped. Or even telling us at which stage of the boot it happens might have given a clue. I'd look in the bug you filed to see if you provided that information there... but you didn't even bother to tell us the bug number. My crystal ball isn't working today, so I _couldn't_ help you, even if I _didn't_ have a policy of not helping thread-hijackers until they post their problem politely ;) -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora PPC for oldworld Mac?
On Wed, 2009-10-28 at 22:25 -0400, Tony Nelson wrote: > On 09-10-28 18:24:49, Josh Boyer wrote: > > On Wed, Oct 28, 2009 at 06:17:31PM -0400, Tony Nelson wrote: > > >Sorry to bug developers, but I didn't get any bites from PPC > > >users on fedora-list. > > > > > >Does Fedora PPC work or install on oldworld PCI Macs, such as > > >a beige G3 desktop? My impression is that no one has tried it > > >on an oldworld > > > > > > No, it doesn't. The ppc specific release notes cover that here: > > > > http://docs.fedoraproject.org/release-notes/f11/en-US/ > > index.html#sect-Release_Notes-Hardware_Requirements > > I'd looked at the release notes. They says "Minimum CPU: PowerPC > G3..." and "Although Old World machines should work, they require a > special bootloader which is not included in the Fedora distribution." > My question is whether anyone has tried it in any recent Fedora > release and knows whether "should" means "do" or "don't". > > (FWIW, the special bootloader is BootX, and Debian Lenny is installing > now, so /some/ form of Linux works. I just don't know anything but > hearsay about Debian. I see it uses "apt".) I don't know of anyone who's tried it recently, but in the past we've fixed things in the kernel to make it work properly on OldWorld Macs and it _has_ been known to work fine. It _ought_ to work if you sort out the bootloader. -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: mass rebuild and i586 rpms - glglobe
On 10/20/2009 08:48 PM, Milos Jakubicek wrote: http://mjakubicek.fedorapeople.org/need-rebuild.html hmmn, glglobe is mine, wonder what went wrong. It seems that the build logs are no longer available ? https://koji.fedoraproject.org/koji/taskinfo?taskID=1504772 eg for: x86_64 (red) https://koji.fedoraproject.org/koji/taskinfo?taskID=1516629 And the other 3x orange ones appear to mean cancelled, is that correct ? Wonder whether they were cancelled manually (ie the whole rebuild) ? Or did the fail on one arch trigger the cancels ? Anyway, a scratch build (without change) succeeds: https://koji.fedoraproject.org/koji/taskinfo?taskID=1766626 Should I bump and rebuild, or just re-request the same build ? Should I request it to be in F-12 ? (the i586.f11 one that is in f-12 beta (rawhide) works OK). DaveT. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Eternal 'good file hashes' list
On 10/21/2009 07:47 AM, Ralf Ertzinger wrote: Hi. On Tue, 20 Oct 2009 17:40:46 -0600, Stephen John Smoogen wrote: In most cases, you can get that information from the original RPM compared to the system... if you have the RPM :). rpm -Vp Which is pretty much what I want, just pulling the data from an external (signed) source instead of the local RPM database. Sounds familiar. Solaris Fingerprint DB, anyone? http://sunsolve.sun.com/fileFingerprints.do Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Thunderbird 3.0rc1
On 10/19/2009 3:05 PM, mcloaked wrote: > David gmail.com> writes: > >>> I presume that it will go out with GLODA and smart folders turned OFF? >>> >> >> GLODA - Global Search and Indexer - is defaulted disabled from >> Mozilla. I am forever seeing users talking about having 'emails going >> back years' and this feature would help in searching for that question >> and answer that might solve a problem. And once indexing is done the >> first time it is not a 'machine stopper' to use it enabled. >> >> However you don't need it if you only want to count the emails and never >> search them. > > I don't know if you saw the rather extended thread recently concerning the > release of thunderbird 3.0b4 but there were significant problems with GLODA. > Having it off by default and make sure users are informed that it is > available is the better way to do things - however in 3.0b4 it was ON > by default and caused a huge headache for users with significant volumes > of mail across multiple accounts. > > I'll refer to the thread if you missed it. I had no problems with Thunderbird 3.0b4 or any of the nightly builds that have lead up to it. Once or twice over the many months I had a 'bad day' but it was corrected by the next night's build. I should say that these are Mozilla nightly builds and not Fedora's. I currently am using 3.0pre dated Oct 19, 2009. I turned on GLODA as soon as it was available. It took some time to complete the first time. From then on it takes nothing that I can never notice unless I see the information show up in the activity notification area. As for the thread you mentioned? I saw that I seem to recall that no one really had a problem other than the amount of time it took to do the indexing the first time. But I did not find that a major problem or experience any others with the 3.0b4 series. And to repeat myself - these were *not* Fedora supplied packages. They came directly from Mozilla. I also get my Firefox nightly-build packages directly from Mozilla. Mozilla does not force all of those language packages on me as Fedora does. :-) But seriously if you think that this is really important you should write a Bugzilla on it so that the maintainer(s) will know about this. Writing to a mailing list normally only generates message threads. -- David signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Thunderbird 3.0rc1
On 10/19/2009 12:58 PM, Mike Cloaked wrote: > Julian Sikorski gmail.com> writes: > >>> Will a build of Thunderbird 3.0rc1 be pushed to updates-testing for F11 >> when it is released? > >> What makes you think it won't? >> >> Julian >> > > I did wonder what the process would be after all the kerfuffle with TB3.0b4 > > I presume that it will go out with GLODA and smart folders turned OFF? > GLODA - Global Search and Indexer - is defaulted disabled from Mozilla. I am forever seeing users talking about having 'emails going back years' and this feature would help in searching for that question and answer that might solve a problem. And once indexing is done the first time it is not a 'machine stopper' to use it enabled. However you don't need it if you only want to count the emails and never search them. ;-) -- David signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Sat, 2009-10-03 at 22:09 +0200, yersinia wrote:
> On Thu, Oct 1, 2009 at 7:15 PM, David Malcolm
> wrote:
[snip]
> $ rpm -qf /usr/lib/python2.*/site-packages/* | grep -v "is not
> owned" |
> SIA, this is off of topic , i am sure. BUT, it is very strange that
> could be exists, perhaps, some file or directory not owned by
> someone. Isn't it ?
FWIW I've done a lot of packaging experimentation on that system, and
brute-force copying of .py files into place, so there's a fair amount of
"cruft" lurking about on my system. That's why I had that in the shell
pipeline I gave. (But yes, this is heading off-topic)
>
> sort | uniq | xargs rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}
> %{SOURCERPM}\n" | sed -e"s/.src.rpm//" | squeal -f table col0,
> col1 from
> - where col0 != col1
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: wmii window manager
On 10/03/2009 07:12 PM, Ilyes Gouta wrote: Do we have wmii (a window manager, http://wmii.suckless.org) packaged for Fedora? Not that I can see for f11 or rawhide. Would you like to begin packaging it ? DaveT. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, 2009-10-01 at 13:15 -0400, David Malcolm wrote: [snip] (replying to self, with some archive links) > An earlier proposal about python 3 in Fedora is here: > https://www.redhat.com/archives/fedora-devel-list/2008-May/msg02417.html ...which was the "Let's make a plan for python3.0 in Fedora 10+" thread. FWIW, looking back in the logs there was also: "python-2.6 and python-3.x" ( https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00085.html ) and further back: "The looming Python 3(000) monster" https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00379.html [snip] -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, 2009-10-01 at 19:12 -0400, Ben Boeckel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> David Malcolm wrote:
> > "Naming convention" proposal:
> > How does this sound:
> > - an rpm with a "python-" prefix means a python 2 rpm, of
> the
> > "default" python 2 minor version (for Fedora this will be the
> most
> > recent stable upstream minor release, for EPEL it will be the
> minor
> > release of 2 that came with the distro, so 2.4 for EPEL5)
> >
> > - an rpm with a "python3-" prefix means a python 3 rpm, of
> the
> > "default" python 3 minor version (for Fedora this will be the
> most
> > recent stable upstream release)
> >
> > (we could extend this to have specific minor-releases (e.g.
> use
> > "python24-" for a python 2.4 stack, in case some brave soul
> wants to get
> > zope/plone running. But may be better to try to fix the
> zope/2.6
> > incompatibility at that point (caveat: haven't looked at the
> details of
> > the issue). I don't intend to work on such versions))
> >
> > What about packages without a "python-" prefix? Proposal: If
> upstream
> > has a naming convention for python2 vs python3, use it.
> Otherwise, add
> > a "python3-" prefix to make things clear. I'm not sure about
> the
> > details here. Examples?
> >
> > There have been various discussions upstream about what to
> call the
> > python 3 binary. My favorite quote on the subject is from
> Guido,
> > http://mail.python.org/pipermail/python-3000/2008-
> March/012421.html :
> >> During the next 3 years or so, installing Py3k as the default
> "python"
> >> will be a deed of utter irresponsibility and is likely to
> break your
> >> system in subtle ways (both OSX and Linux these days use
> Python for
> >> certain system tasks). If you *really* want to shoot yourself
> in the
> >> foot this way, go ahead and explicitly use "make altinstall
> >> bininstall" or link it yourself.
> >
> > I propose that for Fedora we have "/usr/bin/python3" for the
> > system/default version of python 3 and "/usr/bin/python" for
> the
> > system/default version of python 2. Both would be symlinks to
> a binary
> > with the minor-release embedded in the name
> ("/usr/bin/python3.1" and
> > "/usr/bin/python/2.6").
> >
> > As I understand things, this should make us broadly in
> agreement with
> > upstream; see e.g.:
> > http://mail.python.org/pipermail/python-dev/2009-
> April/088862.html
> > http://mail.python.org/pipermail/python-dev/2009-
> April/04.html
>
> Could we do something similar to what qt and kdelibs packages
> have done? While qt3 was default, the 'qt' package points to qt3
> and qt4 is an entirely separate package. When qt4 became
> default, qt3 was the one with the explicit version on it (and
> qt4 still exists, but the default 'qt' is qt4 now). This would
> mean that python2 packages grow 'Provides: python2-foo =
> %{version}-%{release}'. When python3 is the default, then have
> python point to python3 (and we can drop the Provides/Obsoletes
> for python3- prefixed packages later if wanted).
>
> My thought process is that I would not like, after python3 is
> the default, to still have to put the explicit 3 on there
> because python is still python2. Just thinking ahead here.
Thanks! If I'm correctly reading your mail, this approach is one I did
think of, but I'm not fond of it.
I think that anyone dealing with Python is going to have to be thinking
"is this python 2 or python 3" for some years to come, so having an
explicit "python3-" prefix is probably not too painful.
What I think would be painful in your suggestion is the flag day where
we'd change the meaning of "python-" in RPM names. Currently in Fedora
and EPEL, "python-" implies the system-supplied minor release of python
2, be it in Fedora (2.6), or in EPEL (2.4). I worry that changing it to
imply the system-supplied minor release of Python 3 (3.1, or 3.2/3.3? by
that point) would be thoroughly confusing, since we'd have to update
everything all at once. It wouldn't fly within EPEL, since the
pre-existing Enterprise downstreams of Fedora aren't going to change
(far too disruptive).
One middle ground might be to start using "python2-" explicitly for
_new_ packages. That wouldn't break anything, but could easily be
confusing as well. I think I prefer keeping things consistent.
Perhaps at some point we could cut over "/usr/bin/python" from being
Python 2 to Python 3, but I refer you again to this quote from Guido:
http://mail.python.org/pipermail/python-3000/2008-March/012421.html
(The other fun thing to do might be to package Unladen Swallow. Not at
all sure what to call _that_ though!)
Dave
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, 2009-10-01 at 12:17 -0700, Toshio Kuratomi wrote:
> On 10/01/2009 10:15 AM, David Malcolm wrote:
> > Proposal: Python 3 in Fedora 13
> >
> > "Evolutionary, not revolutionary": build a python 3 stack
> > parallel-installable with the python 2 stack.
> >
>
> First: Overall +1.
>
> Note: liberally snipped, throughout.
[likewise snipped lots of stuff]
> > "Naming convention" proposal:
> > How does this sound:
> > - an rpm with a "python-" prefix means a python 2 rpm, of the
> > "default" python 2 minor version (for Fedora this will be the most
> > recent stable upstream minor release, for EPEL it will be the minor
> > release of 2 that came with the distro, so 2.4 for EPEL5)
> >
> > - an rpm with a "python3-" prefix means a python 3 rpm, of the
> > "default" python 3 minor version (for Fedora this will be the most
> > recent stable upstream release)
> >
> > What about packages without a "python-" prefix? Proposal: If upstream
> > has a naming convention for python2 vs python3, use it. Otherwise, add
> > a "python3-" prefix to make things clear. I'm not sure about the
> > details here. Examples?
> >
> +1 to the basics. There are a lot of details to work out:
[snip the details]
Thanks. Given that, I went ahead and created a Feature page for this:
https://fedoraproject.org/wiki/Features/Python3F13
So far it's mostly just a restatement of my post, though I've started
fleshing out some sections e.g. "how to test". I've assumed the naming
convention from my post "python3" for the srpm, and for the symlink to
the binary.
Feel free to dive in and edit. I marked myself as owner of the feature
as I know I'm going to be able to devote a big chunk of time to this.
Hope that's OK.
We now have 3 competing srpms for Python 3:
(i) the one from ivazquez:
> > http://ivazquez.fedorapeople.org/packages/python3000/
("python3000")
(ii) the one by Andrew McNabb:
https://bugzilla.redhat.com/show_bug.cgi?id=526126 (named "python3")
(iii) and the one I did, also named "python3":
> > http://people.redhat.com/dmalcolm/python3/python3.spec
> > and an SRPM here:
> > http://people.redhat.com/dmalcolm/python3/python3-3.1.1-1.fc13.src.rpm
> I was just going to suggest you contact ivazquez :-) he's done a lot of
> work, both to get a python3 package working and on the update from
> python2.5 to python2.6.
I'm assuming ivazquez is seeing these emails (I _think_ he said he'd
seen it on IRC earlier today), and I added a link to my email to the
review bug above so hopefully Andrew is seeing this.
I hope to have a look at the commonality/differences between the 3
efforts tomorrow. I think "python3" is a better name (if nothing else,
it's shorter to type!).
I'd like it if the eventually python 3 specfile could resemble the
python 2 specfile so that we can meaningfully look at the textual diffs
between them (but it may be necessary to clean up the python specfile to
achieve this! I'll try to have a look at the merge-review)
Thanks for the feedback; hope this all sounds sane
Dave
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, 2009-10-01 at 11:23 -0700, Toshio Kuratomi wrote: > On 10/01/2009 11:11 AM, Jesse Keating wrote: > > > > > > On Oct 1, 2009, at 10:59, Josh Boyer wrote: > > > >> On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: > >>> Scoping: > >>> - this work would target Fedora 13. I'd avoid pushing it into F12 > >>> until it's proven safe to do so > >> > >> I'm going to think on the overall proposal more, but I very very very > >> much > >> wish this sentence said "I will not push this into F12 at all." > >> > >> josh > >> > > > > Ditto. This is not something you would push as an update to a released > > product. > > > I disagree. The proposal is really treating python3 as a new language. > We can and do push such things into a released Fedora. Treating it as a new language is the intent, and I'll make every effort to keep them separated. In theory there wouldn't be any problems. However if I screw up and somehow cross the streams, I run the risk of breaking _lots_ of things; yum is the most obvious victim in the critical path. Obviously I don't want to do that. I'm not volunteering to put it into F12. I think that anyone wanting to push it into F12 needs to sign up for a lot of testing (brainstorming some testcases: can you still compile and build external modules with both 2 and 3 -devel subpackages installed? does every configure script pick up the correct version? etc) Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, 2009-10-01 at 13:07 -0500, Chris Adams wrote: > Once upon a time, Josh Boyer said: > > On Thu, Oct 01, 2009 at 01:15:09PM -0400, David Malcolm wrote: > > >Scoping: > > > - this work would target Fedora 13. I'd avoid pushing it into F12 > > >until it's proven safe to do so > > > > I'm going to think on the overall proposal more, but I very very very much > > wish this sentence said "I will not push this into F12 at all." > > Yeah, we seem to have too much "churn" going with some things as it is > during a release. What possible reason would there be to push a major > new component into an existing release? Agreed. This part of my post was clumsy. I think what I meant to say was that I'd want to veto anyone wanting to push it into F12, that they'd have a significant burden of proof of safety before such an action could occur. I don't have any interest in such a backport. Sorry Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Proposal: Python 3 in Fedora 13
Proposal: Python 3 in Fedora 13
"Evolutionary, not revolutionary": build a python 3 stack
parallel-installable with the python 2 stack.
= High-level summary =
- Python 3.0 was released almost 10 months ago, on 2008-12-03, and the
latest release of the 3.* branch is 3.1.1, released on 2009-08-17.
- Other distros have python 3, though not necessarily with anything
"on top" resembling the full python 2 stack.
- We have a working, valuable python 2 stack, which is used by
critical system components (yum and anaconda): we must not destabilize
the python 2 stack.
- Python 3 is sufficiently different from python 2 that we need them
to be independent software stacks.
- I plan to spend a large chunk of my $DAYJOB over the next few months
trying to build a useful Python 3 stack for Fedora 13, for some
definition of "useful" (help will be appreciated!)
- I don't want to add extra work for package maintainers: if you
maintain an SRPM of a python 2 module that's working for you, you
shouldn't feel obligated to own a separate SRPM for python 3. If
someone has a need for the module on python 3, they can take on that
work.
= Background =
Python 3 is intended by upstream to be the future of Python, but we have
many critical components that use Python 2. Python 2 and Python 3 are
sufficiently different that we need both (try writing "print" in each).
Python 2 will be around for a long time.
An interesting summary of Python 3 adoption can be seen here:
http://renesd.blogspot.com/2009/09/py3kpython3-more-than-one-year-on-096.html
An earlier proposal about python 3 in Fedora is here:
https://www.redhat.com/archives/fedora-devel-list/2008-May/msg02417.html
Going forward, I will have plenty of time to spend, as part of my
dayjob, on Python in Fedora [1]
= Proposal =
I want to get python 3 into Fedora, but I don't want to break yum or
anaconda (or anything else, for that matter!)
How to do this? I propose that Fedora shall have separate,
parallel-installable Python 2 and Python 3 stacks. I believe we can get
things to the point where on a Fedora box you'd be able to install both
stacks, and have some processes running python 2 code, and some running
python 3, simultaneously.
Where I would draw the line is on having both python 2 and python 3
running within the same _process_: the two libraries share most of their
symbol names, but with differing implementations, and the result of
trying to dynamically link the two into the same address space would be
highly unstable.
As an example, you'd be able to install both mod_python and mod_python3
rpms, but you wouldn't be able to (sanely) configure httpd to have both
running simultaneously (I guess we should add a run-time warning for
this case)
Scoping:
- this work would target Fedora 13. I'd avoid pushing it into F12
until it's proven safe to do so
- the proposal is for python 2 vs python 3. It could be extended to
support having multiple minor-versions of Python as well, but that's a
big extension of the work involved and not something I'm planning to
work on myself.
= Details =
We should split python 2 and python 3 at the source RPM level, where
possible.
The easy case is when upstream release separate tarballs for the python
2 and python 3 versions of code. For example, given package
"python-foo" in packaging CVS, there would be a separate "python3-foo"
for the python 3 version. There would be no expectation that the two
would need to upgrade in lock-step. (The two SRPMS could have different
maintainers within Fedora: the packager of a python 2 module might not
yet have any interest in python 3)
The more difficult case is when the python module is emitted as part of
the build of a larger module. Some examples:
- the build of "rpm" itself emits an "rpm-python" subpackage.
- Another example is the "postgres" srpm, which emits a
"postgresql-python" subpackage.
In a quick attempt at seeing other examples, on my laptop (F11), here
are the packages installed that provide python modules where the package
name differs from the srpm name:
$ rpm -qf /usr/lib/python2.*/site-packages/* | grep -v "is not owned" |
sort | uniq | xargs rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}
%{SOURCERPM}\n" | sed -e"s/.src.rpm//" | squeal -f table col0, col1 from
- where col0 != col1
col0| col1|
+--+
at-spi-python-1.26.0-1.fc11| at-spi-1.26.0-1.fc11|
audit-libs-python-1.7.13-1.fc11| audit-1.7.13-1.fc11|
cracklib-python-2.8.13-4| cracklib-2.8.13-4|
gamin-python-0.1.10-4.fc11| gamin-0.1.10-4.fc11|
hplip-libs-3.9.8-12.fc11| hplip-3.9.8-12.fc11|
libproxy-python-0.2.3-10.fc11|libproxy-0.2.3-10.fc11|
libselinux-python-2.0.80-1.fc11| libselinux-2.0.80-1.fc11|
Re: yum-presto not on by default
On 9/25/2009 1:00 PM, Adam Williamson wrote: > On Fri, 2009-09-25 at 12:43 -0400, David Boles wrote: > >> 'lurker mode off' >> >> Comment from a 'lurker' >> >> You developers and all do a fine job with this. >> >> *But* you all seem to have the same wrong idea about *most* regular >> Linux users. At least the ones that I see on the help lists. >> >> *Almost none of them read that darn DOCs.* Nor do they read the release >> Notes. Nor do they read the FAQ's. Nor do they read they Known Problems. > > That's, um, pretty much what I was saying. > >> Really? They don't read the instructions and hints *before* they destroy >> their working systems with an update? Or with a release upgrade? >> >> Really? Not the Newbies? Not the 'I think that I am an Expert' people? >> Not the 'I have much Linux experience' people? Really? Sure. Just follow >> the questions asked when something well written about pops up as a >> *surprise*. > > I know this. > > It is, however, fair to point out that you're using an inherently skewed > sample - "the ones that I see on the help lists'. All other things being > equal, the people who bother to read the documentation naturally show up > far less often on help lists. =) Agreed. So how do you get those 'others' to read the instructions? Linux used to basically require that you do that. Things had to be found in the system and then configured by hand. In the rush to make things auto-magic, which is not a bad thing IMO, when something does not 'just work' users are lost. They seem to have forgotten how to read. Or perhaps comprehend what they read. And those users will always be Linux's bane. -- David signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: yum-presto not on by default
On 9/25/2009 11:23 AM, Adam Williamson wrote: > On Fri, 2009-09-25 at 11:08 -0400, Seth Vidal wrote: > >> My only reason for arguing has been that our users are not stupid, we >> don't TARGET new users anyway >> https://fedoraproject.org/wiki/Overview#Is_Fedora_for_me.3F >> >> so there's no point in acting like they're new users. > > sure, but nothing I've said is predicated on the assumption that the > users in question are new or dumb or anything like that. as I said, you > can observe this behaviour happening all the time in experienced user / > developer circles (developer planets, IRC etc). No matter how 'advanced' > the user group, probably the majority do not refer to documentation > until they hit something they would consider a problem. > 'lurker mode off' Comment from a 'lurker' You developers and all do a fine job with this. *But* you all seem to have the same wrong idea about *most* regular Linux users. At least the ones that I see on the help lists. *Almost none of them read that darn DOCs.* Nor do they read the release Notes. Nor do they read the FAQ's. Nor do they read they Known Problems. Really? They don't read the instructions and hints *before* they destroy their working systems with an update? Or with a release upgrade? Really? Not the Newbies? Not the 'I think that I am an Expert' people? Not the 'I have much Linux experience' people? Really? Sure. Just follow the questions asked when something well written about pops up as a *surprise*. Sorry for the noise. Back to 'lurker' mode'. -- David signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: removal of dhcpv6 package from Fedora
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 18 Sep 2009, J. Randall Owens wrote: On 09/18/2009 05:25 PM, David Cantrell wrote: If you do not care about IPv6, feel free to stop reading now. I would like to remove the dhcpv6 package from Fedora as the current dhcp package is now providing DHCPv6 protocol support for both the client, server, and relay. ISC has finally surpassed what the dhcpv6 package was providing and, frankly, I have no desire to continue working on the dhcpv6 at this point. Does anyone care? If not, I will be marking it as a dead.package per our package removal procedure. The dhclient package will grow the necessary Provides/Obsoletes for the former dhcpv6-client package and the dhcp package will grow the necessary Provides/Obsoletes for the former dhcpv6 package. On a related note, I'd been meaning to inquire about and/or suggest ways to get ISC's dhcpd working for both IPv4 and IPv6 simultaneously. Do you have one way or another of doing this yet? That was the only thing that had me using dhcp6s for a short time. Unfortunately, no. Like dhclient, dhcpd can only operate as a DHCP (protocol) or DHCPv6 (protocol) server. It can't operate as both at the same time. To use both with dhcpd, just run two instances. This is the recommendation from ISC at the moment. The dhcpd architecture needs a lot of changes before both protocols can be supported by a single daemon. - -- David Cantrell Red Hat / Honolulu, HI -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkq0MmwACgkQ5hsjjIy1VknXzwCeKaEgVGuVlDA3ZeNiNH0OwgdU MRcAoI4L5zz8uNj/NAkZxU4hSPhT/lTD =7IHO -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
removal of dhcpv6 package from Fedora
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If you do not care about IPv6, feel free to stop reading now. I would like to remove the dhcpv6 package from Fedora as the current dhcp package is now providing DHCPv6 protocol support for both the client, server, and relay. ISC has finally surpassed what the dhcpv6 package was providing and, frankly, I have no desire to continue working on the dhcpv6 at this point. Does anyone care? If not, I will be marking it as a dead.package per our package removal procedure. The dhclient package will grow the necessary Provides/Obsoletes for the former dhcpv6-client package and the dhcp package will grow the necessary Provides/Obsoletes for the former dhcpv6 package. - -- David Cantrell Red Hat / Honolulu, HI -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkq0JQ0ACgkQ5hsjjIy1VknfvgCgq5csF03YMkQxp+A0p4tmAhI1 cLoAoLTxhH09fzrO7dawQyR4VCVs5jg+ =/7o7 -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GNU libc confusion with symbols undefined.
On Fri, 2009-09-18 at 09:21 -0500, Brown, Rodrick wrote:
> I'm trying to understand the following here
>
> I have a simple test program that calls memcpy/malloc/printf
>
> int
> main(int argc, char **argv)
> {
> char * p = malloc(10);
> memcpy(p,"Hello",6);
> printf("%s\n", p);
> }
>
> When looking at the symbol list why are the following routines undefined? And
> why is it referncing GLIBC_2.2.5?
>
> $ nm /tmp/f |grep ' U '
> U __libc_start_main@@GLIBC_2.2.5
> U malloc@@GLIBC_2.2.5
> U memcpy@@GLIBC_2.2.5
> U printf@@GLIBC_2.2.5
>
> $ rpm -qa |grep -i glibc
> glibc-2.3.4-2.41
> glibc-common-2.3.4-2.41
> glibc-2.3.4-2.41
>
> I really can't find an explination for this and was wondering if someone
> could clear it up.
libc has "versioned symbols", and you're linking against the default
implementations of each of the three symbols, as defined in the version
of libc you built against (the "@@" notation means the default version
of a versioned symbol).
For detailed information on this, see:
http://people.redhat.com/drepper/dsohowto.pdf
and for the most detail, see:
http://people.redhat.com/drepper/symbol-versioning
Hope this helps
Dave
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Script to detect conflicting files in PATH within a yum repo (was Re: conflict between libotf and openmpi)
On Thu, 2009-09-17 at 14:14 -0400, Seth Vidal wrote: > > On Thu, 17 Sep 2009, David Malcolm wrote: > > > On Thu, 2009-09-17 at 09:57 -0400, Seth Vidal wrote: > >> > >> On Wed, 16 Sep 2009, David Malcolm wrote: > >> > >>> On Wed, 2009-09-16 at 18:45 -0400, Neal Becker wrote: > >>>> Which makes me wonder, how could this conflict have been avoided? Is > >>>> there > >>>> a tool that would check any new package to see if any object* in it would > >>>> conflict with any existing package? If not, sounds like a good thing to > >>>> have. > >>>> > >>>> * Here, object means filesystem object. I'm not sure if there are any > >>>> other > >>>> types of objects to worry about. > >>> Brainstorming: a script that walks the yum repo's filelist.tar.gz, and > >>> figures out a list of filename collisions, filtering by directories in > >>> the default PATH > >>> > >>> > >>> Attached is a first pass at a python script that does this. > >>> > >>> Output from the script when run upon [1] is below. Caveat: the script > >>> probably has bugs. > >>> > >>> Does this look useful? > >> > >> David, > >> Yes it does look useful. > >> > >> I wrote something similar: > >> > >> http://skvidal.fedorapeople.org/misc/potential_conflict.py > >> > >> which is what I believe autoqa is starting from for their file conflict > >> checker. > > Aha! Your approach looks superior, as you're leveraging all that extra > > info from the RPM headers about file hashes etc. Thanks. > > > > maybe a bit more thourough but I wouldn't call it superior - it takes > forever to complete b/c you have to look at all those headers :( > > Magic alternatives welcome. Well, define "forever"... my script takes about 30 seconds (and ~1GB RAM) on my workstation; if that's a bit improvement over your runtimes, perhaps you could try a hybrid approach of walking the filelist.xml.gz to quickly find possible conflicts, then only opening the rpm headers as needed to reject the false conflicts? Dunno [snip content-addressed storage/hashing ideas] Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Script to detect conflicting files in PATH within a yum repo (was Re: conflict between libotf and openmpi)
On Thu, 2009-09-17 at 09:57 -0400, Seth Vidal wrote: > > On Wed, 16 Sep 2009, David Malcolm wrote: > > > On Wed, 2009-09-16 at 18:45 -0400, Neal Becker wrote: > >> Which makes me wonder, how could this conflict have been avoided? Is there > >> a tool that would check any new package to see if any object* in it would > >> conflict with any existing package? If not, sounds like a good thing to > >> have. > >> > >> * Here, object means filesystem object. I'm not sure if there are any > >> other > >> types of objects to worry about. > > Brainstorming: a script that walks the yum repo's filelist.tar.gz, and > > figures out a list of filename collisions, filtering by directories in > > the default PATH > > > > > > Attached is a first pass at a python script that does this. > > > > Output from the script when run upon [1] is below. Caveat: the script > > probably has bugs. > > > > Does this look useful? > > David, > Yes it does look useful. > > I wrote something similar: > > http://skvidal.fedorapeople.org/misc/potential_conflict.py > > which is what I believe autoqa is starting from for their file conflict > checker. Aha! Your approach looks superior, as you're leveraging all that extra info from the RPM headers about file hashes etc. Thanks. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Script to detect conflicting files in PATH within a yum repo (was Re: conflict between libotf and openmpi)
On Wed, 2009-09-16 at 20:08 -0400, Neal Becker wrote: > Why not report all conflicts, instead of only those on your PATH? This is acting at the level of individual filenames (dropping the directory component from the path), and doesn't have any knowledge about a file beyond its full installation path. The PATH filtering allows it to avoid lots of false-positives from all of the various "COPYING", "README" etc files we drop into various places in the filesystem. Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Script to detect conflicting files in PATH within a yum repo (was Re: conflict between libotf and openmpi)
On Wed, 2009-09-16 at 18:45 -0400, Neal Becker wrote: > Which makes me wonder, how could this conflict have been avoided? Is there > a tool that would check any new package to see if any object* in it would > conflict with any existing package? If not, sounds like a good thing to > have. > > * Here, object means filesystem object. I'm not sure if there are any other > types of objects to worry about. Brainstorming: a script that walks the yum repo's filelist.tar.gz, and figures out a list of filename collisions, filtering by directories in the default PATH Attached is a first pass at a python script that does this. Output from the script when run upon [1] is below. Caveat: the script probably has bugs. Does this look useful? ulockmgr_server /bin/ulockmgr_server from fuse /usr/bin/ulockmgr_server from fuse telnet /usr/bin/telnet from telnet /usr/kerberos/bin/telnet from krb5-workstation-clients gzip /bin/gzip from gzip /usr/bin/gzip from gzip fusermount /bin/fusermount from fuse /usr/bin/fusermount from fuse stap-env /usr/bin/stap-env from systemtap-client /usr/bin/stap-env from systemtap /usr/bin/stap-env from systemtap-server winemaker /usr/bin/winemaker from wine-devel /usr/bin/winemaker from wine-common ftp /usr/bin/ftp from ftp /usr/kerberos/bin/ftp from krb5-workstation-clients pinentry /usr/bin/pinentry from pinentry /usr/bin/pinentry from pinentry-gtk /usr/bin/pinentry from pinentry-qt kadmin /usr/kerberos/bin/kadmin from krb5-workstation-servers /usr/kerberos/bin/kadmin from krb5-workstation lzcmp /usr/bin/lzcmp from xz-lzma-compat /usr/bin/lzcmp from lzma lzgrep /usr/bin/lzgrep from xz-lzma-compat /usr/bin/lzgrep from lzma lzdiff /usr/bin/lzdiff from xz-lzma-compat /usr/bin/lzdiff from lzma lzcat /usr/bin/lzcat from xz-lzma-compat /usr/bin/lzcat from lzma lzmainfo /usr/bin/lzmainfo from xz-lzma-compat /usr/bin/lzmainfo from lzma lzfgrep /usr/bin/lzfgrep from xz-lzma-compat /usr/bin/lzfgrep from lzma plymouth /bin/plymouth from plymouth /usr/bin/plymouth from plymouth gawk /bin/gawk from gawk /usr/bin/gawk from gawk ex /bin/ex from vim-minimal /usr/bin/ex from vim-enhanced ircd /usr/bin/ircd from ircd-ratbox /usr/bin/ircd from ircd-hybrid cut /bin/cut from coreutils /usr/bin/cut from coreutils towhee-mpi /usr/bin/towhee-mpi from towhee-mpi /usr/bin/towhee-mpi from towhee pscp /usr/bin/pscp from putty /usr/bin/pscp from pssh links /usr/bin/links from links /usr/bin/links from elinks rsh /usr/kerberos/bin/rsh from krb5-workstation-clients /usr/bin/rsh from rsh awk /bin/awk from gawk /usr/bin/awk from gawk tmda-ofmipd /usr/bin/tmda-ofmipd from tmda-ofmipd /usr/bin/tmda-ofmipd from tmda kvno /usr/kerberos/bin/kvno from krb5-workstation-servers /usr/kerberos/bin/kvno from krb5-workstation sclient /usr/kerberos/bin/sclient from krb5-devel /usr/kerberos/bin/sclient from krb5-server unlzma /usr/bin/unlzma from xz-lzma-compat /usr/bin/unlzma from lzma ktutil /usr/kerberos/bin/ktutil from krb5-workstation-servers /usr/kerberos/bin/ktutil from krb5-workstation lzegrep /usr/bin/lzegrep from xz-lzma-compat /usr/bin/lzegrep from lzma ntfs-3g /bin/ntfs-3g from ntfs-3g /usr/bin/ntfs-3g from ntfs-3g k5srvutil /usr/kerberos/bin/k5srvutil from krb5-workstation-servers /usr/kerberos/bin/k5srvutil from krb5-workstation rlogin /usr/kerberos/bin/rlogin from krb5-workstation-clients /usr/bin/rlogin from rsh stap-find-servers /usr/bin/stap-find-servers from systemtap-client /usr/bin/stap-find-servers from systemtap-server lzma /usr/bin/lzma from xz-lzma-compat /usr/bin/lzma from lzma kde4-doxygen.sh /usr/bin/kde4-doxygen.sh from kdelibs-devel /usr/bin/kde4-doxygen.sh from kdelibs find /bin/find from findutils /usr/bin/find from findutils jasper5-setclasspath.sh /usr/bin/jasper5-setclasspath.sh from tomcat5 /usr/bin/jasper5-setclasspath.sh from tomcat5-jasper translate /usr/bin/translate from libtranslate /usr/bin/translate from surfraw stap-gen-cert /usr/bin/stap-gen-cert from systemtap /usr/bin/stap-gen-cert from systemtap-server stap-authorize-cert /usr/bin/stap-authorize-cert from systemtap /usr/bin/stap-authorize-cert from systemtap-server rcp /usr/kerberos/bin/rcp from krb5-workstation-clients /usr/kerberos/bin/rcp from krb5-workstation-servers /usr/bin/rcp from rsh env /bin/env from coreutils /usr/bin/env from coreutils jspc5.sh /usr/bin/jspc5.sh from tomcat5 /usr/bin/jspc5.sh from tomcat5-jasper synergyc /usr/bin/synergyc from synergy /usr/bin/synergyc from synergy-plus synergys /usr/bin/synergys from synergy /usr/bin/synergys from synergy-plus xemacs /usr/bin/xemacs from xemacs-nox /usr/bin/xemacs from xemacs kill /bin/kill from util-linux-ng /usr/bin/kill from util-linux-ng gettext /bin/gettext from gettext /usr/bin/gettext from gettext winedump
Re: dhclient and dhcp update require restart?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 2 Sep 2009, Dennis J. wrote: On 08/27/2009 07:49 PM, David Cantrell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 26 Aug 2009, Dariusz J. Garbowski wrote: Hi, something that bothers me a bit... More and more system restart requests with each update (even if one doesn't use the package at the time). Is this necessary for dhclient and dhcp update packages to require restart? Wouldn't "service network restart" and "service dhcpd restart" in the install/upgrade scripts do the trick (after checking that the service is actually running)? Ssh used to do that since, well, as far as I remember. Yes, 'service dhcpd restart' will work fine for dhcpd. For dhclient, it's not necessarily as simple as restarting the network service. If you are using the network service, that will work fine. If you are using NetworkManager, you'll need to either restart NetworkManager or have it down the connection you're using dhclient on and bring it back up. Why is a restart of NetworkManager necessary in this case? If dhclient reinitializes the interface and gets the old dhcp data then nothing really changes and NetworkManager shouldn't have to care. If e.g. der IP changes then NetworkManager should detect that and reinitialize the connection info on its end (after all the "new" interface might not be connected to anything and thus have to be marked as down anyway). It doesn't work that way. dhclient isn't a service with an init.d script. If you are using NetworkManager, dhclient is a child process of NetworkManager. You can't just restart dhclient since NetworkManager is controlling it. You have to either tell NetworkManager to down the interface, stop dhclient, and bring it back up -- or restart NetworkManager. Either way, the result is the same. If you are using the network service, dhclient is run when the interface is ifup'ed (so either restart the network service or ifup/ifdown the interface in that case). - -- David Cantrell Red Hat / Honolulu, HI -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqe1pUACgkQ5hsjjIy1VklGugCgxHxszZp60PHjRN5UpRfP59qD dOkAoLMk8WXoyXnsRaiIWIdwLn6u8mdp =5WWs -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dhclient and dhcp update require restart?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 27 Aug 2009, Matthew Woehlke wrote: Dariusz J. Garbowski wrote: Hi, something that bothers me a bit... More and more system restart requests with each update (even if one doesn't use the package at the time). This is a real shame. One of the selling points of Linux is that you *don't* need to reboot for every little upgrade (unlike a certain other OS I shan't name). Is this necessary for dhclient and dhcp update packages to require restart? Wouldn't "service network restart" and "service dhcpd restart" in the install/upgrade scripts do the trick (after checking that the service is actually running)? Ssh used to do that since, well, as far as I remember. Yes, please. Though maybe with prompting; we shouldn't go restarting possibly-critical services without good warning. As David said, for dhcpd, 'service restart dhcpd' should be fine. For dhclient I would question why /any/ restart is needed. If your dhcp connection is currently established, is dhclient even running? And even if it is, what benefit do you get cycling the interface /now/, if the new dhclient takes over whenever the interface cycles anyway? This is a limitation of the updates system, at least to my knowledge. I submit updates based on package builds, but cannot set things like 'suggests reboot' on a per subpackage basis. Since dhclient is a subpackage of dhcp, and I flag needs reboot for the dhcp package, dhclient inherits that. But I explained in the previous reply how to cycle the interface using either the network service or NetworkManager. I still view this as something more technical users will be familiar with and for the average user, simply rebooting the system is the easiest method. - -- David Cantrell Red Hat / Honolulu, HI -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqYYQ0ACgkQ5hsjjIy1VkmmAQCgyTlzwMUifVgU4xYYdKbeCZJS A9UAoKO1pnjuM82JLy3+gYxL8T0/Sxgn =O/sd -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit 0.9 is going away
On Thu, 2009-08-27 at 12:45 -0400, Matthias Clasen wrote: > > I'd be willing to maintain PolicyKit 0.9 packages (as compatibility > > packages > > (though renaming should not be needed as they already have distinct names), > > to be used by KDE) for F12. It is my understanding that those will not > > conflict with PolicyKit 1 and can coexist just fine, if that's not the > > case, > > please correct me. So please don't obsolete PolicyKit 0.9! We announced that this would happen long ago. And, FWIW, it was approved long ago by FESCO too. And you've been aware of this long ago as well. So, sorry, but we will obsolete the old packages and I'm afraid you will need to deal with it. Just like everyone else. > We really don't want to ship multiple authorization > databases, that way lies confusion and madness. Indeed. And in this transition period where we've been shipping both set of packages, there has been a lot of confusion. I've witnessed that myself. We just don't want that to happen in a released OS. David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dhclient and dhcp update require restart?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 26 Aug 2009, Dariusz J. Garbowski wrote: Hi, something that bothers me a bit... More and more system restart requests with each update (even if one doesn't use the package at the time). Is this necessary for dhclient and dhcp update packages to require restart? Wouldn't "service network restart" and "service dhcpd restart" in the install/upgrade scripts do the trick (after checking that the service is actually running)? Ssh used to do that since, well, as far as I remember. Yes, 'service dhcpd restart' will work fine for dhcpd. For dhclient, it's not necessarily as simple as restarting the network service. If you are using the network service, that will work fine. If you are using NetworkManager, you'll need to either restart NetworkManager or have it down the connection you're using dhclient on and bring it back up. For any of these scenarios, I figure most technical users will know what to do. When I select the 'suggest reboot' box in the updates system, I'm thinking of the non-technical users. Both dhcpd and dhclient would be things brought up on boot, so suggesting a reboot to the user is the easiest way to get the correct services restarted. - -- David Cantrell Red Hat / Honolulu, HI -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqWxw0ACgkQ5hsjjIy1VknDsgCfasl1AnpQ74vKT/ZTK8l2WU6b CUAAoMKxJloW1IEiRGIVC9lRPLUYW/+C =Kqzr -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Thu, 2009-08-13 at 21:27 -0400, Steve Grubb wrote: > On Thursday 13 August 2009 05:53:37 pm John Poelstra wrote: > > Can you update the feature page to reflect the reduced scope of the > > feature and its completion percentage? All I see since FESCo met was > > the change to the detailed description related to the permissions. > > That *is* the reduction in scope - other than what I have time to actually > work on. If I can fix dhcp, that is a major win. That is the item that stands > out as the biggest problem when running netcap. Steve: With my paranoid/QA hat on, I think the "How to Test" section needs some more items. It covers testing that each specific change being made works as expected, but it doesn't also cover testing that there weren't unexpected side effects. I added some questions to this end to the discussion page: https://fedoraproject.org/wiki/Talk:Features/LowerProcessCapabilities Hope this is helpful Dave -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anaconda install askmethod
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 11 Aug 2009, Mike Chambers wrote: On Tue, 2009-08-11 at 14:35 -1000, David Cantrell wrote: What version of anaconda did you try? I just recently fixed a problem with askmethod not doing anything. If you booted from a CD or DVD but wanted to do a network install, the askmethod parameter was not working. That fix is in anaconda-12.12-1. I'll give it a shot again here in the next day or so, maybe this weekend if I get time and some personal things don't get in the way. I believe 12.7 was the last version I tried with. My mistake and I see a bug has already been filed. I was confusing 'askmethod' with 'asknetwork'. I had fixed a problem around the asknetwork parameter. - -- David Cantrell Red Hat / Honolulu, HI -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqDG88ACgkQ5hsjjIy1Vkn5FwCgx7vfH0u4VPN5GHuc7uwzQPhN tfEAoNYKBOoDcJUDeJCG275GJ9g3VECx =IcfP -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Cannot rely on /dev being present in %post scripts?
According to bug #517013, %post scripts should not assume that /dev is available -- so we can't do anything that requires the existence of /dev/null, /dev/urandom, etc. Is this a known and expected packaging rule, or is it a bug in the way that the user is attempting to install the packages? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Anaconda install askmethod
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 11 Aug 2009, Mike Chambers wrote: When trying to do an install against rawhide and/or F12 Alpha test image, and using askmethod as in previous releases, it doesn't seem to do the same thing. Instead of going through and asking for network configuration, type of install and location of image and such, before the actual installer gui starts, it just asks for language and keyboard types, then asks what partition and path the image is on. I'm doign an nfs install, so I have no way of answering that question. Is askmethod parameter during install going through a change or just a mishap? What version of anaconda did you try? I just recently fixed a problem with askmethod not doing anything. If you booted from a CD or DVD but wanted to do a network install, the askmethod parameter was not working. That fix is in anaconda-12.12-1. - -- David Cantrell Red Hat / Honolulu, HI -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqCDlsACgkQ5hsjjIy1VkmMEwCdEgqLcE/0JOK+tS8OYZsQJ19f Z+kAn1cr1NHHAyyhFb3djEb44OqQSNLI =mh6W -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: new to list, first post
Thomas Janssen wrote: > 2009/7/30 : >> I am new to this list, and I am looking forward to hearing the discussion. >> >> But thanks to bob and others responding to my post on fedoraforum.org >> http://forums.fedoraforum.org/showthread.php?t=227101 , I think I would >> like to broach a subject. My apologies if this is already a burning issue >> -- I am at work, and should not spend time browsing the archives. >> >> Is Fedora really gaining that much ground with every bi-yearly release to >> justify that pace? >> >> After all Red Hat is not a desktop but a server, right? And Chrome could >> kill current races to find a desktop to compete with Windows. So why not >> concentrate on what Red Hat/Fedora does best? Let Ubuntu grind out Gnome >> and KDE enhancements. How often does Solaris release desktop distros? > > That post is just intended to start a flamewar. It didn't work on the > forum, so you try it here. > *If* it's seriously what you think. You shouldn't waste the time of > our developers, but google and read up on all the topics you brought > up here. If you cant do at work, do it at home. > > Sorry if it sounds too snarky. I was thinking the same as you Thomas. It appears that just about every week a new 'blog type' post like this appears. And many, too many IMHO, respond. After the thread dies down another, similar, post arrives and it happens all over again. I think it looks like a set pattern. -- David signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: new to list, first post
On Thu, Jul 30, 2009 at 10:30 AM, wrote: > I am new to this list, and I am looking forward to hearing the discussion. > > But thanks to bob and others responding to my post on fedoraforum.org > http://forums.fedoraforum.org/showthread.php?t=227101 , I think I would > like to broach a subject. My apologies if this is already a burning issue > -- I am at work, and should not spend time browsing the archives. > > Is Fedora really gaining that much ground with every bi-yearly release to > justify that pace? > > After all Red Hat is not a desktop but a server, right? And Chrome could > kill current races to find a desktop to compete with Windows. So why not > concentrate on what Red Hat/Fedora does best? Let Ubuntu grind out Gnome > and KDE enhancements. How often does Solaris release desktop distros? > > Thanks again for letting me be a party to the discussion. > > D_bot Welcome to the list. So the question that jumps out of me, is what arena are you measure the ground gained in? There are clearly some things that Fedora cares about, but doesn't necessarily prioritize, and in many of those areas, we probably gain little ground, and perhaps even lose ground because of our priorities. Fedora's priority is to be a place of innovation, to be the best of openource right now, and those priorities require rapid releases. The pace is gruelling, and how some of the members of the community keep up remains a mystery to me. (I fully expect to discover that Jesse is really a set of triplets committed to Fedora) Also, please note, that Red Hat != Fedora - though Red Hat certainly has an interest in Fedora and Fedora is the upstream for RHEL; much like kernel.org is the upstream for Fedora's and Ubuntu's kernel. I think you'll find that there is really far more innovation that occurs here (yes desktop innovation too) than elsewhere, not to diminish the work of others, but between the huge community and the dedicated engineers from RH that are working with upstream projects like Gnome, most features appear here first (because we closely track upstream, and becase many of those features, like NetworkManager, are largely written by people in Fedora) Now - all of that said - what kind of work in Fedora can we get you involved in? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Anaconda packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 28 Jul 2009, Rahul Sundaram wrote: On 07/28/2009 03:14 AM, David Cantrell wrote: I've been doing that for Jeroen. He's submitting patchsets for review and I've built at least a few anaconda updates for him. He is currently testing updates for F-11 and when that's ready, he'll submit the patches for review for anaconda and we can do an update. That's good news. Thanks for doing it. Are these test packages available publicly? You'll have to ask Jeroen how he handles testing. Once he has a patchset suitable for an F-11 update, he submits it for review and then we go from there. The idea being that once we roll the update for F-11, he'll be ready to pick it up and make images. - -- David Cantrell Red Hat / Honolulu, HI -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpuJrEACgkQ5hsjjIy1Vkk3ywCaAlMgCV7Kdfjsr17r1AjYTdKn wxQAoLeHQJ6xSCnLTlVFScZzAts0YUUD =lX70 -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Updated Anaconda packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 28 Jul 2009, Rahul Sundaram wrote: On 07/28/2009 01:11 AM, David Cantrell wrote: The problem here is when do you stop generating new media to fix bugs in F-11's installer and start working on F-12? Never? A week after F-11 GA? What determines if an installer bug gets a fix in F-11 vs. not? It's a gigantic waste of time for the installer team to release updates to F-11's installer. We can address those bugs in rawhide and have them fixed in the next stable release. Can you push the fixes as updates for Anaconda in Fedora 11? Fedora Unity isn't the only one doing updated images. It is increasingly becoming useful to have updated Anaconda packages available within the official repository as updates. If the Anaconda team doesn't want to do it, hand over that work to Jeroen van Meeuwen. He has already volunteered to take care of it and since he is doing it anyway for the unity images, his work could benefit more people. The only thing you got to do is give him commit access. I've been doing that for Jeroen. He's submitting patchsets for review and I've built at least a few anaconda updates for him. He is currently testing updates for F-11 and when that's ready, he'll submit the patches for review for anaconda and we can do an update. - -- David Cantrell Red Hat / Honolulu, HI -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpuH8kACgkQ5hsjjIy1Vkn5xwCgyk+B2AEYTqFTexDh+8NM8BL3 JP4An1d+XIrM9B1LfJpaSh/Lc9rbBaxV =WT9h -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 27 Jul 2009, Ralf Corsepius wrote: On 07/27/2009 11:26 AM, David Cantrell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 27 Jul 2009, Ralf Corsepius wrote: On 07/27/2009 07:33 AM, David Cantrell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 26 Jul 2009, Björn Persson wrote: Ralf Corsepius wrote: On 07/26/2009 02:37 PM, Seth Vidal wrote: On Sat, 25 Jul 2009, Alan Cox wrote: "all of my system has a wrong openssl version" all these symptoms sound like your upgrade went horribly wrong. I've seen preupgrade mash up a box by half upgrading like that. It's the main reason I don't think preupgrade is actually safe to use yet. Preupgrade's process is to depsolve - using the same method anaconda does, download the pkgs it solves out. Put them in a cachedir. Download a kernel and an initrd, Setup a ks.cfg. then reboot the machine and allow anaconda to do the install. Specific issues we've had with preupgrade are related to not being able to find a mirror and/or not being able to get pkgs. Mine were * preupgrade running out of diskspace on / when trying to fill /var/cache/yum (my "/"'s tend to be minimized/small) You're not blaming Preupgrade for the partition being too small, are you? If you want a small root partition you should put /var/cache/yum on another partition. Do you mean Preupgrade didn't handle the lack of disk space well? * anaconda failing during reboots due not being able to process fstab correctly (FC11's anaconda misparses fstab and is unable able to process bind-mounts nor nfs-mounts). Bind mounts are fixed, as far as I know: https://bugzilla.redhat.com/show_bug.cgi?id=496406 For NFS mounts, I believe it's fixed in commit 40728ffcc1e32eb6b5ccc0cd3b3ddb23216cf199, which was on June 7th. That should carry over NFS mounts listed in /etc/fstab if you are doing an upgrade. Well, to my knowledge these are "FIXED RAWHIDE", only. That's true. anaconda is unique in that the only way a new one can be released to fix installation issues for users is to generate new media. Exactly => this bug is _not fixed_. We continue to fix problems reported against Fedora 11's anaconda in rawhide, but for users needing the fix in the latest stable release, consider Fedora Unity. Fedora Unity generates new spins of the latest stable release including backports of anaconda fixes: http://www.fedoraunity.org/ With all due respect to fedoraunity and you. To me it is a serious Fedora management and rel-eng mistake causing major harm to fedora's and RH's reputation to not provide updated media, thus to expose users to known bugs. Openly said, I think this management mistake is one of the culprits for the poor shape of Fedora. Another one is not having banned "FIXED RAWHIDE/UPSTREAM". The problem here is when do you stop generating new media to fix bugs in F-11's installer and start working on F-12? Never? A week after F-11 GA? What determines if an installer bug gets a fix in F-11 vs. not? It's a gigantic waste of time for the installer team to release updates to F-11's installer. We can address those bugs in rawhide and have them fixed in the next stable release. Generating new media for an existing release is not a great solution. The mirrors are already synced up with the GA release. Here's what we do and I think it works best for now given the incredibly short (and damn near impossible to work with) planning and development windows for Fedora releases: 1) Major installation problems are documented on the Common Bugs wiki page for the Fedora release in question. Either a workaround or updates.img file is provided to fix the issue. 2) New bugs come in and we address them in rawhide. Where we run in to issues here is asking people to test the next build of rawhide. Not everyone wants to do that (or can, has time, etc). But spending our time producing new media and/or updates.img files for F-11 takes away from our time to work on F-12. This is where I think Fedora Unity can bridge the gap. They can pick up fixes for F-11 installation problems and roll new media for users. That provides a non-rawhide solution for the reporter, lets the bug at least get some testing, and frees us [installer team] from having to produce media or updates.img files for F-11. A larger problem we have is that we don't get the wide testing on the Alpha, Beta, or Release Candidate releases of the upcoming Fedora release. The same group of people generally test things out and the QA team performs their tests, but we never get the same testing exposure that a GA release does. Most users are sitting around waiting for the GA release and when they find a bug, it's too late for us to do anything about it in that release. Maybe if we lengthened the development cycle for a F
Re: fedora 11 worst then ever release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 27 Jul 2009, Ralf Corsepius wrote: On 07/27/2009 07:33 AM, David Cantrell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 26 Jul 2009, Björn Persson wrote: Ralf Corsepius wrote: On 07/26/2009 02:37 PM, Seth Vidal wrote: On Sat, 25 Jul 2009, Alan Cox wrote: "all of my system has a wrong openssl version" all these symptoms sound like your upgrade went horribly wrong. I've seen preupgrade mash up a box by half upgrading like that. It's the main reason I don't think preupgrade is actually safe to use yet. Preupgrade's process is to depsolve - using the same method anaconda does, download the pkgs it solves out. Put them in a cachedir. Download a kernel and an initrd, Setup a ks.cfg. then reboot the machine and allow anaconda to do the install. Specific issues we've had with preupgrade are related to not being able to find a mirror and/or not being able to get pkgs. Mine were * preupgrade running out of diskspace on / when trying to fill /var/cache/yum (my "/"'s tend to be minimized/small) You're not blaming Preupgrade for the partition being too small, are you? If you want a small root partition you should put /var/cache/yum on another partition. Do you mean Preupgrade didn't handle the lack of disk space well? * anaconda failing during reboots due not being able to process fstab correctly (FC11's anaconda misparses fstab and is unable able to process bind-mounts nor nfs-mounts). Bind mounts are fixed, as far as I know: https://bugzilla.redhat.com/show_bug.cgi?id=496406 For NFS mounts, I believe it's fixed in commit 40728ffcc1e32eb6b5ccc0cd3b3ddb23216cf199, which was on June 7th. That should carry over NFS mounts listed in /etc/fstab if you are doing an upgrade. Well, to my knowledge these are "FIXED RAWHIDE", only. That's true. anaconda is unique in that the only way a new one can be released to fix installation issues for users is to generate new media. If the problem is confined to the second stage of the installer, we can put the fix in to an updates.img. We do this for common bugs when a release comes out, but we cannot spend all of our time constantly releasing updates.img files: https://fedoraproject.org/wiki/Common_F11_bugs We continue to fix problems reported against Fedora 11's anaconda in rawhide, but for users needing the fix in the latest stable release, consider Fedora Unity. Fedora Unity generates new spins of the latest stable release including backports of anaconda fixes: http://www.fedoraunity.org/ No guarantees of what Fedora Unity contains, but I know they follow the rawhide anaconda and pick out fixes that work for the latest stable release and generate new installation media. You also get the benefit of having all current stable updates for F-11 rolled up in to the installation media. - -- David Cantrell Red Hat / Honolulu, HI -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkptcuEACgkQ5hsjjIy1VklUDwCg3VaxUZcccm4X2io9BffrPWBP NagAnRS0EuOe/RFaynGENwrN/8RD9kI4 =6ACn -END PGP SIGNATURE--- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: fedora 11 worst then ever release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 26 Jul 2009, Björn Persson wrote: Ralf Corsepius wrote: On 07/26/2009 02:37 PM, Seth Vidal wrote: On Sat, 25 Jul 2009, Alan Cox wrote: "all of my system has a wrong openssl version" all these symptoms sound like your upgrade went horribly wrong. I've seen preupgrade mash up a box by half upgrading like that. It's the main reason I don't think preupgrade is actually safe to use yet. Preupgrade's process is to depsolve - using the same method anaconda does, download the pkgs it solves out. Put them in a cachedir. Download a kernel and an initrd, Setup a ks.cfg. then reboot the machine and allow anaconda to do the install. Specific issues we've had with preupgrade are related to not being able to find a mirror and/or not being able to get pkgs. Mine were * preupgrade running out of diskspace on / when trying to fill /var/cache/yum (my "/"'s tend to be minimized/small) You're not blaming Preupgrade for the partition being too small, are you? If you want a small root partition you should put /var/cache/yum on another partition. Do you mean Preupgrade didn't handle the lack of disk space well? * anaconda failing during reboots due not being able to process fstab correctly (FC11's anaconda misparses fstab and is unable able to process bind-mounts nor nfs-mounts). Bind mounts are fixed, as far as I know: https://bugzilla.redhat.com/show_bug.cgi?id=496406 For NFS mounts, I believe it's fixed in commit 40728ffcc1e32eb6b5ccc0cd3b3ddb23216cf199, which was on June 7th. That should carry over NFS mounts listed in /etc/fstab if you are doing an upgrade. * anaconda's depsolving failed when upgrading an FC10 + FC10-updates system due to NEVR issues. If you have any details of the failure, it would help. Anaconda relies on yum to do depsolving and yum relies on correctly configured yum repositories to provide the information to do depsolving. If you have details, please file a bug for anaconda. Those would be Anaconda issues, not Preupgrade issues – which makes them all the more serious. - -- David Cantrell Red Hat / Honolulu, HI -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkptPBYACgkQ5hsjjIy1VkkFlACeNHFf5Tx8Ief3O1qjFgSrYPEm GBkAnj4Guybso65om2SV88cQb+vU2JiC =uTAM -END PGP SIGNATURE--- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mass rebuild for Fedora 12
On 7/20/2009 4:14 PM, Bill Nottingham wrote: > Fedora Release Enginerering is going to be starting a mass rebuild this > Thursday, July 28th, for the following Fedora 12 features: > - XZ RPM Payloads > - x86 Architecture Support > > Just as in the Fedora 11 mass rebuild, if you'd like to opt out for > your packages, check a file into your package's devel/ branch, named > 'noautobuild'. This file should contain a short rationale of why you > wish to do the build yourself. Note that if you do not do a rebuild > during the timeframe before Alpha, one will be done regardless of > the presence of this file. > > Also note that delta RPMS will be disabled in rawhide for the duration > of this mass rebuild; delta rpms across payload format changes in > RPM are not useful. > > For more information, see: > https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild Recommendation? Continue to update Fedora 12/Rawhide during the rebuild? Or wait until the rebuild is completed? -- David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
meeting minutes posts - line / wordwrap in
Hi, what would be the best location to list an issue with the meeting minutes, where the entries overflow the width of the user's screen ? DaveT. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86_64 packages depends on i586.
On 7/11/2009 11:53 PM, Eric Springer wrote: > On Sun, Jul 12, 2009 at 12:35 PM, David wrote: >> I am serious here. Really. The names are...? > > It's besides the point, but there are quite a few games (World of > Warcraft, Half-life 2 etc.) that run perfectly under wine. I do think > Kevin does need to act a little more maturely though (especially now > that he's got an official position), and I also know that nothing is > going to be gained by continuing this emotional argument. > "quite a few games"? "quite a few games" does not count IMO as a real world situation. Real Microsoft applications. Not games. As for Keven? He needs. IMO, to control his emotions if he really wants to be a 'voice?'. Those of use that have been here for years can deal with that. Newbies? They see what is written. My anyone. Wrong or right. as 'the truth". Period. -- David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86_64 packages depends on i586.
On 7/11/2009 9:35 PM, Jesse Keating wrote: > > > On Jul 11, 2009, at 17:03, David wrote: > >> On 7/11/2009 6:17 PM, Kevin Kofler wrote: >>> Frank Murphy wrote: >>>> Doesn't seem to work for wine :) >>> >>> That's because WINE is only 32-bit, because most Winblow$ executables >>> are. >>> >>>Kevin Kofler >> >> >> "Winblow$"? >> >> You really should learn some control here. >> >> The 'real guys'. The developers, code writers, people-in-the-know, show >> respect where respect is warranted. >> >> Microsoft should recieve that respect IMO. >> >> 90% of the desktop computers in the world use some version of Windows. >> More desktop computers use some form of Mac OS than all combined >> versions (distributions) of Linux. >> >> WINE? Is a nice concept. But it will never, again IMO, as long as the >> 'Windows programs' that WINE can run are mostly really old DOS programs. >> >> Sheesh. >> -- >> > > Perhaps you should do a little research before you spout off. Wine is > capable of running very modern day applications that are written for the > windows platform. It is anything but old dos programs. Mr. Keating. May I call you Jessie? I know who you are and I respect you a lot. Would you please name "some very modern day applications that are written for the windows platform" that will run in a Linux current version of WINE? That will run under the currently available WINE in Fedora 11. Names and versions. _Real_ applications. The ones that ordinary 'users' want. Not the geeky ones that 'Linux geeks' want. I am serious here. Really. The names are...? -- David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86_64 packages depends on i586.
On 7/11/2009 9:27 PM, Bruno Wolff III wrote: > On Sat, Jul 11, 2009 at 21:17:56 -0400, > David wrote: >> On 7/11/2009 8:27 PM, Bruno Wolff III wrote: >>> On Sat, Jul 11, 2009 at 20:03:51 -0400, >>> David wrote: >>>> The 'real guys'. The developers, code writers, people-in-the-know, show >>>> respect where respect is warranted. >>> I'm sure Al Capone got a lot of respect in his day as well. >> >> ;-) >> >> I think that he *demanded* that respect. Deserved? Not really. > > I think the analogy works. > Thought of that way. I agree. -- David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86_64 packages depends on i586.
On 7/11/2009 8:27 PM, Bruno Wolff III wrote: > On Sat, Jul 11, 2009 at 20:03:51 -0400, > David wrote: >> The 'real guys'. The developers, code writers, people-in-the-know, show >> respect where respect is warranted. > > I'm sure Al Capone got a lot of respect in his day as well. ;-) I think that he *demanded* that respect. Deserved? Not really. -- David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86_64 packages depends on i586.
On 7/11/2009 6:17 PM, Kevin Kofler wrote: > Frank Murphy wrote: >> Doesn't seem to work for wine :) > > That's because WINE is only 32-bit, because most Winblow$ executables are. > > Kevin Kofler "Winblow$"? You really should learn some control here. The 'real guys'. The developers, code writers, people-in-the-know, show respect where respect is warranted. Microsoft should recieve that respect IMO. 90% of the desktop computers in the world use some version of Windows. More desktop computers use some form of Mac OS than all combined versions (distributions) of Linux. WINE? Is a nice concept. But it will never, again IMO, as long as the 'Windows programs' that WINE can run are mostly really old DOS programs. Sheesh. -- David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, 2009-07-05 at 17:52 +0200, Jeroen van Meeuwen wrote: > > > As described on the Feature page, but if there's any specific > questions > about the reasoning on there I'll be happy to answer those questions. I had read the feature page, in which you claim that a three-year cycle "disqualifies the distribution(s) as desktop Linux distributions". I didn't see any justification for that assertion, especially given that you're simultaneously claiming that a 13-month lifetime isn't long _enough_ for you. You've conveniently dodged the question of what lifetime you _do_ want to provide, by saying 'yet to be determined'. But you must have _some_ idea, if you're so sure that 13 months is too short and 36 months is too long. So if three years is too long and one year is too short, what _do_ you want? 2 years? 18 months? 18 months would be a single extra Fedora release, and that _might_ be something we could make some progress on. How much work would it take, to make it possible for us to still ship updates for a release which has officially reached EOL? Does the sky fall on our heads if we don't push the 'Kill F-9' button in koji and bodhi precisely 1 month after the F-11 release? As a first step, perhaps we try that -- still officially state that the release is EOL and should not be used, but _allow_ interested people like Jeroen (and the original package owners, _if_ they are so inclined) to continue to build and push updates, instead of forcibly cutting off builds and updates as we do at the moment. That _isn't_ something we would publish as a 'feature' though -- it would strictly _unofficial_, although you'd be permitted to use the Fedora infrastructure for it. If it turns out that there _is_ enough interest and the interested people are _actually_ keeping on top of security fixes etc., then maybe we could consider officially admitting that it happens, and _then_ publishing it as a 'feature'. And/or extending it to more than one extra release. But those are all questions for the future. If it doesn't take too much infrastructure work, I see no reason why we shouldn't let them _try_. It doesn't hurt Fedora at all, does it? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Feature proposal: Extended Life Cycle Support
On Sun, 2009-07-05 at 12:03 +0200, Jeroen van Meeuwen wrote: > The CentOS project, or it's upstream, has a release cycle of approximately > three years -not a steady release cycle of three years but that's what it > turns out to be. This disqualifies the distribution(s) as desktop Linux > distributions, as desktops tend to need to run the latest and greatest for > as far the latest and greatest lets them. > > Does that make sense? As a standalone observation, perhaps -- some desktop users often don't want old, stagnant code; they'd prefer the latest bells and whistles. But it makes no sense when considered in conjunction with your apparent desire for an old, stagnant version of Fedora. What makes you think it would be any different? It's not exactly difficult or problematic to update from one version of Fedora to the next. I do it on each of my servers at least once a year (I usually skip a release, but not always). And those are mostly headless, remote boxes. If you want new stuff, run Fedora and do a fairly painless update annually. If you want old stuff, run Centos and update less frequently. I don't see any need for a middle ground. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: ppc64 assistance
On Thu, 2009-07-02 at 16:28 +0100, Peter Robinson wrote: > >> http://koji.fedoraproject.org/koji/taskinfo?taskID=1449113 > > > > Unrelated to this issue, but please use "make V=1" so we see the actual > > build command lines in the build.log (see the thread about the new > > automake). > > With V=1 > > http://koji.fedoraproject.org/koji/getfile?taskID=1450335&name=build.log You know you can have access to a real box to test this on if you want it, right? You don't have to do it all in koji and look at the build logs. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Fri, Jul 3, 2009 at 1:23 AM, Rahul Sundaram wrote: > On 07/02/2009 08:51 PM, David wrote: > >> I disagree that Fedora should be packaging books, both of these can >> easily be downloaded via web. >> Why package something that has no dependencies? > > We package hundreds of things that have no dependencies and can be > downloaded easily via web including fonts. That is not a argument. OK, but if the package payload doesn't interoperate with another package, I can't see the point. Fonts, artwork, sure, they are a system resource for other software. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090702 changes
On Thu, Jul 2, 2009 at 10:41 PM, Rahul Sundaram wrote: > On 07/02/2009 06:03 PM, drago01 wrote: >> On Thu, Jul 2, 2009 at 1:32 PM, Rawhide Report >> wrote: >>> Compose started at Thu Jul 2 06:15:05 UTC 2009 >>> ... >>> New package ldd-pdf >>> Linux Device Drivers, Third Edition Book in PDF format >> >> We ship books as packages? > > Yes and this is not even the first time. Dive Into Python has been in > the repo for ages already. I disagree that Fedora should be packaging books, both of these can easily be downloaded via web. Why package something that has no dependencies? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Suggestion re FESCO Ticket #170
On 6/29/2009 12:31 PM, Adam Miller wrote: > On Mon, Jun 29, 2009 at 11:27 AM, Mat Booth wrote: >> Fedora Live Image <--- A link that downloads the Gnome or KDE image, >> picked at random by a script. > > Now its just getting silly... What a support nightmare that would be. > > I need help > What desktop are you running? > I dunno ... I just downloaded the default > . > > Enjoy DE Russian Roulette :) Now you guys are just getting Geeky about this. First. What makes you think that 'a Newbie from Windows' has any idea just what this 'desktop thing' is all about? Second. I would guess that if 'a Newbie from Windows' showed up to download that someone showed him where to go and made strong suggestions something like 'this one is what I use'. Third. I would be willing to bet that many of them would name the wallpaper if you ask them what a Windows desktop is. :-) What makes you think that 'a Newbie from Windows' has any idea just what a 'desktop' is? Sheesh. -- David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Suggestion re FESCO Ticket #170
Re the discussion at https://www.redhat.com/archives/fedora-devel-list/2009-June/msg01991.html The below suggestion tries to satisfy all parties: - it presents a neutral default - it presents a simple choice for newbie who doesnt know what a desktop is - it shows the range of what is available - it allows a specific choice Design suggestion for the Fedora download page (http://fedoraproject.org/en/get-fedora): FEDORA LIVE CD Do you require a specific desktop ? [ * ] I don't care [ ] Fedora Live with GNOME [ ] Fedora Live with KDE [ ] Fedora Live with LXDE [ ] Fedora Live with XFCE etc The "I don't care" just links to whichever desktop is currently the "default". Implementation of this logic doesn't require radio buttons. Just 2 links: 1) "click here for default" 2) or "click here to choose (go to a selection menu)" Clicking link #1 gets you the default. Or clicking link #2 takes you to a menu of links, one for each available choice. Fedora policy specifies which desktop the user gets if they click the default. But the above user interface design is independent of whichever one is the default. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Pidgin Issue, F11 64bit
On 6/26/2009 1:04 PM, Aly Dharshi wrote: > Yeah I just caught that, and started a new one already ! Sorry about the > grief. > > ASD. > > On 06/26/2009 11:02 AM, David wrote: >> On 6/26/2009 11:01 AM, Aly Dharshi wrote: >>> Hello Folks, >>> >>> I fired up pidgin via the cmd line and get the following error: >>> >>> $ pidgin >>> >>> (pidgin:25897): GStreamer-CRITICAL **: gst_element_register: assertion >>> `g_type_is_a (type, GST_TYPE_ELEMENT)' failed >>> >>> ERROR: Caught a segmentation fault while loading plugin file: >>> /usr/lib64/gstreamer-0.10/libgsttcp.so >>> >>> Please either: >>> - remove it and restart. >>> - run with --gst-disable-segtrap and debug. >>> >>> Is there something I can do to fix this and get my stuff working >>> again ? Empathy has the same issue. >>> >>> Cheers, >>> >>> ASD. >> >> >> Someone may, or may not, tell you sooner or later that you need to start >> a new thread instead of just changing the header of and existing thread >> if you expect anyone to help you. No grief friend. Just trying to help. -- David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Pidgin Issue, F11 64bit
On 6/26/2009 11:01 AM, Aly Dharshi wrote: > Hello Folks, > > I fired up pidgin via the cmd line and get the following error: > > $ pidgin > > (pidgin:25897): GStreamer-CRITICAL **: gst_element_register: assertion > `g_type_is_a (type, GST_TYPE_ELEMENT)' failed > > ERROR: Caught a segmentation fault while loading plugin file: > /usr/lib64/gstreamer-0.10/libgsttcp.so > > Please either: > - remove it and restart. > - run with --gst-disable-segtrap and debug. > > Is there something I can do to fix this and get my stuff working > again ? Empathy has the same issue. > > Cheers, > > ASD. Someone may, or may not, tell you sooner or later that you need to start a new thread instead of just changing the header of and existing thread if you expect anyone to help you. -- David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
RE: Why do we need FC version attached to the package name?
The problem is preupgrade normally pulls from release + updates, pulling from the DVD even now will not work because F10 + updates has newer file versions than are on the DVD. -Original Message- From: fedora-devel-list-boun...@redhat.com [mailto:fedora-devel-list-boun...@redhat.com] On Behalf Of Alexander Boström Sent: Wednesday, June 24, 2009 12:16 PM To: Development discussions related to Fedora Subject: Re: Why do we need FC version attached to the package name? Den 2009-06-24 11:37, Simon Andrews skrev: > So, just to be clear here. Anyone who either has no network connection > or whose network connection is too slow to support downloading > potentially hundreds of megs up updates isn't going to be able to > upgrade any more? Preupgrade could install a hook that recognises distro DVDs (or even CDs) when inserted in a running system, prompting the user "Would you like to upgrade to ?", which would just run Preupgrade as usual, copying packages off the disc if possible. /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit and malware, was: What I HATE about F11
Hi, (once again, with manually adding f-d-l to the To field, since the fedora-devel-list mailman setup is broken) On Tue, 2009-06-23 at 19:42 +0200, Kevin Kofler wrote: > > An example where 1. is useful includes, funny enough, a last guard > > against having malware dial 1-900 numbers in other countries at $50 per > > hour > > That scenario has malware in it. Your attitude is really annoying. Try reading my message again. And, gee, maybe try googling for "security in depth" or "layered security". David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit and malware, was: What I HATE about F11
Hi, (I'm not subscribed to fedora-devel so if you want replies from me don't remove me from the Cc.) On Tue, 2009-06-23 at 12:27 -0400, Kevin Kofler wrote: > David Zeuthen wrote: > > Anyway, the goal of PolicyKit isn't to fix the "cope with malware in > > your session" problem. That problem is much much harder to fix and it > > requires us to depart from the model where the whole user session is a > > single security context. > > Then why does it prompt for authentication at all? It could just as well > just let the user do everything without a password, he/she's already > authenticated due to the login. Prompting for passwords again makes sense > to protect against malware, but what else? Users who left their desktop for > a while? It's their responsibility to lock the desktop. Because it is desirable to verify that either 1. The person in front of the system really is the logged-in user and authorizes an action 2. The person in front of the system really is an administrator An example where 1. is useful includes, funny enough, a last guard against having malware dial 1-900 numbers in other countries at $50 per hour - e.g. NetworkManager should only allow connections previously marked as trusted to use the modem to dial out. (OK, so having malware in the first place is bad... having it cost you $50/minute because someone wasn't thinking right when designing the OS is even worse. So this guard really is warranted. Notably Windows has suffered from this issue and it is naive to think that the Linux desktop won't suffer from this once we get many more users than the 1% of the market we have right now.) An example where 2. is useful includes lockdown - e.g. as a head of household you may restrict other users from installing new software while still allowing them to update existing software providing it is signed. So you ask for administrator authentication. There are many other examples. Just use your imagination. David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090619 changes
2009/6/20 Ben Boeckel > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > David Nielsen wrote: > > > 2009/6/19 Peter Robinson > > > >> > >> mono-tools-2.4.2-1.fc12 > >>> --- > >>> * Tue Jun 09 2009 Paul F. Johnson johnsons.co.uk> - 2.4.2-1 > >>> - Bump to 2.4.2 preview 1 > >>> - Add support for ppc and ppc64 > >>> - Add label for udev-acl > >>> > >>> > >> is there any reason why mono doesn't use the 0.x revision > tags for > >> alpha/beta/RC releases like everyone else? > >> > > > > Plenty of projects fall outside that naming scheme, it's > unfortunate but > > that is life. Maybe upstream will consider your thoughts on > the matter if > > you bring them to their attention. > > > > - David > > > This is not an upstream issue, but a packaging one. Release: > 0.x is how you should mark prereleases so that -1 is the actual > release. > > Example: > kde-plasma-networkmanagement-0.1-0.12.20090519svn.fc11.x86_64 > > k-p-nm-0.1 can have a Release: 1 with this scheme. > My apologies. - David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090619 changes
2009/6/19 Peter Robinson > > mono-tools-2.4.2-1.fc12 >> --- >> * Tue Jun 09 2009 Paul F. Johnson - 2.4.2-1 >> - Bump to 2.4.2 preview 1 >> - Add support for ppc and ppc64 >> - Add label for udev-acl >> >> > is there any reason why mono doesn't use the 0.x revision tags for > alpha/beta/RC releases like everyone else? > Plenty of projects fall outside that naming scheme, it's unfortunate but that is life. Maybe upstream will consider your thoughts on the matter if you bring them to their attention. - David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit and malware, was: What I HATE about F11
Hi, On Thu, 2009-06-18 at 21:11 +0100, Richard W.M. Jones wrote: > On Thu, Jun 18, 2009 at 03:02:53PM -0400, Matthias Clasen wrote: > > On Thu, 2009-06-18 at 19:09 +0100, Richard W.M. Jones wrote: > > > Can the malware inject code into the process which gained the > > > authentication (eg. using ptrace)? > > > > Once you have malware running in your session, there's probably more > > important stuff to worry about, like all your data in ~/.firefox... > > Right, but this is about privilege escalation (malware trying to gain > root). However I agree that it's bad enough if you have any malware > in your session. > > I'm only interested BTW. I'm not saying this is a real exploit :-) As others have said, if you have malware in your session then you've basically lost already. The observation to make here is that for truly dangerous stuff, such as installing unsigned software (PackageKit) or running programs as root (pkexec), you _always_ use one-shot authorizations. There is even a facility to customize what is shown to the user in a way that is not spoofable [1]. But for e.g. applications where you repeatedly need to continuously do operations over and over again, such as a disk utility app for example, it's not really convenient having to type in your password over and over again. As noted in many many places about both usability and security, authentication dialogs are, in general, bad - they don't really add any real security, they confuse users and they disrupt workflows. So for applications where the authorization to do stuff is kept (for a limited time and only limited to the process doing it), sure, malicious code running as the same uid can inject code and take advantage of that authorization. It doesn't even need to use ptrace, there's a lot of other well-known ways to inject code. Including, but not limited to taking advantage of the windowing system (e.g. X11) and the accessibility framework. But the point is really that said malicious code can't do a lot of harm. At worst it can manage your networks, update installed packages with newer signed versions and, if the user happens to run the disk utility app, format some disks that are not already mounted and maybe change the time zone. Not very exciting, compared to some much higher value targets in e.g. ~/.firefox or ~/.evolution. Of course, if the user wanted, he could configure PolicyKit so it always prompts for authentication whenever the user requests services from a Mechanism. Or you can use the existing nullbackend (shipped with polkit) to always deny service (it's what you want to use for servers). But then you turned a relatively good desktop user experience into a horrible one. Ie. not worth the effort. Unless maybe you are the DoD (and that's exactly why PolicyKit is pluggable so orgs/sites/etc can define their own authorization policy.) Anyway, the goal of PolicyKit isn't to fix the "cope with malware in your session" problem. That problem is much much harder to fix and it requires us to depart from the model where the whole user session is a single security context. Hope this clarifies. David [1] : except of course that right now the authentication agent runs in your user session. This means it is susceptible to the same attacks as anything else in the session including ptrace and xspy. So you can easily inject code into this process to capture passwords or spoof dialogs. Anyway, the way we want to solve this is to add a "secure" desktop. Whenever we have the need to prompt the user for a password, we bring up the "secure desktop". This would be a completely different session using a separate X server and with only well-known and trusted programs running in it. We'd run, ideally, all password prompts in this session. User-experience-wise the user won't notice this implementation detail since we can composite it to run on top of the normal desktop. We'd want to make it hard to spoof though - there's a couple of well-known ways to do this as well (make it show something your sessions can't know, make it do something your session can't do (require you press ctrl+alt+del)). Users of this "secure desktop" would include - PolicyKit Authentication Agents - Screensaver - GVfs - the gvfs backends needing the passwords don't use UI so it is possible to secure these programs so you can't get to them via ptrace - Other things needing passwords - IM programs such as Empathy - ... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: PolicyKit and malware, was: What I HATE about F11
Hi, This is an accurate description of how things work, thanks to Matthias for clearing things up on this list. There's more background information about this particular thing here http://hal.freedesktop.org/docs/polkit/ http://hal.freedesktop.org/docs/polkit/PolicyKit-1.8.html http://hal.freedesktop.org/docs/polkit/pkexec.1.html in the docs. In the future please direct questions/concerns/etc about to the polkit-devel mailing list, see http://lists.freedesktop.org/mailman/listinfo/polkit-devel before taking misinformation to non-upstream lists. Thanks. David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: BTRFS in 2.6.31-rcwhatever
2009/6/18 Matej Cepl > Josef Bacik, Wed, 17 Jun 2009 12:27:34 -0400: > > Btrfs will not be as stable as ext4 currently is for at least another > > year, so it is still very much just for testing. I am very interested > > in hearing about bugs and getting them fixed, however there will be > > little to nothing that I can do if you lose data. > > And just to increase appetite of masochists among us, this is meant very > seriously ... I have lost /var partitions on two computers (Fedora > without /var/lib/rpm is very interestig animal). Pray without cessation > and have your backups ready. Btrfs has been surprisingly good for me, no problems outside claiming the partition was full when there was 25gb left (on a 120gb drive). I say bring on this update, hilarity and dataloss, they do mix no matter what sanity says. - David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: using CD/DVD as media
On 6/17/2009 4:40 PM, Muayyad AlSadi wrote: >>> notice that I asked about "new UI for media change" >>> I guess it means a dialog box which says "please insert the disk label >>> so and so" >> >> I know of *no* distribution that does this. Sorry. >> >> > most of them do that > and mandriva was mentioned in this thread [not by me] > I give up trying to reason with you. Bye. -- David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: using CD/DVD as media
On 6/17/2009 3:27 PM, Muayyad AlSadi wrote: >> I believe that the way to do this is to *write* a repo configuration >> file that *points* to the DVD drive. Which is what that article said to >> do. And no you can not put the disk in the drive and expect the GUI >> applications to add it for you. >> >> And that, I don't think, is considered a 'bug'. So if you want this to >> change you need to write a Bugzilla RFE. Not a Bugzilla bug. That would >> put you in direct contact with the developer and not a common user like >> I am. >> > hello!! > you miss the key point here, the media is REMOVABLE and you need to > handle media insertion and removal > > notice that I asked about "new UI for media change" > I guess it means a dialog box which says "please insert the disk label > so and so" I know of *no* distribution that does this. Sorry. -- David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: using CD/DVD as media
On 6/17/2009 3:10 PM, Muayyad AlSadi wrote: >> It appears that existing media sources can be enabled or can be disabled >> in the GUI by marking the check boxes or unmarking the check boxes. In >> my Fedora 11 it does not show a CD or DVD source. You would have to add >> them, as in the example that I pointed to earlier, yourself. From what I >> read it works. I can not really confirm that because I have not done >> that. Nor will I because it is not what I want. >> >> Similar to yumex. >> >> -- > > a bit you can't add the media itself as a repo [not a copy of it nor a > file:// something I'm talking about the removable media] > > not in PK nor yumex nor any other tool I'll say this one last time. Then I am done with this. I believe that the way to do this is to *write* a repo configuration file that *points* to the DVD drive. Which is what that article said to do. And no you can not put the disk in the drive and expect the GUI applications to add it for you. And that, I don't think, is considered a 'bug'. So if you want this to change you need to write a Bugzilla RFE. Not a Bugzilla bug. That would put you in direct contact with the developer and not a common user like I am. Have a good day. -- David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: using CD/DVD as media
On 6/17/2009 3:30 AM, Muayyad AlSadi wrote: >> Note that this is of only very limited usefulness because packages often >> have updates available anyway. > > on the contrary this feature is very important for people who got no > or slow internet connection, and in my country this is almost always > the case > > in that case one won't mind getting an older openoffice.org than > downloading tons of mega bytes. > and even if one wants the latest oo.o he could install it from DVD > then use presto to save bandwidth > >> The closing is done automatically, not by humans, so there's no way that >> bugs that are 'obviously' still valid can be excepted. > >> You have already said that you *know* how to do this. May I suggest that > you do it then? > > I'm not here to complain about closing the bug nor to ask how to make > a local repo > I'm here to ask what does the "new UI for media change" mean in the PK update > https://admin.fedoraproject.org/updates/FEDORA-2009-5748 It appears that existing media sources can be enabled or can be disabled in the GUI by marking the check boxes or unmarking the check boxes. In my Fedora 11 it does not show a CD or DVD source. You would have to add them, as in the example that I pointed to earlier, yourself. From what I read it works. I can not really confirm that because I have not done that. Nor will I because it is not what I want. Similar to yumex. -- David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
On Wed, 2009-06-17 at 02:55 +0200, Kevin Kofler wrote: > Bruno Wolff III wrote: > > Is there going to be a way to tell which binaries actually use sse2 > > instructions, so that the others can be inherited by a secondary arch? > > Due to how GCC works, if the compiler flags enable SSE/SSE2, basically all > the binaries will be using some SSE/SSE2 instructions. And on the various SSE-capable CPUs, how much benefit does that actually give us? I'm after a system-wide answer, not a microbenchmark for zlib or crypto code. It should take into account any overheads involved in saving/restoring registers on context switch that wouldn't otherwise have to be saved/restored. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: using CD/DVD as media
On 6/16/2009 10:16 PM, Mani A wrote: > David wrote: > >> To have the DVD *always* as a source to check for packages is a pain in >> the neck IMO. >> >> Mandriva does that. The install DVD is a default source. *Every time* >> that you try to *install*, or *update*, you have to find and insert the >> DVD for it to check it for the disired package(s) *and* their >> dependencies as well as the online repos. >> >> Everyone that I know that uses Mandriva *disables* that 'feature' as one >> of the very first things that they do. > > > I think this behaviour should be changed in Fedora. At least for the > first update, the media should be used by Yum (and others). > > It will also be very useful for people doing upgrades from earlier > versions of Fedora with a DVD (instead of yum). Yum went for a 2.2GB+ > update after a F10 --> F11 upgrade with a DVD in one desktop system > and many of the packages were on the DVD. Do I understand 'you' correctly? I use 'you' for the "very useful for people". Okay? *If* 'you' downloaded the *whole* 3.4G Fedora 11 DVD so that 'you' could upgrade an installed Fedora 10 machine and the upgrade installed *some* of the packages from the DVD and downloaded and installed *some* of the packages from The Internet that would not make sense to me? Some of the packages on the DVD that 'you' just downloaded where updated the same day Fedora 11 was released. So those files, that 'you' just downloaded in the ISO, were already old and not used. The newest ones, and their dependencies, were downloaded anyway. Many of the packages on the DVD which 'you' just downloaded where probably not used at all anyway. But you just downloaded them in the ISO. If you had several, many, machines to upgrade that could make some sense. But not for one machine. Or two very different setups. I actually did an upgrade of a Fedora 10 Desktop system to Fedora 11 as a test. A Fedora 10 install up-to-date the day that I did it. My download total was less that 900M. No where near the 3.4G DVD or the extra packages they 'you' would have downloaded. So please explain to me how that would have saved "very useful for people" any time and any bandwidth? -- David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: using CD/DVD as media
On 6/16/2009 4:58 PM, Muayyad AlSadi wrote: >> Second hit on the first page. >> >> http://lmgtfy.com/?q=fedora+repo+dvd > > do you think I'm that stupid! > > I'm not asking how can I install packages from the DVD > > I'm asking when will that be implemented in PK > and how does PK support a "UI helpers for media changing" > while it does not support media in the first place > > what UI helper? > I did not imply that you are stupid. I posted that with a smile. Did you not see it? To have the DVD *always* as a source to check for packages is a pain in the neck IMO. Mandriva does that. The install DVD is a default source. *Every time* that you try to *install*, or *update*, you have to find and insert the DVD for it to check it for the disired package(s) *and* their dependencies as well as the online repos. Everyone that I know that uses Mandriva *disables* that 'feature' as one of the very first things that they do. You have already said that you *know* how to do this. May I suggest that you do it then? -- David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: using CD/DVD as media
On 6/16/2009 4:05 PM, Muayyad AlSadi wrote: > hello, > > I filed RFE bugs claiming that in fedora we have no way to use the DVD as a > repo > including PK, yum cli,yumex, apt-get, smart, ... > I tried all the tools and non can add a DVD as a media repo > > all my bugs were closed by Bug Zappers and asked me to reopen them > although it was clearly not solved > > eg. https://bugzilla.redhat.com/show_bug.cgi?id=435625 > > I was fooled by this update > https://admin.fedoraproject.org/updates/FEDORA-2009-5748 > > which says > - Add UI helpers for media changing > > so PK does support media changing but does not support media!! > this does not make sense to me > > did I miss something > Second hit on the first page. http://lmgtfy.com/?q=fedora+repo+dvd :-) -- David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
RE: Split Media - A use case
Use case : PIII 950Mhz system CDROM installed , no DVD, NO USB boot option , no PXE boot option, local network does not allow DHCP server ( corp rules) , local net is firewalled from internet via (http | ftp) proxy Yes it's old It was running F10 It _Needs_ split CD to install Anaconda takes forever because it won't accept proxy info and has to mutiply time out trying to access unreachable network mirrors -Original Message- From: fedora-devel-list-boun...@redhat.com [mailto:fedora-devel-list-boun...@redhat.com] On Behalf Of Michael Cronenworth Sent: Monday, June 15, 2009 10:25 AM To: Development discussions related to Fedora Subject: Re: Split Media - A use case G.Wolfe Woodbury wrote: > That's what they wanted to use :-) besides it was quicker to gen > them than to download the live CDs or DVDs. > CDs will be much slower than a DVD in terms of read speed. You'll also have to swap disks out during install (hello 1998). Why do they "want" to use CDs? In fact, why are you wasting a DVD or CDs? That's not very green of you. Give them a USB stick with the DVD install ISO loaded on it so it can be reused for more useful things. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: What I HATE about F11
On 6/13/2009 10:19 PM, Charles Butterfield wrote: > Okay, so I mostly love Fedora. However, here are 4 things that got by > blood really, really boiling, so I thought I’d share my emotions. They > are mostly policy issues, where I think you have gotten it very very wrong. > > > > Just installed F11 64 bit, here are the things I hate about it in the > first 30 minutes (of course there are a lot of things I like too, but > they work, these don't). No doubt more will crop up. > > * Root gdm login - gets harder every release - SHAME ON YOU root nazis! > * Samba (outbound) browsing requires firewall mods > * Jamming SELinux enforcing mode with no query during install > > And a bug: > > * My "supported" NVIDIA card (Quadro NVS 295) is not detected - okay > this may not be due to overt, mulish arrogance, but I did check > the supported card list and it is really annoying. > > > The first 3 items are just freaking absurd and represent some sort of > political agenda combined with astonishing arrogance. > > Is a graphical root login dangerous -- of course! So are a lot of > things, which have obvious enable/disable controls. Was this this > discussed in the release note? - NO. Should it be inhibited by an > ever-increasing set of obscure work-arounds (in this case an new file to > edit in F11)? Of course not. (Well as was pointed out to me in thread > http://forums.fedoraforum.org/showthread.php?t=223793 this is > discussed... but in non-highlighted text at the end of the boring last > bullet suggesting you “save and close”). > > > And why on earth show the stupid "Windows Network" if it doesn't work -- > just gives an obscure error message "Failed to retrieve share list from > server". If you install the client, the reasonable man would open the > ports, OR provide a cluefull error message. > > SELinux - enforcing So all the bugs are worked out? I think not. > > > > > > Regards > > -- Charlie Butterfield > > > > P.S. Here is a bit more context: > > > > Bob -- Thanks for the tip, I did NOT realize the developers didn't scan > the forums. I have been using Fedora since FC2 (I think), and overall > think its great, esp as a bleeding edge incubator for RHEL/CentOS. BUT > there are some annoying trends occurring that finally pushed me over > rant/no-rant threshold. > > Dan -- I like all manner of stuff, but what caused me to just wipe my > CentOS 5.3 root partition and replace it with F11 was a desire to get > the relatively new GNOME gvfs stuff -- so I can manipulate remote > windows shares with any tool, not just GnomeVFS aware tools. > > On a higher level I am amazed and impressed by the creative outpouring > from the various Open Source communities, although it is also a stark > reminder of the fact that programmers hate, hate, hate documentation :-) This is an interesting debate that you all are having here. But has anyone, other than me that is, noticed the complete absence to the OP, Mr. Charlie Butterfield, after his original rants? Or would this be trolling? ;-) BTW. Great job on Fedora 11. -- David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: x86_64 kernel + i586 F11 userspace + yum
On Tue, 2009-06-09 at 16:56 +0100, Paul Jakma wrote:
> Hi,
>
> I run the above system, and everything works fine (except perhaps for
> SELinux[1]). I have created a /etc/rpm/platform containing
> 'i586-redhat-linux'.
>
> Well, everything works except for one thing: yum. Installing with
> 'yum install name' no longer works, I must now instead explicitly
> specify the arch, e.g. 'yum install name.i58'.
>
> Does anyone know a fix for this?
>
> Also, if I explicitely add the x86-64 updates repo, and only include
> the 'kernel' package from it, should I be able to expect that yum
> update will Do The Right Thing, or will I need to manually 'yum
> install kernel.x86_64' whenever kernels are updated (or worse)?
>
> Thanks.
>
> 1. Least, I presume this is SELinux related:
>
> SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses
> genfs_contexts
> ioctl32(mount:1503): Unknown cmd fd(3) cmd(80041272){t:12;sz:4}
> arg(ffb0eb68) on /home/xguest
> ioctl32(mount:1503): Unknown cmd fd(3) cmd(1260){t:12;sz:0}
> arg(ffb0eb70) on /home/xguest
> ioctl32(mount:1503): Unknown cmd fd(3) cmd(801c0204){t:02;sz:28}
> arg(ffb0eb4c) on /home/xguest
>
> regards,
> --
> Paul Jakmap...@clubi.ie p...@jakma.org Key ID: 64A2FF6A
> Fortune:
> "But officer, I was only trying to gain enough speed so I could coast
> to the nearest gas station."
>
I don't think this is a problem with SELinux just an unfortunate case of
being close to the error. What I think is happening is that the utility
that is trying to call ioctl is passing the wrong value into cmd. In
this case it is passing a command that the particular filesystem/device
doesn't understand.
Dave
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, Jun 5, 2009 at 6:23 AM, Bastien Nocera wrote: > Heya, > > Yesterday, I was browsing Ubuntu's "Blueprints" for their next release, > and saw this: > https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnomescan > > gnome-scan is already packaged by Deji, but I gather that more > integration work could be done to make setting up and using scanners > easier in GNOME and Fedora in general. > > Any takers? > > I think a good start would be making a list of problems seen in setting > up scanners (additional packages required, tweaks), and make sure that > gnome-scan and the necessary plugins are installed in a default > installation. > > Cheers > > /Bastien, who doesn't own a scanner > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I'd be very interested in helping with this, scanning is one of the most abhorrently performing niches in Linux that I've dealt with recently. $dayjob essentially grants me access to a plethora of high-end Fujitsu, Kodak, Bell & Howe, and Xerox scanners. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about web applications
On Thu, Jun 4, 2009 at 7:33 AM, Paulo Cavalcanti wrote: > > > On Thu, Jun 4, 2009 at 8:00 AM, David Nalley wrote: >> >> On Thu, Jun 4, 2009 at 6:23 AM, Paulo Cavalcanti wrote: >> > Hi, >> > >> > I submitted ampache (http://ampache.org/) for review, but I was told >> > that it >> > could not use any external software >> > bundled in the code. In fact, it uses getid3, a file that seems to come >> > from >> > horde (horde/Browser.php), >> > and some others. >> > >> > According to the weekpedia (http://en.wikipedia.org/wiki/Ampache) >> > >> > "Ampache has been featured in numerous online blogs and technical >> > articles. >> > One of the more notable was the O'Reilly book Spidering Hacks which >> > tested >> > the security of online applications. Ampache was found to be immune to >> > standard spidering hacks as described in the O'Reilly article, and it >> > has >> > continued that trend by focusing on security during its development. The >> > Code Philosophy listed on Ampache's wiki specifically lists security as >> > one >> > of those most important considerations during application development." >> > >> > Does it make any sense to fiddle something that has always had security >> > as a >> > prime concern? >> > >> > Any comment is welcome. >> > >> > Thanks. >> > >> > -- >> > Paulo Roma Cavalcanti >> > LCG - UFRJ >> > >> > -- >> > fedora-devel-list mailing list >> > fedora-devel-list@redhat.com >> > https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > >> >> >> Perhaps I am the least well suited to respond as I did some of the >> initial review. > > No, on the contrary. > >> >> However, there are at least 10 bundled libraries with ampache, >> including pear-XML_RPC, nusoap, getid3, small snippets from Horde, >> captchaphp, php-Snoopy, etc. >> >> In addition to the security benefits, creating the separate package >> means other packages (even other web apps) can make use of the >> libraries that would be available in Fedora instead of just ampache. >> I can empathize with the extra work that this causes, as I am trying >> to fix a few of these problems with another web app. >> > > Maybe we can list all of the packages we would like to have for web > applications, and try to set a "task force" to cope with them? > > I think if we had three or four people willing to help, the work would be > concluded fast. There are always people looking forward to contributing, > but without a good package to work with. > I think that's an outstanding idea, and I'd be willing to work towards such an end, and perhaps since there is such a prevalence of php we can get some buy-in from the php-sig as well. To illustrate some of the usefulness - I have a web app I am working on now that uses php-Snoopy as ampache also does, so that's at least two applications that can make use of the package. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about web applications
On Thu, Jun 4, 2009 at 6:23 AM, Paulo Cavalcanti wrote: > Hi, > > I submitted ampache (http://ampache.org/) for review, but I was told that it > could not use any external software > bundled in the code. In fact, it uses getid3, a file that seems to come from > horde (horde/Browser.php), > and some others. > > According to the weekpedia (http://en.wikipedia.org/wiki/Ampache) > > "Ampache has been featured in numerous online blogs and technical articles. > One of the more notable was the O'Reilly book Spidering Hacks which tested > the security of online applications. Ampache was found to be immune to > standard spidering hacks as described in the O'Reilly article, and it has > continued that trend by focusing on security during its development. The > Code Philosophy listed on Ampache's wiki specifically lists security as one > of those most important considerations during application development." > > Does it make any sense to fiddle something that has always had security as a > prime concern? > > Any comment is welcome. > > Thanks. > > -- > Paulo Roma Cavalcanti > LCG - UFRJ > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Perhaps I am the least well suited to respond as I did some of the initial review. However, there are at least 10 bundled libraries with ampache, including pear-XML_RPC, nusoap, getid3, small snippets from Horde, captchaphp, php-Snoopy, etc. In addition to the security benefits, creating the separate package means other packages (even other web apps) can make use of the libraries that would be available in Fedora instead of just ampache. I can empathize with the extra work that this causes, as I am trying to fix a few of these problems with another web app. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Thu, Jun 04, 2009 at 08:59:23AM +0200, Ralf Corsepius wrote: > Kevin Kofler wrote: >> Steve Grubb wrote: >>> Not if its closed. How would I be notified that the fix is in Fedora? If >>> the bug is severe enough, shouldn't the upstream commit be applied to >>> Fedora's package and the package pushed out for testing? Is all this going >>> to happen if the bug is closed? >> >> You're supposed to be the reporter of or CCed on the upstream bug, then >> you'll get notified of the fix and can reopen our bug asking for a backport >> of the fix if it's really that important (but keep in mind that Fedora >> packages often get upgraded to a bugfix release anyway, for example our KDE >> gets upgraded to a bugfix release about once a month). > You are still presuming your users to be interested in developing and > working on your package. > I think it has been already mentioned in this thread, but I'm going to mention it again (in, probably void, hope you'll understand it): One of principles of open source development is a relationship between the developer and the user. If the relationship be functioning rightly, the user should be willing _to give_ something back, not just _to take_. > This simply does not apply - They want to use your package. If you don't accept that, go on and buy RHEL or SLED or MacOS X or even MS Windows and you'll get the attendance you expect. Maybe. Maybe not. Maybe product management decides your bug is not important enough or your request for enhancement wouldn't be wanted by majority of users and rejects it... As a last instance, you can always hire a free lance programmer to fix the bugs for you, provided you have the sources and rights to modify them. David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Thu, Jun 04, 2009 at 07:23:05AM +0200, Ralf Corsepius wrote:
> Steven M. Parrish wrote:
>
>> Many people have mentioned that it is not right to ask the users to
>> file their bug reports upstream. I ask why not?
>
> Let me summarize what I already wrote elsewhere in this thread:
> * Users aren't necessarily developers.
> * Users aren't necessarily interested in getting involved upstream.
> * Users are reporting bugs against your product (your package in
> Fedora), not against upstream's work (somebody else's product).
>
>
> Let me try an analogy: How do you handle defects/malfunctions with your
> car?
>
> You'll visit your car dealer/a garage and report the issue to them.
> You'll expect them to identify the problem and to take appropriate steps
> to solve your issue.
Let me try another analogy: How do you handle health problems?
You'll visit your doctor. You'll expect him to identify the problem and
to take appropriate steps to solve your issue--that may well be just him
sending you to a specialist. Would you expect your doctor to serve as a
proxy between you and the specialist? Or even substitute you for
checkup? I wouldn't.
> You don't expect them to direct you to the car's
> manufacturer or a component manufacturer and to discuss technical
> details you have no knowledge about with them ("Is the stuttering engine
> cause by triac 7 in a component A you haven't heard about before" or by
> the hall sensor in component B you also haven't heard about before).
>
Who spoke about technical details? Have you ever been asked to look into
the source code of some project? I don't think so. An upstream developer
can ask better/more detailed questions than a packager, but that's only
to be expected.
Btw, I'm really interested to hear why answering questions of an
upstream developer through a packager as a proxy is better than
answering the same questions directly...
David
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Tue, 2009-06-02 at 16:17 -0400, Steve Grubb wrote: > > I don't want to start a long thread, but just to ask a couple questions for > my > own clarification. Does a maintainer's responsibilities end with packaging > bugs? IOW, if there is a problem in the package that is _broken code_ do they > need to do something about it or is it acceptable for them to close the bug > and say talk to upstream? There are _some_ kinds of bug (feature requests, etc.) which it's reasonable for any decent maintainer to punt upstream. There are other kinds of bugs (crashes, security issues -- perhaps even _anything_ that's a real bug rather than an RFE) which the maintainer really _ought_ to deal with directly. Opinions vary on precisely where the boundary between those classes should be, but I'm fairly adamant it should be 'RFE vs. bug'. Any packager who _isn't_ capable of handling the latter class of bug probably shouldn't be maintaining the package without the assistance of a co-packager or their sponsor. Note that you don't _have_ to be able to code to handle a real bug in an acceptable fashion -- decent coordination with upstream can be perfectly sufficient, if upstream are responsive enough. But just closing the bug in our bugzilla as 'upstream' is rarely acceptable for a _real_ bug, IMHO. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
