Re: Unity For Fedora (As in OpenSUSE or Arch)
On Wed, 01 Feb 2012 17:00:30 -0700 Adam Williamson wrote: > I realize this isn't a very constructive mail, and the point has been > raised before, but I'm hoping at some point the sheer weight of > complaints will cause someone more creative than myself to actually > come up with a notification system for GNOME 3 which satisfies the > GNOME design team and *also* does not suck. Is there a bug we can vote on? I also agree 100% with this, I rather like gnome-shell except for this 'notification system'. --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Matthew Garrett wrote: > Because it is the job of people who are proposing a spec to answer the > objections of the people who perform critical analysis of the spec They did answer. You just didn't like their answer. It's the GNOME developers who stopped replying. The KDE developers were willing to clarify their spec, but not to make incompatible changes with no practical benefits (such as renaming Movie to Animation in an identifier) nor to specify rendering (which is a non-goal of the spec), up to the most minute detail even (e.g. the position of the overlay on an icon), as the GNOME developers demanded (not "requested", or they wouldn't have run away when the KDE developers explained why they cannot make those changes). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi critical path updates policy adjustment
Adam Williamson wrote: > We'll keep it around, but I'll update the wiki pages to note that it's > kinda 'dormant' for now. I'm hoping that with Bodhi 2.0 we'll be able to > re-design the process and utilize proventesters in a better way. How about just requiring 1 proventester +1 *or* 2 regular +1s instead of the current "any 2" or the previous "1+1" rule? A proventester should be trusted, so why require a second +1 if the first one was from a proventester? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Random koji problems
On 02/01/2012 12:24 PM, Jerry James wrote: > Yes, the buildroots are both fine now. Thanks for fixing them. I was > just responding to spot's apparent surprise that an updated libvpx in > the buildroot should have broken package building for other people. Indeed, I'm a little horrified at how deep of a dep tree has gstreamer-plugins-bad-free at its top. xulrunner is also now built in rawhide, so all the libvpx broken deps are now resolved. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On 02/01/2012 05:00 PM, Adam Williamson wrote: On 2012-02-01 11:39, Florian Müllner wrote: Because the "integrated experience" means that there is a fixed set of system items with a defined order. Extensions can be used to "hack" the intended experience (which includes adding "non-official" icons in the top bar), but it's nothing we want normal applications to do. Applications are encouraged to interact with the message tray (== the autohiding bottom panel) via freedesktop notifications (yay, cross-desktop! ;-) Yay cross-desktop maybe, but still a freaking disaster from a UI point of view, and the only thing I really dislike about GNOME 3 (when I was forced to drop to Xfce for a couple of days last week, the old-school notifications were the only things I preferred). That sometimes-hidden, erratically-triggered notification area *never* seems to do what I actually want it to do. It shows up when I don't want it, it doesn't show up when there's something on it I probably actually needed to see, the icons on it fly around like space invaders and take two or hree clicks to get rid of, transmission 'torrent completed' notifications stack to the moon and back...it's just not nice. I realize this isn't a very constructive mail, and the point has been raised before, but I'm hoping at some point the sheer weight of complaints will cause someone more creative than myself to actually come up with a notification system for GNOME 3 which satisfies the GNOME design team and *also* does not suck. Me too. I can't stand that bottom corner area. I can't stand how they fly around left and right like they are dodging my mouse. Do I right click left click... some stick around forever... Seriously annoying. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Thu, Feb 02, 2012 at 02:21:01AM +0100, Kevin Kofler wrote: > If you think the version as written does not guarantee interoperability, why > don't YOU propose a version which you think does? Because it is the job of people who are proposing a spec to answer the objections of the people who perform critical analysis of the spec. It's not Gnome's job to write a specification for something that KDE wants. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi critical path updates policy adjustment
On Thu, 2012-02-02 at 02:58 +0100, Michel Alexandre Salim wrote: > On 02/02/2012 01:19 AM, Luke Macken wrote: > > FESCo recently made an adjustment to the updates policy to no > > longer require proventester karma for a critical path update to be > > deemed as stable. > > > > Critical path updates will now require just one regular +1 karma > > vote during the pre-beta phase and two regular +1 karma votes in > > other phases to be pushed to the stable updates repo. Anonymous > > karma is not taken into account. > > > Is the "proventester" group getting phased out as well? Or will it be > repurposed for something else? We'll keep it around, but I'll update the wiki pages to note that it's kinda 'dormant' for now. I'm hoping that with Bodhi 2.0 we'll be able to re-design the process and utilize proventesters in a better way. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi critical path updates policy adjustment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/02/2012 01:19 AM, Luke Macken wrote: > FESCo recently made an adjustment to the updates policy to no > longer require proventester karma for a critical path update to be > deemed as stable. > > Critical path updates will now require just one regular +1 karma > vote during the pre-beta phase and two regular +1 karma votes in > other phases to be pushed to the stable updates repo. Anonymous > karma is not taken into account. > Is the "proventester" group getting phased out as well? Or will it be repurposed for something else? Thanks, - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPKe22AAoJEEr1VKujapN6AUoIAJwrYgEgYnN1RTWkWqhY0vO2 mAK67deCxfURLmAeCiXV5O0MICygmyyg07U5+OP4FhlYVFQqydSdhKk/28vmfGCM aT4wbv1KepOlcSdLnnap2BZ+VVBz7Cr7rxIcXc9PprNSdAisBy90YbfIPuPxPz4W VSu20smNF8KDDnH82RcX/er1OC7zCWqzEw6Ot5BRPAV8MKVSZbb/xPbaehHmAEhJ VggvZgfwGNpYVsMtkHOgBVT1g2oQ5Ua6OmgxTfnmJ2Xkxhei4vXNYWrU/hn2WuH2 bCqjeXCt/YUG2iBpclVdwmcg3oPcN6s4i0jADlmxtFsD7gpNOIBrKTAi5tOW9ck= =tJ9A -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-up: soname-bumped bind landed in Rawhide without announcement
On Wed, 2012-02-01 at 17:19 -0800, Adam Williamson wrote: > A note for all: bind-9.9.0-0.7.rc2.fc17 , which was built for Rawhide > today, bumps the soname of at least /usr/lib64/libdns-export (from 92 to > 93), but this API compatibility change wasn't announced. Best check if > any package you own that depends on bind is affected and needs a > rebuild. > > It looks like the other affected lib is /usr/lib64/libdns (also went > from libdns.so.92 to libdns.so.93). The libraries versioned *.so.90 do > not appear to have had their soname bumped, they're .90 in both rc1 and > rc2. > > atkac, in future, please announce API-incompatible bumps like this > before you do them, as is required by the policy. Thanks! Addendum - I've rebuilt dhcp (which includes dhclient) and dnsperf, those are the two most prominent deps. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Matthew Garrett wrote: > It can be completely unusable. There's no way to design an application > that will work with all valid implementations. Sure there is. Just provide the data and let the implementation worry about how it is displayed. > Yes, but it's not about visual uniformity. It's about ensuring that > information is presented. The fact that the information is provided to be presented and not ignored is blatantly obvious to everyone other than you, the GNOME developers. > If the point is interoperability then just propose a version of the spec > that actually guarantees useful interoperability. If you think the version as written does not guarantee interoperability, why don't YOU propose a version which you think does? Canonical had no problems implementing KDE's spec as is. You are the ones who think it's poorly written. (Of course, the modified spec should still be compatible with the existing implementations and should still comply with the non-goal of enforcing visual uniformity! The changes GNOME demanded on the XDG list failed on both counts.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads-up: soname-bumped bind landed in Rawhide without announcement
A note for all: bind-9.9.0-0.7.rc2.fc17 , which was built for Rawhide today, bumps the soname of at least /usr/lib64/libdns-export (from 92 to 93), but this API compatibility change wasn't announced. Best check if any package you own that depends on bind is affected and needs a rebuild. It looks like the other affected lib is /usr/lib64/libdns (also went from libdns.so.92 to libdns.so.93). The libraries versioned *.so.90 do not appear to have had their soname bumped, they're .90 in both rc1 and rc2. atkac, in future, please announce API-incompatible bumps like this before you do them, as is required by the policy. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Thu, Feb 02, 2012 at 01:51:55AM +0100, Kevin Kofler wrote: > Matthew Garrett wrote: > > I'm on multiple spec bodies. If someone proposed an ammendment that > > allowed two conforming implementations to be entirely incompatible, and > > then argued that this was future proofing, they'd be laughed at. > > The constraints actually relevant for compatibility are all specified very > clearly! E.g., there are some D-Bus methods, there is a string which takes > an icon name etc. Your implementation can look entirely different (that's > the point!), but it will still be COMPATIBLE. It can be completely unusable. There's no way to design an application that will work with all valid implementations. > > The purpose of a spec is to *ensure* interoperability between different > > implementations. Any spec that relies on common sense is a bad spec. > > So you WOULD specify the value of pi in your spec?! ^^ No, because it's adequately specified elsewhere. A correct implementation of this spec isn't. > And the spec as is DOES ensure interoperability. It does not ensure visual > uniformity, by design. (Neither does the message-based notification spec > GNOME implements and recommends, by the way. The GNOME 3 message tray, the > Plasma notifier and the more traditional passive popup implementations used > elsewhere all implement the notification spec, yet look VERY different.) Yes, but it's not about visual uniformity. It's about ensuring that information is presented. > And finally, even if the spec really were as badly written as you claim, it > would still be very much possible to interoperate with the actual > implementations. Samba was written without any spec at all, and unlike Samba > you even have the source code of the applications and workspaces you'd > interoperate with. So the quality of the spec is a very poor argument for > not being interoperable. If the point is interoperability then just propose a version of the spec that actually guarantees useful interoperability. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Matthew Garrett wrote: > I'm on multiple spec bodies. If someone proposed an ammendment that > allowed two conforming implementations to be entirely incompatible, and > then argued that this was future proofing, they'd be laughed at. The constraints actually relevant for compatibility are all specified very clearly! E.g., there are some D-Bus methods, there is a string which takes an icon name etc. Your implementation can look entirely different (that's the point!), but it will still be COMPATIBLE. >> And why do we have to specify common sense? It was obvious to everyone >> involved that the bad implementation would be bad. Are you going to >> require a spec on drawing circles to specify that the circumference of >> the circle must be between 355/113-2^-21 and 355/113 times its diameter? >> ^^ > > The purpose of a spec is to *ensure* interoperability between different > implementations. Any spec that relies on common sense is a bad spec. So you WOULD specify the value of pi in your spec?! ^^ And the spec as is DOES ensure interoperability. It does not ensure visual uniformity, by design. (Neither does the message-based notification spec GNOME implements and recommends, by the way. The GNOME 3 message tray, the Plasma notifier and the more traditional passive popup implementations used elsewhere all implement the notification spec, yet look VERY different.) And finally, even if the spec really were as badly written as you claim, it would still be very much possible to interoperate with the actual implementations. Samba was written without any spec at all, and unlike Samba you even have the source code of the applications and workspaces you'd interoperate with. So the quality of the spec is a very poor argument for not being interoperable. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Florian Müllner wrote: > No, but it would require that "circle" is drawn as circle and not a > square (or just discarded without notice). The NotifyIcon spec > explicitly allows either absurdity. If your icon theme thinks a square is a good way to represent the concept of a "circle", that's an issue you need to take up with your icon theme author. ;-D The fact that if you ask for an icon named "circle", you should get a visualization which conveys the concept of a circle (whether it is really an *icon* or something else, as long as it clearly conveys the *concept*) is both obvious and outside of the scope of the spec. As for just discarding the icon without notice, that necessarily has to be allowed because the USER could have asked for that. The user could even have deleted the system tray widget entirely, or placed it somewhere hidden. (Outside of the GNOME world, software tends to actually listen to its users!) Now if the implementation ALWAYS just discards the icon and ignores both the application's and the user's requests, that would indeed suck as an implementation, but again, that's obvious! (Why would you implement the spec in the first place if you discard all the data you get? OF COURSE you're expected to provide the data to the user one way or the other unless the user explicitly asked you not to.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Bodhi critical path updates policy adjustment
FESCo recently made an adjustment to the updates policy to no longer require proventester karma for a critical path update to be deemed as stable. Critical path updates will now require just one regular +1 karma vote during the pre-beta phase and two regular +1 karma votes in other phases to be pushed to the stable updates repo. Anonymous karma is not taken into account. This policy change has been implemented and deployed to production with Bodhi v0.8.6. https://admin.fedoraproject.org/updates Please report any issues in bodhi's trac: http://bodhi.fedorahosted.org Thanks, luke pgpT8uFHtXnb9.pgp Description: PGP signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinux-related Rawhide breakage today
I'll note here a nice "Help wanted"... If you have access to RHEL6 (or I suppose any of the binary compatible variants) and some time: rel-eng is looking for some quick regression testing of the rpm change in https://bugzilla.redhat.com/show_bug.cgi?id=761000 to make sure it doesn't break in any obvious way for all the builds we use our builders for. See: https://fedorahosted.org/fesco/ticket/690#comment:33 for more info. Basically, just setup mock with no caching, install the rpm from http://people.redhat.com/harald/downloads/rpm/4.8.0-19.el6.0.usrmove.1/ and rebuild a bunch of core packages, then check them against the normal versions. There should be no substantial differences. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Florian Müllner wrote: > No, the argument for refusing to implement the protocol is that the spec > is bad. I was merely pointing out that *if* we used the protocol in the > top bar, it would have been as an implementation detail with no benefit > to applications (e.g. no way for applications to provide options to > override that behavior as you imply) Then your implementation in gnome-shell would just be half-assed and crappy, just like your implementation of the XEmbed-based spec is. Unlike the XEmbed-based spec, the status notifier spec actually allows apps to specify whether their icon is "active" or not, and a good implementation will show it in the panel if it is active and hide it behind a popup if it is not. (That's exactly what Plasma does.) You have both an area in the panel where the icon could be shown (themed to look the same as the icons which are already there, that's exactly why the spec allows the shell to theme the icons!) and a popup where it could be shelved in when inactive. Now the spec does allow you (by design) to decide you know better and always hide the icon behind the popup, it would just be lame, but apps would still be no worse off than now, where they automatically fall back to the old XEmbed- based spec, to which you give the same treatment. But in any case, that doesn't address the issue of GNOME application developers rejecting patches to support the spec in their applications, which was the issue that started this subthread. GNOME applications aren't only used on gnome-shell. > On mié, 2012-02-01 at 22:18 +0100, Kevin Kofler wrote: >> Including a bluetooth icon on a machine which does not even have >> bluetooth hardware? This is just beyond silly! > > *sigh* > You are trolling. How is that trolling? Some icons are just useless in some situations. (And even if you can autodetect whether a bluetooth controller is present, you still cannot know whether the user actually owns anything it can pair with, so that is not a solution either.) There's also the accessibility icon which will be totally useless for most users. Why does it take third-party extensions to get rid of those useless icons? It just doesn't make sense. > Except that applications can set a 'resident' hint on notifications, in > which case a representive icon is kept in the message tray, from which > the notification can be recalled; together with the ability to provide > actions on notifications, the experience is not different from status > icons. Except that this feature only works that way in GNOME and nowhere else. It also makes some strong assumptions on how the message tray looks, which is exactly what the status notifier spec tries hard to avoid. There is no place in the Plasma notifier where one would put an icon (in fact, the Plasma notifier IS an icon in the system tray, and the notifications pile up in the icon's popup). There is support for persistent notifications, but they are really persistent, i.e. they keep showing (as notifications) until you click them away. To my knowledge, no non-GNOME desktop implements the "resident" notifications you describe. And it's still a different concept from the status notifier icons, even if it might be possible to abuse it to work approximately the same way. If it were the same concept, why implement a different incompatible spec rather than the one at least 2 other desktop environments implement? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinux-related Rawhide breakage today
On 2012-02-01 15:16, Daniel J Walsh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/01/2012 12:49 PM, Kevin Kofler wrote: Daniel J Walsh wrote: Yes we have shipped a policy that requires the usrmove functionality. How many times do we have to tell you that you MUST build usrmove stuff in the f17-usrmove build target, NOT in f17(-candidate)??? This is already the third time somebody else cleans up your mess! (Rex Dieter fixed the first offending package, I fixed the second and now Adam Williamson fixed the third.) Please build your packages in the correct tag in the first place! (fedpkg build takes a --target flag for a reason!) Kevin Kofler The first two happened at the same time. The third happened because of confusion over which is which. Thanks for your consideration. But as long as we live in the Rawhide/Non Rawhide world things are going to be strange and mistakes are going to happen. Why anyone is on Rawhide and not trying out usrmove is beyond me at this time. Rawhide is supposed to be the latest and greatest code... If we are going to do usrmove, then lets do it and get over the hump. There are a couple of main reasons: 1) We really didn't want the /usr move to delay Alpha testing. This one is already proving to be genuine: it's looking like we won't really be ready to push the /usr move stuff into 'production' for a day or two at least, but we can still generate working TC1 images today, since we used a tag for /usr move. 2) It was at the time (and to an extent still is) unclear whether the feature will eventually be un-approved. Providing the builds in a tag allows us to try the change out and look for previously unidentified roadblocks. If we hit something which makes us think 'crap, maybe we shouldn't do this after all', we don't have to revert and bump a ton of packages and probably cause some new problems and make things a very bumpy ride for 'regular' Rawhide users: we can just never tag the packages across to the Rawhide repo, and the change will never have happened. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On 2012-02-01 14:49, Florian Müllner wrote: Except that applications can set a 'resident' hint on notifications, in which case a representive icon is kept in the message tray, from which the notification can be recalled; together with the ability to provide actions on notifications, the experience is not different from status icons. Not different...except that you can't see or interact with the icon in question unless you perform a distractive action (move your mouse to bottom-right corner or trigger the overview). Doesn't exactly fit in with the 'distraction-free computing' idea if you have to cycle through the overview every five minutes to check if a notification icon changed while you weren't paying attention. The whole GNOME 3 notification area is something of a bizarre netherland: there doesn't seem any logic to its existence. Unlike traditional notification areas it's not tethered to a panel, a concept users generally understand. It's just this kind of ethereal (non-)presence which sort of reserves the bottom right hand corner of your screen (and hence, really, the entire bottom portion of it, since if you try to interact with anything there you'll forever be triggering the notification area accidentally) but sort of doesn't, because it's not always visible. It's an odd bit of UI altogether. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Wed, 2012-02-01 at 17:00 -0700, Adam Williamson wrote: > On 2012-02-01 11:39, Florian Müllner wrote: > > > Because the "integrated experience" means that there is a fixed set > > of > > system items with a defined order. Extensions can be used to "hack" > > the > > intended experience (which includes adding "non-official" icons in > > the > > top bar), but it's nothing we want normal applications to do. > > Applications are encouraged to interact with the message tray (== the > > autohiding bottom panel) via freedesktop notifications (yay, > > cross-desktop! ;-) > > Yay cross-desktop maybe, but still a freaking disaster from a UI point > of view, and the only thing I really dislike about GNOME 3 (when I was > forced to drop to Xfce for a couple of days last week, the old-school > notifications were the only things I preferred). That sometimes-hidden, > erratically-triggered notification area *never* seems to do what I > actually want it to do. It shows up when I don't want it, it doesn't > show up when there's something on it I probably actually needed to see, > the icons on it fly around like space invaders and take two or hree > clicks to get rid of, transmission 'torrent completed' notifications > stack to the moon and back...it's just not nice. > > I realize this isn't a very constructive mail, and the point has been > raised before, but I'm hoping at some point the sheer weight of > complaints will cause someone more creative than myself to actually come > up with a notification system for GNOME 3 which satisfies the GNOME > design team and *also* does not suck. Amen! The notification area is my biggest grief with gnome-shell as well, sadly. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On 2012-02-01 11:39, Florian Müllner wrote: Because the "integrated experience" means that there is a fixed set of system items with a defined order. Extensions can be used to "hack" the intended experience (which includes adding "non-official" icons in the top bar), but it's nothing we want normal applications to do. Applications are encouraged to interact with the message tray (== the autohiding bottom panel) via freedesktop notifications (yay, cross-desktop! ;-) Yay cross-desktop maybe, but still a freaking disaster from a UI point of view, and the only thing I really dislike about GNOME 3 (when I was forced to drop to Xfce for a couple of days last week, the old-school notifications were the only things I preferred). That sometimes-hidden, erratically-triggered notification area *never* seems to do what I actually want it to do. It shows up when I don't want it, it doesn't show up when there's something on it I probably actually needed to see, the icons on it fly around like space invaders and take two or hree clicks to get rid of, transmission 'torrent completed' notifications stack to the moon and back...it's just not nice. I realize this isn't a very constructive mail, and the point has been raised before, but I'm hoping at some point the sheer weight of complaints will cause someone more creative than myself to actually come up with a notification system for GNOME 3 which satisfies the GNOME design team and *also* does not suck. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Wed, Feb 01, 2012 at 11:00:52PM +0100, Kevin Kofler wrote: > Matthew Garrett wrote: > > A spec that allows two conformant implementations to differ to such a > > degree that it's impossible for an application to work sensibly in both > > implementations is a *bad* *spec*. The only argument anyone had against > > that was "Oh, nobody would implement the spec in that way", which is > > another huge blaring warning that it's a bad spec. There was a simple > > and straightforward way of handling this, which was to rewrite the > > problematic parts of the specification in order to constrain > > implementations. But nobody bothered, and so it continues to be a bad > > spec. > > It's not a bad spec, it's a future-safe spec! I'm on multiple spec bodies. If someone proposed an ammendment that allowed two conforming implementations to be entirely incompatible, and then argued that this was future proofing, they'd be laughed at. > And why do we have to specify common sense? It was obvious to everyone > involved that the bad implementation would be bad. Are you going to require > a spec on drawing circles to specify that the circumference of the circle > must be between 355/113-2^-21 and 355/113 times its diameter? ^^ The purpose of a spec is to *ensure* interoperability between different implementations. Any spec that relies on common sense is a bad spec. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Random koji problems
On Wed, 2012-02-01 at 18:45 +0100, Kevin Kofler wrote: > Kevin Fenzi wrote: > > The only way is to revert the usrmove commit, then make your > > change/build. > > Actually, last I checked, it was possible to create a git branch off the > last commit before the stuff you don't want (i.e. the last commit before the > usrmove commit in this case) and then build from that branch. (It might need > some convincing for fedpkg, e.g. by giving some --dist flag, or you can just > use the koji command directly, which won't care about what branch the commit > ID you give it comes from and just use the build tag you give it.) That's a point - you could kind of retroactively set up the 'usrmove branch / master branch' setup I suggested before. That might be a decent way to handle it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
drago01 wrote: > On Wed, Feb 1, 2012 at 10:18 PM, Kevin Kofler > wrote: >> Florian Müllner wrote: >>> I don't think anyone made an argument for letting apps "decide how >>> exactly the icon will look" (which is basically what XEmbed does, and >>> everyone agrees that it's crap), but rather to avoid the other extreme >>> of giving the shell complete power of what to display (and even whether >>> to display anything at all). As is, applications can only hope that the >>> shell will use enough of the data it provides to convey the information >>> as intended, >> >> Thus the shell should do that. How hard can it be? > > If that is the intend of the spec then why not explicitly state it in > there? Instead of having some "unwritten rules" that app authors depend > on. To reuse your words "how hard can that be?" What is the point of specifying that "the shell [shall] use enough of the data [the application] provides to convey the information as intended"? It's obvious! (And it's all that CAN be specified, since the goal of the spec is explicitly NOT to specify HOW that data shall be displayed.) > Well because the app provides an interface to the user and it has to > somehow be able to know what the user actually sees. Why does the app need to worry whether the user will see an icon with the "locked" overlay located in the bottom-right corner, in the top-left corner, monochromatic and translucent over the entire icon, located next to the icon in a vertical list, or even something completely different from an overlay icon but still conveying the concept of being locked? It's the workspace shell's business, not the app's business. > Lets say your app opens a dialog and the window manager is free to > just not display it. Does that make any sense? Yet that's exactly what happens if you use the notification (message) spec GNOME wants apps to use instead of the status notifier spec. Your notification might get completely silenced. And FWIW, sometimes that's actually what the user WANTS. Plasma also allows the user to forcefully hide status notifier icons (they will show up in a popup you can open through an arrow next to the system tray instead of the system tray itself) even when the icon actually wants to be shown. (There are 3 options: automatic, i.e. do what the app wants, obviously the default; always shown; always hidden.) It's part of empowering the user (a concept GNOME is missing completely, sadly). >> So the argument that you're refusing to implement a cross-desktop >> protocol in order to ban random applications from adding themselves to >> the panel is bogus. > > Nobody said that. Florian Müllner did: | You are right about requiring a Javascript extension to add items to the | top panel, but you are wrong about the reasoning - it is not because the | "system tray looked out of place" (which it does, but it is nevertheless | still supported in the message tray), but rather because the top panel | is considered "system space", which means that we do not want random | applications to add anything to it. So even if we had adopted | NotifierIcons for the top bar (which was considered), it would still | have been reserved for a small set of processes (mostly | gnome-settings-daemon). Given that design restriction, it becomes very | much irrelevant whether the implementation uses cross-desktop technology | or not. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Fedora-Bugzilla] Clean up spec file and add perl default filter
commit bea7f42782c4cf86f9125e310d9f30822de4b25b
Author: Emmanuel Seyman
Date: Thu Feb 2 00:38:36 2012 +0100
Clean up spec file and add perl default filter
perl-Fedora-Bugzilla.spec | 16 +++-
1 files changed, 7 insertions(+), 9 deletions(-)
---
diff --git a/perl-Fedora-Bugzilla.spec b/perl-Fedora-Bugzilla.spec
index abbe2f2..12ae166 100644
--- a/perl-Fedora-Bugzilla.spec
+++ b/perl-Fedora-Bugzilla.spec
@@ -1,6 +1,6 @@
Name: perl-Fedora-Bugzilla
Version:0.13
-Release:10%{?dist}
+Release:11%{?dist}
Summary:Access Fedora's Bugzilla
Group: Development/Libraries
@@ -8,7 +8,6 @@ License:LGPLv2+
URL:http://camelus.fedorahosted.org
Source0:
http://search.cpan.org/CPAN/authors/id/R/RS/RSRCHBOY/Fedora-Bugzilla-%{version}.tar.gz
Patch0: perl-Fedora-Bugzilla-0.13-no-CascadeClear.patch
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
BuildArch: noarch
@@ -48,6 +47,8 @@ Requires: perl(Crypt::SSLeay)
Requires: perl(MooseX::MultiInitArg)
Requires: perl(RPC::XML::Client)
+%{?perl_default_filter}
+
%description
The XML-RPC interface to bugzilla is quite useful, and while Bugzilla 3.x
is starting to flesh their interface out a bit more (see, e.g.,
@@ -70,8 +71,6 @@ make %{?_smp_mflags}
%install
-rm -rf %{buildroot}
-
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null ';'
@@ -83,18 +82,17 @@ find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null
';'
make test
-%clean
-rm -rf %{buildroot}
-
-
%files
-%defattr(-,root,root,-)
%doc README Changes TODO COPYING
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
+* Thu Feb 2 2012 Emmanuel Seyman - 0.13-11
+- Clean up spec file
+- Add perl default filter
+
* Fri Jan 13 2012 Fedora Release Engineering
- 0.13-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: SELinux-related Rawhide breakage today
On Wed, Feb 1, 2012 at 14:16, Daniel J Walsh wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > But as long as we live in the Rawhide/Non Rawhide world things are > going to be strange and mistakes are going to happen. > > Why anyone is on Rawhide and not trying out usrmove is beyond me at > this time. Rawhide is supposed to be the latest and greatest code... > > If we are going to do usrmove, then lets do it and get over the hump. > > I am on rawhide and I usually update daily (though sometimes I am on koji and update hourly to be completely insane). There are times when there is a major change when I don't update as often because I expect the change will cause problems that I don't have time to fix/troubleshoot, or know I won't be able to submit a decent bug report. There is also the need to test the next day because the fix might cause another breakage to show up. Nothing like having a fresh batch of testers. Also, thankfully, the change has not been pushed to rawhide but is available for testing elsewhere. I'm very happy that this process has started to happen for the larger changes to coordinate all the pieces that need to be in place. When the change does get moved to rawhide I'll have the decision of remaining with what I have or being part of the test at whatever state it is in. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On mié, 2012-02-01 at 23:00 +0100, Kevin Kofler wrote: > Are you going to require a spec on drawing circles to specify that the > circumference of the circle must be between 355/113-2^-21 and 355/113 > times its diameter? No, but it would require that "circle" is drawn as circle and not a square (or just discarded without notice). The NotifyIcon spec explicitly allows either absurdity. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinux-related Rawhide breakage today
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/01/2012 12:49 PM, Kevin Kofler wrote: > Daniel J Walsh wrote: >> Yes we have shipped a policy that requires the usrmove >> functionality. > > How many times do we have to tell you that you MUST build usrmove > stuff in the f17-usrmove build target, NOT in f17(-candidate)??? > > This is already the third time somebody else cleans up your mess! > (Rex Dieter fixed the first offending package, I fixed the second > and now Adam Williamson fixed the third.) Please build your > packages in the correct tag in the first place! (fedpkg build takes > a --target flag for a reason!) > > Kevin Kofler > The first two happened at the same time. The third happened because of confusion over which is which. Thanks for your consideration. But as long as we live in the Rawhide/Non Rawhide world things are going to be strange and mistakes are going to happen. Why anyone is on Rawhide and not trying out usrmove is beyond me at this time. Rawhide is supposed to be the latest and greatest code... If we are going to do usrmove, then lets do it and get over the hump. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8pudUACgkQrlYvE4MpobMldACgtgKifrd/mWx4P93iDRAHsUfj bW0AnRyECjTzWxOuIZQq+p2sZWHW401D =Hg4k -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Matthew Garrett wrote: > A spec that allows two conformant implementations to differ to such a > degree that it's impossible for an application to work sensibly in both > implementations is a *bad* *spec*. The only argument anyone had against > that was "Oh, nobody would implement the spec in that way", which is > another huge blaring warning that it's a bad spec. There was a simple > and straightforward way of handling this, which was to rewrite the > problematic parts of the specification in order to constrain > implementations. But nobody bothered, and so it continues to be a bad > spec. It's not a bad spec, it's a future-safe spec! It does not make sense to specify things which do not NEED to be specified. It needlessly constrains future implementations which may be (and possibly NEED to be) totally different. The spec cannot mandate that some action makes the icon blink because that assumes that there's an icon in the first place and that the hardware allows making it blink. What about non-visual representations, e.g. for users who cannot see those small icons for whatever reason, and/or on hardware which doesn't even have a display in the first place? (That example was brought up by the KDE developers in the XDG thread.) It's not the spec's business to make your shell not suck, it's the shell developers' business! And why do we have to specify common sense? It was obvious to everyone involved that the bad implementation would be bad. Are you going to require a spec on drawing circles to specify that the circumference of the circle must be between 355/113-2^-21 and 355/113 times its diameter? ^^ Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [389-devel] PAM plugin vs post op processing. New return code proposal...
On 02/01/2012 02:48 PM, Mark Reynolds wrote:
On 02/01/2012 04:28 PM, Rich Megginson wrote:
On 02/01/2012 02:16 PM, Mark Reynolds wrote:
Hi Everyone,
There is an issue with the PAM plugin, that when it performs a
successful bind we actually return error 1 to plugins_call_func(),
which essentially causes the abort of the all plugin processing:
the rest of pre-op, the backend call, and all of post-op. PAM has
completed the bind and already returned the result, so it returns 1
to stop the DS from doing the rest of bind op. Makes sense...
Where is the code that calls the preop?
However, with the Account Policy plugin, when tracking the "last
bind time", binding thru PAM won't update the entry, even though the
bind was successful. This is because the successful PAM bind
essentially aborted all the pre-op and post-op plugins. I feel that
we should still call the post op plugins in this scenario. The
pre-op plugins should still be aborted, because the operation was
already completed - there's nothing to reject at that point.
So to get around plugins like this, I am proposing a new plugin
pre-op return code(either use 1, or -2). This return code implies
that the operation was fully completed, and that we should also
process the post op plugins - but do not send the operation to the
backend.
So to the recap, the new return code says the operation was fully
completed by the plugin, but we still want to process just the
post-op plugins.
I know this will impact documentation, there might be unforeseen
issues, and this is also a rare situation(only PAM plugin seems to
behave like this). Saying that, I still think its the valid
solution to this type of problem. It could also allow future
plugins for be more versatile/robust.
Please let me know your thoughts.
I don't think we need a new return code - I just think we need to
diff --git a/ldap/servers/slapd/bind.c b/ldap/servers/slapd/bind.c
index 1d860b6..bd7df3d 100644
--- a/ldap/servers/slapd/bind.c
+++ b/ldap/servers/slapd/bind.c
@@ -796,6 +796,10 @@ do_bind( Slapi_PBlock *pb )
slapi_pblock_set( pb, SLAPI_PLUGIN_OPRETURN, &rc );
plugin_call_plugins( pb, SLAPI_PLUGIN_POST_BIND_FN );
+} else {
+/* even if the pre-op plugins returned an error, we
still need
+ to call the post-op plugins */
+plugin_call_plugins( pb, SLAPI_PLUGIN_POST_BIND_FN );
}
} else {
send_ldap_result( pb, LDAP_UNWILLING_TO_PERFORM, NULL,
I thought about this, but I thought we needed a new code because isn't
it by design: if pre-op fails, it should all fail?
I don't think so. In every other case in bind.c, when something fails,
the POST_BIND functions are called. I don't see why this particular
case should be any different. IMHO a POST_BIND plugin will always want
to know if the bind succeeded or failed for any reason. Note that IPA
has a POST_BIND plugin - ipa_lockout - which will want to be called in
this case.
PAM really isn't failing, it just doesn't have a better mechanism to
handle its behaviour.
The above code would work fine, so maybe this could be a discussion
for a later time. I was just looking for a more "global" solution.
So, I will use this approach for now so I can get the bug resolved.
If there's time in the future maybe we can come back to this. Like I
said it's not something that is needed, but it would allow for more
creative plugins :-)
Thanks,
Mark
Looking at bind.c - there is a lot of special case code that makes
sure to call the POST_BIND plugins in various error cases. This
seems like just another error case that we should handle by calling
the POST_BIND plugins.
Thanks,
Mark
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
[ACTION REQUIRED v4] Retiring packages for F-17
(comaintainers bcc'd) Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 17. New this go-round is that we are also blocking packages that have failed to build since before Fedora 15. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. Due to the orphaning of packages due to inactive maintainers, this list is a little longer than normal. If these packages are not claimed, they will be retired shortly before the mass branch for Fedora 17 on February 7th. Orphan adaptx Orphan ario Orphan asa comaintained by: pertusus Orphan autodafe Orphan avant-window-navigator comaintained by: ngompa Orphan avl Orphan awn-extras-applets Orphan bit Orphan blam comaintained by: alexlan Orphan blt Orphan bwidget Orphan camstream Orphan ccsm Orphan compiz Orphan compiz-bcop Orphan compiz-fusion-extras Orphan compiz-fusion-unsupported Orphan compiz-manager Orphan compizconfig-backend-gconf Orphan compizconfig-backend-kconfig4 Orphan compizconfig-python Orphan conexus Orphan dbus-cxx Orphan eazykeyboard Orphan eclipse-setools Orphan eclipse-slide Orphan erlang-erlzmq2 Orphan expatmm Orphan freehdl comaintained by: chitlesh Orphan gestikk Orphan gget Orphan gimpfx-foundry Orphan gkrellm-volume Orphan gmime22 Orphan gnome-paint Orphan gnubversion Orphan gpx-viewer Orphan higlayout Orphan intellij-idea Orphan intuitively comaintained by: pertusus Orphan invulgotracker Orphan itaka Orphan itcl Orphan itk Orphan itools Orphan iwak Orphan iwidgets Orphan jps Orphan kcirbshooter Orphan libcompizconfig Orphan libdesktop-agnostic Orphan libmetalink Orphan libnoise Orphan libspe2 Orphan libsx comaintained by: pertusus Orphan lifeograph comaintained by: sundaram Orphan log4c Orphan lush Orphan maradns Orphan mathmap Orphan maxr comaintained by: cassmodiah Orphan mediawiki-rss comaintained by: ianweller Orphan memchan Orphan metalink Orphan mingw32-OpenSceneGraph Orphan mingw32-plib Orphan mod_perlite Orphan monsoon Orphan mtkbabel Orphan mulk Orphan nanoxml Orphan netbeans Orphan netstiff Orphan openbios Orphan papyrus Orphan pfscalibration Orphan pfstmo Orphan pfstools Orphan phpTodo Orphan picocontainer Orphan pinot Orphan podcatcher Orphan puritan Orphan pyactivemq Orphan pyevent comaintained by: lmacken Orphan pymssql Orphan pypar2 Orphan python-ZSI comaintained by: jbowes Orphan python-assets Orphan python-elixir comaintained by: lmacken smilner Orphan python-text_table Orphan python-wehjit Orphan quadkonsole Orphan quotatool Orphan rainbow comaintained by: mstone Orphan rudecgi Orphan rudeconfig Orphan saxon comaintained by: dbhole Orphan snacc comaintained by: chitlesh Orphan specspo Orphan spr Orphan spu-binutils Orphan stgit comaintained by: jcwillia Orphan systemtapguiserver Orphan tbcload Orphan tcl-tclxml Orphan tcl-thread Orphan tclchecker Orphan tclcompiler Orphan tcldebugger Orphan tclhttpd Orphan tcllib Orphan tclparser Orphan tclpro Orphan tclsoap Orphan tdom Orphan tkcon Orphan tklib Orphan tktable comaintained by: sergiopr Orphan tomcat5 comaintained by: devrim dwalluck Orphan transbot Orphan ugene Orphan verilator comaintained by: chitlesh Orphan vim-perl-tt2 Orphan wordtrans Orphan xcftools Orphan xmldb-api comaintained by: dbhole Orphan xmlrpc-epi Orphan xmlunit List of deps left behind by packages which are orphaned or fail to build: Removing: blt magic requires blt = 2.4-34.z.fc17 ngspice requires blt-devel = 2.4-34.z.fc17 scitools-extras requires blt = 2.4-34.z.fc17 Removing: bwidget amsn requires bwidget = 1.9.0-3.fc17 mcu8051ide requires bwidget = 1.9.0-3.fc17 setools-gui requires bwidget = 1.9.0-3.fc17 tkabber requires bwidget = 1.9.0-3.fc17 Removing: ccsm fusion-icon requires ccsm = 0.9.5.92-2.fc17 Removing: compiz compiz-fusion requires compiz-devel = 0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17 compiz-fusion requires compiz = 0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17 compiz-fusion-devel requires pkgconfig(compiz) = 0.9.5.92.1 compiz-fusion-devel requires compiz-devel = 0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17 compiz-plugins-main requires libopengl.so compiz-plugins-main requires compiz-devel = 0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17 compiz-plugins-main requires compiz = 0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17 compiz-plugins-main requires libcomposite.so compiz-plugins-main requires libcompiztoolbox.so compiz-plugins-main-devel requires pkgconfig(compiz-opengl) = 0.9.5.92.1 compiz-plugins-main-devel requires pkgconfig(compiz) = 0.9.5.92.1 compiz-plugins-main-devel requires compiz-devel = 0.9.5.92.1-0.1.gite676f1b12eb8db3
Re: Unity For Fedora (As in OpenSUSE or Arch)
On mié, 2012-02-01 at 22:18 +0100, Kevin Kofler wrote: > So the argument that you're refusing to implement a cross-desktop protocol > in order to ban random applications from adding themselves to the panel is > bogus. No, the argument for refusing to implement the protocol is that the spec is bad. I was merely pointing out that *if* we used the protocol in the top bar, it would have been as an implementation detail with no benefit to applications (e.g. no way for applications to provide options to override that behavior as you imply) > > Because the "integrated experience" means that there is a fixed set of > > system items with a defined order. > > Including a bluetooth icon on a machine which does not even have bluetooth > hardware? This is just beyond silly! *sigh* You are trolling. > Notification messages and status notifier icons are totally independent > concepts with totally different use cases and totally different practical > uses. They are separate protocols for a reason. > > Notifications (also called "passive popups") are for one-off messages you > want to show to the user to inform them of something transient. Status > notifiers are for status icons the user wants to permanently keep an eye on, > such as network connectivity (which in fact you do realize needs a status > icon, or you wouldn't have hardcoded it in your shell). Except that applications can set a 'resident' hint on notifications, in which case a representive icon is kept in the message tray, from which the notification can be recalled; together with the ability to provide actions on notifications, the experience is not different from status icons. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [389-devel] PAM plugin vs post op processing. New return code proposal...
On 02/01/2012 04:28 PM, Rich Megginson wrote:
On 02/01/2012 02:16 PM, Mark Reynolds wrote:
Hi Everyone,
There is an issue with the PAM plugin, that when it performs a
successful bind we actually return error 1 to plugins_call_func(),
which essentially causes the abort of the all plugin processing: the
rest of pre-op, the backend call, and all of post-op. PAM has
completed the bind and already returned the result, so it returns 1
to stop the DS from doing the rest of bind op. Makes sense...
Where is the code that calls the preop?
However, with the Account Policy plugin, when tracking the "last bind
time", binding thru PAM won't update the entry, even though the bind
was successful. This is because the successful PAM bind essentially
aborted all the pre-op and post-op plugins. I feel that we should
still call the post op plugins in this scenario. The pre-op plugins
should still be aborted, because the operation was already completed
- there's nothing to reject at that point.
So to get around plugins like this, I am proposing a new plugin
pre-op return code(either use 1, or -2). This return code implies
that the operation was fully completed, and that we should also
process the post op plugins - but do not send the operation to the
backend.
So to the recap, the new return code says the operation was fully
completed by the plugin, but we still want to process just the
post-op plugins.
I know this will impact documentation, there might be unforeseen
issues, and this is also a rare situation(only PAM plugin seems to
behave like this). Saying that, I still think its the valid solution
to this type of problem. It could also allow future plugins for be
more versatile/robust.
Please let me know your thoughts.
I don't think we need a new return code - I just think we need to
diff --git a/ldap/servers/slapd/bind.c b/ldap/servers/slapd/bind.c
index 1d860b6..bd7df3d 100644
--- a/ldap/servers/slapd/bind.c
+++ b/ldap/servers/slapd/bind.c
@@ -796,6 +796,10 @@ do_bind( Slapi_PBlock *pb )
slapi_pblock_set( pb, SLAPI_PLUGIN_OPRETURN, &rc );
plugin_call_plugins( pb, SLAPI_PLUGIN_POST_BIND_FN );
+} else {
+/* even if the pre-op plugins returned an error, we still
need
+ to call the post-op plugins */
+plugin_call_plugins( pb, SLAPI_PLUGIN_POST_BIND_FN );
}
} else {
send_ldap_result( pb, LDAP_UNWILLING_TO_PERFORM, NULL,
I thought about this, but I thought we needed a new code because isn't
it by design: if pre-op fails, it should all fail? PAM really isn't
failing, it just doesn't have a better mechanism to handle its behaviour.
The above code would work fine, so maybe this could be a discussion for
a later time. I was just looking for a more "global" solution. So, I
will use this approach for now so I can get the bug resolved. If
there's time in the future maybe we can come back to this. Like I said
it's not something that is needed, but it would allow for more creative
plugins :-)
Thanks,
Mark
Looking at bind.c - there is a lot of special case code that makes
sure to call the POST_BIND plugins in various error cases. This seems
like just another error case that we should handle by calling the
POST_BIND plugins.
Thanks,
Mark
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Wed, Feb 1, 2012 at 10:18 PM, Kevin Kofler wrote: > Florian Müllner wrote: >> I don't think anyone made an argument for letting apps "decide how >> exactly the icon will look" (which is basically what XEmbed does, and >> everyone agrees that it's crap), but rather to avoid the other extreme >> of giving the shell complete power of what to display (and even whether >> to display anything at all). As is, applications can only hope that the >> shell will use enough of the data it provides to convey the information >> as intended, > > Thus the shell should do that. How hard can it be? If that is the intend of the spec then why not explicitly state it in there? Instead of having some "unwritten rules" that app authors depend on. To reuse your words "how hard can that be?" >> but there are no guarantees or ways to query the shell's capabilities. > > Because the application should not have to worry about it. Well because the app provides an interface to the user and it has to somehow be able to know what the user actually sees. Lets say your app opens a dialog and the window manager is free to just not display it. Does that make any sense? > So the argument that you're refusing to implement a cross-desktop protocol > in order to ban random applications from adding themselves to the panel is > bogus. Nobody said that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Florian Müllner wrote: > I don't think anyone made an argument for letting apps "decide how > exactly the icon will look" (which is basically what XEmbed does, and > everyone agrees that it's crap), but rather to avoid the other extreme > of giving the shell complete power of what to display (and even whether > to display anything at all). As is, applications can only hope that the > shell will use enough of the data it provides to convey the information > as intended, Thus the shell should do that. How hard can it be? > but there are no guarantees or ways to query the shell's capabilities. Because the application should not have to worry about it. > But I don't want to reopen that xdg discussion; I just wanted to clarify > that GNOME did not ignore the spec, but refused to adopt it because it > was deemed insufficient. We'll have to agree to disagree on whether the > reasons brought forward justify the non-adoption. I have no problem with > your opinion that the NotifierIcon spec is a good spec, but I do take > issue on blaming GNOME for not adopting a spec we consider "bad" Implementing the spec is needed for your application to work properly on everyone else's desktops, and everyone else's applications to work properly on your desktop. > - after all, "enforcing" adoption of technology is not what > freedesktop.org is supposed to be about[0] ;-) > > [0] http://aseigo.blogspot.com/2005/04/stupidity-of-dconf.html Bad example. Configuration file storage is not a communication protocol. The status notifier protocol is a protocol for communication between the applications and the workspace, and thus a communication protocol to the same extent as HTTP, FTP, SMB etc. > You are right about requiring a Javascript extension to add items to the > top panel, but you are wrong about the reasoning - it is not because the > "system tray looked out of place" (which it does, but it is nevertheless > still supported in the message tray), but rather because the top panel > is considered "system space", which means that we do not *want* random > applications to add anything to it. So even if we had adopted > NotifierIcons for the top bar (which was considered), it would still > have been reserved for a small set of processes (mostly > gnome-settings-daemon). Given that design restriction, it becomes very > much irrelevant whether the implementation uses cross-desktop technology > or not. Newsflash: KDE *also* deprecated the use of the system tray by random applications by default! However: * Some users WANT to have the OPTION of having an icon for a specific application there. I know GNOME hates options, but not everyone agrees with that. So several applications do have a preference to show a system tray icon even if it is disabled by default, and change requests such as https://bugzilla.redhat.com/show_bug.cgi?id=761640 are just rude. (And yes, I know XChat is still using the crappy legacy XEmbed protocol. And by the way, I no longer comaintain or use XChat, so for all I personally care you can cripple it all you want, but that doesn't make it any less stupid to do so.) * Not any cross-desktop program is a regular application. There can also be cross-desktop system utilities. Think, e.g., of hardware enablement: gnome- shell currently has a hardcoded Bluetooth icon (and in fact requires an extension to get rid of it), what if there's a completely new hardware technology coming up which warrants an icon just as much? Why does everything have to be rewritten and hardcoded into gnome-shell (as was done for network management, bluetooth etc.)? Another example is imsettings, which not only had to be rewritten as a gnome-shell extension, but was not even allowed onto the default Fedora desktop (the misnamed GNOME "Desktop" live image) because the extension was not yet merged into upstream gnome- shell! So the argument that you're refusing to implement a cross-desktop protocol in order to ban random applications from adding themselves to the panel is bogus. > Because the "integrated experience" means that there is a fixed set of > system items with a defined order. Including a bluetooth icon on a machine which does not even have bluetooth hardware? This is just beyond silly! I'm really fed up of GNOME's "one size fits it all" mentality. > Extensions can be used to "hack" the intended experience (which includes > adding "non-official" icons in the top bar), but it's nothing we want > normal applications to do. Applications are encouraged to interact with > the message tray (== the autohiding bottom panel) via freedesktop > notifications (yay, cross-desktop! ;-) Notification messages and status notifier icons are totally independent concepts with totally different use cases and totally different practical uses. They are separate protocols for a reason. Notifications (also called "passive popups") are for one-off messages you want to show to the user to inform them of something transient
Re: Rolling release Fedora - fantastic idea
* Przemek Klosowski [01/02/2012 19:58] : > > I am just trying to explore if there's a way around that. The answer is the same on this subject and the rolling release: You need to get a group together, put together a set of specifications that everybody agrees on and start working on making it happen. If nobody is willing to do this, nothing is going to happen. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Retirement of cernlib, cernlib-g77
Neither package has built since F15, and while there's a new patchset to apply, I don't quite have time to get it to work. Unless someone wants to get them to build, or take ownership, I'll retire them Friday, 2/3. Thanks, -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Wed, Feb 01, 2012 at 06:25:05PM +0100, Kevin Kofler wrote: > The objections weren't addressed because they objected to the very point of > the spec, making it impossible to address them without defeating the purpose > of the spec. A spec that allows two conformant implementations to differ to such a degree that it's impossible for an application to work sensibly in both implementations is a *bad* *spec*. The only argument anyone had against that was "Oh, nobody would implement the spec in that way", which is another huge blaring warning that it's a bad spec. There was a simple and straightforward way of handling this, which was to rewrite the problematic parts of the specification in order to constrain implementations. But nobody bothered, and so it continues to be a bad spec. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: Ticket #87 - Manpages fixes
https://fedorahosted.org/389/ticket/87 https://fedorahosted.org/389/attachment/ticket/87/0001-Ticket-87-Manpages-fixes.patch -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please review: fix a couple of minor coverity issues
On 02/01/2012 01:56 PM, Rich Megginson wrote: -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel ack -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Outage: buildsystem and pkgs - 2012-02-02 03:00 UTC
Outage: buildsystem and pkgs - 2012-02-02 03:00 UTC There will be an outage starting at 2012-02-02 03:00 UTC, which will last approximately 1 hour. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2012-02-02 03:00 UTC' Reason for outage: We will be upgrading the firmware in our backend storage devices for the buildsystem and lookaside cache. Additionally we will be upgrading the koji hub instances. During this outage, new package uploads and builds will be disabled. Affected Services: Buildsystem - http://koji.fedoraproject.org/ GIT / Source Control Unaffected Services: Ask Fedora - http://ask.fedoraproject.org/ BFO - http://boot.fedoraproject.org/ Bodhi - https://admin.fedoraproject.org/updates/ DNS - ns1.fedoraproject.org, ns2.fedoraproject.org Docs - http://docs.fedoraproject.org/ Email system Fedora Account System - https://admin.fedoraproject.org/accounts/ Fedora Community - https://admin.fedoraproject.org/community/ Fedora Hosted - https://fedorahosted.org/ Fedora Insight - https://insight.fedoraproject.org/ Fedora People - http://fedorapeople.org/ Main Website - http://fedoraproject.org/ Mirror List - https://mirrors.fedoraproject.org/ Mirror Manager - https://admin.fedoraproject.org/mirrormanager/ Package Database - https://admin.fedoraproject.org/pkgdb/ QA Services Secondary Architectures Smolt - http://smolts.org/ Spins - http://spins.fedoraproject.org/ Start - http://start.fedoraproject.org/ Torrent - http://torrent.fedoraproject.org/ Wiki - http://fedoraproject.org/wiki/ Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/3121 Contact Information: Please join #fedora-admin in irc.freenode.net or add comments to the ticket for this outage above. signature.asc Description: PGP signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: fix a couple of minor coverity issues
0001-fix-a-couple-of-minor-coverity-issues.patch Description: application/mbox -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
File Net-STOMP-Client-1.4.tar.gz uploaded to lookaside cache by stevetraylen
A file has been added to the lookaside cache for perl-Net-STOMP-Client: 5b9a13ba8383ac33bcf3e16eeea6a44d Net-STOMP-Client-1.4.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Rolling release Fedora - fantastic idea
2012/2/1 Bruno Wolff III : > A lot of people need to step up and do the work. So far no one has been > able to successfully organize a group to do it. And given Fedora is more > likely > to attract people who want to run the latest and (hopefully) greatest stuff, > I would expect finding a lot of people who want to support old Fedora releases > is going to be difficult. > -- +1 Too bad I do not have the experience necessary to take the first step, but when this group is created, I'll be happy to help in anyway I can. -- Henrique "LonelySpooky" Junior -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On mié, 2012-02-01 at 18:25 +0100, Kevin Kofler wrote: > The objections weren't addressed because they objected to the very point of > the spec, making it impossible to address them without defeating the purpose > of the spec. > > One main design goal of the spec was that it should NOT be the app's job to > decide how exactly the icon will look, but the shell's. I don't think anyone made an argument for letting apps "decide how exactly the icon will look" (which is basically what XEmbed does, and everyone agrees that it's crap), but rather to avoid the other extreme of giving the shell complete power of what to display (and even whether to display anything at all). As is, applications can only hope that the shell will use enough of the data it provides to convey the information as intended, but there are no guarantees or ways to query the shell's capabilities. But I don't want to reopen that xdg discussion; I just wanted to clarify that GNOME did not ignore the spec, but refused to adopt it because it was deemed insufficient. We'll have to agree to disagree on whether the reasons brought forward justify the non-adoption. I have no problem with your opinion that the NotifierIcon spec is a good spec, but I do take issue on blaming GNOME for not adopting a spec we consider "bad" - after all, "enforcing" adoption of technology is not what freedesktop.org is supposed to be about[0] ;-) > And it makes sense: > Look at how gnome-shell deprecated the system tray entirely because it > looked totally out of place there, and is forcing everyone who wants an icon > in the panel to implement a GNOME-specific shell extension in JavaScript. You are right about requiring a Javascript extension to add items to the top panel, but you are wrong about the reasoning - it is not because the "system tray looked out of place" (which it does, but it is nevertheless still supported in the message tray), but rather because the top panel is considered "system space", which means that we do not *want* random applications to add anything to it. So even if we had adopted NotifierIcons for the top bar (which was considered), it would still have been reserved for a small set of processes (mostly gnome-settings-daemon). Given that design restriction, it becomes very much irrelevant whether the implementation uses cross-desktop technology or not. > Cross-desktop status notifiers and native Plasma widgets > (plasmoids) can sit right next to each other in the Plasma system tray and > look and feel the same, why can't gnome-shell offer the same integrated > experience rather than deprecating everything other than gnome-shell-only > extensions? Because the "integrated experience" means that there is a fixed set of system items with a defined order. Extensions can be used to "hack" the intended experience (which includes adding "non-official" icons in the top bar), but it's nothing we want normal applications to do. Applications are encouraged to interact with the message tray (== the autohiding bottom panel) via freedesktop notifications (yay, cross-desktop! ;-) Florian [0] http://aseigo.blogspot.com/2005/04/stupidity-of-dconf.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release Fedora - fantastic idea
On Wed, Feb 01, 2012 at 13:20:58 -0500, Przemek Klosowski wrote: > > Precisely---but lack of the EOL path sometimes prevents use of > Fedora in the first place. Jon Vos said elsewhere in this discussion > that "Fedora is not for long term if updates/security are an issue. > Period." > > I am just trying to explore if there's a way around that. A lot of people need to step up and do the work. So far no one has been able to successfully organize a group to do it. And given Fedora is more likely to attract people who want to run the latest and (hopefully) greatest stuff, I would expect finding a lot of people who want to support old Fedora releases is going to be difficult. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release Fedora - fantastic idea
On 01/31/2012 04:27 PM, Emmanuel Seyman wrote: * Przemek Klosowski [31/01/2012 00:37] : To solve that, I'd be nice if there was a way to roll over an EOL version into an appropriate release of one of the long-term-supported systems such as RHEL, Centos or Scientific Linux. This would be a massive distraction from our mission. Get the $FOO people to cover migrations from other distributions to $FOO. The Fedora people should only be concerned with migrations to Fedora, not from it. Precisely---but lack of the EOL path sometimes prevents use of Fedora in the first place. Jon Vos said elsewhere in this discussion that "Fedora is not for long term if updates/security are an issue. Period." I am just trying to explore if there's a way around that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Sat, 2012-01-28 at 00:03 +0100, Kevin Kofler wrote: > That's really GNOME's fault. :-( Canonical explicitly designed > libappindicator (which is the library applications are expected to use, it > uses libindicator behind the scenes; there's also libindicate which is for > communication apps to notify new messages and such, confusing, isn't it?) to > be interoperable with KDE's status notifier spec, and thus applications > supporting libappindicator will also integrate better into the KDE Plasma > workspaces than applications still stuck on the legacy XEmbed-based system > tray protocol and/or using a GNOME-only gnome-shell extension. But GNOME is > giving the finger to cross-desktop protocols and refusing to implement them. > > It's too bad that our maintainers for the affected packages are often one > and the same as the GNOME maintainers and thus Fedora is mostly siding with > GNOME on this and refusing to carry those patches, hurting all non-GNOME > desktops, not just Unity. Kevin, I am not going to comment on the incendiary language here (I know you are pretty tone-deaf in email). But to blame us for not embracing a spec after our comments on it were completely ignored seems a little unfair, to say the least. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] please review ticket 55 - Limit of 1024 chars in nsMatchingRule
https://fedorahosted.org/389/attachment/ticket/55 https://fedorahosted.org/389/attachment/ticket/55/0001-Ticket-55-Limit-of-1024-characters-for-nsMatchingRul.patch -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Matthias Clasen wrote: > After the fruitless discussion on xdg-list, we decided that the spec was > not going to help us in implementing the desired user experience. That's not up to you to decide. The spec is a cross-desktop spec already implemented by KDE Plasma and Unity. Sometimes you have to interoperate even with a protocol you don't like! Do you think SMB/CIFS is a great protocol? Yet we have Samba, and for a good reason! Interoperability doesn't always mean YOUR spec will be the one getting adopted by everyone. (That's exactly the frustrating thing about GNOME's current approach to interoperability: They always want to force THEIR standards onto everyone. And that's when they even remember other desktop environments exist in the first place.) I have also explained in my reply to Florian why the "discussion" on the XDG list was fruitless and why that spec would actually HELP implement the desired user experience in gnome-shell, if you were open to cross-desktop protocols instead of forcing the "native GJS extensions only" dogma. And independently of what gnome-shell supports, your applications will also run on plenty of non-GNOME workspaces (KDE Plasma, Unity, Xfce, LXDE, proprietary operating systems; and yes, users WILL run them on all those platforms), so supporting only what gnome-shell supports does a disservice to your users. At least Plasma and Unity users would benefit from you adopting libappindicator in your applications; for the other platforms, it will either also help or just not make a difference. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinux-related Rawhide breakage today
Daniel J Walsh wrote: > Yes we have shipped a policy that requires the usrmove functionality. How many times do we have to tell you that you MUST build usrmove stuff in the f17-usrmove build target, NOT in f17(-candidate)??? This is already the third time somebody else cleans up your mess! (Rex Dieter fixed the first offending package, I fixed the second and now Adam Williamson fixed the third.) Please build your packages in the correct tag in the first place! (fedpkg build takes a --target flag for a reason!) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Wed, 2012-02-01 at 18:03 +0100, Kevin Kofler wrote: > Bastien Nocera wrote: > > GNOME never gave an opinion on the spec, we gave an opinion on the > > library, which was really just a huge pile of bugs (I know, they patched > > a bunch of the applications I maintain, and I get to receive a large > > number of crashers because of it). > > But I don't see any movement from the GNOME side on developing a less buggy > library implementing the spec nor on fixing the bugs in libappindicator, so > GNOME is ignoring the spec. After the fruitless discussion on xdg-list, we decided that the spec was not going to help us in implementing the desired user experience. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Random koji problems
Kevin Fenzi wrote: > The only way is to revert the usrmove commit, then make your > change/build. Actually, last I checked, it was possible to create a git branch off the last commit before the stuff you don't want (i.e. the last commit before the usrmove commit in this case) and then build from that branch. (It might need some convincing for fedpkg, e.g. by giving some --dist flag, or you can just use the koji command directly, which won't care about what branch the commit ID you give it comes from and just use the build tag you give it.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On 02/01/2012 06:38 PM, Bill Nottingham wrote: Panu Matilainen (pmati...@laiskiainen.org) said: To-be-installed files obviously have no on-disk fingerprints, so it wont work for initial installation. So yes, those "fake" compatibility provides are needed. Strictly speaking, compatibility provides would be needed for ALL the moved files, not just /bin, as it's technically perfectly legal for a package to depend on an arbitrary path in /lib[64], not just /[s]bin. - Panu - Would it be possible to leave out these provides and fix each individual package to require in the new path instead? It isn't practical to "fix" every package that requires /bin/sh. It's not "just" that the impracticality either - not providing /bin/sh, /sbin/ldconfig and the like would mean a huge incompatibility break with nearly every existing package in the wild. Not really an option. I'm not convinced of the "all" case, though. /bin/sh, /sbin/ldconfig, etc. could be reasonable for a package to require, and should be provided. Requires: /lib/modules/3.1.2-1.fc16/kernel/drivers/net/3c59x.ko is likely too dumb to live, though. Oh, sure. Hence the "strictly speaking". I'm not arguing for adding provides for eg /lib/modules (although I think I've seen such dependencies in the wonderful world of kernel module packaging ;), just pointing out that it's not 100% transparent change for package(r)s. Made ever more fun by the rpm behavior on installed files where you test a package on your machine, see it installs fine and then scratch head when it fails to work as part of initial install. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rolling release Fedora - fantastic idea
Przemek Klosowski wrote: > The downgrades would actually be better than having an unsupported > system that doesn't get any updates ever. The assumption here is that > the downgrades aren't introducing any security or fundamental > functionality issues--hopefully, 'long term support' means that they > would fix such problems. Well, then you can try migrating with yum distro-sync and it will do the required downgrades, but such an option will never be officially supported by anybody because package downgrades aren't officially supported in the first place. (Fedora doesn't support it, some upstreams also don't support it, and e.g. config files from the new version might no longer work with the old one.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Florian Müllner wrote: > I can not comment on the quality of the library, but GNOME did comment > on the spec[0] (or rather: several gnomers did) - there were a couple of > objections, none of which have been addressed in the spec as far as I > can tell. The objections weren't addressed because they objected to the very point of the spec, making it impossible to address them without defeating the purpose of the spec. One main design goal of the spec was that it should NOT be the app's job to decide how exactly the icon will look, but the shell's. And it makes sense: Look at how gnome-shell deprecated the system tray entirely because it looked totally out of place there, and is forcing everyone who wants an icon in the panel to implement a GNOME-specific shell extension in JavaScript. Yet Plasma can deliver the same integrated look (supplying its own monochrome icons and displaying its own Plasma-themed menus) for system tray icons using the new status notifier spec (and the D-Bus menu spec for the menus, though the status notifier spec predates the D-Bus menu spec and thus also allows for displaying the menu in process). How would you be able to adjust the presentation to the shell's design if the app tells you that it wants some overlay placed at offset (5,7) of the icon as Dan Winship requested?! Such a request just makes no sense whatsoever because the app doesn't (and shouldn't!) even know how the icon and the overlay look like! Offset (5,7) may work great with the desktop shell and theme you tested with, but cover the most important part of the icon elsewhere! Yet when Aaron Seigo and Marco Martin explained exactly that, the discussion just dried off and GNOME decided to ignore the spec, when actually its design would also make status notifiers much more useful for gnome-shell than the XEmbed junk. The status notifier spec was started by KDE and adopted by Canonical, it was the opposite for the D-Bus menu spec. In both cases, KDE/Plasma and Canonical/Unity cooperate nicely, only GNOME keeps doing its own, incompatible thing. Cross-desktop status notifiers and native Plasma widgets (plasmoids) can sit right next to each other in the Plasma system tray and look and feel the same, why can't gnome-shell offer the same integrated experience rather than deprecating everything other than gnome-shell-only extensions? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Random koji problems
On Wed, Feb 1, 2012 at 9:46 AM, Rex Dieter wrote: > Jerry James wrote: > >> On Tue, Jan 31, 2012 at 12:42 PM, Tom Callaway >> wrote: >>> No, because xulrunner needs it to rebuild. Why is libvpx breaking >>> package builds? Almost nothing should depend on it. The plan is for the >>> libvpx update to go out at the same time as the xulrunner update. >> >> Sorry, got busy with Real Life and couldn't get back to this thread >> yesterday. In my case, it is because of this chain of dependencies: >> >> PyQt4-devel => >> PyQt4 (via libQtWebKit) => >> qtwebkit (via libQtLocation & libQtSensors) => >> qt-mobility (via libgstphotography) => >> gstreamer-plugins-bad-free => >> libvpx > > Which buildroot? rawhide? f16? (As far as I recall, rawhide, f16 should > have the new libvpx, gstreamer-plugins-bad-free tagged properly) Yes, the buildroots are both fine now. Thanks for fixing them. I was just responding to spot's apparent surprise that an updated libvpx in the buildroot should have broken package building for other people. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
Bastien Nocera wrote: > GNOME never gave an opinion on the spec, we gave an opinion on the > library, which was really just a huge pile of bugs (I know, they patched > a bunch of the applications I maintain, and I get to receive a large > number of crashers because of it). But I don't see any movement from the GNOME side on developing a less buggy library implementing the spec nor on fixing the bugs in libappindicator, so GNOME is ignoring the spec. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Package-Generator] Created tag perl-Package-Generator-0.103-8.fc17
The lightweight tag 'perl-Package-Generator-0.103-8.fc17' was created pointing to: ca2b7d1... Spec clean-up -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Random koji problems
Jerry James wrote: > On Tue, Jan 31, 2012 at 12:42 PM, Tom Callaway > wrote: >> No, because xulrunner needs it to rebuild. Why is libvpx breaking >> package builds? Almost nothing should depend on it. The plan is for the >> libvpx update to go out at the same time as the xulrunner update. > > Sorry, got busy with Real Life and couldn't get back to this thread > yesterday. In my case, it is because of this chain of dependencies: > > PyQt4-devel => > PyQt4 (via libQtWebKit) => > qtwebkit (via libQtLocation & libQtSensors) => > qt-mobility (via libgstphotography) => > gstreamer-plugins-bad-free => > libvpx Which buildroot? rawhide? f16? (As far as I recall, rawhide, f16 should have the new libvpx, gstreamer-plugins-bad-free tagged properly) --rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
Panu Matilainen (pmati...@laiskiainen.org) said: > >>>To-be-installed files obviously have no on-disk fingerprints, so it > >>>wont work for initial installation. So yes, those "fake" compatibility > >>>provides are needed. Strictly speaking, compatibility provides would > >>>be needed for ALL the moved files, not just /bin, as it's technically > >>>perfectly legal for a package to depend on an arbitrary path in > >>>/lib[64], not just /[s]bin. > >>> > >>>- Panu - > >> > >>Would it be possible to leave out these provides and fix each individual > >>package to require in the new path instead? > > > >It isn't practical to "fix" every package that requires /bin/sh. > > It's not "just" that the impracticality either - not providing > /bin/sh, /sbin/ldconfig and the like would mean a huge > incompatibility break with nearly every existing package in the > wild. Not really an option. I'm not convinced of the "all" case, though. /bin/sh, /sbin/ldconfig, etc. could be reasonable for a package to require, and should be provided. Requires: /lib/modules/3.1.2-1.fc16/kernel/drivers/net/3c59x.ko is likely too dumb to live, though. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Package-Generator] Spec clean-up
commit ca2b7d13c0716228c6e03f416ad6eac5ef4bee85
Author: Paul Howarth
Date: Wed Feb 1 16:11:46 2012 +
Spec clean-up
- Run Perl::Critic test in %check too
- BR: perl(Test::Perl::Critic)
- BR: perl(Carp) and perl(Symbol), which might be dual-lived
- Use DESTDIR rather than PERL_INSTALL_ROOT
- Drop version requirement for perl(ExtUtils::MakeMaker); older versions
work
without problems, e.g. version 6.17 on EL-4
- Make %files list more explicit
- Don't use macros for commands
- Use tabs
.gitignore |2 +-
perl-Package-Generator.spec | 97 --
2 files changed, 56 insertions(+), 43 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a9bb77b..9cf01c9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-Package-Generator-0.103.tar.gz
+/Package-Generator-[0-9.]*.tar.gz
diff --git a/perl-Package-Generator.spec b/perl-Package-Generator.spec
index 2491fd5..4051060 100644
--- a/perl-Package-Generator.spec
+++ b/perl-Package-Generator.spec
@@ -1,22 +1,26 @@
-Name: perl-Package-Generator
-Version:0.103
-Release:7%{?dist}
-Summary:Generate new packages quickly and easily
-License:GPL+ or Artistic
-Group: Development/Libraries
-URL:http://search.cpan.org/dist/Package-Generator/
-Source0:
http://search.cpan.org/CPAN/authors/id/R/RJ/RJBS/Package-Generator-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-BuildArch: noarch
-Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
-
-BuildRequires: perl(ExtUtils::MakeMaker) >= 6.42
-BuildRequires: perl(Test::Pod::Coverage)
-BuildRequires: perl(Test::Pod)
-BuildRequires: perl(Params::Util)
-BuildRequires: perl(Scalar::Util)
-BuildRequires: perl(Test::More)
-
+Name: perl-Package-Generator
+Version: 0.103
+Release: 8%{?dist}
+Summary: Generate new packages quickly and easily
+License: GPL+ or Artistic
+Group: Development/Libraries
+URL: http://search.cpan.org/dist/Package-Generator/
+Source0:
http://search.cpan.org/CPAN/authors/id/R/RJ/RJBS/Package-Generator-%{version}.tar.gz
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
+BuildArch: noarch
+BuildRequires: perl(Carp)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Params::Util)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(Symbol)
+BuildRequires: perl(Test::More)
+# Test::Perl::Critic not available in EPEL-4
+%if "%{rhel}" != "4"
+BuildRequires: perl(Test::Perl::Critic)
+%endif
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+Requires: perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
%description
This module lets you quickly and easily construct new packages. It gives
@@ -26,21 +30,18 @@ them unused names and sets up their package data, if
provided.
%setup -q -n Package-Generator-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
-
-make pure_install PERL_INSTALL_ROOT=%{buildroot}
-
+make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} \;
-find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null \;
-
-%{_fixperms} %{buildroot}/*
+find %{buildroot} -depth -type d -exec rmdir {} \; 2>/dev/null
+%{_fixperms} %{buildroot}
%check
-make test
+make test PERL_TEST_CRITIC=1
%clean
rm -rf %{buildroot}
@@ -48,10 +49,22 @@ rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc Changes README
-%{perl_vendorlib}/*
-%{_mandir}/man3/*
+%{perl_vendorlib}/Package/
+%{_mandir}/man3/Package::Generator.3pm*
+%{_mandir}/man3/Package::Reaper.3pm*
%changelog
+* Wed Feb 1 2012 Paul Howarth - 0.103-8
+- Run Perl::Critic test in %%check too
+- BR: perl(Test::Perl::Critic)
+- BR: perl(Carp) and perl(Symbol), which might be dual-lived
+- Use DESTDIR rather than PERL_INSTALL_ROOT
+- Drop version requirement for perl(ExtUtils::MakeMaker); older versions work
+ without problems, e.g. version 6.17 on EL-4
+- Make %%files list more explicit
+- Don't use macros for commands
+- Use tabs
+
* Fri Jan 13 2012 Fedora Release Engineering
- 0.103-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
@@ -62,17 +75,17 @@ rm -rf %{buildroot}
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
* Tue Dec 21 2010 Marcela Maslanova - 0.103-4
-- 661697 rebuild for fixing problems with vendorach/lib
+- Rebuild to fix problems with vendorarch/lib (#661697)
* Tue May 04 2010 Marcela Maslanova - 0.103-3
- Mass rebuild with perl-5.12.0
* Mon Dec 7 2009 Stepan Kasal - 0.103-2
-- rebuild against perl 5.10.1
+- Rebuild against perl 5.10.1
-* Tue Aug 11 2009 Chris Weyl 0.103-1
-- auto-update to 0.103 (by cpan-spec-update 0.0
Re: Review Request for trident
> You'll also need to BR eclipse-swt and add %{_libdir}/java/swt.jar to
> the classpath. Also, set jdk.home in build.properties to something
> reasonable, say /usr/lib/jvm/java. Regards,
There's a macro for the Java home, %{java_home}, set to
/usr/lib/jvm/java by the way.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review Request for trident
On Tue, Jan 31, 2012 at 1:22 PM, Sven Baus wrote:
> Hello everybody,
>
> I'm trying to build a trident package
> (https://bugzilla.redhat.com/show_bug.cgi?id=771480) , because it is
> needed by my main review request for tv-browser
> (https://bugzilla.redhat.com/show_bug.cgi?id=754246)
>
> I ran into some problems building the jar from ant:
> "[javac]
> /home/makerpm/rpmbuild/BUILD/trident-1.3/src/org/pushingpixels/trident/android/AndroidPropertyInterpolators.java:37:
> package android.graphics does not exist
> [javac] import android.graphics.*;
> [javac] ^"
>
> Does anybody know, how to fix this? I'm a bit out of ideas ;).
Since you are not building for the Android platform, I suggest adding
this to %prep:
rm -fr src/org/pushingpixels/trident/android
You'll also need to BR eclipse-swt and add %{_libdir}/java/swt.jar to
the classpath. Also, set jdk.home in build.properties to something
reasonable, say /usr/lib/jvm/java. Regards,
--
Jerry James
http://www.jamezone.org/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
Once upon a time, Genes MailLists said: > Just asking - does a bind mount of /bin instead of a soft link help? That doesn't affect RPM database and yum metadata issues. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On 02/01/2012 04:41 PM, Chris Adams wrote: Once upon a time, Emanuel Rietveld said: On 02/01/2012 01:32 PM, Panu Matilainen wrote: To-be-installed files obviously have no on-disk fingerprints, so it wont work for initial installation. So yes, those "fake" compatibility provides are needed. Strictly speaking, compatibility provides would be needed for ALL the moved files, not just /bin, as it's technically perfectly legal for a package to depend on an arbitrary path in /lib[64], not just /[s]bin. - Panu - Would it be possible to leave out these provides and fix each individual package to require in the new path instead? It isn't practical to "fix" every package that requires /bin/sh. It's not "just" that the impracticality either - not providing /bin/sh, /sbin/ldconfig and the like would mean a huge incompatibility break with nearly every existing package in the wild. Not really an option. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On 02/01/2012 09:41 AM, Chris Adams wrote: > Once upon a time, Emanuel Rietveld said: >> On 02/01/2012 01:32 PM, Panu Matilainen wrote: >>> To-be-installed files obviously have no on-disk fingerprints, so it >>> wont work for initial installation. So yes, those "fake" compatibility >>> provides are needed. Strictly speaking, compatibility provides would >>> be needed for ALL the moved files, not just /bin, as it's technically >>> perfectly legal for a package to depend on an arbitrary path in >>> /lib[64], not just /[s]bin. >>> >>>- Panu - >> >> Would it be possible to leave out these provides and fix each individual >> package to require in the new path instead? > > It isn't practical to "fix" every package that requires /bin/sh. > > There sure seems to be a lot of uncertainty for a "feature" that is > supposedly ready to land. Just asking - does a bind mount of /bin instead of a soft link help? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
Once upon a time, Emanuel Rietveld said: > On 02/01/2012 01:32 PM, Panu Matilainen wrote: > >To-be-installed files obviously have no on-disk fingerprints, so it > >wont work for initial installation. So yes, those "fake" compatibility > >provides are needed. Strictly speaking, compatibility provides would > >be needed for ALL the moved files, not just /bin, as it's technically > >perfectly legal for a package to depend on an arbitrary path in > >/lib[64], not just /[s]bin. > > > >- Panu - > > Would it be possible to leave out these provides and fix each individual > package to require in the new path instead? It isn't practical to "fix" every package that requires /bin/sh. There sure seems to be a lot of uncertainty for a "feature" that is supposedly ready to land. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On 02/01/2012 01:32 PM, Panu Matilainen wrote: To-be-installed files obviously have no on-disk fingerprints, so it wont work for initial installation. So yes, those "fake" compatibility provides are needed. Strictly speaking, compatibility provides would be needed for ALL the moved files, not just /bin, as it's technically perfectly legal for a package to depend on an arbitrary path in /lib[64], not just /[s]bin. - Panu - Would it be possible to leave out these provides and fix each individual package to require in the new path instead? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On mié, 2012-02-01 at 12:01 +, Bastien Nocera wrote: > GNOME never gave an opinion on the spec, we gave an opinion on the > library, which was really just a huge pile of bugs (I know, they patched > a bunch of the applications I maintain, and I get to receive a large > number of crashers because of it). I can not comment on the quality of the library, but GNOME did comment on the spec[0] (or rather: several gnomers did) - there were a couple of objections, none of which have been addressed in the spec as far as I can tell. Florian [0] http://lists.freedesktop.org/archives/xdg/2010-January/011228.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Rpm-maint] Fedora 17’s unified filesystem (/usr-move)
On 01/31/2012 11:30 PM, James Antill wrote: On Tue, 2012-01-31 at 15:58 -0500, Bill Nottingham wrote: James Antill (ja...@fedoraproject.org) said: [root@nostromo ~]# mv /bin /cow [root@nostromo ~]# /cow/ln -s /cow /bin [root@nostromo ~]# rpm -qf /cow/bash bash-4.2.20-1.fc16.x86_64 [root@nostromo ~]# rpm -qf /bin/bash bash-4.2.20-1.fc16.x86_64 rpm should already handle this, no need for the provides. Good to see everyone still doesn't read what I write. As I said, rpm _does something_ to make the above work for -qf (the above even works if you inside /cow ... as long as the /bin symlink exists!). However, it _does not_ work, if you put the above in package provides/requires and try to install them. Eg. It does, in some cases. Which makes it even more fun. Take a system with /usr/bin/sdiff. ... Name: cow Summary: cow Version: 1.0 Release: 1 URL: http://redhat.com/ License: Moo Requires: /bin/sdiff ... root@nostromo x86_64]# rpm -ivh cow-1.0-1.x86_64.rpm --test error: Failed dependencies: /bin/sdiff is needed by cow-1.0-1.x86_64 [root@nostromo x86_64]# mv /bin /cow [root@nostromo x86_64]# /cow/ln /usr/bin -s /bin [root@nostromo x86_64]# /cow/rpm -ivh cow-1.0-1.x86_64.rpm --test Preparing...### [100%] IMO this is pretty crazy, because by changing the symlink back you've broken the prco constraints in the DB (but everything would verify as "correct"). Actually verify does notice this breakage (using slightly different sample specimen to avoid having to muck with /bin): [root@localhost ~]# rpm -Uvh /home/pmatilai/rpmbuild/RPMS/noarch/cow-1.0-1.noarch.rpm error: Failed dependencies: /moo/sdiff is needed by cow-1.0-1.noarch [root@localhost ~]# ln -s /usr/bin /moo [root@localhost ~]# rpm -Uvh /home/pmatilai/rpmbuild/RPMS/noarch/cow-1.0-1.noarch.rpm Preparing...### [100%] Updating / installing... 1:cow### [100%] [root@localhost ~]# rpm -V cow [root@localhost ~]# rm -f /moo [root@localhost ~]# rpm -V cow Unsatisfied dependencies for cow-1.0-1.noarch: /moo/sdiff is needed by (installed) cow-1.0-1.noarch [root@localhost ~]# It also seems like rpm is doing a _lot_ of work it doesn't need to do here, but who knows ... it looks pretty magic (and I'm scared to go find out why/how it's doing the above :). Cc'ing rpm maintainers for their opinion on what rpm is doing and why. This is the somewhat infamous and magical "fingerprinting" at work, whether you actually wanted to know it or not :) Roughly speaking, rpm doesn't look up installed file matches by comparing the entire path, it compares the "fingerprint" (basically inode + device combination) of all matching basenames for equality. So what happens in the above /moo/sdiff case is that rpm looks up all files with 'sdiff' basename from the rpmdb (in this case returning /usr/bin/sdiff from diffutils), and compares the fingerprint of /moo/sdiff and /usr/bin/sdiff for equality. When the /moo -> /usr/bin link is in place, /moo/sdiff and /usr/bin/sdiff are the same physical file regardless of the actual path used to reach it, and thus considered a match. As for the why-part: its a caching and tracking mechanism for dealing with directories vs symlinks to directories. Whether the issue discussed here should be considered a side-effect or an intentional feature is perhaps another question, but that's how rpm has worked since very very early days. To-be-installed files obviously have no on-disk fingerprints, so it wont work for initial installation. So yes, those "fake" compatibility provides are needed. Strictly speaking, compatibility provides would be needed for ALL the moved files, not just /bin, as it's technically perfectly legal for a package to depend on an arbitrary path in /lib[64], not just /[s]bin. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Sat, 2012-01-28 at 00:03 +0100, Kevin Kofler wrote: > Adam Williamson wrote: > > As far as I'm aware, Canonical were reasonably good about proposing the > > libindicator patches for upstream inclusion, but many upstream projects > > - especially those that are part of GNOME - weren't exactly rushing to > > adopt the patches. I think Canonical did try to implement libindicator > > support as a plugin for apps with sufficently sophisticated plugin > > frameworks, which obviously helps. > > That's really GNOME's fault. :-( Canonical explicitly designed > libappindicator (which is the library applications are expected to use, it > uses libindicator behind the scenes; there's also libindicate which is for > communication apps to notify new messages and such, confusing, isn't it?) to > be interoperable with KDE's status notifier spec, and thus applications > supporting libappindicator will also integrate better into the KDE Plasma > workspaces than applications still stuck on the legacy XEmbed-based system > tray protocol and/or using a GNOME-only gnome-shell extension. But GNOME is > giving the finger to cross-desktop protocols and refusing to implement them. GNOME never gave an opinion on the spec, we gave an opinion on the library, which was really just a huge pile of bugs (I know, they patched a bunch of the applications I maintain, and I get to receive a large number of crashers because of it). > It's too bad that our maintainers for the affected packages are often one > and the same as the GNOME maintainers and thus Fedora is mostly siding with > GNOME on this and refusing to carry those patches, hurting all non-GNOME > desktops, not just Unity. I refuse to carry the patches because libappindicator is far too buggy to be widely deployed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
Le Mar 31 janvier 2012 21:32, James Antill a écrit : > Also, even if someone could fix rpm to work this out, making this work > at the yum layer is _much_ harder ... because the repodata does not > currently specify that /path/to/blah is a regular file or a symlink (and > if it's a symlink, what it points to). This, BTW, is a PITA whenever you need to check repo compliance with any packaging guideline that specifies file location or ownership. It's not possible to do a simple repoquery to find problem packages, you have to download every single package with a file name in the wrong location, just in case it's not actually wrong but contains a compat symlink pointing to the right file (that may or may not be installed by the same package). That makes simple repo checks astonishingly long and bandwidth-expensive. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
